軟件開發(fā)12頁

《軟件開發(fā)12頁》由會員分享，可在線閱讀，更多相關《軟件開發(fā)12頁（12頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、軟件開發(fā)軟件（Software）簡單的說就是那些在計算機中能看的著，但摸不著的東西，概念性的說軟件也稱為“軟設備”，廣義地說軟件是指系統(tǒng)中的程序以及開發(fā)、使用程序所需要的所有文檔的集合。軟件分為系統(tǒng)軟件和應用軟件。 軟件并不只是包括可以在計算機上運行的程序，與這些程序相關的文件一般也被認為是軟件的一部分。 軟件被應用于世界的各個領域，對人們的生活和工作都產生了深遠的影響目錄軟件開發(fā)的內容 1. 設計 2. 編程 3. 測試 4. 客戶 5. 開發(fā)人員軟件開發(fā)過程 1. 分析 2. 設計 3. 編碼 4. 測試 5. 維護軟件開發(fā)專業(yè) 1. 專業(yè)培養(yǎng) 2. 就業(yè)方向軟件開發(fā)流程 1. 流程的總括

2、 2. 流程的舉例 3. 軟件開發(fā)中的注意事項 4. 軟件開發(fā)企業(yè)用人主要有以下幾個特征軟件開發(fā)平臺 軟件開發(fā)-軟件開發(fā)中的注意事項軟件開發(fā)的內容 1. 設計 2. 編程 3. 測試 4. 客戶 5. 開發(fā)人員軟件開發(fā)過程 1. 分析 2. 設計 3. 編碼 4. 測試 5. 維護軟件開發(fā)專業(yè) 1. 專業(yè)培養(yǎng) 2. 就業(yè)方向軟件開發(fā)流程 1. 流程的總括 2. 流程的舉例 3. 軟件開發(fā)中的注意事項 4. 軟件開發(fā)企業(yè)用人主要有以下幾個特征軟件開發(fā)平臺 軟件開發(fā)-軟件開發(fā)中的注意事項展開軟件開發(fā)的內容不僅僅是用戶需求，應該是開發(fā)中遇到的所有的需求。比如，你首先要知道做這個項目是為了解決什么問題

3、；測試案例中應該輸入什么數(shù)據(jù).為了清楚地知道這些需求，你經(jīng)常要和客戶、項目經(jīng)理以及項目伙伴交流。 設計編碼前，肯定有個計劃告訴你要做什么，結構是怎樣等等。你一定要按照這個來做，否則可能會一團糟。 編程如果在項目截止日，你的程序不能跑起來或達不到客戶的要求，你就拿不到錢。 測試目的是讓你知道，什么時候算是完成了。如果你聰明，你就應該先寫測試，這樣可以及時知道你是否真地完成了。否則，你經(jīng)常會不知道，到底有哪些功能是真正完成了，離預期目標還差多遠。 軟件開發(fā)中，客戶和開發(fā)人員都有自己的基本權利和義務。 客戶定義每個用戶需求的商業(yè)優(yōu)先級； 制訂總體計劃，包括用多少投資、經(jīng)過多長時間、達到什么目的； 在

4、項目開發(fā)過程中的每個工作周，都能讓投資獲得最大的收益； 通過重復運行你所指定的功能測試，準確地掌握項目進展情況； 能隨時改變需求、功能或優(yōu)先級，同時避免昂貴的再投資；能夠根據(jù)各種變化及時調整項目計劃； 能夠隨時取消項目；項目取消時，以前的開發(fā)工作不是一堆垃圾，已開發(fā)完的功能是合乎要求的，正在進行或未完成的的工作則應該是不難接手的。 開發(fā)人員知道要做什么，以及要優(yōu)先做什么； 工作有效率； 有問題或困難時，能得到客戶、同事、上級的回答或幫助； 對工作做評估，并根據(jù)周圍情況的變化及時重新評估； 積極承擔工作，而不是消極接受分配； 一周40小時工作制，不加班。 軟件開發(fā)過程軟件開發(fā)過程分為5個階段：

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

