本篇文章給大家談?wù)勡浖_發(fā)管理流程圖，以及軟件開發(fā)管理過程對應(yīng)的知識(shí)點(diǎn)，希望對各位有所幫助，不要忘了收藏本站喔。

本文目錄一覽：

• 1、軟件工程各種圖的區(qū)別
• 2、軟件開發(fā)有哪些需求分析管理工具？或者說一個(gè)軟件需求分析師會(huì)用到什么工具
• 3、bpmn流程圖要運(yùn)行起來，并且能接收用戶輸入，跟實(shí)際數(shù)據(jù)庫聯(lián)系，請問用什么軟件，在什么環(huán)境下開發(fā)啊？
• 4、互聯(lián)網(wǎng)軟件開發(fā)過程包括哪幾個(gè)階段？
• 5、軟件開發(fā)過程中的常見問題有哪些？

軟件工程各種圖的區(qū)別

1.完成患者監(jiān)護(hù)系統(tǒng)功能級的數(shù)據(jù)流圖、實(shí)體聯(lián)系圖、軟件結(jié)構(gòu)圖。2.網(wǎng)上書店系統(tǒng),其外部用戶主要有游客、會(huì)員和管理員。其中,游客進(jìn)行注冊后,可以成為系統(tǒng)的會(huì)員,會(huì)員享有訂購圖書及訂單和書籍等信息查詢的功能,管理員可對系統(tǒng)的各種信息進(jìn)行管理和維護(hù)。根據(jù)上述描述,請畫出網(wǎng)上書店系統(tǒng)的:①基本系統(tǒng)模型(第0層);②功能級的數(shù)據(jù)流圖(第1層);③底層的訂購圖書數(shù)據(jù)流圖。1.把如下統(tǒng)計(jì)空格程序的Jackson圖改畫為等價(jià)的程序流程圖和盒圖。2、用Jackson圖描述下述的一列火車的構(gòu)成:一列火車最多有兩個(gè)火車頭。只有一個(gè)火車頭時(shí)則位于列車最前面

軟件開發(fā)有哪些需求分析管理工具？或者說一個(gè)軟件需求分析師會(huì)用到什么工具

需求分析是不可能考一個(gè)軟件就搞定的。需求分析指的是開發(fā)軟件前，對所有需求進(jìn)行分析整合，最后形成一個(gè)文檔的過程。最問的文檔一般來說就是word，word中的內(nèi)容就是你自己寫的，通常會(huì)包含流程圖，畫流程圖的工具有太多太多了，比如，visio，rose等。如果包含數(shù)據(jù)庫模型，還可能用到PD等工具。。。。。等等等等。所以沒辦法確切的說會(huì)用到哪些工具，不過word類應(yīng)該是99.99%都會(huì)用到。

bpmn流程圖要運(yùn)行起來，并且能接收用戶輸入，跟實(shí)際數(shù)據(jù)庫聯(lián)系，請問用什么軟件，在什么環(huán)境下開發(fā)??？

業(yè)務(wù)流程建模標(biāo)注（Business Process Modeling Notation，BPMN)　描述基本的BPMN符號，包括這些圖元如何組合成一個(gè)業(yè)務(wù)流程圖（Business Process Diagram）；討論BPMN的各種的用途，包括以何種精度來影響一個(gè)流程圖中的模型；（Also discussed will be the different uses of BPMN, including how levels of precision affect what a modeler will include in a diagram.）；BPMN作為一個(gè)標(biāo)準(zhǔn)的價(jià)值，以及BPMN未來發(fā)展的遠(yuǎn)景。

由BPMI(The Business Process Management Initiative)開發(fā)了一套標(biāo)準(zhǔn)叫業(yè)務(wù)流程建模符號(BPMN)。在 BPMI Notation Working Group超過2年的努力，于2004年5月對外發(fā)布了BPMN 1.0 規(guī)范。BPMN的主要目標(biāo)是提供一些被所有業(yè)務(wù)用戶容易理解的符號，從創(chuàng)建流程輪廓的業(yè)務(wù)分析到這些流程的實(shí)現(xiàn)，直到最終用戶的管理監(jiān)控。BPMN也支持提供一個(gè)內(nèi)部的模型可以生成可執(zhí)行的BPEL4WS。因此BPMN的出現(xiàn)，彌補(bǔ)了從業(yè)務(wù)流程設(shè)計(jì)到流程開發(fā)的間隙。

BPMN定義了一個(gè)業(yè)務(wù)流程圖（Business Process Diagram），該業(yè)務(wù)流程圖基于一個(gè)流程圖（flowcharting），該流程圖被設(shè)計(jì)用于創(chuàng)建業(yè)務(wù)流程操作的圖形化模型。而一個(gè)業(yè)務(wù)流程模型（Business Process Model），指一個(gè)由的圖形對象（graphical objects）組成的網(wǎng)狀圖，圖形對象包括活動(dòng)（acticities)和用于定義這些活動(dòng)執(zhí)行順序的流程控制器（flow controls）。

編輯本段BPMN規(guī)范簡介BPMN是BPM以及workflow的建模語言標(biāo)準(zhǔn)之一,有必要學(xué)習(xí)。

在我的前篇文章淺談眾多工作流規(guī)范中談到了一個(gè)重要的工作流建模語言的規(guī)范--BPMN。先是直接查看BPMN V1.01的規(guī)范內(nèi)容，200多頁內(nèi)容繁多，細(xì)節(jié)不少。作為初學(xué)者看得暈頭轉(zhuǎn)向，現(xiàn)獻(xiàn)上 幫助初學(xué)者理清思路,總體把握清楚BPMN規(guī)范。

1、什么是BPMN

首先BPMN規(guī)范是由標(biāo)準(zhǔn)組織BPMI發(fā)布的.BPMN 1.0規(guī)范發(fā)布于2004年5月。此規(guī)范展示了BPMI組織兩年多的努力成果。BPMN的主要目標(biāo)就是要提供被所有業(yè)務(wù)用戶理解的一套標(biāo)記語言，包括業(yè)務(wù)分析者、軟件開發(fā)者以及業(yè)務(wù)管理者與監(jiān)察者。BPMN還將支持生成可執(zhí)行的BPEL4WS語言。所以，BPMN在業(yè)務(wù)流程設(shè)計(jì)與流程實(shí)現(xiàn)之間搭建了一條標(biāo)準(zhǔn)化的橋梁。

