软件项目管理的组织与过程.docx

《软件项目管理的组织与过程.docx》由会员分享，可在线阅读，更多相关《软件项目管理的组织与过程.docx（48页珍藏版）》请在三一办公上搜索。

1、软件工程项目管理第六章 项 目 管 理26.1 项目管理概述36.1.1 项目管理的特点36.1.2 项目管理的过程46.2 项目计划56.3 进度安排66.4 项目估算66.4.1 软件规模估算76.4.2 软件开发成本估算86.5 项目组织106.5.2 人员配备106.6 软件质量106.6.1软件质量及质量保证116.6.2质量保证的主要内容116.6.3质量保证体系116.6.4软件工程标准化126.6.5 CMM模型146.7 软件配置管理156.7.1 概述166.7.2 配置管理的过程166.8 常用软件项目管理工具17 第六章 项 目 管 理 本章要点 软件项目管理概念 项目

2、管理组织及过程 软件质量及保证 CMM模型 本章学习目标 了解软件项目管理的任务与目标、软件的作用范围 理解可行性研究、成本估算技术与成本估算模型、软件项目的组织与计划、软件质量保证。 理解软件能力成熟度模型（CMM）的基本概念、软件过程的成熟度等级、关键过程区域、软件企业如何实施CMM。 掌握软件管理技术的基本方法。6.1 项目管理概述软件项目管理同样体现出管理的四个基本职能，即计划、组织、领导和控制。软件项目管理是项目管理方法的一个应用领域，项目管理就是为了满足甚至超越项目涉及人员对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去。要想满足或超过项目涉及人员的需求和期望，

3、我们是需要在下面这些相互间有冲突的要求中寻求平衡： 范围、时间、成本和质量 有不同需求和期望的项目涉及人员 明确表示出来的要求（需求）和未明确表达的要求（期望）项目管理关注计划和资源分配以保证在预算内按时完成质量合格的系统。项目管理也面临技术开发同样的问题：复杂和变化。复杂的产品需要很多有着不同背景和能力的开发者参与开发。市场竞争和需要使开发过程需要变化，带来了经常性的资源重新分配，并使得对项目状况的跟踪也变得困难。管理者和开发者使用同样的方法处理和多变问题：通用模型、交流、基本原理和配置。 项目管理已经成为一种广泛应用于各行各业的技术管理过程。在软件行业，对项目实施有效的管理是软件成败的关键

4、。项目管理已经得到越来越多的企业和政府部门的重视，学习和借鉴国际上先进的项目管理经验是非常明智和有益的。软件企业的项目规范是许多公司通过几十年的摸索和实践逐步发展形成的。随着我国正式加入世界贸易组织（WTO），我国与国际上的交流与合作更加频繁，越来越多的国内软件将承接外包软件作为业务发展的一个方向。外包软件指的是发达国家的企业将软件开发项目转移到他国。利用他国廉价的劳动力成本来降低软件开发的成本。国外企业选择外包软件的合作伙伴时，最看重的是项目管理的项目经理的综合素质要求较高，好的项目经理应该在软件开发技术，软件开发技术，软件工程理论与实践，项目管理，人际沟通等方面均要有较深的造诣。6.1.1

5、 项目管理的特点软件项目管理除涉及计算机软硬件领域技术外，还涉及到系统工程学、心理学、社会学、经济学、乃至法律等方面的问题。需要用到多方面的综合知识，特别是要涉及到社会的因素、精神的因素、人的因素比技术问题复杂得多。在相关领域的研究成果和实践已经比较丰富，但在具体的软件项目实践中，必须结合该项目的工作条件、人员和社会环境等多种因素来开展和实施。软件工程发展的实践证明，软件项目成败的关键往往在于项目管理能力水平的高低，管理得好就能带来效率，赢得时间，最终将在技术前进的道路上取得领先地位。软件项目的特点：软件产品与其他任何产业产品相比有它自己的特点，它是无形的，没有物理属性，它是一个物理系统的逻辑

