一、需求分析

    需求分析是理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發計劃的一個復雜過程。它是軟件開發中的第一步，因為如果沒有完全分析清楚用戶的需求，盲目的投入大量的人力、物力、財力和時間，開發出的軟件卻滿足不了用戶的需求,被迫要求重新開發，或終止合作都是讓人痛心疾首的事，因此在軟件開發過程中有必要做足充分的需求分析。

二、項目設計    

    項目設計是由軟件開發單位對軟件項目開發階段中的工作進行自我管理、質量控制、進度控制、投資控制，對進度的實施在技術上和經濟上進行全面而詳盡地安排，形成設計圖紙和說明書，并在實施的過程中進行監督和驗收。

    這也是軟件開發過程中必須注意的事項，做任何事都要有計劃，軟件開發也不例外。因此先將項目的整體規劃出來，然后按照需求合理的安排人力物力，使之按照計劃行事，才能有條不絮的將項目進行下去。

三、有效控制需求變化    

    開發人員最怕的是什么呢？設計變化，還是需求變化？個人覺得需求變化是最最致命的。當你的一個項目的大部分功能都定下來后，而且已經開發了若干個工作日，突然接到甲方公司提出，某個功能要改變，原先的需求分析要重新改，如果這個修改是涉及的數據庫的表結構更改的話，那是致命的。所以在軟件開發過程中要有效的應對這種需求變化，在開發合同中進行必要的說明。    

四、代碼編寫    

    當需求確定定下來之后，就可以進行實質性的編碼了，所以以下的一些規范是開發者必須要遵守的：    

    1、源程序文件結構：每個程序文件應由標題、內容和附加說明三部分組成。   （1）標題：文件最前面的注釋說明，其內容主要包括：程序名，作者，版權信息，簡要說明 等，必要時應有更詳盡的說明（將以此部分以空行隔開單獨注釋）。   （2）內容控件注冊等函數應放在內容部分的最后，類 的定義按 private 、 protected 、 pubilic 、 __pubished 的順序，并盡量保持每一部分只有一個，各部分中按數據、函數、屬性、事件的順序。    一、附加說明：文件末尾的補充說明，如參考資料等，若內容不多也可放在標題部分的最后。    

    2、界面設計風格的一致性：由于采用可視化編程，所有的界面均與Win32方式類似，相應采用的控件等也大都為Windows操作系統下的標準控件，而且參考了其他一些市面上相關的企業內部管理的應用軟件。    

基于簡單易操作的原則，貼近用戶考慮，用戶界面采用Windows風格的標準界面，操作方式亦同Windows風格，這樣在實施過程，可以降低對客戶的培訓，也可以使用戶容易上手，簡單易學。  

    3、編輯風格：    

   （1）縮進：縮進以 Tab 為單位，一個 Tab 為四個空格大小。全局數據、函數 原型、標題、附加說明、函數說明、標號等均頂格書寫。    

   （2）空格：數據和函數在其類型，修飾（如 __fastcall 等）名稱之間適當空格并據情況對 齊。關鍵字原則上空一格，不論是否有括號，對語句行后加的注釋應用適當空格與語句隔開并盡可能對齊。    

   （3）對齊：原則上關系密切的行應對齊，對齊包括類型、修飾、名稱、參數等各部分對齊。另每一行的長度不應超過屏幕太多，必要時適當換行。    

   （4）空行：程序文件結構各部分之間空兩行，若不必要也可只空一行，各函數實現之間一般空兩行。    

   （5）注釋：對注釋有以下三點要求：  A、必須是有意義；  B、必須正確的描述了程序；   C、必須是最新的。    

    4、命名規范：堅持采用匈牙利變量命名慣例，所有標識符一律用英文或英文縮寫，杜絕采用拼音，標識符中每個單詞首字母大寫，縮寫詞匯一般全部大寫，只在必要時加“_”間隔詞匯。 

五、測試上線   

    軟件開發接近尾聲的一個重要事項就是測試，測試是保證代碼能正常運行的前提，它需要將影響軟件正常運行的因素逐一排除，當一切都測試完成后就可以上線交付使用了。