系统工程，软件工程，UML建模，项目管理主旨的抽象于软件开发流程内。软件开发的方法集合。
一、需求分析
1.总体需求分析
2.各部分需求分析
概念模型：
系统抽象的最终目的：
5w2h:why ,人物，（时间，地点），事件，方法（how much）
用例图：从用户角度描述功能并制定各子系统的操作者
1.划分系统子系统或者包图
2.指定各子系统实现的操作者
3组成：
用例、事件流、异常流、前置条件、后置条件
系统的原理，性能，结构，了解并掌握（绘制结构框架图）
1）.明确大概事件流：大概的逻辑模型。.分类系统功能模块或者包图
2.）指定各功能模块实现的操作者
二、概要设计
1.面向对象
1）面向对象方法：
静态图：
类图：（类之间的联系：关联，依赖，聚合。类的内部结构：类的属性和操作。在系统的整个生命周期都有效），
对象图：（是类图的实例，不同于类的地方在于对象图显示类的多个对象实例而不是实际的类，对象有生命周期，只能在系统某一时间段存在），
包图：（由包或类组成，表示包与包之间的关系，用于描述系统的分层结构）
模块的4m1e的设计
模块的4m1e的5w1h的统计
2）明确事件流：大概的逻辑模型
3）明确时序图流程：
组织及其清单
组织：部门，组织团队，组织活动
活动清单：时序图(逻辑模型)
三、
行为图：物理模型：（行为实现）描述系统的动态模型和组成对象间的关系
活动图：描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并进 行活动，对系统的功能建模特别重要，强调对象间的控制流程。
状态图：有多个状态，其行为受外界环境影响，并发生改变的类画状态图 m与h。
描述类的对象所有可能的状态及时间发生时状态的转移条件。使用上不需为所有类画状态图，仅为那些有多个状态，其行为受外界环境影响并发生改变的类画状态图
交互图：（时序图）描述对象间的交互关系
顺序图：（强调时间和顺序）
合作图：强调上下级关系
实现图：
构件图（组件图） 描述代码部件的物理结构及各部件之间的依赖关系。可能是 一个资源代码部件，二进制部件或可执行部件，包含逻辑类或实现类的 有关信息。展现了一组组件的物理结构和组件之间的依赖关系。部件图有 助于分析和理解组件之间的相互影响程度。
配置图：定义系统中软硬件的物理体系结构。展现了运行处理节点以及其中的组 件的配置。部署图给出了系统的体系结构和静态实施视图。它与组件图相关，通常 一个节点包含一个或多个构建。
首先：描述需求
其次：根据需求建立系统 的静态模型，来构造系统的结构
再次：描述系统的行为
静态建模机制：1,2所建立的模型都是静态的，包括用例图，类图，兑现图，包图，组件图，配置图
动态建模机制：3.所建立的模型或者可执行时的时序状态或交互关系包括状态图，活动图，时序图(顺序图和合作图。)
系统：设备，测量，材料，人，环境 方法
万物皆对象始终逃不出系统的范围
业务流程即方法
业务需求分析始终逃不出5w2h的范围
业务需求分析始终逃不出5w2h的范围
程序优化分析始终逃不出ECRSI，PDCA的范围
用户界面层 业务逻辑层 数据访问层
一、软件项目开发流程
1.需求分析
目的：按照软件工程的要求，复述用户的需求，得到用户的认可。
先做需求分析。招标前需求分析。能不能中标很大一部分取决于需求分析。
业务规格书：
分类与方法：
需求分析->技术语言、归纳和整理（抽象出来）、
面向业务人员，用户化的需求文档。收集分析用户的需求
面向设计人员，专业化的需求文档。有逻辑性的需求分析
《需求规则说明书》
1）总体需求
2）各部分需求
3）组成：
用例、事件流、异常流、前置条件、后置条件
用例：能达到什么效果，5w2h。完成这些功能的操作者.概念模型
明确大概事件流：怎样一步一步的达到效果。横向的（不包括纵向的）。设计阶段确定发生的。必定会发生的。逻辑模型
异常流：设计阶段不能确定的。有可能会发生的。逻辑模型
前置条件：条件
后置条件：产品
分析阶段不考虑和具体设计有关的内容。不考虑如何实现。
简单的演示程序（demo）：在招标中的作用至关重要。
看不同的人，做出不同专业的演示程序。但是结果都是把用户的业务需求搞清楚。
2.概要设计
面向过程的主框架：事件流。关注细节
面向对象的主框架：对象的过程。
1）总体框架：
2）技术路线：（采用什么体系架构，采用什么样的基础产品：采用什么数据库。访问数据库采用什么方式，使用分布式的还是集成式系统？用什么语言来开发，工作在什么操作系统上。用不用什么中间键）。
访问量是多少，并发线程是多少。
2.1）体系架构 c/s，b/s，两层，三层。MVC
2.2）平台约束
2.3）绘制结构框架图 -模块
结构框架：分成什么大的模块。模块是干吗的。通过什么来交换数据。
写大的模块，大的框架。
做完模块开发时，基本上就做好了开发计划。
2.4）逻辑模型 （接口，接口实现，业务逻辑对象）
用户界面（接口，实现），业务逻辑（接口，实现），数据访问（接口，实现），业务逻辑对象（）
《概要设计说明书》 一般是架构师来做。
3)面向对象：
面向对象方法：
面向对象设计的首要任务就是找对象；然后描述对象的属性的改变，状态的改变（描述如何实现）。
明确事件流：大概的逻辑模型
描述事件流：依据时间的描述、依据数据的描述、两者并重
读取（行为）->文件（属性），形成->记录
事件->数据，事件->数据
主谓宾要齐全
理论：根据需求事件流中的名词和动词找对象。
需求和设计师是相关的。设计类的名字多数都是名词。设计函数都是动词或者动词组成的词组。名词，形容词设置成员变量。
成员变量来自某些前置条件。成员函数来自事件流的某一个环节
实践：
根据需求事件流中的事件找对象，事件由对象触发，责任分配，关注行为，接口驱动
根据需求事件流中的数据找对象，关注属性，模型驱动。
根据需求异常流中的事件找对象，关注异常，异常驱动。先设置异常，面向异常，先考虑异常的情况，然后再考虑正确的情况。
根据这三者结合找备选对象。
明确时序图流程：
需要哪些具体的功能和处理哪些具体的信息，这就达到了事件流的细化阶段。
通过时序图验证对象能否实现事件流。
用对象验证执行流程。
用执行流程验证对象。
开发时间：预定的时间+预定的时间*20%
3.详细设计
1）根据对象抽象类，形成类图
2）对类分配责任，即主要成员函数。细节问题，行为
3）通过时序图验证类的成员函数能否实现事件流
4）对类设计成员变量，成员变量来自前置条件，后置条件，方法中的临时变量。
5）对类分析设计成员函数的返回值、参数、函数名、访控属性（公有私有保护）
6）设计成员函数的过程：流程（活动图/状态图），异常
活动图状态图
7）其他细节：构造函数，析构函数，拷贝构造函数，操作符重载
8）通过继承和多态引入抽象。优化。降低模块之间的耦合。
9）套用设计模式。不要为了设计模式而用设计模式。很容易弄巧成拙。
会形成一份详细的设计文档。文档要尽可能详细。会发送给代码编写人员和测试人员。
功能性详细描述、类型、函数、各种条件、流程设计、关键算法、关键库的接口（提供哪些接口，这些接口是干吗的，怎么调用这些库）。
《详细设计说明书》
不要做蓝领。不要做codeing。
4.编写代码/设计用例
编写程序代码:
基本测试:（使用main函数调用一下函数实现，定义函数，定义类的。函数级别的），
单元测试:（模块级别的。写一个测试的简单的测试代码服务器端，。为了测试我们写的客户端代码。仅仅为了测试客户端写一个简单的服务端。仅仅为测试客户端只是写几个简单的函数，写死一个响应包。写一个模拟逻辑）
集成测试:（所有模块都做完了，做集成测试。在开发中把环境搭建起来。几个模块都写好了：文件访问，数据库访问。网络。界面。UI）。
只有在研发这边测不出什么明显bug时，才有可能提交给测试部门。
测试部门：考虑的是具体的功能和需求
5.测试验证/修改错误
测试用例：
白测试：语句级测试。
黑测试：
工具：测试用脚本，有测试用例。有测试软件。
测试方向：功能测试、性能测试、压力测试、健壮性测试，稳定性测试（烤机，连续运行一个月）。
《测试报告》
bug管理系统。
回归测试。
把所有的测试报告改到95%以上。再发布
如果能确定前面不出错，那么就能缩小确定出错的范围
6.产品发布/工程实施
发布：打包、必要的文档、工程实施、售后服务、技术支持。
技术支持：三层
第一层：网线什么的，安装，卸载等
第二层:数据库异常等
第三层：研发层的
7.项目总结：
瀑布式开发。
迭代开发，只能少量迭代而不能全部迭代，回到过去
SQA部：质量管理。
国内开发一般拼体力。往项目管理方面走：需要了解项目流程。
代码的高效性，健壮性，稳定性，安全性，
文件外部编写代码及其他：
基础设施及辅助工具
配置文件（辅助工具文件）
文件组织：
1.代码文件命名
1）（根据业务系统分）.h .cpp 文件名（声明，定义）类
2.）基础设施及辅助工具（main（）函数，（声明，定义）全局变量，（声明，定义）辅助工具函数）
2.脚本文件makefle
makefile文件编写：
#！ bin/bash #!告诉编译器用bash解释器来解释。
-I. 包含头文件
#用来解释
if cp $1 $2 > /dev/null表示第一个路径，$2表示第二个路径,将$1复制到$2,有多余的输出，就输出到空设备.if判断一个命令的返回值，fi表示结束
cat /dev/null > $1 将$1清空
exit 0 让脚本的进程返回码为0；
开发计划：
实现。编写代码/设计用例Debug
实现过程
测试验证，修改错误
风险评估
产品发布，工程实施
项目总结