（三） 進度安排
軟件開發項目的進度安排可以有兩種考慮方式。第一種，系統最終交付使用的日期已經確定，軟件開發機構必須在合同規定的時間內安排;第二種，只確定了大致的年限，最后交付使用的日期由軟件開發機構根據具體情況確定。后一種考慮能夠對軟件開發任務進行細致的分析;能夠最好地利用資源，合理地分配工作量，但實際工作中常常遇到第一種情況，問題是軟件管理人員如何在規定的期限內分配人力和安排進度。進度安排的好壞往往影響整個項目的按期完成和用戶的使用，如不能按期完成，用戶就會不滿，而且需向用戶賠償損失。如作為商品，將會失去市場競爭力。進度安排的精確性有時比成本估算更重要。在商品生產的社會中，某種商品的損失往往還可以通過其他商品或分期償還來承擔。而進度拖延的損失是無法彌補的。下面就軟件開發項目進度安排中的幾個問題進行討論。
1.軟件工作的特殊性
制定軟件進度與其他工程沒有很大的區別，因此使用一般的通用技術和工具即可。但重點要強調的是軟件產品是邏輯產品，這與其他工程不同。因此當幾個人共同完成某項任務時，人與人之間就有一個思想交流問題，稱之為通信關系。通信是要付出代價的，不只是要花時間，同時由于通信中的疏忽常常會使錯誤增加。如一個組有4個軟件工程師，兩兩之間進行通信聯系，通信路徑有6條;對6個軟件工程師，則通信路徑增加至14條。因此所付的代價就必然會增加，所以工作組的人員不宜太多，一般3—5人為好，目前國外一般采用主程序員組的制度。另一點要強調的是軟件工作切忌中間臨時加人，必須在安排進度時就考慮周到。
2.各階段工作量的分配
估算出總的工作量以后，就需要一個可以進行各階段工作量分配的模型。某一階段工作量所占的百分比必須根據經驗數據確定。這里要再一次強調，在開發過程中保存的記錄將增加經驗數據庫存，而且將改善今后估算的準確性。R.S.Pressman提出一種稱作40-20-40的工作量分配規則，即前期工作（計劃、需求分析、概要設計和詳細設計階段）和后期工作（測試階段）各占40%，編碼階段占20%。應該強調要重視前期和后期工作。前期工作容易被忽視，主要原因是:管理人員認為不開始編碼工作就算沒有進行，他們不了解前期工作的重要性;技術人員往往也急于編碼，認為寫出代碼任務就算完成了。后期工作也容易被忽視，認為編碼出來就完事了，對測試工作要占這么大的工作量沒有思想準備。所以要制定好進度計劃，就要研究軟件工作的規律，前期基礎工作沒做好，將會給后期工作帶來很大困難，往往使工程進度一拖再拖，難以堅持，有的不得不中途夭折。
3.制定開發進度
需要涉及的下一個未知量是開發進度。進度安排是軟件計劃工作中一項最困難的任務，計劃人員要把可用資源與項目工作量協調好;要考慮各項任務之間的相互依賴關系，并且盡可能地平行進行;預見可能出現問題和項目的“細脖子”，并提出處理意見;以及規定進度，評審和應交付的文檔。
假設用作變量的開發時間TD按線性變化，而且已經得到了總的開發工作量估算值ED，要求在規定的時間TD內完成，在項目中最好有參加工作的人員平均值M，即M=ED/TD，這將是一個非常有用的數據。遺憾的是在上述算式中，項目的工作量和開發時間不能作為獨立的變量。Brooks定律描述了這種現象的最極端情況:為誤期的軟件項目增加人員將會使其進度更慢。
（四） 軟件開發組織
有多少個軟件開發機構，幾乎也就有多少人員的組織機構。不管這些組織機構是好或壞，一般是不可能輕易改變的。盡管組織機構的改變不屬于軟件計劃人員的職責范圍內的事。不過，在一個新的軟件項目中直接涉及人員的組織問題卻是可以，也應該在軟件計劃階段加以認真考慮的。對于一個需要n個人工作k年的軟件項目，如何使用人員資源，可能有以下幾種選擇:
（1）把m項不同功能的軟件分配給n個人去完成，他們之間無需多少合作，主要協調的任務由一位軟件主管人員來負責。這樣，軟件主管可能同時需要管理多個不同項目;
（2）把m項不同功能的軟件分配給n個人去完成（m≤n），這樣可能就要建立一些非正式的小組，并指定小組負責人，而小組之間的協調工作則由軟件主管負責;
（3）n個人被組成k個小組，每個小組分配一個或多個功能，并有具體組織，協調工作由小組和軟件主管共同進行。雖然對上述每一種方案都可能說出贊成或反對的理由。然而，有越來越多的證據表明，第三種方案，即正式的小組是最好最有效的。正式的小組的方案來源于“主程序員小組”的概念。它是由Harlan Mills首先提出，并由Baker進一步闡述的。小組的核心由一位高級工程師（主程序員）、2至5位技術人員和一位后備工程師組成。主程序員負責小組的所有技術活動的計劃、協調和評審工作;技術人員負責項目的具體分析和開發;后備工程師則支持主程序員工作，必要時能代替主程序員工作，以便使項目能繼續進行，而使損失最小。主程序員小組有一名或多名專家（如數據庫設計或通信方面專家）、數名輔助人員（如秘書和打字員）和一名資料員參加工作。資料員同時為多個小組工作，具體完成下列工作:
（1）保存和管理所有軟件配置（包括各種文檔、源程序清單、數據和各種磁介質資料）;
（2）協助收集和整理軟件生產率數據;
（3）對可修改的模塊分類及編寫索引;
（4）協助小組進行調查、評價和準備文檔等。主程序員小組的主要目標是發揮集體力量。因引，小組要培養從“全局”觀點出發進行程序設計，把“我的”程序變為“我們的”程序;幫助消除軟件的個人屬性，小組可以鼓勵更加徹底的評審，并在共同的工作中增加學習，從而改善軟件質量。在本章的第3節中，我們曾討論過人們在工作中有一個需要交流的問題。當采用主程序員小組這種形式時，必須會增加交換意見所需的工作量，這似乎不利于提高軟件開發的生產率。然而，不管怎樣組織，在軟件整個開發過程的總工作量的相當一部分總是要花費在交換意見方面（如計劃、分析和評審等）。雖然，小組的形式增加了內部交換意見的工作量，但是這是有組織的評審，必將減少在設計和編碼中引入的錯誤。結果是測試工作量減少了，從而使小組有更高的生產率。當然，小組中技術人員的數量不宜過多，一般建議2～5人為好。（三） 進度安排
軟件開發項目的進度安排可以有兩種考慮方式。第一種，系統最終交付使用的日期已經確定，軟件開發機構必須在合同規定的時間內安排;第二種，只確定了大致的年限，最后交付使用的日期由軟件開發機構根據具體情況確定。后一種考慮能夠對軟件開發任務進行細致的分析;能夠最好地利用資源，合理地分配工作量，但實際工作中常常遇到第一種情況，問題是軟件管理人員如何在規定的期限內分配人力和安排進度。進度安排的好壞往往影響整個項目的按期完成和用戶的使用，如不能按期完成，用戶就會不滿，而且需向用戶賠償損失。如作為商品，將會失去市場競爭力。進度安排的精確性有時比成本估算更重要。在商品生產的社會中，某種商品的損失往往還可以通過其他商品或分期償還來承擔。而進度拖延的損失是無法彌補的。下面就軟件開發項目進度安排中的幾個問題進行討論。
1.軟件工作的特殊性
制定軟件進度與其他工程沒有很大的區別，因此使用一般的通用技術和工具即可。但重點要強調的是軟件產品是邏輯產品，這與其他工程不同。因此當幾個人共同完成某項任務時，人與人之間就有一個思想交流問題，稱之為通信關系。通信是要付出代價的，不只是要花時間，同時由于通信中的疏忽常常會使錯誤增加。如一個組有4個軟件工程師，兩兩之間進行通信聯系，通信路徑有6條;對6個軟件工程師，則通信路徑增加至14條。因此所付的代價就必然會增加，所以工作組的人員不宜太多，一般3—5人為好，目前國外一般采用主程序員組的制度。另一點要強調的是軟件工作切忌中間臨時加人，必須在安排進度時就考慮周到。
2.各階段工作量的分配
估算出總的工作量以后，就需要一個可以進行各階段工作量分配的模型。某一階段工作量所占的百分比必須根據經驗數據確定。這里要再一次強調，在開發過程中保存的記錄將增加經驗數據庫存，而且將改善今后估算的準確性。R.S.Pressman提出一種稱作40-20-40的工作量分配規則，即前期工作（計劃、需求分析、概要設計和詳細設計階段）和后期工作（測試階段）各占40%，編碼階段占20%。應該強調要重視前期和后期工作。前期工作容易被忽視，主要原因是:管理人員認為不開始編碼工作就算沒有進行，他們不了解前期工作的重要性;技術人員往往也急于編碼，認為寫出代碼任務就算完成了。后期工作也容易被忽視，認為編碼出來就完事了，對測試工作要占這么大的工作量沒有思想準備。所以要制定好進度計劃，就要研究軟件工作的規律，前期基礎工作沒做好，將會給后期工作帶來很大困難，往往使工程進度一拖再拖，難以堅持，有的不得不中途夭折。
3.制定開發進度
需要涉及的下一個未知量是開發進度。進度安排是軟件計劃工作中一項最困難的任務，計劃人員要把可用資源與項目工作量協調好;要考慮各項任務之間的相互依賴關系，并且盡可能地平行進行;預見可能出現問題和項目的“細脖子”，并提出處理意見;以及規定進度，評審和應交付的文檔。
假設用作變量的開發時間TD按線性變化，而且已經得到了總的開發工作量估算值ED，要求在規定的時間TD內完成，在項目中最好有參加工作的人員平均值M，即M=ED/TD，這將是一個非常有用的數據。遺憾的是在上述算式中，項目的工作量和開發時間不能作為獨立的變量。Brooks定律描述了這種現象的最極端情況:為誤期的軟件項目增加人員將會使其進度更慢。
（四） 軟件開發組織
有多少個軟件開發機構，幾乎也就有多少人員的組織機構。不管這些組織機構是好或壞，一般是不可能輕易改變的。盡管組織機構的改變不屬于軟件計劃人員的職責范圍內的事。不過，在一個新的軟件項目中直接涉及人員的組織問題卻是可以，也應該在軟件計劃階段加以認真考慮的。對于一個需要n個人工作k年的軟件項目，如何使用人員資源，可能有以下幾種選擇:
（1）把m項不同功能的軟件分配給n個人去完成，他們之間無需多少合作，主要協調的任務由一位軟件主管人員來負責。這樣，軟件主管可能同時需要管理多個不同項目;
（2）把m項不同功能的軟件分配給n個人去完成（m≤n），這樣可能就要建立一些非正式的小組，并指定小組負責人，而小組之間的協調工作則由軟件主管負責;
（3）n個人被組成k個小組，每個小組分配一個或多個功能，并有具體組織，協調工作由小組和軟件主管共同進行。雖然對上述每一種方案都可能說出贊成或反對的理由。然而，有越來越多的證據表明，第三種方案，即正式的小組是最好最有效的。正式的小組的方案來源于“主程序員小組”的概念。它是由Harlan Mills首先提出，并由Baker進一步闡述的。小組的核心由一位高級工程師（主程序員）、2至5位技術人員和一位后備工程師組成。主程序員負責小組的所有技術活動的計劃、協調和評審工作;技術人員負責項目的具體分析和開發;后備工程師則支持主程序員工作，必要時能代替主程序員工作，以便使項目能繼續進行，而使損失最小。主程序員小組有一名或多名專家（如數據庫設計或通信方面專家）、數名輔助人員（如秘書和打字員）和一名資料員參加工作。資料員同時為多個小組工作，具體完成下列工作:
（1）保存和管理所有軟件配置（包括各種文檔、源程序清單、數據和各種磁介質資料）;
（2）協助收集和整理軟件生產率數據;
（3）對可修改的模塊分類及編寫索引;
（4）協助小組進行調查、評價和準備文檔等。主程序員小組的主要目標是發揮集體力量。因引，小組要培養從“全局”觀點出發進行程序設計，把“我的”程序變為“我們的”程序;幫助消除軟件的個人屬性，小組可以鼓勵更加徹底的評審，并在共同的工作中增加學習，從而改善軟件質量。在本章的第3節中，我們曾討論過人們在工作中有一個需要交流的問題。當采用主程序員小組這種形式時，必須會增加交換意見所需的工作量，這似乎不利于提高軟件開發的生產率。然而，不管怎樣組織，在軟件整個開發過程的總工作量的相當一部分總是要花費在交換意見方面（如計劃、分析和評審等）。雖然，小組的形式增加了內部交換意見的工作量，但是這是有組織的評審，必將減少在設計和編碼中引入的錯誤。結果是測試工作量減少了，從而使小組有更高的生產率。當然，小組中技術人員的數量不宜過多，一般建議2～5人為好。
希望與更多計算機等級考試的網友交流，請進入計算機等級考試論壇
更多信息請訪問：考試吧計算機等級考試欄目
