《软件项目管理》由会员分享，可在线阅读，更多相关《软件项目管理（140页珍藏版）》请在金锄头文库上搜索。
1、软件开发技术课程软件开发技术课程 软件项目管理软件项目管理张张 帆帆 2005年年3月月27日日联系: 13980880800 13308081800Sailor_SAILOR 2005 copyright / 2 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术 市场竞争的迫切需要市场竞争的迫切需要市场竞争市场竞争人才人才管理管理能力、水平能力、水平粗放型粗放型规模规模数量数量投入投入集约型集约型效益效益质量质量水平水平 质量与人品质量与人品规范规范标准标准人人 品品质质 量量知识知识技能技能纪律纪律精神精神教育、培训教育、培训管理管理问题
2、的提出问题的提出SAILOR 2005 copyright / 3 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术 影响软件质量的因素影响软件质量的因素 软件危机尚未渡过软件危机尚未渡过- 现象：现象：软件发展落后于硬件软件发展落后于硬件软件质量不可把握，矛盾尖锐化软件质量不可把握，矛盾尖锐化软件开发不能令客户满意软件开发不能令客户满意超容、超时、超支、文档超容、超时、超支、文档 .- 设想可能的出路：设想可能的出路：有银弹！、有银弹！、CASE、OO技术技术 .问题的提出问题的提出SAILOR 2005 copyright / 4 200
3、5年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术- 寻找出路的指导思想寻找出路的指导思想1. 净室（净室（Clean Room）技术：净化软件过程技术：净化软件过程2. 过程控制而不是产品控制：过程控制而不是产品控制：“质量是制造质量是制造 出来的，不是检验出来的出来的，不是检验出来的”事后事后被动被动个体个体所有环节所有环节主动主动全体全体过程控制过程控制产品控制产品控制3. 开发考虑维护开发考虑维护- 摆脱危机的措施：加强管理摆脱危机的措施：加强管理1. 阶段评审阶段评审 Review, Inspection2. 实施软件工程标准和质量体系认证
4、制度实施软件工程标准和质量体系认证制度 ISO9000-33. 提高软件开发机构的能力提高软件开发机构的能力 CMM问题的提出问题的提出SAILOR 2005 copyright / 5 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目的建立有其质量管理理论作为科学依据。软件项目的建立有其质量管理理论作为科学依据。几位著名的质量管理大师为其奠定了基础。几位著名的质量管理大师为其奠定了基础。Shewhart的的PDCA循环循环- 早在早在30年代末年代末Walter Shewhart已提出质量改进已提出质量改进的的 PDCA循环。循环。
5、- PDCA循环至今影响着许多现代质量管理和质量循环至今影响着许多现代质量管理和质量 改进方法，包括改进方法，包括ISO9000国际质量标准等。国际质量标准等。PDCA循环循环ActionCheckPlanDoAPCD软件项目管理的理论依据软件项目管理的理论依据SAILOR 2005 copyright / 6 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术APCD收集数据收集数据实施系统变更实施系统变更确定有效性确定有效性评估评估确定问题确定问题描述改进目标描述改进目标找出问题出现找出问题出现的可能原因的可能原因建立基线建立基线 找出改进
6、的机会找出改进的机会 提出改进计划提出改进计划 针对共同原因采取的措施针对共同原因采取的措施 进行持续改进进行持续改进Shewhart的的PDCA质量循环质量循环软件项目管理的理论依据软件项目管理的理论依据SAILOR 2005 copyright / 7 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术Juran的质量改进四步骤的质量改进四步骤- Joseph Juran提出了控制和改进质量的一种系统方法。提出了控制和改进质量的一种系统方法。- Juran强调在产品生命期的所有阶段实施质量管理。强调在产品生命期的所有阶段实施质量管理。 他的
7、质量策划、质量控制和质量改进反映在图他的质量策划、质量控制和质量改进反映在图1212表表 示的示的4 4个步骤中个步骤中。- Juran的质量改进方法在全世界许多国家采用，特别的质量改进方法在全世界许多国家采用，特别 是美、日。是美、日。Juran的质量控制与改进步骤的质量控制与改进步骤研究产品质量问题的各种现象（缺陷或事故）研究产品质量问题的各种现象（缺陷或事故）提出理论或解释造成产品质量问题的原因提出理论或解释造成产品质量问题的原因在生产中检验理论以证实原因在生产中检验理论以证实原因实施纠正或改进措施实施纠正或改进措施质量改进质量改进软件项目管理的理论依据软件项目管理的理论依据SAILOR
8、 2005 copyright / 8 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术70年代中期年代中期70%的项目是由于管理不善引起的，而并不是因为技术实力不够管理是影响软件研发项目全局的因素，而技术因素只影响局部。SAILOR 2005 copyright / 9 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术90年代中期年代中期 美国软件工程实施现状的调查：美国软件工程实施现状的调查： 10%10%的项目能够在预定的费用的项目能够在预定的费用和进度下交付。和进度下交付。SAILO
9、R 2005 copyright / 10 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术什么是软件项目管理？软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理的对象是软件工程项目，他所涉及的范围覆盖了整个软件工程过程。 SAILOR 2005 copyright / 11 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术Meiler Page-Jones：我拜访了很多商业公司，我也观察我拜访了很多商业公
10、司，我也观察了很多数据处理的管理者，我常常恐惧地了很多数据处理的管理者，我常常恐惧地看到这些管理者徒劳地与恶梦般的项目斗看到这些管理者徒劳地与恶梦般的项目斗争着，在根本不可能的最后期限下苦苦挣争着，在根本不可能的最后期限下苦苦挣扎，或是在交付了使其用户极为不满的系扎，或是在交付了使其用户极为不满的系统之后，又继续花费大量的时间去维护该统之后，又继续花费大量的时间去维护该系统。系统。SAILOR 2005 copyright / 12 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SAILOR 2005 copyright / 13 2005
11、年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目管理软件项目管理 软件项目管理是软件工程的保护性活软件项目管理是软件工程的保护性活动，它先于任何技术活动之前开始，并且动，它先于任何技术活动之前开始，并且持续贯穿于整个计算机软件的定义、开发持续贯穿于整个计算机软件的定义、开发和维护之中。和维护之中。SAILOR 2005 copyright / 14 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件范围软件范围 软软件件项项目目管管理理的的第第一一个个活活动动是是软软件件范范围围的的确定。
12、范围是通过回答下列问题来定义的：确定。范围是通过回答下列问题来定义的：背背景景：待待开开发发的的软软件件如如何何适适应应大大型型的的系系统统、产产品品或或商商业的背景，在该背景下要加什么约束？业的背景，在该背景下要加什么约束？信信息息目目标标：软软件件要要产产生生什什么么样样的的客客户户可可见见的的数数据据对对象象来作为输出使用？需要什么样的数据对象作为输入？来作为输出使用？需要什么样的数据对象作为输入？功功能能和和性性能能：软软件件要要执执行行什什么么样样的的功功能能使使得得输输入入数数据据才才能能变变换换为为输输出出数数据据？需需要要满满足足什什么么特特殊殊的的性性能能特特征征吗？吗？SA
13、ILOR 2005 copyright / 15 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件范围软件范围 软件项目范围在管理层和技术层都必软件项目范围在管理层和技术层都必须是无二义性的和可理解的。对软件范围的须是无二义性的和可理解的。对软件范围的描述必须是确定的。即，描述必须是确定的。即，明明确确给给出出定定量量的的数数据据（如如并并发发用用户户数数目目、邮邮件件列列表的大小、允许的最大响应时间）；表的大小、允许的最大响应时间）；说明约束和说明约束和/或限制（如产品成本、内存大小）；或限制（如产品成本、内存大小）；描描述述其其他他的
14、的特特殊殊因因素素（如如要要用用的的算算法法能能够够很很好好地地理解，并写成理解，并写成C+程序）。程序）。SAILOR 2005 copyright / 16 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术管理的范围管理的范围有效的项目管理集中于三个P 上：People项目参与者项目负责人软件项目组协调和通讯Problem软件范围问题分解Process合并问题和过程过程分解SAILOR 2005 copyright / 17 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目开发项目开
15、发有机体有机体项目开发好比一个项目开发好比一个“有机体有机体”所有关键的部分必须协调一致的工作所有关键的部分必须协调一致的工作SPTO软件项目跟踪软件项目跟踪就是在项目中始终就是在项目中始终保持控制。保持控制。SAILOR 2005 copyright / 18 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目控制的问题？项目控制的问题？如何确保一个项目的重要部分能协调工作？如何确保一个项目的重要部分能协调工作？如何寻找问题并尽快、彻底解决？如何寻找问题并尽快、彻底解决？如何尽早地发现问题并审慎的控制其后果，以便如何尽早地发现问题并审慎的
16、控制其后果，以便把损失减到最小程度？把损失减到最小程度？保证项目的成功！保证项目的成功！SAILOR 2005 copyright / 19 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目跟踪的难题？项目跟踪的难题？问题总是不能及时的发现？问题总是不能及时的发现？必要的修复措施来得十分缓慢？必要的修复措施来得十分缓慢？“一个项目是如何拖延了一年的？就是每次拖延了一天一个项目是如何拖延了一年的？就是每次拖延了一天”人月神化人月神化SAILOR 2005 copyright / 20 2005年年3月月27日日 电子科技大学电子科技大学 计
17、算机学院计算机学院 软件工程技术软件工程技术操作系统开发工具技术水平操作系统开发工具技术水平国外国内与国外的软件开发相比与国外的软件开发相比SAILOR 2005 copyright / 21 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术国外国内缺乏规范的管理缺乏规范的管理管理管理操作系统开发工具技术水平操作系统开发工具技术水平SAILOR 2005 copyright / 22 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件质量软件质量？软件生产达不到规模化软件生产达不到规模化人
18、员流动人员流动成员间缺少沟通成员间缺少沟通缺少有效的通信机制缺少有效的通信机制缺乏管理所造成的问题缺乏管理所造成的问题SAILOR 2005 copyright / 23 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目管理软件项目计划风险管理项目成本预算SAILOR 2005 copyright / 24 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划 Software Project PlanningSoftware Project Planning对估算的观察 O
19、bservations on Estimating项目计划目标 Project Planning Objectives软件范围 Software Scope资源 Resources软件项目估算 Software Project Estimation分解技术 Decomposition 经验估算模型 Empirical Estimation Models自行开发或购买的决策 The Make/Buy DecisionSAILOR 2005 copyright / 25 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术亚里斯多德：亚里斯多德：记住
20、：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确SAILOR 2005 copyright / 26 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划Project Planning ObjectivesProject Planning Objectives提供一个框架，使得管理者能够对资源、提供一个框架，使得管理者能够对资源、成本及进度进行合理的估算。成本及进度进行合理的估算。一个限定的时间框架内一个限定的时间框架内“最好的情况最好的情况” 及及“最坏的情况最坏的情况”通过一个信息发现的过程实现的
21、通过一个信息发现的过程实现的SAILOR 2005 copyright / 27 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划Project Planning ObjectivesProject Planning ObjectivesAdvice:Advice:The more you know, the better you estimate. Therefore, update your estimates as the project progresses.SAILOR 2005 copyright / 28 2005年
22、年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划Software ScopeSoftware Scope软件项目计划的第一个活动是软件范围的软件项目计划的第一个活动是软件范围的确定。确定。软件范围描述了功能、性能、约束条件、软件范围描述了功能、性能、约束条件、接口及可靠性。接口及可靠性。SAILOR 2005 copyright / 29 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划Software ScopeSoftware Scope范围是通过回答下列问题来定义的：范围
23、是通过回答下列问题来定义的：背景背景：待建造的软件如何适应于大型的系统、待建造的软件如何适应于大型的系统、产品或商业的背景，在该背景下要加什么约产品或商业的背景，在该背景下要加什么约束？束？信息目标信息目标：软件要产生什么样的客户可见的：软件要产生什么样的客户可见的数据对象输出，需要什么样的数据对象输入数据对象输出，需要什么样的数据对象输入？功能和性能功能和性能：软件执行什么样的功能使得输软件执行什么样的功能使得输入数据才能变换成为输出数据？需要满足什入数据才能变换成为输出数据？需要满足什么特殊的性能特征吗？么特殊的性能特征吗？SAILOR 2005 copyright / 30 2005年年
24、3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划ResourcesResources硬件/软件工具可复用构件人员提供支持开发 工作的基础极大地降低开发成本，时间主要资源SAILOR 2005 copyright / 31 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划ResourcesResources人力资源人力资源描述组织的职位及专业技能等描述组织的职位及专业技能等可复用软件资源可复用软件资源可直接使用的构件可直接使用的构件; 具有完全经验的构件具有完全经验的构件具有部分经
25、验的构件具有部分经验的构件;新构件新构件环境资源环境资源硬件及软件硬件及软件SAILOR 2005 copyright / 32 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划ResourcesResources资源说明四特征资源说明四特征资源描述资源描述可用性说明可用性说明需要该资源的时间需要该资源的时间被使用的持续时间被使用的持续时间SAILOR 2005 copyright / 33 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划ResourcesResou
26、rces软件成本及工作量估算永远不会是一门精软件成本及工作量估算永远不会是一门精确的科学。确的科学。可以从神秘的技巧向一系列系统化的步骤可以从神秘的技巧向一系列系统化的步骤转化转化SAILOR 2005 copyright / 34 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划Software Project EstimationSoftware Project Estimation几种可考虑的选择几种可考虑的选择将估算拖延到项目的最后将估算拖延到项目的最后基于已经完成的类似项目基于已经完成的类似项目使用简单的分解技术使用简单
27、的分解技术使用经验模型使用经验模型SAILOR 2005 copyright / 35 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划DecompositionDecomposition分解问题，分解问题， 将项目分解成若干主要功能将项目分解成若干主要功能及相关的软件工程活动及相关的软件工程活动,通过逐步求精的通过逐步求精的方式进行成本及工作量的估算方式进行成本及工作量的估算问题分解问题分解“分而治之分而治之”过程分解过程分解回答回答“如何完成公共过程框架？如何完成公共过程框架？” SAILOR 2005 copyright /
28、 36 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目计划Empirical Estimation Empirical Estimation ModelsModelsCOCOMO 模型模型（Constructive Cost MOdel）软件估算模型的层次体系软件估算模型的层次体系模型模型1：基本：基本COCOMO模型，将软件开发工作量及模型，将软件开发工作量及成本作为程序规模的函数进行计算，程序规模已估成本作为程序规模的函数进行计算，程序规模已估算的代码来表示。算的代码来表示。模型模型2：中级：中级COCOMO模型，将软件开发工作
29、量及模型，将软件开发工作量及成本作为程序规模及一组成本作为程序规模及一组“成本驱动因子成本驱动因子”的函数的函数来进行计算，其中来进行计算，其中“成本驱动因子成本驱动因子”包括对产品、包括对产品、硬件、人员、及项目属性的主管评估。硬件、人员、及项目属性的主管评估。模型模型3：高级：高级COCOMO模型，包含了能够的所有特模型，包含了能够的所有特性，并结合了成本驱动因子对软件工程过程中每一性，并结合了成本驱动因子对软件工程过程中每一步骤的影响评估。步骤的影响评估。SAILOR 2005 copyright / 37 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件
30、工程技术软件工程技术软件项目计划 Software Project PlanningSoftware Project Planning对估算的观察 Observations on Estimating项目计划目标 Project Planning Objectives软件范围 Software Scope资源 Resources软件项目估算 Software Project Estimation分解技术 Decomposition 经验估算模型 Empirical Estimation Models自行开发或购买的决策 The Make/Buy DecisionSAILOR 2005 copy
31、right / 38 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术最常见的进度计划风险最常见的进度计划风险功能无限蔓延需求镀金或开发人员镀金质量不定计划过于乐观设计欠佳银弹综合症研发导向的开发人员薄弱签约商失败研发人员与客户的摩擦SAILOR 2005 copyright / 39 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术风险管理风险管理 Risk Management风险管理要素 Risk Management Principles风险识别 Risk Identificatio
32、n风险分析 Risk Analysis风险的优先级 Risk Prioritization风险管理计划 Risk Management planning风险化解 Risk Resolution风险监视 Risk MonitoringSAILOR 2005 copyright / 40 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SAILOR 2005 copyright / 41 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术Risk Management PrinciplesSAIL
33、OR 2005 copyright / 42 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术风险管理风险评估风险控制风险识别风险分析风险优先级风险管理计划风险化解风险监控SAILOR 2005 copyright / 43 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术风险评估风险识别提出一个潜在破坏项目进度的风险列表。风险分析评估每一个风险出现的可能性及其影响，判定风险的级别。风险优先级按风险影响大小排出一个风险优先级，这个风险列表将作为风险控制的基础。SAILOR 2005 copy
34、right / 44 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术风险控制风险管理计划制定一个应对每个重要风险的方案，同时确保每一个单独的风险管理计划之间以及与整体项目计划之间相一致。风险化解每个重要风险所对应计划的执行。风险监控对解决风险的过程进行监控，还可以包括识别新的风险并将其反馈到正在进行的风险管理进程中。SAILOR 2005 copyright / 45 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目风险管理五种状态危机管理风险已经造成麻烦后才处理。失败处理觉察到风
35、险并迅速处理。风险缓解事先制订好风险发生后的补救 措施，但不作任何防范措施。着力预防将识别和防范作为项目一部分 加以规划和执行。消灭根源识别和消除风险根源。SAILOR 2005 copyright / 46 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目风险管理原则区分风险和已存在的现有问题区分风险和已存在的现有问题通过风险的管理变被动的面对风险，即消通过风险的管理变被动的面对风险，即消防状态为主动面对风险，即钓鱼状态防状态为主动面对风险，即钓鱼状态最小化项目失败的潜在可能最小化项目失败的潜在可能创造风险管理的气氛创造风险管理的气
36、氛SAILOR 2005 copyright / 47 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术Risk Identification 如果你不问关于风险的问题，你就可能是正在问所遇到麻烦的问题 Tom GilbSAILOR 2005 copyright / 48 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术风险检查列表风险检查列表产品规模与要建造或要修改的软件的总体规模相关的风险。与要建造或要修改的软件的总体规模相关的风险。商业影响与管理或市场所加诸的约束相关的风险。与管理或市
37、场所加诸的约束相关的风险。客户特性与客户的素质以及开发者和客户定期通信的能力与客户的素质以及开发者和客户定期通信的能力相关的风险。相关的风险。过程定义与软件过程被定义的程度以及它们被开发组织所与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。遵守的程度相关的风险。开发环境与用以建造产品的工具的可用性及质量相关的风与用以建造产品的工具的可用性及质量相关的风险。险。建造的技术与待开发软件的复杂性及系统所包含技术的与待开发软件的复杂性及系统所包含技术的“新奇性新奇性”相关的风险。相关的风险。人员数目与经验与参与工作的软件工程师的总体技术水平与参与工作的软件工程师的总体技术水平及项目经验
38、相关的风险。及项目经验相关的风险。SAILOR 2005 copyright / 49 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术风险因素风险因素性能风险性能风险产品能够满足需求且符合于其产品能够满足需求且符合于其 使用目的的不确定的程度。使用目的的不确定的程度。成本风险成本风险项目预算能够被维持的不确定项目预算能够被维持的不确定 的程度。的程度。支持风险支持风险软件易于纠错、适应及增强的软件易于纠错、适应及增强的 不确定的程度。不确定的程度。进度风险进度风险项目进度能够被维持且产品能项目进度能够被维持且产品能 按时交付的不确定的程度。
39、按时交付的不确定的程度。SAILOR 2005 copyright / 50 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SAILOR 2005 copyright / 51 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件成本软件成本软件报价软件报价SAILOR 2005 copyright / 52 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术涉及到软件成本的常见问题涉及到软件成本的常见问题情境一：情境一：你们帮我们设计个办
40、公自动化系统，需要多少钱？你们帮我们设计个办公自动化系统，需要多少钱？情境二：情境二：我们预算投入我们预算投入20万建立公司的信息管理系统，你们能不能万建立公司的信息管理系统，你们能不能做的到？做的到？情境三：情境三：对方公司希望与我们合作，捆绑销售，我们的软件许可证对方公司希望与我们合作，捆绑销售，我们的软件许可证一份收多少钱？一份收多少钱？SAILOR 2005 copyright / 53 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件成本的构成软件成本的构成一：一：人员工资人员工资差旅费差旅费通讯费通讯费硬件硬件工具工具福利费福
41、利费招待费等等招待费等等二：二：管理费用分摊管理费用分摊人员招聘费用人员招聘费用风险费用风险费用培训成本费培训成本费技术支持费技术支持费用户教育费用户教育费包装制作费包装制作费市场推广费等等市场推广费等等SAILOR 2005 copyright / 54 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术历史经验：历史经验：人员规模越大人员规模越大,成本系数越高。成本系数越高。技术水平越高，成本系数越高。技术水平越高，成本系数越高。开发周期越长，成本系数越高。开发周期越长，成本系数越高。一般系数为：一般系数为：1.53.0之间。之间。SAIL
42、OR 2005 copyright / 55 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术历史经验：历史经验：系统越复杂，开发难度系数越高系统越复杂，开发难度系数越高开发架构与语言越高级，开发难度越高开发架构与语言越高级，开发难度越高功能点越精细，准确度越高功能点越精细，准确度越高团队开发历史越久，准确度越高团队开发历史越久，准确度越高功能点单价除了根据历史经验外可参考同等功能点单价除了根据历史经验外可参考同等规模的同行报价。规模的同行报价。SAILOR 2005 copyright / 56 2005年年3月月27日日 电子科技大学电子
43、科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件报价的相关因素软件成本软件成本销售模式销售模式市场战略市场战略软件成本销售模式市场战略SAILOR 2005 copyright / 57 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件的销售办法软件的销售办法销售性质销售性质销售方法销售方法成本加权成本加权“一次收费一次收费”性性光盘发行，网上下载注册光盘发行，网上下载注册中中分期授权分期授权网上注册，出售许可证卡网上注册，出售许可证卡低低分帐模式分帐模式厂商厂商OEM，捆绑销售，捆绑销售，中低中低收取服务费收取服务费ASP应
44、用服务提供应用服务提供中中用户定制用户定制项目招投标，系统集成项目招投标，系统集成最高最高SAILOR 2005 copyright / 58 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件的报价原则个性化定制的越多，成本加权越高个性化定制的越多，成本加权越高产品化成熟度越低，成本加权越高产品化成熟度越低，成本加权越高行业与专业特征越明显，成本加权越高行业与专业特征越明显，成本加权越高同样功能和性能的软件产品，因为销售方式的不同，报价很可能相差巨大！SAILOR 2005 copyright / 59 2005年年3月月27日日 电子科
45、技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目管理的人员项目管理的人员项目参与者项目参与者项目负责人项目负责人软件项目组软件项目组SAILOR 2005 copyright / 60 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目参与者项目参与者高级管理者：负责确定商业问题，这些问题往往对高级管理者：负责确定商业问题，这些问题往往对项目产生很大影响。项目产生很大影响。项目（技术）管理者：必须计划、激励、组织和控项目（技术）管理者：必须计划、激励、组织和控制软件开发人员。制软件开发人员。开发人员：负责开发一个产品或
46、应用软件所需的专开发人员：负责开发一个产品或应用软件所需的专门技术人员。门技术人员。客户：负责说明待开发软件的需求的人员。客户：负责说明待开发软件的需求的人员。最最终终用用户户：一一旦旦软软件件发发布布成成为为产产品品，最最终终用用户户是是直直接与软件进行交互的人。接与软件进行交互的人。SAILOR 2005 copyright / 61 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目负责人项目负责人解决问题：解决问题：一个有效的软件项目负责人应该能够准一个有效的软件项目负责人应该能够准确地诊断出技术的和管理的问题；系统地计划解决确地诊
47、断出技术的和管理的问题；系统地计划解决方案；适当地激励其他开发人员实现解决方案；把方案；适当地激励其他开发人员实现解决方案；把从以前的项目中学到的经验应用到新的环境下；如从以前的项目中学到的经验应用到新的环境下；如果最初的解决方案没有结果，能够灵活地改变方向。果最初的解决方案没有结果，能够灵活地改变方向。管理能力：管理能力：一个好的项目负责人必须掌管整个项目，一个好的项目负责人必须掌管整个项目，他在必要时必须有信心进行控制，必须保证让优秀他在必要时必须有信心进行控制，必须保证让优秀的技术人员能够按照他们的本性行事。的技术人员能够按照他们的本性行事。SAILOR 2005 copyright /
48、 62 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目负责人项目负责人激励能力：激励能力：为了提高项目组的生产率，项目负为了提高项目组的生产率，项目负责人必须奖励具有主动性和作出成绩的人。并责人必须奖励具有主动性和作出成绩的人。并通过自己的行为表明约束下的冒险不会受到惩通过自己的行为表明约束下的冒险不会受到惩罚。罚。理理解解和和控控制制能能力力：一一个个有有效效的的项项目目负负责责人人必必须须能能够够“读读懂懂”人人；他他必必须须能能够够理理解解语语言言的的和和非非语语言言的的信信号号，并并对对发发出出这这些些信信号号的的人人的的要要求
49、求做做出出反反应应。项项目目负负责责人人必必须须在在高高压压力力环环境境下下保保持持良好的控制能力。良好的控制能力。SAILOR 2005 copyright / 63 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目组软件项目组 项目分配人力资源的若干可选方案，设该项目需要项目分配人力资源的若干可选方案，设该项目需要n个个人工作人工作k年：年：n个人被分配来完成个人被分配来完成m个不同的功能任务，相对而言几乎没个不同的功能任务，相对而言几乎没有合作的情况发生；协调是软件管理者的责任，而他可能同有合作的情况发生；协调是软件管理者的责任
50、，而他可能同时还有六个其他项目要管。时还有六个其他项目要管。n个人被分配来完成个人被分配来完成m个不同的功能任务（个不同的功能任务（mn），），建立非建立非正式的小组；指定一个专门的小组负责人；小组之间的协调正式的小组；指定一个专门的小组负责人；小组之间的协调由软件管理者负责。由软件管理者负责。n个人被分成个人被分成t个小组；每一个小组完成一个或多个功能任务；个小组；每一个小组完成一个或多个功能任务；每一个小组有一个特定的结构，该结构是为同一个项目的所每一个小组有一个特定的结构，该结构是为同一个项目的所有小组定义的；协调工作由小组和软件项目管理者共同控制。有小组定义的；协调工作由小组和软件项目
51、管理者共同控制。SAILOR 2005 copyright / 64 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目组软件项目组软件工程小组的组织方式：软件工程小组的组织方式：民民主主分分权权式式（Democratic Decentralized, DD）：这这种种软软件件工工程程小小组组没没有有固固定定的的负负责责人人。任任务务协协调调者者是是短短期期指指定定的的，之之后后就就由由其其他他协协调调不不同同任任务务的的人人取取代代。问问题题和和解解决决方方法法的的确确定定是是由由小小组组讨讨论论决决策策的。的。控控制制分分权权式式（
52、Controlled Decentralized, CD）：这这种种软软件件工工程程小小组组有有一一个个固固定定的的负负责责人人，他他协协调调特特定定的的任任务务及及负负责责子子任任务务的的二二级级负负责责人人关关系系。问问题题解解决决仍仍是是一一个个群群体体活活动动，但但解解决决方方案案的的实实现现是是有有小小组组负负责责人人在在子子组组之之间间进进行行划划分分的的。子子组组和和个个人人间间的的通通信信是是平平行行的的，但也会发生沿着控制层产生的上下级的通信。但也会发生沿着控制层产生的上下级的通信。控控制制集集权权式式（Controlled Centralized, CC）：顶顶层层的的问问
53、题题解解决决和和内内部部小小组组协协调调是是由由小小组组负负责责人人管管理理的的。负负责责人人和和小小组组成成员员之之间间的的通通信是上下级式的。信是上下级式的。SAILOR 2005 copyright / 65 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目组软件项目组计划软件工程小组结构时应该考虑的因素：计划软件工程小组结构时应该考虑的因素：待解决问题的困难程度；待解决问题的困难程度；要生成的程序的规模，以代码行或功能点来衡量；要生成的程序的规模，以代码行或功能点来衡量；小组成员需要待在一起的时间（小组生命期）；小组成员需要待
54、在一起的时间（小组生命期）；问题能够被模块化的程度；问题能够被模块化的程度；待开发系统所要求的质量和可靠性；待开发系统所要求的质量和可靠性；交付日期的严格程度；交付日期的严格程度；项目所需要的社交性（通信）的程度。项目所需要的社交性（通信）的程度。SAILOR 2005 copyright / 66 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目组软件项目组因因为为集集中中式式的的结结构构能能够够更更快快地地完完成成任任务务，因因此此最最适适合合处处理理简简单单问问题题。而而分分散散式式的的小小组组比比起起个个人人而而言言能能够够产
55、产生生更更多多更更好好的的解解决决方方案案，因因此此这这种种小小组组在在处处理理复复杂杂问问题题时时成成功功的的可可能能性性更更大大。因因为为CD小小组组是是集集中中式式地地解解决决问问题题，所所以以CD或或CC小小组组结结构构能能够够成成功功地地用用来来解解决决简简单单的的问问题题。而而DD结结构构则则适适合合于于解解决决难难度度较大的问题。较大的问题。因因为为小小组组的的性性能能与与必必须须进进行行的的通通信信量量成成反反比比，所所以以如如果果子子组组很很容容易易协协调调的的话话，很很大大的的项项目目最最好好采采用用CC或或CD结构的小组组织方式。结构的小组组织方式。SAILOR 2005
56、 copyright / 67 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目组软件项目组因为小组的性能与必须进行的通信量成反比，所以如果子因为小组的性能与必须进行的通信量成反比，所以如果子组很容易协调的话，很大的项目最好采用组很容易协调的话，很大的项目最好采用CC或或CD结构的结构的小组组织方式。小组组织方式。DD小小组组结结构构最最适适合合于于解解决决模模块块化化程程度度较较低低的的问问题题，因因为为它它需需要要更更多多的的通通信信。如如果果有有可可能能要要较较高高的的模模块块化化程程度度，则则CC或或CD结构更加合适。结构更加
57、合适。CC和和CD小小组组已已被被发发现现能能够够产产生生比比DD小小组组更更少少的的缺缺陷陷，但但这这与与小小组组所所采采用用的的质质量量保保证证活活动动密密切切相相关关。分分散散式式结结构构通通常常需需要要比比集集中中式式结结构构更更多多的的时时间间来来完完成成一一个个项项目目，但但是是如果要求高社交性，它是最合适的。如果要求高社交性，它是最合适的。SAILOR 2005 copyright / 68 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目组软件项目组软件工程小组的组织范型：软件工程小组的组织范型：封封闭闭式式范范型型：
58、按按照照传传统统的的权权利利层层次次来来组组织织小小组组（类类似似CC小小组组）。这这种种小小组组在在开开发发与与过过去去已已经经做做过过的的产产品品类类似似的的软软件件时时十十分分有有效效，但但这这种种封封闭闭式式范范型型下下难以进行创新式的工作。难以进行创新式的工作。随随机机式式范范型型：松松散散地地组组织织小小组组，并并依依赖赖于于小小组组成成员员个个人人的的主主动动性性。当当需需要要创创新新或或技技术术上上的的突突破破时时，按按照照这这种种随随机机式式范范型型组组织织的的小小组组很很有有优优势势。但但当当需需要要“有有次次序序的的执执行行”才才能能完完成成工工作作时时，这这种种小小组组
59、组组织织范型就会陷入困境。范型就会陷入困境。SAILOR 2005 copyright / 69 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件项目组软件项目组软件工程小组的组织范型：软件工程小组的组织范型：开放式范型：试图以一种既具有封闭式范型的控开放式范型：试图以一种既具有封闭式范型的控制性、又包含随机式范型的创新性的方式来组织制性、又包含随机式范型的创新性的方式来组织小组。工作的执行结合了大量的通信和基于小组小组。工作的执行结合了大量的通信和基于小组一致意见的决策。开放式范型小组结构特别适合一致意见的决策。开放式范型小组结构特别适
60、合于解决复杂问题，但可能不象其他类型小组那么于解决复杂问题，但可能不象其他类型小组那么效率高。效率高。同步式范型：依赖于问题的自然划分，组织小组同步式范型：依赖于问题的自然划分，组织小组成员各自解决问题的片段，他们之间没有什么主成员各自解决问题的片段，他们之间没有什么主动的通信需求。动的通信需求。SAILOR 2005 copyright / 70 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术协调和通信问题协调和通信问题有很多原因会使软件项目陷入困境。许多开发项目规模宏有很多原因会使软件项目陷入困境。许多开发项目规模宏大，以至于使小组成员
61、间的关系复杂性高混乱、难以协调。大，以至于使小组成员间的关系复杂性高混乱、难以协调。不确定性是经常存在的，它会引起困扰项目组的一连串的不确定性是经常存在的，它会引起困扰项目组的一连串的改变。改变。软件工程小组必须建立有效的方法，以协调参与工作的人软件工程小组必须建立有效的方法，以协调参与工作的人员之间的关系。要完成这项任务，必须建立小组成员之间员之间的关系。要完成这项任务，必须建立小组成员之间及多个小组之间的正式的和非正式的通信机制。及多个小组之间的正式的和非正式的通信机制。正正式式的的通通信信是是通通过过文文字字、会会议议及及其其他他相相对对而而言言非非交交互互和和非非个个人人的的通通信信渠
62、渠道道来来实实现现。非非正正式式的的通通信信则则更更加加个个人人化化。软软件件工工程程小小组组的的成成员员在在一一个个特特别别的的基基础础上上共共享享想想法法，出出现现问问题时相互帮助，且每天相互交流。题时相互帮助，且每天相互交流。SAILOR 2005 copyright / 71 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目协调技术项目协调技术正式的、非个人的方法：包括软件工程文档和交付物（如源程序）正式的、非个人的方法：包括软件工程文档和交付物（如源程序）、技术备忘录、项目里程碑、进度和项目控制工具、修改请求及、技术备忘录、项目
63、里程碑、进度和项目控制工具、修改请求及相关文档、错误跟踪报告、中心库数据。相关文档、错误跟踪报告、中心库数据。正式的、个人间的规程：集中表现于软件工程工作中产品的质量正式的、个人间的规程：集中表现于软件工程工作中产品的质量保证活动中，包括状态复审会议及设计和代码检查。保证活动中，包括状态复审会议及设计和代码检查。非正式的、个人间的规程：包括信息传播、问题解决的小组会议。非正式的、个人间的规程：包括信息传播、问题解决的小组会议。电子通信：包括电子邮件、电子公告栏、电子通信：包括电子邮件、电子公告栏、Web站点以及基于视频站点以及基于视频的会议系统。的会议系统。个人间的网络：与项目组之外的人进行的
64、非正式的讨论，这些人个人间的网络：与项目组之外的人进行的非正式的讨论，这些人可能有足够的经验或见解，能够帮助项目组成员。可能有足够的经验或见解，能够帮助项目组成员。SAILOR 2005 copyright / 72 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目管理的问题项目管理的问题 软件项目管理者从软件项目一开始就面临软件项目管理者从软件项目一开始就面临着进退两难的局面。需要定量的估算成本和有组着进退两难的局面。需要定量的估算成本和有组织的计划项目的进展，但却没有可靠的信息可以织的计划项目的进展，但却没有可靠的信息可以使用。对软件
65、需求的详细分析可以提供必要的估使用。对软件需求的详细分析可以提供必要的估算信息，但分析常常要花数周甚至数月的时间才算信息，但分析常常要花数周甚至数月的时间才能完成。更糟糕的是，随着项目的进展经常发生能完成。更糟糕的是，随着项目的进展经常发生改变，需求可能是不固定的。改变，需求可能是不固定的。SAILOR 2005 copyright / 73 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目管理中的常见问题项目管理中的常见问题无法确定项目进度，项目经常延期无法确定项目进度，项目经常延期项目进展到什么程度了？项目进展到什么程度了？是否按计划
66、完成？还有百分之多少未完成？是否按计划完成？还有百分之多少未完成？无法控制项目费用，经常超支无法控制项目费用，经常超支项目费用是否在按计划执行？项目费用是否在按计划执行？目前项目是超支还是节余？目前项目是超支还是节余？无法控制项目风险，有可能导致项目失败无法控制项目风险，有可能导致项目失败项目中存在问题吗？项目中存在问题吗？项目中的风险都消除或降低了吗？项目中的风险都消除或降低了吗？SAILOR 2005 copyright / 74 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目管理中的常见问题项目管理中的常见问题(Cont.)无法确
67、定项目的规模，不知道项目规模的变化无法确定项目的规模，不知道项目规模的变化项目有多大？项目有多大？项目规模比前一阶段变大还是变小了？项目规模比前一阶段变大还是变小了？无法确定项目资源是否够用和可用无法确定项目资源是否够用和可用项目资源是否充足？项目资源是否充足？已有的资源都可用吗？已有的资源都可用吗？无法确定工作量无法确定工作量我到底做了多少工作我到底做了多少工作项目的工作量有多少？项目的工作量有多少？SAILOR 2005 copyright / 75 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术产生问题的根源产生问题的根源无无计划计划
68、计划不完整计划不完整计划不合理计划不合理没有做项目估算没有做项目估算没有评估项目风险没有评估项目风险没有制订跟踪与监控策略没有制订跟踪与监控策略跟踪与监控策略不合理跟踪与监控策略不合理没有做跟踪没有做跟踪没有根据跟踪措施采取相应的行动没有根据跟踪措施采取相应的行动。SAILOR 2005 copyright / 76 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术解决问题的最佳途径解决问题的最佳途径制订合理的项目计划制订合理的项目计划进行项目估算进行项目估算在项目计划中确定合理的项目跟踪与监控在项目计划中确定合理的项目跟踪与监控策略策略在项
69、目开发过程中根据跟踪结果不断调整在项目开发过程中根据跟踪结果不断调整和优化项目计划和优化项目计划在项目开发过程中根据跟踪结果不断调整在项目开发过程中根据跟踪结果不断调整和优化项目的跟踪与监控策略和优化项目的跟踪与监控策略SAILOR 2005 copyright / 77 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术问题分解问题分解问题分解，有时称为划分，是一个软件需求分析的核心活问题分解，有时称为划分，是一个软件需求分析的核心活动。在确定软件范围的活动中并没有完全分解问题。分解动。在确定软件范围的活动中并没有完全分解问题。分解一般用于两
70、个主要领域：一般用于两个主要领域： （1）必须交付的功能；（）必须交付的功能；（2）交付所用的过程。）交付所用的过程。面对复杂的问题人们常常采用分而治之的策略。简单讲，面对复杂的问题人们常常采用分而治之的策略。简单讲，就是将一个复杂的问题划分成若干较易处理的小问题。这就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在估算开始之前，范围是项目计划开始时所采用的策略。在估算开始之前，范围中所描述的软件功能必须被评估和精化，以提供更多的细中所描述的软件功能必须被评估和精化，以提供更多的细节。因为成本和进度估算都是面向功能的，所以某种程度节。因为成本和进度估算都是面向功
71、能的，所以某种程度的分解是很有用的。的分解是很有用的。SAILOR 2005 copyright / 78 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项目管理的过程项目管理的过程软件过程的一般阶段（定义、开发和维护）适软件过程的一般阶段（定义、开发和维护）适用于所有软件项目。问题在于如何选择一个合用于所有软件项目。问题在于如何选择一个合适项目组要开发的软件过程模型。适项目组要开发的软件过程模型。项目管理者必须决定哪一个过程模型最适合待项目管理者必须决定哪一个过程模型最适合待开发项目，然后基于公共过程框架活动集合，开发项目，然后基于公共过
72、程框架活动集合，定义一个初步的计划，便可以开始进行过程分定义一个初步的计划，便可以开始进行过程分解，即建立一个完整的计划，以反映框架活动解，即建立一个完整的计划，以反映框架活动中所需要的工作任务。中所需要的工作任务。SAILOR 2005 copyright / 79 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术工作内容工作内容跟踪的主要内容项有跟踪的主要内容项有7项：项：规模、工作量、成本、关键计算机资源、进度、技术进规模、工作量、成本、关键计算机资源、进度、技术进展、风险。展、风险。在项目开展中：在项目开展中：收集数据；收集数据；与项
73、目开发计划的估算进行比较，得出偏差；与项目开发计划的估算进行比较，得出偏差；对偏差进行分析，如果偏差超过了规定的域值，就应该对偏差进行分析，如果偏差超过了规定的域值，就应该采取相应的措施进行纠正采取相应的措施进行纠正(如修改计划等如修改计划等)。SAILOR 2005 copyright / 80 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术收集跟踪数据的时机收集跟踪数据的时机跟踪项度量单位收集时机收集人规模规模用例点用例点(UCP)/功能点功能点/代码行数代码行数 每个阶段和每个迭代结束时每个阶段和每个迭代结束时 项目经理项目经理 工作
74、量工作量人时人时每周每周 全体成员全体成员项目成本项目成本人民币人民币(元元)每月每月 财务人员财务人员 关键计算关键计算机资源机资源逐项说明逐项说明每月每月 项目经理项目经理项目进度项目进度工作任务完成率工作任务完成率%每周每周 项目经理项目经理项目风险项目风险停留周数停留周数每周每周 项目经理项目经理技术进展技术进展实现的用例实现的用例/实现的类等实现的类等 每周每周 项目经理项目经理SAILOR 2005 copyright / 81 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术跟踪数据域值跟踪数据域值跟踪项偏差控制域 规模规模10
75、%工作量工作量10%项目成本项目成本3%关键计算机资关键计算机资源源10%(每项)项目进度项目进度20%项目风险项目风险风险发生的第一征兆是否出现 SAILOR 2005 copyright / 82 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术合并问题和过程合并问题和过程 项目计划开始于问题和过程的合并。项目计划开始于问题和过程的合并。软件项目组要开发的每一个功能都必须通过软件项目组要开发的每一个功能都必须通过为软件组织定义的框架活动集合来完成。为软件组织定义的框架活动集合来完成。SAILOR 2005 copyright / 83 2
76、005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项项 目目 疲惫不堪的产业专家们在讨论特别困疲惫不堪的产业专家们在讨论特别困难的软件项目时，常常提及难的软件项目时，常常提及90-90规则：规则：一个系统的第一个一个系统的第一个90%花费了所分配工作量和时花费了所分配工作量和时间的间的90%，系统最后，系统最后10%也会花费所分配工作量也会花费所分配工作量和时间的和时间的90%。SAILOR 2005 copyright / 84 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术项项 目目评估进
77、度所采用的方法是有缺陷的（很显然，如果评估进度所采用的方法是有缺陷的（很显然，如果90-90规规则是真的，则是真的，90%的完成度就不是一个准确的指标）。的完成度就不是一个准确的指标）。没有办法测定进度，因为没有可用的、量化的度量。没有办法测定进度，因为没有可用的、量化的度量。项目计划在项目结束时没有考虑协调所需要的资源。项目计划在项目结束时没有考虑协调所需要的资源。没有明确地考虑风险，没有建立缓解、监控和管理风险的计没有明确地考虑风险，没有建立缓解、监控和管理风险的计划。划。进度计划是不现实或有缺陷的。进度计划是不现实或有缺陷的。 为为了了克克服服这这些些问问题题，在在项项目目开开始始时时必
78、必须须花花时时间间建建立立一一个个现现实实的的计计划划，在在项项目目进进行行中中监监控控该该计计划划，并并在项目整个过程中控制质量和变化。在项目整个过程中控制质量和变化。SAILOR 2005 copyright / 85 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术环境并不简单环境并不简单 开发环境这一术语是指在开发和部署系统时所需的全部工件，开发环境这一术语是指在开发和部署系统时所需的全部工件，开发环境这一术语是指在开发和部署系统时所需的全部工件，开发环境这一术语是指在开发和部署系统时所需的全部工件，其中包括工具、指南、流程、模板和基
79、础设施。其中包括工具、指南、流程、模板和基础设施。其中包括工具、指南、流程、模板和基础设施。其中包括工具、指南、流程、模板和基础设施。 环境包括：环境包括：环境包括：环境包括：组织的开发环境组织的开发环境组织的开发环境组织的开发环境项目的开发环境项目的开发环境项目的开发环境项目的开发环境TPUP、RUP、瀑布模型计划模板、指南模板报告模板设计指南、编码指南、工具指南计算机、网络设备VB、VC、JAVARose以前我们的以前我们的认识认识SAILOR 2005 copyright / 86 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术组织的
80、开发环境组织的开发环境 & 项目的开发环境项目的开发环境组织的开发环境组织的开发环境开发组织内的不同项目之间通常会存在许多相似之处。开发组织内的不同项目之间通常会存在许多相似之处。各项目以相似的方法使用同样的工具。对于不同的项目，各项目以相似的方法使用同样的工具。对于不同的项目，流程大致相似，某些指南也可能一样。因此，如果开发流程大致相似，某些指南也可能一样。因此，如果开发组织让一个团队来开发和维护组织的开发环境（组织让一个团队来开发和维护组织的开发环境（即由组即由组织范围的流程、工具使用和基础设施组成的开发环境织范围的流程、工具使用和基础设施组成的开发环境），），就可以提高开发效率。就可以提
81、高开发效率。项目的开发环境项目的开发环境就软件开发项目而言，是指就软件开发项目而言，是指在项目在项目开发和部署系统时所开发和部署系统时所需的全部工件，其中包括工具、指南、流程、模板和基需的全部工件，其中包括工具、指南、流程、模板和基础设施。础设施。SAILOR 2005 copyright / 87 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术组织的开发环境组织的开发环境 VS 项目的开发环境项目的开发环境(TPUP、XP、瀑布模型)项目的开发环境项目的开发环境项目的开发环境项目的开发环境SAILOR 2005 copyright / 8
82、8 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件配置管理软件配置管理当当开开发发软软件件系系统统的的过过程程中中，变变化化是是不不可可避避免免的的。这这些些变变化化使使得得在在同同一一个个项项目目中中工工作作的的软软件件开开发发人人员员之之间间的的彼彼此此不不理理解解程程度度更更加加增增大大。当当变变化化进进行行前前没没有有经经过过分分析析、变变化化实实现现前前没没有有被被记记录录、没没有有向向那那些些需需要要知知道道的的人人报报告告变变化化、或或变变化化没没有有以以可可以以改改善善质质量量及及减减少少错错误误的的方方式式被被控控制制
83、时时，大大量量的不理解问题将会产生。的不理解问题将会产生。协协调调软软件件开开发发以以减减少少由由变变化化带带来来的的不不理理解解性性到到最最小小程程度度的的技技术术称称为为配配置置管管理理。软软件件配配置置管管理理（SCM）是是贯贯穿穿于于整整个个软件过程中的保护性活动。软件过程中的保护性活动。SAILOR 2005 copyright / 89 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件配置管理软件配置管理SCM活动内容：活动内容：标识变化标识变化控制变化控制变化保证变化被适当地实现保证变化被适当地实现向其他可能感兴趣的人报告变
84、化。向其他可能感兴趣的人报告变化。SAILOR 2005 copyright / 90 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件配置管理软件配置管理 明明确确地地区区分分软软件件维维护护和和软软件件配配置置管管理理是是很重要的：很重要的：维维护护是是发发生生在在软软件件已已经经被被交交付付给给客客户户、并并且且投投入入运行后的一系列软件工程活动。运行后的一系列软件工程活动。软软件件配配置置管管理理则则是是当当软软件件项项目目开开始始时时就就开开始始、并并且且仅仅仅仅当当软软件件退退出出运运行行后后才才终终止止的的一一组组跟跟踪踪和
85、和控控制活动。制活动。SAILOR 2005 copyright / 91 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件配置软件配置 软件过程的输出信息可以分为三个主要软件过程的输出信息可以分为三个主要的类别：的类别：计算机程序（源代码和可执行程序）计算机程序（源代码和可执行程序）描述计算机程序的文档（针对技术开发者和用户）描述计算机程序的文档（针对技术开发者和用户）数据（包含在程序内部和程序外部）。数据（包含在程序内部和程序外部）。 它们包含了所有在软件过程中产生的它们包含了所有在软件过程中产生的信息，总称为软件配置。信息，总称为软
86、件配置。SAILOR 2005 copyright / 92 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术变化的起源变化的起源有四种基本的变化源：有四种基本的变化源：新的商业或市场条件，引起产品需求和业务规则的变化。新的商业或市场条件，引起产品需求和业务规则的变化。新新的的客客户户需需要要，要要求求修修改改信信息息系系统统产产生生的的数数据据、产产品品提提供供的功能、或基于计算机的系统提供的服务。的功能、或基于计算机的系统提供的服务。改改组组和和/或或企企业业规规模模减减小小，导导致致项项目目优优先先级级或或软软件件工工程程队队伍结构的变
87、化。伍结构的变化。预算或进度的限制，导致系统或产品的重定义。预算或进度的限制，导致系统或产品的重定义。SAILOR 2005 copyright / 93 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件配置项软件配置项 软件配置项（软件配置项（Software Configuration Items, SCI）定义为部分软件工程过程中创建的定义为部分软件工程过程中创建的信息，在极端情况下，一个信息，在极端情况下，一个SCI可被考虑为某个可被考虑为某个大的规约中的某个单独段落，或在某个大的测大的规约中的某个单独段落，或在某个大的测试用例集
88、中的某种测试用例，更实际地，一个试用例集中的某种测试用例，更实际地，一个SCI是一个文档、一个全套的测试用例、或一个是一个文档、一个全套的测试用例、或一个已命名的程序构件（例如，已命名的程序构件（例如，C函数或函数或Ada95软件包）。软件包）。SAILOR 2005 copyright / 94 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术基基 线线基基线线是是一一个个软软件件配配置置管管理理的的概概念念，它它帮帮助助我我们们在在不不严严重重阻阻碍碍合合理理变变化化的的情情况况下下来来控控制变化。制变化。IEEE(IEEE Std.61
89、0.12-1990)定定义义基基线线如如下下：已已经经通通过过正正式式复复审审审审核核批批准准的的某某规规约约或或产产品品，它它因因此此可可以以作作为为进进一一步步开开发发的的基基础础，并并且且只只能能通通过过正正式式的的变变化化控控制制过过程程而而改变。改变。SAILOR 2005 copyright / 95 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术基基 线线在软件配置项变成基线前，变化可以迅速而非正在软件配置项变成基线前，变化可以迅速而非正式地进行，然而，一旦基线已经建立，我们就得式地进行，然而，一旦基线已经建立，我们就得象通过
90、一个单向开的门那样，变化可以进行，但象通过一个单向开的门那样，变化可以进行，但是，必须应用特定的、正式的规程来评估和验证是，必须应用特定的、正式的规程来评估和验证每个变化。每个变化。在软件工程的范围内，基线是软件开发中的里程在软件工程的范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，碑，其标志是有一个或多个软件配置项的交付，且这些且这些SCI已经经过正式技术复审而获得认可。已经经过正式技术复审而获得认可。SAILOR 2005 copyright / 96 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术常见的软件基线
91、常见的软件基线系统工程需求定义软件设计编 码测 试发 布系统规约系统规约软件需求规约软件需求规约设计规约设计规约源代码源代码测试计划测试计划/过程过程/数据数据可操作的系统可操作的系统SAILOR 2005 copyright / 97 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术产生基线的流程产生基线的流程SCIsSCIsSCIsSCIsSCIs正式技术复审SCM控制软件工程任务修改认可提取存储项目数据库SAILOR 2005 copyright / 98 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件
92、工程技术软件工程技术成为基线的成为基线的SCIs系统规约系统规约软件项目计划软件项目计划软件需求规约软件需求规约 图形分析模型；处理规约；原型；数学规约图形分析模型；处理规约；原型；数学规约初步的用户手册初步的用户手册SAILOR 2005 copyright / 99 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术成为基线的成为基线的SCIs设计规约设计规约 数据设计描述数据设计描述；体系结构设计描述；模块设计体系结构设计描述；模块设计描述；界面设计描述；对象描述（如果使用面描述；界面设计描述；对象描述（如果使用面向对象技术）向对象技术）
93、源代码清单源代码清单测试规约测试规约 测试计划和过程；测试用例和结果记录测试计划和过程；测试用例和结果记录操作和安装手册操作和安装手册SAILOR 2005 copyright / 100 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术成为基线的成为基线的SCIs可执行程序可执行程序 模块的可执行代码；链接的模块模块的可执行代码；链接的模块数据库描述数据库描述 模式和文件结构；初始内容模式和文件结构；初始内容联机用户手册联机用户手册维护文档维护文档 软件问题报告；维护请求；工程变化命令软件问题报告；维护请求；工程变化命令软件工程的标准和规约
94、软件工程的标准和规约SAILOR 2005 copyright / 101 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术成为基线的成为基线的SCIs除除了了上上面面列列出出的的SCI，很很多多软软件件工工程程组组织织也也将将软软件件工工具具列列入入配配置置管管理理之之下下，即即，特特定定版版本本的的编编辑辑器器、编编译译器器和和其其他他CASE工工具具被被“固固定定”作作为为软软件件配配置置的的一一部部分分。因因为为这这些些工工具具被被用用于于生生成成文文档档。源源代代码码和和数数据据，所所以以当当对对软软件件配配置置进进行行改改变变时时
95、，必必然然要要用用到到它它们们。虽虽然然问问题题并并不不多多见见，但但有有可可能能某某工工具具的的新新版版本本（如如，编编译译器器）可可能能产产生生和和原原版版本本不不同同的的结结果果。为为此此，工工具具就就象象它它们们辅辅助助生生产产的的软软件件一一样样，可可以以被被基基线线化化，并并做做为为综综合合的的配配置置管管理理过程的一部分。过程的一部分。SAILOR 2005 copyright / 102 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术基线基线SCISCI和项目数据库和项目数据库SAILOR 2005 copyright /
96、103 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM过程过程 软软件件配配置置管管理理是是软软件件质质量量保保证证的的重重要要一一环环，其其主主要要责责任任是是控控制制变变化化。然然而而，SCM也也负负责责个个体体SCI和和软软件件的的各各种种版版本本的的标标识识、软软件件配配置置的的审审计计（以以保保证证它它已已被被适适当地开发）、以及配置中所有变化的报告。当地开发）、以及配置中所有变化的报告。SAILOR 2005 copyright / 104 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工
97、程技术软件工程技术SCM过程过程任何关于任何关于SCM的讨论均涉及一系列复杂问题：的讨论均涉及一系列复杂问题：一一个个组组织织如如何何标标识识和和管管理理程程序序（及及其其文文档档）的的很很多多现现存存版版本本，以使得变化可以高效地进行？以使得变化可以高效地进行？一个组织如何在软件被发布给客户之前和之后控制变化？一个组织如何在软件被发布给客户之前和之后控制变化？谁负责批准变化，并给变化确定优先级？谁负责批准变化，并给变化确定优先级？我们如何保证变化已经被恰当地进行？我们如何保证变化已经被恰当地进行？采用什么机制去告知其他人员已经实行的变化？采用什么机制去告知其他人员已经实行的变化？SAILOR
98、 2005 copyright / 105 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM过程过程SCM五大任务：五大任务：标识标识版本控制版本控制变化控制变化控制配置审计配置审计报告。报告。SAILOR 2005 copyright / 106 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中对象的标识中对象的标识为了控制和管理软件配置项，每个配置项必须被独立为了控制和管理软件配置项，每个配置项必须被独立命名，然后用面向对象的方法组织。命名，然后用面向对象的方法组织。有两种
99、类型的对象可以被标识：基本对象和聚集对象。有两种类型的对象可以被标识：基本对象和聚集对象。基本对象是软件工程师在分析、设计、编码或测试中基本对象是软件工程师在分析、设计、编码或测试中创建的创建的“文本单元（文本单元（unit of text）” ，例如，一个基例如，一个基本对象可能是需求规约的一个段落、模块的源程序清本对象可能是需求规约的一个段落、模块的源程序清单或一组用于测试代码的测试用例。单或一组用于测试代码的测试用例。一个聚集对象是基本对象和其他聚集对象的集合。一个聚集对象是基本对象和其他聚集对象的集合。SAILOR 2005 copyright / 107 2005年年3月月27日日
100、电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中对象的标识中对象的标识每每个个对对象象均均具具有有一一组组唯唯一一地地标标识识它它的的、独独特特的的特特征征：名名字、描述、资源表、以及字、描述、资源表、以及“现实现实” 。对对象象名名是是无无二二义义性性地地标标识识对对象象的的一一个个字字符符串串；对对象象描描述述是一个数据项的列表，它们标识：是一个数据项的列表，它们标识： 该对象所表示的该对象所表示的SCI类型（如，文档、程序、数据）；类型（如，文档、程序、数据）； 项目标识符；以及变化和项目标识符；以及变化和/或版本信息；或版本信息；资资源源是是由由对对象象
101、提提供供、处处理理、引引用用或或需需要要的的实实体体，例例如如，数数据据类类型型、特特定定函函数数、或或甚甚至至变变量量名名也也可可以以作作为为对对象象资资源；源；现现实实是是一一个个指指针针，对对基基本本对对象象而而言言指指向向“文文本本单单元元” ，对聚集对象而言则指向对聚集对象而言则指向null。SAILOR 2005 copyright / 108 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中对象的标识中对象的标识配置对象的标识也必须考虑存在于命名对象之间的配置对象的标识也必须考虑存在于命名对象之间的关系，一个对象可被标识
102、为某聚集对象的关系，一个对象可被标识为某聚集对象的，关系关系定义了一个对象层次。定义了一个对象层次。对于软件对象的标识模式必须认可对象在整个软件对于软件对象的标识模式必须认可对象在整个软件过程中的演化，在一个对象被确定为基线前，它可过程中的演化，在一个对象被确定为基线前，它可能会变化很多次，甚至在基线已经建立后，变化也能会变化很多次，甚至在基线已经建立后，变化也可能经常发生。有可能为任意对象创建一个演化图可能经常发生。有可能为任意对象创建一个演化图，演化图描速了对象的变化历史。演化图描速了对象的变化历史。SAILOR 2005 copyright / 109 2005年年3月月27日日 电子科
103、技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中对象的标识中对象的标识obj1.0obj1.1obj1.2obj1.3obj1.4obj2.0obj2.1obj1.1.1Obj1.1.2对象演化图对象演化图SAILOR 2005 copyright / 110 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的版本控制中的版本控制版版本本控控制制结结合合了了规规程程和和工工具具以以管管理理在在软软件件工工程程中所创建的配置对象的不同版本。中所创建的配置对象的不同版本。SCM中中的的版版本本控控制制可可以以描描
104、述述如如下下：配配置置管管理理使使得得用用户户能能够够通通过过对对适适当当版版本本的的选选择择来来指指定定可可选选的的软软件件系系统统的的配配置置，这这一一点点的的实实现现是是通通过过将将属属性性关关联联到到每每个个软软件件版版本本上上，然然后后通通过过描描述述一一组组所期望的属性来指定（和构造）配置的。所期望的属性来指定（和构造）配置的。SAILOR 2005 copyright / 111 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制 对于大型的软件开发项目，无控制的变对于大型的软件开发项目，无控制的变化
105、将迅速导致混乱，化将迅速导致混乱，SCM变化控制结合人的规变化控制结合人的规程和自动化工具以提供一个变化控制的机制。程和自动化工具以提供一个变化控制的机制。SAILOR 2005 copyright / 112 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制一个变化请求被提交和评估，以评价技术指标、潜在副作用、对一个变化请求被提交和评估，以评价技术指标、潜在副作用、对其他配置对象和系统功能的整体影响、以及对于变化的成本预测。其他配置对象和系统功能的整体影响、以及对于变化的成本预测。评估的结果以变化报告的形式给出
106、，该报告被变化控制审核者评估的结果以变化报告的形式给出，该报告被变化控制审核者（change control authority, CCA）-对变化的状态及优先级对变化的状态及优先级作最终决策的人或小组作最终决策的人或小组-使用。对每个被批准的变化生成一个使用。对每个被批准的变化生成一个过程变化命令（过程变化命令（engineering change order, ECO），），ECO描描述了将要进行的变化、必须注意的约束、以及复审和审计的标准。述了将要进行的变化、必须注意的约束、以及复审和审计的标准。将被修改的对象从项目数据库将被修改的对象从项目数据库“提取（提取（check out）”出来
107、，进出来，进行修改，并应用于合适的行修改，并应用于合适的SQA活动，然后，将对象活动，然后，将对象“提交提交（check in）”进数据库，并使用合适的版本控制机制去建立软进数据库，并使用合适的版本控制机制去建立软件的下一个版本。件的下一个版本。SAILOR 2005 copyright / 113 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制 “提交提交”和和“提取提取”过程实现了两个过程实现了两个主要的变化控制要素主要的变化控制要素-访问控制和同步访问控制和同步控制：控制：访问控制管理哪个软件工程师有权限
108、去访问和访问控制管理哪个软件工程师有权限去访问和修改某特定的配置对象。修改某特定的配置对象。同步控制帮助保证由两个不同人员完成的并行同步控制帮助保证由两个不同人员完成的并行修改不会互相覆盖。修改不会互相覆盖。SAILOR 2005 copyright / 114 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制 基于一个被批准的变化请求和基于一个被批准的变化请求和ECO，软软件工程师提取出配置对象，访问控制功能保件工程师提取出配置对象，访问控制功能保证该软件工程师有权限提取该对象，而同步证该软件工程师有权限提取该
109、对象，而同步控制对项目数据库中的该对象加锁，使得当控制对项目数据库中的该对象加锁，使得当前提取出的版本在被放回以前不能对它作任前提取出的版本在被放回以前不能对它作任何其他修改。注意，可以提取出其他的备份，何其他修改。注意，可以提取出其他的备份，但是，不能进行其他修改。但是，不能进行其他修改。SAILOR 2005 copyright / 115 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制非正式变化控制：非正式变化控制： 在在SCI变成基线以前，只需要进行非正式变成基线以前，只需要进行非正式的变化控制。配置对
110、象（的变化控制。配置对象（SCI）的开发者可以的开发者可以进行任何被管理和技术需求证明是合适的修改进行任何被管理和技术需求证明是合适的修改（只要修改不会影响到在开发者工作范围之外（只要修改不会影响到在开发者工作范围之外的更广的系统需求），一旦对象已经经过正式的更广的系统需求），一旦对象已经经过正式的技术复审并已被认可，则创建了一个基线。的技术复审并已被认可，则创建了一个基线。SAILOR 2005 copyright / 116 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制项目级变化控制：项目级变化控制： 一
111、旦一旦SCI变成基线，则项目级的变化控变成基线，则项目级的变化控制就开始实施了。这时，为了进行修改，开发制就开始实施了。这时，为了进行修改，开发者必须获得项目管理者的批准（如果变化是者必须获得项目管理者的批准（如果变化是“局部的局部的” ），或），或CCA的批准（如果该变化影的批准（如果该变化影响到其他响到其他SCI）。）。在某些情况下，变化需求、在某些情况下，变化需求、变化报告和变化报告和ECO的正式生成可以省略，然而，的正式生成可以省略，然而，需要管理对每个变化的评价，并对所有变化进需要管理对每个变化的评价，并对所有变化进行跟踪和复审。行跟踪和复审。SAILOR 2005 copyrigh
112、t / 117 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制正式的变化控制：正式的变化控制： 当软件产品发布给客户时，正式的变化控当软件产品发布给客户时，正式的变化控制就开始实施了制就开始实施了SAILOR 2005 copyright / 118 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的变化控制中的变化控制 变变化化控控制制审审核核者者（CCA）在在第第二二和和第第三三层层控控制制上上扮扮演演了了活活跃跃的的角角色色，依依赖赖于于软软件件
113、项项目目的的规规模模和和性性质质，CCA可可能能包包含含一一个个人人-项项目目管管理理者者-或或一一组组人人（如如，来来自自软软件件、硬硬件件、数数据据库库工工程程、支支持持、市市场场等等五五方方面面的的代代表表）。CCA的的角角色色是是从从全全局局的的观观点点来来评评估估变变化化对对SCI之之外外的的事事务务的的影影响：响：变化将如何影响硬件？变化将如何影响硬件？变化将如何影响性能？变化将如何影响性能？变化将如何改变客户对产品的感觉？变化将如何改变客户对产品的感觉？变化将如何影响产品的质量和可靠性？变化将如何影响产品的质量和可靠性？ 这些和很多其他的问题需被这些和很多其他的问题需被CCA处理
114、。处理。SAILOR 2005 copyright / 119 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的配置审计中的配置审计 标标识识、版版本本控控制制和和变变化化控控制制帮帮助助软软件件开开发发者者维维持持秩秩序序，否否则则情情况况可可能能将将是是混混乱乱和和不不固固定定的的。然然而而，即即使使最最成成功功的的控控制制机机制制也也只只能能在在ECO产产生生后后才才可可以以跟跟踪踪变变化化。我我们们如如何何帮帮助助变变化被合适的实现呢？回答是两方面的：化被合适的实现呢？回答是两方面的： （1）正式的技术复审；）正式的技术复审
115、； （2）软件配置审计。）软件配置审计。SAILOR 2005 copyright / 120 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的配置审计中的配置审计 正正式式的的技技术术复复审审关关注注已已经经被被修修改改的的配配置置对对象象的的技技术术正正确确性性，复复审审者者评评估估SCI以以确确定定它它与与其其他他SCI的的一一致致性性、遗遗漏漏、及及潜潜在在的的副副作作用用，正正式式的的复复审审应应该该对对所所有有的的变变化化进行，除了那些最琐碎的变化之外。进行，除了那些最琐碎的变化之外。SAILOR 2005 copyri
116、ght / 121 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的配置审计中的配置审计 软软件件配配置置审审计计通通过过评评估估配配置置对对象象的的通通常常不不在在复复审审中中考考虑虑的的特特征征，而而形成正式复审的补充。审计询问并回答如下问题：形成正式复审的补充。审计询问并回答如下问题：在在ECO中说明的变化已经完成了吗？加入了任意附加的修改吗？中说明的变化已经完成了吗？加入了任意附加的修改吗？是否已经进行了正式的技术复审，以评估技术的正确性？是否已经进行了正式的技术复审，以评估技术的正确性？是否适当地遵循了软件工程标准？是否适
117、当地遵循了软件工程标准？变化在变化在SCI中被中被“显著地强调（显著地强调（highlighted）”了吗？是否指出了变化的日期和了吗？是否指出了变化的日期和变化的作者？配置对象的属性反应了变化吗？变化的作者？配置对象的属性反应了变化吗？是否遵循了标注变化、记录变化并报告变化的是否遵循了标注变化、记录变化并报告变化的SCM规程？规程？所有相关的所有相关的SCI被适当修改了吗？被适当修改了吗？ 在在某某些些情情况况下下，审审计计问问题题被被作作为为正正式式的的技技术术复复审审的的一一部部分分而而询询问问，然而，当然而，当SCM是一个正式的活动时，是一个正式的活动时，SCM审计由质量保证组单独进行
118、。审计由质量保证组单独进行。SAILOR 2005 copyright / 122 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的状态报告中的状态报告 配置状态报告（配置状态报告（Configuration status reporting, 有时称为有时称为status accounting）是一个是一个SCM任务，它回答任务，它回答下列问题：下列问题：发生了什么事？发生了什么事？谁做的此事？谁做的此事？此事是什么时候发生的？此事是什么时候发生的？将影响别的什么吗？将影响别的什么吗？SAILOR 2005 copyright /
119、 123 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的状态报告中的状态报告配置状态报告配置状态报告(CSR)的信息流如下：的信息流如下：每次当一个每次当一个SCI被赋上新的和修改后的标识时，则一个被赋上新的和修改后的标识时，则一个CSR条目被创建；条目被创建；每次当一个变化被每次当一个变化被CCA批准时（即，一个批准时（即，一个ECO产生），产生），一个一个CSR条目被创建；条目被创建；每次当配置审计进行时，其结果作为每次当配置审计进行时，其结果作为CSR任务的一部分被任务的一部分被报告。报告。CSR的输出可以放置到一个联机数据
120、库中，使得软件开发的输出可以放置到一个联机数据库中，使得软件开发者或维护者可以通过关键词分类访问变化信息。此外，者或维护者可以通过关键词分类访问变化信息。此外，CSR报告被定期生成，并允许管理者和开发者评估重要的报告被定期生成，并允许管理者和开发者评估重要的变化。变化。SAILOR 2005 copyright / 124 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM中的状态报告中的状态报告 配配置置状状况况报报告告在在大大型型软软件件开开发发项项目目的的成成功功中中扮扮演演了了重重要要角角色色，当当涉涉及及到到很很多多人人员员时时
121、，有有可可能能会会发发生生“左手不知道右手在做什么左手不知道右手在做什么”的综合症：的综合症：两两个个开开发发者者可可能能试试图图以以不不同同的的或或冲冲突突的的意意图图去去修修改改同同一一个个SCI；软软件件工工程程队队伍伍可可能能花花费费几几个个月月的的工工作作量量针针对对过过时时的的硬硬件件规规约约建造软件；建造软件；能能认认识识到到被被建建议议的的修修改改有有严严重重副副作作用用的的人人并并不不知知道道该该修修改改已已经进行。经进行。 CSR通通过过改改善善所所有有相相关关人人员员之之间间的的通通信信，帮帮助助排排除这些问题。除这些问题。SAILOR 2005 copyright /
122、125 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SCM标准标准 在过去在过去20年中，已经提出了一系列的软件年中，已经提出了一系列的软件配置管理标准。很多早期的配置管理标准。很多早期的SCM标准，如标准，如MIL-STD-483、DOD-STD-480A、和、和MIL-STD1521A，主要用于为军事用途而开发的软件。然主要用于为军事用途而开发的软件。然而，最近的而，最近的ANSI/IEEE标准，如标准，如ANSI/IEEE Std. No. 828-1983，No. 1042-1987，和，和Std. No.1028-1988，可应
123、用于商业软件，并被向大型可应用于商业软件，并被向大型的和小型的软件工程组织推荐。的和小型的软件工程组织推荐。SAILOR 2005 copyright / 126 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件质量软件质量软件质量定义软件质量定义 明确声明的功能和性能需求、明确明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满的软件所应具有的所有隐含特征都得到满足。足。SAILOR 2005 copyright / 127 2005年年3月月27日日
124、 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件质量软件质量软件质量定义软件质量定义软件需求是进行软件需求是进行“质量质量”度量的基础。与需求不度量的基础。与需求不符就是质量不高。符就是质量不高。指定的标准定义了一组指导软件开发的准则。如指定的标准定义了一组指导软件开发的准则。如果不能遵守这些准则，就极有可能导致质量不高。果不能遵守这些准则，就极有可能导致质量不高。通常有一组通常有一组“隐含需求隐含需求”是不被提及的（如对维是不被提及的（如对维护性的需求）。如果软件符合了明确的需求却没护性的需求）。如果软件符合了明确的需求却没有满足隐含需求，软件质量仍然值得怀疑。
125、有满足隐含需求，软件质量仍然值得怀疑。SAILOR 2005 copyright / 128 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件质量的定义软件质量的定义ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J. Fisher 定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。SAILOR 2005 copyright / 129 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件需求是度量软
126、件质量的基础。不符合需求的软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。软件就不具备质量。标准定义了一组开发准则，用来指导软件人员用标准定义了一组开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。准则，软件质量就得不到保证。软件质量是各种特性的复杂组合。它随着应用的软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不不同而不同，随着用户提出的质量要求不同而不同。同。软件质量软件质量SAILOR 2005 copyright / 130 2005年年3月月27日
127、日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件质量特性软件质量特性软件质量特性，反映了软件的本质。讨论一个软软件质量特性，反映了软件的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特件的质量，问题最终要归结到定义软件的质量特性。性。定义一个软件的质量，就等价于为该软件定义一定义一个软件的质量，就等价于为该软件定义一系列质量特性。系列质量特性。人们通常把影响软件质量的特性用软件质量模型人们通常把影响软件质量的特性用软件质量模型来描述。来描述。SAILOR 2005 copyright / 131 2005年年3月月27日日 电子科技大学电子科技大学 计
128、算机学院计算机学院 软件工程技术软件工程技术软件质量模型软件质量模型软件质量特性定义成分层模型软件质量特性定义成分层模型最基本的叫做基本质量特性，它可以由一些子最基本的叫做基本质量特性，它可以由一些子质量特性定义和度量。质量特性定义和度量。二次特性在必要时又可由它的一些子质量特性二次特性在必要时又可由它的一些子质量特性定义和度量。定义和度量。1976年年 Boehm质量模型质量模型1979年年 McCall质量模型质量模型1985年年 ISO质量模型质量模型SAILOR 2005 copyright / 132 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工
129、程技术软件工程技术软件质量模型软件质量模型SAILOR 2005 copyright / 133 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术ISOISO的软件质量评价模型的软件质量评价模型按照按照ISO/TC97/SC7/WG3/1985-1-30/N382，软件质量度量模型由三层组成软件质量度量模型由三层组成软件质量需求评价准则（软件质量需求评价准则（SQRC）软件质量设计评价准则（软件质量设计评价准则（SQDC）软件质量度量评价准则（软件质量度量评价准则（SQMC）高层和中层建立国际标准，低层可由各使用高层和中层建立国际标准，低层可
130、由各使用单位视实际情况制定单位视实际情况制定SAILOR 2005 copyright / 134 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术Boehm质量模型质量模型SAILOR 2005 copyright / 135 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件质量软件质量McCall模型中的软件质量要素模型中的软件质量要素产品产品修改修改产品产品变迁变迁产品产品运行运行易维护性易维护性灵活性灵活性易测试性易测试性易移植性易移植性易复用性易复用性互用性互用性正确性正确性
131、可靠性可靠性 高效率高效率完整性完整性 易使用性易使用性SAILOR 2005 copyright / 136 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术软件质量保证软件质量保证 软件质量保证（软件质量保证（SQA）是一种应用于整个是一种应用于整个软件过程的保护性活动。软件过程的保护性活动。SQA包括：包括：一种质量管理方法一种质量管理方法有效的软件工程技术（方法和工具）有效的软件工程技术（方法和工具）在整个软件过程中采用的正式技术复审在整个软件过程中采用的正式技术复审一种多层次的测试策略一种多层次的测试策略对软件文档及其修改的控制对软
132、件文档及其修改的控制保证遵从软件开发标准的规程保证遵从软件开发标准的规程度量和报告机制度量和报告机制SAILOR 2005 copyright / 137 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SQA小组小组 在一个组织中有多个机构负有保证软件质在一个组织中有多个机构负有保证软件质量的责任，包括软件工程师、项目管理者、量的责任，包括软件工程师、项目管理者、客户、销售人员和客户、销售人员和SQA小组成员。小组成员。SQA小组负责质量保证的计划、监督、记小组负责质量保证的计划、监督、记录、分析及报告工作。录、分析及报告工作。SQA小组充
133、当客户在公司内部的代表。这小组充当客户在公司内部的代表。这就是说，就是说，SQA小组的成员必须以客户的观小组的成员必须以客户的观点看待软件。点看待软件。SAILOR 2005 copyright / 138 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SQA计划计划 SQA计划为建立软件质量保证提供一张行计划为建立软件质量保证提供一张行路图，其由路图，其由SQA小组和项目组共同制定，充当小组和项目组共同制定，充当软件项目中软件项目中SQA活动的模板。活动的模板。需要进行的评价；需要进行的评价；需要进行的审计和复审；需要进行的审计和复审；项
134、目可采用的标准；项目可采用的标准；错误报告和跟踪过程；错误报告和跟踪过程；由由SQA小组产生的文挡；小组产生的文挡；为软件项目组提供的反馈数量。为软件项目组提供的反馈数量。SAILOR 2005 copyright / 139 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术SQA活动活动为项目准备为项目准备SQA计划；计划；参与开发该项目的软件过程描述；参与开发该项目的软件过程描述；复审各项软件工程活动、对其是否符合定义好的软件过程复审各项软件工程活动、对其是否符合定义好的软件过程进行核实；进行核实；审计指定的软件工作产品、对其是否符合定义
135、好的软件过审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实；程中的相应部分进行核实；确保软件工作及工作产品产品中的偏差已被记录在案，并确保软件工作及工作产品产品中的偏差已被记录在案，并根据预定规程进行处理；根据预定规程进行处理；记录所有不符合的部分，并报告给高级管理者；记录所有不符合的部分，并报告给高级管理者；协调变化的控制和管理，并帮助收集和分析软件度量信息。协调变化的控制和管理，并帮助收集和分析软件度量信息。SAILOR 2005 copyright / 140 2005年年3月月27日日 电子科技大学电子科技大学 计算机学院计算机学院 软件工程技术软件工程技术总总 结结 任何工程方法（包括软件工程）必任何工程方法（包括软件工程）必须以有组织的质量保证为基础。全面的质须以有组织的质量保证为基础。全面的质量管理和类似的理念刺激了不断的过程改量管理和类似的理念刺激了不断的过程改进，正是这种改进导致了更加成熟的软件进，正是这种改进导致了更加成熟的软件工程方法的不断出现。支持软件工程的根工程方法的不断出现。支持软件工程的根基就在于对质量的关注。基就在于对质量的关注。
