《第十章 软件项目管理.ppt》由会员分享，可在线阅读，更多相关《第十章 软件项目管理.ppt（89页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、情景情景3.1 3.1 软件项目管理软件项目管理 大型软件工程项目的失败-才使人们逐渐认识到软件项目管理的重要性和特殊性。失败的原因-不是软发工程师无能，而主要是管理不善。所谓管理-就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。软件项目管理-先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理-从一组项目计划活动开始，其基础是工作量估算和完成期限估算。213.1 13.1 估算软件规模估算软件规模13.1.1 代码行技术 代码行技术是比较简单的定量估算软件规模的方法。为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师
2、分别做出估计。每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)，分别算出这3种规模的平均值，再用下式计算程序规模的估计值 L=单位是代码行数（LOC），或是千行代码数（KLOC）3代码行技术的主要优点：代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。代码行技术的缺点：源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。413.1.2 功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这
3、种方法用功能点（FP）为单位度量软件规模。1.信息域特性 功能点技术定义了信息域的5个特性：（1）输入项数(Inp)：用户向软件输入的项数，这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。（2）输出项数(Out)：软件向用户输出的项数，它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。（3）查询数(Inq)：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。（4）主文件数(Maf)：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。（5）外部接口数(Inf)：机器可读的全部接口（
4、例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。52.估算功能点的步骤（1）计算未调整的功能点数UFP 首先，把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。然后，用下式计算未调整的功能点数UFP：UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf其中，ai(1i5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1（见书297页）所示。6(2)
5、计算技术复杂性因子TCF 这一步骤度量14种技术因素对软件规模的影响程度。这些因素包括高处理率、性能标准（例如，响应时间）、联机更新等，在表13.2（见书297页）中列出了全部技术因素，并用Fi(1i14)代表这些因素。根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI：DI=技术复杂性因子TCF由下式计算：TCF=0.65+0.01DI 因为DI的值在070之间，所以TCF的值在0.651.35之间。7（3）计算功能点数FP 用下式计算功能点数FP：FP=UFPTCF 功能点数与所用的编程语言无关，看
6、起来功能点技术比代码行技术更合理一些。但是，在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。813.2 工作量估算 软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。913.2.1 13.2.1 静态单变量模型静态单变量模型这类模型的总体结构形式如下：E=A+B(ev)C其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。
7、下面给出几个典型的静态单变量模型。1.面向KLOC的估算模型(1)Walston_Felix模型:E=5.2(KLOC)0.91(2)Bailey_Basili模型:E=5.5+0.73(KLOC)1.16(3)Boehm简单模型:E=3.2(KLOC)1.05(4)Doty模型（在KLOC9时适用）:E=5.288(KLOC)1.047102.面向FP的估算模型 (1)Albrecht&Gaffney模型 E=-13.39+0.0545FP (2)Maston,Barnett和Mellichamp模型 E=585.7+15.12FP 从上面列出的模型可以看出，对于相同的KLOC或FP值，用不
8、同模型估算将得出不同的结果。主要原因是，这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。1113.2.2 13.2.2 动态多变量模型动态多变量模型 动态多变量模型也称为软件方程式，它是根据从4000多个当代软件项目中收集的生产率数据推导出来的。该模型把工作量看作是软件规模和开发时间这两个变量的函数。动态多变量估算模型的形式如下：E=(LOCB0.333/P)3(1/t)4 (13.2)其中，E是以人月或人年为单位的工作量；t是以月或年为单位的项目持续时间；B
9、是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=515），B=0.16,对于超过70 KLOC的程序，B=0.39;P是生产率参数，它反映了下述因素对工作量的影响：总体过程成熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；应用系统的复杂程度。开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。从（13.2）式可以看出，开发同一个软件（即LOC固定）的时候，如
10、果把项目持续时间延长一些，则可降低完成项目所需的工作量。1213.2.3 COCOMO2模型模型COCOMO是构造性成本模型（constructive cost model)的英文缩写。1981年Boehm在软件工程经济学中首次提出了COCOMO模型。1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。这些模型既可以用于不同类型的项目，也可以用于同一个项目的不同开发阶段。这3个层次的估算模型分别是 （
11、1）应用系统组成模型。这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。（2）早期设计模型。这个模型适用于体系结构设计阶段。（3）后体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。13下面以后体系结构模型为例，介绍COCOMO2模型。该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数：E=(13.3)其中:E 是开发工作量（以人月为单位），A 是模型系数，KLOC 是估计的源代码行数（以千行为单位），B 是模型指数，fi(i=117)是成本因素。每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。这些成本因
12、素对任何一个项目的开发工作量都有影响，即使不使用COCOMO2模型估算工作量，也应该重视这些因素。Boehm把成本因素划分成产品因素、平台因素、人员因素和项目因素等4类。表13.3（见书300页）列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。1413.3 13.3 进度计划进度计划 项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。软件项目的进度安排是通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工
13、作量分布于计划好的项目持续期内。进度计划将随着时间的流逝而不断演化。在项目计划的早期，首先制定一个宏观的进度安排表，标识出主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展，把宏观进度表中的每个条目都精化成一个详细进度表，从而标识出完成一个活动所必须实现的一组特定任务，并安排好了实现这些任务的进度。15软件开发小组人数与软件生产率的软件开发小组人数与软件生产率的关系关系n当几个人共同承担软件开发项目中的当几个人共同承担软件开发项目中的某一任务时，某一任务时，人与人之间必须通过交人与人之间必须通过交流来解决各自承担任务之间的接口问流来解决各自承担任务之间的接口问题题，即所谓，即所谓通信
14、问题通信问题。通信需花费时。通信需花费时间和代价，会引起软件错误增加，降间和代价，会引起软件错误增加，降低软件生产率。低软件生产率。16n若两个人之间需要通信，则称在这两若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个人之间存在一条通信路径。如果一个软件开发小组有个软件开发小组有 n 个人，每两人之个人，每两人之间都需要通信，则总的通信路径有间都需要通信，则总的通信路径有 n(n-1)/2(条条)。17n设一个人单独开发软件，生产率是设一个人单独开发软件，生产率是5000行人年行人年。若。若 4 个人个人组成一个小组成一个小组共同开发这个软件，则需要组共同开发这个软件，则需要
15、 6条通条通信路径信路径。若在每条通信路径上耗费的。若在每条通信路径上耗费的工作量是工作量是 250 行人年行人年。则小组中每。则小组中每个人的软件生产率降低为个人的软件生产率降低为 500062504 =5000375 =4625 行人年。行人年。18n从上述分析可知，从上述分析可知，一个软件任务由一一个软件任务由一个人单独开发，生产率最高个人单独开发，生产率最高；而对于；而对于一个稍大型的软件项目，一个人单独一个稍大型的软件项目，一个人单独开发，时间太长。因此开发，时间太长。因此软件开发小组软件开发小组是必要的是必要的。n但是，开发小组不宜太大，成员之间但是，开发小组不宜太大，成员之间避免
16、太多的通信路径。避免太多的通信路径。n在开发进程中，切忌中途加人，避免在开发进程中，切忌中途加人，避免太多的生产率损失。太多的生产率损失。19任务的确定与并行性任务的确定与并行性n当参加同一软件工程项目的人数不止当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现并行一人的时候，开发工作就会出现并行情形。情形。n软件开发进程中设置许多里程碑。里软件开发进程中设置许多里程碑。里程碑为管理人员提供了指示项目进度程碑为管理人员提供了指示项目进度的可靠依据。的可靠依据。n软件工程项目的并行性提出了一系列软件工程项目的并行性提出了一系列的进度要求。的进度要求。2021n因为并行任务是同时发生的，
17、所以进因为并行任务是同时发生的，所以进度计划表必须决定任务之间的从属关度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。确定各个任务完成的持续时间。n项目负责人应注意构成关键路径的任项目负责人应注意构成关键路径的任务，即若要保证整个项目能按进度要务，即若要保证整个项目能按进度要求完成，就必须保证这些任务要按进求完成，就必须保证这些任务要按进度要求完成。度要求完成。22制定开发进度计划制定开发进度计划n402040规则规则u在整个软件开发过程中，编码工作在整个软件开发过程中，编码工作量仅占量仅占 20，编码前工作量占，
18、编码前工作量占40，编码后工作量占编码后工作量占 40。u 402040 规则只应用来做为规则只应用来做为 一一个指南。实际的工作量分配比例必个指南。实际的工作量分配比例必须按照各项目的特点来决定。须按照各项目的特点来决定。23估算开发时间估算开发时间T T的方程的方程:(1)(1)Walston_FelixWalston_Felix模型模型 T=2.5ET=2.5E0.350.35 (2)(2)原始的原始的COCOMOCOCOMO模型模型 T=2.5ET=2.5E0.380.38 (3)COCOMO2 (3)COCOMO2模型模型 T=3.0ET=3.0E0.33+0.20.33+0.2(b
19、-1.01)(b-1.01)(4)Putnam (4)Putnam模型模型 T=2.4ET=2.4E1/31/3 其中，其中，E E是开发工作量（以人月为单位），是开发工作量（以人月为单位），T T是开发时间（以月为单位）。是开发时间（以月为单位）。24进度安排的方法进度安排的方法n可以把用于一般开发项目的进度安排可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。的技术和工具应用于软件项目。n为监控为监控软件项目的进度计划和工作的软件项目的进度计划和工作的实际进展情况实际进展情况，为表现，为表现各项任务之间各项任务之间进度的相互依赖关系进度的相互依赖关系，需要采用图示，需要采用图示的
20、方法。的方法。n在图示方法中，必须明确标明：在图示方法中，必须明确标明：25u 各个任务的各个任务的计划开始时间计划开始时间，完成时间完成时间；u 各个任务各个任务完成标志完成标志（即（即文档编写和文档编写和评审）；评审）；u 各个任务与参与工作的人数，各个各个任务与参与工作的人数，各个任务任务与工作量之间的衔接情况与工作量之间的衔接情况；u 完成各个任务所需的物理资源和数据资完成各个任务所需的物理资源和数据资源。源。26(1)甘特图（甘特图（Gantt Chart）n在甘特图中，每一任务完成的标准，在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，不是以能否继续下一阶段任务为
21、标准，而是而是以必须交付应交付的文档与通过以必须交付应交付的文档与通过评审为标准评审为标准。因此在甘特图中，文档。因此在甘特图中，文档编制与评审是软件开发进度的里程碑。编制与评审是软件开发进度的里程碑。2728(2)PERT技术和技术和CPM方法方法nPERT技术叫做技术叫做计划评审技术计划评审技术，CPM方法叫做方法叫做关键路径法关键路径法，它们都是安排，它们都是安排开发进度，制定软件开发计划的最常开发进度，制定软件开发计划的最常用的方法。用的方法。n它们都采用网络图来描述一个项目的它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始任务网络，也就是从一个项目的开始到结束，把应当
22、完成的任务用图或表到结束，把应当完成的任务用图或表的形式表示出来。的形式表示出来。29三个模块开发的网络图三个模块开发的网络图30n通常用两张表来定义网络图。通常用两张表来定义网络图。n一张表给出一张表给出与一特定软件项目有关的与一特定软件项目有关的所有任务所有任务（也称为任务分解结构（也称为任务分解结构WorkBreakdown Structure）;n另一张表给出另一张表给出应当按照什么样的次序应当按照什么样的次序来完成这些任务来完成这些任务（有时称为限制表（有时称为限制表RestrictionList）。）。PERT技术和技术和CPM方法都为项目计划人方法都为项目计划人员提供了一些定量的
23、工具。员提供了一些定量的工具。31 确定关键路径确定关键路径，即决定项目开发时间，即决定项目开发时间的任务链。在关键路径上的各个任务的任务链。在关键路径上的各个任务都是时间余量为零的关键任务，不能都是时间余量为零的关键任务，不能有任何时间延误。有任何时间延误。应用统计模型应用统计模型，对每一个单独的任务，对每一个单独的任务确定最可能的开发持续时间的估算值。确定最可能的开发持续时间的估算值。计算边界时间计算边界时间，以便为具体的任务定，以便为具体的任务定义时间窗口。义时间窗口。32项目的追踪和控制项目的追踪和控制软件项目管理一项重要工作就是软件项目管理一项重要工作就是在在项目实施过程中项目实施过
24、程中进行进行追踪追踪和和控制控制：n定期举行项目状态会议。由每位项目定期举行项目状态会议。由每位项目成员报告其进展和遇到的问题。成员报告其进展和遇到的问题。n评价在软件工程过程中所产生的所有评价在软件工程过程中所产生的所有评审的结果。评审的结果。n确定由项目的计划进度所安排的可能确定由项目的计划进度所安排的可能选择的正式的里程碑。选择的正式的里程碑。33n比较在项目资源表中所列出的每一个比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始项目任务的实际开始时间和计划开始时间。时间。n非正式地与开发人员交谈，以得到他非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观们对
25、开发进展和刚冒头的问题的客观评价。评价。n当问题出现的时候，当问题出现的时候，项目管理人员必项目管理人员必须须实行控制以尽快地排解实行控制以尽快地排解问题。问题。3413.413.4 软件项目的组织与计划软件项目的组织与计划n制定计划制定计划n软件项目组织的建立软件项目组织的建立n人员配备人员配备35 制定计划制定计划n软件开发项目的计划涉及到实施项目软件开发项目的计划涉及到实施项目的各个环节，带有全局性质。的各个环节，带有全局性质。n计划的计划的合理性合理性和和准确性准确性往往关系着项往往关系着项目的成败。目的成败。n计划应力求完备。要计划应力求完备。要考虑到一些未知考虑到一些未知因素和不确
26、定因素因素和不确定因素，考虑到可能的修考虑到可能的修改改。计划应力求准确。计划应力求准确。尽可能提高所尽可能提高所依据数据的可靠程度依据数据的可靠程度。361.制定计划目标和进行风险分析制定计划目标和进行风险分析n制定计划的目的就是要回答：这个软制定计划的目的就是要回答：这个软件项目的范围是什么？需要哪些资源件项目的范围是什么？需要哪些资源？花费多少工作量？要用的成本有多？花费多少工作量？要用的成本有多少？以及进度如何安排等等一系列问少？以及进度如何安排等等一系列问题。题。n这步工作应当以系统计划为基础，以这步工作应当以系统计划为基础，以系统规格说明为依据。系统规格说明为依据。37n在开发工作
27、尚未开始之前，准确回答在开发工作尚未开始之前，准确回答这些问题是十分困难的。需要通过以这些问题是十分困难的。需要通过以往的开发经验做出估算，往的开发经验做出估算，很难达到准很难达到准确确。n从估算出发，项目必然带有一定的风从估算出发，项目必然带有一定的风险险。估算的准确性越差，风险也就越。估算的准确性越差，风险也就越大。研制的软件项目越复杂，规模越大。研制的软件项目越复杂，规模越大，结构化程度越低，资源、成本、大，结构化程度越低，资源、成本、进度等因素的不确定性越大，承担这进度等因素的不确定性越大，承担这一项目所冒的风险也越大。一项目所冒的风险也越大。38n组织软件项目必须事先认清可能构成组织
28、软件项目必须事先认清可能构成风险的因素，并研究战胜风险的对策，风险的因素，并研究战胜风险的对策，只有这样才能避免出现灾难性的后果，只有这样才能避免出现灾难性的后果，取得项目预期的成果。取得项目预期的成果。392.软件计划的类型软件计划的类型n针对不同工作目标，软件计划有：针对不同工作目标，软件计划有：项目实施计划项目实施计划（软件开发计划软件开发计划）这这是软件开发的综合性计划，通常应包是软件开发的综合性计划，通常应包括任务、进度、人力、环境、资源、括任务、进度、人力、环境、资源、组织等多个方面。组织等多个方面。质量保证计划质量保证计划 把软件开发的质量要把软件开发的质量要求具体规定为每个开发
29、阶段可以检查求具体规定为每个开发阶段可以检查的质量保证活动。的质量保证活动。40 软件测试计划软件测试计划 规定测试活动的任务、规定测试活动的任务、测试方法、进度、资源、人员职责等。测试方法、进度、资源、人员职责等。文档编制计划文档编制计划 规定所开发项目应编规定所开发项目应编制的文档种类、内容、进度、人员职制的文档种类、内容、进度、人员职责等。责等。用户培训计划用户培训计划 规定对用户进行培训规定对用户进行培训的目标、要求、进度、人员职责等。的目标、要求、进度、人员职责等。41 综合支持计划综合支持计划 规定软件开发过程中规定软件开发过程中所需要的支持，以及如何获取和利用所需要的支持，以及如
30、何获取和利用这些支持。这些支持。软件分发计划软件分发计划 软件开发项目完成后，软件开发项目完成后，如何提供给用户。如何提供给用户。423.项目实施计划中任务的划分项目实施计划中任务的划分n如何进行工作划分是实施计划首先应如何进行工作划分是实施计划首先应解决的问题。常用的计划结构有：解决的问题。常用的计划结构有：阶段项目计划阶段项目计划 按软件生存期，把开发工作划分为若按软件生存期，把开发工作划分为若干阶段，对每一阶段工作做出计划。干阶段，对每一阶段工作做出计划。再把每一阶段工作分解为若干任务，再把每一阶段工作分解为若干任务，做出任务计划。还要把任务细分为若做出任务计划。还要把任务细分为若干步骤
31、，做出步骤计划。干步骤，做出步骤计划。43 任务分解结构任务分解结构 按项目的实际情况进行自顶向下的结按项目的实际情况进行自顶向下的结构化分解，形成树形任务结构。进一构化分解，形成树形任务结构。进一步把工作内容、所需工作量、预计完步把工作内容、所需工作量、预计完成的期限也规定下来。成的期限也规定下来。任务责任矩阵任务责任矩阵 在任务分解的基础上，把工作分配给在任务分解的基础上，把工作分配给相关的人员，用一个矩阵形表格表示相关的人员，用一个矩阵形表格表示任务的分工和责任。任务的分工和责任。44任务分解结构任务分解结构45任务责任矩阵任务责任矩阵46 软件项目组织的建立软件项目组织的建立n开发组织
32、采用什么形式，要针对开发组织采用什么形式，要针对软件软件项目的特点项目的特点来决定，同时也来决定，同时也与参与人与参与人员的素质有关员的素质有关。1、组织原则、组织原则 (1)尽早落实责任：尽早落实责任：在软件项目工作在软件项目工作开始时，要尽早开始时，要尽早指定专人负责指定专人负责。使他。使他有权进行管理有权进行管理，并，并对任务的完成负全对任务的完成负全责责。47 （2）减少接口：）减少接口：一个组织的一个组织的生产率生产率随完成任务中存在的通信路径数目增随完成任务中存在的通信路径数目增加而降低加而降低。要有合理的人员分工、好。要有合理的人员分工、好的组织结构、有效的通信，减少不必的组织结
33、构、有效的通信，减少不必要的生产率的损失。要的生产率的损失。（3）责权均衡：）责权均衡：软件经理人员所负软件经理人员所负的责任不应比委任给他的权力还大。的责任不应比委任给他的权力还大。482.组织结构的模式组织结构的模式（1）按课题划分的模式）按课题划分的模式 把软件开发人员按课题组成小组，小把软件开发人员按课题组成小组，小组成员自始至终参加所承担课题的各组成员自始至终参加所承担课题的各项任务。他们应负责完成软件产品的项任务。他们应负责完成软件产品的定义、设计、实现、测试、复查、文定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。档编制、甚至包括维护在内的全过程。49 （2）按
34、职能划分的模式）按职能划分的模式 把参加开发项目的软件人员按任务的把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。要工作阶段划分成若干个专业小组。要开发的软件产品在每个专业小组完成开发的软件产品在每个专业小组完成阶段加工（即工序）以后，沿工序流阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划水线向下传递。例如，分别建立计划组、需求分析组、设计组、实现组、组、需求分析组、设计组、实现组、系统测试组、质量保证组、维护组等。系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间传递。各种文档资料按工序在各组之间传递。50（3）矩阵形模式）矩阵形模式 这种模式实际
35、上是以上两种模式的复这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些合。一方面，按工作性质，成立一些专门组，如开发组、业务组、测试组专门组，如开发组、业务组、测试组等；另一方面，每一个项目又有它的等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属经理人员负责管理。每个软件人员属于某一个于某一个 专门组，又参加某一项目的专门组，又参加某一项目的工作。工作。51523.程序设计小组的组织形式程序设计小组的组织形式n小组内部人员的组织形式对生产率也小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。有影响。现有的组织形式有三种。（1）主程序员制小组）主程序员制
36、小组 小组的核心由一位小组的核心由一位主程序员主程序员(高级工程高级工程师师)、二至五位、二至五位技术员技术员、一位、一位后援工程后援工程师师组成。主程序员负责小组全部技术组成。主程序员负责小组全部技术活动的计划、协调与审查，设计和实活动的计划、协调与审查，设计和实现项目中的关键部分。现项目中的关键部分。53 技术员负责项目的具体分析与开发，技术员负责项目的具体分析与开发，文档资料的编写工作。后援工程师支文档资料的编写工作。后援工程师支持主程序员的工作，为主程序员提供持主程序员的工作，为主程序员提供咨询，也做部分分析、设计和实现的咨询，也做部分分析、设计和实现的工作。并在必要时能代替主程序员工
37、工作。并在必要时能代替主程序员工作。作。主程序员制小组还可以由一些主程序员制小组还可以由一些专家专家(如通信专家或数据库设计专家如通信专家或数据库设计专家)、辅辅助人员助人员(如打字员和秘书如打字员和秘书)、软件资料软件资料员员协助工作。协助工作。54（2）民主制小组）民主制小组 在民主制小组中，遇到问题，组内成在民主制小组中，遇到问题，组内成员之间可以平等地交换意见。员之间可以平等地交换意见。工作目工作目标的制定及做出决定都由全体成员参标的制定及做出决定都由全体成员参加。加。虽然也有一位成员当组长，但工虽然也有一位成员当组长，但工作的讨论、成果的检验都公开进行。作的讨论、成果的检验都公开进行
38、。这种组织形式强调发挥小组每个成员这种组织形式强调发挥小组每个成员的积极性。的积极性。有人认为这种组织形式适有人认为这种组织形式适合于研制时间长、开发难度大的项目。合于研制时间长、开发难度大的项目。55 （3）层次式小组）层次式小组 在层次式小组中，组内人员分为在层次式小组中，组内人员分为 三级：三级：组长（项目负责人）组长（项目负责人）一人负责全组工一人负责全组工作，包括任务分配、技术评审和走查、作，包括任务分配、技术评审和走查、掌握工作量和参加技术活动。掌握工作量和参加技术活动。他直接他直接领导二至三名领导二至三名高级程序员高级程序员，每位高级，每位高级程序员通过基层小组，管理若干位程序员
39、通过基层小组，管理若干位程程序员序员。56n这种组织结构这种组织结构只允许必要的人际通信只允许必要的人际通信。比较比较适用于项目本身就是层次结构的适用于项目本身就是层次结构的课题课题。因为这样可以把项目按功能划。因为这样可以把项目按功能划分成若干个子项目，把子项目分配给分成若干个子项目，把子项目分配给基层小组，由基层小组完成。基层小组，由基层小组完成。n这种组织方式比较适合于大型软件项这种组织方式比较适合于大型软件项目的开发。目的开发。5758 人员配备人员配备n如何合理地配备人员，也是成功地完如何合理地配备人员，也是成功地完成软件项目的切实保证。所谓合理地成软件项目的切实保证。所谓合理地配备
40、人员应包括：配备人员应包括：u 按不同阶段适时任用人员按不同阶段适时任用人员u 恰当掌握用人标准恰当掌握用人标准。591.项目开发各阶段所需人员项目开发各阶段所需人员n一个软件项目完成的快慢，取决于参一个软件项目完成的快慢，取决于参与开发人员的多少。与开发人员的多少。n在开发的整个过程中，多数软件项目在开发的整个过程中，多数软件项目是以恒定人力配备的。是以恒定人力配备的。n实际人力需求与开发进度的关系如下实际人力需求与开发进度的关系如下图中的曲线所示图中的曲线所示。6061n按此曲线，需要的人力随开发进展逐渐按此曲线，需要的人力随开发进展逐渐增加，在编码与单元测试阶段达到高峰，增加，在编码与单
41、元测试阶段达到高峰，以后又逐渐减少。以后又逐渐减少。n如果恒定地配备人力，在开发初期将会如果恒定地配备人力，在开发初期将会有部分人力资源用不上而浪费掉。在开有部分人力资源用不上而浪费掉。在开发中期，需要人力不够，造成进度的延发中期，需要人力不够，造成进度的延误。在开发后期就需要增加人力以赶进误。在开发后期就需要增加人力以赶进度。度。n恒定地配备人力将浪费人力资源。恒定地配备人力将浪费人力资源。622.配备人员的原则配备人员的原则n重质量重质量 软件项目是技术性很强的工作，软件项目是技术性很强的工作，要任用少量有实践经验、有能力的人员要任用少量有实践经验、有能力的人员去完成关键性的任务。去完成关
42、键性的任务。n重培训重培训 培养所需技术人员和管理人员培养所需技术人员和管理人员是有效解决人员问题的好方法。是有效解决人员问题的好方法。n双阶梯提升双阶梯提升 人员提升应分别按技术职人员提升应分别按技术职务和管理职务进行，不能混在一起。务和管理职务进行，不能混在一起。633.对项目经理人员的要求对项目经理人员的要求n软件经理人员是工作的组织者，软件经理人员是工作的组织者，他的他的管理能力的强弱是项目成败的关键管理能力的强弱是项目成败的关键。他应具有以下能力：他应具有以下能力：把用户提出的非技术性要求加以整理把用户提出的非技术性要求加以整理提炼提炼,以技术说明书的形式转告给分析以技术说明书的形式
43、转告给分析员和测试员。员和测试员。能说服用户放弃一些不切实际的要求能说服用户放弃一些不切实际的要求,以保证合理的要求得以满足。以保证合理的要求得以满足。64 能够把表面上似乎无关的要求集中在能够把表面上似乎无关的要求集中在一起一起,归结为归结为“需要什么需要什么”,“要解决要解决什么问题什么问题”。这是一种综合问题的能。这是一种综合问题的能力。力。要懂得心理学要懂得心理学,能说服上级领导和用能说服上级领导和用户，让他们理解什么是不合理的要求。户，让他们理解什么是不合理的要求。但又要使他们毫不勉强但又要使他们毫不勉强,乐乐 于接受，于接受，并受到启发。并受到启发。654.评价人员的条件评价人员的
44、条件n软件项目中人的因素越来越受重视。软件项目中人的因素越来越受重视。在评价和任用软件人员时，必须掌握在评价和任用软件人员时，必须掌握一定的标准。一定的标准。人员素质的优劣常常影人员素质的优劣常常影响到项目的成败响到项目的成败。牢固掌握计算机软件的基本知识和技牢固掌握计算机软件的基本知识和技能。能。善于分析和综合问题，具有严密的逻善于分析和综合问题，具有严密的逻辑思维能力。辑思维能力。66 工作踏实、细致工作踏实、细致,不靠碰运气，遵循不靠碰运气，遵循标准和规范，具有严格的科学作风。标准和规范，具有严格的科学作风。工作中表现出有耐心、有毅力、有责工作中表现出有耐心、有毅力、有责任心。任心。善于
45、听取别人的意见，善于与周围人善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。员团结协作，建立良好的人际关系。具有良好的书面和口头表达能力。具有良好的书面和口头表达能力。6713.5 质量保量保证1 1软件质量软件质量2 2 软件质量就是软件质量就是“软件与明确地和隐软件与明确地和隐含地定义的需求相一致的程度含地定义的需求相一致的程度”。更具体更具体地说，软件质量是软件与明确地叙述的功地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具准以及任何专业开发的软件产品都应该具有的隐含特征相一致
46、的程度。有的隐含特征相一致的程度。68软件质量因素与产品活动的关系软件质量因素与产品活动的关系692 2软件质量保证措施软件质量保证措施 软件质量保证（software quality assurance SQA）的措施主要有：基于非执行的测试（也称为复审或评审），主要用来保证在编码之前各阶段产生的文档的质量；基于执行的测试（即以前讲过的软件测试）,需要在程序编写出来之后进行，它是保证软件质量的最后一道防线；程序正确性证明，使用数学方法严格验证程序是否与对它的说明完全一致。70参加软件质量保证工作的人员，可以划分成下述两类：软件工程师通过采用先进的技术方法和度量，进行正式的技术复审以及完成计划
47、周密的软件测试来保证软件质量。SQA小组的职责，是辅助软件工程师以获得高质量的软件产品。其从事的软件质量保证活动主要是：计划，监督，记录，分析和报告。简而言之，SQA小组的作用是，通过确保软件过程的质量来保证软件产品的质量。71软件质量保证具体措施软件质量保证具体措施1.走走 查2.审审 查查3.测测 试试4.证证 明明 7213.6 软件配置管理件配置管理（SCM）Software Configuration Management 在开发软件的过程中，变化（或称为变动）既是必要的，又是不可避免的。但是，变化也很容易失去控制，如果不能适当地控制和管理变化，势必造成混乱并产生许多严重的错误。软件
48、配置管理是在软件的整个生命期内管理变化的一组活动 标识变化；控制变化；确保适当地实现了变化；向需要知道这类信息的人报告变化。配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。软件配置管理的目标是，使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。7313.6.1 软件配置件配置1.软件配置件配置项 计算机程序（源代算机程序（源代码和可和可执行程序）；行程序）；描述描述计算机程序的文档（供技算机程序的文档（供技术人人员或用或用户使用）；使用）；数据（程序内包含的或在程序外的）。数据（程序内包含的或在程序外的）。为了开发出高质量的软件产品，软件开发人
49、员为了开发出高质量的软件产品，软件开发人员不仅要努力保证每个软件配置项正确，而且必须保不仅要努力保证每个软件配置项正确，而且必须保证一个软件的所有配置项是完全一致的。证一个软件的所有配置项是完全一致的。742.2.基线基线 IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一
50、个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。7513.6.2 软件配置管理过程软件配置管理过程 1 1、标识配置项标识配置项 2 2、进行配置控制进行配置控制 3 3、执行配置审计执行配置审计 4 4、记录配置状态记录配置状态 配置控制是核心：配置控制是核心：存取控制（开发库、基线库、产品库）存取控制（开发库、基线库、产品库）版本控制版本控制 变更控制变更控制 产品发布控制产品发布控制7613.6.3 13.6.3 常用配置管理工具常用配置管理工具1、SourceSafe SourceSaf