论坛首页 综合技术论坛

黑暗中摸索,UP实践

浏览 6049 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2007-12-24  

不知是水平不足还是运气不好(可能都有)。先后工作的几家公司(小则数十人,大则数百人)要不就是作坊模式(基本上没有规范),要不就是传统的开发模式(基本上都基于瀑布模型)。

附:这篇文章倒是给了我一些启发:如何在管理不规范的公司中生存

现代软件工程实践的机会一直十分有限。很多东西一直靠个人在黑暗中摸索。对现代软件工程的理解也主要限于书本和几个小项目中的不完全实践(主要是对UP的实践,像XP,Scrum,FDD还停留在yy阶段)。

近段时间负责开发一个公司内部系统(不大,估计4个人半年时间吧)。有机会全面尝试一下UP的运用。这里简单介绍一下我们对UP实践的情况,希望各位前辈赐教。呵呵。

1、关于开发案例
由于资源等各种因素的制约,我们没有完整的制定开发案例,只是简单的对UP做了一定的裁剪,保留在我们看来比较有用的东西。

主要制品如下:
项目管理:风险列表,项目计划,迭代计划,状态评估
需求:前景(Vision),词汇表,用例规格说明,补充规格说明,软件需求规格说明,界面原型
分析设计:软件架构文档,数据库设计文档(这个UP中未定义,但我们觉得有其实用性,就把它纳入进来了)
测试:测试计划,测试用例,测试评估摘要
部署:用户手册
配置与变更管理:配置管理计划

是不是感觉不够敏捷。其实我们对相关制品进行了尽可能的简化,只保留最核心的部分。

2、关于模型
项目中主要用到了UP中的领域模型、用例模型、设计模型,但我们并没有使用任何建模工具,基本上就是用白板画出来讨论讨论就行了。

3、关于商业理由(Business Case)
本来这个制品在UP中地位似乎挺高的,不过考虑到我们是一个内部项目,且商业环境相对单纯,最终放弃了此制品。相关的内容简单的合并到了前景(Vision)文档或项目计划文档中。

4、关于用例分析方法
在我们的实践中,用例分析方法遭到了比较大的抵触,公司领导习惯了传统的需求描述方式。而用户(公司内部用户)又觉得我们写的太细了,他们不想花太多的时间投入(客户参与不足似乎是现在大部分项目的通病吧)。不知各位同仁实践中是什么情况呢?

5、关于里程碑
项目中基本上按照UP的规范制定的里程碑:
初始:目标里程碑
精化:架构里程碑
构造:操作性能里程碑
移交:产品发布里程碑

只是在精化阶段加入了一个界面原型里程碑(毕竟用户还是喜欢图形化表达方式)。

6、关于需求冻结
我们项目基本上在精化阶段结束时就冻结了需求(不是说以后就不允许变更了,之后的变更纳入变更管理范畴)。UP似乎对这点没有严格定义。可能有些项目需要经过构造阶段的几个迭代才能冻结需求吧。

7、关于迭代开发
正如o6z曾经说过的迭代开发并不是按模块开发,每个迭代都应该是完整的产品,通常它应该包括所有模块。我们主要是依据用例的业务价值,架构相关性,风险这几个指标来定义迭代目标的。也就是说把业务价值高的,架构相关性强的,风险高的用例或用例场景在前期迭代中实现。

8、关于解决方案
UP中似乎没有这个东西。在我们完成初始阶段后,公司领导要求我们一定要先撰写一个解决方案文档。而且还要求写的越细越好。说实在的我们始终就没太搞明白这个东西到底其作用是什么。有没有其必要性呢?这也是我们比较迷惑的地方。不知哪位能提供一些建议。

好像写的太口水了。水平就这样,各位先将就着看看。还请多多指教。呵呵。

   发表时间:2007-12-24  
