通过RUP用例进行需求管理的可追踪性策略(1)

发表于:2007-06-11来源:作者:点击数: 标签:
本文作者将结合理论知识,实践案例,优秀的工具介绍,经典文章导读,告诉您 软件工程 中最重要的一个过程――需求过程各方各面的知识。通过阅读,您将了解到,需求的知识体系,需求的过程能力,相关的软件工程知识,在实践中如何做好 需求分析 。文章虽然有

本文作者将结合理论知识,实践案例,优秀的工具介绍,经典文章导读,告诉您软件工程中最重要的一个过程――需求过程各方各面的知识。通过阅读,您将了解到,需求的知识体系,需求的过程能力,相关的软件工程知识,在实践中如何做好需求分析。文章虽然有很多的例子,但是,文章主要还是偏向于宣传一种思想,一种面向对象的思想,一种实践的思想。

1.1. 从猴子说起

有这样一个笑话:一个旅客走进硅谷的一家宠物店,浏览展示的宠物。这时,走进一个顾客,对店主说:"我要买一只C猴。"店主点了点头,走到商店一头的兽笼边,抓出一只猴,递给顾客说:"总共5000美元。"顾客付完款,然后带走了他的猴子。

这位旅客非常惊讶,走到店主跟前说:"那只猴子也太贵了!"

店主说:"那只猴子能用C编程,非常快,代码紧凑高效,所以值那么多钱。"

这时,旅客看到了笼子中的另一只猴子,它标价10000美元。于是又问:"那只更贵了!它能做什么?"

店主回答:"哦,那是一只C++猴;它会面向对象的编程,会用Visual C++,还懂得一点Java,是非常有用的。"

旅客又逛了一会儿,发现了第三只猴子,它独占一个笼子,脖子上的标价是50000美元。旅客倒抽一口气,问道:"那只猴子比其他所有猴子加起来都贵!它究竟能做什么?"

店主说:"我们也不知道它究竟能做什么,不过它是做项目顾问出身的。"

虽然这只是一个笑话,但是有一点是可以肯定的,项目管理是非常重要的,而项目管理的人才又是极为缺乏的。在软件工业发达的国家,大家多少都知道点软件工程规划的重要性。在我们身边的台湾、印度、日本,都不乏因实施软件工程而成功的软件团体,更不用说身为软件大国的美国,已经从较低级的软件实现摆脱出来,进入了设计和营销的境界。

软件首先是一种产品(软件是服务还是产品的问题,向来未有定论),看看世界上制造业的发展历程,就会发现一些很有意思的现象。在本世纪早些的年代,西方国家的制造业经历了规模生产、提高质量等等促进生产力提高的过程。可是由于西方国家的人力资源成本不断的攀升,越来越难降低产品成本,所以西方国家又不可避免的经历了一次将制造业外移的过程(制造业外移的结果是成本大幅下降、国际贸易频繁、接受制造业的国家发展了自身的制造业),而西方国家只留下营销和设计的能力,掌握了产品生产的重点。

同样,IT行业也在经历这种过程:美国将软件外包给印度,硬件外包给台湾。而中国的硬件也在崛起,但是在软件行业,中国和其他国家的差距还是太大了,且不说在软件行业中处于核心地位的操作系统、数据库。即便是应用软件,中国的软件水平也实在低的可怜。在国外制造业刚刚迁移进中国的时候(改革开放),中国的小企业家同样没有任何管理经验、质量意识。但是随着制造业的发展和国外先进思想的进入,中国也诞生了极为出色的全球制造业巨头。而中国的软件行业现在正是处于刚刚有了一点管理思想,但还没有成熟的地步。我们有理由相信,在不久的将来中国也会诞生出出色的全球性软件企业。

憧憬归憧憬,现实的问题还是必须要考虑的。软件这个产品很奇特,软件企业的管理思想同样很奇特。不同于现在企业推崇的各种管理思想,软件企业的管理思想主要是针对项目的管理,确保项目的成功。

1.2. 项目和需求

笑话里的猴子对应到项目就是指项目管理人员,这里要引入一个角色的概念(同样的人可以担任多种的角色),通常的项目管理角色包括:项目经理、项目复审员、变更控制经理、企业流程分析师、业务模型设计师、需求分析员、需求复审员、系统分析员…在一个成功的项目里,多种角色职责明确,分工合作,共同完成项目的设计实施。

那么这些"猴子"在项目中都做了些什么呢?RUPRational Unified Process 瑞理统一过程,本文采用了众多的RUP的思想)把一个项目分成10个核心工作流程(Core Workflows)和4个阶段(Phases),并以核心工作流程为Y轴,阶段为X轴建立起一个项目视图(图一)。

本文将主要对先启阶段做介绍。在先启阶段,需求是重中之中,这里指的需求不仅仅是RUP的一个工作流程(在业务建模下),而是比较广义的概念,包括了RUP的工作流程中的业务建模、需求、一部分的分析、测试计划、配置和变更管理。

1.3. 需求是根本

由于忽略需求过程造成的项目返工是恶性的,大量的项目在需求阶段就注定了它的失败。以下是需求过程不科学的典型例子:

开发人员在用户处呆了两三天就埋头开发;

用户告诉开发人员我要开发一个XX系统,但是我很忙,你先开发一个让我看看; 

上面的这两种态度都意味着项目的不成功,应该说上面的开发人员和用户都应该对此负责。需求是开发者和用户交互的一个过程,任何一方的不投入都会导致项目的失败。当然,由于用户不是专业人士,开发者有权利告诉用户应该采用何种态度来对待项目的需求。曾经和几个朋友聊过他们公司开发过的项目,最后得出一个结论,所有最成功的项目都有一个重要的特性:用户非常的支持。

评判一个软件项目成功的标准是看它是否解决了用户的问题,而用户的问题就是体现为用户的需求,需求也就顺理成章的成为项目的成功标准。而需求阶段的一个不慎都有可能导致软件实现阶段的大量返工,而需求的不慎不是说你小心就可以的,因为很多需求是隐性的,连用户都不清楚自己的需求。这时候就需要一种科学的方法来帮助软件组织实施需求过程。


共5页: 1 [2] [3] [4] [5] 下一页

原文转自:http://www.ltesting.net

...