第一篇:軟件開發(fā)管理規(guī)定
軟件開發(fā)管理規(guī)定
第一條 第二條 第三條 為規(guī)范自有軟件研發(fā)以及外包軟件的管理工作,特制定本制度。本制度中軟件開發(fā)指新系統(tǒng)開發(fā)和現(xiàn)有系統(tǒng)重大改造。
本制度中自行開發(fā)是指主要依賴公司自身的管理、業(yè)務(wù)和技術(shù)力量進(jìn)行系統(tǒng)設(shè)計(jì)、軟件開發(fā)、集成和相關(guān)的技術(shù)支持工作,一般僅向外購置有關(guān)的硬件設(shè)備和支撐軟件平臺(tái);合作開發(fā)是公司與專業(yè)IT公司(合作商)共同協(xié)作完成IT應(yīng)用的項(xiàng)目實(shí)施和技術(shù)支持工作,一般形式是公司負(fù)責(zé)提供業(yè)務(wù)框架,合作商提供技術(shù)框架,雙方組成開發(fā)團(tuán)隊(duì)進(jìn)行項(xiàng)目實(shí)施,IT系統(tǒng)的日常支持由IT管理小組和合作商共同承擔(dān),IT管理小組負(fù)責(zé)內(nèi)部(一級(jí))支持,合作商負(fù)責(zé)外部(二級(jí))支持;外包開發(fā)是指將IT應(yīng)用項(xiàng)目的設(shè)計(jì)、開發(fā)、集成、培訓(xùn)等任務(wù)承包給某家專業(yè)公司(可以是專業(yè)的IT公司或咨詢公司等),由該公司(承包商)負(fù)責(zé)應(yīng)用項(xiàng)目的實(shí)施。
第四條 軟件開發(fā)遵循項(xiàng)目管理和軟件工程的基本原則。項(xiàng)目管理涉及立項(xiàng)管理、項(xiàng)目計(jì)劃和監(jiān)控、配置管理、合作開發(fā)管理和結(jié)項(xiàng)管理。軟件工程涉及需求管理、系統(tǒng)設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)、系統(tǒng)測試、用戶接受測試、試運(yùn)行、系統(tǒng)驗(yàn)收、系統(tǒng)上線和數(shù)據(jù)遷移。
第五條 除特別指定,本制度中項(xiàng)目組包括業(yè)務(wù)組(或需求提出組)、IT組(可能包括網(wǎng)絡(luò)管理員和合作開發(fā)商)。
第二節(jié) 立項(xiàng)管理
第六條 提出開發(fā)需求的信息技術(shù)部門參與公司層面立項(xiàng),進(jìn)行立項(xiàng)的技術(shù)可行性分析,編寫《立項(xiàng)分析報(bào)告》,開展前期籌備工作。《立項(xiàng)分析報(bào)告》應(yīng)明確項(xiàng)目的范圍和邊界。
第七條 第八條 應(yīng)用系統(tǒng)主要使用部門將《立項(xiàng)分析報(bào)告》上交公司進(jìn)行立項(xiàng)審批。《立項(xiàng)分析報(bào)告》得到批準(zhǔn)后,成立項(xiàng)目組(如果是外包開發(fā),則成立外包商項(xiàng)目組;如果是合作開發(fā),則與外包商共同成立合作開發(fā)項(xiàng)目組,以下統(tǒng)稱“項(xiàng)目組”),項(xiàng)目組應(yīng)包括業(yè)務(wù)組(由公司相關(guān)業(yè)務(wù)部門組成)和IT組(自行開發(fā)為辦公室網(wǎng)絡(luò)管理員;外包開發(fā)為外包商成員;合作開發(fā)為網(wǎng)絡(luò)管理員和外包商成員)。公司委派一名員工負(fù)責(zé)監(jiān)督項(xiàng)目的進(jìn)度,進(jìn)
第九條
第十條
第十一條第十二條第十三條第十四條第十五條第十六條第十七條行項(xiàng)目管理工作,確保開發(fā)能及時(shí)完成并能滿足業(yè)務(wù)需要。項(xiàng)目組人員的選擇應(yīng)滿足項(xiàng)目對(duì)業(yè)務(wù)及技術(shù)要求,項(xiàng)目組人員應(yīng)有足夠的業(yè)務(wù)和IT技術(shù)方面的專業(yè)知識(shí)來勝任項(xiàng)目各方面的工作。
第三節(jié) 需求分析
立項(xiàng)后業(yè)務(wù)組對(duì)用戶需求進(jìn)行匯總整理,出具《業(yè)務(wù)需求說明書》,并確保《業(yè)務(wù)需求說明書》中包含了所有的業(yè)務(wù)需求。經(jīng)系統(tǒng)使用部門審批確認(rèn),作為業(yè)務(wù)需求基線。
IT組在獲得《業(yè)務(wù)需求說明書》后,提出技術(shù)需求和解決方案,并對(duì)系統(tǒng)進(jìn)行定義,出具《系統(tǒng)需求規(guī)格說明書》。《系統(tǒng)需求規(guī)格說明書》需詳細(xì)列出業(yè)務(wù)對(duì)系統(tǒng)的要求(界面、輸入、輸出、管理功能、安全需求、運(yùn)作模式、關(guān)鍵指標(biāo)(KPI)等)。《系統(tǒng)需求規(guī)格說明書》需要由業(yè)務(wù)組提交給相關(guān)業(yè)務(wù)流程負(fù)責(zé)人確認(rèn)。
對(duì)于合作開發(fā)的項(xiàng)目,當(dāng)業(yè)務(wù)需求發(fā)生變更時(shí),業(yè)務(wù)組應(yīng)提交《需求變更申請(qǐng)》,IT組組長審批后交給合作開發(fā)商實(shí)施。
項(xiàng)目組應(yīng)對(duì)需求變更影響到的文檔及時(shí)更新。
第四節(jié) 項(xiàng)目計(jì)劃和監(jiān)控
軟件開發(fā)采用項(xiàng)目形式進(jìn)行管理。項(xiàng)目經(jīng)理負(fù)責(zé)整個(gè)項(xiàng)目的計(jì)劃、組織、領(lǐng)導(dǎo)和控制。
需求分析過程中,項(xiàng)目經(jīng)理組織制定詳細(xì)的《項(xiàng)目計(jì)劃書》,包括具體任務(wù)描述和項(xiàng)目進(jìn)度表等。
在項(xiàng)目的各個(gè)階段,業(yè)務(wù)組組長和IT組組長需配合項(xiàng)目經(jīng)理制定階段性項(xiàng)目計(jì)劃。業(yè)務(wù)組組長和IT組組長需配合項(xiàng)目經(jīng)理對(duì)項(xiàng)目計(jì)劃執(zhí)行情況進(jìn)行監(jiān)控,確保項(xiàng)目按計(jì)劃完成。
項(xiàng)目計(jì)劃需要變更時(shí),項(xiàng)目經(jīng)理填寫《項(xiàng)目計(jì)劃變更說明》,并提交公司主管領(lǐng)導(dǎo)審批,通過審批后,交給業(yè)務(wù)組組長和IT組組長執(zhí)行。
第五節(jié) 系統(tǒng)設(shè)計(jì)
系統(tǒng)設(shè)計(jì)應(yīng)分為概要設(shè)計(jì)和詳細(xì)設(shè)計(jì),系統(tǒng)設(shè)計(jì)要遵循完備性、一致性、第十八條 第十九條
第二十條
第二十一條第二十二條第二十三條第二十四條第二十五條第二十六條第二十七條第二十八條第二十九條擴(kuò)展性、可靠性、安全性、可維護(hù)性等原則。
在系統(tǒng)設(shè)計(jì)階段中,用戶應(yīng)充分參與,確保系統(tǒng)設(shè)計(jì)能滿足系統(tǒng)需求。項(xiàng)目組進(jìn)行詳細(xì)設(shè)計(jì),出具《設(shè)計(jì)說明書》和《單元測試用例》。《設(shè)計(jì)說明書》中需要定義系統(tǒng)輸入輸出說明和接口設(shè)計(jì)說明。公司主管領(lǐng)導(dǎo)組織相關(guān)人員對(duì)概要設(shè)計(jì)進(jìn)行評(píng)審,出具《設(shè)計(jì)評(píng)審報(bào)告》。業(yè)務(wù)組組長和IT組組長應(yīng)參加此評(píng)審并對(duì)評(píng)審意見簽字確認(rèn)。
設(shè)計(jì)評(píng)審均以《業(yè)務(wù)需求說明書》和《系統(tǒng)需求規(guī)格說明書》為依據(jù),確保系統(tǒng)設(shè)計(jì)滿足全部需求。
對(duì)已確認(rèn)通過的系統(tǒng)設(shè)計(jì)進(jìn)行修改需獲得管理部門、業(yè)務(wù)組組長和IT組組長的審批后方可進(jìn)行。
對(duì)系統(tǒng)設(shè)計(jì)的修改的文檔須由文檔管理人員進(jìn)行歸檔管理。
第六節(jié) 系統(tǒng)實(shí)現(xiàn)
項(xiàng)目組根據(jù)《設(shè)計(jì)說明書》制定系統(tǒng)實(shí)現(xiàn)計(jì)劃,并提交項(xiàng)目經(jīng)理對(duì)計(jì)劃可行性進(jìn)行審批。
系統(tǒng)實(shí)現(xiàn)包括程序編碼、單元測試和集成測試。
項(xiàng)目組保證開發(fā)、測試和生產(chǎn)環(huán)境獨(dú)立,為各環(huán)境建立訪問權(quán)限控制機(jī)制,并明確項(xiàng)目成員的職責(zé)分工。對(duì)開發(fā)環(huán)境、測試環(huán)境與生產(chǎn)環(huán)境在物理或邏輯方面應(yīng)該做到隔離;如果環(huán)境的分隔是通過邏輯形式實(shí)現(xiàn)的,應(yīng)定期檢查網(wǎng)絡(luò)設(shè)置。項(xiàng)目組對(duì)已授權(quán)訪問生產(chǎn)環(huán)境的人員進(jìn)行詳細(xì)記錄,并對(duì)該記錄進(jìn)行定期檢查,確保只有經(jīng)授權(quán)的人員才能訪問到生產(chǎn)環(huán)境。
項(xiàng)目組進(jìn)行單元測試和集成測試,測試人員簽字確認(rèn)測試結(jié)果。
第七節(jié) 系統(tǒng)測試和用戶測試
項(xiàng)目組制定《系統(tǒng)/用戶測試計(jì)劃》,并提交項(xiàng)目經(jīng)理對(duì)計(jì)劃可行性進(jìn)行審批。
《系統(tǒng)/用戶測試計(jì)劃》必須定義測試標(biāo)準(zhǔn),并明確各種測試的測試步驟和需要的系統(tǒng)設(shè)置要求。
項(xiàng)目組向數(shù)據(jù)擁有部門申請(qǐng)獲取測試用業(yè)務(wù)數(shù)據(jù)的使用權(quán),對(duì)獲取的數(shù)據(jù)進(jìn)行嚴(yán)格的訪問控制,確保只有相關(guān)項(xiàng)目人員才能訪問及使用。
第三十條 項(xiàng)目組負(fù)責(zé)測試數(shù)據(jù)準(zhǔn)備,測試用數(shù)據(jù)要足夠模擬生產(chǎn)環(huán)境中的實(shí)際數(shù)據(jù)。對(duì)已評(píng)定為敏感信息的數(shù)據(jù)進(jìn)行敏感性處理和保護(hù)。
第三十一條 IT組或合作開發(fā)商建立測試環(huán)境進(jìn)行系統(tǒng)測試。在系統(tǒng)測試中對(duì)新系統(tǒng)內(nèi)部各模塊之間的接口和與其他系統(tǒng)的接口進(jìn)行充分測試。出具《系統(tǒng)測試報(bào)告》,測試人員簽字確認(rèn)測試結(jié)果。
第三十二條 系統(tǒng)測試通過后,IT組配合業(yè)務(wù)組建立用戶測試環(huán)境,業(yè)務(wù)組根據(jù)用戶測第三十三條
第三十四條 第三十五條 第三十六條 第三十七條 第三十八條 第三十九條 第四十條 試用例進(jìn)行用戶測試,出具《用戶測試報(bào)告》,業(yè)務(wù)組組長和IT組組長應(yīng)在用戶測試報(bào)告中簽字確認(rèn)。
項(xiàng)目組完成系統(tǒng)幫助文檔(其中包括《用戶操作手冊》和《安裝維護(hù)手冊》)。凡涉及應(yīng)用系統(tǒng)的變更,應(yīng)對(duì)系統(tǒng)幫助文檔及時(shí)更新。
第八節(jié) 試運(yùn)行
系統(tǒng)主要使用部門根據(jù)項(xiàng)目規(guī)模及影響決定試運(yùn)行策略。
項(xiàng)目組制定《試運(yùn)行計(jì)劃》,并制定試運(yùn)行驗(yàn)收指標(biāo),上報(bào)公司主管領(lǐng)導(dǎo)審批。《試運(yùn)行計(jì)劃》中應(yīng)包含問題應(yīng)對(duì)機(jī)制,明確問題溝通渠道和職責(zé)分工。
項(xiàng)目組聯(lián)合試運(yùn)行單位進(jìn)行相關(guān)系統(tǒng)部署工作,準(zhǔn)備培訓(xùn)資料,對(duì)相關(guān)用戶和信息技術(shù)人員進(jìn)行培訓(xùn)。用戶培訓(xùn)的完成度應(yīng)為實(shí)施后評(píng)估的指標(biāo)之一。
項(xiàng)目組根據(jù)《試運(yùn)行計(jì)劃》進(jìn)行系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移。系統(tǒng)轉(zhuǎn)換前,檢查系統(tǒng)環(huán)境,確保運(yùn)行環(huán)境能滿足新應(yīng)用系統(tǒng)的需要。系統(tǒng)轉(zhuǎn)換時(shí)必須詳細(xì)記錄原系統(tǒng)中的重要參數(shù)、設(shè)置等系統(tǒng)信息,并填寫試運(yùn)行報(bào)告相關(guān)內(nèi)容。系統(tǒng)參數(shù)、設(shè)置的轉(zhuǎn)換工作作為系統(tǒng)上線的驗(yàn)收的評(píng)估指標(biāo)之一。
數(shù)據(jù)遷移前,應(yīng)制定詳細(xì)的《數(shù)據(jù)遷移計(jì)劃》,《數(shù)據(jù)遷移計(jì)劃》中應(yīng)包含遷移方案、測試方案、數(shù)據(jù)定義,新舊數(shù)據(jù)對(duì)照表、遷移時(shí)間、回退計(jì)劃等信息。數(shù)據(jù)遷移計(jì)劃需經(jīng)項(xiàng)目經(jīng)理和主管領(lǐng)導(dǎo)簽字審批。
數(shù)據(jù)遷移后,項(xiàng)目組對(duì)數(shù)據(jù)遷移的完整性和準(zhǔn)確性作出檢查,出具《數(shù)據(jù)遷移報(bào)告》,其中包括數(shù)據(jù)來源、轉(zhuǎn)換前狀態(tài)、轉(zhuǎn)換后狀態(tài),數(shù)據(jù)遷移負(fù)責(zé)人、對(duì)完整性檢查情況、對(duì)準(zhǔn)確性檢查情況等內(nèi)容。各相關(guān)部門驗(yàn)收轉(zhuǎn)換結(jié)果后在該報(bào)告上簽字確認(rèn)。
系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移由試運(yùn)行單位業(yè)務(wù)部門和公司主管領(lǐng)導(dǎo)共同監(jiān)督并進(jìn)行驗(yàn)收。
第四十一條 系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移驗(yàn)收通過后,正式啟動(dòng)試運(yùn)行。在試運(yùn)行過程中,試運(yùn)行單位辦公室把系統(tǒng)運(yùn)行情況(系統(tǒng)資源使用,反應(yīng)速度等)記錄到試運(yùn)行報(bào)告中。必要時(shí),項(xiàng)目組應(yīng)根據(jù)系統(tǒng)運(yùn)行情況對(duì)應(yīng)用系統(tǒng)進(jìn)行優(yōu)化。
第四十二條 試運(yùn)行達(dá)到試運(yùn)行計(jì)劃規(guī)定的終止條件時(shí),項(xiàng)目組編寫《試運(yùn)行報(bào)告》。此
第四十三條 第四十四條 第四十五條 第四十六條 第四十七條 第四十八條 第四十九條 報(bào)告應(yīng)由項(xiàng)目組和試運(yùn)行單位簽字確認(rèn),并提交公司主管領(lǐng)導(dǎo)審閱。公司主管領(lǐng)導(dǎo)審閱試運(yùn)行結(jié)果,決定試運(yùn)行結(jié)束或延期。
第九節(jié) 系統(tǒng)驗(yàn)收
系統(tǒng)主要使用部門及信息技術(shù)部門聯(lián)合組成獨(dú)立系統(tǒng)驗(yàn)收小組,也可授權(quán)原項(xiàng)目組作為驗(yàn)收小組。驗(yàn)收小組從功能需求及技術(shù)需求層面對(duì)系統(tǒng)進(jìn)行綜合評(píng)估。
驗(yàn)收小組應(yīng)根據(jù)驗(yàn)收情況整理形成《系統(tǒng)驗(yàn)收?qǐng)?bào)告》提交系統(tǒng)主要使用部門和信息技術(shù)部門審閱。
系統(tǒng)主要使用部門和信息技術(shù)部門負(fù)責(zé)人根據(jù)系統(tǒng)測試、試運(yùn)行情況簽署驗(yàn)收意見。
第十節(jié) 系統(tǒng)上線
系統(tǒng)上線應(yīng)遵循穩(wěn)妥、可控、安全的原則。通常情況下,系統(tǒng)上線包含數(shù)據(jù)遷移工作。
項(xiàng)目組制定《系統(tǒng)上線計(jì)劃》,上報(bào)公司主管領(lǐng)導(dǎo)審批。在上線計(jì)劃得到批準(zhǔn)后才能開始部署上線工作。
《系統(tǒng)上線計(jì)劃》內(nèi)容應(yīng)包括但不限于:
1、部署方式和資源分配(包括人力資源及服務(wù)器資源);
2、上線工作時(shí)間表;
3、上線操作步驟以及問題處理步驟;
4、項(xiàng)目階段性里程碑和成果匯報(bào)(項(xiàng)目執(zhí)行狀態(tài)的審閱、進(jìn)度安排等);
5、數(shù)據(jù)遷移的需求和實(shí)施計(jì)劃;
6、完整可行的應(yīng)急預(yù)案和“回退”計(jì)劃;
7、用戶培訓(xùn)計(jì)劃(包括:培訓(xùn)計(jì)劃、培訓(xùn)手冊、培訓(xùn)考核等);
8、公司下發(fā)的系統(tǒng)標(biāo)準(zhǔn)參數(shù)配置。
第五十條 上線單位在上線初期需加強(qiáng)日常運(yùn)行狀態(tài)監(jiān)控,出現(xiàn)問題時(shí)應(yīng)及時(shí)處理,對(duì)重大問題應(yīng)啟動(dòng)緊急預(yù)案。
第五十一條 在完成上線后要填寫《系統(tǒng)驗(yàn)收評(píng)估報(bào)告》,上報(bào)公司項(xiàng)目組匯總整理。第五十二條 第五十三條
第五十四條 第五十五條 第五十六條 第五十七條 第五十八條 第五十九條 第六十條
第六十一條 第六十二條 第六十三條 第六十四條 《系統(tǒng)驗(yàn)收評(píng)估報(bào)告》內(nèi)容包括:數(shù)據(jù)準(zhǔn)確性、系統(tǒng)性能及穩(wěn)定性、接口問題、權(quán)限問題、業(yè)務(wù)操作影響度、問題處理情況、備份、批處理等。
上線單位管理層要對(duì)《系統(tǒng)驗(yàn)收評(píng)估報(bào)告》進(jìn)行審批簽字。
公司主管領(lǐng)導(dǎo)批準(zhǔn)結(jié)項(xiàng)后,業(yè)務(wù)組和IT組將整理的文檔提交各自部門統(tǒng)一管理。
第十一節(jié) 合作開發(fā)管理
合作開發(fā)商的選擇應(yīng)遵循公司相關(guān)規(guī)定,合作商資質(zhì)認(rèn)定參見第三方管理制度。
合作開發(fā)商必須遵循公司《軟件開發(fā)管理制度》。
項(xiàng)目經(jīng)理同合作開發(fā)商明確規(guī)定項(xiàng)目變更的范圍和處理方式,重點(diǎn)關(guān)注需求和設(shè)計(jì)變更。
項(xiàng)目經(jīng)理負(fù)責(zé)監(jiān)控合作開發(fā)商的項(xiàng)目管理及軟件開發(fā)活動(dòng)。合作開發(fā)商應(yīng)按計(jì)劃定期向項(xiàng)目經(jīng)理報(bào)告進(jìn)展?fàn)顟B(tài),并提交階段性成果文檔。發(fā)生重大問題時(shí),合作開發(fā)商需及時(shí)向項(xiàng)目經(jīng)理匯報(bào)。
IT組組長派專人監(jiān)控合作開發(fā)商的質(zhì)量保證過程。項(xiàng)目組同合作開發(fā)商商定驗(yàn)收的標(biāo)準(zhǔn)和方法。以上各要求需要在開發(fā)合同中明確。
第十二節(jié) 外包開發(fā)管理
立項(xiàng)申請(qǐng)得到公司主管領(lǐng)導(dǎo)的審批后,選定開發(fā)商,簽訂外包開發(fā)合同。項(xiàng)目經(jīng)理負(fù)責(zé)監(jiān)控外包開發(fā)商的項(xiàng)目管理及軟件開發(fā)活動(dòng)。外包開發(fā)商應(yīng)按計(jì)劃定期向項(xiàng)目經(jīng)理報(bào)告進(jìn)展?fàn)顟B(tài),并提交階段性成果文檔。發(fā)生重大問題時(shí),外包開發(fā)商需及時(shí)向項(xiàng)目經(jīng)理匯報(bào)。
項(xiàng)目經(jīng)理監(jiān)控外包開發(fā)商的質(zhì)量保證過程。項(xiàng)目組同外包開發(fā)商商定驗(yàn)收的標(biāo)準(zhǔn)和方法。第六十五條 以上各要求需要在開發(fā)合同中明確。
第二篇:軟件開發(fā)安全管理規(guī)定
xxx軟件開發(fā)安全管理規(guī)定
第一章
總則
第一條
為加強(qiáng)xxx軟件開發(fā)的安全管理,保護(hù)軟件開發(fā)中軟件和信息的安全,依據(jù)《》、《》等要求,特制訂本規(guī)定。
第二條
本規(guī)定適用于xxx軟件開發(fā)過程中需求分析、設(shè)計(jì)、開發(fā)及測試等階段的安全管理。
第二章
軟件安全需求分析
第三條
業(yè)務(wù)需求提出人員應(yīng)會(huì)同需求分析人員,確定業(yè)務(wù)持續(xù)性、輸入輸出、身份欺騙及抗抵賴等方面的業(yè)務(wù)風(fēng)險(xiǎn)。
第四條
業(yè)務(wù)需求提出人員應(yīng)會(huì)同需求分析人員,依據(jù)業(yè)務(wù)風(fēng)險(xiǎn),提出系統(tǒng)功能、性能及數(shù)據(jù)等方面的業(yè)務(wù)安全需求。
第五條
需求分析人員應(yīng)根據(jù)業(yè)務(wù)安全需求,進(jìn)行資產(chǎn)識(shí)別、資產(chǎn)分析和風(fēng)險(xiǎn)分析,確定軟件的安全需求。
第六條
需求分析人員應(yīng)明確軟件系統(tǒng)的安全目標(biāo),并提交安全需求規(guī)格說明書(或需求規(guī)格說明書包括安全需求部分),包括系統(tǒng)需要保護(hù)的要素、保護(hù)程度,應(yīng)用系統(tǒng)中存在的威脅、脆弱性及其風(fēng)險(xiǎn)等。
第七條
xx部門應(yīng)會(huì)同信息安全相關(guān)處室組織對(duì)整體安全目標(biāo)進(jìn)行評(píng)審并確認(rèn)。
第三章
軟件安全設(shè)計(jì)
第八條
設(shè)計(jì)人員應(yīng)根據(jù)安全目標(biāo)進(jìn)行安全設(shè)計(jì),在符合xxx信息化架構(gòu)規(guī)劃的基礎(chǔ)上,確保安全功能的完整實(shí)現(xiàn),并提交安全設(shè)計(jì)方案(或總體方案設(shè)計(jì)文檔中包括安全方案設(shè)計(jì)部分)。
第九條
安全設(shè)計(jì)應(yīng)遵循:
(一)保護(hù)最薄弱的環(huán)節(jié)原則:保護(hù)最易受攻擊影響的部分;
(二)縱深防御原則:不同層面、不同角度之間需要相互配合;
(三)最小權(quán)限原則:只授予執(zhí)行操作所需的最小權(quán)限;
(四)最小共享原則:使共享文件資源盡可能少;
(五)權(quán)限分離原則:授予不同用戶所需的最小權(quán)限,并在它們之間形成相互制約的關(guān)系。
第十條
安全設(shè)計(jì)應(yīng)包括:
(一)確定安全體系架構(gòu),設(shè)計(jì)安全協(xié)議和安全接口;
(二)確定訪問控制與身份鑒別機(jī)制,定義主體角色和權(quán)限;
(三)信息輸入的安全過濾,信息輸出的校驗(yàn)和控制;
(四)數(shù)據(jù)結(jié)構(gòu)安全設(shè)計(jì),選擇加密方法和算法;
(五)確定敏感數(shù)據(jù)保護(hù)方法;
(六)內(nèi)部處理邏輯安全設(shè)計(jì);
(七)評(píng)估內(nèi)部通信機(jī)制,確定完整性機(jī)制。
第十一條
xx部門會(huì)同信息安全相關(guān)處室組織對(duì)安全設(shè)計(jì)方案進(jìn)行評(píng)審并確認(rèn)。
第四章
軟件安全開發(fā)
第十二條
開發(fā)人員根據(jù)安全設(shè)計(jì)方案進(jìn)行系統(tǒng)安全開發(fā),確保開發(fā)環(huán)境、編碼及系統(tǒng)流程控制的安全。
第十三條
開發(fā)環(huán)境安全管理要求:
(一)軟件系統(tǒng)開發(fā)、測試不得在生產(chǎn)環(huán)境中進(jìn)行;
(二)開發(fā)環(huán)境中所使用的操作系統(tǒng)、開發(fā)工具、數(shù)據(jù)庫等必須是正版軟件;
(三)開發(fā)環(huán)境中的開發(fā)用機(jī)應(yīng)進(jìn)行統(tǒng)一安全配置,及時(shí)進(jìn)行系統(tǒng)補(bǔ)丁升級(jí)和漏洞修復(fù)。
第十四條
編碼安全要求:
(一)遵循代碼編寫安全規(guī)范,根據(jù)代碼編寫安全規(guī)范以及安全設(shè)計(jì)方案進(jìn)行系統(tǒng)開發(fā);
(二)遵循通用安全編程準(zhǔn)則,包括輸入驗(yàn)證、緩存溢出、安全調(diào)用組件和程序編譯等;
(三)遵循機(jī)密性要求,保護(hù)用戶訪問信息的機(jī)密性,嚴(yán)禁在客戶端存放敏感數(shù)據(jù),避免內(nèi)存溢出,嚴(yán)格檢查和驗(yàn)證輸入輸出信息等;
(四)遵循結(jié)構(gòu)化異常處理機(jī)制,捕捉并處理程序異常,防止系統(tǒng)信息泄露;
(五)遵循代碼脆弱性防范要求,包括緩沖區(qū)溢出、SQL注入、跨站腳本攻擊、XML注入攻擊、HTTP
HEAD注入等。
第十五條
開發(fā)流程安全要求:
(一)開發(fā)過程中應(yīng)對(duì)階段性開發(fā)成果進(jìn)行有效管理;
(二)開發(fā)過程中應(yīng)定期進(jìn)行代碼靜態(tài)分析,使用代碼審核工具對(duì)源代碼進(jìn)行檢測,并報(bào)告源代碼中存在的安全弱點(diǎn)。
第十六條
開發(fā)人員不得超越其規(guī)定權(quán)限進(jìn)行開發(fā),不得在程序中設(shè)置后門或惡意代碼程序。
第五章
軟件安全測試
第十七條
測試內(nèi)容應(yīng)包括代碼的安全測試和安全功能測試。代碼的安全測試是指使用代碼測試工具來識(shí)別代碼的安全脆弱性,并應(yīng)按照其提供的修復(fù)建議進(jìn)行修復(fù)。安全功能測試主要包括身份認(rèn)證和訪問控制的功能測試。
第十八條
測試系統(tǒng)環(huán)境應(yīng)盡可能模擬生產(chǎn)環(huán)境,并與生產(chǎn)環(huán)境進(jìn)行安全隔離。
第十九條
真實(shí)數(shù)據(jù)不得直接在測試環(huán)境中使用,須進(jìn)行適當(dāng)修改或屏蔽。在測試完成之后,須立即從測試應(yīng)用系統(tǒng)清除運(yùn)行信息。
第二十條
測試人員編制安全測試方案,構(gòu)造安全測試用例。
第二十一條
測試人員不得由開發(fā)人員兼任。
第二十二條
信息安全等級(jí)保護(hù)定級(jí)為二級(jí)及以下的應(yīng)用軟件,由xx部門組織代碼漏洞檢測;信息安全等級(jí)保護(hù)定級(jí)為三級(jí)及以上的應(yīng)用軟件,xx部門應(yīng)聘請(qǐng)有相關(guān)資質(zhì)的專業(yè)機(jī)構(gòu)進(jìn)行代碼漏洞檢測,并提交分析報(bào)告。
第六章
文檔安全管理
第二十三條
xx部門應(yīng)對(duì)源代碼的變更和版本發(fā)布進(jìn)行統(tǒng)一控制,對(duì)程序資源庫的任何修改、更新和發(fā)布都需經(jīng)xx部門主管領(lǐng)導(dǎo)授權(quán)和批準(zhǔn)。
第二十四條
xx部門應(yīng)指定專人妥善保管程序源代碼及相關(guān)技術(shù)文檔(見附),對(duì)于源代碼與技術(shù)文檔實(shí)行授權(quán)訪問。
第二十五條
軟件程序不得篡改應(yīng)用軟件所運(yùn)行的環(huán)境或平臺(tái)中任何安全配置、安全文件和安全程序。
第七章
外包開發(fā)安全管理
第二十六條
xx部門應(yīng)與外包開發(fā)單位簽署相關(guān)知識(shí)產(chǎn)權(quán)保護(hù)協(xié)議和保密協(xié)議。
第二十七條
外包開發(fā)單位進(jìn)行系統(tǒng)開發(fā)過程中,須嚴(yán)格遵循本規(guī)定軟件開發(fā)各階段的相關(guān)安全要求。
第二十八條
xx部門在系統(tǒng)開發(fā)過程中,須指派專人監(jiān)督審核外包開發(fā)單位在各個(gè)階段安全要求的執(zhí)行情況。
第二十九條
外包開發(fā)單位在系統(tǒng)開發(fā)完成后向xx部門提供程序源代碼和相關(guān)技術(shù)文檔,不得將計(jì)算機(jī)系統(tǒng)采用的關(guān)鍵安全技術(shù)措施和核心安全功能設(shè)計(jì)對(duì)外公開。
第三十條
xx部門應(yīng)對(duì)開發(fā)完成后的應(yīng)用軟件進(jìn)行審查或檢測。
第八章
附則
第三十一條
xxx參照?qǐng)?zhí)行本規(guī)定。
第三十二條
本規(guī)定由xxxx負(fù)責(zé)解釋和修訂。
第三十三條
本規(guī)定自發(fā)布之日起執(zhí)行。
附
系統(tǒng)開發(fā)相關(guān)技術(shù)文檔清單:
業(yè)務(wù)需求書(其中包含信息安全業(yè)務(wù)需求部分)
安全需求規(guī)格說明書(或需求規(guī)格說明書包括安全需求部分)
安全方案設(shè)計(jì)文檔(或總體方案設(shè)計(jì)文檔中包括安全方案設(shè)計(jì)部分)
程序源代碼
開發(fā)過程中產(chǎn)生的記錄
測試方案
測試過程記錄
測試報(bào)告
代碼分析報(bào)告
系統(tǒng)配置文檔
系統(tǒng)使用指南及操作手冊
附件無
文檔內(nèi)容僅供參考
第三篇:軟件開發(fā)管理流程
軟件開發(fā)管理流程
根據(jù)我公司目前工作現(xiàn)狀,開發(fā)管理流程涉及到三個(gè)方向的工作管理;一是全新項(xiàng)目開發(fā)整體流程;二是二期項(xiàng)目開發(fā)管理流程(項(xiàng)目已部分上線,二期進(jìn)行其它公司或模塊上線);三是維護(hù)工作管理流程;
一、升級(jí)項(xiàng)目流程
針對(duì)我公司現(xiàn)有的BSP項(xiàng)目,存在有些省份的BSP項(xiàng)目存在部分上線而對(duì)于后期需要繼續(xù)上線其他部分的情況,提出以下工作流程。
總體流程
計(jì)劃階段-》需求分析階段-》軟件開發(fā)階段-》測試階段-》部署上線—》驗(yàn)收完成(一)計(jì)劃階段
制定整體開發(fā)計(jì)劃,計(jì)劃體現(xiàn)整個(gè)開發(fā)周期,包括需求、編碼、測試周期以及資源要求;
(二)需求分析階段
修訂需求版本,提供需求說明書,并提出需求評(píng)審申請(qǐng)。
評(píng)審:發(fā)起需求評(píng)審的同時(shí)提交評(píng)審資料至項(xiàng)目管理部—》項(xiàng)目管理部給相關(guān)
人員發(fā)放資料并通知評(píng)審安排--》記錄評(píng)審結(jié)果(需整改時(shí)整改之后可再次評(píng)審)--》確定需求版本。
(三)軟件開發(fā)階段
編碼開發(fā)前:開發(fā)環(huán)境搭建,其中包括遷出代碼最新版本,從線上復(fù)制出數(shù)據(jù)庫(或者導(dǎo)出基礎(chǔ)數(shù)據(jù)庫表數(shù)據(jù));其目的為開發(fā)環(huán)境與正式環(huán)境保持一致,為上線前的部署做好準(zhǔn)備。
編碼開發(fā)中:開發(fā)組長對(duì)整個(gè)開發(fā)過程做好監(jiān)控,保證質(zhì)量的同時(shí)保證進(jìn)度;并且要求開發(fā)人員做好工作記錄;加強(qiáng)團(tuán)隊(duì)的協(xié)作與溝通。
編碼開發(fā)完:提交相關(guān)資料(操作手冊、部署文檔:sql腳本、代碼文件路徑記錄、流程文件路徑記錄),組長整理部署文檔并且提交測試申請(qǐng);部署文檔要求寫明部署步驟及部署內(nèi)容及相應(yīng)注釋;
(四)測試階段
測試組長根據(jù)測試申請(qǐng)中的測試內(nèi)容安排測試。測試環(huán)境模擬線上測試環(huán)境,根據(jù)部署文檔進(jìn)行部署,并且記錄所有補(bǔ)丁包。測試過程中開發(fā)人員在修改bug的同時(shí)需要維護(hù)部署文檔。
(五)部署
部署人員根據(jù)部署文檔中描述的步驟部署系統(tǒng)。完成之后實(shí)施人員安排驗(yàn)收。
二、全新項(xiàng)目開發(fā)管理流程
總體流程
計(jì)劃階段-》需求分析階段-》軟件開發(fā)階段-》測試階段-》部署上線—》驗(yàn)收完成(一)計(jì)劃階段
項(xiàng)目計(jì)劃草案和風(fēng)險(xiǎn)管理計(jì)劃作為第一步,確定、分析項(xiàng)目風(fēng)險(xiǎn)并確定其優(yōu)先級(jí),還要制定風(fēng)險(xiǎn)解決方案。本階段的目的是確立產(chǎn)品開發(fā)的經(jīng)濟(jì)理由。當(dāng)確定開發(fā)之后則制定軟件開發(fā)計(jì)劃、人員組織結(jié)構(gòu)定義及配備、過程控制計(jì)劃。
? 項(xiàng)目計(jì)劃草案
項(xiàng)目計(jì)劃草案應(yīng)包括產(chǎn)品簡介、產(chǎn)品目標(biāo)及功能說明、開發(fā)所需的資源、開發(fā)時(shí)間和里程碑。
? 風(fēng)險(xiǎn)管理計(jì)劃
就是把有可能出錯(cuò)或現(xiàn)在還不能確定的東西列出來,并制定出相應(yīng)的解決方案。風(fēng)險(xiǎn)發(fā)現(xiàn)得越早對(duì)項(xiàng)目越有利。
? 軟件開發(fā)計(jì)劃
軟件開發(fā)計(jì)劃的目的是收集控制項(xiàng)目時(shí)所需的所有信息,項(xiàng)目經(jīng)理
根據(jù)項(xiàng)目計(jì)劃來安排資源需求并根據(jù)時(shí)間表跟蹤項(xiàng)目進(jìn)度。項(xiàng)目團(tuán)隊(duì)
成員根據(jù)項(xiàng)目計(jì)劃以了解他們的工作任務(wù)、工作時(shí)間以及他們所依賴的其他活動(dòng)。
項(xiàng)目管理培訓(xùn)
可將計(jì)劃分成總體計(jì)劃和詳細(xì)計(jì)劃,總體計(jì)劃中每個(gè)任務(wù)為一個(gè)里
程碑,詳細(xì)計(jì)劃中必須將任務(wù)落實(shí)到個(gè)人。
軟件開發(fā)計(jì)劃還應(yīng)包括產(chǎn)品的應(yīng)收標(biāo)準(zhǔn)及應(yīng)收任務(wù)(包括確定需要
制訂的測試用例)。
? 人員組織結(jié)構(gòu)定義及配備
常見的人員組織結(jié)構(gòu)有垂直方案、水平方案、混合方案。垂直方案
中每個(gè)成員充當(dāng)多重角色。水平方案中每個(gè)成員充當(dāng)一到兩個(gè)角色。
混合方案則包括了經(jīng)驗(yàn)豐富的人員與新手相互融合。具體選擇根據(jù)人
員實(shí)際技能情況進(jìn)行選擇。
? 過程控制計(jì)劃
過程控制計(jì)劃的目的是收集項(xiàng)目計(jì)劃正常執(zhí)行所需的所有信息,用來
指導(dǎo)項(xiàng)目進(jìn)度的監(jiān)控、計(jì)劃的調(diào)整,確保項(xiàng)目按時(shí)完成。
(二)需求分析階段
需求分析階段的目的是在系統(tǒng)工作方面與用戶達(dá)成一致。
(1)軟件需求規(guī)約
詳細(xì)說明系統(tǒng)將要實(shí)現(xiàn)的所有功能。
(2)用戶界面原型
可以有三種表示方法:圖紙(在紙上)、位圖(繪圖工具)、可執(zhí)行文件(交互式)。
(三)軟件開發(fā)階段
本階段從物理上實(shí)現(xiàn)目標(biāo)系統(tǒng)。采用了面向?qū)ο蠓椒ā?/p>
(1)軟件架構(gòu)
說明軟件的組織結(jié)構(gòu)、部署結(jié)構(gòu)及運(yùn)行環(huán)境。
(2)功能設(shè)計(jì)
定義功能點(diǎn)之間的關(guān)聯(lián)。
(3)數(shù)據(jù)庫設(shè)計(jì)
定義數(shù)據(jù)庫表之間的關(guān)聯(lián)和各個(gè)表的字段。
(4)編碼和單元測試
按照設(shè)計(jì)文檔進(jìn)行編碼,每完成一個(gè)模塊應(yīng)進(jìn)行單元測試。
(5)集成系統(tǒng)
按軟件組織結(jié)構(gòu)的要求將各個(gè)子模塊組合起來。
(四)測試階段
測試的目的是在發(fā)布之前找出程序的錯(cuò)誤。包括:核實(shí)每個(gè)模塊是否正常運(yùn)行(參考設(shè)計(jì)文檔)、核實(shí)需求是否被正確實(shí)施(參考需求文檔)。
(1)測試計(jì)劃
收集和組織測試信息,為測試工作提供指導(dǎo)。
(2)測試數(shù)據(jù)
盡量使用真實(shí)數(shù)據(jù)。
(3)測試報(bào)告
記錄測試結(jié)果,詳細(xì)描述問題,提出解決辦法。
(4)用戶操作手冊
(五)管理軟件開發(fā)過程
有以下幾方面地工作:
(1)組織會(huì)議
討論會(huì)議、總結(jié)會(huì)議等。
(2)評(píng)審程序
對(duì)各個(gè)階段的工作結(jié)果進(jìn)行審核等。
(3)協(xié)調(diào)人員
(4)監(jiān)控進(jìn)度
軟件項(xiàng)目開發(fā)流程
第一個(gè)步驟是市場調(diào)研,技術(shù)和市場要結(jié)合才能體現(xiàn)最大價(jià)值。
第二個(gè)步驟是需求分析,需求人員出需求分析說明書。發(fā)起需求評(píng)審申請(qǐng),項(xiàng)目管理部組織開發(fā)團(tuán)隊(duì)進(jìn)行評(píng)審;
評(píng)審:發(fā)起需求評(píng)審的同時(shí)提交評(píng)審資料至項(xiàng)目管理部—》項(xiàng)目管理部給相關(guān)人員發(fā)放資料并通知評(píng)審安排--》記錄評(píng)審結(jié)果(需整改時(shí)整改之后可再次評(píng)審)--》確定需求版本。
第三個(gè)步驟是概要設(shè)計(jì),將系統(tǒng)功能模塊初步劃分,并給出合理的研發(fā)流程和資源要求。按照公司現(xiàn)狀,使用快速原型設(shè)計(jì)方法完成概要設(shè)計(jì)就可以進(jìn)入編碼階段了,通常采用這種方法是因?yàn)樯婕暗难邪l(fā)任務(wù)屬于新領(lǐng)域,技術(shù)主管人員一上來無法給出明確的詳細(xì)設(shè)計(jì)說明書,但是并不是說詳細(xì)設(shè)計(jì)說明書不重要,事實(shí)上快速原型法在完成原型代碼后,根據(jù)評(píng)測結(jié)果和經(jīng)驗(yàn)教訓(xùn)的總結(jié),還要重新進(jìn)行詳細(xì)設(shè)計(jì)的步驟
第四個(gè)步驟是詳細(xì)設(shè)計(jì),這是考驗(yàn)技術(shù)專家設(shè)計(jì)思維的重要關(guān)卡,詳細(xì)設(shè)計(jì)說明書應(yīng)當(dāng)把具體的模塊以最‘干凈’的方式提供給編碼者,使得系統(tǒng)整體模塊化達(dá)到最大;一份好的詳細(xì)設(shè)計(jì)說明書,可以使編碼的復(fù)雜性減低到最低。
第五個(gè)步驟是編碼,開發(fā)人員需嚴(yán)格按照編碼規(guī)范及需求文檔編碼,編碼時(shí)不同模塊之間的進(jìn)度協(xié)調(diào)和協(xié)作是最需要小心的,也許一個(gè)小模塊的問題就可能影響了整體進(jìn)度,讓很多程序員因此被迫停下工作等待,這種問題在以前的開發(fā)過程中都出現(xiàn)過。編碼時(shí)的相互溝通和應(yīng)急的解決手段都是相當(dāng)重要的。項(xiàng)目組長需提高對(duì)開發(fā)過程中問題的管控能力。盡量避免重大問題,提高工作效率。
第六個(gè)步驟是測試,測試有很多種:按照測試執(zhí)行方,可以分為內(nèi)部測試和外部測試;按照測試范圍,可以分為模塊測試和整體聯(lián)調(diào);按照測試條件,可以分為正常操作情況測試和異常情況測試;按照測試的輸入范圍,可以分為全覆蓋測試和抽樣測試。總之,測試同樣是項(xiàng)目研發(fā)中一個(gè)相當(dāng)重要的步驟。
第七個(gè)步驟是部署,搭建部署環(huán)境,按照部署方案進(jìn)行部署,完成后驗(yàn)收測試;
第四篇:軟件開發(fā)項(xiàng)目管理(范文)
管理目標(biāo)
1、所有關(guān)系人清晰明確地了解項(xiàng)目的需求和期望,努力做到滿足項(xiàng)目所有關(guān)系人的不同需求;項(xiàng)目關(guān)系人包括:項(xiàng)目團(tuán)隊(duì)成員和項(xiàng)目團(tuán)隊(duì)外(內(nèi)部/外部客戶,內(nèi)部/外部合作伙伴,經(jīng)銷商/客戶等)。
2、項(xiàng)目管理三要素平衡(時(shí)間/成本/質(zhì)量),即開發(fā)項(xiàng)目按需按時(shí)按質(zhì)的完成。
3、目標(biāo):功能滿足需求,設(shè)計(jì)支持變化,開發(fā)快速迭代,成果持續(xù)交付。
執(zhí)行概述
1、建立有效的工作流程保證項(xiàng)目的順利進(jìn)行,初期使用傳統(tǒng)RUP過程,引入部分敏捷方法,團(tuán)隊(duì)磨合完成后逐步實(shí)現(xiàn)敏捷開發(fā)全流程管理。
2、明確項(xiàng)目目標(biāo),制定具有可行性的項(xiàng)目計(jì)劃,有效明確的分解項(xiàng)目需求。
3、跟蹤設(shè)計(jì)/開發(fā)/測試/回歸/發(fā)布全流程,推動(dòng)項(xiàng)目按預(yù)定計(jì)劃執(zhí)行。
4、解決項(xiàng)目過程中出現(xiàn)的問題和沖突,一般集中在需求不明/工作量或時(shí)長/開發(fā)難度/跨部門協(xié)調(diào)等幾個(gè)方面。
5、調(diào)動(dòng)開發(fā)團(tuán)隊(duì)的積極性,創(chuàng)造力,推動(dòng)團(tuán)隊(duì)成員在項(xiàng)目過程中的學(xué)習(xí)成長。
6、風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)控制以及風(fēng)險(xiǎn)的預(yù)案。
項(xiàng)目管理
1、需求階段
對(duì)項(xiàng)目進(jìn)行技術(shù)可行性分析、技術(shù)評(píng)估、成本評(píng)估以及風(fēng)險(xiǎn)評(píng)估。與需求提出方的代表進(jìn)行需求討論,明確項(xiàng)目的目標(biāo)、價(jià)值。確定項(xiàng)目范圍、功能及優(yōu)先級(jí)。
組建項(xiàng)目團(tuán)隊(duì),特別要搞清楚項(xiàng)目的關(guān)鍵人。項(xiàng)目啟動(dòng)會(huì)議,相關(guān)的關(guān)系人都必須參加。
2、設(shè)計(jì)階段
根據(jù)確認(rèn)后的軟件需求規(guī)格說明書,制定項(xiàng)目進(jìn)度計(jì)劃,工作任務(wù)分解(WBS);資源申請(qǐng),項(xiàng)目涉及到的開發(fā)資源、測試資源、設(shè)計(jì)資源(包括人員和軟硬件資源);數(shù)據(jù)庫設(shè)計(jì);系統(tǒng)設(shè)計(jì);文檔(包括系統(tǒng)用例、Demo、測試用例等);評(píng)審會(huì)議。
設(shè)計(jì)階段結(jié)果交付一般為系統(tǒng)用例/系統(tǒng)原型/系統(tǒng)設(shè)計(jì)文檔(概要設(shè)計(jì)和詳細(xì)設(shè)計(jì))/數(shù)據(jù)庫設(shè)計(jì)文檔等。
該階段交付成果需要進(jìn)行評(píng)審。
3、執(zhí)行階段(開發(fā)和測試)準(zhǔn)備開發(fā)環(huán)境、測試環(huán)境。跟蹤,推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行。
項(xiàng)目成員以日?qǐng)?bào)/項(xiàng)目負(fù)責(zé)人以周報(bào)的形式通報(bào)各關(guān)系人當(dāng)前項(xiàng)目的進(jìn)展情況。按里程碑對(duì)階段成果進(jìn)行評(píng)估,以確保該階段完成的質(zhì)量。代碼審核,包括CS審核、SQL審核、WEB審核等。對(duì)需求變更進(jìn)行控制管理。
測試階段BUG響應(yīng)及改進(jìn)、收集反饋意見。對(duì)項(xiàng)目風(fēng)險(xiǎn)進(jìn)行管理。
4、發(fā)布階段
包括制定項(xiàng)目發(fā)布計(jì)劃,用戶培訓(xùn),發(fā)布上線。
5、試運(yùn)行階段
數(shù)據(jù)監(jiān)控(日志、服務(wù)器狀態(tài)),根據(jù)監(jiān)控出現(xiàn)的問題,及時(shí)進(jìn)行處理,改進(jìn)性能問題,特定情況執(zhí)行補(bǔ)丁升級(jí)。
6、收尾階段
產(chǎn)品交付,項(xiàng)目總結(jié)會(huì)。
常見問題
1、開發(fā)時(shí)間的估算
制定項(xiàng)目計(jì)劃時(shí),需要估算每個(gè)任務(wù)所需的時(shí)間,其中主要是開發(fā)任務(wù)中模塊的分配和時(shí)間估算,在公司現(xiàn)有的技術(shù)框架下,開發(fā)人員主要的工作是投入在具體的業(yè)務(wù)邏輯實(shí)現(xiàn)上。通常單個(gè)模塊開發(fā)時(shí)間取決于以下因素:
1、負(fù)責(zé)模塊的業(yè)務(wù)邏輯的復(fù)雜程度。
2、開發(fā)人員的技術(shù)水平和對(duì)項(xiàng)目所在應(yīng)用的熟悉程度(包括對(duì)框架和應(yīng)用的熟悉程度)。
3、模塊技術(shù)實(shí)現(xiàn)上是否存在難點(diǎn),所謂的技術(shù)難點(diǎn)定義是:在現(xiàn)有系統(tǒng)中還未實(shí)現(xiàn)的、開發(fā)人員自身未沒接觸過的技術(shù)。對(duì)于這樣的難點(diǎn),開發(fā)者沒有相關(guān)的代碼可以參考,自己也沒有經(jīng)驗(yàn),所以需要投入學(xué)習(xí)時(shí)間用于研究解決。
模塊分配和開發(fā)時(shí)間估算的步驟:
1、在劃分好模塊后,首先項(xiàng)目管理人員預(yù)先估算各個(gè)模塊所需要的開發(fā)時(shí)間。
2、召集所有開發(fā)人員,討論模塊的分配和開發(fā)時(shí)間估算。將劃分好的模塊,分配給開發(fā)人員,如狀況允許可允許開發(fā)人員自主選擇以提高開發(fā)人員的主動(dòng)性和參與性。分配模塊的時(shí)為確保開發(fā)的速度和質(zhì)量,基本原則如下:
A、類似的模塊由同一人負(fù)責(zé)開發(fā),比如用戶信息的增刪改應(yīng)由同一開發(fā)者負(fù)責(zé)。這樣開發(fā)者對(duì)相關(guān)邏輯會(huì)比較熟悉,代碼/接口的定義也會(huì)相對(duì)明確,溝通的成本低,相應(yīng)可以降低功能實(shí)現(xiàn)的缺陷概率。
B、技術(shù)難度較大的模塊由技術(shù)水平比較高的人負(fù)責(zé)。C、業(yè)務(wù)邏輯比較復(fù)雜的由對(duì)業(yè)務(wù)邏輯比較了解的人負(fù)責(zé)。
3、模塊分配完成后,開發(fā)人員評(píng)估自己負(fù)責(zé)開發(fā)的模塊所需要的時(shí)間。在此過程中應(yīng)
4、對(duì)開發(fā)人員估算的時(shí)間進(jìn)行確認(rèn)。在確認(rèn)過程中作為,項(xiàng)目管理者將預(yù)估時(shí)間和開與開發(fā)者討論每個(gè)模塊的技術(shù)實(shí)現(xiàn)細(xì)節(jié),使時(shí)間的估算更加準(zhǔn)確。發(fā)人員估算時(shí)間進(jìn)行比較。那些差異較大的,與人員探討其中的緣由。對(duì)于時(shí)間周期比較長的任務(wù),將任務(wù)拆分為更小的子任務(wù),每個(gè)任務(wù)的完成時(shí)間為8-24工時(shí),消除時(shí)間周期較長的任務(wù),避免不確定性影響項(xiàng)目的進(jìn)度。
2、CodeReview CodeReview是保證項(xiàng)目中代碼質(zhì)量非常重要的一個(gè)環(huán)節(jié),在這一環(huán)控制不嚴(yán)往往是測試后出現(xiàn)大量bug的主因,有時(shí)甚至導(dǎo)致返工;關(guān)于CodeReview執(zhí)行,首先應(yīng)有編碼規(guī)范和代碼審查規(guī)范。通過這兩個(gè)文檔來規(guī)范開發(fā)人員的代碼實(shí)現(xiàn),代碼編寫者必須要嚴(yán)格按照規(guī)范來進(jìn)行;代碼審核者根據(jù)這些標(biāo)準(zhǔn)來CodeReview代碼,同時(shí)在CodeReview過程中需要不斷完善該文檔。
CodeReview一般可按以下步驟實(shí)施:
1、檢查開發(fā)者的代碼實(shí)現(xiàn)是否遵循了編碼規(guī)范。
2、從代碼的易維護(hù)性、可擴(kuò)展性角度考察代碼的質(zhì)量,提出修改建議。
3、代碼編寫者和代碼審核者坐在一起,由代碼編寫者按照UseCase依次講解自己負(fù)責(zé)的代碼和相關(guān)邏輯,代碼審核者在此過程中可以隨時(shí)提出自己的疑問,同時(shí)積極發(fā)現(xiàn)隱藏的bug,對(duì)這些bug記錄在案。
4、代碼講解完畢后,代碼審核者給自己安排幾個(gè)小時(shí)再對(duì)代碼審核一遍。代碼需要檢查Bug。同時(shí)全面兼顧,確保代碼整體上結(jié)構(gòu)優(yōu)良;審核完畢后,代碼審核者編寫“代碼審核報(bào)告”記錄發(fā)現(xiàn)的問題及修改建議,提交給相關(guān)人員。
5、代碼編寫者根據(jù)“代碼審核報(bào)告”給出的修改意見,修改好代碼,有不清楚的地方可積極向代碼審核者提出。
6、代碼編寫者bugfixed完畢之后給出反饋。
7、代碼審核者把CodeReview中發(fā)現(xiàn)的有價(jià)值的問題更新到“代碼審核規(guī)范”的文檔中,對(duì)于特別值得提醒的問題可群發(fā)email給所有技術(shù)人員。
3、需求變更管理
需求變更管理也是項(xiàng)目管理中最重要的一個(gè)環(huán)節(jié),對(duì)需求變更管理的有效性將直接影響對(duì)待需求變更的正確態(tài)度:
1、需求變更是不可避免的。
2、需求變更要必須被管理。
3、積極發(fā)現(xiàn)引起變更的因素,促使變更盡可能早的出現(xiàn),減低變更帶來的風(fēng)險(xiǎn)。需求變更管理的目標(biāo):
1、相關(guān)的干系人必須清楚地了解發(fā)生的變更。
2、變更處于有效的管理中。
3、盡量降低變更帶來的風(fēng)險(xiǎn)。
通過制定需求變更的流程,確保項(xiàng)目中的需求變更有效地進(jìn)行,實(shí)現(xiàn)上述的目標(biāo)。需求變更流程:
1、確定需求的基準(zhǔn)線。將以UserCase作為需求基準(zhǔn)線,在UserCase確認(rèn)之后的任項(xiàng)目的成功與否。何需求改變,都需要走需求變更流程。
2、項(xiàng)目管理者接收到需求變更的要求。需求變更的提出者可以是項(xiàng)目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。
3、項(xiàng)目管理者評(píng)估該需求變更。針對(duì)接收到的需求變更的要求,召集相關(guān)人員討論該需求變更的合理性、可行性,實(shí)施的代價(jià)以及對(duì)項(xiàng)目的影響。項(xiàng)目管理者對(duì)項(xiàng)目的成功與否負(fù)有主要的責(zé)任。需求變更的決策應(yīng)由項(xiàng)目管理者做出。
4、需求變更確認(rèn)后,由專人將生成需求變更單記錄下來,通知給項(xiàng)目中所有關(guān)系人。
5、確定變更的負(fù)責(zé)人。承擔(dān)需求變更的具體工作,比如基線控制,對(duì)需求變更的記錄,并通知相關(guān)人員。
6、相關(guān)人員接收到確認(rèn)的需求變更后,需求分析人員修改需求說明書和UserCase的相關(guān)內(nèi)容。測試人員修改測試用例的相關(guān)內(nèi)容。開發(fā)人員修改代碼中的相關(guān)部分。
7、按照變更后的計(jì)劃實(shí)施項(xiàng)目,并進(jìn)行檢查,跟蹤,對(duì)變更后的實(shí)施反饋和可能出現(xiàn)的問題及時(shí)溝通和處理。
8、需求凍結(jié)。項(xiàng)目越到后期,需求變更對(duì)項(xiàng)目的影響就越大,所以在一定時(shí)候要進(jìn)入需求凍結(jié)階段,不再接收新需求或需求的變更。
4、風(fēng)險(xiǎn)管理
影響項(xiàng)目成敗的因素涉及方方面面,并且風(fēng)險(xiǎn)伴隨著項(xiàng)目的始終,是客觀存在的,風(fēng)險(xiǎn)引起的負(fù)面后果集中體現(xiàn)在進(jìn)度延后、成本超支、質(zhì)量不達(dá)標(biāo)等方面,常見風(fēng)險(xiǎn)如下:
1、目標(biāo)以及需求不明確
為了市場競爭或內(nèi)部管理決策的需要,業(yè)務(wù)部門提出的需求往往要求的時(shí)間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達(dá)上,沒有正式的業(yè)務(wù)需求文檔,在沒有明確的需求范圍的情況下,有時(shí)為了迎合業(yè)務(wù)部門的口味匆匆開工,過程中用戶不斷地提出新的想法,技術(shù)人員開始疲于奔命和應(yīng)付,很難保證項(xiàng)目的進(jìn)度和質(zhì)量,也難以取得業(yè)務(wù)部門的認(rèn)可。
在項(xiàng)目的前期一定要采取相應(yīng)的手段或措施,與業(yè)務(wù)部門共同明確項(xiàng)目目標(biāo)、需求范圍,充分考慮現(xiàn)有的時(shí)間和資源約束,將需求排定優(yōu)先級(jí),對(duì)于關(guān)鍵的需求優(yōu)先實(shí)現(xiàn),其他輔助性的根據(jù)過程中的具體情況進(jìn)行滾動(dòng)式計(jì)劃,并取得業(yè)務(wù)部門的書面確認(rèn)。在此過程中要注重挖掘用戶的隱性需求,可以通過引導(dǎo)、系統(tǒng)原型等手段讓用戶在前期充分暴露自己的想法和需求。
2、項(xiàng)目目標(biāo)擴(kuò)大以及需求變更
在有了明確的目標(biāo)和需求范圍的情況下,需求的變更還是不可避免的,業(yè)務(wù)部門在看到具體系統(tǒng)的真實(shí)雛形之后,源源不斷地要求、新想法隨之產(chǎn)生,如果不對(duì)此加以控制,新的需求的加入通常會(huì)影響已實(shí)現(xiàn)的需求,并且對(duì)項(xiàng)目進(jìn)度和成本產(chǎn)生很大的影響。項(xiàng)目管理者針對(duì)這種情況一定要采取嚴(yán)格的變更控制流程,不能礙于面子,否則最終的結(jié)果往往是出力不討好。針對(duì)用戶提出的新需求,按照正式流程提出變更申請(qǐng),組織相關(guān)團(tuán)隊(duì)成員進(jìn)行分析及評(píng)估,作為是否實(shí)施的依據(jù),變更控制負(fù)責(zé)人根據(jù)分析結(jié)果判斷是否批準(zhǔn),如果批準(zhǔn),那項(xiàng)目組可以安排實(shí)施,否則,正式拒絕用戶的請(qǐng)求。
前期的需求討論要詳細(xì)、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項(xiàng)目中需求的決策者(通常會(huì)是產(chǎn)品經(jīng)理、相關(guān)職能主管、客戶),所有的需求要經(jīng)過他們的認(rèn)可。客戶在項(xiàng)目過程中的全程參與有助于降低此類風(fēng)險(xiǎn)。需求討論、需求確認(rèn)、UserCase確認(rèn)、測試階段的客戶驗(yàn)收等環(huán)節(jié),都要要求客戶參與。在發(fā)生需求變更時(shí),嚴(yán)格按照需求變更流程執(zhí)行。在分析設(shè)計(jì)階段的中的確認(rèn)和評(píng)審也是降低此類風(fēng)險(xiǎn)的重要手段。
3、代碼質(zhì)量風(fēng)險(xiǎn)
質(zhì)量風(fēng)險(xiǎn)主要指開發(fā)代碼的質(zhì)量。在制定項(xiàng)目計(jì)劃時(shí),對(duì)開發(fā)時(shí)間的評(píng)估要盡可能的合適。合理的開發(fā)時(shí)間對(duì)開發(fā)質(zhì)量的影響很大。開發(fā)人員為了趕進(jìn)度在比較緊張的時(shí)間需要完成指定的任務(wù),可能就存在很大的開發(fā)質(zhì)量問題。在編碼前,開發(fā)人員要對(duì)框架熟練掌握;一份好的系統(tǒng)設(shè)計(jì)文檔對(duì)指導(dǎo)開發(fā)非常重要。
往往有這樣一種情況,每個(gè)團(tuán)隊(duì)成員按照項(xiàng)目計(jì)劃報(bào)告進(jìn)度都是100%完成,但一到最后系統(tǒng)交互測試或集成的時(shí)候就會(huì)發(fā)現(xiàn)一大堆問題。這需要在項(xiàng)目實(shí)施過程中采取有效的措施來規(guī)避風(fēng)險(xiǎn),通常的做法有同行評(píng)審,比如概要設(shè)計(jì)完成之后,邀請(qǐng)其他項(xiàng)目組的技術(shù)專家進(jìn)行技術(shù)評(píng)審以發(fā)現(xiàn)架構(gòu)設(shè)計(jì)問題;管理評(píng)審,通過組織級(jí)的質(zhì)量審計(jì)看產(chǎn)品以及實(shí)施過程是否滿足質(zhì)量要求;代碼走查,在編碼過程中加入至少一次的代碼走查,排查不符合規(guī)范或性能要求的代碼,走查通常能夠發(fā)現(xiàn)50%-70%的錯(cuò)誤;每日構(gòu)建,這是一種非常有效的方法,可以避免把各部分的集成問題拖到最后,并且能夠及時(shí)發(fā)現(xiàn)相應(yīng)的錯(cuò)誤,日構(gòu)建一般在項(xiàng)目的中后期開始,每天自動(dòng)從版本服務(wù)器上獲取源代碼進(jìn)行自動(dòng)編譯和測試。
4、人員技能和資源的不足
項(xiàng)目實(shí)施過程中由于人員技能欠缺造成的進(jìn)度延后和軟件質(zhì)量問題并不少見,一個(gè)熟練的技術(shù)人員完成同樣一個(gè)任務(wù)需要3天,但一個(gè)新手可能就需要7-10天。項(xiàng)目管理者應(yīng)該在前期就分析清楚項(xiàng)目所要采用的技術(shù)以及相應(yīng)的人員技能要求,針對(duì)不同的角色,及時(shí)采取相應(yīng)的技能培訓(xùn),以保證項(xiàng)目的順利實(shí)施。開發(fā)過程中遇到技術(shù)難題,導(dǎo)致開發(fā)時(shí)間延遲或者需求不得不發(fā)生變更。在項(xiàng)目開始前的技術(shù)評(píng)估階段,明確技術(shù)難點(diǎn),提前安排人員進(jìn)行攻克。如果在可預(yù)期的時(shí)間內(nèi)無法解決,如果可以,將向需求提出方要求變更需求或?qū)ふ铱商娲桨浮_@樣的風(fēng)險(xiǎn)應(yīng)該在項(xiàng)目的前期階段就應(yīng)該解決在萌芽狀態(tài)來避免這樣的風(fēng)險(xiǎn)在后期或中期出現(xiàn)。
5、缺乏良好的團(tuán)隊(duì)協(xié)作
軟件項(xiàng)目實(shí)施屬于知識(shí)型,要發(fā)揮團(tuán)隊(duì)成員的創(chuàng)造力,不同于制造業(yè)計(jì)件生產(chǎn),各模塊最終要集成在一起形成一個(gè)有機(jī)的整體,這就需要各小組之間的密切配合,界定清楚工作界面及接口關(guān)系,并在實(shí)施過程中持續(xù)地溝通交流和共享,首先團(tuán)隊(duì)要融為一體,產(chǎn)出的軟件才能融為一體。這是一個(gè)團(tuán)隊(duì)的軟實(shí)力,團(tuán)隊(duì)之間的協(xié)作好壞也將是個(gè)潛在的風(fēng)險(xiǎn)問題,在項(xiàng)目啟動(dòng)和團(tuán)隊(duì)組建的時(shí)候就應(yīng)該加以規(guī)避這樣的風(fēng)險(xiǎn)出現(xiàn)。
6、項(xiàng)目會(huì)議
組織會(huì)議是項(xiàng)目執(zhí)行過程中一項(xiàng)非常重要的工作任務(wù),項(xiàng)目過程中很多重要的決定都是在會(huì)議中做出的,不成功的會(huì)議會(huì)對(duì)項(xiàng)目本身造成了不好的影響。
不成功的會(huì)議通常表現(xiàn)為如下形式:
1、會(huì)議氛圍不好,參與者發(fā)言不踴躍;
2、會(huì)議討論常常偏離主題;
3、會(huì)議沒有取得預(yù)期的結(jié)果;
4、會(huì)議時(shí)間常常一拖再拖。
這些不成功的會(huì)議最終的結(jié)果就是:既浪費(fèi)了大家的寶貴時(shí)間又沒有達(dá)到會(huì)議的目的,很多人都對(duì)這樣的會(huì)議都有抵觸情緒,對(duì)此也是深惡痛絕。以下是組織會(huì)議時(shí)應(yīng)該注意的問題,也可看作組織會(huì)議的最佳實(shí)踐。在列出最佳實(shí)踐之前有三點(diǎn)我們必須要清楚:
1、會(huì)議是否會(huì)取得成功很大程度上取決于會(huì)議的組織者。只有組織得有力,會(huì)議才有可能取得成功,這是會(huì)議成功的充分條件。
2、會(huì)議的組織者和參與者的想法通常是不一致的,有時(shí)候甚至?xí)笙鄰酵ァK圆灰M麜?huì)議的參與者和你一樣,對(duì)會(huì)議有著如此的期待,對(duì)大多數(shù)參與者而言,在會(huì)議中他只是一個(gè)發(fā)表想法的人,他不用對(duì)會(huì)議的成功承擔(dān)責(zé)任。
3、以下十一條最佳實(shí)踐是形式上的約定,具體的實(shí)施可以根據(jù)實(shí)際情況來做。組織會(huì)議的十一條最佳實(shí)踐:
1、只有需要開會(huì)時(shí)才開會(huì)。有時(shí)候兩三個(gè)人單獨(dú)小范圍溝通會(huì)更加有效。
2、提前發(fā)出會(huì)議議程,以便會(huì)議參與者知道他們來做什么。
3、請(qǐng)對(duì)人很重要,不要把非必要的人召來開會(huì),當(dāng)然也不要漏掉那些關(guān)鍵人物。在確保必要人物都在的情況下一次會(huì)議參與者越少效果越好。
4、提前預(yù)約參與者的時(shí)間,以確保他們能按時(shí)到場。
5、會(huì)議的開場很重要。會(huì)議組織者要在開始前做好幾件事情。通常我建議有幾點(diǎn)要在開場時(shí)說: A、再一次強(qiáng)調(diào)會(huì)議的目標(biāo),我們來做什么。
B、強(qiáng)調(diào)會(huì)議的主題與基調(diào)。比如:本次會(huì)議是一個(gè)需求確認(rèn)會(huì),而非需求討論會(huì),主要是討論做還是不做以及告知大家我們要做什么,而不要把太多的精力放在討論如何做上面。
C、說明一下會(huì)議的規(guī)則。如要發(fā)言,請(qǐng)舉手;不要有小圈子討論;不要打斷別人的講話,等別人說完你再說等等。
6、會(huì)議過程中時(shí)刻注意引導(dǎo)和控制會(huì)議,以確保會(huì)議按照目標(biāo)進(jìn)行。一次會(huì)議的氛圍是否良好,討論是否充分,好的引導(dǎo)至關(guān)重要。比如多提一些開放式的問題。
7、會(huì)議記錄很重要,把一些結(jié)論和有價(jià)值的內(nèi)容記錄下來,這些是本次會(huì)議的重要成果之一。
8、會(huì)議要有結(jié)論。我們常在會(huì)議上聽到有人說:“大家討論了這么半天,結(jié)論呢?”。沒有結(jié)論的會(huì)議是沒有意義的。
9、會(huì)議后別忘發(fā)會(huì)議紀(jì)要,以及一些Action,什么人什么時(shí)候做什么。
10、會(huì)議后的action執(zhí)行情況的反饋很重要。反饋是對(duì)會(huì)議參與者的尊重,同時(shí)也告知了會(huì)議的效果。否則會(huì)讓大家感覺到這是一個(gè)可無可無的會(huì)議,大家以后參與的積極性也會(huì)降低。很多會(huì)議往往都不注意這一點(diǎn)。
11、按時(shí)結(jié)束的會(huì)議會(huì)受到所有人的歡迎。
第五篇:淺談軟件開發(fā)項(xiàng)目管理
淺談軟件開發(fā)項(xiàng)目管理
摘要:在軟件項(xiàng)目開發(fā)的過程中,軟件項(xiàng)目管理的成功與否是決定一個(gè)項(xiàng)目是否能夠順利高效率完成的重要保證。但是我國大部分的軟件企業(yè)在進(jìn)行項(xiàng)目管理時(shí)都存在著各種問題,從而使項(xiàng)目不能順利有效地完成。文章探討了在項(xiàng)目管理過程里出現(xiàn)的常見問題,并給出了相應(yīng)的解決策略。
關(guān)鍵詞:軟件項(xiàng)目管理;項(xiàng)目經(jīng)理;項(xiàng)目計(jì)劃
軟件行業(yè)在現(xiàn)在的眾多行業(yè)里是一個(gè)極具挑戰(zhàn)性和創(chuàng)造性的行業(yè),體現(xiàn)了軟件開發(fā)者的智慧和汗水,同時(shí)軟件開發(fā)是一項(xiàng)復(fù)雜的系統(tǒng)工程。牽涉到許多方面的因素,在實(shí)際工作中,經(jīng)常會(huì)出現(xiàn)各種各樣的問題,甚至?xí)媾R失敗。如何總結(jié)、分析失敗的原因。得出有益的教訓(xùn),對(duì)于項(xiàng)目開發(fā)人員來說,是在今后的項(xiàng)目中取得成功的關(guān)鍵。
一、軟件開發(fā)中實(shí)行項(xiàng)目管理的意義
項(xiàng)目管理就是在項(xiàng)目活動(dòng)中運(yùn)用一系列的知識(shí)、技能、工具和技術(shù),以滿足或超過相關(guān)利益者對(duì)項(xiàng)目的要求,實(shí)際上就是通過項(xiàng)目各方干系人的合作,把各種資源應(yīng)用于項(xiàng)目,以實(shí)現(xiàn)項(xiàng)目的目標(biāo),滿足項(xiàng)目干系人的需求,其本質(zhì)就是對(duì)時(shí)間、質(zhì)量和成本的管理。隨著軟件開發(fā)的深入、各種技術(shù)的不斷創(chuàng)新以及軟件產(chǎn)業(yè)的形成,人們越來越意識(shí)到軟件過程管理的重要性,管理學(xué)的思想逐漸融入軟件開發(fā)過程中,項(xiàng)目開發(fā)的管理日益受到重視。
二、目前在軟件項(xiàng)目管理中存在的誤區(qū)
現(xiàn)在大多數(shù)企業(yè)都認(rèn)識(shí)到了在項(xiàng)目中進(jìn)行管理的重要性,但是仍然有許多企業(yè)在實(shí)施項(xiàng)目管理的過程中存在著這樣那樣的誤區(qū),主要表現(xiàn)在:項(xiàng)目經(jīng)理不夠?qū)I(yè)。在軟件企業(yè)中,缺乏專業(yè)的項(xiàng)目管理人員來實(shí)施項(xiàng)目管理及擔(dān)任項(xiàng)目經(jīng)理,通常被任命的項(xiàng)目經(jīng)理主要是因?yàn)樗麄兡軌蛟诩夹g(shù)上獨(dú)當(dāng)一面,但是他們在管理方面特別是項(xiàng)目管理方面的知識(shí)比較缺乏。項(xiàng)目計(jì)劃缺乏綱領(lǐng)性。項(xiàng)目經(jīng)理對(duì)總體計(jì)劃、階段計(jì)劃的作用認(rèn)識(shí)不足,因此制定總體計(jì)劃時(shí)比較隨意,不少事情沒有仔細(xì)考慮:階段計(jì)劃因工作忙等理由經(jīng)常拖延,造成計(jì)劃與控制管理脫節(jié),無法進(jìn)行有效的進(jìn)度控制管理。缺乏有效的管理意識(shí)。部分項(xiàng)目經(jīng)理不能從總體上把握整個(gè)項(xiàng)目,而是埋頭于具體的技術(shù)工作,造成項(xiàng)目組成人員之間忙的忙、閑的閑,計(jì)劃不周、任務(wù)不均、資源浪費(fèi)。有些項(xiàng)目經(jīng)理沒有很好的管理方法,不好安排的工作只好自己做,使項(xiàng)目任務(wù)無法有效、合理地分配給相關(guān)成員,以達(dá)到“負(fù)載均衡”。缺乏有效的溝通制度和機(jī)制。在項(xiàng)目中一些重要信息沒有進(jìn)行充分和有效的溝通。在制定計(jì)劃、意見反饋、情況通報(bào)、技術(shù)問題或成果等方面與相關(guān)人員的溝通不足,造成各做各事、重復(fù)勞動(dòng),甚至造成不必要的損失:有些人沒有每天定時(shí)收郵件的習(xí)慣,以至于無法及時(shí)接收最新的信息。風(fēng)險(xiǎn)管理意識(shí)淡泊。有些項(xiàng)目經(jīng)理沒有充分意識(shí)到風(fēng)險(xiǎn)管理的重要性,對(duì)計(jì)劃書中風(fēng)險(xiǎn)管理的章節(jié)簡單應(yīng)付了事,隨便列出幾個(gè)風(fēng)險(xiǎn),隨便地寫一些簡單的對(duì)策,對(duì)于后面的風(fēng)險(xiǎn)防范起不到什么指導(dǎo)作用。項(xiàng)目干系人的不確定性。在范圍識(shí)別階段,項(xiàng)目組對(duì)客戶的整體組織結(jié)構(gòu)、有關(guān)人員及其關(guān)系、工作職責(zé)等沒有足夠了解以至于無法得到完整需求或最終經(jīng)權(quán)威用戶代表確認(rèn)的需求:或者是多個(gè)用戶代表各說各話、昨是今非,但同時(shí)又要求項(xiàng)目盡早交付:項(xiàng)目后期需求變化隨意,造成項(xiàng)目范圍的蔓延,進(jìn)度的拖延,成本的擴(kuò)大。缺乏項(xiàng)目團(tuán)隊(duì)的合理分工。項(xiàng)目團(tuán)隊(duì)內(nèi)部有時(shí)由于各階段不同角色或同階段不同角色之間的責(zé)任分工不夠清晰而造成工作互相推諉、責(zé)任互相推卸的現(xiàn)象;有時(shí)各階段不同角色或同階段不同角色之間的責(zé)任分工比較清晰,但是各項(xiàng)目成員只顧完成自己那部分任務(wù),不愿意與他人協(xié)作。這些現(xiàn)象都將造成項(xiàng)目組內(nèi)部資源的損耗,從而影響項(xiàng)目進(jìn)展。
三、解決軟件項(xiàng)目管理中存在的誤區(qū)的有效策略
要想解決上面描述的誤區(qū),歸根到底還是要從管理學(xué)的角度入手,即在軟件項(xiàng)目的開發(fā)過程中加入過程管理的內(nèi)容,這樣我們可以在軟件開發(fā)中對(duì)各個(gè)過程的質(zhì)量加以控制,從而達(dá)到保證軟件產(chǎn)品質(zhì)量的目的。為了有效提高管理水平,我們應(yīng)該努力做到:項(xiàng)目經(jīng)理接受系統(tǒng)的項(xiàng)目管理知識(shí)培訓(xùn)是非常必要的,有了專業(yè)領(lǐng)域的知識(shí)與實(shí)踐,再加上項(xiàng)目管理知識(shí)與實(shí)踐和一般管理的知識(shí)和經(jīng)驗(yàn)的有機(jī)結(jié)合,必能大大提高項(xiàng)目經(jīng)理的項(xiàng)目管理水平。計(jì)劃的制定需要在一定條件的限制和假設(shè)之下采用漸近明細(xì)的方式進(jìn)行不斷完善。提高項(xiàng)目經(jīng)理的計(jì)劃意識(shí),采用項(xiàng)目計(jì)劃制定相關(guān)知識(shí)、技術(shù)、工具,加強(qiáng)對(duì)開發(fā)計(jì)劃、階段計(jì)劃的有效性進(jìn)行事前事后的評(píng)估。加強(qiáng)項(xiàng)目管理方面的培訓(xùn),并通過對(duì)考核指標(biāo)的合理設(shè)定和宣傳引導(dǎo)項(xiàng)目經(jīng)理更好地做好項(xiàng)目管理工作。技術(shù)骨干在擔(dān)任項(xiàng)目經(jīng)理之前,最好能經(jīng)過系統(tǒng)的項(xiàng)目管理知識(shí),特別是其中的人力資源管理、溝通管理的學(xué)習(xí),并且在實(shí)際工作中不斷提高自己的管理素質(zhì),豐富項(xiàng)目管理經(jīng)驗(yàn),提高項(xiàng)目管理意識(shí)。制定有效的溝通制度和溝通機(jī)制,提高溝通意識(shí):采取多種溝通方式,提高溝通的有效性。通過制度規(guī)定對(duì)由于未及時(shí)收取郵件而造成損失的責(zé)任歸屬;對(duì)于特別重要的內(nèi)容要采用多種方式進(jìn)行有效溝通以確保傳達(dá)到位,例如:除發(fā)送郵件外還要電話提醒、回執(zhí)等,重要的內(nèi)容還要通過舉行各種會(huì)議進(jìn)行傳達(dá)。通過學(xué)習(xí)項(xiàng)目管理知識(shí)掌握風(fēng)險(xiǎn)識(shí)別、量化、對(duì)策研究、反應(yīng)控制的工具和方法,掌握項(xiàng)目風(fēng)險(xiǎn)管理所必備的知識(shí)。通過加強(qiáng)對(duì)項(xiàng)目規(guī)劃中風(fēng)險(xiǎn)管理計(jì)劃的審核提高項(xiàng)目組的風(fēng)險(xiǎn)管理意識(shí)。總結(jié)本行業(yè)項(xiàng)目中常見的風(fēng)險(xiǎn)及其對(duì)策作為風(fēng)險(xiǎn)管理計(jì)劃中必要的風(fēng)險(xiǎn)內(nèi)容,并切實(shí)評(píng)估相應(yīng)對(duì)策的有效性和可行性。項(xiàng)目的目的就是實(shí)現(xiàn)項(xiàng)目干系人的需求和愿望。項(xiàng)目干系人管理應(yīng)當(dāng)從項(xiàng)目的啟動(dòng)開始,項(xiàng)目經(jīng)理及其項(xiàng)目成員就要分清項(xiàng)目干系人包含哪些人和組織,通過溝通協(xié)調(diào)對(duì)他們施加影響,驅(qū)動(dòng)他們對(duì)項(xiàng)目的支持,調(diào)查并明確他們的需求和愿望,減小其對(duì)項(xiàng)目的阻力,以確保項(xiàng)目獲得成功。項(xiàng)目經(jīng)理應(yīng)當(dāng)對(duì)項(xiàng)目成員的責(zé)任進(jìn)行合理的分配并清楚地說明,同時(shí)應(yīng)強(qiáng)調(diào)不同分工、不同環(huán)節(jié)的成員應(yīng)當(dāng)相互協(xié)作,共同完善。
實(shí)施有效的項(xiàng)目管理絕非易事,對(duì)于軟件企業(yè)而言,這不是一個(gè)小的改變,而是一種變革,企業(yè)需要為此付出艱苦的努力,同時(shí),成熟有效的項(xiàng)目管理無疑將對(duì)企業(yè)起著至關(guān)重要的作用,項(xiàng)目管理的水平將是企業(yè)核心競爭力之一。