软件项目需求开发过程实践之业务建模用例图

本次软件工程项目是重建办公业务流程管理平台,需要在继承原370个流程基础上,还需要提供快速流程开发能力,并要求体现出流程管理的规范性,以及流程的执行力、效率、效益,最终为企业管理创新提供流程再造的能力。

在项目前期及需求分析阶段,开发人员致力于“降低成本”,以最小的代价完成项目,其可预见性的软件产品是经过系统平台升级的,并经过改良的第二个办公业务流程管理平台。按客户验收要求,“只能打60分,是不能给予验收”。

在软件开发中,需求工作致力于解决“产品好卖”的问题,设计工作致力于解决“降低成本”的问题。二者不能相互取代。如果需求和设计不分,利润就会缩水。从需求直接映射设计,会导致功能分解得到重复代码。如果从设计出发找需求,会得到一大堆假的“需求”。

拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路,会跑步,会跳跃,会举重,会投掷,会游泳…。但是设计人体的内部结构时,不能从需求直接映射到设计,得到“走路子系统”、“跑步子系统”、“跳跃子系统”…。人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、 “神经子系统”“内分泌子系统”…..。

首先,回顾我们常用的软件需求开发过程。

1. 需求分析定义

在软件工程中,需求分析指的是在建立一个新的或改变一个现存的信息系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中,系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后,他们才能够分析和寻求新系统的解决方法。需求分析阶段的任务是确定软件系统功能。

2. 需求开发过程综述

(1)目的:

用以指导项目组客观、准确地识别和文档化客户及相关干系人的需求,并在已确认的用户需求基础上完成软件需求的分析及文档化工作。

(2)角色职责:

客户经理:协助项目经理与顾客的沟通与需求的获取。

项目经理:.负责全程的需求标识的管理。及时与顾客进行沟通,了解客户需求,审查客户所提需求,协调对需求标识的评审。

项目成员(需求开发人员):协助项目经理完成客户需求的收集;将收集的需求,通过分析、整理制作成文档;协助项目经理审查收集到的顾客的初始需求。

客户代表:尽可能完整、准确的提出系统所要求的目标、功能、性能、技术、界面、安全水平等需求。并对需求评审结果进行确认。

用户代表:为客户代表和项目成员提供业务需求,并对需求结果进行确认。

(3)输入:

所有与客户需求相关的材料。

(4)输出:

原始需求索引表;

用户需求说明书;

需求获取分析表;

需求用例文档;

软件需求说明书

(5)开发过程

图1

3、关键开发活动

(1)“确认用户需求”活动中,不仅要形成用户需求说明书(格式不限,只要求把需求描述清楚),还必须有用户方客户代表签字确认,最好内附用户代表确认签字。

(2)“评审需求文档”活动,不能省略,需要系统分析、设计人员全面了解、分析需求,确认需求分析描述清楚,并且不超出范围。

(3)“创建及发布需求基线”活动,通过此活动固化了需求,并要求创建需求跟踪矩阵。

接着,我们再重点说需求分析。

需求分析借助UML建模工具EA,通过EA进行业务建模和开发需求用例和对象模型。此段重点关注业务建模实践过程,回答办公业务流程平台要做什么?

1、业务建模

在业务建模用例图上表述出370个业务流程是不合适的,这些流程的功能基本是一致的。流程业务通常情况是这样的,工作人员填写业务申请单(填写表单),并准备好相关资料(添加附件),把业务申请单和资料打包(保存)后,送出传递给流程下一环节审批人办理。

既然要管理370个流程,而且是不停在变的流程,那么从流程建模开始,到流程上线应用、执行流程实例,再到对监控及分析流程,对流程的使用情况进行绩效管理。这样,流程再造是永恒的主题,这也是回答办公流程平台要做什么。至于快速开发流程、监控分析流程,以及体现执行力、效率等管理目标都是属于表面只管需求。业务建模是要通过信息化管理模型来提供有效流程再造的支撑,以此达到管理创新的终极目标。