6、以分為概要設計和詳細設計兩個階段。實際上軟件設計的主要任務就是將軟件分解成模塊是指能實現(xiàn)某個功能的數(shù)據(jù)和程序說明、可執(zhí)行程序的程序單元?？梢允且粋€函數(shù)、過程、子程序、一段帶有程序說明的獨立的程序和數(shù)據(jù)，也可以是可組合、可分解和可更換的功能單元。模塊，然后進行模塊設計。概要設計就是結構設計，其主要目標就是給出軟件的模塊結構，用軟件結構圖表示。詳細設計的首要任務就是設計模塊的程序流程、算法和數(shù)據(jù)結構，次要任務就是設計數(shù)據(jù)庫，常用方法還是結構化程序設計方法。 編碼軟件編碼是指把軟件設計轉換成計算機可以接受的程序，即寫成以某一程序設計語言表示的源程序清單。充分了解軟件開發(fā)語言、工具的特性和編程風格，有

7、助于開發(fā)工具的選擇以及保證軟件產品的開發(fā)質量。 當前軟件開發(fā)中除在專用場合，已經(jīng)很少使用二十世紀80年代的高級語言了，取而代之的是面向對象的開發(fā)語言。而且面向對象的開發(fā)語言和開發(fā)環(huán)境大都合為一體，大大提高了開發(fā)的速度。 測試軟件測試的目的是以較小的代價發(fā)現(xiàn)盡可能多的錯誤。要實現(xiàn)這個目標的關鍵在于設計一套出色的測試用例（測試數(shù)據(jù)和預期的輸出結果組成了測試用例）。如何才能設計出一套出色的測試用例，關鍵在于理解測試方法。不同的測試方法有不同的測試用例設計方法。兩種常用的測試方法是白盒法測試對象是源程序，依據(jù)的是程序內部的的邏輯結構來發(fā)現(xiàn)軟件的編程錯誤、結構錯誤和數(shù)據(jù)錯誤。結構錯誤包括邏輯、數(shù)據(jù)流、初

8、始化等錯誤。用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果。白盒法和黑盒法依據(jù)的是軟件的功能或軟件行為描述，發(fā)現(xiàn)軟件的接口、功能和結構錯誤。其中接口錯誤包括內部/外部接口、資源管理、集成化以及系統(tǒng)錯誤。黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。黑盒法。 維護維護是指在已完成對軟件的研制（分析、設計、編碼和測試）工作并交付使用以后，對軟件產品所進行的一些軟件工程的活動。即根據(jù)軟件運行的情況，對軟件進行適當修改，以適應新的要求，以及糾正運行中發(fā)現(xiàn)的錯誤。編寫軟件問題報告、軟件修改報告。 一個中等規(guī)模的軟件，如果研制階段需要一年至二年的時間，在它投入使用以后，其運行

9、或工作時間可能持續(xù)五年至十年。那么它的維護階段也是運行的這五年至十年期間。在這段時間，人們幾乎需要著手解決研制階段所遇到的各種問題，同時還要解決某些維護工作本身特有的問題。做好軟件維護工作，不僅能排除障礙，使軟件能正常工作，而且還可以使它擴展功能，提高性能，為用戶帶來明顯的經(jīng)濟效益。然而遺憾的是，對軟件維護工作的重視往往遠不如對軟件研制工作的重視。而事實上，和軟件研制工作相比，軟件維護的工作量和成本都要大得多。 在實際開發(fā)過程中，軟件開發(fā)并不是從第一步進行到最后一步，而是在任何階段，在進入下一階段前一般都有一步或幾步的回溯。在測試過程中的問題可能要求修改設計，用戶可能會提出一些需要來修改需求說

10、明書等。 軟件開發(fā)專業(yè)專業(yè)培養(yǎng)計算機：軟件開發(fā)專業(yè)主要培養(yǎng)德智體全面發(fā)展，具有一定計算機軟硬件維護、網(wǎng)絡組建、維護管理的高級實用技術型人才。通過本專業(yè)的學習，能熟練掌握常用的計算機軟件的使用、維護與技巧；在硬件方面學生應了解計算機硬件的發(fā)展，熟練掌握計算機組裝的方法，能熟練運用應用軟件檢測計算機性能、故障的范圍所在，掌握硬件故障的一般處理方法；在網(wǎng)絡方面，學生應掌握目前流行網(wǎng)絡的技術特點，掌握網(wǎng)絡工程、網(wǎng)絡維護、網(wǎng)絡安全及應用方面的知識。能勝任一般網(wǎng)絡工程方案的設計、組建、網(wǎng)絡維護、及簡單網(wǎng)站的建設與維護。同時，使學生了解由于IT技術的發(fā)展而引起的法律和道德方面的問題。 就業(yè)方向本專業(yè)畢業(yè)生適

