面向?qū)ο蟮能浖こ陶n件

2024-1-241第一章緒論軟體工程產(chǎn)生的背景軟體工程的有關概念軟體生存週期及軟體過程模型軟體開發(fā)方法軟體開發(fā)工具2024-1-2421.1軟體的特點、發(fā)展及軟體危機⒈軟體的概念及其特點◆軟體是⑴當它被執(zhí)行時提供希望功能和性能的程式，⑵使得程式能夠適當?shù)牟僮髻Y訊的數(shù)據(jù)結(jié)構(gòu)，以及⑶描述程式被開發(fā)和運行過程中有關功能、結(jié)構(gòu)、操作和使用的文檔?！糗涹w特徵：

?軟體是邏輯的而不是有形的產(chǎn)品，它是被開發(fā)或設計出的，而非傳統(tǒng)意義上的被製造的。軟體成本和軟體品質(zhì)集中於開發(fā)上。

?軟體不會“磨損”。軟體並不受到引起硬體磨損的環(huán)境因素的影響。2024-1-2432024-1-244

?軟體生產(chǎn)正走向基於構(gòu)件的組裝發(fā)展（如圖形用戶介面），但目前多數(shù)軟體仍是定做的。

?軟體的研製需要投入大量的、複雜的腦力勞動，成本高。⒉軟體的發(fā)展◆雙重角色：它是一個產(chǎn)品，通過電腦硬體所體現(xiàn)的計算潛能，它產(chǎn)生、管理、獲取、修改、顯示或傳送資訊，這些資訊簡單到一個bit，複雜到一個多媒體資訊；它是產(chǎn)品交付使用的載體，是電腦控制的基礎（操作系統(tǒng)）、資訊通信的基礎及其它軟體的創(chuàng)建和控制的基礎（軟體工具和環(huán)境）。

2024-1-245

◆角色的演化：早期（50年代初-60年代中期）：

?自定義軟體

?面向批處理第二階段（60年代中期-70年代末期）：

?多用戶

?即時

?資料庫

?軟體產(chǎn)品軟體危機出現(xiàn)！2024-1-246

第三階段（70年代中期-80年代中期）：

?分佈式系統(tǒng)

?嵌入式“智能”軟體

?低成本硬體

?大眾化第四階段（80年代中期至今）：

?強大的桌面系統(tǒng)

?面向?qū)ο蠹夹g(shù)

?人工智慧

?神經(jīng)網(wǎng)路

?並行計算

…2024-1-247

3.軟體危機(crisis)

60年代中期，隨著硬體技術(shù)的發(fā)展，軟體應用範圍的擴展，軟體越來越大型化、複雜化，產(chǎn)生了上萬行的根源程式。當發(fā)現(xiàn)錯誤是需要對這些程式進行修改；當用戶需求發(fā)生變化是需要修改；當硬體環(huán)境更新時需要修改。這些活動（稱為軟體維護）的費用以驚人的速度增加。更糟糕的是，許多程式的個性化特性使得它們根本不能維護?！败涹w危機”出現(xiàn)了!

2024-1-248

◆表現(xiàn)：

?

開發(fā)的軟體不能滿足用戶要求。

?

無完整、規(guī)範的文檔，難以維護。

?

專案計畫不周，進度拖延。

?

軟體品質(zhì)差。

◆原因：

?

缺乏正確的理論指導，開發(fā)人員各行其是。

?

軟體規(guī)模越來越大，無開發(fā)管理經(jīng)驗。

?

軟體複雜度越來越高，而開發(fā)技術(shù)不相適應。

?

缺少先進的開發(fā)工具，開發(fā)方式落後。2024-1-2491.2軟體工程的有關概念

為了克服軟體危機，科學家們從其他產(chǎn)業(yè)(如機械製造、建築等）的工程化生產(chǎn)得到啟示，於1968年在北大西洋公約組織的學術(shù)會上提出了“軟體工程”的概念。工程是對技術(shù)（或社會）實體的分析、設計、構(gòu)造、驗證和管理。這裏只針對一個實體—電腦軟體。◆定義根據(jù)IEEE(TheInstituteforElectricalandElectronicengineers)的定義：

軟體工程是使用系統(tǒng)化的、規(guī)範的、可量化的方法指導軟體開發(fā)、運行和維護的一門學科，它涉及到電腦科學、工程科學、管理科學、數(shù)學等領域的綜合性知識及實踐的應用，它的目的是為建造高質(zhì)量的軟體提供一個框架。2024-1-2410

◆軟體工程層次圖該圖展現(xiàn)了軟體工程研究的內(nèi)容及關注的焦點。

2024-1-2411

過程：定義了一系列活動:

技術(shù)方法的採用，工程產(chǎn)品（模型、文檔、數(shù)據(jù)）的產(chǎn)生，里程碑（milestone)的建立，品質(zhì)的保證及變化的管理。該層構(gòu)成了軟體專案的管理控制的基礎。

方法：提供了建造軟體在技術(shù)上“如何做”。方法覆蓋了一系列任務：需求分析、設計、編程、測試和支持（如糾錯、適應、增強、預防）。

工具：對過程和方法提供了自動或半自動的支持。2024-1-2412

如果不考慮應用領域、專案規(guī)模和複雜性，與軟體工程相關的工作可分為三個一般的階段：

⑴定義階段集中於“做什麼”。搞清楚要處理什麼資訊，預期完成什麼功能和性能，系統(tǒng)將有什麼樣的行為，建立什麼樣的介面，有什麼設計約束，以及建立一個成功系統(tǒng)的確認標準是什麼。

⑵開發(fā)階段集中於“如何做”。即數(shù)據(jù)如何被結(jié)構(gòu)化，功能如何被表示於軟體體系結(jié)構(gòu)中，過程細節(jié)及介面如何實現(xiàn)，設計描述如何被翻譯成程式語言，如何進新測試等活動。⑶支持階段關注於“變化”。為糾正錯誤而做的修改，為適應環(huán)境的演化而做的修改，為增強用戶的需求而做的修改以及使軟體能被更好的維護而進行的軟體再工程。2024-1-2413

軟體通過應用這三個階段實現(xiàn)工程化生產(chǎn)。

還有一些庇護性活動補充上述階段的工作並貫穿於整個軟體工程過程中，如：軟體專案跟蹤與控制、軟體品質(zhì)保證、軟體配置管理等等?！裟芰Τ墒於饶Ｐ虲MM

近年來，“過程成熟度”成為人們關注的焦點。美國Carnegie-Meilon大學的軟體工程研究所（SEI）提出了一個綜合模型，定義了當一個組織達到不同的過程成熟度時應該具有的軟體工程能力。這個綜合模型稱為能力成熟度模型（CapabilityMaturityModel,CMM)。2024-1-2414

該模型定義了5個級別及每個級別上所需的關鍵活動：

⑴初始級(initial):無嚴格定義的活動，專案的成功只依賴於關鍵人物的能力。⑵可重複級（repeatable):建立了基本的專案管理過程：需求管理、專案計畫與跟蹤、品質(zhì)管理、配置管理、合同管理。有類似專案成功的案例和經(jīng)驗。⑶已定義級（defined):包含了第2級的所有特徵。要求制定組織內(nèi)部的工程化標準，包括管理和開發(fā)都需要一套文檔化的標準，並集成到內(nèi)部的軟體過程中去。即所有專案都使用統(tǒng)一的、文檔化的、組織過程認可的版本來開發(fā)和維護軟體。2024-1-2415

