首页 > IT科技->软件程序开发(软件开发的基础)

软件程序开发(软件开发的基础)

小海疼+ 论文 6513 次浏览 评论已关闭

简单介绍

软件开发方法是软件开发方法学。

提供该方法的主要目的是提高软件开发质量、降低软件的成本。

系统学习软件开发方法的步骤,主要有:

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的最佳实践包含:领域对象建模、根据特征进行开发、类的个体所有、组成特征小组、审查、定期构造、配置管理、结果的可见性。

软件重用

软件重用

利用已存在的软件元素建立新的软件系统,可以是软件产品、源程序、也可以是文档,甚至是领域知识。软件重用可以提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期、提高软件质量。

重用主要包含:源代码重用、架构重用、应用框架的重用、业务建构的重用、文档及过程的重用、软构件的重用、软件服务的重用。

构件技术

两个重要的特征:自包容和可重用。

形式化方法

指采用严格的数学方法,使用形式化规约语言来精确定义软件系统。