第一篇：軟件開發(fā)與項目管理-KC0211_教學(xué)管理系統(tǒng)的需求獲取

模塊二 需求分析案例

——教務(wù)管理系統(tǒng)的需求獲取

一、項目簡介

高等學(xué)校的教學(xué)管理內(nèi)容十分豐富，工作繁多。作為一個示例，規(guī)定開發(fā)教學(xué)管理系統(tǒng)JxGL只處理每學(xué)期的課程選修注冊和學(xué)生的成績管理。教學(xué)管理系統(tǒng)JXGL的用戶是學(xué)校的學(xué)生、教師和教學(xué)管理員。學(xué)生使用JXG系統(tǒng)查詢新學(xué)期將開設(shè)的課程和授課教師的情況，選擇自己要學(xué)習(xí)的課程，并進行登記注冊。學(xué)生還可以使用JXGL系統(tǒng)查詢自己的課程成績。教師使用JXGL系統(tǒng)查詢新學(xué)期將開設(shè)的課程、參加聽課的學(xué)生情況，以及學(xué)生的考試成績。教學(xué)管理員使用JXGL系統(tǒng)進行教學(xué)管理，包括新學(xué)期的課程選課注冊管理和學(xué)生成績管理。

二、分析步驟

（一）需求描述

對教學(xué)管理系統(tǒng)JXGL要求提供兩個方面的服務(wù)：(1)選課管理，負(fù)責(zé)新學(xué)期的課程選課注冊工作;(2)成績管理，負(fù)責(zé)學(xué)生成績管理。

在選課管理方面應(yīng)填寫的用戶需求描述如下。(1)錄入與生成新學(xué)期課程表

教學(xué)管理員在新學(xué)期開始前錄入新學(xué)期課程，打印將開設(shè)的課程目錄表，供師生參考選擇。若某課程的實際選課學(xué)生少于10人，則停開該課程，把該課程從課程目錄表中刪除;若某課程的選課學(xué)生多于30人，則停止選課。

(2)學(xué)生選課注冊

新學(xué)期開始前一周為選課注冊時間，在此期間學(xué)生可以選課注冊，并且允許改變或取消注冊申請。每個學(xué)生選課不超過4門課程。每門課程最多允許30名學(xué)生選課注冊。

學(xué)生可以在圖書館、各系資料室、學(xué)生宿舍等處的計算機上聯(lián)網(wǎng)進行選課注冊。在選課注冊結(jié)束后，教學(xué)管理員打印學(xué)生選課注冊名單和開課通知書，送交有關(guān)部門和授課教師。(3)查詢

可以查詢課程信息、學(xué)生選課信息和學(xué)生、教師信息。

學(xué)生、教師、教學(xué)管理員可以查詢課程表，獲得課程信息。查詢的關(guān)鍵詞以是:課程名，授課教師名，學(xué)分。

教師、教學(xué)管理員可以查詢學(xué)生選課情況。查詢的關(guān)鍵詞可以是:學(xué)生名、程名，授課教師名，學(xué)分。學(xué)生只允許查詢自己的選課信息，不允許查詢別人選課信息。學(xué)生、教師、教學(xué)管理員可以查詢學(xué)生或教師的信息。查詢的關(guān)鍵詞可以是學(xué)生名、教師名，性別、班級、職稱。

(4)選課注冊信息的統(tǒng)計與報表生成。

教學(xué)管理員對學(xué)生的選課注冊信息進行統(tǒng)計(按課程，按學(xué)生，按班級)，印匯總統(tǒng)計報表。在成績管理方面應(yīng)填寫的用戶需求描述如下：(1)成績錄入: 教學(xué)管理員錄入學(xué)生考試成績。(2)成績查詢: 教師、教學(xué)管理員可以查詢學(xué)生考試成績。查詢的關(guān)鍵詞可以是:學(xué)生名、課程名、授課教師名、學(xué)分名、學(xué)生只允許查詢自己的考試成績，不允許查詢別人的考試成績。

(3)成績統(tǒng)計與報表生成

教學(xué)管理員進行成績統(tǒng)計(按課程、學(xué)生、按班級)，打印成績匯總統(tǒng)計報表。

為保存數(shù)據(jù)，需建立教學(xué)管理數(shù)據(jù)庫?？梢圆捎藐P(guān)系數(shù)據(jù)庫，建立下列數(shù)據(jù)庫表:學(xué)生表、教師表、課程表、選課表、任課表、成績表。

教學(xué)管理系統(tǒng)的直接用戶有學(xué)生、教師和教學(xué)管理員。教學(xué)管理員有權(quán)操縱數(shù)據(jù)庫的數(shù)據(jù)，進行添加、更新、刪除等操作。學(xué)生和教師一般只查詢信息，只允許對自己有關(guān)的數(shù)據(jù)進行添加，更新、刪除等操作。

教學(xué)管理系統(tǒng)JXGL的相關(guān)系統(tǒng)有財務(wù)系統(tǒng)。JXGL系統(tǒng)需要把學(xué)生選課注冊信息傳送給財務(wù)系統(tǒng)，以供財務(wù)系統(tǒng)計算學(xué)生應(yīng)交納的費用，但是不要求財務(wù)系統(tǒng)回饋學(xué)生應(yīng)交納的費用信息。

假定在學(xué)校的計算中心有功能強大的工作站機器，在各系、各部門、圖書館、學(xué)生宿舍都有臺式PC機，學(xué)校的全部計算機已經(jīng)連網(wǎng)。教學(xué)管理系統(tǒng)JXGL將采用客戶機/服務(wù)器結(jié)構(gòu)建立，JXGL系統(tǒng)的應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器設(shè)置在學(xué)校計算中心的工作站。學(xué)生、教師和教學(xué)管理員可以在各系、各部門、圖書館、學(xué)生宿舍的臺式PC機上使用JXGL系統(tǒng)。

（二）確定系統(tǒng)范圍和邊界

首先要確定業(yè)務(wù)需求和系統(tǒng)目標(biāo)。教學(xué)管理系統(tǒng)JxGL用于新學(xué)期課程的選課注冊管理和學(xué)生的成績管理。凡是這兩方面的教學(xué)管理內(nèi)容都是JXGL系統(tǒng)的職責(zé)范圍，其他的教學(xué)管理內(nèi)容，如安排教學(xué)計劃、排課、實習(xí)、實驗、考試等都不屬于JXGL系統(tǒng)的職責(zé)范圍。至于學(xué)校的其他管理工作，如科研、人事、財務(wù)、資產(chǎn)等管理不屬于JXGL系統(tǒng)的職責(zé)范圍。

JXGL系統(tǒng)與財務(wù)系統(tǒng)存在系統(tǒng)邊界，財務(wù)系統(tǒng)將從JXGL系統(tǒng)得到學(xué)生選課注冊信息。JXGL系統(tǒng)與學(xué)校的其他信息管理系統(tǒng)沒有直接的聯(lián)系，但是可以從學(xué)校的全局?jǐn)?shù)據(jù)庫中共享學(xué)生、教師、教學(xué)計劃等必要的數(shù)據(jù)。

（三）定義用戶

根據(jù)JXGL系統(tǒng)用戶需求描述可以確定4個參與者:學(xué)生、老師、教學(xué)管理員和財務(wù)系統(tǒng)。對于每一個參與者，應(yīng)當(dāng)明確其業(yè)務(wù)活動的內(nèi)容、對系統(tǒng)的服務(wù)要求。

“學(xué)生”參與者使用JXGL系統(tǒng)查詢新學(xué)期開設(shè)的課程信息和教師開課信息，選課并登記注冊課程，查詢自己的課程成績信息。

“老師”參與者使用JXGL系統(tǒng)查詢新學(xué)期開設(shè)的課程信息、學(xué)生選課信息和學(xué)生成績信息。“教學(xué)管理員”參與者使用JXGL系統(tǒng)管理學(xué)期開設(shè)的課程的選課注冊和學(xué)生的考試成績。管理工作包括課程與成績數(shù)據(jù)的錄入、維護、統(tǒng)計、報表打印等，并且負(fù)責(zé)把學(xué)生的選課注冊信息發(fā)送給財務(wù)系統(tǒng)，作為計算學(xué)生應(yīng)付費用的依據(jù)。

“教學(xué)管理員”要求能夠方便地查詢課程信息、學(xué)生選課信息、學(xué)生信息、教師信息和成績信息?！柏攧?wù)系統(tǒng)”參與者是外部系統(tǒng)參與者，從JXGL系統(tǒng)接受學(xué)生的課程注冊信息。

