第一篇：軟件開發(fā)項目計劃書格式

正文

一、項目計劃書格式

根據(jù)《GB8567－88計算機軟件產(chǎn)品開發(fā)文件編制指南》中項目開發(fā)計劃的要求，結合實際情況調(diào)整后的《項目計劃書》內(nèi)容索引如下： 1 引言 1.1 編寫目的 1.2 背景 1.3 定義 1.4 參考資料

1.5 標準、條約和約定 2 項目概述 2.1項目目標 2.2產(chǎn)品目標與范圍 2.3假設與約束 2.4 項目工作范圍 2.5 應交付成果 2.5.1 需完成的軟件 2.5.2 需提交用戶的文檔 2.5.3 須提交內(nèi)部的文檔 2.5.4 應當提供的服務 2.6 項目開發(fā)環(huán)境 2.7 項目驗收方式與依據(jù) 3 項目團隊組織 3.1 組織結構 3.2 人員分工 3.3 協(xié)作與溝通 3.3.1 內(nèi)部協(xié)作 3.3.2 外部溝通 4 實施計劃 4.1 風險評估及對策 4.2 工作流程 4.3 總體進度計劃 4.4 項目監(jiān)控 4.4.1 質(zhì)量控制計劃 4.4.2 進度監(jiān)控計劃 4.4.3 預算監(jiān)控計劃 4.4.4 配置管理計劃 5 支持條件

5.1 內(nèi)部支持（可選）5.2 客戶支持（對項目而言）5.3 外包（可選）6 預算（可選）6.1 人員成本 6.2 設備成本 6.3 其它經(jīng)費預算 6.4 項目合計經(jīng)費預算 7 關鍵問題 8專題計劃要點

二、項目計劃書的編寫說明 1 引言 1.1 編寫目的

說明編寫這份項目計劃的目的，并指出預期的讀者。

作用：本節(jié)是為了說明編制“項目計劃書”亦即本文檔的意圖和希望達到的效果。注意這里的“目的”不是“項目目標”，而是為了說明本文檔的目的與作用?！绊椖磕繕恕痹?.1中說明。

意義：使項目成員和項目干系人了解項目開發(fā)計劃書的作用、希望達到的效果。開發(fā)計劃書的作用一般都是“項目成員以及項目干系人之間的共識與約定，項目生命周期所有活動的行動基礎，以便項目團隊根據(jù)本計劃書開展和檢查項目工作?！?/p>

例如可以這么寫：為了保證項目團隊按時保質(zhì)地完成項目目標，便于項目團隊成員更好地了解項目情況，使項目工作開展的各個過程合理有序，因此以文件化的形式，把對于在項目生命周期內(nèi)的工作任務范圍、各項工作的任務分解、項目團隊組織結構、各團隊成員的工作責任、團隊內(nèi)外溝通協(xié)作方式、開發(fā)進度、經(jīng)費預算、項目內(nèi)外環(huán)境條件、風險對策等內(nèi)容做出的安排以書面的方式，作為項目團隊成員以及項目干系人之間的共識與約定，項目生命周期內(nèi)的所有項目活動的行動基礎，項目團隊開展和檢查項目工作的依據(jù)。

常見的問題：把項目本身的“項目目標”誤作編制項目開發(fā)計劃的目的。1.2 背景

主要說明項目的來歷，一些需要項目團隊成員知道的相關情況。主要有以下內(nèi)容：

項目的名稱：經(jīng)過與客戶商定或經(jīng)過立項手續(xù)統(tǒng)一確定的項目名稱，一般與所待開發(fā)的軟件系統(tǒng)名稱有較大的關系，如針對“XX系統(tǒng)”開發(fā)的項目名稱是“XX系統(tǒng)開發(fā)”。

項目的委托單位：如果是根據(jù)合同進行的軟件開發(fā)項目，項目的委托單位就是合同中的甲方；如果是自行研發(fā)的軟件產(chǎn)品，項目的委托單位就是本企業(yè)。

項目的用戶（單位）：軟件或網(wǎng)絡的使用單位，可以泛指某個用戶群。注意項目的用戶或單位有時與項目的委托單位是同一個，有時是不一樣的。如海關的報關軟件、稅務的報稅軟件，委托單位是海關或稅務機關，但使用的用戶或單位不僅有海關或稅務機關，還包括需要報關、報稅的企業(yè)單位。

