UML 说明:模型,构造型为 <<business analysis>>。
业务分析模型可能有以下属性:
-
简介:文本描述,作为模型的简要简介。
-
业务系统:模型中的组件,表示层次结构。
-
业务工作者:模型中的业务工作者类,为业务系统所有。
-
业务实体:模型中的业务实体类,为业务系统所有。
-
业务事件:模型中的业务事件类,为业务系统所有。
-
业务规则:在模型中获取的业务规则。这些不是在单独工件中以文档形式捕获的业务规则。
-
关系:模型中的关系,为业务系统所有。
-
业务用例实现:模型中的业务用例实现,为业务系统所有。
-
业务环境协作:业务和业务参与者之间的交互的外部实现,显示由顶级业务系统(即业务本身)提供的服务、这些服务的接口、与业务参与者的连接以及业务实体输入和输出。
-
图:模型中的图,为业务系统所有。
请注意,业务本身是顶级组件(业务系统),并可以直接包括业务工作者、业务实体等等。
业务分析模型是在职责、可交付工件和协作行为方面表达业务流程的一种方式。如果要开发或部署新的软件系统,则为了评估系统对业务运作方式的影响,必须创建业务分析模型。通常从业务用例中忽略和排除部署新软件所引起的组织变更,这会导致工作中的软件系统无法使用。
如果未能生成业务分析模型,则意味着存在软件开发人员将不重视业务运作方式的风险。他们将按他们认为最好的方式来行事,即在缺乏业务流程知识的情况下设计和创建软件。结果可能是:建立的软件系统不支持业务需要。
我们已确定了定制业务分析模型的四个主要变体:
另请参阅指南:目标组织评估。
可以选择开发“不完整”的业务分析模型,侧重于说明对业务领域重要的“事项”和产品。这样的模型不包括人们将承担的职责;只描述组织的信息内容。这通常称为领域模型。在这种情况下,将模型构造成 <<领域模型>>,而不是
<<业务分析>>。领域模型对于为阐明和定义概念提供通用基础非常有用。关于更多信息,请参阅概念:领域设计。
如果业务建模工作的目的是进行业务(重新)设计,您应考虑建立业务分析模型的两个版本:一个版本反映当前状况,另一个版本反映预想的新流程(目标状况)。
业务分析模型的当前版本只是一份业务用例实现的清单。业务分析模型的元素未作详细描述。通常情况下,简短描述就足够了。 业务用例实现可用简单的活动图记录下来,其中的泳道对应着业务分析模型的元素。业务分析模型的目标版本需要的是大多数工作。
需要重新考虑当前流程和结构,并使其符合业务策略和目标。
当对业务创建(例如,新业务线或新组织)进行业务建模时,就没有创建“按现状”模型所能依据的现有业务框架。您应该在创建目标模型时参照业务体系结构和流程以获取帮助。
如果所有项目干系人和项目团队都能很好地理解业务分析,开发业务分析模型的好处就大大减少了。如果出现这种情况,可以完全省略业务分析模型。但是,至少开发一个最小业务分析模型通常是好主意,因为这会增进对项目干系人之间业务工作方式的了解。
|