《軟件工程案例分析》由會員分享，可在線閱讀，更多相關(guān)《軟件工程案例分析（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ā)生了巨大的變化,一次性的制造成本,,介質(zhì)成本

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

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

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

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

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

7、或者復(fù)雜的,,項目管理是什么,,項目管理是在項目活動中應(yīng)用知識，技能，工具和技術(shù)來,滿足項目需求,的,過程,，它通過初始化，計劃，執(zhí)行，控制和結(jié)束等,活動,來完成。,,軟件項目與,軟件項目管理,軟件項目的特征,,不可見,,復(fù)雜性（以每一單位貨幣來看）,,靈活性：軟件去適應(yīng)人或組織而不是相反,,一致性,,軟件項目管理,,為了使軟件項目能夠按照預(yù)定的成本、進度、質(zhì)量順利完成，而對成本、人員、進度、質(zhì)量、風險等進行分析和管理的活動。,,軟件項目的活動,需求分析,,描述,,設(shè)計,,編碼,,校驗,,安裝,,維護,,支持,,軟件項目分類,按軟件類別,,信息系統(tǒng)：與組織接口,,嵌入式系統(tǒng)：接口是機器,,操作

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

9、：如客戶,,不同的項目影響者有不同的目標，因而項目領(lǐng)導(dǎo)者需要能夠協(xié)調(diào)這些目標。Boehm和Ross提出軟件項目管理的,“W理論”,，該理論關(guān)注于所有各方都能從項目種獲益因而對項目的成功都有興趣。（W代表Everyone a Winner）,,軟件開發(fā)面臨的挑戰(zhàn),處理最終日期（deadlines）(85%),,處理資源約束（83％）,,與任務(wù)小組有效的溝通（80％）,,從小組成員處得到承諾（74％）,,建立可測量的milestone（90％）,,處理變化（60％）,,得到團隊公認的項目計劃（57％）,,從管理層得到承諾（45％）,,處理沖突（42％）管理銷售商和子項目承包商（38％）,,項目經(jīng)理

10、面臨的挑戰(zhàn),估計和計劃,,缺少質(zhì)量標準和度量,,缺少組織決策的指南,,缺少使進度可視化的技術(shù),,角色定義,,不正確的成功準則,,缺少標準,,項目成員面臨的挑戰(zhàn),工作的不正確的描述,,IT的管理失誤,,缺少應(yīng)用領(lǐng)域的知識,,缺少及時的文檔,,前續(xù)任務(wù)沒有及時完成——包括設(shè)備沒及時提供,,用戶與技術(shù)員之間缺乏交流,,缺少質(zhì)量控制,,軟件環(huán)境的改變,,Deadline壓力,,軟件項目常見錯誤,選自《快速軟件開發(fā)》,,產(chǎn)品相關(guān)的錯誤,,需求鍍金：項目具有比實際需求多得多的性能,,功能蔓延：項目平均會有25%的需求變更（Jones 1994）,,開發(fā)人員的鍍金：開發(fā)人員著迷于新技術(shù),,又推又拉的交易：經(jīng)

11、理在批準項目進度順延時又加入了新的功能,,研究導(dǎo)向的開發(fā),,軟件項目常見錯誤（續(xù)）,過程中的錯誤,,缺乏計劃,,過于樂觀的計劃,,在壓力下放棄計劃,,缺乏足夠的風險管理,,承包人導(dǎo)致的失敗,,在模糊的項目前期浪費時間,,前期活動不合要求,過程中的錯誤,,設(shè)計低劣,,缺少質(zhì)量保證措施,,缺少管理控制,,太早和過于頻繁的集成,,項目估算時遺漏必要的任務(wù),,追趕計劃,,魯莽編碼,,軟件項目常見錯誤（續(xù)）,技術(shù)相關(guān)的錯誤,,銀彈綜合癥: 過于相信以前沒有采用過的技術(shù)的宣傳,,過高估計了新技術(shù)或方法帶來的節(jié)省量,,項目中間切換工具,,缺少自動的源代碼控制手段,,,軟件項目常見錯誤（續(xù)）,人員相關(guān)的錯誤,

