10年间,致力于中国最专业的UML解决方案
UML一站式解决方案   Trufun QQ:344593239   咨询热线:029-62375359 13379288210  

软件开发过程活动分析


时间: 2017-07-03    来源: 楚凡科技

 

  通过前面的文章“软件开发过程分析”的分析,我们知道每个模型对会针对不同的问题而设置活动以及活动之间的结构,从而构成了软件过程。最终在对软件过程特征和在信息化时代的适应性进行了分析后,我们还要分析一下各个活动的特征来明确我们该如何解决问题。

  这里我们仅仅分析与问题最为相关的“需求阶段”和“设计阶段”,同时我们把“规格说明书阶段”纳入“需求阶段”进行论述,这样我们可以更加接近问题的本质。

  需求阶段的任务是根据项目的范围来建立出形同的功能需求。它开始于客户给出的范围,结束于系统功能需求的建立;这里需要系统分析师根据项目的范围建立出每个范围内所需要的功能需求。适用于该阶段的技术一般为调查、走访、快速原型的建立;通过这些方法系统分析师可以明确地建立出系统的功能需求。另外,我们也知道了快速原型使用的条件是存在明确的范围。

  设计阶段的任务是根据功能需求说明(规格说明书)划分出系统的模块和建立出系统的架构。它开始于明确的需求规格说明书,结束于系统模块和架构的生成;这里需要系统工程师、数据库架构师和其他相关技术人员的参与共同建立出系统的架构。适用于该阶段的技术可谓是数不胜数,但是这些技术可以分为几类,如面向对象、面向过程、面向业务等。现在,为了适应变更和复用等问题,也出现了各种不同的设计技术,如UML、SOA(严格地说SOA是一种标准)等。

  我们发现,这两个活动基本上被所有的开发模型所采用,甚至包括演化模型,它们也需要一个结构设计,否则很难构成系统来被客户所使用。那么,我们便产生一个疑问,为什么需求与设计都被用于解决不同问题的模型所采纳。难道这是巧合,还是必然现象?

  至少我们从常识中可以明确一点,这两者对于软件工程而言必不可少。倘若不知道客户的需求,那么我们建造什么呢?倘若设计不存在系统是否还能协作运行呢?那么,除了常识意外还有其他原因吗。从软件的角度来看待,功能需求说明了每个范围内系统所需做的事情,设计从技术角度建立出模块,以使得每个模块易于被维护、易于复用、易于团队开发,更为重要的是降低模块之间的耦合度。

  通过需求与设计我们基本上明确了系统的模块与这些模块如何来完成功能需求的,这也是大多数软件过程所一致认可的。但是,问题却出在了这个被广泛认可的过程之中。我们的功能需求是从技术层面考量的,系统的设计也就自然的从技术层面来建构的。可是这些都属于瀑布模型的特征,也是问题的根源。我们必须承认软件不是无限制可变的,同时我们还需承认工程是被限定在一个有限的条件下来完成的。所以,如果我们不能解决问题的根源“不明确的需求”,那么任何依赖于“需求与分析”这两个活动的模型,都会失败于项目中不断的变更。虽然我们所述的各种模型由于各种不同的原因失败于信息化项目,但是不明确的范围是导致了“需求与设计”阶段失败的“罪魁祸首”。

  缺乏明确的项目范围,我们没有办法管理后期的变动或返工要求。这方面我们可以建立明确的项目范围和正确执行调研的工作,(请参考“降低开发过程中的变动依赖项目范围管理”一文),相信可以大大减低项目的延误。但要提供科技应用的价值,必须利用项目组件分拆法PCDM才能够满足赞助人即干系人的期盼。但仍然不能够保证余下的设计,开发,测试和移交能够顺利完成。

  我们必须有一套明确的方式,让我们可以处理系统的逻辑,未来应用的流程,用户的界面设计,和思考软件应用的环境,才能够有效保证项目能够成功。

  其实大部份的返工不是技术上的应用问题,是业务上的应用问题,是界面定义的问题,是理解客户的期盼并构建可以提供预期效益和能力的问题。

Trufun十五年专注致力于软件工程全过程解决方案,提供从需求、分析、设计、开发到测试的完整管理开发过程,愿与各方进行科研、开发等方面的合作。


分享到: