軟體工程 - 快速指南

---

---

軟體工程概述

讓我們首先了解軟體工程的含義。這個術語由兩個片語成：軟體和工程。

軟體不僅僅是程式程式碼。程式是可執行的程式碼，用於某種計算目的。軟體被認為是可執行程式設計程式碼、相關庫和文件的集合。為特定需求而編寫的軟體稱為軟體產品。

另一方面，工程是關於使用明確定義的科學原理和方法開發產品。

軟體工程是與使用明確定義的科學原理、方法和程式開發軟體產品相關的工程分支。軟體工程的結果是高效且可靠的軟體產品。

定義

IEEE將軟體工程定義為：

(1) 以系統化、規範化、可量化的方式進行軟體開發、執行和維護的應用；也就是說，將工程應用於軟體。

(2) 對上述陳述中所述方法的研究。

德國計算機科學家Fritz Bauer將軟體工程定義為：

軟體工程是在實際機器上經濟有效地獲得可靠且高效工作的軟體的建立和使用健全的工程原理。

軟體演進

使用軟體工程原理和方法開發軟體產品的過程稱為軟體演進。這包括軟體的初始開發及其維護和更新，直到開發出滿足預期需求的所需軟體產品。

演進始於需求收集過程。之後，開發人員建立目標軟體的原型，並在軟體產品開發的早期階段將其展示給使用者以獲取他們的反饋。使用者提出更改，在此基礎上，連續的更新和維護也會不斷變化。這個過程會改變原始軟體，直到完成所需的軟體。

即使使用者已經獲得了所需的軟體，不斷發展的技術和不斷變化的需求也迫使軟體產品做出相應的改變。從頭開始重新建立軟體並逐一滿足需求是不可行的。唯一可行且經濟的解決方案是更新現有軟體，使其與最新需求相匹配。

軟體演進定律

Lehman提出了軟體演進定律。他將軟體分為三類：

• S型（靜態型） - 這是嚴格按照定義的規範和解決方案工作的軟體。解決方案和實現方法在編碼之前都已立即理解。S型軟體最不易更改，因此這是最簡單的一種。例如，用於數學計算的計算器程式。
• P型（實用型） - 這是具有程式集合的軟體。這由程式可以執行的確切操作來定義。在此軟體中，可以描述規範，但解決方案並非立即可見。例如，遊戲軟體。
• E型（嵌入型） - 此軟體作為現實世界環境的需求緊密配合。此軟體具有高度的演化性，因為現實世界情況中的法律、稅收等方面存在各種變化。例如，線上交易軟體。

E型軟體演進

Lehman提出了E型軟體演進的八條定律：

• 持續變化 - E型軟體系統必須持續適應現實世界的變化，否則它將逐漸變得越來越無用。
• 複雜性增加 - 隨著E型軟體系統的演進，除非進行維護或減少其複雜性，否則其複雜性往往會增加。
• 熟悉性保持 - 必須不惜一切代價保留對軟體的熟悉程度或對其開發方式、為何以這種特定方式開發等的瞭解，以便在系統中實施更改。
• 持續增長 - 對於旨在解決某些業務問題的E型系統，其實施更改的規模會根據業務生活方式的變化而增長。
• 質量下降 - 除非嚴格維護並適應不斷變化的操作環境，否則E型軟體系統的質量會下降。
• 反饋系統 - E型軟體系統構成多環、多級反饋系統，必須將其視為這樣的系統才能成功修改或改進。
• 自調節 - E型系統演進過程是自調節的，產品和過程測量的分佈接近正態分佈。
• 組織穩定性 - 在演進的E型系統中，平均有效全域性活動率在產品的整個生命週期中是不變的。

軟體正規化

軟體正規化是指在設計軟體時採取的方法和步驟。今天提出了許多方法並正在使用中，但我們需要了解這些正規化在軟體工程中的位置。這些可以組合成不同的類別，儘管它們每個都包含在彼此之中。

程式設計正規化是軟體設計正規化的子集，而軟體設計正規化又是軟體開發正規化的子集。

軟體開發正規化

這種正規化被稱為軟體工程正規化，其中應用了與軟體開發相關的全部工程概念。它包括各種研究和需求收集，這有助於構建軟體產品。它包括：

• 需求收集
• 軟體設計
• 程式設計

軟體設計正規化

此正規化是軟體開發的一部分，包括：

• 設計
• 維護
• 程式設計

程式設計正規化

此正規化與軟體開發的程式設計方面密切相關。這包括：

• 編碼
• 測試
• 整合

軟體工程的必要性

軟體工程的必要性源於使用者需求和軟體執行環境變化速度加快。

• 大型軟體 - 建造一堵牆比建造一所房子或建築物更容易，同樣，隨著軟體規模的擴大，工程必須介入以使其具有科學的過程。
• 可擴充套件性 - 如果軟體過程不是基於科學和工程概念，那麼重新建立新軟體比擴充套件現有軟體更容易。
• 成本 - 正如硬體行業已經展示其技能並且大規模製造降低了計算機和電子硬體的價格一樣。但如果未採用適當的流程，軟體成本仍然很高。
• 動態特性 - 軟體不斷發展和適應的特性在很大程度上取決於使用者工作的環境。如果軟體的特性總是在變化，則需要對現有軟體進行新的增強。這就是軟體工程發揮良好作用的地方。
• 質量管理 - 更好的軟體開發流程可提供更好、更高質量的軟體產品。

優秀軟體的特性

軟體產品可以透過其提供的功能和易用性來判斷。此軟體必須在以下方面滿足要求：

• 操作性
• 過渡性
• 維護

設計精良的軟體應具有以下特性：

操作性

這說明軟體在操作中的工作情況。它可以根據以下方面進行衡量：

• 預算
• 可用性
• 效率
• 正確性
• 功能性
• 可靠性
• 安全性
• 安全性

過渡性

當軟體從一個平臺遷移到另一個平臺時，這個方面很重要。

• 可移植性
• 互操作性
• 可重用性
• 適應性

維護

這個方面簡要介紹了軟體在不斷變化的環境中保持自身能力的情況。

• 模組化
• 可維護性
• 靈活性
• 可擴充套件性

簡而言之，軟體工程是計算機科學的一個分支，它使用明確定義的工程概念來生產高效、持久、可擴充套件、符合預算和按時交付的軟體產品。

軟體開發生命週期

軟體開發生命週期（簡稱SDLC）是軟體工程中一個明確定義的、結構化的階段序列，用於開發預期的軟體產品。

SDLC活動

SDLC提供了一系列步驟，以便高效地設計和開發軟體產品。SDLC框架包括以下步驟：

溝通

這是第一步，使用者在此發起對所需軟體產品的請求。他聯絡服務提供商並試圖協商條款。他以書面形式向服務提供組織提交他的請求。

需求收集

從這一步開始，軟體開發團隊開始執行專案。團隊與來自問題領域的各種利益相關者進行討論，並嘗試儘可能多地瞭解他們的需求。需求經過考慮並分為使用者需求、系統需求和功能需求。使用許多實踐來收集需求，如下所示：

• 研究現有或過時的系統和軟體；
• 對使用者和開發人員進行訪談；
• 參考資料庫；或
• 收集問卷答案。

可行性研究

在需求收集之後，團隊會制定一個軟體過程的粗略計劃。在此步驟中，團隊會分析是否可以製作軟體來滿足使用者的全部需求，以及軟體是否可能不再有用。它會確定該專案在財務上、實際上和技術上是否可行。有很多演算法可以幫助開發人員得出軟體專案的可行性結論。

系統分析

在此步驟中，開發人員確定其計劃的路線圖，並嘗試提出最適合專案的軟體模型。系統分析包括：瞭解軟體產品的侷限性；預先了解系統相關問題或現有系統中需要進行的更改；識別和解決專案對組織和人員的影響等。專案團隊分析專案的範圍，並相應地規劃進度和資源。

軟體設計

下一步是將所有需求和分析知識整理出來，並設計軟體產品。使用者提供的輸入和在需求收集階段收集的資訊是此步驟的輸入。此步驟的輸出以兩種設計形式出現：邏輯設計和物理設計。工程師會生成元資料和資料字典、邏輯圖、資料流圖，在某些情況下還會生成虛擬碼。

編碼

此步驟也稱為程式設計階段。軟體設計的實現從使用合適的程式語言編寫程式程式碼和高效地開發無錯誤的可執行程式開始。

測試

據估計，整個軟體開發過程的 50% 應該用於測試。錯誤可能會從嚴重級別到軟體本身被移除，都會破壞軟體。軟體測試由開發人員在編碼過程中進行，並由測試專家在程式碼的各個級別（例如模組測試、程式測試、產品測試、內部測試以及在使用者端測試產品）進行徹底的測試。儘早發現錯誤並加以糾正，是獲得可靠軟體的關鍵。

整合

軟體可能需要與庫、資料庫和其他程式整合。SDLC 的此階段涉及將軟體與外部實體整合。

實施

這意味著將軟體安裝在使用者機器上。有時，軟體需要在使用者端進行安裝後配置。軟體會針對可移植性和適應性進行測試，並在實施過程中解決與整合相關的問題。

執行和維護

此階段確認軟體執行效率更高且錯誤更少。如有需要，會對使用者進行培訓，或提供有關如何操作軟體以及如何保持軟體執行的文件。透過根據使用者端環境或技術的更改及時更新程式碼來維護軟體。此階段可能會面臨隱藏錯誤和現實世界中未識別問題的挑戰。

處置

隨著時間的推移，軟體的效能可能會下降。它可能完全過時，或者可能需要大量的升級。因此，迫切需要消除系統的大部分內容。此階段包括存檔資料和所需的軟體元件、關閉系統、規劃處置活動以及在適當的系統結束時間終止系統。

軟體開發正規化

軟體開發範例幫助開發人員選擇開發軟體的策略。軟體開發範例具有自己的一套工具、方法和程式，這些工具、方法和程式表達清晰，並定義了軟體開發生命週期。一些軟體開發範例或流程模型定義如下：

瀑布模型

瀑布模型是最簡單的軟體開發範例模型。它指出 SDLC 的所有階段將以線性方式一個接一個地執行。也就是說，只有完成第一個階段後，才會啟動第二個階段，依此類推。

此模型假設所有事情都按照上一階段的計劃完美地執行和發生，並且不需要考慮下一階段可能出現的過去問題。如果上一步驟留下了一些問題，則此模型無法順利執行。模型的順序性質不允許我們返回並撤消或重做我們的操作。

如果開發人員過去已經設計和開發過類似的軟體，並且瞭解其所有領域，則此模型最適合。

迭代模型

此模型以迭代方式引導軟體開發過程。它以迴圈方式預測開發過程，在 SDLC 過程的每個週期後重復每個步驟。

軟體首先在非常小的規模上開發，並且會遵循所有考慮在內的步驟。然後，在每次迭代中，都會設計、編碼、測試和新增到軟體中更多的功能和模組。每個週期都會產生一個軟體，它本身就是完整的，並且比前一個軟體具有更多功能和能力。

在每次迭代之後，管理團隊可以進行風險管理工作併為下一次迭代做準備。因為一個週期包含整個軟體過程的一小部分，所以更容易管理開發過程，但它會消耗更多資源。

螺旋模型

螺旋模型是迭代模型和 SDLC 模型之一的組合。可以將其視為選擇一個 SDLC 模型並將其與迴圈過程（迭代模型）組合。

此模型考慮風險，而大多數其他模型往往忽略了這一點。該模型從確定一次迭代開始時軟體的目標和約束開始。下一階段是軟體的原型設計。這包括風險分析。然後使用標準 SDLC 模型構建軟體。在第四階段，準備下一次迭代的計劃。

V 模型

瀑布模型的主要缺點是，我們只有在上一個階段完成後才能進入下一個階段，如果在後期階段發現某些錯誤，則沒有機會返回。V 模型提供了一種以相反方式在每個階段測試軟體的方法。

在每個階段，都會建立測試計劃和測試用例，以根據該階段的要求驗證和確認產品。例如，在需求收集階段，測試團隊會根據需求準備所有測試用例。稍後，當產品開發完畢並準備進行測試時，此階段的測試用例會根據此階段的要求驗證軟體的有效性。

這使得驗證和確認能夠並行進行。此模型也稱為驗證和確認模型。

大爆炸模型

此模型是形式上最簡單的模型。它需要很少的計劃，大量的程式設計和大量的資金。該模型的概念圍繞著宇宙大爆炸。正如科學家所說，大爆炸之後，許多星系、行星和恆星都像一個事件一樣進化。同樣，如果我們將大量的程式設計和資金放在一起，我們可能會獲得最好的軟體產品。

