（软考）系统分析师——软件工程

最新推荐文章于 2024-07-07 19:51:06 发布

吃货小娃子

最新推荐文章于 2024-07-07 19:51:06 发布

阅读量858

点赞数

分类专栏：软考系统分析师文章标签：经验分享

本文链接：https://blog.csdn.net/x12345_67890/article/details/109133582

版权

软考系统分析师专栏收录该内容

16 篇文章 7 订阅

订阅专栏

ps:本博客内容只针对博主复习期间对考点的一些总结，内容可能并不全面，还望海涵。也欢迎大家补充和指点错误~~

软件开发生命周期

主要过程：
- 获取过程：
  - 定义、分析需求或委托供方进行需求分析而后认可；招标准备；合同准备以及验收
- 供应过程：
  - 评审需求；准备投标；签订合同；制定并实施项目计划；开展评审及评价；交付产品
- 开发过程：
  - 过程实施；系统需求分析；系统结构设计；软件需求分析；软件结构设计；软件详细设计；软件编码和测试；软件集成；软件合格测试；系统集成；系统合格测试；软件安装及软件验收支持
- 运行过程：
  - 制订并实施运行计划；运行测试；系统运行；对用户提供帮助和咨询
- 维护过程：
  - 问题和变更分析；实施变更；维护评审及维护验收；软件移植及软件退役
支持过程：
- 文档编制过程
  - 设计文档编制标准；确认文档输入数据的来源和适宜性；文档的评审及编辑；文档发布前的批准；文档的生产与提交、存储和控制；文档的维护
- 配置管理过程
  - 配置标志；配置控制；记录配置状态；评价配置；发行管理与交付
  - 软件配置管理的活动主要有编制配置管理计划、配置标识、配置控制、配置状态报告、配置评价、发行管理和交付。
- 质量保证过程
  - 软件质量保证是软件项目控制的重要手段，软件评审是软件质量保证的主要活动之一，其主要方法是审查与复审。
  - 软件产品的质量保证；软件过程的质量保证，以及按ISO 9001标准实施的质量体系保证
- 验证过程
  - 合同、过程、需求、设计、编码、集成和文档等的验证
- 确认过程
  - 为分析测试结果实施特定的测试；确认软件产品的用途；测试软件产品的适用性
- 联合评审过程
  - 实施项目管理评审（项目计划、进度、标准、指南等的评价）；技术评审（评审软件产品的完整性、标准符合性等）
- 审计过程
  - 审核项目是否符合需求、计划、合同，以及规格说明和标准
- 问题解决过程
  - 分析和解决开发、运行、维护或其他过程中出现的问题，提出响应对策，使问题得到解决
组织过程：
- 管理过程
  - 制定计划；监控计划的实施；评价计划实施；涉及到有关过程的产品管理、项目管理和任务管理
- 基础设施过程
  - 为其他过程所需的硬件、软件、工具、技术、标准，以及开发、运行或维护所用的各种基础设施的建立和维护服务；
- 改进过程
  - 对整个软件生存期过程进行评估、度量、控制和改进
- 培训过程
  - 制定培训计划；编写培训资料；培训计划的实施

软件开发方法

净室方法

净室方法是软件开发的一种形式化手法，可以生成高质量的软件；
使用盒结构规约进行分析和设计建模，主要使用的三种盒类型有：黑盒、状态盒、清晰盒
完成盒结构设计后，则运用正确性验证，再统计使用测试，和传统测试不一样，净室软件工程并不强调单元测试或集成测试，使用场景使用概率以及定义符合概率的随机测试来进行软件测试。

结构化方法

属于自顶向下的开发方法，基本思想是“自顶向下，逐步求精”；
针对软件生存周期的各个不同阶段包括：
- 结构化分析（SA）
- 结构化设计（SD）
- 结构化程序设计（SP）
结构化方法的基本原则
- 面向用户的观点
- 严格区分工作阶段，每个阶段都有明确的任务和对应成果；
- 按照系统的观点，自顶向下的完成系统的开发工作；
- 充分考虑变化的情况；
- 工作成果文献化、文档化
结构化分析（SA)
- SA方法使用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下、逐层分解，直至找到满足功能要求的所有可实现的软件为止；
- 一般利用图形表达用户需求，使用手段主要有数据流图（DFD)、数据字典、结构化语言、判定表及判定树
- SA方法步骤：
  - 分析当前的情况，做出反映当前物理模型的数据流图（DFD)
  - 推导出等价的逻辑模型的DFD
  - 设计新的逻辑系统，生成数据字典和基元描述；
  - 建立人机接口，提出可供选择的目标系统物理模型的DFD
  - 确定各种方案的成本和风险等级，据此对各种方案进行分析
  - 选择一种方案
  - 建立完整的需求规约
结构化设计（SD)
- SD方法适用于变换型结构和事务型结构的目标系统；
- SD方法从整个程序的结构出发，利用模块结构图表述程序模块之间的关系；
- SD方法的步骤：
  - 评审和细化数据流图；
  - 确定数据流图的类型；
  - 把数据流图映射到软件模块结构上，设计出模块结构的上层；
  - 基于数据流图逐步分解高层模块，设计中下层模块
  - 对模块结构进行优化，得到更为合理的软件结构；
  - 描述模块接口
SD方法的设计原则是：
- 使每个模块执行一个功能（坚持功能性内聚）
- 每个模块使用过程语句调用其他模块
- 模块间传送的参数作为数据使用
- 模块间共用的信息尽量少
SD方法的缺点：
- 开发周期长
- 早期的结构化方法注重系统功能，兼具数据结构的方面不多
- 结构化程度较低的系统，在开发初期难以锁定功能要求

原型法

