第5讲 结构化生命周期法.

软件工程的结构化生命周期方法
软件工程的结构化生命周期方法是一种把软件开发过程分解成若干个独立、可管理、具有确定性质的阶段或活动，并且阶段之间有明显的输入输出关系和相互制约关系的开发方法。

常见的结构化生命周期方法包括瀑布模型、迭代模型、螺旋模型等。

1. 需求分析阶段
在这个阶段，对用户需求和需求的可行性进行了解和分析，并出具详细的需求说明书。

这个阶段的主要特点是快速出具详细需求文档，以此为基础进行后续的设计等阶段。

2. 设计阶段
在这个阶段，根据需求说明书进行详细设计，并形成设计文档。

这个阶段的主要特点是通过详细设计，保证软件能够达到预期的功能与质量要求。

3. 编码阶段
在这个阶段，根据设计文档进行编码，并进行测试验证编码的正确性。

这个阶段的主要特点是把大量的设计文档转化为可实现的软件，完成最终的实现和测试。

4. 测试阶段
在这个阶段，对开发好的软件进行全面的测试以及错误和缺陷修复，以保证软件的质量和稳定性。

这个阶段的主要特点是对软件进行全面、深入、科学的测试和质量保障。

5. 运维阶段
在这个阶段，管理整个软件体系，记录使用者的各类需求并进行更新维护，以及对于发现的软件缺陷进行修改和升级。

这个阶段的主要特点是保证软件能够随时满足用户的需求，并持续改善软件的质量和性能。

结构化生命周期法台风发源于热带海面，那里温度高，大量的海水被蒸发到了空中，形成一个低气压中心。

随着气压的变化和地球自身的运动，流入的空气也旋转起来，形成一个逆时针旋转的空气漩涡，这就是热带气旋。

只要气温不下降，这个热带气旋就会越来越强大，最后形成了台风。

台风源地，指经常发生台风的海区，全球台风主要发生于8个海区。

其中北半球有北太平洋西部和东部、北大西洋西部、孟加拉湾和阿拉伯海5个海区，而南半球有南太平洋西部、南印度洋西部和东部3个海区。

从每年台风发生数及其占全球台风总数的百分率的区域分布图中可以看到，全球每年平均可发生62个台风，大洋西部发生的台风比大洋东部发生的台风多得多。

其中以西北太平洋海区为最多(占36%以上)，而南大西洋和东南太平洋至今尚未发现有台风生成。

西北太平洋台风的源地又分三个相对集中区：菲律宾以东的洋面、关岛附近洋面和南海中部。

在南海形成的台风，对我国华南一带影响重大。

台风大多数出现在南、北纬度的5°～20°，尤其就是在10°～20°占了总数的65%。

而在20°以外的较为高纬度出现的台风只占到13%，出现在5°以内赤道附近的台风极少，但偶尔还是有的，例如福建省气象台就辨认出～这两年中，西北太平洋共计3个台风出现在5°n以南区域。

据近十多年去卫星资料的分析，发展成台风的扰动云团，在几天前即可辨认出，所以实际上扰动的起始边线比以前辨认出的边线偏东。

例如北大西洋上，以前指出发展成台风的起始扰动大多数产生在大洋的中部，而有人根据云图分析，指出每年存有三分之二台风的扰动源于非洲大陆。

这些扰动通常整体表现为好像v形或旋涡状云型，它们沿东风气流向西移动，抵达北大西洋中部和加勒比海时，便发展成台风。

北太平洋西部和南海台风的起始扰动边线，也必须比以前辨认出的边线偏东。

台风是一个强大而具破坏力的气旋性漩涡，发展成熟的台风，其底层按辐合气流速度大小分为三个区域：①外圈，又称为大风区。

计算机二级《信息管理》重点：结构化生命周期方法结构化生命周期方法结构化分析与设计方法在软件工程中应用已很普遍，并且越来越成熟。

有许多大、中型项目都采用了这种方法进行开发并取得了显著的成果。

按B.W.Boehm的描述，瀑布模型的的软件生命周期可划分七个阶段:系统需求分析、软件需求分析、概要设计、详细设计、编码、测试和运行维护。

系统需求系统需求包括:问题定义、可行性研究及软件计划。

1.问题定义软件开发的第一步就是进行问题定义。

问题定义阶段必须回答的关键问题:软件要解决的问题是什么?如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。

尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最常被忽视的一个步骤。

这里所说的问题，就是指用户的基本要求。

说得通俗些，问题定义实际上就是了解用户到底要建立什么系统，并确定分析员下一步应该做什么。

因此，问题定义的来源是用户。

通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。

这一阶段的分析员应尽可能站在较高的角度去抽象、概括所要干的事情，不要拘泥于问题实现的细节。

尽管用户可能总是习惯于这样做，但分析员在这一阶段必须超脱出来，居高临下鸟瞰系统的全貌。

通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。

当用户的要求不是很多并且不太复杂时，一两个分析员用上一两天就可以完成这一工作了。

但当系统比较大，且复杂时，恐怕就要组织一个问题定义小组，花上一两个星期，甚至数月来定义用户的问题。