對於此模型，只需要很少的規劃。它不遵循任何流程，或者有時客戶不確定需求和未來的需求。因此，輸入需求是任意的。

此模型不適用於大型軟體專案，但對於學習和實驗來說是一個不錯的選擇。

要深入瞭解 SDLC 及其各種模型，點選此處。

軟體專案管理

從事軟體開發的 IT 公司的職位模式可以分為兩部分：

• 軟體建立
• 軟體專案管理

專案是一個明確定義的任務，它是一系列為了實現目標而執行的操作的集合（例如，軟體開發和交付）。專案可以概括為：

• 每個專案可能都有一個獨特且不同的目標。
• 專案不是例行活動或日常運營。
• 專案有開始時間和結束時間。
• 專案在實現其目標時結束，因此它是組織生命週期中的一個臨時階段。
• 專案需要充足的資源，包括時間、人力、資金、材料和知識庫。

軟體專案

軟體專案是軟體開發的完整過程，從需求收集到測試和維護，根據執行方法，在規定的時間內完成，以實現預期的軟體產品。

軟體專案管理的必要性

軟體被稱為無形產品。軟體開發是世界商業中一種全新的潮流，在構建軟體產品方面經驗很少。大多數軟體產品都是定製的，以適應客戶的需求。最重要的是，底層技術變化和發展如此頻繁和迅速，以至於一個產品的經驗可能無法應用於另一個產品。所有這些業務和環境限制都會給軟體開發帶來風險，因此高效地管理軟體專案至關重要。

上圖顯示了軟體專案的三個約束。對於軟體組織來說，在客戶預算限制內保持成本，並根據計劃交付專案，交付高質量產品至關重要。有許多內部和外部因素可能會影響這個三約束三角形。任何三個因素都可能嚴重影響其他兩個因素。

因此，軟體專案管理對於結合使用者需求以及預算和時間限制至關重要。

軟體專案經理

軟體專案經理是一個承擔執行軟體專案責任的人。軟體專案經理完全瞭解軟體將經歷的 SDLC 的所有階段。專案經理可能永遠不會直接參與最終產品的生產，但他會控制和管理生產中涉及的活動。

專案經理密切監控開發過程，制定和執行各種計劃，安排必要的和足夠的資源，保持所有團隊成員之間的溝通，以解決成本、預算、資源、時間、質量和客戶滿意度的問題。

讓我們看看專案經理承擔的一些責任：

人員管理

• 擔任專案領導
• 與利益相關者溝通
• 人力資源管理
• 建立報告層次結構等。

專案管理

• 定義和設定專案範圍
• 管理專案管理活動
• 監控進度和績效
• 每個階段的風險分析
• 採取必要的步驟來避免或解決問題
• 擔任專案發言人

軟體管理活動

軟體專案管理包含許多活動，包括專案規劃、確定軟體產品的範圍、估算各種方面的成本、安排任務和事件以及資源管理。專案管理活動可能包括：

• 專案規劃
• 範圍管理
• 專案估算

專案規劃

軟體專案規劃是在軟體實際生產開始之前執行的任務。它用於軟體生產，但不涉及任何與軟體生產有任何直接聯絡的具體活動；相反，它是一組多個流程，這些流程促進了軟體生產。專案規劃可能包括以下內容：

範圍管理

它定義了專案的範圍；這包括所有活動，需要完成這些過程才能製作可交付的軟體產品。範圍管理至關重要，因為它透過明確定義專案中將執行什麼和不執行什麼來建立專案的邊界。這使得專案包含有限且可量化的任務，這些任務可以輕鬆地記錄下來，進而避免成本和時間超支。

在專案範圍管理期間，有必要：

• 定義範圍
• 確定其驗證和控制
• 將專案劃分為各個較小的部分，以便於管理。
• 驗證範圍
• 透過納入範圍變更來控制範圍

專案估算

為了有效管理，準確估算各種指標是必須的。透過正確的估算，管理者可以更高效、更有效地管理和控制專案。

專案估算可能包括以下內容：

• 軟體規模估算

  軟體規模可以根據程式碼行數（KLOC，千行程式碼）估算，也可以透過計算軟體的功能點來估算。程式碼行數取決於編碼規範，功能點則根據使用者或軟體需求而變化。

• 工作量估算

  管理者根據人員需求和生產軟體所需的工時來估算工作量。進行工作量估算需要知道軟體規模。這可以透過管理者的經驗、組織的歷史資料獲得，或者可以使用一些標準公式將軟體規模轉換為工作量。

• 時間估算

  一旦估算出規模和工作量，就可以估算出生產軟體所需的時間。根據需求規格說明和軟體各個元件的相互依賴性，將所需的工作量細分為子類別。軟體任務透過工作分解結構 (WBS) 分解成更小的任務、活動或事件。這些任務按天或按日曆月進行安排。

  完成所有任務所需時間的總和（以小時或天為單位）就是完成專案所需的總時間。

• 成本估算

  這可能是所有估算中最困難的，因為它依賴於比前面任何一項都更多的因素。為了估算專案成本，需要考慮：

• 軟體規模
• 軟體質量
• 硬體
• 附加軟體或工具、許可證等
• 具備特定任務技能的熟練人員
• 差旅費用
• 溝通
• 培訓和支援

專案估算技術

我們討論了專案估算中涉及的各種引數，例如規模、工作量、時間和成本。

專案經理可以使用兩種廣泛認可的技術來估算上述因素：

分解技術

這種技術將軟體視為各種組成部分的產物。

主要有兩種模型：

• 程式碼行數 根據軟體產品中的程式碼行數進行估算。
• 功能點 根據軟體產品中的功能點數量進行估算。

經驗估算技術

這種技術使用經驗得出的公式進行估算。這些公式基於程式碼行數或功能點。

• Putnam 模型

  該模型由 Lawrence H. Putnam 建立，基於 Norden 的頻率分佈（瑞利曲線）。Putnam 模型將所需的時間和工作量與軟體規模關聯起來。

• COCOMO

  COCOMO 代表 COnstructive COst MOdel，由 Barry W. Boehm 開發。它將軟體產品分為三類：有機型、半獨立型和嵌入型。

專案進度安排

專案進度安排是指對所有活動進行規劃，指定順序並在每個活動分配的時間段內完成。專案經理傾向於定義各種任務和專案里程碑，並考慮到各種因素進行安排。他們會關注進度表中關鍵路徑上的任務，這些任務需要以特定方式（由於任務的相互依賴性）並在分配的時間內嚴格完成。關鍵路徑之外的任務不太可能影響專案的整體進度。

為了安排專案進度，需要：

• 將專案任務分解成更小、更易於管理的形式
• 找出各種任務並將其關聯起來
• 估算每個任務所需的時間範圍
• 將時間劃分為工作單元
• 為每個任務分配足夠數量的工作單元
• 計算專案從開始到結束所需的總時間

資源管理

開發軟體產品所使用的所有元素都可以視為該專案的資源。這可能包括人力資源、生產工具和軟體庫。

資源的數量有限，作為資產池存在於組織中。資源短缺會阻礙專案開發，並可能導致專案落後於進度。分配額外的資源最終會增加開發成本。因此，必須對專案進行充分的資源估算和分配。

資源管理包括：

• 透過建立專案團隊併為每個團隊成員分配職責來定義適當的專案組織
• 確定特定階段所需的資源及其可用性
• 透過在需要時生成資源請求並在不再需要時取消分配資源來管理資源。

專案風險管理

風險管理涉及所有與識別、分析和為專案中可預測和不可預測的風險做出規避措施的活動。風險可能包括：

• 經驗豐富的員工離開專案，新員工加入。
• 組織管理的變化。
• 需求變更或需求理解錯誤。
• 對所需時間和資源的低估。
• 技術變革、環境變化、商業競爭。

風險管理流程

風險管理流程涉及以下活動：

• 識別 - 記錄專案中可能發生的所有風險。
• 分類 - 根據其對專案可能造成的潛在影響，將已知風險分為高、中、低風險強度。
• 管理 - 分析風險在各個階段發生的機率。制定避免或應對風險的計劃。嘗試儘量減少其負面影響。
• 監控 - 密切監控潛在風險及其早期徵兆。還要監控為減輕或避免風險而採取的措施的效果。

專案執行與監控

在此階段，專案計劃中描述的任務將按照其進度執行。

執行需要監控，以檢查一切是否按計劃進行。監控是觀察以檢查風險的可能性並採取措施解決風險或報告各種任務的狀態。

這些措施包括：

• 活動監控 - 可以每天監控在某個任務中安排的所有活動。當任務中的所有活動都完成後，該任務即被視為完成。
• 狀態報告 - 報告包含在給定時間段內（通常是一週）完成的活動和任務的狀態。狀態可以標記為已完成、待處理或進行中等等。
• 里程碑清單 - 每個專案都細分為多個階段，在這些階段中會根據 SDLC 的階段執行主要任務（里程碑）。此里程碑清單每隔幾周準備一次，並報告里程碑的狀態。

專案溝通管理

有效的溝通在專案的成功中起著至關重要的作用。它彌合了客戶和組織之間的差距，彌合了團隊成員以及專案中的其他利益相關者（例如硬體供應商）之間的差距。

溝通可以是口頭的或書面的。溝通管理流程可能包括以下步驟：

• 計劃 - 此步驟包括識別專案中的所有利益相關者以及他們之間的溝通方式。它還考慮是否需要任何額外的溝通設施。
• 分享 - 在確定計劃的各個方面後，經理會專注於在正確的時間向正確的人分享正確的資訊。這使每個參與專案的人都能夠及時瞭解專案的進展及其狀態。
• 反饋 - 專案經理使用各種措施和反饋機制，並建立狀態和績效報告。這種機制確保來自各個利益相關者的意見作為反饋傳達給專案經理。
• 收尾 - 在每個主要事件結束、SDLC 階段結束或專案本身結束時，將正式宣佈行政收尾，以便透過傳送電子郵件、分發文件的紙質副本或其他有效的溝通方式向每個利益相關者進行更新。

收尾後，團隊將進入下一階段或專案。

配置管理

配置管理是一個跟蹤和控制軟體變化的過程，這些變化涉及產品的需求、設計、功能和開發。

IEEE 將其定義為“識別和定義系統中的專案，控制這些專案在其整個生命週期中的變化，記錄和報告專案和變更請求的狀態，以及驗證專案的完整性和正確性”。

通常，一旦 SRS 定稿，使用者就很少需要更改需求。如果發生更改，只有在獲得高階管理層的批准後才能解決這些更改，因為存在成本和時間超支的可能性。

基線

如果某個 SDLC 階段已建立基線，則該階段被認為已完成，即基線是定義階段完整性的衡量標準。當與某個階段相關的所有活動都完成並記錄在案時，該階段即已建立基線。如果不是最後一個階段，其輸出將用於下一個階段。

配置管理是組織管理的一個分支，負責在某個階段建立基線後發生的任何變化（流程、需求、技術、策略等）。CM 會檢查軟體中所做的任何更改。

變更控制

變更控制是配置管理的功能，它確保對軟體系統所做的所有更改都是一致的，並符合組織的規章制度。

產品配置的更改將經歷以下步驟：

• 識別 - 變更請求來自內部或外部來源。當正式識別變更請求時，會對其進行適當的記錄。

• 驗證 - 檢查變更請求的有效性並確認其處理程式。

• 分析 - 從進度、成本和所需工作量的角度分析變更請求的影響。分析預期的變更對系統的整體影響。

• 控制 - 如果預期的更改會影響系統中的太多實體，或者它是不可避免的，則必須在將更改合併到系統中之前獲得高階管理層的批准。決定更改是否值得納入。如果不可行，則正式拒絕變更請求。

• 執行 - 如果上一階段決定執行變更請求，則此階段將採取適當的操作來執行更改，如有必要，將進行徹底的修訂。

• 關閉請求 - 驗證更改是否已正確實施並與系統的其餘部分合並。軟體中新納入的更改將被妥善記錄，並正式關閉請求。

專案管理工具

即使專案按照既定方法開發，專案規模越大，風險和不確定性也會成倍增加。

有一些工具可以幫助有效地進行專案管理。以下是一些描述：

甘特圖

甘特圖由亨利·甘特（1917年）設計。它根據時間段表示專案進度。它是一個水平條形圖，條形代表活動以及專案活動的時間安排。

PERT圖

PERT（計劃評審技術）圖是一種將專案描繪成網路圖的工具。它能夠以並行和連續的方式圖形化地表示專案的關鍵事件。依次發生的事件顯示了後續事件對先前事件的依賴性。

事件顯示為編號的節點。它們透過帶標籤的箭頭連線，描繪了專案中任務的順序。

資源柱狀圖

