简单介绍
软件开发方法是软件开发方法学。
提供该方法的主要目的是提高软件开发质量、降低软件的成本。
系统学习软件开发方法的步骤,主要有:
1、软件生命周期
2、软件开发模型
3、软件重用技术
4、形式化开发方法。
软件生命周期
软件也有诞生和消亡,指软件自开始构思与研发到不再使用消亡的过程。
对于软件生命周期的划分,不同的标准有不同的规定,如GB8566-88-软件工程国家标准-计算机软件开发规范将软件分为了8个阶段,具体如下:
l 可行性分析与计划
通过可行性研究,来决定开发此软件的必要性,可行性分析中确定软件的目标、范围、风险、开发成本等内容,从而制定初步的软件研发计划。
产出物《可行性分析报告》、《初步软件研发计划》
l 需求分析
确定软件做成什么样
产出物《需求规格说明书》
l 概要设计
确定整个软件的技术蓝图,根据需求内容从技术层面完成设计方案,主要确定系统的架构、子系统之间的关系、接口规约、数据库模型、编码规范等内容。
作为程序员的工作指南,共程序员了解系统的内部原理。
产出物《概要设计说明书》
l 详细设计
从概要设计中进行细化。
产出物《详细设计说明书》
l 研发实现
编码和单元测试。
产出物源代码。
l 集成测试
经过细心的组织,制订集成测试计划。
产出物《测试用例》、《测试报告》
l 确认测试
验证软件是否同需求一致,是否达到了预期目标。
l 使用和维护
使用过程中会产生新的需求。同时软件维护的过程会贯穿整个软件的使用过程。
当使用和维护结束后,软件系统也就自消亡,软件系统的生命周期结束。
软件开发模型
由于软件进行大规模的开发时代,需要遵循一定的开发方法才能取得成功,这些模式化的方法称之为开发模型。
瀑布模型
核心思想:从一个特定的阶段流向下一个阶段。
该模型认为软件开发是一个阶段化的精确的过程。主要由需求分析、总体设计、详细设计、编码与调试、集成测试与系统测试,同时每个阶段都会向上一个阶段进行反馈缺陷,由上一个阶段进行修正。
优点:分段明确,阶段界限明确。
各个阶段会产生完整的文档,故也称之后面向文档的软件开发模型。
当软件需求明确、稳定时,可以采用瀑布模型按部就班地开发软件,反之会暴露需求的缺陷、后期修改代价昂贵、难以控制开发的风险。
瀑布V模型
采用瀑布模型出现的缺陷无法避免,只能争取在交付前发现更多的缺陷。所以测试成为了最关键的环节。【测试质量直接影响到时软件的质量】,由此产生的瀑布V模型,提出更加强调测试。
1、完成需求分析之后进入总体设计外,还指向了系统测试,即将产生同软件需求一致的系统测试用例,同时软件产品是否符合最初的需求将在系统测试阶段得到验证。
2、其它的以此类推。
瀑布V模型除了保持瀑布模式的阶段文档驱动的特点,而且更强调了软件产品的验证工作。
瀑布模型的缺点: 1、所有后续工作来源地需求,如果需求出现不正确,所有事项将出现偏差。 2、后期的维护工作相当繁重,大部分是在修正需求中的问题。 3、瀑布模型难以适应变化,如果后期出现了需求变化,整个系统又得从头开始。 4、所有阶段完成才能交付给用户,用户等待时间长,有可能存在最终用户才发现不能够满足客户的需求。 5、每个阶段会产生一大堆的文档,这些文档对客户没有意义,但却需要花费大量的人力,所以也称瀑布模型为重载过程。 |
演化模型
为若干瀑布的迭代,根据不同的迭代特点可以深化为螺旋模型、增量模型和原型开发。
螺旋模型
将瀑布模型与演化模型结果,不仅体现了两个模型的优点,还强调了其他模型均忽略的风险分析。
螺旋模型包含4个阶段:需求定义、风险分析、工程实现和评审,组成一次迭代。
基于瀑布模型的开发阶段前,引入一个非常严格的风险识别、风险分析和风险控制,把项目拆解成一个一个的小项目,每个项目都标识一个或多个主要风险,直到所有的主要风险因素都被确定。
螺旋模型强调的是风险分析,适用于庞大而复杂、具有高风险的系统,及时地识别、分析、决定采取何种对策。
存在缺点:
1、需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失。
2、过多地迭代次数会增加开发成本,延迟提交时间。
增量模型
主要用于系统的技术架构成熟、风险较低的时候,主要有两种策略:
1、增量发布:首先做好分析和设计工作,然后将系统划分为若干不同的版本,每一个版本都是一个完整的系统。用户可以在很短的时间内就可以得到系统的初始版本并试用,试用过程中进行反馈,降低项目风险,需要注意:
(1) 每一个版本都是完整的、可用的。
(2) 版本间增量要均匀,如一个月一次,不能存在一个版本为1个月,后一个片为4个月的情况。
2、原型法:每一次迭代都经过一次完整的生命周期,当用户很不明确需求和技术架构时,存在很多不可知的因素,可采用原型法。
(1) 初始时针对一般用户需求进行快速地实现,并不考虑算法的合理性或系统的稳定性。
(2) 主要目的是为了获取精确的用户需求,或验证架构的可用性。
后期会抛弃原型法,重新实现完整的系统。
构建组装模型
利用软构建进行拱积木式的开发,即构件组装模型。
定义软件功能后,将对构件的组装结构进行设计,将系统划分成一组构件的集合,明确构建之间的关系。
构件是独立的、自包容的,因此架构的开发也是独立的,构件之间通过接口相互协作 。
优点:
1、构件的自包容性让系统的扩展变得更加容易
2、设计良好的构件更容易被重用,降低软件开发的成本。
3、粒度小时,可分为不同的若干小组,独立完成。
缺点:
1、对构件设计需要经验丰富的架构师,设计不良的构件难以实现构件的优点
2、重用度时,性能会做出让步
3、增加研发人员的学习成本
4、第三方构件的质量难以控制
统一开发过程
统一开发过程(Unified Process, UP)是一种软件过程,是一个优秀的软件开发模型,提供了完整的开发过程解决方案,可以有效地降低软件开发过程的风险。
UP的二维模型
UP是一个二维模型,时间主线就是横轴的阶段,主要经过初始、细化、构建和交付。
纵轴是按不同的阶段进行的主要工作。
任何一个阶段的工作都不是绝对的,都是相互交叠配合的,但每一个阶段都有侧重点:
初始阶段:最重要的工作是界定系统范围,明确系统目的,这一阶段业务建模和需求工作成为重头戏。
细化阶段:开发者需要抽象出软件的逻辑模型,设计出软件的架构,这一阶段分析工作是最主要的工程活动。
构件阶段:开发者完成系统的构建,并进行测试和部署,这一阶段实施和测试是最主要的活动。
交付阶段:这一阶段不可避免地要对软件系统进行重构、修改、测试和部署。
纵轴而言,主要的工作流是:业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境称为UP的核心工作流。可分为工程活动与管理活动,业务建模、需求、分析设计、实施、测试、部署为工程活动,配置与变更管理、项目管理、环境称为管理活动。(其中环境,也称环境管理,主要用于定义必需的工具、活动的指南、活动的流程规范、工作产品的模板、基本的开发设施等 。
UP的生命周期
生命周期与时间主线阶段一一对应,共有4个里程碑:
1、目标里程碑,对应先启阶段的结束,明确系统的目标和范围即到达该里程碑;
2、架构里程碑,开发者需要确定稳定的系统架构;
3、能力里程碑,已经足够稳定和成熟,并完成Alpha测试;
4、发布里程碑,需要完成系统的Beta测试、完成系统发布和用户培训等工作。
UP的特点
1、每一个阶段都可以进行需求、设计等活动;
2、采用不同的迭代方式,可以演变为演化模型或增量模型;
3、更容易控制软件开发的风险;
4、未经裁剪的UP是一个重载过程;
5、实际应用中,可根据具体问题对UP进行裁剪,从而使其可以适应各种规模的软件和开发团队。
架构师在UP中的活动
1、建立系统架构模型
2、同需求人员和项目管理人员密切协作
3、细化软件架构
4、保持整个架构的概念完整性
还需要定义设计方法、设计指南、编码指南、评审设计等 工作,也有人称UP是一个以架构师为中心的开发模型。
敏捷方法
2001年2月发表《敏捷软件开发宣言》,指出
1、尽早地、持续地向客户交付有价值的软件对开发人员来说最重要的;
2、拥抱变化
3、经常交付可工作的软件
4、业务人员和开发人员紧密合作
5、满足团队人员的需求,并给予足够的信任
6、面对面沟通
7、进度的度量方式
8、可持续的开发
9、不断追求优秀的技术和良好的设计
10、最简单,尽可能减少工作量
11、最好的架构、需求和设计 都来自于一个自我组织的团队
12、团队要定期的总结如何能够更有效率,然后相应的自我调整
基于以上宣言,市场上共提出11种开发方法,如AD、AM、ASD、Crystal、FDD、DSDM、LSD、Scrum、TDD、XBreed、XP。
最常用的是XP(极限编程)。
极限编程
XP为最成熟的一种,XP是一种轻量、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
1、在更短时间内,更早地提供具体、持续的反馈信息;
2、迭代地进行计划编制,最开始迅速生成一个总体计划
3、依赖自动测试程序来监控开发进度
4、依赖口头交流、测试和源程序进行沟通
5、倡导持续的演化式的设计
6、依赖于开发团队内部的紧密协作
7、尽可能达到程序员短期的利益和项目长期利益的平衡
由价值观、原则、实践和行为4部分组成。
一、四大价值观
XP的核心是其总结沟通、简单、反馈、勇气4大价值观。
1、沟通:项目中许多问题就出在缺乏沟通的开发人员身上,所以要求小组成员之间做到时持续的、无间断的交流。鼓励大家口头交流、通过交流解决问题,提高效率。
2、简单:提倡够用就行,也就是尽量简单化。
3、反馈:开发人员要注重反馈,通过持续、明确的反馈来暴露软件状态的问题。
4、勇气:需要有勇气面对快速开发,面对可能的重新开发。
二、12个最佳实践
XP中集成了12个最佳实践。
1、计划游戏:先快速的制定一个概要设计,随着细化不断的清晰,再逐步完善这份计划,产生的结果是一套用户故事及后续的一两次迭代的概要设计;
2、小型发布:“持续集成、小步快跑”,每一次发布的版本应该尽可能的小,前提条件是每个小版本有足够的商业价值,值得发布。
3、隐喻:寻求共识、发明共享词汇、创新的武器、描述架构。
4、简单设计:认为设计不应该在编码之前一次性完成。
5、测试先行
6、重构:一种对代码进行改进,而不影响功能的实现技术;
7、结对编程:团队协作、知识交流与共享
8、集体代码所有制
9、持续集成
10、每周工作40小时
11、现场客户
12、编码标准
特征驱动开发
FDD方法也是一个迭代的开发模型,FDD的每一步强调质量,不断地交付可运行的软件,并以很小的开发提供精确的项目进度报告和状态信息。
一、FDD的角色定义
三要素:人、过程和技术,6种关键性角色:
1、项目经理:
2、首席架构设计师
3、开发经理
4、主程序员
5、程序员
6、领域专家
二、核心过程
1、开发整体对象模型:业务建模的阶段,强调全系统的完整的面向对象建模,需要领域专家和首席架构师相互配合,完成整体对象模型;
2、构造特征列表:所谓特征指的是一个小的、对客户有价值的功能,采用动作、结果和目标来描述特征,特征的粒度最好把握在两周之内,可以整理出系统的需求。
3、计划特征开发:项目经理构造出特征列表、特征间的依赖关系进行计划,安排开发任务;
4、特征设计:主程序员带着特征小组特征进行详细设计,为后面的构建做准备;
5、构建特征:实现
三、最佳实践
组成FDD的最佳实践包含:领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。
软件重用
软件重用
利用已存在的软件元素建立新的软件系统,可以是软件产品、源程序、也可以是文档,甚至是领域知识。软件重用可以提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期、提高软件质量。
重用主要包含:源代码重用、架构重用、应用框架的重用、业务建构的重用、文档及过程的重用、软构件的重用、软件服务的重用。
构件技术
两个重要的特征:自包容和可重用。
形式化方法
指采用严格的数学方法,使用形式化规约语言来精确定义软件系统。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。