【复习笔记】软件工程概论复习（1）

 

系统工程中的概念（重点）

• 业务过程工程
  系统工程在工作集中于企业业务时的表现形式
  目标是定义一个能有效利用信息进行业务活动的体系
• 产品工程
  系统工程在工作集中于产品生存时的表现形式，系统工程包括业务过程工程和产品工程
  目的是将用户期望的已定义的一组能力转变为真实产品
• 系统要素
  软件、硬件、人员、数据库、文档、规程等等组成计算机系统的要素
• 宏要素
  组成计算机系统的要素组成的更大系统，例如多个计算机系统和机床组成的自动化工厂系统
• 系统包括
  
  • 架构
    三种架构：
    
    1. 数据架构
    2. 应用架构
    3. 技术基础设施
  • 特征
  • 要素
  • 层次
    不同的抽象层次有不同的系统，如全局视图，领域视图，要素视图
  • 建模
  • 仿真
    在具有极高可靠性要求的系统（交互系统）中通过仿真来消除可能造成的意外
• 模板
• UML模型（主要内容）
  
  • 部署图
  • 活动图
  • 类图
  • 用例图

 

系统建模

包括如下模型：
- 定义在所考虑视图中满足需要的过程
- 描述过程行为和该行为所依据的假设
- 明确定义模型的内部和外部输出
- 描述有助于工程师理解视图的全部联系（包括输出）

 

系统模型分类

• Hatley-Pirbhai建模
  输入、处理、输出、用户界面处理、自检处理
• UML建模
  各种图描述

 

需求工程任务（重点）

• 起始
  建立对需求的基本理解
• 导出
  导出需求信息，包括范围问题，理解问题，易变问题
• 精化
  建立分析模型来表示信息、功能和行为
• 协商
  让开发者与客户在一个可交付的系统上达成共识（主要是让客户理解到有些功能不切实际）
• 规格说明
  正式或非正式地描述需求（不是任选，而是根据实际情况选择），例如对于大型系统建立文档，小型系统说明使用场景
• 确认
  对需求工程的工作产品进行质量评估。启动正式技术评审
• 管理
  管理可能变更的需求

需求工程帮助软件工程师更好地理解他们将要解决的问题

 

需求工程的工作产品

• 必要性和可行性陈述
• 系统或产品范围的界限说明
• 参与需求导出的客户、用户和其他共同利益者的列表
• 系统技术环境的说明
• 需求列表以及每个需求适用的领域限制
• 使用场景列表
• 原型（可能有）

 

需求开发的方法

• 协同需求收集（CRG Meeting）
  开会
• 质量功能部署（QFD）
  将需求分类
• 用户场景（即用例）
• 导出工作产品

 

分析模型的作用

为基于计算机的系统提供必要的信息、功能和行为域的说明

 

分析模型的构建原则

• 目标原则
  
  1. 描述客户需要什么
  2. 为软件设计奠定基础
  3. 定于在软件完成后可以被确认的一组需求
• 经验原则
  
  1. “不要陷入细节”，模型应在高级别的抽象层次，不关注具体实现
  2. 分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解
  3. 基础结构和其他非功能的模型不考虑
  4. 最小化系统内部的关联（低耦合）
  5. 确认分析模型对所有共同利益者都有价值
  6. KIS（keep it simple），尽可能简洁

 

分析模型的构建方法（重点）

所述图都是uml图
- 场景建模：用例图、部署图
- 面向对象建模：类图、协作图（即通信图）
- 行为建模：状态图、活动图、顺序图

 

转载于:https://www.cnblogs.com/QEStack/p/8195874.html