⑷已管理級(managed):包含了第3級的所有特徵。該級的管理指量化的管理，即所有的過程需建立相應的度量方式，所有產(chǎn)品的品質(zhì)要有明確的度量指標。量化控制使軟體開發(fā)真正變成工業(yè)生產(chǎn)活動。⑸優(yōu)化級(optimizing):包含了第4級的所有特徵。能根據(jù)回饋資訊進行不斷的過程改進，這些回饋資訊來自於前期過程執(zhí)行或試驗新方法新技術(shù)而得到。達到這一級表明該企業(yè)能夠根據(jù)實際的專案性質(zhì)、技術(shù)等因素，不斷調(diào)整軟體生產(chǎn)過程。

2024-1-2416

CMM對軟體企業(yè)有什麼指導作用？

CMM建立了軟體過程評價與改善及軟體生產(chǎn)能力評估的基礎，為軟體企業(yè)提供一整套提高其軟體生產(chǎn)能力的先進思路和方法，並通過評估使企業(yè)可對外證明其在軟體產(chǎn)品提供方面具有的品質(zhì)保證能力，受到全球各軟體企業(yè)的重視和廣泛採用並實施評估。西安交大博通資訊股份有限公司於2002年12月獲得CMM3級認證。

CMM用於改進一個軟體企業(yè)的管理能力。另外TSP(TeamSoftwareProcess）以提高一個開發(fā)團隊的有效性；PSP（PersonalSoftwareProcess)則增強個人的技能與紀律。2024-1-24171.3軟體生存週期及軟體過程模型

軟體生存週期是指一個軟體從定義開始經(jīng)過開發(fā)、運行、維護，直到最後被廢棄的全過程。引入此概念，可以把軟體生存週期劃分為若干階段。一般劃分為：軟體定義、需求分析、軟體設計、編碼、測試及軟體維護等幾個階段。每一階段有明確的任務，把規(guī)模大、結(jié)構(gòu)複雜、管理複雜的軟體開發(fā)變得容易控制和管理。各個階段的活動如何銜接，開發(fā)過程中採用什麼樣的策略，應遵守什麼樣的規(guī)定和制約，將這些活動框架（忽略不必要的細節(jié)）用一種模型表示出來，稱為軟體過程模型（或軟體開發(fā)模型）。2024-1-2418

軟體過程模型的選擇基於專案和應用的性質(zhì)、採用的方法工具以及需要的控制和交付的產(chǎn)品。幾種典型的模型：

⑴瀑布模型(線性順序模型）

2024-1-2419

特點：

?

提供了軟體過程模型的基本框架。

?

強調(diào)了每一階段活動的嚴格順序。

?

品質(zhì)保證觀點：以經(jīng)過評審確認了的階段工作產(chǎn)品（文檔）驅(qū)動下一階段的工作。

?

是一種整體開發(fā)模型，程式的物理實現(xiàn)集中在開發(fā)階段的後期，用戶在最後才能看到自己的產(chǎn)品。

?

適合於用戶需求明確、完整、無重大變化的軟體專案開發(fā)。

2024-1-2420

⑵原型模型

在用戶不能給出完整、準確的需求說明，或者開發(fā)者不能確定演算法的有效性、操作系統(tǒng)的適應性或人機交互的形式等許多情況下，可以根據(jù)用戶的一組基本需求，快速建造一個原型（可運行的軟體），然後進行評估，進一步精化、調(diào)整原型，使其滿足用戶的要求，也使開發(fā)者對將要做的事情有更好的理解。

2024-1-2421

原型的分類：

?

拋棄型：主要用於需求分析階段，針對開發(fā)目標模糊、用戶與開發(fā)者對專案都缺乏經(jīng)驗的情況。建立原型的目的是為了搞清用戶的需求，確定所期望的特性，探索各種方案的可行性。產(chǎn)生完整、一致、準確的需求說明。

?

實驗型：主要用於設計階段，通過原型驗證設計方案的可行性。原型或成為設計結(jié)果的一部分或拋棄。

?

演化型：用於整個開發(fā)階段。原型經(jīng)過不斷擴充，演化為最終的軟體系統(tǒng)。2024-1-2422

存在的問題：

⑴為了使原型儘快的工作，沒有考慮軟體的總體品質(zhì)和長期的可維護性。

⑵為了演示，可能採用不合適的操作系統(tǒng)、編程語言、效率低的演算法，這些不理想的選擇成了系統(tǒng)的組成部分。

⑶開發(fā)過程不便於管理。

有效的使用原型模式是：建造原型僅是為了定義需求，之後就被拋棄（或被部分拋棄），實際的軟體在充分考慮了品質(zhì)和可維護性之後才被開發(fā)。2024-1-2423

⑶增量模型

是一種漸進地開發(fā)逐步完善的軟體版本的模型。

2024-1-2424

特點：

?

反復的應用瀑布模型的基本成分和原型模型的迭代特徵，每一個線型過程產(chǎn)生一個“增量”的發(fā)佈或提交，該增量均是一個可運行的產(chǎn)品。

?

早期的版本實現(xiàn)用戶的基本需求，並提供給用戶評估的平臺。

⑷螺旋模型

對於複雜的大型軟體，開發(fā)一個原型往往達不到要求。螺旋模型將瀑布模型和增量模型結(jié)合起來，加入了風險分析。在該模型中，軟體開發(fā)使一系列的增量發(fā)佈，早期的迭代中，發(fā)佈的增量可能是一個紙上的模型或原型，在以後的迭代中，逐步產(chǎn)生系統(tǒng)更加完善的版本。螺旋模型將開發(fā)過程劃分為幾個螺旋週期，每個週期有三到六個任務區(qū)域，見下圖。2024-1-2425

2024-1-2426

螺旋的第一圈可能產(chǎn)生產(chǎn)品的規(guī)格說明，再下麵的螺旋可能用於開發(fā)一個原型，隨後可能是軟體的更完善的版本。每一圈還要根據(jù)用戶評估的回饋對專案計畫（包括進度、費用）進行調(diào)整。特點：

?

適合於大型系統(tǒng)的軟體開發(fā)，隨著過程的進展演化，開發(fā)者和用戶能夠更好的識別和對待每一個演化級別上的風險。

?

需要相當豐富的風險評估經(jīng)驗和專門知識，使該模型的應用受到一定限制。

?

隨著迭代次數(shù)的增加，工作量加大，軟體開發(fā)成本增加。2024-1-2427

⑸形式化方法模型

是基於形式化語言和程式變換的模型，因此，也稱變換模型。從軟體需求形式化說明開始，經(jīng)過一系列的數(shù)學變換和正確性證明，最終得到系統(tǒng)的目標程式。形式化方法使開發(fā)者應用一個嚴格的數(shù)學符號體系來表示、構(gòu)造和驗證系統(tǒng)，從而大大提高軟體的可靠性。模型見下圖：2024-1-2428

變換模型

形式化規(guī)格說明與需求比較後修正形式化開發(fā)記錄變換n變換2變換1測試系統(tǒng)需求目標系統(tǒng)…2024-1-2429

兩種技術(shù)：

?

基於模型的規(guī)格說明及其變換技術(shù)基於模型的技術(shù)使用數(shù)學上的結(jié)構(gòu)如集合和函數(shù)為系統(tǒng)建模。它們能展現(xiàn)系統(tǒng)的狀態(tài)以簡化對某些行為的描述?；赌Ｐ偷拿枋稣Z言及方法如Z、VDM(ViennaDefinitionMethod)、B、PetriNets等。

?

基於代數(shù)結(jié)構(gòu)及其變換技術(shù)代數(shù)方法適合於對接口的描述。這裏介面被定義為一組對象類或抽象數(shù)據(jù)類型的集合，用介面操作之間的關係來刻畫系統(tǒng)。2024-1-2430

特點：

?

該模型迫使對系統(tǒng)需求的分析在軟體開發(fā)的早期階段完成。在這個階段改正錯誤比在系統(tǒng)被交付之後修改錯誤要經(jīng)濟得多。

?

形式化描述是對非形式化描述技術(shù)的補充?？梢杂脕砭切问交脑敿毜南到y(tǒng)需求描述。描述是精確的和無二義的，避免了由於語言誤解而產(chǎn)生的一些問題。

?

最適合用於安全性、可靠性和保密性等性能要求極高的系統(tǒng)。

?

開發(fā)成本較高。

?

需要嚴格的數(shù)學理論和開發(fā)環(huán)境的支持。

?

難以與用戶進行通信。2024-1-2431

形式化過程模型的一個擴展，稱為淨室軟體工程（cleanroomsoftwareengineering)或淨室模型，它除了強調(diào)分析和設計上的嚴格性，以及使用基於數(shù)學的正確性證明來對設計模型的每個元素進行形式化驗證外，還強調(diào)了統(tǒng)計品質(zhì)控制技術(shù)?；舅枷耄毫η笤诜治龊驮O計階段就消除錯誤，確保正確，然後在無缺陷或“潔淨”的狀態(tài)下實現(xiàn)軟體的製作。關鍵技術(shù)：