我觉得你仅仅是在做一个项目过程梳理化的过程,而不是在做一次UP的实践。
首先UP的核心定义很明确,那就是用例驱动,构架为中心,迭代增量的开发。你们的实际操作,并没有体现这一点。我估计你们仅仅是把RUP的工具和工件拿来做了个组合排列。
我觉得你们的实践可以算作一次失败的UP学习,但是确实又是一次非常成功的流程控制探索。本身我觉得你学什么并不是问题的关键,核心还是在于你们能够把实际和别人的经验相结合,并且保持一个持续的学习和修正的过程。究竟你的方法是啥,叫啥,根本就是无所谓的事情。除非你是和我一样,需要跑到别人的地盘去推广,所以要有个响亮点的名号做招牌。否则完全没有必要挂到一个啥名号下面。

下面我说说我具体的不解,希望你能做点介绍和解释的工作。
第一我看到你写了项目管理方面的几个制品,我比较奇怪的是这几个工件之间的关系,而且就我的理解看,他们之间存在大量的内容重叠。这不是个好现象。
第二需求部分,我觉得也存在很多不清楚的地方。比如思路应该是业务用例,到功能用例,然后是围绕功能用例的非功能性需要(比如速度,健壮性,可部署性等),以及界面说明,也可以包括界面流程图以说明用例的具体操作流程。
第三分析和设计阶段,我觉得你们可能存在一个很严重的问题。那就是你的构架仅仅是一个问题,而不是一个系列的实际存在的软件和软件结构。如果就UP来说,构架绝对不是一堆文件,而是一个可以运行的程序。而就我看来,其至少还应该包括基础性的测试,以及测试要求,编码的风格要求等等。那个文档可以说没有啥太大的用途,一旦构架出现,就可以抛弃掉。
其他地方还有很多细节和习惯的问题,不过我觉得都可以先不考虑。但是我感觉你似乎对付领导的经验方面有些问题,比如公司领导居然会要你写一个“写的越细越好”的解决方案文档,至少现在没人敢跟我要啥详细的东西,都要我能简单就简单点吧。其实真的如果需要详细,他们做的工作应该大大多于你的工作啊,你首先应该提出了既然要你详细,那么你就只能按照领导的详细程度和详细的要求来做,要他们先给你一个越详细越好的说明,然后你给他们一个放大。我估计这个可能是你以前太概括了。

但是记住一点,你们的实践是一个成功的过程梳理过程,虽然存在很多地方有值得继续推敲的地方。但是总的来说是成功的。
0 请登录后投票
   发表时间:2007-12-24  
ozzzzzz 写道
首先UP的核心定义很明确,那就是用例驱动,构架为中心,迭代增量的开发。你们的实际操作,并没有体现这一点。我估计你们仅仅是把RUP的工具和工件拿来做了个组合排列。 我觉得你们的实践可以算作一次失败的UP学习,但是确实又是一次非常成功的流程控制探索。

可能我没有讲清楚,用例驱动,架构为中心,迭代增量开发在我们项目中一直是核心关注点: 1、我们的完全是采用用例分析方法进行需求分析,在项目计划,构建过程中也是以用例或用例场景的为目标来进行计划和构建的。 2、精化阶段,我们选取了几个业务价值大,架构相关性强的用例进行了实现。其主要目的就是构建一个可执行的核心架构。并不是以构建软件架构文档为目的的。软件架构文档是逐步形成(得到构造阶段后期才完全成型),主要用来简要描述系统的核心部分,以便于新来的人能更好的理解整个系统以及更快的进入角色。在之后的迭代中,我们基本上没有对核心架构做过太大的调整,主要是在核心架构的基础上完善功能。 3、在制定迭代计划时。我们根据业务价值,风险对用例进行了优先级排序,从中选定合适的用例作为本次迭代的内容。

难道我们的理解有误?请解惑。

ozzzzzz 写道
第一我看到你写了项目管理方面的几个制品,我比较奇怪的是这几个工件之间的关系,而且就我的理解看,他们之间存在大量的内容重叠。这不是个好现象。

为什么有很大重复呢?这些都是标准制品。其内容是互补的关系,基本上是没有重复的: 1、风险列表:主要对相关风险进行定义,以及其相应的风险降低策略。 2、项目计划:主要对项目组织结构,项目阶段计划,迭代目标等进行定义。 3、迭代计划:主要对某个迭代的内容进行详细计划。 4、状态评估:对项目状况进行评估,主要用来监控项目进展情况。

