软件工程
软件工程
软件工程的基本要素：方法、工具、过程。
生命周期
信息系统的生命周期：
| 系统规划 | 初步调查、分析系统目标、子系统组成、 拟实施方案、可行性研究、制定系统建设方案 |
可行性研究报告、系统设计任务书 |
| 系统分析 | 业务流程分析、数据与数据流程分 析、软件需求分析、网络需求分析 |
系统需求规格说明书、软件需求规格说明书、 确认测试计划、系统测试计划、初步的用户手册 |
| 系统设汁 | 软件架构设计、软件概要设计、 详细设计、网络设计 |
架构设计文档、概要设计说明书、 详细设计说明书、程序规格说明书、 概要测试计划、详细测试计划、 各类设计图 |
| 系统实现 | 设备采购测试、软件编码、 软件单元/集成/系统测试、综合布线 |
源码、单元测试、集成测试报告、操作手册 |
| 系统运行和维护阶段 |
成熟度模型
CMM 能力成熟模型
| 能力等级 | 特 点 | 关键过程区域 |
|---|---|---|
| 初始级 (Initial) |
软件过程的特点是杂乱无章，有时甚至 很混乱，几乎没有明确定义的步骤，项 目的成功完全依赖个人的努力和英雄式 核心人物的作用。 | |
| 可重复级 (Repeatable) |
建立了基本的项目管理过程和实践来跟 踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功 。 | 软件配置管理、软件质量保证、 软件子合同管理、软件项目跟踪 与监督、软件项目策划、软件需 求管理 |
| 已定义 (Defined) |
管理和工程两方面的软件过程已经文档 化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程 来发和维护软件。 | 同行评审、组间协调、软件产品 工程、集成软件管理、培训大纲、 组织过程定义、组织过程集点 |
| 已管理 (Managed) |
制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。 | 软件质量管理和定量过程管理 |
| 优化级 (Optimized) |
加强了定量分析，通过来自过程质量反 馈和来自新观念、新技术的反馈使过程 能不断持续地改进。 | 过程更改管理、技术改革管理和 缺陷预防 |
CMMI
能力成熟度模型集成CMMI是若干过程模型的综合和改进，不仅仅软件，而是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。
| 能力等级 | 特点 | 关键过程区域 | |
|---|---|---|---|
| 初始级 | 过程不可预测且缺乏控制 | 组织的成功依赖于组织内人员的个人 | |
| 已管理级 | 过程为项目服务 | 在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需 | 有目标、有过程。 可重复 |
| 已定义级 | 过程为组织服务 | 在这一等级，企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程，将这套管理体系与流程予以制度化 | 标准化、制度化、文档化 |
| 定量管理 | 过程已度量和控制 | 组织建立了产品质量、服务质量以及过程性能的定量目标。成熟度级别3级与4级的关键区别在于对过程性能的可预测。组织级改革与实施、因果分析和解决方案 | 量化、可预测 |
| 优化级 | 集中于过程改进和优化 |
DCMM
数据管理能力成熟度评估模型
【DCMM的8个核心能力域】定义了数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准和数据生存周期等。
| 成熟度等级 | 描述 |
|---|---|
| 优化级【L5】 | 数据被认为是组织生存和发展的基础，相关管理流程能实时优化， 能在行业内进行最佳实践分享 |
| 量化管理级【L4 | 数据被认为是获取竞争优势的重要资源，数据管理的效率能量化分析和监控 |
| 稳健级【L3】 | 数据当作绩效目标的重要资产，在组织层面制订了标准化管理流程，促进数据管理规范化 |
| 受管理级【L2】 | 组织意识到数据是资产，根据管理策略的要求制订管理流程，有 相关人初步管理 |
| 初始级【L1】 | 数据需求管理是项目级体现，没有统一管理流程，被动式管理 |
软件开发模型
瀑布模型
【特点】
严格区分阶段，每个阶段因果关系紧密相连 （上一阶段的输出作为下一阶段的输入）
只适合需求明确的项目
瀑布模型是一个线性顺序模型，支持直线开发。它假设当线性序列完成之后就能交付一个完善的系统，并没有考虑软件的演化特征。其优点是强调开发的阶段性、早期计划及需求调查和产品测试，以这样严格的方式构造软件，开发人员很清楚每一步应该做什么，有利于项目管理。
【缺点】
- 软件需求的完整性、正确性等很难确定
- 瀑布模型是一个严格串行化的过程模型，很长时间才能看到结果。 需求或设计中的错误往往只有到了项目后期才能够被发现
- 瀑布模型要求每个阶段一次性完全解决该阶段工作，这不现实。
演化模型、原型模型
原型模型主要有以下两个阶段。
原型开发阶段。
目标软件开发阶段。
从原型是否实现功能来分，可分为水平原型和垂直原型两种。
- 水平原型也称为行为 原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是 功能的导航，但并未真实实现功能。水平原型主要用在界面上；
- 垂直原型也称为结构化 原型，实现了部分功能。垂直原型主要用在复杂的算法实现上。
从原型的最终结果来分，出现了抛弃型原型和演化型原型。
- 抛弃型原型是将原型作为需求确认的手段，在需求确认结束后，原型就被抛弃不用，重新采用一个完整的瀑布模型进行开发。
- 演化性原型是在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。原型的概念也被后续出现的过程模型采纳，如螺旋模型和敏捷方法。
特点：
原型法可以使系统开发的周期缩短、成本和风险降低、速度加快，获得较高的综合开发效益。
原型法是以用户为中心来开发系统的，用户参与的程度大大提高，开发的系统符合用户的需求，因而增加了用户的满意度，提高了系统开发的成功率。
由于用户参与了系统开发的全过程，对系统的功能和结构容易理解和接受，有利于系统的移交，有利于系统的运行与维护。
要有一定的开发环境和工具支持、管理水平要求高。
由以上的分析可以看出，原型法的优点主要在于能更有效地确认用户需求。从直观上来看，原型法适用于那些需求不明确的系统开发。
对于分析层面难度大、技术层面难度不大的系统，适合于原型法开发。
V模型
单元测试对应详细设计。也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；
集成测试对应概要设计。在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；
系统测试对应需求分析，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。
验收测试与用户需求对应，是非设计流程。
W 模型
W模型增加了软件各开发阶段中应同步进行的验证和确认活动
W模型由两个V字型模型组成，分别代表测试与开发过程。W模型中测试与开发对应关系如下：
螺旋模型
螺旋模型 （Spiral Model）是在快速原型的基础上扩展而成。 将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。
螺旋模型沿着螺线进行若干次迭代，每次迭代都包括制订计划（目标设定）、风险分析、实施过程和客户评估4 个方面的工作
螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。
快速应用开发 RAD
RAD 模型是瀑布模型的一个高速变种，通过使用基于构件的开发方法获得快速开发 （ 瀑布模型 + 构件 ）
RAD 的开发流程：业务建模， 数据建模、过程建模、应用生成、测试与交付。
RAD 也具有以下局限性：
（1）并非所有应用都适合RAD 。RAD对模块化要求比较高，如果有哪一项功能不能被模块化，那么 RAD 所需要的构件就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得，则 RAD 也有可能不能奏效。
（2）开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导致RAD项目失败。
（3）RAD 只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统要与现有系统有较高的互操作性时，就不适合使用RAD 。
增量模型
首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。
特点：
- 不是从系统整体角度规划各个模块，因此不利于模块划分。
- 难点在于如何将客户需求划分为多个增量。
- 与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品，而原型的构造一般是为了演示。
喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程
智能模型
智能模型也称为基于知识的软件开发模型，它综合了上述若干模型，并把专家系统结合在一起
基于构件的开发模型CBSD
利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。
ＲＵＰ统一过程模型
ＲUP是基于构件的，在为软件系统建模时，ＲUP 使用的是UML
RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。
RUP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，如下：
业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
分析与设计：把需求分析的结果转化为分析与设计模型。
实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
测试：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
部署：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
（非核心工作流）
配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
RUP把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段如下。
构思阶段（初始/初启阶段）：定义最终产品视图和业务模型、确定系统范围。
细化阶段（精化阶段）：设计及确定体系架构、制定工作计划及资源要求。
构造阶段：开发剩余构件和应用程序功能，把这些构件集成为产品，并进行详细测试。
移交阶段：确保软件对最终用户是可用的，进行β测试，制作产品发布版本。
RUP的特点：
- 用例驱动：需求分析、设计、实现和测试等活动都是用例驱动的。
- 以体系结构为中心：包括系统的总体组织和全局控制、通信协议等。是一个多维的结构，会采用多个视图来描述。 也就是典型的4+1视图模型中：
- 迭代与增量。把整个项目开发分为多个迭代过程。在每次选代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程；每次迭代是在己完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。
4 + 1 视图
敏捷模型
极限编程（ XP）
4大价值观：沟通【加强面对面沟通】、简单【不过度设计】、反馈【及时反馈】 、勇气【接受变更的勇气】
功用驱动开发方法（FDD）
FDD 定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。根据项目大小，部分角色可以重复。
编程开发人员分成两类：首席程序员和“类”程序员。
FDD 有5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。
水晶系列方法
其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。
并列争球 （ SCRUM ）
ASD方法： 其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。
动态系统开发方法(DSDM ： 倡导以业务为核心。
开放式源码：程序开发人员在地域上分布很广【其他方法强调集中办公】。
逆向工程
实现级：包括程序的抽象语法树、符号表、过程的设计表示。
结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型、部署图、状态图。
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。
- 重构/重组（restructuring）。重构是指在【同一抽象级别】上转换系统描述形式。
- 设计恢复（design recovery）。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息
- 逆向工程（reverse engineering）：逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
- 正向工程（forward engineering）。正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
- 再工程/重构工程（Re-engineering）。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。
需求工程
需求的分类
需求的层次
- 业务需求：反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
- 用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
- 系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
- 功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
- 非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
- 设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。
质量功能部署
质量功能部署（QFD） 是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD 将软件需求分为三类：
- 常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
- 期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
- 意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性),实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
PIECES框架
PIECES框架是系统非功能性需求分类的技术。
| 概念 | 示例 | |
|---|---|---|
| 性能 ( Performance) | 描述企业当前的运行效率，业务的处理速度。 | 响应时间，吞吐量 |
| 信息 (Information) | 描述业务数据的输入、输出以及处理方面存 在的各种问题。 | 无法捕获数据，或数据不精准 |
| 经济 ( Economics) | 从成本和收益的角度分析企业当前存在的问 题。 | 订单数减少 |
| 控制 ( Control) | 提高信息系统的安全和控制水平。 | 身份鉴别 |
| 效率 ( Efficiency) | 提高企业的人、财、物等的使用效率。 | 浪费时间/材料/资源 |
| 服务 ( Service) | 提高企业对客户、供应商、合作伙伴、顾客 等的服务质量。 | 系统结果不准、使用困难、与其 它系统不兼容 |
需求获取
用户访谈
形式包括结构化和非结构化两种。
- 结构化是指事先准备好一系列问题，有针对性地进行。
- 而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
为了进行有效的用户访谈，系统分析师需要在三个方面进行组织，分别是准备访谈、主持访谈和访谈的后续工作。
| 准备访谈 | 步骤： 1、确定访谈目的。 2、确定访谈哪些用户。 3、准备一些详细的访谈问题【开放式和封闭式相结合】。 4、作出最终的访谈安排。 此 外 ：领域知识培训，充分阅读相关材料。 |
| 访谈过程 | 注意事项： 1、限制访谈时间。 2、寻找异常和错误情况。 3、深入调查细节。 4、认真作好记录。 |
| 访谈的后续工作 | 1、后续工作的首要任务是吸收、理解和记录访谈所获得的信息。 2、当次错过的问题，记录下来，下次再访谈。 |
优缺点
总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围。
但是，也存在着许多困难，
- 用户经常较忙，难以安排时间；
- 面谈时信息量大，记录较为困难；
- 沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。
- 在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。
- 这看似简洁的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。
问卷调查
三个重要活动
- 确定问题及其类型。开放式和封闭式结合问题。问卷调查表的问题必须非常清楚，组织顺序必须有说服力能预见用户可能的回答。
- 编写问题。在具体问题的编写中，要注意使用“用户的语言”，不要使用含糊的词语，但也要避免过度明确的问题，保持问题的简短，避免措辞上的偏向。
- 设计问卷调查表的格式。 对用户重要的问题放在最前面，内容相似的问题放在一起
优点：
与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据
问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；
问卷调查的结果比较好整理和统计
缺点： （ 不灵活）
- 双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息，用户也没有机会立即澄清对问题有含糊或错误的回答。
- 用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。
- 调查表不利于对问题进行展开的回答，无法了解一些细节问题。
- 回答者的数量往往比预期的要少，无法保证用户会回答问题或进一步说明所有问题。
提升问卷返还率
1、向所有的工作人员解释问卷的目的，以及如何填。
2、强调这份问卷哪些人员必须填写。
3、拜托相关领导督促填写并及时返还。
4、 合理设计，尽量减少回答问卷所花费的时间。
5、设置一些奖品或奖励，激励大家及时返还问卷。
采样
采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。
样本大小
样本大小 = α×(可信度系数/可接受的错误)2
其中，α称为启发式因子，一般取值为0.25; 可信度系数表示希望“种群数据包括了样本中的各种情况”有多大的可信度
例如，如果希望订单样本集包含的所有情况具有90 %的可信度，那么样本大小计算如下：
样本大小 = 0.25×(1.65/(l-0.90))2= 68.0625
优点：
- 通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。
- 采样技术使用了数理统计原理，能减少数据收集的偏差。
缺点：
由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。
情节串联板
情节串联板通常就是一系列图片，系统分析师通过这些图片来讲故事。通过以图片辅助讲故事的方式叙述需求，有助于畚效和准确地沟通。
简单地说，情节串联板技术就是使用工具向用户说明（或演示）系统如何适合企业的需要，并表明系统将如何运转。系统分析师将初始的情节串联板展示给讨论小组，小组成员提供意见。
情节串联板应该易于创建和修改，系统分析师不要企图将情节串联板制作得太好，因为情节串联板既不是原型，也不是真实事物的演示。
情节串联板的类型
被动式 （ 草图、图片、屏幕截图、幻灯片 ）、主动式 （ 自动播放 ） 和交互式
制作工具
大致可以分为两大类：静态工具和动态工具。静态工具主要有纸和铅笔、白板、即时贴和PPT等，动态工具主要有Flash、Macromedia Director和其他动画工具
优缺点
由于情节串联板给用户一个直观的演示，因此它是最生动的需求获取技术，其优点是用户友好、交互性强，对用户界面提供了早期的评审。
情节串联板的缺点是花费的时间很多，使需求获取的速度大大降低。
联合需求计划
联合需求计划（JRP） 是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（JAD） 的一部分。用小组工作会议来代替大量独立的访谈。
主要原则
JRP 的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP 时应把握以下主要原则：
( 1 ) 在 JRP 实施之前，应制订详细的议程，并严格遵照议程进行。
( 2 ) 按照既定的时间安排进行。
( 3 ) 尽量完整地记录会议期间的内容。
( 4 ) 在讨论期间尽量避免使用专业术语。
( 5 ) 充分运用解决冲突的技能。
( 6 ) 会议期间应设置充分的间歇时间。
( 7 ) 鼓励团队取得一致意见。
( 8 ) 保证参加JRP的所有人员能够遵守事先约定的规则。
优缺点：
- JRP 是一种相对来说成本较高的需求获取方法
- 用户参与度高
- 需要有较高的 会议的组织和相关人员的能力，要做到言之有物，气氛开放。否则，将难以达到预想的效果
- 当各方对需求不明确，有严重的分歧的时候 。JRP 将会消除分歧，起到群策群力的效果，
速记表
| 方法 | 特点 |
|---|---|
| 收集资料 | 把与系统有关的、对系统开发有益的信息收集起来。 |
| 阅读历史文档 | 对收集数据性的信息较为有用。 |
| 用户访谈 | 1对1-3,有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑。 |
| 问卷调查 | 用户多，无法——访谈，成本低。 |
| 现场观摩 | 针对较为复杂的流程和操作。 |
| 参加业务实践 | 有效地发现问题的本质和寻找解决问题的办法。 |
| 联合需求计划(JRP) | 高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。 |
| 情节串联板【原型前身】 | 一系列图片，通过这些图片来讲故事。 |
| 抽样调查 | 基于数理统计，降低成本，快速获取。 样本大小 = $a*(可信度系数/可接受的错误)^2$ 注：a一般取0.25 |
需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要系统分析师把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作
需求分析的任务
- 绘制系统上下文范围关系图：这种关系图是用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围
- 创建用户界面原型
- 分析需求的可行性
- 确定需求的优先级
- 为需求建立模型： 例如，面向对象分析中的用例模型和领域模型，SA中的DFD 和 E-R图等。
- 创建数据字典
- 使用QFD（质量功能部署）
结构化分析
SA 方法的基本思想是自顶向下，逐层分解
SA 方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中一般使用E-R图表示数据模型，用 DFD 表示功能模型，用状态转换图（STD） 表示行为模型。这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。
数据流图
DFD是SA 方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD 还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD 作为需求规格说明书的一个组成部分。
DFD的主要作用
DFD 从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系 统所完成的功能。具体来说，DFD 的主要作用如下：
- DFD 是理解和表达用户需求的工具，是需求分析的手段。由于DFD 简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD 与用户进行交流。
- DFD 概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
- DFD 作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
DFD 的基本符号
如何画DFD
重点关注，数据流图的平衡原则，如下所示。
- 父图 ( 上层数据流图 ) 与 子图 ( 下层数据流图 ) 平衡。个数一致：两层数据流图中的数据流个数一致。方向一致：两层数据流图中的数据流方向一致。
- 子图内部的平衡。黑洞：加工只有输入没有输出。奇迹：加工只有输出没有输入。灰洞：加工中输入不足以产生输出。每个数据存储必须既有读的数据流，又有写的数据流。但是在某张子图中，可能只有读没有写，或者只有写没有读。
状态转换图
数据字典
数据字典是在DFD 的基础上，对 DFD 中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD 和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。
数据字典的条目
数据字典中一般有6 类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体
面向对象分析
面向对象的概念
封装：是一种信息隐蔽技术，它的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。
消息：对象之间进行通信的一种构造叫做消息
类：一个类定义一组大体上相似的对象，一个类所包含的方法和数据描述 一组对象的共同行为 和属性 。类是对象之上的抽象，对象是类的具体化，是类的实例。
多态：不同对象收到同一消息可以产生完全不同的结果
对象：在面向对象的系统中，对象是基本的运行实体，它既包括数据（属性），也包括作用于数据的操作（行为），所以一个对象把属性和行为封装为一个整体
抽象：通过特定的实例抽取共同特征以后形成概念的过程
继承： 子类复用父类数据和方法的一种机制。
覆盖：在子类中重定义一个与父类同名同参的方法。
函数重载： 一个类可以拥有多个同名但不同参数的函数。
建模
用例模型
建立流程
第一步：识别参与者【参与者：用户、组织、外部系统、时间】
第二步：合并需求获得用例
第三步：细化用例描述
第四步：调整用例模型(可选步骤) 【关系包括：包含关系、扩展关系、泛化关系】
细化用例描述【登录】
用例关系
包含关系【使用关系】：从多个用例中提取公共行为，提取出来的公共用例称为抽象用例，而把原始用例称为基本用例。
扩展关系：一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用例继承了父用例所有的结构、行为和关系。
分析模型
建立流程
第一步：定义概念类
第二步：确定类之间的关系
第三步：为类添加职责
第四步：建立交互图
第五步：分析模型的详细程度问题
概念类
阅读和理解需求文档或用例描述。
筛选出名词或名词短语，建立初始类清单(候选类)。
将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
舍弃明显无意义的类。
- 去除相同含义的
- 去除不属于系统范围内的
- 去除没有特定独立行为的
- 去除含义解释不清楚的
- 去除属于另一个类属性或行为的
小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。
类之间的关系
依赖关系：一个事物发生变化影响另一个事物。 （ 类A 使用了 类 B的方法，他们就是依赖关系 ）
泛化关系：特殊/一般关系。
关联关系：描述了一组链，链是对象之间的连接。
- 聚合关系：整体与部分生命周期不同。
- 组合关系：整体与部分生命周期相同。
实现关系：接口与类之间的关系。
统一建模语言 UML
UML的结构
从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。
构造块。UML有三种基本的构造块，分别是：事物(thing)、关系(relationship)和**图(**diagram)。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
- 结构事物：模型的静态部分，如类、接口、用例、构件等；
- 行为事物：模型的动态部分，如交互、活动、状态机；
- 分组事物：模型的组织部分，如包；
- 注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。
公共机制。公共机制是指达到特定目标的公共UML方法。
- 规格说明：事物语义的细节描述，它是模型真正的核心
- 修饰：通过修饰来表达更多的信息
- 公共分类：类与对象、接口与实现
- 扩展机制：允许添加新的规则
规则。规则是构造块如何放在一起的规定。
- 范围：给一个名字以特定含义的语境
- 可见性：怎样使用或看见名字
- 完整性：事物如何正确、一致地相互联系
- 执行：运行或模拟动态模型的含义是什么
类图
类图(class diagram):类图描述一组类、接口、协作和它们之间的关系。
对象图(object diagram): m )。对象图描述一组对象及它们之间的关系。对象图描 述了在类图中所建立的事物实例的静态快照。
对象图 VS 类图
| 类图 | 对象图 |
|---|---|
 |
 |
| 类具有3个分栏，自上而下依次为名称、属性和操作 | 对象只有两个分栏，自上而下依次为名称、属性 |
| 在类的名称分栏中只有类名 | 对象的名称形式为“对象名:类名“，匿名对象的名称形式为”:类名” |
| 类的属性分栏定义了所有属性的特征 | 对象则只定义了属性的当前值，以便用于测试用例或例子中 |
| 类中列出了操作 | 对象图中不包括操作，因为对于同属于同一个类的对象而言，其操作是相同的 |
| 类使用关联连接，关联使用名称、角色、多重性以及约束等特征定义类代表的是对对象的分类，所以必须说明可以参与关联的对象的数目 | 对象使用链连接、链拥有名称、角色，但是没有多重性。对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重 |