首页>
动态系统开发方法(DSDM),也称业务中心框架开发方法,是众多敏捷开发方法中的一种,它倡导以业务为核心,快速而有效地进行系统开发。我们可以把DSDM看成种控制框架,重点在于快速交付、并补充如何应用这些控制的指导原则的框架。
DSDM描述了在快速开发以业务为中心的环境中包含的各个方面—一项目管理、预估、原型建立、时光盒法、配置管理、测试、质量保证、角色和职责、项目组结构、工具环境、风险管理、可维护性、重用,以及供货商和购买者之间的关系。DSDM的基本观点是,任何事情都不可能一次性地圆满完成,应该用20%的时间完成80%的有用功能,以适合商业目的为准。实施的思路是,在时间进度和可用资源预先固定的情况下,力争最大化地满足业务需求(传统方法一般是需求固定,时间和资源可变)交付所需要的系统。对于交付的系统,必须达到足够的稳定程度以在实际环境中运行;对于业务方面的某些紧急需求,也要求能够在短时间内得到满足,然后在以后冲刺阶段中对功能进行进一步完善。
1.DSDM的历史背景
20世纪90年代,T业为了弄清楚应用程序开发的流程并归纳出避免失败的方法,进行了一系列的尝试。1994年,英国国内来自各个工业领域不同规模企业的信息系统工作人员,以及来自T行业中的一些大公司的顾问和项目经理聚集在一起,形成了一个非营利性的联盟—DSDM联盟。该联盟专注于理解应用程序开发过程中的最佳实践方法,并尝试建立一种独立于任何工具的、公开的、公认的方法。DSDM联盟提供了一个过程,这个过程能够在可控的项目环境中,在满足紧迫时间的约束下,建立和维护系统。DSDM联盟创立之初有17名会员。现在联盟已经有上千名会员,全球范围内的多个国家都有其社团:英国、北美、比荷卢经济联盟、丹麦、法国和瑞典。社团式的发展,是DSDM与其他一些敏捷型方法的不同,它有专门的组织支持,有手册、培训课程、认证程序等。在英国,由于在各种规模的软件组织中的成功,DSDM已经成为应用得最为广泛的快速软件开发方法。
DSDM一直处于改进和变化之中,其重点内容通过会员的反馈不断修改、更新,以适应当今市场的变化。2001年,DSDM联盟发布了以业务为中心的开发框架DSDM4.1版本,并将DSDM应用到更多的项目—数据仓库、组件开发、原形业务法中,在框架中都增加了这些内容。
2.DSDM过程
DSDM开发过程被形象地称作“两张比萨和一块奶酪”,如图下图所示。
DSDM周期有以下7个阶段：
1)、项目准备阶段。
2)、可行性研究阶段。
3)、业务研究阶段。
4)、功能建模阶段(冲刺式)
5)、系统设计编程阶段(冲刺式)。
6)、实施阶段
7)、项目后期。
项目准备阶段确保启动、建立正确的项目。可行性研究阶段和业务研究阶段是顺序进行的,它们为后面的冲刺、增量式的开发制定了基本规则。也就是说,在这两个阶段的工作充分完成后,才能进入后面的冲刺阶段,而后续冲刺阶段具体的冲刺方式、冲刺周期如何确定、整合,则需要视项目具体情况来定。比如:有些项目需要首先完成功能建模的全部冲刺,其次进入设计和编码阶段进行冲刺,最后进入实施阶段,这种方式是顺序的,是各阶段内部独立完成冲刺;有些项目将功能建模、设计和编码这两个阶段的每一次相关的活动作为一次冲刺,通过不断地冲刺,完成项目开发,最后进入项目实施;有些项目将功能建模、设计和编码、实施这一个过程作为一次冲刺,通过不断地冲刺,不断地呈现给用户满足他们需求的软件。因此,DSDM框架是极其灵活的,在应用DSDM之前,必须定义和评估使用DSDM的方式,在项目过程中,也可以随需而变,进行动态调整,以便能够更好地支持商业需求。DSDM“动态系统开发方法”的名称可能也是由此得来的吧!
DSDM的可行性研究阶段主要侧重评估DSDM方法是否适用于本项目,笔者认为这点比较与众不同,因为在很多的可行性研究结果中,已经把瀑布模型默认为软件开发方法了。在可行性研究阶段需要得到一些结论:“该系统技术上可行吗?”“对当前业务流程带来的影响可接受吗?”“DSDM是开发这个系统最好的方法吗?”……必须把这些问题弄清楚,以便确定“这样去做值得吗”。然后需要制定一份全面的可行性报告,对于风险很高的方面,还需要提供应对和控制风险的策略。除了可行性报告之外,还需要提供开发的框架计划( Outline Plan),证明预期的结果是可实现的。另外,也可以提供一个快速原型,目的是证明项目从技术上是可行的。当然,如果对业务已经有了一定程度的理解,相应的技术也已经用过,那么生成原型的价值也就不大了,可以不需要。DSDM的哲学就是:“足够就好,无须过多!”
业务研究阶段主要是对业务流程进行分析和定义。首先需要开展一系列的讨论会,对业务流程及其相关信息、用户群进行定义,这些定义的结果被称作业务区定义,经过管理层同意后,需要从使用业务的用户群中选出代表参与到开发过程中。其次在进行业务区定义时,可以采用结构化分析方法,定义主要的数据流程图;也可以采用面向对象的方法,定义重要的用户案例。对于业务区定义的功能,必须区分出是功能性需求还是非功能性需求并且划分优先级,因为DSDM是以业务为导向的,所有制定优先级的原则也必须要以业务为导向,但是也需要从技术实现需要的角度来考虑,把技术上要求先实现的功能作为高优先级。这样就可以清晰地理解需要开发的功能和它们实现的优先级,从而引导我们对系统架构的定义,系统架构定义实际上定义了软件开发、运行的平台,软件模块和接口的结构。最后,根据可行性研究阶段的开发框架计划和业务区定义可以制订出开发计划,这个开发计划应该包含功能建模阶段和设计编程阶段的开发策略、测试策略和配置管理计划。
功能建模阶段主要是深入分析业务区定义的功能并进行细化,在分析模型的基础上构建软件模块,将创建的原型交付用户评审,经过用户评审后进一步充实和改进,这样经过不断冲刺,原型逐渐演化成可工作的软件。在功能建模阶段,还会产生以下产物。
1)、带有优先级的功能。随着业务的细化,业务研究阶段定义的优先级需要调整,从而保证本次冲刺中包含用户最需要的核心功能。
2)、功能性原型的评审文档。用户每次对原型评审时提出的改进建议都需要被记录下来,并需要根据这些评审结果对业务定义、建模进行修正。
3)、非功能性需求。在功能建模阶段对非功能需要也需要记录下来。(但是,这里会出现一个问题:因为在前期建模阶段,主要注重了对业务流程的分析建模和对高优先级需求的原型实现,倡导快速实现、交付用户评审,因此,这个过程一直注重功能性需求,对于性能方面关注不多,因为无法从全局考虑,并更深入地考虑到整个系统的性能瓶颈,特别是前期架构设计若存在缺陷将导致后期出现性能隐患,这是很难解决的;另外,若前期冲刺功能与后期冲刺关联功能存在性能制约,也存在一定风险。因此,在这一阶段,进行建模时也必须要考虑到各种可能的性能需求的技术实现,并且也需要制定优先级,在不同的冲刺中处理必要的性能需求。)
4)、实施计划。在功能建模阶段,就应该规划这一阶段的实施计划了。包括业务方案的准备,培训用户的计划,各种知识、技能的准备。
设计编程阶段主要根据功能建模的标准建造实际系统并通过测试。这里的测试和瀑布模型的测试是不同的,它不是一项单独活动,测试应该是贯穿于整个功能建模和设计编码过程的。实施阶段主要是培训用户,完成系统从开发环境向运行环境的交接,然后评估这一阶段哪些需求做完了,下一阶段需要做哪些工作。有时候开发环境(包括测试环境)不可能完全仿真用户运行环境,因此在系统移交过程中,也可能会出现一些实施问题;另外,在这个阶段,部分隐藏的系统性能问题也可能会暴露出来,也需要关注。项目后期应评审当前使用的方案并评估是否达到预期的效果。
广州慧翔企业管理咨询有限公司 专注，所以我们更专业！
优培东方官网 http://www.hxtdpx.com
粤公安备案 44010602008731号