（四）Use Case的獲取

每一個USeCase都是一個參與者與系統(tǒng)在交互中執(zhí)行的有關(guān)事務(wù)序列。應(yīng)當(dāng)根據(jù)用戶需求描述，找出全部的USeCase，并從參與者的角度給出事件流，當(dāng)USeCase執(zhí)行時系統(tǒng)應(yīng)提供給參與者的服務(wù)。

從JxGL的用戶需求描述分析可的有以下用例存在:(1)查詢課程信息:學(xué)生、教師或教學(xué)管理員查詢課程表，獲得課程信息。(2)選課注冊:學(xué)生登錄進行選課注冊。

(3)管理開設(shè)課程:教學(xué)管理員登錄系統(tǒng)產(chǎn)生選課信息，按照要求進行分類統(tǒng)計，生成選課注冊報表。(4)管理學(xué)生信息:教學(xué)管理員對學(xué)生數(shù)據(jù)進行錄入、修改、刪除等操作。(5)管理老師信息:教學(xué)管理員對教師數(shù)據(jù)進行錄入、修改、刪除等操作。(6)管理課程信息:教學(xué)管理員對課程數(shù)據(jù)進行錄入、修改、刪除等操作。(7)查詢學(xué)生成績:學(xué)生、教師查詢學(xué)生成績。(8)查詢課程成績:學(xué)生、教師查詢課程成績。

(9)學(xué)生成績管理:教學(xué)管理員對學(xué)生考試成績數(shù)據(jù)進行錄入，修改、刪除等操作。(10)成績統(tǒng)計:教學(xué)管理員對學(xué)生的考試成績數(shù)據(jù)進行分類統(tǒng)計，生成成績報表。

（五）需求獲取描述

（1）管理課程信息

（2）選課注冊

（3）查詢課程信息

（4）管理開設(shè)課程

（5）學(xué)生成績管理

（6）查詢成績

（7）成績統(tǒng)計

（六）導(dǎo)出UseCase

圖1 學(xué)生與老師用例圖

圖2 管理員用例圖

圖3 學(xué)生與老師成績管理用例

圖4 管理員成績管理用例

第二篇：淺談軟件開發(fā)項目管理

淺談軟件開發(fā)項目管理

摘要：在軟件項目開發(fā)的過程中，軟件項目管理的成功與否是決定一個項目是否能夠順利高效率完成的重要保證。但是我國大部分的軟件企業(yè)在進行項目管理時都存在著各種問題，從而使項目不能順利有效地完成。文章探討了在項目管理過程里出現(xiàn)的常見問題，并給出了相應(yīng)的解決策略。

關(guān)鍵詞：軟件項目管理；項目經(jīng)理；項目計劃

軟件行業(yè)在現(xiàn)在的眾多行業(yè)里是一個極具挑戰(zhàn)性和創(chuàng)造性的行業(yè)，體現(xiàn)了軟件開發(fā)者的智慧和汗水，同時軟件開發(fā)是一項復(fù)雜的系統(tǒng)工程。牽涉到許多方面的因素，在實際工作中，經(jīng)常會出現(xiàn)各種各樣的問題，甚至?xí)媾R失敗。如何總結(jié)、分析失敗的原因。得出有益的教訓(xùn)，對于項目開發(fā)人員來說，是在今后的項目中取得成功的關(guān)鍵。

一、軟件開發(fā)中實行項目管理的意義

項目管理就是在項目活動中運用一系列的知識、技能、工具和技術(shù)，以滿足或超過相關(guān)利益者對項目的要求，實際上就是通過項目各方干系人的合作，把各種資源應(yīng)用于項目，以實現(xiàn)項目的目標(biāo)，滿足項目干系人的需求，其本質(zhì)就是對時間、質(zhì)量和成本的管理。隨著軟件開發(fā)的深入、各種技術(shù)的不斷創(chuàng)新以及軟件產(chǎn)業(yè)的形成，人們越來越意識到軟件過程管理的重要性，管理學(xué)的思想逐漸融入軟件開發(fā)過程中，項目開發(fā)的管理日益受到重視。

二、目前在軟件項目管理中存在的誤區(qū)

現(xiàn)在大多數(shù)企業(yè)都認(rèn)識到了在項目中進行管理的重要性，但是仍然有許多企業(yè)在實施項目管理的過程中存在著這樣那樣的誤區(qū)，主要表現(xiàn)在：項目經(jīng)理不夠?qū)I(yè)。在軟件企業(yè)中，缺乏專業(yè)的項目管理人員來實施項目管理及擔(dān)任項目經(jīng)理，通常被任命的項目經(jīng)理主要是因為他們能夠在技術(shù)上獨當(dāng)一面，但是他們在管理方面特別是項目管理方面的知識比較缺乏。項目計劃缺乏綱領(lǐng)性。項目經(jīng)理對總體計劃、階段計劃的作用認(rèn)識不足，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮：階段計劃因工作忙等理由經(jīng)常拖延，造成計劃與控制管理脫節(jié)，無法進行有效的進度控制管理。缺乏有效的管理意識。部分項目經(jīng)理不能從總體上把握整個項目，而是埋頭于具體的技術(shù)工作，造成項目組成人員之間忙的忙、閑的閑，計劃不周、任務(wù)不均、資源浪費。有些項目經(jīng)理沒有很好的管理方法，不好安排的工作只好自己做，使項目任務(wù)無法有效、合理地分配給相關(guān)成員，以達到“負(fù)載均衡”。缺乏有效的溝通制度和機制。在項目中一些重要信息沒有進行充分和有效的溝通。在制定計劃、意見反饋、情況通報、技術(shù)問題或成果等方面與相關(guān)人員的溝通不足，造成各做各事、重復(fù)勞動，甚至造成不必要的損失：有些人沒有每天定時收郵件的習(xí)慣，以至于無法及時接收最新的信息。風(fēng)險管理意識淡泊。有些項目經(jīng)理沒有充分意識到風(fēng)險管理的重要性，對計劃書中風(fēng)險管理的章節(jié)簡單應(yīng)付了事，隨便列出幾個風(fēng)險，隨便地寫一些簡單的對策，對于后面的風(fēng)險防范起不到什么指導(dǎo)作用。項目干系人的不確定性。在范圍識別階段，項目組對客戶的整體組織結(jié)構(gòu)、有關(guān)人員及其關(guān)系、工作職責(zé)等沒有足夠了解以至于無法得到完整需求或最終經(jīng)權(quán)威用戶代表確認(rèn)的需求：或者是多個用戶代表各說各話、昨是今非，但同時又要求項目盡早交付：項目后期需求變化隨意，造成項目范圍的蔓延，進度的拖延，成本的擴大。缺乏項目團隊的合理分工。項目團隊內(nèi)部有時由于各階段不同角色或同階段不同角色之間的責(zé)任分工不夠清晰而造成工作互相推諉、責(zé)任互相推卸的現(xiàn)象；有時各階段不同角色或同階段不同角色之間的責(zé)任分工比較清晰，但是各項目成員只顧完成自己那部分任務(wù)，不愿意與他人協(xié)作。這些現(xiàn)象都將造成項目組內(nèi)部資源的損耗，從而影響項目進展。

三、解決軟件項目管理中存在的誤區(qū)的有效策略