?

基於統(tǒng)計過程控制之下的增量開發(fā)

?

基於函數(shù)的規(guī)範、設計、驗證

?

統(tǒng)計測試和軟體認證模型見下圖：2024-1-2432

淨室模型盒結(jié)構(gòu)規(guī)約需求收集形式化設計正確性驗證代碼檢查測試計畫統(tǒng)計性使用測試驗證增量#1盒結(jié)構(gòu)規(guī)約需求收集形式化設計正確性驗證代碼檢查測試計畫統(tǒng)計性使用測試驗證增量#2盒結(jié)構(gòu)規(guī)約需求收集形式化設計正確性驗證代碼檢查測試計畫統(tǒng)計性使用測試驗證增量#1............2024-1-2433

⑹構(gòu)件組裝模型

構(gòu)件（component)也稱為組件，是一段實現(xiàn)一系列有確定介面的程式體，具有自己的功能和邏輯，能同其他構(gòu)件組裝起來協(xié)調(diào)工作。該模型支持軟體重用，對縮短軟體開發(fā)週期、降低專案成本有重要的現(xiàn)實意義。同時，建造符合某應用領域體系結(jié)構(gòu)標準的構(gòu)件，可以用來搭建分佈式的、跨越不同操作平臺的軟體，擴展了軟體的應用前景，促進了軟體標準化、商品化的發(fā)展。因此，在此基礎上專家們又提出了“基於構(gòu)件的軟體工程”(CBSE)。構(gòu)件組裝模型如下圖所示：

2024-1-2434

構(gòu)件組裝模型2024-1-2435

軟體體系結(jié)構(gòu)被建立後，必須用構(gòu)件去充實，這些構(gòu)件可從複用庫中獲得，或者根據(jù)專門需要而開發(fā)。整個過程可以演化地進行，面向?qū)ο蠓椒ńo予技術(shù)上的支持。構(gòu)件技術(shù)目前主要有三種流行標準：

?OMG的CORBA：

對象管理組織發(fā)佈的公共對象請求代理體系結(jié)構(gòu)(CommonObjectRequestBrokerArchitecture)。一個對象請求代理（ORB)提供一系列服務，使得一個構(gòu)件和其他構(gòu)件通信，而不管它們在系統(tǒng)中的位置，實現(xiàn)了遠程對象通過介面進行通信的機制。

2024-1-2436

?

微軟的COM/DCOM：微軟開發(fā)了構(gòu)件對象模型（ComponentObjectModel)，它提供了運行於windows之上的單個應用系統(tǒng)使用不同廠商生產(chǎn)的構(gòu)件的規(guī)約。基於分佈式環(huán)境下的COM稱為DCOM(DistributeCOM)。

?SUN的EJB(EnterpriseJavaBean)：隨著Java在企業(yè)級應用的地位日趨重要，Sun提出了一個統(tǒng)一的企業(yè)級Java平臺—J2EE。在J2EE中，EJB負責最核心的業(yè)務處理。它為伺服器端的應用程式提供了一種與廠商無關的Java介面，讓任何符合EJB規(guī)範的構(gòu)件都可以運行在每一臺這樣的伺服器上。2024-1-2437

⑺統(tǒng)一軟體開發(fā)過程

是由Rational公司的Booch、Jacobson、Rumbaugh提出的軟體過程模型，也稱RUP(RationalUnifiedProcess)。RUP重複一系列週期，每個週期由一個交付給用戶的產(chǎn)品結(jié)束。每個週期劃分為初始、細化、構(gòu)造和移交四個階段，每個階段圍繞著五個核心工作流（需求、分析、設計、實現(xiàn)、測試）分別迭代。模型見下圖：

2024-1-24382024-1-2439

初始階段：進行問題定義，確定目標，評估其可行性，降低關鍵風險。

細化階段：制定專案計畫、配置各類資源、建立系統(tǒng)架構(gòu)（包括各類視圖）。

構(gòu)造階段：開發(fā)整個產(chǎn)品，並確保產(chǎn)品可移交給用戶。

移交階段：產(chǎn)品發(fā)佈、安裝、用戶培訓。在每個階段的每次迭代的最後，用例模型、分析模型、設計模型、實現(xiàn)模型都會增量，每個階段結(jié)束的里程碑處，管理層做出是否繼續(xù)、進度、預算、是否給下一階段提供資助等決定。不同階段工作流的側(cè)重點不同，前兩階段大部分工作集中在需求、分析和架構(gòu)設計上；在構(gòu)造階段，重點轉(zhuǎn)移到詳細設計、實現(xiàn)和測試上。

2024-1-24401.4軟體開發(fā)方法

1.

結(jié)構(gòu)化方法（SA、SD、IDEF)2.面向數(shù)據(jù)結(jié)構(gòu)的方法（Jackson、Warnier-On)3.形式化開發(fā)方法（VDM)4.面向?qū)ο蟮拈_發(fā)方法

Coad-Yourdon、Booch、Rumbaugh、Jacobson5.

