《信息系统分析与设计》笔记No.3

信息系统建设是复杂的社会过程

本章总结：本章以信息系统建设相关知识为主要内容，对信息系统建设的复杂性进行了多层次分析，介绍了信息系统的生命周期，分析了各种信息系统建设的方法。

写在前面：

信息系统生命周期的“五阶段”正是信息系统项目管理课程作业的发展轨迹。
在所谓“项目”启动之初，即作业一“项目启动书”，项目组还不太明白信息系统整个的研发过程，主要从现有情况出发，根据一些公开信息或文献倒推项目的启动情况，这为我们的“项目”发展埋下了很多隐患。

由于项目属于电子政务项目，项目启动书格式我们采用的是《国家电子政务工程建设项目管理暂行办法》附件一“国家电子政务工程建设项目项目建议书编制要求”的格式，在项目组进行到作业二“项目可行性报告”时，按照规定：

第八条
项目建设单位应按照《国家电子政务工程建设项目项目建议书编制要求》（附件一）的规定，组织编制项目建议书，报送项目审批部门。项目审批部门在征求相关部门意见，并委托有资格的咨询机构评估后审核批复，或报国务院审批后下达批复。项目建设单位在编制项目建议书阶段应专门组织项目需求分析，形成需求分析报告送项目审批部门组织专家提出咨询意见，作为编制项目建议书的参考。

第九条
项目建设单位应依据项目建议书批复，按照《国家电子政务工程建设项目可行性研究报告编制要求》（附件二）的规定，招标选定或委托具有相关专业甲级资质的工程咨询机构编制项目可行性研究报告，报送项目审批部门。项目审批部门委托有资格的咨询机构评估后审核批复，或报国务院审批后下达批复。

可是我们没有项目建议书批复，项目组根据一些地方的实际建设情况进行的规划，没有后续的建议和发展；更重要的是，项目建议书和项目可行性报告的编制主体不同，我们必须“分饰两角”，但在内容上已没有可发展的空间了，所以项目组把目光转向了项目管理的各个部分，按照《国家电子政务工程建设项目管理暂行办法》附件二“国家电子政务工程建设项目可行性研究报告编制要求”的相关要求，结合一些材料，拟定了一个新的目录结构，把学习研究侧重点转向项目分析，所以在最终的项目可行性报告的前言中，项目组进行了说明：

本报告的研究侧重点有三：较项目启动书更为全面的国内外发展现状分析 （正文第三章） 、较为完整的项目风险分析（包含 风险登记表 、风险分解结构、 风险分析矩阵等内容） 和 使用Project2013软件完成的 项目进度分析 。

每次作业完成过程中都能发现之前作业中的错误，从实施单位错误到参数有误，错误五花八门，要是真有项目这个样子，估计项目经理连夜跑路。

信息系统的复杂性体现在：

技术手段复杂

内容复杂，目标多样

一个组织的管理与业务信息量大、面广，形式多样、来源繁杂，信息内容和处理要求又涉及到广泛的学科和事业领域。
一个组织的信息系统必是一个规模庞大，结构复杂，具备多种功能、实现多个目标的大系统
一个组织内各类机构和人员的信息需求不尽相同，有些需求可能相互冲突，需求的不确定性和可变性非常大。
组织和外部环境之间的数据交换难以控制。

投资密度大，效益难以计算

信息系统的建设，需要巨额投资，是一种资金密集型的建设项目
智力密集型或者知识密集型
需用大量人工，是劳动密集型项目
效益难以计算

成功的含义：在规定的时间内，以规定的预算完成规定的目标。

环境复杂多变

涉及到组织内部各级机构、管理人员
涉及组织面临的外部环境及发展趋势
要考虑管理体制、管理思想、管理方法和管理手段的相互匹配、相互促进
考虑人的习惯、心理状态及现行的制度、惯例和社会、政治诸因素

信息系统开发是一个社会过程。

问题描述和方案验证不同于一般技术工程

技术工程问题明确，可以模拟，或制作实物模型、样品进行验证，信息系统的问题确定性差，难以提前验证解决方案。

人的影响

信息系统是人机系统，有来自于人的障碍。如了解、沟通、实施困难。

社会环境的影响

如政策、竞争、文化观念等对信息系统影响力很大，不同于纯技术工程。

信息系统建设的一般方法

系统方法的应用

