swguide1软件工程概述软件过程与软件生命周期.docx

上传人:b****0 文档编号:9730974 上传时间:2023-05-20 格式:DOCX 页数:36 大小:485.46KB
下载 相关 举报
swguide1软件工程概述软件过程与软件生命周期.docx_第1页
第1页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第2页
第2页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第3页
第3页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第4页
第4页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第5页
第5页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第6页
第6页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第7页
第7页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第8页
第8页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第9页
第9页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第10页
第10页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第11页
第11页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第12页
第12页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第13页
第13页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第14页
第14页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第15页
第15页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第16页
第16页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第17页
第17页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第18页
第18页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第19页
第19页 / 共36页
swguide1软件工程概述软件过程与软件生命周期.docx_第20页
第20页 / 共36页
亲,该文档总共36页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

swguide1软件工程概述软件过程与软件生命周期.docx

《swguide1软件工程概述软件过程与软件生命周期.docx》由会员分享,可在线阅读,更多相关《swguide1软件工程概述软件过程与软件生命周期.docx(36页珍藏版)》请在冰点文库上搜索。

swguide1软件工程概述软件过程与软件生命周期.docx

swguide1软件工程概述软件过程与软件生命周期

第1讲软件工程概述、软件过程、软件生命周期

1.1复习要求

1.了解软件概念、特点及分类方法。

2.了解软件发展及软件危机的起因。

3.了解软件工程过程及软件生存期的概念。

4.了解软件工程的概念及其要素。

5.了解软件工程的基本目标和原则。

掌握软件过程各阶段

1.2内容提要

1.2.1软件的概念、特点

软件是计算机系统中与硬件相互依存的另一部分,它是包括程序,数据及其相关文档的完整集合。

其中,程序是按事先设计的功能和性能要求执行的指令序列;数据是使程序能正常操纵信息的数据结构;文档是与程序开发,维护和使用有关的图文材料。

软件的特点是:

(1)软件是一种逻辑实体,而不是具体的物理实体。

因而它具有抽象性。

(2)软件的生产与硬件不同,它没有明显的制造过程。

对软件的质量控制,必须着重在软件开发方面下功夫。

(3)在软件的运行和使用期间,没有硬件那样的机械磨损,老化问题。

任何机械、电子设备在运行和使用中,其失效率大都遵循如图1.1(a)所示的U型曲线(即浴盆曲线)。

而软件的情况与此不同,因为它不存在磨损和老化问题。

然而它存在退化问题,必须要多次修改(维护)软件,如图1.1(b)所示。

图1.1失效率曲线

(4)软件的开发和运行常常受到计算机系统的限制,对计算机系统有着不同程度的依赖性。

为了解除这种依赖性,在软件开发中提出了软件移植的问题。

(5)软件的开发至今尚未完全摆脱手工艺的开发方式。

(6)软件本身是复杂的。

软件的复杂性可能来自它所反映的实际问题的复杂性,也可能来自程序逻辑结构的复杂性。

(7)软件成本相当昂贵。

软件的研制工作需要投入大量的、复杂的、高强度的脑力劳动,它的成本是比较高的。

(8)相当多的软件工作涉及到社会因素。

许多软件的开发和运行涉及机构、体制及管理方式等问题,甚至涉及到人的观念和人们的心理。

它直接影响到项目的成败。

1.2.2软件的分类

(1)按软件的功能进行划分:

·系统软件:

能与计算机硬件紧密配合在一起,使计算机系统各个部件、相关的软件和数据协调、高效地工作的软件。

例如,操作系统、数据库管理系统、设备驱动程序以及通信处理程序等。

·支撑软件:

是协助用户开发软件的工具性软件,其中包括帮助程序人员开发软件产品的工具,也包括帮助管理人员控制开发的进程的工具。

·应用软件:

是在特定领域内开发,为特定目的服务的一类软件。

(2)按软件规模进行划分:

按开发软件所需的人力、时间以及完成的源程序行数,可确定六种不同规模的软件。

表1.1软件规模的分类

类别

参加人员数

研制期限

产品规模(源程序行数)

微型

1

1~4周

0.5k

小型

1

1~6月

1k~2k

中型

2~5

1~2年

5k~50k

大型

5~20

2~3年

50k~100k

甚大型

100~1000

4~5年

1M(=1000k)

极大型

2000~5000

5~10年

1M~10M

规模大、时间长、很多人参加的软件项目,其开发工作必须要有软件工程的知识做指导。

而规模小、时间短、参加人员少的软件项目也得有软件工程概念,遵循一定的开发规范。

