发布时间:2023-10-03 08:00
1.名词解析 10题
2.简答 5题
3.综合 2题
重点看标记的,了解出小题,理解出小题或者大题,掌握出大题。
结合课本:
写出其中一种。
软件工程是建立和使用一套合理的工程原则,以便获得经济的软件,这种软件是可靠的,可以在实际的机器上高效的运行。
软件工程是:
软件工程是应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度实现满足用户要求的软件产品的工程,或以此为研究对象的学科。
所谓基于计算机的系统是指:通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素组要有:软件、硬件、人员、数据库、文档和规程。
计算机系统工程是一个问题求解的活动,其目的是分析基于计算机的系统的功能,性能等要求,并把它们分配到基于计算机系统的各个系统元素中,确定他们的约束条件和接口。
系统工程主要包括以下任务。
系统工程的第一部就是识别用户对基于计算机的系统的总体要求,标识系统的功能和性能范围,确定系统的功能,性能、约束和接口。
一个基于计算机的系统通常可以考虑一下模型。
开发一个基于计算机的系统需要一定的资金投入和时间约束(交付日期),因此在系统工程阶段应对需开发的基于计算机的系统进行成本估算,并作出进度安排。
可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行,通常只有当解决方案可行并且有一定的经济效益和/或社会效益时,才真正开始基于计算机系统的开发。
在以上各任务完成以后,应该形成一份系统规格说明,作为以后开发基于计算机的系统的依据。系统规格说明描述基于计算机的系统的功能、性能和约束条件,描述系统的输入输出和控制信息,给出各系统元素的模型,进行可行性分析,最后给出成本估算和劲速安排计划。
开发一个基于计算机的系统通常都受到资源(如人力,财力、设备等)和时间上的限制,可行性分析主要从经济、技术。法律等方面分析所给出的解决方案是否可行,能否在规定的资源和时间的约束下完成。
需求工程定义为:“直到(但不包括)把软件分解为实际架构和构建之前的所有活动”。需求工程时一个不断反复的需求定义、文档记录、需求演进的过程,并最终在验证的基础上冻结需求。
20世纪80年代,Herb Krasner定义了需求工程的5个阶段:需求定义和分析、需求决策、形成需求规约。需求实现与验证。需求演进管理。进来,Matthias Jarke和Klaus Pohl提出了3阶段周期的说法:获取、表示和见证。Roger S。pressman将需求工程过程描述为六个清晰的步骤:需求诱导,需求分析和谈判,需求规约,系统建模、需求确认以及需求管理。Lan Sommerviller等将需求工程分为需求抽取,需求分析和需求协商、系统建模、需求确认以及需求管理。
本书将软件需求工程细分为:需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理6个阶段。
在与用户交流的过程中,可能会存在误解、交流障碍、缺乏共同语言等问题,这些交流上的问题会导致得到的用户需求不稳定、缺乏完整性,甚至是错误的需求,因此在获取需求前首先要建立需求获取人员(通常被称为系统分析员)与用户的顺畅的通信途径,与用户交谈,向用户提问题,通过访谈与会议、参观用户的工作流程、观察用户操作、建立联合小组和实例分析来获取需求。
建立顺畅的通信途径
访谈与调查
观察用户操作流程
为了能够有效地获取和挖掘用户需求,打破用户(需方)和开发者(供方)的界限,共同组成一个联合小组,发挥各自的长处,共同负责项目的推进,这样有助于发挥各自优势,这种方法被称为便利的应用规约技术(FAST)。
FAST鼓励建立用户和开发者团队之间的合作,他们共同工作来表示问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案。他已经成为信息系统使用的主流技术,该技术为改善各种应用中的相互通信提供了潜在可能。FAST团队来自市场、软件和硬件工程以及制造方的代表组成,并选择外来人员作为协调者。该方法有以下基本原则:
以产品开发为例,FAST会议大体上有以下几个步骤:
FAST会议并不能解决在早期需求获取阶段遇到的所有问题,但是该方法提供了便利的条件,集中不同的观点、即时地讨论和求精以及具体地规约开发步骤,对于进行正确的需求获取是十分有益的。
5.用况
用况(use case)常称为用例,当需求作为非正式会议-FAST的一部分而收集起来之后,分析员就可以创建一组标识一串待建造系统的使用场景。这些场景被称为用况的实例,用况提供了系统将会被如何使用的描述。
创建用况模型的主要步骤如下:
①确定谁会直接使用该系统,即执行者(actor)。
②选取其中一个执行者。
③定义该执行者希望系统做什么,执行者希望系统所做的每件事将成为一个用况。
④对每件事来说,何时执行者会使用系统,通常会发生什么,这就是用况的基本过程。
⑤描述该用况的基本过程。执行者和用户并不是一回事儿。
一个典型的用户可能在使用系统时扮演了一系列不同的角色,而一个执行者表示了一类外部实体,它们仅扮演一种角色。
软件设计是把软件需求变换成软件表示的过程,早期的软件设计分为概要设计和详细设计,现在的软件设计分为数据/类设计、软件体系结构设计、接口设计和部件级设计。概要设计将需求转换为数据结构、软件体系结构及其接口。详细设计或部件级设计将软件体系结构中的结构性元素转换为软件部件的过程描述,得到软件详细的数据结构和算法。
软件设计的输入是分析模型,使用一种设计方法,软件分析模型中通过数据、功能和行为模型所展示软件需求信息被传送给设计阶段、产生数据/类设计,体系结构设计,接口设计,部件级设计。
体系结构设计
体系结构设计体系结构设计定义了软件的整体结构,由软件部件、外部可见的属性和它们之间的关系组成。体系结构设计表示可以从系统规约、分析模型和分析模型中定义的子系统交互导出。关于软件体系结构设计的概念和风格将在4.3节中介绍。
接口设计
接口设计接口设计描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。体系结构设计为软件工程师提供了程序结构的全局视图,但是就像房子的蓝图一样,如果不画出门、窗、水管、电线和电话线,整个设计将是不完整的。
接口设计主要包括3方面内容:设计软件模块间的接口、设计模块与其他非人的信息生产者和消费者(如外部实体)之间的外部接口以及设计人(用户)与计算机间的人机接口。·模块间的接口设计是由模块间传递的数据和程序设计语言的特性共同导致的。一般来说,分析模型中包含了足够的信息用于模块间的接口设计。
外部接口设计起始于对分析模型的每个外部实体的评估。外部实体的数据和控制需求确定下来以后,就可以设计外部接口了。内部和外部接口设计必须与模块内的数据验证和错误处理算法紧密相关,由于副作用往往是通过程序接口进行传播的,所以必须对从某模块流向另一个模块(或流向外部世界)的数据进行检查,以保证符合需求分析时的要求。关于人机界面设计,将在第11章详细介绍。
部件级设计
部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述。从类为基础的模型、流模型、行为模型等模型中得到的信息是部件设计的基础。详细信息和工具在4.4节中介绍。
2.软件设计的目标
在软件设计的过程中,要密切关注软件的质量因素。设计是在软件开发中形成质量的阶段,设计提供了可以用于质量评估的软件表示,是将用户需求准确地转化为完整的软件产品或系统的主要途径,。
MeGlanghin给出了在将需求转换为设计时,判断设计好坏的3条特征,也就是软件设计过程的目标;
为了达到上述目标,必须建立衡量设计的技术标准,它们包括以下内容
3.软件设计的过程
软件设计是一个把软件需求变换成软件表示的过程,通常的软件设计过程分为如下6个步骤:
通常在建立软件设计过程时,首先应为软件开发组制订在设计时应该共同遵守的标准,以便协调组内各成员的工作。包括阅读和理解软件需求说明书,确认用户要求能否实现;明确实现的条件,从而确定设计的目标,以及它们的优先顺序;根据目标确定最合适的设计方法;规定设计文档的编制标准;规定编码的信息形式,与硬件及操作系统的接口规约,以及會名规则。然后进入到体系结构和接口设计、数据/类设计及部件级(过程)设计。这个过程是一个迭代的过程。最初的设计只是描绘出可直接反映功能、数据、行为需求的软件整体幅架,接着设计的迭代过程开始,在框架中逐步填人细节,将其加工成在实现细节上非常接近于源程序的软件表示。在设计结束后,要编写设计文档、制订用户手册和初步的测试计划并组织进行设计评审。
20世纪60年代末到20世纪70年代初, Yourdon等人在“结构化设计”的研究中提出一种表示数据及对数据进行加工变换的图形符号,从而形成了结构化分析方法的雏形。1979年De Marco在他的著作《结构化分析和系统规约》中引入并命名了创建信息流模型的图形符号,提出了使用这些符号的模型。以后,一些学者又陆续提出了结构化方法的一些变种。到20世纪80年代中期, Ward和Mellor以及Hatley和Pirbhai对结构化方法进行了扩展,以适应于实时系统的分析。
“抽象”和“分解”是处理任何复杂问题的两个基本手段。
结构化方法就是采用这种自顶向下逐层分解的思想进行分析建模的,自顶向下逐层分解充分体现了分解和抽象的原则。随着分解层次的增加,抽象的级别也越来越低,即越来越接近问题的解。在图5.1中,自顶向下的过程是分解的过程,自底向上的过程是抽象的过程。
结构化分析的过程可以分为如下4个步骤
结构化分析方法导出的分析模型采用图5.2所示的描述形式。
图5.2中,数据字典是模型的核心,包括对软件使用和产生的所有数据的描述。围绕数据字典有3重图以及相应的规范或描述。
数据流图用于软件系统的功能建模,描述系统的输入数据流如何经过一系列的加工,逐步变换成系统的输出数据流,这些对数据流的加工实际上反映了系统的某种功能或子功能。数据流图中的数据流、文件、数据项、加工都应在数据字典中描述。加工规约是对数据流图中的加工的说明,在结构化方法中用加工的“小说明”作为加工规约。
实体-关系图(E-R图)用于数据建模,描述数据字典中数据之间的关系。数据对象的属性用:”数据对象描述“来描述。通常存放在数据字典中。
状态转换图用于行为建模,描述系统接收哪些外部事件,以及在外部事件的作用下系统的状态迁移(即从一个状态迁移到另一个状态)。
控制规约用来描述控制方面的附加信息。
结构化分析的分析结果包括:一套分层的数据流图、一本数据字典(包括E-R图)、一组加工规约以及其他补充材料(如非功能性需求等)。
数据字典和数据流图结合起来构成软件的逻辑模型(分析模型)
DFD中的每个元素(数据流、文件、加工、源或宿等)都对应于一个数据字典条目的描述,不同种类的条目有不同的描述内容。对于同一种类的条目,不同的开发组织或团队也可以根据项目的需要定义不同的描述内容。字典条目中的描述内容主要包括: DFD元素的基本信息(名称、别名、简述、注解)、定义(数据类型、数据组成)、使用特点(取值范围、使用频率、激发条件)、控制信息(来源、去向、访问权限)等。
数据流条目的描述内容如下。
其中:
文件条目的描述内容如下。
其中,文件组成的描述与数据流条目相同。
数据项条目的描述内容如下。
其中,“与其他数据项的关系”可用于对数据的校验。
加工条目的描述内容如下。
其中,加工逻辑是加工描述的核心。加工分为基本加工(无DFD子图的加工)和非基加工(有DFD子图的加工),基本加工的加工逻辑用小说明描述(见5.5节),在加工条目中可填写对加工规约的索引。非基本加工分解而成的DFD子图已反映了它的加工逻辑,不书写小说明,可在加工条目中对加工逻辑作简要介绍。
由于源或宿表示系统外的人员或组织,当采用人员或组织的名称作为源或宿的名字时源和宿的含义已经比较清楚了,因此,开发人员常常不将源或宿据字典中、考到字典的完整性,以及便于对DFD和数据字典进行检查,在数据字典中,仍可保留源或宿目,其描述内容如下。
名称:源或宿的名称(外部实体名).
别名:同数据流条目。
简要描述:对源或宿的简要描述(包括指明该外部实体在DFD)中是用作“源”,还是“宿”,还是“既是源又是宿").
输入数据流:描述源向系统提供哪些输人数据流。
输出数据流:描述系统向宿提供哪些输出数据流。注解:对源或宿的其他补充说明。
并非所有的别名都要有别名条目,只有那些有必要补充说明的别名才给出相应的别名条目。
使用下列等式识别面向对象方法:
面向对象(Object oriented) = 对象(Object) + 分类 (classification)+继承(inheritance)+通过消息的通信(communication with massage)
可以说,采用这4个概念开发的软件系统是面向对象的。
在现实世界中,每个实体都是对象,如大学生、汽车、电视机、空调等,都是现实世界中的对象每个对象都有它的属性和操作,如电视机有颜色、音量、亮度、辉度、频道等属性,可以有切换频道、增大/减低音量等操作。电视机的属性值表示了电视机所处的状态,而这些属性值只能通过其提供的操作来改变。电视机的各组成部分,如显像管、印制板、开关等都封装在电视机机箱中,人们不知道也不关心电视机是如何实现这些操作的。
**在计算机系统中,对象是指一组属性以及这组属性上的专用操作的封装体。属性通常是一些数据,有时也可以是另一个对象。**例如,走一对泵,它的属性可以有书名、作者、出版社、出版年份、定价等属性,其中书名、出版年份、定价是数据,作者和出版社可以是对象,它们还可以有自己(在有些简单的软件系统中可能只用到作者名和出版社名,而下关心作者和出版社的其他信息,那么,它们也可以是数据),每个对象都有自己的属性值,表示该对象的状态。**对象中的属性只能通过该对象所提供的操作来存取或修改。**操作也称为方法或服务,操作规定了对象的行为,表示对象所能提供的服务。封装是一种信息隐蔽术,用户只能看见对象封装界面上的信息,对象的内部实现对用户是隐蔽的。封装的目的是使对象的使用者和生产者分高,使对象的定义和实现分开。一个对象通常可由对象名、属作和操作3部分组成。
**类(class)是一组具有相同属性和相同操作的对象的集合。**一个类中的每个对象都是这个类的一个实例(instance),例如,“轿车”是一个类,“轿车”类的实例“张三的轿车”.“条四的轿车”都是对象。也就是说,对象是客观世界中的实体,而类是同一类实体的抽象描述在分析和设计时,人们通常把注意力集中在类上,而不是具体的对象上。人们也不必为每个对象逐个定义,只需对类作出定义,而对类的属性的不同赋值即可得到该类的对象实例,图7.1所示。类和对象之间的关系类似于程序设计语言中的类型(type)和变量(variable)之间的关系。通常把一个类和这个类的所有对象称为类及对象,或称为对象类。
一个类可以定义为另一个更一般的类的特殊情况,如“轿车”类是“汽车”类的特殊情况称一般类是特殊类的父类或超类(superclass),特殊类是一般类的子类(subeclass)。例如“汽车”类是“轿车”类的父类,“轿车”类是“汽车”类的子类。同样,“汽车”类还可以是“交工具”类的子类,“交通工具”类是“汽车”类的父类。这样可以形成类的一种一般特殊的5次关系,如图7.2所示。
在这种一般特殊的关系中,子类可以继承其父类(或祖先类)的所有属性和操作,同子类中还可以定义自己特有的属性和操作。所以,子类的属性和操作是子类中的定义部分和其祖先类中的定义部分的总和。
继承是类间的一种基本关系,是基于层次关系的不同类共享属性和操作的一种机制父类中定义了其所有子类的公共属性和操作,在子类中除了定义自己特有的属性和操作外还可以对父类(或祖先类)中的操作重新定义其实现方法,称为重例如,矩看是多边形的子类,在多边形类中定义了属性;顶点坐标序列,x移、旋转.1示、计算面积等。在矩形类中,可定义它自己的属性长和宽,还可以对操作“计算面积"重新定义。
有时,人们定义一个类,这个类把另一些类组织起来,提供一些公共的行为,但并不需要使用这个类的实例,而仅使用其子类的实例。这种不能建立实例的类称为抽象类(abstract class),例如,图7.2中的交通工具就是一个抽象类。通常一个抽象类只定义这个类的抽象·操作,抽象操作是指只定义操作接口,其实现部分由其子类定义。如果一个子类只有唯一一个父类,这个继承称为单一继承。如果一个子类有一个以上的父类,这种继承称为多重继承。如图7.3所示的“水陆两栖交通工具”类既可继承“陆上交通工具”类,又可以继承“水上交通工具”类的特性。
4.消息
**消息(message)传递是对象间通信的手段,一个对象通过向另一个对象发送消息来请求其服务。**一个消息通常包括接收对象名、调用的操作名和适当的参数(如果有必要的话)。消息只告诉接收对象需要完成什么操作,但并不指示接收者怎样完成操作。消息完全由接收者解释,接收者独立决定采用什么方法完成所需的操作。
5,多态性和动态绑定
多态性(polymorphism)是指同一个操作作用于不同的对象上可以有不同的解释,并产·生不同的执行结果。例如,“画”操作,作用在“矩形”对象上则在屏幕上画一个矩形,作用在“圆”对象上则在屏幕上画一个圆。也就是说,相同操作的消息发送给不同的对象时,每个对象将根据自己所属类中定义的这个操作去执行,从而产生不同的结果。
与多态性密切相关的一个概念就是动态绑定(dynamic binding),动态绑定是指在程序运行时才将消息所请求的操作与实现该操作的方法进行连接。传统的程序设计语言的过程调用与目标代码的连接(即调用哪个过程)放在程序运行前(编译时)进行,称为静态绑定,而动态绑定则是把这种连接推迟到运行时才进行。在一般与特殊关系中,子类是父类的一个特例,所以父类对象可以出现的地方也允许其子类对象出现。因此,在运行过程中,当一个对象发送消息请求服务时,要根据接收对象的具体情况将请求的操作与实现的方法进行连接。
用况建模是用于描述一个系统应该做什么的建模技术,用况建模不仅用于新系统的需求获取,还可以用于已有系统的升级。
通过开发者和客户之间为导出需求规约而进行的交互过程来建立用况模型。用况模型主要成分有用况、执行者和系统。系统被视为一个提供用况的黑盒,系统如何做,用况如何实现、内部他们如何工作,这些对用况建模都是不重要的。系统的边界定义了系统所具有的功能。功能用用况来表示,每个用况指明了一个完整的功能。用况的主要目标如下:
人们可以通过更改用况模型,然后跟踪用况所影响到的系统设计和实现,使系统的修改和扩充简单化。
任何一个涉及系统功能活动的人都会用到用况模型。对客户而言,用况模型指明了系统的功能,描述了系统能如何使用。用况建模时客户的积极参与是十分重要的,客户的参与铁模型能反映客户所希望的细节,并用客户的语言和术语来描述用况。对开发者而言,用况模型帮助他们理解系统要做什么,同时为以后的其他模型建模、结构设计、实现等提供依据。集成测试和系统测试人员根据用况来测试系统,以验证系统是否完成了用况指定的功能。
基于构件的软件开发是指使用可复用的构件来开发应用软件的开发方法。通常也称其为基于构件的软件工程(CBSE)。
1.定义
目前对构件一次尚无统一的定义,这里给出几种典型的定义。
在基于构件的软件开发中经常会使用到的商用成品构件,是指由第三方开发的满足一定构建标准并且可以组装的软件构件。
Brown在其著作中指出,构件具有如下5个要素。
(1)规格说明
规格说明建立在接口概念之上,构件应有一个关于它所提供的服务的抽象描述,作为服务提供方与客户方之间的契约。规格说明应包括定义可用的操作,特殊情况下构件的行为约束条件,以及客户与构件的交互等。
(2)一个或多个实现
一个构件在符合规格说明的前提下,可以有一个或多个实现,例如,不同编程语言或不同算法的实现。构件的实现者可以选择任何一种合适的实现方法,但必须确保其实现是满足规格说明的。必要时,还需按某种构件标准进行包装。
(3)受约束的构件标
准由于实现不同构件的程序语言可能不同,运行环境也可能不同,因此,构件必须符合某种标准,才能支持异质构件间的互操作(访问服务),目前常用的构件标准有Microsoft的CM/DCOM,Sun的EJB和OMG的CORBA.
(4)包装方法
构件可以按不同的方式分组(称为包)来提供一套可替换的服务。通常从第三方获取的构件就是这些包,它们代表了系统中的功能单元。使用包时需要某种对包的注册机制。
(5)部署方法
一个成品构件安装在运行环境中,通过创建构件的可执行实例,并允许与它进行交互来实现部署。一个构件可以部署多个实例,而每一个实例都是独立的,并在自己的进程或线程中执行。
构件模型是关于构件本质特征的抽象描述。目前,学术界与产业界已经提出了许多构件模型,本节介绍3C模型和REBOOT模型。
(1) 3C模型
3C模型是在1989年的Reuse in Practice Workshop中由一些系统工程领域的专家提出的,是关于构件的一个指导性模型。
该模型由构件的3个不同方面的描述组成
(2) REBOOT模型
REBOOT(reuse based on object-oriented technology,基于面向对象技术的复用)构作模型是一种基于刻面(facet)的模型。刻面是在对领域进行分析的基础上得到的一组基本的描述特征。刻面可以描述构件实现的功能、所操作的数据、构件应用的周境或任何其他特征。通常刻面描述限制在不超过7或8个刻面。一个构件通常包括以下刻面。①抽象(abstraction):构件概念的抽象性描述。②操作(operation);构件所提供的操作的描述。③操作对象(operand):描述操作的对象。④依赖(dependency) :描述构件与外界的依赖关系。
标准为了将多个构件组装成一个应用系统,支持异质构件间的互操作,软件产业界出现了多种构件标准,其中最常用的构件标准有国际对象管理组织(OMG)的CORBA, MicrosetCOM/DCOM,Sun公司的EJB.
10.1.3敏捷方法综述(了解,这也是定义。重点)
从20世纪90年代开始,逐渐产生了一大批敏捷软件开发方法。其中比较有影响的包括:极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法、自适应软件开发等。
敏捷软件开发方法具有以下一些共同的特征:
敏捷方法提倡软件开发的适应性,这就意味着能够通过软件过程和方法来降低变更带来的代价。Kent beck认为,可以通过诸如增量和迭代、测试驱动开发、重构、简单设计等手段,”抚平“变更成本的曲线。
敏捷软件开发关注客户价值,并且强调快速的支付。通过增量和迭代的开发,敏捷软件开发方法可以在早期就交付最有价值、最重要的功能。而不必等到所有的开发完成。
同时,敏捷软件开发基于价值来衡量工作流的各个环节,尽量消除不必要的文档和环节,从而消除开发过程中的浪费。
敏捷方法不仅仅强调适应性,更强调”人的因素“在成功的软件开发中的重要性。软件开发从本质上是从一种创造性的活动,只有充分激发每个人的能动性,才能更好地实现软件开发的目的。而经典的过程模型忽略人和人的差异,这对于充分发挥个人的价值是不利的。敏捷软件开发方法中重视给予团队相应的授权,信任,帮助建立自组织的团队。
增量和迭代并不是敏捷软件开发的发明。一直以来就存在很多增量和迭代的软件开发模型。但是,敏捷软件开发强调每次迭代都产生真正可以运行的软件,这样更容易获得客户的反馈,便于做出及时的,正确的适应性改变。同时,由于使用增量和迭代的方法,可以在很短的时间间隔内交付软件增量,能够更快的满足客户的需求。
用户希望控制计算机,而不是被计算机控制,因此在设计人机界面的时候要遵循以下原则,
(1)交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式
例如,如果在字处理菜单中选择拼写检查,则软件将转移到拼写检查模式。如果用户希型在这种模式下进行一些文本编辑,则没有理由强迫用户停留在排写检查模式,用户应够几乎不需要做任何动作就进入或退出该模式。
(2)提供灵活的交互
如允许用户通过键盘命令、鼠标移动、语音识别命令等方式进行交互,以适应不同用户的偏好。
(3)允许用户交互可以被中断和撤销
在设计人机界面时,允许用户交互可以被中断和撤销。
(4)当技能级别增长时可以使交互流水化并允许定制交互
用户经常发现他们重复地完成相同的交互序列。设计“宏”机制,使高级用户能定制界面,以方便交互。
(5)使用户隔离内部技术细节
设计应允许用户与出现在屏幕上的对象直接交互。例如,某应用界面允许用户直接操纵屏幕上的某对象(如“拉伸”其尺寸)。
要求用户记住的东西越多,与系统交互时出错的可能也越大,因此好的用户界面设计不应加重用户的记忆负担。下面是减少用户记忆负担的设计原则。
(1)减少对短期记忆的要求
当用户涉及复杂的任务时,要求很多的短期记忆。界面设计应设法减少需要记住的过去的动作和结果。例如,可以通过提供可视的提示,使用户能识别过去的动作。
(2)建立有意义的默认值
允许用户根据个人的偏爱,定义初始的默认值。例如,设置Reset选项,让用户重定义初始的默认值。
(3)定义直觉性的捷径
当使用助忆符来完成某系统功能时(如用Alt+P激活打印功能),助忆符应以容易记忆的方式(如使用将被激活的任务的第一个字母)联系到相关的动作。
(4)界面的视觉布局应该基于真实世界的隐喻
例如,一个账单支付系统应该使用支票本和支票登记隐喻来指导用户的账单支付过程。这使得用户能依赖已经很好理解的可视提示,而不是记住复杂难懂的交互序列。
(5)以不断进展的方式揭示信息
层次式地组织界面,通过点击感兴趣的界面对象,逐层展开其详细信息。
用户应该以一致的方式展示和获取信息,这意味着:所有可视信息的组织遵循统一的设计标准,所有屏幕显示都遵守该标准。输入机制被约束到有限的集合内,在整个软件系统中被一致地使用,同时从任务到任务的导航机制也被一致地定义和实现。保持界面一致性的设计原则包括以下内容。
(1)允许用户将当前任务放在有意义的语境中
很多界面使用数十个屏幕图像来实现复杂的交互层次,提供指示器(如窗口题目、图形图符、一致的颜色)使用户能知道目前工作的语境。此外,用户应该能确定该任务来自何处以及到某新任务的变迁存在什么选择。
(2)在应用系列内保持一致性
一组应用应该统一实现相同的设计规则,以保持所有交互的一致性。
(3)不要改变用户已经熟悉的用户交互模型
除非有不得已的理由,一旦一个特殊的交互序列已经变成一个事实上的标准(如使用Alt+S来存储文件),则用户在其遇到的每个应用中均是如此期望的。改变其含义将导致混淆,让用户不知所措。
Davis提出了一组指导软件测试的基本原则:
还有以下一些其他的测试原则
单元测试又称模块测试,着重对软件设计的最小单元——软件构件或模块进行测试。
单元测试根据设计描述,对重要的控制路径进行单元测试,以发现构件或模块内部的错误。单元测试通常采用白盒测试,并且多个构件或模块可以进行测试。
单元测试的内容主要包括:接口、局部数据结构、边界条件、独立路径和错误处理路径。
(1)接口
测试模块的接口主要是确保模块的输入输出参数信息是正确的。这些信息包括参数的个数、次序、类型等。
(2)局部数据结构
测试模块的局部数据结构主要是确保临时存储的数据在算法执行的整个过程中都能维特其完整性。典型错误有:不合适的类型说明、不同数据类型的比较或赋值、文件打开和关闭的遗漏、超越数据结构的边界等。
(3)边界条件
测试边界条件主要是确保程序单元在板限或严格的情况下仍能正确地执行。
(4)独立路径
测试过程中遍历所有的独立路径就能确保模块中的所有语句都至少执行一次。程序执行的路径实际上体现了计算的过程,计算中常见的错误有:不正确的操作优先级、不同类型数据间的操作、不正确的初始化、不精确的精度、不正确的循环终止、不适当地修改循环变量、发散的迭代等。
(5)错误处理路径
好的软件设计应该能预料可能发生的错误条件,并在错误真的发生时,能通过错误处理路径进行重定向处理或终止处理。单元测试应该对所有的错误处理路径进行测试。错误处理部分潜在的错误有:报错信息没有提供足够的信息来帮助确定错误的性质及其发生的位置、报错信息与真正的错误不一致、错误条件在错误处理之前就已引起系统异常、异常条件处理不正确等。
单元测试通常与编码工作结合起来进行。通常,模块本身不是一个独立的程序,因此在测试模块时必须为每个被测模块开发一个驱动(driver)程序和若干个桩(stub)模块。
驱动程序接收测试输入数据,调用被测模块,把测试输入数据传送给被测模块,在被测模块执行后,驱动程序接收被测模块的返回数据,并打印相关的结果。
桩模块的功能是替代被测模块调用的模块,接受被测模块的调用,验证入口信息,把控制和模拟结果(可使用测试用例中的预期结果)返回给被测模块。
驱动程序的程序结构如下:
桩模块的程序结构如下:
软件维护是指软件系统交付使用以后,为了改正错误或满足新的需求而修改软件的过程,国标GB/T 11457-2006 对软件维护给出如下定义:在交付以后,修改软件或部件以排除故障、改进性能或其他属性或适应变更了环境的过程。
对软件维护有两种常见的错误认识:一是认为软件维护是一次新的开发活动;二是认为软件维护就是改错。虽然软件维护可以看作是新开发活动的继续,但是这两种活动还是有着本质的差别。新开发活动要在一定的约束条件下从头开始实施**,而维护活动则必须在"现有系统的限定和约束条件下实施**。另一方面,维护活动可能发生在改正程序中的错误和缺陷,改进设计以适应新的软、硬件环境以及增加新的功能时。根据起因不同,软件维护可以分为纠错性维护、适应性维护、改善性维护和预防性维护4类。
人们把为了改正软件系统中的错误,使软件能满足预期的正常运行状态的要求而进行的维护叫做纠错性维护。
随着计算机的飞速发展,数据环境(数据库、数据格式、数据输人输出方储介质)或外流环境(新的软、硬件配置)可能发生变化,为了使软件适应这种变化而修改软件的过程叫做适应性维护。
当一个软件顺利地运行时,常常会出现第三项维护的活动:在软件的使用过程中用户往往会提出增加新功能或修改已有功能的建议,还有可能提出一些改进的意见。为了满足这类要求,需要进行改善性的维护。
计算机软件由于修改而逐渐退化.为了使计算机程序能够被更好地纠错、适应和增强,以提高软件的可维护性、可靠性等,为了使计算机程序能够更好的纠错、适应和增强,以提高软件的可维护性,为以后进一步改进软件打下良好基础而修改软件的活动,叫预防性维护。
第四项维护活动在现代的软件业中还比较少。在维护阶段的最初一两年,纠错性维护的工作量较大。随着错误发现率急剧降低,并趋于稳定,就进入了正常使用期。然而,由于改造的要求,适应性维护和改善性维护的工作量逐步增加。
实践表明,在几种维护活动中,改善性维护所占的比重最大,来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50%。
在实践中,软件维护各种活动常常交织在一起,尽管这些维护在性质上有些重叠,但是还是有充分的理由区分这些维护活动。只有正确区分维护活动的类型才能够更有效地确定维护需求的优先级。
软件维护过程是指在软件维护期间所采取的一系列活动。
软件的开发过程对软件的维护产生较大的影响。如果采用软件工程的方法进行软件开发,保证每个阶段都有完整且详细的文档,这样维护会相对容易,被称为结构化维护。
反之,如果不采用软件工程方法开发软件,软件只有程序而缺少文档,则维护工作将变得十分困难,被称为非结构化维护。在非结构化维护过程中,开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等,这样做是十分困难的,也容易产生误解。要弄清楚整个系统,势必要花费大量的人力和物力,对源程序修改产生的后果也难以估计。在没有文档的情况下,也不可能进行回归测试,很难保证程序的正确性。
在结构化维护的过程中,所开发的软件具有各个阶段的文档,对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计约束等有很大的帮助。维护时,开发人员从分析需求规格说明开始,明白软件功能和性能上的改变,对设计文档进行修改和复查,再根据设计修改进行程序变动,并用测试文档中的测试用例进行回归测试,最后将修改后的软件再次交付使用。这种维护有利于减少工作量和降低成本,大大提高软件的维护效率。
与软件维护有关的大多数问题都可归因于软件定义和开发方法上的不足。软件开发时采用急功近利,还是放眼未来的态度,对软件维护影响极大。一般说来,软件开发若不严格遵循软件开发标准,软件维护就会遇到许多困难。下面列出和软件维护有关的部分问题:
软件维护的代价使生产率惊人下降。维护费用只不过是软件维护最明显的代价,其他一些隐性的代价将更为人们关注。其他无形的代价包括以下内容;
用于维护的工作可以划分成:生产性活动(如分析评价、修改设计、编写程序代码等)和非生产性活动(如理解程序代码功能、解释数据结构、分析接口特点和性能界限等)。下面的公式给出了一个维护工作量的模型:M=p+Kerd
其中,M是维护的总工作量,p是生产性工作量,K是经验常数,c是软件的复杂程度,d是维护人员对软件的熟悉程度。
上述模型表明,如果软件开发没有运用软件工程方法学,而且原来的开发人员未能参与到维护工作之中,则维护工作量和费用将呈指数增加。
在软件维护中,影响维护工作量的因素主要有以下6种。
可维护性,是指理解、改正、调整和改进软件的难易程度。对软件可维护性影响的主要因素有:可理解性、可测试性、可修改性和可移植性。
**可理解性是指理解软件的结构、接口、功能和内部过程的难易程度。**提高软件可理解性的措施有:采用模块化的程序结构:书写详细正确的文档;采用结构化的程序设计;书写源程序的内部文档;使用良好的编程语言;0具有良好的程序设计风格等。
可测试性是指测试和诊断软件(主要指程序)中错误的难易程度。提高软件可测试性的antyeta:具n·措施有:采用良好的程序结构;书写详细正确的文档;使用测试工具和调试工具;保存以前1的测试过程和测试用例等。
**可修改性是指修改软件(主要指程序)的难易程度。**在修改软件时经常会发生这样的情况:修改了程序中某个错误的同时又产生新的错误(由程序的修改引起的);或者在程序中增加了某个功能后,导致原先的某些功能不能正常执行。这主要是因为程序中各成分之间存在着许多联系,当程序中某处修改时,这些修改可能会影响到程序的其他部分。如果一个程序的某个修改,其影响波及的范围越大,则该程序的可修改性就越差;反之,其可修改性越好。软件设计中介绍的设计准则和启发式规则都是影响可修改性的因素。通常一个可修改性好的程序应当是可理解的、通用的、灵活的、简单的。通用性是指程序适用于各种功能变化而无需修改。而灵活性是指能够容易地对程序进行修改。
**可移植性是指程序转移到一个新的计算环境的难易程度。**影响软件可移植性的因素有:信息隐蔽原则、模块独立、模块化、高内聚低耦合、良好的程序结构、不用标准文本以外的语句等。可移植性表明程序转移到一个新的计算环境的可能性的大小,或者表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的性能。通常对于软件可移植性的度量考虑如下因素;
可维护性是所有软件都应该具备的基本特点,在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性。在每个开发阶段结束前的技术审查和管理复审中,可维护都是重要的审查指标。
为了延长软件的生存期,提高软件的可维护性具有决定性的意义。通常采用的方法有: .确定质量管理目标和优先级、规范化程序设计风格、选择可维护性高的程序设计语言、完善程序文档和进行软件质量保证审查。
项目管理是通过项目经理和项目组织的努力,运用系统理论的方法对项目及其资源进行计划、组织、协调、控制、旨在实现项目的特定目标的管理方法体系。其基本内容为:
对软件工程项目进行项目管理也需要对上述五个方面的内容进行管理。
由于软件项目的特殊性,将项目管理技术用于软件项目管理上,其有效的项目管理集中于四个P上:人员People、产品product、过程process、项目project。
1.人员
人员是软件工程项目的基本要素和关键因素,在对人员进行组织时,有必要考虑参与软件过程的人员类型。一把们来说可以分为以下5类。
(1)项目管理人员
项目管理人员负责软件项目的管理工作,其负责人通常称为项目经理,项目经理除了要求掌握相应的软件开发担的应具备管理人员应有的技能。项目经理的任务就是要对项目进行全面的管理,具体表现在对项目目标要有一个全局的观点,制订项目计划,监腔项目进展,控制反馈,组建团队,在不确定环境下对不确定问题进行决策,在必要的时候进行谈判并解决冲突。
(2)高级管理人员
高级管理人员可以是领域专家,负责提出项目的目标并对业务问题进行定义,这类业务问题经常会对项目产生较大的影响
(3)开发人员
这类人员常常掌握了开发一个产品或应用所需的专门技术,可胜任包括需求分析、设计、编码、测试、发布等各种相关的开发岗位。
(4)客户
客户是一组可说明待开发软件的需求的人,也包括与项目目标有关的其他风险承担者。
(5)最终用户
最终用户指产品或应用提交后,那些与产品/应用进行交互的人。软件项目的组织就称为软件项目组,每一个软件项目组都有上述的人员参与。项目组的组织必须最大限度地发挥每个人的技术和能力。
2,产品
在进行项目计划之前,应该首先进行项目定义,也就是定义项目范围,其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等。
软件开发者和客户必须一起定义产品的目的和范围。一般情况下,该活动是作为系统工程或业务过程工程的一部分,持续到软件需求分析阶段的前期。其目的是从客户的角度定义该产品的总体目标,但不必考虑这些目标如何实现。软件范围定义了与软件产品相关的数据、功能和行为,及其相关的约束。软件范围包括以下几个方面
(1)周境(context)
说明待建造的软件与其他相关系统、产品或环境的关系,以及相关的约束条件。
(2)信息目标
说明目标系统所需要的输入数据及应产生的输出数据。(
3)功能和性能
说明软件应提供的功能,从而完成输入数据到输出数据的变换,同时还要给出对目标软件的性能要求。
软件项目范围必须是无二义的和可理解的。为控制其复杂性,必要时还需对问题进行分解。
在确定了产品的目的和范围后,就要开始设计并选择备选的解决方案,选择的依据是由产品交付期限、预算、可用的人员、技术接口及各种其他因素所形成的约束。分解。
3,过程
传统的项目管理有大项目一项目一活动一任务一工作包一工作单元等多种分解层次,对软件项目来说,强调的是对其进行过程控制,通常将项目分解为任务子任务等,其分需者则是基于软件工程的过程。
软件过程提供了一个包含了任务的框架,软件项目中这些任发的全面计划,任务中包含了任务名、里程碑、工作产品和质量组成了软件开不同特征和项目需求,选择不同的软件过程,并可对这些框架软件項目的不同的软件过程,也存在少量的公共过程框架活动(framework a与然,对性活动(umbrella activities) 保护性活动(如软件质量保证、软件配置管理和测量等)独立于任何一个框架活动,并贯穿于整个软件开发过程。
公共过程框架活动可有以下几种
(1)客户交流
建立开发者和客户之间的有效需求诱导所需要的任务。
(2)计划
定义资源、进度及其他相关项目信息所需要的任务。(
3)风险分析
评估技术的及管理的风险所需要的任务。
(4)构造及发布
构造、测试、安装和提供用户支持(如文档及培训)所需要的任务。
(5)客户评估
基于对在工程阶段生产的或在安装阶段实现的软件表示的评估,获取客户反馈所需要的任务。
软件项目组应该灵活地选择最适合当前项目的软件过程模型以及模型中所包含的活动和任务。对于一些以前已有开发类似项目经验的较小项目,可以采用类似项目的软件过程。的任务。对于一些需求不很明确的项目,可选择原型模型或螺旋模型。如果项目的开发时间较瓶,在规定的时间内难以完成所有的功能,则可选择增量模型。总之,项目组应根据项目的具体情况和特点,选择合适的软件过程模型。
4.项目
进行有计划和可控制的软件项目是管理复杂性的一种方式。
既然采用了项目这种方式,就有必要采用科学的方法及工具对项目基本内容进行管理。
Real提出了包含如下5个部分常识的软件项目方法
(1)明确目标及过程
充分理解待解决的问题,明确定义项目目标及软件范围,为项目小组及活动设置明确现实的目标,并充分发挥相关小组的自主性。
(2)保持动力
为了维持动力,项目管理者必须提供激励措施以保持人员变动为绝对最小的量,小组应该强调所完成的每个任务的质量,而高层的管理应该尽量不干涉项目小组的工作方式。
(3)跟踪进展
针对每个软件项目,当每个任务的工作制品(如规约、源代码、测试用例集合等)作为质量保证活动的一部分而被批准(通过正式的技术评审)时,对其进展进行跟踪,并对软件过程和项目进行测量。
(4)做出聪明的决策
本质上,项目管理者和软件小组的决策应该“保持其简单”。例如,采用成品构件(COTS)或采用标准方法等。
(5)项目总结
建立一个一致的机制以从每个完成的项目中获取可学习的经验。对计划的和实际的进度进行评估,收集和分析软件项目度量,从项目组成员和客户处获取反馈,并记录所有发现的问题。
Albrecht与1979年首次提出了面向功能的度量,它是一种针对软件的功能特性进行度量的方法,该方法主要考虑软件系统的“功能性”和“实用性”。他建议一种称为“功能点”的度量,功能点是基于软件信息域的特征(可直接测量)和软件复杂性计算的。
功能点的计算步骤如下。
1.计算信息域特征的值CT