《系统架构设计师 历年真题 2021年5月信息系统项目管理师论文.docx》由会员分享，可在线阅读，更多相关《系统架构设计师 历年真题 2021年5月信息系统项目管理师论文.docx（9页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、2021年5月信息系统项目管理师论文【简答题】论信息系统项目的合同管理项目合同管理是通过对项目合同的全生命周期进行管理，以回避和减轻可识别的项目风险。请以“论信息系统项目的合同管理”为题进行论述”：1.概要叙述你参与管理过的信息系统项目(项目的背景、项目规模、发起单位、目的、项目内容、组织结构、项目周期、交付的成果等)，并说明你其中承担的工作(项目背景要求本人真实经历，不得抄袭及杜撰)2.请结合你所叙述的信息系统项目，围绕以下要点论述你对信息系统项目合同管理的认识，并总结你的心得体会：(1)项目合同管理的过程(2)在有监理参与的情况下，结合项目管理实际写出详细的合同索赔流程。3.请结合你所叙述
2、的信息系统项目，编制一份对应的项目合同(列出主要的条款内容)。1、答案：解析：架构：第一部分：摘要+正文第二部分：合同管理过程合同管理包括：合同签订管理、合同履行管理、合同变更管理、合同档案管理、合同违约索赔管理。其中这部分要求写出要有监理参与的情况下，写出一个详细的合同索赔流程。合同索赔流程项目发生索赔事件后，一般先由监理工程师调解，若调解不成，由政府建设主管机构进行调解，若仍调解不成，由经济合同仲裁委员会进行调解或仲裁。在整个索赔过程中，遵循的原则是索赔的有理性、索赔依据的有效性、索赔计算的正确性。索赔具体流程如下。(1)提出索赔要求。当出现索赔事项时，索赔方以书面的索赔通知书形式，在索赔
3、事项发生后的28天以内，向监理工程师正式提出索赔意向通知。(2)报送索赔资料。在索赔通知书发出后的28天内，向监理工程师提出延长工期和（或）补偿经济损失的索赔报告及有关资料。索赔报告的内容主要有总论部分、根据部分、计算部分和证据部分。索赔报告编写的一般要求如下。索赔事件应该真实。责任分析应清楚、准确、有根据。充分论证事件给索赔方造成的实际损失。索赔计算必须合理、正确。文字要精炼、条理要清楚、语气要中肯。(3)监理工程师答复。监理工程师在收到送交的索赔报告有关资料后，于28天内给予答复，或要求索赔方进一步补充索赔理由和证据。(4)监理工程师逾期答复后果。监理工程师在收到承包人送交的索赔报告的有关
4、资料后28天未予答复或未对承包人作进一步要求，视为该项索赔已经认可。(5)持续索赔。当索赔事件持续进行时，索赔方应当阶段性向监理工程师发出索赔意向，在索赔事件终了后28天内，向监理工程师送交索赔的有关资料和最终索赔报告，监理工程师应在28天内给予答复或要求索赔方进一步补充索赔理由和证据。逾期未答复，视为该项索赔成立。(6)仲裁与诉讼。监理工程师对索赔的答复，索赔方或发包人不能接受，即进入仲裁或诉讼程序。第三部分：总结项目管理中合同管理的组织过程资产总结。【简答题】论信息系统项目的范围管理项目范围管理必须清晰地定义项目范围，其主要工作是要确定哪些工作是项目应该做的，哪些不应该包括在项目中。请以“
5、论信息系统项目的范围管理”为题进行论述1.概要叙述你参与管理过的一个信息系统项目(项目的背景、项目规模、发起单位、目的、项目内容、组织结构、项目周期、交付的成果等)，并说明你在其中承担的工作(项目背景要求本人真实经历，不得抄袭及杜撰)2.请结合你所叙述的信息系统项目，围绕以下要点论述你对信息系统项目范围管理的认识，并总结你的心得体会：(1)项目范围管理的过程;(2)根据你所描述的项目范围，写出核心范围对应的需求跟踪矩阵。3.请结合你所叙述的项目范围和需求跟踪矩阵，给出项目的WBS(要求与描述项目保持一致，符合WBS原则，至少分解至5层)1、答案：解析：架构：第一部分：摘要+正文第二部分：范围管
6、理过程1、规划范围管理2、收集需求其中收集需求要求写出核心范围对于的需求跟踪矩阵。因此涉及到的知识有：（1）需求文件的内容包括（但不限于）以下几个方面：业务需求，包括可跟踪的业务目标和项目目标、执行组织的业务规则、组织的指导原则。干系人需求，包括对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求。解决方案需求，包括功能和非功能需求、技术和标准合规性(Complicance)需求、支持和培训的需求、质量需求和报告需求。可用纯文本方式或用模型展示解决方案需求，也可两者同时使用。项目需求，包括服务水平、绩效、安全和合规性等，以及验收标准。过渡需求。与需求有关的假设条件、依
7、赖关系和制约因素。（2）需求跟踪矩阵在CMMI中，需求管理是已管理级的一个关键过程域，其目标是为产品需求建立一个基线，供软件开发及其管理使用，使计划、产品和活动与需求保持一致。从需求工程的角度来看，需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。可跟踪性包含两个层面的含义，一个是项目执行过程的两个或多个产品之间能够建立关系的程度，尤其是那些具有前后关系或主从关系的产品。例如，某个给定构件的需求和设计的匹配程度
8、；另一个是项目产品中每个元素能够建立其存在理由的程度，例如，产品设计中的每个元素定位它所满足需求的程度。1、需求跟踪的内容每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型，如图5-1所示。图5-1中的箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。图5-1左半部分表明，从用户原始需求可向前追溯到需求
9、文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。如果以用例(usecase)的形式来描述用户需求，图5-1左半部分就是用例和功能需求之间的跟踪情况。图5-1右半部分表明，由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能
10、将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。第五类联系链是需求文件之问的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。2、需求跟踪矩阵表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束时都能交付，还可以为管理产品范围变更提供框架。需要跟踪的内容包括以下几个方面
11、。业务需求、机会、目的和目标。项目目标。项目范围(WBS可交付成果)。产品设计。产品开发。测试策略和测试场景。高层级需求到详细需求。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵，它保存了需求与后继工作 成果的对应关系。例如，从用户原始需求到需求文件之间的跟踪，可以采用如表5-3所示的矩阵。图5-1中的箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。图5-1左半部分表明，从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求
12、，确认每个需求的出处。如果以用例(usecase)的形式来描述用户需求，图5-1左半部分就是用例和功能需求之间的跟踪情况。图5-1右半部分表明，由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。第五类
13、联系链是需求文件之问的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。2、需求跟踪矩阵表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束时都能交付，还可以为管理产品范围变更提供框架。需要跟踪的内容包括以下几个方面。业务需求、机会、目的和目标。项目目标。项目范围(WBS可交付成果)。产品设计。产品开发。测试策略和测试场景。高层级需求到详细需求。不论采用何种跟
14、踪方式，都要建立与维护需求跟踪矩阵，它保存了需求与后继工作 成果的对应关系。例如，从用户原始需求到需求文件之间的跟踪，可以采用如表5-3所示的矩阵。对于从需求文件到下游工作产品之间的跟踪，可以采用如表5-4所示的矩阵。对于从需求文件到下游工作产品之间的跟踪，可以采用如表5-4所示的矩阵。需求跟踪矩阵中可以定义各种产品元素类型间的一对一、对多和多对多关系，也就是说，允许在表5-4的一个单元格中填入多个元素来实现这些特征。例如，一个构件对应一个设计元素，多个测试案例验证一个功能点，每个用例导致多个功能点等。应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。
15、需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。另外，为了确保干系人满意，可能需要增加一些补充属性，例如，稳定性、复杂性和验收标准等。3、定义范围4、创建WBS其中要求举例写出详细的五层WBS。涉及到的知识点如下：WBS将项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解为工作包，持续这个过程，直到整个项目都分解为可管理的工作包，这些工作包的总和是项目的所有工作范围。最普通的WBS如表5-5所示。需求跟踪矩
16、阵中可以定义各种产品元素类型间的一对一、对多和多对多关系，也就是说，允许在表5-4的一个单元格中填入多个元素来实现这些特征。例如，一个构件对应一个设计元素，多个测试案例验证一个功能点，每个用例导致多个功能点等。应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。另外，为了确保干系人满意，可能需要增加一些补充属性，例如，稳定性、复杂性和验收标准等。3、定义范围4、创建WBS其中要求举例写出详细的五层WBS。涉及到的知识点如下：WBS将项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解为工作包，持续这个过程，直到整个项目都分解为可管理的工作包，这些工作包的总和是项目的所有工作范围。最普通的WBS如表5-5所示。这样分层的特点有：(1)每层中的所有要素之和是下一层的工作之和。(2)每个工作要素应该具体指派一个层次，而不应该指派给多个层次。(3) WBS需要有投入工作的范围描述，这样才能使所有人对要完成的工作有全面的了解。5、确认范围6、范围控制第三部分：总结项目管理中范围管理的组织过程资产总结。