軟件工程案例分析

單擊此處編輯母版標題樣式,,單擊此處編輯母版文本樣式,,第二級,,第三級,,第四級,,第五級,,軟件工程案例分析,陳天洲,,浙江大學計算機學院,,軟件特征（1）,最根本的：軟件是一種邏輯元素而不是物理元素,,軟件是開發(fā)出的，而不是用傳統(tǒng)的方法制造出來的,,軟件不會被用壞,,時間,失敗概率,一般產品的浴盆曲線,,軟件特征（2）,時間,失敗,,概率,軟件失敗概率實際曲線,軟件失敗概率理想曲線,,軟件特征（3）,工業(yè)界已經走向了標準化裝配時代，然而絕大多數軟件還是定制出來的科學計算函數庫（60年代）,,重用數據結構,,重用組件,,,,成本結構發(fā)生了巨大的變化,一次性的制造成本,,介質成本的可忽略性－,邏輯產品,,不可回逆的投入,,維護成本的增加,,服務是質量要素中的重點,,,軟件危機,“軟件危機” 是1958年在NATO會議上作為一個正式的議題被提出來,,軟件項目不成功的例子比比即是：,,1999 年 10 月，耗資 1.25 億美元的 NASA 的火星氣象衛(wèi)星失蹤（公,英制轉換）,,軟件危機,一些數據：,,大約,70％,的軟件開發(fā)項目超出了估算的時間，大型項目平均超出計劃交付時間,20％到50％,，,90％,以上的軟件項目開發(fā)費用超出預算，并且項目越大，超出項目計劃的程度越高,,美國政府審計局：只有不到2％的合同定購軟件在發(fā)布時具有可用性——,98％以上的項目都失敗了,,軟件危機,一種看法,,“,兩難境地（Crunch Mode）,”：處于兩難境地的項目面臨無法達到最初目標的威脅（費用、進度表、功能性等），而項目團隊努力想跨越困境。

我們正處于兩難境地，在半夜之前是不會回家”,,“,死亡行軍（Death March）,”：用來描述其進度表幾乎不可能完成的項目這是一個死亡行軍項目，我希望自己不要參與進去”,,軟件危機,更準確的說法：,慢性痛苦,（chronic affliction) Suggested by Prof. Daniel Tiechrow, University of Michigan,,盡管忍受痛苦，但是軟件依然在我們這個世界起著越來越重要的作用，但是如果能夠醫(yī)治痛苦，那么軟件業(yè)將發(fā)展得更加健康軟件危機的主要特征,軟件開發(fā)周期大大超過規(guī)定日期;,,軟件開發(fā)成本嚴重超標;,,軟件質量難于保證,,,軟件成功的標準,用戶在,用,,用戶可很,容易,做完要做的事,,,失敗的根本原因：,,開發(fā)人員寫出的東西達不到,,用戶要求,(,人的問題,.,技術問題,),,規(guī)模,,復雜性,,生產率,軟件技術面臨的問題,,,Exchange2000,Windows,2000,項目經理,25人,約250人,開發(fā)人員,140人,約1700人,測試人員,350人,約3200人,例:,?,Windows95有1000萬行代碼,,,?,Windows2000有5000萬行代碼，,,3000多個工程師，幾百個小團隊。

Exchange2000和 Windows2000開發(fā)人員結構,,“軟件工程案例分析”課程,與其它軟件專業(yè)課的區(qū)別,(1) 立足于系統(tǒng)的整體2) 系統(tǒng)分析、系統(tǒng)設計、,,測試及維護的方法實踐3) 構筑一個軟件系統(tǒng)，實踐,,軟件開發(fā)全過程用戶,分析員,程序員,系統(tǒng)分析員的地位,,“一個好的工業(yè)，應有一套良好的標準來配套”,軟件工業(yè)化生產過程應具備的特點,,明確的工作步驟,,詳細具體的規(guī)范化文檔,,明確的質量評價標準,,,軟件產品的標準化,軟件開發(fā)過程的標準化,,軟件工程技術的兩個明顯特點,,強調規(guī)范化,,強調文檔化,,新世紀軟件產業(yè)的趨勢,網絡化趨勢：,計算機與通信的融合趨勢,,萬維網,?智能網絡,,服務化趨勢：,“打包式”軟件,?,“服務式”軟件,,全球化趨勢,,中國軟件產業(yè)發(fā)展主要問題,,產業(yè)規(guī)模小、集中度低,,產業(yè)競爭力弱，缺乏核心技術,,市場秩序較為混亂，盜版嚴重,,制約軟件產業(yè)發(fā)展的因素,軟件開發(fā)規(guī)范與標準,,知識產權環(huán)境,,知識結構,,公司體制,,項目與項目管理,項目是什么,,沒有例行的任務,,需要計劃,,特定的目標需要滿足或者特定的產品需要生成,,項目有一個預定義的時間范圍,,工作不僅僅是為自己，也是為他人,,工作中有些特性,,工作分為若干階段,,項目完成需要資源,,項目是大型的或者復雜的,,項目管理是什么,,項目管理是在項目活動中應用知識，技能，工具和技術來,滿足項目需求,的,過程,，它通過初始化，計劃，執(zhí)行，控制和結束等,活動,來完成。

軟件項目與,軟件項目管理,軟件項目的特征,,不可見,,復雜性（以每一單位貨幣來看）,,靈活性：軟件去適應人或組織而不是相反,,一致性,,軟件項目管理,,為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動軟件項目的活動,需求分析,,描述,,設計,,編碼,,校驗,,安裝,,維護,,支持,,軟件項目分類,按軟件類別,,信息系統(tǒng)：與組織接口,,嵌入式系統(tǒng)：接口是機器,,操作系統(tǒng)是一個信息系統(tǒng)還是嵌入式系統(tǒng)？,,有些項目是為了生成某一產品，而某些項目的進行是為了達到某些目標許多軟件項目分為兩個階段，第一階段是,目標驅動,，第二階段再生成真正的,軟件產品,從系統(tǒng)的角度看軟件項目,一個項目關注于生成一個系統(tǒng)和/或將一個舊系統(tǒng)轉換為一個新系統(tǒng),,系統(tǒng)，子系統(tǒng)和環(huán)境,,開放和封閉系統(tǒng),,項目失敗的一個原因是技術人員不能夠開放系統(tǒng)和立即接受外界的變化部分優(yōu)化,,例如：可能很高效，但是難于修改,,社會技術系統(tǒng),,軟件項目屬于此類,,軟件項目中的人員,項目影響者(stakeholders),,項目小組內部：,,項目小組外部，但是在同一組織內：,,項目小組和組織外部：如客戶,,不同的項目影響者有不同的目標，因而項目領導者需要能夠協調這些目標。