11、合的工作崗位是計算機程序設計師。適合于熟練地按照工程化的思路進行軟件編制、軟件測試的工作崗位，能擔任各種企事業(yè)單位和各級工程建設部門、管理部門的計算機軟件和硬件維護、網(wǎng)絡的組建、維護等工作，也可從事計算機研究與應用、軟件開發(fā)等方面的工作。就業(yè)范圍為：計算機軟件公司、具有軟件開發(fā)能力的大型企業(yè)及事業(yè)單位、大專院校和科研院所。 軟件開發(fā)流程流程的總括軟件設計思路和方法的一般過程，包括設計軟件的功能和實現(xiàn)的算法和方法、軟件的總體結構設計和模塊設計、編程和調試、程序聯(lián)調和測試以及編寫、提交程序。 1 相關系統(tǒng)分析員和用戶初步了解需求，然后用WORD列出要開發(fā)的系統(tǒng)的大功能模塊，每個大功能模塊有哪些小功

12、能模塊，對于有些需求比較明確相關的界面時，在這一步里面可以初步定義好少量的界面。 2 系統(tǒng)分析員深入了解和分析需求，根據(jù)自己的經(jīng)驗和需求用WORD或相關的工具再做出一份文檔系統(tǒng)的功能需求文檔。這次的文檔會清楚例用系統(tǒng)大致的大功能模塊，大功能模塊有哪些小功能模塊，并且還列出相關的界面和界面功能。 3 系統(tǒng)分析員和用戶再次確認需求。 4 系統(tǒng)分析員根據(jù)確認的需求文檔所例用的界面和功能需求，用迭代的方式對每個界面或功能做系統(tǒng)的概要設計。 5 系統(tǒng)分析員把寫好的概要設計文檔給程序員，程序員根據(jù)所列出的功能一個一個的編寫。 6 測試編寫好的系統(tǒng)。交給用戶使用，用戶使用后一個一個的確認每個功能，然后驗收。

13、 流程的舉例1 某公司想找人訂做一套人事管理軟件,從某種渠道上得知我們有提供這種服務，所以聯(lián)系上了我們。 2 我們會派專門的軟件工程師到他們那里去了解我們要設計一個什么的東西給他們用，然后回來做個方案給他們，其中方案的內容包括：我們開發(fā)出來的軟件大概的界面是怎樣？方便什么人使用？什么人可以使用什么功能？方便到什么程度？大概的硬件要求是怎樣等？ 3 他們看了方案后，確定他們就是要做一套這樣的軟件，我就開始開發(fā)這套軟件。 4 我們把開發(fā)出來的軟件交用他們使用，其中在使用的過程中哪里使用不方便或哪里達不到要求，我們會第第一時間修改這些功能，直到他們要求的所有功能都能很完美的解決掉。 軟件開發(fā)中的注意

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

15、經(jīng)歷是不可能的。我也沒有這樣的本事，所以我也就放棄了這種想法。 簡單設計：簡單設計一種概念，一種可以接受的簡單的設計，最起碼數(shù)據(jù)庫已經(jīng)定下來，基本流程已經(jīng)確定的方案，來作為程序設計的開始，并隨時根據(jù)實際情況的進展來修正具體的功能設計，但這種功能修改不能是修改數(shù)據(jù)庫結構。也就是說數(shù)據(jù)庫結構是在編程之前經(jīng)過反復論證的。這種方法減少了前期設計的時間，把代碼編寫工作和部分設計工作放在了一起，實際縮短了項目開發(fā)的時間。如果說完全設計方法要求有很厲害的前期設計人員，那么簡單設計要求有很有設計頭腦的編程人員。編程人員不僅僅是K代碼的人而且要負責程序架構的設計。所以對程序員的要求就很高了。 簡單設計的成功的一

