[哈工大软件工程期末考试] 《软件过程与项目管理》复习笔记

最新推荐文章于 2026-08-19 20:21:37 发布

原创

最新推荐文章于 2026-08-19 20:21:37 发布 · 1.3k 阅读

软件过程与项目管理复习

第一章：软件及软件工程

软件的概念

什么是软件？
软件是一组对象或项目所形成的一个“配置”，由程序、文档、数据等部分构成。
软件的四大特性
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
- 其他过程模型
  - 基于复用的过程模型
软件过程模型

名称	特点	优点	缺点	适用场合
瀑布模型	各个阶段的工作按顺序连接，难以向前回溯	追求效率	过于理想化：用户难以清楚地确定所有需求，难以快速响应用户需求变更；开发人员与用户之间缺乏有效的沟通；在项目接近尾声的时候才能得到可执行的程序，可能会造成重大损失	软件项目较小，各模块间接口定义非常清晰；需求在项目开始之前就已经被全面了解，产品定义非常稳定；使用的技术非常成熟，团队成员都很熟悉这些技术；负责各个步骤的子团队分属不同的机构或不同的地理位置，不可能做到频繁的交流；外部环境的不可控因素很少
V模型/W模型	强调测试的重要性，将开发活动与测试活动紧密联系在一起，W模型比V模型增加了软件开发各阶段中同步进行的验证和确认活动	开发过程重视测试/验证：简单易用；强调测试验证与开发过程的对应性和并行性；避免缺陷向下游流动	比瀑布模型繁琐	-
增量过程模型	软件被作为一系列的增量来设计、实现、集成和测试，每一个增量是由多个相互作用的模块所形成的特定功能模块或功能模块组，本质是以迭代的方式运用瀑布模型，第一个增量往往是核心产品。	交付满足客户需求的一个子集的可运行产品，对客户起到“镇定剂”的作用；人员分配灵活，如果找不到足够的开发人员可采用；使用户有较充裕的时间来学习和适应新产品；项目总体性失败风险低。	增加增量必须不破坏已构造好的部分；加入新增量时应简单、方便；无法处理需求变更的情况；管理人员必须有足够的技术能力协调各增量之间的关系	-
RAD 模型（快速应用开发模型）	侧重于短开发周期；多个团队并发进行开发	-	需要大量的人力资源；必须在短时间内为急速完成整个系统做好准备；需要合理的模块化系统；技术风险很高的情况下不适用	-
快速原型法	设计并调整原型	提高和改善客户/用户的参与程度，最大程度的相应用户需求的变化；客服预测性模型的缺点，减少由于需求不够明确带来的开发风险	没有考虑整体软件的质量和长期的可维护性，系统结构通常较差；可能混淆原型系统与最终系统；额外的开发费用	-
螺旋式过程模型	在四个象限内沿着螺线旋转：制定计划、风险分析、实施工程、客户评估。出发点是：开发过程中计时识别和分析风险，并采取适当措施以消除或减少风险带来的危害	结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型	适用于大规模软件项目，特别是内部项目，周期长、成本高；软件开发人员应该擅长寻找可能的风险，准确的分析风险	-
总结：迭代过程模型	需求的变更频繁，要求在非常短的期限内实现，以充分满足客户要求、及时投入市场	-	由于构建产品所需的周期数不确定，给项目管理带来困难；迭代速度太快，项目陷入混乱；迭代速度太慢，影响生产率；为追求软件的高质量而牺牲了开发速度、灵活性和可扩展性	-
形式化过程模型	使用严格的数学形式来刻画每一阶段的产物；应用一系列形式化方法咋各阶段的产物之间进行自动/半自动的转换	应用数学分析法，歧义性、不完整性、不一致性等问题更容易被发现和改正，目的是“提供无缺陷的软件”	形式化数学方法难以理解，可视性太差，对开发人员技能要求较高；构造形式化模型非常耗时，成本很高；软件系统中的某些方面难以用形式化模型表达出来	对可靠性和安全性要求较高的一些关键系统

第四章：敏捷方法与过程

为什么要“敏捷”？
- 开发的过程中 “变化”是无处不在的，也是不可避免的
- 在实际项目中，很难预测需求和系统何时以及如何发生变化
- 对开发者来说，应将变化的意识贯穿在每一项开发活动中
敏捷宣言遵循的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开发人员的要求较高	熟悉的业务领域项目，可以复用的项目
自底向上方法	从底层问题入手，先考虑底层任务，进而聚类形成更高层次WBS任务节点层	可以集思广益、头脑风暴，快速开展工作	容易遗漏任务点，不够系统、全面	新业务领域项目，项目新增量，尤其适合敏捷方法