头像制作网站,做网站搭建服务器要多少钱,中企动力做的家具行业网站,游戏网站哪个好本帖的资料来源于某国内顶流高校的期末考试资料#xff0c;仅包含核心的简答题#xff0c;大家结合个人情况#xff0c;按需复习~ 总的来说#xff0c;大层面重点包括如下几个方面#xff1a;
软件过程需求工程 设计工程软件测试软件项目管理软件过程管理
1.掌握软件生命…本帖的资料来源于某国内顶流高校的期末考试资料仅包含核心的简答题大家结合个人情况按需复习~ 总的来说大层面重点包括如下几个方面
软件过程需求工程 设计工程软件测试软件项目管理软件过程管理
1.掌握软件生命周期的几个活动目标、任务、输出 (1) 需求分析需求工程 目的根据描述明确问题域特性 E 构建定义良好的系统行为 S 使得 E 通过 S 达 到预期的需求 R 需求工程的主要工作 (a) 研究问题背景描述问题域特性 E (b) 需求开发 , 确定 R (c) 构建解系统描述解系统行为 S 使得 E , S —— R 理解现实为第一目的保证 S 的质量为第二目的 结果 : SRS (Software Requirements Specification) 用户需求规格说明 (2) 设计 目的以软件实体为基础建立软件结构即整个将要开发的系统的模型或设计表示 任务 (a) 体系结构设计 (b) 细节设计 (c) 用户界面设计 (HCI) 结果模型体系结构模型系统模型 规格说明书体系结构说明系统构件说明界面设计文档 设计决策会极大的影响系统质量所以要有多种选择和折中 (3) 实现 目的用编程语言实现系统中单独的组件 任务 程序设计、编程、调试 结果 可执行的程序 (4) 测试 目的验证和确认软件质量 任务测试设计、单元测试、集成测试、系统测试 | 、确认测试、回归测试 结果发现的缺陷和错误 测试不一定要在实现结束后进行可能并行进行如果测试用例从需求确认中直接 得出可能影响需求分析 (5) 安装与维护 目的在系统向用户发布后保持系统的运行包括完善型 (Perfective) 、调整型 (Adaptive) 、修正型 (Corrective) 、防止型维护 (Preventive) 任务安装培训维护 输出正常运转的系统 2.针对于各种软件过程模型的描述特征描述 优点 缺点 (6) 螺旋模型 描述每个框架活动代表螺旋上的一个片段随着演化的开始从圆心开始顺时针方向执行螺旋上的一圈表示的活动。每次演化都要考虑风险。标记里程碑——沿 着螺旋路径达到的工作产品和条件的结合体 特征在每个阶段的演化中用瀑布模型 风险驱动 原型开发 内圈表示早期的系统分析和原型外圈表示经典瀑布模型的其他方面 优点 采用循环的方式逐步加深系统定义和实现的深度降低风险 确保共利益者都支持可行的和令人满意的系统解决方案 在项目的所有的阶段考虑风险适当利用该方法能够在风险变为问题前化解风险 缺点 依赖大量的风险评估专家来保证成功如果所有的风险不能解决项目就会立即停止 只适用于大规模的项目 3.理解软件和现实世界的互动机制 软件与现实世界的互动 (1) 当现实的状况与人们期望的状况产生差距时就产生了问题。 (2) 要解决问题就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序 使其达到期望的状态或演进顺序。 (3) 这些实体和状态构成了问题解决的基本范围称为该问题的问题域 Problem Domain (4) 软件系统通过影响问题域能够帮助人们解决问题称为解系统 共享现象 (1) 软件系统能够与问题域进行交互和相互影响的原因在于软件系统中的某些部分对问题域中的某些部分的具有模拟特性。 (2) 换句话说软件系统当中含有问题域某些部分的模型或模拟常见的模型包括数据模型、对象模型、处理模型等。 (3) 问题域中的某些信息能够和模型中的信息建立 映射 关系 (4) 这些通过映射建立的共同知识就是问题域和解系统之间的共享现象 需求 是用户对问题域当中的实体状态或事件的期望描述 直接需求是可以通过更改共享现象被满足的需求 ; 需求关注的是现实世界中的部分软件关注的是解系统而规格说明关注的是共享现象 规格说明是解系统为满足用户需求而提供的解决方案规定了解系统的行为特征 主要包括两个部分 1 对共享现象模型的描述 2 系统对共享现象所施加的操作的描述。 4.需求的分类 (1) 功能需求 Functional Requirement 与系统主要工作相关的需求即在不考虑物理约束的情况下用户希望系统所能够执行的活动这些活动可以帮助用户完成任务。 功能需求主要表现为系统和环境之间的行为交互。 (2) 性能需求 Performance Requirement 系统整体或系统组成部分应该拥有的性能特征例如 CPU 使用率、内存使用率等。 (3) 质量属性 Quality Attribute 系统完成工作的质量即系统需要在一个“好的程度”上实现功能需求例如可靠性程 度、可维护性程度等。 (4) 对外接口 External Interface 系统和环境中其他系统之间需要建立的接口包括硬件、软件接口、数据库接口等 (5) 约束进行系统构造时需要遵守的约束例如编程语言、硬件设施等 5.描述需求工程的活动 (1) 需求起始解决业务需求 活动 建立项目范围和前景 ( 涉众分析、确定涉众、识别多种观点、协商合作、首次提问) (2) 需求导出 活动 协同需求收集、质量功能部署(QFD)、开发用户场景和用例导出工作产品 QFD:将客户要求转化成软件技术需求的技术。强调“什么是对客户有价值的” 确认了三种需求正常需求、期望需求、令人兴奋的需求 产品需要及可变性的陈述对系统和产品的范围描述客户及其他涉众人员名单系统技术环境的描述一系列需求以及各需求实现的限制不同操作环境下的用例能更好的确定需求的各种原型 (3) 需求精化开发一个精确的技术模型用以说明软件的功能、特征和约束。是一个分析建模的动作最终结果是分析模型定义问题的信息域、功能域、行为域精化与导出交互进行~ 活动分析模型的元素(基于场景的、基于类的元素、行为元素、面向信息流的元素) 建立一个能够识别出数据和行为特性的模型 利用分析模式建立需求分析模型 (4) 需求协商在一个开发者和用户都能接受的现实的能发布的产品上达成一致 活动 识别系统或子系统关键的共利益者 确定共利益者“赢”的条件 就共利益者“赢”的条件进行协商使其与所有涉及人的一系列双赢条件一致 (5) 需求规格说明需求工程师完成的最终工作产品将作为软件工程师活动的基础 描述了一个基于计算机系统的功能、性能以及影响系统开发的约束。可以用自然语言描述和图形化的模型来编写也可以只是使用场景 (6) 需求验证对需求工程的工作产品进行质量评估。检查规格以保证所有的系统需求无歧义的说明不一致性疏漏和错误已被检测出并被修正工作产品符合为过程、项目和产品建立的标准。 (7) 需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一 组活动 在需求发展后发布基线 保持跟踪表 变更控制 6.理解设计理论的 7 个特征并掌握它们在软件设计上的影响 (1) 设计起始于需求的目的设计前需要需求工程 (2) 设计通常引起转化软件改变世界 需求、共享现象、领域特征 组成软件设计的基础也就是分析模型 (3) 设计需要创造性新思想的产生是设计理论的基础 无论何时 , 只要有一个从现实到未来可能的充满想象力的飞跃 , 设计就会发生 ; 新思想产生的精确方式是难以系统化表示的 影响 : 设计理论的一般风格抽象精化 软件设计的具体风格模块化和信息隐藏新思想产生的影响软件功能独立 创造性抽象 精化 模块化信息隐藏。抽象包括行为抽象只显现功能隐藏具体实 现 数据抽象对数据对象进行抽象精化与抽象相反的过程将抽象时没有考虑的细节考虑进去对抽象级上的功能加以具体实现考虑层次结构设计模块化把软件划分成相互独立的部分通过部分的集成来满足需求要符合高内聚低耦合的特点。信息隐藏抽象的重要手段模块化抽象是信息隐藏的直接 结果。每个模块对其他模块隐藏它的具体设计决策。 (4) 设计需要满足约束原始的需求确定了部分约束大部分约束在设计的过程中逐渐被发现 影响软件质量管理尤其是非功能的需求的管理 (5) 设计是一个问题求解和决策的过程设计问题的解决空间很多设计的特征在于在一系列的选择中做决定。 软件需要看重基础原则的决定如体系结构的设计决定软件需要通过不同方面来划分做决定的工作如分为界面设计安全设计分配设计实时设计等 (6) 设计能产生用来实现最终产品的进度安排产生软件设计模型 (7) 设计具有多样性和演化性任何细节设计都有多种实现在不同的实现方式之间的决策使得设计具有多样性由于不断的决策设计也要不断演化使设计与当前情况相符合。随着演化的进行需求和约束也会逐渐明晰。 软件设计中的多样性决定软件在设计时可以使用已有的问题解决模式 如体系结构模型设计模型代码模型等。同时软件设计需要用重构 等方法进行演化软件的设计需要复用框架构件等比较成功的解决方案。 7.理解常见的体系结构风格
(1) 以数据为中心的体系结构 (2) 数据流体系结构 (3) 调用返回体系结构 (4) 层次体系结构 层次结构定义了一系列不同层次每个层次各自完成操作。这些操作不断接近机器的指令集。最外层构件完成用户界面的操作最内层构件完成 与操作系统的连接中间层提供各种实用程序服务和应用软件的功能。 (5) 面向对象体系结构 构建封装数据和必要的操作 , 构件间通过信息传递进行通信与合作。 8.类设计原则 (0) 单一职责原则 (SRP): 一个类的改变只能出于一种原因 (1) 开关原则 模块应该对外延具有开放性对修改具有封闭性。 设计者应该采用一种无须对构件自身内部做修改就可以进行扩展的方式来说明构件。在扩展的功能与设计类本身之间分离出一个缓冲区。 (2) Liskov 替换原则 子类可以替换它们的基类。 将子类传递给构件来代替基类时使用基类的构件仍能工作。任何子类必须遵守基类与使用该基类的构件之间的隐含约定。 (3) 依赖倒置原则 依赖于抽象而非具体实现。 抽象可以比较容易的扩展不会导致大的混乱。构件依赖的具体构件越多扩展越困难。 (4) 接口分离原则 多个用户专用接口比一个通用接口好。 否则会产生多目标类和不必要的依赖。 9.能够列出至少 5 个界面设计的原则并加以解释 (1) 置用户于控制之下 以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式 提供灵活的交互 允许用户中断或撤销交互。 把用户与内部技术细节隔离开来 (2) 减轻用户的记忆负担 减轻对短期记忆的要求 建立有意义的缺省 定义直观的快捷方式 界面的视觉布局应该基于真实世界的象征 以不断进展的方式揭示信息 (3) 保持界面一致 允许用户将当前任务放入有意义的环境中 在应用系统家族内保持一致性 如果过去的交互模型已经建立起了用户期望除非有不得已的理由否则不要改变它。 (4) 使用用户语言及友好的错误提示好的错误提示需要告诉用户发生了什么需要怎么改进 ] (5) 提供帮助和文档并且应该放在用户易于访问的位置 10.能够描述测试的 5 个层次 主要工作 (1) 单元测试 检测单个模块的行为 侧重以源代码形式实现的每个单元它充分利用测试技术检查构件中每个控制结构的特定路径以确保完全覆盖。注意边界测试。 (2) 集成测试 测试模块之间相互协作时的工作情况。 普遍使用关注输入和输出的测试用例设计技术。常用增量集成自顶向下、自底向上集成冒烟测试 (3) 验收测试 将软件的行为与用户的最终需求进行比较 常用于安装测试 α 测试β 测试 (4) 系统测试 软件行为与需求规格说明书进行比较 将软件与系统的其他成分作为一个整体来测试包括安全测试压力测试性能测试恢复测试 (5) 回归测试 查看新的版本中软件的行为 。回归测试可能包括以上各个层次的重新测试来保证改变没有引进新的错误。 11.能够描述白盒测试和黑盒测试并进行优缺点比较 12.能解释并区别白盒测试三种不同的方法语句覆盖、分支覆盖和路径覆盖 13.掌握 LOC 和 FP 两种估算单位能够说明各自的优缺点 14.理解几种图示工具的使用 所有的项目任务在左边的栏中列出水平条表示各个任务的工期同一时段中存在多个水平条时代表任务之间的并发性菱形表示里程碑。 人员安排 15.能够解释风险管理过程 (1) 风险识别指出对项目计划的威胁。识别已知的和可预测的风险。一种方法是建立风险条目检查表。识别产品规模、商业影响、客户特性、过程定义、开发环境、开发技术、人员才干及经验等类型中的风险。 (2) 风险分析估计每个风险的可能性或概率风险相关问题产生的后果。 活动建立一个尺度以反映风险发生的可能性。 描述风险产生的后果,估计风险对项目及产品的影响。 标明风险预测的整体精确度以免产生误解。 (3) 风险计划考察每一个风险并且为风险的管理开发一个策略。包括 风险回避风险最小化应急计划 (4) 风险跟踪和控制 评估每一个确定的风险跟踪看它的可能性变大还是变小。评估风险的影响是否发生变 化 16.为什么进行软件项目度量 可以提供能够引导长期的软件过程改进的一组过程指标使得软件项目管理者能够 (1) 评估正在进行中的项目状态 (2) 跟踪潜在的风险 (3) 在问题造成不良影响之前发现他们 (4) 调整工作流程或任务 (5) 评估项目团队控制软件工作产品质量的能力 17.描述 SQA Group 的主要活动 18.能够简要描述 SCM process 主要活动各个活动的目的主要工作 SCM 的目标 1) 标识变更 2) 控制变更 3) 保证正确地实现变更 4) 向那些利害相关的人员报告变更 软件配置管理过程中的一系列任务中的四个主要目标 (1) 统一标识软件配置项 (2) 管理一个或多个软件配置项的变更 (3) 便于构造应用的不同版本 (4) 在配置随时间而演化时确保能够保持软件质量
