软件工程复习笔记.docx

1、软件工程复习笔记CH0 概论本章重点： 软件工程的定义 什么是软件退化 软件与程序的区别 软件工程的组成 客户和用户的定义 常见的软件神话，他们错在何处？ 软件工程的目标有哪些？ 软件工程的目标中最重要的是哪个？ 软件过程是一种层次化的技术，其层次结构是什么样的？ 软件是想改就能改的吗？ 软件开发时是不是越早开始写代码越好1.为什么需要软件工程：个人、企业和政府在日常活动、管理和战略战术决策时越来越依赖于软件，因此必须确保软件的质量；鉴于软件开发成本巨大，因此必须确保开发出来的软件能够满足目标用户的真实要求；随着软件越来越复杂，其开发和实际也越来越复杂，必须确保开发活动的有序、有效；随着软件用

2、户数量和寿命的增加，对其适应性、可扩展性的要求也在增加。必须确保软件具备良好的可维护性。2.软件工程定义最经典的定义：软件工程是对合理工程原则的建立和使用，其目的是为了经济地获得可靠的、可以在实际机器上高效运行的软件。IEEE给出的定义：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护。即将工程化方法应用于软件。课程给出的定义：软件工程是为了经济的开发出高质量的软件，并有效的维护它，将工程、管理手段与技术手段相结合应用于软件的方法的集合目的：经济的开发出高质量的软件，并有效的维护它方法：将工程、管理手段与技术手段相结合3.软件工程要实现多个目标，这些目标之间的重要性不一样价值观问题

3、软件工程的目标如下：又好又快 保证软件质量 提升开发效率、降低开发成本 提高维护效率、降低维护成本4.软件的定义：计算机系统中与硬件相互依存的另一部分，是程序、数据及其相关文档的完整集合。软件是逻辑的而非物理的系统元素。5.软件的特点： 没有物理实体 设计开发成本高昂，生产复制则几乎是零成本的 软件不会磨损、老化，但是也会退化软件退化：随着软件的维护升级，软件结构逐渐偏离原有设计并导致了软件质量的下降，称为软件退化。 软件发展的速度落后于硬件和实际需求 软件占计算机系统成本的比重越来越大 软件开发尚未真正实现标准化6.软件与程序的区别：软件不仅仅只是计算机程序7.软件工程组成：软件工程是一种层

4、次化的技术 质量优先是整个软件工程的核心价值观（以质量为中心） （软件）过程：由为建造、维护高质量软件所需要完成的一系列相互关联的活动组成的框架，即形成软件产品的一系列步骤。过程是软件工程管理和实施的基础。 方法：软件开发和维护过程中一些具体问题的最佳解决手段。方法是软件工程的核心手段 工具：为实现软件工程中各种过程和方法的自动化和半自动化而开发的程序系统。工具是软件工程的效率倍增器。8.软件工程必须重视人员的培训。9.软件工程中的相关人员： 用户User：软件使用者。目的是使用软件解决问题或提高工作效率。 客户Customer：为软件付钱的人。他们的目标是增加利润，或只是使业务运作更为有效。

5、 软件开发人员Developer：开发并维护软件的人。 开发管理人员Manager：管理软件开发过程的人员。其目标是花最少的钱满足客户要求10.软件神话：关于软件及其开发过程的一些错误说法。 神话一：因为软件是由弹性的，因此可以很容易的适应需求变化。（修改软件要付出成本） 神话二：如果我们无法按时完成计划，可以通过增加电脑和程序员人数赶上速度。 神话三：软件过程就是严格按照完成的软件开发标准和规程来开发软件。（错在把手段当成了目的，应该根据项目实际需要，灵活安排实际的软件过程活动） 神话四：当程序编写完成并交付给客户后，任务就完成了，因此应该尽快开始编写代码。 神话五：软件工程会导致我们产生大

6、量无用的文档，因此降低了效率。（创建文档的目的是保证开发软件的质量）文档最重要的作用是（1）促使开发者认真思考和（2）促进交流。CH1 软件过程与方法本章重点： 过程管理的任务 过程的定义 五个核心软件活动 几种软件过程模型，其活动间的顺序关系是怎样的（顺序、迭代、演化还是并行？） 原型及其作用 敏捷开发的价值观 敏捷开发的基本推动力1.过程管理：辨识出一连串的商业活动，并针对这些活动的作业流程进行管理。2.过程管理的目标： 确保企业中各种商业活动的执行成果能具有一定的水平和精确度。 确保能持续改善活动的进行方式，串连活动的作业流程 让企业能保持市场上的竞争力3.过程管理的任务： 寻找、发现企

