软件工程课件

第一章軟體工程概述

1.1電腦軟體本節內容1.1.1軟體的定義1.1.2軟體的特點1.1.3軟體的分類1.1.1軟體的定義軟體是程式的完善和發展，是經過嚴格的正確性檢驗和實際試用，並具有相對穩定的文本和完整的文檔資料的程式。Wirth中指出：在結構化程式設計：程式＝演算法＋數據結構在軟體工程中：軟體＝程式＋文檔。IEEE定義：軟體是電腦程式、規程以及運行電腦系統所需要的文檔和數據。1.1.1軟體的定義另一種對軟體的公認解釋是：軟體是包括程式、數據及其相關文檔的完整集合。程式是按照事先設計的功能和性能要求執行的指令序列；數據是使程式能正常操縱資訊的數據結構；文檔是與程式開發、維護和使用有關的圖文材料。1.1.2軟體的特點（1）軟體是一種邏輯實體，具有抽象性。（2）軟體的開發過程中沒有明顯的製造過程。（3）軟體在運行和使用期間，沒有硬體那樣的機械磨損和老化問題，但存在軟體退化問題。（4）軟體的開發和運行常常受到電腦系統的約束和限制，不同程度地依賴電腦硬體。（5）軟體的開發至今未完全擺脫手工藝的開發方式，大部分軟體還是定制的，很難通過組裝方式完成軟體開發。1.1.2軟體的特點（6）軟體是複雜的。實際需求的複雜性程式邏輯的複雜性（7）軟體研製成本相當高，在電腦系統中軟體成本比例逐步增加。（8）軟體投入運行時還涉及到許多社會因素。1.1.3軟體的分類根據軟體服務對象的範圍不同：通用軟體：操作系統、資料庫等；定制軟體：企業ERP、衛星控制系統等；根據軟體完成功能所處的層次不同：系統軟體中間件軟體應用軟體1.1.3軟體的分類系統軟體：指能與電腦硬體緊密配合在一起，使電腦系統各個部件、相關的軟體和數據協調、高效地工作的軟體。操作系統設備驅動程式通信處理程式1.1.3軟體的分類中間件遮罩了底層操作系統的複雜性，使程式開發人員面對一個簡單而統一的開發環境，將注意力集中在自己的業務上，不必再為程式的移植而重複工作，從而大大減少了技術上的負擔。中間件軟體：為了解決分佈異構系統的集成問題而開發的軟體，是處於操作系統軟體與用戶的應用軟體的中間的通用服務，具有標準的介面和協議。1.1.3軟體的分類中間件的種類包括：消息中間件數據訪問中間件應用伺服器對象中間件交易中間件安全中間件1.1.3軟體的分類中間件的十大優越性：

(1)

縮短應用的開發週期

(2)節約應用的開發成本

(3)減少系統初期的建設成本

(4)降低應用開發的失敗率

(5)保護已有的投資

(6)簡化應用集成

(7)減少維護費用

(8)提高應用的開發品質

(9)保證技術進步的連續性

(10)增強應用的生命力1.1.3軟體的分類應用軟體：在特定領域內開發，為特定目的服務的一類軟體。商業數據處理軟體工程與科學計算軟體電腦輔助設計／製造軟體系統仿真軟體智能產品嵌入軟體醫療、制藥軟體事務管理、辦公自動化軟體電腦輔助教學軟體電腦網絡軟體1.1.3軟體的分類按照軟體的規模：類別參加人員數開發週期產品規模（LOC）微型11～4周0.5k小型11～6月1k～2k中型2～51～2年5k～50k大型5～202～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M1.1.3軟體的分類按軟體工作方式不同：即時處理軟體分時軟體互動式軟體批處理軟體按照支撐應用開發的工具類型可以將其劃分為：支持軟體開發過程的工具支持軟體維護過程的工具支持軟體管理過程和支持過程的工具1.2軟體的發展和軟體危機本節內容1.2.1軟體發展階段1.2.2軟體危機1.2.3軟體危機的解決途徑1.2.1軟體發展階段程式設計階段：20世紀50至60年代程式系統階段：20世紀60至70年代 軟體工程階段：20世紀70至90年代現代軟體工程階段：20世紀90年代至今1.2.1軟體發展階段

階段程式設計程式系統（現代）軟體工程特點

軟體所指程式程式及說明書程式、文檔和數據程式設計語言彙編及機器語言高級語言軟體語言軟體工作範圍程式編寫包括設計和測試軟體生存期需求者程式設計本人少數用戶市場用戶開發軟體的組織個人開發小組開發小組及大中型軟體開發機構軟體規模小型中小型大中小型決定品質的因素個人程式技術小組技術水準管理水準開發技術和手段副程式/程式庫結構化程式設計資料庫、開發工具、開發環境、工程化開發方法、標準和規範、網路及分佈式開發、面向對象技術、軟體複用維護責任者程式設計者開發小組專職維護人員硬體特徵價格高/存儲容量小

