軟件工程網絡15我的做業3——案例分析

題目

不少同窗有誤解:html

  • 軟件工程課是否就是理論課?
  • 或者是幾個牛人拼命寫代碼,其餘人打醬油的課?
  • 要否則就是學習一個程序語言,搞一個職業培訓的課?
    都不對!軟件工程有理論,有實踐,更重要的是分析,思辨,總結。在課程中,本身組織團隊寫一個軟件,而後分析,這樣能根據切身體會來分析,頗有價值,但也有可能「身在此山中」,未能看清全局。並且,課程時間有限,咱們也不能作不少具體的項目。所以,咱們也須要從間接經驗中學習,分析。別人的項目的成敗一樣可以給咱們不少啓發!

咱們生活中不少時候要和軟件打交道,你們上課開小差時候玩的手機遊戲,買火車票的網站,互相聯繫用的微信、QQ,等等都是軟件,都很值得分析。算法

  • 你爲什麼成爲它們的用戶?
  • 它們的團隊作對了什麼,作錯了什麼?
  • 若是你來作,會作得更好麼?
    經過各類案例分析,評測,辯論,總結,咱們就能看到軟件工程的原則在實踐中的種種體現,學好軟件工程,幫助咱們在實踐中作得更好。

產品分析

我選擇「智慧集大平臺——集大通APP」進行產品分析
(在平時交流中會跟朋友討論一些集大通的問題,她有一些想法,這樣恰好有采訪的素材)微信

第一部分:調研, 評測

一、下載並使用,描述最簡單直觀的我的第一次上手體驗。

  • 還沒進入集美大學,就先使用了集大通,直觀感覺是方便,爲新生提供了了解學校的途徑。
    (第一次使用離如今真的有點遙遠,幾乎忘了對集大通的第一印象。下面談談對界面的直觀感覺。)
    ① 喜歡登陸界面密碼的當心心;
    ② 剛登陸就跳出「課餘生活」界面,其實對剛剛接觸這個軟件的同窗有點迷茫(好比我本身);
    ③ 「朋友圈」界面貼近咱們經常使用界面(好比QQ的界面),很習慣;
    ④ 新聞界面幾乎都是思政(這個嘛);
    ⑤ 「消息」界面分「消息」和「聯繫人」,用起來很快上手;
    ⑥ 「個人」裏面有實用的課程表、應用中心,也有娛樂性任務。
    總的來講,用起來仍是比較容易上手,沒有不少讓人誤解的地方,整體感受還不錯。

二、按照《構建之法》13.1節描述的 bug 定義, 找出幾個功能性的比較嚴重的 bug,至少2個。

  • 用專業的語言描述 (每一個bug 很多於 40字),若有必要, 能夠配圖。
  • Bug:軟件的缺陷
    Bug能夠分解爲:症狀、程序錯誤、根本緣由
    1)症狀:即從用戶的角度看,軟件出了什麼問題。
    2)程序錯誤:即從代碼的角度看,代碼的錯誤致使了軟件的問題。
    3)根本緣由:錯誤根源,即致使代碼錯誤的根本緣由。

                           ——摘自《軟件工程》13.1節網絡

功能性bug應該很差找(畢竟一直在改進更新),就說一下我的認爲的缺陷:
(程序錯誤不知道該怎麼寫,根本緣由均爲我的推測)(刪刪減減就只剩了3個我的以爲問題比較明顯的缺陷)
(1)症狀:進入一個界面要好久(這是我一直很煩惱的問題),網絡差一些就根本進不去,但仍是會一直在刷新。並且正在刷新有時還不能取消刷新。
  程序錯誤:(未知)
  根本緣由:進入界面時,程序在搜索相應的功能,這個算法可能不太好,所以一直在刷新;每次刷新時,進行所有程序的刷新,拖慢刷新速度。app

(2)症狀:官方微博不能直接打開手機上的已有微博,只能跳到下載微博的界面,並且沒法下載。
  程序錯誤:(未知)
  根本緣由:沒有識別手機上是否有微博的功能,沒有提供微博下載的正確連接。佈局