BPMN定義了業(yè)務(wù)流程圖，其基于流程圖技術(shù)，同時(shí)為創(chuàng)建業(yè)務(wù)流程操作的圖形化模型進(jìn)行了裁減。業(yè)務(wù)流程的模型就是圖形化對象的網(wǎng)圖，包括活動(dòng)（也可以說工作）和定義操作順序的流控制。

2、BPMN基礎(chǔ)

業(yè)務(wù)流程圖由一系列的圖形化元素組成。這些元素簡化了模型的開發(fā)，且業(yè)務(wù)分析者看上去非常熟悉。這些元素每個(gè)都有各自的特性，且與大多數(shù)的建模器類似。比如，活動(dòng)是矩形，條件是菱形。應(yīng)該強(qiáng)調(diào)的是：開發(fā)BPMN的動(dòng)力就是為了在創(chuàng)建業(yè)務(wù)流程模型時(shí)提供一個(gè)簡單的機(jī)制，同時(shí)又能夠處理來自業(yè)務(wù)流程的復(fù)雜性。要處理這兩個(gè)矛盾的需求的方法就是將標(biāo)記的圖形化方面組織分類為特定的類別。這里提供標(biāo)記類別中的一小部分，以便業(yè)務(wù)流程圖的讀者可以簡單地識(shí)別出元素的基本類型從而理解圖形。以下是四種基本的類型：

1）流對象

2）連接對象

3）泳道

4）人工信息

下面一一解釋

流對象：

一個(gè)業(yè)務(wù)流程圖有三個(gè)流對象的核心元素。這三種流對象是

事件---一個(gè)事件用圓圈來描述，表示一個(gè)業(yè)務(wù)流程期間發(fā)生的東西。事件影響流程的流動(dòng)，一般有一個(gè)原因（觸發(fā)器）或一個(gè)影響（結(jié)果）?；谒鼈儗α鞒痰挠绊懀腥N事件：開始，中間以及終止事件

活動(dòng)－－－一個(gè)活動(dòng)用圓角矩形表示，是要處理工作的一般術(shù)語。一個(gè)活動(dòng)可以是原子性的也可以是非原子性的（可以是由多個(gè)活動(dòng)組合而成的更大粒度的活動(dòng)）。活動(dòng)的類型包括：任務(wù)和子流程。子流程在圖形的下方中間外加一個(gè)小加號（+）來區(qū)分。

條件－－－條件用熟悉的菱形表示，用于控制序列流的分支與合并。另外，它還可以作為傳統(tǒng)的選擇，還包括路徑的分支與合并。其內(nèi)部的標(biāo)記會(huì)給出控制流的類型。

連接對象：

連接對象將流對象連接起來形成一個(gè)業(yè)務(wù)流程的基本結(jié)構(gòu)。提供此功能的三個(gè)連接對象是：

順序流---順序流用一個(gè)帶實(shí)心箭頭的實(shí)心線表示，用于指定活動(dòng)執(zhí)行的順序。注意“控制流”這個(gè)術(shù)語一般不用于BPMN

消息流－－－消息流用一條帶有開箭頭的虛線表示，用于描述兩個(gè)獨(dú)立的業(yè)務(wù)參與者（業(yè)務(wù)實(shí)體或業(yè)務(wù)角色）之間發(fā)送和接受的消息流動(dòng)。在BPMN中，用兩個(gè)獨(dú)立的池代表兩個(gè)參與者。

關(guān)聯(lián)－－－用一根帶有線箭頭的點(diǎn)線表示關(guān)聯(lián)，用于將相關(guān)的數(shù)據(jù)、文本和其他人工信息與流對象聯(lián)系起來。關(guān)聯(lián)用于展示活動(dòng)的輸入和輸出。

泳道：

許多建模技術(shù)利用泳道這個(gè)概念將活動(dòng)劃分到不同的可視化類別中來描述由不同的參與者的責(zé)任與職責(zé)。BPMN支持2種主要的泳道構(gòu)件。

池－－－池描述流程中的一個(gè)參與者?？梢钥醋鍪菍⒁幌盗谢顒?dòng)區(qū)別于其他池的一個(gè)圖形容器，一般用于B2B的上下文中。

道－－－道就是在池里面再細(xì)分，可以是垂直的也可以是水平的。道也是用于組織和分類活動(dòng)。

人工信息：

人工信息添加到建模的業(yè)務(wù)流程上下文中作為信息備注，便于人員理解，當(dāng)前BPMN規(guī)范的版本預(yù)定義了3種人工信息：

數(shù)據(jù)對象－－－數(shù)據(jù)對象是一個(gè)顯示活動(dòng)是如何需要或產(chǎn)生數(shù)據(jù)的。它們通過關(guān)聯(lián)與活動(dòng)連接起來。

組－－－組用一個(gè)虛線的圓角矩形表示，用于記錄或分析的目的，但不影響順序流。

注釋－－－注釋是建模者為BPMN圖的讀者提供附加文本信息的一個(gè)機(jī)制。

3、BPMN建模的價(jià)值

BPMN的開發(fā)是減少眾多已存在的業(yè)務(wù)建模工具和標(biāo)記斷層的重要的一步。BPMI標(biāo)準(zhǔn)化組織從許多存在的標(biāo)記中展示出了專業(yè)和經(jīng)驗(yàn)，且從這些不同的標(biāo)記中找到了最好的理念形成一套標(biāo)準(zhǔn)的標(biāo)記語言，眾多的標(biāo)記語言包括UML、Activity Diagram、UML EDOC Business Process、IDEF、ebXML BPSS、RosettaNet以及Event-Process Chains等等。一個(gè)好的標(biāo)準(zhǔn)建模標(biāo)記將會(huì)減少業(yè)務(wù)與IT用戶之間的混亂。

另一個(gè)驅(qū)使BPMN的開發(fā)原動(dòng)力是，歷史上由業(yè)務(wù)人員做出來的業(yè)務(wù)流程建模從需要系統(tǒng)設(shè)計(jì)與執(zhí)行的流程描述中隔離出來，所以有必要將原有的業(yè)務(wù)流程模型轉(zhuǎn)換為執(zhí)行模型，而這個(gè)轉(zhuǎn)換對于流程擁有者來說容易出錯(cuò)，且很艱難。

為了減少建模技術(shù)的斷層，開發(fā)BPMN的重要目標(biāo)就是要?jiǎng)?chuàng)建面向業(yè)務(wù)流程建模標(biāo)記到面向IT執(zhí)行語言的一座橋梁。

