二需求分析与项目管理.docVIP

第二章 需求分析与项目管理 构架师的工作很大程度上要和需求分析与项目管理结合，前面已经谈到，发现架构因素主要依赖于需求分析，所以，一个架构师对于需求分析和项目管理必须有透彻的理解，下面我们来讨论有关问题。 第一节 迭代开发和统一过程 一、IT管理面临的问题 1、预测性过程及其不可靠性 软件开发过程描述的软件构造、部署还有维护的一种方法， 早先的方法是顺序的、线性的或“瀑布”的生命周期，最常见的步骤如下： 1）澄清、记录和承诺一组完整的已经冻结的需求。 2）设计基于这个需求的一组系统。 3）基于设计，实现系统。 这种开发过程被称之为预测性过程，而在项目开发的初始阶段，预测项目未来的走势，是一个不可靠甚至几乎不可能的事情。 2、“瀑布”或顺序生命周期带来的问题 “瀑布”或顺序生命周期带来的主要问题是，需求总是在变化的，而软件总是需要不断升级的。 一个关于影响项目进展的因素的研究如下图。 （Jim Johnson 1994 Chaos:Charting the Seas of Information Technology. Published Report .The Standish Group） 可见37%的问题都与需求有关，这就需要“需求管理”，而需求的变化是绝对的，而且是永远存在的。 在瀑布式生命周期之下，在项目的第一阶段，在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来，并且实际开发前冻结需求，但历史证明这种方式是失败的，在项目很大的时候，冻结需求几乎没有可能。 软件架构设计的一个核心的问题就是，在需求不断变化的状况下，我们的架构和项目管理，如何适应这种变化呢？ 为此，人们提出了统一过程这种观念。 二、迭代开发和统一过程 统一过程（UP），是一种流行的构造面向对象系统的软件开发过程，特别是Rational统一过程（RUP），是对统一过程的详细精化，并已经被广泛采纳。 统一过程，事实上是把需求分析、架构设计以及类设计全部统一在面向对象的观点之下，用统一的方法来处理全部问题。 统一过程（UP）把普遍接受的最佳实践（迭代生命周期和风险驱动开发），合并为内聚和具有良好文档的过程描述。 而迭代开发是在统一过程中最有价值的实践，它是软件开发的一种巧妙的方法。 MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一个为时两年对成功软件项目的研究报告指出，软件项目获得成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。 （其它的因素是： 2，至少每天把新代码合并到整个系统，并且通过测试，对设计变更做出快速反应。 3，开发团队具备运作多个产品的工作经验。 4，很早就致力于构建和提供内聚的架构。 这四个因素中有三个在UPO中有显式的实践。） UP提倡了几种最佳实践，但只有一个最佳实践，那就是迭代开发。 什么是迭代开发？ 1）开发被组织成一系列固定的短期（如四个星期）小项目，称为迭代。 2）每次迭代都产生经过测试的，经过集成的，和可执行的系统。 3）每次迭代都有自己的需求分析、设计、实现和测试活动。 迭代生命周期贯穿多个迭代，系统在这个过程中被持续扩展和精化。 系统迭代过程的驱动力有两个： 循环反馈； 适应调整。 随着一次又一次的迭代递进，系统增量式的发展完善，因此这一过程也称之为迭代增量开发。 我们来看一个简单的实例： 讨论一个两周的迭代。 星期一：分析和澄清本次迭代的任务和需求，同时由一人对上次迭代的代码进行逆向工程，形成UML并打印出重要的图。 星期二：在白板上进行分组设计工作，画出UML草图，使用数码相机记录，并写出一些伪代码和设计注释。 剩余的八天： 实现； 测试（单元测试、验收测试、可用性测试）； 进一步设计； 集成； 每日的构造工作； 系统测试及部分系统的稳定； 与项目相关人员进行演示和评估； 计划下一步迭代。 注意： 1）不要匆忙编码。 2）不要试图在编程前完善所有设计细节的长期持续的设计步骤。 3）少量超前设计使用粗略和快速的UML可视建模来完成。 4）开发人员大概用半天或一整天的时间进行分组的设计工作。 关键的地方是要注意，我们不要把精力放在漂亮的文档，或者漂亮的UML图上，而是要集中全力分析问题，找到问题的矛盾点，以及解决问题的核心知识，在这个问题上来体现你的智慧。 每次迭代的结果是一个可执行但不完善的系统，一般需要10到15次迭代系统才可能投入生产。 迭代输出不是实验性的，也不是即将丢弃的原型，迭代开发也不是原型开发。与之相反，它的输出是最终产品的子集。 一般来说，尽管每次迭代需要扩展新需求并增量扩展系统，但迭代偶尔也会重新审视现有的软件并对它进行改造，例如，并不增加一个子系统的新特性，而致力于提高它的性能。