淘座座軟件項目計劃書

 

 

 

 

1 概述

1.1 項目概述 

項目的目標是開發一套尋找未使用中教室的系統，同時組員們得到系統的軟件工程項目訓練，發佈的產品是軟件的原型、技術文檔等，主要工做是需求分析、系統分析、原型設計。關鍵里程碑分別是需求分析說明書的發佈和系統模型的交付，項目所需資源爲我的開發工具，進度大約爲5周。

1.2項目交付的產品

交付日期2019年11月22日，主要交付物有：淘座座軟件原型、技術文檔包（包括需求分析報告、軟件說明書、項目總結文檔等）

1.3 SPMP的演化

SPMP於第十一週經由團隊分析—>專人撰寫—>討論整合三步造成初稿，由隊長上傳至團隊羣文件，由隊長負責維護。

第十一週之後根據項目的進展能夠對其進行修改須要有隊員提出修改意見，在全體會議上討論經過，並由隊長將修改稿上傳至團隊羣文件。其他隊員經過羣內下載同步得到更新稿。

1.4參考資料

《構造之法-現代軟件工程》，鄒欣，中國工信出版集團

1.5 定義、縮寫詞以及簡寫

   SPMP:軟件項目管理計劃

   UML統一建模語言(Unified Modeling Language，UML)

2 項目組織 

2.1 外部支持 

組織	聯繫人	聯繫方式
指導老師	彭馨儀	502914563@qq.com

 

2.2 內部組織結構 

業餘劇團模式，每一個人在團隊中遵從隊長的指導和安排。挑選本身擅長的以及遵從隊長安排的去完成團隊任務，能夠更好的使一個新組建的團隊融合到一塊兒。增長團隊的默契程度以及增進團隊的工做效率。也能讓團隊成員在業餘玩票、培訓的環境中，每一個人均可以嘗試不一樣角色，你們能夠比較平等地討論。

2.3 角色與職責劃分 

歷次會議記錄員：負責每次會議內容整理與內容傳達

負責人員：高金庫、許爽、顧雪微、彭星、趙鵬、陶一鳴

需求調查人員：負責對目標人羣進行軟件需求調查和用戶反饋

負責人員：許爽、彭星

需求分析人員：整理需求分析並以撰寫需求分析分析文檔

負責人員：孫帥羣、闞宇航

效果圖設計員：負責產品的效果圖設計

負責人員：張博涵、趙迎港

原型設計人員：負責軟件原型的製做

負責人員：孫帥羣、顧雪微、高金庫、闞宇航

總結人員：負責最後的收尾工做並撰寫總結文檔

負責人員：陶一鳴

3 管理過程 

3.1 項目啓動計劃 

每位組員既是積極的建言者，又是負責的合做者。決策應在充分的討論基礎上作出，並被及時有效的執行。按時按量完成項目的基本功能，按時發佈產品模型，遵循規範的項目運做標準，文檔嚴謹完整。產品要界面友好易上手，能很好的提供未使用教室的信息。開發軟件過程當中要注重團隊建設，成員分工合理，合做默契，氣氛融洽。項目設計和開發商要有創新，更好的吸引用戶。

 

3.2 工做計劃 

第9周~第10周：進行需求調查並完成需求分析說明書、討論軟件項目計劃書

第10周~第11周：完成軟件項目規劃書、進行軟件效果圖設計

第11周~第12周：完成軟件效果圖、進行軟件原型設計

第12周：完成軟件原型交付並撰寫總結文檔

3.3 控制計劃 

各開發過程負責人以周爲單位記錄工做進展，造成電子文檔報告，上傳至團體羣文件。負責人在每週項目例會做口頭總結，團隊會議審覈經過給出意見，報告修改後上傳至團體羣文件。各風險負責人密切監控風險狀態，按期提交風險報告。必要時將突發狀況經過羣發通知全部隊員，並由隊員長作出臨時處理決定。每週例會上團隊討論造成一致意見後即爲經過，相關負責人針對改進意見開展下一週工做，團隊會議持續評估其成效。每一項目階段結束以前（里程碑先後），組織一次階段評審會，評估整個階段的工做效率和成果質量。

3.4 風險管理計劃 

 