6、影射，因此难以理解难于驾驶。但它确实是把思想、概念、算法、流程、组织、效率、优化等融合在一起了。文档编制的工作量在整个项目过程研制过程中站有很大的比重，但往往人们并不重视，因而直接影响了软件的质量。软件开发工作技术性很强，要求参加工作的人员具有一定的技术水平和实际工作的经验。另外，人员的流动对项目的影响很大，离去的人员不但带走了重要信息，还带走了工作经验。软件项目管理的困难1. 智力密集，可见性差：软件工程充满了大量高强度的脑力劳动。软件开发的成果是不可见的逻辑实体，软件产品的质量的尺度加以衡量，对于不深入掌握软件知识或缺乏软件经验的人员，是不可能领导做好软件管理工作的。2. 单位生产：在内容

7、、形式各异的基础上研制或生产，与其它领域中大规模现代化生产有着很大的差别，也自然会给管理工作造成许多实际困难。3. 劳动密集，自动化程度低：软件项目经历的各个阶段都渗透了大量的手工劳动，这些劳动十分细致、复杂和容易出差。尽管近年来已经有了软件工具和CASE的研究，但远未达到 自动化的程度。软件产品的提高自然受到了很大影响。4. 使用方法繁琐，维护困难：软件工作渗透人的因素：不仅要求软件人员具有一定的技术水平和工作经验，而且还要求他们具备良好的心理素质。软件人员的情绪和他们的工作环境对他们工作有好大的影响。在总结和分析足够数量失误的软件项目之后，看出其原因大都与管理工作有关问题渗透及到软件项目研

8、制中的计划制定，进度估计资源使用，人员配备，组织机构和管理方法等管理的许多侧面。软件项目管理的主要职能包括：制定计划：规定待完成的任务、要求、资源和进度等建立组织：为实施计划，保证任务的完成，需要建立分工明确的责任制度。配备人员：任何各种层次的技术人员和管理人员。指导：鼓励和动员软件人员完成所分配的工作。检验：对照计划和标准，监督和检查实施的情况。6.1.2 项目管理的过程为使软件项目开发获得最终成功，必须对软件项目的工作范围，可能遇到的风险，需要的资源（人，软/硬件），要实现的任务，过程中的里程碑，花费的工作量（成本），以及进度的安排作到心中有数。软件项目管理应该提供这些信息，这种管理开始于

9、技术工作开始之前，在软件从概念到实现的过程中持续进行，最后终止于软件项目工程结束。通常，软件项目管理包括以下过程：1 软件项目启动通常，项目管理人员和用户是在系统工程启动阶段确定项目的目标和范围。当明确了软件项目的目标和范围后，就考虑可能的解决方案，标明技术和管理上的要求，确定合理，精确成本估算，实际可行的任务分解以及可管的进度安排。2 度量 度量的工作是为了有效地定量地进行管理。度量的目的是为了把握软件工程实际情况和它所生产的产品质量。在对过去未度量的事项进行度量时，需要解决是哪些适合于过程和产品,如何使用收集到的数据，用于比较个人、过程或产品的度量是否合理。3估算在软件项目管理过程中一个关

10、键的活动是制定项目计划。在做计划时，必须就需要的人力、项目持续时间、成本作出估算。这种估算大多是参考以前的花费作出的 。管理人员可使用各种估算技术，并可用一种估算技术作为另一种估算技术的交叉检查。4风险分析风险分析对软件项目管理是决定性的，风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括风险识别、风险估计、风险管理方案、风险解决和风险监督，它能让人们去主动“攻击”风险。5进程安排软件项目的进程安排与任何一个项目的进程安排没有实质上的不同。首先识别一组项目任务，再建立任务之间的相互关联，然后估算各个任务的工作量，分配人力和其它资源，制定进度时序。6追踪和控制项目管理人员追踪在

11、制度安排的每个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。此外，还可以对资源重新定向，对任务重新安排或者可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制软件的开发。6.2 项目计划计划是管理工作的重要职能，在软件项目管理中，软件项目从制定项目计划开始。项目计划中需要确定以下几项内容：目标：定义了待完成的目标，迫切需要的资源，约束和优先级。范围：定义待开发系统的边界，什么包括在系统里，什么不包括在系统里。产品技术说明：说明软硬件信息以及有关功能、性能、安全性等方面的约束。时间：进度表。资金：预

