《軟件工程案例分析-PPT》由會員分享，可在線閱讀，更多相關《軟件工程案例分析-PPT（450頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、,,*,單擊此處編輯母版標題樣式,,單擊此處編輯母版文本樣式,,第二級,,第三級,,第四級,,第五級,,軟件工程案例分析,陳天洲,,浙江大學計算機學院,軟件特征（,1,）,最根本的：軟件是一種邏輯元素而不是物理元素,,軟件是開發(fā)出的，而不是用傳統(tǒng)的方法制造出來的,,軟件不會被用壞,,時間,,失敗概率,一般產(chǎn)品的浴盆曲線,軟件特征（,2,）,,,,,時間,失敗,,概率,軟件失敗概率實際曲線,軟件失敗概率理想曲線,軟件特征（,3,）,工業(yè)界已經(jīng)走向了標準化裝配時代，然而絕大多數(shù)軟件還是定制出來的。,,科學計算函數(shù)庫（,60,年代）,,重用數(shù)據(jù)結(jié)構(gòu),,重用組件,,,成本結(jié)構(gòu)發(fā)生了巨大的變化,一次性的

2、制造成本,,介質(zhì)成本的可忽略性－邏輯產(chǎn)品,,不可回逆的投入,,維護成本的增加,,服務是質(zhì)量要素中的重點,,軟件危機,“,軟件危機,”,是,1958,年在,NATO,會議上作為一個正式的議題被提出來,,軟件項目不成功的例子比比即是：,,1999,年,10,月，耗資,1.25,億美元的,NASA,的火星氣象衛(wèi)星失蹤（公英制轉(zhuǎn)換）,軟件危機,一些數(shù)據(jù)：,,大約,70,％的軟件開發(fā)項目超出了估算的時間，大型項目平均超出計劃交付時間,20,％到,50,％，,90,％以上的軟件項目開發(fā)費用超出預算，并且項目越大，超出項目計劃的程度越高,,美國政府審計局：只有不到,2,％的合同定購軟件在發(fā)布時具有可用性,—

3、—,98,％以上的項目都失敗了,軟件危機,一種看法,,“,兩難境地（,Crunch Mode,）,”,：處于兩難境地的項目面臨無法達到最初目標的威脅（費用、進度表、功能性等），而項目團隊努力想跨越困境。,,“,我們正處于兩難境地，在半夜之前是不會回家,”,,“,死亡行軍（,Death March,）,”,：用來描述其進度表幾乎不可能完成的項目。,,“,這是一個死亡行軍項目，我希望自己不要參與進去,”,軟件危機,更準確的說法：慢性痛苦,（,chronic affliction) Suggested by Prof. Daniel Tiechrow,, University of Michiga

4、n,,盡管忍受痛苦，但是軟件依然在我們這個世界起著越來越重要的作用，但是如果能夠醫(yī)治痛苦，那么軟件業(yè)將發(fā)展得更加健康。,軟件危機的主要特征,軟件開發(fā)周期大大超過規(guī)定日期,;,,軟件開發(fā)成本嚴重超標,;,,軟件質(zhì)量難于保證,,軟件成功的標準,用戶在用,,用戶可很容易做完要做的事,,,失敗的根本原因：,,開發(fā)人員寫出的東西達不到,,用戶要求,(,人的問題,.,技術問題,),規(guī)模,,復雜性,,生產(chǎn)率,軟件技術面臨的問題,,Exchange2000,Windows,2000,項目經(jīng)理,25,人,約,250,人,開發(fā)人員,140,人,約,1700,人,測試人員,350,人,約,3200,人,例,:?,W

5、indows95,有,1000,萬行代碼,,,?,Windows2000,有,5000,萬行代碼，,,,3000,多個工程師，幾百個小團隊。,,,Exchange2000,和,Windows2000,開發(fā)人員結(jié)構(gòu),“,軟件工程案例分析,”,課程,與其它軟件專業(yè)課的區(qū)別,(1),立足于系統(tǒng)的整體。,,(2),系統(tǒng)分析、系統(tǒng)設計、,,測試及維護的方法實踐。,,(3),構(gòu)筑一,個軟件,系統(tǒng),，實踐,,軟件開發(fā)全過程,。,,用戶,,分析員,,程序員,系統(tǒng)分析員的地位,“,一個好的工業(yè)，應有一套良好的標準來配套,”,軟件工業(yè)化生產(chǎn)過程應具備的特點,,明確的工作步驟,,詳細具體的規(guī)范化文檔,,明確的質(zhì)量

6、評價標準,,軟件產(chǎn)品的標準化,軟件開發(fā)過程的標準化,,軟件工程技術的兩個明顯特點,,強調(diào)規(guī)范化,,強調(diào)文檔化,新世紀軟件產(chǎn)業(yè)的趨勢,網(wǎng)絡化趨勢：,計算機與通信的融合趨勢,,萬維網(wǎng),?,智能網(wǎng)絡,,服務化趨勢：,“,打包式,”,軟件,?,“,服務式,”,軟件,,全球化趨勢,中國軟件產(chǎn)業(yè)發(fā)展主要問題,,產(chǎn)業(yè)規(guī)模小、集中度低,,產(chǎn)業(yè)競爭力弱，缺乏核心技術,,市場秩序較為混亂，盜版嚴重,制約軟件產(chǎn)業(yè)發(fā)展的因素,軟件開發(fā)規(guī)范與標準,,知識產(chǎn)權(quán)環(huán)境,,知識結(jié)構(gòu),,公司體制,項目與項目管理,項目是什么,,沒有例行的任務,,需要計劃,,特定的目標需要滿足或者特定的產(chǎn)品需要生成,,項目有一個預定義的時間范圍,,

7、工作不僅僅是為自己，也是為他人,,工作中有些特性,,工作分為若干階段,,項目完成需要資源,,項目是大型的或者復雜的,,項目管理是什么,,項目管理是在項目活動中應用知識，技能，工具和技術來滿足項目需求的過程，它通過初始化，計劃，執(zhí)行，控制和結(jié)束等活動來完成。,軟件項目與軟件項目管理,軟件項目的特征,,不可見,,復雜性（以每一單位貨幣來看）,,靈活性：軟件去適應人或組織而不是相反,,一致性,,軟件項目管理,,為了使軟件項目能夠按照預定的成本、進度、質(zhì)量順利完成，而對成本、人員、進度、質(zhì)量、風險等進行分析和管理的活動。,軟件項目的活動,需求分析,,描述,,設計,,編碼,,校驗,,安裝,,維護,,支持

