软件工程复习笔记 第一章 -- 概述_螺旋式模型在螺旋线中每个回路被分成四个部分

前言

       总结自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了，自己感兴趣就想多了解一些，最后有本章的一些小总结。 如有问题请多指教

1.1 软件与软件危机

软件定义
       1983年，IEEE（国际电气与电子工程协会）为软件下的定义是：计算机程序、方法、规则和相关的文档资料以及在计算机上运行时所必需的数据。
       对软件比较公认的解释：软件是计算机系统中与硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。
记住 软件=程序+数据+文档 软件≠程序

1.1.1软件的特点

       软件是一种逻辑实体，具有抽象性。人们可以把它记录在纸上、磁盘或光盘等介质上，但却无法看到软件本身的形态，必须通过观察、分析、思考和判断才能了解它的功能和性能。
       软件一旦研究开发成功，其生产过程就变成复制过程，不像其他工程产品那样有明显的生产制造过程。由于软件复制非常容易，因此出现了软件产品的版权保护问题和打击盗版的问题。
       软件对硬件和环境有着不同程度的依赖性，这导致了软件升级和移植的问题。计算机硬件和支撑环境不断升级，为了适应运行环境的变化，软件也需要不断维护，并且维护的成本通常比开发成本高许多。
       软件生产至今尚未摆脱手工方式，软件开发的手工行为造就了一个致命的问题，就是为应用“量身订做”软件。其他工程领域有产品标准，所有生产厂家按照标准生产产品。例如，不管哪个厂家生产的灯泡，只要瓦数、电压、电流、接口几个指标符合要求，用户买来装上就可以使用。因此，软件产品规范性差、通用性差。近几年，基于组件的软件开发取得了重大进展，这样在遇到不同的应用需求时，就可以考虑用已有的组件搭建新的系统。
       软件涉及各行各业的知识，软件人员通常缺少专门领域的业务知识，而领域专家往往缺少软件知识，由此加剧了软件和业务之间的鸿沟，造成开发的软件不满足业务需求。
       软件不仅是一种在市场上推销的工业产品，也是与文学艺术作品相似的精神作品。与体力劳动相比，精神活动过程的特点是“不可见性”，这大大增加了组织管理上的困难。

1.1.2软件危机–软件生产的现状

危机定义：

       计算机软件开发和维护过程中所遇到的一系列严重问题。

软件生产的现状

• “已完成”的软件不满足用户的需求
• 软件产品的质量没有保证。
• 开发进度不能保障，交付时间一再拖延。
• 开发成本超出预算。
• 软件没有适当的文档

产生软件危机

例1

• 现象：开发进度不能保障，交付时间一再拖延。
• 案例：2002年的Swanick空运控制系统，包括英格兰和威尔士全部空运线路，在系统交付时，已经延期6年，实际花费6.23亿英镑，比原计划超出2.73亿英镑。
• 点评：软件复杂程度高，开发周期长，并且各种变化不断，因此软件项目按期完成交付的很少。

例2

• 现象：软件产品的质量没有保证。
• 案例：1990年4月10日，在伦敦地铁运营过程中，司机还没上车，地铁列车就驶离了车站，当时司机按了启动按钮，正常情况下如果车门是开的，系统就应该阻止列车启动，当时的问题是，司机离开列车去关另一扇卡着的车门，但当他关上车门时，列车还没有等司机上车就开动了。
• 点评：软件质量和可靠性的评估非常困难，这些投资巨大、技术一流、管理规范、测试充分的软件也难保不出现质量问题。

例3

• 现象：软件通常没有适当的文档资料或文档与最终交付的软件产品不符。
• 点评：软件几乎不可能一版保证成功，而是经历反复修改，其中的文档很难与每次的修改保持一致，错误的文档就像错误的地图一样危险。

例4

• 现象：软件的可维护程度低
• 点评：软件开发过程中，起着重要作用的是开发者的逻辑思维过程。如果若干年后由其他人来修改，必须要理解开发者当时的思维过程。因此说读懂别人的程序比重新编写的难度更大。

