信息系统项目管理师论文评分参考标准

《信息系统项目管理师论文评分参考标准》由会员分享，可在线阅读，更多相关《信息系统项目管理师论文评分参考标准（18页珍藏版）》请在金锄头文库上搜索。

1、信息系统项目管理师论文评分参考标准1. 论文满分是 75 分，论文评分可分为优良、及格与不及格 3 个档次。 评分的分数可分为： 60 分至 75 分优良(相当于百分制 80 分至 100 分)。 45 分至 59 分及格(相当于百分制 60 分至 79 分)。 0 分至 44 分不及格(相当于百分制 0 分至 59 分)。评分时可先用百分制进行评分，然后转化为以 75 分为满分(乘 0.75)。2具体评分时，参照每一试题相应的“解答要点”中提出的要求，对照下述 5 个方面评分：(1)切合题意 (30%)无论是技术论文、理论论文或实践论文，都需要切合解答要点中的一个主要方面或者多个方面进行论述

2、。可分为非常切合、 较好地切合与基本上切合 3 档。(2)应用深度与水平 (20%)可分为很强的、较强的、一般的、较差的独立工作能力 4 档。(3)实践性(20%)可分为如下 4 档； 有大量实践和深入的专业级水平与体会。 有良好的实践与切身体会和经历。 有一般的实践与基本合适的体会。 有初步实践与比较肤浅的体会。(4)表达能力 (15%)可从是否逻辑清晰、表达严谨、文字流 畅和条理分明等区分为 3 档。(5)综合能力与分析能力(15%)可分为很强、比较强和一般 3 档。 3下述情况的论文，需要适当扣分： 摘要应控制在 200-400 字的范围内，凡是没有写论文摘要，摘要过于简略，或者摘要中没

3、有实质性内容的论文。 字迹比较潦草，其中有不少字 难以辨认的论文。 正文基本上只是按照条目方式逐条罗列叙述的论文。 确实属于过分自我吹嘘或自我标榜、夸大其 词的论文。 内容有明显错误和漏洞的，按同一 类错误每一类扣一次分。 内容仅属于大学生或研究生实习性质的项目、并且其实际应用背景的水平相对较低的论文。可考虑扣 5 分到 10 分。4下述情况之一的论文，不能给予及格分数： 虚构情节，文章中有较严 重的不真实的或者不可信的内容出现的论文。 未能详细讨论项目开发的实际经验，主要从 书本知识和根据资料摘录进行讨论的论文。 所 讨论的内容与方法过于陈旧，或者 项目的水准相对非常低下的论文。例如，数据库

4、设计仅讨论了 Foxpro。且没有 鲜明特色的应用；开发的是仅能用单机版的(孤立型的) 、规模很小的、并且没有特色的应用项目。 内容不切题意，或者内容相 对很空洞，基本上是泛泛而谈的、没有较为深入体会的论文。 正文与摘要的篇幅过于短小的论文(如正文少于 1200 字)。 文理很不通顺，错别字很多，条理与思路不清晰，字迹过于潦草等情况相对严重的论文。5下述情况，可考虑适当加分： 有独特的见解或者有着很深入的体会，相对非常突出的论文。 观点很高，确实符合于当今计算机应用系统发展的新趋势与新动向，并能初步加以实现的论文。 内容翔实，体会中肯，思路清晰，非常切合实际的很 优秀的论文。 项 目难度很高，

5、或者项目完成的 质量优异，或者项目涉及重大课题，并且能正确按照试题要求论述的论文。可考虑加 5 分到 10 分。论软件项目管理中的需求变更控制摘要从计算机系 统集成软件开发项目需求变更控制的角度,简单分析需求变更产生的原因、需求变更将会 对项目产生的影响,并结 合实践说明如何在实际工作中对软件开发项目的需求变更进行有效控制和管理 ,以减少项目风险,使项目顺利交付。关键词 项目管理 需求变更 控制软件项目在执行过程的变更,特别是需求的变更是最难把握的,它也是影响到整个项目成败的关键因素。一、计算机系统集成软件开发项目需求变更产生的原因对于软件项目的需求而言,产生变更的原因集中在下面几个方面:1.