8、,軟件項目分類,按軟件類別,,信息系統(tǒng)：與組織接口,,嵌入式系統(tǒng)：接口是機器,,操作系統(tǒng)是一個信息系統(tǒng)還是嵌入式系統(tǒng)？,,有些項目是為了生成某一產(chǎn)品，而某些項目的進行是為了達到某些目標。許多軟件項目分為兩個階段，第一階段是目標驅(qū)動，第二階段再生成真正的軟件產(chǎn)品。,從系統(tǒng)的角度看軟件項目,一個項目關注于生成一個系統(tǒng)和,/,或?qū)⒁粋€舊系統(tǒng)轉(zhuǎn)換為一個新系統(tǒng),,系統(tǒng)，子系統(tǒng)和環(huán)境,,開放和封閉系統(tǒng),,項目失敗的一個原因是技術人員不能夠開放系統(tǒng)和立即接受外界的變化。,,部分優(yōu)化,,例如：可能很高效，但是難于修改,,社會技術系統(tǒng),,軟件項目屬于此類,軟件項目中的人員,項目影響者,(stakeholders

9、),,項目小組內(nèi)部：,,項目小組外部，但是在同一組織內(nèi)：,,項目小組和組織外部：如客戶,,不同的項目影響者有不同的目標，因而項目領導者需要能夠協(xié)調(diào)這些目標。,Boehm,和,Ross,提出軟件項目管理的,“,W,理論,”,，該理論關注于所有各方都能從項目種獲益因而對項目的成功都有興趣。（,W,代表,Everyone a Winner,）,軟件開發(fā)面臨的挑戰(zhàn),處理最終日期（,deadlines,）,(85%),,處理資源約束（,83,％）,,與任務小組有效的溝通（,80,％）,,從小組成員處得到承諾（,74,％）,,建立可測量的,milestone,（,90,％）,,處理變化（,60,％）,,得

10、到團隊公認的項目計劃（,57,％）,,從管理層得到承諾（,45,％）,,處理沖突（,42,％）管理銷售商和子項目承包商（,38,％）,項目經(jīng)理面臨的挑戰(zhàn),估計和計劃,,缺少質(zhì)量標準和度量,,缺少組織決策的指南,,缺少使進度可視化的技術,,角色定義,,不正確的成功準則,,缺少標準,項目成員面臨的挑戰(zhàn),工作的不正確的描述,,IT,的管理失誤,,缺少應用領域的知識,,缺少及時的文檔,,前續(xù)任務沒有及時完成,——,包括設備沒及時提供,,用戶與技術員之間缺乏交流,,缺少質(zhì)量控制,,軟件環(huán)境的改變,,Deadline,壓力,軟件項目常見錯誤,選自,《,快速軟件開發(fā),》,,產(chǎn)品相關的錯誤,,需求鍍金：項目具

11、有比實際需求多得多的性能,,功能蔓延：項目平均會有,25%,的需求變更（,Jones 1994,）,,開發(fā)人員的鍍金：開發(fā)人員著迷于新技術,,又推又拉的交易：經(jīng)理在批準項目進度順延時又加入了新的功能,,研究導向的開發(fā),軟件項目常見錯誤（續(xù)）,過程中的錯誤,,缺乏計劃,,過于樂觀的計劃,,在壓力下放棄計劃,,缺乏足夠的風險管理,,承包人導致的失敗,,在模糊的項目前期浪費時間,,前期活動不合要求,過程中的錯誤,,設計低劣,,缺少質(zhì)量保證措施,,缺少管理控制,,太早和過于頻繁的集成,,項目估算時遺漏必要的任務,,追趕計劃,,魯莽編碼,軟件項目常見錯誤（續(xù)）,技術相關的錯誤,,銀彈綜合癥,:,過于相信

12、以前沒有采用過的技術的宣傳,,過高估計了新技術或方法帶來的節(jié)省量,,項目中間切換工具,,缺少自動的源代碼控制手段,,,軟件項目常見錯誤（續(xù)）,人員相關的錯誤,,挫傷積極性,,人員素質(zhì)低,,對有問題的員工失控,,英雄主義,,項目后期加入人員：“火上加油”,,辦公環(huán)境差,,開發(fā)人員與客戶之間發(fā)生摩擦,,不現(xiàn)實的預期,軟件項目常見錯誤（續(xù)）,缺乏有效的高層對項目的支持,,缺乏各種角色的齊心協(xié)力,,缺乏用戶介入,,政治高于物質(zhì),,充滿想像：“項目組沒人真正相信他們能夠按給定的計劃進度完成項目，但他們認為如果每個人能夠努力工作，并且不出現(xiàn)問題，他們可能會很幸運地按時完成任務,。,軟件項目常見的錯誤,試分

13、析以下故事中的項目所存在的錯誤：,,,一天，一位年青人被選來,“,寫,”,一個用在自動化制造設備上的程序。選擇他的理由很簡單：他是技術小組中唯一參加過編程培訓的人。他懂得匯編語言和,Fortran,語言，但是他不知道軟件工程，更不知道軟件計劃和跟蹤方面的知識。,軟件開發(fā)過程模型選擇,主要內(nèi)容,項目實施的方法選擇問題,,識別項目中的高風險,,軟件開發(fā)過程模型的選擇,,可選擇的模型,,軟件開發(fā)項目過程的選擇,,軟件開發(fā)方法,,項目實施的方法選擇,技術選擇,,技術選擇將影響：,,開發(fā)人員的訓練需要,,人員招聘,,開發(fā)環(huán)境,——,硬件和軟件,,系統(tǒng)維護安排,,方法選擇,,方法選擇將影響：,,開發(fā)人員組

14、合,,實施的進度安排,,開發(fā)策略選擇,項目實施的方法選擇,步驟：,,分析目標驅(qū)動還是產(chǎn)品驅(qū)動,,分析項目其他特征,,面向數(shù)據(jù)還是面向控制,,通用還是專用,,是否需要專用工具支持的專門技術,,是否有特殊的安全性要求,,對軟硬件有何要求,識別項目中的高風險,,產(chǎn)品不確定性：系統(tǒng)需求理解的準確性。用戶在開始時有可能對系統(tǒng)應該什么樣都無法確定。在某些環(huán)境中，精確而有效的需求描述可能迅速變得過時。,,過程不確定性：在項目開始時需要選擇方法或過程模型，或者一種新的工具，任何對原先采用的開發(fā)方法的變化都將引入不確定性,,資源不確定性：項目進行中資源的數(shù)量可能發(fā)生變化,軟件開發(fā)過程模型的選擇,開發(fā)一個軟件需要

15、選擇開發(fā)策略（包括過程，方法和工具）以及通用階段，這些策略和階段被稱為過程模型,,“過程”：相關聯(lián)的活動,,過程模型的選擇基于項目和應用的特性，使用的工具和方法，所需要的控制方法和交付物。,軟件生存周期,(Software Life Cycle),,軟件產(chǎn)品或軟件系統(tǒng)從設計、投入使用到被淘汰的全過程,,軟件生存期的階段劃分,,可行性研究與計劃,,需求分析,,總體設計,,詳細設計,,實現(xiàn),,集成測試,,確認測試,,使用和維護,軟件生存周期,《,計算機軟件開發(fā)規(guī)范,》,上游,下游,新的國際標準定義的,軟件生存,過程（,1995 ISO/IEC 12207,）,軟件生存期過程,支持過程,組織過

16、程,主要過程,獲,,取,,過,,程,供,,應,,過,,程,開,,發(fā),,過,,程,運,,行,,過,,程,維,,護,,過,,程,文,,檔,,編,,制,,過,,程,配,,置,,管,,理,,過,,程,質(zhì),,量,,保,,證,,過,,程,驗,,證,,過,,程,確,,認,,過,,程,聯(lián),,合,,評,,審,,過,,程,審,,核,,過,,程,問,,題,,解,,決,,過,,程,管,,理,,過,,程,基,,礎,,設,,施,,過,,程,改,,進,,過,,程,培,,訓,,過,,程,,只考慮,,編寫程序,,涉及整個,,軟件生存,,周期,,擴展到,軟件工作的范圍,軟件開發(fā)全部過程、活動和任務的結(jié)構(gòu)框架。,,直觀表達軟件開發(fā)

