軟體質量工程這本書如何

① 請問《軟體工程》這本書是不是沒有技術細節。隨便讀一下就好嗎

這個講的是一個開發軟體的項目工程的流程思路和做法，能夠幫助你更好管理整個軟體項目的開發周期好項目計劃安排，他是從工程化角度去考慮問題，一般不會有軟體編程的技術細節
如經典的瀑布流模型開發、敏捷開發、迭代開發等都是軟體工程中會有涉及
而在實際工作中、你如果是一線底層碼農不太需要考慮書中的問題，如果你想當管理，項目經理之類的，就要好好學這個了

② ＜軟體工程＞的好書

軟體工程導論第四版張海潘編著
最適合初學者

軟體工程---實踐者研究 機械工業出版社

<<軟體工程-實踐者的研究方法>>
Software Engineering: A Practitioner's Approach
Roger s.Pressman 梅宏

總體方法論和過程

第1名：
解析極限編程——擁抱變化（影印版）
原書名：Extreme Programming Explained：Embrace Change
作者：Kent Beck
出版社：中國電力出版社
原出版社：Addison-Wesley
頁書：194
定價：26
出版日期：2003-9-1

專家評語：
曲俊生：
XP（極限編程）由於其高度可操作性，尤其是對於業界眾多實踐的總結，在敏捷軟體開發方法中一馬當先，獲得了廣泛的研究與關注。本書是了解XP的必讀寶典，其中對於XP的原則、核心價值、最佳實踐都有深入的描述，更加難能可貴的是，作者並沒有效法其他鼓動者，將XP推到「萬金油」的高度，而是非常清楚地列舉了它不適用的地方。同時，作者也指出，不要太深入地追究您在項目中採用的是否是完全的XP實踐，而應該根據項目的實際進行剪裁。
本書適合對於敏捷軟體開發感興趣，同時又想找到一個可操作性較強方法的開發人員。

王詠剛：
單憑書名里「擁抱變化」這四個字，Kent Beck這本專門給大夥兒解釋極限編程是什麼東東的紅寶書就沒白寫。要說也是，那些沒事兒就鼓搗世界級的軟體工程理論、動輒就要寫1000頁以上大部頭的老先生們做夢也想不到，他們的眼中釘肉中刺，他們想方設法要「管理」、「控制」的對象——軟體開發里的「變化」——在Beck看來就像是楊過身邊的大雕，雖然長得丑點兒，卻能陪你練劍，讓你成為真正的大俠。聽Beck的沒錯，趕快放下架子，和「變化」打成一片吧，要不然你永遠也甭想練成獨孤九劍。

第2名：
敏捷軟體開發（影印版）
原書名：Agile Software Development
作者：Alistair Cockburn
出版社：人民郵電出版社
原出版社：Addison-Wesley
頁數：324 定價：35
出版日期：2003-8-1

專家評語：
曲俊生：
很早以前就讀到英文的電子版，在很大程度上，本書是對於RUP等方法論的顛覆，尤其是在國內「軟體藍領」宣傳大行其道的時候，本書構成了一副有效的清醒劑。本書是Cockburn從20多年的IBM工作中總結出來的實踐結晶。書中充滿了睿智的比喻與描述，例如，將軟體開發形容成一場游戲。書中對於水晶方法的介紹固然可貴，但是更加精彩的是對於人、溝通等主題的深入描述，可以說，這是既《人件》之後對「人」在軟體開發中重要作用描述的又一本經典著作。
該書也不是了解SE（軟體工程）的入門書籍，適合於對傳統軟體開發過程有深入理解，但是對於敏捷軟體開發了解不深的PM（項目經理）詳細閱讀。

第3名：
測試驅動開發（影印版）
原書名：Test-Driven Development
作者：Kent Beck
出版社：中國電力出版社
原出版社：Addison-Wesley
頁數：226 定價：32
出版日期：2003-8-1
專家評語：
徐鋒：
分析、設計、編碼、測試，已經成為了軟體開發領域亘古不變的真理。Kent Beck，這一全力追求敏捷，希望將編程發揮到極限的黑客級大師，提出了顛覆性的理論——測試先行。在本書中，作者結合編程實例，說道理、講方法，並結合自動化測試框架來提高效能。讓筆者看完之外，就有躍躍欲試之感，叛逆的精神融入了每一個細胞。

