需求分析
需求分析是開發人員對系統需要做什么和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了用戶的需求。從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的質量。同時，想在某個時間點上宣布需求分析已經完畢，不再需要進行進一步的需求分析，這也是不現實的。經驗告訴我們，往往在測試過程中會發現，用戶真正想要的并非您腦海中的設想，另一方面用戶往往知道自己肯定不需要什么，而無法明確告知他們需要的是什么。面對這些事實，我們無法期望改變用戶；比如提高用戶同分析人員的"溝通"能力，讓他們說出的話更能被分析人員理解。的做法是采用一定的方式方法，誘導用戶盡可能早地將需求表達出來，表達得完整。
在某個項目中我們的做法有兩個方面：一是請領域專家參與到系統開發的早期階段；二是開發系統原形，原形包括功能性的原形和用戶界面性的原形，也可以是二者混合的原形，用這些原形確認用戶的需求。讓領域專家參與開發的早期階段，是保證分析人員有充足的時間和領域專家進行充分的交流和確認。在這個階段，原形可能在提交到用戶之前，首先被領域專家確認，這樣保證了原形被認可的程度和認可過程耗費的時間盡可能的短，從而在提高效率的同時保證了質量。
在開發方內部還有三項保證措施： 系統分析委員會保證系統分析集思廣益； 質量監督組對分析工作的監督； 技術支持人員參與需求調研。
分析委員會的意義在于任何分析人員在提交其所分析部分的分析說明書前，必須通過委員會的共同審議，委員會的成員根據各自的分析經驗和自身所分析的部分對他人的分析報告提出質疑。如此審議過后保證了各部分間相互關聯的部分被明確定義，避免了由于"疏忽"造成系統在后期進行整合時出現較嚴重的系統鴻溝或系統重疊。
質量監督組在項目的任何階段都要提出監督計劃。按照監督計劃分配相應的資源來保證某階段的開發質量。分析階段的監督計劃會在分析任務之前被項目經理，項目負責人、系統分析員以及技術支持所了解。為保證分析工作高質量進行，同時分析工作又不被過分打擾，質量監督組則主要針對《系統分析報告》進行復審，只在認為確實有必要的情況下才召開質量復審會議。質量復審會議的主要參與者是項目經理、項目負責人、分析人員和質量監督組組長。會議的主要議題是提出質量質疑，給出改進建議即可。具體是否存在質量問題，是否需要改進，不在會議中進行討論。以此保證了會議參與的人數較少，會議的時間盡可能的短。
通過技術支持的職責可以發現，技術支持參與分析調研有利于對分析工作的監督，在獲得用戶需求的口頭表達之后，能幫助技術支持更好地扮演開發階段"用戶"的角色。技術支持具有相當的計算機技術背景，在接下來的開發過程中能較好的起到監督的作用，也為將來維護和為用戶提供更好的服務奠定基礎。
系統設計
優良的體系結構應當具備可擴展性和可配置性，這兩方面因素的實現是通過Windows DNA的應用完成的，正如建議書中所述，在此不再贅述。
實現
實現也是代碼的生產過程。從設計的結構圖中可以看出，生產的類別有類的生產，組件的生產，構件的生產，應用系統的整合，以及各種測試用例的生產。為了能夠提高生產的質量，我們將生產的程序人員按職能分成兩組，測試用例的生產和測試用例生產，也是說如果某個程序員生產了某個組件，則其測試用例不能再由該程序員來生產，但他可以生產其他組件的測試用例。這樣交叉生產更容易發現組件的存在的問題。測試人員按照測試用例來測試組件的各項指標提出測試報告。
隨生產的不斷深入，組件的生產日趨減少，構件的生產的量開始逐步增加，生產構件的過程又是對組件的考驗過程。因此描述組件實現的文檔是非常重要的，它將有可能成為阻礙進一步生產的瓶頸。文檔組在生產過程中的重要工作是對各類部件的文檔進行豐富和規范，同時進行版本的控制。文檔的完備與否，在開發的后期，對項目進度有至關重要的影響。文檔是共享前期開發成果的手段。根據上一節描述的應用系統體系結構來看，整個開發環節絲絲相扣，每一步都受到上一步的制約。
為了控制系統開發過程中的往復，不至于產生重大過失和往復的泛濫。文檔組和質量監督組協同完成軟件開發的配置管理。
軟件配置管理的目的在于控制軟件開發過程中的"變化"，這種變化可能是外部引起的，如需求的變化。也可能是來自于內部的變化，如早期設計的某個部件不夠完備，需要修改等。為了控制這些變化，把變化引起的波動盡可能的控制在有限的范圍內，配置管理的管理模型如下圖：
配置項是指需要進行控制的任何文檔單元，它可能是需求說明報告，也可能是需求說明報告的某個點。在本項目中需要控制的內部配置項包括需求報告，設計報告，組件代碼，組件接口文檔，構件及構件相關文檔；外部配置項包括項目計劃書，使用手冊，系統安裝說明和系統配置說明等。
上圖完整描述了軟件配置管理的流程。
從圖中可以看出在文檔沒有被提交出開發組以前，文檔可以在開發組內部"任意"地被修改，但一旦文檔被提交，則相關的部門會被調動，來維護文檔的質量。因此為了保證工作效率，開發組提交文檔之前必須慎重，以免引起不必要的工作量的增加。從另一角度來看，開發部受到嚴密的監督，從而保證了開發的各個環節對于開發的全過程保持透明，避免了因為個人的原因造成整個開發的癱瘓或受阻。項目經理通過質監報告可以了項目開發的進度和質量情況，為調整開發計劃提供有利的依據。
顯然開發部的內部流程在配置管理的過程中受到的監管是非常有限的。配置管理所能起的作用完全是建立在文檔之上。當項目進度非常緊張時，開發部可能書寫文檔的時間會非常少，在此情況之下質量監督組和文檔組肩負將開發部提供的文檔進行豐富和完善的工作，從而減少開發部書寫文檔的時間，當然這是增加質量監督組與開發部的口頭交流為代價的。
