【无标题】

---

第一章基本概念

1、软件的概念和特点

软件概念定义： 软件=程序+数据+文档
程序：按事先设计的功能和性能需求执行的指令序列数据：是程序能正常操纵信息的数据结构
文档：与程序开发、维护和使用有关的图文材料

软件的特征/特点
① 软件是设计开发的或者是工程化的，不是制造的
② 软件开发时间和工作量难以估计
③ 软件会多次修改
④ 软件的开发进度几乎没有客观衡量标准
⑤ 软件测试非常困难
⑥ 软件不会磨损和老化
⑦ 软件维护易产生新的问题

软件的双重作用：
▪一方面是一种产品，提供计算能力：产生、管理、获取、修改、显示或传输信息
▪另一方面是开发其他软件产品的工具：支持或直接提供系统所需的功能、控制其他程序（如操作系统）、改善通信（如网络软件）、帮助开发其它软件（如软件开发工具）等。

按软件的功能进行划分：
1、系统软件：务服其他于程序的程序
如：操作系统、数据库管理系统、设备驱动程序、通信处理程序等
2、支撑软件：文本编辑程序、文件格式化程序、磁盘向磁带向数据传输的程序、程序库系统、支持需求分析、设计、实现、测试和支持管理的软件
3、应用软件：解决特定需要的独立应用程序。
如：商业数据处理软件、工程与科学计算软件、计算机辅助设计／制造软件、系统仿真软件、智能产品嵌入软 件、医疗制药软件、事务管理、办公自动化软件、计算机辅助教学软件
1、系统软件：务服其他于程序的程序。
2、应用软件：解决特定需要的独立应用程序。
3、工程/科学软件：带数值计算的特征。 4、嵌入式软件。
5、产品线软件：为不同用户使用提供特定功能。 6、web 应用软件。
7、人工智能软件：利用非数值计算解决复杂问题。
按软件规模（参加人员数、研制期限、源程序行数）进行划分：
微型 小型 中型 大型 甚大型 极大型
按软件服务对象的范围划分
项目软件 产品软件

2、软件危机的概念和产生的原因

