> ==>發信人: EightCloud.bbs@BirdNest.twbbs.org (嵐雲), 信區: programming
> : 現代的軟工當然是新時代的軟體發展方法, 是讓這一代的軟體
> : 從業人員能在現代的環境下增加生產力與競爭力的. 然道, CMMI
> : 不是工程技術而是像古代的禮教規矩嗎 ? 禮教終被忽視, 是因為
> : 太多的繁文褥節對做事的效果不管用. 軟工不會是禮教吧 !
> 藉著這個 topic 講一下 CMMI...
> CMMI 只是算是一個流程的目標, 或是評鑑流程的方式..
> 並沒有定義流程的內容.
Capability Maturity Model Integration
能力與成熟度模型整合, 望文生義的說就是提出 "模型" 來供量測與改進
之用. 說的應該是如何評量一個軟體團隊已具有的解決問題能力與熟練度.
> CMMI 並沒有說要使用 waterfall, 或是 iterative...
> 比較相對的, 是
Waterfall 是老式的軟工, 講究的是如瀑布之水勢傾瀉而下, 不可逆流回
溯. 這是認為軟體開發的很多痛苦如時間拖延, 人力增加都是因為反反覆
覆搞不定真正的需求與規格, 開發過程逆流反覆的通病所引起.
這種概念在過去政府機關電腦化時, 引發的就是 "首長帶頭", "強勢推動"
以革命軍的陣勢 "排除障礙". 可能後果之一就真的是造了一隻牛頭套到馬
身上. 在商業上, 就是片面訂約用鈔票堆高逆流障礙, 過期不得再改, 買
方當然是覺得坐上賊船, 恨得牙癢癢的.
後來的改進一招就是 Rapid Prototype , 讓客戶看 "樣品", 先把表面工
夫弄好, 但最後還是片面訂約, 議定後不得反悔.
在還沒有套裝軟體大量普及的時代, 軟體業是賣方市場, 所以上述兩招算
是 "正解". 套裝算不上 Total Solution , 只是逼出一片 "價廉物美"
的零散領域. 之所以軟工人員普遍痛恨 PC 硬體業的根本原因, 就是 PC
硬體助長了 套裝軟體 的發展.
90 年代以後, 印度軟體代工開始成長, 主要的就是 "能配合買方".
買方有專業的人定需求, 開發方又有夠能力與熟練的團隊能切題及時做答
案, 事情也就不再反反覆覆了. 剩下的就是找對 "團隊" , CMMI 剛好就是
能評估出合等級需求的團隊, 不同的等級就是不同的服務價碼, 也不用相
互防來防去, 砍來砍去的.
Agile Method , eXtreme Programming 應該是被印度大軍壓迫以後,
往日高高在上的賣方, 想到 "軟工桎梏下" 的苦難日子即將來臨, 而惱人
的印度神牛低價競爭又不能不面對, 總算在 CMMI 之後找出一個可以結合
又可以匹敵的方法.
現代的軟工當然不會是那種 "有進無退瀑布法" 的 "禮教".
> (
> 對我的經驗,
> 軟體跟其它工業, 最大的不同,
> 是 需求經常會一直修改.................
> )
--
◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw From: 140.115.6.234