風險	標題	可能性	影響	優先級	規避或減輕策略	負責人	預約完成日期
1	開發技術不成熟	80%	災難的	高	提早制定好學習計劃； 下降設計難度	全體人員	第11周
2	考研課程	100%	嚴重的	中	適量少給她分配任務； 開會討論錯開上課時間	闞宇航	第12周
3	考公務員	100%	嚴重的	高	適量少給他分配任務； 開會討論錯開上課時間	陶一鳴	第12周
4	備考四六級	100%	嚴重的	高	適量少給他們分配任務； 分配的任務儘可能能集中處理； 開會討論錯開上課時間	陶一鳴 張博涵 趙迎港 趙鵬 闞宇航 彭星 許爽 顧雪微	第12周
5	需求變動頻繁	50%	嚴重的	中	需求制定充分預見將來； 多於老師討論； 設計方案留有變動餘地	孫帥羣	第12周
6	缺少設計人才	80%	嚴重的	高	組員深刻學習相關知識； 尋求外援幫助	全體人員	第12周
7	缺乏軟件工程經驗	80%	嚴重的	中	組員深刻學習相關知識； 多於老師討論；	全體人員	第12周

風險的詳細描述以下：

風險一：開發技術不熟練

沒有隊員能熟練運用JAVA語言編出程序，僅限於學過，可能致使軟件邏輯有問題。

風險二：考研課程

隊員闞宇航常常須要參加考研課程，在任務分配上有必定的困難。

風險三：考公務員

隊員陶一鳴天天都須要刷申論、形策，準備公務員考試又要完成任務，會致使任務進度變慢。

風險四：備考四六級

由於明年四六級考試會有變化，可能會變難，因此絕大部分隊員準備今年報考。因十二月十四號考試 臨近，刷題、背單詞的力度都加大了很多，會致使總體進度緩慢。

風險五：需求變動頻繁

在設計開發過程當中可能發現原有需求不容易轉化爲設計稿，在測試體驗過程當中可能發現需求有來自現 實的不可抗力因素影響，這都會帶來需求的從新變動。這兩種狀況，尤爲後一種要儘可能避免，以避免帶 來重複開發的浪費。

風險六：缺乏UI設計人員

隊內隊員專科專業大部分與軟件設計無關，有兩位隊員爲圖形圖像專業，可是沒有UI設計經驗。

風險七：缺乏軟件工程經驗

隊內人員都沒有軟件開發經驗，可能會致使大量無用功，或某些工程錯誤。

3.5 項目收尾計劃

在模型設計階段結束後，開發人員之間會進行原型測試，減小邏輯上的錯誤。

最終交付淘座系統軟件模型。

4 計劃過程

4.1 過程模型

應用瀑布模型，軟件開發的各項活動嚴格按照線性的方式進行，當前活動接受上一活動的工做結果，實施完成所需的工做內容。當前活動的工做結果須要進行驗證，若是驗證經過，則該結果做爲下一項活動的輸入，繼續進行下一項活動，不然返回進行修改。所以，這種模型強調文檔的做用，並要求每一個階段都有仔細驗證。 

4.2 方法和技術

本小組的團隊組織結構爲主軟件工程組織結構；利用ps技術製造效果圖；利用原型設計工具設計軟件原型；

4.3 工具

我的PC，筆記本

5 支持過程

5.1 依賴關係

1） 組織團隊是完成軟件項目的前提，明確分工負責；

2） 配置管理貫穿於整個軟件開發和測試過程；

3） 需求分析是軟件項目進入開發階段的重要標誌；

4） 系統設計是基於需求分析的基礎上，又是模型設計的原理依據；

5） 原型測試是該項目開發進展的重要過程；

6） 交付階段是軟件得到用戶的承認，是軟件開發結束的標誌。

5.2 資源需求

人員：小組軟件項目開發成員、用戶

支持軟件：Office、Ps

計算機硬件：筆記本等

辦公室：學院實驗室和宿舍

實驗設備：我的 PC機、筆記本

項目資源維護需求的數目和類型：10臺我的筆記本電腦

5.3 預算和資源分配

預算：本次軟件開發沒有涉及到任何經濟方面的預算

資源分配：各自使用各自的機器。