12、,挫傷積極性,,人員素質(zhì)低,,對有問題的員工失控,,英雄主義,,項目后期加入人員：“火上加油”,,辦公環(huán)境差,,開發(fā)人員與客戶之間發(fā)生摩擦,,不現(xiàn)實的預(yù)期,,軟件項目常見錯誤（續(xù)）,缺乏有效的高層對項目的支持,,缺乏各種角色的齊心協(xié)力,,缺乏用戶介入,,政治高于物質(zhì),,充滿想像：“項目組沒人真正相信他們能夠按給定的計劃進度完成項目，但他們認為如果每個人能夠努力工作，并且不出現(xiàn)問題，他們可能會很幸運地按時完成任務(wù)。,,軟件項目常見的錯誤,試分析以下故事中的項目所存在的錯誤：,,,一天，一位年青人被選來“寫”一個用在自動化制造設(shè)備上的程序。選擇他的理由很簡單：他是技術(shù)小組中唯一參加過編程培訓的人。

13、他懂得匯編語言和Fortran語言，但是他不知道軟件工程，更不知道軟件計劃和跟蹤方面的知識。,,軟件開發(fā)過程模型選擇,,主要內(nèi)容,項目實施的方法選擇問題,,識別項目中的高風險,,軟件開發(fā)過程模型的選擇,,可選擇的模型,,軟件開發(fā)項目過程的選擇,,軟件開發(fā)方法,,,項目實施的方法選擇,技術(shù)選擇,,技術(shù)選擇將影響：,,開發(fā)人員的訓練需要,,人員招聘,,開發(fā)環(huán)境——硬件和軟件,,系統(tǒng)維護安排,,方法選擇,,方法選擇將影響：,,開發(fā)人員組合,,實施的進度安排,,開發(fā)策略選擇,,項目實施的方法選擇,步驟：,,分析目標驅(qū)動還是產(chǎn)品驅(qū)動,,分析項目其他特征,,面向數(shù)據(jù)還是面向控制,,通用還是專用,,是否需要

14、專用工具支持的專門技術(shù),,是否有特殊的安全性要求,,對軟硬件有何要求,,識別項目中的高風險,,產(chǎn)品不確定性,：,系統(tǒng)需求理解,的準確性。用戶在開始時有可能對系統(tǒng)應(yīng)該什么樣都無法確定。在某些環(huán)境中，精確而有效的需求描述可能迅速變得過時。,,過程不確定性,：在項目開始時需要,選擇方法或過程模型,，或者一種新的工具，任何對原先采用的開發(fā)方法的變化都將引入不確定性,,資源不確定性,：項目進行中,資源的數(shù)量,可能發(fā)生變化,,軟件開發(fā)過程模型的選擇,開發(fā)一個軟件需要選擇,開發(fā)策略,（包括過程，方法和工具）以及,通用階段,，這些策略和階段被稱為,過程模型,,“過程”：相關(guān)聯(lián)的活動,,過程模型的選擇基于項目和

15、應(yīng)用的特性，使用的工具和方法，所需要的控制方法和交付物。,,軟件生存周期,(Software Life Cycle),,軟件產(chǎn)品或軟件系統(tǒng)從設(shè)計、投入使用到被淘汰的全過程,,軟件生存期的階段劃分,,可行性研究與計劃,,需求分析,,總體設(shè)計,,詳細設(shè)計,,實現(xiàn),,集成測試,,確認測試,,使用和維護,軟件生存周期,《計算機軟件開發(fā)規(guī)范》,上游,下游,,新的國際標準定義的軟件生存過程（,1995 ISO/IEC 12207,）,軟件生存期過程,支持過程,組織過程,主要過程,獲,,取,,過,,程,供,,應(yīng),,過,,程,開,,發(fā),,過,,程,運,,行,,過,,程,維,,護,,過,,程,文,,檔,,

16、編,,制,,過,,程,配,,置,,管,,理,,過,,程,質(zhì),,量,,保,,證,,過,,程,驗,,證,,過,,程,確,,認,,過,,程,聯(lián),,合,,評,,審,,過,,程,審,,核,,過,,程,問,,題,,解,,決,,過,,程,管,,理,,過,,程,基,,礎(chǔ),,設(shè),,施,,過,,程,改,,進,,過,,程,培,,訓,,過,,程,,,只考慮,,編寫程序,,涉及整個,,軟件生存,,周期,擴展到,軟件工作的范圍,,軟件開發(fā)全部過程、活動和任務(wù)的,結(jié)構(gòu)框架,。,,直觀表達軟件開發(fā)全過程,,明確規(guī)定要完成的主要,活動、任務(wù)和開發(fā)策略,,也稱為：,,軟件過程模型,,軟件生存周期模型,,軟件工程范型,軟件開發(fā)模型

