剖析 
軟件需求剖析便是答復(fù)做什么的問題。它是一個(gè)對(duì)用戶的需求進(jìn)行去粗取精、去偽存真、正確了解，然后把它用軟件工程開發(fā)言語(yǔ)（形式功用規(guī)約，即需求標(biāo)準(zhǔn)闡明書）表達(dá)出來的進(jìn)程。本階段的根本任務(wù)是和用戶一同確定要處理的問題，樹立軟件的邏輯模型，編寫需求標(biāo)準(zhǔn)闡明書文檔并終究得到用戶的認(rèn)可。需求剖析的主要方法有結(jié)構(gòu)化剖析方法、數(shù)據(jù)流程圖和數(shù)據(jù)字典等方法。本階段的作業(yè)是依據(jù)需求闡明書的要求 ，規(guī)劃樹立相應(yīng)的軟件體系的體系結(jié)構(gòu)，并將整個(gè)體系分解成若干個(gè)子體系或模塊，界說子體系或模塊間的接口關(guān)系，對(duì)各子體系進(jìn)行具體規(guī)劃界說，編寫軟件概要規(guī)劃和具體規(guī)劃闡明書，數(shù)據(jù)庫(kù)或數(shù)據(jù)結(jié)構(gòu)規(guī)劃闡明書，組裝測(cè)驗(yàn)計(jì)劃 。
規(guī)劃 
軟件規(guī)劃能夠分為概要規(guī)劃和具體規(guī)劃兩個(gè)階段。實(shí)踐上軟件規(guī)劃的主要任務(wù)便是將軟件分解成模塊是指能完成某個(gè)功用的數(shù)據(jù)和程序闡明、可執(zhí)行程序的程序單元。能夠是一個(gè)函數(shù)、進(jìn)程、子程序、一段帶有程序闡明的獨(dú)立的程序和數(shù)據(jù)，也能夠是可組合、可分解和可更換的功用單元。模塊，然后進(jìn)行模塊規(guī)劃。概要規(guī)劃便是結(jié)構(gòu)規(guī)劃，其主要方針便是給出軟件的模塊結(jié)構(gòu)，用軟件結(jié)構(gòu)圖表明。具體規(guī)劃的首要任務(wù)便是規(guī)劃模塊的程序流程、算法和數(shù)據(jù)結(jié)構(gòu)，次要任務(wù)便是規(guī)劃數(shù)據(jù)庫(kù)，常用方法仍是結(jié)構(gòu)化程序規(guī)劃方法。 
編碼 
軟件編碼是指把軟件規(guī)劃轉(zhuǎn)換成計(jì)算機(jī)能夠承受的程序，即寫成以某一程序規(guī)劃言語(yǔ)表明的"源程序清單"。充分了解軟件開發(fā)言語(yǔ)、東西的特性和編程風(fēng)格，有助于開發(fā)東西的選擇以及確保軟件產(chǎn)品的開發(fā)質(zhì)量。 
當(dāng)前軟件開發(fā)中除在專用場(chǎng)合，現(xiàn)已很少使用二十世紀(jì)80年代的高檔言語(yǔ)了，取而代之的是面向?qū)ο蟮拈_發(fā)言語(yǔ)。并且面向?qū)ο蟮拈_發(fā)言語(yǔ)和開發(fā)環(huán)境大都合為一體，大大提高了開發(fā)的速度。 
測(cè)驗(yàn) 
軟件測(cè)驗(yàn)的目的是以較小的代價(jià)發(fā)現(xiàn)盡可能多的過錯(cuò)。要完成這個(gè)方針的關(guān)鍵在于規(guī)劃一套超卓的測(cè)驗(yàn)用例（測(cè)驗(yàn)數(shù)據(jù)和預(yù)期的輸出成果組成了測(cè)驗(yàn)用例）。如何才干規(guī)劃出一套超卓的測(cè)驗(yàn)用例，關(guān)鍵在于了解測(cè)驗(yàn)方法。不同的測(cè)驗(yàn)方法有不同的測(cè)驗(yàn)用例規(guī)劃方法。兩種常用的測(cè)驗(yàn)方法是白盒法測(cè)驗(yàn)對(duì)象是源程序，依據(jù)的是程序內(nèi)部的的邏輯結(jié)構(gòu)來發(fā)現(xiàn)軟件的編程過錯(cuò)、結(jié)構(gòu)過錯(cuò)和數(shù)據(jù)過錯(cuò)。結(jié)構(gòu)過錯(cuò)包含邏輯、數(shù)據(jù)流、初始化等過錯(cuò)。用例規(guī)劃的關(guān)鍵是以較少的用例掩蓋盡可能多的內(nèi)部程序邏輯成果。白盒法和黑盒法依據(jù)的是軟件的功用或軟件行為描繪，發(fā)現(xiàn)軟件的接口、功用和結(jié)構(gòu)過錯(cuò)。其間接口過錯(cuò)包含內(nèi)部/外部接口、資源管理、集成化以及體系過錯(cuò)。黑盒法用例規(guī)劃的關(guān)鍵同樣也是以較少的用例掩蓋模塊輸出和輸入接口。黑盒法。 
保護(hù) 
保護(hù)是指在已完結(jié)對(duì)軟件的研發(fā)（剖析、規(guī)劃、編碼和測(cè)驗(yàn)）作業(yè)并交付使用以后，對(duì)軟件產(chǎn)品所進(jìn)行的一些軟件工程的活動(dòng)。即依據(jù)軟件運(yùn)轉(zhuǎn)的狀況，對(duì)軟件進(jìn)行恰當(dāng)批改，以適應(yīng)新的要求，以及糾正運(yùn)轉(zhuǎn)中發(fā)現(xiàn)的過錯(cuò)。編寫軟件問題陳述、軟件批改陳述 。 
一個(gè)中等規(guī)模的軟件，假如研發(fā)階段需求一年至二年的時(shí)刻，在它投入使用以后，其運(yùn)轉(zhuǎn)或作業(yè)時(shí)刻可能持續(xù)五年至十年。那么它的保護(hù)階段也是運(yùn)轉(zhuǎn)的這五年至十年期間。在這段時(shí)刻，人們簡(jiǎn)直需求著手處理研發(fā)階段所遇到的各種問題，同時(shí)還要處理某些保護(hù)作業(yè)自身特有的問題。做好軟件保護(hù)作業(yè)，不僅能排除障礙，使軟件能正常作業(yè)，并且還能夠使它擴(kuò)展功用，提高性能，為用戶帶來顯著的經(jīng)濟(jì)效益?？墒沁z憾的是，對(duì)軟件保護(hù)作業(yè)的注重往往遠(yuǎn)不如對(duì)軟件研發(fā)作業(yè)的注重。而事實(shí)上，和軟件研發(fā)作業(yè)相比，軟件保護(hù)的作業(yè)量和成本都要大得多。
在實(shí)踐開發(fā)進(jìn)程中，軟件開發(fā)并不是從第一步進(jìn)行到最終一步，而是在任何階段，在進(jìn)入下一階段前一般都有一步或幾步的回溯。在測(cè)驗(yàn)進(jìn)程中的問題可能要求批改規(guī)劃，用戶可能會(huì)提出一些需求來批改需求闡明書等。
1、項(xiàng)目規(guī)劃 
項(xiàng)目規(guī)劃的主導(dǎo)思維，我覺得能夠了解為兩種，一種是徹底規(guī)劃，一個(gè)是簡(jiǎn)略規(guī)劃。 
徹底規(guī)劃是指在具體編寫代碼之前對(duì)軟件的各種方面都查詢好，做好具體的需求剖析、編寫好悉數(shù)的開發(fā)文檔，規(guī)劃出程序悉數(shù)流程后再開端寫代碼。 換句話說，便是悉數(shù)的計(jì)劃好了，能看到終究的樣子，再開戰(zhàn)。這如同也是許多“軟件工程”書里要求的那樣。開端的時(shí)分，我覺得這種方法不錯(cuò)也。什么都計(jì)劃好了，照著做便是了。不過這里有個(gè)顯著的問題，便是誰(shuí)來做這個(gè)完美的計(jì)劃？估計(jì)只要及其BT的人了，可是大部分人的想要徹底規(guī)劃，并且沒有過錯(cuò)，或者現(xiàn)已有幾種后備的容錯(cuò)計(jì)劃，并能準(zhǔn)確無(wú)誤的推廣。以到達(dá)終究方針。這樣的境界，沒有許多年的作業(yè)經(jīng)歷是不可能的。我也沒有這樣的本事，所以我也就放棄了這種主意。 
簡(jiǎn)略規(guī)劃：簡(jiǎn)略規(guī)劃一種概念，一種能夠承受的簡(jiǎn)略的規(guī)劃，最起碼數(shù)據(jù)庫(kù)現(xiàn)已定下來，根本流程現(xiàn)已確定的計(jì)劃，來作為程序規(guī)劃的開端，并隨時(shí)依據(jù)實(shí)踐狀況的發(fā)展來批改具體的功用規(guī)劃，但這種功用批改不能是批改數(shù)據(jù)庫(kù)結(jié)構(gòu)。也便是說數(shù)據(jù)庫(kù)結(jié)構(gòu)是在編程之前經(jīng)過反復(fù)論證的。這種方法減少了前期規(guī)劃的時(shí)刻，把代碼編寫作業(yè)和部分規(guī)劃作業(yè)放在了一同，實(shí)踐縮短了項(xiàng)目開發(fā)的時(shí)刻。假如說徹底規(guī)劃方法要求有很厲害的前期規(guī)劃人員，那么簡(jiǎn)略規(guī)劃要求有很有規(guī)劃腦筋的編程人員。編程人員不僅僅是K代碼的人并且要負(fù)責(zé)程序架構(gòu)的規(guī)劃。所以對(duì)程序員的要求就很高了。簡(jiǎn)略規(guī)劃的成功的一個(gè)基點(diǎn)是編程人員規(guī)劃的邏輯結(jié)構(gòu)簡(jiǎn)略并能依據(jù)需求來調(diào)整其邏輯結(jié)構(gòu)，便是代碼結(jié)構(gòu)靈活，簡(jiǎn)略規(guī)劃帶來的別的一個(gè)改動(dòng)便是會(huì)議會(huì)比較多，編程人員之間的交流就變的很重要。現(xiàn)在一般的中小型軟件公司根本上都是選用簡(jiǎn)略規(guī)劃的，除非那些很大型的軟件公司。 
總結(jié)，簡(jiǎn)略規(guī)劃?rùn)z測(cè)的是開發(fā)人員的才能。徹底規(guī)劃?rùn)z測(cè)的是前期規(guī)劃人員和整個(gè)項(xiàng)目組完整才能。(各種文檔的編寫，開發(fā)人員一定會(huì)要寫一部分的。)
2、規(guī)劃改動(dòng)和需求改動(dòng) 
開發(fā)人員最怕的是什么呢？規(guī)劃改動(dòng)，仍是需求改動(dòng)？我覺得需求改動(dòng)是最最喪命的。當(dāng)你的一個(gè)項(xiàng)目數(shù)據(jù)庫(kù)都定下來后，并且現(xiàn)已開發(fā)了若干個(gè)作業(yè)日，突然接到甲方公司提出，某個(gè)功用要改動(dòng)，原先的需求剖析要從頭改，假如這個(gè)批改是涉及的數(shù)據(jù)庫(kù)的表結(jié)構(gòu)更改的話，那真是最喪命的。這就意味著項(xiàng)目的某些部分得從頭推倒重來，假如這個(gè)部分跟已完結(jié)的多個(gè)部分有牽連的話，那就結(jié)果更可怕了。所以當(dāng)碰到這種狀況發(fā)生，作為項(xiàng)目經(jīng)理的你就應(yīng)該考慮先查責(zé)任人，究竟是自己的需求剖析做的不夠好，仍是客戶在認(rèn)同了需求剖析后做出的批改，假如是后者的話，你徹底能夠要求客戶對(duì)他的這個(gè)批改負(fù)責(zé)任！那么，呵呵，客戶先生，對(duì)不起了，本次新添加的需求將歸入別的一個(gè)版本。假如是改動(dòng)前面某個(gè)需求的界說，那么說不定就要推倒重來了，不過這個(gè)時(shí)分到不用太在意，畢竟錯(cuò)的是客戶。(項(xiàng)目正式開端前沒有沒有說清楚其需求)。所以，各位看客，在需求剖析做好后，在開工之前一定要叫客戶認(rèn)可簽字，并且在合同上要注明，當(dāng)由客戶原因引起的需求改動(dòng)而造成開發(fā)成本的添加，客戶要為此買單地。 
假如在需求不變的狀況之下，規(guī)劃發(fā)生了改動(dòng)，這個(gè)僅僅是咱們內(nèi)部之間的矛盾，商量一下就能處理。在簡(jiǎn)略規(guī)劃中，由于前期的規(guī)劃是不完整的，那么當(dāng)進(jìn)入任何一個(gè)新的模塊進(jìn)行開發(fā)時(shí)，都有可能引起規(guī)劃的改動(dòng)。開發(fā)人員的水平的凹凸就根本上決議了軟件的好壞。
3、代碼編寫 
當(dāng)需求定下來數(shù)據(jù)庫(kù)也定下來后， 其實(shí)咱們就能夠進(jìn)行實(shí)質(zhì)性的編碼了，依照我的觀點(diǎn)，一個(gè)人獨(dú)自編程最好，能隨時(shí)偷懶。(上網(wǎng)，和MM聊聊)，可是現(xiàn)在的軟件項(xiàng)目越來越大，工期也越來越緊，事實(shí)上咱們一個(gè)小組里邊，一般有3-5程序員，所以咱們要著重團(tuán)隊(duì)合作性。那么你寫的代碼使得別人要能夠看懂，咱們有必要在實(shí)踐的編寫代碼進(jìn)程中要有具體的編碼標(biāo)準(zhǔn)，編碼標(biāo)準(zhǔn)在許多書本里邊都提到過。但最起碼以下的一些標(biāo)準(zhǔn)是咱們有必要要遵守的： 一）源程序文件結(jié)構(gòu)： 
每個(gè)程序文件應(yīng)由標(biāo)題、內(nèi)容和附加闡明三部分組成。 
（1）標(biāo)題：文件最前面的注釋闡明，其內(nèi)容主要包含：程序名，作者，版權(quán)信息，扼要闡明 等，必要時(shí)應(yīng)有更詳盡的闡明（將以此部分以空行離隔獨(dú)自注釋）。 
（2）內(nèi)容控件注冊(cè)等函數(shù)應(yīng)放在內(nèi)容部分的最終，類的界說按 private 、 protected 、 pubilic 、 __pubished 的次序，并盡量堅(jiān)持每一部分只要一個(gè)，各部分中按數(shù)據(jù)、函數(shù)、特點(diǎn)、事情的次序。 
（3）附加闡明：文件末尾的補(bǔ)充闡明，如參考資料等，若內(nèi)容不多也可放在標(biāo)題部分的最終。 二）界面規(guī)劃風(fēng)格的一致性： 
由于選用可視化編程，一切的界面均與Win32方式類似，相應(yīng)選用的控件等也大都為Windows操作體系下的標(biāo)準(zhǔn)控件，并且參考了其他一些市面上相關(guān)的企業(yè)內(nèi)部管理的使用軟件。 
基于簡(jiǎn)略易操作的準(zhǔn)則，貼近用戶考慮，用戶界面選用Windows風(fēng)格的標(biāo)準(zhǔn)界面，操作方式亦同Windows風(fēng)格，這樣在施行進(jìn)程，能夠下降對(duì)客戶的培訓(xùn)，也能夠使用戶簡(jiǎn)單上手，簡(jiǎn)略易學(xué)。 三）修改風(fēng)格： 
（1）縮進(jìn)：縮進(jìn)以 Tab 為單位，一個(gè) Tab 為四個(gè)空格大小。大局?jǐn)?shù)據(jù)、函數(shù) 原型、標(biāo)題、附加闡明、函數(shù)闡明、標(biāo)號(hào)等均頂格書寫。 
（2）空格：數(shù)據(jù)和函數(shù)在其類型，潤(rùn)飾（如 __fastcall 等）稱號(hào)之間恰當(dāng)空格并據(jù)狀況對(duì) 齊。關(guān)鍵字準(zhǔn)則上空一格，不論是否有括號(hào)，對(duì)句子行后加的注釋使用恰當(dāng)空格與句子離隔并盡可能對(duì)齊。 
（3）對(duì)齊：準(zhǔn)則上關(guān)系密切的行應(yīng)對(duì)齊，對(duì)齊包含類型、潤(rùn)飾、稱號(hào)、參數(shù)等各部分對(duì)齊。 
另每一行的長(zhǎng)度不該超越屏幕太多，必要時(shí)恰當(dāng)換行。 
（4）空行：程序文件結(jié)構(gòu)各部分之間空兩行，若不必要也可只空一行，各函數(shù)完成之間一般空兩行。 
（5）注釋：對(duì)注釋有以下三點(diǎn)要求： 
A、有必要是有意義； 
B、有必要正確的描繪了程序； 
C、有必要是最新的。 
注釋必不可少，但也不該過多，以下是四種必要的注釋： 
標(biāo)題、附加闡明； 
函數(shù)闡明：對(duì)簡(jiǎn)直每個(gè)函數(shù)都應(yīng)有恰當(dāng)?shù)年U明，通常加在函數(shù)完成之前，在沒有函數(shù)完成部分的狀況下則加在函數(shù)原型前，其內(nèi)容主要是函數(shù)的功用、目的、算法等闡明，參數(shù)闡明、返回 值闡明等，必要時(shí)還要有一些如特別的軟硬件要求等闡明； 
在代碼不清楚或不可移植處應(yīng)有少數(shù)闡明； 
及少數(shù)的其它注釋。 四）命名標(biāo)準(zhǔn)： 
堅(jiān)持選用匈牙利變量命名慣例，一切標(biāo)識(shí)符一概用英文或英文縮寫，根絕選用拼音，標(biāo)識(shí)符中每個(gè)單詞首字母大寫，縮寫詞匯一般悉數(shù)大寫，只在必要時(shí)加“_”間隔詞匯。
4、BUG修補(bǔ) 
程序呈現(xiàn)了BUG誰(shuí)來修補(bǔ)呢，嘿嘿嘿…… 
最好的方法是誰(shuí)編寫誰(shuí)修補(bǔ)，誰(shuí)改壞誰(shuí)修補(bǔ)。一個(gè)人改壞的代碼一人去修。兩個(gè)人一同改壞的代碼兩人一同修。
5、開發(fā)人員的測(cè)驗(yàn) 
開發(fā)人員的測(cè)驗(yàn)是確保代碼能正常運(yùn)轉(zhuǎn)，在開發(fā)時(shí)分發(fā)現(xiàn)的過錯(cuò)往往比較簡(jiǎn)單批改。(別的一個(gè)優(yōu)點(diǎn)便是沒有人來罵你。由于只要你自己知道)?？墒且坏┸浖搅藴y(cè)驗(yàn)小組那里出了問題，那么就多了許多時(shí)刻來批改BUG，假如到了客戶哪里才發(fā)現(xiàn)的BUG，那么時(shí)刻就更長(zhǎng)了，開發(fā)人員自身受到的壓力也是到了最大話了?？蛻?>公司->測(cè)驗(yàn)小組->開發(fā)人員。 這個(gè)徹底是倒金字塔型的，承受才能差的一環(huán)很簡(jiǎn)單出事情的。 
別的開發(fā)人員的測(cè)驗(yàn)除了確保代碼能正常運(yùn)轉(zhuǎn)以外，還有一個(gè)很重要的方面便是要確保前次能正常運(yùn)轉(zhuǎn)的代碼，這次仍是能正常運(yùn)轉(zhuǎn)。假如做不到這點(diǎn)，那么BUG就不斷的會(huì)呈現(xiàn)，許多BUG也會(huì)反復(fù)呈現(xiàn)。所以軟件看上去就有修補(bǔ)不完的BUG了。假如呈現(xiàn)這種狀況，那么開發(fā)人員有必要再教育。一般公司教育的方式有四種。第一種，扣薪酬，第二種，加班，反復(fù)加班+精力攻擊。 第三種，開除。第四種，調(diào)動(dòng)人員來協(xié)助那個(gè)出了費(fèi)事的家伙。 希望看這個(gè)文章的人不要受到前面三種教育。