工作可靠性差降價、速度、容量及工作可靠性明顯提高向超高速、大容量、微型化及網路化發展軟體特徵完全不受重視軟體技術的發展不能滿足需求，出現軟體危機開發技術有進步，但未獲突破性進展，價高，未完全擺脫軟體危機1.2.2軟體危機20世紀60年代後，隨著電腦軟體應用領域增多，軟體規模不斷擴大，軟體系統功能多，邏輯複雜，不斷擴充，從而導致許多系統開發出現了不良的後果：系統存在大量錯誤，可用性和可靠性差；系統無法增加新功能，難於維護；系統無法按照計畫時間完成；最嚴重的徹底失敗。軟體危機舉例20世紀60年代IBM公司開發的（OS/360）系統就是一個很好的例子。該系統由4000多個模組組成，約100萬條指令，人工為5000人年（一個人年為一個人工作一年的工作量），耗費達數億美元。該系統投入運行後發現了2000多個錯誤，發佈過19個版本，而以後每個版本的更新均有1000多個大大小小的錯誤存在。系統開發陷入了僵局。OS/360系統的負責人F.D.Brooms曾這樣形象地描述了開發過程中的困難和混亂：“……像一頭巨獸在泥潭中作垂死掙扎，掙扎得越猛，泥漿就沾得越多，最後沒有一個野獸能逃脫淹沒在泥潭中的命運……程式設計就像是這樣一個泥潭……一批批程式員在泥潭中掙扎……沒人料到問題竟會這樣棘手……”。1.2.2軟體危機所謂軟體危機（SoftwareCrisis）就是電腦軟體在開發和維護過程中所遇到的一系列嚴重問題，具體表現在：軟體開發成本難以估算，無法制定合理的開發計畫；用戶的需求無法確切表達；軟體品質存在問題；軟體的可維護性差；缺乏文檔資料；軟體成本難以控制；1.2.3軟體危機的解決途徑產生軟體危機的原因：軟體系統本身的複雜性；軟體開發的方法和技術不合理；程式設計方法學討論程式的性質、程式設計的理論和方法軟體工程方法運用工程化原則和方法組織軟體開發工作1968年提出1.3軟體工程本節內容1.3.1軟體工程定義1.3.2軟體工程要素1.3.3軟體工程的目標和原則1.3.4軟體工程基本原理1.3.1軟體工程定義1968年10月，FritzBauer首次提出了“軟體工程”的概念：軟體工程是為了經濟地獲得能夠在實際機器上高效運行的可靠軟體而建立和使用的一系列好的工程化原則。Boehm為軟體工程下的定義：運用現代科學技術知識來設計並構造電腦程式及為開發、運行和維護這些程式所必需的相關檔資料。1.3.1軟體工程定義Fairley認為：軟體工程學是為在成本限額以內按時完成開發和修改軟體產品所需的系統生產和維護的技術和管理的學科。IEEE電腦學會將“軟體工程”定義為：⑴應用系統化的、規範化的、定量的方法來開發、運行和維護軟體，即：將工程應用到軟體；⑵對⑴中各種方法的研究。從以上定義可以看出，軟體工程的含義：（1）工程概念在軟體領域裏的一個特定應用（2）軟體工程涉及軟體產品的所有環節1.3.2軟體工程要素軟體工程包括三個要素：方法、工具和過程。方法：提供了“如何做”的技術；工具：提供了自動的或半自動的軟體支撐環境；過程：將軟體工程的方法和工具綜合起來以達到合理、及時地進行電腦軟體開發的目的；1.3.3軟體工程的目標和原則軟體工程的目標可概括為：生產具有正確性、可用性以及開銷適宜的軟體產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。軟體工程的最終目的是擺脫手工生產軟體的狀況，逐步實現軟體研製和維護的自動化。1.3.3軟體工程的目標和原則軟體工程研究內容：軟體開發技術：根據不同的軟體類型，按不同的觀點和原則，對軟體開發中應遵循的策略、原則、步驟和必須產生的文檔資料等作出規定，從而使軟體的開發能夠進入規範化和工程化的階段，以克服早期的手工作坊生產中的隨意性和非規範性做法。包括：軟體開發方法學、開發過程模型、開發工具、軟體工程環境軟體工程管理軟體按工程化生產時的重要環節，它要求按照預先制定的計畫、進度和預算執行，以實現預期的經濟效益和社會效益。包括：軟體管理學、軟體工程經濟學、軟體心理學等內容1.3.3軟體工程的目標和原則使用軟體工程開發軟體系統的過程中，要堅持四項基本原則：選取適宜的開發模型；採用合適的設計方法；提供高質量的工程支持；重視開發過程的管理；1.3.4軟體工程基本原理八條一般原理：（1）抽象（2）資訊隱藏（3）模組化（4）局部化（5）確定性（6）一致性（7）完備性（8）可驗證性1.3.4軟體工程基本原理七條基本原理（1）用分階段的生命週期計畫嚴格管理（2）堅持進行階段評審（3）實行嚴格的產品控制（4）採用現代程式設計技術（5）結果應能清楚地審查（6）開發小組的人員應少而精（7）承認不斷改進軟體工程實踐的必要性1.4通信軟體工程本節內容1.4.1通信系統1.4.2通信軟體1.4.3通信軟體工程1.4.1通信系統通信系統基本組成1.4.1通信系統通信網：眾多點對點通信系統通過交換系統按一定拓撲結構組合在一起就構成了通信網。通信網的組成：硬體：用戶終端設備、傳輸設備、交換設備軟體：通信網為能很好地完成資訊的傳遞和交換所必需的一整套協議、標準，包括網路結構、信令方式、協議和介面、網路管理、技術體制標準等1.4.1通信系統通信網系統基本功能：⑴基本的傳輸和交換功能。⑵業務控制功能。⑶網路管理功能。1.4.2通信軟體凡是用來實現兩個或多個實體（電腦、電信終端、交換設備等）之間相互通信的軟體都可稱為通信軟體。電信軟體：電話交換軟體、移動通信軟體、智能網軟體等；電腦網絡軟體：網路協議軟體、網路應用軟體；1.4.2通信軟體電信軟體類型1.4.2通信軟體⑴基本呼叫處理軟體：負責呼叫接續和呼叫狀態轉移的處理。⑵業務獨立邏輯處理模組：將交換機側相同的處理功能抽象封裝而成，如智能網。⑶資源管理：為業務控制軟體提供資源控制和管理功能。⑷業務控制：在通信網業務能力基礎上提供業務的生成、配置、接入、管理等功能。⑸客戶服務：客戶關係管理系統（CRM：CustomerRelationshipManagement），包括業務開通、業務保障、業務計量；⑹產品開發與管理電信軟體分類：OSS（OperationSupportSystem，運行支撐系統），包括(1)~(4)BSS（BusinessSupportSystem，經營支撐系統），包括(5),(6)電信業內將BSS和OSS結合起來統稱為BOSS（BusinessandOperationSupportSystem，運營支撐系統）。某電信運營商系統規劃實例1.4.3通信軟體工程通信軟體工程就是將軟體工程知識應用於通信領域，完全遵循軟體工程的三要素：過程、方法和工具，只是在過程、方法和工具中要結合通信軟體的特點。通信系統是全程全網系統，需遵守協議標準；系統協作，在資訊建模同時，需考慮行為建模；分析階段採用UML來表達軟體系統的功能需求和資訊需求；用MSC圖描述系統與外部環境的交互以及內部對象之間的資訊交互；在系統設計階段採用SDL來形式化描述系統設計；即時軟體開發工具：TelelogicTau1.5軟體工程知識體系本節內容1.5.1軟體工程知識體系指南簡介1.5.2軟體工程知識體系知識域1.5.1軟體工程知識體系指南簡介IEEE電腦學會的職業實踐委員會主持的一個專案，目的：促進世界範圍內對軟體工程的一致觀點；闡明軟體工程相對其他學科（如電腦科學、專案管理、電腦工程和數學等）的位置，並確立它們的分界；刻畫軟體工程學科的內容；提供使用知識體系的主題；為開發課程表和個人認證與許可材料提供一個基礎；1.5.2軟體工程知識體系知識域本章內容2.1軟體工程過程2.2軟體生命週期2.3軟體過程模型2.4傳統軟體生命週期模型2.5新型軟體生命週期模型2.1軟體工程過程軟體工程過程是為了獲得軟體產品，在軟體工具的支持下由軟體工程師完成的一系列軟體工程活動。軟體規格說明（specification）：規定軟體的功能及其使用限制；軟體開發（development）：產生滿足規格說明的軟體；軟體確認（validation）：通過有效性驗證以保證軟體能夠滿足客戶的要求；軟體演進（evolution）：為了滿足客戶的變更要求，軟體必須在使用過程中進行不斷地改進。2.2軟體生命週期軟體有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為電腦軟體的生命週期（LifeCycle）。軟體生命週期的六個基本步驟制定計畫需求分析設計程式編碼測試運行維護制定計畫確定要開發軟體系統的總目標；給出功能、性能、可靠性以及介面等方面的要求；完成該軟體任務的可行性研究；估計可利用的資源(硬體，軟體，人力等)、成本、效益、開發進度；制定出完成開發任務的實施計畫，連同可行性研究報告，提交管理部門審查；需求分析對用戶提出的要求進行分析並給出詳細的定義；編寫軟體需求說明書或系統功能說明書及初步的系統用戶手冊；提交管理機構評審；設計概要設計—把各項需求轉換成軟體的體系結構。結構中每一組成部分都是意義明確的模組，每個模組都和某些需求相對應；詳細設計—對每個模組要完成的工作進行具體的描述，為根源程式編寫打下基礎；編寫設計說明書，提交評審。程式編碼把軟體設計轉換成電腦可以接受的程式代碼，即寫成以某一種特定程式設計語言表示的“根源程式清單”；寫出的程式應當是結構良好、清晰易讀的，且與設計相一致的；測試單元測試，查找各模組在功能和結構上存在的問題並加以糾正；組裝測試，將已測試過的模組按一定順序組裝起來；按規定的各項需求，逐項進行有效性測試，決定已開發的軟體是否合格，能否交付用戶使用；運行維護改正性維護：運行中發現了軟體中的錯誤需要修正；適應性維護：為了適應變化了的軟體工作環境，需做適當變更；完善性維護：為了增強軟體的功能需做變更。2.3軟體過程模型模型是實際事物、實際系統的抽象。軟體過程模型也稱做軟體生命週期模型，是從一個特定角度提出的對軟體過程的簡化描述，是對軟體開發實際過程的抽象，它包括構成軟體過程的各種活動、軟體工件（artifact）以及參與角色等。軟體生命週期模型描述從軟體需求定義直至軟體經使用後廢棄為止，跨越整個生存期的軟體開發、運行和維護所實施的全部過程、活動和任務的結構框架，同時描述生命週期不同階段產生的軟體工件，明確活動的執行角色等。2.4傳統軟體生命週期模型2.4.1瀑布模型2.4.2V模型和W模型2.4.3原型方法2.4.4演化模型2.4.5增量模型2.4.6螺旋模型2.4.7噴泉模型2.4.8構件組裝模型2.4.9快速應用開發模型2.4.1瀑布模型WinstonRoyce在軟體生命週期概念的基礎上，於1970年提出了著名的“瀑布模型”（waterfallmodel）。維護評價2.4.1瀑布模型瀑布模型中的每一個開發活動具有下列特徵：本活動的工作對象來自於上一項活動的輸出，這些輸出一般是代表本階段活動結束的里程碑式的文檔。根據本階段的活動規程執行相應的任務。產生本階段活動相關產出——軟體工件，作為下一活動的輸入。對本階段活動執行情況進行評審。2.4.1瀑布模型瀑布模型的優缺點優點缺點降低了軟體開發的複雜程度，而且提高了軟體開發過程的透明性，提高了軟體開發過程的可管理性。模型缺乏靈活性，特別是無法解決軟體需求不明確或不准確的問題。推遲了軟體實現，強調在軟體實現前必須進行分析和設計工作。模型的風險控制能力較弱。