其基本原则是一样的,只是对软件工程技术依赖的程度不同而已。

(3)按软件工作方式划分:

·实时处理软件:

指在事件或数据产生时,立即予以处理,并及时反馈信号,控制需要监测和控制的过程的软件。

主要包括数据采集,分析,输出三部分。

·分时软件:

允许多个联机用户同时使用计算机。

·交互式软件:

能实现人机通信的软件。

·批处理软件:

把一组输入作业或一批数据以成批处理的方式一次运行,按顺序逐个处理完的软件。

(4)按软件服务对象的范围划分:

·项目软件:

也称定制软件,是受某个特定客户(或少数客户)的委托,由一个或多个软件开发机构在合同的约束下开发出来的软件。

例如军用防空指挥系统、卫星控制系统。

·产品软件:

是由软件开发机构开发出来直接提供给市场,或是为千百个用户服务的软件。

例如,文字处理软件、文本处理软件、财务处理软件、人事管理软件等。

(5)按使用的频度进行划分:

有的软件开发出来仅供一次使用。

例如用于人口普查、工业普查的软件。

另外有些软件具有较高的使用频度,如天气预报软件。

(6)按软件失效的影响进行划分:

有的软件在工作中出现了故障,造成软件失效,可能给软件整个系统带来的影响不大。

有的软件一旦失效。

可能酿成灾难性后果。

例如财务金融、交通通信、航空航天等软件。

我们称这类软件为关键软件。

1.2.3软件的发展和软件危机

1.软件发展历史

自20世纪40年代中出现了世界上第一台计算机以后,就有了程序的概念。

其后经历了几十年的发展,计算机软件经历了三个发展阶段:

·程序设计阶段,约为50至60年代

·程序系统阶段,约为60至70年代

·软件工程阶段,约为70年代以后

几十年来最根本的变化体现在:

(1)人们改变了对软件的看法。

50年代到60年代时,程序设计曾经被看做是一种任人发挥创造才能的技术领域。

当时人们认为,写出的程序只要能在计算机上得出正确的结果,程序的写法可以不受任何约束。

随着计算机的广泛使用,人们要求这些程序容易看懂、容易使用,并且容易修改和扩充。

于是,程序便从个人按自己意图创造的“艺术品”转变为能被广大用户接受的工程化产品。

(2)软件的需求是软件发展的动力。

早期的程序开发者只是为了满足自己的需要,这种自给自足的生产方式仍然是其低级阶段的表现。

进入软件工程阶段以后,软件开发的成果具有社会属性,它要在市场中流通以满足广大用户的需要。

(3)软件工作的范围从只考虑程序的编写扩展到涉及整个软件生存周期。

在软件技术发展的第二阶段,随着计算机硬件技术的进步,要求软件能与之相适应。

然而软件技术的进步一直未能满足形势发展提出的要求。

致使问题积累起来,形成了日益尖锐的矛盾。

这就导致了软件危机。

2.软件危机

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象。

.软件危机是指软件产品开发过程中,产品质量低下,并且不能按期交付和费用超支等情况,软件危机始于20世纪70年代出现并且已经持续到今天。

问题归结起来有:

(1)缺乏软件开发的经验和有关软件开发数据的积累,使得开发工作的计划很难制定。

致使经费预算常常突破,进度计划无法遵循,开发完成的期限一拖再拖。

(2)软件需求,在开发的初期阶段提得不够明确,或是未能得到确切的表达,项目没有被很好地理解;计划不周,最终导致进度拖延。

开发工作开始后,软件人员和用户又未能及时交换意见,造成开发后期矛盾的集中暴露。

(3)没有充分的文档资料(documentation)

(4)开发过程没有统一的、公认的方法论和规范指导,参加的人员各行其事。

加之设计和实现过程的资料很不完整;或忽视了每个人工作与其他人的接口,使得软件很难维护。

(5)未能在测试阶段充分做好检测工作,提交用户的软件质量差,在运行中暴露出大量的问题。

(6)软件可靠性(reliability)缺少度量的标准,质量无法保证。

如何保证软件产品的质量,是非常复杂困难的问题,特别对于规模庞大的软件。

如果这些障碍不能突破,进而摆脱困境,软件的发展是没有出路的。

3.软件危机的解决办法

⏹解决问题的想法:

◆Bettermanagement

◆Differentteamorganizations

◆Betterlanguages&tools

◆Uniformcodingconventions

⏹必须意识到:

“软件”编程,它有自己的生命周期(lifecycle)。

