（6）验收。维护工作完成后，由用户、专家及有关领导进行验收，同时要验收有关资料。对于重大的维护应作为小系统开发对待，按部就班地进行。 第8章
1．简述软件生产的特殊性。
（1）产品抽象性。软件生产及软件产品可见性差，其加工对象是信息而不是物理实体。这给检验、管理带来一定的困难。
（2）产品严格性。管理信息系统工程是一项严密的逻辑工程，产品无等级而言，好就是好，错就是错。
（3）生产创造性。软件产品执行重复性大，而构成重复性小。软件生产主要是设计，成批生产只是复制。因此，软件生产主要是创造性生产。
（4）产品无磨损。软件产品不会因使用而产生磨损，其故障也不能用更换零部件的办法解决。
（5）智力密集。目前，软件生产的自动化程度还很低，主要靠人的智慧型劳动完成。
（6）难定量。无论是生产还是维护，工作量都难以定量管理。如系统分析员的工作难于定量化，程序员的劳动生产率难于定量化等等。
（7）易出错。软件产品中错误难以避免，测试只能发现错误而不能保证没有错误。软件产品容易出错的原因是缺乏理论支持。
（8）维护是必要的。软件产品不成熟，无验收标准，交付使用后要经常变动，因此，维护是必要的。而且，维护是系统建设的一个正式阶段。
2．管理信息系统项目管理涉及到哪些方面？系统项目管理的内容包括哪些？ 管理信息系统项目管理主要有以下几方面： （1）开发资源的保障。人、财、物等资源是系统开发的基础条件，为了保证开发进度和开发质量，必须保证有关资源定质、定量、定期到位。 （2）进度计划与控制。在项目进程中，应按照系统规划阶段制定的进度计划进行检查。如某些任务不能如期完成，应分析原因，采取必要的、有成效的措施予以调整和补救，以保证整个工程如期进行。进度计划应以图表方式描述出来，悬挂在工作室中，以督促开发组成员的工作。 （3）阶段性评价。在系统开发的每一个阶段(规划、分析、设计、实施等)完成后都要进行阶段性评价，本阶段评价合格并经批准后才能进入下一阶段。这样可以保证整个工程的质量，防止大范围返工。 （4）工作量与费用统汁。工作量和费用开支是工作量计划和费用计划管理所必须的形式表示。 因此项目管理的内容主要有：人员、组织、计划、控制、用户、文档和规范。
1．人员
MIS开发工程的人员主要有：系统分析员，系统设计员，经济模型设计员、数据库管理员、程序员，资料员，项目管理员和其它辅助人员。根据项目规模的大小，有时可能一人身兼数职，但职责必须明确。 2．组织
软件开发的组织没有统一的模式，在此介绍三种成功的组织结构。 （1）主程序员制
由IBM公司提出的主程序员制是软件结构化设计的组织体现，它是全组协调统一的保证。开发组由一位高级工程师(主程序员)主持计划，协调和复审开发组的全部活动；技术人员(一般2~5人)负责分析和开发工作；一位后援工程师支持主程序员的工作，必要时可以代替主程序员的工作，以减轻主程序员的负担。 （2）专家组
专家组强调每个人的才能，把每个人都看成某一方面的专家，由这些专家组成一个开发组。这种开发组虽然可以发挥每个人的专长，但可能出现协调上的困难。
（3）民主组织
民主组织是由从事各方面工作的人员轮流担任组长。很显然，这种组织对于调动积极性和个人的创造性是值得称道的。但过多的组长轮换，对工作的连续性不利，不符合工程化的要求。 3．计划
由于管理信息系统项目不成熟、变化多，其计划不容易制定，更难以执行。一个有效的办法是以计划为基础加强“控制”。计划包括进度计划和各阶段的具体计划，还包括人员、时间、可能遇到的困难及对策等。 4．控制
控制是为了保证计划的执行，应付各种变动、干扰、异常和意外情况。控制对于开发工作十分重要，尤其是当条件比较复杂、变化多、不稳定时，控制更困难，但也显得更重要。 控制包括风险控制、进度控制、经费控制、质量控制、人员控制等。 5．用户
MIS的最终产品成功与否，还要取决于用户的合作。所以，管理员有责任对用户做工作。系统分析工作应当由软件人员和应用部门业务人员合作进行，考
虑到业务人员对计算机、软件理解上的困难，软件人员应当主动些，主动提问、主动介绍情况、主动与之讨论。管理人员应掌握用户心理，对用户的工作要贯彻始终，防止由于不理解而造成干扰和阻力。 6．文档
文档是开发过程中唯一的可见物，是对未来系统的描述，是人的设计思想的具体体现。思想是不可见的、不稳定的，但思想一旦转化为文档，就成为可见的、稳定的。这就是所谓的“白纸黑字”。只有通过文档才能检查进度、方便通讯。文档使开发过程可见池，如最初要求、中间结果、最后成果等。项目管理很大程度上是通过文档管理来体现的。 7．规范
软件开发过程涉及大量人的活动。制定各种规范有利于统一尺度、协调步骤，有利于定量化，克服偶然性、不稳定性、不确定性。规范包括人员规范、文档规范以及开发过程中的各种规章制度。开发过程可以利用开发工具以实现自动化，但不可能全部自动化。规章制度是用来约束非自动化部分的。 3．试述控制风险的方法。 （1）外部集成法：
将系统实施小组的工作与组织各层次用户的工作紧密联系在一起。结构化程度相对比较低的项目必须在各个阶段都有用户的充分参与。需要动员用户支持多种可选设计方案中的一种，并承担其中的某项设计。所以必须运用外部集成法，其特征如下： 1）用户可作为项目领导，或项目小组中的二把手； 2）建立用户指导委员会对系统设计进行评价； 3）用户可能成为积极的项目小组成员； 4）项目要有用户对说明书的正式评审和批准； 5）所有主要的设计会议记录都能在用户中广泛传送 6）用户能为高层管理者准备状态报告； 7）可以委托用户培训和安装； 8）用户能够负责对变更的控制，一旦最终的设计说明书完成，将停止所有不必要的变更。 （2）内部集成法。
确保系统实施小组作为一个富有凝聚力的整体运作。对高技术水平的项目采用内部集成法很有好处。这类项目的成功主要取决于其技术的复杂程度，项目领导者既需要高水平的技术又需要管理经验。他们必须能预先提出问题，并在一个得力的技术小组中建立一种平稳的工作关系。其特征如下： 1）项目小组成员须有丰富的经验；
2）项目小组须在具有高技术水平和项目管理经验的管理者领导之下； 3）应经常召开小组会议；
4）小组应定期举行技术情况评审工作；
5）项目小组应具备同事之间保持融洽工作关系的良好传统； 6）小组成员应当参与建立目标和确定目标期限的过程；
7）内部尚不具备的必要技术、技能或专家建议应确保从组织外部获得。 （3）规范计划和规范控制法
建立并排列任务，确定每项任务所要求的时间、资金和技术资源预算。辅助监测向目标进展的状况。对高结构化和低技术水平的项目其风险性也最低。其设计是比较确定和稳定的，而且项目不会受到任何技术上的局限。如果这类项目规模较大，则可采用规范计划和控制方法对其进行成功的管理。利用项目管理技术，如：PERT(Program Evaluation and Review Technique)或甘特图，可以建立一个详细计划，定义任务和资源预算。这种项目管理技术能帮助管理者找出项目管理的瓶颈，并确定其对项目完成时间的影响。它的主要内容如下： 1）选择并确定阶段或阶段性标志； 2）通过可行性研究建立说明书； 3）制定说明书标准； 4）建立项目批准程序。
标准控制技术将成功地按预算和预定日期画出项目进程图，以便项目实施小组能按其原始安排进行适当地调整。其好处有： 1）能保持控制； 2）发现计划的偏差：
3）有关计划实施情况的定期状态报告将标明实施进度。
4．你怎么看待用户在系统建设中的作用？用户和系统设计者之间的障碍有哪些？
用户参与信息系统的设计和操作，会有几种肯定的结果。首先，如果用户大量地参与系统设计，他们会有更多的机会按自己优先考虑的问题和业务需求对系统施加影响，有更多的机会控制结果。其次，因为他们积极参与了改变自身的过程，所以他们更能对系统操作产生积极的作用。
虽然兼顾用户的知识和专长能带来较好的解决方案，但用户对要解决问题的看法往往容易存在局限性和目光短浅，由此也可能导致忽视改进业务过程和用信息技术进行革新的重要机遇。实际上，专业信息系统设计人员的作用就如同一座新
房子的建筑师，如果人们企图全凭个人设计去建造自己的房屋，其结果很可能是质量低劣的。
事实上，由于用户与信息系统专业人员具有各自不同的背景、兴趣和优先考虑的问题，因此其解决问题的方法和用语也会完全不同。以至他们进行交流时似乎根本无共同语言。信息系统专业人员往往特别注重技术和机器方面的问题，他们总是试图寻找精确、理想的技术解决方案，使软、硬件在操作上更加便利，或在组织的有效性上达到最优；相比之下，用户则希望信息系统侧重解决业务问题或使组织任务更便利。通常这两类人员的意向有很大差异，以至他们进行交流时似乎根本无共同语言。信息系统之所以不能真实地反映用户需求，以及用户被置于系统建设过程以外的一个主要原因就是最终用户与设计者之间的沟通存在障碍。当用户和技术人员之间存在明显隔阂时，且这两类人员都在不自觉地坚持追求自己的日标时，系统开发项目就会存在极高的失败风险性。 5．怎样处理用户在系统建设中的抵触？
以下三个方面大体说明了用户抵触的原因： （1）用户无论是作为个人还是一个团体产生抵触是由于其内在因素引起的。例如，由于他们的懒散和不愿学习新的工作方法，因此抵制新系统或所有变革。 （2）用户抵触系统的原因是由于系统设计中所固有的一些因素造成的。例如，由于用户界面混乱，或学习如何运行系统非常麻烦，因此用户也会抵制系统。 （3）用户抵触系统的原因是由于人和系统相互作用的诸多因素引起的。例如，系统设计得可能很好，且受到一些用户的欢迎；但却受到一些害怕由此失去个人在组织小权力或地位的人员抵制。 下面给出如何克服上述用户抵触系统的—些常用策略。 第一种情况的策略：用户教育(培训) 采取强制(法令、政策)手段 说服用户参与(明确承担的义务)
第二种情况的策略：用户教育
改善人为因素(用户／系统界面) 用户参与(改进设计)
适当时，可用软件包法修改系统使之与组织需求相符合
第三种情况的策略：在引入新系统前，先解决组织问题
重新构造激励用户的机制 重新建立用户与设计人员之间的关系 适当时，增加用户参与