目前實施項目規范的考慮
由于目前軟件開發實際情況的約束，完全按照RUP實施項目管理是一個理想化思路。在實際實施中會受多方面的影響（如客戶要求、小組成員素質等），這種盲目的追求標準只會做成項目的阻礙，基于這種考慮，我認為根據實際情況采用分步實現的方式，逐步建立起一支穩定的、技術分工合理的開發TEAM，才能采?UP管理規范實現省時、合理的軟件開發。
下面我根據自身對項目管理的認識，對原有項目管理中的問題進行總結，并對目前如何實現軟件工程，及對本項目管理規范的實施進行了相應說明。
4.1. 對項目管理的幾點感受
目前我們的軟件開發多為瀑布式開發，項目管理可以說是沒有。所有的管理與軟件設計都是由項目經理一個人來負責，這樣對項目經理的要求較高。項目開發主要依賴于個人能力，開發中又總是依靠程序員高手來支撐，好是要有一批“快槍手”。而高手又因為多種因素不能集中在一個項目中，同時高手的流動會給項目致命的打擊。以上等等只是項目管理中的一部分問題。我對項目管理中之不足歸納為以下幾個方面：
4.1.1.人員素質
項目開發人員的個人素質不同，根據素質進行角色與行為劃分是項目管理中的一個非常重要的環節。
責任心
我在項目管理中曾遇過這樣一種情況，有個項目成員技術不錯，但是在開發的關鍵時期為個人的一點小事而不顧整個項目的進度，而其在項目中擔任了比較重要的職務，在他看來，項目不如自己個人的小事（可做可不做）重要，所以造成項目進度的延誤，我不得不去物色另外一個人來代替他。但后果已成。
還有一種情況，安排了某人工作，工作量在你的估算內，但是到了檢查時，他對你說“我不會做”，“我不知如何做”之類的話，而同時他還在上網或做其他的事，但作為已有計劃的你來說，則是項目進度被打亂的后果。
這種人當然在下一個項目不會被用，但是如何避免這種情況的發生呢？我認為應當將工作量細化到天甚至于小時，遇到這種員工則可立即開除，同時損失的工作時間是可控的。從而減輕了對項目開發的影響。
個人能力
程序員的領悟力各不相同。對不同的人要采用不同的方法來工作。
對個人能力高的人你可以務虛的談工作任務，他在接受任務的同時可以提出這樣那樣的問題，甚至想到你沒有想到的問題，直到把問題搞清楚。這樣的人你可以放心的讓他去做，因為他已經完全理解了你的意圖。
對個人能力一般的人，你講什么他不能理解的很清楚，有的為了面子不懂也不說，但是在做的時候出了問題，在你指著他做的程序大罵的同時，你的項目進度在拖延。對于這種情況，你只能寫出對他工作的要求，寫出你的意圖，明確工作目標。
對個人能力差的人你不能說只是寫個要求行的，那樣的話他寫的程序依然會讓你忍無可忍，怎么辦，把系統中技術要求較低的部分分出來，然后按1，2，3，4步驟寫出來。有人說這樣還不如自己寫完算了，但是這種工作往往是重復量很大。如做界面等。
當然，RUP的實施方針希望是淡化個人力量，而注重流程與大家的協作，同時細化了系統的每一部分。但是的實施不能教條化，在實行中還要根據項目實際情況而變化。
自我約束能力
自我約束能力主要是指對管理者而言的。因為項目成員工作基本是由項目管理者來監督實施的，那管理者呢，可能沒有人來管理，如果管理者的自我約束能力不強，那樣建立什么樣的軟件工程規范都無法實施。
在實施項目管理規范時，由于條件限制，不可能一下完備軟件工程所需的各個機構部門，從而也可能不存在與項目組平行的流程管理機構，質量審批機構等。由于采用逐步實現的方法，所以提高約束力只能采用其他方法。
針對這種情況，可以采用各種提醒方式：電子系統如掌上電腦；人員提醒如部門技術秘書等。
4.1.2. 工作流程
4.1.2.1 工作流程中的多重循環
用戶需求的不斷變化是令項目開發中頭痛的問題了。我們在做項目時傳統的做法是，新需求來了，趕快叫程序員們改，在這里加一塊，那里補幾行代碼，只要實現行。結果是項目做完了，再看自己設計的系統已面目全非。還談什么可重用性，可定義性，產品化，甚至下一個差不多的項目還要花費同樣的時間。
RUP中強調的循環概念 是針對于這種情況提出的，通過項目小組之間各種角色的循環，實現對用戶需求變化的問題解決。如下圖
這樣采用迭代法開發可以實現此問題，是的，但是要有所犧牲，那是時間。時間充足我們自然可以按照標準的RUP思路來進行。而實際上呢，又是我們犧牲不起的。現在國內大多數項目具有這樣一個共同點：用戶要求急。如我們做一個基金的核心業務系統，用戶說開發時間為兩個月。而由于基金是個新行業，無可用之部件，兩個月的時間是不可能進行迭代開發的。同時我們還要在一定程度上避開需求不斷變化。我建議采用的方式如下：
按階段地進行循環
實現階段性的循環，并且存在多個循環的并發。如業務需求循環在一個階段內將生成相應的模型與業務需求文檔，并得到用戶的認可，然后轉入系統需求循環，在系統需求轉入另一個循環時，再繼續業務需求循環，但此時只是記錄用戶需求，而不進行下一個循環。待根據初需求制作的版本生成后，再根據新的業務需求及與用戶協商結果再決定是否開發下一個版本。
采用快速原型法
快速原型法的作用是為了讓用戶在感性上了解系統的概貌，通過與用戶的交流，從而固定了相應的元素（如輸入參數、跳轉順序等），通過快速原型法與用戶進行交流，能很好的理解用戶的意圖與需求，是縮短開發周期的良好途徑。
生成一個版本
用戶需求是不斷變化的，而且任意性很大，如果一個項目根據用戶需求的變化而變化，那么開發周期是無法估量的。一個三個月開發周期的項目做了六個月，還沒有一個象樣的系統出來，用戶則不斷的埋怨開發力度不夠，管理不好等，項目組又認為是用戶隨意性太大，導致了這種后果。結果是雙方互不滿意。
根據這種情況，我認為在業務需求循環到一個階段，生成正式的業務需求文檔與模型，并得到用戶的認可后，則進入下一個循環。以至于生成一個版本。這樣由于存在這樣的版本，用戶則不能將項目的延遲歸于項目組。而項目組也存在一個完整的版本管理體系。