16、個基點是編程人員設計的邏輯結構簡單并能根據(jù)需要來調整其邏輯結構，就是代碼結構靈活，簡單設計帶來的另外一個變化就是會議會比較多，編程人員之間的交流就變的很重要?，F(xiàn)在一般的中小型軟件公司基本上都是采用簡單設計的，除非那些很大型的軟件公司。 總結，簡單設計考驗的是開發(fā)人員的能力。完全設計考驗的是前期設計人員和整個項目組完整能力。(各種文檔的編寫，開發(fā)人員一定會要寫一部分的。) 2、設計變化和需求變化 開發(fā)人員最怕的是什么呢？設計變化，還是需求變化？我覺得需求變化是最最致命的。當你的一個項目數(shù)據(jù)庫都定下來后，而且已經(jīng)開發(fā)了若干個工作日，突然接到甲方公司提出，某個功能要改變，原先的需求分析要重新改，如果

17、這個修改是涉及的數(shù)據(jù)庫的表結構更改的話，那真是最致命的。這就意味著項目的某些部分得重新推倒重來，如果這個部分跟已完成的多個部分有牽連的話，那就后果更可怕了。所以當碰到這種情況發(fā)生，作為項目經(jīng)理的你就應該考慮先查責任人，究竟是自己的需求分析做的不夠好，還是客戶在認同了需求分析后做出的修改，如果是后者的話，你完全可以要求客戶對他的這個修改負責任！那么，呵呵，客戶先生，對不起了，本次新增加的需求將歸入另外一個版本。如果是改變前面某個需求的定義，那么說不定就要推倒重來了，不過這個時候到不用太在意，畢竟錯的是客戶。(項目正式開始前沒有沒有說清楚其需求)。所以，各位看客，在需求分析做好后，在開工之前一定要

18、叫客戶認可簽字，并且在合同上要注明，當由客戶原因引起的需求改變而造成開發(fā)成本的增加，客戶要為此買單地。 如果在需求不變的情況之下，設計發(fā)生了變化，這個僅僅是我們內部之間的矛盾，商量一下就能解決。在簡單設計中，因為前期的設計是不完整的，那么當進入任何一個新的模塊進行開發(fā)時，都有可能引起設計的變化。開發(fā)人員的水平的高低就基本上決定了軟件的好壞。 3、代碼編寫 當需求定下來數(shù)據(jù)庫也定下來后， 其實我們就可以進行實質性的編碼了，按照我的看法，一個人單獨編程最好，能隨時偷懶。(上網(wǎng)，和MM聊聊)，但是現(xiàn)在的軟件項目越來越大，工期也越來越緊，事實上我們一個小組里面，一般有3-5程序員，所以我們要強調團隊合

19、作性。那么你寫的代碼使得別人要能夠看懂，我們必須在實際的編寫代碼過程中要有詳細的編碼規(guī)范，編碼規(guī)范在很多書籍里面都提到過。但最起碼以下的一些規(guī)范是我們必須要遵守的： 一）源程序文件結構： 每個程序文件應由標題、內容和附加說明三部分組成。 （1）標題：文件最前面的注釋說明，其內容主要包括：程序名，作者，版權信息，簡要說明 等，必要時應有更詳盡的說明（將以此部分以空行隔開單獨注釋）。 （2）內容控件注冊等函數(shù)應放在內容部分的最后，類的定義按 private 、 protected 、 pubilic 、 _pubished 的順序，并盡量保持每一部分只有一個，各部分中按數(shù)據(jù)、函數(shù)、屬性、事件的順序

20、。 （3）附加說明：文件末尾的補充說明，如參考資料等，若內容不多也可放在標題部分的最后。 二）界面設計風格的一致性： 由于采用可視化編程，所有的界面均與Win32方式類似，相應采用的控件等也大都為Windows操作系統(tǒng)下的標準控件，而且參考了其他一些市面上相關的企業(yè)內部管理的應用軟件。 基于簡單易操作的原則，貼近用戶考慮，用戶界面采用Windows風格的標準界面，操作方式亦同Windows風格，這樣在實施過程，可以降低對客戶的培訓，也可以使用戶容易上手，簡單易學。 三）編輯風格： （1）縮進：縮進以 Tab 為單位，一個 Tab 為四個空格大小。全局數(shù)據(jù)、函數(shù) 原型、標題、附加說明、函數(shù)說明、

