软件工程.docx

上传人:b****8 文档编号:11343409 上传时间:2023-02-28 格式:DOCX 页数:38 大小:185.70KB
下载 相关 举报
软件工程.docx_第1页
第1页 / 共38页
软件工程.docx_第2页
第2页 / 共38页
软件工程.docx_第3页
第3页 / 共38页
软件工程.docx_第4页
第4页 / 共38页
软件工程.docx_第5页
第5页 / 共38页
点击查看更多>>
下载资源
资源描述

软件工程.docx

《软件工程.docx》由会员分享,可在线阅读,更多相关《软件工程.docx(38页珍藏版)》请在冰豆网上搜索。

软件工程.docx

软件工程

目录

1软件工程概述2

1.1软件和软件工程定义2

1.2软件危机2

1.3软件工程的目标2

1.4软件生存周期与开发模型2

2系统策划4

2.1问题定义4

2.2可行性研究4

3需求分析4

3.1需求分析概述4

3.2需求说明书5

3.3结构化分析方法6

3.4数据流图6

3.5数据字典8

4软件设计概述9

4.1目标和任务9

4.2设计方法和步骤9

4.3文档10

4.4设计复审10

4.5软件设计准则10

4.6面向对象的程序设计方法12

5软件的编码12

5.1编程语言的选择13

5.2编程风格13

6软件测试14

6.1软件测试目的和方法14

6.2软件测试的分类15

6.3测试阶段的一些基本原则15

6.4测试阶段的几个步骤15

6.5软件测试策略16

7软件维护17

7.1维护的基本概念17

7.2维护的实施17

8软件项目管理17

8.1软件项目计划与组织17

8.2软件项目成本管理18

8.3软件项目进度控制19

8.4软件质量保证19

8.5软件配置管理20

 

1软件工程概述

1.1软件和软件工程定义

软件是由计算机程序演变而形成的一种概念。

程序是按既定算法,用某种计算机语言规定的指令或语句编写的指令或语句的集合。

软件是程序再加上程序实现和维护程序时所必需的文档的总称。

软件=程序+文档

软件工程是从技术(方法和工具)和管理两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

软件工程的理论、方法、技术都是建立在计算机科学的基础上,它是用管理学的原理、方法来进行软件生产管理;用工程学的观点来进行费用估算,制定进度和方案;用数学的方法来建立软件可靠性模型以及分析各种算法和性质。

1.2软件危机

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

软件危机表现在下面几个方面:

(1)不能准确估计软件开发的成本与进度;

(2)用户对“已完成的”软件系统经常不满意;

(3)软件产品质量往往靠不住;

(4)软件难以维护;

(5)软件无完整的文档,无法用以管理和控制软件的开发和维护;

(6)软件费用急剧上升;

(7)软件生产效率低,供不应求。

1.3软件工程的目标

可修改性(modifiability):

容许对系统进行修改而不增加原系统的复杂性。

有效性(efficiency):

指软件系统的时间和空间效率。

可靠性(reliability):

能够防止因概念、设计和结构等方面的不完善造成软件系统失效,具有挽回因操作不当造成软件系统失效的能力。

可理解性(understandability):

系统具有清晰的结构,能直接反映问题的需求。

可维护性(maintainability):

软件产品交付用户使用后,能够对它进行修改,以便改正潜在的错误和其它属性,使软件产品适应环境变化等方面工作的难易程度。

可重用性(reusability):

是指软件可以在多种场合使用的程度。

可适应性(adaptability):

软件在不同系统约束条件下,使用户需求得到满足的难易程度。

可移植性(portability):

软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。

可追踪性(traceability):

根据软件需求对软件设计、程序进行正向追踪,或者根据程序、软件设计对软件需求进行逆向追踪的能力。

可互操作性(interoperability):

多个软件元素相互通信并协同完成任务的能力。

1.4软件生存周期与开发模型

软件从定义开始,经过开发、使用和维护直到最终退役的全过程称为软件生存周期。

1.4.1瀑布模型

特点:

(1)阶段间具有顺序性和依赖性;

(2)每个阶段必须完成规定的文档;

(3)每个阶段结束前完成文档审查,及早改正错误,但:

开发过程一般不能逆转,否则代价太大。

实际的项目开发很难严格按该模型进行。

客户往往很难清楚地给出所有的需求,而该模型却要求如此。

软件的实际情况必须到项目开发的后期客户才能看到,这要求客户有足够的耐心。

应用范围:

(1)用户的需求非常清楚全面,且在开发过程中没有或很少变化

(2)开发人员对软件的应用领域很熟悉。

(3)用户的使用环境非常稳定。

(4)开发工作对用户参与的要求很低

1.4.2原型模型

特点:

(1)可以得到比较良好的需求定义,容易适应需求的变化。

(2)有利于开发与培训的同步。

(3)开发费用低、开发周期短、维护容易且对用户更友好。

客户与开发者对原型理解不同

准确的原型设计比较困难

不利于开发人员的创新

应用范围:

(1)对所开发的领域比较熟悉而且有快速的原型开发工具

(2)项目招投标时,可以以原型模型作为软件的开发模型

(3)进行产品移植或升级时,或对已有产品原型进行客户化工作时,原型模型是非常适合的。

1.4.3基于构件的开发模型

属于演化式开发或迭代式开发,其开发过程:

Ø客户的交流,获得问题的定义

Ø标识基本类

Ø计划与风险分析

Ø类的复用或重新开发

Ø构造系统

Ø用户评估

特点:

(1)采用了先进的面向对象技术。

(2)基于构件库的开发,这是软件复用的基础,开发速度快。

(3)融合了螺旋模型特征

(4)支持软件开发的迭代方法,是一种演化型的开发技术。

2系统策划

2.1问题定义

问题定义阶段的任务是要确定软件系统所要解决的任务。

分析人员在与用户和部门负责人交流之后,应提出关于问题性质、工程目标和规模的书面报告,即软件系统目标与范围的说明。

为了成功地完成问题定义阶段的任务,需要硬件人员和软件人员的共同参与,这一阶段是软件生存周期中较短的阶段。

2.2可行性研究

(1)可行性研究的任务

可行性研究的目的在于用最小的代价确定在问题定义阶段确定的系统目标和规模是否现实,所确定的问题是否可以解决,系统方案在经济上、技术上和操作上是否可以接受。

可行性研究着重考虑以下几个方面:

经济可行性。

估计开发费用以及新系统可能带来的收益,将两者进行权衡,看结果是否可以接受。

②技术可行性。

对要求的功能、性能以及限制条件进行分析,看是否能够做成一个可接受的系统。

所考虑的因素通常还应包括开发的风险,是否能够得到需要的软件和硬件资源,以及一个熟练的有能力的开发队伍,另外与系统开发有关的技术是否足以支持系统的研制。

技术可行性的估计,需要有经验的人员去完成。

③操作可行性。

判断系统的操作方式在该用户组织内是否可行。

(2)推荐方案

根据可行性研究结果要做出的决定是:

是否继续按预定目标进行开发。

可行性分析人员必须清楚地表明他对这个关键性决定的建议。

如果认为值得继续进行这项开发工程,则应提供一种最好的解决方案,并说明理由。

(3)软件开发计划

分析人员应该为推荐的系统草拟一份软件开发计划。

软件开发计划是根据用户提出的功能性要求,开发时间和费用的限制而制定的,它要说明该项目需要的硬件资源和软件资源,需要的开发人员的层次和数量,项目开发费用的估算,开发进度的安排等。

软件开发计划的阅读者可以包括软件主管部门、用户和技术人员。

所确定的成本与进度可供主管部门复审。

软件开发计划同时也给出了整个软件生存周期的基本预算和进度安排。

3需求分析

3.1需求分析概述

软件的需求分析是开发期的第一个阶段。

这个阶段的基本任务是:

用户和分析人员双方共同来理解系统的需求,并将共同理解形成一份文件,即软件需求说明书。

该阶段是面向用户问题的,它主要是对用户的业务活动进行分析,明确在用户的业务环境中软件系统应该“做什么”。

需求分析阶段的特点:

用户与开发人员无共同语言,很难进行交流。

有时进入到设计、编码阶段才能明确,更有甚者,到开发后期还在提新的要求。