項目的任務提出者：本企業(yè)內(nèi)部提出需要完成此項目的人員，一般是領導或商務人員；注意項目的任務提出者一般不同于項目的委托單位，前者一般是企業(yè)內(nèi)部的人員。如果是內(nèi)部開發(fā)項目，則兩者的區(qū)別在于前者指人，后者指單位。

項目的主要承擔部門：有些企業(yè)根據(jù)行業(yè)方向或工作性質(zhì)的不同把軟件開發(fā)分成不同的部門（也有的分為不同事業(yè)部）。項目的特點就是其矩陣式組織，一般一個項目的項目成員可能由不同的部門組成，甚至可能由研發(fā)部門、開發(fā)部門、測試部門、集成部門、服務部門等等其中幾個組成。需要根據(jù)項目所涉及的范圍確定本項目的主要承擔部門。

項目建設背景：從政治環(huán)境上、業(yè)務環(huán)境上說明項目建設背景，說明項目的大環(huán)境、來龍去脈。這有利于項目成員更好地理解項目目標和各項任務。

例句：根據(jù)《某部關于某建設工作的實施意見》精神，為了保障某建設工作的正常實施，必須加強監(jiān)督考核，建立督查通報制度，某市某建設工作小組辦公室把此項建設工作實施列入督查的重要內(nèi)容，及時掌握進度，相關部門建立市某建設工作簡報制度，及時反映全市某建設工作動態(tài)。

目前對于某建設工作的工作主要采用計劃部門手工編制年度計劃、建設工作主管部門和建設工作實施單位聯(lián)合手動編制進度計劃，某建設工作單位手工上報建設工作進度情況的方式，而全市的建設工作有數(shù)百個，加上前期建設工作的數(shù)量和今后某市建設發(fā)展的趨勢，建設工作的數(shù)量將越來越多，原來的工作模式已經(jīng)越來越無法適應市委市政府的要求。因此，充分利用現(xiàn)代信息化、因特網(wǎng)的優(yōu)勢，建立“某市某建設工作信息報送反饋系統(tǒng)”，提高某建設工作信息報送反饋工作效率，提高信息的及時性、減輕各級相關工作人員的勞動強度是非常有必要和緊迫的任務。

軟件系統(tǒng)與其他系統(tǒng)的關系：說明與本系統(tǒng)有關的其他系統(tǒng)，說明它們之間的相互依賴關系。這些系統(tǒng)可以是這個系統(tǒng)的基礎性系統(tǒng)（一些數(shù)據(jù)、環(huán)境等必須依靠這個系統(tǒng)才能運行），也可以是以這個系統(tǒng)為基礎的系統(tǒng)，或者是兩者兼而有之的關系、互相依賴的系統(tǒng)。例句：本系統(tǒng)中對外部辦公部分如需要各個建設單位報送材料的子系統(tǒng)應當掛在市政府網(wǎng)站。

軟件系統(tǒng)與機構的關系：說明軟件系統(tǒng)除了委托單位和使用單位，還與哪些機構組織有關系。例如一些系統(tǒng)需要遵守那些組織的標準、需要通過那些組織機構的測試才能使用等等、是否需要外包或與那些組織機構合作。1.3 定義

列出為正確理解本計劃書所用到的專門術語的定義、外文縮寫詞的原詞及中文解釋。注意盡量不要對一些業(yè)界使用的通用術語進行另外的定義，使它的含義和通用術語的慣用含義不一致。1.4 參考資料

列出本計劃書中所引用的及相關的文件資料和標準的作者、標題、編號、發(fā)表日期和出版單位，必要時說明得到這些文件資料和標準的途徑。本節(jié)與下一節(jié)的“標準、條約和約定”互為補充，注意“參考資料”未必作為“標準、條約和約定”，因為“參考”的不一定是“必須遵守”的。常用資料如： 本項目的合同、標書、上級機關有關通知、經(jīng)過審批的項目任務書； 屬于本項目的其他已經(jīng)發(fā)表的文件；

本文檔中各處引用的文件、資料，包括所要用到的軟件開發(fā)標準。1.5 標準、條約和約定

列出在本項目開發(fā)過程中必須遵守的標準、條約和約定。例如：相應的《立項建議書》、《項目任務書》、合同、國家標準、行業(yè)標準、上級機關有關通知和實施方案、相應的技術規(guī)范等。

