小组软件过程.pptVIP

小组软件过程 董 威 计算机学院602教研室 E-mail：wdong@nudt.edu.cn 为什么工程会失败 如果软件工程失败了，通常是因为协同工作的问题，而不是技术上的问题。 是人的问题 常见的问题 领导不力 无法协调或合作 缺少参与 拖延和缺少自信 质量低劣 随意增加功能 小组是什么 小组规模 4～5人 具有凝聚力的小组 协同工作基本条件 要完成的任务必须清楚明确 小组必须是明确确定的 小组必须对它的项目有自始至终的控制 建立高效的小组 小组内聚力 挑战性的目标 反馈 共同工作框架 必须完成什么计划？ 什么时间？ 按照什么顺序？ 由谁来完成？ 怎样组建小组 目标 确定和接受一系列共同的目标 角色 明确责任 计划 确定达到目标的战略 交流 成员之间的交流 对外交流 小组与其他团体的交流 小组目标 具有挑战性，却是可实现的 目标必须是具体的，可评估的 如 开发一个优质的产品 进行一项高效率的、管理良好的工程 按时完成 小组目标 开发一个优质的产品 在第一次编译之前发现的错误百分比：80% 在系统测试中发现缺陷数目：0 完成的产品包含的需求功能：100% 进行一项高效率的、管理良好的工程 产品大小估计的误差：20% 开发时间估计的误差：20% 按时完成 提前或推迟开发周期的天数：4 小组成员目标 所有小组成员都要有具体可评估的目标 成为一个合作的有效率的小组成员 第一目标 进行始终如一的有纪律的个人工作 计划和跟踪个人的工作 生产出优质的产品 角色目标 小组长目标 组建并维持一个有效的小组 分配任务 激励小组的所有成员在工程中努力工作 解决小组成员提交给你的所有冲突 让教师全面了解小组的进度 有效地作为小组会议的召集者 充当开发人员 角色目标 小组长所需的性格特点 愿意担负责任 能作客观的决定 能督促同学发挥最大的才能 尊重你所领导的小组成员 角色目标 项目主管目标 生产一个出色的产品 全面发挥小组成员的能力和才干 角色目标 项目主管主要任务 领导小组制定开发策略 领导小组给要设计的产品制定最初的大小和时间估计 领导软件需求细节的开发 领导小组制定出高水平的设计 领导小组制定出软件设计细节 领导小组实现并测试产品 参加开发 角色目标 项目主管所需的性格特点 最重要的是：喜欢创建新东西 想成为软件工程师，并想具有领导工程的设计和开发工作的经历 熟悉最主要的设计方法 能听取并采纳其他人的意见 角色目标 计划制定者目标 为小组和每个小组成员制定一个完整的、精确的、正确的计划 定期（如每周）准确地报告小组情况 角色目标 计划制定者的主要任务 领导小组制定开发周期的任务计划 领导小组制定开发周期的日程表 领导小组制定平衡稳定的计划 跟踪小组对照计划进行的情况 参加开发 角色目标 产品质量控制目标 代码检查 测试计划 技术支持目标 开发语言、工具 测试方法、工具 软件配置管理、版本管理等 对个人的要求 对工作负责 履行责任 决不放弃 努力为工作目标奋斗 严格按时间表工作 明确的工作目标产生明确的工作目的 与小组成员合作 小组协作责任 透明性 聆听 协商：有原则的协商，求同存异 参与小组活动 勇于发表自己的看法 对他人的意见要给予关注 参与小组工作计划的制定并努力按照工作计划开展工作 项目启动 获得个人信息 每周哪些时间可用于项目开发、个人特长等信息 产品目标 小组成员共同讨论确定，获得教师认可 角色分配 不是固定死的，可兼任 开发过程 按什么过程开发目标产品 瀑布模型 原型模型 增量模型 迭代模型 螺旋模型 瀑布模型 特点 分阶段 阶段间有因果关系 评审 允许反馈 原型模型 特点 有效适应用户需求的变化 不知循环多少次，进度难以控制 适合场所 需求动态变化、难以确定的软件系统 增量模型 特点 并行开发 管理复杂 迭代模型 特点 通过逐步迭代，建立软件系统 适合场所 需求没有/难以完整定义的软件 螺旋模型 特点 以风险为导向 适合场所 开发风险较大的软件 注意 应该努力选择满足开发小组要求、尽可能少的软件开发过程模型 软件开发模型数目不宜过多 所选择的软件开发模型不宜过于复杂 最好选择那些成员熟悉的、有使用经验的软件开发过程模型 工作量估计 估计方法 基于功能点的估算方法 工作量分布 工作量估计方法 自顶向下 COCOMO模型 LOC估计模型 功能点估计模型 自底向上 先获得项目各部分估计的规模，再得到整个项目的估计的规模 基于功能点的估算方法(1/3) 将每个功能分类为简单功能、中等复杂功能和复杂功能(表1) 根据应用中功能因子的加权和求得总的未经调整的功能点UUCP 计算技术复杂度因子TCF (表2)， TCF=0.6 + (0.01 ×TFactor) 计算出环境因子EF (表3)， EF=1.4 + (-0.03