1、软件项目管理,软件开发技术,问题的提出,市场竞争的迫切需要,人品与质量,问题的提出,影响软件质量的因素软件危机尚未渡过,软件发展落后于硬件软件质量不可把握，矛盾尖锐化软件开发不能令客户满意超容、超时、超支、文档 .,现象,有银弹！CASEOO技术 .,设想可能的出路,问题的提出,寻找出路的指导思想净室（Clean Room）技术：净化软件过程过程控制而不是产品控制：“质量是制造出来的，不是检验出来的”。开发考虑维护摆脱危机的措施：加强管理阶段评审：Review，Inspection实施软件工程标准和质量体系认证制度：ISO9000提高软件开发机构的能力：CMM,软件项目管理的理论依据,Shew
2、hart的PDCA循环30年代末由Walter Shewhart，50年代美国质量管理专家戴明（Edwards Deming）再次提出。PDCA循环至今影响着许多现代质量管理和质量改进方法，包括ISO9000国际质量标准等。,软件项目管理的理论依据,Shewhart的PDCA循环,软件项目管理的理论依据,Juran的质量改进四步骤Joseph Juran提出了控制和改进质量的一种系统方法。Juran强调在产品生命期的所有阶段实施质量管理。他的质量策划、质量控制和质量改进反映在4个步骤中。Juran的质量改进方法在全世界许多国家采用，特别是美、日。,70年代中期,70%的项目是由于管理不善引起的
3、，而并不是因为技术实力不够,管理是影响软件研发项目全局的因素，而技术因素只影响局部。,90年代中期，美国软件工程实施现状的调查：,10%的项目能够在预定的费用和进度下交付。,Meiler Page-Jones：我拜访了很多商业公司（好的和不好的），我也观察了很多数据处理的管理者，我常常恐惧地看到这些管理者徒劳地与恶梦般的项目斗争着，在根本不可能的最后期限下苦苦挣扎，或是在交付了使其用户极为不满的系统之后，又继续花费大量的时间去维护该系统。Page-Jones所描述的正是源于一系列管理和技术问题而产生的症状。不过事后如果再剖析每个项目，很有可能发现一个共同的问题：项目管理太弱。,什么是软件项目管
4、理？,软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理的对象是软件工程项目，它所涉及的范围覆盖了整个软件工程过程。软件项目管理是软件工程的保护性活动，它先于任何技术活动之前开始，并且持续贯穿于整个计算机软件的定义、开发和维护之中。,管理的范围,有效的项目管理集中于三个P 上:Problem软件范围问题分解People项目参与者项目负责人软件项目组协调和通讯Process合并问题和过程过程分解,项目开发有机体,项目开发好比一个“有机体”所有关键的部分必须协调一致的工作SPTO（软件项目跟踪与监控）就是在项目中
5、始终保持控制。,项目控制的问题？,如何确保一个项目的重要部分能协调工作？如何寻找问题并尽快、彻底解决？如何尽早地发现问题并审慎的控制其后果，以便把损失减到最小程度？保证项目的成功！,项目跟踪的难题？,问题总是不能及时的发现？必要的修复措施来得十分缓慢？“一个项目是如何拖延了一年的？就是每次拖延了一天”人月神化,与国外的软件开发相比,国外,国内,与国外的软件开发相比,国外,国内,管理,缺乏管理所造成的问题,软件生产达不到规模化,软件项目管理的活动,软件项目计划风险管理项目成本预算,软件项目计划 Software Project Planning,对估算的观察（Observations on Es
6、timating）项目计划目标（Project Planning Objectives）软件范围（Software Scope）资源（Resources）软件项目估算（Software Project Estimation）分解技术（Decomposition）经验估算模型 （Empirical Estimation Models）自行开发或购买的决策（The Make/Buy Decision）,亚里士多德：记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确,软件项目计划 Software Project Planning,提供一个框架，使得管理者能够对资源
7、、成本及进度进行合理的估算。一个限定的时间框架内“最好的情况” 及“最坏的情况”,Advice:The more you know, the better you estimate. Therefore, update your estimates as the project progresses.,软件项目计划Scope,软件项目计划的第一个活动是软件范围的确定。软件范围描述了功能、性能、约束条件、接口及可靠性。范围是通过回答下列问题来定义的：背景：待开发的软件如何适应大型的系统、产品或商业的背景，在该背景下要加什么约束？信息目标：软件要产生什么样的客户可见的数据对象来作为输出使用？需要什
8、么样的数据对象作为输入？功能和性能：软件要执行什么样的功能使得输入数据才能变换为输出数据？需要满足什么特殊的性能特征吗？,软件项目计划Scope,软件项目范围在管理层和技术层都必须是无二义性的和可理解。对软件范围的描述必须是确定的。即明确给出定量的数据（如并发用户数目、邮件列表的大小、允许的最大响应时间）；说明约束和/或限制（如产品成本、内存大小）；描述其他的特殊因素（如要用的算法能够很好地理解，并写成C+程序）。,软件项目计划Resources,人力资源描述组织的职位及专业技能等可复用软件资源可直接使用的构件; 具有完全经验的构件具有部分经验的构件;新构件环境资源：硬件及软件资源说明四特征资
9、源描述可用性说明需要该资源的时间被使用的持续时间,软件项目计划Resources,软件成本及工作量估算永远不会是一门精确的科学。几种可考虑的选择将估算拖延到项目的最后基于已经完成的类似项目使用简单的分解技术使用经验模型,软件项目计划Decomposition,分解问题， 将项目分解成若干主要功能及相关的软件工程活动,通过逐步求精的方式进行成本及工作量的估算。问题分解：“分而治之”过程分解：回答“如何完成公共过程框架？”,软件项目计划Empirical Estimation Models,COCOMO 模型（COnstructive COst MOdel）模型1：基本COCOMO模型，将软件开发
10、工作量及成本作为程序规模的函数进行计算，程序规模已估算的代码来表示。模型2：中级COCOMO模型，将软件开发工作量及成本作为程序规模及一组“成本驱动因子”的函数来进行计算，其中“成本驱动因子”包括对产品、硬件、人员、及项目属性的主管评估。模型3：高级COCOMO模型，包含了能够的所有特性，并结合了成本驱动因子对软件工程过程中每一步骤的影响评估。,最常见的进度计划风险,功能无限蔓延需求镀金或开发人员镀金质量不定计划过于乐观设计欠佳银弹综合症研发导向的开发人员薄弱签约商失败研发人员与客户的摩擦,风险管理 Risk Management,风险管理要素（Risk Management Principl
11、es）风险识别 （Risk Identification）风险分析 （Risk Analysis）风险的优先级 （Risk Prioritization）风险管理计划 （Risk Management planning）风险化解 （Risk Resolution）风险监视 （Risk Monitoring）,风险管理 Risk Management,风险管理是一种投资，与其相关的有很多成本。,任何情况下，风险管理的成本不应超出潜在的收益。,Risk Management Principles,风险监控,风险控制,风险评估,风险管理,风险管理,风险识别,风险分析,风险优先级,风险管理计划,风险化
12、解,风险管理,风险评估风险识别提出一个潜在破坏项目进度的风险列表。风险分析评估每一个风险出现的可能性及其影响，判定风险的级别。风险优先级按风险影响大小排出一个风险优先级，这个风险列表将作为风险控制的基础。,风险管理,风险控制风险管理计划制定一个应对每个重要风险的方案，同时确保每一个单独的风险管理计划之间以及与整体项目计划之间相一致。风险化解每个重要风险所对应计划的执行。风险监控对解决风险的过程进行监控，还可以包括识别新的风险并将其反馈到正在进行的风险管理进程中。,软件项目风险管理五种状态,危机管理：风险已经造成麻烦后才处理。失败处理：觉察到风险并迅速处理。风险缓解：事先制订好风险发生后的补救措
13、施，但不作任何防范措施。着力预防：将识别和防范作为项目一部分加以规划和执行。消灭根源：识别和消除风险根源。,软件项目风险管理原则,区分风险和已存在的现有问题通过风险的管理变被动的面对风险，即消防状态为主动面对风险，即钓鱼状态最小化项目失败的潜在可能创造风险管理的气氛,Risk Identification,如果你不问关于风险的问题，你就可能是正在问所遇到麻烦的问题！ Tom Gilb,风险检查列表,产品规模与要建造或要修改的软件的总体规模相关的风险。商业影响与管理或市场所加诸的约束相关的风险。客户特性与客户的素质以及开发者和客户定期通信的能力相关的风险。过程定义与软件过程被定义的程度以及它们被
14、开发组织所遵守的程度相关的风险。开发环境与用以建造产品的工具的可用性及质量相关的风险。建造的技术与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。人员数目与经验与参与工作的软件工程师的总体技术水平及项目经验相关的风险。,风险因素,性能风险产品能够满足需求且符合于其使用目的的不确定的程度。成本风险项目预算能够被维持的不确定的程度。支持风险软件易于纠错、适应及增强的不确定的程度。进度风险项目进度能够被维持且产品能按时交付的不确定的程度。,风险因素,软件成本,涉及到软件成本的常见问题情境一：你们帮我们设计个办公自动化系统，需要多少钱？情境二：我们预算投入20万建立公司的信息管理系统，你们能
15、不能做的到？情境三：对方公司希望与我们合作，捆绑销售，我们的软件许可证一份收多少钱？,软件成本的构成,一：人员工资差旅费通讯费硬件工具福利费招待费等等,二：管理费用分摊人员招聘费用风险费用培训成本费技术支持费用户教育费包装制作费市场推广费等等,软件成本,历史经验：人员规模越大，成本系数越高。技术水平越高，成本系数越高。开发周期越长，成本系数越高。一般系数为：1.53.0之间。,软件成本,历史经验：系统越复杂，开发难度系数越高开发架构与语言越高级，开发难度越高功能点越精细，准确度越高团队开发历史越久，准确度越高功能点单价除了根据历史经验外可参考同等规模的同行报价。,软件报价,软件报价的相关因素软
16、件成本销售模式市场战略,软件报价,软件报价,软件的报价原则个性化定制的越多，成本加权越高产品化成熟度越低，成本加权越高行业与专业特征越明显，成本加权越高同样功能和性能的软件产品，因为销售方式的不同，报价很可能相差巨大！,项目管理的人员,项目参与者项目负责人软件项目组,项目参与者,高级管理者：负责确定商业问题，这些问题往往对项目产生很大影响。项目（技术）管理者：必须计划、激励、组织和控制软件开发人员。开发人员：负责开发一个产品或应用软件所需的专门技术人员。客户：负责说明待开发软件的需求的人员。最终用户：一旦软件发布成为产品，最终用户是直接与软件进行交互的人。,项目负责人,解决问题：一个有效的软件
17、项目负责人应该能够准确地诊断出技术的和管理的问题；系统地计划解决方案；适当地激励其他开发人员实现解决方案；把从以前的项目中学到的经验应用到新的环境下；如果最初的解决方案没有结果，能够灵活地改变方向。管理能力：一个好的项目负责人必须掌管整个项目，他在必要时必须有信心进行控制，必须保证让优秀的技术人员能够按照他们的本性行事。,项目负责人,激励能力：为了提高项目组的生产率，项目负责人必须奖励具有主动性和作出成绩的人。并通过自己的行为表明约束下的冒险不会受到惩罚。理解和控制能力：一个有效的项目负责人必须能够“读懂”人；他必须能够理解语言的和非语言的信号，并对发出这些信号的人的要求做出反应。项目负责人必
18、须在高压力环境下保持良好的控制能力。,软件项目组,项目分配人力资源的若干可选方案，设该项目需要n个人工作k年：n个人被分配来完成m个不同的功能任务，相对而言几乎没有合作的情况发生；协调是软件管理者的责任，而他可能同时还有其他项目要管理。n个人被分配来完成m个不同的功能任务（mn），建立非正式的小组；指定一个专门的小组负责人；小组之间的协调由软件管理者负责。n个人被分成t个小组；每一个小组完成一个或多个功能任务；每一个小组有一个特定的结构，该结构是为同一个项目的所有小组定义的；协调工作由小组和软件项目管理者共同控制。,软件项目组,软件工程小组的组织方式：民主分权式（Democratic Dece
19、ntralized, DD）：这种软件工程小组没有固定的负责人。任务协调者是短期指定的，之后就由其他协调不同任务的人取代。问题和解决方法的确定是由小组讨论决策的。控制分权式（Controlled Decentralized, CD）：这种软件工程小组有一个固定的负责人，他协调特定的任务及负责子任务的二级负责人关系。问题解决仍是一个群体活动，但解决方案的实现是由小组负责人在子组之间进行划分的。子组和个人间的通信是平行的，但也会发生沿着控制层产生的上下级的通信。控制集权式（Controlled Centralized, CC）：顶层的问题解决和内部小组协调是由小组负责人管理的。负责人和小组成员之间
20、的通信是上下级式的。,软件项目组,计划软件工程小组结构时应该考虑的因素：待解决问题的困难程度；要生成的程序的规模，以代码行或功能点来衡量；小组成员需要待在一起的时间（小组生命期）；问题能够被模块化的程度；待开发系统所要求的质量和可靠性；交付日期的严格程度；项目所需要的社交性（通信）的程度。,软件项目组,因为集中式的结构能够更快地完成任务，因此最适合处理简单问题。而分散式的小组比起个人而言能够产生更多更好的解决方案，因此这种小组在处理复杂问题时成功的可能性更大。因为CD小组是集中式地解决问题，所以CD或CC小组结构能够成功地用来解决简单的问题。而DD结构则适合于解决难度较大的问题。因为小组的性能
21、与必须进行的通信量成反比，所以如果子组很容易协调的话，很大的项目最好采用CC或CD结构的小组组织方式。,软件项目组,DD小组结构最适合于解决模块化程度较低的问题，因为它需要更多的通信。如果有可能要较高的模块化程度，则CC或CD结构更加合适。CC和CD小组已被发现能够产生比DD小组更少的缺陷，但这与小组所采用的质量保证活动密切相关。分散式结构通常需要比集中式结构更多的时间来完成一个项目，但是如果要求高社交性，它是最合适的。,软件项目组,软件工程小组的组织范型：封闭式范型：按照传统的权利层次来组织小组（类似CC小组）。这种小组在开发与过去已经做过的产品类似的软件时十分有效，但这种封闭式范型下难以进
22、行创新式的工作。随机式范型：松散地组织小组，并依赖于小组成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的小组很有优势。但当需要“有次序的执行”才能完成工作时，这种小组组织范型就会陷入困境。,软件项目组,软件工程小组的组织范型：开放式范型：试图以一种既具有封闭式范型的控制性、又包含随机式范型的创新性的方式来组织小组。工作的执行结合了大量的通信和基于小组一致意见的决策。开放式范型小组结构特别适合于解决复杂问题，但可能不象其他类型小组那么效率高。同步式范型：依赖于问题的自然划分，组织小组成员各自解决问题的片段，他们之间没有什么主动的通信需求。,协调和通信问题,有很多原因会使软件
23、项目陷入困境。许多开发项目规模宏大，以至于使小组成员间的关系复杂性高混乱、难以协调。不确定性是经常存在的，它会引起困扰项目组的一连串的改变。软件工程小组必须建立有效的方法，以协调参与工作的人员之间的关系。要完成这项任务，必须建立小组成员之间及多个小组之间的正式的和非正式的通信机制。正式的通信是通过文字、会议及其他相对而言非交互和非个人的通信渠道来实现。非正式的通信则更加个人化。软件工程小组的成员在一个特别的基础上共享想法，出现问题时相互帮助，且每天相互交流。,项目协调技术,正式的、非个人的方法：包括软件工程文档和交付物（如源程序）、技术备忘录、项目里程碑、进度和项目控制工具、修改请求及相关文档
24、、错误跟踪报告、中心库数据。正式的、个人间的规程：集中表现于软件工程工作中产品的质量保证活动中，包括状态复审会议及设计和代码检查。非正式的、个人间的规程：包括信息传播、问题解决的小组会议。电子通信：包括电子邮件、电子公告栏、Web站点以及基于视频的会议系统。个人间的网络：与项目组之外的人进行的非正式的讨论，这些人可能有足够的经验或见解，能够帮助项目组成员。,项目管理的问题,软件项目管理者从软件项目一开始就面临着进退两难的局面。需要定量的估算成本和有组织的计划项目的进展，但却没有可靠的信息可以使用。对软件需求的详细分析可以提供必要的估算信息，但分析常常要花数周甚至数月的时间才能完成。更糟糕的是，
25、随着项目的进展经常发生改变，需求可能是不固定的。,项目管理中的常见问题,无法确定项目进度，项目经常延期项目进展到什么程度了？是否按计划完成？还有百分之多少未完成？无法控制项目费用，经常超支项目费用是否在按计划执行？目前项目是超支还是节余？无法控制项目风险，有可能导致项目失败项目中存在问题吗？项目中的风险都消除或降低了吗？,项目管理中的常见问题,无法确定项目的规模，不知道项目规模的变化项目有多大？项目规模比前一阶段变大还是变小了？无法确定项目资源是否够用和可用项目资源是否充足？已有的资源都可用吗？无法确定工作量我到底做了多少工作项目的工作量有多少？,产生问题的根源,无计划计划不完整计划不合理没有
26、做项目估算没有评估项目风险没有制订跟踪与监控策略跟踪与监控策略不合理没有做跟踪没有根据跟踪措施采取相应的行动.,解决问题的最佳途径,制订合理的项目计划进行项目估算在项目计划中确定合理的项目跟踪与监控策略在项目开发过程中根据跟踪结果不断调整和优化项目计划在项目开发过程中根据跟踪结果不断调整和优化项目的跟踪与监控策略,问题分解,问题分解，有时称为划分，是一个软件需求分析的核心活动。在确定软件范围的活动中并没有完全分解问题。分解一般用于两个主要领域：必须交付的功能交付所用的过程。面对复杂的问题人们常常采用分而治之的策略。简单讲，就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用
27、的策略。在估算开始之前，范围中所描述的软件功能必须被评估和精化，以提供更多的细节。因为成本和进度估算都是面向功能的，所以某种程度的分解是很有用的。,项目管理的过程,软件过程的一般阶段（定义、开发和维护）适用于所有软件项目。问题在于如何选择一个合适项目组要开发的软件过程模型。项目管理者必须决定哪一个过程模型最适合待开发项目，然后基于公共过程框架活动集合，定义一个初步的计划，便可以开始进行过程分解，即建立一个完整的计划，以反映框架活动中所需要的工作任务。,工作内容,主要内容项有7项：规模、工作量、成本、关键计算机资源、进度、技术进展、风险。在项目开展中：收集数据；与项目开发计划的估算进行比较，得出
28、偏差；对偏差进行分析，如果偏差超过了规定的域值，就应该采取相应的措施进行纠正（如修改计划等）。,收集跟踪数据的时机,跟踪数据域值,合并问题和过程,项目计划开始于问题和过程的合并。软件项目组要开发的每一个功能都必须通过为软件组织定义的框架活动集合来完成。,项目,疲惫不堪的产业专家们在讨论特别困难的软件项目时，常常提及90-90规则：一个系统的第一个90%花费了所分配工作量和时间的90%，系统最后的10%也会花费所分配工作量和时间的90%。,项目,评估进度所采用的方法是有缺陷的（很显然，如果90-90规则是真的，90%的完成度就不是一个准确的指标）。没有办法测定进度，因为没有可用的、量化的度量。项
29、目计划在项目结束时没有考虑协调所需要的资源。没有明确地考虑风险，没有建立缓解、监控和管理风险的计划。进度计划是不现实或有缺陷的。 为了克服这些问题，在项目开始时必须花时间建立一个现实的计划，在项目进行中监控该计划，并在项目整个过程中控制质量和变化。,环境并不简单,开发环境这一术语是指在开发和部署系统时所需的全部工件，其中包括工具、指南、流程、模板和基础设施。环境包括：组织的开发环境项目的开发环境,指南,流程,工具,基础设施,模板,TPUP、RUP、瀑布模型,计划模板、指南模板报告模板,设计指南、编码指南、工具指南,计算机、网络设备,VB、VC、JAVARose,以前我们的认识,组织的开发环境
30、& 项目的开发环境,组织的开发环境开发组织内的不同项目之间通常会存在许多相似之处。各项目以相似的方法使用同样的工具。对于不同的项目，流程大致相似，某些指南也可能一样。因此，如果开发组织让一个团队来开发和维护组织的开发环境（即由组织范围的流程、工具使用和基础设施组成的开发环境），就可以提高开发效率。项目的开发环境就软件开发项目而言，是指在项目开发和部署系统时所需的全部工件，其中包括工具、指南、流程、模板和基础设施。,组织的开发环境 VS 项目的开发环境,软件配置管理,当开发软件系统的过程中，变化是不可避免的。这些变化使得在同一个项目中工作的软件开发人员之间的彼此不理解程度更加增大。当变化进行前没
31、有经过分析、变化实现前没有被记录、没有向那些需要知道的人报告变化、或变化没有以可以改善质量及减少错误的方式被控制时，大量的不理解问题将会产生。协调软件开发以减少由变化带来的不理解性到最小程度的技术称为配置管理。软件配置管理（SCM）是贯穿于整个软件过程中的保护性活动。,软件配置管理,SCM活动内容：标识变化控制变化保证变化被适当地实现向其他可能感兴趣的人报告变化。,软件配置管理,明确地区分软件维护和软件配置管理是很重要的：维护是发生在软件已经被交付给客户、并且投入运行后的一系列软件工程活动。软件配置管理则是当软件项目开始时就开始、并且仅仅当软件退出运行后才终止的一组跟踪和控制活动。,软件质量保
32、证,软件质量保证（SQA）是一种应用于整个软件过程的保护性活动。SQA包括：一种质量管理方法有效的软件工程技术（方法和工具）在整个软件过程中采用的正式技术复审一种多层次的测试策略对软件文档及其修改的控制保证遵从软件开发标准的规程度量和报告机制,SQA小组,在一个组织中有多个机构负有保证软件质量的责任，包括软件工程师、项目管理者、客户、销售人员和SQA小组成员。SQA小组负责质量保证的计划、监督、记录、分析及报告工作。SQA小组充当客户在公司内部的代表。这就是说，SQA小组的成员必须以客户的观点看待软件。,SQA计划,SQA计划为建立软件质量保证提供一张行路图，其由SQA小组和项目组共同制定，充
33、当软件项目中SQA活动的模板。需要进行的评价；需要进行的审计和复审；项目可采用的标准；错误报告和跟踪过程；由SQA小组产生的文挡；为软件项目组提供的反馈数量。,SQA活动,为项目准备SQA计划；参与开发该项目的软件过程描述；复审各项软件工程活动、对其是否符合定义好的软件过程进行核实；审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实；确保软件工作及工作产品产品中的偏差已被记录在案，并根据预定规程进行处理；记录所有不符合的部分，并报告给高级管理者；协调变化的控制和管理，并帮助收集和分析软件度量信息。,课程上机,上机时间：5月19日全天（周六）5月27日全天（周日）上机地点：
34、G542上机内容：大作业B楼导航系统验收。,后续课程安排,5月21日，课程总复习5月28日，各小组汇报大作业完成情况，要求：每个小组选派一名代表，汇报大作业完成情况。制作幻灯片，张数不能少于10张，讲述时间不能少于10分钟。上交大作业报告，每个小组上交一份，其中必须注明小组成员及分工。报告内容包括：需求分析、设计说明、运行情况总结、源代码清单（不少于1/3的注释）。上机+汇报+报告共同构成大作业的30%。报告可以以电子版方式提交。,谢谢大家！,Joseph M. Juran,约瑟夫M 朱兰博士是举世公认的现代质量管理的领军人物。朱兰学院：创办于1979年，是一家咨询机构朱兰基金会：明尼苏达大学卡尔森管理学院的朱兰质量领导中心的一部分代表作：管理突破（Management Breakthrough）质量策划（Panning for Quality）质量控制手册，被称为当今世界质量控制科学的名著他的“质量计划、质量控制和质量改进”被称为“朱兰三部曲”。,