“參考資料”一般具有“物質(zhì)”特性，一般要說明參照了什么，要說明在哪里可以獲得；“標準、條約和約定”一般具有“精神”特性，一般是必須遵守的，不說明在哪里可以獲得。參考資料的內(nèi)容應該涵蓋“標準、條約和約定”。

<項目名稱>

軟件開發(fā)計劃

版本

<1.0>

[注：以下提供的模板用于

Rational Unified Process。其中包括用方括號括起來并以藍色斜體（樣式=InfoBlue）顯示的文本，它們用于向作者提供指導，在發(fā)布此文檔之前應該將其刪除。按此樣式輸入的段落將被自動設置為普通樣式（樣式=正文）。]

修訂歷史記錄

日期

版本

說明

作者

<日/月/年>

<詳細信息>

<姓名>

目錄

1.簡介

1.1 目的 1.2 范圍

1.3 定義、首字母縮寫詞和縮略語

1.4 引用

1.5 概述

2.項目概述

2.1 項目的目的、規(guī)模和目標

2.2 假設與約束

2.3 項目的可交付工件

2.4 軟件開發(fā)計劃的演進

3.項目組織

3.1 組織結構

3.2 外部接口

3.3 角色與職責

4.管理流程

4.1 項目估計

4.2 項目計劃

4.2.1 階段計劃

4.2.2 迭代目標

4.2.3 發(fā)布版

4.2.4 項目時間表

4.2.5 項目資源分配

4.2.5.1 人員配備計劃

4.2.5.2 資源獲取計劃

4.2.5.3 培訓計劃

4.2.6 預算

4.3 迭代計劃

4.4 項目監(jiān)測與控制

4.4.1 需求管理計劃

4.4.2 進度控制計劃

4.4.3 預算控制計劃

4.4.4 質(zhì)量控制計劃

4.4.5 報告計劃

4.4.6 評測計劃

4.5 風險管理計劃

4.6 收尾計劃

5.技術流程計劃

5.1 開發(fā)案例

5.2 方法、工具和技術

5.3 基礎設施計劃

5.4 產(chǎn)品驗收計劃

6.支持流程計劃

6.1 配置管理計劃

6.2 評估計劃

6.3 文檔計劃

6.4 質(zhì)量保證計劃

6.5 問題解決計劃

6.6 分包商管理計劃

6.7 流程改進計劃

7.其他計劃

8.附錄

9.索引

軟件開發(fā)計劃

1.簡介

[軟件開發(fā)計劃的簡介應提供整個文檔的概述。它應包括此軟件開發(fā)計劃的目的、范圍、定義、首字母縮寫詞、縮略語、引用和概述。]

1.1

目的[闡明此軟件開發(fā)計劃的目的。]

1.2

范圍

[簡要說明此軟件開發(fā)計劃的范圍：它的相關項目，以及受到此文檔影響的任何其他事物。]

1.3

定義、首字母縮寫詞和縮略語

[本小節(jié)應提供正確理解此軟件開發(fā)計劃所需的全部術語、首字母縮寫詞和縮略語的定義。

這些信息可以通過引用項目詞匯表來提供。]

1.4

引用

[本小節(jié)應完整地列出此軟件開發(fā)計劃中其他部分所引用的所有文檔。

每個文檔應標有標題、報告號（如果適用）、日期和發(fā)布組織。列出可從中獲取這些引用的來源。這些信息可以通過引用附錄或其他文檔來提供。

對于軟件開發(fā)計劃，所引用工件的列表中應包括：

_

迭代計劃

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

_

需求管理計劃

評測計劃

風險管理計劃

開發(fā)案例

業(yè)務建模指南

用戶界面指南

用例建模指南

設計指南

編程指南

測試指南

手冊風格指南

基礎設施計劃

產(chǎn)品驗收計劃

配置管理計劃

評估計劃（僅當該計劃是單獨的計劃時，但它通常是文檔計劃

質(zhì)量保證計劃

問題解決計劃

SDP 的6.2 節(jié)）

_

分包商管理計劃

_

流程改進計劃]

1.5

概述

[本小節(jié)應說明此軟件開發(fā)計劃中其他部分所包含的內(nèi)容，并解釋文檔的組織方式。]

2.項目概述