這是一個圖形工具，包含條形圖或圖表，表示專案事件（或階段）隨時間推移所需的資源數量（通常是熟練員工）。資源柱狀圖是有效的人員計劃和協調工具。

關鍵路徑分析

此工具有助於識別專案中相互依賴的任務。它還有助於找出成功完成專案的最佳路徑或關鍵路徑。與PERT圖一樣，每個事件都被分配一個特定的時間範圍。此工具顯示事件的依賴性，假設一個事件只有在先前事件完成之後才能繼續進行。

事件按其最早可能的開始時間排列。開始節點和結束節點之間的路徑是關鍵路徑，無法進一步縮短，並且所有事件都需要按相同的順序執行。

軟體需求

軟體需求是對目標系統特性和功能的描述。需求傳達了使用者對軟體產品的期望。從客戶的角度來看，需求可能是顯而易見的或隱藏的，已知的或未知的，預期的或未預期的。

需求工程

從客戶處收集軟體需求、分析和記錄這些需求的過程稱為需求工程。

需求工程的目標是開發和維護複雜且具有描述性的“系統需求規格說明”文件。

需求工程流程

這是一個四步過程，包括：

• 可行性研究
• 需求收集
• 軟體需求規格說明
• 軟體需求驗證

讓我們簡要了解一下這個過程：

可行性研究

當客戶聯絡組織以開發所需產品時，他們會對軟體必須執行的所有功能以及軟體的預期特性有一個大致的概念。

參考這些資訊，分析人員會詳細研究所需系統及其功能是否可行。

這項可行性研究側重於組織的目標。這項研究分析了軟體產品在實施方面、對組織的貢獻、成本約束以及根據組織的價值觀和目標是否能夠實際實現。它探討了專案的技術方面和產品，例如可用性、可維護性、生產力和整合能力。

此階段的輸出應為一份可行性研究報告，其中應包含關於專案是否應該進行的充分評論和管理建議。

需求收集

如果可行性報告對進行專案持積極態度，則下一階段將從收集使用者的需求開始。分析人員和工程師與客戶和終端使用者溝通，瞭解他們對軟體應該提供什麼以及他們希望軟體包含哪些功能的想法。

軟體需求規格說明

SRS是由系統分析師在從各個利益相關者收集需求後建立的文件。

SRS定義了預期的軟體將如何與硬體、外部介面、執行速度、系統響應時間、軟體在各種平臺上的可移植性、可維護性、崩潰後的恢復速度、安全、質量、限制等進行互動。

從客戶那裡收到的需求是用自然語言編寫的。系統分析師有責任用技術語言記錄需求，以便軟體開發團隊能夠理解和使用這些需求。

SRS應該具備以下特性：

• 使用者需求是用自然語言表達的。
• 技術需求是用組織內部使用的結構化語言表達的。
• 設計描述應使用虛擬碼編寫。
• 表單和GUI螢幕截圖的格式。
• DFD等的條件和數學符號。

軟體需求驗證

在開發需求規格說明之後，將驗證此文件中提到的需求。使用者可能會要求非法的、不切實際的解決方案，或者專家可能會錯誤地解釋需求。如果不能從一開始就解決這個問題，這將導致成本大幅增加。可以根據以下條件檢查需求：

• 如果它們可以實際實現
• 如果它們有效並且符合軟體的功能和領域
• 如果存在任何歧義
• 如果它們是完整的
• 如果它們可以被證明

需求獲取過程

可以使用以下圖表來描述需求獲取過程

• 需求收集 - 開發人員與客戶和終端使用者討論，瞭解他們對軟體的期望。
• 組織需求 - 開發人員根據重要性、緊迫性和便利性對需求進行優先順序排序和安排。

• 協商與討論 - 如果需求不明確或各個利益相關者的需求存在衝突，則應與利益相關者進行協商和討論。然後可以對需求進行優先順序排序並進行合理的妥協。

  需求來自各個利益相關者。為了消除歧義和衝突，需要討論其清晰度和正確性。不切實際的需求應進行合理的妥協。

• 文件編制 - 所有正式和非正式、功能性和非功能性需求都將被記錄下來，並提供給下一階段處理。

需求獲取技術

需求獲取是透過與客戶、終端使用者、系統使用者以及其他在軟體系統開發中擁有利益的人員溝通，找出預期軟體系統需求的過程。

有多種方法可以發現需求

訪談

訪談是收集需求的有力手段。組織可以進行幾種型別的訪談，例如：

• 結構化（封閉式）訪談，其中預先確定了要收集的每一條資訊，它們遵循模式和討論的內容。
• 非結構化（開放式）訪談，其中預先沒有確定要收集的資訊，更靈活且偏差更小。
• 口頭訪談
• 書面訪談
• 一對一訪談，在兩人之間進行。
• 小組訪談，在參與者之間進行。由於涉及眾多人員，它們有助於發現任何遺漏的需求。

調查

組織可以透過詢問各個利益相關者對即將推出的系統的期望和需求來進行調查。

問卷調查

將包含預定義的一組客觀問題和相應選項的文件交給所有利益相關者回答，然後收集和整理這些答案。

這項技術的缺點是，如果問卷中沒有提到某個問題的選項，則該問題可能會被忽略。

任務分析

工程師和開發人員團隊可以分析需要新系統進行的操作。如果客戶已經有一些軟體來執行某些操作，則對其進行研究並收集擬議系統的需求。

領域分析

每個軟體都屬於某個領域類別。該領域的專家可以極大地幫助分析一般和特定需求。

頭腦風暴

在各個利益相關者之間進行非正式辯論，並記錄所有輸入內容以供進一步的需求分析。

原型設計

原型設計是在不新增詳細功能的情況下構建使用者介面，以便使用者解釋預期軟體產品的特性。它有助於更好地瞭解需求。如果客戶終端沒有安裝軟體供開發人員參考，並且客戶不瞭解自己的需求，則開發人員會根據最初提到的需求建立原型。原型將顯示給客戶，並記錄反饋。客戶反饋將作為需求收集的輸入。

觀察

專家團隊訪問客戶的組織或工作場所。他們觀察現有已安裝系統的實際工作情況。他們觀察客戶的工作流程以及如何處理執行問題。團隊本身會得出一些結論，這些結論有助於形成對軟體的預期需求。

軟體需求特性

收集軟體需求是整個軟體開發專案的基礎。因此，它們必須清晰、正確且定義明確。

完整的軟體需求規格說明必須：

• 清晰
• 正確
• 一致
• 連貫
• 易於理解
• 可修改
• 可驗證
• 已排序
• 明確
• 可追溯
• 可靠的來源

軟體需求

我們應該嘗試瞭解在需求獲取階段可能會出現什麼樣的需求，以及軟體系統需要什麼樣的需求。

廣義上講，軟體需求應分為兩類：

功能需求

與軟體功能相關的需求屬於此類。

它們定義軟體系統內部和軟體系統的功能。

例如：

• 為使用者提供搜尋選項，以便從各種發票中進行搜尋。
• 使用者應該能夠將任何報告透過郵件傳送給管理層。
• 使用者可以被分成組，並且可以為組分配單獨的許可權。
• 應遵守業務規則和管理功能。
• 軟體開發過程中保持向下相容性。

非功能性需求

與軟體功能方面無關的需求屬於此類。它們是軟體的隱含或預期特性，使用者對此進行假設。

非功能性需求包括：

• 安全性
• 日誌記錄
• 儲存
• 配置
• 效能
• 成本
• 互操作性
• 靈活性
• 災難恢復
• 可訪問性

需求按邏輯分類為：

• 必須具備：沒有它們，軟體就不能算作可執行的。
• 應該具備：增強軟體的功能。
• 可以具備：即使沒有這些需求，軟體也能正常執行。
• 願望清單：這些需求與軟體的任何目標都不匹配。

在軟體開發過程中，必須實現“必須具備”的需求，“應該具備”的需求需要與利益相關者協商和取捨，而“可以具備”和“願望清單”中的需求可以保留到軟體更新時再考慮。

使用者介面需求

UI是任何軟體、硬體或混合系統的的重要組成部分。如果軟體：

• 易於操作
• 響應迅速
• 有效處理操作錯誤
• 提供簡單且一致的使用者介面

使用者是否接受軟體很大程度上取決於使用者如何使用軟體。UI是使用者感知系統的唯一途徑。一個性能良好的軟體系統也必須配備具有吸引力、清晰、一致和響應迅速的使用者介面。否則，軟體系統功能將無法以方便的方式使用。如果一個系統能夠提供高效使用的方法，則該系統被認為是良好的。以下是使用者介面需求的簡要說明：

• 內容呈現
• 輕鬆導航
• 簡潔的介面
• 響應式
• 一致的UI元素
• 反饋機制
• 預設設定
• 有目的的佈局
• 策略性地使用顏色和紋理。
• 提供幫助資訊
• 以使用者為中心的方法
• 基於組的檢視設定。

軟體系統分析師

IT組織中的系統分析師是一個分析擬議系統需求並確保需求被正確且完整地構思和記錄的人員。分析師的角色始於SDLC的軟體分析階段。分析師有責任確保開發的軟體滿足客戶的需求。

系統分析師的職責包括：

• 分析和理解目標軟體的需求
• 理解專案如何促進組織目標的實現
• 識別需求來源
• 需求驗證
• 制定和實施需求管理計劃
• 記錄業務、技術、流程和產品需求
• 與客戶協調以確定需求優先順序並消除歧義
• 與客戶和其他利益相關者最終確定驗收標準

軟體度量和衡量

軟體度量可以理解為量化和象徵軟體的各種屬性和方面的一個過程。

軟體度量為軟體過程和軟體產品的各個方面提供度量。

軟體度量是軟體工程的基本要求。它們不僅有助於控制軟體開發過程，而且還有助於保持最終產品的卓越質量。

軟體工程師湯姆·德馬科 (Tom DeMarco) 認為：“你無法控制你無法衡量的東西。” 這句話清楚地說明了軟體度量的重要性。

讓我們來看一些軟體度量：

• 規模度量 - LOC（程式碼行數），通常以交付的原始碼行數（千行）計算，表示為 KLOC。

  功能點計數是衡量軟體提供的功能的指標。功能點計數定義了軟體功能方面的規模。

• 複雜度度量 - McCabe 的迴圈複雜度量化了程式中獨立路徑數量的上限，這被認為是程式或其模組的複雜度。它使用控制流圖透過圖論概念表示。

• 質量度量 - 缺陷、缺陷的型別和原因、後果、嚴重程度和影響定義了產品的質量。

  在開發過程中發現的缺陷數量和產品安裝或交付給客戶後客戶報告的缺陷數量，決定了產品的質量。

• 過程度量 - 在SDLC的各個階段，所使用的方法和工具、公司標準以及開發的效能都是軟體過程度量。
• 資源度量 - 所用的努力、時間和各種資源代表資源測量的指標。

軟體設計基礎

軟體設計是一個將使用者需求轉換為某種合適形式的過程，這有助於程式設計師進行軟體編碼和實現。

為了評估使用者需求，會建立一個 SRS（軟體需求規格說明）文件，而對於編碼和實現，則需要使用軟體術語進行更具體和詳細的需求。此過程的輸出可以直接用於程式語言中的實現。

軟體設計是 SDLC（軟體設計生命週期）的第一步，它將重點從問題域轉移到解決方案域。它試圖指定如何滿足 SRS 中提到的需求。

軟體設計級別

軟體設計產生三個級別的結果：

• 體系結構設計 - 體系結構設計是系統的最高抽象版本。它將軟體識別為一個由許多相互互動的元件組成的系統。在這個級別，設計人員可以瞭解擬議的解決方案域。
• 高層設計 - 高層設計將體系結構設計中的“單個實體-多個元件”概念分解為子系統和模組的較少抽象檢視，並描述它們之間的相互作用。高層設計側重於如何以模組的形式實現系統及其所有元件。它識別每個子系統的模組化結構及其相互之間的關係和互動。
• 詳細設計 - 詳細設計處理在之前的兩個設計中被視為系統及其子系統的實現部分。它對模組及其實現更詳細。它定義每個模組的邏輯結構及其與其他模組通訊的介面。

模組化

模組化是一種將軟體系統劃分為多個離散且獨立的模組的技術，這些模組有望能夠獨立地執行任務。這些模組可以作為整個軟體的基本構造。設計人員傾向於設計模組，以便可以單獨且獨立地執行和/或編譯它們。

模組化設計無意中遵循了“分而治之”的解決問題策略的規則，這是因為模組化軟體設計還附帶許多其他好處。

模組化的優點：