大型软件系统的开发与其它工程项目如建造桥梁、制造飞机、轮船等的开发是同理的。

⏹“软件工程”(SoftwareEngineering):

NATOConference,Garmisch,Germany,1968.

⏹1)用分阶段的生命周期计划严格管理。

Boehm认为,在工程的整个生命周期应该制定并严格执行六类计划,它们是项目概要计划,里程碑计划,项目控制计划,产品控制计划,验证计划,运行维护计划。

⏹2)坚持进行阶段评审原则。

第一,大部分错误是在编码之前造成的,Boehm等人的统计,设计错误占软件错误的63%,编码错误仅占37%;第二,错误发现与改正行越晚,所需付出的代价也越高(参见图1和图2)

⏹3)严格的产品控制原则。

为了保持系统各个配置成分的一致性,必须实行严格的产品控制,其中主要是实行基准配置管理。

所谓基准配置又称为基线配置,它们是经过阶段评审后的系统配置成分(各个阶段产生的文档或程序代码)。

基准配置管理也称为变动控制:

一切有关修改系统的建议,特别是涉及到对基准配置的个性建议,都必须按照严格的规程进行评审,获得批准以后才能实施修改。

⏹4)采用现代程序设计技术原则

⏹5)结果应能清楚地审查原则

⏹6)开发小组的人员应该少而精原则。

当开发小组人员数为N时,可能的通信路径有N(N-1)/2条。

⏹7)承认不断改进工程实践的必要性原则。

按照这条原则,不仅要积极主动地采纳新的软件技术,而且要注意不断总结经验,例如,收集进度和资源耗费数据,收集出错类型和问题报告数据等等。

1.2.4软件工程过程和软件生存周期

许多计算机和软件科学家尝试,把其它工程领域中行之有效的工程学知识运用到软件开发工作中来。

经过不断实践和总结,最后得出一个结论:

按工程化的原则和方法组织软件开发工作是有效的,是摆脱软件危机的一个主要出路。

1.软件工程过程的过程活动(SoftwareEngineeringProcess)

软件工程过程是为获得软件产品,在软件工具支持下由软件工程师完成的一系列软件工程活动。

软件过程是生产软件的方式,包括软件生命周期模型、所使用的工具及所有这些因素中最重要的因素:

开发软件的人。

软件工程过程通常包含四种基本的过程活动:

·P(Plan):

软件规格说明。

规定软件的功能及其运行的限制;

·D(Do):

软件开发。

产生满足规格说明的软件;

·C(Check):

软件确认。

确认软件能够完成客户提出的要求;

·A(Action):

软件演进。

为满足客户的变更要求,软件必须在使用的过程中演进。

事实上,软件工程过程是一个软件开发机构针对某一类软件产品为自己规定的工作步骤,它应当是科学的、合理的,否则必将影响到软件产品的质量。

2.软件生存周期(lifecycle)

正如同任何事物一样,软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。

我们称其为计算机软件的生存周期。

根据这一思想,把上述基本的过程活动进一步展开,可以得到软件生存周期的六个步骤。

(1)问题定义。

问题定义阶段必须回答的关键问题是:

“要解决的问题是什么?

(2)可行性研究。

这个阶段要回答的关键问题是:

“对于上一个阶段所确定的问题有可行的解决办法或值得做吗?

可行性研究比较简短,这个阶段的任务不是具体解决问题,而是研究问题的范围,探索这个问题是否值得去解,是否有可行的解决办法。

在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。

可行性研究应该导出系统的高层逻辑模型(通常用数据流图表示),并且在此基础上更准确、更具体地确定工程规模和目标。

然后分析员更准确地估计系统的成本和效益,对建议的系统进行仔细的成本/效益分析是这个阶段的主要任务之一。

(3)制定计划

确定要开发软件系统的总目标,给出它的功能、性能、可靠性以及接口等方面的要求;研究完成该项软件任务的可行性,探讨解决问题的可能方案;制定完成开发任务的实施计划,连同可行性研究报告,提交管理部门审查。

(4)需求

对待开发软件提出的需求进行分析并给出详细的定义。

编写出软件需求说明书及初步的用户手册,提交管理机构评审。

这个阶段的任务仍然不是具体地解决问题,而是准确地确定“为了解决这个问题,目标系统必须做什么”,主要是确定目标系统必须具备哪些功能。

●系统分析员在需求分析阶段必须和用户密切配合,充分交流信息,以得出经过用户确认的系统逻辑模型。

