重拾軟體工程—(2)軟體過程
在說軟體過程之前首先要知道軟體的生命週期,我們已經知道了軟體不僅僅是程式碼,還包括很多其他步驟,比如設計、維護等等。所以軟體的生命週期便是指軟體從設計到投入使用再到被淘汰的整個過程。
而這個過程往往是漫長的,所以在這漫長的過程中要保證軟體正常的執行,迭代,這就需要一定的整體框架和流程來保證(不是指程式框架哈),這就被稱作軟體過程。
軟體過程提高了整個軟體工程活動的穩定性、組織性和可控性。
任何完整地軟體工程活動都有以下幾個基本的活動步驟,這也是軟體過程的通用框架:
1、溝通:專案啟動、需求獲取
2、策劃:專案估算、資源需求、進度計劃
3、建模:建立模型、進行分析和設計
4、構建:編碼和測試
5、部署:軟體交付、支援和反饋
介紹了通用過程框架,接下來介紹幾個常用的軟體過程模型
瀑布模型
最常用也是最基礎的軟體過程模型,因為簡單所以適用的場景也比較侷限,常用於甲方可靠(或自己人),需求確定的情況下。因為這樣可以直接按照線性工作方式一步完成。
基本步驟:溝通->策劃->建模(分析)->建模(設計)->構建(編碼)->構建(測試)->執行與維護
優點
- 規範、易操作、簡單、易用;
- 為專案提供了按階段劃分的檢查點,專案管理比較規範;
缺點
- 需求難確定,變更難管理;
- 任務線性依賴,等待時間長;
- 成功晚,增加開發風險;
- 文件多,增加工作量;
- 錯誤發現晚,後果嚴重;
增量模型
顧名思義,該模型將待開發的軟體系統模組化,每個模組被稱為一個增量,從而可以分批次地設計、開發增量。本質就是以迭代的方式運用瀑布模型。
應用舉例
開發一個類似於WORD的文書處理軟體
增量1:提供基本的文件管理、編輯和文件生產功能;
增量2:提供高階的文件編輯功能;
增量3:實現拼寫和語法檢查功能;
增量4:完成高階的文件排版功能;
優點
- 對使用者需求響應快速:使用者看到早期版本提出的建議可在後續增量中增加;
- 人員分配靈活:開發人員有限,可採用此模型;
- 可規避技術風險:不確定的功能可放在後續開發;
問題
- 每個附件增量併入現有軟體時,不能破壞原來已構造好的東西;
- 加入新增量是應簡單、方便——該類軟體的體系結構應當是開放的;
- 仍然無法處理需求發生變更的情況;
- 管理人員應有足夠的技術能力來協調好各增量之間的關係;
演化過程模型——原型開發
現實開發過程中,使用者需求往往是不確定的,或者使用者往往都不清楚自己想要的軟體有什麼功能,長啥樣。這時為了讓使用者能夠確實地有所體驗,就需要快速地開發一個所謂的“樣品”展示給使用者,這也就演變出了原型模型。
目前原型模型在移動端的開發中很常用,因為移動端注重使用者互動,複雜邏輯相對較少。因此也演變出了一系列強大的原型設計工具,比如axure、Demoo、墨刀等,都能在極短的時間裡面設計出可互動的產品原型。
優點
- 快速開發出可以演示的系統,方便與客戶溝通;
- 採用迭代技術可以使開發者逐步理清客戶的需求;
問題
- 只關係表面,不關心內在;
- 使用者可能混淆原型系統和最終系統,可能因為技術原因,最終系統跟展示的不能完全相同;
演化過程模型——螺旋模型
此模型重點在風險分析階段,適用於大型、複雜的系統,結合了原型的迭代性質和瀑布模型的系統性和可控性。
特點
模型沿著螺線旋轉,四個象限表達四個方面的活動:
* 制定計劃:確定目標,選擇實施方案;
* 風險分析:分析所選方案,考慮如何識別和排除風險;
* 實施工程:實施軟體開發;
* 客戶評估:評價開發工作,提供修改建議;
出發點
及時識別和分析風險,並採取適當措施以消除或減少風險帶來的災害;
舉例
- 第1圈:開發出產品的規格說明;
- 第2圈:開發產品的原型系統;
- 第3-n圈:不斷的迭代,開發不同的軟體版本;
- 根據每圈交付後使用者的反饋來調整預算、進度、迭代的次數。
優點
- 是一種風險驅動型的過程模型;
- 採用迴圈方式逐步加深系統定義和實現的深度;
- 始終保持可操作性,直到軟體結束;
問題
- 合同制專案(外部專案)的客戶較難接受該模型依賴於風險評估專家,如未準確識別或管理較大風險,肯定會出問題。
- 所以適用於大規模軟體專案,特別是內部專案。
噴泉模型
噴泉模型是一種以使用者需求為動力,以物件為驅動的模型,主要用於描述物件導向的軟體開發過程。該模型認為軟體開發過程自下而上週期的各階段是相互重疊和多次反覆的,就像水噴上去又可以落下來,類似一個噴泉。各個開發階段沒有特定的次序要求,並且可以互動進行,可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。
優點
可以提供軟體專案開發效率,節省開發時間,適用於物件導向的軟體開發過程。
缺點
- 各個開發階段是重疊的,因此開發過程中需要大量的開發人員,不利於專案的管理;
- 模型要求嚴格的管理文件,使得稽核的難度加大;
能力成熟度模型(CMM)
是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。
CMM的核心是把軟體開發視為一個過程,並根據這一原則對軟體開發和維護進行過程監控和研究,以使其更加科學化、標準化、使企業能更好地實現商業目標。
迄今為止,學術界和工業界公認的有關軟體工程的最好的軟體過程
相關文章
- 軟體工程-過程模型軟體工程模型
- 軟體工程-五 過程軟體工程
- 重拾軟體工程—(3)需求分析軟體工程
- 學習高校課程-軟體工程-軟體工程(ch2)軟體工程
- 軟體工程之開發過程軟體工程
- 個體軟體過程
- 軟體過程與管理實驗2
- 《軟體工程》課程總結軟體工程
- 軟體工程課程設計軟體工程
- 【軟體測試】軟體及其開發過程
- 軟體工程作業2軟體工程
- 軟體、軟體危機、軟體工程 (轉)軟體工程
- [個體軟體過程]之過程改進 (轉)
- 軟體工程 第一章 軟體與軟體工程軟體工程
- 軟體工程——軟體測試軟體工程
- 軟體工程——軟體計劃軟體工程
- 軟體工程-軟體工程層狀模型(EHM)軟體工程模型
- 軟體工程課程小作業軟體工程
- 軟體工程 .軟體工程
- 軟體工程軟體工程
- 軟體專案管理 4.1.軟體需求管理過程專案管理
- 個體軟體過程(Personal Software Process,PSP(續2) (轉)
- 我心中的軟體過程
- 【軟考之軟體過程模型總結】模型
- 《軟體工程》課程設計總結軟體工程
- 軟體工程博士講師:軟體工程是一個學習過程,程式碼只是學習的副產品軟體工程
- 軟體工程—GitHub軟體工程Github
- 軟體工程1軟體工程
- 軟體工程4.21軟體工程
- 軟體工程5.7軟體工程
- 軟體工程4.28軟體工程
- 軟體工程5.9軟體工程
- 軟體工程5.8軟體工程
- 軟體工程4.27軟體工程
- 軟體工程5.13軟體工程
- 軟體工程6軟體工程
- 軟體測試面試過程解析面試
- 敏捷軟體過程的侷限性敏捷