項目開發(fā)流程介紹.ppt

項目開發(fā)流程,目錄,團隊組建與項目計劃 需求管理與配置管理 項目規(guī)范與軟件設(shè)計 軟件測試 驗收交付與過程改進,確定分組和小組分工 確定設(shè)計項目所用的工具和技術(shù) 制定系統(tǒng)開發(fā)計劃,了解團隊在軟件開發(fā)過程中的重要作用 了解常見軟件開發(fā)團隊的角色和分工 學(xué)會制定軟件開發(fā)計劃的原則、方法,需要解決的問題,假如，現(xiàn)在的你正在參加面試，面試官問你如下問題 你能讀懂項目計劃么？ 你有過團隊開發(fā)經(jīng)驗么？ 你能讀懂需求規(guī)格說明書么？ 你對測試了解多少，會寫測試用例么？ 你用Java/.NET做過中小型項目開發(fā)么？ 請你說說一個項目中都應(yīng)該有哪些規(guī)范？ 你做過設(shè)計么，如果做過談?wù)勥@些設(shè)計吧？ ,項目的特征 項目的一次性 一次性是項目區(qū)別其他任務(wù)的基本特征 項目目標(biāo)的明確性 成果性目標(biāo) 約束性目標(biāo) 項目的整體性 項目是為實現(xiàn)目標(biāo)而開展任務(wù)的集合，不是一項項孤立的活動,1、項目的一次性。一次性是項目區(qū)別其它任務(wù)（比如：組裝汽車）的基本特征。這意味著每個項目都有它的特殊之處，不存在兩個完全相同的項目。 2、項目目標(biāo)的明確性。項目作為一類特別設(shè)立的活動有其明確的目標(biāo)，一般由成果目標(biāo)和約束性目標(biāo)組成。其中，成果性目標(biāo)是項目的來源（比如：給中國電信的一套計費系統(tǒng)）；約束性目標(biāo)又稱限制條件，是實現(xiàn)成果性目標(biāo)的客觀條件（比如：項目開發(fā)過程中要遵循國家法律法規(guī)）和人為約束目標(biāo)（比如：項目組成員的去留和項目的最后期限）的統(tǒng)稱，是項目實施過程中必須遵守的條件，從而成為項目實施過程中的主要目標(biāo)。 3、項目的整體性。項目是為實現(xiàn)目標(biāo)而開展任務(wù)的集合，它不是一項項孤立的活動，而是一系列活動的有機組合，從而形成一個完整的過程。強調(diào)項目的整體性也就是強調(diào)項目的過程性和系統(tǒng)性。 項目的屬性是項目所固有的，是區(qū)別于其它活動的根本原因。,常見的軟件開發(fā)團隊組織形式,1、小型軟件公司團隊組織結(jié)構(gòu),2、微軟公司團隊組織結(jié)構(gòu),3、大型軟件公司團隊組織結(jié)構(gòu),第一種：小型軟件公司團隊組織結(jié)構(gòu)。如圖1.7所示，在小型軟件公司中，人員配置精簡實用。由項目經(jīng)理直接帶領(lǐng)開發(fā)經(jīng)理、質(zhì)量保證工程師、開發(fā)工程師和測試工程師來完成項目。 這種組織結(jié)構(gòu)的好處在于分工靈活，但同時每個人也是一個“多面手”，例如，開發(fā)經(jīng)理既要有很強的技術(shù)，也要有相應(yīng)的管理經(jīng)驗；開發(fā)工程師除了進行程序開發(fā)，也要懂得數(shù)據(jù)庫設(shè)計開發(fā)，并且要了解一些軟件測試知識。而且通常是一個人擔(dān)負(fù)多個角色，團隊中的每個人幾乎都要擔(dān)負(fù)開發(fā)工程師和測試工程師的職責(zé)。 第二種：微軟公司團隊組織結(jié)構(gòu)。如圖1.8所示，微軟公司的團隊組織結(jié)構(gòu)可以說是相當(dāng)完善了，這種組織結(jié)構(gòu)中，各團隊人員分工很細(xì)致，而且權(quán)責(zé)明確，人員之間的接口明確。只是構(gòu)建這種項目團隊的成本太高。 第三種：大型軟件公司團隊組織結(jié)構(gòu)。如圖1.9，這種組織結(jié)構(gòu)中，人員配置比較齊備，計劃/需求/設(shè)計/開發(fā)/測試/驗收各個階段都有專人負(fù)責(zé)。但同時人員組織分成了四層，給管理上增加了困難。,建議采取的團隊結(jié)構(gòu),每小組45人 小組所有成員都擔(dān)任開發(fā)工程師和測試工程師職責(zé) 每小組都設(shè)置一個項目經(jīng)理（小組長）、開發(fā)經(jīng)理（技術(shù)負(fù)責(zé)人）和一個質(zhì)量保障工程師（負(fù)責(zé)版本控制工具CVS/SVN/VSS的使用）,我們將采用第一種，既小型軟件公司團隊組織結(jié)構(gòu)。其中每個角色的職責(zé)定義為： 項目經(jīng)理（PM，Project Manager）：項目負(fù)責(zé)人。一般來講，項目經(jīng)理的職責(zé)包括：承擔(dān)責(zé)任；需求管理；協(xié)調(diào)、組織、解決團隊問題；控制進度，獲取并調(diào)配資源（分配任務(wù)）；召集會議；做出決定；風(fēng)險控制，解決危機；考核團隊成員。在我們的畢業(yè)設(shè)計中，項目經(jīng)理（小組長）要協(xié)調(diào)組織大家完成項目，定期檢查大家的進度等。 開發(fā)經(jīng)理（TTL，Team technology Leadr）：技術(shù)負(fù)責(zé)人。一般開發(fā)經(jīng)理的職責(zé)包括：架構(gòu)設(shè)計（技術(shù)決策）；參與需求管理；在技術(shù)上訓(xùn)練并指導(dǎo)團隊；召集技術(shù)會議；組織團隊培訓(xùn)；記錄團隊成員技能提升等。在我們的畢業(yè)設(shè)計項目中，開發(fā)經(jīng)理要主動幫助技術(shù)上有困難的同學(xué)，但不能幫他做。 質(zhì)量保證工程師（QA, Quality Assessment）：一般負(fù)責(zé)配置管理，有效地控制各種項目文檔和代碼當(dāng)前版本的唯一性；按照發(fā)布計劃獲得并發(fā)布版本，提交測試；過程控制和質(zhì)量保證等。 開發(fā)工程師（SE，Software Engineer）：按照需求規(guī)格說明書的描述和項目規(guī)范開發(fā)程序代碼，實現(xiàn)功能，修正開發(fā)過程中產(chǎn)生的缺陷。 測試工程師（TE，Testing Engineer）：根據(jù)需求規(guī)格說明書的描述和項目規(guī)范對發(fā)布的版本軟件進行黑盒測試，發(fā)現(xiàn)并報告軟件缺陷，督促開發(fā)工程師修正缺陷。,制定項目計劃的二個原則,有效追蹤原則（任務(wù)點劃分） 對任務(wù)進行有效分解 粒度適中（一般控制在13個人日） 共同參與原則 不是PM一個人的事 共同估計工作量，并作出承諾,財務(wù)管理系統(tǒng) 任務(wù)點劃分 費用管理 所有費用 增加收入 增加支出 費用類型 報銷人 費用統(tǒng)計 用戶管理 增加用戶 登陸信息,本章任務(wù),畫出“財務(wù)管理系統(tǒng)”用例圖 使用用例的方式準(zhǔn)確描述“權(quán)限管理系統(tǒng)”需求 使用CVS或SVN管理項目文檔,前置條件：用戶（包含普通用戶和系統(tǒng)管理員）在系統(tǒng)首頁輸入用戶名和密碼。 事件流： 用戶在系統(tǒng)首頁輸入用戶名和密碼，點擊“登錄”按鈕時用例開始。 后置條件：“會話”（session）中保存了已登錄用戶的信息及其擁有的權(quán)限。,學(xué)會用例圖的畫法 學(xué)會使用用例的方式描述軟件需求 學(xué)會使用靜態(tài)原型法定義軟件需求 了解配置管理的概念和重要意義 學(xué)會使用CVS/SVN進行版本控制,為什么要做需求管理,1、客戶知道自己要什么，但表達不清。有時候客戶有自己的IT團隊，這時候情況稍好，大家講相同的“語言”溝通會相對順暢。但很多時候，客戶知道哪些數(shù)據(jù)和信息需要通過系統(tǒng)管理，需要系統(tǒng)給業(yè)務(wù)什么樣的支持，但他們只能用自己行業(yè)的語言來表達。這時候首先需要我們對其行業(yè)和業(yè)務(wù)都要有一個理解，然后我們才可以設(shè)計信息系統(tǒng)，并給客戶確認(rèn)。 任何一個具有一定規(guī)模的信息化系統(tǒng)都會涉及很多人，很多崗位和角色。在調(diào)研的時候，對這些人我們都需要訪談。每個崗位都有自身的立場、眼界和利益，對系統(tǒng)需求的描述也會出現(xiàn)相左的情況。這也是需要權(quán)衡處理的。 2、客戶不知道自己要什么。有的時候，客戶期望通過信息化系統(tǒng)提高企業(yè)的效率。但具體怎么做就了解不多了。這時候需要我們?nèi)ブ鲃拥匕l(fā)掘需求，同時需要我們的行業(yè)經(jīng)驗來支撐。 所以，我們要做需求管理。 在軟件生命周期中，計劃完成后，第一項實質(zhì)性的階段就是需求階段。在需求階段結(jié)束的時候，我們需要得到一個準(zhǔn)確的，經(jīng)過客戶確認(rèn)的需求規(guī)格說明書,需求規(guī)格說明書概念 軟件開發(fā)項目中用于明確定義系統(tǒng)需求的文檔。 需求規(guī)格說明書的作用 開發(fā)者與用戶間事實上的技術(shù)合同書 開發(fā)者下一步設(shè)計和編碼的基礎(chǔ) 測試驗收目標(biāo)系統(tǒng)的依據(jù),功能性需求：用來描述系統(tǒng)所應(yīng)提供的功能和服務(wù) 系統(tǒng)功能 輸入輸出 異常 非功能性需求：不直接與系統(tǒng)的具體功能相關(guān)的一類需求 安全性 可擴展性 響應(yīng)時間,1、功能性需求 簡單地說，功能性需求用來描述系統(tǒng)所應(yīng)提供的功能和服務(wù)。包括系統(tǒng)應(yīng)該提供的服務(wù)、對輸入如何響應(yīng)及特定條件下系統(tǒng)行為。對于用戶需求（客戶對系統(tǒng)的要求），用較為一般的描述給出；對于功能性的系統(tǒng)需求，需要詳細(xì)地描述系統(tǒng)功能、輸入和輸出、異常等有時，功能需求還包括系統(tǒng)不應(yīng)該做的事情。功能需求取決于軟件的類型、軟件的用戶及系統(tǒng)的類型等。 系統(tǒng)的功能性需求應(yīng)該具有全面性和一致性。全面性意即應(yīng)該對用戶所需要的所有服務(wù)進行描述，而一致性則指需求的描述不能前后自相矛盾。在復(fù)雜的大型系統(tǒng)中，做到這兩點會有一定困難。但只有做到了這兩點，才能保障我們項目的順利進行。,2、非功能性需求 非功能需求是指那些不直接與系統(tǒng)的具體功能相關(guān)的一類需求，它們與系統(tǒng)的總體特征相關(guān)，如可靠性、可擴展性、安全性、響應(yīng)時間等，甚至包括界面易用程度和文檔、代碼規(guī)范性的要求。非功能需求定義了對系統(tǒng)提供的服務(wù)或功能的約束，包括時間約束、空間約束、開發(fā)過程約束及應(yīng)遵循的標(biāo)準(zhǔn)等。它源于用戶的限制，包括預(yù)算的約束、機構(gòu)政策、與其他軟硬件系統(tǒng)間的互操作，以及如安全規(guī)章、隱私權(quán)保護的立法等外部因素。 與關(guān)心系統(tǒng)個別特性的功能需求相比，非功能需求關(guān)心的是系統(tǒng)的整體特性，因此對于系統(tǒng)來說，非功能需求更關(guān)鍵。一個功能需求得不到滿足會降低系統(tǒng)的能力，但一個非功能需求得不到滿足則有可能使系統(tǒng)無法運行。 非功能需求不僅與軟件系統(tǒng)本身有關(guān)，還與系統(tǒng)的開發(fā)過程有關(guān)。與開發(fā)過程相關(guān)的需求包括：對在軟件過程中必須使用的質(zhì)量標(biāo)準(zhǔn)的需求、設(shè)計中必須使用的建模工具的需求以及軟件過程所必需遵守的原則等。,用例概念 描述系統(tǒng)有哪些人用，和每個人是怎么用的 用例是一種溝通工具 最終用戶和開發(fā)人員使用它進行交流，并在系統(tǒng)需求上達成共識 用例需要回答的問題 這個系統(tǒng)涉及哪些人？他們對系統(tǒng)有什么期望？,用例是什么？其原始英文是usecase，直譯過來就成了用例，從字面的直接理解就是使用的例子。用例的定義是：與系統(tǒng)使用者交互的，并且給使用者提供可觀測的有意義的結(jié)果的一系列活動的集合。簡單的說，用例描述了這個系統(tǒng)有哪些人要用，和每個人是怎么用的。 用例常被用來描述一個系統(tǒng)外在可見的需求情況，常被用作項目的需求分析階段，對項目的測試計劃和用戶指南也有用處。他們被用來創(chuàng)建和驗證被提議的設(shè)計，并確保該設(shè)計滿足所有的需求。 這里，我們使用用例描述系統(tǒng)功能性需求。,為什么要做配置管理,在實際的項目開發(fā)中 工作成果被覆蓋了該怎么辦？ 時間一長，文件版本太多，該如何維護？ 兩人同時修改了一個程序文件，會不會打架？,對小組成員各自承擔(dān)的代碼統(tǒng)一管理 項目開發(fā)小組的成員之間不會發(fā)生代碼修改沖突 對項目小組各成員所作的修改進行統(tǒng)一匯總 保留修改的軌跡，以便撤銷錯誤的改動 對項目過程中代碼的各個版本進行管理,常用的配置管理工具,VSS（Visual SourceSafe） CVS（Concurrent Version System） SVN（Subversion）,了解項目規(guī)范對軟件開發(fā)的重要作用 學(xué)習(xí)數(shù)據(jù)庫規(guī)范、編碼規(guī)范和用戶界面規(guī)范 確定設(shè)計將采用的技術(shù)框架,了解常見的數(shù)據(jù)庫規(guī)范和編碼規(guī)范 了解詳細(xì)設(shè)計和概要設(shè)計階段的主要工作 會按照模板編寫詳細(xì)設(shè)計文檔 會畫類圖，能讀懂時序圖,什么是項目規(guī)范？ 定義： 項目規(guī)范是一系列標(biāo)準(zhǔn)，規(guī)定代碼中的變量如何定義，注釋如何編寫，數(shù)據(jù)庫表如何設(shè)計，界面如何組織等。 要點： 范圍：軟件項目中 要求：所有項目組成員都要嚴(yán)格遵守 目的：統(tǒng)一項目組行為，統(tǒng)一項目產(chǎn)品規(guī)格 內(nèi)容：一系列規(guī)則，包括：數(shù)據(jù)庫規(guī)范、編碼規(guī)范、用戶界面規(guī)范、測試規(guī)范、評審規(guī)范等,常見項目規(guī)范 (1),數(shù)據(jù)庫規(guī)范 數(shù)據(jù)庫設(shè)計規(guī)范 原則上符合第三范式 必要時可違反第三范式 數(shù)據(jù)庫命名規(guī)范 視圖名稱 存儲過程名稱 表名稱 例：表名稱 = 表名前綴 + 下劃線“_” + 表內(nèi)容標(biāo)識 系統(tǒng)用戶信息表 sys_user_info,編碼規(guī)范 命名風(fēng)格 換行縮進的風(fēng)格 其它 每個類不超過200行 每行不超過60字符 所有Action Bean繼承自BaseAction，放在com.cstp.web.action包下等,需要注意的是，編碼規(guī)范不僅限于命名規(guī)則、縮進和換行、注釋。有時候還包括程序結(jié)構(gòu)方面的規(guī)定，比如：實體類放在什么包下，一個規(guī)范的實體類是什么樣子的；DAO層的類包含哪些方法，不應(yīng)該包含什么樣的方法；業(yè)務(wù)邏輯層的代碼中可以放什么的代碼，絕對不允許放什么樣的代碼；Action代碼中不允許描述業(yè)務(wù)邏輯等。,用戶界面規(guī)范 界面展現(xiàn)規(guī)范 界面風(fēng)格要一致 例如：統(tǒng)一的色調(diào)、統(tǒng)一的字體字號 特定內(nèi)容的展現(xiàn)格式要一致 例如：日期的格式、數(shù)字的格式 交互方式的規(guī)范 操作風(fēng)格要一致 例如：“*”表示必輸項 特定內(nèi)容的輸入格式要統(tǒng)一 例如：日期以1982-02-22 的格式輸入,概要設(shè)計 系統(tǒng)設(shè)計：系統(tǒng)具體的技術(shù)方案，與其他系統(tǒng)的接口方式 系統(tǒng)設(shè)計需要考慮到： 硬件環(huán)境、軟件環(huán)境、網(wǎng)絡(luò)環(huán)境 用戶操作水平 團隊技術(shù)能力 開發(fā)時間限制 結(jié)構(gòu)設(shè)計：確定程序是由哪些模塊組成的，各模塊分別完成什么樣的功能，它們之間存在著什么樣的關(guān)系。,軟件詳細(xì)設(shè)計(1),詳細(xì)設(shè)計的核心是將業(yè)務(wù)模型映射到技術(shù)模型 業(yè)務(wù)模型 技術(shù)模型 執(zhí)行 select book_name from sys_book where book_no = 書籍編號 and book_status = 已預(yù)訂 and book_subscribe_stu_no 學(xué)生借書卡編號。如果查詢到1條記錄，則拋出異常，異常信息為：“圖書圖書名稱已經(jīng)被預(yù)訂，不能借出?！?；否則，繼續(xù)處理。,學(xué)生到圖書館申請借書，圖書管理員登錄圖書管理系統(tǒng)。首先， 檢查這本書是否已經(jīng)被預(yù)訂了，如果已被預(yù)訂則不能借出。,詳細(xì)設(shè)計還包括 實現(xiàn)某一功能時，具體包含哪些類、方法、類。以及類之間的關(guān)系和調(diào)用順序 對應(yīng)的界面如何展示，如何交互，界面間如何切換 核心算法的偽代碼 數(shù)據(jù)庫設(shè)計的工作,軟件詳細(xì)設(shè)計-類圖,詳細(xì)設(shè)計中的類圖 圖中每一個方框表示一個類（或接口），分成三格 第一格：類的名字 第二格：類的屬性 第三格：類的方法 空三角箭頭：實現(xiàn)關(guān)系 虛線箭頭：依賴關(guān)系,基于框架開發(fā),在軟件項目開始編碼前，我們已經(jīng)準(zhǔn)備好了： 需求規(guī)格說明書 項目規(guī)范 概要設(shè)計 詳細(xì)設(shè)計 項目框架 我們現(xiàn)在需要做的就是：導(dǎo)入框架代碼，調(diào)試通過。然后直接在此基礎(chǔ)上按照需求規(guī)格說明書，嚴(yán)格遵守項目規(guī)范寫代碼 。,建立軟件質(zhì)量觀念 了解軟件測試的意義和方法 學(xué)會編寫測試用例 了解缺陷管理的流程,軟件缺陷的定義 軟件未達到產(chǎn)品說明書中已經(jīng)標(biāo)明的功能 軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤 軟件未達到產(chǎn)品說明書中雖未指出但應(yīng)當(dāng)達到的目標(biāo) 軟件功能超出了產(chǎn)品說明書中指明的范圍 軟件測試人員認(rèn)為軟件難以理解、不易使用，或者最終用戶認(rèn)為該軟件使用效果不良,什么是軟件測試 定義：軟件測試是為了發(fā)現(xiàn)軟件缺陷而執(zhí)行程序的過程 軟件測試的依據(jù) 需求規(guī)格說明書（重中之重）； 相關(guān)的設(shè)計說明（概要設(shè)計，詳細(xì)設(shè)計等）； 已經(jīng)基本成型的UI（可以有針對性地補充一些用例）。,軟件測試方法(1),按照測試方法來分，軟件測試分為： 黑盒測試 白盒測試,軟件測試方法(2),思想 已知程序內(nèi)部工作流程，通過測試檢驗程序內(nèi)部動作是否按規(guī)格說明書規(guī)定正常運作 依據(jù) 程序的內(nèi)部邏輯結(jié)構(gòu)，針對程序的邏輯路徑設(shè)計測試用例 特點 必須了解程序的內(nèi)部工作流程,白盒測試,思想 根據(jù)已知程序的功能和性能(而不是內(nèi)部細(xì)節(jié))，通過測試檢驗每個功能和性能是否正常 依據(jù) 程序的功能和性能描述 特點 知道程序的功能和性能，不必了解程序的內(nèi)部結(jié)構(gòu)和處理細(xì)節(jié),軟件測試方法(3),黑盒測試,軟件測試階段,按照測試階段來分，軟件測試分為：,需求分析,概要設(shè)計,詳細(xì)設(shè)計,編碼,單元測試,集成測試,確認(rèn)測試,用戶需求,驗收測試,什么是測試用例,測試用例的定義 測試用例就是一個“情況”，軟件程序在這種情況下，必須能夠正常運行并且得到預(yù)期的結(jié)果。 一個簡化的測試用例： 用例： 用戶登錄 前置條件：用戶進入到“用戶登錄頁面” 輸入： 合法用戶在系統(tǒng)中的用戶名和密碼 期待結(jié)果：用戶提交正確的用戶名和密碼后，順利進入系統(tǒng) 測試結(jié)果：成功/失敗,測試用例的設(shè)計原則 對應(yīng)需求編寫測試用例 測試用例要全面覆蓋需求規(guī)格說明書中的軟件功能點 便于發(fā)現(xiàn)有價值的缺陷 比如：系統(tǒng)要求上傳2M以下的文件，一般上載1M多一點的文件絕不會有問題。這時“敏感”會讓我們設(shè)計測試用例時，盡量去注意邊界條件，上載1.9M的文件會不會出問題？上載正好2M的文件呢？上載2M多一點的文件呢？,了解項目驗收的常見流程 了解項目維護的日常事項 了解過程改進的概念及實踐 會給角色分配權(quán)限,什么是項目實施？ 定義：實施是指將軟件系統(tǒng)部署到客戶方的計算機上，協(xié)助客戶準(zhǔn)備基礎(chǔ)數(shù)據(jù)，使軟件系統(tǒng)順利上線運行。 項目實施時的準(zhǔn)備 保證軟件符合需求，質(zhì)量過關(guān) 全面做好測試工作（集成測試、系統(tǒng)