软件工程与项目管理(第2版) 课件 第2章 软件生命周期与软件过程

2.1软件生命周期

2.2软件过程的概念

2.3几种典型的软件过程模型

2.4微软公司的软件开发过程2.1软件生命周期我国国家标准《计算机软件文档编制规范》(GB/T8567—2006)把软件生命周期划分为可行性与计划研究阶段、需求分析阶段、设计阶段、实现阶段、测试阶段、运行与维护阶段六个阶段。通常，人们把可行性与计划研究阶段、需求分析阶段这两个阶段称为软件定义时期，把设计阶段、实现阶段、测试阶段这三个阶段称为软件开发时期，而把运行与维护阶段称为软件运行与维护时期。软件生命周期各个时期及阶段的关系如图2.1所示。2.1.1软件生命周期中时期与阶段的划分以及各阶段的任务1.软件定义时期在软件生命周期中，软件定义时期又可分为可行性与计划研究和需求分析两个阶段。1)可行性与计划研究阶段在可行性与计划研究阶段主要完成以下工作：(1)要确定该软件的开发目标和总的要求。(2)要进行可行性分析。(3)投资-收益分析。(4)制订开发计划。(5)完成可行性分析报告。(6)完成开发计划等文档。2)需求分析阶段在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定该软件的各项功能、性能需求和设计约束，确定文档编制的要求。作为本阶段工作的结果，一般地说软件需求规格说明(也称为软件需求说明、软件规格说明)、数据要求说明和初步的用户手册应该编写出来，主要包括：(1)需求调查：对软件的需求及其使用环境进行详细调查，掌握用户的要求和环境所能提供的条件。(2)功能、性能与环境约束分析：根据掌握的情况，对软件系统的功能(即回答系统必须做什么)、性能(包括软件的安全性、可靠性、可维护性、精度、错误处理、适应性、用户培训等)和环境约束(指待开发的软件系统必须满足运行环境方面的要求)进行分析研究，与用户取得一致的认识。(3)编制软件需求规格说明：把软件系统的功能需求、性能需求、接口需求、设计需求、基本结构、开发标准、验收原则等写成软件需求规格说明，并得到用户的确认。(4)制定软件系统的确认测试准则和用户手册概要：根据确认的软件开发标准及验收原则制定具体的软件确认测试准则和用户手册概要或提纲。2.软件开发时期软件开发时期主要包括设计阶段、实现阶段以及测试阶段。1)设计阶段在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块(或CSCI)的划分、功能的分配以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文档包括：软件(结构)设计说明、详细设计说明和测试计划初稿。(1)概要设计阶段包括以下工作：①建立软件系统的总体结构。②定义功能模块的接口。③设计全局数据库和数据结构。④规定设计约束。⑤编制概要设计文档。(2)详细设计阶段包括以下工作：①模块详细设计。②编制模块的详细规格说明。2)实现阶段在实现阶段内，要完成源程序的编码、编译(或汇编)和排错调试，得到无语法错的程序清单，要开始编写进度日报、周报和月报，并且要完成用户手册、操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。(1)编码：根据模块详细规格说明书，将详细设计转化为程序代码。(2)单元测试：对模块程序进行测试，验证模块功能及接口与详细设计文档的一致性，并形成单元测试报告。3)测试阶段在测试阶段：该程序将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。作为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。测试阶段包括组装测试阶段和确认测试阶段。在整个开发过程中(即前五个阶段中)，开发集体要按月编写开发进度月报。(1)组装测试阶段包括以下工作：①模块程序组装与测试。②编制组装测试报告。(2)确认测试阶段包括以下工作：①软件系统测试。②编制确认测试文档。③软件评审。3.软件运行与维护时期在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充、删改、更新和升级。(1)软件的使用阶段：将软件安装在用户确定的运行环境中使用。(2)软件的维护阶段：对软件产品进行修改或根据软件需求变化做出响应，并对所有的维护写出维护报告。(3)软件的退役阶段：软件一旦完成了其使命，或者由于一个新的软件生命周期的开始，就要终止对软件产品的支持，这使得软件停止使用。2.1.2软件生命周期中各阶段所占的百分比软件生命周期中各阶段所占的百分比和各阶段的参与人员如表2.1所示。2.1.3软件生命周期中各阶段的文档在软件生存周期中，一般应产生以下基本文档：(1)可行性分析(研究)报告；(2)软件(或项目)开发计划；(3)软件需求规格说明；(4)接口需求规格说明；(5)系统/子系统设计(结构设计)说明；(6)软件(结构)设计说明；(7)接口设计说明；(8)数据库(顶层)设计说明；(9) (软件)用户手册；(10)操作手册；(11)测试计划；(12)测试报告；(13)软件配置管理计划；(14)软件质量保证计划；(15)开发进度月报；(16)项目开发总结报告；(17)软件产品规格说明；(18)软件版本说明等。2.1.4各类人员使用的文档说明各类人员所使用的文档如表2.2所示。2.2软件过程的概念2.2.1软件过程的定义软件过程是用以开发和维护软件及其相关产品的一系列方法、实践、活动和转换，包括软件工程活动和软件管理活动。2.2.2软件过程的基本活动一般的软件过程包括问题提出、软件需求说明、软件设计、软件实现、软件确认、软件演化等基本活动。(1)问题提出：开展技术探索、市场调查等活动，研究系统的可行性和可能的解决方案，确定待开发系统的总体目标和范围。(2)软件需求说明：分析、整理和提炼所收集到的用户需求，建立完整的分析模型，编写软件需求规格说明和初步的用户手册。通过评审需求规格说明，确保对用户需求达到共同的理解与认识。(3)软件设计：根据软件需求规格说明文档，确定软件的体系结构，再进一步设计每个系统部件的实现算法、数据结构、接口等，编写软件设计说明书，并组织进行设计评审。(4)软件实现：将所设计的各个子系统编写成计算机可接受的程序代码。(5)软件确认：在设计测试用例的基础上，测试软件的各个组成模块，并将各个模块集成起来，测试整个产品的功能和性能是否满足已有的规格说明。(6)软件演化：整个软件过程是一个不断演化的过程，软件开发覆盖从概念的提出到形成一个可运行系统的整个过程，软件维护则是系统投入使用后所产生的修改。2.2.3软件过程的制品在软件过程的不同阶段，会产生不同的软件制品，如需求规格说明书、设计说明书、源程序代码与构件、测试用例、用户手册以及各种开发管理文档等，表2.3列出了软件过程的一些基本活动以及所产生的主要过程制品。2.2.4软件项目从立项到结题的过程通常情况下，一个软件项目从立项到结题要经过不同的阶段，每个阶段要完成相应的文档。虽然每个企业最终形成的文档不尽相同，但都是根据企业的实际情况，在国家标准的基础之上进行适当删减的结果，其基本内容如下。1.撰写立项申请书一个项目要通过填报项目申报书，经相关部门的专家评审通过后才予以立项。2.签署立项合同一个项目通过专家评审予以立项后，就要与立项相关部门签署合同，该合同具有法律效力。3.撰写开题报告双方签订好合同后，在一个月内要完成项目开题及开题报告的撰写并在相关专家的参与下完成开题工作。4.撰写中期检查报告项目进展到中期时，要接受相关部门的检查，考核是否按任务书中的进度完成了该时间点应该完成的工作。5.撰写项目结题报告书及项目开发总结报告项目完成时，需要撰写项目结题报告及项目开发总结报告。项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。6.项目验收提交项目验收相关文档后，在规定的时间内，相关部门对项目进行验收。7.发结题证书项目验收合格后，由相关部门在规定的时间内颁发结题证书。至此，该项目最终结题。2.3几种典型的软件过程模型2.3.1瀑布模型瀑布模型规定了各项软件工程活动，包括制订开发计划、进行需求分析和说明、软件设计、程序编码、测试及运行维护。瀑布模型还规定了它们自上而下、相互衔接的固定次序，如同瀑布流水一样逐级下落，如图2.2所示。瀑布模型的基本思想：根据软件生命周期中各阶段的任务，从可行性研究与计划开始，逐步进行阶段性变换，直至通过确认测试并得到用户确认的软件为止。瀑布模型的特点如下：(1)阶段间的顺序性和依赖性：上一阶段的变换结果是下一阶段变换的输入，相邻两个阶段具有因果关系，每个阶段完成任务后，都必须进行阶段性评审，确认之后再转入下一个阶段。(2)文档驱动性：要求每个阶段必须完成规定的文档并通过评审，以便尽早发现问题，改正错误。瀑布模型的优点：可强迫开发人员采用规范的方法，严格提交文档，做好阶段评审，从而使软件过程易于管理和控制，有利于软件的质量保障。瀑布模型的缺点：要求软件开发初期就要给出软件系统的全部需求，开发周期比较长，承担的风险也比较大。软件开发的实践表明，上述各项活动之间并非完全是自上而下，呈线性图式。实际情况是，每项开发活动均处于一个质量环(输入—处理—输出—评审)中。只有当其工作得到确认，才能继续进行下一项活动，在图2.2中用向下的箭头表示；否则返工，在图2.2中由向上的箭头表示。2.3.2快速原型模型快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。第二步则在第一步的基础上开发客户满意的软件产品。显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果，如图2.3所示。快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。快速原型模型的基本思想：软件开发人员根据用户提出的软件初步定义，快速开发一个原型，向用户展示原型的功能和性能，在反复征求用户对原型意见的过程中，进一步确认用户的需求并对原型进行修改和完善，直到得到用户确认的软件定义，在确认的原型基础上完成软件系统的设计、实现、测试和使用与维护。快速原型模型的特点如下：(1)原型驱动：整个软件过程围绕着原型的快速开发和对原型的评价，通过原型确认用户需求，以及通过原型的反复修改最终得到用户确认的软件定义。(2)过程的交互性和迭代性：软件过程是由开发人员与用户之间通过原型的评价和确认而进行的一个交互过程。而且这个过程不是简单的重复，而是不断改进和完善的迭代过程。快速原型模型的优点：允许用户在软件开发过程中完善对软件系统的需求，开发周期相对有所缩短，成本比较低，有效地发挥用户和开发人员之间的密切配合作用，使软件过程更能体现逐步发展、逐步完善的原则。快速原型模型的缺点：频繁的需求变化会使开发进程难于管理和控制，原型的快速开发和修改对技术要求比较高，需要有较好的工作基础。2.3.3螺旋模型对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型沿着螺线旋转，如图2.4所示，在笛卡尔坐标的4个象限上分别表达了以下4个方面的活动：(1)制订计划——确定软件目标，选定实施方案，弄清项目开发的限制条件；(2)风险分析——分析所选方案，考虑如何识别和消除风险；(3)实施工程——实施软件开发；(4)客户评估——评价开发工作，提出修正建议。沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。螺旋模型的基本思想：螺旋模型是瀑布模型和快速原型模型的结合，其基本思想是借助构建原型来降低风险，把软件开发的每一个阶段都看作是增加了风险分析的快速原型模型。螺旋模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个部分，软件开发的整个过程就是这4个部分的迭代，每迭代一次，过程就完成一个周期，软件开发就前进一个层次，系统就生成一个新的版本。螺旋模型的特点如下：(1)模型结合性：螺旋模型的每一个周期都应用了原型模型排除风险，在确认了原型之后，又启动瀑布模型继续过程的演化。因此，螺旋模型是瀑布模型和快速原型模型的结合，体现了两个模型的优点。(2)过程迭代性：软件开发过程的每个阶段都是一次迭代，这种迭代不是过程的简单重复，而是每旋转一个圈就前进一个层次，得到一个新的版本。螺旋模型的优点：强调可选方案和约束条件有利于已有软件的重用，有助于把软件质量作为软件开发的一个重要目标，减少过多或测试不足带来的风险。维护被看成是模型的另一个周期，维护和开发之间没有本质的区别。螺旋模型的缺点：要求软件开发人员具有丰富的风险评估经验和有关的专门知识，开发过程比较复杂，给过程管理和控制带来一定的难度。2.3.4增量模型在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成的。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险，如图2.5所示。增量模型也存在以下缺陷：(1)由于各个构件是逐渐并入已有的软件体系结构中的，因此加入构件必须不能破坏已构造好的系统部分，这需要软件具备开放式的体系结构。(2)在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。增量模型的基本思想：把软件产品作为一系列的增量构件来设计、实现、集成和测试。开发时分批逐步向用户提交产品，每次提交一个满足用户需求子集的增量构件，直到最后一次得到满足用户全部需求的完整产品为止。增量模型的特点：过程渐进性，即软件过程分批次完成，每次提交一个满足用户需求子集的增量构件，产品规模逐渐增大，直到得到满足用户全部需求的完整产品为止。增量模型的优点：能在较短的时间内向用户提交部分功能的构件，并且在逐步增加产品功能的过程中有充裕的时间学习和适应新的功能，减少一个全新软件可能给用户带来的冲击。增量模型的缺点：增量构件的划分依赖于系统功能的构成和软件开发人员的经验，每次集成新的增量构件必须不能破坏原有软件系统的结构，因此要求软件系统的体系结构必须具有高度的开放性和可扩充性。2.3.5喷泉模型喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。“喷泉”一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动，即分析、设计和编码之间不存在明显的边界，如图2.6所示。喷泉模型的基本思想：喷泉模型是典型的面向对象生命周期模型。“喷泉”这个词描述了面向对象软件开发过程的迭代和无缝特性。在喷泉模型中，代表开发过程不同阶段的圆圈之间互相交叠，而且各项开发活动之间是无缝过渡的。每个阶段内的向下箭头代表着阶段自身的迭代或求精，整个软件过程呈现一种开发阶段沿中轴向上，又在每一个阶段向下回流的喷泉形态，所以称为喷泉模型。喷泉模型的特点：(1)过程迭代性：在面向对象的方法中，软件开发各个阶段之间或一个阶段内的各个步骤之间都存在迭代的过程，这一点要比面向数据流或面向数据的方法更为常见。(2)阶段间的无间隙过渡性：用面向对象方法开发软件时，在分析、设计、编码等项开发活动之间并不存在明显的边界，不同阶段互相交叠，各项开发活动之间无缝过渡。喷泉模型的优点：支持面向对象方法的软件开发过程，提供软件复用与生命周期中多项开发活动集成的机制。喷泉模型的缺点：喷泉模型本身就不是以面向过程为背景的，过程在喷泉模型中已被弱化，取而代之的是无间隙的阶段过渡与重复迭代。2.3.6V形模型V形模型是瀑布模型的一个变种，如图2.7所示。它同样需要一步一步进行，前一个阶段的任务完成之后才可以进行下一阶段的任务。这个模型强调测试的重要性，它将开发活动与测试活动紧密地联系在一起。每一步都将比前一阶段进行更加完善的测试。V形模型的特点如下：(1)简单易用，只要按照规定的步骤一步一步执行即可。(2) V形模型强调测试过程与开发过程的对应性和并行性。(3) V形模型没有反映实际的开发过程，实际的开发过程会有很多的迭代过程，比如，实施过程中会发现设计中的问题，然后去修正，测试过程中也会返回前一段，重新做一些事情。V形模型使用指南：使用V形模型，要求开发过程严格按照顺序进行，一个阶段的输出是下一个阶段的输入。同时，要并行考虑图2.7中虚线所对应的过程。V形模型适合的场合：项目的需求在项目开始前很明确，解决方案在项目开始前也很明确，项目对系统的性能安全要求很严格。2.3.7形式化方法模型形式化方法模型特别适合于那些对安全性、可靠性和保密性要求极高的软件系统开发，它采用形式化的数学方法将系统描述转换成可执行的程序。形式化方法的过程模型如图2.8所示，它首先将软件需求描述提炼成采用数学符号表达的形式化描述，然后经过一系列的形式化转换将形式化描述自动转换成可执行程序，最后将整个系统集成起来进行测试。由于数学方法具有严密性和准确性，因此形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性。但是，形式化方法在实际软件开发中应用得并不多，其主要原因在于：(1)开发人员需要具备一定技能并经过特殊训练后才能掌握形式化开发方法。(2)现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述。(3)形式化描述和转换是一项费时、费力的工作，采用这种方法开发系统在成本、质量等方面并不占优势。2.3.8组合模型在实际应用中，常常把几种模型结合在一起，配套使用，这就是组合模型。模型的组合方式有两种：一种方式是以某一种模型为主，嵌入另一种或几种模型。例如，在生命周期模型中，为了帮助用户和开发人员尽快确定软件需求，在软件设计阶段之前可以嵌入原型模型。另一种方式是软件开发人员根据软件项目和软件开发环境的特点，建立一个特定的软件开发组合模型，为开发过程设计一条选择多种模型组合的路径。当然，路径的选择应根据软件开发的实际情况而定，目的是降低开发成本，缩短开发时间以及提高软件产品的质量。2.4微软公司的软件开发过程2.4.1微软开发过程管理的基本原则一个优秀软件产品的成功，除了其先进的技术含量之外，产品开发过程的科学管理也是不可或缺的重要因素。在软件产品的开发过程中，微软所遵循的一些基本原则如下：(1)以目标驱动而不是任务驱动。整个软件开发过程是以实现项目目标为最高标准的，项目团队始终明白为什么开发这个产品，产品为谁服务，最终要发布的产品将具备哪些特性等目标，开发过程中的每一项工作任务都是围绕最终的项目目标制定的。(2)具有外部可见的里程碑。微软公司的软件开发过程是由里程碑来推动和管理的，整个项目过程由不同的工作阶段构成，每一个工作阶段都以外部可见的里程碑为标志。项目团队可以借助里程碑管理每一个阶段的工作目标，评估每一个阶段的工作业绩，并且可以根据里程碑的要求同步项目组中的并发工作任务。(3)基于多版本的发布。微软公司的软件开发过程模型采用递进的版本发布策略，即最初创建和提供包含核心功能的产品版本，然后通过不断地改进和添加功能，陆续推出后续的版本。这种做法有利于适应项目目标的及时调整，也有利于产品质量的保证。(4)并行协作的小型化团队。微软公司建议采用小型化的项目组进行软件开发，每个项目组通常由3～8人组成，其角色定义和职责划分清楚，可以充分发挥个人在技术或管理上的经验和技能，有利于相互之间的交流协作。对于大型项目来说，整个项目团队在开发初期被分解成若干结构清晰、目标明确和管理灵活的小型项目组，并按照微软的团队模型进行管理和角色划分，小组之间通常是并行工作的。每隔3～6个月，项目管理者往往会根据项目的整体进展情况对项目小组进行重组，以适应最新的项目需求。(5)经常性的同步和稳定。微软公司强调在软件项目的进程中，经常性地对整个软件进行编译和测试，以保证软件随时处于可生成和可发布的状态。其中，每日生成制度已经成为所有项目组共同遵循的基本开发制度，即项目组在每天工作结束后，需要对整个产品的源代码进行编译和链接，以检验当天的工作是否可以得到完整的且可发布的产品。此外，开发人员和测试人员也要经常性地对软件进行各种极限情