需求二:
某个单位需要做一个任务分派和执行跟踪系统,业务流程大致如下:单位分两级,上级单位经办人建立一个任务,并分派下级单位负责人;下级单位负责人收到任务之后,指定下级单位具体经办人;系统要告知哪个任务分配给哪个下级经办人;下级经办人根据任务要求完成任务;系统根据任务限期时间,对于未完成任务的下级单位负责人和经办人发送提醒;系统对于超期完成的任务执行情况进行记录。
一个具体例子:上级经办人要求14个下级单位2013年1月1日前报送本单位人员花名册;14个下级单位负责人接到任务分派给本单位成员具体经办;下级单位成员上传本单位的花名册。
假如软件系统一(也就是满足需求一的软件)的研发者,得到需求二之后,无论如何都会期望能在软件系统一的基础上稍作修改以满足需求二。但是,以笔者不多的编程经验来看,这种“稍作修改”满足需求二的愿望很难实现。
首先,数据库模型就会有一些区别,这些区别大致如下:增加单位表,包涵单位名称、单位级别字段;增加单位级别表,级别Id、级别名称字段;增加单位职位表,包涵单位级别Id,职位名称(对应下级单位负责人和职员、上级单位只有职员)……
剩下的代码编写阶段需要对现有软件系统一做更大改动:1、新增表crud操作;2、大量的业务控制代码的添加。具体而言,需求二会有大量的权限控制代码需要加入到原有系统中,这就要求代码编写者熟知原有的代码,知道如何将权限控制代码加入到原先系统中穿插在众多crud操作中的业务控制部分。
当软件研发者咬牙在原有系统中加入了满足需求二的代码之后,新的需求犹如一头怪兽肆虐着研发者,考验着研发者的忍受底线。
客户提出新需求:为了提高效率,下级单位负责人可以手机接收任务短信,并通过回复短信的方式指定本单位经办人。
软件研发者:好的,可以实现。
客户新需求:上级单位只关心具体哪个下级单位未完成任务。但是,下级单位负责人关心未完成上级单位分派的任务以及该任务的经办人。
软件研发者:好的,可以实现。
客户新需求:下级单位分行政负责人和党务负责人,行政负责人负责行政任务的分派,党务负责人负责党务任务的分派。
软件研发者:嗯……好的。
客户新需求:单位分为三级,上中下。上级单位分派任务给中级单位,中级单位可以选择转发下级单位完成,也可以直接作为经办人完成。当然,上级单位可以直接越过中级单位分派任务给下级单位。
……
估计这个时候,软件研发者已经失去改造原有系统的想法了。但是,上述痛苦的过程对于软件研发者却时常重现。而导致这种现象发生的原因是什么?我任务主要原因有两点,一是没有挖掘,总结,抽象需求,导致软件不能适应需求变化;二是没有OO建模,实现对功能修改的关闭,对功能扩展的开放(开闭原则)。原有软件编写模式,随着数据库模型的修改,意味着可能产生大量关联数据的业务规则、流程。实现这些业务规则、流程需要在原有系统做“硬”代码修改,而这些修改很有可能就是“压死”改造原有系统想法的 “最后一根稻草”。
那么,适应需求不断变化的应对之策就是——如何挖掘,总结,抽象需求。
挖掘,总结,抽象需求说起来简单,实际做起来完全是一项经验活。不过,好在这个纯属脑力劳动,可以从手上现有小系统开始做脑力风暴式想象。比如,分析需求一的时候,可以扩展设问:公司就只有经理能分派任务吗?公司有没有上级机构?
由此可以抽象得出以下业务:
1、机构可分级。每个级别机构有不同的职位,具备不同的权限。
2、上级机构可创建,分派任务给下级机构。任务包括任务内容、要求、执行期限等。
3、下级机构接受任务,如果还有下级机构还可以分派。
4、机构管理人可以指定任务执行人。
5、系统根据未完成任务期限,提醒任务执行人。
6、系统接受任务执行人完成任务信息,如反馈文字或文档。
接下来,还可以展开设问:除了创建、分派、完成任务,还有什么关于任务的操作?每种任务是不是固定进行创建、分派、完成等操作,是否不同任务具备不同任务操作组合?
这样可以得出一个更为抽象的业务:
1、机构可分级。每个级别机构有不同的职位,具备不同的权限。
2、不同级别机构可对任务进行不同操作,例如上级机构可以创建任务,并分派给下级机构。
3、机构中不同职位人员可以进行不同的任务操作,例如机构负责人可以指定任务执行人;机构职员具体执行、完成任务。
4、本系统根据预先设定的任务操作序列来执行,例如一个任务操作序列是1、任务创建2、分派3、指定4、执行5、反馈等,并跟踪记录任务执行情况。
好了,当业务抽象到这一级别,可以发现,这个抽象业务能很大程度上适应需求的变化,无论是机构级别的改变、职位权限的不同、任务操作的变化等等。剩下的就是如何对这个抽象业务进行OO建模,代码实现了。
总结:为了适应变化的需求,就要在需求分析阶段开始总结、归纳、抽象业务。这个过程就像画同心圆,每一次抽象,得出的就是一个适应需求变化的更大同心圆。当然,每次抽象后,实现的难度会加大,抽象到什么层次结束,应该是受到成本、风险、系统愿景等因素控制。不管怎样,挖掘、总结、抽象业务这个过程使得需求分析,以及在此基础上进行软件设计,的重点回归到业务本身上。随着软件越来越复杂,花费在这方面的时间和精力产生的成果就越有价值。