要想解決上面描述的誤區(qū)，歸根到底還是要從管理學(xué)的角度入手，即在軟件項目的開發(fā)過程中加入過程管理的內(nèi)容，這樣我們可以在軟件開發(fā)中對各個過程的質(zhì)量加以控制，從而達到保證軟件產(chǎn)品質(zhì)量的目的。為了有效提高管理水平，我們應(yīng)該努力做到：項目經(jīng)理接受系統(tǒng)的項目管理知識培訓(xùn)是非常必要的，有了專業(yè)領(lǐng)域的知識與實踐，再加上項目管理知識與實踐和一般管理的知識和經(jīng)驗的有機結(jié)合，必能大大提高項目經(jīng)理的項目管理水平。計劃的制定需要在一定條件的限制和假設(shè)之下采用漸近明細的方式進行不斷完善。提高項目經(jīng)理的計劃意識，采用項目計劃制定相關(guān)知識、技術(shù)、工具，加強對開發(fā)計劃、階段計劃的有效性進行事前事后的評估。加強項目管理方面的培訓(xùn)，并通過對考核指標(biāo)的合理設(shè)定和宣傳引導(dǎo)項目經(jīng)理更好地做好項目管理工作。技術(shù)骨干在擔(dān)任項目經(jīng)理之前，最好能經(jīng)過系統(tǒng)的項目管理知識，特別是其中的人力資源管理、溝通管理的學(xué)習(xí)，并且在實際工作中不斷提高自己的管理素質(zhì)，豐富項目管理經(jīng)驗，提高項目管理意識。制定有效的溝通制度和溝通機制，提高溝通意識：采取多種溝通方式，提高溝通的有效性。通過制度規(guī)定對由于未及時收取郵件而造成損失的責(zé)任歸屬；對于特別重要的內(nèi)容要采用多種方式進行有效溝通以確保傳達到位，例如：除發(fā)送郵件外還要電話提醒、回執(zhí)等，重要的內(nèi)容還要通過舉行各種會議進行傳達。通過學(xué)習(xí)項目管理知識掌握風(fēng)險識別、量化、對策研究、反應(yīng)控制的工具和方法，掌握項目風(fēng)險管理所必備的知識。通過加強對項目規(guī)劃中風(fēng)險管理計劃的審核提高項目組的風(fēng)險管理意識?？偨Y(jié)本行業(yè)項目中常見的風(fēng)險及其對策作為風(fēng)險管理計劃中必要的風(fēng)險內(nèi)容，并切實評估相應(yīng)對策的有效性和可行性。項目的目的就是實現(xiàn)項目干系人的需求和愿望。項目干系人管理應(yīng)當(dāng)從項目的啟動開始，項目經(jīng)理及其項目成員就要分清項目干系人包含哪些人和組織，通過溝通協(xié)調(diào)對他們施加影響，驅(qū)動他們對項目的支持，調(diào)查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。項目經(jīng)理應(yīng)當(dāng)對項目成員的責(zé)任進行合理的分配并清楚地說明，同時應(yīng)強調(diào)不同分工、不同環(huán)節(jié)的成員應(yīng)當(dāng)相互協(xié)作，共同完善。

實施有效的項目管理絕非易事，對于軟件企業(yè)而言，這不是一個小的改變，而是一種變革，企業(yè)需要為此付出艱苦的努力，同時，成熟有效的項目管理無疑將對企業(yè)起著至關(guān)重要的作用，項目管理的水平將是企業(yè)核心競爭力之一。

第三篇：軟件開發(fā)項目管理（范文）

管理目標(biāo)

1、所有關(guān)系人清晰明確地了解項目的需求和期望，努力做到滿足項目所有關(guān)系人的不同需求；項目關(guān)系人包括：項目團隊成員和項目團隊外(內(nèi)部/外部客戶，內(nèi)部/外部合作伙伴，經(jīng)銷商/客戶等)。

2、項目管理三要素平衡（時間/成本/質(zhì)量），即開發(fā)項目按需按時按質(zhì)的完成。

3、目標(biāo)：功能滿足需求，設(shè)計支持變化，開發(fā)快速迭代，成果持續(xù)交付。

執(zhí)行概述

1、建立有效的工作流程保證項目的順利進行，初期使用傳統(tǒng)RUP過程，引入部分敏捷方法，團隊磨合完成后逐步實現(xiàn)敏捷開發(fā)全流程管理。

2、明確項目目標(biāo)，制定具有可行性的項目計劃，有效明確的分解項目需求。

3、跟蹤設(shè)計/開發(fā)/測試/回歸/發(fā)布全流程，推動項目按預(yù)定計劃執(zhí)行。

4、解決項目過程中出現(xiàn)的問題和沖突，一般集中在需求不明/工作量或時長/開發(fā)難度/跨部門協(xié)調(diào)等幾個方面。

5、調(diào)動開發(fā)團隊的積極性，創(chuàng)造力，推動團隊成員在項目過程中的學(xué)習(xí)成長。

6、風(fēng)險識別、風(fēng)險控制以及風(fēng)險的預(yù)案。

項目管理

1、需求階段

對項目進行技術(shù)可行性分析、技術(shù)評估、成本評估以及風(fēng)險評估。與需求提出方的代表進行需求討論，明確項目的目標(biāo)、價值。確定項目范圍、功能及優(yōu)先級。

組建項目團隊，特別要搞清楚項目的關(guān)鍵人。項目啟動會議，相關(guān)的關(guān)系人都必須參加。

2、設(shè)計階段

根據(jù)確認(rèn)后的軟件需求規(guī)格說明書，制定項目進度計劃，工作任務(wù)分解(WBS)；資源申請，項目涉及到的開發(fā)資源、測試資源、設(shè)計資源(包括人員和軟硬件資源)；數(shù)據(jù)庫設(shè)計；系統(tǒng)設(shè)計；文檔(包括系統(tǒng)用例、Demo、測試用例等)；評審會議。

設(shè)計階段結(jié)果交付一般為系統(tǒng)用例/系統(tǒng)原型/系統(tǒng)設(shè)計文檔(概要設(shè)計和詳細設(shè)計)/數(shù)據(jù)庫設(shè)計文檔等。

該階段交付成果需要進行評審。

3、執(zhí)行階段(開發(fā)和測試)準(zhǔn)備開發(fā)環(huán)境、測試環(huán)境。跟蹤，推動項目按計劃進行。

項目成員以日報/項目負(fù)責(zé)人以周報的形式通報各關(guān)系人當(dāng)前項目的進展情況。按里程碑對階段成果進行評估，以確保該階段完成的質(zhì)量。代碼審核，包括CS審核、SQL審核、WEB審核等。對需求變更進行控制管理。

測試階段BUG響應(yīng)及改進、收集反饋意見。對項目風(fēng)險進行管理。

4、發(fā)布階段

包括制定項目發(fā)布計劃，用戶培訓(xùn)，發(fā)布上線。

5、試運行階段

數(shù)據(jù)監(jiān)控(日志、服務(wù)器狀態(tài))，根據(jù)監(jiān)控出現(xiàn)的問題，及時進行處理，改進性能問題，特定情況執(zhí)行補丁升級。

6、收尾階段

產(chǎn)品交付，項目總結(jié)會。

常見問題

1、開發(fā)時間的估算

制定項目計劃時，需要估算每個任務(wù)所需的時間，其中主要是開發(fā)任務(wù)中模塊的分配和時間估算，在公司現(xiàn)有的技術(shù)框架下，開發(fā)人員主要的工作是投入在具體的業(yè)務(wù)邏輯實現(xiàn)上。通常單個模塊開發(fā)時間取決于以下因素：

1、負(fù)責(zé)模塊的業(yè)務(wù)邏輯的復(fù)雜程度。

2、開發(fā)人員的技術(shù)水平和對項目所在應(yīng)用的熟悉程度(包括對框架和應(yīng)用的熟悉程度)。

3、模塊技術(shù)實現(xiàn)上是否存在難點，所謂的技術(shù)難點定義是：在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身未沒接觸過的技術(shù)。對于這樣的難點，開發(fā)者沒有相關(guān)的代碼可以參考，自己也沒有經(jīng)驗，所以需要投入學(xué)習(xí)時間用于研究解決。

模塊分配和開發(fā)時間估算的步驟：

1、在劃分好模塊后，首先項目管理人員預(yù)先估算各個模塊所需要的開發(fā)時間。

2、召集所有開發(fā)人員，討論模塊的分配和開發(fā)時間估算。將劃分好的模塊，分配給開發(fā)人員，如狀況允許可允許開發(fā)人員自主選擇以提高開發(fā)人員的主動性和參與性。分配模塊的時為確保開發(fā)的速度和質(zhì)量，基本原則如下：

A、類似的模塊由同一人負(fù)責(zé)開發(fā)，比如用戶信息的增刪改應(yīng)由同一開發(fā)者負(fù)責(zé)。這樣開發(fā)者對相關(guān)邏輯會比較熟悉，代碼/接口的定義也會相對明確，溝通的成本低，相應(yīng)可以降低功能實現(xiàn)的缺陷概率。

B、技術(shù)難度較大的模塊由技術(shù)水平比較高的人負(fù)責(zé)。C、業(yè)務(wù)邏輯比較復(fù)雜的由對業(yè)務(wù)邏輯比較了解的人負(fù)責(zé)。

3、模塊分配完成后，開發(fā)人員評估自己負(fù)責(zé)開發(fā)的模塊所需要的時間。在此過程中應(yīng)

