系统开发基础
软件工程
软件工程是一门研究和应用如何以系统化、规范化、可量化的方法开发和维护软件的学科。它涉及到软件开发的全过程，包括需求分析、设计、编码、测试、部署和维护等阶段。
基本概念
软件工程的目标:
最大限度地提高软件的质量、可靠性、可维护性和可重用性，并控制软件开发的成本、进度和风险
软件需求工程:
软件系统所需功能和性能的详细描述
软件设计:
指根据软件需求，对软件系统进行结构和逻辑的设计
软件开发:
根据软件设计，编写和测试软件代码的过程
软件测试:
对软件系统进行验证和验证的过程，以确保软件系统满足预期的功能和性能要求
软件维护:
对已经发布的软件系统进行修复bug、增强功能和适应新环境的过程
软件项目管理:
对软件开发项目的组织、协调和控制等活动
信息系统的基本生存周期
可行性分析 → 需求分析 → 概要设计 → 详细设计 → 编码 → 测试 → 维护
软件过程模型
是指开发软件的过程中所采用的一种规范化方法或框架。常见的软件工程过程模型包括瀑布模型、迭代开发模型、喷泉模型敏捷开发模型等
1.瀑布模型
瀑布模型(WaterfallModel)是软件开发生命周期(SDLC)中的一种经典开发模型。它是一种顺序性的开发模型，由上往下依次进行，各个阶段依赖于前一阶段的结果。
阶段划分:可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码、测试、运行维护
适用场景:以文档作为驱动、适合于软件需求很明确的软件项目的模型、适用较小规模项目
优点:
①明确的项目计划和清晰的开发流程
②开发过程中轻松追踪和控制进度
缺点:
①由于各个阶段的依赖关系，需求变更较大时，会导致整个项目的延迟
②测试阶段在开发结束后才进行，可能导致问题的发现和修复较晚
③客户参与程度较低，可能导致最终产品与客户需求有较大差距
解题关键词:
依赖前一阶段
较小规模
文档驱动
需求明确
修复问题晚
用户参与低
需求变化会延期
2.V模型
V模型是瀑布模型的一种变种，它将瀑布模型的开发过程与质量保证过程相互关联，以确保产品的质量和符
合用户需求。
适用场景:需求明确和需求变更不频繁的情形
特点:
①开发过程和测试过程是相互平行的，如同字母“V”一样
②强调测试在整个开发过程中的重要性，将测试过程纳入开发过程中
③能够提供一个明确的开发和测试过程的框架
解题关键词
瀑布模型变体
需求变更不频繁
测试与开发结合
3.演化模型
演化模型(Evolutionary Model)该模型可以表示为:第一次迭代(需求-设计-实现-测试-集成)-反馈-第二次迭代(需求-设计-实现-测试-集成)-反馈-……即根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型，这是一种迭代的过程模型，使软件逐步演化出更完整的软件版本。
适用场景:对软件需求缺乏准确认知的情况
4.原型模型
创建一个快速原型，以便项目干系人与未来用户之间可以通过原型进行交互，从而更好地了解需求和反馈。在基于原型的基础上，进行开发过程，以确保最终交付的产品能够满足用户的期望和需求
适用场景:需求不明确和经常变化的项目
特点:
- 实际可行。
- 具有最终系统的基本特征
- 构造方便、快速，造价低。
- 它对用户需求是动态的、逐步纳入的。
解题关键词
原型方法
经常变化
需求不明确
5.增量模型
也称为增量开发。它是一种迭代式的开发方法，将软件系统划分成多个增量，每个增量分别开发、测试和部署，然后按顺序进行整合，每个增量都是一个完整的软件系统的一部分，具有一定的功能和价值。
适用场景:需求变化频繁、开发周期较长、车需要快速交付、项目规模大，需要不断迭代和更新的项目，
特点:
①把瀑布模型的顺序特征与快速原型法的迭代特征相结合
②把整个软件产品分解成许多个增量构件，分批地逐步向用户提交产品
③必须遵守的约束条件是，当把新增量集成到现有系统中时，所形成的产品必须是可测试的
优点:
①提高反馈效率，每个增量都可以及时交付给用户使用，用户提供反馈和指导，有助于及时纠正和改进
②降低风险，因每个增量是独立的，开发过程中的问题不会对整个系统造成重大影响。
③提高可维护性，每个增量都有独立的设计和文档，方便后续的维护和升级操作
缺点:
①由于需要迭代开发和多次测试，增量模型需要额外的成本和时间来进行
②需要用户的积极参与，增量模型需要用户的积极参与，包括对每个增量的评估和反馈，对某些项目来说可能用户的参与程度较低。
解题关键词
第一个增量是核心
分批
增量
开发周期长
用户参度低
需求频变
规模大
6.螺旋模型
软件开发过程被表示为一个螺旋形状的曲线，其沿着时间和成本两个维度进行演化，通过不断进行风险分析和迭代来逐步开发和改进软件系统，螺旋模型将瀑布模型和演化模型结合起来，强调了风险分析。
适用场景:大型、复杂度高、风险高的系统
优点:
①风险驱动的方法体系。
②每个阶段之前及经常发生的循环签，必须进行风险评估
缺点:
①需要具备丰富的风险评估经验和专门知识
②在风险较大的项目中，如果未能及时识别风险，会造成重大损失②常用于大型和复杂的项目，对于小型项目可能过于繁琐
解题关键词
大型、复杂、有风险
螺旋
风险分析和迭代
7.喷泉模型
将用户需求作为主要动力，并以对象为驱动。它适用于面向对象的开发方法，并且具有迭代性和无间隙性整个开发过程被视为一个喷泉，代表了用户需求的源泉，开发团队通过不断迭代和改进，将用户需求转化为最终的软件产品.
适用场景:面向对象的开发方法，迭代无间隙。
优点
①能够及时响应用户需求的变化，保持开发过程的灵活性和敏捷性
②与传统的瀑布模型相比适合快速迭代和开发周期短的项目
缺点
①由于没有明确的阶段划分，开发团队可能会在需求分析和设计阶段出现混乱
②对开发团队的能力和协作要求较高，需要具备良好的沟通和协调能力
解题关键词
面向对象
复用好
无间隙
7.统一过程(UP)模型
统一过程(UP)模型是一种软件开发过程，以用例和风险为驱动，以架构为中心，采用迭代和增量的方法4个阶段初始阶段、细化阶段、构建阶段、交付阶段。
适用场景:适用于大规模、复杂、要求高质量的软件开发项目。
优点:
①迭代和增量开发
②以用例和风险为驱动，以架构为中心
③使用UML(统一建模语言)方法和工具来支持开发过程
解题关键词
以用例和风险为驱动
架构为中心
迭代和增量
8.敏捷开发方法
极限编程XP:4大价值观、5个原则、12个最佳实践
水晶法:以人为本，每个不同项目都需要有一套不同的策略、约定和方法论
开发式源码:程序开发人员在地域上分布很广
并列争球法(Scrum):每30天依次的迭代为一个“冲刺”
功能驱动开发FDD:首席程序员和“类”程序员
自适应软件开发ASD:三个非线性开发阶段:猜测、合作与学习
系统设计
系统设计-概念
指在需求分析的基础上，对软件系统进行整体架构和各个模块的设计。系统设计的目标是将需求转化为具体的实现方案，明确软件的结构和功能，并考虑系统的可维护性、可扩展性、可重用性等方面的要求。
系统设计-概要设计
概要设计是将需求分析的结果转化为软件系统的高层结构和模块化设计的过程，输出概要设计说明书
系统总体结构设计:确定系统的整体架构，包括各个模块之间的关系、层次结构、数据流向等。
数据设计:确定数据库的表结构、字段类型、关系(E-R)、逻辑结构等，并设计数据访问接口
接口设计:明确各个接口的功能、参数、调用方式等，以确保接口的通用性、稳定性和易用性。
系统安全性设计:分析系统可能面临的安全威胁，并设计相应的安全策略
系统性能设计:考虑系统的响应时间、吞吐量、并发用户数等性能指标，并设计相应的优化策略
系统设计-详细设计
根据概要设计所做的模块划分，为每个模块设计实现算法和所需的局部结构，输出详细设计说明书
确定模块算法:为软件结构图中的每个模块确定具体的算法模块
数据结构设计:每个模块确定所需的局部数据结构，如:数组、链表、树等来存储和处理数据
对数据库进行物理设计:将E-R图转为多张表，进行物理设计，使用数据库三大范式进行审核。
测试用例:为每个模块设计一组测试用例，以便在编码阶段对模块代码进行预定的测试同时还进行代码设计、车输入/输出设计、用户界面设计等其他设计
同时还进行代码设计、输入/输出设计、用户界面设计等其他设计。
内聚性和耦合性
内聚性
内聚性表示一个模块内部各个元素(数据、处理)之间联系的紧密程度。块内联系愈紧,即内聚性愈高，模块独立性愈好，好的内聚是功能内聚即一个模块只做一件事。
内聚类型 描述
功能内聚 完成单一功能，各部分协同工作，缺一不可
顺序内聚 处理元素相关，且顺序执行
通信内聚 所有处理元素集中在一个数据结构的区域上
过程内聚 处理元素相关，必须按特定的次序执行
瞬时内聚 任务必须在同一时间间隔内执行
逻辑内聚 完成逻辑上相关的一组任务
偶然内聚 完成一组没有关系或松散关系的任务
| 内聚类型 | 描述 |
|---|---|
| 功能内聚 | 完成单一功能，各部分协同工作，缺一不可 |
| 顺序内聚 | 处理元素相关，且顺序执行 |
| 通信内聚 | 所有处理元素集中在一个数据结构的区域上 |
| 过程内聚 | 处理元素相关，必须按特定的次序执行 |
| 瞬时内聚 | 任务必须在同一时间间隔内执行 |
| 逻辑内聚 | 完成逻辑上相关的一组任务 |
| 偶然内聚 | 完成一组没有关系或松散关系的任务 |
 |