Boehm和Ross提出軟件項目管理的,“W理論”,，該理論關注于所有各方都能從項目種獲益因而對項目的成功都有興趣W代表Everyone a Winner）,,軟件開發(fā)面臨的挑戰(zhàn),處理最終日期（deadlines）(85%),,處理資源約束（83％）,,與任務小組有效的溝通（80％）,,從小組成員處得到承諾（74％）,,建立可測量的milestone（90％）,,處理變化（60％）,,得到團隊公認的項目計劃（57％）,,從管理層得到承諾（45％）,,處理沖突（42％）管理銷售商和子項目承包商（38％）,,項目經理面臨的挑戰(zhàn),估計和計劃,,缺少質量標準和度量,,缺少組織決策的指南,,缺少使進度可視化的技術,,角色定義,,不正確的成功準則,,缺少標準,,項目成員面臨的挑戰(zhàn),工作的不正確的描述,,IT的管理失誤,,缺少應用領域的知識,,缺少及時的文檔,,前續(xù)任務沒有及時完成——包括設備沒及時提供,,用戶與技術員之間缺乏交流,,缺少質量控制,,軟件環(huán)境的改變,,Deadline壓力,,軟件項目常見錯誤,選自《快速軟件開發(fā)》,,產品相關的錯誤,,需求鍍金：項目具有比實際需求多得多的性能,,功能蔓延：項目平均會有25%的需求變更（Jones 1994）,,開發(fā)人員的鍍金：開發(fā)人員著迷于新技術,,又推又拉的交易：經理在批準項目進度順延時又加入了新的功能,,研究導向的開發(fā),,軟件項目常見錯誤（續(xù)）,過程中的錯誤,,缺乏計劃,,過于樂觀的計劃,,在壓力下放棄計劃,,缺乏足夠的風險管理,,承包人導致的失敗,,在模糊的項目前期浪費時間,,前期活動不合要求,過程中的錯誤,,設計低劣,,缺少質量保證措施,,缺少管理控制,,太早和過于頻繁的集成,,項目估算時遺漏必要的任務,,追趕計劃,,魯莽編碼,,軟件項目常見錯誤（續(xù)）,技術相關的錯誤,,銀彈綜合癥: 過于相信以前沒有采用過的技術的宣傳,,過高估計了新技術或方法帶來的節(jié)省量,,項目中間切換工具,,缺少自動的源代碼控制手段,,,軟件項目常見錯誤（續(xù)）,人員相關的錯誤,,挫傷積極性,,人員素質低,,對有問題的員工失控,,英雄主義,,項目后期加入人員：“火上加油”,,辦公環(huán)境差,,開發(fā)人員與客戶之間發(fā)生摩擦,,不現實的預期,,軟件項目常見錯誤（續(xù)）,缺乏有效的高層對項目的支持,,缺乏各種角色的齊心協力,,缺乏用戶介入,,政治高于物質,,充滿想像：“項目組沒人真正相信他們能夠按給定的計劃進度完成項目，但他們認為如果每個人能夠努力工作，并且不出現問題，他們可能會很幸運地按時完成任務。

軟件項目常見的錯誤,試分析以下故事中的項目所存在的錯誤：,,,一天，一位年青人被選來“寫”一個用在自動化制造設備上的程序選擇他的理由很簡單：他是技術小組中唯一參加過編程培訓的人他懂得匯編語言和Fortran語言，但是他不知道軟件工程，更不知道軟件計劃和跟蹤方面的知識軟件開發(fā)過程模型選擇,,主要內容,項目實施的方法選擇問題,,識別項目中的高風險,,軟件開發(fā)過程模型的選擇,,可選擇的模型,,軟件開發(fā)項目過程的選擇,,軟件開發(fā)方法,,,項目實施的方法選擇,技術選擇,,技術選擇將影響：,,開發(fā)人員的訓練需要,,人員招聘,,開發(fā)環(huán)境——硬件和軟件,,系統(tǒng)維護安排,,方法選擇,,方法選擇將影響：,,開發(fā)人員組合,,實施的進度安排,,開發(fā)策略選擇,,項目實施的方法選擇,步驟：,,分析目標驅動還是產品驅動,,分析項目其他特征,,面向數據還是面向控制,,通用還是專用,,是否需要專用工具支持的專門技術,,是否有特殊的安全性要求,,對軟硬件有何要求,,識別項目中的高風險,,產品不確定性,：,系統(tǒng)需求理解,的準確性用戶在開始時有可能對系統(tǒng)應該什么樣都無法確定在某些環(huán)境中，精確而有效的需求描述可能迅速變得過時過程不確定性,：在項目開始時需要,選擇方法或過程模型,，或者一種新的工具，任何對原先采用的開發(fā)方法的變化都將引入不確定性,,資源不確定性,：項目進行中,資源的數量,可能發(fā)生變化,,軟件開發(fā)過程模型的選擇,開發(fā)一個軟件需要選擇,開發(fā)策略,（包括過程，方法和工具）以及,通用階段,，這些策略和階段被稱為,過程模型,,“過程”：相關聯的活動,,過程模型的選擇基于項目和應用的特性，使用的工具和方法，所需要的控制方法和交付物。

