软考中级《系统集成项目管理工程师》-第3章信息系统集成专业技术知识（1）

软考中级《系统集成项目管理工程师》教材考点纵览系列3.1，分享给有需要的朋友，欢迎大家下载资料去备考复习。

第3章信息系统集成专业技术知识（1）

• 信息系统建设
  • 概念
    • 信息系统建设的内容
      • 主要包括设备采购、系统集成、软件开发、运维服务
    • 信息系统集成
      • 将计算机软件、硬件、网络通信、信息安全等技术和产品集成为能够满足特定需求的信息系统
  • 信息系统的生命周期
    • 选择考点1【常考】
    • 立项
      • 根据用户业务发展和经营管理的需要，提出建设信息系统的初步构想
      • 对企业信息系统的需求进行深入调研和分析，形成《需求规格说明书》，并确定立项
      • 概念阶段或需求阶段
    • 开发
      • 以立项阶段所做的需求分析为基础，进行总体规划
      • 通过系统分析（建模）、系统设计、系统实施、系统验收等工作实现并交付系统
    • 运维
      • 信息系统通过验收，正式移交用户
        • 4种主要类型
          • ① 更正性维护
          • ② 适应性维护
          • ③ 完善性维护
          • ④ 预防性维护
    • 消亡
      • 信息系统不可避免地会遇到系统更新改造、功能扩展、甚至废弃重建等情况
      • 信息系统建设的初期就应该注意系统消亡条件和时机，以及由此而花费的成本
  • 信息系统开发方法
    • 选择考点2【常考】
    • i. 结构化方法
      • 应用最为广泛的一种方法
      • 含义
        • 把整个系统的开发过程分为若干阶段，然后依次进行；前一阶段是后一阶段的工作依据，按顺序完成；每个阶段和主要步骤都有明确详尽的文档编制要求，并对其进行有效控制
      • 特点
        • 注重开发过程的整体性和全局性
      • 缺点
        • 开发周期长；
        • 文档、设计说明繁琐，工作效率低；
        • 要求在开发之初全面认识系统的需求，充分预料各种可能发生的变化
      • 代表手段
        • 数据流程图
        • 数据字典
        • 结构化语言
        • 判定表及判定树
      • 上来就要对系统需求进行全面的认识
    • ii. 原型法
      • 含义
        • 其认为在无法全面准确地提出用户需求的情况下，并不要求对系统做全面、详细的分析，而是基于对用户的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求
      • 特点
        • ✧ 对用户的需求是动态响应、逐步纳入的；
        • ✧ 系统分析、设计与实现都是随着对原型的不断修改而同时完成的，相互之间并无明显界限，也没有明确分工
      • 分类
        • 抛弃型原型
        • 进化行原型
      • 适用于：一开始需求定义并不清楚，管理方法结构化程度不高的系统开发
    • iii. 面向对象方法
      • 含义
        • 用对象表示客观事物，对象是一个严格模块化的实体，在系统开发中可被共享和重复引用，以达到复用的目的
      • 关键
        • 能否建立一个全面、合理、统一的模型，既能反映需求对应的问题域，也能被计算机系统对应的求解域所接受
      • 涉及3个阶段
        • 1）分析2）设计3）实现
        • 特点是在整个开发过程中使用的是同一套工具；整个开发过程都是对面向对象三种模型的建立、补充和验证；因此，这三个阶段的界限并非十分明确
• 信息系统设计
  • 方案设计
    • 系统总体设计
      • 系统的总体架构方案设计、软件系统的总体架构设计、数据存储的总体设计、计算机和网络系统的方案设计
    • 系统详细设计
      • 代码设计、数据库设计、人/机界面设计、处理过程设计
  • 系统架构
    • 选择考点3【常考】
    • 步骤
      • 将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务
      • 然后，进一步确定各层的接口，层与层相互之间的关系
    • 方法
      • 对整个系统的分解，既需要进行“纵向”分解，也需要对同一逻辑层分块，进行“横向”分解
    • 系统的选型 → 取决于系统架构
  • 设备、DBMS（数据库管理系统）及技术选型
    • 不只要考虑系统的功能要求
    • 还要考虑到系统实现的内外环境和主客观条件
