分析 

軟件需求分析就是回答做什么的問題。它是一個對用戶的需求進(jìn)行去粗取精、去偽存真、正確理解，然后把它用軟件工程開發(fā)語言（形式功能規(guī)約，即需求規(guī)格說明書）表達(dá)出來的過程。本階段的基本任務(wù)是和用戶一起確定要解決的問題，建立軟件的邏輯模型，編寫需求規(guī)格說明書文檔并最終得到用戶的認(rèn)可。需求分析的主要方法有結(jié)構(gòu)化分析方法、數(shù)據(jù)流程圖和數(shù)據(jù)字典等方法。本階段的工作是根據(jù)需求說明書的要求 ，設(shè)計建立相應(yīng)的軟件系統(tǒng)的體系結(jié)構(gòu)，并將整個系統(tǒng)分解成若干個子系統(tǒng)或模塊，定義子系統(tǒng)或模塊間的接口關(guān)系，對各子系統(tǒng)進(jìn)行具體設(shè)計定義，編寫軟件概要設(shè)計和詳細(xì)設(shè)計說明書，數(shù)據(jù)庫或數(shù)據(jù)結(jié)構(gòu)設(shè)計說明書，組裝測試計劃 。

設(shè)計 

軟件設(shè)計可以分為概要設(shè)計和詳細(xì)設(shè)計兩個階段。實際上軟件設(shè)計的主要任務(wù)就是將軟件分解成模塊是指能實現(xiàn)某個功能的數(shù)據(jù)和程序說明、可執(zhí)行程序的程序單元?？梢允且粋€函數(shù)、過程、子程序、一段帶有程序說明的獨立的程序和數(shù)據(jù)，也可以是可組合、可分解和可更換的功能單元。模塊，然后進(jìn)行模塊設(shè)計。概要設(shè)計就是結(jié)構(gòu)設(shè)計，其主要目標(biāo)就是給出軟件的模塊結(jié)構(gòu)，用軟件結(jié)構(gòu)圖表示。詳細(xì)設(shè)計的首要任務(wù)就是設(shè)計模塊的程序流程、算法和數(shù)據(jù)結(jié)構(gòu)，次要任務(wù)就是設(shè)計數(shù)據(jù)庫，常用方法還是結(jié)構(gòu)化程序設(shè)計方法。 

編碼 

軟件編碼是指把軟件設(shè)計轉(zhuǎn)換成計算機可以接受的程序，即寫成以某一程序設(shè)計語言表示的"源程序清單"。充分了解軟件開發(fā)語言、工具的特性和編程風(fēng)格，有助于開發(fā)工具的選擇以及保證軟件產(chǎn)品的開發(fā)質(zhì)量。 

當(dāng)前軟件開發(fā)中除在專用場合，已經(jīng)很少使用二十世紀(jì)80年代的高級語言了，取而代之的是面向?qū)ο蟮拈_發(fā)語言。而且面向?qū)ο蟮拈_發(fā)語言和開發(fā)環(huán)境大都合為一體，大大提高了開發(fā)的速度。 

測試 

軟件測試的目的是以較小的代價發(fā)現(xiàn)盡可能多的錯誤。要實現(xiàn)這個目標(biāo)的關(guān)鍵在于設(shè)計一套出色的測試用例（測試數(shù)據(jù)和預(yù)期的輸出結(jié)果組成了測試用例）。如何才能設(shè)計出一套出色的測試用例，關(guān)鍵在于理解測試方法。不同的測試方法有不同的測試用例設(shè)計方法。兩種常用的測試方法是白盒法測試對象是源程序，依據(jù)的是程序內(nèi)部的的邏輯結(jié)構(gòu)來發(fā)現(xiàn)軟件的編程錯誤、結(jié)構(gòu)錯誤和數(shù)據(jù)錯誤。結(jié)構(gòu)錯誤包括邏輯、數(shù)據(jù)流、初始化等錯誤。用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果。白盒法和黑盒法依據(jù)的是軟件的功能或軟件行為描述，發(fā)現(xiàn)軟件的接口、功能和結(jié)構(gòu)錯誤。其中接口錯誤包括內(nèi)部/外部接口、資源管理、集成化以及系統(tǒng)錯誤。黑盒法用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。黑盒法。 