软件危机的概念:
在计算机软件的开发和维护过程中所遇到的一系列严重问题。(效率和质量问题)项目超出预算、项目超过计划完成时间、软件运行效率很低 、软件质量差、软件通常不符合要求、项目难以管理并且代码难以维护、软件不能交付
产生软件危机的原因
客观：软件本身特点：逻辑部件、规模庞大
主观：不正确的开发方法：忽视需求分析，错误认为软件开发=程序编写，轻视软件维护
消除软件危机的途径
1、软件工程
2、对计算机软件有一个正确的认识：(软件≠程序）
3、必须认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
4、推广使用在实践中总结出来的开发软件的成功技术。开发和使用更好的软件工具。

3、软件工程的定义、三要素和发展过程

IEEE 计算机协会将软件工程定义为：
（1）应用系统化的、规范的、可量化的方法，来开发、运行和维护软件，即将工程化方法应用到软件。
（2）对（1）中各种方法的研究。
**软件工程的目标：**在给定的时间和预算内，按照用户的需求，开发易修改、高效、可靠、可维护、适应力强、可移动、可重用的软件。

**软件工程三要素：**工具、方法、过程
工具：为软件工程的过程和方法提供自动化或半自动化的工具支持。将若干工具集成起来，与软件工程数据库和计算机系统构成一个支持软件 开发的系统称“计算机辅助软件工 程(CASE)”，系统中某一工具的信息加工结果可以作为另一工具的输入。 集成的软件工程工具再加上人的因素构成了软件工程环境。
方法：软件工程方法是完成软件工程项目的技术手段。它支持项目计划和估算、系统和软件需求分析、设计、
编程、测试和维护。软件工程方法依赖一组原则，它贯穿软件工程的各个环节。软件工程方法分两类：结构化方法和面向对象方法。
过程：过程贯穿软件开发的各个环节，在各环节之间建立里程碑；管理者在软件工程过程 中对软件开发的质量、进度、成本进行评估、管理和控制； 技术人员采用相应的方法和工具生成软件工程产品（模型、文档、 数据、报告、表格等）。
软件工程的发展已经历了四个重要阶段：
1.第一代软件工程 — 传统的软件工程
2.第二代软件工程 — 对象工程
3.第三代软件工程 — 过程工程
4.第四代软件工程 — 构件工程
软件工程的 7 个原则：
1、使用阶段性生命周期计划的管理
2、进行连续的验证
3、保证严格的产品控制
4、使用现代编程工具/工程实践
5、保持清晰的责任分配
6、用更好更少的人
7、保持过程改进

---

第二章过程模型

1、软件生命周期概念、软件过程概念、能力成熟度模型 CMM 概念软件生命周期定义：软件产品或软件系统从设计、投入使用到被淘汰的全过程。 什么是软件过程：软件生产的一系列活动，这些活动贯穿于软件开发的整个过程。软件过程都具有以下共同活动：

沟通：该活动包括软件设计者与客户沟通，。
计划：软件开发小组讨论使用何种方法及何种工具来实现客户需求。建模：论选择何种模型来满足需求。不同的需求需要不同的模型。 构造：编码和测试。
部署：软件交付给客户。客户给出建议和反馈，软件实施小组改进软件。

软件过程的三个流派
▪CMU-SEI 的 CMM——能力成熟度模型；
▪ISO 9000 质量标准体系；
▪ISO/IEC 15504（SPICE）——信息技术软件过程评估

成熟度模型标准（CMM）
1初始级，工作无序，缺乏健全的管理制度。

2可重复级，管理制度化，建立了基本的管理制度和规程，初步实现标准化。
3已定义级，过程标准化，工作和管理工作，均已实现标准化、文档化。
4量化管理级，产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。
5优化级，持续的过程改进，拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。

2、常见的软件过程模型：瀑布、增量、原型、螺旋、喷泉等，比较各自优缺点

什么是软件过程模型
软件过程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件过程模型也常称为软件开发模型、软件生存周期模型、软件工程范型。
瀑布模型(Waterfall Model)
·软件开发过程与软件生命周期是一致的，也称经典的生命周期模型。规定了各项软件工程活动，以及它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落。▪ 是一种使用广泛、以文档为驱动的模型。
瀑布模型适用于系统需求明确、技术成熟、工程管理较严格的场合。
传统瀑布模型开发软件的特点：
·阶段间具有顺序性和依赖性。
·推迟实现的观点。
·每个阶段必须完成规定的文档; 每个阶段结束前完成文档审查,及早改正错误。

瀑布模型缺点
·线性过程太理想化
·各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
·由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
·早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。增量过程模型(Incremental Model)
增量模型是一种非整体开发的模型，是一种进化式的开发过程。它允许从部分需求定义出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善。如此反复进行，直至软件人员和用户对所设计的软件系统满意为止。包括增量模型与 RAD。
增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序列，每个确定线性序列都会输出该软件的一个“增量”。增量模型特点
·小而可用的软件
·在前面增量的基础上开发后面的增量
·每个增量的开发可用瀑布或快速原型模型
·迭代的思路
增量模型的优缺点优点：
·不需要提供完整的需求。只要有一个增量包出现，开发就可以进行。
·在项目的初始阶段不需要投入太多的人力资源。
·增量可以有效地管理技术风险。缺点：
每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量。

快速应用开发模型（RAD）

·快速应用开发模型（RAD）是一个增量过程模型，强调短暂的开发周期。
·RAD 模型是瀑布模型的“高速”变体，通过基于组件的构建方法实现快速开发。如果需求以及项目范围得到明确界定，RAD 能使开发团队在很短的时间内（如 60 到 90 天）建立一个“全功能系统”。RAD 模型的缺点
1）对大型项目而言，RAD 需要足够的人力资源。
2）开发者和客户都要实现承诺，否则将导致失败。
3）并非所有系统都适合（不能合理模块化的系统、高性能需求并且要调整构件接口的、技术风险很高的系统均不适合）。

演化过程模型：包括原型模型、螺旋模型
演化模型的思想是首先实现软件的最核心的、最重要的功能

原型模型
适用情况：客户定义一个总体目标集，但不清楚系统的具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。此时，原型法是很好的选择。
缺点: 1)设计者在质量和原型间有所折中 2)客户意识不到一些质量问题

螺旋模型（Spiral Model）
·螺旋模型结合了瀑布模型和原型模型的特点。螺旋模型强调风险管理，因此该模型适用于大型系统的开发。
螺旋模型沿着螺线旋转，在笛卡尔坐标的四个象限上分别表达了四个方面的活动：
·制定计划。确定软件目标，选定实施方案，弄清项目开发的限制条件。
·风险分析。分析所选方案，考虑如何识别和消除风险。
·实施工程。实施软件开发。
·客户评估。评价开发工作，提出修正建议。螺旋模型的优点
·支持用户需求的动态变化。
·原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。

·强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，有助于目标软件的适应能力。
·螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。

螺旋模型的缺点
·如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；
·需要丰富的风险评估经验和专门知识，要求开发队伍水平较高。螺旋模型的适应场合
支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。

喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
优点
·喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
缺点
·由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
基于构件的模型的四个阶段：
·需求：与其它模型相同。
·组件分析：根据需求规格搜索可满足该需求的组件。没有完全匹配的情况，则组件需要加以修改。
·系统设计：该模型是基于重用的。设计者必须考虑到重用的概念，如果没有可重用的组件，还要设计新的软件。
·开发和集成：组件集成到系统中。

基于构件的模型优缺点：
优点：组件的重用，降低了成本和风险，节约了时间
缺点：模型复杂，导致需求的折衷，导致系统不能完全符合需求；无法完全控制所开发系统的演化。

