信息系统管理师笔记之信息系统基础

Posted 2023-02-17 Xiao冰同学

信息系统管理师笔记之信息系统基础

系统开发的生命周期一般分为 5个阶段
总体规划阶段（9%）：交付可行性分析报告
系统分析阶段（15%）：系统方案说明书
系统设计阶段（20%）：系统设计说明书
系统实施阶段（50%）：
系统运行和评价阶段（8%）：

管理信息系统规划的主要方法
关键成功因素法（Critical Success Factors CSF）
通过分析找出企业成功的关键因素，然后围绕出这些因素来确定系统的需求，并进行规划
一个组织的信息需求取决于少数管理者的关键性成功因素
关键性成功因素是由行业 、企业、管理者以及周围环境形成的
在关键性成功因素分析中使用的主要方法是面谈

战略目标集转化法（Strategy Set Transformation SST）
把整个战略目标看成是一个“信息集合”，由使命、目标、战略和其他战略变量等组成
MIS的战略规划过程是把组织的战略目标转化为管理信息系统战略目标的方法
识别组织的战略集
描绘出组织各类人员结构
识别每类人员的目标
对于每类人员识别系统相应的使命及战略
将组织战略集转化为信息系统战略
根据组织目标确定信息系统目标
对应组织战略集的元素识别相应信息系统战略的约束
根据信息系统目标和约束提出信息系统战略

企业系统规划法（Business System Planning BSP）
确定出未来系统的总体结构，明确系统的子系统组成和开发子系统的先后顺序
对数据进行统一规划、管理和控制，明确各子系统之间的数据交换关系，保证信息的一致性

什么是U/C矩阵
　　U/C矩阵是用来表达过程与数据两者之间的关系。矩阵中的行表示数据类，列表示过程，并以字母U（Use）和C（Create）来表示过程对数据类的使用和产生。
　　U/C矩阵是MIS开发中用于系统分析阶段的一个重要工具。提出了一种用关系数据库实现U/C矩阵的方法，并对其存储、正确性检验、表上作业等做了分析，同时利用结果关系进行了子系统划分。
　　U/C矩阵是一张表格。它可以表数据/功能系统化分析的结果。它的左边第一列列出系统中各功能的名称，上面第一行列出系统中各数据类的名称。表中在各功能与数据类的交叉处，填写功能与数据类的关系。

U/C矩阵的正确性的检验
U/C矩阵的正确性，可由三方面来检验：
完备性检验。这是指每一个数据类必须有一个产生者(即“C”) 和至少有一个使用者(即“U”) ；每个功能必须产生或者使用数据类。否则这个U/C矩阵是不完备的。
一致性检验。这是指每一个数据类仅有一个产生者，即在矩阵中每个数据类只有一个“C”。如果有多个产生者的情况出现，则会产生数据不一致的现象。
无冗余性检验。这是指每一行或每一列必须有“U” 或“C”，即不允许有空行空列。若存在空行空列，则说明该功能或数据的划分是没有必要的、冗余的。
　　将U/C矩阵进行整理，移动某些行或列，把字母“C” 尽量靠近U/C矩阵的对角线，可得到C符号的适当排列。
U/C矩阵的主要功能
通过对U/C矩阵的正确性检验，及时发现前段分析和调查工作的疏漏和错误。
通过对U/C矩阵的正确性检验来分析数据的正确性和完整性。
通过对U/C矩阵的求解过程最终得到子系统的划分。
通过对子系统之间的联系(“U”)可以确定子系统之间的共享数据。

软件开发的方法：结构化方法、原型法
软件开发的模型：瀑布模型、螺旋模型、

信息完整性是指信息在输入和传输过程中，不被非法授权修改和破坏，保证数据的一致性
信息可靠性是指信息与预期行为一致的特性
信息可验证性是指表征对自己的动作和做出的决定负责的一种特性
信息保密性是指信息不能被未授权的个人、实体或者过程利用或知悉的特性

信息系统的种类
实时信息系统
系统需要及时响应外界事件的请求，并在规定的严格时间内完成对事件的处理
批处理信息系统
作业成批处理和多道程序运行，即在系统内同时存放并运行几道项目独立的程序、由系统成批处理

DFD （Data Flow Diagram）数据流图或数据流程图，是描述系统中数据流程的一种图形工具，标志了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理

所有软件需求的一个基本特征就是可验证性
业务需求(Business Requirement)：反映了组织机构或客户对系统、产品高层次的目标要求
用户需求(User Requirement):描述了用户使用产品必须完成的任务
功能需求(Functional Requirement) 定义了开发人员必须实现的软件功能s

需求分析的目的
1:检测和解决需求之间的冲突
2:发现软件的边界，以及软件与其环境如何交互
3:详细描述系统需求、以导出软件需求

描述需求时应该精确到 确认需求、验证需求的实现、估算需求的成本

使用结构化SA方法进行需求分析、其建立的模型的核心是数据字典、围绕这个核心、有三个层次的模型，分别是数据模型、功能模型和行为模型。实际工作中，一般使用 实体联系图 (E-R图)来表示数据模型，用数据流图(Data Flow Diagram DFD)表示功能模型，用状态图(State transform Diagram STD)来表示行为模型

软件的审计的目的是提供软件产品和过程对于可应用的规则，标准，指南、计划和流程的遵从性的独立评价

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径

