軟件工程第三周作業

第一部分：調研， 評測

1.下載並使用，描述最簡單直觀的個人第一次上手體驗。

   首先登錄成功後，就發現可以簽到，下面還有朋友圈，新聞，消息，我的個人設置。
   朋友圈的話就很豐富了，賣書的，發雞湯的，還有一堆賣七七八八東西的；新聞主要都是與學校相關的消息與通知等，但是該知道的消息還是不知道；消息的話就主要是教務等的消息，可以和同學私聊；個人設置的話就是一些自己的信息的設置，換頭像，查課表什麽的都可以。
   總而言之，第一次上手體驗，感覺反應有點慢，有時還會卡住，主要是功能面向學生群體，還是很適合我們使用，會方便許多，但使用率和實用性不高。

2.按照《構建之法》13.1節描述的bug定義，找出幾個功能性的比較嚴重的bug，至少2個。用專業的語言描述（每個bug不少於40字），如有必要，可以配圖。

(1)第一個Bug表現為“教務”的聊天界面上沒有輸入框，以前是有可以輸入編號用以查詢不同的信息，如今卻無法輸入，而其中播報的信息中也有語意不明的地方，如圖的網上辦事大廳並不知道應該到哪裏去尋找以及設置。

(2)第二個Bug是課程表裏的設置裏的有一個換膚的功能，但點擊之後並沒有反應，初步判定為在與本地圖庫連接的時候發生了錯誤，無法進行連接。

(3)第三個Bug表現為剛進入應用中心內的新聞中心等一系列圖標會不停閃爍。進行黑箱測試後，初步判定為軟件加載圖標時使用循環加載，新聞中心被多次加載。

3.相信每個同學的朋友中一定有人需要用這樣的軟件，選擇一個朋友（用戶）進行采訪，並加以記載。

(1)采訪對象的背景和需求

該對象是集美大學大三學生，已經使用該軟件接近3年，平日使用該軟件進行課表查詢，期末成績查詢，網費充值等。

(2)讓采訪對象使用10 – 30 分鐘該APP的功能

(3)用戶使用該軟件的過程

簡單描述如下：首先是每日簽到和送花，並為當天生日的同學送上生日祝福。其次，還會查詢當天的課表，期末查詢成績。

(4)采訪過程
問：在你使用過集大通之後，你的問題解決了嗎？

答：解決了呀，我一般只是用來查課表，查期末成績，充網費而已。要求並不高。

問：你覺得集大通在界面，功能，準確度上有什麽優缺點呢？

答：界面我說不出來有什麽好不好的地方，至於功能和準確度，缺點的話，就是在課表加載的時間上有點慢，期末的成績播報也沒有及時，還有第二天的課程安排也沒有很及時播報。優點的話，它可以不用內網就可以查成績，還可以充網費，現在還可以查詢充值校園卡等，就這些都挺不錯的。
 

問：用戶體驗方面有問題麽？

答：就是加載很慢，偶爾還會卡住，以及消息播報不及時。

問：您對集大通有什麽改進的意見？

答：課程表加載可以快一點，消息不要經常斷線，第二天的課程安排和期末成績的播報能及時點。

4.請選擇一個結論：經過這麽多工作，你一定有充分的理由給這個軟件下一個評價: 一般

第二部分：分析

1.使用此軟件的所有功能，估計這個項目做到這個程度大約需要多少時間（團隊人數6人左右，計算機大學畢業生，並有專業UI支持）。

答：從大一到現在，也是見證了它三年的成長到現在功能已經逐漸完善了。我覺得像這樣的項目的話，初期開發考慮肯定沒有那麽周全，基本功能實現的話，大概會需要四個月左右。而後才會日趨完善，在逐步找到功能缺陷，也需要一定的時間，只看開發時間的話，總的來說也還需要四個月左右。

2.不要寫成一個羅列功能的流水單子！而是要集中火力在一個場景，這個場景中典型用戶有什麽需求，軟件如何解決了需求（或者沒解決），UX有什麽細節是好的，差的，請結合書上UX的內容來分析。

   答：我認為，在某個特定的場景中，典型用戶一般應該被設置為與之相關的用戶群體，將他的需求典型化，比如一個電子商務網站，專用於交易石頭藝術品一類的環境，這個時候系統就要將用戶細化分為會用電腦的，不會用電腦等，甚至更細化。而軟件在被使用的過程中，就能夠獲得用戶的使用信息以及使用頻率，或者可以開設一個通道，用戶反饋，通過反饋，能獲得很多有用的信息，某功能常被使用，那就要細細完善，某些功能有需求但未被開發，就可以考慮一下功能開發。
   UX之中的同理心我認為是極好的，從用戶的角度出發去思考，去設計，會讓用戶更有親近感，更願意去使用這個軟件。
   但是也有不好的地方，比如說，用戶需要幫助，你提供的幫助是否符合用戶所需要的呢？幫助過於簡單就無法解決用戶的需求，幫助過於復雜，他的使用率也很低，並不能提供幫助。這種時候就需要去細化用戶需求，工作量就會很大，而且定位也並不一定能準確。

