轉(zhuǎn)貼：研發(fā)軟件項目管理

申請免費(fèi)試用、咨詢電話：400-8352-114

小軟件項目開發(fā)的管理
創(chuàng)建成功的工程
成功項目管理的秘密
更好地領(lǐng)導(dǎo)一個項目的訣竅
參與變革,走向成功
CMM/TSP/PSP講義稿
開發(fā)流程中的可用性
軟件開發(fā)的管理和控制
如何組織軟件開發(fā)團(tuán)隊
軟件項目管理（CMM）經(jīng)驗談
實(shí)施CMM/TSP/PSP的建議
軟件開發(fā)質(zhì)量保證體系
技術(shù)討論指南
任務(wù)管理
項目管理軟件
質(zhì)量管理
團(tuán)隊管理
小軟件項目開發(fā)的管理
一個企業(yè)的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把別人的 經(jīng)驗生搬硬套到自己身上，可能會適得其反。同樣，管理一個軟件項目也一樣，大項目和小項目的方式不完全一樣。但從另一個角度來看，項目的大與小并沒有本質(zhì)的區(qū)別，很多方法是共通的。本文的目的是從作者的經(jīng)驗來談?wù)勑№椖块_發(fā)的管理。
一、小項目的特點(diǎn)
　大家知道，“軟件危機(jī)”的出現(xiàn)起源于一些大型項目的不斷延遲甚至失敗。小項目相比之下，具有以下特點(diǎn):
　1.項目功能相對較少
　2.開發(fā)人員較少
　3.開發(fā)周期較短
　　另外，在現(xiàn)實(shí)中，有很多小項目是由一些中小公司進(jìn)行開發(fā)的，這些公司往往人員流動性較大，這也是不容忽視的一個現(xiàn)實(shí).
二、小項目開發(fā)中常犯的錯誤 　　
　　小項目看起來比較簡單，比較容易成功，因而人們往往忽視了小項目的管理，其實(shí)這是一種誤解，從本人的經(jīng)驗看來，小項目開發(fā)中容易犯以下的一些錯誤:
　　1、開發(fā)之前沒有認(rèn)真地進(jìn)行項目可行性和工作量的估計?！　⊥捎陧椖枯^小，便很草率地制定一個開發(fā)日程表，沒有認(rèn)真地估計項目難度，結(jié)果實(shí)際完成時間與估計完成時間往往有較大差別。
　　2、沒有真正的設(shè)計過程
　　開發(fā)人員少，意味著不同人員的程序之間交互、接口相對少一些。開發(fā)周期短意味著往往是同樣的幾個人從頭到尾負(fù)責(zé)一個項目。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下最基本的數(shù)據(jù)結(jié)構(gòu)、函數(shù)接口便分頭去做自己的工作了，沒有一份較正式的文檔。
　　這種做法潛在的危險之一是有的人可能會對討論出的接口、結(jié)構(gòu)理解有偏差(應(yīng)該承認(rèn)人是會犯錯誤的)。一個誤解可能造成以后的返工。 　　另一個潛在的危險是由于討論時忽略了某些情況，等大家都按當(dāng)時的分工完成屬于自己的工作后，才發(fā)現(xiàn)各個模塊組合起來卻形不成一個完整的系統(tǒng)。其根源在于沒有一個負(fù)責(zé)協(xié)調(diào)的人員不斷監(jiān)控整個開發(fā)過程。
　　第三個潛在的危險是一旦有人中途退出開發(fā)隊伍，其他人加入時，新來的人難以理解 以前別人做好的代碼，索性自己從頭來。另外，沒有文檔的程序，日后維護(hù)和版本升級都比較困難。
　　3.不經(jīng)過單元測試而直接進(jìn)入系統(tǒng)測試
　　造成這一現(xiàn)象的原因是每個模塊相對比較簡單，但是為了測試一個模塊需要建立一些測試環(huán)境。例如，為了測試一個函數(shù)是否正確，應(yīng)該用一些測試數(shù)據(jù)去調(diào)用該函數(shù)，需要編寫一些測試數(shù)據(jù)。但很多開發(fā)人員嫌麻煩，覺得反正其他模塊也很快出來了，直接用真正的數(shù)據(jù)來運(yùn)行幾次就行了。
　　殊不知，一旦直接進(jìn)入系統(tǒng)測試，發(fā)現(xiàn)運(yùn)行結(jié)果不正確后需要一步步查找。由于模塊間的調(diào)用關(guān)系，可能查了很久才發(fā)現(xiàn)是某個模塊的問題。這種方法一來效率比較低，大量的時間用在了將一個錯誤定位在模塊上了。另外由于這種測試不完全，真正運(yùn)行系統(tǒng)，當(dāng) 調(diào)用某模塊時，可能大部分時候都是正常數(shù)據(jù)，極少出現(xiàn)邊界情況，可能某些邊界情況容易被忽視，很久之后才被發(fā)現(xiàn)。但是如果對每個模塊進(jìn)行單元測試時都進(jìn)行一下邊界測 試，就會很容易消除一些隱患。真可謂欲速則不達(dá)也。
三.合理的開發(fā)流程
　　合理的開發(fā)模式，一句話形容就是“麻雀雖小，五臟俱全”，即使是小型項目的開 發(fā)，仍然應(yīng)該遵循軟件開發(fā)的一般規(guī)律，必須的步驟不能省略。但是小項目有它自身的一些特點(diǎn)，實(shí)行起來可以相對靈活些。
　　以下我從幾個方面描述一下我認(rèn)為比較合理的模式.
1.需求獲取
　　在進(jìn)入正式開發(fā)之前，必須先從用戶處獲取準(zhǔn)確的需求。在這上面花費(fèi)相當(dāng)時間是很必要的。
　　軟件項目可以大致分為專用軟件和通用軟件兩大類。
　　對于專用軟件，例如給某單位開發(fā)一套該單位專用的系統(tǒng)，一般用戶對于軟件要完成哪些功能已經(jīng)有了一個比較清楚的輪廓，而且往往在開發(fā)合同中已經(jīng)大致地規(guī)定了。
　　但是，開發(fā)合同上規(guī)定的只是一個大概的框架，在進(jìn)入開發(fā)之前必須與用戶進(jìn)行比較具體的交流和討論，了解清楚用戶心目中的產(chǎn)品究竟是什么樣子。這個步驟如果沒有好好做，往往到了開發(fā)工作的后期才發(fā)現(xiàn)開發(fā)人員的理解和用戶的要求有一些誤解，那么必然造成時間上的浪費(fèi)。
　　對于通用軟件，在開發(fā)之前應(yīng)該做一定的市場調(diào)查工作，一方面是從經(jīng)濟(jì)效益考慮，調(diào)查產(chǎn)品的潛在市場有多大，另一方面是從技術(shù)的角度，必須了解清楚潛在用戶對軟件的各種技術(shù)上的要求，例如，用戶現(xiàn)有硬件配置如何，軟件配置如何，使用什么網(wǎng)絡(luò)，使用 什么數(shù)據(jù)庫等等，根據(jù)調(diào)查的統(tǒng)計結(jié)果決定即將開發(fā)的軟件的一些技術(shù)指標(biāo)。
　　為了比較好地與用戶進(jìn)行交流，使用一些工具是很有好處的。 　　為了討論用戶界面，可以用VB, delphi等做一個原型，根據(jù)原型有針對性地與用戶討論需求。(原型開發(fā)不僅僅可以用于準(zhǔn)確獲取用戶的需求，開發(fā)出來的原型本身可以作為下一步開發(fā)的基礎(chǔ)，增量式地完成開發(fā))
　　為了討論軟件運(yùn)行的流程，可以采用UML的Use Case圖。
2.需求分析
　　在了解用戶的需求之后，將需求用一種模型來表示，就是需求分析，目前比較流行的 分析方法是面向?qū)ο蟮姆椒?，通過分析用戶需求，用類、類之間的各種關(guān)系來表示整個系統(tǒng)。
　　這部分涉及到具體的方法，在此不詳細(xì)討論，但是原則上是提取類->類之間關(guān)系,可能需要不斷修改而形成一份分析文檔。
　　我想強(qiáng)調(diào)幾個問題。
　　一是要分清問題域與系統(tǒng)責(zé)任。系統(tǒng)責(zé)任是指所要開發(fā)的軟件應(yīng)該完成的功能，而問題域是包含所有相關(guān)的部分。例如你要開發(fā)一個程控機(jī)計費(fèi)程序，程控機(jī)已經(jīng)是現(xiàn)成，輸出的數(shù)據(jù)格式也已經(jīng)是固定的，你的程序僅僅需要從程控機(jī)中讀取相應(yīng)的信息，那么，程控機(jī)在你的系統(tǒng)里只是一個外部的東西，把它作為一個類也許就是不必要的，僅僅需要一個類來完成讀數(shù)據(jù)的操作。又如，你需要在一個已經(jīng)存在的數(shù)據(jù)庫上開發(fā)一些應(yīng)用，數(shù)據(jù)庫的格式已經(jīng)固定，并且已經(jīng)有一個后臺程序在運(yùn)行，你需要開發(fā)一個新的前臺程序，這時，服務(wù)器程序?qū)δ銇碚f就是一個外部的東西。但是，象這種外部的內(nèi)容必須在分析文檔中有一些說明，作為系統(tǒng)的外在約束。 　　二是需求獲取與需求分析的關(guān)系。
　　用什么方法來完成需求的獲取，在很大程度上影響了需求分析的做法。
　　例如當(dāng)初采用Use Case來表示用戶需求，那么從各種序列圖中選出相互交互的各個實(shí)體，就是一個個類。
　　三是分析與設(shè)計過程的銜接。
　　分析過程的內(nèi)容是用類的結(jié)構(gòu)來表示目標(biāo)系統(tǒng)，并不設(shè)計具體實(shí)現(xiàn)，如采用什么編程 語言，在什么操作系統(tǒng)平臺上運(yùn)行等等。這些具體實(shí)現(xiàn)是在設(shè)計階段來完成的。面向?qū)ο蠓椒ǖ膬?yōu)點(diǎn)是分析、設(shè)計、編碼過程表示法統(tǒng)一，能比較好的銜接。但是，是把分析和設(shè) 計階段分開，采用瀑布式開發(fā)，還是采用其他方式，要看具體的情況。
　　對于需求潛在變化不大的項目，可以采用瀑布模型，有一個很明顯的設(shè)計階段，這樣做的好處是有一份比較完整的分析文檔，這樣以后如果需要采用不同的編程語言、或者采 用其他的平臺時，便可以以這份分析文檔作為開發(fā)的基礎(chǔ)。
　　對于需求變化頻繁的項目，可能采用少量分析;少量設(shè)計少量編碼測試的方式更合適，而且隨時可能要返回到前面某個一階段去進(jìn)行修改。但是這意味著可能沒有一份完整的分析文檔。
　　現(xiàn)在很多CASE工具并不區(qū)分分析和設(shè)計的階段。但是，這并不意味著開發(fā)就可以對分析和設(shè)計不加區(qū)分，CASE工具如同一支筆，如何用好還得還人。
3.設(shè)計過程
　　設(shè)計階段的工作包括:
　　對分析模型必要的修改?？赡苄枰獙δ承╊惤Y(jié)構(gòu)進(jìn)行一些修改，這些修改的原因可能是編程環(huán)境的要求，或者為了重用以前的某些工作。
　　定義界面部分、數(shù)據(jù)訪問(數(shù)據(jù)庫)部分。
　　由于目前很多編程語言都可以可視化地設(shè)計界面，所以界面部分工作往往留到了編碼階段來完成。于是設(shè)計階段的工作量并不大。
4.編碼
　　進(jìn)入編碼工作之后，可能會發(fā)現(xiàn)前面分析或設(shè)計階段的某些錯誤，這時應(yīng)返回到前面的階段進(jìn)行必要的修改。
5.測試
　　如前所述，即使是小項目，也應(yīng)該嚴(yán)格地進(jìn)行測試。
四、人員的安排
　　比較小的項目，往往是幾個人來完成，這幾個人基本上從頭到尾參加開發(fā)。在這幾個人中，有一位項目負(fù)責(zé)人，負(fù)責(zé)分析、設(shè)計和協(xié)調(diào)的工作。由于項目小，項目負(fù)責(zé)人也要參加編程,那么這人必須把時間合理運(yùn)用，
　　經(jīng)驗告訴我?guī)讞l原則:
　　1.協(xié)調(diào)幾個人的工作比自己完成一段編碼更重要.
　　由于協(xié)調(diào)上出了漏洞，可能導(dǎo)致很大的問題，所以項目負(fù)責(zé)人必須隨時監(jiān)控各開發(fā)人員的工作，包括內(nèi)容是否與要求發(fā)生偏差，進(jìn)度是否滯后等等。
　　只有在完成這些工作之后，項目負(fù)責(zé)人剩下的時間才能用于編程。 　　2.給每個開發(fā)人員明確的任務(wù)書.
　　不管是用面向?qū)ο蠡蛘咂渌椒ㄩ_發(fā)，分析、設(shè)計模型只是從功能的角度來描述系 統(tǒng)。但是，具體開發(fā)時每個開發(fā)人員必須非常明確自己的任務(wù)，這些任務(wù)應(yīng)該采用明確的文檔來表示。
　　3.讓大家都大致熟悉設(shè)計模型.
　　讓每個開發(fā)人員都清楚自己所做的工作在整個系統(tǒng)中處于什么地位，有時侯可能會發(fā)現(xiàn)設(shè)計模型中的漏洞，避免了各人的代碼編寫完畢之后又要修改的后果。



________________________________________

主頁 論壇 留言 打印 聯(lián)系






　
創(chuàng)建成功的工程


作者：Bruce Eckel，翻譯：UMLChina.Hairui

　

Bruce Eckel，著名的計算機(jī)語言和工程專家，著有《C++編程思想》（Thinking in C++）、《Java 編程思想》（Thinking in Java）等書籍 相關(guān)網(wǎng)站：http://www.bruceeckel.com --譯者注

以下工程開發(fā)指導(dǎo)是我對決定一項使用任何語言的軟件工程成功與否的決定因素的一些認(rèn)識。

1．記住往往事與愿違

純粹的“軼事工程”（原文為：anecdotal project，其含義不好理解，暫譯為"軼事工程"，盼指正--譯者）的失敗幾率總是存在，一些低至百分之五十而另一些高達(dá)百分之八十，但是所有的這些都表明：你失敗的機(jī)會大于你成功的機(jī)會。為什么我要從這個令人喪氣的預(yù)測開始我的話題呢？因為每一天開始時，我都想“今天將會不同，我今天能夠完成四倍數(shù)量的事情”，盡管（在此之前）有過一系列不間斷的例外。對于軟件工程來說，過度的狂熱往往被那些（只）關(guān)心結(jié)果人所夸大——“這一次，我們將解決以前從來沒有人解決過的問題，只需付出更少的時間和更小的代價”，盡管他們知道，真正的規(guī)則是：“你只能從此三者中選擇一個”。

記住你身后高高堆積的紙牌[i]非常重要。你手中有一根包含時代力量的魔術(shù)手杖或者是掛在懸崖上，會讓你做出完全不同的兩個決定。如果你懂得你的處境屬于后者，你將會說：“是的，這很好。但首先讓我們看看我們是否能夠在現(xiàn)有的進(jìn)度和預(yù)算情況下完成這一切?！?

一個將不穩(wěn)定形勢和對失敗的認(rèn)識放到顯著位置的方法是研究過去的失敗。一份很好的資料是Roberts Glass（一位愛好研究崩潰的專家）的著作：《軟件失控》(Software Runaways,出版信息：Prentice Hall 1998)，以及他其它的著作。此外可以閱讀Tom Demarco和Tim Lister的經(jīng)典之作《人件——生產(chǎn)性工程和團(tuán)隊》 (Peopleware: Productive Projects and Team,出版信息：第二版，Dorset House,1999)。



2．切合實(shí)際地安排時間

時間安排的“魔法”經(jīng)常受到非開發(fā)人員為滿足軟件開發(fā)實(shí)踐之外的愿望和期待而產(chǎn)生的想法所驅(qū)使。最近我校正了自己的時間安排策略。我先將整個工程顯示腦海中，然后閉上眼睛，清理自己的大腦并讓它判斷這個工程大概需要多少時間。如果不考慮奇怪的技術(shù)問題、各種會議和其他分心的事物的影響，得出的這個時間居然非常合理。但我建議將這個合理的時間乘以3，或許可能是4，并且加上百分之十。如果這個估計出來的時間將讓你失去市場機(jī)遇，那么考慮不要進(jìn)行這個工程。如果你認(rèn)為像這樣計劃時間不合理，那么首先請注意，大多數(shù)工程將遵循這個規(guī)律。其次，試想一下，如果你所在公司的所有工程都很成功進(jìn)行會帶來局面：你將擁有更多的收入；更少的程序員會因為愚昧的工程時間安排筋疲力盡而退出。

你也許還會爭論說這個時間評估技術(shù)非常沒有科學(xué)性，這一點(diǎn)我同意。然而，所有的軟件評估技術(shù)都含有臆測和直覺的成分在內(nèi)，甚至連功能點(diǎn)（原文為：function point，若有其他正規(guī)譯法，請指正）分析都需要對功能點(diǎn)進(jìn)行猜測。我的“信封背面”技術(shù)將所有臆測結(jié)合到了一起，而不試圖假裝沒有猜測。用更少的時間，也許產(chǎn)生更好的結(jié)果。但是，我的猜測是建立在我自己的經(jīng)驗之上的。



3．首先讓它運(yùn)作起來

當(dāng)我試圖進(jìn)行一些無意義的事情時，我最大的創(chuàng)造性成功來臨了。銘記最重要技巧——當(dāng)你開始一個工程時，你好比已經(jīng)用手指將自己掛在一個懸崖之上；然后你考慮一下能夠做什么瘋狂的事情簡單地讓你的工程運(yùn)作起來。這并不意味著你需要馬上投入進(jìn)去并用通常的方式開始撰寫代碼，你只需要盡早盡快找到一個轉(zhuǎn)換周期非常短的工具，用來判斷你是否可以做該項工作以及你的工程可行性如何。我在后面將要提到的Python語言就是這樣一種工具。

將你的計劃運(yùn)作起來有很多好處。憑你的經(jīng)驗，你應(yīng)該知道，用戶只有能夠開始使用你開發(fā)的東西的時候才能理解你開發(fā)的是什么，然后他們會突然產(chǎn)生各種念頭并對該軟件應(yīng)該做些什么真正提出要求。一份系統(tǒng)說明書往往只是一份文檔，人們往往不會認(rèn)真地閱讀，但是如果你讓他們體驗一個可運(yùn)行的程序之后，他們就會確切地明白你的意思。更早地了解用戶們真正想要什么豈不是更好？

事情往往會比你想象出來的要復(fù)雜四倍以上，所以對你能夠完成的東西要盡可能地保守一些。無論何時，一些不可知的因素都在伴隨著你的工作（這一點(diǎn)你可以從產(chǎn)品描述中一些“最”中察覺到：“最快”、“最大”、“最新”），原型的價值不能進(jìn)行夸大。如果在此之前你沒有做過類似的工程，那么最重要的事情是盡快地判明該工程是否可以實(shí)現(xiàn)，開發(fā)一個根本不能發(fā)揮作用的程序?qū)岳速M(fèi)你的大量金錢而收場。

最后一點(diǎn)，優(yōu)化。要能夠在這個階段抵抗得了誘惑。牢記Donald Knuth說過的話（其中略有一點(diǎn)開玩笑的意思）：“不成熟的優(yōu)化是所有麻煩的根源”。雖然優(yōu)化是一些工程的關(guān)鍵因素，但是在確認(rèn)程序切實(shí)可行之前一切優(yōu)化都是盲目的。在最后建造系統(tǒng)之前瀏覽一遍所有的問題。每個工程都有一些你沒有接觸過的東西，你應(yīng)該首先將注意力放到這個領(lǐng)域，創(chuàng)建一個測試程序或者原型來尋找解決問題的方法。在你知道你是否可以做到并且知道做到的難度有多大之前，你沒有其他辦法能夠得知工程是否能夠成功、如何為它安排時間以及它需要多少付出等等。



4．使用恰當(dāng)?shù)墓ぞ?

一個工程的早期部分應(yīng)該是高度探索性和實(shí)驗性的，因為那個階段是發(fā)現(xiàn)自己不會做什么以及如何去建造程序的階段。尋找最適合工具的最好方法是去體驗一下他們，然后擯棄其中工作效率低下的那些。例如，你可能開始的時候用的是Rational Rose，后來決定使用Visio Professional來創(chuàng)建視圖，因為你需要Visio（或者通過Versa）提供的一些特性。

用來做工程的恰當(dāng)工具并不一定就必須是你已經(jīng)了解的編程語言。當(dāng)使用一種語言時，你就被局限在該語言所能表示的范圍之中了。如果你是一個C++程序員，你很自然可能想用C++創(chuàng)建所有的工程管理和工具。但當(dāng)你需要更加靈活的工具時，Perl是一種更快速的選擇（甚至將考慮學(xué)習(xí)需要的時間在內(nèi)）。在你的實(shí)際工程開發(fā)中，使用Python來快速造型或者甚至交付一個內(nèi)嵌Python語言的應(yīng)用程序?qū)⒔o你帶來更好的局面。首先，它是免費(fèi)的，所以不需要支付任何許可授權(quán)費(fèi)用；同時它對C 和Java有完全兼容的接口，你可以使用Python解決所有Perl能夠解決的問題，所以它是C++和Java的一種完美的輔助語言。



5．接口的設(shè)計

在C++中，接口是一個包含所有虛函數(shù)的類；而在Java中接口技術(shù)被直接支持；在COM和COBRA中，你沒有其他選擇，你和所有的抽象打交道——所有的都是接口，沒有實(shí)現(xiàn)。接口提供了一個更加整潔的設(shè)計方式。要想讓程序員們確信這一點(diǎn)有些困難，但是它對將COM或者COBRA指定為構(gòu)件模型非常有幫助的（COBRA技術(shù)也是與操作系統(tǒng)無關(guān)的技術(shù)）。它不僅僅提供了工程實(shí)現(xiàn)語言的靈活性，并讓你能夠完全地將工程切割開來。如果你打算在你的開發(fā)組或者公司之外實(shí)現(xiàn)你的工程的一部分，整潔的接口可以阻止任何與工程其它部分不適當(dāng)?shù)倪B接，同時你可以用任何語言來進(jìn)行開發(fā)。你可以采取快速造型來實(shí)現(xiàn)所有的接口，稍后才對其中比較特別的部分進(jìn)行優(yōu)化。



6．設(shè)計時充分考慮異常情況

在C++中，異?？刂撇⒉幌裨贘ava中那樣得到有力支持——這是Java在工程管理方面成功之處。在設(shè)計、代碼編寫和模塊使用的時候往往會有一些錯誤，除非軟件自身能夠通過拋出一個異常來聲明這些錯誤，否則你將會花費(fèi)許多小時或月的時間來捕獲這些問題。只有通過嚴(yán)謹(jǐn)?shù)漠惓Ｊ褂?，你才能保證這些問題不會出其不意地讓你的工程陷入困境。



7．簡潔往往付出代價

雖然很難說服管理部門，但是“簡潔”這個詞是可維護(hù)性和復(fù)用性的同義詞。不僅如此，一個簡潔的程序讓人感覺很好。但是因為我們確信軟件工程是一種商業(yè)行為，目的是為了賺錢，而不是為了感覺，因此很難說簡潔的程序比其他非簡潔的程序更加有靈氣地結(jié)合在一起。但是由于軟件是一種能夠賺錢的藝術(shù)實(shí)體，在美學(xué)和實(shí)用性之間必然會一場爭論。



8．人與人之間的交流是一個瓶頸

這就是為什么小型的組隊往往更加有生產(chǎn)力的原因。當(dāng)一個工程像火焰一樣失去控制的時候，將更多的程序員扔進(jìn)火焰將使情況變得更糟。這也是為什么簡短的小會議往往可以發(fā)揮作用而冗長的大型會議卻做不到，還有為什么太深的管理機(jī)制會導(dǎo)致生疏的原因。參閱《人件》（早些時候提及過）一書了解更多的細(xì)節(jié)。

解決交流問題的最好辦法是免費(fèi)的：在一臺廢棄的計算機(jī)上安裝一個Linux服務(wù)器，你可以在幾分鐘內(nèi)完成這項工作，自動安裝將包括一個Apache網(wǎng)頁服務(wù)器。然后將你們所有的文檔，從測試分析到用戶文檔，拷貝到服務(wù)器上，以便每個人都能夠訪問到最新的信息。你可以輕松地加入Java Servlets或者Perl腳本（http://www.perl.com/）或者Python(http://www.python.org/)來收集每一頁的內(nèi)容，然后用一個List服務(wù)器來向所有的成員發(fā)送公告。如果你想用camera-ready格式來提供文檔，你可以用Adobe Acrobat格式來代替HTML格式。如果你的工程足夠大的話，指定一名成員專門負(fù)責(zé)維護(hù)服務(wù)器是值得的。



