问SDLC涉及哪些文件？

EN

答案是--正如已经说过的--这取决于。我相信很多人都会对敏捷方法学负责(这是一场可移动得多的盛宴)，所以为了完整起见，我将按照您对一个相当标准的瀑布方法的要求：

• A范围文档-非常高级别概述了什么是什么，更重要的是什么不在项目范围内，以及正在进行什么假设。本文档的主要目的是设定最终将交付什么的期望--您不是在说事情将如何工作，而是试图回答诸如是否有报告之类的问题？它会把数据传递给其他系统吗？您需要编写自己的用户管理功能还是从AD中提取？如果你不能得到这些事情的确切答案，那就包括一个假设部分，列出你假设的情况，这样如果你错了，人们就可以纠正你。它还应该包括目标实现日期之类的内容(不是作为承诺，而是让人们知道预期的是什么，并管理预期、accordingly).
• A功能规范、--应用程序应该在业务级别上做什么。这可以分为业务需求(它正在自动化的业务流程及其工作方式)和功能需求(系统所做的以及如何进行屏幕导航、计算等)，但更常见的是，除了最大的系统之外，它们是结合在一起的。它还应该包括“非功能性”需求，如性能、负载、安全性等on.
• A技术规范--这是最有可能被遗漏的。详细的技术设计，包括对象模型、模式图和关于addressed.
• Test计划和测试脚本中详细技术问题的信息--如何使用详细的测试用例、数据和预期结果测试应用程序，包括system.
• User指南和发布Notes的所有元素--如何安装、配置和使用application.

我要添加的是，一个支持文档--这是一个简短(不到10页)的速成课程，内容包括应用程序的功能以及它是如何做到的。开发人员通常不会阅读完整的规范(要么是因为他们没有时间，要么是不想读)，所以这个文档应该足够让他们了解它是如何工作的，它是如何工作的，应用程序中最有可能出现问题的区域等等。它将在运行几周后由建立和实施该系统的团队编写。

当然，根据您的方法，您可能没有这些文档，但如果您正在运行一个标准项目的老学校结构，瀑布式的方式，这将是相当正常的。

我会用典型的咨询答案..。“视情况而定”。

首先，方法学对文档工件(更不用说项目的成功)有很大的影响，我会将瀑布式的项目管理放在与允许我的医生用水蛭覆盖我来治疗腿骨折的水平相同的水平上。

话虽如此，我已经看到人们使用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也是如此。

祝好运!

在一个典型的生产场景中，开发不是在客户端进行的，通常遵循SDLC的瀑布模型，并编写与WFM各个阶段相关的文档：

1. 需求收集-详细描述完整需求的业务需求规范。这在本质上是功能性的。这伴随着用户提供的测试用例场景，在这些场景中，用户提到了他们将实现所需功能的测试和测试用例。这也是开发团队构建功能和验证范围的指南。
2. 需求分析--在此阶段，与项目相关的BA进行了影响分析和可行性分析。如果需求、约束、假设中有任何限制，则记录在案，与业务用户共享并签署，以避免任何进一步的意外。
3. 开发方法--在此阶段，开发团队领导或系统分析人员准备一个方法文档，该文档定义流程流程、屏幕设计、将放在屏幕上的控件、验证、属性、数据库关系图等。然后与BA签署。如果开发团队预见到将影响所需功能的任何技术约束，则再次与业务团队共享并签署。
4. 测试-当用户在发行版上进行测试时，他们根据前面提供的测试用例和测试场景验证发布。发现的缺陷被记录下来并送回开发团队。首先由BA对缺陷进行验证，以确定在“理解缺陷”、“功能需求缺陷”或“技术缺陷”中报告的缺陷。因此，提出了解决办法。在这个阶段，要注意的是，所有的测试用例都被成功地完成，所有的错误都被解决了。如果要将任何测试用例或bug停在下一次运行，那么根据它对功能的影响，开发团队和业务用户将联合调用所涉及的风险。最后，业务用户准备测试注册文档，其中他们提到了每个资源用于测试、观察和过程改进建议所花费的时间。
5. 产品部署--这包括部署团队、服务器和数据库管理员进行部署的部署说明。

请随时提供你的建议。