在信息系统项目实施过程中，能够避免需求发生变更当然是好事，然而，要想完全避免需求变更是不可能的，关键的是如何管理好变更，按照规范的变更控制流程来处理变更。

除非在签订的合同中有明确规定，否则监理方无权"对项目管理责任方进行处罚"。

立项阶段的主要工作应为根据实际需求确定系统设计目标和项目范围、功能、运行环境、投资预算和竣工时间。
项目经理需要一定的技术功底和国家颁布的资格证书，但是并不一定是领域内的专家。
项目不能边验收边测试，应根据严格的软件工程划分，满足验收条件才能够进行验收，而完成测试是验收必须的前提条件。

软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。软件评审是评审软件产品，不要涉及对软件开发者能力的评价；评审前要制定严格的评审计划，并严格遵守预计的日程安排；对评审中出现的问题要记录在案，不要过多地讨论解决方案，把问题留给软件开发者来解决；要限制参与者人数，并要求参加评审的人员在评审会之前仔细阅读文档，作好充分的准备。

本题考核考生对软件质量管理的掌握。
（1）在软件开发初期制定质量保证计划，并在开发中坚持执行是非常重要的。
（2）开发工作严格按阶段进行，文档工作应在开发完成后集中进行。文档工作应该和开发过程并行进行，所以此说法是错误的。
（3）严格执行阶段评审是确保软件质量的必要手段是正确的。
（4）要求用户参与全部开发过程以监督开发质量是错误的。
（5）开发前选定或制定开发标准或开发规范并遵照执行是正确的。
（6）争取足够的开发经费和开发人力的支持不是必要条件。

项目是一个需要完成的具体而又明确的任务。项目具有一次性、目标明确性、项目实施的整体性的特征。
项目是一个系统，系统的组成部分之间直接或间接地相互作用。组成部分包括参与者、功能、政策、程序、目标或必要条件，每一部分都发挥着重要的作用。
项目的参与者或主要参与者是客户、高级管理层、项目经理和项目组；项目最基本的职能是计划、组织、控制和领导；政策和程序决定系统的行为，决定了参与者和某些职能何时出现并相互作用；必要条件是保障系统正常运行的最基本的基础条件，如必须拥有的最基本的时间、资金和人力。
在项目运作过程中，上述各因素之间全都会发生直接或间接作用，甚至会发生冲突。所有系统存在的目的是要实现一定的目的和目标，具有目的性。所有的职能、参与者、必要条件、政策、程序、目的和目标都是系统实现自身目的的"工具"。
项目内部因素不仅相互作用，而且还会与存在于系统外的因素相互作用。所以，项目是一个开放的系统。作为一个系统，项目有其限定自身范围的界限，但绝不能因此而割断系统与外部环境的联系。由于输入和输出内容进出项目系统，因此应该创造一个开放，而不是封闭的环境。
因此，在实施项目风险管理时，如果忽略项目的系统性的特征，必然会在这些因素中产生混乱的局面，从而在各因素间产生冲突。从开始到结束，所有的项目都是要经历几个不同的时期。项目基本的时期包括酝酿期、成长期、成熟期、衰退期和消亡期。

软件项目的风险主要体现在以下4个方面：需求、技术、成本和进度。
IT项目开发中常见的风险有如下几类：
（1）需求风险。需求已经成为项目基准，但需求还在继续变化；需求定义欠佳，而进一步的定义会扩展项目范畴；添加额外的需求；产品定义含混的部分比预期需要更多的时间；在做需求中客户参与不够；缺少有效的需求变化管理过程。
（2）计划编制风险。计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；产品规模（代码行数、功能点、与前一产品规模的百分比）比估计的要大；完成目标日期提前，但没有相应地调整产品范围或可用资源；涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。
（3）组织和管理风险。仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；低效的项目组结构降低生产率；管理层审查、决策的周期比预期的时间长；预算削减，打乱项目计划；管理层做出了打击项目组织积极性的决定；缺乏必要的规范，导致工作失误与重复工作；非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延长。
（4）人员风险。作为先决条件的任务（如培训及其他项目）不能按时完成；开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；缺乏激励措施，士气低下，降低了生产能力；某些人员需要更多的时间适应还不熟悉的软件工具和环境；项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；没有找到项目急需的具有特定技能的人。
（5）开发环境风险。设施未及时到位；设施虽到位，但不配套，如没有电话、网线和办公用品等；设施拥挤、杂乱或者破损；开发工具未及时到位；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；新的开发工具的学习期比预期的长，内容繁多。
（6）客户风险。客户对于最后交付的产品不满意，要求重新设计和重做；客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；客户对规划、原型和规格的审核、决策周期比预期的要长；客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；客户答复的时间（如回答或澄清与需求相关问题的时间）比预期长；客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。
（7）产品风险。矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；开发额外的不需要的功能（镀金），延长了计划进度；严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；开发一种全新的模块将比预期花费更长的时间；依赖正在开发中的技术将延长计划进度。
（8）设计和实现风险。设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成，需要重新设计或制作。
（9）过程风险。前期的质量保证行为不真实，导致后期的重复工作；太不正规（缺乏对软件开发策略和标准的遵循），导致沟通不足，质量欠佳，甚至需重新开发；过于正规（教条地坚持软件开发策略和标准），导致过多耗时于无用的工作；向管理层撰写进程报告占用开发人员的时间比预期的多；风险管理粗心，导致未能发现重大的项目风险。

在软件的开发与维护过程中，版本控制工具是用来存储、更新、恢复和管理软件的多版本的工具。

项目质量管理必须针对项目的管理过程和项目产品，质量保证是所有为保证项目能够满足相关的质量标准而建立的有计划的、系统的活动，包括保证项目管理过程的质量和项目产品的质量。项目质量管理过程包括质量计划编制、质量保证和质量控制。

项目进度计划的制订是一个迭代的过程，如果起始和结束的日期不合实际，则项目可能无法按计划完成。为了对进度变更进行控制，项目经理可以制订进度管理计划。事实上，在项目管理过程中，其他三个计划通常都是没有的。所有进度问题都应该在进度管理计划中得到体现。