第1章 软件工程的范畴
许多软件面临的问题: 推迟交付时间、超出预算、带有残存的错误,且不满足用户的需求
软件工程就是解决这些问题的学科
-
生产出没有错误的软件
-
按时并在预算内交付
-
满足用户的需求
-
易于修改(当用户的需求发生改变时)
1.1 历史方面
相比于发电机和桥梁,软件产品和操作系统崩溃的概率显然较小
软件设计、实现与维护应当有与传统的工程学科具有同等地位,因此提出软件工程这一概念
软件工程应当使用已建立的工程学科的基本原理和范型来解决软件危机
1.2 经济方面
使用新的编码技术会降低时间成本,大家普遍认为速度快的技术应当成为首选,但是需要考虑下列因素:
-
引入新技术的花费。对技术人员的培训费用可能需要两到三个项目来弥补;同时参加培训的阶段技术人员也无法从事生产工作
-
维护问题。新技术的使用给维护带来挑战
1.3 维护性方面
在软件声明周期的范围内描述维护性
传统生命周期:瀑布模型(Waterfall Model)
-
需求阶段: 对概念进行研究和细化,提取客户的需求
-
分析(规格说明)阶段:分析客户需求并生成规格说明文档。“期望产品做什么”
-
设计阶段:结构设计+详细设计。“产品是如何做的”
-
实现阶段:(编码和集成应当并行进行)
-
代码编写+单元测试
-
集成+整体测试
-
验收测试
-
-
交付后维护:纠错性维护(软件修复)+增强型维护(软件改进)
-
退役
1.3.1 维护的传统与现代观点
传统: 开发-维护模型,按照时间进行开发和维护的划分,产品安装之前是开发,产品安装之后是维护
为什么不现实:
-
软件开发周期较长,客户需求很有可能发生改变,也就意味着开发人员可能在产品安装很久之前就要开始“维护”工作。
-
软件复用。传统软件开发过程中,开发人员大多数是从零开始开发。而现在软件开发者需要尽量复用已经存在的软件的各个部分
1.3.2 交付后维护的重要性
1.4 需求、分析与设计
在软件开发的过程中,很明显错误纠正的越早越好
因此在需求、分析和设计阶段纠正错误是很重要的工作。
至于为什么在需求、分析和设计阶段会产生这么多的错误,就说明软件工程的另一个方面:技术能够产生出更好的需求、规格说明和设计
1.5 小组编程方面
如果不能对开发小组进行恰当的组织和安排,将有大量的时间浪费在小组成员的协调上。
所以软件工程的范畴必须包括确保小组恰当管理和组织方面的技术
1.6 为什么没有计划阶段
使用传统范型常常需要进行三类计划:
-
在项目的开始,对管理需求和分析阶段进行初步计划
-
确定软件项目管理计划
-
管理者监督软件项目管理计划的执行
不存在独立的计划阶段,计划贯穿于软件生命周期的始终
1.8 为什么没有文档阶段
与计划相同,没有独立的文档阶段,在任何时候,软件产品的文档必须是完整、正确和最新的。
-
确保文档最新的一个很重要的原因就是软件行业人员流动较大
-
如果前一阶段的文档不是正确、最新和完整的,几乎不可能进行下一阶段的操作
-
除非提供文档来说明一个软件产品的完整性能,否则不可能测试改产品是否正确工作
-
如果没有一个文档精确的描述当前版本的软件可以做什么,维护几乎是不可能的
1.9 面向对象范型
组成传统范型的技术:结构化系统分析,数据流分析,结构化编程和结构化测试
缺陷:
-
不能解决产品规模越变越大的问题。也就是不具备扩展的能力
-
交付后维护难度较高
原因:没有同时面向操作和属性
相反的,面向对象范型将操作和属性看作同等重要。
看待对象的简单方法是将它看作统一的软件制品
关键问题在于实现对象的方法,对象内部的属性外部是看不到的
优势:
1. 关于交付后维护。由于内部信息不为外部所知,极大的减少了回归错误(对软件某处进行修改时,不小心在某处与此毫无关联的位置引发错误)
2. 使软件开发变得容易。软件工程中的对象与现实世界中对应实物的紧密对应关系
3. 设计良好的对象是独立的单元。概念上的独立叫封装
4. 使用传统范型设计的产品是作为一组模块实现的,但是概念上是一个单元
5. 提高了复用度
-
阶段是传统范型的概念,工作流是面向对象范型的概念
-
传统范型的设计阶段: 结构设计+详细设计。先分模块,后对数据结构和算法进行详细设计
1.10 正确看待面向对象范型
1.11 术语
参照课本
PS:本文是作者在阅读《软件工程 面向对象和传统的方法》一书中的个人笔记,起到提纲挈领的作用以帮助理解。详细内容请阅读原数。
本意是帮助本人理解,上传文章也希望能帮助到有需要的人。如果有错误的地方欢迎大家指正。