美文网首页
真实案例解析OO理论与实践(六)

真实案例解析OO理论与实践(六)

作者: 不知公民 | 来源:发表于2017-03-15 14:09 被阅读56次

作者:张洋

再次明晰开发流程

在上一篇文章我给出了一幅开发流程图:

这幅图,加上前几篇文章的内容,给不少朋友留下诸多困惑。如“特性列表不算需求分析吗?”、“用例图怎么跑到需求分析前面去了?没有需求分析哪来的用例图?”为了解开这些困惑,我们应该先把开发流程各个相关概念给明确了。

在一般开发流程中,直观上可以分为两个部分:业务阶段和系统阶段。明确这一点非常重要。其中业务阶段主要进行的工作是与计算机无关的,而系统阶段才是和计算机相关的东西。上图中“我们在这里”那道竖线所指的地方,就是业务阶段和系统阶段的分界点。

而如果从建模角度分析,整个开发流程分为四个子流程:

a)业务建模流程

b)系统建模流程

c)分析设计建模流程

d)部署实施建模流程

其中a)属于业务阶段,而b)c)d)均属于系统阶段。

业务建模流程的任务就是做业务分析、降低风险和给出系统总体概览模型。系统建模主要就是需求工程。分析设计建模就是我们熟悉的概要设计和详细设计。而部署实施建模是对系统的具体实施建立模型。

其中,我们一般所说的“需求”,实际是指“系统需求”,是在b)阶段进行的,所以a)阶段的一切工作,都不能算是需求分析。(当然,如果加一个前缀,说是“业务需求分析”,也是可以的,但是一般在软件工程领域,说“需求分析”是特指“系统需求分析”。)

而关于用例图的疑惑,大家应该知道,用例图分为业务用例图和系统用例图,而业务用例图产生于a)流程,这样它们当然会出现在b)流程,也就是需求分析之前。当然,在b)流程中还会出现用例图,这时就是系统用例图了。

明白了以上开发流程,我想很多疑惑就自然解开了。所以,其实我们所谓的“需求分析之前的故事”,就是业务建模流程。

系统阶段的法宝1:迭代与增量

在上文中,我们提到软件过程大体分为业务阶段是系统阶段。在前面几篇文章中,我们已经基本完成业务阶段,下面是进入系统阶段了。不过莫急,在正式进入系统阶段之前,我们有几个重要的、关于系统阶段的话题要聊一下。

如果你问我,在系统阶段最应该被牢记的是什么,我会告诉你,是两个词:迭代&增量。

我们已经知道,系统阶段是在业务阶段的基础上,在计算机领域内进行需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施等一系列环节。但是,如果你想仅施行一遍这个流程,而完成整个系统的话,不好意思,你大致会精神崩溃。

如果这个过程仅实施一遍,其实就成了瀑布模型。小系统也许可以,但是稍大点的系统,将会带来严重的后果。我们知道,“软件开发中永远不变的就是变化”,如果采用瀑布模型,反馈将会非常靠后,一直要到部署实施阶段才能看到成果,如果客户要求更改需求或认为当前系统不是他们想要的,那么修改过程会异常惨烈,代价也是巨大的。

那么,我们应该如何实施系统阶段开发呢?法宝就是迭代和增量。具体做法是:

我们将整个系统分为许多相对独立的“单元”,每次只对一个或少数几个单元实施需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施等一系列过程,一次这样的过程叫做一次迭代,而将一次迭代的成果加入现有成果的过程就叫做增量。

这种开发流程的优势是明显的:我们总是能在相对较短的时间内,完成整个系统功能的一个“子集”,这个子集是可以运行的,可以看到效果,所以如果用户不满意,反馈是及时的,修改代价也较小。通过合理的过程控制,变更代价总可以控制在一个可以接受的范围内。

在实施迭代&增量过程时,要注意一下两点:

1)迭代单元不是环节,而是系统功能的某个子集。如不能说第一次迭代完成需求分析、第二次迭代完成设计……这不叫迭代式开发,这叫里程碑式开发,和迭代有本质区别。

