|
编者按：越来越多的压力使得一个软件项目无论是最终用户、企业、开发团队都希望在最短的时间完成，可事与愿违的是软件项目的时间延期问题普遍存在，一些调查表明，70%的项目超出了估算的时间。大型项目平均超出计划交付时间的20%到50%，项目越大，超出计划的时间越长。一直以来开发速度的问题都是软件开发业的头等问题。那怎样才能在保证软件质量的同时又缩短开发速度呢？本期的《领航人》月刊中我们就将围绕着有关软件的“快速开发”主题来进行探讨。 开发软件所需要经历的阶段 要谈“快速开发”我们就需要先来了解一下软件项目所需要经历的过程： 软件的开发过程并不仅是一个编写、实现代码的简单过程，软件的开发需要经历许多的步骤。因此在开始时我们先用一个相对简单的 方式了解一下软件开发的常见过程： 从上图可以直观的看出，一个软件的开发至少是包含了上图的三个阶段、七个步骤。 而这个过程中又可能涉及到下列各种参与软件开发的角色： ［并不是任何项目中都会出现所有角色，角色同实际的参与人员也并不一定一一对应］ 我们在此所探讨的软件“快速开发”为的是在软件目标、外部资源相同的情况下（如：同一团队，同一项目）可以缩减整个开发周期的各种方式，使软件项目最终能在一个更短时间内完成。 能缩短软件开发周期的三种方式 缩短软件开发周期其实一直是全世界软件开发团队所长期关注的话题，把现在已被广泛认可的有效缩短周期的方式归类一下可划分为三大类： 1. 工具快速 2. 模式快速 3. 经验快速 其分别代表着实现软件项目“快速开发”的“天时、地利、人和”，同时也蕴藏着“天时不如地利，地利不如人和”的真谛。 天时——工具快速 在一个软件项目所经历的各阶段中（如：⑴需求分析、⑵原型开发、⑶实现、⑷测试、⑸完成、⑹需求变更、⑺后期维护），不同阶段选用适当的工具能非常直接的相应参与人员的工作效率、沟通效率，缩短单个步骤所需要的时间，从而在整体上缩短软件项目的开发周期。值得注意的一点是，工具并不仅限于软件形态的工具。 ⑴需求分析：是软件项目开发第一个也是很重要的一个阶段， 需求分析的基本任务是要准确地定义新系统的目标，为了满足用户需要，回答系统必须“做什么”的问题。 在这个阶段中包含需要获取需求、分析需求、编写规格说明和需求验证。从获取需求到需求验证的这个过程需要编写文档、绘制图形、创建需求模型等，像文档之类的工具可以使用word、绘制图形可以使用visio、建模可以使用rational rose等工具软件，有了这些工具的辅助，可提高编写文档的速度，缩短分析阶段的周期。除了以上这些软件形态的工具外还可为更快的项目参与人员之间的想法沟通，借助一些实体类工具，如纸制卡片，黑板或一些已经成型的系统。 ⑵原型开发：在软件需求分析阶段，需要搞清楚的是软件要“做什么”的问题，并把这些需求通过文档的形式描述出来，这也是目标系统的逻辑模型。进入设计阶段，则要把软件“做什么”的逻辑模型变换为“怎么做”的物理模型，即着手实现软件的需求，并将设计的结果反映在“设计规格说明”文档中，接下来开始设计。设计的基本任务包括：软件结构、数据结构及数据库设计、概要设计文档。开发一个大而复杂的软件系统，我们可以将它进行适当的分解来降低其复杂性，还可减少开发工作量，你也可以使用一些能够提高设计速的软件来帮助你进行设计，从而提高软件生产率，降低开发成本。所用的工具比如使用UML绘制类图的工具。 ⑶实现：设计完成之后进入编码实现阶段，为了提高整个项目的开发速度，编写代码我们可以借助一些有力的开发工具来加快速度，例如，如果是用JAVA语言开做开发的话，可以使用eclipse、JCreater，如果是用C#、VB你可以用Visual Studio.net；如果是开发网站之类的可以用Dreamweaver。美工可以使用photoshop或是FireWork之类的工具。节省项目的开发时间。另外一方面由于软件技术的快速发展带来了各种平台和引擎，选用适当的平台技术与引擎能更大程度的缩短周期。 ⑷测试：软件的测试也是一个非常重要的阶段，大量的测试，甚至重复的测试引出了一个新的问题：全凭手工进行测试会浪费大量的时间。因此，易变的需求对测试提出了一个新的要求：自动化测试。此类型的工具例如Xunit系列。只有自动化的进行测试，才可以完成大量的测试工作，节省时间和人力方面的投入，加快项目的整体开发速度。关于自动化测试这方面的问题，大家可以参考相关的资料，这里我们不作深入的讨论。 工匠用钉枪、成型砖块、涂料喷雾器来建造一个小屋的话要比他单纯用一把榔头、沙砖、涂料刷来得快。拥有快速交通工具的人可以比拥有普通交通工具的人提前到达目的地。但不论什么情况下，如果质量是非常重要的话，那么即使是强有力的工具也将会被手工工具所替代或辅助。软件开发中使用工具的情况与上述情况也是非常相近的。 地利——模式快速 如前所说软件开发的过程并不是一个简单的过程，一个软件的开发会被分成很多步骤来实现，每一个步骤都有自己的起点和终点。也正如此使得开发过程中的每个步骤起点和终点在不同的软件项目中出现不同难度的“坎”，使其难于达到该步骤开始或是终结的条件，开发过程也就不会一帆风顺。 不同的开发模式其实就是将步骤的起点和终点重新定义，甚至重新组合排列，虽然任何一个开发模式最终目的都是完成软件项目的开发，但期间所经历的过程不一样，过程步骤之间的起点和终点的的定义不同所带来的“坎”也就不一样，项目周期自然各不相同，因此，根据软件项目的实际情况选择一个适合的开发模式能减少开发周期中“坎”的出现次数与难度，非常大程度的缩短开发周期。 瀑布模型 在本专题开始时我们所示范的开发流程，实际就是一种典型的瀑布模型（又称线形模型）： 瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型，在瀑布模型中，开发被认为是按照需求分析，设计，实现，测试 (确认)， 集成，和维护坚定地顺畅地进行。 在最初的文章中，Royce提倡重复地使用瀑布模型，以一种迭代的方式。但是，大多数人并不知道这一点，一些人也不相信它能够作为一种真实世界的过程使用。在实践中，过程很少能够以纯线性的方式进行。 通过回到前面的阶段或改便前一阶段的结果的迭代是非常普遍的。 线性模型太理想化，太单纯，以至很多人认为瀑布模型已不再适合现代的软件开发模式，几乎被业界抛弃。偶而被人提起，都属于被贬对象，未被留一丝惋惜。但我们应该认识到，“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。 瀑布模型解决了软件工程上面的基本管理需求，但是对于我们所提的软件项目的“快速开发”瀑布模型并没有什么优势。 2．RUP（Rational Unified Process 瑞理统一过程） RUP是建立在非常优秀的软件工程原则基础上的，例如迭代，需求驱动，基于结构化的过程开发。它提供了几个方法，例如每一次迭代产生一个工作原型，在每一个阶段的结束决定项目是否继续，这些方法提供了对开发过程的非常直观的管理。RUP采用了万维网技术，可以增强团队的开发效率，并为所有成员提供了最佳的软件实现方案。 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） 下面是极限编程的有效实践： 1. 完整团队 XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。 2. 计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。 1. 客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。 2. 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 3. 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。 4. 测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。 5. 改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。 6. 持续集成团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。 7. 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。 8. 编码标准 系统中所有的代码看起来就好像是被单独一人编写的。 9. 隐喻 将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。 10. 可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。 极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。 4.NoahWeb"增量迭代"模式 以RUP和极限编程中的增量所不同的的是NoahWeb“增量迭代”模式仅适用于B/S软件项目。考虑B/S项目中的人员配置、工作重心与C/S项目截然不同的特殊性，因此该模式专门针对B/S项目而提出。 从以往的很多B/S应用开发案例来看，用户的需求并不会在需求分析阶段和原型开发阶段就可以准确获得，往往在应用系统接近发布时，用户才会提出各种各样具体的需求。 
[B/S应用开发过程中各阶段中用户需求变化图] 导致这样的原因很简单：在需求分析阶段，最终用户不可能通过开发文档就能想象出应用系统运行时的实际情况，而系统接近成型时，用户通过真实使用会感觉到系统存在的问题和设计缺陷。由于用户需求在发布前频繁变更这一特性，使用传统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“增量迭代”开发模式的各步骤特点如下： · 用“迭代”探索需求 o 需求分析阶段： 设计人员关注的不是程序结构设计，而是用户流程，在需求分析阶段就可以邀请用户一起参与“动作分解图”的设计，让用户从一开始就可以感受到软件使用的流程，让所开发的软件从一开始就贴近用户需求； · 原型阶段： 原型阶段将整个软件项目的数据输入界面和输出按照动作流程呈现给用户，让用户可以直观的从输入输出的具体细节体验软件，反馈修改意见，让开发的软件再次贴近需求。 · 实现阶段 在此阶段，还可以让用户通过至少两个阶段性的演示让用户体会软件的流程和真实的数据输入输出，体验真实的软件使用感觉，为项目开发团队反馈出更准确的需求。 · 发布阶段 在发布阶段软件已经能非常贴近最终用户需求，即使发布后更意外的需求变更，也能轻松应变。 使用该模式项目实施B/S项目的效果将很大程度上区别于其他模式效果。软件项目的开发中需求分析与编码实现已经被融为一体，而且在开发的任意阶段，开发人员都已经准备好应付后续阶段可能出现的任何变化。变化成为计划一部分。
| 