耦合性
软件模块之间的依赖程度，，一般可分为紧密耦合、松散耦合和无耦合，在常规的软件设计中一般应用松散耦合
| 耦合类型 | 描 述 |
|---|---|
| 非直接耦合 | 两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的 |
| 数据耦合 | 一组模块借助参数表传递简单数据 |
| 标记耦合 | 组模块通过参数表传递记录信息(数据结构) |
| 控制耦合 | 模块之间传递的信息中包含用于控制模块内部逻辑的信息 |
| 外部耦合 | 组模块都访问同一全局简单变量，而且不是通过参数表传递该全局变量的信息 |
| 公共耦合 | 多个模块都访问同一个公共数据环境 |
| 内容耦合 | 模块直接访问另一个模块的内部数据，一个模块不通过正常入口转到另一个模块的内部，两个模块有一部分程序代码重叠;一个块有多个入口 |
高内聚、低耦合
高内聚低耦合，是面向对象设计中的重要原则，判断设计好坏的标准，主要看类的内聚性是否高，耦合度是否低。目的是使得模块的可重用性、移植性大大增强。
黑盒测试
黑盒测试也是功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据和输出数据。
软件测试
软件测试是对软件系统进行验证和验证的过程。它旨在确保软件满足预先确定的需求和规范，并且能够按照预期的方式运行。软件测试的主要目的是发现软件中的错误、缺陷和问题，并提供修复和改进的机会。重点掌握:黑盒测试、白盒测试。
测试用例
测试用例是一组条件，测试人员根据这些条件确定软件应用程序是否按照客户的要求工作，测试用例设计包括前提条件，用例名称，输入条件和预期结果。
等价类划分:
把程序的 输入域 划分为若干部分，然后从每个部分中选取少数代表性数据当作测试用例。
边界值分析:
边界值分析法就是对输入或输出的边界值进行测试。
白盒测试
白盒测试又称为 结构测试或基于代码的测试，关注测试对象的内部逻辑和结构，目的是验证软件的内部逻辑是否正确，并且最大限度地覆盖测试对象的代码路径，
语句覆盖:被测试中每条语句至少执行一次。
判定覆盖:被测试的每个判定至少获得“真”“假”值各一次
条件覆盖:每一个判定语句中每个逻辑条件的各种可能值至少满足一次。
判定/条件覆盖:判定中每个条件的所有可能取值，至少出现一次，并使每个判定本身的判定结果也至少出现一次
组合覆盖:每个判定的所有可能的条件取值组合 都至少出现一次
路径覆盖:覆盖被测试程序中所有可能的路径
软件维护
是指对已经开发完成的软件系统进行修改、优化和修复工作。维护工作的质量直接影响到软件系统的稳定性、可靠性和可用性。维护期通常比开发期更长、更复杂、投入也更大。
纠正性维护:指修复软件系统中的错误和缺陷，确保软件系统的正常运行。
适应性维护:指根据外部环境和需求的变化，对软件系统进行修改和扩展。
完善性维护:指对软件系统的性能、可用性和用户体验进行改进和优化。
预防性维护:指对软件系统进行预防性的检查和调整，以保证系统的稳定性和可靠性
就-纠正性
是-适应性
鱼-预防性
丸-完善性
软件质量和度量
软件质量是指软件在满足用户需求的同时，具备一定的可靠性、可维护性、可测试性等特性，而软件度量是指通过对软件产物进行度量，来评估和衡量软件质量的一种方法。
质量
功能性:软件能否满足用户需求;
可靠性:软件在给定环境下的稳定性和可靠性
易维护性:软件是否容易进行修改和扩展，
可测试性:软件是否易于进行测试;
可移植性:软件是否可以在不同环境中运行
度量
功能点分析:通过对软件的功能进行统计，来评估软件规模和复杂度
代码行数度量:通过对软件代码行数进行统计，来评估软件大小和复杂度
缺陷密度度量:通过对软件缺陷的数量和严重程度进行统计，来评估软件的质量
可靠性度量:通过对软件的故障率和可用性进行统计，来评估软件的可靠性
ISO/IEC 9126
ISO/IEC9126(1991年发布)是一个软件质量的评估标准，包含了质量模型的六大特性和27个子特性后来被最新的软件质量标准ISO/IEC25010:2011(2011年发布)取代。
McCabe 环路复杂度
McCabe复杂性度量又称环路度量。它认为程序的复杂性很大程度上取决于程序图的复杂性。单一的顺序结构最为简单，循环和选择所构成的环路越多，程序就越复杂，
在程序控制流程图中，节点是程序中代码的最小单元，边代表节点间的程序流。流图G的环形复杂度V(G)=E-N+2，其中，E是流图中边的条数，N是结点数。
需求分析
需求分析是软件开发过程中的重要环节之一，它主要是通过收集、分析和规范用户的需求，为软件开发团队提供明确的需求指导(解决做什么的问题)，确保软件开发的目标和方向与用户需求一致。包括:需求收集、需求分析、需求验证、需求管理等主要步骤。
需求来源:
①可以来自于用户、应用领域的专家、相关的技术标准和法规。
②可以来自于原有的系统、原有系统的用户、新系统的潜在用户
③来自于竞争对手的产品。
需求分类及方法
| 需求分类 | 描述 |
|---|---|
| 业务需求 | 反映企业或客户对系统高层级的目标要求(高层级需求) |
| 用户需求 | 描述用户的具体目标，用户想要什么，以及要这些做什么(用户需求) |
| 系统需求 | 从系统的角度说明软件的需求，包括功能需求、非功能需求、设计约束等 |
| 功能需求 | 系统必须完成的那些事，即为了向其用户提供有用的功能，产品必须执行的动作 |
| 非功能需 | 产品必须具备的性能或品质，例如，可靠性、容错性等 |
| 设计约束 | 也称为限制条件、补充规约、通常是对解决方案的一些约束说明，例如，某系统必须采用国有自主知识版权的数据库，必须运行在UNIX系统之下，等等 |
需求分析方法:面向数据流的结构化分析方法(SA)、面相对象的分析方法(OOA)
需求分析的工具:数据流图、数据字典、判定表、判定树。
需求分析的产物:需求规格说明书(SRS)。
软件需求规格说明书(SRS)
需求规格说明书(SRS)是需求分析任务的最终产物，它通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明，以及合适的验收标准，来提供对目标软件的各种需求。
| 内容 | 描述 |
|---|---|
| 引言 | 描述软件目标，以计算机系统为背景进行阐述 |
| 信息描述 | 描述问题的详细说明、信息内容、信息流和信息结构 |
| 功能描述 | 为每个功能提供处理过程说明，描述设计约束和性能特征，使用图形表示软件的整体结构和与其他系统元的相互影响 |
| 行为描述 | 描述软件操作的外部事件和内部控制特征 |
| 校验标准 | 描述系统成功的测试标准，即哪些测试和结果表示系统已成功实现 |
| 参考书目 | 引用与软件相关的文档，包括其他软件工程文档、技术参考文献、厂商文献和标准 |
| 附录 | 包含补充信息、表格数据、算法描述、图表和其他资料等 |
面向数据流的结构化需求分析方法
结构化分析方法的特点是:自顶向下、逐步分解、分析的核心是数据字典，建立三种模型:数据模型功能模型、行为模型。
| 模型类型 | 描述 | 常用图示 |
|---|---|---|
| 数据模型 | 描述实体、属性和实体间的关系 | 实体关系(E-R)图 |
| 功能模型 | 描述数据在系统间的传递情况 | 数据流图(DFD) |
| 行为模型 | 描述系统状态和状态转换的事件，指出系统行为和执行的动作 | 状态转换图(STD) |
需求分析工具-数据字典
数据字典是为分析人员查找数据流图中有关名字的详细定义而服务的，因此也像普通字典一样，要把所有条目按一定的次序排列起来，以便查阅。数据字典有以下条目:数据项、数据结构、数据流、数据存储、加工。
① 数据项(Data ltem):最基本的数据组成单元。
② 数据结构(Data Structure):由一组相关数据项构成的集合或复合数据类型
③ 数据流(Data Flow):在系统内从一个加工到另一个加工传输的数据。
④ 数据存储(Data Store):也称为文件或数据库，是暂时或永久存放数据的地方⑤加工(Process/Transformation):对数据进行处理的动作或活动(做什么)，不需要给出加工细节
加工规格说明工具
加工规格说明工具有:结构化语言、判定表、判定树
软件过程改造
CMM
能力成熟度模型(Capability Maturity Model，简称CMM)是一种软件工程评估模型，用于评估和提高组织的软件开发和维护过程的成熟度。CMM是一个五阶段模型，每个阶段描述了组织的软件工程能力水平和过程成熟度
1.初始级:软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力
2.可重复级:建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功
3.已定义级:已将管理和工程活动两方面的软件过程文档化、标准化、并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁得标准软件过程来开发和维护软件
4.已管理级:收集对软件过程和产品质量得详细度量值，对软件过程和产品都由定量得理解和控制
5.优化级:过程得量化反馈和先进的新思想、新技术促使过程不断改进
CMMI
CMMl(Capability Maturity ModelIntegration For Software，软件能力成熟度模型集成)是在CMM的基础上发展而来的，是若干过程模型的综合和改进，不仅仅是软件，而是支持多个工程学科和领域的、系统的、一致的过程改进框架，共有5个级别，代表软件团队能力成熟度的5个等级，数字越大，成熟度越高高成熟度等级表示有比较强的软件综合开发能力
