软件及软件工程：

计算机软件指计算机系统中的程序、数据及其相关文档
程序：按照特定顺序组织的计算机数据和指令的集合。
数据：使程序能正常执行的数据结构
文档：为了便于理解程序所需的与开发、维护和使用有关的资料

生命周期模型

软件生命周期模型是指在软件开发过程中，按照一定的时间顺序和阶段性的划分，将软件开发过程分为不同的阶段，并规定各个阶段的任务和交付成果。这些阶段通常包括需求分析、设计、编码、测试、部署和维护等
软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级等阶段。那么如何将上述软件开发过程方法化呢？这就是过程模型。过程模型（Process Models）意图解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动（activities）有效地组织了起来。他们之间的线性（linear）、迭代（iterative）、演进（evolutionary）和平行（parallel）关系会产生不同的模型。常见的过程模型包括：瀑布模型、原型模型、增量模型、
软件开发常见模型（瀑布模型、V模型、W模型、敏捷开发模型） - qiaoli - 博客园

软件过程模型：

也称软件开发模型或软件生存周期模型
是软件生存周期中一系列有序的软件开发活动的流程，是软件开发全部活动的结构框架。
对一个软件的开发无论其大小，都需要选择一个合适的软件过程模型，主要根据软件的类型、规模，开发方法、开发环境等多种因素来确定。

瀑布模型
原型模型

结构化程序设计（Structured Programming）是一种软件开发方法，旨在通过清晰、简洁、易于理解的编码方式来提高软件的可读性、可维护性和可靠性。结构化程序设计通常采用顺序、选择和循环等基本控制结构，避免使用goto语句等不可控制的跳转语句，以便更好地理解和控制程序的执行流程。
结构化程序设计的主要特点包括：

模块化：将程序分解成多个相互独立的模块，每个模块具有清晰的输入和输出，便于维护和修改。
顺序结构：按照顺序执行程序的不同部分，避免使用不可控制的跳转语句。
选择结构：根据条件选择不同的执行路径，例如if-else语句、switch语句等。
循环结构：根据条件重复执行某些操作，例如while循环、for循环等。

结构化程序设计的优点是程序结构清晰，易于理解和维护，能够提高程序的可读性、可维护性和可靠性。同时，结构化程序设计还可以提高软件开发的效率和质量，减少开发成本和时间。
是“面向过程”方法的改进，结构上将软件系统划分为若干功能模块，各模块按要求单独编程，再由各模块连接，组合构成相应的软件系统。

潜在可交付的产品增量是什么
在敏捷开发中，潜在可交付的产品增量（Potentially Shippable Product Increment，PSPI）指的是在当前迭代周期结束时，团队完成的一个可用、可测试、可部署、可交付的软件产品版本。它是在迭代周期内完成的所有工作成果的集合，包括新功能、增强功能和修复问题等。PSPI是一个完整的、可用的、可交付的软件产品版本，可以交付给客户或者用于生产环境。
潜在可交付的产品增量是敏捷开发中的一个重要概念，它强调了团队在每个迭代周期内需要完成一个可用、可测试、可部署、可交付的软件产品版本。通过这种方式，团队可以更快地响应客户需求和市场变化，提高开发效率和质量，并不断改进和优化软件产品。
值得注意的是，潜在可交付的产品增量并不一定需要在迭代周期结束时立即交付给客户或者用于生产环境。它可以在迭代周期结束后进行进一步的测试、评估和优化，直至达到满足交付要求的标准后再进行交付。这有助于确保软件产品的质量和可用性，并避免潜在的风险和问题。

敏捷过程：

实施敏捷开发，看这一篇就够了

《敏捷开发培训考试》考试题目及答案 - jiftle - 博客园
迭代计划会议：Scrum敏捷管理之”迭代计划会“
迭代回顾： 迭代回顾会议是Scrum五个仪式之一，是在迭代评审会议之后对本次迭代的优点与改进点进行复盘的一个活动，其最主要的目的是提升团队的整体能力，持续改进，形成一个自学习的团队。. 通过回顾会议可以使团队每个迭代都能比上个迭代做得更好。. 在很多敏捷团队中，最容易忽略该活动，很多团队没有意识到该活动的重要性。. 为什么呢？. 最主要的原因是开了会议，没有实际效果，大家认为没用，所以也就不开了。. 实践中，在开迭代回顾会议时常犯的错误有：. 把回顾会议开成了吐槽大会，大家只提意见，不提改进措施；.

