优化方案的格式及范文项目优化方案怎么写( 四 )

在项目的前续几个版本中，对该复杂度的估算也不是很理想，很多时候只能倒推的方式来进行估算，为了进一步估算准确，从V2.2版本开始项目关注与各个版本的复盘和历史数据的收集，争取找到需求页数，用例数，流总数，业务对象数，数据库设计字段数，界面元素各数，工作量，代码行这些因子的关系，收集数据如下：
通过对这些采集数据的关联性分析，基本得到的可以借鉴的经验数据如下：
用例复杂度可以和用户需求建立一定的对应关系，关系可以体现到页数，如果更细化一点可以体现到用户需求中的输入输出列表和数据项，但要求用户需求足够细化。
用户需求中可以看到的是处理，而处理更多的是体现业务规则，原有估算中把业务规则的一个流和基本流扩展流等同看待有问题，这里根据项目经验提出业务规则对用例复杂度的影响权重应该加大， 3-5个业务规则复杂度应该到2 ， 5-10个业务规则复杂度应该为3或4,对于出现超过10个业务规则的用例必须进行子用例的拆分。这样在用户需求写得较好情况下很容易根据用户需求判定出用例的复杂度。
对于设计界面操作的用户需求，当其用户需求说明书涉及到的输入输出项超过20的时候要考虑增加估算用例的复杂度，在这里数据项再每增加10个用例复杂度加1 。
在项目大版本，而且刚开始用户需求说明书不够详细的情况下，在软件需求完成后必须进行第二次估算，这点在项目 V4.0版本中按此规则进行，由于软需已经完成，需求和设计人员都可以较为准确地估算出用例的规模和复杂度。确立该规则的一个重要原因在于需求和设计开发工作量比一般为1:5 ，说明需求阶段2天的工作量偏差反映到设计开发阶段将是10天的工作量偏差，这个工期偏差对项目来说往往是致命的打击。
所以工作量比例分布仅仅是经验数据，很多时候不能完全地不加分析地采用，更多的时候还需要考虑到设计开发工作的实际情况和特殊性。在项目项目中第二次估算时估计出设计开发总量后，项目经理都通知到各大功能的设计负责人对功能进行功能点的细分，并对该模块的开发进度进行细排，细排后发现保存和载入默认值这块有一周的工作量，但体现到需求文档仅仅是一句话；对于部件的版本控制需要考虑抽象和复用出公用的版本控制服务，但前期作软件需求的时候这个公用服务根本没有需求用例对应，根据这些情况，项目经理进一步对进度计划进行了细化并增加了一个人力资源投入。
确定了估算的规模后，另外一个重点要确认的就是项目的生产率和工作量比例的分布，需求阶段的生产率经过多个版本的积累已经较稳定在0.8到1之间，但设计开发的生产率由于项目成员的变动导致不稳定， V4.0版本项目有三名新员工参加，因此需求与设计开发的比例数据不能够完全采用上个版本的复盘数据，在这里项目稍微做了调整，将需求与设计开发的比例调整到1:5左右，以使设计开发的工作量适当增加。
如果一直停留在估计需求规模层次上，估算准确度是很难提高的，而且项目也迫切地需求了解到代码行的生产效率情况，每个人在设计开发阶段的工作量的实际分布情况，因此在V4.0版本，决定在南京项目组推广个体软件过程，并引入了PSP Studio工具对过程数据进行了准确记录，如下：

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：

优化方案的格式及范文 项目优化方案怎么写( 四 )

优化方案的格式及范文项目优化方案怎么写( 四 )