17、,,問題求解的一般過程,問題求解的一般過程,,,,,,,實際問題并不能簡單劃為四個階段，各個階段會在問題的不同層次上同時并存,,軟件開發(fā)實際上是一個“混沌”（chaos）過程,問題定義,方案集成,技術(shù)開發(fā),現(xiàn)狀,,A.編碼修正模型,Code and Fix,,Code like Hell(魯莽編碼),,從一個大致的想法開始工作，然后經(jīng)過非正規(guī)的設(shè)計、編碼、調(diào)試和測試方法，最后完成工作,可能有可能沒有的規(guī)范,發(fā)布（可能）,,編碼修正模型,好處：,,成本可能很低,,只需要很少的專業(yè)知識，任何寫過程序的人都可以,,對于一些非常小的、開發(fā)完后就會很快丟棄的軟件可以采用,,對于規(guī)模稍大的項目，采用這種模

18、型是很危險的,,B.瀑布模型（Waterfall Model,),所有過程模型的祖宗,,項目從開始到結(jié)束按照一定的順序執(zhí)行,,瀑布模型是,文檔驅(qū)動,的，各個階段不連續(xù)也不交叉,,B.,瀑布模型,,(,Waterfall Model,),可行性研究與計劃,需求分析,設(shè)計,編碼,運行維護,測試,定義,,階段,開,,發(fā),,階,,段,維護階段,適應(yīng)場合？,,優(yōu)缺點？,,瀑布模型的適用場合,有一個,穩(wěn)定產(chǎn)品定義,和很,容易被理解的技術(shù)解決方案,時，純瀑布模型特別合適,,對一個定義得很好的版本進行,維護,或?qū)⒁粋€產(chǎn)品,移植平臺,，瀑布模型也特別合適。,,純瀑布模型能夠,降低管理費用,，因為你可以預(yù)先完成所

19、有計劃。,,對于那些容易理解但很復(fù)雜的項目，采用純瀑布模型比較合適，因為可以,用順序方法處理問題,。,,在,質(zhì)量需求高,于成本需求和進度需求的時候，它尤為出色。,,當開發(fā)隊伍的,技術(shù)力量比較弱,或者缺乏經(jīng)驗時，瀑布模型更為適合。,,瀑布模型缺點,純瀑布模型在項目開始時，在設(shè)計工作完成前和代碼寫出來前，,很難充分描述需求,。,,瀑布模型最主要問題是,缺乏靈活性,。必須在項目開始前說明全部需求。但這恰恰是非常困難的。,,按照傳統(tǒng)瀑布模型開發(fā)軟件的特點,階段間具有順序性和依賴性。,,推遲實現(xiàn)的觀點。,,每個階段必須完成規(guī)定的文檔;,,每個階段結(jié)束前完成文檔審查,及早改正錯誤。,,C.瀑布模型變種：V

20、型模型,該方法是對瀑布模型的修正，強調(diào)了驗證活動,可行性研究,用戶需求,系統(tǒng)設(shè)計,程序設(shè)計,編 碼,程序測試,系統(tǒng)測試,用戶接受,評價,修正,,修正,,修正,,修正,,,D. 瀑布模型變種：生魚片模型,把階段重疊起來的瀑布模型,,起源于日本硬件開發(fā)模型（富士通—施樂）,軟件概念,需求分析,架構(gòu)設(shè)計,詳細設(shè)計,編碼和調(diào)試,系統(tǒng)測試,,生魚片模型的特點和缺點,傳統(tǒng)的瀑布模型,強調(diào),階段之間,最小,重疊,，而生魚片模型,強調(diào)大幅度重疊,，即在需求分析完成之前就可以進行架構(gòu)設(shè)計和部分詳細設(shè)計,,純瀑布模型強調(diào)在任意兩個階段交接時，,文檔,從一個團隊交給另一個,完全隔離,的團隊，但是如果一個團隊完成各

21、個階段任務(wù)時，可以沒有那么多,文檔,。,,問題：缺點是什么？,,生魚片模型因為階段重疊，因而,里程碑不明確,，很難有效地進行過程跟蹤和控制。,,E. 瀑布模型變種：具有子項目的瀑布模型,純瀑布模型的問題：必須完成全部架構(gòu)設(shè)計后才能進行詳細設(shè)計，但是，整個系統(tǒng)中有些部分可能有些特殊性，可以有自己的步驟，即將這些部分劃分為子項目。,,問題：該模型有何問題？,,這種方法的主要風險是,相關(guān)性,無法預(yù)料。,,F. 瀑布模型變種：能夠降低風險的瀑布模型,純瀑布模型：要求在開始,架構(gòu)設(shè)計前,，必須,將用戶的所有需求都搞清楚,，但是實際中是很困難的。,,可降低風險的瀑布模型是在頂端，即,需求分析和架構(gòu)設(shè)計階段