一般来说，迭代回顾会议可以持续1到2小时，以确保充分的讨论和反馈，但也不会过于耗费时间和资源。在会议开始前，团队成员应该准备好相关的数据和材料，如迭代进度报告、测试报告、客户反馈等，以便在会议中进行讨论和分析。
燃尽图：教你如何用燃尽图做项目管理
DOD和DOR是什么：敏捷开发中的 DoD 和 DoR 是什么？_dod 敏捷_LigaAI的博客-CSDN博客
投产文档是软件工程中的一种文档，也称为发布文档、上线文档或部署文档。它是在软件开发过程中最后一个阶段的重要产物，通常是由项目经理、开发团队和运维团队联合编写的。投产文档记录了软件系统的部署、测试、验证和上线等过程中的各种信息和细节，以确保系统能够在生产环境中稳定运行。而DOD是是需求准出的标准表示的是需求，而投产文档是整个步骤完成后要完成的
**PSPI:**在敏捷开发中，潜在可交付的产品增量（Potentially Shippable Product Increment，PSPI）指的是在当前迭代周期结束时，团队完成的一个可用、可测试、可部署、可交付的软件产品版本。它是在迭代周期内完成的所有工作成果的集合，包括新功能、增强功能和修复问题等。PSPI是一个完整的、可用的、可交付的软件产品版本，可以交付给客户或者用于生产环境。
敏捷开发法是一种以团队为核心的、迭代式、自下而上的开发方法，与自顶向下的传统开发方法有所不同。

目前存在两种形式的燃尽图，Sprint燃尽图用于显示迭代中的剩余工作量，而产品燃尽图则用于说明整个项目的剩余工作量。
用户故事（User Story）是敏捷开发中的一种需求描述方式，它描述了用户或利益相关者在使用软件系统时所需要完成的具体任务、目标或需求。用户故事通常由简短的、自然语言的语句组成，用于概括一个或多个特定的用户场景。通常，用户故事通过格式化的语句来描述，例如：
"As a [角色], I want to [行动], so that [目标]"在敏捷开发中，用户故事通常由客户或利益相关者提出，并与开发团队共同制定和明确。客户和利益相关者通常是最了解系统使用场景和需求的人，他们可以通过用户故事的方式清晰地描述和传达自己的需求和期望，帮助开发团队更好地理解和满足用户需求。
客户和利益相关者通常会参与到敏捷开发的迭代过程中，与开发团队一起讨论和优化用户故事，以确保开发团队理解和满足用户需求。这种协作和沟通方式可以帮助团队更好地把握用户需求和期望，以便更好地设计和开发软件产品。
除了客户和利益相关者，开发团队中的其他成员，如产品经理、业务分析师、开发人员等，也可以参与制定用户故事。他们可以提出自己的想法和建议，帮助团队更好地理解和实现用户需求，从而提高软件产品的质量和用户体验。

D选项：有估算的。Product Backlog中的需求应该根据其复杂度、工作量和资源等因素进行估算，并根据其估算结果进行排序和开发。因此，有估算的特点是Product Backlog应该具备的。
Product Backlog（产品待办列表）是敏捷开发中的一种需求管理工具，它是一个优先级排序的需求列表，其中包含了所有的产品需求、特性和用户故事等，以及与之相关的任务、缺陷和技术债务等。
Product Backlog由产品负责人（Product Owner）维护，并根据需求的优先级和价值进行排序和管理。产品负责人通常会与客户和利益相关者紧密合作，收集和明确需求，并根据需求的重要性和价值，将其添加到Product Backlog中。
Product Backlog中的每个需求通常都包含以下信息：

描述：对需求进行简要描述，例如需求的名称、特性等。
价值：对需求的重要性和价值进行评估，并根据其价值进行排序。
优先级：对需求的优先级进行评估，并根据其优先级进行排序。
状态：对需求的状态进行跟踪，例如已完成、正在进行中、待办等。
验收标准：对需求的验收标准进行定义，以便在需求完成后进行验收。

Product Backlog是敏捷开发中的一个重要工具，它可以帮助团队更好地管理和追踪需求，以便更好地满足客户需求和市场变化。团队通常会定期审查和优化Product Backlog，以保持其与产品需求的一致性和实时性。

