|
在做了近四个多月的CMM翻译及文档整理资料工作后，为了验证CMM理论是否真正适合本部门的开发过程及引导提升的作用，最近参与一个项目的需求调研工作，这时候所处的角度就与原先处于开发人员的角度有所差异，此时，考虑的是如何在开发过程中加入CMM的KPA过程活动，在这个不大不小的项目中，在近一个多月的需求调研中，确确实实存在一些问题，值得我们开发人员去思考，这不仅仅涉及是否要按CMM要求去做，更涉及了如何做好需求，如何在需求调研中少走弯路，如何更能准确地制定需求；需求过程中的控制点、操作规程、协同运作等等。club.mypm.net
PgMp.mypm.net
分析阶段：“准备需求采集和分析”bbs.mypm.net
管理要求：项目管理者联盟
① 阅读有关行业/技术概念上的背景资料或相关标准、公文、规则等等PgMp.mypm.net
② 熟悉客户的操作流程项目管理论坛
③ 确定信息采集和分析的方法club.mypm.net
④ 确定用户组和评审组，及评审方式项目管理者联盟
⑤ 项目风险的评估项目管理者联盟文章
项目管理者联盟文章
大部分的需求调研中，以上的准备工作常常被忽略，在这次的操作中，虽然注意了该方面的运作，但还是出现了一些问题，影响了需求调研的工期。首先，确定信息采集和分析的方法，由于该系统是客户方的一个类似商务操作流的控制系统，在收集信息过程中，我们过于相信客户方最初提供的资料，在熟悉客户的流程后，依照客户方提供的资料进行项目的初步成本、工期、资源的核算。但是，在后面的调研时，客户业务流程发生较大的变动，细化点众多，功能点较原先估计的繁杂。出现这样的问题原因在于：1、客户原先手工操作无任何限制，而系统约束性较高。2、在需求调研中客户方发现其流程存在不合理的地方即产生变动，变动性大（该点我们无法控制）。3、与我们进行沟通的客户方人员无决策权。双方在讨论一个流程的实现过程中，对方无权对流程的简、繁进行决策，往往讨论半天实现该功能后，其部门经理一句话就推翻原先拟定的流程，在这点上浪费了许多时间，这也是我们准备过程中的一个失误，当初应该事先申明，沟通人员必须有一定的决策权（这是在确定用户组上的失策）。www.mypm.net
项目管理者联盟
当在熟悉、确定客户操作流程上，我们浪费了很多时间，至后来双方在沟通及决策上达成一定的协议后，后期的调研工作顺利很多，但最终产生的系统需求与原先客户提供的需求已经是截然不同的了，最终需求得出的成本、工期、使用资源都已翻了好几番。项目管理者联盟文章
项目管理者联盟
分析阶段：“收集和分辨需求”
管理要求：training.mypm.net
① 分辨技术（功能点）与非技术（交货日期、里程碑、协议条件等）需求项目管理者联盟
② 建立系统目标和范围training.mypm.net
③ 收集相关技术需求（功能点、约束、处理等）项目管理者联盟
④ 收集用户特殊需求www.mypm.net
⑤ 分析用户工作流程项目管理者联盟
⑦ 准备原型项目管理者联盟文章
该阶段工作较顺利，基本上按要求完成，其实该阶段与第一阶段―――“准备需求采集和分析”基本上可融合，故在双方按一定要求达成沟通协议后，在业务流程及功能点收集上进展较顺利，准确性也较高。转自项目管理者联盟
bbs.mypm.net
分析阶段：“分析—编写文档—评审”talent.mypm.net
根据收集到的功能需求，接下来，项目组各人分工进行模块功能需求的分析工作，按模块的操作角色、模块功能、输入、处理流程、输出等进行技术需求的细分析，该部分与编写文档同步进行。在进行分析及编写文档时，为了确定较准的最终功能需求，分析做得比较细，可以避免后期与客户的纠缠不清。分析时用UML画的业务流图在与客户沟通时发生一点问题，客户无法看懂其图内容，故建议以后项目内部沟通分析时采用UML用例图及流程图，与客户进行沟通时使用通用的流程图较方便。当各模块的分析文档完成时，单单模块功能就写了160多页，其中还不包括近五十张报表的分析数据。此时的功能需求与原先客户给的9页的需求已经大相径庭了。最终整合的需求依照“CMM系统需求规格说明书模板”进行编写，由于在每个模块分析时均注上标号，便于其后需求变更的跟踪及修改。club.mypm.net
项目管理者联盟
评审时准备采用CMM软件质量保证过程要求的“系统需求分析过程评审检查列表”，实际评审中与列表要求的还是会有一定的距离，标准度及执行度暂无法做到CMM完全要求的，只能尽量往其中的要求点靠拢了。其中“系统需求分析过程评审检查列表”的基本内容要求如下：项目管理者联盟文章
项目管理者联盟
____软件需求分析被记录在软件需求说明书或者其他经核准的正式文档中项目管理者联盟
____软件来源的明确性项目管理者联盟
____对于用户给定的需求，文档记录是否完整及有遗漏项项目管理者联盟
____软件需求在配置管理下维持（配置标识）blog.mypm.net
____文字说明清晰、适当项目管理者联盟
____前后一致，变更依据是否充分，是否有正常的记录项目管理者联盟
____功能的可测试性项目管理者联盟
____评估需求的可行性，是否适用于软件实现
____软件开发计划、工作产品，以及活动的变更与软件需求的变更相一致项目经理圈子
____验收被制定，并且使用来确定需求管理的状态blog.mypm.net
项目管理者联盟
在评审中，以上的要求可以起到一定的引导作用。项目管理者联盟
分析阶段：“交付验收”pmp.mypm.net
在交付给用户验收时，所需附上的产品有：各模块的功能分析文档、整合的需求规格说明书、需求验收文档。项目管理者联盟
管理要求：项目经理博客
① 客户对确定的需求无疑异，在验收文档上签字项目管理者联盟
② 若客户提出相应的变更，则为变更做好记录，修改后的变更依然应通过评审才能交付用户。项目管理者联盟
③ 客户签收的需求作为系统的需求基线确立下来，项目管理者联盟
分析阶段：“需求变更过程”项目管理者联盟
该过程主要针对确立需求基线后的变更。目前该项目还未涉及（待续！）项目管理者联盟
管理要求：项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
