《软件工程13章补充知识点.docVIP

第一章补充 瀑布模型 系统工程、需求规约与分析、设计规约与分析、编码与单元测试、 集成测试系统测试、运行与维护、 特征 接受上一阶段的结果作为本阶段的输入 利用这一输入实施本阶段应完成的活动 对本阶段的工作进行评审 将本阶段的结果作为输出，传递给下一阶段 缺点 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发 开发早期存在的问题往往要到交付使用时才发现，维护代价大 增量模型 定义框架需求、设计体系结构、 增量1![核心产品][分析、设计、编码、测试、交付] 增量2 -》[分析、设计、编码、测试、交付]-》最终软件系统 特点： 1.增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。 2.增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征 3.增量模型强调每一个增量都发布一个可运行的产品 增量模型特别适用于： 1.需求经常变化的软件开发2.市场急需而开发人员和资金不能在 设定的市场期限之前实现一个完善的产品的软件开发 优点 产品分解成若干构件后逐步交付，用户可以不断地看到所开发 软件的可运行中间版本 将早期增量作为原型有助于明确后期增量的需求 降低开发风险 4.重要功能被首先交付，从而使其得到最多的测试 缺点 1.需要软件具备开放式的体系结构 2.需求难以在增量实现之前详细定义，因此增量与需求的准确映 射以及增量的集成可能会比较困难 3.容易退化为边做边改方式，使软件过程的控制失去整体性 原型（prototype） 是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。 原型的类型： 探索型（exploratory prototyping） 其目的是要弄清目标系统的要求，确定所希望的特性，并探讨 多种方案的可行性 实验型（experimental prototyping） 其目的是验证方案或算法的合理性，它是在大规模开发和实现 前，用于考核方案是否合适，规格说明是否可靠。 演化型（evolutionary prototyping） 其目的是将原型作为目标系统的一部分，通过对原型的多次改 进，逐步将原型演化成最终的目标系统。 废弃（throw away）策略 追加（add on）策略 特点： 它没有固定的生存期 从需求分析到最终产品都可作原型，即可为不同目标作原型 快速、廉价，适应用户对需求规格的变更 与其他过程模型结合使用 存在问题： 管理复杂，不适合大型的软件项目 可能损伤软件内部结构，文档变更的速度跟不上 适用： 适用于初期用户需求不明确的情况 小型或中等规模的交互式系统 大型系统的某些部分，例如用户界面 生命周期较短的系统 第二章补充 系统工程的任务 识别用户的要求 标识系统的功能和性能范围，确定系统的功能、性能、约束和接口。 系统建模和模拟 系统模型通常可用图形描述，并加以相应的文字说明。 必要时，在系统建模后可构造原型，进行系统模拟，以分析所建的模型能否满足整个基于计算机的系统的要求。 成本估算及进度安排 对将开发的基于计算机的系统进行成本估算，并作出进度安排。 可行性分析 从经济、技术、法律等方面分析所给出的解决方案是否可行，通常只有当解决方案可行并有一定的经济效益和/或社会效益时才开始真正的基于计算机的系统的开发。 生成系统规格说明 第3章补充 需求获取 系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表、一组应用场景。 需求获取的工作产品为进行需求分析提供了基础 需求分析与协商 需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。 在需求获取阶段，经常出现以下问题： 用户提出的要求超出软件系统可以实现的范围或实现能力； 不同的用户提出了相互冲突的需求 系统建模 建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。 常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。 需求规约 软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作