1、1-1開發(fā)過程1-2軟體產品 1-3軟體工程規(guī)範 l軟體開發(fā)(Software Development)是達到資訊應用的必要手段，軟體工程(Software Engineering)強調軟體開發(fā)的方法論(Methodology)Pres01，Somm00，林97，鄭93，趙95，趙03。要開發(fā)一個軟體，除了要充分掌控被開發(fā)的軟體產品(Software Product)外，開發(fā)過程(Development Process)也非常重要。l1-1開發(fā)過程l開發(fā)過程，一般而言可大略包括下面最具代表性的五個步驟：l(A)專案規(guī)劃步驟(Project Planning Step)、l(B)需求與規(guī)格步驟(

2、Requirement and Specification Step)、l(C)設計與實作步驟(Design and Implementation Step)、(lD)證實與驗認步驟(Verification and Validation Step)、l(E)產品演進步驟(Product Evolution Step)，如圖1-1所示。l圖1-1開發(fā)過程的五個步驟l(A) 專案規(guī)劃步驟將確定要開發(fā)軟體的總目標。這些總目標包括：界定專案範圍；決定開發(fā)過程模式；選擇軟體開發(fā)技術；估計可應用的資源；成本估算；風險管理；專案排程與追蹤；決定品質管理；選擇軟體工程的工具；擬定合約與採購；決定如何進行專案

3、結束後檢討。l(B) 需求與規(guī)格步驟是系統(tǒng)分析(System Analysis)出使用者到底需要什麼，因此又常稱之為問題空間(Problem Space)。在做需求與規(guī)格時，我們只問這個軟體是什麼(What)，而不問要怎麼樣做出這個軟體。l(C) 設計與實作步驟是屬於解答空間(Solution Space)。換言之，系統(tǒng)設計(System Design)與軟體實作(Software Implementation)是開發(fā)者設法找出一些解決方案來達成使用者的需求。和需求與規(guī)格恰巧相反，在做設計與實作時，主要是考慮要如何(How)製作出此軟體來，而不去定義這個軟體是什麼。l(D) 開發(fā)過程第四個步驟

4、稱做證實與驗認。證實用的是證明(Proving)的技術，驗認用的是測試(Testing)的技術。軟體產品設計與實作完成後，需要經(jīng)過證實與驗認才能確定產品符合當初定下的需求與規(guī)格。l(E) 開發(fā)過程第五個，也是最後一個步驟，稱做產品演進。軟體產品完成證實與驗認後就可以交由使用者去正式上線運轉了。運轉數(shù)年、數(shù)月甚至數(shù)天之後，若有必要進行下一版，或發(fā)現(xiàn)有些部分錯誤，有些部分需要補強，或使用者覺得有些地方要更改需求與規(guī)格，甚至大翻修，則便要因應之而進行產品演進的步驟了。l除了五個步驟的分類外，也可以將開發(fā)過程涵蓋在軟體工程的二個活動中：(A)軟工管理活動(SE Management Activity)

5、Gilb88，林02、(B)軟工技術活動(SE Technology Activity)。l這二個活動和五個步驟的關係如圖1-2所示。軟工管理活動涵蓋專案規(guī)劃步驟等一個步驟，軟工技術活動涵蓋需求與規(guī)格、設計與實作、證實與驗認、產品演進等四個步驟。圖圖1-2開發(fā)過程中步驟與活動的關係開發(fā)過程中步驟與活動的關係l（附註：軟工管理活動涵蓋專案規(guī)劃步驟，但專案規(guī)劃步驟並不涵蓋軟工管理活動。因為軟工管理活動除了專案規(guī)劃外，尚有其它事項，本書後面章節(jié)會介紹所有的軟工管理活動。）l針對開發(fā)過程的五個步驟，過程模式可以採取瀑布模式(Waterfall Model)進行之，如圖1-3所示。在瀑布模式裡，專案規(guī)劃

6、、需求與規(guī)格、設計與實作、證實與驗認、產品演進等五個步驟相互間呈現(xiàn)的是的一種循序關係。換句話說，每一個步驟必須經(jīng)過確定後才能進入下一個步驟。圖圖1-3瀑布模式瀑布模式l瀑布模式的缺點是使用者無法在短期間看到產品，因而最後的產品可能不是使用者想要的。值是故，軟體開發(fā)的風險相對提高。l為了改善瀑布模式風險高的缺點，開發(fā)過程模式可以採取遞增模式(Incremental Model)來進行，如圖1-4所示。圖圖1-4遞增模式遞增模式l若要了解圖1-4可以用：(A)水平、(B)垂直等二度空間來觀察之。水平空間說明使用者每次提供部分的需求與規(guī)格，開發(fā)者就可以進行設計與實作部分的系統(tǒng)，然後經(jīng)過證實與驗認，就