12、算。地点：工作空间分配。人员：参与人员以及项目组织。在这里，我们强调，项目计划所需确定的内容最终必须以文档的形式保留下来，无论软件项目的规模多少，项目计划文档都是必需的。因为：1、撰写项目计划的过程也是一个澄清模糊认识，整理思路的过程，只有用文字记录下来的东西，才是明确的。2、文档能够作为同其他人的沟通渠道。项目计划可以帮助客户了解我们的开发活动，帮助项目组成员了解项目的约束和策略，帮助项目经理跟踪项目的进展。3、项目计划文档可以作为数据基础和检查列表。通过定期回顾，项目经理能清楚项目所处的状态以及哪些环节需要重点进行更改和调整。很明显，在做这些计划时并为进行项目需求分析，所依据的基础是系统计

13、划，以系统规格说明为依据。要准确回答以上问题是比较困难的，主要靠的是估计，估计的准确程度也与项目的风险直接相关。 项目计划针对不同的工作目标，类型有如下几种:项目实施计划，这是软件开发的综合性计划，包括人物、进度、人力、环境、资源，组织等。质量保证计划，把软件开发的质量要求具体规定为在每批个开发阶段中可以检查的质量保证活动。软件测试计划，规定测试活动的人物、测试方法、进度、资源、人员职责等。文档编制计划，规定所开发的项目应编制的文档种类、内容、进度、人员职责等。用户培训计划，规定对用户进行培训的目标、要求、进度、人员职责等。综合支持计划，规定软件开发过程中所需要的支持，以及如何获得和利用这些支

14、持。软件分发计划，软件项目完成后，如何提交给客户。在以上各类计划中，软件项目实施计划是综合性的，进行工作的划分是该计划应首先解决的问题，常用的计划结构有按阶段进行项目的计划,任务分解结构和人物责任矩阵。 6.3 进度安排软件开发项目的进展安排有两种考虑方式：1.统最终交付日期已经确定，软件开发部门必须在规定期限内完成任务。2.系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定进度安排的准确程度可能比成本估算程度更重要。如果进度安排落空，会导致市场机会的丧失，使得用户不满意，而且也会导致成本的增加。因此，在考虑进度安排时，要把人员的工作量与花费的时间联系起来对于一个小型软件开发项

15、目，一个人就可以完成需求分析、设计、编码和测试工作。而对于一个稍大型的软件项目，一个人单独开发，时间太长。因此，软件开发组是必要的。一般软件开发组的规模不能太大，人数不能太多，2-8人左右较合适当参加同一软件工程项目的人数超过一人的时候，开发工作就会出现并行情况。在软件开发过程的各个活动中，第一项任务是进行项目的需求分析和评审，此项工作为以后的并行工作打下了基础。一旦软件的需求得到认可，并且通过了评审、概要设计（系统结构设计和数据设计）工作和测试计划制定工作就可以并行进行。如果系统的模块结构已经建立，对各个模块的详细设计、编码、单元测试等工作也可以并行进行。待到每个模块都已经完成，就可以对它们

16、进行组织，并进行组装测试。最后，进行确认测试，为软件交付进行确认工作。软件工程项目的并行性提出一系列进度要求。因为并行任务是同时发生的，以进度计划决定任务之间的从属关系，确定各个任务的先后次序和衔接，以及各个任务完成的持续时间。此外，应注意构成关键路径的任务，即要保证整个项目能按进度要求完成，就必须保证这些关键任务要按进度要求完成。这样，就可以确定在进度安排中应保证的重点。前人在整个定义与开发的阶段工作量分配了一种建议方案。这个分配方案称为40-20-40规则。它指出在整个软件开发过程中，编码的工作量分配仅占20%，编码前的工作量占40%，编码后的工作量占40%。40-20-40规则只是用来作