軟件生存周期,(Software Life Cycle),,軟件產品或軟件系統(tǒng)從設計、投入使用到被淘汰的全過程,,軟件生存期的階段劃分,,可行性研究與計劃,,需求分析,,總體設計,,詳細設計,,實現,,集成測試,,確認測試,,使用和維護,軟件生存周期,《計算機軟件開發(fā)規(guī)范》,上游,下游,,新的國際標準定義的軟件生存過程（,1995 ISO/IEC 12207,）,軟件生存期過程,支持過程,組織過程,主要過程,獲,,取,,過,,程,供,,應,,過,,程,開,,發(fā),,過,,程,運,,行,,過,,程,維,,護,,過,,程,文,,檔,,編,,制,,過,,程,配,,置,,管,,理,,過,,程,質,,量,,保,,證,,過,,程,驗,,證,,過,,程,確,,認,,過,,程,聯,,合,,評,,審,,過,,程,審,,核,,過,,程,問,,題,,解,,決,,過,,程,管,,理,,過,,程,基,,礎,,設,,施,,過,,程,改,,進,,過,,程,培,,訓,,過,,程,,,只考慮,,編寫程序,,涉及整個,,軟件生存,,周期,擴展到,軟件工作的范圍,,軟件開發(fā)全部過程、活動和任務的,結構框架,直觀表達軟件開發(fā)全過程,,明確規(guī)定要完成的主要,活動、任務和開發(fā)策略,,也稱為：,,軟件過程模型,,軟件生存周期模型,,軟件工程范型,軟件開發(fā)模型,,問題求解的一般過程,問題求解的一般過程,,,,,,,實際問題并不能簡單劃為四個階段，各個階段會在問題的不同層次上同時并存,,軟件開發(fā)實際上是一個“混沌”（chaos）過程,問題定義,方案集成,技術開發(fā),現狀,,A.編碼修正模型,Code and Fix,,Code like Hell(魯莽編碼),,從一個大致的想法開始工作，然后經過非正規(guī)的設計、編碼、調試和測試方法，最后完成工作,可能有可能沒有的規(guī)范,發(fā)布（可能）,,編碼修正模型,好處：,,成本可能很低,,只需要很少的專業(yè)知識，任何寫過程序的人都可以,,對于一些非常小的、開發(fā)完后就會很快丟棄的軟件可以采用,,對于規(guī)模稍大的項目，采用這種模型是很危險的,,B.瀑布模型（Waterfall Model,),所有過程模型的祖宗,,項目從開始到結束按照一定的順序執(zhí)行,,瀑布模型是,文檔驅動,的，各個階段不連續(xù)也不交叉,,B.,瀑布模型,,(,Waterfall Model,),可行性研究與計劃,需求分析,設計,編碼,運行維護,測試,定義,,階段,開,,發(fā),,階,,段,維護階段,適應場合？,,優(yōu)缺點？,,瀑布模型的適用場合,有一個,穩(wěn)定產品定義,和很,容易被理解的技術解決方案,時，純瀑布模型特別合適,,對一個定義得很好的版本進行,維護,或將一個產品,移植平臺,，瀑布模型也特別合適。

純瀑布模型能夠,降低管理費用,，因為你可以預先完成所有計劃對于那些容易理解但很復雜的項目，采用純瀑布模型比較合適，因為可以,用順序方法處理問題,在,質量需求高,于成本需求和進度需求的時候，它尤為出色當開發(fā)隊伍的,技術力量比較弱,或者缺乏經驗時，瀑布模型更為適合瀑布模型缺點,純瀑布模型在項目開始時，在設計工作完成前和代碼寫出來前，,很難充分描述需求,瀑布模型最主要問題是,缺乏靈活性,必須在項目開始前說明全部需求但這恰恰是非常困難的按照傳統(tǒng)瀑布模型開發(fā)軟件的特點,階段間具有順序性和依賴性推遲實現的觀點每個階段必須完成規(guī)定的文檔;,,每個階段結束前完成文檔審查,及早改正錯誤C.瀑布模型變種：V型模型,該方法是對瀑布模型的修正，強調了驗證活動,可行性研究,用戶需求,系統(tǒng)設計,程序設計,編 碼,程序測試,系統(tǒng)測試,用戶接受,評價,修正,,修正,,修正,,修正,,,D. 瀑布模型變種：生魚片模型,把階段重疊起來的瀑布模型,,起源于日本硬件開發(fā)模型（富士通—施樂）,軟件概念,需求分析,架構設計,詳細設計,編碼和調試,系統(tǒng)測試,,生魚片模型的特點和缺點,傳統(tǒng)的瀑布模型,強調,階段之間,最小,重疊,，而生魚片模型,強調大幅度重疊,，即在需求分析完成之前就可以進行架構設計和部分詳細設計,,純瀑布模型強調在任意兩個階段交接時，,文檔,從一個團隊交給另一個,完全隔離,的團隊，但是如果一個團隊完成各個階段任務時，可以沒有那么多,文檔,。

問題：缺點是什么？,,生魚片模型因為階段重疊，因而,里程碑不明確,，很難有效地進行過程跟蹤和控制E. 瀑布模型變種：具有子項目的瀑布模型,純瀑布模型的問題：必須完成全部架構設計后才能進行詳細設計，但是，整個系統(tǒng)中有些部分可能有些特殊性，可以有自己的步驟，即將這些部分劃分為子項目問題：該模型有何問題？,,這種方法的主要風險是,相關性,無法預料F. 瀑布模型變種：能夠降低風險的瀑布模型,純瀑布模型：要求在開始,架構設計前,，必須,將用戶的所有需求都搞清楚,，但是實際中是很困難的可降低風險的瀑布模型是在頂端，即,需求分析和架構設計階段引入螺旋,以便降低風險螺旋中，,先開發(fā)一個用戶界面原型,，采用系統(tǒng)情節(jié)串聯圖版（system storyboarding）引導用戶提出需求，記錄用戶與系統(tǒng)的交互操作方式，或者采用其它需求獲取方法G.快速原型模型（,Rapid Prototype Model,）,,建造/修改,,原型,用戶測試,,運行原型,聽取用,,戶意見,原型范型,,原型模型,需求分析,原型開發(fā),最終系統(tǒng)設計,原型評價,最終系統(tǒng)實現,用戶,,反饋,,分析定義,,系統(tǒng)需求,生成,,原型,系統(tǒng),,設計,程序,,設計,編碼,測試,運 行,,和維護,原型化,含原型化的,,軟件生存期,采用原型模型的軟件生存周期,,原型法的分類,原型是項目系統(tǒng)中的一個方面或者多個方面的工作模型。

拋棄型原型,：用于試驗某些概念，試驗完系統(tǒng)將無用處,,進化型原型,：原型系統(tǒng)不斷被開發(fā)和被修正，最終它變?yōu)橐粋€真正的系統(tǒng)原型法的優(yōu)點,從實踐中學習(Learning by doing),,改善的溝通,,改善的用戶參與,,使部分已知的需求清晰化,,展示描述的一致性和完整性,,可能可以減少文檔,,減少了維護成本,,特征約束（利用工具構造原型可以將某些特性落到實處，而非在紙上寫的那樣容易失誤）,,試驗是否能產生期待的結果,,原型法的缺點,用戶有時誤解了原型的角色，例如他們可能誤解原形應該和真實系統(tǒng)一樣可靠,,缺少項目標準，進化原型法有點像編碼修正,,缺少控制，由于用戶可能不斷提出新要求，因而原型迭代的周期很難控制,,額外的花費：研究結果表明構造一個原型可能需要10%額外花費,,運行效率可能會受影響,,原型法要求開發(fā)者與用戶密切接觸，有時這是不可能的例如外包軟件從另外的角度看待原型,從中學到什么？,,學生經常會做一些軟件作業(yè)，這些作業(yè)被稱為原型，,,問題：這些原型和軟件系統(tǒng)原型是否相同？,,但是作為一個原型必須：描述他們希望從中學到的東西，規(guī)劃原型評價的方法，報告從原型中真正學到的內容在不同的階段，原型具有不同的作用。