系统科学方法为人们提供了新的思维模式，是研究复杂系统的有效工具。
钱学森曾指出“系统工程是组织管理系统的规划、研究、制造、试验和使用的科学方法，使一种对所有系统都具有普遍意义的方法”。

系统方法在信息系统建设中的应用：

1. 还原论与整体论相结合
2. 微观分析与宏观综合相结合
3. 定性判断与定量计算相结合
4. 严格生命周期阶段与反复迭代相结合

系统建模/模型化

系统模型的概念

建模（modeling）就是为描述系统的构成和行为，对现实系统的各种因素进行适当筛选，用一定方式（数学公式、符号、图形、图像等）表示现实系统的过程。
建模也称模型化。
系统模型是指以某种确定的形式（如文字、符号、图表、实物、数学公式等），对系统某一方面本质属性的描述。

管理系统模型

管理模型描述组织的状况，包括：

1. 组织的静态特征，如组织结构图、实体关系图
2. 动态特征，如任务分解图、状态转换图、甘特图、PERT图
3. 业务流程，如流程图
4. 业务规则，如决策树、决策表

信息系统模型

信息系统模型描述计算机信息系统的状况。
每种模型都有其标准符号、惯例、语法规则和用途，当这一组符号和规则形成了一套完整严谨的表示语言，就形成建模语言。
因为信息系统是为管理服务的，因此有些模型在管理系统和信息系统中通用，如流程图、状态图 、决策树/决策表等。

这么看我们的项目真的是胡闹（🤦‍）

信息系统模型的作用

1. 对复杂问题进行简化描述，帮助有关人员快速、简单直观、准确地了解系统；
2. 建模的过程使得分析师和设计师能更全面地研究系统，深思熟虑，减少遗漏，以形成更成熟的方案；
3. 各阶段产生的模型为后续阶段的有关人员提供了工作依据；
4. 为项目各类人员提供了统一的交流工具，利于沟通和团队合作；
5. 为项目验收和将来的维护工作提供了文档依据；
6. 利用工具将模型映射为特定平台的可执行代码（MDD，Model-Driven Development），减少开发人员工作量。

统一建模语言UML

统一建模语言UML（unified modeling language）是由单一元模型支持的一组图示法。这些图示法有助于表达与设计软件系统，特别是采用面向对象方法构造的软件系统。
UML通过不同的图来描述系统的结构（structure）、行为（behavior）、交互过程（interaction）。
UML 2.2中一共定义了14种图（diagram）：

1. 系统结构：类图、对象图、包图、构件图、部署图等
2. 系统行为：活动图、状态图、用例图
3. 交互过程：通信图、顺序图、计时图等

我读了一篇CSDN上的UML入门博客，什么叫做专业，这就叫专业（战术后仰）
https://blog.csdn.net/qq_35495763/article/details/80764914

差点就找软件之类的学学了，顺手上知乎搜了一下（昨天刚看半佛老师恰了知乎的饭），看看实用性。

UML的问题在于，作为图型这货太复杂，作为语言这货没卵用，没有编译器和IDE支持或者说相较于程序设计语言支持就是个渣渣……其实是一个很奇怪的东西，这货对于程序员来说，程序员会觉得画这玩意儿还不如写代码来生成这玩意儿。对于非程序员的领域建模人员来说，这货的各种符号和箭头过于专业，很多东西与程序实现强相关与领域关系不大。在不同的领域所需要的东西又没有标准化……
作者：Ivony
链接：https://www.zhihu.com/question/23569835/answer/651489599
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

那只用来画流程图是不是有点大材小用？那还是乖乖用思维导图吧。

信息系统的生命周期

信息系统开发围绕信息系统生命周期来进行，有时也称系统开发生命周期（SDLC，System Development Life Cycle），体现系统工程的思想。

五阶段

1. 系统规划
   确定信息系统的发展规划；企业业务流程的识别、改革与创新；对建设新系统的需求作出初步研究，确定信息系统的总体结构；确定系统的备选方案，对这些方案进行可行性分析
2. 系统分析
   详细调查，确定系统的基本目标和逻辑功能要求
3. 系统设计
   根据系统说明书中规定的功能要求，考虑实际条件，具体设计实现逻辑模型的技术方案
4. 系统实施
   计算机等设备的购置、安装和调试；编写、调试和测试程序；人员培训；数据准备或转换；系统调试与转换