以專案的階段評審和文檔控制為手段有效地對整個開發過程進行指導，保證了階段之間的正確銜接，能夠及時發現並糾正開發過程中存在的缺陷，從而能夠使產品達到預期的品質要求。瀑布模型中的軟體活動是文檔驅動的，當階段之間規定過多的文檔時，會極大地增加系統的工作量；而且當管理人員以文檔的完成情況來評估專案完成進度時，往往會產生錯誤的結論。2.4.2V模型和W模型1980年代後期PaulRook提出了V模型W模型Evolutif公司在V模型的基礎上提出了W模型2.4.3原型方法原型方法的產生瀑布模型、V模型和W模型都將軟體生命週期劃分成獨立串行的幾個階段，前一個階段沒有完成便無法開始下一階段的工作。然而完整而準確的需求規格說明是很難得到的，因為：在開發早期用戶往往對系統只有一個模糊的想法，很難完全準確地表達對系統的全面要求隨著開發工作的推進，用戶可能會產生新的要求開發者有可能在設計與實現的過程中遇到一些沒有預料到的實際困難，需要以改變需求來解脫困境2.4.3原型方法原型指模擬某種最終產品的原始模型；原型方法指在獲得一組基本需求後，通過快速分析構造出一個小型的軟體系統原型，滿足用戶的基本要求。用戶通過使用原型系統，提出修改意見，從而減少用戶與開發人員對系統需求的誤解，使需求盡可能準確。原型方法主要用於明確需求，但也可以用於軟體開發的其他階段。2.4.3原型方法原型的三種作用類型：（1）探索型：弄清用戶對目標系統的要求，確定所期望的特性；探討多種實現方案的可行性。主要針對需求模糊、用戶和開發者對專案開發都缺乏經驗的情況。（2）實驗型；用於大規模開發和實現之前，考核技術實現方案是否合適、分析和設計的規格說明是否可靠。（3）進化型：在構造系統的過程中能夠適應需求的變化，通過不斷地改進原型，逐步將原型進化成最終的系統。它將原型方法的思想擴展到軟體開發的全過程，適用於需求經常變動的軟體專案。2.4.3原型方法由於運用原型的目的和方式不同，在使用原型時可採取以下兩種不同的策略：廢棄策略：原型主要用於回饋和評價，據此設計出完整、準確、一致、可靠的最終系統。系統構造完成後，原來的原型系統就被廢棄不用。探索型和實驗型原型屬於這種策略。追加策略：原型作為最終系統的核心，然後通過不斷地擴充修改，逐步追加新要求，最後發展成為最終系統。它對應於進化型原型。2.4.3原型方法原型方法的特點：（1）從認知論的角度看，原型方法遵循了人們認識事物的規律，因而更容易為人們所普遍接受，這主要表現在：①人們對任何事物的認知都不可能一蹴而就、盡善盡美；②認識和學習的過程都是循序漸進的；③對於事物的描述，往往都是受環境的啟發而不斷完善的；④人們批評指責一個已有的事物，要比空洞地描述自己的設想容易得多，改進一些事物要比創造一些事物容易得多。2.4.3原型方法⑵原型方法將模擬的手段引入分析的初期階段，溝通了人們的思想，縮短了用戶和開發人員之間的距離。這主要表現在：①所有問題的討論都是圍繞某一個確定原型而進行的，彼此之間不存在誤解和答非所問的可能性，為準確認識問題創造了條件。②有了原型才能啟發人們對原來想不起來或不易準確描述的問題有一個比較確切的描述；③能夠及早地暴露出系統實現後存在的一些問題，促使人們在系統實現之前就加以解決。2.4.3原型方法原型提供了用戶與開發人員良好的溝通手段，易於被人們接受，使用原型方法有以下好處：原型方法有助於增進軟體人員和用戶對系統服務需求的理解；原型方法提供了一種有力的學習手段；使用原型方法，可以容易地確定系統的性能，確認各項主要系統服務的可應用性，確認系統設計的可行性，確認系統作為產品的結果；軟體原型的最終版本，有的可以原封不動地成為產品，有的略加修改就可以成為最終系統的一個組成部分，這樣有利於建成最終系統。2.4.3原型方法原型法的適用範圍和局限性：對於一個大型系統，如果不經過系統分析得到系統的整體劃分，而直接用原型來模擬是很困難的。對於大量運算的、邏輯性較強的程式模組，原型方法很難構造出該模組的原型來供人評價。對於原有應用的業務流程、資訊流程混亂的情況，原型構造與使用有一定的困難。對於一個批處理系統，由於大部分活動是內部處理的，因此應用原型方法會有一定的困難。2.4.3原型方法原型方法存在的問題：文檔容易被忽略。建立原型的許多工作會被浪費掉。專案難以規劃和管理。2.4.3原型方法1984年Boar提出一系列影響原型方法選擇的因素方面適用原型法不適用原型法系統結構聯機事務處理系統、相互關聯的應用系統批處理系統邏輯結構有結構系統，如運行支持系統、管理資訊系統基於大量演算法和邏輯結構的系統用戶特徵積極參與、積極決策應用約束線上運行系統的補充專案管理專案負責人願意使用原型方法專案負責人不願意使用原型方法專案環境需求複雜易變、性能要求高需求明確固定2.4.3原型方法原型方法的應用過程2.4.3原型方法原型方法可以支持軟體生命週期的不同階段輔助或代替分析階段輔助設計階段代替分析與設計階段代替分析、設計和實現階段代替全部開發階段2.4.3原型方法支持原型構造的軟體複用技術所謂複用就是利用一些從早先軟體開發過程中收集到的、對建立新系統有用的資訊來構建新系統。從複用的內容角度可以劃分其類型為：數據複用：實現不同數據環境的移植；模組複用：COM/DCOM、JavaBean/EJB、CORBA結構複用：領域內通用業務邏輯；實現MVC（Model-View-Control，模型－視圖－控制器）體系結構的Struts框架、實現資料庫訪問邏輯複用的Hibernate框架等設計複用：MDA（ModelDrivenArchitecture，模型驅動體系結構）規格說明複用：規格說明可使用或者可參照使用。2.4.3原型方法軟體複用的兩種實現機制：合成複用：構件是基礎，構件以抽象數據類型為理論基礎，將功能實現細節與數據結構封裝在構件內部，對外有著精心設計的介面，供外部使用者構造應用時調用。構件本身可以是對某一函數、過程、副程式、數據類型、演算法等可複用軟體成份的抽象，利用構件來構造軟體系統，有較高的生產率和較短的開發週期。生成複用：利用可複用的模式（Patterns），通過生成程式產生一個新的應用程式或程式段2.4.4演化模型使用瀑布模型人們認識到，由於需求很難調研充分，所以很難一次性開發成功。演化模型提倡兩次開發：第一次是試驗開發，得到試驗性的原型產品，其目標只是在於探索可行性，弄清軟體需求；第二次在此基礎上獲得較為滿意的軟體產品。2.4.4演化模型演化模型分類：探索式演化模型拋棄式演化模型演化模型的特點：優點：明確用戶需求、提高系統品質、降低開發風險；缺點：難於管理、結構較差、技術不成熟；演化模型適用範圍：需求不清楚；小型或中小型系統；開發週期短2.4.5增量模型Mills等人於1980年提出，指首先對系統最核心或最清晰的需求進行分析、設計、實現、測試並集成到系統中。再按優先順序逐步對後續的需求進行上述工作，逐步建設成一個完整系統的開發方法。2.4.5增量模型使用增量模型開發字處理軟體時，可以按照以下優先順序進行增量開發：第一個增量實現基本的檔管理、編輯和文檔生成功能；第二個增量實現更加完善的編輯和文檔生成功能；第三個增量實現拼寫和文法檢查功能；第四個增量完成高級的頁面佈局功能。2.4.5增量模型增量模型的優點：有利於增加客戶對系統的信心；降低系統失敗風險；提高系統可靠性；提高了系統的穩定性和可維護性；增量模型的缺點：增量粒度難以選擇；確定所有的基本業務服務比較困難。2.4.6螺旋模型Boehm於1988年提出，主要針對大型軟體專案的開發。大型軟體專案的特點：（1）需求功能複雜，無法一開始就明確；開發週期長，中途需求經常變化；（2）往往存在諸多風險因素，在不同程度上損害軟體開發過程和軟體產品的品質，所以必須對風險進行管理。螺旋模型最大特點就是引入了明確的風險管理。2.4.6螺旋模型四個象限制定計畫風險分析實施工程客戶評價2.4.6螺旋模型制定計畫：確定軟體專案目標；明確對軟體開發過程和軟體產品的約束；制定詳細的專案管理計畫；根據當前的需求和風險因素，制定實施方案，並進行可行性分析，選定一個實施方案，並對其進行規劃。風險分析：明確每一個專案風險，估計風險發生的可能性、頻率、損害程度，並制定風險管理措施規避這些風險。實施工程：針對每一個開發階段的任務要求執行本開發階段的活動。客戶評估：客戶使用原型，回饋修改意見；根據客戶的回饋，對產品及其開發過程進行評審，決定是否進入螺旋線的下一個回路。

