《软件工程与测试》教案_第1页
《软件工程与测试》教案_第2页
《软件工程与测试》教案_第3页
《软件工程与测试》教案_第4页
《软件工程与测试》教案_第5页
已阅读5页,还剩83页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

婕'工业懿技统

课程软件工程与测试

授课班级1501计等

课时64____________

教师奚修学

扬州工业职业技术学院教案

序号1周次1授课形式新课

授课章节名称第一章软件工程概述

了解有关软件的特点、分类以及发展历程

教学目的了解软件危机及其产生的原因

了解软件工程的相关理念

软件危机及其产生的原因

教学重点

软件工程的相关理念

教学难点软件工程的相关理念

使用教具

课外作业

课后体会结合以往的具体的典型软件进行讲解

1.1软件

一、什么是软件

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

整集合。

程序是按事先设计的功能和性能要求执行的指令序列

数据是使程序能正常操纵信息的数据结构

文档是与程序开发,维护和使用有关的图文材料

二、软件的特点

1、软件是一种逻辑实体,而不是具体的物理实体。因而它具有抽象性

2、软件的生产与硬件不同,在它的开发过程中没有明显的制造过程

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

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

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

•软件本身是复杂的

•实际问题的复杂性

6、程序逻辑结构的复杂性

7、软件成本相当昂贵

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

成本%

195019701985

三、软件分类

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

>系统软件

•操作系统

•数据库管理系统

•设备驱动程序

•通信处理程序等

>支撑软件

•文本编辑程序

•文件格式化程序

•磁盘向磁带向数据传输的程序

•程序库系统

•支持需求分析、设计、实现、测试和支持管理的软件

>应用软件

•商业数据处理软件

•工程与科学计算软件

•计算机辅助设计/制造软件

•系统仿真软件

•智能产品嵌入软件

医疗、制药软件

事务管理、办公自动化软件

计算机辅助教学软件

2、按软件规模进行划分:

类别参加人员数研制期限源程序行数

微型11〜4周0.5k

小型11~6月lk~2k

中型2〜51〜2年5k〜50k

大型5〜202〜3年50k—100k

甚大型100—10004〜5年1M(=1000k)

极大型2000-50005〜10年IM〜10M

3、按软件工作方式划分:

•实时处理软件

•分时软件

•交互式软件

•批处理软件

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

•项目软件

•产品软件

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

•一次使用

•频繁使用

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

•高可靠性软件

•一般可靠性软件

四、软件发展阶段

>程序设计阶段(50至60年代)

多用于科学过程计算,采用机器语言或汇编语言编程,程序任务单一,编程难度大,多数

是自编自用,可移植性差,软件还没有形成产品。

>程序系统阶段(60至70年代)

以“软件作坊”的形式制作软件产品。软件开发的主要内容是编写程序,核心问题是技术

问题,而其他文档、技术标准以及维护等问题被忽略,导致软件危机的爆发。

>软件工程阶段(70年代以后)

1968年在联邦德国召开的计算机国际会议上正式提出“软件工程”术语,正是软件危机

问题的不断出现,推动着软件工程方法学的快速发展。

1.2软件危机

一、软件危机现象

•软件开发成本、进度的估计不准确

•软件产品与用户的要求不一致

•软件产品质量可靠性差

•软件文档不完整、不一致

•软件产品可维护性差

•软件生产率低

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

二、软件危机产生的原因

•软件的不可见性

•软件系统规模庞大

•软件生产工程化管理程度低

•对用户需求了解程度不够

•对软件维护重视程度不够

•软件开发工具自动化程度低

1.3软件工程

一、软件工程概念

•Boehm:运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这

些程序所必需的相关文件资料

•IEEE:软件工程是开发、运行、维护和修复软件的系统方法。其中“软件”被定

义为:计算机程序、方法、规则、相关文档资料,以及程序运行是需要的数据。

•FritzBauer:建立并使用完善的工程化原则,以较经济的手段获得能在实际机器上

有效运行的可靠软件的一系列方法

二、软件工程三要素:方法、工具、过程

1、软件工程方法:指完成软件开发和维护任务时,应该“如何做”的技术方法。主要

有结构化方法、JSD方法、面向对象方法。

•结构化方法:以软件功能为目标进行软件构建。包括结构化分析、结构化设计、结

构化实现、结构化维护等。

•JSD方法:以软件中的数据结构为基本依据进行软件构建和程序算法设计•是结构

化方法的有效补充。

•面向对象方法:以软件问题域中的对象为基本依据进行软件构建。包括面向对象分

析、面向对象设计、面向对象实现、面向对象维护等。

2、软件工具:为软件工程方法提供了自动的或半自动的软件支撑环境。也叫计算机辅

助软件工程,简称CASE。

•高端CASE工具:用于支持软件分析、设计的CASE工具。如:数据字典管理器、

分析建模图形编辑器、软件结构设计器。

•低端CASE工具:用来支持软件实现和测试的CASE工具。如:程序编辑器、程序

分析器、源程序调试器等。

3、软件工程过程:指软件开发机构在软件工具的支持下,在开发软件的过程中所进行

的一系列软件工程活动。以下是几项基本的活动。

•软件定义:进行软件规格和使用限制的定义

•软件开发:根据软件规格定义制作出软件产品

•软件验证:确认软件能够满足用户提出的要求