21、標號等均頂格書寫。 （2）空格：數(shù)據(jù)和函數(shù)在其類型，修飾（如 _fastcall 等）名稱之間適當空格并據(jù)情況對 齊。關鍵字原則上空一格，不論是否有括號，對語句行后加的注釋應用適當空格與語句隔開并盡可能對齊。 （3）對齊：原則上關系密切的行應對齊，對齊包括類型、修飾、名稱、參數(shù)等各部分對齊。 另每一行的長度不應超過屏幕太多，必要時適當換行。 （4）空行：程序文件結構各部分之間空兩行，若不必要也可只空一行，各函數(shù)實現(xiàn)之間一般空兩行。 （5）注釋：對注釋有以下三點要求： A、必須是有意義； B、必須正確的描述了程序； C、必須是最新的。 注釋必不可少，但也不應過多，以下是四種必要的注釋： 標題、附

22、加說明； 函數(shù)說明：對幾乎每個函數(shù)都應有適當?shù)恼f明，通常加在函數(shù)實現(xiàn)之前，在沒有函數(shù)實現(xiàn)部分的情況下則加在函數(shù)原型前，其內容主要是函數(shù)的功能、目的、算法等說明，參數(shù)說明、返回 值說明等，必要時還要有一些如特別的軟硬件要求等說明； 在代碼不明晰或不可移植處應有少量說明； 及少量的其它注釋。 四）命名規(guī)范： 堅持采用匈牙利變量命名慣例，所有標識符一律用英文或英文縮寫，杜絕采用拼音，標識符中每個單詞首字母大寫，縮寫詞匯一般全部大寫，只在必要時加“_”間隔詞匯。 4、BUG修補 程序出現(xiàn)了BUG誰來修補呢，嘿嘿嘿 最好的辦法是誰編寫誰修補，誰改壞誰修補。一個人改壞的代碼一人去修。兩個人一起改壞的代碼兩

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

24、軟件看上去就有修補不完的BUG了。如果出現(xiàn)這種情況，那么開發(fā)人員有必要再教育。一般公司教育的方式有四種。第一種，扣工資，第二種，加班，反復加班+精神攻擊。 第三種，開除。第四種，調動人員來幫助那個出了麻煩的家伙。 但愿看這個文章的人不要受到前面三種教育。 軟件開發(fā)企業(yè)用人主要有以下幾個特征1 外包開發(fā)行業(yè)快速發(fā)展，對“人才”在代碼和文檔方面的規(guī)范性、技能和工具的熟練程度要求越來越高； 2 Java和.NET技術在市場上平分秋色，都有大量的崗位需求，同時值得慶幸的是二者在應用層面上的技術差異越來越少； 3 軟件開發(fā)企業(yè)對開發(fā)人員的基本技術素養(yǎng)強調得越來越多，例如：面向對象的程序設計思想和代碼組織

25、方法、HTML/CSS/JavaScript客戶端技術； 4 為了保證質量和工期，企業(yè)中大量使用各種框架技術，要求開發(fā)人員至少熟悉一種框架技術； 5 MIS、OA、ERP、CRM、系統(tǒng)集成、物流、進銷存、電子政務、網(wǎng)站建設這一類B/S系統(tǒng)，成為軟件工程師需求最大的業(yè)務領域。 軟件開發(fā)平臺軟件開發(fā)平臺源于繁瑣的實踐開發(fā)過程中。開發(fā)人員在實踐中將常用的函數(shù)、類、抽象、接口等進行總結、封裝，成為了可以重復使用的“中間件”，而隨著“中間件”的成熟和通用，功能更強大、更能滿足企業(yè)級客戶需求的軟件開平臺應運而生。 平臺是一段時間內科研成果的匯聚，也是階段性平臺期的標志，為行業(yè)進入新的研發(fā)領域提供了基礎。由

26、于平臺對企業(yè)核心競爭力的提升非常明顯，目前國內的管理軟件市場，軟件開發(fā)平臺的應用已經(jīng)成為一種趨勢。 目前國內的軟件開發(fā)平臺，除國際品牌如IBM，國內平臺商比較成熟的有Justep、普元、昕友億方、創(chuàng)恒信、北京百特安茂信息技術有限公司提供的VisualSet開發(fā)平臺，以及山東金現(xiàn)代信息技術有限公司出品的輕騎兵軟件開發(fā)平臺等，部分管理軟件企業(yè)也開始借力平臺提升企業(yè)競爭力，如用友。 由于開發(fā)環(huán)境、開發(fā)人員、功能定位、行業(yè)背景等的不同，不同品牌的平臺存在較大差別。以輕騎兵軟件開發(fā)平臺為例，其最大特點在于可視化的界面定制、方便快捷的流程配置、按需定義的報表定制、功能完善的二次開發(fā)支持。 軟件開發(fā)-軟件開

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

