软件工程1-3章补充知识点.doc

《软件工程1-3章补充知识点.doc》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、第一章补充瀑布模型系统工程、需求规约与分析、设计规约与分析、编码与单元测试、集成测试系统测试、运行与维护、特征接受上一阶段的结果作为本阶段的输入利用这一输入实施本阶段应完成的活动对本阶段的工作进行评审将本阶段的结果作为输出，传递给下一阶段缺点缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发开发早期存在的问题往往要到交付使用时才发现，维护代价大增量模型定义框架需求、设计体系结构、增量1![核心产品][分析、设计、编码、测试、交付]增量2-》[分析、设计、编码、测试、交付]-》最终软件系统特点：1.增量模型将软件的开发过程分成若干

2、个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。52.增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征3.增量模型强调每一个增量都发布一个可运行的产品增量模型特别适用于：1.需求经常变化的软件开发2.市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发优点1.产品分解成若干构件后逐步交付，用户可以不断地看到所开发软件的可运行中间版本2.将早期增量作为原型有助于明确后期增量的需求3.降低开

3、发风险4.重要功能被首先交付，从而使其得到最多的测试缺点1.需要软件具备开放式的体系结构2.需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及增量的集成可能会比较困难3.容易退化为边做边改方式，使软件过程的控制失去整体性原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。原型的类型：探索型（exploratoryprototyping）5其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方

4、案的可行性实验型（experimentalprototyping）其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠。演化型（evolutionaryprototyping）其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。废弃（throwaway）策略追加（addon）策略特点：它没有固定的生存期从需求分析到最终产品都可作原型，即可为不同目标作原型快速、廉价，适应用户对需求规格的变更与其他过程模型结合使用存在问题：管理复杂，不适合大型的软件项目可

5、能损伤软件内部结构，文档变更的速度跟不上适用：适用于初期用户需求不明确的情况小型或中等规模的交互式系统大型系统的某些部分，例如用户界面5生命周期较短的系统第二章补充系统工程的任务识别用户的要求标识系统的功能和性能范围，确定系统的功能、性能、约束和接口。系统建模和模拟系统模型通常可用图形描述，并加以相应的文字说明。必要时，在系统建模后可构造原型，进行系统模拟，以分析所建的模型能否满足整个基于计算机的系统的要求。成本估算及进度安排对将开发的基于计算机的系统进行成本估算，并作出进度安排。可行性分析从经济、技术、法律等方面分析所给出的解决方

6、案是否可行，通常只有当解决方案可行并有一定的经济效益和/或社会效益时才开始真正的基于计算机的系统的开发。生成系统规格说明第3章补充需求获取系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表、一组应用场景。5需求获取的工作产品为进行需求分析提供了基础需求分析与协商需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。在需求获取阶段，经

7、常出现以下问题：用户提出的要求超出软件系统可以实现的范围或实现能力；不同的用户提出了相互冲突的需求系统建模建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。需求规约软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求规约作为用户和开发者之

8、间的一个协议，在之后的软件工程各个阶段发挥重要作用。需求验证5作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。需求管