9．制定一份計劃（可以是任何類型的）

我曾經(jīng)見過許多工程在沒有簽訂任何合同（更別說一份計劃）時已經(jīng)有大量資金流動。哪怕是對于一個很小的工程，你也需要某種計劃，甚至它可能只是被寫在一個信封的背面或者只存在于主程序員的腦海中。當(dāng)工程逐漸變大，你需要一個回顧的過程。一個典型的計劃包括：分析階段（包括你打算用程序解決什么問題以及程序?qū)⑼瓿墒裁矗?、設(shè)計階段（程序如何完成它的任務(wù)、程序?qū)崿F(xiàn)的組成、分析階段預(yù)定目標(biāo)是否達(dá)到的測試使用信息以及發(fā)布、安裝和培訓(xùn)等事項）。當(dāng)新的信息被收集時，這些階段將被重復(fù)。根據(jù)工程的大小，這些步驟將被縮小或者放大，但你必須像熟悉你的編程語言一樣熟悉它們。



10．考慮外部幫助

一種放棄：我的公司提供培訓(xùn)和咨詢服務(wù)，因此當(dāng)然我感覺這是一個好主意。然而，如果你的公司內(nèi)部有經(jīng)驗豐富的人可以擔(dān)任你的工程的顧問，你可以不必向公司之外尋求幫助。這是一種以知識為基礎(chǔ)的商業(yè)行為，生產(chǎn)力最低和最高的軟件工人之間的生產(chǎn)力差別是很大的。如果你無法雇用那些最有生產(chǎn)力的工人，你可以通過培訓(xùn)提高他們的生產(chǎn)力，通過咨詢和代碼預(yù)排來改進(jìn)你的工程的分析、設(shè)計和實(shí)現(xiàn)。對于顧問和客戶來說，有一本優(yōu)秀的書籍是Weinberg的《咨詢的秘密》（出版信息：Dorset House,1986）

另一方面，我曾經(jīng)見過一些工程中，使用外部的開發(fā)組隊剝奪了內(nèi)部的隊伍的權(quán)利，該項目最后以花費(fèi)更多的時間和資金收場。這將我們帶到我的最后一個提示:



11.了解永遠(yuǎn)沒有銀彈（原文為：silver bullets,此處直譯為銀彈，估計引申含義和free lunch接近）的道理

這句諺語是由Fred Brooks發(fā)明的，對于今天仍然適用——盡管有許多“銀彈”已經(jīng)被發(fā)明出來了。統(tǒng)一建模語言（UML）就是這樣一個例子：它當(dāng)然是一個很好的通用詞匯表和設(shè)計符號集，但是UML僅僅輕微地減少了方法學(xué)家之間的爭論而已。永遠(yuǎn)不會有不勞而獲的事情。你必須艱辛地計劃你的對象、它們的接口和結(jié)構(gòu)，然后跨越一道道障礙將工程變成成果。你必須清楚沒有任何可以保證成功的方案可以依賴，同時牢記工程的失敗的幾率讓自己更好的瞄準(zhǔn)成功。



________________________________________

主頁 論壇 留言 打印 聯(lián)系






　
成功項目管理的秘密
摘自SDMagazine，Karl Wiegers著，UMLChina.Shids譯



在最好的情況下，管理軟件項目也是很困難的。不幸的是，許多新項目經(jīng)理實(shí)質(zhì)上沒有受到任何就職培訓(xùn)。這里有20個成功的管理經(jīng)驗供項目經(jīng)理參考。



1. 定義項目成功的標(biāo)準(zhǔn)

在項目的開始，要保證風(fēng)險承擔(dān)者對于他們?nèi)绾闻袛囗椖渴欠癯晒τ薪y(tǒng)一的認(rèn)識。經(jīng)常，滿足一個預(yù)定義的進(jìn)度安排是唯一明顯的成功因素，但是肯定還有其他的因素存在，比如：增加市場占有率，獲得指定的銷售量或銷售額，取得特定用戶滿意程度，淘汰一個高維護(hù)需求的遺留系統(tǒng)，取得一個特定的事務(wù)處理量并保證正確性。



2. 識別項目的驅(qū)動、約束和自由程度

每個項目都需要平衡它的功能性，人員，預(yù)算，進(jìn)度和質(zhì)量目標(biāo)。我們把以上五個項目方面中的每一個方面，要么定義成一個約束，你必須在這個約束中進(jìn)行操作，要么定義成與項目成功對應(yīng)的驅(qū)動，或者定義成通向成功的自由程度，你可以在一個規(guī)定的范圍內(nèi)調(diào)整。相關(guān)的詳細(xì)信息，請參照我的《創(chuàng)建一種軟件工程文化》（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。



3. 定義產(chǎn)品發(fā)布標(biāo)準(zhǔn)

在項目早期，要決定用什么標(biāo)準(zhǔn)來確定產(chǎn)品是否準(zhǔn)備好發(fā)布了。你可以把發(fā)布標(biāo)準(zhǔn)基于：還存在有多少個高優(yōu)先級的缺陷，性能度量，特定功能完全可操作，或其他方面表明項目已經(jīng)達(dá)到了它的目的。不管你選擇了什么標(biāo)準(zhǔn)，都應(yīng)該是可實(shí)現(xiàn)的、可測量的、文檔化的，并且與你的客戶指的“質(zhì)量”一致。



4. 溝通承諾

盡管有承諾不可能事件的壓力，從不作一個你知道你不能保證的承諾。和客戶和管理人員溝通哪些可以實(shí)際取得時，要有好的信譽(yù)。你的任何以前項目的數(shù)據(jù)會幫助你作說服的論據(jù)，雖然這對于不講道理的人來說沒有任何真正的防御作用。



5. 寫一個計劃

有些人認(rèn)為，花時間寫計劃還不如花時間寫代碼，但是我不這么認(rèn)為。困難的部分不是寫計劃。困難的部分是作這個計劃--思考，溝通，權(quán)衡，交流，提問并且傾聽。你用來分析解決問題需要花費(fèi)的時間，會減少項目以后會帶給你的意外。



6. 把任務(wù)分解成英寸大小的小圓石

英寸大小的小圓石是縮小了的里程碑。把大任務(wù)分解成多個小任務(wù)，幫助你更加精確的估計它們，暴露出在其他情況下你可能沒有想到的工作活動，并且保證更加精確、細(xì)密的狀態(tài)跟蹤。



7. 為通用的大任務(wù)開發(fā)計劃工作表

如果你的組經(jīng)常承擔(dān)某種特定的通用任務(wù)，如實(shí)現(xiàn)一個新的對象類，你需要為這些任務(wù)開發(fā)一個活動檢查列表和計劃工作表。每個檢查列表應(yīng)該包括這個大任務(wù)可能需要的所有步驟。這些檢查列表和工作表將幫助小組成員確定和評估與他/她必須處理的大任務(wù)的每個實(shí)例相關(guān)的工作量。



8. 計劃中，在質(zhì)量控制活動后應(yīng)該有修改工作

幾乎所有的質(zhì)量控制活動，如測試和技術(shù)評審，都會發(fā)現(xiàn)缺陷或其他提高的可能。你的項目進(jìn)度或工作細(xì)分結(jié)構(gòu)，應(yīng)該把每次質(zhì)量控制活動后的修改，作為一個單獨(dú)的任務(wù)包括進(jìn)去。如果你事實(shí)上不用作任何的修改，很好，你已經(jīng)走在了本任務(wù)的計劃前面。但是不要去指望它。



9. 為過程改進(jìn)安排時間

你的小組成員已經(jīng)淹沒在他們當(dāng)前的項目中，但是如果你想把你的組提升到一個更高的軟件工程能力水平，你就必須投資一些時間在過程改進(jìn)上。從你的項目進(jìn)度中留出一些時間，因為軟件項目活動應(yīng)該包括做能夠幫助你下一個項目更加成功的過程改進(jìn)。不要把你項目成員可以利用的時間100％的投入到項目任務(wù)中，然后驚訝于為什么他們在主動提高方面沒有任何進(jìn)展。



10. 管理項目的風(fēng)險

如果你不去識別和控制風(fēng)險，那么它們會控制你。在項目計劃時花一些時間集體討論可能的風(fēng)險因素，評估它們的潛在危害，并且決定你如何減輕或預(yù)防它們。要一個軟件風(fēng)險管理的簡要的指南，參見我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。



11. 根據(jù)工作計劃而不是日歷來作估計

人們通常以日歷時間作估計，但是我傾向于估計與任務(wù)相關(guān)聯(lián)的工作計劃（以人時為單位）的數(shù)量，然后把工作計劃轉(zhuǎn)換為日歷時間的估計。這個轉(zhuǎn)換基于每天我有多少有效的小時花費(fèi)在項目任務(wù)上，我可能碰到的任何打斷或突發(fā)調(diào)整請求，會議，和所有其他會讓時間消失的地方。



12. 不要為人員安排超過他們80％的時間

跟蹤你的組員每周實(shí)際花費(fèi)在項目指定工作的平均小時數(shù)，實(shí)在會讓人吃驚。與我們被要求做的許多活動相關(guān)的任務(wù)切換的開銷，顯著地降低了我們的工作效率。不要只是因為有人在一項特定工作上每周花費(fèi)10小時，就去假設(shè)他或她可以馬上做4個這種任務(wù)，如果他或她能夠處理完3個任務(wù)，你就很幸運(yùn)了。



13. 將培訓(xùn)時間放到計劃中

確定你的組員每年在培訓(xùn)上花費(fèi)多少時間，并把它從組員工作在指定項目任務(wù)上的可用時間中減去。你可能在平均值中早已經(jīng)減去了休假時間、生病時間和其他的時間，對于培訓(xùn)時間也要同樣的處理。



14. 記錄你的估算和你是如何達(dá)到估算的

當(dāng)你準(zhǔn)備估算你的工作時，把它們記錄下來，并且記錄你是如何完成每個任務(wù)的。理解創(chuàng)建估算所用的假設(shè)和方法，能夠使它們在必要的時候更容易防護(hù)和調(diào)整，而且它將幫助你改善你的估算過程。



15. 記錄估算并且使用估算工具

有很多商業(yè)工具可以幫助你估算整個項目。根據(jù)它們真實(shí)項目經(jīng)驗的巨大數(shù)據(jù)庫，這些工具可以給你一個可能的進(jìn)度和人員分配安排選擇。它們同樣能夠幫助你避免進(jìn)入“不可能區(qū)域”，即產(chǎn)品大小，小組大小和進(jìn)度安排組合起來沒有已知項目成功的情況。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一試的好工具。



16. 遵守學(xué)習(xí)曲線

如果你在項目中第一次嘗試新的過程，工具或技術(shù)，你必須認(rèn)可付出短期內(nèi)生產(chǎn)力降低的代價。不要期望在新軟件工程方法的第一次嘗試中就獲得驚人的效益，在進(jìn)度安排中考慮不可避免的學(xué)習(xí)曲線。



17. 考慮意外緩沖

事情不會象你項目計劃的一樣準(zhǔn)確的進(jìn)行，所以你的預(yù)算和進(jìn)度安排應(yīng)該在主要階段后面包括一些意外的緩沖，以適應(yīng)無法預(yù)料的事件。不幸的是，你的管理者或客戶可能把這些緩沖作為填料，而不是明智的承認(rèn)事實(shí)確實(shí)如此。指明一些以前項目不愉快的意外，來說明你的深謀遠(yuǎn)慮。



18. 記錄實(shí)際情況與估算情況

如果你不記錄花費(fèi)在每項任務(wù)上的實(shí)際工作時間，并和你的估算作比較，你將永遠(yuǎn)不能提高你的估算能力。你的估算將永遠(yuǎn)是猜測。



19. 只有當(dāng)任務(wù)100%完成時，才認(rèn)為該任務(wù)完成

使用英寸大小的小圓石的一個好處是，你可以區(qū)分每個小任務(wù)要么完成了，要么沒有完成，這比估計一個大任務(wù)在某個時候完成了多少百分比要實(shí)在的多。不要讓人們只入不舍他們?nèi)蝿?wù)的完成狀態(tài)；使用明確的標(biāo)準(zhǔn)來判斷一個步驟是否真正的完成了。



20. 公開、公正地跟蹤項目狀態(tài)

創(chuàng)建一個良好的風(fēng)氣，讓項目成員對準(zhǔn)確地報告項目的狀態(tài)感到安全。努力讓項目在準(zhǔn)確的、基于數(shù)據(jù)的事實(shí)基礎(chǔ)上運(yùn)行，而不是從因為害怕報告壞消息而產(chǎn)生的令人誤解的樂觀主義。使用項目狀態(tài)信息在必要的時候進(jìn)行糾正操作，并且在條件允許時進(jìn)行表揚(yáng)。



這些提示不能保證你的成功，但是它們將幫助你在你的項目上獲得一個堅實(shí)的把手，并且保證你做了所有你可以做的事來讓項目在這個瘋狂的世界上成功。

原文鏈接：http://www.processimpact.com/articles/proj_mgmt_tips.html



________________________________________

主頁 論壇 留言 打印 聯(lián)系






　
更好地領(lǐng)導(dǎo)一個項目的訣竅


----Warren Keuffel

自：SD Magazine，Sep,1999. UMLChina.Think譯

----------------------------------------------------------------------------

　技術(shù)管理就像開車。當(dāng)你做得正確時，沒有人注意，一旦某個環(huán)節(jié)出錯，問題會接踵而來。以下是我11年來作為Interviewing Manager的Team管理體會，排名不分先后，你必須注意每一點(diǎn)。

1. 不要重復(fù)過去二三十年來別人犯過的錯誤

　這句話來自Steve Mcconnell，IEEE軟件編輯和軟件開發(fā)暢銷書作家。Mcconnell的作品包括經(jīng)典著作“Code Complete”。Mcconnell認(rèn)為，“大量閱讀”是避免凡重復(fù)錯誤的最好方法。

2. 80%的管理就是選擇正確的人選

　Scott Adams, Dilbert漫畫的作者認(rèn)為一個好的項目經(jīng)理必須創(chuàng)造一個人盡其用的環(huán)境。所有的項目經(jīng)理都應(yīng)該讀一讀Tom Demarco和Tim Lister的新書“Peopleware：Productive Projects and Teams”（2nd Edition, Dorset House, 1999）。

3. 總是試圖雇用比你強(qiáng)的人

　不要讓你的自負(fù)成為項目的瓶頸。組織一支聰明的隊伍，給他們足夠的資源和解決問題的規(guī)則，讓員工自己解決問題。

4. 不要浪費(fèi)時間

　Tom Bragg，Intellisys Technology Corp.的首席技術(shù)官員，認(rèn)為太多的項目由于不能如期開始最后陷入麻煩。通常導(dǎo)致延遲的原因包括其它任務(wù)的干擾，人事變動，不準(zhǔn)時的經(jīng)理等等。

5. 最優(yōu)的未必是最大的

　Tom Bragg的另一個建議是：密切注意項目開始后發(fā)生的事情。Bragg說：“計劃好你的工作然后如期進(jìn)行，過分緊張的工作強(qiáng)度反而往往導(dǎo)致生產(chǎn)率的降低，可能保持每周50小時以內(nèi)的工作強(qiáng)度是最佳的。

6. 真實(shí)的，公正的估計

　項目經(jīng)理應(yīng)該避免“依照管理者的欲望修改計劃”的陷阱?！耙粋€有效的估計的特征是所估計的時間與金錢比實(shí)際情況低和高的概率相等”，Bragg說。

7. 使你的組織結(jié)構(gòu)更有效率

　很多情況下，你可以采用另外一種與現(xiàn)在不同的組織結(jié)構(gòu)。看一看Apache Web server的開發(fā)小組，他們的層次組織并不分明，卻開發(fā)出了成功的產(chǎn)品。

8. 使用WWW上的免費(fèi)工具

　從http://sunnet.usc.edu/winwin/winwin.html，你可以下載由Barry Boehm的學(xué)生開發(fā)的，能夠把W理論（WinWin模型）和螺旋形模型結(jié)合起來的工具。在項目管理研究所的網(wǎng)址www.pmi.org，你可以下載它的聯(lián)機(jī)手冊。從www.spmn.com你可以看到從CMM模型出發(fā)的一些建議以及兩套工具：Control Panel和Risk Radar。Control Panel是Excel表格形式，由于監(jiān)測生產(chǎn)率和質(zhì)量；Risk Radar是一個Access數(shù)據(jù)庫，對項目的風(fēng)險進(jìn)行量化管理。

9. 不要小看老程序員

　重新訓(xùn)練現(xiàn)有的程序員比雇用新畢業(yè)的大學(xué)生要有價值。老的程序員在以往的多個項目上有豐富的經(jīng)驗，通過新技能的訓(xùn)練后，他們的經(jīng)驗和知識會幫助年輕的程序員（包括項目經(jīng)理）節(jié)約時間和金錢。

10. 為你的項目選擇定正確的工作流程

　并不是所有的項目都適用一種開發(fā)流程。Intel公司有規(guī)律地檢查每個開發(fā)小組的工作質(zhì)量，如果出現(xiàn)了延遲交付或質(zhì)量問題，Intel鼓勵該小組改進(jìn)他們的工作流程。

11. 做好你的生存計劃
....


________________________________________

主頁 論壇 留言 打印 聯(lián)系






　
參與變革



---------發(fā)現(xiàn)更多可重用的過程與簡單的版本控制相比，更易走向成功
Lisa J. Roberts，譯：umlchina.mirnshi(mirnshi@263.net)



譯者序：本文刊登于SDMagazine，2000年11月。論述了為什么要建立可重用過程以及從中得到的好處。譯文中部分語句采用了意譯，不妥之處和曲意之處請參見原文。



對開發(fā)過程共享實(shí)施猛烈的變革和改變是個什么樣子？除了可能的時間大量損失（好，其實(shí)這是很小的

可能，除了正在改變開發(fā)過程時），當(dāng)它們獲得了人們支持時就都會成功。

在歷史上，人民，社會的勞動者，通過聯(lián)合推動了社會變革。這就是我們所滿意的應(yīng)用程序，MeshTV，用二維和三維的有限元網(wǎng)格以圖形的方式可視化和分析數(shù)據(jù)。它也能處理多種不同的網(wǎng)格類型，提供各種方式查看數(shù)據(jù)并去除了大多數(shù)的硬件和廠商的依賴，同時以自身圖形硬件的速度顯示圖形。MeshTV也可以并行工作，你可以想象得到這需要一些組織級別滿足程序的復(fù)雜性，保持有序。最后說一點(diǎn)，MeshTV大約有450,000行源代碼。

這是我所作的全部描述。如果你想了解得更多，查看www.llnl.gov/bdiv/meshtv，你可以下載可執(zhí)行程序、源代碼和手冊。



受約束的混亂


象許多為內(nèi)部使用而開發(fā)的程序一樣，在加利福尼亞Livemore的勞倫斯Livemore國家實(shí)驗室，對程序必需的修改和增加超出了可用的資源。在MeshTV項目中，這導(dǎo)致了混亂，（on the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（譯者注：這句話不好譯）沒有人有時間坐下來畫出應(yīng)用流程。我們都在實(shí)驗室的里里外外，忙于我們客戶的貪婪的需求。（有約150個文檔用戶-可能更多，實(shí)際上要靠5個兼職的開發(fā)人員支持）在我們這種狀況下，這種過程導(dǎo)致了我們用戶更多的抱怨和可靠性匱乏的程序。

三年前，我們的職責(zé)很小（幾個用戶，幾個開發(fā)人員，很少有廣泛的應(yīng)用功能）允許我們在CVS上用非常不正規(guī)的過程管理源代碼。當(dāng)用戶數(shù)和他們需求差異增多時，相應(yīng)的代碼管理的復(fù)雜性也增加了。處理我們增長的工作量也變得更加困難，我們知道有些事情必須要改變了。我們決定加入到我們部門的其他開發(fā)小組中去，并使用Rational軟件公司的版本控制系統(tǒng)—ClearCase。從此，我們過程的改進(jìn)氛圍（our process improvement culture）開始改變，變革的種子已經(jīng)播下了

在我們轉(zhuǎn)向ClearCase前，我們小組的一位經(jīng)理曾經(jīng)誘導(dǎo)我們更多的集中在過程上，她徒勞了。她看到了增長的壓力和用戶的不滿，她想我們應(yīng)該嘗試用不同的方法提高我們程序的可靠性和在用戶那里的名聲。不幸的是，她的話從來沒有引起重視，同樣我們也認(rèn)識到了這點(diǎn)，但我們不得不忙于作完我們的工作。開發(fā)人員認(rèn)為最好的情況是軟件工程學(xué)所論述的那樣，而在最糟和最可能的情況下，會占用大量的時間，提供眾多的文檔，用處不是很大。我們的一些老開發(fā)人員認(rèn)為改進(jìn)我們的過程沒有用并且……（Some of our veteran developers saw no use for "improving our process" and would have sooner appeared in public in a tutu rather than utter such a sissy phrase.）（譯者注：這句話太難譯了，單詞也不認(rèn)識）而且俱樂部所有人，包括我也懷疑我們要收獲的巨大好處。我認(rèn)為CVS工作得很好，我們真的不需要更多先進(jìn)的東西。

在CVS工作的同時，ClearCase工作得更好。我認(rèn)為在每個軟件工程生產(chǎn)力上沒有真正的提高，但是可以用我以前不能采用的工作方式工作。這些新的工作方法可以使管理源代碼變得更容易，同時也減少了我曾經(jīng)在CVS中遇到的問題。例如，我現(xiàn)在可以輕松的多并發(fā)地開發(fā)，我可以在我完成后可靠的歸并我所作的。新特性彌補(bǔ)了我花在開發(fā)和學(xué)習(xí)新過程上的時間。



真正的產(chǎn)出


過渡不久，一位同事和我與一位來自蘋果計算機(jī)公司的開發(fā)同行進(jìn)行了一次有趣的討論。他的工作需要產(chǎn)品開發(fā)過程的急迫應(yīng)用，包括構(gòu)建方法學(xué)和發(fā)行版本管理過程。當(dāng)我們敘述我們通常隨意無計劃的方式時，他幾乎震驚暈倒。后來的討論，使我們驚奇的了解到了通過改進(jìn)我們的過程所獲得的好處。有一位經(jīng)理鼓勵我們是一方面，但是非同尋常的另一面是聽到一位開發(fā)同行稱贊他發(fā)現(xiàn)的好處。這是真正的產(chǎn)出，計算機(jī)科學(xué)風(fēng)格的。

我們對其思考的越多，我們越認(rèn)識到我們需要行動。將新特性和缺少固定發(fā)行日期聯(lián)系起來的狂熱，導(dǎo)致了在發(fā)行新版本和功能性的匱乏測試間長久的延期。我們的意圖是好的，我們想讓我們的客戶滿意。然而，不知何故，我們的期望事實(shí)上很糟糕，似乎看起來我們工作得很辛苦，但是，我們聽到了更多的抱怨。我們需要改變現(xiàn)狀。

首先，我們轉(zhuǎn)換到有目的的發(fā)行版本日期，使其包含明確的更改和新的功能。像許多的內(nèi)部產(chǎn)品，MeshTV有著明顯的直接的用戶（MeshTV had users who lived "right down the street."）。新特性的不同的聲音淹沒在所有的目標(biāo)回應(yīng)中，我們嘗試經(jīng)常性的從那些所有從會議廳走下來，停下來聊會兒天的用戶那里獲取要求。（這些打斷也可以避免我們持續(xù)工作）荒謬的是在試圖獲取所有要求中，我們不能滿足他們中的大多數(shù)，我們失望了。所以我們從這種方法上退回來?；蛘咴噲D將所有要求放進(jìn)去（可能匆忙地完成，沒有更多明顯的bugs）,或者針對最后的抱怨作一個改正（從而沒有舊的要求）。我們需要一個載明新發(fā)行版本應(yīng)體現(xiàn)哪些要求的計劃。

這表明另一個過程需要改進(jìn)。在決定之前，我們通過將bugs報告和要改變的要求寫到紙上，保證可追蹤。這片紙經(jīng)常“走向了所有事物的歸途”，或者偶然的扔進(jìn)了廢紙簍，或者壓在了其他所有的紙張下面。（這點(diǎn)上我堅信我已危險地靠近制造我自己桌面中子星）（譯者注：黑洞乎）那些紙隨著時間的流逝而不能理解，無心的造成了客戶輸入損失的結(jié)果。

