1对软件研发过程中用户需求研发设计项目测试交付实施测试等流程监督管理

1、软件工程治理流程总结1 .风险评估2 .本钱预算3 .客户沟通的过程4 .需求分析5 .面向对象程序设计(略)6 .开发治理7 .产品交付一、风险评估软件工程风险是指在整个工程周期中所涉及的本钱预算、开发进度、技术难度、经济可行性、平安治理等各方面的问题,以及由这些问题而对工程所产生的影响.工程的风险与其可行性成反比,其可行性越高,风险越低.软件工程的可行性分为经济可行性、业务可行性、技术 可行性、法律可行性等四个方面.而软件工程风险那么分为产品规模风险、需要风险、相关性 风险、治理风险、平安风险等六个方面： 1.产品规模风险工程的风险是与产品的规模成正比的,一般产品规模越大, 问题就越突出.

2、尤其是估算产品规模的方法,复用软件的多少,需求变更的多少等因素与产品风险息息相关： 估算产品规模的方法(2)产品规模估算的信任度(3)产品规模与以前产品规模平均值的偏差(4) 产品的用户数(5) 复用软件的多少(6) 产品需求变更的多少2. 需求风险很多工程在确定需求时都面临着一些不确定性.当在工程早期容忍了这些不确定性,并且在工程进展过程当中得不到解决,这些问题就会对工程的成功造成很大威胁.如果不限制与需求相关的风险因素,那么就很有可能产生错误的产品或者拙劣地建造预期的产品.每一种情况对产品来讲都可能致命的,这些的风险因素有：(1) 对产品缺少清楚的熟悉(2)对产品需求缺少认同在做需求分析过

3、程中客户参与不够(4)没有优先需求由十/、确无的需要导致新的市场(6)不断变化需求缺少有效的需求变化治理过程(8)对需求的变化缺少相关分析等3. 相关性风险许多风险都是由于工程的外部环境或因素的相关性产生的.限制外部的相关性风险,能缓解策略应该包括可能性方案,以便从第二资源或协同工作资源中取得必要的组成局部,并觉察潜在的问题,与外部环境相关的因素有：(1)客户供给条目或信息(2) 交互成员或交互团体依赖性(3)内部或外部转包商的关系(4) 经验丰富人员的可得性工程的复用性4. 技术风险软件技术的飞速开展和经验丰富员工的缺乏,意味着工程团队可能会由于技巧的原因影响项目的成功. 在早期,识别风险从

4、而采取适宜的预防举措是解决风险领域问题的关键,比方:培训、聘请参谋以及为工程团队招聘适宜的人才等.关于技术主要有下面这些风险因素：(1) 缺乏培训(2) 对方法、工具和技术理解的不够(3) 应用领域的经验缺乏(4) 对新的技术和开发方法应用不熟悉5. 治理风险尽管治理问题制约了很多工程的成功,但是不要由于风险治理方案中没有包括所有治理活动而感到惊奇.在大局部工程里, 工程经理经常是写工程风险治理方案的人,他们有先天性的缺乏一一不能检查到自己的错误.因而,使工程的成功变得更加困难.如果不正视这些棘手的问题,它们就很有可能在工程进行的某个阶段影响工程本身.当我们定义了工程追踪过程并且明晰工程角色和

5、责任,就能处理这些风险因素：(1) 方案和任务定义不够充分(2) 对实际工程状态不了解(3)工程所有者和决策者分不清(4) 不切实际的承诺(5) 不能与员工之间的进行充分地沟通(6) 平安风险软件产品本身是属于创造性的产品,产品本身的核心技术保密非常重要.但一直以来,我们在软件这方 面的平安意识比拟淡薄,对软件产品的开发主要注重技术本身,而忽略了专利的保护.软件行业的技术人员流动是很普遍的现象,随着技术人员的流失、变更,很能会导致产品和新技术的泄密,致使我们的软件产品被它公司窃取, 导致工程失败.而且在软件方 面关于知识产权的认定目前还没有明确的一个行业标准,这也是我们 软件工程潜在的风险.7

6、. 回避风险的方式(1)以开发方诱导能保证需求的完整,使需求与客户的真实期望高度一致.再以书面方便 形成?用户需求?这一重要的文档,预防疏漏造成的损失在软件系统的后续阶段被逐步地放(2) 设立监督制度,工程开发中任何较大的决定都必须有客户参与进行的,在该工程中项目监督由工程开发中的质量监督组来实施.(3) 需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可 ,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况.(4)限制系统的复杂程度,过于简单的系统结构,对用户来使用比例会有明显的折扣,甚 至造成软件寿命过短.反之,软件结构的过于灵活和通

7、用,必然引起软件实现的难度增加, 系统的复杂度会上升,这又会在实现和测试阶段带来风险.适当限制系统的复杂程度有利于降低开发的风险.(5) 从软件工程的角度看,软件维护费用约占总费用的55%70% ,系统越大,该费用越高.对系统可维护性的轻视是大型软件系统的最大风险.在软件漫长的运营期内,业务规那么肯定会不断开展,科学的解决此问题的做法是不断对软件系统进行版本升级,在保证可维护性的前提下逐步扩展系统. (6) 设定应急方案,每个开发方案都至少应该设定一个应急预案去应对出现突发情况和不 可遇知的风险.回到目录 二、本钱预算(1) 本钱预算方式(1)自上而下的预算方法 自上而下的预方法主要是依据上层