2.1

項目的目的、規(guī)模和目標

[簡要說明此項目的目的與目標，以及此項目將要交付的可交付工件。]

2.2

假設與約束

[列出此計劃所依據(jù)的假設和對項目的所有約束（如預算、人員、設備、時間表等）。]

2.3

項目的可交付工件

[以表格的形式列出將在項目中創(chuàng)建的工件，包括目標交付日期。]

2.4

軟件開發(fā)計劃的演進

[以表格的形式列出軟件開發(fā)計劃的提議版本，以及在計劃外修訂與重新發(fā)行此計劃需符合的標準。]

3.項目組織

3.1

組織結構

[說明項目團隊（包括管理人員和其他復審委員會）的組織結構。]

3.2

外部接口

[說明項目與外部組織聯(lián)系的方式。

對于每個外部組織，應確定其內(nèi)部和外部聯(lián)系人的姓名。]

3.3

角色與職責

[確定將負責各個核心工作流程、工作流程明細和支持流程的項目組織單位。]

4.管理流程

4.1

項目估計

[提供所估計的項目成本與進度、這些估計所依據(jù)的基礎，以及項目中將重新進行估計的時間點和情況。]

4.2

項目計劃

4.2.1

階段計劃

[包括以下內(nèi)容：

_

工作細分結構

(WBS)

_

顯示項目各階段或迭代的時間分配情況的時間線或甘特圖

_

確定主要里程碑及其成就標準

確定所有重要的發(fā)布點和演示版]

4.2.2

迭代目標

[列出每次迭代將要實現(xiàn)的目標。]

4.2.3

發(fā)布版

[簡要說明每個軟件發(fā)布版，并指出它是否是演示版、Beta 版等。]

4.2.4

項目時間表

[用圖表顯示完成迭代與階段、發(fā)布點、演示版及其他里程碑的目標日期。]

4.2.5

項目資源分配

4.2.5.1

人員配備計劃

[在此處確定所需人員的數(shù)目和類型，以及項目階段或迭代需要的任何特殊技能或經(jīng)驗。]

4.2.5.2

資源獲取計劃

[說明您將如何發(fā)現(xiàn)并得到項目所需的人員。]

4.2.5.3

培訓計劃

[列出項目團隊成員需要的所有特殊培訓，以及完成這些培訓的目標日期。]

4.2.6

預算

[按照

WBS 和階段計劃分配成本。]

4.3

迭代計劃

[通過引用的方式將各項迭代計劃附加在本節(jié)中。]

4.4

項目監(jiān)測與控制

4.4.1

需求管理計劃

[通過引用附加。]

4.4.2

進度控制計劃

[說明以何種方法按照所計劃的時間表監(jiān)控項目進展，以及如何在需要時執(zhí)行糾正操作。]

4.4.3

預算控制計劃

[說明以何種方法按照項目預算監(jiān)控項目開支，以及如何在需要時執(zhí)行糾正操作。]

4.4.4

質(zhì)量控制計劃

[說明將在何時、以何種方法來控制項目可交付工件的質(zhì)量，以及如何在需要時執(zhí)行糾正操作。]

4.4.5

報告計劃

[說明將生成的內(nèi)部和外部報告，以及報告發(fā)布的頻率和范圍。]

4.4.6

評測計劃

[通過引用附加。]

4.5

風險管理計劃

[通過引用附加。]

4.6

收尾計劃

[說明有序地完成項目所要執(zhí)行的活動，其中包括人員重新分配、項目材料存檔、事后檢查匯報及報告等。]

5.技術流程計劃

5.1

開發(fā)案例

[通過引用附加。]

5.2

方法、工具和技術

[以引用的方式列出所記錄的項目技術標準：

_

業(yè)務建模指南

_

用戶界面指南

_

用例建模指南

_

設計指南

_

編程指南

_

測試指南

_

手冊風格指南]

5.3

基礎設施計劃

[通過引用附加。]

5.4

產(chǎn)品驗收計劃

[通過引用附加。]

6.支持流程計劃

6.1

配置管理計劃

[通過引用附加。]

6.2

評估計劃

[作為軟件開發(fā)計劃的一部分，本小節(jié)說明項目的產(chǎn)品評估計劃，并介紹評估所使用的技術、標準、指標和過程；評估將包括走查、檢查和復審。請注意，評估計劃是對測試計劃的補充，但軟件開發(fā)計劃中并不包括測試計劃。]