敏捷（agile)開發(fā)方法極限編程

(ExtremeProgramming，XP)是其中的一種主要方法。支持需求變化、遞增式開發(fā)。每一遞增週期的代碼必須充分測試（單元測試），用戶和開發(fā)組在一起，隨時保證做出的功能滿足用戶的需求，專案組成員在同一地點工作，保證高效的面對面交流，要經(jīng)常性的（如每個週期結(jié)束）進行回顧，隨時調(diào)整方法與過程以達到最有效的開發(fā)。2024-1-24411.5軟體開發(fā)工具

軟體開發(fā)工具對軟體過程和方法提供了自動的或半自動的支持。

1.工具箱：各種工具的組合，介面不統(tǒng)一。

2.軟體開發(fā)環(huán)境：各階段使用的軟體工具集合成一個完整的整體，支持軟體開發(fā)的全過程。如Delphi。

3.

電腦輔助軟體工程（ComputerAidedSoftwareEngineering,CASE)：方法與工具的結(jié)合，支持某種方法論，支持某種過程模型，幫助軟體開發(fā)人員進一步提高軟體開發(fā)的效率和品質(zhì)。CASE可以簡單到輔助某特定的軟體工程活動（如分析建模），也可以複雜到一個完整的環(huán)境，它包含工具、資料庫、人員、硬體、網(wǎng)路、操作系統(tǒng)、標準及其它部件。2024-1-2442

CASE的構(gòu)造積木塊如圖所示：

2024-1-2443

⑴

環(huán)境體系結(jié)構(gòu)：由硬體平臺和系統(tǒng)支持（包括網(wǎng)路軟體、資料庫管理和對象管理服務）構(gòu)成，是CASE的基石。

⑵可移植服務：提供了工具及其集成框架與環(huán)境體系結(jié)構(gòu)的橋樑，即允許工具及其集成框架能跨越不同硬體平臺和操作系統(tǒng)使用，而不需要做大量的適應性修改。

⑶集成框架：是一組專用程式，它們使得個體的CASE工具可以和其他工具相互通信，能夠建立專案數(shù)據(jù)庫，以及向開發(fā)人員展示相同的介面。

2024-1-2444

集成框架有如下結(jié)構(gòu)：

?

用戶介面層：包含標準的介面工具箱和公共的表示協(xié)議（給予CASE工具相同介面的一組指導原則：螢幕佈局約定、菜單名和組織、圖符、對象名、鍵盤和滑鼠的使用以及工具訪問機制等表示協(xié)議）。

?

工具管理層：協(xié)調(diào)工具的使用。

?

對象管理層：提供配置管理服務。

?

共用資料庫層：完成對象管理層與資料庫的訪問控制。

⑷

工具：專案管理工具、分析與設計工具、編程工具、測試工具、原型建造工具、介面開發(fā)工具、風險分析工具、文檔工具以及再工程工具等。西安交通大學劉海巖45第2章軟體專案管理軟體專案管理的概念軟體度量軟體專案計畫專案進度安排與跟蹤軟體品質(zhì)管理軟體配置管理西安交通大學劉海巖462.1軟體專案管理的概念

?

專案：以一套獨特而相互聯(lián)繫的任務為前提，有效的利用資源，為實現(xiàn)一個特定目標所作的工作。專案的成功受以下幾個因素的制約：技術(shù)範圍、成本、進度、用戶滿意度、人員等。

?

專案管理的職責：確保專案目標的實現(xiàn)，即在預算內(nèi)按時完成品質(zhì)合格的產(chǎn)品。

?

軟體專案管理：是對傳統(tǒng)專案管理進行軟體工程化的一種擴展與拓延，是它在軟體工程的任何技術(shù)活動之前開始，並持續(xù)貫穿於整個軟體定義、開發(fā)和支持階段的庇護性活動，是決定一個產(chǎn)品或?qū)０改芊癯晒ψ钪匾闹笜酥弧?/p>

西安交通大學劉海巖474個P（People、Product、Process、Project）對軟體專案管理有實質(zhì)性的影響：

人員必須被組織成有效的開發(fā)團隊。

產(chǎn)品需求被劃分成較小的組成部分，便於分配給軟體開發(fā)小組。開發(fā)過程應根據(jù)人員和產(chǎn)品選擇合適的開發(fā)模型。

專案必須被組織成便於控制和管理的方式，使有計畫的進行。西安交通大學劉海巖48◆

人員：人員是一個成功軟體專案中最重要的因素?？煞譃?類：⑴高級管理者：負責定義業(yè)務問題，影響著專案。⑵技術(shù)管理者：組織、激勵和控制開發(fā)人員。⑶開發(fā)人員：負責開發(fā)一個產(chǎn)品或應用所需的技術(shù)。⑷客戶（customer)：負責說明待開發(fā)的軟體需求。⑸最終用戶（user)：直接使用發(fā)佈的軟體。西安交通大學劉海巖49

每一個軟體專案都有上述的人員參與。必須被組織成有效的小組，最大限度的發(fā)輝每個人的技術(shù)和能力，激勵他們進行高質(zhì)量的工作，並協(xié)調(diào)他們實現(xiàn)有效的通信。Constantine提出4個“組織範型”：(1)封閉式範型：傳統(tǒng)的控制層次，垂直通信，難以創(chuàng)新。(2)隨機式範型：小組管理較鬆散，依賴於成員個人的主動性。不適合“有次序地完成”。(3)開放式範型：具有封閉式範型的控制性，又包含隨機式範型的創(chuàng)新性。適合於解決複雜問題?？赡懿幌衿渌愋托〗M那麼有效率。(4)同步式範型：依賴於問題的自然劃分，小組成員各自解決問題的獨立部分。主動通信差。建立一個有凝聚力的小組，要有團隊精神。西安交通大學劉海巖50

◆

產(chǎn)品：進行專案計畫之前，應該首先定義產(chǎn)品的目的和範圍，考慮可選的解決方案，標識技術(shù)和管理的約束。無這些資訊，就不可能進行合理的、準確的成本估算、有效的風險評估、適當?shù)膶０溉蝿談澐?、可管理的專案進度安排。

“目的”指從用戶的角度標識出該產(chǎn)品的總體目標而不考慮這些目標如何實現(xiàn)。

“範圍”指標識出與產(chǎn)品相關的主要數(shù)據(jù)、功能和行為。確定了目的和範圍，就可以根據(jù)產(chǎn)品交付的期限、預算的限制、可用的人員、技術(shù)介面及各種其他因素，選擇最好的解決方案途徑。

西安交通大學劉海巖51◆過程

根據(jù)以下條件選擇一個合適的軟體過程模型：⑴開發(fā)人員及需要該產(chǎn)品的用戶⑵產(chǎn)品本身的特徵⑶專案組的工作環(huán)境採用如下的框架活動集合：客戶交流、計畫、風險分析、工程實施、構(gòu)造及發(fā)佈、用戶評估。這些活動可被修改以適應不同軟體專案的特徵和專案組的需求。每個活動可被分解為更詳細的工作任務。如客戶交流活動可能需要下列任務：西安交通大學劉海巖52

