三級信息管理技術(shù)分章節(jié)考試要點:軟件工程(軟件管理之進度安排)

字號:

進度安排
    軟件開發(fā)項目的進度安排可以有兩種考慮方式。第一種,系統(tǒng)最終交付使用的日期已經(jīng)確定,軟件開發(fā)機構(gòu)必須在合同規(guī)定的時間內(nèi)安排;第二種,只確定了大致的年限,最后交付使用的日期由軟件開發(fā)機構(gòu)根據(jù)具體情況確定。后一種考慮能夠?qū)浖_發(fā)任務(wù)進行細(xì)致的分析;能夠地利用資源,合理地分配工作量,但實際工作中常常遇到第一種情況,問題是軟件管理人員如何在規(guī)定的期限內(nèi)分配人力和安排進度。進度安排的好壞往往影響整個項目的按期完成和用戶的使用,如不能按期完成,用戶就會不滿,而且需向用戶賠償損失。如作為商品,將會失去市場競爭力。
    進度安排的精確性有時比成本估算更重要。在商品生產(chǎn)的社會中,某種商品的損失往往還可以通過其他商品或分期償還來承擔(dān)。而進度拖延的損失是無法彌補的。下面就軟件開發(fā)項目進度安排中的幾個問題進行討論。
    1.軟件工作的特殊性
    制定軟件進度與其他工程沒有很大的區(qū)別,因此使用一般的通用技術(shù)和工具即可。但重點要強調(diào)的是軟件產(chǎn)品是邏輯產(chǎn)品,這與其他工程不同。因此當(dāng)幾個人共同完成某項任務(wù)時,人與人之間就有一個思想交流問題,稱之為通信關(guān)系。通信是要付出代價的,不只是要花時間,同時由于通信中的疏忽常常會使錯誤增加。如一個組有4個軟件工程師,兩兩之間進行通信聯(lián)系,通信路徑有6條;對6個軟件工程師,則通信路徑增加至14條。因此所付的代價就必然會增加,所以工作組的人員不宜太多,一般3—5人為好,目前國外一般采用主程序員組的制度。另一點要強調(diào)的是軟件工作切忌中間臨時加人,必須在安排進度時就考慮周到。
    2.各階段工作量的分配
    估算出總的工作量以后,就需要一個可以進行各階段工作量分配的模型。某一階段工作量所占的百分比必須根據(jù)經(jīng)驗數(shù)據(jù)確定。這里要再一次強調(diào),在開發(fā)過程中保存的記錄將增加經(jīng)驗數(shù)據(jù)庫存,而且將改善今后估算的準(zhǔn)確性。
    R.S.Pressman提出一種稱作40-20-40的工作量分配規(guī)則,即前期工作(計劃、需求分析、概要設(shè)計和詳細(xì)設(shè)計階段)和后期工作(測試階段)各占40%,編碼階段占20%。
    應(yīng)該強調(diào)要重市馨期和后期工作。前期工作容易被忽視,主要原因是:管理人員認(rèn)為不開始編碼工作就算沒有進行,他們不了解前期工作的重要性;技術(shù)人員往往也急于編碼,認(rèn)為寫出代碼任務(wù)就算完成了。后期工作也容易被忽視,認(rèn)為編碼出來就完事了,對測試工作要占這么大的工作量沒有思想準(zhǔn)備。所以要制定好進度計劃,就要研究軟件工作的規(guī)律,前期基礎(chǔ)工作沒做好,將會給后期工作帶來很大困難,往往使工程進度一拖再拖,難以堅持,有的不得不中途夭折。
    3.制定開發(fā)進度
    需要涉及的下一個未知量是開發(fā)進度。進度安排是軟件計劃工作中一項最困難的任務(wù),計劃人員要把可用資源與項目工作量協(xié)調(diào)好;要考慮各項任務(wù)之間的相互依賴關(guān)系,并且盡可能地平行進行;預(yù)見可能出現(xiàn)問題和項目的“細(xì)脖子”,并提出處理意見;以及規(guī)定進度,評審和應(yīng)交付的文檔。
    假設(shè)用作變量的開發(fā)時間TD接線性變化,而且已經(jīng)得到了總的開發(fā)工作量估算值ED,要求在規(guī)定的時間TD內(nèi)完成,在項目中有參加工作的人員平均值M,即M=ED/TD,這將是一個非常有用的數(shù)據(jù)。遺憾的是在上述算式中,項目的工作量和開發(fā)時間不能作為獨立的變量。Brooks定律描述了這種現(xiàn)象的最極端情況:為誤期的軟件項目增加人員將會使其進度更慢。估算開發(fā)時間可以使用類似于工作量的估算法。一些研究人員指出,開發(fā)時間與開發(fā)工作量之間十分精確地滿足下面關(guān)系 TD=a(ED) b
    其中a和b為經(jīng)驗常數(shù),若ED以人-月為單位,則TD的單位為月,a和b的大小分別為2到4和0.25到0.4。
    算式TD=a(ED) b 給出了名義開發(fā)時間。某些其他模型能夠表示出名義開發(fā)時間發(fā)生變化后,開發(fā)工作量將如何變化。如COCOMO模型,最多只能壓縮到名義開發(fā)時間的75%。所增加的這一部分工作人員的工作量都消耗在保持項目人員通信開銷中了。
    4.軟件開發(fā)組織
    有多少個軟件開發(fā)機構(gòu),幾乎也就有多少人員的組織機構(gòu)。不管這些組織機構(gòu)是好或壞,一般是不可能輕易改變的。盡管組織機構(gòu)的改變不屬于軟件計劃人員的職責(zé)范圍內(nèi)的事。不過,在一個新的軟件項目中直接涉及人員的組織問題卻是可以,也應(yīng)該在軟件計劃階段加以認(rèn)真考慮的。
    對于一個需要n個人工作k年的軟件項目,如何使用人員資源,可能有以下幾種選擇:
    (1)把m項不同功能的軟件分配給n個人去完成,他們之間無需多少合作,主要協(xié)調(diào)的任務(wù)由一位軟件主管人員來負(fù)責(zé)。這樣,軟件主管可能同時需要管理多個不同項目;
    (2)把m項不同功能的軟件分配給n個人去完成(m≤n),這樣可能就要建立一些非正式的小組,并指定小組負(fù)責(zé)人,而小組之間的協(xié)調(diào)工作則由軟件主管負(fù)責(zé);
    (3)n個人被組成k個小組,每個小組分配一個或多個功能,并有具體組織,協(xié)調(diào)工作由小組和軟件主管共同進行。
    雖然對上述每一種方案都可能說出贊成或反對的理由。然而,有越來越多的證據(jù)表明,第三種方案,即正式的小組是的。
    正式的小組的方案來源于“主程序員小組”的概念。它是由Harlan Mills首先提出,并由Baker進一步闡述的。小組的核心由一位高級工程師(主程序員)、2至5位技術(shù)人員和一位后備工程師組成。主程序員負(fù)責(zé)小組的所有技術(shù)活動的計劃、協(xié)調(diào)和評審工作;技術(shù)人員負(fù)責(zé)項目的具體分析和開發(fā);后備工程師則支持主程序員工作,必要時能代替主程序員工作,以便使項目能繼續(xù)進行,而使損失最小。
    主程序員小組有一名或多名專家(如數(shù)據(jù)庫設(shè)計或通信方面專家)、數(shù)名輔助人員(如秘書和打字員)和一名資料員參加工作。資料員同時為多個小組工作,具體完成下列工作:
    (1)保存和管理所有軟件配置(包括各種文檔、源程序清單、數(shù)據(jù)和各種磁介質(zhì)資料);
    (2)協(xié)助收集和整理軟件生產(chǎn)率數(shù)據(jù);
    (3)對可修改的模塊分類及編寫索引;
    (4)協(xié)助小組進行調(diào)查、評價和準(zhǔn)備文檔等。主程序員小組的主要目標(biāo)是發(fā)揮集體力量。因引,小組要培養(yǎng)從“全局”觀點出發(fā)進行程序設(shè)計,把“我的”程序變?yōu)椤拔覀兊摹背绦?幫助消除軟件的個人屬性,小組可以鼓勵更加徹底的評審,并在共同的工作中增加學(xué)習(xí),從而改善軟件質(zhì)量。
    在本章中,我們曾討論過人們在工作中有一個需要交流的問題。當(dāng)采用主程序員小組這種形式時,必須會增加交換意見所需的工作量,這似乎不利于提高軟件開發(fā)的生產(chǎn)率。然而,不管怎樣組織,在軟件整個開發(fā)過程的總工作量的相當(dāng)一部分總是要花費在交換意見方面(如計劃、分析和評審等)。雖然,小組的形式增加了內(nèi)部交換意見的工作量,但是這是有組織的評審,必將減少在設(shè)計和編碼中引入的錯誤。結(jié)果是測試工作量減少了,從而使小組有更高的生產(chǎn)率。當(dāng)然,小組中技術(shù)人員的數(shù)量不宜過多,一般建議2~5人為好。5.軟件計劃
    軟件開發(fā)過程的每一步都要生產(chǎn)出可交付的文檔,這些文檔可以用來進行評審和作為下一步工作的基礎(chǔ)。
    軟件計劃是一份比較簡短精煉的文件。它應(yīng)該發(fā)給有關(guān)部門,其中包括:
    (1)把該項目所確定的工作范圍和所需的資源告訴軟件主管部門、技術(shù)人員和該項目的需求者;
    (2)有關(guān)該項目的成本估算和進度安排,應(yīng)告訴軟件主管部門,以便他們進行評審;
    (3)還要發(fā)給與該項目開發(fā)有關(guān)的所有人員,給他們提供有關(guān)該項目開發(fā)的總辦法。軟件計劃應(yīng)包含以下內(nèi)容:
    1.工作范圍
    1.1項目目標(biāo) 1.2主要功能 1.3其他特性 1.4開發(fā)情況
    2.資源
    2.1人員資源 2.2硬件資源 2.3軟件資源2.4可利用的窗口
    3.成本估算
    4.進度安排六、軟件開發(fā)工具與環(huán)境
    目前,軟件開發(fā)工具種類繁多,按功能可將軟件開發(fā)工具分為8類:
    (1)業(yè)務(wù)系統(tǒng)規(guī)劃工具 通過將企業(yè)的策略性信息需求模型化,這類工具提供一個可導(dǎo)出特定信息系統(tǒng)的“原模型”,這樣可使業(yè)務(wù)信息運行于企業(yè)的各個部門。
    (2)項目管理工具 借助這類工具,項目管理者可以有效地估算軟件項目所需的工作量、成本和研制周期等,可以定義一個功能分解結(jié)構(gòu)WBS,并制定可行的項目開發(fā)計劃;基于需求跟蹤項目的開發(fā)情況;可采集度量數(shù)據(jù),以此評價軟件開發(fā)效率和產(chǎn)品質(zhì)量。由此可見,這類工具又可詳細(xì)分為項目計劃工具、需求跟蹤工具及度量和管理工具等。
    (3)支持工具 這類工具用于支持軟件工程過程,具體包括文檔編制工具、系統(tǒng)軟件工具、質(zhì)量保證工具、數(shù)據(jù)庫管理工具和軟件配置管理工具等。
    (4)分析和設(shè)計工具 這類工具是用于建立待開發(fā)系統(tǒng)的模型,并評價模型的質(zhì)量,通過對模型進行一致性和有效性檢查,保證分析與設(shè)計的完整性。它除包括支持某種開發(fā)方法的工具外,還包括基于規(guī)則體系的分析與設(shè)計機,這種分析與設(shè)計機是90年代的期望產(chǎn)品,它可使工具適用于各種分析和設(shè)計方法。
    (5)編程工具 這類工具包括用于支持大多數(shù)傳統(tǒng)編程語言的編譯器、編輯器和調(diào)試器等,從工具輸出來看,4GL也屬于這一類。
    (6)測試與分析工具 常用的測試與分析工具包括靜態(tài)分析工具和動態(tài)測試工具。
    (7)原型工具 作為除瀑布式開發(fā)模式以外的另一主要開發(fā)模式是原型開發(fā)模式,因其運用的靈活性和用戶需求反應(yīng)的快捷性愈來愈受到重視,特別是隨著軟件構(gòu)件重用研究的深入,更增強了這種開發(fā)模式的實用價值。但原型的構(gòu)造離不開經(jīng)驗信息,所以支持原型開發(fā)模式的原型工具的發(fā)展日趨專用化,諸如用于用戶界面設(shè)計的原型工具可利用圖形包快速構(gòu)造出應(yīng)用系統(tǒng)的界面,供用戶評價,以確定最終產(chǎn)品的界面形式。
    (8)維護工具 用于協(xié)助維護活動的完成,包括當(dāng)運行發(fā)現(xiàn)問題時,定位到相應(yīng)的軟件開發(fā)基線;軟件配置不完備時由源程序到分析與設(shè)計模型的逆轉(zhuǎn)換工具等。軟件開發(fā)環(huán)境的分類方法很多。
    這里介紹三種:
    (1)按解決的問題分類;
    (2)按現(xiàn)有的軟件開發(fā)環(huán)境的演變趨向分類;
    (3)按集成化程度分類。
    1.按解決的問題分類
    軟件開發(fā)中遇到的問題主要出現(xiàn)在三個級別上:程序設(shè)計級、系統(tǒng)合成級和項目管理級。軟件開發(fā)環(huán)境也應(yīng)該在這三個級別上給予支持。
    (1)程序設(shè)計環(huán)境
    程序設(shè)計環(huán)境主要解決一個相對他人獨立工作的程序員如何把規(guī)范說明轉(zhuǎn)變成可工作的程序的問題,即屬于局部編程(programming-in-the-small)的范疇。這個過程包括兩個重要部分:方法和工具。其中方法(例如“結(jié)構(gòu)化編碼技術(shù)”)可能是更重要的部分,因為對于設(shè)計和編碼很差的程序而言,再好的工具也不會是靈丹妙藥。但作為軟件開發(fā)環(huán)境而言,我們將把重點放在工具上。
    (2)系統(tǒng)合成環(huán)境
    系統(tǒng)合成環(huán)境主要考慮把很多子系統(tǒng)集成為一個大系統(tǒng)的問題,即屬于全局編程(proˉgramming-in-the-large)的范疇(已有文章把更大規(guī)模的系統(tǒng)編程稱為programming-in-the-garantuan)。所有的大型軟件系統(tǒng)都有兩個基本特點:第一,它們是由一些較小的、較易理解的子系統(tǒng)組成的;第二,它們是不斷改變的。這兩個特點使軟件在開發(fā)過程中產(chǎn)生大量的分支。因此,需要有一個系統(tǒng)合成環(huán)境來輔助人們控制子系統(tǒng)及其向大系統(tǒng)的集成。沒有適當(dāng)?shù)闹С?,就不能在軟件中?zhǔn)確地進行修改(改正錯誤或者改進功能),因為人的智力將難于招架如此之大的規(guī)模和隨之產(chǎn)生的高度復(fù)雜性。系統(tǒng)合成的兩個基本問題是接口控制和版本控制。接口控制要考慮對模塊相連和資源共享問題的描述和制約。版本控制則要考慮對系統(tǒng)的各個版本的生成和管理。
    (3)項目管理環(huán)境
    大型軟件系統(tǒng)的開發(fā)和維護必然會有多個人員在一段時間內(nèi)協(xié)同工作。對人與人之間的交流和合作缺乏管理就會造成比程序設(shè)計更多、更嚴(yán)重的問題。另外,項目生存期越長,參與的人越多,就有越多的管理問題產(chǎn)生。項目管理環(huán)境的責(zé)任就是解決由于軟件產(chǎn)品的規(guī)模大、生存期長、人們的交往多而造成的問題,即屬于多方編程(programming-in-the-many)的范疇。項目管理環(huán)境必須對付的三個問題是誤解、缺乏信息和利益沖突。項目管理環(huán)境可由兩部分組成:記錄和維護系統(tǒng)開發(fā)的狀態(tài)信息以及集成和分發(fā)文檔。
    2.按現(xiàn)有的軟件開發(fā)環(huán)境的演變趨向分類
    按現(xiàn)有軟件開發(fā)環(huán)境的演變趨向,軟件開發(fā)環(huán)境可分成四類,它們對軟件開發(fā)環(huán)境的發(fā)展(在工具、用戶接口和體系結(jié)構(gòu)方面)有著重要的影響。
    (1)以語言為中心的環(huán)境(language-centered environments)
    它們是圍繞一種語言而構(gòu)成的,可以提供一套適合于這種語言的工具集。這類環(huán)境是高度交互式的,通常對系統(tǒng)合成的支持是有限的,也不支持項目管理。換句話說,它基本上屬于程序設(shè)計環(huán)境。
    在現(xiàn)有的環(huán)境中,60年代末期出現(xiàn)的Lisp環(huán)境、70年代中期的以Mesa/Cedar語言為中心的Cedar環(huán)境、以Smalltalk語言為中心的Smalltalk環(huán)境及80年代早期形成的以Ada語言為中心的Rational環(huán)境等屬于以語言為中心的環(huán)境。
    (2)面向結(jié)構(gòu)的環(huán)境(structure-oriented environments)
    這種環(huán)境所采用的技術(shù)允許用戶直接操作結(jié)構(gòu)。初始的動機是給用戶一個借于語言的結(jié)構(gòu)來輸入程序的交互式工具,即語法制導(dǎo)編輯器(syntax-directed editor)。這種能力后來擴展到提供一個單用戶程序設(shè)計環(huán)境,它還支持交互式語義分析、程序執(zhí)行和調(diào)試。編輯器是這種環(huán)境的中心組成部分。最重要的是這種形式化地描述一種語言的語法和靜態(tài)語義的能力,由此可以生成一個結(jié)構(gòu)編輯器的實例(instance)。也就是說,這種與語言無關(guān)的技術(shù)引出了環(huán)境生成器的概念,在支持局部編程、全局編程、歷史記載和存取控制表方面繼續(xù)所作的努力,使術(shù)語“語法制導(dǎo)”逐漸被“面向結(jié)構(gòu)”所取代了。
    在現(xiàn)有的環(huán)境中,80年代初期出現(xiàn)的Aloe編輯器就屬于面向結(jié)構(gòu)的環(huán)境,它是的Gendalf項目中的一個組成部分,它只允許用戶在結(jié)構(gòu)化元素上進行操作,也就是說,用戶只看到抽象語法樹,而看不到熟悉的源語言文本,不過它不會允許用戶構(gòu)造語法不正確的程序;稍后出現(xiàn)的Cornell程序合成器也屬于面向結(jié)構(gòu)的環(huán)境,它采用文本表示方式,以克服用戶在輸入和修改語言表示方面的困難。另外一些系統(tǒng)采用混合方式,用戶可自由選擇在哪種表示方式(文本或結(jié)構(gòu))上進行操作,系統(tǒng)內(nèi)部保留兩種形式,并始終使它們處于一致狀態(tài)。
    (3)工具箱環(huán)境(toolkit environments)
    工具箱環(huán)境由一套工具組成,用于支持軟件開發(fā)和編碼階段。它從操作系統(tǒng)開始,加入一些諸如編輯程序、編譯程序、匯編程序、連接程序和調(diào)試程序等編碼工具。此外,也有一些支持大型軟件開發(fā)任務(wù)的工具,如版本控制和配置管理。它采用簡單的數(shù)據(jù)模型來提高工具的可擴充性和可移植性。這樣的環(huán)境允許高度的剪裁,但對工具集的使用幾乎不提供任何環(huán)境定義、管理或控制的技術(shù)。當(dāng)代工具箱環(huán)境是使用相當(dāng)成熟的技術(shù)。商業(yè)化的環(huán)境設(shè)計者正在把高級接口放在普通操作系統(tǒng)的用戶命令接口之上,即擴充操作系統(tǒng)。
    商業(yè)化工具箱系統(tǒng)的例子是:UNIX程序員工作臺UNIX/PWB和DEC VMS/VAX set等,它們都是在80年代中期推出的。對全局編程提供的工具分別是源代碼控制系統(tǒng)(Source Code Control System-SCCS)和代碼管理系統(tǒng)(Code Management System—CMS),它們都是起版本控制的作用,并用獨立于具體的程序設(shè)計語言的。稍后開發(fā)的的工具箱環(huán)境的例子是:可移植的公用工具環(huán)境(Portable Common Tool Environrment—PCTE)和公用APSE接口集(Comˉmon APSE Interface Set—CAIS)。其中APSE是Ada程序設(shè)計支持環(huán)境的英文縮寫。
    (4)基于方法的環(huán)境(method-based environments)
    這種環(huán)境支持一種特定的軟件開發(fā)方法。這些方法可分為兩類:①支持軟件開發(fā)周期特定階段的;②管理開發(fā)過程的。前者包括規(guī)格說明、設(shè)計、確認(rèn)、驗證和重用。方法不同,形式化的程序有很大不同,從非形式化到準(zhǔn)形式化到形式化。后者又可細(xì)分為兩個部分:支持產(chǎn)品管理與支持開發(fā)和維護產(chǎn)品的過程管理。產(chǎn)品管理包括版本、配置和投放管理。開發(fā)過程的管理包括項目計劃和控制、任務(wù)管理、通信管理及加工過程建模。
    這類環(huán)境的例子有:Anna———一種用于Ada的規(guī)格說明語言;VDM———用于軟件開發(fā)的形式化方法,也是一種規(guī)格說明語言;SREM———分布式計算的設(shè)計系統(tǒng)SL/PSA———問題描述語言/問題描述分析程序,這是為信息處理系統(tǒng)的結(jié)構(gòu)化文檔編制和分析設(shè)計的。支持管理開發(fā)過程的典型環(huán)境有ISTAR———一個集成式項目管理系統(tǒng)MA———一個知識型軟件環(huán)境中的項目管理部分。
    3.按集成化程序分類
    環(huán)境的形成與發(fā)展主要體現(xiàn)在各工具的集成化的程度上,當(dāng)前國外軟件工程界把軟件開發(fā)環(huán)境分成三代,各代之間的主要區(qū)別及特征如下:
    (1)第一代
    ①建立在操作系統(tǒng)之上(如VMS和UNIX等);
    ②工具間通過一個公用框架集成;
    ③只有工具使用的文件修改即可加入,由調(diào)用過程來使用這些工具;
    ④工具所使用的文件結(jié)構(gòu)不變,而且成為環(huán)境文件庫的一部分;
    ⑤從人機界面來看,這類環(huán)境主要采用單色、低分辨率的文字終端,圖形能力較差,多數(shù)使用菜單技術(shù)。
    例如,70年代中期的UNIX環(huán)境以文件庫為集成核心,管道命令實施控制功能,SHELL語言表達的程序顯示用戶工作界面。
    (2)第二代
    ①具有真正的數(shù)據(jù)庫(如INGRES),而不是文件庫,有時稱為信息庫,多數(shù)采用E-R模式或E-R-A模式;
    ②工具集成在更低的層次上,工具和文件都作為實體保存在數(shù)據(jù)庫中,而不是簡單地看作一種獨立的成分;
    ③現(xiàn)有的工具不能隨意放入,要作適當(dāng)修改或定制;
    ④人機界面采用高分辨率、點陣式工作站,具有多窗口、圖形符號等功能,采用鼠標(biāo)裝置。例如,Ada程序設(shè)計支持環(huán)境(APSE),以數(shù)據(jù)庫為集成核心,有可移植性的工作界面。
    (3)第三代
    ①建立在知識庫系統(tǒng)上;
    ②順序調(diào)用獨立工具的概念完全被集成化的工具集所替化,用戶不再需要在任務(wù)之間來回切換不同的工具;
    ③采用形式化方法,軟件重用等新技術(shù);
    ④由多個工具控制的多窗口技術(shù)被單個工具操縱的多窗口技術(shù)所替代;
    顯然,第三代軟件開發(fā)環(huán)境中工具間的集成度,利用這些工具,人們逐漸從繁重的手工開發(fā)軟件的活動中解放出來,從而實現(xiàn)軟件開發(fā)和維護的自動化,提高軟件開發(fā)和維護的質(zhì)量和生產(chǎn)率,縮短軟件開發(fā)周期并降低成本。為集中研究并解決這樣一系列的問題,80年代提出了CASE思想,目前的研究重點集中于CASE的集成化方面。