維護(hù) 

維護(hù)是指在已完成對軟件的研制（分析、設(shè)計、編碼和測試）工作并交付使用以后，對軟件產(chǎn)品所進(jìn)行的一些軟件工程的活動。即根據(jù)軟件運行的情況，對軟件進(jìn)行適當(dāng)修改，以適應(yīng)新的要求，以及糾正運行中發(fā)現(xiàn)的錯誤。編寫軟件問題報告、軟件修改報告 。 

一個中等規(guī)模的軟件，如果研制階段需要一年至二年的時間，在它投入使用以后，其運行或工作時間可能持續(xù)五年至十年。那么它的維護(hù)階段也是運行的這五年至十年期間。在這段時間，人們幾乎需要著手解決研制階段所遇到的各種問題，同時還要解決某些維護(hù)工作本身特有的問題。做好軟件維護(hù)工作，不僅能排除障礙，使軟件能正常工作，而且還可以使它擴展功能，提高性能，為用戶帶來明顯的經(jīng)濟效益。然而遺憾的是，對軟件維護(hù)工作的重視往往遠(yuǎn)不如對軟件研制工作的重視。而事實上，和軟件研制工作相比，軟件維護(hù)的工作量和成本都要大得多。

在實際開發(fā)過程中，軟件開發(fā)并不是從第一步進(jìn)行到*一步，而是在任何階段，在進(jìn)入下一階段前一般都有一步或幾步的回溯。在測試過程中的問題可能要求修改設(shè)計，用戶可能會提出一些需要來修改需求說明書等。

1、項目設(shè)計 

項目設(shè)計的主導(dǎo)思想，我覺得可以理解為兩種，一種是完全設(shè)計，一個是簡單設(shè)計。 

完全設(shè)計是指在具體編寫代碼之前對軟件的各種方面都調(diào)查好，做好詳細(xì)的需求分析、編寫好全部的開發(fā)文檔，設(shè)計出程序全部流程后再開始寫代碼。 換句話說，就是全部的計劃好了，能看到最終的樣子，再開戰(zhàn)。這好像也是很多“軟件工程”書里要求的那樣。開始的時候，我覺得這種方法不錯也。什么都計劃好了，照著做就是了。不過這里有個明顯的問題，就是誰來做這個完美的計劃？估計只有及其BT的人了，但是大部分人的想要完全設(shè)計，并且沒有錯誤，或者已經(jīng)有幾種后備的容錯方案，并能準(zhǔn)確無誤的推行。以達(dá)到最終目標(biāo)。這樣的境界，沒有很多年的工作經(jīng)歷是不可能的。我也沒有這樣的本事，所以我也就放棄了這種想法。 

簡單設(shè)計：簡單設(shè)計一種概念，一種可以接受的簡單的設(shè)計，最起碼數(shù)據(jù)庫已經(jīng)定下來，基本流程已經(jīng)確定的方案，來作為程序設(shè)計的開始，并隨時根據(jù)實際情況的進(jìn)展來修正具體的功能設(shè)計，但這種功能修改不能是修改數(shù)據(jù)庫結(jié)構(gòu)。也就是說數(shù)據(jù)庫結(jié)構(gòu)是在編程之前經(jīng)過反復(fù)論證的。這種方法減少了前期設(shè)計的時間，把代碼編寫工作和部分設(shè)計工作放在了一起，實際縮短了項目開發(fā)的時間。如果說完全設(shè)計方法要求有很厲害的前期設(shè)計人員，那么簡單設(shè)計要求有很有設(shè)計頭腦的編程人員。編程人員不僅僅是K代碼的人而且要負(fù)責(zé)程序架構(gòu)的設(shè)計。所以對程序員的要求就很高了。 簡單設(shè)計的成功的一個基點是編程人員設(shè)計的邏輯結(jié)構(gòu)簡單并能根據(jù)需要來調(diào)整其邏輯結(jié)構(gòu)，就是代碼結(jié)構(gòu)靈活，簡單設(shè)計帶來的另外一個變化就是會議會比較多，編程人員之間的交流就變的很重要?，F(xiàn)在一般的中小型軟件公司基本上都是采用簡單設(shè)計的，除非那些很大型的軟件公司。 