22、引入螺旋,以便降低風險。,,螺旋中，,先開發(fā)一個用戶界面原型,，采用系統(tǒng)情節(jié)串聯(lián)圖版（system storyboarding）引導(dǎo)用戶提出需求，記錄用戶與系統(tǒng)的交互操作方式，或者采用其它需求獲取方法。,,G.快速原型模型（,Rapid Prototype Model,）,,建造/修改,,原型,用戶測試,,運行原型,聽取用,,戶意見,原型范型,,原型模型,需求分析,原型開發(fā),最終系統(tǒng)設(shè)計,原型評價,最終系統(tǒng)實現(xiàn),用戶,,反饋,,分析定義,,系統(tǒng)需求,生成,,原型,系統(tǒng),,設(shè)計,程序,,設(shè)計,編碼,測試,運 行,,和維護,原型化,含原型化的,,軟件生存期,采用原型模型的軟件生存周期,,原型法的

23、分類,原型是項目系統(tǒng)中的一個方面或者多個方面的工作模型。,,拋棄型原型,：用于試驗?zāi)承└拍?，試驗完系統(tǒng)將無用處,,進化型原型,：原型系統(tǒng)不斷被開發(fā)和被修正，最終它變?yōu)橐粋€真正的系統(tǒng)。,,原型法的優(yōu)點,從實踐中學習(Learning by doing),,改善的溝通,,改善的用戶參與,,使部分已知的需求清晰化,,展示描述的一致性和完整性,,可能可以減少文檔,,減少了維護成本,,特征約束（利用工具構(gòu)造原型可以將某些特性落到實處，而非在紙上寫的那樣容易失誤）,,試驗是否能產(chǎn)生期待的結(jié)果,,原型法的缺點,用戶有時誤解了原型的角色，例如他們可能誤解原形應(yīng)該和真實系統(tǒng)一樣可靠,,缺少項目標準，進化原型法有

24、點像編碼修正,,缺少控制，由于用戶可能不斷提出新要求，因而原型迭代的周期很難控制,,額外的花費：研究結(jié)果表明構(gòu)造一個原型可能需要10%額外花費,,運行效率可能會受影響,,原型法要求開發(fā)者與用戶密切接觸，有時這是不可能的。例如外包軟件。,,從另外的角度看待原型,從中學到什么？,,學生經(jīng)常會做一些軟件作業(yè)，這些作業(yè)被稱為原型，,,問題：這些原型和軟件系統(tǒng)原型是否相同？,,但是作為一個原型必須：描述他們希望從中學到的東西，規(guī)劃原型評價的方法，報告從原型中真正學到的內(nèi)容。,,在不同的階段，原型具有不同的作用。,,原型起作用的程度,,實物模型（Mock-ups）,,仿真交互,,部分模型：水平，垂直（某些

25、特性構(gòu)造詳細原型,）,,H.演化模型,增量模型(Incremental Model),,,螺旋模型(Sprial Model),,H.1 增量模型(遞增模型),先完成一個系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加功能 (系統(tǒng)子集),如此遞增下去直至滿足全部系統(tǒng)需求。,,系統(tǒng)的總體設(shè)計在初始子集設(shè)計階段就應(yīng)作出設(shè)想。,,分析,設(shè)計,編碼,測試,分析,設(shè)計,編碼,測試,分析,設(shè)計,編碼,測試,分析,設(shè)計,編碼,測試,增量1,增量2,增量3,增量n,增量1,,交付客戶,增量2,,交付客戶,增量3,,交付客戶,增量n,,交付客戶,日歷時間,…..,H.1 增量模型,,風險,,分析,工程,,實施,用戶通