我們需要很好的保持我們改變要求的追蹤，這樣我們就可以為下一個發(fā)行版本選擇明確的要求。在對幾個產(chǎn)品調(diào)研后，我們購買了Pure Atria的ClearDDTS，幫助我們管理我們的改變要求，我們試圖一年四次發(fā)布新版本應(yīng)用程序，這作為一策略被我們采納，這樣我們就可以很快的清晰地增加新功能，不用更新得過于頻繁導(dǎo)致沒有時間測試我們的修改。為了達(dá)到結(jié)束點(diǎn)，我們努力選擇一定量的能夠在三個月內(nèi)完成的工作。第一次時，因為我們沒有人知道如何預(yù)測一個詳細(xì)的修改需要多長時間，我們徹底失敗了。幸運(yùn)的是，我們可以通過ClearDDTS跟蹤我們曾經(jīng)預(yù)測的時間和工作中實(shí)際花費(fèi)的時間，并且個別開發(fā)人員利用這些數(shù)據(jù)預(yù)測將來。在為其他版本的選擇工作中，這獲得了重大的成功。變革明顯的站住了腳。

我們也決定與目標(biāo)發(fā)行版本并進(jìn)，著手提高質(zhì)量的工作。為了完成這點(diǎn)，我們要求所有決意要改變的要求要被不具有開發(fā)責(zé)任的其他人所驗證。當(dāng)我們知道其他人會檢查工作時，我們就都會非常仔細(xì)，這多么驚奇。我們也開始采用Mercury Interactive’s Xrunner和內(nèi)部使用的腳本開發(fā)了一個自動測試系統(tǒng)。將來，在我們發(fā)布一個新版本應(yīng)用程序前，這些測試必須成功的測試過。



持續(xù)的改進(jìn)


所有這些工作都以我們不能想象的方式的到回報了。我們更好地跟蹤我們的改變要求，也就是我們沒有丟掉它們，我們確實(shí)能跟得上用戶的更新狀態(tài)了。用戶喜歡這點(diǎn)，我們也不再面對來自客戶的挫折。他們也喜歡我們更頻繁的更新和更加健壯的程序。

我們正在尋找另外的方式，我們可以從改變我們過程中獲得好處的方式?，F(xiàn)在，我們正在研究軟件開發(fā)成熟度模型（CMM）,看是否能通過遵從2級幫助我們提供更好的應(yīng)用軟件（請到http://www.sei.cmu.edu/查看更多的CMM信息）。我們可以從這種方式中獲得好處，但是我們想確認(rèn)通過2級認(rèn)證能夠編寫更好的代碼，不只是更多的文書工作的要求。我們的興趣在于進(jìn)步，不在于核對boxes。

我們正在進(jìn)行的另一個改變是，我們能夠更容易地在我們每年四個主版本之間發(fā)布修訂bugs的版本。這點(diǎn)可以是我們更快的轉(zhuǎn)向用戶的要求，平息用戶的憤怒。（我們基于用戶認(rèn)識到的嚴(yán)重性和我們察覺的嚴(yán)重性的比較，選擇哪些bugs被改正，還包括工作區(qū)存在的風(fēng)格。我們在整體上也為客戶整合了全部優(yōu)先級的感覺）

我們過程改革的更多驚人結(jié)果之一是不只影響了程序，更多地影響了程序開發(fā)人員。他們停止了改善用戶的態(tài)度，轉(zhuǎn)向提高應(yīng)用程序。程序變得更可靠，發(fā)行版本變得更可預(yù)測的同時，用戶對應(yīng)用軟件整體上也更加滿意。

但是我們不僅只關(guān)心我們的過程的改革。MeshTV的開發(fā)人員同其他的開發(fā)小組并同工作著，我們試著同其他的小組分享我們的經(jīng)驗，學(xué)習(xí)我們的勝利和錯誤。圍繞我們新的過程，我們提供了四個展示，至少有一個小組已經(jīng)決定采用我們的一些經(jīng)驗。變革在成長。



成功孕育成功


當(dāng)管理層嘗試推動改變過程時，從最初的懷疑和憤怒，我們在這個過程中經(jīng)歷了巨大的變革。這些曾經(jīng)著名的過程都是那些所有刊物都討論過，當(dāng)作福音傳授給我們的同事。當(dāng)我回頭看看我們的小組，我驚奇于我們從使用一個版本控制系統(tǒng)改變到幾個可重用性、文檔化過程，甚至將那些經(jīng)驗出售給別人。什么能夠允許我們背離我們正規(guī)的商業(yè)方式

對于我們來說，在開展新的過程中最重要的因素是一個成功的戰(zhàn)士，他醞釀了過程改革中的興趣。這個戰(zhàn)士應(yīng)該是一個受到尊敬的開發(fā)人員，在小組里的，因持續(xù)工作而聞名，因渴望經(jīng)驗的增長而受人尊重。在我們的事中，我們有二位戰(zhàn)士，我的同事Sean Ahern和我自己。在我們興奮于可能的好處并開始著手于一些改革后，小組的其他人信服了并跟隨我們。當(dāng)管理層決定了過程必須跟隨時，來自小組外的壓力出現(xiàn)了。對于外來的，組員將可能排斥它，對此我不能強(qiáng)調(diào)得足夠多。然而，來自里受人尊敬的組成員的狂熱，開發(fā)人員感到是必須聽從。畢竟，這些人們事實(shí)上知道到底它象個什么樣子。一旦其他團(tuán)隊里的人看到了真正的好處，他們就會跳進(jìn)這個潮流中，變革也就會良好的進(jìn)行下去。當(dāng)開發(fā)人員開始思考改進(jìn)過程的方式，獲取真正的好處時，好戲就開始了

你如何開始你的變革？每次一個改變。一旦明顯有好處，你的同事就會加入到你的行列中，同你一起征服編程世界。

________________________________________

主頁 論壇 留言 打印 聯(lián)系






CMM、TSP、PSP講義稿
　
Blueski


　　CMM/TSP/PSP應(yīng)該是目前世界上公認(rèn)的最好的軟件管理模式。
　
CMM提供了框架和目標(biāo)，PSP針對個人進(jìn)行優(yōu)化，TSP針對團(tuán)隊進(jìn)行優(yōu)化。
　
以下提供的是一些CMM/TSP/PSP 介紹的幻燈片。壓縮為cmmtsppsp.zip，打開后共有4個文件，其中cmmtsppss.ppt是主文件，帶有對其它文件的連接。
點(diǎn)擊下載：
　
下載-->> CMM、TSP、PSP講義稿
　
　
此致

2001-8-30制作　


________________________________________

主頁 論壇 留言 打印 聯(lián)系






開發(fā)流程中的可用性
　
來源：
http://www.microsoft.com/China/msdn/msdnonline/features/articles/uicycle.ASP
Microsoft Corporation
2000年10月
　
摘要：本文討論反復(fù)、周期性的設(shè)計過程，包括以用戶為中心進(jìn)行設(shè)計的四個原則、兩種類型的產(chǎn)品設(shè)計過程，以及可用性活動如何滲透產(chǎn)品開發(fā)的各個階段并為其帶來益處。
　
目錄
• 簡介
• 使用反復(fù)、周期性的設(shè)計過程
• 構(gòu)思階段
• 規(guī)劃階段
• 開發(fā)階段
• 穩(wěn)定化階段
• 為下一版本做準(zhǔn)備
________________________________________

簡介
可用性測試為您帶來的好處
簡言之，如果將可用性測試從產(chǎn)品開發(fā)周期的一開始一直貫徹到項目的每一階段中，將使您在最后的處理過程中省去重新開發(fā)這一環(huán)節(jié)。
本文首先討論重復(fù)、周期性的設(shè)計過程。第一部分闡述了以用戶為中心進(jìn)行設(shè)計時的四個原則，這是由 Gould、Boies 和 Lewis 提出的。接下來介紹了兩種類型的產(chǎn)品設(shè)計過程：“瀑布式”方法和“螺旋式”方法。本文的其余部分將簡要介紹產(chǎn)品開發(fā)的各個階段，并討論可用性活動是如何滲透各個階段并帶來益處的。此處所述的開發(fā)階段包括：構(gòu)思、規(guī)劃、開發(fā)、穩(wěn)定化以及為下一版本做準(zhǔn)備。
在您閱讀各小節(jié)時，請注意用戶將頻繁地參與到各個過程中。用戶對每個階段的介入將會在項目的收尾階段為您省去成本高昂的返工工作，而且這樣開發(fā)出來的產(chǎn)品將使用戶樂于使用、易于學(xué)習(xí)，并會長期使用。

使用反復(fù)、周期性的設(shè)計過程
反復(fù)、周期性的設(shè)計過程為以用戶為中心進(jìn)行的設(shè)計帶來了極大的便利。以用戶為中心的設(shè)計有四個重要原則，這些原則是由 Gould、Boies 和 Lewis 于 1991 年提出的：
• 及早以用戶為中心：設(shè)計人員應(yīng)當(dāng)在設(shè)計過程的早期就致力于了解用戶的需要。
• 綜合設(shè)計：設(shè)計的所有方面應(yīng)當(dāng)齊頭并進(jìn)發(fā)展，而不是順次發(fā)展。使產(chǎn)品的內(nèi)部設(shè)計與用戶界面的需要始終保持一致。
• 及早并持續(xù)性地進(jìn)行測試：當(dāng)前對軟件測試的唯一可行的方法是根據(jù)經(jīng)驗總結(jié)出的方法，即若實(shí)際用戶認(rèn)為設(shè)計是可行的，它就是可行的。通過在開發(fā)的全過程引入可用性測試，可以使用戶有機(jī)會在產(chǎn)品推出之前就設(shè)計提供反饋意見。
• 反復(fù)式設(shè)計：大問題往往會掩蓋小問題的存在。設(shè)計人員和開發(fā)人員應(yīng)當(dāng)在整個測試過程中反復(fù)對設(shè)計進(jìn)行修改。
多年來，“瀑布式”的產(chǎn)品設(shè)計過程是軟件設(shè)計的標(biāo)準(zhǔn)。在這一方法中，項目開發(fā)通過分階段發(fā)展的、按順序的各個階段進(jìn)行。這種方法使用重大事件作為轉(zhuǎn)變點(diǎn)和評估點(diǎn)，并認(rèn)為在下一階段開始前，前面的每一階段均已結(jié)束?！捌俨际健钡姆椒▽τ趶?fù)雜的項目很有效。在復(fù)雜的項目中，多個供應(yīng)商負(fù)責(zé)項目的各個方面（例如，一個供應(yīng)商負(fù)責(zé)需求分析，另一個負(fù)責(zé)規(guī)范，等等）。但是，使用這種方法可能導(dǎo)致隨著項目的進(jìn)展，對項目進(jìn)行更改越來越難。
相形之下，“螺旋式”的產(chǎn)品設(shè)計過程卻是反復(fù)、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。這一過程允許更大地發(fā)揮創(chuàng)造性，并且更易于隨著項目的進(jìn)展而對項目進(jìn)行修改。在進(jìn)行螺旋式的設(shè)計過程時，您會發(fā)現(xiàn)可在各個階段對產(chǎn)品各方面的功能進(jìn)行設(shè)計。這種方法可為以用戶為中心的產(chǎn)品開發(fā)過程帶來便利。
螺旋式的產(chǎn)品設(shè)計過程有六個階段：構(gòu)思、規(guī)劃、建模、開發(fā)、穩(wěn)定化以及為下一版本做準(zhǔn)備。

構(gòu)思階段
產(chǎn)品開發(fā)的構(gòu)思階段是確定項目的目標(biāo)和范圍的階段。此階段要確立構(gòu)思陳述、設(shè)計目標(biāo)、風(fēng)險評估以及項目構(gòu)架。
在構(gòu)思階段，通常進(jìn)行下列可用性活動：
環(huán)境研究
基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一書中所述的方法，此類型的研究包括觀察用戶的所做所為，使您更為直觀地了解用戶行為。如果您尚未決定究竟要開發(fā)何種軟件，但認(rèn)為存在市場機(jī)會，就可使用環(huán)境研究來對活動進(jìn)行研究。您可了解可為用戶做些什么以及實(shí)現(xiàn)的難易程度。不是尋求具體的功能，而是尋求設(shè)計機(jī)會。
環(huán)境研究為項目提供工作的重心。如果項目是全新的項目，或是較全面的升級，這種方法最為適用。在進(jìn)行較全面的升級或開展全新項目時，您無法全面了解用戶在做什么、如何做、以及他們所面臨的問題或困擾。而進(jìn)行較小的升級時，您有可能從產(chǎn)品支持部門、先前的研究等處獲得這些信息。在這種情況下，您基本上是對現(xiàn)有的設(shè)計加以完善，所以環(huán)境研究并不是不可或缺的。
環(huán)境研究在以下情況最為適合：項目組進(jìn)行跨學(xué)科的環(huán)境研究，小組由可用性工程師帶領(lǐng)。
競爭性測試
通過競爭性可用性測試，您可以為產(chǎn)品設(shè)置量化的可用性目標(biāo) — 任務(wù)完成的速度、每項任務(wù)出錯的數(shù)目，等等。這種方法可對項目的成功與否進(jìn)行量化的度量，即使所進(jìn)行的競爭只是人工過程，而您將對此過程進(jìn)行自動化。競爭性測試經(jīng)常用于市場開發(fā)。當(dāng)市場開發(fā)代表對競爭對手進(jìn)行評估時，他們只比較產(chǎn)品的功能?？捎眯詼y試則更側(cè)重于使用這些功能完成任務(wù)時的性能。
競爭性測試對僅用于公司內(nèi)部的產(chǎn)品來說，似乎不大適用。但是，如果仔細(xì)考慮，從理論上而言，您也是在與產(chǎn)品的先前版本或前一個流程競爭。內(nèi)部產(chǎn)品可能與人工過程進(jìn)行競爭 — 產(chǎn)品必須比現(xiàn)有的進(jìn)程更有效、更好。
進(jìn)行競爭性測試的方法之一是開展研究，比較與其相競爭的產(chǎn)品的性能。例如，對其他人員的產(chǎn)品進(jìn)行性能研究。在選擇要測試的競爭產(chǎn)品時，要考慮到計算機(jī)之外的產(chǎn)品：如果產(chǎn)品涉及在線交易，則競爭性產(chǎn)品就可以是電子貨幣。從研究結(jié)果中您可以確定使用最頻繁的、最重要的功能。
用戶/受眾分析
了解您的用戶！盡可能采取各種方法來了解您的用戶的特點(diǎn)?？紤]一下如果您基于產(chǎn)品最終用戶的特點(diǎn)來開發(fā)軟件，可減少多少技術(shù)支持電話的數(shù)量。設(shè)想一下用戶是否認(rèn)為產(chǎn)品易于使用并且包含了他們所需的功能。問自己“對于我要創(chuàng)建的產(chǎn)品，哪些用戶特點(diǎn)是與之相關(guān)的？”，例如：
• 計算機(jī)使用經(jīng)驗
• 年齡
• 接受培訓(xùn)的程度
• 用戶群之間的社會關(guān)系
• 特殊要求（可訪問性）
您可以通過環(huán)境研究來獲得一些此類信息。例如，您可對一些用戶進(jìn)行觀察以得出一些假設(shè)，然后通過調(diào)研或取樣來驗證這些假設(shè)。您的人力資源部門或培訓(xùn)部門可能會具有一些相關(guān)的信息；例如每個新雇員要接受多少培訓(xùn)。市場研究人員也可能有此類信息。對于公司內(nèi)部使用的應(yīng)用程序而言，收集這些信息有時會比對外出售的應(yīng)用程序簡便，因為您的用戶是具體的群體而不是普通大眾。

規(guī)劃階段
規(guī)劃階段是進(jìn)行首次實(shí)際設(shè)計的階段。在此階段中，有關(guān)用戶界面的早期設(shè)想將初步成形，并著重于先前階段未涉及的知識。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的簡單描繪圖紙、打印在紙上的屏幕位圖圖形，用 Macromedia Director 之類的程序創(chuàng)建的帶有有限交互功能（也稱為“點(diǎn)閱”）的聯(lián)機(jī)版本，或是用 HTML 或 Microsoft Visual Basic® 創(chuàng)建的帶有大量交互功能的聯(lián)機(jī)版本。在大多數(shù)情況下，您會發(fā)現(xiàn)原型具有的仿真度越高，用戶建議進(jìn)行重大修改的可能性就越低。所以，用寫在紙上的原型來開始著手測試是非常值得采取的做法。
根據(jù)您所設(shè)計的產(chǎn)品種類，您可能需要進(jìn)行下述的一些或所有活動。如果您在規(guī)劃階段花時間來完成這些任務(wù)并使用原型，則在開發(fā)階段碰到的可用性問題將會大為減少。
用戶情況
創(chuàng)建您自己的用戶情況概要，列出產(chǎn)品的典型用戶能做什么，不能做什么。通過早期的環(huán)境研究和用戶/受眾分析，您做出一些較高級別的決策，基于這些決策進(jìn)行軟件設(shè)計。使用用戶情節(jié)，您可創(chuàng)建一個有關(guān)用戶使用您所設(shè)計的軟件的“故事”。這些情況可以是情節(jié)串聯(lián)圖板、聯(lián)機(jī) Macromedia Director 電影、簡單的流程圖、或簡單的敘述性文本。一種比較精致的用戶情節(jié)模式是“日常生活”錄像。這種錄像把演員作為“用戶”顯示，這些用戶在日常活動中與模擬的系統(tǒng)進(jìn)行交互。通過用戶情節(jié)可得出您在任務(wù)分析時要尋找的具體細(xì)節(jié)。
任務(wù)分析
任務(wù)分析決定了在新產(chǎn)品中執(zhí)行任務(wù)的方式。在撰寫規(guī)范之前，必須首先進(jìn)行任務(wù)分析。用任務(wù)分析來確定您所規(guī)劃的支持的任務(wù)是否確實(shí)能夠反映現(xiàn)實(shí)，這一點(diǎn)是很重要的。對任務(wù)的逼真度進(jìn)行分析。就產(chǎn)品的特性而言，任務(wù)的完整性如何？分析逼真度意味著觀察用戶完成一項任務(wù)所必須執(zhí)行的所有操作；或進(jìn)行表象的觀察，了解用戶完成所有任務(wù)或功能所需執(zhí)行的所有操作。無需擔(dān)心過于詳盡 — 把重點(diǎn)放在實(shí)質(zhì)內(nèi)容上。
一些要考慮的問題和活動：
• 此環(huán)境中的任務(wù)是什么？環(huán)境研究應(yīng)能幫助您找出并描述用戶所執(zhí)行的任務(wù)。
• 創(chuàng)建順序圖，描述用戶執(zhí)行的任務(wù)之間、用戶和產(chǎn)品之間的相互作用。
• 在構(gòu)思階段確定功能的作用領(lǐng)域。提出問題：“我們要支持的具體任務(wù)是什么？”
• 與產(chǎn)品設(shè)計者一起創(chuàng)建情節(jié)串聯(lián)圖板或順序簡圖。
啟發(fā)式評估
啟發(fā)式評估涉及評估人員小組，這些評估人員查看界面并基于基本可用性原則來對其做出判斷。啟發(fā)式評估允許您在整個反復(fù)式設(shè)計過程中查找并更正可用性問題。如果您在工作進(jìn)展的同時糾正問題，您將在收尾階段節(jié)省大量工作。因為在收尾階段，更改真實(shí)代碼將更加困難而且成本更高。
如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，啟發(fā)式評估包括以下步驟：
1. 每個評估人員都瀏覽數(shù)遍界面，檢查各種對話框元素，然后將其與一些已知的可用性原則相比較。
2. 評估人員相互合作，將結(jié)果合并到列表中，列出用戶界面中的可用性問題，并注明設(shè)計方案中違反的相關(guān)可用性原則。
3. 一旦每個評估人員都分別執(zhí)行了啟發(fā)式評估后，他們就集中起來將其評估結(jié)果合并在一起。
在開發(fā)的早期階段，啟發(fā)式評估可能是發(fā)現(xiàn)可用性問題的非常有效的方法。
認(rèn)知性遍歷
認(rèn)知性遍歷的意思是，仔細(xì)檢查界面要求用戶執(zhí)行多少步驟以及何種步驟后，才能完成某項任務(wù)，其中包含用戶必須經(jīng)過思考才能完成的那些步驟。您需要關(guān)注的是用戶必須調(diào)用什么或用戶必須進(jìn)行的計算 — 認(rèn)知性任務(wù)決定學(xué)習(xí)和使用您的產(chǎn)品的難易程度。認(rèn)知性遍歷可幫助您找出潛在的可用性問題，以及找出您制訂的規(guī)范中的破綻！
根據(jù) Gregory Abowd 的 Performing a Cognitive Walkthrough，要進(jìn)行認(rèn)知性遍歷活動，需要以下四個條件：
1. 對系統(tǒng)原型的詳盡描述，例如初級規(guī)范可提供什么樣的系統(tǒng)。這種描述不一定是完整的，但要相當(dāng)詳盡。諸如菜單的位置或措辭這樣的細(xì)節(jié)也可能導(dǎo)致相當(dāng)大的差異。
2. 對用戶在系統(tǒng)中要完成的任務(wù)的描述。該任務(wù)應(yīng)當(dāng)是大多數(shù)用戶將要執(zhí)行的有代表性的任務(wù)。
3. 一個完整的、書面的操作清單，列出使用給定原型完成任務(wù)所需執(zhí)行的操作。
4. 指出用戶的身份，以及評估人員能夠假定這些用戶已具有哪一類別的知識和經(jīng)驗。
有了這些信息，評估人員可執(zhí)行一遍上文第三項所列的操作，從而確定用戶是否能夠按預(yù)期要求合理執(zhí)行這些步驟。
GOMS
GOMS 是描述任務(wù)和用戶執(zhí)行該任務(wù)所需知識的方法，它是通過目標(biāo) (Goal)、操作符 (Operator)、方法 (Method) 以及選擇規(guī)則 (Selection rule) 四個方面進(jìn)行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他們還創(chuàng)建了一個簡化的版本，即擊鍵級別模型 (KLM)。Bonnie E. John 開發(fā)了并行活動版本 CPM-GOMS，而 David Kieras 則開發(fā)出定義更為嚴(yán)謹(jǐn)?shù)陌姹荆鹤匀?GOMS 語言 (NGOMSL)。所有這些技術(shù)都基于同一 GOMS 概念。
• 不言自明，目標(biāo)就是指用戶的目標(biāo)。用戶使用軟件要達(dá)到什么目的？在下一天、下幾分鐘、下幾秒鐘？
• 操作符是指軟件允許用戶采取的操作。
• 方法是子目標(biāo)和操作符經(jīng)仔細(xì)設(shè)計后得出的序列，可用來實(shí)現(xiàn)諸如剪切和粘貼等目標(biāo)。
• 選擇規(guī)則是用戶要遵守的判定規(guī)則，以確定在特定環(huán)境下要使用的方法。
GOMS 模型由對方法的描述組成，這些方法是達(dá)到目標(biāo)所必需的。方法是一些步驟，這些步驟包括用戶為達(dá)到目標(biāo)所需執(zhí)行的操作符。如果有一種以上的方法可以達(dá)到目標(biāo)，則需使用選擇規(guī)則來確定在此情況下哪種方法更為適用。
卡片排序
卡片排序是一種可用性技術(shù)，用于此階段的早期，以了解用戶關(guān)于信息的總體模型?？ㄆ判虻幕救蝿?wù)是要讓參與者按卡片上的說明對卡片進(jìn)行組織，將屬于同一類的項目堆放在一起。在創(chuàng)建好堆后，參與者還可為所創(chuàng)建的堆建立名稱、標(biāo)簽或說明。
卡片排序用于：
• 展示用戶對于任務(wù)范圍的總體模型。
• 展示用戶如何對項目進(jìn)行分組或分類的。
• 展示用戶對項目之間的關(guān)系和相似性的看法。
• 將用戶的概念模型轉(zhuǎn)換為設(shè)計。
反復(fù)可用性測試
對原型設(shè)計的反復(fù)可用性測試是另一種很有價值的方法，用于在產(chǎn)品周期的早期階段確定界面是否易于用戶使用。在此階段進(jìn)行更改比等到開發(fā)階段開始后再進(jìn)行更改要更容易些，并且成本更低。
您從可用性實(shí)驗室可以收集的數(shù)據(jù)量取決于原型的強(qiáng)健性。對于紙上原型測試，可用性工程師就是計算機(jī)，并且在測試的過程中與用戶在一起。
在許多種情況下，嚴(yán)謹(jǐn)?shù)目捎眯詼y試是過猶不及的。在建模階段，您仍可使用簡化的方法進(jìn)行有效的可用性測試，這些方法通常稱為“打折扣的”可用性測試。
如 Jakob Nielsen 所述，反復(fù)的可用性測試包括：
1. 用戶和任務(wù)觀察 — 觀察用戶，保持安靜，讓用戶做一切通常情況下會做的操作。
2. 情況 — 使用一種可以減少功能數(shù)量、降低功能級別的建模方法。
3. 簡化的對談式測試 — 一次安排一個用戶完成一組任務(wù)，并要求用戶“發(fā)現(xiàn)問題就直接告知測試人員”。
4. 啟發(fā)式評估 — 基于基本可用性原則來評價界面。