　ProcessOn在線流程設(shè)計(jì)器

ProcessOn流程圖設(shè)計(jì)器支持BPMN2.0的三種標(biāo)準(zhǔn)類型建模 - Process, Collaboration和Choreography. 用戶在畫BPMN2.0流程圖的同時(shí)，還可以設(shè)置與特定圖形相關(guān)的業(yè)務(wù)屬性，ProcessOn內(nèi)置了BPMN2.0展示層所要求的所有標(biāo)準(zhǔn)業(yè)務(wù)屬性。

BPMN 2.0 Modeler for Visio description

BPMN的2.0建模for Visio是微軟Visio附件設(shè)計(jì)繪制和建模業(yè)務(wù)流程。這是一個(gè)全面的用戶友好的軟件包。2.0建模的BPMN為Visio支持的BPMN 2.0元素提出一套完整的（流對象，連接對象，泳道，文物和數(shù)據(jù)）。

目前最新版本為支持Visio 2010的2.1版。

互聯(lián)網(wǎng)軟件開發(fā)過程包括哪幾個(gè)階段？

Boehm：運(yùn)用現(xiàn)代科學(xué)技術(shù)知識(shí)來設(shè)計(jì)并構(gòu)造計(jì)算機(jī)程序及為開發(fā)、運(yùn)行和維護(hù)這些程序所必需的相關(guān)文件資料。

IEEE：軟件工程是開發(fā)、運(yùn)行、維護(hù)和修復(fù)軟件的系統(tǒng)方法。

Fritz Bauer：建立并使用完善的工程化原則，以較經(jīng)濟(jì)的手段獲得能在實(shí)際機(jī)器上有效運(yùn)行的可靠軟件的一系列方法。

軟件工程學(xué)的內(nèi)容

軟件工程學(xué)的主要內(nèi)容是軟件開發(fā)技術(shù)和軟件工程管理．

軟件開發(fā)技術(shù)包含軟件工程方法學(xué)、軟件工具和軟件開發(fā)環(huán)境；軟件工程管理學(xué)包含軟件工程經(jīng)濟(jì)學(xué)和軟件管理學(xué)。

軟件工程基本原理

著名軟件工程專家B.Boehm綜合有關(guān)專家和學(xué)者的意見并總結(jié)了多年來開發(fā)軟件的經(jīng)驗(yàn)，于1983年在一篇論文中提出了軟件工程的七條基本原理。

（1）用分階段的生存周期計(jì)劃進(jìn)行嚴(yán)格的管理。

（2）堅(jiān)持進(jìn)行階段評審。

（3）實(shí)行嚴(yán)格的產(chǎn)品控制。

（4）采用現(xiàn)代程序設(shè)計(jì)技術(shù)。

（5）軟件工程結(jié)果應(yīng)能清楚地審查。

（6）開發(fā)小組的人員應(yīng)該少而精。

（7）承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性。

B.Boehm指出，遵循前六條基本原理，能夠?qū)崿F(xiàn)軟件的工程化生產(chǎn)；按照第七條原理，不僅要積極主動(dòng)地采納新的軟件技術(shù)，而且要注意不斷總結(jié)經(jīng)驗(yàn)。

軟件工程(SoftWare Engineering)的框架可概括為：目標(biāo)、過程和原則。

(1)軟件工程目標(biāo)：生產(chǎn)具有正確性、可用性以及開銷合宜的產(chǎn)品。正確性指軟件產(chǎn)品達(dá)到預(yù)期功能的程度?？捎眯灾杠浖窘Y(jié)構(gòu)、實(shí)現(xiàn)及文檔為用戶可用的程度。開銷合宜是指軟件開發(fā)、運(yùn)行的整個(gè)開銷滿足用戶要求的程度。這些目標(biāo)的實(shí)現(xiàn)不論在理論上還是在實(shí)踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。

(2)軟件工程過程：生產(chǎn)一個(gè)最終能滿足需求且達(dá)到工程目標(biāo)的軟件產(chǎn)品所需要的步驟。軟件工程過程主要包括開發(fā)過程、運(yùn)作過程、維護(hù)過程。它們覆蓋了需求、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)以及維護(hù)等活動(dòng)。需求活動(dòng)包括問題分析和需求分析。問題分析獲取需求定義，又稱軟件需求規(guī)約。需求分析生成功能規(guī)約。設(shè)計(jì)活動(dòng)一般包括概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。概要設(shè)計(jì)建立整個(gè)軟件系統(tǒng)結(jié)構(gòu)，包括子系統(tǒng)、模塊以及相關(guān)層次的說明、每一模塊的接口定義。詳細(xì)設(shè)計(jì)產(chǎn)生程序員可用的模塊說明，包括每一模塊中數(shù)據(jù)結(jié)構(gòu)說明及加工描述。實(shí)現(xiàn)活動(dòng)把設(shè)計(jì)結(jié)果轉(zhuǎn)換為可執(zhí)行的程序代碼。確認(rèn)活動(dòng)貫穿于整個(gè)開發(fā)過程，實(shí)現(xiàn)完成后的確認(rèn)，保證最終產(chǎn)品滿足用戶的要求。維護(hù)活動(dòng)包括使用過程中的擴(kuò)充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓(xùn)過程等。

(3)軟件工程的原則是指圍繞工程設(shè)計(jì)、工程支持以及工程管理在軟件開發(fā)過程中必須遵循的原則。

軟件工程必須遵循什么原則

圍繞工程設(shè)計(jì)、工程支持以及工程管理已提出了以下四條基本原則：

(1)選取適宜的開發(fā)模型

該原則與系統(tǒng)設(shè)計(jì)有關(guān)。在系統(tǒng)設(shè)計(jì)中，軟件需求、硬件需求以及其它因素間是相互制約和影響的，經(jīng)常需要權(quán)衡。因此，必需認(rèn)識(shí)需求定義的易變性，采用適當(dāng)?shù)拈_發(fā)模型，保證軟件產(chǎn)品滿足用戶的要求。

(2)采用合適的設(shè)計(jì)方法

在軟件設(shè)計(jì)中，通常需要考慮軟件的模塊化、抽象與信息隱蔽、局部化、一致性以及適應(yīng)性等特征。合適的設(shè)計(jì)方法有助于這些特征的實(shí)現(xiàn)，以達(dá)到軟件工程的目標(biāo)。

