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. 生产部署 - 这包括部署团队，服务器和数据库管理员可以结转部署部署说明。

随时提供您的建议。