• 較小的元件更容易維護
• 程式可以根據功能方面進行劃分
• 可以在程式中引入所需的抽象級別
• 具有高內聚性的元件可以再次重用
• 可以實現併發執行
• 從安全形度來看是理想的

併發性

過去，所有軟體都旨在順序執行。順序執行意味著編碼指令將一個接一個地執行，這意味著任何給定時間只有一個程式部分被啟用。例如，一個軟體有多個模組，那麼在任何執行時間，只能找到一個模組處於活動狀態。

在軟體設計中，併發性是透過將軟體拆分為多個獨立的執行單元（如模組）並並行執行它們來實現的。換句話說，併發性為軟體提供了並行執行多個程式碼部分的能力。

程式設計師和設計師有必要識別哪些模組可以進行並行執行。

示例

文字處理器中的拼寫檢查功能是一個軟體模組，它與文字處理器本身一起執行。

耦合和內聚

當軟體程式模組化時，其任務將根據某些特性劃分為幾個模組。眾所周知，模組是一組指令，為了完成某些任務而組合在一起。它們雖然被認為是單個實體，但可能會相互引用以一起工作。有一些衡量標準可以用來衡量模組的設計質量及其相互之間的互動。這些衡量標準稱為耦合和內聚。

內聚

內聚是一種衡量模組元素內部依賴程度的指標。內聚越高，程式設計就越好。

共有七種內聚型別：

• 偶然內聚 - 這是無計劃的和隨機的內聚，可能是為了模組化而將程式分解成較小模組的結果。因為它沒有計劃，所以可能會讓程式設計師感到困惑，並且通常不被接受。
• 邏輯內聚 - 當邏輯分類的元素組合到一個模組中時，這稱為邏輯內聚。
• 時間內聚 - 當模組的元素被組織起來，以便在相似的點處理時，這稱為時間內聚。
• 過程內聚 - 當模組的元素組合在一起，按順序執行以執行任務時，這稱為過程內聚。
• 通訊內聚 - 當模組的元素組合在一起，按順序執行並在相同的資料（資訊）上工作時，這稱為通訊內聚。
• 順序內聚 - 當模組的元素組合在一起，因為一個元素的輸出作為另一個元素的輸入，依此類推時，這稱為順序內聚。
• 功能內聚 - 這被認為是最高程度的內聚，並且它是非常理想的。功能內聚中模組的元素組合在一起，因為它們都對單個明確定義的功能做出了貢獻。它也可以重複使用。

耦合

耦合是一種衡量程式模組之間相互依賴程度的指標。它說明了模組以什麼級別相互干擾和互動。耦合越低，程式越好。

共有五種耦合級別：

• 內容耦合 - 當一個模組可以直接訪問、修改或引用另一個模組的內容時，這稱為內容級耦合。
• 公共耦合 - 當多個模組對某些全域性資料具有讀寫訪問許可權時，這稱為公共或全域性耦合。
• 控制耦合 - 如果一個模組決定另一個模組的功能或更改其執行流程，則這兩個模組稱為控制耦合。
• 標記耦合 - 當多個模組共享公共資料結構並在其不同部分工作時，這稱為標記耦合。
• 資料耦合 - 資料耦合是指兩個模組透過傳遞資料（作為引數）來相互互動。如果一個模組傳遞資料結構作為引數，那麼接收模組應該使用其所有元件。

理想情況下，無耦合被認為是最好的。

設計驗證

軟體設計過程的輸出是設計文件、虛擬碼、詳細邏輯圖、流程圖以及所有功能性或非功能性需求的詳細描述。

下一個階段，即軟體的實現，取決於上述所有輸出。

因此，在進入下一個階段之前，有必要驗證輸出。越早發現錯誤越好，否則可能直到產品測試時才被發現。如果設計階段的輸出採用形式化表示形式，則應使用其相關的驗證工具；否則，可以使用徹底的設計評審進行驗證。

透過結構化驗證方法，評審人員可以發現可能因忽略某些條件而造成的缺陷。良好的設計評審對於良好的軟體設計、準確性和質量至關重要。

軟體分析與設計工具

軟體分析和設計包括所有有助於將需求規範轉換為實現的活動。需求規範指定軟體的所有功能性和非功能性期望。這些需求規範以人類可讀和理解的文件形式出現，計算機對此無能為力。

軟體分析和設計是中間階段，它有助於將人類可讀的需求轉換為實際程式碼。

讓我們看看軟體設計師使用的一些分析和設計工具

資料流圖

資料流圖是資訊系統中資料流動的圖形表示。它能夠描繪傳入資料流、傳出資料流和儲存資料。DFD 沒有提及資料如何在系統中流動。

DFD 和流程圖之間存在顯著區別。流程圖描述程式模組中的控制流。DFD 描述系統中不同層次的資料流。DFD 不包含任何控制或分支元素。

DFD 的型別

資料流圖可以是邏輯的或物理的。

• 邏輯 DFD - 此型別的 DFD 重點關注系統過程和系統中的資料流。例如，在銀行軟體系統中，資料如何在不同實體之間移動。
• 物理 DFD - 此型別的 DFD 顯示資料流在系統中的實際實現方式。它更具體，更接近於實現。

DFD 元件

DFD 可以使用以下元件集表示資料來源、目標、儲存和流 -

• 實體 - 實體是資訊資料的源和目標。實體用矩形及其各自的名稱表示。
• 過程 - 對資料採取的活動和操作用圓形或圓角矩形表示。
• 資料儲存 - 資料儲存有兩個變體 - 它可以表示為兩側都沒有的矩形，也可以表示為只有一側缺失的開放式矩形。
• 資料流 - 資料移動用尖箭頭表示。資料移動從箭頭的底部（作為其源）指向箭頭的頭部（作為目標）。

DFD 的層次

• 0 層 - 最高抽象級別的 DFD 稱為 0 層 DFD，它將整個資訊系統描繪成一個圖，隱藏所有底層細節。0 層 DFD 也稱為上下文層 DFD。

• 1 層 - 0 層 DFD 被分解成更具體的 1 層 DFD。1 層 DFD 描繪系統中的基本模組以及各個模組之間的資料流。1 層 DFD 還提到了基本流程和資訊來源。


• 2 層 - 在此級別，DFD 顯示資料如何在 1 層中提到的模組內部流動。

  更高層次的 DFD 可以轉換為更具體的更低層次的 DFD，並具有更深入的理解，直到達到所需的規範級別。

結構圖

結構圖是從資料流圖派生的圖表。它比 DFD 更詳細地表示系統。它將整個系統分解為最低功能模組，比 DFD 更詳細地描述每個系統模組的功能和子功能。

結構圖表示模組的層次結構。每一層執行一項特定任務。

以下是結構圖中使用的符號 -

• 模組 - 它表示過程、子程式或任務。控制模組分支到多個子模組。庫模組是可重用的，可以從任何模組呼叫。
• 條件 - 它用模組底部的菱形表示。它表示控制模組可以根據某些條件選擇任何子程式。
• 跳轉 - 指向模組內部的箭頭表示控制將跳轉到子模組的中間。
• 迴圈 - 曲線箭頭表示模組中的迴圈。迴圈覆蓋的所有子模組都重複執行模組。
• 資料流 - 末端帶有空心圓的定向箭頭表示資料流。
• 控制流 - 末端帶有實心圓的定向箭頭表示控制流。

HIPO 圖

HIPO（層次輸入過程輸出）圖是分析系統並提供文件化手段的兩種組織方法的組合。HIPO 模型由 IBM 於 1970 年開發。

HIPO 圖表示軟體系統中模組的層次結構。分析師使用 HIPO 圖來獲得系統功能的高階檢視。它以層次方式將功能分解為子功能。它描述了系統執行的功能。

HIPO 圖非常適合文件化目的。它們的圖形表示使設計人員和管理人員更容易獲得系統結構的圖解。

與描繪模組中控制流和資料流的 IPO（輸入過程輸出）圖相反，HIPO 不提供有關資料流或控制流的任何資訊。

示例

HIPO 圖的兩個部分，層次表示和 IPO 圖表，都用於軟體程式的結構設計以及同一程式的文件化。

結構化英語

大多數程式設計師都沒有意識到軟體的大圖景，因此他們只依賴於管理人員告訴他們做什麼。高階軟體管理人員有責任向程式設計師提供準確的資訊，以開發準確且快速的程式碼。

使用圖表或圖的其他方法有時會被不同的人解釋得不同。

因此，軟體的分析師和設計師提出了諸如結構化英語之類的工具。它只不過是對需要編碼的內容以及如何編碼的描述。結構化英語幫助程式設計師編寫無錯誤的程式碼。

使用圖表或圖的其他方法有時會被不同的人解釋得不同。在這裡，結構化英語和虛擬碼都試圖彌合這種理解差距。

結構化英語使用結構化程式設計範例中的普通英語單詞。它不是最終的程式碼，而是一種對需要編碼的內容以及如何編碼的描述。以下是結構化程式設計的一些標記。

IF-THEN-ELSE,  
DO-WHILE-UNTIL

分析師使用儲存在資料字典中的相同變數和資料名稱，這使得編寫和理解程式碼更加簡單。

示例

我們以線上購物環境中的客戶身份驗證為例。可以使用結構化英語編寫此客戶身份驗證過程，如下所示：

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
   Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
   PRINT error message
   Call procedure NEW_CUSTOMER_REQUEST()
ENDIF

用結構化英語編寫的程式碼更像是日常口語英語。它不能直接作為軟體程式碼實現。結構化英語獨立於程式語言。

虛擬碼

虛擬碼更接近於程式語言。它可以被認為是增強的程式語言，充滿了註釋和描述。

虛擬碼避免變數宣告，但它們使用某些實際程式語言的結構編寫，例如 C、Fortran、Pascal 等。

虛擬碼比結構化英語包含更多程式設計細節。它提供了一種執行任務的方法，就像計算機正在執行程式碼一樣。

示例

列印斐波那契數列直到 n 個數的程式。

void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
   if a greater than b 
   {
      Increase b by a;
      Print b;
   } 
   else if b greater than a
   {
      increase a by b;
      print a;
   }
}

決策表

決策表以結構化的表格格式表示條件以及為解決這些條件而應採取的相應操作。

它是一個強大的工具，可以除錯和防止錯誤。它有助於將類似的資訊分組到一個表中，然後透過組合表來提供簡單方便的決策。

建立決策表

要建立決策表，開發人員必須遵循以下四個基本步驟

• 確定所有需要解決的可能條件
• 確定所有已識別條件的操作
• 建立儘可能多的規則
• 為每條規則定義操作

決策表應由終端使用者驗證，並且稍後可以透過消除重複規則和操作來簡化。

示例

讓我們以我們網際網路連線的日常問題的簡單示例為例。我們首先確定啟動網際網路時可能出現的所有問題及其各自可能的解決方案。

我們將所有可能的問題列在“條件”列下，並將可能的解決方案列在“操作”列下。

表：決策表 – 內部網際網路故障排除

實體關係模型

實體關係模型是一種資料庫模型，基於現實世界實體及其之間關係的概念。我們可以將現實世界場景對映到 ER 資料庫模型。ER 模型建立一組具有其屬性的實體、一組約束以及它們之間的關係。

ER 模型最適合用於資料庫的概念設計。ER 模型可以表示如下

• 實體 - ER 模型中的實體是現實世界中的存在，它具有一些稱為屬性的屬性。每個屬性都由其對應的值集定義，稱為域。

  例如，考慮一個學校資料庫。這裡，學生是一個實體。學生具有各種屬性，例如姓名、ID、年齡和班級等。

• 關係 - 實體之間的邏輯關聯稱為關係。關係以各種方式對映到實體。對映基數定義兩個實體之間的關聯數。

  對映基數

  • 一對一
  • 一對多
  • 多對一
  • 多對多

資料字典

資料字典是關於資料的集中式資訊集合。它儲存資料的含義和來源、它與其他資料的關聯、使用的資料格式等。資料字典對所有名稱都具有嚴格的定義，以方便使用者和軟體設計師。

資料字典通常被稱為元資料（關於資料的資料）儲存庫。它與軟體程式的資料流圖 (DFD) 模型一起建立，並且在 DFD 發生更改或更新時，也應相應更新。

資料字典的需求

在軟體設計和實現過程中，資料是透過資料字典來引用的。資料字典消除了任何歧義的可能性。它有助於使程式設計師和設計師在程式的各個部分使用相同的物件引用時保持工作同步。

資料字典提供了一種在一個地方記錄完整資料庫系統的方法。可以使用資料字典對 DFD 進行驗證。

內容

資料字典應包含以下方面的資訊：

• 資料流
• 資料結構
• 資料元素
• 資料儲存
• 資料處理

資料流透過前面學習過的資料流圖 (DFD) 來描述，並以所述的代數形式表示。

