地利——模式快速 如前所说软件开发的过程并不是一个简单的过程,一个软件的开发会被分成很多步骤来实现,每一个步骤都有自己的起点和终点。也正如此使得开发过程中的每个步骤起点和终点在不同的软件项目中出现不同难度的“坎”,使其难于达到该步骤开始或是终结的条件,开发过程也就不会一帆风顺。 不同的开发模式其实就是将步骤的起点和终点重新定义,甚至重新组合排列,虽然任何一个开发模式最终目的都是完成软件项目的开发,但期间所经历的过程不一样,过程步骤之间的起点和终点的的定义不同所带来的“坎”也就不一样,项目周期自然各不相同,因此,根据软件项目的实际情况选择一个适合的开发模式能减少开发周期中“坎”的出现次数与难度,非常大程度的缩短开发周期。 瀑布模型 在本专题开始时我们所示范的开发流程,实际就是一种典型的瀑布模型(又称线形模型): ![](https://i-blog.csdnimg.cn/blog_migrate/f3eca3595c94194902de0e3570c78b42.png) 瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,在瀑布模型中,开发被认为是按照需求分析,设计,实现,测试 (确认), 集成,和维护坚定地顺畅地进行。 在最初的文章中,Royce提倡重复地使用瀑布模型,以一种迭代的方式。但是,大多数人并不知道这一点,一些人也不相信它能够作为一种真实世界的过程使用。在实践中,过程很少能够以纯线性的方式进行。 通过回到前面的阶段或改便前一阶段的结果的迭代是非常普遍的。 线性模型太理想化,太单纯,以至很多人认为瀑布模型已不再适合现代的软件开发模式,几乎被业界抛弃。偶而被人提起,都属于被贬对象,未被留一丝惋惜。但我们应该认识到,“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。线性是一种简洁,简洁就是美。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。 瀑布模型解决了软件工程上面的基本管理需求,但是对于我们所提的软件项目的“快速开发”瀑布模型并没有什么优势。 ? 2.RUP(Rational Unified Process 瑞理统一过程) RUP是建立在非常优秀的软件工程原则基础上的,例如迭代,需求驱动,基于结构化的过程开发。它提供了几个方法,例如每一次迭代产生一个工作原型,在每一个阶段的结束决定项目是否继续,这些方法提供了对开发过程的非常直观的管理。RUP采用了万维网技术,可以增强团队的开发效率,并为所有成员提供了最佳的软件实现方案。 ![](https://i-blog.csdnimg.cn/blog_migrate/11dcb1fe0cab962bfb601f05fb875a80.png) RUP处理过程为软件开发提供了规定性的指南、模板和范例。它可以通过提供一个应用于整个软件开发周期的、可定制的最佳开发方案架构,RUP可以对整个开发小组的工作进行指导和安排。RUP将项目管理、商业建模、需求管理、分析和设计、测试以及变更控制等,统一到了一个一致的、贯穿整个开发周期的处理过程。 RUP正如其名,它使团队中每个开发人员的见解和思想得到统一,使开发小组成员的沟通更为容易,而这正是任何项目要取得成功的关键因素;它增强了开发人员对软件的预见性,最终的好处就是提高了软件质量,并有效缩短了软件从开发到投放市场的时间,全面提高了开发速度。 RUP是严格按照行业标准UML开发的,它的特点主要表现为如下六个方面:
- 开发复用。减少开发人员的工作量,并保证软件质量,在项目初期可降低风险。
- 对需求进行有效管理。
- 可视化建模。
- 使用组件体系结构,使软件体系架构更具弹性。
- 贯穿整个开发周期的质量核查。
- 对软件开发的变更控制。
RUP可以缩短软件项目的开发周期,实现大型项目的快速开发,对于中小型项目RUP就显的过于庞大,其需要投入的成本也很非常观。 3.敏捷开发,极限编程 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟。敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme Programming,简称XP)。 极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合,使软件能以尽可能快的速度开发出来并向客户提供最高的效益。XP在很多方面都和传统意义上得软件工程不同,同时,它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。 XP具有12个过程,只有完全使用12个过程才是真正使用了XP,只是简单使用了其中一个方法并不代表使用了XP。
- 现场客户(On-site Customer)
- 计划博弈(Planning Game)
- 系统隐喻(System Design)
- 简化设计(Simple Design)
- 集体拥有代码(Collective Code Ownership)
- 结对编程(Pair Programming)
- 测试驱动(Test-driver)
- 小型发布(Small Release)
- 重构(Refactoring)
- 持续集成(Continous integration)
- 每周40小时工作制(40-hour Weeks)
- 代码规范(Coding Standards)
? 下面是极限编程的有效实践:
- 完整团队 XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
- 计划游戏计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
- 客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
- 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。
- 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
- 测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。
- 改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。
- 持续集成团队总是使系统完整地被集成。一个人拆入(Check in)后,其它所有人责任代码集成。
- 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。
- 编码标准 系统中所有的代码看起来就好像是被单独一人编写的。
- 隐喻 将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。
- 可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。 极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。
? 4.NoahWeb"增量迭代"模式 以RUP和极限编程中的增量所不同的的是NoahWeb“增量迭代”模式仅适用于B/S软件项目。考虑B/S项目中的人员配置、工作重心与C/S项目截然不同的特殊性,因此该模式专门针对B/S项目而提出。 从以往的很多B/S应用开发案例来看,用户的需求并不会在需求分析阶段和原型开发阶段就可以准确获得,往往在应用系统接近发布时,用户才会提出各种各样具体的需求。 ![](https://i-blog.csdnimg.cn/blog_migrate/0c2f559041f9c691e054c8e76f75071d.png) [B/S应用开发过程中各阶段中用户需求变化图] 导致这样的原因很简单:在需求分析阶段,最终用户不可能通过开发文档就能想象出应用系统运行时的实际情况,而系统接近成型时,用户通过真实使用会感觉到系统存在的问题和设计缺陷。由于用户需求在发布前频繁变更这一特性,使用传统B/S解决方案的设计人员和开发人员将会此阶段面临需求变更的各种考验,项目周期和开发成本也会在发布阶段由于需求变更急剧扩大,有时甚至可能之前工作推倒从来。
B/S项目以往一直采用同C/S软件项目一样的开发模式和流程管理。但由于B/S项目同C/S项目太多的不同之处,使得B/S项目开发周期很难控制。B/S一方面要面临着需要短时间获取需求,需求不明确。另一方面B/S开发中美工和界面设计美化的重要性也不同于C/S项目,B/S项目往往由美术和程序两方面的人员来决定需求并且相互制约,这些巨大区别似的不能将B/S项目等同与C/S项目来进行管理。 NoahWeb“增量迭代”开发模式的各步骤特点如下:
设计人员关注的不是程序结构设计,而是用户流程,在需求分析阶段就可以邀请用户一起参与“动作分解图”的设计,让用户从一开始就可以感受到软件使用的流程,让所开发的软件从一开始就贴近用户需求;
原型阶段将整个软件项目的数据输入界面和输出按照动作流程呈现给用户,让用户可以直观的从输入输出的具体细节体验软件,反馈修改意见,让开发的软件再次贴近需求。
在此阶段,还可以让用户通过至少两个阶段性的演示让用户体会软件的流程和真实的数据输入输出,体验真实的软件使用感觉,为项目开发团队反馈出更准确的需求。
在发布阶段软件已经能非常贴近最终用户需求,即使发布后更意外的需求变更,也能轻松应变。
使用该模式项目实施B/S项目的效果将很大程度上区别于其他模式效果。软件项目的开发中需求分析与编码实现已经被融为一体,而且在开发的任意阶段,开发人员都已经准备好应付后续阶段可能出现的任何变化。变化成为计划一部分。 更多有关NoahWeb“增量迭代”开发模式的详细介绍,可查看:
? ? |