(3)提供高質(zhì)量的工程支撐

工欲善其事，必先利其器。在軟件工程中，軟件工具與環(huán)境對軟件過程的支持頗為重要。軟件工程項(xiàng)目的質(zhì)量與開銷直接取決于對軟件工程所提供的支撐質(zhì)量和效用。

(4)重視軟件工程的管理

軟件工程的管理直接影響可用資源的有效利用，生產(chǎn)滿足目標(biāo)的軟件產(chǎn)品以及提高軟件組織的生產(chǎn)能力等問題。因此，僅當(dāng)軟件過程予以有效管理時(shí)，才能實(shí)現(xiàn)有效的軟件工程。

軟件工程是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的工程學(xué)科。

采用工程的概念、原理、 技術(shù)和方法來開發(fā)與維護(hù)軟件，把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠 得到的最好的技術(shù)方法結(jié)合起來，這就是軟件工程。

軟件工程強(qiáng)調(diào)使用生存周期方法學(xué)和各種結(jié)構(gòu)分析及結(jié)構(gòu)設(shè)計(jì)技術(shù)。它們是在七十年代為了對付應(yīng)用軟件日益增長的復(fù)雜程度、漫長的開發(fā)周期以及用戶對軟件產(chǎn)品經(jīng)常不滿意的狀況而發(fā)展起來的。人類解決復(fù)雜問題時(shí)普遍采用的一個(gè)策略就是“各個(gè)擊破”，也就是對問題進(jìn)行分解然后再分別解決各個(gè)子問題的策略。軟件工程采用的生存周期方法學(xué)就是從時(shí)間角度對軟件開發(fā)和維護(hù)的復(fù)雜問題進(jìn)行分解，把軟件生存的漫長周期依次劃分為若干個(gè)階段，每個(gè)階段有相對獨(dú)立的任務(wù)，然后逐步完成每個(gè)階段的任務(wù)。采用軟件工程方法論開發(fā)軟件的時(shí)候，從對任務(wù)的抽象邏輯分析開始，一個(gè)階段一個(gè)階段地進(jìn)行開發(fā)。前一個(gè)階段任務(wù)的完成是開始進(jìn)行后一個(gè)階段工作的前提和基礎(chǔ)，而后一階段任務(wù)的完成通常是使前一階段提出的解法更進(jìn)一步具體化，加進(jìn)了更多的物理細(xì)節(jié)。每一個(gè)階段的開始和結(jié)束都有嚴(yán)格標(biāo)準(zhǔn)，對于任何兩個(gè)相鄰的階段而言，前一階段的結(jié)束標(biāo)準(zhǔn)就是后一階段的開始標(biāo)準(zhǔn)。在每一個(gè)階段結(jié)束之前都必須進(jìn)行正式嚴(yán)格的技術(shù)審查和管理復(fù)審，從技術(shù)和管理兩方面對這個(gè)階段的開發(fā)成果進(jìn)行檢查，通過之后這個(gè)階段才算結(jié)束；如果檢查通不過，則必須進(jìn)行必要的返工，并且返工后還要再經(jīng)過審查。審查的一條主要標(biāo)準(zhǔn)就是每個(gè)階段都應(yīng)該交出“最新式的”（即和所開發(fā)的軟件完全一致的）高質(zhì)量的文檔資料，從而保證在軟件開發(fā)工程結(jié)束時(shí)有一個(gè)完整準(zhǔn)確的軟件配置交付使用。文檔是通信的工具，它們清楚準(zhǔn)確地說明了到這個(gè)時(shí)候?yàn)橹梗P(guān)于該項(xiàng)工程已經(jīng)知道了什么，同時(shí)確立了下一步工作的基礎(chǔ)。此外，文檔也起備忘錄的作用，如果文檔不完整，那么一定是某些工作忘記做了，在進(jìn)入生存周期的下一階段之前，必須補(bǔ)足這些遺漏的細(xì)節(jié)。在完成生存周期每個(gè)階段的任務(wù)時(shí)，應(yīng)該采用適合該階段任務(wù)特點(diǎn)的系統(tǒng)化的技術(shù)方法——結(jié)構(gòu)分析或結(jié)構(gòu)設(shè)計(jì)技術(shù)。

把軟件生存周期劃分成若干個(gè)階段，每個(gè)階段的任務(wù)相對獨(dú)立，而且比較簡單，便于不同人員分工協(xié)作，從而降低了整個(gè)軟件開發(fā)工程的困難程度；在軟件生存周期的每個(gè)階段都采用科學(xué)的管理技術(shù)和良好的技術(shù)方法，而且在每個(gè)階段結(jié)束之前都從技術(shù)和管理兩個(gè)角度進(jìn)行嚴(yán)格的審查，合格之后才開始下一階段的工作，這就使軟件開發(fā)工程的全過程以一種有條不紊的方式進(jìn)行，保證了軟件的質(zhì)量，特別是提高了軟件的可維護(hù)性。總之，采用軟件工程方法論可以大大提高軟件開發(fā)的成功率，軟件開發(fā)的生產(chǎn)率也能明顯提高。

目前劃分軟件生存周期階段的方法有許多種，軟件規(guī)模、種類、開發(fā)方式、開發(fā)環(huán)境以及開發(fā)時(shí)使用的方法論都影響軟件生存周期階段的劃分。在劃分軟件生存周期的階段時(shí)應(yīng)該遵循的一條基本原則就是使各階段的任務(wù)彼此間盡可能相對獨(dú)立，同一階段各項(xiàng)任務(wù)的性質(zhì)盡可能相同，從而降低每個(gè)階段任務(wù)的復(fù)雜程度，簡化不同階段之間的聯(lián)系，有利于軟件開發(fā)工程的組織管理。一般說來，軟件生存周期由軟件定義、軟件開發(fā)和軟件維護(hù)三個(gè)時(shí)期組成，每個(gè)時(shí)期又進(jìn)一步劃分成若干個(gè)階段。下面的論述主要針對應(yīng)用軟件，對系統(tǒng)軟件也基本適用。

軟件定義時(shí)期的任務(wù)是確定軟件開發(fā)工程必須完成的總目標(biāo)；確定工程的可行性，導(dǎo)出實(shí)現(xiàn)工程目標(biāo)應(yīng)該采用的策略及系統(tǒng)必須完成的功能；估計(jì)完成該項(xiàng)工程需要的資源和成本，并且制定工程進(jìn)度表。這個(gè)時(shí)期的工作通常又稱為系統(tǒng)分析，由系統(tǒng)分析員負(fù)責(zé)完成。軟件定義時(shí)期通常進(jìn)一步劃分成三個(gè)階段，即問題定義、可行性研究和需求分析。