⑴列出需要澄清問題的清單⑵安排與用戶進行討論的會議⑶評審用戶要求及範圍的陳述⑷研究推薦的解決方案⑸為正式的會議準備工作文檔⑹共同制訂能反映軟體的數(shù)據(jù)、功能和行為特征的規(guī)約，形成軟體範圍的文檔⑺評審文檔⑻根據(jù)需求修改文檔

……庇護性活動貫穿於整個過程。西安交通大學劉海巖53

◆專案有計畫的控制軟體專案，Boehm提出了一種方法，強調(diào)專案目標、里程碑、進度、責任、管理和技術(shù)方法以及需要的資源,稱之為W5H2原則。通過下麵一系列的提問和回答,可以導出專案的關鍵特徵並產(chǎn)生專案計畫的大綱：⑴為什麼（Why)該系統(tǒng)被開發(fā)？值得嗎？⑵將做什麼（What)？什麼時候(When)做？建立專案進度，標識關鍵的專案任務和里程碑。⑶某功能由誰（Who)負責？開發(fā)人員的角色和責任。⑷哪里需要（Where)?客戶、用戶和其他投資者也有責任。⑸工作將如何（How)進行？定義專案的管理和技術(shù)策略。⑹資源需要多少(Howmuch)？

西安交通大學劉海巖54

軟體專案管理中的主要元素及之間的關係

開發(fā)人員、小組、角色、任務、工作產(chǎn)品、進度表（UML類圖）之間的關係西安交通大學劉海巖55

軟體專案管理的主要內(nèi)容：

?定義問題(確定新系統(tǒng)的作用域-目標）

?確認專案的可行性

?建立專案的進度計畫

?建立專案的品質(zhì)保證體系

?建立專案配置管理體系和準則

?專案版本變更管理?

跟蹤、監(jiān)控專案的進展

?風險管理

?團隊建設（人員管理，包括績效評估等）

西安交通大學劉海巖562.2可行性研究

1、可行性研究的任務和目的GB8566-88《電腦軟體開發(fā)規(guī)範》中指出：

可行性研究的主要任務是瞭解客戶的要求及現(xiàn)實環(huán)境，從技術(shù)、經(jīng)濟和社會因素等方面研究並論證本軟體專案的可行性，編寫可行性研究報告供專案管理人員評審，以便作出是否開發(fā)軟體專案的決策。西安交通大學劉海巖57◆技術(shù)可行性

度量一個系統(tǒng)解決方案的實用性及技術(shù)資源的可用性?？紤]的問題：(1)開發(fā)風險分析(2)資源分析(3)相關技術(shù)的發(fā)展（現(xiàn)有技術(shù)能否實現(xiàn)新系統(tǒng)、技術(shù)難點、建議採用技術(shù)的先進性）西安交通大學劉海巖58◆經(jīng)濟可行性

主要內(nèi)容：成本/效益分析不可能得到精確的分析結(jié)果?系統(tǒng)成本：①軟體開發(fā)費用②購置並安裝軟硬體機有關設備的費用估算③系統(tǒng)安裝、運行和維護費用④人員培訓費用?系統(tǒng)效益包括經(jīng)濟效益和社會效益經(jīng)濟效益:可通過直接的或統(tǒng)計的方法估算社會效益：定性的方法估算西安交通大學劉海巖59◆社會因素可行性

政策、法律、使用、環(huán)境等2、可行性研究的步驟(1)復查確認系統(tǒng)目標、規(guī)模(2)研究現(xiàn)行系統(tǒng)的工作流程(3)導出目標系統(tǒng)高層邏輯模型(4)導出和評價供選擇的方案(5)推薦可行的方案(6)編寫可行性研究報告，送審西安交通大學劉海巖603、可行性研究報告的編寫提示（1）引言：編寫目的、背景、定義、參考資料；（2）可行性研究的前提：要求、目標、條件、假定和限制、進行可行性研究的方法、評價尺度；（3）對現(xiàn)有系統(tǒng)的分析：工作流程、工作負荷、費用開支、人員、設備、局限性；（4）所建議的系統(tǒng)：說明、數(shù)據(jù)流程和處理流程、改進之處、影響、局限性、技術(shù)條件的可行性；（5）可選擇的其他系統(tǒng)方案；（6）投資及收益分析：支出、收益、收益/投資比、投資回收期等；（7）社會條件方面的可行性（法律、使用）。

西安交通大學劉海巖61例：一個軟體系統(tǒng)的開發(fā)費用（一次）：人員：2名系統(tǒng)分析員(450小時/名,45美元/小時)$40,500

5名系統(tǒng)開發(fā)人員(275小時/名,36美元/小時）$49,5001名數(shù)據(jù)通訊專家(60小時/名,42美元/小時)$2,520

1名數(shù)據(jù)庫管理員(30小時/名,42美元/小時)$1,2602名技術(shù)寫作者(120小時/名,25美元/小時)$6,0001名秘書(160小時/名,15美元/小時)$2,4002名在轉(zhuǎn)換期間數(shù)據(jù)輸入人員$960（40小時/名,12美元/小時)

西安交通大學劉海巖62培訓：三天的開發(fā)人員內(nèi)部培訓課程$7,00030個用戶，三天的內(nèi)部培訓課程$10,000複印$500磁片、紙張等消耗品$650購買硬體、軟體：20臺工作站W(wǎng)indows軟體$1,00020臺工作站記憶體升級$8,000網(wǎng)路軟體$17,50020臺工作站辦公軟體產(chǎn)品$20,000系統(tǒng)開發(fā)總費用$167,790（成本）西安交通大學劉海巖63

一個系統(tǒng)的年運行費用（每年）：人員：維護程式員/分析員(250小時/年,42美元/小時)$10,500網(wǎng)路管理員(300小時/年,50美元/小時)$15,000購買硬體、軟體升級：硬體$5,000軟體$6,000物資和雜項$3,500每年總運行費用$40,000西安交通大學劉海巖642.3軟體度量

軟體度量（metrics)域分為過程度量、專案度量和產(chǎn)品度量。對過程、專案及產(chǎn)品的特定屬性進行度量產(chǎn)生指導管理及技術(shù)動作的指標，使得管理者和開發(fā)者能夠：

?

改善軟體過程

?

輔助軟體專案計畫

?

跟蹤及控制軟體專案的進展

?

評價軟體產(chǎn)品的品質(zhì)西安交通大學劉海巖65

軟體度量的方式：直接度量間接度量

?軟體工程過程的直接度量包括所投入的成本和工作量。

?軟體產(chǎn)品的直接度量包括產(chǎn)生的代碼行數(shù)（LOC）、執(zhí)行速度、存儲量大小、在某種時間週期中所報告的錯誤數(shù)。

?軟體產(chǎn)品的間接度量包括功能性、複雜性、效率、可靠性、可維護性和許多其他的品質(zhì)特性。西安交通大學劉海巖661.過程和專案的度量

◆過程度量：

使一個組織從戰(zhàn)略上考察已有過程的功效，如開發(fā)範型、工程任務的劃分、工作產(chǎn)品、里程碑等，使管理者評估那些部分起了作用。度量數(shù)據(jù)的收集跨越所有的專案，經(jīng)歷較長的時間，目的是改善軟體過程。間接的度量一個軟體過程的功效：