(3)症狀:消息中的教務前一秒能夠進去,去刷一下其它界面再回來就進不去消息界面了,退出集大通再進行訪問就能夠進入消息界面。
  程序錯誤:(未知)
  根本緣由:程序卡在某一個地方,沒法識別用戶進行的操做。學習

三、相信每一個同窗的朋友中必定有人須要用這樣的軟件, 選擇一個朋友(用戶)進行採訪,並加以記載。

(1)介紹採訪對象的背景和需求

背景:集美大學理學院學生
需求:
① 爲何使用集大通 → 首先,大一尚未入學就被錄取通知書安利了集大通;其次,主要用集大通查看課程表以及教務功能。
② 「痛點」 → 目前但願集大通能夠直接充值校園卡,不須要到圈存機領款(以爲又慢又麻煩)
③其它需求 → 但願集大通能夠有快捷方式,好比網費充值,一點進去就能充而不是通過一系列的繁雜過程,以爲有點冗餘;這個快捷方式能夠本身設置,拖到首頁或者合適的地方。測試

(2)讓採訪對象使用10 – 30 分鐘該APP的功能 (請上傳照片證實用戶的確正在使用, 遠程採訪的同窗請讓別人幫忙照相)

(3)描述用戶使用這個產品的過程,用戶的問題解決了麼?軟件在數據量/界面/功能/準確度上各有什麼優缺點?用戶體驗方面有問題麼?

① 過程:用戶首先登陸,再根據習慣打開了應用中心進行使用,期間咱們交流了各自對集大通的見解,提出了一些相同的想法。(如優缺點)
② 用戶表述的是目前存在的問題已經想要的功能,因此用戶的問題沒有解決。

A. 數據量——集大通有不少消息的更新都不夠同步,若是過久沒有進入界面就會下線,下線以後的消息都不會同步;集大通有不少不用的功能都會被擱置,好像再也不更新消息,好比應用中心的新聞中心,裏面幾乎沒有什麼內容。而後不但願有過於暴露本身的隱私信息,什麼宿舍分配之類的功能,感受這個數據量就「太大」了吧。
B. 界面——整體來講仍是不錯的,容易上手,界面佈局比較熟悉。但一張課程表能夠不須要兩個頁面。
C. 功能——用戶認爲應用中心能夠不要那麼多功能,好比說須要內網服務的,就能夠不要顯示在集大通裏,在學校能夠用i集大和教務處,不在學校同樣都用不了。好比說易班網,其實易班不都有APP了嘛。
D. 準確度——從這點來講仍是不錯的,從常用的課程表和教務功能(好比成績查詢)來講,至少是不會出錯的。
④ 用戶體驗方面以爲許多功能都很雞肋,無關緊要。網站

(4)用戶對產品有什麼改進意見?

① 內網鏈接的功能顯得有點雞肋,能夠不要。(還有挺多用不到的功能的)
② 但願有快捷功能,還能夠本身編輯。
③ 朋友圈有各類屏蔽功能。(我的意見)
④ 但願進入圖書館的界面就是搜索館藏書目而不是學術資源。(我的以爲圖書館這個功能主要是來查找想借的書的)ui

四、請選擇一個結論:通過這麼多工做,你必定有充分的理由給這個軟件下一個評價:

  • 很是不推薦
  • 不推薦
  • 通常 √
  • 好,不錯
  • 很是推薦

理由:集大通的許多功能都不怎麼被學生用到(老師那邊不太清楚),學生用戶能用到的只有充值校園卡,網費充值,圖書館查詢,教務信息查詢,網上辦事大廳,以及查詢課程表等;更況且朋友圈幾乎都是廣告,都有點避而遠之;而後本身也不怎麼用集大通;因此個人評價是通常。

五、[附加題]除了定性的結論,是否能有定量的結論 (就像比較時髦的手機評測那樣, 跑個分?), 如何定量地評價一個軟件?

這裏貼一個定性評價與定量評價的概念:定性評價與定量評價

從定量的角度來講,能夠統計用這個軟件的人數,用這個軟件的功能的人數;從而斷定這個軟件是否收到用戶的承認。