8、、中层工程治理人员的治理经验进行判断,对构成工程整体本钱的子工程本钱进行估计,并把这些判断估计的结果传递给低一层的治理人员,在此基础上由这一层的治理人员对组成工程的子任务和子工程的本钱进行估计,然后继续向下一层传递他们的本钱估计,直到传递到最低一层.使用此预算方式,在上层的治理人员根据他们的经验进行的费用估计分解到下层时,可能会出现下层人员认为上层的估计缺乏以完成相应任务的情况.这时,下层人员不一定会表达出自己的真实观点,不一定会和上层治理人员进行理智地讨论,从而得出更为合理的预算分配方案.在实际中,他们往往只能沉默地等待上层治理者自行发现问题并予以纠正,这样往往会给工程带来诸多问题. 自上而

9、下更适用于工程启动的前期,与真实费用相差在30%70% 之间.Scrum 使用自上而下的本钱预算方式,它不会立即精确地确定本钱,而是以最大限度容纳 客户对未来产品要求所产生的变更. (2)自下而上的预算方法 自下而上方法要求运用 WBS (Work Breakdown Structure ,工作分解结构)对工程的 所有工作任务的时间和预算进行仔细考察.最初,预算是针对资源(团队成员的工作时间、 硬件的配置)进行的,工程经理在此之上再加上适当的间接费用(如培训费用、治理费用、 不可预见费等)以及工程要到达的利润目标就形成了工程的总预算.自下而上的预算方法要求全面考虑所有涉及到的工作任务,更适用于

10、工程的初期与中期,它能准备地评估工程的成本,与真实费用相差在 5%10% 之间.注解：WBSWBS是面向提交成果对工程的分解,从提交成果的列表可以确定每个提交成果需要执行的 活动.Scrum 会对WBS进一步细化,把一个迭代分解为一个或多个的工作包,再把工作 包分解为细小的开发任务(一般开发任务的开发周期在 15个工作小时以内). 2. 确定工程支出 总体本钱预算就是结合以下多个本钱预算方式综合计算的开发本钱： (1) 零基数预算 在本钱预算的初期应该使用零基数的计算原那么,而不可以使用类似于： 以上一年总体费用加上20%这样粗略的方式计算工程本钱.(2) 软硬件本钱、物品本钱物品本钱是指类似

11、于：效劳器(RAM硬盘CPU NIC卡RAID簇)本钱、维护本钱、机房 租金、光纤通讯本钱、软件本钱等的本钱.计算本钱时需要考虑组装硬盘需时的长短,技术人员需要具备的质素,产品供给商能否提供保证质量,治理时是否需要额外的治理人员这些多方因素.(3) 软件许可证本钱(4) 外包本钱当使用类似：视频、短信、移动电信类效劳、门户网站等子工程时可以考虑以外包形式完成, 以降低开发本钱.(5) 人力资源本钱计算人力资源本钱时应该使用以最高和最低的工作效率估算平均效率的方式,计算出人力资源的平均本钱.(6)维修保养本钱回到目录三、客户沟通的过程从客户沟通的方向出发来看,软件工程可分为：需求识别、方案定制、

12、工程实施、工程结束等4个不同的阶段,各个阶段都具有不同的沟通重点.1.需求识别阶段(1) 文本沟通在需求识别的前期,应该通过问卷、原型展示、界面展示、逻辑处理展示、准化文档模板等方式进行全方位多角度的分析,随时将不明确之处反响给客户,以期待客户解答.并以文本记录的方式建立需要分析书, 并要求客户审核需求分析书, 以到达需要分析与客户的真实期 望高度一致的结果.(2) 业务逻辑沟通在进行业务沟通时, 应该了解客户的行业语言, 以促进业务分析的过程, 越过应用需求和开 发之间的鸿沟.沟通过程提倡以草图或者可视信息化的方式进行 ,针对不同层面的企业用户 提供最适合的操作界面.以多角度的方式思考问题,

13、要抓住需求重点,尤其是客户方领导所关注的创新类和实用类需求.(3) 需求变更的标准化治理需求变更在软件开发类工程中是可以理解的,但必须对需求变更做好标准化的治理,以预防出现需求无止境变更的风险.需求变更必须由统一的负责人提出,并且由用户需求的审核领导者认可.需求变更的提出应该是定期而不是随时的,开发方应该做好详细的文本记录,让客户了解需求变更的实际情况和开发方为之所付出的本钱代价.2 .方案定制阶段该阶段工程的主要任务是与客户共同制定一个以前期明确的需求、双方的资源、工程开始的阶段、实施的时间约定、工程费用限制等为根底的具有可操作性的工程方案,从本阶段开始争取客户全面参与工程的治理,并以双方的

14、共同利益考虑工程实施的具体方案与风险躲避.3 .工程实施阶段在该阶段,软件工程团队应该与客户共同领导工程的实施.同时,工程团队应实时评估客户满意度,并通过持续改良的方式提升客户满意度 ,还应要求客户参加必要的培训 ,以及在必要时 检查工程产品.在出现客户的需求变更前,应主动与客户沟通交流,使客户充分了解工程的每 个环节,以及变更带来的影响,减少需求变更.如果出现客户需求变更 ,应与客户一起共同解 决由变更引起的本钱、进度、质量变化.4 .结束阶段该阶段主要进行工程成果的移交,并把系统交付给维护人员,帮助客户实现商务目标, 结清各种款项.完成这些工作后应该进行工程评估,审核此工程的成果并总结工程