28、多年的工作經(jīng)歷是不可能的。我也沒有這樣的本事，所以我也就放棄了這種想法。 簡單設計：簡單設計一種概念，一種可以接受的簡單的設計，最起碼數(shù)據(jù)庫已經(jīng)定下來，基本流程已經(jīng)確定的方案，來作為程序設計的開始，并隨時根據(jù)實際情況的進展來修正具體的功能設計，但這種功能修改不能是修改數(shù)據(jù)庫結構。也就是說數(shù)據(jù)庫結構是在編程之前經(jīng)過反復論證的。這種方法減少了前期設計的時間，把代碼編寫工作和部分設計工作放在了一起，實際縮短了項目開發(fā)的時間。如果說完全設計方法要求有很厲害的前期設計人員，那么簡單設計要求有很有設計頭腦的編程人員。編程人員不僅僅是K代碼的人而且要負責程序架構的設計。所以對程序員的要求就很高了。 簡單設計

29、的成功的一個基點是編程人員設計的邏輯結構簡單并能根據(jù)需要來調整其邏輯結構，就是代碼結構靈活，簡單設計帶來的另外一個變化就是會議會比較多，編程人員之間的交流就變的很重要?，F(xiàn)在一般的中小型軟件公司基本上都是采用簡單設計的，除非那些很大型的軟件公司。 總結，簡單設計考驗的是開發(fā)人員的能力。完全設計考驗的是前期設計人員和整個項目組完整能力。(各種文檔的編寫，開發(fā)人員一定會要寫一部分的。) 2、設計變化和需求變化 開發(fā)人員最怕的是什么呢？設計變化，還是需求變化？我覺得需求變化是最最致命的。當你的一個項目數(shù)據(jù)庫都定下來后，而且已經(jīng)開發(fā)了若干個工作日，突然接到甲方公司提出，某個功能要改變，原先的需求分析要重

30、新改，如果這個修改是涉及的數(shù)據(jù)庫的表結構更改的話，那真是最致命的。這就意味著項目的某些部分得重新推倒重來，如果這個部分跟已完成的多個部分有牽連的話，那就后果更可怕了。所以當碰到這種情況發(fā)生，作為項目經(jīng)理的你就應該考慮先查責任人，究竟是自己的需求分析做的不夠好，還是客戶在認同了需求分析后做出的修改，如果是后者的話，你完全可以要求客戶對他的這個修改負責任！那么，呵呵，客戶先生，對不起了，本次新增加的需求將歸入另外一個版本。如果是改變前面某個需求的定義，那么說不定就要推倒重來了，不過這個時候到不用太在意，畢竟錯的是客戶。(項目正式開始前沒有沒有說清楚其需求)。所以，各位看客，在需求分析做好后，在開工

31、之前一定要叫客戶認可簽字，并且在合同上要注明，當由客戶原因引起的需求改變而造成開發(fā)成本的增加，客戶要為此買單地。 如果在需求不變的情況之下，設計發(fā)生了變化，這個僅僅是我們內部之間的矛盾，商量一下就能解決。在簡單設計中，因為前期的設計是不完整的，那么當進入任何一個新的模塊進行開發(fā)時，都有可能引起設計的變化。開發(fā)人員的水平的高低就基本上決定了軟件的好壞。 3、代碼編寫 當需求定下來數(shù)據(jù)庫也定下來后， 其實我們就可以進行實質性的編碼了，按照我的看法，一個人單獨編程最好，能隨時偷懶。(上網(wǎng)，和MM聊聊)，但是現(xiàn)在的軟件項目越來越大，工期也越來越緊，事實上我們一個小組里面，一般有3-5程序員，所以我們要

32、強調團隊合作性。那么你寫的代碼使得別人要能夠看懂，我們必須在實際的編寫代碼過程中要有詳細的編碼規(guī)范，編碼規(guī)范在很多書籍里面都提到過。但最起碼以下的一些規(guī)范是我們必須要遵守的： 一）源程序文件結構： 每個程序文件應由標題、內容和附加說明三部分組成。 （1）標題：文件最前面的注釋說明，其內容主要包括：程序名，作者，版權信息，簡要說明 等，必要時應有更詳盡的說明（將以此部分以空行隔開單獨注釋）。 （2）內容控件注冊等函數(shù)應放在內容部分的最后，類 的定義按 private 、 protected 、 pubilic 、 _pubished 的順序，并盡量保持每一部分只有一個，各部分中按數(shù)據(jù)、函數(shù)、屬性

