开发组织现状评估报告
——威海海源网络信息有限公司软件研发部
一、评估依据
✓使用代码分析软件对已有3个项目的源码进行统计
✓组织项目组成员填写现状调查表
✓组织项目组成员完成OOAD测验
✓与项目经理、开发人员的访谈
✓抽查项目组已有的文档
二、项目抽样统计结果分析
威海电业局请假管理系统项目
威海供电公司生产MIS系统项目
诸城电业局计划管理系统项目
三、现状调查表统计
调查问
题序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 张媛 B C B C B A C C A A D C C C C C C B 卢媛 B B B B A A B C B A C B B A B C C B
袁金辉 B B C B A B B A C B A A B A B A C B
陈永祝 B C C C B B A C A B D B C C C D D C
陈正 A C B B A A B B A B D B B D D C C B
冷小洁 A B B C A B A C A B B B B A D D C C
马萍 C C B B A B C C A A B A C B B C C C
杨萍 A B B C A A B B A B D B C A C C D B
张小清 B C C C B A B C A B D B C B B C C C
李美红 A B C C A A C D A A B B C B A D C C
平均得
分（％）694548428178573981693063426042272445四、OOAD测验结果统计
五、被访谈人员
项目经理：张媛、李美红
开发人员：陈永祝、杨萍、和婷
六、CMMI关键过程域评分与说明
过程管理域
评分：
结论——已经认识到过程规范化的重要性，但过程意识、相关的投入还很欠缺
不足：
没有分工协作，难以凸显团队的优势
✓项目组各成员没有明确的角色定义，组员对自己到底要从事哪些具体的工作不清
楚
✓目前项目组的开发模式是：每个人分配一个功能模块，他负责这个模块相关的几乎所有开发工作，包括需求、分析、设计和编码，乃至测试
✓在现有开发模式下，开发人员必须掌握需求、分析、设计和编码，乃至测试的所有相关技能，而现实状况是，他们普遍缺乏编程之外开发技能
✓开发人员虽然也认为规范化的开发途径很好，但是现有模式下，需求、编码都是自己一个人做，因此花费时间描述一个用例好像有点儿多此一举✓大家都认为当前的开发不规范
✓因为缺少统一的规范，造成沟通和理解上产生偏差，例如，需求表达不规范，造成开发人员和客户对需求的理解不一致
✓软件组织没有一个统一的开发过程规范，虽然参照ISO9000做过一些文档，但并没有形成系统的开发流程
✓软件组织有一定的培训活动，但没有明确的计划，也没有形成一种制度
✓公司没有帮助员工制定长远的职业发展规划，开发人员不能有计划地不断改进自己的技能
✓项目经理虽然对整个项目的运作有大概的思路，对局部的一些问题都有一些解决对策，但还是缺乏通盘的考虑，对开发过程的具体步骤认识模糊
项目管理域
评分：
工作的计划性计划执行的控制力度计划的可行性
634260
结论——项目有计划，但不细致，执行的监控力度有待加强
不足：
管理不到位，项目一直处在高风险的状态下
✓目前，项目经理本人在管理方面投入的时间并不多，更多是参与那些困难或重要的需求、设计和编码活动
✓管理的缺位，使得项目组各成员的工作不够协调一致，不能将每个人的能力都充分发挥出来
✓项目经理对组员的情况都比较了解，但并不能在任务分配中真正做到“扬长避短”
（没有细致的分工，任务分配时可选择的余地很小）
✓项目经理做的计划常常受外界因素的左右而被打乱
✓项目组没有列出项目当前的十大风险列表，风险管理的意识比较薄弱
✓项目经理的管理活动应当更加细化
✓项目经理在周例会上向领导汇报进度，除此之外，缺少其它的渠道让领导了解项目的实时状况
优势：
✓项目组成员沟通比较顺畅，项目经理得到组员的信任
✓项目经理了解自己组员的基本状况，能够较为合理地安排组员的工作，而且被组员所接受
✓项目组成员都很敬业
软件工程域
评分：
需求被贯彻的力度需求的质量需求被文档化的程
度需求的一致性
69454842
设计活动的质量测试活动的质量
4227
结论——需求开发质量不高，需求管理还很欠缺；设计已经开始引入，但质量有待提升；测试由开发人员承担，不能起到测试的应有作用
不足：
没有掌握正确和有效的开发方法
✓开发人员特别对需求的获取和描述感觉到很困惑，与客户的沟通有困难，不容易理清客户的问题，往往在开发完成之后才发现对客户的要求理解有偏差✓项目组成员缺乏编程之外的相关开发技能，对需求、分析设计等工作经验不足
✓项目组没有专门的测试人员，而每个开发人员的测试能力并不专业
✓自己的测试不充分，而且不能象最终用户那样来考察我们的软件，结果有30％的Bug被遗留到发布给客户的版本中，并由用户来发现，客户对我们的意见很大✓开发人员各自负责自己那块的测试，结果测试活动支离破碎，没有统一的指标来指导我们何时能发布软件给客户
✓开发人员在工期的巨大压力之下，普遍对代码的质量有所忽视
✓需求变更频繁，给我们造成极大困扰
✓项目中使用的基础框架，在设置时还是比较复杂
✓需求规格感觉不够细致，缺少很多细节的描述
✓数据库的表结构通常与客户的报表直接相对应，表设计过于简单化
✓代码的注释普遍写得不到位，一旦要修改和维护代码，特别是由另外的人修改时，感觉比较费劲
✓代码中常常使用立即数，比如一些逻辑判断，直接用中文字符串，而非枚举类型，一旦要更改那些状态值，会牵涉到多处
✓根据OOAD的测试结果，项目组在面向对象的开发技能方面还有差距
优势：
✓项目有个统一的基础框架，我们在此基础上来构建系统，重复的工作被大幅减少✓项目中使用了统一的模板控件，代码的维护比较容易
支持过程域
评分：
统一工件的组织配置管理支持发布配置管理的质量配置审计的应用
81785739
并行开发的支持配置管理的实施广度变更控制
81 69 30
质量保证中的度量质量保证机构
2445
结论——配置管理使用了VSS工具，并开始推广应用，但变更控制很不到位；没有建立最起码的质量保证机制
不足：
没有质量保证机制，没有人来对软件质量和规范的执行把关
因为没有建立变更控制制度，客户直接向具体负责的开发人员提出变更，开发人员会马上处理，造成项目组后期常常出现混乱，会出现别人的修改引起自己的功能出错的情况。