用例设计在软件开发项目计划中的应用

前言

软件开发项目计划为项目管理服务的，本文用项目管理的眼光去看待项目计划的内容。应用本文的方法制定的项目计划可以：
1. 让项目的时间、成本、进度的估算可以通过简易的公式进行一次性计算得到
2. 让不了解项目实现技术的人，如客户、投资者、管理者及愿意了解项目的人员很容易地了解项目的时间、成本、进度的状态及其完工估算
3. 让项目工作量的分配更具体、更客观，对成员的绩效表现显而易见
4. 使项目之间的工作绩效具有可比性

实例

一般情况下我们的项目计划是这样的：
1. 第一层是项目开发的实际阶段
2. 第二层是所在阶段的工作
3. 第三层是对较大工作量的工作做进一步分解

问题

这样的计划有以下几个缺点：
1. 不适应迭代开发的工作模式。多数应用软件的开发不是纯粹“瀑布开发模型”，当到达后面的阶段时，不可避免的发现以前阶段的工作没有真正完成，需要继续进行。例如，设计阶段时，极有可能会发现分析需求阶段中漏了一个功能没有考虑进去，以致分析需求阶段没有真正完成而需要继续。
2. 计划的实际执行数据不能作为项目的完成估算的依据。 比如调研和需求确认阶段完成时，依据该阶段的实际执行数据不能预知项目将在什么时间结束，在什么成本范围完成。有以下几个原因：
1) 阶段本身的界限是不清晰的
2) 阶段之间的时间、成本、进度的分配关系并不确定
3. 这些估算数据难以被以后的开发计划所借鉴。当一个项目或一个阶段结束后，我们总会想在这个已执行完成的计划的上面得到一点关于估算方面的经验或教训，如：
1) 这个项目的总开发成本与其他项目相比，是多了还是少了？
2) 设计分析阶段的时间分是不是不与项目的需求不匹配？
3) 哪个阶段的成本分配有问题？
4) 各项工作的平均时间合不合适？
按上面的计划，我们不能够很好的回答这些问题，是因为这个计划是按阶段来划分的，实际工作中，这些阶段的界限并不明显，无法得到准确的数据。
4. 当需求变更时，不知把这些变更的工作放入项目计划的哪个阶段。因为这些变更往往包含了很多的阶段。有人建议把它们放到一个叫做“需求变更”的特殊阶段中，但这些变更是不可预知的，它几乎分布到项目的整个开发过程中，我们又如何在计划是反应它们呢？

实际过程

在介绍本文的方法以前，了解RUP(rational unified process) 的朋友，知道软件开发过程并不是我们想象的如此简单。它告诉我们在同一个时间内所有的开发阶段是有可能共存的。也是说整个开发过程可以是多个迭代同时进行。
我们回顾一下日常的开发过程：
1. 得知有一个项目需要开发。有可能是老板告诉你的，也可能是业务部门告诉你的，总之我们要为它而工作了，同时确信老板同意开始这个项目
2. 对这个项目涉及的人员及其需求进行调查。这里的需求包括了所有项目的需求，比如老板对这个项目的要求及期望，用户对这个项目的期望，开发人员对这个项目的期望。这时，我们很快会发现，调查所有人是不可能的，调查所有需求也是不可能的。因此，
1) 我们会先找几个关键人物，了解他们的期望，确定系统的边界（或叫轮廓，XP(Extreme Programming)中把它叫系统隐喻）；
2) 再把系统划分为几个部分，确定先做哪个部分后做哪个部分；
3) 再一个一个部分对需求进行调查
当我们在调查的时候，常常会发现新的部分之间的关联，这使我们不得不对这两个部分的内容进行检查，加的加，改的改，删的删。
3. 基于调查的结果进行设计。这个时间，我们经过对这些需求的分析、归类，设计一个开发的模型以支持这些需求。设计时也免不了会发现需求不对的地方，对需求进行加的加，改的改，删的删。
4. 基于设计的结果进行编码、集成。也免不了会发现设计、需求不对的地方，对需求进行加的加，改的改，删的删。
5. 基于编码的结果进行测试，以验证软件是否达到了需求。我们常常发现这时的需求与设计之前的需求已有了很大的变化。
6. 发布（部署）产品，进行项目收尾。
如果某一时间，客户要知道项目进行到哪了，我们告诉他设计已完成，正进行编码工作。当有需求变更时，相关的需求、设计又要来过。客户能不怀疑我们的回答么？

解决方法

做过软件开发的人就会知道，上面的过程描述中有很大的问题。我们的做过程并没有错，一个一个需求，一个一个功能的实现，有变更时就一个一个变更的实现，大家都这样做，也只有这样做。对于一个应用软件项目来讲，而不太可能真正的按软件书上写的过程一个一个过程的做下去，集中10天做完所有的需求，集中20天内做完所有设计。
做的过程没有错，把过程描述出来，为什么就错了？原因很简单：我们在描述时，总喜欢套用一些“模式”，一些书写的“方法”，而不是按实际的过程描述。如果我们不套用任何模式，将会如何呢？我们再来描述一遍上面的过程：
1. 了解软件项目的故事（story）。开始一个软件应用项目，了解关键人物都有哪些？他们要求是一个什么样的系统？把这些要求描述成一个一个的故事，如果稍稍规范一点。就会象这样：
1) 这个系统的目标是为了谁解决什么问题
2) 第一步做什么，系统反馈什么
3) 第二步做什么，系统反馈什么
4) …
5) 问题解决了，结束本故事
我们会仔细的看这些故事，发现有些地方看不懂，于是我们就去问清楚，有些事情是那个描述故事的A也不清楚的，但A告诉我们B会懂，于是我就问B；有些事情A也不知道有谁会知道，我们就把它放在一边，等知道的时候再问，继续看其他的故事。
2. 了解系统隐喻，构造软件框架。永远也问不清楚所有的事情，所以当我们知道整个系统的是为了解决什么问题，将用什么办法来解决它（暂时叫做系统隐喻），关键人物也认可时，我们就不再问下去了。我们依据这个系统隐喻去构造一个最上面的故事。然后，只关心与这个故事有关的故事。同时构造一个程序框架以支持项目的开发
3. 实现故事。在软件框架上，实现一个故事，再实现一个故事，…
4. 实现变更。有时发现事情并没有想象的简单，于是就变更它，这就要求我们实现这些次变更。它象实现故事一样：实现一次变更，再实现一次变更，…

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有