软件原型是所提出的新产品的部分实现，建立原型的主要目的是为了解决开发初期需求不明确的问题，其目的是明确并完善需求、探索设计选择方案、发展为最终产品；
原型的分类：
- 从原型是否实现功能分：
  - 水平原型（行为原型）：用来探索预期系统的一些特定行为，并达到细化需求的目的；通常只是功能的导航，不实现功能，主要用在界面上；
  - 垂直原型（结构化原型）：实现一部分功能；主要用在复杂算法实现上
- 从原型的最终结果分
  - 抛弃型原型（探索型原型）：达到预期目的后，被抛弃；主要用在解决需求不确定性、二义性、不完整性、含糊性等；
  - 演化型原型：为开发增量式产品提供基础，是螺旋模型的一部分，也是面向对象软件开发过程的一部分；主要用在必须易于升级和优化的系统，以适用Web的项目
原型类型的选择
- 如果在需求分析阶段要使用原型化方法，需要从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑；
  - 系统结构：联机事务处理系统、相互关联的应用系统适合；批处理、批修改等结构不适宜
  - 逻辑结构：有结构的系统适合；基于大量算法的系统不适合；
  - 用户特征：愿意承担决策责任，准备积极参与的用户适合；
  - 应用约束：对已运行系统的补充不适合；
  - 项目管理：只有项目负责人愿意使用原型化方法，才适合使用；
  - 项目环境：根据每个项目实际环境选择
- 当系统规模很大、要求复杂、系统服务不清晰时，可以在需求分析阶段先开发一个系统原型，特别是当性能要求较高时，用原型做试验很有必要。
- 原型生存期：原型的开发和使用过程
- 快速分析：在分析者和用户紧密配合下，快速确定软件系统基本要求；
- 构造原型：在快速分析基础上，根据基本需求，尽快实现一个可运行的系统；
- 构造原型需要注意的2个基本原则：集成原则（尽可能用现有软件和模型来构成，这需要相应的原型工具）、最小系统原则（耗资一般不超过总投资的10%）
原型开发技术
- 通常用于构造原型的一些技术包括：
  - 可执行规格说明、基于场景的设计、自动程序设计、专用语言、可复用的软件构件、简化假设和面向对象技术等

逆向工程

对旧软件进行重新处理、调整，提高其可维护性；
再工程
- 对现有软件系统的重新开发过程，包括逆向工程（反向工程）、新需求的考虑（软件重构）、正向工程
软件重构
- 软件重构是对源代码、数据进行修改，使其易于修改和维护，以适应将来的变更；
- 软件重构并不修改软件体系结构，而是关注模块的细节；
- 软件重构分为：代码重构、数据重构
- 软件重构的意义在于提高软件质量和生产率，减少维护工作量，提高软件可维护性
逆向工程
逆向工程是分析程序，力求在比源代码更高的抽象层次上建立程序表示的过程；
逆向工程的完整性是指在某些抽象层次上提供的细节程度，在大多数情况，随着抽象层次增高，完整性就降低；

软件开发模型

瀑布模型（生命周期法）

是结构化方法中最常用的开发模型，适用于需求明确或很少变更的项目
把软件开发的过程分为
- 软件计划（问题的定义及规划）
  - 主要确定软件的开发目标及其可行性
- 需求分析
  - 对软件需要实现的各个功能进行详细分析
- 软件设计
  - 对整个软件系统进行设计，一般分为总体设计（概要设计）和详细设计
    - 总体设计：将项目分成若干模块，确定模块功能以及模块之间的接口
    - 详细设计：具体设计每个模块的功能和结构
- 程序编码：
  - 将软件设计的结果转换成计算机可运行的程序代码；
- 软件测试
  - 进行严密测试，已发现软件在整个设计过程中存在的问题并加以纠正；
- 运行维护
  - 是软件生命周期中持续最长的时间
规定按自上而下、相互衔接的固定次序，进行开发
优点：
- 为项目提供了按阶段划分的检查点（文档）
- 当前一阶段完成后，只需要去关注后续阶段
- 提供了模板
缺点：
开发是线性的，所以未经测试用户无法看到软件效果，增加一定风险
开发前期未发现的错误传到后面可能会扩散，导致整个软件项目开发失败
需求分析阶段要想完全确定用户的所有需求几乎是不可能的
产生大量文档

其他经典模型

演化模型（变换模型）
- 从原型到逐步细化的过程，适用于对软件需求缺乏准确认识的情况
螺旋模型
- 将瀑布模型和快速原型模型相组合，增加风险分析，以原型为基础，强调项目的风险分析，特别适合大型复杂系统的开发过程
- 螺旋模型沿着螺线进行若干次迭代，依次经历计划指定、风险分析、工程实施、软件测试四个主要活动
喷泉模型
- 以用户需求为动力，以对象为驱动，开发过程自下而上，主要支持面向对象的开发方法；具有迭代和无间隙的特性；所谓无间隙是指在开发活动中，分析、设计、编码之间不存在明显边界
智能模型
- 基于知识的软件开发模型，综合上述若干模型，并与专家系统结合在一起；该模型应用基于规则的系统，采用规约和推理机制，实施过程中要建立知识库，将模型本身软件工程知识与特定领域的知识分别存入数据库
增量模型
- 融合瀑布模型的基本成分和原型实现的迭代特征；强调每个增量均发布一个可操作产品，引进增量包的概念；第一个增量往往是核心的产品，实现基本需求；客户对每个增量的使用和评估都作为下一增量发布的新特征和功能；
- 优点：
  - 人员分配灵活；
  - 不能在期限完成产品时提供先推出核心产品的途径；
  - 能够有计划的管理技术风险
- 缺点：
  - 增量包之间存在相交情况且不能很好处理就必须做全盘系统分析；
