project-management - SDLC涉及哪些文件？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

2年前关闭。




Improve this question




从估算到交付 - 在整个软件开发生命周期中，

其中涉及的所有文件和

顺序是什么？

我不确定方法论是否对文档有很大影响，无论如何让我们考虑瀑布。

Answer 1

答案是——正如已经说过的——这取决于。我相信很多人会回答敏捷方法论(这是一个更可移动的盛宴)，所以为了完整起见，我将采用你所拥有的相当标准的瀑布方法论:

范围文档 - 非常高级地概述了项目范围内的内容以及更重要的内容，以及正在做出的假设。本文档的主要目的是设定对最终交付内容的期望——您不是在说事情将如何运作，而是试图回答诸如是否会有报告之类的问题？它会将数据传递给其他系统吗？您是否必须编写自己的用户管理功能或从 AD 中提取？如果您无法对这些事情得到明确的答案，那么请在假设部分中列出您所假设的情况，以便在您错的时候人们可以纠正您。它还应该包括诸如目标实现日期之类的内容(不是作为 promise ，而是让人们知道预期的内容并相应地管理预期)。

功能规范 - 应用程序应该在业务级别上做什么。这可以分为业务需求(它自动化的业务流程及其工作方式)和功能需求(系统做什么以及如何做 - 屏幕导航、如何进行计算等)，但更常见的是它们是除了最大的系统。它还应包括“非功能性”要求，例如性能、负载、安全性等。

技术规范 - 最有可能被错过。详细的技术设计，包括对象模型、模式图和有关如何解决详细技术问题的信息。

测试计划和测试脚本 - 如何使用详细的测试用例、数据和预期结果测试应用程序，涵盖系统的所有元素。

用户指南和发行说明 - 如何安装、配置和使用应用程序。

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

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