产生软件危机的原因

• 与软件本身的特点有关
  • 软件缺乏“可见性”, 开发过程的进展情况较难衡量，软件的质量也较难评价，管理和控制软件开发过程相当困难
  • 软件维护通常意味着改正或修改原来的设计，这就在客观上使得软件较难维护
  • 显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升,不仅涉及许多技术问题必须有严格而科学的管理
• 与软件开发和维护的方法有关
  • 忽视软件需求分析的重要性
  • 轻视软件维护
  • 只重视程序而忽视软件配置其余成分的糊涂观念

1.2 软件行业的出路？–软件工程

1）1993 IEEE软件工程定义

       软件工程是①将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护过程，即将工程化应用于软件开发和管理之中，②对①中所选方法的研究。

注意：软件工程研究所依据的基础理论：数学、计算机科学、经济学、工程学、管理学和心理学等学科。其中

• 数学和计算机科学用于构造模型、分析算法；
• 工程学用于评估成本、制定规范和标准；
• 管理学和心理学用于进度、资源、环境、质量、成本等的分析和管理。

2）软件工程研究的主要内容

技术方面：软件生命周期全过程中使用的一整套技术方法的集合称为方法学，其三要素：

1. 过程：获取高质量软件所需要的一系列任务框架（活动）、任务完成顺序、以及质量保证点和项目管理------做什么；
2. 方法：过程中规定各项任务中采取的技术方法------如何做；
3. 工具：为方法应用提供自动或半自动支持环境

管理方面：主要研究软件项目管理学、软件经济学、软件心理学。

3）软件工程层次化

软件工程三段论（补充）

软件项目开发

开发过程是软件人员“生产”软件的过程，一般包括：需求分析、设计、编码、测试等,相当于生产线上的生产过程。

软件项目开发路线图

软件项目管理

       管理过程是项目管理者规划软件开发、控制软件开发的过程，相当于生产线上的管理过程，管理过程是伴随开发过程进行的过程。

软件项目管理路线图

软件过程改进

       过程改进相当于对软件开发过程和软件管理过程的“工艺流程”进行管理和改进，如果没有好的工艺生产不出好的产品，它包括对开发过程和管理过程的定义和改进。

软件过程改进路线图

4）规范化和文档化

• 规范化：使众多的开发者遵守相同的规范，使软件生产摆脱个人生产方式，进入标准化、工程化的生产方式—关注国标、行标。
• 文档化：
  • 把软件的设计思想、设计过程和实现过程完整地记录下来，便于各类相关人员交流和沟通；
  • 使软件开发过程由不可见变为可见，便于管理者对软件生产进度和开发过程进行管理；
  • 是验收、质量检测的标准和依据。

5）软件工程的目标

软件工程旨在开发满足用户需要、及时交付、不超过预算和无故障的软件，其主要目标如下：

• 实现预期的软件功能，达到较好的软件性能，满足用户的需求。
• 增强软件过程可见性和可控性，保证软件的质量。
• 提高软件的可维护性，降低维护费用。
• 提高软件开发生产率，及时交付使用。
• 合理预算开发成本，付出较低的开发费用。

1.3 软件工程发展简史

       1968年在德国格密斯（Garmish）举行的学术会议上，北大西洋公约组织（NATO）正式提出了“软件工程”这一术语。软件工程作为工程学科家族中的新成员，对软件产业的形成和发展起了决定性作用，它指导人们科学地开发软件，有效地管理软件项目，对提高软件质量具有重要作用。
       在20世纪70年代基本形成了软件工程的概念、框架、方法，被称之为第一代软件工程，即传统软件工程。结构化分析、结构化设计和结构化编程方法是这个时期的代表。
       80年代出现的Smalltalk 80程序设计语言标志着面向对象程序设计进入了实用阶段，从80年代中到90年代中，研究的重点转移到面向对象分析和设计上来，从而演化成软件工程的第二代，称之为对象工程。
       90年代后期，软件工程的一个重要进展就是基于组件的开发方法。为了提高软件生产力，尽可能地利用可复用组件来组装成新的应用软件系统。到目前为止，组件技术的研究和发展形成了新一代软件工程，即第三代软件工程，也有不少人称之为组件工程。
       软件工程至今还在不断发展，无论是组件工程还是对象工程都在不断发展，即使是传统软件工程的一些基本概念、框架，也随着技术的进步在发生变化。总之，软件工程代与代之间并没有鸿沟，它们不仅交叉重叠，也携手并进。