- 增量模型采用将功能细化、分别开发的方法，适用于需求经常改变的软件开发过程
迭代模型
- 开发迭代是一次完整的经过所有工作流程的过程；每一次迭代都会产生一个可以发布的作品，这个产品是最终产品的子集；迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发
构件组装模型
- 基于构件的软件开发（CBSD）模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程；
- 融合了螺旋模型许多特性，本质是演化型的、开发过程是迭代的
- 优点：
  - 提高软件开发效率，不再从头开始，开发过程是构件组装过程；
  - 允许多个项目同时开发，降低费用，提高可维护性
- 缺点：
  - 缺乏通用的组装结构标准，引入具有较大风险；
  - 可重用性和软件高效性不易协调
  - 过于依赖构件，构件库的质量影响产品质量
V模型
以测试为中心的开发模型
单元测试的主要目的是针对编码过程中可能存在的各种错误
集成测试主要目的是针对详细设计中可能存在的问题，尤其检查各单元与其他程序部分之间的接口中可能存在的错误
系统测试主要针对概要设计，检查系统作为一个整体是否有效得得到运行
验收测试通常由业务专家或用户进行，已确认产品能真正符合用户业务上的需要，针对需求分析

快速应用开发（RAD）

RAD是一个增量型的软件开发过程模型，强调极短的开发周期；
通过大量可复用的构件，采用基于构件的建造方法赢得快速开发；
RAD模型各个活动及其要完成的任务：
- 业务建模：数据流图
- 数据建模：E-R图
- 过程建模：细化数据流图的处理框
- 应用程序生成
- 测试与交付：一般只做总体测试

敏捷方法

敏捷方法主要适用于小规模软件开发和小型团队开发
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。强调程序员团队与业务专家之间的紧密协作、面对面沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法，更注重人的作用；
敏捷开发原则：
- 最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意；
- 即使到开发后期也欢迎改变需求，利用变化来为客户创造竞争优势
- 经常性的交付可以工作的软件，交付时间越短越好，不要求每次交付的都是系统的完整功能
- 整个项目开发期间业务人员和开发人员必须天天在一起工作
- 通过提供工作人员需要的环境和支持并且足够信任他们来激励他们构建项目
- 团队内部的面对面交谈是非常具有效果并且富有效率的传递信息的方法
- 工作的软件是首要进度度量标准
- 敏捷过程需要提供持续开发速度
- 不断地关注优秀的技能和好的设计会增强敏捷能力
- 简单——使未完成的工作最大化的艺术——是根本的
- 最好的架构、需求和设计出自团队内部
- 每隔一段时间团队内部对如何更有效工作进行反思和调整
敏捷开发的不同流派
- 极限编程（XP）：
  - 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学且充满乐趣的软件开发方式
  - 适用于小型或中型软件开发团队，并且客户的需求模糊或需求多变
  - 注重的核心是沟通、简明、反馈、勇气；由于知道计划永远赶不上变化，所以无需在软件开始初期做很多的文档，提倡测试先行，为以后出现bug的几率降到最低
  - 使用的重要技术是重构，包括设计技术的重构和结构技术的重构
  - 提倡在基础设计完成后，团队不直接开始编码，而是开发一系列用于检测本次发布的包括所有故事（story）的单元测试；
  - 关键概念之一是“结对编程”，推荐两人面对同一台计算机共同开发代码
  - 编程过程中建立的单元测试应当使用一个可以自动实施的框架，支持代码修改后及时的回归测试策略
- 自适应软件开发(ASD)
  - ASD不像其他方法那样具有很多具体的实践做法，侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性；
- SCRUM
  - 是一种迭代的增量化过程，用于产品开发或工作管理；是一种可以集合各种开发时间的经验化过程框架；其中发布产品的重要性高于一切；是一种寻求充分发挥面向对象和构建技术的开发方法，是对迭代式面向对象方法的改进。
- 水晶方法(Crystal Methods)
  - 是一个系列，他相信不同类型的项目需要不同的方法
- 动态系统开发方法(DSDM)
  - 倡导以业务为核心，快速而有效的进行系统开发
- 轻量型RUP
  - RUP其实是个过程的框架，可以包容许多不同类型的过程
- 特性驱动开发(FDD)
- 是一套针对中小型软件开发项目的开发模式；
- 是一个模型驱动的快速迭代开发过程
- 强调的简化、实用、易于被开发团队接受，适用于需求经常变动的项目
从开发者角度，主要关注点有短平快会议、小版本发布、较少文档、合作为重、客户直接参与、自动化测试、适应性计划调整、结对编程；
从管理者角度，主要关注点有测试驱动开发、持续集成、重构