2.4.7噴泉模型噴泉模型也稱迭代模型，認為軟體開發過程的各個階段是相互重疊和多次反復的，就象噴泉一樣，水噴上去又可以落下來，既可以落在中間，又可以落到底部。各個開發階段沒有特定的次序要求，完全可以並行進行，可以在某個開發階段中隨時補充其他任何開發階段中遺漏的需求。優點：提高開發效率縮短開發週期缺點：難於管理2.4.8構件組裝模型構件組裝模型利用模組化思想將整個系統模組化，並在一定構件模型的支持下複用構件庫中的一個或多個軟體構件，通過組裝高效率、高質量地構造軟體系統。構件組裝模型本質上是演化的，開發過程是迭代的。構件組裝模型的開發過程就是構件組裝的過程，維護的過程就是構件升級、替換和擴充的過程。2.4.8構件組裝模型優點：充分利用軟體複用，提高了軟體開發的效率。允許多個專案同時開發，降低了費用，提高了可維護性，可實現分步提交軟體產品。缺點：缺乏通用的構件組裝結構標準，風險較大；構件可重用性和系統高效性之間不易協調；由於過分依賴於構件，構件品質影響著最終產品的品質。2.4.9快速應用開發模型快速應用開發（RapidApplicationDevelopment，RAD）是一個增量型的軟體開發過程模型，強調極短的開發週期。2.4.9快速應用開發模型RAD模型的缺點：並非所有應用都適合採用RAD，如果一個應用不能被模組化，那麼構造應用的構件就無法快速獲取由於時間約束，開發人員和客戶必須在較短的時間內完成一系列的需求分析，溝通配合不當都會導致應用RAD模型的失敗RAD適合於管理資訊系統的開發，對於其他類型的應用系統，如技術風險較高、與週邊系統的互操作性較高等，不太合適2.5新型軟體生命週期模型2.5.1RUP2.5.2敏捷模型2.5.1RUPRUP（RationalUnifiedProcess）統一過程模型是由Rational公司（現被IBM公司收購）開發的一種軟體工程過程框架，是一個面向對象的基於web的程式開發方法論。RUP既是一種軟體生命週期模型，又是一種支持面向對象軟體開發的工具，它將軟體開發過程要素和軟體工件要素整合在統一的框架中。2.5.1RUPRUP的基本結構2.5.1RUPRUP中的軟體生命週期在時間上被分解為四個順序的階段：初始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）和交付階段（Transition）。每個階段結束於一個主要的里程碑(MajorMilestones)，並在階段結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許專案進入下一個階段。2.5.1RUPRUP的9個核心工作流6個核心過程工作流商業建模（BusinessModeling）需求（Requirements）分析和設計（Analysis&Design）實現（Implementation）測試（Test）部署（Deployment）2.5.1RUP3個核心支持工作流：配置和變更管理（Configuration&ChangeManagement）專案管理（ProjectManagement）環境（Environment）2.5.1RUP初始階段目標是為系統建立商業案例（businesscase）並確定專案的邊界。商業案例包括專案的驗收規範、風險評估、所需資源估計、階段計畫等。要確定專案邊界，需識別所有與系統交互的外部實體，並在較高層次上定義外部實體與系統交互的特性，主要包括識別外部角色（actor）、識別所有用例並詳細描述一些重要的用例。階段結束里程碑：生命週期目標（LifecycleObjective）里程碑，包括一些重要的文檔，如：專案構想（vision）、原始用例模型、原始業務風險評估、一個或者多個原型、原始商業案例等。需要對這些文檔進行評審，以確定正確理解用例需求、專案風險評估合理、階段計畫可行等。2.5.1RUP細化階段目標是分析問題領域，建立健全的體系結構基礎，編制專案計畫，完成專案中高風險需求部分的開發。里程碑：生命週期體系結構（LifecycleArchitecture）里程碑。包括風險分析文檔、軟體體系結構基線、專案計畫、可執行的進化原型、初始版本的用戶手冊等。通過評審確定軟體體系結構已經穩定、高風險的業務需求和技術機制已經解決、修訂的專案計畫可行等。2.5.1RUP構造階段將所有剩餘的技術構件和穩定業務需求功能開發出來，並集成為產品，所有功能被詳細測試。從某種意義上說，構造階段只是一個製造過程，其重點放在管理資源及控制開發過程以優化成本、進度和品質。里程碑：初始運行能力（InitialOperationalCapability）里程碑。包括可以運行的軟體產品、用戶手冊等，它決定了產品是否可以在測試環境中進行部署。此刻，要確定軟體、環境、用戶是否可以開始系統的運行。2.5.1RUP移交階段移交階段的重點是確保軟體對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發佈做準備的產品測試，基於用戶回饋的少量調整。里程碑：產品發佈(ProductRelease)里程碑。此時，要確定最終目標是否實現，是否應該開始產品下一個版本的另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的相重合。2.5.1RUPRUP的迭代增量開發思想RUP是融合了噴泉模型和增量模型的一種綜合生命週期模型。每一次迭代就是為了完成一定階段性小目標而從事的一系列開發活動。2.5.1RUPRUP通過迭代增量建模思想提高了風險控制能力，這體現在：⑴迭代計畫安排是風險驅動的，高風險因素集中在前兩個階段解決，特別是體系結構級的風險在細化階段就得到瞭解決，及早降低了系統風險；⑵每一次迭代都包括需求、設計、實施、部署和測試活動，因此，每一個中間產品都得到了集成測試，而且這個集成測試是在一個統一的軟體體系結構指導下完成的；2.5.1RUP⑶每一個階段結束時還有嚴格的品質評審，保證里程碑文檔的品質；⑷由於中間版本的產品是逐步產生的，而且核心功能和性能需求已經包含在前面的版本中，所以，可以根據市場競爭的情況適時推出中間版本，降低市場風險。2.5.1RUPRUP的最佳實踐：⑴短時間分區式的迭代：2～6周，不鼓勵時間推遲；⑵適應性開發：小步驟、快速回饋和調整；⑶在早期迭代中解決高技術風險和高業務價值的問題；⑷不斷地讓用戶參與迭代結果的評估，並及時獲取回饋資訊，以逐步闡明問題並引導專案進展；⑸在早期迭代中建立內聚的核心架構。2.5.1RUP⑹不斷地驗證品質；儘早、經常和實際地測試；⑺使用用例驅動軟體建模：用例是獲取需求、制定計畫、進行設計、測試、編寫終端用戶文檔的驅動力量。⑻可視化軟體建模：使用UML（UnifiedModelingLanguage，統一建模語言）進行軟體建模。⑼仔細地管理需求：不要草率地對待需求，而要有機地進行需求的提出、記錄、等級劃分、追蹤。拙劣的需求管理是專案陷入麻煩的一個常見原因。⑽實行變更請求和配置管理。2.5.1RUPRUP是一個通用的過程範本，包含了很多開發指南、工件、開發過程所涉及到的角色說明等，因此，具體開發機構在應用RUP開發專案時要做裁剪。RUP裁剪可以分為以下幾步：⑴確定本項目需要的工作流。⑵確定每個工作流需要的工件。⑶確定4個階段之間的演進計畫。以風險控制為原則，決定每個階段實施的工作流，每個工作流的執行程度，生成的工件及其完成程度等。⑷確定每個階段內的迭代計畫。規劃RUP的4個階段中每次迭代開發的內容。⑸規劃工作流內部結構。用活動圖（activitydiagram）規劃工作流中涉及的角色、角色負責的活動及產出的工件。2.5.2敏捷模型敏捷建模（AgileModeling，AM）是由ScottW.Ambler從許多的軟體開發過程實踐中歸納總結出來的一些敏捷建模價值觀、原則和實踐等組成的，它只是一種態度，不是一個說明性過程。AM是對已有生命週期模型的補充，它本身不是一個完整的方法論，在應用傳統的生命週期模型時可以借鑒AM的過程指導思想。2.5.2敏捷模型敏捷建模的價值觀：個人和交互勝過過程和工具；實用的軟體勝過面面俱到的文檔；客戶合作勝過合同談判；回應變化勝過遵循計畫。溝通、簡單、回饋、勇氣、謙遜2.5.2敏捷模型敏捷建模原則：(1)優先考慮的是通過儘早地和不斷地提交有價值的軟體使客戶滿意；(2)即使到了開發的後期，也歡迎改變需求；(3)敏捷過程利用變化來為客戶創造競爭優勢；(4)經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好；(5)圍繞被激勵起來的個體來構建專案；(6)給他們提供所需的環境和支持，並且信任他們能夠完成工作；2.5.2敏捷模型(7)在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談；工作的軟體是首要的進度度量標準；敏捷過程提倡可持續的開發速度；(8)責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度；(9)優秀的技能和好的設計會增強敏捷能力；(10)簡單是最根本的；(11)最好的構架、需求和設計出於自組織團隊；(12)每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，對自己的行為進行調整。2.5.2敏捷模型敏捷建模核心實踐專案干係人的積極參與正確使用工件集體所有制測試性思維並行創建模型創建簡單的內容簡單地建模公開展示模型