17、全過程,,明確規(guī)定要完成的主要活動、任務和開發(fā)策略,,也稱為：,,軟件,過程,模型,,軟件生存,周,期模型,,軟件工程范型,軟件開發(fā)模型,,,問題求解的一般過程,問題求解的一般過程,,,,,,,實際問題并不能簡單劃為四個階段，各個階段會在問題的不同層次上同時并存,,軟件開發(fā)實際上是一個,“,混沌,”,（,chaos,）過程,問題定義,方案集成,技術開發(fā),現(xiàn)狀,A.,編碼修正模型,Code and Fix,,Code like Hell(,魯莽編碼,),,從一個大致的想法開始工作，然后經(jīng)過非正規(guī)的設計、編碼、調(diào)試和測試方法，最后完成工作,,,可能有可能沒有的規(guī)范,發(fā)布（可能）,編碼修正模型,好處

18、：,,成本可能很低,,只需要很少的專業(yè)知識，任何寫過程序的人都可以,,對于一些非常小的、開發(fā)完后就會很快丟棄的軟件可以采用,,對于規(guī)模稍大的項目，采用這種模型是很危險的,B.,瀑布模型（,Waterfall Model,),所有過程模型的祖宗,,項目從開始到結(jié)束按照一定的順序執(zhí)行,,瀑布模型是文檔驅(qū)動的，各個階段不連續(xù)也不交叉,B.,瀑布模型,,(,Waterfall Model,),可行性研究與計劃,需求分析,設計,編碼,運行維護,測試,,,,,,,,,,定義,,階段,開,,發(fā),,階,,段,維護階段,,適應場合？,,優(yōu)缺點？,瀑布模型的適用場合,有一個,穩(wěn)定產(chǎn)品定義,和很,容易被理解的技術解

19、決方案,時，純瀑布模型特別合適,,對一個定義得很好的版本進行,維護,或?qū)⒁粋€產(chǎn)品,移植平臺,，瀑布模型也特別合適。,,純瀑布模型能夠,降低管理費用,，因為你可以預先完成所有計劃。,,對于那些容易理解但很復雜的項目，采用純瀑布模型比較合適，因為可以,用順序方法處理問題,。,,在,質(zhì)量需求高,于成本需求和進度需求的時候，它尤為出色。,,當開發(fā)隊伍的,技術力量比較弱,或者缺乏經(jīng)驗時，瀑布模型更為適合。,瀑布模型缺點,純瀑布模型在項目開始時，在設計工作完成前和代碼寫出來前，很難充分描述需求。,,瀑布模型最主要問題是,缺乏靈活性,。必須在項目開始前說明全部需求。但這恰恰是非常困難的。,按照傳統(tǒng)瀑布模型開

20、發(fā)軟件的特點,階段間具有順序性和依賴性。,,推遲實現(xiàn)的觀點。,,每個階段必須完成規(guī)定的文檔,;,,每個階段結(jié)束前完成文檔審查,,,及早改正錯誤。,C.,瀑布模型變種：,V,型模型,該方法是對瀑布模型的修正，強調(diào)了驗證活動,可行性研究,用戶需求,系統(tǒng)設計,程序設計,編 碼,程序測試,系統(tǒng)測試,用戶接受,評價,修正,修正,修正,修正,,,,,,,D.,瀑布模型變種：生魚片模型,把階段重疊起來的瀑布模型,,起源于日本硬件開發(fā)模型（富士通,—,施樂）,軟件概念,需求分析,架構(gòu)設計,詳細設計,編碼和調(diào)試,系統(tǒng)測試,生魚片模型的特點和缺點,傳統(tǒng)的瀑布模型強調(diào)階段之間最小,重疊,，而生魚片模型強調(diào)大幅度重

21、疊，即在需求分析完成之前就可以進行架構(gòu)設計和部分詳細設計,,純瀑布模型強調(diào)在任意兩個階段交接時，文檔從一個團隊交給另一個完全隔離的團隊，但是如果一個團隊完成各個階段任務時，可以沒有那么多,文檔,。,,問題：缺點是什么？,,生魚片模型因為階段重疊，因而,里程碑不明確,，很難有效地進行過程跟蹤和控制。,E.,瀑布模型變種：具有子項目的瀑布模型,純瀑布模型的問題：必須完成全部架構(gòu)設計后才能進行詳細設計，但是，整個系統(tǒng)中有些部分可能有些特殊性，可以有自己的步驟，即將這些部分劃分為子項目。,,問題：該模型有何問題？,,這種方法的主要風險是,相關性,無法預料。,F.,瀑布模型變種：能夠降低風險的瀑布模型,

22、純瀑布模型：要求在開始架構(gòu)設計前，必須將用戶的所有需求都搞清楚，但是實際中是很困難的。,,可降低風險的瀑布模型是在頂端，即需求分析和架構(gòu)設計階段引入螺旋以便降低風險。,,螺旋中，先開發(fā)一個用戶界面原型，采用系統(tǒng)情節(jié)串聯(lián)圖版（,system storyboarding,）引導用戶提出需求，記錄用戶與系統(tǒng)的交互操作方式，或者采用其它需求獲取方法。,G.,快速,原,型模型（,Rapid Prototype Model,）,,,,,建造,/,修改,,原型,,,用戶測試,,運行原型,,聽取用,,戶意見,原型范型,原型模型,需求分析,原型開發(fā),最終系統(tǒng)設計,原型評價,最終系統(tǒng)實現(xiàn),用戶,,反饋,,,,,

23、,,,分析定義,,系統(tǒng)需求,生成,,原型,系統(tǒng),,設計,程序,,設計,編碼,測試,運 行,,和維護,原型化,含原型化的,,軟件生存期,,,采用原型模型的軟件生存周期,原型法的分類,原型是項目系統(tǒng)中的一個方面或者多個方面的工作模型。,,拋棄型原型：用于試驗某些概念，試驗完系統(tǒng)將無用處,,進化型原型：原型系統(tǒng)不斷被開發(fā)和被修正，最終它變?yōu)橐粋€真正的系統(tǒng)。,原型法的優(yōu)點,從實踐中學習,(Learning by doing),,改善的溝通,,改善的用戶參與,,使部分已知的需求清晰化,,展示描述的一致性和完整性,,可能可以減少文檔,,減少了維護成本,,特征約束（利用工具構(gòu)造原型可以將某些特性落到實處，而

24、非在紙上寫的那樣容易失誤）,,試驗是否能產(chǎn)生期待的結(jié)果,原型法的缺點,用戶有時誤解了原型的角色，例如他們可能誤解原形應該和真實系統(tǒng)一樣可靠,,缺少項目標準，進化原型法有點像編碼修正,,缺少控制，由于用戶可能不斷提出新要求，因而原型迭代的周期很難控制,,額外的花費：研究結(jié)果表明構(gòu)造一個原型可能需要,10%,額外花費,,運行效率可能會受影響,,原型法要求開發(fā)者與用戶密切接觸，有時這是不可能的。例如外包軟件。,從另外的角度看待原型,從中學到什么？,,學生經(jīng)常會做一些軟件作業(yè)，這些作業(yè)被稱為原型，,,問題：這些原型和軟件系統(tǒng)原型是否相同？,,但是作為一個原型必須：描述他們希望從中學到的東西，規(guī)劃原型評

