close
iThome上的好文章
點出軟體工程、CMMI的重要性
「要殺一個程式設計師不需要刀，改三次規格就好」、「品質的劣化程度，依規格改變的次數與規模而定」真是經典名言阿
另外加上我自己最常說的"程式不是寫來用的，程式是寫來改的"
...........
沒有需求規格，等於航海少了地圖
沒有專職的需求確定者（通常我們會說這樣的人是使用者或使用者的代表），通常就會衍生出第二個問題：沒有需求規格。
這是許多開發團隊的問題，他們根本不撰寫需求規格，所以整個開發專案，根本沒有規格可言。我相信為數不少的程式人在這種情況下，天天過著聽使用者口述需求的日子。甚至還有人把這種開發方式，自顧自地稱為「eXtreme Programming」，實在是大大誤解XP的精神。
不論你所用的開發方法論，是多麼的敏捷、輕量級，但需求總是必須確定下來，而且明確地記錄，讓專案的每個人都可以接觸到。不論記錄、表達需求規格的方式是簡單或複雜，它總是必須明確地記錄並表達。
需求規格就像是軟體開發時的航海圖，少了這張圖，「程式設計師就必須憑自己的力量在海上找到大陸」。少了一個確切的方向，每個人不見得都往同一個方向前進，這要如何確保大家會相會呢？
想要省略需求規格的主要動機，往往是想省去撰寫規格的時間，以提高開發的速度。有些人將「撰寫文件」視為浪費時間的無用舉動。但是，倘若需求不能準確地從需求提供者傳遞給程式人，結果實作出不能滿足需求的產物，最後來來回回地更正及修改，只會耗去更多時間。
需求的更動，不僅將耗費人力及時間，也會導致品質下降
也有一些開發團隊，把需求規格的格式設計的過於繁瑣，導致制定規格者必須耗費大量的時間於文書工作，事實上，太多的細節描述，有時無助於程式人更深刻了解需求，不僅可能造成反效果，更是為了繁文縟節而浪費時間。
此外，需求沒有獲得技術人員的承諾，也是常見的問題。提出需求的人員，天馬行空地想像了許多的功能，但在制定規格的過程中，並沒有技術人員參與、了解，並認可其中的可行性。於是，當需求規格完成後，片面交付開發人員實作。幸運的話，在短時間可以重新再修改規格（也浪費不少時間），運氣差的話，到了後段才被發現需求不可行，那麼所造成的衝擊更是驚人。
需求規格的變更幾乎是所有程式人的惡夢。江湖上流傳的格言說：「需求規格在程式寫完後才會敲定」、「基本規格要客戶看到成品後才會決定」、「詳細規格要使用者用過後才會確定」。
太多握有需求控制權的人們，對於需求的變更，幾乎已經到了一種肆無忌憚的境界。有的甚至幾乎每天對於系統應該具備的功能，都有新的想法。無怪乎程式人會說「品質的劣化程度，依規格改變的次數與規模而定」。
需求的變更，對於系統的傷害是很大的。因為軟體高複雜度的特性，牽一髮動全身，更動一條需求規格，有時程式人將因此大幅度修改。而且，對測試工作而言，除非全面徹底地重新再測試，否則很難保證單靠迴歸測試，就可以找到修改所造成的副作用。需求規格的更動，除了意謂著得投入更多的人力及時間外，通常更會造成品質下降。
沒有專職的需求確定者（通常我們會說這樣的人是使用者或使用者的代表），通常就會衍生出第二個問題：沒有需求規格。
這是許多開發團隊的問題，他們根本不撰寫需求規格，所以整個開發專案，根本沒有規格可言。我相信為數不少的程式人在這種情況下，天天過著聽使用者口述需求的日子。甚至還有人把這種開發方式，自顧自地稱為「eXtreme Programming」，實在是大大誤解XP的精神。
不論你所用的開發方法論，是多麼的敏捷、輕量級，但需求總是必須確定下來，而且明確地記錄，讓專案的每個人都可以接觸到。不論記錄、表達需求規格的方式是簡單或複雜，它總是必須明確地記錄並表達。
需求規格就像是軟體開發時的航海圖，少了這張圖，「程式設計師就必須憑自己的力量在海上找到大陸」。少了一個確切的方向，每個人不見得都往同一個方向前進，這要如何確保大家會相會呢？
想要省略需求規格的主要動機，往往是想省去撰寫規格的時間，以提高開發的速度。有些人將「撰寫文件」視為浪費時間的無用舉動。但是，倘若需求不能準確地從需求提供者傳遞給程式人，結果實作出不能滿足需求的產物，最後來來回回地更正及修改，只會耗去更多時間。
需求的更動，不僅將耗費人力及時間，也會導致品質下降
也有一些開發團隊，把需求規格的格式設計的過於繁瑣，導致制定規格者必須耗費大量的時間於文書工作，事實上，太多的細節描述，有時無助於程式人更深刻了解需求，不僅可能造成反效果，更是為了繁文縟節而浪費時間。
此外，需求沒有獲得技術人員的承諾，也是常見的問題。提出需求的人員，天馬行空地想像了許多的功能，但在制定規格的過程中，並沒有技術人員參與、了解，並認可其中的可行性。於是，當需求規格完成後，片面交付開發人員實作。幸運的話，在短時間可以重新再修改規格（也浪費不少時間），運氣差的話，到了後段才被發現需求不可行，那麼所造成的衝擊更是驚人。
需求規格的變更幾乎是所有程式人的惡夢。江湖上流傳的格言說：「需求規格在程式寫完後才會敲定」、「基本規格要客戶看到成品後才會決定」、「詳細規格要使用者用過後才會確定」。
太多握有需求控制權的人們，對於需求的變更，幾乎已經到了一種肆無忌憚的境界。有的甚至幾乎每天對於系統應該具備的功能，都有新的想法。無怪乎程式人會說「品質的劣化程度，依規格改變的次數與規模而定」。
需求的變更，對於系統的傷害是很大的。因為軟體高複雜度的特性，牽一髮動全身，更動一條需求規格，有時程式人將因此大幅度修改。而且，對測試工作而言，除非全面徹底地重新再測試，否則很難保證單靠迴歸測試，就可以找到修改所造成的副作用。需求規格的更動，除了意謂著得投入更多的人力及時間外，通常更會造成品質下降。
................
全站熱搜
留言列表
