软件工程
| 课程代号 | 课程名称 | 教材代号 | 教材名称 | 作者 | 出版社 | 版次 |
|---|---|---|---|---|---|---|
| 02333 | 软件工程 | 023331 | 软件工程 | 瞿中、宋琦等 | 人民邮电出版社 | 2016 年 |
参考书籍:软件工程.epub
考试大纲:02333 软件工程(高纲4068).pdf
【重点】软件工程的定义、特点、基本原理
软件的定义:软件,包括程序、相关数据及其说明文档,在计算机系统中与硬件相互依存。其中程序是按照事先设计的功能和性能要求执行的指令序列;数据是程序能正常操纵信息的数据结构;说明文档包含与程序开发、维护和使用过程中有关的各种图文数据。
软件工程的定义:软件工程是一门研究如何用系统化、规范化、数量化等工程原则和方法进行软件开发和维护的学科,包括软件开发技术和软件项目管理。
软件的特点:首先,软件是一种抽象的逻辑实体;其次,软件是一种通过智力活动,把知识与技术转化为信息的一种产品,它是在研制、开发中被创造出来的;最后,在软件的运行和使用期间,没有硬件那样的机器磨损、老化问题,但是软件也存在退化问题,需要维护。
软件工程的基本原理:
- 用分阶段的生存周期计划严格管理。
- 坚持进行阶段评审。
- 实行严格的产品控制。
- 采纳现代程序设计技术。
- 能清楚地审查结果。
- 开发小组的人员应少而精。
- 承认不断改进软件工程实践的必要性。
软件的分类:系统软件,支撑软件,应用软件
软件系统:系统软件是与计算机硬件紧密配合,使计算机的硬件与相关软件及数据进行协调、高效工作的系统,如操作系统、数据库管理系统、设备驱动程序以及通信处理程序等。
软件危机的定义和原因
软件危机的定义:软件危机指软件产品的质量低得通常不能接受,并且不能满足交付日期和预算限制。
软件危机产生的原因:
- 忽视软件开发前期的需求分析。
- 开发过程没有统一的、规范的方法论的指导,文件资料不齐全,忽视人与人的交流。
- 忽视测试阶段的工作,提交用户的软件质量差。
- 忽视软件的维护。
- 缺少规范而盲目编写程序。
软件工程的生命周期
软件生存周期:软件从开始计划起,到废弃不用止,称为软件生存周期。
通常将软件生存周期分为计划、开发、运行、维护 4 个时期。
软件的生存周期:
- 制订计划
- 需求分析和定义
- 软件设计
- 程序编写
- 软件测试
- 运行与维护
需求分析和定义:需求分析包括需求的获取、分析、规格说明、变更、验证、管理等一系列需求工程。软件人员与用户共同讨论决定,哪些需求是可以满足的,并且加以确切描述。然后编写出软件需求说明书或系统功能说明书,以及初步的系统用户手册,提交管理机构。
运行与维护: 软件产品开发完成投入使用后可能运行若干年。在运行过程中可能因为各方面原因需要进行修改,如硬件变更、操作系统换代、平台移植等问题都可能需要对软件进行维护。
软件开发过程模型
瀑布模型:瀑布模型将软件开发过程划分为需求定义与分析、软件设计、软件实现、软件测试和运行维护等一系列基本活动,并且规定这些活动自上而下、相互衔接的固定次序。该模型支持结构化的设计方法,但它是一种理想的线性开发模式,缺乏灵活性,无法解决软件需求不明确或不准确的问题。
瀑布模型的优点:(1)严格规范软件开发过程,克服了非结构化的编码和修改过程的缺点。(2)强调文档的作用,要求每个阶段都要仔细验证。
瀑布模型的缺点:(1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。(2)由于开发模型是线性的,用户只有等到整个过程的后期才能见到开发成果,中间提出的变更要求很难响应。(3)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
快速原型模型:快速原型模型需要迅速建造一个可以运行的软件原型,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定用户需求基础上开发用户满意的软件产品。
快速原型模型的优点:克服了瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,可以快速构建一个软件原型,用于进行用户需求分析,帮助用户更好地描述系统要实现的功能。
快速原型模型的缺点:(1)所选用的开发技术和工具不一定符合主流的发展。(2)快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
螺旋模型:螺旋模型将瀑布模型和快速原型模型结合起来,它将软件过程划分为若干个开发回线,每一个回线表示开发过程的一个阶段,如此反复形成了螺旋上升的过程。螺旋模型适合于大型软件的开发,它吸收了软件工程“演化”的概念。
螺旋模型的优点:(1)以风险驱动开发过程,强调可选方案和约束条件从而支持软件的重用。(2)关注于早期错误的消除,将软件质量作为特殊目标融入产品开发之中。
螺旋模型的缺点:(1)要求许多客户接受和相信风险分析并做出相关反应是不容易的,往往适应于内部的大规模软件开发。(2)需要软件开发人员具备风险分析和评估的经验,否则将会带来更大的风险。
增量模型:增量模型是一种非整体开发的模型。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,从而适应用户逐步细化需求的形成过程。该模型有较大的灵活性,适合于软件需求不明确、设计方案有一定风险的软件项目。
增量模型的优点:(1)较好地适应需求的变化,用户可以不断看到所开发软件的可运行中间版本。(2)重要功能被首先交付,从而使其得到最多的测试。
增量模型的缺点:(1)各个构件是逐渐并入已有的软件体系结构中,要求软件具备开放式的体系结构。(2)容易退化为边做边改的方式,从而使软件过程的控制失去整体性。
喷泉模型:喷泉模型是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。
喷泉模型的优点:(1)具有更多的增量和迭代性质,生存周期的各个阶段可以相互重叠和多次反复。(2)在项目的整个生存周期中还可以嵌入子生存周期。(3)采用面向对象方法实现的这种在概念上和表示方法上的一致性,保证了开发活动间的无缝过渡。
喷泉模型的缺点:面向对象范例要求经常对开发活动进行迭代,这就有可能造成在使用喷泉模型的开发过程中过于无序。
统一过程模型:Rational统一过程(Rational Unified Process,RUP),RUP把一个项目分为 4 个不同的阶段。(1)初始阶段。包括用户沟通和计划活动两个方面,强调定义和细化用例,并将其作为主要模型。(2)细化阶段。包括用户沟通和建模活动,重点是创建分析和设计模型,强调类的定义和体系结构的表示。(3)构造阶段。将设计转化为实现,并进行集成和测试。(4)交付阶段。将本次迭代的可用产品移交给用户。
统一过程模型的优点:(1)任何功能开发后就进入测试过程,及早进行验证。(2)早期风险识别,采取预防措施。
统一过程模型的缺点:(1)需求必须在开始之前完全弄清楚,是否有可能在架构上出现错误。(2)必须有严格的过程管理,以免使过程退化为原始的“试—错—改”模式。(3)如果不加控制地让用户过早接触没有测试完全、版本不稳定的产品,可能为用户和开发团队都带来负面的影响。
极限编程过程:极限编程(Extreme Programming,XP)是敏捷软件开发方法的代表。
极限编程过程模型的优点:(1)重视客户的参与、团队合作和沟通。 (2)制订计划前做出合理预测,让编程人员参与软件功能的管理。 (3)重视质量、设计简单、高频率的重新设计和重构、高频率及全面的测试。 (4)递增开发和连续的过程评估。 (5)对过去的工作持续不断地检查。
极限编程过程模型的缺点: (1)以代码为中心,忽略了设计。 (2)缺乏设计文档,局限于小规模项目。 (3)对已完成工作的检查步骤缺乏清晰的结构,质量保证依赖于测试并缺乏质量规划。 (4)没有提供数据的收集和使用的指导。 (5)开发过程不详细,全新的管理手法带来的认同度问题。 (6)缺乏过渡时的必要支持。
软件开发方法,软件开发工具
软件开发方法:结构化方法,面向数据结构的开发方法,面向对象的方法,视觉化开发方法
结构化方法:1978 年,爱德华·尤顿和拉里·康斯坦丁提出了结构化方法。结构化方法的基本要点是自顶向下、逐步求精、模块化设计。
面向数据结构的开发方法:面向数据结构开发方法的最终目标是得出对程序处理的描述。这种方法的总指导思想是自顶而下、逐步求精、单入口、单出口,基本原则是抽象和功能分解。因此,这种方法最适合于详细设计阶段使用,在完成软件结构设计之后,可以使用面向数据结构的方法来设计每个模块的处理过程。
视觉化开发方法:可视化开发工具应提供两大类服务。一类是生成图形用户接口及相关的消息响应函数;另一类服务是为各种具体的子应用的各个常规执行步骤提供规范窗口,它包括对话框、菜单、列表框、组合框、按钮和编辑框等,以供用户挑选,开发工具还应为所有的选择(事件)提供消息响应函数。
软件工程的最新发展动向
- 软件工程合理的开发治理
- 软件工程全球化协作发展
- 软件工程模块化
- 软件工程开放式计算
可行性研究的任务、内容和步骤
可行性研究:可行性研究是在明确了问题定义的基础上,对软件项目从技术、经济等各个方面进行研究与分析,得出项目是否具有可行性结论的过程。
可行性研究的任务:用最小的代价、在尽可能短的时间内确定问题是否能够解决。
但必须注意的是,可行性研究的根本目的并不是解决问题,而是确定问题是否值得去解决,也就是判断系统原定的目标和规模是否能实现,软件使用所带来的效益是否值得用户去投资开发。因此,可行性研究实质上是要进行一次压缩和简化系统分析、设计的过程,是在较高层次上以较抽象的方式进行的系统分析和设计
可行性研究的基本内容:经济可行性、技术可行性、法律可行性。
技术可行性:在技术可行性研究过程中,系统分析员应采集软件系统涉及的各种信息(包括系统性能、可靠性、可维护性和可生产性方面),分析实现系统功能和性能所需要的各种设备、技术、方法和过程,并且需要分析软件开发在技术方面可能面临的风险,以及技术问题对开发成本的影响等。
可行性研究的步骤:
- 系统规模和目标的复查
- 认真研究现有系统
- 导出新系统的高层逻辑模型
- 重新定义问题
- 导出和评价供选择的方案
- 推荐方案和行动方针
- 草拟开发计划
- 提交文档
需求规格说明书的写法
问题定义
问题定义阶段在说明软件项目的最基本情况下形成问题定义报告。在此阶段,开发者与用户一起,讨论待开发软件项目的类型(应用软件还是系统软件、通用软件还是专用软件)、将要开发软件项目的性质(主要是区分软件是新开发软件还是原有软件系统的升级)、待开发软件项目的目标(软件主要的使用功能)、待开发软件的大致规模以及开发软件项目的负责人等问题,并且用简洁、明确的语言将上述内容写进问题报告,最后双方对报告签字认可。
问题定义阶段的持续时间一般很短,形成的报告文本也相对比较简单。问题定义报告主要有如下内容。
- 待开发项目名称。
- 软件项目的使用单位和部门。
- 软件项目的开发单位。
- 软件项目的用途和目标。
- 软件项目的类型和规模。
- 软件项目开发的开始时间以及大致交付使用的时间。
- 软件项目开发可能投入的经费。
- 软件项目的使用单位与开发单位双方名称全称及其盖章。
- 软件项目的使用单位与开发单位双方的负责人签字。
- 问题定义报告的形成时间。
系统流程图的画法
系统流程图的符号:
系统流程图的图形元素比较简单,也较容易理解。一个图形符号代表一种物理部件,这些部件可以是程序、文件、数据库、表格、人工过程等。
在系统流程图的绘制过程中,要注意以下 3 个方面:
- 物理部件的名称应写在图形内,用以说明该部件的含义。
- 系统流程图中不应该出现信息加工控制的符号。
- 用以表示信息流的箭头符号,无须标注名称。
分层:面对复杂的系统,一个比较好的方法是分层次描绘。首先用一张高层次的系统流程图描绘系统总体概括,表明系统的关键功能,然后分别把每个关键功能扩展到适当的详细程度,画在单独的一页纸上。