7、业中有价值的业务过程（过程识别） 发现、去除非增值活动，简化过程；通过合理安排活动顺序提高过程效率（过程梳理和优化） 对过程各个活动进行规范，形成标准（过程固化） 对过程执行情况加以监控（过程监控） 寻找过程中的错误、薄弱、低效环节并加予以纠正（过程改进）4.过程：也称业务过程，指为客户创造价值的一系列相互关联、有组织的活动或任务的集合。 管理学意义上的过程是有明确目的性的：为客户（或企业）创造价值5.（业务）过程的特点： 可确定性：有明确的输入、输出和边界； 顺序：构成过程的活动，必须在时间和空间里具有确定的顺序； 客户：过程的结果必须有接收者客户。 增值：在过程中发生的转换必须为接收者增加

8、价值，无论接收者是在过程的上游还是下游。6.软件过程：构建、维护软件产品时所执行的一系列步骤（活动、动作和任务）的集合。 活动：组成软件过程的最主要的宏观步骤。 例如：需求分析、设计、编码、发布等。 动作：对活动进一步细分的得到的步骤。 例如设计活动，可以细分分为总体设计、模块设计等多个动作。 任务：具体的工作步骤7.核心软件活动：所有合理的软件过程都包含一些共同的必要的活动（步骤），这些活动我们称为核心软件活动。8.软件过程通常包括下列五个核心软件活动： 需求分析：通过与客户的沟通协作，了解客户的真实需要，决定软件特性和功能，制定项目目标。 建模（设计）：通过构造软件模型(通常是图形形式的模

9、型）的方法来研究、理解具体问题，（向客户和其他开发人员）展现具体解决方案。 编码与测试：实际编写代码、验证代码的正确性 运行与部署：将软件交付用户使用。通常用户会对软件进行一段时间的试用，并给出反馈意见 维护：修复用户使用过程中发现的软件缺陷，或者根据用户使用意见对软件进行改进9.在实际软件过程中往往还存在一些贯穿整个过程的普适性活动，以帮助软件团队管理和控制项目进度、质量、变化和风险。项目管理的角度说，这些“普适性活动”实质上是项目管理活动。常见普适性活动包括： 策划：创建软件项目的“地图”，以指导团队的项目旅程。通常包括：需要执行的具体任务、每个任务需要的资源分配，每个任务的具体产品，以及

10、工作计划等 项目跟踪和控制：定期评估项目进度情况，采取必要措施确保项目按期完成 风险管理：对可能影响项目进度和产品质量的风险进行评估，并采取必要措施来降低风险 测量：定义和采集关于过程、项目和产品的度量数据，以帮助管理和改进其他活动。例如：开发人员的生产率等 软件质量保证：确保软件质量的措施和活动 软件配置管理：管理软件（代码、配置信息及其文档）的版本变化历史 可复用管理：建立产品（代码等）复用的机制和标准（如公用函数库等） 人员培训：对相关人员进行必要的培训，使其具备必要的知识和技能，掌握相关工具的使用方法10. 软件过程模型是从一特定角度提出的软件过程的简化描述。过程流（模型）是最主要的一

11、类软件过程模型。过程流描述了如何在执行顺序和执行时间这一层面上，组织软件过程中（除维护之外的）的活动。11.几种主要的过程流及典型过程模型： 线性过程流：瀑布模型 迭代过程流：原型开发模型 演化过程流：螺旋模型 并行过程流 混合过程流：增量模型12.瀑布模型：又称软件生存周期模型，瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。是一种以文档作为驱动的模型 软件生存周期：软件从定义开始，经过开发、使用和维护，直到最终退役的全过程称为软件生存周期

12、。瀑布模型将软件生命周期分成软件定义、软件开发、运行、维护及退役五个时期组成。 优点：可强迫开发人员采用的规范方法；严格规定了每一阶段必须提交的文档；要求每一阶段交付之产品都必须经过质量保证小组的仔细审查；清晰区分了逻辑设计与物理设计，尽可能推迟程序的物理实现；提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。 缺点：要求在项目开始的需求分析阶段就能够完整的得到客户的所有需求，现实中很难实现 客户要到项目接近尾声的验收阶段才能够看到实际的程序执行效果。如果这时才发现程序和客户实际要求有重大偏差，就可能会造

13、成重大的损失13.原型开发模型：原型，就是软件的一个模拟的可执行界面。用户可在原型上进行操作，直观的感受软件的执行效果。原型开发就是软件开发人员根据用户提出的软件基本需求快速开发一个原型，向用户展示软件界面和功能。在征求用户对原型的评价意见后，进一步改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。优点： 原型的开发和评审时系统分析员和用户/客户共同参与的迭代过程，有利于双方充分理解和沟通。 比瀑布模型更符合人们认识事物的过程和规律，项目成员能够更清晰的理解用户实际需求。 如果原型的开发语言和实际软件相同，那么它的若干高质量的程序片段和开发工具也可被用于

14、工作程序的开发。快速原型的开发途径：原型仅仅是需求分析的一部分，因此必须尽可能快速的开发原型。建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见部分，如人机界面、数据的输入方式和输出格式等。缺点： 原型开发模型要求开发者和用户在一段时间内紧密配合、共同参与完成原型系统的开发，特别是需要用户的及时反馈。如果用户对此不够重视，那么原型开发的意义也就大打折扣了。 原型的快速构造容易让用户误以为实际软件的开发也是可以很容易、很快就完成的，或者要求开发者直接将原型稍加修改使之成为实际运行的产品。 而实际上，为了快速开

15、发原型，开发者往往会牺牲软件质量和可维护性而采取了最快速的开发手段，因此实际的高质量软件产品需要抛弃原型从头开发。 如果不能够充分的向客户解释这一点的话，就容易导致软件开发人员和用户之间产生矛盾。 原型开发模型最大的缺点在于，它仍然没有解决需求变化的问题。14.螺旋模型：一种演化式的软件过程模型。结合了原型开发模型的迭代性和瀑布模型的系统性和可控性特点。螺旋模型的每一个迭代周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。螺旋模型是一个风险驱动的模型，每个迭代周期都不应该太长（一般是2-8周左右）螺旋模型优点： 支持用户需求的动态变化 原型可看作形式的可执行的需求规格说明，易于为双

16、方共同理解；开发者和用户共同参与软件开发，可尽早发现软件中的错误。 螺旋模型特别强调原型的可扩充性和可修改性。既保持瀑布模型的系统性、阶段性，又可利用原型评估降低开发风险。 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险 螺旋模型缺点： 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高适用场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法15.增量过程模型：螺旋模型基础上的改进。采用并行方式 解决阻塞带来的浪费问题16.敏捷开发

17、提出的背景：传统过程开发模型都是从管理者的角度来看待软件开发，存在重大缺陷：忽视变化的存在；忽视了软件开发是一个智力密集型的工作；忽视了人与人之间的直接交流；过分注重过程。17.敏捷开发宣言：敏捷开发的价值观 个人与交流 胜于 开发过程和工具 可运行的软件 胜于 面面俱到的文档 客户协作 胜于 合同谈判 响应变化 胜于 按部就班遵循计划18.敏捷的基本推动力：普遍存在的变化19.敏捷鼓励： 使沟通更便利的团队结构和协作态度 快速交付可运行产品而非中间文档 客户以开发团队中的一员的身份参与项目 根据实际情况灵活调整项目计划20.敏捷开发非常强调人的因素在软件项目开发中的重要性敏捷开发强调团队及其

18、成员应该具备下列要素：基本能力、共同目标、精诚合作、决策能力、相互尊重和信任、不断学习、自我组织。21.敏捷过程模型： 极限编程（eXtreme Programming,XP） Scrum 特征驱动开发（FDD） 精益软件开发（LSD） 统一过程（AUP）22.极限编程：XP定义了五个有重要意义的要素： 沟通：强调口头的、面对面的交流 简明：为了简化设计，只对当前的需要做设计。当设计需要改进时，使用重构来实现。 反馈：通过测试、增量交付和持续集成等手段，快速获得反馈 鼓励：鼓励符合极限精神的实践。例如，尽可能减少过度设计。 尊重：敏捷团队应在内部成员之间，以及内部成员与其他利益相关者之间，灌输

19、相互尊重的思想。减少推诿和扯皮，增加协作。23. Scrum是一种迭代式增量软件开发过程冲刺：一个15-30天周期在冲刺的过程中，没有人能够变更冲刺订单24.软件过程领域最新的流行趋势是DevOps，强调开发和运营的密切协作，运营部门在软件的产品设计、开发和测试过程中都要深度介入。DevOps也强调最新工具，如持续集成等自动化工具的使用，以提高工作效率并实现快速反应。25.小结： 需要将软件开发划分为一系列规范化的步骤，使之便于实施和管理。 软件开发需要客户的深入参与和合作 软件开发的主体是人，必须重视人的需求和交流沟通 软件开发过程必须具备高度的灵活性，以适应变化。 总之，软件开发过程在不断

20、引入新的技术和工具的同时，对管理者也提出了越来越高的要求CH2 需求分析概述本章重点： 软件需求的概念 需求分析的目标 功能需求与非功能需求 企业管理各个层级对信息系统的需求主要是什么？企业管理信息系统可分为哪两大模块，各自对应哪个管理层级的需求 需求分析的五个阶段（都做什么）； 需求跟踪与需求状态跟踪各自都做什么？1.导致项目不能按计划完成的最重要的三个原因是： 缺少用户反馈（12.8%） 需求不完整（12.3%） 需求变化（11.8%）软件需求是决定软件开发成败的关键因素2.(软件)需求(Requirement)：为了解决客户的特定问题，软件所必须提供的能力和必须遵从的约束条件。3.需求分

21、析：项目人员确定用户需求所需要做的工作需求分析的目标： 弄清楚客户/用户究竟想用软件来干什么。 弄清楚用户究竟想怎么用。 让客户明确他最终能得到什么样的产品需求分析的成果：软件需求说明书4.需求通常分为功能需求和非功能需求两大类功能需求：描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互。即软件必须提供的能力。 业务需求、用户需求、功能需求、系统需求非功能需求：从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。即软件的约束。非功能需求难以被测试和雁阵；容易被忽视。业务规则、质量属性、外部接口、约束条件5

22、.除非必要，否则需求中不应该包含技术细节6.软件需求的固有困难： 用户不一定清楚的知道他到底想要什么； 软件开发人员不了解项目的业务背景知识； 日常交流所用的语言文字本身具有很大的模糊性； 用户企业不同部门之间需求彼此矛盾； 用户的需求经常会发生变化7.需求工程就是：形式化、工程化的需求分析8.软件需求工程的五个阶段 需求获取：软件开发人员通过与用户之间的有效沟通,了解用户对软件真实需要的过程。本质：开发人员与用户间的沟通目的：了解用户对软件的真实需要需求获取的内容： 客户的战略 相关的业务过程 相关规章制度、业务规则等 相关票据、记录、报表等业务规则:描述业务处理可能遇到的情况及相应的处理措

23、施或约束。需求获取方法：个别访谈、会议、调查、观察 需求分析与协商：对需求获取采集的信息进行汇总、分析，形成详细、规范的需求描述。需要获取的成果最终必须以可见成果的形式描述出来需求描述工具： 用例：一段用文字表述的故事，阐述用户如何使用软件来实现某个具体的业务目标。相关工具：系统范围图/表业务流程图（活动图）用户目标表：用表格形式汇总展现系统所涉及的全部用例及其优先级(用例的目录)用户情况表数据流模型：用图形方式表示数据的输入、输出和加工过程。 需求规约：形成正式需求分析文档的过程软件需求说明书（软件需求规约，SRS）是分析任务的最终产物，是用户和开发者双方对于软件产品要求的正式约定。需求说明

24、书模板： 第一章 目标与范围 1a 项目的整体范围与目标是什么？ 1b 利益相关者（Who cares?） 1c 项目范围内包括什么？什么不在项目范围内？ 第二章 词汇表 第三章 用例 3a 项目的主要参与者与他们的目标 3b 概要级别用例（以主要参与者的视角来分别描述各个主要的业务流程） 3c 用户目标级别用例（具体描述主要参与者如何使用系统来实现他们的目标） 3d 用户目标表 第四章技术要求 第五章其他要求 第六章人工备份、法律、政治与组织问题 需求验证 需求管理：是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动 目的： 保障需求说明书与产品的一致性 控制需求变更对项

25、目开发的影响 使需求活动与计划保持一致 内容：变更控制 版本控制 需求跟踪 需求状态跟踪 需求变更：在软件需求基线已经确定之后又要添加新的需求或进行较大的需求变动。需求变更管理：由专人统一负责接收、评估、审批和实施需求变更请求需求变更管理的目的：确保需求变更的利大于弊 需求跟踪：在软件开发的全过程中，记录和维护每项需求与软件其他系统元素（如设计模块、程序代码、测试用例等等）之间的关系作用：建立与维护“需求其他需求-设计编程测试”之间的一致性方式：正向跟踪、逆向跟踪、双向跟踪目的： 确保所有的工作成果最终符合用户需求。 当需求发生变更时能够快速定位所有被影响的系统元素需求跟踪矩阵（RTM）是表示

26、需求和其他系统元素之间的联系链的一种常用工具需求状态跟踪：在项目整个生命周期中对项目所处状态（即其在当前时刻的情况）进行追踪目的：确保用户提出的每一项需求都得到了妥善的处理工具：单独的需求状态跟踪表；也可合并到需求跟踪矩阵中9.管理层级与信息系统关注：用户使用场景和业务流程关注：绩效指标体系和数据流 还要关注：岗位与权限、数据量10.不能说的秘密：需求分析必须重视利益干系人CH3 需求分析场景分析与用例本章重点： 用例的组成部份及其写法 各用例相关工具的作用 用例图的画法 活动图的画法 基于用例的场景分析1.需求分析的两个最主要的视角： 业务（流程）视角 绩效（信息）视角2.目前的主流是使用以

27、用例为核心的一套方法和工具来描述企业业务用例（Use Case）：一种通过描述用户的使用场景来获取需求的技术。客观（第三者视角）描述使用场景对业务场景中有明确目标的参与者之间的行为描述；用例是利益相关方关于（待开发）系统行为的契约。3.用例的组成 用例名称 动词、动词+宾语结构词组或简短的主谓宾结构短语 能够清晰的反映用例的功能或要实现的目标 参与者及其目标参与者（Actor）是在用例中具有行为或职责的人事物。参与者可能是人，也可能是某个组织（部门、企业），还可能是某个软硬件系统。待分析的系统（SuD）一般不会作为参与者。 主要参与者：SuD的主要服务目标或使用对象。使用SuD实现其目标。 协

28、助参与者：为SuD提供服务的参与者 利益相关者及其关注点间接受用例影响的组织或个人，我们称之为利益相关者。SuD必须确保利益相关者的利益得到了切实的保护 范围与目标级别范围界定了用例中要分析的系统 目标级别：描述用例中主要参与者的目标层级 概要：描述企业业务流程或用户流程的总体步骤，如采购流程、研发流程等（可能跨度很长；可能涉及多个非系统参与者） 用户目标：业务流程中的某一步，在这一步骤中，主要参与者使用待开发系统来实现一个具体的目标。如（超市）用户结账等。 子功能：对用户目标级别用例中的单个步骤的进一步描述，如（超市）用户刷卡付款等。判断： （图书馆管理系统）读者登录 （图书馆管理系统）读者

29、借书 （超市管理系统）用信用卡支付 （超市管理系统）处理退货 （超市管理系统）寻找供货商 （ATM系统）使用ATM取现金 (ATM系统）使用ATM修改密码 (ATM系统）使用ATM办理业务 前置条件：在用例中的场景开始之前，必须保证为真的条件用例中不要出现对前置条件进行检查的步骤可以不写触发条件：导致用例中的场景开始的事件。基本保证：在用例执行后，系统对各利益相关者的利益的最小保证 无论用例最终执行是否成功，系统都必须确保基本保证中的承诺。成功保证：承诺如果用例成功执行完毕，利益相关者的哪些利益将会得到满足（不重复基本保证中的内容） 主成功场景和步骤 扩展描述了用例中的其他所有场景或者场景分支

30、片段 为什么扩展是需求中最容易出问题的部分？ 扩展中主要是各种异常或错误情况的处理。 这往往是业务人员并不熟悉的。 不熟悉就会导致遗漏。 一个只能处理正常情况的系统显然不是一个完善的系统。即使扩展中的异常情况系统最终不处理或无法处理，预先把它写出来，甲乙双方充分讨论，能够避免以后的扯皮 触发条件：对应于主成功场景中的某个步骤的特殊情况。在该步骤中，如果满足该触发条件，则改为执行扩展场景。（注意序号的对应，数字代表步骤，字母代表触发条件） 目标：消除异常或特殊情况，以继续执行主成功场景 场景结束：通常是重新并入主成功场景（缺省情况），或者是中止处理（即处理失败） 其他链接、特殊需求（与用例直接相关的非功能性需求、质量属性或约束）、技术和数据变元表（用户对于系统实现的特殊技术要求）因为用例中避免设计和实现细节、发生频率、优先级、未决问