•软件维护:修正软件缺陷,并能根据用户需求变化改进软件

三、软件工程管理

软件项目的管理质量决定了软件项目的成败。主要体现在以下几个方面:

1、软件项目规划:即项目开发计划,以明确项目中人员、任务、进度、费用、文档和

目标等。是实现项目有效管理的直接依据。

2、项目资源调配:以项目规划为基本依据,实现对硬件、软件、技术资料以及人员等

资源进行合理调整。

3、软件产品控制:对软件生产过程、软件产品规格等实施有效控制。

•软件质量管理:对软件开发工程中产生的各种文档以及软件产品进行审查和评估。

•软件配置管理:制定标准、跟踪记录变更情况、存档所开发软件的不同版本等。

四、软件工程基本原则

1、采用分阶段的生命周期计划,以实现对项目的严格管理。

把软件项目按照软件的生命周期分成若干阶段,以阶段为基本单位制定出切实可行的计

戈I,并严格按照计划对软件的开发、维护实施有效的管理。

2、坚持阶段评审制度,以确保软件产品质量。

软件的错误大部分出现在编码之前,错误越早发现,越容易修正,所付出的代价越小。

在软件产品形成的过程中,对质量进行过程监控,确保在每个阶段具有较高的质量。

3、实行严格的产品控制,以适应软件规格的变更。

当软件的规格发生变更时,保证软件产品的各项配置保持一致性,能使用规格的变更。

4、采用先进的程序设计技术。

能提高软件开发效率,提高软件产品质量,软件更容易维护,延长产品的使用寿命。

5、软件成果应该能够清楚地审查。

根据软件开发项目的总目标及完成期限,规定开发组织的责任和软件成果标准,使得到

的结果能够清楚的审查。

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

•人员素质高:主要是指专业素质、团队协作意识以及责任意识。

•人数不宜多:一般不超过5人,人员过多会影响相互之间的协作,降低工作效率。

7、承认不断改迸软件工程实践的必要性。

软件过程在实际应用中,应该积极主动地采纳新的软件技术,不断总结新的过程经验。

五、软件工程目标

软件工程目标是基于软件项目目标的成功实现而提出的,体现在以下几个方面:

•付出较低的开发成本

•达到用户所要求的软件功能

•取得较好的软件性能

•软件的可靠性高

•软件易于使用、维护和移植

•能按时完成开发工作,及时交付使用

六、软件工程文化

软件工程文化主要是指软件工程人员所应具备的产品质量观、价值观、道德标准和团队

意识,它决定着一个软件企业能否得到很好的发展。

上网了解有关软件工程的发展现状。

扬州工业职业技术学院教案

序号2周次1授课形式新课

授课章节名称1.3.1软件生命周期1.3.2常用软件过程模型

掌握软件生命周期的概念及全过程

教学目的

了解常用软件过程模型的相关知识

软件生命周期

教学重点

有关过程模型

教学难点有关过程模型

使用教具

课外作业

课后体会结合具体软件开发任务来讲解过程模型

1.3.1软件生命周期

一、软件生命周期概念

1、软件生命周期:软件系统或软件产品从定义、开发、运行维护,直到被淘汰的全过程。

根据我国国家标准《计算机软件开发规范》(GB8566—8),软件生命周期包含:软件定义、

软件开发、软件运行维护三个时期。并可细分为可行性研究、项目计划、需求分析、概要

设计、详细设计、编码实现与单元测试、系统集成测试、系统确认测试、系统运行与维护

等几个阶段。

2、软件过程模型:为了使软件生命周期中的各项任务能够有序地按照规程进行,需要一

定的工作模型对各项任务给以规程约束,这样的工作模型被称为软件过程模型,也叫软件

生命周期模型。

二、软件定义期

软件定义主要是软件系统分析人员和用户的合作,对有待开发的软件系统进行

分析、规划、规格的描述。主要有以下几项工作:

1、软件任务立项:软件项目是从任务立项开始的,以“软件任务立项报告”的形式对项

目的名称、性质、目标、意义和规模等进行定义或说明。

2、项目可行性分析:对待进行的软件项目进行可行性风险评估•提出高层模型,根据高

层模型特征,从技术可行性、经济可行性、操作可行性三个方面,以“可行性研究

报告”的形式,对项目作出是否值得往下进行的回答。

3、制定项目计划:在“可行性研究报告”的基础上,从人员、组织、进度资金、设备等

方面进行合理规划,并以“项目开发计划书”的形式提交书面报告。

4、软件需求分析:以用户需求为基本依据,从功能、性能、数据、操作等方面。对软件

给出完整、准确、具体的描述,以“软件需求规格说明书”的形式提交书面报告。

是从软件定义到软件开发的最关键步骤,“软件需求规格说明书”既是软件开发的基

本依据,也是用户对软件产品进行验收的基本依据。

三、软件开发期

以“软件需求规格说明书”为依据进行软件开发工作,主要有以下进行工作:

1、软件概要设计:对软件系统的结果设计,从总体上对软件的构造、接口、全局数据结

构和数据环境给出设计说明,并以“概要设计说明书”的形式提交书面报告,它将

称为软件详细设计和系统集成的基本依据。

模块是概要设计是构造软件的基本元素,概要设计主要体现在模块的构成和模块的