1.4 软件工程的7条基本原理

       著名的软件工程专家B.W.Boehm综合软件工程的专家学者们的意见并总结了TRW公司多年开发软件的经验，于1983 年在一篇论文中提出了软件工程的7条基本原理

原理1、用分阶段的生命周期计划严格管理

       在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作，这条基本原理意味着，应该把软件生命周期划分成若干阶段，并相应地制定出切实可行的计划，按照计划对软件的开发与维护工作进行控制。

原理2、坚持进行阶段评审

       软件的质量保证工作不能等到编码阶段结束之后再进行。经过大量的统计数据表明，大部分错误是在编码之前造成的，其中，设计错误约占软件错误的63%，编码错误占37%。
       在前期改正错误所需要的可能只是橡皮和铅笔，而在交付后改正错误需要的工作就太多了：查找出错的代码、重新组织程序结构和数据结构、测试、修改文档。也就是说，错误发现与改正的越晚，所需付出的代价也越高。
       因此，在每个阶段都应该进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。

原理3、实行严格的产品控制

       基准配置管理也称为变动控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审和控制，获得批准以后才能实施修改（基准配置又称基线配置，它们是经过阶段评审后的软件配置成份 ）。目的是当需求变动时，其它各阶段的文档或代码随之相应变动，以保证软件的一致性。

原理4、采用现代程序设计技术

       自从提出软件工程概念后，人们一直把主要精力用于研究各种新的程序设计技术。60年代末提出了结构化程序设计技术，以后又进一步发展出结构化分析与设计技术、面向对象的分析和设计技术。实践表明，采用先进的技术既可提高软件开发和维护的效率，又可提高软件质量。

原理5、结果应能清楚地审查

       软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，明确地规定开发小组的责任和产品标准，从而使所得到的产品有明确的标准能清楚地审查。

原理6、开发小组的人员应该少而精

       软件开发小组成员的素质应该好，人数不宜过多。素质高的人员开发效率高、质量好、错误少。开发小组人员过多，信息交流造成的通信开销会急剧增加。

原理7、承认不断改进软件工程实践的必要性

       遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产。但是，仅有上述六条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，因此，应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原理。按照这条原理，不仅要积极地采纳新的软件技术，而且要注意不断总结经验、汲取教训。

1.5软件过程模型

1）软件生命周期

• 软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存期。
• 三个阶段：定义、开发、维护
• 八个步骤：问题定义、可行性研究、需求分析；总体设计、详细设计、编码与单元测试、综合测试；运行维护。

软件定义

• ①问题定义
• ②可行性研究
• ③需求分析

软件开发

• ①总体设计
• ②详细设计
• ③编码和单元测试
• ④综合测试

运行维护

问题定义阶段

• 主题：“要解决的问题是什么?”
• 任务：通过对客户的访问调查，系统分析人员弄清问题的背景、解决的意义和目标。扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。

可行性研究

• 主题：“对于上一个阶段所确定的问题有行得通的解决办法吗?”
• 任务：分析待开发系统的总体目标和范围，研究系统的可行性和可能的解决方案，对资源、成本及进度进行合理的估算。

需求分析

• 主题：“为了解决这个问题，系统必须做什么？”。
• 任务：通过分析、整理和提炼所收集到的用户需求，建立完整的分析模型，将其编写成软件需求规格说明和初步的用户手册。通过评审需求规格说明书，确保对用户需求达到共同的理解与认识。需求规格说明书明确地描述了软件的功能，列出软件必须满足的所有约束条件，并定义软件的输入和输出接口。