6.3

文檔計劃

[通過引用附加。]

6.4

質(zhì)量保證計劃

[通過引用附加。]

6.5

問題解決計劃

[通過引用附加。]

6.6

分包商管理計劃

[通過引用附加。]

6.7

流程改進計劃

[通過引用附加。]

7.其他計劃

[列出合同或法規(guī)所要求的其他計劃。]

8.附錄

[供

SDP 讀者使用的其他材料。]

9.索引

第二篇：軟件開發(fā)項目商業(yè)計劃書

軟件開發(fā)項目商業(yè)計劃書

目前，中國軟件產(chǎn)業(yè)的快速增長已成為拉動我國經(jīng)濟增長的關鍵點之一。工信部部長李毅中表示，IT行業(yè)為我國經(jīng)濟增長做出了十分重要的貢獻，軟件在 IT行業(yè)發(fā)展中舉足輕重，成為推動經(jīng)濟增長和創(chuàng)造經(jīng)濟機會的催化劑。因此發(fā)展和扶持軟件產(chǎn)業(yè)，是一個國家提高國家競爭力的重要途徑，也是參與全球化競爭所必須占領的戰(zhàn)略制高點。而《中國軟件產(chǎn)業(yè)發(fā)展戰(zhàn)略研究報告》也指出全球軟件產(chǎn)業(yè)在發(fā)展過程中的網(wǎng)絡化已成為第一發(fā)展趨勢。

從2000年到2010年這十年間，中國軟件產(chǎn)業(yè)發(fā)展較快，產(chǎn)業(yè)規(guī)模增速迅猛。2009年軟件服務業(yè)銷售收入同比增長20%，是所有行業(yè)里面唯一增長20%以上的產(chǎn)業(yè)。2007年軟件收入5834.3億。2007年的前五年，平均的增速接近40%，07年的速度與五年前相比增加了五倍多。企業(yè)數(shù)14373家，平均增速是25%，07年較02年增長了3倍。從業(yè)人員達到152.9萬。到了2009年，我國軟件產(chǎn)業(yè)完成軟件業(yè)務收入9513億元，同比增長25.6%，增速比上年低4.2個百分點，是2000年的16倍；軟件出口196億美元，是2000年的49倍。面對金融危機，雖然軟件產(chǎn)業(yè)的增長速度有所放緩，但總體增長水平依然強勁。

第一部分 摘要

一、項目背景

二、項目簡介

三、項目競爭優(yōu)勢

四、融資與財務說明

第二部分軟件開發(fā)行業(yè)市場分析

一、軟件開發(fā)行業(yè)發(fā)展現(xiàn)狀

二、目標市場分析

三、競爭對手分析

四、小結

第三部分 公司介紹

一、公司基本情況

二、組織架構

三、管理團隊介紹

第四部分 產(chǎn)品介紹

一、產(chǎn)品介紹

二、產(chǎn)品的新穎性/先進性/獨特性

三、產(chǎn)品的競爭優(yōu)勢

第五部分 研究與開發(fā)

一、已有的技術成果及技術水平

二、研發(fā)能力

三、研發(fā)規(guī)劃

第六部分 產(chǎn)品制造

一、生產(chǎn)方式

二、生產(chǎn)設備

三、成本控制

第七部分 市場營銷

一、企業(yè)發(fā)展規(guī)劃

二、營銷戰(zhàn)略

三、市場推廣方式

第八部分 融資說明

一、資金需求及使用規(guī)劃

（一）項目總投資

（二）固定資產(chǎn)投資（土地費用、土建工程、淀粉糖裝飾、設備、預備費、工程建設其他費用、建設期利息）

（三）流動資金

二、資金籌集方式

三、投資者權利

四、資金退出方式

第九部分 財務分析與預測

一、基本財務數(shù)據(jù)假設

二、銷售收入預測與成本費用估算

三、盈利能力分析

1、損益和利潤分配表

2、現(xiàn)金流量表

3、計算相關財務指標（投資利潤率、投資利稅率、財務內(nèi)部收益率、財務凈現(xiàn)值、投資回收期）

四、敏感性分析

五、盈虧平衡分析

六、財務評價結論

第十部分 風險分析

一、風險因素

二、風險控制措施