該帖由: lindows修改，時間 2004-1-6 上午11:44

分析和設計

第1名：
編寫有效用例
原書名:Writing Effective Use Cases
作者:Alistair Cockburn
出版社:機械工業出版社
原出版社:Addison-Wesley
頁數：304
定價：25
出版日期：2002-7-1

專家評語：
張恂：
用例是10多年來最重要的需求分析技術，更是現代軟體過程和項目管理的主驅動軸。隨著對用例理解的深入，我不禁倒吸一口氣:對於大多數項目，如果不細化到用例這個層次，我們過去寫的所謂「需求」其實都算不上真正的需求。此書是繼Ivar Jacobson的OOSE之後，用例兩大流派的「教主」之一Alistair Cockburn的代表之作，而且我一直認為它是迄今為止最好的用例教材。
10多年前Cockburn曾經聽過Jacobson的課，沒想到後來他在用例技術的實用化方面做出了貢獻，大有青出於藍而勝於藍之勢。大概與作者喜歡作詩（以及他對道德經的愛好）有關，我很喜歡他的寫作風格:依著人們的直覺娓娓道來，在平淡無奇的文字背後卻折射出極其豐富的項目經驗和扎實的專業技巧，讀完之後你會驚訝地發現一切竟然如此簡單和美妙，這不就是軟體開發的真諦么？
徐鋒：
用例分析技術是一個偉大的創舉，它將開發團隊帶到了客戶的視角上，這是一個良好的驅動點。掌握用例分析技術，將對你的職業生涯帶來很大的益處。《編寫有效用例》是你的起點，本書能夠幫助你真正有效地利用該技術，更好地掌握這一看似十分簡單、卻又十分復雜的需求分析方法。薄薄的一本書，卻記載著方方面面問題的答案，從這里騰飛吧。

第2名：
重構——改善既有代碼的設計（影印版）
原書名:Refactoring: Improving the Design of
Existing Code
作者:Martin Fowler
譯者:侯捷 熊節
出版社:中國電力出版社
原出版社:Addison-Wesley
頁數：431 定價：68
出版日期:2003-8-1

專家評語：
王詠剛：
沒有什麼比《重構》這本書更能理解程序員的苦衷並處處為程序員著想了。那些軟體工程權威們總板著臉說「你不能這樣，你不能那樣」，好像所有程序員都是該他們管教的小孩子；而《重構》卻告訴我們說，沒人能一步到位地把所有問題都想清楚，設計差不多了就開始寫代碼吧，等寫煩了寫膩了的時候再抽空兒零敲碎打修修補補——這可不是三天打魚兩天曬網，用形而上學的話講，這叫重構。

第3名：
分析模式——可復用對象模型（影印版）
原書名:Analysis Patterns:Reusable Object Models
作者：Martin Fowler
出版社:中國電力出版社
原出版社:Addison-Wesley
頁數:357 定價:48
出版日期:2003-6-20

專家評語：
宓吉琦：
應該是一本比較難懂的書，晦澀程度可能還超過設計模式，但也是任何一個想做架構師的人所必讀的。軟體是為其他產業服務的, 只有能把其他產業的需求順利轉化為軟體功能， 同時具有軟體設計藝術的人才是好的架構師。本書中，作者就把他從事的許多行業的寶貴建模經驗無條件地提供給大家，這些建模的經驗的積累往往需要花費幾年或者十幾年的時間。

項目和配置管理

第1名：
人月神話（影印版）
原書名：The Mythical Man-Month
作者：Frederick Phillips Brooks, Jr.
出版社:中國電力出版社
原出版社:Addison-Wesley
頁數：322
定價：25
出版日期：2003-3-1