26、信,用戶,,評估,產(chǎn)品維護項目,產(chǎn)品增強項目,新產(chǎn)品開發(fā)項目,概念開發(fā)項目,計劃,建造及發(fā)布,H.2 螺旋模型,,螺旋模型的優(yōu)缺點,優(yōu)勢：隨著迭代的增加（成本的增加），風險程度隨之降低,,缺陷：比較復(fù)雜，需要責任心，專注和管理方面的知識。,,H.3,,WIN-WIN螺旋模型,在螺旋模型中，通過與客戶的通信獲取客戶的需求，實際上，客戶的需求與最終確定的需求是不一致的，客戶與開發(fā)者之間需要進行協(xié)商，最終達到雙贏的局面。,,Boehm提出的WIN-WIN螺旋模型中，客戶與開發(fā)者之間需要,,識別系統(tǒng)或子系統(tǒng)的關(guān)鍵stakeholders,,確定涉及者的“win conditions”,,對這些條件進行

27、協(xié)商獲得互贏條件,,WIN-WIN螺旋模型,WIN-WIN螺旋模型還引入了三個過程的里程碑，被稱為定位點（Anchor points）,,生命周期目標（life cycle objectives）:定義每個主要活動的目標,,生命周期體系結(jié)構(gòu)（life cycle architecture）:定義系統(tǒng)和軟件的體系結(jié)構(gòu)目標,,初步操作能力（initial operational capability）:定義軟件安裝，發(fā)布目標。,,I. 并行開發(fā)模型,并行開發(fā)模型（concurrent development model）又被稱為并行工程（concurrent engineering）（By Dav

28、is and Sitaram）,,軟件開發(fā)中的所有活動可能,同時并存,，但是都處于不同狀態(tài)中,,并行開發(fā)模型定義了活動從一個狀態(tài)轉(zhuǎn)化為另一個狀態(tài)的事件,,并行開發(fā)模型,None,Awaiting changes,Under revision,Under review,Baselined,Done,Under development,Analysis activity,,并行開發(fā)模型,并行過程模型經(jīng)常被用于開發(fā)C/S系統(tǒng)。該系統(tǒng)的活動可以被分為系統(tǒng)維和部件維。,,系統(tǒng)維:包含設(shè)計，裝配和使用三個活動,,部件維:包含設(shè)計和實現(xiàn)兩個活動,,并發(fā)性表現(xiàn)在兩個方面：,,系統(tǒng)和部件的活動同時發(fā)生,,各個部

29、件可以并行設(shè)計和開發(fā),,“基于版本發(fā)布”的特點,V,1.0,功,,能,時間,,,,V,2.0,V,1.1,,Trade-off Decision,(,折中決定,),,√,,√,,,,,√,,可 靠 性,發(fā)布日期,,功 能,,最優(yōu),約束范圍,可接受,正確的,Trade-off,決定,,J. 面向?qū)ο竽Ｐ?噴泉模型(Fountain Model),,可重用部件組裝模型 (構(gòu)件集成模型 Component Integration Model),,分析,設(shè)計,,實現(xiàn),測試,集成,演化,J.1 噴泉模型,,噴泉模型特點,主要用于支持面向?qū)ο箝_發(fā)過程體現(xiàn)了軟件創(chuàng)建所固有的迭代和無間隙的特征,,

30、J.2 可重用部件組裝模型,(構(gòu)件集成模型),使用重用技術(shù)的軟件工程模型,,構(gòu)件,(,components),：,可重用的軟件成份,,可復(fù)用性,（,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ā),,分析 設(shè)計 編程 測試,領(lǐng)域分析,系統(tǒng),,測試,構(gòu)件提交,領(lǐng)域?qū)＜医?jīng)驗,現(xiàn)有系統(tǒng)資料,領(lǐng)域構(gòu),,件需求,構(gòu)件/

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

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

33、,統(tǒng)計測試和軟件認證,,凈室模型,盒結(jié)構(gòu),,規(guī)約,需求,,收集,形式化,,設(shè)計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量 #1,盒結(jié)構(gòu),,規(guī)約,需求,,收集,形式化,,設(shè)計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量 #2,盒結(jié)構(gòu),,規(guī)約,需求,,收集,形式化,,設(shè)計,正確性,,驗證,代碼,,檢查,測試計劃,統(tǒng)計性,,使用測,,試,驗證,增量 #1,.,,.,,.,.,,.,,.,.,,.,,.,.,,.,,.,,L. 階段交付,階段交付持續(xù)地在確定的階段向用戶展示軟件。,,和漸進原型不同，在階段交付的時候，你

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

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

