【总结】项目管理（适用于软件工程）

（本文只是自己的学习总结，不一定正确，仅供参考）

项目管理基础（适用于软件工程）

项目基本概念

项目特点

项目是为创造独特的产品、服务或成果而进行的临时性工作。

愿景（Vision），说明“What to be”，即成为什么。

使命（Mission），说明“What to do”，即需要做哪些事情才能使愿景得以实现。

战略（Strategy），说明“How to
do”，即，如何做，也就是确定完成使命所采用的具体路线和方法。

目标（Aim），说明“How to
measure”，即，如何对使命完成的情况进行检查和度量。

运营，保证组织的“持续稳定”。

项目，则推动组织的“持续发展”。

项目分类

项目流程模型

瀑布模型

串行、流水线，顺序性、依赖性。文档驱动。

项目生命周期一般都是瀑布模型。

里程碑、阶段性文档评审。

不急于实现，多花时间做好前期规划设计，尽可能推迟编码和测试。

快速原型模型

先开发出一个简单的原型，基于原型与用户反复进行需求分析，然后拿到准确的需求正式开发。

解决难以分析需求的问题，适合需求模糊的中小型工程，先按照感觉开发一个简单原型，基于原型进行需求分析。

增量模型

把整个工程分解为多个小型增量模块，每个增量模块都具有可用功能点，分批次交付，最终要能够集成为一个整体。

螺旋模型

优先进行风险分析，使用原型等方法尽量降低风险，本质上是快速原型模型。风险驱动。

轮次迭代，每轮进行制定计划、风险分析、原型开发、客户评估的一整套流程，然后进行下一轮迭代。实现项目完成度的螺旋提升。

构建集成模型

软件模块重用，搭积木。

项目生命周期总览

墨菲定律

工作比设想的复杂

花费的时间比设想的多

所需的费用比设想的多

问题总是层出不穷

项目总体控制

控制

范围

应当在项目规划阶段确定范围（工程的目标、功能、规模，以及大致的实现架构），重点是需求分析和总体设计两部分，后期不应当大范围变动。否则项目将变得极不可控。

时间

人天或人月为单位。三大阶段：计划阶段、实施阶段、测试阶段。

成本

开发成本、运维成本；经济效益、社会效益。

质量

相关干系人

项目中，乙方为主导并进行决策，第三方中间辅助，甲方应当给乙方参考而不是决策，项目经理为中心，项目经理监控项目并及时听取项目组、领导、用户的意见和反馈，进行统筹规划。

1项目经理-全程参与

项目经理是所有相关干系人的最高权力和决策人，项目由项目经理统筹。

乙方是产品和服务提供和实施方，故应当以乙方项目经理为最高决策，甲方项目经理次之，第三方（若有）项目经理再次之。

2项目组-系统建设

3领导-全程参与

4用户-项目规划和测试验收

资源与连通性

所有系统的网络账号可用性

完备可靠的资源和数据

及时有效沟通

风险

风险描述三元组：风险、发生概率、发生后果。

风险的影响：成本、进度、性能。

应当提前准备风险防控预案。

意外事故风险

需求变更风险（范围）

项目延期风险（时间）

项目超支风险（成本）

项目质量风险（质量）

技术风险

遇到难以解决的技术问题。

监控

项目组监控

定期反馈与总结

里程碑与阶段性文档输出

领导监控

项目进度汇报

项目生命周期

1甲方项目提出

1.1问题定义（初步需求分析）

有哪些问题或者需求，问题的性质、问题的规模、解决问题的大致思路。

1.2可行性分析

是否值得解决？问题的必要性、重要性、紧迫性。

是否能够解决？

技术可行性；

经济可行性；

操作可行性；

法律可行性；

商业可行性。

2商务阶段

甲方——产品或服务需求购买方；乙方——产品或服务提供方。

·商务组转交给项目组

·项目组立项start

3项目规划阶段

（项目预处理）

大部分项目立项时候必然做不到明确定义，项目启动后必然还需要一段时间进行重新调研与调整

3.1需求分析what

用户对目标软件系统的期望——功能、性能、约束。

需求调研->需求分析->需求确认。

需求分析需要满足：

一致性。1.所有需求必须一致，各个需求之间不能互相矛盾；2.乙方理解的需求必须与甲方的需求意向一致。

完整性。需求必须完整，需求规则说明书应该包括甲方用户需要的每一个功能或性能。

可实现性。指定的需求必须能够用现有的软硬件基本上可以实现，并且也能在项目的时间、成本限制内可以按质按量完成。