摘要：对于【信息系统项目管理师】软考考试而言，试题无疑是最重要的学习资料之一。在软考备考过程中，吃透所考知识点、熟悉出题思路，对我们提升分数的效果是最明显的，通过试题反复练习，还可以查漏补缺。今天，给大家带来【信息系统项目管理师】部分试题的详解，一起来看看吧~



1、依据GB/T 16680-2015《系统与软件工程 用户文档的管理者要求》，管理者应制定和维护用户文档编制计划。（   ）不属于用户文档编制计划内容。
A、 文档开发过程中实施的质量控制
B、 用户文档的可用性要求
C、 确定用户文档需要覆盖的软件产品
D、 每个文档的媒体和输出格式的控制模板和标准设计

答案:A
答题解析:

依据《系统与软件工程 用户文档的管理者要求》（GB/T 16680－2015），一个计划应包含以下元素：①发布日期和状态；②范围；③发行机构；④适用的政策、法律、标准、合同、要求和其他计划和程序的参考资料；⑤审批授权；⑥技术和管理评审和报告的方法；⑦其他计划，进一步补充计划细节而产生的计划或任务描述；⑧计划的活动和任务；⑨工具、方法和技术的确定；⑩进度表；⑪预算和成本估计；⑫资源以及资源分配；⑬职责和授权，包括高级责任人和直接责任人；⑭各方之间的沟通接口；⑮风险和风险识别、评估和转移活动；⑯质量保证和控制测量；⑰环境、基础设施、保密性和安全性；⑱变更流程和变更历史；⑲终止过程。

除上述通用内容，文档编制计划还宜包含如下内容：

l 确定用户文档需要覆盖的软件产品；

l 每个文档或者文档集的理论依据或目的（指导性的或者供参考的）以及范围；

l 每个文档的预期受众（用户属性），例如以教育水平、技能和经验为特征进行描述；

l 要获取、重用或开发的文档和信息以及它们的预期来源；

l 用户文档的可用性要求；

l 每个文档的媒体和输出格式的控制模版和标准设计；

l 根据文档主题、插图、单词、页、错误信息、命令或者其他参数的个数估计用户文档的大小；

l 用户文档的大纲、目录或者主题列表；

l 文档开发和生产过程中的方法和工具，包括在软件开发过程中将软件变更信息及时传递到文档编写者的方法；

l 角色和职责；需要的技能水平，团队成员选拔计划可以作为可选内容；

l 文档开发、评审、批准通过和发布的进度表，包括对软件产品开发进度表或其他文档项目的依赖；

l 翻译和本地化用户文档的相关计划；

l 确定具体交付物，例如打印版的份数（如果适用）、磁盘和文件格式（包括软件版本）、提交物发布的位置。

文档管理计划还宜包含如下信息：

l 信息管理策略以及和整体组织战略的关系；

l 描述用户所需的电子版和打印版信息的授权、开发、评审、存储、通信和维护的过程和相关活动；

l 确定信息获取，重用和生产的过程；

l 与整个组织方针相一致的资源，角色和责任；

l 内容管理或重用策略与版本控制（文档配置管理）；

l 确定用户电子版或打印版文档的结构、格式和风格的标准、指南、模型或模板；

l 方法和工具；

l 文档开发过程中实施的质量控制；

l 确定信息开发、评审和批准过程中典型的进度表和标准的持续时间；

l 确定用户文档编制项目的标准测量和估算方法；

l 谁将接收或访问受限的信息；

l 保留信息的策略和用户文档版本控制、变更控制和维护的规定；

l 过程评估和改进的规定。

可见选项A属于文档管理计划的内容。

2、以下关于信息系统生命周期的叙述中，不正确的是（ ）。
A、 信息系统生命周期可分为立项、开发、运维和消亡四个阶段
B、 立项阶段结束的里程碑是集成企业提交的立项建议书
C、 广义的开发阶段包括系统实施和系统验收
D、 在系统建设的初期就要考虑系统的消亡条件和时机

答案:B
答题解析:

立项阶段：即概念阶段或需求阶段，这一阶段根据用户业务发展和经营管理的需要，提出建设信息系统的初步构想；然后对企业信息系统的需求进行深入调研和分析，形成《需求规格说明书》并确定立项。

选项B错，立项建议书（项目建议书）是建设单位向发改委提出的对于拟建项目的总体构想。虽然也属于立项阶段，不过这个立项是属于前期的，需要经过审批才能成立项目，然后进行后续的招投标和签订合同阶段。题目中的信息系统生命周期阶段中的立项已经是签订合同之后，真正着手做项目前进行的工作。

3、以下关于需求分析的叙述中，不正确的是：（ ）。
A、 需求分析的目的是确定系统必须完成哪些工作，对目标系统提出完整、准确、清 晰、具体的要求
B、 完整的需求分析过程包括：获取用户需求、分析用户需求、编写需求说明书三个过程
C、 根据项目的复杂程度，需求分析的工作可以由专门的系统分析人员来做，也可以由项目经理带领技术人员完成
D、 软件需求分为三个层次：业务需求、用户需求、功能需求与非功能需求

答案:B
答题解析:

软件需求分析主要目的是分析并抽象描述各种需求信息，为目标系统建立一个概念模型，是在计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。是要解决目标系统“做什么”的问题。由此可见选项A正确。

选项B“需求分析”可分为需求提出、需求描述及需求评审三个阶段。

需求提出：主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。开发人员和用户确定一个问题领域，并定义一个描述该问题的系统，这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。

需求描述：在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。

需求评审：在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。因此，选项B不正确。

选项C，根据项目的复杂程度，需求分析的工作可以由不同人员来完成。

选项D，需求分为三个层次：业务需求、用户需求、功能需求与非功能需求。

业务需求（Business Requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。

用户需求（User Requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件一响应表都是达用户需求的有效途径。也就是说，用户需求描述了用户能使用系统来做些什么。

功能需求（Functional Requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（Behaviour Requirement）。功能需求描述是开发人员需要实现什么。

非功能需求：产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。