（本文只是自己的学习总结，不一定正确，仅供参考）
文章目录
项目管理基础（适用于软件工程）
项目基本概念
项目特点
项目是为创造独特的产品、服务或成果而进行的临时性工作。
愿景（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.乙方理解的需求必须与甲方的需求意向一致。
完整性。需求必须完整，需求规则说明书应该包括甲方用户需要的每一个功能或性能。
可实现性。指定的需求必须能够用现有的软硬件基本上可以实现，并且也能在项目的时间、成本限制内可以按质按量完成。
有效性。必须证明需求是正确有效的，确实能解决用户面对的问题。
3.2总体设计how
数据模型（E-R图）
功能模型（数据流图）
行为模型（状态转换图）
先逻辑，后物理；由外向内，自顶向下，逐层细化。确认实际物理整体架构，确定软件技术框架，技术边界，建立物理架构模型。
数据设计——数据建模；
体系结构设计——模块以及各模块的关系，系统架构设计；
过程设计——模块内部设计。
3.3详细设计how
分解各个模块，详细设计物理架构模型，确定各个模块的软硬件平台、数据结构与算法。
4系统建设阶段
4.1实施与单元测试do-check
分模块实现和测试验证，模块完成后分阶段进行项目内部交付。
5测试上线阶段
5.1测试check
整个工程全部接近尾声，整体测试。
复审测试（需求分析、设计说明书、编码复审）。
功能测试、性能测试。
测试用例——为测试而专门设计的数据。
出现问题则解决问题，排错（debug）。
5.2上线done
试运行（上线测试）。
系统上线。
·项目组结项end
6持续支持阶段
6.1运维addition
运行，改正性维护、适应性维护、完善性维护、预防性维护。
X项目管理
项目经理全程管理项目计划、需求变更、问题清单
项目行为与输出
各阶段行为与输出
1甲方项目提出
1.1问题定义（初步需求分析）
——甲方行为：甲方内部提出问题，进行初步需求分析，领导拟定立项
1.2可行性分析
——甲方行为：甲方进行可行性分析，若可行则提交商务购买，并预先筹备项目组
——甲方输出：《可行性分析报告》
2商务阶段
——甲方行为：甲方根据初步需求招标
——乙方行为：乙方根据自身能力参与投标，中标
——双方行为：双方基于初步知晓项目内容、乙方能够满足甲方需求的认知建立合作，签合同
——双方输出：《商务合同》（双方商务签字）
·商务组转交给项目组
——双方行为：甲方乙方商务组转交相关资料到各自项目组，项目主导权转移到项目组
——双方输出：《商务与项目内部交接单》
·项目组立项
——双方行为：甲方乙方项目组会面，开项目启动会议；根据商务移交的信息，详细讨论项目的需求范围、甲方提供的资源、乙方实施规划，协调建立项目主计划；立项
——乙方输出：《乙方项目实施组织架构》《项目启动会PPT》
——甲方输出：《甲方项目实施组织架构》《资源清单》
——双方输出：《项目启动会会议纪要》（双方项目经理签字）《项目实施规范》《项目主计划书》
3项目规划阶段
（项目预处理）
——乙方行为：乙方再次调研项目情况，调研资源清单、IT环境是否满足，相关干系人是否明确，甲方项目组是否需要培训，风险是否可控，视情况输出《IT环境清单》《培训内容及计划》，调整《资源清单》《项目主计划书》
3.1需求分析
——乙方行为：乙方主动沟通甲方进行需求调研；乙方根据调研记录进行需求分析；乙方输出需求分析文档找甲方确认，若有问题则继续调研迭代
——甲方行为：甲方配合乙方进行需求调研，甲方领导对乙方的调研结果进行把关、确认
——乙方输出：《需求规格说明书》（甲方项目经理签字）
3.2总体设计
——乙方行为：乙方项目组主导进行项目整体设计，并把设计结果提交甲方项目经理确认
——甲方行为：甲方项目经理对乙方的设计结果进行把关、确认
——乙方输出：《总体设计说明书》（甲方项目经理签字）
3.3详细设计
——乙方行为：乙方项目组主导进行项目详细设计，并把设计结果提交甲方项目经理确认
——甲方行为：甲方项目经理对乙方的设计结果进行把关、确认
——乙方输出：《详细设计说明书》（甲方项目经理签字）
4系统建设阶段
4.1实施与单元测试
——乙方行为：乙方具体实施建设
——双方行为：适时召开会议，解决中间发生的问题，督促进度
——乙方输出：《开发说明书》
——双方输出：《某次会议纪要》
5测试上线阶段
5.1测试
——乙方行为：根据测试方案进行测试
——甲方行为：对测试结果进行把关、确认
——乙方输出：《测试方案》
——双方输出：《功能测试报告》（甲方项目经理签字）《性能测试报告》（甲方项目经理签字）
5.2上线
——乙方行为：主导试运行和上线切换操作，并及时解决过程中发生的问题
——甲方行为：配合乙方
——乙方输出：《用户操作手册》《运维操作手册》《试运行方案》《系统上线方案》
——双方输出：《试运行报告》（双方项目经理签字）《系统上线检查报告》（双方项目经理签字）《系统上线确认书》（双方项目经理签字）
·项目组结项
——双方行为：项目结项会议，确认验收结项
——乙方输出：《项目与运维内部交接单》《项目总结报告》
——双方输出：《项目验收报告》（双方项目经理签字）《项目验收单》（双方项目经理签字）《项目人天确认单》（双方项目经理签字）
6持续支持阶段
6.1运维
——乙方行为：对已上线系统持续提供服务
——甲方行为：对已上线的系统持续运维
X项目管理
——项目经理内部维护：《项目实施管理计划书》《需求变更单》《问题管理台账》《阶段性回顾》
图表
甘特图
用于项目管理、项目主计划，串行（可少许并发）流水线。
系统流程图
是描述系统物理模型的一种传统工具。它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
没有统一标准，画法很随意，尽量使用visio画图。
决策树
决策表
左上-条件：罗列决策条件。
右上-条件组合/状态：纵向是各种条件的组合（Y满足此行的条件，N不满足，-不参与判断）；横向是条件组合的个数。
左下-动作：罗列决策动作。
右下-动作选择/决策规则：判断在某种条件组合下是否执行决策动作以及执行哪个动作（√执行，空不执行）。
数据流图DFD
从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程.建立系统的功能模型。
顶点是各个实体（不同的实体用不同的形状表示），边是数据流。
矩形：起点和终点；
圆角矩形或圆形：处理过程；
开口矩形：数据存储；
箭头：数据流。
实体关系图ERD
当数据量很大并且数据间关系复杂时对于数据的分析就得用到它来刻画系统数据模型。
数据库建模专用图表，概念数据模型。
矩阵：对象；
圆角矩形或圆形：属性；
菱形：关系；
连接线：连接。
状态转换图（控制流图）STD
刻画系统响应外部事件的过程。为系统的行为建模。
数据字典
对数据流图各个数据内容的详细定义，数据内容、定义、使用特点、控制信息、分组信息。
数据库建模必用图表，逻辑数据模型。
UML（标准化多种图形建模）
包括：
结构型的图(Structure Diagram)
类图(Class Diagram)
对象图(Object Diagram)
构件图(Component Diagram)
部署图(Deployment Diagram)
包图(Package Diagram)
行为型的图(Behavior Diagram)
活动图(Activity Diagram)
状态机图(State Machine Diagram)
顺序图(Sequence Diagram)
通信图(Communication Diagram)
用例图(Use Case Diagram)
时序图(Timing Diagram)
软件工程基础
软件工程基本概念
软件定义
程序+数据+文档。
逻辑实体而非物理实体。
软件危机
1.对软件开发的成本和进度估计不准确，实际成本可能比估计成本高出一个数量级，进度拖慢几个月甚至几年。
2.用户对已完成的软件系统不满意。软件开发人员对用户的需求只有模糊的理解就匆忙开发。
3.可靠性差，bug多，不兼容。
4.难以维护。低可扩展性、难以适应新的硬件环境、难以改造旧版的错误、可读性差。
5.缺乏文档。
6.重复开发。
7.软件成本上升。
8.软件开发生产率提高慢，追不上硬件升级的速度。
软件工程的本质特征
1.主要适用于大型软件。
2.中心问题是控制复杂性。
3.软件经常变化。
4.开发效率非常重要。
5.多人协作。
6.软件必须有效地支持用户，符合用户需求、易用性。
7.要与软件的应用行业结合起来。
软件工程原则
抽象（数学建模，面向对象）
封装（黑箱，可重用）
局部性（高内聚，低耦合）
尽量降低控制耦合，把控制耦合转化为数据耦合；作用域不要超过控制域。
确定性（无歧义）
一致性（范式，标准化接口）
完备性（流程完备，文档齐全）
可验证性（易于测试评审）
软件工程方法学
结构化（面向过程）
程序=数据结构+算法。
加入顺序、分支、循环等结构。汇编语言是非结构化程序设计，C语言开始升级到结构化。
总分总，前到后，结构化，逻辑层次清晰。
面向对象OOP
程序=对象+消息。
粗略到详细，迭代之间没有本质区别，界限模糊。
软件工程的短板
【关键】项目管理
【关键】需求分析
只要需求明确了，技术不是问题。明确目标，明确特定软件的根本定义。
需求分析的方法可扩展到生活规划，奋斗目标分析。
软件测试
软件文档（参考国标）
软件工程总体设计
最优架构-总分总
顶层聚合（统一对外接口），中层分解（分模块），底层再聚合（底层组件重用）。
深度——层数；
宽度——模块最多的层的模块数。
软件工程评判指标
功能
功能是否完备
性能
性能是否优秀
时间效率
运行速度
空间效率
占用存储空间
并发
并发性能