敏捷开发团队通常由5至9人组成。

错误。虽然敏捷开发可以提高团队的灵活性和响应变化的能力，但是对于极高的关键性、可靠性、安全性要求的项目，敏捷开发不一定是最适合的开发方法。这类项目通常需要更多的计划、设计、测试和验证工作，以确保系统的稳定性、可靠性和安全性，而这些工作在敏捷开发中可能会被忽略或减少。
相反，传统的瀑布模型（Waterfall Model）可能更适合这类项目。瀑布模型强调计划、设计、测试和验证等阶段的顺序性和严格性，可以确保系统的稳定性、可靠性和安全性，并在项目初期进行详细的规划和设计，以避免后期的问题和风险。
当然，对于某些具有极高可变性的项目，例如创新型项目，敏捷开发可能是更为适合的方法。在这种情况下，敏捷开发可以帮助团队更快地响应变化和市场需求，从而提高创新和竞争力。

软件需求

软件需求指用户对目标系统在功能、性能等方面的期望;主要有:功能需求、性能需求、可靠性需求、可用性需求、出错处理需求、接口需求等

软件需求3层次：

软件需求的三个层次:
业务需求：业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求
业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。
一般使用前景和范围（vision and scope）文档来记录业务需求，称作项目轮廓图或市场需求文档。
这些最高级别的需求数量很少（2－5条）
**用户需求：**用户需求(user requirement)描述了用户使用产品必须要完成的任务。
用例、场景描述和事件―响应表都是表达用户需求的有效途径。
在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。
描述了用户能使用系统来做些什么（what）。
**功能需求：**系统分析员描述开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些用户需求（how），其数量往往比用户需求高一个数量级。
这些需求记录在软件需求规格说明SRS（Software Requirments Specification）中。

软件需求的分类

**功能需求：**描述系统预期提供的功能或服务
系统应提供的服务
系统如何对输入做出反应
系统在特定条件下的行为
系统不应该做什么
非功能需求：不直接与系统具体功能相关的需求。
产品需求：产品行为的需求，包括性能需求、可靠性需求和可用性需求等。
机构需求：客户和开发者所在机构中的政策和规定要求，如过程标准、实现要求、交付需求。
外部需求：所有的系统外部因素要求，如互操作需求

需求工程：

应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求分析的基本活动：

起始—询问一系列问题，以确立：
对问题的基本理解
谁需要解决方案
所期望解决方案的性质
导出—从所有利益相关者（ stakeholders）处获取需求（需求获取）
精化—创建一个分析模型，定义问题的信息域、功能域和行为域（需求建模）
协商—通过协商过程来调解客户提出的过高的目标要求和相互冲突的需求
规格说明—需求分析师的工作产品，为以下一种或几种:写好的文档、图形化的模型、形式化的数学模型、一组用户场景（用例）、原型
两种需求文档
需求定义：客户要求的完整列表
通常由客户和需求分析师一起编写，是开发人员对系统功能的一个合同，主要给客户阅读
需求规格说明：要构建系统的规格化说明
由需求分析师编写，并由其他软件开发人员使用
确认（需求验证）—通过评审机制，寻找：
内容或解释上的差错
可能需要进一步澄清的地方
丢失的信息
不一致 (开发大型系统时的主要问题)
冲突或不现实的需求
需求管理
在项目执行过程中标识、控制和跟踪需求以及变更需求

获取需求的技术：

