做業五——團隊項目——需求規格說明書

團隊項目總體安排

  • 角色及分工
學號後三位 姓名 角色及分工
221 石偉光 PM:架構設計、服務端開發、項目管理
228 遊炳坤 開發:Android開發,數據庫設計
415 黃少強 開發:Android開發,測試主導
337 林界 UI:UI設計、文檔

概述:
  隊伍依照我的現有的知識積累,以及性格,意願和當前項目的需求。將隊伍中的每一個人分爲一名項目文檔及測試人員,一名主要負責服務端編寫人員,以及兩名客戶端編寫人員。
  分角色的目的不是爲了讓每一個人的工做分得互不干涉。而是出於這樣的考慮:發揮每一個人的優勢和長處,而且在項目的過程當中讓每一個人參與進來,成爲項目的主導的一部分。項目的每一個階段都有很明確的目標和很強的動力。
  當團隊的每一個人都明確本身的價值以後,在項目進行的每一個階段,每一個人都有可能成爲該階段的主導。在這個階段中,主導的這我的應該是處在階段所須要的關鍵角色中的人。成爲主導後,這我的應該明確目標,肯定任務,劃分任務,以及處理過程當中出現的問題。
  當過程細化爲每一個任務時,任務採起認領的形式。對於認領任務的人,每一個人都是本身是這項任務的主導人和負責人,因此對於這項任務,認領該任務的人擁有絕對的權限,能夠向團隊中的任何人尋求幫助和建議,但負責和做決定的,還是他本身。
  每一個階段開始和結束時候都會進行一次會議。結束會議由階段負責人負責,階段負責人總結,隊長進行評價,成員對各自任務總結和體會。造成記錄,而且團隊和每一個人都應該有所收穫。開始會議由隊長組織,進行下一階段的計劃,討論構建過程的框架,確認階段負責人。
  應用worktile團隊協做工具。跟進任務,記錄項目的進展。git

  • 時間規劃
時間 人員 工做及任務
10.17-10.24 石偉光 一、在本地搭建服務端環境(LAMP)並編寫demo完成測試。二、測試現有的騰訊雲服務器,一樣在demo中完成測試。三、學習架構設計,針對本項目進行學習總結。四、組織初步架構搭建。五、獨立完成PHP編碼規範。
黃少強、遊炳坤 一、合做完成Android編碼規範,併發布總結。二、採用eclipse ADT開發工具,完成虛擬機、真機測試,調研適用於用戶人羣版本型號。三、從新學習結對編程,並設想結對過程,在github上面完成結對過程的迭代開發demo及開發測試。四、針對本次項目學習經常使用控件以及自定義控件demo編寫。五、eclipse單元測試學習,並對demo進行簡單的單元測試。
林界 一、組織完成需求規格說明書最終版。並與用戶進行肯定。(教師、負責人)二、瞭解經常使用控件效果,調研主流設計風格。三、學習UI設計,瞭解概念和設計模式。四、針對已有原型,進行UI設計。並與客戶端編碼人員進行可行性探討。對於每一個交互頁面造成原型,以及肯定實現方式。
10.24-10.31 石偉光 一、組織進行對初步架構的討論。並造成完整架構設計。二、學習PHP的mvc開發模式。三、選擇一門輕量級的框架進行demo編寫,並完成測試,造成總結。四、學習項目管理,尋找樣例心得。
黃少強 一、組織編寫測試計劃。二、學習Android上的框架,並完成與sqlite,服務端進行數據交互demo。三、深層次瞭解Android機制。
遊炳坤 一、學習Android上的框架,並完成與sqlite,服務端進行數據交互demo。二、powerdesigner深刻學習。與服務端人員、web合做小組進行數據庫設計討論。三、初步設計數據存放方式與表的造成,基本SQL語句編寫。四、深層次瞭解Android機制。
林界 一、與客戶端編寫人員進行UI改進,造成最後的成果,並組織會議進行討論完善,並進行可行性分析。二、學習如何評估用戶體驗方法,以及如何獲得用戶的真實反饋,並造成總結。
11.7-11.14 石偉光 一、對服務端邏輯進行評估,做出改進計劃。二、總結第一階段衝刺經驗,對下一階段衝刺進行規劃。
黃少強 一、總結測試成果,改進測試計劃。二、總結結對經驗,並對下一段結對進行計劃。三、對上一階段出現的技術難題進行總結,並尋找解決方法。
遊炳坤 一、對數據庫進行評估,提出下一步改進計劃。二、總結結對經驗,並對下一段結對進行計劃。三、對上一階段出現的技術難題進行總結,並尋找解決方法。
林界 一、用戶反饋調查,並造成結果文檔。並列出修改建議給予開發人員。跟進修改計劃。二、制定真實用戶試用計劃流程,獲得用戶真實反饋。
11.14-11.21 石偉光 一、完善服務端內容,並根據修改計劃進行修改。二、推動項目管理,針對上次衝刺的總結進行改進。三、主持每日站立會議。
黃少強、遊炳坤 一、攻克技術性難題,並根據修改計劃進行修改。二、與web合做小組進行進度交流。
林界 一、跟進修改建議。二、學習用戶手冊的編寫。並造成學習總結。三、與web合做小組瞭解web使用方式
11.21-11.28 石偉光 一、總結第二次衝刺過程。二、制定後期維護計劃。三、對正式版本服務端進行完善。
黃少強、遊炳坤 一、完善發佈正式版本。二、制定現場測試方案。三、做出開發總結。
林界 一、編寫併發布用戶手冊。
11.28-12.19 石偉光 一、爲上線、現場演示作準備。二、瞭解並完成軟件著做內容。三、完成項目總結。
黃少強、遊炳坤 一、爲上線、現場演示作準備。二、最後的bug檢查以及壓力測試。三、完成開發總結。
林界 一、修改完善用戶手冊,交付給用戶使用。二、對成果進行評分,做出總結。

需求規格說明書

  • 工做流程github

    1. 團隊開需求分析會議,針對用戶描述的內容提出疑問,基本瞭解app各個角色工做流程。
    2. 經過與用戶交流,解疑。
    3. 將需求規格說明書內容細化爲若干任務,一人主導,以人員主動認領的方式分配任務。
    4. 主導人員回收各方人員的成果,進行審覈提出改正意見,不斷迭代。
    5. 主導人員將最終全部成果彙總爲《需求規格說明書》,並進行適當修改細化。
  • 組員分工
    根據checklist中的內容將任務劃分以下:web

人員 分配任務
221石偉光 功能描述
228遊炳坤 界面原型
415黃少強 用戶場景及驗收驗證標準
337林界 引言及文檔整合統一,類圖及用例圖
  • 組員工做量比例
人員 工做量比例
221石偉光 21%
228遊炳坤 27%
415黃少強 27%
337林界 25%

  其中組長因外出參加比賽,在實際撰寫需求規格說明書時參與量不大,但在前期需求分析會議及肯定原型的工做中完成了前期大量準備工做,爲組員完成後續工做提供便利。故佔21%。
  328及415兩名組員,完成了分配出的大量任務,同時兩人共同協做將功能描述與原型界面整合統一。故兩人分別佔27%。
  337完成類圖及用例圖等圖的工做,同時最終整合文檔,佔25%。sql

附件:《需求規格說明書》

地址:http://pan.baidu.com/s/1c0nuYsS數據庫

相關文章
相關標籤/搜索