a、需求分析
需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程。從系統(tǒng)分析的經(jīng)驗來看，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識是困難的。只有不斷地和客戶領(lǐng)域?qū)＜疫M行交
流確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。
解決系統(tǒng)分析錯誤的方法我們公司通常采用邀請用戶參與進行需求評定，然后對其用戶的意見由質(zhì)保成員跟蹤檢測是否納入需求規(guī)格說明書，同時與用戶簽字確認形成需求基線，交由配置管理員放入配置管理庫。
雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求變更請求。對于開發(fā)過程存在的需求變動，我們要求用戶填寫變更申請單發(fā)送給項目配置管理員，在通過配置配置員轉(zhuǎn)交質(zhì)保小組，負責組織專家小組和項目組成員一起討論實施變更的可行性及實施后所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更（包括需求規(guī)格說明書、詳細設計文、安裝手冊、操作手冊等）。但是對于無法實現(xiàn)或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進行協(xié)調(diào)會議，討論變更取舍問題或是項目進度變更問題。
決定變更之后，由項目經(jīng)理組織實施變更，測試人員檢測變更結(jié)果，而質(zhì)保小組成員監(jiān)督變更實施過程并協(xié)助配置管理員對變更后的成果物進行版本控制。變更實施完后，上線前還需要指定人員協(xié)助用戶一同測試并由用戶簽字后同意方可上線。
b、系統(tǒng)設計
優(yōu)良的體系結(jié)構(gòu)應當具備可擴展性和可配置性，而好的體系結(jié)構(gòu)則需要好的設計方法，自然設計選型成為了系統(tǒng)設計首要的工作，究竟是采用哪種設計方法好呢？
對于設計選型不能一概而論，需要針對項目的結(jié)構(gòu)、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質(zhì)，如果其中大部分都沒有從事過面向?qū)ο蟮脑O計且項目進對緊迫，這樣沒有多余的時間來培訓小組成員來掌握面向?qū)ο蟮脑O計方法，盡管眾所周知面向?qū)ο笤O計方法的優(yōu)勢，我們還是不如采用面向過程的方式（除用戶指定開發(fā)設計方式外）可以減少項目承擔的技術(shù)風險。
我們公司有過一個項目，用戶指定需要采用面向?qū)ο蠓治?、設計和開發(fā)，且開發(fā)周期短，在無賴的情況下，項目小組只能選用面向?qū)ο蟮能浖_發(fā)過程，由于項目小組很少從事過面向?qū)ο蟮拈_發(fā)，經(jīng)驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。
針對此次開發(fā)，我們分析其原因，發(fā)現(xiàn)小組成員在開發(fā)過程中對于新技術(shù)互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關(guān)人員發(fā)布，再由配置管理員對其發(fā)布的文檔進行整理、規(guī)類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在這次開發(fā)中我們公司從管理人員、設計人員到開發(fā)人員都汲取了很多教訓，同時經(jīng)過此次項目的開發(fā)，小組成員也積累了豐富的面向?qū)ο蟮拈_發(fā)經(jīng)驗。
除設計選型，還有一個容易被忽視的問題，就是公共類開發(fā)。公共類開發(fā)可以減少工作中的重復工作，降低開發(fā)成本。這要求我們再設計階段通過對用戶需求的仔細研究，盡可能的識別出公共類，并進行定義指定專人負責設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文檔，由質(zhì)保小組組織技術(shù)專家、項目組設計人員、開發(fā)人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性