二、《计划管理说明文档》:如果有完整的Porject计划是最好的,但此文档一定要注意的是其准确性,在用Project进行计划管理时,往往是项目进展时间越长,变更越多,计划维护就越困难,此时就有可能计划已经无法反应实际的项目进展情况了。计划管理文档一定要仔细研究,整个项目计划是否安排妥当,哪些任务制定了但没有完成,哪些任务取消了,这些取消的任务是否是属于预定的功能要求,哪些环节就没有进行,哪些环节多次重复,有哪些人员工作过程中发生了任务的中断变化,都可以从计划管理说明文档看出,这样更有利于评估项目的实际情况,风险情况,并可以根据前阶段未完善的内容进行后续完善。同时,很关键的一点是,这些任务中是否存在非正常情况,譬如:你认为很难的技术研发工作在短时间内却已经完成,这都需要注意,并了解实际情况。最终通过计划管理说明确文档定是否预定的目标已经全部完成。而已经完成的内容应该和以上提交的成果说明是一致的,此部分如果不存在文档,就需要根据相应的成果内容及人员对整个过程进行文档补充。此文档完成后,也可成为后续管理的一个基础,进行优化处理。
如果没有计划管理文档的话,补充的时候,则建议采用Project来完成,前一个成果提交文档,并且最好可以采用WBS来组织任务的安排,将已经提交的对应到相应的任务中。通过前一文档状态的说明,将未完成的内容做标记,并且看是否存在同样的任务不同的成果表现形式的情况,这时应该是属于重复性任务,也做标记说明。
三、《需求说明书》:需说明产品的最初需求内容实际对于我当前接手的这个产品,需求说明书的重要性已经大大降低了,因为产品已经研发完成,且提供了完整的用户手册,但整理需求说明书的主要目的还是有两个:
1、是要建立完整的项目过程追溯流程,为后续工作做准备。
2、通过需求验证成果的有效及可用性。
需求说明书是一个可简可繁的一个文档,在这个项目中,需求说明书更多的是从用户手册中来提取需求了,实际的意义并不是很大。但如果是做一个新的项目,则需求说明书应该是仅最大可能的对用户业务进行一种还原描述,不要掺杂个人的理解。至于是否可以实现,怎么实现是后续工作的事情,不是这个环节的内容。
四、《系统设计说明书》:系统设计说明书现在在这个时候已经无法在考虑设计的问题,但此时应该提供以下内容:
1、系统的架构设计及架构在应用过程的调整。并且最好可以提供架构的弊病分析说明。
2、接口设计说明及接口的详细规格及设计说明。现在的系统基本上都是松散的,通过接口标准从而最终实现系统的集成,所以,接口部分非常关键,这部分内容一定要非常清晰和准确。
3、如果现在无法再提供设计文档,则建议通过第三方工具,根据成果代码反项生成设计,并在此基础上进行文档补充,看设计总比看代码好很多,所以,这部分内容应该进行提供。如果在新项目中,此部分内容页建议考虑,主要是规划接口调用、对象职能及对象关系。
五、《数据库设计说明书》
我本人还是十分重视数据库设计的,虽然现在有很多的DAO的工具,而且也倡导对象建模,但实际在应用过程中,完全做到的却是少之又少,尤其是针对数据分析部分内容。所以此文档我认为还是非常重要的。至于文档的格式,因为此方面已经非常“标准”化了,就不在进行说明了。
责任编辑:张瑶