DeadLine:2017.10.13 23:00html
聲明:本做業以鄒欣老師博客
http://www.cnblogs.com/xinz/archive/2012/03/26/2417699.html
http://www.cnblogs.com/xinz/p/3308608.html
爲基礎進行修改。算法
不少同窗有疑惑:微信
軟件工程課是否就是枯燥的理論課?
或者是幾個牛人拼命寫代碼,其餘人抱大腿的課?
要否則就是學習一個程序語言,練習某個框架,搞一個職業培訓的課?數據結構
都不對!軟件工程有理論,有實踐,更重要的是分析,思辨,總結。在課程中,同窗們本身組織團隊寫一個軟件發佈,而後分析其中的得失,的確是學習軟件工程的一個好方法。這樣能根據切身體會來分析,頗有價值,但也有可能「身在此山中」,未能看清全局。並且,課程時間有限,咱們也不能作不少具體的項目。所以,咱們也須要從間接經驗中學習,分析。別的項目的成敗一樣給咱們不少啓發!架構
咱們生活中不少時候要和軟件打交道,你們上課開小差時候玩的手機遊戲,背英語單詞的手機App,買火車票的網站,互相聯繫用的微信微博,等等,都是軟件,都很值得分析。框架
- 你爲什麼成爲它們的用戶?
- 它們的團隊作對了什麼,作錯了什麼?
- 軟件工程質量如何?
- 若是你來作,會作得更好麼?
經過各類案例分析,評測,辯論,總結,咱們就能看到軟件工程的原則在實踐中的種種體現,學好軟件工程,幫助咱們在實踐中作得更好。工具
分析什麼樣的軟件也有講究,這就要說到一個故事:學習
某國空軍爲了提升飛機在空戰中的存活率,決定加固飛機,可是加固什麼地方呢?他們研究空戰後飛回基地的飛機,飛機各部分中彈的地方和密度,想以此得出結論。可是專家們忽略了一點,那些被擊中要害的飛機,都沒有能飛回基地,也沒有可以參加這些調查。測試
倖存者偏倚(Survivorship bias)是一種常見的邏輯謬誤,意思是隻能看到通過某種篩選而產生的結果,而沒有意識到篩選的過程,所以忽略了被篩選掉的關鍵信息。這東西的別名有不少,好比「沉默的數據」、「死人不會說話」等等。網站
所以,咱們不光要分析那些經歷戰場的考驗而最後"活着出來"而勝利的軟件,還要分析那些在戰場中被戰勝,或者傷痕累累,正在掙扎的軟件,這樣才能全面地瞭解軟件工程的原理在好/壞軟件上所起的做用。
有的同窗會說:
「我只會看看界面,寫不出來..."
那麼,能夠看看這個只評價界面的分析報告,爭取寫出相似水平的報告來:如何評價微軟的UI設計?
當鄒欣老師在博客園班級博客微信羣中問道:
咱們之前讓軟件工程的學生測試博客園,提意見,不知道博客園認爲這樣的活動對博客園有意義麼?若是這個學期咱們又繼續作,博客園支持麼?
博客園負責人dudu在中這樣說:
有意義,支持!咱們這個月開始啓動博客產品的大改進!
因而,請對cnblogs.com的博客功能,特別是https://edu.cnblogs.com中針對學習,教學,班級管理,互相交流的功能進行分析,這一方面的參考對象是:www.csdn.net。
另外,cnblogs的各項功能(包括博客和班級博客)在手機上作得如何呢?
另外,關於cnblogs.com的競品分析,請嘗試分析stackoverflow.com:
雖而後者不是博客站點,但二者都是面向開發者的社區:
所以仍是有不少能夠分析的地方的:D
有一天,在咱們的構建之法教學羣內發生了這樣的對話:
鄒欣老師:
點評軟件,找到一家願意合做的。
桑文鋒-神策數據:
能夠嘗試分析一下咱們Sensors Analytics,這是一個數據分析工具。我還能夠來北航做講解:D
因而,大家懂的。
不瞭解神策數據的同窗請看簡介:
目前神策分析主要有如下五個功能:
- 事件分析
- 漏斗分析
- 留存分析
- 行爲序列
- 用戶分羣
這些功能針對不一樣的業務決策者均能起到重要做用。
另外,從功能上來講,還有一個使用上的功能:
數據概覽。
這是一個不一樣角色都會用到,適合作易用性分析的功能,在裏面能夠靈活添加配置、建立概覽、添加數據項等。
請選取其中一個功能進行測評。另外,能夠測評的方面有:
最近,必應詞典產品經理最近給了鄒欣老師一個反饋:
歡迎測試移動版本,但願着重測試這些新功能:拍照翻譯,語音翻譯以及詞彙量測試~
因而,咱們但願你們能着重測試這些功能:D
必應詞典客戶端有Windows 10,Windows Phone,iPhone,Android,iPad客戶端!
它的競爭品更是多得數不勝數!
註冊並使用網站的功能,按照描述的bug定義,找出幾個功能性的比較嚴重的bug。至少兩個。用專業的語言描述(每一個bug很多於40字),若有必要,能夠配圖。
相信每一個同窗的朋友中必定有人須要用這樣的軟件(例如你上課的同窗),記載你對這位用戶的採訪。
提示: 採訪提要
- 介紹採訪對象的背景和需求(他們爲什麼要開博客,讀博客,給博客點評,她有什痛點,她還有別的需求麼)
- 讓採訪對象使用10–30分鐘這個軟件的基本功能(請上傳照片證實用戶的確正在使用,遠程採訪的同窗請讓別人幫忙照相)
- 描述用戶使用這個產品的過程,用戶的問題解決了麼?軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗方面有問題麼?
- 用戶對產品有什麼改進意見?
結論:通過這麼多工做,你必定有充分的理由給這個軟件下一個評價:
請選擇一個結論。除了定性的結論,是否能有定量的結論(就像最近比較時髦的手機評測那樣,跑個分?),如何定量地評價一個軟件?
請看這個連接,並嘗試進行定量的測評:
http://www.cnblogs.com/xinz/p/3308608.html
在書上咱們看到:
程序 = 算法 + 數據結構;
軟件 = 程序 + 軟件工程(軟件服務還有數據,內容的因素)
軟件企業 = 軟件 + 商業模式
那麼:
你在第一部分發現的bug,爲什麼軟件團隊不能在發佈前修復?他們是不知道,仍是有意不修復?你以爲是什麼緣由?從下面的可能性中選取幾個:
- 對用戶需求掌握很差
- 具體的設計質量不高
- 開發人員粗枝大葉
- 測試把關不嚴,敷衍了事,沒有注意在特殊的配置或環境下測試
- 其餘
這個軟件/網站/服務有不少能夠提升的部分,若是你是新上任的項目經理,如何提升從而在競爭中勝出?
把上面幾個部分都寫清楚,並帶有選擇第回答其中三分之二的問題,發佈一個我的博客。
做業實際花費時間記錄:請你們在博客末尾記錄本次博客做業實際花費的時間,計時標準爲:一心一意開始作相關調研,不能幹其餘事。
按時提交,文章顯示較高的專業水平和認真細緻的工做態度,詳略得當:滿分。 按時提交,有各類不足,則酌情扣分。 遲交做業,得0分。 不交做業,從學生成績中倒扣分數。 抄襲等行爲則根據學校有關規定處理。