本文用於記錄軟件工程學習筆記，包含多個學習課程，目前處於每日更新狀態。
如果前面的筆記包含後面的課程內容，那麼後面的筆記將不會重複記錄。
預計包含：
軟件工程——劉強（目前處於）
傳統軟件工程—— 孫豔春
軟件工程專業導論——徐曉飛
軟件服務工程導論——徐曉飛
軟件構造——李勁華
DevOps——榮國平等

1. 軟件工程——劉強

學堂在線地址

初識軟件工程

1.1 軟件的本質特性

定義
軟件 = 程序 + 數據 + 文檔
程序：計算機可以接受的一系列指令，運行時可以提供所要求的功能和性能。   數據：使得程序能夠適當地操作信息的數據結構。
文檔：描述程序的研製過程、方法和使用的圖文資料

軟件文檔非常的重要，然而初學者往往不重視。

本質特性

複雜性
一致性
可變性
不可見性

複雜性
一致性
1. 軟件必須依附一定的運行環境
2. 軟件必須遵循一定的慣例並適應已有的技術和系統
3. 軟件需要隨接口不同而改變，隨時間推移而變化
可變性
1. 軟件能夠隨着版本更新不斷變化
2. 然而，不斷地修改可能導致軟件的退化，從而結束其生命週期
不可見性
1. 軟件是看不見摸不着的邏輯實體
2. 源代碼並不是軟件本身
3. 軟件以機器碼運行，但開發人員看不見機器碼執行過程

軟件所具有的複雜性、一致性、可變性、不可見性等特性，使得軟件開發過程變得難以控制，開發團隊如同在焦油坑中掙扎的巨獸

1.2 軟件工程歷史

軟件開發面臨的挑戰

軟件工程發展歷史概括如下：
史前時代 --> 瀑布流 --> 面向對象 --> 敏捷開發

1.3 軟件工程基本概念

工程
1. 大規模的設計與建造
2. 複雜問題與目標分解
3. 團隊協作與過程控制
軟件工程
1. 將系統性的、規範化的、可定量的方法應用於軟件的開發、運行和維護，即工程化應用到軟件上
2. 對1中所述方法的研究
3. 要素
軟件工程過程：從用戶需求 --> 軟件開發活動 —> 用戶滿意的產品
1. 軟件開發活動
2. 軟件開發管理
  軟件項目管理計劃、軟件配置管理計劃、軟件質量保證計劃、評審記錄……
軟件工程方法（從大到小）
1. 面向服務：在應用表現層次上將軟件構件化，即應用業務過程由服務組成，而服務由構件組裝而成。
2. 面向構件：尋求比類的粒度更大的且易於複用的構件，期望實現軟件的再工程。
3. 面向對象：以類爲基本程序單元，對象是類的實例化，對象之間以消息傳遞爲基本手段。
4. 面向過程：以算法作爲基本構造單元，強調自頂向下的功能分解，將功能和數據進行一定程度的分離。

SASD：SA結構化分析，SA結構化設計，（SP結構化編程）
OOD：Object-Oriented Design，面向對象設計時的一箇中間環節，目標是解決程序內部各部分的依賴關係。
UML：面向對象統一建模語言
OMT：對象建模技術
J2EE：企業級分佈式應用解決方案
DCOM：分佈式組件對象模型,分佈式組件對象模式，是一系列微軟的概念和應用接口，通過這些接口，客戶端程序對象能夠請求來自網絡中另一臺計算機上的服務器程序對象
CORBA：Common ObjectRequest Broker Architecture公共對象請求代理體系結構；爲解決分佈式處理環境(DCE)中，硬件和軟件系統的互連而提出的一種解決方案。
HTTP：是一個簡單的請求-響應協議，它通常運行在TCP之上。
XML：結構化的、可擴展標記語言
OWL：網絡本體語言(Web ontology language,OWL)是語義網技術的一個重要組成部分,適合於對複雜的數據進行語義描述和建模.在軟件系統的開發過程中通常會產生大量結構複雜、語義豐富的數據,而建立一個靈活的語義模型是對各類軟件工程數據進行統一管理的基礎。
webServer三要素：

