項目研發(fā)標準和規(guī)范

文檔名稱項目研發(fā)標準和規(guī)范

版本號VI.0

創(chuàng)建人XXX

創(chuàng)建日期

保密分類秘密

文檔修訂記錄

版本號變化狀態(tài)簡要說明變更人變更日期審批人審批日期

VI.0C初次創(chuàng)建劉XX2019-3-14王XX2019-6-28

*變化狀態(tài)：C=創(chuàng)立，A=增加，M=修改，D=刪除

批準人：XX

批準日期:2019-6-28

目錄

1.概述.......................................................................1

1.1文檔目的.............................................................1

1.2適用范圍.............................................................1

2.代碼規(guī)范...................................................................1

2.1源代碼規(guī)范..........................................................1

2.1.1通用規(guī)范........................................................1

2.1.2Java/JavaScript.......................................................................................................1

2.13文本格式........................................................3

2.2開發(fā)原則.............................................................4

2.2.1類、接口........................................................4

2.2.2方法............................................................4

2.23表達式與語句....................................................5

2.2.4循環(huán)語句........................................................7

2.2.5異常捕捉........................................................7

2.2.6變量...........................................................10

2.2.7方法...........................................................11

2.2.8日志............................................................11

2.2.9其它...........................................................12

2.2.10編程技巧.......................................................12

2.3代碼示例...........................................................16

2.3.1Example.java.........................................................................................................16

2.3.2Html/jsp/js.............................................................................................................18

3.研發(fā)過程..................................................................19

3.1研發(fā)計劃...........................................................19

3.1.1工作描述.......................................................19

3.1.2交付工作產品...................................................20

3.1.3文檔編寫指南...................................................20

3.1.4經驗分享.......................................................21

3.1.5方法與工具.....................................................22

3.1.6自檢要素........................................................24

3.2設計與開發(fā).........................................................24

3.2.1工作描述.......................................................24

3.2.2交付_L作產品...................................................25

3.2.3文檔編寫指南...................................................25

3.2.4經驗分享.......................................................25

3.2.5方法與工具.....................................................26

3.2.6自檢要素........................................................28

33發(fā)版................................................................28

3.3.1工作描述.......................................................28

3.3.2交付工作產品...................................................29

3.3.3文檔編寫指南...................................................29

3.3.4經驗分享.......................................................29

3.3.5自檢要素........................................................29

3.4項目結項............................................................30

3.4.1工作描述.......................................................30

3.4.2交付工作產品...................................................30

3.4.3文檔編寫指南...................................................31

3.4.4經驗分享.......................................................31

3.4.5自檢要素.......................................................31

4.例行工作..................................................................32

4.1例會及報告.........................................................32

4.1.1項目例會.......................................................32

4.1.2個人周報.......................................................32

4.1.3項目周報.......................................................32

4.2研發(fā)管理...........................................................33

4.2.1里程碑報告.....................................................33

4.2.2項目評審.......................................................33

4.2.3風險管理.......................................................34

4.3項目變更............................................................34

4.3.1變更控制的要點.................................................34

4.3.2如何進行變更...................................................34

5.資料管理....................................................................36

5.1文檔管理............................................................36

5.1.1日常資料備份...................................................36

5.1.2項目資料歸檔...................................................36

5.2代碼管理...........................................................36

5.2.1崗位劃分.......................................................36

5.2.2版本劃分.......................................................37

5.2.3流程說明.......................................................37

5.3安全管理............................................................38

XX科技信息技術有限公司

1.概述

1.1文檔目的

為加強對北京研發(fā)總部及各研發(fā)分中心的管理、提高研發(fā)工作效率、規(guī)范開發(fā)工作，特

制定研發(fā)標準及規(guī)范。

文檔中對研發(fā)標準及規(guī)范進行詳細描述，在研發(fā)經驗總結、研發(fā)項目總結基礎上，不斷

完善規(guī)范的有效性，提高項目文檔質量，幫助推進項目，保證項目質量，提升研發(fā)項目生產

效率，確保項目研發(fā)成功。

1.2適用范圍

適用于全體研發(fā)工作人員；適用于公司所有研發(fā)項目。

2.代碼規(guī)范

2.1源代碼規(guī)范

2.1.1通用規(guī)范

?開發(fā)人員的開發(fā)環(huán)境應保燈統(tǒng)一：(Tomcat,JDK1.8,Intel1ijIDEA,Chrome)。