统一过程(UP/RUP）

UP是一个通用过程框架，基于构件，使用的是UML；与其他软件过程相比显著特点是：用例驱动、以体系结构为中心、迭代和增量
UP中软件过程在时间上被分解成四个顺序过程：
- 初始阶段：为系统建立业务模型并确定项目边界；
- 细化阶段：分析问题域，建立健全的体系结构基础，淘汰项目中最高风险的元素
- 构建阶段：开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试
- 交付阶段：确保软件对最终用户是可用的。
每个阶段结束都要安排一次技术评审，以确定这个阶段的目标是否已经达成，通过这四个阶段就是一个开发周期，每经过一个周期产生一代软件；
UP工作流程分为两部分：
- 核心工作流程（在项目中的流程）：业务需求建模、分析设计、实施、测试、部署
- 核心支持工作流程（在组织中的流程）：环境、项目管理、配置、变更管理

系统规划与问题定义

总体规划阶段主要目标是制定软件的长期发展方案，决定软件在整个生命周期内的发展方向、规模和发展进程；
总体规划阶段任务：
- 制定软件的发展战略
- 确定组织的主要信息需求，形成软件的总体结构方案，安排项目开发计划
- 制定系统建设的资源分配计划
总体规划阶段步骤：
- 对当前系统进行初步调查,初步调查包括一般调查和软件需求初步调查，软件需求初步调查是主要内容；
- 分析和确定系统目标
- 分析子系统的组成以及基本功能
- 拟定系统的实施方案
- 进行系统的可行性分析
- 编写可行性报告

可行性分析

可行性研究的任务是研究系统开发的必要性和可能性，用最少的代价在尽可能短的时间内确定问题是否值得解决和是否能够解决；
一般可行性分析从
- 技术可行性
  - 确定使用现有的技术资源条件下能否实现系统，技术风险有多大，系统能否实现；
- 经济可行性
  - 进行开发成本的估算以及了解取得效益的评估，确定要开发的系统是否值得投资开发；
- 操作可行性（运行环境可行性）
  - 包括法律（社会）可行性、操作使用可行性（执行可行性）
    - 法律方面：主要指在系统开发过程中可能涉及的各种合同、侵权、责任以及各种与法律相抵触的问题；
    - 操作使用方面：主要指系统使用单位在行政管理、工作制度和人员素质等因素上能否满足系统操作方式的要求
可行性分析的步骤：
- 核实问题定义与目标：
  - 使问题定义更加清晰、明确、没有歧义，对于系统目标、规模以及相关约束与限制条件做出更加细致的定义
- 研究分析现有系统
- 为新系统建模：
  - 目的是获得一个对新系统的框架认识和概念性认识，一PO般采用的技术：
    - 系统上下文关系范围图（数据流图的0层图）
    - 实体关系图
    - 用例模型
    - 域模型
    - IPO表
- 用户复核：将模型与客户进行复核
- 提出并评价解决方案
- 确定最终推荐的解决方案
- 草拟开发计划
- 提交可行性分析报告：
  - 大致内容有：引言、可行性研究的前提、对现有系统的分析、所建议的系统、可选择的其他系统方案、投资及效益分析、社会因素方面的可行性、结论

成本效益分析

成本效益分析首先是估算新系统的开发成本，然后与可能取得的利益进行权衡比较；
有形的效益：用货币时间价值、投资回收期、投资回收率等进行度量；
无形的效益：主要从性质上、心理上进行权衡

货币时间价值

P为本金，n为年期，i为利率，F为P元在n年后的价值
单利：仅本金为基数的计算利息，计算公式：F=P×(1+i×n)
复利：以本金与累计利息之和为基数计算利息，F=P×(1+i)ⁿ
折现（贴现）：把将来某一时点的资金额换算成现在时点的等值金额；
折现率（贴现率）：折现时所使用的利率；
折现系数：若n年后能收入F元，那么这些钱现在的价值（现值）P=F/(1+i)ⁿ,其中1/(1+i)ⁿ为折现系数

净现值分析法

净现值(NPV)：是指项目在生命周期内各年的净现金流量按照一定的、相同的贴现率贴现到初时的现值之和，即：(第t年的收入－第t年的支出)/(1+折现率或行业基准收益率)^t求t=0到t=n的和
如果NPV=0，表示正好达到规定的基准收益率水平；
NPV>0,表示可以得到超额收益，方案可行；
NPV<0,表示方案达不到基准收益率水平，不可行
一般净现值越大越好
同一净现金流量的净现值随着折现率i的增加而减少，故基准收益率i定得越高，能被接受的方案就越少
净现值指标用于多个方案比较时，不考虑各方案投资额的大小，所以不能直接放映资金利用率，一般采用净现值率(NPVR)作为净现值的辅助指标，其计算公式为：NPVR=NRV/投资总额§
由于P>0，所以对于单一方案来说，若NPV>=0,则NPVR>=0;若NPV<0,则NPVR<0;因此净现值与净现值率是等效的评价指标

内含报酬率（IRR)的分析

由于实际折现率不是一成不变的，往往会因为各种因素使其偏高于银行贷款利率，实际折现率升高，方案的可行性就下降，这就存在一个临界点，当实际折现率高于此值时，方案就不可行。这个临界点叫内含报酬率（内部收益率），即一种能够使投资方案的净现值为0的折现率。
使用线性插值法来求IRR，其公式为：IRR=i₁+(i₂-i₁)×|b|/(|b|+|c|)
i₁：表示有剩余净现值的低折现率；|b|：表示低折现率时剩余净现值的绝对值
i₂：表示产生负净现值的高折现率；|c|：表示高折现率时负净现值的绝对值
内含报酬的最大优点：排除了项目大小、生命周期长短等因素，给出了评价不同项目经济效益的统一指标

投资回收期

投资回收期是指投资回收的期限，也就是用投资方案所产生的净现金收入回收初始全部投资所需时间。投资回收期反映投资回收快慢
根据是否考虑资金的时间价值可分为
- 静态投资回收期（不考虑）：
  - 第一种情况，一次性支付全部投资P，当年产生收益，每年净现金收入不变（收入-支出），不包括投资支出，此时，静态投资回收期T=全部投资/每年净现金收入
  - 第二种情况，仍是一次性支付全部投资P，但每年净现金收入不一样，则能使全部投资等于0-T年每年净现金收入之和的T值便是静态投资回收期
  - 第三种情况，如果投资在建设期m年内分期投入，t年投资为P_t,t年净现金收入仍为t年收入-t年支出，则能够使0~T年总投资等于0-T年总净现金收入的T值为静态投资回收期
  - 一般可使用下列使用公式计算T值：
    - T=累计净现金开始出现正值的年份数-1+|上年累计净现金|/当年净现金
- 动态投资回收期（考虑）：
  - T_p=累计折现值开始出现正值的年份数-1+|上年累计折现值|/当年折现值

投资回收率

投资回收率反应企业投资的获利能力，其计算公式为：投资回收率=1/动态投资回收期×100%

盈亏平衡点（BEP)