36、層系統(tǒng)功能,。,,漸進交付,軟件概念,需求分析,構(gòu)架和內(nèi)核設(shè)計,開發(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)緊密相關(guān),,,項目管理、工具、技術(shù)、流程與組織,,,主要內(nèi)容,回顧,,軟件項目實施的方法選擇,,軟件開發(fā)過程模型的選擇,,軟件開發(fā)方法,,項目管理,,項

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

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

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

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

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

42、行性分析與評估,,,內(nèi)容安排,可行性分析的內(nèi)容,,項目范圍管理,,技術(shù)評估,,經(jīng)濟評估,,風險評估,,可行性報告,,項目建議書,,需求建議書,,可行性分析,目的,,“說明該軟件開發(fā)項目的實現(xiàn)在技術(shù)上、經(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ū)域總體經(jīng)濟投資環(huán)境的分析,,任務(wù),,了解客戶要求及現(xiàn)實環(huán)境，從技術(shù)、經(jīng)濟和社會

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

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

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

46、,業(yè),能,力,價,值,建,議,目,標,客,戶,產(chǎn),品,與,服,務(wù),創(chuàng),新,R,e,v,e,n,u,e,,M,o,d,e,l,價,值,結(jié),構(gòu),收,入,模,型,收,益,/,損,失,資,產(chǎn),、,財,務(wù),電子商務(wù)概念模型,,初始化,初始化(Initiation),,正式授權(quán)一個新項目或者決定一個已有項目繼續(xù)進行下一階段,,項目是由于下面一些原因產(chǎn)生的：,,市場需要（新性能汽車）,,業(yè)務(wù)需要（培訓中心新課程設(shè)計）,,客戶需要（客戶定制產(chǎn)品）,,技術(shù)進步（如計算機技術(shù)進步）,,法規(guī)需要（污染處理）,,社會需要（政府水處理系統(tǒng)）,,初始化,輸入：,,產(chǎn)品描述,,策略計劃：企業(yè)的戰(zhàn)略計劃,,項目選擇準則（經(jīng)濟

47、回報，市場回報，公共形象）,,歷史信息：以前項目的結(jié)果和性能,,工具和技術(shù),,項目選擇方法,,專家判斷,,輸出：,,項目章程（授權(quán)項目的正式文檔，包括業(yè)務(wù)需求，產(chǎn)品描述）,,項目經(jīng)理指派,,約束,,假設(shè),,范圍計劃,范圍計劃是將生成產(chǎn)品的項目工作（項目范圍）,逐步細化,的過程。,,輸入：,,產(chǎn)品描述,,項目章程,,約束,,假設(shè),,工具和技術(shù),,產(chǎn)品分析,,利益成本分析(Benefit/Cost Analysis),,備選方案（brainstorming or lateral thinking),,專家判斷,,范圍計劃,輸出,,范圍聲明（Scope Statement)，包括,,項目理由：Pro

48、ject Justification(Business need),,項目產(chǎn)品:概述,,項目交付物：project deliverables,,項目目標: 判斷項目是否成功的定量準則,,支持細節(jié)（包括假設(shè)和約束）,,范圍管理計劃,,,范圍定義,范圍定義涉及到將主要的項目交付物細分以：,,提高成本，周期和資源估計的準確性,,定義性能度量和控制的基線,,便于清晰定義責任分配,,范圍定義正確與否將影響項目的節(jié)奏，進度，生產(chǎn)率和項目人員的士氣。,,范圍定義,輸入,,范圍聲明,,約束,,假設(shè),,其它計劃輸出,,歷史信息,,工具和技術(shù),,WBS(Work breakdown structure)模板,,分

49、解技術(shù),,策略評估中的模塊管理,模塊管理（Programm management),,“模塊是一組協(xié)調(diào)管理的項目，通過將項目組成模塊，將獲得比單個管理項目更大的效益?！薄狣. C. Ferns,,有效的模塊管理需要有一個模塊目標，項目必須根據(jù)模塊目標來選擇,,在大的組織中，將可能有模塊管理的機構(gòu)，例如模塊主管或者模塊經(jīng)理,,即使沒有專門的組織來管理模塊，項目的選擇也需要根據(jù)組織的整個業(yè)務(wù)目標來評價,,策略評估的內(nèi)容,目標：提出的系統(tǒng)對組織目標具有怎樣的貢獻？例如它是否能夠增加市場份額？,,IS計劃：提出的系統(tǒng)如何與IS計劃相適應(yīng)？它將替換或者與那些系統(tǒng)接口？它與將來開發(fā)的系統(tǒng)有何交互關(guān)系？,