15、经验.5 .售前人员考前须知在产品型工程作为开发成果时, 相关销售人员应该注意： 对产品的推销不应该过分承诺. 如 果过分承诺,会给后续的工程实施带来困难 ；一旦承诺没有兑现,也会降低客户满意度,影响今 后合作.如果有附加承诺,一定要以文本形式记录,让实施工程经理知晓并传达给工程组成注解：在软件工程中,需要明确以下四种客户角色A.要明确最终使用部门和用户,要去了解他们现有的工作方式,要让他们知道工程的目标 框架,知道工程要解决他们的哪些困难,但绝对不是全部困难,这样可以较好的限制工程范 围.B.要明确需求的提出者,他或者他们要能够代表最终客户群体.提出产品需求的这类客户 要具有一定的技术、业务

16、水平和权威,能够真正代表最终客户团队的意愿和想法,最好有IT 根底,能够用IT语言描述问题和需求,以利于双方的沟通、协作,预防产生歧义.C.要明确做需求确认的中层领导,他要把握方向.软件开发工程是解决实际生产或者治理 问题,同时 也是领导系统建设的具体实现,做需求确认的客户领导,既要了解高层领导的系 统建设要点和方向,又要谙熟具体业务和生产治理实际.如果是这样的客户领导来把 握和决 策,对企业软件开发工程的顺利进展作用非凡.D.要明确谁来对成品提意见,谁来验收.工程验收环节,是工程的收尾环节,如果验收的人 对工程初期的需求目标不了解,会从态度和产品实际使用效果上对验收产生负面的影响,对 提供产

17、品的企业关闭工程非常不利.根据实践总结,由需求提出人和确认人来做项 目的验收 工作,能够促进工程的顺利完成,预防延期.回到目录 四、需求分析1. 需求分析的过程需求过程包括需求开发和需求治理2个局部：(1) 需求开发就是对开发前期的治理,与客房的沟通过程, 可以分为4个阶段：需求获取、需求分析、编写需求和需求验证.(2) 需求治理：就是软件工程开发过程中限制和维持需求约定的活动.包括：变更限制、 版本限制、需求跟踪、需求状态跟踪.2. 需求的层次需求的层次包括：业务需求、用户需求、功能需求、非功能需求等4个方面.3. 需求开发阶段的重点(1) 提取业务对象业务对象是指系统使用的真实对象,例如一

18、个供给链治理 (Supply Chain Management ,简称SCM)业务对象主要包括：生产批发商、零售商、送货商、顾客多个层次.(2) 提取业务流程在了解业务逻辑的过程中,应该列举出所开发软件模块的各自职能,并细化每个工作流程, 深入分析业务逻辑.(3) 性能需求在分析的前期应该注意客户对所开发软件的技术性能指标,如存储容量限制、运行时间限制、平安保密性等.(4) 环境需求环境需求是指软件平台运行时所处环境的要求,如硬件方面：机型、外部设备、数据通信接口；软件方面：系统软件,包括操作系统、网络软件、数据库治理系统方面；使用方面：使用部门在制度上,操作人员上的技术水平上应具备怎样的条件

19、.(5) 可靠性需求对所开发软件在投入运行后发生故障的概率,应该按实际的运行环境提出要求. 对于重要的软件,或是运行失效会造成严重后果的软件,应提出较高的可靠性要求.(6) 平安保密要求在需求分析时应当在这方面恰当地做出规定,对所开发的软件给予特殊的设计,使其在运行中,其平安保密方面的性能得到必要的保证.(7)用户界面需求为用户界面细致地规定到达的要求.(8)资源使用需求开发的软件在运行时和开发时所需要的各种资源.(9)软件本钱消耗与开发进度需求在软件工程立项后,根据合同规定,对软件开发的进度和各步骤的费用提出要求,作为开发治理的依据.(10)开发目标需求预先估计以后系统可能到达的目标,这样可

20、以比拟容易对系统进行必要的补充和修改.4. 需求分析的任务需求分析的主要任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型,其流程如下：确定对系统的综合需求(功能、性能、运行、扩充需求)(2)制作产品需求文档 (PRD)(3) 分析系统的数据需求(概念模型、数据字典、标准化)(4)导出目标系统的详细的逻辑模型(数据流图、数据字典、主要功能描述)(5) 开发原形系统(6) 从PRD提取编制软件需求规格说明书(SRS )注解：SRS格式1 .引言2系统概述(工程背景、系统目标、核心业务流程)3.术语说明4.系统结构(架 构图、功能图)5.主体功能与业务逻辑(重点)6.接口需求(内部、外部接口、)

21、7.网络总体设计(拓扑网络、主机、组网)8.运行环境(Linux、Windows 、IIS、WebLogic、Tomcat、OLAP、OLTP、JDK 8.0 、.NET Framework 4.0等)回到目录5、 面向对象程序设计(略)(1) 设计原那么(1) SRP单一责任链每个类都应该只负责做一件事.(2) OCP开封闭合原那么软件的实体(类、模块、函数等)应该是可以扩展的,但是不可修改的.(3) LSP替换原那么子类必须能替换他们的基类型.(4) DIP依赖倒置原那么高层模块不应该依赖于低层模块,二者都应该依赖于接口与抽象类.抽象不应该依赖于细节,细节应依赖于对象.(5) ISP接口隔

