谈谈用户在信息系统开发和改善中的作用Word下载.doc

谈谈用户在信息系统开发和改善中的作用Word下载.doc

《谈谈用户在信息系统开发和改善中的作用Word下载.doc》由会员分享，可在线阅读，更多相关《谈谈用户在信息系统开发和改善中的作用Word下载.doc（5页珍藏版）》请在冰豆网上搜索。

Abstract:

Atpresent,informationsystem'

sresearchanddevelopmentbecomeamereformalityfrequently.Becauselackstheuserparticipationthereasonablemechanism;

Lackstothedemanddocumentsmaterialeffectivemanagement;

Lacksbetweentheuserandthedevelopmentpersonneltheeffectiveexchangemethod,causesthesystemresearchanddevelopmentefficiencytobelow,theeffectisbad.Inordertochangethiskindofconditionneedstointroducethesoftwareengineeringthemethod,thedisplayuserinthesystemdevelopmentandtheimprovementleadingrole,carriesontheessentialmanagementtotheinformationsystemresearchanddevelopmentprocess.Thisarticlehasstudiedthesoftwareengineeringbasicquestion,andhasdiscussedtheuserthequestionwhichandthesolutionoftenmeetsintheinformationsystemsoftwareengineeringfunctionaswellastheuserparticipationsoftwareresearchanddevelopment.

keyword:

Softwaredevelopment,informationsystem;

User

引言

信息系统建设普遍存在立项多、花钱多、鉴定会多，但真正受用户欢迎、有三年以上寿命的系统不多。

其主要原因是在系统项目开发过程中，对用户测试重视不够、营理不力，是造成这种现象的基本原因之一。

信息系统成功应用的关键，在于最终是否满足了应用者的“口味”。

1、用户在统需求阶段中的作用

众所周知，一个系统的诞生是从需求工程开始的，是软件生命周期的第一个阶段。

虽然大家都知道需求工程对软件整个生命周期的重要性，但对它的研究远远没有对软件工程其他部分的研究那么深入。

随着信息化建设的步伐越来越快，信息管理应用软件需要不断增加，规模和复杂程度方面的需求也越来越高。

面对庞大的需求，软件研制人员越来越感到难以把握，客户对“已完成”系统不满意的现象时有发生，需求问题已经成为制约信息系统应用软件发展的重要因素。

1．1需求工程的基本问题

需求工程的基本问题是获取需求、分析需求、表述需求、确认需求、进化需求。

获取需求就是与用户共同分析研究用户的工作过程，协助用户搞清楚他们想要的东西，并准确地记录下来。

分析需求是软件研制人员与用户对需求进行分析、综合、定义、建模的过程，其目的是从用户提供的各种各样的需要说明中找出对应的软件解决方法[1]。

表述需求是编写软件需求规格说明的过程，其目的是表达对需求的理解，订下软件开发项目的一份契约，确立评价后续工作的依据，固化需求进化的基线。

确认需求是一个验证需求的过程，是以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和检验需求规格说明的正确性和可行性，并使用户、系统分析员、软件开发者、测试员、项目管理者对需求规格说明达成共识[2]。

从主观意义上说，需求工程需要专家、用户、研制主管理部门、需求分析员、系统分析员、软件程序员等方方面面的人员参与，各方面人员有不同的着眼点和不同的知识背景，沟通上的困难给需求工程的实施增加了人为的难度。

1．2需求工程中用户的主导地位

需求工程是以用户为主要工作对象的工程。

需求研究就是软件工程人员与用户进行不断交流、不断磨合的一个过程，只有反复与用户交流，在不断认识和分析用户工作的过程中，才能比较准确的获取用户需求，才能将用户想要的软件功能和性能描述清楚，编写出既符合用户要求，又便于软件工程人员操作的软件需求规格说明[3]。

由此可见，需求工程中软件研制人员的首要任务就是协助用户分析自己的业务工作过程，通过与用户进行各种形式的交流，找出其中最需要解决的而且是软件系统能够解决的问题，这个过程是一个用户为主导的，而不是以技术为主导的过程。

2、用户在系统设计与开发阶段中的作用

系统分析设计是根据业务重组得到的业务流程模型进行系统的分析，对数据、体系结构、接口、过程进行设计，完成系统功能详细设计、界面设计、系统权限设计、测试用例等设计。

这阶段工作是将业务需求转化为逻辑模块的关键一步，也是软件工程的核心。

在这阶段的工作中，用户的主要工作，是了解并参与设计的全过程，及时提出用户方的意见，使设计结果基本符合用业务的要求；

与其他人员共同复审设计报告。

在这期间，常见的问题是:

开发商的设计不能充分反映用户的需求，而业务又不时会发生部分变化。

在这种情况下，首先要尽量使“业务调研与重组”按时完成，为“系统分析设计”提供时间保证，同时应组织部分用户技术人员参加设计，及时提出工作意见和建议，帮助开发商的设计工作。

在这段工作中，要注意及时检查设计的正确性、完整性、一致性、可维护性及详细设计文档的完整性。

应不断提醒开发商:

必须注意设计的系统性和完整性，必须充分考虑现在的设计与整个系统的关系；

必须充分考虑业务变化对系统的影响，设计出具有较强适应性和易维护、易扩充的系统。

用户方应特别重视对设计报告的复审工作，成立由各级领导、业务操作第一线骨干、工作人员、开发商项目管理技术总监、咨询专家组成的设计审定小组，按标准认真审定设计报告:

是否能正确体现业务操作的要求；