?版本控制環(huán)境，統(tǒng)一使用公司的SVN,研發(fā)分中心通過VPN接入。

?頁面設計過程中，要考慮到操作系統(tǒng)、瀏覽器、瀏覽器版本、顯示器分倍率等因素。

?代碼整潔、注釋合理，嚴格遵守Java文檔注釋標準。

2.1.2Java/JavaScript

1.類/接口

每個Java類，保存為單獨的文件(內部類除外)，不允許使用非public修飾的類，確

有需要的，使用其他修飾方法解決。

1

文件開頭加入版權聲明

/**

*版權聲明XX科技信息技術有限公司版權所有違者必究

*<br>Company：天創(chuàng)科技

*<br>?author劉方正

*<br>?version1.0

*------------------------------------------------------

*/

2.包(Package)

在公司整體框架的基礎上，每個功能模塊單獨建立一個包，再按小模塊劃分，自行建立

子包。

包名統(tǒng)一小寫，具有業(yè)務意義。

每個功能模塊包，加入package.html,描述此包。

例如：

packagecom.gas.framework,controller:

importjava.io.File;

importjava.io.OutStream;

importjava.util.Observable;

importhotJava.util.Application;

3.方法

2

方法的命名，要求遵守：首字母小寫，以后每單詞首字母大寫。功能性方法，以其功能

的英文開頭，比如：添加用戶：addUser.

如果方法名沒有合適的英文描述，可使用拼音全拼。如果拼音全拼太長，可適當縮短為

拼音首字母，但是要有詳細注釋。

方法注釋：以簡明扼要的語句，描述方法所做的事，調用需要注意的事項。各參數含義，

返回值。

方法內各語句的注釋，以適量為準，能讓不了解業(yè)務的人看明白。

4.字段

字段的命名：以業(yè)務規(guī)則命名。好的命名，可以代替注釋。字段的聲明位置，要求在類

的頭部，其get/set方法，放在類的尾部。

字段的注釋：以注釋在字段聲明同一行結尾。

5.單元測試

針對每一個業(yè)務方法，要求提供JUnit的單體測試代碼

2.1.3文本格式

?請以4個空格設置Tab鍵寬度，按代碼層級設置縮進。

?花括號的使用，要配合Tab鍵，做到上下對稱，層級分明。

?在適當的位置加入空格和空行，以保持代碼的美觀和可讀性。

?保持適當的折行，一行代碼的長度不要超過100個字符。

?文件的編碼格式，統(tǒng)一為UTF-8（包括數據庫編碼）。

3

2.2開發(fā)原則

2.2.1類、接口

?類的劃分粒度，不可太大，造成過于龐大的單個類，也不可太細，從而使類的繼承太

深。一般而言，一個類只做一件事；另一個原則是根據每個類的職責進行劃分，比如

用User來存放用戶信息，而用UserDao來對用戶信息進行數據訪問操作（比如存取數

據庫），用UserService來封裝用戶信息的業(yè)務操作等等。

?多使用設計模式，隨時重構。多個類中使用相同方法時將其方法提到一個接口中或使

用抽象類，盡量提高重用度。同時可以減少維護難度。

?將不希望再被繼承的類聲明成final,例如某些實用類，但不要濫用final,否則會對

系統(tǒng)的可擴展性造成影響。

?將不希望被實例化的類的缺省構造方法聲明成privateo

?每個項目文件中的主class必須寫一個main方法，它要提供測試和演示功能

?在一個單獨的應用程序中，帶有main。方法的類應該與其他類分開。原因：如果主類

和其他類不分開，將會導致很難再使用

?為你經常使用的類做一個模板。原因：代碼標準的一致化。

?在抽象類和接口都可實現的情況下，建議使用接口。定義抽象類，僅當它們部分方法

抽象時。原因：接口比抽象類更容易擴展，可以實現多重繼承。

?考慮每個類是否要實現Cloneable或者Serializer接口

?定義一個類為final,僅當它是個子類，或者類的實現，或者是沒有人任何實現方法

的接口。原因：把一個類定義為final,意味著再也沒機會重新實現類的方法。

?為每一個類定義一個默認的構造器，以便于可以通過Class.newInstanceO來構造。

原因：通過定義默認的構造器，可以在編譯期間動態(tài)的加載類。

2.2.2方法

