《软件开发工程管理2008(四).》由会员分享，可在线阅读，更多相关《软件开发工程管理2008(四).（42页珍藏版）》请在金锄头文库上搜索。
1、软件开发工程管理,第四讲,上讲提要,需求获取 需求分析,本讲主要内容,需求规约说明 需求验证 需求管理 项目计划介绍,什么是软件需求规约？ Software Requirement Specification，简称SRS 是对用户需求和系统需求的详细描述 一般要用文档描述,需求规约说明（1/8）,需求规约说明（2/8）,需求规约说明书有什么作用？,需求规约说明书至少要有哪些内容？ 产品能处理何种输入？ 产品能提供何种输出？ 如何能：将输入 =输出？ 有没有数据库？有多少？什么样？ 是不是网络程序？c/s还是b/s？有没有中间层？使用什么协议？ 用户界面什么样？菜单怎么设计？ 能提供哪些外部接口
2、？ ,需求规约说明（3/8）,需求规约说明书应该有的内容分类？ 待处理的数据 控制 功能 性能 约束 接口 可靠性,需求规约说明（4/8）,运行软件的硬件（如：处理机、外设）及不直接由软件控制的设备（如：机器、显示器） 已存在的、且必须与新软件连接的软件（如：数据库、可复用软件构件、OS） 通过键盘或其他I/O设备使用软件的人 在该软件之前或之后的过程，它们代表了一个顺序操作系列,凡是计划要实现的，均写入需求文档 凡是文档中没有的，统统不用实现！,需求规约说明书的格式规范： 要排版！ 消灭错别字！ 避免模糊的语言 不要口语化 图的命名：图 2-1（figure 2-1） 表的命名：表 2-1（
3、table 2-1） 英文缩写要在第一次出现的地方写全名 ,需求规约说明（5/8）,需求规约说明（6/8）,例：传送带分类系统 传送带分类系统将沿传送带移动的盒子进行分类。每一个盒子由一个包含零件号的条形码来标识，并在传送带末端分送到6个箱子中的一个。这些盒子要通过一个由条形码阅读器及一台PC所组成的分类站。分类站的PC连接到一个分流器上，它把盒子分送到不同箱子中。盒子以随机的顺序通过且其间的距离相同。传送带以每分钟5英尺的速度移动。,需求规约说明（7/8）,例：传送带分类系统的软件功能 传送带分类系统软件以和传送带速度一致的时间间隔接受来自条形码阅读器的信息。条形码数据被解码成盒子的标识格式
4、。软件将在最多可容纳1000个条目的零件号数据库中进行检索，以确定当前在阅读器位置的盒子应该放到哪个箱子中。该箱子的信息被传送到分流器，以把盒子放进合适的箱子中。每一个盒子所放进的箱子的记录均被保存起来以备后用。传送带分类系统软件同时也接受来自脉冲流速计的输入，用于使控制信号与分流器同步。根据分类站和分流器之间产生的脉冲数，软件将产生一个控制信号给分流器，以适当地定位盒子。,需求规约说明（8/8）,传送带分类系统功能 读取条形码输入 读取脉冲流速计 解码零件编码数据 检索数据库 确定合适的箱子 产生分流器的控制信号 维护盒子目的地的记录,传送带分类系统性能 对于每个盒子的处理必须在下一个盒 子
5、到达条形码阅读器前完成,传送带分类系统约束 该软件受硬件、可用内存、及 整个传送带的配置的约束,Next,广义的需求管理 狭义的需求管理,需求管理 概述（1/4）,为什么要做需求管理？ 实验表明：需求缺陷最多，而且随着各阶段的逐渐进行，修复需求缺陷所付出的代价最大 需求管理的目的是什么？ 使软件需求受控，并建立供软件工程和管理使用的需求基线 使软件计划、产品和活动与软件需求保持一致,需求管理 概述（2/4）,管理中应坚持哪些原则？ 需求一定要分类管理 需求必须分优先级 需求必须文档化 需求一旦变化，就必须对需求变更的影响进行评估 需求管理必须与需求工程的其他活动紧密整合,需求管理 概述（3/4
6、）,需求管理 概述（4/4）,在需求管理中，项目经理该干些什么？ 借助具体工具和手段，对需求的开发、实现和变更进行控制和管理,需求开发的管理 需求处理阶段,在需求处理阶段，项目经理该干些什么？ 明确需求的来源 指导需求形式化 需求文档化 需求数据库化 指导建立需求跟踪矩阵,需求开发的管理 需求验证阶段（1）,步骤： 编写测试计划和测试用例 编写用户使用手册 编写系统验收标准 通过需求评审,需求开发的管理 需求验证阶段（2）,需求评审对象： 软件需求规格说明书 需求评审内容： 确定不完整和遗漏的给定需求 评审给定需求，并确定它们是否可行，适于软件实现，说明是否清楚、适当、一致，是否可测试 确认可
7、能有问题的需求，评审并修改 相关小组协商由给定需求得出的约定,需求开发的管理 需求验证阶段（3）,良好的需求规格说明书： 准确 完整 无歧义 一致 需求分级 可检验 可修改 可跟踪 可理解,需求开发的管理 需求验证阶段（4）,验证中应进行的检查： 有效性检查 一致性检查 完备性检查 现实性检查 可检验性检查 可跟踪性检查 可调节性检查 可读性检查,需求开发的管理 需求验证阶段（5）,在需求验证阶段，项目经理该干些什么？ 参与评审 关注评审内容和结构 根据评审意见，与评审委员会一起决定项目的下一阶段,需求实现的管理 需求属性,需求的创建时间 需求的版本 需求的创建者 需求的批准者 需求状态 需求
8、的起因或根据 需求的优先级 需求的稳定性 需求和其他产品的关系,需求实现的管理 需求状态,已建议 已批准 已拒绝 已设计 已实现 已验证 已交付 已删除,需求实现的管理 需求跟踪,正向跟踪 以用户需求为切入点，检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点 逆向跟踪 检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处,需求跟踪时需要考虑： 需求本身的提出者等 需求和其他需求的关系 需求和设计的关系,Next,制定软件项目开发计划,软件项目计划,计划从估算开始 建立计划 整体计划 贯穿项目始终 详细计划 完成规格说明之后必须产生的,估算什么？,
9、估算成本 内部成本 外部成本 估算开发周期,影响估算的因素,项目复杂性 项目规模 结构不确定性,影响估算结果的最大因素：？,不同开发人员之间的差距： 产品规模上： 6：1 产品执行时间上： 8：1 开发时间上： 9：1 编码时间上： 18：1 调试时间上： 28：1 平均： 5：1,软件项目计划活动 估算需要的资源,有哪些项目资源？ 开发环境 可复用构件 人员,软件项目计划活动 软件项目估算（1）,怎么进行估算？ 将估算拖延到项目的后期 基于已经完成的类似项目进行估算 使用相对简单的分解技术以生成项目成本及工作量估算 使用一个或多个经验模型进行软件成本及工作量的估算,软件项目计划活动 软件项目
10、估算（2）,估算内容： 产品规模度量 产品成本估算,产品规模度量 代码行（1）,代码行数 代码行（LOC） Lines Of Code 已交付源代码指令（KDSI） Thousand Delivered Source Instructions,产品规模度量 代码行（2）,产品规模度量 代码行（3）,可用的度量 每千行代码（KLOC）的错误数 每千行代码（KLOC）的缺陷数 每个代码行（LOC）的花费 每千行代码（KLOC）的文档页数 每人月的错误数 每人月的代码行（LOC） 每页文档的花费,产品规模度量 代码行（4）,支持者： LOC是所有软件开发项目的“生成品” 易于计算 很多软件估算模型使
11、用LOC作为输入 反对者： LOC测量依赖于语言 对设计得很好但较小的程序会产生不利的评判 估算时需要一些难以得到的信息,产品规模度量 功能点（1）,功能点（function point）： 用户输入数 用户输出数 用户查询数 文件数 外部接口数,产品规模度量 功能点（2）,FP = a*Inp + b*Out + c*Inq + d*Maf + e*Inf 其中a,b,c,d,e为常数 为产品的各个组件指定对应的复杂度级别 查表找出对应级别的功能点系数 对分配给每个组件的功能点求和 上面得到的实际上是UFP（unadjusted）,产品规模度量 功能点（3）,计算UFP 计算技术复杂因子TCF（Technical Complexity Factor） 查表得到各部分影响度 累加得到总影响度DI（Degree Of Influence） TCF = 0.65 + 0.01*DI 计算功能点FP FP = UFP*TCF,产品规模度量 功能点（4）,可用的度量 每个功能点（FP）的错误数 每个功能点（FP）的缺陷数 每个功能点（FP）的花费 每个功能点（FP）的文档页数 每人月的功能点（FP）数,产品规模度量 功能点（5）,支持者： FP与程序设计语言无关 基于项目开发初期就有可能得到的数据 反对者： FP的计算基于主观的数据 FP没有直接的物理含义,产品规模度量 二者的转换,