**敏捷开发模型：**一种从 90 年代开始逐渐引起广泛关注的一些新型软件开发方法。
·是基本原理和开发准则的结合。基本原理强调客户满意度和较早的软件增量交付；小但有激情的团队；非正式的方法；最小的软件工程产品；简化整体开发。开发准则强调分析和设计的交付，以及开发者和客户之间积极持续的交流。
·目前的敏捷过程模型主要包括极限编程（XP），自适应软件开发（ASD），动态系统开发方法（DSDM）等。

如何选择过程模型？参考原则
1.在前期需求明确的情况下，尽量采用瀑布模型或改进的瀑布模型。
2.在用户无系统使用经验，需求分析人员技能不足情况下一定要借助原型。
3.在不确定因素很多，很多东西前面无法计划的情况下尽量采用增量迭代和螺旋模型。

4.在需求不稳定的情况下尽量采用增量迭代模型。
5.在资金和成本无法一次到位的情况下可采用增量模型，软件产品多个版本进行发布。
6.对于完成多个独立功能开发可以在需求分析阶段就进行功能并行，但每个功能内部都应该遵循瀑布模型。
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行。
8.对于编码人员经验较少的情况下建议不要采用敏捷或迭代等生命周期模型。
9.增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则。

---

第三章 需求分析

1、需求分析的概念

为什么需要需求分析？
·需求分析的错误和变更导致的软件开发失败，如缺少用户的输入、不完整的需求和规格说明书、需求和规格说明书的变更
·希望对开发进行指导
·希望开发人员对用户的要求理解
·希望用户理解开发人员
·测试部门有理可依

软件需求管理的过程
需求确认：需求获取–>需求提炼–>需求描述–>需求验证需求变更：需求变更需求分析的定义：确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。即需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面

的陈述的一个集合。

需求分析的任务和步骤
·需求分析的任务
建立分析模型 ：准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。编写需求说明 ：用《需求规格说明书》规范的形式准确地表达用户的需求。
·需求分析的步骤
1、需求获取 2、需求提炼 3、需求描述（撰写需求规格说明书） 4、需求验证

2、需求分析的过程：需求确认与需求变更

需求变更管理
·变更管理是将个人、团队和组织从现有状态转移/过渡到期望状态的结构化方法。它授权雇员接受并理解当前业务环境中的变更。在项目管理中，变更管理是指项目变更被引入和接受后的项目管理过程。
·管理和控制需求基线的过程
·需求变更控制系统
一个正式的文档，说明如何控制需求变更建立变更审批系统

3、需求确认的步骤：需求获取→需求提炼→需求描述→需求验证

第一步：需求获取
软件需求获取指的是软件需求的来源以及软件工程师收集这些软件需求的方法。需求类型
（1）功能性需求：为用户和其它系统完成的功能、提供的服务。
（2）非功能需求：必须遵循的标准，外部界面的细节，实现的约束条件，质量属性等等。非功能需求限定了选择解决问题方案的范围，如运行平台、实现技术、编程语言和工具等。
需求获取技术
采访、设定情景（用例）、原型、会议、观察商业过程和工作流需求获取面临的挑战

客户说不清楚需求、需求易变性、问题的复杂性和对问题理解的不完备性与不一致性需求诱导十原则
1、倾听； 2、有准备的沟通； 3、需要有人推动； 4、最好当面沟通； 5、记录所有决定； 6、保持通力协作； 7、聚焦并协调话题； 8、采用图形表示； 9、继续前进原则（认可某件事情，继续前进；如果不认可某件事情，继续前进；如果某项特性或功能不清晰，当时无法澄清，继续前进）； 10、谈判双赢原则。

第二步：需求提炼（需求分析）
定义：对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化，最终形成需求规格说明书。
·需求分析的核心在于建立分析模型。
·需求分析采用多种形式描述需求，通过建立需求的多种视图，揭示出一些更深的问题。
·需求分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要，其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

需求分析模型

第三步：需求规格说明书
软件需求规格说明书（SRS）：软件系统的需求规格说明，是对待开发系统的行为的完整描述。它包含了功能性需求和非功能性需求。
·需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。
·需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

软件需求规格说明的原则
▪从现实中分离功能，即描述要“做什么”而不是“怎样实现”
▪要求使用面向处理的规格说明语言（或称系统定义语言）
▪如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中
▪规格说明必须包括系统运行环境
▪规格说明必须是一个认识模型

▪规格说明必须是可操作的
▪规格说明必须容许不完备性并允许扩充
▪规格说明必须局部化和松散耦合

第四步：需求验证
需求验证的重要性：如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。
对需求文档需执行以下类型的检查：
（1）有效性检查：检查不同用户使用不同功能的有效性。
（2）一致性检查：在文档中，需求之间不应该冲突。
（3）完备性检查：需求文档应该包括所有用户想要的功能和约束。
（4）现实性检查：检查保证能利用现有技术实现需求。