17、为一个指南，实际的工作量分配比例必须按照每个项目的特点来决定。一般在计划阶段的工作量很少超过总工作量的2%-3%，除非是具有高风险的巨额投资的项目。需求分析可能占总工作量的10%-25%。花费在分析或原型化方面的工作量应当随项目规模和复杂性成比例地增加。通常用于软件设计的工作量在20%-25%之间，而在设计评审与反复修改的时间也必须考虑在内。由于软件设计已经投入了工作量，因而其后的编码工作相对来说困难要小一些，用工作量的15%-20%就可以完成。测试和随后的调试工作约占总工作量的30%-40%，所需要的测试量往往取决于软件的重要程序。在项目实施过程中进行追踪和控制是软件项目管理的一项重要工作。

18、比如定期举行项目状态会议。评价在软件工程过程中所产生的所有评审的结果。确定由项目的计划进度所安排的可能选择的正式的里程碑，比较在项目计划表中所列出的每个想没的任务的实际开始时间和计划开始时间。6.4 项目估算软件项目管理过程从一开始被称为项目计划的活动开始。这些活动中的第一个是估算。无论何时进行估算，我们都是在预测未来没，在做软件项目估算时往往存在某些不确定性，使得软件项目管理人员无法正常迟迟不能完成。虽然估算是一门科学，但它更是一门艺术，可这个重要的活动不能以随意的方式开进行。现在已使用的实用技术是时间和工作量估算。因为估算是所有其他项目计划活动的基石，且项目计划又为软件工程提供了工作方向，

19、所以不能没有计划就着手开发，否则将会陷入盲目开发。对软件项目进行有效的估算，取决于掌握多少有关项目范围的原始资料。通常，应当根据正式的需求描述进行估算。正式的需求描述可以是需求说明书、系统规格说明书或软件需求说明书等。如果开始时缺乏一些正式的资料，也可以采用口头描述或草稿的方式开始估算工作。在得到项目范围的正式资料后，必须进行再估算。估算的两个主要方法是： 第一种方法是根据项目特征和算法进行估算。例如，根据软件系统的输入、输出、查询、文件及外部接口等信息、使用功能点估算出系统的规模。基于功能点估算是按照用例（Use case）来做的，而不是软件功能来做。通过研究初始应用需求来确定各种输入、输出

20、、计算和数据库需求的数量和特性。 第二种方法是采用类比的方法，根据历史数据来进行估算。如果有一个以前做过的类似项目并且掌握它的规模，就可以把新项目的各个主要部分与原有项目的相应部分进行比较，得出一个比例关系，将各部分相对于原项目规模比例相加，计算出新项目的规模。如果估算者的经验丰富并且新项目与老项目具有足够的相似性，就能够得到合理的估算值。但是采用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。6.4.1 软件规模估算软件

21、项目的规模估计历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估计往往和实际情况相差甚远。 因此，估计错误已被列入软件项目失败的主要原因之一。先介绍一个衡量软件项目规模最常用的概念-LOC(Line of Code)，LOC指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：Job Control Language）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。例如，某软件公司统计

22、发现该公司每一万行C语言源代码形成的源文件（.c和.h文件）约为250K。某项目的源文件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用公滩等），则该项目中1LOC的价值为： （24010000）/15000016元/LOC 改项目的人月均代码行数为： 150000/240=625LOC/人月 方法一、Delphi 法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家专的程度及对项目的理解程度是工作中的难点，尽管Delphi

23、技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种软件相关经验人的参与，互相说服对方。 Delphi法的步骤是： 1、协调人向各专家提供项目规格和估计表格； 2、协调人召集小组会各专家讨论与规模相关的因素； 3、各专家匿名填写迭代表格； 4、协调人整理出一个估计总结，以迭代表的形式返回专家； 5、协调人召集小组会，讨论较大的估计差异； 6、专家复查估计总结并在迭代表上提交另一个匿名估计； 7、重复4-6， 直到达到一个最低和最高估计的一致。 方法二、 类比法 类比法

24、适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。 其基本步骤是： 1、整理出项目功能列表和实现每个功能的代码行； 2、标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方； 3、通过步骤1和2得出各个功能的估计值； 4、产生规模估计。 软件项目中用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码

25、，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行： 等价代码行 = (重新设计% +重新编码% +重新测试%)/3 已有代码行 方法三、功能点估计法 功能点测量是在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。通常的步骤是： 1、计算输入，输出，查询，主控文件，和接口需求的数目。 2、将这些数据进行加权乘。下表为一个典型的权值表。 功能类型 权值 输入 4 输出 5 查询 4 主控文件 10 接口 10 3、估计者

