软件开发工程管理2008(四)

软件开发工程管理第四讲上讲提要需求获取需求分析本讲主要内容需求规约说明需求验证需求管理项目计划介绍什么是软件需求规约？SoftwareRequirementSpecification，简称SRS是对用户需求和系统需求的详细描述一般要用文档描述需求规约说明（1/8）需求规约说明（2/8）需求规约说明书有什么作用？使用对象需求文档作用客户了解项目提交物,检查软件需求是否满足需要项目管理人员根据需求文档制定开发计划,初步预测资源软件开发人员理解要开发的产品及具体的开发内容软件测试人员验证软件系统是否满足了预期要求软件维护人员帮助理解软件系统内在逻辑关系软件发布人员依据需求文档编写用户手册软件培训人员依据需求文档编写培训材料需求规约说明书至少要有哪些内容？产品能处理何种输入？产品能提供何种输出？如何能：将输入=〉输出？有没有数据库？有多少？什么样？是不是网络程序？c/s还是b/s？有没有中间层？使用什么协议？用户界面什么样？菜单怎么设计？能提供哪些外部接口？……需求规约说明（3/8）需求规约说明书应该有的内容分类？待处理的数据控制功能性能约束接口可靠性需求规约说明（4/8）运行软件的硬件（如：处理机、外设）及不直接由软件控制的设备（如：机器、显示器）已存在的、且必须与新软件连接的软件（如：数据库、可复用软件构件、OS）通过键盘或其他I/O设备使用软件的人在该软件之前或之后的过程，它们代表了一个顺序操作系列凡是计划要实现的，均写入需求文档凡是文档中没有的，统统不用实现！需求规约说明书的格式规范：要排版！消灭错别字！！避免模糊的语言不要口语化图的命名：图2-1（figure2-1）表的命名：表2-1（table2-1）英文缩写要在第一次出现的地方写全名……需求规约说明（5/8）需求规约说明（6/8）例：传送带分类系统 传送带分类系统将沿传送带移动的盒子进行分类。每一个盒子由一个包含零件号的条形码来标识，并在传送带末端分送到6个箱子中的一个。这些盒子要通过一个由条形码阅读器及一台PC所组成的分类站。分类站的PC连接到一个分流器上，它把盒子分送到不同箱子中。盒子以随机的顺序通过且其间的距离相同。传送带以每分钟5英尺的速度移动。需求规约说明（7/8）例：传送带分类系统的软件功能 传送带分类系统软件以和传送带速度一致的时间间隔接受来自条形码阅读器的信息。条形码数据被解码成盒子的标识格式。软件将在最多可容纳1000个条目的零件号数据库中进行检索，以确定当前在阅读器位置的盒子应该放到哪个箱子中。该箱子的信息被传送到分流器，以把盒子放进合适的箱子中。每一个盒子所放进的箱子的记录均被保存起来以备后用。传送带分类系统软件同时也接受来自脉冲流速计的输入，用于使控制信号与分流器同步。根据分类站和分流器之间产生的脉冲数，软件将产生一个控制信号给分流器，以适当地定位盒子。需求规约说明（8/8）传送带分类系统功能读取条形码输入读取脉冲流速计解码零件编码数据检索数据库确定合适的箱子产生分流器的控制信号维护盒子目的地的记录传送带分类系统性能对于每个盒子的处理必须在下一个盒

子到达条形码阅读器前完成传送带分类系统约束该软件受硬件、可用内存、及

整个传送带的配置的约束Next广义的需求管理狭义的需求管理需求管理

——概述（1/4）为什么要做需求管理？实验表明：需求缺陷最多，而且随着各阶段的逐渐进行，修复需求缺陷所付出的代价最大需求管理的目的是什么？使软件需求受控，并建立供软件工程和管理使用的需求基线使软件计划、产品和活动与软件需求保持一致需求管理

——概述（2/4）管理中应坚持哪些原则？需求一定要分类管理需求必须分优先级需求必须文档化需求一旦变化，就必须对需求变更的影响进行评估需求管理必须与需求工程的其他活动紧密整合需求管理

——概述（3/4）需求管理活动活动的任务变更控制建议需求变更并分析其影响，做出是否变更的决策版本控制确定单个需求和SRS的版本需求跟踪定义对于其他需求及系统元素的联系链需求状态定义并跟踪需求的状态需求管理

——概述（4/4）在需求管理中，项目经理该干些什么？借助具体工具和手段，对需求的开发、实现和变更进行控制和管理需求开发的管理

——需求处理阶段在需求处理阶段，项目经理该干些什么？明确需求的来源指导需求形式化需求文档化需求数据库化指导建立需求跟踪矩阵需求开发的管理