原型起作用的程度,,實物模型（Mock-ups）,,仿真交互,,部分模型：水平，垂直（某些特性構造詳細原型,）,,H.演化模型,增量模型(Incremental Model),,,螺旋模型(Sprial Model),,H.1 增量模型(遞增模型),先完成一個系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加功能 (系統(tǒng)子集),如此遞增下去直至滿足全部系統(tǒng)需求系統(tǒng)的總體設計在初始子集設計階段就應作出設想分析,設計,編碼,測試,分析,設計,編碼,測試,分析,設計,編碼,測試,分析,設計,編碼,測試,增量1,增量2,增量3,增量n,增量1,,交付客戶,增量2,,交付客戶,增量3,,交付客戶,增量n,,交付客戶,日歷時間,…..,H.1 增量模型,,風險,,分析,工程,,實施,用戶通信,用戶,,評估,產品維護項目,產品增強項目,新產品開發(fā)項目,概念開發(fā)項目,計劃,建造及發(fā)布,H.2 螺旋模型,,螺旋模型的優(yōu)缺點,優(yōu)勢：隨著迭代的增加（成本的增加），風險程度隨之降低,,缺陷：比較復雜，需要責任心，專注和管理方面的知識H.3,,WIN-WIN螺旋模型,在螺旋模型中，通過與客戶的通信獲取客戶的需求，實際上，客戶的需求與最終確定的需求是不一致的，客戶與開發(fā)者之間需要進行協商，最終達到雙贏的局面。

Boehm提出的WIN-WIN螺旋模型中，客戶與開發(fā)者之間需要,,識別系統(tǒng)或子系統(tǒng)的關鍵stakeholders,,確定涉及者的“win conditions”,,對這些條件進行協商獲得互贏條件,,WIN-WIN螺旋模型,WIN-WIN螺旋模型還引入了三個過程的里程碑，被稱為定位點（Anchor points）,,生命周期目標（life cycle objectives）:定義每個主要活動的目標,,生命周期體系結構（life cycle architecture）:定義系統(tǒng)和軟件的體系結構目標,,初步操作能力（initial operational capability）:定義軟件安裝，發(fā)布目標I. 并行開發(fā)模型,并行開發(fā)模型（concurrent development model）又被稱為并行工程（concurrent engineering）（By Davis and Sitaram）,,軟件開發(fā)中的所有活動可能,同時并存,，但是都處于不同狀態(tài)中,,并行開發(fā)模型定義了活動從一個狀態(tài)轉化為另一個狀態(tài)的事件,,并行開發(fā)模型,None,Awaiting changes,Under revision,Under review,Baselined,Done,Under development,Analysis activity,,并行開發(fā)模型,并行過程模型經常被用于開發(fā)C/S系統(tǒng)。

該系統(tǒng)的活動可以被分為系統(tǒng)維和部件維系統(tǒng)維:包含設計，裝配和使用三個活動,,部件維:包含設計和實現兩個活動,,并發(fā)性表現在兩個方面：,,系統(tǒng)和部件的活動同時發(fā)生,,各個部件可以并行設計和開發(fā),,“基于版本發(fā)布”的特點,V,1.0,功,,能,時間,,,,V,2.0,V,1.1,,Trade-off Decision,(,折中決定,),,√,,√,,,,,√,,可 靠 性,發(fā)布日期,,功 能,,最優(yōu),約束范圍,可接受,正確的,Trade-off,決定,,J. 面向對象模型,噴泉模型(Fountain Model),,可重用部件組裝模型 (構件集成模型 Component Integration Model),,分析,設計,,實現,測試,集成,演化,J.1 噴泉模型,,噴泉模型特點,主要用于支持面向對象開發(fā)過程體現了軟件創(chuàng)建所固有的迭代和無間隙的特征,,J.2 可重用部件組裝模型,(構件集成模型),使用重用技術的軟件工程模型,,構件,(,components),：,可重用的軟件成份,,可復用性,（,Reusability,）,,集成化軟件開發(fā)環(huán)境,（,ISEE,）,,用戶,,通信,計劃,產品開發(fā)及發(fā)布,用戶,,評估,風險,,分析,標志候,,選構件,查找,,構件,若存在則,,提取構件,若不存在則,,構造構件,進行下,,一次迭代,將新構件,,存入庫中,可重用部件組裝模型,,基于構件的軟件工程(CBSE)過程模型,,構 件 開 發(fā),,分析 設計 編程 測試,領域分析,系統(tǒng),,測試,構件提交,領域專家經驗,現有系統(tǒng)資料,領域構,,件需求,構件/構架庫,領域構架,領,,域,,構,,件,,,系統(tǒng),,開發(fā),系統(tǒng)專用構件,應用,,系統(tǒng),構件生產線,領域構架,領域構件,問題域,用戶需求,系統(tǒng)生產線,系 統(tǒng) 組 裝,,分析 設計 編程,構架細化,專,,用,,構 件,,開,,發(fā),,分析 設計 編程 測試,,軟件生產線,應用構件,,提取車間,構件生,,產車間,標準規(guī)范 與 質量保證,1,基礎構件，,2,功能構件,,3,接口構件，,4,用戶界面構件,應用,,構件庫,構件庫,組裝,,車間,領域,,1,領域,,2,應用,,系統(tǒng),...,1,2,3,4,,轉換,模型,(,Transformational Model,),,,凈室模型,(,Cleanroom,Model,),K.形式化方法模型,,K.1 轉換模型,形式化,,規(guī)格說明,與需求比,,較后修正,,形式化開發(fā)記錄,變換,n,變換,2,變換,1,測試,系統(tǒng)需求,目標系統(tǒng),,形式化規(guī)格語言及其變換技術,基于模型的規(guī)格說明及其變換技術,,基于代數結構及其變換技術,,基于時序邏輯的規(guī)格說明和驗證技術,,基于可視形式化技術,,K.2 凈室模型(形式化的增量開發(fā)模型),基于思想,：,,力求在分析和設計階段就消除錯誤，確保正確，然后在無缺陷或“潔凈”的狀態(tài)下實現軟件的制作。

三個關鍵技術,,置于統(tǒng)計過程控制之下的增量開發(fā),,基于函數的規(guī)范、設計、驗證,,統(tǒng)計測試和軟件認證,,凈室模型,盒結構,,規(guī)約,需求,,收集,形式化,,設計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量 #1,盒結構,,規(guī)約,需求,,收集,形式化,,設計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量 #2,盒結構,,規(guī)約,需求,,收集,形式化,,設計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量 #1,.,,.,,.,.,,.,,.,.,,.,,.,.,,.,,.,,L. 階段交付,階段交付持續(xù)地在確定的階段向用戶展示軟件和漸進原型不同，在階段交付的時候，你明確地知道下一步要完成什么工作階段交付的特點是不會在項目結束的時候一下交付全部軟件，而是在項目整個開發(fā)過程中持續(xù)不斷地交付階段性成果階段交付,軟件概念,需求分析,構架設計,階段1：詳細設計，編碼，調試，……,階段2：詳細設計，編碼，調試，……,,階段交付的優(yōu)缺點,優(yōu)點：項目結束交付全部成果前，分階段將有用的功能交付給用戶缺點：如果管理層面和技術層面上缺乏仔細規(guī)劃，工作就無法進行。