7、會產出部分產品。垂直空間則說明部分產品會因為使用者逐漸補強需求與規(guī)格而一再演進。l在遞增模式裡，雖然部分產品只滿足使用者部分的需求，但這些部分產品卻都可以正式上線運轉。1-2 軟體產品l軟體是一個很奇特的產品，透過本節(jié)的探討，我們可以更進一步了解軟體的內含。l1-2-1軟體在整體系統(tǒng)中的角色l在本書裡，軟體(Software)指的就是電腦軟體(Computer Software)。一般而言，軟體不可能單獨存在。通常源自整體系統(tǒng)需要，人們才會去開發(fā)軟體。一個整體系統(tǒng)可以是一家企業(yè)，一個飛機航空站，一間學校，一個城市，一架太空梭，一個國家等等。l軟體在整體系統(tǒng)裡面，只能算是一個子系統(tǒng)。如圖1-5所

8、示，一個整體系統(tǒng)是由一些子系統(tǒng)所組成的。這些子系統(tǒng)包括建築物、人員、機械設備、物流、金流、資訊系統(tǒng)等等。然後資訊系統(tǒng)又可以再分成軟體和電腦硬體。圖圖1-5軟體在整體系統(tǒng)中的角色軟體在整體系統(tǒng)中的角色l軟體和電腦硬體的關係非常奇特。軟體無法單獨存在，它必須是架在電腦硬體之上的，如圖1-6所示。由於軟體和電腦硬體有如此的關係，所以人們使用資訊系統(tǒng)的方式可以說是先讓電腦硬體提供操作和服務給軟體使用，然後再由軟體提供操作和服務給人們使用。圖圖1-6人們透過軟體來使用電腦硬體人們透過軟體來使用電腦硬體l1-2-2軟體危機l資訊系統(tǒng)已經(jīng)成為當今人類社會最重要的裝備。l可想見的是，越來越多的軟體將被規(guī)劃來開

9、發(fā)。但是吾人在開發(fā)軟體時，常常會遭遇到許多問題，像是如何去開發(fā)軟體、又如何去維護這些日益增多的軟體、怎樣才能應付一日數(shù)變的軟體需求。這些問題都導致軟體危機(Software Crisis)的產生Your99。軟體危機歸結起來有下列這些：l(A) 一般老闆都不重視軟體。寧願花大筆錢採購硬體，也不肯投資在軟體開發(fā)上。因為對大多數(shù)的老闆來說，硬體是看的到、摸的著，而軟體則是看不到、摸不著的。 l(B) 即使老闆願意投資開發(fā)軟體了，但技術人員缺乏軟體開發(fā)經(jīng)驗，使得開發(fā)工作的計劃很難制定。在專案規(guī)劃時期，主觀盲目的制定專案計劃，執(zhí)行起來和實際情況會有所出入。未能做任何風險分析、監(jiān)控以及管理，致使經(jīng)費預算

10、常常突破。對於工作量估算不準確，進度計劃無法遵循，開發(fā)工作完成期限一拖再拖。已經(jīng)拖延了的任務，為了加快進度而增加人力，結果適得其反，不僅未能加快，反而更加延誤了。在這種狀況下，軟體投資老闆和軟體使用者對軟體開發(fā)工作既不滿意，也不信任。l(c)軟體設計與實作依據(jù)的需求與規(guī)格，在分析時期寫的不夠明確，或是為未能得到充份的表達。進入軟體設計時期，開發(fā)人員和使用者又未能及時交換意見，使得一些問題不能立即得到解決而隱藏起來，造成軟體實作時期矛盾的集中暴露。 l(D)未能在軟體證實與驗認的步驟中做好證明與測試的工作。提交給使用者的軟體品質非常差勁，在正式上線運轉中暴露大量的問題。 l(E)開發(fā)過程沒有統(tǒng)一

11、的、公認的方法論或規(guī)範，參加的人員各行其事。加上不重視文件整理工作，使得規(guī)格文件、設計文件、實作文件、測試文件、維護文件，等等都付之闕如，最後完成的的軟體產品非常難以維護。l(F)即使勉強做些維護，也未先做任何評估以及複審。想到那裡，就做到那裡。如此非結構式的維護方法，只有讓軟體危機愈來愈嚴重。l1-2-3軟體迷思l軟體迷思(Software Myths)就是一些對軟體似是而非的錯誤觀念Putn97。因此它們也是造成軟體危機的另一個主要原因。比較著名的軟體迷思如下：l(A) 幹嘛公司自己開發(fā)軟體呢？到外面買個套裝軟體就可以用了。事實上，套裝軟體只是提供一些簡單的功能。若想要有符合企業(yè)運作的軟體

12、，則一定要公司自己開發(fā)才行的通。l(B) 軟體先隨便做做，反正以後修改很容易。事實上，變更軟體要比重新開發(fā)軟體還要困難。絕對不可以隨便先做做，以後再修改。l(C) 進度落後八個月？那很簡單，再多加入五個開發(fā)人員就可以補上進度了。事實上，開發(fā)軟體用除了體力外，還要腦力。進度落後採用增加人員的方法，可能會效果不佳。l(D) 給我看到軟體開發(fā)結果就好了，不用告訴我軟體開發(fā)過程。事實上，軟體開發(fā)過程決定軟體開發(fā)結果。不去注意軟體開發(fā)過程，則註定軟體開發(fā)結果會很淒慘。l(E) 開發(fā)軟體技術人員就夠了，不要麻煩企業(yè)經(jīng)營者。事實上，開發(fā)軟體，技術約只有百分之二十的重要性，其它關鍵百分之八十是非技術問題。唯有

