目录
第一章 项目管理概述
- 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、进度、质量、风险进行分析和管理的活动。
- 项目管理是一系列伴随项目的进行而进行，目的是确保项目能够达到期望结果的一系列管理行为
- 软件项目管理的根本目的是让软件项目尤其是大型项目的生命周期能在管理者的控制之下，以预定成本按期、按质地完成软件项目，并且交付用户使用。
- 研究软件项目管理是为了从已有的成功或者失败的案例中总结出能够指导今后开发的通用原则、方法，以避免前人的失误。
- PMBOK：项目管理知识体系指南
- PMI：对项目管理所需的知识、技能和工具进行概括性的描述。
- 过程管理就是对过程进行管理，其目的是要让过程能够被共享、服用，并得到持续改进。
项目定义
- 项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。
- 是以一套独特而相互联系的任务为前提，有效地利用资源，在一定时间内满足一系列特定目标的多项相关工作的总称。
项目的特征
| 目标性 | 有明确的目标 |
| 相关性 | 项目之间的活动具有相关性 |
| 临时性 | 限定的周期 |
| 独特性 | 有独特性 |
| 资源的约束性 | 资源成本的约束性 |
| 不确定性 | 项目的不确定性 |
日常运作与项目的共同点
- 都需要人来完成
- 均受到有限资源的限制
- 均需要计划、执行、控制
日常运作与项目的不同点
- 项目是一次性的，日常运作是重复进行的；
- 项目是以目标为导向的，日常运作是通过效率和有效性体现的；
- 项目是通过项目经理及其团队工作完成的，日常运作是职能式的线性管理；
- 项目存在大量的变更管理，日常运作基本保持持续的连贯性。
软件项目的特殊性
- 逻辑实体（软件项目代表的是抽象的内容）
- 渐进明细（软件项目的内容随着软件项目的展开变得清晰明确）
- 相互作用的系统
- 变更
软件项目要素
- 软件开发的过程；
- 软件开发的结果；
- 软件开发赖以生存的资源及软件项目的特定委托人（客户，既是项目结果的需求者，也是项目实施的资金提供者）
项目目标实现的制约因素
| 项目范围S | 为使客户满意做的所有工作 |
| 成本C | 完成项目所需的费用 |
| 进度计划T | 每项任务的起止时间及所需的资源 |
| 客户满意度Q | 交付成果的质量 |
PMBOK体系图 （项目管理知识体系指南）
项目管理五大过程组
- 启动过程组
- 计划过程组
- 执行过程组
- 控制过程组
- 收尾过程组
| 启动过程组 | 主要是确定一个项目或一个阶段可以开始了，并要求着手实行；定义和授权项目或者项目的某个阶段。 |
| 计划过程组 | 为完成项目所要达到的商业要求而进行的实际可行的工作计划的设计、维护，确保实现项目的既定商业目标。计划基准是后面跟踪和监控的基础。 |
| 执行过程组 | 根据前面制定的基准计划，协调人力和其他资源，去执行项目管理计划或相关子计划。 |
| 控制过程组 | 通过监控和检测过程确保项目达到目标，必要时采取一些修正措施。集成变更控制是一个重要的过程。 |
| 收尾过程组 | 取得项目或阶段的正式认可并且有序地结束该项目或阶段。向客户提交相关产品，发布相关结束报告，并且更新组织过程资产并释放资源。 |
关系：各个过程组通过其结果进行连接，一个过程组的结果或输出是另一个过程组的输入。
其中，计划过程组、执行过程组、控制过程组是核心管理过程组。
PMBOK10个知识领域
- 项目集成管理
- 项目范围管理
- 项目时间管理
- 项目成本管理
- 项目质量管理
- 项目人力资源管理
- 项目沟通管理
- 项目风险管理
- 项目采购管理
- 项目干系人管理
软件项目管理过程
| 项目初始 |
|
| 项目计划 |
|
| 项目控制执行 |
|
| 项目结束 |
|
第二章 软件项目管理
- 在（项目立项）阶段，应该明确项目的目标、时间表、使用的资源和经费，而且得到项目发起人的认可。
- 项目建议书是项目结尾阶段开发的文档
Make or Buy 决策（自造-购买决策）
- 产品负责人确定待开发的产品哪些部分应当采购、外包开发或自主研发。
- 除了考虑自造-购买的初始成本，还要考虑后续的大量费用。
- 软件使用的时间较长、就制作， 时间较短可以购买
项目招投标过程
| 甲方过程 |
|
| 乙方过程 |
|
招标与竞标（招标的方式）
- 公开招标
- 有限招标
- 多方洽谈
- 直接谈判
项目章程(Project Charter) ——任务书
- 正式的授权项目，项目正式开始的标志
- 项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件
- 确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。
项目经理的职责
- 开发计划
- 组织实施
- 项目控制
招标书 （包括三部分）
| 技术说明 | 对采购的产品或者委托的项目进行详细的描述 |
| 商务说明 | 包括合同条款 |
| 投标说明 | 对项目背景、标书的提交格式、内容、提交时间等做出规定 |
第三章 项目初始-生存期
软件生存期模型特征
- 描述了开发的主要阶段
- 定义每一个阶段要完成的主要过程和活动
- 确定每一个阶段的输入和输出
常用传统生存期模型
| 瀑布模型 | 瀑布模型(严格按照顺序，没有反馈) 要求项目所有的活动都严格按照顺序进行，一个阶段的输入是下一个阶段的输入 适合瀑布模型的项目特征：
|
| V模型 | 强调测试的重要性 适合V模型的项目特征：
|
| 快速原型模型 | 需求阶段快速构建和调整原型满足客户要求 适合快速原型的项目特征：
|
| 增量模型 | 假设需求可以分段成一系列增量产品，整个产品分解成若干构件，按构件逐个交付产品 适合增量模型的项目特征：
|
| 渐近式阶段模型 | 强调分阶段完成，每个阶段提交不同版本的产品 特点：
优缺点：
|
第三章（2） 敏捷开发模型
- 关键词：人、迭代、灵活
- 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
- 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。（换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。）
- 以人为核心、迭代，循序渐进的开发方法，是一种轻量级的软件开发方法。
- 敏捷开发通过迭代和快速用户反馈应对管理的不确定性和变更。
敏捷模型
- 敏捷组织提出的一个灵活开发方法
- 应对迅速变化需求的快速软件开发方法
- 是一种迭代、循序渐进的开发方法
敏捷开发管理实践模型
Scrum（迭代式增量软件开发过程）
敏捷开发实践：
- 每日站立会议
- 燃尽图
XP（极限编程模型）
实施原则：
- 快速反馈
- 假设简单
- 包容变化
敏捷开发宣言
- 个体和交互胜过过程和工具。
- 可以工作的软件胜过面面俱到的文档。
- 客户合作胜过合同谈判。
- 响应变化胜过遵循计划。
第四章 软件项目需求管理
- 软件需求定义：需求是指用户对软件的功能和性能的要求
- 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书
-
需求变更是软件项目的的一个突出特点，可以导致软件项目的蔓延。
软件需求管理的过程
| 需求获取 | |
| 需求分析 |
|
| 需求规格编写 | |
| 需求验证 | |
| 需求变更 |
需求建模的基本方法
| 原型方法 | 需求分析、原型开发、原性评价 三者迭代 |
| 结构化分析方法 |
数据字典由三部分组成：
结构化分析方法-技术：
|
| 面向对象的用例分析法 |
|
| 功能列表法 |
UML需求视图
- 用例图
- 顺序图
- 状态图
- 活动图
第五章 软件项目任务分解
- 任务分解是项目管理的基础
- 任务分解是将一个项目分解为更多的工作细目或者子项目 ，是项目变得更小、更易管理、更易操作。
-
一般来说，进行项目分解时，可以采用 清单或图表 两种形式来表达任务分解的结果。
-
当项目过于复杂是，可以对项目进行任务分解，这样做的好处是什么？答：将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、 更易操作， 这样可以提高估算成本、时间和资源的准确性，使工作变得更易操作，责任分工更加明确。
任务分解
| 任务分解过程 | 将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作 |
| 任务分解结果 | WBS（任务分解结构） |
WBS（任务分解结构）
- WBS是对项目由粗到细的分解过程，是分级的树型结构。
- WBS是面向交付成果的对项目元素的分组。
- WBS组织并定义了整个项目范围。
- WBS的最低层次的可交付成果，是wbs的最小元素（工作包）。
- 工作包（最底层）应当由唯一主体负责。
- WBS提供了项目范围基线
WBS分解形式
清单形式
图表形式
任务分解方法
| 模板参照 | 标准或半标准的WBS作为模板参考使用 |
| 类比 | WBS经常被“重复使用”，有些项目在某种程度上具有相似性
|
| 自顶向下 | 从一般到特殊、要求对项目十分了解 |
| 自底向上 | 特殊到一般 探索型的项目 |
任务分解的基本步骤
- 确认并分解项目的组成要素(WBS编号)
- 确定分解标准（分解的标准要统一）
- 确定分解是否详细 （是否可以作为费用和时间估计的标准）
- 确定项目交付成果（可以编制WBS字典） （WBS的具体工作阐述，包括对工作包的阐述，明确WBS组件是什么）
- 验证分解的正确性
检验分解结果的标准
- 最底层的要素是否是实现目标的充分必要条件
- 最底层要素是否有重复的
- 每个要素是否清晰完整定义
- 最底层要素是否有定义清晰的责任人
- 是否可以进行成本估算和进度安排
WBS任务分解建议
- 最低层是可控的和可管理的，但是不必要的过细
- 每个Work package（工作包）必须有一个提交物
- 定义任务完成的标准
- 有利于责任分配
- 推荐任务分解到40小时以内
第八章 软件项目质量计划
软件质量是软件满足明确说明或者隐含的需求的程度
软件质量模型
| Boehm模型 | 软件质量三个方面：
分解为若干层次， 最底层的软件质量概念再引入数量化的指标
|
| McCall质量模型 | 影响质量的因素是用户使用时的3种倾向：
评价准则对反映质量特征的软件属性进行分级，以估计软件质量特征的值。 软件属性级别从0到10 |
| ISO/IEC9126模型 | “质量特征—质量子特征—度量因子”三层结构模型
|
软件质量管理过程
质量管理的对象
- 过程的质量
- 产品的质量
软件质量管理过程
| 软件质量计划 |
|
| 软件质量保证（QA） |
要点：
质量保证活动-审计（ Audit ）：
软件项目中常用的质量保证活动：
|
| 软件质量控制（QC） |
要点：
质量控制活动： 技术评审 代码走查 测试 返工 |
质量保证与质量控制的关系
- QC:前期质量活动(检验产品质量符合客户需求)
- QA:后期质量活动(审计产品和过程的质量，保证过程被正确执行)
| 质量保证（QA） |
|
| 质量控制（QC） |
|
软件质量计划
质量成本（CoQ）
质量成本是由于产品的第一次工作不正常而衍生的附加花费，包括两部分：
- 预防成本
- 缺陷成本
质量的形成
质量形成于产品或者服务的开发过程中，而不是事后的检查（测试）把关等。
质量计划方法
| 1.试验设计 | 试验设计是一种统计学方法，确定哪些因素可能会对特定变量产生影响。 |
| 2.基准对照 | 是一种寻找最佳实践的方法，是利用其他项目的实施情况作为当前项目性能衡量的标准。 |
| 3.质量成本分析 | 质量成本的综合分析，以便决定质量活动。 |
| 4.流程图方法 | 可以显示系统的各种成分是相互的关系，帮助我们预测在何处可能发生何种质量问题. |
| 5.因果分析图 | 描述相关的各种原因和子原因如何产生潜在问题或影响，将影响质量问题的“人员、设备、参考资料、方法、环境”等各方面的原因进行细致的分解，方便地在质量计划中制定相应的预防措施。
|
扫一扫
291
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
