|
3 、据流向是否清晰，模块之间的数据关联设计是否合理。blog.mypm.net
4、预计的开发时间是否合理，是否满足项目的整体开发周期要求。项目管理者联盟
评审完毕后，各自根据修改意见下去调整规格书。如此反复几个回合，确定了功能规格书作为了项目的标杆。这个时候，项目组的所有成员〔包括测试〕都统一了对 项目的认识，规格书进入了冻结阶段，任何人无法修改。接下来，开发人员开始按照规格书中的设计进行编码，测试人员开始根据规格书编写测试用例。项目管理者联盟
编写功能规格书〔其实是设计的过程〕是一项繁复的工作，尤其是进入项目实施阶段。用户的需求变更会不可避免的导致系统与规格书的不同步。按照正规的流程， 变更首先会导致设计的变更〔规格书〕，设计的变更指导代码的变更。但实际上，项目进入实施阶段后，留给项目组处理反馈的时间往往并不多，再者，一些细微的 调整〔比如界面的改动，控件的初始值〕如果遵循正规的流程会使开发人员怨声载道，士气低下。因此，我采用了折中的方法：第一次设计一气呵成，必须保证实际 运行的系统与设计同步。这一点由测试部负责监控。系统上线后，同步的工作可以专门抽个时间来完成。即，前期是系统参照规格书开发，后期是规格书参照系统来 同步。在频繁的修改下必须保证一周内至少同步一次，并且将文档提交给测试部检查，出现问题，以bug论处。那有朋友会问，既然规格书在后期失去了标杆的作 用，那还费时费劲的同步它有何意义?项目经理圈子
1、对项目后期维护起至关重要作用，完整的设计文档在加上良好的代码注释，会让维护人员迅速的进入项目状态。
2、让新进入项目组的成员能尽快的对项目有整体的印象，从而担任工作。另外还可以减少项目培训的成本。项目管理者联盟
然而，后期的同步又引发了另一个棘手问题：测试人员对需求变更的测试标准从哪里获取呢?于是我们又做了改进，当需求变更到项目组手里后，召开会议，测试人 员参加。会议上，对小的、简单的修改当即提出解决方案，测试人员记录，以此作为测试依据。对于大的改动〔有可能会增加功能模块〕，则还是采用先设计后开发 的原则。项目经理博客
八、 《详细设计报说明》项目管理者联盟文章
作为《功能规格书》的一份补充文档，主要解决如何编码的问题，测试人员一般不看。开发人员在编码之前或编码过程中如果遇到了复杂的算、业务逻辑，可以在该文档中详细的说明解决思路，也可以用一段伪代码来说明。项目管理者联盟
九、《数据库设计报告》项目管理者联盟
该文档与《功能规格书》配套。规格书中关于数据库设计的说明直接引用该文档。另外，项目验收时，客户也常要求开发方提供数据库设计报告，作为日后其他系统与本系统做接口的依据说明。项目管理者联盟
《数据库设计报告》记录的内容有：模块名，数据表名，英文字段名，中文说明，主键，外键，索引，约束〔注明关联的表及字段〕，数据类型，长度，能否为空以 及对整张数据表的备注信息。对于某些关键字段还要对他的值所表示的含义做详细说明。另外，《数据库设计报告》也会面临后期同步的棘手问题，其同步的策略是 做了修改就立即同步〔数据库的改动较少，且简单。这一点与规格书还有所不同〕。club.mypm.net
数据库设计报告的评审与规格书相同，评审依据有如下几点：项目管理者联盟
1、是否留有适当的冗余便于系统的扩展。项目管理者联盟
2、性能是否能达标。索引是否合理。项目管理者联盟
3、数据字段描述是否清晰易懂。项目管理者联盟
评审通过的数据库设计报告交给测试一份，测试人员会针对具有特殊性能要求的模块编写脚本做压力测试项目管理者联盟
十、《uml设计说明》项目管理者联盟
这个文档不常用，我一般会在两种情况下要求项目做业务模型设计：项目管理者联盟
1、 业务相当复杂的时候。项目管理者联盟
功能规格书更多的是从模块界面，操作方式上去阐述模块的功能，至于底层的数据模型还得用uml图来辅助说明。uml图有很多种，我们一般也只常用几种，包括：用例图，类图，时序图，其中类图又最为重要。项目经理圈子
2、 对原有系统进行重构的时候。项目管理者联盟
原有系统由于种种原因〔业务了解不透，工期紧张，人员能力不具备〕在做开发之前没有对复杂的业务进行模型设计，开发出来的系统虽然能用，但漏洞百出，开发 人员时常处于救火的状态。随着时间推移，开发人员对业务有了更深入的了解，慢慢的不满足在现有的代码基础上修补，产生了强烈的重构的愿望。就这样，再作第 二个类似系统的时候，很自然的就操起uml工具对现有的代码进行重构。项目管理者联盟
有很多的朋友不理解为什么要建模，直接用代码说话不是更好么?我举个项目中的例子：我曾经带队实施过一个有2000人企业的信息管理系统， 有14个子系统，600来个功能模块。其中有一个物资子系统，做过类似项目的朋友应该知道，物资子系统流程复杂还要嵌套〔大流程中嵌套小流程〕，模块众 多。刚开始没有进行业务建模，功能规格书设计完毕后，直接数据库设计报告，然后上手编码。整个子系统设计花了2人月，编码用了4人月。等进入到测试阶段 后，bug满天飞，真是按下葫芦起来瓢，原定与1个月的稳定期最后又延迟了1个月才总算表面上稳定下来。在客户那里上线后，需求一旦发生变更，开发人员就 心惊胆颤，生怕出现牵一发而动全身。究其根本原因就是在面对如此复杂的业务系统面前，没有用建模的手段将业务逻辑的全局勾勒出来，每个人只关注自己的一 块，导致数据的交互出了很多的问题。最后，在项目总结会上，大家一致认为下一个物资系统，要想办法从根本上解决这些问题。结果，下一个物资系统，我们做了 充分的设计，用uml对业务建模，使每个开发人员既能清晰的看到业务的整体轮廓，又能深入细致的了解到每个类之间的交互以及提供的接口。这样开发出来的系 统才有底气，面对客户的需求变更我们也能知道动哪个位置、影响到哪个地方，做到心中有数。项目管理者联盟
所以，在以后的项目里，只要是碰见业务复杂的系统，都会要求进行建模。多花些功夫在前面，后面肯才不会被拖累。项目管理论坛
|
