软件工程 第2章 软件生存周期与软件过程__CUMT_2

1、计算机网络课件 制作人：谢希仁王荣存 博士 第2章 软件生存周期与软件过程课件制作人：谢希仁2.1 软件生存周期2.2 软件生存期模型2.3 问题定义2.4 可行性研究2.5 可行性论证报告的主要方面2.6 项目计划课件制作人：谢希仁l 软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期。l 一般说来，软件生命周期划分为三个时期：计划时期、开发时期、运行时期。u 计划时期划分为问题定义和可行性研究；u 开发时期又划分为需求分析、概要设计、详细设计、编码和测试阶段；u 运行时期主要是在运行中完成各类维护。2.1 软件生存周期课件制作人：谢希仁课件制作人：谢希仁2.

2、1.1计划时期1.问题定义l 确定要开发软件系统的总目标。l 给出功能、性能、可靠性以及接口等方面的要求，系统定义。2.可行性研究l 估计可利用的资源(计算机硬件，软件，人力等)、成本、效益、开发进度。l 制定出完成开发任务的实施计划和解决方案,可行性研究报告。课件制作人：谢希仁2.1.2开发时期1.需求分析l 对待开发软件提出的需求进行分析并给出详细的定义。l 编写软件需求说明书或系统功能说明书及初步的系统用户手册。l 提交管理机构评审。课件制作人：谢希仁2.概要设计l 把各项需求转换成软件的体系结构，结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应。l 编写概要设计说明书。

3、3.详细设计l 对每个模块要完成的工作进行具体的描述，为源程序编写打下基础。l 编写详细设计说明书。课件制作人：谢希仁4.编码l 把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”。l 写出的程序应当是结构良好、清晰易读的，且与设计相一致的。5.测试l 单元测试，查找各模块在功能和结构上存在的问题并加以纠正。l 组装测试，将已测试过的模块按一定顺序组装起来。l 按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用。课件制作人：谢希仁2.1.3运行时期运行时期的主要工作是维护l 改正性维护运行中发现了软件中的错误需要修正。l

4、适应性维护为了适应变化了的软件工作环境，需做适当变更。l 完善性维护为了增强软件的功能需做变更。课件制作人：谢希仁各阶段工作小结阶段关键问题结束标准问题定义问题是什么关于规模和目标的报告书可行性研究有可行的解系统的高层逻辑模型需求分析系统必须做什么系统逻辑模型总体设计概括地说，应该如何解决问题可能解法详细设计怎样具体实现编码规格说明课件制作人：谢希仁阶段关键问题结束标准编码和单元测试正确的程序模块源程序清单，单元测试方案和结果综合测试符合要求的软件综合测试方案和结果，完整一致的软件配置维护持久地满足用户需要的软件完整准确的维护记录课件制作人：谢希仁2.2 软件生存期模型l 软件生存期模型是跨越

5、整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。l 软件开发模型是对软件过程的建模u边做边改模型u瀑布模型u原型模型u增量模型u螺旋模型uRUP过程u敏捷过程u极限编程u微软过程模型课件制作人：谢希仁2.2.1边做边改模型 遗憾的是，许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。 课件制作人：谢希仁2.2.2瀑布模型 1970年Winston Royce提出了著名的瀑布模型，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。该模型将基本的过程活动、描述、开发、有效性验证和进化，看成

6、是一些界限分明的独立的过程阶段，如：需求描述阶段、软件设计阶段、实现阶段、测试阶段等。 该模型也可以看成是软件的生命周期模型。该模型是计划驱动的，理论上，在开始工作之前，必须对所有的过程活动制定计划并给出进度安排。课件制作人：谢希仁课件制作人：谢希仁开发开发时期时期运行运行时期时期计划计划时期时期( (目标与范围说明书目标与范围说明书) )( (可行性论证论告可行性论证论告) )( (维护报告维护报告) )( (测试报告测试报告) )( (程序程序) )( (设计文档设计文档) )( (需求说明书需求说明书) )课件制作人：谢希仁瀑布模型的特点1阶段间具有顺序性和依赖性关系l顺序性的含义是必须