这无疑给软件开发带来困难。

如果在需求分析产生一个错误,这个错误发现越晚,则花的代价越高。

需求分析的任务是理解和表达用户的要求。

用户的要求包括软件系统的范围、功能、性能、限制和约束。

范围是指软件的规模有多大,处理的对象及性质是什么;

功能是指能做什么样的加工和处理,如数据录入、查询、统计分析、打印报表等;

性能是指处理数据量的多少、系统响应时间、查询速度、数据的精度、系统工作可靠性等;限制和约束是指开发费用、开发周期、可使用的资源等。

其中功能要求是基本的,它又包括数据要求和处理要求两个方面。

需求分析是在系统分析员主持下,由用户和软件开发人员参加。

参加需求分析的用户人员应有三个层次,即企业负责人,各部门负责人,具体工作人员。

3.2需求说明书

需求说明书主要有三个作用:

作为用户和软件开发人员之间的合同;作为开发人员进行设计和编程的根据;作为软件开发完成后验收的依据。

编写需求说明书时,应该完整、一致、精确、无二义性,同时又要简明、易懂、易修改。

它越精确,以后出现错误、混淆、反复的可能性就越小。

需求说明书包括的内容和书写参考格式如下:

一、概述

二、数据描述

·        数据流图

·        数据字典

·        系统接口说明

·        内部接口

三、功能描述

·        功能

·        处理说明

·        设计的限制

四、性能描述

·        性能参数

·        测试种类

·        预期的软件响应

·        应考虑的特殊问题

五、参考文献目录

六、附录

概述是从系统的角度描述软件的目的和任务。

数据描述是对软件系统所必须解决的问题做出的详细说明。

功能描述中描述了为解决用户问题所需要的每一项功能的过程细节。

对每一项功能要给出处理说明和在设计时需要考虑的限制条件。

在性能描述中说明系统应达到的性能和应该满足的条件,以及测试的方法和标准,预期的软件响应和可能需要考虑的特殊问题。

参考文献目录中应包括与该软件有关的全部参考文献,其中包括前期的其它文档、技术参考资料、产品目录手册以及标准等。

附录部分包括一些补充资料,如列表数据、算法的详细说明、框图、图表和其它材料。

3.3结构化分析方法

结构化分析(SA,StructuredAnalysis)方法是一种简单实用、使用很广的方法。

SA方法与设计阶段的SD方法联合使用,能够较好地实现一个软件系统的研制。

SA方法的基本思想和步骤是采用“分解”和“抽象”的基本手段,自顶向下逐层分解,使分解工作有条不紊地进行,使复杂的问题有效地被控制。

逐层分解体现了抽象的原则,使人们不至于纠缠于具体细节而是有控制地逐步地了解更多的细节,直至最详细的内容。

SA方法在表达问题时尽可能用图形的方法,因为图形比较形象、直观,容易理解。

用SA方法来描述软件将要处理的信息时,使用数据流图和数据字典等描述工具。

数据流图表示了软件的信息流向和信息的加工,而数据字典是对这些信息和加工进行更详细的描述。

还可以使用结构化语言、判定表、判定树对信息加工的加工逻辑进行描述。

使用SA方法进行软件需求分析时,可按如下步骤进行:

(1)建立当前系统的物理模型。

即理解当前的现实环境,获得当前系统的物理模型。

当前系统的物理模型就是现实环境的真实写照,在理解了当前系统是怎样做的情况下,用数据流图等形式将现实环境表达出来。

(2)建立当前系统的逻辑模型。

通过对物理模型的分析,找到本质性的因素,抽象出当前系统的功能和性能,建立当前系统的逻辑模型。

(3)建立目标系统的逻辑模型。

首先要清楚所建立的目标系统的功能,进一步分析与当前系统逻辑模型的差别,将当前系统的数据流图分成两部分,一部分是与目标系统相同的部分,另一部分是与目标系统不同的即变化的部分。

将变化的部分重新分析和设计,建立一个目标系统的逻辑模型。

(4)为目标系统的逻辑模型作补充。

为了对一个软件系统作出完整的说明,需对已得到的结果作一些补充。

如说明目标系统的人机边界,即确定系统的范围。