?一個方法只完成一項功能，在定義系統(tǒng)的公用接口方法外的方法應盡可能的縮小其可

見性。

?避免用一個類是實例去訪問其靜態(tài)變量和方法。

4

?避免在一個較長的方法里提供多個出口，如：

〃不要使用這鐘方式，當處理程序段很長時將很難找到出口點

if(condition){

returnA;

)

else{

returnB;

)

〃建議使用如下方式

Stringresult=null;

if(condition){

result=A;

)

else{

result=B;

)

returnresult;

?避免過多的參數列表

盡量控制在5個以內，若需要傳遞多個參數時，應使用一人容納這些參數的對象

進行傳遞，以提高程序的可讀性和可擴展性。參數類型和返回值盡量接口化，以屏

蔽具體的實現細節(jié)，提高系統(tǒng)的可擴展性，

例如：

publicvoidjoinGroup(ListuserList){}

publicListlistAHUsersO{}

2.2.3表達式與語句

?控制語句

判斷中如有常量，則應將常量置與判斷式的右側。

如：

if(true==isAdminO)...

if(null==user)...

if(.equals(strParameter)….這種判斷還可以省了判斷null

盡量不使用三目條件判斷。

所有if語句必須用。包括起來，即便是只有一句，如：

〃不要使用這種

if(true)i=0;

〃使用這種方式

if(true){

i=0;.

)

?過多的else分句請將其轉成switch語句或使用子函數

每當一個case順著往下執(zhí)行時(因為沒有break語句)，通常應在break語句的位

置添加注釋。如：

switch(condition){

caseABC:

//statements;

〃繼續(xù)下一個CASE

caseDEF:

//statements;

break;

caseXYZ:

//statements;

break;

default:

6

//statements;

break;

}//endswitch

2.2.4循環(huán)語句

循環(huán)中必須有終止循環(huán)的條件或語句，避免死循環(huán)。

當在for語句的初始化或更新子句中使用逗號時，避免因使用三個以上變量，而導致

復雜度提高。若需要，可以在for循環(huán)之前(為初始化子句)或for循環(huán)末尾(為更新子句)

使用單獨的語句。

避免在循環(huán)中執(zhí)行取固定值的重復操作，比較一下兩種循環(huán)的差異：

〃不推薦方式______________________________________________

while(index<products.getCountO){

〃每此都會執(zhí)行一次gelCount()方法，

〃若此方法耗時則會影響執(zhí)行效率

〃而且可能帶來同步問題，若有同步需求，請使用同步塊或同步方法

}

〃推薦方式________________________________________________

〃將操作結構保存在臨時變量里，減少方法調用次數

finalintcount=products.getCount0;

u-hile(index<count){

)

2.2.5異常捕捉

?當捕捉到異常時，必須處理catch代碼區(qū)，打印錯誤信息。原因：不能預料代碼運行

可能出現的所有情況。為了減少測試周期和避免未知的錯誤，必須在catch代碼區(qū)報

告錯誤信息。

7

try(

_serivce.connect0;

}catch(ConnectionExccptionce){

//Thisisunexpectedbutsince

//IreadthecodingstandardandIunderstand

//itsbenefits,I'11logamessage

_logger.og(ce.printStackTrace());

}

?不要使用Exception,而應該盡可能的精確捕捉異常。原因：精確的捕捉異常能夠幫

助你了解代碼和確切知道你要做什么。下面為錯誤使用異常的案例：

try{

_file=newFile(name);

if(_file.existsO){

db.store(_file);

}

printReport();

}catch(Exceptione){

e.printStackTraceO;

}

正確異常捕捉的案例:

8

try(

_file=newFile(name);

if(_file.existsO){

db.store(_filc);

)

printReport();

}catch(lOExceptionie){

Stringmessage=MessageService.message(FILE_NOT_FOUND,name);

thrownewStoringException(ie,message);

}catch(JDOExceptionje){

Stringmessage=MessageService.message(DB_ERROR);

thrownewStroringException(je,message);

}catch(ReportExceptionre){

logger,log(re.getMessage());

?每個構造器和方法必須明確的聲明所有可能拋出的未經制止的異常。原因：為了保持

一致性，構造方法和其他方法可以在他們調用的命令上設置約束。文檔允許調用者忽

略運行期異常。

?當拋出異常時，不要提及拋出這個異常的方法的名字，而是使用說明性的文字。原因:

報告信息不能只提供方法的名字，一個好的異常信息是非常有用的。

?確保有一個catch塊捕捉和處理所有未能預料的異常。原因：java允許開發(fā)者不去聲

明和捕捉共有的容易處理的異常。應定義它并捕捉它。

9

?不要用一個未經處理的異常來代替檢測異常條件的代碼

如：空指針異?？捎蓷l件處理

〃不要這樣做

StringuserName=request.getParameter("username");

try(

userName=userName.trim();

)

catch(NulIPointExceptionnpex){

npex.printStackTrace0;

)

〃應這樣

StringuserName=request.getParameter("username");

userName=(null==userName)?userName:userName.trim();

2.2.6變量

?不要把一個實例變量聲明為public(這不包括常量的聲明)。原因：這是面向對象的

原理。使變量為公開的，意味著放棄對類內部結構的控制，而且不能保證變量有有效

的值。

?盡量減少使用變量默認的初始化值。(像String初始化為“”)。原因：盡量減少初

始化的錯誤。

?盡量減少static。staticfinal常量除外。原因：static變量相當于非00語言的全

局變量。它們使方法依賴于局部的上下文環(huán)境，有時會引起同步錯誤，而且使代碼更

容易崩潰。

?通常用long代替int,double代替float。原因：用long比int要少4億次的上溢和

下溢；類似的，用double比float少出現精確度的問題。另一方面，由于JAVA的限制,

用long和double要同步，而用int和float不需要同步。

?如果要使變量在類的生命期內不被改變，定義為finals原因：使用這種方式定義的

10

常量不需要任何同步。

?避免定義多余的存取實例變量的方法。只有直正需要時，才為它們寫get/set方法。

原因：許多類中的變量的值依賴其它的變量。

?盡可能不要在方法中直接存取實例變量，而是采用protected的存取方法來代替。原

因：OOP規(guī)則

?通常使用protected代替private。

?避免給一個類中的成員變量取和超類相同的名字。原因：它們通常會造成錯誤。

?在你知道局部變量值時，你才去定義它。原因：盡量減少因為局部變量初始化而帶來

的問題。

?寧愿定義和初始化一個局部變量，也不要使用一個碰巧不再使用的一個已經定義的變

量。原因：盡量減少局部變量初始化而帶來的問題。

?賦予不再使用的變量的值為null。原因：保證垃圾更容易回收

2.2.7方法

?聲明你的類和方法是線程安全的。原因：保證代碼在任何情況都可以正常運行。

?避免覆蓋返回有爭議類型的方法。原因：默認版本的clone可能不像你期望的那樣實

現你所要實現的。

?寫一個僅做“一件事”的方法。

?定義主類中有默認實現的方法為抽象方法。原因：Java編譯器會強迫子類的實現者去

實現抽象方法，避免因為沒有實現父類的方法而導致程序出錯。

2.2.8日志

以下內容請使用日志形式記錄，不要使用System.out.printin.

?所有調試信息

?操作日志

?系統(tǒng)業(yè)務日志

11

2.2.9其它

?如果一個Serializable類依賴于那些有不同處理過程的狀態(tài)，例如hashcodes和

transient字段，覆蓋readObject和writeObject。原因：否則這個類的對象將不能

正確傳送。

?如果你認為在你寫的類中可能調用clone。方法，那你就明確的定義它（聲明這個類繼

承Cloneable接口）。原因：默認版本的clone可能不像你期望的那樣實現你所要實現

的。

?如果你替換了Object.equals,同時你也要替換Object.hashCode。原因：木質上，所

有的容器和其他工具在比較對象時，所有的使用equals的方法都是依靠hashCode來比

較是否相等。

?對象比較時用equals代替==,尤其是Strings比較時。原因：默認的equals方法等

同于“=="方法。

?用notifyAll代替notify和resumeo原理：僅使用notify的類能夠正常的支持僅使

用一種等待條件跨越所有類和子類方法的情況。使用suspend/resume更容易使代碼崩

潰。

2210編程技巧

?exit（）

exit除了在main中可以被調用外，其他的地方不應該被調用。

?異常

申明的錯誤應該拋出一個RuntimeException或者派生的異常。

頂層的main。函數應該截獲所有的異常，并且打印（或者記錄在日志中）在屏幕

上。

?數據庫連接池

連接完數據庫時，必須關閉數據庫連接。

盡量使用PreparedStatement,而不要使用Statemento

12

盡可能使用批處理操作。

?垃圾收集

JAVA使用成熟的后臺垃圾收集技術來代替引用計數，你必須在使用完對象的實例

后進行清除。下面是一個錯誤使用的例子：

FileOutputStreamfos=newFileOutputStream(projectFile);

project.save(fos,"IDEProjectFile");

}

除非輸出流一出作用域就關閉，否則Java是不能自動完成變量的清除工作的。下

面為正確例子：

FileOutputStreamfos=newFileOutputStream(projectFile);

project,save(fos,"IDEProjectFile*);

fos.close();

?final類

絕對不要因為性能的原因而將類輕易定義為final0

如果一個類還沒有準備好被繼承,最好在類文檔中注明，而不要將它定義為final,

因為不能保證它以后不會被繼承。

?Clone

下面是一種有用的方法

implementsCloneable

13

public

Objectclone()

(

try(

ThisClassobj=(ThisClass)super,clone();

obj.fieldl=(int[])fieldl.clone();

obj.field2=field2;

returnobj;

}catch(CloneNotSupportedExceptione){

thrownewInternalError(*UnexpectedCloneNotSUpportedException:“

+e.getMessage());

)

)

?byte數組轉換到characters

把characters轉換到byte數組

“Helloworld!\getBytesO;

?Utility類

Utility類(僅僅提供方法的類)應該被申明為抽象的來防止被繼承或被初始化。

?初始化

下面的代碼是一種很好的初始化數組的方法：

objectArguments=newObject[]{arguments);

?枚舉類型

14

JAVA對枚舉的支持不好，但是下面的代碼是一種很有用的模板：

classColor{

publicstaticfinalColorBLACK=newColor(0,0,0);

publicstaticfinalColorRED=newColor(OxFF,0,0)

這種方式實現了RED,GREEN,BLUE等可以像其他語言的枚卷類型一樣使用?？梢?/p>

使用“二”操作符來比較。

但是這樣使用有一個缺陷：如果用下面方法創(chuàng)建顏色BLACK如：new

Color(0,0,0)o

使用“==”操作符會產生錯誤。它的equal。方法仍然有效。這種技巧的缺陷最

好注明在文檔中，或者只在自己的包中使用。

?訪問類的成員變量

大部分的類成員變量應該定義為private的來防止繼承類使用他們。

注意，要用packets”,而不是"intpackets1]〃，后,種永遠也不要用。

publicvoidsetPackets(int[]packets){this,packets=packets;}

CounterSet(intsize){

this,size=size;

?成員函數的可見性

良好的程序設計應該盡可能減小類與類之間耦合，所遵循的經驗法則是：盡量限制

成員函數的可見性。如果成員函數沒必要公有(public),就定義為保護(protected)；

沒必要保護(protected),就定義為私有(private)(,

可見性說明正確用法

public公有成員函數可被任何其它對象和當該成員函數必須被該函數所在的層

15

類的成員函數調用。次結構之外的其他對象和類在訪問

時。

protected被保護的成員函數可被它所在的類當該成員函數提供的行為被它所在類

或該類的子類的任何成員函數調的層次結構內部而非外部需要時。

用。

private私有成員函數只可以被該類所在的當該成員函數用提供的行為明確針對

其它成員函數調用，該類的子類不定義它的類時。私有成員函數常常是

可以調用。重新分配要素的結果。重新分配要素

又叫“重組”，指類內其它成員函數

封裝某一個特定行為的做法。

2.3代碼示例

2.3.1Example.java

/**

*xx科技信息技術有限公司版權所有違者必究

*

*<br>Company：天創(chuàng)科技

*<br>?author李四

*<br>?version1.0

?-------------------------------------------

*修改記錄

*修改者：李四

*修改原因：新增解析XM：方法，參見504行。

*

packagecom.intalio.n3.xml；

importjava.io.Serializable；

16

importjava.net.URL；

importjava.net.MalformedURLException；

/**

*示例，用于示例

*

publicclassExampleClassimplementsSerializable(

privateStringid；〃用戶ID

/**

*構造函數，根據傳入的ID創(chuàng)建一個新的對象

*@paramidString新ID

*/

publicExampleClass(Stringid){

this.id=id；

}

/??

*添加新用戶

?@paramUseruser新用戶實例

*@retumString0,成功，1,已存在，2,校瞼失敗,3,系統(tǒng)錯誤

?/

publicStringaddUser(Useruser){

〃1.查看庫中是否存在用戶

try{

UsertmpUser=dao.getUser(user.getldO)；

if(null!=tmpUser){

17

return1；

)

}catch(NulIPointerExcepticne){

return"3"；

)

//2校驗用戶是信息

if(user.getName().indcxOf("w)>0){

return"2"；

)

//3.保存

dao.saveUser(user)；

return"0"；

)

//=====—===getter/setter=========

publicStringgetldO{

returnthis,id；

)

publicvoidsetld(Stringid){

this,id二id：

)

2.3.2Html/jsp/js

<html>

<hcad>

18

。一引入內容一〉

〈/head〉

<body>

</body>

/**

*JS方法，添加用戶

*/

functionaddUser(id,name)

)

</html>

3.研發(fā)過程

3.1研發(fā)計劃

3.1.1工作描述

項目經理根據項目實際情況，按照項目管理計劃模板,制定出項目管理計劃。主要包括：

項目目標、項目環(huán)境資源需求、項目過程定義、主要里程碑、項目人力資源計劃、干系人介

入計劃、項目組培訓計劃、評審計劃、度量數據收集與分析計劃、可交付成果清單、方法與

工具等。

根據項目管理計劃中的里程碑時間點制定項目詳細進度計劃。進度計劃中應進行任務細

分，將每個階段的工作細化，并規(guī)定完成時間以及負責人。使用Project編寫進度計劃。

19

項目經理需要識別項目潛在風險，并使用《項目風險/重大跟蹤表》記錄和跟蹤風險狀

態(tài)。

配置管理員與項目變更控制委員會（CCB）確認項目的訪問控制、基線和版本策略、

分支版本策略、構建發(fā)布策略、變更控制策略等，建立配置管理計劃。

由品質保證工程師根據項目開發(fā)計劃中的時間進度,制定針對其具體過程和產品的品質

保證計劃。計劃中需要根據項目的特征確定檢查哪些過程和工作成果，還需要計劃檢查的時

間和人員。

測試負責人根據項目管理計劃和需求規(guī)格說明書對項目的測試進度、測試資源的投入、

測試的整體思路和測試重點等進行計劃，完成項目測試計劃。

項目管理計劃及附屬計劃評審，使用評審報告記錄和跟蹤評審發(fā)現問題。如項目工期緊

張，該項評審工作可采用郵件評審方式。

需求范圍明確后，需要對項目管理計劃中的里程碑時間點、人員安排等做調整，各附屬

計劃也進行相應調整。

項目立項且需求基本確定后，由項目經理根據項目的實際情況，會同分管領導意見，提

出項目獎金申請，申請過程通過編報《項目詳細進度計劃》、《項目成本估算、獎金核定表

（研發(fā)）》、并將完成的相關材料通過郵件發(fā)送給運營監(jiān)管中心項目監(jiān)管部并抄送主管領導，

進行審批。

3.1.2交付工作產品

?《項目管理計劃》

?《項目詳細進度計劃》

?《風險/重大問題跟蹤表》

?《品質保證計劃及路線圖》

3.1.3文檔編寫指南

(1)《項目管理計劃》

20

項Fl經理在制定項Fl管理計劃時，至少要明確，項目目標與內容、項目所需資源及環(huán)境

要求、項目過程定義、項目主要里程碑、人力資源計劃、干系人介入計劃、項目度量計劃、

項目評審計劃、提交的工作產品清單、方法與工具等。

項目過程定義主要是根據項目實際情況對項目過程進行裁剪；項目干系人介入計劃主要

明確項目相關干系人何時、如何介入項目；項目度量計劃和評審計劃目前模板中已經有固定

的數據了，項目經理可以根據項目情況進行裁剪。需求、開發(fā)規(guī)模的度量，計劃、需求、功

能評審都是必須要做的。

（2）《項目詳細進度計劃》

根據項目管理計劃使用xls或MSProject編寫項目詳細計劃，項目詳細計劃中的工作包

顆粒度要細，每個工作包需要投入的資源及資源投入百分比都需要填寫。項目進度計劃制定

后，應定期進行跟蹤、更新、細化，至少1-2周一次。

（3）《風險/重大問題跟蹤表》

制定項目計劃的同時，對項目潛在風險進行識別，并記錄在風險/重大問題跟蹤表的上

半部分，如果風險發(fā)生，轉變?yōu)閱栴}后，應該更新風險的狀態(tài)，并將問題記錄在風險/重大

問題跟蹤表的下半部分進行跟蹤。對風險和問題的跟蹤也應是定期的，至少1-2周一次。

（4）《品質保證計劃及路線圖》

主要明確品質保證工程師在那些點介入項目，進行審計和檢查。

3.1.4經驗分享

項目管理計劃及附屬計劃完成后需進行評審，評審可采取郵件或會議形式,為節(jié)約資源,

一般都建議采取郵件評審方式。項目計劃出現變更時，相關附屬計劃都需要隨之進行變更。

項目管理計劃中，比較容易忽略的資源環(huán)境、干系人介入計劃一定要按實際情況填寫，

評審計劃、度量數據收集計劃、項目使用的方法與工具應按照項目實際情況進行填寫。提交

的工作產品清單應盡量詳細，命名也要規(guī)范，要與項目過程定義時確認需要提交的工作產品

保持一致。

21

制定項Fl計劃階段要重視風險識別，最好所有干系人都參與風險識別，可以參考類似項

目，必要時向專家請教。需求、設計階段要持續(xù)進行風險識別?？梢詮墓δ?、質量、性能角

度識別技術風險，從人力資源狀況識別管理風險。

制定項目計劃時，選用合適的軟件工具，盡量減少項目計劃的工作量。

3.1.5方法與工具

在進行進度和成本估算時可使用以下方法：

(1)專家判斷法

即請本領域的專家來判斷執(zhí)行項目各工作所需時間的長短。工作持續(xù)時間的估計常常是

相當困難的，它要涉及到眾多的因素，一般很難找到一個通用的計算方法，這個時候專家的

歷史經驗和記錄就顯得尤為重要，盡管這種方法的結果也具有一定的不確定性和風險，但仍

然不失為一種行之有效的方法。

(2)三時估算法

一般地還可以通過估計完成工作的最樂觀時間、最悲觀時間及最可能時間按下式來估算

工作持續(xù)時間：工作持續(xù)時間=(樂觀的時間+4義最有可能的時間+最悲觀的時間)/6

(3)經驗估算法

進行估計的人應有專門知識和豐富的經驗，據此提出一個近似的數字。這種方法是一種

最原始的方法，還稱不上估算，只是一種近似的猜測。它僅適合于要求很快拿出一個大概數

字的項目。

(4)自上而下估算法

此方法一般要求有類似完成項目的經驗的情況下使用。其主要內容是：收集上、中層管

理人員的經驗和判斷，以及相關歷史數據，然后上、中層管理人員估計整個項目的費用和各

個分項目的費用，將此結果傳送給下一層管理人員，責成其對組成項目和子項目的任務和子

任務的費用進行估算，并繼續(xù)向下傳送其結果，直到項目組的最基層。

這種過程和層級計劃制定的過程類似，費用如同項目一樣，按照IBS過程，從最高層到

最底層進行逐層分解。

22

這種方法的缺點是特別需要是立好上下管理層暢通的溝通渠道。因為上層管理人員根據

經驗得出的費用估算結果可能不能滿足下層管理人員認為完成任務的需要。此時若不能適當

地溝通，費用分配方案失去原有的作用而變成完成項目任務的阻礙，從而導致項目的失敗。

使用此方法的好處是中、上層管理人員能夠比較準確地掌握項目整體費用分配，從而使

項目的費用能夠合理地控制在一個水平上，一定程度上避免了項目的費用風險。

(5)自下而上估算法

該方法是指參與項目工作的每一機構和基層單位都估算自己的費用，將估算結果加起來

的總和，得到該項目的整個估算燹用。具體地可按照WBS體系，從下而上估算各個工作的費

用，得到項目的直接費用估計，項目經理再在此基礎上加上合理的間接費用，估算出項目的

總費用。

根據軟件程序模塊的標識和定義，估計代碼的行數，可近似確定開發(fā)和測試軟件的費用。

這種方法的缺點在于要保證所有的工作和任務都被考慮到，而且對每個工作單元有過高

估算的傾向，往往導致最后的費用估算無法接受。

它的優(yōu)點在于比起高層管理人員來,底層直接參與項目工作的人員更清楚項目工作所需

資源的種類和數量，費用估算更為精確。而且費用估算出自他們自己的估計，可以避免以后

費用預算過程中的一些沖突和不滿。

(6)類比估算法

即比照以前的經驗，或比較以往類似項目的檔案資料，根據以前的類似的實際項目的工

作時間來推測估計當前項目各工作時間的。如果當前的項目與類比的項目很類似時，類比估

計是一種最有效的方法。

類比估算中的不確定性歸根結底是由技術人員和費用估算人員所作的主觀評價引起的。

在多數情況下，可以進行實際的技術比較。問題是在技術差異的基礎上建立費用關系，甚至

當技術人員做出的所有決策都可以定量客觀評價時，費用估算人員還需要確定有關技術發(fā)現

的費用影響。在很多情況下，這些費用影響是非常主觀的，因而，這種估算還是具有較大的

不確定性。類比估算適用于項目早期，此時還沒有系統(tǒng)的實際費用數據，也沒有相似系統(tǒng)的

大型數據庫，只有此種方法的估算較為準確。

23

3.1.6自檢要素

令相關文檔的命名是否符合公司相關規(guī)范，是否以項目編號+項目名稱+文檔名稱的方

式命名

令項目管理計劃里程碑時間點是否是具體的日期，并且有標志性提交物

?項目管理計劃最終提交二作產品清單是否全部包含了項目裁剪后生命周期模型所

要求的工作產品

?是否制定了項目組必須的培訓計劃（包含對內培訓和對外培訓）

?是否對項目的風險進行了識別，制定了風險管理措施

令是否識別了相關干系人，并對干系人介入的活動進行了定義

令項目進度計劃中，工作任務的工期、工時、起止時間、資源是否否己明確定義

令項目的溝通計劃是否清晰明確

令項目的評審、度量計劃是否已制定

令項目管理計劃及其附屬計劃是否經過正式評審（郵件或會議），并保留了評審記錄

令進行成本估算時，項目的主要需求是否已確定

3.2設計與開發(fā)

3.2.1工作描述

分析與設計軟件的體系結構，產生《概要技術方案說明書》。

對系統(tǒng)數據進行設計，定義各數據實體的存儲結構，確定結構、約束、索引、關系等,

產生《數據庫設計說明書》

設計關鍵用戶界面，設計軟件模塊的主要接口、類、數據結構、算法，產生《模塊設計

說明書》

完成代碼的編寫，并通過單元測試，完成集成測試所需要的產品

24

3.2.2交付工作產品

?《技術研究報告》

?《概要技術方案說明書》

?《數據庫設計說明書》

?《模塊設計說明書》

?《相關評審報告》

3.2.3文檔編寫指南

（1）《技術研究報告》

需要明確項目的技術路線.描述集中可能用到的技術路線,并加以對比分析,最終確認

可行的技術路線。

（2）《概要技術方案說明書》

確定項目的總體框架、關鍵技術。

（3）《數據庫設計說明書》

主要描述項目總體ER圖及各模塊的ER圖，項目各表之前的關系及表結構。

（4）《模塊設計說明書》

主要對各模塊的類圖、調用關系、接口等進行設計。

（5）《相關評審報告》

如項目有設計工作，設計工作產品應及時進行評審，每個項目都必須做功能評審。

3.2.4經驗分享

目前公司多數產品都是基于D&A平臺進行開發(fā)的，一般都是做完需求規(guī)格后直接就進

行開發(fā)，項目的設計工作可以根據項目具體情況進行裁剪，單元測試、功能評審一定要做。

系統(tǒng)設計可分為兩個部分進行，首先是總體設計,其任務是系統(tǒng)的總體結構進行設計，

在此基礎上進行第二階段一一詳細設計，它的任務是在系統(tǒng)總體設計的指導下，對系統(tǒng)各組

成部分進行細致、具體的物理設計，使系統(tǒng)總體設計階段所作的各種決定具體化。

25

對開發(fā)人員進行“代碼審查、測試、改錯”等方面的培訓，提高他們的工作效率。

開發(fā)小組根據產品的特征，可以適當地修改本規(guī)范的各種文檔模板。

代碼設計的基本原則：具備唯一確定性；標準化與通用性：可擴充且易修改；短小精

悍即選擇最小值代碼；具有規(guī)律性、便于編碼和識別。