切換到另外的工件

小增量建模

和他人一起建模

用代碼驗證

使用最簡單的工具

2.5.2敏捷模型敏捷模型補充實踐：使用建模標準逐漸應用模式（pattern）丟棄臨時模型合同模型要正式為外部交流建模為幫助理解建模重用現有的資源不到萬不得已不更新模型極限編程極限編程(eXtremeProgramming，XP)是敏捷模型的一種實現過程，由Kent

Beck在1996年提出。極限編程極限編程的12個實踐：（1）小版本。為了高度迭代，與客戶展現開發的進展，小版本發佈是一個可交流的好辦法，客戶可以針對性提出回饋。但小版本把模組縮得很小，會影響軟體的整體思路連貫，所以小版本也需要總體合理的規劃。（2）規劃遊戲。就是客戶需求，以客戶故事的形式，由客戶負責編寫。極限編程不講求統一的客戶需求收集，也不是由開發人員整理，而是採取讓客戶編寫，開發人員進行分析，設定優先順序別，並進行技術實現。當然遊戲規則可進行多次，每次迭代完畢後再行修改。客戶故事是開發人員與客戶溝通的焦點，也是版本設計的依據，所以其管理一定是有效的、溝通順暢的。極限編程（3）現場客戶。極限編程要求客戶參與開發工作，客戶需求就是客戶負責編寫的，所以要求客戶在開發現場一起工作，並為每次迭代提供回饋。（4）隱喻。隱喻是讓專案參與人員都必須對一些抽象的概念理解一致，也就是我們常說的行業術語，因為業務本身的術語開發人員不熟悉，軟體開發的術語客戶不理解，因此開始要先明確雙方使用的隱喻，避免歧異。（5）簡單設計。極限編程體現跟蹤客戶的需求變化，既然需求是變化的，所以對於目前的需求就不必過多地考慮擴展性的開發，講求簡單設計，實現目前需求即可。簡單設計的本身也為短期迭代提供了方便，若開發者考慮“通用”因素較多，增加了軟體的複雜度，開發的迭代週期就會加長。極限編程（6）重構。重構是極限編程先測試後編碼的必然需求，為了整體軟體可以先進行測試，對於一些軟體要開發的模組先簡單模擬，讓編譯通過，到達測試的目的。然後再對模組具體“優化”，所以重構包括模組代碼的優化與具體代碼的開發。重構是使用了“物理學”的一個概念，是在不影響物體外部特性的前提下，重新優化其內部的機構。這裏的外部特性就是保證測試的通過。（7）測試驅動開發。極限編程是以測試開始的，為了可以展示客戶需求的實現，測試程式優先設計，測試是從客戶實用的角度出發，客戶實際使用的軟體介面著想，測試是客戶需求的直接表現，是客戶對軟體過程的理解。測試驅動開發，也就是客戶的需求驅動軟體的開發。（8）持續集成。集成的理解就是提交軟體的展現，由於採用測試驅動開發、小版本的方式，所以不斷集成(整體測試)是與客戶溝通的依據，也是讓客戶提出回饋意見的參照。持續集成也是完成階段開發任務的標誌。極限編程（9）結對編程。這是極限編程最有爭議的實踐。就是兩個程式員合用一臺電腦編程，一個編碼，一個檢查，增加專人審計是為了提供軟體編碼的品質。兩個人的角色經常變換，保持開發者的工作熱情。這種編程方式對培養新人或開發難度較大的軟體都有非常好的效果。（10）代碼共有。在極限編程裏沒有嚴格文檔管理，代碼為開發團隊共有，這樣有利於開發人員的流動管理，因為所有的人都熟悉所有的編碼。（11）編碼標準。編碼是開發團隊裏每個人的工作，又沒有詳細的文檔，代碼的可讀性是很重要的，所以規定統一的標準和習慣是必要的，有些象編碼人員的隱喻。（12）每週40小時工作。極限編程認為編程是愉快的工作，不輕易加班，今天的工作今天做，小版本的設計也為了單位時間可以完成的工作安排。本章內容3.1基於電腦系統的系統分析3.2可行性分析3.3系統體系結構建模3.4系統流程圖3.5系統分析總結3.1基於電腦系統的系統分析本節內容3.1.1電腦系統工程3.1.2系統需求識別3.1.1電腦系統工程Webster定義的電腦系統是：元素的集合或排列，這些元素被組織在一起，以便通過處理外部資訊完成某些預定的目標。這些系統元素是：軟體：指程式、數據結構和相關文檔。硬體：指提供計算能力的電子設備和提供外部功能的機電設備（感測器、馬達等）。人員：指使用硬體和軟體的用戶和其他人員。文檔：指手冊、表格和其他表示系統使用和操作的描述性資訊。資料庫：指系統所具有的資訊模型，是系統中對資訊具有存取功能的一個主要部分。過程：指定義每一種系統元素的特定使用步驟或使用環境。