还要说明系统逻辑模型中未详细考虑的一些细节问题,如出错处理,系统如何启动和结束,系统输入输出格式,系统性能方面的其它要求(如响应时间、存储容量)等等。

3.4数据流图

数据流图是描述系统中数据流程的图形工具,它标识了一个系统的逻辑输入和逻辑输出以及把逻辑输入转换为逻辑输出所需要的加工。

3.4.1数据流图的组成

数据流图由四种基本成分组成,如图所示:

数据流图的基本成分

(1)数据流——用箭头表示,箭头旁边用文字加以标记;它是一条流水线,在这条流水线上有一组由一定成分组成的数据在流动。

数据流的流向由箭头方向指出,可从加工流向加工,也可以从加工流向数据存储或从数据存储流向加工,也可以从源点流向加工或从加工流向终点。

每条数据流均有一个合适的名字,表明数据流的含义,但流入或流出数据存储的数据流可以不命名。

(2)加工——用圆圈表示,圆圈内用文字加以标记;它是对数据进行的操作。

每个加工除了命名外,还有一个编号,说明这个加工在层次分解中的位置。

(3)数据存储——用双线表示,双线旁边用文字加以标记;它是数据流在加工过程中产生的临时文件或加工过程中需要查找的信息。

数据流反映了系统中流动的数据,表现出动态数据的特征;数据存储反映了系统中静止的数据,表现出静态数据的特征。

(4)数据的源点和终点——用方框表示,方框内用文字加以标记。

它表示系统中数据的来龙去脉,通常存于系统之外的人和组织之中。

源点和终点的表达不必很严格,它只是起到注释作用,补充说明系统与其它外界环境的联系。

学生档案管理系统数据流图

3.4.2数据流图的结构

一个实际的软件系统是非常复杂的,为了描述它们的信息流向和加工,用一套分层的数据流图来描述,有顶层、中间层、层底之分。

(1)顶层。

决定系统的范围,决定输入输出数据流,它说明系统的边界,把整个系统的功能抽象为一个加工。

(2)中间层。

顶层之下是若干中间层,某一中间层既是它上一层加工的分解结果,又是它下一层若干加工的抽象,即它又可进一步分解。

(3)层底。

若一张数据流图的加工不能进一步分解,这张数据流图就是底层的数据流图。

故底层数据流图的加工是由基本加工构成的,所谓基本加工是指不能再进行分解的加工。

3.4.3分层数据流图的画法

画分层数据流图时,应根据分解和抽象的原则自顶向下逐层分解画出。

在画各层数据流图时,要注意父图与子图的平衡,各层数据流图及其加工的编号和数据守恒问题。

(1)父图与子图的平衡。

在分层数据流图直接相邻的两层中,上层是下层的父图,下层是上层的子图。

一般来说,父图中有几个加工,下层就有几个子图,但子图的个数也可以少于父图中加工个数,即父图中有些加工可能是基本加工,它就没有子图。

父图中某个加工的输入输出数据流应该同相应的子图的输入输出流的数目相同,分层数据流图的这种特性称为父图与子图的平衡。

(2)子图的编号规则。

子图的编号即为父图相应加工的编号;子图中加工的编号由子图号、小数点、局部号构成。

顶层只有一张,只有一个加工,不必编号。

第一层子图的编号为0,图中加工的编号为0.1,0.2,…,通常简化为1,2,…。

对应的子图编号为1图,2图,…,这是第二层数据流图的编号,该层图中加工的编号为1.1,1.2,…,2.1,2.1,…。

这样可以根据子图编号中小数点个数来确定该子图在哪一层上。

(3)数据守恒。

所谓数据守恒是指加工的输入输出数据流是否匹配,即一个加工既有输入数据流又有输出数据流。

(4)完善数据流图。

画出了分层数据流图后,应进一步完善,提高数据流图的可理解性。

在对加工进行分解时,应注意分解的均匀性,即分解为大小均匀的几部分,应避免不均匀的分解,即在某一张数据流图中,某些加工已是基本加工,而另一些加工还可以进一步分解为好几层,这时应重新分解。

一个加工一次分解为多少个子加工为好?

