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

软件工程:是指导计算机软件开发和维护的工程学科。

它采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

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

主要是两个问题:1. 如何开发软件,怎样满足对软件的日益增长的需求。

2. 如何维护数量不断膨胀的已有软件。

主要表现:1. 对软件开发成本和进度的估计不准确2. 用户不满意3. 软件质量不高、可靠性差4. 软件常常不可维护、错误难以改正5. 缺乏适当的文档资料6. 软件成本占系统总成本的比例逐年上升7. 软件开发速度跟不上计算机发展速度产生软件危机的原因1. 与软件本身的特点有关:软件不同于硬件,它是计算机系统的逻辑部件而不是物理部件。

在写出程序代码并在计算机运行之前,软件开发过程的进展情况较难衡量,软件开发的质量也较难评价。

因此,管理和控制软件开发过程相当困难。

2. 软件不易于维护:(1软件维护通常意味着改正或修改原来的设计,客观上使软件较难维护。

(2软件不同于一般程序,它的规模大,不易于维护。

3. 在软件开发过程中,或多或少地采用了错误的方法和技术。

4. 对用户需求没有完整准确的认识,就匆忙着手编写程序。

解决软件危机的途径:⑴研制新一代体系结构的智能计算机,以改变软件的实现方式,降低软件的复杂性。

目前尚未研制成功。

⑵采用工程化、规范化的开发方法来指导软件的开发:这就是产生“软件工程学”的背景,并在70年代形成了结构化分析、设计方法。

⑶在求解方法上采用面向对象的软件设计方法。

即在软件开发中,以客观世界的问题空间入手进行软件设计,以减少求解方法空间与客观世界问题空间存在的“鸿沟”。

“生命周期法”的起源:软件工程采用的“生命周期法”,就是从时间角度对软件开发和维护的复杂问题进行分解,把软件生存的漫长周期依次划分为若干个阶段,每个阶段有相对独立的任务,然后再逐步完成每个阶段的任务.生命周期划分的原则:任务的性质尽可能相同,从而降低每个阶段任务的复杂性,简化不同阶段之间的联系,有利于软件开发过程的组织管理。

生命周期的划分:软件生命周期一般分为:软件定义(问题定义、可行性研究、需求分析、软件开发(总体设计、详细设计、编码和测试、软件使用与维护等三个时期八个阶段。

问题定义:“要解决什么问题?”可行性研究:“上一个阶段所确定的问题是否有行得通的解决办法”目的:用最小的代价在尽可能短的时间内确定问题是否能够解决需求分析:“系统必须做什么”对待开发软件提出的需求进行分析并给出详细的定义、编写软件需求规格说明书、提交管理机构评审概要设计:把各项需求转换成软件的体系结构。

结构中每一组成部分都是意义明确的模块,每个模块都和某些需求相对应详细设计:对每个模块要完成的工作进行具体的描述,为源程序编写打下基础、编写设计说明书,提交评审。

编码:把软件设计转换成计算机可以接受的程序代码,即写成以某一种特定程序设计语言表示的“源程序清单”、写出的程序应当是结构良好、清晰易读的,且与设计相一致的软件测试:单元测试:查找各模块在功能和结构上存在的问题并加以纠正组装测试:将已测试过的模块按一定顺序组装起来,按规定的各项需求,逐项进行有效性测试,决定已开发的软件是否合格,能否交付用户使用软件维护改正性维护:运行中发现了软件中的错误需要修正适应性维护:为了适应变化了的软件工作环境,需做适当变更完善性维护:为了增强软件的功能需做变更软件工程三要素:过程(为软件工程的过程和方法提供自动化或半自动化的工具支持、方法(完成项目的技术手段(传统方法学、面向对象方法学和工具(为软件工程的过程和方法提供自动化或半自动化的工具支持软件工程釆用层次化的方法,每个层次都包括过程、方法、工具三要素.方法支撑过程和工具、过程和工具促进方法学的研究。

将系统的、规范的、可量化的方法运用到软件工程的始终,渗透到软件工程的过程、方法和工具中。

传统方法学(生命周期方法学原理: 采用结构化技术来完成软件开发的各项任务,并使用适当的软件工具或软件工程环境来支持结构化技术的运用,即把软件生命周期的全过程依次划分为若干阶段,然后顺序地完成每个阶段的任务。

软件的生存周期及其开发模型:一、瀑布模型:优点:通过设置里程碑,明确每阶段的任务与目标。

可为每阶段制定开发计划,进行成本预算,组织开发力量。

通过阶段评审,将开发过程纳入正确轨道。

严格的计划性保证软件产品的按时交付。

缺点:缺乏灵活性,不能适应用户需求的改变。

开始阶段的小错误被逐级放大,可能导致软件产品报废。

返回上一级的开发需要十分高昂的代价。

随着软件规模和复杂性的增加,软件产品成功的机率大幅下降。

适应范围:它主要适应于小规模和需求较为稳定的的软件开发。

瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。

例如操作系统、编译系统、数据库管理系统等系统软件的开发。

应用有一定的局限性。

二、快速原型模型:基本思想:在获取一组基本的需求定义后,利用高级软件工具的可开发环境,快速地建立一个目标系统的最初版本,并把它交给用户试用、补充和修改,再进行新的版本开发。

反复进行这个过程,直到得出系统的“精确解”,即用户满意为止。

经过这样一个反复补充和修改的过程,应用系统的“最初版本”就逐步演变为系统的“最终版本”。

三、增量模型:一种非整体开发的模型。

根据增量的方式和形式的不同,分为基于瀑布模型的渐增模型和基于原型的快速原型模型。

使用增量模型开发模型时,把软件产品作为一系列的增量构件来设计、编码、集成和测试。

每个构件由多个相互作用的模块构成,并且能完成特定的功能。

第一个增量构件往往提供最核心的功能。

注意:在把每个新的增量构件集成到现有软件体系结构中时,必须不破坏原来已经开发出的产品。

增量模型和瀑布模型之间的本质区别是:瀑布模型属于整体开发模型,它规定在开始下一个阶段的工作之前,必须完成前一阶段的所有细节。

而增量模型属于非整体开发模型,它推迟某些阶段或所有阶段中的细节,从而较早地产生工作软件。

四、螺旋模型:在原型基础上,进行多次原型反复并增加风险评估,形成螺旋模型。

模型、优点、缺点:瀑布模型、文档驱动、系统可能不满足客户的需求;快速原型模型、关注满足客户需求、可能导致系统设计差、效率低,难于维护;增量模型、开发早期反馈及时,易于维护、需要开放式体系结构,可能会设计差、效率低;螺旋模型、风险驱动、风险分析人员需要有经验且经过充分训练第二章可行性分析可行性分析就是解决一个项目是否有可行解以及是否值得去解的问题。

该阶段的主要任务就是用最小的代价在尽可能短的时间内确定问题是否能够得到解决。

主要任务:具体地说,分析员应从下面三个方面对项目做出可行性分析:(1技术可行性:使用现有的技术能实现这个系统吗?(2经济可行性:这个系统的经济效益能超过它的开发成本吗?(详细在后面介绍成本/效益分析(3操作可行性:系统的操作方式在该用户组织内行得通吗?必要时还应该进一步从法律、社会效益等更广泛的角度研究每种解法的可行性。

计算成本/效益分析“可行性报告”中最主要的内容是:(1项目的背景:问题描述、实现环境和限制条件等(2管理概要与建议:重要的研究结果(结论、说明、劝告和影响等(3推荐的方案(不止一个:候选系统的配置与选择最终方案的原则(4简略的系统范围描述:分配元素的可行性(5经济可行性分析结果:经费概算和预期的经济效益等(6技术可行性(技术风险评价:技术实力分析、已有的工作及技术基础和设备条件等等(7法律可行性分析结果描述(8可用性评价:汇报用户的工作制度和人员的素质,确定人机交互功能界面需求(9其他项目相关的问题:如可能会发生的变更等等可行性研究报告由系统分析员撰写,交由项目负责人审查,再上报给上级主管审阅。

在可行性研究报告中,应当明确项目“可行还是不可行”,如果认为可行,接下来还要制定项目开发计划书。

第三章软件需求分析需求分析:准确地定义未来系统的目标,确定为了满足用户的需求系统必须做什么。

用<需求规格说明书> 规范的形式准确地表达用户的需求。

任务:确定对系统的综合要求、分析系统的数据要求、导出系统的逻辑模型、修正系统开发计划。

确定对系统的综合要求:1. 功能需求:这方面的需求指定系统必须提供的服务。

通过需求分析应该划分出系统必须完成的所有功能2. 性能需求:性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间、信息量速率、主存容量、磁盘容量、安全性等方面的需求3. 可靠性和可用性需求:可靠性需求定量地指定系统的可靠性4. 出错处理需求:这类需求说明系统对环境错误应该怎样响应5. 接口需求:接口需求描述应用系统与它的环境通信的格式。

常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求6. 约束:设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。

常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台7. 逆向需求:逆向需求说明软件系统不应该做什么8. 将来可能提出的要求:应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。

分析系统的数据要求:分析系统的数据要求,这是软件需求分析的一个重要任务。

分析系统的数据要求通常采用建立数据模型的方法(ER图—考点、数据字典、层次方框图、Wariner图等工具导出系统的逻辑模型:综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

修正系统开发计划:根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划。

需求获取的常用方法:1.客户访谈:发放调查表和情景分析2. 面向数据流自顶向下求精:数据字典、数据流图3.简易的应用规格说明:面向团队需求收集法4.快速建立原型:要点:建立用户看的见得功能、快速、易修改需求建模:所谓模型,就是为了理解事物而对事物做出的一种抽象,是对事物的一种无歧义的书面描述。

通常,模型由一组图形符号和组织这些符号的规则组成。

模型化或模型方法是通过抽象、概括和一般化,把研究的对象或问题转化为本质(关系或结构相同的另一对象或问题,从而加以解决的方法。

需求分析的模型(结构化分析:数据模型ER图;功能模型数据流图P41;行为模型状态转换图数据字典(DD,DataDictionaryDD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义,使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。