第三篇：軟件開發(fā)計劃書

軟件開發(fā)計劃書模板

默認分類2009-06-30 14:21閱讀258評論0

字號： 大中小

項目名稱：圖書管理系統(tǒng)

小組編號: 15

版本號: v1.0

評審日期：2006-11-19

目錄

1.概述 3

1.1 目的 3

1.2 項目范圍 3

1.3 術語定義 3

2.人員分工 3

2.1 基本信息 3

2.2 假設和約束 3

2.3 關鍵里程碑及其提交產(chǎn)品 3

3.項目計劃 4

3.1 項目開發(fā)過程選擇 4

3.2 項目估算 4

3.2.1 工作量估算 4

3.2.2 進度估算 4

3.3 開發(fā)環(huán)境 4

3.4 小組評審 4

4.項目跟蹤 5

4.1 任務跟蹤 5

4.2 問題跟蹤 5

4.3 項目進展報告 5

5.參考資料 5

軟件開發(fā)計劃書

1.概述

圖書管理系統(tǒng)是指應用電子計算機和網(wǎng)絡通信設備，為圖書館管理人員能使日常辦公實現(xiàn)自支化，同時也為本校師生提供方便的圖書借閱環(huán)境,并能滿足所有授權用戶對信息的各種功能需求的計算機應用

軟件系統(tǒng)。

1.1 目的通過書寫開發(fā)計劃文檔，開發(fā)小組可以有條不紊地進行開發(fā)活動。這樣，小組在開發(fā)的過程中有章

可循，否則會造成混亂而且低的工作效率。

1.2 項目范圍

本項目負責項目生命周期模型的需求分析，系統(tǒng)設計、原型編碼階段。

2.角色與人員分工

2.1 基本信息

個人詳細的任務分工在后面進度計劃中描述，這里僅僅說明成員在本項目中擔任的角色

人員 角色 職責

李曉虎 項目經(jīng)理 管理負責整個項目，協(xié)同開發(fā)

林君宇 系統(tǒng)分析員 進行系統(tǒng)分析與設計

蘭皓 程序員 編程實現(xiàn)原型

連九研 程序員 編程實現(xiàn)原型

蔣海倩 測試,配置 測試，配置管理

2.2 假設和約束

假設：（1）需求比較穩(wěn)定；

（2）項目人員按時到位；

（3）項目中遇到的所有新技術能順利得到解決；

約束：軟件需求文檔中描述的需求都能實現(xiàn)，保證項目工期

2.3 關鍵里程碑及其提交產(chǎn)品

里程碑名稱 產(chǎn)品名稱 提交日期 責任人

項目計劃 《小組項目開發(fā)計劃》 2006.11.20 李曉虎

業(yè)務需求描述 《 業(yè)務需求描述基線》 2006.11.21 李曉虎

對象系統(tǒng)需求規(guī)格基線 《系統(tǒng)需求規(guī)格說明書》 2006.11.29 李曉虎

對象系統(tǒng)設計規(guī)格基線 《系統(tǒng)設計規(guī)格說明書》 2006.12.5 李曉虎

結構化系統(tǒng)需求基線 《結構化需求規(guī)格說明書》 2006.12.17 李曉虎

結構化系統(tǒng)設計基線 《結構化設計規(guī)格說明書》 2006.12.22 李曉虎

小組項目總結 《小組項目總結報告》 2006.12.29 李曉虎

程序包及程序框架文檔 程序包以及程序框架文檔 2006.12.29 李曉虎

3.項目計劃

3.1 項目開發(fā)過程選擇

小組開發(fā)所用的開發(fā)過程

1）面向對象開發(fā)方法中的迭代開發(fā)。

2）結構化開發(fā)方法中的瀑布模型。

3.2 項目估算

3.1.1 工作量估算

Stage Percentage of Effort Effort(Person-Hours)

需求獲取 4 8

需求分析 20 20

設計 40 30

實現(xiàn)（含編程，測試）20 20

項目管理 8 10

其它 4 8

總計 100 96

3.1.2 進度估算

Microsoft Project Gantt Chart：

3.2 開發(fā)環(huán)境

硬件環(huán)境 軟件環(huán)境

PC 等 JBuilder2006, Oracle, Weblogic 等

3.3 小組評審

小組自行定義的內(nèi)部評審點

