您好,欢迎访问三七文档
需求分析师培训Day03Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结需求建模实例—确定业务需求总经理:为什么我们的开发项目进度计划总是那么不准确,延期经常出现,更可恨的是甚至无法给出一个相对比较明确的延迟时间。这样给市场的推广会带来很大的影响,不确定因素使得应对十分困难。研发经理:唉这个问题我花了很多时间来解决,但一直收效不好。最初我用WBS方法,根据用例包、用例的方式来组织需求,然后将某个用例或子用例作为工作任务分配的开发人员,并指定了相应的完成时间,但到了时间开发人员总是完不成,都反应时间安排不合理。后来,在技术顾问的指导下,改为自底向上的估计方法,任务明确后让开发人员反馈工作量及所需的工作天数。虽然有所好转,但还是有一些工作任务,开发人员反馈的天数到了,仍然无法完成,甚至无法告诉我要延迟多少天。汇总起来,就形成了这样的结果了。总经理:这样呀,那有什么好办法呢?技术顾问:其实问题的关键还是在于“估算”的经验上,对于软件开发而言,实际上没有万能的、准确的估算公式…需求建模实例—确定业务需求(研发经理抢过话题)研发经理:对对对!我一直在尝试使用FP、COCOMO模型来,仍然得不出合理的估计值,真难办。技术顾问:呵呵,急了!其实估算的基础是经验数据,对于不同的开发人员而言其产能是不一致的,甚至对于相同的开发人员而言,不同的任务所需的时间也是不同的。因此关键在于积累这种经验数据。例如,我在编写技术书籍时,就采用了PSP(个人软件开发过程)的思路,对所有的工作过程进行了时间的记录,在半年之后,就积累了许多相关的产能数据,现在给编辑的时间承诺总是能够比较的准确。总经理:哦,难怪你做的承诺都一般很少延误,这种经验能否适用于软件开发的管理呢?技术顾问:呵呵,这是当然。PSP是个人软件开发过程,它本来就是为软件开发设计。它是CMM的创始人提出的,PSP、TSP和CMM分别针对软件开发员、软件开发小组和软件开发组织。通过PSP的贯彻,就一定能够提高软件开发人员的时间安排、时间估算的能力。需求建模实例—确定业务需求研发经理&总经理(几乎同时):那我们就尝试一下!技术顾问:哈哈,不过贯彻PSP有两个困难。一是开发人员很难适应,每天都要记录自己的工作时间很繁琐,而且产生数据不容易使用;二是时间日志做出来后,管理者会忍不住用来考核开发人员,给他们带来心理压力。研发经理:那我们可以开发一套软件来帮助他们记录,通过写到数据库中,这样数据的使用问题也就解决了。技术顾问:对,这就是我的建议。那后者呢?总经理:我们不考核就是了!技术顾问:没那么简单!我认为要从以下几点来进行:一是鼓励,鼓励记录时间日志,奖励估算准确的开发人员,从而避免做假时间的情况;二是宣扬,宣扬有效工作时间的概念,我的经验是每个开发人员一天有效的工作时间在4个小时之上就是比较好的,树立这种概念能够打消开发人员的顾虑;三是培训,从理论高度建立开发人员执行PSP的意识。需求建模实例—确定业务需求总经理:好!我修订绩效考核,解决鼓励问题;小陈(研发经理),我配合你树立“每天有效工作4小时”的概念;至于培训嘛只好拜托你了。技术顾问:好!没问题。为开发人员提供一个PSP工具,简化时间记录工作;同时提供数据使用的工具,帮助开发人提高估算能力。需求捕获技术顾问:根据我的经验,整个系统应该包括以下几个主要的方面。第一,项目及任务安排,由研发经理或项目经理创建项目和任务,开发人员在接到任务后进行估算填写时间计划,研发经理或项目经理对其进行确认。第二,时间记录,开发人员对自己的开发时间进行记录,与任务关联起来。第三,产能分析,研发经理及公司领导可以根据任务和相应的时间记录,来统计公司员工的产能数据。开发人员甲:我认为,开发人员自己应该能够通过这套系统来统计自己的产能数据。研发经理:那么产能数据怎么表示呢?任务可是不同的呀。技术顾问:我认为比较合适是KLOC/天(每天编写的千代码行数)。开发人员乙:但不同的程序KLOC可能接近,但难度不同所花的时间是不同的。技术顾问:对,我们可以在每个任务中加上难度系数,产能中的KLOC=实际的KLOC*难度系数。研发经理:那么测试任务怎么算?需求捕获技术顾问:我认为这套系统主要关注的是开发时间、而对于前期的分析和概要设计,以及后续的集成和系统测试等工作可以先忽略,放在系统范围之外,这里只考虑详细设计、编码和相应的测试工作。研发经理:我明白了,就是对于一个任务而言所花的时间。对,这样比较合理。开发人员甲:我希望系统能够在让我们填写估算值时,可以查询历史数据,否则仍然没有意义。开发人员丙:查询历史数据时,还应该有类别吧!这样我们才能够根据自己将要完成的任务情况找到有参考依据的统计数据。开发人员乙:还有就是时间记录一定要方便,另外像我们这样经常要在现场开发,如何完成时间记录?研发经理:可以考虑有一个离线版本的时间记录程序,等回公司连接服务器后再进行数据同步。……获取需求特性表编号特性FEAT01研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目FEAT02项目经理可以对项目设置工作包,工作包允许多级嵌套,它只用来组织工作任务FEAT03项目经理可以为开发人员指派工作任务,工作任务属于特定的工作包FEAT04项目经理在分配工作任务时,能够查阅开发人员的日程安排表,可以按开发人员查询、也可按日程查询FEAT05开发人员接到任务时,通过系统填写计划时间(计划开始时间和计划结束时间),项目经理确认后,更新日程安排表FEAT06开发人员可以查询相近工作任务的历史数据(估算数据、实际数据)FEAT07开发人员任务执行将超计划时,应报告项目经理,项目经理通过系统更新其日程表FEAT08当任务完成之后,项目经理负责Close任务,并填入实际的完成情况(KLOC、实际结束时间)FEAT09开发人员可以随时记录自己的时间,提供“开始计时”、“暂停计时”、“停止计时”,在停止时,填入任务编号(在线则选择)、工作关键字(以逗号分隔的多个),自动生成开始时间、暂停时间、停止时间、总时长、有效时长(总时长-中断时长)FEAT10开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计FEAT11时间记录程序会自动连接服务器,完成时间日志上传的工作,未能连接服务器,则在本机暂存时间日志FEAT12项目经理可以按项目、任务、关键字统计实际工作时长、产能FEAT13研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能建立概念模型—发现类研发经理项目项目经理工作任务工作包开发人员日程安排表计划时间历史数据估算数据实际数据任务编号工作关键字开始时间暂停时间停止时间总时长有效时长服务器产能管理层时间日志项目工作任务工作包开发人员日程安排表时间日志建立概念模型—关联分析建立概念模型—职责分析建立用例模型—识别参与者建立用例模型—合并特性获得用例参与者特性用例开发人员FEAT05.开发人员接到任务时,应通过系统填写计划时间(计划开始时间和计划结束时间),项目经理确认后,更新日程安排表UC01.填写任务计划FEAT06.开发人员可以查询相近工作任务的历史数据(估算数据、实际数据)FEAT10.开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计UC02.查询历史任务数据(UC01的扩展)FEAT09.开发人员可以随时记录自己的时间,提供“开始计时”、“暂停计时”、“停止计时”,在停止时,填入任务编号(在线则选择)、工作关键字(以逗号分隔的多个),自动生成开始时间、暂停时间、停止时间、总时长、有效时长(总时长-中断时长)FEAT11.时间记录程序会自动连接服务器,完成时间日志上传的工作,未能连接服务器,则在本机暂存时间日志UC03.记录时间日志建立用例模型—合并特性获得用例项目经理FEAT02.项目经理可以对项目设置工作包,工作包允许多级嵌套,它只用来组织工作任务UC04.设置工作包FEAT03.项目经理可以为开发人员指派工作任务,工作任务属于特定的工作包FEAT04.项目经理在分配工作任务时,能够查阅开发人员的日程安排表,可以按开发人员查询、也可按日程查询UC05.分配工作任务UC5A.查看日程安排(扩展用例)FEAT07.开发人员任务执行将超计划时,应报告项目经理,项目经理通过系统更新其日程表UC06.更新日程表FEAT08.当任务完成之后,项目经理负责Close任务,并填入实际的完成情况(KLOC、实际结束时间)UC07.关闭工作任务FEAT12.项目经理可以按项目、任务、关键字统计实际工作时长、产能UC08.统计项目产能研发经理FEAT01.研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目UC09.管理项目信息管理层FEAT13.研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能UC10.统计团队产能建立用例模型—绘制用例图建立用例模型—简要描述用例用例编号UC01用例名称填写任务计划用例概述开发人员对项目经理安排给自己的工作任务进行计划,填入计划开始时间和计划完成时间。主参与者开发人员补充说明在填入计划开始时间和计划完成时间时,开发人员可以查询与该任务的关键字相关的历史任务的数据。建立用例模型—划分用例优先级优先级用例说明1UC11.登录系统系统使用的基础,并且可复用原有资源UC09.管理项目信息UC04.设置工作包UC05.分配工作任务UC01.填写任务计划任务管理的完整流程,是记录时间日志的基础UC03.记录时间日志系统核心功能2UC07.关闭工作任务只是对任务信息进行更新,重要性次之UC06.更新日程表UC5A.查看日程安排对日程安排进行优化,使任务安排合理化3UC02.查询历史任务数据UC08.统计项目产能UC10.统计团队产能对系统记录的时间记录进行有效的利用,必须有前面的信息才能够开发UC12.管理用户前期可以通过直接往数据库中写值的方式进行使用,最后提供界面操作即可建立用例模型—详细描述用例用例编号UC03用例名称记录时间日志用例概述开发人员可以随时记录自己的时间,提供“开始计时”、“暂停计时”、“停止计时”等功能,在停止时,填入任务编号(在线则选择)、工作关键字(以逗号分隔的多个),自动生成开始时间、暂停时间、停止时间、总时长、有效时长(总时长-中断时长)。主参与者开发人员前置条件用户进入“记录时间日志”程序后置条件将本次时间日志存入数据库基本事件流步骤活动1系统显示“开始”、“暂停”和“停止”按钮,但仅“开始”可用2用户点击“开始”,系统记录开始时间,并将“开始”置为不可用,使“暂停”和“停止”按钮可用3用户点击“停止”按钮,系统记录停止时间,并统计暂时时间、暂停次数、总时长、有效时长,并要求用户选择任务编号、输入工作关键字和相关信息。填写完成后,点击确定,用例完成。扩展事件流3a在此期间,若用户点击“暂停”按钮,系统则记录暂停开始时间,并使暂停次数增加1次,并使“暂停”按钮变为“恢复”,使“停用”按钮不可用3a1当用户点击“恢复”按钮,用当前时间减去暂停开始时间得到本次暂停时间,并累加到“暂停时间”时间中,并使“恢复”按钮变为“暂停”,使“停用”按钮恢复可用规则与约束时间记录程序应以离线式工作,该程序会自动连接服务器,完成时间日志上传的工作,如果未能连接服务器,则在本机暂存时间日志建立交互/状态模型用户界面设计Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结业务流程是信息系统的主脉落业务规则是变化的要点什么是流程目标性:有明确的输出内在性:包含于任何事物或行为中整体性:至少由两个活动组成动态性:由一个活动到另一个活动进行层次性:组成流程的活动本身也可以是流程结构性:串联、关联、反馈等流程设计的原则流程应以产出为中心,而非任务为中
本文标题:需求分析师培训-3
链接地址:https://www.777doc.com/doc-989915 .html