示例

地址 = 門牌號 + （街道/區域）+ 城市 + 省份

課程ID = 課程編號 + 課程名稱 + 課程級別 + 課程成績

資料元素

資料元素由資料和控制項、內部或外部資料儲存等的名稱和描述組成，包含以下詳細資訊：

• 主名稱
• 次要名稱（別名）
• 用例（如何以及在哪裡使用）
• 內容描述（符號等）
• 補充資訊（預設值、約束等）

資料儲存

它儲存資料進入系統和離開系統的資訊。資料儲存可能包括：

• 檔案
  • 軟體內部。
  • 軟體外部，但在同一臺機器上。
  • 軟體和系統外部，位於不同的機器上。
• 表
  • 命名約定
  • 索引屬性

資料處理

資料處理有兩種型別：

• 邏輯：使用者看到的
• 物理：軟體看到的

軟體設計策略

軟體設計是一個將軟體需求概念化為軟體實現的過程。軟體設計將使用者需求作為挑戰，並試圖找到最佳解決方案。在軟體概念化的過程中，會制定一個計劃來找到實現預期解決方案的最佳設計。

軟體設計有多種變體。讓我們簡要地學習它們。

結構化設計

結構化設計是將問題概念化為解決方案的幾個組織良好的元素。它主要關注解決方案設計。結構化設計的優點是，它能夠更好地理解如何解決問題。結構化設計還可以使設計人員更準確地專注於問題。

結構化設計主要基於“分而治之”的策略，其中一個問題被分解成幾個較小的問題，並且每個小問題都被單獨解決，直到整個問題被解決。

小問題的解決是透過解決方案模組來實現的。結構化設計強調這些模組必須組織良好，以實現精確的解決方案。

這些模組按層次排列。它們相互通訊。良好的結構化設計始終遵循一些模組間通訊規則，即：

內聚性 - 將所有功能相關的元素分組。

耦合性 - 不同模組之間的通訊。

良好的結構化設計具有高內聚性和低耦合性。

面向函式的設計

在面向函式的設計中，系統由許多稱為函式的較小的子系統組成。這些函式能夠在系統中執行重要任務。系統被認為是所有函式的頂層檢視。

面向函式的設計繼承了結構化設計的一些屬性，其中使用了分而治之的方法。

這種設計機制將整個系統劃分為較小的函式，這透過隱藏資訊及其操作來提供抽象方法。這些功能模組可以透過傳遞資訊和使用全域性可用的資訊來相互共享資訊。

函式的另一個特點是，當程式呼叫函式時，函式會改變程式的狀態，這有時是其他模組無法接受的。面向函式的設計適用於系統狀態無關緊要且程式/函式基於輸入而不是狀態的情況。

設計過程

• 整個系統被視為資料如何透過資料流圖在系統中流動。
• DFD 描述了函式如何改變資料和整個系統狀態。
• 整個系統根據其在系統中的操作邏輯地分解成較小的單元，稱為函式。
• 然後詳細描述每個函式。

面向物件的設計

面向物件的設計圍繞實體及其特性而不是軟體系統中涉及的函式展開。這種設計策略側重於實體及其特性。軟體解決方案的整個概念圍繞參與的實體展開。

讓我們看看面向物件設計的重要概念：

• 物件 - 解決方案設計中涉及的所有實體都稱為物件。例如，人、銀行、公司和客戶都被視為物件。每個實體都有一些與其相關的屬性，並有一些方法對屬性進行操作。

• 類 - 類是對物件的概括性描述。物件是類的例項。類定義了物件可以具有的所有屬性以及定義物件功能的方法。

  在解決方案設計中，屬性儲存為變數，功能透過方法或過程定義。

• 封裝 - 在 OOD 中，將屬性（資料變數）和方法（對資料進行的操作）捆綁在一起稱為封裝。封裝不僅將物件的 important 資訊捆綁在一起，還限制了外部世界對資料和方法的訪問。這稱為資訊隱藏。
• 繼承 - OOD 允許相似的類以層次結構方式堆疊，其中較低的或子類可以從其直接的超類匯入、實現和重用允許的變數和方法。OOD 的此屬性稱為繼承。這使得定義特定類和從特定類建立通用類更容易。
• 多型性 - OOD 語言提供了一種機制，其中執行類似任務但引數不同的方法可以分配相同的名稱。這稱為多型性，它允許單個介面為不同型別執行任務。根據函式呼叫的方式，程式碼的相應部分將被執行。

設計過程

軟體設計過程可以被視為一系列明確定義的步驟。儘管它根據設計方法（面向函式或面向物件）而有所不同，但它可能涉及以下步驟：

• 根據需求或先前使用的系統和/或系統序列圖建立解決方案設計。
• 識別物件並根據屬性特徵的相似性將其分組到類中。
• 定義類層次結構及其之間的關係。
• 定義應用程式框架。

軟體設計方法

以下是兩種通用的軟體設計方法：

自頂向下設計

我們知道一個系統是由多個子系統組成的，它包含許多元件。此外，這些子系統和元件可能有它們自己的子系統和元件集，並在系統中建立層次結構。

自頂向下設計將整個軟體系統作為一個實體，然後根據某些特性將其分解為多個子系統或元件。然後將每個子系統或元件視為一個系統，並進一步分解。此過程持續執行，直到達到自頂向下層次結構中的最低系統級別。

自頂向下設計從系統的通用模型開始，並不斷定義其更具體的方面。當所有元件組合在一起時，整個系統就形成了。

當軟體解決方案需要從頭設計並且具體細節未知時，自頂向下設計更合適。

自底向上設計

自底向上設計模型從最具體和最基本的元件開始。它透過使用基本或較低級別的元件來構建更高級別的元件。它不斷建立更高級別的元件，直到所需的系統沒有發展為單個元件。隨著每個更高級別，抽象量都會增加。

當需要從某些現有系統建立系統時，自底向上策略更合適，其中基本原語可以在較新的系統中使用。

自頂向下和自底向上方法單獨使用都不實用。相反，使用這兩種方法的良好組合。

軟體使用者介面設計

使用者介面是前端應用程式檢視，使用者與其互動以使用軟體。使用者可以透過使用者介面操作和控制軟體以及硬體。如今，使用者介面幾乎存在於任何使用數字技術的地方，從計算機、行動電話、汽車、音樂播放器、飛機、船舶等。

使用者介面是軟體的一部分，其設計方式旨在向用戶提供對軟體的洞察力。UI 為人機互動提供了基本平臺。

UI 可以是圖形化的、基於文字的、基於音訊影片的，這取決於底層的硬體和軟體組合。UI 可以是硬體或軟體，也可以是兩者的組合。

如果其使用者介面：

• 吸引人
• 易於使用
• 響應時間短
• 易於理解
• 所有介面螢幕上保持一致

UI 主要分為兩類：

• 命令列介面
• 圖形使用者介面

命令列介面 (CLI)

在影片顯示器出現之前，CLI 一直是與計算機互動的重要工具。CLI 是許多技術使用者和程式設計師的首選。CLI 是軟體可以為使用者提供的最小介面。

CLI 提供一個命令提示符，使用者在此處鍵入命令並將其饋送到系統。使用者需要記住命令的語法及其用法。早期的 CLI 沒有被程式設計為有效地處理使用者錯誤。

命令是文字形式的指令集的引用，系統預期執行這些指令。宏、指令碼等方法使使用者易於操作。

與 GUI 相比，CLI 使用的計算機資源較少。

CLI 元素

基於文字的命令列介面可以包含以下元素：

• 命令提示符 - 它是一個基於文字的通知器，主要顯示使用者正在工作的上下文。它由軟體系統生成。

• 游標 - 它是一條細小的水平線或一條與行高相同的垂直條，用於表示打字時字元的位置。游標通常處於閃爍狀態。當用戶編寫或刪除內容時，它會移動。

• 命令 - 命令是一個可執行的指令。它可以有一個或多個引數。命令執行後的輸出將直接顯示在螢幕上。輸出產生後，命令提示符將顯示在下一行。

圖形使用者介面

圖形使用者介面 (GUI) 為使用者提供了與系統互動的圖形化方式。GUI 可以是硬體和軟體的組合。使用者透過 GUI 來理解軟體。

通常，GUI 比 CLI 更消耗資源。隨著技術的進步，程式設計師和設計師建立了更復雜、更高效、更準確、更快速的 GUI 設計。

GUI 元素

GUI 提供了一組元件來與軟體或硬體互動。

每個圖形元件都提供了一種與系統互動的方式。GUI 系統具有以下元素：

• 視窗 - 顯示應用程式內容的區域。如果視窗代表檔案結構，則視窗中的內容可以以圖示或列表的形式顯示。使用者在資源管理器視窗中瀏覽檔案系統更容易。視窗可以最小化、調整大小或最大化到螢幕大小。它們可以移動到螢幕上的任何位置。視窗可以包含同一應用程式的另一個視窗，稱為子視窗。

• 標籤 - 如果應用程式允許執行其多個例項，則它們會在螢幕上顯示為單獨的視窗。選項卡式文件介面 允許在同一視窗中開啟多個文件。此介面還有助於檢視應用程式中的首選項面板。所有現代網路瀏覽器都使用此功能。

• 選單 - 選單是一組標準命令的陣列，它們組合在一起並放置在應用程式視窗中可見的位置（通常是頂部）。可以對選單進行程式設計，使其在滑鼠點選時顯示或隱藏。

• 圖示 - 圖示是一張小圖片，代表相關的應用程式。單擊或雙擊這些圖示時，將開啟應用程式視窗。圖示以小圖片的形式顯示系統上安裝的應用程式和程式。

• 游標 - 在 GUI 中，滑鼠、觸控板、數位筆等互動式裝置表示為游標。螢幕游標幾乎即時地遵循硬體的指令。在 GUI 系統中，游標也稱為指標。它們用於選擇選單、視窗和其他應用程式功能。

特定於應用程式的 GUI 元件

應用程式的 GUI 包含列出的一個或多個 GUI 元素。

• 應用程式視窗 - 大多數應用程式視窗使用作業系統提供的結構，但許多應用程式使用自己建立的自定義視窗來包含應用程式的內容。

• 對話方塊 - 這是一個子視窗，包含給使用者的提示資訊以及需要採取的操作請求。例如：應用程式會生成一個對話方塊，以獲取使用者刪除檔案的確認。

  

• 文字框 - 為使用者提供了一個區域來鍵入和輸入基於文字的資料。

• 按鈕 - 它們模擬現實生活中的按鈕，用於向軟體提交輸入。

  

• 單選按鈕 - 顯示可供選擇的選項。所有提供的選項中只能選擇一個。

• 複選框 - 功能類似於列表框。選擇一個選項後，該框將被標記為已選中。可以選中由複選框表示的多個選項。

• 列表框 - 提供可供選擇的專案列表。可以選中多個專案。

  

其他令人印象深刻的 GUI 元件包括：

• 滑塊
• 組合框
• 資料網格
• 下拉列表

使用者介面設計活動

設計使用者介面會執行許多活動。GUI 設計和實現的過程類似於 SDLC（軟體開發生命週期）。瀑布模型、迭代模型或螺旋模型都可以用於 GUI 實現。

用於 GUI 設計和開發的模型應滿足這些 GUI 特定的步驟。

• GUI 需求收集 - 設計師可能希望列出 GUI 的所有功能和非功能需求。這可以從使用者及其現有的軟體解決方案中獲得。

• 使用者分析 - 設計師會研究誰將使用該軟體 GUI。目標受眾很重要，因為設計細節會根據使用者的知識和能力水平而改變。如果使用者是技術達人，則可以採用高階和複雜的 GUI。對於新手使用者，會包含更多關於軟體使用方法的資訊。

• 任務分析 - 設計師必須分析軟體解決方案要完成的任務。在 GUI 中，如何完成並不重要。任務可以以分層的方式表示，將一個主要任務進一步細分為較小的子任務。任務為 GUI 展示提供目標。子任務之間資訊流決定了軟體中 GUI 內容的流程。

• GUI 設計與實現 - 設計師在獲得關於需求、任務和使用者環境的資訊後，設計 GUI 並將其實現到程式碼中，並將 GUI 與後臺的工作或虛擬軟體嵌入在一起。然後由開發人員對其進行自測。

• 測試 - GUI 測試可以透過多種方式進行。組織可以進行內部檢查，直接讓使用者參與，以及釋出測試版等。測試可能包括可用性、相容性、使用者驗收等。

GUI 實現工具

有幾種工具可用，設計師可以使用這些工具只需單擊滑鼠即可建立整個 GUI。某些工具可以嵌入到軟體環境（IDE）中。