25、價的方法，報告從原型中真正學到的內(nèi)容。,,在不同的階段，原型具有不同的作用。,,原型起作用的程度,,實物模型（,Mock-ups,）,,仿真交互,,部分模型：水平，垂直（某些特性構(gòu)造詳細原型,）,H.,演化模型,增量模型,(Incremental Model),,,螺旋模型,(Sprial,Model),H.1,增量模型,(,遞增模型,),先完成一個系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加功能,(,系統(tǒng)子集,),,如此遞增下去直至滿足全部系統(tǒng)需求。,,系統(tǒng)的總體設計在初始子集設計階段就應作出設想。,,分析,,設計,,編碼,,測試,,分析,,設計,,編碼,,測試,,分析,,設計,,編碼,,測試,

26、,分析,,設計,,編碼,,測試,增量,1,增量,2,增量,3,增量,n,,增量,1,,交付,客戶,,增量,2,,交付,客戶,,增量,3,,交付,客戶,,增量,n,,交付,客戶,日歷時間,…..,H.1,增量模型,,,,,,,,,,,,風險,,分析,工程,,實施,用戶通信,用戶,,評估,,,,,,,,,,,,,,產(chǎn)品維護項目,產(chǎn)品增強項目,新產(chǎn)品開發(fā)項目,概念開發(fā)項目,,,,,計劃,建造及發(fā)布,H.2,螺旋模型,螺旋模型的優(yōu)缺點,優(yōu)勢：隨著迭代的增加（成本的增加），風險程度隨之降低,,缺陷：比較復雜，需要責任心，專注和管理方面的知識。,H.3,,WIN-WIN,螺旋模型,在螺旋模型中，通過與客戶

27、的通信獲取客戶的需求，實際上，客戶的需求與最終確定的需求是不一致的，客戶與開發(fā)者之間需要進行協(xié)商，最終達到雙贏的局面。,,Boehm,提出的,WIN-WIN,螺旋模型中，客戶與開發(fā)者之間需要,,識別系統(tǒng)或子系統(tǒng)的關鍵,stakeholders,,確定涉及者的,“,win conditions,”,,對這些條件進行協(xié)商獲得互贏條件,WIN-WIN,螺旋模型,WIN-WIN,螺旋模型還引入了三個過程的里程碑，被稱為定位點（,Anchor points,）,,生命周期目標（,life cycle objectives,）,:,定義每個主要活動的目標,,生命周期體系結(jié)構(gòu)（,life cycle arc

28、hitecture,）,:,定義系統(tǒng)和軟件的體系結(jié)構(gòu)目標,,初步操作能力（,initial operational capability,）,:,定義軟件安裝，發(fā)布目標。,I.,并行開發(fā)模型,并行開發(fā)模型（,concurrent development model,）又被稱為并行工程（,concurrent engineering,）（,By Davis and Sitaram,）,,軟件開發(fā)中的所有活動可能,同時并存,，但是都處于不同狀態(tài)中,,并行開發(fā)模型定義了活動從一個狀態(tài)轉(zhuǎn)化為另一個狀態(tài)的事件,,,并行開發(fā)模型,None,Awaiting changes,Under revision,U

29、nder review,Baselined,Done,Under development,Analysis activity,并行開發(fā)模型,并行過程模型經(jīng)常被用于開發(fā),C/S,系統(tǒng)。該系統(tǒng)的活動可以被分為系統(tǒng)維和部件維。,,系統(tǒng)維,:,包含設計，裝配和使用三個活動,,部件維,:,包含設計和實現(xiàn)兩個活動,,并發(fā)性表現(xiàn)在兩個方面：,,系統(tǒng)和部件的活動同時發(fā)生,,各個部件可以并行設計和開發(fā),“,基于版本發(fā)布,”,的特點,V,1.0,功,,能,時間,,,,,,,,,,,,,,,,,,,,,,,,,,,,V,2.0,,,V,1.1,Trade-off Decision,(,折中決定,),,√,,√,

30、,,,,√,,可 靠 性,發(fā)布日期,,功 能,,,最優(yōu),約束范圍,可接受,正確的,Trade-off,,決定,J.,面向?qū)ο竽Ｐ?噴泉模型,(Fountain Model),,可重用部件組裝模型,(,構(gòu)件集成模型,Component Integration Model),,,,,,,,,分析,設計,,,,實現(xiàn),測試,集成,,,,,,,,,,演化,J.1,噴泉模型,噴泉模型特點,,主要用于支持面向?qū)ο箝_發(fā)過程體現(xiàn)了軟件創(chuàng)建所固有的迭代和無間隙的特征,J.2,可重用部件組裝模型,(,構(gòu)件集成模型,),使用重用技術的軟件工程模型,,構(gòu)件,(,components),：,可重用的軟件成份,,可復

31、用性,（,Reusability,）,,集成化軟件開發(fā)環(huán)境,（,ISEE,）,,,,,,,,,,,,用戶,,通信,,,,,,,,,,,,,,計劃,產(chǎn)品開發(fā)及發(fā)布,用戶,,評估,風險,,分析,,標志候,,選構(gòu)件,查找,,構(gòu)件,若存在則,,提取構(gòu)件,若不存在則,,構(gòu)造構(gòu)件,進行下,,一次迭代,將新構(gòu)件,,存入庫中,,,可重用部件組裝模型,基于構(gòu)件的軟件工程,(CBSE),過程模型,,,,構(gòu) 件 開 發(fā),,分析 設計 編程 測試,領域分析,,系統(tǒng),,測試,,,構(gòu)件提交,,領域?qū)＜医?jīng)驗,現(xiàn)有系統(tǒng)資料,領域構(gòu),,件需求,構(gòu)件,/,構(gòu)架庫,領域構(gòu)架,領,,域,,構(gòu),,件,,,系統(tǒng),,開發(fā),系統(tǒng)專用構(gòu)

32、件,應用,,系統(tǒng),構(gòu)件生產(chǎn)線,領域構(gòu)架,領域構(gòu)件,問題域,用戶需求,系統(tǒng)生產(chǎn)線,,系 統(tǒng) 組 裝,,分析 設計 編程,構(gòu)架細化,專,,用,,構(gòu) 件,,開,,發(fā),,分析 設計 編程 測試,,軟件生產(chǎn)線,應用構(gòu)件,,提取車間,構(gòu)件生,,產(chǎn)車間,標準規(guī)范 與 質(zhì)量保證,1,基礎構(gòu)件，,2,功能構(gòu)件,,3,接口構(gòu)件，,4,用戶界面構(gòu)件,,,,,,,,,,,,,,應用,,構(gòu)件庫,,構(gòu)件庫,組裝,,車間,領域,,,1,領域,,,2,,,,,應用,,系統(tǒng),,,,,,,,,,,,,,,...,,,,,,,,,,,,,,,,,,,,,,,1,2,3,4,,,,轉(zhuǎn)換,

33、模型,(,Transformational Model,),,,凈室模型,(,Cleanroom,Model,),K.,形式化方法模型,K.1,轉(zhuǎn)換,模型,形式化,,規(guī)格說明,與需求比,,較后修正,,形式化開發(fā)記錄,變換,n,變換,2,變換,1,測試,系統(tǒng)需求,目標系統(tǒng),形式化規(guī)格語言及其變換技術,基于模型的規(guī)格說明及其變換技術,,基于代數(shù)結(jié)構(gòu)及其變換技術,,基于時序邏輯的規(guī)格說明和驗證技術,,基于可視形式化技術,K.2,凈室,模型,(,形式化的增量開發(fā)模型,),基于思想：,,力求在分析和設計階段就消除錯誤，確保正確，然后在無缺陷或“潔凈”的狀態(tài)下實現(xiàn)軟件的制作。,,三個關鍵技術,,置于統(tǒng)計