7、待前一阶段的工作完成之后，才能进行下一阶段的工作。l依赖性的含义是前一阶段的输出就是后一阶段的输入，只有前一阶段的输出正确，后一阶段的工作才有可能获得正确的结果。课件制作人：谢希仁2推迟实现l 实践表明，编码开始得越早完成开发工作所需要的时间反而越长。l 这是因为，前期阶段的工作没完全做好，就急于考虑程序实现，其结果导致大量返工，有时甚至产生无法弥补的问题，带来严重后果。课件制作人：谢希仁3质量保证l各阶段都必须完成规定的文档。完整、正确、合格的文档不仅是软件开发时期各类人员之间相互通信的媒介，也是软件维护的重要依据。l各阶段结束前都要对所完成的文档进行评审，以便及时发现问题，改正错误。课件制

8、作人：谢希仁瀑布模型的缺点（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。课件制作人：谢希仁2.2.3快速原型模型 由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。做两次或多次：l 第一次只是试验开发，其目标只是在于探索可行性，弄清软件需求。l 第二次则在此基础上获得较为满意的软件产品。需求分析原型开发与建模原型评价系统设计系

9、统实现测用户反馈课件制作人：谢希仁快速原型模型特点快速原型模型特点l 在需求定义之前，需要快速构建一个系统。l 根据构建系统的优缺点，用户给开发人员提出反馈意见。l 根据反馈意见修改软件需求规格，以便系统可以更正确地反映用户的需求。l 减少各种假设以及风险。课件制作人：谢希仁2.2.4增量模型l 在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成 。l 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是

10、软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。 课件制作人：谢希仁l 在使用增量模型时，第一个增量往往是实现基本需求的核心产品。l 核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。l 这个过程在每个增量发布后不断重复，直到产生最终的完善产品。课件制作人：谢希仁增量模型也存在以下缺陷（1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速

11、原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。课件制作人：谢希仁增量模型总结增量模型总结n融合了瀑布模型和原型的迭代特征。融合了瀑布模型和原型的迭代特征。n每一个增量均发布一个可操作产品。每一个增量均发布一个可操作产品。课件制作人：谢希仁2.2.5螺旋模型 螺旋模型是目前软件开发中最常用的一种软件开发模型，是在组合瀑布模型与快速原型模型基础上演变而成的，尤其适用于大型软件的开发。 螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：l 制定计划确定软件目标，选定实施方案，弄清项目开发的限制条件。l 风险分析分析所选方案，考虑如何识别和消除风险。l 工程实现

12、实施软件开发。l 评审评价开发工作，提出修正建议。课件制作人：谢希仁 课件制作人：谢希仁螺旋模型的限制条件 （1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。 （2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。 （3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。课件制作人：谢希仁 螺旋模型总结螺旋模型总结n基于风险驱动的开发模型，基于风险驱动的开发模型， 使用原型法或使用原型法或其它方法来尽量降低风险。其它方法来尽量降低风

13、险。n适用于需求不明确的大规模软件项目。适用于需求不明确的大规模软件项目。课件制作人：谢希仁增量模型和螺旋模型的主要区别（1）增量模型的通过避免使用未成熟技术和经常的客户反馈等方法减少风险；而螺旋模型中直接增加了风险分析，评价所选方案，识别和消除风险。（2）增量模型经常是先做总体需求分析和设计，然后在编码和测试中逐个增量开发；螺旋模型在每个开发周期内采用简化瀑布模型或快速模型。（3）增量模型通过迭代来逐步添加功能和需求，以完善产品；螺旋模型是事先定义大部分需求,开发过程中计划性比较强。课件制作人：谢希仁2.2.6 RUP过程(统一过程)课件制作人：谢希仁n 用例驱动用例驱动Concise, s

14、imple, and understandablen 以体系结构为中心以体系结构为中心 Effective basis for large-scale reuse增量和迭代开发增量和迭代开发 基于风险前驱的原则，渐进地展开分析、设基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。证和调整模型机会，推动软件质量的提升。课件制作人：谢希仁l迭代式开发 容纳需求变更/减少风险。l管理需求 使用用例和脚本。l使用基于构件的体系结构。l可视化建模。l验证软件质量 质量评估内建在贯穿于整个开发过程的、由全

15、体成员参与的所有活动中。l控制软件变更。课件制作人：谢希仁核心工作流l业务建模l需求分析与设计l实现l测试l部署 生成目标系统的可运行版本，移交给用户l配置与变更管理跟踪维护开发过程中Artifacts的完整性和一致性。l项目管理提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的使用准则，并为风险管理提供框架。l环境提供软件开发环境，包括过程管理和工具支持。课件制作人：谢希仁工作阶段lInception（初始）：建立业务模型，定义最终产品视图，确定项目的范围。lElaboration（细化）：设计并确定系统的体系结构，制定项目计划，确定资源需求。lConstruction（