需求验证技术
（1）需求评审（由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。正式会议要有严格的评审程序，要有会议记录，开发组根据缺陷建议修改需求说明并重审。）
（2）利用原型检验系统是否符合用户的真正需要
（3）对每个需求编写概念性的测试用例。
（4）编写用户手册。用浅显易懂的语言描述用户可见的功能。
（5）自动的一致性分析。可用 CASE 工具检验需求模型的一致性。

4、需求分析三类建模：功能模型、数据模型、行为模型。面向过程和面向对象的需分析过程中，三类模型各包含哪些内容？

结构化分析方法
·面向数据流进行需求分析的方法
·结构化分析方法适合于数据处理类型软件的需求分析
·结构化分析方法按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止
·建立模型：数据流图，数据字典，实体联系图，状态变迁图
功能模型——数据流图
数据流图中的主要图形元素：
描述银行取款过程的数据流图:

数据流与数据加工之间的关系

数据流图的层次结构
为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统商店业务系统数据流图绘制步骤
·首先确定系统的输入和输出，画出顶层数据流图，以反映最主要业务处理流程顶层数据流图
第一层数据流图第二层：加细每个加工框
1.销售细化
数据模型——ER 图
实体-联系图(ERD)
·ER 图 是用来建立数据模型的工具。
·数据模型 是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。
·数据模型中包含 3 种相互关联的信息：数据对象（实体）、数据对象的属性及数据对象联系。
(1)数据对象
·数据对象: 对软件必须理解的复合信息的抽象。复合信息: 是指具有一系列不同性质或属性的事物。
(2)属性
·属性定义了数据对象的性质。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。如：学生具有学号、姓名、性别、年龄、专业（其它略）等属性
(3)联系
·数据对象彼此之间相互连接的方式称为联系，也称为关系。
a.一对一联系(1∶1)， b. 一对多联系(1∶N)， c. 多对多联系(M∶N)·联系也可能有属性。
(4)实体-联系图的符号
ER 图中包含了实体(即数据对象)、关系和属性等 3 种基本成分。通常用矩形框代表实体 ；
用连接相关实体的菱形框表示关系；
用椭圆形或圆角矩形表示实体(或关系)的属性；并用直线把实体(或关系)与其属性连接起来。
行为模型——状态变迁图
状态变迁图
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。
1)状 态
·状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
·状态规定了系统对事件的响应方式。
·系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
2)事 件
·事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。
3)符 号
·初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。
·中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下 3 个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。
·状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。
·状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
·事件表达式的语法：事件说明［守卫条件］／动作表达式
·事件说明的语法为：事件名(参数表)
·守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。
·动作表达式是一个过程表达式，当状态转换开始时执行该表达式。
功能模型——用例图
用例做需求分析的特点
▪用例从使用系统的角度描述系统中的信息，即站在系统外部察看系统功能，而不考虑系统内部对该功能的具体实现方式。
▪用例描述了用户提出的一些可见需求，对应一个具体的用户目标。
▪用例是对系统行为的动态描述，属于 UML 的动态建模部分。
▪识别用例时一个常见的错误是：把用例当成是单独的步骤、操作或事务的处理。



用例建模的过程
1确定谁会直接使用该系统。这些都是参与者(Actor)。
2选取其中一个参与者。
3定义该参与者希望系统做什么，参与者希望系统做的每件事成为一个用例。
4对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用例的基本过程。
5描述该用例的基本过程。
6考虑一些可变情况，把他们创建为扩展用例。
7复审不同用例的描述，找出其中的相同点，抽出相同点作为共同的用例。
8重复步骤 2~7 找出每一个用例。
数据模型——类图
类图不仅能够表现信息的结构，还能够反映系统的行为。
·软件开发不同时期的类图反映了不同层次上的抽象。在需求分析阶段，类图用于研究领域的概念，主要反映实体类和界面类；在设计阶段，类图描述类与类之间的接口和控制；在实现阶段，类图描述系统中类的具体实现。
类
·类是包含信息和影响信息行为的逻辑元素。
·包含类的名字，类的属性，类的操作行为。
·寻找类有两种办法：一种是从用例的描述开始，检查用例描述中的每个名词。另一种是检查时序图中的对象，研究对象具有的共同属性和操作来发现类。
属性
·属性是与类相关联的信息，描述该类对象的共同特点。例如，“客户”类有“客户名”、“地址”。
·常见的属性可见性有 Public、Private 和 Protected 三种，分别表示为“+”、“-”和“#”
·属性的类型可以是基本数据类型，例如整数、实数、布尔型、字符串型等，也可以是用户自定义的类型。一般它由所使用的程序设计语言确定。