GUI 實現工具提供強大的 GUI 控制元件陣列。為了進行軟體定製，設計師可以相應地更改程式碼。

根據不同的用途和平臺，GUI 工具分為不同的部分。

示例

移動 GUI、計算機 GUI、觸控式螢幕 GUI 等。以下是一些構建 GUI 的實用工具列表：

• FLUID
• AppInventor（Android）
• LucidChart
• Wavemaker
• Visual Studio

使用者介面黃金法則

以下規則被認為是 GUI 設計的黃金法則，由 Shneiderman 和 Plaisant 在他們的著作《Designing the User Interface》（使用者介面設計）中描述。

• 力求一致性 - 在類似的情況下，應需要一致的操作順序。提示、選單和幫助螢幕中應使用相同的術語。整個過程中應使用一致的命令。

• 允許頻繁使用者使用快捷鍵 - 使用者減少互動次數的願望會隨著使用頻率的增加而增加。縮寫、功能鍵、隱藏命令和宏工具對專家使用者非常有幫助。

• 提供資訊反饋 - 對於每個操作員操作，都應該有一些系統反饋。對於頻繁和次要的操作，響應必須適中，而對於不頻繁和主要的操作，響應必須更充分。

• 設計對話方塊以產生閉合感 - 操作序列應組織成具有開始、中間和結束的組。在完成一組操作後提供的資訊反饋，讓操作員獲得成就感、解脫感，併發出訊號，讓他們從腦海中放棄應急計劃和選項，這表明前進的道路清晰，可以準備下一組操作。

• 提供簡單的錯誤處理 - 儘可能設計系統，以防止使用者犯嚴重錯誤。如果發生錯誤，系統應該能夠檢測到它，並提供簡單易懂的錯誤處理機制。

• 允許輕鬆撤消操作 - 此功能可以減輕焦慮，因為使用者知道可以撤消錯誤。輕鬆撤消操作鼓勵探索不熟悉的選項。可逆轉的單元可以是單個操作、資料條目或一組完整的操作。

• 支援內部控制中心 - 經驗豐富的操作員強烈希望感覺到他們掌控著系統，並且系統響應他們的操作。設計系統，使使用者成為操作的發起者，而不是響應者。

• 減少短期記憶負荷 - 人類在短期記憶中資訊處理的侷限性要求顯示保持簡單，多個頁面顯示合併，視窗移動頻率降低，並分配足夠的培訓時間來學習程式碼、助記符和操作序列。

軟體設計複雜性

複雜性是指事件或事物處於具有多個相互關聯的連結和高度複雜結構的狀態。在軟體程式設計中，隨著軟體設計的實現，元素的數量及其相互連線的數量逐漸變得巨大，這使得一次難以理解。

如果不使用複雜性指標和度量，軟體設計複雜性就難以評估。讓我們看看三個重要的軟體複雜性度量。

Halstead 複雜性度量

1977 年，Maurice Howard Halstead 先生引入了用於測量軟體複雜性的指標。Halstead 指標取決於程式的實際實現及其度量，這些度量是靜態地直接從原始碼中的運算子和運算元計算出來的。它允許評估 C/C++/Java 原始碼的測試時間、詞彙量、大小、難度、錯誤和工作量。

根據 Halstead 的說法，“計算機程式是演算法的實現，被認為是令牌的集合，這些令牌可以分為運算子或運算元”。Halstead 指標將程式視為運算子及其相關運算元的序列。

他定義了各種指標來檢查模組的複雜性。

當我們在度量檢視器中選擇原始檔以檢視其複雜性詳細資訊時，將在度量報告中看到以下結果

圈複雜度度量

每個程式都包含需要執行以執行某些任務的語句以及其他決定哪些語句需要執行的決策語句。這些決策結構改變了程式的流程。

如果我們比較兩個大小相同的程式，那麼具有更多決策語句的程式將更復雜，因為程式控制會頻繁跳轉。

McCabe 在 1976 年提出了圈複雜度度量來量化給定軟體的複雜性。這是一個基於程式決策結構（例如 if-else、do-while、repeat-until、switch-case 和 goto 語句）的圖形驅動模型。

建立流程控制圖的過程

• 將程式分解成更小的塊，由決策結構分隔。
• 建立表示每個塊的節點。
• 按如下方式連線節點

• 如果控制可以從塊 i 分支到塊 j

  繪製一條弧

• 從出口節點到入口節點

  繪製一條弧。

為了計算程式模組的圈複雜度，我們使用以下公式 -

V(G) = e – n + 2

Where
e is total number of edges
n is total number of nodes

上述模組的圈複雜度是

e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
                      = 4

根據 P. Jorgensen 的說法，模組的圈複雜度不應超過 10。

功能點

它被廣泛用於衡量軟體的大小。功能點關注系統提供的功能。系統的特性和功能用於衡量軟體複雜性。

功能點計數基於五個引數，分別命名為外部輸入、外部輸出、邏輯內部檔案、外部介面檔案和外部查詢。為了考慮軟體的複雜性，每個引數進一步分為簡單、平均和複雜。

讓我們看看功能點的引數

外部輸入

來自外部的每個唯一輸入都被視為外部輸入。輸入的唯一性是衡量的，因為沒有兩個輸入應該具有相同的格式。這些輸入可以是資料或控制引數。

• 簡單 - 如果輸入計數低且影響較少的內部檔案

• 複雜 - 如果輸入計數高且影響較多的內部檔案

• 平均 - 簡單和複雜之間。

外部輸出

系統提供的所有輸出型別都計入此類別。如果輸出格式和/或處理是唯一的，則輸出被認為是唯一的。

• 簡單 - 如果輸出計數低

• 複雜 - 如果輸出計數高

• 平均 - 簡單和複雜之間。

邏輯內部檔案

每個軟體系統都維護內部檔案以維護其功能資訊並正常執行。這些檔案儲存系統的邏輯資料。這些邏輯資料可能包含功能資料和控制資料。

• 簡單 - 如果記錄型別數量少

• 複雜 - 如果記錄型別數量多

• 平均 - 簡單和複雜之間。

外部介面檔案

軟體系統可能需要與其它的外部軟體共享其檔案，或者它可能需要將檔案傳遞給某個函式進行處理或作為引數。

• 簡單 - 如果共享檔案中記錄型別的數量少

• 複雜 - 如果共享檔案中記錄型別的數量多

• 平均 - 簡單和複雜之間。

外部查詢

查詢是輸入和輸出的組合，使用者傳送一些資料作為輸入進行查詢，系統則以處理後的查詢輸出響應使用者。查詢的複雜性高於外部輸入和外部輸出。如果查詢的輸入和輸出在格式和資料方面是唯一的，則該查詢被認為是唯一的。

• 簡單 - 如果查詢需要較少的處理併產生少量輸出資料

• 複雜 - 如果查詢需要大量的處理併產生大量的輸出資料

• 平均 - 簡單和複雜之間。

系統中的每個引數都會根據其類別和複雜性賦予權重。下表列出了賦予每個引數的權重

上表得出原始功能點。這些功能點會根據環境複雜性進行調整。系統使用十四個不同的特性來描述

• 資料通訊
• 分散式處理
• 效能目標
• 操作配置負載
• 事務速率
• 線上資料輸入
• 終端使用者效率
• 線上更新
• 複雜的處理邏輯
• 可重用性
• 安裝簡易性
• 操作簡易性
• 多個站點
• 希望方便更改

這些特性因素的等級從 0 到 5，如下所示

• 無影響
• 偶然的
• 適中的
• 平均
• 重要的
• 必要的

所有等級相加為 N。N 的值範圍為 0 到 70（14 種特性 x 5 種等級）。它用於使用以下公式計算複雜性調整因子 (CAF)

CAF = 0.65 + 0.01N

然後，

Delivered Function Points (FP)= CAF x Raw FP

此 FP 可用於各種度量，例如

成本 = 美元/FP

質量 = 錯誤數/FP

生產力 = FP/人月

軟體實現

在本章中，我們將學習軟體實現中的程式設計方法、文件和挑戰。

結構化程式設計

在編碼過程中，程式碼行不斷增加，從而導致軟體大小增加。逐漸地，記住程式流程變得幾乎不可能。如果一個人忘記了軟體及其底層程式、檔案、過程是如何構建的，那麼共享、除錯和修改程式就會變得非常困難。解決這個問題的方法是結構化程式設計。它鼓勵開發人員使用子程式和迴圈，而不是在程式碼中使用簡單的跳轉，從而使程式碼更清晰並提高其效率。結構化程式設計還有助於程式設計師減少編碼時間並正確組織程式碼。

結構化程式設計規定了程式的編碼方式。結構化程式設計使用三個主要概念

• 自頂向下分析 - 軟體總是被用來執行一些合理的工作。在軟體術語中，這項合理的工作被稱為問題。因此，瞭解如何解決問題非常重要。在自頂向下分析中，問題被分解成許多小的部分，每個部分都有一定的意義。每個問題都被單獨解決，並清楚地說明了解決問題的方法。

• 模組化程式設計 - 在程式設計中，程式碼被分解成更小的指令組。這些組被稱為模組、子程式或子例程。模組化程式設計基於對自頂向下分析的理解。它不鼓勵使用程式中的“goto”語句進行跳轉，這通常會使程式流程難以追蹤。在結構化程式設計中禁止跳轉並鼓勵模組化格式。

• 結構化編碼 - 參考自頂向下分析，結構化編碼按照其執行順序將模組進一步細分為更小的程式碼單元。結構化程式設計使用控制結構來控制程式的流程，而結構化編碼使用控制結構以可定義的模式組織其指令。

函數語言程式設計

函數語言程式設計是一種程式語言風格，它使用數學函式的概念。數學中的函式在接收到相同的引數時應該總是產生相同的結果。在過程式語言中，程式的流程透過過程執行，即程式的控制被轉移到被呼叫的過程。當控制流從一個過程轉移到另一個過程時，程式會改變其狀態。

在程序式程式設計中，過程在使用相同引數呼叫時可能產生不同的結果，因為程式本身在呼叫時可能處於不同的狀態。這是程序式程式設計的一個特性也是一個缺點，其中過程執行的順序或時間變得很重要。

函數語言程式設計提供了一種將計算作為數學函式的方法，無論程式狀態如何，它都會產生結果。這使得預測程式的行為成為可能。

函數語言程式設計使用以下概念

• 一等函式和高階函式 - 這些函式能夠接受另一個函式作為引數，或者將其他函式作為結果返回。

• 純函式 - 這些函式不包括破壞性更新，也就是說，它們不影響任何 I/O 或記憶體，如果它們沒有被使用，則可以很容易地刪除它們而不會影響程式的其餘部分。

• 遞迴 - 遞迴是一種程式設計技術，其中一個函式呼叫自身並在其中重複程式程式碼，直到滿足某個預定義的條件。遞迴是在函數語言程式設計中建立迴圈的方式。

• 嚴格求值 - 這是一種對作為引數傳遞給函式的表示式進行求值的方法。函數語言程式設計有兩種求值方法，嚴格（急切）或非嚴格（惰性）。嚴格求值總是在呼叫函式之前對錶達式進行求值。非嚴格求值不會對錶達式求值，除非需要。

• λ演算 - 大多數函數語言程式設計語言使用 λ 演算作為其型別系統。λ 表示式在出現時透過對其進行求值來執行。

Common Lisp、Scala、Haskell、Erlang 和 F# 是一些函數語言程式設計語言的示例。

程式設計風格

程式設計風格是一套所有程式設計師遵循的編寫程式碼的規則。當多個程式設計師在一個軟體專案上工作時，他們經常需要使用其他開發人員編寫的程式程式碼。如果所有開發人員不遵循某些標準程式設計風格來編寫程式，這將變得繁瑣，有時甚至是不可能的。

適當的程式設計風格包括使用與預期任務相關的函式和變數名稱、使用放置良好的縮排、為方便讀者編寫程式碼註釋以及程式碼的整體演示。這使得程式程式碼易於被所有人閱讀和理解，從而使除錯和錯誤解決更容易。此外，正確的編碼風格有助於簡化文件和更新。

編碼規範

編碼風格的做法因組織、作業系統和編碼語言本身而異。

以下編碼元素可以在組織的編碼規範中定義

• 命名約定 - 本節定義如何命名函式、變數、常量和全域性變數。

• 縮排 - 這通常是行首留出的空格，通常是 2-8 個空格或單個製表符。

• 空格 - 通常省略行尾空格。

• 運算子 - 定義編寫數學、賦值和邏輯運算子的規則。例如，賦值運算子“=”應該在其前後留有空格，例如“x = 2”。

• 控制結構 - 編寫 if-then-else、case-switch、while-until 和 for 控制流語句的規則，包括單獨使用和巢狀使用。