图2

通过上述分析,业务建模就不必画具体流程用例,也不必画具体报表用例…。下图3才是办公业务流程平台系统核心业务模型用例,而资费审批流程、中层领导请假流程…,仅仅是流程模型【注:为图3中监管流程(定义)信息】不同。

图3

业务模型应用简单场景如下:

(1)通过快速开发流程(建模流程)用例,开发资费审批流程模型,并发布流程;

(2)申请、审批流程用例,是执行流程实例;

……。

2、系统平台建模

此系统平台用例,本不应该放在此处,但是,由于此项目的特殊性,建设目标之一是搭建办公能力平台,所以,就出现了系统平台建模,也可以看作系统用例。概念有些模糊,姑且先放在这儿。

图4

为什么需求经常“容易变化”?根源之一是它们的来路不正,一开始的时候是拍脑袋得来的,没有把系统当作一个零件放在组织中来看,得到的系统当然和组织的其他零件格格不入,系统上马磨合后发现问题,自然要改。“需求变化剧烈”只是一个假象,许多需求的变化是假的变化,真正的需求并没有变化,只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能,大多数假的需求变化会消于无形。

业务用例是组织的、而不是组织内某个系统的用例。组织的用例不会因为某个人肉系统或电脑系统的存在或消失而改变。

综上所述,软件项目需求开发过程中,业务建模是非常重要的活动,直接关系到项目的成败。而本项目实质是用户化的BPM,例如解决人员跨组织问题,以及提供流程业务数据统计支撑需求等。

参考及摘自:

《软件方法》UMLChina 潘加宇 2012.11

易扩展的办公流程化管理核心模型(第1版) 肖永威 2015.1

用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续) 肖永威 2015.1

时间: 2024-10-10 14:20:31

软件项目需求开发过程实践之业务建模用例图的相关文章

软件项目需求开发过程实践之软件需求说明书

软件需求说明书为谁而编写?把这个问题搞清楚是非常有意义的. 先讲个故事. 在软件项目开始时,需求及架构设计人员把需求和架构方案讲给开发人员听,开发人员还在设计"他那辆车",没有听明白?需求及架构设计人员接着写出一些列文档后,开发人员还在设计稍作调整"他那辆车",沟通出现了问题了吗?项目完成后,最后结果仍是开发人员所设计的,已经变形的"他那辆车". 问题的源头当然在需求,需求人员又如何把需求调研结果无损的分享给"相关人员"呢?其

软件项目需求评分表

   软件项目需求评分表 组序号:23      组成员:何健勋 王岸城 苏月          评分人:苏月 序 号 N(需求) A(方法) B(好处) C(竞争) D(交付) 1 -4 -4 -4 -4 -4 2 -3 -3 -3 -3 -3 3 3 3 3 3 1 4 -2 -2 -2 -2 -2 5 2 2 2 2 2 6 4 4 4 4 4 7 5 5 5 5 5 8 -5 -5 -5 -5 -5 9 -6 -6 -6 -6 -6 10 -1 -1 -1 -1 -1 11 8 8 8

有什么方式可以接软件项目需求,怎么接项目

软件团队最为关心的一点是在哪里可以找到项目做,也就是到哪里可以找到有软件需求的客户.对于一般人来说,广交朋友然后通过熟人介绍还是接项目的第一途径,但这要求你的朋友或熟人要在企业或公司里有比效重要的管理位置,对于像那些每天只能是埋头写代码的程序员这显然是不太现实的.所以大家不能等着项目来找你,而是要主动的出击去找项目.接项目最重要的一步是与客户谈需求.客户对软件的需求是项目规划和实施的根本,所以在与客户谈需求时,一定要让用户将所有的想法尽可能的阐述清楚,并把所有的要求罗列出来.这时候不应该害怕"勾

浅谈软件项目的需求管理