開發(fā)階段
開發(fā)階段是將產(chǎn)品用實(shí)際的代碼來實(shí)現(xiàn)的階段。在此階段中，您可以對實(shí)際產(chǎn)品的早期版次進(jìn)行可用性測試。您仍有可能不時要用到原型，但隨著時間的推移產(chǎn)品將逐漸完善。不是所有的功能都將在開發(fā)階段同時完成，所以您有可能在原型和實(shí)際代碼之間往復(fù)轉(zhuǎn)換。
在理想條件下，您將可以把大部分時間用來進(jìn)行推敲，在建模階段就能夠找出主要問題。
真實(shí)代碼測試
讓用戶測試真實(shí)代碼版本可能會有助于針對在計算機(jī)上使用產(chǎn)品發(fā)現(xiàn)問題。這些問題更有可能是設(shè)計問題而非概念問題。它們通常涉及相當(dāng)?shù)图壍慕换プ饔脝栴}，如在屏幕上選擇項目、拖放，以及僅在實(shí)際產(chǎn)品中才有的動態(tài)圖形。對于產(chǎn)品的大多方面，真實(shí)代碼不一定比設(shè)計上的原型或其它模型的真實(shí)度更高，所以不要拖延到有真實(shí)代碼后再進(jìn)行可用性測試。
可用性實(shí)驗室測試
在開發(fā)階段，您可進(jìn)行可用性實(shí)驗室測試，該測試類似于規(guī)劃階段的反復(fù)可用性測試。但是，由于產(chǎn)品的更多部分已趨于完善，您可測試更多任務(wù)。您仍可在 Director 中使用模型，或?qū)⑸宰鲂薷牡陌娲斡迷诳捎眯詼y試中。隨著時間的推移，產(chǎn)品會越來越完善，原型就越來越不象一個模型了。但是，用“已完成”產(chǎn)品進(jìn)行測試的問題在于，由于已進(jìn)行了如此之多的工作，剩下的時間如此之少，您就不能指望對發(fā)現(xiàn)的問題做太多的修改了。
注意： 作為此任務(wù)的一部分，您還可能進(jìn)行焦點(diǎn)組分析或群集分析，以對產(chǎn)品進(jìn)行可用性測試。

穩(wěn)定化階段
當(dāng)開發(fā)結(jié)束、錯誤已修正后，就進(jìn)入了穩(wěn)定化階段。在此階段中，要創(chuàng)建一個可發(fā)售的穩(wěn)定的產(chǎn)品。在此階段對可用性進(jìn)行測試的重點(diǎn)是進(jìn)行微調(diào)。新的功能以及代價高昂的可用性增強(qiáng)功能應(yīng)被記錄下來，以備下一版本使用。
基準(zhǔn)測試
對可用性進(jìn)行基準(zhǔn)測試類似于“質(zhì)量保證”中的綜合測試?；鶞?zhǔn)測試的目的是通過測試用戶想要完成的所有頂級任務(wù)，就產(chǎn)品的可用性提供可靠的量化數(shù)據(jù)。這些測試的目標(biāo)與其說是要找出問題（雖然找出問題是大多數(shù)可用性測試的目的），不如說是要評估產(chǎn)品可用性的狀態(tài)。
要進(jìn)行基準(zhǔn)測試，請首先觀察產(chǎn)品的功能，然后將這些功能按任務(wù)細(xì)分。在穩(wěn)定化階段，特別是對于復(fù)雜的產(chǎn)品，您將不能對用戶界面進(jìn)行可提高每個任務(wù)性能的修改。理想情況下，您可以確定哪些是頂級任務(wù)，并且確保大多數(shù)頂級任務(wù)都是可用的。低優(yōu)先級的任務(wù)的可用性可以較低，可記錄下來在將來的版本中再作改進(jìn)。

為下一版本做準(zhǔn)備
將此階段視為開始對過程進(jìn)行回顧的階段。您將全面考慮在構(gòu)思階段和規(guī)劃階段所進(jìn)行的許多相同任務(wù)。例如，您將進(jìn)行：
• 競爭性測試 — 在穩(wěn)定化階段，這種測試是對自己的產(chǎn)品進(jìn)行測試，以將其與先前收集的有關(guān)競爭產(chǎn)品的數(shù)據(jù)作比較。
• 現(xiàn)場研究 — 類似于環(huán)境研究（該研究是要了解“我們要做什么軟件？”），使用您已構(gòu)建的軟件來找出存在哪些問題，可在下一版本加以解決。
• 關(guān)于事件的工具化版本研究 — 軟件的工具化版本基本上用來觀測軟件自身并在發(fā)生事件時記錄數(shù)據(jù)。您在大量會話和用戶的基礎(chǔ)上對產(chǎn)品進(jìn)行測量以找到使用趨勢。


________________________________________

主頁 論壇 留言 打印 聯(lián)系







　
如何組織軟件開發(fā)團(tuán)隊
　
專家、多面手還是他們的組合？
Scott W. Ambler
總裁，Ronin International
2000 年 11 月 2 日
本文來自IBM DeveloperWorks中國網(wǎng)站
　
如何構(gòu)建軟件開發(fā)團(tuán)隊取決于可供選擇的人員、項目的需求以及組織的需求。本文闡述了各種團(tuán)隊組織的策略。
有效的軟件項目團(tuán)隊由擔(dān)當(dāng)各種角色的人員所組成。每位成員扮演一個或多個角色；可能一個人專門負(fù)責(zé)項目管理，而另一些人則積極地參與系統(tǒng)的設(shè)計與實(shí)現(xiàn)。常見的一些項目角色包括：
• 分析師
• 策劃師
• 數(shù)據(jù)庫管理員
• 設(shè)計師
• 操作／支持工程師
• 程序員
• 項目經(jīng)理
• 項目贊助者
• 質(zhì)量保證工程師
• 需求分析師
• 主題專家（用戶）
• 測試人員
您是如何組織項目團(tuán)隊的？是采用垂直方案、水平方案還是混合方案？以垂直方案組織的團(tuán)隊由多面手組成，每個成員都充當(dāng)多重角色。以水平方案組織的團(tuán)隊由專家組成，每個成員充當(dāng)一到兩個角色。以混合方案組織的團(tuán)隊既包括多面手，又包括專家。
一個重要的考慮因素是可供選擇的人員的性質(zhì)。如果大多數(shù)人員是多面手，則您往往需要采用垂直方案，同樣，如果大多數(shù)人員是專家，則采用水平方案。如果您正引入一些新人，即使這些人員都是合同工，則仍然需要優(yōu)先考慮您的項目和組織。本文描述了形成團(tuán)隊組織的垂直、水平和混合方案，并指出了它們各自的優(yōu)缺點(diǎn)。本次討論的一個重要含意是您的團(tuán)隊組織和用于管理項目的手段之間應(yīng)構(gòu)成默契；任何方法上的失諧都很可能導(dǎo)致項目產(chǎn)生問題。
　
垂直團(tuán)隊組織

垂直團(tuán)隊由多面手組成。用例 分配給了個人或小組，然后由他們從頭至尾地實(shí)現(xiàn)用例。
　
優(yōu)點(diǎn)
• 以單個用例為基礎(chǔ)實(shí)現(xiàn)平滑的端到端開發(fā)。
• 開發(fā)人員能夠掌握更廣泛的技能。
　
缺點(diǎn)
• 多面手通常是一些要價很高并且很難找到的顧問。
• 多面手通常不具備快速解決具體問題所需的特定技術(shù)專長。
• 主題專家可能不得不和若干開發(fā)人員小組一起工作，從而增加了他們的負(fù)擔(dān)。
• 所有多面手水平各不相同。
　
成功因素
• 每個成員都按照一套共同的標(biāo)準(zhǔn)與準(zhǔn)則工作。
• 開發(fā)人員之間需要進(jìn)行良好的溝通，以避免公共功能由不同的組來實(shí)現(xiàn)。
• 公共和達(dá)成共識的體系結(jié)構(gòu)需要盡早在項目中確立。
　
水平團(tuán)隊組織

水平團(tuán)隊由專家組成。此類團(tuán)隊同時處理多個用例，每個成員都從事用例中有關(guān)其自身的方面。
優(yōu)點(diǎn)
• 能高質(zhì)量地完成項目各個方面（需求、設(shè)計等）的工作。
• 一些外部小組，如用戶或操作人員，只需要與了解他們確切要求的一小部分專家進(jìn)行交互。
　
缺點(diǎn)
• 專家們通常無法意識到其它專業(yè)的重要性，導(dǎo)致項目的各方面之間缺乏聯(lián)系。
• “后端”人員所需的信息可能無法由“前端”人員來收集。
• 由于專家們的優(yōu)先權(quán)、看法和需求互不相同，所以項目管理更為困難。
　
成功因素
• 團(tuán)隊成員之間需要有良好的溝通，這樣他們才能彼此了解各自的職責(zé)。
• 需要制定專家們必須遵循的工作流程和質(zhì)量標(biāo)準(zhǔn)，從而提高移交給其他專家的效率。
　
混合團(tuán)隊組織

混合團(tuán)隊由專家和多面手共同組成。多面手繼續(xù)操作一個用例的整個開發(fā)過程，支持并處理多個使用例中各部分的專家們一起工作。
優(yōu)點(diǎn)
• 擁有前兩種方案的優(yōu)點(diǎn)。
• 外部小組只需要與一小部分專家進(jìn)行交互。
• 專家們可集中精力從事他們所擅長的工作。
• 各個用例的實(shí)現(xiàn)都保持一致。
　
缺點(diǎn)
• 擁有前兩種方案的缺點(diǎn)。
• 多面手仍然很難找到。
• 專家們?nèi)匀徊荒苷J(rèn)識到其他專家的工作并且無法很好地協(xié)作，盡管這應(yīng)該由多面手來調(diào)節(jié)。
• 項目管理仍然很困難。
　
成功因素
• 項目團(tuán)隊成員需要良好的溝通。
• 需要確定公共體系結(jié)構(gòu)。
• 必須適當(dāng)?shù)囟x公共流程、標(biāo)準(zhǔn)和準(zhǔn)則。
　
項目團(tuán)隊士氣是項目成功的一個因素

大部分項目成功的定義說的是項目如何按時完成、是否在預(yù)算內(nèi)以及是否滿足用戶的需要。但是，在如今要找到好的軟件專業(yè)人員都非常困難，更不用說留住他們的這種情況下，還需要將項目成功的定義擴(kuò)展為包括項目團(tuán)隊的士氣。可能在努力完成一個軟件項目后，不料卻因為壓榨他們過度而失去了重要的開發(fā)人員，這樣做可能會符合組織的短期需要，但它對構(gòu)建一個高效的軟件部門的長遠(yuǎn)利益來說肯定是有害的。衡量項目成功與否的一個重要手段是項目結(jié)束后團(tuán)隊的士氣。在項目結(jié)束之際，項目團(tuán)隊的各個成員是否覺得他們從自己的經(jīng)歷中學(xué)到了一些知識、是否喜歡為這次項目工作，以及是否希望參與組織的下一個項目都是非常重要的。
　

________________________________________

主頁 論壇 留言 打印 聯(lián)系









軟件項目管理（CMM）經(jīng)驗談

（張鳳岐　2001年07月04日 （電腦商報）

編者按：
CMM認(rèn)證是當(dāng)今IT界最熱的話題之一，這表明中國軟件企業(yè)已開始重視與軟件項目管理有關(guān)的問題了。為了了解國內(nèi)軟件企業(yè)對軟件項目管理的認(rèn)識程度以及他們在軟件項目管理方面的具體做法，日前，記者采訪了開思、東方通、瑞星三家純軟件公司的相關(guān)負(fù)責(zé)人。三家公司中，東方通業(yè)已開始按照CMM規(guī)范進(jìn)行軟件開發(fā)。在采訪中，三家公司的負(fù)責(zé)人分別介紹了各自企業(yè)在軟件項目管理方面的經(jīng)驗。開思公司的產(chǎn)品總監(jiān)石宏峰先生還為記者詳細(xì)講解了開思公司的《產(chǎn)品部開發(fā)規(guī)范》。

經(jīng)過整理，我們將東方通和瑞星兩家公司的負(fù)責(zé)人在采訪中所說的主要內(nèi)容刊登于此。我們相信，其具有一定的認(rèn)識價值。另外，我們將開思公司《產(chǎn)品部開發(fā)規(guī)范》的一部分也刊登于此——我們并不認(rèn)為開思的規(guī)范就是最好的規(guī)范。對軟件項目管理而言，普適性是不存在的，好壞是相對的，適用不適用才是絕對的——我們相信，其具有一定的參照價值?！?


加強(qiáng)相關(guān)教育和培訓(xùn)

朱律瑋（東方通科技首席軟件設(shè)計師）

楊樺（東方通科技總經(jīng)理助理）　　　

東方通科技從去年底開始為參加CMM認(rèn)證（二級）做準(zhǔn)備。擬議中正式參評的時間是今年11月。在這之前我們會請國內(nèi)咨詢公司的有關(guān)專家和國外的評估師進(jìn)行兩次預(yù)評估。

半年多來，我們覺得一切還算順利。起初我們擔(dān)心編程人員會有抵觸情緒——因為每完成一天的工作或一道工序或一個項目后都要做記錄、編文檔、寫報告，較之以前，工作量無疑是增加了——后來看看，大家對執(zhí)行CMM規(guī)范還是理解的、支持的。

按照CMM規(guī)范開展工作后，到目前為止，公司的運(yùn)營成本是增加了——因為要增加管理人員、撰寫文檔也需要人手——但從長遠(yuǎn)看，其會帶來降低成本、提高質(zhì)量、提高用戶滿意度等好處。對此，我們確信不疑。

與國外相比，我們在軟件工程管理方面的差距不僅表現(xiàn)為管理體制、管理方法、管理思想的陳舊，整個軟件業(yè)的落后才是根源。

個人英雄主義情結(jié)、喜歡單打獨(dú)斗是我們的民族性之一，其在軟件人才身上表現(xiàn)得尤為明顯，已成為中國軟件企業(yè)做大的一個瓶頸。造成這種狀況的原因，除了國內(nèi)軟件業(yè)的發(fā)展水平不高、軟件項目規(guī)模不大和軟件企業(yè)管理者自身素質(zhì)不高外，還有很重要的一點(diǎn)，即與軟件工程管理有關(guān)的教育內(nèi)容幾乎沒有。在國外，PSP和GSP均為軟件專業(yè)學(xué)生的必修課，可在國內(nèi)，這兩門課在學(xué)校里至今還沒有開起來。國外施行的是定崗培訓(xùn)，比如撰寫文檔就是一門專業(yè)課，專門有人修它，畢業(yè)后拿它來“安身立命”，國內(nèi)則是大家過獨(dú)木橋，統(tǒng)統(tǒng)都學(xué)寫程序。應(yīng)該說，目前國內(nèi)同行對軟件工程管理的重要性已有了一定的認(rèn)識，但在相關(guān)人員的培訓(xùn)上下的力氣仍遠(yuǎn)遠(yuǎn)不夠。

其實(shí)人才才是最關(guān)鍵的?，F(xiàn)在軟件業(yè)最缺的人才之一就是產(chǎn)品經(jīng)理，他們是軟件工程管理的主角。產(chǎn)品經(jīng)理必須具備以下素質(zhì)：具有長期的軟件開發(fā)經(jīng)驗——般來講，要在8年以上；了解用戶的需求；對產(chǎn)品熟、對市場熟——他可以不了解一個產(chǎn)品的底層技術(shù)，但必須了解其功能，能把握其發(fā)展方向；具有協(xié)調(diào)能力?？傊?，產(chǎn)品經(jīng)理并不一定非常聰明，并不需要在某一方面特別突出，但要八面玲瓏。這樣的人才太難找了。東方通的產(chǎn)品經(jīng)理都是自己培養(yǎng)的。

CMM規(guī)范并非只適用于大型軟件企業(yè)，其也適用于中小型企業(yè)。CMM規(guī)范只是一個框架、綱要性質(zhì)的東西。企業(yè)在落實(shí)它時要細(xì)化一次；企業(yè)將其落實(shí)到具體的某個項目時，要再細(xì)化一次；中小企業(yè)可以不像大型企業(yè)那樣將CMM規(guī)范細(xì)化得那么細(xì)，夠用就好，不要教條。

實(shí)施CMM規(guī)范、通過CMM認(rèn)證有如下一些好處：確定工作流程和方式，從而使產(chǎn)品的質(zhì)量和開發(fā)的可延續(xù)性有了保證；可以提高企業(yè)在用戶中的信譽(yù)度，增加企業(yè)與強(qiáng)勢公司競爭的籌碼；可以承接國際大公司的外包項目———美國公司愿意找印度公司來承接其外包項目，就是因為印度公司對CMM規(guī)范普遍比較重視，通過CMM認(rèn)證的軟件企業(yè)也多；公司不再受制于人，人走了，事照做，這是一個公司成熟的表現(xiàn)。


軟件商業(yè)化的必要手段

談文明（北京瑞星科技股份有限公司研發(fā)部經(jīng)理）

中國軟件產(chǎn)業(yè)發(fā)展時間不長，雖然已有部分技術(shù)達(dá)到國際水平，但由于商業(yè)環(huán)境還不夠完善，在軟件技術(shù)的商業(yè)化與軟件工程管理等方面，與國際同行相比，還存在差距。

只有率先將技術(shù)先進(jìn)的產(chǎn)品推向市場的公司才會贏得利潤。在瑞星，技術(shù)商品化已被當(dāng)作一種制度，它有助于提高整個企業(yè)的素質(zhì)。

瑞星意識到在充滿競爭的環(huán)境中要獲得成功，天才人物是必不可少的，但他們并不是全部。目前，一個軟件工程的成功更多地要依靠科學(xué)家、工程師、制造人員和銷售人員的協(xié)同努力。

在軟件商業(yè)化的過程之中，建立規(guī)范化的易于操作的軟件開發(fā)行為規(guī)范是首先要做的工作。針對殺毒軟件的特點(diǎn)，瑞星專門設(shè)計了瀑布模型結(jié)合增量模型的開發(fā)方式，即將項目分階段來實(shí)現(xiàn)。首先實(shí)現(xiàn)市場最需求的核心功能，然后在此基礎(chǔ)上繼續(xù)開發(fā)，每個單獨(dú)的階段都采用瀑布模型的開發(fā)方式。

具體地說，一個基本的軟件開發(fā)流程包括需求階段、系統(tǒng)設(shè)計階段、詳細(xì)設(shè)計階段、編碼階段、單元測試階段、集成測試階段、系統(tǒng)測試階段、軟件發(fā)布軟件維護(hù)階段。其中決定軟件開發(fā)成功與否的關(guān)鍵階段是：軟件需求管理、軟件計劃管理、軟件質(zhì)量管理和軟件配置管理。

為了在用戶和處理用戶需求的軟件項目組之間達(dá)成共識（用戶由最終用戶、高層領(lǐng)導(dǎo)、銷售人員和市場調(diào)研人員組成），“軟件需求規(guī)格說明書”是必不可少的。經(jīng)過正式的評審和確認(rèn)，其將成為后續(xù)工作的基礎(chǔ)。

軟件項目的實(shí)施過程是根據(jù)軟件項目的資源、約束條件和執(zhí)行能力確定的，因此需要制定合理的軟件工程管理計劃，這是項目經(jīng)理的職責(zé)之一。項目經(jīng)理應(yīng)定期檢查“項目開發(fā)計劃書”，按照當(dāng)前項目開發(fā)的實(shí)際情況，對其進(jìn)行調(diào)整。

為了保證每一個軟件產(chǎn)品都合乎需求，需要設(shè)立一個負(fù)責(zé)項目監(jiān)督和協(xié)調(diào)的SQA。其會對軟件產(chǎn)品是否符合定義好的軟件過程中的相應(yīng)部分進(jìn)行審查、復(fù)審和測試。公司高層主管應(yīng)該定期參與、評審SQA的活動。

軟件配置管理是指在整個工程期間對項目的所有軟件配置項進(jìn)行規(guī)范化管理。如采用版本控制軟件對軟件配置項版本進(jìn)行版本控制，采用基線管理方法對變化進(jìn)行控制，即在遵循軟件工程標(biāo)準(zhǔn)的基礎(chǔ)上對整個軟件進(jìn)行控制和管理，維護(hù)其完整性、一致性和可跟蹤性。

瑞星努力營造的是一個廣泛的網(wǎng)絡(luò)，研發(fā)、制造、銷售、分銷和服務(wù)，連續(xù)進(jìn)行。圍繞著產(chǎn)品、市場和開發(fā)階段而不是單純的技術(shù)來組織各項工作。為了這個目的，標(biāo)準(zhǔn)操作是必不可少的。


附錄：開思公司《產(chǎn)品部開發(fā)規(guī)范》　（摘要）

說明：第一部分為《目錄》，從中可以看出開思公司《產(chǎn)品部開發(fā)規(guī)范》的整體架構(gòu)；第二部分為《開發(fā)規(guī)范概述》，從中可以看出開思公司在軟件項目管理方面的一些具體做法。

1　　目　錄

1　目的

2　開發(fā)規(guī)范概述

2．1　應(yīng)用項目管理管理開發(fā)過程

2．2　標(biāo)準(zhǔn)的階段性開發(fā)工作

2．2．1　總體規(guī)劃

2．2．2　項目立項

2．2．3　需求分析

2．2．4　系統(tǒng)分析

2．2．5　系統(tǒng)設(shè)計

2．2．6　編碼實(shí)現(xiàn)

2．2．7　項目測試

2．2．8　文檔制作

2．2．9　項目驗收

2．2．10　項目版本化發(fā)布

2．3　項目組織

3　開發(fā)工作規(guī)范

3．1　總體規(guī)劃階段

3．1．1　項目需求報告

3．1．1．1　工作定義

3．1．1．2　前序工作及輸入成果

3．1．1．3　具體工作內(nèi)容

3．1．1．3．1　資料收集（可選）

3．1．1．3．2　資料研究（可選）

3．1．1．3．3　項目需求報告編制

3．1．1．3．4項目需求報告討論準(zhǔn)備

3．1．1．3．5　項目需求報告討論

3．1．1．3．6　項目需求報告修改

3．1．1．3．7　項目需求報告驗收

3．1．1．4　參與者及職責(zé)

3．1．1．5　輸出成果及后序工作

3．1．2　技術(shù)可行性實(shí)驗（可選）

3．1．3　項目計劃書

3．2　項目立項

3．2．1　立項申請

3．2．2　項目立項評估

3．2．3　項目進(jìn)度計劃

3．2．4　項目立項審批

3．3　需求分析

3．3．1　資料收集

3．3．2　需求分析編制

3．3．3　討論準(zhǔn)備

3．3．4　需求分析討論

3．3．5　需求分析修改

3．3．6　需求分析驗收

3．4　系統(tǒng)分析

3．4．1　系統(tǒng)分析準(zhǔn)備

3．4．2　確定問題域

3．4．3　需求建模

3．4．4　建立分析對象模型

3．4．5　系統(tǒng)分析合并

3．4．6　系統(tǒng)分析測試

3．4．7　系統(tǒng)分析修改（測試后）

3．4．8　系統(tǒng)分析驗收

3．5　系統(tǒng)設(shè)計

3．5．1　系統(tǒng)設(shè)計準(zhǔn)備

3．5．2　界面設(shè)計

3．5．3　建立設(shè)計模型

3．5．4　系統(tǒng)設(shè)計合并

3．5．5　對象持久化設(shè)計

3．5．6　詳細(xì)設(shè)計

3．5．7　系統(tǒng)設(shè)計測試

3．5．8　系統(tǒng)設(shè)計修改（測試后）

3．5．9　系統(tǒng)設(shè)計驗收

3．6　編碼實(shí)現(xiàn)

3．6．1　編碼準(zhǔn)備

3．6．2　編碼

3．6．3　編碼單元測試（測試工作）