22、离原那么不应该强迫客户依赖于并未使用的接口,而应该把胖接口别离.(2) 实现UML建模(3) 业务对象的提取(4) 根据SRS、CRC等实现用况建模(5) 实现业务顺序图(6) 建立类图,根据用况图建立对象之间的关联(7) 绘制活动图、实现协作图、状态图回到目录6、 开发治理1. 建立工程方案(1) 设计总体架构针对系统的实施需要,采取适当的且成熟的框架结构.(2) 限制可扩展度扩展度过大,将提升系统的复杂程度,延长开发时间；扩展度过低,会直接影响系统的二次开发与维护.限制系统的可扩展性,能提升开发效率,降低系统维护的难度.(3) 建立根底设施合理分配部署软、硬件等根底设施所需要的时间与本钱(

23、例如：效劳器的订购安装、光纤接 入、软件平台订购).(4) 划分开发任务利用 WBS (Work Breakdown Structure ,工作分解结构)对可交付结果进行分类与划分.每个工程都能划分为多个不同阶段,每个阶段又可以分为多个工作包(Work Package ),工作包是WBS里最小的可交付结果,最后从工作包中分解出多个开发任务列表.(5) 部署开发进度一个工程应该按进度划分为多个开发阶段,每个阶段的开发周期一般在3060 个工作日以内.在此阶段内应该与客户举行协商会议,制定产品路线图,在开发过程中邀请客户积极参与并提出反响意见. 然后把该时段内的开发任务根据开发难度,依赖性,重要性

24、等多方条件划分为多个迭代周期.在Scrum 敏捷软件开发原那么中, 应该把每个迭代任务进一步细分为多个开发任务列表,再开发任务分配给组员各自负责,而开发时间应该限制在 15个工作小时以内.如果开发时间超出15个工作小时,应该考虑把开发任务再度细化.开发任务建议应该由组员自主选择, 而不要使用强制分配的方式.测试工程成果每个工作包都应该同步部署测试工作,提升工程的质量.对出错 BUG的工作包应该由测试人员以文本方式记录,向开发人员展示错误所在,让开发人员及时进行修改.2. 治理开发团队组建团队根据工作任务与工程时间的前提条件建立团队,按团队责任分配人员, 一般团队人数应该控制在812人之间.当团

25、队人数超过 15人时,应该考虑把团队分解成 2个独立团队,负 责不同的开发任务.(2) 分配开发任务在每个迭代周期内(一般是1530 个工作日),应该把每个工作包进一步细分为多个开发任务,再开发任务分配给组员各自负责,开发时间应该限制在15个工作小时以内.如果开发任务的开发时间超出 15个工作小时,应该考虑把任务再度细化.而开发任务应该以自由 选择的方式分配给每个组员.(3) 监督开发进度在迭代的前期举行一次会议,让组员了解开发的进展及流程,并以自主选择的方式分配开发任务.期间可使用 Microsoft Project等工具记录开发流程的进展,在每个工作包完成开发后应该进行性功能的测试,并以文

26、本方式记录测试结果.每天举行一次15分钟的站立会议,让组员交待昨天已完成的开发任务,当天将要做的任务,与开发过程中所遇到的问题.并在每周末举行一次例行会议,交待总体进程.在迭代末期举行一次冲刺会议,总结工程的进展,交行已完成的任务,回忆该迭代周期内所遇到的问题,为下一个迭代做好准备.(4) 系统测试对每个已完成的工作包进行适时的测试,保证系统质量与性能.对测试结果进行文本的记录,并把测试结果与绩效工资收入挂钩,并以真实数据计算组员的绩效收入.(5) 解决开发中所遇到的问题对开发人员进行前期培训,可适当按工作水平分配任务,指导组员的开发.当遇到问题时应该在当天的站立会议时即时提出,并在15个工作

27、小时内解决所遇到的问题以预防问题进一步扩大.3. 监管产品质量(1) 质量需要的是方案、设计而并非审查的.在产品建立的初级,必须与质量保证(QA) 的部门进行协商,以正式文档的方式,决定恰当的质量策略和标准.(2) 在开发过程中使用 TDD (测试驱动开发)的模式,提升开发质量.测试人员应该以文 本方式记录bug ,并与开发人员共同工作的,把突出的缺陷演示给开发人员,以提升修改 的效率.(3)在每个迭代的结束时进行一次产品效果的演示,从客户、使用者、高层领导中收集反 馈信息.在团队内部举行评审会议,分析测试结果,了解产品性能,为下次迭代所需要做的改良做好方案.4. 修改工程方案(1) 在产品需

28、要识别阶段,应该以文档形式记录产品功能与开发流程,在开发方案需要修 改时,应该与客户共同探讨,让客户了解方案修改对工程进度所造成的影响.(2)工程方案的修改应该由统一的负责人提出,并且由用户需求的审核领导者认可.需求变更的提出应该是定期而不是随时的.(3) 方案的变更应该做好详细的文本记录,让客户了解需求变更的实际情况和开发方为之 所付出的本钱代价.回到目录 七、产品交付1. 工程的后期审核在工程开发最终完成后, 对开发人员来说可算是放下工作的重担,但对工程经理来说这往往是工程的关键时刻. 前期的风险评估、本钱预算、需求分析、软件设计都是为了引导工程走向这一时刻,此时所有的目光都将投向工程治理