26、根据对复杂度的判断，总数可以用+25%、0、或-25%调整。 据发现，对一个软件产品的开发，功能点对项目早期的规模估计很有帮助。然而，在了解产品越多后，功能点可以转换为软件规模测量更常用的LOC。6.4.2 软件开发成本估算软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。它不同于其他物理产品的成本，不包括原材料和能源的消耗，主要是人的劳动消耗。人的劳动消耗所需代价就是软件产品的的开发成本。另一方面，软件产品开发的计算方法不同于其他物理产品成本的计算。软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、需求分析、

27、设计、编码、单元测试、组装测试到确认测试，整个软件开发过程所花费的代价作为依据的。对于一个大型的软件项目，要进行一系列的估算处理，主要靠分解和类推的方法进行。基本估算方法分为3类：1、自顶想下的估算方法。这种方法的主要思想是：从项目的整体出发，进行类推。即估算人员根据以前已完成项目所消耗的总成本，来推算将要开发的软件的总成本，然后按比例将它分配到各开发任务单元中去。这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。2、自底向上的估算法。这种方法的主要思想是：把待开发的软件细分，直到没个子任务都已经明确所需要的开发工作

28、量，然后把它们累加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各部分的准确性高。缺点是缺少各个子任务之间相互联系所需要的工作量，还缺少许多同软件开发有关的系统级工作量。所以估算值往往偏低，必须用其他方法进行校验和校正。3、差别估计法。这种方法综合了上述两种方法的优点，其主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种方法的优点是提高估算的准确程度，缺点是不容易明确所谓“类似”的界限。常见的几种估算模型为：1、IBM模型 1977年，IBM的Wals

29、ton和Felix提出了如下的估算公式： E 5.2L0.91，L是源代码行数(以KLOC计)，E是工作量（以PM计） D 4.1L0.36，D是项目持续时间(以月计) S 0.54E0.6，S是人员需要量(以人计) DOC 49L1.01。DOC是文档数量(以页计) 在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。 2、Putnam模型 这是1978年Putnam提出的模型，是一种动态多变量模型。它是假定在软件开发的整个生存期中工作量有特定的分布。这

30、种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。 Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。其中，td是开发持续时间（以年计），K是软件开发与维护在内的整个生存期所花费的工作量（以人年计），L是源代码行数（以LOC计），Ck是技术状态常数，它反映出“妨碍程序员进展的限制”，并因开发环境而异。其典型值的选取如下表所示。 3、COCOMO模型 这是由TRW公司开发。Boehm提出的结构型成本估算模型，是一种精确、易于使用的成本估算方法。在该模型中使用的基本量

31、有以下几个：DSI（源指令条数）定义为代码或卡片形式的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。KDSI1000DSI。MM（度量单位为人月）表示开发工作量。TDEV（度量单位为月）表示开发进度。它由工作量决定。 （1）软件开发项目的分类 在COCOMO模型中，考虑开发环境，软件开发项目的总体类型可分为三种：组织型、嵌入型和介于上述两种软件之间的半独立型。 （2）COCOMO模型的分类 COCOMO模型按其详细程度分成三级：即基本COCOMO模型、中间COCOMO模型、详细COCOMO模型。基本COCOMO模型是一个静态单变量模型，它用一个以

32、已估算出来的源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量(此时称为名义工作量)的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。 6.5 项目组织6.5.1 组织原则在建立项目组织时应注意到以下原则： （1） 早落实原则 （2） 减少接口 （3） 责权均衡6.5.2 人员配备合理地配备人员是成功地完成软件项目的切实保证。所谓合理地配备