16、构造）：开发所有构件和程序，集成为可户需要的产品，测试所有功能。lTransition（交付）：把开发出的产品提交给用户使用。课件制作人：谢希仁2.2.7 敏捷过程n敏捷过程（2001/2敏捷软件开发宣言 The Manifesto of the Agile Alliance ）n敏捷过程的价值观n个体和交互胜过过程和工具。n可以工作的软件胜过面面俱到的文档。n客户合作胜过合同谈判。n响应变化胜过遵循计划。课件制作人：谢希仁敏捷过程的原则l我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。l即使到了开发的后期，,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。l经常性地交

17、付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。l在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。l围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。课件制作人：谢希仁l敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。l在团队内部，最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。l工作的软件是首要的进度度量标准。l不断地关注优秀的技能和好的设计会增强敏捷能力。l简单是根本的。l最好的架构、需求和设计出自于自组织的团队。l每隔一段时间，团队就会在如何才能更有效地工作方面进

18、行反省，然后相应地对自己的行为进行调整。课件制作人：谢希仁2.2.8 极限编程（eXtreme Programming, XP）l 极限编程是敏捷过程中最富盛名的一个，其中“极限”的含义是指把最好的开发实践运用到极致。目前极限编程已经成为一个典型的开发方法，广泛应用于需求模糊且经常改变的场合。l 特点：n对变化和不确定性反应更快速，更敏捷。n快速的同时保持可持续的开发速度。课件制作人：谢希仁l 客户作为开发团队的成员。l 使用用户素材。l 短交付周期（每两周完成一次迭代）。l 验收测试。l 结对编程。l 测试驱动的开发。l 集体所有（程序代码属于整个开发小组，每个成员都有修改代码的权利，都对全

19、部代码负责）。极限编程的有效实践课件制作人：谢希仁l 持续集成（一日内多次集成，不断回归测试）。l 可持续的开发速度（周工作时间不超过40小时，连续加班不超过两周）。l 开放的工作空间。l 及时调整计划。l 重构。l 使用隐喻（隐喻是把整个系统联系在一起的全局视图，描述系统如何运做，如何把新功能加入到系统中）。课件制作人：谢希仁极限编程的整体开发过程课件制作人：谢希仁极限编程的迭代过程课件制作人：谢希仁2.2.9 微软过程模型nMicrosoft公司自己独特的软件开发过程，综合了RUP和XP的许多优点，是对众多成功项目的开发经验的正确总结。n不足：n方法工具和产品等方面的论述不如RUP和XP全

20、面。n人们对它的某些准则本身也有不同意见。课件制作人：谢希仁微软过程准则l项目计划应该兼顾未来的不确定因素。l用有效的风险管理来减少不确定的因素。l经常生成并快速地测试软件的过渡版本。l采用快速循环、递进的开发过程。l用创造性的工作来平衡产品特性和产品成本。l项目进度表应该具有较高的稳定性和权威性。l使用小型项目组并发地完成开发工作。l在项目早期把软件配置项基线化。课件制作人：谢希仁l 使用原型验证概念。l 把零缺陷作为追求的目标。l 里程碑评审会强调改进工作，避免相互指责。课件制作人：谢希仁微软软件生命周期课件制作人：谢希仁 规划阶段l确定产品目标。l获取竞争对手的信息。l完成对客户和市场的

21、调研分析。l确定新版本产品应该具备的主要特性。l确定相对于前一版本而言，新版本应该解决的问题和需要增加的功能。课件制作人：谢希仁设计阶段l根据产品目标编写系统的特性规格说明书，这份说明书主要描述软件特性、系统结构、各构件之间的相关性以及接口标准。l从系统高层开始着手进行系统设计。u描述整个系统的设计方案。u绘制系统结构图。u确定系统中存在的风险因素。u分析系统的可重用性。课件制作人：谢希仁u划分出系统中的子系统，给出各个子系统和各个构件的规格说明。u根据产品特性规格说明书制定产品开发计划。l 开发阶段 编写程序代码/书写文档。l 稳定阶段 测试和调试。l 发布阶段 发布产品和解决方案，把项目移