操作
·操作是与类相关的行为，用于修改、检索类的属性或执行某些动作。
·在类图中，描述类的操作分三个部分：操作名、返回类型和参数表。类间关系
类图中的基本关系包括：关联关系，聚合关系，组合关系，依赖关系，泛化关系等。关联关系
关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象，关联有两元关系和多元关系。
聚合关系
聚合关系指的是整体与部分的关系。在聚合关系中，类 A 是类 B 的一部分，但是类 A 可以独立存在，聚合关系用带空心菱形的直线表示。
组合关系
组合关系也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有共生死的关系。在组合关系中，类 A 包含类 B，而且可以控制类 B 的生命周期。在 UML 中，组合关系用带实心菱形的直线表示。依赖关系
依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物。通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。在 UML 中也可以在其它的事物之间使用依赖关系，如节点之间的关系。依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方

泛化关系
泛化也就是继承关系，也称为“is-a-kind-of”关系，泛化关系描述了超类与子类之间的关系，超类又叫做基类，子类又叫做派生类。在 UML 中，泛化关系用带空心三角形的直线来表示。类的分类
·类的版型可以将类进行分类，并且有助于理解每个类的责任
·分析过程中，可以根据功能将类分为实体类、边界类和控制类。
’·边界类——位于系统与外界的交界处，包括所有的窗体、报表、系统硬件接口、与其它系统的接口。
·实体类——实体类保存要存入永久存储体的信息。
·控制类——控制类负责协调其它类的工作。

分析类图设计类图
行为模型——活动图、时序图、状态图等
时序图
活动图

---

第四章系统设计

1、系统设计分为概要设计和详细设计

**软件设计定义：**软件系统或组件的架构、构件、接口和其他特性的定义过程及该过程的结果。设计指导原则
设计应该是一种架构；设计应该是模块化的；设计应该包含数据、体系结构、接口和组件各个方面，应该设计出系统所用的数据结构，该设计出展现独立功能特性的各组件；设计由软件需求分析过程中获得信息驱动，采用可重复使用的方法导出；设计应该采用正确清楚的表示法。

设计质量属性
功能性、易用性、可靠性、性能、可支持性（可支持性包含扩展性、适应性、可维护性）设计模型分类：数据设计 ，架构设计 ，接口设计 ，组件级设计

2、设计相关的 8 个概念：抽象、体系结构、设计模式、模块化、信息隐藏、功能独立、精化、重构，着重考察体系结构、模块化、信息隐藏、功能独立。体系结构定义：软件的整体结构和这种结构为系统提供概念上完整性的方式

体系结构设计可以使用大量的一种或多种模型来表达 结构模型、框架模型、动态模型、过程模型、功能模型

模块化定义：软件被划分为命名和功能相对独立的多个组件（模块），通过这些组件的集成来满足问题的需求
模块化设计标准
模块化的分解性 ：可分解为子问题 模块化的组合性 ：组装可重用的组件
模块化的可理解性 ：可作为独立单元理解
模块化的连续性 ：需求小变化只影响单个模块模块化的保护 ：模块内异常只影响自身

信息隐藏
模块化基本问题：分解软件系统以达最佳的模块划分
信息隐藏原则：模块应该具有彼此相互隐藏的特性，模块定义和设计时应当保证模块内的信息（过程和数据）不可以被不需要这些信息的其他模块访问
特点
抽象有助于定义构成软件的过程（或信息）实体。
信息隐藏原则定义和隐藏了模块内的过程细节和模块内的本地数据结构。

功能独立定义：每个模块只解决了需求中特定的子功能，并从程序结构的其他部分看该模块具有简单的接口
优点：易于开发：功能被划分，接口被简化，易于维护（和测试）：错误传递减少，模块重用定性衡量标准
内聚性：模块的功能相对强度
耦合性：模块之间的相互依赖程度模块独立性强 = 高内聚低耦合

设计模式定义：在给定上下文环境中一类共同问题的共同解决方案

重构定义：不改变组件功能和行为条件下，简化组件设计（或代码）的一种重组技术
方法：检查现有设计的冗余情况、未使用的设计元素、无效或不必要的算法、较差的构建方式或不恰当的数据结构，或任何其他可更改并导致更好设计的错误

抽象定义：是“忽略具体的信息将不同事物看成相同事物的过程”数据抽象：描述数据对象的冠名数据集合
过程抽象：具有明确和有限功能的指令序列

细化：逐步求精的过程
与抽象的关系：抽象使设计师确定过程和数据，但不局限于底层细节；细化有助于设计者在设计过程中揭示底层细节

3、系统设计从体系结构、数据、接口和组件四方面进行设计。面向过程和面向对象的系统设计，各自包含哪些设计内容？

数据设计：数据设计（有时也被称为数据架构）构建高层抽象（客户/用户的数据视图）的数据模

型、信息模型。

体系结构设计：系统需要执行的函数功能组件集（如数据库、计算模块），组件之间通信、协同和合作的连接器 ，组件集成构成系统的约束 ，设计人员通过分析其组成部分的已知特性理解系统整体特性的语义模型分析
界面设计原则
允许用户操作控制（用户为中心）减少用户记忆负担
保持界面一致

