前言
大学老师说：软件工程是个很重要的课
以程序员的我，表示并没有什么卵用。直到有一天，我明白了原来软件工程讲的是让我怎么开展一件事情。
软件工程
| 软件工程 | 事件 | 产物 |
|---|---|---|
| 问题的定义 | 对系统的实际用户和使用部门负责人的访问调查 | 提出关于问题性质、工程目标和规模的书面报告 |
| 可行性分析 | 从技术，经济，操作，法律方面分析上述问题 | 可行性分析报告 |
| 需求分析 | 确定目标系统必须具备哪些功能 | 产品原型图PRD |
| 总体设计 | 根据功能分解模块，层级 | 系统架构（模块）图 |
| 详情设计 | 确定模块，层级功能的算法和数据结构 | 用例图，E-R图，顺序图 & 测试用例 |
| 编码 | 针对详情设计内码编写代码 | 代码及单元测试 |
| 测试 | 根据测试要求提供测试 | 测试&交付报告 |
| 维护 | 通过各种必要的维护活动使系统持久地满足用户的需要 | 系统正常运行 |
问题定义
- 主处理人：产品经理
- 问题的来源：
- 老板要求的市场调研
- 客户反馈的市场需求
- 竞争产品上的功能的市场调研
- 对应会议： 无
可行性分析
- 主处理人：产品经理
- 分析过程：
- 技术咨询并成本估算
- 法律咨询
- 其它咨询
- 对应会议： 立项会
- 会议目的：
- 大致说明产品功能及价值
- 解决大家相关疑问，确立项目
需求分析
- 主处理人：产品经理
- 分析过程：
- 根据各功能点，完成PRD
- 对应会议： 需求评审会
- 会议目的：详细说明PRD中产品功能，价值以及产品的性能要求，并解决大家的疑问。
总体设计 & 详情设计
- 主处理人：技术经理（架构师），开发人员
- 设计过程：
- 根据功能划分模块。系统架构（模块）图
- 确定各模块内的数据结构与算法。用例图，ER图，顺序图
- 对应会议： 架构评审会
- 会议目的：介绍自己的设计，通过此设计是否可满足产品需求
编码
- 主处理人：开发人员
- 编码过程：根据设计编写代码，及单元测试，代码review
- 主处理人：测试人员
- 设计过程：
- 根据PRD,编写测试用例
- 根据架构及详情设计，确立产品性能测试方案
- 对应会议： 测试用例评审会
- 会议目的：介绍自己的测试范围及测试方法，通过些方法是否可满足用户使用需求
测试
- 主处理人：测试人员
- 测试过程：根据测试用例及性能测试方案进行测试
- 主处理人：开发人员，测试人员
- 设计过程：
- 根据设计方案，制定发布计划。
- 确定回滚方案
- 对应会议： 发布计划会
- 会议目的：针对发布计划，回滚方案进行评审，接纳各方意见，保证发布顺利进行。
维护
- 主处理人：开发人员，测试人员，产品经理
- 维护过程：
- 开发人员查看报警日志
- 产品经理跟踪用户反馈
- 测试人员复现线上问题
- 对应会议： 无
开发模式
针对软件工程的生命周期，不同公司针对自身情况做了不同的调整
瀑布模型
瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。
它的严格分级导致的自由度降低，需求调整代价高昂。需求不明并且在项目进行过程中可能变化的情况下基本是不可行的
迭代式开发
每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发。
- 整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。
- 每一次迭代都包括了需求分析、设计、实现与测试。
采用这种方法，开发工作可以在需求被完整地确定之前启动， 并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。 再通过客户的反馈来细化需求，并开始新一轮的迭代
螺旋开发
（略）
敏捷开发
（略）
总结
明确自己所在的位置，明确自己所做的事情后。也就不迷茫了。不要再怪会议多了。