肖永威的专栏

针对CMMI2.0评估，整理配置管理的工作内容，以及项目实践等内容。

针对CMMI2.0评估，整理配置管理的工作流程及相关工作内容的，包括配置项识别、配置计划、变更管理、配置审计、配置工具使用，以及持续改进等内容。

客串配置组织级管理员，系统的实践配置管理及其工具gitlab过程笔记。

基于采油生产案例，使用EA工具，设计数据流图。

使用EA工具，编写用例规约。

EA使用入门之活动图实践。

通过油田采油生产业务建模，介绍使用EA工具画用例图。

本文实际项目为例，通过分析工作量、人力资源、风险与问题跟踪，总结出项目采购成本增加的原因，并总结经验教训。

本文描述集成测试的测试计划、测试活动过程、测试用例及执行等三部分内容实践，每部分仅举例部分实际内容供参考，以及相关测试规范。文中推荐使用UML时序图做为测试用例中测试步骤描述。

本文介绍在EA工具中，从最初的用例延续下来，先设计类及其方法，再设计时序图过程，以及时序图分层设计方法。

在项目前期及需求分析阶段，开发人员致力于“降低成本”，以最小的代价完成项目，其可预见性的软件产品是经过系统平台升级的，并经过改良的第二个办公业务流程管理平台。按客户验收要求，“只能打60分，是不能给予验收”。 在软件开发中，需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题。二者不能相互取代。如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解得到重复代码。如果从设计出发找需求，会得到一大堆假的“需求”。

本文重点是业务建模实践，以及建模工具EA初级使用过程日志。先前写了些文档，从不同角度描述了业务建模，但是条理性和规范性仍无法让人一目了然。春节期间当我再次读了《软件方法》前几章，产生了共鸣：误解随处都在，通过UML规范沟通环境，是辛勤汗水的教训。

最关键的一点：缺乏稳定的开发团队，特别是在信息技术快速发展的今天，松散、临时组建的团队，缺乏沟通上下文环境，沟通成本、时间成本、返工成本的产生，是必然的。

在可能技术方案选择决策分析过程中，如果项目经理认为技术方案整体相差不大时，可以通过此方法，尊重技术人员的选择，做其喜好的，对项目更有利。如果项目经理有足够的资源，那么可能是另种结果，何况没有资源呢！        （1）评估结果        方案一：86.17，方案二：87.08，方案三：80.25        基于此评估结果，选择方案二，也就是整合JavaEE平台到系统中，提供系统前端开发技术能力。        （2）分析结果        通过得分来看

在项目实施过程中，技术方案选型往往是比较揪心的一个过程，需要在满足需求、技术先进性、成熟度、成本、人力、工期等方面进行平衡，而且这些方案是项目干系人和项目组成员在头脑风暴会议经上，通过快速互动、刺激提出有创意的备选技术解决方案。每个方案都有意义，或者说，多数的方案都是能解决问题，只是成本、时间、人力等纬度的目标一致性需要统一衡量。 所以提出方案的人，都会认为自己的方案比较优，这样矛盾就产生了，需要一套决策分析管理过程来决策选择哪个方案。

项目监督与控制(PMC)是CMMI 2级中项目管理过程内容，使用的比较普遍，但能成为一套管理体系的还是比较难的，本文记录实践过程中主要内容和样式，供相互交流、学习使用。

续：软件项目量化管理（CMMI高成熟度）实践经验谈——之概述篇

1 AC或ACWP：    已经完成工作量的实际成本。Actual Costof WorkPerformed，已完成工作的实际成本——实际成本（工作量），显示到项目状态日期或当前日期为止，与某任务的已完成工作所对应的实际成本。2 BAC：    完成预算3 Baseline：   配置管理术语，基线。基线包括如下属性：    1）是一系列工作产品的集合；    2）是项目最

虽然从事软件项目管理工作多年，但一直不得要领，没有多少感悟。今年，有机会参与CMM5，我带的项目作为试点项目，经过一段时间的磨练，终于有所突破领悟，融汇贯通了点。   工作量估算方法很多，我常用的是功能点、Delphi估算法，用法上也无啥问题，关键是用的较麻烦，而且估算算结果只能用作项目成本和人力估算上，与进度计划关联不紧密。   进度计划，我从2002年就开始使用Project工

本文整理本人近些年来关于软件项目管理经验、CMMI5学习与应用实践博客集锦，方便分享与交流讨论。