?軟體發(fā)佈之前發(fā)現(xiàn)的錯誤數(shù)

?交付給用戶後報告的缺陷數(shù)

?花費的工作量、時間、成本

?與進度計畫是否一致

西安交通大學劉海巖67

個體軟體過程（如PSP）提供了表格、腳本、標準以幫助開發(fā)人員估算、計畫以及度量、跟蹤自己工作的方法。過程度量對於一個組織（如企業(yè)）提高其總體的過程成熟度能提供很大的幫助。如一個產(chǎn)品中，需求規(guī)約缺陷占了25.5%，原因如圖所示。通過分析一個完整的魚骨圖可以導出能改進軟體過程以降低錯誤和缺陷率的頻率。

西安交通大學劉海巖68

◆專案度量：

是戰(zhàn)術(shù)的，使專案管理者能夠以即時的方式改進專案的工作流程及技術(shù)方法，如軟體專案的工作量及時間的估算。

專案度量的基礎是歷史專案中收集的數(shù)據(jù)。隨著專案的進展，所花費的工作量及時間和預算的值進行比較，從而控制專案的進展。另外，可根據(jù)文檔的頁數(shù)、評審的時間、功能點及源代碼行數(shù)來度量軟體的生產(chǎn)率。

西安交通大學劉海巖69

專案度量可在專案進行的基礎上評估產(chǎn)品的品質(zhì)，以指導在必要時修改技術(shù)方法以改進品質(zhì)。軟體專案度量建議每個專案都應該測量：

?輸入：完成工作所需要的資源（如人員、環(huán)境）；

?輸出：軟體工程過程中產(chǎn)生的工作產(chǎn)品；

?結(jié)果：最終產(chǎn)品的有效性。專案度量集成起來產(chǎn)生對整個軟體組織公用的過程度量。

西安交通大學劉海巖702.軟體度量的方法

（1）面向規(guī)模的度量

是對軟體和軟體開發(fā)過程的直接度量?？梢越⒁粋€面向規(guī)模的數(shù)據(jù)表格來記錄專案的某些資訊。該表格列出了在過去幾年完成的每一個軟體開發(fā)專案和關於這些專案的相應面向規(guī)模的數(shù)據(jù)。

西安交通大學劉海巖71

基於所生產(chǎn)軟體的“規(guī)?！?，使用代碼行作為其他計算的規(guī)範化因數(shù)。計算：

?每千行代碼（KLOC)的錯誤數(shù)。

?每KLOC

的缺陷數(shù)。

?每個LOC的花費成本。

?每KLOC的文檔頁數(shù)

?每人月的錯誤數(shù)。

?每人月的代碼行。

?每頁文檔的成本。

西安交通大學劉海巖72

可製作一個如下的表：

對該方法的有效性有爭議：

支持：易計算，很多軟體估算模型以它為關鍵的輸入。

反對：LOC依賴於語言，不適用於非過程化語言，在分析與設計完成之前難以估算。專案名KLOC工作量（人月）成本（萬元）文檔頁數(shù)錯誤缺陷人員BETA1236101556085西安交通大學劉海巖73

（2）面向功能的度量

“功能”不能直接測量，利用其他的測量數(shù)據(jù)間接地導出。Albrecht提出來的一種稱為功能點的度量。用下表計算5個資訊域的值：

西安交通大學劉海巖74其中：

?用戶輸入數(shù)：每個用戶向系統(tǒng)提供的不同應用的輸入數(shù)據(jù)。

?用戶輸出數(shù)：系統(tǒng)向每個用戶提供的資訊，如報表、螢幕資訊、出錯資訊等。

?用戶查詢數(shù)：每個不同的詢問/回應的交互操作。

?檔數(shù)：可以是資料庫的一部分或是一個獨立的檔。

?外部介面數(shù)：與系統(tǒng)中其他設備通過外部介面讀寫信息的次數(shù)。

“簡單、平均、複雜”中的常量值是加權(quán)因數(shù)，根據(jù)經(jīng)驗確定。

西安交通大學劉海巖75

利用以下公式計算功能點（FP）：FP=總計數(shù)值×（0.65+0.01×

Fi）

其中Fi（i=1~14）是回答14個方面問題而得到的複雜度調(diào)整值（值域為0~5），如輸入、輸出、查詢及內(nèi)部處理複雜嗎？代碼複用嗎？有分佈處理嗎等等（詳見p64）。計算出功能點。就可進行以下度量：

?每個功能點的錯誤數(shù)。

?每個功能點的缺陷數(shù)。

?每個功能點的成本。

?每個功能點的文檔頁數(shù)。

?每人月完成的功能點數(shù)。西安交通大學劉海巖76代碼行和功能點度量之間的關係依賴於實現(xiàn)軟體所採用的程式設計語言及設計的品質(zhì)。下麵給出了在不同的程式設計語言中建造一個功能點所需的平均代碼行數(shù)的統(tǒng)計：程式設計語言LOC/FP

組合語言320

C128FORTRAN106Pascal90C++64Java46VisualBASIC32PowerBuilder16SQL12

西安交通大學劉海巖77

3、軟體品質(zhì)度量

軟體工程的目標是產(chǎn)生高質(zhì)量的系統(tǒng)或產(chǎn)品。品質(zhì)依賴於描述問題的需求、建模、設計、編碼、測試。品質(zhì)度量貫穿於軟體工程的全過程中以及軟體交付用戶使用之後。應評估分析與設計模型、源代碼、測試案例的品質(zhì)。

西安交通大學劉海巖78

在軟體交付之前得到的度量數(shù)據(jù)可作為判斷設計和測試品質(zhì)好壞的依據(jù)。這一類度量包括程式複雜性、有效的模組性和總的程式規(guī)模。

在軟體交付之後的度量數(shù)據(jù)則把注意力集中於還未發(fā)現(xiàn)的缺陷數(shù)和系統(tǒng)的可維護性方面。

McCall提出了影響軟體品質(zhì)的11個因素(詳見P367)，其中重要的有以下幾點：

?正確性：軟體完成所需功能的程度，最常用

“缺陷數(shù)/kLoc”來測量。西安交通大學劉海巖79

?可維護性：遇到錯誤時程式能被修改的容易程度、環(huán)境變化時程式能被適應的容易程度、用戶希望改變需求時程式能被增強的容易程度，一種最簡單的測量方法是計算平均修改時間（MTTC）。

?完整性：測量系統(tǒng)在安全方面的抗攻擊性。

完整性＝Σ[(1-威脅)×(1-安全性)]

其中威脅是某個特定類型的攻擊在給定時間內(nèi)發(fā)生的可能性。安全性是某個特定類型的攻擊將被擊退的可能性。

?可用性：用戶友好性。另外還有可靠性、效率、可測試性、可移植性、可複用性等等。

西安交通大學劉海巖802.4軟體專案計畫

專案計畫既指出了專案組織未來努力的方向和奮鬥目標，又是當前行動的準則。針對不同工作目標，軟體專案計畫有：

?專案實施計畫（軟體開發(fā)計畫）這是軟體開發(fā)的綜合性計畫，通常應包括任務、進度、人力、環(huán)境、資源、組織等多個方面。