開發(fā)時(shí)期具體設(shè)計(jì)和實(shí)現(xiàn)在前一個(gè)時(shí)期定義的軟件，它通常由下述四個(gè)階段組成：總體設(shè)計(jì)，詳細(xì)設(shè)計(jì)，編碼和單元測試，綜合測試。

維護(hù)時(shí)期的主要任務(wù)是使軟件持久地滿足用戶的需要。具體地說，當(dāng)軟件在使用過程中發(fā)現(xiàn)錯(cuò)誤時(shí)應(yīng)該加以改正；當(dāng)環(huán)境改變時(shí)應(yīng)該修改軟件以適應(yīng)新的環(huán)境；當(dāng)用戶有新要求時(shí)應(yīng)該及時(shí)改進(jìn)軟件滿足用戶的新需要。通常對維護(hù)時(shí)期不再進(jìn)一步劃分階段，但是每一次維護(hù)活動(dòng)本質(zhì)上都是一次壓縮和簡化了的定義和開發(fā)過程。

下面扼要介紹軟件生存周期每個(gè)階段的基本任務(wù)和結(jié)束標(biāo)準(zhǔn)。

1問題定義

問題定義階段必須回答的關(guān)鍵問題：“要解決的問題是什么？”如果不知道問題是什么就試圖解決這個(gè)問題，顯然是盲目的，只會(huì)白白浪費(fèi)時(shí)間和金錢，最終得出的結(jié)果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的，但是在實(shí)踐中它卻可能是最容易被忽視的一個(gè)步驟。

通過問題定義階段的工作，系統(tǒng)分析員應(yīng)該提出關(guān)于問題性質(zhì)、工程目標(biāo)和規(guī)模的書面報(bào)告。通過對系統(tǒng)的實(shí)際用戶和使用部門負(fù)責(zé)人的訪問調(diào)查，分析員扼要地寫出他對問題的理解，并在用戶和使用部門負(fù)責(zé)人的會(huì)議上認(rèn)真討論這份書面報(bào)告，澄清含糊不精的地方，改正理解不正確的地方，最后得出一份雙方都滿意的文檔。

問題定義階段是軟件生存周期中最簡短的階段，一般只需要一天甚至更少的時(shí)間。

2可行性研究

這個(gè)階段要回答的關(guān)鍵問題：“對于上一個(gè)階段所確定的問題有行得通的解決辦法嗎？”為了回答這個(gè)問題，系統(tǒng)分析員需要進(jìn)行一次大大壓縮和簡化了的系統(tǒng)分析和設(shè)計(jì)的過程，也就是在較抽象的高層次上進(jìn)行的分析和設(shè)計(jì)的過程。

可行性研究應(yīng)該比較簡短，這個(gè)階段的任務(wù)不是具體解決問題，而是研究問題的范圍，探索這個(gè)問題是否值得去解，是否有可行的解決辦法。

在問題定義階段提出的對工程目標(biāo)和規(guī)模的報(bào)告通常比較含糊。可行性研究階段應(yīng)該導(dǎo)出系統(tǒng)的高層邏輯模型（通常用數(shù)據(jù)流圖表示），并且在此基礎(chǔ)上更準(zhǔn)確、更具體地確定工程規(guī)模和目標(biāo)。然后分析員更準(zhǔn)確地估計(jì)系統(tǒng)的成本和效益，對建議的系統(tǒng)進(jìn)行仔細(xì)的成本／效益分析是這個(gè)階段的主要任務(wù)之一。

可行性研究的結(jié)果是使用部門負(fù)責(zé)人做出是否繼續(xù)進(jìn)行這項(xiàng)工程的決定的重要依據(jù)，一般說來，只有投資可能取得較大效益的那些工程項(xiàng)目才值得繼續(xù)進(jìn)行下去?？尚行匝芯恳院蟮哪切╇A段將需要投入要多的人力物力。及時(shí)中止不值得投資的工程項(xiàng)目，可以避免更大的浪費(fèi)。

3需求分析

這個(gè)階段的任務(wù)仍然不是具體地解決問題，而是準(zhǔn)確地確定“為了解決這個(gè)問題，目標(biāo)系統(tǒng)必須做什么”，主要是確定目標(biāo)系統(tǒng)必須具備哪些功能。

用戶了解他們所面對的問題，知道必須做什么，但是通常不能完整準(zhǔn)確地表達(dá)出他們的要求，更不知道怎樣利用計(jì)算機(jī)解決他們的問題；軟件開發(fā)人員知道怎樣使用軟件實(shí)現(xiàn)人們的要求，但是對特定用戶的具體要求并不完全清楚。因此系統(tǒng)分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經(jīng)過用戶確認(rèn)的系統(tǒng)邏輯模型。通常用數(shù)據(jù)流圖、數(shù)據(jù)字典和簡要的算法描述表示系統(tǒng)的邏輯模型。

在需求分析階段確定的系統(tǒng)邏輯模型是以后設(shè)計(jì)和實(shí)現(xiàn)目標(biāo)系統(tǒng)的基礎(chǔ)，因此必須準(zhǔn)確完整地體現(xiàn)用戶的要求。系統(tǒng)分析員通常都是計(jì)算機(jī)軟件專家，技術(shù)專家一般都喜歡很快著手進(jìn)行具體設(shè)計(jì)，然而，一旦分析員開始談?wù)摮绦蛟O(shè)計(jì)的細(xì)節(jié)，就會(huì)脫離用戶，使他們不能繼續(xù)提出他們的要求和建議。較件工程使用的結(jié)構(gòu)分析設(shè)計(jì)的方法為每個(gè)階段都規(guī)定了特定的結(jié)束標(biāo)準(zhǔn)，需求分析階段必須提供完整準(zhǔn)確的系統(tǒng)邏輯模型，經(jīng)過用戶確認(rèn)之后才能進(jìn)入下一個(gè)階段，這就可以有效地防止和克服急于著手進(jìn)行具體設(shè)計(jì)的傾向。

4總體設(shè)計(jì)

這個(gè)階段必須回答的關(guān)鍵問題是：“概括地說，應(yīng)該如何解決這個(gè)問題？”

