软件过程与项目管理复习

第一章：软件及软件工程

软件的概念

• 什么是软件？
  软件是一组对象或项目所形成的一个“配置”，由程序、文档、数据等部分构成。
• 软件的四大特性
  1. 复杂性
  2. 不可见性
  3. 易变性
  4. 一致性

软件工程的发展

• 软件的发展阶段
  1. 第一阶段
     • 主要用于数值计算的需求
     • 完全依赖于程序员的个人才能
     • “软件危机” 的出现
  2. 第二阶段
     • 开始向商务领域推广
     • “软件生命周期” 的概念开始形成
  3. 第三阶段
     • 软件系统的规模、复杂度进一步扩大
     • 开始关注对软件开发过程的管理和工程性的开发
     • 出现了CASE工具
     • 开始关注软件的质量度量和管理
     • 面向对象（OO） 思想开始出现
  4. 第四阶段
     • Internet和Web -> 分布式、异构环境下的软件
     • 软件复用成为关注点
     • 软件生命周期的每一个阶段都发展出详细的方法论
     • 分布式计算、网格技术
  5. 第五阶段
     • 软件的服务化、系统互操作的需求
     • 基于云计算平台的软件体系结构、模型驱动的开发方法MDA、敏捷软件开发方法、软件集成开发环境及工具
     • 面向对象的体系架构SOA方法
     • 基于互联网与云计算的软件开发方法
     • 普适计算、移动计算
• 软件开发技术的发展过程
  • 1950~1960年代
    • 软件 = 程序
    • 面向过程的软件 = 算法 + 数据结构
  • 1970年代
    • 软件 = 程序 + 文档
    • 软件 = 程序 + 文档 + 数据
  • 1980~1990年代
    • 面向对象的软件 = 对象 + 消息
  • 1990至今
    • 面向构件的软件 = 构件 + 框架
    • 面向服务的软件 = 服务 + 消息 + 总线
• 软件危机
  • 软件危机：计算机软件的开发和维护过程所遇到的一系列严重问题
  • 出现软件危机的原因
    1. 客观上，软件产品开发的复杂度和难度随软件规模呈指数级别增长；
    2. 主观上，软件开发人员缺乏工程性的、系统性的方法论

软件工程的概念

• 什么是软件工程？
  • 软件工程重要的 不是技术 而是 如何开发软件项目的思想
  • 软件工程是一种 建模 活动
  • 软件工程是一种 解决问题 的活动
  • 软件工程是一种 知识获取 的活动
  • 软件工程是一种 受软件工程原理指导 的活动
• 软件工程的范围
  • 过程
  • 方法
  • 工具
  • 质量
• 软件工程的目标
  • 满足用户需求
  • 按时交付
  • 控制成本
  • 高质量软件
• 软件的质量特性
  • 软件开发效率
  • 用户满意度
  • 可靠性
  • 可维护性

第二章：软件工程核心思想

• 软件工程的本质
  用严格的规范和管理手段来缩小偏差，通过牺牲“时间”来提高“质量”
• 软件工程的两个映射
  • 概念映射：问题空间的概念与计算机解空间的模型化概念之间的映射
  • 业务逻辑映射：问题空间的处理逻辑与计算机解空间处理逻辑之间的映射
• 软件工程所关注的对象
  软件工程具有 “产品与过程二相性” 的特点，必须把二者结合起来去考虑，而不能忽略其中任何一方。
• 软件工程所关注的目标
  • 功能性需求：软件所实现的功能达到它的设计规范和满足用户需求的程度
  • 功能性需求关注的目标：
    • 完备性
    • 正确性
    • 健壮性
    • 可靠性
  • 非功能性需求：系统能够完成所期望的工作的性能与质量
  • 非功能性需求关注的目标：
    • 效率
    • 可用性
    • 可维护性
    • 可移植性
    • 清晰性
    • 安全性
    • 兼容性
    • 经济性
    • 商业质量
• 软件工程的四个核心理论概念
  • 分治：核心问题是如何分解策略可以使得软件更容易理解、开发和维护
  • 复用：已有的架构、框架、团队、软构件、功能模块
  • 折中：核心问题是如何调和矛盾
  • 演化：可修改性、可维护性、可扩展性

第三章：软件过程模型

• 软件过程定义的内容
  • 人员与分工
  • 执行的活动
  • 活动的细节和步骤
