软考高级-架构设计师 【第二章 软件工程 2.1开发模型 2.2需求工程】基于B站的学习笔记

第二章 软件工程

2.1开发模型

2.1.1瀑布模型

结构化方法，严格区分阶段，每个阶段因果关系紧密相连,责任划分清楚

  只适合需求明确的项目

2.1.2原型模型

迭代方法，适合需求不明确的项目
  原型模型两个阶段：原型开发阶段和目标软件开发阶段

2.1.3V模型

测试贯穿于始终，测试分阶段，测试计划提前

需求分析->验收测试与系统测试；

概要设计对应集成测试；

详细设计对应单元测试；

2.1.4迭代和增量

2.1.5螺旋模型

以快速原型为基础+瀑布模型，考虑了风险问题,大型，复杂，风险

目标设定->决定目标方案和限制

  风险分析->评价方案，识别风险，清楚风险

     开发和有效性验证->开发，验证下一产品

  评审->

2.1.6基于构建的开发模型（CBSD）

建立构件库，

  优点：易扩展，易重用，降低成本，安排任务更灵活

缺点：构件设计要求经验丰富的架构师，设计不好的构件难重用；

2.1.7基于构件的软件工程（CBSE）

购买而不是重新构造

  可组装性，可部署性，文档性，独立性，标准化性

    构件的组装：顺序组装，层测组装，叠加组装

2.1.8快速应用开发（RAD）

瀑布+基于构件

  主要过程：业务建模，数据建模，过程建模，应用生成，测试与交付

2.1.9统一过程（UP/RUP）

用例驱动，以架构为中心，迭代和增量;

核心工作流：业务建模，需求，分析与设计，实现，测试，部署，配置与变更管理，项目管理，环境

初始->定义最终产品视图和业务模型，确定系统范围,生命周期目标

细化->设计及确定系统架构，制定工作计划及资源要求,生命周期架构

构造->开发剩余构件和应用程序功能，把这些构件集成产品，并详细测试,初始运作功能

移交->确保软件对最终用户是可用的，进行β测试，制作产品发布版本,产品发布

2.1.10敏捷开发

四大价值观->沟通（加强面对面沟通），简单（不过度设计），反馈（及时反馈），勇气（接受变更的勇气）

以人为本，思想是适应性而不是预设性；

与传统方法相比，敏捷方法比较适合需求变化大或者开发前期需求不是很清晰的项目；

     以原型开发思想为基础，采用迭代式增量开发；

          敏捷方法-开放式源码（Open Source）开发方法:适用地域广

  敏捷方法-极限编程（XP），价值观：交流，朴素，反馈，勇气，近螺旋式开发，费用控制严格

  敏捷方法-SCRUM:侧重于项目管理

  敏捷方法-水晶方法“机动性”方法，拥有对不同类型项目非常有效的敏捷开发，用最少纪律约束而仍能成功的

  敏捷方法-特征驱动开发方法（FDD）:认为有效的软件开发需要三要素：【人，过程，技术】，定义了6种关键的项目角色：项目经理，首席架构设计师，开发经理，主程序员，程序员和领域专家

  

2.1.11逆向工程

实现级：包括程序的抽象语法树，符号表，过程的设计

结构级：包括反映程序分量之间相互依赖关系的信息，列入调用图，结构图等

功能级：包括反馈程序段功能及程序段之间关系的信息，列入数据和控制流模型

领域级：反映程序分量或程序各实体与应用领域概念之间对应关系，

2.1.12净室软件工程

 即无尘室，也就是一个受控污染级别的环境

 强调正确性验证而不是测试 

 定义3种抽象层次：行为视图（黑盒）-》有限状态机视图（状态图）-》过程视图（明盒）

缺点：

太理论化，正确性验证步骤比较困难耗时

开发小组不进行传统的模块测试，这不现实

2.2需求工程

概述：

  软件需求是指：用户对系统在功能，行为，性能，设计约束等方面的期望

需求工程主要活动的阶段划分：

需求开发【需求获取，需求分析，形成需求规格（形成SRS），需求确认与验证】

需求管理【变更控制，版本控制，需求跟踪，需求状态跟踪】

需求管理是对【需求基线】进行管理

2.2.1需求开发

需求开发主要包括：需求获取，需求分析，需求定义和需求验证

需求开发有别于软件开发，需求规格说明书评审之后形成基线，需求开发差不多就结束了

2.2.1.1需求获取方法

2.2.1.2需求分析

2.2.1.2.1结构化需求分析

功能模型->数据流图(DFD)：数据流，加工，数据存储，外部实体

行为模型->状态转换图：状态，事件

数据模型->ER图：实体，联系

2.2.1.2.2面向对象需求分析(UML)

结构图（静态图）

类图(Class Diagram)：显示类、接口及其静态关系

对象图(Object Diagram)：展示某一时刻的对象及其关系

组件图(Component Diagram)：描述系统组件及其依赖关系

部署图(Deployment Diagram)：展示系统物理部署结构

包图(Package Diagram)：展示包及其依赖关系

复合结构图(Composite Structure Diagram)：展示类的内部结构

行为图（动态图）

用例图(Use Case Diagram)：展示系统功能与外部参与者的交互

活动图(Activity Diagram)：描述业务流程或算法流程

状态图(State Machine Diagram)：展示对象状态变化

序列图(Sequence Diagram)：强调时间顺序的对象交互

通信图(Communication Diagram)：展示对象间的协作关系

时序图(Timing Diagram)：关注时间约束的交互

交互概览图(Interaction Overview Diagram)：活动图与交互图的结合

UML4+1视图

1、逻辑视图(Logical View)：

关注功能需求，展示系统的静态结构和动态行为

主要使用类图、对象图、状态图和交互图

面向分析师和设计人员

2、进程视图(Process View)：

关注非功能性需求，如性能、可扩展性

展示系统的并发和同步机制

主要使用活动图、序列图、状态图

面向系统集成人员

3、实现视图(Implementation View)：

关注软件模块的组织和管理

展示组件及其关系

主要使用组件图、包图

面向开发人员

4、部署视图(Deployment View)：

关注系统的物理部署

展示节点和它们之间的连接

主要使用部署图

面向系统工程师

5、用例视图(Use Case View) (+1)：

作为核心，驱动其他视图的开发

展示系统功能需求

主要使用用例图

面向所有利益相关者

2.2.1.3需求定义

2.2.1.3.1严格定义法

所有需求都能被预先定义；

开发人员与用户之间能准确而清晰的交流；

采用图形/文字可以充分体现最终系统；

2.2.1.3.2原型法

  并非所有的需求都能在开发前被准确说明;

  项目参加者之间通常都存在交流上的困难；

  需要实际的，可供用户参与的系统模型；

  有合适的系统开发环境；

  反复是完全需要和值得提倡的，需求一旦确定，应遵从严格方法

2.2.1.4需求验证

2.2.2需求管理

 需求变更管理：问题分析和变更描述、变更分析和成本计算、变更实现。