2)每次迭代一定要完整完成需求分析、系统分析、概要设计、详细设计、编码、测试、部署实施这一套环节,产生的成果必须是成品,是可运行、可交付的,是整个系统的一个子集,而不能是一个半成品。

系统阶段的法宝2:用例驱动

相信,大家或多或少听说过“用例驱动”。那么什么是用例驱动呢?如果你理解了上文的迭代&增量过程,就很好理解用例驱动了。上文不是说过,迭代时每次选取一个或少数几个“单元”吗?那么这个“单元”是什么?理论上,什么都可以,只要是对系统合理的划分。但在实践中,人们发现,使用业务用例作为迭代单元是最合适的。为什么呢?

其一,业务用例大小适中,规模平均。

其二,业务用例大多相互独立性好,适合进行迭代。

其三,业务用例能很好反映系统的功能单元。

所以,所谓的用例驱动就是以业务用例作为迭代单元进行迭代开发的流程。

你看,我们前面做了那么多业务分析,其中成果之一就是业务用例图。而这里,业务用例成了我们进行系统迭代开发的单元和驱动者,所以,软件开发过程不是割裂的,而是相互联系的,不会说上一个阶段过去就过去了,和下一阶段毫无联系。一般,上一阶段的产品总会成为下一阶段的材料。

在这里附上一副我自己画的示意图,希望能帮助大家理解本文内容:

本文理论讲得多了点,有点枯燥,但是必须讲,因为明白这些是以后进行系统阶段的基础。从下一篇开始,我们回归示例,进入真正的系统阶段了。下一篇,将开始第一轮迭代的起始阶段:需求分析。

重点总结

1.软件过程大致可分为业务阶段和系统阶段。

2.业务阶段进行业务建模流程,与计算机领域无关;系统阶段进行系统建模、分析设计建模和部署建模阶段,与计算机相关。

3.系统阶段的两大法宝:迭代式开发与用例驱动。

相关文章

  • 真实案例解析OO理论与实践(六)

    作者:张洋 再次明晰开发流程 在上一篇文章我给出了一幅开发流程图: 这幅图,加上前几篇文章的内容,给不少朋友留下诸...

  • 真实案例解析OO理论与实践(四)

    作者:张洋 细节的泥沼 现在我们再次将特性列表贴过来: 1.可以将各种原料信息发布到系统上 2.加盟商和连锁店可以...

  • 真实案例解析OO理论与实践(三)

    作者:张洋 风险无处不在 在上一篇文章中,我们写出了一张特性列表。然后是不是就可以做需求分析了?很遗憾,还不可以,...

  • 真实案例解析OO理论与实践(二)

    作者:张洋 第一份说明 当这个项目开始时,我们得到的关于我们要做的系统的唯一说明是一页Word文档,这是一份简单的...

  • 真实案例解析OO理论与实践(一)

    作者:张洋 为什么要写这个系列 “OO都是一个已经被讨论烂的话题了,还有什么可写的!” 不知当你看到文章标题时,是...

  • 真实案例解析OO理论与实践(五)

    作者:张洋 高质量软件的第一要素 到目前为止,我们做了很多工作,但是我一直在强调这些都还不是需求分析。在很多人心目...

  • 真实案例解析OO理论与实践(七)

    作者:张洋 在前面,我们花了六篇文章的篇幅去讨论需求分析之前发生的事情,这些内容看起来枯燥或飘渺,但实际是为真正开...

  • Android技术文章

    Android 内存泄漏案例和解析 RxJava 与 Retrofit 结合的最佳实践 APK瘦身记,如何实现高达...

  • “案例”的现实意义

    每一个理论的或实践的研究都离不开“案例”,有了“案例”,理论的研究才有依据,有了“案例”,实践的研究才有意义。那么...

  • 我的书单

    机器学习实践指南——案例应用解析(麦好) 社交网站的数据挖掘与分析_中文版(Mattbew A Russell,师...

网友评论

      本文标题:真实案例解析OO理论与实践(六)

      本文链接:https://www.haomeiwen.com/subject/azplnttx.html