• 软件过程通过以下方式组织和管理软件生命周期
  • 定义软件生产中的活动
  • 定义这些活动的顺序及其关系
• 软件过程的目的
  • 标准化、可预见性、提高开发效率、获得高质量产品
  • 提升指定时间和预算计划的能力
• 软件过程的实质
  在软件开发生命周期内采取特定的方式和策略进行过程管理控制
  软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。
• 软件过程模型分类
  • 预测型
    • 瀑布模型、V模型、形式化过程
  • 迭代型
    • 增量模型、RAD
  • 增量型
    • 增量模型、原型模型
  • 敏捷型
    • XP、Scrum
  • 其他过程模型
    • 基于复用的过程模型
• 软件过程模型

第四章：敏捷方法与过程

• 为什么要“敏捷”？
  • 开发的过程中 “变化”是无处不在的，也是不可避免的
  • 在实际项目中，很难预测需求和系统何时以及如何发生变化
  • 对开发者来说，应将变化的意识贯穿在每一项开发活动中
• 敏捷宣言遵循的12条原则
  1. 我们最高的目标是通过尽早和持续交付有价值的软件来满足客户
  2. 欢迎对需求提出变更
  3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好
  4. 项目过程中，业务人员与开发人员必须在一起工作
  5. 要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务
  6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
  7. 可用的软件是衡量进度的主要指标
  8. 敏捷过程提倡可持续的开发；项目方、开发人员和用户应该能够保持恒久稳定的进度速度
  9. 对技术的精益求精以及对设计的不断完善将提升敏捷性
  10. 要做到简洁，尽最大可能减少不必要工作
  11. 最佳的架构、需求和设计出自于自组织的团队
  12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为
• 敏捷方法的本质是什么
  以快速的增量和迭代方式进行软件开发
• 敏捷过程中最重要的因素：人
  • 基本能力
  • 共同目标
  • 精诚合作
  • 决策能力
  • 模糊问题解决能力
  • 相互信任与尊重
  • 自我组织
• 结对编程的程序各方面质量取决于各方面水平较高的那一位
• 关于XP的一些反对意见
  • 需求波动
  • 客户需求冲突
  • 需求非正规表达
  • 缺乏形式化设计
• Scrum的基本过程
  1. Product Owner组织会议将计划开发的产品分解成若干开发项
  2. Product Backlog中的一个或几个任务项，是一次Scrum Sprint要开发的任务
  3. 在Sprint开始前，Scrum Master组织Scrum Team会议
  4. Sprint启动后，每天需要召开一次会议
  5. Sprint结束后
• 各类过程模型规划
  • 瀑布模型：将全部需求以整体方式向前推进，无迭代
  • 增量模型：将需求分成多份，串行推进，无迭代
  • RAD模型：将需求分成多份，可并行推进，无迭代
  • 原型模型：始终结果可见，不断迭代修正原型，指导开发完成
  • 螺旋模型：按瀑布阶段划分，各阶段分别迭代（原型+风险分析）
  • 敏捷模型：将需求分成尽量小的碎片，以碎片为单位进行高速迭代

第五章 软件项目管理

概述

• 项目
  为创建某种特定的产品或服务而组织或设计的临时的、一次性的行动，通过执行一组行动，使用受约束的资源（资金、人、原料、能源、空间等）来满足预定义的目标
• 项目管理
  有效的组织与管理各类资源，以是项目能够在预定的范围、质量、时间和成本等约束条件下顺利交付
• 软件项目管理
  为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员、产品、过程和项目进行分析和管理的活动
• 软件项目的参与人员
  • 高级管理者
  • 项目管理者
  • 开发人员
  • 客户
  • 最终用户
• 项目关注的四个方面
  • 范围
  • 时间
  • 成本
  • 质量
• 项目管理的主要任务
  • 项目可行性分析与估算
  • 项目进度安排
  • 项目风险管理
  • 项目质量管理
  • 项目跟踪与控制
• 可行性分析的四个方面
  • 技术可行性
  • 经济可行性
  • 时间可行性
  • 资源可行性

任务分解

• 项目任务分解
  项目任务分解就是详细而正确定义软件项目开发的工作范围或边界，得到项目管理的基本粒度和任务集合
• WBS：工作分解结构
  • 是对项目工作任务由粗到细的分解结果的表达形式
  • 最终结果是面向可交付的软件提交物
  • 组织并定义了整个项目范围
