1. 程式人生 > >結對項目原型設計

結對項目原型設計

審核 str 增加 stage 合計 通知 mat 友好 身邊

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

結隊者:3006 梁旖 & 3010 艾曉晗

在《構建之法(鄒欣版)》中,在競爭性需求分析的框架板塊介紹了NABCD模型

? N需求(need),解決用戶的需求;

? A,做法(approach),解決需求的手段;

? B,好處(benefit),產品會給客戶/用戶帶來什麽好處;

? C,競爭(competitors),市場競爭,看清優劣事態;

? D,推廣(delivery),如何把產品交到用戶手中

設計過程

按照本次作業的要求,我們兩人來自不同的課設小組。一開始我們沒有什麽好的想法,也想不出來能有什麽創新點,看了不同版本不同牌子的手機備忘錄,也問了一下周圍同學使用備忘錄的一些習慣,我們開始有了一點思路,在討論過程中,雖然想法不一,但最終殊途同歸,最終完成了作業。

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

N:在日常生活中,備忘錄是對我們管理時間和幫我們記錄重要事情的好東西,但是我們對備忘錄的使用頻率卻不是很高,表現在經常會忘記一些待辦的事務。這其實反應了目前為止,手機上自帶的備忘錄功能還不夠完善也不夠智能,所以我們沒能使用好。這給了我們一個很好的思路就是——要是有一個智能的備忘錄,不需要每次都是我們自己一個一個字地敲上去,甚至團隊中有一個人做了可以提醒全隊的人,效率不是更高嗎?因此我們需要一個更為智能的備忘錄來管理我們的時間和提醒我們待辦事件的時間地點。

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

1. 首先在web端和app之間,我們選擇了後者;因為我們更多的時候是在移動端接收到提醒,我們很少會主動登陸網頁頁面查看。斷網情況下網頁也無法及時推送提醒。

2. 接著我們參考了一些我們自己手機本身已有的備忘錄(針對界面設計)以及目前應用市場上已有的一些備忘錄app(針對功能和用戶反饋),我們簡略地模擬出一些界面和功能。比如登陸、手動添加備忘錄、系統主動識別信息的時間地點事件等主要信息並自動設置提醒等過程。

3. 完善和設計我們的亮點功能,明確各功能優缺點,完善我們的項目

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

技術分享圖片

技術分享圖片

技術分享圖片

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

  • 設計亮點1:信息篩選和自動設置提醒功能。
    針對事件突然到來或者緊急的情況,我們可能在忙其他事情,沒有來得及手動輸入提醒,這時候只要把事件通知復制黏貼到備忘錄app裏,它會自動識別出時間、地點和主要事件等關鍵字,並且自動設置提醒。

技術分享圖片

  • 設計亮點2:互動功能。 在傳統印象裏,備忘錄就是自己一個人的事情,但是有些事件(比如班會、同部門的會議、考試)是和身邊同學一起進行的,要是有人和自己一起使用這個app,並且添加為好友,一個人設置了提醒時可以選擇想要提醒的好友,那麽被“點名”的好友備忘錄裏也會自動添加這一提醒。
  • 設計亮點 3:界面簡潔友好 許多app界面顏色鮮艷多彩,其實不會引起用戶太多的興趣,甚至會讓人視覺疲憊,簡潔友好的界面可以使用戶有更好的體驗

B:改變了原先手動的“碼字備忘”模式,不僅實現了信息提醒智能化,並且通過我們的設計,原本單一的“單槍匹馬完成任務”可以變成和“隊友”一起互相提醒,互相監督。當看到自己的要完成的事情一件一件一件地被完成,也會獲得成就感。增加了交流功能,也可以減少我們設置備忘錄時一些重要信息的錯誤輸入等。

C:這個原型設計如果說存在競爭壓力的話,首先是來自不同對的同學,其次是來自已有的備忘錄軟件和其他類似功能的小程序等。

D:如果老師接納,該方案將作為我們結對項目的下次作業。如果老師不接納,下周我們的結對就將無法繼續編碼本次的內容。如果能夠完成,相比不那麽智能化的傳統備忘錄,只要我們成功推薦給同學們,很快就能收到歡迎。

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

PSP

PSP2.1

Personal Software Process Stages

預估耗時(分鐘)

實際耗時時間

(分鐘)

Planning

計劃

10

30

· Estimate

· 估計這個任務需要多少時間

10

15

Development

開發

655

500

· Analysis

· 需求分析 (包括學習新技術)

30

10

· Design Spec

· 生成設計文檔

30

15

· Design Review

· 設計復審 (和同事審核設計文檔)

10

10

· Coding Standard

· 代碼規範 (為目前的開發制定合適的規範)

5

· Design

· 具體設計

40

· Coding

· 具體編碼

5h*60

· Code Review

· 代碼復審

1h*60

· Test

· 測試(自我測試,修改代碼,提交修改)

3h*60

Reporting

報告

290

· Test Report

· 測試報告+博客

4h*60

· Size Measurement

· 計算工作量

10

· Postmortem & Process Improvement Plan

· 事後總結, 並提出過程改進計劃

40

合計

955

心得

這次和不同組的同學一起結對,感覺收獲很多,只有兩個人一起合作,工作量也會相應地增多。從確定項目,到功能的設計和細化,還要考慮適用性和競爭對手等等,比自己一個人完成一個“XX系統”要難。很感謝“對友”的信任和耐心,合作愉快。

梁旖

技術分享圖片

結對項目原型設計