信息系统集成专业技术知识.doc

信息系统集成专业技术知识系统集成项目是根据用户的需求、优选各种技术产品，进行设计开发，将各个分离的“信息孤岛”连接、集成为一个完整、可靠、经济和有效的整体，并使之能彼此协调工作，发挥整体效益，达到整体优化的目的。3.1 信息系统集成的简述3.2信息系统建设由于典型的系统集成项目具有目标不明确、需求变化频繁、智力密集、设计人员高度专业化、涉及的承包商多等特点；在系统集成项目中，由于用户的不同需求和特点，每一个系统集成项目都和其他工程不完全一样，因此需要一定的定制，带有一些非标准的问题，加之系统集成项目要求对用户需求有较好的掌握，所有这些因素就造成了对信息系统建设的复杂性。、3.2.1 信息系统的生命周期、各阶段的目标以及主要的工作内容信息系统的生命周期可以分为四个阶段：形成、开发、运维和消亡。典型的信息系统有软件子系统、数据库子系统和网络子系统组成。所以应在信息系统的早期明确对信息系统的需求，并把这些系统分配给软件子系统、数据库子系统和网络子系统。l 形成阶段包括概念形成（问题定义）、可行性分析和需求调研。l 开发阶段包括需求分析、系统设计、系统实施和系统验收等子阶段。l 运维阶段包括保证系统正常。当信息系统不可避免的会遇到更新改造、功能扩展、甚至报废重建等情况时，信息系统就进入消亡阶段。典型的信息系统的生命周期如图，其中验收之前的工作称作项目或工程，验收之后称为系统的运行和维护。87图3.1 典型的信息系统生命周期信息系统建设的原则如下：l 为客户的业务发展服务l 总体规划、分步实施l 保护客户现有的（IT资产）（与客户现有的系统和数据兼容、互联互通)l 支持SOA架构3.2.2 信息系统的开发方法常用的信息系统分析与系统设计的方法有：结构化方法和面向对象的方法。常用的过程方法有：瀑布模型、螺旋模型、原型法和迭代法。习题及其分析适用于项目需求清晰，在项目初期就可以明确所有需求、不需要二次开发的软件生命周期模型是瀑布模型；适用于项目实先不能完整定义产品需求、计划多期开发的软件生命周期模型是迭代模型。一般把信息系统项目的生命周期划分为启动、计划、实施和收尾等四个典型的阶段，监控作为过程贯穿于整个生命周期，而信息系统作为项目的产品也可按技术工作划分产品的生命周期，按个生命周期按时间的先后，以过程的方式相互穿插在一起。瀑布模型、迭代模型和快速原型开发是典型的三个产品的生命周期模型。对需求清晰、在项目初期就可以明确所有的需求、不需要二次开发的项目而言，瀑布模型适合用来做产品的生命周期模型。对于事先不能完整定义产品所需需求、计划多期开发的项目来说，迭代模型适合用来做产品的生命周期模型。对于需要很快给客户/用户演示产品原型的项目，快速原型开发适用于做产品的生命周期模型。习题三在软件开发的V模型中，应该在概要设计阶段制定系统的测试计划。瀑布模型把测试推迟到项目生命周期的最后阶段进行，系统前期出现的严重错误可能被隐藏，此时修改代价很大、发布日期会被迫延迟，而且瀑布模型使得开发中的很多关键成员例如开发人员和测试人员长期处于空闲状态。“V模型”可以称为瀑布模型的变形模式，它提出了测试提前的理念。V模型如图3.2所示图3.2的左边是设计和分析，是软件设计实现过程，同时伴随着制定测试计划的过程；右边是对左边结果的验证，即对设计和分析的结果进行测试，以确认是否满足用户需求。如：l 需求分析对应验收测试。在做需求分析、产品功能设计的同时，测试人员就开始阅读、审查需求分析结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例并制定验收测试计划。l 当系统设计人员在概要设计时，测试人员可以了解系统是如何实现的，基于甚么样的平台，这样可以设计系统测试方案和系统测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采购。需求分析验收测试概要设计系统测试详细设计集成测试编码单元测试l 当设计人员在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例并开发测试脚本。l 在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试可以大幅度提高程序质量，减少成本。习题四RUP是信息系统项目的生命周期模型之一，“确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。针对项目软件架构上的主要风险已经解决或处理完成细化阶段的主要任务。RUP（Rational Unified Process）软件统一过程是一种”过程方法“，它就是迭代模型的一种。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、 需求分析的任务需求分析的任务是：准确定义未来系统的目标，确定为了满足用户的需求待建系统必须做什么即”what to do?”,并用需求规格说明书以规范的形式准确表达用户的需求。让用户和开发者共同明确待建的是一个甚么样的系统，关注待建的系统要做甚么，应具备甚么样的功能和性能。需求分析有两个任务：l 建立分析模型l 编写需求规格说明书需求分析的步骤如下：l 需求获取l 需求提炼l 需求描述l 需求验证一个典型的、传统的结构化的需求分析过程形成的软件需求说明书包括如下内容：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功能需求13.1.1.1引言3.1.1.2输入3.1.1.3加工3.1.1.4输出3.1.2 功能需求2.3.1.n 功能需求n3.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、The OPOEN Process、OOSP。软件过程可概括为三类：基本过程类、支持过程类和组织过程类。基本过程类包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程。支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。组织过程类包括基础设施过程、改进过程以及培训过程。为了获得满足工程目标的软件、不仅涉及工程开发，而且还涉及工程支持和工程管理。对于一个特定的项目，可以通过剪裁过程定义所需的活动和任务，并可使活动并发执行。与软件有关的单位，根据需要和目标，可采用不同的过程、活动和任务。有效的软件过程可以提高组织的生产能力，软件过程的作用如下：l 理解软件开发的基本原则，可以帮我们做出明智的决定。l 可以标准化你的工作，提高软件的可用性和Team间的协作。l 我们所采用的这种机制本身是不断提高的，我们可以跟上潮流，使自己不断接受新的，最好的软件开发经验。有效的软件过程可以改善我们对软件的维护：l 有效的定义如何管理需求的变更，在未来的版本中恰当分配变更部分，使之平滑过渡。l 首先在具体操作和相关支持中定义如何平滑的改造软件，并且这种具体操作和支持是可实施的；不可实施的软件过程将很快束之高阁。人们越来越关注软件过程，而不仅仅关注任务，软件开发和维护的运作过程为中心的方式在进行。要解决软件危机，首要的任务是软件活动视为可控的、可度量的和可改进的过程。好的过程才能产生好的产品。因此需要对软件的过程进行管理。一般的，软件过程的改进包含如下内容：（1） 软件过程成熟模型（2） 软件过程的持续性。（3） 软件过程评估。（4） 初始过程、可重复的过程、已定义的过程、管理的过程和过程优化。习题及其分析原型发是一个动态定义需求的方法，提供完整定义的需求不是原型化方法的特征。原型化方法是一种逐步的、迭代的完成需求定义的方法，是一种动态定义系统需求的技术。原型化方法的优势就在于逐步从简答到复杂的提交系统，起点低，可以追加功能以及用户参与，还可以直观、及时地交付原型。新项目与过去成功开发过的一个项目类似，但规模更大，这是应该使用瀑布模型进行项目开发设计。新项目与过去成功开发过的一个项目类似，就应该使用瀑布模型进行项目开发。因为已有了以前开发的经验和积累的软件模块，这些都可以应用到新项目中。需求规格说明书的内容不应当包括：对算法过程的描述。包括对重要功能的描述、软件确认准则和软件性能。需求分析的任务是：准确定义未来系统的目标，确定为了满足用户的需求待建系统必须做甚么，并用需求规格说明书以规范的形式准确的表达用户的需求，需求规格说明书应该得到客户的确认。让用户和开发者共同明确待建的是一个甚么样的系统，关注待建的系统要做甚么。需求任务有两个任务：l 建立分析模型l 编写需求规格说明书对算法的描述属于系统设计的任务。RUP是信息系统开发的过程方法。RUP属于过程方法，是一种软件项目实施过程的方法论，他的目标是在可预见的工期内、在确定的预算内提交能够满足最终用户需求的高质量产品。EGP、RIP、BGP分别是OSI网络层的路由协议。结构化的分析方法有结构化分析、结构化设计、结构化程序设计构成。它是一种面向数据流的开发方法。结构化方法总的指导思想是自顶向下、逐步求精。他的基本原则是功能的分解与抽象，它是软件工程中最早出现的开发方法，特别适合于数据处理领域。CMMI提供了两种模式表述方式：“连续式”和“阶段式”。一下说法中正确的是前者可以描述过程能力成熟度，后者可以描述组织能力成熟度。CMMI提供了两种模型表述方式：”连续式“和”阶段式“。连续式的模型将CMMI过程领域分为”过程管理、项目管理、工程、支持“四个过程域。阶段式的模型：它按成熟度级别过程领域进行划分为”初始级、可管理级（或称已管理级、重复级）、已定义级、定量管理级、持续优化级“五个级别。选择信息系统开发工具和开发平台时（尤其是选择软件开发工具和开发平台），应考虑功能、易用性、稳健性、运行要求和性能、服务和支持。为了提高项目的开发效率，通常需要若干开发工具或开发平台的辅助支持。而在选择这些开发工具或开发平台时。应当选择功能上满足需要、运行稳定，且具有良好服务支持的工具。另外工具和平台的易用性也是选择时要考虑的首要因素，因为一个容易使用的开发工具或开发平台可以显著提高项目的开发效率。软件的维护并不只是修正错误。为了满足用户提出的修改现有功能、增加新功能以及一般性的改进要求和建议，需要进行完善性维护，它是软件维护工作的主要部分；软件测试不可能发现系统中所有潜在的错误。所以这些程序在使用过程中还可能发生错误，诊断和更正这些错误的过程称为改正性维护；为了改进软件未来的可维护性或可靠性，或者为了给未来的改进提供更好的基础而对软件进行修改，这类活动称为预防性维护。一般来说，软件的维护活动可以分为改正性维护、适应性维护、完善性维护和预防性维护四类：（1) 改正性维护是软件投入运行一段时间后，可能会暴露出一部分在测试阶段没有发现的错误，为改正这些错误而对软件进行的修改活动。（2) 适应性维护是由于软件运行的外部环境（例如软件、硬件）和数据环境等发生了变化而修改软件，使之适应这些变化的活动。（3) 完善性维护是因为用户需求是经常变化的，在软件使用过程中，用户会对软件提出新的功能和性能要求，为了满足这些新的要求而对软件进行修改，使之在功能和性能上得到完善和增强的活动。（4) 预防性维护是不等用户提出维护申请，采用先进的软件工程方法对需要维护的软件或部分软件进行重新设计、编码和测试，以提高软件的可维护性和可靠性目标，为以后进一步改进软件打下基础的活动。3.4面向对象技术基础与UML3.4.1基本概念面向对象的基本概念有对象、类、继承、消息、组件、模式、复用、模型、物理模型、逻辑模型、建模和可视化建模等。1. 对象对象是对现实世界一个具体实体的描述，如学生张飞鸿基本信息是一个对象，而张鸿飞在建行的存折则是另一个对象。对象由表示实体属性的数据以及表示实体行为的操作所构成。在信息系统里把一个对象的数据和操作合起来作为一个整体加以处理，这就是封装，对象是构成信息系统的基本单元。如采用计算机语言描述，对象是由一组属性和对这组属性进行处理的一组操作所构成。对象包含三个基本要素，分别是对象标识（对象名称）、对象状态（对象数据）和对象行为（对象操作）。2. 类类是现实世界一组同类实体的抽象、形式化的描述，该类将改组实体和操作封装在一起。类的数据也叫属性、状态或特征，它表现类静态的一面。类的操作也叫功能、行为、函数或服务，它表现类动态的一面。3. 类和对象的关系对象是类的实际例子。如果将对象比作房子，那么类就是房子的设计图纸。4. 继承继承表现的逻辑关系是”B类是A类的一种“，例如老虎是猫科动物的一种。此时B类能够直接获得A类已有的性质或特征。而不必要重复定义他们。前一类叫子类，也叫派生类。后一类叫父类，也叫基类。这是我们说B类继承了A类所有的属性集合行为。5. 消息消息是对象内操作之间的交互手段。一个对象执行一个操作后产生了消息，这个消息可以触发另一个操作。6. 组件组件是软件系统可替换的、物理的组成部分，它封装了实现体（实现某个功能），并提供一组接口的实现方法。可以认为组件是一个封装的代码模块或大粒度的运行时的模块，也可将组件理解为具有一定功能、能够独立工作或同其他组件合起来协调工作的对象。组建也叫构件。7. 模式模式是一条由三部分组成的规则，它表示了一个特定的环境、一个问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题，以及该问题的解决方案。这样就能一次一次的使用该方案而不必要重复劳动。将设计模式引入软件设计和开发过程的目的在于充分利用已有的软件开发经验，这是因为设计模式经常是对于某一类软件设计问题的可重用的解决方案。设计模式使得人们可以更加简单和方便的去复用成功的软件设计和体系结构，从而能够帮助设计者更快更好的完成系统设计。8. 复用软件复用是指将已有的软件及其有效成分用于构造新的软件或系统。组建技术是软件复用实现的关键。9. 模型所谓模型，就是对现实的简化描述。10. 物理模型和逻辑模型物理模型是当前系统的一个模型化表示，或待建系统的原型化表示。逻辑模型是一个从现有的物理模型中抽象出来的模型，也叫概念模型，经优化后用来指导项目的实施。从优化后的逻辑模型出发设计新系统的物理模型，此时物理模型也叫实施模型。表3.1说明了逻辑模型和物理模型的联系与区别。逻辑模型物理模型现行系统或待建系统描述重要的业务功能，不考虑系统是如何实施的。描述现实系统是如何在物理上实现的。目标系统描述新系统的主要业务功能和用户的新需求，不涉及系统如何实施描述新系统是如何实施的（包括技术）11. 建模建模是捕捉系统本质的过程。建模是恶使逐层深入解决问题的方法。建模就是把复杂的系统编程小的系统，采用”各个击破“的原则逐一解决。12. 可视化模型可视化模型就是用图形来表示模型的建模过程。为了使构件系统更切合实际、更有效的被利用，构建应当具备可变性，以提高其通用性。软件复用是指将已有的软件及其有效成分用于构造新的软件或系统。构建技术是软件复用实现的关键。构件是软件系统可替换的、物理的组成部分，它封装了实现体（实现某个职能），并提供一组接口的实现方法。可以认为构件是一个封装的代码模块或大粒度的运行时的模块，也可将构件理解为具有一定功能、能够独立工作或同其他构件组合起来协调工作的对象。对于构件，应当按可复用的要求进行设计、实现、打包、编写文档。构件应当是内聚的，并具有相当稳定的公开接口。为了使构件更切合实际、更有效的被复用，构件应当具备”可变性“以提高其通用性。针对不同的应用系统，只需对其可变部分进行适当的调节，复用者要根据复用的具体需要，该做构件的可变”特性“，即”客户化“。3.4.2统一建模语言UML统一建模语言是一种通用的可视化建模语言，他可以完整的描述软件的需求和结构。利用UML，软件设计人员可以很方便的为实际系统的编写提供一个”蓝图“，可以对软件系统及其部件进行直观的表示、架构和开发，并可由工具软件使整个过程半自动化和文档化，能大大简化软件设计的复杂过程。当然，仅有建模语言还不够，还需要有相应的”过程“来实现建模语言的搭建的”蓝图“。UML是一种图形化的建模语言，但用户对语言进行扩展，它贯穿于系统开发的各个阶段，并且和系统的开发过程相独立。UML由符号和图形两部分组成。1、 UMLv1.0的符号如表3.2所示。表3.2UML基本符号一览表序号符号及示例说明1Note注释。在UML图中提供注释的目的是以简短的说明阐明图表的内容。2Actor参与者。它代表与待开发系统交互的一个人、硬件设备或者另外一个系统。3User Case用例。User Case描述了系统某一部分的行为。一般的，User Case记录对某个系统功能的需求，而这个功能由动作或者事件的应答动作系列完成。4Collaboration协作。协作命名了彼此合作完成某个行为的类、接口和其他元素的群体。是用例的一个具体实现。5Class类。UML类与面向对象编程的类一样。即它定义并封装了一组属性和行为。类在运行时被实例化从而创建出对象。6Boundary Class边界类边界类处理系统环境与系统内部之间的通信，边界类为用户或另一个系统提供了接口，边界类用于为系统的接口建模。7Entity Class实体类是模拟必须被存储的信息和关联行为的类。8Control Class控制类控制类是用来为特定于一个或几个用例的控制行为建模的类9ParameterizedClassParameterized Class参数化类又称为模板类，它定义了类中族。10Object:ClassObject对象。对象是类的实例。例如，”MyClass myObj=new MyClass;”创建了一个myObj对象。11 MessageMessage消息。消息是对象间的通信，它传达了要执行动作的信息，他能触发事件。12Interface 接口。接口定义了一组可以从外部访问的行为。类、库、执行条件、数据文件都可以由软件来描述。接口本身并不实现任何功能，它只是和声明实现该接口的对象订立一个必要实现那些行为的契约。13PackagePackage包。用来聚集和组织模型中的一部分。包可以含有类、接口、组件、节点、协作、用例、图或其他的包。14 ComponentComponent构件，或者叫组件，构件一般代表一个接口定义良好的软件模块，它是系统的一个物理的、可替代的部分，它遵循接口的定义并未接口提供了实现。它可以是一个Dll、一个执行文件，或者一个数据库。15NodeNode节点。节点是运行时存在的物理单元。节点一般代表具有内存以及处理能力的计算资源。节点是为系统物理方面建模的重要模型元素。16StateTrackingEntry/setModel(on)Exit/setModel(off)Do/follow/Target State状态，表示对象在其生命期中的一种条件或状况，在这种情况下，对象满足某个条件，或执行某个动作，或等待某个事件。17Initial StateInitial State初始状态，表示状态机的开始18Final StateFinal State最终状态，表示状态机的执行结束。19DecisionDecision判定，代表了活动图或状态图上一个特殊的位置，根据其内的判断条件决定活动图或状态图的走向。20TransitionTransition跃迁表示两个状态之间的一种关系，表示对资源状态将执行某些动作，当规定的条件满足时，对象进入目的状态。对单个状态，还有内部跃迁和自跃迁。21SynchronizationSynchronization同步条表示活动中的分叉和联结。22ActivityActivity活动是状态机中进行的一个非原子执行，它由一系列动作组成。23示例Accountbalance:floatdata:DateAccount()DateCustomerDependency依赖关系。正如其字面意义，它表示一个事务依赖于另一事务。这意味着一个事务了解于另一事务，并需要另外一个事务才能发挥功能。左边的事例中，Account依赖于Date、Date是被依赖的事务（类）。24Personname:stringeat()示例：studentGenaralization类属关系，描述一般事务与该事物的特殊种类之间的关系，也就是父元素与子元素之间的关系，父类能派生出具有更多特殊子类，此时父类即为子类的超类（或子类的父类或基类）。类属关系描述了类之间的是一种关系。左边的事例中，student是person的子类。25 双向关系事例单向关联 聚合关联组合关联Company +employer 1:n +employee 1:nstaffAssociation关联关系，表示两个类之间存在某种语义上的联系。它是一种结构关系，规定了一种事务的对象可以与另一种事物的对象相连。Aggregation聚合关系。是一种特殊的关联关系，表示类之间的整体和部分的关系。代表“has a”关系。Composition组合关系是一种特殊的聚合关系，该关系的整体与其部分之间具有很强的所有关系和一致的生命期。26Realize Relation实现规定Realize Relation实现关系，描述了规定协议的元素和遵守协议的元素之间的关系，例如接口和实现接口的组件之间的关系。27 示例： Validate passwordValidate User Scan ID CardGeneration用例之间的类属关系。28示例 Login Deleting exsiting account Modifying account information Create new accountInclude Relationship包含关系，标注为,在该关系中，用例能够引入其他用例的功能。左边的事例中，用例Login是其他三个用例的公共部分，该用例被其他三个用例所包含。29Extend Relationship扩充关系，标注为,在关系中，基用例在制定的扩充点隐式的含有另一个用例的行为。30Abstract Base ClassAbstract Class抽象类。抽象类不能被直接实例化，但允许派生出具体的、有实际功能的类。2、 UML的图形由UML的符号，根据需求调研的结果，由符号画出图形以表示待建系统的结构和行为，UML提供了如下的九种图来对待建系统建模。1） 用例图用例图表示一个系统中所有的用例与所有的外部参与者的交互。可为待建系统的功能建模，如图3.4所示某保