螺旋模型是快速原型模型以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。该模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。用螺旋模型的软件过程如下

瀑布模型，一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段

PDPC (过程决策程序图) 用于理解

SPI (Software process Improvement) 软件过程改进
五大原则
注重问题
强调知识创新
鼓励参与
领导层的统一
计划不断地改进

数据操作
数据集成： 将多个数据源中的数据合并并存放在一个一致的数据仓库中
数据清洗： 将重复多余的数据筛选清楚，将缺失的数据补充完整，将错误的数据纠正或者删除吧 ，最后整理成为我们可以进一步加工、使用的数据
数据变换：将数据转换或统一成适合挖掘的形式
数据归纳：缩小数据的取值范围，使其更适合于数据挖掘算法的需要。

需求类型
《计算机软件需求说明编制指南》GB/T9385 中
功能需求：描述软件产品的输入怎样变换成输出即软件必须要完成的基本动作
性能需求：从整体来说本软件或人于软件交互的静态或动态数值需求
设计需求：设计约束受其他标准、硬件限制等方面的影响
属性：

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

UML（4+1）视图
Philippe Krunchten 提出 4+1视图模型
逻辑视图/设计视图：主要支持系统的功能需求，它直接面向最终用户
开发视图/实现视图：主要支持软件模块的组织和管理，它直接面向编程人员
进程视图：主要关注一些非功能的需求，如系统的性能和可用性等，它直接面向系统集成人员
物理视图/实施视图：主要关注如何把软件映射到硬件上，通常要解决系统的拓扑结构、系统安装和通信等问题、它直接面向系统工程人员
场景视图/用例视图：重要系统活动的抽象描述，可以使上面4个视图有机联系起来，可认为是最重要的需求抽象

CMMI (Capability Maturity Model Intergration) 软件能力成熟模型改善
CMMI 一级，完成级，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是任务完成带有很大的偶然性、企业无法保证实施同类项目的时候能完成任务。企业在一级上的项目实施对实施人员有很大的依赖性

CMMI 二级，管理级，企业在项目实施上能遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制
CMMI 三级，定义级，在定义级水平上企业不仅能够对项目的实施有一定的一整套流程规范，并保障项目的完成，
CMMi 四级，量化管理级，在量化管理水平上，企业的项目管理不仅形成了一种制度，而且要实现数字级的管理，对管理做到量化和数字化
CMMI 五级 持续优化级

过程和质量保证的目的是 使工作人员和管理者客观了解过程和相关的工作产品，从而支持交付高质量的产品和服务

连续式表示法： 相对单个过程域，使用能力等级来描述组织过程状态的特征
阶段式表示法：相对模型整体，使用成熟度级别来描述组织过程总体状态的特征

设计范式
设计范式（范式、数据库设计范式（符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系型数据库中，这种规则就是范式。
范式级别越高，存储同样的数据就需要分解成更多张表
范式级别越高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降
范式级别越高，需求变化时数据的稳定性越差
范式级别越高，需要访问的表增多，性能下降

面向对象技术
类之间的关系：包括关联、依赖、泛化、实现

软件工程
结构设计是定义系统各主要组件关系
数据设计是根据分析模型转化为数据结构
接口设计是描述如何通信
过程设计系统结构部件转化为软件的过程性描述

代码审计：由某人、某小组或借助某种工具对源代码进行的独立的审查，以验证其是否符合软件设计文件和程序设计标准，还可能对正确性和有效性进行估计。
走查：静态分析技术或评审过程，在此过程中，设计者或程序员引导开发组的成员通读已书写的设计或者代码，其他成员负责提出问题，并对有关技术风格、可能的错误、是否违背开发标准等方面进行评论

功能性：适宜性、准确性、互用性、依从性、安全性
可靠性：成熟型、容错性、可恢复性
可用性：可理解性、易学性、可操作性
效率：时间特性、资源特性
可维护性：可分析、可修改、稳定性、可测试行性
可移植性：适应性、易安装性、一致性、可替换性

测试流程
测试人员发现Bug后，判断属于哪个模块的问题，填写BUG报告后，然后通知开发组长和该模块开发者
开发组长根据具体情况，重新分配给BUG所属的开发者
开发者收到通知后，判断是否属于自己的修改范围，如果不是，重新分配给开发组长或者应该分配的开发者，如果是，进行处理，解决问题并给出解决方法
测试人员查询开发者已经修改的BUG，进行回归测试，经验证无误后，修改状态为验证通过，待整个产品发布后，关闭BUG

EAI（Enterprise Application Intergration） 企业应用集成
表示集成：表示集成也称为界面集成，这是比较原始和最浅显的集成，也是最常用的集成
控制集成：功能集成或应用集成，是在业务逻辑层上对应用系统进行集成，集成点在程序代码上，集成处可能只需要简单使用公开的API就可以访问
数据集成：为了完成控制集成和业务流程集成，必须首先解决数据和数据库的集成问题，在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型，保证数据在数据库系统中分布和共享。因此，数据集成也是白盒集成
业务流程集成：也称为过程集成，这种集成超越超越数据和系统，它由一系列基于标准的，统一数据格式的工作流组成，当进行业务流程集成时，企业必须对各种业务信息的交换进行定义，授权和管理，以便改进操作、减少成本、提高响应速度

信息安全