第12章软件工程课件

第12章软件工程项目管理基础12.1项目管理的范围

12.2人员角色管理12.3问题管理12.4过程管理12.5小结12.1项目管理的范围有效的项目管理集中在三个P上，即人员(People)、问题(Problem)和过程(Process)。这三者的顺序不能够任意变更。软件工程是人的智力密集型劳动，忽略了对人的管理，工程必然失败；如果在项目早期没有和用户进行有效的通信交流，没有界定出清晰的需求，那么即使设计出不错的解决方案，也往往针对的是错误的目标；如果对于过程环节疏于管理，即使采用了良好的技术方法和先进的工具，也会因过程的混乱失控而遭遇失败。人员的过程能力、技术水平和协同工作能力是保证软件项目成功的关键因素。培养有创造力的、技术水平高的软件人员是从20世纪60年代起就开始讨论的话题。近年来对于优秀软件人才的要求中又增加了针对个人软件过程能力(PSP)方面的要素。考虑到人的因素非常重要，SEI还专门开发了一个人员管理能力成熟度模型PM-CMM。专门用以指导软件开发组织改进人力资源管理工作。人员管理能力成熟度模型PM-CMM共分为五个成熟度等级。它为软件人员管理定义了如下的关键过程域：招聘、选择、绩效管理、培训、报酬、专业发展、组织和工作计划以及团队精神/企业文化培养。在PM-CMM方面的成熟度等级越高的组织，更有可能增强开发团队的能力，实现有效的软件工程开发。问题管理主要解决“软件定义”和任务分解方面的问题，明晰针对什么对象、进行什么处理、达到什么目标、分配给什么角色去完成。任何一个软件工程项目都应当首先界定项目的目标和范围。这一活动是作为系统工程活动的一部分开始的，持续到软件需求分析阶段。这一活动的目的是说明该项目的总体目标，但并不涉及到如何实现；范围说明给出与问题相关的主要数据、功能和行为，并且以量化的形式约束这些特性。目标和范围确定之后，要开始考虑软件的解决方案，并据此确定项目的约束条件。软件过程提供了一个活动框架的集合，这些框架适合于任何一个软件项目。根据该框架可以建立一个综合的开发计划。通过定义框架中不同的具体任务，能够使描述通用过程的框架“个性化”，从而适合于不同软件项目的特征和项目组的需求。每一个框架(任务集合)都由任务、里程碑、交付的工作产品和质量控制点组成。对软件过程进行管理，使之按照严格的规则有效地进行裁剪，以适应具体的工程特征；对实际进程进行度量都属于过程管理的任务。12.2人员角色管理12.2.1项目参与者(1)高级管理者：负责确定商业问题，这些问题往往对项目会产生很大影响。所有涉及外部组织和个人的承诺只能由高级管理者验证确定。(2)项目(技术)管理者：对项目的进展负责。包括制定项目计划；组织、控制并激励软件开发人员展开工作；负责和用户代表交流，获取项目的需求与约束条件；和用户代表协商，进行变更控制；协调内部软件相关组的工作；安排必要的培训。(3)开发人员：负责开发一个产品或者应用软件所需的各类专门技术人员。根据工作性质的不同，又可以划分成不同的角色，比如系统分析员、系统设计师、程序员、测试工程师等等。按照项目开发计划所赋予的任务和角色的岗位职责开展工作。(4)客户代表：负责说明待开发软件需求的人员。同时和项目管理者协作控制项目开发过程中的各类变更。(5)最终用户：一旦软件发布成为产品，最终用户是直接与软件进行交互的人，在使用过程中还会提供必要的反馈信息。在验收测试阶段，最终用户起着非常重要的作用。每一个软件项目都应当有上述人员参加，为了提高人员工作效率，项目负责人必须最大限度地发挥每个人的技术和能力。为了能够更好地发挥各类专业人员的作用，软件开发组织应当根据实际情况建立本组织的岗位责任制度。划定岗位，明确职责，力争做到人定其岗、岗定其责。同时开发组织、项目组还应当保证每种角色在承担自己的任务时都接受过必要的、足够的培训，保证具有履行相应岗位职责的能力。12.2.2项目负责人项目负责人是项目管理工作的策划者和主要执行者之一。遴选项目负责人时必须注意，管理人员的管理技能水平是首要的条件。一个优秀的软件工程师并不见得就能够很好地承担项目负责人的角色。项目管理的核心是人员的管理，一个优秀的项目管理人必须善于利用激励机制鼓励技术人员发挥其最大能力；必须具有组织能力，能够驾驭或者创新过程，使得最初的概念能够逐渐转化成最终的产品；他也应当鼓励人们在工作中发挥创造性。项目负责人还应当集中注意力理解待解决的问题；管理新想法、新思路的交流；通过语言和行为在整个项目组中贯彻质量至上的意识。一个有效的软件项目负责人应当能够准确地诊断出技术的和管理的问题，把以往的成功经验应用到新环境下；策划系统的解决方案并激励开发人员实现方案。如果最初的方案遭遇挫折，项目负责人应当灵活地改进方案。项目负责人必须掌管整个项目，在必要时对项目进程进行调控，必须保证优秀的技术人员能够最充分地发挥技术特长，奖励有主动性和做出成绩的人员，并鼓励在项目约束范围内进行创新。项目负责人应当具有较强的语言交流能力，以期充分理解下属的意见并与之交流。良好的心态对于一个优秀的项目负责人来说是不可或缺的。当项目出现困难时，项目负责人必须能够承受较大的压力，保持对项目的控制能力。项目管理者的目标都是尽力建立并维持一个具有“凝聚力”的小组。一个具有凝聚力的小组是一组团结紧密的人，他们的整体力量大于个体力量的总和。具有凝聚力的小组成员比起一般的小组来说具有更高的生产率和更大的动力。软件企业的人员流动率远高于传统企业，管理者更应当认真做好人员管理工作，提高小组的凝聚力、稳定开发队伍。(2)受控分权式(CD，ControlledDecentralized)。这种软件工程小组有一个固定的负责人，他负责协调特定的任务并负责和负责子任务的二级负责人交流。问题的解决过程仍然是一个群体活动，但是解决方案的实现是由小组负责人在二级组之间进行划分的。子小组和个人之间的通信是平行的，也存在着上下级的通信。CD结构模式适用于项目有较高的模块化特性时。当质量保证活动比较有效时，CD模式能够产生比DD模式更少的缺陷。(3)受控集权式(CC，ControlledCentralized)。适用于较大项目。顶层问题的解决和内部小组协调是小组负责人管理的。负责人和小组成员之间的通信是上下级形式的。CC结构模式适用于项目有较高的模块化特性的情况。当质量保证活动比较有效时，CC模式能够产生比DD模式更少的缺陷。历史上风行一时的“主程序员组”就属于CC模式。选择项目小组结构方式时，应当充分考虑到项目各方面的具体特征，尽量选择适合的结构形式。集中式的结构能够更快地完成任务，最适合处理简单问题；分散使得小组更能够产生出更多的解决方案，所以这种结构在处理复杂问题时成功的几率更大；小组的性能和通信量成反比，所以较大的项目最好采用CC或CD结构。表12.1描述了项目特性对选择项目小组结构的影响。表12.1项目特征与适宜的小组结构小组结构项目特性DDCDCC难度高√

