软件开发方法
软件开发方法时指软件开发过程所遵循的办法和步骤,从不同角度可以对软件开发方法进行不同的分类。
按照开发风范分类
自顶向下
将一个大问题分化成多个可以解决的小问题,然后逐一进行解决。每个问题都会有一个模块去解决它,且每个问题包括抽象步骤和具体步骤。
自底向上
从具体的器件、逻辑部件或者相似系统开始,凭借设计者熟练的技巧和丰富的经验,通过对其进行相互连接、修改和扩大,构成所需要的系统。
按照性质分类
形式化
基于严密的、数学上的形式机制的计算机系统研究方法。
非形式化
各种开发模型
结构化方法
由结构化分析、结构化设计、结构化程序设计组成。
- 开发目标清晰化
- 保持与用户沟通,让用户了解工作进展,校准工作方向。
- 开发工作阶段化
- 每个阶段完成后,要进行评审,便于项目管理与控制。
- 开发文档规范化
- 每个阶段完成后,按照要求完成相应文档,保证系统维护工作的便利。
- 设计方法结构化
- 自顶向下分解,进行分析与设计。根据设计要求先编写各个功能模块,自底向上实现。
缺点:开发周期长、难以适应需求变化、很少考虑数据结构。
面向对象方法
方法 | 说明 |
---|---|
Coad/Yourdon方法 | 特别强调OOA和OOD采用完全一致的概念和表示法,使分析和设计之间不需要表示法的转换。 |
Booch方法 | 开发模型包括静态模型和动态模型,静态模型分为逻辑模型(类图、对象图)和物理模型(模块图、进程图),用来描述系统的构成和结构。动态模型包括状态图和顺序图,用来描述对象的状态变化和交互过程。 |
OMT方法 | 使用了建模的思想,采用对象模型(对象图)、动态模型(状态图)、功能模型(DFD)来建立一个实际的应用模型。 |
OOSE | 使用用例(use case)取代了DFD来进行需求分析和建立功能模型。 |
原型方法
原型法也称快速原型法,可以根据用户初步需求利用系统工具快速建立一个系统模型,与用户交流。
按照实现功能划分
水平原型 | 垂直原型 |
---|---|
行为原型,用于界面。细化需求但未实现功能。 | 结构化原型,用于复杂算法的实现,实现了部分功能。 |
按照最终结果划分
抛弃式 | 演化式 |
---|---|
探索式原型,解决需求不确定性、二义性、不完整性、含糊性等。 | 逐步演化为最终系统,用于易于升级和优化的场合,适用于Web项目。 |
面向服务的方法
抽象级别
- 操作
- 最低层,代表单个逻辑单元的事物,包含特定的结构化接口,并且返回结构化的响应。
- 服务
- 代表操作的逻辑分组。
- 业务流程
- 最高层,为了实现特定业务目标而执行的一组长期运行的动作或者活动。
构件化开发方法
- 构件
- 独立部署单元
- 作为第三方的组装单元
- 没有(外部可见)状态
- 对象
- 一个实例单元,具有唯一标志
- 可能具有状态,此状态外部可见
- 封装了自己的状态和行为
构件并非一定包含类,一个类元素只能属于一个构件。
构件的获取
- 从现有的构件中获得符合要求的构件,直接使用或作适应性修改,得到可复用的构件。
- 通过遗留工程(Legacy Engineering),将具有潜在复用价值的构件提取出来,得到可复用的构件。
- 从市场上购买现成的商业构件。
- 开发新的符合要求的构件。
构件的分类
- 关键字分类法
- 将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构,每个概念用一个描述性的关键字表示。
- 刻面分类法
- 定义若干用于刻画构件特征的“刻面”,每个面包含若干概念,这些概念描述构件在刻面商的特征。
- 超文本分类法
- 所有构件必须辅以详尽的功能或行为说明文档
- 说明中出现的重要概念或构件以网状链接方式相互连接
- 检索者在阅读文档的过程中可按照人类的联想思维方式任意跳转到包含相关概念或构件的文档
- 全文检索系统将用户给出的关键字与说明文档中的文件进行匹配,实现构件的浏览式检索。
构件复用方法
- 检索与提取构件
- 理解与评价构件
- 修改构件
- 构件组装
构件的检索方法
- 基于关键字的检索
- 刻面检索法
- 超文本检索法
敏捷开发方法
核心思想
- 适应型,而非可预测型。
- 以人为本,而非以过程为本。
- 迭代增量式的开发过程。
核心价值观
- 沟通
- 设计者、开发者、客户,三者之间的有效交流是开发成功的关键。
- 简单
- 设计和编码的指导原则,强调只满足当前功能需求,尽量使代码简单化。
- 反馈
- 强调设计者、开发者、客户,三者之间及时和详尽的意见反馈是开发成功的保证。
- 勇气
- 要求设计者和开发者在必需作出取舍或重构时,勇于抉择、勇于实践。
过程实践规则
- 计划游戏
- 快速制定计划、随着细节的不断变化而完善。
- 小型发布
- 系统的设计要能够尽可能早地交付。
- 隐喻
- 找到合适的比喻传达信息。
- 简单设计
- 只处理当前的需求,使设计保持简单。
- 测试先行
- 先写测试代码,然后编写程序。
- 重构
- 重新审视需求和设计,重新明确地描述它们以符合新的和现有的需求。
- 结对编程
- 两个程序员在一个计算机上共同工作。一个人输入代码,另一个人审查。
- 集体代码所有制
- 开发人员轮换完成系统不同领域中不同模块的不同任务。每个人都对程序负责。
- 持续集成
- 可以按日,甚至按小时为客户提供可能运行的版本。
- 每周工作40个小时
- 保证工作质量。
- 现场客户
- 系统用户代表全程配合XP团队。
- 编码标准
- 规范代码的编写。
分类
方法 | 说明 |
---|---|
XP极限编程 | 高效、低风险、测试先行(先写测试代码,后编写程序。) |
Cockburn水晶方法 | 不同项目,不同策略。 |
SCRUM并列争求方法 | 迭代。30天为一个迭代周期,按照需求优先级实现。 |
FDD功用驱动方法 | 开发人员分类。分为指挥者(首席程序员)、类程序员。 |
开放式源码 | 虚拟团队,开发成员分布各地。 |
ASD自适应方法 | 预测—协作—学习 |
适用范围分类
整体性方法
局部性方法
开发模型
软件生存周期模型又称软件开发模型(Software Develop Model)或软件过程模型(Software Process Model),它是从某一个特定角度提出的软件过程的简化描述。
模型的主要特点是简单化,软件过程模型是软件开发实际过程的抽象与概括,它应该包括构成软件过程的各种活动,也就是对软件开发过程各阶段之间关系的一个描述和表示。
基本概念
软件过程是制作软件产品的一组活动以及结果,这些活动主要由软件人员来完成,软件活动主要有:
- 软件描述
- 必须定义软件功能以及使用的限制。
- 软件开发
- 也就是软件的设计和实现,软件工程人员制作出能满足描述的软件。
- 软件有效性验证
- 软件必须经过严格的验证,以保证能够满足客户的需求。
- 软件进化
- 软件随着客户需求的变化不断改进。
瀑布模型-结构化方法
特点
- 上一次的开发成果作为本活动的输入,利用这一输入实施本活动。
- 本次活动的成果输出给下次活动。
- 对本次活动的成果实施评审。若成功得到确认,则继续下一项开发活动;否则返回前一项,甚至更前项活动。
缺点
- 现实中软件的需求很难确定,甚至是不可能和不现实的。
- 需要很长时间才会得到软件的初始版本,如果需求改变可能损失巨大。
原型模型-原型方法
注意事项
- 用户对系统模糊不清,无法准确回答目标系统的需求。
- 要有一定的开发环境和工具支持。
- 经过对原型的若干次修改,应收敛到目标范围内,否则可能会失败。
- 对大型软件来说,原型可能非常复杂而难以快速形成,如果没有现成的,就不应考虑用原型法。
螺旋模型
螺旋模型是瀑布模型和原型模型相结合,并加入两者所忽略的风险分析所建立的一种软件开发模型。
螺旋模型沿着螺线进行若干次迭代,每次迭代都包括制定计划、风险分析、实施工程和客户评估4个方面的工作。
螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应。
因此,特别适用于庞大、复杂并具有高风险的系统。
喷泉模型-面向对象方法
- 各项活动之间无明显边界,如分析、设计和编码之间没有明显的界限。
- 在系统某个部分常常被重复工作多次,相关对象在每次迭代中随之渐进的加入系统。
基于可重用构件的模型-构件化开发方法
RAD快速应用开发
快速应用开发(Rapid Application Develop,RAD)是一种比传统生命周期法快得多的开发方法,它强调极端的开发周期。
RAD模型是瀑布模型的一个高速变种,通过使用基于构件的开发方法进行快速开发。
基本思想
- 让用户更主动地参与到系统分析、设计和构造活动中来。
- 将项目开发组织成一系列重点突出的研讨会,研讨会要让项目投资方、用户、系统分析师、设计人员和开发人员一起参与。
- 通过一种迭代的构造方法,加速需求分析和设计阶段。
- 让用户提前看到一个可工作的系统。
RUP统一过程模型
统一过程模型(Rational Unified Process,RUP)将项目管理、业务建模、分析与设计等统一起来,贯穿整个开发过程。
RUP中的软件过程在时间上被分解为4个顺序的阶段,分别是初始阶段、细化阶段、构建阶段和移交阶段。
每个阶段结束时都要安排一次技术评审,以确定这个阶段的目标是否已经满足。如果评审结果令人满意,就可以允许项目进入下一个阶段。
RUP强调要采用迭代和增量的方式来开发软件,把整个项目开发分为多个迭代过程。在每次迭代中,只考虑系统的一部分需求,进行分析、设计、实现、测试和部署等过程,每次迭代是在已完成部分的基础上进行的,每次增加一些新的功能实现,以此进行下去,直至最后项目的完成。
软件开发采用迭代和增量的方式有以下好处:
- 在软件开发的早期就可以对关键的、影响大的风险进行处理。
- 可以提出一个软件体系结构来指导开发。
- 可以更好地处理不可避免的需求变更。
- 可以较早地得到一个可运行的系统,鼓舞开发团队的士气,增强项目成功的信心。
- 为开发人员提供一个能更有效工作的开发过程。
软件重用
软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括需求分析文档、设计过程、设计文档、程序代码、测试用例和领域知识等。
分类
软件重用可区别为横向重用和纵向重用。
类别 | 说明 |
---|---|
横向重用 | 指重用不同领域中的软件元素,例如数据结构、分类算法和人机界面构件等。 |
纵向重用 | 指在一类具有较多公共性的应用领域之间进行软件重用。 |
逆向工程
逆向工程(Reverse Engineering),与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。
概念说明
- 重构(Restructuring)
- 重构是指在同一抽象级别上转换系统描述形式。
- 设计恢复(Design Recovery)
- 设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
- 再工程(Re-Engineering)
- 再工程是指在逆向工程所获得信息的基础上,修改或重构已有的系统,产生系统的一个新版本。
- 再工程是对现有系统的重新开发过程,包括逆向工程、新需求的考虑过程和正向工程三个步骤。
- 正向工程(Forward Engineering)
- 正向工程是指不仅从现有系统中恢复设计信息,而且使用该信息去改变或重构现有系统,以改善其整体质量。
抽象层次
抽象级别 | 说明 |
---|---|
实现级别 | 抽象的语法树、符号表、过程的设计表示。 |
结构界别 | 反应程序分量之间相互依赖关系的信息,如调用图、结构图、程序和数据结构。 |
功能级别 | 反应程序段功能及程序段之间关系的信息,如数据和控制流模型。 |
领域级别 | 反应程序分量或程序实体与应用领域概念之间对应关系的信息,如E-R模型。 |
完备性
可以用在某一个抽象层次上提供信息的详细程度来描述。
抽象层次越高完备性越低,通过逆向工程恢复的难度越大。