22、交到运营和支持人员手中。课件制作人：谢希仁各种模型的比较 每个软件开发组织应该选择适合于该组织的软件开发模型，并且应该随着当前正在开发的特定产品特性而变化，以减小所选模型的缺点，充分利用其优点，下表列出了几种常见模型的优缺点。 课件制作人：谢希仁模型优点缺点瀑布模型文档驱动系统可能不满足需求原型模型关注满足需求可能导致系统设计差,难于维护增量模型 开发早期反馈及时,易于维护需要开放式结构,可能会设计差螺旋模型风险驱动风险分析人员需要有经验且经过充分训练课件制作人：谢希仁2.3 问题定义2.4 可行性研究2.5 可行性论证报告的主要方面2.6 项目计划课件制作人：谢希仁问题定义问题定义可行性研究

23、可行性研究可行否？可行否？否否是是终止项目终止项目.计划计划时期时期课件制作人：谢希仁2.3 问题定义问题定义l是计划时期的第一个阶段。l该阶段必须回答的问题是“是什么”。l其目的是弄清用户需要解决的问题,以及项目所需的资源和经费。l关键性任务就是确定问题的性质、工程的目标和规模。课件制作人：谢希仁【目的】明确用户要计算机解决的问题是什么。【任务】确定问题的性质、待开发系统的目标和范围。【方式】口头形式了解用户的要求；阅读用户提供的相关资料；形成调查提纲，要求用户填写。【成果】软件开发任务书课件制作人：谢希仁系统开发任务书系统开发任务书 l系统分析员对用户提出的问题有了明确的认识后，应该整理出

24、一份书面调查报告，并提交用户和部门负责人进行审查 。l应包括项目名称、开发背景、项目目标、项目范围、初步设想等内容。 课件制作人：谢希仁软件开发任务书内容项目名称开发背景当前工作中存在的问题；项目目标用户对新系统的目标；项目范围初步想法在用户提出的需求的基础上，分析人员考虑可以实现的其他功能。提出可行性研究的计划课件制作人：谢希仁【例】教材科开发一个教材销售系统。项目名称：教材销售系统开发背景：人工发售教材手续繁琐，且易出错。项目目标：建立一个高效率、无差错的微机教材销售系统。项目范围利用现有计算机，C/S模式；软件开发费用不超过.初步想法：建议在系统中增加对缺书的统计与采购功能。提出可行性研

25、究的计划建议进行大约10天的可行性研究课件制作人：谢希仁【例2】开发一个传送带分类系统的软件(CLSS)问题描述：16ID121ID110ID111ID1002345传送带移动方向传送带移动方向(2米米/秒秒) 条形码条形码分类站分类站分流器分流器课件制作人：谢希仁【例2】开发一个传送带分类系统的软件(CLSS)项目范围软件功能读取条形码输入CLSS软件以和传送带速度一致的时间间隔接受来自条形码阅读器的信息。解码零件数据条形码数据被解码成盒子的标识格式。检索数据库软件可在最多可容纳1000个条目的零件号数据库中进行检索，以确定当前在分类站位置的盒子应该放到哪个箱子中。课件制作人：谢希仁确定合适

26、的箱子箱子的信息被送到分流器，以把盒子放进合适的箱子中。维护盒子目的地的记录每一个盒子所放进的箱子的记录均被保存起来以供以后提取及报告。课件制作人：谢希仁项目范围软件性能性能取决于传送带的速度；每个盒子的处理必须在下一个盒子到达条形码阅读器之前完成。项目范围外部接口运行软件的设备、由软件控制的设备PC、条形码阅读器、分流器。已存在、且必须与新软件连接的软件，销售软件和分类软件配合，制作已经发货的列表。通过键盘或其他I/O设备使用软件的人。课件制作人：谢希仁2.4 可行性研究可行性研究l一个项目并非一定可行，存在大量失败的例子。l目的不是解决问题，而是确定问题是否值得去解。l是一次在较高层次上以

27、比较抽象的方式进行的大大压缩简化的系统分析和设计过程。课件制作人：谢希仁2.4.1可行性研究的任务可行性研究的任务1. 复查项目目标和规模复查项目目标和规模2. 市场调查市场调查3. 研究当前系统研究当前系统4. 得出目标系统解决方案得出目标系统解决方案5. 方案的选择与评价方案的选择与评价6. 制订开发计划制订开发计划课件制作人：谢希仁解决方案应该包含的工作内容l 物理分析的任务是：了解实际业务活动状况，特别对一些活动要点进行分析，明确在这些要点之间什么东西在流动，如何进行流动，对物理流量进行分析，对其模型化，得到实际当前系统的物理模型。l 功能分析的任务是：决定系统应具备的功能，分析功能的

