您好,登錄后才能下訂單哦!
大家好,我是十一,今天我們就軟件生命周期進行詳細的解說。讓大家整體的認識下軟件的"成長歷程"。
什么是軟件生命周期?
軟件生命周期是軟件從產生到廢棄的整個過程,周期內有問題定義、可行性分析、需求分析、系統設計、編碼、調試和測試、部署/發版、維護升級到廢棄等階段。
那軟件生命周期各個階段都是什么呢?
我們先看張購物圖(為了這張圖我眼睛也是要廢了~)
上圖呢就是一個完整的淘寶定制購物過程圖了,那么購物過程跟咱們軟件又有什么關系呢?整個過程對比《淺聊軟件開發》里的軟件生命周期圖你能一一對應上嗎?
大家先自己想想~(來,閉上眼睛,想一想~)
好啦,我來揭曉答案,大家看看你想的對不對!
首先,為故事找一主人公,暫且叫心心吧,心心定制了需求,然后跟客服溝通是否可做(需求可行性分析),溝通后選擇喜歡的樣式、尺碼等下單,商家拿到訂單后根據訂單要求出設計圖(原型設計),出圖后跟心心溝通看是否是心心想要的(需求確認),得到肯定答復后投入生產(開發),生產完成后內部質檢員檢查(測試),檢查無誤后快遞給心心(上線/發版),心心拿到衣服開始試穿以及查看是否有質量問題(測試),很滿意此次購物,于是給了滿意好評后,訂單關閉,整個購物過程完成。
大家可能會說那支持維護沒體現呀?
那如果心心穿了一周后發現衣服有掉色/圖案一洗就花了等等質量問題呢?是不是就該去找客服了,跟客服溝通后商家會進行處理,換貨/退貨/修復等等,這個就是支持維護啦。
注意哦:購物圖中的“商家根據要求出設計圖樣式” 這個跟軟件流程圖中的設計不是一個東西!
軟件流程圖中的設計:是開發設計,設計要實現產品那么需要用的語言、框架、技術等等;對應購物圖中的商家生產部分,商家生產前需要決定各種用什么布、線、縫制方式、配圖材料/方法等等。
上述整個過程其實跟實際的軟件產品的整個流程比較貼切了。你了解了嗎?我畫了一張完整的軟件流程圖,供大家參考~
下面我們依據上圖來分別介紹各個階段。著重介紹每個階段的概念以及參與者。
需求定義(Ruquest for Proposal):
描述:定義出本次任務都需要做什么,做成什么樣子(比如,買家跟賣家說我要什么樣子的衣服,然后雙方開始協商,最終達成一致意見,這個過程就是需求定義)。
參與者:產品經理,需求,客戶
可行性分析:
描述:由項目組相關成員去研究需求是否可行,能不能做出來(比如:商家拿訂單需求去找設計和工廠,問設計圖形或者樣式能否做出來;問工廠在相應的布料上能不能做出設計圖樣式的衣服,這個過程就是可行性分析)
參與者:產品經理,項目經理,開發,架構師
需求分析/用戶需求(Requirements Analysis):
描述:需求分析其實是在做需求細化,按照任務說明書中的任務內容和指標具體細化各個點,細化到每個框每個按鈕的樣式,輸入輸出等各項值(比如:設計和工廠分別就這個衣服做材料分析,分析出這個衣服需要多少布料,扣子什么樣式、顏色,不同布料具體用多少等等,這個過程叫做需求分析);統一整理編寫成《需求說明書/需求規格說明書》。
參與者:產品經理,項目經理,測試/質量管理員(很多公司把這個統稱為QA),開發,架構師
評審:(從圖中可以看出,各個階段幾乎都需要做評審,在此處統一描述)
描述:評審就是做審查,對這個階段的工作進行審查,看是否偏離或者有遺漏(比如:設計和工廠的各個環節都有相關的審查,審查材料是否合格、設計是否符合規定、按照工人/設計出的材料需求是否足夠或者多余等等,這些審查都是評審);評審一般由相應工作人員來參與
參與者:每個階段的評審一般都是各職能部門內部審核,也可以申請其他相關人員審核,比如需求評審,一般是產品經理、項目經理、測試、開發一起評審;系統設計一般是項目經理、開發評審;測試策略評審一般是測試組內部評審等等
設計(Design):
描述:
架構師根據需求確定產品或者項目的場景、特點,選擇合適的框架,技術使項目實現最優化。在此上將系統進行概要設計,包括系統總體數據結構、數據庫結構、模塊結構以及它們之間的關系等。開發人員根據概要設計對具體模塊進行詳細設計,包括接口參數、參數等。此處設計會形成概要設計文檔和詳細設計文檔。
參與者:項目經理,架構師,開發,測試
編碼(Coding):
描述:開發人員根據詳細設計文檔對系統進行模塊化開發,在確定參數和接口的情況下,根據需求對模塊內部進行方法級別的設計和編碼以及自測,對產品功能進行一一實現
參與者:開發
提測:
描述:開發人員完成一個小迭代/小功能,且完成自測(開發編碼完成后,一般都會自己檢測下),于是向測試部門發起提測,一般以郵件方式或者任務管理工具任務流方式向測試部門通知xxx模塊/功能可以測試
參與者:任務責任人(開發)、測試
測試策略:
描述:測試組長要根據《任務說明書》和《需求說明書》來決定此次測試的思路/類別(功能測試/性能測試/文檔性測試或者幾種組合)、測試方式方法、flag(任務指標,做到什么程度)等。也有很多公司把測試策略作為測試方案中的一部分。
參與者:測試組長/測試leader/自身的測試工程設計師
測試計劃(Testing plan):
描述:測試組長要根據《任務說明書》和《需求說明書》開始編寫《測試計劃》,其中包括人員,軟件硬件資源,測試點,集成順序,進度安排和風險識別等內容。
參與者:測試組長/測試leader
測試方案:
描述:測試方案一般由對需求很熟的高資深的測試工程師設計,測試方案要求根據《需求說明書》上的每個需求點設計出包括需求點簡介,測試思路和詳細測試方法三部分的方案。
參與者:測試工程師
測試設計:
描述:主要是對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的,測試用例需要包括測試項,用例級別,預置條件,操作步驟和預期結果。同樣,測試用例也需要評審。
參與者:相關測試工程師
測試執行(Testing):
描述:
根據測試用例對開發提測部分進行,通過的標記通過,不通過的提交有質量的Bug(問題缺陷)。這里要說下bug,測試對出問題的部分提交bug到相關開發工程師,開發根據問題描述,進行修訂,修訂完成后會將bug流轉給相關測試人員(通過缺陷管理工具分配/郵件通知相關測試人員bug修訂完成,可測),測試需要對bug以及bug相關模塊進行測試回歸。
參與者:相關測試工程師、責任開發工程師
測試報告:
描述:最終測試完成(所有測試用例通過/已掛起)會出測試報告對以上測試進行總結性描述。
參與者:相關測試工程師
部署/發版(Deploy):
描述:經過前面的各個階段,產品已經可以出售或者面見大眾了;由測試進行冒煙測試,冒煙測試通過后配置管理人員進行封版、版本制作(針對產品來說)/部署上線(針對項目應用來說)。
參與人:配置管理人員,測試
支持維護(Production Support):
描述:支持維護類似于我們日常中的售后,主要是對已賣出的產品/已上線的項目進行日常維護。包括糾錯性維護和改進性維護兩個方面。
參與人:支持維護人員/售后工程師
以上就是整個軟件的流程介紹了,內容有點多,但是我希望你能認真的看完,并且加以理解變成你自己的知識。
注意:以上的軟件開發流程只是一個最基本的模板,但是公司內部有自己的組織架構,可根據項目酌情調整。只要適合自己的項目那么就是對的,就是好的。
好了今天的內容到此結束,歡迎進群與我溝通!我們下次再見~
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。