信息系统集成专业技术知识.docx
《信息系统集成专业技术知识.docx》由会员分享，可在线阅读，更多相关《信息系统集成专业技术知识.docx（70页珍藏版）》请在冰豆网上搜索。
信息系统集成专业技术知识
信息系统集成专业技术知识
系统集成项目是根据用户的需求、优选各种技术产品，进行设计开发，将各个分离的“信息孤岛”连接、集成为一个完整、可靠、经济和有效的整体，并使之能彼此协调工作，发挥整体效益，达到整体优化的目的。
3.1信息系统集成的简述
3.2信息系统建设
由于典型的系统集成项目具有目标不明确、需求变化频繁、智力密集、设计人员高度专业化、涉及的承包商多等特点；在系统集成项目中，由于用户的不同需求和特点，每一个系统集成项目都和其他工程不完全一样，因此需要一定的定制，带有一些非标准的问题，加之系统集成项目要求对用户需求有较好的掌握，所有这些因素就造成了对信息系统建设的复杂性。
、
3.2.1信息系统的生命周期、各阶段的目标以及主要的工作内容
信息系统的生命周期可以分为四个阶段：
形成、开发、运维和消亡。
典型的信息系统有软件子系统、数据库子系统和网络子系统组成。
所以应在信息系统的早期明确对信息系统的需求，并把这些系统分配给软件子系统、数据库子系统和网络子系统。
●形成阶段包括概念形成（问题定义）、可行性分析和需求调研。
●开发阶段包括需求分析、系统设计、系统实施和系统验收等子阶段。
●运维阶段包括保证系统正常。
当信息系统不可避免的会遇到更新改造、功能扩展、甚至报废重建等情况时，信息系统就进入消亡阶段。
典型的信息系统的生命周期如图，其中验收之前的工作称作项目或工程，验收之后称为系统的运行和维护。
图3.1典型的信息系统生命周期
信息系统建设的原则如下：
●为客户的业务发展服务
●总体规划、分步实施
●保护客户现有的（IT资产）（与客户现有的系统和数据兼容、互联互通）
●支持SOA架构
3.2.2信息系统的开发方法
常用的信息系统分析与系统设计的方法有：
结构化方法和面向对象的方法。
常用的过程方法有：
瀑布模型、螺旋模型、原型法和迭代法。
习题及其分析
适用于项目需求清晰，在项目初期就可以明确所有需求、不需要二次开发的软件生命周期模型是瀑布模型；适用于项目实先不能完整定义产品需求、计划多期开发的软件生命周期模型是迭代模型。
一般把信息系统项目的生命周期划分为启动、计划、实施和收尾等四个典型的阶段，监控作为过程贯穿于整个生命周期，而信息系统作为项目的产品也可按技术工作划分产品的生命周期，按个生命周期按时间的先后，以过程的方式相互穿插在一起。
瀑布模型、迭代模型和快速原型开发是典型的三个产品的生命周期模型。
对需求清晰、在项目初期就可以明确所有的需求、不需要二次开发的项目而言，瀑布模型适合用来做产品的生命周期模型。
对于事先不能完整定义产品所需需求、计划多期开发的项目来说，迭代模型适合用来做产品的生命周期模型。
对于需要很快给客户/用户演示产品原型的项目，快速原型开发适用于做产品的生命周期模型。
习题三
在软件开发的V模型中，应该在概要设计阶段制定系统的测试计划。
瀑布模型把测试推迟到项目生命周期的最后阶段进行，系统前期出现的严重错误可能被隐藏，此时修改代价很大、发布日期会被迫延迟，而且瀑布模型使得开发中的很多关键成员例如开发人员和测试人员长期处于空闲状态。
“V模型”可以称为瀑布模型的变形模式，它提出了测试提前的理念。
V模型如图3.2所示
图3.2的左边是设计和分析，是软件设计实现过程，同时伴随着制定测试计划的过程；右边是对左边结果的验证，即对设计和分析的结果进行测试，以确认是否满足用户需求。
如：
●需求分析对应验收测试。
在做需求分析、产品功能设计的同时，测试人员就开始阅读、审查需求分析结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例并制定验收测试计划。
●当系统设计人员在概要设计时，测试人员可以了解系统是如何实现的，基于甚么样的平台，这样可以设计系统测试方案和系统测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。
需求分析验收测试
概要设计系统测试
详细设计集成测试
编码单元测试
●当设计人员在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例并开发测试脚本。
●在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试可以大幅度提高程序质量，减少成本。
习题四
RUP是信息系统项目的生命周期模型之一，“确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。
针对项目软件架构上的主要风险已经解决或处理完成细化阶段的主要任务。
RUP（RationalUnifiedProcess）软件统一过程是一种”过程方法“，它就是迭代模型的一种。
RUP中的软件生命周期在时间上分解为四个顺序的阶段，分别是：
初始阶段、细化阶段、构建阶段和交付阶段。
这四个阶段的顺序执行就形成一个周期。
其中细化阶段的任务如下：
（1）确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预算完成整个项目的成本和日程的程度。
（2）针对项目的软件结构上的主要风险已经解决或处理完成。
（3）通过完成软件结构上的主要场景建立软件体系结构的基线。
（4）建立一个包含高质量组件的可演化的产品模型。
（5）说明基线化的软件结构可以保障系统需求可以控制在合理的成本和时间范围内。
（6）建立好产品的支持支撑。
极限编程技术XP适用于需求多变，开发队伍规模较小，需求开发方”快速反馈，及时调整“。
极限编程技术XP是一种开发软件的轻量级方法。
XP适用于小型或中型软件开发团队，并且客户的需求模糊或需求多变。
XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期。
通过积极的交流和反馈，可以根据实际情况及时的调整开发过程。
3.3信息系统工程与软件工程
3.3.1信息系统工程
1、信息系统需求调研与系统分析
通过需求调研要搞清楚如下问题：
客户对待建系统有那些要求？
用户的业务目前是如何开展的？
目前存在甚么问题？
业务及其流程是否需要优化？
用户的那些业务需要IT技术支持？
用户业务的那些问题需要IT技术俩解决？
此时客户和用户的语言类描述客户的需求和用户的业务，用客户和用户的语言来与他们进行交流的并与他们达成一致的认识。
通过需求分析（或者称之为系统分析），要把需求调研的结果用IT语言或通俗的图形描述出来，要回答如下问题：
未来要开发的系统应该具有那些功能和性能？
它有甚么样的系统架构？
每一个功能模块有时如何支持客户需求和用户业务的？
对系统的可用性、可靠性、可移植性、集成性、适应性和数据要求是甚么？
上述过程提及的描述语言是统一建模语言（UML）。
ＵＭＬ提供了通俗的符号和图形来描述客户的需求和用户眼中的业务，UML以图形的方式方便了IT人员、客户和用户之间的交流。
对软件项目和软件子项目来说，RUP可以参考的开发方法之一，RUP对网络工程也有很强的指导作用。
2、信息系统的设计
由于信息系统由线路、网路、软件和数据库组成，因此无论是信息系统的需求调研、需求分析（或称系统分析）还是信息系统的设计，都涉及到综合布线、组网和软件系统（含数据库）等三部分，这三部分分别承担客户和用户对信息系统的相应需求。
1关于三部分的设计工作，下文都会有论述。
1）方案设计
信息系统的方案设计包括如下内容：
、
（1）信息系统的总体设计
（2）软件工程的设计
（3）网络工程的设计
（4）综合布线和机房工程设计
有关软件工程的设计请参考3.3.3节和3.4.5节相关的内容，有关网络工程的设计、综合布线和机房工程的设计和设备、DBMS和技术选型。
请参考3.7.11节中的相关内容。
2）系统架构
典型的信息系统体系结构如下图3.3所示
在图3.3中，环境支持平台包括机房和电源，环境支持平台也叫基础设施。
计算机网络平台包括网络传输基础设施、网络通信设备、网络服务器和操作系统、网络协议、网络平台、外部信息基础设备等，以保证网络的互联互通、应用基础平台包括数据库平台、Internet基础服务、网络管理平台和开发工具等。
网络应用系统层放置为用户的业务开发出来的各种应用软件系统用户界面层包括为用户开发的客户/服务器Client界面、Web界面和GUI界面。
在图3.3中，网络安全是指在网络系统中保证信息产生、处理、传输、存储过程中的机密性、鉴别、完整性和可用性的软硬件措施，它可能贯穿与网络体系结构的每一个层次。
除网络安全技术之外，还需要对网络进行安全管理，网络安全管理是一个组织建立信息安全方针和目标实现这些目标的体系。
3.3.2软件工程之软件需求分析与定义
软件需求分析与定义过程了解客户需求和用户的业务，为客户、用户和开发者之间建立一个对于待开发的软件产品的共同理解，并把软件需求分析结果写到《软件需求说明书》中。
1、需求分析的任务
需求分析的任务是：
准确定义未来系统的目标，确定为了满足用户的需求待建系统必须做什么即”whattodo?
”,并用需求规格说明书以规范的形式准确表达用户的需求。
让用户和开发者共同明确待建的是一个甚么样的系统，关注待建的系统要做甚么，应具备甚么样的功能和性能。
需求分析有两个任务：
●建立分析模型
●编写需求规格说明书
需求分析的步骤如下：
●需求获取
●需求提炼
●需求描述
●需求验证
一个典型的、传统的结构化的需求分析过程形成的软件需求说明书包括如下内容：
1、前言
1.1目的
1.2范围
1.3定义、缩写语、略语
1.4参考资料
2、软件项目概述
2.1软件产品描述
2.2软件产品功能描述
2.3用户特点
2.4一般约束
2.5假设和依据
3、具体需求
3.1功能需求
3.1.1功能需求1
3.1.1.1引言
3.1.1.2输入
3.1.1.3加工
3.1.1.4输出
3.1.2功能需求2
.
.
.
3.1.n功能需求n
3.2外部接口需求
3.2.1用户接口
3.2.2硬件接口
3.2.3软件接口
3.2.4通信接口
3.3性能需求
3.4设计约束
3.4.1其他标准的约束
3.4.2硬件的限制
.
.
.
3.5属性
3.5.1安全性
3.5.2可维护性
.
.
.
3.6其他需求
3.6.1数据库
3.6.2操作
3.6.3场合适应性
对上述的部分款项，解释如下：
1.2范围要明确项目软件产品的名称、用途和应用
2项目概述描述影响产品和其需求的一般因素，不说明具体的需求，而仅使需求更易于理解。
进一步说明如下：
2.1软件描述说明产品是不是独立的、全部内容自含的，说明软件产品的功能和性能、设计限制、属性（可移植性、正确性、可维护性及安全性等）、外观接口。
2.2产品功能为将要完成的软件功能提供一个摘要。
2.3用户特点描述影响具体需求的、产品的最终用户的一般特点如教育水平、经验、技术、专长等，都是施加于系统操作环境的重要约束。
2.4一般约束对设计系统时限制开发者选择的其中一些事项做一般性描述包括管理方针、硬件的限制、与其应用间的接口等等。
2.5假设与依据列出影响SRS中陈述的需求的一个因素。
这些因素不是软件的设计约束，但是他们的改变可能影响到SRS中的需求。
例如：
假定一个操作系统是被如软件产品制定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，SRS就要进行相应的改变。
3、具体需求应包括软件开发者在建立设计时需要的全部细节，对每一个需求细节做具体描述应该遵循可验证性、无歧义性等准则，还要提供对任何一个具体需求交叉引用的背景。
除描述功能需求外，还应该描述性能需求、设计约束、属性和外部接口需求。
3.3.3软件工程之软件设计、测试与维护
软件设计回答如何做。
软件设计可分为概要设计和详细设计。
有时也成为概要设计为总体设计。
在概要设计阶段，应设计完成软件的系统架构（或称体系结构）、每个子系统承担的功能以及满足的要求，应完成数据库的设计，编制集成测试计划，编制用户手册的最初版本，项目经理编制更为详细的项目计划。
所有这些成果都要通过相应的评审。
详细设计负责对每个软件子系统或模块进行设计，详细设计的结果应该能够指导程序的编码和测试工程师的工作
同样详细设计的结果如《详细设计说明书》和《软件子系统或模块测试计划》也要通过严格的评审。
软件设计包括：
（1）体系结构设计
（2）数据设计
（3）接口设计
（4）过程设计
上述前三部属于概要设计，过程设计、详细设计。
概要设计说明书和详细设计说明书包含如下：
1、概要设计说明书
软件概要设计说明书又可分为软件系统设计说明书、软件系统总体设计说明书，对软件系统的设计考虑包括软件系统的基本处理过程、软件系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件系统的详细设计提供基础。
概要设计说明书的编写提示如下：
1引言
1.1编写目的
说明编写这份概要设计说明书的目的。
指出预期的读者。
1.2背景
说明：
a.待开发软件系统的名称；
b.列出此项目的任务提出者、开发者、用户以及将运行该软件的信息中心。
1.3定义
累出本文中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考文件，如：
a.本项目的经批准的计划任务书或合同，上级机关的批文；
b.属于本项目的其他已发表的文件；
c.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2.总体设计
2.1需求规定
说明对本系统的主要输入输出项、处理的功能性能要求。
2.2运行的环境
简要地说明对本系统的运行环境（包括网络环境和支持环境）的规定。
2.3基本设计概念和处理流程
说明本系统的基本设计概念和处理流程、尽量使用图表的形式。
2.4结构
用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能。
分层次的给出各元素之间的控制与被控制关系。
2.5功能需求与程序的关系
用一张表说明各项功能需求（最左一列）的实现同各块程序（最上一行）的分配关系。
2.6人工处理过程
说明本软件系统的工作过程中不得不包含的人工处理过程。
2.7尚未解决的问题
说明在概要设计过程中尚未解决而设计者认为在系统完成之前解决的各个问题。
3接口设计
3.1用户接口
说明将向用户提供的提示和命令，以及软件的应答信息。
3.2外部接口说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。
3.3内部接口
说明本系统之内的各个系统元素之间的接口安排。
4运行设计
4.1运行模块组合
说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件。
4.2运行控制
说明每种运行模块组合将占用各种资源的时间。
5系统数据结构的设计
5.1逻辑结构设计要点
给出本系统内所使用的每个数据结构的名称、标识符以及他们之中每个数据项、记录和文卷的标识、定义长度及他们之间的相互关系。
5.2物理结构设计要点
给出本系统内所使用的每个数据结构中的每个数据项的存储要求、访问方法、存取单位、存取的物理关系（索引、设备、存储区域）设计考虑和保密条件。
5.3数据接口和程序的关系
说明各个数据结构与访问这些数据结构的程序模块之间的对应关系。
6出错信息
用一览表的方式说明每种可能的出错或故障情况出现时，系统显示信息的形式、含意及处理方法。
6.2补救措施
说明故障出现后可能采取的变通措施，包括：
a.后备技术：
说明采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动技术；
b.降效技术：
说明准备采用的后备技术，使用另一个效率较低的系统或方法来求得所需结果的某些部分，例如一个自动系统的一个降效技术可以是手工操作和人工记录；
c.恢复及再启动技术：
说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。
6.3系统维护设计
说明为了系统维护的方便而在软件系统内部设计中做出的安排，包括在系统中专门安排用于系统的检查与维护的检测点和专用模块。
2、详细设计说明书
详细设计说明书又可分为模块设计说明书、单元设计说明书，他提供了每一个软件系统中的每一个模块或子系统的设计考虑。
如果一个系统比较简单，本文件可以合并入到概要设计说明书。
详细设计说明书的编写提示如下：
1引言
1.1编写目的
说明编写这份详细设计说明书的目的，指出预期的读者。
1.2背景
说明：
a.待开发软件系统的名称及本模块的名称；
b.本项目的任务提出者、开发者、用户和运行该软件系统的信息中心。
1.3定义
列出本文件中用到专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考资料，如：
a本项目的经批准的任务书或者合同、升级机关的批文。
b属于本项目的其他已发表的文件；
c.本文中各处引用到的文件资料，包括所要用到的软件开发标准、列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2.软件系统的结构
用一系列的图表列出本软件系统内的每个模块或子系统的名称、标识符和他们之间的层次结构关系。
3第一个模块的设计说明
从第一个模块开始，逐个地给出各个层次中的每个模块的设计考虑，对于一个具体的模块，尤其是层次比较低的模块和子程序，其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同，此时只要简单的说明这一点即可。
3.1模块描述
给出对该模块的简要描述，主要说明设计本模块的目的意义，还要说明本模块的特点（如果常驻内存还是非常驻、是否是子过程、是可重入的还是不可重入的、有无覆盖要求、是顺序处理还是并发处理等等。
）
3.2功能
说明该模块应具有的功能，可采用IPO图（即输入-处理-输出图）的形式。
3.3性能
说明对该模块的全部性能要求，包括对精度、灵活性和时间特性的要求。
3.4输入项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式、数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3.5输出项
给出对每一个输出项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输出的形式、数量和频度、输出媒体、对输出图形及符号的说明、安全保密条件等等。
3.6算法
详细说明本模块所使用的算法，具体的计算公式和计算步骤。
3.7流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本模块的逻辑流程。
3.8接口
用图的形式说明本模块所隶属的上一层模块及隶属于本程序的下一层模块、子系统、说明参数赋值和调用方式，说明与本模块直接关联的数据结构（数据库、数据文卷）。
3.9存储分配
根据需要，说明本模块的存储分配。
3.10注释设计
说明准备在本模块中安排的注释，如：
a加在模块首部的注释。
b.加载各分支点的注释，对各变量的功能、范围、缺省条件等所加的注释；
c.对使用的逻辑所加的注释等等。
3.11限制条件
说明本模块运行中所受到的限制条件。
3.12测试计划
说明对本模块进行单元测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备驱动程序及桩模块等的规定。
3.13尚未解决的问题
说明在本模块的设计中尚未解决而设计者认为在软件完成之前解决的问题。
4程序2（标识符）设计说明
用类似模块1的方式，说明第2个模块乃至第n个模块的设计考虑。
......
软件工程师把软件子系统、模块集成成为一个更大的子系统，甚至成为最终的软件产品，并进行集成测试。
确保集成后的软件交付满足开发者、用户和客户的要求。
最后，已完成的软件系统和已完成的网络进行系统联调、试运行，经验收后交付用户使用。
此时作为项目，其任务已完成，信息系统作为产品，进入系统运行维护期，为支撑用户的业务发挥着数字神经系统的作用，其前期对项目的投入才逐渐地产生回报。
3.3.4软件复用
什么是软件复用？
软件复用是指利用已有的软件组件，已有的各种有关知识来构造新的软件，以加快软件开发的速度、提高软件的质量和可靠性，以及降低软件的开发和系统的维护成本。
3.3.5软件的质量保证和质量的评价
国际标准ISO9126定义的软件质量包括“内部质量”、“外部质量”和“使用质量”三部分。
另一方面，软件的质量作为“软件满足规定或潜在用户需求的能力”，要从软件在内部、外部和使用中的表现来衡量。
软件质量保证过程并通过计划来制订、实施和完成一组活动提供保证，这些活动保证项目生命周期中的软件产品和过程符合其规定的需求。
1、验证与确认
验证是确定软件开发过程中的一个给定阶段的产品是否达到前面阶段确立的需求的过程。
确认是指在软件开发过程结束时，对软件进行评价，以确认它和需求是否相一致的过程。
2、评审与审计
评审与审计过程包括：
管理评审、技术评审、检查、走查、审计等。
管理评审的目的是监控进展，确定计划和进度的状态，确认需求及其系统分配，或评价用于达到目标适应性的管理方法的有效性。
他们支持有关软件项目实施期间需求的变更和其他便攻活动。
技术评审的目的是评价软件产品，以确定对使用意图的适合性，目标是识别规范说明书和规范的差异，并向管理提供依据，以表明产品是否满足规范说明书并遵从标准，而且可以控制变更。
3.3.6软件配置管理
软件配置管理主要是对软件生存期过程中的各种阶段和最终产品演化和变更的管理，它是软件质量管理的重要组成部分，其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度与用户需求相吻合。
如果从变更的意义讲，软件配置管理要解决软件的变更标识、变更控制以及变更发布的问题。
通常，软件配置管理的实施包括，制订软件配置管理计划；确定配置标识规则；实施变更控制；报告配置状态；进行配置审核；进行版本管理和发行管理。
配置管理通常包括如下的变更管理：
（1）提交建议的变更
（2）评审和批准建议的变更。
（3）变更跟踪系统。
（4）为授权和控制变更规定的批准级别。
（5）确认批准的变更方法。
3.3.7软件开发环境
软件开发环境是支持软件开发方法的一组相关软件工具集合，通常可以用工具来支持特定的软件工程方法如RUP、XP等，以较少手工方式管理的负担。
与软件工程方法一样，他么试图让软件工程更加系统化，工具的支持包括支持单个任务的工具及涵盖整个项目生命周期的工具。
3.3.8软件过程管理
软件过程是指软件生存周期所涉及的一系列相关过程。
过程是活动的集合；活动是任务的集合；任务要起着把输入进行加工然后输出的作用。
活动的执行可以是顺序的、重复的、并行的、嵌套的或者有条件的引发的。
软件过程由项目的阶段、状态、方法、技术与研发、维护软件的人员以及相关交付物（计划、文档、模型、编码、测试、手册等）组成。
目前的三种过程方法：
UP、TheOPOENProcess、
OOSP。
软件过程可概括为三类：
基本过程类、支持过程类和组织过程类。
基本过程类包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程。
支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。
组织过程类包括基础设施过程、改进过程以及培训过程。
为了获得满足工程目标的软件、不仅涉及工程开发，而且还涉及工程支持和工程管理。
对于一个特定的项目，
升级会员 