通常用数据流图、数据字典和简要的算法表示系统的逻辑模型。

●Ataninitialmeetingbetweenclientanddevelopers,theclientoutlinestheproductasheorsheconceptualizes.(客户勾勒产品轮廓)

●考虑若干约束条件:

Atypicalconstraintisthedeadline.(最基本的约束是产品交付日期);Themostimportantconstrainusuallyisthecost.(最重要的约束是费用(价格))

(5)规格说明

规格说明文档须明确描述产品的功能-即明确说明产品要做什么,并且列出产品要满足的任何约束。

规格说明文档包括产品的输入和要求的输出。

(规格说明构成了合同的基础,验收时需要对照检查)

Ambiguous(二义性、模糊性)不应当包含不严密的词汇、如应当、可能、充分、足够等

Incomplete(不完整)

软件规格说明一般包括:

1)功能规格说明。

对软件所应具备的功能作出规定;

2)性能规格说明。

对软件所应具备的性能,如计算精度、响应速度和占用存储空间的大小等作出规定;

3)接口规定说明。

对软件与其环境之间、软件各组成部分之间的接口关系作出规定;

4)设计规格说明

(6)软件设计

把已确定了的各项需求转换成一个相应的体系结构。

进而对每个模块要完成的工作进行具体的描述。

编写设计说明书,提交评审。

设计的目的是确定产品如何做,包括architecturaldesign(结构设计、概要设计)anddetaileddesign(详细设计).如果规格阶段的目标是阐明产品将做什么,设计阶段的目的是确定它将如何做。

●设计阶段的目标

1)Choosingthedatastructuresthatwillrepresenttheinformationmanipulatedbytheprogram选择程序信息处理的数据结构

2)Choosingthealgorithmsthatwilloperateonandmanipulatethedatastructures选择对数据结构进行处理的算法

3)Determiningtheinternaldataflows,thatis,howtheinformationwillmovefromcomponenttocomponentoftheprogram确定内部数据流,即信息在程序部件与部件之间是如何流转的

4)Breakingtheproductintomodules,orself-containedpiecesofcodethatinteractwithothermodulesintheproductthroughawell-definedinterface将产品分解成为通过明确定义的产品接口进行交互的模块或独立的代码块

5)Designingtheinterfaceforeachmodule设计每个模块的接口

●总体设计

这个阶段必须回答的关键问题是:

“概括地说,应该如何解决这个问题”,

首先,应该考虑几种可能的解决方案。

1)    低成本的解决方案;

2)    中等成本的解决方案。

3)    高成本的“十全十美”的系统。

系统分析员应该使用系统流程图或其他工具描述每种可能的系统,估计每种方案的成本和效益,还应该在充分权衡各种方案的利弊的基础上,推荐一个较好的系统(最佳方案),并且制定实现所推荐的系统的详细计划。

如果用户接受分析员推荐的系统,则可以着手完成本阶段的另一项主要工作。

上面的工作确定了解决问题的策略以及目标系统需要哪些程序,但是,怎样设计这些程序呢?

结构设计的一条基本原理就是程序应该模块化,也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。

总体设计阶段的第二项主要任务就是设计软件的结构,也就是确定程序由哪些模块组成以及模块间的关系。

通常用层次图或结构图描绘软件的结构。

总体设计的目的是确定产品的结构,设计人员将产品分解成模块,模块与其它部分定义完备的接口。

每个模块的接口,既传递模块的参数和模块返回的参数,必须详细定义。

●详细设计

总体设计阶段以比较抽象概括的方式提出了解决问题的办法。

详细设计阶段的任务就是把解法具体化,也就是回答下面这个关键问题:

“应该怎样具体地实现这个系统呢?

Foreachmodule,algorithmsareselectedanddatastructureschosen.为每个模块选择相应的算法和数据结构。

这个阶段的任务还不是编写程序,而是设计出程序的详细规格说明。

这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图,它们应该包含必要的细节,程序员可以根据它们写出实际的程序代码。

通常用HIPO图(层次加输入/处理/输出图)或过程设计语言(ProcessDesignLanguage,简称PDL),也称程序描述语言(ProgramDescriptionLanguage),又称为伪码描述详细设计的结果。

设计中需要详细记录(1、便于回溯;2、便于维护)

(7)程序编写

把软件设计转换成计算机可以接受的程序代码。

这个阶段的关键任务是按照设计要求写出正确的容易理解、容易维护的系统模块。

根据文档内容开始实现模块、数据结构和算法

(8)集成

完成所有的模件测试和文档,开始进行集成阶段。