概要设计

• 主题：“概括地说，应该怎样实现目标系统?”
• 任务：概要设计“系统的蓝图”。确定解决问题的策略，设计目标系统框架结构和主要元素的布局。也就是确定程序由哪些模块组成以及模块间的关系

详细设计

• 主题：“应该怎样具体地实现这个系统呢?”
• 任务：根据整体结构设计具体的细节：用户界面设计，模块实现算法、数据结构和接口等，编写设计说明书，并组织进行设计评审。设计过程将现实世界的问题模型转换成计算机世界的实现模型，设计同样需要文档化，并应当在编写程序之前评审其质量。

编码和单元测试：

• 主题：“具体实现”
• 任务：
  • 将所设计的各个模块编写成计算机可接受的程序代码。
  • 在设计测试用例的基础上，测试软件的各个组成模块。一旦生成了代码，就可以开始单元测试，这种测试一般由程序员完成。

系统集成和综合测试：

• 主题：“全面测试软件”
• 软件是作为一个整体运行的，除了单个模块的测试外，还需要进行系统集成，以及集成测试、系统测试和验收测试等。
• 任务：通过各种类型的测试(及相应的调试)使软件达到预定的要求，应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来。

运行和维护：

• 主题：“维持软件的正常运行”
• 一旦软件交付运行之后，所做的任何修改就是维护。维护是软件过程的一个组成部分，应当在软件的设计和实现阶段充分考虑软件的可维护性。
• 任务：通过各种必要的维护活动使系统持久地满足用户的需要，包括改正性维护，适应性维护，完善性维护，预防性维护；每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。

2）软件过程

• 定义：软件过程是为获取高质量软件所需要的一系列任务框架，它规定了完成各项任务的工作步骤。
• 解释：过程是为了达到一个目标所进行的一系列活动，或者说是为达到一个目标而设计的“路线图”。
• 例如：为了培养一个世界体操冠军，需要研究训练方法、运用先进的训练器械、不断改进训练过程，最终有可能培养出世界冠军。

3）软件过程模型

• 软件过程是为获取高质量软件所需要的一系列任务框架。规定了要完成的各项任务、使用各种方法的顺序、各个阶段应交付的文档资料、任务完成标记（里程碑），为保证质量和协调变化应采取的管理措施。
• 软件生命周期的每一阶段都有明确的任务，各个阶段的活动如何衔接，开发过程中采用什么样的策略，应遵守什么样的规定和制约，将这些活动框架用一种模型表示出来，称为软件过程模型。
• 也就是说， 软件过程模型是软件开发全部过程、活动和任务的结构框架。

1.5.1瀑布模型

瀑布模型规定了软件生命周期的各项活动：问题定义、可行性研究、需求分析、软件设计、编码、测试、运行和维护。各项活动自顶向下、相互衔接如同瀑布一样。

瀑布模型特点

阶段间具有顺序性和依赖性

1. 必须等前一阶段的工作完成之后，才能开始后一阶段的工作
2. 前一阶段的输出(文档)就是后一阶段的输入(文档)

推迟实现的观点：清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现

质量保证的观点

1. 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；
2. 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

瀑布模型的作用及问题

       它提供了里程碑式的工作流程，为软件项目按规程管理提供了便利，例如，按阶段制定项目计划，分阶段进行成本核算，进行阶段性评审等；
       其作用还体现在文档上。每个阶段都必须完成规定的文档，并在每个阶段结束前都要对所完成的文档进行评审。这种工作方式有利于软件错误的尽早发现和尽早解决，并为软件系统今后的维护带来了很大的便利。
       但是，在实际的软件项目中存在着许多不稳定因素。例如，开发中的工作疏漏或通信误解；在项目实施中途，用户可能会提出一些新的要求；开发者也可能在设计中遇到某些未曾预料的实际困难，希望在需求中有所权衡等。因此，提出经过改进的，跟实际开发环境更加接近的瀑布模型。