5. 系统维护
   运行情况的记录；必要的修改；评价和总结等

信息系统开发方法

信息系统的开发方法从两个维度分类：

开发过程（霍尔三维结构的时间维度）
信息系统开发过程可以根据特点按照系统工程阶段和步骤有变种，也称为不同的生存周期模型。
方法将包含整个开发的步骤，每个步骤的任务，由什么人完成，任务的成果如何体现等内容。

开发技术及模型（知识维度和逻辑维度）
不同的建模方法，从不同的观点来反映系统的全貌，运用学科知识和技术手段予以实现（主要是由信息技术推动的方法论体系）。

基于生命周期的开发方法

瀑布开发方法

适用于一些需求已明确并且变化较少的信息系统

需求：客户常常难以表达真正的需求，而这种模型却要求严格的阶段性成果，返工困难，变更代价很大
风险：客户要等到开发周期的晚期才能看到程序运行的测试版本，这时若发现大的错误，可能引起客户的惊慌，其后果也可能是灾难性的
效率：因为前后任务的依赖关系，成员不能并行工作，有可能花在等待的时间比开发的时间要长，即所谓的“堵塞状态”

原型开发方法

快速建立起来的可以在计算机上运行的程序，通常选取信息系统中某个关键功能作为原型。

迭代开发方法

先提交一个有限的版本，细节部分逐步增加，即多次迭代后完成系统。

有两种迭代：

1. 迭代增量：迭代周期完成一个增量，然后集成

   

2. 迭代进化：迭代周期内包含演化和完善

   进化迭代与增量迭代的区别是在每个迭代周期是对上一次迭代的演化和完善。
   比如可以将一个软件功能的编程划分了多个迭代周期，每个迭代是对该功能的补充和进化。

增量模型 (Incremental Model) 是您在部分中构建整个解决方案的地方，但是在每个阶段或部分结束时您没有, 任何可以审查或反馈的东西。您需要等到增量过程的最后阶段才能交付最终产品。

这个增量模型让我想到了贾跃亭，还没到最后一步先窒息了233333

迭代模型 (Iterative Model) 是我们迭代这个想法并在迭代各种版本时不断改进的地方。你从一个版本移动到另一个版本你决定（根据反馈）在新版本中需要什么作为更好的选择以及需要丢弃什么。

来源：CSDN《项目生命周期之迭代和增量的区别》，如有侵权请联系删除。
https://blog.csdn.net/Anita0928/article/details/98473604

螺旋开发方法

把软件开发过程定义成不断上升的螺旋周期，每个周期划分为计划、风险分析、实施和评价四个方面。沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。

有点像PDCA？

敏捷开发方法

敏捷过程（agile process）是一系列轻量的过程模型的总称，致力于在无过程和过于繁琐的过程中达到一种平衡，强调对需求变化的敏捷响应，以不多的步骤过程获取满意的结果。

基于开发技术的开发方法

软件结构从简单到复杂，走过了从机器指令、语句、模块封装到类封装、再到构件和服务封装的历史发展过程，不同的开发技术和软件结构催生了不同的开发方法。

基于软件技术的开发方法：

结构化开发方法

也称为 面向功能/面向过程/面向数据流 的软件开发方法

阶段	内容
结构化分析（Structured Analysis，简称SA）	对软件进行需求分析，以数据流图表示
结构化设计（Structured Design，简称SD）	–进行总体设计，以结构图表示
结构化程序设计（Structured Program，简称SP）	–以程序流程图表示

面向数据开发方法

面向对象开发方法

面向对象(object-oriented)方法具有很强的类和对象的概念，因此它就能很自然地直观地模拟人类认识客观世界的方式。

面向服务开发方法

面向服务的体系结构（Service-Oriented Architecture，SOA）以服务为软件组成要素，服务对外定义良好的接口和契约，独立于实现服务的硬件平台、操作系统和编程语言。

信息系统开发的组织管理

信息系统建设要执行有计划的管理：

1. 信息系统发展的诺兰模型
2. 建立信息系统的基础条件
3. 信息系统建设的相关人员
4. 做好准备工作
5. 选择开发方式
6. 开展项目管理

信息系统开发工具（CASE工具）

信息系统开发工具指在系统开发生命周期各个阶段帮助开发者提高工作质量和效率的一类软件，也称为CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具。