美國某大型軟體的開發計劃日程安排 (轉)
ideograph">這是以前從上找到的某(不知道使用真實名稱是否有爭議,暫且稱之為XXX ‘97吧)的開發計劃日程安排,我想它是有可學之處的,就翻譯了過來,希望能有所借鑑,其中某些該軟體技術方面的細節,並不影響對開發計劃的理解,所以沒有翻譯,鑑於本人英文水平有限,可能有錯誤之處。雖然不同的情況開發計劃不同,但該文件對於規範開發是有啟示的。文中字樣“注:”為譯者新增。我無法給出來源,只好貼在原創裡面了
譯者注
:namespace prefix = o ns = "urn:schemas--com::office" />
以下為實際內容
XXX ‘97 開發計劃
戴維於1997年2月
介紹
這個文件為XXX’97開發的日程安排 ,它用於為《開發議案》中的三部分內容服務:XXX’97開發文件和它的用於YY2.0的OLE ,某用於DTP的服務包,和某獨立的。
XXX’97和XXX’97J(遠東版)將被作為可回撥的繪圖部件服務,作為Office’96和Publisher’96之間的資訊載體。
這個日程使用Office系列的宏建立,這些宏可以生成可讀性及強的報表,包括每週的日程進展情況,如果日程可以在網路上使用,就不必進行列印工作。
XXX’97.XLS – 包括建立所有的相關文件部件。
XXX’97J.XLS -包括建立遠東版所有的相關文件部件。將在XXX’97非遠東部分完成後指定三個開發者完成。
在開發階段,日程將在每週更新。每個月,員們必須重新在他們的相關日程上簽名並彙總到戴維處,由戴維統一控制日程計劃安排。
關於本工程的細節問題,請聯絡負責人Ho,他將指導你找到相關可用文件,如:本工程開發規範。
目標日期和階段
本日程的各階段時間的制定主要基於日程安排,雖然它也在很大程度上受其它客戶端的影響:如瀏覽器、YY2.0等。
開發由兩個主要階段組成,第一階段:資訊可以被投遞到它的回撥服務整合環境; 第二階段:其餘程式碼的完成。工程文件的設計也將遵照這些階段進行。
在完成XXX’97後,三個開發者將被立即分配到XXX’97J遠東工程部分。
下面的表格中為預計的重要目標的日期。
表格1:目標日程安排
5/1/96
最終的議案及日程安排結束,第一階段開始 (14 個星期)
7/31/96
第一階段程式碼完成。完善期開始 (4個星期)
8/15/96
第一個可用的程式提交
8/28/96
第二階段開始 (14個星期)
11/27/96
第二階段結束,程式碼完成。
1/20/97
開始XXX’97J版開發,三個開發者將主要完成遠東版釋出和在MIPS平臺的編譯的工作(12個星期)
2/15/97
正式版XXX’97釋出,它包括(… …)
4/15/97
XXX’97J版程式碼完成
6/15/97
正式版XXX’97J釋出
各階段日程細節
每個階段包括開發部分14個星期,緊接著4周的穩定、完善期。最後階段還有4周附加的完善期。
每個開發部分以47天作為一個段,其中有14天的內部完善工作日,6天的病、節假日,和2.5天的程式碼檢察。
下表顯示每個階段有多少天被分配。(注:該演算法是按照每週5天計算的)
表 2: 階段定義
主要階段的開發期 - 70 天
日程安排項 47 天 (67%)
內部完善期 14 天 (20%)
(這個鞏固階段被算在主要階段中是為了鼓勵開發者立刻修復新出現的錯誤,以便程式部件一直保持穩固。)
病假、節假日等 6 天(8.5%)
正常情況下一個階段每個開發者可以有1天病假
在工程中,(注:所處的日期關係,考慮到階段中的法定節假日),第一階段有2個假日,第二階段有3個假日,J版本開發階段有1個假日。
開發者平均每個階段可趕上3或4個假日。
內部完善-程式碼回顧檢察階段 2.5 天(3.5%)
每個階段有2.5天的程式碼檢察,這個數字對於幾個程式設計師來說就顯得多一點。
主要階段的緩衝、鞏固完善期- 20 天。
階段完善、錯誤修正時間一共佔據了以90天為一大階段時間的22%。所有完善、鞏固、緩衝的時間(包括每個階段的14天)佔據工程時間的38%,相對於47天的開發任務日程,有34天的緩衝和鞏固時間。
當XXX’97的測試結束後,這個完善階段才真正的結束。(注:這意味著雖然你有這麼多完善時間,或者說花這麼多時間完善,但是如果沒有透過測試,那麼還不算完)
主要工作項
介紹…
圖1:
…. ….
圖2:
…. ….
開發資源
開發組主要成員:戴維(主要負責人和程式碼劃分)AA(客戶端介面) … … XXX(xxx)
將於某月某日左右從別的任務脫身加入本開發組的成員 M1(… …),M2(… …)
J版的開發將由J1(… …) J2(… …)J3(… …)完成
表<
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-987637/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 迭代型軟體專案開發計劃的編制(轉)
- 軟體開發專案計劃編制過程(轉)
- 用例設計在軟體開發專案計劃中的應用(轉)
- 【大型軟體開發】淺談大型Qt軟體開發(一)開發前的準備——在著手開發之前,我們要做些什麼?QT
- 軟體專案計劃的制定方法(轉)
- 如何讓工作計劃顯示在桌面上面?電腦桌面日程安排軟體
- 軟體工程——軟體計劃軟體工程
- 【大型軟體開發】淺談大型Qt軟體開發(四)動態連結庫的宏衝突問題、COM元件開發的常見問題QT元件
- 劃分軟體開發人員的兩種尺度
- 軟體開發的管理和控制 (轉)
- 物件導向的軟體開發 (轉)物件
- 軟體開發的哲學思考 (轉)
- 論軟體的元件式開發 (轉)元件
- Linux下的軟體開發(轉)Linux
- “安德的遊戲”和軟體開發 (轉)遊戲
- 軟體開發的專案管理(轉)專案管理
- 日本軟體開發的度量取向(轉)
- 軟體開發隨想 (轉)
- 制訂軟體專案計劃的方法與策略(轉)
- 軟體專案計劃編制方針 (轉)
- 怎樣做好軟體專案風險計劃(轉)
- 規劃迭代--及時開發詳細計劃(轉)
- 團軟體的設計與開發
- Qt開發Active控制元件:如何使用ActiveQt Server開發大型軟體的主框架(2)QT控制元件Server框架
- 軟體開發設計文件
- 自上而下的軟體開發和自下而上軟體開發
- 小軟體專案開發的管理 (轉)
- 小軟體專案開發的管理(轉)
- 軟體開發中的專案管理(轉)專案管理
- 軟體開發專案的風險管理(轉)
- 對軟體開發的一點心得體會 (轉)
- vb開發通訊軟體 (轉)
- 歐盟實施新開源計劃 建立成員國“軟體池”(轉)
- 美國國防承包商計劃收購間諜軟體公司NSO
- 從Java談軟體開發前期規劃的重要性Java
- C語言大型軟體設計的物件導向C語言物件
- 軟體開發:app軟體開發,pc端軟體開發,微商城/小程式開發APP
- 行軟體開發中的專案管理 (轉)專案管理