目录
软件开发生命周期
软件工程过程
软件维护分类
遗留系统
软件重用
逆向工程
相关概念
抽象层次
需求工程
需求工程主要活动
需求管理的主要活动
需求获取的主要步骤
需求获取方法
需求变更管理的过程
净室软件工程
定义
理论基础
技术手段
应用
缺点
软件开发生命周期
按照传统的软件生命周期方法学,可以把软件生命周期划分为软件定义、软件开发、软件运行与维护三个阶段。
- 软件定义:软件定义包括可行性研究和详细需求分析过程,任务是确定软件开发工程必须完成的目标。具体可分为问题定义、可行性研究、需求分析等。
- 问题定义:问题定义就是人们常说的软件的目标系统是什么,系统的定位以及范围等。也就是要按照软件系统工程需求来确定空间的性质(说明是一种什么性质的系统)。
- 可行性研究:软件系统的可行性研究包括技术可行性、经济可行性、操作可行性和社会可行性等,确定问题是否有解,解决办法是否可行。
- 需求分析:需求分析的任务是确定软件系统的功能需求、性能需求和运行环境的约束,写出软件需求规格说明书、软件系统测试大纲、用户手册概要。
- 功能需求是软件必须完成的功能;
- 性能需求是软件的安全性、可靠性、可维护性、结果的精度、容错性、响应速度和适应性等;
- 运行环境是软件必须满足运行环境的要求,包括硬件和软件平台。
- 软件开发:软件开发时期就是软件的设计与实现,可分成概要(总体)设计、详细设计、编码、测试等。
- 概要设计: 概要设计就是在软件需求规格说明的基础上,建立系统的总体结构(含子系统的划分)和模块间的关系,定义功能模块及各功能模块之间的关系。
- 详细设计:详细设计对概要设计产生的功能模块逐步细化,把模块内部细节转化为可编程的程序过程性描述。详细设计包括算法与数据结构、数据分布、数据组织、模块间接口信息和用户界面等的设计,并写出详细设计报告。
- 编码:又称编程,编码的任务是把详细设计转化为能在计算机上运行的程序。
- 测试:测试可分成单元测试、集成测试、确认测试和系统测试等。通常把编码和测试称为系统的实现。
- 软件运行与维护
- 软件运行就是把软件移交给用户使用。软件投入运行的主要任务就是使软件持久满足用户的要求。
- 软件维护是对软件产品进行修改或对软件需求变化做出响应的过程,也就是尽可能地延长软件的寿命,当软件已没有维护的价值时,宜告退役,软件生命随之宣告结束。
软件工程过程
软件工程过程是指为获得软件产品,在软件工具的支持下由软件工程师完成的一系列软件工程活动,包括以下4个方面
- P(plan)-软件规格说明。规定软件的功能及其运行时的限制。
- D(DO)-软件开发。开发出满足规格说明的软件。
- C(Check)- 软件确认。确认开发的软件能够满足用户的需求。
- A(Action)-软件演进。软件在运行过程中不断改进以满足客户新的需求。
软件维护分类
软件维护可以分为:改正性维护、适应性维护、完善性维护、预防性维护。
- 改正性维护:修改软件错误、改正软件性能上的缺陷、排除实施中的误使用。
- 适应性维护:在使用过程中,外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方法、数据存储介质)可能发生变化。为使软件适应这种变化而修改软件的过程称为适用性维护。
- 完善性维护:扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性
- 预防性维护:指预先提高软件的可维护性、可靠性等,为以后进一步改进软件打下良好的基础。采用先进的软件工程方法对需要维护的软件或软件中的某一部分进行设计、编码和测试。
遗留系统
把对遗留系统的评价结果分列在4个象限内。对处在不同象限的遗留系统采取不同的演化策略。四个策略分别是:淘汰策略(低水平、低价值)、继承策略(低水平、高价值)、改造策略(高水平、高价值)、集成策略(高水平、低价值)
- 淘汰策略:第四象限为低水平、低价值区,即遗留系统的技术含量较低,具有较低的业务价值。对这种遗留系统的演化策略为淘汰,即全面重新开发新的系统以代替遗留系统
- 继承策略:第二象限为低水平、高价值区即遗留系统的技术含量较低,已经不能满足企业运作的功能或性能要求,但具有较高的商业价值,目前企业的业务尚紧密依赖该系统。称这种遗留系统的演化策略为继承。在开发新系统时,需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性,新老系统必须并行运行一段时间,再逐渐切换到新系统运行。
- 改造策略:第一象限为高水平、高价值区,即遗留系统的技术含量较高,本身还有强大的生命力。系统具有较高的业务价值,基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短,称对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型改造两个方面。
- 系统功能的增强是指在原有系统的基础上增加新的应用要求,对遗留系统本身不做改变;
- 数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。
- 集成策略:第三象限为高水平、低价值区,即遗留系统的技术含量较高,但其业务价值较低,可能只能完成某个部门的的业务管理。这种系统在各自的领域里工作良好,但对于整个企业来说,存在多个这样的系统,不同的系统基于不同的平台、不同的数据模型,形成了一个个信息孤岛,对这种遗留系统的演化策略为集成。
软件重用
软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括需求分析文档、设计过程、设计文档、程序代码、测试用例和领域知识等。
- 横向重用:指重用不同应用领域中的软件元素,例如数据结构、分类算法和人机界面构建等
- 纵向重用:指在一类具有较多公共性的应用领域之间进行软件重用
逆向工程
相关概念
- 重构:是指在同一抽象级别上转换系统描述形式
- 设计恢复:是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息
- 正向工程:正向工程是指不仅从现有系统中恢复设计信息,而且使用该信息去改变或重构现有系统,以改善其整体质量。
- 再工程:是指在逆向工程所获得信息的基础上,修改或重构已有的系统,产生系统的一个新版本。再工程是对现有系统的重新开发过程,包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息,而且还能使用这些信息来重构现有系统,以改进它的综合质量。在利用再工程重构现有系统的同时,一般会增加新的需求,包括增加新的功能和改善系统的性能。
抽象层次
- 实现级别:抽象的语法树、符号表、过程的设计表示
- 结构级别:反映程序分量之间相互依赖关系的信息,如调用图、结构图、程序和数据结构
- 功能级别:反映程序功能及程序之间关系的信息,如数据和控制流模型
- 领域级别:反映程序分量或程序实体与应用领域概念之间对应关系的信息,如E-R模型
逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述。抽象层次越高完备性越低,通过逆向工程恢复的难度越大。
需求工程
需求工程主要活动
- 需求获取
- 需求分析
- 需求文档化
- 需求确认与验证
- 需求管理
需求管理的主要活动
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
需求获取的主要步骤
- 开发高层的业务模型
- 定义项目范围和高层需求
- 识别用户角色和用户代表
- 获取具体的需求
- 确定目标系统的业务工作流
- 需求整理与总结
需求获取方法
- 用户面谈
- 需求专题讨论会
- 问卷调查
- 现场观察
- 原型化方法
- 头脑风暴法
需求变更管理的过程
- 需求变更管理的主要过程包括:问题分析和变更描述、变更分析和成本计算、变更实现
净室软件工程
定义
- 净室软件工程是软件开发的一种形式化方法,它可以生成质量非常高的软件。它使用盒子结构规约进行分析和设计建模,并且强调将正确性验证(而不是测试)作为发现和消除错误的主要机制。
- 净室软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工作方式,力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品,再去消除缺陷,而是要求在规约和设计中消除错误,然后以“净”的方式制作,可以降低软件开发中的风险,以合理的成本开发出高质量的软件。
-
净室是一种以合理的成本开发高质量软件的基于理论、面向工作组的方法。
- 净室是基于理论的,坚实的理论是任何工程学科所不可缺少的。再好的管理也代替不了理论基础。
- 净室是面向工作组的,因为软件是由人开发出来的,并且理论必须简化到实际应用才能引导人的创造力和协作精神。
- 净室是针对经济实用软件的生产的,因为在现实生活中,业务和资源的限制必须在软件工程中予以满足。
- 净室是针对高质量软件的生产的,因为高质量改进管理,降低风险及成本,满足用户需求,提供竞争优势。
理论基础
-
函数理论:一个函数定义了从定义域到值域的映射。一个特定的程序好似定义了一个从定义域(所有可能的输入序列的集合)到值域(所有对应于输入的输出集合)的映射。这样一个程序的规范就是一个函数的规范。
- 一个明确定义的函数应当具有以下特性:
- 完备性:对定义域中的每个元素,值域中至少有一个元素与之对应。对程序而言,每种可能的输入都必须定义,并有一个输出与之对应。
- 一致性:在值域中最多有一个元素与定义域中的同一元素对应。对程序而言,每个输入只能对应一个输出。
- 正确性:函数的正确性可以由上述性质判断。对程序而言,某项设计的正确性可以通过基于函数理论的推理来验证。
- 抽样理论:不可能对软件的所有可能应用都进行测试。把软件的所有可能的使用情况看作总体,通过统计学手段对其进行抽样,并对样本进行测试,根据测试结果分析软件的性能和可靠性。
技术手段
净室软件工程的技术手段包括:统计过程控制下的增量式开发、基于函数的规范与设计、正确性验证、统计测试和软件认证。
- 统计过程控制下的增量式开发:增量开发基于产品开发中受控迭代的工程原理-控制迭代。增量开发不是把整个开发过程作为一个整体,而是将其划分为一系列较小的累计增量。小组成员在任何时刻只需把注意力集中于工作的一部分,而无须一次考虑所有的事情。
- 基于函数的规范与设计:盒子结构方法按照函数理论定义了3种抽象层次,行为视图、有限状态机试图和过程试图。规范从一个外部行为视图(称为黑盒)开始,然后被转化为一个状态机视图(称为状态盒),最后由一个过程视图(明盒)来实现。盒子结构是基于对象的,并支持软件工程的关键原则:信息隐藏和实现分离。
- 正确性验证:正确性验证被认为是CSE 的核心,正是由于采用了这一技术,净室项目的软件质量才有了极大的提高
- 统计测试和软件认证:净室测试方法采用统计学的基本原理,即当总体太大时必须采取抽样的方法。首先确定一个使用模型来代表系统所有可能使用的总体。然后由使用模型产生测试用例。因为测试用例是总体的一个随机样本,所以可以得到系统预期操作性能的有效统计推导。
应用
- COBOL 结构化设施项目开发出一项商业软件再工程产品
- IBM 运用净室方法开发的海量存储控制单元适配器
缺点
- CSE 太理论化,需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。CSE 要求采用增量式开发、盒子结构、统计测试方法,普通工程师必须经过加强训练才能掌握,开发软件的成本比较高昂。
- CSE 开发小组不进行传统的模块测试,这是不现实的。工程师可能对编程语言和开发环境还不熟悉,而且编译器或操作系统的bug 也可能导致未预期的错误。
- CSE 毕竟脱胎于传统软件工程,不可避免的带有传统软件工程的弊端。