3．6．4　單元測試后編碼修改

3．6．5　編碼聯(lián)調(diào)

3．6．6　集成測試（測試工作）

3．6．7　集成測試后編碼修改

3．6．8　系統(tǒng)測試（測試工作）

3．6．9　系統(tǒng)測試后編碼修改

3．6．10　編碼驗收

3．7　項目測試

3．7．1　系統(tǒng)分析測試

3．7．2　系統(tǒng)設(shè)計測試

3．7．3　項目測試方案

3．7．4　單元測試

3．7．5　集成測試

3．7．6　系統(tǒng)測試

3．8　文檔編制

3．8．1　開發(fā)文檔整理

3．8．2　用戶文檔編制

3．8．3　宣傳資料編寫

3．9　項目驗收

3．10　項目版本化發(fā)布

4　項目工作總結(jié)

4．1　項目任務(wù)數(shù)

4．1．1　總?cè)蝿?wù)數(shù)

4．1．2　階段任務(wù)數(shù)

4．2　輸出成果

2　　開發(fā)規(guī)范概述

2．1　應(yīng)用項目管理管理開發(fā)過程

產(chǎn)品部接受的各種開發(fā)任務(wù)均以項目形式出現(xiàn)，包括：新產(chǎn)品開發(fā)，產(chǎn)品維護(hù)（錯誤修改、功能增強(qiáng)、缺陷完善等），產(chǎn)品客戶化開發(fā)及維護(hù)等，全程使用項目管理方法進(jìn)行控制和管理。

根據(jù)項目規(guī)模和難易有大、小，繁簡之分。每個項目的完成周期要控制在6個月以內(nèi)，項目規(guī)模控制在60個人月內(nèi)。過大的項目需要拆分成多個小的項目來完成。30個人月以上的項目稱為大項目，10個人月以內(nèi)的項目稱為小項目。

每個項目要根據(jù)具體情況拆分成工作階段，即里程碑，以便對項目進(jìn)度的有效控制與檢測。

2．2　標(biāo)準(zhǔn)的階段性開發(fā)工作

2．2．1　總體規(guī)劃

全面規(guī)劃項目工作的內(nèi)容，確定目標(biāo)市場、技術(shù)指標(biāo)和應(yīng)用要求，劃定項目工作范圍和交付成果，明確項目實(shí)現(xiàn)的總體設(shè)想和實(shí)施方案；確定項目中的新技術(shù)的可行性；明確項目需要用到的各種資源，估算項目的工作量和成本。

2．2．2　項目立項

產(chǎn)品部對要進(jìn)行的開發(fā)項目進(jìn)行立項申請，提交項目資料。由公司的有關(guān)人員對項目進(jìn)行一系列的風(fēng)險評估。

通過風(fēng)險評估的項目，由產(chǎn)品部進(jìn)行詳細(xì)進(jìn)度計劃安排，落實(shí)時間進(jìn)度、資源（人員／設(shè)備、內(nèi)部／外部）、技術(shù)、資金和費(fèi)用等，相關(guān)資源和資金使用計劃要詳細(xì)列出。

最后所有的項目申請資料、風(fēng)險評估報告及產(chǎn)品進(jìn)度計劃都要報給公司上級領(lǐng)導(dǎo)審批，進(jìn)行立項評審。

立項通過的項目才能進(jìn)入正式的開發(fā)工作。

2．2．3　需求分析

根據(jù)項目需求報告界定的工作范圍和應(yīng)用方案的設(shè)計思路，進(jìn)一步深入細(xì)化應(yīng)用方案，描述將要開發(fā)出計算機(jī)系統(tǒng)中包含的各項業(yè)務(wù)是如何做的，及業(yè)務(wù)流程、相關(guān)理論、運(yùn)算公式、原理、業(yè)務(wù)數(shù)據(jù)、單據(jù)報表格式等。

2．2．4　系統(tǒng)分析

根據(jù)項目需求分析，對將要建立的滿足用戶需求的計算機(jī)系統(tǒng)進(jìn)行分析。在系統(tǒng)分析過程中采用面向?qū)ο蠓治黾夹g(shù)（OOA）劃分需求的問題域，對每一個問題域進(jìn)行分析和抽象，對其中的事物和它們之間的關(guān)系產(chǎn)生正確的認(rèn)識，找出描述問題域及其系統(tǒng)責(zé)任所需的類及對象，定義這些類和對象的屬性與服務(wù)，以及它們之間所形成的結(jié)構(gòu)、靜態(tài)聯(lián)系和動態(tài)聯(lián)系。最終產(chǎn)生一個符合用戶需求，并能夠直接反映問題域和系統(tǒng)責(zé)任的面向?qū)ο蟮姆治瞿Ｐ汀?

2．2．5　系統(tǒng)設(shè)計

根據(jù)項目需求分析和系統(tǒng)分析，針對具體實(shí)現(xiàn)中的人機(jī)界面、數(shù)據(jù)存儲、任務(wù)管理等內(nèi)容，運(yùn)用面向?qū)ο笤O(shè)計技術(shù)（OOD）進(jìn)行系統(tǒng)設(shè)計。主要包括UI設(shè)計、對象設(shè)計和數(shù)據(jù)庫表設(shè)計。

2．2．6　編碼實(shí)現(xiàn)

根據(jù)系統(tǒng)設(shè)計的結(jié)果，運(yùn)用面向?qū)ο蟮姆椒ㄟM(jìn)行程序編碼（OOP）以實(shí)現(xiàn)系統(tǒng)設(shè)計的內(nèi)容。

編碼過程就是用具體的數(shù)據(jù)結(jié)構(gòu)來定義對象的屬性，用具體的語言來實(shí)現(xiàn)服務(wù)流程圖所表示的算法。在對象設(shè)計階段形成的對象類和關(guān)系最后被轉(zhuǎn)換成特殊的程序設(shè)計語言、數(shù)據(jù)庫或者硬件的實(shí)現(xiàn)。

2．2．7　項目測試

對系統(tǒng)分析、系統(tǒng)設(shè)計、程序編碼等運(yùn)用面向?qū)ο蟮姆椒ㄟM(jìn)行測試（OOT）。項目的測試工作貫穿項目的整個開發(fā)過程。主要包括：分析（OOA）測試、設(shè)計（OOD）測試和編碼（OOP）測試，以及集成測試和系統(tǒng)測試。

2．2．8　文檔制作

跟隨項目開發(fā)過程應(yīng)產(chǎn)生的文檔主要包括三類：

（1）開發(fā)文檔：分析、設(shè)計、編碼、測試以及各種開發(fā)管理文檔等資料；

（2）用戶文檔：在線幫助，安裝指南，使用手冊，技術(shù)手冊，培訓(xùn)教材等；

（3）宣傳資料：產(chǎn)品介紹資料，產(chǎn)品白皮書，產(chǎn)品宣傳PPT，演示光盤等。

2．2．9　項目驗收

對完工的項目按照驗收步驟進(jìn)行驗收。驗收過程中對項目的情況給予評價。

2．2．10　項目版本化發(fā)布

對驗收通過的項目進(jìn)行版本控制，整理項目版本包含的內(nèi)容并版本化，發(fā)布產(chǎn)品發(fā)布通告。

2．3　項目組織

每個項目指定一個項目經(jīng)理進(jìn)行管理，同時指定一個分析、設(shè)計人員（來自分析設(shè)計組）負(fù)責(zé)對技術(shù)問題的管理。當(dāng)任務(wù)涉及到多個職能組的工作時（有些項目可能只涉及單一的職能組），由項目經(jīng)理根據(jù)項目工作安排與職能組的組長進(jìn)行協(xié)調(diào)，由職能組的組長來協(xié)助安排本組承擔(dān)的項目工作，指定組內(nèi)人員來完成相關(guān)工作。項目經(jīng)理根據(jù)各職能組長的安排匯總編制整個項目的進(jìn)度計劃，并根據(jù)最終形成的項目計劃對項目進(jìn)行控制和管理。

項目進(jìn)行過程中需按照項目管理的要求對項目進(jìn)行跟蹤、總結(jié)，各職能組的人員要對這些工作給予積極的支持和配合。產(chǎn)品委員會（或產(chǎn)品部內(nèi)部）不定期組織人員對項目進(jìn)行審查，確保項目的進(jìn)度和質(zhì)量。

項目完工后需要由產(chǎn)品委員會組織對項目進(jìn)行驗收。

________________________________________

主頁 論壇 留言 打印 聯(lián)系






實(shí)施軟件質(zhì)量保障體系CMM/TSP/PSP的建議
　
　　軟件產(chǎn)業(yè)的發(fā)展，在經(jīng)歷了從70年代開始以結(jié)構(gòu)化分析與設(shè)計、結(jié)構(gòu)化評審、結(jié)構(gòu)化程序設(shè)計以及結(jié)構(gòu)化測試為特征的結(jié)構(gòu)化生產(chǎn)時代，到90年代中期，以CMM模型的成熟模型和日益為市場接受為標(biāo)志，已經(jīng)進(jìn)入以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標(biāo)志的以過程為中心的時代，而軟件發(fā)展第三個時代，及軟件工業(yè)化生產(chǎn)時代，從90年代中期軟件過程技術(shù)的成熟和面向?qū)ο蠹夹g(shù)、構(gòu)件技術(shù)的發(fā)展為基礎(chǔ)，已經(jīng)漸露端倪，估計到2005年，可以實(shí)現(xiàn)真正的軟件工業(yè)化生產(chǎn)，這個趨勢應(yīng)該引起軟件企業(yè)界和有關(guān)部門的高度重視，及早采取措施，跟上世界軟件發(fā)展的腳步。軟件生產(chǎn)轉(zhuǎn)向以改善軟件過程為中心，是世界各國軟件產(chǎn)業(yè)或遲或早都要走的道路。軟件過程改善是當(dāng)前軟件開發(fā)技術(shù)的核心問題。
　　　--------摘自北京航空航天大學(xué)軟件工程研究所周伯生教授的《CMM評估基本要點(diǎn)及最新動態(tài)》學(xué)術(shù)報告

引言

　　50多年來計算事業(yè)的發(fā)展使人們認(rèn)識到要高效率、高質(zhì)量和低成本地開發(fā)軟件，必須改善軟件生產(chǎn)過程。軟件生產(chǎn)轉(zhuǎn)向以改善軟件過程為中心，是世界各國軟件產(chǎn)業(yè)或遲或早都要走的道路。軟件工業(yè)已經(jīng)或正在經(jīng)歷著"軟件過程的成熟化"，并向"軟件的工業(yè)化"漸進(jìn)過渡。規(guī)范的軟件過程是軟件工業(yè)化的必要條件。
　　軟件過程研究的是如何將人員、技術(shù)和工具等組織起來，通過有效的管理手段，提高軟件生產(chǎn)的效率，保證軟件產(chǎn)品的質(zhì)量。

軟件過程的理論研究與實(shí)踐成果
n 國際
n 國內(nèi)
國 際
軟件過程的三個流派：
CMU-SEI的CMM/PSP/TSP
SO 9000質(zhì)量標(biāo)準(zhǔn)體系
SO/IEC 15504（SPICE）

CMU-SEI的CMM/PSP/TSP

　　20世紀(jì)80年代中期國際軟件產(chǎn)業(yè)界對軟件的研究十分重視，因為在采用軟件工程方法克服軟件危機(jī)的過程中，人們認(rèn)識到，軟件是否完善是軟件風(fēng)險大小的決定因素。這方面的研究取得了重大的突破，其標(biāo)志是1987年美國 Carnegie Mellon 大學(xué)軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發(fā)表的研究成果"承制方軟件工程能力的評估方法"，該成果在1991年發(fā)展成為CMM（軟件過程能力成熟度模型）。軟件過程能力成熟度模型被國際軟件界公認(rèn)為軟件工程學(xué)的一項重大成果。軟件目前，軟件能力成熟度模型2.0版已經(jīng)修訂問世。CMM在軟件工程的實(shí)踐方面已有很大的影響，在工業(yè)界已得到廣泛接受。不僅已用于軍事控制系統(tǒng)，而且已用于全球經(jīng)濟(jì)領(lǐng)域的主要組織。有數(shù)千個組織在利用CMM的軟件過程改進(jìn)。在美國，關(guān)于CMM模型的教程已經(jīng)作為參考和研究的對象出現(xiàn)了，這樣做是為了讓CMM模型極其相關(guān)問題引起工業(yè)界的更密切地關(guān)注。基于CMM模型的工具如成熟度問題集，軟件過程評估訓(xùn)練和軟件能力評價訓(xùn)練已經(jīng)在CMM中漸漸得到修訂。近期的關(guān)于CMM的活動主要是發(fā)展關(guān)于CMM模型的不同版本。由于CMM并未提供有關(guān)實(shí)現(xiàn)CMM關(guān)鍵過程域所需的具體知識和技能，因此，美國 Carnegie Mellon 大學(xué)軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發(fā)了個體軟件過程PSP（Personal software process）和群組軟件過程TSP(Team Software Process)，形成CMM/PSP/TSP體系。

ISO 9000質(zhì)量標(biāo)準(zhǔn)體系
　　最初的軟件質(zhì)量保證系統(tǒng)是在70年代由歐洲首先采用的，其后在美國和世界其他地區(qū)也迅速地發(fā)展起來。目前，歐洲聯(lián)合會積極促進(jìn)軟件質(zhì)量的制度化，提出了如下ISO9000軟件標(biāo)準(zhǔn)系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002。這一系列現(xiàn)已成為全球的軟件質(zhì)量標(biāo)準(zhǔn)。除了ISO9000標(biāo)準(zhǔn)系列外，許多工業(yè)部門、國家和國際團(tuán)體也頒布了特定環(huán)境中軟件運(yùn)行和維護(hù)的質(zhì)量標(biāo)準(zhǔn)，如：IEEE標(biāo)準(zhǔn)729-1983、730-1984、Euro Norm EN45012等。

ISO/IEC 15504（SPICE）

　　CMM的方法很快就引起了軟件界的廣泛關(guān)注，1991年國際標(biāo)準(zhǔn)化組織采納了一項動議，開展調(diào)查研究，在此后引發(fā)了一系列的研究工作，現(xiàn)已取得重要成果，產(chǎn)生了技術(shù)報告ISO/IEC 15504《信息技術(shù)-軟件過程評估》，預(yù)計于今年產(chǎn)生正式標(biāo)準(zhǔn)。從該技術(shù)報告的內(nèi)容來看，其基本的目的和思路，均與CMU/SEI的CMM相似。
　　目前，學(xué)術(shù)界和工業(yè)界公認(rèn)美國 Carnegie Mellon 大學(xué)軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發(fā)的軟件能力成熟度模型CMM是當(dāng)前最好的軟件過程，已成為業(yè)界事實(shí)上的軟件過程的工業(yè)標(biāo)準(zhǔn)。

國 內(nèi)

　　學(xué)術(shù)界：中國生產(chǎn)力促進(jìn)協(xié)會、北航SEI、中科院研究SEI等科研機(jī)構(gòu)已于近幾年在北京、上海、廣州和深圳等地先后舉辦過多次報告會和研討會，組織過課程學(xué)習(xí)和應(yīng)用實(shí)驗，開展了軟件過程方面的研究與開發(fā)工作，并發(fā)表了多篇的研究成果和學(xué)術(shù)論文，在軟件質(zhì)量保障平臺支撐環(huán)境也取得了一定的成果。
　　產(chǎn)業(yè)界：近兩年來，CMM在我國獲得了各界越來越多關(guān)注，業(yè)界有過多次關(guān)于CMM的討論，國務(wù)院發(fā)布的《鼓勵軟件產(chǎn)業(yè)和集成電路產(chǎn)業(yè)發(fā)展的若干政策》對中國軟件企業(yè)申請CMM認(rèn)證給予了積極的支持，在第17條規(guī)定"對軟件出口型企業(yè)CMM認(rèn)證費(fèi)用予以適當(dāng)支持。"2000年中國村電腦節(jié)上還有CMM專題論壇，吸引了眾多業(yè)內(nèi)人士。鼎新、東大阿爾派、聯(lián)想、方正、金蝶、用友、浪潮、創(chuàng)智、華為、東大阿爾派等大型集團(tuán)或企業(yè)等都從1997---2000年起批企業(yè)都在進(jìn)行研究、實(shí)驗或?qū)嵤╊A(yù)評估。其中鼎新公司從1997年著手進(jìn)行CMM認(rèn)證工作。1999年7月通過第三方認(rèn)證機(jī)構(gòu)的CMM2認(rèn)證。東大阿爾派公司于2000年10月通過第三方認(rèn)證機(jī)構(gòu)的CMM2認(rèn)證。2001年1月，聯(lián)想軟件經(jīng)過英國路透集團(tuán)的嚴(yán)格評估，順利通過CMM2認(rèn)證。
　　總體上講，國內(nèi)對軟件過程理論的討論與實(shí)踐正在展開，目標(biāo)是使軟件的質(zhì)量管理和控制達(dá)到國際先進(jìn)水平，中國的軟件產(chǎn)業(yè)獲得可持續(xù)發(fā)展的能力。專家分析，在未來兩三年內(nèi)，國內(nèi)軟件業(yè)勢必將出現(xiàn)實(shí)施CMM的高潮。從這一趨勢看，中國的軟件企業(yè)已經(jīng)開始走上標(biāo)準(zhǔn)化、規(guī)范化、國際化的發(fā)展道路，中國軟件業(yè)已經(jīng)面臨一個整體突破的時代。
軟件質(zhì)量保障體系的實(shí)施
　　根據(jù)一直以來對國際上軟件過程理論與實(shí)踐的發(fā)展、尤其是近幾年來著重在CMM、PSP和TSP以及ISO軟件過程標(biāo)準(zhǔn)草案等方面的研究工作，國內(nèi)專家學(xué)者建議，軟件過程的改善應(yīng)該從三方面著手進(jìn)行：
　　o 軟件能力成熟度模型CMM(Capability Maturity Model)
　　o 個體軟件過程PSP (Personal Software Process)
　　o 群組軟件過程TSP(Team Software Process)
三者各有側(cè)重，但互為補(bǔ)充。

CMM

　　o 迄今為止學(xué)術(shù)界和工業(yè)界公認(rèn)的有關(guān)軟件工程和管理實(shí)踐的最好的軟件過程。
　　o 為評估軟件組織的生產(chǎn)能力提供了標(biāo)準(zhǔn)。
　　o 為提高軟件組織的生產(chǎn)過程指明了方向。

CMM軟件過程成熟度模型概要*

1、 比較
　　
　　在介紹CMM內(nèi)容之前，首先概述一下不成熟軟件組織與成熟軟件組織的差異。在不成熟的軟件單位，軟件過程一般由實(shí)踐者及其管理者在項目進(jìn)程中臨時拼湊而成，因而推遲進(jìn)度和超出預(yù)算已成為慣例，產(chǎn)品質(zhì)量難以預(yù)測，有時為了滿足進(jìn)度要求，常在產(chǎn)品功能和質(zhì)量上做出讓步。
　　然而，一個成熟軟件組織具有在全組織范圍內(nèi)管理軟件、開發(fā)過程和維護(hù)過程的能力，規(guī)定的軟件過程被正確無誤地通知到所有員工，工作活動均按照已規(guī)劃的過程進(jìn)行。并通過可控的先導(dǎo)性試驗和費(fèi)效分析使這些過程得到改進(jìn)，對已定義過程中的所有崗位及其職責(zé)都有清楚的描述，和通過文檔與培訓(xùn)使全組織有關(guān)人員對已定義的軟件過程都有很好的理解，從而使其軟件過程所導(dǎo)致的生產(chǎn)率和質(zhì)量能隨時間的推移得到改進(jìn)。
　　表1給出了不成熟和成熟軟件組織的比較，這種比較分析不僅是形成軟件能力成熟模型的基礎(chǔ)，也有利于理解該模型。
　　　
2、 CMM的一些基本概念

　?。?）軟件過程：人們用于開發(fā)和維護(hù)軟件及其相關(guān)過程的一系列活動，包括軟件工程活動和軟件管理活動。
　?。?）軟件過程能力：描述（開發(fā)組織或項目組）遵循其軟件過程能夠?qū)崿F(xiàn)預(yù)期結(jié)果的程度，它既可對整個軟件開發(fā)組織而言，也可對一個軟件項目而言。
　?。?）軟件過程性能：表示（開發(fā)組織或項目組）遵循其軟件過程所得到的實(shí)際結(jié)果，軟件過程性能描述的是已得到的實(shí)際結(jié)果，而軟件過程能力則描述的是最可能的預(yù)期結(jié)果，它既可對整個軟件開發(fā)組織而言，也可對一個特定項目而言。
　　（4）軟件過程成熟：一個特定軟件過程被明確和有效地定義，管理測量和控制的程度。
　?。?）軟件能力成熟度等級：軟件開發(fā)組織在走向成熟的途中幾個具有明確定義的表示軟件過程能力成熟度的平臺。
　?。?）關(guān)鍵過程域：每個軟件能力成熟度等級包含若干個對該成熟度等級至關(guān)重要的過程域，它們的實(shí)施對達(dá)到該成熟度等級的目標(biāo)起到保證作用。這些過程域就稱為該成熟度等級的關(guān)鍵過程域，反之有非關(guān)鍵過程域是指對達(dá)到相應(yīng)軟件成熟度等級的目標(biāo)不起關(guān)鍵作用。歸納為：互相關(guān)聯(lián)的若干軟件實(shí)踐活動和有關(guān)基礎(chǔ)設(shè)施的一個集合。
　　（7）關(guān)鍵實(shí)踐：對關(guān)鍵過程域的實(shí)踐起關(guān)鍵作用的方針、規(guī)程、措施、活動以及相關(guān)基礎(chǔ)設(shè)施的建立。關(guān)鍵實(shí)踐一般只描述"做什么"而不強(qiáng)制規(guī)定"如何做"。整個軟件過程的改進(jìn)是基于許多小的、漸進(jìn)的步驟，而不是通過一次革命性的創(chuàng)新來實(shí)現(xiàn)的，這些小的漸進(jìn)步驟就是通過一些著關(guān)鍵實(shí)踐來實(shí)現(xiàn)。
　?。?）軟件能力成熟度模型：隨著軟件組織定義、實(shí)施、測量、控制和改進(jìn)其軟件過程，軟件組織的能力也伴隨著這些階段逐步前進(jìn)，完成對軟件組織進(jìn)化階段的描述模型。
　
3、 CMM模型概要

　　軟件開發(fā)的風(fēng)險之所以大，是由于軟件過程能力低，其中最關(guān)鍵的問題在于軟件開發(fā)組織不能很好地管理其軟件過程，從而使一些好的開發(fā)方法和技術(shù)起不到預(yù)期的作用。而且項目的成功也是通過工作組的杰出努力，所以僅僅建立在可得到特定人員上的成功不能為全組織的生產(chǎn)和質(zhì)量的長期提高打下基礎(chǔ)，必須在建立有效的軟件工程實(shí)踐和管理實(shí)踐的基礎(chǔ)設(shè)施方面，堅持不懈地努力，才能不斷改進(jìn)，才能持續(xù)地成功。
　　CMM提供了一個框架，將軟件過程改進(jìn)的進(jìn)化步驟組織成5個成熟等級，為過程不斷改進(jìn)奠定了循序漸進(jìn)的基礎(chǔ)。這5個成熟度等級定義了一個有序的尺度，用來測量一個組織的軟件過程成熟和評價其軟件過程能力，這些等級還能幫助組織自己對其改進(jìn)工作排出優(yōu)生次序。成熟度等級是已得到確切定義的，也是在向成熟軟件組織前進(jìn)途中的平臺。每一個成熟度等級為連續(xù)改進(jìn)提供一個臺基。每一等級包含一組過程目標(biāo)，通過實(shí)施相應(yīng)的一組關(guān)鍵過程域達(dá)到這一組過程目標(biāo)，當(dāng)目標(biāo)滿足時，能使軟件過程的一個重要成分穩(wěn)定。每達(dá)到成熟框架的一個等級，就建立起軟件過程的一個相應(yīng)成分，導(dǎo)致組織能力一定程度的增大。
　　下面表2給出了CMM模型概要，表中的5個等級各有其不同的行為特征。要通過描述不同等級組織的行為特征：即一個組織為建立或改進(jìn)軟件過程所進(jìn)行的活動，對每個項目所進(jìn)行的活動和所產(chǎn)生的橫跨各項目的過程能力。
　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　表2 CMM模型概要
　
　　

