2015《软件工程》主要知识点完整版 by 望远号
（基本上不长的都附上来了，有些整章整节的看书吧…………）
（虽然是我整理手打的不过这个应该不能算原创来着……）
1. 软件的概念P1
计算机软件指计算机系统中的程序及其文档
程序是计算任务的处理对象和处理规则的描述(形式上是source, binary)
文档是为了便于了解程序所需的阐明性资料
2. 软件发展的3个阶段（时间、标志、开发（组织）的方式）P1-P2 （没打完）
第一阶段 1946-1956年
从计算机问世到实用的高级程序语言出现前
第二阶段 1956-1968年
从实用的高级程序语言出现到软件工程出现前
第三阶段 1968年-至今
从软件工程出现到现在
3. 软件的特点 vs 硬件 P2
A 软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确得估算；
B 软件是被开发的或被设计的，没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大；
C 软件的使用没有硬件那样的机械磨损和老化问题。 （下略 在P3）
4. 软件的分类 P3
系统软件：位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。
支持软件：支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。
应用软件：特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。
5. 软件工程的定义
IEEE：软件工程是：
①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；
②在①中所述方法的研究（若考试，必须回答IEEE1993这个定义）
6. 软件生存周期的概念及若干个阶段P6-P7
软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期
• 软件生存周期大体可分为如下几个活动：计算机系统工程、需求分析、设计、编码、测试、运行和维护
A 计算机系统工程的任务是确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，做出进度安排，并进行可行性分析，即从经济、技术、法律等方面分析待开发的软 件是否有可行的解决方案，并在若干个可行的解决方案中做出选择。
B 需求分析主要解决待开发软件要“做什么”的问题，确定软件的功能、性能、数据、界面等要求，生成 软件需求规约。
C 软件设计只要解决待开发软件“怎么做”的问题。软件设计通常可分为系统设计和详细设计。系统设计的任务是设计软件系统的体系结构，包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通 信，同时设计全局数据结构。详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法 等。
D 编码阶段的任务是用某种程序设计语言，将设计的结果转换为可执行的程序代码。
E 测试阶段的任务是发现并纠正软件中的错误和缺陷。测试主要包括单元测试、集成测试、确认测试和系 统测试。
F 软件完成各种测试后就可交付使用，在软件运行期间，需对投入运行的软件进行维护，即可发现了软件 中潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时，对软件进行修改。
7. 瀑布模型 P16
1970年W.Royce提出瀑布模型
• 特征
• 接受上一阶段的结果作为本阶段的输入
• 利用这一输入实施本阶段应完成的活动
• 对本阶段的工作进行评审
• 将本阶段的结果作为输出，传递给下一阶段
• 缺点
• 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发
• 开发早期存在的问题往往要到交付使用时才发现，维护代价大
8. 演化模型 P17
许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功
•可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品
•演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程
•演化模型适用于对软件需求缺乏准确认识的情况
•典型的演化模型有：增量模型、原型模型、螺旋模型
9. 增量模型 P18
增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。
• 增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征
• 增量模型强调每一个增量都发布一个可运行的产品
增量模型特别适用于：
• 需求经常变化的软件开发
• 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发
• 增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术
10. 原型与原型模型 P18
原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型
• 原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型
• 被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发
原型的类型：
• 探索型（exploratory prototyping）
目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性
• 实验型（experimental prototyping）
目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠
• 演化型（evolutionary prototyping）
目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统
原型的使用策略：
• 废弃（throw away）策略
主要用于探索型和实验型原型的开发。这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统
• 追加（add on）策略
主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统
• 原型可作为单独的过程模型使用，它也可作为一种方法或实现技术应用于其它的过程模型中
11. 螺旋模型 P20
B.Boehm于1988年提出
• 是瀑布模型和演化模型的结合，并增加了风险分析
• 螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：
•制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
•风险分析：评价所选的方案，识别风险，消除风险
•工程实施：实施软件开发，验证工作产品
•客户评估：评价开发工作，提出修正建议
螺旋模型出现了一些变种，它可以有3到6个任务区域
• 螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本
• 如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止
• 多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统
================================
12. 组成基于计算机的系统由哪些元素组成 P27
所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合
• 组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程（Procedure）
软件—指计算机程序、数据结构和相关的工作产品，它们被用于实现所需的逻辑方法、规程或控制
硬件—指提供计算能力的电子设备、使能数据流动的互连设备（如网络交换器、电信设备）和提供外部世界功能的电子机械设备（如传感器、马达等）
• 人员—指硬件和软件的用户和操作者
数据库 —指通过软件访问并持久存储的大型的有组织的信息集合
• 文档 —指描绘系统的使用和/或操作的描述性信息（如模型、规格说明、硬复制手册、联机帮助文件、
Web站点）
• 规程（procedures） —指定义每个系统元素或其外部相关流程的具体使用步骤
13. 系统工程的任务 P28
计算机系统工程是一个问题求解的活动，其目的是分析基于计算机的系统的功能、性能、等要求，并把它们分配到基于计算机系统的各个系统元素中，确定它们的约束条件和接口
识别用户的要求
标识系统的功能和性能范围，确定系统的功能、性能、约束和接口
系统建模和模拟
通常可考虑建立如下模型：
• 硬件系统模型：描述基于计算机系统中的硬件（包括计算机、受系统控制的其它硬件设备等）配置、通信协议、拓扑结构、以及确保基于计算机系统的安全性、可靠性、性能等要求的措施
• 软件系统模型：描述各软件子系统的功能、性能等要求，它们在硬件系统中的部署情况，以及软件子系统之间的交互
• 人机接口模型：描述人如何与基于计算机的系统进行交互，包括用户环境、用户的活动、人机交互的语法和语义等
• 数据模型：描述基于计算机的系统使用了哪些数据库管理系统，如果使用多个数据库管理系统，还应描述它们之间的数据转换方式，必要时可给出主要的数据结构
系统模型通常可用图形描述，并加以相应的文字说明必要时，在系统建模后可构造原型，进行系统模拟，以分析所建的模型能否满足整个基于计算机的系统的要求
成本估算及进度安排
对将开发的基于计算机的系统进行成本估算，并作出进度安排
• 可行性分析
从经济、技术、法律等方面分析所给出的解决方案是否可行，通常只有当解决方案可行并有一定的经济效益和/或社会效益时才开始真正的基于计算机的系统的开发
• 生成系统规格说明
（不全 看P29）
14. 可行性分析P29
开发一个基于计算机的系统通常都受到资源（人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成
经济可行性分析
• 经济可行性主要进行成本效益分析，从经济角度，确定系统是否值得开发
• 基于计算机的系统的成本主要包括：
• 购置硬件、软件（如数据库管理系统、第三方开发的构件等）
和设备（如传感器等）的费用
• 系统的开发费用
• 系统安装、运行和维护费用
• 人员培训费用
效益
• 经济效益包括使用基于计算机的系统后可增加的收入和可节省的运行费用（如操作人员数、工作时间、消耗的物资等）。在进行
成本效益分析时通常只统计五年内的经济效益
• 社会效益指使用基于计算机的系统后对社会产生的影响（如提高办事效益，提高用户满意度等），通常社会效益只能定性地估计经济效益通常可用货币的时间价值、投资回收期和纯收入来度量
货币的时间价值
设：当前金额为P，年利率为i，n年后的金额为F，
则
（看书P30）
计算时，累计经济效益应折合成当前金额例如，一个基于计算机的系统使用后，每年产生的经济效益为10万，如果年利率为5%，那么，五年
内该系统的累计经济效益是43．2948万，而不是50万
投资回收期：累计的经济效益正好等于投资数（成本）所需的时间
• 纯收入：累计经济效益 – 投资数
• 当纯收入大于零时，该工程值得投资开发
• 当纯收入小于零时，该工程不值得投资（除非它有明显的社会效益）
• 当纯收入等于零时，通常也不值得投资
显然，纯收入越大越好
技术可行性分析
•技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现
•技术可行性分析通常包括风险分析、资源分析和技术分析
风险分析：分析在给定的约束条件下设计和实现系统的风险
•采用不成熟的技术可能造成技术风险
•人员流动可能给项目带来风险
•成本和人员估算不合理造成的预算风险
风险分析的目的是找出风险，评价风险的大小，并有效地控制和缓解风险
资源分析：论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作环境
例如，有一支开发过类似项目的开发和管理的团队，或者开发人员比较熟悉系统所处的领域，并有足够的人员保证，所需的硬件和支撑软件能通过合法的手段获取，那么从技术角度看，可以认为具备设计和实现系统的条件
技术分析：分析当前的科学技术是否支持系统开发的各项活动
在技术分析过程中，分析员收集系统的性能、可靠性、可维护性和生产率方面的信息，分析实现系统功能、性能所需的技术、方法、算法或过程，从技术角度分析可能存在的风险，以及这些技术问题对成本的影响
技术可行性分析时通常需进行系统建模，必要时可建造原型和进行系统模拟
法律可行性分析
• 研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题
• 我国颁布了《中华人民共和国著作权法》，其中将计算机软件作为著作权法的保护对象。国务院颁布了《计算机软件保护条例》。这两个法律文件是法律可行性分析的主要依据
方案的选择和折衷
• 一个基于计算机的系统可以有多个可行的实现方案，每个方案对成本、时间、人员、技术、设备都有不同的要求，不同方案开发出来的系统在功能、性能方面也会有所不同。因此要在多个可行的实现方案中作出选择
• 方案评估的依据是待开发系统的功能、性能、成本、开发时间、采用的技术、设备、风险以及对开发人员的要求等
• 由于系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约
• 如，为达到高的精度就可能导致长的执行时间，为达到高可靠性就会导致高的成本等等。因此，在必要时应进行折衷
可行性分析的结论
• 可以立即开始进行
• 需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行
• 需要对开发目标进行某些修改之后才能开始进行
• 因为某种原因（如，技术不成熟、经济上不合算等）不能进行
================================
15. 需求工程的概念P33
Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”
• Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理
• Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证
本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。
16. 需求工程的六个阶段 P34
需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段
需求获取
• 系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的任意原型。
• 需求获取的工作产品为进行需求分析提供了基础
需求分析与协商
• 需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。
• 在需求获取阶段，经常出现以下问题：
– 用户提出的要求超出软件系统可以实现的范围或实现能力；
– 不同的用户提出了相互冲突的需求
系统建模
• 建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。
• 常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。
需求规约
• 软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合
适的验收标准，给出对目标软件的各种需求。
• 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。
需求验证
• 作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。
在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。
需求管理
• 需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。
• 换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。
17. 软件需求的定义 P35-36
软件需求是指用户对目标软件系统在功能、行为、性能设计约束等方面的期望。
软件需求包括
• 功能需求
• 性能需求
• 用户或人的因素
• 环境需求
• 界面需求
• 文档需求
• 数据需求
• 资源使用需求
• 安全保密要求
• 可靠性需求
• 软件成本消耗与开发进度需求
• 其他非功能性要求
18. 需求获取的方法与策略 P36-P38
建立顺畅的通信途径
• 建立分析所需要的通信途径，以保证能顺利地对问题进行分析。
访谈与调查
• 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：
– 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；
– 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；
– 提问和回答在汇总后应能够反映用户需求的全貌。
观察用户操作流程
• 到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。
组成联合小组
• 便利的应用规约技术(FacilitatedApplication Specification Techniques ,FAST) ：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调
FAST基本原则
① 在中立的地点举行由开发者和用户出席的会议；
② 建立准备和参与会议的规则；
③ 建议一个足够正式的议程以便可以进行自由的交流；
④ 一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；
⑤ 使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；
⑥ 目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。
（FAST会议流程 P39）
用况（Use Case）
• 当需求作为非正式会议、Fast的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。
• 创建用况模型的主要步骤如下：
1)确定谁会直接使用该系统，即参与者（Actor）
2)选取其中一个参与者
3)定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况
4)对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程
5)描述该用况的基本过程
19. 常用的需求分析方法 P41
– 面向数据流的结构化分析方法(SA)
– 面向数据结构的分析方法
– 面向对象的分析方法 (OOA)
20. 软件的需求规约主要包含哪些内容
（概念P42）
• 引言：陈述软件目标，在基于计算机的系统语境内进行描述。
• 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。
• 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。
• 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。
• 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。
• 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。
• 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。
==================================
21. 软件设计的任务（注意在回答接口设计的时候，需要讲清楚3个方面的内容） P46-47
• 数据/类设计：将分析-类模型变换成类的实现和软件实现所需要的数据结构
• 体系结构设计：体系结构设计定义了软件的整体结构
• 接口设计：接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信
• 部件级设计：部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述
数据/类设计
• 在类和由CRC中定义的数据对象和关系以及数据字典中描述的详细数据内容提供了数据设计活动的基础
• 数据设计的过程包括以下两步 ：
– 首先，为在需求分析阶段所确定的数据对象选择逻辑表示，需要对不同结构进行算法分析，以便选择一个最有效的设计方案；
– 然后，确定对逻辑数据结构所必需的那些操作的程序模块，以便限制或确定各个数据设计决策的影响范围。
体系结构设计
体系结构设计定义了软件的整体结构，它由软件部件、外部可见的属性和它们之间的关系组成。
• 体系结构设计表示可以从系统规约、分析模型和分析模型中定义的子系统的交互导出。
接口设计
• 接口设计主要包括三个方面：
–设计软件模块间的接口
–设计模块和其他非人的信息生产者和消费者(比如外部实体)之间的接口
–设计人(用户)和计算机间的接口
部件级设计
• 部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述。
• 从类为基础的模型、流模型、行为模型中得到的信息是部件设计的基础。
22. 软件设计的目标 P48
在进行软件设计的过程中，我们要密切关注软件的质量因素。
• McGlanghlin 软件设计过程的目标：
1)设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
2)设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。
3)设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。
23. 衡量软件设计的技术标准 P48
1) 设计出来的结构应是分层结构，从而建立软件成份之间的控制。
2) 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。
3) 设计应当既包含数据抽象，也包含过程抽象。
4) 设计应当建立具有独立功能特征的模块。
5) 设计应当建立能够降低模块与外部环境之间复杂连接的接口。
6) 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
24. 软件设计的过程 P48
1) 制定规范
2) 体系结构和接口设计
3) 数据/类设计
4) 部件级（过程）设计
5) 编写设计文档
6) 设计评审
（P48还有一部分）
25. 数据抽象与过程抽象 P49
• 抽象，是在软件设计的规模逐渐增大的情况下，控制复杂性的基本策略。
• 抽象的过程是从特殊到一般的过程，上层概念是下层概念的抽象，下层概念是上层概念的精化和细化。
• 软件工程过程的每一步都是对较高一级抽象的解作一次具体化的描述
• 软件设计中主要抽象手段有：过程抽象和数据抽象
• 过程抽象（也称功能抽象）是指任何一个完成明确定义功能的操作都可被使用者当作单个实体看待，尽管这个操作实际上是由一系列更低级的操作来完成的
• 数据抽象是指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据
26. 模块 P49
• 模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件，实际上是系统分解和抽象的过程。
• 模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问
– 例如，过程。函数、子程序、宏等
（P50有解释）
27. 信息隐藏的概念 p50-p51
• 每个模块的实现细节对于其它模块来说应该是隐蔽的
• 块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用
• 通过信息隐蔽，则可定义和实施对模块的过程细节和局部数据结构的存取限制
28. 内聚与耦合的概念 P51-52
（• 功能独立：功能独立是模块化、抽象、信息隐藏和局部化等概念的直接结果。开发功能专一的且避免与其他模块过多交互的的模块可以实现功能独立。
• 功能独立的重要性
– 功能被分隔且接口被简化使得软件更容易开发
– 由于因修改设计或修改编码引起的副作用被限制，减少了错误扩散，且模块复用成为可能，因而使得软件更易于维护和测试。）
• 功能独立性可以由两项指标来衡量：内聚度与耦合度
• 内聚（cohesion）是一个模块内部各个元素彼此结合的紧密程度的度量
• 一般模块的内聚性分为七种类型
1) 巧合内聚（偶然内聚）：将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称为巧合内聚模块。
2) 逻辑内聚 ：指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能。
3) 时间内聚：指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终止模块。
4) 过程内聚 ：指一个模块完成多个任务，这些任务必须按指定的过程（procedural）执行。
5) 通信内聚 ：指一个模块内所有处理元素都集中在某个数据结构的一块区域中。
6) 顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行。
7) 功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。
• 耦合(coupling)是模块之间的相对独立性（互相连接的紧密程度）的度量
• 一般模块之间可能的耦合方式有七种类型
1) 内容耦合 ：如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另一模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合。
2) 公共耦合 ：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
3) 外部耦合 ：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合。
4) 控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑，则称为控制耦合。
5) 标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构），就是标记耦合。
6) 数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合。
7) 非直接耦合 ：如果两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能独立工作，这种耦合称为非直接耦合。
• 模块之间的连接越紧密，联系越多，耦合性就越高，而其功能独立性就越弱
• 一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高
• 功能独立性比较强的模块应是高内聚低耦合的模块
29. 功能内聚的概念
7) 功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。
30. 数据耦合的概念
6) 数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合。
31. 调用和返回风格的体系结构 P55
• 这种风格使一个软件设计者设计出非常容易修改和扩充的体系结构。
• 包含：主程序/子程序风格体系结构和远程过程调用风格的体系结构
（P55有一堆）
（• 在这里要了解几个概念：
– 程序结构的深度：程序结构的层次数称为结构的深度。结构的深度在一定意义上反映了程序结构的规模和复杂程度。
– 程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度。
– 模块的扇入和扇出：扇出表示一个模块直接调用（或控制）的其它模块数目。扇入则定义为调用（或控制）一个给定模块的模块个数。多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块。）
32. 部件级设计阶段的主要工作 P58
在部件级设计阶段，主要完成如下工作：
1）为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述；
2）确定每一部件内部使用的数据结构；
3）在部件级设计结束时，应该把上述结果写入部件级设计说明书，并且通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。
33. 设计规约主要包含哪些内容 P63
工作范围、
体系结构设计、
数据设计、
接口设计、
各部件的过程设计、
运行设计、
出错处理设计、
安全保密设计、
需求/设计交叉索引、
测试部分、
注解、
附录。
见P63
=======================================
34. 结构化分析与设计（一整章内容）
• 一种面向数据流的传统软件开发方法
• 以数据流为中心构建软件的分析模型和设计模型
• 分为：
– 结构化分析(Structured Analysis 简称SA)
– 结构化设计(Structuresd Design 简称SD)
– 结构化程序设计(Structured Programmin 简称SP)
• 结构化分析方法概述
• 数据流图
• 分层数据流图的审查
• 数据字典
• 描述基本加工的小说明
• 结构化设计概述
• 数据流图到软件体系结构的映射
• 初始结构图的改进
……见第五章
35. 结构化分析模型有哪些
数据字典、数据流图、E-R图、状态转换图
• 数据字典是模型的核心，它包含了软件使用和产生的所有数据的描述
• 数据流图：用于功能建模，描述系统的输入数据流如何经过一系列的加工变换逐步变换成系统的输出数据流,数据流图中的数据流、文件、数据项、加工在数据字典中描述，反映加工逻辑的加工规约用“小说明”描述
• 实体—关系图(E-R图）：用于数据建模，描述数据字典中数据之间的关系，数据对象的属性用“数据对象描述”描述
• 状态转换图：用于行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下系统的状态迁移，控制规约用来描述软件控制方面的附加信息
=========================================
36. 系统响应时间的概念P230
• 系统响应时间指从用户执行某个控制动作（如按回车键或点鼠标）到软件作出响应（期望的输出或动作）的时间。系统响应时间长会使用户感到不安和沮丧。稳定的响应时间（如1秒）比不定的响应时间（如0.1秒到2.5秒）要好。
37. 人机界面设计时的常见问题有哪些P230-231
系统响应时间、用户求助设施、错误信息处理、命令标记（概念见P230-231）
• 系统响应时间
• 关于求助设施，在设计时须考虑如下问题：
1) 在系统交互时，是否总能得到各种系统功能的帮助？是提供部分功能的帮助还是提供全部功能的帮助。
2) 用户怎样请求帮助？使用帮助菜单、特殊功能键还是HELP命令。
3) 怎样表示帮助？在另一个窗口中、指出参考某个文档（不是理想的方法）还是在屏幕特定位置的简单提示。
4) 用户怎样回到正常的交互方式？可做的选择有：屏幕上显示返回键、功能键或控制序列。
5) 怎样构造帮助信息？是平面式（所有信息均通过关键字来访问）、分层式（用户可以进一步查询得到更详细的信息）还是超文本式。
• 交互系统给出的出错消息和警告应具备以下特征：
1) 消息以用户可以理解的术语描述问题。
2) 消息应提供如何从错误中恢复的建议性意见。
3) 消息应指出错误可能导致哪些不良后果（比如破坏数据），以便用户检查是否出现了这些情况或帮助用户进行改正。
4) 消息应伴随着视觉或听觉上的提示，也就是说，显示消息时应该伴随警告声或者消息用闪耀方式，或明显表示错误的颜色显示。
5) 消息应是“非批评性的”（nonjudgmental），即不能指责用户。
· 在提供命令交互方式时，必须考虑以下问题：
1) 每一个菜单选项是否都有对应的命令？
2) 以何种方式提供命令？控制序列（如Alt +P）、功能键还是键入命令。
3) 学习和记忆命令的难度有多大？命令忘了怎么办？
4) 用户是否可以定制和缩写命令？
38. 人机界面设计的黄金原则是什么 P231-232
·让用户拥有控制权
1) 交互模式的定义不能强迫用户进入不必
要的或不希望的动作的方式
2) 提供灵活的交互
3) 允许用户交互可以被中断和撤销
4) 当技能级别增长时可以使交互流水化并
允许定制交互
5) 使用户隔离内部技术细节
·减少用户的记忆负担
1) 减少对短期记忆的要求
2) 建立有意义的缺省
3) 定义直觉性的捷径
4) 界面的视觉布局应该基于真实世界的隐
喻
5) 以不断进展的方式揭示信息
·保存界面一致
1) 允许用户将当前任务放在有意义的语境中
2) 在应用系列内保持一致性
3) 不要改变用户已经熟悉的用户交互模型
39. 可用性与可用性测试
可用性
• 可用性指的是产品的使用效率、易学性和舒适程度。
• 对界面进行可用性测试和评价是确保产品可用性的重要手段，通过各种可用性测试及早发现界面存在的可用性问题，不仅可以节约开发成本，提高产品的品质，还可以降低用户使用产品的心理负荷，减少操作错误，提高工作效率以及对产品的认可度和满意度。
可用性测试是保证产品可用性的重要手段。
• 在进行可用性测试前，设计者需要制订出具体详细的测试计划，包括任务列表、主观满意标准以及所要询问的相关问题。同时，必须确定参与测试的用户数目、类型和来源。
• 可用性测试可以要求用户完成一系列任务，对用户的完成过程进行记录，再对记录进行评审。这可以给设计人员很大的启发，及时发现缺陷并改正。
===================================
40. 标识符命名需要注意的问题 P241
1）这些名字应能反映它所代表的实体，有一定实际意义。
2）名字应先选择精炼意义明确的名字。
3）必要时可缩写，但保持规则一致，并加注释。
4）不用关键字作标示符。
5）同一个名字不要有多个含义。
6）不用相似的名字。
7）避免使用易混淆的字符。如O 和0。
41. 序言性注释
通常置于每个程序模块的开头部分，主要描述：
模块的功能
模块的接口：包括调用格式、参数的解释、该模块需要调用的其它子模块名
重要的局部变量：包括用途、约束和限制条件
开发历史：包括模块的设计者、评审者、评审日期、修改日期以及对修改的描述
42. 书写功能性注释需要主要哪些问题 P242
通常嵌在源程序体内，主要描述程序段的功能。
书写功能性注解时应注意的问题：
注解要正确，错误的注解比没有注解更坏；
为程序段作注解，而不是为每一个语句作注解；
用缩进和空行，使程序与注释容易区分；
注解应提供一些从程序本身难以得到的信息，而不是语句的重复。
43. 编写程序时，对数据说明应该注意哪些问题
为了使程序中数据说明更易于理解和维护，可采用以下风格：
·数据说明的次序应当规范化
数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护
原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定
·说明语句中变量安排有序化
当多个变量名在一个说明语句中说明时，可以将这些变量按字母的顺序排列，以便于查找
·使用注解说明复杂数据结构
如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点
例如用户自定义的数据类型，应当在注释中做必要的补充说明
===============================
44. 测试用例的概念P247
测试用例由测试输入数据和预期结果组成。
45. 测试目的 P247
• Glen Myers给出的软件测试目的：
测试是一个为了发现错误而执行程序的过程
一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例
一个成功的测试是指揭示了迄今为至尚未发现的错误的测试
根据这个测试目的，我们应该排除对测试的错误观点，设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误
46. 白盒测试与黑盒测试的概念P249
（• 测试用例的设计是软件测试的关键所在
• 设计尽可能少的测试用例来发现尽可能多的错误；设计最有可能发现软件错误的测试用例，同时避免使用发现错误效果相同的测试用例（可从成本角度分析为什么这样）
• 测试用例的设计方法大体可分为两类：白盒测试和黑盒测试，也称白箱测试和黑箱测试）
• 白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作
• 黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求
（P249还有）
47. 白盒测试方法及测试用例设计
方法：逻辑覆盖测试、基本路径测试、数据流测试、循环测试
用例覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖
P251开始
48. 黑盒测试方法及测试用例设计
方法：等价类划分、边界值分析、比较测试、错误猜测、因果图
P259开始
49. 各种逻辑覆盖准则以及它们之间的关系
1)语句覆盖：测试程序的每个可执行语句都至少执行一次
2)判断覆盖：判定的每个分支至少经过一次
3)条件覆盖：每个判定中的每个条件的所有可能都至少出现一次
4)判定/条件覆盖：每个判定的所有可能结果都至少执行一次，并且，每个判定中的每个条件的所有可能结果都至少出现一次
5)条件组合覆盖：每个判定中的条件结果的所有可能组合都至少出现一次
6)路径覆盖：每条可能执行到的路径都至少经过一次
50. 基本路径测试 P255
• 在实际问题中，一个不太复杂的程序，特别是包含循环的程序，其路径数可能非常大。因此测试常常难以做到覆盖程序中的所有路径，为此，我们希望把测试的程序路径数压缩到一定的范围内
• 基本路径测试是Tom McCabe提出的一种白盒测试技术，这种方法首先根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例
51. 独立路径的概念 P255
• 独立路径是指程序中至少引进一个新的处理语句序列或一个新条件的任一路径，在流图中，独立路径至少包含一条在定义该路径之前未曾
用到过的边。在基本路径测试时，独立路径的数目就是流图的区域数
52. 测试V模型中四类测试的对象、依据和任务分别是什么
V模型：描述软件开发各阶段与测试策略之间的对应关系（重点！！！！！P267）
单元测试：针对程序中的模块和构件，主要揭露编码阶段产生的错误。
• 单元测试又称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行测试
• 单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误
• 单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试
• 这里将构件或模块统一称为模块
单元测试内容：
• 模块接口：确保模块的输入/输出参数信息是正确的。这些信息包括参数的个数、次序、类型等
• 局部数据结构：确保临时存储的数据在算法执行的整个过程中都能维持其完整性。典型错误有：不合适的类型说明、不同数据类型的比较或赋值、文件打开和关闭的遗漏、超越数据结构的边界等
• 边界条件：确保程序单元在极限或严格的情况下仍能正确地执行
• 所有独立路径：确保模块中的所有语句都至少执行一次。程序执行的路径实际上体现了计算的过程，计算中常见的错误有：不正确的操作优先级、不同类型数据间的操作、不正确的初始化、不精确的精度、不正确的循环中止、不适当地修改循环变量、发散的迭代等
• 所有错误处理路径：单元测试应该对所有的错误处理路径进行测试。错误处理部分潜在的错误有：报错信息没有提供足够的信息来帮助确定错误的性质及其发生的位置、报错信息与真正的错误不一致、错误条件在错误处理之前就已引起系统异常、异常条件处理不正确等
集成测试：针对集成的软件系统，主要揭露设计阶段产生的错误。
• 集成测试 也称组装测试、联合测试
• 经单元测试后，每个模块都能独立工作，但把它们放在一起往往不能正常工作
确认测试：根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。
系统测试：对基于计算机的系统进行测试，揭露不符合系统工程中对软件要求的错误。
（P268开始……一堆）
53. 测试完成的标准
观察测试过程中单位时间内发现错误数目的曲线。
因为无法判定当前查出的错误是否是最后一个错误，所以决定什么时候停止程序测试就成了最困难的问题，但是测试最后一定要停止的
• 几种实用的测试完成标准：
– Musa和Ackerman提出了一个基于统计标准的答复：“不，我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够的测试”
– 使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止
– 观察测试阶段中单位时间内发现错误数目的曲线：
54. 调试的目的及调试过程 P277
• 测试的目的是发现错误，调试（也称排错）的目的是确定错误的原因和准确位置，并加以纠正
调试过程：首先寻找错误的原因和位置，然后
1)找到错误的原因和位置，则将其纠正，并进行回归测试，以确保这一改正未影响其他正常的功能
2)未找到错误的原因和位置，此时应假设错误的原因，并设计测试用例来验证此假设，重复这一过程直至找到错误的原因，并加以改正。
====================================
55. 软件维护的定义 P297
• 什么是软件维护
– 是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程
• 国标GB/T 11457-2006给出如下定义
– 在一软件产品交付使用后对其进行修改，以纠正故障;
– 在一软件产品交付使用后对其进行修改，以纠正故障、改进其性能和其它属性，或使产品适应改变了的环境
56. 纠错性维护
• 纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护
57. 适应性维护
• 适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程
58. 改善性维护
• 改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护
59. 预防性维护
• 预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动
60. 提高可维护性的方法 P304
• 确定质量管理目标和优先级
– 一个可维护的程序应该是可理解的，可修改的和可测试的。但是要实现所有这些目标，需要付出很大的代价。因为有些维护属性之间是相互促进的，例如，可理解性和可测试性，可理解性和可修改性，另外一些属性之间则是相互抵触的。
– 在程序的开发阶段就应保证软件具有可理解性。可修改性和可测试性。在软件开发的每一个阶段都应尽力考虑软件的可维护性。
• 使用提高软件质量的技术与工具
– 在进行软件设计时，采用如本书前面所述的模块化程序设计、结构化程序设计等程序设计方法，在软件开发过程中，采用结构化小组，建立主程序小组，实现严格的组织化管理，职能分工，规范标准，在对程序的质量进行检测时，也可以采用分工合作的方法，这些方法会有效地提高软件质量和检测效率，进而提高软件的可维护性。
• 选择可维护性高的程序设计语言
– 选择较好的程序设计语言对软件维护有很大的影响。低级语言（如：机器代码或汇编语言）程序是一般人很难掌握和理解的，因而很难维护。高级语言比低级语言容易理解，具有更好的可维护性。在高级语言中，一些语言可能比另外一些语言更容易理解。例如，cobol语言比fortran语言更容易理解，因为cobol的变量接近英语；pl/1比cobol更容易理解，因为pl/1有更丰富、更强的语言集等
• 完善程序文档
– 程序文档对提高程序的可理解性有着重要的作用。即使是一个相对简单的程序，要想有效地，迅速对它进行维护，也需要编制文档对它的目的和任务进行解释。而对于程序的维护人员来说，要想对程序编制人员的意图进行重新修改，并对今后可能出现的变化估计，缺少文档的帮助也将很难实现。另一方面，对于程序文档一定要能及时反映程序的变化，否则将对后续维护人员产生误导。
• 进行质量保证审查
– 除了保证软件得到适当的质量外，审查还可以用来检测在开发和维护阶段内发生的质量变化。一旦检测出问题来，就可以采取措施来纠正，以控制不断增长的软件维护成本，延长软件系统的有效生命期。为了保证软件的可维护性，有四种类型的软件审查：在检查点进行复审、验收检查、周期性地维护审查、对软件包进行检查。
（基本上不长的都附上来了，有些整章整节的看书吧…………）
（虽然是我整理手打的不过这个应该不能算原创来着……）
1. 软件的概念P1
计算机软件指计算机系统中的程序及其文档
程序是计算任务的处理对象和处理规则的描述(形式上是source, binary)
文档是为了便于了解程序所需的阐明性资料
2. 软件发展的3个阶段（时间、标志、开发（组织）的方式）P1-P2 （没打完）
第一阶段 1946-1956年
从计算机问世到实用的高级程序语言出现前
第二阶段 1956-1968年
从实用的高级程序语言出现到软件工程出现前
第三阶段 1968年-至今
从软件工程出现到现在
3. 软件的特点 vs 硬件 P2
A 软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确得估算；
B 软件是被开发的或被设计的，没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大；
C 软件的使用没有硬件那样的机械磨损和老化问题。 （下略 在P3）
4. 软件的分类 P3
系统软件：位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。
支持软件：支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。
应用软件：特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。
5. 软件工程的定义
IEEE：软件工程是：
①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；
②在①中所述方法的研究（若考试，必须回答IEEE1993这个定义）
6. 软件生存周期的概念及若干个阶段P6-P7
软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期
• 软件生存周期大体可分为如下几个活动：计算机系统工程、需求分析、设计、编码、测试、运行和维护
A 计算机系统工程的任务是确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，做出进度安排，并进行可行性分析，即从经济、技术、法律等方面分析待开发的软 件是否有可行的解决方案，并在若干个可行的解决方案中做出选择。
B 需求分析主要解决待开发软件要“做什么”的问题，确定软件的功能、性能、数据、界面等要求，生成 软件需求规约。
C 软件设计只要解决待开发软件“怎么做”的问题。软件设计通常可分为系统设计和详细设计。系统设计的任务是设计软件系统的体系结构，包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通 信，同时设计全局数据结构。详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法 等。
D 编码阶段的任务是用某种程序设计语言，将设计的结果转换为可执行的程序代码。
E 测试阶段的任务是发现并纠正软件中的错误和缺陷。测试主要包括单元测试、集成测试、确认测试和系 统测试。
F 软件完成各种测试后就可交付使用，在软件运行期间，需对投入运行的软件进行维护，即可发现了软件 中潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时，对软件进行修改。
7. 瀑布模型 P16
1970年W.Royce提出瀑布模型
• 特征
• 接受上一阶段的结果作为本阶段的输入
• 利用这一输入实施本阶段应完成的活动
• 对本阶段的工作进行评审
• 将本阶段的结果作为输出，传递给下一阶段
• 缺点
• 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发
• 开发早期存在的问题往往要到交付使用时才发现，维护代价大
8. 演化模型 P17
许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功
•可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品
•演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程
•演化模型适用于对软件需求缺乏准确认识的情况
•典型的演化模型有：增量模型、原型模型、螺旋模型
9. 增量模型 P18
增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。
• 增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征
• 增量模型强调每一个增量都发布一个可运行的产品
增量模型特别适用于：
• 需求经常变化的软件开发
• 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发
• 增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术
10. 原型与原型模型 P18
原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型
• 原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型
• 被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发
原型的类型：
• 探索型（exploratory prototyping）
目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性
• 实验型（experimental prototyping）
目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠
• 演化型（evolutionary prototyping）
目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统
原型的使用策略：
• 废弃（throw away）策略
主要用于探索型和实验型原型的开发。这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统
• 追加（add on）策略
主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统
• 原型可作为单独的过程模型使用，它也可作为一种方法或实现技术应用于其它的过程模型中
11. 螺旋模型 P20
B.Boehm于1988年提出
• 是瀑布模型和演化模型的结合，并增加了风险分析
• 螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：
•制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
•风险分析：评价所选的方案，识别风险，消除风险
•工程实施：实施软件开发，验证工作产品
•客户评估：评价开发工作，提出修正建议
螺旋模型出现了一些变种，它可以有3到6个任务区域
• 螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本
• 如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止
• 多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统
================================
12. 组成基于计算机的系统由哪些元素组成 P27
所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合
• 组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程（Procedure）
软件—指计算机程序、数据结构和相关的工作产品，它们被用于实现所需的逻辑方法、规程或控制
硬件—指提供计算能力的电子设备、使能数据流动的互连设备（如网络交换器、电信设备）和提供外部世界功能的电子机械设备（如传感器、马达等）
• 人员—指硬件和软件的用户和操作者
数据库 —指通过软件访问并持久存储的大型的有组织的信息集合
• 文档 —指描绘系统的使用和/或操作的描述性信息（如模型、规格说明、硬复制手册、联机帮助文件、
Web站点）
• 规程（procedures） —指定义每个系统元素或其外部相关流程的具体使用步骤
13. 系统工程的任务 P28
计算机系统工程是一个问题求解的活动，其目的是分析基于计算机的系统的功能、性能、等要求，并把它们分配到基于计算机系统的各个系统元素中，确定它们的约束条件和接口
识别用户的要求
标识系统的功能和性能范围，确定系统的功能、性能、约束和接口
系统建模和模拟
通常可考虑建立如下模型：
• 硬件系统模型：描述基于计算机系统中的硬件（包括计算机、受系统控制的其它硬件设备等）配置、通信协议、拓扑结构、以及确保基于计算机系统的安全性、可靠性、性能等要求的措施
• 软件系统模型：描述各软件子系统的功能、性能等要求，它们在硬件系统中的部署情况，以及软件子系统之间的交互
• 人机接口模型：描述人如何与基于计算机的系统进行交互，包括用户环境、用户的活动、人机交互的语法和语义等
• 数据模型：描述基于计算机的系统使用了哪些数据库管理系统，如果使用多个数据库管理系统，还应描述它们之间的数据转换方式，必要时可给出主要的数据结构
系统模型通常可用图形描述，并加以相应的文字说明必要时，在系统建模后可构造原型，进行系统模拟，以分析所建的模型能否满足整个基于计算机的系统的要求
成本估算及进度安排
对将开发的基于计算机的系统进行成本估算，并作出进度安排
• 可行性分析
从经济、技术、法律等方面分析所给出的解决方案是否可行，通常只有当解决方案可行并有一定的经济效益和/或社会效益时才开始真正的基于计算机的系统的开发
• 生成系统规格说明
（不全 看P29）
14. 可行性分析P29
开发一个基于计算机的系统通常都受到资源（人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成
经济可行性分析
• 经济可行性主要进行成本效益分析，从经济角度，确定系统是否值得开发
• 基于计算机的系统的成本主要包括：
• 购置硬件、软件（如数据库管理系统、第三方开发的构件等）
和设备（如传感器等）的费用
• 系统的开发费用
• 系统安装、运行和维护费用
• 人员培训费用
效益
• 经济效益包括使用基于计算机的系统后可增加的收入和可节省的运行费用（如操作人员数、工作时间、消耗的物资等）。在进行
成本效益分析时通常只统计五年内的经济效益
• 社会效益指使用基于计算机的系统后对社会产生的影响（如提高办事效益，提高用户满意度等），通常社会效益只能定性地估计经济效益通常可用货币的时间价值、投资回收期和纯收入来度量
货币的时间价值
设：当前金额为P，年利率为i，n年后的金额为F，
则
（看书P30）
计算时，累计经济效益应折合成当前金额例如，一个基于计算机的系统使用后，每年产生的经济效益为10万，如果年利率为5%，那么，五年
内该系统的累计经济效益是43．2948万，而不是50万
投资回收期：累计的经济效益正好等于投资数（成本）所需的时间
• 纯收入：累计经济效益 – 投资数
• 当纯收入大于零时，该工程值得投资开发
• 当纯收入小于零时，该工程不值得投资（除非它有明显的社会效益）
• 当纯收入等于零时，通常也不值得投资
显然，纯收入越大越好
技术可行性分析
•技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现
•技术可行性分析通常包括风险分析、资源分析和技术分析
风险分析：分析在给定的约束条件下设计和实现系统的风险
•采用不成熟的技术可能造成技术风险
•人员流动可能给项目带来风险
•成本和人员估算不合理造成的预算风险
风险分析的目的是找出风险，评价风险的大小，并有效地控制和缓解风险
资源分析：论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作环境
例如，有一支开发过类似项目的开发和管理的团队，或者开发人员比较熟悉系统所处的领域，并有足够的人员保证，所需的硬件和支撑软件能通过合法的手段获取，那么从技术角度看，可以认为具备设计和实现系统的条件
技术分析：分析当前的科学技术是否支持系统开发的各项活动
在技术分析过程中，分析员收集系统的性能、可靠性、可维护性和生产率方面的信息，分析实现系统功能、性能所需的技术、方法、算法或过程，从技术角度分析可能存在的风险，以及这些技术问题对成本的影响
技术可行性分析时通常需进行系统建模，必要时可建造原型和进行系统模拟
法律可行性分析
• 研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题
• 我国颁布了《中华人民共和国著作权法》，其中将计算机软件作为著作权法的保护对象。国务院颁布了《计算机软件保护条例》。这两个法律文件是法律可行性分析的主要依据
方案的选择和折衷
• 一个基于计算机的系统可以有多个可行的实现方案，每个方案对成本、时间、人员、技术、设备都有不同的要求，不同方案开发出来的系统在功能、性能方面也会有所不同。因此要在多个可行的实现方案中作出选择
• 方案评估的依据是待开发系统的功能、性能、成本、开发时间、采用的技术、设备、风险以及对开发人员的要求等
• 由于系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约
• 如，为达到高的精度就可能导致长的执行时间，为达到高可靠性就会导致高的成本等等。因此，在必要时应进行折衷
可行性分析的结论
• 可以立即开始进行
• 需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行
• 需要对开发目标进行某些修改之后才能开始进行
• 因为某种原因（如，技术不成熟、经济上不合算等）不能进行
================================
15. 需求工程的概念P33
Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”
• Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理
• Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证
本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。
16. 需求工程的六个阶段 P34
需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段
需求获取
• 系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的任意原型。
• 需求获取的工作产品为进行需求分析提供了基础
需求分析与协商
• 需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。
• 在需求获取阶段，经常出现以下问题：
– 用户提出的要求超出软件系统可以实现的范围或实现能力；
– 不同的用户提出了相互冲突的需求
系统建模
• 建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。
• 常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。
需求规约
• 软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合
适的验收标准，给出对目标软件的各种需求。
• 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。
需求验证
• 作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。
在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。
需求管理
• 需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。
• 换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。
17. 软件需求的定义 P35-36
软件需求是指用户对目标软件系统在功能、行为、性能设计约束等方面的期望。
软件需求包括
• 功能需求
• 性能需求
• 用户或人的因素
• 环境需求
• 界面需求
• 文档需求
• 数据需求
• 资源使用需求
• 安全保密要求
• 可靠性需求
• 软件成本消耗与开发进度需求
• 其他非功能性要求
18. 需求获取的方法与策略 P36-P38
建立顺畅的通信途径
• 建立分析所需要的通信途径，以保证能顺利地对问题进行分析。
访谈与调查
• 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：
– 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；
– 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；
– 提问和回答在汇总后应能够反映用户需求的全貌。
观察用户操作流程
• 到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。
组成联合小组
• 便利的应用规约技术(FacilitatedApplication Specification Techniques ,FAST) ：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调
FAST基本原则
① 在中立的地点举行由开发者和用户出席的会议；
② 建立准备和参与会议的规则；
③ 建议一个足够正式的议程以便可以进行自由的交流；
④ 一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；
⑤ 使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；
⑥ 目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。
（FAST会议流程 P39）
用况（Use Case）
• 当需求作为非正式会议、Fast的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。
• 创建用况模型的主要步骤如下：
1)确定谁会直接使用该系统，即参与者（Actor）
2)选取其中一个参与者
3)定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况
4)对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程
5)描述该用况的基本过程
19. 常用的需求分析方法 P41
– 面向数据流的结构化分析方法(SA)
– 面向数据结构的分析方法
– 面向对象的分析方法 (OOA)
20. 软件的需求规约主要包含哪些内容
（概念P42）
• 引言：陈述软件目标，在基于计算机的系统语境内进行描述。
• 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。
• 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。
• 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。
• 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。
• 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。
• 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。
==================================
21. 软件设计的任务（注意在回答接口设计的时候，需要讲清楚3个方面的内容） P46-47
• 数据/类设计：将分析-类模型变换成类的实现和软件实现所需要的数据结构
• 体系结构设计：体系结构设计定义了软件的整体结构
• 接口设计：接口设计描述了软件内部、软件和协作系统之间以及软件同人之间如何通信
• 部件级设计：部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述
数据/类设计
• 在类和由CRC中定义的数据对象和关系以及数据字典中描述的详细数据内容提供了数据设计活动的基础
• 数据设计的过程包括以下两步 ：
– 首先，为在需求分析阶段所确定的数据对象选择逻辑表示，需要对不同结构进行算法分析，以便选择一个最有效的设计方案；
– 然后，确定对逻辑数据结构所必需的那些操作的程序模块，以便限制或确定各个数据设计决策的影响范围。
体系结构设计
体系结构设计定义了软件的整体结构，它由软件部件、外部可见的属性和它们之间的关系组成。
• 体系结构设计表示可以从系统规约、分析模型和分析模型中定义的子系统的交互导出。
接口设计
• 接口设计主要包括三个方面：
–设计软件模块间的接口
–设计模块和其他非人的信息生产者和消费者(比如外部实体)之间的接口
–设计人(用户)和计算机间的接口
部件级设计
• 部件级设计将软件体系结构的结构性元素变换为对软件部件的过程性描述。
• 从类为基础的模型、流模型、行为模型中得到的信息是部件设计的基础。
22. 软件设计的目标 P48
在进行软件设计的过程中，我们要密切关注软件的质量因素。
• McGlanghlin 软件设计过程的目标：
1)设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
2)设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。
3)设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。
23. 衡量软件设计的技术标准 P48
1) 设计出来的结构应是分层结构，从而建立软件成份之间的控制。
2) 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。
3) 设计应当既包含数据抽象，也包含过程抽象。
4) 设计应当建立具有独立功能特征的模块。
5) 设计应当建立能够降低模块与外部环境之间复杂连接的接口。
6) 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。
24. 软件设计的过程 P48
1) 制定规范
2) 体系结构和接口设计
3) 数据/类设计
4) 部件级（过程）设计
5) 编写设计文档
6) 设计评审
（P48还有一部分）
25. 数据抽象与过程抽象 P49
• 抽象，是在软件设计的规模逐渐增大的情况下，控制复杂性的基本策略。
• 抽象的过程是从特殊到一般的过程，上层概念是下层概念的抽象，下层概念是上层概念的精化和细化。
• 软件工程过程的每一步都是对较高一级抽象的解作一次具体化的描述
• 软件设计中主要抽象手段有：过程抽象和数据抽象
• 过程抽象（也称功能抽象）是指任何一个完成明确定义功能的操作都可被使用者当作单个实体看待，尽管这个操作实际上是由一系列更低级的操作来完成的
• 数据抽象是指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据
26. 模块 P49
• 模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件，实际上是系统分解和抽象的过程。
• 模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问
– 例如，过程。函数、子程序、宏等
（P50有解释）
27. 信息隐藏的概念 p50-p51
• 每个模块的实现细节对于其它模块来说应该是隐蔽的
• 块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用
• 通过信息隐蔽，则可定义和实施对模块的过程细节和局部数据结构的存取限制
28. 内聚与耦合的概念 P51-52
（• 功能独立：功能独立是模块化、抽象、信息隐藏和局部化等概念的直接结果。开发功能专一的且避免与其他模块过多交互的的模块可以实现功能独立。
• 功能独立的重要性
– 功能被分隔且接口被简化使得软件更容易开发
– 由于因修改设计或修改编码引起的副作用被限制，减少了错误扩散，且模块复用成为可能，因而使得软件更易于维护和测试。）
• 功能独立性可以由两项指标来衡量：内聚度与耦合度
• 内聚（cohesion）是一个模块内部各个元素彼此结合的紧密程度的度量
• 一般模块的内聚性分为七种类型
1) 巧合内聚（偶然内聚）：将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称为巧合内聚模块。
2) 逻辑内聚 ：指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能。
3) 时间内聚：指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终止模块。
4) 过程内聚 ：指一个模块完成多个任务，这些任务必须按指定的过程（procedural）执行。
5) 通信内聚 ：指一个模块内所有处理元素都集中在某个数据结构的一块区域中。
6) 顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行。
7) 功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。
• 耦合(coupling)是模块之间的相对独立性（互相连接的紧密程度）的度量
• 一般模块之间可能的耦合方式有七种类型
1) 内容耦合 ：如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另一模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合。
2) 公共耦合 ：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
3) 外部耦合 ：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合。
4) 控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑，则称为控制耦合。
5) 标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构），就是标记耦合。
6) 数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合。
7) 非直接耦合 ：如果两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能独立工作，这种耦合称为非直接耦合。
• 模块之间的连接越紧密，联系越多，耦合性就越高，而其功能独立性就越弱
• 一个模块内部各个元素之间的联系越紧密，则它的内聚性就越高
• 功能独立性比较强的模块应是高内聚低耦合的模块
29. 功能内聚的概念
7) 功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的。
30. 数据耦合的概念
6) 数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合。
31. 调用和返回风格的体系结构 P55
• 这种风格使一个软件设计者设计出非常容易修改和扩充的体系结构。
• 包含：主程序/子程序风格体系结构和远程过程调用风格的体系结构
（P55有一堆）
（• 在这里要了解几个概念：
– 程序结构的深度：程序结构的层次数称为结构的深度。结构的深度在一定意义上反映了程序结构的规模和复杂程度。
– 程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度。
– 模块的扇入和扇出：扇出表示一个模块直接调用（或控制）的其它模块数目。扇入则定义为调用（或控制）一个给定模块的模块个数。多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块。）
32. 部件级设计阶段的主要工作 P58
在部件级设计阶段，主要完成如下工作：
1）为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述；
2）确定每一部件内部使用的数据结构；
3）在部件级设计结束时，应该把上述结果写入部件级设计说明书，并且通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。
33. 设计规约主要包含哪些内容 P63
工作范围、
体系结构设计、
数据设计、
接口设计、
各部件的过程设计、
运行设计、
出错处理设计、
安全保密设计、
需求/设计交叉索引、
测试部分、
注解、
附录。
见P63
=======================================
34. 结构化分析与设计（一整章内容）
• 一种面向数据流的传统软件开发方法
• 以数据流为中心构建软件的分析模型和设计模型
• 分为：
– 结构化分析(Structured Analysis 简称SA)
– 结构化设计(Structuresd Design 简称SD)
– 结构化程序设计(Structured Programmin 简称SP)
• 结构化分析方法概述
• 数据流图
• 分层数据流图的审查
• 数据字典
• 描述基本加工的小说明
• 结构化设计概述
• 数据流图到软件体系结构的映射
• 初始结构图的改进
……见第五章
35. 结构化分析模型有哪些
数据字典、数据流图、E-R图、状态转换图
• 数据字典是模型的核心，它包含了软件使用和产生的所有数据的描述
• 数据流图：用于功能建模，描述系统的输入数据流如何经过一系列的加工变换逐步变换成系统的输出数据流,数据流图中的数据流、文件、数据项、加工在数据字典中描述，反映加工逻辑的加工规约用“小说明”描述
• 实体—关系图(E-R图）：用于数据建模，描述数据字典中数据之间的关系，数据对象的属性用“数据对象描述”描述
• 状态转换图：用于行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下系统的状态迁移，控制规约用来描述软件控制方面的附加信息
=========================================
36. 系统响应时间的概念P230
• 系统响应时间指从用户执行某个控制动作（如按回车键或点鼠标）到软件作出响应（期望的输出或动作）的时间。系统响应时间长会使用户感到不安和沮丧。稳定的响应时间（如1秒）比不定的响应时间（如0.1秒到2.5秒）要好。
37. 人机界面设计时的常见问题有哪些P230-231
系统响应时间、用户求助设施、错误信息处理、命令标记（概念见P230-231）
• 系统响应时间
• 关于求助设施，在设计时须考虑如下问题：
1) 在系统交互时，是否总能得到各种系统功能的帮助？是提供部分功能的帮助还是提供全部功能的帮助。
2) 用户怎样请求帮助？使用帮助菜单、特殊功能键还是HELP命令。
3) 怎样表示帮助？在另一个窗口中、指出参考某个文档（不是理想的方法）还是在屏幕特定位置的简单提示。
4) 用户怎样回到正常的交互方式？可做的选择有：屏幕上显示返回键、功能键或控制序列。
5) 怎样构造帮助信息？是平面式（所有信息均通过关键字来访问）、分层式（用户可以进一步查询得到更详细的信息）还是超文本式。
• 交互系统给出的出错消息和警告应具备以下特征：
1) 消息以用户可以理解的术语描述问题。
2) 消息应提供如何从错误中恢复的建议性意见。
3) 消息应指出错误可能导致哪些不良后果（比如破坏数据），以便用户检查是否出现了这些情况或帮助用户进行改正。
4) 消息应伴随着视觉或听觉上的提示，也就是说，显示消息时应该伴随警告声或者消息用闪耀方式，或明显表示错误的颜色显示。
5) 消息应是“非批评性的”（nonjudgmental），即不能指责用户。
· 在提供命令交互方式时，必须考虑以下问题：
1) 每一个菜单选项是否都有对应的命令？
2) 以何种方式提供命令？控制序列（如Alt +P）、功能键还是键入命令。
3) 学习和记忆命令的难度有多大？命令忘了怎么办？
4) 用户是否可以定制和缩写命令？
38. 人机界面设计的黄金原则是什么 P231-232
·让用户拥有控制权
1) 交互模式的定义不能强迫用户进入不必
要的或不希望的动作的方式
2) 提供灵活的交互
3) 允许用户交互可以被中断和撤销
4) 当技能级别增长时可以使交互流水化并
允许定制交互
5) 使用户隔离内部技术细节
·减少用户的记忆负担
1) 减少对短期记忆的要求
2) 建立有意义的缺省
3) 定义直觉性的捷径
4) 界面的视觉布局应该基于真实世界的隐
喻
5) 以不断进展的方式揭示信息
·保存界面一致
1) 允许用户将当前任务放在有意义的语境中
2) 在应用系列内保持一致性
3) 不要改变用户已经熟悉的用户交互模型
39. 可用性与可用性测试
可用性
• 可用性指的是产品的使用效率、易学性和舒适程度。
• 对界面进行可用性测试和评价是确保产品可用性的重要手段，通过各种可用性测试及早发现界面存在的可用性问题，不仅可以节约开发成本，提高产品的品质，还可以降低用户使用产品的心理负荷，减少操作错误，提高工作效率以及对产品的认可度和满意度。
可用性测试是保证产品可用性的重要手段。
• 在进行可用性测试前，设计者需要制订出具体详细的测试计划，包括任务列表、主观满意标准以及所要询问的相关问题。同时，必须确定参与测试的用户数目、类型和来源。
• 可用性测试可以要求用户完成一系列任务，对用户的完成过程进行记录，再对记录进行评审。这可以给设计人员很大的启发，及时发现缺陷并改正。
===================================
40. 标识符命名需要注意的问题 P241
1）这些名字应能反映它所代表的实体，有一定实际意义。
2）名字应先选择精炼意义明确的名字。
3）必要时可缩写，但保持规则一致，并加注释。
4）不用关键字作标示符。
5）同一个名字不要有多个含义。
6）不用相似的名字。
7）避免使用易混淆的字符。如O 和0。
41. 序言性注释
通常置于每个程序模块的开头部分，主要描述：
模块的功能
模块的接口：包括调用格式、参数的解释、该模块需要调用的其它子模块名
重要的局部变量：包括用途、约束和限制条件
开发历史：包括模块的设计者、评审者、评审日期、修改日期以及对修改的描述
42. 书写功能性注释需要主要哪些问题 P242
通常嵌在源程序体内，主要描述程序段的功能。
书写功能性注解时应注意的问题：
注解要正确，错误的注解比没有注解更坏；
为程序段作注解，而不是为每一个语句作注解；
用缩进和空行，使程序与注释容易区分；
注解应提供一些从程序本身难以得到的信息，而不是语句的重复。
43. 编写程序时，对数据说明应该注意哪些问题
为了使程序中数据说明更易于理解和维护，可采用以下风格：
·数据说明的次序应当规范化
数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护
原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定
·说明语句中变量安排有序化
当多个变量名在一个说明语句中说明时，可以将这些变量按字母的顺序排列，以便于查找
·使用注解说明复杂数据结构
如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点
例如用户自定义的数据类型，应当在注释中做必要的补充说明
===============================
44. 测试用例的概念P247
测试用例由测试输入数据和预期结果组成。
45. 测试目的 P247
• Glen Myers给出的软件测试目的：
测试是一个为了发现错误而执行程序的过程
一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例
一个成功的测试是指揭示了迄今为至尚未发现的错误的测试
根据这个测试目的，我们应该排除对测试的错误观点，设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误
46. 白盒测试与黑盒测试的概念P249
（• 测试用例的设计是软件测试的关键所在
• 设计尽可能少的测试用例来发现尽可能多的错误；设计最有可能发现软件错误的测试用例，同时避免使用发现错误效果相同的测试用例（可从成本角度分析为什么这样）
• 测试用例的设计方法大体可分为两类：白盒测试和黑盒测试，也称白箱测试和黑箱测试）
• 白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作
• 黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求
（P249还有）
47. 白盒测试方法及测试用例设计
方法：逻辑覆盖测试、基本路径测试、数据流测试、循环测试
用例覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖
P251开始
48. 黑盒测试方法及测试用例设计
方法：等价类划分、边界值分析、比较测试、错误猜测、因果图
P259开始
49. 各种逻辑覆盖准则以及它们之间的关系
1)语句覆盖：测试程序的每个可执行语句都至少执行一次
2)判断覆盖：判定的每个分支至少经过一次
3)条件覆盖：每个判定中的每个条件的所有可能都至少出现一次
4)判定/条件覆盖：每个判定的所有可能结果都至少执行一次，并且，每个判定中的每个条件的所有可能结果都至少出现一次
5)条件组合覆盖：每个判定中的条件结果的所有可能组合都至少出现一次
6)路径覆盖：每条可能执行到的路径都至少经过一次
50. 基本路径测试 P255
• 在实际问题中，一个不太复杂的程序，特别是包含循环的程序，其路径数可能非常大。因此测试常常难以做到覆盖程序中的所有路径，为此，我们希望把测试的程序路径数压缩到一定的范围内
• 基本路径测试是Tom McCabe提出的一种白盒测试技术，这种方法首先根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例
51. 独立路径的概念 P255
• 独立路径是指程序中至少引进一个新的处理语句序列或一个新条件的任一路径，在流图中，独立路径至少包含一条在定义该路径之前未曾
用到过的边。在基本路径测试时，独立路径的数目就是流图的区域数
52. 测试V模型中四类测试的对象、依据和任务分别是什么
V模型：描述软件开发各阶段与测试策略之间的对应关系（重点！！！！！P267）
单元测试：针对程序中的模块和构件，主要揭露编码阶段产生的错误。
• 单元测试又称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行测试
• 单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误
• 单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试
• 这里将构件或模块统一称为模块
单元测试内容：
• 模块接口：确保模块的输入/输出参数信息是正确的。这些信息包括参数的个数、次序、类型等
• 局部数据结构：确保临时存储的数据在算法执行的整个过程中都能维持其完整性。典型错误有：不合适的类型说明、不同数据类型的比较或赋值、文件打开和关闭的遗漏、超越数据结构的边界等
• 边界条件：确保程序单元在极限或严格的情况下仍能正确地执行
• 所有独立路径：确保模块中的所有语句都至少执行一次。程序执行的路径实际上体现了计算的过程，计算中常见的错误有：不正确的操作优先级、不同类型数据间的操作、不正确的初始化、不精确的精度、不正确的循环中止、不适当地修改循环变量、发散的迭代等
• 所有错误处理路径：单元测试应该对所有的错误处理路径进行测试。错误处理部分潜在的错误有：报错信息没有提供足够的信息来帮助确定错误的性质及其发生的位置、报错信息与真正的错误不一致、错误条件在错误处理之前就已引起系统异常、异常条件处理不正确等
集成测试：针对集成的软件系统，主要揭露设计阶段产生的错误。
• 集成测试 也称组装测试、联合测试
• 经单元测试后，每个模块都能独立工作，但把它们放在一起往往不能正常工作
确认测试：根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。
系统测试：对基于计算机的系统进行测试，揭露不符合系统工程中对软件要求的错误。
（P268开始……一堆）
53. 测试完成的标准
观察测试过程中单位时间内发现错误数目的曲线。
因为无法判定当前查出的错误是否是最后一个错误，所以决定什么时候停止程序测试就成了最困难的问题，但是测试最后一定要停止的
• 几种实用的测试完成标准：
– Musa和Ackerman提出了一个基于统计标准的答复：“不，我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够的测试”
– 使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止
– 观察测试阶段中单位时间内发现错误数目的曲线：
54. 调试的目的及调试过程 P277
• 测试的目的是发现错误，调试（也称排错）的目的是确定错误的原因和准确位置，并加以纠正
调试过程：首先寻找错误的原因和位置，然后
1)找到错误的原因和位置，则将其纠正，并进行回归测试，以确保这一改正未影响其他正常的功能
2)未找到错误的原因和位置，此时应假设错误的原因，并设计测试用例来验证此假设，重复这一过程直至找到错误的原因，并加以改正。
====================================
55. 软件维护的定义 P297
• 什么是软件维护
– 是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程
• 国标GB/T 11457-2006给出如下定义
– 在一软件产品交付使用后对其进行修改，以纠正故障;
– 在一软件产品交付使用后对其进行修改，以纠正故障、改进其性能和其它属性，或使产品适应改变了的环境
56. 纠错性维护
• 纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护
57. 适应性维护
• 适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程
58. 改善性维护
• 改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护
59. 预防性维护
• 预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动
60. 提高可维护性的方法 P304
• 确定质量管理目标和优先级
– 一个可维护的程序应该是可理解的，可修改的和可测试的。但是要实现所有这些目标，需要付出很大的代价。因为有些维护属性之间是相互促进的，例如，可理解性和可测试性，可理解性和可修改性，另外一些属性之间则是相互抵触的。
– 在程序的开发阶段就应保证软件具有可理解性。可修改性和可测试性。在软件开发的每一个阶段都应尽力考虑软件的可维护性。
• 使用提高软件质量的技术与工具
– 在进行软件设计时，采用如本书前面所述的模块化程序设计、结构化程序设计等程序设计方法，在软件开发过程中，采用结构化小组，建立主程序小组，实现严格的组织化管理，职能分工，规范标准，在对程序的质量进行检测时，也可以采用分工合作的方法，这些方法会有效地提高软件质量和检测效率，进而提高软件的可维护性。
• 选择可维护性高的程序设计语言
– 选择较好的程序设计语言对软件维护有很大的影响。低级语言（如：机器代码或汇编语言）程序是一般人很难掌握和理解的，因而很难维护。高级语言比低级语言容易理解，具有更好的可维护性。在高级语言中，一些语言可能比另外一些语言更容易理解。例如，cobol语言比fortran语言更容易理解，因为cobol的变量接近英语；pl/1比cobol更容易理解，因为pl/1有更丰富、更强的语言集等
• 完善程序文档
– 程序文档对提高程序的可理解性有着重要的作用。即使是一个相对简单的程序，要想有效地，迅速对它进行维护，也需要编制文档对它的目的和任务进行解释。而对于程序的维护人员来说，要想对程序编制人员的意图进行重新修改，并对今后可能出现的变化估计，缺少文档的帮助也将很难实现。另一方面，对于程序文档一定要能及时反映程序的变化，否则将对后续维护人员产生误导。
• 进行质量保证审查
– 除了保证软件得到适当的质量外，审查还可以用来检测在开发和维护阶段内发生的质量变化。一旦检测出问题来，就可以采取措施来纠正，以控制不断增长的软件维护成本，延长软件系统的有效生命期。为了保证软件的可维护性，有四种类型的软件审查：在检查点进行复审、验收检查、周期性地维护审查、对软件包进行检查。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