结构化的总体设计方法：
1）首先研究、分析和审查数据流图。 从软件的需求规格说明中弄清数 据流加工的过程，对于发现的问题及时解决。
2）然后根据数据流图决定问题的类型。数据处理问题典型的类型有 两种：变换型和事务型。针对两种不同的类型分别进行分析处理。
3）由数据流图推导出系统的初始结构图。
4）利用一些启发式原则来改进系统的初始结构图，直到得到符合要求的系统结构图为止。
5）修改和补充数据词典。

变换型系统结构图
▪变换型数据处理问题的工作过程大致分为三步，即取得数据，变换数据和给出数据。
▪相应于取得数据、变换数据、给出数据，变换型系统结构图由输入、中心变换和输出等三部分组成。

事务型系统结构图
它接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。在事务型系统结构图中，事务中心模块按所接受的事务的类型，选择某一事务处理模块执行。各事务处理模块并列。每个事务处理模块可能要调用若干个操作模块，而操作模块又可能调用若干个细节模块。

混合结构分析
▪变换分析是软件系统结构设计的主要方法。一般，一个大型的软件系统是变换型结构和事务型结构的混合结构。
所以，我们通常利用以变换分析为主、事务分析为辅的方式进行软件结构设计。

4、掌握流程图和顺序图作法。

流程图的基本结构
1）顺序结构
2）选择结构：二元选择结构（基本结构）、多重选择结构
循环结构：while-do 结构、do-while 结构

面向对象设计的特点
▪面向对象设计强调定义软件对象，并且使这些软件对象相互协作来满足用户需求。
▪面向对象分析和设计的界限是模糊的，从面向对象分析到面向对象设计是一个逐渐扩充模型的过程。分析的结果通过细化直接生成设计结果，在设计过程中逐步加深对需求的理解，从而进一步完善需求分析的结果。
▪分析和设计活动是一个反复迭代的过程。
▪面向对象方法学在概念和表示方法上的一致性，保证了各个开发阶段之间的平滑性。

面向对象设计与结构化设计的过程和方法完全不同，要设计出高质量的软件系统，记住：
•对接口进行设计
•发现变化并且封装它
•先考虑聚合然后考虑继承

强内聚、弱耦合
▪在面向对象设计中，耦合主要指不同对象之间相互关联的程度。如果一个对象过多地依赖于其它对象来完成自己的工作，则不仅使该对象的可理解性下降，而且还会 增加测试、修改的难度，同时降低了类的可重用性和可移植性。
▪对象不可能是完全孤立的，当两个对象必须相互联系时，应该通过类的公共接口实现耦合，不应该依赖于类的具体实现细节。

耦合方式
▪交互耦合——如果对象之间的耦合是通过消息连接来实现的，则这种耦合就是交互耦合。在设

计时应该尽量减少对象之间发送的消息数和消息中的参数个数，降低消息连接的复杂程度。
▪继承耦合——继承耦合是一般化类与特殊化类之间的一种关联形式，设计时应该适当使用这种耦合。在设计时要特别认真分析一般化类与特殊化类之间继承关系，如果抽象层次不合理，可能会造成对特殊化类的修改影响到一般化类，使得系统的稳定性降低。另外，在设计时特殊化类应该尽可能多地继承和使用一般化类的属性和服务，充分利用继承的优势。

可重用性
▪软件重用是从设计阶段开始的，所有的设计工作都是为了使系统完成预期的任务， 为了提高工作效率、减少错误、降低成本，就要充分考虑软件元素的重用性。重用 性有两个方面的含义：
▪尽量使用已有的类，包括开发环境提供的类库和已有的相似的类；
▪如果确实需要创建新类，则在设计这些新类时考虑将来的可重用性。
▪设计一个可重用的软件比设计一个普通软件的代价要高，但是随着这些软件被重用 次数的增加，分摊到它的设计和实现成本就会降低。

框架是一组可用于不同应用的类的集合。框架中的类通常是一些抽象类并且相互有联系，可以通过继承的方式使用这些类。例如，Java 应用程序接口（API）就是一个成功的框架包，为众多的应用提供服务，但一个应用程序通常只需要其中的部分服务，可以采用继承或聚合的方式将应用包与框架包关联在一起来获得需要的服务。 一般不会直接去修改框架的类，而是通过继承或聚合为应用创建合适的 GUI 类。

---

第五章质量保证

1、质量保证的概念

软件质量的定义：明确表示是否符合功能和性能要求，明确地记载开发标准和所有专业开发软件的期望的隐性特点。
关键点：
▪软件需求是软件质量测量的基础
▪缺乏规定的一致性就是缺乏软件的质量
▪制定的标准会定义软件工程发展的标准，它引导着软件工程经理
质量保证的含义：系统地监测和评估一个工程的各个方面，以最大限度地提高正在由生产过程中实现的质量的最低标准。
原则 ：1） “适合用途”：该产品应符合预期的目的 2）“一次成功”：错误应该被淘汰

