软件开发与需求管理的定义cczd.pptx

《软件开发与需求管理的定义cczd.pptx》由会员分享，可在线阅读，更多相关《软件开发与需求管理的定义cczd.pptx（54页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件需求与需求管理软件需求与需求管理2002-4-4内内 容容软件发展的三个时期软件生存期过程软件开发软件需求需求工程需求变更及其控制CMM2级需求管理关键过程域 一、软件发展的三个时期表一时期年代阶段涉及注重主要使用语言标准模型初期50-60程序设计点编程技巧ALGOLFORTRANCOBOLBASIC中期70-80软件开发线结构化模块化PASCALGB8566软件开发规范瀑布原型现代90-软件过程面过程能力C,C+JAVAVB、VCISO/IEC12207软件生存期过程ISO9000螺旋CMM二、软件生存期过程ISO/IEC12207信息技术软件生存期过程基本过程支持过程组织过程软件生存期

2、过程图1-1 供应过程开发过程运行过程基本过程获取过程维护过程图1-2质量保证过程验证过程确认过程支持过程配置管理过程联合评审过程审核过程文档编制过程问题解决过程图1-3基础设施过程改进过程培训过程组织过程管理过程图1-4三、软件开发1.计算机系统人员硬件软件数据传输机构执行机构（剧作家、导演）（舞台剧本演员道具）图2计算机系统2.软件开发过程：活动任务系统需求分析系统结构设计软件需求分析建立软件需求评价软件需求联合评审软件结构设计软件详细设计软件编码和测试软件集成软件鉴定测试系统集成系统鉴定测试软件安装软件验收支持软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题3当前软件开

3、发项目的特点 规模大：LOC1万几十万HP激光打印驱动软件4万110万 复杂质量要求高满足客户需求和期望客户满意度统计开发和维护成本缺陷后期发现返工成本延误交付期四、软件需求1.系统需求分析软件系统需求(1)系统需求分配软件工程组硬件系统需求(2)其它成分系统需求(n)软件需求客户最终用户系统工程组图3系统需求分配2.软件需求定义（IEEE-STD-610）用户为解决某个问题、或为实现某一目标，要求软件必须满足的条件或能力。软件需求的三个层次业务需求用户需求功能需求和非功能需求非功能需求过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性，机密性，安全

4、性，使用要求业务需求业务说明使用实例用户需求功能需求约束条件非功能需求软件需求规格说明图4软件需求的层次质量功能展开（QFDQualityFunctionDevelopment）客户需求常规需求：客户明确提出期望需求：并未明确提出的潜在需求，不言而喻的需求 兴奋需求：客户未想到，若实现客户 感到意外分配需求的实例系统需求ACCS应能使汽车保持在预期车速的2KMH范围内行驶分配给硬件的需求硬件应能使车速在规定的精确度1.5KMH范围内分配给软件的需求软件应能在车速超出预期车速0.5KMH时给硬件加/减速命令软件需求软件应能：读入当前车速值计算当前车速与预期车速之差若差值0.5KMH给出加/减速命

5、令图5汽车限速系统ACCS的需求分配3CMM2级关键过程域需求管理（KPARM）中对软件需求的解释：分配需求（allocatedrequirements）：分配给软件的系统需求（1）分配需求包括：影响和确定软件项目活动的非技术性需求（在合同条款中规定），如：要交付的产品交付日期里程碑软件的技术需求，如：最终用户、操作人员、支持或集成的功能性能需求设计约束条件编程语言界面需求用于确认软件产品满足分配需求的验收准则（2）分配需求应当是：以软件来实现是可行的，而且是适合的；已得到清晰而正确的阐述；相互之间是一致的；可以测试的。同时，分配需求应当：被管理和控制（如必要可纳入软件配置管理）是制定软件开发

6、计划SDP的基础是制定软件需求的基础（3）与分配需求相关的组：软件评估组系统工程组系统测试组软件质量保证组SQA合同管理组文档支持组五、需求工程1需求工程需求开发需求管理获取需求分析需求定义需求验证需求需求变更控制需求跟踪需求状态跟踪需求文档版本控制需求开发需求管理需求工程图6需求工程的构成用户/系统市场管理者初始需求变更的需求获取,分析,定义,验证需求控制需求变更需求规格说明项目环境需求开发需求管理图7需求开发与需求管理2需求开发（1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求必要性可行性（3）定义需求编写软件需求规