(簡單說一下)

第二部分:分析

一、使用此軟件的全部功能 , 估計這個項目作到這個程度大約須要多少時間 (團隊人數6 人左右, 計算機大學畢業生, 並有專業UI 支持)。

  • 需求調研:找老師和學生進行調研,大概1周(從設計問題到統計完成)
    需求分析:根據調研的結果進行分析,並作出一份「痛點」圖,大概1周
    系統設計:要設計蠻多的功能的,大概一個月
    軟件編碼:2個月(能夠在系統設計初步完成的時候開始)
    軟件測試:測試須要全面一些,大概3周
    實施發佈:2周
  • 總的來講,大概須要5個月

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

(額,不知道UX什麼意思,還查了一下意思的我)

(1)典型用戶的需求:但願將不經常使用的功能刪除或減小,並添加「快捷方式」功能,以便於使用;完善充值校園卡的功能。(軟件還未解決)
(2)集大通的用戶體驗:(主要體驗應用中心的功能)

應用中心 優勢 缺點
第一印象 看起來有不少功能 實用的功能比較少
界面 一目瞭然 有的圖標會一閃一閃的
功能
個人媒體 「易班網」「大學主頁」「官方微博」比較方便 可是這裏的功能學生都不怎麼用到
個人系統 內網結合的方式更好的展現了系統的功能 可是內網通常在APP中不多用到,使用時有一些麻煩(宿舍分配好像沒什麼用啊)
個人服務 這裏的功能實用的較多,方便學生 「電量助手」只是拿來查看電量使用狀況的,不能充值電費/「圖書館」的第一界面不是館藏查詢而且切換繁瑣
其餘 (額,沒有發現什麼優勢) 「網上辦事大廳」裏的功能跟「網費充值」同樣,「集大通」是來下載集大通APP的,可是不是正在使用APP了麼
我的事務 「課程表」功能仍是挺實用的 不能本身隨意編輯
總結 「個人服務」與「我的事務」較爲實用 功能分類有些不明確,「其餘」的功能累贅

三、你在第一部分發現的bug,爲什麼軟件團隊不能在發佈前修復?他們是不知道,仍是有意不修復?你以爲是什麼緣由?從下面的可能性中選取幾個:

  • 對用戶需求掌握很差 √
  • 具體的設計質量不高
  • 開發人員粗枝大葉
  • 測試把關不嚴,敷衍了事,沒有注意在特殊的配置或環境下測試
  • 其餘 √ 好比沒有發現這個bug或者這個bug是以後纔出現的,原來沒有。

四、團隊在哪個層次還有問題? 能夠把本身想問軟件團隊的問題都列出來, 也許就能獲得團隊的親自解答了!

(1)團隊需求調研的形式?
(2)團隊進行APP試用過程當中是否是發現了大量的問題,以致於小問題不太起眼?
(3)團隊開發的功能那麼多,可是不少並不完善或正在完善,是否考慮下架一些功能?
(4)團隊是否太過將開發中心放在新功能的開發上而忽略了之前最想作的功能?
(5)在同步更新消息這個問題上,爲何不能下線也更新消息?

五、從各方面的問題,推理出這個軟件團隊在軟件工程方面能夠提升的一個重要方面 (具體建議)。

在作用戶體驗的時候能夠多讓幾我的進行用戶體驗,以用戶的角度看問題,將沒有實質性意義的功能刪除,再增添一些用戶以爲應該要有的功能,好比我以爲能夠在「個人」頁面增長一個快捷功能服務;而且在這個期間能及時發現軟件出現的小問題,而後改正。

第三部分:建議和規劃

(參考《構建之法》第8章功能的定位和優先級;第9章項目經理)