• 行長和換行 - 定義一行中應該有多少個字元，通常一行是 80 個字元長。換行定義瞭如果一行太長應該如何換行。

• 函式 - 這定義瞭如何宣告和呼叫函式，包括帶引數和不帶引數的函式。

• 變數 - 這提到了如何宣告和定義不同資料型別的變數。

• 註釋 - 這是重要的編碼元件之一，因為程式碼中包含的註釋描述了程式碼的實際作用以及所有其他相關的描述。本節還有助於為其他開發人員建立幫助文件。

軟體文件

軟體文件是軟體流程的重要組成部分。一份編寫良好的文件提供了必要的軟體流程資訊庫，是一個極好的工具和資訊資源。軟體文件還提供有關如何使用產品的資訊。

一份維護良好的文件應包含以下文件

• 需求文件 - 這份文件是軟體設計人員、開發人員和測試團隊執行各自任務的關鍵工具。這份文件包含目標軟體的所有功能性、非功能性和行為描述。

  這份文件的來源可以是先前儲存的軟體資料、客戶端已執行的軟體、客戶端訪談、問卷調查和研究。通常情況下，它以電子表格或文字處理文件的形式儲存在高階軟體管理團隊中。

  這份文件是待開發軟體的基礎，主要用於驗證和確認階段。大多數測試用例都是直接根據需求文件構建的。

• 軟體設計文件 - 這些文件包含構建軟體所需的所有必要資訊，包括：(a) 高階軟體架構，(b) 軟體設計細節，(c) 資料流圖，(d) 資料庫設計

  這些文件是開發人員實現軟體的資源庫。雖然這些文件沒有提供任何關於如何編寫程式的細節，但它們提供了編碼和實現所需的所有必要資訊。

• 技術文件 - 這些文件由開發人員和實際編碼人員維護。這些文件作為一個整體，代表了關於程式碼的資訊。在編寫程式碼時，程式設計師還會說明程式碼的目標、編寫者、需要使用的位置、程式碼的功能和實現方式、程式碼使用的其他資源等。

  技術文件增強了不同程式設計師之間對同一程式碼的理解。它增強了程式碼的可重用性。它使除錯更容易且可追溯。

  有各種各樣的自動化工具可用，有些工具與程式語言本身一起提供。例如，Java 提供了 JavaDoc 工具來生成程式碼的技術文件。

• 使用者文件 - 這份文件與上述所有文件都不同。所有之前的文件都是為了提供關於軟體及其開發流程的資訊而維護的。但使用者文件解釋了軟體產品應該如何工作以及如何使用它來獲得所需的結果。

  這些文件可能包括軟體安裝過程、操作指南、使用者指南、解除安裝方法以及獲取更多資訊的特殊參考，例如許可證更新等。

軟體實現挑戰

開發團隊在實現軟體時會面臨一些挑戰。其中一些如下所示

• 程式碼重用 - 當今程式語言的程式設計介面非常複雜，並配備了大量的庫函式。但為了降低最終產品的成本，組織管理層更傾向於重用為其他軟體建立的程式碼。程式設計師在相容性檢查和決定重用多少程式碼方面面臨著巨大的問題。

• 版本管理 - 每當向客戶釋出新軟體時，開發人員都必須維護版本和配置相關的文件。這些文件需要高度準確並按時提供。

• 目標主機 - 組織正在開發的軟體程式需要為客戶端的宿主機器設計。但有時，不可能設計出一個在目標機器上執行的軟體。

軟體測試概述

軟體測試是對軟體進行評估，以驗證其是否滿足從使用者和系統規範中收集的需求。測試是在軟體開發生命週期的階段級別或程式程式碼的模組級別進行的。軟體測試包括驗證和確認。

軟體確認

確認是檢查軟體是否滿足使用者需求的過程。它在 SDLC 結束時進行。如果軟體符合其製作的要求，則認為它是有效的。

• 確認確保正在開發的產品符合使用者需求。
• 確認回答了這樣一個問題——“我們開發的產品是否滿足使用者對該軟體的所有需求？”
• 確認強呼叫戶需求。

軟體驗證

驗證是確認軟體是否滿足業務需求，以及是否按照正確的規範和方法開發的過程。

• 驗證確保正在開發的產品符合設計規範。
• 驗證回答了這樣一個問題——“我們是否按照所有設計規範嚴格地開發此產品？”
• 驗證側重於設計和系統規範。

測試的目標是 -

• 錯誤 - 這些是開發人員實際犯下的編碼錯誤。此外，軟體的輸出與預期輸出之間的差異也被認為是錯誤。

• 缺陷 - 當存在錯誤時，就會發生缺陷。缺陷，也稱為 bug，是錯誤的結果，可能導致系統故障。

• 故障 - 故障是指系統無法執行所需任務。當系統中存在缺陷時，就會發生故障。

手動測試與自動化測試

測試既可以手動進行，也可以使用自動化測試工具進行

• 手動測試 - 這種測試是在不借助自動化測試工具的情況下進行的。軟體測試人員為程式碼的不同部分和級別準備測試用例，執行測試並將結果報告給經理。

  手動測試既費時又費資源。測試人員需要確認是否使用了正確的測試用例。大部分測試都涉及手動測試。

• 自動化測試 這種測試是藉助自動化測試工具進行的測試過程。使用自動化測試工具可以克服手動測試的侷限性。

一項測試需要檢查是否可以在 Internet Explorer 中開啟網頁。這可以透過手動測試輕鬆完成。但是，要檢查 Web 伺服器是否能夠承受 100 萬用戶的負載，手動測試是無法實現的。

有一些軟體和硬體工具可以幫助測試人員進行負載測試、壓力測試和迴歸測試。

測試方法

測試可以基於兩種方法進行：

• 功能測試
• 實現測試

當在不考慮實際實現的情況下測試功能時，這被稱為黑盒測試。另一方面被稱為白盒測試，它不僅測試功能，還分析實現方式。

窮舉測試是理想的完美測試方法。測試輸入和輸出值範圍內的每一個可能的取值。如果取值範圍很大，在現實場景中不可能測試每個取值。

黑盒測試

它用於測試程式的功能。它也稱為“行為”測試。在這種情況下，測試人員有一組輸入值和相應的預期結果。提供輸入後，如果輸出與預期結果匹配，則程式測試“透過”，否則出現問題。

在這種測試方法中，程式碼的設計和結構對測試人員是未知的，測試工程師和終端使用者對軟體進行此測試。

黑盒測試技術

• 等價類 - 輸入被劃分為相似的類。如果一個類的元素通過了測試，則假定該類的所有元素都通過了測試。

• 邊界值 - 輸入被劃分為較高和較低端的值。如果這些值通過了測試，則假定介於兩者之間的所有值也可能透過。

• 因果圖 - 在前面兩種方法中，一次只測試一個輸入值。因果圖是一種測試技術，它以系統的方式測試輸入值的組合。

• 配對測試 - 軟體的行為取決於多個引數。在配對測試中，對多個引數的不同值進行配對測試。

• 基於狀態的測試 - 系統在提供輸入時會更改狀態。這些系統根據其狀態和輸入進行測試。

白盒測試

它用於測試程式及其實現，以提高程式碼效率或結構。它也稱為“結構”測試。

在這種測試方法中，程式碼的設計和結構對測試人員是已知的。程式碼的程式設計師對程式碼進行此測試。

以下是一些白盒測試技術

• 控制流測試 - 控制流測試的目的是設定覆蓋所有語句和分支條件的測試用例。分支條件被測試為真和假，以便可以覆蓋所有語句。

• 資料流測試 - 這種測試技術強調覆蓋程式中包含的所有資料變數。它測試變數的宣告和定義位置以及使用或更改的位置。

測試級別

測試本身可以在 SDLC 的各個級別定義。測試過程與軟體開發並行執行。在進入下一階段之前，需要對一個階段進行測試、驗證和確認。

單獨進行測試只是為了確保軟體中沒有隱藏的錯誤或問題。軟體在各個級別進行測試 -

單元測試

在編碼過程中，程式設計師會對程式的單元進行一些測試，以瞭解它是否沒有錯誤。測試是在白盒測試方法下進行的。單元測試幫助開發人員確定程式的各個單元是否按要求工作並且沒有錯誤。

整合測試

即使軟體的單元單獨工作良好，也需要找出如果將這些單元整合在一起是否也能正常工作，例如引數傳遞和資料更新等。

系統測試

軟體被編譯成產品，然後作為一個整體進行測試。這可以透過以下一項或多項測試來完成

• 功能測試 - 根據需求測試軟體的所有功能。

• 效能測試 - 此測試證明軟體的效率。它測試軟體執行所需任務的效率和平均時間。效能測試是透過負載測試和壓力測試來完成的，其中軟體在各種環境條件下承受高使用者和資料負載。

• 安全性和可移植性 - 當軟體旨在在各種平臺上執行並被多人訪問時，會進行這些測試。

驗收測試

當軟體準備交付給客戶時，它必須經過最後的測試階段，在該階段中，它將針對使用者互動和響應進行測試。這很重要，因為即使軟體滿足所有使用者需求，如果使用者不喜歡其外觀或工作方式，也可能會被拒絕。

• α測試 - 開發團隊本身透過在工作環境中使用系統來執行 α 測試。他們試圖找出使用者對軟體中某些操作的反應以及系統應如何響應輸入。

• β測試 - 在軟體內部測試後，將其交給使用者，僅出於測試目的在其生產環境中使用。這還不是交付的產品。開發人員期望使用者在此階段會發現一些微小的錯誤，而這些錯誤之前被忽略了。

迴歸測試

每當軟體產品使用新程式碼、功能或功能進行更新時，都會對其進行徹底測試，以檢測新增的程式碼是否產生任何負面影響。這稱為迴歸測試。

測試文件

測試文件在不同階段準備 -

測試前

測試從生成測試用例開始。需要參考以下文件 -

• SRS 文件 - 功能需求文件

• 測試策略文件 - 描述在釋出產品之前應進行多長時間的測試。

• 測試策略文件 - 本文件詳細說明了測試團隊、責任矩陣以及測試經理和測試工程師的權利/責任。

• 可追溯性矩陣文件 - 這是SDLC文件，與需求收集過程相關。隨著新需求的到來，它們將新增到此矩陣中。這些矩陣幫助測試人員瞭解需求的來源。它們可以向前和向後追溯。

測試期間

測試開始和進行期間可能需要以下文件

• 測試用例文件 - 此文件包含需要執行的測試列表。它包括單元測試計劃、整合測試計劃、系統測試計劃和驗收測試計劃。

• 測試描述 - 此文件詳細描述了所有測試用例和執行它們的程式。

• 測試用例報告 - 此文件包含測試結果的測試用例報告。

• 測試日誌 - 此文件包含每個測試用例報告的測試日誌。

測試後

測試後可能會生成以下文件

• 測試總結 - 此測試總結是對所有測試報告和日誌的綜合分析。它總結並得出軟體是否準備好釋出的結論。如果軟體準備好釋出，則在版本控制系統下發布。

測試與質量控制、質量保證和審計

我們需要理解軟體測試不同於軟體質量保證、軟體質量控制和軟體審計。

• 軟體質量保證 - 這些是軟體開發過程監控手段，透過它可以確保所有措施都按照組織的標準執行。進行此監控是為了確保遵循適當的軟體開發方法。

• 軟體質量控制 - 這是一個維護軟體產品質量的系統。它可能包括軟體產品的功能和非功能方面，這增強了組織的商譽。該系統確保客戶獲得滿足其需求的優質產品，並且產品被認證為“適合使用”。

• 軟體審計 - 這是對組織用於開發軟體的程式的審查。一個獨立於開發團隊的審計團隊檢查軟體過程、程式、需求和SDLC的其他方面。軟體審計的目的是檢查軟體及其開發過程是否都符合標準、規則和法規。

軟體維護概述

軟體維護現在已被廣泛接受為SDLC的一部分。它代表軟體產品交付後進行的所有修改和更新。需要進行修改的原因有很多，其中一些簡要介紹如下

• 市場環境 - 隨著時間的推移而變化的政策，例如稅收和新引入的約束，例如如何維護簿記，可能會觸發修改的需求。

• 客戶需求 - 隨著時間的推移，客戶可能會要求軟體提供新的功能。

• 主機修改 - 如果目標主機的任何硬體和/或平臺（例如作業系統）發生變化，則需要更改軟體以保持適應性。

• 組織變化 - 如果客戶方面有任何業務層面的變化，例如組織規模縮減、收購另一家公司、組織涉足新業務，則可能需要修改原始軟體。

維護型別

