尽管程序员领着一份不错的薪水,可是他们也同样付出了巨大的精力与时间。随着软件规模的日益庞大,用户需求的不确定以及快速变更,使得软件开发已经不能停留在小作坊式的个人英雄时代,它已经发展为如今的依赖团队合作的行为,常规的管理方法已经无法满足软件开发的实际需求。而软件工程正是研究如何以系统性的、规范化的 、可定量的过程化方法高效开发与管理、维护软件的交叉性学科。
- 软件工程过程有哪些
- 常见的软件开发过程模型有哪些
- UML中一般有哪些图
软件工程过程有哪些
软件工程是一门系统科学,是研究与应用如何以系统性的、规范性的、可定量的过程化方法来开发与维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的方法。
标准的软件开发过程具备一定的流程,一般包括以下几个方面的内容:可行性分析、需求分析、设计、编码与实现、测试以及运行与维护。
(1)可行性分析
可行性分析是系统在正式立项之前必须进行的一项工作,它的目的不是为了分析软件开发过程中的问题,也不是为了解决软件开发过程中可能存在的问题,而是确定软件系统是否有价值做、是否能够以尽可能小的代价在尽可能短的时间内解决问题。
具体而言,在可行性分析阶段,要确定软件的开发目标与总的要求,所以在做可行性分析的时候,一般需要考虑技术是否可行、经济效益是否可行、用户操作是否可行、法律与社会是否可行等。例如,对于一个超市商品价格查询系统而言,就需要调查顾客是否希望使用这样的软件,超市商品价格来源是哪里?技术上是否能够实现等?
可行性分析一般都由战略专家执行,该阶段的文档成果为《可行性分析报告》
(2)需求分析
需求分析是软件项目成败的关键,它是回答客户做什么的问题,是一个对用户的需求进行正确加工、正确理解,然后把它用软件工程开发语言表达出来的过程。需求分析不仅仅是用户需求,也应该死开发中遇到的所有的需求。例如,在做需求分析时,首先需要弄清楚该项目的目的是为了解决什么问题;其次弄清楚测试案例中应该输入什么数据,最后就是弄清楚哪些人需要使用本系统等。
本阶段的基本任务是和用户一起确定要解决的问题,建立软件的逻辑结构,编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段一般能形成软件需求说明书、数据要求说明书以及初步的用户手册。
需求分析需要领域专家与系统架构师都参与进来,阶段性文档成果为《需求分析说明书》等。
(3)设计
软件设计的主要任务是将软件分解成模块,即实现某个功能的数据和程序说明、可执行程序的程序单元。这个模块可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据,也可以是可组合、可分解以及可更换的功能单元。
软件设计可以分为概要设计和详细设计两个阶段。
概要设计就是结构设计,其主要目标就是给出软件的模块结构。在详细设计中,首先就是要设计出模块的程序流程、算法和数据结构,其次是设计数据库,常用方法还是结构化程序设计方法。
该阶段的文档成果有《概要设计说明书》、《业务用例文档》、《详细设计说明书》、《技术用例文档》等
(4)编码与实现
编码是指把软件设计转换成计算机可以接受的程序,即写成以某一程序设计语言表示的“源程序清单”。程序设计语言可以是C、C++、C#或Java等。 当前软件开发中除在专用场合,已经很少使用20世纪80年代的高级语言了,取而代之的是面向对象程序设计语言,而且面向对象的开发语言和开发环境大都合为一体,大大提高了开发的速度。由面向对象的开发语言开发的项目,系统的可扩展性与可维护性都大大增强。
该阶段的文档成果有《接口文档》、《关键算法文档》等。
(5)测试
软件测试贯穿于软件开发的整个过程,它的目的是以较小的代价发现尽可能多的错误。要实现这个目标关键在于根据软件开发各阶段的规格说明和程序的内部结构精心设计一套出色的测试用例(测试数据和预期的输出结果组成了测试用例),利用这些测试用例进行测试,从而发现程序中存在的错误和bug。不同的测试方法有不同的测试用例设计方法,常用的测试方法有白盒测试和黑盒测试。
白盒测试是一种测试单元内部如何工作的方法,目的是通过检查软件内部的逻辑结构,对软件中逻辑路径进行覆盖的测试,而黑盒测试不考虑程序的内部结构与特性,只根据程序功能或程序的外部特性设计测试用例,这两种测试方法都是依据软件的功能或对软件的行为描述,发现软件的接口、功能和结构错误。
该阶段的文档成果有《单元测试报告》、《集成测试报告》、《系统测试报告》等。
(6)运行与维护
虽然系统交付给用户,安装运行了,但是任何一个系统都不是一开始就能完全满足实际的应用需求,一般在交付使用后,还需要不断地进行再开发。而维护是指在已完成对软件的研制(分析、设计、编码和测试)工作并交付使用以后,对软件产品所进行的一些软件工程的活动。即根据软件运行的情况,对软件进行适当修改与维护,如完善性维护、适应性维护,以适应新的要求,以及纠正运行中发现的错误,编写软件问题报告、软件修改报告。一个系统的质量的高低和系统的分析、设计有很大的关系,和系统的维护也有很大的关系。
需要注意的是,软件工程比较强调文档的重要性,所以每个阶段最好能够有文档保存,因为每个阶段建立在上一个阶段的基础之上,如果基础出了问题,后续阶段都可能会出现相应的问题,文档正好可以备查。
常见的软件开发过程模型有哪些
软件开发过程描述的是软件构造、部署以及维护的一种方法,它规定了完成各项任务所需的步骤。建立软件开发过程模型的理论基础是软件生命周期理论和相关的软件工程原则。
软件开发过程的核心思想是将软件开发过程分为若干个阶段,每个阶段都遵循“高内聚、低耦合”(耦合性:也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。。内聚性:又称块内联系。指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的内聚性就越高。)的特性,这样可以有助于简化问题、有助于验证分阶段的工作成功,并且加强对软件开发的管理。
常见的软件开发过程模型有瀑布模型、螺旋模型、增量模型、原型模型和RUP模型。
(1)瀑布模型
瀑布模型将软件生命周期划分为可行性分析、需求分析、设计、代码实现、测试、安装于维护等6个基本活动,并且规定了它们自上而下的固定次序,形如瀑布流水,逐层下落。图11-1所示为瀑布模型结构图。
在瀑布模型中,软件开发的各项活动都严格按照现行方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。
作为一种最早出现的软件开发模型,瀑布模型为项目提供了按阶段划分的检查点,当前一阶段完成后,开发人员只需要去关注后续阶段的工作,所以采用瀑布模型可以严格地保证软件产品最终能够按时交付使用。但是由于瀑布模型的这种线性关系,使得各个阶段的划分太过固定,阶段之间产生了大量的文档,从而会增加工作量;在瀑布模型中,用户只有等到整个开发过程的末期才能见到开发成果,从而会增加开发的风险;而且会产生一个严重的后果,就是早期的错误可能等到了测试才被发现,问题会被放大最终导致严重的后果。
(2)原型模型
原型是指模拟某种产品的原始模型,软件系统的原型是软件系统的一个早期可以运行的版本。原型模型是增量模型的一种形式,在开发真实系统前,首先需要构建一个简单的系统原型,实现客户或未来的用户与系统的交互,客户或用户在对原型进行使用使用的过程中,不断发现问题,从而达到进一步细化系统需求的目的。开发人员在已有原型的基础上,通过逐步调整原型来满足客户或用户的需求,确定客户的真正需求,进而开发出客户或用户满意的系统。图11-3所示为原型模型结构图。
原型模型可以克服瀑布模型的缺点,减少因为软件需求不明造成的开发风险。它的关键之处在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,使用原型模型进行软件开发,最重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求,而不是系统的内部结构。
(3)螺旋模型
螺旋模型是一种采用周期性的方法来进行软件系统开发的模型,它结合了瀑布模型与原型模型的特点,强调了其他模型所忽视的风险分析,常用于大型复杂系统的开到。图11-2所示的为螺旋模型结构图。
螺旋模型的优点主要表现在它设计上的灵活性,它可以在项目的各个阶段进行变更,以小的分段来构建大型系统可以使成本计算简单明了,而且风险分析可以使一些极端困难的问题和可能导致费用过高的问题被更改或取消,同时用户评价为需求的变更带来柔性,客户始终能够掌握项目的进展,从而提高需求的准确性与开发的高效性。而螺旋模型的缺点是由于它强调风险分析,要求客户接受并相信这种分析,而做出相关反应是不容易的,需要开发人员具有相当丰富的风险凭据经验和专门知识,而且要求用户参与阶段评价,对用户来说比较困难,过多的迭代次数也会增加开发成本,推迟软件交付的时间。
(4)增量模型
增量模型也称为渐增模型,是在项目的开发过程中以一系列的增量方式开发系统。在增量模型中,软件被作为一系列的构件来设计、实现、集成与测试。每一个构件都由多种相互作用的模块所形成的提供特定功能的代码片段构成。在增量模型开发中,将整个产品分解成若干个构件,每次并不是交付一个可运行的完整产品,而是交付系统的部分可运行子系统。此种方法的优点四可以较好地适应客户或用户需求的变化,客户或用户可以分批不间断地看到运行良好的子系统,从而降低开发风险。图11-4所示为增量模型结构图
缺陷:
- 系统是进行增量开发的,所以每次加法的构件在添加入系统的时候都有可能破坏已构建好的系统部分。
- 需求的变化时不可避免的,增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也容易使软件过程的控制失去整体性。
在增量模型中,第一个增量往往是实现基本需求的核心产品。核心产品交付使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、编辑和文档生成功能,第二个增量发布更加完善的编辑和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能。
(5)统一软件过程RUP模型
RUP(Rational Unified Process 统一过程)是Rational公司提出的一套软件开发过程模型。它将用户需求转化为软件系统所需活动的集合,描述了一系列相关的软件工程流程,他们具有相同的结构,即相同的流程框架。
RUP 吸收了多种开发模型的优点,具有良好的操作性与实用性。统一过程不仅是一个简单的过程,而且是一个通用的过程框架。它可以用于各种不同类型的软件系统、各种不同的应用领域、各种不同的项目规模等。
RUP可以用二维坐标来描述。横轴通过时间组织,是过程展开的生命周期特征,体现开发过程的动态结构,用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone);纵轴以内容来组织为自然的逻辑活动,体现开发过程的静态结构,用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。
RUP中的软件生命周期在时间上被分解为4个阶段,即初始阶段(Inception)、细化阶段(Elaboration)、构建阶段(Construction)以及交付阶段(Transition)。每个阶段结束于一个主要的里程碑,而每个阶段本质上是两个里程碑之间的时间跨度。图11-5RUP所示为RUP工作流程示意图。具体而言,四个阶段的功能如下所示。
- 初始阶段:初始阶段的目标是为系统建立商业案例并确定项目的边界,在这个阶段定义了最终产品视图、商业模型并确定系统范围。它以需求分析为主,建立系统整体结构。初始阶段结束时的第一个重要的里程碑是生命周期目标里程碑,它用于评价项目基本的生存能力。
- 细化阶段:设计及确定系统的体系结构,制定工作计划及资源要求。针对第一阶段需求分析结果,进行设计、代码实现、测试、然后再反馈到需求分析。该阶段结束时第二个重要的里程碑是生命周期结构里程碑,它为系统的结构建立了管理基准并使项目能够在构建阶段进行衡量
- 构建阶段:构建产品并继续演进需求、体系结构、计划直至产品提交。对初始阶段的需求进行设计、代码实现、测试、反馈。重复需求、设计、编程、测试的过程。构建阶段的里程碑是初始功能里程碑,它决定了产品是否可以在测试环境中进行部署。
- 交付阶段:把产品提交给用户使用,综合测试,交付可运行产品。该阶段结束时的里程碑是产品发布里程碑。