软件质量保证(SQA) 的含义：监控软件工程以确保软件质量的过程。SQA 涵盖了整个软件开发过程。
SQA 的目标：承诺，能力，Review 活动，测量和验证。

2、测试策略 V 模型概念，测试与开发的各阶段对应关系。

软件测试的定义：在某种指定的条件下对系统或组件操作，观察或记录结果，对系统或组件的某些方面进行评估的过程。分析软件各项目以检测现有的结果和应有结果之间的差异（即软件缺陷），并评估软件各项目的特征的过程。

3、单元测试的内容、集成测试的分类、系统测试的分类、验收测试的分类。①单元测试

▪单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
▪单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
▪单元的内涵

▪单元测试的主要依据
▪单元级测试工具：C++Test，JUnit，NUnit

单元测试的进入条件
•被测代码编译链接通过
•被测代码静态检查工具检查通过
•已完成至少一轮代码检视或走读
•单元测试用例的检视通过
•单元测试代码写完并通过检测

单元测试的退出条件
•所用测试用例执行通过
•单元测试覆盖率达到预定要求
•单元测试未被执行的代码进行 正式审查

单元测试主要内容：模块接口、局部数据结构、边界条件、独立路径、出错处理

②集成测试
▪集成测试就是将软件集成起来后进行测试。又称为子系统测试、组装测试、部件测 试等。
▪集成测试主要可以检查诸如两个模块单独运行正常，但集成起来运行可能出现问题 的情况。
▪集成测试是一种范围很广的测试，当向下细化时，就成为单元测试。

集成测试的主要方法
▪自顶向下的集成方法
▪自底向上的集成方法
▪SMOKE 方法

集成测试用例的设计
▪首先应考虑为通过性测试设计用例，用来验证需求和设计是否得到满足、软件功能是否得到实现。可以考虑等价类分法、场景分析法、状态图法等
▪其次考虑为失效性测试设计用例，主要以已知的缺陷空间为依据设计测试用例。可以考虑边界值法、错误猜测法、因果图法和状态图法等
▪也应强调覆盖率的要求。集成测试的覆盖率有接口覆盖率，接口路径覆盖率等。
▪注意接口有显性和隐性之分。函数调用（API）接口属于显性接口，而消息、网络协议等都属于隐性接口。

③系统测试
▪系统测试是从用户使用的角度来进行的测试，主要工作是将完成了集成测试的系统 放在真实的运行环境下进行测试，用于功能确认和验证。
▪系统测试基本上使用黑盒测试方法
▪系统测试的依据主要是软件需求规格说明

4、回归测试的概念

回归测试
▪在软件测试的各个阶段，在修正发现的软件缺陷或增加新功能时，变化的部分必须进行再测试。此外，对软件进行修改还可能会导致引入新的软件缺陷以及其他问题。 为解决这些问题，需要进行回归测试。
▪回归测试是指有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求。
▪回归测试可以在所有的测试级别执行，并应用于功能和非功能测试中。
▪回归测试应该尽量采用自动化测试。

5、测试技术常见术语的概念：软件缺陷、验证和确认、测试与质量保证、质量与可靠性、调试与测试、测试用例软件缺陷：

•软件未实现产品说明书要求的功能。
•软件出现了产品说明书指明不能出现的错误。
•软件实现了产品说明书未提到的功能。
•软件未实现产品说明书虽未明确提及但应该实现的目标。
•软件难以理解、不易使用、运行缓慢或者——从测试员的角度 看——最终用户会认为不好。

验证和确认：
验证（Verification）：保证软件特定开发阶段的输出已经正确完整地实现了规格说明。
确认（Validation）: 对于每个测试级别，都要检查开发活动的输出是否满足具体的需求或与这些特定级别相关的需求。

测试与质量保证
软件测试人员的目标是尽早找出软件缺陷，并确保缺陷得以修复。
软件质量保证人员的主要职责是创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。

质量与可靠性
▪功能性（functionality）
▪可靠性（reliability）：MTTF(Mean Time To Failure，平均无故障时间)
▪可维护性（maintainability）：MTTR(Mean Time To Repair，平均修复时间)
▪可用性（usability）：MTTF/(MTTF+MTTR)
▪效率（efficiency）
▪可移植性（portability）

软件调试与测试
同：都包含有处理软件缺陷和查看代码的过程
异：• 测试的目标是发现软件缺陷的存在 • 调试的目标是定位与修复缺陷

测试用例
测试用例（test case）是测试输入、执行条件、以及预期结果的集合，是为特定的目的开发的，例如执行特定的程序路径或验证与指定的需求相符合。

6、白盒测试、黑盒测试、静态分析各有哪些方法？