经验证明不超过7个为宜。

分解过少,可能有较多的层次,分解过多,使人难以理解。

一般分解应是自然的,概念上是合理的,清晰的。

若一张子图上的所有加工都是不可再分解的基本加工,这时分解过程就可结束了。

3.5数据字典

数据流图描述软件系统的信息流程和加工,但并没有对各个成分进行详细说明,SA方法使用数据字典对这些成分进行详细说明。

数据流图中的数据流名、数据存储名、数据项名、基本加工名的严格定义的集合构成了数据字典。

数据字典是SA方法重要工具之一,与数据流图配套,缺一不可。

数据流图中的非基本加工不必描述,它们是基本加工的抽象,可用基本加工的组合来说明,源点终点也不必在数据字典中描述。

因此数据字典中有如下四种条目:

数据流、数据存储、数据项和基本加工。

数据字典的作用是建立一组一致的定义,便于用户与分析员之间、用户与程序员之间的通讯,使程序员用一致的数据项和数据存储定义来描述数据库和数据结构,避免了模块接口和系统接口的不一致性。

建立数据字典时要求无冗余,同一件事不能在几处说明,否则引起修改的麻烦。

为避免冗余,需要建立一些约定。

数据字典可用人工管理,也可用计算机管理。

(1)符号约定

数据字典的描述方法可采用卡片格式。

对数据流、数据存储和数据项的描述可采用如下符号:

“+”表示与。

例如:

登记表=姓名+专业+班级+年龄+性别+籍贯;

“|”表示或。

例如:

存期=[1|2|3|5],表示银行存期可有1年,2年,3年,5年,而“[]”表示选择项。

“{}”表示重复。

例如:

发票={发票行},表示一张发票有若干行。

(2)数据字典条目的描述

数据字典各条目的详细内容及格式如图所示。

对于数据流名、数据存储名、数据项名的条目,有若干项是共同的。

名字表示该条目的名称;种类表示是数据流、数据存储、数据项或基本加工中的某一种;简述是该条目的作用、含义的简单描述;别名是指该条目名的另一个名字;组成是指该条目由哪些数据成分构成,可用上述的符号约定来描述。

各种条目还有自己专有项目,在图中已表示出来了。

数据字典(a)数据流条目;(b)数据存储条目;(c)数据项条目;(d)基本加工条目

(3)加工逻辑的描述

加工逻辑是基本加工条目中的一项重要内容,有三种工具来描述加工逻辑:

结构化语言,判定表,判定树。

结构化语言是描述加工逻辑的常用工具,它是介于自然语言和形式语言之间的一种语言,其结构分为内、外两层,外层语法是比较具体的,内层语法比较灵活。

外层语法描述操作的控制结构,如顺序、选择和循还等,这些控制结构将加工中的各个操作连起来。

内层语法通常由分析员根据系统的具体特点及用户接受能力灵活决定,一般来说,只有祈使句一种,明确地表达“加工”要做什么,加工对象用的名词都是数据字典中定义过的词或自定义的词,动词要避免用“处理”等抽象的词汇,不用形容词和副词,允许引入运算符和关系符。

在描述加工逻辑时,如果有一系列逻辑判断,用结构化语言描述就不直观,也不简捷,这时可用判定表或判定树来描述。

判定表是用表格的形式列出在什么条件下作什么处理,一目了然。

判定树是以一棵从左向右生长的树型表示来描述在各种条件下要作的事情,树的各个分支表示某种条件,分支的端点表示该分支对应的条件下要作的处理。

(4)数据字典的用途

数据字典作为分析阶段的工具,有助于改进分析人员和用户间的通信,进而消除很多的误解,同时也有助于改进不同的开发人员之间的通信。

开发人员如果都能按数据字典描述的数据设计模块,则能避免许多因数据不一致而造成的麻烦。

此外,数据字典对于应用系统中的数据库设计也起着重要作用。

4软件设计概述

4.1目标和任务

需求分析阶段是解决软件系统“做什么”的问题,设计阶段是解决软件系统“如何做”的问题,也就是软件系统的功能、性能如何实现,最后应得到软件设计说明书。