如果分析员和用户及使用部门的负责人对所要解决的问题取得完全一致的看法，而且使用部门的负责人同意开发工程继续进行下去，那么开发工程将转入生命周期的下一个阶段可行性研究。

结构化生命周期法的特点
结构化生命周期法的特点
结构化生命周期法是一种软件工程最重要的方法之一，也是面向对象技术的基础。

它把软件开发过程分解成一系列阶段，每个阶段都有明确的目标，每个阶段的输入和输出都能够正确地流动。

特点：
1、结构化生命周期法以软件开发中各个不同阶段的交付物作为驱动，它有助于清晰地定义软件开发流程；
2、结构化生命周期法有利于管理软件开发的风险，可以将风险分解成比较小的部分，从而更好地控制风险；
3、结构化生命周期法具有可重复性，可以用于多个项目，并且每个项目都能从中受益；
4、结构化生命周期法可以提供有效的可衡量的质量保证，使得质量更加可控，从而更好地满足客户需求。

第十章信息系统建设10.12 系统开发的结构化生命周期法2系统开发的结构化生命周期法结构化生命周期法(Structured Life Cycle)是最早的、成熟的一种信息系统开发方法。

该方法基于结构化方法的思想，按照信息系统的生命周期进行信息系统的开发。

基本思想：用系统的思想和系统工程的方法，遵循用户至上原则，结构化、模块化、自顶向下地对系统进行开发。

31. 系统开发过程按照信息系统的生命周期将信息系统开发过程划分为若干阶段；规定每个阶段的工作任务、目标及其应达到的阶段性成果；按照一定的准则按部就班地完成各个阶段的工作，完成上一阶段的工作之后才可以进入下一阶段；每个阶段都要形成完整、规范的文档，作为下一阶段开发的依据；文档更改严格管理。

系统规划系统分析系统实现系统设计系统运维2. 生命周期法的优点强调整体性和全局性；开发过程有计划，便于管理与控制；模块化便于分工合作完成大型项目；工作文档标准化、规范化——完成了艺术向技术的转变，排斥个性化与自由发挥；详尽的系统分析便于组织理清业务流程，发现缺陷，找到改进措施，使组织从中受益。

453. 生命周期法的适用性组织相对稳定、业务处理过程规范、需求明确且在一定时期内不会发生大的变化的大型系统；软件的社会化大生产；特别适用于开发大型TPS和MIS系统。

64. 生命周期法的不足耗费资源大，开发周期长。

详细业务调查与正规文档整理工作消耗巨大的人力物力，也花费较长的时间，导致最终开发出的系统可能过时；缺乏灵活性。

修改不灵活，手续繁琐且需要修改大量的文档。

有时用户在见到实际系统前，难以提出明确的修改意见，见到后再想提出时已经为时已晚。

5. 生命周期法的局限性不适用于以下系统：需求不明确的系统-非结构化决策（ESS）-半结构化决策（DSS）快速变化的系统小型系统7Thank You8。

快速原型法及其他快速原型法、面向对象的方法的基本思想、开发过程、适用范围。

教学难点在实际管理信息系统开发过程中开发方法的选择。

各种开发方法之间的关系。

建议学时1学时教学教具多媒体教学系统软件微机录像教学方法讲授（PPT）演示设计板书设计一、快速原型法二、面向对象的方法教学过程课程导入问题讨论:1.什么是快速原型法？2.为什么许多管理信息系统开发和应用失败了, 原因是什么？3、面向对象的方法包括哪些？通过上述问题的讨论, 引导学生重视开发方法的学习, 对目前各种开发方法从总体上加以了解。

通过上述问题的讨论，引导学生重视开发方法的学习，对目前各种开发方法从总体上加以了解。

一、快速原型法信息系统原型, 就是一个可以实际运行、可以反复修改、可以不断完善的信息系统。

1. 原型法产生的原因运用结构化系统开发生命周期法的前提条件是要求用户在项目开始初期就非常明确地陈述其需求, 需求陈述出现错误, 对信息系统开发的影响尤为严重, 因此, 这种方法不允许失败。

事实上这种要求又难以做到。

人们设想, 有一种方法, 能够迅速发现需求错误。

当图形用户界面(Graphic User Interface, GUI)出现后, 自80年代中期以来, 原型法逐步被接受, 并成为一种流行的信息系统开发方法。

2. 基本思想原型法（Prototyping Method）是在系统开发初期, 凭借系统开发人员对用户需求的了解和系统主要功能的要求, 在强有力的软件环境支持下, 迅速构造出系统的初始原型, 然后与用户一起不断对原型进行修改、完善, 直到满足用户需求。

3.开发过程可行性研究。

对系统开发的意义、费用、时间作出初步的计算, 确定系统开发的必要性和可行性。

确定系统的基本要求。

系统开发人员向用户了解用户对信息系统的基本需求, 即应该具有的一些基本功能, 人机界面的基本形式等。

建造系统初始原型。

在对系统有了基本了解的基础上, 系统开发人员应争取尽快地建造一个具有这些基本功能的系统。