單元 1.2.3 軟體開發
這是一個眾所周知的模型，它由一系列階段組成，每個階段只有在完成前一個階段後才能開始。如果需要，也可以返回模型中的上一步。所涉及的階段是
- 問題定義
- 可行性研究
- 分析 (包括系統調查/資訊收集)
- 設計
- 評估
- 安裝
- 維護
在分析人員開始設計和構建系統之前，必須仔細識別問題。這是因為
- 客戶可能不知道計算機系統的功能。
- 分析人員可能不知道問題領域的來龍去脈。
- 它確保解決的是正確的問題。
- 它確保建立的解決方案滿足客戶的需求。
- 它將確定專案的結束時間，從而確定付款時間。
這項研究使用 TELOS（技術、經濟、法律、運營和進度安排）來確保專案能夠完成
- 技術 - 是否有技術可用於解決問題？
- 經濟 - 專案在經濟上可行嗎？
- 法律 - 問題是否可以在法律範圍內解決？
- 運營 - 是否有足夠的人員來執行新系統，這對客戶有何影響？
- 進度安排 - 問題是否可以在時間限制內解決？
其他因素可能包括社會或環境影響。
這項研究將產生一份可行性報告，其中詳細說明了使用者需求、現有軟體和硬體、當前系統範圍、主要資料處理功能和流程、成本效益分析以及結論和建議。
分析包括理解當前系統、新系統的需求、提出新系統和新系統的規格。
這種技術包括儘可能多地瞭解當前系統的功能。它可以透過多種方式完成
- 員工和管理層的問卷調查
- 一種快速收集方法，因為可以一次發放許多問卷。它需要問題簡單，因為無法解釋。
- 員工和管理層的訪談
- 在這裡可以詢問更詳細的問題，並且提出的問題可以基於之前對問卷的回答。
- 程式觀察
- 觀察工作場所的人可以提供有關係統功能和遇到的問題的有用資訊。
- 檔案研究
- 這些可能包括手冊/指南、行為準則、紙質檔案、發票、收據，甚至牆上的便籤！
- 資料
- 必須儲存哪些資料？
- 這些資料是如何收集的？
- 自動 - 條形碼、OMR 等
- 新資料採集表格/方法的設計
- 輸入
- 資料是如何輸入系統的？
- 手動輸入，還是使用自動化方法？
- 資料是如何輸入系統的？
- 處理
- 必須對資料進行哪些處理？
必須為新系統設計所有輸入、處理和輸出。這可能包括螢幕設計和列印的報告。它需要定義系統的型別，例如批處理系統或即時系統。還必須考慮安裝的軟體，以及 HCI（人機互動）。
這將產生一份設計規格，其中詳細說明了系統的功能，並可能包括其演算法、設計、屏幕布局或資料儲存方法。
包括系統的全面測試部分，使用不同的方法
- Alpha 測試 - 使用開發公司內部沒有參與該專案的工作人員，旨在查詢系統中的錯誤。
- Beta 測試 - 使用公司外部的特定使用者組在不同的環境中測試軟體。
- 破壞性測試 - 一種試圖以儘可能多的方式破壞程式的測試形式。
- 驗收測試 - 使用者根據需求規格對程式進行測試。一旦測試成功，專案就可以簽署。
這涵蓋了系統將如何安裝。這包括任何硬體購買、員工培訓、資料檔案建立、轉換方法和未來維護。
有兩種型別 - 使用者和技術。
- 使用者 - 關於如何作業系統的指南，提供錯誤訊息和故障排除的描述。
- 技術 - 用於以後的維護，可能包括程式碼和模組的描述以及演算法。
主要有三種轉換/轉換方法
- 分階段 - 將系統的一部分更改為新系統，而其餘部分保持在舊系統上。如果出現任何問題，它們將被限制，因此不會影響系統關鍵部分。
- 並行 - 舊系統和新系統並行執行，使用即時資料，以便可以比較兩個系統的效率。最終，舊系統可以完全下線。
- 直接 - 在一個特定的時間點，舊系統關閉，新系統上線。最便宜、最簡單，但可能是最危險的方法，因為如果系統出現故障，將沒有備份。
3 種主要型別
- 適應性 - 對系統進行改進以滿足變化，例如新的增值稅門檻。
- 完善性 - 改進以滿足使用者需求，例如移動按鈕或選單。
- 糾正性 - 修復錯誤。
.png)
螺旋模型圍繞著風險處理。它使用四個階段，每個階段構成螺旋的四分之一，螺旋迴圈。
- 確定目標 - 第一個階段根據最大潛在風險確定此螺旋迭代的目標。
- 識別和解決風險 - 識別可能的風險並考慮替代方案。如果風險被認為過高，專案可能會停止。
- 開發和測試 - 開發和測試正在處理的專案元件。
- 規劃下一次迭代 - 此階段計劃下一次螺旋迭代的內容。
螺旋模型能夠很好地處理風險，適合大型專案，但需要熟練的風險評估員和管理人員，這可能很昂貴。
此模型使用原型系統，這些系統缺乏最終系統的全部功能。這可能包括螢幕模擬或部分工作的系統。這可以向用戶展示以獲得反饋和評論，並在此基礎上進行改進。每個構建-評估週期都會新增改進，直到產品完成，最終原型成為最終系統。它非常適合那些一開始需求不明確的專案，並且由於原型化的反饋迴圈，很可能導致產品具有出色的可用性。但是，它不適合建立高效的程式碼，並且它確實需要終端使用者的參與。
敏捷方法是一組方法，能夠很好地應對不斷變化的需求。軟體以迭代的方式生成，並且可以在每次迭代中新增功能。它通常被描述為一套價值觀和原則，這些價值觀和原則決定了程式碼的生成方式。它提倡適應性規劃、演化開發、早期交付和持續改進，並鼓勵對變化做出快速靈活的響應。通常，敏捷將包括一個“Scrum 團隊”，他們在“衝刺”中開發軟體。在每次迭代之後，使用者將在每日站立會議上評估軟體。但是，需要注意的是，敏捷是一種非常靈活的方法，因此這些共同特徵是可選的。
敏捷開發的一種形式。XP 重視編碼 - 一名代表客戶成為團隊的一部分，並提供“使用者故事”（需求）、設計測試並回答程式設計師的問題。迭代時間短，它會生成“工作版本” - 該程式碼將在最終產品中使用。在程式設計時必須確定使用者故事的順序，程式設計師成對編寫程式碼（結對程式設計）。一名程式設計師編寫程式碼，而另一名程式設計師評估編寫的程式碼，他們定期交換角色。程式碼被重構以使其更有效，並且在開發過程中使用了一套明確的標準。程式設計師每週工作時間不超過 40 小時。最終程式碼質量可能非常高，但是此方法需要一個緊密合作的團隊，並且客戶必須不斷地派出一名員工加入開發人員。
| 模型 | 原則 | 優勢 | 劣勢 |
|---|---|---|---|
|
瀑布模型 |
|
|
|
| 螺旋模型 |
|
|
|
| 敏捷 |
|
|
|
| RAD |
|
|
|
| XP |
|
|
|
瀑布生命週期是為一種程式設計方法而命名的。解釋遵循這種程式設計方法的程式設計師的優勢。
答案
瀑布模型具有迴圈（1）模型，可以在需要時回溯（1）到以前的階段。有定義的階段，因此可以提供截止日期（1），並且每個程式設計師都可以處理定義的階段（1）。
瀑布生命週期的替代方案是快速應用程式開發（RAD）。描述為什麼 RAD 更適合由兩名程式設計師組成的的小團隊。
答案
RAD 強調立即開發（1）而不是規劃（1）。需求被調整，原型被使用（1）。這更適合小型團隊，因為需要遵循的繁文縟節較少（1）。