本阶段的目的是组合所有模块,测试其相互操作,确定从整体上的功能与规格说明满意度以及在所有环境下的运行正确性。

SQA小组负责测试工作,但开发人员也必须始终进行测试,创建和保存测试用例以便SQA小组使用。

这个阶段的关键任务是通过各种类型的测试(相应的调试)使系统达到预定的要求。

最基本的测试是集成测试和验收测试。

应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来,做为系统配置的一个组成部分。

1)IntegrationTesting(集成测试)

Thepurposeofintegrationtestingistocheckthatthemodulescombinetogethercorrectlytoachieveaproductthatsatisfiesitsspecifications.集成测试的目的是检查模块是否正确组合在一起,是否实现规格说明文档中的功能要求。

bottom-upintegration(充分测试、重复测试)和top-downintegration(较早发现集成错误、底层模块测试不充分)sandwichintegration(混合方法)

2)ProductTesting(产品测试)

集成测试完成后由SQA小组进行产品测试,依照产品规格说明进行整体测试,尤其针对各项约束进行测试(性能)、正确性测试、健壮性测试(容错能力)、源代码及文档工作是否完成、一致等(使用试验数据)。

3)AcceptanceTesting(验收测试)

集成测试的最后的阶段是验收测试(试运行),在产品交付客户前,由用户使用真实数据在真实环境中对产品进行测试。

4)AlphaandBetaTesting(α测试和β测试)

COTS(shrink-wrappedsoftwareproduct)软件产品测试完成后交给潜在客户potentialfuturecustomers进行现场测试,第一个版本称为α测试,经过纠正后的“α版”称为“β版”,“β版”一般是投放市场前的最终版本。

(9)运行/维护

已交付的软件投入正式使用,并在运行过程中进行适当的维护。

在客户接受产品之后,开发人员对产品进行的改变成为维护。

maintenanceisanintegralpartofthesoftwareprocess.维护是软件进程的主要部分。

维护阶段的关键任务是,通过各种必要的维护活动使系统持久地满足用户的需要。

四类维护活动:

改正性维护、适应性维护、完善性维护、预防性维护。

实际上每一项维护活动都应该经过提出维护要求(或报告问题),分析维护要求,提出维护方案,审批维护方案,确定维护计划,修改软件设计,修改程序,测试程序,复查验收等一系列步骤,因此是经历了一次压缩和简化了的系统定义和开发的全过程。

每一项维护活动都应该准确地记录下来,做为正式的文档资料加以保存。

(10)退役

(11)两个贯穿始终的工作:

1)测试。

在设计测试用例的基础上检验软件的各个组成部分,主要包括:

a)Verification(验证,每阶段结束前进行);b)Validation(确认,移交用户前进行)。

如果将测试作为单独阶段,将不能连续测试;

2)文档

文档需在各阶段结束前完成;开发结束后开发人员或者负责人被抽调做别的工作,文档被拖延;需求变化,设计变化,文档未随之变化;软件开发过程·软件测试:

阶段

关键问题

结束标准

问题定义

问题是什么?

关于规模和目标的报告书

可行性研究

有可行的解吗?

系统的高层逻辑模型

成本/效益分析

数据流图

需求分析

系统必须做什么?

系统的逻辑模型

数据流图

数据字典

算法描述

总体设计

概括地说,应该如何解决这个问题

可能的解法:

系统流程图

成本/效益分析

推荐的系统结构;

层次图或结构图

详细设计

怎样具体地实现这个系统?

编码规格说明:

HIPO图或PDL

编码和单元测试

正确的程序模块

源程序清单;单元测试方案和结果

集成与测试

符合要求的软件

综合测试方案和结果;完整一致的软件配置

维护

持久地满足用户需要的软件

完整准确的维护记录

3.掌握为什么没有计划、文档和测试阶段1%

WhyThereIsNoPlanningPhase计划阶段,TestingPhase测试阶段orDocumentationPhase文档阶段?

Planning,continual持续的testinganddocumentationactivities活动arecarriedout执行throughout贯穿于thelifecycle.Thereisnoseparate独立的planning,testingordocumentationphase.Thistestingistheresponsibility职责of

Everysoftwareprofessional专业人员,andThesoftwarequalityassurancegroup软件质量保证小组(SQAgroup)

DocumentationMustAlwaysbeCurrent:

Keyindividualsmayleavebeforethedocumentationiscomplete.Wecannotperformaphasewithouthavingthedocumentationof

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 小学教育 > 语文

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2