SDLC涉及哪些文件？

Question

從估計到交付 - thoughout的軟件開發生命週期，

1. 所有文檔都參與和
2. 什麼順序？

我不確定方法是否對文檔有太大影響，無論如何讓我們考慮一下Waterfall。

Answer 1

答案是 - 如前所述 - 取決於。我相信很多人會回答的敏捷方法（這是一個更爲動產盛宴），所以爲了完整，我會跟你有什麼比較規範的瀑布方法去：

• 一個範圍文件 - 非常高的級別，概述什麼是和更重要的是哪些不在項目範圍內，以及正在做出什麼假設。本文檔的主要目的是設定對最終將提供的內容的期望 - 你不是在說事情會如何工作，而是在嘗試回答問題，比如是否會有報告？它會傳遞數據給其他系統嗎？您是否必須編寫自己的用戶管理功能或從AD中獲取？如果你無法得到這些東西的明確答案，那麼包括一個假設部分，並列出你正在假設的情況，以便人們可以糾正你，如果你錯了。它還應包括諸如目標實施日期等事項（不是作爲承諾，而是讓人們知道預期的事情並相應地管理預期）。
• 功能規範 - 應用程序應該在業務級別上做什麼。這可以分爲業務需求（業務流程的自動化以及它們的工作方式）和功能需求（系統的功能和操作方式 - 屏幕導航，計算方式等），但更常見的是除了最大的系統以外。它還應包括「非功能性」要求，如性能，負載，安全性等。
• A技術規格 - 最有可能被遺漏。一個詳細的技術設計，包括諸如對象模型，模式圖和關於如何解決詳細技術問題的信息。
• 測試計劃和測試腳本 - 應用程序如何使用詳細的測試用例，數據和預期結果進行測試，涵蓋系統的所有元素。
• 用戶指南和發行說明 - 如何安裝，配置和使用該應用程序。

我想添加到這樣一個支持文檔 - 在應用程序中所做的一個短（少於10頁）速成班以及如何做的。開發人員經常不會閱讀完整的規範（或者因爲他們沒有時間或不想），所以這個文檔應該足以讓他們理解它的功能，工作原理，應用領域最可能是有問題的等等。它將在建立和實施該系統的團隊上線幾周後寫出來。

當然，根據您的方法學，您可能沒有這些文檔，但如果您正在以舊式結構的瀑布方式運行標準項目，這將非常正常。

Answer 2

我將使用典型的諮詢答案......「它取決於」。

首先，方法學對文檔工件產生了巨大的影響（更不用說項目成功了），我會把瀑布式項目管理放在同一水平上，讓醫生用水蛭覆蓋我，腿。

話雖這麼說 - 我見過人們使用Microsoft解決方案框架，這裏是一個鏈接，你可以抓住他們的模板：

http://www.microsoft.com/downloads/details.aspx?FamilyID=9D2016AD-6F8A-47F5-84FA-BEC389DB18C1&displaylang=en&displaylang=en

在現實中，我會強烈建議任何項目使用敏捷方法和工程實踐（至少，如果你希望它比瀑布項目有更高的成功機會）。

http://www.agilealliance.com/有一些良好的閱讀，截至http://en.wikipedia.org/wiki/Agile_software_development

好運呢維基百科！

Answer 3

在典型的生產場景，這裏的發展不是在客戶端的位置進行，通常瀑SDLC的模型之後和有關WFM的各個階段的文檔編寫：

1. 需求收集 - 業務需求規範詳細說明了完整的需求。這在本質上是功能性的。這伴隨着用戶提供的測試用例場景，用戶在其中提到他們將執行所需功能的測試和測試用例。這也是開發團隊的指導原則，也是爲了構建功能和驗證的範圍。

2. 需求分析 - 在這個階段，與項目相關的BA開展影響分析和可行性分析。在需求，約束條件，假設條件中存在的限制都會被記錄下來，與業務用戶共享並簽名以避免任何進一步的意外。

3. 發展路徑 - 在這個階段，開發團隊領導或系統分析員編寫的做法文檔定義流程，屏幕設計，將被放置在屏幕上的控制，驗證，屬性，數據庫圖表，等等。然後與廣管局簽字。如果開發團隊預見到任何會影響所需功能的技術限制，則再次與業務團隊共享並簽名。
4. 測試 - 當用戶對發佈進行測試時，他們會根據之前提供的測試案例和測試場景驗證發佈。發現的缺陷被記錄併發送回開發團隊。缺陷首先由廣管局驗證，以確定是否在理解缺陷，功能需求失效或技術缺陷時報告缺陷。因此提供瞭解決方案。在此階段，要注意所有測試用例都已成功完成，並且所有錯誤都得到解決。如果任何測試案例或錯誤將被停放以便下一次運行，那麼基於它對功能的影響，開發團隊和業務用戶就所涉及的風險進行聯合調用。最後，業務用戶準備測試簽名文檔，提供每個資源用於測試，觀察和過程改進建議的時間。
5. 生產部署 - 這包括部署團隊，服務器和數據庫管理員可以結轉部署部署說明。

隨時提供您的建議。