使用階段交付的注意點：,,必須確定每一階段的交付是對用戶有用的,,必須確?？紤]了不同產品組成部分的技術依賴關系,,M. 面向進度的設計,類似于階段交付，但是面向進度的設計生命周期模型在開始的時候不必知道究竟能達到何目標，但是要確保最后的,期限,該模型的關鍵是要,按優(yōu)先級別劃分系統(tǒng)特性并規(guī)劃開發(fā)階段,，保證前面的階段具有高優(yōu)先級的特性，低特性具有低優(yōu)先級別是否采用這種方法決定于你是否對系統(tǒng)目標具有足夠的信心，如果有信心，則沒必要采用這種方法N.漸進交付,漸進交付是一種跨越了漸進原型和階段交付兩種模型的過程模型基本過程：開發(fā)一個產品的版本，展示給用戶，根據反饋改善產品如果計劃滿足用戶的絕大部分需求，漸進交付與漸進原型差不多，如果計劃滿足少量的需求，漸進交付就和階段交付差不多漸進原型，強調的是系統(tǒng)看得見的樣子，再回來堵漏洞，漸進交付中，最初的重點是系統(tǒng)核心和底層系統(tǒng)功能,漸進交付,軟件概念,需求分析,構架和內核設計,開發(fā)一個版本,并入用戶反饋,交付該版本,開發(fā)一個版本,交付最終版本,,確定漸進交付目標的一種方法,價值成本比,,軟件開發(fā)方法,,軟件開發(fā)過程遵循的方法和步驟,,幾種典型的開發(fā)方法：,,模塊化方法（,modular method,）,,,結構化方法,,,面向數據結構方法,,,面向對象方法,,軟件開發(fā)需要項目管理,軟件開發(fā)是個系統(tǒng)工程,,需要資源的協調,,軟件開發(fā)過程的選擇與項目的協調緊密相關,,,項目管理、工具、技術、流程與組織,,,主要內容,回顧,,軟件項目實施的方法選擇,,軟件開發(fā)過程模型的選擇,,軟件開發(fā)方法,,項目管理,,項目管理基本概念,,實施項目管理的工具與技術,,項目管理的流程,,項目管理的流程特征（產品／項目／軟件項目）,,項目管理組織結構,,軟件項目管理的流程,,,? 建立不現實的最終期限,,? 不斷變更的客戶需求,,? 對努力的低估,,? 可預見和不可預見的風險,,? 技術的困難性,,? 項目成員的溝通不暢通,,? 項目管理不利,為什么項目會失敗?,,People,— 項目成功的最重要因素,,Product,— 建立的軟件,,Process,— 框架活動集合和得到工作的軟件工程任務,,Project,— 實現產品所需要的所有工作,The 4 P’s,,軟件梯隊,被解決問題的難易程度,,代碼和功能點形成的結果程序的規(guī)模,,梯隊的生存周期,,問題被模塊化的程度,,被建立系統(tǒng)所需要的質量和可靠性,,發(fā)布日期的嚴格性,,項目的社會化程度（溝通程度）,選擇軟件項目梯隊結構所要考慮的因素,,...,,建立范圍—陳述性描述，約束問題表達,,分解—建立功能性分割,問題定義,,發(fā)現項目的關鍵,系統(tǒng)為什么被開發(fā)?,,做什么? 什么時候?,,誰對某一功能負責?,,他們組織定位在哪里?,,從技術和管理上工作怎樣被做?,,多少資源需要 (e.g., 人, 軟件, 工具, 數據庫)?,Barry Boehm,,形式的風險分析,,經驗成本和進度估算,,基于度量的項目管理,,價值跟蹤（Earned value tracking）,,質量目標下的跟蹤,,人要意識到項目管理,關鍵實踐,,什么是項目,項目是什么,,沒有例行的任務,,需要計劃,,特定的目標需要滿足或者特定的產品需要生成,,項目有一個預定義的時間范圍,,工作不僅僅是為自己，也是為他人,,工作中有些特性,,工作分為若干階段,,項目完成需要資源,,項目是大型的或者復雜的,,什么是項目管理,項目管理是在項目活動中應用知識，技能，工具和技術來,滿足項目需求,的,過程,，它通過初始化，計劃，執(zhí)行，控制和結束等,活動,來完成。

項目生命周期,項目生命周期定義一個項目的,開始,與,結束,項目生命周期定義的階段順序通常包括某些技術轉移或“握手”(hand off)，如從需求到設計，從構造到運行，但是在風險允許下，也可以下一階段提前進行，這種重疊的階段被稱為快速跟蹤(fast tracking)項目生命周期通常定義：,,各個階段需要完成的技術工作；,,每個階段需要涉及的人項目生命周期,絕大多數項目生命周期有一些共同的特點，如成本和人員消耗的變化曲線項目生命周期與產品生命周期是不同的項目中的人員,項目影響者(stakeholders),,項目小組內部：,,項目小組外部，但是在同一組織內：,,項目小組和組織外部：如客戶,,不同的項目影響者有不同的目標，因而項目領導者需要能夠協調這些目標Boehm和Ross提出軟件項目管理的“W理論”，該理論關注于所有各方都能從項目種獲益因而對項目的成功都有興趣W代表Everyone a Winner）,,軟件項目管理定義,軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動軟件項目包含的活動,需求分析,,描述,,設計,,編碼,,校驗,,安裝,,維護,,支持,,應用項目管理方法開展軟件開發(fā),項目的可行性分析,,需求開發(fā)與需求管理,,軟件項目工作量估算,,軟件項目計劃與資源分配,,軟件項目監(jiān)控,,風險管理,,軟件質量管理與軟件開發(fā)規(guī)范,,軟件項目中的人員管理,,軟件配置管理,,項目可行性分析與評估,,,內容安排,可行性分析的內容,,項目范圍管理,,技術評估,,經濟評估,,風險評估,,可行性報告,,項目建議書,,需求建議書,,可行性分析,目的,,“說明該軟件開發(fā)項目的實現在技術上、經濟上和社會條件上的可行性；評述為合理地達到開發(fā)目標可能選擇的各種方案”。

