高项-信息化和信息系统3

一、需求工程

1.软件需求：用户对系统在功能、行为、性能、设计约束等方面的期望，用户解决问题或达到目标所需的条件或能力，系统或系统部件要满足合同、标准、规范或者其他正式规定文档所需具有的条件或能力

2.需求开发和需求管理两大过程

 

 二、需求层次

1.业务需求：企业或客户对系统高层次的目标要求

2.用户需求：用户的具体目标，或用户要求系统必须能完成的任务，用户能使用系统用来做什么

3.系统需求：从系统的角度来说明软件的需求

　　开发人员必须在系统中实现的软件功能

　　系统必须具备的属性或品质

　　对系统的一些约束说明

三、质量功能部署

1.质量功能部署是一种将用户要求转化成软件需求的技术

　　系统应该做到的功能或性能

　　想当然认为系统应具备的功能或性能，并不能正确描述

　　用户要求范围外的功能或性能

四、需求获取和分析

1.需求获取：是一个确定和理解不同的项目干系的需求和约束的过程

2.常见的需求获取法包括：用户访谈、问卷调查、采样、情节串联板、联合需求计划

3.需求分析：把杂乱无章的用户和期望转化为用户需求

五、需求定义

1.需求定义：整个开发工作的基础

2.SRS（需求规格说明书）应该包括以下内容：

 

 六、需求验证

1.需求验证：与用户一起确认需求无误

　　需求评审：正式评审和非正式评审

　　需求测试：设计概念测试用例

2.需求验证通过后，用户签字确认，作为验收标准之一，需求规格说明书是需求基线，不可以随意再更新，如果需要更改必须走需求变更流程

-----------------------------------------------------------------------------------------------------------------------------------

七、统一建模语言UML

1.UML组成

　　UML：可视化的建模语言，而非程序设计语言

　　结构：构造块、规则和公共机制

　　　　构造块：事物、关系和图

　　　　公共机制：达到特定目标的公共UML方法

　　　　规则：构造块如何放在一起的规定

2.UML关系

　　依赖：一个事物发生变化会影响另一个事物的语义

　　关联：一组对象之间连接的结构关系，分为组合和聚合

　　泛化：一般/特殊的关系

　　实现：一个类元指定了另一个类元保证执行的锲约

 

 

 

 　　类图：静态图，为系统的静态设计视图，展现一组对象，接口、协作和它们之间的关系

　　

 

 　　用例图：静态图，用例、参与者以及它们之间的关系

　　　　包含：多个用例的公共行为，即要完成用例A必须先完成用例B

　　　　扩展：用例之间的可选扩展分支，完成用例A后，可选是否完成用例B

　　　　泛化：一般和特殊，父子关系

　　　　

 

 　　序列图：顺序图，动态图，描述了以时间顺序组织的对象之间的交互活动

　　

 

 　　通信图：动态图，强调参加交互的对象的组织

　　

 

 　　状态图：动态图，展现了一个状态机，描述单个对象在多个用例中的行为，包括简单状态和组合状态

　　

 

 　　活动图：动态图，一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程

　　　　

 

 　　构件图：静态图，为系统静态实现视图，展现了一组构件之间的组织和依赖

　　　　

 

 　　部署图：静态图，为系统静态部署视图，物理模块的节点分布，一个节点包含一个或多个构件

　　　　

 

 2.UML视图

1）逻辑视图：设计视图，类、子系统、包和用例实现子集

2）进程视图：并发与同步结构

3）实现视图：物理代码的文件和构件进行建模

4）部署视图：构件部署到一组物理节点上

5）用例视图：最基本的需求分析模型

八、面向对象分析

1.OOA基本任务：找出描述问题域和系统功能所需的类和对象

     面向对象分析阶段：核心工作是建立系统的用例模型与分析模型

2.用例模型与分析模型

　　用例模型：识别参与者、合并需求获得用例、细化用例描述和调整用例模型

　　用例之间关系：包含、扩展和泛化

　　分析模型：对象和类如何组成系统（静态模型），以及他们如何保持通信、实现系统行为（动态模型）

　　类之间的关系：关联、依赖、泛化、聚集、组合、实现

　　对象：为类的实例

　　类：对象的抽象

　　消息：对象之间进行通信

　　继承：父类和子类之间共享数据和方法的机制

　　函数重载：重载一个函数名相同，但是返回值或参数不同的函数