软件测试的主要方法
1）白盒测试：指考虑系统或组件的内部机制的测试形式（如分支测试、 路径测试、语句 测试等），也称结构性测试。
2）黑盒测试：指忽略系统或组件的内部机制，仅关注于那些响应所选择的输入及相应执行条件的输出的测试形式，也称功能性测试。
3）灰盒测试：介于白盒测试与黑盒测试之间的一种测试，多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

白盒测试
此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：
•对程序模块的所有独立的执行路径至少测试一次；
•对所有的逻辑判定，取“真”与取“假” 的两种情况都至少测试一次；
•在循环的边界和运行界限内执行循环体；
•测试内部数据结构的有效性等。

逻辑覆盖是以程序内部的逻辑结构为基础的设计测试 用例的技术。它属白盒测试。
•语句覆盖：设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。
•分支覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。分支覆盖又称为判定覆盖。
•条件覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
•条件组合覆盖：设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。

控制流图覆盖测试是将代码转变为控制流图（CFG），基于其进行测试的技术。它属白盒测试。

节点覆盖即对于图 G 中每个语法上可达的节点，测试用例所执行的测试路径的集合中至少存在一条测试路径访问该节点。显然，节点覆盖和语句覆盖是等价的。
边覆盖即对于图 G 中每一个可到达的长度小于等于 1 的路径，测试用例所执行的测试路径的集合中至少存在一条测试路径游历该路径。显然，边覆盖包含节点覆盖，且边覆盖也可以实现分支覆盖。
路径测试路径覆盖测试就是设计足够的测试用例，覆盖程序中所有可能的路径。每个条件、可执行语句都要测试到。对循环体来说，路径包含的循环次数不同，也算不同的路径，需要分别测试。

黑盒测试
是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能测试或数据驱动测试。
黑盒测试方法：等价类划分、界值分析、状态测试等价类划分方法
▪等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格
说明来设计测试用例。
▪等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。
▪使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。

划分等价类
▪等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的 错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。
▪等价类的划分有两种不同的情况：
▪有效等价类：是指对于程序的规格说明来说，是合理的、有意义的输入数据构成的集合。
▪无效等价类：是指对于程序的规格说明来说，是不合理的、无意义的输入数据构成的集合。
▪在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

边界值分析方法
▪边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。
▪人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上， 而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的 错误。
▪比如，在做三角形计算时，要输入三角形的三个边长：A、B 和 C。 我们应注意到 这三个数值应当满足 A＞ 0、B＞0、C＞0、A＋B＞C、A＋C＞B、B＋C＞A，才能 构成三角形。
▪但如果把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”，那就不 能构成三角形。问题恰出现在容易被疏忽的边界附近。

边界值
▪这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。
▪使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意 值做为测试数据。

状态测试
▪由于在黑盒测试阶段，程序内部的逻辑结构是无从得知的，因此只能通过对状态的测试间接地加以验证。
▪软件状态（software state）是指软件当前所处的条件或者模式。通常，访问所有的状态是可以实现的，但除了极少数简单程序外，不可能以走完所有分支的方式来达到每种状态，即必须选择重要的内容进行测试。

---

第六章软件项目管理

1、项目管理四要素：人员、产品、项目、过程（概念）软件项目管理定义：计划、协调、度量、监控、控制及报告等管理方法在软件开发和维护中的具体应用，以保证整个过程是系统的、有原则的、可量化的。

软件项目管理的四大要素 有效的软件项目管理集中在四个 P：
•人员(People)：关键业务领域：招聘、选拔、绩效管理、培训、薪酬、职业发展、组织和工作设计、团队/文化的发展。
•产品(Product)：在策划一个项目以前，应当建立产品的目标和范围，应考虑其他解决办法，以及技术和管理应当被约束。
•过程(Process)：软件开发的一个全面计划。
•项目(Project)：理解成功项目管理的关键因素，掌握项目计划、监控和控制的一般方法。

人力资源管理成熟度模型（PCMM）：PCMM 是通过对人力资源管理的如人力资源规划、薪酬管理、绩效管理、组织管理、职 业规划、培训管理、知识管理等模块，按初始级、重复级、定义级、定量级和优化级这五个递进层级进行详细描述和分级，建立企业人力资源管理的成熟程度评价模型，以此来对企业目前人力资源管理现状进行评级，寻找不足和差距，以此来明确未来的发展方向。

2、软件度量有哪些方法：生产率估计（基于规模（KLOC）、基于功能点（FP））、工作量度量（算法成本模型、COCOMO 模型）。掌握直接测量（基于规模）方法。

软件度量的定义：一种量化衡量方法,使得人们可以理解和把握软件项目的(生产)效率(或者所需要的劳动量)。

软件度量的目的：
▪描述（项目和过程）
▪评估（状态和质量）
▪预测（为计划）
▪改进（产品质量和过程性能）