衆所周知，做軟體的目的就是要滿足客戶的需求，這個需求包括功能、外觀、操作、時間及性能等各方面。那麼，在軟體開發過程中那部分最重要呢，程式員說“毋庸置疑，我編寫的程式實作了客戶提出的功能以及業務流程，肯定我是最重要的”，美工說“你開發的功能如果沒有我的頁面美化，是無法呈現給客戶的，要知道，很多客戶并不很了解内部複雜的功能，首先映入眼簾的就是界面的效果，就像人一樣，如果你不是美女，那麼他看了你一眼之後，就沒有想和你再繼續溝通和發展的積極性了”，測試聽了不高興了，說“漏洞百出的産品，哪怕你外觀再漂亮，實作的功能再多，也是不成熟的産品，客戶是不會使用的。”衆說紛纭，各執一詞。
以上所說都很有道理，每個角色都是軟體成功必不可少的，每個人都好比是一塊積木，隻有組合起來才能搭成既美觀又穩固的造型。
另一方面，他們卻又都不是最重要的。舉個例子，現在我家在進行裝修，木工、瓦工、油漆工都是南方的勞工，有很好的手藝，幹活也很細緻，可是他們在施工的時候都要參考兩份檔案，一是房屋結構圖，二是裝修效果圖。沒有此檔案，他們就無從下手，就是擁有再好的手藝，做出來的再漂亮，到時候也會與房屋的實際效果存在偏差。
孫悟空三大白骨精，相信誰都耳熟能詳。裡面有這樣一個場景，孫悟空去化齋前，劃了一個圈，将唐僧他們包在裡面，隻要他們在圈裡面，就不會有事，如果出了圈就很危險。這個圈，就是一個範圍、一個标準。在這個圈裡，你随便折騰，怎麼折騰都行，但千萬不要越界，否則後果不堪設想。
而在軟體開發中文檔就是那個圈，它将項目開發所進行的一切活動都進行詳細的定義，隻要遵照這個文檔去開發，那麼最終的結果一定是八九不離十。
文檔貫穿軟體工程的始終，從前期的項目準備，中期的開發到後期的維護、教育訓練，無不以文檔作為工作的依據。那麼在軟體項目中，都包括哪些文檔呢，它們的作用又是什麼呢，下面我将我的經驗分享給大家。
《可行性研究報告》：這是客戶在進行項目調研階段所編寫的，具有兩重意義，其一，指明項目的必要性和緊迫性，并從業務角度闡述大概的功能需求，注意，隻是大概，可能與最後的結果有很大出入；其二，最重要的一點就是為了要錢，向财政部要錢，将最終實作的功能寫得天花亂墜，包括決策支援、全文檢索、商業智能、遠端報表等，但最後開發的可能僅僅是融合簡單業務流程的資訊輸入和輸出而已，但這已無關緊要，最重要的是我要到了錢。但是嚴格來說，這不是項目組所需的文檔，于軟體開發也意義不大。
《建設方案》：或者是《實施方案》，當客戶從财政部申請到資金後，就要着手進行詳細的調研和分析了，這裡有兩種情況，其一，客戶自己從各個産品廠家進行相關的調研，進行彙總後，編寫方案，這樣，聰明、細心的軟體公司就會從方案的技術環節，挖掘出客戶所選擇的産品，最後和這個産品公司合作來中标；其二，讓和其關系很好的一家或兩家軟體公司（不會超過三家）編寫，客戶進行稽核，客戶最後選擇了誰的方案那麼最後這個項目就是這家公司的，這樣很多情況并不是公開招标。
《招标書》：将《建設方案》或《實施方案》進行摘取，并附帶上技術問題以及招标時的細節、注意事項，構成《招标書》，這個檔案也是由客戶寫得，軟體公司在投标前需要購買《招标書》。
《投标書》：與《招标書》所呼應，對技術問題進行相應的技術應答，包括技術标和商務标兩部分。
上面幾份文檔，是項目前期準備時需要的，是側重于售前方面的；而下面的文檔是軟體開發過程中必不可少的，我們按開發工作的時間順序一一介紹。
《需求分析說明書》：對于軟體開發來說，《需求分析說明書》就好像是蓋樓時所用的圖紙，是最重要的文檔，由項目經理對客戶相關部門進行業務調研後編寫，語言側重于從業務的角度描述功能需求。内容涉及三大部分，其一，編寫目的、背景、目标任務等公共性語言；其二，功能性需求，将業務梳理成幾大功能子產品，一級功能下細分二級功能，依次類推，将最終細化的功能按描述、輸入、處理和輸出進行較長的描述；其三，非功能性需求，包括性能、處理能力、進度、界面設計和運作環境的規定。
《資料庫設計說明書》：我是做資料庫出身，是以這部分的工作也是由我這個項目經理來做，根據《需求分析說明書》在Erwin模組化工具中設計好邏輯模型和實體模型，然後将其整理到此文檔中，文檔還包含資料庫所有的表結構和相關的字段說明。
《概要設計說明書》：說實話，在我做過的項目中，沒有編寫過此文檔，因為我覺得《需求分析說明書》和《詳細設計說明書》就足矣了。甚至如果項目簡單或時間緊急，《詳細設計說明書》都會省略：）。
《詳細設計說明書》：主要包含兩部分内容，其一，體系結構的設計，也就是項目所采用的幾層架構，以及層與層之間的通信機制，還有就是基礎架構所采用的技術；其二，是本文檔的核心部分，包括每個細分子產品的詳細設計說明，包括程式描述、功能、性能、輸入項、輸出項、算法、流程邏輯、接口、存儲配置設定、注釋設計、限制條件、測試計劃和尚未解決的問題等内容。本說明書對項目所采用的技術和接口都做了詳細的規定，是指導程式員開發的直接工具。但需要說明的是，很多項目由于時間原因，都忽略了此說明書的編寫，包括本人目前在做的項目也是如此，是以本文檔并不是必須的。但如果作為給客戶的傳遞物，需要在項目完成後補全。
《計劃進度》：這個不用多說，由項目經理編寫，實作對項目進度的嚴格把控，是項目必須的文檔，可用project編寫。
《測試用例》：測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟體産品進行測試任務的描述，展現測試方案、方法、技術和政策。内容包括測試目标、測試環境、輸入資料、測試步驟、預期結果、測試腳本等，并形成文檔。它是将軟體測試的行為活動做一個科學化的組織歸納．目的是能夠将軟體測試的行為轉化成可管理的模式；同時測試用例也是将測試具體量化的方法之一。由此可見，《測試用例》非常重要，是對項目或産品品質的嚴格保證，但由于測試人員和項目組的規範性、時間進度等限制，本文檔在本地區的實際項目中也很少應用，至少我認識的很多測試人員中，隻有極少數的項目中會編寫此文檔。
《測試結果》：在項目開發階段使用，也就是傳遞客戶之前。文檔為Excel格式，并提供關鍵字段的資料篩選，内容包括描述、缺陷類型（Bug、需求）、開發人員、狀态、關閉時間、所屬子產品、送出人、解決人、備注等。其中狀态包含送出、解決和确認解決，測試人員将問題送出（紅色），當程式員解決後就置為解決（黃色），測試人員再次确認無誤後，就修改狀态為确認解決（綠色），并且添寫關閉時間。
《需求變更文檔》：産品傳遞客戶之後使用。任何一個好軟體，不是在第一個版本就把這些标準全部實作，而是有步驟有重點地實作，逐漸成為一個好軟體。是以《需求變更文檔》是不必可少的，同樣作個Excel表格，量化解決。包括下列幾項：客戶名稱、需求提出人、提出日期、需求關閉時間，功能子產品名，客戶現在版本号，需求描述，需求分類（需求、Bug）等。每次釋出新版本都把從上一版本釋出之日關閉的需求清單都單獨摘成一個檔案，附帶到這次新釋出的版本之後。
此舉有兩個好處，其一，能夠清楚的列出客戶以往所提的需求，因為有一些客戶提出的改動總是反反複複，一個問題一會要改成A,然後覺得不好要改成B，之後覺得還不如A好，便又要求改回去，這樣給公司的進度和安排帶來很大的不便，如果因為這個耽誤了其他的工作，便可以有此根據和客戶進行溝通，防止客戶賴賬；其二，可以評判技術支援和相關程式員的工作量。此文檔為EXCEL格式，但最好還有一個word類型的文檔，每次客戶提出修改意見時，将此文檔列印出來交由客戶簽字，作為憑證，此方法實際中并不是次次可行，一些強權客戶或不敢承擔責任的就不簽字，那也沒轍。
《測試結果》和《需求變更文檔》要定期（可一周或一個月）給老闆一份。這表明了你的工作量，讓他看看你确實一直很辛苦地在工作，另外，也能看出你的認真負責态度。
《使用者使用手冊》：按标準說，應該由文案寫，但在大多數的軟體公司中都不設這個職位，是以要麼由項目經理寫要麼由測試人員寫，關鍵看是誰給客戶做教育訓練。在目前我做的這個項目中，并沒有專職測試，是以這個工作還是項目經理來做。《使用者使用手冊》可根據實際情況寫成三種版本，其一，chm類型檔案，适用于C/S的項目，就像微軟的産品中，都會有此幫助手冊；其二，做成網頁形式的幫助檔案，适用于B/S項目；其三，就是做成word文檔，雖然可儲存至本地，但使用起來沒有前二者友善。
餘者還有《開發任務書》、《項目總結報告》、《軟體驗收評審》等，并不是必須的，可根據客戶需要和實際的項目來選擇使用，再次并不一一贅述。
并且，以上所有文檔，雖然有些是必須的，比如《需求分析說明書》、《測試結果》、《使用者使用手冊》等，但根據不同的行業、不同的地區以及不同的項目和團隊規模，文檔的具體内容都會有所不同，不必較真。隻要能抓到老鼠，白貓黑貓都是好貓，況且，沒必要的多餘的文檔會浪費時間和成本等資源。
作者：lihui_79 來源：lihui_79的blog
<b>作者贊賞</b>
<a href="http://union.dangdang.com/transfer.php?from=P-262177&ad_type=10&sys_id=1&backurl=http%3A%2F%2Fbook.dangdang.com%2F">當當計算書籍 5-8折</a>
本文轉自Sam Lin部落格部落格園部落格，原文連結：http://www.cnblogs.com/samlin/archive/2009/07/27/1532131.html，如需轉載請自行聯系原作者
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)