不放過每一個知識點，尤其是對易混淆的知識點更要花心思理解清楚。下面是小編整理的關於進度安排的計算機四級考點，歡迎閱讀!
軟體開發專案的進度安排可以有兩種考慮方式。
第一種，系統最終交付使用的日期已經確定，軟體開發機構必須在合同規定的時間內安排;
第二種，只確定了大致的年限，最後交付使用的日期由軟體開發機構根據具體情況確定。
後一種考慮能夠對軟體開發任務進行細緻的分析;能夠最好地利用資源，合理地分配工作量，但實際工作中常常遇到第一種情況，問題是軟體管理人員如何在規定的期限內分配人力和安排進度。進度安排的好壞往往影響整個專案的按期完成和使用者的使用，如不能按期完成，使用者就會不滿，而且需向用戶賠償損失。如作為商品，將會失去市場競爭力。進度安排的精確性有時比成本估算更重要。在商品生產的社會中，某種商品的損失往往還可以通過其他商品或分期償還來承擔。而進度拖延的損失是無法彌補的`。下面就軟體開發專案進度安排中的幾個問題進行討論。
1.軟體工作的特殊性
制定軟體進度與其他工程沒有很大的區別，因此使用一般的通用技術和工具即可。但重點要強調的是軟體產品是邏輯產品，這與其他工程不同。因此當幾個人共同完成某項任務時，人與人之間就有一個思想交流問題，稱之為通訊關係。通訊是要付出代價的，不只是要花時間，同時由於通訊中的疏忽常常會使錯誤增加。如一個組有4個軟體工程師，兩兩之間進行通訊聯絡，通訊路徑有6條;對6個軟體工程師，則通訊路徑增加至14條。因此所付的代價就必然會增加，所以工作組的人員不宜太多，一般3—5人為好，目前國外一般採用主程式設計師組的制度。另一點要強調的是軟體工作切忌中間臨時加人，必須在安排進度時就考慮周到。
2.各階段工作量的分配
估算出總的工作量以後，就需要一個可以進行各階段工作量分配的模型。某一階段工作量所佔的百分比必須根據經驗資料確定。這裡要再一次強調，在開發過程中儲存的記錄將增加經驗資料庫存，而且將改善今後估算的準確性。sman提出一種稱作40-20-40的工作量分配規則，即前期工作(計劃、需求分析、概要設計和詳細設計階段)和後期工作(測試階段)各佔40%，編碼階段佔20%。應該強調要重視前期和後期工作。前期工作容易被忽視，主要原因是:管理人員認為不開始編碼工作就算沒有進行，他們不瞭解前期工作的重要性;技術人員往往也急於編碼，認為寫出程式碼任務就算完成了。後期工作也容易被忽視，認為編碼出來就完事了，對測試工作要佔這麼大的工作量沒有思想準備。所以要制定好進度計劃，就要研究軟體工作的規律，前期基礎工作沒做好，將會給後期工作帶來很大困難，往往使工程進度一拖再拖，難以堅持，有的不得不中途夭折。
3.制定開發進度
需要涉及的下一個未知量是開發進度。進度安排是軟體計劃工作中一項最困難的任務，計劃人員要把可用資源與專案工作量協調好;要考慮各項任務之間的相互依賴關係，並且儘可能地平行進行;預見可能出現問題和專案的“細脖子”，並提出處理意見;以及規定進度，評審和應交付的文件。
假設用作變數的開發時間TD按線性變化，而且已經得到了總的開發工作量估算值ED，要求在規定的時間TD內完成，在專案中最好有參加工作的人員平均值M，即M=ED/TD，這將是一個非常有用的資料。遺憾的是在上述算式中，專案的工作量和開發時間不能作為獨立的變數。Brooks定律描述了這種現象的最極端情況:為誤期的軟體專案增加人員將會使其進度更慢。