ozzzzzz 写道
第二需求部分,我觉得也存在很多不清楚的地方。比如思路应该是业务用例,到功能用例,然后是围绕功能用例的非功能性需要(比如速度,健壮性,可部署性等),以及界面说明,也可以包括界面流程图以说明用例的具体操作流程。

这部分我们的做法和你说的差不多,只是我们省略了业务建模过程,这在很多不是很大的项目中这不是推荐的做法么?比如《UML和模式应用》中就建议一般不要进行业务建模。不过我们后面也定义了一个业务模型的变体:领域模型。但这个和业务分析过程可能就不是一个含义了。

ozzzzzz 写道
第三分析和设计阶段,我觉得你们可能存在一个很严重的问题。那就是你的构架仅仅是一个问题,而不是一个系列的实际存在的软件和软件结构。如果就UP来说,构架绝对不是一堆文件,而是一个可以运行的程序。而就我看来,其至少还应该包括基础性的测试,以及测试要求,编码的风格要求等等。那个文档可以说没有啥太大的用途,一旦构架出现,就可以抛弃掉。

正如上面所说,我们的架构不是指一堆文档,而恰恰是你说的可执行的架构。编码标准等指南文件我们是有的,只是没有列在这里罢了。另外,对于流程,活动我这里没有仔细说明,只是简单的列举了我们项目中产出的制品,可能这也是说的不清楚的原因所在。

ozzzzzz 写道
但是我感觉你似乎对付领导的经验方面有些问题,比如公司领导居然会要你写一个“写的越细越好”的解决方案文档,至少现在没人敢跟我要啥详细的东西,都要我能简单就简单点吧。其实真的如果需要详细,他们做的工作应该大大多于你的工作啊,你首先应该提出了既然要你详细,那么你就只能按照领导的详细程度和详细的要求来做,要他们先给你一个越详细越好的说明,然后你给他们一个放大。我估计这个可能是你以前太概括了。

你说的对,我确实这方面的经验十分不足。你有什么好的建议么?不过还有一个原因是:我们公司的领导对UP基本上没啥概念。更别说敏捷方法了。基本上他们都还是瀑布思维。在他们的想法中,文档应该越详细越好。所以沟通上很有难度。另外,他们的工作量不会太大,首先领导不会给我们列出很详细的要求及说明。因为那只是对我们的要求,而不是对领导本身。而且我们即使写的很详细也并不代表他们会仔细看。呵呵。这也是我更不想写这样的方案书的原因了。

同时想请教一个问题,方案书在整个项目的开发中是什么样的地位呢?是必要的么?UP中似乎没有什么方案书的概念。在我的经历来中,见得比较多的只有投标方案书。

ozzzzzz 写道
但是记住一点,你们的实践是一个成功的过程梳理过程,虽然存在很多地方有值得继续推敲的地方。但是总的来说是成功的。

谢谢o6z老大的鼓励。请继续帮忙解惑。

总的来说,我们的过程大概是这样两个循环往复的并行过程,直到项目完成:
开发:用例模型、领域模型->分析设计模型->编码实现->测试
管理:项目计划->计划跟踪

0 请登录后投票
   发表时间:2007-12-25  
呵呵,和我们现在搞的差不多,不过我们的不太顺利。
对于制品,感觉选择的不错,如果在实际中注意之间可能重复的地方就可以了。
对于架构文档,不太同意可以抛弃的想法。架构文档对于项目成员在开发阶段应该具有指导性的意义,对于新加入的项目成员具有教育意义,应该体现出整体架构的思想和灵魂,这样才不至于随着时间的推移,开发人员执行架构思想出现走形。
对于业务建模,我们也是省了,应该是没有真实客户的原因吧。如果你们用DDD的开发方式,业务、分析和设计都有一个模型,也是可以的。
对于方案书,我感觉应该是架构文档对客户方面(或者领导方面)的一些视图。如果投标的方案书,就要写点能拿得出手的花样。

0 请登录后投票
   发表时间:2007-12-25  