UDDI：是一種用於描述、發現、集成Web Service的技術（規範），它是Web Service協議棧的一個重要部分。通過UDDI，企業可以根據自己的需要動態查找並使用Web服務，也可以將自己的Web服務動態地發佈到UDDI註冊中心，供其他用戶使用。
SOAP：簡單對象訪問協議是交換數據的一種協議規範，是一種輕量的、簡單的、基於XML（標準通用標記語言下的一個子集）的協議，它被設計成在WEB上交換結構化的和固化的信息。
WSDL：Web服務描述語言，Web Services Description Language,是爲描述Web服務發佈的XML格式。

軟件工程工具
軟件開發基本策略
1. 軟件複用
  構造一個新的系統不必從零做起，直接複用已有的構件進行組裝
  構件是經過反覆使用驗證的，由其組成的新系統具有較高的質量
  複用庫函數、庫類、模板、設計模式、組件、框架等。
2. 分而治之
  將一個複雜的問題分解成若干個簡單的問題，然後逐個解決
  來源於人們生活與工作的經驗，完全適合於技術領域
3. 逐步演進
  軟件開發是自底向上逐步有序的生長過程
  小步快跑：每走完一步再調整併爲下一步確定方向，直到終點
  軟件開發應該遵循軟件的客觀規律，不斷進行迭代式增量開發，最終交付符合客戶價值的產品。
4. 優化折中
  優化：優化軟件的各個質量特性，如運行速度、資源利用、用戶體驗
  折中：通過協調各個質量特性，實現整體質量的最優
軟件工程學科發展

1.4 軟件質量實現

軟件質量可分爲功能質量，結構質量，過程質量

正確的軟件：爲用戶創建利潤、減少成本
軟件運行正確：沒有或很少缺陷、可擴展、高性能、高易用

軟件質量模型（ISO9126）

軟件質量不是被測量出來的，而是在開發過程中逐步構建出來的；
但未經測試的也不可能開發出高質量軟件；
質量是開發過程的問題，測試是開發過程不可或缺的環節。

軟件的質量並非越高越好，絕大部分都是商用，應當平衡好成本、質量、效率之間的關係。

編寫高質量代碼

2.1 編碼過程與規範

軟件編程是一個複雜而迭代的過程，它不僅僅是編寫代碼，還應該包括代碼審查、單元測試、代碼優化、集成調試等一系列工作。

軟件編碼規範是與特定語言相關的描寫如何編寫代碼的規則集合。

現實
- 軟件全生命週期的 70% 成本是維護
- 軟件在其生命週期中很少由原編寫人員進行維護
目的
- 提高編碼質量，避免不必要的程序錯誤
- 增強程序代碼的可讀性、可重用性和可移植性

不同的的編程語言都會有一些比較有名的規範書。本人主學Java，這裏推薦一下阿里巴巴Java開發手冊；此外，如果你用IDEA，有專用的插件能夠實時掃描代碼規範，具體請自行百度

大家都遵循同一個代碼規範，能夠提高協同開發效率，降低維護成本。
此外，有很多規範能夠減少前期開發給後期挖的坑。

2.2 良好的編程實踐

可以通過看、問、練，逐漸提高實踐能力。
軟件開發的工程思維：分析問題，分解大問題爲小問題；解決小問題，合成過程，直至得到解決方案（分而治之）；

高質量的設計：

模塊化設計
面向對象編程
錯誤和異常處理

模塊化設計

常見的模塊包括：函數、類、模塊、包
模塊化常見的問題就是：循環依賴，A依賴B，B依賴C，C依賴A；一定要避免這種問題。

2.3 代碼靜態檢查

代碼審查（Code Review）是一種用來確認方案設計和代碼實現的質量保證機制，它通過閱讀代碼來檢查源代碼與編碼規範的符合性以及代碼的質量。

代碼審查的作用

檢查設計的合理性
互爲 Backup （備份）
分享知識、設計、技術
增加代碼可讀性
處理代碼中的“地雷區”

缺陷檢查表

分析工具：
阿里巴巴Java開發插件也有靜態檢查功能，也可參考以下工具。

2.4 代碼性能分析

一些準則：

滿足正確性、可靠性、健壯性、可讀性
全局效率爲主，局部效率爲輔
優化效率時，應當先找出限制效率的瓶頸
時間和空間效率往往對立，先明確優化目標
從一開始就應該考慮程序性能，而不是等到開發結束後進行調整
認真選擇測試數據
永遠不要再沒有進行前後性能評估的時候就嘗試優化
掌握不同內置結構的迭代操作速度
從算法入手