34、過程控制之下的增量開發(fā),,基于函數(shù)的規(guī)范、設計、驗證,,統(tǒng)計測試和軟件認證,,凈室,模型,盒結(jié)構(gòu),,規(guī)約,需求,,收集,形式化,,設計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量,#1,盒結(jié)構(gòu),,規(guī)約,需求,,收集,形式化,,設計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量,#2,盒結(jié)構(gòu),,規(guī)約,需求,,收集,形式化,,設計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量,#1,.,,.,,.,.,,.,,.,.,,.,,.,.,,.,,.,L.,階段交付,階段交付持續(xù)地在確定的階段向用戶展示軟件。,,

35、和漸進原型不同，在階段交付的時候，你明確地知道下一步要完成什么工作。階段交付的特點是不會在項目結(jié)束的時候一下交付全部軟件，而是在項目整個開發(fā)過程中持續(xù)不斷地交付階段性成果。,階段交付,軟件概念,需求分析,構(gòu)架設計,階段,1,：詳細設計，編碼，調(diào)試，,……,階段,2,：詳細設計，編碼，調(diào)試，,……,階段交付的優(yōu)缺點,優(yōu)點：項目結(jié)束交付全部成果前，分階段將有用的功能交付給用戶。,,缺點：如果管理層面和技術層面上缺乏仔細規(guī)劃，工作就無法進行。,,使用階段交付的注意點：,,必須確定每一階段的交付是對用戶有用的,,必須確?？紤]了不同產(chǎn)品組成部分的技術依賴關系,M.,面向進度的設計,類似于階段交付，但是面

36、向進度的設計生命周期模型在開始的時候不必知道究竟能達到何目標，但是要確保最后的,期限,。,,該模型的關鍵是要,按優(yōu)先級別劃分系統(tǒng)特性并規(guī)劃開發(fā)階段,，保證前面的階段具有高優(yōu)先級的特性，低特性具有低優(yōu)先級別。,,是否采用這種方法決定于你是否對系統(tǒng)目標具有足夠的信心，如果有信心，則沒必要采用這種方法。,N.,漸進交付,漸進交付是一種跨越了漸進原型和階段交付兩種模型的過程模型。,,基本過程：開發(fā)一個產(chǎn)品的版本，展示給用戶，根據(jù)反饋改善產(chǎn)品。,,如果計劃滿足用戶的絕大部分需求，漸進交付與漸進原型差不多，如果計劃滿足少量的需求，漸進交付就和階段交付差不多。,,漸進原型，強調(diào)的是系統(tǒng)看得見的樣子，再回來堵

37、漏洞，漸進交付中，最初的重點是系統(tǒng)核心和底層系統(tǒng)功能,。,,漸進交付,軟件概念,需求分析,構(gòu)架和內(nèi)核設計,開發(fā)一個版本,并入用戶反饋,交付該版本,開發(fā)一個版本,交付最終版本,,確定漸進交付目標的一種方法,價值成本比,軟件開發(fā)方法,,軟件開發(fā)過程遵循的方法和步驟,,幾種,典型,的開發(fā),方法：,,模塊化方法（,modular method,）,,結(jié)構(gòu)化方法,,面向數(shù)據(jù)結(jié)構(gòu)方法,,面向?qū)ο蠓椒?軟件開發(fā)需要項目管理,軟件開發(fā)是個系統(tǒng)工程,,需要資源的協(xié)調(diào),,軟件開發(fā)過程的選擇與項目的協(xié)調(diào)緊密相關,,項目管理、工具、技術、流程與組織,,主要內(nèi)容,回顧,,軟件項目實施的方法選擇,,軟件開發(fā)過程模型的選擇

38、,,軟件開發(fā)方法,,項目管理,,項目管理基本概念,,實施項目管理的工具與技術,,項目管理的流程,,項目管理的流程特征（產(chǎn)品／項目／軟件項目）,,項目管理組織結(jié)構(gòu),,軟件項目管理的流程,,,?,建立不現(xiàn)實的最終期限,,?,不斷變更的客戶需求,,?,對努力的低估,,?,可預見和不可預見的風險,,?,技術的困難性,,?,項目成員的溝通不暢通,,?,項目管理不利,為什么項目會失敗,?,People,—,,項目成功的最重要因素,,Product,—,,建立的軟件,,Process,—,,框架活動集合和得到工作的軟件工程任務,,Project,—,,實現(xiàn)產(chǎn)品所需要的所有工作,The 4 P’s,軟件梯隊,

39、被解決問題的難易程度,,代碼和功能點形成的結(jié)果程序的規(guī)模,,梯隊的生存周期,,問題被模塊化的程度,,被建立系統(tǒng)所需要的質(zhì)量和可靠性,,發(fā)布日期的嚴格性,,項目的社會化程度（溝通程度）,選擇軟件項目梯隊結(jié)構(gòu)所要考慮的因素,,...,,,建立范圍,—,陳述性描述，約束問題表達,,分解,—,建立功能性分割,問題定義,發(fā)現(xiàn)項目的關鍵,系統(tǒng)為什么被開發(fā),?,,做什么,?,什么時候,?,,誰對某一功能負責,?,,他們組織定位在哪里,?,,從技術和管理上工作怎樣被做,?,,多少資源需要,(e.g.,,人,,,軟件,,,工具,,,數(shù)據(jù)庫,)?,Barry Boehm,形式的風險分析,,經(jīng)驗成本和進度估算,,基

40、于度量的項目管理,,價值跟蹤（,Earned value tracking,）,,質(zhì)量目標下的跟蹤,,人要意識到項目管理,關鍵實踐,什么是項目,項目是什么,,沒有例行的任務,,需要計劃,,特定的目標需要滿足或者特定的產(chǎn)品需要生成,,項目有一個預定義的時間范圍,,工作不僅僅是為自己，也是為他人,,工作中有些特性,,工作分為若干階段,,項目完成需要資源,,項目是大型的或者復雜的,什么是項目管理,項目管理是在項目活動中應用知識，技能，工具和技術來滿足項目需求的過程，它通過初始化，計劃，執(zhí)行，控制和結(jié)束等活動來完成。,,項目生命周期,項目生命周期定義一個項目的開始與結(jié)束。,,項目生命周期定義的階段順序

41、通常包括某些技術轉(zhuǎn)移或,“,握手,”,(hand off),，如從需求到設計，從構(gòu)造到運行，但是在風險允許下，也可以下一階段提前進行，這種重疊的階段被稱為快速跟蹤,(fast tracking),。,,項目生命周期通常定義：,,各個階段需要完成的技術工作；,,每個階段需要涉及的人。,項目生命周期,絕大多數(shù)項目生命周期有一些共同的特點，如成本和人員消耗的變化曲線。,,,,,,,項目生命周期與產(chǎn)品生命周期是不同的。,,項目中的人員,項目影響者,(stakeholders),,項目小組內(nèi)部：,,項目小組外部，但是在同一組織內(nèi)：,,項目小組和組織外部：如客戶,,不同的項目影響者有不同的目標，因而項目領

