2013项目管理说明.docVIP

1 　引言 随着软件产品规模增大、生命周期时间延长、产品开发团队扩大和环境复杂化,软件业对配置管理在保证产品及其开发过程的标识和可追溯性方面具有的重要意义已形成了共识。但是,实用中仍然会令人感到配置管理工作影响效率,有些活动做起来僵化笨拙,做过了得不偿失。较常被引用的配置管理定义是Babich W提出的“协调软件开发以减少不理解性到最小程度的技术称为配置管理。配置管理是对正在被一个项目组建造的软件的修改标识、组织和控制的技术,其目标是通过最大限度地减少错误来最大限度地提高生产率” 。按照软件工程术语的国家标准,配置管理是“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征,控制这些特征的变更,记录和报告变更处理和实现状态并验证与规定需求的遵循性”。按照SW2CMM 的软件配置管理关键过程域:“软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整性”。要求的四个目标( Goal) 是: (1)软件配置管理活动是有计划的; (2) 所选定的软件工作产品是已标识的、受控的和适用的; (3) 对已标识的软件工作产品的更改是受控的; (4) 受影响的组和个人得到软件基线的状态和内容的通知 。?? 按照CMMI 模型中的配置管理过程域:“‘配置管理’过程的目的在于运用配置标识、配置控制、配置状态统计和配置审核,建立和维护工作产品的完整性”。要求的三个特定目标是: (1) 建立基线; (2) 跟踪并控制变更; (3) 建立完整性 。综合以上的说法,配置管理的目的是“建立和维护工作产品的完整性”;基本活动是“配置标识、配置控制、配置状态统计和配置审核”,以及相关的制订配置管理计划、配置状态报告等活动。经典的定义、标准、模型可以视为业界标准的软件过程,从业界标准软件过程到组织标准软件过程,再到项目定义软件过程有相当长的路要走。标准的软件过程模型要与具体组织、项目的特点相结合“, 工作产品的完整性”需要具体规定。否则,可能出现从方法、过程层面看起来配置管理的基本活动都做到了,但所做活动与业务目标不协调、与约束条件不一致,不清楚活动该做到什么程度,做起来事倍功半、流于形式,仍然不能保证产品的完整性,难以收到实效。为了使配置管理活动有效、适宜、充分地支持软件业务活动,可以先从引起配置管理问题的深层原因即混乱源开始分析,再研究不同层次的“完整性”及其相关的主要活动和能力、资源等约束,最后提出一组实用、有效配置管理的原则和策略。 2 　配置管理失效的深层次原因?? 在配置管理中,简单层次的原因包括缺乏基本的版本记录、缺乏基本的变更控制、缺乏配置状态审计及沟通不畅等。解决简单层次的难题也需要做认真工作,但一般只要认真去做就不难做到。真正把配置管理做到既完整、有序又提高效率则很不容易,除了对配置管理的一般目标、实践要有足够理解外,还与组织的业务流程、技术及管理能力密切相关,仅靠配置管理过程难以消除复杂、深层次的原因(混乱源) 。2. 1 　多版本、多分支?? 许多软件产品是以演进式发布版本方式开发的,面向多个客户的产品更可能增加工作产品的版本数,需要同时管理多个版本。从根源上减少多版本、多分支的问题,需要在产品策划时就考虑好版本演进策略,把握好顾客定位、顾客核心需求及自己产品核心功能的能力,以及与顾客沟通(识别及引导用户) 的能力。在技术上要有实现版本向前兼容的能力,合并多版本、多分支的工件。2. 2 　频繁、重大变更?? 由于顾客沟通不畅、需求开发不完整、业务能力不足,以及产品、需求本身复杂等原因,在软件设计和开发的生命周期中可能频繁发生变更。频繁、重大变更会引起可观的配置管理工作量,如果要执行严格的配置管理策略,则流程笨拙、响应速度慢、管理成本高;如果放松配置管理,则变更环境太宽松,可能更加加剧变更的频度及变更申请的随意性。根本上解决频繁、重大变更本身不是配置管理的直接任务,需要提高整体的管理、业务能力,从项目管理的角度可以考虑选择演进、叠代型的生命周期模型,在配置管理方面可以考虑分层控制。2. 3 　产品结构混乱不清?? 规模较大、历史较长的产品结构可能存在产品结构差的问题,甚至由于文档缺失、人员更替而连产品的历史状态也不清楚。这会直接加大变更分析及确定变更后回归测试范围的难度。从根本上解决结构混乱问题可能需整理产品结构,自动化测试技术对控制回归测试工作量有所帮助。配置管理的直接贡献包括支持了解、管理配置项本身的特征、相互之间的联系,以及对回归测试用例、脚本等配置项的管理等。2. 4 　异地、并行开发?? 由于信息安全、系统环境约束等原因,在软件公司内部可能无法得到用户的真实数据和软、硬件运行环境。为了提高效率,可能会有多名程序员对同一配置项并行开发或并行维护。