盈亏平衡点是指在这一点上，销售收入等于总成本，项目既不亏损，也不盈利；
盈亏平衡点越低，表示项目适应市场变化的能力越大，抗风险能力越强；
其计算公式为：BEP=TFC/(P-VC);TFC,表示总固定成本；P,表示单位售价；VC,表示单位可变成本
可变成本是与产量水平成比例变化的要素，通常包括原材料、劳动力成本以及利用成本
固定成本是不随数量变化的费用，通常包括租金、保险费以及财务税

系统建模

结合现有系统（当前）的分析，进行新系统设计的过程
1. 获得当前系统的物理模型
2. 抽象出当前系统的逻辑模型
3. 建立目标系统的逻辑模型
4. 建立目标系统的物理模型

问题定义

为了对要解决的问题有个透彻的理解需要进行5个步骤：
- 在问题定义上达成共识
- 理解问题的本质
- 确定项目干系人
- 定义系统边界
- 确定系统实现的约束
对于一个问题的完整定义，通常应该包括3个方面
- 目标：是指构建系统的原因，是最高层次的用户需求，是业务上的需要；功能和性能需求则必须是以某种形式对该目标做出贡献
- 功能：用来指明系统必须做的事情，功能需求应该来源于业务需求，只与问题域有关
- 非功能需求（性能）：是系统必须具备的属性，它们是产品具有吸引力、易用、快速、可靠

需求工程

需求工程是包括创建和维护系统需求文档所必需的一切活动的过程，可分为
- 需求开发
  - 获得需求并形成文档的过程；
  - 包括需求获取、需求分析、编写规格说明书（需求定义）、需求验证
- 需求管理
  - 需求跟踪和需求变更的管理
  - 包括定义需求基线、处理需求变更及需求跟踪等
上述两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障；需求开发是努力更清晰、更明确的掌握客户对系统的需求；需求管理是对需求变化进行管理的过程

需求开发概述

需求开发主要确定开发软件的功能、性能、数据和界面等要求；
需求开发工作可分为4个方面：
- 问题识别/情况获取
- 分析与综合/分析
- 编制需求分析文档/编写规格说明
- 需求分析与评审/评审
需求分类：
- 功能需求：定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求
- 非功能需求：产品必须具备的性能或品质
- 设计约束：限制条件、补充规约
- 业务需求：是指反映组织机构或客户对系统、产品高层次的目标要求，在项目视图与范围文档中予以说明；
- 用户需求：从用户使用角度考虑的需求，描述用户使用产品必须完成的任务，在用例文档或方案脚本说明中予以说明
- 系统需求：从系统角度说明软件需求，是IT人考虑的重点，包括用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束

需求获取

需求获取技术：
- 用户访谈
- 用户调查
- 现场观摩
- 阅读历史文档
- 联合讨论会

需求分析

详细调查

收集资料：调查的根本手段
开调查会：能够有效获取用户对系统的想法和建议等定性特征
个别访问：通常作为开调查会的补充，可以根据需要对个别人进行详细访问
书面调查：主要适用于系统比较复杂、调查范围比较宽的情况
抽样调查：主要适用于那些需要全面资料而又不可能进行全面调查，或者进行全面调查有困难，或者没有必要进行全面调查的情况
现场观摩：适用于系统流程和操作过程复杂、难以用语言表达的情况
参加业务实践
阅读历史文档：主要适用于一些数据流比较复杂、工作表单较多的项目。

业务流程分析

业务流程分析的目的是了解各个业务流程的过程，明确各部门之间的业务关系和每个业务处理的意义，为业务流程合理化改造提供建议，为业务流程变化提供依据；
业务流程分析的步骤：
- 通过调查掌握基本情况
- 描述现有业务流程，绘制业务流程图
- 确认现有业务流程
- 对业务流程进行分析
- 发现问题，提出解决方案；
- 提出优化后的业务流程

数据流图（DFD)

DFD是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法
DFD利用图形符号通过逐层细分的描述系统内各个部件的功能和数据在他们之间传递的情况，来说明系统所完成的功能；
DFD通常有4种基本符号，分别是
- 数据流：具有名字和流向的数据，DFD中用标有名字的箭头表示
- 加工：对数据流的变换，一般用圆圈表示
- 数据存储：可访问的存储信息，一般用直线段表示
- 外部实体：位于被建模的系统之外的信息生产者或消费者，不能由计算机处理的成分，分别表示数据处理过程的数据来源及去向，用标有名字的方框表示

数据字典

目的是对数据流程图中各个元素做出详细的说明（定义和描述）；
DFD和数据字典共同构成系统的逻辑模型
常用的加工描述方法有：结构化语言、判定树、判定表

需求定义

需求定义的过程是形成需求规格说明书的过程，通常有两种需求定义的方法：
- 严格定义（预先定义）方法
  - 是目前采用较多的一种需求定义方法；
  - 在严格定义方法中，各个工作阶段排列成理想的线性开发序列，每个工作阶段都用上一阶段所提供的完整、严格的文档作为指导文件，因此本质上是一种顺序型的开发方法；
  - 严格定义建立在以下基本假设上：
    - 所有需求都能被预先定义；
    - 开发人员与用户之间能够准确而清晰的交流；
    - 采用图形/文字可以充分体现最终系统
  - 缺陷：
    - 文档量大
    - 开发过程可见性差，来自用户的反馈太迟
- 原型方法
  - 是一个开发人员与用户通力合作的反复过程；
  - 从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求根据用户要求不断的对系统进行完善，实质上是一种迭代的循环型开发方式；
  - 需要注意的几个问题：
    - 并非所有的需求都能在系统开发前准确的说明；
    - 项目参加者之间通常都存在交流上的困难，原型提供克服该困难的一个手段；
    - 需要实际的、可供用户参与的系统模型；
    - 有合适的系统开发环境；
    - 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法

