Download
1 / 140
1.4k likes | 1.48k Views
信息系统工程监理质量控制务实. 主讲 ：. 时代鼎典. 目 录. 第 1 篇 信息系统工程与监理总论 第 1 章 信息系统工程与监理概述 第 2 章 项目管理的生命周期 第 3 章 监理工作重点 第 2 篇 软件工程监理 第 4 章 软件工程管理体系 第 5 章 软件工程启动阶段的监理 第 6 章 需求分析阶段监理 第 7 章 分析设计阶段的监理 第 8 章 编码实现阶段的监理. 第 9 章 验收测试阶段的监理 第 10 章 试运行阶段的监理 第 11 章 最终验收阶段监理 第 12 章 运行维护阶段的监理
E N D
信息系统工程监理质量控制务实 主讲 ：
时代鼎典 目 录 第1篇 信息系统工程与监理总论 第1章 信息系统工程与监理概述 第2章 项目管理的生命周期 第3章 监理工作重点 第2篇 软件工程监理 第4章 软件工程管理体系 第5章 软件工程启动阶段的监理 第6章 需求分析阶段监理 第7章 分析设计阶段的监理 第8章 编码实现阶段的监理
第9章 验收测试阶段的监理 第10章 试运行阶段的监理 第11章 最终验收阶段监理 第12章 运行维护阶段的监理 第13章 典型软件工程分析 第3篇 计算机网络系统工程监理 第14章 标准化组织介绍 第15章 计算机网络系统分类 第16章 计算机网络实施准备阶段监理 第17章 方案深化设计阶段监理 第18章 设备采购阶段监理 第19章 现场安装调试阶段监理 第20章 测试阶段监理 第21章 验收阶段监理 第22章 运行阶段监理 第23章 典型案例分析
时代鼎典 第一章 信息系统工程与监理概论 • 1.1 信息系统工程 信息系统工程是指信息化工程建设中的信息网络系统信息资源系统、信息应用系统的新建、升级、改造工程。 • 1.2 信息系统工程的产生及发展 90年代初萌芽 2002年正式推向IT行业市场化运作 • 1.3 信息系统工程监理 信息系统工程监理是指依法设立且具备相应资质的信息系统工程监理单位，受业主单位委托，依据国家有关法律法规、技术标准和信息系统工程监理合同，对信息系统工程项目实施的监督管理。
1.4 信息系统工程干系人 • 1.4.1 甲方 甲方:信息系统工程建设合同的建设机构。 包括：建设单位、业主单位、审批部门、监察部门、审计部门等。 • 1.4.2 乙方 乙方：信息系统工程建设合同的承建机构。 包括：承建单位、设计单位、咨询单位、施工单位、分包单位等。 • 1.4.3 监理方与监理机构 监理方：信息系统建设过程中独立的第三方，受甲方委托，确保工程的设计，实现预定的投资、进度、质量目标而进行协调、监督和管理。 监理机构：监理方具体完成监理服务的组织。 • 1.4.4 第三方机构 协助甲方完成信息系统工程预定目标，而提供专项服务的机构，主要有投资机构、招标代理机构、咨询机构、安全测评机构、系统测评机构、系统评估机构、设计机构等。 • 1.5 信息系统工程监理实施范围和内容 • 1.5.1 工程监理实施范围 • 1.5.2 工程监理内容 三控、X管、一协调
时代鼎典 第二章 项目管理的生命周期 2.1项目生命周期 立项-招投标-实现-运维 2.2 各阶段工作流程框架与职责 2.2.1 规划阶段 2.2.2 立项阶段 2.2.3 招投标阶段 2.2.4 启动阶段 2.2.5 需求阶段 2.2.6 设计阶段 2.2.7 实施阶段
2.2.8 测试验收阶段 2.2.9 培训阶段 2.2.10 试运行阶段 2.2.11 最终验收（结项）阶段 2.2.12 运行维护阶段
第三章 监理工作重点 • 3.1 规划阶段 规划阶段是信息工程建设的第一步，规划的好坏影响着项目建设的成败。 任务：发起、论证、审定。 • 3.1.1项目发起 需要确定： 监理服务委托合同 规划书 需求调研计划和方案 规划阶段需求建议书 • 3.1.2项目建议 需要确定： 规划阶段计划和实施方案 规划阶段需求调研报告 规划阶段需求建议书（初步） 规划阶段需求建议书（初步）审核意见
3.1.3项目论证 需要确定： 规划阶段专家需求建议报告 规划阶段监理机构需求建议 规划阶段业主单位意见 规划阶段需求建议书 规划阶段需求建议书（确认单） • 3.1.4项目审核 成果：规划阶段需求确认报告
3.2 立项阶段 监理工作重点：协助建设单位完成《可行性研究报告》的分析、论证等相关咨询和管理服务。 • 3.2.1立项准备 （1）监理机构协助建设单位根据《规划阶段需求建议书》、《规划阶段需求确认报告》和业主单位意见，编写《立项阶段计划和实施方案》。 （2）监理机构协助建设单位对《立项阶段计划和实施方案》进行评审，提交《<立项阶段计划和实施方案>评审意见》，并成立立项阶段工作小组。 阶段成果 《立项阶段计划和实施方案》 《<立项阶段计划和实施方案>评审意见》
3.2.2立项申请 （1）监理机构协助建设单位根据国家和地方相关法律法规，以及《电子政务标准化指南》和相关电子政务或信息化建设管理办法等，编制《立项报告》，并得到相关部分的审批。 （2）监理机构协助建设单位向管理部门提交《立项报告》和《规划阶段需求建议书》，征的相关部门的批准；由财政部门进行初步评审，得到财政部门的《立项批准书》和项目计划资金后，展开可行性分析阶段工作。 阶段成果：《立项报告》、《<立项报告>建设单位审批单》、《立项批准书》、《项目资金说明书》 • 3.2.3可行性分析阶段 1.可行性分析流程 （1）根据《规划阶段需求建议书》、《立项报告》等确定项目规模和目标，形成《项目规模和建设目标说明》，并得到相关部门确认。
（2）监理机构协助建设单位对现有系统进行分析，进一步阐述《规划阶段需求建议书》中开发新系统或修改现有系统的必要性，形成《现有系统分析报告》。（2）监理机构协助建设单位对现有系统进行分析，进一步阐述《规划阶段需求建议书》中开发新系统或修改现有系统的必要性，形成《现有系统分析报告》。 （3）根据《现有系统分析报告》和《规划阶段需求建议书》对项目进行初步可行性研究，形成《初步可行性研究报告》，并由相关部门审核确认。 （4）监理机构协助建设单位根据《初步可行性研究报告》对项目进行可行性研究，形成《项目可行性研究报告》，并由相关部门进行审核确认。 （5）监理机构协助建设单位依据《立项阶段计划和实施方案》，完成各项论证工作的实施，撰写《项目可行性论证进展报告》，即使向建设单位汇报论证进度，并进行质量、进度和风险和费用控制。 阶段成果 《项目可行性论证进展报告》、《项目可行性论证费用报告》、《项目规模和建设目标说明》、《现有系统分析报告》、《可行性研究报告》
2.对现有系统的分析 目的：进一步阐述《规划阶段需求建议书》中开发新系统或修改现有系统的必要性。 重点考虑以下问题： （1）新系统必须能够解决旧系统中存在的问题。 （2）处理流程和数据流程。说明现有系统基本的处理流程和数据流程。 （3）费用开支。 （4）工作负荷。列出现有系统所承担的工作及工作量。 （5）人员。列出现有系统的运行和维护需要的人员的专业技术类别和数量。 （6）设备。现有系统所使用的各种设备。 （7）局限性。 （8）分析员对现有系统的文档资料和使用手册进行分析。 （9）分析员实地考察现有系统，了解现有系统能做什么，画出描绘现有系统的高层系统流程图。 （10）了解并记录现有系统和其他系统的接口情况。
3.所建议的新系统分析 说明所建议新系统的目标和要求将如何被满足。通过对现有系统存在的问题的分析，并根据需要，合理的给出所建议系统的体系结构、功能结构、过程模型、接口界面等能够满足现有业务及未来业务发展的需要，且不丢失现有工作数据的理想系统。 说明所建议系统商存在的局限性以及这些问题未能消除的原因、技术条件方面的可行性等。 4.可选择的系统方案 扼要说明曾考虑过的每一种可选择系统方案，包括需开发的和可从国内国外直接购买的，指定技术路线，建议项目的具体实施方案。 5.投资及效益分析 对所选择的方案，进行项目资金的预算，分析性能价格比，包括： （1）基本建设投资。 （2）其他一次性支出。 （3）非一次性支出。 （4）一次性收益。 （5）非一次性收益。 （6）不可定量的收益。
6.风险评估 在、立项和可行性研究阶段认证研究分析项目中可能存在的各种风险，如：政策风险、技术风险、运营风险、进度风险等，并指定相应的预防规避措施，防患于未然。 7.社会因数方面的可行性分析 说明对社会因数方面的可行性分析的结果，包括以下内容： （1）法律方面的可行性。 （2）使用报告方面的可行性。 8.时间进度合理性分析 信息系统项目时间包括从项目启动到系统上线运行、直至验收交付的全过程。 相关因素：财务经费能否满足各个阶段的使用，人力、设备等资源的合理化配置等。 9.可行性分析的结论 （1）可以立即开始进行。 （2）需要推迟到某些条件落实之后才能开始进行。 （3）需要对开发目标进行某些修改之后才能开始进行。 （4）不能进行或不必进行。
3.2.4专家评审 （1）监理机构协助建设单位根据项目特征，组织立项专家评审委员会对《可行性研究报告》进行评审。 （2）协助建设单位确定评审会议的时间、地点、设备和参加会议人员名单，协助立项专家评审委员会确定评审会议的议程、重点、原则、时间限制等。 （3）答辩 （4）立项专家评审委员会给出评审结论和意见，形成《<可行性研究报告>专家意见》，并由专家签字确认。由立项专家委员会撰写《立项评审报告》，并递交给建设单位。 （5）监理机构协助建设单位根据《<可行性研究报告>专家意见》和《立项评审报告》修订《可行性研究报告》，形成最终可行性研究报告。 阶段成果 《立项评审检查表》 《<可行性研究报告>专家意见》 《可行性研究报告》最终稿
第四章 软件工程管理体系 • 4.1软件相关的国家标准
4.2 CMMI简介 4.2.1 CMMI发展简介 • 1987，SEI推出SW-CMM框架； • 1991，SEI CMM1.0版； • 1993，SEICMM1.1版； • 1998，计划SEI CMMI(包括SW-CMM); • 2000.8.11，CMMI-SE/SW 1.0版发布； • 2001.12，CMMI-SE/SW/IPPD/SS1.1版发布； • 2002.8，CMMI-SW1.1版发布； • 2001.4，我国发布SJ/T11234和SJ/T11235; • 2006.8，CMMI for Development 1.2版发布；
4.2.3CMMI模式表示法 表示方法：阶段式和连续式
CMMI评估 CMMI评估用于评价组织过程改进的现状。由于CMMI采用了两种表示方法，与此对应就有两种不同类型的评估，一是关于具体的过程能力等级的评估；二是组织整体成熟度水平的评估。通过评估分别产生能力等级剖面图或成熟度等级。
4.3 ISO 9001简介 • 4.3.1 ISO 9001发展史 • ISO9000质量体系认证是由国家或政府认可的组织以ISO9000系列质量体系标准为依据进行的第三方认证活动，以绝对的权力和威信保证公开、公正、公平及相互间的充分信任。其系列标准发展历程如下： • ●1980年，“质量”一词被定义为企业动作及绩效中所展现的组织能力。导致一些行业标准与国家标准的产生，而由于跨国贸易的逐渐形成，跨行业、跨国度的新标准也呼之欲出。 • ●1987年，国际标准化组织（ISO）成立TC176技术委员会，联系53个国家，致力于ISO9000系列标准的发展。颁布ISO9000系列质量保证体系标准。 • ●1992年，中国等同采用ISO9000系列标准，形成GB/T19000系列标准。欧共体提出欧共体内部各国企业按照ISO9000系列标准完善质量体系，美国把此作为“进入全球质量运动会的规则”。 • ●1994年国际标准化组织ISO修改发布ISO9000-1994系列标准。世界各大企业如：德国西门子公司、日本松下公司、美国杜邦公司等纷纷通过了认证，并要求他们的分供方通过ISO9000认证。 • ●1996年，我国政府部门如：电子部、石油部、建设部等逐步将通过ISO9000认证作为政府采购的条件之一，从而推动了我国ISO9000认证事业迅速发展。 2000年国际标准化组织ISO修改发布ISO9000系列-2000系列标准，更适应新时期各行业质量管理的需求。
4.3.2 ISO 9000体系构成 1.核心标准 • ISO 9000:2000《质量管理体系结构 基础和术语》，表述质量管理体系基础知识，并规定质量管理体系术语。 • ISO 9001:2000《质量管理体系 要求》，规定质量管理体系要求，用于证实组织具有提供满足顾客要求和适用法规要求的产品的能力，目的在于增于顾客满意。 • ISO9004:2000《质量管理体系 业绩改进指南》，提供考虑质量管理体系的有效性和效率两方面的指南。该标准的目的是促进组织业绩改进和使顾客及其他相关方满意。 • ISO90011：2001《质量和环境审核指南》本标准为审核原则、审核方案管理、质量管理体系审核和环境管理体系审核实施提供了指南。本标准适用于需要实施质量和（或）环境管理体系内部和外部审核，或需要管理审核方案的所有组织。 2.其他标准 • ISO 10012:2003《测量控制系统》标准规定了测量过程和测量设备计量确认管理的通用要求，并提供了指南，用于支持和证明符合计量要求。它规定了测量管理体系的质量管理要求，可由执行测量的组织作为整个管理体系的一部分，以缺保满足计量要求。 3.技术报告 • ISO/TR 10006 项目管理指南 • ISO/TR 10007技术状态管理指南 • ISO/TR 10013质量管理体系文件指南 • ISO/TR 10014质量经济性指南 • ISO/TR 10015教育和培训指南 • ISO/TR 10017统计技术在ISO 9001中的应用
4.小册子 • 质量管理原理、选择和使用指南 • ISO9001在小型企业的应用 • GB/T19011-2003《质量和（或）环境管理体系审核指南》 • GB/T19022-2003《测量管理体系 测量过程和测量设备的要求》
4.3.5 8项质量管理原则 （1）以顾客为关注焦点。 （2）领导作用。 （3）全员参与。 （4）过程方法。 （5）管理系统方法。 （6）持续改进。 （7）基于事实的决策方法。 （8）与供方互利的关系。
4.4 CMMI与ISO 9001的比较 • 4.4.1 条款的比较 • 4.4.2 组织机构的比较 • 4.4.3 覆盖范围 • 4.4.4体系文件 • 4.4.5相同点与不同点 • 4.4.6适用性方面对比
第五章 软件工程启动阶段监理 • 5.1 启动阶段监理工作流程
5.2 项目启动阶段的主要输入和输出 • 5.3 启动阶段的主要文档及其作用 • 5.3.1 项目联络单 • 5.3.2 项目章程 • 5.3.3 项目范围说明书
5.3 启动项目的主要文档及其作用 • 5.3.1 项目联络单 项目联络单是沟通管理的一部分，为项目干系人提供各方主要联系人及联系方式。由监理机构收集信息、编制并发送给项目各方留存使用。 • 5.3.2 项目章程 项目实施的重要文件之一，主要包括如下内容： （1）项目名称及项目背景描述。 （2）项目经理任命及职责范围界定。 （3）项目业务需求描述。 （4）项目发起的原因。 （5）主要项目干系人及其初步需求。 （6）产品及预期交付成果说明。 （7）项目假设和约束条件。
5.3.3 项目范围说明书 项目范围说明书确定了项目的范围，即需要完成的各种事情。项目经理在被任命后的第一动作就是制定项目初步范围说明书。 项目章程和项目范围说明书一般视作承建单位的内部管理文档，监理工程师对这样的文档要了解，不必要求承建单位提交这些文档。 • 5.3.4 项目计划 编写项目计划是项目管理的重要工作，在项目中起到承上启下的作用。 作用： • 确定完成项目目标所需的各项任务范围，落实责任，制定各项任务的时间表，明确各项任务所需的人力、物力、财力。 • 确定项目的工作范围，遵循的标准，成为项目实施的依据和指南。 • 明确项目组成员及其工作责任范围以及相应的职权；使项目组成员明确自己的工作目标，工作方法、工作途径、工作期限要求。 • 保证项目过程中的项目组成员和项目干系人之间的交流、沟通与协助，使得项目各项工作协调一致，增加客户满意度。 • 为项目的跟踪控制提供基础。 • 项目机计划在项目中起到承上启下的作用，计划批准后应当作为项目的工作指南。 与承建单位内部计划的不同： （1）项目的成本预算属承建单位的内部管理事务，本项目计划可以不包括这些内容。 （2）作为项目活动的重要参与者，业主单位和监理机构的主要配合性工作，应该在这份项目计划中明确指出。
5.3.5 质量保证计划 软件质量保证是CMMI2级中德一个关键过程区域，他是贯穿与整个软件过程的独立审查活动，在CMMI的过程中充当重要角色。其主要工作包括以下3个方面： • 通过监控软件的开发过程来保证产品的质量。 • 保证生产的软件和软件开发过程符合相应的标准和规范。 • 保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者。 质量保证计划是项目质量保证的行动计划，用以规定软件质量保证活动的目标执行审查所参照的标准和处理的方式。一个有效的质量保证计划应包括一系列质量保证活动：缺陷追踪、单元测试、源码追踪、技术评审、集成测试和系统测试。质量保证计划的内容如下： • 质量保证计划的组织机构、人员配备、职责分配。 • 开展质量保证活动的质量标准、方法、流程和工具。 • 质量保证活动的任务分解、所需资源、时间安排。 • 质量保证活动记录的标识、收集、归档及维护流程。
5.3.6 软件配置管理计划 概念：对软件配置进行管理 软件配置的组成：程序，包括源代码和可执行代码；文档，包括开发流程文档和用户手册等使用文档；数据，包括程序内数据，配置文件，程序外数据如外部输入数据等。 软件配置管理计划是承建单位为建立和维护在项目的生命周期中软件产品的完备性、一致性和正确性，管理和控制变更而进行的内部管理活动的行动计划。一般包括以下内容： • 配置管理机构、任务和职责分配。 • 配置管理活动，及活动的流程和进度安排。 • 配置管理里程碑说明。 • 配置管理所用工具、技术和方法。
5.4 启动阶段监理工作重点 《承建合同》签订后即进入项目启动阶段。这个阶段主要工作是建立项目管理机制、制定项目计划。 • 5.4.1编写《监理规划》和《监理实施细则》 《监理规划》之于项目监理工作的作用类似《项目计划》之于项目实施的作用。在总监理工程师的支持下编写，经监理机构技术负责人书面批准，用来全面指导项目监理部全面开展项目监理工作的指导性文件。《监理实施细则》是专业监理工程师根据《监理规划》编写的针对工程中某一方面或某一专业监理工作的操作性文件。 编写基础：对工程建设内容、建设目标、涉及的专业技术的深刻理解和掌握。总监要第一时间与业主单位接触，了解工程信息、获得工程承建合同、招标文件以及与工程相关的其他资料，组织学习、充分理解工程特点和业主单位对工程建设的具体要求。
5.4.2 组织项目启动会 项目启动会是整个项目过程中重要的里程碑，标志着项目从启动阶段进入实施阶段，业主单位、承建单位、监理机构以及项目其他干系单位的合作从此拉开序幕。开项目启动会直接关系到日后项目的顺利开展。 项目启动会的发起和组织者是业主单位，监理机构应协助业主单位完成会务准备等工作。 1.项目启动会前的准备 （1）会前拜访业主单位，递交《监理规划》，了解必要的信息，商定项目启动会得参会人员、时间、地点、日程、会议议程，重点在于明确的项目管理制度和各方责任分工、工作配合要求等。 （2）最好由业主单位出面通知承建单位项目经理、联络其他干系方做好会议准备、发出会议通知。 （3）安排好监理机构出席会议的人员及分工，准备项目签到表。 （4）前期准备工作确定之后，需提请业主单位下发项目启动会通知，通知的主要内容是会议议程，议程要清楚表示，即会议时间、地点、参会人员、会议主题，以及简要说明会议的目的和要求。 （5）开始记录项目监理周报（日志）。
2.启动会议的内容 （1）业主单位宣布项目正式启动，由业主单位方介绍项目背景、内容、要求和业主单位项目组成员及其分工；并给监理单位正式授权。 （2）总监理工程师介绍监理机构成员及分工，介绍监理工作方法、范围、依据、工作流程。 （3）承建单位介绍本单位项目组成员及分工，介绍项目初始计划。向业主单位进行项目开发方法的介绍，使得业主单位能够了解项目开发的阶段、各个阶段要发布的成果以及需要配合的工作等。 （4）讨论确定项目管理制度、流程。比如项目变更流程、承建单位向业主单位和监理机构、监理机构想业主单位汇报工作的方式、途径、频率、内容等。 （5）对项目计划的里程碑点设置进行讨论并确定。 3.其他注意事项 （1）监理机构做好会议纪要。 （2）做好会前沟通及准备，控制会议时间。 （3）准备好会议签到表，会后及时整理项目联络单，及时发送各方。 （4）如何做好会议纪要：详细记录会议提出的问题、解决问题的意见及相关信息，有争议的问题，会议总结及要求等。
5.4.3 项目计划评审 1.项目计划评审要点 • 项目计划是否完整、合理、可行，各子计划之间协调一致。质量保证计划、配置管理计划、文档编制计划、用户培训计划、风险管理计划等内容是否齐备。项目计划内容可参见GB/T 8567-2006《计算机软件文档编制规范》中第7.2节描述。 • 项目范围界定是否清晰准确、重要环节是否标志出来。 • 工作分解是否合理、里程碑设置合理易于鉴别、关键路径是否标定。 • 项目进度估计是否合理、人员安排是否合理。 • 人力资源是否充足、适当，职责、分工是否明确。 • 质量保证计划和配置管理计划的安排是否保证了质量管理活动、配置管理活动安排充分、并能满足项目质量要求；是否这些管理活动有独立的、专职的人员负责。 • 进度安排、跟踪和报告方法是否正确。 • 项目交付物的验证和确认条件、方式是否确定。 • 是否清晰界定出需要业主单位及其他相关方完成或配合的任务。
2.项目计划评审方式 项目计划评审方式可分为会议评审和会签评审。 3.评审依据 • 承建合同 • 招投标文件 • GB/T 8566 -2007《信息技术 软件生存周期过程》5.2.4编制计划。 4.其他注意事项 • 由于项目本身的特性使人们在启动、计划阶段不可能预知项目以后的实施过程所有的细节，因此在此处不要过分追求完美，以免过多耗费时间和人力。另外对周期长得项目计划尽量采用远粗近细的原则，并采用滚动式的方法不断明细和调整。 • 业主单位作为项目的发起人和项目交付物的最终接收者和使用者，其在项目过程中亦有需要承担的责任和完成的工作。那些需要业主单位完成的工作。那些需要业主单位完成的工作及完成时间、交付物的形式等要在项目计划中清晰描述。 • 为使项目计划能够起到对项目各方工作的指导和约束作用，项目计划通过各方评审后，要取得各方的书面确认，并正式发布以得到相关方的认可和承诺。如果承建单位选择迭代次数至少为3~4次，并且尽量在前两次的迭代中解决软件系统的关键及不正确性问题。 • 目前比较流行的极限编程方法中有一个基本的思想，就是提倡开发人员关注眼前明晰的需求，在开发过程中依靠软件重构活动来适应需求的变动。
5.4.4 质量保证计划评审 1.评审依据 • 项目计划 • GB/T 8566 2.评审要点 • 与项目计划是否协调。 • 是否有专业人负责质量活动。 • 质量保证活动是否充分，流程是否清楚。 • 质量保证活动是否有书面记录。 • 与本项目特点的契合度与适用性，如活动的种类、频度是否具可操作性等。 • 5.4.5软件配置管理计划评审 1.评审依据 • 项目计划。 • 项目质量保证计划。 • GB/T 20158-2006《信息技术 软件生存周期过程 配置管理》 2.评审要点 • 是否与项目计划、质量保证计划协调。 • 是否满足国标GB/T 20158的要求。 • 是否清晰定义了配置管理活动和流程。 • 是否定义了配置管理里程碑。 • 是否设置了配置管理组织、明确了职责。
第六章 需求分析阶段监理 • 6.1 需求分析阶段监理工作流程
6.3 需求分析阶段文档及其作用 • 6.3.1 需求分析阶段计划 项目计划是指导项目实施的纲领性文件，它从大的脉络上表明了项目管理及实施活动的内容、时间安排、责任人和通过标准等，在项目启动阶段由承建单位项目经理制定并通过业主单位和监理机构的评审。项目开始正式实施后，在不同的项目阶段还需要对此计划进行针对本阶段特点和项目当前状况的细化和调整，以便对本阶段具体的项目活动进行指导和约束。因此在需求分析阶段监理机构首先应要求承建单位做出此阶段的详细项目计划。这个计划应包括本阶段的具体工作目标、工作内容、工作方法和手段、进度安排、责任人、里程碑及阶段输出成果的确认方法等。 • 6.3.2 调研提纲 调研提纲是承建单位项目经理根据项目范围对业主单位业务现状、交付物应具有的功能，以及系统最终用户对交付物的各种使用要求进行摸底调查时，需要了解的情况的汇总。此文档需在调研开始前提交给被调研对象，并在调研结束时收回，这样一能使调研有序高效进行；二可将调查重点锁定在该调研提纲内，否则调查工作将变得漫无边际。调研提纲可以是层次化的，随着调查的深入，调研提纲将不断地被细化。调研提纲应当可以“选择题”和“是非题”为主。调研提纲设计的完整性和针对性等有效度直接决定了调研过程和结果的有效性。
6.3.3 调研报告 调研报告由承建单位撰写，在调研结束或分阶段结束时完成。主要是承建单位对调研工作中的调研对象、调研过程、调研结果等主要内容进行记录和汇总，尤其要对调研中发现的问题进行认真梳理。调研报告需要书面提交给业主单位，必要时可以会议方式进行汇报，以促使其中的问题能够尽快得到解答或解决。调研报告的结果直接影响到软件需求规格说明的形成。 • 6.3.4 软件需求规格说明 软件规格说明是“对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明（GB/T 9835-2008）”。它一方面描述对计算机软件配置项的需求，及确保每个要求得以满足的方法；另一方面是设计与验收测试的基础（GB/T 8567-2006）。 软件需求规格说明的编写要求参见GB/T 9385-2008《计算机软件需求规格说明规范》。
6.4 需求分析阶段监理工作重点 • 6.4.1 全程参与需求调研过程 监理工程师应直接全程参与需求调研过程。监理工程师应尽最大可能参与项目调研过程，以便在后期协助和推动业主单位对软件需求规格说明的评审过程中发挥作用，并重点在应用软件功能界定、性能指标的确定，以及需求边界把握和实现路径的优化等方面上起到应有的作用。 • 6.4.2 调研计划和调研提纲确认 调研活动开始前，承建单位需要与业主单位共同讨论并确定调研计划和调研提纲，有几点值得注意： （1）强调需求调研阶段业主单位的密切配合。 （2）调研时间安排要有一定的弹性。 （3）甄选被调研的对象。 （4）尽量在调研计划讨论定制的过程中就与最终的被调研对象进行沟通，听取其意见，并最终促使调研提纲以业主单位正式的公文渠道下发。