软件项目区别于其它项目的最显著的特征是其不可见性,它不像硬件购销.建筑工程,都是实实在在可见的东西.而软件项目在系统交付之前很长一段时间,客户是无法感知自己想要的系统究竟是什么样子.因此,需求管理就显得十分重要,据相关统计数据分析,软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的. 需求管理作为软件项目管理的一个重要内容,贯穿项目实施的全生命周期.俗话说:万事开头难.需求作为软件开发的第一个环节,其重要性不言而喻.市面上关于需求管理的相关理论和书籍很多,但多数停留在

【DDD】业务建模实践 —— 删除帖子

本文是基于上一篇‘业务建模战术’的实践,主要讲解‘删除帖子’场景的业务建模,包括:业务建模.业务模型.示例代码:示例代码会使用java编写,文末附有github地址.相比于<领域驱动设计>原书中的航运系统例子,社交服务系统的业务场景对于大家更加熟悉,相信更好理解.本文是[DDD]系列文章的第一篇,可参考:通过业务系统的重构实践DDD 业务建模 这里的‘删除帖子’场景是指帖子作者主动删除帖子,至于管理员通过后台管理端下线帖子,我们认为该行为不同于‘删帖’,需要单独处理. 我们来分析下“删除帖子”

软件项目与过程管理第八周作业

内容:软件项目与过程管理课程内容总结 经过八周时间的学习,软件项目与过程管理课程已经逐渐接近了尾声.通过这八周的学习,我对软件项目与过程管理课程有了更深的理解. 一.关于团队项目. 团队项目是本次软件项目与过程管理课程中最重要的一部分.我们团队项目是作业管理系统.在项目开发的整个过程中,我们在项目经理的带领下,项目团队的每一个成员团结合作.相互沟通,团队成员之间相互学习彼此的优点和技术,在每个成员的共同努力下,基本完成了此次软件开发项目. 通过这次团队项目, 我的总结如下: 1.在项目的开发过程

《JUST DO IT!》团队作业4-基于原型的团队项目需求调研与分析

一.实验目的与要求 (1)体验以原型设计为基础的团队软件项目需求获取技巧与方法. (2)学习利用UML模型描述用户需求. (3)编写软件需求规格说明书. 二.实验环境要求 (1)实验七开发的团队项目原型: (2)UML绘制工具. 三.实验内容与步骤 实施团队项目软件用户调研活动. 1.需求调研方法 (1)原型法 将我们APP端和WEB端的原型发给调研用户,用户通过使用反馈给我们一些意见和建议. (2)远程交流 我们选取典型用户通过qq在线交流的方式获得用户的需求,在了解完用户的需求过后将我们已经

A_Pancers团队作业4—基于原型的团队项目需求调研与分析

任务1:实施团队项目软件用户调研活动. (1)用户调研对象:我们的项目软件是基于安卓系统的音乐播放器,以设计出操作简单的音乐播放器为目的,所以本次用户调研的对象主要以身边的老人为主,对他们听音乐,听戏曲的情况进行了解,看他们对于音乐播放器有何需求,有何期待:并将我们设计出的项目模型对他们进行介绍,听取他们的意见和建议.另外考虑到为了获取更加全面的需求其他年龄阶段的人为辅助调研对象(例如:身边的同学.家长.朋友等). (2)调研方式:对于老人这个用户对象我们采取了面对面采访的方式进行调研,而对于其

有哪几种方式可以寻找APP项目需求资源

如今接项目的竞争越来越激烈,不单单是程序员或软件团队参与竞争,更有不少的正规的软件公司也加入其中,而软件项目相对比较少,因此如果想接到一个项目确实比较艰难.这里首先要牢记的一个字是快:就是比别人抢先一步先联系客户.客户都有一种先入为主的思想, 总是对于第一个联系他的人印象比较深刻,如果其他如价格方面又满意的话,十之七八就会把你作为承接项目的最佳人选.那如何去找APP项目需求呢1.社群社群是一个很不错的地方,长时间的积累软件开发群一定能让你获益匪浅,那么你就可以积累自己的客户资源,而且社群做的就是