接口两个方面。但不需要说明模块的内部细节。模块的独立性是有关质量的主要技

术指标,用模块的内聚和耦合两个参数来度量。

2、软件详细设计:以“概要设计说明书”为依据,确定软件结构中每个模块的内部细节,

并以“详细设计说明书”的形式提交书面报告,为编写程序提供最直接的依据。

3、编码和单元测试:

编码必须按照“详细设计说明书”的要求逐个实现模块,一般由程序员来完成,以

获得源程序基本模块为目标。

单元测试以“详细设计说明书”为依据,用于检测每个模块在功能、算法、数据结

构上是否符合设计要求。常常和编码结合在一起进行。

4、系统集成测试:依据概要设计中的软件结构,把经过测试的模块,按照某种集成策略,

将系统组装起来,并完成对整个系统的测试,确保系统在技术上符合设计要求,在

应用上满足需求规格要求。

5、系统确认测试:以用户为主体,以需求规格说明书为依据,对软件各项规格进行确认。

还需要对用户进行一定的培训。以“项目开发总结报告”的书面形式对项目进行总

结。软件系统可以交用户使用。

四、软件运行维护期

软件运行主要和用户相关.

软件维护可以看作是对软件的再次开发,主要涉及到三个方面的任务:改正性维护、

适应性维护、完善性维护。

1、瀑布模型

瀑布模型在1970年前后就已经出现了,直到80年代早期,它一直是唯一被广泛采用的软

件开发模型。从本质来讲,它是一个软件开发架构,开发过程是通过一系列阶段顺序展开

的,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好“返

回”上一个阶段并进行适当的修改,开发进程从一个阶段“流动”到下一个阶段,这也是瀑布

开发名称的由来。如下图所示:

项目廿书

源程^»道里

一、瀑布模型的特点

1、线性化模型结构

视软件项目为一个稳定的线性过程,项目被划分为从上至下的几个阶段,前一个阶段输

出的成果被作为后一阶段的输入条件。

2、各阶段具有里程碑特征

各阶段只能逐级到达,每个阶段度需要产生确定的成果(文档)。

3、基于文档的驱动

文档成为各阶段的里程碑标志,文档也是推进下一阶段工作开展的前提动力。

4、严格的阶段评审机制

各阶段产生的文档需经过严格的评审,经确认以后才能启动下一阶段的工作。

二、瀑布模型的作用

•为软件项目按规程管理提供了便利

•各阶段产生的文档有利于尽早发现问题和解决问题

•为其他过程模型的推出提供了一个良好的平台

三、瀑布模型的缺点

1、各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。

2、由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了

开发的风险。

3、早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。

4、可能会造成大量的人力资源浪费。

基于以上原因,瀑布模型已不再适合现代的软件开发模式。

四、瀑布模型的选择准则

1、在开发时间内,需求比较稳定。

2、分析、设计人员对项目所涉及的应用领域比较熟悉。

3、合同对完成时间和进度要求不严格。

4、低风险项目。

5、用户应用环境稳定。

2、原型模型

一、原型是什么

原型是指模拟某种产品的原始模型,在其他产业中经常使用。软件开发中的原型是软件的

一个早期可运行的版本,它反映了最终系统的重要特性,但功能相对比较简单。

二、原型模型思想的产生

由于种种原因,在需求分析阶段很难得到完全、一致、准确、合理的需求说明,在获得一

组基本需求说明后,先用相对较少的成本,较短的周期开发一个简单的、但可以运行的系

统原型向用户演示或让用户试用,以便及早澄清并检验一些主要设计策略,在此基础上再

开发实际的软件系统。

三、原型模型的原理

原型是利用原型辅助软件开发的一种新思想。经过简单快速分析,快速实现一个原型,用

户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥

补漏洞,适应变化,最终提高软件质量。

四、原型模型的分类

根据原型的不同作用,有三类原型模型:

1、探索型原理:把原型用于开发的需求分析阶段,目的是要弄清用户的需求,确定所期

望的特性,并探索各种方案的可行性。它主要针对开发目标模糊,用户与开发都对

项目都缺乏经验的情况,通过对原型的开发来明确用户的需求。

2、实验型原型:主要用于设计阶段,考核实现方案是否合适,能否实现。对于一个大型

系统,若对设计方案心中没有把握时,可通过这种原型来验证设计方案的正确性。

3、进化型原型:这种原型主要用于及早向用户提交一个原型系统,该原型系统或者包含

系统的框架,或者包含系统的主要功能,在得到用户的认可后,将原型系统不断扩

充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程•进化原型模

型如下图。

软件原型创建软件版本

软件需求细部定义

软件需求框架描述软件产品开发

软件有效性验证

进化原型的特点:

•获得软件需求框架以后,就可以直接进入到对软件的开发中去,可以缩短软件的开发

时间和开发成本。但对于大型软件项目,该模型对项目管理和软件配置管理有一定难

度,适合对中小型软件产品开发。

•通过不断发布新的软件版本从而使软件逐步完善。适合用户急需的软件产品开发,能

够很好地适应用户对需求规格的变更。但过快的变更有可能损伤软件的内部结构,如

果反映版本变更的文档不能得到及时更新的话,对以后的软件维护带来困难。

五、原型模型的运用方式

由于运用原型的目的和方式不同,在使用原型时也采取不同的策略,有抛弃策略和附加策