4、對開發(fā)人員估算的時間進行確認(rèn)。在確認(rèn)過程中作為，項目管理者將預(yù)估時間和開與開發(fā)者討論每個模塊的技術(shù)實現(xiàn)細節(jié)，使時間的估算更加準(zhǔn)確。發(fā)人員估算時間進行比較。那些差異較大的，與人員探討其中的緣由。對于時間周期比較長的任務(wù)，將任務(wù)拆分為更小的子任務(wù)，每個任務(wù)的完成時間為8-24工時，消除時間周期較長的任務(wù)，避免不確定性影響項目的進度。

2、CodeReview CodeReview是保證項目中代碼質(zhì)量非常重要的一個環(huán)節(jié)，在這一環(huán)控制不嚴(yán)往往是測試后出現(xiàn)大量bug的主因，有時甚至導(dǎo)致返工；關(guān)于CodeReview執(zhí)行，首先應(yīng)有編碼規(guī)范和代碼審查規(guī)范。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn)，代碼編寫者必須要嚴(yán)格按照規(guī)范來進行；代碼審核者根據(jù)這些標(biāo)準(zhǔn)來CodeReview代碼，同時在CodeReview過程中需要不斷完善該文檔。

CodeReview一般可按以下步驟實施：

1、檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。

2、從代碼的易維護性、可擴展性角度考察代碼的質(zhì)量，提出修改建議。

3、代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負(fù)責(zé)的代碼和相關(guān)邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug，對這些bug記錄在案。

4、代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要檢查Bug。同時全面兼顧，確保代碼整體上結(jié)構(gòu)優(yōu)良；審核完畢后，代碼審核者編寫“代碼審核報告”記錄發(fā)現(xiàn)的問題及修改建議，提交給相關(guān)人員。

5、代碼編寫者根據(jù)“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。

6、代碼編寫者bugfixed完畢之后給出反饋。

7、代碼審核者把CodeReview中發(fā)現(xiàn)的有價值的問題更新到“代碼審核規(guī)范”的文檔中，對于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。

3、需求變更管理

需求變更管理也是項目管理中最重要的一個環(huán)節(jié)，對需求變更管理的有效性將直接影響對待需求變更的正確態(tài)度：

1、需求變更是不可避免的。

2、需求變更要必須被管理。

3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風(fēng)險。需求變更管理的目標(biāo)：

1、相關(guān)的干系人必須清楚地了解發(fā)生的變更。

2、變更處于有效的管理中。

3、盡量降低變更帶來的風(fēng)險。

通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現(xiàn)上述的目標(biāo)。需求變更流程：

1、確定需求的基準(zhǔn)線。將以UserCase作為需求基準(zhǔn)線，在UserCase確認(rèn)之后的任項目的成功與否。何需求改變，都需要走需求變更流程。

2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。

3、項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關(guān)人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。項目管理者對項目的成功與否負(fù)有主要的責(zé)任。需求變更的決策應(yīng)由項目管理者做出。

4、需求變更確認(rèn)后，由專人將生成需求變更單記錄下來，通知給項目中所有關(guān)系人。

5、確定變更的負(fù)責(zé)人。承擔(dān)需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關(guān)人員。

6、相關(guān)人員接收到確認(rèn)的需求變更后，需求分析人員修改需求說明書和UserCase的相關(guān)內(nèi)容。測試人員修改測試用例的相關(guān)內(nèi)容。開發(fā)人員修改代碼中的相關(guān)部分。

7、按照變更后的計劃實施項目，并進行檢查，跟蹤，對變更后的實施反饋和可能出現(xiàn)的問題及時溝通和處理。

8、需求凍結(jié)。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入需求凍結(jié)階段，不再接收新需求或需求的變更。

4、風(fēng)險管理

影響項目成敗的因素涉及方方面面，并且風(fēng)險伴隨著項目的始終，是客觀存在的，風(fēng)險引起的負(fù)面后果集中體現(xiàn)在進度延后、成本超支、質(zhì)量不達標(biāo)等方面，常見風(fēng)險如下：

1、目標(biāo)以及需求不明確

為了市場競爭或內(nèi)部管理決策的需要，業(yè)務(wù)部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有正式的業(yè)務(wù)需求文檔，在沒有明確的需求范圍的情況下，有時為了迎合業(yè)務(wù)部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術(shù)人員開始疲于奔命和應(yīng)付，很難保證項目的進度和質(zhì)量，也難以取得業(yè)務(wù)部門的認(rèn)可。

在項目的前期一定要采取相應(yīng)的手段或措施，與業(yè)務(wù)部門共同明確項目目標(biāo)、需求范圍，充分考慮現(xiàn)有的時間和資源約束，將需求排定優(yōu)先級，對于關(guān)鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取得業(yè)務(wù)部門的書面確認(rèn)。在此過程中要注重挖掘用戶的隱性需求，可以通過引導(dǎo)、系統(tǒng)原型等手段讓用戶在前期充分暴露自己的想法和需求。

2、項目目標(biāo)擴大以及需求變更

在有了明確的目標(biāo)和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務(wù)部門在看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項目進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴(yán)格的變更控制流程，不能礙于面子，否則最終的結(jié)果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關(guān)團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負(fù)責(zé)人根據(jù)分析結(jié)果判斷是否批準(zhǔn)，如果批準(zhǔn)，那項目組可以安排實施，否則，正式拒絕用戶的請求。

前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關(guān)職能主管、客戶)，所有的需求要經(jīng)過他們的認(rèn)可。客戶在項目過程中的全程參與有助于降低此類風(fēng)險。需求討論、需求確認(rèn)、UserCase確認(rèn)、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時，嚴(yán)格按照需求變更流程執(zhí)行。在分析設(shè)計階段的中的確認(rèn)和評審也是降低此類風(fēng)險的重要手段。

3、代碼質(zhì)量風(fēng)險

質(zhì)量風(fēng)險主要指開發(fā)代碼的質(zhì)量。在制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質(zhì)量的影響很大。開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務(wù)，可能就存在很大的開發(fā)質(zhì)量問題。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設(shè)計文檔對指導(dǎo)開發(fā)非常重要。

往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題。這需要在項目實施過程中采取有效的措施來規(guī)避風(fēng)險，通常的做法有同行評審，比如概要設(shè)計完成之后，邀請其他項目組的技術(shù)專家進行技術(shù)評審以發(fā)現(xiàn)架構(gòu)設(shè)計問題；管理評審，通過組織級的質(zhì)量審計看產(chǎn)品以及實施過程是否滿足質(zhì)量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要求的代碼，走查通常能夠發(fā)現(xiàn)50%-70%的錯誤；每日構(gòu)建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應(yīng)的錯誤，日構(gòu)建一般在項目的中后期開始，每天自動從版本服務(wù)器上獲取源代碼進行自動編譯和測試。

4、人員技能和資源的不足

項目實施過程中由于人員技能欠缺造成的進度延后和軟件質(zhì)量問題并不少見，一個熟練的技術(shù)人員完成同樣一個任務(wù)需要3天，但一個新手可能就需要7-10天。項目管理者應(yīng)該在前期就分析清楚項目所要采用的技術(shù)以及相應(yīng)的人員技能要求，針對不同的角色，及時采取相應(yīng)的技能培訓(xùn)，以保證項目的順利實施。開發(fā)過程中遇到技術(shù)難題，導(dǎo)致開發(fā)時間延遲或者需求不得不發(fā)生變更。在項目開始前的技術(shù)評估階段，明確技術(shù)難點，提前安排人員進行攻克。如果在可預(yù)期的時間內(nèi)無法解決，如果可以，將向需求提出方要求變更需求或?qū)ふ铱商娲桨?。這樣的風(fēng)險應(yīng)該在項目的前期階段就應(yīng)該解決在萌芽狀態(tài)來避免這樣的風(fēng)險在后期或中期出現(xiàn)。

5、缺乏良好的團隊協(xié)作

軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關(guān)系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產(chǎn)出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在的風(fēng)險問題，在項目啟動和團隊組建的時候就應(yīng)該加以規(guī)避這樣的風(fēng)險出現(xiàn)。

6、項目會議

組織會議是項目執(zhí)行過程中一項非常重要的工作任務(wù)，項目過程中很多重要的決定都是在會議中做出的，不成功的會議會對項目本身造成了不好的影響。

不成功的會議通常表現(xiàn)為如下形式：

1、會議氛圍不好，參與者發(fā)言不踴躍；

2、會議討論常常偏離主題；