評審關鍵點 評審內(nèi)容 評審安排

開發(fā)計劃 項目開發(fā)計劃 2006.11.20 上午 九教北304

業(yè)務需求描述 《 業(yè)務需求描述基線》 2006.11.21 上午 九教北304

對象系統(tǒng)需求規(guī)格基線 《系統(tǒng)需求規(guī)格說明書》 2006.11.29 上午 九教北304

對象系統(tǒng)設計規(guī)格基線 《系統(tǒng)設計規(guī)格說明書》 2006.12.5 上午 九教北304

結構化系統(tǒng)需求基線 《結構化需求規(guī)格說明書》 2006.12.17 上午 九教北304

結構化系統(tǒng)設計基線 《結構化設計規(guī)格說明書》 2006.12.22 上午 九教北304

小組項目總結 《小組項目總結報告》 2006.12.28 上午 九教北304

4.項目跟蹤

4.1 任務跟蹤

小組每周開一次例會來總結工作，時間是每周六上午；

每個成員每周要交一個《個人工作進展報告》。

4.2 問題跟蹤

小組成員將問題申報給組長，組長匯總并組織開會來討論解決，同時形成會議記錄。組長跟蹤問題

使其最終得到解決。

.4.3 項目進展報告

小組長填寫關鍵里程碑處小組工作匯報的安排，關鍵里程碑是指課程計劃中定義的關鍵評審點，需

要評審時做小組工作匯報

匯報人 內(nèi)容 文檔負責人

蘭皓 業(yè)務需求描述 林君宇

蘭皓 系統(tǒng)需求說明 李曉虎

蘭皓 系統(tǒng)設計說明 李曉虎

蘭皓 結構化需求規(guī)格說明 李曉虎

蘭皓 結構化設計規(guī)格說明 李曉虎

5.參考資料

1.《系統(tǒng)分析與設計》.John W.Satzinger 等著.機械工業(yè)出版社

第四篇：軟件開發(fā)項目合同

軟件開發(fā)合同書

甲方：

乙方： 深圳市凱路網(wǎng)絡技術有限公司

鑒于甲方委托乙方軟件開發(fā)，幫助甲方樹立企業(yè)形象，擴大宣傳，拓寬銷售渠道，為明確雙方責任，根據(jù)中國相關法律經(jīng)雙方協(xié)商，簽訂此合同，以期雙方共同遵守。

甲方在此委托乙方進行_軟件的開發(fā)，為明確雙方責任，經(jīng)友好協(xié)商，雙方達成以下協(xié)議：

第一條：項目的內(nèi)容、價款、開發(fā)進度、交付方式由“合同附錄”載明。

第二條：甲方的權利和義務

１、提供專人與乙方聯(lián)絡。

２、提供所有需要開發(fā)需求的資料給乙方。

３、按照“合同附錄”的要求，及時支付費用。

４、甲方將在著作版權法的范圍內(nèi)使用本合同標的及相關作品、程序、文件源碼，不得將其復

制、傳播、出售或許可給其它第三方。

５、甲方對合同中的系統(tǒng)軟件、頁面設計，程序開發(fā)享有排它的使用權。

第三條：乙方的權利和義務

１、提供專人與甲方聯(lián)絡。

２、按照“合同附錄”的要求，使用甲方資料，進行軟件的開發(fā)。

３、在“合同附錄”要求的期限內(nèi)，完成軟件的開發(fā)，并通知甲方進行驗收。

４、在驗收期內(nèi)甲方要求下，對不合格地方進行修改。

５、本合同標的及相關作品、程序、文件源碼的版權屬于乙方。(版權歸屬應該為嘉源公司)

第四條：驗收

１、驗收標準有以下幾條：

（a）、甲方可以通過任何上網(wǎng)的計算機訪問這個軟件

（b）、軟件系統(tǒng)中不存在任何錯誤或系統(tǒng)運行錯誤，圖片鏈接錯誤（以甲方提供的開發(fā)需求為準）。（功能符合開發(fā)需求，開發(fā)需求需要清晰界定功能）

（c）、網(wǎng)絡程序運行正常。

２、驗收期為一周。

第五條：違約責任

1、任何一方有證據(jù)表明對方已經(jīng)、正在或將要違約，可以中止履行本合同，但應及時通知對方。若對方繼續(xù)不履行、履行不當或者違反本合同，該方可以解除本合同并要求對方賠償損失。