3.1.1電腦系統工程電腦系統工程是一個問題求解活動，目的是揭示、分析所期望的功能、性能、介面和約束條件，並把它們分配到各個系統元素中去。電腦的系統工程包括：硬體工程、軟體工程、人機工程和數據庫工程，每一項工程的作用就是明確和細化系統的功能和性能的範圍和內容，產生一個能與其他系統元素適當集成的可操作的系統元素。硬體工程軟體工程3.1.2系統需求識別系統分析目標識別用戶要求；進行技術分析並進行評價；把功能分配給系統元素；建立成本和進度限制；生成系統規格說明（包括軟體和硬體）。可通過回答以下問題協助完成系統分析過程系統的總體目標是什麼？系統所期望的功能和性能是什麼？系統的可靠性和品質要求是什麼？成本與進度限制如何？有無軟硬體製造和購買的需求？有效的技術方案有哪些？將來系統可能有哪些擴充？3.2可行性分析本節內容：3.2.1可行性分析的任務和步驟3.2.2經濟可行性分析3.2.3技術可行性分析為什麼要進行可行性分析影響系統開發的因素有哪些？時間因素資源因素成本和利潤的因素技術條件和能力的因素系統分析和可行性分析的目的是明確系統是否值得做，避免投資損失衡量軟體系統是否值得做的標準：能否帶來經濟效益、企業效益或社會效益。援引柳傳志的一段話：“沒錢賺的事我們不幹；有錢賺但投不起錢的事不幹；有錢賺也投得起錢但沒有可靠的人選，這樣的事也不幹。”3.2.1可行性分析的任務和步驟首先，針對專案確定問題域並對問題域進行概要的分析和研究，初步確定專案的規模、約束和限制條件。其次，針對問題域中的關鍵和核心問題進行簡要的需求分析，抽象出問題域的邏輯結構，並構建邏輯模型。最後從邏輯模型出發，通過小規模的設計和技術實現論證，探索出若干種可供選擇的解決方案，並對每種方案進行可行性方面的論證。可行性分析主要集中在以下四個方面：經濟可行性分析 技術可行分析法律可行性分析 實施方案的選擇3.2.2經濟可行性分析軟體開發為何要進行經濟方面的分析？軟體開發需要有投資，有投資就需要有收益。目的是從經濟角度評價一個新專案是否可行、是否划算，從而幫助投資人或者用戶正確地做出是否投資於這個專案的開發決策。如何進行經濟可行性的分析？成本/效益分析是對軟體的開發成本和可能取得的效益進行權衡比較。短期/長遠利益分析而是從另一種角度來評價成本和效益之間的關係。軟體成本的估算方法軟體開發體現為最終可運行的軟體系統以及相應的開發過程，為此有以下估算軟體成本的方法：代碼行技術每行代碼的成本×代碼行數；代碼行數：根據經驗和歷史數據估計；每行代碼成本：根據軟體複雜度和開發人員工資估計；功能點技術以軟體功能作為測量依據；功能點測量法；任務分解技術將整個開發過程分解為幾個獨立的任務；評估每個任務的成本，再求和得到整個系統的成本；每個任務成本＝每人月平均成本×人月數；軟體成本的估算方法經驗估算模型根據以往經驗總結出軟體成本估算模型，軟體規模（例如LOC）作為模型的輸入；不同的專案需要對模型參數進行相應調整；COCOMO模型BarryBoehm在《軟體工程經濟學》仲介紹的軟體估算模型，稱為COCOMO（ConstructiveCostMOdel），該模型為分層模型，分為基本模型、中級模型和高級模型。軟體方程式：多變量模型軟體成本的估算方法軟體的其他成本估算：除了以上主要的軟體開發成本之外，還必須考慮支撐軟體開發所必需的市場、銷售和行政等項的開支，根據經驗有如下內容需要考慮：辦公室房租、現場開發住宿費等。辦公用品，如桌、椅、書櫃、照明電器、空調等。電腦、印表機、網路等硬體設備。電話、傳真等通訊設備以及通訊費用。資料費。辦公消耗，如水電費、列印複印費等。行政人員的工資。差旅費、國內外出差補貼等。做市場調查、可行性分析、需求分析的交際費用。公司人員培訓費用。產品宣傳費用。如果用Internet作宣傳，則要考慮建設Web站點的費用。軟體開發的效益度量貨幣的時間價值：由於任何軟體專案大都是投資在前，取得效益在後，因此要考慮到貨幣的時間價值。設年利率為i，現存入P元，若計複利則n年後貨幣價值為反之，若n年能收入F元，那麼這些錢的現值是軟體開發的效益度量例如：某企業花20萬引進資訊化系統後，每年節省9.6萬元的人力成本，若該軟體生命週期為5年，銀行年利率5%，請計算其節約的成本的當前價值是多少？解：因為：所以：第n年節約成本當前價值=第n年節約成本/(1+0.05)n軟體開發的效益度量投資回收期：就是使累計的經濟效益等於最初的投資費用所需的時間。投資回收期越短，就能越快獲得利潤。設上例中的投資回收期為N，則：（N-2）*8.29=20-17.85N=2.259年純收入：就是在整個生存期之內系統的累計經濟效益（折合成現在值）與投資之差。純收入>0說明值得投資純收入=0等於把資金存入銀行純收入<0說明不值得投資上例中的純收入為：41.563-20=21.563萬元軟體開發的效益度量投資回收率：設想把數量等於投資額的資金存入銀行，每年年底從銀行回收的錢等於系統每年預期可以獲得的效益，在時間等於系統壽命時，正好把在銀行中的存款全部取完。這個假想的年利率就等於投資回收率。P＝F1／(1+j)+F2／(1+j)2+…+Fn／(1+J)n其中，P是現在的投資額；Fi是第i年年底的效益（i＝1,2,…,n）；n是系統的使用壽命，j是投資回收率。3.2.3技術可行性分析技術可行性分析主要考慮以下幾項內容：開發風險：在給定的限制範圍內，能否設計出系統，並實現必須的功能和性能？資源可用性：是否有充足的熟練技術人員可以支配？其他必要的資源（軟體和硬體）對建造系統可用麼？技術條件：相關的技術條件是否能夠支持系統的開發？最終得出一個在技術層面上的決策基礎：可行，還是不可行！技術可行性分析的機制Blanchard和Fabrycky定義了在系統的技術可行性分析中使用建模方法的一組標準：能動態地表示系統的配置並能進行評估，要求配置項很容易理解和操縱、並且與現實操作足夠接近。模型應該盡可能全面的包括所有相關的因素，並且應體現結果的可重複性。模型應該關注那些關鍵問題的因素，並且抑制和回避那些不重要的因素。模型設計應該足夠簡單，以允許快速實現。模型設計應該易於修改和/或擴展。3.3系統體系結構建模本節內容：3.3.1構建系統級體系結構3.3.2系統結構的規格說明定義3.3.3分配與權衡3.3.1構建系統級體系結構每個基於電腦的系統可用輸入-處理-輸出（IPO）的結構來為資訊的變換和處理建模，在附加經常使用的用戶介面處理和維護自測試處理特性，構成了系統體系結構範本。通過創建一個系統結構模型，為後期的需求分析和設計奠定了基礎，同時也是技術可行性分析建模的主要方法。體系結構語境圖ACD最高層的系統體系結構叫做體系結構語境圖ACD。語境圖建立了待實現系統與系統運行環境之間的資訊邊界： 定義了系統使用資訊的所有外部生產者；系統創建消息的所有外部消費者；所有通過介面通信或完成維護和自測的實體；構建ACD實例描述分類帶傳送系統（CLSS）分類站處設置PC程式軟體，能夠通過掃描輸入帶上的產品的條碼，根據系統存儲的產品分類資訊對產品進行分類，並結合傳送帶的速度，對分類控制器硬體進行控制，對產品進行分類。此外，程式還可以與中央工廠自動化主機進行通信；並與分類站操作人員進行交互，支持資訊查詢和故障診斷。CLSS的ACDCLSS的AFD體系結構流程圖AFD的擴展最初的AFD中的每個圓角矩形又可被擴展為另一個專門描述它的體系結構範本。每個子系統的說明描述和在子系統間流動的所有數據的定義構成了系統規約的重要元素。3.3.2系統結構的規格說明定義結構圖的規格說明（ADS）給出了每個子系統的資訊、各個子系統之間的資訊流以及每個子系統的“系統模組描述”。規格說明還可能具有一個“結構詞典”，即在規格說明中出現的每一個資訊項的清單，以及每個資訊項的說明。例如AFD中的“部分號碼”的說明如下：

