信息系统解决方案信息系统的开发方法有什么？

人力资源信息系统建立的步骤是什么？

第1步组建小组 第2步制定目标 第3步全景 第4步未来需要 第5步技术环境 第6步预算 第7步编制说明书 第8步开发或购买 第9步发布需求信息 第10步资料初审 第11步发布项目招标书 第12步评估 第13步测试版本的控制 第14步第二次评估 第15步决策因素 第16步考察案例 第17步第二次演示测试版 第18步再次评估和选择 可以做一个评估表，来进行辅助决策，横向的是决策因素，纵向的是每个系统产品。

如果前面的步骤都很切实地完成，小组将很容易做出选择。

在有些情况下，会发现最后有两个系统都能满足你的需要，那么就可以同这几个公司谈判，来选择最有利于公司的方案--价格、培训、实施等等。

项目的每一步都关系到系统选择的成败。

如何实行信息系统项目管理？

项目经理关键在于对老板，对客户，对合作伙伴，团队成员的沟通把握好"度"。

以下是我的几点积累，如有不妥之处，烦请指正。

一、让老板知道，信息系统的项目是比较独特的、渐进的，是项较复杂的工程 信息系统项目,它不是硬件产品。

具有相对可见的、固定的属性。

正因为它的可定制性强，才具有活力。

一旦接触，就要作好打持久战的准备，公司所有资源要优先供项目组利用。

项目推迟验收，客户需求频繁变更也是一个重大原因。

一个公司的成功与否，很大程度上取决于对项目的 管理是否得当。

二、作好项目范围和项目目标控制 项目范围一定要用规范的文档描述。

客户大多是用口头描述他们心中所想，而且是相当临散的,尤其是政务项目，他们可能写公文很在行，但是要他把需求用文字有条理的表达出来。

一句话很难，就算他们提出来了,也已经是几周之后了。

再者项目范围不清晰，随着项目的进展,项目组所有人员的工作热情很容易被拖垮，双方都觉得项目越作越大，严重超出开始的范围、超出计划完成日期。

今天这个功能不完善,明天那个要细化。

日子一久，开发工程师都有点怀疑自己的能力了。

最好是注明是第几期工程，项目范围和目标提出来了，同时在文档中注明，如超出此项目范围的作何处理。

一定要客户方使用的业务科室和客户领导签字。

或许有这种情况出现，客户方有推脱的理由不方便签字，那么请说服他，这是公司的项目流程和规定。

三、严格控制客户需求变更，告诉他并不是所有的变更都必须实现和能实现 客户是上帝,不可否认。

项目最终是给客户方使用的。

我们是否发现，有时客户提的需求有点奇异，有点脱离实际,或者说暂且实现成本很大。

那么你要坚定些，告诉他们.如按照他所做会如何如何,会带来有成本、进度、质量相关实际的问题。

给他们这样的感觉，我们是系统解决方案提供者，关注的全局的,关键性的，必要性问题的解决。

何况微软还有补丁呢？ 对他们的需求我们实行的方针是:"全部记录，全部评估和控制，部分实施，全部验收" 四、要让客户提供相关的负责人，整些必须的"整"事情 在实际中，有些客户只知道把想要的东西说出来，然后要求完成日期，到时候要用上。

之后好象与他无关。

客户方很可能是业务科室的工作人员, 毕竟他们有自己的日常工作。

那么，勇敢地告诉他，在上次项目启动会议上，他们领导已发表了他在项目中的职责。

并告知他你的实际工作难处。

相信他很难再犹豫和推脱了。

五、让开发工程师"走出去",充分理解调研，面对客户沟通 千万不要认为，调研是浪费时间，调研如果方便的话，带上女同事(嘿....嘿....别小看女同事哦)和开发工程师。

我不赞成，调研人员中只有项目经理和需求分析人员两种角色。

调研中的问题，要生成分析报告。

并能根据调研内容，迅速提出重点和难点,及关键性的问题。

这样开发工程师是会将大部分精力放在重点模块上，会更好地细化关键性的模块。

我们每个人的理解不一样,开发工程师更关注的编码的技巧和功能的实现。

开发工程师代表，参与调研可以很好地保证调研是指导开发，更好地的避免出现业务需求和开发脱节。

再者让他们切实感觉用户的所说，所想。

让他们也了解下原来有时客户需求表达的不清晰和多变性。

平时并不是需求分析人员和调研员故意为难开发工程师。

这样比你天天喊提高产品质量,站在用户角度换位思考强多了。

六、作好实施准备，先"跑"为"赢" 系统好了，要人用呀，相信只有用了，才能体现系统的价值和公司的信誉度。

也只有系统用了，才能体现你作为项目经理的价值。

因此要想法设法，尽一切可能让客户先把数据采集上来。

数据上来了， 主动权就掌握在咱手里了。

之后的种种修改，不再是系统的功能不完善了。

更重要的是公司里，老板会认为你之前所作的各种变更和修改是有意义的。

切莫要把所有功能都细化，抱着等先完善好了，再上线采集数据的心态。

这样成功的可能性很小， 甚至有可能直到你离开之日，系统功能还在作差不多的修改，里面却因没有客户的业务数据作支撑而变得毫无意义。

很多不大不小的项目，缺少实施方法论。

我见过很多软件公司。

就只有业务员和软件工程师两中角色，没有专门的实施工程师。

可能项目小不觉得，项目稍上一点规模，问题就暴露了。

俗话说"三分开发，七分实施"呀。

建议当系统大部分功能经过测试就可以了，先跑起来吧。

一些小修改，非关键性目标的，在"跑后"再作为升级处理。

这样即使某些功能不够细化,你能可以放心的对客户和老板说项目达到预期目标了，甚至可以说成功了。

七、关于在开发过程中的用户征求意见会议 项目经理或开发公司方负责人一定要掌握会议进展的主动权。

但凡有客户方参加的项目会议，介绍完系统之后，客户方领导往往会发表意见，有的是与系统功能有关，有的可能是涉及客户方各职能部门的管理机制，工作流程，甚至是工作上的繁琐。

连春晚都众口难调呀。

记住,跑题了，及时把话题拉回来, 在这些发表意见中不排除有阻碍项目者的高论。

会议不能太长,凡是与信息系统有关的会议,主题切莫离开中心思想"你们开发的系统是什么,能为他们干什么，是怎么体现和优化他们实际的业务流程"勿需太多地用演示帐户，操作开发的信息系统。

他们讨论的时间不能太长（控制在四十分钟左右）。

会议结束后，要第一时间内整理出会议报告，最好是开会时，有专人现场作Word文档。

现场签完名后，才让他们拍屁股走人。

会议记录之后，回到公司召集项目组所有成员及客户方的支持者，对会议记录中相关问题作出评估和控制，最后生产客户需求变更评估和控制文档。

存档(三份,一份交于客户确认，一份交于公司商务部，当然自己得留份底。

到时候老板过问进度，也好有个交代呀)。

信息系统的开发方法有什么？

信息系统的开发方法？（基本原理、优劣点） 1、 系统开发生命周期法： a) 基本原理 用户的积极参与；严格按划分的阶段和活动进行系统开发；设立检查点；文档的标准化。

b) 优点 阶段的顺序性和依赖性；从抽象到具体，逐步求精；逻辑设计与物理设计分开；质量保证措施完备。

c) 劣点 它是一种预先定义需求的方法，基本前提是必须能够在早期就冻结用户的需求，只适应于可以在早期阶段就完全确定用户需求的项目；未能很好地解决系统分析到系统设计之间的过渡，即如何是物理模型如实反映出逻辑模型的要求，通俗地说，就是如何从纸上谈兵到真枪实弹地作战的转变过程；该方法文档的编写工作量极大，随着开发工作的进行，这些文档需要及时更新。

2、 原型法： a) 优点 符合人们认识事物的规律；能及早暴露系统实施后潜在的一些问题；能调动用户参与的积极性。

b) 劣点 不适合大型系统的开发；不适合大量运算及逻辑性强的模块；对原企业基础管理工作要求较高，否则容易走上机械模拟原手工系统的轨道。

3、 面向对象法： a) 基本思想 客观世界是由各种各样的对象组成的，每种对象都有各自的内部状态和运动规律，不同的对象之间的相互作用和联系构成了各种不同的系统。

b) 特点 : 封装性；抽象性；继承性；动态链接性。