用例驱动的绝对不是用了用例就是用例驱动了。如果你去看UP中对构架的定义,就会明白用例也是构架的一个组成。同时任何的工作,都只能从用例那里得到理由和原因。
另外就是什么是构架为核心,并不是你有了一个构架,并且采取组件开发就是核心了。而是应该在开发过程中不断的强化构架,提供更多的测试和接口约束。而不是你开始就设定一个稳定的构架,以后就很少去动它。至少每一个阶段结束就该从新对构架做一次新的总结和提炼。这里我顺便说说为啥要抛弃构架文档的问题,因为构架应该自己提供约束和自说明,新人的入手和研究应该直接从构架自身入手。这里除了构架自身包括的业务层面的说明,都应该抛弃,理由很简单——关键的信息应该只来自一个关键的点,而不能来自多个点——维护和同步都是很费资源的。
同时对于你们文档规划的问题,我觉得在这里很难简单的给你说清楚。这个方面我在别的地方已经说过,我准备在je3.0推出以后,把我的文档写作教程公开出来,下一步就是总结如果规划文档。也就是说等我有时间,我会把如何做一个文档系统做个说明的。
另外一个问题是,领导觉得越详细越好。其实这里很简单,你就直接告诉他们,你会以他们提供的素材做详细程度的规范,也就是说他们详细到啥地步,你就只比他们详细进一步。如果他们喜欢文档,要你写一个啥东西,那么你就先跟他们要一个文档,要他们在文档中说明他们想要一个啥东西,否则你就不行动,并且你要不断的催促他们赶快提供这个文档,每小时催促一次,并且必须有签字验收,而且需要每次谈话都在谈完之后要备忘录,然后参加的各方互相对照,最后签字备案。搞几次他们自然就会闭嘴。
0 请登录后投票
   发表时间:2007-12-25  
好狠,对日本人无效
0 请登录后投票
   发表时间:2007-12-25  
抛出异常的爱 写道
好狠,对日本人无效

对日本人有日本人的办法。
遇到了再来找我吧。嘿嘿
0 请登录后投票
   发表时间:2007-12-25  
hyhongyong 写道
呵呵,和我们现在搞的差不多,不过我们的不太顺利。对于制品,感觉选择的不错,如果在实际中注意之间可能重复的地方就可以了。对于架构文档,不太同意可以抛弃的想法。架构文档对于项目成员在开发阶段应该具有指导性的意义,对于新加入的项目成员具有教育意义,应该体现出整体架构的思想和灵魂,这样才不至于随着时间的推移,开发人员执行架构思想出现走形。对于业务建模,我们也是省了,应该是没有真实客户的原因吧。如果你们用DDD的开发方式,业务、分析和设计都有一个模型,也是可以的。对于方案书,我感觉应该是架构文档对客户方面(或者领导方面)的一些视图。如果投标的方案书,就要写点能拿得出手的花样。

我们项目中对架构文档的应用和你说的基本一致。

你们项目为啥不太顺利,能谈谈么?

我觉得你把方案书作为架构文档对客户方面或领导的一些视图的看法是一种不错的想法。其实我更倾向于以技术备忘录的形式将架构决策记录在架构文档中。然后就用架构文档来代替(其实也不能说是代替,UP中本来就没有什么方案书的概念)方案书。而不是另外单独写一个方案书。我觉得这样就够了。当然出于商业上或其它什么方面的原因,方案书还是有其存在的价值吧。

0 请登录后投票
   发表时间:2007-12-25  
