软件工程专题读书报告笔记1

S201325016 赵鹏飞

一软件要素

软件工程包括三个要素：方法、工具和过程。

软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编

码、测试以及维护等。

软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。目前，已经推出了许多软件工具，这些软件工具集成起来，建立起称之为计算机辅助软件工程(CASE)的软件开发支撑系统。CASE将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。

软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协

调变化所需要的管理、及软件开发各个阶段完成的里程碑。

软件工程是一种层次化的技术。任何工程方法（包括软件工程）必须以有组织的质量保证为基础。全面的质量管理和类似的理念刺激了不断的过程改进，正是这种改进导致了更加成熟的软件工程方法的不断出现。支持软件工程的根基就在于对质量的关注。

二软件过程

软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

软件过程（Software Process）是指一套关于项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关Artifacts（计划、文档、模型、编码、测试、手册等）组成。目前有三种方法：UP（the unified process），The OPEN Process，OOSP(TheObject-Oriented Software Process)。软件过程(Software Procedure)是指软件生存周期所涉及的一系列相关过程。过程是活动的集合；活动是任务的集合；任务要起着把输入进行加工然后输出的作用。活动的执行可以是顺序的、重复的、并行的、嵌套的或者是有条件地引发的。

软件过程可概括为三类：基本过程类、支持过程类和组织过程类。基本过程类包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程。支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。组织过程类包括基础设施过程、改进过程以及培训过程。

软件过程主要针对软件生产和管理进行研究。为了获得满足工程目标的软件，不仅涉及工程开发，而且还涉及工程支持和工程管理。对于一个特定的项目，可以通过剪裁过程定

义所需的活动和任务，并可使活动并发执行。与软件有关的单位，根据需要和目标，可采用不同的过程、活动和任务。

软件过程是指软件整个生命周期，从需求获取，需求分析，设计，实现，测试，发布和维护一个过程模型。一个软件过程定义了软件开发中采用的方法，但软件工程还包含该过程中应用的技术——技术方法和自动化工具。过程定义一个框架，为有效交付软件工程技术，这个框架必须创建。软件过程构成了软件项目管理控制的基础，并且创建了一个环境以便于技术方法的采用、工作产品（模型、文档、报告、表格等）的产生、里程碑的创建、质量的保证、正常变更的正确管理。

所谓软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。一个错误模型的选择，将迷失我们的开发方向。对于下面的模型，希望能够给开发者们一个参考和一点启示。

它有时也称为传统生存周期模型或瀑布模型。它提出了软件开发的系统

化的、顺序的方法。其流程从系统开始，随后是需求分析、设计、编码、测试、支持。这种模型是最早也是应用最广泛的软件过程模型(虽然这种模型会引起“堵赛状态”)。

缺点：

1、实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。

2、经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。

3、客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。

4、采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。

优点：

1、它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。

2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。

原型实现

从需求收集开始，开发者和客户在一起定义软件的总体目标，标识已知的需求并且规划出需要进一步定义的区域。然后是“快速设计”，它集中于软件中那些对客户可见的部分的表示，这将导致原型的创建，并由客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的需求，这个过程是迭代的。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统（虽然这个系统不带有任何质量的保证），所以客户和开发

者都比较喜欢这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质量和不害怕长期维护的公司而言）。

缺点：

1、没有考虑软件的整体质量和长期的可维护性。

2、大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。

3、由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。

优点：

1、如果客户和开发者达成一致协议：原型被建造仅为了定义需求，之后就被抛弃或者部分抛弃，那么这种模型很合适了。

2、迷惑客户抢占市场，这是一个首选的模型。

快速应用

这是一个增量型的软件开发过程模型，强调极短的开发周期，它是线性模型的一个“高速”变种，通过使用构件的建造方法赢得了快速开发。如果需求理解的好而且约束了项目的范围，利用这种模型可以很快的创建出功能完善的“信息系统”。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。RAD过程强调的是复用，复用已有的或开发可复用的构件。实际上RAD采用第四代技术。

缺点：

1、只能用于信息系统。

2、对于较大的项目需要足够的人力资源去建造足够的RAD组。

3、开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。

4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造RAD所需要的构件就会有问题。

5、技术风险很高的情况下不适合这种模型。

优点：

1、开发速度快，质量有保证。

2、对信息系统特别有效。

增量

这种模型融合了线性顺序模型的基本成份和原型实现模型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都做为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断从复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

缺点：

1、至始至终开发者和客户纠缠在一起，直到完全版本出来。