28、结构，功能如何展开和功能分配，分析各功能之间的关系，整理它们之间传递的信息，利用数据流图，描述信息在系统流动与处理的情况。课件制作人：谢希仁l 信息分析的任务是：调查系统的输入、输出、保存信息，明确信息的结构及各信息之间的关系，调查各信息的信息量，调查各种报表和文件的格式，建立粗略的数据词典，定义系统中使用的数据。l 动态分析的任务是：系统内每一部分有几种状态，各种状态转换的条件，同步产生的条件与同步后状态的变化。课件制作人：谢希仁选择与评价方案l 多种候选方案。l 对同一功能，可以分配不同的系统元素。l 为选取最有效的分配方案，使用一组权衡准则进行评价。课件制作人：谢希仁2.4.2可行性研究

29、的内容可行性研究的内容 开发任何一个基于计算机的系统都要受到时间和各种资源等的限制。 风险评估就是在开发之前，就软件系统目标、用户可能提供的时间和资源等条件进行可行性研究，以避免错误的决策，造成人力、物力及财力上的浪费，甚至提高成本、拖延工期，更严重的会导致软件失败。 在项目计划阶段主要进行风险识别和风险估计。 1. 经济可行性2. 技术可行性3. 运行可行性4. 法律可行性值得开发值得开发可能实现可能实现课件制作人：谢希仁l 粗略地估算成本。l 估算可能取得的效益。l 提出可能需要的资源，包括人员、硬件、软件等。课件制作人：谢希仁【任务】l用户多长时间可以回收成本？l评估项目的开发成本，估算

30、开发成本是否会超过项目预期的全部利润。【方法】l费用估计l效益估计l成本效益分析课件制作人：谢希仁 经济可行性【费用估计】设备l计算机硬件、空调、电源、机房及其它设施；l系统软件，DBMS，各种应用软件(包括软件包)的估算；人力l管理人员、研制人员、数据录人员、维护人员的工资、奖金以及他们的培训费用；l差旅费用。日常开销水、电、打印纸等易耗物品及设备的维修费用。评审费用课件制作人：谢希仁经济可行性【效益估计】新软件提供哪些以前不能做或难以做到的工作；提供信息的速度、精度、质量有什么提高；使用新系统增加的收入、节省的运行费。如：l本系统可以高速、准确地处理和提供管理工作所需的各类统计报表和分析报

31、告，避免工作过程中可能出现的文件丢失、计算失误、文件流程多、审阅慢、报表报告格式不规整、存档管理复杂等情况.l可以减轻基层工作人员大量繁琐的书写、计算工作，节约管理成本，提供有关工程的准确全面细致的决策信息，促使管理人员决策科学化，管理水平上新台阶.l估计每年可以节省管理费用10万元.课件制作人：谢希仁经济可行性【成本效益分析】资金的时间价值计算公式：FP ( 1i ) N其中：lF：投资的将来值；lP：投资的现在值；li：利率；lN：年数；把5000元存入银行3年(利率0.12)，3年后的价值为 F=5000(1+0.12)3=7024.64要在3年底获得5000元的收入，现在要投资为P=F

32、/(1+i)N=5000/(1+0.12)3=3558.90课件制作人：谢希仁 经济可行性【成本效益分析】【例3】某系统投入使用后，5年内每年节约人民币1000元，其投资3000元，试计算其效益。年利率12%年年效益效益利率利率当前值当前值 累计当前值累计当前值110001.12892.86892.86210001.25800.001692.86310001.40 714.29 2407.15410001.57636.943044.09510001.76568.183612.27投资回收率投资回收率 =( 3612.27-3000)/3000 = 20%课件制作人：谢希仁l 根据客户提出的系统

33、功能、性能及实现系统的各项约束条件，从技术角度研究实现系统的可行性。l 技术可行性研究往往是系统开发过程中难度最大的工作。课件制作人：谢希仁【任务】根据客户提出的系统功能、性能及实现系统的各约束条件，从技术角度研究实现系统的可行性。【方法】资源分析管理人员和各类专业技术人员；开发人员是否对术语、缩写、开发模式有一致的理解； 人员是否进行了必要的培训；是否具备必需的软件、硬件资源和工作环境等。技术分析l现有的技术能否实现这一新系统？l有哪些技术难点？l建议采用的技术先进程度怎样？课件制作人：谢希仁3. 运行可行性运行可行性l 对目标系统所规定的运行方式能否达到。l 例如，目标系统是一个实时系统，但由于它还需要承担其他任务，可能会造成系统发生问题。课件制作人：谢希仁 新系统的运行方式用户可以接受吗？l 体制的改变；l 人员的变