?品質(zhì)保證計畫把軟體開發(fā)的品質(zhì)要求具體規(guī)定為每個開發(fā)階段可以檢查的品質(zhì)保證活動。

?軟體測試計畫規(guī)定測試活動的任務、測試方法、進度、資源、人員職責等。

西安交通大學劉海巖81

?文檔編制計畫規(guī)定所開發(fā)專案應編制的文檔種類、內(nèi)容、進度、人員職責等。

?用戶培訓計畫規(guī)定對用戶進行培訓的目標、要求、進度、人員職責等。

?綜合支持計畫規(guī)定軟體開發(fā)過程中所需要的支持，以及如何獲取和利用這些支持。

?軟體發(fā)佈計畫軟體開發(fā)專案完成後，如何提交給用戶。這裏，主要針對綜合計畫來介紹。西安交通大學劉海巖82專案管理是一個創(chuàng)造的過程，專案早期的不確定性因素，使計畫不可能在啟動階段就全部一次完成，需逐步展開和不斷修正，這又取決於計畫執(zhí)行情況的回饋與及時的資訊交流。制訂專案基準計畫(BaselinePlan)的步驟：①定義專案目標，確定軟體範圍②把專案按專案範圍分解為多個任務③確定對應每個任務必須執(zhí)行的活動④將每個任務分配給一個小組，並為每個開發(fā)者分配角色和職責⑤用Gantt圖或PERT圖表示出項目的進度

西安交通大學劉海巖831、軟體專案估算專案計畫的一個重要的前提是專案估算（有時在可行性研究階段完成），一般以團隊的歷史經(jīng)驗為基礎，讓團隊中的一線人員參與估算，才能保證專案計畫的可行性。成本及工作量的估算不是一門精確的科學，有幾種選擇：

?

基於已完成的類似專案進行估算；

?使用分解技術(shù)以生成專案成本及工作量的估算；

?使用一個或多個經(jīng)驗模型；

（1）分解技術(shù)分解技術(shù)採用“分而治之”的策略進行軟體專案估算。將專案分解成若干主要功能及相關的軟體過程活動，通過逐步求精的方式進行成本及工作量估算。具體方法為：

西安交通大學劉海巖84

劃分主要的軟體功能，接著估算：①Loc的數(shù)量②對於FP，估算每個資訊域特徵（輸入、輸出、數(shù)據(jù)檔、查詢、外部介面）及14個複雜度調(diào)整值③實現(xiàn)每個功能所需的人月數(shù)④每個軟體過程活動所需人月數(shù)基本的估算方法：

?自頂向下估算：總成本按階段、步驟、工作單元?自底向上估算：先劃分，分別估算每個子任務所需的工作量，然後∑。

西安交通大學劉海巖85?差別估算法：與類似專案比較，估算每個不同之處對成本的影響。還有專家估算法等等。（2）經(jīng)驗估算模型經(jīng)驗估算模型可用於補充分解技術(shù)，並提供一種潛在有價值的估算方法。該模型是基於經(jīng)驗（歷史數(shù)據(jù)）的，可以用下麵的形式表示：

=?（

）其中

是要估算的值（如工作量、成本、專案持續(xù)時間）之一，

是選擇出來的獨立參數(shù)（如被估算的Loc或FP）。西安交通大學劉海巖86

由經(jīng)驗導出的公式，最著名的是COCOMO模型，構(gòu)造型成本模型（COnstructiveCOstMOdel）。初期的模型廣泛的使用於軟體成本估算，發(fā)展到反映不同階段的成本。

初始模型的分類：?基本COCOMO模型是靜態(tài)單變數(shù)模型，用源代碼行數(shù)(LOC)為引數(shù)的經(jīng)驗函數(shù)計算軟體開發(fā)工作量。?中間COCOMO模型該模型在用LOC為引數(shù)的函數(shù)計算軟體開發(fā)工作量的基礎上，用涉及產(chǎn)品、硬體、人員、專案等方面的影響因素調(diào)整工作量估算。?詳細COCOMO模型該模型包括中間COCOMO模型的所有特性，但用上述各種影響因素調(diào)整工作量估算時，還要考慮對軟體工程過程中每一步驟（分析、設計等）的影響。

西安交通大學劉海巖87

模型的擴展：COCOCOMⅡ使用對象點、功能點、源代碼行作為不同層次模型的參數(shù)。

對象點只是一種間接軟體測量數(shù)，使用以下計數(shù)：①用戶介面上的螢幕數(shù)②報表數(shù)③建立應用軟體需要的構(gòu)件數(shù)。每個對象實例（如一個螢幕或一個報表）給出三個複雜度權(quán)數(shù)（簡單、中等、複雜），如一個螢幕的權(quán)簡單為1，中等為2，複雜為3。通過以下公式計算總對象點數(shù)：西安交通大學劉海巖88Σ（初始的對象實例數(shù)×加權(quán)因數(shù)）＝總的對象點（NOP）當應用基於構(gòu)件的開發(fā)時，對象點計數(shù)調(diào)整為：NOP＝NOP×[(100-%複用)/100]進而計算：生產(chǎn)率＝NOP/人月針對不同級別的開發(fā)者經(jīng)驗和開發(fā)環(huán)境成熟度，給出對象點的生產(chǎn)率：非常低低額定高非常高47132550專案工作量＝NOP/生產(chǎn)率西安交通大學劉海巖89

2、專案進度安排專案計畫中的一個重要內(nèi)容是建立進度表，該表對專案進度進行科學度量、調(diào)整專案計畫起很重要的作用。在眾多軟體專案中，缺乏合理的進度安排是造成專案泄後的最主要原因。進度安排為專案管理者和開發(fā)者建立了一張行路圖。

（1）進度安排的指導原則：

?劃分：專案分解成若干易於管理的任務。如何進行任務的分解呢？可從兩個方面獲得幫助：①軟體開發(fā)模型：模型幫助將整個專案進行階段性的劃分，這些階段可以做計畫中很重要的里程碑。

②

軟體開發(fā)需求：開發(fā)模型只給專案計畫提供了個框架，需求的整理與規(guī)格化，是細化專案計畫的基礎。

西安交通大學劉海巖90

?

相互依賴性：各個被劃分的活動或任務之間的相互關係必須是確定的。有些任務必須順序進行，有些可以併發(fā)進行。

?

時間分配：必須為每個被調(diào)度的任務分配一定數(shù)量的工作單位（如，人天、人月），並指定開始和結(jié)束日期。

?

工作量確認：每個專案都有預定數(shù)量的人員參與。在進行時間分配時，必須確保在任意時段中分配給任務的人員數(shù)量不會超過專案組中的人員總量。

?

定義的責任：每個被調(diào)度的任務都應該指定某個特定的小組成員來負責。

?

定義的結(jié)果：每個被調(diào)度的任務都應該有一個定義好的輸出結(jié)果，輸出結(jié)果通常是一個工作產(chǎn)品或某個工作產(chǎn)品的一部分。

?

定義的里程碑：每個任務或任務組都應該與一個專案里程碑相關聯(lián)。當一個或多個工作產(chǎn)品經(jīng)過品質(zhì)評審並且得到認可時，標誌著一個里程碑的完成。