带信息反馈的瀑布模型

当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。

瀑布模型的优缺点：

优点：为项目提供了按阶段划分的检查点；当前一活动完成后，只需要去关注后续活动；它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：瀑布模型确定了需求分析的绝对重要性，在项目开始的时候，用户常常难以清楚地给出所有需求；用户与开发人员对需求理解存在差异；由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

适用场合

• 当有一个稳定的产品定义和很容易被理解的技术解决方案 时，纯瀑布模型特别合适。
• 当你对一个定义得很好的版本进行维护或将一个产品移植到 一个新的平台上，瀑布模型也特别合适。
• 对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。
• 在质量需求高于成本需求和进度需求的时候，它尤为出色。
• 当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。

1.5.2快速原型化模型

• 定义：快速建立起来的可以在计算机上运行的程序，它 所能完成的功能往往是最终产品能完成的功能的一个子集
• 步骤：
  • 快速建立一个能反映用户主要需求的原型系统
  • 用户试用原型系统之后会提出许多修改意见
  • 开发人员按照用户的意见快速地修改原型系统，返回上一步
  • 用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求
    

快速原型化模型的优缺点

适用于用户驱动的系统（即需求模糊或随时间变化的系统）。
优点：

• 从实践中学习(Learning by doing)
• 改善通信
• 改善用户参与
• 使部分已知需求清晰化
• 展示描述的一致性和完整性
• 提高系统的实用性、可维护性
• 节省开发的投入、缩短整个软件的开发周期

缺点：

• 用户有时误解了原型的角色，例如他们可能误解原型应该和真实系统一样可靠。
• 缺少项目标准，进化原型方法有点像编码修正。
• 缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制。
• 额外的花费：研究结果表明构造一个原型可能需要10%额外花费。
• 为了尽快实现原型，采用了不合适的技术，运行效率可能会受影响。
• 原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件

1.5.3增量模型

• 定义：通过构造一系列可执行的软件构件来实施开发活动，以增量方式逐步完善待开发的软件。当一个新的构件被编码和测试后，并入到软件系统结构中，然后将该结构作为一个整体进行测试。这个过程不断循环往复直到软件系统达到要求的功能为止。
• 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付一个子集。整个产品被分解成多个构件，开发人员可以分别实现各个构件，每个构件都可以独立运行。
  

增量模型约束和优缺点

• 软件产品分解成增量构件的约束
  • 软件体系结构必须是开放的，向现有产品中加入新构件的过程必须简单、方便；
  • 需要更精心的设计；
  • 当把新构件集成到现有软件中时，所形成的产品必须是可测试的
• 优点：
  • 在较短时间内向用户提交可完成部分工作的产品
  • 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击

1.5.4螺旋模型

       螺旋模型即是一种引入了风险分析与规避机制的过程模型，是瀑布模型、快速原型方法和风险分析方法的有机结合。
       螺旋模型基本方法是，在各个阶段创建原型进行项目试验，以降低各个阶段可能遇到的项目风险。例如，为了降低用户对软件界面不满意的风险，可以在需求分析阶段建立“界面原型”；为了降低软件不能按设计要求实现的风险，可以在设计阶段针对所采用的技术建立“仿真试探原型”。

• 用螺旋线表示软件项目的进行情况，其中，螺旋线中的每个回路表示软件过程的一个阶段。因此，最里面的回路与项目可行性有关，接下来的一个回路与软件需求定义有关，而再下一个回路则与软件系统设计有关，以此类推。
• 螺旋线中的每个回路都被分成为四个部分：
  1）目标设置：确定项目的阶段性目标，分析项目风险。
  2）风险评估：对风险进行详细地评估分析，并确定适当的风险规避措施。
  3）开发软件：根据对风险的认识，决定采用合适的软件开发模型，实施软件开发。
  4）制定计划：对项目进行阶段评审，制定项目下一个阶段的工作计划。