專家評語：
青潤：
一種感慨，一種沉默……在該書中看到的神品的推薦，讓人唏噓不已。不過，這本書的確是軟體工程領域內的一本極品，國內見過似乎理論道行很深的書，但是卻沒有見到過有這樣理論與實踐深度並存的書籍出現過！
沒有項目經歷，沒有工程經驗，勸你千萬不要閱讀此書，否則，是對神品的褻瀆！而且，你也絕對不可能看明白的！
「開發人員交付的是用戶滿意度，而不僅僅是有形的產品」——沒有經驗的人能看明白么？國內的軟體以工程項目居多，國內的教育以理論為主，理論與實踐的脫節，學生學到的幾乎是空白，這也就是為什麼其他專業轉過來從事計算機行業的人往往在軟體公司裡面的表現往往比計算機專業畢業要好的一個很重要因素。
王詠剛：
網上有不少板磚拍在這本書上，因為有人嫌這書太老套，幾十年前的破事兒了還敢擦脂抹粉地端出來蒙人騙錢。我偏要說這書挺好看，關鍵是你不能拿它當項目管理入門的教材看，你得把他當成一本跟你談心聊天講故事的散文集來看。你瞧前些年，那麼多女孩子捧著本余秋雨如醉如痴似顰似笑風情萬種，難道就不許我們程序員揣著《人月神話》假裝深沉故作風雅，既陶冶了知識青年的道德情操又學習了項目管理的思想方法嗎？

第2名：
快速軟體開發（影印版）
原書名：Rapid Development
作者：Steve McConnell
出版社：機械工業出版社
原出版社：Microsoft Press
頁數：676
定價：58
出版日期：2003-3-1

專家評語：
張恂:
眾人看完此書皆掩卷長嘆，相見恨晚啊！在外面參加了那麼多國際項目管理課程，對改進「軟體」項目管理到底有多大真實效果呢？軟體項目經理當然要懂軟體項目自身的規律！誇張一點，學了這么多通用的PM知識，可能還不及這樣一本實話實說的書管用。軟體項目經理可能是軟體行業中承擔壓力最大，也是最有苦難言，最需要關心的一個群體。書里有這么多美國同行的經驗教訓、陷阱和誤區，如果你對此還一無所知，難免會一而再、再而三地掉進去;書里還有這么多優秀的實踐方法，你為什麼不試著用用看呢？所以我的建議是，如果Steve McConnell這位朴實的優秀程序員、著有多本名著的技術作家兼國際軟體工程權威說話了，大家一定要仔細聽聽。這年頭的「必讀經典」大有泛濫之勢，實在讓人招架不住，可是這次我甘冒風險大膽地說：對於改變國內軟體項目管理的窘況，此乃必讀之選。

第3名：
領導軟體開發團隊
原書名：Leading a Software Development Team:A
Developer's Guide to Successfully Leading
People and Projects
作者：Richard Whitehead
譯者：吳志明
出版社：電子工業出版社
原出版社：Addison-Wesley
頁數：304 定價：36
出版日期：2002-5-1

專家評語：
徐鋒：
一本親切的好書，讓我愛不釋手。如果你第一次擔任項目經理，這本書可以讓你迅速進入角色；如果你已有豐富的項目管理經驗，你也能夠從中吸取養份，解決埋藏在你心中很久的疑問。其採用的實例為驅動的寫作方法，可以成為案頭常備的寶典。

③ 《軟體測試工程師培訓教程》這本書怎麼樣

沒聽說過..
一般都看清華大學的軟體評測師教材..或者上海市的軟體質量管理測試教材.

④ 如何學習軟體工程