略。

1、抛弃策略:将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、

一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的。

2、附加策略:将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能

和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,近化型原型就

是采用此策略。

六、原型模型的开发步骤

1、快速分析

在分析人员与用户密切配合下,迅速确定系统的基本需求,根据原型所要体现的特征

描述基本需求以满足开发原型的需要。

2、构造原型

在快速分析的基础上,根据基本需求说明尽快实现一个可行的系统。这里要求具有强

有力的软件工具的支持,并忽略最终系统在某些细节上的要求,如安全性、坚固性、例外

处理等等,主要考虑原型系统能够充分反映所要评价的特性,而暂时删除一切次要内容。

3、运行原型

这是发现问题、消除误解、开发者与用户充分协调的一个步骤。

4、评价原型

在运行的基础上,考核评价原型的特性,分析运行效果是否满足用户的愿望,纠正过

去交互中的误解与分析中的错误,增添新的要求,并满足因环境变化或用户的新想法引起

的系统要求变动,提出全面的修改意见。

5、修改

根据评价原型的活动结果进行修改。若原型未满足需求说明的要求,说明对需求说明

存在不一致的理解或实现方案不够合理,则根据明确的要求迅速修改原型。

3、增量模型

一、增量模型原理

在总体上按照瀑布模型的流程实施项目开发,便于对项目的管理;在软件实际创建过

程中,将软件按功能分成多个增量构件,并以构件为单位逐个地创建与交付,直到所有构

件全部创建完毕,并都被集成到系统中交付用户使用。是将瀑布模型和原型进化模型的优

点进行结合的一种过程模型。

原型进化模型每次交付给用户的是一个新版的软件产品,而增量模型每次交付给用户

的是一个软件产品中的某个组成部分。

二、增量模型的工作流程

开发增量构建

|细化构件需求

三、增量模型的作用

1、需求细节性描述延迟到增量构件开发是进行,有利于用户需求的逐渐明朗,能够有效

适应用户需求的变更。

2、能使软件的需求定义越往后越容易。

3、开发者通过对诸多构件的逐步开发,可以积累开发经验。还有利于技术的复用。

4、有利于从总体上降低软件项目的技术风险。

5、核心构件最先交付使用,它所得到的测试次数也最多,核心构件的可靠性也最高,使

整个系统更具健壮性。

四、增量模型的缺陷

1、由于各个构件是逐渐并入已有的软件体系结构中的,为使新加入的构件不破坏已构造

好的系统部分,就需要软件具备开放式的体系结构。

2、在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化

的能力大大优于瀑布模型和快速原型模型,也使得软件过程的控制失去整体性。

4、螺旋模型

一、螺旋模型思想的产生

软件风险是任何软件项目中都存在的问题,而且项目越大,软件越复杂,风险越大,

软件风险在一定程度上损害软件开发过程,影响产品质量。因此,在软件开发的过程中,

需要及时识别风险,分析风险,采取适当措施规避风险。这种引入了风险分析与规避机制

的过程模型就叫螺旋模型。是瀑布模型、快速原型方法和风险分析方法的有机结合。其工

作流程如下图所示。

二、螺旋模型原理

每个回路表示软件过程的一个阶段,在每个阶段创建原型进行项目试验,以降低各阶

段可能遇到的项目风险。最里面的回路与可行性分析有关,第二个回路与需求分析有关,回

路与概要设计有关,以此类推。每个回路被分成四个部分:

1、制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

2、风险分析:分析评估所选方案,考虑如何识别和消除风险:

3、实施工程:实施软件开发和验证;

4、客户评估:评价开发工作,提出修正建议,制定下一步计划。

三、使用螺旋模型的限制条件

1、螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是

不容易的,因此,这种模型往往适用于软件公司内部使用的大规模软件的开发。

2、如果执行风险分析的费用过高,将大大影响项目的利润,那么进行风险分析毫无意

义,因此,螺旋模型只适合于大规模软件项目。

3、软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会给软件开发工

作带来更大的风险。

5、喷泉模型

喷泉模型是专门针对面向对象软件开发

方法而提出的。“喷泉”这个词体现了面

向对象软件开发过程迭代和无缝的特

性。图中代表不同阶段的圆圈相互重叠,

这明确表示两个活动之间存在交迭;而

面向对象方法在概念和表示方法上的一

致性,保证了在各项开发活动之问的无

缝过渡,事实上,用面向对象方法开发

软件时,在分析、设计和编码等项开发

活动之间并不存在明显的边界。图中在

一个阶段内的向下箭头代表该阶段内的

迭代(或求精)。图中较小的圆圈代表维

护,圆圈较小象征着采用了面向对象范

型之后维护时间缩短了。其优点是可以

提高软件项目开发效率,节省开发时

间。由于喷泉模型在各个开发阶段是

重叠的,因此在开发过程中需要大量

的开发人员,因此不利于项目的管

理。

为避免使用喷泉模型开发软件时开发过程过分无序,应该把一个线性过程(图中的中心垂线)

作为总目标。

6、组件复用模型

一、什么是软件复用

软件复用是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的

成本。软件复用也是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码

级复用,被复用的知识专指程序(如对函数的调用),后来扩大到包括领域知识、开发经验、

设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

二、什么是组件复用

组件复用的主要思想是将软件看成是由不同功能成分的“组件”所组成的有机体,每