• 软件工程
  • 软件需求分析与定义
    • 含义
      • 软件需求是针对待解决问题的特性的描述，所定义的需求可以被验证，在资源有限时，可以通过优先级对需求进行权衡
    • 需求分析的作用/目的
      • 选择考点4【常考】
      • 1| 通过需求分析，可以检测和解决需求之间的冲突；
      • 2| 发现系统的边界；
      • 3| 详细描述出系统需求
    • 三个层次
      • 业务需求
        • 标识组织或客户高层次的目标，通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门
      • 用户需求
        • 描述的是用户的目标，或用户要求系统必须完成的任务
      • 功能需求
        • 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求
    • 常用方法
      • 结构化分析方法（SA）
      • 面向对象的分析方法（OOA）
  • 软件设计
    • 含义
      • 根据软件需求，产生一个软件内部结构的描述，并将其作为软件构造的基础；通过软件设计，描述出软件架构及相关组件之间的接口；然后，进一步详细地描述组件，以便能构造这些组件
    • 阶段
      • 1. 软件架构设计阶段（也称高层设计）
        • 2. 软件详细设计阶段
  • 软件测试
    • 含义
      • 测试是为了评价和改建产品质量、识别产品的缺陷和问题而进行的活动；
      • 软件测试是针对一个程序的行为，在有限测试用例集合上，动态验证是否达到预期的行为
    • 地位
      • 选择考点5
      • 测试不再只是一种仅在编码阶段完成后才开始的活动，现在的软件测试被认为是包含在整个开发和维护过程中的活动；它本身是实际产品构造的一个重要部分
    • 注意事项
      • 选择考点6
      • (1). 程序员应避免测试自己的程序【单元测试除外】
      • (2). 尽早地、不断地进行软件测试，系统测试应尽可能在实际运行使用环境下测试
      • (3). 在设计测试用例时，应包括合理的和不合理的输入条件
      • (4). 要充分注意测试中的集群现象【80/20原则】；经验表明，测试后程序中残存的错误数与该程序中已发现的错误数成正比
        • 不要以为发现几个错误并且解决这些问题之后，就不需要测试了；反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益
      • (5). 严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作
      • (6). 应对每一个测试结果进行全面检查
      • (7). 妥善保存测试用例、测试计划、测试报告和最终分析报告，为软件维护提供方便
    • 类型
      • 以软件开发的过程按阶段划分
        • 选择考点7
        • ♦ 单元测试阶段
          • 对每个模块进行测试，其目的主要是针对编码过程中可能存在的各种错误
        • ♦ 集成测试阶段
          • 在单元测试的基础上，将所有模块按照设计要求组装成系统，必须精心计划，应提交集成测试计划、集成测试规模说明书、集成测试分析报告；主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序部分之间的接口上可能存在的错误
        • ♦ 系统测试阶段
          • 将软件放在整个计算机环境下，在实际运行环境中进行一系列的测试，发现软件与系统定义不符合或矛盾的地方
        • ♦ 验收测试阶段
          • 验证软件的功能、性能以及其他特性是否与用户的要求一致
      • 以是否执行程序的角度划分
        • 静态测试
        • 动态测试
      • 以是否关心软件内部结构和具体实现的角度划分
        • 黑盒测试
        • 白盒测试
    • 具体测试种类
      • 选择考点8
      • i. 黑盒测试：不考虑模块内部结构，只在其接口进行测试
        • 不涉及程序的内部逻辑
        • 测试用例设计
          • 等价类划分：将所有可能输入数据划分为几类，从每一类中选取具有代表性的数据作为测试用例
          • 边界值分析：选取刚好等于、刚刚大于、刚刚小于输入范围边界的值作为测试数据
          • 错误推测法：根据程序中所有可能的错误和容易发生错误的特殊情况设计测试用例
          • 因果图法：利用输入条件的多种组合产生相应多个动作的方式设计测试用例
      • ii. 白盒测试： 把测试对象看成是一个透明的盒子，对程序所有的逻辑路径进行测试
        • 逻辑覆盖
        • 代表性逻辑覆盖
          • 语句覆盖
          • 判断覆盖
          • 条件覆盖
          • 判定--条件覆盖
          • 条件组合覆盖
          • 路径覆盖
      • iii. α测试：在开发环境下的测试
      • iv. β测试：由软件的多个用户在实际使用环境下进行的测试
  • 软件维护
    • 含义
      • 需要提供软件支持的全部活动，包括：① 交付前要完成的活动 → 交付后的运行计划和维护计划② 交付后的活动 → 软件修改、培训、帮助资料
    • 分类
      • 选择考点9
      • ➊ 更正性维护 → 更正交付后发现的错误
        • 设计错误
        • 程序错误
        • 数据错误
        • 文档错误
        • 有错就改
      • ➋ 适应性维护 → 使软件产品能够在变化后或变化中的环境中继续使用
        • 适应环境
      • ➌ 完善性维护 → 改进交付后产品的性能和可维护性
        • 没毛病，改进性能
      • ➍ 预防性维护 → 在软件产品中的潜在错误成为实际错误前，检测并更正它们
        • 防止出现未来错误
  • 软件质量保证和质量评价
    • 软件需求定义了软件质量特性，及确认这些特性的方法和原则；软件质量使指软件特性的总和，是软件满足用户需求的能力，包括：内部质量、外部质量、使用质量
    • 软件质量管理由许多活动组成
      • 1. 质量保证过程
      • 2. 验证与确认过程
        • 选择考点10【常考】
        • 验证：确保活动的输出产品已经被正确构造，即活动的输出产品满足活动的规范说明
        • 确认：确保构造了正确的产品，即产品满足其特定的目的
        • 注意区分：验证 → 有没有做确认 → 做的对不对
      • 3. 评审与审计过程
        • 管理评审：目的是监控进展，决定计划和进度的状态，或评价用于达到目标所用管理方法的有效性
        • 技术评审：目的是评价软件产品，以确定其对使用意图的适合性
        • 检查
        • 走查
        • 审计：目的是提供软件产品何过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价
  • 软件配置管理
    • ① 软件配置管理计划② 软件配置标识 ③ 软件配置控制 → 关注的是管理软件生命周期中的变更 ④ 软件配置状态记录⑤ 软件配置审计 ⑥ 软件发布管理与交付
  • 软件过程管理
    • 1） 项目启动与范围定义2） 项目规划3） 项目实施4） 项目监控与评审5） 项目收尾与关闭
  • 软件复用
    • 含义
      • 利用已有软件的各种有关知识构造新的软件，以缩减软件开发和维护的费用 → 把之前的东西拿来重复利用，进行二次开发
    • 作用
      • 是提高软件生产力和质量的一种重要技术
    • 主要思想：将软件看成是由不同功能的”组件“所组成的有机体，每一个组件在设计编写时可被设计成完成同类工作的通用工具
    • 应用：代码级复用、领域知识、开发经验、设计决策、架构、需求、设计、代码和文档等一切有关方面
• 本章历年真题只考选择题，占比16～17分