隨著人才流動的加快和研發周期的縮短，我們個人需要快速高效的完成自己的設計，維護和升級，公司需要人走不影響項目進度、新員工很快就能接手。這就需要：一個系統設計完成以后，它不應該僅僅是一些源代碼，還應該包括各種各樣的開發文檔。（這對以后自己對系統的維護和升級都有很好的參考作用。而且能最大情況的避免一種情況：你改了一個BUG，卻發現又出現了很多個BUG。）一個系統開發完成，它究竟應該包含那些文檔，這些文檔一般是怎么完成的，應該包含哪些內容？這就是系統開發的規范化問題。系統開發的規范化不僅有利于自己，也有利于公司，更有利于新手。規范化的設計讓工程師工作更高效，這已經是不用爭論的事實。現在在大型軟件工程開發方面，這已經做得相當好。但在單片機和嵌入式系統的開發方面，規范化的工作卻有待我們共同探討。一個不容否認的事實是：國內的大部分小系統開發工程師從來不寫文檔，一開始就是以功能完成為中心進行代碼設計。

在香港的一些公司也是這樣一種設計模式。在國內，一些公司的研發管理人員也有一種誤導——快寫代碼，快讓我看見功能，不要你做其他的，完成功能就好。這些都把我們的設計導入一種誤區：大部分時間都在寫代碼，改代碼。

在此提出系統開發的規范化問題，也是我個人的一點想法而已。僅供參考。不過，一切還得從實際出發，倒沒有必要硬要把設計從寫某些文檔開始，太教條了不好。如果你感覺寫某些文檔是浪費時間，那就別寫吧。

在這里，我給出一個小系統大致包括的文檔，僅作參考。

PRODUCT SPECIFICATION 一般是市場部或者是客戶提供的
PRODUCT SPECIFICATION ——》 PROJECT LEADER
PROJECT LEADER 給工程師分配方案
SOFTWARE  SPECIFICATION  ——》 HARDWARE ENGINEERS
HARDWARE  SPECIFICATION ——》 SOFTWARE ENGINEERS
MECHANICAL SPECIFICATION ——》 MECHANICAL ENGINEER

一、    硬件工程師的芯片選擇，原理圖的設計

硬件工程師根據HARDWARE SPECIFICATION 來選擇芯片（也可能是PROJECT LEADER 早已為你定了），再根據芯片說明來設計各功能模塊電路。出一份文檔
HARDWARE IMPLEMENTATION 
并進行SCHEMATIC DESIGN 
再把這些資料提供給SOFTWARE ENGINEER。
PCB LAYER 當然不需要文檔了。
但有跟隨的HARDWARE UPDATE REPORT
包括調試修改和最后的軟硬聯調，所做的任何工作都要出相應的說明。
（呵，呵，你自己保存一表格天天填吧，改動地方，修改原因，就兩項，不難寫的）

軟件工程師得到芯片和電路資料，開始根據SOFTWARE SPECIFICATION 進行設計

首先我們應該出一文檔：

SOFTWARE IMPLEMENTATION 這里大致包括軟件采用的芯片，軟件的功能模塊及使用系統端口功能情況，仿真系統，原始數據資料，自己用其他語言寫的數據處理工具。

在此文檔完成后，我們進入了詳細設計階段：

MODULE DESIGN 開始寫各模塊的實現，包括各模塊所要實現的功能，用到的系統資源（包括變量的定義，常量的定義），與其他模塊的聯系（*對系統的維護和升級很重要的）和時間間隔圖（有固定時間點用固定時間點，沒有固定時間點，就用時間間隔 ，用來設計主循環的）。這里表現的其實是你的思路，如果你思路清晰，做起事情來自然是事半功倍了。

MAINLOOP DESIGN：
主要是根據時間間隔圖和各模塊的重要性及響應優先級進行主監控程序的設計，確保各功能能順利完成。

MIAN CHART FLOW
畫出程序流程圖

SOURCE CODE DESIGN。
這一部分才是代碼的實現，要是你前面寫得很詳細了，這里你的思路很清晰，按照MAINLOOP DESIGN直接做就是了。當然，我們需要按照我們自己的〈編程語言規范〉來設計源程序。這是軟件工程師的基本，我就不提了。

最后是軟硬聯調，需要兩個人配合的，基本不出什么文檔，但如果你作了什么修改，請記錄在案，最后要更新你前面的設計文檔。