西安交通大學劉海巖91（2）工作量分配(指導原則）計畫需求分析設計編碼測試

2％~3%10%~25%20%~25%15%~20%30%~40%(3)進度表（圖）

?

甘特圖（GanttChart)

也稱時間表，所有的專案任務都在左邊的欄目中列出。水準條表示每個任務的持續(xù)時間，當同一時間段中存在多個水準條時，表示任務之間存在併發(fā)。

?

PERT(ProgramEvaluationReviewTechnique)圖也稱任務網(wǎng)路圖，表示一個專案的任務流程，刻畫了各項任務、任務之間的依賴關係及任務的持續(xù)時間。它的最簡單形式可當作宏觀進度表使用。西安交通大學劉海巖92

Gantt圖Gantt圖可清晰的表達每個任務活動的進展以及併發(fā)活動。水準條的顏色既可以表示概要任務和詳細任務的分解，也可以表示任務完成的情況。用一個特定的符號（如黑菱形）表示一個活動的結(jié)束（里程碑），以便檢查階段成果和最後成果。

西安交通大學劉海巖93

PERT圖PERT圖另一個重要的用途是用來判斷關鍵路徑，關鍵路徑表明了完成該專案可能需要的最小時間，並能識別最有可能成為瓶頸的活動,該路徑上的活動是專案負責人或小組長抓的主要工作。非關鍵路徑上的活動延遲，不會導致專案總體進度偏離。下圖是一個專案的總的PERT圖。

西安交通大學劉海巖94西安交通大學劉海巖95說明：①考慮進度表中的變化：建立進度表時，專案分解為哪些任務以及任務持續(xù)的時間往往根據(jù)歷史數(shù)據(jù)估算而來，專案進展過程中未預料到的事件，如需求的變化或較晚發(fā)現(xiàn)的設計缺陷，都會打亂進度表，因此在進度表中為將來可能的變化留有餘地。②進度表可有不同的抽象層次：高層進度表反映整個專案的進度，應包括所有可交付產(chǎn)品的期限，底層進度表是任務和時間的分解?？裳u作短期內(nèi)的進度表，其餘部分在專案進行過程中完成。底層進度表可用於指導每個小組的進度。③每個里程碑可以附帶一個標識進度值的百分比，用來說明專案完成了多少，如：30％。

西安交通大學劉海巖96

專案開展階段管理活動圖（UML活動圖）

2.5專案進度的跟蹤

西安交通大學劉海巖97

1、專案啟動

進行專案計畫

2、專案開展

專案的監(jiān)督與跟蹤

（1）收集狀況資訊的方式

?

定期報告：非正式的會議和交流，報告工作產(chǎn)品、進度誤差等需要及早溝通的資訊。

?

里程碑的監(jiān)督與驗證：里程碑可以是事件，也可以是工作產(chǎn)品，驗證是否在預定時間內(nèi)完成。

?

專案檢查：正式會議，所有開發(fā)人員交換活動進展狀況，比較各項任務實際開始日期與計畫開始日期。

?

代碼檢查：同事之間的正式代碼檢查。

?

原型示範：原型是為了驗證需求或為了評估技術(shù)和功能而部分實現(xiàn)的系統(tǒng)，可用來估算初始進度。

西安交通大學劉海巖98

?

度量：主要是修正錯誤數(shù)目的度量,即還需要付出多少努力的估量。

（2）專案再計畫根據(jù)專案的變化動態(tài)更新專案計畫，應對一些新的需求、新的變化、突發(fā)因素做出回應，或解決問題以適應計畫，或調(diào)整計畫以保證最後按時交付產(chǎn)品。

（3）風險管理風險是一些不利因素實際發(fā)生的可能性。如：人員跳槽，管理層變更，硬體缺乏，需求變化，描述延遲，低估了系統(tǒng)的規(guī)模，工具性能差，技術(shù)變更，產(chǎn)品竟爭等等。

西安交通大學劉海巖99風險管理的活動有：

?風險識別：確定風險的類型（管理、技術(shù)）。

?風險分析：評估風險出現(xiàn)的可能性及其後果。

?風險規(guī)劃：制定避免或降低風險的策略。

?風險控制：定期進行風險評估，及時修正緩解風險的計畫。3、專案總結(jié)

?用戶驗收：根據(jù)專案協(xié)議中規(guī)定的驗收標準對系統(tǒng)進行評價，並通過場景演示，測試系統(tǒng)功能性和非功能性需求。

?安裝：在目標環(huán)境下安裝、運行系統(tǒng)並提交文檔。

?總結(jié)：總結(jié)經(jīng)驗教訓，建立團隊工作效率的歷史檔案，以便提高個人和團隊整體的軟體工程能力。西安交通大學劉海巖1002.6軟體品質(zhì)保證

1、概述軟體品質(zhì)是軟體產(chǎn)品、體系或過程的一組固有特性滿足（顧客和其他相關方）要求的程度。軟體品質(zhì)保證(SoftwareQualityAssurance,SQA)是一種應用於整個軟體過程的庇護性活動，包含：

?品質(zhì)管理方法

?有效的軟體工程方法和工具

?過程中採用的正式技術(shù)評審

?多層次的測試策略

?對軟體文檔及其修改的控制

?保證與開發(fā)標準符合的規(guī)程

?軟體度量及報告機制等等方面的內(nèi)容西安交通大學劉海巖101

軟體品質(zhì)保證的對象一般有三方面：產(chǎn)品、過程和品質(zhì)體系實施軟體品質(zhì)保證需運用幾種支持過程作為品質(zhì)保證的手段。

?驗證或確認：通過提供客觀證據(jù)對規(guī)定要求已得到滿足的認定。

?評審或?qū)徍耍捍_定主題事項達到規(guī)定目標的適應性、充分性和有效性所進行的活動。聯(lián)合評審是由任何兩方（評價方和被評價方）用來在適當時機對專案的某個活動的狀態(tài)和產(chǎn)品進行評價並可能形成檔的過程。

西安交通大學劉海巖102

2、軟體品質(zhì)保證過程中的數(shù)據(jù)

SQA過程中必然產(chǎn)生有關產(chǎn)品、過程和體系品質(zhì)的多種數(shù)據(jù)，是進行下一步工作的決策依據(jù)，對於提高品質(zhì)管理效果和改進品質(zhì)管理過程至關重要。要收集、存儲、及時分析和使用這些數(shù)據(jù)，才能做好品質(zhì)保證工作。質(zhì)量數(shù)據(jù)有多種：

?專案規(guī)模：FP表示軟體大小，以功能點計數(shù);

?工作量E：表示專案的人力總投入，以人月計數(shù);

?生產(chǎn)率：

P=FP/E；

?缺陷數(shù)：D1表示軟體交付前發(fā)現(xiàn)的錯誤數(shù)，D2表示交付後發(fā)現(xiàn)的缺陷數(shù)；

?品質(zhì)：Q=D2/FP，表示每個功能點包含多少交付的缺陷，

?缺陷引入率：DI=(D1+D2)/FP，整個專案生存期中每個功能點發(fā)現(xiàn)的缺陷數(shù);?缺陷排除率：

DR=D1/DI西安交通大學劉海巖103

3、SQA的實施