3、會議沒有取得預(yù)期的結(jié)果；

4、會議時間常常一拖再拖。

這些不成功的會議最終的結(jié)果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應(yīng)該注意的問題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：

1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有可能取得成功，這是會議成功的充分條件。

2、會議的組織者和參與者的想法通常是不一致的，有時候甚至?xí)笙鄰酵ァＫ圆灰Ｍ麜h的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只是一個發(fā)表想法的人，他不用對會議的成功承擔(dān)責(zé)任。

3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。組織會議的十一條最佳實踐：

1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。

2、提前發(fā)出會議議程，以便會議參與者知道他們來做什么。

3、請對人很重要，不要把非必要的人召來開會，當(dāng)然也不要漏掉那些關(guān)鍵人物。在確保必要人物都在的情況下一次會議參與者越少效果越好。

4、提前預(yù)約參與者的時間，以確保他們能按時到場。

5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在開場時說： A、再一次強調(diào)會議的目標(biāo)，我們來做什么。

B、強調(diào)會議的主題與基調(diào)。比如：本次會議是一個需求確認(rèn)會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論如何做上面。

C、說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人的講話，等別人說完你再說等等。

6、會議過程中時刻注意引導(dǎo)和控制會議，以確保會議按照目標(biāo)進行。一次會議的氛圍是否良好，討論是否充分，好的引導(dǎo)至關(guān)重要。比如多提一些開放式的問題。

7、會議記錄很重要，把一些結(jié)論和有價值的內(nèi)容記錄下來，這些是本次會議的重要成果之一。

8、會議要有結(jié)論。我們常在會議上聽到有人說：“大家討論了這么半天，結(jié)論呢？”。沒有結(jié)論的會議是沒有意義的。

9、會議后別忘發(fā)會議紀(jì)要，以及一些Action，什么人什么時候做什么。

10、會議后的action執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性也會降低。很多會議往往都不注意這一點。

11、按時結(jié)束的會議會受到所有人的歡迎。

第四篇：軟件開發(fā)項目管理實施方案.

項目管理實施方案

作為一個項目管理者,如何要成功的做好項目管理;首先必須先要明白的是在特定的領(lǐng)域中賦予這個角色所要實現(xiàn)的目標(biāo)、承擔(dān)的職責(zé)、以及項目管理者的具體工作內(nèi)容是什么? 從我個人的淺見和角度以及我們所從事的IT領(lǐng)域來分析回答以上三個問題。第一:目標(biāo)

作為一個項目的管理者,必須要明確的知道自己的工作目標(biāo);我個人認(rèn)為項目管理者的目標(biāo)無非就是以下兩點:

1、就是清晰明確地了解項目利害關(guān)系者的需求和期望,努力做到滿足項目利害關(guān)系者的不同需求;項目利害關(guān)系者包括:項目團隊成員和項目團隊外成員(比如各部門的部門負(fù)責(zé)人和市場人員,客戶等。

2、就是保證開發(fā)項目按需按時保質(zhì)的完成。第二:職責(zé)

作為項目的管理者,首先要端正態(tài)度,要明確知道自己的工作職責(zé),認(rèn)識到這份工作職責(zé)的本質(zhì)。項目管理者不是來管人的,而是來支持人的,是來協(xié)調(diào)資源的,是來營造一個適合團隊成員比較認(rèn)同的工作環(huán)境和氛圍的,是來為一個共同的目標(biāo)和大家一起戰(zhàn)斗共同成長的。可以大概概括成以下幾點:

1、建立有效的工作流程保證項目的順利進行。

2、制定詳細周密的項目計劃。

3、跟蹤,推動項目按計劃進行。

4、積極解決項目過程中出現(xiàn)的問題和沖突。

5、調(diào)動開發(fā)團隊的積極性,創(chuàng)造力,推動團隊成員在項目過程中不斷成長。

6、項目風(fēng)險識別、風(fēng)險評估、風(fēng)險解決和風(fēng)險管理策略以及做好突發(fā)風(fēng)險的應(yīng)急預(yù)案。

7、實現(xiàn)目標(biāo)

第三:項目管理者的具體工作內(nèi)容

最后一個是項目管理者的具體工作內(nèi)容,作為項目管理者必須清晰的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心,分為以下六點:

1、項目前期階段

對項目進行技術(shù)可行性分析、技術(shù)評估、成本評估以及風(fēng)險評估。與需求提出方的代表進行需求討論,明確項目的目標(biāo)、價值;確定項目范圍、功能及優(yōu)先級。組建項目團隊,特別要搞清楚項目的key person(對產(chǎn)品有決定權(quán)的人。項目啟動會議,相關(guān)的

利害關(guān)系人員都必須參加。

該階段完成后的成果:確認(rèn)后的最終軟件需求規(guī)格說明書文檔。

2、分析設(shè)計階段

根據(jù)確認(rèn)后的軟件需求規(guī)格說明書,制定項目進度計劃,工作任務(wù)分解(WBS;資源申請,項目涉及到的開發(fā)資源、測試資源、設(shè)計資源(包括人員和軟硬件資源;數(shù)據(jù)庫設(shè)計;系統(tǒng)設(shè)計;文檔(包括Use Case、Demo系統(tǒng)原型、Test Case等;評審會議。

該階段完成后的成果: A、User Case(系統(tǒng)用例;B、DEMO(系統(tǒng)原型;

C、系統(tǒng)設(shè)計文檔(概要設(shè)計和詳細設(shè)計;D、數(shù)據(jù)庫設(shè)計文檔。

最后對完成的成果,包括User Case和設(shè)計文檔等進行評審。

3、執(zhí)行階段(開發(fā)和測試

準(zhǔn)備開發(fā)環(huán)境、測試環(huán)境;跟蹤,推動項目按計劃進行;以周報的形式通報項目的進展情況。對項目的階段成果進行評估,以確保該階段完成的質(zhì)量,包括代碼審核、SQL 審核等。對需求變更進行控制管理;對項目風(fēng)險進行管理;測試階段BUG FIXED及改進、收集反饋意見。

4、發(fā)布階段

包括制定項目發(fā)布計劃,用戶培訓(xùn),發(fā)布上線。

5、上線后監(jiān)控

數(shù)據(jù)監(jiān)控(日志、服務(wù)器狀態(tài),根據(jù)監(jiān)控出現(xiàn)的問題,及時進行BUG FIXED及改進或做補丁升級。

6、結(jié)束階段

產(chǎn)品交付,項目總結(jié)會。

第四:基于以上三個問題所做的應(yīng)對細則

要做好項目管理,并能確實解決好以上三個問題,實現(xiàn)目標(biāo)、履行職責(zé)、完成工作中的具體內(nèi)容,從我個人這幾年的工作經(jīng)驗和面臨的一些問題,還有所積累的一些項目管理中的

一些知識以及自己的觀察和思考的角度看,應(yīng)該要努力做好以下這幾個方面的具體工作:

1、項目開發(fā)時間的估算

制定項目進度時間表的時候,需要估算每個任務(wù)所需的時間,其中開發(fā)任務(wù)中模塊的分配和時間估算是其中最主要的部分;在分配模塊和估算開發(fā)時間時需要遵循的原則和目標(biāo):

1、保證項目整體的進度。

2、有助于確保開發(fā)編碼的質(zhì)量。

3、有助于提高開發(fā)編碼的速度。

在公司現(xiàn)有的技術(shù)框架下,開發(fā)人員主要的工作是投入在具體的商業(yè)邏輯上。通常每個模塊所需的開發(fā)時間取決于以下三個因素:

1、所負(fù)責(zé)模塊的商業(yè)邏輯的復(fù)雜程度。

2、開發(fā)人員的技術(shù)水平和對項目所在應(yīng)用的熟悉程度(包括對框架和應(yīng)用的熟悉程度。

3、該模塊技術(shù)實現(xiàn)上是否有技術(shù)難點;這里所謂的技術(shù)難點定義是:在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身也未沒接觸過的技術(shù)。對于這樣的難點,開發(fā)者沒有相關(guān)的代碼可以參考,自己也沒有經(jīng)驗,所以需要投入一些時間研究解決。

模塊分配和開發(fā)時間估算的步驟:

1、在劃分好模塊后,首先自己先估算一下每個模塊所需要的開發(fā)時間。

2、然后召集所有開發(fā)人員,討論模塊的分配和開發(fā)時間估算。將劃分好的模塊,讓開發(fā)人員從中挑選他們感興趣的模塊。這樣做可以提高開發(fā)人員的主動性和參與性。在分配模塊的時候還需從以下幾方面考慮,以確保開發(fā)的速度和質(zhì)量: A、相同類似的模塊由同一人負(fù)責(zé)開發(fā),比如用戶管理的增刪改由同一開發(fā)者負(fù)責(zé)。

這樣做的好處就是開發(fā)者對相關(guān)邏輯會更加熟悉,同時接口的定義也會比較明確,溝通的成本比較低,同時功能實現(xiàn)的缺陷也相應(yīng)的會降低。

B、技術(shù)難度比較大的模塊由技術(shù)水平比較高的人負(fù)責(zé)。C、業(yè)務(wù)邏輯比較復(fù)雜的由對這塊邏輯比較了解的人負(fù)責(zé)。

3、模塊分配完后,開發(fā)人員評估自己負(fù)責(zé)開發(fā)的模塊所需要的時間。在此過程中最好做到要和開發(fā)者比較詳細的討論每個模塊的技術(shù)實現(xiàn),以便使時間的估算更加準(zhǔn)確。

4、對開發(fā)人員估算的時間進行確認(rèn)。在確認(rèn)過程中作為項目管理者應(yīng)參考以上提到的三個因素,同時將自己估算的時間和開發(fā)人員估算的時間進行比較。這其中的差異當(dāng)然會存在的。對于那些差異比較大的,將與技術(shù)人員探討其中的緣由。對于時間周期比較長的任務(wù),盡量將任務(wù)通過再細分的手段細化任務(wù),爭取每個任務(wù)的最長時間不超過3天;時間周期越長的任務(wù),不確定性越高,風(fēng)險也越高,越有可能成為項目的瓶頸,影響項目的進度。

2、Code Review Code Review是保證項目中代碼質(zhì)量非常重要的一個環(huán)節(jié),在這一環(huán)中我們公司做的非常欠缺,把關(guān)不嚴(yán)格;這是導(dǎo)致每次測試后出現(xiàn)大量bug的主要原因,這一環(huán)需要納入績效考核中,實行責(zé)任追究制,實施重點監(jiān)控。出現(xiàn)這樣的薄弱環(huán)節(jié),造成這樣的原因,我想也是有很多因素造成的;比如開發(fā)人員對需求不是很明確,以自己比較主觀的因素去完成任務(wù)的;還有對整個系統(tǒng)業(yè)務(wù)邏輯沒有正確的清晰的認(rèn)識的原因,以及對項目組成員培訓(xùn)不到位的原因等眾多因素糾集在一起才產(chǎn)生的。

如何做好這方面的工作?首先編碼要有“編碼規(guī)范”文檔,Code Review要有“代碼審

核規(guī)范”文檔:記錄代碼實現(xiàn)應(yīng)該遵循的標(biāo)準(zhǔn)。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn),代碼編寫者必須要嚴(yán)格按照規(guī)范來進行;代碼審核者根據(jù)這些標(biāo)準(zhǔn)來Code Review代碼,同時在Code Review過程中不斷完善該文檔。

在做好這些前期工作的前提下,分以下幾個步驟來實施:

1、檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。

2、從代碼的易維護性、可擴展性角度考察代碼的質(zhì)量,提出修改建議。

3、代碼編寫者和代碼審核者坐在一起,由代碼編寫者按照Use Case依次講解自己負(fù)責(zé) 的代碼和相關(guān)邏輯,從Web層-到Manage層再到Dao層;

4、代碼審核者在此過程中可以隨時提出自己的疑問,同時積極發(fā)現(xiàn)隱藏的bug;對這

些bug記錄在案。

5、代碼講解完畢后,代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一

行一行靜下心來看。同時代碼又要全面的看,以確保代碼整體上設(shè)計優(yōu)良。

6、代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報告”,“審核報告”中記錄發(fā)現(xiàn)的問題

及修改建議,然后把“審核報告”發(fā)送給相關(guān)人員。

7、代碼編寫者根據(jù)“代碼審核報告”給出的修改意見,修改好代碼,有不清楚的地方

可積極向代碼審核者提出。

8、代碼編寫者bug fixed完畢之后給出反饋。

9、代碼審核者把Code Review中發(fā)現(xiàn)的有價值的問題更新到“代碼審核規(guī)范”的文檔中, 對于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。如果通過以上步驟,還因為是代碼編寫者的原因而出現(xiàn)嚴(yán)重的缺陷問題,將通過績效考核來加深代碼編寫者的印象,并在周報會議上做通報批評。

3、需求變更管理

需求變更管理也是項目管理中最重要的一個環(huán)節(jié),對需求變更管理的有效性將直接影響項目的成功與否。

對待需求變更的態(tài)度:

1、需求變更是不可避免的。

2、需求變更要必須被管理。

3、積極發(fā)現(xiàn)引起變更的因素,促使變更盡可能早的出現(xiàn),減低變更帶來的風(fēng)險。需求變更管理的目標(biāo):

1、相關(guān)的干系人必須清楚地了解發(fā)生的變更。

2、變更處于有效的管理中。

3、盡量降低變更帶來的風(fēng)險。

通過制定需求變更的流程,確保項目中的需求變更有效地進行,實現(xiàn)上述的目標(biāo)。需求變更流程:

1、確定需求的基準(zhǔn)線。將以User Case作為需求基準(zhǔn)線,在User Case確認(rèn)之后的任何需求改變,都需要走需求變更流程,這一環(huán)節(jié)我們基本沒有,期間有時候使的工

作很混亂,也就是因為沒有一個規(guī)范的變更流程而造成的;如果建立了這么一個流程規(guī)范和機制,需求變更沒有走這個流程的將不被認(rèn)可。

2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。

3、項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關(guān)人員討論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍,進

度,費用,質(zhì)量等計劃。項目管理者作為項目的負(fù)責(zé)人,對項目的成功與否負(fù)有主要的責(zé)任。所以需求變更的決策者應(yīng)該由項目管理者承擔(dān)。

4、需求變更確認(rèn)后由專人將需求變更記錄下來,通知給項目中所有成員。其中以下人員對需求的變更是緊密相關(guān)的,他們必須知曉并認(rèn)可此需求變更。包括(客戶方,需求分析人員,測試人員,相關(guān)開發(fā)人員。需求變更記錄格式如下: 序號變更提出時間變更描述變更類型(是 對原有需求 的修改還是 新增需求 原因變更提出 者

開發(fā)人員對進度的 影響(工 作量 2

5、確定變更的負(fù)責(zé)人。承擔(dān)需求變更的具體工作,比如基線控制,對需求變更的記錄,并通知相關(guān)人員。

6、相關(guān)人員接收到確認(rèn)的需求變更后,做以下事情。需求分析人員修改需求說明書和User Case的相關(guān)內(nèi)容。測試人員修改測試用例的相關(guān)內(nèi)容。開發(fā)人員修改代碼中的相關(guān)部分。

7、按照變更后的計劃實施項目,并進行檢查,跟蹤,對變更后的實施反饋和可能出現(xiàn)的問題及時溝通和處理。

8、需求凍結(jié)。項目越到后期,需求變更對項目的影響就越大,所以在一定時候要進入需求凍結(jié)階段,不再接收新需求或需求的變更。

4、風(fēng)險管理

風(fēng)險管理是項目管理者最重要的工作之一。風(fēng)險管理是一個持續(xù)的過程,貫穿于整個項目過程中,風(fēng)險管理包括風(fēng)險識別、風(fēng)險評估、風(fēng)險解決以及風(fēng)險管理策略。

在項目的實施過程中需要不斷地識別和應(yīng)對風(fēng)險,并加以有效的控制,風(fēng)險管理的好與壞直接影響項目的實施效果,從某種意義上講,項目實施對于項目管理者就是識別、分析、應(yīng)對、控制風(fēng)險的過程,使項目的約束性目標(biāo)和質(zhì)量目標(biāo)朝有利的方向發(fā)展。

項目不同于日常任務(wù),它有明確的起止時間和目標(biāo),要在明確的范圍、時間和成本約束下,達到相應(yīng)的質(zhì)量標(biāo)準(zhǔn),并取得用戶的滿意。影響項目成敗的因素涉及方方面面,并且風(fēng)險伴隨著項目的始終,是客觀存在的,作為一個項目管理者,應(yīng)該具備良好的風(fēng)險控制意識,善于識別風(fēng)險并分析風(fēng)險的影響,從中發(fā)現(xiàn)影響目標(biāo)的風(fēng)險點,并施

加影響或采取應(yīng)對措施,把風(fēng)險的負(fù)面影響降到最低,并且風(fēng)險控制應(yīng)該貫穿項目始終。

風(fēng)險引起的負(fù)面后果集中體現(xiàn)在進度延后、成本超支、質(zhì)量不達標(biāo)等方面,導(dǎo)致這些問題的因素主要包括目標(biāo)以及需求不明確、范圍蔓延以及需求變更、代碼質(zhì)量或返工風(fēng)險、人員技能和資源的不足、缺乏良好的團隊協(xié)作等。下面將詳細描述一下這些問題以及出現(xiàn)這些問題時的應(yīng)對方案:

1、目標(biāo)以及需求不明確

為了市場競爭或內(nèi)部管理決策的需要,業(yè)務(wù)部門提出的需求往往要求的時間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達上,沒有形成正式的業(yè)務(wù)需求文檔,在沒有明確的需求范圍的情況下,有時為了迎合業(yè)務(wù)部門的口味匆匆開工,過程中用戶不斷地提出新的想法,技術(shù)人員開始疲于奔命和應(yīng)付,很難保證項目的進度和質(zhì)量,也難以取得業(yè)務(wù)部門的認(rèn)可。所以,在項目的前期一定要采取相應(yīng)的手段或措施,與業(yè)務(wù)部門共同明確項目目標(biāo)、需求范圍,充分考慮現(xiàn)有的時間和資源約束,將需求排定優(yōu)先級, 對于關(guān)鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取 得業(yè)務(wù)部門的書面確認(rèn)。在此過程中要注重挖掘用戶的隱性需求，可以通過引導(dǎo)、系統(tǒng) 原型等手段讓用戶在前期充分暴露自己的想法和需求。

2、范圍蔓延以及需求變更 在有了明確的目標(biāo)和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務(wù)部門在 看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控 制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項目進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴(yán)格的變更控制流程，不能礙于面子，否則最終的 結(jié)果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相 關(guān)團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負(fù)責(zé)人根據(jù)分析結(jié)果判斷 是否批準(zhǔn)，如果批準(zhǔn)，那項目組可以安排實施，否則，正式拒絕用戶的請求，當(dāng)然實際 情況下可以采取一些軟措施緩解矛盾。需求變更風(fēng)險：需求已經(jīng)打上了基線，但此后仍然有變更

發(fā)生，對項目造成影響。如何減少此類風(fēng)險的發(fā)生？ 前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關(guān)職能主管、客戶，所有的需求要經(jīng) 過他們的認(rèn)可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風(fēng)險。需求討論、需求確 認(rèn)、User Case 確認(rèn)、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變 更時，嚴(yán)格按照需求變更流程執(zhí)行。在分析設(shè)計階段的中的確認(rèn)和評審也是降低此類風(fēng) 險的重要手段。

3、代碼質(zhì)量或返工風(fēng)險 質(zhì)量風(fēng)險主要指開發(fā)代碼的質(zhì)量。如何提高開發(fā)人員開發(fā)的質(zhì)量？在制定項目計劃 時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質(zhì)量的影響也很大。有 時開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務(wù)，可能就存在很大的開發(fā) 質(zhì)量問題。開發(fā)要有一套嚴(yán)格可行的代碼規(guī)范，編碼時嚴(yán)格遵守，到現(xiàn)在為止，我們這 個方面做的不是很規(guī)范，做的也很不足，大家編寫的代碼隨意性比較大，代碼編寫者的 主觀意識性比較強。要建立一套大家認(rèn)可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，code review 時嚴(yán)格考核。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設(shè)計文檔對 指導(dǎo)開發(fā)非常重要。返工是項目組最不愿意看到的，既浪費人力、物力和財力，又影響團隊積極性。需 求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質(zhì)量沒有達到用 戶要求。往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是 100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題，不得不花費很大精力回頭 排查、修改程序，造成這種情況的主要原因是過程中質(zhì)量保證沒有做到位，把大部分問 題留在了后面。這就需要在項目實施過程中采取有效的措施來規(guī)避返工的風(fēng)險，通常的 做法有同行評審，比如概要設(shè)計完成之后，邀請其他項目組的技術(shù)專家進行技術(shù)評審以 發(fā)現(xiàn)架構(gòu)設(shè)計問題； 管理評審，通過組織級的質(zhì)量審計看產(chǎn)品以及實施過程是否滿足質(zhì) 量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要 求的代碼，走查通常能夠發(fā)現(xiàn) 50%-70%的錯誤；每日構(gòu)建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應(yīng)的錯誤，日構(gòu)建一般在 項目的中后期開始，每天自動從版本服務(wù)器上獲取源代碼進行自動編譯和測試。

4、人員技能和資源的不足 項目實施過程中由于人員技能欠缺造成的進

度延后和軟件質(zhì)量問題并不少見，一個 熟練的技術(shù)人員完成同樣一個任務(wù)需要 3 天，但一個生手可能就需要 7-10 天。項目管

理者應(yīng)該在前期就分析清楚項目所要采用的技術(shù)以及相應(yīng)的人員技能要求，針對不同的 角色，及時采取相應(yīng)的技能培訓(xùn)，以保證項目的順利實施。如果對于項目中某些部分專 業(yè)性特別強或新技術(shù)，短期內(nèi)又不能快速建立技能的情況，可以考慮將該塊任務(wù)外包，借鑒合作商的力量降低實施風(fēng)險，當(dāng)然要進行外購人力成本與自建人力成本的效益分 析。開發(fā)過程中遇到技術(shù)難題，導(dǎo)致開發(fā)時間延遲或者需求不得不發(fā)生變更。如何減少 此類風(fēng)險的發(fā)生？在項目開始前的技術(shù)評估階段，明確技術(shù)難點，提前安排人員進行攻 克。如果在可預(yù)期的時間內(nèi)無法解決，如果可以，將向需求提出方要求變更需求或?qū)ふ?可替代方案。這樣的風(fēng)險應(yīng)該在項目的前期階段就應(yīng)該解決在萌芽狀態(tài)來避免這樣的風(fēng) 險在后期或中期出現(xiàn)。項目所需人力資源無法按時到位，導(dǎo)致資源風(fēng)險。如何減少此類風(fēng)險的發(fā)生？這個 就需要在項目計劃制定的時候提前申請確認(rèn)資源，并在項目過程中不斷溝通協(xié)調(diào)。

5、缺乏良好的團隊協(xié)作 軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各 模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清 楚工作界面及接口關(guān)系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產(chǎn)出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在 的風(fēng)險問題，在項目啟動和團隊組建的時候就應(yīng)該加以規(guī)避這樣的風(fēng)險出現(xiàn)。項目風(fēng)險管理的要點：

1、上述我們所說的風(fēng)險管理都是指可以預(yù)期將要發(fā)生的風(fēng)險，那些不可預(yù)期將要發(fā)生 的風(fēng)險不屬于風(fēng)險管理的范疇。這也將是考驗一個項目管理者的經(jīng)驗和知識對能否 管理好風(fēng)險至關(guān)重要的內(nèi)容。

2、對不可預(yù)期的風(fēng)險，項目管理者要有潛在的風(fēng)險意識評估，做好一些可操作性的預(yù) 案準(zhǔn)備。

3、詳細明確的項目計劃、以及項目執(zhí)行過程中每個要點的質(zhì)量保證是降低項目風(fēng)險的 必要條件。

4、風(fēng)險報告是項目團隊以及領(lǐng)導(dǎo)了解項目風(fēng)險的一個有效手段。風(fēng)險報告的格式： 序號 風(fēng)險簡介 對項目的影響 解決方案或?qū)Σ?/p>

5、團隊管理 團隊就是一組個體為實現(xiàn)共同的目標(biāo)而相互依賴、一起工作的共同體。團隊工作顧名思 義就是團隊成員為實現(xiàn)這個共同的目標(biāo)而付出的共同努力，項目團隊的工作是否有效直接關(guān) 系到

項目的成敗。團隊管理是個漸進的過程。世界上只有完美的團隊，沒有完美的個人。好的高效的團隊 不是管理出來的，而是營造出來的。團隊成員需要有大家可認(rèn)同的團隊文化，這需要大家共 同的努力。

1、營造良好的工作環(huán)境和氛圍。

2、建設(shè)優(yōu)秀或鮮明的團隊文化。

3、保持高效的溝通。

6、項目會議 組織會議是項目管理者日常工作中一項非常重要的工作任務(wù)，項目過程中很多重要的決 定都是在會議中做出的，也有很多由于不成功的會議而對項目本身造成了不好的影響。首先看看不成功的會議常常表現(xiàn)為哪些形式：

1、會議氛圍不好，參與者發(fā)言不踴躍；

2、會議討論常常偏離主題；

3、會議沒有取得預(yù)期的結(jié)果；

4、會議時間常常一拖再拖。這些不成功的會議最終的結(jié)果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應(yīng)該注意的問 題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：

1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有 可能取得成功，這是會議成功的充分條件。

2、會議的組織者和參與者的想法通常是不一致的，有時候甚至?xí)笙鄰酵?。所以不?希望會議的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只 是一個發(fā)表想法的人，他不用對會議的成功承擔(dān)責(zé)任。

3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。組織會議的十一條最佳實踐：

1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。

2、提前發(fā)出會議議程，以便會議參與者知道他們來做什么。

3、請對人很重要，不要把非必要的人召來開會，當(dāng)然也不要漏掉那些關(guān)鍵人物。在確 保必要人物都在的情況下一次會議參與者越少效果越好。

4、提前預(yù)約參與者的時間，以確保他們能按時到場。

5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在 開場時說： A、再一次強調(diào)會議的目標(biāo)，我們來做什么。B、強調(diào)會議的主題與基調(diào)。比如：本次會議是一個需求確認(rèn)會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論 如何做上面。C、說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人 的講 話，等別人說完你再說等等。

6、會議過程中時刻注意引導(dǎo)和控制會議，以確保會議按照目

標(biāo)進行。一次會議的氛圍 是否良好，討論是否充分，好的引導(dǎo)至關(guān)重要。比如多提一些開放式的問題。

7、會議記錄很重要，把一些結(jié)論和有價值的內(nèi)容記錄下來，這些是本次會議的重要成 果之一。

8、會議要有結(jié)論。我們常在會議上聽到有人說：“大家討論了這么半天，結(jié)論呢？”。沒有結(jié)論的會議是沒有意義的。

9、會議后別忘發(fā)會議紀(jì)要，以及一些 Action，什么人什么時候做什么。

10、會議后的 action 執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知 了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性 也會降低。很多會議往往都不注意這一點。

11、按時結(jié)束的會議會受到所有人的歡迎。

7、版本控制 版本控制也是項目管理者的一個重要工作內(nèi)容之一，一個項目或產(chǎn)品的完成不可能是一 步到位的，在項目完成的后期可能會有多個不同的版本的發(fā)布（開發(fā)版本，測試版本，發(fā)布 版本等）。需要做好版本的管理和控制。

8、項目總結(jié) 在項目完成后，總結(jié)整個完成項目的過程和經(jīng)歷，為下一次的項目啟動提供參考經(jīng)驗，完善不足，避免在類似的項目中出現(xiàn)可能存在的相同的錯誤發(fā)生。

第五篇：物業(yè)公司住宅小區(qū)物業(yè)項目管理系統(tǒng)軟件開發(fā)實施方案

物業(yè)公司住宅小區(qū)物業(yè)項目管理系統(tǒng)

軟件開發(fā)實施方案

1.前言

對物業(yè)公司而言，高質(zhì)量的物業(yè)管理能提高物業(yè)市場競爭力，使開發(fā)企業(yè)的房產(chǎn)暢銷，加速資金周轉(zhuǎn)。同時，完善的物業(yè)管理能為開發(fā)商樹立良好的企業(yè)形象，吸引更多的房地產(chǎn)交易商和消費者。在環(huán)境效益上，住宅區(qū)內(nèi)的環(huán)境和布局、治安等與整個建設(shè)風(fēng)貌融為一體，提高了房地產(chǎn)業(yè)的綜合效益。

2.項目概述

本公司住宅小區(qū)物業(yè)業(yè)務(wù)增多，對物業(yè)管理軟件的需求呈上升趨勢，公司股東會議決定投入資金開發(fā)一套小區(qū)物業(yè)項目管理軟件，提供有關(guān)住宅小區(qū)物業(yè)管理用信息網(wǎng)，并能夠盡可能采用各種計算機和通信技術(shù)，為住戶提供快速、準(zhǔn)確和渠道多樣的服務(wù)。因此，開發(fā)這樣一套小區(qū)物業(yè)項目管理系統(tǒng)軟件成為很有必要的事情，為了完成該軟件，本文制定出相應(yīng)的詳細計劃。

3.功能需求

3.1.功能介紹

典型的小區(qū)物業(yè)管理系統(tǒng)主要應(yīng)具有以下管理功能：

a)系統(tǒng)用戶管理；管理使用該系統(tǒng)的用戶信息，包括系統(tǒng)用戶的添加、修改、刪除；

b)樓盤信息管理：管理小區(qū)中樓盤的基本信息，包括樓盤信息的添加、修改、刪除、查詢；

c)住戶信息管理：管理小區(qū)住戶的各種信息，包括住戶信息的添加、修改、刪除、查詢；

d)停車場管理：管理停車場的各種信息，包括停車場信息的添加、修改、刪

除、查詢；

e)物業(yè)收費管理：管理小區(qū)內(nèi)的各種收費項目，比如水費、電費、物業(yè)費等，包括收費項目的添加、修改、刪除、查詢；

f)住戶報修管理：管理住戶報修信息，包括住戶報修信息的添加、修改、刪

除、查詢；

g)住戶投訴管理：管理住戶投訴信息，包括住戶投訴信息的添加、修改、刪

除、查詢。

3.2.開發(fā)過程

“小區(qū)物業(yè)管理系統(tǒng)”的開發(fā)過程是根據(jù)軟件的生命周期的原理和方法進行的，包括以下幾個階段：

a)確定課題，根據(jù)需要制定相應(yīng)的項目計劃，并完成項目計劃書； b)對軟件進行可行性分析，并完成可行性分析報告；

c)對小區(qū)進行調(diào)研并了解軟件的需求分析，完成需求分析說明書； d)軟件的總體設(shè)計和詳細設(shè)計，并完成相應(yīng)文檔； e)根據(jù)要實現(xiàn)的功能，完成軟件的編碼； f)對開發(fā)的軟件進行測試； g)確認(rèn)和評審； h)交付使用。