個人淺見：軟體工程涉及的內容非常多，而且學習時理論抽象的東西居多，沒有具體的實踐經驗在將來處理具體問題時會有難度，也許這也是為什麼很多人覺得很空洞的原因，不過事實顯然並非如此。如果是在學校學習，個人建議：耐心先學習課本理論、多看雜志開闊視野、最重要的程序設計和系統設計的計算機基礎千萬不可拋到一邊，否則將來實踐時，很難理解開發人員面臨問題的實質。
1、軟工理論（課本知識）
2、CMMI（淺嘗的話可以看看這本《CMMI精粹：集成化過程改進實用導論》（第二版），不過有空的話還是建議看看CMMI的原件，雖然比較枯燥，不過還是可以掃一下，不要強迫自己都記住，那是不可能的）開拓視野：
多看書籍、雜志、網頁，別無它法。不過看的時候有幾點注意事項：
2、目前書籍、雜志、網頁等談的多是敏捷方法，這和Web開發、企業應用IT的領域有很大的關聯，而這部分領域正是由於和網路相關，所以非常火爆，不過這畢竟只是軟體領域中的冰山一角，千萬不可被其表象所迷惑，而抱怨課本理論。這方面很難一言道盡，有一本書《平衡敏捷和規范》（清華大學出版社）不妨買來收藏，不過要體會其中的價值，可能需要真正積累的許多問題和經驗的時候才能有所發現，但先留著免得以後絕版。
3、PMP（項目管理）的知識不放也有空瀏覽一下，因為在軟工中占據很大位置的一塊——質量管理，始終是和項目管理糾纏在一塊，很難分家。
4、總結一下，多看書，不是要盲從，而是要在將來形成自己的觀點。實踐中需要具體問題具體對待，最忌生搬硬套。「理論」和「經驗」都很重要，象現在很多人都在談「道」（理論），切不可被其迷惑，「術」也很重要，知道「道」不一定能夠幫你解決問題，但知道「道」會使人得到升華和括寬思路，「術」則是真正體會「道」的基礎，否則一切都是空談，就像武俠小說里常說的什麼「明白就是明白」之類的鬼話。
系統與程序設計：
1、需要深究，一是這一塊也是軟工中的一塊重頭，二是沒有自己的開發實踐，很難理解開發所碰到的困難和問題。
3、《產生式編程－方法、工具與應用》這本書也值得一讀，裡面對現今程序設計的發展有一定的論述。尤其是領域工程部分，值得再去查閱其他資料。
4、上面的書可能都是引子，看到有興趣的話題不放通過書中所列的參考書籍進行進一步的查閱，不過這就和個人很相關了，誰也幫不上忙。
5、沒事時，自己要多寫寫代碼編編程序，結合自己的體會驗證一下各家所言。
關於學軟工的職業道路：
1、直接從事軟體開發，成為軟體開發主力
2、軟體質量管理：QA、EPG、項目運作管理。這一行也很容易轉回開發做管理。
3、軟體咨詢：新興的行業，不過要有實力和廣交朋友才行。

⑤ 軟體工程好學嗎應怎樣准備累不累 我無基礎

還不錯 看一些軟體編程的書了安裝一些環境先 累是當然的 要想讀好 那個專業都累 不過計算機還好 都是實操課 教室大部分學校都有空調 上到大學 出了英語有用其他都沒用 全部都是從零開始的 加油吧 出來就業率也很高

⑥ 《軟體品質之完美管理》這本書怎麼樣

《軟體品質之完美管理》作者顏廷吉。
作者簡介
顏廷吉，山東臨沂人，畢業於北京大學軟體與微電子學院，碩士學位。上海頤凡軟體科技有限公司創始人兼首席架構師，高級系統工程師,「頤凡Java應用開發平台」軟體著作權人，擁有PMP、OCP、LIP-3等各種高級國際技術認證證書，日本國家高度人才。
2007年就職於NTTDATA集團公司，任研發部主任，從事一線軟體研發與設計近十年。曾經主導與參與了日本厚生勞動省HelloWork就職勞動項目、Taspo全國香煙自動販賣項目、飲料自動販賣機販賣信息採集項目等大型系統的設計與研發，曾連續多年獲得公司社長獎，優秀項目獎等各種獎項。
本書是作者多年從事品質管理經驗的總結與精華。從軟體品質管理理論、開發中的品質管理、運營中品質管理、品質預防這四大部分進行了詳細介紹。同時本書還包含品質管理5項解密，6篇品質管理標准範文，7種品質項目檢查表，10種品質管理要領，13種品質管理原則， 18個實戰經典案例， 18個溫馨提示，40項品質管理技巧以及完美文檔品質，完美運營品質，架構師的自我完美修煉等完整品質分析與管理體系內容。其內容翔實、理念新穎、條理清晰、圖文並茂、實戰性強。

