自底向上的归纳
OMT的第一步是从问题的陈述入手，构造系统模型。从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关联。类是具有相似属性和行为的一组具体实例（客观对象）的抽象，父类是若干子类的归纳。因此这是一种自底向上的归纳过程。在自底向上的归纳过程中，为使子类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理。由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类的思维规律，因此能更快、更方便地完成任务。这与自顶向下的Yourdon方法构成鲜明的对照。在Yourdon方法中构造系统模型是最困难的一步，因为自顶向下的"顶"是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。而在ＯＭＴ中这一工作可由一般开发人员较快地完成。在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型。这三个模型一起构成要求解的系统模型。
自顶向下的分解
系统模型建立后的工作就是分解。与Yourdon方法按功能分解不同，在OMT中通常按服务（Service）来分解。服务是具有共同目标的相关功能的集合，如I／O处理、图形处理等。这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易。所以OMT也具有自顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了Yourdon方法中功能分解的困难和不确定性。
OMT的基础是对象模型
每个对象类由数据结构（属性）和操作（行为）组成，有关的所有数据结构（包括输入、输出数据结构）都成了软件开发的依据。因此Jackson方法和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。更重要的是，在Jackson方法和PAM方法中，当它们的出发点--输入、输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。但在OMT中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
需求分析彻底
需求分析不彻底是软件失败的主要原因之一。即使在目前，这一危险依然存在。传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种问题。正是由于这一原因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改进需求。在每次改进需求后又形成新的进化原型供用户试用，直到用户基本满意，大大提高了软件的成功率。但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。
OMT彻底解决了这一问题。因为需求分析过程已与系统模型的形成过程一致，开发人员与用户的讨论是从用户熟悉的具体实例（实体）开始的。开发人员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语言，避免了传统需求分析中可能产生的种种问题。
可维护性大大改善
在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。但从本质上讲，基于功能分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。更严重的是，在这种软件系统中，修改是困难的。由于种种原因，即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。正是OMT才使软件的可维护性有了质的改善。
OMT的基础是目标系统的对象模型，而不是功能的分解。功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。
更重要的是OMT彻底解决了软件的可维护性。在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为（虚函数）。利用这一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为（即虚函数或虚方法）进行重载，也就是对它们重新定义。由于不再在原来的程序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。OO技术还提高了软件的可靠性和健壮性。
六、可视化开发方法
可视化开发是90年代软件界最大的两个热点之一。随着图形用户界面的兴起，用户界面在软件系统中所占的比例也越来越大，有的甚至高达60～70％。产生这一问题的原因是图形界面元素的生成很不方便。为此Windows提供了应用程序设计接口API（Application Programming Interface），它包含了600多个函数，极大地方便了图形用户界面的开发。但是在这批函数中，大量的函数参数和使用数量更多的有关常量，使基于Windows API的开发变得相当困难。为此Borland C++推出了Object Windows编程。它将API的各部分用对象类进行封装，提供了大量预定义的类，并为这些定义了许多成员函数。利用子类对父类的继承性，以及实例对类的函数的引用，应用程序的开发可以省却大量类的定义，省却大量成员函数的定义或只需作少量修改以定义子类。
Object Windows还提供了许多标准的缺省处理，大大减少了应用程序开发的工作量。但要掌握它们，对非专业人员来说仍是一个沉重的负担。为此人们利用Windows API或Borland C++的Object Windows开发了一批可视开发工具。
可视化开发就是在可视开发工具提供的图形用户界面上，通过操作界面元素，诸如菜单、按钮、对话框、编辑框、单选框、复选框、列表框和滚动条等，由可视开发工具自动生成应用软件。
这类应用软件的工作方式是事件驱动。对每一事件，由系统产生相应的消息，再传递给相应的消息响应函数。这些消息响应函数是由可视开发工具在生成软件时自动装入的。
国内的软件公司大多数是处在"十几条枪,一个手工作坊"的水平上,在承接软件开发的项目之后往往是几位骨干人物讨论之后对费用和进度作一个大致的估计,然后就开始进入项目的执行。这种方法带有明显的主观性。在作一个精确的软件费用估计和作一个比较现实的项目开发计划时需要考虑许多因素。对于一个大的软件项目,用手工作费用估计和作计划是不能胜任的。现在国外市场上有大约50种商业软件费用估计工具包和大约100种商业项目计划工具包,使用他们作精确的估计比手工的估计更可能获得成功。
常用的软件费用估计工具软件有Checkpoint,Colomo,Estimacs,Price_s,Slim。 常用的项目管理软件有MS Project,Primavera,Project Manager*s Workbench,Timeline。把这二种工具软件联合使用可以互为补充,帮助经理驳回客户和程序员的无理要求并且能精确的控制项目的执行。
错误3:忽视用户的需求的变动
尽管最初的用户需求在签定开发合同时已经包含在需求说明书中,但在整个开发周期中期望用户的需求一直保持不变是不大可能的,因为用户对于如何应用计算机软件并没有一个成熟的经验。在项目进行中用户的需求会不断的增长,一般情况下用户的需求以每月1%的速率增加,如果一个项目在12个月内完成,最终将有超过10%的改动,如果项目要持续36个月,最后将增加1/3的功能。每月1%也只是一个经验数据,一个缺乏计算机应用经验的用户会更频繁的改变和增加他的要求。因此在作项目的费用和时间估计时一定要考虑用户需求的变化。一种比较明智的方法是在签定开发合同时把用户需求的改动和经济利益挂钩,如果用户增加或改动了需求,那么软件的交付日期可以推迟,费用也应增加。
错误4:忽视监督项目的进度
到目前为止,软件产业还没有一个标准的项目进度的检查标准。一个比较清晰的尺度是用已经实现的软件功能反映项目的进度。但这种方法是否就是最科学的衡量标准,现在还不能定论,毕竟在一个软件项目中软件功能只是一个主要而非全部的任务。因此一个项目经理在监控项目执行时不应该只关注实现的软件功能,还要关心文档,测试,技术支持这些因素。在实际工作中我们经常听到经理或程序员说这样的话:"项目已经完成了90%",这种结论带有明显的主观性,一个优秀的项目经理不应该被手下的判断所迷惑,而应该按照一个比较客观的标准去深入检查。
错误5:忽视设计复查和代码复查
很多程序员习惯于这样一种工作方式:只做不想。他们更关心每天可以写多少行代码,完成几个模块。在这种态度下,他们都很不愿意复查自己的工作,而习惯于在软件测试阶段把隐藏的错误改正过来。但设计复查和代码复查在大型的软件项目中已经有30年的应用历史,而且已经被证明在设计和代码编写阶段的复查比软件测试更能有效的消除错误,一些经验数据表明,在设计和代码复查时发现的错误是在同等工作量下软件测试发现的错误的两倍。
结论:
软件开发是一个带有一定风险的工作,为了把风险降到最低, 在项目的执行中项目经理必须严格的监督项目的进度,对程序员不愿复查的坏习惯要给予纠正。项目经理必须要从软件开发的历史数据和辅助工具包提供的数据中作出精确的估计,在作估计时他应该考虑为不断变化的用户需求留出富余量。
责任编辑：张瑶
您现在的位置： 