SDLC涉及哪些文件？

Question

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

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

Answer 1

答案是 - 如前所述 - 取决于.我相信很多人会回答敏捷方法论(这是一个更加可移动的盛宴),所以为了完整性,我会选择你所拥有的相当标准的瀑布式方法:

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

我要添加的是一份支持文档 - 一个简短的(少于10页)速成课程,介绍应用程序的功能及其运行方式.开发人员通常不会阅读完整的规范(因为他们没有时间或不想),所以这份文档应该足以让他们了解它的作用,工作原理,应用领域最有可能出现问题,等等.它将在建立并实施该系统的团队上线几周后编写.

当然,根据您的方法,您可能没有这些文件,但如果您在旧式学校运行标准项目,结构化,瀑布方式,这将是非常正常的.