软件需求说明书(SRS)

SRS是需求开发阶段的成果，代表用户和开发人员对软件系统的共同理解，是软件项目后期开发和维护的基础；
SRS不仅是系统测试和用户文档的基础，还是所有子系列项目规划、设计和编码的基础；
SRS需要把用户对软件的功能需求和非功能需求进行详细记录和准确描述，尽可能完整的描述系统预期的外部行为和用户可视化行为；
SRS不应该包括设计、构造、测试或工程管理的细节，也不应该包括对算法的详细过程描述

需求管理

需求变更的管理主要是使用需求变更流程和需求跟踪矩阵的管理方式；
需求跟踪分为正向跟踪和逆向跟踪，一般合称双向跟踪；不论采用哪种跟踪方式，都要建立和维护需求跟踪矩阵；
需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现前后生存期

软件设计

软件设计可以分为
- 概要设计：
  - 概要设计也称为高层设计或总体设计；
  - 将软件需求转换为数据结构和软件的系统结构；
  - 主要包括设计软件的结构、确定系统有哪些模块组成，以及模块之间的关系；
  - 采用结构图来描述程序的结构，还可以使用层次图和HIPO（输入处理输出图）；
- 详细设计：
  - 详细设计也称为底层设计，即对结构图进行细化，得到详细的数据结构与算法；
  - 若采用结构化设计，详细设计的任务是为每个模块进行设计；
  - 采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构；
  - 经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）、PDL（伪代码）

软件设计活动

软件设计活动包括4个即独立又相互联系的活动：
- 数据设计：
  - 数据结构对软件质量影响很深远，所以好的数据设计将改善程序结构和模块划分，降低过程复杂度；
  - 数据设计将分析时创建的信息域模型转换成实现软件所需的数据结构
- 软件结构设计：
  - 主要目标是开发一个模块化的程序结构，并表示出模块之间的控制关系
- 人机界面设计（接口设计）
  - 描述软件内部、软件和协作系统之间，以及软件与人之间如何通信；
  - 要实现的内容包括一般交互、信息显示、数据输入
- 过程设计
  - 所有程序都可以建立在一组已有的逻辑构成元素上，这一组逻辑构成元素强调了“对功能域的维护”，其中每个逻辑构成元素有可预测的逻辑结构，很容易理解过程流

结构化设计

结构化设计包括
- 体系结构设计
- 接口设计
- 数据设计
- 过程设计
结构化设计是一种面向数据流的设计方法，是以结构化分析阶段所产生的成果为基础，进一步自顶而下、逐步求精和模块化的过程；
结构化方法中，模块化是一个很重要的概念，是指将一个待开发的软件分解成若干个小的简单部分（模块），使得程序的结构清晰、易于测试和修改
- 模块是指执行某一特定任务的数据结构和程序代码；
- 模块外部特性：模块接口和功能
- 模块内部特性：模块局部数据和实现该模块的程序代码
- 模块设计时，最重要的原则是实现信息隐蔽和模块独立
- 模块设计的特点：
  - 抽象化（过程抽象、数据抽象、控制抽象）
  - 自顶向下，逐步求精
  - 信息隐蔽：
    - 将每个程序的成分隐蔽或封装在一个单一的设计模块中，尽可能少的暴露其内部的处理过程；
    - 可以提高软件的可修改性、可测试性、可移植性
  - 模块独立
    - 每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系最简单；
    - 衡量标准：（目标）高内聚，低耦合
      - 耦合（模块之间联系的紧密程度）
      - 内聚（模块内部各元素之间联系的紧密程度）
模块内聚类型（内聚度从高到低）
- 功能内聚：完成一个单一功能，各个部分协同工作，缺一不可
- 顺序内聚：处理元素相关，而且必须顺序执行
- 通信内聚：所有处理元素集中在一个数据结构的区域上
- 过程内聚：处理元素相关，而且必须按特定的次序执行
- 瞬时内聚：所包含的任务必须在同一时间间隔内执行
- 逻辑内聚：完成逻辑上相关的一组任务
- 偶然内聚：完成一组没有关系或松散关系的任务
模块耦合类型（耦合度从低到高）
- 非直接耦合：没有直接联系，互相不依赖对方
- 数据耦合：借助参数表传递简单数据
- 标记耦合：一个数据结构的一部分借助于模块接口被传递
- 控制耦合：模块间传递的信息中包含用于控制模块内部逻辑的信息
- 外部耦合：与软件以外的环境有关
- 公共耦合：多个模块引用同一全局数据区
- 内容耦合：一个模块访问另一模块的内部数据；一个模块不通过正常入口转到另一模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口
模块分解时需要注意的地方：
- 保持模块的大小适中
- 尽可能减少调用的深度
- 直接调用该模块的次数应该尽量多，但调用其他模块的次数不宜过多；
- 保证模块是单入口、单出口的；
- 模块的作用域应该在模块之内；
- 功能应该是可预测的

工作流设计

工作流：是自动运作的业务过程部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递；简单说，工作流就是一系列相互连接、自动进行的业务活动或任务。

软件质量

软件质量强调三个方面的内容：
- 软件需求是测试软件质量的基础
- 开发标准定义了一组用于指导软件开发方式的准则
- 隐式需求（期望需求）间接定义了用户对某些特性的期望
软件质量属性描述了软件的非功能性属性；
可用性质量属性描述了可用性是系统能够正常运行的时间比例，实现可用性策略的主要方法有错误检测、错误恢复、错误防御；
主动冗余是一种错误恢复的策略；
队列调度是一种提升系统性能的常用方法

软件测试