29、人员.你可能发现大量而琐碎的工作将要在几个小时内完成,此刻工程经理更需要保持清醒与镇定,把最后的工作视为微型工程来对待.细致地对工程进行后期的审核,分析工程成果、工程团队的效率、可交付产品的价值,以此审核结果可作为工程治理经验总结的一局部.2. 质量评审在工程交付前,应该把工程交给相关的旗量保证(QA)部门进行质量评审,并邀请典型用户感受产品的质量.3. 工程的最终交付正常情况下在工程的前期就会订立工程交付的协议,工程交付方式分为非正式验收与正式验收两种.一般在工程完成后都会先进行非正式验收,让客户体会工程的质量并提出反响意见,最后在客户肯定产品质量后再以书面协议的形式进行正式的产品验收.4.

30、 工程的最终报告在工程的最后,应该制定工程的最终报告,此报告可以视为是对该工程一个记录,但报告不必包含工程的所有方面.一般最终报告应该包含以下方面：(1) 最初引进工程时的初期工程视图(2)对该工程的价值评估及支持性信息(3) 工程的范围(4) 工程的开发流程及 WBS(5) 工程的会议记录(6) 工程变更的报告及变更的理由(7) 与工程相关的沟通过程文件(8)工程的审核报告与客户验收报告(9)工程成员的表现报告(10)工程的最终成果目录产品研发过程常见问题产品研发过程常见问题 产品研发过程常见问题 产品研发过程常见问题 产品研发过程常见问题 产品研发过程常见问题【场景2】：研发过程衔接不畅公

31、司的需求治理、方案治理、缺陷跟踪、 发的无法整合的工具, 这些不同来源的工具, 又无法在各种不同类型的数据之间建立关联,测试治理等等各种研发活动,使用不同公司开 既无法共享工程信息,给使用上带来很多不便,导致一些高级治理功能无法实现,比方要实现1:缺乏统一的治理平台2:难以量化的需求开发与治理3:跨部门协作困难4:多工程治理挑战多1 :缺乏统一的治理平台随着软件开发实践的不断深入,应用生命周期治理越来越被业界接受为一种经过实践检 验的,可以创造高品质的应用程序的,可靠的软件开发模式.但是,要实施整个应用程序生命周期治理是非常复杂的,我们必须借助一些工具来帮助我们完成整个生命周期的治理.让我们先

32、往返忆一下绝大多数软件研发团队的典型工作情景：【场景1：工具满天飞很多研发企业的治理平台非常分散,不同团队和个人使用工具不同,我们常常可以看到,产品部门收集需求使用Word、Excel ,工程经理制定工程方案、进行任务划分和分配使用Project ,开发部门治理任务和缺陷使用Jira、URTracker ,测试部门治理测试任务使用TestDirector、TestLink ,配置治理使用 VSS、SVN、CVS、CC等等,这些平台相互是独 立的,不仅不可以信息共享,部门之间还产生了有明显的信息壁垒,完全靠手工操作实现信息传递.需求跟踪,就需要整合需求治理、任务治理、测试治理三个系统.【场景3：

33、一个BUG引发的血案?!软件开发人员1:通过代码走查发现一个 BUG ,需要将这个BUG记入缺陷跟踪系统； 软件开发人员2代码的作者：需要根据这个缺陷判断需要如何修改,并评估修改的工作量.如果是普通的 BUG ,只需要开发人员进行修改即可；一旦发现是深层次的 BUG ,涉及到数据结构的调整、界面的调整甚至软件架构的调整,这将牵动研发团队的 工程经理、系统架构师、数据库治理员、界面设计人员、产品经理 ；工程经理：收到开发人员的汇报,很不幸的发现这个问题需要在缺陷跟踪系统中将相关的人员统统拉到一起才可以解决问题；产品经理：需要根据缺陷评估即将投入的人力本钱和由此引发的后果；系统架构师：评估架构调整

34、的本钱并拿出可行性方案；数据库治理员：调整数据结构,并为由此带来的数据结构升级准备方案；界面设计人员：重新调整界面,并为原来统一白风格如何调整伤透脑经；软件开发人员3最终确定FIX BUG的人员：根据最终收到的修改方案,制定修改计 划并进行BUG的修改,而且该软件开发人员制订的开发方案需要让相关人员能准确的掌握 BUG修改的进度,由于他的方案制约了后续的每一步工作；版本经理：根据修改结果发布一个测试版本,并知道版本中已包含了此次修改；测试人员：在拿到该版本后需要对这个 BUG导致的代码修改设计针对性的测试用例, 这个测试用例可能是自动测试用例,也可能是人工测试用例,总之测试人员需要在测试治理系

35、统来记录这个 BUG修改的验证过程；版本经理又出现了 ！： 一切就绪后,向客户发布版本时还需要提供release notes以指明该版本中的这个改动假设该BUG对用户可见；技术支持：收到版本经理发布的版本、操作手册以及相关的FAQ,做好给客户提供支持的准备；QA:仔细分析代码走查发现的所有BUG原因,如果是典型问题,还需要将该问题写入开发经验库,并通过知识共享的形式分享给所有团队成员；工程经理冏!： 一切却还没有结束！工程经理 的责任还需要从组织级的角度把控工程过 程和研发全进程.一个开发人员的代码如果被统计出问题较多,应该对该开发人员开发的代码采取补救和预防举措,要么增强测试,要么给他一些培

