欢迎关注我的公众号

第一章新信息化和信息系统 1.4

2022-08-17 09:52
216
0
添加收藏

1.4 软件工程

1.4.1 需求分析
 

】需求的层次:
 

业务需求:指反应企业或客户对系统高层次的目标要求,通常来自投资人、购买产品的客户、客户单位的管理人员、市场营销部或产品策划部门等。
 

用户需求:描述的是用户的具体目标,或用户要求必须能完成的任务。
 

系统需求:从系统的角度来说吗软件的需求,包括功能需求、非功能需求、设计约束等。

 

】质量功能部署(Quality Funciton Deployment,QFD):

  • 常规需求:用户认为系统应该做到的功能或性能,实现越多用户越满意。
  • 期望需求:用户想当然认为系统应具备的功能或性能,但并不能正确描述自己想要得到的这些功能或性能需求;
  • 意外需求:也称兴奋需求,是用户要求范围外的功能或性能。实现这些功能用户会很高兴,不实现也不影响购买的决策。
     


 

需求分析:使用SA(结构化)方法进行需求分析,其建立的模型的核心是数据字典。分为三个层次的模型,数据模型(实体联系图E-R图表示)、功能模型(数据流图DFD)、行为模型(状态转换图STD)。

了解】软件需求规格说明书(software requirement specification , SRS):是需求开发活动的产物,编制该文档的目的是使干系人与开发团队对系统的初始规定有一个共同的理解,使之成为整个开发工作的基础。包括内容如下:范围、引用文件、合格性规定、需求可追踪性、注解、附录。

了解需求验证也称为需求确认,包括以下内容:

  • SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
  • SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导来的。
  • 需求是完整的和高品质的。
  • 需求的表示在所有地方都是一致的。
  • 需求为继续进行系统设计、实现和测试提供了足够的基础。

 

了解UML:建模语言,包括结构块、规则、公共机制三个部分。

】UML中的关系:依赖(dependency)、关联(association)、泛化(generalization)、实现(realization);

UML2.0中的图例(14种):类图、对象图、构建图、组合结构图、用例图、顺序图、通信图、定时图、状态图、活动图、部署图、制品图、包图、交互概览图。

UML视图:

  • 逻辑视图:也称设计视图,表示了设计模型中在架构方面具有重要意义的部分,即类、子系统、包和用例实现的子集。
  • 进程视图:可执行线程和进程作为活动类型的建模,它是逻辑视图的一次执行实例,描述了并发与同步结构。
  • 实现视图:对组成基于系统的物理代码的文件和构件进行建模。
  • 部署视图:把构件部署到一组物理节点上,表示软件到硬件的映射和分布结构。
  • 用例视图:最基本的需求分析模型。

 

了解面向对象分析阶段的核心工作是建立系统的用例模型和分析模型。
 

】类之间主要关系有:泛化、组合、关联、依赖、聚合和实现。

 

1.4.2 软件架构设计

软件架构设计:核心问题是能否达到架构级的软件复用。通用软件架构分类如下:
 

  • 数据流风格:包括批处理序列和管道/过滤器两种风格。
  • 调用/返回风格:包括主程序/子程序、数据抽象和面向对象,以及层次结构。
  • 独立构件风格:包括进程通信和事件驱动的系统。
  • 虚拟机风格:解释器和基于规则的系统。
  • 仓库风格:数据库系统、黑板系统和超文本系统。


 

了解软件架构评估中,评估人员关注的是系统的质量属性。评估方式:调查问卷、场景(常用)、度量三种方式。基于场景方式主要包括:架构权衡分析法、软件架构分析法、成本效益分析法。


 

1.4.3 软件设计

了解结构化设计:一个自顶向下、逐步求精和模块化的过程。

了解SD:一种面向数据流的方法,遵守高内聚、低耦合。

了解面向对象设计,常用原则:单一职责原则、开发-闭合原则、里氏替换原则、迪米特原则、依赖倒置原则、接口隔离原则、组合重用原则。

1.4.4 软件工程的过程管理

了解在软件过程管理方面,最著名的是能力成熟度模型集成。
 

了解对同一组织采用两种模型分别进行CMMI评估,得到的结论应该是相同的
 

阶段式模型
 

成熟度等级
 

过程域
 

可管理级
 

需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证
 

已定义级
 

需求开发、技术解决方案、产品集成、验证、确认、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成
 

量化管理级
 

组织级过程性能、定量项目管理
 

优化管理级
 

组织级改革与实施、因果分析和解决方案
 

 

连续式模型
 

连续式分组
 

过程域
 

过程管理
 

组织级过程焦点、组织级过程定义、组织级培训、组织级过程性能、组织级改革与实施
 

项目管理
 

项目计划、项目监督与控制、供应商合同管理、集成项目管理、风险管理、集成化的团队、定量项目管理
 

工程
 

需求管理、需求开发、技术解决方案、产品集成、验证、确认
 

支持
 

配置管理、度量和分析、过程和产品质量保证、组织级集成环境、因果分析和解决方案
 

 

1.4.5 软件测试及管理

了解分为静态(桌面检查、代码走查、代码审查)和动态(白盒、黑盒)测试。

了解测试类型:单元测试、集成测试、确认测试(内部确认测试、Alpha测试和Beta测试、验收测试、系统测试、配置项测试、回归测试。

】软件测试和调试主要区别:

  • 测试的目的是找出存在的错误,而调试的目的是定位错误并修改程序以修正错误
  • 调试是测试之后的活动,测试和调试在项目、方法和思路上都有所不同。
  • 测试从一个已知的条件开始,使用预先定义的过程,有预知的记过;调试从一个未知条件开始,结果的过程不可预计。
  • 测试过程可以事先设计,进度可以事先确定;调试不能描述过程或持续时间。

 

了解软件测试管理:过程管理、配置管理、评审;

1.4.6软件集成技术

】企业应用集成(enterprise application integration EAI)

】分为:

  • 表示集成:界面集成,集成点在界面上
  • 数据集成:白盒集成,集成点在中间件上
  • 控制集成:黑盒集成,集成点在应用逻辑层上
  • 业务流集成:过程集成
  • 企业之间的应用集成

全部评论