常見算法時間複雜度：
O(1) ==> O(lg n) ==> O(n lg n) ==> O(n^2) ==> O(n^3) ==> O(n^k) ==> O(k^n) ==> O(n!)

2.5 結對編程

結對編程是由兩名程序員在同一臺電腦上結對編寫解決同一問題的代碼

結對編程不僅意味着編程活動，也包括分析、設計、測試等全程活動。
結對編程有助於按時完成項目，並且保證高質量的代碼。

類似模型：

駕駛員：負責用鍵盤編寫程序 領航員：起到領航、提醒的作用 
 
兩個人輪流駕駛，角色互換

結對編程的基礎是會話和討論，不是一個人自得其樂。
口渴指數是覈實夥伴交流程度的一個考覈標準。

不要連續工作超過1個小時，每1個小時休息10分鐘
給同伴一點時間去發現和找到錯誤，別讓他覺得你很煩
常用的資料和規範（可以打印出來）以及書籍等應該放在手邊
結對開始之前要協調溝通，彼此互相通告希望對方關注些什麼，自己喜歡做什麼
主動參與，任何一個任務都是共同的責任，只有“我們的代碼
堅持代碼標準和流程規範 •  注意聽取夥伴的意見

下面的一些情況不適合結對編程：

處於探索階段的項目
後期維護的技術含量不高
驗證測試需要運行很長時間
團隊的人員要在多個項目中工作
領航的用處不大

另外，也不是所有的人都適合結對編程。

單元測試

3.1 單元測試概述

現實的開發問題：
經常把單元測試任務堆積到系統測試階段，導致：

大量故障堆積在項目中後期，項目後10% 的工作佔用了項目 90%的時間。
故障難以定位，而且飄忽不定，開發和測試人員疲於奔命。

單元測試（Unit Testing，UT）是對軟件中的最小可測試單元進行檢查和驗證。

單元測試內容

單元測試原則

單元測試過程

單元測試質量

測試覆蓋率可以查看本文章

單元測試方法
靜態測試：人工分析
動態測試：程序調試
黑盒測試（功能測試）：將測試對象看做一個黑盒子，完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。
白盒測試（結構測試）：把測試對象看做一個透明的盒子，允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。

保證單元測試的獨立性
一般來說，被測單元都不是獨立的，其上有調用模塊調用該單元，其下有依賴模塊被該單元調用。
如下圖：

因此，爲保證單元測試的獨立性，我們需要替換上層和下層的模塊。

舉個例子，驅動模塊用於輸入測試用例，接收bool測試結果。
下層模塊（樁模塊），用一些可能的模擬數據，提供給被測模塊。

xUnit（x表示不同語言）
xUnit 通常適用於以下場景的測試

單個函數、一個類或者幾個功能相關類的測試
尤其適用於純函數測試或者接口級別的測試

xUnit 無法適用於複雜場景的測試

被測對象依賴關係複雜，甚至無法簡單創建出這個對象
對於一些失敗場景的測試
被測對象中涉及多線程合作
被測對象通過消息與外界交互的場景
分佈式

Mock測試
Mock測試是在測試過程中對於某些不容易構造或者不容易獲取的對象，用一個虛擬的對象（即Mock對象）來創建以便測試的方法。

真實對象具有不可確定的行爲（產生不可預測的結果）
真實對象很難被創建（如具體的Web容器）
真實對象的某些行爲很難觸發（如網絡錯誤）
真實情況令程序的運行速度很慢
真實對象有用戶界面
測試需要詢問真實對象它是如何被調用的
真實對象實際上並不存在

關鍵：需要應用針對接口的編程技術，即被測試的代碼通過接口來引用對象，再使用Mock對象模擬所引用的對象及其行爲，因此被測試模塊並不知道它所引用的究竟是真實對象還是Mock對象。
例一：現有程序是 classA調用classB實現功能，現在要測試classB，可以將classB抽象成接口，同時寫一個實現該接口的Mock對象。此時通過接口調用，classA並不知道自己調用的是classB還是MOck對象。