36、训,要么他根本不适合这个职位应 该走人；对于这个开发人员的上司,他应该如何评价这个犯错的下属,由于几个BUG就认为他的工作不称职显然是不正确的,还有他如何衡量这个开发人员的工作量,是否是该员工工作量太多导致了该员工的代码质量不高？他还想知道该员工在引入这个BUG时当时的工作任务是否过于紧迫？当然,他也可能想分析一下这个典型的BUG引入会导致多少额外的工作量产生？这,也太麻烦了吧！一切就只是由于一个开发人员的某行代码的BUG引发的血案?!拜托!这就是研发工作的特点！好吗?!理由很简单：没有一个集中治理、统一、高度整合的治理平台！【解决方案推荐】工欲善其身,必先利其器. 软件企业也是如此,要做到高

37、效的软件开发和过程治理,必 须选择运用灵活高效、统一整合的开发治理工具.TechExcel DevSuite 是一款高度集成、灵活可扩展的研发治理平台,实现了在同一平 台下从产品的概念形成、需求分析、工程规划、任务跟踪到开发测试等全生命周期的治理. 有效且协同地限制需求、资源、工期和质量,帮助研发团队快速改良软件开发过程,提升产 品质量和工作效率.一个平台即解决所有工具问题 ！DevSuite平台不但包含了工程人员、架构师、开发人员和测试人员等所有人员对应的 支持功能,增强了软件开发团队中的沟通与协作.举个例子,工程经理在定制工程方案时可以直接使用需求内容, 在做方案的同时又可以给研发人员分配

38、任务,研发人员在接到任务时可以直接查看相关联的客户需求,而测试人员在遇到缺陷时可以自动提交Bug,并且能实时查看Bug的修复进度.统一的平台既节省了所有员工的工作量,也保证了信息的一致性, 同时也使得工程研发的所有历史都可追踪到.也就是说,研发过程的每一个阶段轻而易举的实现业务关联,如用户需求与产品功能、 定制工程可关联；产品功能与工程规划、开发任务、测试用例、测试任务可关联；测试任务与BUG可关联；开发任务与源代码可关联；知识条目与需求、功能、任务均可关联等等！当然必须地要提一下,DevSuite平台还适用于跨地域、跨时区协同开发,支持分布式研发团队,实现高效率的沟通与协作.产品研发过程常见

39、问题 2：难以量化的需求开发与治理在软件工程的开发过程中,需求治理贯穿了软件工程的整个生命周期,在软件工程治理中需求工程是软件开发的第一步,是关键的一步,也是最难把握的一步.需求治理做得好坏 直接影响到软件的质量,甚至软件工程的成败.从软件的工程立项、研发、维护,用户的经 验在增加,对使用软件的感受有变化, 以及整个行业的新动态, 都为软件带来不断完善功能、 优化性能、提升用户友好性的要求.在工程治理过程中,工程经理经常面对用户的需求变更,如果不能有效处理这些需求变更,工程方案会一再调整,软件交付日期一再拖延,工程研发人员的士气将越来越低落,将直接导致工程本钱增加、 质量下降及工程交付日期推后

40、.这就决定了工程组必须拥有需求管理策略和有效的落地.让我们一起往返忆一下实际研发过程中,通常会面临到的需求治理挑战：1.缺乏需求的集中治理根据需求工程的说法, 在进入开发环节之前, 开发团队和客户之间需要形成一份完整的 需求规格说明书,详细地说明目标软件的各种需求,这其中包括功能性需求、非功能性需求和其他各种约束.在典型的瀑布模型中,需求规格说明书是在需求分析阶段完成的.然而, 由于软件外部环境的变化,很少有哪个工程在需求分析阶段就能将所有可能的需求准确无误 地包含进来,并且在开发阶段不需要修改,一句话,需求的变更是不可预防的.需求的变更 也需要及时地反响到需求治理中.除此之外,在实际的敏捷

41、软件开发中,对开发而言,需求的来源不一定像瀑布模型那样 完善的需求规格说明书,而通常有以下几种：1客户初始的业务需求：很多客户可能只会告诉我们,它想做一个系统或者工具平台, 大致是什么样子,应该具备哪些功能,但这种需求往往比拟抽象,缺乏细致的分析.这种需求可能源自于一次交谈,或者一封Email ,形式上并不正式.2客户对工程快速原型的反响意见：对于需求,在实际工程开发中,客户关注的业务功能,工程经理关注的是抽象设计,而开发人员关注的却是具体实现.在工程初期,客户往往也不是很清楚他们要什么,或者理想中的产品到底最后会是什么样的,界面布局,操作流程等等.这一点,在新产品的开发中尤为明显.这时候,就

42、需要开发团队能够根据现有的理解快速地开发一个原型,作为开发团队和客户讨论和分析需求的共同根底, 原型能够帮助用户更好地开掘和定义需求. 客户对于原型的 论证作为反响意见也可以使开发团队更加直观和感性地熟悉客户的需求.3客户对每个迭代周期发布的版本的修改建议如果该企业采用的是敏捷开发, 每个迭代周期都要发布一个可用的版本给客户,该版本尽可能多地实现了当前迭代周期内的需求以及之前迭代周期内遗留下来的需求.客户要验证需求的实现是否符合他们的要求,并提出修改意见和建议.4客户在研发周期中的需求变更需求来源的特殊性决定了软件开发过程中需求治理的特殊性,尤其是对于一个同时承当数个小工程的开发团队而言, 不

43、同的工程需求是由不同的开发人员或QA分别进行治理和跟踪的,缺乏集中的治理,对于需求的跟踪也比拟原始.往往是手工整理需求邮件和需求列表,然后形成简单的需求文档,在需求查询和状态维护方面存在明显缺乏.2 .需求变更频繁软件开发的显著特点之一就是灵活性、机动性、对变化的快速响应水平.尤其是敏捷开发过程,需求变更更为频繁.敏捷开发的口号是拥抱需求变化,也就是说,开发团队对于客户提出的需求变更通常是抱以欢送的态度,尽管这些变更可能会给工程方案和工程进度带来麻烦,但这种观念上的转变更能表达开发团队和客户之间合作的诚意.客户在迭代周期中的变更大致可以分为五种类型：添加新需求、删除本次迭代周期内的需求、删除之

44、前迭代周期内的需求、更改本次迭代周期内的需求、更改之前迭代周期内的需求.这就是说,开发团队需要实时高效地治理这些变更,并且将需求变更涉及到的迭代周期内工程方案和人员安排变更的影响最小化.3 .缺乏有针对性的需求治理流程传统的需求治理过程,尤其是其中的变更限制过程是针对那些组织机构清楚,只能定义明确的传统软件工程, 其流程相比照拟严谨和死板.同时,为了弥补需求变更对工程进程带来的影响,开发人员常常需要快速的进行功能修改和增加,而没有遵循统一的流程限制,从而常常使得软件开发的有序性被破坏,人为地增加了工作量.这就需要有更为高效和精简的需求治理过程以及相应的工具支持.4 .需求、测试用例、Bug治理

45、脱节软件开发中,需求和测试用例是紧密联系的, 通常来说,一条需求只有通过了所有针对 该需求的测试之后才能说这条需求的实现真正实现了.而测试的结果是产生Bug报告,如果针对某条需求的一个测试用例没有通过测试,换句话说,也就是产生了一个 Bug ,这就说明该需求根本没有完成.同时,需求的变更直接影响到与该需求相关的测试用例的更新,继而影响到现有Bug的状态的更新.然而现实情况却是,大多数敏捷开发团队都没有实现需 求、测试用例和 Bug的一体化治理.我们希望在需求、测试用例和Bug之间建立一种动态的联系,能够实时地更新三者的状态,并且实现三者之间状态的动态联动,从而减少开发团队在治理和维护需求、测试

46、用例和Bug时的工作量.5 .缺乏量化的工程治理反响企业在工程治理中,需求的频繁变更对工程治理者评估需求、制定迭代周期内的工程计划都是个巨大的挑战. 治理者在需求评估经验和水平上的缺乏,以及治理者对团队成员开发水平熟悉缺乏容易造成需求评估出现大的误差,虽然这种误差是不可预防的、但是我们希望可以通过历史评估数据的反响来帮助工程治理者积累经验,逐步修正和调整自己的判断和评价体系,从而尽可能减小由于评估误差引起的工程风险.而没有工具的支持,历史的准确数据那么很难获取.总结以上问题,显而易见,需求治理是软件工程中一项十分重要的工作,据调查显示在众多失败的软件工程中,由于需求原因导致的约占到45%,因此

47、有效的需求治理是企业 软件开发工程顺利达成目标的重要支撑条件.如何理解工程开发的目的和用途,梳理用户需求,监控需求变化,进行需求确认,对需求风险进行防范, 并利用工具进行有效的实施需求治理 工具,方能推进软件工程良性开展,到达用户与软件开发企业的双赢.有效的需求治理方法与工具方法一：量化需求治理如前所述,企业研发工程通常规模巨大,涉及部门众多,需求功能描述文件中包含众多内容,假设仅仅只用整篇的文档来指导开发和测试工作,很容易引起任务分配的混乱；当发生需求变更时,也很难追溯历史版本.TechExcel公司推出的DevSuite产品研发治理软件,从实践中提炼出一个行之有效的 解决方法 用标准点Sp

48、ecification,以下简称Spec量化需求,正规表达每一个功能单元. 只需翻开?需求功能描述书?的WORD文档,就可以利用插件,将其中的功能单元逐条地复制出来,在需求治理系统DevSpec中直接生成Spec.相对于需求,Spec是更面向技术人员的语言.客户业务需求可以在平台中进行集中治理,并以需求结构化和条目化的形式治理需求,为需求的评估、追踪与变更治理提供了根底.同时,通过系统强大的页面自定义水平,我们可以治理需求的来源、难度、实现时间、实现本钱等,这些信息为需求优先级的评估,提供 了量化的指标,帮助工程经理准确的排布需求优先级,让团队优先实现最重要、最紧急、客 户价值最高的需求.此外

49、,需求说明书、分析设计文档、评审记录等,均可以以附件形式保存,且能对文档 的版本进行有效的治理.方法二：有序治理需求变更在实际工程中,实现需求变更的本钱随着开发进度呈指数级增长.需求变更的流程化管 理能保证正常的开发进度,将变更及时反响到开发和测试等部门.以下描述的是一个典型过程 如图1.一项变更请求在需求治理系统中被提交后,与之 关联的各个部门,如市场、工程治理、产品研发、QA、测试等,都会有相关人员接到系统通知而介入.他们将组成评估团队,根据实施难度、周期、费用、对其他机制的影响等指标, 对该变更进行全面考察和评估.鞭英希求受星请直对需求差更强行翼查'一jr ; ° ,i