資訊項名稱部分號碼資訊項說明產品類型首碼+數字標識+成本類型類型（數據或控制）數據來源（外部實體或子系統）條碼閱讀器控制子系統去處（外部實體或子系統）資料庫訪問子系統通信路徑（名稱）內部軟體介面3.3.3分配與權衡3.4系統流程圖本節內容：3.4.1符號3.4.2示例3.4.3分層3.4.1符號3.4.2示例3.4.3分層如果系統比較複雜，可以採用流程圖分層次地描述系統。高層的系統流程圖描述系統總體概貌，定義其中的關鍵功能。對每個關鍵功能再進一步擴展為獨立的流程圖。3.5系統分析總結本節內容：3.5.1系統規格說明書3.5.2可行性分析報告本章內容4.1什麼是軟體的需求4.2軟體需求分析的目標和任務4.3軟體需求分析建模的原則和方法4.4軟體需求工程4.5軟體需求分析過程本章目標為何要進行軟體的需求分析？軟體的需求分析處於軟體生命週期的那個階段？起到什麼作用？怎樣才能做好軟體需求分析？軟體需求分析的過程和步驟是什麼？軟體需求分析的最終結果是什麼？4.1什麼是軟體的需求4.1.1需求的定義4.1.2需求分析失敗案例4.1.1需求的定義需求來源於用戶的一些“需要”，這些“需要”被分析、確認後形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什麼。Boehm給出軟體需求的定義：研究一種無二義性的表達工具，它能為用戶和軟體人員雙方都接受，並能夠把“需求”嚴格地、形式地表達出來。“需求、設計、編程、測試四者究竟哪個環節最重要？”首先，每個環節都是很重要，任何一個環節出現問題，都會導致軟體的品質問題。但是，從風險管理的角度來看，需求是軟體產品的起源，因而是最重要的一個環節。4.1.2需求分析失敗案例某大型的電信設備供應商，案例中涉及6個部門A,B,C,D,E和F，它們之間的關係如下圖所示：F客戶E：網管軟體承包商D銷售機構A：增值業務研發機構C：專案管理機構B：核心平臺研發機構一年前，B研製了一種數據接入伺服器的原型。B對A講：“我們的接入伺服器前途很好，請你們幫助開發網管軟體（屬於增值業務範疇），大家合作把產品做好，一起發財。”D對B和A講：“你們把接入伺服器和網管軟體做好，我們負責賣，掙了錢大家一起分。”4.1.2需求分析失敗案例A覺得機會難得，於是向C申請立項。立項後，A把專案外包給專業做網管軟體的公司E，期望半年內完成。由於接入伺服器是B的，於是A和E就派開發人員到B處搞需求分析。B的接入伺服器並不成熟，老在變，三方折騰了好久，最終E用了一年時間把接入伺服器的網管軟體做出來了。

E把網管軟體交付給A，A付清了E的開發費用，再把網管軟體交付給D，D再賣給客戶F（某地電信局）。F對D講：“你們的網管軟體不是我們想要的東西，等你們把軟體改好後我們再付錢。”D趕緊對A講：“兄弟阿，貨已經出手了，但是不對路，請趕緊把它改好，不然大家都沒錢賺。”A很憤怒，怨天不公：“我們辛苦了一年，又花了很多錢，可是產品做完了卻沒人要，豈有此理！”4.1.2需求分析失敗案例禍不單行的是，C來找A的麻煩：“你們的專案延期半年多了，經費也用光了，請儘快結束專案。”A的那位專案經理為此每天愁眉苦臉，他的上司請來幾位參謀商量對策，設法把事情搞定。大家挖空心思只想出一個餿主意：既然套子是B下的，那麼就把套子還給B。要設法把“那麼好”的網管產品轉讓給B，只要B能給我們成本費，以後就跟B拜拜。這個案例的問題根源在於進行軟體開發之前沒有搞清楚網管軟體的需求，這都是B,A,E閉門造車惹的禍。最可悲的是，相關責任人關心的是如何把事情“完成”，而不是深刻瞭解用戶的具體需求。這種類似的事情在軟體開發行業中經常發生而且還會繼續發生，最主要的是每發生一次就損失大量的人力和物力。4.2軟體需求分析的目標和任務需求分析是一項必須的軟體工程活動。它在系統需求分析和軟體設計之間起到橋樑的作用：它使得軟體開發人員在系統分析的基礎上深入描述軟體的功能和性能、指明軟體和其他系統元素的介面，建立軟體必須滿足的約束條件。它允許軟體開發人員對關鍵問題進行細化，並構建相應的分析模型：數據、功能和行為模型。分析模型成為設計模型的基礎，需求規格說明書也為軟體測試人員和用戶提供了軟體品質評估的依據。它能準確表達用戶對系統的各項要求。4.2軟體需求分析的目標和任務軟體需求分析的對象是用戶要求。其任務是要準確地定義新系統的目標。回答系統必須“做什麼”的問題並編制需求規格說明書。作為目標系統的參考，需求分析的任務就是借助於（業務）系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的“做什麼”的問題。軟體開發的目標需求分析的目標4.2軟體需求分析的目標和任務（1）獲得當前系統的物理模型：分析、理解當前系統（人工處理或原電腦系統）是如何運行的，瞭解其組織機構、輸入輸出、資源利用情況和日常數據處理過程。（2）抽象出當前系統的邏輯模型：在理解當前系統“怎樣做”的基礎上，抽取其“做什麼”的本質。（3）建立目標系統的邏輯模型：分析目標系統與當前系統邏輯上的差別，明確目標系統到底要“做什麼”，進而從當前系統的邏輯模型導出目標系統的邏輯模型。（4）對邏輯模型的補充：包括說明目標系統的用戶介面、系統細節和性能限制等。4.3需求分析建模的原則和方法4.3.1數據建模4.3.2功能和行為建模4.3.3問題劃分需求分析的三元模型需求分析方法的一組操作性原則是：問題的資訊域必須被表示和理解。軟體將完成的功能必須被定義。軟體的行為（作為外部事件的結果）必須被表示。描述資訊、功能和行為的模型必須被劃分，使得可以用層次的方式揭示細節。分析過程應該遵從自頂向下，逐層細化的原則。需求分析的三元模型：數據模型——第1條原則功能模型——第2條原則行為模型——第3條原則需求工程的指導性原則首先要正確地理解問題，再建立分析模型。記錄每個需求的起源及原因，保證需求的可回溯性。開發一個能使用戶能夠瞭解人機交互過程的原型。因為對軟體品質的感覺經常基於對介面“友好性”的感覺。使用多個需求視圖。建立數據模型、功能模型和行為模型，為軟體工程師提供三種不同的視圖，增加識別不一致性的基礎。給需求賦予優先順序。緊張的開發時間要求儘量避免一次性實現每個軟體需求，應採用迭代增量的開發模型。努力刪除歧義性。因為大多數需求以自然語言描述，存在歧義性的可能性，正式的技術評審是發現並刪除歧義性的一種有效方法。4.3.1數據建模資訊域包含三個不同的數據和控制視圖：資訊內容和關係；資訊流；資訊結構。資訊流表示了數據和控制在系統中流動時變化的方式資訊內容表示了個體數據和控制對象；數據和控制對象可和其他的數據和控制對象關聯資訊結構表示了各種數據和控制項的內部組織4.3.2功能和行為建模功能模型：對進入軟體的資訊和數據進行變換和處理的模組，它必須至少完成三個常見功能：輸入、處理和輸出。行為模型：大多數軟體對來自外界的事件做出反應，這種刺激／反應特徵形成了行為模型的基礎。行為模型創建了軟體狀態的表示，以及導致軟體狀態變化的事件的表示。功能模型和行為模型的作用如下：模型能夠幫助軟體開發人員快速準確的理解系統所涉及的資訊、功能和動態行為；模型可成為後期軟體設計的基礎，為軟體設計人員提供了設計軟體功能的視圖化表示；模型能夠成為軟體測試和軟體評審的重要依據4.3.3問題劃分需求問題域涉及面廣泛而且複雜，以至於難以進行整體理解。為此，需要將這樣的問題劃分為易於理解的子問題，並建立各子問題間的關係以使得可以完成整個功能。軟體的資訊、功能和行為域可以被劃分。在本質上，劃分將問題分解為其構成成分。在概念上，建立資訊或功能的層次結構表示，通過進行自頂向下的分析，進而暴露更多的細節問題，並在各層次上進行各功能元素的分配。4.4軟體需求工程軟體的需求分析是一系列複雜的軟體工程活動，為了便於對需求進行更好的管理，人們把所有與需求直接相關的活動通稱為需求工程。需求工程需求開發需求變更控制需求管理需求確認需求跟蹤需求獲取需求分析需求定義用戶需求說明書軟體需求規格說明書需求跟蹤矩陣

