項目 | 內容 |
---|---|
本次做業所屬課程 | 北航軟件工程2019 |
本次做業要求 | 要求詳情 |
我在本課程的目標 | 熟悉瞭解現代軟件工程,提升自身能力 |
本次做業的幫助 | 在《構建之法》的幫助下更好了解軟件工程 |
假如你發明了電報,創辦了電報公司,這時一個年輕人上門推銷了他的創新——電話。你敏銳地看到這個創新將會顛覆目前的電報產業,這時你會怎麼想?會不會恨這個新發明?html
在這個問題上我可能有一點不同的見解。創新是爲了咱們的社會和時代向着未知的遠方邁進,是給咱們每一個人帶來愈來愈方便高質量生活的一條必經之路。尚且不說每一個人都有如此高尚的道德品質與以人 類發展爲目標的信仰,即便是爲了利益,我認爲當一個發明電報的人看到新發明電話的時候想的並非恨。我相信每個聰明人更多想到的應該是吸取與發展,由於他已經看清楚這個創新會顛覆目前的一切,那爲何不選擇參與這個創新而進一步昇華自我?我以爲當咱們承認一個創新的時候,不論它會對咱們形成怎樣的影響,咱們仍是喜歡如此的創新。若是夾雜了太多的主觀情感與因素,那麼這是對創新的一種不負責任,也就談不上本身於創新有什麼關係了。git
在前面關於創新的幾個問題探討過程當中做者曾屢次提到專家們對於顛覆性技術的預測每每是錯誤的——由於顛覆性技術的市場還不存在,而我也查了一些資料而且深有體會:通常的人是不會看到這些匪夷所思的顛覆性創新在將來不久將會有如此的市場,並且即使是創新者本人在這個問題上也不是特別的肯定,每每會對本身的想法持有懷疑的一面。結合書中所提到的SWOT框架以及我本身查閱到的一些關於SWOT分析框架的內容,無非是分析企業在當前社會市場中的優劣勢與利害關係。那麼問題就來了,企業的專家在分析一個創新的時候固然也會想到這些,可是他們不少的分析預測卻與實際相反,那咱們爲何還要以如此方式去分析本身創新的將來?是顛覆性技術創新的未知因素太多?仍是專家在分析預測時不夠客觀全面?github
- 第一象限(解決剛需且殺手功能):建議採起「差別化」的辦法,盡心盡力投資在這個領域。
- 第二象限(解決剛需提供外圍能力):建議採起「抵消」和「優化」的辦法。
- 第三象限(不是剛需且是輔助功能):建議採起「維持」的辦法,以最低代價維持此功能。
- 第四象限(不是剛需但咱們有獨特的辦法作的更好):建議採起「維持」的辦法,或者限制「不作」,等待好時機。
書的8.5中提到過要把用戶從競爭對手那裏吸引過來,團隊本身的產品要有一個差別化的焦點,在這個焦點上,咱們的團隊能作得比別人好10倍(10X原則)。也就是咱們全身心投入到一個殺手功能也就是第一象限上去,可我覺的有時候咱們的關注點反而應該在第二象限纔對,也就是用戶必要的外圍功能。既然是用戶必要的功能,那我能夠理解爲是這個產品的基礎功能。咱們可不能夠有一個相似於推動式創新的想法就是把這些基礎外圍功能作到比別人好2倍,我暫稱它爲「廣泛2X原則」,由於據我所知所感,有不少好的軟件在全方位的功能與體驗上比競爭對手都要好出一個檔次,好比一款用來背英語單詞的APP——墨墨。因此從性價比上來看(可能10X原則付出會更多更難)優化提升第二象限的產品功能是否是比只關注殺手功能更好一些?web
我覺的產生這兩類人的主要緣由仍是我的的性格問題,對於我來講我大機率會是上面談到的第二類人。我是比較傾向於先把本身的事情作到心安理得,再去管其餘的事情。由於一直以來不管是老師的教導仍是在實際的體會中,一旦你在某一個項目中留下了不少漏洞,你再回來補救所花的時間可能要比當時全面周到完成項目的時間更多。但第一類人的活躍又能獲得更高的曝光率,這裏我有一個問題就是如今的企業或者公司中更看重的是「蘿蔔快了不洗泥」型的仍是「慢工出細活」型的開發人員呢?編程
書中對於敏捷開發提到了不少條的原則,可其中不少條好比「以有進取心的人做爲項目核心,充分支持信任他們」卻徹底沒法讓我與「敏捷」聯繫起來。在我搜索查閱了敏捷開發等相關內容後大概瞭解了一點就是一個項目的模塊化,也沒有更多的深層次理解。而咱們這門課的微信羣名中也提到了「敏捷工程」,這使我覺的敏捷開發必定是現代軟件工程中十分重要的一環,因此我想知道敏捷流程與敏捷開發具體須要咱們在從此不管學習工做中怎樣實踐?他們更深一層的內涵是如何的?api
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years. This led many to credit Tukey with coining the term, particularly in obituaries published that same year,although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim. The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.服務器
——引用自維基百科微信
Margaret H. Hamilton "is the person who came up with the idea of naming the discipline, "software engineering", as a way of giving it legitimacy." According to Hamilton:
During this time at MIT, she wanted to give their software "legitimacy", just like with other engineering disciplines, so that it (and those building it) would be given its due respect; and, as a result she made up the term "software engineering" to distinguish it from other kinds of engineering.
Hamilton details how she came about to make up the term "software engineering":
When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.
When Hamilton started using the term "software engineering", software engineering was not taken seriously compared to other engineering, nor was it regarded as a science. She began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering. Over time the term "software engineering" has gained the same respect as any other discipline.The IEEE Software September/October issue celebrates the 50th anniversary of software engineering.Hamilton talks about "Errors" and how they influenced her work related to software engineering and how her language, USL, could be used to prevent the majority of "Errors" in a system. "At MIT she assisted in the creation of the core principles in computer programming as she worked with her colleagues in writing code for the world's first portable computer".Hamilton's innovations go beyond the feats of playing an important role in getting humans to the moon. "She, along with that other early programming pioneer, CoBOL inventor Grace Hopper, also deserve tremendous credit for helping to open the door for more women to enter and succeed in STEM fields like software."框架
——引用自維基百科electron
GitHub(3100萬用戶)
Microsoft TFS(Team Foundation Server)
Trac
Mercurial