设计阶段是较为重要的阶段,设计质量的好坏直接影响到软件系统的可靠性,因此,在设计阶段要达到如下的目标:

(1)提高可维护性。

软件工程按阶段进行,但各阶段相互有影响,由于软件维护费用极高,因此在设计阶段就需要考虑设计一个可维护的软件,它体现在软件可读性、可扩充性和可修改性上。

(2)提高可理解性。

可理解性指结构清晰,层次分明,结构程度高,文档规范化、标准化。

对软件人员来说,要易读易理解,对用户来说要易使用。

(3)提高可靠性。

可靠性包含正确性和健壮性两个方面,正确性指软件系统本身没有错误,健壮性指在输入数据不合理或异常时,软件系统还能适应工作,不造成严重的损害。

软件的可靠性是一个重要的目标,它涉及到软件系统能否投入工作,使用后效率是否好的问题。

设计阶段分为两步:

总体设计和详细设计。

4.2设计方法和步骤

软件设计方法是软件工程中最早发展的领域之一,其工作流程如图所示。

总体设计是为软件系统定义一个逻辑上一致的结构:

进行模块划分,建立模块层次结构及模块间的调用关系,设计全局数据结构及数据库,设计系统接口及人机界面等。

总体设计的方法有许多种。

在早期有模块化方法,功能分解方法,在20世纪60年代后期提出了面向数据流的设计方法,面向数据结构的设计方法,近年来又提出面向对象的设计方法等。

详细设计是根据每个模块的功能描述,设计出每个模块的实现算法,以及这些算法的逻辑控制流程,并设计出这些模块所需的局部数据结构。

详细设计的方法主要有结构程序设计方法。

详细设计的表示工具有图形工具和语言工具,图形工具有程序流程图、PAD(ProblemAnalysisDiagram)图、N–S图,语言工具有伪码和PDL(ProgramDesignLanguage)等。

4.3文档

设计阶段结束要交付的文档是设计说明书。

设计说明书前面部分在总体设计后完成,后面部分是详细设计后写出,分别是总体设计说明书和详细设计说明书。

设计说明书有两个作用:

对于编程和测试,它提供了一个指南;软件交付使用后,为维护人员提供帮助。

设计说明书的框架和内容如下:

(1)概述。

描述设计工作总的范围,包括系统目标、功能、接口等。

(2)系统结构。

用软件结构图说明本系统的模块划分,扼要说明每个模块的功能,分层次地给出各模块之间的控制关系。

(3)数据结构及数据库设计。

对整个系统使用的数据结构及数据库进行设计,包括概念结构设计、逻辑结构设计、物理设计。

用相应的图形和表格把设计结果描述出来。

(4)接口设计。

要进行人机界面设计,说明向用户提供的命令以及系统的返回信息;要进行外部接口设计,说明本系统与外界的所有接口安排,包括软件与硬件之间的接口,本系统与支持软件之间的接口关系。

(5)模块设计。

这是详细设计的结果,根据模块的功能,用详细设计表示工具描述每个模块的流程,描述每个模块用到的数据结构。

4.4设计复审

开发中较早发现错误,可减少错误扩大的机会,考虑周到、计划良好的复审与技术方法一样重要。

复审方法有两种:

一种是非正式的遍查,由一个通晓全部设计的高级技术人员实施,复查者与设计者一起开会来复查所有技术文档;另一种是正式的结构化审查,要组织一个审查小组,事先查看设计文档,由设计者介绍情况,然后进行评价,使用正式的审查表,正式的错误报告。

4.5软件设计准则

(1)软件结构的准则

软件可以从结构上和过程上进行表示,这种表示上的差别是我们理解总体设计和详细设计的先决条件。

软件结构表示软件的系统结构,是一种层次体系,它不考虑时间的先后和执行的顺序,而只给出各软件模块之间的关系和相互作用。

从下图中可看出M调用A、B、C时,没有指明调用A、B、C的次序和条件,即软件结构不提供模块间实现控制关系的操作细节,更不提供模块内部的操作细节。

软件结构

 

软件过程描述每个模块的操作细节,同时也包括一个模块对下一层模块控制的操作细节。

过程的描述就是关

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

当前位置:首页 > 高等教育 > 哲学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1