3.你在第一部分發現的bug，為何軟件團隊不能在發布前修復？他們是不知道，還是有意不修復？你覺得是什麽原因？從下面的可能性中選取幾個：對用戶需求掌握不好；具體的設計質量不高；開發人員粗心大意；測試把關不嚴，敷衍了事，沒有註意在特殊的配置或環境下測試；其他

   答：(1)第一個Bug我認為應該是測試把關不嚴，敷衍了事，沒有註意在特殊的配置或環境下測試。這個功能在有的手機環境上是可以使用的，有的不行。
   (2)第二個Bug我認為應該是具體的設計質量不高。這一現象也是一開始就有了，也見過很多次了，一直都沒得到關註，可能是覺得並不是什麽大問題，但是小問題總是越積越多的，最後就成了大問題了。
   (3)第三個Bug我認為應該是開發人員粗心大意。在一開始的時候可能還是可以使用的，只是後來隨著使用的次數加多，後臺的bug也越來越多，沒有及時修復就導致了現在的後果。

4.團隊在哪一個層次還有問題？可以把自己想問軟件團隊的問題都列出來，也許就能得到團隊的親自解答了！

答：主要就是後臺這邊，消息的播報延遲了，沒有及時播報，這個的設置的話，其實只要重新設置時間就好了吧？主要是隨著使用時間的加長，時間也會有所延遲，導致時間出現偏移。我的猜想是這樣，不知道實際上是怎麽樣。

5.從各方面的問題，推理出這個軟件團隊在軟件工程方面可以提高的一個重要方面 (具體建議)。

答：我覺得還是同理心吧，平時可以做個面向全校集大通的使用者的調查問卷，統計一下大家對於集大通還有什麽未開發的使用需求，衡量一下利弊可以考慮是否要開發。還有就是對有能力的同學開放一個架構平臺，有什麽自己想加的功能可以自己去設計，去實現。當然了，這些都需要得到大力的宣傳，鼓勵並支持這種行動。

第三部分：建議和規劃

1.這個軟件/網站/服務有很多可以提高的部分，如果你是項目經理，如何提高從而在競爭中勝出？

答：詳情參考第二部分的第五點，以一個開放的平臺集思廣益，將會得到更多意想不到的收獲。平臺就是市場，市場就是一個項目賴以生存的東西，要想得到提高甚至勝出，市場是必不可缺的，當然了，市場和成本也需要達到一個平衡狀態，不能顧此失彼。

2.目前市場上有什麽樣的產品了？

答：每個高校都會有各自的“校園通”，各式各樣，百花齊放，但是針對人群也只是校內人員，所以不存在什麽太大的競爭壓力。

3.作為新的項目經理，這個產品的核心用戶群是什麽樣的人，典型用戶長什麽樣？學歷，年齡，專業，愛好，收入，表面需求，潛在需求都是什麽？

答：核心用戶群體是校內人員，典型用戶包括老師，學生。

4.功能：你要設計什麽樣的功能?為何要做這個功能，而不是其他功能？為什麽用戶會用你的產品/功能? 你的創新在哪裏? 可以用 NABCD 分析。

答：我們初期打算制作一個簡單一點的“周打卡”微信小程序，主要功能就是可以實現在打卡話題下分享個人打卡動態，也相當於一個交流分享的平臺。
    我們認為在當今社會，網絡社交是相當火熱的，而正因為這種火熱，我們親近網絡更多與大自然，或者說我們的現實生活，而我們的小程序就是從這一點出發，每周發布多個話題打卡，比如說每日早起打卡，時間為期一周，然後如果成功完成任務了就可以領取小獎勵。
    像這種小程序也是現今很受歡迎的東西，因為現在也有很多人意識到了自律的重要性，但卻沒有這種自覺性去做到，有了這樣的小程序不僅方便，還使用，符合用戶需求，迎合了用戶的喜好。
    就NABCD的分析來說，需求和好處前面都有提到，做法的話，我們都也是有做過小項目的經驗了，遇到難題的話，可以請教老師，也可以自己去查資料，或者和隊員一起討論。競爭，現在這種打卡小程序還比較少，但是這種打卡的平臺還是很多的，競爭可以說是很大了，但是我們可以優化界面美工，簡化操作步驟，讓用戶體驗更好，再者就是發布的打卡任務更有趣，更符合用戶需求，更有吸引力。交付，就交付來說我們可以先小範圍推廣，從宿舍到班級，到學院，逐步實現使用範圍擴大

5.如果你有錢可以招聘 6 個人, 有 4 個月的時間, 你作為項目經理, 應該如何配置角色 (開發，測試，美工等等)？

答：我覺得可以先安排三個人進行開發，因為開發任務會比較重，需要的人會比較多。三個人美工兼測試，測試、美工一類比較簡單一些，所以人會少一點。像這樣子將工作分攤一下會比較好，後期測試後還需要開發人員對其進行改進。

6.描述你的團隊在16周期間每周都要做什麽，才能在第16周如期發布軟件的改進版本，並取得預想中的成績。

答：首先肯定是進行項目討論，討論出來一個大綱，然後細化細節。然後後臺開發的就沿著大綱進行開發，同時前端的就可以著手做界面了。期間必不可少的在周末的時候就做個總結，總結一周的工作有沒有達到預期，然後彼此之間有沒存在什麽疑問，或者交流一下意見什麽的，促進接下來的開發能正常進行。之後就是測試，我有兩個想法，一是可以讓開發人員相互錯開對對方的代碼進行測試；二是可以大家一起對此進行測試，有的人準備測試數據，有的記錄，然後開發人員進行改進。

軟件工程第三周作業