第1讲 软件工程与软件规范.docx
- 文档编号:30019738
- 上传时间:2023-08-04
- 格式:DOCX
- 页数:29
- 大小:202.85KB
第1讲 软件工程与软件规范.docx
《第1讲 软件工程与软件规范.docx》由会员分享,可在线阅读,更多相关《第1讲 软件工程与软件规范.docx(29页珍藏版)》请在冰豆网上搜索。
第1讲软件工程与软件规范
第一讲软件与软件工程
大连海事大学计算机学院信息系统研究所蒋波
自从1968年首次提出“软件工程”一词以来,软件工程已经成为计算机软件的一个重要分支和研究方向。
软件工程是指应用计算科学,数学及管理科学等原理以及工程化的原则和方法来解决软件问题的工程。
其目的是:
提高软件生产率,提高软件质量,降低软件成本。
大家对软件工程的知识已经有了很好的掌握。
下面我们首先就软件工程与软件规范的一些概念做一些说明,然后就需求定义与需求分析的一般原理进行讲解并对系统分析的一般方法进行综述(以MIS开发为背景)。
一、软件的特点及其分类
1.什么是软件或软件定义
软件是程序、数据以及相关文档的完整集合。
Boehm认为软件=程序+文档。
进一步,对于一个计算机而言,有:
硬件系统
计算机系统程序:
按事先设计的功能和性能要求执行的指令序列
软件系统数据:
程序能够正常操纵信息的数据结构
文档:
与程序开发、维护、使用有关的图文资料
为了能全面、正确地理解计算机和软件,必要了解软件的特点。
2、软件的特点
①.软件是一种逻辑实体,它具有抽象性。
我们无法看见软件本身的形态,而只有通过观察、分析、思考、判断等去了解它的功能性能以及特性。
②.软件的开发过程没有明显的制作过程。
软件是通过他们的智力活动,把知识与技术转化为信息的一种产品,软件产品研制成立后可以复制使用,但不可以像硬件产品那样可以重复制造。
③.软件在使用期内没有磨损、老化问题。
对硬件设备而言,刚投入使用时,由于与其它各部件之间有一个磨合期,所以可能会经常出问题。
但经过一个阶段的运行后,就会进入一个稳定工作的时期,再经过相当一段时间的运转后,就会出现磨损,老化的问题,其失效率变的越来越大,当失效率达到一定程度时其生命也就终止了。
对软件产品而言,它虽然也有一个“磨合”期,但不存在老化、磨损问题。
不过,软件也有一个退化的问题。
在软件的生存周期中,为了克服迄今为止尚未发现的故障,或者为了让他能够适应硬件环境、软件环境的变化以及用户新的要求,必须多次修改(维护)软件,而每次修改又不可避免的会引入新的错误。
这样一次次的修改,就使得软件的失效率逐渐升高,从而使软件退化,软件也有终止其生命的一天。
④.软件的开发与运行常常受计算机系统的限制,对计算机系统有着不同程度的依赖性。
作为软件质量的因素之一的可移植性,就要求相应软件应该对开发环境具有较少或完全没有依赖性。
当然,绝对不依赖硬件环境的软件是不存在的,这就要求设计者加以斟酌。
⑤.软件的开发至今尚未完全摆脱手工艺的开发方式,虽然近年来软件复用技术、自动生成技术开发工具等有了新的进展。
但是所占的比率仍然很少。
因此,研究工具软件就成为软件研究中非常热门的话题。
比如,我们可以通过对管理信息系统(MIS)的一般模式的分析,抽象出MIS的一般应用模式,然后利用组件的概念开发各个模式并利用这些开发出的组件“组装”用户所需要的应用系统。
组件技术就是这种概念的推广。
⑥.软件本身是复杂的,而且随着应用规模的扩大,软件变得越来越复杂。
有人认为,软件是人类能够制造的最复杂的产物。
⑦.软件的成本相当昂贵。
软件的技术落后于应用需求,软件成本占计算机系统的总成本的比率逐渐在变大。
⑧.相当多的软件工作涉及到社会因素。
由于对软件的认识不同,导致软件在开发过程中得不到应有的重视,也是导致软件开发失败的关键因素之一。
从以上分析可以看出,出现软件危机是必然的,而且,到目前为止这种危机并没有被排除。
3、软件的分类
①.按功能可分为:
系统软件,支撑软件,应用软件
②.按软件规模可分为:
微型软件,小型软件,中型软件,大型软件,甚大型软件,极大型软件
③.按软件工作方式分:
a.实时处理软件:
监控软件等;
b.分时处理软件:
多个用户联机使用计算机;
c.交互式软件:
实现人机交互;
d.批处理软件:
把一组作业以成批方式一次运行,按顺序逐个处理。
④.按软件服务对象的范围划分项目软件(定制软件),产品软件(商品软件)
除此以外,还要按使用频度划分,按软件失效的影响进行划分等方法。
4、软件危机
①.由于缺乏软件开发的经验和有关软件数据的积累,使得开发工作的计划很难制定,在进度、费用上估计不准确,引起用户不满。
②.软件需求很难确定或不确定,这一点是非常关键,尤其在国内开发软件更为突出。
③.开发过程没有统一的、公认的方法论和规范指导,缺乏规范文档,使软件很难维护。
④.测试工作不充分,导致软件错误很多,使软件可靠性降低。
有很多的软件测试方法已经被广泛采纳,如黑盒测试、白盒测试、逻辑覆盖、等价类划分、边界值划分、错误猜测、Alpha测试、Beta测试等技术等,在软件测试一讲中将做详细说明,在这里不一一叙述。
下面举两个例子说明软件测试的重要性。
例1:
1963年美国的火箭控制系统程序
把FORTRAN语句DO5I=1,3写成了DO5I=1.3
结果使得发往火星的火箭爆炸,造成1000多万美元的损失。
例2:
1966年开发的IBM360机的操作系统,花费了5000人年的工作量,写出了近100万行源程序,但是却得到一个很不成功的软件。
每更新一次版本,都能找到1000多个错误,成为用之不灵、弃之可惜的软件系统。
由于上述种种原因,产生了软件危机。
解决软件危机的方法之一是:
按工程化的原则和方法组织软件开发工作,并且要制定相应的标准。
二、软件工程过程与软件生存期
1.软件工程过程:
为获得软件产品,在软件工具支持下,由软件工程师完成的一系列软件工程活动,称为软件工程过程。
每一个软件开发结构都可以规定自己的软件工程过程。
针对不同类型的软件产品,同一软件开发机构也可使用多个不同的软件工程过程。
软件工程过程通常包含4种基本的过程活动。
P(plan):
软件规格说明,规定软件的功能及其运行限制
D(do):
软件开发,产生满足规格说明的软件
C(check):
软件确认,确认软件能够完成客户提出的要求
A(action):
软件演进,为满足客户的变更要求,软件必须在使用的过程中演进。
事实上,软件工程过程是一个软件开发机构针对某类软件产品为自己规定的工作步骤。
2.软件生存期(软件生命周期)
制定计划、需求分析、基本设计与详细设计、编码、测试、维护等阶段。
软件生存期概念的出现曾经帮助我们较为全面的认识软件开发、软件运行与维护的全过程。
这主要表现在1988年制定和公布的国家标准《GB8566-88计算机软件开发规范》中,该标准曾将软件生存期划分为8个阶段,即:
可行性研究和计划、需求分析、概要设计、详细设计、实现、组装测试、确认测试、使用和维护。
该标准为每个阶段规定了任务、实施步骤。
该标准反映了80年代人们对于软件工程的认识。
90年代初期,提出了软件工程过程的概念,认为软件工程过程是为了获得软件产品或是为了完成软件工程项目需要完成的有关工程活动,每一项活动又可以分解为一些软件工程任务,每一个软件开发机构都可以规定自己的软件工程过程。
针对不同类型的软件产品或是软件工程项目,软件机构可以规定自己适合的软件工程过程,甚至可能使用多个不同的软件工程过程。
软件生存期中除了开发过程以外,还有许多其他的软件工程过程。
这一思想主要集中体现在1995年制定和公布的国家标准《GB/T8565-1995信息技术软件生存期过程》中,事实上,它是《GB8566-88计算机软件开发规范》的代替标准。
该标准定义了软件生存期7个主要过程,分别是管理过程,获取过程,供应过程,开发过程,操作过程,维护过程和支持过程。
1995年国家标准化组织公布了新的国际标准,即《ISO/IEC12207信息技术---软件生存期过程》,该标准全面、系统的阐述了软件生存期的过程、活动和任务。
关于该标准的结构图,请大家查阅有关标准文件。
3.软件工程的目标
软件工程包括三个基本要素,即方法、工具和过程。
方法主要研究如何做的问题;工具则是为了软件开发提供一个支撑环境;过程则是将软件工程的方法和工具结合起来以达到合理、及时地进行计算机软件开发地目的。
这些目标是:
低开发成本;高可靠性;高性能;按时交付;易于维护等。
这些目标之间是具有一定的联系的,可用下图来描述这种联系:
其中,有些目标是互补的,而又有一些目标又是相互冲突的。
三﹑软件质量保证
软件质量是贯穿软件生存期的一个极为重要的问题,是软件开发过程中所使用的各种开发技术和验证方法的最终体现。
因此,在软件生存期中,要特别重视质量的保证,以生成高质量的软件产品。
1.软件质量的定义
有各种各样的软件质量定义。
下面说明两个定义:
ANSI/IEEEstd729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”;
M.J.Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。
软件质量反映了以下三个方面的问题:
①软件需求是度量软件质量的基础。
不符合需求的软件就没有质量;
②在各种标准中定义了一些开发准则,用来指导软件人员用工程化的方法来开发软件。
如果不遵守这些开发准则,软件质量就得不到保证;
③往往会有一些隐含的需求没有明确地提出来。
如果软件只满足那些精确定义了的需求而没有满足这些隐含需求,软件质量也不能保证。
软件质量是各种特性的复杂组合。
它随着应用的不同而不同,随着用户提出的质量要求不同而不同。
2.典型的软件质量的模型
①McCall质量模型
1979年McCall等人提出的软件质量模型,其软件质量概念基于11个特性之上,而这11个特性分别面向软件产品的运行、修正、转移。
它们与特性的关系如下图所示。
进一步,McCall等给出了一个三层次式模型的框架。
如下图所示。
McCall等人认为,特性是软件质量的反映,软件属性可用做评价准则,定量化地度量软件属性可知软件质量的优劣。
下表给出了McCall等人定义的软件质量特性与评价准则之间的关系。
表1.1McCall定义的软件质量模型
软件质
软件量因
质量的素
评价准则
正确性
可靠性
效率
完整性
可使用性
可维护性
灵活性
可测试性
可移植性
复用性
互联性
可跟踪性
○
完备性
○
一致性
○
○
○
○
安全性
○
○
容错性
○
准确性
○
简单性
○
○
○
○
执行效率
○
存储效率
○
存取控制
○
存取审查
○
操作性
○
易训练性
○
简明性
○
○
○
○
模块独立性
○
○
○
○
○
○
自描述性
○
○
○
○
结构性
○
文档完备性
○
通用性
○
○
○
○
可扩充性
○
○
可修改性
○
○
○
自检性
○
○
○
机器独立性
○
○
软件系统独立性
○
○
通信共享性
○
数据共享性
○
I/O容量
○
I/O速率
○
通用性
○
McCall等人的质量特性定义如下:
正确性:
在预定环境下,软件满足设计规格说明及用户预期目标的程度。
它要求软件没有错误。
可靠性:
软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度。
效率:
为了完成预定功能,软件系统所需的计算机资源的多少。
完整性:
为了某目的而保护数据,避免它受到偶然的,或有意的破坏、改动或遗失的能力。
可使用性:
对一个软件系统,用户学习、使用软件及为程序准备输入和解释输出所需工作量的大小。
可维护性:
为满足用户新的需求,或当环境发生了变化,或运行中发现了新的错误时,对一个已经投入运行的软件进行相应诊断和修改所需工作量的大小。
可测试性:
测试软件以确保其能够执行预定功能所需工作量的大小。
灵活性:
修改或改进一个已经投入运行的软件所需工作量的大小。
可移植性:
将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需工作量的大小
复用性:
一个软件(或软件的部件)能够再次用于其它应用(该应用的功能与此软件或软件部件的所完成的功能有联系)的程度。
互联性:
连接一个软件和其它系统所需工作量的大小。
如果这个软件需要联网,或与其它系统通信,或要把其它系统纳入到自己的控制之下,必须有系统间的接口,使之可以连接。
互联性有时也称相互操作性。
通常,通过以上各个质量特性直接对软件进行度量是很困难的。
因此,McCall又定义了一些评价标准,使用它们对反映质量特性的软件属性进行分级,以此来估计软件质量特性的值。
上表给出了它们之间的关系(左边的列为各个评价标准)。
具体含义这里从略。
②ISO的软件质量评价模型
按照ISO/TC97/SC7/WG3/1985-1-30/N382,软件质量度量模型由三层组成,分别是:
高层(TopLevel):
软件质量需求评价标准(SQRC);
中层(MidLevel):
软件质量设计评价标准(SQDC);
低层(LowLevel):
软件质量度量评价标准(SQMC);
其模型结构如下图所示。
③上海软件中心(SSC)的软件质量度量模型
在SSC模型中,采用了与ISO/IEC9126相同的6个质量特性,它们分别是:
功能性(正确性)、可靠性、易使用性、效率、可维护性和可移植性。
同时参照McCall模型定义设置了22个质量子特性。
各个质量子特性及其与质量特性之间的关系如下表所示。
表1.2各质量特性与质量子特性之间的关系
功能性
可靠性
易使用性
效率
可维护性
可移植性
精确性
○
健壮性
○
安全性
○
通信有效性
○
执行有效性
○
设备有效性
○
操作性
○
培训性
○
完备性
○
一致性
○
○
○
可追踪性
○
可见性
○
硬件系统无关性
○
软件系统无关性
○
可扩充性
○
产品文档完备性
○
○
公用性
○
清晰性
○
○
模块性
○
○
自描述性
○
○
简单性
○
○
结构性
○
3.软件质量的保证
为了在软件开发过程中保证软件的质量,主要采取以下措施:
①审查在软件生命周期的各个阶段结束前,都使用结束标准对该阶段所产生的软件配置成分进行严格的技术审查
②复查与管理复审
复查:
检查已有的材料以决定特定阶段的工作是否能够开始或继续。
管理复审:
向开发组织或使用部门的管理人员提供有关项目的总体状况、成本和进度等方面的情况,以便他们从使用角度对开发工作进行审查。
③测试用已知的输入在已知的环境中动态地执行系统或系统的部件。
测试过程中产生下列基本文档:
(1)测试计划(通常包括单元测试和集成测试):
确定测试范围、方法和需要的资源等。
(2)测试过程:
详细描述和每个测试方案有关的测试步骤和数据(包括测试数据和预期的结果)。
(3)测试结果:
把每次测试运行的结果归入文档。
如果运行出错,则应该产生问题报告,并且必须通过调试解决所发现的问题。
具体的测试方法与测试数据的作成等,在下面的介绍中将有详细的说明。
四、软件文档
1.软件文档的作用与分类
①什么是文档
文档(Document)是指某种数据媒体和其中所记录的数据。
在软件工程中,文档常常用来表示对活动、需求、过程、或结果进行描述、定义、规定、报告、或认证的任何书面或图示的信息。
它们描述和规定了软件设计和实现的细节,说明使用软件的操作命令。
文档也是软件产品的一部分,没有文档的程序不能称之为软件。
软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量。
实际工作中,忽视软件文档的编制的现象非常普遍。
有两种因素导致了这种现象的发生及其延续。
·软件开发人员认为软件文档的编制是浪费时间,他们更多的是愿意将精力花费在如何调通一个程序;
·用户抱怨软件文档代价太大,软件文档有时与系统功能等不相符合,难于使用;
无论是那种现象,都影响到软件文档的编制。
②软件文档的作用
在软件的生产过程中,总伴随着大量的信息要记录、要使用。
记录这些信息对软件开发过程有着重要的作用。
·提高软件开发过程的能见度。
开发人员利用文档可以进行各种交流;管理人员利用文档可以检查软件开发进度和开发质量,实现对软件开发的工程管理;
·提高开发效率。
软件文档的编制,使得开发人员对各个阶段的工作都进行周密思考、全盘衡量,从而减少返工。
并且,可以在早期发现错误和不一致性以便及时加以纠正。
(错误发现得越早、纠正错误得代价就越小);
软件开发过程出现的错误具有积累和放大效应。
·作为开发人员在一定阶段的工作成果和结束标志;
·记录开发过程中的有关信息,便于协调以后的软件开发、使用和维护;
·提供对软件的运行、维护和培训的有关信息,便于管理人员、开发人员、操作人员、用户之间的协作、交流和了解,使软件开发活动更加科学、更有成效;
·便于用户了解软件的功能、性能等各项指标,为用户选择软件提供依据。
软件文档在各类人员之间的多种桥梁作用可用
下图描述。
③软件文档的分类
对软件文档的分类存在着几种分类方法,若按文档产生和使用的范围可将文档分为3类:
·开发文档
软件开发过程中作为前一阶段工作成果的体现和后一阶段工作的依据而作成的图文资料。
主要包括:
Ⅰ软件需求说明书
Ⅱ数据要求说明书
Ⅲ概要设计说明书
Ⅳ详细设计说明书
Ⅴ可行性研究报告
Ⅵ项目开发计划
·管理文档
软件开发过程中由开发人员制定并提交给管理人员的一些工作计划和工作报告。
管理人员能够通过这些文档了解软件开发项目安排、进度、资源利用和成果等。
主要包括:
Ⅰ项目开发计划
Ⅱ测试计划
Ⅲ测试报告
Ⅳ开发进度月报表
Ⅴ项目开发总结
·用户文档
开发人员为用户准备的有关该软件的使用、操作、维护的资料。
主要包括:
Ⅰ用户手册
Ⅱ操作手册
Ⅲ维护修改建议
Ⅳ软件需求说明书
2.软件文档规范
国家标准局在1988年1月发布了《计算机软件开发规范》和《软件产品开发文件编制指南》,作为软件开发人员工作的准则和规程。
该规程基于软件生存周期方法,把软件产品从形成概念开始,经过开发、使用和不断增补修订,直到最后被淘汰的整个过程应提交的文档归纳为以下13种。
下面逐一予以说明:
(1)可行性研究报告:
说明该软件项目的实现在技术上、经济上、使用上和法律上的可行性,对为合理地达到开发目标可供选择的各种可能的实现方案加以评述,说明并论证所选定实施方案的理由。
(2)项目开发计划:
为软件项目实施方案制定出的具体计划。
它应该包括各部分工作的负责人员、开发的进度、开发经费的概算、所需的硬件和软件资源等。
项目开发计划应提供给管理部门,并作为开发阶段评审的基础。
(3)软件需求说明书:
软件需求说明书也称软件规格说明书。
其中对所开发软件的功能、性能、用户界面、机器运行环境等作出详细说明。
它是用户与开发人员双方对软件需求取得共同理解的基础上达成的协议,也是实际开发工作的基础。
(4)数据要求说明书:
该说明书应当给出数据逻辑描述和数据采集的各项要求,为生成和维护软件系统的数据文件作好准备。
(5)概要设计说明书:
该说明书是概要设计阶段的成果。
它应该说明系统的功能分配、模块划分、程序的总体结构、输入输出及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计奠定基础。
(6)详细设计说明书:
该说明书着重描述每一个模块是如何实现的,包括实现算法、程序流程等。
(7)用户手册:
详细描述软件的功能、性能和用户界面,使用户了解如何使用该软件。
(8)操作手册:
为操作人员提供该软件各种运行情况的有关知识,特别是操作方法细节的描述。
(9)测试计划:
针对组装测试和确认测试,需要为组织测试制定计划。
计划应该包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
(10)测试分析报告:
测试工作完成以后,应当提交测试计划执行情况的说明。
对测试结果加以分析,并提出测试的结论性意见。
(11)开发进度月报:
该月报是软件人员按月度向管理部门提交的项目进展情况的报告。
报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决问题的办法以及下个月的打算等。
(12)项目开发总结报告:
软件项目开发完成以后,应当与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力。
此外。
还需对开发工作做出评价,总结经验和教训。
(13)维护修改建议:
软件产品投入运行后,可能有修改、更正等问题,应当对存在的问题、修改的考虑以及修改影响的估计等作详细的描述,写成维护修改建议,提交审批。
上述13个文档最终要向软件管理部门或向用户回答下列问题:
·要满足那些要求,即回答“做什么?
(What)”;
·所开发的软件在什么环境中实现,所需信息从哪里来,即回答“从何处?
(Where)”;
·开发工作的时间如何安排,即回答“何时做?
(When)”;
·开发(或维护)工作打算“由谁来做?
(Who)”;
·需求应如何实现,即回答“怎样做?
(How)”;
·为什么要进行这些软件开发或维护修改工作?
(Why);
具体地说,哪个文档要回答什么样的问题,哪些人又参与哪些文档的编制等可以用下面的表加以归纳。
软件文档一览表
可行性研究与开发计划
需求
分析
软件
设计
编码与
单元测试
集成测试
运行维护
什
么
何
处
何
时
谁
如
何
为
何
管理
人员
开发
人员
维护
人员
用
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第1讲 软件工程与软件规范 软件工程 软件 规范