房地產項目管理軟件
當前位置：工程項目OA系統(tǒng) > 房地產OA系統(tǒng) > 相關系統(tǒng) > 房地產項目管理軟件
轉貼：研發(fā)軟件項目管理
小軟件項目開發(fā)的管理
創(chuàng)建成功的工程
成功項目管理的秘密
更好地領導一個項目的訣竅
參與變革,走向成功
CMM/TSP/PSP講義稿
開發(fā)流程中的可用性
軟件開發(fā)的管理和控制
如何組織軟件開發(fā)團隊
軟件項目管理（CMM）經驗談
實施CMM/TSP/PSP的建議
軟件開發(fā)質量保證體系
技術討論指南
任務管理
項目管理軟件
質量管理
團隊管理
小軟件項目開發(fā)的管理
一個企業(yè)的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把別人的 經驗生搬硬套到自己身上，可能會適得其反。同樣，管理一個軟件項目也一樣，大項目和小項目的方式不完全一樣。但從另一個角度來看，項目的大與小并沒有本質的區(qū)別，很多方法是共通的。本文的目的是從作者的經驗來談談小項目開發(fā)的管理。
一、小項目的特點
大家知道，“軟件危機”的出現(xiàn)起源于一些大型項目的不斷延遲甚至失敗。小項目相比之下，具有以下特點:
1.項目功能相對較少
2.開發(fā)人員較少
3.開發(fā)周期較短
另外，在現(xiàn)實中，有很多小項目是由一些中小公司進行開發(fā)的，這些公司往往人員流動性較大，這也是不容忽視的一個現(xiàn)實.
二、小項目開發(fā)中常犯的錯誤
小項目看起來比較簡單，比較容易成功，因而人們往往忽視了小項目的管理，其實這是一種誤解，從本人的經驗看來，小項目開發(fā)中容易犯以下的一些錯誤:
1、開發(fā)之前沒有認真地進行項目可行性和工作量的估計?！ ⊥捎陧椖枯^小，便很草率地制定一個開發(fā)日程表，沒有認真地估計項目難度，結果實際完成時間與估計完成時間往往有較大差別。
2、沒有真正的設計過程
開發(fā)人員少，意味著不同人員的程序之間交互、接口相對少一些。開發(fā)周期短意味著往往是同樣的幾個人從頭到尾負責一個項目。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下最基本的數(shù)據(jù)結構、函數(shù)接口便分頭去做自己的工作了，沒有一份較正式的文檔。
這種做法潛在的危險之一是有的人可能會對討論出的接口、結構理解有偏差(應該承認人是會犯錯誤的)。一個誤解可能造成以后的返工。 另一個潛在的危險是由于討論時忽略了某些情況，等大家都按當時的分工完成屬于自己的工作后，才發(fā)現(xiàn)各個模塊組合起來卻形不成一個完整的系統(tǒng)。其根源在于沒有一個負責協(xié)調的人員不斷監(jiān)控整個開發(fā)過程。
第三個潛在的危險是一旦有人中途退出開發(fā)隊伍，其他人加入時，新來的人難以理解 以前別人做好的代碼，索性自己從頭來。另外，沒有文檔的程序，日后維護和版本升級都比較困難。
3.不經過單元測試而直接進入系統(tǒng)測試
造成這一現(xiàn)象的原因是每個模塊相對比較簡單，但是為了測試一個模塊需要建立一些測試環(huán)境。例如，為了測試一個函數(shù)是否正確，應該用一些測試數(shù)據(jù)去調用該函數(shù)，需要編寫一些測試數(shù)據(jù)。但很多開發(fā)人員嫌麻煩，覺得反正其他模塊也很快出來了，直接用真正的數(shù)據(jù)來運行幾次就行了。
殊不知，一旦直接進入系統(tǒng)測試，發(fā)現(xiàn)運行結果不正確后需要一步步查找。由于模塊間的調用關系，可能查了很久才發(fā)現(xiàn)是某個模塊的問題。這種方法一來效率比較低，大量的時間用在了將一個錯誤定位在模塊上了。另外由于這種測試不完全，真正運行系統(tǒng)，當 調用某模塊時，可能大部分時候都是正常數(shù)據(jù)，極少出現(xiàn)邊界情況，可能某些邊界情況容易被忽視，很久之后才被發(fā)現(xiàn)。但是如果對每個模塊進行單元測試時都進行一下邊界測 試，就會很容易消除一些隱患。真可謂欲速則不達也。
三.合理的開發(fā)流程
合理的開發(fā)模式，一句話形容就是“麻雀雖小，五臟俱全”，即使是小型項目的開 發(fā)，仍然應該遵循軟件開發(fā)的一般規(guī)律，必須的步驟不能省略。但是小項目有它自身的一些特點，實行起來可以相對靈活些。
以下我從幾個方面描述一下我認為比較合理的模式.
1.需求獲取
在進入正式開發(fā)之前，必須先從用戶處獲取準確的需求。在這上面花費相當時間是很必要的。
軟件項目可以大致分為專用軟件和通用軟件兩大類。
對于專用軟件，例如給某單位開發(fā)一套該單位專用的系統(tǒng)，一般用戶對于軟件要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發(fā)合同中已經大致地規(guī)定了。
但是，開發(fā)合同上規(guī)定的只是一個大概的框架，在進入開發(fā)之前必須與用戶進行比較具體的交流和討論，了解清楚用戶心目中的產品究竟是什么樣子。這個步驟如果沒有好好做，往往到了開發(fā)工作的后期才發(fā)現(xiàn)開發(fā)人員的理解和用戶的要求有一些誤解，那么必然造成時間上的浪費。
對于通用軟件，在開發(fā)之前應該做一定的市場調查工作，一方面是從經濟效益考慮，調查產品的潛在市場有多大，另一方面是從技術的角度，必須了解清楚潛在用戶對軟件的各種技術上的要求，例如，用戶現(xiàn)有硬件配置如何，軟件配置如何，使用什么網絡，使用 什么數(shù)據(jù)庫等等，根據(jù)調查的統(tǒng)計結果決定即將開發(fā)的軟件的一些技術指標。
為了比較好地與用戶進行交流，使用一些工具是很有好處的。 為了討論用戶界面，可以用VB, delphi等做一個原型，根據(jù)原型有針對性地與用戶討論需求。(原型開發(fā)不僅僅可以用于準確獲取用戶的需求，開發(fā)出來的原型本身可以作為下一步開發(fā)的基礎，增量式地完成開發(fā))
為了討論軟件運行的流程，可以采用UML的Use Case圖。
2.需求分析
在了解用戶的需求之后，將需求用一種模型來表示，就是需求分析，目前比較流行的 分析方法是面向對象的方法，通過分析用戶需求，用類、類之間的各種關系來表示整個系統(tǒng)。
這部分涉及到具體的方法，在此不詳細討論，但是原則上是提取類->類之間關系,可能需要不斷修改而形成一份分析文檔。
我想強調幾個問題。
一是要分清問題域與系統(tǒng)責任。系統(tǒng)責任是指所要開發(fā)的軟件應該完成的功能，而問題域是包含所有相關的部分。例如你要開發(fā)一個程控機計費程序，程控機已經是現(xiàn)成，輸出的數(shù)據(jù)格式也已經是固定的，你的程序僅僅需要從程控機中讀取相應的信息，那么，程控機在你的系統(tǒng)里只是一個外部的東西，把它作為一個類也許就是不必要的，僅僅需要一個類來完成讀數(shù)據(jù)的操作。又如，你需要在一個已經存在的數(shù)據(jù)庫上開發(fā)一些應用，數(shù)據(jù)庫的格式已經固定，并且已經有一個后臺程序在運行，你需要開發(fā)一個新的前臺程序，這時，服務器程序對你來說就是一個外部的東西。但是，象這種外部的內容必須在分析文檔中有一些說明，作為系統(tǒng)的外在約束。 二是需求獲取與需求分析的關系。
用什么方法來完成需求的獲取，在很大程度上影響了需求分析的做法。
例如當初采用Use Case來表示用戶需求，那么從各種序列圖中選出相互交互的各個實體，就是一個個類。
三是分析與設計過程的銜接。
分析過程的內容是用類的結構來表示目標系統(tǒng)，并不設計具體實現(xiàn)，如采用什么編程 語言，在什么操作系統(tǒng)平臺上運行等等。這些具體實現(xiàn)是在設計階段來完成的。面向對象方法的優(yōu)點是分析、設計、編碼過程表示法統(tǒng)一，能比較好的銜接。但是，是把分析和設 計階段分開，采用瀑布式開發(fā)，還是采用其他方式，要看具體的情況。
對于需求潛在變化不大的項目，可以采用瀑布模型，有一個很明顯的設計階段，這樣做的好處是有一份比較完整的分析文檔，這樣以后如果需要采用不同的編程語言、或者采 用其他的平臺時，便可以以這份分析文檔作為開發(fā)的基礎。
對于需求變化頻繁的項目，可能采用少量分析;少量設計少量編碼測試的方式更合適，而且隨時可能要返回到前面某個一階段去進行修改。但是這意味著可能沒有一份完整的分析文檔。
現(xiàn)在很多CASE工具并不區(qū)分分析和設計的階段。但是，這并不意味著開發(fā)就可以對分析和設計不加區(qū)分，CASE工具如同一支筆，如何用好還得還人。
3.設計過程
設計階段的工作包括:
對分析模型必要的修改?？赡苄枰獙δ承╊惤Y構進行一些修改，這些修改的原因可能是編程環(huán)境的要求，或者為了重用以前的某些工作。
定義界面部分、數(shù)據(jù)訪問(數(shù)據(jù)庫)部分。
由于目前很多編程語言都可以可視化地設計界面，所以界面部分工作往往留到了編碼階段來完成。于是設計階段的工作量并不大。
4.編碼
進入編碼工作之后，可能會發(fā)現(xiàn)前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。
5.測試
如前所述，即使是小項目，也應該嚴格地進行測試。
四、人員的安排
比較小的項目，往往是幾個人來完成，這幾個人基本上從頭到尾參加開發(fā)。在這幾個人中，有一位項目負責人，負責分析、設計和協(xié)調的工作。由于項目小，項目負責人也要參加編程,那么這人必須把時間合理運用，
經驗告訴我?guī)讞l原則:
1.協(xié)調幾個人的工作比自己完成一段編碼更重要.
由于協(xié)調上出了漏洞，可能導致很大的問題，所以項目負責人必須隨時監(jiān)控各開發(fā)人員的工作，包括內容是否與要求發(fā)生偏差，進度是否滯后等等。
只有在完成這些工作之后，項目負責人剩下的時間才能用于編程。 2.給每個開發(fā)人員明確的任務書.
不管是用面向對象或者其他方法開發(fā)，分析、設計模型只是從功能的角度來描述系 統(tǒng)。但是，具體開發(fā)時每個開發(fā)人員必須非常明確自己的任務，這些任務應該采用明確的文檔來表示。
3.讓大家都大致熟悉設計模型.
讓每個開發(fā)人員都清楚自己所做的工作在整個系統(tǒng)中處于什么地位，有時侯可能會發(fā)現(xiàn)設計模型中的漏洞，避免了各人的代碼編寫完畢之后又要修改的后果。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
創(chuàng)建成功的工程
作者：Bruce Eckel，翻譯：UMLChina.Hairui
Bruce Eckel，著名的計算機語言和工程專家，著有《C++編程思想》（Thinking in C++）、《Java 編程思想》（Thinking in Java）等書籍 相關網站：http://www.bruceeckel.com --譯者注
以下工程開發(fā)指導是我對決定一項使用任何語言的軟件工程成功與否的決定因素的一些認識。
1．記住往往事與愿違
純粹的“軼事工程”（原文為：anecdotal project，其含義不好理解，暫譯為"軼事工程"，盼指正--譯者）的失敗幾率總是存在，一些低至百分之五十而另一些高達百分之八十，但是所有的這些都表明：你失敗的機會大于你成功的機會。為什么我要從這個令人喪氣的預測開始我的話題呢？因為每一天開始時，我都想“今天將會不同，我今天能夠完成四倍數(shù)量的事情”，盡管（在此之前）有過一系列不間斷的例外。對于軟件工程來說，過度的狂熱往往被那些（只）關心結果人所夸大——“這一次，我們將解決以前從來沒有人解決過的問題，只需付出更少的時間和更小的代價”，盡管他們知道，真正的規(guī)則是：“你只能從此三者中選擇一個”。
記住你身后高高堆積的紙牌[i]非常重要。你手中有一根包含時代力量的魔術手杖或者是掛在懸崖上，會讓你做出完全不同的兩個決定。如果你懂得你的處境屬于后者，你將會說：“是的，這很好。但首先讓我們看看我們是否能夠在現(xiàn)有的進度和預算情況下完成這一切。”
一個將不穩(wěn)定形勢和對失敗的認識放到顯著位置的方法是研究過去的失敗。一份很好的資料是Roberts Glass（一位愛好研究崩潰的專家）的著作：《軟件失控》(Software Runaways,出版信息：Prentice Hall 1998)，以及他其它的著作。此外可以閱讀Tom Demarco和Tim Lister的經典之作《人件——生產性工程和團隊》 (Peopleware: Productive Projects and Team,出版信息：第二版，Dorset House,1999)。
2．切合實際地安排時間
時間安排的“魔法”經常受到非開發(fā)人員為滿足軟件開發(fā)實踐之外的愿望和期待而產生的想法所驅使。最近我校正了自己的時間安排策略。我先將整個工程顯示腦海中，然后閉上眼睛，清理自己的大腦并讓它判斷這個工程大概需要多少時間。如果不考慮奇怪的技術問題、各種會議和其他分心的事物的影響，得出的這個時間居然非常合理。但我建議將這個合理的時間乘以3，或許可能是4，并且加上百分之十。如果這個估計出來的時間將讓你失去市場機遇，那么考慮不要進行這個工程。如果你認為像這樣計劃時間不合理，那么首先請注意，大多數(shù)工程將遵循這個規(guī)律。其次，試想一下，如果你所在公司的所有工程都很成功進行會帶來局面：你將擁有更多的收入；更少的程序員會因為愚昧的工程時間安排筋疲力盡而退出。
你也許還會爭論說這個時間評估技術非常沒有科學性，這一點我同意。然而，所有的軟件評估技術都含有臆測和直覺的成分在內，甚至連功能點（原文為：function point，若有其他正規(guī)譯法，請指正）分析都需要對功能點進行猜測。我的“信封背面”技術將所有臆測結合到了一起，而不試圖假裝沒有猜測。用更少的時間，也許產生更好的結果。但是，我的猜測是建立在我自己的經驗之上的。
3．首先讓它運作起來
當我試圖進行一些無意義的事情時，我最大的創(chuàng)造性成功來臨了。銘記最重要技巧——當你開始一個工程時，你好比已經用手指將自己掛在一個懸崖之上；然后你考慮一下能夠做什么瘋狂的事情簡單地讓你的工程運作起來。這并不意味著你需要馬上投入進去并用通常的方式開始撰寫代碼，你只需要盡早盡快找到一個轉換周期非常短的工具，用來判斷你是否可以做該項工作以及你的工程可行性如何。我在后面將要提到的Python語言就是這樣一種工具。
將你的計劃運作起來有很多好處。憑你的經驗，你應該知道，用戶只有能夠開始使用你開發(fā)的東西的時候才能理解你開發(fā)的是什么，然后他們會突然產生各種念頭并對該軟件應該做些什么真正提出要求。一份系統(tǒng)說明書往往只是一份文檔，人們往往不會認真地閱讀，但是如果你讓他們體驗一個可運行的程序之后，他們就會確切地明白你的意思。更早地了解用戶們真正想要什么豈不是更好？
事情往往會比你想象出來的要復雜四倍以上，所以對你能夠完成的東西要盡可能地保守一些。無論何時，一些不可知的因素都在伴隨著你的工作（這一點你可以從產品描述中一些“最”中察覺到：“最快”、“最大”、“最新”），原型的價值不能進行夸大。如果在此之前你沒有做過類似的工程，那么最重要的事情是盡快地判明該工程是否可以實現(xiàn)，開發(fā)一個根本不能發(fā)揮作用的程序將會以浪費你的大量金錢而收場。
最后一點，優(yōu)化。要能夠在這個階段抵抗得了誘惑。牢記Donald Knuth說過的話（其中略有一點開玩笑的意思）：“不成熟的優(yōu)化是所有麻煩的根源”。雖然優(yōu)化是一些工程的關鍵因素，但是在確認程序切實可行之前一切優(yōu)化都是盲目的。在最后建造系統(tǒng)之前瀏覽一遍所有的問題。每個工程都有一些你沒有接觸過的東西，你應該首先將注意力放到這個領域，創(chuàng)建一個測試程序或者原型來尋找解決問題的方法。在你知道你是否可以做到并且知道做到的難度有多大之前，你沒有其他辦法能夠得知工程是否能夠成功、如何為它安排時間以及它需要多少付出等等。
4．使用恰當?shù)墓ぞ?
一個工程的早期部分應該是高度探索性和實驗性的，因為那個階段是發(fā)現(xiàn)自己不會做什么以及如何去建造程序的階段。尋找最適合工具的最好方法是去體驗一下他們，然后擯棄其中工作效率低下的那些。例如，你可能開始的時候用的是Rational Rose，后來決定使用Visio Professional來創(chuàng)建視圖，因為你需要Visio（或者通過Versa）提供的一些特性。
用來做工程的恰當工具并不一定就必須是你已經了解的編程語言。當使用一種語言時，你就被局限在該語言所能表示的范圍之中了。如果你是一個C++程序員，你很自然可能想用C++創(chuàng)建所有的工程管理和工具。但當你需要更加靈活的工具時，Perl是一種更快速的選擇（甚至將考慮學習需要的時間在內）。在你的實際工程開發(fā)中，使用Python來快速造型或者甚至交付一個內嵌Python語言的應用程序將給你帶來更好的局面。首先，它是免費的，所以不需要支付任何許可授權費用；同時它對C 和Java有完全兼容的接口，你可以使用Python解決所有Perl能夠解決的問題，所以它是C++和Java的一種完美的輔助語言。
5．接口的設計
在C++中，接口是一個包含所有虛函數(shù)的類；而在Java中接口技術被直接支持；在COM和COBRA中，你沒有其他選擇，你和所有的抽象打交道——所有的都是接口，沒有實現(xiàn)。接口提供了一個更加整潔的設計方式。要想讓程序員們確信這一點有些困難，但是它對將COM或者COBRA指定為構件模型非常有幫助的（COBRA技術也是與操作系統(tǒng)無關的技術）。它不僅僅提供了工程實現(xiàn)語言的靈活性，并讓你能夠完全地將工程切割開來。如果你打算在你的開發(fā)組或者公司之外實現(xiàn)你的工程的一部分，整潔的接口可以阻止任何與工程其它部分不適當?shù)倪B接，同時你可以用任何語言來進行開發(fā)。你可以采取快速造型來實現(xiàn)所有的接口，稍后才對其中比較特別的部分進行優(yōu)化。
6．設計時充分考慮異常情況
在C++中，異?？刂撇⒉幌裨贘ava中那樣得到有力支持——這是Java在工程管理方面成功之處。在設計、代碼編寫和模塊使用的時候往往會有一些錯誤，除非軟件自身能夠通過拋出一個異常來聲明這些錯誤，否則你將會花費許多小時或月的時間來捕獲這些問題。只有通過嚴謹?shù)漠惓Ｊ褂?，你才能保證這些問題不會出其不意地讓你的工程陷入困境。
7．簡潔往往付出代價
雖然很難說服管理部門，但是“簡潔”這個詞是可維護性和復用性的同義詞。不僅如此，一個簡潔的程序讓人感覺很好。但是因為我們確信軟件工程是一種商業(yè)行為，目的是為了賺錢，而不是為了感覺，因此很難說簡潔的程序比其他非簡潔的程序更加有靈氣地結合在一起。但是由于軟件是一種能夠賺錢的藝術實體，在美學和實用性之間必然會一場爭論。
8．人與人之間的交流是一個瓶頸
這就是為什么小型的組隊往往更加有生產力的原因。當一個工程像火焰一樣失去控制的時候，將更多的程序員扔進火焰將使情況變得更糟。這也是為什么簡短的小會議往往可以發(fā)揮作用而冗長的大型會議卻做不到，還有為什么太深的管理機制會導致生疏的原因。參閱《人件》（早些時候提及過）一書了解更多的細節(jié)。
解決交流問題的最好辦法是免費的：在一臺廢棄的計算機上安裝一個Linux服務器，你可以在幾分鐘內完成這項工作，自動安裝將包括一個Apache網頁服務器。然后將你們所有的文檔，從測試分析到用戶文檔，拷貝到服務器上，以便每個人都能夠訪問到最新的信息。你可以輕松地加入Java Servlets或者Perl腳本（http://www.perl.com/）或者Python(http://www.python.org/)來收集每一頁的內容，然后用一個List服務器來向所有的成員發(fā)送公告。如果你想用camera-ready格式來提供文檔，你可以用Adobe Acrobat格式來代替HTML格式。如果你的工程足夠大的話，指定一名成員專門負責維護服務器是值得的。
9．制定一份計劃（可以是任何類型的）
我曾經見過許多工程在沒有簽訂任何合同（更別說一份計劃）時已經有大量資金流動。哪怕是對于一個很小的工程，你也需要某種計劃，甚至它可能只是被寫在一個信封的背面或者只存在于主程序員的腦海中。當工程逐漸變大，你需要一個回顧的過程。一個典型的計劃包括：分析階段（包括你打算用程序解決什么問題以及程序將完成什么）、設計階段（程序如何完成它的任務、程序實現(xiàn)的組成、分析階段預定目標是否達到的測試使用信息以及發(fā)布、安裝和培訓等事項）。當新的信息被收集時，這些階段將被重復。根據(jù)工程的大小，這些步驟將被縮小或者放大，但你必須像熟悉你的編程語言一樣熟悉它們。
10．考慮外部幫助
一種放棄：我的公司提供培訓和咨詢服務，因此當然我感覺這是一個好主意。然而，如果你的公司內部有經驗豐富的人可以擔任你的工程的顧問，你可以不必向公司之外尋求幫助。這是一種以知識為基礎的商業(yè)行為，生產力最低和最高的軟件工人之間的生產力差別是很大的。如果你無法雇用那些最有生產力的工人，你可以通過培訓提高他們的生產力，通過咨詢和代碼預排來改進你的工程的分析、設計和實現(xiàn)。對于顧問和客戶來說，有一本優(yōu)秀的書籍是Weinberg的《咨詢的秘密》（出版信息：Dorset House,1986）
另一方面，我曾經見過一些工程中，使用外部的開發(fā)組隊剝奪了內部的隊伍的權利，該項目最后以花費更多的時間和資金收場。這將我們帶到我的最后一個提示:
11.了解永遠沒有銀彈（原文為：silver bullets,此處直譯為銀彈，估計引申含義和free lunch接近）的道理
這句諺語是由Fred Brooks發(fā)明的，對于今天仍然適用——盡管有許多“銀彈”已經被發(fā)明出來了。統(tǒng)一建模語言（UML）就是這樣一個例子：它當然是一個很好的通用詞匯表和設計符號集，但是UML僅僅輕微地減少了方法學家之間的爭論而已。永遠不會有不勞而獲的事情。你必須艱辛地計劃你的對象、它們的接口和結構，然后跨越一道道障礙將工程變成成果。你必須清楚沒有任何可以保證成功的方案可以依賴，同時牢記工程的失敗的幾率讓自己更好的瞄準成功。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
成功項目管理的秘密
摘自SDMagazine，Karl Wiegers著，UMLChina.Shids譯
在最好的情況下，管理軟件項目也是很困難的。不幸的是，許多新項目經理實質上沒有受到任何就職培訓。這里有20個成功的管理經驗供項目經理參考。
1. 定義項目成功的標準
在項目的開始，要保證風險承擔者對于他們如何判斷項目是否成功有統(tǒng)一的認識。經常，滿足一個預定義的進度安排是唯一明顯的成功因素，但是肯定還有其他的因素存在，比如：增加市場占有率，獲得指定的銷售量或銷售額，取得特定用戶滿意程度，淘汰一個高維護需求的遺留系統(tǒng)，取得一個特定的事務處理量并保證正確性。
2. 識別項目的驅動、約束和自由程度
每個項目都需要平衡它的功能性，人員，預算，進度和質量目標。我們把以上五個項目方面中的每一個方面，要么定義成一個約束，你必須在這個約束中進行操作，要么定義成與項目成功對應的驅動，或者定義成通向成功的自由程度，你可以在一個規(guī)定的范圍內調整。相關的詳細信息，請參照我的《創(chuàng)建一種軟件工程文化》（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。
3. 定義產品發(fā)布標準
在項目早期，要決定用什么標準來確定產品是否準備好發(fā)布了。你可以把發(fā)布標準基于：還存在有多少個高優(yōu)先級的缺陷，性能度量，特定功能完全可操作，或其他方面表明項目已經達到了它的目的。不管你選擇了什么標準，都應該是可實現(xiàn)的、可測量的、文檔化的，并且與你的客戶指的“質量”一致。
4. 溝通承諾
盡管有承諾不可能事件的壓力，從不作一個你知道你不能保證的承諾。和客戶和管理人員溝通哪些可以實際取得時，要有好的信譽。你的任何以前項目的數(shù)據(jù)會幫助你作說服的論據(jù)，雖然這對于不講道理的人來說沒有任何真正的防御作用。
5. 寫一個計劃
有些人認為，花時間寫計劃還不如花時間寫代碼，但是我不這么認為。困難的部分不是寫計劃。困難的部分是作這個計劃--思考，溝通，權衡，交流，提問并且傾聽。你用來分析解決問題需要花費的時間，會減少項目以后會帶給你的意外。
6. 把任務分解成英寸大小的小圓石
英寸大小的小圓石是縮小了的里程碑。把大任務分解成多個小任務，幫助你更加精確的估計它們，暴露出在其他情況下你可能沒有想到的工作活動，并且保證更加精確、細密的狀態(tài)跟蹤。
7. 為通用的大任務開發(fā)計劃工作表
如果你的組經常承擔某種特定的通用任務，如實現(xiàn)一個新的對象類，你需要為這些任務開發(fā)一個活動檢查列表和計劃工作表。每個檢查列表應該包括這個大任務可能需要的所有步驟。這些檢查列表和工作表將幫助小組成員確定和評估與他/她必須處理的大任務的每個實例相關的工作量。
8. 計劃中，在質量控制活動后應該有修改工作
幾乎所有的質量控制活動，如測試和技術評審，都會發(fā)現(xiàn)缺陷或其他提高的可能。你的項目進度或工作細分結構，應該把每次質量控制活動后的修改，作為一個單獨的任務包括進去。如果你事實上不用作任何的修改，很好，你已經走在了本任務的計劃前面。但是不要去指望它。
9. 為過程改進安排時間
你的小組成員已經淹沒在他們當前的項目中，但是如果你想把你的組提升到一個更高的軟件工程能力水平，你就必須投資一些時間在過程改進上。從你的項目進度中留出一些時間，因為軟件項目活動應該包括做能夠幫助你下一個項目更加成功的過程改進。不要把你項目成員可以利用的時間100％的投入到項目任務中，然后驚訝于為什么他們在主動提高方面沒有任何進展。
10. 管理項目的風險
如果你不去識別和控制風險，那么它們會控制你。在項目計劃時花一些時間集體討論可能的風險因素，評估它們的潛在危害，并且決定你如何減輕或預防它們。要一個軟件風險管理的簡要的指南，參見我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。
11. 根據(jù)工作計劃而不是日歷來作估計
人們通常以日歷時間作估計，但是我傾向于估計與任務相關聯(lián)的工作計劃（以人時為單位）的數(shù)量，然后把工作計劃轉換為日歷時間的估計。這個轉換基于每天我有多少有效的小時花費在項目任務上，我可能碰到的任何打斷或突發(fā)調整請求，會議，和所有其他會讓時間消失的地方。
12. 不要為人員安排超過他們80％的時間
跟蹤你的組員每周實際花費在項目指定工作的平均小時數(shù)，實在會讓人吃驚。與我們被要求做的許多活動相關的任務切換的開銷，顯著地降低了我們的工作效率。不要只是因為有人在一項特定工作上每周花費10小時，就去假設他或她可以馬上做4個這種任務，如果他或她能夠處理完3個任務，你就很幸運了。
13. 將培訓時間放到計劃中
確定你的組員每年在培訓上花費多少時間，并把它從組員工作在指定項目任務上的可用時間中減去。你可能在平均值中早已經減去了休假時間、生病時間和其他的時間，對于培訓時間也要同樣的處理。
14. 記錄你的估算和你是如何達到估算的
當你準備估算你的工作時，把它們記錄下來，并且記錄你是如何完成每個任務的。理解創(chuàng)建估算所用的假設和方法，能夠使它們在必要的時候更容易防護和調整，而且它將幫助你改善你的估算過程。
15. 記錄估算并且使用估算工具
有很多商業(yè)工具可以幫助你估算整個項目。根據(jù)它們真實項目經驗的巨大數(shù)據(jù)庫，這些工具可以給你一個可能的進度和人員分配安排選擇。它們同樣能夠幫助你避免進入“不可能區(qū)域”，即產品大小，小組大小和進度安排組合起來沒有已知項目成功的情況。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一試的好工具。
16. 遵守學習曲線
如果你在項目中第一次嘗試新的過程，工具或技術，你必須認可付出短期內生產力降低的代價。不要期望在新軟件工程方法的第一次嘗試中就獲得驚人的效益，在進度安排中考慮不可避免的學習曲線。
17. 考慮意外緩沖
事情不會象你項目計劃的一樣準確的進行，所以你的預算和進度安排應該在主要階段后面包括一些意外的緩沖，以適應無法預料的事件。不幸的是，你的管理者或客戶可能把這些緩沖作為填料，而不是明智的承認事實確實如此。指明一些以前項目不愉快的意外，來說明你的深謀遠慮。
18. 記錄實際情況與估算情況
如果你不記錄花費在每項任務上的實際工作時間，并和你的估算作比較，你將永遠不能提高你的估算能力。你的估算將永遠是猜測。
19. 只有當任務100%完成時，才認為該任務完成
使用英寸大小的小圓石的一個好處是，你可以區(qū)分每個小任務要么完成了，要么沒有完成，這比估計一個大任務在某個時候完成了多少百分比要實在的多。不要讓人們只入不舍他們任務的完成狀態(tài)；使用明確的標準來判斷一個步驟是否真正的完成了。
20. 公開、公正地跟蹤項目狀態(tài)
創(chuàng)建一個良好的風氣，讓項目成員對準確地報告項目的狀態(tài)感到安全。努力讓項目在準確的、基于數(shù)據(jù)的事實基礎上運行，而不是從因為害怕報告壞消息而產生的令人誤解的樂觀主義。使用項目狀態(tài)信息在必要的時候進行糾正操作，并且在條件允許時進行表揚。
這些提示不能保證你的成功，但是它們將幫助你在你的項目上獲得一個堅實的把手，并且保證你做了所有你可以做的事來讓項目在這個瘋狂的世界上成功。
原文鏈接：http://www.processimpact.com/articles/proj_mgmt_tips.html
________________________________________
主頁 論壇 留言 打印 聯(lián)系
更好地領導一個項目的訣竅
----Warren Keuffel
自：SD Magazine，Sep,1999. UMLChina.Think譯
----------------------------------------------------------------------------
技術管理就像開車。當你做得正確時，沒有人注意，一旦某個環(huán)節(jié)出錯，問題會接踵而來。以下是我11年來作為Interviewing Manager的Team管理體會，排名不分先后，你必須注意每一點。
1. 不要重復過去二三十年來別人犯過的錯誤
這句話來自Steve Mcconnell，IEEE軟件編輯和軟件開發(fā)暢銷書作家。Mcconnell的作品包括經典著作“Code Complete”。Mcconnell認為，“大量閱讀”是避免凡重復錯誤的最好方法。
2. 80%的管理就是選擇正確的人選
Scott Adams, Dilbert漫畫的作者認為一個好的項目經理必須創(chuàng)造一個人盡其用的環(huán)境。所有的項目經理都應該讀一讀Tom Demarco和Tim Lister的新書“Peopleware：Productive Projects and Teams”（2nd Edition, Dorset House, 1999）。
3. 總是試圖雇用比你強的人
不要讓你的自負成為項目的瓶頸。組織一支聰明的隊伍，給他們足夠的資源和解決問題的規(guī)則，讓員工自己解決問題。
4. 不要浪費時間
Tom Bragg，Intellisys Technology Corp.的首席技術官員，認為太多的項目由于不能如期開始最后陷入麻煩。通常導致延遲的原因包括其它任務的干擾，人事變動，不準時的經理等等。
5. 最優(yōu)的未必是最大的
Tom Bragg的另一個建議是：密切注意項目開始后發(fā)生的事情。Bragg說：“計劃好你的工作然后如期進行，過分緊張的工作強度反而往往導致生產率的降低，可能保持每周50小時以內的工作強度是最佳的。
6. 真實的，公正的估計
項目經理應該避免“依照管理者的欲望修改計劃”的陷阱?！耙粋€有效的估計的特征是所估計的時間與金錢比實際情況低和高的概率相等”，Bragg說。
7. 使你的組織結構更有效率
很多情況下，你可以采用另外一種與現(xiàn)在不同的組織結構。看一看Apache Web server的開發(fā)小組，他們的層次組織并不分明，卻開發(fā)出了成功的產品。
8. 使用WWW上的免費工具
從http://sunnet.usc.edu/winwin/winwin.html，你可以下載由Barry Boehm的學生開發(fā)的，能夠把W理論（WinWin模型）和螺旋形模型結合起來的工具。在項目管理研究所的網址www.pmi.org，你可以下載它的聯(lián)機手冊。從www.spmn.com你可以看到從CMM模型出發(fā)的一些建議以及兩套工具：Control Panel和Risk Radar。Control Panel是Excel表格形式，由于監(jiān)測生產率和質量；Risk Radar是一個Access數(shù)據(jù)庫，對項目的風險進行量化管理。
9. 不要小看老程序員
重新訓練現(xiàn)有的程序員比雇用新畢業(yè)的大學生要有價值。老的程序員在以往的多個項目上有豐富的經驗，通過新技能的訓練后，他們的經驗和知識會幫助年輕的程序員（包括項目經理）節(jié)約時間和金錢。
10. 為你的項目選擇定正確的工作流程
并不是所有的項目都適用一種開發(fā)流程。Intel公司有規(guī)律地檢查每個開發(fā)小組的工作質量，如果出現(xiàn)了延遲交付或質量問題，Intel鼓勵該小組改進他們的工作流程。
11. 做好你的生存計劃
....
________________________________________
主頁 論壇 留言 打印 聯(lián)系
參與變革
---------發(fā)現(xiàn)更多可重用的過程與簡單的版本控制相比，更易走向成功
Lisa J. Roberts，譯：umlchina.mirnshi(mirnshi@263.net)
譯者序：本文刊登于SDMagazine，2000年11月。論述了為什么要建立可重用過程以及從中得到的好處。譯文中部分語句采用了意譯，不妥之處和曲意之處請參見原文。
對開發(fā)過程共享實施猛烈的變革和改變是個什么樣子？除了可能的時間大量損失（好，其實這是很小的
可能，除了正在改變開發(fā)過程時），當它們獲得了人們支持時就都會成功。
在歷史上，人民，社會的勞動者，通過聯(lián)合推動了社會變革。這就是我們所滿意的應用程序，MeshTV，用二維和三維的有限元網格以圖形的方式可視化和分析數(shù)據(jù)。它也能處理多種不同的網格類型，提供各種方式查看數(shù)據(jù)并去除了大多數(shù)的硬件和廠商的依賴，同時以自身圖形硬件的速度顯示圖形。MeshTV也可以并行工作，你可以想象得到這需要一些組織級別滿足程序的復雜性，保持有序。最后說一點，MeshTV大約有450,000行源代碼。
這是我所作的全部描述。如果你想了解得更多，查看www.llnl.gov/bdiv/meshtv，你可以下載可執(zhí)行程序、源代碼和手冊。
受約束的混亂
象許多為內部使用而開發(fā)的程序一樣，在加利福尼亞Livemore的勞倫斯Livemore國家實驗室，對程序必需的修改和增加超出了可用的資源。在MeshTV項目中，這導致了混亂，（on the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（譯者注：這句話不好譯）沒有人有時間坐下來畫出應用流程。我們都在實驗室的里里外外，忙于我們客戶的貪婪的需求。（有約150個文檔用戶-可能更多，實際上要靠5個兼職的開發(fā)人員支持）在我們這種狀況下，這種過程導致了我們用戶更多的抱怨和可靠性匱乏的程序。
三年前，我們的職責很?。◣讉€用戶，幾個開發(fā)人員，很少有廣泛的應用功能）允許我們在CVS上用非常不正規(guī)的過程管理源代碼。當用戶數(shù)和他們需求差異增多時，相應的代碼管理的復雜性也增加了。處理我們增長的工作量也變得更加困難，我們知道有些事情必須要改變了。我們決定加入到我們部門的其他開發(fā)小組中去，并使用Rational軟件公司的版本控制系統(tǒng)—ClearCase。從此，我們過程的改進氛圍（our process improvement culture）開始改變，變革的種子已經播下了
在我們轉向ClearCase前，我們小組的一位經理曾經誘導我們更多的集中在過程上，她徒勞了。她看到了增長的壓力和用戶的不滿，她想我們應該嘗試用不同的方法提高我們程序的可靠性和在用戶那里的名聲。不幸的是，她的話從來沒有引起重視，同樣我們也認識到了這點，但我們不得不忙于作完我們的工作。開發(fā)人員認為最好的情況是軟件工程學所論述的那樣，而在最糟和最可能的情況下，會占用大量的時間，提供眾多的文檔，用處不是很大。我們的一些老開發(fā)人員認為改進我們的過程沒有用并且……（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.）（譯者注：這句話太難譯了，單詞也不認識）而且俱樂部所有人，包括我也懷疑我們要收獲的巨大好處。我認為CVS工作得很好，我們真的不需要更多先進的東西。
在CVS工作的同時，ClearCase工作得更好。我認為在每個軟件工程生產力上沒有真正的提高，但是可以用我以前不能采用的工作方式工作。這些新的工作方法可以使管理源代碼變得更容易，同時也減少了我曾經在CVS中遇到的問題。例如，我現(xiàn)在可以輕松的多并發(fā)地開發(fā)，我可以在我完成后可靠的歸并我所作的。新特性彌補了我花在開發(fā)和學習新過程上的時間。
真正的產出
過渡不久，一位同事和我與一位來自蘋果計算機公司的開發(fā)同行進行了一次有趣的討論。他的工作需要產品開發(fā)過程的急迫應用，包括構建方法學和發(fā)行版本管理過程。當我們敘述我們通常隨意無計劃的方式時，他幾乎震驚暈倒。后來的討論，使我們驚奇的了解到了通過改進我們的過程所獲得的好處。有一位經理鼓勵我們是一方面，但是非同尋常的另一面是聽到一位開發(fā)同行稱贊他發(fā)現(xiàn)的好處。這是真正的產出，計算機科學風格的。
我們對其思考的越多，我們越認識到我們需要行動。將新特性和缺少固定發(fā)行日期聯(lián)系起來的狂熱，導致了在發(fā)行新版本和功能性的匱乏測試間長久的延期。我們的意圖是好的，我們想讓我們的客戶滿意。然而，不知何故，我們的期望事實上很糟糕，似乎看起來我們工作得很辛苦，但是，我們聽到了更多的抱怨。我們需要改變現(xiàn)狀。
首先，我們轉換到有目的的發(fā)行版本日期，使其包含明確的更改和新的功能。像許多的內部產品，MeshTV有著明顯的直接的用戶（MeshTV had users who lived "right down the street."）。新特性的不同的聲音淹沒在所有的目標回應中，我們嘗試經常性的從那些所有從會議廳走下來，停下來聊會兒天的用戶那里獲取要求。（這些打斷也可以避免我們持續(xù)工作）荒謬的是在試圖獲取所有要求中，我們不能滿足他們中的大多數(shù)，我們失望了。所以我們從這種方法上退回來?；蛘咴噲D將所有要求放進去（可能匆忙地完成，沒有更多明顯的bugs）,或者針對最后的抱怨作一個改正（從而沒有舊的要求）。我們需要一個載明新發(fā)行版本應體現(xiàn)哪些要求的計劃。
這表明另一個過程需要改進。在決定之前，我們通過將bugs報告和要改變的要求寫到紙上，保證可追蹤。這片紙經?！白呦蛄怂惺挛锏臍w途”，或者偶然的扔進了廢紙簍，或者壓在了其他所有的紙張下面。（這點上我堅信我已危險地靠近制造我自己桌面中子星）（譯者注：黑洞乎）那些紙隨著時間的流逝而不能理解，無心的造成了客戶輸入損失的結果。
我們需要很好的保持我們改變要求的追蹤，這樣我們就可以為下一個發(fā)行版本選擇明確的要求。在對幾個產品調研后，我們購買了Pure Atria的ClearDDTS，幫助我們管理我們的改變要求，我們試圖一年四次發(fā)布新版本應用程序，這作為一策略被我們采納，這樣我們就可以很快的清晰地增加新功能，不用更新得過于頻繁導致沒有時間測試我們的修改。為了達到結束點，我們努力選擇一定量的能夠在三個月內完成的工作。第一次時，因為我們沒有人知道如何預測一個詳細的修改需要多長時間，我們徹底失敗了。幸運的是，我們可以通過ClearDDTS跟蹤我們曾經預測的時間和工作中實際花費的時間，并且個別開發(fā)人員利用這些數(shù)據(jù)預測將來。在為其他版本的選擇工作中，這獲得了重大的成功。變革明顯的站住了腳。
我們也決定與目標發(fā)行版本并進，著手提高質量的工作。為了完成這點，我們要求所有決意要改變的要求要被不具有開發(fā)責任的其他人所驗證。當我們知道其他人會檢查工作時，我們就都會非常仔細，這多么驚奇。我們也開始采用Mercury Interactive’s Xrunner和內部使用的腳本開發(fā)了一個自動測試系統(tǒng)。將來，在我們發(fā)布一個新版本應用程序前，這些測試必須成功的測試過。
持續(xù)的改進
所有這些工作都以我們不能想象的方式的到回報了。我們更好地跟蹤我們的改變要求，也就是我們沒有丟掉它們，我們確實能跟得上用戶的更新狀態(tài)了。用戶喜歡這點，我們也不再面對來自客戶的挫折。他們也喜歡我們更頻繁的更新和更加健壯的程序。
我們正在尋找另外的方式，我們可以從改變我們過程中獲得好處的方式?，F(xiàn)在，我們正在研究軟件開發(fā)成熟度模型（CMM）,看是否能通過遵從2級幫助我們提供更好的應用軟件（請到http://www.sei.cmu.edu/查看更多的CMM信息）。我們可以從這種方式中獲得好處，但是我們想確認通過2級認證能夠編寫更好的代碼，不只是更多的文書工作的要求。我們的興趣在于進步，不在于核對boxes。
我們正在進行的另一個改變是，我們能夠更容易地在我們每年四個主版本之間發(fā)布修訂bugs的版本。這點可以是我們更快的轉向用戶的要求，平息用戶的憤怒。（我們基于用戶認識到的嚴重性和我們察覺的嚴重性的比較，選擇哪些bugs被改正，還包括工作區(qū)存在的風格。我們在整體上也為客戶整合了全部優(yōu)先級的感覺）
我們過程改革的更多驚人結果之一是不只影響了程序，更多地影響了程序開發(fā)人員。他們停止了改善用戶的態(tài)度，轉向提高應用程序。程序變得更可靠，發(fā)行版本變得更可預測的同時，用戶對應用軟件整體上也更加滿意。
但是我們不僅只關心我們的過程的改革。MeshTV的開發(fā)人員同其他的開發(fā)小組并同工作著，我們試著同其他的小組分享我們的經驗，學習我們的勝利和錯誤。圍繞我們新的過程，我們提供了四個展示，至少有一個小組已經決定采用我們的一些經驗。變革在成長。
成功孕育成功
當管理層嘗試推動改變過程時，從最初的懷疑和憤怒，我們在這個過程中經歷了巨大的變革。這些曾經著名的過程都是那些所有刊物都討論過，當作福音傳授給我們的同事。當我回頭看看我們的小組，我驚奇于我們從使用一個版本控制系統(tǒng)改變到幾個可重用性、文檔化過程，甚至將那些經驗出售給別人。什么能夠允許我們背離我們正規(guī)的商業(yè)方式
對于我們來說，在開展新的過程中最重要的因素是一個成功的戰(zhàn)士，他醞釀了過程改革中的興趣。這個戰(zhàn)士應該是一個受到尊敬的開發(fā)人員，在小組里的，因持續(xù)工作而聞名，因渴望經驗的增長而受人尊重。在我們的事中，我們有二位戰(zhàn)士，我的同事Sean Ahern和我自己。在我們興奮于可能的好處并開始著手于一些改革后，小組的其他人信服了并跟隨我們。當管理層決定了過程必須跟隨時，來自小組外的壓力出現(xiàn)了。對于外來的，組員將可能排斥它，對此我不能強調得足夠多。然而，來自里受人尊敬的組成員的狂熱，開發(fā)人員感到是必須聽從。畢竟，這些人們事實上知道到底它象個什么樣子。一旦其他團隊里的人看到了真正的好處，他們就會跳進這個潮流中，變革也就會良好的進行下去。當開發(fā)人員開始思考改進過程的方式，獲取真正的好處時，好戲就開始了
你如何開始你的變革？每次一個改變。一旦明顯有好處，你的同事就會加入到你的行列中，同你一起征服編程世界。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
CMM、TSP、PSP講義稿
Blueski
CMM/TSP/PSP應該是目前世界上公認的最好的軟件管理模式。
CMM提供了框架和目標，PSP針對個人進行優(yōu)化，TSP針對團隊進行優(yōu)化。
以下提供的是一些CMM/TSP/PSP 介紹的幻燈片。壓縮為cmmtsppsp.zip，打開后共有4個文件，其中cmmtsppss.ppt是主文件，帶有對其它文件的連接。
點擊下載：
下載-->> 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ā)的各個階段并為其帶來益處。
目錄
• 簡介
• 使用反復、周期性的設計過程
• 構思階段
• 規(guī)劃階段
• 開發(fā)階段
• 穩(wěn)定化階段
• 為下一版本做準備
________________________________________
簡介
可用性測試為您帶來的好處
簡言之，如果將可用性測試從產品開發(fā)周期的一開始一直貫徹到項目的每一階段中，將使您在最后的處理過程中省去重新開發(fā)這一環(huán)節(jié)。
本文首先討論重復、周期性的設計過程。第一部分闡述了以用戶為中心進行設計時的四個原則，這是由 Gould、Boies 和 Lewis 提出的。接下來介紹了兩種類型的產品設計過程：“瀑布式”方法和“螺旋式”方法。本文的其余部分將簡要介紹產品開發(fā)的各個階段，并討論可用性活動是如何滲透各個階段并帶來益處的。此處所述的開發(fā)階段包括：構思、規(guī)劃、開發(fā)、穩(wěn)定化以及為下一版本做準備。
在您閱讀各小節(jié)時，請注意用戶將頻繁地參與到各個過程中。用戶對每個階段的介入將會在項目的收尾階段為您省去成本高昂的返工工作，而且這樣開發(fā)出來的產品將使用戶樂于使用、易于學習，并會長期使用。
使用反復、周期性的設計過程
反復、周期性的設計過程為以用戶為中心進行的設計帶來了極大的便利。以用戶為中心的設計有四個重要原則，這些原則是由 Gould、Boies 和 Lewis 于 1991 年提出的：
• 及早以用戶為中心：設計人員應當在設計過程的早期就致力于了解用戶的需要。
• 綜合設計：設計的所有方面應當齊頭并進發(fā)展，而不是順次發(fā)展。使產品的內部設計與用戶界面的需要始終保持一致。
• 及早并持續(xù)性地進行測試：當前對軟件測試的唯一可行的方法是根據(jù)經驗總結出的方法，即若實際用戶認為設計是可行的，它就是可行的。通過在開發(fā)的全過程引入可用性測試，可以使用戶有機會在產品推出之前就設計提供反饋意見。
• 反復式設計：大問題往往會掩蓋小問題的存在。設計人員和開發(fā)人員應當在整個測試過程中反復對設計進行修改。
多年來，“瀑布式”的產品設計過程是軟件設計的標準。在這一方法中，項目開發(fā)通過分階段發(fā)展的、按順序的各個階段進行。這種方法使用重大事件作為轉變點和評估點，并認為在下一階段開始前，前面的每一階段均已結束?！捌俨际健钡姆椒▽τ趶碗s的項目很有效。在復雜的項目中，多個供應商負責項目的各個方面（例如，一個供應商負責需求分析，另一個負責規(guī)范，等等）。但是，使用這種方法可能導致隨著項目的進展，對項目進行更改越來越難。
相形之下，“螺旋式”的產品設計過程卻是反復、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。這一過程允許更大地發(fā)揮創(chuàng)造性，并且更易于隨著項目的進展而對項目進行修改。在進行螺旋式的設計過程時，您會發(fā)現(xiàn)可在各個階段對產品各方面的功能進行設計。這種方法可為以用戶為中心的產品開發(fā)過程帶來便利。
螺旋式的產品設計過程有六個階段：構思、規(guī)劃、建模、開發(fā)、穩(wěn)定化以及為下一版本做準備。
構思階段
產品開發(fā)的構思階段是確定項目的目標和范圍的階段。此階段要確立構思陳述、設計目標、風險評估以及項目構架。
在構思階段，通常進行下列可用性活動：
環(huán)境研究
基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一書中所述的方法，此類型的研究包括觀察用戶的所做所為，使您更為直觀地了解用戶行為。如果您尚未決定究竟要開發(fā)何種軟件，但認為存在市場機會，就可使用環(huán)境研究來對活動進行研究。您可了解可為用戶做些什么以及實現(xiàn)的難易程度。不是尋求具體的功能，而是尋求設計機會。
環(huán)境研究為項目提供工作的重心。如果項目是全新的項目，或是較全面的升級，這種方法最為適用。在進行較全面的升級或開展全新項目時，您無法全面了解用戶在做什么、如何做、以及他們所面臨的問題或困擾。而進行較小的升級時，您有可能從產品支持部門、先前的研究等處獲得這些信息。在這種情況下，您基本上是對現(xiàn)有的設計加以完善，所以環(huán)境研究并不是不可或缺的。
環(huán)境研究在以下情況最為適合：項目組進行跨學科的環(huán)境研究，小組由可用性工程師帶領。
競爭性測試
通過競爭性可用性測試，您可以為產品設置量化的可用性目標 — 任務完成的速度、每項任務出錯的數(shù)目，等等。這種方法可對項目的成功與否進行量化的度量，即使所進行的競爭只是人工過程，而您將對此過程進行自動化。競爭性測試經常用于市場開發(fā)。當市場開發(fā)代表對競爭對手進行評估時，他們只比較產品的功能?？捎眯詼y試則更側重于使用這些功能完成任務時的性能。
競爭性測試對僅用于公司內部的產品來說，似乎不大適用。但是，如果仔細考慮，從理論上而言，您也是在與產品的先前版本或前一個流程競爭。內部產品可能與人工過程進行競爭 — 產品必須比現(xiàn)有的進程更有效、更好。
進行競爭性測試的方法之一是開展研究，比較與其相競爭的產品的性能。例如，對其他人員的產品進行性能研究。在選擇要測試的競爭產品時，要考慮到計算機之外的產品：如果產品涉及在線交易，則競爭性產品就可以是電子貨幣。從研究結果中您可以確定使用最頻繁的、最重要的功能。
用戶/受眾分析
了解您的用戶！盡可能采取各種方法來了解您的用戶的特點?？紤]一下如果您基于產品最終用戶的特點來開發(fā)軟件，可減少多少技術支持電話的數(shù)量。設想一下用戶是否認為產品易于使用并且包含了他們所需的功能。問自己“對于我要創(chuàng)建的產品，哪些用戶特點是與之相關的？”，例如：
• 計算機使用經驗
• 年齡
• 接受培訓的程度
• 用戶群之間的社會關系
• 特殊要求（可訪問性）
您可以通過環(huán)境研究來獲得一些此類信息。例如，您可對一些用戶進行觀察以得出一些假設，然后通過調研或取樣來驗證這些假設。您的人力資源部門或培訓部門可能會具有一些相關的信息；例如每個新雇員要接受多少培訓。市場研究人員也可能有此類信息。對于公司內部使用的應用程序而言，收集這些信息有時會比對外出售的應用程序簡便，因為您的用戶是具體的群體而不是普通大眾。
規(guī)劃階段
規(guī)劃階段是進行首次實際設計的階段。在此階段中，有關用戶界面的早期設想將初步成形，并著重于先前階段未涉及的知識。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的簡單描繪圖紙、打印在紙上的屏幕位圖圖形，用 Macromedia Director 之類的程序創(chuàng)建的帶有有限交互功能（也稱為“點閱”）的聯(lián)機版本，或是用 HTML 或 Microsoft Visual Basic® 創(chuàng)建的帶有大量交互功能的聯(lián)機版本。在大多數(shù)情況下，您會發(fā)現(xiàn)原型具有的仿真度越高，用戶建議進行重大修改的可能性就越低。所以，用寫在紙上的原型來開始著手測試是非常值得采取的做法。
根據(jù)您所設計的產品種類，您可能需要進行下述的一些或所有活動。如果您在規(guī)劃階段花時間來完成這些任務并使用原型，則在開發(fā)階段碰到的可用性問題將會大為減少。
用戶情況
創(chuàng)建您自己的用戶情況概要，列出產品的典型用戶能做什么，不能做什么。通過早期的環(huán)境研究和用戶/受眾分析，您做出一些較高級別的決策，基于這些決策進行軟件設計。使用用戶情節(jié)，您可創(chuàng)建一個有關用戶使用您所設計的軟件的“故事”。這些情況可以是情節(jié)串聯(lián)圖板、聯(lián)機 Macromedia Director 電影、簡單的流程圖、或簡單的敘述性文本。一種比較精致的用戶情節(jié)模式是“日常生活”錄像。這種錄像把演員作為“用戶”顯示，這些用戶在日常活動中與模擬的系統(tǒng)進行交互。通過用戶情節(jié)可得出您在任務分析時要尋找的具體細節(jié)。
任務分析
任務分析決定了在新產品中執(zhí)行任務的方式。在撰寫規(guī)范之前，必須首先進行任務分析。用任務分析來確定您所規(guī)劃的支持的任務是否確實能夠反映現(xiàn)實，這一點是很重要的。對任務的逼真度進行分析。就產品的特性而言，任務的完整性如何？分析逼真度意味著觀察用戶完成一項任務所必須執(zhí)行的所有操作；或進行表象的觀察，了解用戶完成所有任務或功能所需執(zhí)行的所有操作。無需擔心過于詳盡 — 把重點放在實質內容上。
一些要考慮的問題和活動：
• 此環(huán)境中的任務是什么？環(huán)境研究應能幫助您找出并描述用戶所執(zhí)行的任務。
• 創(chuàng)建順序圖，描述用戶執(zhí)行的任務之間、用戶和產品之間的相互作用。
• 在構思階段確定功能的作用領域。提出問題：“我們要支持的具體任務是什么？”
• 與產品設計者一起創(chuàng)建情節(jié)串聯(lián)圖板或順序簡圖。
啟發(fā)式評估
啟發(fā)式評估涉及評估人員小組，這些評估人員查看界面并基于基本可用性原則來對其做出判斷。啟發(fā)式評估允許您在整個反復式設計過程中查找并更正可用性問題。如果您在工作進展的同時糾正問題，您將在收尾階段節(jié)省大量工作。因為在收尾階段，更改真實代碼將更加困難而且成本更高。
如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，啟發(fā)式評估包括以下步驟：
1. 每個評估人員都瀏覽數(shù)遍界面，檢查各種對話框元素，然后將其與一些已知的可用性原則相比較。
2. 評估人員相互合作，將結果合并到列表中，列出用戶界面中的可用性問題，并注明設計方案中違反的相關可用性原則。
3. 一旦每個評估人員都分別執(zhí)行了啟發(fā)式評估后，他們就集中起來將其評估結果合并在一起。
在開發(fā)的早期階段，啟發(fā)式評估可能是發(fā)現(xiàn)可用性問題的非常有效的方法。
認知性遍歷
認知性遍歷的意思是，仔細檢查界面要求用戶執(zhí)行多少步驟以及何種步驟后，才能完成某項任務，其中包含用戶必須經過思考才能完成的那些步驟。您需要關注的是用戶必須調用什么或用戶必須進行的計算 — 認知性任務決定學習和使用您的產品的難易程度。認知性遍歷可幫助您找出潛在的可用性問題，以及找出您制訂的規(guī)范中的破綻！
根據(jù) Gregory Abowd 的 Performing a Cognitive Walkthrough，要進行認知性遍歷活動，需要以下四個條件：
1. 對系統(tǒng)原型的詳盡描述，例如初級規(guī)范可提供什么樣的系統(tǒng)。這種描述不一定是完整的，但要相當詳盡。諸如菜單的位置或措辭這樣的細節(jié)也可能導致相當大的差異。
2. 對用戶在系統(tǒng)中要完成的任務的描述。該任務應當是大多數(shù)用戶將要執(zhí)行的有代表性的任務。
3. 一個完整的、書面的操作清單，列出使用給定原型完成任務所需執(zhí)行的操作。
4. 指出用戶的身份，以及評估人員能夠假定這些用戶已具有哪一類別的知識和經驗。
有了這些信息，評估人員可執(zhí)行一遍上文第三項所列的操作，從而確定用戶是否能夠按預期要求合理執(zhí)行這些步驟。
GOMS
GOMS 是描述任務和用戶執(zhí)行該任務所需知識的方法，它是通過目標 (Goal)、操作符 (Operator)、方法 (Method) 以及選擇規(guī)則 (Selection rule) 四個方面進行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他們還創(chuàng)建了一個簡化的版本，即擊鍵級別模型 (KLM)。Bonnie E. John 開發(fā)了并行活動版本 CPM-GOMS，而 David Kieras 則開發(fā)出定義更為嚴謹?shù)陌姹荆鹤匀?GOMS 語言 (NGOMSL)。所有這些技術都基于同一 GOMS 概念。
• 不言自明，目標就是指用戶的目標。用戶使用軟件要達到什么目的？在下一天、下幾分鐘、下幾秒鐘？
• 操作符是指軟件允許用戶采取的操作。
• 方法是子目標和操作符經仔細設計后得出的序列，可用來實現(xiàn)諸如剪切和粘貼等目標。
• 選擇規(guī)則是用戶要遵守的判定規(guī)則，以確定在特定環(huán)境下要使用的方法。
GOMS 模型由對方法的描述組成，這些方法是達到目標所必需的。方法是一些步驟，這些步驟包括用戶為達到目標所需執(zhí)行的操作符。如果有一種以上的方法可以達到目標，則需使用選擇規(guī)則來確定在此情況下哪種方法更為適用。
卡片排序
卡片排序是一種可用性技術，用于此階段的早期，以了解用戶關于信息的總體模型?？ㄆ判虻幕救蝿帐且寘⑴c者按卡片上的說明對卡片進行組織，將屬于同一類的項目堆放在一起。在創(chuàng)建好堆后，參與者還可為所創(chuàng)建的堆建立名稱、標簽或說明。
卡片排序用于：
• 展示用戶對于任務范圍的總體模型。
• 展示用戶如何對項目進行分組或分類的。
• 展示用戶對項目之間的關系和相似性的看法。
• 將用戶的概念模型轉換為設計。
反復可用性測試
對原型設計的反復可用性測試是另一種很有價值的方法，用于在產品周期的早期階段確定界面是否易于用戶使用。在此階段進行更改比等到開發(fā)階段開始后再進行更改要更容易些，并且成本更低。
您從可用性實驗室可以收集的數(shù)據(jù)量取決于原型的強健性。對于紙上原型測試，可用性工程師就是計算機，并且在測試的過程中與用戶在一起。
在許多種情況下，嚴謹?shù)目捎眯詼y試是過猶不及的。在建模階段，您仍可使用簡化的方法進行有效的可用性測試，這些方法通常稱為“打折扣的”可用性測試。
如 Jakob Nielsen 所述，反復的可用性測試包括：
1. 用戶和任務觀察 — 觀察用戶，保持安靜，讓用戶做一切通常情況下會做的操作。
2. 情況 — 使用一種可以減少功能數(shù)量、降低功能級別的建模方法。
3. 簡化的對談式測試 — 一次安排一個用戶完成一組任務，并要求用戶“發(fā)現(xiàn)問題就直接告知測試人員”。
4. 啟發(fā)式評估 — 基于基本可用性原則來評價界面。
開發(fā)階段
開發(fā)階段是將產品用實際的代碼來實現(xiàn)的階段。在此階段中，您可以對實際產品的早期版次進行可用性測試。您仍有可能不時要用到原型，但隨著時間的推移產品將逐漸完善。不是所有的功能都將在開發(fā)階段同時完成，所以您有可能在原型和實際代碼之間往復轉換。
在理想條件下，您將可以把大部分時間用來進行推敲，在建模階段就能夠找出主要問題。
真實代碼測試
讓用戶測試真實代碼版本可能會有助于針對在計算機上使用產品發(fā)現(xiàn)問題。這些問題更有可能是設計問題而非概念問題。它們通常涉及相當?shù)图壍慕换プ饔脝栴}，如在屏幕上選擇項目、拖放，以及僅在實際產品中才有的動態(tài)圖形。對于產品的大多方面，真實代碼不一定比設計上的原型或其它模型的真實度更高，所以不要拖延到有真實代碼后再進行可用性測試。
可用性實驗室測試
在開發(fā)階段，您可進行可用性實驗室測試，該測試類似于規(guī)劃階段的反復可用性測試。但是，由于產品的更多部分已趨于完善，您可測試更多任務。您仍可在 Director 中使用模型，或將稍做修改的版次用在可用性測試中。隨著時間的推移，產品會越來越完善，原型就越來越不象一個模型了。但是，用“已完成”產品進行測試的問題在于，由于已進行了如此之多的工作，剩下的時間如此之少，您就不能指望對發(fā)現(xiàn)的問題做太多的修改了。
注意： 作為此任務的一部分，您還可能進行焦點組分析或群集分析，以對產品進行可用性測試。
穩(wěn)定化階段
當開發(fā)結束、錯誤已修正后，就進入了穩(wěn)定化階段。在此階段中，要創(chuàng)建一個可發(fā)售的穩(wěn)定的產品。在此階段對可用性進行測試的重點是進行微調。新的功能以及代價高昂的可用性增強功能應被記錄下來，以備下一版本使用。
基準測試
對可用性進行基準測試類似于“質量保證”中的綜合測試。基準測試的目的是通過測試用戶想要完成的所有頂級任務，就產品的可用性提供可靠的量化數(shù)據(jù)。這些測試的目標與其說是要找出問題（雖然找出問題是大多數(shù)可用性測試的目的），不如說是要評估產品可用性的狀態(tài)。
要進行基準測試，請首先觀察產品的功能，然后將這些功能按任務細分。在穩(wěn)定化階段，特別是對于復雜的產品，您將不能對用戶界面進行可提高每個任務性能的修改。理想情況下，您可以確定哪些是頂級任務，并且確保大多數(shù)頂級任務都是可用的。低優(yōu)先級的任務的可用性可以較低，可記錄下來在將來的版本中再作改進。
為下一版本做準備
將此階段視為開始對過程進行回顧的階段。您將全面考慮在構思階段和規(guī)劃階段所進行的許多相同任務。例如，您將進行：
• 競爭性測試 — 在穩(wěn)定化階段，這種測試是對自己的產品進行測試，以將其與先前收集的有關競爭產品的數(shù)據(jù)作比較。
• 現(xiàn)場研究 — 類似于環(huán)境研究（該研究是要了解“我們要做什么軟件？”），使用您已構建的軟件來找出存在哪些問題，可在下一版本加以解決。
• 關于事件的工具化版本研究 — 軟件的工具化版本基本上用來觀測軟件自身并在發(fā)生事件時記錄數(shù)據(jù)。您在大量會話和用戶的基礎上對產品進行測量以找到使用趨勢。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
如何組織軟件開發(fā)團隊
專家、多面手還是他們的組合？
Scott W. Ambler
總裁，Ronin International
2000 年 11 月 2 日
本文來自IBM DeveloperWorks中國網站
如何構建軟件開發(fā)團隊取決于可供選擇的人員、項目的需求以及組織的需求。本文闡述了各種團隊組織的策略。
有效的軟件項目團隊由擔當各種角色的人員所組成。每位成員扮演一個或多個角色；可能一個人專門負責項目管理，而另一些人則積極地參與系統(tǒng)的設計與實現(xiàn)。常見的一些項目角色包括：
• 分析師
• 策劃師
• 數(shù)據(jù)庫管理員
• 設計師
• 操作／支持工程師
• 程序員
• 項目經理
• 項目贊助者
• 質量保證工程師
• 需求分析師
• 主題專家（用戶）
• 測試人員
您是如何組織項目團隊的？是采用垂直方案、水平方案還是混合方案？以垂直方案組織的團隊由多面手組成，每個成員都充當多重角色。以水平方案組織的團隊由專家組成，每個成員充當一到兩個角色。以混合方案組織的團隊既包括多面手，又包括專家。
一個重要的考慮因素是可供選擇的人員的性質。如果大多數(shù)人員是多面手，則您往往需要采用垂直方案，同樣，如果大多數(shù)人員是專家，則采用水平方案。如果您正引入一些新人，即使這些人員都是合同工，則仍然需要優(yōu)先考慮您的項目和組織。本文描述了形成團隊組織的垂直、水平和混合方案，并指出了它們各自的優(yōu)缺點。本次討論的一個重要含意是您的團隊組織和用于管理項目的手段之間應構成默契；任何方法上的失諧都很可能導致項目產生問題。
垂直團隊組織
垂直團隊由多面手組成。用例 分配給了個人或小組，然后由他們從頭至尾地實現(xiàn)用例。
優(yōu)點
• 以單個用例為基礎實現(xiàn)平滑的端到端開發(fā)。
• 開發(fā)人員能夠掌握更廣泛的技能。
缺點
• 多面手通常是一些要價很高并且很難找到的顧問。
• 多面手通常不具備快速解決具體問題所需的特定技術專長。
• 主題專家可能不得不和若干開發(fā)人員小組一起工作，從而增加了他們的負擔。
• 所有多面手水平各不相同。
成功因素
• 每個成員都按照一套共同的標準與準則工作。
• 開發(fā)人員之間需要進行良好的溝通，以避免公共功能由不同的組來實現(xiàn)。
• 公共和達成共識的體系結構需要盡早在項目中確立。
水平團隊組織
水平團隊由專家組成。此類團隊同時處理多個用例，每個成員都從事用例中有關其自身的方面。
優(yōu)點
• 能高質量地完成項目各個方面（需求、設計等）的工作。
• 一些外部小組，如用戶或操作人員，只需要與了解他們確切要求的一小部分專家進行交互。
缺點
• 專家們通常無法意識到其它專業(yè)的重要性，導致項目的各方面之間缺乏聯(lián)系。
• “后端”人員所需的信息可能無法由“前端”人員來收集。
• 由于專家們的優(yōu)先權、看法和需求互不相同，所以項目管理更為困難。
成功因素
• 團隊成員之間需要有良好的溝通，這樣他們才能彼此了解各自的職責。
• 需要制定專家們必須遵循的工作流程和質量標準，從而提高移交給其他專家的效率。
混合團隊組織
混合團隊由專家和多面手共同組成。多面手繼續(xù)操作一個用例的整個開發(fā)過程，支持并處理多個使用例中各部分的專家們一起工作。
優(yōu)點
• 擁有前兩種方案的優(yōu)點。
• 外部小組只需要與一小部分專家進行交互。
• 專家們可集中精力從事他們所擅長的工作。
• 各個用例的實現(xiàn)都保持一致。
缺點
• 擁有前兩種方案的缺點。
• 多面手仍然很難找到。
• 專家們仍然不能認識到其他專家的工作并且無法很好地協(xié)作，盡管這應該由多面手來調節(jié)。
• 項目管理仍然很困難。
成功因素
• 項目團隊成員需要良好的溝通。
• 需要確定公共體系結構。
• 必須適當?shù)囟x公共流程、標準和準則。
項目團隊士氣是項目成功的一個因素
大部分項目成功的定義說的是項目如何按時完成、是否在預算內以及是否滿足用戶的需要。但是，在如今要找到好的軟件專業(yè)人員都非常困難，更不用說留住他們的這種情況下，還需要將項目成功的定義擴展為包括項目團隊的士氣。可能在努力完成一個軟件項目后，不料卻因為壓榨他們過度而失去了重要的開發(fā)人員，這樣做可能會符合組織的短期需要，但它對構建一個高效的軟件部門的長遠利益來說肯定是有害的。衡量項目成功與否的一個重要手段是項目結束后團隊的士氣。在項目結束之際，項目團隊的各個成員是否覺得他們從自己的經歷中學到了一些知識、是否喜歡為這次項目工作，以及是否希望參與組織的下一個項目都是非常重要的。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
軟件項目管理（CMM）經驗談
（張鳳岐 2001年07月04日 （電腦商報）
編者按：
CMM認證是當今IT界最熱的話題之一，這表明中國軟件企業(yè)已開始重視與軟件項目管理有關的問題了。為了了解國內軟件企業(yè)對軟件項目管理的認識程度以及他們在軟件項目管理方面的具體做法，日前，記者采訪了開思、東方通、瑞星三家純軟件公司的相關負責人。三家公司中，東方通業(yè)已開始按照CMM規(guī)范進行軟件開發(fā)。在采訪中，三家公司的負責人分別介紹了各自企業(yè)在軟件項目管理方面的經驗。開思公司的產品總監(jiān)石宏峰先生還為記者詳細講解了開思公司的《產品部開發(fā)規(guī)范》。
經過整理，我們將東方通和瑞星兩家公司的負責人在采訪中所說的主要內容刊登于此。我們相信，其具有一定的認識價值。另外，我們將開思公司《產品部開發(fā)規(guī)范》的一部分也刊登于此——我們并不認為開思的規(guī)范就是最好的規(guī)范。對軟件項目管理而言，普適性是不存在的，好壞是相對的，適用不適用才是絕對的——我們相信，其具有一定的參照價值?！?
加強相關教育和培訓
朱律瑋（東方通科技首席軟件設計師）
楊樺（東方通科技總經理助理）
東方通科技從去年底開始為參加CMM認證（二級）做準備。擬議中正式參評的時間是今年11月。在這之前我們會請國內咨詢公司的有關專家和國外的評估師進行兩次預評估。
半年多來，我們覺得一切還算順利。起初我們擔心編程人員會有抵觸情緒——因為每完成一天的工作或一道工序或一個項目后都要做記錄、編文檔、寫報告，較之以前，工作量無疑是增加了——后來看看，大家對執(zhí)行CMM規(guī)范還是理解的、支持的。
按照CMM規(guī)范開展工作后，到目前為止，公司的運營成本是增加了——因為要增加管理人員、撰寫文檔也需要人手——但從長遠看，其會帶來降低成本、提高質量、提高用戶滿意度等好處。對此，我們確信不疑。
與國外相比，我們在軟件工程管理方面的差距不僅表現(xiàn)為管理體制、管理方法、管理思想的陳舊，整個軟件業(yè)的落后才是根源。
個人英雄主義情結、喜歡單打獨斗是我們的民族性之一，其在軟件人才身上表現(xiàn)得尤為明顯，已成為中國軟件企業(yè)做大的一個瓶頸。造成這種狀況的原因，除了國內軟件業(yè)的發(fā)展水平不高、軟件項目規(guī)模不大和軟件企業(yè)管理者自身素質不高外，還有很重要的一點，即與軟件工程管理有關的教育內容幾乎沒有。在國外，PSP和GSP均為軟件專業(yè)學生的必修課，可在國內，這兩門課在學校里至今還沒有開起來。國外施行的是定崗培訓，比如撰寫文檔就是一門專業(yè)課，專門有人修它，畢業(yè)后拿它來“安身立命”，國內則是大家過獨木橋，統(tǒng)統(tǒng)都學寫程序。應該說，目前國內同行對軟件工程管理的重要性已有了一定的認識，但在相關人員的培訓上下的力氣仍遠遠不夠。
其實人才才是最關鍵的?，F(xiàn)在軟件業(yè)最缺的人才之一就是產品經理，他們是軟件工程管理的主角。產品經理必須具備以下素質：具有長期的軟件開發(fā)經驗——般來講，要在8年以上；了解用戶的需求；對產品熟、對市場熟——他可以不了解一個產品的底層技術，但必須了解其功能，能把握其發(fā)展方向；具有協(xié)調能力。總之，產品經理并不一定非常聰明，并不需要在某一方面特別突出，但要八面玲瓏。這樣的人才太難找了。東方通的產品經理都是自己培養(yǎng)的。
CMM規(guī)范并非只適用于大型軟件企業(yè)，其也適用于中小型企業(yè)。CMM規(guī)范只是一個框架、綱要性質的東西。企業(yè)在落實它時要細化一次；企業(yè)將其落實到具體的某個項目時，要再細化一次；中小企業(yè)可以不像大型企業(yè)那樣將CMM規(guī)范細化得那么細，夠用就好，不要教條。
實施CMM規(guī)范、通過CMM認證有如下一些好處：確定工作流程和方式，從而使產品的質量和開發(fā)的可延續(xù)性有了保證；可以提高企業(yè)在用戶中的信譽度，增加企業(yè)與強勢公司競爭的籌碼；可以承接國際大公司的外包項目———美國公司愿意找印度公司來承接其外包項目，就是因為印度公司對CMM規(guī)范普遍比較重視，通過CMM認證的軟件企業(yè)也多；公司不再受制于人，人走了，事照做，這是一個公司成熟的表現(xiàn)。
軟件商業(yè)化的必要手段
談文明（北京瑞星科技股份有限公司研發(fā)部經理）
中國軟件產業(yè)發(fā)展時間不長，雖然已有部分技術達到國際水平，但由于商業(yè)環(huán)境還不夠完善，在軟件技術的商業(yè)化與軟件工程管理等方面，與國際同行相比，還存在差距。
只有率先將技術先進的產品推向市場的公司才會贏得利潤。在瑞星，技術商品化已被當作一種制度，它有助于提高整個企業(yè)的素質。
瑞星意識到在充滿競爭的環(huán)境中要獲得成功，天才人物是必不可少的，但他們并不是全部。目前，一個軟件工程的成功更多地要依靠科學家、工程師、制造人員和銷售人員的協(xié)同努力。
在軟件商業(yè)化的過程之中，建立規(guī)范化的易于操作的軟件開發(fā)行為規(guī)范是首先要做的工作。針對殺毒軟件的特點，瑞星專門設計了瀑布模型結合增量模型的開發(fā)方式，即將項目分階段來實現(xiàn)。首先實現(xiàn)市場最需求的核心功能，然后在此基礎上繼續(xù)開發(fā)，每個單獨的階段都采用瀑布模型的開發(fā)方式。
具體地說，一個基本的軟件開發(fā)流程包括需求階段、系統(tǒng)設計階段、詳細設計階段、編碼階段、單元測試階段、集成測試階段、系統(tǒng)測試階段、軟件發(fā)布軟件維護階段。其中決定軟件開發(fā)成功與否的關鍵階段是：軟件需求管理、軟件計劃管理、軟件質量管理和軟件配置管理。
為了在用戶和處理用戶需求的軟件項目組之間達成共識（用戶由最終用戶、高層領導、銷售人員和市場調研人員組成），“軟件需求規(guī)格說明書”是必不可少的。經過正式的評審和確認，其將成為后續(xù)工作的基礎。
軟件項目的實施過程是根據(jù)軟件項目的資源、約束條件和執(zhí)行能力確定的，因此需要制定合理的軟件工程管理計劃，這是項目經理的職責之一。項目經理應定期檢查“項目開發(fā)計劃書”，按照當前項目開發(fā)的實際情況，對其進行調整。
為了保證每一個軟件產品都合乎需求，需要設立一個負責項目監(jiān)督和協(xié)調的SQA。其會對軟件產品是否符合定義好的軟件過程中的相應部分進行審查、復審和測試。公司高層主管應該定期參與、評審SQA的活動。
軟件配置管理是指在整個工程期間對項目的所有軟件配置項進行規(guī)范化管理。如采用版本控制軟件對軟件配置項版本進行版本控制，采用基線管理方法對變化進行控制，即在遵循軟件工程標準的基礎上對整個軟件進行控制和管理，維護其完整性、一致性和可跟蹤性。
瑞星努力營造的是一個廣泛的網絡，研發(fā)、制造、銷售、分銷和服務，連續(xù)進行。圍繞著產品、市場和開發(fā)階段而不是單純的技術來組織各項工作。為了這個目的，標準操作是必不可少的。
附錄：開思公司《產品部開發(fā)規(guī)范》?。ㄕ?br>
說明：第一部分為《目錄》，從中可以看出開思公司《產品部開發(fā)規(guī)范》的整體架構；第二部分為《開發(fā)規(guī)范概述》，從中可以看出開思公司在軟件項目管理方面的一些具體做法。
1 目 錄
1 目的
2 開發(fā)規(guī)范概述
2．1 應用項目管理管理開發(fā)過程
2．2 標準的階段性開發(fā)工作
2．2．1 總體規(guī)劃
2．2．2 項目立項
2．2．3 需求分析
2．2．4 系統(tǒng)分析
2．2．5 系統(tǒng)設計
2．2．6 編碼實現(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 具體工作內容
3．1．1．3．1 資料收集（可選）
3．1．1．3．2 資料研究（可選）
3．1．1．3．3 項目需求報告編制
3．1．1．3．4項目需求報告討論準備
3．1．1．3．5 項目需求報告討論
3．1．1．3．6 項目需求報告修改
3．1．1．3．7 項目需求報告驗收
3．1．1．4 參與者及職責
3．1．1．5 輸出成果及后序工作
3．1．2 技術可行性實驗（可選）
3．1．3 項目計劃書
3．2 項目立項
3．2．1 立項申請
3．2．2 項目立項評估
3．2．3 項目進度計劃
3．2．4 項目立項審批
3．3 需求分析
3．3．1 資料收集
3．3．2 需求分析編制
3．3．3 討論準備
3．3．4 需求分析討論
3．3．5 需求分析修改
3．3．6 需求分析驗收
3．4 系統(tǒng)分析
3．4．1 系統(tǒng)分析準備
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)設計
3．5．1 系統(tǒng)設計準備
3．5．2 界面設計
3．5．3 建立設計模型
3．5．4 系統(tǒng)設計合并
3．5．5 對象持久化設計
3．5．6 詳細設計
3．5．7 系統(tǒng)設計測試
3．5．8 系統(tǒng)設計修改（測試后）
3．5．9 系統(tǒng)設計驗收
3．6 編碼實現(xiàn)
3．6．1 編碼準備
3．6．2 編碼
3．6．3 編碼單元測試（測試工作）
3．6．4 單元測試后編碼修改
3．6．5 編碼聯(lián)調
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)設計測試
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 項目工作總結
4．1 項目任務數(shù)
4．1．1 總任務數(shù)
4．1．2 階段任務數(shù)
4．2 輸出成果
2 開發(fā)規(guī)范概述
2．1 應用項目管理管理開發(fā)過程
產品部接受的各種開發(fā)任務均以項目形式出現(xiàn)，包括：新產品開發(fā)，產品維護（錯誤修改、功能增強、缺陷完善等），產品客戶化開發(fā)及維護等，全程使用項目管理方法進行控制和管理。
根據(jù)項目規(guī)模和難易有大、小，繁簡之分。每個項目的完成周期要控制在6個月以內，項目規(guī)?？刂圃?0個人月內。過大的項目需要拆分成多個小的項目來完成。30個人月以上的項目稱為大項目，10個人月以內的項目稱為小項目。
每個項目要根據(jù)具體情況拆分成工作階段，即里程碑，以便對項目進度的有效控制與檢測。
2．2 標準的階段性開發(fā)工作
2．2．1 總體規(guī)劃
全面規(guī)劃項目工作的內容，確定目標市場、技術指標和應用要求，劃定項目工作范圍和交付成果，明確項目實現(xiàn)的總體設想和實施方案；確定項目中的新技術的可行性；明確項目需要用到的各種資源，估算項目的工作量和成本。
2．2．2 項目立項
產品部對要進行的開發(fā)項目進行立項申請，提交項目資料。由公司的有關人員對項目進行一系列的風險評估。
通過風險評估的項目，由產品部進行詳細進度計劃安排，落實時間進度、資源（人員／設備、內部／外部）、技術、資金和費用等，相關資源和資金使用計劃要詳細列出。
最后所有的項目申請資料、風險評估報告及產品進度計劃都要報給公司上級領導審批，進行立項評審。
立項通過的項目才能進入正式的開發(fā)工作。
2．2．3 需求分析
根據(jù)項目需求報告界定的工作范圍和應用方案的設計思路，進一步深入細化應用方案，描述將要開發(fā)出計算機系統(tǒng)中包含的各項業(yè)務是如何做的，及業(yè)務流程、相關理論、運算公式、原理、業(yè)務數(shù)據(jù)、單據(jù)報表格式等。
2．2．4 系統(tǒng)分析
根據(jù)項目需求分析，對將要建立的滿足用戶需求的計算機系統(tǒng)進行分析。在系統(tǒng)分析過程中采用面向對象分析技術（OOA）劃分需求的問題域，對每一個問題域進行分析和抽象，對其中的事物和它們之間的關系產生正確的認識，找出描述問題域及其系統(tǒng)責任所需的類及對象，定義這些類和對象的屬性與服務，以及它們之間所形成的結構、靜態(tài)聯(lián)系和動態(tài)聯(lián)系。最終產生一個符合用戶需求，并能夠直接反映問題域和系統(tǒng)責任的面向對象的分析模型。
2．2．5 系統(tǒng)設計
根據(jù)項目需求分析和系統(tǒng)分析，針對具體實現(xiàn)中的人機界面、數(shù)據(jù)存儲、任務管理等內容，運用面向對象設計技術（OOD）進行系統(tǒng)設計。主要包括UI設計、對象設計和數(shù)據(jù)庫表設計。
2．2．6 編碼實現(xiàn)
根據(jù)系統(tǒng)設計的結果，運用面向對象的方法進行程序編碼（OOP）以實現(xiàn)系統(tǒng)設計的內容。
編碼過程就是用具體的數(shù)據(jù)結構來定義對象的屬性，用具體的語言來實現(xiàn)服務流程圖所表示的算法。在對象設計階段形成的對象類和關系最后被轉換成特殊的程序設計語言、數(shù)據(jù)庫或者硬件的實現(xiàn)。
2．2．7 項目測試
對系統(tǒng)分析、系統(tǒng)設計、程序編碼等運用面向對象的方法進行測試（OOT）。項目的測試工作貫穿項目的整個開發(fā)過程。主要包括：分析（OOA）測試、設計（OOD）測試和編碼（OOP）測試，以及集成測試和系統(tǒng)測試。
2．2．8 文檔制作
跟隨項目開發(fā)過程應產生的文檔主要包括三類：
（1）開發(fā)文檔：分析、設計、編碼、測試以及各種開發(fā)管理文檔等資料；
（2）用戶文檔：在線幫助，安裝指南，使用手冊，技術手冊，培訓教材等；
（3）宣傳資料：產品介紹資料，產品白皮書，產品宣傳PPT，演示光盤等。
2．2．9 項目驗收
對完工的項目按照驗收步驟進行驗收。驗收過程中對項目的情況給予評價。
2．2．10 項目版本化發(fā)布
對驗收通過的項目進行版本控制，整理項目版本包含的內容并版本化，發(fā)布產品發(fā)布通告。
2．3 項目組織
每個項目指定一個項目經理進行管理，同時指定一個分析、設計人員（來自分析設計組）負責對技術問題的管理。當任務涉及到多個職能組的工作時（有些項目可能只涉及單一的職能組），由項目經理根據(jù)項目工作安排與職能組的組長進行協(xié)調，由職能組的組長來協(xié)助安排本組承擔的項目工作，指定組內人員來完成相關工作。項目經理根據(jù)各職能組長的安排匯總編制整個項目的進度計劃，并根據(jù)最終形成的項目計劃對項目進行控制和管理。
項目進行過程中需按照項目管理的要求對項目進行跟蹤、總結，各職能組的人員要對這些工作給予積極的支持和配合。產品委員會（或產品部內部）不定期組織人員對項目進行審查，確保項目的進度和質量。
項目完工后需要由產品委員會組織對項目進行驗收。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
實施軟件質量保障體系CMM/TSP/PSP的建議
軟件產業(yè)的發(fā)展，在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特征的結構化生產時代，到90年代中期，以CMM模型的成熟模型和日益為市場接受為標志，已經進入以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心的時代，而軟件發(fā)展第三個時代，及軟件工業(yè)化生產時代，從90年代中期軟件過程技術的成熟和面向對象技術、構件技術的發(fā)展為基礎，已經漸露端倪，估計到2005年，可以實現(xiàn)真正的軟件工業(yè)化生產，這個趨勢應該引起軟件企業(yè)界和有關部門的高度重視，及早采取措施，跟上世界軟件發(fā)展的腳步。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業(yè)或遲或早都要走的道路。軟件過程改善是當前軟件開發(fā)技術的核心問題。
--------摘自北京航空航天大學軟件工程研究所周伯生教授的《CMM評估基本要點及最新動態(tài)》學術報告
引言
50多年來計算事業(yè)的發(fā)展使人們認識到要高效率、高質量和低成本地開發(fā)軟件，必須改善軟件生產過程。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業(yè)或遲或早都要走的道路。軟件工業(yè)已經或正在經歷著"軟件過程的成熟化"，并向"軟件的工業(yè)化"漸進過渡。規(guī)范的軟件過程是軟件工業(yè)化的必要條件。
軟件過程研究的是如何將人員、技術和工具等組織起來，通過有效的管理手段，提高軟件生產的效率，保證軟件產品的質量。
軟件過程的理論研究與實踐成果
n 國際
n 國內
國 際
軟件過程的三個流派：
CMU-SEI的CMM/PSP/TSP
SO 9000質量標準體系
SO/IEC 15504（SPICE）
CMU-SEI的CMM/PSP/TSP
20世紀80年代中期國際軟件產業(yè)界對軟件的研究十分重視，因為在采用軟件工程方法克服軟件危機的過程中，人們認識到，軟件是否完善是軟件風險大小的決定因素。這方面的研究取得了重大的突破，其標志是1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發(fā)表的研究成果"承制方軟件工程能力的評估方法"，該成果在1991年發(fā)展成為CMM（軟件過程能力成熟度模型）。軟件過程能力成熟度模型被國際軟件界公認為軟件工程學的一項重大成果。軟件目前，軟件能力成熟度模型2.0版已經修訂問世。CMM在軟件工程的實踐方面已有很大的影響，在工業(yè)界已得到廣泛接受。不僅已用于軍事控制系統(tǒng)，而且已用于全球經濟領域的主要組織。有數(shù)千個組織在利用CMM的軟件過程改進。在美國，關于CMM模型的教程已經作為參考和研究的對象出現(xiàn)了，這樣做是為了讓CMM模型極其相關問題引起工業(yè)界的更密切地關注?；贑MM模型的工具如成熟度問題集，軟件過程評估訓練和軟件能力評價訓練已經在CMM中漸漸得到修訂。近期的關于CMM的活動主要是發(fā)展關于CMM模型的不同版本。由于CMM并未提供有關實現(xiàn)CMM關鍵過程域所需的具體知識和技能，因此，美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發(fā)了個體軟件過程PSP（Personal software process）和群組軟件過程TSP(Team Software Process)，形成CMM/PSP/TSP體系。
ISO 9000質量標準體系
最初的軟件質量保證系統(tǒng)是在70年代由歐洲首先采用的，其后在美國和世界其他地區(qū)也迅速地發(fā)展起來。目前，歐洲聯(lián)合會積極促進軟件質量的制度化，提出了如下ISO9000軟件標準系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002。這一系列現(xiàn)已成為全球的軟件質量標準。除了ISO9000標準系列外，許多工業(yè)部門、國家和國際團體也頒布了特定環(huán)境中軟件運行和維護的質量標準，如：IEEE標準729-1983、730-1984、Euro Norm EN45012等。
ISO/IEC 15504（SPICE）
CMM的方法很快就引起了軟件界的廣泛關注，1991年國際標準化組織采納了一項動議，開展調查研究，在此后引發(fā)了一系列的研究工作，現(xiàn)已取得重要成果，產生了技術報告ISO/IEC 15504《信息技術-軟件過程評估》，預計于今年產生正式標準。從該技術報告的內容來看，其基本的目的和思路，均與CMU/SEI的CMM相似。
目前，學術界和工業(yè)界公認美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發(fā)的軟件能力成熟度模型CMM是當前最好的軟件過程，已成為業(yè)界事實上的軟件過程的工業(yè)標準。
國 內
學術界：中國生產力促進協(xié)會、北航SEI、中科院研究SEI等科研機構已于近幾年在北京、上海、廣州和深圳等地先后舉辦過多次報告會和研討會，組織過課程學習和應用實驗，開展了軟件過程方面的研究與開發(fā)工作，并發(fā)表了多篇的研究成果和學術論文，在軟件質量保障平臺支撐環(huán)境也取得了一定的成果。
產業(yè)界：近兩年來，CMM在我國獲得了各界越來越多關注，業(yè)界有過多次關于CMM的討論，國務院發(fā)布的《鼓勵軟件產業(yè)和集成電路產業(yè)發(fā)展的若干政策》對中國軟件企業(yè)申請CMM認證給予了積極的支持，在第17條規(guī)定"對軟件出口型企業(yè)CMM認證費用予以適當支持。"2000年中國村電腦節(jié)上還有CMM專題論壇，吸引了眾多業(yè)內人士。鼎新、東大阿爾派、聯(lián)想、方正、金蝶、用友、浪潮、創(chuàng)智、華為、東大阿爾派等大型集團或企業(yè)等都從1997---2000年起批企業(yè)都在進行研究、實驗或實施預評估。其中鼎新公司從1997年著手進行CMM認證工作。1999年7月通過第三方認證機構的CMM2認證。東大阿爾派公司于2000年10月通過第三方認證機構的CMM2認證。2001年1月，聯(lián)想軟件經過英國路透集團的嚴格評估，順利通過CMM2認證。
總體上講，國內對軟件過程理論的討論與實踐正在展開，目標是使軟件的質量管理和控制達到國際先進水平，中國的軟件產業(yè)獲得可持續(xù)發(fā)展的能力。專家分析，在未來兩三年內，國內軟件業(yè)勢必將出現(xiàn)實施CMM的高潮。從這一趨勢看，中國的軟件企業(yè)已經開始走上標準化、規(guī)范化、國際化的發(fā)展道路，中國軟件業(yè)已經面臨一個整體突破的時代。
軟件質量保障體系的實施
根據(jù)一直以來對國際上軟件過程理論與實踐的發(fā)展、尤其是近幾年來著重在CMM、PSP和TSP以及ISO軟件過程標準草案等方面的研究工作，國內專家學者建議，軟件過程的改善應該從三方面著手進行：
o 軟件能力成熟度模型CMM(Capability Maturity Model)
o 個體軟件過程PSP (Personal Software Process)
o 群組軟件過程TSP(Team Software Process)
三者各有側重，但互為補充。
CMM
o 迄今為止學術界和工業(yè)界公認的有關軟件工程和管理實踐的最好的軟件過程。
o 為評估軟件組織的生產能力提供了標準。
o 為提高軟件組織的生產過程指明了方向。
CMM軟件過程成熟度模型概要*
1、 比較
在介紹CMM內容之前，首先概述一下不成熟軟件組織與成熟軟件組織的差異。在不成熟的軟件單位，軟件過程一般由實踐者及其管理者在項目進程中臨時拼湊而成，因而推遲進度和超出預算已成為慣例，產品質量難以預測，有時為了滿足進度要求，常在產品功能和質量上做出讓步。
然而，一個成熟軟件組織具有在全組織范圍內管理軟件、開發(fā)過程和維護過程的能力，規(guī)定的軟件過程被正確無誤地通知到所有員工，工作活動均按照已規(guī)劃的過程進行。并通過可控的先導性試驗和費效分析使這些過程得到改進，對已定義過程中的所有崗位及其職責都有清楚的描述，和通過文檔與培訓使全組織有關人員對已定義的軟件過程都有很好的理解，從而使其軟件過程所導致的生產率和質量能隨時間的推移得到改進。
表1給出了不成熟和成熟軟件組織的比較，這種比較分析不僅是形成軟件能力成熟模型的基礎，也有利于理解該模型。
2、 CMM的一些基本概念
?。?）軟件過程：人們用于開發(fā)和維護軟件及其相關過程的一系列活動，包括軟件工程活動和軟件管理活動。
?。?）軟件過程能力：描述（開發(fā)組織或項目組）遵循其軟件過程能夠實現(xiàn)預期結果的程度，它既可對整個軟件開發(fā)組織而言，也可對一個軟件項目而言。
?。?）軟件過程性能：表示（開發(fā)組織或項目組）遵循其軟件過程所得到的實際結果，軟件過程性能描述的是已得到的實際結果，而軟件過程能力則描述的是最可能的預期結果，它既可對整個軟件開發(fā)組織而言，也可對一個特定項目而言。
?。?）軟件過程成熟：一個特定軟件過程被明確和有效地定義，管理測量和控制的程度。
（5）軟件能力成熟度等級：軟件開發(fā)組織在走向成熟的途中幾個具有明確定義的表示軟件過程能力成熟度的平臺。
?。?）關鍵過程域：每個軟件能力成熟度等級包含若干個對該成熟度等級至關重要的過程域，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟件成熟度等級的目標不起關鍵作用。歸納為：互相關聯(lián)的若干軟件實踐活動和有關基礎設施的一個集合。
?。?）關鍵實踐：對關鍵過程域的實踐起關鍵作用的方針、規(guī)程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什么"而不強制規(guī)定"如何做"。整個軟件過程的改進是基于許多小的、漸進的步驟，而不是通過一次革命性的創(chuàng)新來實現(xiàn)的，這些小的漸進步驟就是通過一些著關鍵實踐來實現(xiàn)。
?。?）軟件能力成熟度模型：隨著軟件組織定義、實施、測量、控制和改進其軟件過程，軟件組織的能力也伴隨著這些階段逐步前進，完成對軟件組織進化階段的描述模型。
3、 CMM模型概要
軟件開發(fā)的風險之所以大，是由于軟件過程能力低，其中最關鍵的問題在于軟件開發(fā)組織不能很好地管理其軟件過程，從而使一些好的開發(fā)方法和技術起不到預期的作用。而且項目的成功也是通過工作組的杰出努力，所以僅僅建立在可得到特定人員上的成功不能為全組織的生產和質量的長期提高打下基礎，必須在建立有效的軟件工程實踐和管理實踐的基礎設施方面，堅持不懈地努力，才能不斷改進，才能持續(xù)地成功。
CMM提供了一個框架，將軟件過程改進的進化步驟組織成5個成熟等級，為過程不斷改進奠定了循序漸進的基礎。這5個成熟度等級定義了一個有序的尺度，用來測量一個組織的軟件過程成熟和評價其軟件過程能力，這些等級還能幫助組織自己對其改進工作排出優(yōu)生次序。成熟度等級是已得到確切定義的，也是在向成熟軟件組織前進途中的平臺。每一個成熟度等級為連續(xù)改進提供一個臺基。每一等級包含一組過程目標，通過實施相應的一組關鍵過程域達到這一組過程目標，當目標滿足時，能使軟件過程的一個重要成分穩(wěn)定。每達到成熟框架的一個等級，就建立起軟件過程的一個相應成分，導致組織能力一定程度的增大。
下面表2給出了CMM模型概要，表中的5個等級各有其不同的行為特征。要通過描述不同等級組織的行為特征：即一個組織為建立或改進軟件過程所進行的活動，對每個項目所進行的活動和所產生的橫跨各項目的過程能力。
表2 CMM模型概要
4、 CMM的結構
軟件機構的最終質量保證模式可以用下圖1說明，圖1給出軟件質量計劃、質量控制、質量改進一個簡單循環(huán)，其實，它歸納出CMM的真正內核，所以，可以說CMM的模型是一種新興管理思想：連續(xù)改進（Continuos Improvement）循環(huán)的體現(xiàn)。
圖1
CMM的作用
n 科學地評價軟件開發(fā)單位的軟件能力成熟等級
n 幫助軟件開發(fā)單位進行自檢，了解自己的強項和弱項，從而不斷完善和改進單位的軟件開發(fā)過程，確保軟件質量，提高軟件開發(fā)能效率。
CMM實施的思考
根據(jù)CMM的基本原理、基本內容和基本方法，對CMM提出4個問題供大家思考：
1. 過程成熟度需要多長時間？多少費用？對企業(yè)有何好處？
2. 影響基于CMM的軟件過程的成敗因素是什么？
3. CMM是否會導致過度官僚主義？是否會使組織變得更保守，不愿冒風險？
4. 有無合適的、易理解的框架（不僅僅是告訴"我們做什么"，而且告訴"我們怎么做"）可指導所有軟件組織進行CMM改進？
這些針對CMM提出的問題與爭論，國外進行了一些調查工作，但國內基本上沒有這方面的專業(yè)調查和研究，以后再根據(jù)國內企業(yè)對CMM的認識、認證的增強和增多，這些問題會得到更科學的解答。
現(xiàn)給出國外針對上述問題的一些調查結果：
問題1：成熟度提升一級建議安排1年到2年，費用問題國內外相距太遠不好比較。對企業(yè)的好處問題給出下表說明：
問題2：影響過程改進失敗的因素有：無法實施計劃和跟蹤、突發(fā)事件或危險造成、時間和資源限制造成、知道應該做什么而不知道如何做造成。
問題3：大部分（84%-96%）不認為會使組織變成官僚主義機構、難于創(chuàng)新和不敢冒風險。
問題4：這需要不斷總結經驗，提出辦法。
在國內要想取得過程改進成功，作者認為：
1、 軟件過程改進必須有高級主管的支持與委托，并積極地管理過程改進的進展。
2、 中層管理的支持很重要
3、 責任分明，過程改進小組威望高
4、 基層的支持與參與極端重要
5、 如何利用定量的可觀察數(shù)據(jù)，盡快使過程改進成果可見，從而激勵參與者的興趣
6、 為企業(yè)的商業(yè)利益服務，并要求有成功的過程改進相符的企業(yè)文化變革
如果企業(yè)出現(xiàn)如下情況，過程改進肯定就失?。?br> 1、 高層領導機構態(tài)度不明確，見解不一致
2、 各部門只管自己，互不通氣，互不支持
3、 對以前不成功的過程改進冷嘲熱諷
4、 項目成員認為軟件過程改進會影響實際工作，而不支持軟件過程改進活動
結論：CMM不是萬能的，它的成功與否，與一個組織內部有關人員的積極參與和創(chuàng)造性活動是密不可分的。
CMM是對軟件工程的工業(yè)實踐所需的有關目標、方法和實踐的最佳有效描述。問題是如何在一個實驗室或者產業(yè)環(huán)境中做到CMM規(guī)則的應用？
CMM是一個致力于組織過程改進的框架，問題是如何才能確保CMM使工作有效而且便利？
未提供有關實現(xiàn)關鍵過程域所需要的具體知識和技能。
因此，個體軟件過程PSP(Personal Software Process)也就應運而生。
PSP概述
個體軟件過程（Personal Software Process ,PSP）是由美國Carnegie Mellon大學軟件工程研究所(CMU/SEI)的Watts s. Humphrey領導開發(fā)的，于1995年它的推出，在軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個標志。PSP是一種可用于控制、管理和改進個人工作方式的自我改善過程，是一個包括軟件開發(fā)表格、指南和規(guī)程的結構化框架。 PSP為基于個體和小型群組軟件過程的優(yōu)化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質量，如何與其他人相互協(xié)作等等。在軟件設計階段， PSP的著眼點在于軟件缺陷的預防，其具體辦法是強化設計結束準則，而不是設計方法的選擇。根據(jù)對參加培訓的104位軟件人員的統(tǒng)計數(shù)據(jù)表明，在應用了PSP后，軟件中總的差錯減少了58.0％，在測試階段發(fā)現(xiàn)的差錯減少了71.0％，生產效率提高了20.0％。PSP的研究結果還表明，絕大多數(shù)軟件缺陷是由于對問題的錯誤理解或簡單的失誤所造成的，只有很少一部分是由于技術問題而產生的。而且根據(jù)多年來的軟件工程統(tǒng)計數(shù)據(jù)表明，如果在設計階段注入一個差錯，則這個差錯在編碼階段引發(fā)了3一5個新的缺陷，要修復這些缺陷所花的費用要比修復這個設計缺陷所花的費用多一個數(shù)量級。因此，PSP保障軟件產品質量的一個重要途徑是提高設計質量。
個體軟件過程PSP的現(xiàn)狀
o 從1993年開始，美國、歐洲、澳大利亞等地已先后有20多所大學開設了講授PSP的課程。
o 在工業(yè)界，PSP也先后在Motorola、 HP、 AIS等公司推廣使用。
o 北航軟件工程研究所于1997年開始，在北航計算機科學與工程系率先講授了PSP課程，并組織了PSP應用實驗。
個體軟件過程PSP的演化*
個體軟件過程PSP的內容
PSP與具體的技術（程序設計語言、工具或者設計方法）相對獨立，其原則能夠應用到幾乎任何的軟件工程任務之中。PSP能夠：
(1) 說明個體軟件過程的原則；
(2) 幫助軟件工程師作出準確的計劃；
(3) 確定軟件工程師為改善產品質量要采取的步驟；
(4) 建立度量個體軟件過程改善的基準；
(5) 確定過程的改變對軟件工程師能力的影響。
個體軟件過程PSP支持環(huán)境
北航軟件工程研究所在研制的基于Internet的"個體軟件過程支持環(huán)境"，支持個體軟件過程的定義、運作、度量、分析和優(yōu)化，支持PSP在實際軟件開發(fā)項目中的應用，支持PSP概念和方法的推廣普及，支持軟件工作人員軟件工程方面素質的提高。
個體軟件過程PSP的作用
l 使用自底向上的方法來改進過程，向每個軟件工程師表明過程改進的原則，使他們能夠明白如何有效地生產出高質量 的軟件。
l 為基于個體和小型群組軟件過程的優(yōu)化提供了具體而有效的途徑。其研究與實踐填補了CMM的空白。
l 幫助軟件工程師在個人的基礎上運用過程的原則，借助于PSP提供的一些度量和分析工具，了解自己的技能水平，控 制和管理自己的工作方式，使自己日常工作的評估、計劃和預測更加準確、更加有效，進而改進個人的工作表現(xiàn)，提 高個人的工作質量和產量，積極而有效地參與高級管理人員和過程人員推動的組織范圍的軟件工程過程改進。
群組軟件過程TSP概述
致力于開發(fā)高質量的產品，建立、管理和授權項目小組，并且指導他們如何在滿足計劃費用的前提下，在承諾的期限范圍內，不斷生產并交付高質量的產品。
TSP指導項目組中的成員如何有效地規(guī)劃和管理所面臨的項目開發(fā)任務，并且告訴管理人員如何指導軟件開發(fā)隊伍。始終以最佳狀態(tài)來完成工作。TSP實施集體管理與自己管理自己相結合的原則，最終目的在于指導開發(fā)人員如何在最少的時間內，以預定的費用生產出高質量的軟件產品，所采用的方法是對群組開發(fā)過程的定義、度量和改進。
實現(xiàn)TSP方法需要具備的條件
o 需要有高層主管和各級經理的支持，以取得必要的資源
o 整個軟件開發(fā)小組至少應在CMM的第二級（可重復層）。
o 全體軟件開發(fā)人員必須經過PSP的培訓，并有按TSP工作的愿望和熱情。
o 開發(fā)小組成員應在2到20個人之間。
在實施TSP的過程中，首先要有明確的目標，開發(fā)人員要努力完成已經接受的委托任務。在每一階段開始，要做好工作計劃。如果發(fā)現(xiàn)未能按期按質完成計劃，應立即分析原因，以判定問題是由于工作內容不合適或工作計劃不實際所引起，還是由于資源不足或主觀努力不夠所引起。開發(fā)小組一方面應隨時追蹤項目進展狀態(tài)并進行定期匯報，另一方面應經常評審自己是否按PSP的原理工作。開發(fā)小組成員應按自己管理自己的原則管理軟件過程，如發(fā)現(xiàn)過程不合適，應及時改進，以保證用高質量的過程來產生高質量的軟件。項目開發(fā)小組則按集體管理的原則進行管理，全體成員都要參加和關心小組的規(guī)劃、進展的追蹤和決策的制定等項工作。
按TSP原理對開發(fā)小組的基本度量要素
o 所編文檔的頁數(shù)。
o 所編代碼的行數(shù)。
o 花費在各開發(fā)階段或各開發(fā)任務上的時間（以分為單位）。
o 在各個開發(fā)階段中引入和改正的差錯數(shù)目。
o 在各個階段對最終產品增加的價值。
度量TSP實施質量的過程質量元素
o 軟件設計時間應大于軟件實現(xiàn)時間。
o 設計評審時間至少應占一半以上的設計時間。
o 代碼評審時間至少應占一半以上的代碼編制時間。
o 在編譯階段發(fā)現(xiàn)的差錯不超過10個/KLOC
o 在測試階段發(fā)現(xiàn)的差錯不超過5個/KLOC。
CMM、PSP和TSP組成的軟件過程框架
l CMM是過程改善的第一步，它提供了評價組織的能力、識別優(yōu)先改善需求和追蹤改善進展的管理方式。企業(yè)只有開始 CMM改善后，才能接受需要規(guī)劃的事實，認識到質量的重要性，才能注重對員工經常進行培訓，合理分配項目人員， 并且建立起有效的項目小組。然而，它實現(xiàn)的成功與否與組織內部有關人員的積極參加和創(chuàng)造性活動密不可分。
l PSP能夠指導軟件工程師如何保證自己的工作質量，估計和規(guī)劃自身的工作，度量和追蹤個人的表現(xiàn)，管理自身的軟 件過程和產品質量。經過PSP學習和實踐的正規(guī)訓練，軟件工程師們能夠在他們參與的項目工作之中充分運用PSP，從 而有助于CMM目標的實現(xiàn)。
l TSP結合了CMM的管理方法和PSP的工程技能，通過告訴軟件工程師如何將個體過程結合進小組軟件過程，并將后者與 組織進而整個管理系統(tǒng)相聯(lián)系；通過告訴管理層如何支持和授權項目小組，堅持高質量的工作，并且依據(jù)數(shù)據(jù)進行項 目的管理，向組織展示如何應用CMM的原則和PSP的技能去生產高質量的產品。
PSP和TSP對CMM的支持*
l CMM/TSP/PSP代表了目前國際上軟件過程工程研究方面最先進的成果，它們對促進軟件生產的科學化管理，提高軟件 生產能力意義重大。
l 軟件的生產過程及其它的許多子過程、軟件的開發(fā)者和用戶、以及系統(tǒng)的使用中存在著巨大的變化和不同，要使一個 軟件過程對軟件生產的改善真正有所幫助，其框架應是由CMM、TSP和PSP組成的一個完整體系，即從組織、群組和個 人三個層次進行良好的軟件工程和管理實踐的指導和支持?？偠灾?，單純實施CMM，永遠不能真正做到能力成熟度 的升級，只有將實施CMM與實施PSP和TSP有機地結合起來，才能發(fā)揮最大的效力。
建議
過程改善工作必然具有一切過程所具有的固有特征，即需要循序漸進，不能一蹴而就需要持續(xù)改善，不能停滯不前；需要聯(lián)系實際，不能照本宣讀需要適應變革，不能凝固不變。我認為，將CMM／PSP／TSP引人軟件企業(yè)最有效的途徑首先要對單位主管和主要開發(fā)人員進行系統(tǒng)的培訓。Carnegie Mellon大學軟件工程研究所曾嘗試讓軟件工程師通過自學的方式來進行，但實際上，只有不到20％的人能夠堅持到底。另外一個有效的途徑是自頂向下的課程培訓，即從高層主管依次普及到下面的工程師。
CMM就如同軟件生產的一面鏡子，以之來衡量自己可以折射出企業(yè)發(fā)展的水平以及具體的差距。借鑒CMM的方法，改進軟件研發(fā)項目管理，提高軟件開發(fā)水平。軟件研發(fā)項目管理管理是影響軟件研發(fā)項目全局的因素，而技術只影響局部。建議以CMM為框架，先從PSP做起，然后在此基礎上逐漸過渡到TSP，以保證CMM／PSP／TSP確實在企業(yè)中生根開花。我相信只要堅持改善軟件工程的管理，并在實踐中總結適合自身的經驗，一定能取得很好的效果。
不過強調一點，我們必須根據(jù)自身的實際制定可行的方案。不深入研究就照搬別的企業(yè)的模式是很難起到提高軟件產品質量水平的真正目的的。
/*
本文來自--
http://www.china-pub.com/computers/eMook/0891/info.htm
中國互動出版網
2001-4-10
*/
________________________________________
主頁 論壇 留言 打印 聯(lián)系
軟件開發(fā)質量保證體系
來自lannuo.533.net
________________________________________
1. 使用范圍
2. 引用標準
3. 定義
4. 質量體系框架
4.1 管理職責
4.2 質量體系
4.3 評審
4.4 糾正措施
5. 質量體系生存周期
5.1 合同評審
5.2 需方需求規(guī)格說明
5.3 開發(fā)計劃
5.4 質量計劃
5.5 設計和實現(xiàn)
5.6 測試和確認
5.7 驗收
5.8 復制、交付和安裝
5.9 維護
軟件開發(fā)質量保證體系
公司內部標準
本標準參照ISO9000-3 《質量管理和質量保證標準 第三部分：在軟件開發(fā)、供應和維護中的使用指南》。
1、 使用范圍
本標準作為本公司在軟件項目開發(fā)、供應和維護時的質量要求，以保證產品的質量，防止不合格產品。
以下詳細描述了軟件開發(fā)各階段的控制手段和要求。要求質量保證貫穿各個階段，始終保證嚴格實施。
2、 引用標準
本標準制定考慮本公司的實際情況，因此本標準僅用于本公司內部控制產品質量。
使用本文檔時，請盡量參照最新版本。
3、 定義
產品：以下指軟件產品，即交付給用戶的一整套計算機程序、規(guī)程及相關的文檔和數(shù)據(jù)。
開發(fā)：創(chuàng)作軟件產品的所有活動。
供方：指本公司。
需方：指具體項目的需求方，即客戶。
質量體系：質量要素、各要素需要達到的目標以及在開發(fā)過程中必須采取的措施。
4、 質量體系框架
4.1管理職責
4.1.1 供方(及具體的項目開發(fā)組)負責以下職責
組織機構
本公司內部專門設立部門質量保證部門，由部門負責人及專門經過培訓的人員組成。具體項目開發(fā)組，設立質量保證組，或委托公司質量保證部門協(xié)助開展工作。
質量保證部門負責以下工作：
建立并維護公司內部的質量保證體系。
對可能導致產品不合格的問題予以識別，采取措施予以避免。
發(fā)現(xiàn)并記錄產品的質量問題。
提出、采取或推薦問題解決辦法。
驗證解決辦法的實施效果。
對不合格產品的處理、交付過程進行控制，確保最終問題得以糾正。
質量保證部門的評審活動應由與被評審工作無直接責任的人員組成。
制定質量方針和質量目標
確保項目組成員均理解質量方針并能堅持貫徹執(zhí)行。
公司內部制定一般性的質量方針及對軟件產品的質量目標，作為各項目組的參照，各項目組可根據(jù)具體客戶期望及需求作出具體質量目標及質量承諾，具體質量目標及承諾，特別是超出公司目標的部分，提交給質量保證部門，以便提交給質量保證部門充分理解并協(xié)助實施。
《質量方針和質量目標》見附錄
管理評審
質量保證部門負責人應每月對質量體系進行評審，主要是對內部質量審核結果的評定，以保證質量體系持續(xù)有效，保存評審記錄。
4.1.2 需方（客戶）應負的職責
在項目中，應向需方（客戶）提出具體要求，明確其需要承擔的職責，以便相互配合，共同保證項目的順利實施。
需方應明確指定項目相關負責人，應具有足夠的權力處理以下問題：
向供方提出需求
回答供方提出的某些相關問題
認可供方的提案
與供方簽訂協(xié)議并能確保遵守簽訂的協(xié)議
規(guī)定驗收準則和規(guī)程
向供方提供必要的信息,提供有利的環(huán)境并解決項目中一些障礙。
4.1.3 共同評審
雙方定期地交流，并聯(lián)合評審軟件是否滿足已經商定的需求規(guī)格說明書。
4.2 質量體系
本質量體系貫穿整個開發(fā)周期，是為了在開發(fā)過程中保證質量，并非在開發(fā)結束時才檢查質量問題，所以重點強調防止問題地發(fā)生，問題發(fā)生后的糾正僅作為補充手段。
本公司將采取必要手段保證這一體系得以有效地貫徹實施。
質量體系文件
本公司的質量體系文件,包括質量要素、各要素需要達到的目標以及在開發(fā)過程中必須采取的措施。
質量體系文件見附錄《質量體系文件》
質量計劃
具體項目開發(fā)組根據(jù)公司質量體系制訂質量活動計劃并形成《質量保證計劃》，以保證開發(fā)組能正確理解質量體系并能遵照執(zhí)行。
附錄之《質量保證計劃指導》作為各項目組制訂計劃的指導。
4.3 審核
本公司內部建立全面的審核制度，以驗證各具體項目中的質量活動是否符合計劃要求，同時檢查質量體系的有效性，以不斷完善質量體系。
審核過程及采取的措施均要按書面方式進行。
審核結果形成報告，提交審核部門負責人。對于審核時發(fā)現(xiàn)的問題，相關負責人應及時采取措施。
4.4 糾正措施
糾正措施必須制定書面規(guī)程，應包括以下內容：
調查問題產生的直接原因，并制定防止同類事件發(fā)生所需的措施。
查詢分析各類過程記錄、讓步記錄、操作記錄、質量記錄、客戶投訴等等，已查明潛在原因并消除
根據(jù)風險程度，采取預防措施
對糾正措施的有效實施加以控制
對糾正措施的記錄
5. 質量體系生存周期
要求各階段必須有合格的產品（包括文檔），并以其作為下一階段的工作基礎。對每一階段的產品，必須組織評審，確保其質量，避免錯誤影響后續(xù)工作。
本標準適用于任何生存周期模型。
5.1 合同評審
本公司應評審每一合同，以確保：
規(guī)定合同的范圍和需求并寫入文檔
識別可能出現(xiàn)的風險
恰當?shù)谋Ｗo有關的專利信息
解決所有與招標不一致的需求
有能力滿足需求
規(guī)定其他涉及項目的供貨商的責任
統(tǒng)一雙方對術語的理解
需方有能力履行合同職責
合同評審記錄應妥善保管。
此外，應注意有關質量條款
驗收準則
在開發(fā)過程中對需求變更的處理
對驗收后出現(xiàn)問題的處理
確定需方的責任，尤其是在需求規(guī)格說明、安裝和驗收時的作用
有需方提供的必要便利條件，如設施、工具和軟件等
采用的標準和規(guī)程
5.2 需方需求規(guī)格說明
在某一具體項目進行開發(fā)前，本公司應具有一套該項目的完整、精確、無歧義的功能需求，這些需求應包括需方的所有要求。
因為本公司在業(yè)務領域具有豐富的經驗，可以大力配合客戶識別并確定需求，需求在開發(fā)前得到需方的確認。
該需求應足以成為產品驗收確認時的依據(jù)。
在制訂需求規(guī)格說明時應注意：
雙方制定專人負責
需求認可和更改的批準
防止誤解，定義好術語，對需求的背景進行說明
記錄和評審雙方討論的結果，以備將來查詢某些需求確定原因。
5.3開發(fā)計劃
在項目進行前制定開發(fā)計劃，作為總體的策劃，指導整個項目有序的進行。
開發(fā)計劃要求包括以下方面：
項目定義
項目資源組織管理
開發(fā)階段
進度
確定質量保證計劃、測試計劃、集成計劃等
隨著項目的進展，開發(fā)計劃要不斷更新，在生命周期模型每一階段開始之前，都要有該階段的工作計劃，并經過評審后實施。
以下較詳細的說明開發(fā)計劃中應具備的各方面。
A. 開發(fā)階段
開發(fā)計劃應將項目目標轉化為最終結果的過程、方法等清楚的描述出來，可以把工作分為幾個階段，比如按照生命周期法劃分開發(fā)階段。
開發(fā)階段要確定以下項：
要執(zhí)行的開發(fā)階段
每一階段所需的輸入
必須用文檔方式確定下來，每一項需求均有明確的定義，以保證完成情況可被檢驗。
每一階段應產生的輸出
驗證階段輸出，必須滿足以下幾點：
滿足相應的要求
有明確的驗收準則，作為驗收評審的參考。
符合開發(fā)慣例和約定
每一階段需要執(zhí)行的驗證步驟
必須有對每階段輸出的驗證計劃，并在適當?shù)臅r間進行驗證評審。
分析各階段可能潛在的問題或需要解決的問題
B. 項目管理
項目開發(fā)、實施等過程的時間進度安排
進度的控制方法及活動
確定組織機構及其職責、各工作組的資源及工作分配
不同工作組間的組織協(xié)調方法，并明確技術接口問題。
C. 開發(fā)方法和工具
規(guī)定項目活動應共同遵循的方法及使用的工具，包括：
開發(fā)規(guī)范、慣例
開發(fā)工具及技術
5.4 質量計劃
質量計劃作為開發(fā)計劃的一部分。
質量計劃隨項目進展而更新，質量計劃經正式評審，并得到所有與計劃執(zhí)行有關的組織的統(tǒng)一。
質量計劃應包含或引用以下內容：
質量目標，盡可能以定量方式給出
定義每一階段的輸入、輸出準則
確定要進行的測試、驗證和確認活動的類型和詳細計劃，包括時間、進度等。
確定具體質量活動的職責：比如，評審和測試、更改控制、對缺陷的控制和糾正措施。
5.5 設計和實現(xiàn)
設計和實現(xiàn)活動是將需求規(guī)格說明轉化為軟件產品的過程。為保證軟件產品的質量，這些活動必須在嚴格規(guī)定的方法下進行，不能依賴于事后的審查監(jiān)督。
設計
設計階段要滿足各階段的共同要求，此外，設計階段還應考慮：
選用適合所開發(fā)產品類型的設計方法
總結吸取以往項目的經驗教訓
設計應考慮軟件以后的測試、維護和使用
B. 實現(xiàn)
規(guī)定編程規(guī)則、編程語言、命名約定、編碼和注釋規(guī)則等
要求在實現(xiàn)過程中嚴格遵守既定開發(fā)規(guī)則
選用合適的方法和工具實現(xiàn)產品
本公司內部制定《開發(fā)規(guī)范》，各項目組可參照制定適合特定項目的規(guī)范。
C. 評審
為使需求規(guī)格說明得以滿足和上述規(guī)則方法得以實施，必須以評審的方式加以保證。直到所有被發(fā)現(xiàn)的缺陷被消除，或確定缺陷的風險可被控制后，才能進入下一步的設計或實現(xiàn)工作。
各項目組引用公司規(guī)范或參照制定的開發(fā)規(guī)范應在取得本項目組廣泛認可的情況下，提交給評審部門，作為評審參照依據(jù)。
評審紀錄應保存，評審結果可能作為個人及項目組工作成績評定的參考之一。
5.6 測試和確認
要具有完整的測試計劃，測試計劃要經過評審，并以此為依據(jù)進行測試活動。
A.測試計劃
包括單元測試計劃、集成測試計劃、系統(tǒng)測試計劃、驗收測試計劃
制定測試用例、測試數(shù)據(jù)和預期結果
考慮要進行的測試類型，如：功能測試、邊界測試、性能測試、可用性測試等
描述測試環(huán)境、工具以及測試軟件
軟件產品是否完成的判斷準則
測試所需人員及其要求
B.測試活動
記錄發(fā)現(xiàn)的問題，指出可能的受影響的其他部分的軟件，通知相關負責人員。
確定受影響的其他部分軟件，并對其進行重新測試。
評價測試是否適度和適當。
在驗收和交付產品前，必須盡可能在類似使用環(huán)境中進行確認測試。
5.7 驗收
當軟件產品已經完成，經過內部確認測試，準備好交付后，應要求需方根據(jù)合同中的規(guī)定原則判斷是否可以進行驗收。對于驗收中發(fā)現(xiàn)問題的處理辦法由雙方商定并納入文檔。
具備驗收條件后，應制定驗收計劃并逐步實施。
驗收計劃應包括：
時間進度
評估規(guī)程
軟件/硬件環(huán)境
驗收準則
5.8 復制、交付和安裝
制定安裝分發(fā)計劃。
復制
制作好安裝程序，復制好必要的拷貝。
準備好該交付的操作手冊、用戶指南等文檔。
交付
交付前應對所交付產品的正確性及完整性進行檢驗。
安裝
就以下方面雙方明確商定各自的作用、責任和義務：
時間進度及安排，包括非工作時間及假日的人員安排及工作責任
提供出入便利條件，如通行證等
指定熟練人員的密切配合
提供必要的系統(tǒng)及設備
對每次安裝的確認條件需明確規(guī)定
對每次安裝認可的正式規(guī)程
5.9 維護
對于軟件產品在初次交付及安裝后，本公司必須提供的維護應在合同中明確規(guī)定。合同中應明確以下各項的維護期：
程序
數(shù)據(jù)
規(guī)格說明
維護工作一般包括：
問題的解決
接口的調整
功能擴充和性能改進
本公司針對以上維護工作制訂完善的維護方案，并嚴格遵照執(zhí)行。具體維護方案見《維護工作流程》
附錄C 質量體系文件
包括質量要素、各要素需要達到的目標以及在開發(fā)過程中必須采取的措施
質量要求要素定義如下：
正確性 在預定環(huán)境下，軟件滿足設計規(guī)格說明及用戶預期目標的程度。它要求軟件沒有錯誤。
可靠性 軟件按照設計要求，在規(guī)定時間和條件下不出故障，持續(xù)運行的程度。
效率 為了完成預定功能，軟件系統(tǒng)所需的計算機資源的多少。
完整性 為了某一目的面保護數(shù)據(jù)，避免它受到偶然的，或有意的破壞、改動或遺失的能力。
可使用性 對于一個軟件系統(tǒng)，用戶學習、使用軟件及為程序準備輸入和解釋輸出所需工作量的大小。
可維護性 為滿足用戶新的要求，或當環(huán)境發(fā)生了變化，或運行中發(fā)現(xiàn)了新的錯誤時，對一個已投入運行的軟件進行相應診斷和修改所需工作量的大小。
可測試性 測試軟件以確保其能夠執(zhí)行預定功能所需工作量的大小。
靈活性 修改或改進一個已投入運行的軟件所需工作量的大小。
復用性 一個軟件（或軟件的部分）能再次用于其它應用（該應用的功能與軟件或軟件部件的所完成功能有聯(lián)系）的程度。
在設計開發(fā)過程中，必須注意以下要求，以保證軟件的質量達到目標。
正確性
軟件的功能要滿足用戶的要求，在預定環(huán)境下能夠完成預期的功能。因此，必須明確的了解用戶的需求。
在需求確定方面，應通過深刻的理解電信企業(yè)的運營系統(tǒng)及了解其發(fā)展趨勢，建立模型并分析，廣泛了解其他系統(tǒng)的特長，并總結以往的經驗教訓的基礎上，確定出需求并通過與用戶的交流最終確定。
在需求的表達方面，強調以全面、精確、細致、易于理解的方式表達，可能需要以多種形式，比如：功能描述、數(shù)據(jù)描述、數(shù)據(jù)流圖、系統(tǒng)說明等。
可維護性
遵從統(tǒng)一的規(guī)范，包括命名規(guī)范、界面規(guī)范、編程風格。
編碼應具有良好的可讀性，注釋完整清晰。
避免復雜的邏輯判斷條件，易讀，易測試
編碼應盡量簡練，邏輯簡單
保存異常信息與錯誤日志以便于調試與分析
降低模塊之間的耦合度，增強模塊內的內聚。
可用性
用戶容易理解和使用該功能
響應時間快，操作方便，提高用戶工作效率。
提示信息簡潔準確
可靠性
具有異常捕獲功能并提供異常處理與恢復功能
5、效率
盡量降低系統(tǒng)資源的開銷
查詢語句要充分考慮到索引
減少與數(shù)據(jù)庫的不必要的交互
靈活性，易于擴展
充分考慮到各地的不同的環(huán)境，通過參數(shù)設置使其易于適應不同的要求。
完整性、安全性
保證相關的數(shù)據(jù)一致性
考慮數(shù)據(jù)的存取權限。
文檔完善
按文檔要求完成相關文檔。
審查制度
對于每一階段的文檔及軟件產品都應交付證質量保證部門，由審查小組按質量要求嚴格審查。
審查內容：
文檔：開發(fā)計劃、用戶需求規(guī)格說明、概要及詳細設計文檔、技術文檔、用戶手冊等，詳細要求見文檔計劃。評審文檔是否規(guī)范，表達清晰，有實用價值。
設計方案：是否達到設計目標。
應用程序：是否達到質量目標和符合設計目標。
審查流程：
項目組按計劃準備好交付的產品及文檔
交付質量保證部門，組織評審
完成評審，發(fā)現(xiàn)錯誤報告
發(fā)現(xiàn)錯誤的返工
復查返工問題是否已解決
________________________________________
主頁 論壇 留言 打印 聯(lián)系
技術討論指南---如何“不戰(zhàn)而勝”
來自lannuo.533.net
________________________________________
限制參與者人數(shù)。精心選擇合適的人選，只讓必需的人參加，不必求全。
準備好討論問題，明確主要目的，將問題和目的書面化，這樣會更清晰，并讓參與者清楚地了解這些問題和目的。最好能給參與者比較充足的思考時間。
控制討論主題，避免離題。
注意突出重點、不要陷入細枝末節(jié)，一般能進入正式討論的問題不會是太瑣碎的問題。不要試圖在討論會上將所有作業(yè)完全做完，有些事情本應該會后進行，比如具體實現(xiàn)等。避免讓大家為個人做作業(yè)。
不能取得大家理解的問題暫時記錄在案，留待以后討論。有時一個問題被提出，但多數(shù)人并未理解該問題的重要性，除非能夠有效地解釋明白，否則應在時機更成熟時再討論。如果是關鍵核心問題當然另當別論。
不能期望取得絕對的一致，對分歧較大和爭執(zhí)不休的問題及時轉換角度，先討論判斷準則及衡量方法等，如果暫時沒有討論思路則記錄在案，留待以后討論。再更充分的思考后，更容易找到問題的關鍵點和思路。
做好書面記錄。對問題的解決做好文檔，被否定的思路也應該包含在文檔中，有利于以后理解方案選擇思路。
主持人的責任
充分理解討論目的，控制討論朝目標前進。必須做好前期準備。
對貶低和羞辱別人的行為嚴加約束。會前強調：“討論發(fā)言必需對產品而不能對人，絕對避免攻擊別人的行為，哪怕是以開玩笑的方式”，指出這樣的行為是不光彩的。討論期間如果不幸發(fā)生這樣的事情，果斷明確地指出。必要時（失去控制時）立即停止討論，不要勉強進行。正常地，引導討論在和諧的氣氛和態(tài)度中。
限制爭論和辯駁。將問題引導到判斷準則、衡量方法和解決思路上來。
制止冗長無效率的發(fā)言，制止離題的發(fā)言，制止進入瑣碎細節(jié)的發(fā)言。以簡單總結問題的方法或時間進度的理由搶回主動控制權。提醒和警告經常轉移問題的人，重申討論重點和目的。
總結討論成功與失敗的經驗，使自己和別人可以做得更好。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
任務管理
來自lannuo.533.net
概述
一個工程項目是由一系列的任務組成，合理地安排這些任務單元并保證其按時完成，才能保證整個項目進度能夠按時完成。為此我們制訂以下方法加強任務管理。
一個任務是包含在一個整體計劃環(huán)境中的，因此作為個體首先要服從于整體計劃。
任務管理方法
任務安排：
采用明確任務、明確責任的方式來安排任務。
下達任務必須書面化。
要求負責人明確、時限明確、任務表達明確、優(yōu)先順序明確。
明確任務的結果。
方法： 我們定制格式化任務安排表，附錄《任務安排工作單》即為一個實例。
協(xié)調及控制：
統(tǒng)一協(xié)調調度任務，及滿足每個人的任務量，又避免超負荷。并監(jiān)督任務能按時按質完成。
合理安排每個人的長期任務和緊急任務。
協(xié)調者必須監(jiān)督進度的進展，及時地調整或督促。
通過日常檢查監(jiān)控任務的進展。其中應特別關注關鍵路徑上的任務。
對重要任務進行正式評審。以保證其完成質量。
方法：
可以在定期舉行的例會上總結匯報工作。
為幫助統(tǒng)一管理任務及人力，我們設計了附錄《任務安排匯總表》，將任務、人力、進度三維統(tǒng)一表達，即可以看到一個任務由那幾個人來完成，及各自的角色，又可以看到每個人當前所承擔的所有任務，便于工作量均衡。進度跟蹤便于統(tǒng)計剩余任務工作量。
結果考評：
個人工作成績通過任務完成情況紀錄為依據(jù)。
任務等級定義
任務分為幾個等級，在安排任務時確定輕重緩急，任務等級作為安排者和執(zhí)行者間交流的一種簡潔的信息，包含了安排者在全局的層次上對任務的一種認識和理解，并將這種理解記錄下來，并傳達給執(zhí)行者，有利于執(zhí)行者能理解并按統(tǒng)一調度執(zhí)行任務。這樣可以更好地控制進度，避免關鍵或緊急任務被拖后。
對執(zhí)行者來說，可以有根據(jù)當前任務的優(yōu)先級，有條理地安排工作。
任務等級可從以下方面來考慮：
緊急程度：（對任務過程的時間要求）
寬松：時限十分寬松，可以在其他任務后考慮。
一般：時間比較充裕，可以合理安排進度。
較急：有明確要求的時限，且應該盡快著手盡快完成。一般在關鍵路徑上的任務至少有較急的級別。
緊急：立即著手，以盡快的速度解決問題。一般在任務進度可能造成較大影響時定義該級別，比如影響項目進度或影響客戶業(yè)務使用。具有較高的優(yōu)先級別，
特急：立即著手，需要時必須加班，需要趕赴現(xiàn)場時必須以最快的速度到達。需要其他人力配合時立即聯(lián)系相關人員。一般在對客戶業(yè)務造成重大影響時定義特急的級別。最高優(yōu)先級別。
注釋：緊急程度可能隨著時間變動。
重要程度：（對任務本身的影響及作用的估計）
不重要：任務失敗不會造成嚴重結果，能夠容忍。
普通：任務失敗會造成一定影響，能通過措施補救，不在關鍵路徑上，不影響整體進度，不影響客戶業(yè)務。
重要：任務重要，對整個系統(tǒng)或項目影響很大，比如在關鍵路徑上的任務，必須保證其成功完成。一般要在工期和質量上給以充分的控制。
關鍵：影響整個系統(tǒng)或項目的成敗，必須給予最高的重視，對任務進行充分的控制，確保成功完成。
任務排序優(yōu)先級：（任務執(zhí)行的先后次序，利于有條理的工作）
暫緩：盡量向后安排
普通：按順序安排
盡快：盡量向前安排
立即：安排在任務列表最前。
以上作為粗略地優(yōu)先級別估計，方便于優(yōu)先級的調整，缺省地，任務排序按照緊急在先、重要在先的原則排列。
特急 緊急 較急 一般 寬松
關鍵 *****！ ****！ ***！ **！ /
重要 ***** **** *** **
普通 / **+ *+ +
不重要 / + -
表中符號代表分值： *：20 ！：10 +：5 -：-5 /：不定義
附件一：任務匯總表（示例） 可打印格式見其word文檔 - 任務管理
任 務 匯 總 表 項目簡稱： 階段日期：
任務編號 任務概述 工作量 最后時限 人員A 。 。 人員N 計劃 分析 開發(fā) 測試 實施 反饋 完成時間
工作量：
d天 h小時 角色：M負責 A分析 D設計 P編碼 T測試 J輔助參與 進度：已完成則打勾
附件二：任務單（示例） 可打印格式見其word文檔 - 任務管理
任 務 單 任務編號
任務負責人簽字： 任務協(xié)調人：
重要級別：□關鍵 □重要 □普通 □不重要 工作量：
緊急級別：□特急 □緊急 □較急 □一般 □寬松 最后期限：
概述：
任務詳述：
完成日期：
任務負責人總結（如果任務延期或失敗，請說明原因）：
評價：□優(yōu)秀 □良 □基本滿意 □不滿意 □很差
備注：
________________________________________
主頁 論壇 留言 打印 聯(lián)系
項目管理篇系列之七 - 項目管理軟件
摘自www.computerworld.com.cn
左美云 李東 董小英等著
項目管理技術的發(fā)展與計算機技術的發(fā)展密不可分，隨著計算機性能的迅速提高，大量的項目管理軟件涌現(xiàn)出來。它們可以用于各種商業(yè)活動，提供便于操作的圖形界面，幫助用戶制定任務、管理資源、進行成本預算、跟蹤項目進度等。
具備的功能
目前，市場上大約有120多種項目管理軟件工具。這些軟件各具特色，各有所長。這里列出大多數(shù)項目管理軟件具備的主要功能。
1．成本預算和控制
輸入任務、工期，并把資源的使用成本、所用材料的造價、人員工資等一次性分配到各任務包，即可得到該項目的完整成本預算。在項目實施過程中，可隨時對單個資源或整個項目的實際成本及預算成本進行分析、比較。
2．制定計劃、資源管理及排定任務日程
用戶對每項任務排定起始日期、預計工期、明確各任務的先后順序以及可使用的資源。軟件根據(jù)任務信息和資源信息排定項目日程，并隨任務和資源的修改而調整日程。
3．監(jiān)督和跟蹤項目
大多數(shù)軟件都可以跟蹤多種活動，如任務的完成情況、費用、消耗的資源、工作分配等。通常的做法是用戶定義一個基準計劃，在實際執(zhí)行過程中，根據(jù)輸入當前資源的使用狀況或工程的完成情況，自動產生多種報表和圖表，如“資源使用狀況”表、“任務分配狀況”表、進度圖表等。還可以對自定義時間段進行跟蹤。
4．報表生成
與人工相比，項目管理軟件的一個突出功能是能在許多數(shù)據(jù)資料的基礎上，快速、簡便地生成多種報表和圖表，如甘特圖、網絡圖、資源圖表、日歷等。
5．方便的資料交換手段
許多項目管理軟件允許用戶從其他應用程序中獲取資料，這些應用程序包括Excel、Access、Lotus或各種 ODBC兼容數(shù)據(jù)庫。一些項目管理軟件還可以通過電子郵件發(fā)送項目信息，項目人員通過電子郵件獲取信息，如最新的項目計劃、當前任務完成情況以及各種工作報表。
6．處理多個項目和子項目
有些項目很大而且很復雜，將其作為一個大文件進行瀏覽和操作可能難度較大。而將其分解成子項目后，可以分別查看每個子項目，更便于管理。另外，有可能項目經理或成員同時參加多個項目的工作，需要在多個項目中分配工作時間。通常，項目管理軟件將不同的項目存放在不同的文件中，這些文件相互連接。也可以用一個大文件存儲多個項目，便于組織、查看和使用相關數(shù)據(jù)。
7．排序和篩選
大多數(shù)項目管理軟件都提供排序和篩選功能。通過排序，用戶可以按所需順序瀏覽信息，如按字母順序顯示任務和資源信息。通過篩選，用戶可以指定需要顯示的信息，而將其他信息隱藏起來。
8．安全性
一些項目管理軟件具有安全管理機制，可對項目管理文件以及文件中的基本信息設置密碼，限制對項目文件或文件中某些數(shù)據(jù)項的訪問，使得項目信息不被非法之徒盜取。
9．假設分析
“假設分析”是項目管理軟件提供的一個非常實用的功能，用戶可以利用該功能探討各種情況的結果。例如，假設某任務延長一周，則系統(tǒng)就能計算出該延時對整個項目的影響。這樣，項目經理可以根據(jù)各種情況的不同結果進行優(yōu)化，更好地控制項目的發(fā)展。
常見的項目管理軟件
根據(jù)項目管理軟件的功能和價格水平，大致可以劃分為兩個檔次：一種是供專業(yè)項目管理人士使用的高檔項目管理軟件，這類軟件功能強大，價格一般在2000美元以上，如Primavera公司的P3、Gores技術公司的 Artemis、ABT公司的WorkBench、Welcom公司的OpenPlan等。另一類是低檔項目管理軟件，應用于一些中小型項目，這類軟件雖功能不很齊全，但價格較便宜，如 TimeLine公司的TimeLine、Scitor公司的Project Scheduler、Primavera公司的 SureTrak、Microsoft公司的Project 2000等。
1．Microsoft Project 2000
Microsoft Project 2000是一種功能強大而靈活的項目管理工具，可用于控制簡單或復雜的項目。它能夠幫助您建立項目計劃、對項目進行管理，并在執(zhí)行過程中追蹤所有活動，使用戶實時掌握項目進度的完成情況、實際成本與預算的差異、資源的使用情況等信息。
Microsoft Project 2000的界面標準、易于使用，具有項目管理所需的各種功能，包括項目計劃、資源的定義和分配、實時的項目跟蹤、多種直觀易懂的報表及圖形、用Web頁面方式發(fā)布項目信息、通過Excel、Access或各種 ODBC兼容數(shù)據(jù)庫存取項目文件等。
2.Primavera Project Planner
Primavera Project Planner（簡稱P3）工程項目管理軟件是美國Primavera公司的產品，是國際上流行的高檔項目管理軟件，已成為項目管理的行業(yè)標準。
P3軟件適用于任何工程項目，能有效地控制大型復雜項目，并可以同時管理多個工程。P3軟件提供各種資源平衡技術，可模擬實際資源消耗曲線、延時；支持工程各個部門之間通過局域網或Internet進行信息交換，使項目管理者可以隨時掌握工程進度。P3還支持ODBC，可以與Windows程序交換數(shù)據(jù)，通過與其他系列產品的結合支持數(shù)據(jù)采集、數(shù)據(jù)存儲和風險分析。
3．SureTrak Project Manager
Primavera公司除了有針對大型、復雜項目的P3項目管理軟件以外，還有管理中小型項目的SureTrak。SureTrak是一個高度視覺導向的程序，利用SureTrak的圖形處理方式，項目經理能夠簡便、快速地建立工程進度并實施跟蹤。它支持多工程進度計算和資源計劃，并用顏色區(qū)分不同的任務。對于不同的人以不同方式建立的工程，SureTrak也能把它們放在一起作為工程組管理。此外，SureTrak還提供40多種標準報表，可任意選取、輸出所需要的信息。利用電子郵件和網上發(fā)布功能，項目組成員可進行數(shù)據(jù)交流，如上報完成情況、接收上級安排的任務等。利用VB、C++或SureTrak自身的SBL語言,可訪問SureTrak的開放式數(shù)據(jù)庫結構和OLE，必要時可把工程數(shù)據(jù)合并到其他信息系統(tǒng)。
4．CA-SuperProject
Computer Associates International公司的CA-SuperProject是一個很常用的軟件，適合于多種平臺，包括Windows、OS/2、 Unix/Solaris、DOS 和VAX/VMS等。大量的視圖有助于用戶了解、分析和管理項目的各方面。容易發(fā)現(xiàn)和有效解決資源沖突，并提供各種工具，使用戶在多個項目之間調整進度表和資源。CA-SuperProject先進和靈活的進度安排可以讓用戶準確模擬真實世界。還可以根據(jù)預定計劃、當前完成情況、剩余情況，精確地重新制定剩余部分的執(zhí)行計劃。
5．Project Management Workbench(PMW)
PMW項目管理軟件是應用商業(yè)技術公司（ABT）的產品，該軟件可以管理復雜的項目。它運行在Windows操作系統(tǒng)下，提供了對項目建模、分析和控制的圖形化手段，具有項目管理所需的各種功能，深受廣大工程人員的歡迎。
6．Project Scheduler
Project Scheduler是Scitor公司的產品，它可以幫助用戶管理項目中的各種活動。Project Scheduler的資源優(yōu)先設置和資源平衡算法非常實用，利用項目分組，用戶可以觀察到多項目中的一個主進度計劃，并可以分析更新。數(shù)據(jù)可以通過工作分解結構、組織分解結構、資源分解結構進行調整和匯總。Project Scheduler提供了統(tǒng)一的資源跟蹤工作表，允許用戶根據(jù)一個周期的數(shù)據(jù)來評價資源成本和利用率，還有詳細的“what if”分析功能，通過ODBC連接數(shù)據(jù)庫。
7．Time Line
Time Line是Symantec公司的產品，盡管該軟件對初學者來說使用稍感困難，但仍是有經驗的項目管理經理的首選。它除了具有項目管理的所有功能外，還具有報表功能和極強的與SQL數(shù)據(jù)庫連接的功能。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
項目管理系列之六-質量管理
摘自www.computerworld.com.cn
左美云 李東 董小英等著
目前，人們對信息系統(tǒng)項目提出的要求往往只強調系統(tǒng)必須完成的功能、應該遵循的進度計劃以及開發(fā)這個系統(tǒng)所花費的成本，卻很少注意在整個生命周期中信息系統(tǒng)應該具備的質量標準。這種做法導致系統(tǒng)維護費用增加，當需要把系統(tǒng)移植到另外的環(huán)境中或使系統(tǒng)與其他系統(tǒng)配合使用時，需要完成很多輔助工作，導致總擁有成本增加。
IS建設需要全面質量控制
信息系統(tǒng)的質量管理不僅僅是項目開發(fā)完成后的最終評價，還需要在信息系統(tǒng)開發(fā)過程中進行全面質量控制。也就是說，不僅包括系統(tǒng)實現(xiàn)時的質量控制，也包括系統(tǒng)分析、系統(tǒng)設計時的質量控制；不僅包括對系統(tǒng)實現(xiàn)時軟件的質量控制，而且還包括對文檔、開發(fā)人員和用戶培訓的質量控制。
之所以對信息系統(tǒng)采取全面質量控制，是因為在信息系統(tǒng)生命周期的各個階段，對上一階段的理解以及本階段的設計與實現(xiàn)上都存在著這樣那樣的問題。在圖1中，各階段之間的接口至少存在列出來的9個問題，要想順利解決每一個問題并非易事。
圖2 軟件質量與產品活動的關系
根據(jù)一些軟件公司的統(tǒng)計資料，在后期引入一個變動比在早期引入相同變動所需付出的代價高2～3個數(shù)量級。因此，我們應該從信息系統(tǒng)開發(fā)的初始階段就進行質量控制，以便盡量在早期發(fā)現(xiàn)錯誤，及早更正。
如何建立質量指標體系？
信息系統(tǒng)的質量比較難管理，原因之一是信息系統(tǒng)的質量指標難以定義，即使能夠定義，也較難度量。由于信息系統(tǒng)的核心是軟件，因此如何度量軟件的質量成為解決問題的關鍵。這里介紹一種從管理角度度量軟件質量的方法。
我們把影響軟件質量的因素分成三組，分別反映用戶在使用軟件產品時的三種不同傾向或觀點（圖2）。這三種傾向是：產品運行、產品修改和產品轉移。信息系統(tǒng)作為一個產品，也可以參照這三種傾向來定義。
圖1 信息系統(tǒng)生命周期各階段之間的關系
我們可以采取以下步驟實施全面質量控制：
1．實行工程化開發(fā)
“信息系統(tǒng)開發(fā)方法”一詞的廣義理解是“探索復雜系統(tǒng)開發(fā)過程的秩序”；狹義理解是“一組為信息系統(tǒng)開發(fā)起工具作用的規(guī)程”，按這些規(guī)程工作，可以較合理地達到目標。規(guī)程由一系列活動組成，形成方法體系。信息系統(tǒng)是一項系統(tǒng)工程，必須建立嚴格的工程控制方法，要求開發(fā)組的每一個人都要遵守工程規(guī)范。
2．實行階段性凍結與改動控制
信息系統(tǒng)具有生命周期，這就為我們劃分項目階段提供了參考。一個大項目可分成若干階段，每個階段有自已的任務和成果。這樣一方面便于管理和控制工程進度，另一方面可以增強開發(fā)人員和用戶的信心。
在每個階段末要“凍結”部分成果，作為下一階段開發(fā)的基礎。凍結之后不是不能修改，而是其修改要經過一定的審批程序，并且涉及到項目計劃的調整。
3．實行里程碑式的審查與版本控制
里程碑式審查就是在信息系統(tǒng)生命周期每個階段結束之前，都正式使用結束標準對該階段的凍結成果進行嚴格的技術審查，如果發(fā)現(xiàn)問題，就可以及時在階段內解決。
版本控制是保證項目小組順利工作的重要技術。版本控制的含義是通過給文檔和程序文件編上版本號，記錄每次的修改信息，使項目組的所有成員都了解文檔和程序的修改過程。廣義的版本控制技術稱為軟件配制管理，并已有功能完善的軟件工具支持，如PVCS和Microsoft Visual SourceSafe。
4．實行面向用戶參與的原型演化
在每個階段的后期，快速建立反映該階段成果的原型系統(tǒng)，通過原型系統(tǒng)與用戶交互，及時得到反饋信息，驗證該階段的成果并及時糾正錯誤，這一技術被稱為“原型演化”。原型演化技術需要先進的CASE工具的支持。
5．盡量采用面向對象和基于構件的方法
面向對象的方法強調類、封裝和繼承，能提高軟件的可重用性，將錯誤和缺憾局部化，同時還有利于用戶的參與，這些對提高信息系統(tǒng)的質量都大有好處。
基于構件的開發(fā)又被稱為“即插即用編程”方法，是從計算機硬件設計中吸收過來的優(yōu)秀方法。這種編程方法是將編制好的“構件”插入已做好的框架中，從而形成一個大型軟件。構件是可重用的軟件部分，構件既可以自己開發(fā)，也可以使用其他項目的開發(fā)成果，或者直接向軟件供應商購買。當我們發(fā)現(xiàn)某個構件不符合要求時，可對其進行修改而不會影響其他構件，也不會影響系統(tǒng)功能的實現(xiàn)和測試，就好像整修一座大樓中的某個房間，不會影響其他房間的使用。
6．全面測試
要采用適當?shù)氖侄?，對系統(tǒng)調查、系統(tǒng)分析、系統(tǒng)設計、實現(xiàn)和文檔進行全面測試。
7．引入外部監(jiān)理與審計
要重視信息系統(tǒng)的項目管理，特別是項目人力資源的管理，因為項目成員的素質和能力以及積極性是項目成敗的關鍵。同時還要重視第三方的監(jiān)理和審計的引入，通過第三方的審查和監(jiān)督來確保項目質量。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
項目管理系列之五-團隊管理
摘自www.computerworld.com.cn
左美云 李東 董小英等著
通常，項目小組可以按子系統(tǒng)或職能進行劃分，這里主要討論項目團隊的具體人員構成以及有效的激勵方式。
項目小組構成
這里所說的項目小組是指項目團隊的基層單位，例如，一個大項目開發(fā)團隊可以分為總體組、軟件開發(fā)組、硬件網絡組、測試組等若干個項目小組。
圖1 大型IS項目基層項目小組構成
首先，每個項目小組的人數(shù)不能太多，否則組員之間彼此通信將占用大量的時間。此外，通常我們不能把一個子系統(tǒng)劃分成大量獨立的單元模塊，如果項目小組人數(shù)太多，則每個組員所負責實現(xiàn)的單元模塊與其他成員的接口將更復雜，不僅出現(xiàn)接口錯誤的可能性增加，而且系統(tǒng)測試也會變得既困難又費時。
一般說來，每個項目小組的規(guī)模應該比較小，以2～9名成員為宜。如果項目屬于中小型規(guī)模且建設時間在一年以內，那么項目小組可以采用工作包負責人制。工作包負責人既負責該工作包的日常管理工作，同時又是該工作包的技術負責人，在其他成員中再挑選一位為助理，協(xié)助工作包負責人做好各方面的工作。
如果項目屬于大中型規(guī)模，建設時間在一年以上，那么就必須考慮項目建設人員因各種原因發(fā)生變動的情況。這時，項目小組具體構成最好如圖1所示。這里的系統(tǒng)開發(fā)人員既可以是程序員，也可以是測試員。
采用這種按技術水平分層的構成模式主要基于兩點考慮：第一，信息系統(tǒng)建設中既有創(chuàng)造性很強的事務，也有經驗性很強的事務和照葫蘆畫瓢的簡單性事務，如果所有活動都讓高級人員去完成，則導致成本上升，造成人力資源的浪費，還會引起高級人員的不滿；第二，由于項目建設時間太長，容易發(fā)生人員更替，并且由于信息系統(tǒng)開發(fā)技術主要靠“干中學”，中級和初級開發(fā)人員在系統(tǒng)建設過程中會成長起來，如果一旦發(fā)生上一層次人員變動，下層人員由于一直參與項目的研發(fā)，基本上可以“無縫”地接手工作。
如果項目小組成員不發(fā)生人員更替，則項目小組的整體素質將隨時間的推移而提高，從而使項目的進度加快。一般來說，初、中、高級人員最初的薪水可以按類似3∶7∶10的比例定位。當然，隨著初中級人員技術水平的提高，他們的薪水也應該不斷提高，因為他們在同樣時間內可以完成更多、更復雜的工作。
把握團隊成長規(guī)律
信息系統(tǒng)項目團隊的成長與其他項目一樣，一般需要經過四個階段：
1．形成階段
形成階段促使個體成員轉變?yōu)閳F隊成員。每個人在這一階段都有許多疑問：我們的目的是什么？其他團隊成員的技術、人品怎么樣？每個人都急于知道他們能否與其他成員合得來，自己能否被接受。
為使項目團隊明確方向，項目經理一定要向團隊說明項目目標，并設想出項目成功的美好前景以及成功所產生的益處；公布項目的工作范圍、質量標準、預算及進度計劃的標準和限制。項目經理在這一階段還要進行組織構建工作，包括確立團隊工作的初始操作規(guī)程，規(guī)范溝通渠道、審批及文件記錄工作。所以在這一階段，對于項目成員采取的激勵方式主要為預期激勵、信息激勵和參與激勵。
2．震蕩階段
這一階段，成員們開始著手執(zhí)行分配到的任務，緩慢地推進工作?，F(xiàn)實也許會與個人當初的設想不一致。例如，任務比預計的更繁重或更困難；成本或進度計劃的限制可能比預計的更緊張；成員們越來越不滿意項目經理的指導或命令。
震蕩階段的特點是人們有挫折、憤怨或者對立的情緒。這一階段士氣很低，成員可能會抵制形成團隊，因為他們要表達與團隊聯(lián)合相對立的個性。
因此在這一階段，項目經理要做導向工作，致力于解決矛盾，決不能希望通過壓制來使其自行消失。這時，對于項目成員采取的激勵方式主要是參與激勵、責任激勵和信息激勵。
3．正規(guī)階段
經受了震蕩階段的考驗，項目團隊就進入了發(fā)展的正規(guī)階段。項目團隊逐漸接受了現(xiàn)有的工作環(huán)境，團隊的凝聚力開始形成。這一階段，隨著成員之間開始相互信任，團隊內大量地交流信息、觀點和感情，合作意識增強，團隊成員互相交換看法，并感覺到他們可以自由地、建設性地表達他們的情緒及意見。
在正規(guī)階段，項目經理采取的激勵方式除參與激勵外，還有兩個重要方式：一是發(fā)掘每個成員的自我成就感和責任意識，引導員工進行自我激勵；二是盡可能地多創(chuàng)造團隊成員之間互相溝通、相互學習的環(huán)境，以及從項目外部聘請專家講解與項目有關的新知識、新技術，給員工充分的知識激勵。
4．表現(xiàn)階段
團隊成長的最后階段是表現(xiàn)階段。這時，項目團隊積極工作，急于實現(xiàn)項目目標。這一階段的工作績效很高，團隊有集體感和榮譽感，信心十足。團隊能感覺到被高度授權，如果出現(xiàn)技術難題，就由適當?shù)膱F隊成員組成臨時攻關小組，解決問題后再將相關知識或技巧在團隊內部快速共享。
這一階段，項目經理需要特別關注預算、進度計劃、工作范圍及計劃方面的項目業(yè)績。如果實際進程落后于計劃進程，項目經理就需要協(xié)助支持修正行動的制定與執(zhí)行。這一階段激勵的主要方式是危機激勵、目標激勵和知識激勵。
需要要強調的是，對于信息系統(tǒng)建設人才，要更多地引導他們進行自我激勵和知識激勵。當然，足夠的物質激勵是不言而喻的，它從始至終都是最有效的激勵。
激勵的結果是使參與信息系統(tǒng)的所有成員組成一個富有成效的項目團隊，這種團隊具有如下特點：
● 能清晰地理解項目的目標；
● 每位成員的角色和職責有明確的期望；
● 以項目的目標為行為的導向；
● 項目成員之間高度信任、高度合作互助。
總之，科學地管理團隊有助于項目按期、按質完成。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
創(chuàng)建成功的工程
成功項目管理的秘密
更好地領導一個項目的訣竅
參與變革,走向成功
CMM/TSP/PSP講義稿
開發(fā)流程中的可用性
軟件開發(fā)的管理和控制
如何組織軟件開發(fā)團隊
軟件項目管理（CMM）經驗談
實施CMM/TSP/PSP的建議
軟件開發(fā)質量保證體系
技術討論指南
任務管理
項目管理軟件
質量管理
團隊管理
小軟件項目開發(fā)的管理
一個企業(yè)的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把別人的 經驗生搬硬套到自己身上，可能會適得其反。同樣，管理一個軟件項目也一樣，大項目和小項目的方式不完全一樣。但從另一個角度來看，項目的大與小并沒有本質的區(qū)別，很多方法是共通的。本文的目的是從作者的經驗來談談小項目開發(fā)的管理。
一、小項目的特點
大家知道，“軟件危機”的出現(xiàn)起源于一些大型項目的不斷延遲甚至失敗。小項目相比之下，具有以下特點:
1.項目功能相對較少
2.開發(fā)人員較少
3.開發(fā)周期較短
另外，在現(xiàn)實中，有很多小項目是由一些中小公司進行開發(fā)的，這些公司往往人員流動性較大，這也是不容忽視的一個現(xiàn)實.
二、小項目開發(fā)中常犯的錯誤
小項目看起來比較簡單，比較容易成功，因而人們往往忽視了小項目的管理，其實這是一種誤解，從本人的經驗看來，小項目開發(fā)中容易犯以下的一些錯誤:
1、開發(fā)之前沒有認真地進行項目可行性和工作量的估計?！ ⊥捎陧椖枯^小，便很草率地制定一個開發(fā)日程表，沒有認真地估計項目難度，結果實際完成時間與估計完成時間往往有較大差別。
2、沒有真正的設計過程
開發(fā)人員少，意味著不同人員的程序之間交互、接口相對少一些。開發(fā)周期短意味著往往是同樣的幾個人從頭到尾負責一個項目。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下最基本的數(shù)據(jù)結構、函數(shù)接口便分頭去做自己的工作了，沒有一份較正式的文檔。
這種做法潛在的危險之一是有的人可能會對討論出的接口、結構理解有偏差(應該承認人是會犯錯誤的)。一個誤解可能造成以后的返工。 另一個潛在的危險是由于討論時忽略了某些情況，等大家都按當時的分工完成屬于自己的工作后，才發(fā)現(xiàn)各個模塊組合起來卻形不成一個完整的系統(tǒng)。其根源在于沒有一個負責協(xié)調的人員不斷監(jiān)控整個開發(fā)過程。
第三個潛在的危險是一旦有人中途退出開發(fā)隊伍，其他人加入時，新來的人難以理解 以前別人做好的代碼，索性自己從頭來。另外，沒有文檔的程序，日后維護和版本升級都比較困難。
3.不經過單元測試而直接進入系統(tǒng)測試
造成這一現(xiàn)象的原因是每個模塊相對比較簡單，但是為了測試一個模塊需要建立一些測試環(huán)境。例如，為了測試一個函數(shù)是否正確，應該用一些測試數(shù)據(jù)去調用該函數(shù)，需要編寫一些測試數(shù)據(jù)。但很多開發(fā)人員嫌麻煩，覺得反正其他模塊也很快出來了，直接用真正的數(shù)據(jù)來運行幾次就行了。
殊不知，一旦直接進入系統(tǒng)測試，發(fā)現(xiàn)運行結果不正確后需要一步步查找。由于模塊間的調用關系，可能查了很久才發(fā)現(xiàn)是某個模塊的問題。這種方法一來效率比較低，大量的時間用在了將一個錯誤定位在模塊上了。另外由于這種測試不完全，真正運行系統(tǒng)，當 調用某模塊時，可能大部分時候都是正常數(shù)據(jù)，極少出現(xiàn)邊界情況，可能某些邊界情況容易被忽視，很久之后才被發(fā)現(xiàn)。但是如果對每個模塊進行單元測試時都進行一下邊界測 試，就會很容易消除一些隱患。真可謂欲速則不達也。
三.合理的開發(fā)流程
合理的開發(fā)模式，一句話形容就是“麻雀雖小，五臟俱全”，即使是小型項目的開 發(fā)，仍然應該遵循軟件開發(fā)的一般規(guī)律，必須的步驟不能省略。但是小項目有它自身的一些特點，實行起來可以相對靈活些。
以下我從幾個方面描述一下我認為比較合理的模式.
1.需求獲取
在進入正式開發(fā)之前，必須先從用戶處獲取準確的需求。在這上面花費相當時間是很必要的。
軟件項目可以大致分為專用軟件和通用軟件兩大類。
對于專用軟件，例如給某單位開發(fā)一套該單位專用的系統(tǒng)，一般用戶對于軟件要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發(fā)合同中已經大致地規(guī)定了。
但是，開發(fā)合同上規(guī)定的只是一個大概的框架，在進入開發(fā)之前必須與用戶進行比較具體的交流和討論，了解清楚用戶心目中的產品究竟是什么樣子。這個步驟如果沒有好好做，往往到了開發(fā)工作的后期才發(fā)現(xiàn)開發(fā)人員的理解和用戶的要求有一些誤解，那么必然造成時間上的浪費。
對于通用軟件，在開發(fā)之前應該做一定的市場調查工作，一方面是從經濟效益考慮，調查產品的潛在市場有多大，另一方面是從技術的角度，必須了解清楚潛在用戶對軟件的各種技術上的要求，例如，用戶現(xiàn)有硬件配置如何，軟件配置如何，使用什么網絡，使用 什么數(shù)據(jù)庫等等，根據(jù)調查的統(tǒng)計結果決定即將開發(fā)的軟件的一些技術指標。
為了比較好地與用戶進行交流，使用一些工具是很有好處的。 為了討論用戶界面，可以用VB, delphi等做一個原型，根據(jù)原型有針對性地與用戶討論需求。(原型開發(fā)不僅僅可以用于準確獲取用戶的需求，開發(fā)出來的原型本身可以作為下一步開發(fā)的基礎，增量式地完成開發(fā))
為了討論軟件運行的流程，可以采用UML的Use Case圖。
2.需求分析
在了解用戶的需求之后，將需求用一種模型來表示，就是需求分析，目前比較流行的 分析方法是面向對象的方法，通過分析用戶需求，用類、類之間的各種關系來表示整個系統(tǒng)。
這部分涉及到具體的方法，在此不詳細討論，但是原則上是提取類->類之間關系,可能需要不斷修改而形成一份分析文檔。
我想強調幾個問題。
一是要分清問題域與系統(tǒng)責任。系統(tǒng)責任是指所要開發(fā)的軟件應該完成的功能，而問題域是包含所有相關的部分。例如你要開發(fā)一個程控機計費程序，程控機已經是現(xiàn)成，輸出的數(shù)據(jù)格式也已經是固定的，你的程序僅僅需要從程控機中讀取相應的信息，那么，程控機在你的系統(tǒng)里只是一個外部的東西，把它作為一個類也許就是不必要的，僅僅需要一個類來完成讀數(shù)據(jù)的操作。又如，你需要在一個已經存在的數(shù)據(jù)庫上開發(fā)一些應用，數(shù)據(jù)庫的格式已經固定，并且已經有一個后臺程序在運行，你需要開發(fā)一個新的前臺程序，這時，服務器程序對你來說就是一個外部的東西。但是，象這種外部的內容必須在分析文檔中有一些說明，作為系統(tǒng)的外在約束。 二是需求獲取與需求分析的關系。
用什么方法來完成需求的獲取，在很大程度上影響了需求分析的做法。
例如當初采用Use Case來表示用戶需求，那么從各種序列圖中選出相互交互的各個實體，就是一個個類。
三是分析與設計過程的銜接。
分析過程的內容是用類的結構來表示目標系統(tǒng)，并不設計具體實現(xiàn)，如采用什么編程 語言，在什么操作系統(tǒng)平臺上運行等等。這些具體實現(xiàn)是在設計階段來完成的。面向對象方法的優(yōu)點是分析、設計、編碼過程表示法統(tǒng)一，能比較好的銜接。但是，是把分析和設 計階段分開，采用瀑布式開發(fā)，還是采用其他方式，要看具體的情況。
對于需求潛在變化不大的項目，可以采用瀑布模型，有一個很明顯的設計階段，這樣做的好處是有一份比較完整的分析文檔，這樣以后如果需要采用不同的編程語言、或者采 用其他的平臺時，便可以以這份分析文檔作為開發(fā)的基礎。
對于需求變化頻繁的項目，可能采用少量分析;少量設計少量編碼測試的方式更合適，而且隨時可能要返回到前面某個一階段去進行修改。但是這意味著可能沒有一份完整的分析文檔。
現(xiàn)在很多CASE工具并不區(qū)分分析和設計的階段。但是，這并不意味著開發(fā)就可以對分析和設計不加區(qū)分，CASE工具如同一支筆，如何用好還得還人。
3.設計過程
設計階段的工作包括:
對分析模型必要的修改?？赡苄枰獙δ承╊惤Y構進行一些修改，這些修改的原因可能是編程環(huán)境的要求，或者為了重用以前的某些工作。
定義界面部分、數(shù)據(jù)訪問(數(shù)據(jù)庫)部分。
由于目前很多編程語言都可以可視化地設計界面，所以界面部分工作往往留到了編碼階段來完成。于是設計階段的工作量并不大。
4.編碼
進入編碼工作之后，可能會發(fā)現(xiàn)前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。
5.測試
如前所述，即使是小項目，也應該嚴格地進行測試。
四、人員的安排
比較小的項目，往往是幾個人來完成，這幾個人基本上從頭到尾參加開發(fā)。在這幾個人中，有一位項目負責人，負責分析、設計和協(xié)調的工作。由于項目小，項目負責人也要參加編程,那么這人必須把時間合理運用，
經驗告訴我?guī)讞l原則:
1.協(xié)調幾個人的工作比自己完成一段編碼更重要.
由于協(xié)調上出了漏洞，可能導致很大的問題，所以項目負責人必須隨時監(jiān)控各開發(fā)人員的工作，包括內容是否與要求發(fā)生偏差，進度是否滯后等等。
只有在完成這些工作之后，項目負責人剩下的時間才能用于編程。 2.給每個開發(fā)人員明確的任務書.
不管是用面向對象或者其他方法開發(fā)，分析、設計模型只是從功能的角度來描述系 統(tǒng)。但是，具體開發(fā)時每個開發(fā)人員必須非常明確自己的任務，這些任務應該采用明確的文檔來表示。
3.讓大家都大致熟悉設計模型.
讓每個開發(fā)人員都清楚自己所做的工作在整個系統(tǒng)中處于什么地位，有時侯可能會發(fā)現(xiàn)設計模型中的漏洞，避免了各人的代碼編寫完畢之后又要修改的后果。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
創(chuàng)建成功的工程
作者：Bruce Eckel，翻譯：UMLChina.Hairui
Bruce Eckel，著名的計算機語言和工程專家，著有《C++編程思想》（Thinking in C++）、《Java 編程思想》（Thinking in Java）等書籍 相關網站：http://www.bruceeckel.com --譯者注
以下工程開發(fā)指導是我對決定一項使用任何語言的軟件工程成功與否的決定因素的一些認識。
1．記住往往事與愿違
純粹的“軼事工程”（原文為：anecdotal project，其含義不好理解，暫譯為"軼事工程"，盼指正--譯者）的失敗幾率總是存在，一些低至百分之五十而另一些高達百分之八十，但是所有的這些都表明：你失敗的機會大于你成功的機會。為什么我要從這個令人喪氣的預測開始我的話題呢？因為每一天開始時，我都想“今天將會不同，我今天能夠完成四倍數(shù)量的事情”，盡管（在此之前）有過一系列不間斷的例外。對于軟件工程來說，過度的狂熱往往被那些（只）關心結果人所夸大——“這一次，我們將解決以前從來沒有人解決過的問題，只需付出更少的時間和更小的代價”，盡管他們知道，真正的規(guī)則是：“你只能從此三者中選擇一個”。
記住你身后高高堆積的紙牌[i]非常重要。你手中有一根包含時代力量的魔術手杖或者是掛在懸崖上，會讓你做出完全不同的兩個決定。如果你懂得你的處境屬于后者，你將會說：“是的，這很好。但首先讓我們看看我們是否能夠在現(xiàn)有的進度和預算情況下完成這一切。”
一個將不穩(wěn)定形勢和對失敗的認識放到顯著位置的方法是研究過去的失敗。一份很好的資料是Roberts Glass（一位愛好研究崩潰的專家）的著作：《軟件失控》(Software Runaways,出版信息：Prentice Hall 1998)，以及他其它的著作。此外可以閱讀Tom Demarco和Tim Lister的經典之作《人件——生產性工程和團隊》 (Peopleware: Productive Projects and Team,出版信息：第二版，Dorset House,1999)。
2．切合實際地安排時間
時間安排的“魔法”經常受到非開發(fā)人員為滿足軟件開發(fā)實踐之外的愿望和期待而產生的想法所驅使。最近我校正了自己的時間安排策略。我先將整個工程顯示腦海中，然后閉上眼睛，清理自己的大腦并讓它判斷這個工程大概需要多少時間。如果不考慮奇怪的技術問題、各種會議和其他分心的事物的影響，得出的這個時間居然非常合理。但我建議將這個合理的時間乘以3，或許可能是4，并且加上百分之十。如果這個估計出來的時間將讓你失去市場機遇，那么考慮不要進行這個工程。如果你認為像這樣計劃時間不合理，那么首先請注意，大多數(shù)工程將遵循這個規(guī)律。其次，試想一下，如果你所在公司的所有工程都很成功進行會帶來局面：你將擁有更多的收入；更少的程序員會因為愚昧的工程時間安排筋疲力盡而退出。
你也許還會爭論說這個時間評估技術非常沒有科學性，這一點我同意。然而，所有的軟件評估技術都含有臆測和直覺的成分在內，甚至連功能點（原文為：function point，若有其他正規(guī)譯法，請指正）分析都需要對功能點進行猜測。我的“信封背面”技術將所有臆測結合到了一起，而不試圖假裝沒有猜測。用更少的時間，也許產生更好的結果。但是，我的猜測是建立在我自己的經驗之上的。
3．首先讓它運作起來
當我試圖進行一些無意義的事情時，我最大的創(chuàng)造性成功來臨了。銘記最重要技巧——當你開始一個工程時，你好比已經用手指將自己掛在一個懸崖之上；然后你考慮一下能夠做什么瘋狂的事情簡單地讓你的工程運作起來。這并不意味著你需要馬上投入進去并用通常的方式開始撰寫代碼，你只需要盡早盡快找到一個轉換周期非常短的工具，用來判斷你是否可以做該項工作以及你的工程可行性如何。我在后面將要提到的Python語言就是這樣一種工具。
將你的計劃運作起來有很多好處。憑你的經驗，你應該知道，用戶只有能夠開始使用你開發(fā)的東西的時候才能理解你開發(fā)的是什么，然后他們會突然產生各種念頭并對該軟件應該做些什么真正提出要求。一份系統(tǒng)說明書往往只是一份文檔，人們往往不會認真地閱讀，但是如果你讓他們體驗一個可運行的程序之后，他們就會確切地明白你的意思。更早地了解用戶們真正想要什么豈不是更好？
事情往往會比你想象出來的要復雜四倍以上，所以對你能夠完成的東西要盡可能地保守一些。無論何時，一些不可知的因素都在伴隨著你的工作（這一點你可以從產品描述中一些“最”中察覺到：“最快”、“最大”、“最新”），原型的價值不能進行夸大。如果在此之前你沒有做過類似的工程，那么最重要的事情是盡快地判明該工程是否可以實現(xiàn)，開發(fā)一個根本不能發(fā)揮作用的程序將會以浪費你的大量金錢而收場。
最后一點，優(yōu)化。要能夠在這個階段抵抗得了誘惑。牢記Donald Knuth說過的話（其中略有一點開玩笑的意思）：“不成熟的優(yōu)化是所有麻煩的根源”。雖然優(yōu)化是一些工程的關鍵因素，但是在確認程序切實可行之前一切優(yōu)化都是盲目的。在最后建造系統(tǒng)之前瀏覽一遍所有的問題。每個工程都有一些你沒有接觸過的東西，你應該首先將注意力放到這個領域，創(chuàng)建一個測試程序或者原型來尋找解決問題的方法。在你知道你是否可以做到并且知道做到的難度有多大之前，你沒有其他辦法能夠得知工程是否能夠成功、如何為它安排時間以及它需要多少付出等等。
4．使用恰當?shù)墓ぞ?
一個工程的早期部分應該是高度探索性和實驗性的，因為那個階段是發(fā)現(xiàn)自己不會做什么以及如何去建造程序的階段。尋找最適合工具的最好方法是去體驗一下他們，然后擯棄其中工作效率低下的那些。例如，你可能開始的時候用的是Rational Rose，后來決定使用Visio Professional來創(chuàng)建視圖，因為你需要Visio（或者通過Versa）提供的一些特性。
用來做工程的恰當工具并不一定就必須是你已經了解的編程語言。當使用一種語言時，你就被局限在該語言所能表示的范圍之中了。如果你是一個C++程序員，你很自然可能想用C++創(chuàng)建所有的工程管理和工具。但當你需要更加靈活的工具時，Perl是一種更快速的選擇（甚至將考慮學習需要的時間在內）。在你的實際工程開發(fā)中，使用Python來快速造型或者甚至交付一個內嵌Python語言的應用程序將給你帶來更好的局面。首先，它是免費的，所以不需要支付任何許可授權費用；同時它對C 和Java有完全兼容的接口，你可以使用Python解決所有Perl能夠解決的問題，所以它是C++和Java的一種完美的輔助語言。
5．接口的設計
在C++中，接口是一個包含所有虛函數(shù)的類；而在Java中接口技術被直接支持；在COM和COBRA中，你沒有其他選擇，你和所有的抽象打交道——所有的都是接口，沒有實現(xiàn)。接口提供了一個更加整潔的設計方式。要想讓程序員們確信這一點有些困難，但是它對將COM或者COBRA指定為構件模型非常有幫助的（COBRA技術也是與操作系統(tǒng)無關的技術）。它不僅僅提供了工程實現(xiàn)語言的靈活性，并讓你能夠完全地將工程切割開來。如果你打算在你的開發(fā)組或者公司之外實現(xiàn)你的工程的一部分，整潔的接口可以阻止任何與工程其它部分不適當?shù)倪B接，同時你可以用任何語言來進行開發(fā)。你可以采取快速造型來實現(xiàn)所有的接口，稍后才對其中比較特別的部分進行優(yōu)化。
6．設計時充分考慮異常情況
在C++中，異?？刂撇⒉幌裨贘ava中那樣得到有力支持——這是Java在工程管理方面成功之處。在設計、代碼編寫和模塊使用的時候往往會有一些錯誤，除非軟件自身能夠通過拋出一個異常來聲明這些錯誤，否則你將會花費許多小時或月的時間來捕獲這些問題。只有通過嚴謹?shù)漠惓Ｊ褂?，你才能保證這些問題不會出其不意地讓你的工程陷入困境。
7．簡潔往往付出代價
雖然很難說服管理部門，但是“簡潔”這個詞是可維護性和復用性的同義詞。不僅如此，一個簡潔的程序讓人感覺很好。但是因為我們確信軟件工程是一種商業(yè)行為，目的是為了賺錢，而不是為了感覺，因此很難說簡潔的程序比其他非簡潔的程序更加有靈氣地結合在一起。但是由于軟件是一種能夠賺錢的藝術實體，在美學和實用性之間必然會一場爭論。
8．人與人之間的交流是一個瓶頸
這就是為什么小型的組隊往往更加有生產力的原因。當一個工程像火焰一樣失去控制的時候，將更多的程序員扔進火焰將使情況變得更糟。這也是為什么簡短的小會議往往可以發(fā)揮作用而冗長的大型會議卻做不到，還有為什么太深的管理機制會導致生疏的原因。參閱《人件》（早些時候提及過）一書了解更多的細節(jié)。
解決交流問題的最好辦法是免費的：在一臺廢棄的計算機上安裝一個Linux服務器，你可以在幾分鐘內完成這項工作，自動安裝將包括一個Apache網頁服務器。然后將你們所有的文檔，從測試分析到用戶文檔，拷貝到服務器上，以便每個人都能夠訪問到最新的信息。你可以輕松地加入Java Servlets或者Perl腳本（http://www.perl.com/）或者Python(http://www.python.org/)來收集每一頁的內容，然后用一個List服務器來向所有的成員發(fā)送公告。如果你想用camera-ready格式來提供文檔，你可以用Adobe Acrobat格式來代替HTML格式。如果你的工程足夠大的話，指定一名成員專門負責維護服務器是值得的。
9．制定一份計劃（可以是任何類型的）
我曾經見過許多工程在沒有簽訂任何合同（更別說一份計劃）時已經有大量資金流動。哪怕是對于一個很小的工程，你也需要某種計劃，甚至它可能只是被寫在一個信封的背面或者只存在于主程序員的腦海中。當工程逐漸變大，你需要一個回顧的過程。一個典型的計劃包括：分析階段（包括你打算用程序解決什么問題以及程序將完成什么）、設計階段（程序如何完成它的任務、程序實現(xiàn)的組成、分析階段預定目標是否達到的測試使用信息以及發(fā)布、安裝和培訓等事項）。當新的信息被收集時，這些階段將被重復。根據(jù)工程的大小，這些步驟將被縮小或者放大，但你必須像熟悉你的編程語言一樣熟悉它們。
10．考慮外部幫助
一種放棄：我的公司提供培訓和咨詢服務，因此當然我感覺這是一個好主意。然而，如果你的公司內部有經驗豐富的人可以擔任你的工程的顧問，你可以不必向公司之外尋求幫助。這是一種以知識為基礎的商業(yè)行為，生產力最低和最高的軟件工人之間的生產力差別是很大的。如果你無法雇用那些最有生產力的工人，你可以通過培訓提高他們的生產力，通過咨詢和代碼預排來改進你的工程的分析、設計和實現(xiàn)。對于顧問和客戶來說，有一本優(yōu)秀的書籍是Weinberg的《咨詢的秘密》（出版信息：Dorset House,1986）
另一方面，我曾經見過一些工程中，使用外部的開發(fā)組隊剝奪了內部的隊伍的權利，該項目最后以花費更多的時間和資金收場。這將我們帶到我的最后一個提示:
11.了解永遠沒有銀彈（原文為：silver bullets,此處直譯為銀彈，估計引申含義和free lunch接近）的道理
這句諺語是由Fred Brooks發(fā)明的，對于今天仍然適用——盡管有許多“銀彈”已經被發(fā)明出來了。統(tǒng)一建模語言（UML）就是這樣一個例子：它當然是一個很好的通用詞匯表和設計符號集，但是UML僅僅輕微地減少了方法學家之間的爭論而已。永遠不會有不勞而獲的事情。你必須艱辛地計劃你的對象、它們的接口和結構，然后跨越一道道障礙將工程變成成果。你必須清楚沒有任何可以保證成功的方案可以依賴，同時牢記工程的失敗的幾率讓自己更好的瞄準成功。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
成功項目管理的秘密
摘自SDMagazine，Karl Wiegers著，UMLChina.Shids譯
在最好的情況下，管理軟件項目也是很困難的。不幸的是，許多新項目經理實質上沒有受到任何就職培訓。這里有20個成功的管理經驗供項目經理參考。
1. 定義項目成功的標準
在項目的開始，要保證風險承擔者對于他們如何判斷項目是否成功有統(tǒng)一的認識。經常，滿足一個預定義的進度安排是唯一明顯的成功因素，但是肯定還有其他的因素存在，比如：增加市場占有率，獲得指定的銷售量或銷售額，取得特定用戶滿意程度，淘汰一個高維護需求的遺留系統(tǒng)，取得一個特定的事務處理量并保證正確性。
2. 識別項目的驅動、約束和自由程度
每個項目都需要平衡它的功能性，人員，預算，進度和質量目標。我們把以上五個項目方面中的每一個方面，要么定義成一個約束，你必須在這個約束中進行操作，要么定義成與項目成功對應的驅動，或者定義成通向成功的自由程度，你可以在一個規(guī)定的范圍內調整。相關的詳細信息，請參照我的《創(chuàng)建一種軟件工程文化》（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。
3. 定義產品發(fā)布標準
在項目早期，要決定用什么標準來確定產品是否準備好發(fā)布了。你可以把發(fā)布標準基于：還存在有多少個高優(yōu)先級的缺陷，性能度量，特定功能完全可操作，或其他方面表明項目已經達到了它的目的。不管你選擇了什么標準，都應該是可實現(xiàn)的、可測量的、文檔化的，并且與你的客戶指的“質量”一致。
4. 溝通承諾
盡管有承諾不可能事件的壓力，從不作一個你知道你不能保證的承諾。和客戶和管理人員溝通哪些可以實際取得時，要有好的信譽。你的任何以前項目的數(shù)據(jù)會幫助你作說服的論據(jù)，雖然這對于不講道理的人來說沒有任何真正的防御作用。
5. 寫一個計劃
有些人認為，花時間寫計劃還不如花時間寫代碼，但是我不這么認為。困難的部分不是寫計劃。困難的部分是作這個計劃--思考，溝通，權衡，交流，提問并且傾聽。你用來分析解決問題需要花費的時間，會減少項目以后會帶給你的意外。
6. 把任務分解成英寸大小的小圓石
英寸大小的小圓石是縮小了的里程碑。把大任務分解成多個小任務，幫助你更加精確的估計它們，暴露出在其他情況下你可能沒有想到的工作活動，并且保證更加精確、細密的狀態(tài)跟蹤。
7. 為通用的大任務開發(fā)計劃工作表
如果你的組經常承擔某種特定的通用任務，如實現(xiàn)一個新的對象類，你需要為這些任務開發(fā)一個活動檢查列表和計劃工作表。每個檢查列表應該包括這個大任務可能需要的所有步驟。這些檢查列表和工作表將幫助小組成員確定和評估與他/她必須處理的大任務的每個實例相關的工作量。
8. 計劃中，在質量控制活動后應該有修改工作
幾乎所有的質量控制活動，如測試和技術評審，都會發(fā)現(xiàn)缺陷或其他提高的可能。你的項目進度或工作細分結構，應該把每次質量控制活動后的修改，作為一個單獨的任務包括進去。如果你事實上不用作任何的修改，很好，你已經走在了本任務的計劃前面。但是不要去指望它。
9. 為過程改進安排時間
你的小組成員已經淹沒在他們當前的項目中，但是如果你想把你的組提升到一個更高的軟件工程能力水平，你就必須投資一些時間在過程改進上。從你的項目進度中留出一些時間，因為軟件項目活動應該包括做能夠幫助你下一個項目更加成功的過程改進。不要把你項目成員可以利用的時間100％的投入到項目任務中，然后驚訝于為什么他們在主動提高方面沒有任何進展。
10. 管理項目的風險
如果你不去識別和控制風險，那么它們會控制你。在項目計劃時花一些時間集體討論可能的風險因素，評估它們的潛在危害，并且決定你如何減輕或預防它們。要一個軟件風險管理的簡要的指南，參見我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。
11. 根據(jù)工作計劃而不是日歷來作估計
人們通常以日歷時間作估計，但是我傾向于估計與任務相關聯(lián)的工作計劃（以人時為單位）的數(shù)量，然后把工作計劃轉換為日歷時間的估計。這個轉換基于每天我有多少有效的小時花費在項目任務上，我可能碰到的任何打斷或突發(fā)調整請求，會議，和所有其他會讓時間消失的地方。
12. 不要為人員安排超過他們80％的時間
跟蹤你的組員每周實際花費在項目指定工作的平均小時數(shù)，實在會讓人吃驚。與我們被要求做的許多活動相關的任務切換的開銷，顯著地降低了我們的工作效率。不要只是因為有人在一項特定工作上每周花費10小時，就去假設他或她可以馬上做4個這種任務，如果他或她能夠處理完3個任務，你就很幸運了。
13. 將培訓時間放到計劃中
確定你的組員每年在培訓上花費多少時間，并把它從組員工作在指定項目任務上的可用時間中減去。你可能在平均值中早已經減去了休假時間、生病時間和其他的時間，對于培訓時間也要同樣的處理。
14. 記錄你的估算和你是如何達到估算的
當你準備估算你的工作時，把它們記錄下來，并且記錄你是如何完成每個任務的。理解創(chuàng)建估算所用的假設和方法，能夠使它們在必要的時候更容易防護和調整，而且它將幫助你改善你的估算過程。
15. 記錄估算并且使用估算工具
有很多商業(yè)工具可以幫助你估算整個項目。根據(jù)它們真實項目經驗的巨大數(shù)據(jù)庫，這些工具可以給你一個可能的進度和人員分配安排選擇。它們同樣能夠幫助你避免進入“不可能區(qū)域”，即產品大小，小組大小和進度安排組合起來沒有已知項目成功的情況。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一試的好工具。
16. 遵守學習曲線
如果你在項目中第一次嘗試新的過程，工具或技術，你必須認可付出短期內生產力降低的代價。不要期望在新軟件工程方法的第一次嘗試中就獲得驚人的效益，在進度安排中考慮不可避免的學習曲線。
17. 考慮意外緩沖
事情不會象你項目計劃的一樣準確的進行，所以你的預算和進度安排應該在主要階段后面包括一些意外的緩沖，以適應無法預料的事件。不幸的是，你的管理者或客戶可能把這些緩沖作為填料，而不是明智的承認事實確實如此。指明一些以前項目不愉快的意外，來說明你的深謀遠慮。
18. 記錄實際情況與估算情況
如果你不記錄花費在每項任務上的實際工作時間，并和你的估算作比較，你將永遠不能提高你的估算能力。你的估算將永遠是猜測。
19. 只有當任務100%完成時，才認為該任務完成
使用英寸大小的小圓石的一個好處是，你可以區(qū)分每個小任務要么完成了，要么沒有完成，這比估計一個大任務在某個時候完成了多少百分比要實在的多。不要讓人們只入不舍他們任務的完成狀態(tài)；使用明確的標準來判斷一個步驟是否真正的完成了。
20. 公開、公正地跟蹤項目狀態(tài)
創(chuàng)建一個良好的風氣，讓項目成員對準確地報告項目的狀態(tài)感到安全。努力讓項目在準確的、基于數(shù)據(jù)的事實基礎上運行，而不是從因為害怕報告壞消息而產生的令人誤解的樂觀主義。使用項目狀態(tài)信息在必要的時候進行糾正操作，并且在條件允許時進行表揚。
這些提示不能保證你的成功，但是它們將幫助你在你的項目上獲得一個堅實的把手，并且保證你做了所有你可以做的事來讓項目在這個瘋狂的世界上成功。
原文鏈接：http://www.processimpact.com/articles/proj_mgmt_tips.html
________________________________________
主頁 論壇 留言 打印 聯(lián)系
更好地領導一個項目的訣竅
----Warren Keuffel
自：SD Magazine，Sep,1999. UMLChina.Think譯
----------------------------------------------------------------------------
技術管理就像開車。當你做得正確時，沒有人注意，一旦某個環(huán)節(jié)出錯，問題會接踵而來。以下是我11年來作為Interviewing Manager的Team管理體會，排名不分先后，你必須注意每一點。
1. 不要重復過去二三十年來別人犯過的錯誤
這句話來自Steve Mcconnell，IEEE軟件編輯和軟件開發(fā)暢銷書作家。Mcconnell的作品包括經典著作“Code Complete”。Mcconnell認為，“大量閱讀”是避免凡重復錯誤的最好方法。
2. 80%的管理就是選擇正確的人選
Scott Adams, Dilbert漫畫的作者認為一個好的項目經理必須創(chuàng)造一個人盡其用的環(huán)境。所有的項目經理都應該讀一讀Tom Demarco和Tim Lister的新書“Peopleware：Productive Projects and Teams”（2nd Edition, Dorset House, 1999）。
3. 總是試圖雇用比你強的人
不要讓你的自負成為項目的瓶頸。組織一支聰明的隊伍，給他們足夠的資源和解決問題的規(guī)則，讓員工自己解決問題。
4. 不要浪費時間
Tom Bragg，Intellisys Technology Corp.的首席技術官員，認為太多的項目由于不能如期開始最后陷入麻煩。通常導致延遲的原因包括其它任務的干擾，人事變動，不準時的經理等等。
5. 最優(yōu)的未必是最大的
Tom Bragg的另一個建議是：密切注意項目開始后發(fā)生的事情。Bragg說：“計劃好你的工作然后如期進行，過分緊張的工作強度反而往往導致生產率的降低，可能保持每周50小時以內的工作強度是最佳的。
6. 真實的，公正的估計
項目經理應該避免“依照管理者的欲望修改計劃”的陷阱?！耙粋€有效的估計的特征是所估計的時間與金錢比實際情況低和高的概率相等”，Bragg說。
7. 使你的組織結構更有效率
很多情況下，你可以采用另外一種與現(xiàn)在不同的組織結構。看一看Apache Web server的開發(fā)小組，他們的層次組織并不分明，卻開發(fā)出了成功的產品。
8. 使用WWW上的免費工具
從http://sunnet.usc.edu/winwin/winwin.html，你可以下載由Barry Boehm的學生開發(fā)的，能夠把W理論（WinWin模型）和螺旋形模型結合起來的工具。在項目管理研究所的網址www.pmi.org，你可以下載它的聯(lián)機手冊。從www.spmn.com你可以看到從CMM模型出發(fā)的一些建議以及兩套工具：Control Panel和Risk Radar。Control Panel是Excel表格形式，由于監(jiān)測生產率和質量；Risk Radar是一個Access數(shù)據(jù)庫，對項目的風險進行量化管理。
9. 不要小看老程序員
重新訓練現(xiàn)有的程序員比雇用新畢業(yè)的大學生要有價值。老的程序員在以往的多個項目上有豐富的經驗，通過新技能的訓練后，他們的經驗和知識會幫助年輕的程序員（包括項目經理）節(jié)約時間和金錢。
10. 為你的項目選擇定正確的工作流程
并不是所有的項目都適用一種開發(fā)流程。Intel公司有規(guī)律地檢查每個開發(fā)小組的工作質量，如果出現(xiàn)了延遲交付或質量問題，Intel鼓勵該小組改進他們的工作流程。
11. 做好你的生存計劃
....
________________________________________
主頁 論壇 留言 打印 聯(lián)系
參與變革
---------發(fā)現(xiàn)更多可重用的過程與簡單的版本控制相比，更易走向成功
Lisa J. Roberts，譯：umlchina.mirnshi(mirnshi@263.net)
譯者序：本文刊登于SDMagazine，2000年11月。論述了為什么要建立可重用過程以及從中得到的好處。譯文中部分語句采用了意譯，不妥之處和曲意之處請參見原文。
對開發(fā)過程共享實施猛烈的變革和改變是個什么樣子？除了可能的時間大量損失（好，其實這是很小的
可能，除了正在改變開發(fā)過程時），當它們獲得了人們支持時就都會成功。
在歷史上，人民，社會的勞動者，通過聯(lián)合推動了社會變革。這就是我們所滿意的應用程序，MeshTV，用二維和三維的有限元網格以圖形的方式可視化和分析數(shù)據(jù)。它也能處理多種不同的網格類型，提供各種方式查看數(shù)據(jù)并去除了大多數(shù)的硬件和廠商的依賴，同時以自身圖形硬件的速度顯示圖形。MeshTV也可以并行工作，你可以想象得到這需要一些組織級別滿足程序的復雜性，保持有序。最后說一點，MeshTV大約有450,000行源代碼。
這是我所作的全部描述。如果你想了解得更多，查看www.llnl.gov/bdiv/meshtv，你可以下載可執(zhí)行程序、源代碼和手冊。
受約束的混亂
象許多為內部使用而開發(fā)的程序一樣，在加利福尼亞Livemore的勞倫斯Livemore國家實驗室，對程序必需的修改和增加超出了可用的資源。在MeshTV項目中，這導致了混亂，（on the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（譯者注：這句話不好譯）沒有人有時間坐下來畫出應用流程。我們都在實驗室的里里外外，忙于我們客戶的貪婪的需求。（有約150個文檔用戶-可能更多，實際上要靠5個兼職的開發(fā)人員支持）在我們這種狀況下，這種過程導致了我們用戶更多的抱怨和可靠性匱乏的程序。
三年前，我們的職責很?。◣讉€用戶，幾個開發(fā)人員，很少有廣泛的應用功能）允許我們在CVS上用非常不正規(guī)的過程管理源代碼。當用戶數(shù)和他們需求差異增多時，相應的代碼管理的復雜性也增加了。處理我們增長的工作量也變得更加困難，我們知道有些事情必須要改變了。我們決定加入到我們部門的其他開發(fā)小組中去，并使用Rational軟件公司的版本控制系統(tǒng)—ClearCase。從此，我們過程的改進氛圍（our process improvement culture）開始改變，變革的種子已經播下了
在我們轉向ClearCase前，我們小組的一位經理曾經誘導我們更多的集中在過程上，她徒勞了。她看到了增長的壓力和用戶的不滿，她想我們應該嘗試用不同的方法提高我們程序的可靠性和在用戶那里的名聲。不幸的是，她的話從來沒有引起重視，同樣我們也認識到了這點，但我們不得不忙于作完我們的工作。開發(fā)人員認為最好的情況是軟件工程學所論述的那樣，而在最糟和最可能的情況下，會占用大量的時間，提供眾多的文檔，用處不是很大。我們的一些老開發(fā)人員認為改進我們的過程沒有用并且……（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.）（譯者注：這句話太難譯了，單詞也不認識）而且俱樂部所有人，包括我也懷疑我們要收獲的巨大好處。我認為CVS工作得很好，我們真的不需要更多先進的東西。
在CVS工作的同時，ClearCase工作得更好。我認為在每個軟件工程生產力上沒有真正的提高，但是可以用我以前不能采用的工作方式工作。這些新的工作方法可以使管理源代碼變得更容易，同時也減少了我曾經在CVS中遇到的問題。例如，我現(xiàn)在可以輕松的多并發(fā)地開發(fā)，我可以在我完成后可靠的歸并我所作的。新特性彌補了我花在開發(fā)和學習新過程上的時間。
真正的產出
過渡不久，一位同事和我與一位來自蘋果計算機公司的開發(fā)同行進行了一次有趣的討論。他的工作需要產品開發(fā)過程的急迫應用，包括構建方法學和發(fā)行版本管理過程。當我們敘述我們通常隨意無計劃的方式時，他幾乎震驚暈倒。后來的討論，使我們驚奇的了解到了通過改進我們的過程所獲得的好處。有一位經理鼓勵我們是一方面，但是非同尋常的另一面是聽到一位開發(fā)同行稱贊他發(fā)現(xiàn)的好處。這是真正的產出，計算機科學風格的。
我們對其思考的越多，我們越認識到我們需要行動。將新特性和缺少固定發(fā)行日期聯(lián)系起來的狂熱，導致了在發(fā)行新版本和功能性的匱乏測試間長久的延期。我們的意圖是好的，我們想讓我們的客戶滿意。然而，不知何故，我們的期望事實上很糟糕，似乎看起來我們工作得很辛苦，但是，我們聽到了更多的抱怨。我們需要改變現(xiàn)狀。
首先，我們轉換到有目的的發(fā)行版本日期，使其包含明確的更改和新的功能。像許多的內部產品，MeshTV有著明顯的直接的用戶（MeshTV had users who lived "right down the street."）。新特性的不同的聲音淹沒在所有的目標回應中，我們嘗試經常性的從那些所有從會議廳走下來，停下來聊會兒天的用戶那里獲取要求。（這些打斷也可以避免我們持續(xù)工作）荒謬的是在試圖獲取所有要求中，我們不能滿足他們中的大多數(shù)，我們失望了。所以我們從這種方法上退回來?；蛘咴噲D將所有要求放進去（可能匆忙地完成，沒有更多明顯的bugs）,或者針對最后的抱怨作一個改正（從而沒有舊的要求）。我們需要一個載明新發(fā)行版本應體現(xiàn)哪些要求的計劃。
這表明另一個過程需要改進。在決定之前，我們通過將bugs報告和要改變的要求寫到紙上，保證可追蹤。這片紙經?！白呦蛄怂惺挛锏臍w途”，或者偶然的扔進了廢紙簍，或者壓在了其他所有的紙張下面。（這點上我堅信我已危險地靠近制造我自己桌面中子星）（譯者注：黑洞乎）那些紙隨著時間的流逝而不能理解，無心的造成了客戶輸入損失的結果。
我們需要很好的保持我們改變要求的追蹤，這樣我們就可以為下一個發(fā)行版本選擇明確的要求。在對幾個產品調研后，我們購買了Pure Atria的ClearDDTS，幫助我們管理我們的改變要求，我們試圖一年四次發(fā)布新版本應用程序，這作為一策略被我們采納，這樣我們就可以很快的清晰地增加新功能，不用更新得過于頻繁導致沒有時間測試我們的修改。為了達到結束點，我們努力選擇一定量的能夠在三個月內完成的工作。第一次時，因為我們沒有人知道如何預測一個詳細的修改需要多長時間，我們徹底失敗了。幸運的是，我們可以通過ClearDDTS跟蹤我們曾經預測的時間和工作中實際花費的時間，并且個別開發(fā)人員利用這些數(shù)據(jù)預測將來。在為其他版本的選擇工作中，這獲得了重大的成功。變革明顯的站住了腳。
我們也決定與目標發(fā)行版本并進，著手提高質量的工作。為了完成這點，我們要求所有決意要改變的要求要被不具有開發(fā)責任的其他人所驗證。當我們知道其他人會檢查工作時，我們就都會非常仔細，這多么驚奇。我們也開始采用Mercury Interactive’s Xrunner和內部使用的腳本開發(fā)了一個自動測試系統(tǒng)。將來，在我們發(fā)布一個新版本應用程序前，這些測試必須成功的測試過。
持續(xù)的改進
所有這些工作都以我們不能想象的方式的到回報了。我們更好地跟蹤我們的改變要求，也就是我們沒有丟掉它們，我們確實能跟得上用戶的更新狀態(tài)了。用戶喜歡這點，我們也不再面對來自客戶的挫折。他們也喜歡我們更頻繁的更新和更加健壯的程序。
我們正在尋找另外的方式，我們可以從改變我們過程中獲得好處的方式?，F(xiàn)在，我們正在研究軟件開發(fā)成熟度模型（CMM）,看是否能通過遵從2級幫助我們提供更好的應用軟件（請到http://www.sei.cmu.edu/查看更多的CMM信息）。我們可以從這種方式中獲得好處，但是我們想確認通過2級認證能夠編寫更好的代碼，不只是更多的文書工作的要求。我們的興趣在于進步，不在于核對boxes。
我們正在進行的另一個改變是，我們能夠更容易地在我們每年四個主版本之間發(fā)布修訂bugs的版本。這點可以是我們更快的轉向用戶的要求，平息用戶的憤怒。（我們基于用戶認識到的嚴重性和我們察覺的嚴重性的比較，選擇哪些bugs被改正，還包括工作區(qū)存在的風格。我們在整體上也為客戶整合了全部優(yōu)先級的感覺）
我們過程改革的更多驚人結果之一是不只影響了程序，更多地影響了程序開發(fā)人員。他們停止了改善用戶的態(tài)度，轉向提高應用程序。程序變得更可靠，發(fā)行版本變得更可預測的同時，用戶對應用軟件整體上也更加滿意。
但是我們不僅只關心我們的過程的改革。MeshTV的開發(fā)人員同其他的開發(fā)小組并同工作著，我們試著同其他的小組分享我們的經驗，學習我們的勝利和錯誤。圍繞我們新的過程，我們提供了四個展示，至少有一個小組已經決定采用我們的一些經驗。變革在成長。
成功孕育成功
當管理層嘗試推動改變過程時，從最初的懷疑和憤怒，我們在這個過程中經歷了巨大的變革。這些曾經著名的過程都是那些所有刊物都討論過，當作福音傳授給我們的同事。當我回頭看看我們的小組，我驚奇于我們從使用一個版本控制系統(tǒng)改變到幾個可重用性、文檔化過程，甚至將那些經驗出售給別人。什么能夠允許我們背離我們正規(guī)的商業(yè)方式
對于我們來說，在開展新的過程中最重要的因素是一個成功的戰(zhàn)士，他醞釀了過程改革中的興趣。這個戰(zhàn)士應該是一個受到尊敬的開發(fā)人員，在小組里的，因持續(xù)工作而聞名，因渴望經驗的增長而受人尊重。在我們的事中，我們有二位戰(zhàn)士，我的同事Sean Ahern和我自己。在我們興奮于可能的好處并開始著手于一些改革后，小組的其他人信服了并跟隨我們。當管理層決定了過程必須跟隨時，來自小組外的壓力出現(xiàn)了。對于外來的，組員將可能排斥它，對此我不能強調得足夠多。然而，來自里受人尊敬的組成員的狂熱，開發(fā)人員感到是必須聽從。畢竟，這些人們事實上知道到底它象個什么樣子。一旦其他團隊里的人看到了真正的好處，他們就會跳進這個潮流中，變革也就會良好的進行下去。當開發(fā)人員開始思考改進過程的方式，獲取真正的好處時，好戲就開始了
你如何開始你的變革？每次一個改變。一旦明顯有好處，你的同事就會加入到你的行列中，同你一起征服編程世界。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
CMM、TSP、PSP講義稿
Blueski
CMM/TSP/PSP應該是目前世界上公認的最好的軟件管理模式。
CMM提供了框架和目標，PSP針對個人進行優(yōu)化，TSP針對團隊進行優(yōu)化。
以下提供的是一些CMM/TSP/PSP 介紹的幻燈片。壓縮為cmmtsppsp.zip，打開后共有4個文件，其中cmmtsppss.ppt是主文件，帶有對其它文件的連接。
點擊下載：
下載-->> 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ā)的各個階段并為其帶來益處。
目錄
• 簡介
• 使用反復、周期性的設計過程
• 構思階段
• 規(guī)劃階段
• 開發(fā)階段
• 穩(wěn)定化階段
• 為下一版本做準備
________________________________________
簡介
可用性測試為您帶來的好處
簡言之，如果將可用性測試從產品開發(fā)周期的一開始一直貫徹到項目的每一階段中，將使您在最后的處理過程中省去重新開發(fā)這一環(huán)節(jié)。
本文首先討論重復、周期性的設計過程。第一部分闡述了以用戶為中心進行設計時的四個原則，這是由 Gould、Boies 和 Lewis 提出的。接下來介紹了兩種類型的產品設計過程：“瀑布式”方法和“螺旋式”方法。本文的其余部分將簡要介紹產品開發(fā)的各個階段，并討論可用性活動是如何滲透各個階段并帶來益處的。此處所述的開發(fā)階段包括：構思、規(guī)劃、開發(fā)、穩(wěn)定化以及為下一版本做準備。
在您閱讀各小節(jié)時，請注意用戶將頻繁地參與到各個過程中。用戶對每個階段的介入將會在項目的收尾階段為您省去成本高昂的返工工作，而且這樣開發(fā)出來的產品將使用戶樂于使用、易于學習，并會長期使用。
使用反復、周期性的設計過程
反復、周期性的設計過程為以用戶為中心進行的設計帶來了極大的便利。以用戶為中心的設計有四個重要原則，這些原則是由 Gould、Boies 和 Lewis 于 1991 年提出的：
• 及早以用戶為中心：設計人員應當在設計過程的早期就致力于了解用戶的需要。
• 綜合設計：設計的所有方面應當齊頭并進發(fā)展，而不是順次發(fā)展。使產品的內部設計與用戶界面的需要始終保持一致。
• 及早并持續(xù)性地進行測試：當前對軟件測試的唯一可行的方法是根據(jù)經驗總結出的方法，即若實際用戶認為設計是可行的，它就是可行的。通過在開發(fā)的全過程引入可用性測試，可以使用戶有機會在產品推出之前就設計提供反饋意見。
• 反復式設計：大問題往往會掩蓋小問題的存在。設計人員和開發(fā)人員應當在整個測試過程中反復對設計進行修改。
多年來，“瀑布式”的產品設計過程是軟件設計的標準。在這一方法中，項目開發(fā)通過分階段發(fā)展的、按順序的各個階段進行。這種方法使用重大事件作為轉變點和評估點，并認為在下一階段開始前，前面的每一階段均已結束?！捌俨际健钡姆椒▽τ趶碗s的項目很有效。在復雜的項目中，多個供應商負責項目的各個方面（例如，一個供應商負責需求分析，另一個負責規(guī)范，等等）。但是，使用這種方法可能導致隨著項目的進展，對項目進行更改越來越難。
相形之下，“螺旋式”的產品設計過程卻是反復、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。這一過程允許更大地發(fā)揮創(chuàng)造性，并且更易于隨著項目的進展而對項目進行修改。在進行螺旋式的設計過程時，您會發(fā)現(xiàn)可在各個階段對產品各方面的功能進行設計。這種方法可為以用戶為中心的產品開發(fā)過程帶來便利。
螺旋式的產品設計過程有六個階段：構思、規(guī)劃、建模、開發(fā)、穩(wěn)定化以及為下一版本做準備。
構思階段
產品開發(fā)的構思階段是確定項目的目標和范圍的階段。此階段要確立構思陳述、設計目標、風險評估以及項目構架。
在構思階段，通常進行下列可用性活動：
環(huán)境研究
基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一書中所述的方法，此類型的研究包括觀察用戶的所做所為，使您更為直觀地了解用戶行為。如果您尚未決定究竟要開發(fā)何種軟件，但認為存在市場機會，就可使用環(huán)境研究來對活動進行研究。您可了解可為用戶做些什么以及實現(xiàn)的難易程度。不是尋求具體的功能，而是尋求設計機會。
環(huán)境研究為項目提供工作的重心。如果項目是全新的項目，或是較全面的升級，這種方法最為適用。在進行較全面的升級或開展全新項目時，您無法全面了解用戶在做什么、如何做、以及他們所面臨的問題或困擾。而進行較小的升級時，您有可能從產品支持部門、先前的研究等處獲得這些信息。在這種情況下，您基本上是對現(xiàn)有的設計加以完善，所以環(huán)境研究并不是不可或缺的。
環(huán)境研究在以下情況最為適合：項目組進行跨學科的環(huán)境研究，小組由可用性工程師帶領。
競爭性測試
通過競爭性可用性測試，您可以為產品設置量化的可用性目標 — 任務完成的速度、每項任務出錯的數(shù)目，等等。這種方法可對項目的成功與否進行量化的度量，即使所進行的競爭只是人工過程，而您將對此過程進行自動化。競爭性測試經常用于市場開發(fā)。當市場開發(fā)代表對競爭對手進行評估時，他們只比較產品的功能?？捎眯詼y試則更側重于使用這些功能完成任務時的性能。
競爭性測試對僅用于公司內部的產品來說，似乎不大適用。但是，如果仔細考慮，從理論上而言，您也是在與產品的先前版本或前一個流程競爭。內部產品可能與人工過程進行競爭 — 產品必須比現(xiàn)有的進程更有效、更好。
進行競爭性測試的方法之一是開展研究，比較與其相競爭的產品的性能。例如，對其他人員的產品進行性能研究。在選擇要測試的競爭產品時，要考慮到計算機之外的產品：如果產品涉及在線交易，則競爭性產品就可以是電子貨幣。從研究結果中您可以確定使用最頻繁的、最重要的功能。
用戶/受眾分析
了解您的用戶！盡可能采取各種方法來了解您的用戶的特點?？紤]一下如果您基于產品最終用戶的特點來開發(fā)軟件，可減少多少技術支持電話的數(shù)量。設想一下用戶是否認為產品易于使用并且包含了他們所需的功能。問自己“對于我要創(chuàng)建的產品，哪些用戶特點是與之相關的？”，例如：
• 計算機使用經驗
• 年齡
• 接受培訓的程度
• 用戶群之間的社會關系
• 特殊要求（可訪問性）
您可以通過環(huán)境研究來獲得一些此類信息。例如，您可對一些用戶進行觀察以得出一些假設，然后通過調研或取樣來驗證這些假設。您的人力資源部門或培訓部門可能會具有一些相關的信息；例如每個新雇員要接受多少培訓。市場研究人員也可能有此類信息。對于公司內部使用的應用程序而言，收集這些信息有時會比對外出售的應用程序簡便，因為您的用戶是具體的群體而不是普通大眾。
規(guī)劃階段
規(guī)劃階段是進行首次實際設計的階段。在此階段中，有關用戶界面的早期設想將初步成形，并著重于先前階段未涉及的知識。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的簡單描繪圖紙、打印在紙上的屏幕位圖圖形，用 Macromedia Director 之類的程序創(chuàng)建的帶有有限交互功能（也稱為“點閱”）的聯(lián)機版本，或是用 HTML 或 Microsoft Visual Basic® 創(chuàng)建的帶有大量交互功能的聯(lián)機版本。在大多數(shù)情況下，您會發(fā)現(xiàn)原型具有的仿真度越高，用戶建議進行重大修改的可能性就越低。所以，用寫在紙上的原型來開始著手測試是非常值得采取的做法。
根據(jù)您所設計的產品種類，您可能需要進行下述的一些或所有活動。如果您在規(guī)劃階段花時間來完成這些任務并使用原型，則在開發(fā)階段碰到的可用性問題將會大為減少。
用戶情況
創(chuàng)建您自己的用戶情況概要，列出產品的典型用戶能做什么，不能做什么。通過早期的環(huán)境研究和用戶/受眾分析，您做出一些較高級別的決策，基于這些決策進行軟件設計。使用用戶情節(jié)，您可創(chuàng)建一個有關用戶使用您所設計的軟件的“故事”。這些情況可以是情節(jié)串聯(lián)圖板、聯(lián)機 Macromedia Director 電影、簡單的流程圖、或簡單的敘述性文本。一種比較精致的用戶情節(jié)模式是“日常生活”錄像。這種錄像把演員作為“用戶”顯示，這些用戶在日常活動中與模擬的系統(tǒng)進行交互。通過用戶情節(jié)可得出您在任務分析時要尋找的具體細節(jié)。
任務分析
任務分析決定了在新產品中執(zhí)行任務的方式。在撰寫規(guī)范之前，必須首先進行任務分析。用任務分析來確定您所規(guī)劃的支持的任務是否確實能夠反映現(xiàn)實，這一點是很重要的。對任務的逼真度進行分析。就產品的特性而言，任務的完整性如何？分析逼真度意味著觀察用戶完成一項任務所必須執(zhí)行的所有操作；或進行表象的觀察，了解用戶完成所有任務或功能所需執(zhí)行的所有操作。無需擔心過于詳盡 — 把重點放在實質內容上。
一些要考慮的問題和活動：
• 此環(huán)境中的任務是什么？環(huán)境研究應能幫助您找出并描述用戶所執(zhí)行的任務。
• 創(chuàng)建順序圖，描述用戶執(zhí)行的任務之間、用戶和產品之間的相互作用。
• 在構思階段確定功能的作用領域。提出問題：“我們要支持的具體任務是什么？”
• 與產品設計者一起創(chuàng)建情節(jié)串聯(lián)圖板或順序簡圖。
啟發(fā)式評估
啟發(fā)式評估涉及評估人員小組，這些評估人員查看界面并基于基本可用性原則來對其做出判斷。啟發(fā)式評估允許您在整個反復式設計過程中查找并更正可用性問題。如果您在工作進展的同時糾正問題，您將在收尾階段節(jié)省大量工作。因為在收尾階段，更改真實代碼將更加困難而且成本更高。
如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，啟發(fā)式評估包括以下步驟：
1. 每個評估人員都瀏覽數(shù)遍界面，檢查各種對話框元素，然后將其與一些已知的可用性原則相比較。
2. 評估人員相互合作，將結果合并到列表中，列出用戶界面中的可用性問題，并注明設計方案中違反的相關可用性原則。
3. 一旦每個評估人員都分別執(zhí)行了啟發(fā)式評估后，他們就集中起來將其評估結果合并在一起。
在開發(fā)的早期階段，啟發(fā)式評估可能是發(fā)現(xiàn)可用性問題的非常有效的方法。
認知性遍歷
認知性遍歷的意思是，仔細檢查界面要求用戶執(zhí)行多少步驟以及何種步驟后，才能完成某項任務，其中包含用戶必須經過思考才能完成的那些步驟。您需要關注的是用戶必須調用什么或用戶必須進行的計算 — 認知性任務決定學習和使用您的產品的難易程度。認知性遍歷可幫助您找出潛在的可用性問題，以及找出您制訂的規(guī)范中的破綻！
根據(jù) Gregory Abowd 的 Performing a Cognitive Walkthrough，要進行認知性遍歷活動，需要以下四個條件：
1. 對系統(tǒng)原型的詳盡描述，例如初級規(guī)范可提供什么樣的系統(tǒng)。這種描述不一定是完整的，但要相當詳盡。諸如菜單的位置或措辭這樣的細節(jié)也可能導致相當大的差異。
2. 對用戶在系統(tǒng)中要完成的任務的描述。該任務應當是大多數(shù)用戶將要執(zhí)行的有代表性的任務。
3. 一個完整的、書面的操作清單，列出使用給定原型完成任務所需執(zhí)行的操作。
4. 指出用戶的身份，以及評估人員能夠假定這些用戶已具有哪一類別的知識和經驗。
有了這些信息，評估人員可執(zhí)行一遍上文第三項所列的操作，從而確定用戶是否能夠按預期要求合理執(zhí)行這些步驟。
GOMS
GOMS 是描述任務和用戶執(zhí)行該任務所需知識的方法，它是通過目標 (Goal)、操作符 (Operator)、方法 (Method) 以及選擇規(guī)則 (Selection rule) 四個方面進行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他們還創(chuàng)建了一個簡化的版本，即擊鍵級別模型 (KLM)。Bonnie E. John 開發(fā)了并行活動版本 CPM-GOMS，而 David Kieras 則開發(fā)出定義更為嚴謹?shù)陌姹荆鹤匀?GOMS 語言 (NGOMSL)。所有這些技術都基于同一 GOMS 概念。
• 不言自明，目標就是指用戶的目標。用戶使用軟件要達到什么目的？在下一天、下幾分鐘、下幾秒鐘？
• 操作符是指軟件允許用戶采取的操作。
• 方法是子目標和操作符經仔細設計后得出的序列，可用來實現(xiàn)諸如剪切和粘貼等目標。
• 選擇規(guī)則是用戶要遵守的判定規(guī)則，以確定在特定環(huán)境下要使用的方法。
GOMS 模型由對方法的描述組成，這些方法是達到目標所必需的。方法是一些步驟，這些步驟包括用戶為達到目標所需執(zhí)行的操作符。如果有一種以上的方法可以達到目標，則需使用選擇規(guī)則來確定在此情況下哪種方法更為適用。
卡片排序
卡片排序是一種可用性技術，用于此階段的早期，以了解用戶關于信息的總體模型?？ㄆ判虻幕救蝿帐且寘⑴c者按卡片上的說明對卡片進行組織，將屬于同一類的項目堆放在一起。在創(chuàng)建好堆后，參與者還可為所創(chuàng)建的堆建立名稱、標簽或說明。
卡片排序用于：
• 展示用戶對于任務范圍的總體模型。
• 展示用戶如何對項目進行分組或分類的。
• 展示用戶對項目之間的關系和相似性的看法。
• 將用戶的概念模型轉換為設計。
反復可用性測試
對原型設計的反復可用性測試是另一種很有價值的方法，用于在產品周期的早期階段確定界面是否易于用戶使用。在此階段進行更改比等到開發(fā)階段開始后再進行更改要更容易些，并且成本更低。
您從可用性實驗室可以收集的數(shù)據(jù)量取決于原型的強健性。對于紙上原型測試，可用性工程師就是計算機，并且在測試的過程中與用戶在一起。
在許多種情況下，嚴謹?shù)目捎眯詼y試是過猶不及的。在建模階段，您仍可使用簡化的方法進行有效的可用性測試，這些方法通常稱為“打折扣的”可用性測試。
如 Jakob Nielsen 所述，反復的可用性測試包括：
1. 用戶和任務觀察 — 觀察用戶，保持安靜，讓用戶做一切通常情況下會做的操作。
2. 情況 — 使用一種可以減少功能數(shù)量、降低功能級別的建模方法。
3. 簡化的對談式測試 — 一次安排一個用戶完成一組任務，并要求用戶“發(fā)現(xiàn)問題就直接告知測試人員”。
4. 啟發(fā)式評估 — 基于基本可用性原則來評價界面。
開發(fā)階段
開發(fā)階段是將產品用實際的代碼來實現(xiàn)的階段。在此階段中，您可以對實際產品的早期版次進行可用性測試。您仍有可能不時要用到原型，但隨著時間的推移產品將逐漸完善。不是所有的功能都將在開發(fā)階段同時完成，所以您有可能在原型和實際代碼之間往復轉換。
在理想條件下，您將可以把大部分時間用來進行推敲，在建模階段就能夠找出主要問題。
真實代碼測試
讓用戶測試真實代碼版本可能會有助于針對在計算機上使用產品發(fā)現(xiàn)問題。這些問題更有可能是設計問題而非概念問題。它們通常涉及相當?shù)图壍慕换プ饔脝栴}，如在屏幕上選擇項目、拖放，以及僅在實際產品中才有的動態(tài)圖形。對于產品的大多方面，真實代碼不一定比設計上的原型或其它模型的真實度更高，所以不要拖延到有真實代碼后再進行可用性測試。
可用性實驗室測試
在開發(fā)階段，您可進行可用性實驗室測試，該測試類似于規(guī)劃階段的反復可用性測試。但是，由于產品的更多部分已趨于完善，您可測試更多任務。您仍可在 Director 中使用模型，或將稍做修改的版次用在可用性測試中。隨著時間的推移，產品會越來越完善，原型就越來越不象一個模型了。但是，用“已完成”產品進行測試的問題在于，由于已進行了如此之多的工作，剩下的時間如此之少，您就不能指望對發(fā)現(xiàn)的問題做太多的修改了。
注意： 作為此任務的一部分，您還可能進行焦點組分析或群集分析，以對產品進行可用性測試。
穩(wěn)定化階段
當開發(fā)結束、錯誤已修正后，就進入了穩(wěn)定化階段。在此階段中，要創(chuàng)建一個可發(fā)售的穩(wěn)定的產品。在此階段對可用性進行測試的重點是進行微調。新的功能以及代價高昂的可用性增強功能應被記錄下來，以備下一版本使用。
基準測試
對可用性進行基準測試類似于“質量保證”中的綜合測試。基準測試的目的是通過測試用戶想要完成的所有頂級任務，就產品的可用性提供可靠的量化數(shù)據(jù)。這些測試的目標與其說是要找出問題（雖然找出問題是大多數(shù)可用性測試的目的），不如說是要評估產品可用性的狀態(tài)。
要進行基準測試，請首先觀察產品的功能，然后將這些功能按任務細分。在穩(wěn)定化階段，特別是對于復雜的產品，您將不能對用戶界面進行可提高每個任務性能的修改。理想情況下，您可以確定哪些是頂級任務，并且確保大多數(shù)頂級任務都是可用的。低優(yōu)先級的任務的可用性可以較低，可記錄下來在將來的版本中再作改進。
為下一版本做準備
將此階段視為開始對過程進行回顧的階段。您將全面考慮在構思階段和規(guī)劃階段所進行的許多相同任務。例如，您將進行：
• 競爭性測試 — 在穩(wěn)定化階段，這種測試是對自己的產品進行測試，以將其與先前收集的有關競爭產品的數(shù)據(jù)作比較。
• 現(xiàn)場研究 — 類似于環(huán)境研究（該研究是要了解“我們要做什么軟件？”），使用您已構建的軟件來找出存在哪些問題，可在下一版本加以解決。
• 關于事件的工具化版本研究 — 軟件的工具化版本基本上用來觀測軟件自身并在發(fā)生事件時記錄數(shù)據(jù)。您在大量會話和用戶的基礎上對產品進行測量以找到使用趨勢。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
如何組織軟件開發(fā)團隊
專家、多面手還是他們的組合？
Scott W. Ambler
總裁，Ronin International
2000 年 11 月 2 日
本文來自IBM DeveloperWorks中國網站
如何構建軟件開發(fā)團隊取決于可供選擇的人員、項目的需求以及組織的需求。本文闡述了各種團隊組織的策略。
有效的軟件項目團隊由擔當各種角色的人員所組成。每位成員扮演一個或多個角色；可能一個人專門負責項目管理，而另一些人則積極地參與系統(tǒng)的設計與實現(xiàn)。常見的一些項目角色包括：
• 分析師
• 策劃師
• 數(shù)據(jù)庫管理員
• 設計師
• 操作／支持工程師
• 程序員
• 項目經理
• 項目贊助者
• 質量保證工程師
• 需求分析師
• 主題專家（用戶）
• 測試人員
您是如何組織項目團隊的？是采用垂直方案、水平方案還是混合方案？以垂直方案組織的團隊由多面手組成，每個成員都充當多重角色。以水平方案組織的團隊由專家組成，每個成員充當一到兩個角色。以混合方案組織的團隊既包括多面手，又包括專家。
一個重要的考慮因素是可供選擇的人員的性質。如果大多數(shù)人員是多面手，則您往往需要采用垂直方案，同樣，如果大多數(shù)人員是專家，則采用水平方案。如果您正引入一些新人，即使這些人員都是合同工，則仍然需要優(yōu)先考慮您的項目和組織。本文描述了形成團隊組織的垂直、水平和混合方案，并指出了它們各自的優(yōu)缺點。本次討論的一個重要含意是您的團隊組織和用于管理項目的手段之間應構成默契；任何方法上的失諧都很可能導致項目產生問題。
垂直團隊組織
垂直團隊由多面手組成。用例 分配給了個人或小組，然后由他們從頭至尾地實現(xiàn)用例。
優(yōu)點
• 以單個用例為基礎實現(xiàn)平滑的端到端開發(fā)。
• 開發(fā)人員能夠掌握更廣泛的技能。
缺點
• 多面手通常是一些要價很高并且很難找到的顧問。
• 多面手通常不具備快速解決具體問題所需的特定技術專長。
• 主題專家可能不得不和若干開發(fā)人員小組一起工作，從而增加了他們的負擔。
• 所有多面手水平各不相同。
成功因素
• 每個成員都按照一套共同的標準與準則工作。
• 開發(fā)人員之間需要進行良好的溝通，以避免公共功能由不同的組來實現(xiàn)。
• 公共和達成共識的體系結構需要盡早在項目中確立。
水平團隊組織
水平團隊由專家組成。此類團隊同時處理多個用例，每個成員都從事用例中有關其自身的方面。
優(yōu)點
• 能高質量地完成項目各個方面（需求、設計等）的工作。
• 一些外部小組，如用戶或操作人員，只需要與了解他們確切要求的一小部分專家進行交互。
缺點
• 專家們通常無法意識到其它專業(yè)的重要性，導致項目的各方面之間缺乏聯(lián)系。
• “后端”人員所需的信息可能無法由“前端”人員來收集。
• 由于專家們的優(yōu)先權、看法和需求互不相同，所以項目管理更為困難。
成功因素
• 團隊成員之間需要有良好的溝通，這樣他們才能彼此了解各自的職責。
• 需要制定專家們必須遵循的工作流程和質量標準，從而提高移交給其他專家的效率。
混合團隊組織
混合團隊由專家和多面手共同組成。多面手繼續(xù)操作一個用例的整個開發(fā)過程，支持并處理多個使用例中各部分的專家們一起工作。
優(yōu)點
• 擁有前兩種方案的優(yōu)點。
• 外部小組只需要與一小部分專家進行交互。
• 專家們可集中精力從事他們所擅長的工作。
• 各個用例的實現(xiàn)都保持一致。
缺點
• 擁有前兩種方案的缺點。
• 多面手仍然很難找到。
• 專家們仍然不能認識到其他專家的工作并且無法很好地協(xié)作，盡管這應該由多面手來調節(jié)。
• 項目管理仍然很困難。
成功因素
• 項目團隊成員需要良好的溝通。
• 需要確定公共體系結構。
• 必須適當?shù)囟x公共流程、標準和準則。
項目團隊士氣是項目成功的一個因素
大部分項目成功的定義說的是項目如何按時完成、是否在預算內以及是否滿足用戶的需要。但是，在如今要找到好的軟件專業(yè)人員都非常困難，更不用說留住他們的這種情況下，還需要將項目成功的定義擴展為包括項目團隊的士氣。可能在努力完成一個軟件項目后，不料卻因為壓榨他們過度而失去了重要的開發(fā)人員，這樣做可能會符合組織的短期需要，但它對構建一個高效的軟件部門的長遠利益來說肯定是有害的。衡量項目成功與否的一個重要手段是項目結束后團隊的士氣。在項目結束之際，項目團隊的各個成員是否覺得他們從自己的經歷中學到了一些知識、是否喜歡為這次項目工作，以及是否希望參與組織的下一個項目都是非常重要的。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
軟件項目管理（CMM）經驗談
（張鳳岐 2001年07月04日 （電腦商報）
編者按：
CMM認證是當今IT界最熱的話題之一，這表明中國軟件企業(yè)已開始重視與軟件項目管理有關的問題了。為了了解國內軟件企業(yè)對軟件項目管理的認識程度以及他們在軟件項目管理方面的具體做法，日前，記者采訪了開思、東方通、瑞星三家純軟件公司的相關負責人。三家公司中，東方通業(yè)已開始按照CMM規(guī)范進行軟件開發(fā)。在采訪中，三家公司的負責人分別介紹了各自企業(yè)在軟件項目管理方面的經驗。開思公司的產品總監(jiān)石宏峰先生還為記者詳細講解了開思公司的《產品部開發(fā)規(guī)范》。
經過整理，我們將東方通和瑞星兩家公司的負責人在采訪中所說的主要內容刊登于此。我們相信，其具有一定的認識價值。另外，我們將開思公司《產品部開發(fā)規(guī)范》的一部分也刊登于此——我們并不認為開思的規(guī)范就是最好的規(guī)范。對軟件項目管理而言，普適性是不存在的，好壞是相對的，適用不適用才是絕對的——我們相信，其具有一定的參照價值?！?
加強相關教育和培訓
朱律瑋（東方通科技首席軟件設計師）
楊樺（東方通科技總經理助理）
東方通科技從去年底開始為參加CMM認證（二級）做準備。擬議中正式參評的時間是今年11月。在這之前我們會請國內咨詢公司的有關專家和國外的評估師進行兩次預評估。
半年多來，我們覺得一切還算順利。起初我們擔心編程人員會有抵觸情緒——因為每完成一天的工作或一道工序或一個項目后都要做記錄、編文檔、寫報告，較之以前，工作量無疑是增加了——后來看看，大家對執(zhí)行CMM規(guī)范還是理解的、支持的。
按照CMM規(guī)范開展工作后，到目前為止，公司的運營成本是增加了——因為要增加管理人員、撰寫文檔也需要人手——但從長遠看，其會帶來降低成本、提高質量、提高用戶滿意度等好處。對此，我們確信不疑。
與國外相比，我們在軟件工程管理方面的差距不僅表現(xiàn)為管理體制、管理方法、管理思想的陳舊，整個軟件業(yè)的落后才是根源。
個人英雄主義情結、喜歡單打獨斗是我們的民族性之一，其在軟件人才身上表現(xiàn)得尤為明顯，已成為中國軟件企業(yè)做大的一個瓶頸。造成這種狀況的原因，除了國內軟件業(yè)的發(fā)展水平不高、軟件項目規(guī)模不大和軟件企業(yè)管理者自身素質不高外，還有很重要的一點，即與軟件工程管理有關的教育內容幾乎沒有。在國外，PSP和GSP均為軟件專業(yè)學生的必修課，可在國內，這兩門課在學校里至今還沒有開起來。國外施行的是定崗培訓，比如撰寫文檔就是一門專業(yè)課，專門有人修它，畢業(yè)后拿它來“安身立命”，國內則是大家過獨木橋，統(tǒng)統(tǒng)都學寫程序。應該說，目前國內同行對軟件工程管理的重要性已有了一定的認識，但在相關人員的培訓上下的力氣仍遠遠不夠。
其實人才才是最關鍵的?，F(xiàn)在軟件業(yè)最缺的人才之一就是產品經理，他們是軟件工程管理的主角。產品經理必須具備以下素質：具有長期的軟件開發(fā)經驗——般來講，要在8年以上；了解用戶的需求；對產品熟、對市場熟——他可以不了解一個產品的底層技術，但必須了解其功能，能把握其發(fā)展方向；具有協(xié)調能力。總之，產品經理并不一定非常聰明，并不需要在某一方面特別突出，但要八面玲瓏。這樣的人才太難找了。東方通的產品經理都是自己培養(yǎng)的。
CMM規(guī)范并非只適用于大型軟件企業(yè)，其也適用于中小型企業(yè)。CMM規(guī)范只是一個框架、綱要性質的東西。企業(yè)在落實它時要細化一次；企業(yè)將其落實到具體的某個項目時，要再細化一次；中小企業(yè)可以不像大型企業(yè)那樣將CMM規(guī)范細化得那么細，夠用就好，不要教條。
實施CMM規(guī)范、通過CMM認證有如下一些好處：確定工作流程和方式，從而使產品的質量和開發(fā)的可延續(xù)性有了保證；可以提高企業(yè)在用戶中的信譽度，增加企業(yè)與強勢公司競爭的籌碼；可以承接國際大公司的外包項目———美國公司愿意找印度公司來承接其外包項目，就是因為印度公司對CMM規(guī)范普遍比較重視，通過CMM認證的軟件企業(yè)也多；公司不再受制于人，人走了，事照做，這是一個公司成熟的表現(xiàn)。
軟件商業(yè)化的必要手段
談文明（北京瑞星科技股份有限公司研發(fā)部經理）
中國軟件產業(yè)發(fā)展時間不長，雖然已有部分技術達到國際水平，但由于商業(yè)環(huán)境還不夠完善，在軟件技術的商業(yè)化與軟件工程管理等方面，與國際同行相比，還存在差距。
只有率先將技術先進的產品推向市場的公司才會贏得利潤。在瑞星，技術商品化已被當作一種制度，它有助于提高整個企業(yè)的素質。
瑞星意識到在充滿競爭的環(huán)境中要獲得成功，天才人物是必不可少的，但他們并不是全部。目前，一個軟件工程的成功更多地要依靠科學家、工程師、制造人員和銷售人員的協(xié)同努力。
在軟件商業(yè)化的過程之中，建立規(guī)范化的易于操作的軟件開發(fā)行為規(guī)范是首先要做的工作。針對殺毒軟件的特點，瑞星專門設計了瀑布模型結合增量模型的開發(fā)方式，即將項目分階段來實現(xiàn)。首先實現(xiàn)市場最需求的核心功能，然后在此基礎上繼續(xù)開發(fā)，每個單獨的階段都采用瀑布模型的開發(fā)方式。
具體地說，一個基本的軟件開發(fā)流程包括需求階段、系統(tǒng)設計階段、詳細設計階段、編碼階段、單元測試階段、集成測試階段、系統(tǒng)測試階段、軟件發(fā)布軟件維護階段。其中決定軟件開發(fā)成功與否的關鍵階段是：軟件需求管理、軟件計劃管理、軟件質量管理和軟件配置管理。
為了在用戶和處理用戶需求的軟件項目組之間達成共識（用戶由最終用戶、高層領導、銷售人員和市場調研人員組成），“軟件需求規(guī)格說明書”是必不可少的。經過正式的評審和確認，其將成為后續(xù)工作的基礎。
軟件項目的實施過程是根據(jù)軟件項目的資源、約束條件和執(zhí)行能力確定的，因此需要制定合理的軟件工程管理計劃，這是項目經理的職責之一。項目經理應定期檢查“項目開發(fā)計劃書”，按照當前項目開發(fā)的實際情況，對其進行調整。
為了保證每一個軟件產品都合乎需求，需要設立一個負責項目監(jiān)督和協(xié)調的SQA。其會對軟件產品是否符合定義好的軟件過程中的相應部分進行審查、復審和測試。公司高層主管應該定期參與、評審SQA的活動。
軟件配置管理是指在整個工程期間對項目的所有軟件配置項進行規(guī)范化管理。如采用版本控制軟件對軟件配置項版本進行版本控制，采用基線管理方法對變化進行控制，即在遵循軟件工程標準的基礎上對整個軟件進行控制和管理，維護其完整性、一致性和可跟蹤性。
瑞星努力營造的是一個廣泛的網絡，研發(fā)、制造、銷售、分銷和服務，連續(xù)進行。圍繞著產品、市場和開發(fā)階段而不是單純的技術來組織各項工作。為了這個目的，標準操作是必不可少的。
附錄：開思公司《產品部開發(fā)規(guī)范》?。ㄕ?br>
說明：第一部分為《目錄》，從中可以看出開思公司《產品部開發(fā)規(guī)范》的整體架構；第二部分為《開發(fā)規(guī)范概述》，從中可以看出開思公司在軟件項目管理方面的一些具體做法。
1 目 錄
1 目的
2 開發(fā)規(guī)范概述
2．1 應用項目管理管理開發(fā)過程
2．2 標準的階段性開發(fā)工作
2．2．1 總體規(guī)劃
2．2．2 項目立項
2．2．3 需求分析
2．2．4 系統(tǒng)分析
2．2．5 系統(tǒng)設計
2．2．6 編碼實現(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 具體工作內容
3．1．1．3．1 資料收集（可選）
3．1．1．3．2 資料研究（可選）
3．1．1．3．3 項目需求報告編制
3．1．1．3．4項目需求報告討論準備
3．1．1．3．5 項目需求報告討論
3．1．1．3．6 項目需求報告修改
3．1．1．3．7 項目需求報告驗收
3．1．1．4 參與者及職責
3．1．1．5 輸出成果及后序工作
3．1．2 技術可行性實驗（可選）
3．1．3 項目計劃書
3．2 項目立項
3．2．1 立項申請
3．2．2 項目立項評估
3．2．3 項目進度計劃
3．2．4 項目立項審批
3．3 需求分析
3．3．1 資料收集
3．3．2 需求分析編制
3．3．3 討論準備
3．3．4 需求分析討論
3．3．5 需求分析修改
3．3．6 需求分析驗收
3．4 系統(tǒng)分析
3．4．1 系統(tǒng)分析準備
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)設計
3．5．1 系統(tǒng)設計準備
3．5．2 界面設計
3．5．3 建立設計模型
3．5．4 系統(tǒng)設計合并
3．5．5 對象持久化設計
3．5．6 詳細設計
3．5．7 系統(tǒng)設計測試
3．5．8 系統(tǒng)設計修改（測試后）
3．5．9 系統(tǒng)設計驗收
3．6 編碼實現(xiàn)
3．6．1 編碼準備
3．6．2 編碼
3．6．3 編碼單元測試（測試工作）
3．6．4 單元測試后編碼修改
3．6．5 編碼聯(lián)調
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)設計測試
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 項目工作總結
4．1 項目任務數(shù)
4．1．1 總任務數(shù)
4．1．2 階段任務數(shù)
4．2 輸出成果
2 開發(fā)規(guī)范概述
2．1 應用項目管理管理開發(fā)過程
產品部接受的各種開發(fā)任務均以項目形式出現(xiàn)，包括：新產品開發(fā)，產品維護（錯誤修改、功能增強、缺陷完善等），產品客戶化開發(fā)及維護等，全程使用項目管理方法進行控制和管理。
根據(jù)項目規(guī)模和難易有大、小，繁簡之分。每個項目的完成周期要控制在6個月以內，項目規(guī)?？刂圃?0個人月內。過大的項目需要拆分成多個小的項目來完成。30個人月以上的項目稱為大項目，10個人月以內的項目稱為小項目。
每個項目要根據(jù)具體情況拆分成工作階段，即里程碑，以便對項目進度的有效控制與檢測。
2．2 標準的階段性開發(fā)工作
2．2．1 總體規(guī)劃
全面規(guī)劃項目工作的內容，確定目標市場、技術指標和應用要求，劃定項目工作范圍和交付成果，明確項目實現(xiàn)的總體設想和實施方案；確定項目中的新技術的可行性；明確項目需要用到的各種資源，估算項目的工作量和成本。
2．2．2 項目立項
產品部對要進行的開發(fā)項目進行立項申請，提交項目資料。由公司的有關人員對項目進行一系列的風險評估。
通過風險評估的項目，由產品部進行詳細進度計劃安排，落實時間進度、資源（人員／設備、內部／外部）、技術、資金和費用等，相關資源和資金使用計劃要詳細列出。
最后所有的項目申請資料、風險評估報告及產品進度計劃都要報給公司上級領導審批，進行立項評審。
立項通過的項目才能進入正式的開發(fā)工作。
2．2．3 需求分析
根據(jù)項目需求報告界定的工作范圍和應用方案的設計思路，進一步深入細化應用方案，描述將要開發(fā)出計算機系統(tǒng)中包含的各項業(yè)務是如何做的，及業(yè)務流程、相關理論、運算公式、原理、業(yè)務數(shù)據(jù)、單據(jù)報表格式等。
2．2．4 系統(tǒng)分析
根據(jù)項目需求分析，對將要建立的滿足用戶需求的計算機系統(tǒng)進行分析。在系統(tǒng)分析過程中采用面向對象分析技術（OOA）劃分需求的問題域，對每一個問題域進行分析和抽象，對其中的事物和它們之間的關系產生正確的認識，找出描述問題域及其系統(tǒng)責任所需的類及對象，定義這些類和對象的屬性與服務，以及它們之間所形成的結構、靜態(tài)聯(lián)系和動態(tài)聯(lián)系。最終產生一個符合用戶需求，并能夠直接反映問題域和系統(tǒng)責任的面向對象的分析模型。
2．2．5 系統(tǒng)設計
根據(jù)項目需求分析和系統(tǒng)分析，針對具體實現(xiàn)中的人機界面、數(shù)據(jù)存儲、任務管理等內容，運用面向對象設計技術（OOD）進行系統(tǒng)設計。主要包括UI設計、對象設計和數(shù)據(jù)庫表設計。
2．2．6 編碼實現(xiàn)
根據(jù)系統(tǒng)設計的結果，運用面向對象的方法進行程序編碼（OOP）以實現(xiàn)系統(tǒng)設計的內容。
編碼過程就是用具體的數(shù)據(jù)結構來定義對象的屬性，用具體的語言來實現(xiàn)服務流程圖所表示的算法。在對象設計階段形成的對象類和關系最后被轉換成特殊的程序設計語言、數(shù)據(jù)庫或者硬件的實現(xiàn)。
2．2．7 項目測試
對系統(tǒng)分析、系統(tǒng)設計、程序編碼等運用面向對象的方法進行測試（OOT）。項目的測試工作貫穿項目的整個開發(fā)過程。主要包括：分析（OOA）測試、設計（OOD）測試和編碼（OOP）測試，以及集成測試和系統(tǒng)測試。
2．2．8 文檔制作
跟隨項目開發(fā)過程應產生的文檔主要包括三類：
（1）開發(fā)文檔：分析、設計、編碼、測試以及各種開發(fā)管理文檔等資料；
（2）用戶文檔：在線幫助，安裝指南，使用手冊，技術手冊，培訓教材等；
（3）宣傳資料：產品介紹資料，產品白皮書，產品宣傳PPT，演示光盤等。
2．2．9 項目驗收
對完工的項目按照驗收步驟進行驗收。驗收過程中對項目的情況給予評價。
2．2．10 項目版本化發(fā)布
對驗收通過的項目進行版本控制，整理項目版本包含的內容并版本化，發(fā)布產品發(fā)布通告。
2．3 項目組織
每個項目指定一個項目經理進行管理，同時指定一個分析、設計人員（來自分析設計組）負責對技術問題的管理。當任務涉及到多個職能組的工作時（有些項目可能只涉及單一的職能組），由項目經理根據(jù)項目工作安排與職能組的組長進行協(xié)調，由職能組的組長來協(xié)助安排本組承擔的項目工作，指定組內人員來完成相關工作。項目經理根據(jù)各職能組長的安排匯總編制整個項目的進度計劃，并根據(jù)最終形成的項目計劃對項目進行控制和管理。
項目進行過程中需按照項目管理的要求對項目進行跟蹤、總結，各職能組的人員要對這些工作給予積極的支持和配合。產品委員會（或產品部內部）不定期組織人員對項目進行審查，確保項目的進度和質量。
項目完工后需要由產品委員會組織對項目進行驗收。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
實施軟件質量保障體系CMM/TSP/PSP的建議
軟件產業(yè)的發(fā)展，在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特征的結構化生產時代，到90年代中期，以CMM模型的成熟模型和日益為市場接受為標志，已經進入以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心的時代，而軟件發(fā)展第三個時代，及軟件工業(yè)化生產時代，從90年代中期軟件過程技術的成熟和面向對象技術、構件技術的發(fā)展為基礎，已經漸露端倪，估計到2005年，可以實現(xiàn)真正的軟件工業(yè)化生產，這個趨勢應該引起軟件企業(yè)界和有關部門的高度重視，及早采取措施，跟上世界軟件發(fā)展的腳步。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業(yè)或遲或早都要走的道路。軟件過程改善是當前軟件開發(fā)技術的核心問題。
--------摘自北京航空航天大學軟件工程研究所周伯生教授的《CMM評估基本要點及最新動態(tài)》學術報告
引言
50多年來計算事業(yè)的發(fā)展使人們認識到要高效率、高質量和低成本地開發(fā)軟件，必須改善軟件生產過程。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業(yè)或遲或早都要走的道路。軟件工業(yè)已經或正在經歷著"軟件過程的成熟化"，并向"軟件的工業(yè)化"漸進過渡。規(guī)范的軟件過程是軟件工業(yè)化的必要條件。
軟件過程研究的是如何將人員、技術和工具等組織起來，通過有效的管理手段，提高軟件生產的效率，保證軟件產品的質量。
軟件過程的理論研究與實踐成果
n 國際
n 國內
國 際
軟件過程的三個流派：
CMU-SEI的CMM/PSP/TSP
SO 9000質量標準體系
SO/IEC 15504（SPICE）
CMU-SEI的CMM/PSP/TSP
20世紀80年代中期國際軟件產業(yè)界對軟件的研究十分重視，因為在采用軟件工程方法克服軟件危機的過程中，人們認識到，軟件是否完善是軟件風險大小的決定因素。這方面的研究取得了重大的突破，其標志是1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發(fā)表的研究成果"承制方軟件工程能力的評估方法"，該成果在1991年發(fā)展成為CMM（軟件過程能力成熟度模型）。軟件過程能力成熟度模型被國際軟件界公認為軟件工程學的一項重大成果。軟件目前，軟件能力成熟度模型2.0版已經修訂問世。CMM在軟件工程的實踐方面已有很大的影響，在工業(yè)界已得到廣泛接受。不僅已用于軍事控制系統(tǒng)，而且已用于全球經濟領域的主要組織。有數(shù)千個組織在利用CMM的軟件過程改進。在美國，關于CMM模型的教程已經作為參考和研究的對象出現(xiàn)了，這樣做是為了讓CMM模型極其相關問題引起工業(yè)界的更密切地關注?；贑MM模型的工具如成熟度問題集，軟件過程評估訓練和軟件能力評價訓練已經在CMM中漸漸得到修訂。近期的關于CMM的活動主要是發(fā)展關于CMM模型的不同版本。由于CMM并未提供有關實現(xiàn)CMM關鍵過程域所需的具體知識和技能，因此，美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發(fā)了個體軟件過程PSP（Personal software process）和群組軟件過程TSP(Team Software Process)，形成CMM/PSP/TSP體系。
ISO 9000質量標準體系
最初的軟件質量保證系統(tǒng)是在70年代由歐洲首先采用的，其后在美國和世界其他地區(qū)也迅速地發(fā)展起來。目前，歐洲聯(lián)合會積極促進軟件質量的制度化，提出了如下ISO9000軟件標準系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002。這一系列現(xiàn)已成為全球的軟件質量標準。除了ISO9000標準系列外，許多工業(yè)部門、國家和國際團體也頒布了特定環(huán)境中軟件運行和維護的質量標準，如：IEEE標準729-1983、730-1984、Euro Norm EN45012等。
ISO/IEC 15504（SPICE）
CMM的方法很快就引起了軟件界的廣泛關注，1991年國際標準化組織采納了一項動議，開展調查研究，在此后引發(fā)了一系列的研究工作，現(xiàn)已取得重要成果，產生了技術報告ISO/IEC 15504《信息技術-軟件過程評估》，預計于今年產生正式標準。從該技術報告的內容來看，其基本的目的和思路，均與CMU/SEI的CMM相似。
目前，學術界和工業(yè)界公認美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發(fā)的軟件能力成熟度模型CMM是當前最好的軟件過程，已成為業(yè)界事實上的軟件過程的工業(yè)標準。
國 內
學術界：中國生產力促進協(xié)會、北航SEI、中科院研究SEI等科研機構已于近幾年在北京、上海、廣州和深圳等地先后舉辦過多次報告會和研討會，組織過課程學習和應用實驗，開展了軟件過程方面的研究與開發(fā)工作，并發(fā)表了多篇的研究成果和學術論文，在軟件質量保障平臺支撐環(huán)境也取得了一定的成果。
產業(yè)界：近兩年來，CMM在我國獲得了各界越來越多關注，業(yè)界有過多次關于CMM的討論，國務院發(fā)布的《鼓勵軟件產業(yè)和集成電路產業(yè)發(fā)展的若干政策》對中國軟件企業(yè)申請CMM認證給予了積極的支持，在第17條規(guī)定"對軟件出口型企業(yè)CMM認證費用予以適當支持。"2000年中國村電腦節(jié)上還有CMM專題論壇，吸引了眾多業(yè)內人士。鼎新、東大阿爾派、聯(lián)想、方正、金蝶、用友、浪潮、創(chuàng)智、華為、東大阿爾派等大型集團或企業(yè)等都從1997---2000年起批企業(yè)都在進行研究、實驗或實施預評估。其中鼎新公司從1997年著手進行CMM認證工作。1999年7月通過第三方認證機構的CMM2認證。東大阿爾派公司于2000年10月通過第三方認證機構的CMM2認證。2001年1月，聯(lián)想軟件經過英國路透集團的嚴格評估，順利通過CMM2認證。
總體上講，國內對軟件過程理論的討論與實踐正在展開，目標是使軟件的質量管理和控制達到國際先進水平，中國的軟件產業(yè)獲得可持續(xù)發(fā)展的能力。專家分析，在未來兩三年內，國內軟件業(yè)勢必將出現(xiàn)實施CMM的高潮。從這一趨勢看，中國的軟件企業(yè)已經開始走上標準化、規(guī)范化、國際化的發(fā)展道路，中國軟件業(yè)已經面臨一個整體突破的時代。
軟件質量保障體系的實施
根據(jù)一直以來對國際上軟件過程理論與實踐的發(fā)展、尤其是近幾年來著重在CMM、PSP和TSP以及ISO軟件過程標準草案等方面的研究工作，國內專家學者建議，軟件過程的改善應該從三方面著手進行：
o 軟件能力成熟度模型CMM(Capability Maturity Model)
o 個體軟件過程PSP (Personal Software Process)
o 群組軟件過程TSP(Team Software Process)
三者各有側重，但互為補充。
CMM
o 迄今為止學術界和工業(yè)界公認的有關軟件工程和管理實踐的最好的軟件過程。
o 為評估軟件組織的生產能力提供了標準。
o 為提高軟件組織的生產過程指明了方向。
CMM軟件過程成熟度模型概要*
1、 比較
在介紹CMM內容之前，首先概述一下不成熟軟件組織與成熟軟件組織的差異。在不成熟的軟件單位，軟件過程一般由實踐者及其管理者在項目進程中臨時拼湊而成，因而推遲進度和超出預算已成為慣例，產品質量難以預測，有時為了滿足進度要求，常在產品功能和質量上做出讓步。
然而，一個成熟軟件組織具有在全組織范圍內管理軟件、開發(fā)過程和維護過程的能力，規(guī)定的軟件過程被正確無誤地通知到所有員工，工作活動均按照已規(guī)劃的過程進行。并通過可控的先導性試驗和費效分析使這些過程得到改進，對已定義過程中的所有崗位及其職責都有清楚的描述，和通過文檔與培訓使全組織有關人員對已定義的軟件過程都有很好的理解，從而使其軟件過程所導致的生產率和質量能隨時間的推移得到改進。
表1給出了不成熟和成熟軟件組織的比較，這種比較分析不僅是形成軟件能力成熟模型的基礎，也有利于理解該模型。
2、 CMM的一些基本概念
?。?）軟件過程：人們用于開發(fā)和維護軟件及其相關過程的一系列活動，包括軟件工程活動和軟件管理活動。
?。?）軟件過程能力：描述（開發(fā)組織或項目組）遵循其軟件過程能夠實現(xiàn)預期結果的程度，它既可對整個軟件開發(fā)組織而言，也可對一個軟件項目而言。
?。?）軟件過程性能：表示（開發(fā)組織或項目組）遵循其軟件過程所得到的實際結果，軟件過程性能描述的是已得到的實際結果，而軟件過程能力則描述的是最可能的預期結果，它既可對整個軟件開發(fā)組織而言，也可對一個特定項目而言。
?。?）軟件過程成熟：一個特定軟件過程被明確和有效地定義，管理測量和控制的程度。
（5）軟件能力成熟度等級：軟件開發(fā)組織在走向成熟的途中幾個具有明確定義的表示軟件過程能力成熟度的平臺。
?。?）關鍵過程域：每個軟件能力成熟度等級包含若干個對該成熟度等級至關重要的過程域，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟件成熟度等級的目標不起關鍵作用。歸納為：互相關聯(lián)的若干軟件實踐活動和有關基礎設施的一個集合。
?。?）關鍵實踐：對關鍵過程域的實踐起關鍵作用的方針、規(guī)程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什么"而不強制規(guī)定"如何做"。整個軟件過程的改進是基于許多小的、漸進的步驟，而不是通過一次革命性的創(chuàng)新來實現(xiàn)的，這些小的漸進步驟就是通過一些著關鍵實踐來實現(xiàn)。
?。?）軟件能力成熟度模型：隨著軟件組織定義、實施、測量、控制和改進其軟件過程，軟件組織的能力也伴隨著這些階段逐步前進，完成對軟件組織進化階段的描述模型。
3、 CMM模型概要
軟件開發(fā)的風險之所以大，是由于軟件過程能力低，其中最關鍵的問題在于軟件開發(fā)組織不能很好地管理其軟件過程，從而使一些好的開發(fā)方法和技術起不到預期的作用。而且項目的成功也是通過工作組的杰出努力，所以僅僅建立在可得到特定人員上的成功不能為全組織的生產和質量的長期提高打下基礎，必須在建立有效的軟件工程實踐和管理實踐的基礎設施方面，堅持不懈地努力，才能不斷改進，才能持續(xù)地成功。
CMM提供了一個框架，將軟件過程改進的進化步驟組織成5個成熟等級，為過程不斷改進奠定了循序漸進的基礎。這5個成熟度等級定義了一個有序的尺度，用來測量一個組織的軟件過程成熟和評價其軟件過程能力，這些等級還能幫助組織自己對其改進工作排出優(yōu)生次序。成熟度等級是已得到確切定義的，也是在向成熟軟件組織前進途中的平臺。每一個成熟度等級為連續(xù)改進提供一個臺基。每一等級包含一組過程目標，通過實施相應的一組關鍵過程域達到這一組過程目標，當目標滿足時，能使軟件過程的一個重要成分穩(wěn)定。每達到成熟框架的一個等級，就建立起軟件過程的一個相應成分，導致組織能力一定程度的增大。
下面表2給出了CMM模型概要，表中的5個等級各有其不同的行為特征。要通過描述不同等級組織的行為特征：即一個組織為建立或改進軟件過程所進行的活動，對每個項目所進行的活動和所產生的橫跨各項目的過程能力。
表2 CMM模型概要
4、 CMM的結構
軟件機構的最終質量保證模式可以用下圖1說明，圖1給出軟件質量計劃、質量控制、質量改進一個簡單循環(huán)，其實，它歸納出CMM的真正內核，所以，可以說CMM的模型是一種新興管理思想：連續(xù)改進（Continuos Improvement）循環(huán)的體現(xiàn)。
圖1
CMM的作用
n 科學地評價軟件開發(fā)單位的軟件能力成熟等級
n 幫助軟件開發(fā)單位進行自檢，了解自己的強項和弱項，從而不斷完善和改進單位的軟件開發(fā)過程，確保軟件質量，提高軟件開發(fā)能效率。
CMM實施的思考
根據(jù)CMM的基本原理、基本內容和基本方法，對CMM提出4個問題供大家思考：
1. 過程成熟度需要多長時間？多少費用？對企業(yè)有何好處？
2. 影響基于CMM的軟件過程的成敗因素是什么？
3. CMM是否會導致過度官僚主義？是否會使組織變得更保守，不愿冒風險？
4. 有無合適的、易理解的框架（不僅僅是告訴"我們做什么"，而且告訴"我們怎么做"）可指導所有軟件組織進行CMM改進？
這些針對CMM提出的問題與爭論，國外進行了一些調查工作，但國內基本上沒有這方面的專業(yè)調查和研究，以后再根據(jù)國內企業(yè)對CMM的認識、認證的增強和增多，這些問題會得到更科學的解答。
現(xiàn)給出國外針對上述問題的一些調查結果：
問題1：成熟度提升一級建議安排1年到2年，費用問題國內外相距太遠不好比較。對企業(yè)的好處問題給出下表說明：
問題2：影響過程改進失敗的因素有：無法實施計劃和跟蹤、突發(fā)事件或危險造成、時間和資源限制造成、知道應該做什么而不知道如何做造成。
問題3：大部分（84%-96%）不認為會使組織變成官僚主義機構、難于創(chuàng)新和不敢冒風險。
問題4：這需要不斷總結經驗，提出辦法。
在國內要想取得過程改進成功，作者認為：
1、 軟件過程改進必須有高級主管的支持與委托，并積極地管理過程改進的進展。
2、 中層管理的支持很重要
3、 責任分明，過程改進小組威望高
4、 基層的支持與參與極端重要
5、 如何利用定量的可觀察數(shù)據(jù)，盡快使過程改進成果可見，從而激勵參與者的興趣
6、 為企業(yè)的商業(yè)利益服務，并要求有成功的過程改進相符的企業(yè)文化變革
如果企業(yè)出現(xiàn)如下情況，過程改進肯定就失?。?br> 1、 高層領導機構態(tài)度不明確，見解不一致
2、 各部門只管自己，互不通氣，互不支持
3、 對以前不成功的過程改進冷嘲熱諷
4、 項目成員認為軟件過程改進會影響實際工作，而不支持軟件過程改進活動
結論：CMM不是萬能的，它的成功與否，與一個組織內部有關人員的積極參與和創(chuàng)造性活動是密不可分的。
CMM是對軟件工程的工業(yè)實踐所需的有關目標、方法和實踐的最佳有效描述。問題是如何在一個實驗室或者產業(yè)環(huán)境中做到CMM規(guī)則的應用？
CMM是一個致力于組織過程改進的框架，問題是如何才能確保CMM使工作有效而且便利？
未提供有關實現(xiàn)關鍵過程域所需要的具體知識和技能。
因此，個體軟件過程PSP(Personal Software Process)也就應運而生。
PSP概述
個體軟件過程（Personal Software Process ,PSP）是由美國Carnegie Mellon大學軟件工程研究所(CMU/SEI)的Watts s. Humphrey領導開發(fā)的，于1995年它的推出，在軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個標志。PSP是一種可用于控制、管理和改進個人工作方式的自我改善過程，是一個包括軟件開發(fā)表格、指南和規(guī)程的結構化框架。 PSP為基于個體和小型群組軟件過程的優(yōu)化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質量，如何與其他人相互協(xié)作等等。在軟件設計階段， PSP的著眼點在于軟件缺陷的預防，其具體辦法是強化設計結束準則，而不是設計方法的選擇。根據(jù)對參加培訓的104位軟件人員的統(tǒng)計數(shù)據(jù)表明，在應用了PSP后，軟件中總的差錯減少了58.0％，在測試階段發(fā)現(xiàn)的差錯減少了71.0％，生產效率提高了20.0％。PSP的研究結果還表明，絕大多數(shù)軟件缺陷是由于對問題的錯誤理解或簡單的失誤所造成的，只有很少一部分是由于技術問題而產生的。而且根據(jù)多年來的軟件工程統(tǒng)計數(shù)據(jù)表明，如果在設計階段注入一個差錯，則這個差錯在編碼階段引發(fā)了3一5個新的缺陷，要修復這些缺陷所花的費用要比修復這個設計缺陷所花的費用多一個數(shù)量級。因此，PSP保障軟件產品質量的一個重要途徑是提高設計質量。
個體軟件過程PSP的現(xiàn)狀
o 從1993年開始，美國、歐洲、澳大利亞等地已先后有20多所大學開設了講授PSP的課程。
o 在工業(yè)界，PSP也先后在Motorola、 HP、 AIS等公司推廣使用。
o 北航軟件工程研究所于1997年開始，在北航計算機科學與工程系率先講授了PSP課程，并組織了PSP應用實驗。
個體軟件過程PSP的演化*
個體軟件過程PSP的內容
PSP與具體的技術（程序設計語言、工具或者設計方法）相對獨立，其原則能夠應用到幾乎任何的軟件工程任務之中。PSP能夠：
(1) 說明個體軟件過程的原則；
(2) 幫助軟件工程師作出準確的計劃；
(3) 確定軟件工程師為改善產品質量要采取的步驟；
(4) 建立度量個體軟件過程改善的基準；
(5) 確定過程的改變對軟件工程師能力的影響。
個體軟件過程PSP支持環(huán)境
北航軟件工程研究所在研制的基于Internet的"個體軟件過程支持環(huán)境"，支持個體軟件過程的定義、運作、度量、分析和優(yōu)化，支持PSP在實際軟件開發(fā)項目中的應用，支持PSP概念和方法的推廣普及，支持軟件工作人員軟件工程方面素質的提高。
個體軟件過程PSP的作用
l 使用自底向上的方法來改進過程，向每個軟件工程師表明過程改進的原則，使他們能夠明白如何有效地生產出高質量 的軟件。
l 為基于個體和小型群組軟件過程的優(yōu)化提供了具體而有效的途徑。其研究與實踐填補了CMM的空白。
l 幫助軟件工程師在個人的基礎上運用過程的原則，借助于PSP提供的一些度量和分析工具，了解自己的技能水平，控 制和管理自己的工作方式，使自己日常工作的評估、計劃和預測更加準確、更加有效，進而改進個人的工作表現(xiàn)，提 高個人的工作質量和產量，積極而有效地參與高級管理人員和過程人員推動的組織范圍的軟件工程過程改進。
群組軟件過程TSP概述
致力于開發(fā)高質量的產品，建立、管理和授權項目小組，并且指導他們如何在滿足計劃費用的前提下，在承諾的期限范圍內，不斷生產并交付高質量的產品。
TSP指導項目組中的成員如何有效地規(guī)劃和管理所面臨的項目開發(fā)任務，并且告訴管理人員如何指導軟件開發(fā)隊伍。始終以最佳狀態(tài)來完成工作。TSP實施集體管理與自己管理自己相結合的原則，最終目的在于指導開發(fā)人員如何在最少的時間內，以預定的費用生產出高質量的軟件產品，所采用的方法是對群組開發(fā)過程的定義、度量和改進。
實現(xiàn)TSP方法需要具備的條件
o 需要有高層主管和各級經理的支持，以取得必要的資源
o 整個軟件開發(fā)小組至少應在CMM的第二級（可重復層）。
o 全體軟件開發(fā)人員必須經過PSP的培訓，并有按TSP工作的愿望和熱情。
o 開發(fā)小組成員應在2到20個人之間。
在實施TSP的過程中，首先要有明確的目標，開發(fā)人員要努力完成已經接受的委托任務。在每一階段開始，要做好工作計劃。如果發(fā)現(xiàn)未能按期按質完成計劃，應立即分析原因，以判定問題是由于工作內容不合適或工作計劃不實際所引起，還是由于資源不足或主觀努力不夠所引起。開發(fā)小組一方面應隨時追蹤項目進展狀態(tài)并進行定期匯報，另一方面應經常評審自己是否按PSP的原理工作。開發(fā)小組成員應按自己管理自己的原則管理軟件過程，如發(fā)現(xiàn)過程不合適，應及時改進，以保證用高質量的過程來產生高質量的軟件。項目開發(fā)小組則按集體管理的原則進行管理，全體成員都要參加和關心小組的規(guī)劃、進展的追蹤和決策的制定等項工作。
按TSP原理對開發(fā)小組的基本度量要素
o 所編文檔的頁數(shù)。
o 所編代碼的行數(shù)。
o 花費在各開發(fā)階段或各開發(fā)任務上的時間（以分為單位）。
o 在各個開發(fā)階段中引入和改正的差錯數(shù)目。
o 在各個階段對最終產品增加的價值。
度量TSP實施質量的過程質量元素
o 軟件設計時間應大于軟件實現(xiàn)時間。
o 設計評審時間至少應占一半以上的設計時間。
o 代碼評審時間至少應占一半以上的代碼編制時間。
o 在編譯階段發(fā)現(xiàn)的差錯不超過10個/KLOC
o 在測試階段發(fā)現(xiàn)的差錯不超過5個/KLOC。
CMM、PSP和TSP組成的軟件過程框架
l CMM是過程改善的第一步，它提供了評價組織的能力、識別優(yōu)先改善需求和追蹤改善進展的管理方式。企業(yè)只有開始 CMM改善后，才能接受需要規(guī)劃的事實，認識到質量的重要性，才能注重對員工經常進行培訓，合理分配項目人員， 并且建立起有效的項目小組。然而，它實現(xiàn)的成功與否與組織內部有關人員的積極參加和創(chuàng)造性活動密不可分。
l PSP能夠指導軟件工程師如何保證自己的工作質量，估計和規(guī)劃自身的工作，度量和追蹤個人的表現(xiàn)，管理自身的軟 件過程和產品質量。經過PSP學習和實踐的正規(guī)訓練，軟件工程師們能夠在他們參與的項目工作之中充分運用PSP，從 而有助于CMM目標的實現(xiàn)。
l TSP結合了CMM的管理方法和PSP的工程技能，通過告訴軟件工程師如何將個體過程結合進小組軟件過程，并將后者與 組織進而整個管理系統(tǒng)相聯(lián)系；通過告訴管理層如何支持和授權項目小組，堅持高質量的工作，并且依據(jù)數(shù)據(jù)進行項 目的管理，向組織展示如何應用CMM的原則和PSP的技能去生產高質量的產品。
PSP和TSP對CMM的支持*
l CMM/TSP/PSP代表了目前國際上軟件過程工程研究方面最先進的成果，它們對促進軟件生產的科學化管理，提高軟件 生產能力意義重大。
l 軟件的生產過程及其它的許多子過程、軟件的開發(fā)者和用戶、以及系統(tǒng)的使用中存在著巨大的變化和不同，要使一個 軟件過程對軟件生產的改善真正有所幫助，其框架應是由CMM、TSP和PSP組成的一個完整體系，即從組織、群組和個 人三個層次進行良好的軟件工程和管理實踐的指導和支持?？偠灾?，單純實施CMM，永遠不能真正做到能力成熟度 的升級，只有將實施CMM與實施PSP和TSP有機地結合起來，才能發(fā)揮最大的效力。
建議
過程改善工作必然具有一切過程所具有的固有特征，即需要循序漸進，不能一蹴而就需要持續(xù)改善，不能停滯不前；需要聯(lián)系實際，不能照本宣讀需要適應變革，不能凝固不變。我認為，將CMM／PSP／TSP引人軟件企業(yè)最有效的途徑首先要對單位主管和主要開發(fā)人員進行系統(tǒng)的培訓。Carnegie Mellon大學軟件工程研究所曾嘗試讓軟件工程師通過自學的方式來進行，但實際上，只有不到20％的人能夠堅持到底。另外一個有效的途徑是自頂向下的課程培訓，即從高層主管依次普及到下面的工程師。
CMM就如同軟件生產的一面鏡子，以之來衡量自己可以折射出企業(yè)發(fā)展的水平以及具體的差距。借鑒CMM的方法，改進軟件研發(fā)項目管理，提高軟件開發(fā)水平。軟件研發(fā)項目管理管理是影響軟件研發(fā)項目全局的因素，而技術只影響局部。建議以CMM為框架，先從PSP做起，然后在此基礎上逐漸過渡到TSP，以保證CMM／PSP／TSP確實在企業(yè)中生根開花。我相信只要堅持改善軟件工程的管理，并在實踐中總結適合自身的經驗，一定能取得很好的效果。
不過強調一點，我們必須根據(jù)自身的實際制定可行的方案。不深入研究就照搬別的企業(yè)的模式是很難起到提高軟件產品質量水平的真正目的的。
/*
本文來自--
http://www.china-pub.com/computers/eMook/0891/info.htm
中國互動出版網
2001-4-10
*/
________________________________________
主頁 論壇 留言 打印 聯(lián)系
軟件開發(fā)質量保證體系
來自lannuo.533.net
________________________________________
1. 使用范圍
2. 引用標準
3. 定義
4. 質量體系框架
4.1 管理職責
4.2 質量體系
4.3 評審
4.4 糾正措施
5. 質量體系生存周期
5.1 合同評審
5.2 需方需求規(guī)格說明
5.3 開發(fā)計劃
5.4 質量計劃
5.5 設計和實現(xiàn)
5.6 測試和確認
5.7 驗收
5.8 復制、交付和安裝
5.9 維護
軟件開發(fā)質量保證體系
公司內部標準
本標準參照ISO9000-3 《質量管理和質量保證標準 第三部分：在軟件開發(fā)、供應和維護中的使用指南》。
1、 使用范圍
本標準作為本公司在軟件項目開發(fā)、供應和維護時的質量要求，以保證產品的質量，防止不合格產品。
以下詳細描述了軟件開發(fā)各階段的控制手段和要求。要求質量保證貫穿各個階段，始終保證嚴格實施。
2、 引用標準
本標準制定考慮本公司的實際情況，因此本標準僅用于本公司內部控制產品質量。
使用本文檔時，請盡量參照最新版本。
3、 定義
產品：以下指軟件產品，即交付給用戶的一整套計算機程序、規(guī)程及相關的文檔和數(shù)據(jù)。
開發(fā)：創(chuàng)作軟件產品的所有活動。
供方：指本公司。
需方：指具體項目的需求方，即客戶。
質量體系：質量要素、各要素需要達到的目標以及在開發(fā)過程中必須采取的措施。
4、 質量體系框架
4.1管理職責
4.1.1 供方(及具體的項目開發(fā)組)負責以下職責
組織機構
本公司內部專門設立部門質量保證部門，由部門負責人及專門經過培訓的人員組成。具體項目開發(fā)組，設立質量保證組，或委托公司質量保證部門協(xié)助開展工作。
質量保證部門負責以下工作：
建立并維護公司內部的質量保證體系。
對可能導致產品不合格的問題予以識別，采取措施予以避免。
發(fā)現(xiàn)并記錄產品的質量問題。
提出、采取或推薦問題解決辦法。
驗證解決辦法的實施效果。
對不合格產品的處理、交付過程進行控制，確保最終問題得以糾正。
質量保證部門的評審活動應由與被評審工作無直接責任的人員組成。
制定質量方針和質量目標
確保項目組成員均理解質量方針并能堅持貫徹執(zhí)行。
公司內部制定一般性的質量方針及對軟件產品的質量目標，作為各項目組的參照，各項目組可根據(jù)具體客戶期望及需求作出具體質量目標及質量承諾，具體質量目標及承諾，特別是超出公司目標的部分，提交給質量保證部門，以便提交給質量保證部門充分理解并協(xié)助實施。
《質量方針和質量目標》見附錄
管理評審
質量保證部門負責人應每月對質量體系進行評審，主要是對內部質量審核結果的評定，以保證質量體系持續(xù)有效，保存評審記錄。
4.1.2 需方（客戶）應負的職責
在項目中，應向需方（客戶）提出具體要求，明確其需要承擔的職責，以便相互配合，共同保證項目的順利實施。
需方應明確指定項目相關負責人，應具有足夠的權力處理以下問題：
向供方提出需求
回答供方提出的某些相關問題
認可供方的提案
與供方簽訂協(xié)議并能確保遵守簽訂的協(xié)議
規(guī)定驗收準則和規(guī)程
向供方提供必要的信息,提供有利的環(huán)境并解決項目中一些障礙。
4.1.3 共同評審
雙方定期地交流，并聯(lián)合評審軟件是否滿足已經商定的需求規(guī)格說明書。
4.2 質量體系
本質量體系貫穿整個開發(fā)周期，是為了在開發(fā)過程中保證質量，并非在開發(fā)結束時才檢查質量問題，所以重點強調防止問題地發(fā)生，問題發(fā)生后的糾正僅作為補充手段。
本公司將采取必要手段保證這一體系得以有效地貫徹實施。
質量體系文件
本公司的質量體系文件,包括質量要素、各要素需要達到的目標以及在開發(fā)過程中必須采取的措施。
質量體系文件見附錄《質量體系文件》
質量計劃
具體項目開發(fā)組根據(jù)公司質量體系制訂質量活動計劃并形成《質量保證計劃》，以保證開發(fā)組能正確理解質量體系并能遵照執(zhí)行。
附錄之《質量保證計劃指導》作為各項目組制訂計劃的指導。
4.3 審核
本公司內部建立全面的審核制度，以驗證各具體項目中的質量活動是否符合計劃要求，同時檢查質量體系的有效性，以不斷完善質量體系。
審核過程及采取的措施均要按書面方式進行。
審核結果形成報告，提交審核部門負責人。對于審核時發(fā)現(xiàn)的問題，相關負責人應及時采取措施。
4.4 糾正措施
糾正措施必須制定書面規(guī)程，應包括以下內容：
調查問題產生的直接原因，并制定防止同類事件發(fā)生所需的措施。
查詢分析各類過程記錄、讓步記錄、操作記錄、質量記錄、客戶投訴等等，已查明潛在原因并消除
根據(jù)風險程度，采取預防措施
對糾正措施的有效實施加以控制
對糾正措施的記錄
5. 質量體系生存周期
要求各階段必須有合格的產品（包括文檔），并以其作為下一階段的工作基礎。對每一階段的產品，必須組織評審，確保其質量，避免錯誤影響后續(xù)工作。
本標準適用于任何生存周期模型。
5.1 合同評審
本公司應評審每一合同，以確保：
規(guī)定合同的范圍和需求并寫入文檔
識別可能出現(xiàn)的風險
恰當?shù)谋Ｗo有關的專利信息
解決所有與招標不一致的需求
有能力滿足需求
規(guī)定其他涉及項目的供貨商的責任
統(tǒng)一雙方對術語的理解
需方有能力履行合同職責
合同評審記錄應妥善保管。
此外，應注意有關質量條款
驗收準則
在開發(fā)過程中對需求變更的處理
對驗收后出現(xiàn)問題的處理
確定需方的責任，尤其是在需求規(guī)格說明、安裝和驗收時的作用
有需方提供的必要便利條件，如設施、工具和軟件等
采用的標準和規(guī)程
5.2 需方需求規(guī)格說明
在某一具體項目進行開發(fā)前，本公司應具有一套該項目的完整、精確、無歧義的功能需求，這些需求應包括需方的所有要求。
因為本公司在業(yè)務領域具有豐富的經驗，可以大力配合客戶識別并確定需求，需求在開發(fā)前得到需方的確認。
該需求應足以成為產品驗收確認時的依據(jù)。
在制訂需求規(guī)格說明時應注意：
雙方制定專人負責
需求認可和更改的批準
防止誤解，定義好術語，對需求的背景進行說明
記錄和評審雙方討論的結果，以備將來查詢某些需求確定原因。
5.3開發(fā)計劃
在項目進行前制定開發(fā)計劃，作為總體的策劃，指導整個項目有序的進行。
開發(fā)計劃要求包括以下方面：
項目定義
項目資源組織管理
開發(fā)階段
進度
確定質量保證計劃、測試計劃、集成計劃等
隨著項目的進展，開發(fā)計劃要不斷更新，在生命周期模型每一階段開始之前，都要有該階段的工作計劃，并經過評審后實施。
以下較詳細的說明開發(fā)計劃中應具備的各方面。
A. 開發(fā)階段
開發(fā)計劃應將項目目標轉化為最終結果的過程、方法等清楚的描述出來，可以把工作分為幾個階段，比如按照生命周期法劃分開發(fā)階段。
開發(fā)階段要確定以下項：
要執(zhí)行的開發(fā)階段
每一階段所需的輸入
必須用文檔方式確定下來，每一項需求均有明確的定義，以保證完成情況可被檢驗。
每一階段應產生的輸出
驗證階段輸出，必須滿足以下幾點：
滿足相應的要求
有明確的驗收準則，作為驗收評審的參考。
符合開發(fā)慣例和約定
每一階段需要執(zhí)行的驗證步驟
必須有對每階段輸出的驗證計劃，并在適當?shù)臅r間進行驗證評審。
分析各階段可能潛在的問題或需要解決的問題
B. 項目管理
項目開發(fā)、實施等過程的時間進度安排
進度的控制方法及活動
確定組織機構及其職責、各工作組的資源及工作分配
不同工作組間的組織協(xié)調方法，并明確技術接口問題。
C. 開發(fā)方法和工具
規(guī)定項目活動應共同遵循的方法及使用的工具，包括：
開發(fā)規(guī)范、慣例
開發(fā)工具及技術
5.4 質量計劃
質量計劃作為開發(fā)計劃的一部分。
質量計劃隨項目進展而更新，質量計劃經正式評審，并得到所有與計劃執(zhí)行有關的組織的統(tǒng)一。
質量計劃應包含或引用以下內容：
質量目標，盡可能以定量方式給出
定義每一階段的輸入、輸出準則
確定要進行的測試、驗證和確認活動的類型和詳細計劃，包括時間、進度等。
確定具體質量活動的職責：比如，評審和測試、更改控制、對缺陷的控制和糾正措施。
5.5 設計和實現(xiàn)
設計和實現(xiàn)活動是將需求規(guī)格說明轉化為軟件產品的過程。為保證軟件產品的質量，這些活動必須在嚴格規(guī)定的方法下進行，不能依賴于事后的審查監(jiān)督。
設計
設計階段要滿足各階段的共同要求，此外，設計階段還應考慮：
選用適合所開發(fā)產品類型的設計方法
總結吸取以往項目的經驗教訓
設計應考慮軟件以后的測試、維護和使用
B. 實現(xiàn)
規(guī)定編程規(guī)則、編程語言、命名約定、編碼和注釋規(guī)則等
要求在實現(xiàn)過程中嚴格遵守既定開發(fā)規(guī)則
選用合適的方法和工具實現(xiàn)產品
本公司內部制定《開發(fā)規(guī)范》，各項目組可參照制定適合特定項目的規(guī)范。
C. 評審
為使需求規(guī)格說明得以滿足和上述規(guī)則方法得以實施，必須以評審的方式加以保證。直到所有被發(fā)現(xiàn)的缺陷被消除，或確定缺陷的風險可被控制后，才能進入下一步的設計或實現(xiàn)工作。
各項目組引用公司規(guī)范或參照制定的開發(fā)規(guī)范應在取得本項目組廣泛認可的情況下，提交給評審部門，作為評審參照依據(jù)。
評審紀錄應保存，評審結果可能作為個人及項目組工作成績評定的參考之一。
5.6 測試和確認
要具有完整的測試計劃，測試計劃要經過評審，并以此為依據(jù)進行測試活動。
A.測試計劃
包括單元測試計劃、集成測試計劃、系統(tǒng)測試計劃、驗收測試計劃
制定測試用例、測試數(shù)據(jù)和預期結果
考慮要進行的測試類型，如：功能測試、邊界測試、性能測試、可用性測試等
描述測試環(huán)境、工具以及測試軟件
軟件產品是否完成的判斷準則
測試所需人員及其要求
B.測試活動
記錄發(fā)現(xiàn)的問題，指出可能的受影響的其他部分的軟件，通知相關負責人員。
確定受影響的其他部分軟件，并對其進行重新測試。
評價測試是否適度和適當。
在驗收和交付產品前，必須盡可能在類似使用環(huán)境中進行確認測試。
5.7 驗收
當軟件產品已經完成，經過內部確認測試，準備好交付后，應要求需方根據(jù)合同中的規(guī)定原則判斷是否可以進行驗收。對于驗收中發(fā)現(xiàn)問題的處理辦法由雙方商定并納入文檔。
具備驗收條件后，應制定驗收計劃并逐步實施。
驗收計劃應包括：
時間進度
評估規(guī)程
軟件/硬件環(huán)境
驗收準則
5.8 復制、交付和安裝
制定安裝分發(fā)計劃。
復制
制作好安裝程序，復制好必要的拷貝。
準備好該交付的操作手冊、用戶指南等文檔。
交付
交付前應對所交付產品的正確性及完整性進行檢驗。
安裝
就以下方面雙方明確商定各自的作用、責任和義務：
時間進度及安排，包括非工作時間及假日的人員安排及工作責任
提供出入便利條件，如通行證等
指定熟練人員的密切配合
提供必要的系統(tǒng)及設備
對每次安裝的確認條件需明確規(guī)定
對每次安裝認可的正式規(guī)程
5.9 維護
對于軟件產品在初次交付及安裝后，本公司必須提供的維護應在合同中明確規(guī)定。合同中應明確以下各項的維護期：
程序
數(shù)據(jù)
規(guī)格說明
維護工作一般包括：
問題的解決
接口的調整
功能擴充和性能改進
本公司針對以上維護工作制訂完善的維護方案，并嚴格遵照執(zhí)行。具體維護方案見《維護工作流程》
附錄C 質量體系文件
包括質量要素、各要素需要達到的目標以及在開發(fā)過程中必須采取的措施
質量要求要素定義如下：
正確性 在預定環(huán)境下，軟件滿足設計規(guī)格說明及用戶預期目標的程度。它要求軟件沒有錯誤。
可靠性 軟件按照設計要求，在規(guī)定時間和條件下不出故障，持續(xù)運行的程度。
效率 為了完成預定功能，軟件系統(tǒng)所需的計算機資源的多少。
完整性 為了某一目的面保護數(shù)據(jù)，避免它受到偶然的，或有意的破壞、改動或遺失的能力。
可使用性 對于一個軟件系統(tǒng)，用戶學習、使用軟件及為程序準備輸入和解釋輸出所需工作量的大小。
可維護性 為滿足用戶新的要求，或當環(huán)境發(fā)生了變化，或運行中發(fā)現(xiàn)了新的錯誤時，對一個已投入運行的軟件進行相應診斷和修改所需工作量的大小。
可測試性 測試軟件以確保其能夠執(zhí)行預定功能所需工作量的大小。
靈活性 修改或改進一個已投入運行的軟件所需工作量的大小。
復用性 一個軟件（或軟件的部分）能再次用于其它應用（該應用的功能與軟件或軟件部件的所完成功能有聯(lián)系）的程度。
在設計開發(fā)過程中，必須注意以下要求，以保證軟件的質量達到目標。
正確性
軟件的功能要滿足用戶的要求，在預定環(huán)境下能夠完成預期的功能。因此，必須明確的了解用戶的需求。
在需求確定方面，應通過深刻的理解電信企業(yè)的運營系統(tǒng)及了解其發(fā)展趨勢，建立模型并分析，廣泛了解其他系統(tǒng)的特長，并總結以往的經驗教訓的基礎上，確定出需求并通過與用戶的交流最終確定。
在需求的表達方面，強調以全面、精確、細致、易于理解的方式表達，可能需要以多種形式，比如：功能描述、數(shù)據(jù)描述、數(shù)據(jù)流圖、系統(tǒng)說明等。
可維護性
遵從統(tǒng)一的規(guī)范，包括命名規(guī)范、界面規(guī)范、編程風格。
編碼應具有良好的可讀性，注釋完整清晰。
避免復雜的邏輯判斷條件，易讀，易測試
編碼應盡量簡練，邏輯簡單
保存異常信息與錯誤日志以便于調試與分析
降低模塊之間的耦合度，增強模塊內的內聚。
可用性
用戶容易理解和使用該功能
響應時間快，操作方便，提高用戶工作效率。
提示信息簡潔準確
可靠性
具有異常捕獲功能并提供異常處理與恢復功能
5、效率
盡量降低系統(tǒng)資源的開銷
查詢語句要充分考慮到索引
減少與數(shù)據(jù)庫的不必要的交互
靈活性，易于擴展
充分考慮到各地的不同的環(huán)境，通過參數(shù)設置使其易于適應不同的要求。
完整性、安全性
保證相關的數(shù)據(jù)一致性
考慮數(shù)據(jù)的存取權限。
文檔完善
按文檔要求完成相關文檔。
審查制度
對于每一階段的文檔及軟件產品都應交付證質量保證部門，由審查小組按質量要求嚴格審查。
審查內容：
文檔：開發(fā)計劃、用戶需求規(guī)格說明、概要及詳細設計文檔、技術文檔、用戶手冊等，詳細要求見文檔計劃。評審文檔是否規(guī)范，表達清晰，有實用價值。
設計方案：是否達到設計目標。
應用程序：是否達到質量目標和符合設計目標。
審查流程：
項目組按計劃準備好交付的產品及文檔
交付質量保證部門，組織評審
完成評審，發(fā)現(xiàn)錯誤報告
發(fā)現(xiàn)錯誤的返工
復查返工問題是否已解決
________________________________________
主頁 論壇 留言 打印 聯(lián)系
技術討論指南---如何“不戰(zhàn)而勝”
來自lannuo.533.net
________________________________________
限制參與者人數(shù)。精心選擇合適的人選，只讓必需的人參加，不必求全。
準備好討論問題，明確主要目的，將問題和目的書面化，這樣會更清晰，并讓參與者清楚地了解這些問題和目的。最好能給參與者比較充足的思考時間。
控制討論主題，避免離題。
注意突出重點、不要陷入細枝末節(jié)，一般能進入正式討論的問題不會是太瑣碎的問題。不要試圖在討論會上將所有作業(yè)完全做完，有些事情本應該會后進行，比如具體實現(xiàn)等。避免讓大家為個人做作業(yè)。
不能取得大家理解的問題暫時記錄在案，留待以后討論。有時一個問題被提出，但多數(shù)人并未理解該問題的重要性，除非能夠有效地解釋明白，否則應在時機更成熟時再討論。如果是關鍵核心問題當然另當別論。
不能期望取得絕對的一致，對分歧較大和爭執(zhí)不休的問題及時轉換角度，先討論判斷準則及衡量方法等，如果暫時沒有討論思路則記錄在案，留待以后討論。再更充分的思考后，更容易找到問題的關鍵點和思路。
做好書面記錄。對問題的解決做好文檔，被否定的思路也應該包含在文檔中，有利于以后理解方案選擇思路。
主持人的責任
充分理解討論目的，控制討論朝目標前進。必須做好前期準備。
對貶低和羞辱別人的行為嚴加約束。會前強調：“討論發(fā)言必需對產品而不能對人，絕對避免攻擊別人的行為，哪怕是以開玩笑的方式”，指出這樣的行為是不光彩的。討論期間如果不幸發(fā)生這樣的事情，果斷明確地指出。必要時（失去控制時）立即停止討論，不要勉強進行。正常地，引導討論在和諧的氣氛和態(tài)度中。
限制爭論和辯駁。將問題引導到判斷準則、衡量方法和解決思路上來。
制止冗長無效率的發(fā)言，制止離題的發(fā)言，制止進入瑣碎細節(jié)的發(fā)言。以簡單總結問題的方法或時間進度的理由搶回主動控制權。提醒和警告經常轉移問題的人，重申討論重點和目的。
總結討論成功與失敗的經驗，使自己和別人可以做得更好。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
任務管理
來自lannuo.533.net
概述
一個工程項目是由一系列的任務組成，合理地安排這些任務單元并保證其按時完成，才能保證整個項目進度能夠按時完成。為此我們制訂以下方法加強任務管理。
一個任務是包含在一個整體計劃環(huán)境中的，因此作為個體首先要服從于整體計劃。
任務管理方法
任務安排：
采用明確任務、明確責任的方式來安排任務。
下達任務必須書面化。
要求負責人明確、時限明確、任務表達明確、優(yōu)先順序明確。
明確任務的結果。
方法： 我們定制格式化任務安排表，附錄《任務安排工作單》即為一個實例。
協(xié)調及控制：
統(tǒng)一協(xié)調調度任務，及滿足每個人的任務量，又避免超負荷。并監(jiān)督任務能按時按質完成。
合理安排每個人的長期任務和緊急任務。
協(xié)調者必須監(jiān)督進度的進展，及時地調整或督促。
通過日常檢查監(jiān)控任務的進展。其中應特別關注關鍵路徑上的任務。
對重要任務進行正式評審。以保證其完成質量。
方法：
可以在定期舉行的例會上總結匯報工作。
為幫助統(tǒng)一管理任務及人力，我們設計了附錄《任務安排匯總表》，將任務、人力、進度三維統(tǒng)一表達，即可以看到一個任務由那幾個人來完成，及各自的角色，又可以看到每個人當前所承擔的所有任務，便于工作量均衡。進度跟蹤便于統(tǒng)計剩余任務工作量。
結果考評：
個人工作成績通過任務完成情況紀錄為依據(jù)。
任務等級定義
任務分為幾個等級，在安排任務時確定輕重緩急，任務等級作為安排者和執(zhí)行者間交流的一種簡潔的信息，包含了安排者在全局的層次上對任務的一種認識和理解，并將這種理解記錄下來，并傳達給執(zhí)行者，有利于執(zhí)行者能理解并按統(tǒng)一調度執(zhí)行任務。這樣可以更好地控制進度，避免關鍵或緊急任務被拖后。
對執(zhí)行者來說，可以有根據(jù)當前任務的優(yōu)先級，有條理地安排工作。
任務等級可從以下方面來考慮：
緊急程度：（對任務過程的時間要求）
寬松：時限十分寬松，可以在其他任務后考慮。
一般：時間比較充裕，可以合理安排進度。
較急：有明確要求的時限，且應該盡快著手盡快完成。一般在關鍵路徑上的任務至少有較急的級別。
緊急：立即著手，以盡快的速度解決問題。一般在任務進度可能造成較大影響時定義該級別，比如影響項目進度或影響客戶業(yè)務使用。具有較高的優(yōu)先級別，
特急：立即著手，需要時必須加班，需要趕赴現(xiàn)場時必須以最快的速度到達。需要其他人力配合時立即聯(lián)系相關人員。一般在對客戶業(yè)務造成重大影響時定義特急的級別。最高優(yōu)先級別。
注釋：緊急程度可能隨著時間變動。
重要程度：（對任務本身的影響及作用的估計）
不重要：任務失敗不會造成嚴重結果，能夠容忍。
普通：任務失敗會造成一定影響，能通過措施補救，不在關鍵路徑上，不影響整體進度，不影響客戶業(yè)務。
重要：任務重要，對整個系統(tǒng)或項目影響很大，比如在關鍵路徑上的任務，必須保證其成功完成。一般要在工期和質量上給以充分的控制。
關鍵：影響整個系統(tǒng)或項目的成敗，必須給予最高的重視，對任務進行充分的控制，確保成功完成。
任務排序優(yōu)先級：（任務執(zhí)行的先后次序，利于有條理的工作）
暫緩：盡量向后安排
普通：按順序安排
盡快：盡量向前安排
立即：安排在任務列表最前。
以上作為粗略地優(yōu)先級別估計，方便于優(yōu)先級的調整，缺省地，任務排序按照緊急在先、重要在先的原則排列。
特急 緊急 較急 一般 寬松
關鍵 *****！ ****！ ***！ **！ /
重要 ***** **** *** **
普通 / **+ *+ +
不重要 / + -
表中符號代表分值： *：20 ！：10 +：5 -：-5 /：不定義
附件一：任務匯總表（示例） 可打印格式見其word文檔 - 任務管理
任 務 匯 總 表 項目簡稱： 階段日期：
任務編號 任務概述 工作量 最后時限 人員A 。 。 人員N 計劃 分析 開發(fā) 測試 實施 反饋 完成時間
工作量：
d天 h小時 角色：M負責 A分析 D設計 P編碼 T測試 J輔助參與 進度：已完成則打勾
附件二：任務單（示例） 可打印格式見其word文檔 - 任務管理
任 務 單 任務編號
任務負責人簽字： 任務協(xié)調人：
重要級別：□關鍵 □重要 □普通 □不重要 工作量：
緊急級別：□特急 □緊急 □較急 □一般 □寬松 最后期限：
概述：
任務詳述：
完成日期：
任務負責人總結（如果任務延期或失敗，請說明原因）：
評價：□優(yōu)秀 □良 □基本滿意 □不滿意 □很差
備注：
________________________________________
主頁 論壇 留言 打印 聯(lián)系
項目管理篇系列之七 - 項目管理軟件
摘自www.computerworld.com.cn
左美云 李東 董小英等著
項目管理技術的發(fā)展與計算機技術的發(fā)展密不可分，隨著計算機性能的迅速提高，大量的項目管理軟件涌現(xiàn)出來。它們可以用于各種商業(yè)活動，提供便于操作的圖形界面，幫助用戶制定任務、管理資源、進行成本預算、跟蹤項目進度等。
具備的功能
目前，市場上大約有120多種項目管理軟件工具。這些軟件各具特色，各有所長。這里列出大多數(shù)項目管理軟件具備的主要功能。
1．成本預算和控制
輸入任務、工期，并把資源的使用成本、所用材料的造價、人員工資等一次性分配到各任務包，即可得到該項目的完整成本預算。在項目實施過程中，可隨時對單個資源或整個項目的實際成本及預算成本進行分析、比較。
2．制定計劃、資源管理及排定任務日程
用戶對每項任務排定起始日期、預計工期、明確各任務的先后順序以及可使用的資源。軟件根據(jù)任務信息和資源信息排定項目日程，并隨任務和資源的修改而調整日程。
3．監(jiān)督和跟蹤項目
大多數(shù)軟件都可以跟蹤多種活動，如任務的完成情況、費用、消耗的資源、工作分配等。通常的做法是用戶定義一個基準計劃，在實際執(zhí)行過程中，根據(jù)輸入當前資源的使用狀況或工程的完成情況，自動產生多種報表和圖表，如“資源使用狀況”表、“任務分配狀況”表、進度圖表等。還可以對自定義時間段進行跟蹤。
4．報表生成
與人工相比，項目管理軟件的一個突出功能是能在許多數(shù)據(jù)資料的基礎上，快速、簡便地生成多種報表和圖表，如甘特圖、網絡圖、資源圖表、日歷等。
5．方便的資料交換手段
許多項目管理軟件允許用戶從其他應用程序中獲取資料，這些應用程序包括Excel、Access、Lotus或各種 ODBC兼容數(shù)據(jù)庫。一些項目管理軟件還可以通過電子郵件發(fā)送項目信息，項目人員通過電子郵件獲取信息，如最新的項目計劃、當前任務完成情況以及各種工作報表。
6．處理多個項目和子項目
有些項目很大而且很復雜，將其作為一個大文件進行瀏覽和操作可能難度較大。而將其分解成子項目后，可以分別查看每個子項目，更便于管理。另外，有可能項目經理或成員同時參加多個項目的工作，需要在多個項目中分配工作時間。通常，項目管理軟件將不同的項目存放在不同的文件中，這些文件相互連接。也可以用一個大文件存儲多個項目，便于組織、查看和使用相關數(shù)據(jù)。
7．排序和篩選
大多數(shù)項目管理軟件都提供排序和篩選功能。通過排序，用戶可以按所需順序瀏覽信息，如按字母順序顯示任務和資源信息。通過篩選，用戶可以指定需要顯示的信息，而將其他信息隱藏起來。
8．安全性
一些項目管理軟件具有安全管理機制，可對項目管理文件以及文件中的基本信息設置密碼，限制對項目文件或文件中某些數(shù)據(jù)項的訪問，使得項目信息不被非法之徒盜取。
9．假設分析
“假設分析”是項目管理軟件提供的一個非常實用的功能，用戶可以利用該功能探討各種情況的結果。例如，假設某任務延長一周，則系統(tǒng)就能計算出該延時對整個項目的影響。這樣，項目經理可以根據(jù)各種情況的不同結果進行優(yōu)化，更好地控制項目的發(fā)展。
常見的項目管理軟件
根據(jù)項目管理軟件的功能和價格水平，大致可以劃分為兩個檔次：一種是供專業(yè)項目管理人士使用的高檔項目管理軟件，這類軟件功能強大，價格一般在2000美元以上，如Primavera公司的P3、Gores技術公司的 Artemis、ABT公司的WorkBench、Welcom公司的OpenPlan等。另一類是低檔項目管理軟件，應用于一些中小型項目，這類軟件雖功能不很齊全，但價格較便宜，如 TimeLine公司的TimeLine、Scitor公司的Project Scheduler、Primavera公司的 SureTrak、Microsoft公司的Project 2000等。
1．Microsoft Project 2000
Microsoft Project 2000是一種功能強大而靈活的項目管理工具，可用于控制簡單或復雜的項目。它能夠幫助您建立項目計劃、對項目進行管理，并在執(zhí)行過程中追蹤所有活動，使用戶實時掌握項目進度的完成情況、實際成本與預算的差異、資源的使用情況等信息。
Microsoft Project 2000的界面標準、易于使用，具有項目管理所需的各種功能，包括項目計劃、資源的定義和分配、實時的項目跟蹤、多種直觀易懂的報表及圖形、用Web頁面方式發(fā)布項目信息、通過Excel、Access或各種 ODBC兼容數(shù)據(jù)庫存取項目文件等。
2.Primavera Project Planner
Primavera Project Planner（簡稱P3）工程項目管理軟件是美國Primavera公司的產品，是國際上流行的高檔項目管理軟件，已成為項目管理的行業(yè)標準。
P3軟件適用于任何工程項目，能有效地控制大型復雜項目，并可以同時管理多個工程。P3軟件提供各種資源平衡技術，可模擬實際資源消耗曲線、延時；支持工程各個部門之間通過局域網或Internet進行信息交換，使項目管理者可以隨時掌握工程進度。P3還支持ODBC，可以與Windows程序交換數(shù)據(jù)，通過與其他系列產品的結合支持數(shù)據(jù)采集、數(shù)據(jù)存儲和風險分析。
3．SureTrak Project Manager
Primavera公司除了有針對大型、復雜項目的P3項目管理軟件以外，還有管理中小型項目的SureTrak。SureTrak是一個高度視覺導向的程序，利用SureTrak的圖形處理方式，項目經理能夠簡便、快速地建立工程進度并實施跟蹤。它支持多工程進度計算和資源計劃，并用顏色區(qū)分不同的任務。對于不同的人以不同方式建立的工程，SureTrak也能把它們放在一起作為工程組管理。此外，SureTrak還提供40多種標準報表，可任意選取、輸出所需要的信息。利用電子郵件和網上發(fā)布功能，項目組成員可進行數(shù)據(jù)交流，如上報完成情況、接收上級安排的任務等。利用VB、C++或SureTrak自身的SBL語言,可訪問SureTrak的開放式數(shù)據(jù)庫結構和OLE，必要時可把工程數(shù)據(jù)合并到其他信息系統(tǒng)。
4．CA-SuperProject
Computer Associates International公司的CA-SuperProject是一個很常用的軟件，適合于多種平臺，包括Windows、OS/2、 Unix/Solaris、DOS 和VAX/VMS等。大量的視圖有助于用戶了解、分析和管理項目的各方面。容易發(fā)現(xiàn)和有效解決資源沖突，并提供各種工具，使用戶在多個項目之間調整進度表和資源。CA-SuperProject先進和靈活的進度安排可以讓用戶準確模擬真實世界。還可以根據(jù)預定計劃、當前完成情況、剩余情況，精確地重新制定剩余部分的執(zhí)行計劃。
5．Project Management Workbench(PMW)
PMW項目管理軟件是應用商業(yè)技術公司（ABT）的產品，該軟件可以管理復雜的項目。它運行在Windows操作系統(tǒng)下，提供了對項目建模、分析和控制的圖形化手段，具有項目管理所需的各種功能，深受廣大工程人員的歡迎。
6．Project Scheduler
Project Scheduler是Scitor公司的產品，它可以幫助用戶管理項目中的各種活動。Project Scheduler的資源優(yōu)先設置和資源平衡算法非常實用，利用項目分組，用戶可以觀察到多項目中的一個主進度計劃，并可以分析更新。數(shù)據(jù)可以通過工作分解結構、組織分解結構、資源分解結構進行調整和匯總。Project Scheduler提供了統(tǒng)一的資源跟蹤工作表，允許用戶根據(jù)一個周期的數(shù)據(jù)來評價資源成本和利用率，還有詳細的“what if”分析功能，通過ODBC連接數(shù)據(jù)庫。
7．Time Line
Time Line是Symantec公司的產品，盡管該軟件對初學者來說使用稍感困難，但仍是有經驗的項目管理經理的首選。它除了具有項目管理的所有功能外，還具有報表功能和極強的與SQL數(shù)據(jù)庫連接的功能。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
項目管理系列之六-質量管理
摘自www.computerworld.com.cn
左美云 李東 董小英等著
目前，人們對信息系統(tǒng)項目提出的要求往往只強調系統(tǒng)必須完成的功能、應該遵循的進度計劃以及開發(fā)這個系統(tǒng)所花費的成本，卻很少注意在整個生命周期中信息系統(tǒng)應該具備的質量標準。這種做法導致系統(tǒng)維護費用增加，當需要把系統(tǒng)移植到另外的環(huán)境中或使系統(tǒng)與其他系統(tǒng)配合使用時，需要完成很多輔助工作，導致總擁有成本增加。
IS建設需要全面質量控制
信息系統(tǒng)的質量管理不僅僅是項目開發(fā)完成后的最終評價，還需要在信息系統(tǒng)開發(fā)過程中進行全面質量控制。也就是說，不僅包括系統(tǒng)實現(xiàn)時的質量控制，也包括系統(tǒng)分析、系統(tǒng)設計時的質量控制；不僅包括對系統(tǒng)實現(xiàn)時軟件的質量控制，而且還包括對文檔、開發(fā)人員和用戶培訓的質量控制。
之所以對信息系統(tǒng)采取全面質量控制，是因為在信息系統(tǒng)生命周期的各個階段，對上一階段的理解以及本階段的設計與實現(xiàn)上都存在著這樣那樣的問題。在圖1中，各階段之間的接口至少存在列出來的9個問題，要想順利解決每一個問題并非易事。
圖2 軟件質量與產品活動的關系
根據(jù)一些軟件公司的統(tǒng)計資料，在后期引入一個變動比在早期引入相同變動所需付出的代價高2～3個數(shù)量級。因此，我們應該從信息系統(tǒng)開發(fā)的初始階段就進行質量控制，以便盡量在早期發(fā)現(xiàn)錯誤，及早更正。
如何建立質量指標體系？
信息系統(tǒng)的質量比較難管理，原因之一是信息系統(tǒng)的質量指標難以定義，即使能夠定義，也較難度量。由于信息系統(tǒng)的核心是軟件，因此如何度量軟件的質量成為解決問題的關鍵。這里介紹一種從管理角度度量軟件質量的方法。
我們把影響軟件質量的因素分成三組，分別反映用戶在使用軟件產品時的三種不同傾向或觀點（圖2）。這三種傾向是：產品運行、產品修改和產品轉移。信息系統(tǒng)作為一個產品，也可以參照這三種傾向來定義。
圖1 信息系統(tǒng)生命周期各階段之間的關系
我們可以采取以下步驟實施全面質量控制：
1．實行工程化開發(fā)
“信息系統(tǒng)開發(fā)方法”一詞的廣義理解是“探索復雜系統(tǒng)開發(fā)過程的秩序”；狹義理解是“一組為信息系統(tǒng)開發(fā)起工具作用的規(guī)程”，按這些規(guī)程工作，可以較合理地達到目標。規(guī)程由一系列活動組成，形成方法體系。信息系統(tǒng)是一項系統(tǒng)工程，必須建立嚴格的工程控制方法，要求開發(fā)組的每一個人都要遵守工程規(guī)范。
2．實行階段性凍結與改動控制
信息系統(tǒng)具有生命周期，這就為我們劃分項目階段提供了參考。一個大項目可分成若干階段，每個階段有自已的任務和成果。這樣一方面便于管理和控制工程進度，另一方面可以增強開發(fā)人員和用戶的信心。
在每個階段末要“凍結”部分成果，作為下一階段開發(fā)的基礎。凍結之后不是不能修改，而是其修改要經過一定的審批程序，并且涉及到項目計劃的調整。
3．實行里程碑式的審查與版本控制
里程碑式審查就是在信息系統(tǒng)生命周期每個階段結束之前，都正式使用結束標準對該階段的凍結成果進行嚴格的技術審查，如果發(fā)現(xiàn)問題，就可以及時在階段內解決。
版本控制是保證項目小組順利工作的重要技術。版本控制的含義是通過給文檔和程序文件編上版本號，記錄每次的修改信息，使項目組的所有成員都了解文檔和程序的修改過程。廣義的版本控制技術稱為軟件配制管理，并已有功能完善的軟件工具支持，如PVCS和Microsoft Visual SourceSafe。
4．實行面向用戶參與的原型演化
在每個階段的后期，快速建立反映該階段成果的原型系統(tǒng)，通過原型系統(tǒng)與用戶交互，及時得到反饋信息，驗證該階段的成果并及時糾正錯誤，這一技術被稱為“原型演化”。原型演化技術需要先進的CASE工具的支持。
5．盡量采用面向對象和基于構件的方法
面向對象的方法強調類、封裝和繼承，能提高軟件的可重用性，將錯誤和缺憾局部化，同時還有利于用戶的參與，這些對提高信息系統(tǒng)的質量都大有好處。
基于構件的開發(fā)又被稱為“即插即用編程”方法，是從計算機硬件設計中吸收過來的優(yōu)秀方法。這種編程方法是將編制好的“構件”插入已做好的框架中，從而形成一個大型軟件。構件是可重用的軟件部分，構件既可以自己開發(fā)，也可以使用其他項目的開發(fā)成果，或者直接向軟件供應商購買。當我們發(fā)現(xiàn)某個構件不符合要求時，可對其進行修改而不會影響其他構件，也不會影響系統(tǒng)功能的實現(xiàn)和測試，就好像整修一座大樓中的某個房間，不會影響其他房間的使用。
6．全面測試
要采用適當?shù)氖侄?，對系統(tǒng)調查、系統(tǒng)分析、系統(tǒng)設計、實現(xiàn)和文檔進行全面測試。
7．引入外部監(jiān)理與審計
要重視信息系統(tǒng)的項目管理，特別是項目人力資源的管理，因為項目成員的素質和能力以及積極性是項目成敗的關鍵。同時還要重視第三方的監(jiān)理和審計的引入，通過第三方的審查和監(jiān)督來確保項目質量。
________________________________________
主頁 論壇 留言 打印 聯(lián)系
項目管理系列之五-團隊管理
摘自www.computerworld.com.cn
左美云 李東 董小英等著
通常，項目小組可以按子系統(tǒng)或職能進行劃分，這里主要討論項目團隊的具體人員構成以及有效的激勵方式。
項目小組構成
這里所說的項目小組是指項目團隊的基層單位，例如，一個大項目開發(fā)團隊可以分為總體組、軟件開發(fā)組、硬件網絡組、測試組等若干個項目小組。
圖1 大型IS項目基層項目小組構成
首先，每個項目小組的人數(shù)不能太多，否則組員之間彼此通信將占用大量的時間。此外，通常我們不能把一個子系統(tǒng)劃分成大量獨立的單元模塊，如果項目小組人數(shù)太多，則每個組員所負責實現(xiàn)的單元模塊與其他成員的接口將更復雜，不僅出現(xiàn)接口錯誤的可能性增加，而且系統(tǒng)測試也會變得既困難又費時。
一般說來，每個項目小組的規(guī)模應該比較小，以2～9名成員為宜。如果項目屬于中小型規(guī)模且建設時間在一年以內，那么項目小組可以采用工作包負責人制。工作包負責人既負責該工作包的日常管理工作，同時又是該工作包的技術負責人，在其他成員中再挑選一位為助理，協(xié)助工作包負責人做好各方面的工作。
如果項目屬于大中型規(guī)模，建設時間在一年以上，那么就必須考慮項目建設人員因各種原因發(fā)生變動的情況。這時，項目小組具體構成最好如圖1所示。這里的系統(tǒng)開發(fā)人員既可以是程序員，也可以是測試員。
采用這種按技術水平分層的構成模式主要基于兩點考慮：第一，信息系統(tǒng)建設中既有創(chuàng)造性很強的事務，也有經驗性很強的事務和照葫蘆畫瓢的簡單性事務，如果所有活動都讓高級人員去完成，則導致成本上升，造成人力資源的浪費，還會引起高級人員的不滿；第二，由于項目建設時間太長，容易發(fā)生人員更替，并且由于信息系統(tǒng)開發(fā)技術主要靠“干中學”，中級和初級開發(fā)人員在系統(tǒng)建設過程中會成長起來，如果一旦發(fā)生上一層次人員變動，下層人員由于一直參與項目的研發(fā)，基本上可以“無縫”地接手工作。
如果項目小組成員不發(fā)生人員更替，則項目小組的整體素質將隨時間的推移而提高，從而使項目的進度加快。一般來說，初、中、高級人員最初的薪水可以按類似3∶7∶10的比例定位。當然，隨著初中級人員技術水平的提高，他們的薪水也應該不斷提高，因為他們在同樣時間內可以完成更多、更復雜的工作。
把握團隊成長規(guī)律
信息系統(tǒng)項目團隊的成長與其他項目一樣，一般需要經過四個階段：
1．形成階段
形成階段促使個體成員轉變?yōu)閳F隊成員。每個人在這一階段都有許多疑問：我們的目的是什么？其他團隊成員的技術、人品怎么樣？每個人都急于知道他們能否與其他成員合得來，自己能否被接受。
為使項目團隊明確方向，項目經理一定要向團隊說明項目目標，并設想出項目成功的美好前景以及成功所產生的益處；公布項目的工作范圍、質量標準、預算及進度計劃的標準和限制。項目經理在這一階段還要進行組織構建工作，包括確立團隊工作的初始操作規(guī)程，規(guī)范溝通渠道、審批及文件記錄工作。所以在這一階段，對于項目成員采取的激勵方式主要為預期激勵、信息激勵和參與激勵。
2．震蕩階段
這一階段，成員們開始著手執(zhí)行分配到的任務，緩慢地推進工作?，F(xiàn)實也許會與個人當初的設想不一致。例如，任務比預計的更繁重或更困難；成本或進度計劃的限制可能比預計的更緊張；成員們越來越不滿意項目經理的指導或命令。
震蕩階段的特點是人們有挫折、憤怨或者對立的情緒。這一階段士氣很低，成員可能會抵制形成團隊，因為他們要表達與團隊聯(lián)合相對立的個性。
因此在這一階段，項目經理要做導向工作，致力于解決矛盾，決不能希望通過壓制來使其自行消失。這時，對于項目成員采取的激勵方式主要是參與激勵、責任激勵和信息激勵。
3．正規(guī)階段
經受了震蕩階段的考驗，項目團隊就進入了發(fā)展的正規(guī)階段。項目團隊逐漸接受了現(xiàn)有的工作環(huán)境，團隊的凝聚力開始形成。這一階段，隨著成員之間開始相互信任，團隊內大量地交流信息、觀點和感情，合作意識增強，團隊成員互相交換看法，并感覺到他們可以自由地、建設性地表達他們的情緒及意見。
在正規(guī)階段，項目經理采取的激勵方式除參與激勵外，還有兩個重要方式：一是發(fā)掘每個成員的自我成就感和責任意識，引導員工進行自我激勵；二是盡可能地多創(chuàng)造團隊成員之間互相溝通、相互學習的環(huán)境，以及從項目外部聘請專家講解與項目有關的新知識、新技術，給員工充分的知識激勵。
4．表現(xiàn)階段
團隊成長的最后階段是表現(xiàn)階段。這時，項目團隊積極工作，急于實現(xiàn)項目目標。這一階段的工作績效很高，團隊有集體感和榮譽感，信心十足。團隊能感覺到被高度授權，如果出現(xiàn)技術難題，就由適當?shù)膱F隊成員組成臨時攻關小組，解決問題后再將相關知識或技巧在團隊內部快速共享。
這一階段，項目經理需要特別關注預算、進度計劃、工作范圍及計劃方面的項目業(yè)績。如果實際進程落后于計劃進程，項目經理就需要協(xié)助支持修正行動的制定與執(zhí)行。這一階段激勵的主要方式是危機激勵、目標激勵和知識激勵。
需要要強調的是，對于信息系統(tǒng)建設人才，要更多地引導他們進行自我激勵和知識激勵。當然，足夠的物質激勵是不言而喻的，它從始至終都是最有效的激勵。
激勵的結果是使參與信息系統(tǒng)的所有成員組成一個富有成效的項目團隊，這種團隊具有如下特點：
● 能清晰地理解項目的目標；
● 每位成員的角色和職責有明確的期望；
● 以項目的目標為行為的導向；
● 項目成員之間高度信任、高度合作互助。
總之，科學地管理團隊有助于項目按期、按質完成。
________________________________________
主頁 論壇 留言 打印 聯(lián)系