需求評審報告

需求變更控制報告4.5軟體需求分析過程4.5.1軟體需求獲取的對象及注意事項4.5.2需求獲取4.5.3需求類別4.5.4需求分析與綜合4.5.5需求建模4.5.6編制需求分析文檔4.5.7需求確認4.5.8需求分析評審4.5.1軟體需求獲取的對象及注意事項需求獲取的對象：用戶“用戶”（user）是一種泛稱，它可細分為：“客戶”（Customer）：掏錢買軟體的用戶“最終用戶”（Enduser）：真正操作軟體的用戶“間接用戶”（或稱為關係人）如果軟體是面向企業用戶的，那麼客戶與最終用戶通常不是同一個人。如果軟體是面向個人用戶的，那麼客戶與最終用戶通常是同一個人。軟體需求獲取的注意事項用戶無法清晰地表達需求本身不清楚要做什麼知道做什麼卻表達不准確需求分析員的職責就是設法搞清楚用戶真正的需求。雙方或多方對需求的理解往往存在歧義需求會經常發生變化：避免由於溝通不充分而發生的變更；歡迎因環境變化造成的變更；需求變更並不可怕，可怕的是需求變更失去控制，導致專案混亂。4.5.2需求獲取目的獲取用戶（客戶與最終用戶）的需求資訊，經過分析後產生《用戶需求說明書》。角色與職責需求分析員調查、分析用戶的需求，客戶與最終用戶提供必要的需求資訊。啟動準則需求分析員已經確定輸入任何與用戶需求相關的材料主要步驟第一步：準備調查第二步：調查與記錄第三步：分析需求資訊第四步：撰寫《用戶需求說明書》第五步：需求確認輸出《用戶需求說明書》結束準則需求分析員已經撰寫完成《用戶需求說明書》，確保無拼寫、排版等錯誤。並確保《用戶需求說明書》的內容無二義性，且涵蓋了所有的用戶需求。度量需求分析員統計工作量和上述文檔的規模，彙報給專案經理。需求獲取流程：需求獲取的準備工作需求獲取的準備工作圍繞三項展開：調查什麼？通過什麼方式去調查？“何人”在“何時”調查？首先，應起草需求調查問題表，將重點鎖定在該問題表內，否則調查工作將變得漫無邊際。其次，應當確定需求調查的方式，比如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發調查問卷。與同行、專家交談，聽取他們的意見。需求獲取的記錄準備工作完畢後，需求分析員按照計畫執行調查。在調查過程中隨時記錄（或存儲）需求資訊，建議採用表格的形式，如下圖：需求標題1調查方式調查人調查對象時間、地點需求資訊記錄基本要素如“是什麼”、“為什麼”等需求獲取注意事項如果與用戶約好了時間，切勿遲到或早退。要注意禮節，盡可能獲得用戶的好感，並為下次打擾他們埋下伏筆。需求分析員應事先瞭解用戶的身份、背景，以便隨機應變。需求調查應該先瞭解宏觀問題，再瞭解細節問題。如果雙方氣氛融洽，可以採用靈活的訪談形式，輕易不要打斷用戶的談話。當雙方對某些問題的交流合乎邏輯地結束後，即可繼續討論問題表中的其他問題。盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調查的力度。避免片面地聽取某些用戶的需求而忽視其他用戶的需求。撰寫用戶需求說明書對收集到的所有需求資訊進行分析，消除錯誤，歸納與總結共性的用戶需求。按照規定的文檔範本撰寫《用戶需求說明書》，調查過程中獲取的需求資訊可以作為《用戶需求說明書》的附件。之後應當邀請同行專家和用戶一起評審《用戶需求說明書》，盡最大努力使《用戶需求說明書》能夠正確無誤地反映用戶的真實意願。用戶需求說明書與

軟體需求規格說明書的區別前者主要採用自然語言來表達用戶需求，其內容相對於後者而言比較粗略，不夠詳細。後者是前者的細化，更多地採用電腦語言和圖形符號來刻畫需求，軟體需求是軟體系統設計的直接依據。兩者之間可能並不存在一一映射關係，因為軟體開發商會根據產品發展戰略、企業當前狀況適當地調整軟體需求，例如用戶需求可能被分配到軟體的數個版本中。軟體開發人員應當依據《軟體需求規格說明書》來開發當前產品。4.5.3需求類別功能需求：列舉出所開發軟體在功能上應做什麼，這是最主要的需求。性能需求：給出所開發軟體的技術性能指標，尤其是系統的即時性和其他時間要求，如回應時間、處理時間、消息傳送時間等；資源配置要求，精確度，數據處理量等要求。環境需求：是對軟體系統運行時所處環境的要求。在硬體方面，採用什麼機型、有什麼外部設備、數據通信介面等等。在軟體方面，採用什麼支持系統運行的系統軟體（指操作系統、網路軟體、資料庫管理系統等）。在使用方面，需要使用部門在制度上、操作人員的技術水準上應具備什麼樣的條件等等。4.5.3需求類別可靠性需求：指軟體的有效性和數據完整性。各種軟體在運行時失效的影響各不相同。在需求分析時，應對所開發軟體在投入運行後不發生故障的概率，按實際的運行環境提出要求。安全保密要求：工作在不同環境的軟體對其安全、保密的要求顯然是不同的，應當把這方面的需求恰當地做出規定。用戶介面需求：軟體與用戶介面的友好性是用戶能夠方便有效愉快地使用該軟體的關鍵之一。4.5.3需求類別資源使用需求：指所開發軟體