33、人员应包括：按不同阶段适时任用人员，恰当掌握用人标准。1. 配备人员的原则： 配备软件人员时，应注意以下3个主要原则：（1） 重质量：软件项目是技术性很强的工作，任用少量有实践经验、有能力的人员去完成关键性的任务，常常要比使用教多的经验不足的人员更有限。（2） 重培训：花力气培养所需的技术人员和管理人员是有效解决人员问题的好方法。（3） 双阶梯提升：人员的提升应分别按技术职务和管理职务进行，不能混在一起。2. 对项目经理人员的要求 软件经理人员是人员的组织者，他的管理能力的强弱是项目成败的关键。除去一般的管理要求外，他应具有的能力：1）把用户提出的非技术性要求加以整理提炼，以技术说明书形式转告

34、给分析员和测试员。2）能说服用户放弃一些不切实际的要求，以便保证合理的要求得以满足。3）具有综合问题的能力。4）要懂得心理学。3. 评价人员的条件软件项目中人的因素越来越受到重视。在评价和任用软件人员时，必须掌握一定的标准。人员素质要求：1）牢固掌握计算机软件的基础知识和技能。2）善于分析和综合问题，具有严密的逻辑思维能力。3）工作踏实、细致、不靠碰运气，遵循标准和规范，具有严格的科学作风。4）工作中表现出耐心、有毅力、有责任心。5）善于听取别人的意见，善于与周围人员团结协作，建立良好的人际关系。6）具有良好的书面和口头表达能力。6.6 软件质量计算机科学与技术的迅速发展和应用范围日益广泛，计

35、算机软件的重要性与日俱增。人民对软件质量要求越来越高，对软件的质量控制和质量管理越来越重视。软件产业的迅猛发展急需软件工程方法、技术的支持，软件工程的理论也随着软件产业的实践而逐渐丰富。 6.6.1软件质量及质量保证按照ANSI/IEEE1983年的标准，软件质量定义为“与软件产品满足需求所规定的和隐含的能力有关的特征和特性的全体。”具体包括：（1） 软件产品中所能满足用户给定的全部特性的集合。（2） 软件具有所期望的各种属性组合的程度（3） 用户主观得出的软件是否满足其综合期望的程度。（4） 决定所用软件在使用中将满足其综合期望程度的软件合成特性。 软件质量是降低软件开发成本的基本保障。提高

36、软件质量是软件企业竞争的需要，是软件企业生存的基础，也是其进入国际市场的基本条件。 软件质量保证（SQA)是软件工程学科的一部分，是一个复杂的系统，它根据一系列的标准，采用一定的方法，技术和工具，处理和调整软件产品各个特性之间的相互关系，以确保软件产达到其应该达到的质量水平。6.6.2质量保证的主要内容软件工程保证应用于整个软件过程的保护活动，包括：（1） 质量管理方法（2） 有效的软件工程技术（方法和工具）。（3） 应用于整个软件过程的形式化技术评论。（4） 多等级测试策略。（5） 软件文档以及对软件进行改变和维护的控制和约束。（6） 确保遵照软件开发标准的过程。（7） 测量和报告机制。 质

37、量保证包括管理的审核和报告功能。质量保证的目的是以有关产品的基本数据进行质量管理，从而保证产品质量不断地找着其质量目标迈进。质量保证活动提供大量有关质量的基本数据，不过，根据这些数据所指出的质量问题必须通过质量管理来解决。6.6.3质量保证体系为了更好地协调好软件质与软件生产率、软件开发成本之间的关系，保证软件达到一定的质量水平，必须遵守一定的软件质量保证原则。软件质量保证原则：（1） 在开始制定项目计划时，充分考虑用户的要求，确定实用的质量特征（2） 详细制定质量计划。（3） 对阶段性成果进行各种质量检查、校对等评审活动。（4） 不断地优化和完善质量计划。（5） 尽早发现并及时改正错误和缺陷

38、。（6） 由独立的测试小组进行测试。（7） 在对开发过程进行质量评估似的基础上，检查质量测试的结果以发现与质量计划的偏差，确定适当的修改方案。6.6.4软件工程标准化随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围从只是使用程序设计语言编写程序，扩展到 整个软件生存期。诸如，软件概念的形成、需求分析、设计、实现、测 试、制造、安装和检验、运行和维护直到软件引退(为新的软件所代 替)。同时还有许多技术管理工作(如过程管理、产品管理、资源管 理)以及确认与验证工作(如评审与审计、产品分析、测试等)常常是跨越软件生存期各个阶段的专门工作。所有这些方面都应逐步 建立起标准或规范来