13、企業(yè)經(jīng)營者百分之百的投入，軟體成功的機率會比較大。l(F) 開軟體公司很容易，不需要多少資本就可以了。事實上，軟體產品比硬體產品複雜多了。相較之下，同等級的軟體公司會比硬體公司需要更多的資本。l1-2-4 系統(tǒng)模型l若我們可以使用一個好的系統(tǒng)模型(System Model)來描述與表達軟體產品，如此整個軟體開發(fā)工作可以達到事半功倍的效果。l系統(tǒng)模型的目標就是幫助我們來描述與表達軟體的多重觀點(Multiple Views)。一個軟體有多重觀點。這些觀點包括：結構角度的觀點(View of Structure Area)、行為角度的觀點(View of Behavior Area)、其他觀點(V

14、iew of Others)三者。在此的其他觀點包括：分析觀點(Use Case View) l（附註：本書將Use Case View翻譯成分析觀點，其他參考資料可能會翻譯成使用個案觀點。）、設計觀點(Logical View)（附註：本書將Logical View翻譯成設計觀點，其他參考資料可能會翻譯成邏輯觀點。）、元件觀點(Component View)、部署觀點(Deployment View)、行程觀點(Process View)等等。l系統(tǒng)模型描述與表達上述軟體多重觀點可能採用兩種不同的方法。第一種為非架構導向方法(Non-Architecture-Oriented Methodo

15、logy)，第二種為架構導向方法(Architecture-Oriented Methodology)。l非架構導向方法會為每一個觀點各自選取一個模型，如圖1-7所示，結構角度的觀點有結構模型，行為角度的觀點有行為模型，其他觀點有其他模型。在此的其他模型包括：分析觀點有分析模型，設計觀點有設計模型，元件觀點有元件模型，部署觀點有部署模型，行程觀點有行程模型。這些不同模型彼此之間完全沒有異種同形(Isomorphism)的關係，因而這些模型是分離的，而且無法整合的。圖圖1-7非架構導向方法會為每一個觀點各自選非架構導向方法會為每一個觀點各自選取一個模式取一個模式l讓我們在此舉一個例子來說明之。結

16、構化系統(tǒng)開發(fā)方法(Structured System Development Methodology)是一個在軟體領域中行之多年，並且相當著名的非架構導向方法Gutt88，蕭92。l結構化系統(tǒng)開發(fā)方法採用資料流程圖(Data Flow Diagram)當作其行為模型行為模型。資料流程圖裡含有五個要素：(A)處理(Process)、(B)資料流(Data Flow)、(C)資料儲存(Data Store)、(D)資料起迄處(Data Source and Sink)、(E)選擇信號(Selection Signal)。利用這些要素，資料流程圖可以繪製出一個系統(tǒng)的系統(tǒng)行為，如圖1-8所示。圖圖1-

17、8資料流程圖範例資料流程圖範例l結構化系統(tǒng)開發(fā)方法採用結構表(Structured Chart)當作其結構模型。結構表裡含有有三個要素：(A)模組(Module)、(B)呼叫連結(Call Link)、(C)模組的交談。利用這些要素，結構表可以繪製出一個系統(tǒng)的系統(tǒng)結構，如圖1-9所示。圖圖1-9結構表範例結構表範例l架構導向方法和非架構導向方法絕然不同，如圖1-10所示。架構導向方法只會有一個模型，這個模型就稱為軟體架構，結構角度的觀點、行為角度的觀點、其他觀點三者都在這一個模型裡，在此的其他觀點包括：分析觀點、設計觀點、元件觀點、部署觀點、行程觀點等等。由於這個軟體架構模型可以同時描述與表達

18、所有觀點，所以它是一個整合模型(Integrated Model)。圖圖1-10軟體架構是一個整合模型軟體架構是一個整合模型l軟體架構(Software Architecture)採用一個整合模型來描述與表達(Describe and Represent)軟體的多重觀點(Multiple Views)，淺顯易懂，威力無窮。l使用軟體架構來描述與表達軟體的多重觀點，一說軟體架構可以投射(Projection)出結構觀點、行為觀點、其他觀點等等，二說經(jīng)由結構觀點、行為觀點、其他觀點的相互合作可以推導(Derivation)出軟體架構來，如圖1-11示。圖圖1-11軟體架構和觀點之間的投射與推導關係軟體架構和觀點之間的投射與推導關係l1-3軟體工程規(guī)範l軟體危機和軟體迷思告訴我們軟體開發(fā)不是只會寫程式就好了，必須採用有效的工程方法。l軟體工程提供軟體開發(fā)的方法論Pres01，Somm00，林97，鄭93，趙95，趙03。軟體工程規(guī)範下列要點，以便解決軟體危機和軟體迷思，而使得到軟體開發(fā)有事半功倍的效果。l第一，產品與過程並重。唯有好的過程方才會有好的產品，軟體開發(fā)也不例外。軟