2、因不可抗力而無法承擔責任的一方，應在不可抗力發(fā)生的3天內(nèi)，及時通知另一方。

3、一方因不可抗力確實無法承擔責任，而造成損失的，不付賠償責任。本合同所稱不可抗力是指不能預見、不能克服并不能避免且對一方當事人造成重大影響的客觀事件，包括但不限于自然災害如洪水、地震、火災和風暴等以及社會事件如戰(zhàn)爭、**、政府行為等。

第六條：保密條款

雙方應嚴格保守在合作過程中所了解的對方的商業(yè)及技術機密，否則應對因此造成的損失進行賠償。

第七條：其它

1、如果本合同任何條款根據(jù)現(xiàn)行法律被確定為無效或無法實施，本合同的其它所有條款將繼續(xù)

有效。此種情況下，雙方將以有效的約定替換該約定，且該有效約定應盡可能接近原約定和本合同相應的精神和宗旨。

2、“合同附錄”規(guī)定的有效期滿，本合同自動失效。屆時雙方若愿意繼續(xù)合作，應重新訂立合同。

3、本合同經(jīng)雙方授權代表簽字并蓋章，自簽訂日起生效。

4、本合同一式兩份，雙方當事人各執(zhí)一份，具有同等法律效力。

第八條：以上條款如有未盡事宜，經(jīng)甲、乙雙方協(xié)商后加以補充。

5、付款方式：項目總費用為八千元(人民幣),在簽定合同當日內(nèi)預付總項目費用的百分之三十，在軟件完成后交付總項目費用的百分之四十，測試用兩個月沒問題后再付剩下的總項目費用的百分之三十。

甲方：乙方：

甲方代表：乙方代表：

電話：電話：

電子信箱：電子信箱：

日期：日期：

合同附錄

<>

關于購買OA系統(tǒng)信息:

1在線郵局（增加部門群和全公司兩個功能）

新郵件發(fā)郵件發(fā)件箱收郵件廢郵件

2個人文件夾

私人文件夾公共文件夾管理員管理

3辦公用品管理

辦公用品種類領取辦公用品審核領用表發(fā)放辦公用品資料管理

4人事管理

企業(yè)員工資料企業(yè)員工統(tǒng)計 企業(yè)部門員工 員工調(diào)職管理員工培訓管理員工考勤管理 5權限設置

部門管理權限職位權限管理用戶帳號設置用戶權限設置系統(tǒng)維護設置 6系統(tǒng)幫助

系統(tǒng)幫助信息管理幫助類別輸入幫助信息

7常用資料

公共信息查詢常用公共網(wǎng)址手機與IP地址查用郵編查詢?nèi)f年日歷查詢世界時間查詢常用信息查詢常用網(wǎng)址查詢酒店飯店查詢常用郵編查詢列車資料查詢航班資料查詢單位換算查詢媒體資料查詢

8個人辦公(能否增加部門工作計劃)

個人工作計劃部門工作計劃員工工作任務

9通訊助理

個人通訊錄內(nèi)部通訊錄外部通訊錄手機短消息

10通知管理

通知管理發(fā)送通知已發(fā)通知已收通知我的通知（做到按部門發(fā)送）11通告管理(發(fā)布通告)

發(fā)布通告管理通告瀏覽通告

12考勤管理+值班管理(能否放在一起,算一個模塊)

設置考勤時間開始考勤今日考勤統(tǒng)計日考勤統(tǒng)計月考勤統(tǒng)計值班管理值班記錄

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

管理目標

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

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

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

執(zhí)行概述

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

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

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

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

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

6、風險識別、風險控制以及風險的預案。

項目管理

1、需求階段

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

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

2、設計階段

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

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

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

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

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

測試階段BUG響應及改進、收集反饋意見。對項目風險進行管理。

4、發(fā)布階段

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

5、試運行階段

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

6、收尾階段

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

常見問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3、需求變更管理

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

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

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

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

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

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

3、盡量降低變更帶來的風險。

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

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

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

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

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

5、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關人員。

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

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

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

4、風險管理

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

1、目標以及需求不明確

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

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

2、項目目標擴大以及需求變更

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

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

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

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

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

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

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

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

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

6、項目會議

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

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

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

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

3、會議沒有取得預期的結果；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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