總結(jié)，簡單設(shè)計考驗的是開發(fā)人員的能力。完全設(shè)計考驗的是前期設(shè)計人員和整個項目組完整能力。(各種文檔的編寫，開發(fā)人員一定會要寫一部分的。)

2、設(shè)計變化和需求變化 

開發(fā)人員最怕的是什么呢？設(shè)計變化，還是需求變化？我覺得需求變化是最最致命的。當(dāng)你的一個項目數(shù)據(jù)庫都定下來后，而且已經(jīng)開發(fā)了若干個工作日，突然接到甲方公司提出，某個功能要改變，原先的需求分析要重新改，如果這個修改是涉及的數(shù)據(jù)庫的表結(jié)構(gòu)更改的話，那真是最致命的。這就意味著項目的某些部分得重新推倒重來，如果這個部分跟已完成的多個部分有牽連的話，那就后果更可怕了。所以當(dāng)碰到這種情況發(fā)生，作為項目經(jīng)理的你就應(yīng)該考慮先查責(zé)任人，究竟是自己的需求分析做的不夠好，還是客戶在認(rèn)同了需求分析后做出的修改，如果是后者的話，你完全可以要求客戶對他的這個修改負(fù)責(zé)任！那么，呵呵，客戶先生，對不起了，本次新增加的需求將歸入另外一個版本。如果是改變前面某個需求的定義，那么說不定就要推倒重來了，不過這個時候到不用太在意，畢竟錯的是客戶。(項目正式開始前沒有沒有說清楚其需求)。所以，各位看客，在需求分析做好后，在開工之前一定要叫客戶認(rèn)可簽字，并且在合同上要注明，當(dāng)由客戶原因引起的需求改變而造成開發(fā)成本的增加，客戶要為此買單地。 

如果在需求不變的情況之下，設(shè)計發(fā)生了變化，這個僅僅是我們內(nèi)部之間的矛盾，商量一下就能解決。在簡單設(shè)計中，因為前期的設(shè)計是不完整的，那么當(dāng)進(jìn)入任何一個新的模塊進(jìn)行開發(fā)時，都有可能引起設(shè)計的變化。開發(fā)人員的水平的高低就基本上決定了軟件的好壞。

3、代碼編寫

 

當(dāng)需求定下來數(shù)據(jù)庫也定下來后， 其實我們就可以進(jìn)行實質(zhì)性的編碼了，按照我的看法，一個人單獨編程*，能隨時偷懶。(上網(wǎng)，和MM聊聊)，但是現(xiàn)在的軟件項目越來越大，工期也越來越緊，事實上我們一個小組里面，一般有3-5程序員，所以我們要強調(diào)團隊合作性。那么你寫的代碼使得別人要能夠看懂，我們必須在實際的編寫代碼過程中要有詳細(xì)的編碼規(guī)范，編碼規(guī)范在很多書籍里面都提到過。但最起碼以下的一些規(guī)范是我們必須要遵守的： 

 

一）源程序文件結(jié)構(gòu)： 

每個程序文件應(yīng)由標(biāo)題、內(nèi)容和附加說明三部分組成。 

（1）標(biāo)題：文件最前面的注釋說明，其內(nèi)容主要包括：程序名，作者，版權(quán)信息，簡要說明 等，必要時應(yīng)有更詳盡的說明（將以此部分以空行隔開單獨注釋）。 

（2）內(nèi)容控件注冊等函數(shù)應(yīng)放在內(nèi)容部分的*，類的定義按 private 、 protected 、 pubilic 、 __pubished 的順序，并盡量保持每一部分只有一個，各部分中按數(shù)據(jù)、函數(shù)、屬性、事件的順序。 

