P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
D(Do ) — —软件开发。开发出满足规格说明的软件。
C(Check)——软件确认。确认开发的软件能够满足用户的需求。
A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。
生命周期：经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰的全过程
1、软件过程模型
1、瀑布模型
因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。
2、原型化模型
又称快速原型。分为原型开发阶段、目标软件开发阶段。
抛弃型原型：在需求确认结束后，原型就被抛弃不用，重新采用一个完整的瀑布模型进行开发
演化性原型：不断补充和完善原型
3、螺旋模型
在快速原型的基础上扩展，引入风险分析
过程：目标设定、风险分析、开发和有效性验证、评审
4、敏捷模型
适应性、以人为本、迭代增量式的轻量级的开发过程
极限编程XP：费用严格控制
水晶系列方法：最少纪律性约束
开放式源码：程序员地域分布广泛
ASD:三个非线性、重叠的开发阶段。猜测，合作，学习
Scrum：侧重于项目管理、迭代式增量、可重复的方法过程
特征驱动开发方法FDD：
1）要素：人、过程和技术
2）角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家
3）过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建
5、软件统一过程RUP
描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程
1、用例驱动：需求分析、设计、实现和测试等活动都是用例驱动的。
2、以体系结构为中心：与代码设计无关，包括系统的总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配功能、设计元素的组织、物理分布、系统的伸缩性和性能等。
在功能性特征方面要考虑系统的功能；
在非功能性特征方面要考虑系统的性能、安全性和可用性等；
与软件开发有关的特征要考虑可修改性、可移植性、可重用性、可集成性和可测试性等；
与开发经济学有关的特征要考虑开发时间、费用、系统的生命期等。
3、迭代和增量：
(1)在软件开发的早期就可以对关键的、影响大的风险进行处理。
(2)可以提出一个软件体系结构来指导开发。
(3)可以更好地处理不可避免的需求变更。
(4)可以较早得到一个可运行的系统，鼓舞发团队的士气，增强项目成功的信心。
(5)为开发人员提供一个能更有效工作的开发过程。
核心流程：
● 业务建模： 理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
● 需求： 定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
● 分析与设计：把需求分析的结果转化为分析与设计模型。
● 实现： 把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
● 测试： 检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
● 部署：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
● 配置与变更管理 ：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
● 项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
● 环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
软件开发生命周期
● 初始 (inception) 阶段：定义最终产品视图和业务模型，并确定系统范围。
● 细化 (elaboration) 阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
● 构造 (construction) 阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
● 移交 (transition) 阶段：把产品提交给用户使用。
架构与UML的 4+1视图
2、需求工程
1、三个层次
业务需求：反映了组织机构或客户对系统、产品高层次的目标要求。
用户需求：描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望。这两种构成了用户原始需求文档的内容。
功能需求：定义了开发人员必须实现的软件功能
2、需求开发
1）需求获取
通过与用户的交流，对现有系统的观察及对任务进行分析
获取的方法：用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法、头脑风暴法
2）需求分析
为系统建立一个概念模型，作为对需求的抽象描述
功能模型：DFD（数据流、加工、数据存储、外部实体）
行为模型：状态转化图 （状态、事件）
数据模型：E-R图（实体、关系）
3）需求定义
形成需求规格说明书SRS、文档化
4）需求确认与验证
通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法。包含有效性检查、一致性检查、可行性检查和确认可验证性。
3、需求管理
包括需求文档的追踪管理、变更控制、版本控制等管理性活动。
变更控制过程
变更控制委员会CCB
项目所有者权益代表，负责裁定接受哪些变更。通常包括用户和实施方的决策人员
1、制定决策
2、交流情况
3、重新协商约定
需求跟踪
元素包括其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等
(1)正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
(2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
4、需求抽取
通常为一个迭代过程，其中的活动包括需求发现、需求分类和组织、需求协商、需求文档化。
1．访谈，开发者和其他人谈论他们做的事情。
2．观察或人种学调查，观察人们做自己的工作来了解他们使用哪些制品、他们如何使用这些制品
3、系统分析与设计
1、结构化方法
面向功能或面向数据流的软件开发方法
1）结构化分析 (SA)
数据流图DFD、数据字典、结构化语言、判定表、判定树
DFD组成项：
(1)数据流 (Data Flow)。 数据流用一个箭头描述数据的流向，箭头上标注的内容可以是
信息说明或数据项。
(2)处理 (Process)。 表示对数据进行的加工和转换，在图中用矩形框表示。指向处理的
数据流为该处理的输入数据，离开处理的数据流为该处理的输出数据。
(3)数据存储。表示用数据库形式(或者文件形式)存储的数据，对其进行的存取分别以
指向或离开数据存储的箭头表示。
(4)外部项。也称为数据源或者数据终点。描述系统数据的提供者或者数据的使用者，如
教师、学生、采购员、某个组织或部门或其他系统，在图中用圆角框或者平行四边形框表示。
DFD建模过程
顶层被逐渐细化、层次结构、上一层是下一层的抽象
(1)明确目标，确定系统范围。
(2)建立顶层D F D图。
(3)构建第一层D F D分解图。
(4)开发D F D层次结构图。
(5)检查确认D F D图。
2）结构化设计 (SD)
面向数据流的设计方法，以SRS和SA阶段所产生的数据流图和数据字典为文档基础，是一个自顶向下、逐步求精和模块化的过程。
1）概要设计【外部设计】：主要任务是确定软件系统的结构，对系统进行模块拆分，确定每个模块的功能、接口和模块之间的调用关系，形成模块结构图；
2）详细设计【内部设计】：为每个模块设计实现的细节。
设计原则：
1、模块独立性（高内聚、低耦合）
2、保持模块大小适中
3、多扇入、少扇出
4、深度(调用层次)和宽度(一个模块调用其他模块个数)均不宜过高
模块四要素：
输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那儿取得输入，进行加工后再把输出返回调用者。
处理功能：指模块把输入转换成输出所做的工作。
内部数据：指仅供该模块本身引用的数据。
程序代码：指用来实现模块功能的程序。
最高：功能内聚
最低：非直接耦合、数据耦合
3）结构化编程 (SP)
各个模块通过“顺序、选择、循环”的控制结构进行连接，并且只有一个入口和一个出口。
程序=(算法)+(数据结构)
2、面向对象方法
适用敏捷开发模型
1.面向对象分析OOA
五个层次：主题层、对象类层、结构层、属性层和服务层
五个活动：标识对象类、标识结构、定义主题、定义属性和定义服务
2.面向对象设计OOD
类的分类
实体类：需要存储在永久存储体中的信息，对标数据库ORM
控制类：控制用例工作的类，具备动作、业务逻辑。身份证验证器
边界类：封装在用例内、外流动的信息或数据流。包括所有二维码、通信协议、窗体、报表、打印机和扫描仪等硬件的对外接口
设计过程：
包图如下：
设计原则：
3.面向对象编程OOP
封装、继承和多态
4、软件测试
静态测试：被测程序不运行，只依靠分析或检查源程序的语句、结构、过程等检查程序是否有误。
动态测试：运行被测试程序
黑盒测试：在不考虑任何程序内部结构和特性的条件下，根据需求规格说明书设计测试实例
白盒测试：借助程序内部逻辑和相关信息，通过检测内部动作是否按照设计规格说明书的设定进行
覆盖程度由低到高：语句覆盖、判定覆盖、分支覆盖和路径覆盖
单元测试：软件模块，编码测试。先通过静态测试，再进行白盒测试
集成测试：
系统测试：
功能测试、性能测试、压力测试
验收测试：交付客户测试使用，Alpha测试（开发环境）或Beta测试（生产环境）
回归测试：需求变更后，进行验证
自动化测试：
1）线性脚本：录制手工测试用例
2）结构化脚本：内容结构化
3）共享脚本：一个脚本可以被多个程序共享
4）数据驱动脚本：测试输入存储在独立的数据文件中
5、净室软件工程
一种应用数学与统计学理论、力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷
要求在规约和设计中消除错误、形式化、建立数学模型、验证而不是测试
技术手段：
1）统计过程控制下的增量式开发：控制迭代
2）基于函数的规范与设计：盒子结构
三种抽象层次：行为视图（黑盒）、有限状态机视图（状态盒）和过程视图（明盒）
3）正确性验证：净室工程核心
4）统计测试和软件认证：统计学，样本大的抽样方法
缺陷：太理论化、开发小组不进行传统的模块测试、脱胎于传统软件工程
6、逆向工程
实现级：包括程序的抽象语法树、符号表、过程的设计表示
结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构
功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型
领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型
7、基于构件的软件工程CBSE
购买而不是重新构造
从程序编写转移到了基于已有构件的组装
特征：
(1)可组装型：所有外部交互必须通过公开定义的接口进行
(2)可部署性：构件总是二进制形式，作为一个独立实体运行
(3)文档化：用户根据文档来判断构件是否满足需求
(4)独立性：在无其他特殊构件的情况下进行组装和部署
(5)标准化：使用的构件必须符合某种标准化的构件模型
组装方式：
1.顺序组装：通过按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件
2.层次组装：被调用构件的“提供”接口必须和调用构件的“请求”接口兼容
3.叠加组装：在两个或两个以上构件放在一起来创建一个新构件，提供新接口
8、软件项目管理
软件进度管理过程：
活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和进度控制。
1、工作分解结构WBS
项目→任务→工作→日常活动
最底层的被称为工作包，是最低层次的可交付成果，它应当由唯一主体负责完成。
(1)WBS 的工作包是可控和可管理的，不能过于复杂。
(2)任务分解也不能过细，一般原则W B S的树形结构不超过6层。
(3)每个工作包要有一个交付成果。
(4)每个任务必须有明确定义的完成标准。
(5)WBS 必须有利于责任分配。
2、任务活动图
每个活动的前驱、持续时间、必须完成日期、里程碑或交付成果
3、软件配置管理
核心内容：
1）版本控制
对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理
2）变更控制
便跟来源：
一是自外部的变更要求，如客户要求修改工作范围和需求等；
二是开发过程内部的变更要求，如为解决测试中发现问题。
4、软件质量保证SQA
SQA审计与评审、报告、处理不符合问题
5、软件能力成熟度模型CMMI
初始级：随意且混乱，依赖于组织内人员的能力与英雄主义
已管理级：建立明确的目标，并能实现成本、进度和质量目标等
已定义级：适合自己企业和项目的标准流程
量化管理级：建立了产品质量、服务质量以及过程性能的定量目标
优化级：通过增量式的与创新式的过程与技术改进，不断地改进过程性能
层次结构：顶层方针、过程文件、规程文件、模板类文件
标签：需求,测试,基础知识,开发,软件工程,模块,设计,架构师,软件 From： https://blog.csdn.net/xcg340123/article/details/136809038