GPS監(jiān)控系統(tǒng)的投資失誤,,做什么？近期目標？,,人員配備，怎樣整合,,需求調研問題,,開發(fā)費用問題,,風險規(guī)避,,頂新國際集團：在投資新產品時,,1400萬：全國28個城鎮(zhèn)居民消費習慣調查,,700 萬：委托28個城鎮(zhèn)社會科學院進行全國七大區(qū)域總體經濟投資環(huán)境的分析,,任務,,了解客戶要求及現實環(huán)境，從技術、經濟和社會因素研究并論證軟件項目可行性，編寫可行性報告，制定初步項目開發(fā)計劃,,“,什么都不做,”永遠是一個可考慮的方案,,可行性分析的內容,項目范圍,,策略評估,,技術評估,,經濟評估,,風險評估,,項目范圍管理內容,保證項目,包括并且僅僅包括,需要包括的內容它由以下步驟組成：,,初始化：對項目或階段,授權,,范圍計劃：開發(fā)一個作為將來項目決策基礎的,書面,的范圍聲明,,范圍定義：將,項目交付物細分,為更小的，更易管理的元件,,范圍校驗：形式化項目范圍的接受條件,,范圍變更控制：控制項目范圍的變更,,范圍的含義,“范圍”包含產品范圍和項目范圍,,產品范圍：產品或服務的特點和功能,,項目范圍：為了生產具有特定特點和功能的產品所需要的工作,,軟件范圍,軟件項目計劃的第一項任務就是確定軟件的工作范圍，即,軟件的用途及對軟件的要求,。

因此，應從管理角度和技術角度出發(fā)，確定明確的可理解的軟件項目范圍軟件范圍的敘述,明確給出,定量的,數據（例如，同時使用該軟件的用戶數目，發(fā)送表格的長短，最大允許響應時間等）,,指明,約束條件和/或限制,（例如，產品成本限制了存儲的容量）,,敘述某些,質量,因素（例如，給出的算法是否容易理解、是否使用Ada語言等）,,軟件范圍的估計,軟件范圍包括功能、性能、限制、接口和可靠性功能：,,軟件功能評價，并進行適當細化,,功能分解，滿足未來成本和進度估算要求,,性能,,包括處理和響應時間的需求約束條件：,,外部硬件、可用存儲或其他現有系統(tǒng)對軟件限制功能、性能和約束必須在一起進行評價當性能限制不同時，為實現同樣的功能，開發(fā)工作量可能相差一個數量級如果功能保持相同而性能可變，則開發(fā)軟件所需的工作量和成本將有顯著的差異價值驅動的電子商務分析方法,,,,,業(yè)務流程,,模型,,,業(yè)務概念,,模型,策略,規(guī)劃級,結構級,實施級,電子商務技術層,業(yè)務策略的概念結構,,,概念建模,協商建模,價值驅動流程建模,,,資,源,價,值,配,置,伙,伴,網,絡,價,值,鏈,構,架,信,息,策,略,發(fā),布,渠,道,客,戶,信,任,客,戶,關,系,企,業(yè),能,力,價,值,建,議,目,標,客,戶,產,品,與,服,務,創(chuàng),新,R,e,v,e,n,u,e,,M,o,d,e,l,價,值,結,構,收,入,模,型,收,益,/,損,失,資,產,、,財,務,電子商務概念模型,,初始化,初始化(Initiation),,正式授權一個新項目或者決定一個已有項目繼續(xù)進行下一階段,,項目是由于下面一些原因產生的：,,市場需要（新性能汽車）,,業(yè)務需要（培訓中心新課程設計）,,客戶需要（客戶定制產品）,,技術進步（如計算機技術進步）,,法規(guī)需要（污染處理）,,社會需要（政府水處理系統(tǒng)）,,初始化,輸入：,,產品描述,,策略計劃：企業(yè)的戰(zhàn)略計劃,,項目選擇準則（經濟回報，市場回報，公共形象）,,歷史信息：以前項目的結果和性能,,工具和技術,,項目選擇方法,,專家判斷,,輸出：,,項目章程（授權項目的正式文檔，包括業(yè)務需求，產品描述）,,項目經理指派,,約束,,假設,,范圍計劃,范圍計劃是將生成產品的項目工作（項目范圍）,逐步細化,的過程。

輸入：,,產品描述,,項目章程,,約束,,假設,,工具和技術,,產品分析,,利益成本分析(Benefit/Cost Analysis),,備選方案（brainstorming or lateral thinking),,專家判斷,,范圍計劃,輸出,,范圍聲明（Scope Statement)，包括,,項目理由：Project Justification(Business need),,項目產品:概述,,項目交付物：project deliverables,,項目目標: 判斷項目是否成功的定量準則,,支持細節(jié)（包括假設和約束）,,范圍管理計劃,,,范圍定義,范圍定義涉及到將主要的項目交付物細分以：,,提高成本，周期和資源估計的準確性,,定義性能度量和控制的基線,,便于清晰定義責任分配,,范圍定義正確與否將影響項目的節(jié)奏，進度，生產率和項目人員的士氣范圍定義,輸入,,范圍聲明,,約束,,假設,,其它計劃輸出,,歷史信息,,工具和技術,,WBS(Work breakdown structure)模板,,分解技術,,策略評估中的模塊管理,模塊管理（Programm management),,“模塊是一組協調管理的項目，通過將項目組成模塊，將獲得比單個管理項目更大的效益。