42、導者需要能夠協(xié)調(diào)這些目標。,Boehm,和,Ross,提出軟件項目管理的,“,W,理論,”,，該理論關注于所有各方都能從項目種獲益因而對項目的成功都有興趣。（,W,代表,Everyone a Winner,）,軟件項目管理定義,軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質(zhì)量順利完成，而對成本、人員、進度、質(zhì)量、風險等進行分析和管理的活動。,軟件項目包含的活動,需求分析,,描述,,設計,,編碼,,校驗,,安裝,,維護,,支持,應用項目管理方法開展軟件開發(fā),項目的可行性分析,,需求開發(fā)與需求管理,,軟件項目工作量估算,,軟件項目計劃與資源分配,,軟件項目監(jiān)控,,風險管理,,軟件質(zhì)量管理

43、與軟件開發(fā)規(guī)范,,軟件項目中的人員管理,,軟件配置管理,,項目可行性分析與評估,,內(nèi)容安排,可行性分析的內(nèi)容,,項目范圍管理,,技術評估,,經(jīng)濟評估,,風險評估,,可行性報告,,項目建議書,,需求建議書,可行性分析,目的,,“,說明該軟件開發(fā)項目的實現(xiàn)在技術上、經(jīng)濟上和社會條件上的可行性；評述為合理地達到開發(fā)目標可能選擇的各種方案,”,。,,GPS,監(jiān)控系統(tǒng)的投資失誤,,做什么？近期目標？,,人員配備，怎樣整合,,需求調(diào)研問題,,開發(fā)費用問題,,風險規(guī)避,,頂新國際集團：在投資新產(chǎn)品時,,1400,萬：全國,28,個城鎮(zhèn)居民消費習慣調(diào)查,,700,萬：委托,28,個城鎮(zhèn)社會科學院進行全國七大區(qū)

44、域總體經(jīng)濟投資環(huán)境的分析,,任務,,了解客戶要求及現(xiàn)實環(huán)境，從技術、經(jīng)濟和社會因素研究并論證軟件項目可行性，編寫可行性報告，制定初步項目開發(fā)計劃,,“,什么都不做,”,永遠是一個可考慮的方案,可行性分析的內(nèi)容,項目范圍,,策略評估,,技術評估,,經(jīng)濟評估,,風險評估,項目范圍管理內(nèi)容,保證項目包括并且僅僅包括需要包括的內(nèi)容。它由以下步驟組成：,,初始化：對項目或階段授權(quán),,范圍計劃：開發(fā)一個作為將來項目決策基礎的書面的范圍聲明,,范圍定義：將項目交付物細分為更小的，更易管理的元件,,范圍校驗：形式化項目范圍的接受條件,,范圍變更控制：控制項目范圍的變更,范圍的含義,“,范圍”包含產(chǎn)品范圍和項目

45、范圍,,產(chǎn)品范圍：產(chǎn)品或服務的特點和功能,,項目范圍：為了生產(chǎn)具有特定特點和功能的產(chǎn)品所需要的工作,軟件范圍,軟件項目計劃的第一項任務就是確定軟件的工作范圍，即軟件的用途及對軟件的要求。因此，應從管理角度和技術角度出發(fā)，確定明確的可理解的軟件項目范圍。,軟件范圍的敘述,明確給出定量的數(shù)據(jù)（例如，同時使用該軟件的用戶數(shù)目，發(fā)送表格的長短，最大允許響應時間等）,,指明約束條件和,/,或限制（例如，產(chǎn)品成本限制了存儲的容量）,,敘述某些質(zhì)量因素（例如，給出的算法是否容易理解、是否使用,Ada,語言等）,軟件范圍的估計,軟件范圍包括功能、性能、限制、接口和可靠性。,,功能：,,軟件功能評價，并進行適當

46、細化,,功能分解，滿足未來成本和進度估算要求,,性能,,包括處理和響應時間的需求。,,約束條件：,,外部硬件、可用存儲或其他現(xiàn)有系統(tǒng)對軟件限制。,,功能、性能和約束必須在一起進行評價。,,當性能限制不同時，為實現(xiàn)同樣的功能，開發(fā)工作量可能相差一個數(shù)量級。,,如果功能保持相同而性能可變，則開發(fā)軟件所需的工作量和成本將有顯著的差異。,價值驅(qū)動的電子商務分析方法,,,,,業(yè)務流程,,模型,,,業(yè)務概念,,模型,策略,規(guī)劃級,結(jié)構(gòu)級,實施級,電子商務技術層,業(yè)務策略的概念結(jié)構(gòu),,,,概念建模,協(xié)商建模,價值驅(qū)動流程建模,,,,,資,源,,價,值,配,置,,伙,伴,網(wǎng),絡,,,,,,,,價,值,鏈,構(gòu),

47、架,,,信,息,策,略,,發(fā),布,渠,道,,客,戶,信,任,,,,,,,,客,戶,關,系,,企,業(yè),能,力,,價,值,建,議,,目,標,客,戶,,,,,,,,,,,,產(chǎn),品,與,服,務,創(chuàng),新,,,R,e,v,e,n,u,e,,M,o,d,e,l,,,,,,,,價,值,結(jié),構(gòu),,收,入,模,型,,收,益,/,損,失,,,,,,,資,產(chǎn),、,財,務,電子商務概念模型,初始化,初始化,(Initiation),,正式授權(quán)一個新項目或者決定一個已有項目繼續(xù)進行下一階段,,項目是由于下面一些原因產(chǎn)生的：,,市場需要（新性能汽車）,,業(yè)務需要（培訓中心新課程設計）,,客戶需要（客戶定制產(chǎn)品）,,技術進步

48、（如計算機技術進步）,,法規(guī)需要（污染處理）,,社會需要（政府水處理系統(tǒng)）,初始化,輸入：,,產(chǎn)品描述,,策略計劃：企業(yè)的戰(zhàn)略計劃,,項目選擇準則（經(jīng)濟回報，市場回報，公共形象）,,歷史信息：以前項目的結(jié)果和性能,,工具和技術,,項目選擇方法,,專家判斷,,輸出：,,項目章程（授權(quán)項目的正式文檔，包括業(yè)務需求，產(chǎn)品描述）,,項目經(jīng)理指派,,約束,,假設,范圍計劃,范圍計劃是將生成產(chǎn)品的項目工作（項目范圍）逐步細化的過程。,,輸入：,,產(chǎn)品描述,,項目章程,,約束,,假設,,工具和技術,,產(chǎn)品分析,,利益成本分析,(Benefit/Cost Analysis),,備選方案（,brainstorm

49、ing or lateral thinking),,專家判斷,范圍計劃,輸出,,范圍聲明（,Scope Statement),，包括,,項目理由：,Project Justification(Business need),,項目產(chǎn)品,:,概述,,項目交付物：,project deliverables,,項目目標,:,判斷項目是否成功的定量準則,,支持細節(jié)（包括假設和約束）,,范圍管理計劃,,范圍定義,范圍定義涉及到將主要的項目交付物細分以：,,提高成本，周期和資源估計的準確性,,定義性能度量和控制的基線,,便于清晰定義責任分配,,范圍定義正確與否將影響項目的節(jié)奏，進度，生產(chǎn)率和項目人員的士氣。