• 工作包
  • 是WBS最低层次的可交付成果，即WBS中的“叶子结点”
  • 每个工作包应当由唯一主体负责
  • 项目管理的基本单位，成本估算、进度安排、跟踪控制等管理的最小对象
• WBS形式
  • 组织结构图式
  • 提纲式
• 任务分解方法
  • 模板参照法
  • 类比法
  • 自顶向下方法
  • 自底向上方法

• WBS任务分解粒度的掌控
  80/8规则：\(8小时（一天） \leq 工作包 \leq 80小时（两周）\)
• 用户故事分解概念
  • 史诗故事
  • 软件特性
  • 用户故事
  • 任务

成本估算

• 功能点估算
  • EI/EO：外部输入输出
  • EQ：外部查询
  • EIF：外部接口文件
  • ILF：内部逻辑文件
  1. 计算 \(UFC = 功能项系数 \times 复杂度系数\)
  2. 计算 \(TCF = 0.65 + 0.01 \times \sum F_i\) 故 \(0.65 \leq TCF \leq 1.35\)
  3. 计算 \(FP = UFC \times TCF\)
  4. 计算工作量
• 用例点估算
  1. 计算未调整的角色权值 \(UAW = 数量 \times 权值\)
  2. 计算未调整的用例权值 \(UUCW = 数量 \times 权值\)
  3. 计算未调整的用例点 \(UUCP = UAW + UUCW\)
  4. 计算技术复杂度因子 \(TCF = 0.6 + 0.01 \times \sum({TCF_{weight} \times Value)}\)
  5. 计算环境复杂度因子 \(ECF = 1.4 + (-0.03 \times \sum(ECF_{weight} \times Value))\)
  6. 计算调整的用例点 \(UCP = UUCP \times TCF \times ECF\)
  7. 计算工作量
• 类比计算
  • \(distance(P_i,P_j) = \sqrt{\frac{\sum_{k = 1}^{n}{\delta(P_{ik},P_{jk})}}{n}}\)
  • \(\delta(P_{ik},P_{jk}) = (\frac{|P_{ik}, P{jk}|}{max_k - min_k})^2（k是连续的）或0（k是分散的且P_{ik} = P_{jk}）或1(k是分散的且P_{ik} \neq P_{jk})\)

进度计划

• 进度
  进度是对执行的活动和里程碑制定的工作计划日期表

• 进度计划执行过程

  1. 任务定义
  2. 任务关系
  3. 历时估算
  4. 项目进度编排
  5. 项目进度优化

• 任务
  确定为完成项目的各个交付成果所必须进行的诸项具体活动

• 项目任务的关联关系

  • 结束-开始
  • 结束-结束
  • 开始-开始
  • 开始-结束

• 关系依赖矩阵
  如果 \(d_i\) 是 \(d_j\) 的前置，则 \(d_{ij} = 1\)，否则 \(d_{ij} = 0\)

• 定额估算法
  \(T = \frac{Q}{R \times S}\)

  • T：活动历时
  • Q：任务工作量
  • R：人力数量
  • S：工作效率（贡献率）

• 经验导出模型
  \(D = a \times E^b\)

  • D：进度（月）
  • E：工作量（人月）
  • a：2到4之间
  • \(\frac{1}{3}\) 左右：依赖于项目的自然属性

• 基于承诺的进度估算优点
  有利于开发者对进度的关注，充分发挥主观能动性

• 项目进度管理图示
  
  

• 任务滞后：Lag

• 任务超前：Lead

• 浮动时间

  • 总浮动时间：在不影响项目最早完成时间的前提下一个任务/活动可以延迟的时间
  • 自由浮动时间：在不影响后置任务/活动最早开始时间的前提下一个任务/活动可以延迟的时间

• 关键路径：正推法

  • 计算ES、EF
    • \(EF = ES + duration\)
    • \(ES = EF(p) + Lag - Lead\)
  • 计算每个路径所有任务的ES和EF
  • 最后根据EF最大值的节点为线索，确定关键路径

• 关键路径：逆推法

  • 计算LS、LF
    • \(LS = LF - duration\)
    • \(LF = LS(s) - Lag + Lead\)
  • 遍历网络图，计算每个路径的所有任务的LS和LF
  • 最后，确地关键路径：找到浮动时间 \(Float\) 为 \(0\) 的路径