螺旋模型的优缺点

• 对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。
• 需要相当的风险分析评估专门技术，比较复杂。

1.5.5 Rational统一过程

Rational Unified Process，RUP
Rational公司推出的一种完整的软件过程
总结多年商业化验证的6条有效的开发经验，被称为“最佳实践”

• 迭代开发（可运行版本）:通过一系列的细化、若干个渐进的反复过程得出有效解决方案
• 管理需求：如何提取、组织系统的功能性需求和约束条件并文档化；有效方法包括用例、脚本
• 使用基于构件的体系结构：使得软件重用成为可能
• 可视化建模（UML）：模型是为理解事物而对事物的一种抽象
• 验证软件质量：内建的质量评估过程，评估过程不再是事后型的软件过程
• 控制软件变更：具有管理变更的能力

RUP软件开发生命周期

• 二维生命周期模型
  ①横轴：时间
  ②纵轴：核心工作流
• 四个阶段，九个工作流
• 核心工作流
  ①业务建模
  ②需求
  ③分析和设计
  ④实现
  ⑤测试
  ⑥部署
  

Rational统一过程

• RUP把软件生命周期划分成4个阶段
  ①初始阶段：建立业务模型，定义最终产品视图，确定项目范围
  ②精华阶段：设计并确定系统体系结构，制定项目计划，确定资源需 求
  ③构建阶段：开发构件和产品，集成并进行测试
  ④移交阶段：开发产品提交给用户
• RUP迭代和渐增式开发
  每次考虑一部分，每次迭代增加一部分，每个阶段进一步划分或多次迭代，但不同的迭代过程中以不同的工作重点和强度对这些核心工作流程进行访问

1.5.6敏捷过程与极限编程

• 敏捷过程（Agile Process，AP）
  原则：

  • 文档适度、度量适度、管理适度
  • “沟通、简单、反馈、勇气”

  “敏捷软件开发宣言”阐述的4条价值观

  • 个体和交互胜过过程和工具：强调优秀的团队成员是软件开发项目获得成功的最重要因素
  • 可以工作的软件胜过详尽的文档：软件开发的主要目标是向用户提供可以工作的软件而非文档，重大意义是才写文档
  • 与客户协作胜过合同谈判：能够满足用户不断变化的需求的切实途径是与客户密切合作
  • 响应计划胜过遵循计划：计划必须有足够的灵活性和可塑性

• 敏捷方法（Agile Methodology，AM）

• 敏捷建模（Agile Modeling，AM）

• 极限编程（eXtreme Programming，XP）
  极限编程是敏捷过程中最有名的一个
  XP的整体开发过程
  
  

1.5.7微软过程

微软软件生命周期

规划阶段：市场获取用户情况、客户需求、竞争对手等信息
设计阶段：已经确定了70%以上的需求，包括系统规格说明书、设计方案、系统结构图、划分子系统、制定产品开发计划书
开发阶段：完成编码，并进行单元测试
稳定阶段：完整的进行集成测试，确保真实环境下的使用和操作
发布

微软过程准则：

• Microsoft拥有自己的软件开发过程
• 项目计划应该兼顾未来的不确定因素
• 用有效的风险管理来减少不确定因素
• 经常生成并快速地测试软件的过度版本
• 采用快速循环、迭代的开发过程
• 用创造性的工作来平衡产品特性和产品成本
• 项目进度表应该具有较高的稳定性和权威性
• 使用小型项目组并发地完成工作
• 在项目早期把软件配置基线化，项目后期则冻结产品
• 使用原型验证概念，对项目进行早期论证
• 把零缺陷作为追逐的目标
• 里程碑评审的目的是改进工作，切忌相互指责

1.6软件开发方法简述

1）结构化方法