是否充分考虑了业务的变化对系统的影响；

是否具有较好的可扩充性和可维护性；

是否考虑系统的后续开发与设计；

对系统其他资源方面的要求是否合理；

系统的响应速度是否令用户满意；

是否具有友好的用户界面（视觉效果和使用效果）；

是否具有实用的联机帮助系统，实现手段是否先进；

数据库中相关信息的分类是否合理；

表间约束是否正确；

测试用例的设计是否合理、全面；

系统切换计划是否可行；

增补数据的采集、录人、维护工作计划是否可行、合理；

权限的设定与维护是否易于操作；

文档的规范性和完整性。

系统开发阶段是把详细设计转化为程序设计语言的步骤。

需要投人较多的人力资源。

用户方软件开发管理者应合理地调配人员检查工作质量，了解具体的设计开发过程。

用户方最好能积极参与部分模块的开发。

这一方面可以最大限度地了解系统开发的全过程，为今后的系统维护打下基础；

另一方面，也锻炼和提高了自身技术队伍的水平。

3、用户在软件测试阶段中的作用

一个软件经过需求分析后，就进入开发过程，在系统投入正式运行阶段之前，还必须要经过用户测试。

用户测试的主体，由开发技术人员转为最终应用者。

用户通过对系统全部功能和工作流程的亲手应用、测试，逐步全面了解系统是否完全实现了需求书的要求，从而接受和认可该软件，这是保证系统功能和流程正确性、完整性和实用性的关键。

实践证明，只有用户试用，才能提出合理建议，促使软件实用化和产品化。

因此我们把用户测试看作开发工作的继续，是用户技能培训的过程，是系统试运行所需要的设备、技术、组织和制度的准备过程，也是软件系统开发双方和用户方相互理解、建立长期密切合作关系的过程。

4、用户参与软件工程的难度分析

4．1需求调查困难

软件开发人员总是在困惑，为什么按照用户提出的需求做的软件，用户仍然不满意。

用户也总是在困惑，为什么软件和自己想要的差距会那么大。

究其原因在于，目前大部分的软件开发工作都是面向程序（ProgramOriented），而不是面向用户（CustomerOriented）。

面对一个信息系统，开发者可能首先想到的是整个系统应如何设计？

系统包括哪些部分？

什么样的系统结构最先进？

而使用方领导人员想的却是计算机系统可以帮助管理与决策吗？

可以代替监督和审核吗？

使用起来是不是很方便等等。

在进行需求调研过程中，开发人员自己认为已经了解了使用者的需求，而事实并非如此，他们总是偏重于从技术层面考虑问题，跟用户解释这样不行那样不行，抱怨用户经常修改需求，影响工程进度等等；

用户不知道如何表达才能够使开发人员理解自己的需求，也不明白软件开发为什么有如此多的限制条件。

这些现象都说明用户和开发人员的立场不同，二者之间缺少对需求的共同研究和理解，这些差异就造成软件系统与用户需求产生偏差。

因此，软件开发人员必须转变观点，把“面向程序”转为“面向用户”。

为解决这一问题，可以采用原型化开发方法。

针对生命周期法存在的问题，在八十年代初期，在生命周期法的基础上提出了快速原型法（Rapidprototyping）。

这种方法是基于用户和系统开发人员之间总是存在着这样或那样的认识不一致，或者用户自己也不清楚系统的最终需要，或者由于通信及交流上的障碍无法把自己的意图向开发人员完全表达出来[4]。

也就是说用户只有看到最后那个具体的系统，才能清楚地了解到自己所需要的系统是什么样子。

这说明并不是所有的需求都能预先确定，由于存在这样的问题，系统不能满足用户的需求是常有的事。

因此，开发过程中的反复是必要的，不可避免的。

从这种观点出发，原型法就产生了与生命周期法的两个截然不同的特点:

在还没有完全弄清楚用户的要求之前，即初步了解用户需求之后，通过一个原型设计环境，迅速地建立原型系统，并在原型环境中对原型系统进行修改、扩充、完善。

作为开发信息系统的一种方法，原型从原理到流程都非常简单。

正是由于其简单使用得这种方法曾经倍受推崇。

原型化方法在实际应用中也取得了巨大的成功。

在实际实用中，常常把原型法作为一种需求分析策略，来弥补结构化方法在需求分析阶段所遇到的困难。

一旦得到明确的需求之后，即可运用行之有效的结构化方法来完成系统的开发。

原型化方法采用循环反复、螺旋式上升的工作方法，即了解用户需求——建立初始原型——用户与开发人员评价并修改初始原型直到用户满意为止。

原型化方法始终强调用户的参与，特别是对模型的描述和系统运行功能的检验，都强调了用户的主导作用，缩短了用户和系统开发者的距离，因而信息反馈更及时、准确，使用户的要求得到了很好的满足，同时也提高了用户参与开发的积极性。

4．2需求变更难以控制

项目需求调研阶段，用户因为没有IT知识，讲不清究竟要系统干什么，虽然用户需求书双方签了字，但在用户使用过程中，随着IT经验的增加，自然会发现一些不合理或不完整或缺少的需求，必然会引起需求变更。

需求变化是不可避免的，关键是做好需求控制。

如果放任需求变化，完全用户说了算，项目可能陷人无休止开发或进度失控状态。

但若把需求书看作不可更改的圣经，从表面上看是坚持了合同，但无数事实表明，整个系统却可能因此而最终失败。

需求变更控制管理，是项目管理的核心和关键。

在实施中，设计了用户测试反