低

√√规模大

√√小√

小组生命期短

√√长√

模块化程度高

√√低√

可靠性高√√

低

√交付日期紧

√松√√

社交性高√

低

√√除上述的划分方法之外，还有人将软件工程小组划分为四种“范型”。(1)封闭式范型：按照传统的权利层次来组织小组，类似于CC小组。这种小组不利于创新，但在开发和原先的产品类似的软件时十分有效。(2)随机式范型：依赖小组成员个人的主动性。适于进行创新或技术上的突破，但当需要“有次序的执行任务”才能完成工作时，常常陷入困境。(3)开放式范型：试图结合前两种范型的优势。工作的执行结合了大量的通信和基于小组一致意见的决策。适于解决复杂问题，但效率不是很高。(4)同步式范型：依赖于问题的自然划分，小组成员各自解决问题的片断，彼此之间很少有主动的通信需要。从历史上看，最早的软件开发小组是IBM首先提出的“主程序员组”。这种组织就本质来看，类同与CC结构的小组。12.2.4小组内的协调和通信协调一致的工作是小组成功的保证，便捷灵活的通信是进行协调的技术手段。许多现代软件的规模宏大，小组成员之间的关系比较复杂。一部分成员以另一部分成员的工作输出为自己的工作输入。彼此之间进行产品交接、技术讨论、产品互查都是日常必须进行的工作。此外，在项目的进展过程中，不确定性经常出现，给项目组带来困扰和一系列的变更。在多人协作开发的软件成分之间，不可避免地存在着相互操作的要求，这更需要在开发者之间进行交流。为了保证小组成员之间开展成功的协同工作，项目组必须建立良好的协调和通信机制。例如工作产品的交换，同事之间针对个人工作的相互审查，变更的请求，实施与通报，里程碑处的正式复审等等都需要有效的通信机制来保障。在组内的通信与协调，可以借助电子邮件、项目简报、周工作会议、同行审查和里程碑报告等方式进行。具体可以归为如下几类：(1)正式的、非个人的交流方法：包括使用组织的历史数据库、项目配置库、工程文档、阶段产品、备忘录、错误跟踪报告等方式进行的通信与交流。(2)正式的、个人间的通信交流，如状态复审会议、产品互查等等。(3)非正式的、个人间的交流，例如个人间针对特定问题的讨论等。(4)电子通信：包括电子邮件、网络会议等通信方式。对于由N个成员组成的小组来说，通信的路径有N×(N－1)条。随着N值的增加，通信与协调工作的复杂性急剧增加。所以，软件工程的基本原则中，要求建立“少而精”的开发小组。同样，因为通信协调工作的复杂性，在项目开发的后期靠增加开发人员来赶进度并不是明智之举。图12.1协调和通信技术的价值及使用12.3问题管理所谓问题，包括需求问题和工程过程问题两重含义。问题管理要解决两个问题：问题界定与问题的分解划分。和用户的深入交流是本项工作得以完成的保障。也可以认为问题管理的实质就是初始需求管理，包括获取需求和精化需求两项内容。问题界定要明确就当前认识层次而言，确定的软件范围是什么。据此可以制定初步的开发计划；问题的分解进一步评估和精化软件功能，为量化估算提供基础。软件范围的确定可以从三个层面上来描述。(1)工程背景与约束条件(环境需求)：待建造的软件如何适应特定的客户背景，包括未来的运行环境、软硬件平台和其他系统的接口以及可能提出的扩充性需求。(2)信息目标(数据I/O需求)：需要什么样的输入流，输出什么样的用户可见的数据，输出具有什么样的表现形式。(3)功能和性能(综合需求)：为将输入数据转换成输出数据，软件需要什么样的加工功能；对于处理精度、处理速度、数据容量、通信速率、容错性、可靠性等各类性能有什么要求。问题分解又称为划分，是软件需求分析的核心活动。在软件范围界定时虽然也对需求进行了初始划分，但粒度较粗，不利于进行精确的分析与估算。在此基础上，还需要进一步的划分。首先需要对功能进行细分。从整体功能到子系统，从子系统到功能模块。如此逐层细分，为估算项目规模、开发工作量、工作进度和资源需求提供了基础。其次，要对生产待交付产品的工作过程进行细分。按照选定的工程模型，将整个过程中所包含的一般性、保护性活动划分为若干阶段，确定每个阶段的任务，明确阶段工作产品，确定工作里程碑。这样不但有利于制定较详细的工作计划，也有利于将整体综合计划细分为阶段计划和单项计划，增加计划的可操作性。12.4过程管理项目过程定义、制订过程计划、实施过程跟踪监控是过程管理环节的中心工作。软件过程一般可以粗略地定义为系统定义、软件开发、软件维护三大阶段，这种划分适用于任何软件项目。但是，采用不同的软件工程过程模型，各类一般性和保护性框架中包括的具体活动及其执行顺序是有差别的。可供我们选择的软件工程过程模型包括线性顺序模型、RAD模型、原型模型、演化增量模型、演化螺旋模型等等。项目管理者应当根据项目的特点和用户的要求，选择最适合本项目的工程过程模型。基于特定模型的公共过程框架活动集合定义一个初步的项目计划。然后通过对过程的细化分解，从初步计划出发建立一个完整的计划，明确框架活动中所需要的工作任务。项目计划开始于“问题”和“过程”的合并。软件项目组所要开发的每一个功能(问题)都必须选择过程规定的框架活动集合来完成。假如组织采用了如下的框架活动集合：用户通信：建立开发者和用户之间有效通信的任务。计划：定义资源、进度及其他项目相关信息所需要的任务。风险分析：评估技术风险、管理风险的任务。工程：建立应用的“表示”(文档、源码、可执行代码等)的任务。建造及发布：建造、安装、调试、培训用户等任务。用户评估：获取用户反馈信息所需要的任务。那么，承担每一项具体工作任务(如需求分析、体系设计、测试等等)的成员，都必须将规定的每一项活动应用于本项任务的开发上。这样，整个工作就得以按照“规范化的统一的过程”进行，在要解决的具体问题和统一的过程活动上进行了统一。考虑到项目各有特点，项目组在选择过程模型时应当有较大的灵活度，并应当按照项目的特点和组织的现实情况对过程规定的活动进行裁剪。如果开发一个和原来开发过的项目类似的小项目，可以考虑采用线性顺序模型；如果时间很