一个组件在设计编写时都被设计成可以完成同类工作的通用部件。这样,当完成各种工作

的组件被建立起来后,编写一特定软件的工作就变成了将各种不同组件连接起来,这对于

软件产品的最终质量和维护工作都有本质的改变。

三、组件复用模型

组件复用模型主要包含以下几个阶段的工作任务:需求框架描述

1、需求框架描述:描述系统功能构成,将功能以组

件为单位进行区域划分。组件复用分析

2、组件复用分析:分析哪些组件是现成的,哪些组

件可以在专业组件开发机构购买到,哪些组件必须自己开需求修改和细化

发。

3、需求修改和细化:以提高对现有组件的复用和降系统设计

低新组件的开发为目标,对软件系统的详细需求定义。工

4、系统设计:给予组件技术设计系统框架。组件开发

5、组件开发:开发不能获得复用的新组件。X

6、系统集成:将系统所需要的诸多组件整合在一起,系统集成

组成一个完整的系统。

扬州工业职业技术学院教案

序号3周次2授课形式新课

授课章节名称项目可行性分析、项目成本效益分析与项目规划

掌握成本估算和效益分析的方法

教学目的了解可行性分析的意义、内容及过程

了解项目规划

可行性分析的内容及过程

教学重点成本估算和效益分析

教学难点成本估算和效益分析

使用教具

课外作业

课后体会内容相对比较枯燥一点

1、计算机系统分析

一、计算机系统

计算机系统是一个非常复杂的系统,包含硬件系统、软件系统、网络通信系统、人工操作

系统等诸多子系统。计算机的智能特性是通过软件系统来实现的,因此对软件系统所进行

的分析,必须以整个计算机系统为分析背景来进行。

二、系统分析方法

系统分析是对项目的高层分析,得到的是系统的基本框架。不需要对系统的内部构造做过

多的研究,而是需要将系统分解为多个能够独立工作的组建或子系统。从以下几个方面对

软件及其相关问题作出描述。

1、系统的规模大小、功能范围。

2、系统对硬件环境、网络环境、数据环境和支撑软件的依赖。

3、系统中有关安全保密问题的考虑。

4、与其他相关系统之间的通信问题。

5、用户单位的组织结构,与软件有关的用户的工作流程。

三、建立系统模型

以作图的方式对系统进行直观的描述,主要有系统框架图和系统流程图。

1、系统框架图

使用矩形和带箭头的线段来描述系统的逻辑框架。矩形表示构成系统的组件或子系统,线

段表示组件或子系统之间的关系。

下图是一个图书借阅系统的系统框架图,由图书信息数据库、图书信息录入、借书、还书、

借阅信息查询、相关信息打印、信息备份组成,并以图书信息数据库为核心构建。

2、系统流程图

系统流程图用来描述系统的工作流程,说明系统对数据的加工步骤。有关系统流程图中一

些常用的符号参见课本P29的表3—1。下图是关于图书借阅系统的系统流程图

2、项目可行性分析

一、可行性分析的意义

凡是工程项目都具有工程风险,软件项目更具有高风险的特征。因此在软件项目开始实施

之前,必须对其进行可行性分析。它能给软件项目带来以下积极意义:

1、避免项目开展以后所带来的大量人力、物力和时间上的浪费。

2、对有待开发的系统在体系结构、合作模式等方面作出高层抉择,利于项目以后的实现。

3、可行性分析的结构可作为一个高层框架用于软件需求分析工程之中,便于软件规格定

义工作的顺利开展。

二、可行性分析内容

1、技术可行性分析:确认所采用的技术能够支持系统的成功实现。

•技术限制:从技术的先进性和成熟度作出平衡考虑,以决定采用何种技术进行开发。

•技术资源限制:从开发人员对技术掌握的熟练程度、工程经验的积累程度以及技术资

料的多少等方面作出决定。

2、经济可行性分析:

是对项目实施成本和项目可能带来的经济效益的分析,并以项目成本是否在项目资金限制

范围以内作为项目的一项可行性依据。

另一个因素就是对项目经济效益的分析。对开发商来说,主要是开发一些通用软件所能创

造的价值的大小;对用户来说则是使用软件所带来的间接收益。

3、应用可行性:

应用可行性主要涉及法律法规和用户操作规程等问题。

法律法规:是否构成侵权、是否与法律法规冲突、开发者和用户双方是否就责任、权利等

因素通过合同的形式明确体现出来.

用户操作规程:用户单位的组织结构、不同级别用户的工作流程等。

三、可行性分析过程

1、建立系统模型

•研究现有系统的物理模型

•导出现有系统的逻辑模型

•设想新系统的逻辑模型

•提出新系统的物理模型

2、进行可行性评估

可行性评估是针对新系统的物理模型从技术、经济、应用等方面进行评估。评估结果大致

是以下三种:

•各方面条件以及具备,可以立即着手实施。

•主要条件基本具备,可以暂缓实施。

•基本条件不具备,项目不能实施。

3、撰写可行性分析报告

3、项目成本效益分析

一、项目成本估算

无论是进行可行性分析,还是制度项目预算,或是向用户提供软件报价,都需要对项目进

行成本的初步估算。

1、基于软件规模的成本估算:传统的结构化程序设计与面向对象程序设计在对软件规模