最后是出FIRST SAMPLE ，MECHANICAL ENGINEER 會根據要求修改自己的設計。并出IMPLEMENTATION 和 UPDATE ME REPORT。

整個系統開發流程的規范化還應該包括項目的會審，軟硬協調，成本的控制，貨源的規劃，測試規劃，等等，由于我這里不是介紹一個現代研發部的研發流程，只想對系統軟件規范化說得詳細一點（這些可能是我們目前規范化面臨的最大的問題吧），其他我都省掉了。

    這里寫的不詳細，還沒貼出實際的文檔式樣，僅為拋磚引玉而已，希望有經驗的各位同行修改補充。如有不明之處或者需要一些資料的，請給我留言。


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

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

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

其實人才才是最關鍵的。現在軟件業最缺的人才之一就是產品經理，他們是軟件工程管理的主角。產品經理必須具備以下素質：具有長期的軟件開發經驗——般來講，要在8年以上；了解用戶的需求；對產品熟、對市場熟——他可以不了解一個產品的底層技術，但必須了解其功能，能把握其發展方向；具有協調能力。總之，產品經理并不一定非常聰明，并不需要在某一方面特別突出，但要八面玲瓏。這樣的人才太難找了。東方通的產品經理都是自己培養的。 

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

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


軟件商業化的必要手段

談文明（北京瑞星科技股份有限公司研發部經理） 

中國軟件產業發展時間不長，雖然已有部分技術達到國際水平，但由于商業環境還不夠完善，在軟件技術的商業化與軟件工程管理等方面，與國際同行相比，還存在差距。 

只有率先將技術先進的產品推向市場的公司才會贏得利潤。在瑞星，技術商品化已被當作一種制度，它有助于提高整個企業的素質。 

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

在軟件商業化的過程之中，建立規范化的易于操作的軟件開發行為規范是首先要做的工作。針對殺毒軟件的特點，瑞星專門設計了瀑布模型結合增量模型的開發方式，即將項目分階段來實現。首先實現市場最需求的核心功能，然后在此基礎上繼續開發，每個單獨的階段都采用瀑布模型的開發方式。 

具體地說，一個基本的軟件開發流程包括需求階段、系統設計階段、詳細設計階段、編碼階段、單元測試階段、集成測試階段、系統測試階段、軟件發布軟件維護階段。其中決定軟件開發成功與否的關鍵階段是：軟件需求管理、軟件計劃管理、軟件質量管理和軟件配置管理。 

為了在用戶和處理用戶需求的軟件項目組之間達成共識（用戶由最終用戶、高層領導、銷售人員和市場調研人員組成），“軟件需求規格說明書”是必不可少的。經過正式的評審和確認，其將成為后續工作的基礎。 

軟件項目的實施過程是根據軟件項目的資源、約束條件和執行能力確定的，因此需要制定合理的軟件工程管理計劃，這是項目經理的職責之一。項目經理應定期檢查“項目開發計劃書”，按照當前項目開發的實際情況，對其進行調整。 

為了保證每一個軟件產品都合乎需求，需要設立一個負責項目監督和協調的SQA。其會對軟件產品是否符合定義好的軟件過程中的相應部分進行審查、復審和測試。公司高層主管應該定期參與、評審SQA的活動。 

軟件配置管理是指在整個工程期間對項目的所有軟件配置項進行規范化管理。如采用版本控制軟件對軟件配置項版本進行版本控制，采用基線管理方法對變化進行控制，即在遵循軟件工程標準的基礎上對整個軟件進行控制和管理，維護其完整性、一致性和可跟蹤性。 

瑞星努力營造的是一個廣泛的網絡，研發、制造、銷售、分銷和服務，連續進行。圍繞著產品、市場和開發階段而不是單純的技術來組織各項工作。為了這個目的，標準操作是必不可少的。 

附錄：開思公司《產品部開發規范》　（摘要）

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

1　　目　錄 

1　目的 

2　開發規范概述 

2．1　應用項目管理管理開發過程 

2．2　標準的階段性開發工作 

2．2．1　總體規劃 

2．2．2　項目立項 

2．2．3　需求分析 

2．2．4　系統分析 

2．2．5　系統設計 

2．2．6　編碼實現 

2．2．7　項目測試 

2．2．8　文檔制作 

2．2．9　項目驗收 

2．2．10　項目版本化發布 

2．3　項目組織 

3　開發工作規范 

3．1　總體規劃階段 

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　需求分析驗收