50、,范圍定義,輸入,,范圍聲明,,約束,,假設,,其它計劃輸出,,歷史信息,,工具和技術,,WBS(Work breakdown structure),模板,,分解技術,策略評估中的模塊管理,模塊管理（,Programm,management),,“,模塊是一組協(xié)調(diào)管理的項目，通過將項目組成模塊，將獲得比單個管理項目更大的效益。,”,——,D. C. Ferns,,有效的模塊管理需要有一個模塊目標，項目必須根據(jù)模塊目標來選擇,,在大的組織中，將可能有模塊管理的機構(gòu)，例如模塊主管或者模塊經(jīng)理,,即使沒有專門的組織來管理模塊，項目的選擇也需要根據(jù)組織的整個業(yè)務目標來評價,策略評估的內(nèi)容,目標：提出的

51、系統(tǒng)對組織目標具有怎樣的貢獻？例如它是否能夠增加市場份額？,,IS,計劃：提出的系統(tǒng)如何與,IS,計劃相適應？它將替換或者與那些系統(tǒng)接口？它與將來開發(fā)的系統(tǒng)有何交互關系？,,組織結(jié)構(gòu)：新系統(tǒng)對目前的部門和組織結(jié)構(gòu)有何影響？例如一個新的訂單處理系統(tǒng)是否與目前的銷售與庫存控制的功能相重疊？,,MIS:,系統(tǒng)將在組織的何層次上提供何種信息？它將以何種方式對現(xiàn)存管理信息系統(tǒng)進行補充何提高？,,人員：系統(tǒng)將以何種方式影響人力水平何現(xiàn)存雇員的技術？它對組織整個人員開發(fā)策略有何影響？,,情形：系統(tǒng)將使客戶對組織的態(tài)度有何變化？是否采用一個自動化的系統(tǒng)將與提供友好的服務相沖突？,策略評估中的業(yè)務管理,業(yè)務管理

52、,,選定的項目將成為業(yè)務的一部分，項目將對資源產(chǎn)生競爭,,競爭中對業(yè)務的調(diào)整是必要的,技術評估,技術的成熟程度,,實驗室技術,,經(jīng)過中試的技術,,已經(jīng)工業(yè)化應用的技術,,市場需求,,顯在,,潛在：轉(zhuǎn)化為顯在的條件,,競爭態(tài)勢：,與競爭技術相比，所采用技術的優(yōu)勢及缺陷,,技術轉(zhuǎn)換成本,,支撐體系與條件：原料、銷售網(wǎng)絡、用戶體系、政策,,技術發(fā)展趨勢及所采用技術的發(fā)展前景,技術方案選擇,要考慮的制約條件,,需求制約：現(xiàn)存的需求結(jié)構(gòu)及需求結(jié)構(gòu)可能的變化,,資源制約：資金、人力資源、自然資源、其它要素,,環(huán)境制約：經(jīng)濟技術環(huán)境、社會文化環(huán)境、自然環(huán)境,,選擇原則,,經(jīng)濟性原則：以最小的投入取得最好的效

53、果,,發(fā)展原則：發(fā)展的前景及適應發(fā)展的能力,,兼容性原則：與原有經(jīng)濟、技術、環(huán)境、社會的兼容性,,相關效果原則：相關的經(jīng)濟、技術、環(huán)境、社會效果,,選擇視角,,技術先進性,,技術適用性,經(jīng)濟分析,開發(fā)所需要的成本和系統(tǒng)運行所需要的成本與得到的效益的比較,,識別出項目進行中所需要的所有成本和效益并對其進行聚集,,將成本和效益用單元來表達,,成本分為,,開發(fā)成本,,安裝成本,,運行成本,經(jīng)濟分析,效益,,直接效益,,可見的間接效益,,不可見的效益,經(jīng)濟分析,凈收益（,Net Profit):,項目的凈收益是在項目生命周期內(nèi)總的收入與總的成本的差。,,沒有考慮時間因素,,回收期限（,Payback

54、Period,）：將初始投資收回的期限,,忽略了整個項目的盈利空間,經(jīng)濟分析,投資回報,(Return on investment):,也被稱為回報率,(accounting rate of return)(ARR),,ROI=,（平均年收益,/,總投資）,×,100,,例如項目,1,：,ROI=10,000/100,000*100=10%,,缺點：,,沒有考慮時間因素,,該回報率易與銀行利率混淆,,經(jīng)濟分析,凈現(xiàn)率,(Net Present Value),,考慮了時間因素,,對將來的收益打一個折扣,,“,拿在手里的錢才是真正的錢,”,,如果假定年折扣率為,10,％，那么明年的,100,元等于

55、現(xiàn)在手中的,91,元，后年的,100,元等于現(xiàn)在的,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,名數(shù)據(jù)通訊專家,(,60,小時,/,名,,42,美元,/,小時,),$2,400,,.,1,名數(shù)據(jù)庫管理員,(,30,小時,/,名,,42,美元,/,小時,),$1,260,,.,2,名技術寫作者,(,120,小時,/,名,,25

56、,美元,/,小時,),$6,000,,.,1,名秘書,(,160,小時,/,名,,15,美元,/,小時,),$2,400,,.,2,名在轉(zhuǎn)換期間數(shù)據(jù)輸入人員,$49,500,,(,40,小時,/,名,,12,美元,/,小時,),系統(tǒng)開發(fā)和每年運行費用舉例,培訓：,,三天的開發(fā)人員內(nèi)部培訓課程,$,7,000,,30,個用戶，三天的內(nèi)部培訓課程,$,10,000,,物資：,,復印,$,500,,磁盤、紙張等消耗品,$,650,,系統(tǒng)開發(fā)和每年運行費用舉例,購買硬件、軟件：,,20,臺工作站,Windows,軟件,$,1,000,,20,臺工作站內(nèi)存升級,$,8,000,,網(wǎng)絡軟件,$,17,50

57、0,,20,臺工作站辦公軟件產(chǎn)品,$,20,000,,系統(tǒng)開發(fā)總費用,$161,670,系統(tǒng)開發(fā)和每年運行費用舉例,2.,年運行費用（每年）,,人員：,,維護程序員,/,分析員,(250,小時,/,年,,42,美元,/,小時,) $10,500,,網(wǎng)絡管理員,(300,小時,/,年,,50,美元,/,小時,) $15,000,,購買硬件、軟件升級：,,硬件,$5,000,,軟件,$6,000,,物資和雜項,$3,500,,每年總運行費用,$40,000,可行性研究的步驟,,(1),復查確認系統(tǒng)目標、規(guī)模,,,(2),研究正使用系統(tǒng)工作流程,,,(3),導出新系統(tǒng)高層邏輯模型,,,

58、(4),重新定義問題,,,(5),導出和評價供選擇的方案,,,(6),推薦,可行的方案,,,(7),草擬開發(fā)計劃,,,(8),編寫可行性研究報告,，送審,可行性分析,可行性分析報告的格式,可行性研究報告的編寫提示,,GB 8567-88《,計算機軟件產(chǎn)品開發(fā)文件編制指南,》,1,引言,,,1.1,編寫目的,,,1.2,背景,,,1.3,定義,,,1.4,參考資料,可行性研究報告的編寫提示,2,可行性研究的前提,,,2.1,要求,,,2.2,目標,,,2.3,條件、假定和限制,,,2.4,進行可行性研究的方法,,,2.5,評價尺度,可行性研究報告的編寫提示,3,對現(xiàn)有系統(tǒng)的分析,,,3.1,數(shù)據(jù)

