《软件需求》学习第四、五章第四章改进需求过程软件开发过程的改进两个主要目标:解决在以前项目或目前项目中遇到的问题。防止和避免你可能在将来的项目中要遇到的问题。变更需求开发和管理方法将对项目其他过程产生影响,反之亦然。4.1需求与项目其他过程的联系4.2软件需求对项目其他风险承担者的影响4.3软件过程改进的基础四条改进软件的原则(Wiegers1996a):改进过程应该是革命性的、彻底的、连续的、反复的;人们和组织机构都只有在他们获得激励时才愿意变更;变更改进的几种驱动力:•项目没有时限,因为需求说明变得超想象的复杂。•开发人员不得不大量超时工作,因为误解或二义性的需求直到开发后期才发现。•系统测试白费了,因为测试者并未明白产品要做什么。•功能都实现了,但由于产品的低性能、使用不方便或其它因素用户不满意。•维护费用相当高,因为客户的许多增强要求未在需求获取阶段提出。•开发组织落得交付一项客户并不想要的产品的名声,声誉受损过程变更是面向目标的;将改进活动看作一些小项目.4.4过程改进周期4.4.1评估当前采用的方法评价方法:设计自我评价问卷让外部顾问客观地评估4.4.2制定改进活动计划制定出整个软件过程改进初始工作的战略计划和在各个特定改进领域的战术行动计划,指明改进行动的目标、风险承担者和一些必须完成的活动条目。活动条目不超过10个,如多对其进行优先级的排列,并时时进行更新4.4.3建立、实验和实施新的过程为你建立的新过程或文档模板计划一个“实验”通过在实验中获取的经验来调整新技术,从而将它运用于整个目标群体时,改进活动会更有效果。引导实验的建议:–选择实验参与者(participant),他们将尝试新方法并提供反馈信息,这些参与者可以是生手也可以是老手,但他们不应该对过程改进持有强烈的反对意向。–确定用于评估实验的标准,使得到的结果易于解释。–通知那些需要知道实验是什么以及为什么要实施的工程风险承担者。–考虑在不同的项目中实验新过程的不同部分。用这个方式可使更多的人尝试新方法,因此能提高认知水平,增加反馈信息。–作为评估的一部分工作,询问实验参与者,如果他们不得不回头采用他们原有的工作方法,他们会觉得怎样。4.4.4评估结果–首先要考虑整个新过程在群体中执行的情况。是否能使每个人都明白新过程或模板的好处?参与者是否理解并成功地应用了新过程?是否在下次工作中需要有所变更?–关键是评估新实施的过程是否带来了期望的结果让他们知道你的改进想法和调整计划。要向他们说明改进后的新过程会带来什么好处。反对是因为对变更产生的影响产生恐惧。需要在变更之前说明变更产生的影响。此外,询问其他组织需要从开发队伍中获取什么以有助于他们的工作。要给予新方法以足够的运行时间,选定能说明每项过程变更成功与否的衡量标准。当从业者(practitioner)花费时间去吸收新方法时,生产率会降低。对从业者进行过程改进学习曲线的学习。过程改进学习曲线4.5需求过程的积累材料为了执行这些步骤,你应当将需求各个过程的材料收集起来,包括已完成的活动和可交付的产品。信息获取、分析、编写规格说明、验证以及管理。–需求开发过程的积累材料–需求管理过程的积累材料4.5.1需求开发过程积累的材料项目视图与范围模板(业务和用户需求)需求开发过程(包括以下所有)需求分配过程使用实例模板软件需求规格说明模板需求优先级确定过程SRS和使用实例审查清单4.5.2需求管理过程的积累材料变更控制过程–明确了一种方法来提出、协商、评估一个新的需求或在已有需求上的一项变更。变更控制委员会过程–由风险承担者组成,对需求的变更做出裁决需求变更影响分析检查清单和模板–估计提出的需求变更的成本费用和影响,是决定是否执行变更的重要步骤。需求状态跟踪过程需求跟踪能力矩阵模板第5章软件需求与风险管理风险:可能给项目的成功带来威胁或损失的情况。项目成本费用、进度安排、技术方面、产品质量及团队工作效率等带来较大的负面影响。风险管理:在风险给项目带来损失之前,就指明、评估并对风险加以控制。5.1软件风险管理基础5.1.1风险管理的要素风险评价风险评价(riskassessment)是一个检查工程项目并识别潜在风险区域的过程。风险评价的方法–列举通常的软件项目风险因素–检查一些特定风险对项目可能造成的潜在后果。确定风险优先级–风险分级(riskprioritization)有助你通过评价每项风险的潜在危害值,优先处理最严重的风险。–风险危害值(riskexposure)包括带来损失的可能性大小和潜在损失的规模。风险避免风险避免(riskavoidance)是处理风险的一种方法:尽量别作冒险的事。风险控制(riskcontrol)–制定风险管理计划是一项处理具有一旦发生,影响较大的风险的计划,包括降低风险的方法、应急计划、负责人和截止日期。风险解决方案:包括了降低、减少每项风险的执行计划风险监控风险监控(riskmonitoring)来跟踪风险解决过程的进展情况。监控可以很好了解降低风险工作的进展情况,可以定期地修订先前风险清单的内容和划分的优先级。5.1.2编写项目风险文档将风险编写成文档–在整个项目开发过程中有利于风险承担者了解风险情况和状态–可以定期地修订先前风险清单的内容和划分的优先级。你的目标是将最有威胁的风险和那些不急需处理的风险区别开来,并处理最具有威胁的风险。风险控制的策略:–一些策略是尽量降低风险发生的可能性;–另一些则是减少风险发生后带来的影响。–降低风险措施的前两条是通过更多的用户参与项目来减少风险发生的可能性。而采用原型法则可以利用用户关于界面的早期反馈来减少风险的潜在影响。5.1.3制定风险管理计划将与风险有关的内容制定为一个风险管理计划将其作为整个项目计划和项目投资的一部份,并在项目计划中为风险管理计划留出足够的时间和其它项目管理活动一样,你需要建立起周期性的监控措施。保持对十来个有最大危害的风险的高度重视,并追踪降低风险措施的有效性。当完成一项活动后,重新评估那项风险的可能性和影响,更新风险清单和其它相关的计划。5.2与需求有关的风险5.2.1需求获取1)产品视图与范围此最好在项目早期写一份项目视图与范围将业务需求涵盖在内,并将其作为新的需求及修改需求的指导。2)需求开发所需时间3)需求规格说明的完整性和正确性4)对革新产品的需求有时容易忽略市场对产品的反馈信息。5)明确非功能需求6)客户赞同产品需求7)未加说明的需求8)把已有的产品作为需求基线9)给出期望的解决办法5.2.2需求分析1)划分需求优先级2)带来技术困难的特性3)不熟悉的技术、方法、语言、工具或硬件平台5.2.3需求规格说明1)需求理解2)时间压力对TBD的影响3)具有二义性的术语4)需求说明中包括了设计5.2.4需求验证1)未经验证的需求2)审查的有效性5.2.5需求管理1)变更需求2)需求变更过程3)未实现的需求4)扩充项目范围谢谢!