7、格说明（SRS）作用要求：完整、正确、可行、无歧意、可验证形式：图、表、文字（4）验证需求联合评审六、需求变更1、难于完全避免初始需求变更的需求对问题的初始理解对问题的新理解时间图8需求的变更2、需求变更原因分析1)单纯的用户因素2)市场形势变化3)系统因素4)工作环境和要求变化5)需求开发的缺陷 需求分析、定义和评审不充分与用户沟通不畅3、需求变更对软件开发的影响使变更前开发工作和成果失效返工成为被迫采取的对策工作量及资源投入的增加使开发成本提高项目完成时间后延4、需求变更失控可能导致的后果未受控的需求变更引起需求和实现不一致需求文档V1系统实现V1系统实现V2需求变更受控的需求 变更使需求

8、和实现一致图7未受控及受控的需求变更需求文档V1需求文档V2系统实现V1系统实现V2需求变更5.降低需求变更风险的策略与用户充分沟通与用户共同明确确定的需求的意义项目开发工作项目开发组织用户*产品后续开发工作的基础*产品维护工作的重要参考*对用户的承诺*关系到项目开发工作的投入、交付期和产品质量*关系到能否如期获得所需的产品*作为合同的附件，关系到双方的权益*是产品验收的依据向用户说明需求不确切或频繁变更对开发工作的冲击使用户理解过多变更最终对用户不利与用户共同确定需求，作为合同附件，签字生效合同中含有对需求变更的条款采用原型方法开发，或螺旋模型开发项目计划中适当留有余地（时间进度、人力投入、

9、费用等）严格实施变更控制七、需求变更控制要求 1变更控制的策略（1）所有需求变更必须遵循需求变更控制规程实施变更。（2）需求变更提出后是否被接受，应由专门的组织变更控制委员会（CCBChangeControlBoard）审查决定。（3）不得以任何理由删除和修改需求变更的原始文件。（4）应将已接受的需求变更通知到所有相关人员。（5）已接受的需求变更应能追溯到批准的变更请求。（6）对项目的需求赋予状态属性，以利于需求变更的控制。2需求变更影响的控制按CMM2级RMKPA的要求，由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作：识别评价风险分析编制文档制定计划传达给受影响的小组和人员

10、跟踪直至结束3变更控制的步骤（1）提出变更请求（2）审理变更请求，进行变更影响评估。评估内容包括：变更所需人力投入变更对原计划安排的影响估计变更引起的成本增加（3）批准变更请求（4）取得用户的认可（5）修订项目计划（6）实施变更（7）验证变更批准提出变更请求变更影响评估评审评估报告审批用户认可修订项目计划实施变更验证变更结束拒绝修正图10需求变更控制流程八、需求变更控制实施1需求变更请求（1）内容申请号变更说明变更类别影响分析变更请求状态变更请求日期（2）需求变更请求实例（表三）项目名：XYZ变更申请号11日期：23Feb1998变更说明IS-41分析器对CDMA的支持影响分析对CDMA的配置

11、模块和分析器无影响TDMA码可复用受影响的模块是：CGAAPP模块，需对IS-41单独进行规范性分析CDMAPP01模块（a）TRIS41R01按TRCDMARS41R01复制（b）使用纯虚拟对TRCDMAR01建立（c）ActualCallModeManager并重新定义SILVER06GUIAPP+模块：在资源表中加入IS-41工作量5人日计划时间无需重大变动状态将并入新的CDMA软件包2需求变更累积影响的跟踪（1）需求变更累积影响跟踪的意义和作法累积影响变更累积表（2）需求变更累积表实例（表四）表四需求变更累积表需求变更号需求变更时间变更说明工作量状态118/2规定使用情况统计322/2

12、结束2演示期用户阻塞2未结束3演示期用户强迫退出2未结束418/2用户信息归档527/2结束5演示期关闭窗口1未结束6演示期保存扩展数并在需要时恢复10未结束7演示期能够在特定节点启动2未结束8演示期删除时列出所有节点1未结束918/2注释（建立删除批准修改等）10未结束1023/2PENETCONFIG支持netconfig格式10未结束1123/2IS-41分析器IS-41分析器对CDMA的支持51/3结束总计513需求控制流（1）需求状态及其演变软件需求在后继阶段开发工作中将逐步展开，加以实现。在不同的开发阶段软件需求以不同的形式进行着状态的演变。例如：需求阶段从获取的需求到定义的需求建