6、用户对系统功能理解的分歧。在进行用户需求调查分析时,分析人员的知识、背景、与用 户的交流情况等因素会造成系统分析人员和用户在功能理解上的分歧,随着项目的进行,这种分歧肯定会带来变更。2.用户业务逻辑发生了变化。用户自身的业务逻辑不太明确,特别是处于激烈竞争情况下的用户肯定要随着市场情况的变化,随时调整自己的运作来适应这种变化,这肯定会对相关的软件产品提出更多的变更要求。3.用户在试用过程中提出的变更。当用户拿到测试版本可以进行实际操作时,用户一般都会对功能、性能、界面、操作方式等提出新的意见,这时变更产生了。4.技术的升级。技术的升级分为两个方面,一方面是随着信息化技术的迅速发展,原项目中使用

7、的技术可能变成过时技术,需要对原技 术进行升级;另一个方面是开发方自身对软件版本升级、性能改 进、 设计修正时产生的变更。从上面可以看出,指望软件项目需求能从始至终一成不变是不可能的。二、计算机系统集成软件开发项目需求变更的影响及管理原则1.设定项目需求基线。需求基线是需求变更的参照标准,每次的变更均应在需求基线的基础上进行。每次 变更评审通过后要重新确定需求基 线,使其符合需求变更后的状况。2.严格执行需求变更流程,并记录在变更过程中产生的所有文档。3.成立项目变更控制委员会(CCB),负责对项目变更进行评估,裁定哪些变更需要执行,哪些变更应该放弃。变更控制委员会的成员应 由项目所涉及到的多

8、方面人同组成,应该包括用户方和开发方的决策人员在内。4.需求变更后,受影响的相关软件计划、产品、活 动都要进行相应的变更,以保持和更新的需求一致。三、计算机系统集成软件开发项目需求变更的流程在软件项目需求变更时,一般采用下面的流程进行控制:1.申请变更。当项目开发组确认将要产生需求变更时,用标准的变更申请表格将用户的每一次变更申请记录存档。2.变更评估。项目开发组收到用户提交的需求变更申请后,应对该变更所带来的影响进行评估。它包括项目的人力、物力、资金、管理、时间、质量、工作负荷等内部因素,以及外部因素如资本、用户要求的完工时间、项目负债情况等各个方面的影响。对于一个变更的申请,可能会有以下几

9、个可能的评估结果:(1)在现有资源和时间范围允许的情况下可以采纳该变更。(2)可以采纳,但要延长交付时间。(3)在现有的可交付 时间内可以采纳,但需要额外的资源支持。(4)可以采纳,但需要额外的资源和延长交付时间。(5)可以采纳,但需要采取多次发布策略,并排定不同发布时期交付成果的优先次序。这种情况的发生非常频繁,项目经理需要权衡将一些重要的工作提前完成,而有一些不重要的工作延迟完成。(6)不能采纳。3.变更的实施。一旦确定变更后,下一步就是分析和选择可行的实施方案。项目的目标、 预算、团队以及项目的进度是决定项目成功实施的主要因素。在需求变更时,力求在尽可能小的变动幅度内对这些主要的因素 进

10、行微调。为了将项目变更的影响降低到最小,一定要认真执行变更的控制流程 ,减小项目风险。四、实际项目分析以某学院的信息管理系统软件开发项目为例。该系统包括了学籍管理、排课管理、学生选课、教材管理、学生考勤管理、教学 质量管理、考试管理、成绩管理、宿舍管理、财务管理、证明管理、招生管理等子系统 。在开发过程中,我们对需求变更进行了较严格的管理,产品得以按时保质地上线。在该管理信息系统的开发过程中,变更的因素有以下几个:1.由于项目启动时间距离第一个版本的上线时间很近,不可能在短时间内将所有的需求都获取到。2.开发 人员有时会对用户的描述理解不正确,或遗漏某些要求,所以要对已有的需求进 行修改。3.

11、用户在项目开始的时候,大都不是很了解自己到底需要什么,等他们使用一段 时间管理系统后,就会在实际使用中不断发现这样那样的需求。 4.最主要的因素 ,就是该学院成立时间不长,且不是采用国内常规的管理方法,而要使这些管理方法适合国内的高校管理体制,需要有一段磨合期,所以学院内部的管理经常变,导致系统的相应需求也必须变。变更控制委员会由主管这套系统开发的副院长、项目经理以及配置管理员三个人组成。根据开发的实际情况,我们制定了一套变更管理程序,就是所有变更都必须以变更申请书的形式提交给变更控制委员会,变更控制委员会评估后,出具变更报告,然后才交给相关人员做相应处理,之后,由测试人员对变更后的相关用例进

