谈谈分析模型的那些事儿 之 开始分析
来源:互联网 发布:财经日历数据 编辑:程序博客网 时间:2024/06/09 16:27
当需求分析结束、需求确认完成、需求讨论告一段落的时候,我们的需求分析员拿出了厚厚的一打用例分析模型、领域设计模型,需求分析阶段结束,开始进入开发阶段。但是,这时候虽然需求分析阶段结束了,却千万不要以为需求分析就结束了,如果你还这样认为,说明你还没有摆脱瀑布式开发的思维。瀑布式开发的思维的关键点就是认为,需求分析阶段应当完成所有的需求分析和确认的工作,否认需求分析阶段以后还会变更需求。拥抱变化是现代软件开发思想的核心之一,什么敏捷开发、迭代开发、极限编程,都是围绕这个主题展开的。拥抱变化,意味着我们的软件需求总是在变化,因此需求分析文档,包括用例模型、领域模型,总是在与之同步。总之,不要期望在需求分析阶段就完成所有的事,在分析设计,以及之后的编程开发阶段、实施和维护阶段,我们都应当随时与客户保持联系,注意与他们的反馈。
在需求分析阶段结束以后,许多公司(包括我们)通常的做法都是立即进入开发编程阶段。开发人员与需求人员坐在一起开了一个简短的动员会,按照模块和功能的划分,给所有的人进行一次任务分配,紧接着开发人员就领着自己的任务开始埋头开发。诚然,几乎所有的开发任务时间都是非常紧张的,但是没有经过规划和设计的系统,往往是无序和低效的。那些我在《谈谈软件开发的那些事儿》中提到的噩梦就是这样开始的。随意地创建对象,随意地分配属性和方法,随意地相互调用,都会大大降低软件的可维护性。一个小小的变更,就会让我们的软件大动筋骨,从何谈起拥抱变化呢?要提高软件的可维护性、可变更性,就必须让我们的设计低耦合、高内聚,也就必须做到职责驱动设计(RDD)。建立必要的分析模型和设计模型,可以帮助我们做到这一点。
分析模型和设计模型就是在需求分析结束后、程序开发开始前的这段分析设计阶段使用的。按照RUP的流程,应当先建立分析模型,然后再建立设计模型。但是分析模型和设计模型没有明显的时间分隔,通常都是经过无数次迭代,从分析模型逐渐过渡到设计模型。分析模型是在不考虑任何技术实现的前提下进行的纯OO分析的模型。不论你的系统是采用J2EE实现还是C++实现,分析模型都是一样的。而设计模型则相反,设计模型开始考虑具体技术的实现。因此,从分析模型到设计模型是一个从抽象到逐渐细化的过程。
另一个问题是,谁来完成从分析模型到设计模型的整个过程?我认为,应当是需求分析人员和架构分析师共同来完成。然而,在实际情况是,更多的工作是需求分析人员来完成的。因此,那些由技术出身的,拥有扎实OO分析设计基础的需求分析员在完成这些工作时会更加得心应手。下面我们看看分析模型是怎样开始分析和设计的。(续)
转载:http://fangang.iteye.com/blog/492082
- 谈谈分析模型的那些事儿 之 开始分析
- 谈谈分析模型的那些事儿 之 职责驱动设计
- 谈谈用例模型的那些事儿 之 用例图
- 谈谈用例模型的那些事儿 之 注意什么
- 谈谈领域模型的那些事儿 之 注意什么
- 谈谈领域模型的那些事儿 之 从领域获取知识
- s5pv210 u-boot的那些事儿之---lowleve_init.S的分析
- s5pv210 u-boot的那些事儿之---mem_setup.S的分析
- 关系模型的那些事儿
- linux驱动那些事儿之驱动分析之前的磨刀工
- 谈谈软件开发的那些事儿 笔记
- 谈谈Js对象的那些事儿
- 谈谈Js继承的那些事儿
- 谈谈Js闭包的那些事儿
- 谈谈Js事件的那些事儿
- 让我们谈谈虚拟机的那些事儿
- 谈谈主席树的那些事儿
- 谈谈加密那些事儿
- keil所有错误
- 搭ssi框架相关
- 2013自己的职业规划
- 短信猫
- Embedded OS survey
- 谈谈分析模型的那些事儿 之 开始分析
- Camera最新资料大全
- Oracle 等待事件
- 如何搭建个人网站
- 内存监控软件Eclipse Memory Analyzer
- A10 android4.0 adb push一些小文件的路径
- FORM的ENCTYPE="multipart/form-data" 时request.getParameter()值为null问题的解决
- 第70章、初识Intent-打开另一个Activity:双向传值(从零开始学Android)
- JS自定义属性的设置与获取