內容簡介
本書內容可劃分為軟體品質理論要點、開發中的品質管理、運營中的品質管理及品質預防四大部分。
第1章介紹了軟體品質相關的理論基礎與概念。
第2章到第10章主要介紹軟體開發中所必備品質管理技能體系。第2章介紹了品質管理要點及大致流程；第3章與第4章介紹了品質注入階段中具體的定量與定性品質管理技能；第5章與第6章是對品質驗證階段中具體的定量與定性品質管理技能的介紹；第7章重點介紹了軟體開發過程中必備的文件種類與文檔寫作技巧；第8章主要介紹了架構品質管理方面應該考慮的要點；第9章介紹了各種品質管理要領；第10章介紹了品質開發與運營中重要的常用工具等。
第11章，主要內容是介紹軟體運營時必備的品質管理技能。
第12章主要介紹架構師自我修煉的必備技巧。
《軟體品質之管理》適合軟體工程師、架構師、軟體產品經理和軟體品質管理員提升自身軟體品質管理水平使用；還適用於那些有志於成為軟體架構師的其他軟體從業人員自學使用；也可以作為各大院校相關專業師生參考；各大培訓機構也可將本書作為軟體工程、軟體架構等方面的培訓教材。
本書特色

授人以魚，授之以漁：本書的內容是按照品質管理培訓師的標准進行編排的，不僅可以自我提高亦可以作為講師教材。
案例驅動，腳踏實地：不單獨講理論，而是以案例驅動進行實戰解析；不僅是經驗與理論總結，更重要的是用最佳項目案例來說明技術應用。特別是各種文檔成果物的模板，在實際項目中都可以拿來即用。
圖解技術，形象生動：避免了乏味難懂的文字描述，使繁冗復雜的事物一目瞭然，也是對理論進行深刻透徹理解的形象記憶。
與時俱進，中西結合：本書大量汲取了日本品質管理中的精髓，並結合我們國內的實情進行了優化，日本人的品質管理思想與意識值得我們研究與學習。特別是在文檔的寫作能力上，本書安排了較大篇幅進行指導，就是針對國內IT人員不善於製作文檔的弱點而開出的良方。而且本書安排的圖表頗多，也是有意在展示與訓練讀者——盡可能地在文檔里融入圖表技術，這樣會給讀者帶來賞心悅目的閱讀體驗。

⑦ 軟體工程這個專業怎麼樣

中國的軟體行業規模不是很大，有些軟體企業在軟體製作上，也只是採用了一些軟體工程的思想，距離大規模的工業化大生產比較還是有一定的差距；原因有管理體制的問題，市場問題，政策問題，也有軟體工程理論不全面和不完善的問題。所以軟體工程的研究和應用，以及中國軟體行業的進一步發展，都需要一定的既有軟體工程的理論基礎和研究能力，又有一定的實踐經驗的軟體工程科學技術人員來推動。軟體工程的前途是光明的。軟體服務外包屬於智力人才密集型現代服務業。大量著名外包企業落戶寧波。主要就業去向包括軟體外包與服務企業、信息產品與服務企業，擔任程序員、軟體測試員、項目經理等工作崗位。軟體工程專業是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及到程序設計語言，資料庫，軟體開發工具，系統平台，標准，設計模式等方面。在現代社會中，軟體應用於多個方面。典型的軟體比如有電子郵件，嵌入式系統，人機界面，辦公套件，操作系統，編譯器，資料庫，游戲等。同時，各個行業幾乎都有計算機軟體的應用，比如工業，農業，銀行，航空，政府部門等。這些應用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量。相關學者、組織機構都分別給出了定義：Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

⑧ 關於軟體工程這門課程

軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：

Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。

Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

軟體工程學的內容
軟體工程學的主要內容是軟體開發技術和軟體工程管理．
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。

軟體工程基本原理

著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗，於1983年在一篇論文中提出了軟體工程的七條基本原理。
（1）用分階段的生存周期計劃進行嚴格的管理。
（2）堅持進行階段評審。
（3）實行嚴格的產品控制。
（4）採用現代程序設計技術。
（5）軟體工程結果應能清楚地審查。
（6）開發小組的人員應該少而精。
（7）承認不斷改進軟體工程實踐的必要性。
B.Boehm指出，遵循前六條基本原理，能夠實現軟體的工程化生產；按照第七條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

軟體工程必須遵循什麼原則

圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：

(1)選取適宜的開發模型

該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。

(2)採用合適的設計方法

在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。

(3)提供高質量的工程支撐

工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

(4)重視軟體工程的管理

軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。

軟體工程是指導計算機軟體開發和維護的工程學科。

採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。

軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法——結構分析或結構設計技術。

把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高軟體開發的成功率，軟體開發的生產率也能明顯提高。

目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟體生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。

軟體定義時期的任務是確定軟體開發工程必須完成的總目標；確定工程的可行性，導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，並且制定工程進度表。這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段，即問題定義、可行性研究和需求分析。

開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。

維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。

下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。

1問題定義

問題定義階段必須回答的關鍵問題：「要解決的問題是什麼？」如果不知道問題是什麼就試圖解決這個問題，顯然是盲目的，只會白白浪費時間和金錢，最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實踐中它卻可能是最容易被忽視的一個步驟。

通過問題定義階段的工作，系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查，分析員扼要地寫出他對問題的理解，並在用戶和使用部門負責人的會議上認真討論這份書面報告，澄清含糊不精的地方，改正理解不正確的地方，最後得出一份雙方都滿意的文檔。

問題定義階段是軟體生存周期中最簡短的階段，一般只需要一天甚至更少的時間。

2可行性研究

這個階段要回答的關鍵問題：「對於上一個階段所確定的問題有行得通的解決辦法嗎？」為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程，也就是在較抽象的高層次上進行的分析和設計的過程。

可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。

在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型（通常用數據流圖表示），並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益，對建議的系統進行仔細的成本／效益分析是這個階段的主要任務之一。

可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據，一般說來，只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目，可以避免更大的浪費。

3需求分析

這個階段的任務仍然不是具體地解決問題，而是准確地確定「為了解決這個問題，目標系統必須做什麼」，主要是確定目標系統必須具備哪些功能。

用戶了解他們所面對的問題，知道必須做什麼，但是通常不能完整准確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟體開發人員知道怎樣使用軟體實現人們的要求，但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。

在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎，因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家，技術專家一般都喜歡很快著手進行具體設計，然而，一旦分析員開始談論程序設計的細節，就會脫離用戶，使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准，需求分析階段必須提供完整准確的系統邏輯模型，經過用戶確認之後才能進入下一個階段，這就可以有效地防止和克服急於著手進行具體設計的傾向。

4總體設計

這個階段必須回答的關鍵問題是：「概括地說，應該如何解決這個問題？」

首先，應該考慮幾種可能的解決方案。列如，目標系統的一些主要功能是用計算機自動完成還是用人工完成；如果使用計算機，那麼是使用批處理方式還是人機交互方式；信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案：

低成本的解決方案。系統只能完成最必要的工作，不能多做一點額處的工作。

中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求，但是系統分析員根據自己的知識和經驗斷定，這些附加的能力在實踐中將證明是很有價值的。

高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。

系統分析員應該使用系統流程圖或其他工具描述每種可能的系統，估計每種方案的成本和效益，還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統，則可以著手完成本階段的另一項主要工作。

上面的工作確定了解決問題的策略以及目標系統需要哪些程序，但是，怎樣設計這些程序呢？結構設計的一條基本原理就是程序應該模塊化，也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構，也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。

5詳細設計

總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化，也就是回答下面這個關鍵問題：「應該怎樣具體地實現這個系統呢？」

這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖，它們應該包含必要的細節，程序員可以根據它們寫出實際的程序代碼。

通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設計語言）描述詳細設計的結果。

6編碼和單元測試

這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。

程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把說細設計的結果翻譯成用選定的語言書寫的程序，並且仔細測試編寫出的每一個模塊。

7綜合測試

這個階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟體達到預定的要求。

最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標系統進行驗收。

必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。

為了使用戶能夠積極參加驗收測試，並且在系統投入生產性運行以後能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。

通過對軟體測試結果的分析可以預測軟體的可靠性；反之，根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。

應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，做為軟體配置的一個組成成分。

8軟體維護

維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。

通常有四類維護活動：改正性維護，也就是診斷和改正在使用過程中發現的軟體錯誤；適應性維護，即修改軟體以適應環境的變化；完善性維護，即根據用戶的要求改進或擴充軟體使它更完善；預防性維護，即修改軟體為將來的維護活動預先做准備。