目前，软件测试的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段；
软件测试的目的是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷；
测试是以评价一个程序或系统属性为目标的任何一种活动；
测试是对软件质量的度量；
软件测试是为发现错误而执行程序的过程
软件测试是为了证明程序有错，而不是证明程序无错误；
一个好的测试用例在于它能发现至今未发现的错误
一个成功的测试是发现至今未发现的错误的测试
软件测试只是软件质量标准的手段之一，不能单凭测试来保证软件质量

测试类型

动态测试：通过运行程序发现错误
- 黑盒法（功能测试/数据驱动测试）
  - 测试人员完全不考虑程序内部结构和处理过程，只是在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求
  - 常用的黑盒测试用例的设计方法有：
    - 等价类划分
    - 边界值分析
    - 错误推测
    - 因果图
- 白盒法（结构测试）
  - 测试人员必须了解程序内部结构和处理过程，已检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检查内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致
  - 被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例；
  - 常用的白盒测试用例设计方法有：
    - 基本路径测试
    - 循环覆盖测试
    - 逻辑覆盖测试（以程序内部逻辑为基础的测试技术）【用发现错误的能力从弱至强的排序】
      - 语句覆盖
      - 判定覆盖
      - 条件覆盖
      - 条件判定覆盖
      - 修正条件判断覆盖
      - 条件组合覆盖
      - 点覆盖
      - 边覆盖
      - 路径覆盖
- 灰盒法
  - 一种介于黑盒和白盒之间的测试，关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整
静态测试（被测试程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进行检测）
- 桌前检查
  - 由程序员自己检查自己编写的程序；
- 代码审查
  - 由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程
- 代码走查
  - 代码走查与代码审查基本相同，但是开会的程序与代码会审不同，不是简单的读程序和对照错误检查表进行检查，而是让与会者充当计算机，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用
使用静态测试的方法也可以实现白盒测试（例如：人工检查代码的方法来检查代码的逻辑问题也属于白盒测试的范畴）

测试阶段

根据测试的目的、阶段的不同，可以把测试分为：
- 单元测试（模块测试）：
  - 是针对软件设计的最小单位（程序模块）进行正确性检验的测试工作，单元测试计划是在软件详细设计阶段完成的；
  - 单元测试通常由开发人员自己负责，常需要借助驱动模块（相当于用于测试模拟的主程序）和桩模块（子模块）来完成；
  - 单元测试一般使用白盒测试方法
- 集成测试（组装测试、联合测试）
  - 将已通过的单元测试的模块集成在一起，主要测试模块之间的协作性；
  - 模块并不是独立的程序，所以再集成测试时需要考虑它和外界的联系，用些辅助模块，这些辅助模块分为
    - 驱动模块：相当于被测模块的主程序
    - 桩模块：用于代替被测模块调用的子模块
  - 可以分为一次性组装和增量式组装（包括自顶向下、自底向上及混合式）
    - 自顶向下进行组装，不需要驱动模块
    - 自底向上进行组装，不需要桩模块
  - 集成测试计划一般在概要设计阶段完成，
  - 集成测试一般采用黑盒测试方法
  - 在每个版本提交时，都需要进行“冒烟”测试，即对程序主要功能进行验证，冒烟测试也被称为版本验证测试或提交测试；
- 确认测试（有效性测试）
  - 主要包括验证软件的功能、性能及其他特性是否与用户要求一致；
  - 确认测试计划通常是在需求分析阶段完成的；
  - 根据用户的参与程度分为4类：
    - 内部确认测试
      - 主要由软件开发组织内部按软件需求说明书进行测试
    - Alpha测试：
      - 由用户在开发环境下进行测试
    - Beta测试：
      - 由用户在实际使用环境下进行测试
    - 验收测试：
      - 针对软件需求说明书，在交付前以用户为主进行测试
- 系统测试
  - 如果项目不只包含软件，还有硬件和网络等，则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列集成与确认测试
  - 系统测试计划一般在系统分析阶段（需求分析阶段）完成
  - 系统测试主要内容：
    - 功能测试
    - 健壮性测试
    - 性能测试
    - 用户界面测试
    - 安全性测试
    - 安装与反安装测试

性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试；
负载测试和压力测试都属于性能测试，两者结合统称负载压力测试
- 负载测试：
  - 通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载增加时，系统各项性能指标的变化情况；
- 压力测试：
  - 通过一个系统的瓶颈或不能接收的性能点，来获得系统能提供的最大服务级别的测试
- 负载压力测试：
  - 是指系统在某种指定软件、硬件及网络环境下承受的流量，例如并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的重要体现；
  - 在网络应用系统中，负载压力测试应重点关注客户端、网络及服务器（包括应用服务器和数据库服务器）的性能
性能测试的目的：
- 验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，并优化软件，最后达到优化系统的目的，具体包括：；
  - 评估系统的能力
  - 识别体系中的弱点
  - 系统调优
  - 检测软件中的问题
  - 验证稳定性和可靠性
性能测试的类型：
- 负载测试：指数据在超负荷环境中运行，程序是否能够承担
- 强度测试：测试系统在异常情况下是否能够运行，或者说是在系统资源特别低的情况下考察软件系统运行情况
- 容量测试：确定系统可处理的同时在线的最大用户数

测试自动化

运用既有的测试工具或开发相应的测试程序进行测试
好处：
- 提高测试执行的速度
- 提高运行效率
- 保证测试结果的准确性
- 连续运行测试脚本
- 模拟现实环境下受约束的情况
引入自动化测试好处很多，但也不能用它解决所有测试问题：
- 它不能将所有测试活动自动完成，需要根据实际需要来决定
- 引入自动化测试只是测试过程规范化的一种必然结果，但若由此减少人力资源意味着测试过程不完整，项目风险会提升，所以不能以此减少人力成本；
- 需要耗费一定的成本；
- 自动化测试结果需要进行分析和评估，不然测试结果没有价值；

软件调试

