軟件開發(fā)流程-論文.doc

精品文檔 畢業(yè)設計（論文）題目：軟件開發(fā)流程管理 班 級： 11工升學 號： 1000303071姓 名： 指導教師： 2014年11月摘 要從軟件開發(fā)最初至今，不斷地有新的軟件開發(fā)技術產生，但是在軟件開發(fā)能力和質量方面卻始終存在達不到預計目標這一問題。每一個軟件開發(fā)的最大目標，就是最大限度提高質量與生產率。而影響質量與生產率的三個關鍵因素：過程、人和技術，因此，我們除了提高技術能力，培養(yǎng)更多優(yōu)質人才之外，還需要制定一套軟件開發(fā)過程管理標準，并在軟件開發(fā)過程中對這一標準不斷地完善，以達到提高軟件質量與生產率的目標。本文結合CMM（軟件過程成熟度模型），對軟件開發(fā)、維護全過程進行標準化、規(guī)范化管理，制定出軟件開發(fā)管理標準。關鍵詞：軟件開發(fā)過程，管理標準目 錄第一章 軟件開發(fā)的概念及目的4第二章 軟件開發(fā)流程劃分及開發(fā)環(huán)境42.1.軟件開發(fā)階段劃分42.2.軟件開發(fā)環(huán)境需求6第三章 軟件開發(fā)過程中存在的問題83.1.對用戶方需求的掌握不全面83.2.對軟件的價值認識不清晰83.3.跟用戶方的合作不順利83.4.開發(fā)隊伍的結構不合理93.5.軟件開發(fā)管理制度不健全93.6.開發(fā)團隊人員不穩(wěn)定9第四章 軟件開發(fā)流程管理規(guī)范104.1.什么是CMM104.2.結合CMM制定開發(fā)流程管理方案114.2.1軟件項目生命周期模型114.2.2需求分析流程圖及描述124.2.3設計流程圖及描述164.2.4編碼流程圖及描述184.2.5測試流程圖及描述194.2.6驗收流程圖及描述22第四章 軟件開發(fā)行業(yè)前景23參考文獻24第一章 軟件開發(fā)的概念及目的軟件開發(fā)是根據(jù)用戶要求建造出軟件系統(tǒng)或者系統(tǒng)中的軟件部分的過程。軟件開發(fā)是一項包括需求捕捉、需求分析、設計、實現(xiàn)和測試的系統(tǒng)工程。軟件一般是用某種程序設計語言來實現(xiàn)的。通常采用軟件開發(fā)工具可以進行開發(fā)。軟件分為系統(tǒng)軟件和應用軟件，并不只是包括可以在計算機上運行的程序，與這些程序相關的文件一般也被認為是軟件的一部分。 軟件設計思路和方法的一般過程，包括設計軟件的功能和實現(xiàn)的算法和方法、軟件的總體結構設計和模塊設計、編程和調試、程序聯(lián)調和測試以及編寫、提交程序。為什么我們會使用軟件開發(fā)？這樣做的目的是為了什么，其中的一個主要原因是向客戶提供價值不斷增長的軟件需求?；镜母驹谟谟脩粜枨蠡蚴袌鰻I銷目標必須創(chuàng)建或轉換成好的軟件應用。所以從本質上講,軟件開發(fā)是它允許最終用戶執(zhí)行他想做的任務。一個繁榮必然導致其他環(huán)節(jié)的上升。因此，許多公司都在提供軟件開發(fā)項目。隨著新開發(fā)過程中對世界的探索,軟件開發(fā)將會無限增長。這是當今世界多少軟件開發(fā)手段。企業(yè)網(wǎng)站建設的應用程序必須提供包括一系列非常復雜的機器不同的目的包括很多行業(yè)類型和幾乎任何你能想到的。第二章 軟件開發(fā)流程劃分及開發(fā)環(huán)境2.1軟件開發(fā)階段劃分軟件開發(fā)一般分為六個階段：1. 問題的定義及規(guī)劃對所要解決的問題進行總體定義，包括了解用戶的要求及現(xiàn)實環(huán)境，從技術、經濟和社會因素等3個方面研究并論證本軟件項目的可行性，編寫可行性研究報告，探討解決問題的方案，并對可供使用的資源（如計算機硬件、系統(tǒng)軟件、人力等）成本，可取得的效益和開發(fā)進度作出估計，制訂完成開發(fā)任務的實施計劃。2. 需求分析軟件需求分析就是對開發(fā)什么樣的軟件的一個系統(tǒng)的分析與設想。它是一個對用戶的需求進行去粗取精、去偽存真、正確理解，然后把它用軟件工程開發(fā)語言（形式功能規(guī)約，即需求規(guī)格說明書）表達出來的過程。本階段的基本任務是和用戶一起確定要解決的問題，建立軟件的邏輯模型，編寫需求規(guī)格說明書文檔并最終得到用戶的認可。需求分析的主要方法有結構化分析方法、數(shù)據(jù)流程圖和數(shù)據(jù)字典等方法。本階段的工作是根據(jù)需求說明書的要求，設計建立相應的軟件系統(tǒng)的體系結構，并將整個系統(tǒng)分解成若干個子系統(tǒng)或模塊，定義子系統(tǒng)或模塊間的接口關系，對各子系統(tǒng)進行具體設計定義，編寫軟件概要設計和詳細設計說明書，數(shù)據(jù)庫或數(shù)據(jù)結構設計說明書，組裝測試計劃。在任何軟件或系統(tǒng)開發(fā)的初始階段必須先完全掌握用戶需求，以期能將緊隨的系統(tǒng)開發(fā)過程中哪些功能應該落實、采取何種規(guī)格以及設定哪些限制優(yōu)先加以定位。系統(tǒng)工程師最終將據(jù)此完成設計方案，在此基礎上對隨后的程序開發(fā)、系統(tǒng)功能和性能的描述及限制作出定義。3. 軟件設計軟件設計可以分為概要設計和詳細設計兩個階段。實際上軟件設計的主要任務就是將軟件分解成模塊是指能實現(xiàn)某個功能的數(shù)據(jù)和程序說明、可執(zhí)行程序的程序單元?？梢允且粋€函數(shù)、過程、子程序、一段帶有程序說明的獨立的程序和數(shù)據(jù)，也可以是可組合、可分解和可更換的功能單元。模塊，然后進行模塊設計。概要設計就是結構設計，其主要目標就是給出軟件的模塊結構，用軟件結構圖表示。詳細設計的首要任務就是設計模塊的程序流程、算法和數(shù)據(jù)結構，次要任務就是設計數(shù)據(jù)庫，常用方法還是結構化程序設計方法。4. 程序編碼軟件編碼是指把軟件設計轉換成計算機可以接受的程序，即寫成以某一程序設計語言表示的“源程序清單”。充分了解軟件開發(fā)語言、工具的特性和編程風格，有助于開發(fā)工具的選擇以及保證軟件產品的開發(fā)質量。當前軟件開發(fā)中除在專用場合，已經很少使用二十世紀80年代的高級語言了，取而代之的是面向對象的開發(fā)語言。而且面向對象的開發(fā)語言和開發(fā)環(huán)境大都合為一體，大大提高了開發(fā)的速度。5. 軟件測試軟件測試的目的是以較小的代價發(fā)現(xiàn)盡可能多的錯誤。要實現(xiàn)這個目標的關鍵在于設計一套出色的測試用例（測試數(shù)據(jù)與功能和預期的輸出結果組成了測試用例）。如何才能設計出一套出色的測試用例，關鍵在于理解測試方法。不同的測試方法有不同的測試用例設計方法。兩種常用的測試方法是白盒法測試對象是源程序，依據(jù)的是程序內部的的邏輯結構來發(fā)現(xiàn)軟件的編程錯誤、結構錯誤和數(shù)據(jù)錯誤。結構錯誤包括邏輯、數(shù)據(jù)流、初始化等錯誤。用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果。白盒法和黑盒法依據(jù)的是軟件的功能或軟件行為描述，發(fā)現(xiàn)軟件的接口、功能和結構錯誤。其中接口錯誤包括內部/外部接口、資源管理、集成化以及系統(tǒng)錯誤。黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。6. 軟件維護維護是指在已完成對軟件的研制（分析、設計、編碼和測試）工作并交付使用以后，對軟件產品所進行的一些軟件工程的活動。即根據(jù)軟件運行的情況，對軟件進行適當修改，以適應新的要求，以及糾正運行中發(fā)現(xiàn)的錯誤。編寫軟件問題報告、軟件修改報告。一個中等規(guī)模的軟件，如果研制階段需要一年至二年的時間，在它投入使用以后，其運行或工作時間可能持續(xù)五年至十年。那么它的維護階段也是運行的這五年至十年期間。在這段時間，人們幾乎需要著手解決研制階段所遇到的各種問題，同時還要解決某些維護工作本身特有的問題。做好軟件維護工作，不僅能排除障礙，使軟件能正常工作，而且還可以使它擴展功能，提高性能，為用戶帶來明顯的經濟效益。然而遺憾的是，對軟件維護工作的重視往往遠不如對軟件研制工作的重視。而事實上，和軟件研制工作相比，軟件維護的工作量和成本都要大得多。在實際開發(fā)過程中，軟件開發(fā)并不是從第一步進行到最后一步，而是在任何階段，在進入下一階段前一般都有一步或幾步的回溯。在測試過程中的問題可能要求修改設計，用戶可能會提出一些需要來修改需求說明書等。2.2軟件開發(fā)環(huán)境需求l 開發(fā)平臺軟件開發(fā)平臺源于繁瑣的實踐開發(fā)過程中。開發(fā)人員在實踐中將常用的函數(shù)、類、抽象、接口等進行總結、封裝，成為了可以重復使用的“中間件”，而隨著“中間件”的成熟和通用，功能更強大、更能滿足企業(yè)級客戶需求的軟件開發(fā)平臺應運而生。平臺是一段時間內科研成果的匯聚，也是階段性平臺期的標志，為行業(yè)進入新的研發(fā)領域提供了基礎。由于平臺對企業(yè)核心競爭力的提升非常明顯，目前國內的管理軟件市場，軟件開發(fā)平臺的應用已經成為一種趨勢。由于開發(fā)環(huán)境、開發(fā)人員、功能定位、行業(yè)背景等的不同，不同品牌的平臺存在較大差別。l 開發(fā)環(huán)境軟件開發(fā)環(huán)境在歐洲又叫集成式項目支持環(huán)境（Integrated Project Support Environment，IPSE）。軟件開發(fā)環(huán)境的主要組成成分是軟件工具。人機界面是軟件開發(fā)環(huán)境與用戶之間的一個統(tǒng)一的交互式對話系統(tǒng)，它是軟件開發(fā)環(huán)境的重要質量標志。存儲各種軟件工具加工所產生的軟件產品或半成品（如源代碼、測試數(shù)據(jù)和各種文檔資料等）的軟件環(huán)境數(shù)據(jù)庫是軟件開發(fā)環(huán)境的核心。工具間的聯(lián)系和相互理解都是通過存儲在信息庫中的共享數(shù)據(jù)得以實現(xiàn)的。軟件開發(fā)環(huán)境數(shù)據(jù)庫是面向軟件工作者的知識型信息數(shù)據(jù)庫，其數(shù)據(jù)對象是多元化、帶有智能性質的。軟件開發(fā)數(shù)據(jù)庫用來支撐各種軟件工具，尤其是自動設計工具、編譯程序等的主動或被動的工作。較初級的SDE數(shù)據(jù)庫一般包含通用子程序庫、可重組的程序加工信息庫、模塊描述與接口信息庫、軟件測試與糾錯依據(jù)信息庫等；較完整的SDE數(shù)據(jù)庫還應包括可行性與需求信息檔案、階段設計詳細檔案、測試驅動數(shù)據(jù)庫、軟件維護檔案等。更進一步的要求是面向軟件規(guī)劃到實現(xiàn)、維護全過程的自動進行，這要求SDE數(shù)據(jù)庫系統(tǒng)是具有智能的，其中比較基本的智能結果是軟件編碼的自動實現(xiàn)和優(yōu)化、軟件工程項目的多方面不同角度的自我分析與總結。這種智能結果還應主動地被重新改造、學習，以豐富SDE數(shù)據(jù)庫的知識、信息和軟件積累。這時候，軟件開發(fā)環(huán)境在軟件工程人員的恰當?shù)耐獠靠刂苹驇椭轮鸩较蚋叨戎悄芘c自動化邁進。軟件實現(xiàn)的根據(jù)是計算機語言。時至今日，計算機語言發(fā)展為算法語言、數(shù)據(jù)庫語言、智能模擬語言等多種門類，在幾十種重要的算法語言中，C&C+語言日益成為廣大計算機軟件工作人員的親密伙伴，這不僅因為它功能強大、構造靈活，更在于它提供了高度結構化的語法、簡單而統(tǒng)一的軟件構造方式，使得以它為主構造的SDE數(shù)據(jù)庫的基礎成分子程序庫的設計與建設顯得異常的方便。事實上，以C#&C+為背景建立的SDE子程序庫能為軟件工作者提供比較有效、靈活、方便、友好的自動編碼基礎，尤其是C+的封裝等特性，更適合大項目的開發(fā)管理和維護。第三章 軟件開發(fā)過程中存在的問題當今社會的軟件工程理論和數(shù)據(jù)庫設計理論為我們提供了各種各樣系統(tǒng)開發(fā)的方法，在開發(fā)實踐過程中也有很多成功的案例，但在實際開發(fā)過程中失敗的個例也是屢見不鮮的。普遍情況是這樣：投入大量人力、物力、財力，開發(fā)出來的系統(tǒng)不符合用戶的需求，需要大量的返工修改，甚至重新開發(fā)。開發(fā)工作進度難以控制，周期一拖再拖，用戶發(fā)怨聲載道，認為開發(fā)方沒有盡心盡力，開發(fā)方也是滿腹牢騷，認為用戶方不配合工作，甚至有些已經驗收的項目在投入實際使用的過程中被棄用了，這樣就造成了很大的浪費。那么在軟件開發(fā)過程中，究竟產生哪些方面的問題呢？下面我們就來探討。3.1對用戶方需求的掌握不全面目前國內的軟件開發(fā)企業(yè)的規(guī)模都不大，開發(fā)團隊需要承擔的工作量多且繁重，企業(yè)在接了項目之后，馬上組織團隊開發(fā)，在盡可能短的時間內完成項目任務，將資金收回。這種短、平、快，急功近利的運作方式，導致我們在對用戶的業(yè)務需求認識還不夠充分之前，就開始編程，加上很多用戶對需要提供也不重視不專業(yè)，導致軟件開發(fā)過程中頻繁的調整，調試運行和維護期間的工作多是“打補丁”。3.2對軟件的價值認識不清晰由于目前國內的IT產業(yè)還處于起步階段，軟件價值及其在計算機技術應用中的核心作用還未被認識，目前國內保護知識產權的意識不強，相關法律也不很健全，軟件業(yè)盜版猖獗，使得廣大用戶不愿意購買價格相對高的正版軟件，更不愿意投入較大的財力開發(fā)應用軟件，導致軟件項目投入過低或在計算機相關的工程中軟硬件投入比列失調，自然無法保護軟件的開發(fā)質量。3.3跟用戶方的合作不順利用戶方在軟件開發(fā)過程中一般會指定人員來配合開發(fā)方的工作。對一些有計算機專業(yè)人員的用戶單位，在計算機行業(yè)飛速發(fā)展的形勢下，他們的知識結構與目前的信息技術發(fā)展已有了一定的距離，所提出的對軟件的要求或者太空泛，或者過于計較某些細節(jié)。還有，一些用戶單位在出資購置軟件后，軟件開發(fā)過程中根本不給予開發(fā)方有力的配合，甚至還認為開發(fā)工作室開發(fā)方一家的事情，他們只管用，不參與開發(fā)工作，他們對于購買軟件的觀念還是“我出錢買你的東西，買來就得好用”。3.4開發(fā)隊伍的結構不合理目前，大多數(shù)的軟件開發(fā)單位，缺少優(yōu)秀的系統(tǒng)分析員和項目 管理人員，缺少由項目管理員、系統(tǒng)分析員、程序員等組成的良好的開發(fā)隊伍結構，往往有項目了就臨時組織一個軟件開發(fā)小組，小組成員沒有工作層次上的分工，更沒有管理和具體技術工作的分工。全體人員從事基本相同的工作，每人分工負責一塊，然后從用戶需求、系統(tǒng)設計、具體編程到測試，文檔編寫統(tǒng)統(tǒng)一做到底，各干各的，項目小組的負責人也往往是程序員出身，沒有受過項目管理的專業(yè)培訓，更沒有項目管理的經驗，當然也不能真正較完滿地起到項目的管理、協(xié)調作用。大多數(shù)的系統(tǒng)分析員也多是程序員出身，雖然有參加過或大或小項目的經驗，可實際上他們是一邊學習最新的計算機技術的理論，一邊結合自己的編程和做項目的經驗來做分析做設計。在沒有系統(tǒng)的符合實際的理論知識指導的情況下，我們的很多項目都面臨著管理上的問題，至少不能取得高效率的投入產出。3.5軟件開發(fā)管理制度不健全主要表現(xiàn)在項目開發(fā)計劃制定不明確，項目開發(fā)小組成員職責不明確。開發(fā)方與用戶方的分工協(xié)作的工作沒有很好的界定。開發(fā)過程中每個環(huán)節(jié)的管理不到位，沒有制定相應的管理規(guī)范和操作程序的工作，基本上還是手工作坊式的個體行為?，F(xiàn)今軟件開發(fā)，特別是大型軟件的開發(fā)是高度集中的集體行為，要有團隊精神，一個單打獨斗的個人英雄時代已經過去，但是，很多開發(fā)人員在軟件開發(fā)中，既不做整體設計規(guī)劃，也不寫文檔，只會寫程序，沒有規(guī)范性的整體開發(fā)思路，這樣開發(fā)出的軟件程序往往與個人捆綁，既沒有通用思路，也很難協(xié)同開發(fā)整個產品，更不用說是大型軟件。有時候一個人的離去，可能影響整個軟件產品的開發(fā)，甚至導致產品的早期流產。軟件作為成熟的產品，一般要經歷前期調研、總體設計、編程開發(fā)三個過程，前期調研和設計完成以后，最后的開發(fā)也就是寫程序，而當調研和設計較為全面和成熟后，寫程序則是一個并不是很復雜的問題。3.6開發(fā)團隊人員不穩(wěn)定由于目前社會對IT技術人才需求缺口較大，各類企業(yè)紛紛高薪招聘有一定實踐經驗的IT技術人才，加之企業(yè)與國外公司較大的收入差距，致使很多企業(yè)參加過大型計算機應用系統(tǒng)建設的計算機技術人員大量跳槽流失，這種流失造成了很多國內企業(yè)成為事實上的人才培訓基地，無法形成持續(xù)強有力的開發(fā)力量。因骨干開發(fā)人員流失致使軟件項目開發(fā)、維護受到影響的事例也時有發(fā)生。第四章 軟件開發(fā)流程管理規(guī)范軟件開發(fā)團隊應具有使軟件開發(fā)過程實現(xiàn)標準化的能力。如果開發(fā)團隊不能使得軟件開發(fā)過程實現(xiàn)標準化，則該團隊是不能承擔軟件開發(fā)任務的。美國卡耐基梅隆大學軟件工程研究所創(chuàng)立了軟件能力成熟度模型（CMM）對軟件開發(fā)、維護全過程進行標準化、規(guī)范化管理。4.1什么是CMM能力成熟度模型（Capability Maturity Model，英文縮寫為CMM）1 是 一種開發(fā)模型。Carnegie Mellon大學的研究人員從美國國防部合同承包方那里收集數(shù)據(jù)并加以研究，提出了CMM。美國國防部資助了這項研究。Carnegie Mellon以該模型為基礎，創(chuàng)辦了軟件工程研究所（SEI）。CMM的目標是改善現(xiàn)有軟件開發(fā)過程，也可用于其它過程。CMM是一種用于評價軟件承包能力以改善軟件質量的方法，側重于軟件開發(fā)過程的管理及工程能力的提高與評估。分為五個等級：一級為初始級，二級為可重復級，三級為已定義級，四級為已管理級，五級為優(yōu)化級。其假設是：只要集中精力持續(xù)努力去建立有效的軟件工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟件生產中的困難。4.2.結合CMM制定開發(fā)流程管理方案4.2.1軟件項目生命周期模型4.2.2需求分析流程圖及描述需求分析EPG部門經理PM測試負責人臨時項目組QA客戶輸入/輸出5、審批裁剪1、組建臨時項目組開始6、確定項目管理機制3、建立配置庫表2、制定需求階段日程表9、評審架構設計書/需求規(guī)格書4、申請裁剪11、確定項目目標范圍7、編寫需求清單列表8、確定系統(tǒng)架構編寫需求規(guī)格書10、確認需求規(guī)格書需求清單列表項目裁剪表14、協(xié)調人員及資源結束19、建立階段基線20、階段總結17、編制項目日程表16、編制項目計劃書13、確定項目關鍵參數(shù)12、項目估算15、建立工作環(huán)境18、評審項目計劃書需求分析階段總結報告需求分析階基線項目日程表項目計劃書規(guī)模估算表/項目估算表過程描述：1、 由部門經理組建臨時項目組，并指定PM、開發(fā)人員、測試人員、QA，人數(shù)根據(jù)項目規(guī)模確定。2、 PM制定需求階段日程表，該表須通過研發(fā)經理審核。3、 PM指示配置管理員建立配置庫。4、 由PM與測試負責人提出裁剪申請，QA指導臨時項目組人員對項目進行裁剪，形成項目裁剪表。5、 EPG和部門經理對裁剪結果進行審批，審批通過項目裁剪表正式生效。6、 PM與測試負責人確定項目管理機制，內容包括組織結構、溝通、跟蹤、報告、風險管理、問題管理、QA、CM等。7、 項目組人員與客戶進行溝通，編寫需求清單列表。8、 PM組織臨時項目組成員確定系統(tǒng)架構，編寫架構設計書和需求規(guī)格書。架構設計過程中的重要的技術方案選擇、開發(fā)/采購/復用分析等內容要明確體現(xiàn)在架構設計書中。 對技術方案選擇（例如，系統(tǒng)結構、開發(fā)平臺、數(shù)據(jù)庫等的選擇），要事先建立評價準則（例如，滿足系統(tǒng)需求的能力（例如，功能、性能、可靠性等）、技術的發(fā)展前景、供應商資質與實力等）及相對優(yōu)先級，采用討論表決的方法選擇并確定最終的技術方案。 關于自行開發(fā)和采購復用的分析。如果公司有基本滿足系統(tǒng)需要的可復用組建（包括其分析、設計、代碼、測試用例等），一般應進行復用；本公司沒有能力開發(fā)或沒有必要開發(fā)的非核心技術部分，如果采購成本在項目可接受范圍內，可考慮采購；否則，由項目組自行開發(fā)。架構設計的總體候選方案選擇和供應商選擇要使用正式的方法做決策。9、 PM召集臨時項目組、測試負責人等技術骨干評審架構設計書和需求規(guī)格書。10、PM組織臨時項目組與客戶溝通、說明需求，必要時編制系統(tǒng)原型向客戶展示，直到臨時項目組、客戶就需求的真實含義達成共識、客戶書面確認要求規(guī)格書為止。11、臨時項目組確定項目目標的范圍，明確系統(tǒng)邊界，建立系統(tǒng)的模塊分解結構。12、PM與測試負責人遵循項目估算流程組織人員進行項目估算。13、PM、測試負責人與臨時項目組確定項目關鍵參數(shù)。 工作量、工期、日程、人數(shù) 成本/預算（由于本公司的項目的絕大部分成本是人力成本，對估計成本的管理等同于估計工作量的管理，對實際成本的管理等同于實際工作量的管理，對預算的管理等同于計劃工作量的管理） 質量目標14、PM、測試負責人與部門經理協(xié)調人員及資源、計劃知識技能、協(xié)調相關干系人的參與。15、項目組基于公司環(huán)境標準，結合項目實際情況建立合適的工作環(huán)境。16、PM、測試負責人編制項目計劃書。17、PM、測試負責人編制項目日程表。18、臨時項目組、研發(fā)部、QA評審項目計劃書，評審通過后正式生效。19、PM指示配置管理員建立配置基線。20、PM編制階段總結報告（項目總結報告中的度量分析頁面），召開階段會議。4.2.3設計流程圖及描述PM項目組配置管理員輸入/輸出1、組織項目組成員學習需求調研報告開始B、架構設計書A、需求規(guī)格書9、組織召開階段會議6、組織人員評審設計文檔5、系統(tǒng)外圍設計3、系統(tǒng)功能設計2、組織人員明確設計約束結束8、建立階段基線H、會議紀要C、設計說明書過程描述：1）項目經理組織項目組人員學習需求規(guī)格書；2）項目經理組織項目組中的開發(fā)人員確定設計約束，這些約束可能包括以下幾個方面： 需求約束，需求規(guī)格書中約定的設計約束； 隱含約束，需求規(guī)格書中沒有，但對系統(tǒng)設計或者使用帶來潛在影響的特殊約束。3）項目經理及開發(fā)人員根據(jù)需求規(guī)格書、架構設計書進行設計，編制設計說明書。 基于對業(yè)務和現(xiàn)有系統(tǒng)結構的理解，劃分/調整系統(tǒng)模塊。 描述各系統(tǒng)模塊協(xié)作實現(xiàn)各業(yè)務場景的處理流程（可用序列圖）。 必要時，修正系統(tǒng)模塊劃分和處理流程。 描述各處理流程中的各活動的輸入、處理、輸出和可能的異常。 系統(tǒng)模塊構成及其相互關系。 系統(tǒng)模塊內部設計4）開發(fā)人員根據(jù)需求規(guī)格書、架構設計書進行設計、設計說明書進行用戶界面和數(shù)據(jù)庫以及接口等方面的詳細設計，納入設計說明書。 用戶界面設計 數(shù)據(jù)庫設計 文件設計 接口設計5）項目經理組織開發(fā)人員、測試人員及其他骨干評審設計說明書。6）配置管理員建立設計階段配置基線7）項目經理編制階段報告，組織項目組人員并邀請部門經理召開階段會議，并形成會議紀要。4.2.4編碼流程圖及描述輸入開發(fā)人員輸出編碼規(guī)范界面規(guī)范設計說明書結束開始（8）編寫階段報告（7）進行聯(lián)調（6）評審代碼（5）編碼及調試（4）開發(fā)環(huán)境配置（3）培訓編碼、界面規(guī)范（2）審核詳細類圖（1）繪制詳細類圖階段報告代碼文件詳細類圖過程描述：a) 根據(jù)準入條件中的設計文檔，繪制詳細類圖，以指導編碼。b) 對生成的類圖進行審核。c) 項目經理組織開發(fā)人員學習編碼規(guī)范、用戶界面規(guī)范，以保障程序的可靠性、可讀性、可修改性、可維護性、一致性以及界面的規(guī)范性。d) 開發(fā)環(huán)境的配置項目經理或其他指定人員在公司的開發(fā)環(huán)境指南的基礎上編制開發(fā)環(huán)境配置說明，項目組成員遵照開發(fā)環(huán)境配置說明配置統(tǒng)一的開發(fā)環(huán)境。e) 編寫及調試f） 審評代碼g) 進行自測h) 編寫階段報告4.2.5測試流程圖及描述開發(fā)人員PM測試負責人測試人員輸入/輸出4、評審測試方案、測試用例5、負責測試方案、測試用例等文檔入庫6、召開階段會議開始1、學習、評審學習用戶需求列表、需求規(guī)格書結束3、編寫測試用例2、編寫測試方案測試用例測試方案需求規(guī)格書用戶需求列表過程描述：1. 測試負責人組織測試人員學習、評審用戶需求列表、需求規(guī)格書。在學習、評審過程中充分理解客戶及業(yè)務需求，確保文檔信息的正確性、充分性、一致性。2. 測試負責人組織測試人員完成編寫整個項目的測試方案。3. 測試負責人組織測試人員基于需求規(guī)格書編寫測試用例。設計說明書通過評審后，測試人員基于設計說明書對測試用例進行必要的調試。測試用例的組織分類須遵循以下原則： 測試用例的組織分類（例如，文檔名、頁面名、一級標題、二級標題等）必須與需求規(guī)格書中的各需求點明確對應起來。4. 測試負責人組織測試人員、開發(fā)人員、PM評審測試方案、測試用例。5. 測試負責人指示配置管理員將測試方案及測試用例文檔入庫。6. 測試負責人組織PM、開發(fā)人員、測試人員召開階段會議形成階段報告。4.2.6驗收流程圖及描述項目經理客戶代表客服人員測試人員開發(fā)人員CM輸出（12）整理項目數(shù)據(jù)（11）客戶驗收并交付使用（6）分派缺陷處理責任（5）匯總缺陷（1）溝通驗收事項結束（4）開展試運行（3）對客戶進行培訓（2）產品安裝調試（9）回歸測試（8）缺陷修復確認（10）更新試運行版本（7）分析、解決缺陷循環(huán)（13）整理工作產品驗收缺陷跟蹤表結束（15）召開總結會議（14）項目總結（16）歸檔總結報告過程描述：1) 項目經理與客服人員溝通驗收事項。2) 客服人員在客戶指定的環(huán)境下參照安裝維護手冊進行產品安裝調試，并把合同約定的文檔、源程序等交給客戶。3) 客服人員對客戶進行系統(tǒng)操作方法培訓。4) 客戶試用系統(tǒng)開展業(yè)務，測試人員收集客戶反饋的問題；如果客戶驗收測試環(huán)境與生產環(huán)境差異明顯時，要進行性能測試，以保證滿足系統(tǒng)性能需求。5) 測試人員在驗收中發(fā)現(xiàn)缺陷并告知項目經理，項目經理將缺陷記錄到BugFree中。某些情況下（例如，缺陷描述不詳、明顯不是缺陷等）項目經理可以向相關人員（測試人員、客戶）解釋、說明，達成一致后駁回相關人員（測試人員、客戶）提出的問題。6) 項目經理將缺陷分派給適合的開發(fā)人員。7) 開發(fā)人員分析缺陷的原因及解決該缺陷，并將該缺陷的解決方法及解決狀態(tài)更新BugFree。8) 項目經理將所有已處理的缺陷轉移至測試人員進行缺陷修復的確認。9) 在更新驗收版本之前，測試人員要進行一次回歸測試。對即將發(fā)布的新版本，進行一次整體的測試。10) 驗收中發(fā)現(xiàn)的缺陷累積到一定程度或嚴重缺陷導致驗收無法繼續(xù)時，應更新驗