天天看點

結對項目之需求分析與原型設計

結對項目之需求分析與原型設計

結對者:031402509胡澤善;031402524王智強

使用工具:AxureRp 8.0

本次作業PDF文檔

在在《建構之法》的第八章中,介紹了NABCD模型,

NABCD模型(p154~p157):

目的是:在競争性地環境中做實用并且創新的項目;

而具體的解釋如下

  • N需求(need),解決使用者的需求;
  • A,做法(approach),解決需求的手段;
  • B,好處(benefit),産品會給客戶/使用者帶來什麼好處;
  • C,競争(competitors),市場競争,看清優劣事态;
  • D,推廣(delivery),如何把産品交到使用者手中;

結對設計過程

按照本次作業的要求,我們兩人來自不同的課設小組,我們的結對是比較主動和積極的,在本次作業釋出的第三天,我們就互相聯系,約定結對,在規定的時間内,共同合作,完成本次作業。下面是我們在結對原型設計中的照片記錄:

結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計

首先,我在此先用NABCD模型簡要分析一下我們兩人的設計過程:

N:在第二次作業的部落格中,描述了目前畢業生選擇導師系統給使用者/客戶帶來的困擾,以及介紹了在目前選導師過程中人工配置設定遵循的五大規則(詳細請見部落格)。目前的 選擇和配置設定大學畢設導師的流程複雜繁瑣不透明,是以,使用者希望我們設計出一種新的畢設選導師的原型系統,讓選擇和配置設定導師的過程能夠資訊化起來,讓師生之間可以雙向選擇。

A:明白客戶需求之後,我和我的“對友”便開始了分析和讨論如何解決問題、滿足需求的方法:

1. 首先在web端和app之間,我們選擇了後者;

2. 然後,我們參考以往使用過的多個類似的帶選擇性的軟體或者網頁,結合大二選專業導師的經曆,總結并粗略模拟出整個選擇和配置設定的過程;這其中主要就分為導師與同學的互相了解以及學生先選擇導師,導師再挑選學生,最後無法比對的人工确定。

3. 确定整個軟體的設計核心,然後完善這個軟體(包括登入,學生首頁,老師首頁,背景管理等)接下來就是将這個過程通過原型設計工具AxureRp展示出來;

4. 對模型做修改,不斷完善。(完)

結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計
結對項目之需求分析與原型設計

此處我們采用的做法有以下的亮點:

  • 設計亮點1:标簽選擇。針對部落格中所述的,在現狀中,每個老師對應期望的學生數不同,且學生不太了解老師的課題選擇和研究方向的問題,我們在已有的學生績點這一名額的基礎上,又設定了第二個用于學生和老師之間互相了解、促進選擇的名額,那就是标簽。通過學生所選标簽和導師研究領域的交集,算出學生與導師之間的比對度,并在簡介頁面中以星級的形象形式顯示,供雙方參考!
  • 設計亮點2:互動增多。互動可以更好地增進彼此的了解程度,這一點我們在大二選專業導師的時候深有體會,出于這麼目的,我們在軟體中設計了問題調查(老師考察學生,幫助老師選擇)、公共讨論區(某老師回答,所有學生可見),私信(學生老師互動)。這裡面既滿足了老師了解學生,學生了解老師又滿足了雙方互相私人交流的管道。

B:改變了原先手動的人工配置設定模式,不僅實作了資源資訊化,并且通過我們的設計,使得學生對于老師的課題選擇和研究方向有了比較全面地了解,老師不僅可以查閱學生的個人履歷,學習績點,而且還能通過私信或者讨論區回複的新式,和學生之間有所交流;标簽的設計使得選擇過程變得不再盲目。

C:這個原型設計如果說存在競争壓力的話,那應該是來自不同對的同學,在同一個命題的情況下,不同對的同學之間以客戶在評論中所表現出來的滿意度作為競争的名額,滿意度最終以本次作業的考核成績這一形式呈現。

D:就像部落格中說的那樣,如果客戶接納,該方案将作為我們結對項目的第三次作業。如果客戶不接納,下周我們的結對就将無法繼續編碼本次的内容,将完成老師命題的作業。如果能夠完成,相比不人性化的傳統選擇導師方式,隻要我們成功推薦給學校使用并讓同學們和導師了解,很快就能收到歡迎。

效能分析和PSP

在《建構之法》的第二章中,有詳細講解了效能分析和psp,在此,我簡單概括如下:

其中效能分析(P29~P34):

  • 效能分析的對象是:程式;
  • 效能分析的目标是:降低程式複雜度。
  • vsts會提供友善的效能分析工具,使得設計者很快地找出程式的效能瓶頸,便于改 程序式,改程序式的流程為“效能測試,分析,改進,再效能測試”。

此處由于我們的産品原型并沒有實際的代碼和成品,無法進行真正的效能分析。但是我們可以預測在我們的産品中最有可能出現瓶頸的是對學校的教師簡介、學生簡介的調取以及對軟體操作的儲存。因為學校的服務并不僅僅是供我們使用,從平時打開教務處個人詳情的速度上看,資料的傳輸速率很有可能成為我們軟體的瓶頸。對此我們可以考慮單獨架設伺服器。

另外有PSP(P34~P37):

  • 即個人軟體開發流程,
  • 對象是:軟體工程師
  • 目标是:記錄工程師如何實作需求的效率。
  • Psp有很多種版本,在書中介紹了psp2.1版本的軟體工程師的任務清單,psp包括計劃,開發,報告三個部分。

同樣,我們的項目目前處于原型階段,無法提供諸如開發、記錄用時的具體資訊,但是我們可以完成的是對于項目用時的估計。

  • APP部分
  • 登陸子產品
  • 标簽選擇子產品
  • 教師首頁
  • 學生首頁
  • 教師詳情頁
  • 學生詳情頁
  • 管理子產品
  • 私信子產品

預計共一個半月

  • 伺服器部分
  • 資料庫的搭建
  • 使用者資訊錄入(考慮到使用者固定,無需注冊)
  • 讨論區服務
  • 學生及老師初始簡介的導入
  • 私信服務
  • 使用者資訊的記錄及修改服務(包括标簽等)

預計共一個月