的估算上有所不同,因此对成本的估算方法也有所不同。

基于软件代码行数的人力成本估算公式:

WC=(TCL/MPACL)*MPAP

WC是软件工作成本,TCL是软件的总行数,MPACL是以项目参与人员为基数计算的每

月人均完成代码行数,MPAP是以项目参与人员为基数计算的每月人均工资,其中项目参

与人员包括所有技术人员和管理人员。将软件系统分解为许多基本模块,通过对基本模块

代码行数的估算和累加,得到TCL值。

基于应用对象的人力成本估算公式:

WC=((E(NOP(1-R)))/PROP)*MPAP

WC是软件工作成本,NOP是应用对象的对象点数,R是构造应用对象的代码复用率,

PROP是以项目参与人员为基数计算的每月人均完成对象点数,MPAP是以项目参与人员

为基数计算的每月人均工资,其中项目参与人员包括所有技术人员和管理人员。

2、基于任务分解的成本估算:

以项目任务的人力消耗为依据的成本估算的方法。将项目按照软件生命周期分解为诸多任

务,累加每个任务所消耗的人力成本的总和就得到项目的成本。具体实例参见书本P34。

3、成本估算中的其他因素

以上的成本估算所得到的还只是项目的软件成本,除此之外,一个项目还有其他成本,如

相关硬件和支撑软件的购置费、差旅费、培训费、会议费、材料费、资料费、固定资产折

旧费、咨询费、招待费等等。

为了提高成本估算的准确性,可以考虑采用几种不同的方法,并运用统计技术进行成本统

计分析;或根据自己的项目经验和有关资料,建立项目成本模型,使诸多经验数据在成本

估算中产生作用。另外,在项目实施以后,需要根据项目的实际进展和项目需求变动情况,

适当地对成本进行修正。

二、项目效益分析

项目效益分析分为以下几种情况:

1、用户委托开发的软件项目:效益取决于用户对项目的投资金额是否超过项目实际成本。

2、软件公司自主开发的通用软件:

3、用户使用软件所产生的效益:

在计算项目的经济效益时,需要将未来效益中产生的资金折算为现值进行计算。

资金折算公式是:

资金折现值=资金未来值/(1+k)n

其中k是银行利率,n是软件产品从使用直至淘汰的总年份。

衡量项目经济效益的主要经济指标有:

纯收入:产品使用期内产生的资金收益折算为现值一项目的成本投入。

投资回收期:产品使用期内产生的资金收益折算为现值之和等于项目成本投入所需要的时

间。若回收期高于产品的正常试用期,则项目不可行。

投资回收率:根据资金收益进行利息折算,将其与银行利息做比较,若回收率低于银行利

率,则项目不可行。具体计算公式为:

P=Fl/(1+j)+F2/(1+j)2+...+Fn/(1+j)n

其中P是现在的投资额;Fi是第i年年底的效益(i=1,2,…,n);n是系统的使

用寿命;j是投资回收率;

具体实例参照课本P36

扬州工业职业技术学院教案

序号4周次2授课形式新课

授课章节名称项目规划Visi。工具的使用

了解项目规划的内容

教学目的

掌握Visio工具的使用

项目进度表的制定

教学重点

Visio工具的使用

教学难点Visio工具的使用

使用教具

课外作业

课后体会结合具体软件开发任务来讲解效果不错

1、项目规划

软件工程对项目的要求是计划在先、实施在后。项目初期拟定的计划成为项目开展的驱动

和指南,并以计划书的形式明确体现出来。常用的有:开发计划、验收计划、质量计划、

维护计划、配置管理计划、人员计划等。

一、项目开发计划

项目开发计划是在可行性评估通过以后着手编制的,期涉及的内容包括:

•开发团队的组织结构,人员组成与分工。

•项目成本预算。

•项目对软硬件资源的需求。

•项目任务分解和每项任务的里程碑标志。

•基于里程碑的进度计划和人员配备计划。

•项目风险计划。

•项目监督计划。

项目开发计划需要给出软件项目的各项约束条件,因此开发计划要有一定的灵活性,便于

对计划作出适当的调整。

二、项目进度表

项目进度是基于里程碑制定的,使对项目的管理落实到项目工程中的每一个关键点上去,

可实现对项目的微观管理。把项目中的所有工作分解为若干个独立的活动,需要估算完成

各项活动所需的时间和资源,并按一定的顺序把它们严密地组织起来。

正常情况下,各项活动至少需要持续一周时间,因此,项目进度中的活动可以以周为单位

计量。项目进行过程中难免有偶然事件的发生,在估算进度时,各项活动之间应该有短暂

的事件间隔,便于活动的过度。

甘特图是一种常见的进度图表,可以直观的描述项目任务的活动分解,以及活动之间的依

赖关系、资源配置情况、各项活动的进展情况等。

2、Visio工具的使用

扬州工业职业技术学院教案

序号5周次3授课形式新课

需求分析的任务与过程用户需求的获取

授课章节名称3.13.2

3.3结构化分析工具

了解如何获取用户需求

教学目的掌握需求分析的任务和需求分析的过程

掌握结构化分析工具的使用

需求分析的任务和需求分析的过程

教学重点

结构化分析工具的使用

教学难点结构化分析工具的使用

使用教具

课外作业