××物業(yè)公司小區(qū)物業(yè)項目管理系統(tǒng)WBS分解:

3.3.工作任務(wù)的分配及人員分工

軟件開發(fā)過程中的工作任務(wù)的分配及人員的分工如下表所示：

3.4.開發(fā)和運行環(huán)境

小區(qū)物業(yè)管理系統(tǒng)開發(fā)和運行環(huán)境如下：

a)開發(fā)環(huán)境：windows XP b)開發(fā)工具：×××編程語言 c)數(shù)據(jù)庫管理系統(tǒng)：×××數(shù)據(jù)庫平臺 d)運行環(huán)境：windows 98/XP/2000

3.5.項目進度

項目單代號網(wǎng)絡(luò)圖：

項目里程碑圖：

計劃

3.6.費用開支

軟件開發(fā)過程中的費用開支如下：

4.項目關(guān)鍵問題

a)項目計劃制定的不詳細時，后期工作不好做；

b)需求分析做不到位的話，軟件可能不能滿足用戶的需求；

c)系統(tǒng)各個小模塊不能很好的融合到一起，使其成為一個有機的整體； d)數(shù)據(jù)流圖和關(guān)系模型的建立。

5.總結(jié)分析

其實，任何一個項目在執(zhí)行過程中都會碰到許多問題的，評價一個項目是否成功并不能以碰到問題的多少作為標(biāo)準(zhǔn)，其標(biāo)準(zhǔn)應(yīng)是按時、保質(zhì)實現(xiàn)預(yù)先確定的各項指標(biāo)，比如說系統(tǒng)的功能、系統(tǒng)的性能等，完成合同要求內(nèi)容，也要提供優(yōu)質(zhì)的服務(wù)，搞好與客戶關(guān)系；同時也要規(guī)范管理，為公司今后的工作積累技術(shù)信息，市場信息，人才資源和管理經(jīng)驗，提升企業(yè)形象，保障事業(yè)的進一步發(fā)展。

總之，項目成敗取決于很多因素，項目管理中的溝通是關(guān)系到項目成敗的關(guān)鍵之一。大型的IT應(yīng)用項目不僅僅是一個技術(shù)工作，更是一場管理變革。