——需求验证阶段（1）步骤：编写测试计划和测试用例编写用户使用手册编写系统验收标准通过需求评审需求开发的管理

——需求验证阶段（2）需求评审对象：软件需求规格说明书需求评审内容：确定不完整和遗漏的给定需求评审给定需求，并确定它们是否可行，适于软件实现，说明是否清楚、适当、一致，是否可测试确认可能有问题的需求，评审并修改相关小组协商由给定需求得出的约定需求开发的管理

——需求验证阶段（3）良好的需求规格说明书：准确完整无歧义一致需求分级可检验可修改可跟踪可理解需求开发的管理

——需求验证阶段（4）验证中应进行的检查：有效性检查一致性检查完备性检查现实性检查可检验性检查可跟踪性检查可调节性检查可读性检查需求开发的管理

——需求验证阶段（5）在需求验证阶段，项目经理该干些什么？参与评审关注评审内容和结构根据评审意见，与评审委员会一起决定项目的下一阶段需求实现的管理

——需求属性需求的创建时间需求的版本需求的创建者需求的批准者需求状态需求的起因或根据需求的优先级需求的稳定性需求和其他产品的关系需求实现的管理

——需求状态已建议已批准已拒绝已设计已实现已验证已交付已删除需求实现的管理

——需求跟踪正向跟踪以用户需求为切入点，检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点逆向跟踪检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处需求跟踪时需要考虑：需求本身的提出者等需求和其他需求的关系需求和设计的关系Next制定软件项目开发计划软件项目计划计划从估算开始建立计划整体计划贯穿项目始终详细计划完成规格说明之后必须产生的估算什么？估算成本内部成本外部成本估算开发周期影响估算的因素项目复杂性项目规模结构不确定性影响估算结果的最大因素：？不同开发人员之间的差距：产品规模上： 6：1产品执行时间上： 8：1开发时间上： 9：1编码时间上： 18：1调试时间上： 28：1平均： 5：1软件项目计划活动

——估算需要的资源有哪些项目资源？开发环境可复用构件人员软件项目计划活动

——软件项目估算（1）怎么进行估算？将估算拖延到项目的后期基于已经完成的类似项目进行估算使用相对简单的分解技术以生成项目成本及工作量估算使用一个或多个经验模型进行软件成本及工作量的估算软件项目计划活动

——软件项目估算（2）估算内容：产品规模度量产品成本估算产品规模度量

——代码行（1）代码行数代码行（LOC）LinesOfCode已交付源代码指令（KDSI）ThousandDeliveredSourceInstructions产品规模度量

——代码行（2）项目LOC工作量成本文档页数错误缺陷人员A1210024168365134293B27200624401224321865C20200433141050256646……………………产品规模度量

——代码行（3）可用的度量每千行代码（KLOC）的错误数每千行代码（KLOC）的缺陷数每个代码行（LOC）的花费每千行代码（KLOC）的文档页数每人月的错误数每人月的代码行（LOC）每页文档的花费产品规模度量

——代码行（4）支持者：LOC是所有软件开发项目的“生成品”易于计算很多软件估算模型使用LOC作为输入反对者：LOC测量依赖于语言对设计得很好但较小的程序会产生不利的评判估算时需要一些难以得到的信息产品规模度量

——功能点（1）功能点（functionpoint）：用户输入数用户输出数用户查询数文件数外部接口数组件复杂级别简单一般复杂输入项346输出项457查询346主文件71015接口5710产品规模度量

——功能点（2）FP=a*Inp+b*Out+c*Inq+d*Maf+e*Inf

其中a,b,c,d,e为常数为产品的各个组件指定对应的复杂度级别查表找出对应级别的功能点系数对分配给每个组件的功能点求和上面得到的实际上是UFP（unadjusted）产品规模度量

——功能点（3）计算UFP计算技术复杂因子TCF（TechnicalComplexityFactor）查表得到各部分影响度累加得到总影响度DI（DegreeOfInfluence）TCF=0.65+0.01*DI计算功能点FPFP=UFP*TCF1系统需要可靠的备份和恢复吗？2需要数据通信吗？3有分布处理功能吗？4性能很关键吗？5系统是否在一个现存的、重复的操作环境中运行？6系统需要联机数据登录？7联机数据登录是否需要在多屏幕或多操作之间切换以完成输入？8需要联机更新主文件吗？9输入、输出、文件或查询很复杂吗？10内部处理复杂吗？11代码需要被设计成可复用的吗？12设计中需要包括转换及安装吗？13系统的设计支持不同组织的多次安装吗？14应用的设计方便用户修改和使用吗？产品规模度量

——功能点（4）可用的度量每个功能点（FP）的错误数每个功能点（FP）的缺陷数每个功能点（FP）的花费每个功能点（FP）的文档