ozzzzzz 写道
用例驱动的绝对不是用了用例就是用例驱动了。如果你去看UP中对构架的定义,就会明白用例也是构架的一个组成。同时任何的工作,都只能从用例那里得到理由和原因。另外就是什么是构架为核心,并不是你有了一个构架,并且采取组件开发就是核心了。而是应该在开发过程中不断的强化构架,提供更多的测试和接口约束。而不是你开始就设定一个稳定的构架,以后就很少去动它。至少每一个阶段结束就该从新对构架做一次新的总结和提炼。这里我顺便说说为啥要抛弃构架文档的问题,因为构架应该自己提供约束和自说明,新人的入手和研究应该直接从构架自身入手。这里除了构架自身包括的业务层面的说明,都应该抛弃,理由很简单——关键的信息应该只来自一个关键的点,而不能来自多个点——维护和同步都是很费资源的。同时对于你们文档规划的问题,我觉得在这里很难简单的给你说清楚。这个方面我在别的地方已经说过,我准备在je3.0推出以后,把我的文档写作教程公开出来,下一步就是总结如果规划文档。也就是说等我有时间,我会把如何做一个文档系统做个说明的。另外一个问题是,领导觉得越详细越好。其实这里很简单,你就直接告诉他们,你会以他们提供的素材做详细程度的规范,也就是说他们详细到啥地步,你就只比他们详细进一步。如果他们喜欢文档,要你写一个啥东西,那么你就先跟他们要一个文档,要他们在文档中说明他们想要一个啥东西,否则你就不行动,并且你要不断的催促他们赶快提供这个文档,每小时催促一次,并且必须有签字验收,而且需要每次谈话都在谈完之后要备忘录,然后参加的各方互相对照,最后签字备案。搞几次他们自然就会闭嘴。

应付领导的方法我会试试的。呵呵。

我同意你关于用了用例并不代表就是用例驱动的观点。但我还是不太明白我们的做法为什么不是用例驱动的,什么才叫用例驱动呢?能不能举个例子。

在我的理解来看:需求用用例来表达,计划以用例为基准进行编制,分析设计以用例为输入源开发用例实现模型(我们是手工通过白来来做的),开发基于用例场景。所有工作都是围绕用例来进行的。这个和你说的任何工作都只能从用例那里得到理由和原因似乎是一致的啊。

关于UP中的架构我赞同你的说法,使我对UP中架构有了新的认识。虽然对于有些问题还有些不太明白的地方。比如:用例也是架构的一部分。

还有一点需要说明的是在我们的项目中只是后期没有做什么大的架构变更。并不是开始就设定不允许变更。

另外,关于文档的问题,期待o6z老大后续文章的剖析。

0 请登录后投票
   发表时间:2007-12-25  
用例驱动的问题其实很复杂,我这里只能简单的说解释一下。
为什么说用例也是构架的一个部分呢?其实你看UP中对构架的解释,那里就说到一个视图是用例。简单说用例为构架提供了功能性的理由,并且用例其实也为结构提出了一个高层次的理念参照系统。这些都是比较明显的。
其实还有一个方面是比较隐秘的,那就是开发过程也是用例驱动的。这里有两个方面的内容,一个是需要用例来制定计划,部署资源等等。而另外一个方面是,用例之过程的的理由和约束的前提。比如你要搞一个文档,那么为什么你需要这个文档,并不是说你的过程要求你必须有这个文档,而是你的用例需要这个文档来完成它。比如你要搞一个测试,并不是你的程序需要测试,也不是客户要求你必须测试,而是你的用例自身需要通过某些检查来验证其自身。这一点是我以前很少意识到,也是我在其他地方没有看到过的。我仅仅是在最近研究RUP文件的时候,才注意到的,并且这一点在《统一软件开发过程》中有解释的。这也就是我说任何工作都需要从用例里面找到理由和原因的意思。

同时我要对构架的问题在多做解释。其实我们谈构架的时候,很多情况下混淆了构架和构架基线的概念。构架基线,自然是越来越稳定,并且后期很少变更。但是请注意构架基线不变更,并不代表构架不变更。而且越是后期构架的越是应该清晰,越是应该明确,越是应该被加强。也就是说构架也不是一个前期就设定好了,就很少变化的东西,而是一个随着你的开发过程的进步,不断的被强化被清晰被明确表达的过程。这一点非常的重要。

另外我觉得引入一个方法,最好要找一个突破口,然后一步一步前进,而不是一下子就铺开一个大的阵势,全面实施。比如你这里其实我看主要的就是实施了迭代,其他方面都是次要和辅助的。而你们的组织应该总结这个方面的内容,并在下一个阶段继续加强。然后在迭代的过程中,逐步使引入其他的实践。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics