当前位置:  开发笔记 > 程序员 > 正文

项目文件?

如何解决《项目文件?》经验,为你挑选了1个好方法。

我为CMMI 5级认证公司工作,我讨厌的一件事是我们准备的文件数量(作为程序员,我已经讨厌过文件).我们有很多很多文件,比如PID(项目启动文档),业务需求,系统需求,技术规范,代码审查清单,问题日志,缺陷日志,配置管理计划,配置管理检查表,发布文档和批次...

这些文档中有近90%只是为了QA审计而完成:) ..您认为项目最重要的文档是什么?从长远来看,其他开发人员可以使用哪些文档?

请在此分享您的良好做法.我想将它们用于我自己的项目或我计划从长远来看的公司.

谢谢



1> ConcernedOfT..:

关键文件是一个很好的功能规范. 系统应该只有一个参考文档.

每当有人更改系统或界面时,过度使用的文档会增加大量的小需求和规范文档.对于任何复杂的系统,不久你就可以将你的规范分布在几百个单词,excel,visio甚至powerpoint文件中.当发生这种情况时,您会对当前的内容或甚至是否找到并确定所有相关文档都不清楚.

BRD-SRD-Tech规范进展是基于业务签署BRD的假设,业务分析师根据BRD中记录的要求签署SRD并且技术规范与SRD签署.这会生成一个签名网络,多个包含冗余信息的文档,并使规范文档保持最新变得困难和笨拙.

因此,后续需求文档往往采取一系列变更请求和补充要求以及规范文档的形式,每个都有自己的签名和审计流程.您获得了CYA和审计跟踪(或至少是审计跟踪的外观),但您失去了清晰度.现在没有关于该系统的明确参考文件,并且很难确定任何特定活动的当前或相关内容.最终结果是您的业务分析过程陷入了法医研究的困境,这增加了交付计划的开销和延迟.

应该以这样的方式构建规范文档,即对任何给定的系统或子系统都有一个明确的引用.该文件应保持最新和版本.获得一个很好的技术文档工具,如Framemaker,因此您的流程可以扩展,并且文档具有一些缺乏Word的结构完整性.

推荐阅读
mobiledu2402851373
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有