**面谈：**面对面交流是理解业务功能和规则的最有效方法
该方法比较耗时和资源
项目组成员与单个用户或用户组举行会议
面谈步骤：
阅读背景资料
确定面谈目标
决定面谈对象
和面谈对象沟通。
整理面谈报告.
非正式面谈和正式面谈
**调查技术：**向客户组织的相关人员发放调查表
关键：确定调查内容
非正式会谈
制定调查表
组织调查
使用场合：
系统相关者较多
地理上分布广
**观察实际业务过程：**观察并记录业务流程
同用户进行交谈。
观察：有效收集信息的另一种方法
方式：直接在用户工作的地方观察他们的日常活动并记录下观察到的业务操作过程
观察方法
对办公室进行快速浏览
安排一定的时间观察用户的工作过程
同用户一道亲身实践体会工作过程
使用工作流图来进行记录
工作流 – 处理商业事务或客户请求的一系列步骤
工作流图：流程图、数据流图、活动图
**原型法：**软件原型是一种软件系统的局部实现技术，可以帮助软件开发人员、用户和客户更好地理解软件需求。
使用原型的主要目的：
明确并完善需求
探索设计选择方案
发展为最终的产品原型
**基于场景的需求捕获方法：**也称为情景实例的分析方法
基于对应用环境的某一特定情景的描述来阐述用户的需求
从场景的结构化描述中抽取活动图、场景、角色、数据关系图等，从而形成需求模型。
**竞争性需求分析法：**1) N (Need 需求)
你的创意解决了用户的什么需求?
2) A (Approach 做法)
你有什么招数, 特别是独特的招数, 来解决用户的痛苦。
3) B (Benefit 好处)
那你这个产品用户带来什么好处呢?
4) C (Competitors 竞争)
与竞争对手相比你有什么优势?
5) D (Delivery)
你怎么让目标用户都知道你的产品? 并且让产品的用户量快速提高?

需求建模方法：

结构化分析
考虑数据和处理的分析建模方法
数据作为独立实体转换
数据对象定义了对象的属性和关系
处理表明数据对象在系统内流动时的数据转换
面向对象分析
定义类和类之间的协作方式

结构化分析方法-技术：

如何掌握结构化的分析方法？

数据流图：

软件工程：数据流图，数据字典的画法，以及如何转化为软件结构图_数据字典怎么画_Brother汤的博客-CSDN博客
 【软件工程】根据数据流图导出程序结构_数据流图转换为软件结构图_AC它真的很香的博客-CSDN博客
 【软件工程】数据流图 ( 数据流图简介 | 数据流图概念 | 数据流 | 加工 | 数据存储 | 外部实体 | 数据流图分层 | 顶层数据流图 | 中层数据流图 | 底层数据流图 )_韩曙亮的博客-CSDN博客
数据字典：数字字典是指一个用来存储和管理数据元素定义和描述信息的集合，它包括了系统中使用到的所有数据元素、数据结构、数据类型、数据格式、数据值域等信息。数字字典通常用于帮助软件开发人员在系统分析、设计和开发中更好地理解和管理数据元素。其基本功能是数据定义。
找到变换中心是数据流图导出结构图的关键，一般将数据流划分为交换流和事务流。

结构化分析常用工具：数据流图（DFD），数据字典（DD），判定表，判定树。
详细设计阶段常用的工具：程序流程图，N-S图，PAD图，HIP0图。而需求分析主要是完成总体设计，是结构化分析，需求分析建模是采用结构化分析建模。

是的，数据流图和数据字典通常被视为系统的逻辑模型的两个主要组成部分。
数据流图（Data Flow Diagram，简称DFD）是一种图形化工具，用于描述系统中数据的流动和处理过程。它通过图形符号表示系统中的各种处理过程、数据存储、数据流动和外部实体，形成一个数据流图，用于描述系统的功能和行为。数据流图通常用于识别和定义系统的功能需求、系统流程和数据流动的过程。
数据字典（Data Dictionary）是系统中使用的各种数据和信息的集合，包括数据类型、数据格式、数据来源和数据用途等。它用于描述系统中各种数据和信息的定义和用途，从而为系统的设计、开发和测试提供指导和依据。数据字典通常包括数据元素的名称、描述、数据类型、数据长度、数据格式、取值范围等信息。

如果在数据流图中出现控制流，将会导致数据流图的复杂度增加，难以理解和维护。此外，过多的控制流可能也会使数据流图变得冗长和混乱，影响对系统的理解和描述。
因此，数据流图不允许出现控制流，它应该专注于描述系统中的数据流动和处理过程，从而更好地识别和定义系统的功能需求和功能间的关系。

需求规格说明书不包括软件的可行性研究的依据需求分析：系统必须做什么？定义时期最后一个阶段，产生软件需求规格说明书。可行性研究是在其上一个步骤

软件需求分析阶段的主要工作包括四个方面：需求获取、需求分析、编写需求规格说明书和需求评审1 2 3 4 5。需求获取是通过与用户接触初步确定系统的功能；需求分析的任务是确定系统必须完成哪些工作，提出完整、准确、清晰、具体的要求；在需求分析阶段结束之前，系统分析员应该编写需求规格说明书；需求评审是根据需求规格说明书来严格审查和验证需求分析的结果1。