首先，應(yīng)該考慮幾種可能的解決方案。列如，目標(biāo)系統(tǒng)的一些主要功能是用計(jì)算機(jī)自動(dòng)完成還是用人工完成；如果使用計(jì)算機(jī)，那么是使用批處理方式還是人機(jī)交互方式；信息存儲(chǔ)使用傳統(tǒng)的文件系統(tǒng)還是數(shù)據(jù)庫……。通常至少應(yīng)該考慮下述幾類可能的方案：

低成本的解決方案。系統(tǒng)只能完成最必要的工作，不能多做一點(diǎn)額處的工作。

中等成本的解決方案。這樣的系統(tǒng)不僅能夠很好地完成預(yù)定的任務(wù)，使用起來很方便，而且可能還具有用戶沒有具體指定的某些功能和特點(diǎn)。雖然用戶沒有提出這些具體要求，但是系統(tǒng)分析員根據(jù)自己的知識(shí)和經(jīng)驗(yàn)斷定，這些附加的能力在實(shí)踐中將證明是很有價(jià)值的。

高成本的“十全十美”的系統(tǒng)。這樣的系統(tǒng)具有用戶可能希望有的所有功能和特點(diǎn)。

系統(tǒng)分析員應(yīng)該使用系統(tǒng)流程圖或其他工具描述每種可能的系統(tǒng)，估計(jì)每種方案的成本和效益，還應(yīng)該在充分權(quán)衡各種方案的利弊的基礎(chǔ)上,推薦一個(gè)較好的系統(tǒng) (最佳方案),并且制定實(shí)現(xiàn)所推薦的系統(tǒng)的詳細(xì)計(jì)劃。如果用戶接受分析員推薦的系統(tǒng)，則可以著手完成本階段的另一項(xiàng)主要工作。

上面的工作確定了解決問題的策略以及目標(biāo)系統(tǒng)需要哪些程序，但是，怎樣設(shè)計(jì)這些程序呢？結(jié)構(gòu)設(shè)計(jì)的一條基本原理就是程序應(yīng)該模塊化，也就是一個(gè)大程序應(yīng)該由許多規(guī)模適中的模塊按合理的層次結(jié)構(gòu)組織而成?？傮w設(shè)計(jì)階段的第二項(xiàng)主要任務(wù)就是設(shè)計(jì)軟件的結(jié)構(gòu)，也就是確定程序由哪些模塊組成以及模塊間的關(guān)系。通常用層次圖或結(jié)構(gòu)圖描繪軟件的結(jié)構(gòu)。

5詳細(xì)設(shè)計(jì)

總體設(shè)計(jì)階段以比較抽象概括的方式提出了解決問題的辦法。詳細(xì)設(shè)計(jì)階段的任務(wù)就是把解法具體化，也就是回答下面這個(gè)關(guān)鍵問題：“應(yīng)該怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)呢？”

這個(gè)階段的任務(wù)還不是編寫程序，而是設(shè)計(jì)出程序的詳細(xì)規(guī)格說明。這種規(guī)格說明的作用很類似于其他工程領(lǐng)域中工程師經(jīng)常使用的工程藍(lán)圖，它們應(yīng)該包含必要的細(xì)節(jié)，程序員可以根據(jù)它們寫出實(shí)際的程序代碼。

通常用HIPO圖（層次圖加輸入／處理／輸出圖）或PDL語言（過程設(shè)計(jì)語言）描述詳細(xì)設(shè)計(jì)的結(jié)果。

6編碼和單元測試

這個(gè)階段的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護(hù)的程序模塊。

程序員應(yīng)該根據(jù)目標(biāo)系統(tǒng)的性質(zhì)和實(shí)際環(huán)境，選取一種適當(dāng)?shù)母呒壋绦蛟O(shè)計(jì)語言（必要時(shí)用匯編語言），把說細(xì)設(shè)計(jì)的結(jié)果翻譯成用選定的語言書寫的程序，并且仔細(xì)測試編寫出的每一個(gè)模塊。

7綜合測試

這個(gè)階段的關(guān)鍵任務(wù)是通過各種類型的測試（及相應(yīng)的調(diào)試）使軟件達(dá)到預(yù)定的要求。

最基本的測試是集成測試和驗(yàn)收測試。所謂集成測試是根據(jù)設(shè)計(jì)的軟件結(jié)構(gòu)，把經(jīng)過單元測試檢驗(yàn)的模塊按某種選定的策略裝配起來，在裝配過程中對程序進(jìn)行必要的測試。所謂驗(yàn)收測試則是按照規(guī)格說明書的規(guī)定（通常在需求分析階段確定），由用戶（或在用戶積極參加下）對目標(biāo)系統(tǒng)進(jìn)行驗(yàn)收。

必要時(shí)還可以再通過現(xiàn)場測試或平行運(yùn)行等方法對目標(biāo)系統(tǒng)進(jìn)一步測試檢驗(yàn)。

為了使用戶能夠積極參加驗(yàn)收測試，并且在系統(tǒng)投入生產(chǎn)性運(yùn)行以后能夠正確有效地使用這個(gè)系統(tǒng)，通常需要以正式的或非正式的方式對用戶進(jìn)行培訓(xùn)。

通過對軟件測試結(jié)果的分析可以預(yù)測軟件的可靠性；反之，根據(jù)對軟件可靠性的要求也可以決定測試和調(diào)試過程什么時(shí)候可以結(jié)束。

應(yīng)該用正式的文檔資料把測試計(jì)劃、詳細(xì)測試方案以及實(shí)際測試結(jié)果保存下來，做為軟件配置的一個(gè)組成成分。

8軟件維護(hù)

維護(hù)階段的關(guān)鍵任務(wù)是，通過各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要。

通常有四類維護(hù)活動(dòng)：改正性維護(hù)，也就是診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯(cuò)誤；適應(yīng)性維護(hù)，即修改軟件以適應(yīng)環(huán)境的變化；完善性維護(hù)，即根據(jù)用戶的要求改進(jìn)或擴(kuò)充軟件使它更完善；預(yù)防性維護(hù)，即修改軟件為將來的維護(hù)活動(dòng)預(yù)先做準(zhǔn)備。