33、、事件的順序。 （3）附加說明：文件末尾的補充說明，如參考資料等，若內容不多也可放在標題部分的最后。 二）界面設計風格的一致性： 由于采用可視化編程，所有的界面均與Win32方式類似，相應采用的控件等也大都為Windows操作系統(tǒng)下的標準控件，而且參考了其他一些市面上相關的企業(yè)內部管理的應用軟件。 基于簡單易操作的原則，貼近用戶考慮，用戶界面采用Windows風格的標準界面，操作方式亦同Windows風格，這樣在實施過程，可以降低對客戶的培訓，也可以使用戶容易上手，簡單易學。 三）編輯風格： （1）縮進：縮進以 Tab 為單位，一個 Tab 為四個空格大小。全局數(shù)據(jù)、函數(shù) 原型、標題、附加說明

34、、函數(shù)說明、標號等均頂格書寫。 （2）空格：數(shù)據(jù)和函數(shù)在其類型，修飾（如 _fastcall 等）名稱之間適當空格并據(jù)情況對 齊。關鍵字原則上空一格，不論是否有括號，對語句行后加的注釋應用適當空格與語句隔開并盡可能對齊。 （3）對齊：原則上關系密切的行應對齊，對齊包括類型、修飾、名稱、參數(shù)等各部分對齊。 另每一行的長度不應超過屏幕太多，必要時適當換行。 （4）空行：程序文件結構各部分之間空兩行，若不必要也可只空一行，各函數(shù)實現(xiàn)之間一般空兩行。 （5）注釋：對注釋有以下三點要求： A、必須是有意義； B、必須正確的描述了程序； C、必須是最新的。 注釋必不可少，但也不應過多，以下是四種必要的注釋

35、： 標題、附加說明； 函數(shù)說明：對幾乎每個函數(shù)都應有適當?shù)恼f明，通常加在函數(shù)實現(xiàn)之前，在沒有函數(shù)實現(xiàn)部分的情況下則加在函數(shù)原型前，其內容主要是函數(shù)的功能、目的、算法等說明，參數(shù)說明、返回 值說明等，必要時還要有一些如特別的軟硬件要求等說明； 在代碼不明晰或不可移植處應有少量說明； 及少量的其它注釋。 四）命名規(guī)范： 堅持采用匈牙利變量命名慣例，所有標識符一律用英文或英文縮寫，杜絕采用拼音，標識符中每個單詞首字母大寫，縮寫詞匯一般全部大寫，只在必要時加“_”間隔詞匯。 4、BUG修補 程序出現(xiàn)了BUG誰來修補呢，嘿嘿嘿 最好的辦法是誰編寫誰修補，誰改壞誰修補。一個人改壞的代碼一人去修。兩個人一起

36、改壞的代碼兩人一起修。 5、開發(fā)人員的測試 開發(fā)人員的測試是保證代碼能正常運行，在開發(fā)時候發(fā)現(xiàn)的錯誤往往比較容易修正。(另外一個好處就是沒有人來罵你。因為只有你自己知道)。但是一旦軟件到了測試小組那里出了問題，那么就多了很多時間來修正BUG，如果到了客戶哪里才發(fā)現(xiàn)的BUG，那么時間就更長了，開發(fā)人員本身受到的壓力也是到了最大話了?？蛻?公司-測試小組-開發(fā)人員。 這個完全是倒金字塔型的，承受能力差的一環(huán)很容易出事情的。 另外開發(fā)人員的測試除了保證代碼能正常運行以外，還有一個很重要的方面就是要保證上次能正常運行的代碼，這次還是能正常運行。如果做不到這點，那么BUG就不斷的會出現(xiàn)，很多BUG也會反復出現(xiàn)。于是軟件看上去就有修補不完的BUG了。如果出現(xiàn)這種情況，那么開發(fā)人員有必要再教育。一般公司教育的方式有以下四種： 第一種，開會教育批評， 第二種，扣工資， 第三種，加班，反復加班+精神攻擊， 第四種，開除。