软件调试用来发现错误产生的原因，解决错误
主要由3个步骤组成：
- 首先确定错误的准确位置
- 然后仔细研究推断代码以确定问题的原因，并设法改正；
- 最后进行回归测试
有3种调试的实现方法：
- 蛮力法
  - 是最普通最低效的方法，当所有其他方法都失败的情形下，才会使用这种方法，也就是人工一点点找；
- 回溯法：
  - 在小程序中经常能够奏效的相当常用的方法；
  - 从发现症状的地方开始，开始（手工的）往回跟踪源代码，直到发现错误的原因
- 原因排除法
  - 通过演绎和归纳，以及二分法来实现，对和错误发生有关的数据进行分析可寻找潜在的原因，然后进行检测来一个个的进行排除

测试设计

软件测试过程包括
- 测试计划
- 测试设计：是整个测试过程中非常重要的一个环节
- 测试执行
- 测试评估
从以下几个方面进行测试设计：
- 用户层
- 应用层
- 功能层
- 子系统层
- 协议层

测试管理

为了保证软件的开发质量，软件测试应贯穿开发的整个过程，因此，要成立专门的测试管理小组对测试进行统一、规范的管理
测试管理组的组成
- 评审小组
- 测试小组
- 支持小组
软件测试管理的目的是确保软件测试技术能在软件项目的整个生命周期内得到顺利实施，并产生预期的效果；
软件测试管理大致分为：
- 测试团队管理
- 测试计划管理
- 错误（缺陷）跟踪管理
- 测试件管理

系统运行和维护

新旧系统的转换策略：
- 直接转换
  - 对原有系统进行抛弃，直接完全重构新系统
  - 优点：
    - 新系统能够非常灵活地适应业务需求、功能齐全、结构合理、系统稳定、扩展性强，整个软件系统的利用率比较高；
  - 缺点
    - 新旧系统转换代价比较大；
    - 开发新系统周期比较长，一次性投资比较大，新系统具有一定的风险
    - 旧系统的业务数据在新系统中的录入、转换、检查、重构等很重要，应尽量减小在新旧系统转换的时候对用户现有业务的冲击
- 逐步转换（分段转换、向导转换、试点过渡法）
  - 部分继承原有系统，部分进行新系统的更新和开发的技术路线；
  - 每成熟一部分新系统软件，就更新一部分旧系统软件，最终采取渐进的方式，过渡到新的软件平台上来；
  - 优点
    - 新旧系统的转换震动比较小，用户容易接受；
  - 缺点：
    - 新旧系统的转换周期较长；
    - 同时由于需求的变化，给新系统的稳定造成比较大影响
  - 在转换过程中，需要开发新旧系统之间的接口、还需要制定阶段性的转换目标和计划
- 并行转换
  - 在一定阶段并行使用新旧系统，将同样的业务在新旧系统中都完成一次，确定新系统稳定后停止旧系统和全面启用新系统
  - 该策略会增加用户的工作量，且难以控制新旧系统中数据变化，因此很少使用；
对于现有信息系统比较稳定，能够适应自身业务发展需要的建设单位、或新旧系统转换风险很大的情况可以采用渐进方式；
对于信息系统本身就存在问题，比如已经不能满足业务需要，存在安全、性能等方面问题的，应采用直接转换策略

遗留系统（遗产系统）的处理策略

遗留系统（遗产系统）：是指没有使用价值，基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统；
遗留系统（遗产系统）具有的特点：
- 系统虽然完成企业中许多重要业务管理工作，但已经不能完全满足要求；
- 系统性能已经落后，采用的技术已经过时
- 系统维护工作十分困难；
- 系统没有使用现代系统工程方法进行管理和开发，现在基本上已经没有文档，很难理解；
遗留系统（遗产系统）的演化策略（由上至下应用价值不断变高）
- 淘汰策略
  - 遗留系统（遗产系统）技术含量较低，且具有较低的商业价值，
  - 全面重新开发新的系统
- 继承策略
  - 遗留系统（遗产系统）技术含量较低，但具有较高的商业价值，目前企业业务尚紧密依赖该系统；
  - 在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型
  - 为了保证业务的连续性，新老系统还需并行运行一段时间，在逐渐切换到新系统上运行；
  - 由于要对遗留系统进行继承需要进行系统分析，若遗留系统维护文档不完整，可以使用有关系统重构的CASE（计算机辅助软件工程）工具，通过分析系统的代码产生出系统结构图或其他报告
- 改造策略
  - 遗留系统的技术含量高，本身还有较大的生命力，且具有较高的商业价值，基本上能够满足企业业务运作和决策支持的要求
  - 改造策略主要是包括两方面
    - 对系统功能的增强
      - 在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变
    - 数据模型的改造
      - 将遗留系统的旧数据模型向新数据模型的转化
- 集成策略
  - 技术含量较高，但其商业价值较低，可能只能完成某个部门（或子公司）的业务管理；
    -这类系统在各自局部领域工作良好，但对于整个企业来说，存在多个这样系统，就将其集成，遗留系统作为从属系统来描述。

软件维护

软件维护是指在使用和运行过程中对软件产品进行的修改；
软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩展和裁剪的容易程度；
目前广泛用来衡量程序可维护性的因素包括可理解性、可测试性、可修改性等
软件维护占整个软件生命周期的60%~80%，主要维护类型有：
- 改正性维护（20%）
  - 对测试阶段未发现、运行阶段发现的错误进行改正；
- 适应性维护（25%）
  - 为了适应环境变化去修改软件
- 完善性维护（50%）
  - 为了满足用户使用过程中提出的新的功能与性能要求，而修改或在开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件可维护性
- 预防性维护（5%）
  - （日常更新的维护）预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好的基础
影响维护工作量的因素主要有
- 系统大小
- 程序设计语言
- 系统年龄
- 数据库技术的应用
- 软件开发技术