例二：現有程序需要調用系統函數獲得當前時間，如果使用普通測試，可能需要苦苦等到設定好的時間。通過mock對象，替換時間獲取的方法，能夠隨心所欲的更改測試時間。

3.2 黑盒測試方法

良好的測試用例能夠降低軟件測試成本，保證測試工作質量，評估和檢驗測試效果。

測試用例的概念

測試用例的設計：

具有代表性和典型性
尋求系統設計和功能設計的弱點
既有正確輸入也有錯誤或異常輸入
考慮用戶實際的諸多使用場景

具體的實現方法請自己百度。

3.3 白盒測試方法

測試覆蓋標準

測試需求：測試的對象，是軟件製品的一個特定元素，如源代碼的一條語句、需求文檔等
覆蓋標準：將測試需求施加在一個測試集上的一組規則，如：源代碼的每條語句都要測試，這就是一個覆蓋標準
測試覆蓋：對於每個測試需求，至少有一個測試用例，滿足這個需求
覆蓋程度（覆蓋率）：完全測試是不現實的，一個測試集能夠滿足測試需求的比例。

覆蓋標準的選擇
軟心糖豆：6 種口味和 4 種顏色
檸檬味（黃色）、開心果味（綠色）、梨子味（白色）哈密瓜味（橙色）、橘子味（橙色）、杏味（黃色)

測試需求：口味、顏色
覆蓋標準：

顏色作爲標準，即便顏色覆蓋率爲100%，也會有兩種口味沒有覆蓋到
口味作爲標準，口味和顏色都能滿足覆蓋率100%

即：口味這個標準，包含顏色這個標準。

實際開發中複雜的多，通常考慮以下因素：

處理測試需求的難易程度
生成測試的難以程度
用測試發現缺陷的能力

案例
有一臺麪包機，輸入麪粉和水，輸出麪包。
如果該面包機廢棄多年，重新拿來使用需要進行測試。
黑盒測試（功能測試）：放入麪粉和水，看能不能生成麪包。
這種辦法顯然不全面，不能知道麪包機裏面是否生鏽、麪包是否真的能吃。
白盒測試（結構測試）：把麪包機拆開，清洗鏽跡，修理細節，然後再放入麪粉和水，生成麪包（黑盒測試）。

顯然白+黑更好。

控制流圖
控制流圖（CFG， Control Flow Graph）是一個過程或程序的抽象表示。

控制流圖的基本符號：

控制流圖就是簡化版的流程圖，他的每一個節點，都是一段過程，簡化方法：將順序計算的所有語句合併爲一個矩陣、將判斷語句放入棱形，並引出真假分支、將判斷結束後的匯聚點作爲合併節點。

如下：

基於控制流的測試流程

基本路徑測試
基本路徑測試是在程序控制流圖基礎上，通過分析控制構造的環路複雜性，導出基本可執行路徑集合，從而設計測試用例的方法。

計算環路複雜度的三種方法：

一個環爲一個區域，加上最外層整體區域
邊數-節點數+2
判斷節點數+1

如：

確定獨立路徑
一條獨立路徑與其他獨立路徑相比，至少有一條新的邊。
環路複雜度=獨立路徑數
獨立路徑選擇方法：以每個分支節點爲標準，向分支節點左右遍歷
如：

基本路徑測試

軟件開發過程

4.1 軟件過程

過程：是一組將輸入轉化爲輸出的相互關聯或相互作用的活動。

過程方法：系統地識別和管理組織內所使用的過程，保證更有效地獲得期望的結果。

軟件過程：

問題定義：人們通過開展技術探索和市場調查等活動，研究系統的可行性和可能的解決方案，確定待開發系統的總體目標和範圍。
問題提出 ⇒ 可行性研究 ⇒ 可行性分析報告
需求開發：在可行性研究之後，分析、整理和提煉所收集到的用戶需求，建立完整的需求分析模型，編寫軟件需求規格說明。
軟件設計：根據需求規格說明，確定軟件體系結構，進一步設計每個系統部件的實現算法、數據結構及其接口等。
軟件構造：概括地說是將軟件設計轉換成程序代碼，這是一個複雜而迭代的過程，要求根據設計模型進行程序設計以及正確而高效地編寫和測試代碼。
軟件測試：檢查和驗證所開發的系統是否符合客戶期望，主要包括單元測試、子系統測試、集成測試和驗收測試等活動。
軟件維護：系統投入使用後對其進行改進，以適應不斷變化的需求。完全從頭開發的系統很少，將軟件系統的開發和維護看成是一個連續過程更有意義。

