软件工程导论(PPT 69页).ppt

SoftwareEngineeringCCUTSE2013 软件工程导论 第4篇软件项目管理 1 估算软件规模2 工作量估算3 进度计划4 人员组织5 质量保证6 能力成熟度模型7 软件配置管理8 能力成熟度模型 主要内容 导言 俗话说 三分技术 七分管理 俗话说 吃不穷穿不穷算计不到就受穷 俗话说 巧妇难为无米之炊 软件工程包括技术和管理两方面的内容 是技术与管理紧密结合所形成的工程学科 导言 俗话说 三分技术 七分管理 工程与项目工程 是类 是总称 项目 是对象 是实例 是一个具体的工程 导言 软件项目管理贯穿于软件的整个生命周期 导言 软件项目管理 什么是管理 management 管理就是通过计划 组织和控制等一系列活动 合理地配置和使用资源 达到既定目标的过程 导言 计划 组织 控制 过程 资源 合理使用与配置 效率质量 软件项目管理的内容 导言 时间管理 人员管理 配置管理 质量管理 项目的时间管理 导言 估算工作量 软件需求 KLOCFP 估算规模 人月 估算进度 GanttPert 模型 模型 模型 项目的人员管理 导言 民主制程序员组 主程序员组 现代程序员组 项目的质量管理 导言 SQA小组 计划 监督 记录 分析 报告 活动 措施 基于非执行的测试 基于执行的测试 程序正确性证明 软件的配置管理 导言 变化管理 标识变化 版本控制 变化控制 报告 配置审计 能力成熟度模型 评价软件机构的软件过程能力成熟度的模型 导言 能力成熟度模型 评价软件机构的软件过程能力成熟度的模型 导言 能力成熟度模型 评价软件机构的软件过程能力成熟度的模型 导言 能力成熟度模型 评价软件机构的软件过程能力成熟度的模型 导言 能力成熟度模型 评价软件机构的软件过程能力成熟度的模型 导言 1 代码行 KLOC LOC 技术 11 1估计软件规模 出发点 依据以往开发类似产品的经验和历史数据 加权平均法 多名有经验的软件工程师每人都估计程序的最小规模 a 最大规模 b 和最可能的规模 m 分别计算出这3中规模的平均值a b和m之后 计算L 1 代码行 KLOC LOC 技术 11 1估计软件规模 6 11 4 14 12 13 17 1 代码行 KLOC LOC 技术 11 1估计软件规模 优点 代码是所有软件项目的产品 且代码行易于计算 缺点 1 代码仅是软件配置的成分之一 用代码行表示软件规模不尽合理 2 用不同语言实现统一软件 代码行数并不相同 2 功能点 FP 技术 11 1估计软件规模 克服代码行技术的缺点 依据软件信息域特性和软件复杂性的评测结果 用功能点 FP 为单位度量软件规模 2 功能点 FP 技术 11 1估计软件规模 1 信息域特性 输入项数 Inp 输出项数 Out 查询数 Inq 主文件数 Maf 外部接口数 Maf 信息域 2 功能点 FP 技术 11 1估计软件规模 1 信息域特性 输入项数 Inp 用户向软件输入的项数 这些输入给软件提供面向应用的数据 不包括查询 输出项数 Out 查询数主文件数外部接口数 2 功能点 FP 技术 11 1估计软件规模 2 估算功能点的步骤 计算未调整的功能点UFP 计算技术复杂性因子TCF 计算功能点数FP 2 功能点 FP 技术 11 1估计软件规模 2 估算功能点的步骤 计算未调整的功能点UFP UFP a1 Inp a2 Out a3 Inq a4 Maf a5 Inf 2 功能点 FP 技术 13 1估计软件规模 2 估算功能点的步骤 计算技术复杂性因子TCF 确定技术因素对软件规模的影响值F1 F14 0 Fi 5 计算技术因素对软件规模的综合影响程度DI DI Fi 计算技术复杂性因子TCF TCF 0 65 0 01 DI i 1 14 2 功能点 FP 技术 11 1估计软件规模 2 估算功能点的步骤 技术因素 计算技术复杂性因子TCF 2 功能点 FP 技术 11 1估计软件规模 2 估算功能点的步骤 计算功能点数FP FP UFP TCF 2 功能点 FP 技术 11 1估计软件规模 3 FP技术的优缺点优点 与编程语言无关 比代码行技术更加合理 缺点 在判断信息与特性复杂级别和技术因素的影响度时 主观性较大 11 2工作量估计 工作量单位 人月 pm 工作量估算 是估算而不是计算 因为是事先而不是事后 工作量模型 是经验公式 是KLOC或FP的函数 模型类别 静态模型动态模型构造模型 11 2工作量估计 1 静态单变量模型 E A B ev C其中 E 工作量A B C 经验常数ev 估算变量 KLOC或FP 总体结构形式 11 2工作量估计 1 静态单变量模型 Walston Felix模型 E 5 2 KLOC 0 91 1 面向KLOC的估算模型 Bailey Basili模型 E 5 5 0 73 KLOC 1 16 Boehm简单模型 E 3 2 KLOC 1 05 Doty模型 KLOC 9时 E 5 288 KLOC 1 047 11 2工作量估计 1 静态单变量模型 Albrecht Gaffney模型 E 13 39 0 0545FP 2 面向FP的估算模型 Maston Barnett和Mellichamp模型 E 5 587 15 12FP 11 2工作量估计 1 静态单变量模型 对于相同的KLOC或FP用不同的模型得到的结果不同 这是因为模型经验来自于有限领域和有限项目 进而适用范围有限 因此实际应用时应适当调整模型 如 修改常数 3 静态单变量模型的评价 11 2工作量估计 2 动态多变量模型 E LOC B0 333 P 3 1 t 4其中E是工作量 t是项目持续时间 B是特殊技术因子 当KLOC 5 15时B 0 16 当KLOC 70时B 0 39 P是生产率参数 P 2000 嵌入式软件 P 10000 电信系统 系统软件 P 28000 商业应用系统 1 总体结构形式 11 2工作量估计 2 动态多变量模型 是软件规模和开发时间的函数 开发统一软件时 延长项目持续时间可降低完成项目所需的工作量 2 模型评价 11 2工作量估计 3 构造性成本模型 COCOMO2模型 应用系统组成模型 估算构建原型的工作量 早期设计模型 适用于体系结构设计阶段 后体系结构模型 适用于体系结构设计之后的开发阶段 1 模型层次 11 2工作量估计 3 构造性成本模型 COCOMO2模型 2 后体系结构模型 其中 E是工作量a是模型系数b是模型指数fi是成本因素 11 3进度计划 1 估算开发时间2 Gantt图3 工程网络4 估算工程进度5 关键路径6 机动时间 12人员组织 1 民主制程序员组2 主程序员组3 现代程序员组 民主制程序员组 主程序员组 现代程序员组 12人员组织 1 民主制程序员组 特点 地位平等 充分民主 协商决策 通信路径 n n 1 2规模 较小 2 8人为宜优点 积极面对程序错误 质量较高 充分民主 凝聚力高 利于攻关 实用于成员经验均丰富时 缺点 成员经验均不丰富 缺乏协调 导致失败 12人员组织 2 主程序员组 12人员组织 2 主程序员组 产生背景 IBM公司20世纪70年代初期发明 1 软件开发人员多数比较缺乏经验 2 程序设计过程中有许多事物性工作 如信息存储和更新 3 多渠道通信很费时间 将降低程序员的生产率 12人员组织 2 主程序员组 特性 1 专业化 该组每名成员仅完成他们受过专业训练的哪些工作 2 层次化 主程序员指挥没命组员工作 并对工作全面负责 12人员组织 2 主程序员组 分工 1 主程序员 体系结构设计 关键部分详细设计 技术指导 2 后备程序员 协助主程序员 必要时接替主程序员 3 编程秘书 负责事务性工作 12人员组织 2 主程序员组 缺点 1 主程序员 是高级程序员和优秀管理者的结合体 难找 2 后备程序员 期望与主程序员一样优秀 难找 3 编程秘书 专业人员厌烦事务工作 难找 12人员组织 3 现代程序员组 1 现代程序员组的结构 技术管理 非技术管理 12人员组织 3 现代程序员组 程序员 程序员 程序员 2 大型项目的技术管理组织结构 技术管理 组长 程序员 程序员 程序员 程序员 程序员 组长 组长 项目经理 12人员组织 3 现代程序员组 程序员 程序员 程序员 3 包含分散决策的组织方式 技术管理 组长 程序员 程序员 程序员 程序员 程序员 组长 组长 项目经理 项目的质量管理 12质量保证 SQA小组 计划 监督 记录 分析 报告 活动 措施 基于非执行的测试 基于执行的测试 程序正确性证明 12质量保证 1 何谓软件质量 定义 软件与明确地和隐含地定义的需求相一致的程度 明确地叙述的功能和性能需求 文档中明确描述的开发标准 任何专业开发的软件产品都应该具有的隐含特征 12质量保证 1 何谓软件质量 定义 软件与明确地和隐含地定义的需求相一致的程度 要点 1 与需求不一致就是质量不高 2 没有遵守开发准则会导致质量不高 3 不满足隐含的需求 质量仍然是值得怀疑的 13质量保证 1 何谓软件质量 软件质量因素与产品活动的关系 正确性 它按我的需要工作吗 健壮性 对意外环境它能适当地响应吗 效率 完成预定功能时它需要的计算机资源多吗 完整性 它是安全的吗 可用性 我能使用它吗 风险 能按计划完成它吗 可理解性 我能理解它吗 可维修性 我能修复它吗 灵活性 我能改变它吗 可测试性 我能测试它吗 可移植性 我能在另一台机器上使用它吗 可再用性 我能再用它的某些部分吗 互运行性 我能把它和另一个系统结合吗 13质量保证 2 软件质量保证措施 措施 基于非执行的测试 也称为复审或评审 用来保证在编码之前各阶段产生的文档的质量 基于执行的测试在程序编写出来之后保证软件质量的最后一道防线 程序正确性证明使用数学方法严格验证程序是否与它说明的完全一致 13质量保证 2 软件质量保证措施 人员 软件工程师采用先进的方法和度量 进行正式的技术复审以及完成计划周密的软件测试来保证软件质量 SQA小组通过计划 监督 记录 分析和报告等活动 辅助软件工程师 通过确保软件过程的质量来保证软件产品的质量 软件工程师 SQA小组 13质量保证 2 软件质量保证措施 技术复审 1 技术复审 走查 walkthrough 审查 inspection 2 技术复审的必要性能够较早发现软件错误 从而防止错误传播到软件过程的后续阶段 40 30 其它错误 60 70 规格说明或设计错误 复审发现规格说明或设计错误的75 13质量保证 2 软件质量保证措施 技术复审 3 走查小组 4 6人组成走查方式 参与驱动法 参与者按照事先准备好的列表 提出他们不理解的术语和认为不正确的术语 文档编写组的代表必须回答每个质疑 要么承认确实有错误 要么对质疑作出解释 文档驱动法 文档编写者向走查组成员仔细解释文档 走查组成员在此过程中针对问题进行质疑 这是更有效的方法 13质量保证 2 软件质量保证措施 技术复审 4 审查小组 4人组成 综述 准备 审查 返工 跟踪 文档编写者综述文档 评审员仔细阅读文档 评审组仔细走查文档 确保问题解决 文档作者解决问题 13质量保证 2 软件质量保证措施 技术复审 5 程序正确性证明 测试只能证明程序中有错误 不能证明程序中没有错误 如果在程序中的若干点上 设计者可以提出关于程序变量及它们的关系的断言 那么在每一点上的断言都应该永远是真的 13质量保证 2 软件质量保证措施 技术复审 5 程序正确性证明 P1 P2 Pi Pn Pi 1 a1 a2 ai 1 an ai 语句 断言 输出断言 输入断言 ai ai 1 如果 a1和an都是正确的且 则 Pi Pi 1 是正确的 从而所有语句是正确的 13软件配置管理 变化容易失控 一旦失控造成混乱或严重错误 管理整个生命周期的变化 在软件开发的过程中 变化 或称变动 既是必要的 又是不可避免的 软件配置管理 软件配置管理是在软件的整个生命周期内管理变化的一组活动 具体地说这组活动用来 1 标识变化 2 控制变化 3 确保适当地实现了变化 4 想需要知道这类信息的人报告变化 软件配置管理贯穿于软件的整个生命周期 13 6软件配置管理 软件配置管理 软件配置管理的目标使变化更正确且更容易被适应 在必须变化时减少所需花费的工作量 13 6软件配置管理 软件的配置项 13 6软件配置管理 计算机程序 源代码和可执行程序 描述计算机程序的文档 供技术人员或用户使用 数据 程序内包含的或在程序外的 基线 Baseline 13 6软件配置管理 数据 程序 文档 软件配置项 基线 正式复审 可以迅速而非正式修改 必须用特定的 正式的过程来评估 实现和验证每个变化 软件配置管理过程