结合具体软件开发任务来讲解需求分析的过程和具体任务效果比

课后体会

较好

1、需求分析的任务

由于开发人员精通计算机技术但不熟悉用户的业务领域,而用户熟悉业务领域,但不太懂

计算机技术。因此,要想开发出满足用户要求的软件产品,就需要既懂技术又懂用户业务

的系统分析人员对软件问题进行细致的需求分析。

需求分析是软件工程过程中一个重要的里程碑,形成的需求规格说明书是进行软件开发工

作的依据。涉及面向用户的用户需求和面向开发人员的系统需求。

一、用户需求

用户需求是用户有关软件的一系列意图和想法的集中体现,反应了软件的基本需求框架。

具有以下几个特点。

•用户需求直接来源于用户,可以由用户主动提出、与用户交谈或对用户进行问卷调查

等方式获取。

•用户需求要以文档的形式给用户审查,要用自然语言或直观图表来进行表述。

•用户需求是建立在开发者与用户共同讨论和协商的基础之上的。

•用户方与软件有关的各种层次的人员都应该认真阅读用户需求文档。

二、系统需求

系统需求是提供给软件开发人员和用户方技术人员阅读的,并将作为开发人员设计系统的

基本依据,涉及系统在功能、性能、数据等方面的规格定义。因此要求更严格的形式化语

言进行描述。

功能需求:说明系统应该做什么,对软件系统的服务能力进行全面的详细的描述。在结构

化方法中,通常使用数据流图建立软件系统的功能动态模型。

数据需求:用于对系统中的数据(输入输出数据、加工的数据、存储的数据)进行详细的

说明和规格定义。在结构化方法中,使用数据字典对数据进行全面准确的定义;使用数据

关系模型图(ER图)来描述数据实体以及数据实体之间的关系。

其他需求:指系统在性能、安全、界面等方面需要达到的要求。

2、需求分析过程

需求分析需要经过一系列活动,如下图所示:

从上图可得出需求分析的过程大致如下:

1、以可行性分析中的系统高层模型为前提,分析用户需求,提出系统需求框架。

2、根据系统需求框架的描述,建立需求原型,经过与用户的不断交流以及反复分析用户

需求,完善需求原型。

3、技术人员根据需求原型提取系统模型,并对系统模型进行细化处理,形成需求细节。

4、对需求框架、系统模型、需求细节等稳定进行有效性验证,形成用户和开发人员都能

接受的软件需求规格说明书。

3、用户需求获取

一、研究用户

1、用户:在软件抽象建模过程中,可以把用户看作系统的外部应用接口;从软件的商业

服务角度来看,用户主要是指购置软件的机构、使用软件的部门、操作软件的人。

2、用户的分类:

按软件需求层次:高层用户、中层用户、基层用户。

按使用软件的时间:熟练用户、非熟练用户。

按是否直接操作软件:直接用户、间接用户。

二、用户调查

用户调查是获取用户需求最基本的方法,为保证用户需求的完整性,用户调查需要涉及到

能够代表用户意愿的相关人员。

在调查过程中,根据不同的问题和条件,采用不同的调查方法。常用的调查方法有:

1、用户访谈:指面对面与单个用户进行对话。用户访谈的形式包括结构化和非结构化两

种。结构化是指事先准备好一系列问题,有针对性地进行;非结构化是只列出一个粗略的

想法,根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。

2、需求讨论会:是一种相对来说成本较高的需求获取方法,但也是十分有效的一种。它

通过联合各个关键客户代表,分析人员,开发人员,通过有组织的会议来讨论需求。将与

讨论主体相关的材料提前分发给所有将要参加会议的人。针对材料所列举的问题进行逐项

专题时论,对原有系统、类似系统的不足进行开放性交流,并在此基础上对新的解决方案

进行构思,所有的想法、问题和不足记录下来,形成一个要点清单,作为后续需求分析的

依据。

3、问卷调查:通过精心设计提问问题形成调查问卷,下发到相关人员手中,让他们填写

答案,来获取用户需求。由于缺乏面多面的交流,所获取的信息量也比较有限。因此在实

际工作中,建议先采用用户调查的方式获取一定量的信息,然后有针对性地开展用户访谈。

4、跟班作业:对于一些较为复杂的流程和操作而言,是比较难以用语言和文字进行表达

的,对于这种情况,可以采用到客户的工作现场,一边观察,一边听客户讲解,从而更直

观的了解客户需求。但比较耗费时间。

5、从行业标准、规则中提取需求:如果用户要求所开发的软件产品必须满足一定的行业

标准和业务规则,需求分析师可以通过阅读政策法规、业务规则以及行业标准等各类相关

的文档,并与相关领域的业务专家进行业务交流来了解客户的需求。这种方法要求需求分

析师有一定的行业从业经验,能够了解行业的发展动向。

6、收集用户资料(文档考古):对于一些数据流比较复杂的、工作表单较多的项目,有时

是难以通过说或者观察来了解需求细节的。可以通过对历史存在的一些文档进行研究,主

要的工作重心是通过已经填写完毕的、也就是带有数据的文件、表单、报告,获得所需的

信息。

三、通过原型完善用户需求

把系统主要功能和接口通过快速开发制作为需求原型(探索性原型),以可视化的形式展

现给用户,及时征求用户意见,从而明确无误地确定用户需求。同时,原型也可用于征求