軟件開發管理

軟件項目管理是爲了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量和風險進行控制和管理的活動。
軟件配置管理是通過執行版本控制、變更控制的規程，並且使用合適的配置管理軟件，來保證所有產品配置項的完整性和可跟蹤性。

4.2 軟件過程模型

軟件過程模型是對軟件過程的抽象描述。

瀑布模型

開發階段嚴格按照線性方式進行，每一個階段具有相關的里程碑和交付產品，且需要確認和驗證。

•  以預測性爲原則
•  以文檔驅動開發過程
•  以過程控制爲核心

每個階段的正確結果，作爲下一個階段的輸入。

缺點

軟件的行爲，只有在運行過程中，才能夠顯現出來。因此瀑布模型，只有到測試階段，才能真正的驗證和確認軟件的功能和性能，然而此時所有的代碼都已經編碼完畢，因此很難返回去糾正需求的問題和設計的缺陷。儘管對各個階段進行了嚴格的控制，但卻缺少了對變化的控制；
各個階段的大量文檔，增加了開發成本；
整個過程是線性的，開發過程中間，很難響應客戶的需求。
早期的錯誤，也要等到後期測試才能發現。

軟件開發作爲一個問題求解過程，具有迭代性。需要不斷地反覆嘗試，通過比較和選擇不同的設計，最終確定令人滿意的問題解決方案。
顯然，瀑布開發模式違背了這個性質。

原型化模型

解決需求不確定；
通過迅速構建一個軟件原型（可理解爲提供部分功能的、給用戶的操作界面），通過原型的“模擬使用”，迅速確定需求或設計。
原型可以是可運行軟件（慢），也可以是圖紙（快，更易修改）

迭代式開發

•  更快速地發佈產品
•  追求產品創新
•  需求不確定性高
•  需要快速響應用戶的變化
•  關注用戶行爲

迭代式開發有兩種模型：

增量模型：一張圖片分爲三部分，每次完成一部分
迭代模型：先把輪廓畫出來，然後修改細節，最後完成上色。

可轉換模型

需要構建準確的數學方法，因此目前只用於有限狀態的嵌入式系統。

4.3 敏捷開發過程

軟件開發是一個逐步認知和明晰的活動；
軟件開發中的變化是實際存在和必然的；

軟件開發應更關注於交付的價值
高質量的交付物是最重要的
系統不是一次構建而成，而是迭代演進的
基於完整的場景構建計劃，並按優先級執行

如今的互聯網時代：
•  快魚吃慢魚
•  版本發佈成本很低
•  追求創新
•  需要快速響應用戶的變化
•  需求不確定性高
•  關注用戶行爲

敏捷開發是一種基於更緊密的團隊協作、能夠有效應對快速變化需求、快速交付高質量軟件的迭代和增量的新型軟件開發方法。

•  更關注協作
•  更關注質量
•  更關注可工作的產品
•  更關注全才化的專才
•  基於實踐而非基於理論

由於需求是不可預測的,軟件開發應是一個自適應的跟蹤過程，而敏捷開發的特點，就是適應而非預測。

敏捷宣言：

傳統開發方法VS敏捷方法：

敏捷開發方法：

敏捷開發方法是一組輕量級開發方法的總稱，包含很多具體的開發過程和方法，最有影響的兩個方法是極限編程（XP）和Scrum開發方法。

XP和Scrum：

Scrum框架

product backlog：產品訂單，根據用戶需要，市場需求，所有利益相關者排序給出需求列表、
挑選出衝刺計劃、
一個衝刺週期內，每天進行會議，檢查進展情況
一個週期結束後，就能產生一個可運行的交付版本

Scrum迭代開發