一、這個軟件/網站/服務有不少能夠提升的部分, 若是你是項目經理,如何提升從而在競爭中勝出?

  • 我參考了第8章8.4節的內容,以爲能夠利用NABCD模型對項目進行需求分析,以便更好的知足用戶的需求,在競爭中脫穎而出。
    N(Need):全面調研用戶需求,看他們須要的是什麼樣的軟件,團隊能夠根據他們的需求作出怎麼樣的項目改變。
    A(Approach):完成一些需求後,團隊能夠對這些知足需求的功能進行先進行測試,再將這些功能推薦給提意見的用戶,看是否還有須要改進的地方。
    B(Benefit):在宣傳產品的時候能夠適當的宣傳該軟件與其餘類似軟件或網站有什麼較優的地方,讓用戶體驗並說說感覺,以便參考。
    C(Competitors):以上的步驟完成後,團隊充分了解本身的項目的優缺點,無論是先進入市場仍是後進入市場都將會有必定的優點。
    D(Delivery):作好了項目的改善,團隊應該對本身的軟件作一個比較適應相應羣體的宣傳,讓用戶知道這個產品,知道這個產品的一些好的功能,從而選擇使用。

二、目前市場上有什麼樣的產品了?

  • 除了集大通好像沒有其餘相似的產品了,畢竟是本身學校用的APP,一個就夠了;但不乏其餘學校也有相應的APP產品,因而我就查了一下,發現每一個學校都有他們對應的APP,好比清華大學——AtTsinghua、復旦大學——i復旦、浙江大學——浙江大學等等。還有一些高校用的課程表之類的APP。

三、做爲新的項目經理,這個產品的核心用戶羣是什麼樣的人, 典型用戶長什麼樣?學歷,年齡,專業,愛好,收入,表面需求,潛在需求都是什麼?

(針對學生客戶端)典型用戶——懶癌發做但須要各類充值的學生

核心用戶羣 學歷 年齡 專業 愛好 收入 表面需求 潛在需求
集美大學全體學生 本科 18-23 各個專業 閱讀/運動/遊戲 部分無收入 查課表/充值校園卡/充值網費/查成績等 功能能夠很方便的看到並使用

四、功能:你要設計什麼樣的功能? 爲什麼要作這個功能,而不是其餘功能? 爲何用戶會用你的產品/功能? 你的創新在哪裏? 能夠用 NABCD 分析。

http://www.cnblogs.com/xinz/archive/2010/12/01/1893323.html

(1)你要設計什麼樣的功能?
答:在集大通中,想設計的功能是:快捷方式
(2)爲什麼要作這個功能,而不是其餘功能?
答:快捷方式有利於學生管理本身經常使用的或隨時須要用的功能,方便,同時也是採訪的用戶須要的。好比這個功能能夠將網費充值中的充值直接提取出來,放在本身想放的界面。
(3) 爲何用戶會用你的產品/功能?
答:這個功能比較方便,適合愈來愈「懶」的大學生們。
(4)你的創新在哪裏? 能夠用 NABCD 分析。
答:至少以前的開發團隊沒有作到這個功能而且這個功能也是用戶所需求的。
N:我想設計的功能知足了大部分學生找想用功能的便捷度,沒有快捷功能就要在應用中心找相應的功能。(進入速度慢)
A:而後利用一些連接將想要的功能拖出,先放幾個經常使用的。
B:這個功能節省了時間,節省了流量。
C:這個功能尚未被先前的開發團隊採用過,有競爭市場。
D:將這個功能介紹給身邊的朋友,若是實用,他們就會告訴本身身邊的同窗與好友。

五、若是你有錢能夠招聘 6 我的, 有 4 個月的時間, 你做爲項目經理, 應該如何配置角色 (開發, 測試,美工等等)?

  • 開發3人(我的以爲這個方面比較難,須要分塊進行,再整合)
  • 測試1人(開發人員能夠協助測試)
  • 美工1人
  • 用戶體驗1人(以用戶的角度使用該產品,提出中肯的意見和建議)

六、描述你的團隊在16 週期間每週都要作什麼,才能在第16周如期發佈軟件的改進版本,並取得預想中的成績。

時間 任務
第1~2周 需求分析(進行調研)
第3~4周 系統設計,討論設計細節(界面以及功能)
第5~10周 Alpha階段,初步實現軟件功能
第11~14周 Beta階段,改進軟件功能
第15~16周 軟件試運行(包括修復以前沒有發現的bug以及用戶體驗後改進)
相關文章
相關標籤/搜索