导图社区 六、建设信息系统
- 61
- 举报
六、建设信息系统
管理信息系统第六章建设信息系统知识梳理，包括信息系统开发视为有计划的组织变更、信息系统开发过程中的核心活动、系统建模与设计、构建信息系统可选用的方法等等。
编辑于2022-09-28 19:17:49- 管理信息系统
- 双语版思维导图
- 建设信息系统
- 相似推荐
- 大纲
六、建设信息系统
信息系统开发视为有计划的组织变更P513
当我们在设计一个新的信息系统，就是对组织的再设计
建造一个新的信息系统就是对组织进行有计划的变更
系统开发和组织变更
IT的应用就是多种程度的组织改变
四种结构化的组织变革
自动化 automation
信息科技的第一个应用协助雇员更高效的执行工作 3个例子
组织变革中的最常见的形式
合理化 rationalization
程序合理化
程序合理化就是理顺标准化操作过程(SOP)
一系列持续的组织质量改善
整体质量管理TQM：全员参与
six sigma：对质量的评价测量，3.4defects per million opportunity 。。。。大多数企业无法达到这种标准，但以它为目标可以促进质量改善
局限于企业的某些特定部分
业务流程再设计/再造 business process redesign
一个比较有用的组织变革形式
业务流程被分析，总结和再设计 业务流程再社会组织工作流 痛点：减少浪费和消除重复的密集型的任务
比程序合理化更激进的组织变革
范式转移 paradigm shifts
激进，影响更深远的组织变革形式
回报大，但风险高，失败的可能性大
重新思考组织和业务的性质
组织变革最根本radical的形式
从A-R-B-p，回报↑，风险↑
业务流程再造 BPR
业务流程管理BPM
提供了一系列工具和方法去分析存在的流程，设计新的流程和优化这些流程
从不会结束因为流程改进需要持续的改变
5个步骤
识别需要进行变革的业务流程
最重要的一个战略决定
需要话费许多时间和成本，但回报可能很小
分析现存业务流程中存在的问题
买书的建模分析
设计新的业务流程
新的流程设计需要合理的展示减少了多少时间和成本或者改进顾客服务和价值
实施新的业务流程
连续不断的评估与衡量
流程改进优化后，需要持续不断的测量
信息系统开发过程中的核心活动
新的信息系统是组织问题解决过程中的产物
信息系统的开发：产生信息系统来解决组织性问题和威胁的活动，一系列核心活动的集合 通常依次sequential发生，但是有点会被重复或同时simultaneously发生
六个
标注
系统分析systems analysis
四个步骤
定义问题
辨别原因
确认解决方案
识别信息需求
systems analyst系统分析师
创建现有组织和系统的路径图
确定信息，硬件，软件的主要所有者和使用者
详细分析现有系统中存在的问题
feasibility study（可行性分析）
系统分析最具挑战性的工作
三个角度
财务：是否像预期那样是一个好投资
技术：系统的技术需要是否是可获得的和可把握的，被公司信息系统的专家
组织：组织是否可以处理挑战
系统需求分析
错误的分析
公司破产
大程度的修改
确定谁需要信息，何时何地，如何
目的：分析组织利用信息系统来解决的问题
系统设计systems design
展示系统如何完成它的目标
设计内容
超前的计划和模型
包含所有的具体规格要求
终端用户的作用：驱动整个系统的构建过程
编程programing
系统的设计阶段讲具体的规格要求转化为软件程序编码
外部源的具体表现形式
软件包
外包企业
软件服务
测试3种testing
unit testing单元测试：包括测验系统中分散的各个程序单元，此类型测验普遍被认为是确保程序是无缺陷的，但这个目标实际上不大可能
system testing系统测试：测验信息系统整体功能。①确定各个模块是否会按照计划共同运行②确定系统设计和实际运行之间是否存在矛盾
acceptance testing验收测试：是对系统能否用于生产进行最后的确认，验收测验结果将被用户评估，管理层复审
测验计划test plan
检测系统是否产生预期结果 费时，必须精心准备测试数据，检查结果 忽略某一步风险是巨大的 回答了系统是否产生了在已知条件下要求的结果
系统开发的完成阶段
切换4种conversion
并行策略 parallel strategy
新旧系统同时运行一段时间直到所有人确认新系统可以正常运行
最保险的转化策略，但成本很高
直接切入策略direct cutover strategy
在指定某一天直接用新系统完全代替旧系统
风险很高risky，若新系统出了问题，成本讲比运行新旧两个系统还高
引导策略pilot study strategy
引入新系统仅应用于组织的局部，如单个部门或操作单元
同时或分阶段在其他部门安装
分阶段策略phased approach strategy
按照职能或者按照组织单元分阶段引入新系统
从老系统更换到新系统的过程 新旧系统的切换需要培训终端用户使用新系统 说明书documentation：从技术和终端用户的角度介绍系统是如何使用与运行的，以用于培训和日常运营
运行和维护production and maintenance
production：用户和技术专家会检查系统，以确定系统在多大程度上到达了初始目标，从而决定是否要安排修改和修正
maintenance：改进一个运行系统的硬件软件，文件或程序，以纠正错误，满足新的需求和提高运营效率的一系列活动
维护时间
20%用来测验或者解决突发的产品问题
20%改进数据，文件，报告，硬件或者系统软件
60%提高用户满意度，改进文档以及记录系统各组件的工作以提高运行效率
通过更好的系统分析和设计实践，显著的减少第三类维护所花费的时间
通常同时的反复进行
系统建模与设计
结构化方法（structured methodologies）
对程序建模很有效，但对 于数据建模的效果不佳。 数据和处理程序分离。 分析采用数据流程图，设计采用 结构图
20世纪70年代以来，结构化方法就被用来记录，分享和设计信息系统
结构化：其中的技术是逐步实施的，每一个工作都是建立在上一个工作的基础之上
自上而下的（top-down）
面向过程的，主要集中在信息流经系统时收集，存储，加工和分配信息的流程或活动建模。将数据从程序中独立出来
数据流程图（data flow diagram）DFD
描述系统各组件处理及其之间数据流的主要工具
①为信息流提供了逻辑图形模型 ②严格指明每一模块内和接口处发生的数据处理和转换
圆角矩形rounded boxex，直角矩形square box，开口的矩形open rectangles，箭头arrows
数据字典
包含了系统各自独立的数据和数据集
定义了数据流的内容和数据存储
流程的规格说明（process specification）：描述了数据流程图最低层次结构中出现的转变
分层次结构图 hierarchical structure charts
软件设计
自上而下的层次图，展示了每一层的设计，每一层和其它层次的关系，以及每一层在整个设计结构中的位置
面对对象的开发object-oriented development
面向对象的开发比传统结构 化开发更具迭代性和增量性
面向对象的设计阶段讲描述对象的 作用以及对象之间是如何交互的
将对象作为系统分析和设计的基本单元
对象包含了数据以及运营这些数据的具体流程，封装在对象中的数据只能被与这个对象相关的操作和方法存取更改
信息系统被视为对象和对象关系之间关系组成的集合，对象之间还需要进行配合以使系统正常运行
面向对象建模建立在类和继承概念的基础上。对象属于一个有特定的类或有着所属类特征的相同类。类也可以继承上一级更一般类的所有结构和行为，还可以在其每个对象中加入特有的变量（variables)和行为
建立新的类的对象：先选择一个现有类，然后分析新的类个现有类有哪些不同再做出改进，而不用每次都重新设计
类名（class name）在方框的顶部，属性（attributes)在方框的中部，操作则在底部的每一个方框中
最终的系统必须经过彻底测验和评估
对象可以重复使用
计算机辅助软件工程 CASE computer-Aided software engineering
是一种提供软件工具以实现自动化从而减少开发者重复工作的方法
CASE工具可以帮忙创建清晰文档，并协调开发团队工作
提供自动化图形工具
提高工作效率和质量的方法
有效验证设计图标和说明书specifications
开发项目中的每个成员都要遵守一套通用的命名规格，标准，开发方法
构建信息系统可选用的方法
每个系统在规模，技术复杂度和需 要解决的组织问题方面都是不同的
传统的生命周期法 systems life cycle
构建信息系统最传统的方法
在最终用户和信息系统专家之间有着正式的分工。系统分析师：负责分析设计，系统实施工作。终端用户：仅提供系统信息需求，检阅技术人员的工作
分阶段，通常六个，系统开发的六个核心活动
强调正式的说明书和文档
瀑布型方法：上一个阶段工作完成以后才能开始下一阶段的工作
用来构建大型复杂的系统，这些系统往往需要严格且正式的系统需求分析和预定义说明 不适合许多小型的桌面系统，以为起通常欠缺结构性且更强调个性化
缺点：成本高，费时和不灵活
原型法 prototyping 。。。。
比较省时省钱，系统 开发者可以多次迭代
先构建一个低成本原型系统攻终端用户评估，通过和原型系统交互，用户可以更好地厘清信息需求，作为一个临时版本
原型prototype：是信息系统的一个工作版本，但只是一个初步的模型
迭代iterative：构建初步设计，尝试，精炼和重新设计的过程，这些构建系统的步骤可以重复。原型法比生命周期法更容易迭代，更容易支持系统设计的改变
原型法使有计划的迭代取代了无规则的重复设计，是每个版本都能更准确的反映用户需求
步骤
确定用户的基本需求
开发初步原型
使用原型
修改并补强原型：重复步骤3和步骤四，直至满足用户需求
优缺点
优点：当对需求和设计方法不明确时，原型法最有效 通常用来设计信息系统的终端用户界面（end-user interface） 更可能的满足用户需求
缺点：容易忽略系统开发过程中的一些关键步骤 像这样一些快速构建的系统，可能会很难适应有大量数据和大量用户的开发环境
终端用户开发法 end-user development
可以由终端用户开发，只需要很少甚至是不需要来自技术专家的帮助，基于第四代语言的一系列软件工具是终端用户自行开发得以实现
第四代语言
特点
非流程化
可操作性比较强
流程化语言与非流形化语言的区别
分类
比生命周期法速度快。用户能详细说明业务需求，可以提高所收集的信息质量，但是容易造成组织风险
应用软件包 application software packages
通过使用软件包内预先编写，预先设计和预先测试好了的软件程序，组织可以节省时间和成本
有些公司会对软件包内所没有的功能有额外要求，很多软件包都提供定制化服务的功能 定制（customization）这一特性使软件包可以满足不同公司独特的需求，同时也不会破坏软件包的完整性
软件包的评估工作往往基于需求清单（request for proposal）RFP是提交给软件包供应商的一份详细问题列表
确定使用某个软件包后，公司也就失去了对系统设计的全面控制。系统设计工作将不是修改系统设计以满足用户需求，而是影响用户需求以适应软件包功能特色
外包 outsourcing
云计算和SaaS是外包形式的一种，租用服务供应商提供的软件，硬件资源作为系统的技术平台
另一种形式，请一家外部供应商为自己设计和构建软件系统
离岸外包offshore outsourcing，由成本驱动
比较辨析：p3p MIPS TQM
六、建设信息系统
信息系统开发视为有计划的组织变更P513
当我们在设计一个新的信息系统，就是对组织的再设计
建造一个新的信息系统就是对组织进行有计划的变更
系统开发和组织变更
IT的应用就是多种程度的组织改变
四种结构化的组织变革
自动化 automation
信息科技的第一个应用协助雇员更高效的执行工作 3个例子
组织变革中的最常见的形式
合理化 rationalization
程序合理化
程序合理化就是理顺标准化操作过程(SOP)
一系列持续的组织质量改善
整体质量管理TQM：全员参与
six sigma：对质量的评价测量，3.4defects per million opportunity 。。。。大多数企业无法达到这种标准，但以它为目标可以促进质量改善
局限于企业的某些特定部分
业务流程再设计/再造 business process redesign
一个比较有用的组织变革形式
业务流程被分析，总结和再设计 业务流程再社会组织工作流 痛点：减少浪费和消除重复的密集型的任务
比程序合理化更激进的组织变革
范式转移 paradigm shifts
激进，影响更深远的组织变革形式
回报大，但风险高，失败的可能性大
重新思考组织和业务的性质
组织变革最根本radical的形式
从A-R-B-p，回报↑，风险↑
业务流程再造 BPR
业务流程管理BPM
提供了一系列工具和方法去分析存在的流程，设计新的流程和优化这些流程
从不会结束因为流程改进需要持续的改变
5个步骤
识别需要进行变革的业务流程
最重要的一个战略决定
需要话费许多时间和成本，但回报可能很小
分析现存业务流程中存在的问题
买书的建模分析
设计新的业务流程
新的流程设计需要合理的展示减少了多少时间和成本或者改进顾客服务和价值
实施新的业务流程
连续不断的评估与衡量
流程改进优化后，需要持续不断的测量
信息系统开发过程中的核心活动
新的信息系统是组织问题解决过程中的产物
信息系统的开发：产生信息系统来解决组织性问题和威胁的活动，一系列核心活动的集合 通常依次sequential发生，但是有点会被重复或同时simultaneously发生
六个
标注
系统分析systems analysis
四个步骤
定义问题
辨别原因
确认解决方案
识别信息需求
systems analyst系统分析师
创建现有组织和系统的路径图
确定信息，硬件，软件的主要所有者和使用者
详细分析现有系统中存在的问题
feasibility study（可行性分析）
系统分析最具挑战性的工作
三个角度
财务：是否像预期那样是一个好投资
技术：系统的技术需要是否是可获得的和可把握的，被公司信息系统的专家
组织：组织是否可以处理挑战
系统需求分析
错误的分析
公司破产
大程度的修改
确定谁需要信息，何时何地，如何
目的：分析组织利用信息系统来解决的问题
系统设计systems design
展示系统如何完成它的目标
设计内容
超前的计划和模型
包含所有的具体规格要求
终端用户的作用：驱动整个系统的构建过程
编程programing
系统的设计阶段讲具体的规格要求转化为软件程序编码
外部源的具体表现形式
软件包
外包企业
软件服务
测试3种testing
unit testing单元测试：包括测验系统中分散的各个程序单元，此类型测验普遍被认为是确保程序是无缺陷的，但这个目标实际上不大可能
system testing系统测试：测验信息系统整体功能。①确定各个模块是否会按照计划共同运行②确定系统设计和实际运行之间是否存在矛盾
acceptance testing验收测试：是对系统能否用于生产进行最后的确认，验收测验结果将被用户评估，管理层复审
测验计划test plan
检测系统是否产生预期结果 费时，必须精心准备测试数据，检查结果 忽略某一步风险是巨大的 回答了系统是否产生了在已知条件下要求的结果
系统开发的完成阶段
切换4种conversion
并行策略 parallel strategy
新旧系统同时运行一段时间直到所有人确认新系统可以正常运行
最保险的转化策略，但成本很高
直接切入策略direct cutover strategy
在指定某一天直接用新系统完全代替旧系统
风险很高risky，若新系统出了问题，成本讲比运行新旧两个系统还高
引导策略pilot study strategy
引入新系统仅应用于组织的局部，如单个部门或操作单元
同时或分阶段在其他部门安装
分阶段策略phased approach strategy
按照职能或者按照组织单元分阶段引入新系统
从老系统更换到新系统的过程 新旧系统的切换需要培训终端用户使用新系统 说明书documentation：从技术和终端用户的角度介绍系统是如何使用与运行的，以用于培训和日常运营
运行和维护production and maintenance
production：用户和技术专家会检查系统，以确定系统在多大程度上到达了初始目标，从而决定是否要安排修改和修正
maintenance：改进一个运行系统的硬件软件，文件或程序，以纠正错误，满足新的需求和提高运营效率的一系列活动
维护时间
20%用来测验或者解决突发的产品问题
20%改进数据，文件，报告，硬件或者系统软件
60%提高用户满意度，改进文档以及记录系统各组件的工作以提高运行效率
通过更好的系统分析和设计实践，显著的减少第三类维护所花费的时间
通常同时的反复进行
系统建模与设计
结构化方法（structured methodologies）
对程序建模很有效，但对 于数据建模的效果不佳。 数据和处理程序分离。 分析采用数据流程图，设计采用 结构图
20世纪70年代以来，结构化方法就被用来记录，分享和设计信息系统
结构化：其中的技术是逐步实施的，每一个工作都是建立在上一个工作的基础之上
自上而下的（top-down）
面向过程的，主要集中在信息流经系统时收集，存储，加工和分配信息的流程或活动建模。将数据从程序中独立出来
数据流程图（data flow diagram）DFD
描述系统各组件处理及其之间数据流的主要工具
①为信息流提供了逻辑图形模型 ②严格指明每一模块内和接口处发生的数据处理和转换
圆角矩形rounded boxex，直角矩形square box，开口的矩形open rectangles，箭头arrows
数据字典
包含了系统各自独立的数据和数据集
定义了数据流的内容和数据存储
流程的规格说明（process specification）：描述了数据流程图最低层次结构中出现的转变
分层次结构图 hierarchical structure charts
软件设计
自上而下的层次图，展示了每一层的设计，每一层和其它层次的关系，以及每一层在整个设计结构中的位置
面对对象的开发object-oriented development
面向对象的开发比传统结构 化开发更具迭代性和增量性
面向对象的设计阶段讲描述对象的 作用以及对象之间是如何交互的
将对象作为系统分析和设计的基本单元
对象包含了数据以及运营这些数据的具体流程，封装在对象中的数据只能被与这个对象相关的操作和方法存取更改
信息系统被视为对象和对象关系之间关系组成的集合，对象之间还需要进行配合以使系统正常运行
面向对象建模建立在类和继承概念的基础上。对象属于一个有特定的类或有着所属类特征的相同类。类也可以继承上一级更一般类的所有结构和行为，还可以在其每个对象中加入特有的变量（variables)和行为
建立新的类的对象：先选择一个现有类，然后分析新的类个现有类有哪些不同再做出改进，而不用每次都重新设计
类名（class name）在方框的顶部，属性（attributes)在方框的中部，操作则在底部的每一个方框中
最终的系统必须经过彻底测验和评估
对象可以重复使用
计算机辅助软件工程 CASE computer-Aided software engineering
是一种提供软件工具以实现自动化从而减少开发者重复工作的方法
CASE工具可以帮忙创建清晰文档，并协调开发团队工作
提供自动化图形工具
提高工作效率和质量的方法
有效验证设计图标和说明书specifications
开发项目中的每个成员都要遵守一套通用的命名规格，标准，开发方法
构建信息系统可选用的方法
每个系统在规模，技术复杂度和需 要解决的组织问题方面都是不同的
传统的生命周期法 systems life cycle
构建信息系统最传统的方法
在最终用户和信息系统专家之间有着正式的分工。系统分析师：负责分析设计，系统实施工作。终端用户：仅提供系统信息需求，检阅技术人员的工作
分阶段，通常六个，系统开发的六个核心活动
强调正式的说明书和文档
瀑布型方法：上一个阶段工作完成以后才能开始下一阶段的工作
用来构建大型复杂的系统，这些系统往往需要严格且正式的系统需求分析和预定义说明 不适合许多小型的桌面系统，以为起通常欠缺结构性且更强调个性化
缺点：成本高，费时和不灵活
原型法 prototyping 。。。。
比较省时省钱，系统 开发者可以多次迭代
先构建一个低成本原型系统攻终端用户评估，通过和原型系统交互，用户可以更好地厘清信息需求，作为一个临时版本
原型prototype：是信息系统的一个工作版本，但只是一个初步的模型
迭代iterative：构建初步设计，尝试，精炼和重新设计的过程，这些构建系统的步骤可以重复。原型法比生命周期法更容易迭代，更容易支持系统设计的改变
原型法使有计划的迭代取代了无规则的重复设计，是每个版本都能更准确的反映用户需求
步骤
确定用户的基本需求
开发初步原型
使用原型
修改并补强原型：重复步骤3和步骤四，直至满足用户需求
优缺点
优点：当对需求和设计方法不明确时，原型法最有效 通常用来设计信息系统的终端用户界面（end-user interface） 更可能的满足用户需求
缺点：容易忽略系统开发过程中的一些关键步骤 像这样一些快速构建的系统，可能会很难适应有大量数据和大量用户的开发环境
终端用户开发法 end-user development
可以由终端用户开发，只需要很少甚至是不需要来自技术专家的帮助，基于第四代语言的一系列软件工具是终端用户自行开发得以实现
第四代语言
特点
非流程化
可操作性比较强
流程化语言与非流形化语言的区别
分类
比生命周期法速度快。用户能详细说明业务需求，可以提高所收集的信息质量，但是容易造成组织风险
应用软件包 application software packages
通过使用软件包内预先编写，预先设计和预先测试好了的软件程序，组织可以节省时间和成本
有些公司会对软件包内所没有的功能有额外要求，很多软件包都提供定制化服务的功能 定制（customization）这一特性使软件包可以满足不同公司独特的需求，同时也不会破坏软件包的完整性
软件包的评估工作往往基于需求清单（request for proposal）RFP是提交给软件包供应商的一份详细问题列表
确定使用某个软件包后，公司也就失去了对系统设计的全面控制。系统设计工作将不是修改系统设计以满足用户需求，而是影响用户需求以适应软件包功能特色
外包 outsourcing
云计算和SaaS是外包形式的一种，租用服务供应商提供的软件，硬件资源作为系统的技术平台
另一种形式，请一家外部供应商为自己设计和构建软件系统
离岸外包offshore outsourcing，由成本驱动
比较辨析：p3p MIPS TQM