4、 CMM的結(jié)構(gòu)

　　
　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　
　　軟件機(jī)構(gòu)的最終質(zhì)量保證模式可以用下圖1說明，圖1給出軟件質(zhì)量計劃、質(zhì)量控制、質(zhì)量改進(jìn)一個簡單循環(huán)，其實(shí)，它歸納出CMM的真正內(nèi)核，所以，可以說CMM的模型是一種新興管理思想：連續(xù)改進(jìn)（Continuos Improvement）循環(huán)的體現(xiàn)。
　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　圖1
CMM的作用

　　n 科學(xué)地評價軟件開發(fā)單位的軟件能力成熟等級
　　n 幫助軟件開發(fā)單位進(jìn)行自檢，了解自己的強(qiáng)項和弱項，從而不斷完善和改進(jìn)單位的軟件開發(fā)過程，確保軟件質(zhì)量，提高軟件開發(fā)能效率。
CMM實(shí)施的思考
　　根據(jù)CMM的基本原理、基本內(nèi)容和基本方法，對CMM提出4個問題供大家思考：
　　1. 過程成熟度需要多長時間？多少費(fèi)用？對企業(yè)有何好處？
　　2. 影響基于CMM的軟件過程的成敗因素是什么？
　　3. CMM是否會導(dǎo)致過度官僚主義？是否會使組織變得更保守，不愿冒風(fēng)險？
　　4. 有無合適的、易理解的框架（不僅僅是告訴"我們做什么"，而且告訴"我們怎么做"）可指導(dǎo)所有軟件組織進(jìn)行CMM改進(jìn)？
　　這些針對CMM提出的問題與爭論，國外進(jìn)行了一些調(diào)查工作，但國內(nèi)基本上沒有這方面的專業(yè)調(diào)查和研究，以后再根據(jù)國內(nèi)企業(yè)對CMM的認(rèn)識、認(rèn)證的增強(qiáng)和增多，這些問題會得到更科學(xué)的解答。
　　現(xiàn)給出國外針對上述問題的一些調(diào)查結(jié)果：
　　問題1：成熟度提升一級建議安排1年到2年，費(fèi)用問題國內(nèi)外相距太遠(yuǎn)不好比較。對企業(yè)的好處問題給出下表說明：
　　　　　　
　　問題2：影響過程改進(jìn)失敗的因素有：無法實(shí)施計劃和跟蹤、突發(fā)事件或危險造成、時間和資源限制造成、知道應(yīng)該做什么而不知道如何做造成。
　　問題3：大部分（84%-96%）不認(rèn)為會使組織變成官僚主義機(jī)構(gòu)、難于創(chuàng)新和不敢冒風(fēng)險。
　　問題4：這需要不斷總結(jié)經(jīng)驗，提出辦法。
　　在國內(nèi)要想取得過程改進(jìn)成功，作者認(rèn)為：
　　1、 軟件過程改進(jìn)必須有高級主管的支持與委托，并積極地管理過程改進(jìn)的進(jìn)展。
　　2、 中層管理的支持很重要
　　3、 責(zé)任分明，過程改進(jìn)小組威望高
　　4、 基層的支持與參與極端重要
　　5、 如何利用定量的可觀察數(shù)據(jù)，盡快使過程改進(jìn)成果可見，從而激勵參與者的興趣
　　6、 為企業(yè)的商業(yè)利益服務(wù)，并要求有成功的過程改進(jìn)相符的企業(yè)文化變革
　　如果企業(yè)出現(xiàn)如下情況，過程改進(jìn)肯定就失?。?br> 　　1、 高層領(lǐng)導(dǎo)機(jī)構(gòu)態(tài)度不明確，見解不一致
　　2、 各部門只管自己，互不通氣，互不支持
　　3、 對以前不成功的過程改進(jìn)冷嘲熱諷
　　4、 項目成員認(rèn)為軟件過程改進(jìn)會影響實(shí)際工作，而不支持軟件過程改進(jìn)活動
　　結(jié)論：CMM不是萬能的，它的成功與否，與一個組織內(nèi)部有關(guān)人員的積極參與和創(chuàng)造性活動是密不可分的。
　　CMM是對軟件工程的工業(yè)實(shí)踐所需的有關(guān)目標(biāo)、方法和實(shí)踐的最佳有效描述。問題是如何在一個實(shí)驗室或者產(chǎn)業(yè)環(huán)境中做到CMM規(guī)則的應(yīng)用？
　　CMM是一個致力于組織過程改進(jìn)的框架，問題是如何才能確保CMM使工作有效而且便利？
　　未提供有關(guān)實(shí)現(xiàn)關(guān)鍵過程域所需要的具體知識和技能。
　　因此，個體軟件過程PSP(Personal Software Process)也就應(yīng)運(yùn)而生。

PSP概述
　　個體軟件過程（Personal Software Process ,PSP）是由美國Carnegie Mellon大學(xué)軟件工程研究所(CMU/SEI)的Watts s. Humphrey領(lǐng)導(dǎo)開發(fā)的，于1995年它的推出，在軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個標(biāo)志。PSP是一種可用于控制、管理和改進(jìn)個人工作方式的自我改善過程，是一個包括軟件開發(fā)表格、指南和規(guī)程的結(jié)構(gòu)化框架。 PSP為基于個體和小型群組軟件過程的優(yōu)化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質(zhì)量，如何與其他人相互協(xié)作等等。在軟件設(shè)計階段， PSP的著眼點(diǎn)在于軟件缺陷的預(yù)防，其具體辦法是強(qiáng)化設(shè)計結(jié)束準(zhǔn)則，而不是設(shè)計方法的選擇。根據(jù)對參加培訓(xùn)的104位軟件人員的統(tǒng)計數(shù)據(jù)表明，在應(yīng)用了PSP后，軟件中總的差錯減少了58.0％，在測試階段發(fā)現(xiàn)的差錯減少了71.0％，生產(chǎn)效率提高了20.0％。PSP的研究結(jié)果還表明，絕大多數(shù)軟件缺陷是由于對問題的錯誤理解或簡單的失誤所造成的，只有很少一部分是由于技術(shù)問題而產(chǎn)生的。而且根據(jù)多年來的軟件工程統(tǒng)計數(shù)據(jù)表明，如果在設(shè)計階段注入一個差錯，則這個差錯在編碼階段引發(fā)了3一5個新的缺陷，要修復(fù)這些缺陷所花的費(fèi)用要比修復(fù)這個設(shè)計缺陷所花的費(fèi)用多一個數(shù)量級。因此，PSP保障軟件產(chǎn)品質(zhì)量的一個重要途徑是提高設(shè)計質(zhì)量。
個體軟件過程PSP的現(xiàn)狀

o 從1993年開始，美國、歐洲、澳大利亞等地已先后有20多所大學(xué)開設(shè)了講授PSP的課程。
o 在工業(yè)界，PSP也先后在Motorola、 HP、 AIS等公司推廣使用。
o 北航軟件工程研究所于1997年開始，在北航計算機(jī)科學(xué)與工程系率先講授了PSP課程，并組織了PSP應(yīng)用實(shí)驗。
個體軟件過程PSP的演化*

　　　　　　　　　　　
　
　
　
　
　
　
　
　
　
　
　

個體軟件過程PSP的內(nèi)容
　　PSP與具體的技術(shù)（程序設(shè)計語言、工具或者設(shè)計方法）相對獨(dú)立，其原則能夠應(yīng)用到幾乎任何的軟件工程任務(wù)之中。PSP能夠：
(1) 說明個體軟件過程的原則；
(2) 幫助軟件工程師作出準(zhǔn)確的計劃；
(3) 確定軟件工程師為改善產(chǎn)品質(zhì)量要采取的步驟；
(4) 建立度量個體軟件過程改善的基準(zhǔn)；
(5) 確定過程的改變對軟件工程師能力的影響。
個體軟件過程PSP支持環(huán)境
　　北航軟件工程研究所在研制的基于Internet的"個體軟件過程支持環(huán)境"，支持個體軟件過程的定義、運(yùn)作、度量、分析和優(yōu)化，支持PSP在實(shí)際軟件開發(fā)項目中的應(yīng)用，支持PSP概念和方法的推廣普及，支持軟件工作人員軟件工程方面素質(zhì)的提高。
個體軟件過程PSP的作用
l 使用自底向上的方法來改進(jìn)過程，向每個軟件工程師表明過程改進(jìn)的原則，使他們能夠明白如何有效地生產(chǎn)出高質(zhì)量　的軟件。
l 為基于個體和小型群組軟件過程的優(yōu)化提供了具體而有效的途徑。其研究與實(shí)踐填補(bǔ)了CMM的空白。
l 幫助軟件工程師在個人的基礎(chǔ)上運(yùn)用過程的原則，借助于PSP提供的一些度量和分析工具，了解自己的技能水平，控　制和管理自己的工作方式，使自己日常工作的評估、計劃和預(yù)測更加準(zhǔn)確、更加有效，進(jìn)而改進(jìn)個人的工作表現(xiàn)，提　高個人的工作質(zhì)量和產(chǎn)量，積極而有效地參與高級管理人員和過程人員推動的組織范圍的軟件工程過程改進(jìn)。
群組軟件過程TSP概述
　　致力于開發(fā)高質(zhì)量的產(chǎn)品，建立、管理和授權(quán)項目小組，并且指導(dǎo)他們?nèi)绾卧跐M足計劃費(fèi)用的前提下，在承諾的期限范圍內(nèi)，不斷生產(chǎn)并交付高質(zhì)量的產(chǎn)品。
　　TSP指導(dǎo)項目組中的成員如何有效地規(guī)劃和管理所面臨的項目開發(fā)任務(wù)，并且告訴管理人員如何指導(dǎo)軟件開發(fā)隊伍。始終以最佳狀態(tài)來完成工作。TSP實(shí)施集體管理與自己管理自己相結(jié)合的原則，最終目的在于指導(dǎo)開發(fā)人員如何在最少的時間內(nèi)，以預(yù)定的費(fèi)用生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，所采用的方法是對群組開發(fā)過程的定義、度量和改進(jìn)。
實(shí)現(xiàn)TSP方法需要具備的條件

o 需要有高層主管和各級經(jīng)理的支持，以取得必要的資源
o 整個軟件開發(fā)小組至少應(yīng)在CMM的第二級（可重復(fù)層）。
o 全體軟件開發(fā)人員必須經(jīng)過PSP的培訓(xùn)，并有按TSP工作的愿望和熱情。
o 開發(fā)小組成員應(yīng)在2到20個人之間。
　　在實(shí)施TSP的過程中，首先要有明確的目標(biāo)，開發(fā)人員要努力完成已經(jīng)接受的委托任務(wù)。在每一階段開始，要做好工作計劃。如果發(fā)現(xiàn)未能按期按質(zhì)完成計劃，應(yīng)立即分析原因，以判定問題是由于工作內(nèi)容不合適或工作計劃不實(shí)際所引起，還是由于資源不足或主觀努力不夠所引起。開發(fā)小組一方面應(yīng)隨時追蹤項目進(jìn)展?fàn)顟B(tài)并進(jìn)行定期匯報，另一方面應(yīng)經(jīng)常評審自己是否按PSP的原理工作。開發(fā)小組成員應(yīng)按自己管理自己的原則管理軟件過程，如發(fā)現(xiàn)過程不合適，應(yīng)及時改進(jìn)，以保證用高質(zhì)量的過程來產(chǎn)生高質(zhì)量的軟件。項目開發(fā)小組則按集體管理的原則進(jìn)行管理，全體成員都要參加和關(guān)心小組的規(guī)劃、進(jìn)展的追蹤和決策的制定等項工作。
按TSP原理對開發(fā)小組的基本度量要素

o 所編文檔的頁數(shù)。
o 所編代碼的行數(shù)。
o 花費(fèi)在各開發(fā)階段或各開發(fā)任務(wù)上的時間（以分為單位）。
o 在各個開發(fā)階段中引入和改正的差錯數(shù)目。
o 在各個階段對最終產(chǎn)品增加的價值。
度量TSP實(shí)施質(zhì)量的過程質(zhì)量元素

o 軟件設(shè)計時間應(yīng)大于軟件實(shí)現(xiàn)時間。
o 設(shè)計評審時間至少應(yīng)占一半以上的設(shè)計時間。
o 代碼評審時間至少應(yīng)占一半以上的代碼編制時間。
o 在編譯階段發(fā)現(xiàn)的差錯不超過10個/KLOC
o 在測試階段發(fā)現(xiàn)的差錯不超過5個/KLOC。

CMM、PSP和TSP組成的軟件過程框架

　　　　　　　　　　　　

l CMM是過程改善的第一步，它提供了評價組織的能力、識別優(yōu)先改善需求和追蹤改善進(jìn)展的管理方式。企業(yè)只有開始　CMM改善后，才能接受需要規(guī)劃的事實(shí)，認(rèn)識到質(zhì)量的重要性，才能注重對員工經(jīng)常進(jìn)行培訓(xùn)，合理分配項目人員，　并且建立起有效的項目小組。然而，它實(shí)現(xiàn)的成功與否與組織內(nèi)部有關(guān)人員的積極參加和創(chuàng)造性活動密不可分。
l PSP能夠指導(dǎo)軟件工程師如何保證自己的工作質(zhì)量，估計和規(guī)劃自身的工作，度量和追蹤個人的表現(xiàn)，管理自身的軟　件過程和產(chǎn)品質(zhì)量。經(jīng)過PSP學(xué)習(xí)和實(shí)踐的正規(guī)訓(xùn)練，軟件工程師們能夠在他們參與的項目工作之中充分運(yùn)用PSP，從　而有助于CMM目標(biāo)的實(shí)現(xiàn)。
l TSP結(jié)合了CMM的管理方法和PSP的工程技能，通過告訴軟件工程師如何將個體過程結(jié)合進(jìn)小組軟件過程，并將后者與　組織進(jìn)而整個管理系統(tǒng)相聯(lián)系；通過告訴管理層如何支持和授權(quán)項目小組，堅持高質(zhì)量的工作，并且依據(jù)數(shù)據(jù)進(jìn)行項　目的管理，向組織展示如何應(yīng)用CMM的原則和PSP的技能去生產(chǎn)高質(zhì)量的產(chǎn)品。
PSP和TSP對CMM的支持*
　　　　
l CMM/TSP/PSP代表了目前國際上軟件過程工程研究方面最先進(jìn)的成果，它們對促進(jìn)軟件生產(chǎn)的科學(xué)化管理，提高軟件　生產(chǎn)能力意義重大。
l 軟件的生產(chǎn)過程及其它的許多子過程、軟件的開發(fā)者和用戶、以及系統(tǒng)的使用中存在著巨大的變化和不同，要使一個　軟件過程對軟件生產(chǎn)的改善真正有所幫助，其框架應(yīng)是由CMM、TSP和PSP組成的一個完整體系，即從組織、群組和個　人三個層次進(jìn)行良好的軟件工程和管理實(shí)踐的指導(dǎo)和支持?？偠灾?，單純實(shí)施CMM，永遠(yuǎn)不能真正做到能力成熟度　的升級，只有將實(shí)施CMM與實(shí)施PSP和TSP有機(jī)地結(jié)合起來，才能發(fā)揮最大的效力。
　

建議

　　過程改善工作必然具有一切過程所具有的固有特征，即需要循序漸進(jìn)，不能一蹴而就需要持續(xù)改善，不能停滯不前；需要聯(lián)系實(shí)際，不能照本宣讀需要適應(yīng)變革，不能凝固不變。我認(rèn)為，將CMM／PSP／TSP引人軟件企業(yè)最有效的途徑首先要對單位主管和主要開發(fā)人員進(jìn)行系統(tǒng)的培訓(xùn)。Carnegie Mellon大學(xué)軟件工程研究所曾嘗試讓軟件工程師通過自學(xué)的方式來進(jìn)行，但實(shí)際上，只有不到20％的人能夠堅持到底。另外一個有效的途徑是自頂向下的課程培訓(xùn)，即從高層主管依次普及到下面的工程師。
　　CMM就如同軟件生產(chǎn)的一面鏡子，以之來衡量自己可以折射出企業(yè)發(fā)展的水平以及具體的差距。借鑒CMM的方法，改進(jìn)軟件研發(fā)項目管理，提高軟件開發(fā)水平。軟件研發(fā)項目管理管理是影響軟件研發(fā)項目全局的因素，而技術(shù)只影響局部。建議以CMM為框架，先從PSP做起，然后在此基礎(chǔ)上逐漸過渡到TSP，以保證CMM／PSP／TSP確實(shí)在企業(yè)中生根開花。我相信只要堅持改善軟件工程的管理，并在實(shí)踐中總結(jié)適合自身的經(jīng)驗，一定能取得很好的效果。
　　不過強(qiáng)調(diào)一點(diǎn)，我們必須根據(jù)自身的實(shí)際制定可行的方案。不深入研究就照搬別的企業(yè)的模式是很難起到提高軟件產(chǎn)品質(zhì)量水平的真正目的的。
　
/*
本文來自--
http://www.china-pub.com/computers/eMook/0891/info.htm
中國互動出版網(wǎng)
2001-4-10
*/

________________________________________

主頁 論壇 留言 打印 聯(lián)系






軟件開發(fā)質(zhì)量保證體系
來自lannuo.533.net
________________________________________
1. 使用范圍

2. 引用標(biāo)準(zhǔn)

3. 定義

4. 質(zhì)量體系框架

4.1 管理職責(zé)

4.2 質(zhì)量體系

4.3 評審

4.4 糾正措施

5. 質(zhì)量體系生存周期

5.1 合同評審

5.2 需方需求規(guī)格說明

5.3 開發(fā)計劃

5.4 質(zhì)量計劃

5.5 設(shè)計和實(shí)現(xiàn)

5.6 測試和確認(rèn)

5.7 驗收

5.8 復(fù)制、交付和安裝

5.9 維護(hù)



軟件開發(fā)質(zhì)量保證體系

　

公司內(nèi)部標(biāo)準(zhǔn)

本標(biāo)準(zhǔn)參照ISO9000-3 《質(zhì)量管理和質(zhì)量保證標(biāo)準(zhǔn) 第三部分：在軟件開發(fā)、供應(yīng)和維護(hù)中的使用指南》。

　

1、 使用范圍

本標(biāo)準(zhǔn)作為本公司在軟件項目開發(fā)、供應(yīng)和維護(hù)時的質(zhì)量要求，以保證產(chǎn)品的質(zhì)量，防止不合格產(chǎn)品。

以下詳細(xì)描述了軟件開發(fā)各階段的控制手段和要求。要求質(zhì)量保證貫穿各個階段，始終保證嚴(yán)格實(shí)施。

2、 引用標(biāo)準(zhǔn)

本標(biāo)準(zhǔn)制定考慮本公司的實(shí)際情況，因此本標(biāo)準(zhǔn)僅用于本公司內(nèi)部控制產(chǎn)品質(zhì)量。

使用本文檔時，請盡量參照最新版本。

3、 定義

產(chǎn)品：以下指軟件產(chǎn)品，即交付給用戶的一整套計算機(jī)程序、規(guī)程及相關(guān)的文檔和數(shù)據(jù)。

開發(fā)：創(chuàng)作軟件產(chǎn)品的所有活動。

供方：指本公司。

需方：指具體項目的需求方，即客戶。

質(zhì)量體系：質(zhì)量要素、各要素需要達(dá)到的目標(biāo)以及在開發(fā)過程中必須采取的措施。

　

4、 質(zhì)量體系框架

4.1管理職責(zé)

4.1.1 供方(及具體的項目開發(fā)組)負(fù)責(zé)以下職責(zé)

組織機(jī)構(gòu)
本公司內(nèi)部專門設(shè)立部門質(zhì)量保證部門，由部門負(fù)責(zé)人及專門經(jīng)過培訓(xùn)的人員組成。具體項目開發(fā)組，設(shè)立質(zhì)量保證組，或委托公司質(zhì)量保證部門協(xié)助開展工作。

質(zhì)量保證部門負(fù)責(zé)以下工作：

建立并維護(hù)公司內(nèi)部的質(zhì)量保證體系。
對可能導(dǎo)致產(chǎn)品不合格的問題予以識別，采取措施予以避免。
發(fā)現(xiàn)并記錄產(chǎn)品的質(zhì)量問題。
提出、采取或推薦問題解決辦法。
驗證解決辦法的實(shí)施效果。
對不合格產(chǎn)品的處理、交付過程進(jìn)行控制，確保最終問題得以糾正。
質(zhì)量保證部門的評審活動應(yīng)由與被評審工作無直接責(zé)任的人員組成。

制定質(zhì)量方針和質(zhì)量目標(biāo)
確保項目組成員均理解質(zhì)量方針并能堅持貫徹執(zhí)行。

公司內(nèi)部制定一般性的質(zhì)量方針及對軟件產(chǎn)品的質(zhì)量目標(biāo)，作為各項目組的參照，各項目組可根據(jù)具體客戶期望及需求作出具體質(zhì)量目標(biāo)及質(zhì)量承諾，具體質(zhì)量目標(biāo)及承諾，特別是超出公司目標(biāo)的部分，提交給質(zhì)量保證部門，以便提交給質(zhì)量保證部門充分理解并協(xié)助實(shí)施。

《質(zhì)量方針和質(zhì)量目標(biāo)》見附錄

管理評審
質(zhì)量保證部門負(fù)責(zé)人應(yīng)每月對質(zhì)量體系進(jìn)行評審，主要是對內(nèi)部質(zhì)量審核結(jié)果的評定，以保證質(zhì)量體系持續(xù)有效，保存評審記錄。

4.1.2 需方（客戶）應(yīng)負(fù)的職責(zé)

在項目中，應(yīng)向需方（客戶）提出具體要求，明確其需要承擔(dān)的職責(zé)，以便相互配合，共同保證項目的順利實(shí)施。

需方應(yīng)明確指定項目相關(guān)負(fù)責(zé)人，應(yīng)具有足夠的權(quán)力處理以下問題：
向供方提出需求
回答供方提出的某些相關(guān)問題
認(rèn)可供方的提案
與供方簽訂協(xié)議并能確保遵守簽訂的協(xié)議
規(guī)定驗收準(zhǔn)則和規(guī)程
向供方提供必要的信息,提供有利的環(huán)境并解決項目中一些障礙。
4.1.3 共同評審

雙方定期地交流，并聯(lián)合評審軟件是否滿足已經(jīng)商定的需求規(guī)格說明書。

4.2 質(zhì)量體系

本質(zhì)量體系貫穿整個開發(fā)周期，是為了在開發(fā)過程中保證質(zhì)量，并非在開發(fā)結(jié)束時才檢查質(zhì)量問題，所以重點(diǎn)強(qiáng)調(diào)防止問題地發(fā)生，問題發(fā)生后的糾正僅作為補(bǔ)充手段。

本公司將采取必要手段保證這一體系得以有效地貫徹實(shí)施。

質(zhì)量體系文件
本公司的質(zhì)量體系文件,包括質(zhì)量要素、各要素需要達(dá)到的目標(biāo)以及在開發(fā)過程中必須采取的措施。

質(zhì)量體系文件見附錄《質(zhì)量體系文件》

質(zhì)量計劃
具體項目開發(fā)組根據(jù)公司質(zhì)量體系制訂質(zhì)量活動計劃并形成《質(zhì)量保證計劃》，以保證開發(fā)組能正確理解質(zhì)量體系并能遵照執(zhí)行。

附錄之《質(zhì)量保證計劃指導(dǎo)》作為各項目組制訂計劃的指導(dǎo)。

4.3 審核

本公司內(nèi)部建立全面的審核制度，以驗證各具體項目中的質(zhì)量活動是否符合計劃要求，同時檢查質(zhì)量體系的有效性，以不斷完善質(zhì)量體系。

審核過程及采取的措施均要按書面方式進(jìn)行。

審核結(jié)果形成報告，提交審核部門負(fù)責(zé)人。對于審核時發(fā)現(xiàn)的問題，相關(guān)負(fù)責(zé)人應(yīng)及時采取措施。

4.4 糾正措施

糾正措施必須制定書面規(guī)程，應(yīng)包括以下內(nèi)容：

調(diào)查問題產(chǎn)生的直接原因，并制定防止同類事件發(fā)生所需的措施。
查詢分析各類過程記錄、讓步記錄、操作記錄、質(zhì)量記錄、客戶投訴等等，已查明潛在原因并消除
根據(jù)風(fēng)險程度，采取預(yù)防措施
對糾正措施的有效實(shí)施加以控制
對糾正措施的記錄


　 　
5. 質(zhì)量體系生存周期

要求各階段必須有合格的產(chǎn)品（包括文檔），并以其作為下一階段的工作基礎(chǔ)。對每一階段的產(chǎn)品，必須組織評審，確保其質(zhì)量，避免錯誤影響后續(xù)工作。

本標(biāo)準(zhǔn)適用于任何生存周期模型。