59、流程和處理流程,,,3.2,工作負荷,,,3.3,費用開支,,,3.4,人員,,,3.5,設備,,,3.6,局限性,可行性研究報告的編寫提示,4,所建議的系統(tǒng),,,4.1,對所建議系統(tǒng)的說明,,,4.2,數(shù)據(jù)流程和處理流程,,,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.

60、5,敏感性分析,可行性研究報告的編寫提示,7,社會條件方面的可行性,,,7.1,法律方面的可行性,,,7.2,使用方面的可行性,項目建議書,起源：組織內(nèi)部認識到需要利用信息技術,,改進目前的業(yè)務運行,,改進目前的信息系統(tǒng),,開發(fā)新的產(chǎn)品,,目的：,,使管理層能夠作出項目決策,準備招標書,目的：,,從客戶的角度全面地、詳細的論述，為了達成確定的需求應需要作何準備,,一份招標書應當是全面的，能提供足夠詳細的信息，以使承約商或項目團隊能針對顧客的需要相應地準備一份最優(yōu)的招標書,招標書,招標書中需要提供工作表述,,招標書中必須包括客戶要求，此要求中規(guī)定了規(guī)格和特征,,招標書應當說明客戶期望承約商或項目

61、團隊提供什么樣的交付物,,招標書中應當列舉客戶供應條款,,招標書中可以表述出客戶對需要的確認,,招標書中可以提到客戶想要用的合同類型,招標書,表述出客戶想用的付款方式,,表述出項目完成所需的進度計劃,,提供有關承約商申請書的格式和內(nèi)容安排,,支持客戶希望潛在承約商提交申請書的最后期限,,可能包括評價標準,,可能會指出客戶所擁有的可用于此項目的資金量。,案例分析,寧波市第五次全國人口普查辦公室的寧波市人口地理信息系統(tǒng),,地理空間分析、人口統(tǒng)計與分析一體化,,寧波人口普查、日常管理、統(tǒng)計與分析的數(shù)字化、可視化,,人口信息存儲、管理與分析，建立規(guī)范化的空間地理信息與人口信息統(tǒng)一管理、分析、統(tǒng)計、發(fā)布

62、、錄入、更新與維護,,對空間數(shù)據(jù)和人口數(shù)據(jù)的快速采集、建庫、維護、查詢、管理、顯示、輸出、統(tǒng)計分析、共享與發(fā)布功能,案例分析,性能要求,,滿足寧波全部市縣人口的數(shù)據(jù)存儲,,不同縣區(qū)都可以調(diào)用數(shù)據(jù)，操作數(shù)據(jù),,保證調(diào)查高峰操作響應的人機交互,,保證數(shù)據(jù)統(tǒng)計的響應時間,,案例分析,限制要求,,Windows,平臺客戶端,,服務器選用,Intel,服務器,,存儲,RAID,，保證存儲安全,,與,DOMINO,辦公系統(tǒng)可以實現(xiàn)接口，可以抽取數(shù)據(jù)報表,,需求開發(fā)與需求管理,,主要內(nèi)容,從一個故事看軟件開發(fā)的實際問題,,需求管理的困難性,,管理需求的目的,,軟件需求特性,,需求工程,,如何獲取需求,,需求

63、規(guī)格說明,,需求管理工具,,軟件開發(fā)面臨的實際問題,軟件開發(fā)面臨的實際問題,軟件開發(fā)面臨的實際問題,為什么？？？,需求？？？,什么是需求,需求為用戶解決問題或達到目標所需的條件或權(quán)能,,系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范和其它正式規(guī)定文檔所需具有的條件或權(quán)能,,一種反映上述條件或權(quán)能的文檔說明,舉例,系統(tǒng)必須提供基于,PPPoE,協(xié)議的用戶接入模式,,產(chǎn)品應當提供機架式安裝，并提供兩個千兆以太網(wǎng)端口,,系統(tǒng)使用的用戶是信息中心和網(wǎng)絡管理員,,系統(tǒng)在運行時必須提供自動數(shù)據(jù)備份功能,簡要的解釋,需求來源于用戶的一些,“,需要,”,，這些,“,需要,”,被分析、確認后形成完整文檔，該文檔詳細地說明

64、了產(chǎn)品,“,必須或應當,”,做什么。,,如果只有一些零碎的對話、資料或郵件，你就以為自己已經(jīng)掌握了需求，那是自欺欺人。,需求管理的困難性,需求不總是顯而易見的，而且它可來自各個方面。,,需求并不總是能容易用文字明白無誤地表達。,,存在不同種類的需求，其詳細程度各不相同。,,如果不加以控制，需求的數(shù)量將難以管理。,,需求之間相互關聯(lián)，而且需求也和軟件工程流程中的其他可交付工件有關。,,需求有唯一的特征或特征值。例如，它們的重要性和容易滿足的程度都各不相同。,,需求涉及眾多相關方面，這意味著需求要由功能交叉的各組人員管理。,,需求會變更。,為什么要管理需求,為什么要管理需求？,,避免失敗就是一個很

65、充分的理由。,,提高項目的成功率,,需求管理帶來其他好處,,Standish Group,的,CHAOS,報告進一步證實了與成功項目關系最大的因素是良好的需求管理。,什么是軟件需求,從軟件開發(fā)過程看軟件需求開發(fā),從軟件發(fā)展周期看軟件開發(fā)過程,時期,,,年代,,,階段,,,涉及,,,注重,,,主要使用語言,,,標準,,,模型,,,初期,,,50-60,,,程序設計,,,點,,,編程,,技巧,,,ALGOL,,FORTRAN,,COBOL,,BASIC,,,,,,,,,中期,,,70-80,,,軟件開發(fā),,,線,,,結(jié)構(gòu)化,,模塊化,,,PASCAL,,,?,GB8566,,軟件開發(fā),,規(guī)范,,,

66、?,瀑布,,?,原型,,,現(xiàn)代,,,90-,,,軟件過程,,,面,,,過程,,能力,,,C,C++,,JAVA,,VB,、,VC,,,?,ISO/IEC,,12207,,軟件生存期過程,,?,ISO9000,,,?,螺旋,,?,CMM,,,,計算機系統(tǒng),,人員,硬件,軟件,數(shù)據(jù),傳輸,,機構(gòu),執(zhí)行,,機構(gòu),（劇作家、導演）,（舞臺,劇本,演員,道具）,,軟件開發(fā)全過程,,,,活動－任務,,⑴,系統(tǒng)需求分析,,⑵,系統(tǒng)結(jié)構(gòu)設計,,,⑶,軟件需求分析,,建立軟件需求,,評價軟件需求,,聯(lián)合評審,,,⑷,軟件結(jié)構(gòu)設計,,,⑸,軟件詳細設計,,,⑹,軟件編碼和測試,,,⑺,軟件集成,,,⑻,軟件鑒定測試,,⑼,系統(tǒng)集成,,⑽,系統(tǒng)鑒定測試,,⑾,軟件安裝,,⑿,軟件驗收支持,,軟件開發(fā)過程,,⑴,,定義（,IEEE-STD-610,）,,用戶為解決某個問題、或為實現(xiàn)某一目標，,,要求軟,件,必須滿足的條件或能力。,,,⑵,軟件需求的三個層次,,業(yè)務需求,,,用戶需求,,,功能需求和非功能需求,,軟件需求的層次性,軟件,,系統(tǒng)需求,(1),系統(tǒng)需求,分配,軟件工程組,硬件,,系統(tǒng)需求,(2),,