（3）附加說明：文件末尾的補充說明，如參考資料等，若內(nèi)容不多也可放在標(biāo)題部分的*。 

 

二）界面設(shè)計風(fēng)格的一致性： 

由于采用可視化編程，所有的界面均與Win32方式類似，相應(yīng)采用的控件等也大都為Windows操作系統(tǒng)下的標(biāo)準(zhǔn)控件，而且參考了其他一些市面上相關(guān)的企業(yè)內(nèi)部管理的應(yīng)用軟件。 

基于簡單易操作的原則，貼近用戶考慮，用戶界面采用Windows風(fēng)格的標(biāo)準(zhǔn)界面，操作方式亦同Windows風(fēng)格，這樣在實施過程，可以降低對客戶的培訓(xùn)，也可以使用戶容易上手，簡單易學(xué)。 

 

三）編輯風(fēng)格： 

（1）縮進(jìn)：縮進(jìn)以 Tab 為單位，一個 Tab 為四個空格大小。全局?jǐn)?shù)據(jù)、函數(shù) 原型、標(biāo)題、附加說明、函數(shù)說明、標(biāo)號等均頂格書寫。 

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

（3）對齊：原則上關(guān)系密切的行應(yīng)對齊，對齊包括類型、修飾、名稱、參數(shù)等各部分對齊。 

另每一行的長度不應(yīng)超過屏幕太多，必要時適當(dāng)換行。 

（4）空行：程序文件結(jié)構(gòu)各部分之間空兩行，若不必要也可只空一行，各函數(shù)實現(xiàn)之間一般空兩行。 

（5）注釋：對注釋有以下三點要求： 

A、必須是有意義； 

B、必須正確的描述了程序； 

C、必須是*的。 

注釋必不可少，但也不應(yīng)過多，以下是四種必要的注釋： 

標(biāo)題、附加說明； 

函數(shù)說明：對幾乎每個函數(shù)都應(yīng)有適當(dāng)?shù)恼f明，通常加在函數(shù)實現(xiàn)之前，在沒有函數(shù)實現(xiàn)部分的情況下則加在函數(shù)原型前，其內(nèi)容主要是函數(shù)的功能、目的、算法等說明，參數(shù)說明、返回 值說明等，必要時還要有一些如特別的軟硬件要求等說明； 

在代碼不明晰或不可移植處應(yīng)有少量說明； 

及少量的其它注釋。 

 

四）命名規(guī)范： 

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

4、BUG修補 

程序出現(xiàn)了BUG誰來修補呢，嘿嘿嘿…… 

*的辦法是誰編寫誰修補，誰改壞誰修補。一個人改壞的代碼一人去修。兩個人一起改壞的代碼兩人一起修。

5、開發(fā)人員的測試 

開發(fā)人員的測試是保證代碼能正常運行，在開發(fā)時候發(fā)現(xiàn)的錯誤往往比較容易修正。(另外一個好處就是沒有人來罵你。因為只有你自己知道)。但是一旦軟件到了測試小組那里出了問題，那么就多了很多時間來修正BUG，如果到了客戶哪里才發(fā)現(xiàn)的BUG，那么時間就更長了，開發(fā)人員本身受到的壓力也是到了最大話了?？蛻?>公司->測試小組->開發(fā)人員。 這個完全是倒金字塔型的，承受能力差的一環(huán)很容易出事情的。 

另外開發(fā)人員的測試除了保證代碼能正常運行以外，還有一個很重要的方面就是要保證上次能正常運行的代碼，這次還是能正常運行。如果做不到這點，那么BUG就不斷的會出現(xiàn)，很多BUG也會反復(fù)出現(xiàn)。于是軟件看上去就有修補不完的BUG了。如果出現(xiàn)這種情況，那么開發(fā)人員有必要再教育。一般公司教育的方式有四種。第一種，扣工資，第二種，加班，反復(fù)加班+精神攻擊。 第三種，開除。第四種，調(diào)動人員來幫助那個出了麻煩的家伙。 但愿看這個文章的人不要受到前面三種教育。