在軟體生命週期中，維護型別可能會根據其性質而有所不同。它可能只是某些使用者發現的錯誤的例行維護任務，也可能根據維護規模或性質本身就是一個大型事件。以下是根據其特徵的一些維護型別

• 糾正性維護 - 這包括為了糾正或修復問題而進行的修改和更新，這些問題要麼由使用者發現，要麼由使用者錯誤報告得出結論。

• 適應性維護 - 這包括應用的修改和更新，以使軟體產品保持最新狀態，並適應不斷變化的技術和商業環境。

• 完善性維護 - 這包括為了使軟體在較長時間內保持可用而進行的修改和更新。它包括新功能、改進軟體的新使用者需求以及提高其可靠性和效能。

• 預防性維護 - 這包括進行修改和更新以防止軟體的未來問題。其目的是解決目前並不重要但將來可能導致嚴重問題的問題。

維護成本

報告表明，維護成本很高。一項關於估計軟體維護成本的研究發現，維護成本高達整個軟體過程週期的67%。

平均而言，軟體維護成本超過所有SDLC階段的50%。有各種因素導致維護成本居高不下，例如

影響維護成本的現實因素

• 任何軟體的標準使用壽命被認為最多為10到15年。
• 旨在在記憶體和儲存容量較小的慢速機器上執行的較舊軟體無法在現代硬體上的新興增強型軟體面前保持競爭力。
• 隨著技術的進步，維護舊軟體的成本變得很高。
• 大多數維護工程師都是新手，並使用反覆試驗的方法來糾正問題。
• 通常，所做的更改很容易損害軟體的原始結構，從而使任何後續更改都變得困難。
• 更改通常沒有記錄，這可能會在將來導致更多衝突。

影響維護成本的軟體端因素

• 軟體程式的結構
• 程式語言
• 對外部環境的依賴
• 員工的可靠性和可用性

維護活動

IEEE為順序維護過程活動提供了一個框架。它可以以迭代方式使用，並且可以擴充套件，以便可以包含自定義專案和過程。

這些活動與以下每個階段相輔相成

• 識別與追蹤 - 它涉及與識別修改或維護需求相關的活動。它由使用者生成，系統本身也可能透過日誌或錯誤訊息報告。在這裡，維護型別也被分類。

• 分析 - 分析修改對系統的影響，包括安全隱患。如果可能的影響嚴重，則尋找替代方案。然後將一組所需的修改具體化為需求規範。分析修改/維護的成本並得出估計。

• 設計 - 根據上一階段設定的需求規範，設計需要替換或修改的新模組。建立測試用例以進行驗證。

• 實現 - 在設計步驟中建立的結構化設計的幫助下對新模組進行編碼。每個程式設計師都應該並行進行單元測試。

• 系統測試 - 在新建立的模組之間進行整合測試。還在新模組和系統之間進行整合測試。最後，按照迴歸測試程式對整個系統進行測試。

• 驗收測試 - 在內部測試系統後，在使用者的幫助下對其進行驗收測試。如果在此狀態下，使用者抱怨某些問題，則會解決這些問題或記錄下來以便在下次迭代中解決。

• 交付 - 驗收測試後，系統將透過小型更新包或系統的全新安裝部署到整個組織。軟體交付後，最終測試將在客戶端進行。

  如果需要，除了使用者手冊的紙質副本外，還將提供培訓設施。

• 維護管理 - 配置管理是系統維護的重要組成部分。它藉助版本控制工具來控制版本、半版本或補丁管理。

軟體再工程

當我們需要更新軟體以使其保持在當前市場水平，而又不影響其功能時，這稱為軟體再工程。這是一個徹底的過程，其中軟體的設計被更改並且程式被重寫。

遺留軟體無法與市場上最新的技術保持同步。隨著硬體的過時，軟體的更新變得令人頭疼。即使軟體隨著時間的推移而老化，其功能也不會消失。

例如，Unix 最初是用匯編語言開發的。當 C 語言出現時，Unix 被用 C 語言重新設計，因為用匯編語言工作很困難。

除此之外，有時程式設計師會注意到軟體的某些部分比其他部分需要更多的維護，並且它們也需要再工程。

再工程過程

• 決定要再工程什麼。是整個軟體還是一部分？
• 執行反向工程，以獲得現有軟體的規範。
• 如有必要，重構程式。例如，將面向函式的程式更改為面向物件的程式。
• 根據需要重構資料。
• 應用正向工程概念以獲得再工程的軟體。

軟體再工程中使用了一些重要的術語

反向工程

這是一個透過徹底分析、理解現有系統來實現系統規範的過程。這個過程可以看作是反向SDLC模型，即我們試圖透過分析較低的抽象級別來獲得較高的抽象級別。

現有系統是先前實現的設計，我們對其一無所知。然後，設計人員透過檢視程式碼並嘗試獲取設計來進行反向工程。有了設計，他們試圖得出規範。因此，從程式碼反向到系統規範。

程式重構

這是一個重構和重建現有軟體的過程。它完全是關於重新排列原始碼，無論是在相同的程式語言中還是從一種程式語言到另一種程式語言。重構可以包括原始碼重構和資料重構，或者兩者兼而有之。

重構不會影響軟體的功能，但會提高可靠性和可維護性。可以更改或更新經常導致錯誤的程式元件。

可以透過重構來消除軟體對過時硬體平臺的依賴性。

正向工程

正向工程是從現有規範中獲取所需軟體的過程，這些規範是透過反向工程獲得的。它假設過去已經完成了一些軟體工程工作。

前向工程與軟體工程過程相同，只有一點不同——它總是在逆向工程之後進行。

元件可重用性

元件是軟體程式程式碼的一部分，它在系統中執行獨立的任務。它可以是一個小模組或子系統本身。

示例

網路上使用的登入過程可以被認為是元件，軟體中的列印系統可以被視為軟體的一個元件。

元件具有較高的功能內聚性和較低的耦合率，即它們獨立工作，可以執行任務而無需依賴其他模組。

在面向物件程式設計中，物件的設計非常具體地針對它們關注的問題，並且很少有機會在其他軟體中使用。

在模組化程式設計中，模組的編碼是為了執行特定任務，這些任務可以在許多其他軟體程式中使用。

有一個全新的垂直領域，它基於軟體元件的重用，被稱為基於元件的軟體工程 (CBSE)。

重用可以在不同的層次上進行

• 應用級 - 將整個應用程式用作新軟體的子系統。

• 元件級 - 使用應用程式的子系統。

• 模組級 - 重用功能模組。

  軟體元件提供介面，可用於建立不同元件之間的通訊。

重用過程

可以採用兩種方法：保持需求相同並調整元件，或者保持元件相同並修改需求。

• 需求規範 - 使用現有系統、使用者輸入或兩者兼而有之，指定軟體產品必須符合的功能和非功能需求。

• 設計 - 這也是標準 SDLC 過程步驟，其中需求以軟體術語定義。建立整個系統及其子系統的基本架構。

• 指定元件 - 透過研究軟體設計，設計人員將整個系統細分為更小的元件或子系統。一個完整的軟體設計變成了一個龐大的元件集合共同工作。

• 搜尋合適的元件 - 設計人員參考軟體元件庫，根據功能和預期的軟體需求搜尋匹配的元件。

• 整合元件 - 將所有匹配的元件打包在一起，以將其塑造成完整的軟體。

軟體案例工具概述

CASE 代表Computer Aided Software Engineering（計算機輔助軟體工程）。這意味著在各種自動化軟體工具的幫助下開發和維護軟體專案。

CASE 工具

CASE 工具是一組軟體應用程式，用於自動化 SDLC 活動。軟體專案經理、分析師和工程師使用 CASE 工具來開發軟體系統。

有許多 CASE 工具可用於簡化軟體開發生命週期的各個階段，例如分析工具、設計工具、專案管理工具、資料庫管理工具、文件工具等等。

使用 CASE 工具可以加快專案開發以產生預期結果，並有助於在繼續進行軟體開發的下一階段之前發現缺陷。

CASE 工具的組成部分

根據在特定 SDLC 階段的使用，CASE 工具大致可以分為以下幾部分

• 中央儲存庫 - CASE 工具需要一箇中央儲存庫，它可以作為常見、整合和一致資訊的來源。中央儲存庫是一箇中央儲存位置，儲存產品規範、需求文件、相關報告和圖表以及其他關於管理的有用資訊。中央儲存庫也用作資料字典。

  

• 上層 CASE 工具 - 上層 CASE 工具用於 SDLC 的規劃、分析和設計階段。

• 下層 CASE 工具 - 下層 CASE 工具用於實現、測試和維護。

• 整合 CASE 工具 - 整合 CASE 工具有助於 SDLC 的所有階段，從需求收集到測試和文件。

如果 CASE 工具具有相似的功能、流程活動和與其他工具整合的能力，則可以將其組合在一起。

CASE 工具的範圍

CASE 工具的範圍貫穿整個 SDLC。

CASE 工具型別

現在我們簡要介紹各種 CASE 工具

圖表工具

這些工具用於以圖形形式表示系統元件、資料和各種軟體元件之間的控制流以及系統結構。例如，用於建立最先進流程圖的流程圖製作工具。

流程建模工具

流程建模是一種建立軟體流程模型的方法，該模型用於開發軟體。流程建模工具幫助管理人員選擇流程模型或根據軟體產品的需求對其進行修改。例如，EPF Composer。

專案管理工具

這些工具用於專案規劃、成本和工作量估算、專案排程和資源規劃。管理人員必須嚴格遵守軟體專案管理中提到的每個步驟來執行專案。專案管理工具有助於在整個組織中即時儲存和共享專案資訊。例如，Creative Pro Office、Trac Project、Basecamp。

文件工具

軟體專案中的文件工作始於軟體過程之前，貫穿 SDLC 的所有階段，並在專案完成後完成。

文件工具為技術使用者和終端使用者生成文件。技術使用者主要是開發團隊的內部專業人員，他們參考系統手冊、參考手冊、培訓手冊、安裝手冊等。終端使用者文件描述系統的功能和使用方法，例如使用者手冊。例如，用於文件編制的 Doxygen、DrExplain、Adobe RoboHelp。

分析工具

這些工具有助於收集需求，自動檢查圖表中是否存在任何不一致、不準確之處、資料冗餘或錯誤遺漏。例如，用於需求分析的 Accept 360、Accompa、CaseComplete，用於全面分析的 Visible Analyst。

設計工具

這些工具幫助軟體設計師設計軟體的模組結構，可以使用細化技術將其進一步分解成更小的模組。這些工具提供了每個模組的詳細資訊以及模組之間的互連。例如，Animated Software Design。

配置管理工具

軟體的一個例項在一個版本下發布。配置管理工具處理：

• 版本和修訂管理
• 基線配置管理
• 變更控制管理

CASE 工具透過自動跟蹤、版本管理和釋出管理來幫助實現這一點。例如，Fossil、Git、Accu REV。

變更控制工具

這些工具被認為是配置管理工具的一部分。它們處理在軟體確定基線後或軟體首次釋出後對軟體所做的更改。CASE 工具自動化變更跟蹤、檔案管理、程式碼管理等等。它還有助於執行組織的變更策略。

程式設計工具

這些工具包括程式設計環境，如 IDE（整合開發環境）、內建模組庫和模擬工具。這些工具為構建軟體產品提供了全面的幫助，幷包括模擬和測試功能。例如，用於在 C 中搜索程式碼的 Cscope、Eclipse。

原型工具

軟體原型是預期軟體產品的模擬版本。原型提供了產品的初始外觀和感覺，並模擬了實際產品的某些方面。

原型設計 CASE 工具基本上帶有圖形庫。它們可以建立獨立於硬體的使用者介面和設計。這些工具幫助我們根據現有資訊構建快速原型。此外，它們還提供軟體原型的模擬。例如，Serena prototype composer、Mockup Builder。

Web 開發工具

這些工具有助於設計網頁以及所有相關元素，如表單、文字、指令碼、圖形等等。Web 工具還提供正在開發的內容的即時預覽，以及完成後它會是什麼樣子。例如，Fontello、Adobe Edge Inspect、Foundation 3、Brackets。

質量保證工具

軟體組織中的質量保證是對開發軟體產品的工程過程和方法的監控，以確保符合組織標準的質量。QA 工具包括配置和變更控制工具以及軟體測試工具。例如，SoapTest、AppsWatch、JMeter。

維護工具

軟體維護包括在軟體產品交付後對其進行修改。自動日誌記錄和錯誤報告技術、自動錯誤工單生成和根本原因分析是一些 CASE 工具，這些工具可以幫助軟體組織進行 SDLC 的維護階段。例如，用於缺陷跟蹤的 Bugzilla、HP Quality Center。