12、行测试跟踪。一个需求变更申请提交后,变更控制委员会对其进行评估,如确认进行变更,则由我方项目经理出具一份变更报告,写明变更事由、提出方、提出时间、变更评估结果。配置管理员将这份变更报告加到配置管理库中存档,并分发给变更申请人以及相关系统分析员。系统分析员对之进行分析,提交出一份变更列表,将该变更所影响到的文档、程序都详细的列出来,上交给配置管理员进行存档。然后,系统分析员对列表的中所列出来的文档逐个进行修改,再交由编程人员进行相应的代码修改,然后提交测试员测试,出具测试报告。这些修改的文档、代码以及测试报告都要提交给配置管理员进行存档管理,配置管理员还要根据提交情况对变更列表进行相应维护,如某

13、项修改完成了,就要在它后面打上完结标记。当该变更列表中的所有变更项都完结了,配置管理员在变更报告后要加上实际完成时间。这样,变更所导致的文档、程序变化就可以在一个可以追溯、可以控制的状态下进行了。减少了遗漏的可能性,并便于变更的追踪。由于采取了上述变更控制方法,即使该项目的变更比较多,但还是能保持开发工作正常有序地进行。五、结束语对于软件开发的过程中不可避免的会出现需求变更,并且这些变更会发生在项目的整个生命周期里,因此变更控制显得尤其重要,变 更控制的管理好坏对项目成败有重要影响。论 IT 软件项目中的沟通管理【摘要】IT 软件 项目开发中最普遍的 现象是一遍一遍的返工，项目工期一推再推，项

14、 目成本一再加大，客户需求不断提出，项目管理日益困 难，造成这些普遍现象的一个重要因素就是沟通管理问题。沟通失 败常常是 软件项目成功的最大障碍。对于软件项目来说 ，要科学地组织、指挥、 协调、控制项目的实施过程，就必须进行良好的沟通管理。【正文】1.建立适合组织的项目沟通管理体系1.1 基于组织结构的沟通计划编制。沟通计划编制主要是确定项目干系人的信息需求和沟通需求;何人，在何时，需要何种信息，以及信息提供的方法。虽然所有项目都需要进行项目信息沟通，但所需要的信息和发布的方法差别甚远。因为项目的组织结构将在很大程度上影响项目的沟通需求，所以沟通计划的编制一定是在组织结构的基础上建立的。项目沟

15、通计划是项目管理计划中的一部分，它的作用非常重要。在 IT 软件项目过程中经常会出现被动式、应付式沟通，造成项目随意而行、混乱无序。这种问题的原因主要是在早期项目计划阶段没有制定完善的沟通计划。在一个组织中，一般会有以往项目实施的沟通管理计划，在一个新的项目实施时，可以重复利用组织的过程资产， 结合新项目的组织结构特点修订相应的沟通管理计划。从便于管理和节约的角度看，组织应该在各个项目间采取基本统一格式的沟通管理模版。一个沟通管理计划的样本模块主要包括分发给项目干系人的信息、信息分配的动机、信息分 发的频率、信息分 发的时间表、信息编排与传输方法以及项目成员沟通职责等。1.2 信息分发。信息分

16、发涉及向项目干系人及时提供所需的信息。信息分发的技术主要包括沟通技能，书面的、口 头的，内部的、外部的，正式的、非正式的，纵向的以及横向的;信息 查询体系，包括人工存档体系、电子数据库、项目管理软件以及允许查阅的诸如设计规范、测试计划等技术文档系统。 信息发送方法，包括项目会议、书面文挡复印件的发布、共享的网 络电子数据库、 传真、电子邮件、语音邮件、电视会议和项目内部网。一般从信息的迫切性、项目环境的可能性等方面综合考虑确定何种技术和方法。1.3 绩效报告。绩效报告是向所有项目干系人提供信息，主要包括状态报告、 进度报告以及预测。一般使用项目日报、 项目月报、召开阶段性会议、汇报等方式来提供有关范围、进度、费用、质量等信息。项目管理者可以基于绩效报告的有关信息进一步开展相关的偏差分析、趋势分析以及挣值分析。通常， 项目绩效的分析通常产生对项目的某些方面变更的要求。1.4 管理收尾。管理收尾包含