Project management SDLC涉及哪些文件？

从评估到交付-考虑软件开发生命周期

涉及的所有文件以及

点什么菜

---

我不确定方法论是否对文档有很大影响，不管怎样，让我们来考虑一下瀑布。

< P>我会用典型的咨询答案……看情况而定

首先，方法论对文档工件有着巨大的影响（更不用说项目成功了），我将瀑布式项目管理放在与允许我的医生用水蛭覆盖我治疗断腿相同的水平上

话虽如此，我看到人们使用Microsoft解决方案框架，这里有一个链接，您可以从中获取他们的模板：

实际上，我强烈建议任何项目使用敏捷方法和工程实践（至少，如果您希望它比瀑布式项目有更高的成功机会的话）

有一些很好的阅读，就像维基百科在

---

祝你好运

答案是——正如前面所说的那样——这要看情况而定。我相信很多人都会对敏捷方法论负责（这是一个更具流动性的盛宴），因此为了完整性，我将采用您认为相当标准的瀑布式方法论：

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

我想在此添加的是一个支持文档——一个简短（少于10页）的速成课程，介绍应用程序的功能以及如何实现。开发人员通常不会阅读完整的规范（因为他们没有时间或不想阅读），因此本文档应足以让他们了解它的功能、工作方式、应用程序中最有可能出现问题的领域等等。它将由构建和实施该系统的团队在上线几周后编写

---

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

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

需求收集-详细说明完整需求的业务需求规范。这是功能性的。这伴随着用户提供的测试用例场景，其中用户提到了他们将对所需功能执行的测试和测试用例。这可以作为开发团队构建功能和验证范围的指南

需求分析-在此阶段，与项目相关的BA进行了影响分析和可行性分析。需求、约束和假设中的限制（如果有）被记录下来，与业务用户共享并签署，以避免任何进一步的意外

开发方法-在此阶段，开发团队负责人或系统分析员准备一份方法文档，该文档定义了流程、屏幕设计、屏幕上的控件、验证、属性、数据库图等。然后与BA签署。如果开发团队预见到任何会影响所需功能的技术约束，那么将再次与业务团队共享这些约束并签署

测试-当用户对发布进行测试时，他们会根据前面提供的测试用例和测试场景验证发布。发现的缺陷被记录下来并发送回开发团队。BA首先对缺陷进行验证，以确定在理解缺陷、功能需求失效或技术缺陷时报告的缺陷。因此，提供了解决方案。在这个阶段，要注意所有的测试用例都成功完成，所有的bug都得到解决。如果有任何测试用例或bug将在下一次运行时停止，那么根据它对功能的影响，进行联合调用