50、,組織結(jié)構(gòu)：新系統(tǒng)對目前的部門和組織結(jié)構(gòu)有何影響？例如一個新的訂單處理系統(tǒng)是否與目前的銷售與庫存控制的功能相重疊？,,MIS:系統(tǒng)將在組織的何層次上提供何種信息？它將以何種方式對現(xiàn)存管理信息系統(tǒng)進行補充何提高？,,人員：系統(tǒng)將以何種方式影響人力水平何現(xiàn)存雇員的技術(shù)？它對組織整個人員開發(fā)策略有何影響？,,情形：系統(tǒng)將使客戶對組織的態(tài)度有何變化？是否采用一個自動化的系統(tǒng)將與提供友好的服務(wù)相沖突？,,策略評估中的業(yè)務(wù)管理,業(yè)務(wù)管理,,選定的項目將成為業(yè)務(wù)的一部分，項目將對資源產(chǎn)生競爭,,競爭中對業(yè)務(wù)的調(diào)整是必要的,,技術(shù)評估,技術(shù)的成熟程度,,實驗室技術(shù),,經(jīng)過中試的技術(shù),,已經(jīng)工業(yè)化應(yīng)用的技術(shù),,

51、市場需求,,顯在,,潛在：轉(zhuǎn)化為顯在的條件,,競爭態(tài)勢：,與競爭技術(shù)相比，所采用技術(shù)的優(yōu)勢及缺陷,,技術(shù)轉(zhuǎn)換成本,,支撐體系與條件：原料、銷售網(wǎng)絡(luò)、用戶體系、政策,,技術(shù)發(fā)展趨勢及所采用技術(shù)的發(fā)展前景,,技術(shù)方案選擇,要考慮的制約條件,,需求制約：現(xiàn)存的需求結(jié)構(gòu)及需求結(jié)構(gòu)可能的變化,,資源制約：資金、人力資源、自然資源、其它要素,,環(huán)境制約：經(jīng)濟技術(shù)環(huán)境、社會文化環(huán)境、自然環(huán)境,,選擇原則,,經(jīng)濟性原則：以最小的投入取得最好的效果,,發(fā)展原則：發(fā)展的前景及適應(yīng)發(fā)展的能力,,兼容性原則：與原有經(jīng)濟、技術(shù)、環(huán)境、社會的兼容性,,相關(guān)效果原則：相關(guān)的經(jīng)濟、技術(shù)、環(huán)境、社會效果,,選擇視角,,技術(shù)先進

52、性,,技術(shù)適用性,,經(jīng)濟分析,開發(fā)所需要的成本和系統(tǒng)運行所需要的成本與得到的效益的比較,,識別出項目進行中所需要的所有成本和效益并對其進行聚集,,將成本和效益用單元來表達,,成本分為,,開發(fā)成本,,安裝成本,,運行成本,,經(jīng)濟分析,效益,,直接效益,,可見的間接效益,,不可見的效益,,經(jīng)濟分析,凈收益（Net Profit):項目的凈收益是在項目生命周期內(nèi)總的收入與總的成本的差。,,沒有考慮時間因素,,回收期限（Payback Period）：將初始投資收回的期限,,忽略了整個項目的盈利空間,,經(jīng)濟分析,投資回報(Return on investment):也被稱為回報率(accounting

53、 rate of return)(ARR),,ROI=（平均年收益/總投資）×100,,例如項目1：ROI=10,000/100,000*100=10%,,缺點：,,沒有考慮時間因素,,該回報率易與銀行利率混淆,,,經(jīng)濟分析,凈現(xiàn)率(Net Present Value),,考慮了時間因素,,對將來的收益打一個折扣,,“拿在手里的錢才是真正的錢”,,如果假定年折扣率為10％，那么明年的100元等于現(xiàn)在手中的91元，后年的100元等于現(xiàn)在的83元,,目前值＝t年的值/(1+r),t,,系統(tǒng)開發(fā)和每年運行費用舉例,1.系統(tǒng)開發(fā)費用（一次）,,人員：,,.,2名系統(tǒng)分析員(,450小時/名,45美元/

54、小時,),$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名技術(shù)寫作者(,120小時/名,25美元/小時,),$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個用戶，三天