团队计划

• 软件开发团队的组织方式
  • 一窝蜂模式
  • 主治医师模式
  • 明星模式
  • 社区模式
  • 交响乐团模式
  • 爵士乐模式
  • 功能团队模式
  • 官僚模式
• 组织结构的主要类型
  • 职能型
    • 优点
      • 以职能部门为主体承担项目，可充分发挥职能部门的人力优势
      • 职能部门内部技术专家可以被多个项目共享，节约人力资源
      • 同一职能部门内部专业人员便于交流、支援
      • 项目成员有调离时，容易在部门内部增员，保持项目技术连续性
      • 项目成员将项目工作与本职能部门工作融合，减少因项目临时性带来的不确定性
    • 缺点
      • 客户利益与职能部门利益发生冲突，项目及客户利益往往不优先考虑
      • 当项目需要多个职能部门共同完成，或者部门内部承担多个项目时，资源的平衡就会出现问题
      • 当项目需要多个职能部门共同完成，由于权利分割不利于各部门沟通，项目经理没有足够权利控制项目进展
      • 项目成员在行政上隶属于各职能部门的领导，项目经理对项目成员没有足够的控制权力，沟通成本高
  • 矩阵型
    • 优点
      • 专制的项目经理负责整个项目，以项目为中心，能迅速解决问题，在最短的时间内调配人员组成团队，将不同职能的人集中在一起
      • 多个项目可以共享各个职能部门的资源
      • 既有利于项目目标的实现，也有利于公司长远目标方针的贯彻
      • 项目结束后可以回到原来部门，项目成员顾虑减少了
    • 缺点
      • 容易引起职能部门经理与项目经理权力的冲突
      • 资源共享可能会引起项目组之间的冲突
      • 项目成员有项目经理和原职能部门领导等多重领导，会有一定焦虑和压力

第六章 软件演化与配置管理

• 软件演化的 Lehman 定律
  • 持续变化
  • 复杂度逐渐增大
• 软件演化的处理策略
  • 软件维护
  • 软件再工程
• 软件维护
  在软件产品发行和投入运行之后对其的修改，以改正错误，改善性能或其他属性，从而使产品适应新的环境或新的需求
• 软件维护的类型
  • 纠错性维护
  • 适应性维护
  • 完善性维护（占比最大）
  • 预防性维护
• 软件维护的内容
  • 程序维护
  • 数据维护
  • 硬件维护
• 软件维护中出现的大部分问题都可归咎于软件规划和开发方法的缺陷
• 造成困难的根本原因
  • 很难甚至不可能追踪的整个创建过程
  • 很难甚至不可能追踪软件版本的进化过程，软件的变化没在响应文档中反映出来
  • 理解他人的程序非常困难，当软件配置不全、仅有源代码时问题尤为严重
  • 软件人员流动性很大，维护他人软件时很难得到开发者的帮助
  • 软件没有文档、或文档不全、或文档不易理解、或与源代码不一致
  • 多数软件设计未考虑修改的需要（有些设计方法采用了功能独立和对象类型等一些便于修改的概念），软件修改不仅困难而且容易出错
  • 软件维护不是一项有吸引力的工作，从事这项工作令人缺乏成就感
• 不好的维护造成的代价
  • 丧失了开发的良机
  • 引起用户不满
  • 引入了潜伏的故障
  • 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱
  • 生产率的大幅下降
• 缺乏管理造成的问题
  • 软件生产达不到规模化
  • 缺少有效的沟通机制
  • 成员间缺少沟通
  • 人员流动
• 软件配置
  由在软件工程过程中产生的所有信息项构成，它可以看作该软件的具体形态（软件配置项）在某一时刻瞬间映像。
• 软件配置管理的含义
  • 使得混乱减到最小，正在开发软件的修改进行标识、组织和控制
  • 处理变更，随时保持其完整性，变更请求跟踪变更，并保存系统在不同时刻的状态。
• 软件配置管理的目标
  • 标识变更
  • 控制变更
  • 确保变更的正确实现
  • 总结：当变更发生时，能够提高适应变更的容易程度，并且能够减少所花费的工作量
• SCM的基本元素
  • 配置项
  • 基线
  • 配置管理数据库
  • 最终硬件库
  • 最终软件库
• 基线
  已正式通过评审和标准的软件配置项