• 1978年，E.Yourdon和L.L.Constantine提出了Yourdon方法，也称为结构化方法或面向功能的软件开发方法或面向数据流的方法。
• Yourdon方法是80年代使用最广泛的软件开发方法。它首先用结构化分析技术进行需求分析，然后用结构化设计技术进行总体设计和详细设计，最后是结构化编程。这一方法的精髓是自顶向下、逐步求精，也就是将功能逐步分解，直到人们可以理解和控制它为止。
  2）面向对象方法：
• 研究始于1966年，自90年代以来，面向对象的分析、设计、测试、度量和管理等研究都得到长足发展。
• 对象是由数据和容许的操作组成的封装体，与客观实体有直接对应关系，一个对象类定义了具有相似性质的一组对象。
• 继承性是对具有层次关系的类的属性和操作进行共享的一种方式。
• 基本思想：用对象模拟问题领域中的实体，以对象间的关系刻画实体间联系。本质是主张从客观世界固有的事物出发构造系统。

软件工程研究的最新方向

       软件形式语言的研究：目前，大部分软件文档都是用自然语言书写的。由于自然语言本身具有模糊性，因此有一部分专家研究“形式化描述语言的应用，以及不同形式化语言之间的转换”。这类研究工作难度较大，也不容易为一般人所接受。但是由于越来越多的大型软件的复杂程度与日俱增，这些软件一旦出错所引起的后果十分严重，所以形式化的研究工作就显得非常重要。
       构件技术：软件开发构件化可以说是软件开发技术的一个发展趋势，也是软件工程界的一个热门话题。近年来，软件技术的进步以及CORBA，DCOM，JavaBean等构件标准的出现已经使情况开始改变，这给软件危机的真正缓和带来了希望。
       质量管理：软件开发过程的质量控制将逐步得到重视。软件开发过程中精神活动的“不可见性”大大增加了过程管理的困难。因此软件工程管理的指导思想就是千方百计地使这些过程变为“可见的”，以及事后可以检查的记录。只有从一开始就在软件开发过程中严格贯彻质量管理，软件产品的质量才有保证。否则，开发工作一旦进行到后期，无论怎样测试和补漏洞，都无济于事。这就是近年来国际上十分重视的“软件生产过程质量管理”思想。

1.7软件工程标准

1）国际标准：

由国际联合机构制定和公布，提供各国参考的标准。

• ISO（International Standards Organization）国际标准化组织，该机构建立了“计算机与信息处理技术委员会”（简称ISO／TC97)，专门负责与计算机有关的标准化工作。
• 这类标准通常标有ISO字样，如ISO 8631—86 Information processing —Program constructs and conventions for the representation（信息处理——程序构造及其表示法的约定)，该标准现已被我国收入国家标准。

2）国家标准

• 由政府或国家级的机构制定或批准，适用于全国范围的标准。
• GB——中华人民共和国国家标准。国家技术监督局是我国的最高标准化机构，它所公布实施的标准简称为“BG”。
• ANSI（American National Standards Institute)——美国国家标准协会。这是美国一些民间标准化组织的领导机构，具有一定权威性。
• BS（British Standard)——英国国家标准。

3）行业标准

• 由行业机构、学术团体或国防机构制定并适用于某个业务领域的标准。
• IEEE（1nstitute Of Electrical and Electronics Engineers)——美电气和电子工程师学会。近年该学会专门成立了软件标准分技术委员会（SESS)，积极开展了软件标准化活动，取得了显著成果，受到软件界的关注。IEEE通过的标准常常要报请ANSI审批，使其具有国家标准的性质。因此，我们看到IEEE公布的标准常冠有 ANSI字头。例如，ANSI／IEEE Str 828—1983软件配置管理计划标准。
• GJB——中华人民共和国国家军用标准。这是由我国国防科学技术工业委员会批准，适合于国防部门和军队使用的标准。例如，1988年发布实施的GJB473—88军用软件开发规范。
• DOD-STD（Department Of Defense- STanDards)——美国国防部标准。适用于美国国防部门。

4）企业标准

一些大型企业或公司，由于软件工程工作的需要，制定适用于本部门的规范。例如，美国IBM公司通用产品部（General Products Division)1984年制定的“程序设计开发指南”，仅供该公司内部使用。