3.面向对象基本概念

　　多态：不同的对象收到同一个消息时产生完全不同的反应

　　静态类型：一个对象类型载编译时就确定，动态类型：在运行时才能确定

　　封装：一种信息隐藏技术

八、系统设计

1.软件架构：结构、行为和属性的高级抽象，显示了系统需求和构件之间的对应关系

2.软件架构研究主要内容涉及：软件架构描述、架构风格、架构评估、架构的形式方法

3.解决好软件的复用、质量和维护问题

4.软件架构风格：核心问题是否达到架构级的软件复用，描述某一个特定应用领域中系统组织方式的惯用模式

九、软件架构风格分类

1.数据流风格：按照一定的顺序从前向后执行程序

2.调用/返回风格：构件之间存在互相调用的关系

3.独立构件风格：构件之间是互相独立的，通过某个事件触发，异步的方式来执行

4.虚拟机风格：自定义了一套规则使用者使用

5.仓库风格：以数据为中心

十、软件架构评估

1.敏感点：实现某种特定的质量属性

2.权衡点：影响多个质量属性的特性

3.软件架构评估在架构涉及之后，为了评估所采用的架构是否能解决软件系统需求

4.常用的架构评估方式

　　基于调查问卷的方式

　　基于度量的方式

　　基于场景的方式

十一、软件设计

 1.软件设计：解决怎么做的问题

2.结构化设计：面向数据流、面向过程，自顶向下，逐步求精和模块化，高内聚，低耦合

3.面向对象设计：是对类和对象进行设计，OOD的结果就是设计模型，可用性是同时提高软件的可维护性和可复用性

4.设计模式：方便地复用成功的软件设计

5.根据目的和用途不同，设计模式可分为创建型模式、结构型模式、和行为模式

十二、软件工程的过程管理

1.能力成熟模型集成CMMI:消除不同模型之间的不一致和重复，降低基于模型将那些改进的成本

2.CMMI表示法：

　　1）阶段式模型：保持4个成熟等级，从低到高，依次为：可管理级、已定义级、量化管理级、优化管理级

　　2）连续式模型：没有与组织成熟度相关的几个阶段，将24个过程按照功能划分为过程管理、项目管理、工程和支持

3.软件工程的过程管理

　　可管理级：能够遵守既定的计划与流程

　　已定义级：根据自身的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化

　　量化管理级：数字化

　　优化级：主动地改善流程，运用新技术、实现流程的优化

　　

 十三、软件测试维护与集成

1.软件测试方法

　　静态测试：不在机器上运行，采用人工检测和计算机辅助静态分析的手段，桌前检查、代码审查、代码走查

　　动态测试：实际运行程序，功能性测试和结构性测试

　　单元测试：可独立编译或汇编的程序模块，软件详细设计说明书

　　集成测试：检查模块之间，以及模块和集成的软件之间的接口关系，软件概要设计文档

　　确认测试：验证软件的功能、性能和其他特性是否与用户需求一致

　　　　内部确认：软件开发组织内部按照SRS进行测试

　　　　alpha测试:用户在开发环境下进行测试

　　　　beta测试：用户在实际使用环境下进行测试

　　　　验收测试：针对SRS，在交付前以用户为主进行的测试

　　　　系统测试：测试对象式完整的，集成的计算机系统，用户需求或开发合同

　　　　配置项测试：软件配置，检验软件配置项与SRS的一致性

　　　　回归测试：测试软件变更后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能，性能和其他规定的要求不能损害性

　　　　软件维护：交付后的活动包括软件修改、培训和帮助资料

　　　　软件维护类型：

　　　　　　1）更正性维护：更正发现的问题

　　　　　　2）适应性维护：保持软件产品能在变化后或变化中的环境继续使用

　　　　　　3）完善性维护：改进性能和可维护性

　　　　　　4）预防新维护：软件产品中潜在的错误成为实际错误前，检测和更正

2.评审与审计

　　评审与审计：管理评审、技术评审、检查、走查、审计

十四、集成测试

1.企业应用集成EAI

　　1）表示集成：统一入口

　　2）数据集成：把不同来源、格式、特点性质的数据在逻辑上或者物理上有机的集中，提供全面数据共享

　　3）控制集成：业务逻辑层次的集成

　　

 

　　4）业务流程集成：过程集成，最彻底的、综合的集成