雖然沒有把維護(hù)階段進(jìn)一步劃分成更小的階段，但是實(shí)際上每一項(xiàng)維護(hù)活動(dòng)都應(yīng)該經(jīng)過提出維護(hù)要求（或報(bào)告問題），分析維護(hù)要求，提出維護(hù)要求，提出維護(hù)方案，審批維護(hù)方案，確定維護(hù)計(jì)劃，修改軟件設(shè)計(jì)，修改程序，測試程序，復(fù)查驗(yàn)收等一系列步驟，因此實(shí)質(zhì)上是經(jīng)歷了一次壓縮和簡化了的軟件定義和開發(fā)的全過程。

都應(yīng)該經(jīng)過提出維護(hù)要求（或報(bào)告問題），分析維護(hù)要求，提出維護(hù)要求，提出維護(hù)方案，審批維護(hù)方案，確定維護(hù)計(jì)劃，修改軟件設(shè)計(jì)，修改程序，測試程序，復(fù)查驗(yàn)收等一系列步驟，因此實(shí)質(zhì)上是經(jīng)歷了一次壓縮和簡化了的軟件定義和開發(fā)的全過程。

軟件開發(fā)過程中的常見問題有哪些？

1.前言應(yīng)用軟件系統(tǒng)是事件驅(qū)動(dòng)的軟件系統(tǒng)，系統(tǒng)通過接口接受事件后，交由系統(tǒng)業(yè)務(wù)層處理，業(yè)務(wù)層處理完事件后將需要的信息存入數(shù)據(jù)庫，整個(gè)應(yīng)用軟件系統(tǒng)分為三個(gè)子系統(tǒng)：接口子系統(tǒng)，業(yè)務(wù)子系統(tǒng)，數(shù)據(jù)庫子系統(tǒng)，業(yè)務(wù)子系統(tǒng)進(jìn)一步分為三個(gè)子系統(tǒng)：表示層，業(yè)務(wù)層，數(shù)據(jù)接入層。其中業(yè)務(wù)層是整個(gè)系統(tǒng)的核心，表示層負(fù)責(zé)通過接口子系統(tǒng)接收系統(tǒng)事件交給業(yè)務(wù)層處理，數(shù)據(jù)接入層供業(yè)務(wù)層使用完成數(shù)據(jù)的持久化。每個(gè)層對編程人員的技術(shù)要求是不同的，表示層需要了解的技術(shù)根據(jù)接口子系統(tǒng)選擇的不同而不同：如windows界面，需要對MFC有比較深入的了解，web界面則要求對asp，asp.net，或jsp有比較深入的了解。數(shù)據(jù)訪問層需要的技術(shù)則由數(shù)據(jù)庫子系統(tǒng)的選擇決定，另外還需要了解：ODBC，JDBC等。接口子系統(tǒng)的選擇：windows界面，java界面，web界面，命令行接口，CTI， API等 數(shù)據(jù)庫子系統(tǒng)的選擇：關(guān)系數(shù)據(jù)庫，普通文件等基于以上對應(yīng)用軟件系統(tǒng)的理解，軟件開發(fā)流程的輸入是用戶的業(yè)務(wù)需求，輸出就是系統(tǒng)的業(yè)務(wù)層、表示層、數(shù)據(jù)接入層的代碼，以及接口和數(shù)據(jù)庫,以及各種文檔。因此得到比較理想化的軟件開發(fā)流程圖，該圖使用uml中的活動(dòng)圖描述。2.需求分析階段需求分析階段的常見問題是：需求分析不夠深入，對問題域沒有仔細(xì)研究，急于進(jìn)入設(shè)計(jì)階段。造成這種問題一方面是因?yàn)轫?xiàng)目管目趕進(jìn)度以及存在于管理人員頭腦中的根深蒂固的想法：任何時(shí)候不能讓任何人員閑著，另外很大的原因是很多人不知道如何進(jìn)一步深入研究問題域。需求分析階段不僅要列出系統(tǒng)的use case，更重要的是要列出use case的輸入輸出和例外情況等，以及問題域中的對象之間的靜態(tài)關(guān)系和動(dòng)態(tài)關(guān)系，如對象間的包含關(guān)系，繼承關(guān)系，調(diào)用關(guān)系等。需求分析階段另外一個(gè)常見的問題是常常將需求分析等同于數(shù)據(jù)庫設(shè)計(jì)，需求分析階段定義的是系統(tǒng)作什么，而不是怎么做，需求分析的結(jié)果應(yīng)該與具體的技術(shù)實(shí)現(xiàn)無關(guān)。數(shù)據(jù)庫設(shè)計(jì)是技術(shù)實(shí)現(xiàn)的細(xì)節(jié)，應(yīng)該盡可能的推遲技術(shù)細(xì)節(jié)的決策，不應(yīng)該使技術(shù)細(xì)節(jié)束縛了我們對系統(tǒng)需求的理解。需求分析階段應(yīng)該從用戶的角度對系統(tǒng)建模，不應(yīng)將大量的技術(shù)細(xì)節(jié)暴露給用戶，導(dǎo)致系統(tǒng)易用性差。需求分析階段可以進(jìn)一步細(xì)分為業(yè)務(wù)需求分析階段和系統(tǒng)功能需求分析階段。在很多研發(fā)性質(zhì)的系統(tǒng)中，不注重業(yè)務(wù)需求分析，只有系統(tǒng)功能需求分析，導(dǎo)致開發(fā)人員知其然不知其所以然。系統(tǒng)功能規(guī)范文檔與業(yè)務(wù)需求文檔的重要區(qū)別有以下幾點(diǎn)：內(nèi)容不同：系統(tǒng)需求分為功能需求和非功能需求，功能需求進(jìn)一步分為業(yè)務(wù)功能需求和非業(yè)務(wù)功能需求。系統(tǒng)需求規(guī)范文檔除了包括業(yè)務(wù)需求文檔中的業(yè)務(wù)功能需求，功能規(guī)范文檔需要增加以下內(nèi)容：系統(tǒng)的非業(yè)務(wù)功能需求，由于業(yè)務(wù)需求由計(jì)算機(jī)系統(tǒng)實(shí)現(xiàn)而產(chǎn)生的功能需求，如系統(tǒng)需要系統(tǒng)管理員管理，系統(tǒng)管理員的角度產(chǎn)生一些非業(yè)務(wù)功能需求，另外需要描述系統(tǒng)非功能需求：數(shù)據(jù)量，性能要求，響應(yīng)速度，可用性要求，可靠性要求，界面語言要求等等。 閱讀的對象不同：業(yè)務(wù)需求文檔是用來與業(yè)務(wù)人員交流，功能規(guī)范文檔是開發(fā)人員開發(fā)的依據(jù) 使用的語言不同：業(yè)務(wù)需求文檔使用自然語言書寫，而功能規(guī)范文檔使用比較嚴(yán)謹(jǐn)?shù)恼Z言，如：uml書寫 對編寫人的要求不一樣：業(yè)務(wù)需求編寫人員只需要對業(yè)務(wù)系統(tǒng)熟悉，系統(tǒng)規(guī)范由系統(tǒng)架構(gòu)師完成 體現(xiàn)系統(tǒng)架構(gòu)師價(jià)值的地方是編寫系統(tǒng)規(guī)范文檔和業(yè)務(wù)層設(shè)計(jì), 系統(tǒng)規(guī)范文檔是下一步界面設(shè)計(jì)，業(yè)務(wù)層設(shè)計(jì)和數(shù)據(jù)庫設(shè)計(jì)的依據(jù)，表示層，業(yè)務(wù)層，數(shù)據(jù)訪問層之間是相互聯(lián)系的，它們之間的關(guān)系應(yīng)該在系統(tǒng)規(guī)范文檔中找到。3.架構(gòu)設(shè)計(jì)階段架構(gòu)設(shè)計(jì)階段的常見問題是將架構(gòu)設(shè)計(jì)理解為技術(shù)架構(gòu)設(shè)計(jì)，實(shí)際上架構(gòu)設(shè)計(jì)分為技術(shù)架構(gòu)設(shè)計(jì)和業(yè)務(wù)架構(gòu)設(shè)計(jì)。技術(shù)架構(gòu)一般由系統(tǒng)軟件商提供，可以在不同的應(yīng)用軟件系統(tǒng)中使用，例如：微軟的MFC， SUN的J2EE等。對于一個(gè)應(yīng)用軟件系統(tǒng)，更重要的是業(yè)務(wù)架構(gòu)的設(shè)計(jì)，也就是將需求分析階段中得到的各種關(guān)系，根據(jù)系統(tǒng)的非功能需求將需求分析轉(zhuǎn)變?yōu)榇a。其實(shí)沒有業(yè)務(wù)架構(gòu)的設(shè)計(jì)也是可以的，很多項(xiàng)目中直接將對象之間的各種關(guān)系以數(shù)據(jù)庫的方式實(shí)現(xiàn)，這樣的系統(tǒng)不是面向?qū)ο蟮?，因此面向?qū)ο笤O(shè)計(jì)的很多好處不能體現(xiàn)。由于在架構(gòu)設(shè)計(jì)階段中沒有進(jìn)一步細(xì)分，通常會(huì)導(dǎo)致不能準(zhǔn)確估計(jì)任務(wù)量，造成項(xiàng)目計(jì)劃變成擺設(shè)。4.詳細(xì)設(shè)計(jì)階段詳細(xì)設(shè)計(jì)階段一個(gè)重要的任務(wù)是系統(tǒng)持久化設(shè)計(jì)。對應(yīng)用系統(tǒng)而言，持久化設(shè)計(jì)只是管理存儲(chǔ)的機(jī)制，有多種技術(shù)手段可以選擇：可以是面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)，簡單的文件，或者是關(guān)系數(shù)據(jù)庫，也可以是使用ORM工具等?？傊畱?yīng)該把它留到最后作為細(xì)節(jié)處理。我們不應(yīng)該將我們的系統(tǒng)和任何特定的技術(shù)綁定在一起。我們可以根據(jù)需求自由選擇需要的持久化技術(shù)，并且保留在將來需要時(shí)更改持久化技術(shù)的自由。5.編碼階段編碼階段還處于小農(nóng)經(jīng)濟(jì)，自給自足，沒有分工合作。編碼階段以use case為粒度安排工作，這樣的安排方式要求每一個(gè)開發(fā)人員必須對表示層，業(yè)務(wù)層，數(shù)據(jù)接入層的所有技術(shù)都要有比較深入的了解，由于每個(gè)開發(fā)人員各自只對自己的use case負(fù)責(zé)，對別人的use case不了解，但是每一個(gè)use case會(huì)有功能重復(fù)的地方，導(dǎo)致大量的重復(fù)工作。編碼階段工作安排的粒度應(yīng)該是類，編碼階段工作的安排原則是先分層，再分割，按照表示層，業(yè)務(wù)層，數(shù)據(jù)訪問層分開后，每一層內(nèi)可以進(jìn)一步分為不同類，使用測試驅(qū)動(dòng)的編程方法，每個(gè)編程人員單獨(dú)編寫代碼，并進(jìn)行單元測試。每個(gè)層次的編程人員只需要對某一種技術(shù)有比較深入的了解。6.測試階段很多人分不清什么是單元測試，什么是集成測試，什么是系統(tǒng)測試？測試的順序是先單元測試，然后是集成測試，最后是系統(tǒng)測試。單元測試是源代碼級的測試，一般由編程人員自己使用各種unit工具測試，是白盒測試。集成測試是在單元測試結(jié)束后，將一個(gè)或若干個(gè)單元作為一個(gè)子系統(tǒng)的黑盒測試，測試子系統(tǒng)內(nèi)的所有組件可以正確的交互，集成測試通過對子系統(tǒng)不斷增加新的單元最后完成整個(gè)系統(tǒng)的測試，集成測試不應(yīng)由開發(fā)人員完成。7.結(jié)束軟件開發(fā)過程中，各種輔助工具以及process很重要，但是使用工具和process的最終目的是為了更高效的在開發(fā)人員之間溝通交流，記錄存在開發(fā)人員腦子里的想法，不要為了process而process。不能以為會(huì)使用MS word，就認(rèn)為可以成為作家。最后引用Robert Martin的《敏捷軟件開發(fā)：原則、模式與實(shí)踐》中的一句話作為本文的結(jié)束：過渡信賴工具和過程以及低估智力和經(jīng)驗(yàn)都是軟件開發(fā)災(zāi)難的源泉。 注： 本文摘自網(wǎng)絡(luò) 臺(tái)州極速網(wǎng)絡(luò)有限公司愿以雄厚的技術(shù)實(shí)力基礎(chǔ)

軟件開發(fā)管理流程圖的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于軟件開發(fā)管理過程、軟件開發(fā)管理流程圖的信息別忘了在本站進(jìn)行查找喔。