内部意见,作为分析和设计的接口之一,可方便于沟通。原型主要价值是可视化,强化沟

通,降低风险,节省后期变更成本,提高项目成功率。适用于相对较小的项目。在诸多原

型中,界面原型是应用得最广泛的原型。需求原型可以方便由用户需求到系统需求的过度。

四、用户需求陈述

用户需求陈述用于记录用户需求,一般用自然语言进行描述。

扬州工业职业技术学院教案

序号6周次3授课形式新课

授课章节名称结构化分析建模需求有效性验证需求规格定义

掌握数据流模型、数据关系模型、系统状态模型的建立

教学目的

了解有效性验证的内容和方法

教学重点数据流模型、数据关系模型、系统状态模型的建立

教学难点数据流模型、数据关系模型、系统状态模型的建立

使用教具

课外作业

课后体会本节内容需要对用户需求有较好的了解

4.4结构化分析建模

模型是为了理解问题而对问题做的一种符号抽象。一般由一组图示符号和组织这些符号的

规则组成,采用图示方式进行直观的描述。

为了开发复杂的软件系统,需要从不同角度构造系统模型。如,用于描述系统功能组织结

构的此次模型;用于描述系统数据价格流程的数据流模型;用于描述数据实体及其关系的

数据关系模型;用于描述系统行为过程的系统状态模型。

一、功能层次模型

功能层次模型使用矩形表示系统中的子系统或功能模块,使用树形连线结构来表达系统所

具有的功能层次关系。

功能层次模型简洁性特别适合就系统的功能组织结构方面的问题和用户进行讨论。功能层

次模型不仅清晰地说明系统的功能组成关系,还可以利用它对系统的功能关系进行调整,

使系统功能分配更加合理。

下图是一个学生成绩管理下图的功能层次图。

,_______________I_I管理员录入I

I成绩录入I—

1-I任课教师录入I

生I成绩修改I-------1管理员修改I

绩I_I个人成绩查询I

管1成绩查询I■—______________

1-I班级成绩查询I

统I■-I及格率统计I

I成绩统计分析

T_1补考数据统计I

I-I个人成绩打印I

1成绩打印

"I_I班级成绩打印1

二、数据流模型(DFD图)

1、数据流图的特点、用途;

数据流图用来描述系统对的逻辑加工步骤。能方便系统物理模型与逻辑模型之间的转换。

数据流图的基本符号:

图形符号说明

数据接口,系统的外部源头或终点。包括与本系统有关的人员、部

门、机构、其他系统或设备等。

数据处理。表示数据由一种形式转换成另一种形式的某种活动,必

须有数据的流入和流出。可以是人工、程序、设备处理。

匚数据存储。用来表示任何对数据的存储。

数据流。表示数据的流向。数据流必须与一个数据处理相连接。

针对此前的学生成绩管理系统,假设任课教师只负责原始成绩的录入,其他任务全部由教

号处负责,则可得到如下数据流图。

I备份文件查询结果

统计结果

|备g•成绩I成绩查询I[成绩统计II成绩打印I

I备份数据成绩数据成绩数据[成绩数据I

有效成绩

成绩录入成绩数据成

A绩

—单

原f修改后数据

绩成绩修改

原始成绩

--------------------------j修改前数据

教务处=

任课教师

2、数据流图的细化过程

DFD/L2.1DFD/L2,2DFD/L2,3

结构化分析是基于数据流的细化实现的,数据流的细化是从上到下对系统功能进行分层描

述的过程,是结构化分析的关键。

数据流细化原则:

>在多层数据流图中,顶层流图仅包含一个加工,它代表被开发系统。它的输入流是该

系统的输入数据,输出流是系统所输出数据。数据存储不出现在顶层图中。

>数据存储之间不应该有数据流。

>仔细、恰当地为处理命名:处理+对象。

>仔细、恰当地为数据流命名:反映整体含义。

>对处理建立唯一、层次性编号。

>每个处理通常要求既有输入又有输出。

>不要试图让DFD反映处理的顺序。

>底层流图是指其加工不需再做分解的数据流图,它处在最底层。

>中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化,形成子图。

数据流细化实例

教务处

“成绩管理系统”的顶层数据流图

有效成绩

11.成绩录入

成绩数据表

原|修改E赢'

成2.成4修改]

原始成绩

j修改前数据

教务处1tz

任课教师

“成绩管理系统的"。层数据流图

对“成绩修改”处理框细化后的1层数据流图

3、数据流图中符号的命名

数据接口:名词或名词短语。如教务处。

数据存储:名词或名词短语。如班级表、成绩数据表。

数据流:名词或名词短语。流入数据存储和从数据存储流出的数据流,在不发生名词混淆

的前提下可以省略。

数据处理:涉及处理方式和处理对象,一般采用动词+名词短语进行命名.

4、检查和修改数据流图的原则

>数据流图上所有图形符号只限于前述四种基本图形元素。

>顶层数据流图必须包括前述四种基本元素,缺一不可。

>顶层数据流图上的数据流必须封闭在外部实体之间。

>每个处理框至少有一个输入数据流和一个输出数据流。

>在数据流图中,需按层给处理框编号。表明该处理所处层次及上下层的亲子关系。

>规定任何一个数据流子图必须与它上一层的一个处理对应,两者的输

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论