迭代開發的關鍵要點：
•  每一次迭代都建立在穩定的質量基礎上，並做爲下一輪迭代的基線，整個系統的功能隨着迭代穩定地增長和不斷完善。
•  每次迭代要邀請用戶代表驗收，提供需求是否滿足的反饋。
•  在一次迭代中，一旦團隊作出承諾，就不允許變更交付件和交付日期；如果發生重大變化，產品負責人可以中止當次迭代。
•  在迭代中可能會出現“分解”和“澄清”，但是不允許添加新工作或者對現有的工作進行“實質變更”。
•  對於“分解”和“澄清”，如果存在爭議，那麼將其認定爲變更，放到產品訂單中下一次迭代再考慮

其他方法或框架
kanban

團隊開發管理

5.1 團隊組織與管理

開發團隊組織模式

民主式結構：團隊成員完全平等，享有充分民主，成員之間通過協商做出決策。
- 小組成員完全平等，名義上的組長與其他成員沒有任何區別。
- 項目工作由全體討論協商決定，並根據每個人的能力和經驗進行分配。
- 特別適合於規模小、能力強、習慣於共同工作的軟件開發組。
主程序員式結構：以主程序員爲核心，主程序員既是項目管理者也是技術負責人，團隊其他人員的職能進行專業化分工。
矩陣式結構：將技術與管理工作進行分離，技術負責人負責技術上的決策，管理負責人負責非技術性事務的管理決策和績效評價。

組織建設團隊

召開項目會議
確立團隊身份
創建共同的目標
管理決策制定
建立獎勵體系
管理衝突
激發項目團隊活動

團隊建設活動：

5.2 項目溝通管理

“智慧、專業技術、經驗三者只佔成功因素的25%，其餘75%決定於良好的人際溝通。”

溝通是你被理解了什麼，⽽不是你說了什麼

Brooks法則：向一個進度延遲的軟件項目中增加人員可能會使其進度更加推遲。
溝通人數在3~7，理論上是最合適的。

項目溝通管理：

•  和誰進行溝通？爲什麼？
•  需要什麼類型的信息？
•  詳盡程度和頻率如何？
•  溝通的目標是什麼？
•  採用何種方式溝通比較好？

項目會議：
•  項目啓動會議（至關重要）

目標
- 項目概況：範圍與目標、總體進度、方法和程序
- 確定項目人員的角色和任務
- 確立團隊的工作模式
形式
- 重大項目：精心準備、集中1-2 天；前期介紹與建立基本規則
- 一般項目：簡單有效；回顧項目範圍與成員互相自我介紹
建立基本規則 -  計劃決策、追蹤決策、管理變動決策、關係決策

• 項目計劃會議（通常在每一階段開始時）

制定當前階段的項目計劃
將工作任務明確分配給項目成員

項目組工作例會（每日或每週一次）

通報項目組成員的工作進展
瞭解成員在工作中遇到的困難，並尋找資源解決
確定後續的工作計劃

項目階段進展會議（每月或每季度一次）

向項目干係人和高層管理者彙報項目進展
解決需要高層管理者支持的問題

5.3 軟件項目計劃

軟件項目計劃是對軟件項目實施所涉及的活動、資源、任務、進度等進行規劃。按時交付是軟件項目的最大挑戰，合理地安排進度是軟件項目計劃的關鍵內容。

必須做什麼？
如何做？
誰去做？
什麼時候做？
成本是多少？
達到什麼質量？

軟件項目計劃流程：

開發問題描述
- 問題描述是描述系統應該說明的問題、目標環境、客戶交付和驗收標準的簡短文檔。問題描述是對系統所表述問題的共同認識，通常是由項目團隊和客戶共同開發形成的，它定義了問題提出的背景、需要支持的功能和性能以及系統運行的目標環境等。
定義頂層設計
- 頂層設計描述了最初從系統到子系統的分解，它描述了系統的軟件體系結構。
- 子系統分解應該是高層的，專注於功能，並且要保持穩定。
- 每一個子系統可以被分配給一個團隊或一個人，由他負責其定義和實現。
定義工作分解結構
- 項目工作分解是將項目整體分解成較小的、易於管理和控制的若干子項目或工作單元，直到可交付成果定義的足夠詳細，足以支持項目將來的活動。
建立初始時間表
- 在項目工作分解的基礎上，進一步估算活動所需的時間和資源，並按照一定的順序將這些活動進行組織和調度，從而創建項目的進度計劃表。
- 制定進度計劃需要在資源、時間和實現功能之間不斷平衡，並需要定期更新。