免费的seo教程,专注于上海seo做网站建设,刷关键词优化排名,文化公司做网站交文化事业费吗软件过程模型 瀑布模型特点缺点 原型化模型特点两个阶段不同类型注意 螺旋模型V 模型特点 增量模型特点 喷泉模型基于构件的开发模型(CBSD)形式化方法模型敏捷模型特点“适应性” (adaptive) 而非“预设性” (predictive)“面向人的” (People-oriented) 而非“面向过程的” (P… 软件过程模型 瀑布模型特点缺点 原型化模型特点两个阶段不同类型注意 螺旋模型V 模型特点 增量模型特点 喷泉模型基于构件的开发模型(CBSD)形式化方法模型敏捷模型特点“适应性” (adaptive) 而非“预设性” (predictive)“面向人的” (People-oriented) 而非“面向过程的” (Process-oriented) 核心思想主要敏捷方法极限编程XP特点 水晶系列方法并列争球法(Scrum)特征驱动开发方法(FDD)项目角色核心过程 统一过程模型(RUP)生命周期阶段核心工作流循环中的阶段 核心概念特点用例驱动以体系结构为中心迭代与增量 软件过程模型是一种规划和组织软件开发过程的方法。 过程模型通常由一系列阶段和任务组成这些任务在软件开发的不同阶段都有特定的目标。每个阶段都有自己的任务和产出物这些产出物构成了软件开发的不同部分最终汇总成完整的软件产品。
瀑布模型
瀑布模型 (Waterfall Model) 是最早使用的软件过程模型之一包含一系列活动。这些活动从一个阶段到另一个阶段逐次下降它的工作流程在形式上很像瀑布因此被称为瀑布模型。
特点
因果关系紧密相连前一个阶段工作的输出结果是后一个阶段工作的输入。每一个阶段都是建筑在前一个阶段正确实施的结果之上。每一个阶段工作完成后都伴随着一个里程碑(一组检查条件)对该阶段的工作进行审查和确认。
缺点
1软件需求的完整性、正确性等很难确定甚至是不可能和不现实的。 2瀑布模型是一个严格串行化的过程模型使得用户和软件项目负责人要相当长的时间才能得到一个可以看得见的软件系统。 3瀑布模型的基本原则是在每个阶段一次性地完全解决该阶段的工作不会出现遗漏、错误等情况而实际上这是不现实、不可能的。
原型化模型
原型模型 (Prototype Model) 又称快速原型。 由于瀑布型的缺点人们借鉴建筑师、工程师建造原型的经验提出了原型模型。
特点
创建快速原型弄清当前需求。 适用于需求不明确的情况。
两个阶段
原型开发阶段。软件开发人员根据用户提出的软件系统的定义快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌展示目标系统的全部或部分功能、性能等。目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善确认软件系统的需求并达到一致的理解进一步开发实际系统。
不同类型
按照原型的作用不同分为抛弃型原型和演化性原型。 1抛弃型原型是将原型作为需求确认的手段在需求确认结束后原型就被抛弃不用重新采用一个完整的瀑布模型进行开发。 2演化性原型是在需求确认结束后不断补充和完善原型直至 形成一个完整的产品。
注意
用户对系统的认识模糊不清无法准确回答目标系统的需求。要有一定的开发环境和工具支持。经过对原型的若干次修改应收敛到目标范围内否则可能会失败。对大型软件来说原型可能非常复杂而难以快速形成如果没有现成的原型模型就不应考虑用原型法。
螺旋模型
螺旋模型 (Spiral Model) 是在快速原型的基础上扩展而成。也有人把螺旋模型归到快速原型实际上它是生命周期模型与原型模型的结合。 这种模型把整个软件开发流程分成多个阶段每一个阶段都由4部分组成 1目标设定。为该项目进行需求分析定义和确定这一个阶段的专门目标指定对过程和产品的约束并且制订详细的管理计划。 2风险分析。对可选方案进行风险识别和详细分析制定解决办法采取有效措施避免这些风险。 3开发和有效性验证。风险评估后可以为系统选择开发模型并且进行原型开发即开发软件产品。 4评审。对项目进行评审以确定是否需要进入螺旋线的下一次回路如果决定继续就要制订下一阶段计划。
该模型支持大型软件开发适用于面向规格说明、面向过程和面向对象的软件开发方法也适用于几种开发方法的组合。
V 模型
从整体上看V模型就是一个V字结构。 由左右两边组成如下图。
特点
单元测试的主要目的是针对编码过程中可能存在的各种错误集成测试主要针对详细设计中可能存在的问题系统测试主要针对概要设计检查系统作为一个整体是否有效得到运行验收测试通常由业务或专家或用户来进行以确认产品能真正符合用户业务上的需要。V模型适用于需求明确并且需求变更不频繁的情形。
增量模型
首先开发核心模块功能而后与用户确认之后再开发次核心模块的功能。 即每次开发一部分功能并与用户确认最终完成项目开发优先级最高的服务最先交付。
特点
但由于并不是从系统整体角度规划各个模块所以并不利于模块划分。 难点在于如何将用户需求划分为多个增量。 与原型不同的是增量模型的每一次增量版本都可以作为独立可操作的产品而原型的构造一般是为了演示。
喷泉模型
是一种以用户需求作为动力以对象作为驱动的模型适合于面向对象开发方法。
基于构件的开发模型(CBSD)
也称为快速开发模型。 主要是利用预先包装的构件来构造应用系统。 构件可以是组织内部开发的构件也可以是商品化成品软件构件。 特点是增强了复用性。 在开发过程中会构建一个构件库供其它系统复用因此可以提高可靠性节省时间和成本。
形式化方法模型
建立在严格数学基础上的一种软件开发方法。 主要活动是生成计算机软件形式化的数学规格说明。
敏捷模型
软件开发在20世纪90年代受到两个大的因素影响
对内面向对象编程开始取代面向过程编程对外互联网泡沫导致快速投向市场以及公司的快速发展成为关键商业因素。
快速变化的需求需要短的产品交付周期这与传统软件开发流程并不兼容。 2001年2月17位著名的软件开发专家举行了一次敏捷方法发起者和实践者的聚会。在这次会议上正式提出了Agile (敏捷)的概念。
特点
敏捷型方法主要有两个特点这也是其区别于其他方法——尤其是计划驱动或重型开发方法——的最主要的特征。
“适应性” (adaptive) 而非“预设性” (predictive)
软件开发不同于传统工程——如土木工程等——无法将设计和实施分离开来。 一些设计错误只能在编码和测试时才能发现根本无法做出一个交给程序员就能直接编码的软件设计。 软件需求的不稳定导致软件过程的不可预测。 但是必须对这样的过程进行监控以使得整个过程能向期望的目标前进。 敏捷方法使用反馈机制对不可预测过程进行控制。
“面向人的” (People-oriented) 而非“面向过程的” (Process-oriented)
敏捷开发过程要求开发人员必须有权做技术方面的所有决定。开发人员和管理人员在一个软件项目的领导方面有同等的地位共同对整个开发过程负责。敏捷方法特别强调开发中相关人员之间的信息交流。项目的需求是在不断变化的管理人员之间、开发人员之间以及管理人员和开发人员之间都必须不断地了解这些变化对这些变化做出反应并实施在随后的开发过程中。敏捷方法还特别提倡直接的面对面交流。一般都按照高内聚、低耦合的原则将项目划分为若干小组以增加沟通提高敏捷性及应变能力。
核心思想
敏捷方法是适应型而非可预测型。与传统方法不同敏捷方法拥抱变化也可以说它的初衷就是适应变化的需求利用变化来发展甚至改变自己最后完善自己。敏捷方法是以人为本而非以过程为本。强调充分发挥人的特性不去限制它。并且软件开发在无过程控制和过于严格烦琐的过程控制中取得一种平衡以保证软件的质量。迭代增量式的开发过程。敏捷方法以原型开发思想为基础采用迭代增量式开发发行版本小型化。它根据客户需求的优先级和开发风险制订版本发行计划每一发行版都是在前一成功发行版的基础上进行功能需求扩充最后满足客户的所有功能需求。
主要敏捷方法
极限编程XP
极限编程 (Extreme Programming,XP)。 在所有的敏捷型方法中 XP是最引人瞩目的。 极限编程是一个轻量级的、灵巧的软件开发方法同时它也是一个非常严谨和周密的方法。 它的基础和价值观是交流、朴素、反馈和勇气即任何一个软件项目都可以从4个方面入手进行改善加强交流从简单做起寻求反馈勇于实事求是。
特点
XP是一种近螺旋式的开发方法它将复杂的开发过程分解为一个个相对比较简单的小周期通过积极的交流、反馈以及其他一系列的方法开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等并根据实际情况及时地调整开发过程XP提倡测试先行目的是将以后出现BUG的几率降至最低。
水晶系列方法
水晶系列方法(Crystal)与XP方法一样都有以人为中心的理念但在实践上有所不同。 其目的是发展一种提倡“机动性的”方法包含具有共性的核心元素每个都含有独特的角色、过程模式、工作产品和实践。 Crystal 家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程它的发明使得敏捷团队可以根据其项目和环境选择最合适的 Crystal 家族成员。
并列争球法(Scrum)
并列争球法(Scrum)侧重于项目管理。 Scrum是迭代式增量软件开发过程通常用于敏捷软件开发。 Scrum包括了一系列实践和预定义角色的过程骨架(是一种流程、计划、模式用于有效率地开发软件)。 在Scrum 中使用产品 Backlog 来管理产品的需求。 产品 Backlog 是一个按照商业价值排序的需求列表。 根据 Backlog 的内容将整个开发过程被分为若干个短的迭代周期 (Sprint)。 在 Sprint 中Scrum 团队从产品 Backlog 中挑选最高优先级的需求组成 Sprint backlog。 在每个迭代结束时 Scrum 团队将递交潜在可交付的产品增量。 当所有 Sprint 结束时团队提交最终的软件产品。
特征驱动开发方法(FDD)
特征驱动开发方法 (Feature Driven Development,FDD) 是一个迭代的开发模型。 FDD认为有效的软件开发需要3个要素人、过程和技术。
项目角色
FDD定义了6种关键的项目角色 1项目经理 2首席架构设计师 3开发经理 4主程序员 5程序员 6领域专家。 根据项目大小部分角色可以重复。
核心过程
1开发整体对象模型 2构造特征列表 3计划特征开发 4特征设计 5特征构建。 其中计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划设计出包含特征设计和特征构建过程组成的多次迭代。
统一过程模型(RUP)
软件统一过程 (Rational Unified Process, RUP) 描述了如何有效地利用商业的、可靠的方法开发和部署软件是一种重量级过程。 RUP类似一个在线的指导者它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。
生命周期阶段
核心工作流
RUP 软件开发生命周期是一个二维的软件开发模型RUP 中有9个核心工作流具体如下。
业务建模 (Business Modeling)理解待开发系统所在的机构及其商业运作确保所有参与人员对待开发系统所在的机构有共同的认识评估待开发系统对所在机构的影响。需求(Requirements)定义系统功能及用户界面使客户知道系统的功能使开发人员理解系统的需求为项目预算及计划提供基础。分析与设计 (Analysis Dcsign)把需求分析的结果转化为分析与设计模型。实现 (Implementation)把设计模型转换为实现结果对开发的代码做单元测试将不同实现人员开发的模块集成为可执行系统。测试 (Test)检查各子系统之间的交互、集成验证所有需求是否均被正确实现对发现的软件质量上的缺陷进行归档对软件质量提出改进建议。部署 (Deployment)打包、分发、安装软件升级旧系统培训用户及销售人员并提供技术支持。配置与变更管理 (Configuration Change Management)跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。项目管理 (Project Management)为软件开发项目提供计划、人员分配、执行、监控等方面的指导为风险管理提供框架。环境 (Environment)为软件开发机构提供软件开发环境即提供过程管理和工具的支持。
表示核心工作流的术语 Discipline中文意义较多。根据RUP的定义Discipline是相关活动的集合这些活动都和项目的某一个方面有关如这些活动都是和业务建模相关的或者都是和需求相关的或者都是和分析设计相关的等等。
循环中的阶段
RUP 把软件开发生命周期划分为多个循环 (Cycle)每个循环生成产品的一个新的版本每个循环依次由4个连续的阶段 (Phase) 组成每个阶段完成确定的任务。
初始 (inception) 阶段定义最终产品视图和业务模型并确定系统范围。细化 (elaboration) 阶段设计及确定系统的体系结构制订工作计划及资源要求。构造 (construction) 阶段构造产品并继续演进需求、体系结构、计划直至产品提交。移交 (transition) 阶段把产品提交给用户使用。
每一个阶段都由一个或多个连续的迭代 (Iteration) 组成。 迭代并不是重复地做相同的事而是针对不同用例的细化和实现。 每一个迭代都是一个完整的开发过程它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果适当地对核心工作流中的行为进行裁剪。 在每个阶段结束前有一个里程碑 (Milestone) 评估该阶段的工作。如果未能通过该里程碑的评估则决策者应该做出决定是取消该项目还是继续做该阶段的工作。
核心概念
RUP 中定义了如下一些核心概念理解这些概念对于理解RUP很有帮助。
角色 (Role)Who 的问题。角色描述某个人或一个小组的行为与职责。 RUP预先定义了很多角色如体系结构师 (Architect)、 设计人员 (Designer)、 实现人员(Implementer)、 测试员 (tester) 和配置管理人员 (Configuration Manager) 等并对每一个角色的工作和职责都做了详尽的说明。活动 (Activity)How 的问题。活动是一个有明确目的的独立工作单元。制品(Artifact)What 的问题。制品是活动生成、创建或修改的一段信息。也有些书把 Artifact 翻译为产品、工件等和制品的意思差不多。工作流 (Workflow)When 的问题。工作流描述了一个有意义的连续的活动序列每个工作流产生一些有价值的产品并显示了角色之间的关系。
RUP 2003对这些概念有比较详细的解释并用类图描述了这些概念之间的关系除了上述这4个核心概念外还有其他一些基本概念如工具教程 (ToolMentor)、 检查点 (Checkpoints)、 模板 (Template) 和报告 (Report) 等。
特点
RUP 是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。
用例驱动
RUP中的开发活动是用例驱动的即需求分析、设计、实现和测试等活动都是用例驱动的。
以体系结构为中心
RUP中的开发活动是围绕体系结构展开的。 软件体系结构的设计和代码设计无关也不依赖于具体的程序设计语言。 软件体系结构是软件设计过程中的一个层次这一层次超越计算过程中的算法设计和数据结构设计。 体系结构层次的设计问题包括系统的总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配功能、设计元素的组织、物理分布、系统的伸缩性和性能等。 对于一个软件系统不同人员所关心的内容是不一样的。 因此软件的体系结构是一个多维的结构也就是说会采用**多个视图 **(View) 来描述软件体系结构。 RUP采用“41”视图模型来描述软件系统的体系结构如下图所示。
迭代与增量
RUP强调采用迭代和增量的方式来开发软件把整个项目开发分为多个迭代过程。 在每次迭代中只考虑系统的一部分需求进行分析、设计、实现、测试和部署等过程。 每次迭代是在已完成部分的基础上进行的每次增加一些新的功能实现。 以此进行下去直至最后项目的完成。 软件开发采用迭代和增量的方式有以下几种优点 1在软件开发的早期就可以对关键的、影响大的风险进行处理。 2可以提出一个软件体系结构来指导开发。 3可以更好地处理不可避免的需求变更。 4可以较早得到一个可运行的系统鼓舞发团队的士气增强项目成功的信心。 5为开发人员提供一个能更有效工作的开发过程。