雖然沒有把維護階段進一步劃分成更小的階段，但是實際上每一項維護活動都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

都應該經過提出維護要求（或報告問題），分析維護要求，提出維護要求，提出維護方案，審批維護方案，確定維護計劃，修改軟體設計，修改程序，測試程序，復查驗收等一系列步驟，因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

⑨ 軟體質量管理指南的圖書前言

軟體質量管理是個全組織、多角色共同參與的、復雜的系統過程，好的軟體質量是各級軟體管理人員孜孜追求的最高夢想。
軟體質量管理體系的知識涵蓋了軟體工程、CMMI軟體能力成熟度模型、PMP項目管理以及軟體測試技術的理論。其中，軟體工程主要介紹了各種生命周期模型，這是軟體研發和質量管理的基礎，也是CMMI軟體能力成熟度模型和PMP項目管理理論中非重點介紹的內容；PMP項目管理理論適用於任何行業的項目管理工作，它詳細介紹了制定項目估算、預算的方法，以及制定項目進度計劃的各種技術，這些是CMMI軟體能力成熟度模型和軟體工程的重要補充；CMMI軟體能力成熟度模型是當今最流行的一種對軟體企業成熟度的評判標准，它所涵蓋的內容之廣及體系之完整都是前所未有的。CMMI將軟體的管理過程拆分為多個PA（過程域），並詳細介紹了每個PA所需要完成的工作、流程以及流程中必備的產出物，它是軟體質量管理中的核心部分。但CMMI軟體能力成熟度模型著重於過程的定義，有些具體的操作方法和技術就必須參考PMP項目管理理論或軟體測試理論的相關知識。軟體測試一直以來都被很多人誤解為等同於軟體質量管理，多樣的軟體測試技術正是CMMI軟體能力成熟度模型VER（驗證）的重要補充內容。總的來說，軟體工程中生命周期模型好比蓋房子時打下的地基，CMMI軟體能力成熟度模型就是房子的框架結構，PMP項目管理以及軟體測試技術的理論就是填充房子的磚石，而蓋好的這座房子就是軟體質量管理體系。
本書以CMMI軟體能力成熟度模型為主線，第1章對軟體質量管理體系進行了概述，第2～4章介紹了軟體質量管理所必備的常用技術「驗證」、「確認」和「同行評審」；第5～8章介紹軟體質量管理的基礎管理流程「質量保證」、「配置管理」、「度量管理」和「風險管理」的知識；第9～11章介紹軟體項目管理相關的「項目集成管理」、「項目計劃」和「項目監控」的知識；第12～14章介紹了軟體質量管理體系的「需求工程」、「決策分析」和「產品集成」的理論；第15章重點介紹了如何進行持續的質量改進，第16章為廣大讀者講解了微軟最新的軟體項目工具「Team Foundation Server」的基本使用方法。
為了讓廣大讀者更好地理解軟體質量管理的理論，本書在每章的結束都針對軟體項目研發過程中的常見問題進行案例分析，目的是為了將軟體質量管理體系的知識與實際項目進行聯系，更好地讓軟體各級管理人員進行理解和應用。
本書總結了當今軟體質量管理所需要的全部知識，其中重點介紹的CMMI軟體能力成熟度模型可以為軟體公司高層管理人員和過程改進小組（EPG）的工作提供幫助；PMP項目管理的相關技術可以為軟體公司的項目管理人員提供日常的項目指導並作為PMP考試的參考資料；每章的案例分析也採取了「信息類項目管理師」的考試形式，希望可以為參加「信息類項目管理師」考試的朋友提供幫助。
這些年來我一直希望可以將總結的軟體質量管理的知識和理論與大家分享，本書能夠順利出版首先要感謝51Testing所提供的機會，也要感謝各位編輯的辛勤勞動。同時還要感謝長期以來支持我的朋友和我的妻子蔡覓女士，你們是我成長的最大動力！
作 者
2009年5月28日於蘇州

⑩ 推薦一下幾本關於軟體質量管理的書

電子工業出版社的《軟體質量管理實踐-軟體缺陷預防、清除、管理實用方法》，這本就夠了，非常好，作者本身就是做這個的，第一手經驗。