——D. C. Ferns,,有效的模塊管理需要有一個模塊目標，項目必須根據模塊目標來選擇,,在大的組織中，將可能有模塊管理的機構，例如模塊主管或者模塊經理,,即使沒有專門的組織來管理模塊，項目的選擇也需要根據組織的整個業(yè)務目標來評價,,策略評估的內容,目標：提出的系統(tǒng)對組織目標具有怎樣的貢獻？例如它是否能夠增加市場份額？,,IS計劃：提出的系統(tǒng)如何與IS計劃相適應？它將替換或者與那些系統(tǒng)接口？它與將來開發(fā)的系統(tǒng)有何交互關系？,,組織結構：新系統(tǒng)對目前的部門和組織結構有何影響？例如一個新的訂單處理系統(tǒng)是否與目前的銷售與庫存控制的功能相重疊？,,MIS:系統(tǒng)將在組織的何層次上提供何種信息？它將以何種方式對現存管理信息系統(tǒng)進行補充何提高？,,人員：系統(tǒng)將以何種方式影響人力水平何現存雇員的技術？它對組織整個人員開發(fā)策略有何影響？,,情形：系統(tǒng)將使客戶對組織的態(tài)度有何變化？是否采用一個自動化的系統(tǒng)將與提供友好的服務相沖突？,,策略評估中的業(yè)務管理,業(yè)務管理,,選定的項目將成為業(yè)務的一部分，項目將對資源產生競爭,,競爭中對業(yè)務的調整是必要的,,技術評估,技術的成熟程度,,實驗室技術,,經過中試的技術,,已經工業(yè)化應用的技術,,市場需求,,顯在,,潛在：轉化為顯在的條件,,競爭態(tài)勢：,與競爭技術相比，所采用技術的優(yōu)勢及缺陷,,技術轉換成本,,支撐體系與條件：原料、銷售網絡、用戶體系、政策,,技術發(fā)展趨勢及所采用技術的發(fā)展前景,,技術方案選擇,要考慮的制約條件,,需求制約：現存的需求結構及需求結構可能的變化,,資源制約：資金、人力資源、自然資源、其它要素,,環(huán)境制約：經濟技術環(huán)境、社會文化環(huán)境、自然環(huán)境,,選擇原則,,經濟性原則：以最小的投入取得最好的效果,,發(fā)展原則：發(fā)展的前景及適應發(fā)展的能力,,兼容性原則：與原有經濟、技術、環(huán)境、社會的兼容性,,相關效果原則：相關的經濟、技術、環(huán)境、社會效果,,選擇視角,,技術先進性,,技術適用性,,經濟分析,開發(fā)所需要的成本和系統(tǒng)運行所需要的成本與得到的效益的比較,,識別出項目進行中所需要的所有成本和效益并對其進行聚集,,將成本和效益用單元來表達,,成本分為,,開發(fā)成本,,安裝成本,,運行成本,,經濟分析,效益,,直接效益,,可見的間接效益,,不可見的效益,,經濟分析,凈收益（Net Profit):項目的凈收益是在項目生命周期內總的收入與總的成本的差。

沒有考慮時間因素,,回收期限（Payback Period）：將初始投資收回的期限,,忽略了整個項目的盈利空間,,經濟分析,投資回報(Return on investment):也被稱為回報率(accounting rate of return)(ARR),,ROI=（平均年收益/總投資）×100,,例如項目1：ROI=10,000/100,000*100=10%,,缺點：,,沒有考慮時間因素,,該回報率易與銀行利率混淆,,,經濟分析,凈現率(Net Present Value),,考慮了時間因素,,對將來的收益打一個折扣,,“拿在手里的錢才是真正的錢”,,如果假定年折扣率為10％，那么明年的100元等于現在手中的91元，后年的100元等于現在的83元,,目前值＝t年的值/(1+r),t,,系統(tǒng)開發(fā)和每年運行費用舉例,1.系統(tǒng)開發(fā)費用（一次）,,人員：,,.,2名系統(tǒng)分析員(,450小時/名,45美元/小時,),$40,500,,.,5名系統(tǒng)開發(fā)人員(,275小時/名,36美元/小時,),$49,500,,.,1名數據通訊專家(,60小時/名,42美元/小時,),$2,400,,.,1名數據庫管理員(,30小時/名,42美元/小時,),$1,260,,.,2名技術寫作者(,120小時/名,25美元/小時,),$6,000,,.,1名秘書(,160小時/名,15美元/小時,),$2,400,,.,2名在轉換期間數據輸入人員,$49,500,,(,40小時/名,12美元/小時,),,系統(tǒng)開發(fā)和每年運行費用舉例,培訓：,,三天的開發(fā)人員內部培訓課程 $,7,000,,30個用戶，三天的內部培訓課程 $,10,000,,物資：,,復印 $,500,,磁盤、紙張等消耗品 $,650,,,系統(tǒng)開發(fā)和每年運行費用舉例,購買硬件、軟件：,,20,臺工作站,Windows,軟件,,,$,1,000,,20,臺工作站內存升級,$,8,000,,網絡軟件,$,17,500,,20,臺工作站辦公軟件產品,$,20,000,,系統(tǒng)開發(fā)總費用,$161,670,,系統(tǒng)開發(fā)和每年運行費用舉例,2.年運行費用（每年）,,人員：,,維護程序員/分析員(250小時/年,42美元/小時) $10,500,,網絡管理員(300小時/年,50美元/小時) $15,000,,購買硬件、軟件升級：,,硬件 $5,000,,軟件 $6,000,,物資和雜項 $3,500,,每年總運行費用 $40,000,,可行性研究的步驟,,(1)復查確認系統(tǒng)目標、規(guī)模,,(2)研究正使用系統(tǒng)工作流程,,(3)導出新系統(tǒng)高層邏輯模型,,(4)重新定義問題,,(5)導出和評價供選擇的方案,,(6)推薦可行的方案,,,(7)草擬開發(fā)計劃,,(8)編寫可行性研究報告，送審,,可行性分析,可行性分析報告的格式,,可行性研究報告的編寫提示,,GB 8567-88《 計算機軟件產品開發(fā)文件編制指南 》,1 引言,,1.1 編寫目的,,1.2 背景,,1.3 定義,,1.4 參考資料,,可行性研究報告的編寫提示,2 可行性研究的前提,,2.1 要求,,2.2 目標,,2.3 條件、假定和限制,,2.4 進行可行性研究的方法,,2.5 評價尺度,,可行性研究報告的編寫提示,3 對現有系統(tǒng)的分析,,3.1 數據流程和處理流程,,3.2 工作負荷,,3.3 費用開支,,3.4 人員,,3.5 設備,,3.6 局限性,,可行性研究報告的編寫提示,4 所建議的系統(tǒng),,4.1 對所建議系統(tǒng)的說明,,4.2 數據流程和處理流程,,4.3 改進之處,,4.4 影響,,4.5 局限性,,4.6 技術條件方面的可行性,,可行性研究報告的編寫提示,5 可選擇的其它系統(tǒng)方案,,5.1 可選擇的其它系統(tǒng)1,,5.2 可選擇的其它系統(tǒng)2,,......,,,可行性研究報告的編寫提示,6 投資及收益分析,,6.1 支出,,6.2 收益,,6.3 收益/投資比,,6.4 投資回收周期,,6.5 敏感性分析,,可行性研究報告的編寫提示,7 社會條件方面的可行性,,7.1 法律方面的可行性,,7.2 使用方面的可行性,,項目建議書,起源：組織內部認識到需要利用信息技術,,改進目前的業(yè)務運行,,改進目前的信息系統(tǒng),,開發(fā)新的產品,,目的：,,使管理層能夠作出項目決策,,準備招標書,目的：,,從客戶的角度全面地、詳細的論述，為了達成確定的需求應需要作何準備,,一份招標書應當是全面的，能提供足夠詳細的信息，以使承約商或項目團隊能針對顧客的需要相應地準備一份最優(yōu)的招標書,,招標書,招標書中需要提供工作表述,,招標書中必須包括客戶要求，此要求中規(guī)定了規(guī)格和特征,,招標書應當說明客戶期望承約商或項目團隊提供什么樣的交付物,,招標書中應當列舉客戶供應條款,,招標書中可以表述出客戶對需要的確認,,招標書中可以提到客戶想要用的合同類型,,招標書,表述出客戶想用的付款方式,,表述出項目完成所需的進度計劃,,提供有關承約商申請書的格式和內容安排,,支持客戶希望潛在承約商提交申請書的最后期限,,可能包括評價標準,,可能會指出客戶所擁有的可用于此項目的資金量。