39、。另一方面，软件工程标准的类型也是多方面的。它可能包括过程标准(如方法、技术、度量等)、产品标准(如需求、设计、部件、 描述、计划、报告等)、专业标准(如职别、道德准则、认证、特许、课程等)以及记法标准(如术语、表示法、语言等)。 在全面考虑以上两个方面的情况下，软件工程的标准可用一张二维的表格来表示。表61(a)和(b)给出了这个二维表的大致格式。(b)表是(a)表的继续。表中填入了三个标准的例子(请注意 它们在表中所处的位置)。表6.1 (a)软件工程标准分类软 件 生 存 期 概念需求设计实现测试制造安装与检验运行与维护引退标准类型过程方法技术度量产品需求设计部件描述计划报告专业职别道德

40、准则认证特许课程记法术语表示法ISO5807语言FIPSl05是美国国家标准局发布的软件文档管理指南 (National Bureau OfStandards，Guideline for Software Documentation Management，FIPS PUB 105，June 1984) NSAC39是美国核子安全分析中心发布的安全参数显示 系统的验证与确认(Nuclear Safety Analysis Center，Verification and Validation for Safety Parameter Display Systems，NSAC39，De cember

41、l981)ISO 5807是国际标准化组织公布(现已成为我国国家标 准)的信息处理数据流程图、程序流程图、系统流程图、程序 网络图和系统资源图的文件编制符号及约定(本书第四章41节讨论过的标准程序流程图正是以此为依据)。 这个表不仅告诉了我们软件工程标准的范围和标准如何分类，而且对标准的开发具有指导作用。已经制定的标准都可在表中找到相应的位置，而且它可启发我们去制定新的标准。表6.1 (b)软件工程标准分类技术管理 确认与验证 过程管理产品管理资源管理评审与审计产品分析测试标准类型过程方法NSAC-39NSAC-39NSAC-39技术FIPS 105度量产品需求设计部件描述计划报告专业职别道德

42、准则认证特许课程记法术语表示法语言软件工程标准的制定与推行 软件工程标准的制定与推行通常要经历一个环状的生命期 (参看图61)。最初，制定一项标准仅仅是初步设想，经发起后沿着环状生命期，顺时针进行要经历以下的步骤： 图61软件工程标准的环状生命期 建议，拟订初步的建议方案 开发：制定标准的具体内容 咨询：征求并吸收有关人员意见 审批，由管理部门决定能否推出 公布：公开发布，使标准生效 培训：为推行标准准备人员条件 实施：投入使用，需经历相当期限 审核：检验实施效果，决定修订还是撤销 修订：修改其中不适当的部分，形成标准的新版本，进入 新的周期 软件工程标准化的意义为使标准逐步成熟，可能在环状生

43、命周期上循环若干圈，需要 做大量的工作。事实上，软件工程标准在制定和推行过程中还会 遇到许多实际问题。其中影响软件工程标准顺利实施的一些不利 因素应当特别引起重视。这些因素可能有： 标准本身制定得有缺陷，或是存在不够合理，不够恰当的 部分。标准文本编写得有缺点，例如，文字叙述可读性差，难于 理解，或是缺少实例供读者参阅。 主管部门未能坚持大力推行，在实施的过程中遇到问题又 未能及时加以解决。 未能及时作好宣传、培训和实施指导。 未能及时修订和更新。一个软件开发项目有多个层次、不同分工的人员相 互配合，在开发项目的各个部分以及各开发阶段之间也都存在着 许多联系和衔接问题。如何把这些错综复杂的关系协调好，需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时，需要进行阶段评审和验收测试。投入运行的软件，其维护工作中遇到的问题又与开发工作有着密切的关系。软件的管理 工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行动规范和衡量准则，使得各种工作都能有章可循。 软件工程的标准化会给软件工作带来许多好处，比如： 提高软件的可靠性、可维护性和可移植性(这表明软件工程 标准化可提高软件产品的质量) 提高软件的生产率 提高软件人员的技术水平 提高软件人员之间的通信效率，减少差错和误解