50、b,.!".四士需求变更审批替部门0S埋密王电斤到论春修2* * ,对需求交更撇强整拗准变更请求 一托葩萱更聪求工程规划执行A使Effnl布氏开鼻斜一Et需求变更的有序管珥DevSpec提供了专门的变更治理视图,在这里,我们可以治理各个工程中的需求变更 任务,不管是需求增加、 减少或是改变,我们都会为之建立一条变更记录,在这条变更记录中,记录了变更的来源、原因、具体描述和变更本钱、收益估算,这些信息可以成为变更评 估的标准与依据.每个变更任务均可以和在变更中受影响的需求相关联,包括增加的、减少的和变更的需求.通过需求变更列表,我们可以清楚的看到工程中当前有多少变更任务,影响了哪些需求

51、,也能够观察到整个工程周期中总计发生了多少变更,总计影响了多少需求条目.方法三：标准的需求治理流程需求治理的整个过程都可以用标准、有效的工作流限制起来,如需求变更流程的设定, 通常包括请求、复查、讨论、调整、批准和拒绝等状态,只有具备权限的工程成员才能改变 状态.根据预设的流程,各方审批全部通过后,该变更才能被接受.DevSuite提供了灵活的工作流程定制和治理水平,图形化工作流引擎将工作流图形转变为工作流脚本,因此工程治理员可以在图形化界面中, 轻松快速的定制工程组工程治理流 程.如上图中红色框内为需求的 工作流程,用户可以根据公司的实际业务流程,定制符合需要的需求流程图,系统可以同时定义多

52、条工程工作流程,以适应不同规模、不同类型的工程.方法四：需求有效驱动开发与测试在理想的研发治理平台中,需求治理与所有规划、开发、测试治理过程相集成.因此, 需求的正规表达Spec ,以及围绕Spec正在或将要进行的开发任务和测试任务,都能被纳 入综合考虑的范畴,便于评估团队估算该变更造成的奉一发而动全身的潜在影响.有时,还要结合商业需求进行考量,为了赶上产品的最正确发布时机,有些变更将被拒绝.变更请求被批准后, 与之相关联的开发、 测试任务都会在系统中被一一标记出来,以提醒程序和测试部门的相关负责人,引发这些任务的需求已经变更,请他们做出相应的调整处理.在系统中跟踪这些任务的进展,可以实时掌握

53、该变更的落实情况.变更完成后,也可以核算它对开发周期和费用的实际影响,与评估时的预测相比照, 找出差异的原因,为将来更准确地评估提供参考.-“ivt 1- -"ITg ih>*t'就KE3：离二 4 #HltFXit p iFWi WTinirI - > L* II 1|fff r|l± ' : 当*T az 11. Q,-J =*7 M «1 a» r* HI 4Lk- - jjfcl JI Q > "»T -> F fkJg 隔 I -i-3 P*-'"»-sse

54、miDevSuite提供了变更标识功能,通过变更标识子任务,我们可以选择受影响的开发、测试任务,建立变更标识子任务,该子任务将以旗帜形式反映到开发、测试任务中.变更标识子任务不但能够标识变更, 还能够帮助团队进行变更反响,通过文字记录和状态改变,任务负责人员可以将需求变更对于任务的影响及时回馈给需求治理人员.另外,对于需求实际改变的内容,需求负责人员可以创立变更推送子任务, 通过邮件系统,可以将变更信息发送 给该需求的干系人.方法五：需求指导工程规划与执行纵使工程最初都有比拟全面的方案,延期仍然会时常发生, 即便是在治理机制比拟成熟的大型研发企业中, 跳票也不可预防.通常情况下,导致跳票主要有

55、以下几点原因：功能设 计规划过多,很多又无法删除,如不增加开发时间,产品几乎不能完成；缺乏有经验的治理或开发人员,不能准确估计工作量 ；任务执行缺乏标准,开发人员随意更改功能设计,影响 整体进度；过高的人员流动率,导致知识的流失,任务不能及时跟进.针对以上问题,只要从量化需求入手,有序治理需求变更,用正规表达、可量化的Spec来指导工程规划、编程和测试,就能把风险降到最低.基于结构化的Spec集合,可以将工程分解为多个子工程,将Spec直接分配到各自对应的子工程中,以此来规划和估算子工程的工作量.工程治理人员为每个子工程分配资源,安排优先顺序,确定工程里程碑.在工程执行时,可以为每一个Spec

56、产生出一系列开发任务.自定义的工作流机制保证 每一个任务从提交到最终解决的生命周期都严格符合业务流程,保证任何时刻都有唯一的负责人、状态和截止日期.这样,不仅能标准产品研发过程,还能降低人员流动带来的风险.任务的流转及相关知识文档,如源代码、设计资源等,都得到系统完整的记录,还能与任务关联,便于追溯.一旦有人离开工程,接替的人员能够查看任务和文档信息,迅速弥补人员 空缺.DevSuite需求治理视图提供产品版本树治理,产品经理可以创立新产品和版本,每个 需求和功能点可以在多个产品和版本实现.通常一个产品的各个功能可能会分布在不同的项各个功能点的负目中实现,工程经理如何在产品发布的时候知道每次发布实现了那些功能, 责人是谁,通过 DevSpec视图提供的产品版本树功能,工程经理可以轻松的过滤出每个发 布版本实现了那些客户需求.支持产品的版本规划,当收集到的需求经过评审等规定流程决策后, 将需求与规划好的 产品版本关联起来,通过产品版本视图可以直接追踪到需求与产品版本的关系,未决定开发的需求可以不设