13、议阶段制定出项目计划以后演化为承诺的需求设计阶段设计工作完成并在验收后成为设计的需求编码阶段完成编码和单元测试后成为实现的需求测试阶段完成确认测试后成为完成的需求开发阶段需求状态需求建议设计编码测试获取定义承诺设计实现完成图11生存期各阶段需求状态的演变九、可追溯性管理1需求可追溯性与需求变更控制随着开发工作的进展需求将逐步扩展和演化各个开发阶段的工作产品之间存在的继承关系可追溯性矩阵2可追溯性管理的目标使每一项需求均能追溯到前后继承关系的脉络清晰可见3两类不同的追溯（1）向前追溯（2）向后追溯4可追溯性矩阵（1）矩阵的作用可防止遗漏为评审提供方便便于进行变更影响追踪、分析和检查（2）矩阵的建

14、立与维护（3）矩阵的应用完整性检验考察有无需求遗漏的情况有无冗余代码检查所有性能需求是否已被测试用例测试对集成测试计划和系统测试计划进行交互检查需求变更控制需求变更后相关的工作产品受影响的部分应随之变更更新需求规格说明，同时要更新追溯矩阵每增加一项需求，应在追溯矩阵中得到体现表五追溯矩阵实例12345678需求号需求描述概要设计文档索引号对应的设计(功能,结构,数据库)实现(程序,类,继承类)单元测试用例集成/系统测试用例验收测试用例1.1.2利用收集的数据实现亮点的实时集成5.3.2数据采集与亮度控制器接口PB405数据采集#12#46#11CICS203亮点控制器启动#1#47#11十、C

15、MM2级RMKPA需求管理（RMRequirementsManagement）是CMM2级的第1个关键过程域。需求管理的目的是要在客户和将处理客户需求的软件项目之间形成共同的理解。这种共同理解应该体现在：客户需求的文档和对客户需求的控制中使项目的计划、产品和活动都应与需求一致2级RMSPPSPTOSSMSQASCM目标G1G2约定能力活动测量验证C1Ab1Ab2Ab3Ab4Ac1Ac2Ac3M1V1V2V3图13RMKPA结构1目标与活动目标目标1：分配给软件的系统需求应是受控的，以利建立软件工程和管理的基线活动1：在分配需求被纳入软件项目之前，软件工程组应对其进行评审目标目标2：软件计划、产

16、品和活动要与分配给软件的系统需求保持一致活动2：软件工程组将分配需求作为软件计划、工作产品和活动的基础活动3：评审对分配需求的变更，并将变更纳入软件项目2约定与能力约定约定1：项目要遵循一个书面的组织方针来管理分配给软件的系统需求能力1：为每个项目规定分析系统需求并将其分配给硬件、软件和其它系统成分的职责能力2：编制分配需求文档能力3：为管理分配需求提供足够的资源和资金能力4：软件工程组人员和与软件相关的其它组 人员要接受培训，以利于完成他们的需 求管理活动3测量与验证测量测量1：进行测量，并将测量结果用于确定对分配需求所作管理活动的状态验证1：高级管理者定期评审管理需求分配的活动验证2：项目

17、经理定期地也要在特定事件出现时审管理需求分配的活动验证3：软件质量保证组评审和（或）审核管理 需求分配的活动和工作产品，并报告结 果4入口任务验证出口（ETVXEntry,Task,VerificationandeXit(表六 RMRM的的 ETVXETVX）入口条件入口条件任务任务出口条件出口条件1方针（C1）2职责（Ab1）3文档化需求 （Ab2）4评审和(或)审核 （Ab3）5 5人员培训 （Ab4）1.1.需求纳入之前应进行评审 （Ac1）2.2.需求作为计划、工作产品和活动的基础 （Ac2）3.3.变更评审和纳入（Ac3）1需求基线化（G1）2一致的需求、计划、产 品和活动（G2）3基线化需求成为受控的 工作产品4对需求基线作文档化的、经评审和批准的变更验证验证1高级管理者评审（V1）2项目经理评审（V2）3SQA评审和(或)审核（V3）4RM活动状态的测量（M1）