55、的內(nèi)部培訓課程 $,10,000,,物資：,,復(fù)印 $,500,,磁盤、紙張等消耗品 $,650,,,系統(tǒng)開發(fā)和每年運行費用舉例,購買硬件、軟件：,,20,臺工作站,Windows,軟件,,,$,1,000,,20,臺工作站內(nèi)存升級,$,8,000,,網(wǎng)絡(luò)軟件,$,17,500,,20,臺工作站辦公軟件產(chǎn)品,$,20,000,,系統(tǒng)開發(fā)總費用,$161,670,,系統(tǒng)開發(fā)和每年運行費用舉例,2.年運行費用（每年）,,人員：,,維護程序員/分析員(250小時/年,42美元/小時) $10,5

56、00,,網(wǎng)絡(luò)管理員(300小時/年,50美元/小時) $15,000,,購買硬件、軟件升級：,,硬件 $5,000,,軟件 $6,000,,物資和雜項 $3,500,,每年總運行費用 $40,000,,可行性研究的步驟,,(1)復(fù)查確認系統(tǒng)目標、規(guī)模,,(2)研究正使用系統(tǒng)工作流程,,(3)導(dǎo)出新系統(tǒng)高層邏輯

57、模型,,(4)重新定義問題,,(5)導(dǎo)出和評價供選擇的方案,,(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ù)流程和處理流程,,3.2

58、 工作負荷,,3.3 費用開支,,3.4 人員,,3.5 設(shè)備,,3.6 局限性,,可行性研究報告的編寫提示,4 所建議的系統(tǒng),,4.1 對所建議系統(tǒng)的說明,,4.2 數(shù)據(jù)流程和處理流程,,4.3 改進之處,,4.4 影響,,4.5 局限性,,4.6 技術(shù)條件方面的可行性,,可行性研究報告的編寫提示,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 社會條件方面

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

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

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

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

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

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

65、0-,,軟件過程,,面,,過程,,能力,,C,C++,,JAVA,,VB、VC,,?,ISO/IEC,,12207,,軟件生存期過程,,?,ISO9000,,?,螺旋,,?,CMM,,,計算機系統(tǒng),,人員,硬件,軟件,數(shù)據(jù),傳輸,,機構(gòu),執(zhí)行,,機構(gòu),（劇作家、導(dǎo)演）,（舞臺,劇本,演員,道具）,軟件開發(fā)全過程,,,,,活動－任務(wù),,⑴系統(tǒng)需求分析,,⑵系統(tǒng)結(jié)構(gòu)設(shè)計,,⑶軟件需求分析,,建立軟件需求,,評價軟件需求,,聯(lián)合評審,,⑷軟件結(jié)構(gòu)設(shè)計,,⑸軟件詳細設(shè)計,,⑹軟件編碼和測試,,⑺軟件集成,,⑻軟件鑒定測試,,⑼系統(tǒng)集成,,⑽系統(tǒng)鑒定測試,,⑾軟件安裝,,⑿軟件驗收支持,,軟件開發(fā)過程,

66、,⑴,,定義（IEEE-STD-610）,,用戶為解決某個問題、或為實現(xiàn)某一目標，,,要求軟,件必須滿足的條件或能力。,,⑵ 軟件需求的三個層次,,業(yè)務(wù)需求,,,用戶需求,,,功能需求和非功能需求,,軟件需求的層次性,,軟件,,系統(tǒng)需求(1),系統(tǒng)需求,分配,軟件工程組,硬件,,系統(tǒng)需求(2),,其它成分,,系統(tǒng)需求(n),,軟件需求,客戶,最終用戶,系統(tǒng)工程組,系統(tǒng)需求分配,,業(yè)務(wù)需求,業(yè)務(wù)說明,使用實例,用戶需求,功能需求,約束條件,非功能需求,軟 件 需 求 規(guī) 格 說 明,軟件需求的層次,,需求的層次性,,業(yè)務(wù)需求,項目視圖與范圍文檔,用戶需求,質(zhì)量屬性,系統(tǒng)需求,功能需求,約束條件,其它非功能需求,Use Case文檔,軟件需求規(guī)格說明,,非功能需求,,過程需求：交付需求，實現(xiàn)需求，遵循的標準,,性能需求：速度，容量，可靠性,,,外部需求：互操作性，倫理性，,,機密性，安全性，,,使用要求,,非功能,軟件需求,,系 統(tǒng) 需 求,,ACCS應(yīng)能使汽車保持在預(yù)期車速的,?,2KM,?,H范圍內(nèi)行駛,分配給硬件的需求,,硬件應(yīng)能使車速在規(guī)定的精確度,?,1.5KM,?,H范