5.1 合同評審

本公司應(yīng)評審每一合同，以確保：

規(guī)定合同的范圍和需求并寫入文檔
識別可能出現(xiàn)的風(fēng)險
恰當(dāng)?shù)谋Ｗo(hù)有關(guān)的專利信息
解決所有與招標(biāo)不一致的需求
有能力滿足需求
規(guī)定其他涉及項目的供貨商的責(zé)任
統(tǒng)一雙方對術(shù)語的理解
需方有能力履行合同職責(zé)
合同評審記錄應(yīng)妥善保管。

此外，應(yīng)注意有關(guān)質(zhì)量條款

驗收準(zhǔn)則
在開發(fā)過程中對需求變更的處理
對驗收后出現(xiàn)問題的處理
確定需方的責(zé)任，尤其是在需求規(guī)格說明、安裝和驗收時的作用
有需方提供的必要便利條件，如設(shè)施、工具和軟件等
采用的標(biāo)準(zhǔn)和規(guī)程
　

5.2 需方需求規(guī)格說明

在某一具體項目進(jìn)行開發(fā)前，本公司應(yīng)具有一套該項目的完整、精確、無歧義的功能需求，這些需求應(yīng)包括需方的所有要求。

因為本公司在業(yè)務(wù)領(lǐng)域具有豐富的經(jīng)驗，可以大力配合客戶識別并確定需求，需求在開發(fā)前得到需方的確認(rèn)。

該需求應(yīng)足以成為產(chǎn)品驗收確認(rèn)時的依據(jù)。

在制訂需求規(guī)格說明時應(yīng)注意：

雙方制定專人負(fù)責(zé)
需求認(rèn)可和更改的批準(zhǔn)
防止誤解，定義好術(shù)語，對需求的背景進(jìn)行說明
記錄和評審雙方討論的結(jié)果，以備將來查詢某些需求確定原因。

5.3開發(fā)計劃

在項目進(jìn)行前制定開發(fā)計劃，作為總體的策劃，指導(dǎo)整個項目有序的進(jìn)行。

開發(fā)計劃要求包括以下方面：

項目定義
項目資源組織管理
開發(fā)階段
進(jìn)度
確定質(zhì)量保證計劃、測試計劃、集成計劃等
隨著項目的進(jìn)展，開發(fā)計劃要不斷更新，在生命周期模型每一階段開始之前，都要有該階段的工作計劃，并經(jīng)過評審后實(shí)施。

以下較詳細(xì)的說明開發(fā)計劃中應(yīng)具備的各方面。

A. 開發(fā)階段

開發(fā)計劃應(yīng)將項目目標(biāo)轉(zhuǎn)化為最終結(jié)果的過程、方法等清楚的描述出來，可以把工作分為幾個階段，比如按照生命周期法劃分開發(fā)階段。

開發(fā)階段要確定以下項：

要執(zhí)行的開發(fā)階段
每一階段所需的輸入
必須用文檔方式確定下來，每一項需求均有明確的定義，以保證完成情況可被檢驗。

每一階段應(yīng)產(chǎn)生的輸出
驗證階段輸出，必須滿足以下幾點(diǎn)：

滿足相應(yīng)的要求
有明確的驗收準(zhǔn)則，作為驗收評審的參考。
符合開發(fā)慣例和約定
每一階段需要執(zhí)行的驗證步驟
必須有對每階段輸出的驗證計劃，并在適當(dāng)?shù)臅r間進(jìn)行驗證評審。

分析各階段可能潛在的問題或需要解決的問題
　

B. 項目管理

項目開發(fā)、實(shí)施等過程的時間進(jìn)度安排
進(jìn)度的控制方法及活動
確定組織機(jī)構(gòu)及其職責(zé)、各工作組的資源及工作分配
不同工作組間的組織協(xié)調(diào)方法，并明確技術(shù)接口問題。
C. 開發(fā)方法和工具

規(guī)定項目活動應(yīng)共同遵循的方法及使用的工具，包括：

開發(fā)規(guī)范、慣例
開發(fā)工具及技術(shù)
5.4 質(zhì)量計劃

質(zhì)量計劃作為開發(fā)計劃的一部分。

質(zhì)量計劃隨項目進(jìn)展而更新，質(zhì)量計劃經(jīng)正式評審，并得到所有與計劃執(zhí)行有關(guān)的組織的統(tǒng)一。

質(zhì)量計劃應(yīng)包含或引用以下內(nèi)容：

質(zhì)量目標(biāo)，盡可能以定量方式給出
定義每一階段的輸入、輸出準(zhǔn)則
確定要進(jìn)行的測試、驗證和確認(rèn)活動的類型和詳細(xì)計劃，包括時間、進(jìn)度等。
確定具體質(zhì)量活動的職責(zé)：比如，評審和測試、更改控制、對缺陷的控制和糾正措施。
5.5 設(shè)計和實(shí)現(xiàn)

設(shè)計和實(shí)現(xiàn)活動是將需求規(guī)格說明轉(zhuǎn)化為軟件產(chǎn)品的過程。為保證軟件產(chǎn)品的質(zhì)量，這些活動必須在嚴(yán)格規(guī)定的方法下進(jìn)行，不能依賴于事后的審查監(jiān)督。

設(shè)計
設(shè)計階段要滿足各階段的共同要求，此外，設(shè)計階段還應(yīng)考慮：

選用適合所開發(fā)產(chǎn)品類型的設(shè)計方法
總結(jié)吸取以往項目的經(jīng)驗教訓(xùn)
設(shè)計應(yīng)考慮軟件以后的測試、維護(hù)和使用
B. 實(shí)現(xiàn)

規(guī)定編程規(guī)則、編程語言、命名約定、編碼和注釋規(guī)則等
要求在實(shí)現(xiàn)過程中嚴(yán)格遵守既定開發(fā)規(guī)則
選用合適的方法和工具實(shí)現(xiàn)產(chǎn)品
本公司內(nèi)部制定《開發(fā)規(guī)范》，各項目組可參照制定適合特定項目的規(guī)范。

C. 評審

為使需求規(guī)格說明得以滿足和上述規(guī)則方法得以實(shí)施，必須以評審的方式加以保證。直到所有被發(fā)現(xiàn)的缺陷被消除，或確定缺陷的風(fēng)險可被控制后，才能進(jìn)入下一步的設(shè)計或?qū)崿F(xiàn)工作。

各項目組引用公司規(guī)范或參照制定的開發(fā)規(guī)范應(yīng)在取得本項目組廣泛認(rèn)可的情況下，提交給評審部門，作為評審參照依據(jù)。

評審紀(jì)錄應(yīng)保存，評審結(jié)果可能作為個人及項目組工作成績評定的參考之一。

5.6 測試和確認(rèn)

要具有完整的測試計劃，測試計劃要經(jīng)過評審，并以此為依據(jù)進(jìn)行測試活動。

A.測試計劃

包括單元測試計劃、集成測試計劃、系統(tǒng)測試計劃、驗收測試計劃
制定測試用例、測試數(shù)據(jù)和預(yù)期結(jié)果
考慮要進(jìn)行的測試類型，如：功能測試、邊界測試、性能測試、可用性測試等
描述測試環(huán)境、工具以及測試軟件
軟件產(chǎn)品是否完成的判斷準(zhǔn)則
測試所需人員及其要求
B.測試活動

記錄發(fā)現(xiàn)的問題，指出可能的受影響的其他部分的軟件，通知相關(guān)負(fù)責(zé)人員。
確定受影響的其他部分軟件，并對其進(jìn)行重新測試。
評價測試是否適度和適當(dāng)。
在驗收和交付產(chǎn)品前，必須盡可能在類似使用環(huán)境中進(jìn)行確認(rèn)測試。
　

5.7 驗收

當(dāng)軟件產(chǎn)品已經(jīng)完成，經(jīng)過內(nèi)部確認(rèn)測試，準(zhǔn)備好交付后，應(yīng)要求需方根據(jù)合同中的規(guī)定原則判斷是否可以進(jìn)行驗收。對于驗收中發(fā)現(xiàn)問題的處理辦法由雙方商定并納入文檔。

具備驗收條件后，應(yīng)制定驗收計劃并逐步實(shí)施。

驗收計劃應(yīng)包括：

時間進(jìn)度
評估規(guī)程
軟件/硬件環(huán)境
驗收準(zhǔn)則
5.8 復(fù)制、交付和安裝

制定安裝分發(fā)計劃。

復(fù)制
制作好安裝程序，復(fù)制好必要的拷貝。

準(zhǔn)備好該交付的操作手冊、用戶指南等文檔。

交付
交付前應(yīng)對所交付產(chǎn)品的正確性及完整性進(jìn)行檢驗。

安裝
就以下方面雙方明確商定各自的作用、責(zé)任和義務(wù)：

時間進(jìn)度及安排，包括非工作時間及假日的人員安排及工作責(zé)任
提供出入便利條件，如通行證等
指定熟練人員的密切配合
提供必要的系統(tǒng)及設(shè)備
對每次安裝的確認(rèn)條件需明確規(guī)定
對每次安裝認(rèn)可的正式規(guī)程
5.9 維護(hù)

對于軟件產(chǎn)品在初次交付及安裝后，本公司必須提供的維護(hù)應(yīng)在合同中明確規(guī)定。合同中應(yīng)明確以下各項的維護(hù)期：

程序
數(shù)據(jù)
規(guī)格說明

維護(hù)工作一般包括：

問題的解決
接口的調(diào)整
功能擴(kuò)充和性能改進(jìn)
本公司針對以上維護(hù)工作制訂完善的維護(hù)方案，并嚴(yán)格遵照執(zhí)行。具體維護(hù)方案見《維護(hù)工作流程》

　

附錄C 質(zhì)量體系文件

包括質(zhì)量要素、各要素需要達(dá)到的目標(biāo)以及在開發(fā)過程中必須采取的措施

質(zhì)量要求要素定義如下：

正確性 在預(yù)定環(huán)境下，軟件滿足設(shè)計規(guī)格說明及用戶預(yù)期目標(biāo)的程度。它要求軟件沒有錯誤。
可靠性 軟件按照設(shè)計要求，在規(guī)定時間和條件下不出故障，持續(xù)運(yùn)行的程度。
效率 為了完成預(yù)定功能，軟件系統(tǒng)所需的計算機(jī)資源的多少。
完整性 為了某一目的面保護(hù)數(shù)據(jù)，避免它受到偶然的，或有意的破壞、改動或遺失的能力。
可使用性 對于一個軟件系統(tǒng)，用戶學(xué)習(xí)、使用軟件及為程序準(zhǔn)備輸入和解釋輸出所需工作量的大小。
可維護(hù)性 為滿足用戶新的要求，或當(dāng)環(huán)境發(fā)生了變化，或運(yùn)行中發(fā)現(xiàn)了新的錯誤時，對一個已投入運(yùn)行的軟件進(jìn)行相應(yīng)診斷和修改所需工作量的大小。
可測試性 測試軟件以確保其能夠執(zhí)行預(yù)定功能所需工作量的大小。
靈活性 修改或改進(jìn)一個已投入運(yùn)行的軟件所需工作量的大小。
復(fù)用性 一個軟件（或軟件的部分）能再次用于其它應(yīng)用（該應(yīng)用的功能與軟件或軟件部件的所完成功能有聯(lián)系）的程度。
在設(shè)計開發(fā)過程中，必須注意以下要求，以保證軟件的質(zhì)量達(dá)到目標(biāo)。

正確性
軟件的功能要滿足用戶的要求，在預(yù)定環(huán)境下能夠完成預(yù)期的功能。因此，必須明確的了解用戶的需求。

在需求確定方面，應(yīng)通過深刻的理解電信企業(yè)的運(yùn)營系統(tǒng)及了解其發(fā)展趨勢，建立模型并分析，廣泛了解其他系統(tǒng)的特長，并總結(jié)以往的經(jīng)驗教訓(xùn)的基礎(chǔ)上，確定出需求并通過與用戶的交流最終確定。

在需求的表達(dá)方面，強(qiáng)調(diào)以全面、精確、細(xì)致、易于理解的方式表達(dá)，可能需要以多種形式，比如：功能描述、數(shù)據(jù)描述、數(shù)據(jù)流圖、系統(tǒng)說明等。

可維護(hù)性
遵從統(tǒng)一的規(guī)范，包括命名規(guī)范、界面規(guī)范、編程風(fēng)格。

編碼應(yīng)具有良好的可讀性，注釋完整清晰。

避免復(fù)雜的邏輯判斷條件，易讀，易測試

編碼應(yīng)盡量簡練，邏輯簡單

保存異常信息與錯誤日志以便于調(diào)試與分析

降低模塊之間的耦合度，增強(qiáng)模塊內(nèi)的內(nèi)聚。

可用性
用戶容易理解和使用該功能

響應(yīng)時間快，操作方便，提高用戶工作效率。

提示信息簡潔準(zhǔn)確

可靠性
具有異常捕獲功能并提供異常處理與恢復(fù)功能

5、效率

盡量降低系統(tǒng)資源的開銷

查詢語句要充分考慮到索引

減少與數(shù)據(jù)庫的不必要的交互

靈活性，易于擴(kuò)展
充分考慮到各地的不同的環(huán)境，通過參數(shù)設(shè)置使其易于適應(yīng)不同的要求。

完整性、安全性
保證相關(guān)的數(shù)據(jù)一致性

考慮數(shù)據(jù)的存取權(quán)限。

文檔完善
按文檔要求完成相關(guān)文檔。

　

審查制度

對于每一階段的文檔及軟件產(chǎn)品都應(yīng)交付證質(zhì)量保證部門，由審查小組按質(zhì)量要求嚴(yán)格審查。

審查內(nèi)容：

文檔：開發(fā)計劃、用戶需求規(guī)格說明、概要及詳細(xì)設(shè)計文檔、技術(shù)文檔、用戶手冊等，詳細(xì)要求見文檔計劃。評審文檔是否規(guī)范，表達(dá)清晰，有實(shí)用價值。

設(shè)計方案：是否達(dá)到設(shè)計目標(biāo)。

應(yīng)用程序：是否達(dá)到質(zhì)量目標(biāo)和符合設(shè)計目標(biāo)。

審查流程：

項目組按計劃準(zhǔn)備好交付的產(chǎn)品及文檔
交付質(zhì)量保證部門，組織評審
完成評審，發(fā)現(xiàn)錯誤報告
發(fā)現(xiàn)錯誤的返工
復(fù)查返工問題是否已解決

________________________________________

主頁 論壇 留言 打印 聯(lián)系







技術(shù)討論指南---如何“不戰(zhàn)而勝”
來自lannuo.533.net
________________________________________

限制參與者人數(shù)。精心選擇合適的人選，只讓必需的人參加，不必求全。

準(zhǔn)備好討論問題，明確主要目的，將問題和目的書面化，這樣會更清晰，并讓參與者清楚地了解這些問題和目的。最好能給參與者比較充足的思考時間。

控制討論主題，避免離題。

注意突出重點(diǎn)、不要陷入細(xì)枝末節(jié)，一般能進(jìn)入正式討論的問題不會是太瑣碎的問題。不要試圖在討論會上將所有作業(yè)完全做完，有些事情本應(yīng)該會后進(jìn)行，比如具體實(shí)現(xiàn)等。避免讓大家為個人做作業(yè)。

不能取得大家理解的問題暫時記錄在案，留待以后討論。有時一個問題被提出，但多數(shù)人并未理解該問題的重要性，除非能夠有效地解釋明白，否則應(yīng)在時機(jī)更成熟時再討論。如果是關(guān)鍵核心問題當(dāng)然另當(dāng)別論。

不能期望取得絕對的一致，對分歧較大和爭執(zhí)不休的問題及時轉(zhuǎn)換角度，先討論判斷準(zhǔn)則及衡量方法等，如果暫時沒有討論思路則記錄在案，留待以后討論。再更充分的思考后，更容易找到問題的關(guān)鍵點(diǎn)和思路。

做好書面記錄。對問題的解決做好文檔，被否定的思路也應(yīng)該包含在文檔中，有利于以后理解方案選擇思路。

　

主持人的責(zé)任

充分理解討論目的，控制討論朝目標(biāo)前進(jìn)。必須做好前期準(zhǔn)備。

對貶低和羞辱別人的行為嚴(yán)加約束。會前強(qiáng)調(diào)：“討論發(fā)言必需對產(chǎn)品而不能對人，絕對避免攻擊別人的行為，哪怕是以開玩笑的方式”，指出這樣的行為是不光彩的。討論期間如果不幸發(fā)生這樣的事情，果斷明確地指出。必要時（失去控制時）立即停止討論，不要勉強(qiáng)進(jìn)行。正常地，引導(dǎo)討論在和諧的氣氛和態(tài)度中。

限制爭論和辯駁。將問題引導(dǎo)到判斷準(zhǔn)則、衡量方法和解決思路上來。

制止冗長無效率的發(fā)言，制止離題的發(fā)言，制止進(jìn)入瑣碎細(xì)節(jié)的發(fā)言。以簡單總結(jié)問題的方法或時間進(jìn)度的理由搶回主動控制權(quán)。提醒和警告經(jīng)常轉(zhuǎn)移問題的人，重申討論重點(diǎn)和目的。

總結(jié)討論成功與失敗的經(jīng)驗，使自己和別人可以做得更好。

________________________________________

主頁 論壇 留言 打印 聯(lián)系






任務(wù)管理
來自lannuo.533.net
　
概述
一個工程項目是由一系列的任務(wù)組成，合理地安排這些任務(wù)單元并保證其按時完成，才能保證整個項目進(jìn)度能夠按時完成。為此我們制訂以下方法加強(qiáng)任務(wù)管理。
一個任務(wù)是包含在一個整體計劃環(huán)境中的，因此作為個體首先要服從于整體計劃。
任務(wù)管理方法
任務(wù)安排：
采用明確任務(wù)、明確責(zé)任的方式來安排任務(wù)。
下達(dá)任務(wù)必須書面化。
要求負(fù)責(zé)人明確、時限明確、任務(wù)表達(dá)明確、優(yōu)先順序明確。
明確任務(wù)的結(jié)果。
方法： 我們定制格式化任務(wù)安排表，附錄《任務(wù)安排工作單》即為一個實(shí)例。
協(xié)調(diào)及控制：
統(tǒng)一協(xié)調(diào)調(diào)度任務(wù)，及滿足每個人的任務(wù)量，又避免超負(fù)荷。并監(jiān)督任務(wù)能按時按質(zhì)完成。
　
合理安排每個人的長期任務(wù)和緊急任務(wù)。
協(xié)調(diào)者必須監(jiān)督進(jìn)度的進(jìn)展，及時地調(diào)整或督促。
通過日常檢查監(jiān)控任務(wù)的進(jìn)展。其中應(yīng)特別關(guān)注關(guān)鍵路徑上的任務(wù)。
對重要任務(wù)進(jìn)行正式評審。以保證其完成質(zhì)量。
方法：
可以在定期舉行的例會上總結(jié)匯報工作。
為幫助統(tǒng)一管理任務(wù)及人力，我們設(shè)計了附錄《任務(wù)安排匯總表》，將任務(wù)、人力、進(jìn)度三維統(tǒng)一表達(dá)，即可以看到一個任務(wù)由那幾個人來完成，及各自的角色，又可以看到每個人當(dāng)前所承擔(dān)的所有任務(wù)，便于工作量均衡。進(jìn)度跟蹤便于統(tǒng)計剩余任務(wù)工作量。
結(jié)果考評：
個人工作成績通過任務(wù)完成情況紀(jì)錄為依據(jù)。
　
任務(wù)等級定義
任務(wù)分為幾個等級，在安排任務(wù)時確定輕重緩急，任務(wù)等級作為安排者和執(zhí)行者間交流的一種簡潔的信息，包含了安排者在全局的層次上對任務(wù)的一種認(rèn)識和理解，并將這種理解記錄下來，并傳達(dá)給執(zhí)行者，有利于執(zhí)行者能理解并按統(tǒng)一調(diào)度執(zhí)行任務(wù)。這樣可以更好地控制進(jìn)度，避免關(guān)鍵或緊急任務(wù)被拖后。
對執(zhí)行者來說，可以有根據(jù)當(dāng)前任務(wù)的優(yōu)先級，有條理地安排工作。
任務(wù)等級可從以下方面來考慮：
緊急程度：（對任務(wù)過程的時間要求）
　
寬松：時限十分寬松，可以在其他任務(wù)后考慮。
一般：時間比較充裕，可以合理安排進(jìn)度。
較急：有明確要求的時限，且應(yīng)該盡快著手盡快完成。一般在關(guān)鍵路徑上的任務(wù)至少有較急的級別。
緊急：立即著手，以盡快的速度解決問題。一般在任務(wù)進(jìn)度可能造成較大影響時定義該級別，比如影響項目進(jìn)度或影響客戶業(yè)務(wù)使用。具有較高的優(yōu)先級別，
特急：立即著手，需要時必須加班，需要趕赴現(xiàn)場時必須以最快的速度到達(dá)。需要其他人力配合時立即聯(lián)系相關(guān)人員。一般在對客戶業(yè)務(wù)造成重大影響時定義特急的級別。最高優(yōu)先級別。
注釋：緊急程度可能隨著時間變動。
重要程度：（對任務(wù)本身的影響及作用的估計）
　
不重要：任務(wù)失敗不會造成嚴(yán)重結(jié)果，能夠容忍。
普通：任務(wù)失敗會造成一定影響，能通過措施補(bǔ)救，不在關(guān)鍵路徑上，不影響整體進(jìn)度，不影響客戶業(yè)務(wù)。
重要：任務(wù)重要，對整個系統(tǒng)或項目影響很大，比如在關(guān)鍵路徑上的任務(wù)，必須保證其成功完成。一般要在工期和質(zhì)量上給以充分的控制。
關(guān)鍵：影響整個系統(tǒng)或項目的成敗，必須給予最高的重視，對任務(wù)進(jìn)行充分的控制，確保成功完成。
任務(wù)排序優(yōu)先級：（任務(wù)執(zhí)行的先后次序，利于有條理的工作）

暫緩：盡量向后安排
普通：按順序安排
盡快：盡量向前安排
立即：安排在任務(wù)列表最前。
以上作為粗略地優(yōu)先級別估計，方便于優(yōu)先級的調(diào)整，缺省地，任務(wù)排序按照緊急在先、重要在先的原則排列。
　 特急 緊急 較急 一般 寬松
關(guān)鍵 *****！ ****！ ***！ **！ /
重要 ***** **** *** **
普通 / **+ *+ +
不重要 / + -
表中符號代表分值： *：20 ?。?0 +：5 -：-5 /：不定義
　
附件一：任務(wù)匯總表（示例） 可打印格式見其word文檔 - 任務(wù)管理
任 務(wù) 匯 總 表 項目簡稱： 階段日期：
任務(wù)編號 任務(wù)概述 工作量 最后時限 人員A 。 。 人員N 計劃 分析 開發(fā) 測試 實(shí)施 反饋 完成時間




工作量：
　
d天 h小時 角色：M負(fù)責(zé) A分析 D設(shè)計 P編碼 T測試 J輔助參與 進(jìn)度：已完成則打勾
附件二：任務(wù)單（示例） 可打印格式見其word文檔 - 任務(wù)管理
任 務(wù) 單 任務(wù)編號
任務(wù)負(fù)責(zé)人簽字： 任務(wù)協(xié)調(diào)人：
重要級別：□關(guān)鍵 □重要 □普通 □不重要 工作量：
緊急級別：□特急 □緊急 □較急 □一般 □寬松 最后期限：
概述：
任務(wù)詳述：
完成日期：
任務(wù)負(fù)責(zé)人總結(jié)（如果任務(wù)延期或失敗，請說明原因）：
評價：□優(yōu)秀 □良 □基本滿意 □不滿意 □很差
備注：


________________________________________

主頁 論壇 留言 打印 聯(lián)系







項目管理篇系列之七 - 項目管理軟件
　
摘自www.computerworld.com.cn
左美云 李東 董小英等著
　
項目管理技術(shù)的發(fā)展與計算機(jī)技術(shù)的發(fā)展密不可分，隨著計算機(jī)性能的迅速提高，大量的項目管理軟件涌現(xiàn)出來。它們可以用于各種商業(yè)活動，提供便于操作的圖形界面，幫助用戶制定任務(wù)、管理資源、進(jìn)行成本預(yù)算、跟蹤項目進(jìn)度等。



具備的功能

目前，市場上大約有120多種項目管理軟件工具。這些軟件各具特色，各有所長。這里列出大多數(shù)項目管理軟件具備的主要功能。

1．成本預(yù)算和控制