数据字典中什么是加工条目：，加工条目（Processing Entry）是指描述系统中某个数据项的加工过程或转换过程的数据元素。

软件工程 – 数据流图的画法_CodeJiao的博客-CSDN博客

Beta测试是一种软件测试方式，旨在通过让最终用户或特定用户群体使用软件产品的测试版本，以帮助开发人员收集用户反馈和识别潜在问题。Beta测试通常是软件开发周期中的最后一个测试阶段，在正式发布之前进行。
Beta测试通常包括以下几个步骤：

选定测试用户：在Beta测试阶段，开发团队会选定一些最终用户或特定用户群体来测试软件产品的测试版本，以获得真实的用户反馈和使用情况。
发布测试版本：开发团队会将软件产品的测试版本发布给测试用户，让他们使用并提供反馈和建议。
收集用户反馈：测试用户使用测试版本后，会向开发团队提供反馈和建议，包括软件的使用体验、功能问题、性能问题等。
分析和修复问题：开发团队会分析用户反馈和测试结果，识别潜在问题并进行修复和改进。
发布正式版本：经过多次Beta测试和问题修复后，开发团队会发布正式版本的软件产品。

Beta测试可以帮助开发人员在软件发布之前获得真实的用户反馈和使用情况，从而识别和修复潜在问题，提高软件的质量和用户体验。同时，Beta测试也可以建立用户与开发团队之间的沟通渠道，促进开发团队和用户之间的合作和沟通。

条件覆盖：判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支
判定条件覆盖：判定/条件覆盖是使判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次；
条件覆盖，路径覆盖，语句覆盖，分支覆盖 - Jerry19880126 - 博客园

软件设计阶段：

【软件工程】软件设计阶段_光哥_帅的博客-CSDN博客
软件设计阶段输出的主要是设计规格说明书

程序的正确性：是程序能够满足规格说明书和用户目标的程度

等价类的划分：等价类划分法-案例剖析-设计测试用例_等价类划分法举例_chde2Wang的博客-CSDN博客

代码审查：代码审查(Code Review)_代码审核_夕刃的博客-CSDN博客

功能点方法（FPA）：

  （Function Point Analysis） 功能点分析法，简称FPA，与代码行分析法是近年来最流行的两种基础软件规模估算和度量方法。是从用户角度出发度量软件规模的一种方法。它从用户的角度出发，将**系统分为数据功能和事物功能两大类（这是要依靠**信息域值），分别根据具体的规则来计算功能点，最后结合系统的特征因子来调整功能点数， 从而得到最终的系统规模。

A. 计算机辅助静态分析是软件测试方法中的静态测试方法之一。静态测试是在代码执行之前对软件进行检查，以发现潜在的缺陷和错误。计算机辅助静态分析是使用计算机工具对软件代码进行分析，以检测潜在的缺陷和错误。这种方法可以自动化地执行许多常见的静态测试任务，例如语法检查、类型检查、代码风格检查等。因此，它可以提高软件开发的效率和质量。其他静态测试方法包括代码审查、故障模拟和需求分析等。

详细设计阶段可以利用判定树和判定表。

软件重用是指在开发新软件时，利用已有的可重复使用的软件组件、模块或库，以便更快地、更经济地开发出高质量的软件。它可以降低软件开发成本、缩短开发周期、提高软件的可靠性、可维护性和可重用性。
具体来说，通过软件重用可以实现以下优点：

提高软件开发效率：软件重用可以避免重复开发已有的功能，减少了开发时间和成本。
提高软件质量：经过多次测试和验证的可重用组件，具有高质量和稳定性，能够提高新软件的可靠性和稳定性。
提高软件可维护性：可重用的软件组件通常具有良好的文档和接口规范，易于维护和更新。
提高软件可重用性：重用软件组件可以使开发人员积累更多的经验和技能，并促进软件组件的共享和发展。

因此，软件重用是降低软件成本和提高软件质量的合理方法之一

对的，盒图的特点是取
消了传统流程图中的流程线，而是使用缩进和嵌套的方式来表示程序的结构和控制流程。这种表达方式强迫程序员以结构化方式思考和解决问题，避免了不必要的跳转和分支，使程序更易于理解和维护。、

McCall的质量模型

McCall的软件质量模型_gz153016的博客-CSDN博客