案例分析,寧波市第五次全國人口普查辦公室的寧波市人口地理信息系統(tǒng),,地理空間分析、人口統(tǒng)計與分析一體化,,寧波人口普查、日常管理、統(tǒng)計與分析的數字化、可視化,,人口信息存儲、管理與分析，建立規(guī)范化的空間地理信息與人口信息統(tǒng)一管理、分析、統(tǒng)計、發(fā)布、錄入、更新與維護,,對空間數據和人口數據的快速采集、建庫、維護、查詢、管理、顯示、輸出、統(tǒng)計分析、共享與發(fā)布功能,,案例分析,性能要求,,滿足寧波全部市縣人口的數據存儲,,不同縣區(qū)都可以調用數據，操作數據,,保證調查高峰操作響應的人機交互,,保證數據統(tǒng)計的響應時間,,,案例分析,限制要求,,Windows平臺客戶端,,服務器選用Intel服務器,,存儲RAID，保證存儲安全,,與DOMINO辦公系統(tǒng)可以實現接口，可以抽取數據報表,,,需求開發(fā)與需求管理,,,主要內容,從一個故事看軟件開發(fā)的實際問題,,需求管理的困難性,,管理需求的目的,,軟件需求特性,,需求工程,,如何獲取需求,,需求規(guī)格說明,,需求管理工具,,,軟件開發(fā)面臨的實際問題,,軟件開發(fā)面臨的實際問題,,軟件開發(fā)面臨的實際問題,,為什么？？？,需求？？？,,什么是需求,需求為用戶解決問題或達到,目標,所需的條件或權能,,系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范和其它正式規(guī)定文檔所需具有的,條件,或權能,,一種反映上述條件或權能的,文檔說明,,舉例,系統(tǒng)必須提供基于PPPoE協議的用戶接入模式,,產品應當提供機架式安裝，并提供兩個千兆以太網端口,,系統(tǒng)使用的用戶是信息中心和網絡管理員,,系統(tǒng)在運行時必須提供自動數據備份功能,,簡要的解釋,需求來源于用戶的一些,“需要”,，這些“需要”被,分析、確認,后形成,完整文檔,，該文檔詳細地說明了產品,“必須或應當”,做什么。

如果只有一些零碎的對話、資料或郵件，你就以為自己已經掌握了需求，那是自欺欺人需求管理的困難性,需求,不,總是,顯而易見,的，而且它可來自各個方面需求并,不,總是能容易用,文字明白,無誤地,表達,存在,不同種類的需求,，其,詳細程度,各,不相同,如果不加以控制，需求的,數量將難以管理,需求之間,相互關聯,，而且需求也和軟件工程流程中的其他可交付工件有關需求有,唯一的特征或特征值,例如，它們的重要性和容易滿足的程度都各不相同需求涉及眾多相關方面，這意味著需求要由功能交叉的各組人員管理需求會,變更,為什么要管理需求,為什么要管理需求？,,避免失敗就是一個很充分的理由,提高項目的成功率,,需求管理帶來其他好處,,Standish Group 的 CHAOS 報告進一步證實了與成功項目關系最大的因素是良好的需求管理什么是軟件需求,從軟件開發(fā)過程看軟件需求開發(fā),,從軟件發(fā)展周期看軟件開發(fā)過程,時期,,年代,,階段,,涉及,,注重,,主要使用語言,,標準,,模型,,初期,,50-60,,程序設計,,點,,編程,,技巧,,ALGOL,,FORTRAN,,COBOL,,BASIC,,,,,,中期,,70-80,,軟件開發(fā),,線,,結構化,,模塊化,,PASCAL,,?,GB8566,,軟件開發(fā),,規(guī)范,,?,瀑布,,?,原型,,現代,,90-,,軟件過程,,面,,過程,,能力,,C,C++,,JAVA,,VB、VC,,?,ISO/IEC,,12207,,軟件生存期過程,,?,ISO9000,,?,螺旋,,?,CMM,,,計算機系統(tǒng),,人員,硬件,軟件,數據,傳輸,,機構,執(zhí)行,,機構,（劇作家、導演）,（舞臺,劇本,演員,道具）,軟件開發(fā)全過程,,,,,活動－任務,,⑴系統(tǒng)需求分析,,⑵系統(tǒng)結構設計,,⑶軟件需求分析,,建立軟件需求,,評價軟件需求,,聯合評審,,⑷軟件結構設計,,⑸軟件詳細設計,,⑹軟件編碼和測試,,⑺軟件集成,,⑻軟件鑒定測試,,⑼系統(tǒng)集成,,⑽系統(tǒng)鑒定測試,,⑾軟件安裝,,⑿軟件驗收支持,,軟件開發(fā)過程,,⑴,,定義（IEEE-STD-610）,,用戶為解決某個問題、或為實現某一目標，,,要求軟,件必須滿足的條件或能力。

⑵ 軟件需求的三個層次,,業(yè)務需求,,,用戶需求,,,功能需求和非功能需求,,軟件需求的層次性,,軟件,,系統(tǒng)需求(1),系統(tǒng)需求,分配,軟件工程組,硬件,,系統(tǒng)需求(2),,其它成分,,系統(tǒng)需求(n),,軟件需求,客戶,最終用戶,系統(tǒng)工程組,系統(tǒng)需求分配,,業(yè)務需求,業(yè)務說明,使用實例,用戶需求,功能需求,約束條件,非功能需求,軟 件 需 求 規(guī) 格 說 明,軟件需求的層次,,需求的層次性,,業(yè)務需求,項目視圖與范圍文檔,用戶需求,質量屬性,系統(tǒng)需求,功能需求,約束條件,其它非功能需求,Use Case文檔,軟件需求規(guī)格說明,,非功能需求,,過程需求：交付需求，實現需求，遵循的標準,,性能需求：速度，容量，可靠性,,,外部需求：互操作性，倫理性，,,機密性，安全性，,,使用要求,,非功能,軟件需求,,系 統(tǒng) 需 求,,ACCS應能使汽車保持在預期車速的,?,2KM,?,H范圍內行駛,分配給硬件的需求,,硬件應能使車速在規(guī)定的精確度,?,1.5KM,?,H范。