5）项目规范

由某一科研生产项目组织制定，并且为该项任务专用的软件工程规范。例如，计算机集成制造系统（CIMS)的软件工程规范。

1.8软件工程师职业道德规范

1）规范

• 1999年由ACM/IEEE-CS软件工程师道德规范和职业实践（SEEPP）联合工作组制订了《软件工程师职业道德规范》，规范含有8组由关键词命名的行为准则。
• 公众 、客户和雇主 、产品 、判断 、管理 、专业 、同行 、自身 。

2）职业化素质

• 职业化，简单说就是能胜任工作，让人放心。
• “能胜任工作”，就需要具备相应的专业技能、知识和经验；
• “让人放心”意味着很多，包括遵守行业成文的或未成文的规则和规范，积极有效地和同事沟通，确保自己的工作产品是大家所期望的，尽可能地向客户提供最专业的服务和产品。
• 自律、沟通和技能是成为职业化软件工程师的必要条件。

3）职业化软件工程师忌讳的十大问题
行为一：对外交付半成品。
行为二：不遵守标准和规范。
行为三：不积极帮助他人。
行为四：版权意识不敏感。
行为五：对待计划不严肃。
行为六：公事私事相混淆。
行为七：不注意知识更新。
行为八：不主动与人沟通。
行为九：不遵守职业规则。
行为十：不够诚实和正直。

本章要点

       软件危机的主要表现是　“已完成”的软件不满足用户的需求；开发进度不能保障；软件开发成本难以准确估算；软件产品的质量没有保证。
       软件工程是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和先进软件开发技术结合起来，运用到软件开发和维护过程中，来解决软件危机。
       软件工程研究的主要内容是软件开发技术和软件开发管理两个方面。软件开发技术方面主要研究软件开发方法、软件开发过程、软件开发工具和环境。软件开发管理方面主要研究软件工程管理学、软件工程经济学、软件工程心理学。
       软件工程的7条基本原理是①用分阶段的生命周期计划严格管理②坚持进行阶段评审③实行严格的产品控制④采用现代程序设计技术⑤结果应能清楚地审查⑥开发小组的人员应该少而精⑦承认不断改进软件工程实践的必要性。
       软件生命周期是指一个软件从提出开发要求开始到该软件报废为止的整个时期。通常将软件的生命周期划分为问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、集成和测试、维护阶段。
       软件生命周期模型反映的是软件开发过程、活动和任务的结构框架。它能够清晰、直观地表达软件开发全过程，明确规定要完成的主要活动和任务。对于不同的软件系统，可能采用不同的开发方法，使用不同的程序设计语言、不同的管理方法和手段、以及各种具有不同技能的人员参与工作，但是对于软件生命周期模型来说都应该是稳定有效和普遍适用的。到目前为止，已经提出了多种模型，主要有瀑布模型、快速原型模型、演化模型、螺旋模型、V模型等。模型的选择是基于软件的特点和应用领域。
       目前，主流的软件开发方法有结构化方法和面向对象方法。
       为了提高软件开发的效率，保障软件产品的质量，软件工程领域中公布了许多国际标准、国家标准、行业标准、企业标准、项目规范，通常由低级到高级使用。软件工程的标准关系到许多方面，有规范开发过程的标准，有定义产品的标准，还有管理标准和记法符号的标准等等。
       1999年由ACM/IEEE-CS软件工程师道德规范和职业实践（SEEPP）联合工作组制订了《软件工程师职业道德规范》，规范含有8组由关键词命名的准则。公众 、客户和雇主 、产品 、判断 、管理 、专业 、同行 、自身 。
       职业化软件工程师要注意的十大问题：①高质量地完成任务②遵守行业标准，不能肆意按照自己的想象来发挥③积极帮助他人④版权意识敏感⑤严格遵守计划⑥公私分明⑦注意知识更新⑧善于沟通⑨遵守职业规则⑩诚实和正直。