輸入任務(wù)、工期，并把資源的使用成本、所用材料的造價、人員工資等一次性分配到各任務(wù)包，即可得到該項目的完整成本預(yù)算。在項目實(shí)施過程中，可隨時對單個資源或整個項目的實(shí)際成本及預(yù)算成本進(jìn)行分析、比較。

2．制定計劃、資源管理及排定任務(wù)日程

用戶對每項任務(wù)排定起始日期、預(yù)計工期、明確各任務(wù)的先后順序以及可使用的資源。軟件根據(jù)任務(wù)信息和資源信息排定項目日程，并隨任務(wù)和資源的修改而調(diào)整日程。

3．監(jiān)督和跟蹤項目

大多數(shù)軟件都可以跟蹤多種活動，如任務(wù)的完成情況、費(fèi)用、消耗的資源、工作分配等。通常的做法是用戶定義一個基準(zhǔn)計劃，在實(shí)際執(zhí)行過程中，根據(jù)輸入當(dāng)前資源的使用狀況或工程的完成情況，自動產(chǎn)生多種報表和圖表，如“資源使用狀況”表、“任務(wù)分配狀況”表、進(jìn)度圖表等。還可以對自定義時間段進(jìn)行跟蹤。

4．報表生成

與人工相比，項目管理軟件的一個突出功能是能在許多數(shù)據(jù)資料的基礎(chǔ)上，快速、簡便地生成多種報表和圖表，如甘特圖、網(wǎng)絡(luò)圖、資源圖表、日歷等。

5．方便的資料交換手段

許多項目管理軟件允許用戶從其他應(yīng)用程序中獲取資料，這些應(yīng)用程序包括Excel、Access、Lotus或各種 ODBC兼容數(shù)據(jù)庫。一些項目管理軟件還可以通過電子郵件發(fā)送項目信息，項目人員通過電子郵件獲取信息，如最新的項目計劃、當(dāng)前任務(wù)完成情況以及各種工作報表。

6．處理多個項目和子項目

有些項目很大而且很復(fù)雜，將其作為一個大文件進(jìn)行瀏覽和操作可能難度較大。而將其分解成子項目后，可以分別查看每個子項目，更便于管理。另外，有可能項目經(jīng)理或成員同時參加多個項目的工作，需要在多個項目中分配工作時間。通常，項目管理軟件將不同的項目存放在不同的文件中，這些文件相互連接。也可以用一個大文件存儲多個項目，便于組織、查看和使用相關(guān)數(shù)據(jù)。

7．排序和篩選

大多數(shù)項目管理軟件都提供排序和篩選功能。通過排序，用戶可以按所需順序瀏覽信息，如按字母順序顯示任務(wù)和資源信息。通過篩選，用戶可以指定需要顯示的信息，而將其他信息隱藏起來。

8．安全性

一些項目管理軟件具有安全管理機(jī)制，可對項目管理文件以及文件中的基本信息設(shè)置密碼，限制對項目文件或文件中某些數(shù)據(jù)項的訪問，使得項目信息不被非法之徒盜取。

9．假設(shè)分析

“假設(shè)分析”是項目管理軟件提供的一個非常實(shí)用的功能，用戶可以利用該功能探討各種情況的結(jié)果。例如，假設(shè)某任務(wù)延長一周，則系統(tǒng)就能計算出該延時對整個項目的影響。這樣，項目經(jīng)理可以根據(jù)各種情況的不同結(jié)果進(jìn)行優(yōu)化，更好地控制項目的發(fā)展。

常見的項目管理軟件

根據(jù)項目管理軟件的功能和價格水平，大致可以劃分為兩個檔次：一種是供專業(yè)項目管理人士使用的高檔項目管理軟件，這類軟件功能強(qiáng)大，價格一般在2000美元以上，如Primavera公司的P3、Gores技術(shù)公司的 Artemis、ABT公司的WorkBench、Welcom公司的OpenPlan等。另一類是低檔項目管理軟件，應(yīng)用于一些中小型項目，這類軟件雖功能不很齊全，但價格較便宜，如 TimeLine公司的TimeLine、Scitor公司的Project Scheduler、Primavera公司的 SureTrak、Microsoft公司的Project 2000等。

1．Microsoft Project 2000

Microsoft Project 2000是一種功能強(qiáng)大而靈活的項目管理工具，可用于控制簡單或復(fù)雜的項目。它能夠幫助您建立項目計劃、對項目進(jìn)行管理，并在執(zhí)行過程中追蹤所有活動，使用戶實(shí)時掌握項目進(jìn)度的完成情況、實(shí)際成本與預(yù)算的差異、資源的使用情況等信息。

Microsoft Project 2000的界面標(biāo)準(zhǔn)、易于使用，具有項目管理所需的各種功能，包括項目計劃、資源的定義和分配、實(shí)時的項目跟蹤、多種直觀易懂的報表及圖形、用Web頁面方式發(fā)布項目信息、通過Excel、Access或各種 ODBC兼容數(shù)據(jù)庫存取項目文件等。

2.Primavera Project Planner

Primavera Project Planner（簡稱P3）工程項目管理軟件是美國Primavera公司的產(chǎn)品，是國際上流行的高檔項目管理軟件，已成為項目管理的行業(yè)標(biāo)準(zhǔn)。

P3軟件適用于任何工程項目，能有效地控制大型復(fù)雜項目，并可以同時管理多個工程。P3軟件提供各種資源平衡技術(shù)，可模擬實(shí)際資源消耗曲線、延時；支持工程各個部門之間通過局域網(wǎng)或Internet進(jìn)行信息交換，使項目管理者可以隨時掌握工程進(jìn)度。P3還支持ODBC，可以與Windows程序交換數(shù)據(jù)，通過與其他系列產(chǎn)品的結(jié)合支持?jǐn)?shù)據(jù)采集、數(shù)據(jù)存儲和風(fēng)險分析。

3．SureTrak Project Manager

Primavera公司除了有針對大型、復(fù)雜項目的P3項目管理軟件以外，還有管理中小型項目的SureTrak。SureTrak是一個高度視覺導(dǎo)向的程序，利用SureTrak的圖形處理方式，項目經(jīng)理能夠簡便、快速地建立工程進(jìn)度并實(shí)施跟蹤。它支持多工程進(jìn)度計算和資源計劃，并用顏色區(qū)分不同的任務(wù)。對于不同的人以不同方式建立的工程，SureTrak也能把它們放在一起作為工程組管理。此外，SureTrak還提供40多種標(biāo)準(zhǔn)報表，可任意選取、輸出所需要的信息。利用電子郵件和網(wǎng)上發(fā)布功能，項目組成員可進(jìn)行數(shù)據(jù)交流，如上報完成情況、接收上級安排的任務(wù)等。利用VB、C++或SureTrak自身的SBL語言,可訪問SureTrak的開放式數(shù)據(jù)庫結(jié)構(gòu)和OLE，必要時可把工程數(shù)據(jù)合并到其他信息系統(tǒng)。

4．CA-SuperProject

Computer Associates International公司的CA-SuperProject是一個很常用的軟件，適合于多種平臺，包括Windows、OS/2、 Unix/Solaris、DOS 和VAX/VMS等。大量的視圖有助于用戶了解、分析和管理項目的各方面。容易發(fā)現(xiàn)和有效解決資源沖突，并提供各種工具，使用戶在多個項目之間調(diào)整進(jìn)度表和資源。CA-SuperProject先進(jìn)和靈活的進(jìn)度安排可以讓用戶準(zhǔn)確模擬真實(shí)世界。還可以根據(jù)預(yù)定計劃、當(dāng)前完成情況、剩余情況，精確地重新制定剩余部分的執(zhí)行計劃。

5．Project Management Workbench(PMW)

PMW項目管理軟件是應(yīng)用商業(yè)技術(shù)公司（ABT）的產(chǎn)品，該軟件可以管理復(fù)雜的項目。它運(yùn)行在Windows操作系統(tǒng)下，提供了對項目建模、分析和控制的圖形化手段，具有項目管理所需的各種功能，深受廣大工程人員的歡迎。

6．Project Scheduler

Project Scheduler是Scitor公司的產(chǎn)品，它可以幫助用戶管理項目中的各種活動。Project Scheduler的資源優(yōu)先設(shè)置和資源平衡算法非常實(shí)用，利用項目分組，用戶可以觀察到多項目中的一個主進(jìn)度計劃，并可以分析更新。數(shù)據(jù)可以通過工作分解結(jié)構(gòu)、組織分解結(jié)構(gòu)、資源分解結(jié)構(gòu)進(jìn)行調(diào)整和匯總。Project Scheduler提供了統(tǒng)一的資源跟蹤工作表，允許用戶根據(jù)一個周期的數(shù)據(jù)來評價資源成本和利用率，還有詳細(xì)的“what if”分析功能，通過ODBC連接數(shù)據(jù)庫。

7．Time Line

Time Line是Symantec公司的產(chǎn)品，盡管該軟件對初學(xué)者來說使用稍感困難，但仍是有經(jīng)驗的項目管理經(jīng)理的首選。它除了具有項目管理的所有功能外，還具有報表功能和極強(qiáng)的與SQL數(shù)據(jù)庫連接的功能。


　


________________________________________

主頁 論壇 留言 打印 聯(lián)系






項目管理系列之六-質(zhì)量管理
　
摘自www.computerworld.com.cn
左美云 李東 董小英等著
　
目前，人們對信息系統(tǒng)項目提出的要求往往只強(qiáng)調(diào)系統(tǒng)必須完成的功能、應(yīng)該遵循的進(jìn)度計劃以及開發(fā)這個系統(tǒng)所花費(fèi)的成本，卻很少注意在整個生命周期中信息系統(tǒng)應(yīng)該具備的質(zhì)量標(biāo)準(zhǔn)。這種做法導(dǎo)致系統(tǒng)維護(hù)費(fèi)用增加，當(dāng)需要把系統(tǒng)移植到另外的環(huán)境中或使系統(tǒng)與其他系統(tǒng)配合使用時，需要完成很多輔助工作，導(dǎo)致總擁有成本增加。



IS建設(shè)需要全面質(zhì)量控制

信息系統(tǒng)的質(zhì)量管理不僅僅是項目開發(fā)完成后的最終評價，還需要在信息系統(tǒng)開發(fā)過程中進(jìn)行全面質(zhì)量控制。也就是說，不僅包括系統(tǒng)實(shí)現(xiàn)時的質(zhì)量控制，也包括系統(tǒng)分析、系統(tǒng)設(shè)計時的質(zhì)量控制；不僅包括對系統(tǒng)實(shí)現(xiàn)時軟件的質(zhì)量控制，而且還包括對文檔、開發(fā)人員和用戶培訓(xùn)的質(zhì)量控制。

之所以對信息系統(tǒng)采取全面質(zhì)量控制，是因為在信息系統(tǒng)生命周期的各個階段，對上一階段的理解以及本階段的設(shè)計與實(shí)現(xiàn)上都存在著這樣那樣的問題。在圖1中，各階段之間的接口至少存在列出來的9個問題，要想順利解決每一個問題并非易事。
　　　圖2 軟件質(zhì)量與產(chǎn)品活動的關(guān)系


根據(jù)一些軟件公司的統(tǒng)計資料，在后期引入一個變動比在早期引入相同變動所需付出的代價高2～3個數(shù)量級。因此，我們應(yīng)該從信息系統(tǒng)開發(fā)的初始階段就進(jìn)行質(zhì)量控制，以便盡量在早期發(fā)現(xiàn)錯誤，及早更正。

如何建立質(zhì)量指標(biāo)體系？

信息系統(tǒng)的質(zhì)量比較難管理，原因之一是信息系統(tǒng)的質(zhì)量指標(biāo)難以定義，即使能夠定義，也較難度量。由于信息系統(tǒng)的核心是軟件，因此如何度量軟件的質(zhì)量成為解決問題的關(guān)鍵。這里介紹一種從管理角度度量軟件質(zhì)量的方法。

我們把影響軟件質(zhì)量的因素分成三組，分別反映用戶在使用軟件產(chǎn)品時的三種不同傾向或觀點(diǎn)（圖2）。這三種傾向是：產(chǎn)品運(yùn)行、產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。信息系統(tǒng)作為一個產(chǎn)品，也可以參照這三種傾向來定義。
圖1　信息系統(tǒng)生命周期各階段之間的關(guān)系


我們可以采取以下步驟實(shí)施全面質(zhì)量控制：

1．實(shí)行工程化開發(fā)

“信息系統(tǒng)開發(fā)方法”一詞的廣義理解是“探索復(fù)雜系統(tǒng)開發(fā)過程的秩序”；狹義理解是“一組為信息系統(tǒng)開發(fā)起工具作用的規(guī)程”，按這些規(guī)程工作，可以較合理地達(dá)到目標(biāo)。規(guī)程由一系列活動組成，形成方法體系。信息系統(tǒng)是一項系統(tǒng)工程，必須建立嚴(yán)格的工程控制方法，要求開發(fā)組的每一個人都要遵守工程規(guī)范。

2．實(shí)行階段性凍結(jié)與改動控制

信息系統(tǒng)具有生命周期，這就為我們劃分項目階段提供了參考。一個大項目可分成若干階段，每個階段有自已的任務(wù)和成果。這樣一方面便于管理和控制工程進(jìn)度，另一方面可以增強(qiáng)開發(fā)人員和用戶的信心。

在每個階段末要“凍結(jié)”部分成果，作為下一階段開發(fā)的基礎(chǔ)。凍結(jié)之后不是不能修改，而是其修改要經(jīng)過一定的審批程序，并且涉及到項目計劃的調(diào)整。

3．實(shí)行里程碑式的審查與版本控制

里程碑式審查就是在信息系統(tǒng)生命周期每個階段結(jié)束之前，都正式使用結(jié)束標(biāo)準(zhǔn)對該階段的凍結(jié)成果進(jìn)行嚴(yán)格的技術(shù)審查，如果發(fā)現(xiàn)問題，就可以及時在階段內(nèi)解決。

版本控制是保證項目小組順利工作的重要技術(shù)。版本控制的含義是通過給文檔和程序文件編上版本號，記錄每次的修改信息，使項目組的所有成員都了解文檔和程序的修改過程。廣義的版本控制技術(shù)稱為軟件配制管理，并已有功能完善的軟件工具支持，如PVCS和Microsoft Visual SourceSafe。

4．實(shí)行面向用戶參與的原型演化

在每個階段的后期，快速建立反映該階段成果的原型系統(tǒng)，通過原型系統(tǒng)與用戶交互，及時得到反饋信息，驗證該階段的成果并及時糾正錯誤，這一技術(shù)被稱為“原型演化”。原型演化技術(shù)需要先進(jìn)的CASE工具的支持。

5．盡量采用面向?qū)ο蠛突跇?gòu)件的方法

面向?qū)ο蟮姆椒◤?qiáng)調(diào)類、封裝和繼承，能提高軟件的可重用性，將錯誤和缺憾局部化，同時還有利于用戶的參與，這些對提高信息系統(tǒng)的質(zhì)量都大有好處。

基于構(gòu)件的開發(fā)又被稱為“即插即用編程”方法，是從計算機(jī)硬件設(shè)計中吸收過來的優(yōu)秀方法。這種編程方法是將編制好的“構(gòu)件”插入已做好的框架中，從而形成一個大型軟件。構(gòu)件是可重用的軟件部分，構(gòu)件既可以自己開發(fā)，也可以使用其他項目的開發(fā)成果，或者直接向軟件供應(yīng)商購買。當(dāng)我們發(fā)現(xiàn)某個構(gòu)件不符合要求時，可對其進(jìn)行修改而不會影響其他構(gòu)件，也不會影響系統(tǒng)功能的實(shí)現(xiàn)和測試，就好像整修一座大樓中的某個房間，不會影響其他房間的使用。

6．全面測試

要采用適當(dāng)?shù)氖侄?，對系統(tǒng)調(diào)查、系統(tǒng)分析、系統(tǒng)設(shè)計、實(shí)現(xiàn)和文檔進(jìn)行全面測試。

7．引入外部監(jiān)理與審計

要重視信息系統(tǒng)的項目管理，特別是項目人力資源的管理，因為項目成員的素質(zhì)和能力以及積極性是項目成敗的關(guān)鍵。同時還要重視第三方的監(jiān)理和審計的引入，通過第三方的審查和監(jiān)督來確保項目質(zhì)量。
　


________________________________________

主頁 論壇 留言 打印 聯(lián)系






項目管理系列之五-團(tuán)隊管理
　
摘自www.computerworld.com.cn
左美云 李東 董小英等著
　
通常，項目小組可以按子系統(tǒng)或職能進(jìn)行劃分，這里主要討論項目團(tuán)隊的具體人員構(gòu)成以及有效的激勵方式。



項目小組構(gòu)成

這里所說的項目小組是指項目團(tuán)隊的基層單位，例如，一個大項目開發(fā)團(tuán)隊可以分為總體組、軟件開發(fā)組、硬件網(wǎng)絡(luò)組、測試組等若干個項目小組。
圖1　大型IS項目基層項目小組構(gòu)成


首先，每個項目小組的人數(shù)不能太多，否則組員之間彼此通信將占用大量的時間。此外，通常我們不能把一個子系統(tǒng)劃分成大量獨(dú)立的單元模塊，如果項目小組人數(shù)太多，則每個組員所負(fù)責(zé)實(shí)現(xiàn)的單元模塊與其他成員的接口將更復(fù)雜，不僅出現(xiàn)接口錯誤的可能性增加，而且系統(tǒng)測試也會變得既困難又費(fèi)時。

一般說來，每個項目小組的規(guī)模應(yīng)該比較小，以2～9名成員為宜。如果項目屬于中小型規(guī)模且建設(shè)時間在一年以內(nèi)，那么項目小組可以采用工作包負(fù)責(zé)人制。工作包負(fù)責(zé)人既負(fù)責(zé)該工作包的日常管理工作，同時又是該工作包的技術(shù)負(fù)責(zé)人，在其他成員中再挑選一位為助理，協(xié)助工作包負(fù)責(zé)人做好各方面的工作。

如果項目屬于大中型規(guī)模，建設(shè)時間在一年以上，那么就必須考慮項目建設(shè)人員因各種原因發(fā)生變動的情況。這時，項目小組具體構(gòu)成最好如圖1所示。這里的系統(tǒng)開發(fā)人員既可以是程序員，也可以是測試員。

采用這種按技術(shù)水平分層的構(gòu)成模式主要基于兩點(diǎn)考慮：第一，信息系統(tǒng)建設(shè)中既有創(chuàng)造性很強(qiáng)的事務(wù)，也有經(jīng)驗性很強(qiáng)的事務(wù)和照葫蘆畫瓢的簡單性事務(wù)，如果所有活動都讓高級人員去完成，則導(dǎo)致成本上升，造成人力資源的浪費(fèi)，還會引起高級人員的不滿；第二，由于項目建設(shè)時間太長，容易發(fā)生人員更替，并且由于信息系統(tǒng)開發(fā)技術(shù)主要靠“干中學(xué)”，中級和初級開發(fā)人員在系統(tǒng)建設(shè)過程中會成長起來，如果一旦發(fā)生上一層次人員變動，下層人員由于一直參與項目的研發(fā)，基本上可以“無縫”地接手工作。

如果項目小組成員不發(fā)生人員更替，則項目小組的整體素質(zhì)將隨時間的推移而提高，從而使項目的進(jìn)度加快。一般來說，初、中、高級人員最初的薪水可以按類似3∶7∶10的比例定位。當(dāng)然，隨著初中級人員技術(shù)水平的提高，他們的薪水也應(yīng)該不斷提高，因為他們在同樣時間內(nèi)可以完成更多、更復(fù)雜的工作。

把握團(tuán)隊成長規(guī)律

信息系統(tǒng)項目團(tuán)隊的成長與其他項目一樣，一般需要經(jīng)過四個階段：

1．形成階段

形成階段促使個體成員轉(zhuǎn)變?yōu)閳F(tuán)隊成員。每個人在這一階段都有許多疑問：我們的目的是什么？其他團(tuán)隊成員的技術(shù)、人品怎么樣？每個人都急于知道他們能否與其他成員合得來，自己能否被接受。

為使項目團(tuán)隊明確方向，項目經(jīng)理一定要向團(tuán)隊說明項目目標(biāo)，并設(shè)想出項目成功的美好前景以及成功所產(chǎn)生的益處；公布項目的工作范圍、質(zhì)量標(biāo)準(zhǔn)、預(yù)算及進(jìn)度計劃的標(biāo)準(zhǔn)和限制。項目經(jīng)理在這一階段還要進(jìn)行組織構(gòu)建工作，包括確立團(tuán)隊工作的初始操作規(guī)程，規(guī)范溝通渠道、審批及文件記錄工作。所以在這一階段，對于項目成員采取的激勵方式主要為預(yù)期激勵、信息激勵和參與激勵。

2．震蕩階段

這一階段，成員們開始著手執(zhí)行分配到的任務(wù)，緩慢地推進(jìn)工作?，F(xiàn)實(shí)也許會與個人當(dāng)初的設(shè)想不一致。例如，任務(wù)比預(yù)計的更繁重或更困難；成本或進(jìn)度計劃的限制可能比預(yù)計的更緊張；成員們越來越不滿意項目經(jīng)理的指導(dǎo)或命令。

震蕩階段的特點(diǎn)是人們有挫折、憤怨或者對立的情緒。這一階段士氣很低，成員可能會抵制形成團(tuán)隊，因為他們要表達(dá)與團(tuán)隊聯(lián)合相對立的個性。

因此在這一階段，項目經(jīng)理要做導(dǎo)向工作，致力于解決矛盾，決不能希望通過壓制來使其自行消失。這時，對于項目成員采取的激勵方式主要是參與激勵、責(zé)任激勵和信息激勵。

3．正規(guī)階段

經(jīng)受了震蕩階段的考驗，項目團(tuán)隊就進(jìn)入了發(fā)展的正規(guī)階段。項目團(tuán)隊逐漸接受了現(xiàn)有的工作環(huán)境，團(tuán)隊的凝聚力開始形成。這一階段，隨著成員之間開始相互信任，團(tuán)隊內(nèi)大量地交流信息、觀點(diǎn)和感情，合作意識增強(qiáng)，團(tuán)隊成員互相交換看法，并感覺到他們可以自由地、建設(shè)性地表達(dá)他們的情緒及意見。

在正規(guī)階段，項目經(jīng)理采取的激勵方式除參與激勵外，還有兩個重要方式：一是發(fā)掘每個成員的自我成就感和責(zé)任意識，引導(dǎo)員工進(jìn)行自我激勵；二是盡可能地多創(chuàng)造團(tuán)隊成員之間互相溝通、相互學(xué)習(xí)的環(huán)境，以及從項目外部聘請專家講解與項目有關(guān)的新知識、新技術(shù)，給員工充分的知識激勵。

4．表現(xiàn)階段

團(tuán)隊成長的最后階段是表現(xiàn)階段。這時，項目團(tuán)隊積極工作，急于實(shí)現(xiàn)項目目標(biāo)。這一階段的工作績效很高，團(tuán)隊有集體感和榮譽(yù)感，信心十足。團(tuán)隊能感覺到被高度授權(quán)，如果出現(xiàn)技術(shù)難題，就由適當(dāng)?shù)膱F(tuán)隊成員組成臨時攻關(guān)小組，解決問題后再將相關(guān)知識或技巧在團(tuán)隊內(nèi)部快速共享。

這一階段，項目經(jīng)理需要特別關(guān)注預(yù)算、進(jìn)度計劃、工作范圍及計劃方面的項目業(yè)績。如果實(shí)際進(jìn)程落后于計劃進(jìn)程，項目經(jīng)理就需要協(xié)助支持修正行動的制定與執(zhí)行。這一階段激勵的主要方式是危機(jī)激勵、目標(biāo)激勵和知識激勵。

需要要強(qiáng)調(diào)的是，對于信息系統(tǒng)建設(shè)人才，要更多地引導(dǎo)他們進(jìn)行自我激勵和知識激勵。當(dāng)然，足夠的物質(zhì)激勵是不言而喻的，它從始至終都是最有效的激勵。

激勵的結(jié)果是使參與信息系統(tǒng)的所有成員組成一個富有成效的項目團(tuán)隊，這種團(tuán)隊具有如下特點(diǎn)：

● 能清晰地理解項目的目標(biāo)；

● 每位成員的角色和職責(zé)有明確的期望；

● 以項目的目標(biāo)為行為的導(dǎo)向；

● 項目成員之間高度信任、高度合作互助。

總之，科學(xué)地管理團(tuán)隊有助于項目按期、按質(zhì)完成。
　


________________________________________

主頁 論壇 留言 打印 聯(lián)系

QQ在線咨詢