软件工程模型
你在工作中, 軟件的開發(fā)流程是怎樣的? 你是否想過, 除了你當前使用的流程, 還存在其他怎樣的流程? 現(xiàn)在的流程有哪些問題, 又能夠如何解決? 別說, 前輩們已經(jīng)給出了一些項目流程的模型, 既軟件工程. 可以簡單了解一下, 帶動一下我這生了銹的腦子.
在很久以前, 一個軟件的從想法到落地, 還沒有什么可供參考的流程, 基本上就是邊提需求邊開發(fā), 毫無章法. 對于當時的項目來說, 因為規(guī)模不大, 這種方式就已經(jīng) OK 了. 但隨著后面功能越來越復雜, 項目越來越大, 就逐漸暴露出了一些問題, 整個項目開發(fā)流程不可控, 無法進行有效的計劃, 同時項目沒有分工合作, 也不利于大型項目的開發(fā)等等.
為了解決這些問題, 前輩們提出了軟件工程. 一個項目由想法到發(fā)布, 大概可以劃分為這么幾個步驟(這幾個步驟可能并不準確, 我自己想的…):
根據(jù)這些步驟, 發(fā)明了瀑布模型.
瀑布模型
瀑布模型, 顧名思義, 像一個瀑布一樣, 將流程分為若干個階段, 完成一個階段之后, 流向下一個階段. 瀑布模型包括如下幾個階段:
使用瀑布模型來管理軟件之后, 效果立竿見影, 項目的管理流程化了, 同時也可以針對各個階段進行評估, 來估算項目的整體進度.
瀑布模型和裝修有些類似, 先確認需求, 然后進行設計, 最后具體實施. 但是畢竟是兩個不同的領域, 在蓋房子的過程中, 基本不會有需求變更的時候, 而在軟件開發(fā)中, 變更需求簡直就是家常便飯. 而瀑布模型又無法快速的對需求的變更進行響應.
簡單總結(jié)一下瀑布模型的優(yōu)缺點.
優(yōu)點: 可以按照階段進行檢查, 在前一階段無誤后, 全力開啟下一個階段. 同時項目總體進度可控, 可以有計劃的進行.
缺點:
- 難以及時響應需求的變化
- 工作分布不均衡, 前期開發(fā)人員無法參與, 后期又完全靠開發(fā)測試
- 任何一環(huán)的出現(xiàn)問題導致時間過長, 會導致連鎖反應, 后面環(huán)節(jié)的時間都要壓縮.
雖然瀑布模型存在這一些缺點, 但也比之前的游擊隊要好的多了.
快速原型模型
在需求分析階段, 為了進行需求的確認, 可以簡單快速的搭一個demo, 用戶需求變化之后, 可以快速進行響應并將其添加到軟件中. 當然, 為了追求速度是需要犧牲質(zhì)量的.
在需求確認之后, 對于原型可以選擇丟棄, 因為他已經(jīng)完成了它的使命.
不過建造原型不一定需要開發(fā), 對于一些界面應用, 有簡單可行的工具, 進行簡單的拖拽就能實現(xiàn)簡單的界面與交互, 同樣可以達到確認需求的目的.
小瀑布模型
瀑布模型因為周期比較長, 所以無法及時響應需求的變動, 如果將一個大瀑布拆分成多個小瀑布, 就可以分階段交付.
那么問題來了, 如果將一個瀑布拆分成多個呢?
其中每個小瀑布都包含瀑布模型的完整流程.
敏捷開發(fā)
以上幾種模型, 都是基于瀑布模型進行的改進, 傳統(tǒng)的瀑布模型周期長, 難以響應變化, 針對這些問題, 提出了敏捷開發(fā).
你一定聽說過一個東西: 敏捷宣言. 就是下面這個:
鏈接: http://agilemanifesto.org/
敏捷宣言中并沒有給出具體的實施步驟, 只是提出了一些思想.
不難發(fā)現(xiàn), 敏捷宣言中右側(cè)的內(nèi)容, 都是傳統(tǒng)的瀑布模型中強調(diào)的內(nèi)容. 其大概就是通過不斷的快速交付軟件, 收集新的需求, 不斷進行完善. 其強調(diào)擁抱需求的變化.
打個比方, 我們開始一個新的項目, 按照傳統(tǒng)的瀑布模型, 在開發(fā)過程中是不會輕易修改需求的, 而這明顯違背了敏捷開發(fā)的價值觀: 客戶合作高于合同談判, 響應變化高于遵循計劃.
而為了達到以上的目的, 也提出了一些方法.
1. 需求就是一個小故事
沒有詳細的需求文檔, 只是提出: 我想要一個 xxx. 開發(fā)人員再開發(fā)過程中, 不斷進行完善并確認細節(jié). 如此就減少了大量需求文檔的編寫, 但同時, 也會造成需求理解錯誤, 最終效果差別較大.
可以將所有的故事放到一個列表中, 并標明狀態(tài)(待辦/處理中/已完成等), 開發(fā)人員根據(jù)優(yōu)先級去完成列表中的任務即可. 同時也可以追蹤哪些任務提了很久都沒做, 已經(jīng)不需要可以直接去掉.
2. 定期重構(gòu)
因為每次只做部分需求, 所以無法在一開始就將整體架構(gòu)完善, 迭代次數(shù)一多, 架構(gòu)就跟不上業(yè)務了, 所以要進行重構(gòu)來滿足新的業(yè)務.
3. 自動化測試
通過單元測試, 集成測試等, 在開發(fā)的過程中完成部分測試的任務.
4. 每日站立會議
每天上班時, 先一起開一個站立會議, 目的是同步一下項目進度, 是否需要他人支持, 是否遇到困難等.
5. 小版本發(fā)布
每個版本只添加一些小功能, 就可以快速完成并發(fā)布. 發(fā)布多個版本之后達到一個較復雜的功能. 可以多次發(fā)布版本, 及時對業(yè)務進行調(diào)整.
等等
那么敏捷開發(fā)和上面簡化需求持續(xù)迭代的小瀑布模型有什么區(qū)別么? 我是這樣理解的, 在瀑布模型中, 需要經(jīng)過整個從提出問題到測試發(fā)布的過程. 而敏捷開發(fā)沒有這些繁瑣的流程, 開發(fā)人員直接拿到一個需求的想法, 就可以開始編碼發(fā)布了.
敏捷開發(fā)也有一些提出的具體流程, 比如極限編程/Scrum等(個人覺得極限編程的想法有點扯). 但我覺得主要還是借鑒其思想.
以上幾種開發(fā)流程, 其實就是2種, 傳統(tǒng)的瀑布模型, 和較新的敏捷開發(fā). 瀑布模型基本上就是流水線作業(yè), 項目進度較為直觀, 基本上是從傳統(tǒng)工業(yè)上面借鑒的思路. 而敏捷開發(fā)給我的感覺更適合軟件行業(yè)一些. 倒也不是說那個好那個不好, 甭管黑貓白貓, 能抓到耗子就是好貓. 在具體實施中, 可以將多個模型相結(jié)合, 相互借鑒想法, 打造出適合自己的流程.
簡單了解一下, 只聽說過敏捷開發(fā), 但沒有具體了解過.
總結(jié)
- 上一篇： 求最大连续子集
- 下一篇： java gui 单选_java GUI