第一篇：案例-某公司软件过程规范示例
编者说明：
软件过程管理中的一个很重要的工作就是制定项目、组织的过程规范，它是软件开发组织行动的准则与指南。该文档就是一个实际的过程规范的实例，通过该实例，相信对大家根据自身情况制定符合要求的项目过程规范、组织过程规范有很好的借鉴作用。
1.总则
最大限度提高Q&P（质量与生产率），提高Q&P的可预见性，是每一个软件开发机构的最大目标。而Q&P依赖于三个因素：过程、人和技术，因此要实现Q&P的提高，除了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P和Q&P的可预见性。
本规范采用CMM（软件过程成熟度模型）的指导，吸收RUP、XP、MSF、PSP、TSP等过程规范指南的思想、方法及实践，充分结合xxx技术开发部的实际情况，引入先进的技术、方法、工具，为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中，主要包括管理过程和开发过程两个部分，管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。
2.项目管理过程规范
项目管理过程是对软件项目过程进行计划、监控/管理、总结的辅助过程，包括需求、配置、成本、进度、质量和风险等的管理。项目管理过程主要包括三个阶段：项目立项与计划、项目实施、项目关闭。
2.1 项目立项与计划
参与人员：技术开发部指定的项目负责人（包括前期负责人、正式的项目经理）、立项申请人、[相关最终客户]以及实施该项目的开发组队成员；
入口准则：接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》； 出口准则：立项申请人签字确认了经修订正后的正式《软件项目计划》，并通过《工作任务卡》下达了开发任务，开发工作正式开始；
输入：经审批的《软件开发立项申请表》、与需求相关的业务资料； 输出：《软件项目计划》、《软件需求规格说明书》、《开发任务卡》； 活动：
接到《软件开发立项申请表》后，技术开发部经理指定前期负责人，并告知立项申请人； 前期负责人阅读《软件开发立项申请表》后，通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流等方式，了解项目目标、范围与基本需求；并形成最初的《软件需求规格说明书》；
前期负责人会同技术开发部经理以及其它相关人员，制定最初的《软件项目计划》，并组织评审；
向立项申请人提交最初的《软件项目计划》；
最初的《软件项目计划》通过立项申请人的确认后，项目经理计划安排需求分析； 需求分析完成后，形成正式的《软件需求说明书》，提交立项申请人确认；（需求分析过程参见开发过程规范部分）
根据立项申请人确认后的《软件需求说明书》，项目经理组织进行软件高层设计，并对工作任务进行分解，并根据实际需要向技术开发部经理申请资源，组建项目组队；
项目经理根据工作任务分解，下发《工作任务卡》，并协同组队成员进行任务估算；
注：工作任务包括模块开发任务、其它任务（如安装）；模块开发任务主要包括：详细设计、编码和单元测试
任务估算完成后，组队成员向项目经理提交《个人进度安排》（以甘特图的形式表示），项目经理根据每个组队成员的《个人进度安排》修订《软件项目计划》（必须包括总的计划甘特图），并提交立项申请人确认；
立项申请人确定后，项目经理根据软件项目计划基线，补充《工作任务卡》，下发到每个组队成员，开发工作开始。
相关模板：
《软件需求规格说明书》、《软件项目计划》、《工作任务卡》
说明： 如果计划确认、需求确认未通过，立项申请人与项目经理进行协商，进行修正，无法达成共识的，提交部门经理、总经理协调； 2.2 项目实施
参与人员：项目经理，项目组成员；
入口准则：项目计划基线已建立，并通过立项申请人确定，带有工作进度要求的《工作任务卡》已下发到每个项目成员；
出口准则：立项申请人在《验收报告》上签字确认；
输入：《软件需求规格说明书》、《软件项目计划》、《工作任务卡》； 输出：经验收测试的可交付的程序、源代码及相关文档。活动：
在开发期间，项目成员每周需上交一份《时间日志》、《缺陷日志》，每天向项目经理汇报工作任务进度；
在开发期间，项目经理负责填写《项目进度周报》报于技术开发部经理、立项申请人（格式不同，交予立项申请人的只需周报的第一页，报予技术开发部经理的项目进度周报的第二页为“跟踪甘特图”）；
项目经理必须根据实际的进度情况，及时调整项目计划，若发现进度延误，需采取措施。相关模板：
《软件项目计划》、《开发任务卡》、《时间日志》、《缺陷日志》、《项目进度周报》
2.3 项目关闭
参与人员：技术开发部经理或经理助理、项目经理，项目组成员、立项申请人、[相关客户、公司总经理、公司副总经理]；
入口准则：立项申请人在《验收报告》上确认；
出口准则：形成《项目总结》，完成项目绩效考核，项目数据存入“过程数据库”； 输入：《时间日志》、《缺陷日志》、《项目开发计划》；
输出：《项目总结》、已完成的《项目绩效考核表》、过程数据库中的该项目记录； 活动：
项目经理主持召开项目总结会，交流项目实施过程中的心得体会，对项目实施中的成功处、不足处进行总结，并由项目经理形成《项目总结》；
由技术开发部经理组织对该项目进行绩效考核，并填写相应的《项目绩效考核表》； 项目经理组织所有成员对项目过程中的文档、源程序等资料进行整理、归档； 由项目经理根据过程数据库的需要，整理相应的数据，提交技术开发部经理，存入过程数据库。
相关模板：
《项目总结》、《项目绩效考核表》
3.开发过程规范
开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户的过程。是软件过程中的主体过程之一。当开发新的应用或计划为现有的应用进行重要的增强时，需使用本规范所定义的开发过程执行。
项目管理过程是对开发过程进行计划、监控/管理、总结的辅助过程，但由于项目管理是保证进度、质量的重要手段，因此在软件项目中也是十分重要的过程之一。而需求管理过程与配置管理过程则是次重要的辅助过程，需求管理过程是一个需求变更管理的过程，以对变更进行统一的管理；配置管理过程的最重要工作就是版本控制，使得开发过程中的各种交付物能够有机地形成一个个整体。
因此以上四个过程是交织进行的，均是为成功完成软件项目的保障过程。
3.1 过程总述
现在比较通行的开发过程模型包括：瀑布模型、演化模型、原型模型、螺旋模型等。根据公司的项目特点、队伍规模、组队情况等实际因素，决定选择最为简单、易于掌握的瀑布模型为基础，根据公司特点，进行合理的修改，使其成为公司本阶段的软件开发过程。
本规范将整个开发过程分为：需求分析、高层设计、详细设计、编码和单元测试、集成计划与测试、系统测试、验收测试与安装、维护等八个阶段。
3.2 需求分析阶段
需求分析的主要目的是生成一个正确说明客户所有需求的文档。换言之，软件需求规格（Software Requirement Specification，SRS）文档是该阶段的主要输出。正确的需求分析和确定需求规格对一个项目的成功是非常关键的。许多在系统和验收测试时发现的缺陷是在需求阶段产生的。在验收阶段去掉需求阶段产生的一个错误将比在需求阶段本身去掉该错误要多花100多倍的费用。很明显，在执行这阶段时，正确地生成具有最少缺陷的SRS是非常必要的。
参与人员：项目经理，[分析员]，立项申请人，[客户，最终用户]； 入口准则：项目立项，最初的项目计划已得到立项申请人的确认。
注：这里所说明的需求分析阶段是进行开发过程的需求分析阶段，在技术开发部出具初步的项目计划之前的需求沟通工作，不是该过程规范所定义的。最初的需求沟通工作可以参考本过程规范。
出口准则：立项申请人、[客户]在《软件需求规格说明书》上签字确认； 输入：《项目立项申请表》、最初的《项目计划》，需求相关的资料； 输出：经确认的《软件需求规格说明书》； 活动：整个需求分析过程主要包括以下几个步骤：
首先，项目经理与分析员一块，做好需求分析的准备，包括阅读相关的背景资料，熟悉客户的实际情况，准备用户访谈计划，准备会谈问题清单等；
然后通过面谈、专题讨论会等形式与客户进行沟通，采集需求的详细内容，澄清每一个需求点；从而界定出系统的目标和范围；
对所采集和澄清的需求进行分析，构建需求模型，从功能性、非功能性两个方面进行需求分析，深入领会客户需求；
形成《软件需求规格说明书》，建立软件需求基线，并为软件需求评审做好准备； 由项目经理安排软件需求评审，协同立项申请人、[客户]进行需求评审； 立项申请人[或客户]在《软件需求规格说明书》上确认。相关模板：
《软件需求规格说明书》
3.3 高层设计阶段
高层设计是软件开发过程中的一个重要阶段，在这个阶段将从计算机实现的逻辑角度开发针对用户需求的解决方案。这一解决方案是一个高级的抽象方案。高层设计要设计出各主要部分，并说明他们在技术上如何工作：1）相互间的协作；2）所需外在的硬件和软件环境；3）内在环境。也就是说，高层设计确定了组成产品的构件，定义了每个构件的功能任务，并且定义了构件间的接口及构件到运行环境的外部接口。
参与人员：项目经理，项目组员（设计团队）；
入口准则：《软件需求规格说明书》已通过立项申请人的确认； 出口准则：形成高层设计，实现任务分解，所有的问题得到解决； 输入：《软件需求说明书》
输出：《高层设计说明书》（功能与数据库设计）、详细设计、编码、文档和用户接口标准；
活动：
制定详细设计、编码、文档和用户接口的标准； 根据项目特点选择运行的目标平台和开发工具；
制定软件的体系结构，定义逻辑和物理的对象模型，包括确定类、类的属性、类方法、类之间的关系和对象间的动态交互。若采用结构化设计，则该活动应为功能设计；
从需求规格说明书中的数据模型中得到物理数据库结构，进行物理数据库设计：包括确定表/记录类型、域和其他部分。
生成高层设计说明书，并组织设计评审。相关模板： 《高层设计说明书》
3.4 详细设计阶段
在详细设计阶段，高层设计阶段开发出的整体应用被分成几个模块（或构件）和程序。为每个程序（或构件）进行逻辑设计，然后归档作为程序规格，同时为每个程序（或构件）生成一个单元测试计划。详细设计阶段的重要活动包括通用例程和程序的确定、框架程序的开发以及用于提高生产率的实用程序和工具的开发。
在详细设计阶段负责每个程序、模块（或构件）的内部设计，确定其程序流程，并且可以通过使用设计语言、图形流程图（如活动图、状态图）等，或通过简单地写叙述而将设计文档化。
参与人员：每个模块（或构件）的任务承担人； 入口准则：《高层设计说明书》已通过评审； 出口准则：完成详细设计，所有的问题得到解决，详细设计与单元测试计划文档化； 输入：《软件需求规格说明书》、《高层设计说明书》、详细设计标准 输出：《详细设计说明书》、《单元测试计划》 活动：
将高层设计中的每个程序（或构件）细分成小的组件；
对每个小组件进行详细设计，包括确定调用方法、输入和输出、程序逻辑、数据结构等； 根据组件的逻辑，制定单元测试计划，包括确定单元测试环境、测试用例、测试数据等； 向项目经理（或高层设计者）提交详细设计与单元测试计划； 相关模板：
《详细设计说明书》、《单元测试计划》
剪裁说明：对一些小项目，详细设计阶段的活动1、2可以省略。
3.5 编码和单元测试
在编码子阶段，根据详细设计用编程语言编写所需的程序。这个阶段根据合适的编码规范产生源代码、可执行代码以及数据库（如果使用了数据库）。这个阶段的输出是随后测试和验证的主体。而单元测试子阶段则是根据详细设计阶段所制定出来的单元测试计划进行测试，验证每一个组件正确、可用。
参与人员：每个模块（或构件）的任务承担人；
入口准则：《详细设计说明书》已通过批准，编码规范已建立； 出口准则：成功执行所有单元测试计划中的测试用例；
输入：《软件需求规格说明书》、《高层设计说明书》、《详细设计说明书》、《单元测试计划》编码、用户接口标准；
输出：测试数据、源代码、可执行代码、《单元测试报告》 活动：
根据详细设计，按照编码、用户接口规范编写程序；
对程序进行代码复查、编译、调试，直到程序运行通过，符合详细设计的要求； 根据单元测试计划进行单元测试，生成单元测试报告。相关模板： 《单元测试报告》 3.6 集成计划与测试
集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整软件结构的系统方法。可采用很多方式进行集成，集成计划必须指定模块集成的顺序。在该阶段，同时进行测试，以发现与接口相关的缺陷。集成按照集成计划中制定的顺序进行，并执行每个集成阶段的相应测试用例。集成计划描述了集成顺序、额外需要的软件、测试环境和资源需求。集成计划与集成测试计划通常一起完成。
参与人员：项目经理，集成团队； 入口准则：经批准的《高层设计说明书》；
出口准则：集成计划和集成测试计划经过评审和授权； 输入：《高层设计说明书》、源程序 输出：《集成计划》、《集成测试计划》 活动：
确定集成所需的环境，包括硬件的物理特性、通信和系统软件、使用模式等； 决定集成规程，确定将要集成的关键模块，集成的顺序，需要测试的接口等； 开发集成测试计划，确定测试用例和执行用例的规程，确定测试数据，确定期望输出等。相关模板：
《集成计划》、《集成测试计划》
剪裁说明：对一些小项目，集成计划与测试阶段可以省略。
3.7 系统测试
系统测试是依据需求规格验证软件产品有效性的活动。这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷。就像外部接口、性能、安全、配置敏感性、共存、恢复以及可靠性等属性只有在这个阶段才能判断其是否有效。可以使用具有不同测试目的的一系列测试来验证所有系统元素都已经正确地集成，系统能够执行所有功能并满足所有非功能需求。系统测试开始之前，必须在系统测试计划阶段详细地制定计划。
系统测试计划工作从需求分析结束后就可以开始，一直到编码时结束。参与人员：项目经理，系统测试团队；
入口准则：经确认的《软件需求规格说明书》和经批准的《高层设计说明书》； 出口准则：系统测试计划经过评审和授权，成功执行所有系统测试计划中的测试用例；； 输入：《软件需求规格说明书》、《高层设计说明书》 输出：《系统测试计划》、《系统测试报告》 活动：
决定所需的测试环境；
决定系统测试的规程，包括：确定测试特性，如用户接口、软硬件接口、通信接口、主要业务过程；确定不需要测试的重要特性以及不测试的原因；确定关键测试；
开发测试用例，包括确定每个测试用例以及执行它的规程，确定每个输入、输出数据的要求，确定预期的结果。
相关模板：
《系统测试计划》、《系统测试报告》
剪裁说明：对一些小项目，系统测试阶段可以省略，直接准备验收测试，在验收测试之前，开发组队按验收测试计划做一次没有立项申请人、[客户]参加的预测试。
3.8 验收测试与安装
验收测试和安装阶段的主要任务是将软件产品集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。这个阶段包括两个基本任务：使软件得以验收和客户处安装软件。验收指的是由立项申请人、[客户]根据早期准备的《验收报告》而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。当分析结果满足验收测试时，用户接受软件。安装指的是把接受的软件置于实际产品环境中。
注：《验收报告》应附有验收测试计划
参与人员：项目经理，安装团队、立项申请人、[客户]；
入口准则：成功地完成了系统测试（或成功地完成了验收预测试）； 出口准则：立项申请人或客户在《验收报告》上签署确认意见； 输入：《软件需求说明书》、测试后的软件和《验收报告》 输出：签署了确认意见的《验收报告》和安装后的软件； 活动：
根据《软件需求说明书》，编写验收报告； 与立项申请人、[客户]一起按《验收报告》执行验收测试，包括：在验收环境下安装软件、进行实况运行、协助客户进行验收测试、改正验收缺陷、更新文档以反映所有变更、获得客户的验收确认；
执行安装，包括：在产品环境下安装软件、搭建产品环境、载入软件和数据、进行实况运行、修改安装缺陷、执行用户培训。
相关模板： 《验收报告》
3.9 维护
维护支持阶段是指已安装的应用得到支持，直至其在生产环境中稳定运行的阶段。参与人员：项目经理，系统安装人员； 入口准则：软件在生产中运行；
出口准则：合同中指定的维护支持阶段终止；
输入：安装后的应用、用户文档和《软件维护申请表》；
4.需求变更管理过程规范
需求变更，这是个永恒的真理。需求变更的一个重要原因是系统周围的世界在变化，从而要求系统适应这个变化。在项目生命周期的任何时候或者项目结束之后都可以有需求变更。与其希望变更不会来临，不如希望初始的需求在某种程度上做得很好而使得没有变更需求，最好是项目准备时想到对付这些变更，以防变更真的到来。不管做多少准备和计划都不可能阻止变更，说项目在需求冻结后再开始不过是个神话罢了。
4.1 过程总述
需求变更管理过程定义了一系列活动，当有新的需求或对现有需求进行变更（我们可以称它们都是需求变更）时就会执行这些活动。需求变更可以在项目执行的任何一个点上发生。需求变更会影响项目进度，甚至会影响已经生产出来的产品。越是在生命周期后期的需求变更，对项目的影响越严重。不可控的需求变更导致对成本、进度以及项目质量的负面影响，这些极可能严重危害项目成功的概念。需求变更管理过程用来控制需求变更并减少他们对项目的影响。这个目标需要理解需求变更请求的隐含意义，以及变更带来的总影响。同样，也需要立项申请人、[客户]意识到变更对项目影响的后果，使得可以友好地将变更反映到协商好的条款中。需求变更管理过程，从某种程序上说，试图保证在需求变更影响下项目依然可以成功。
需求变更管理有两个方面，一方面与立项申请人、[客户]就怎样处理变更达成一致，一方面是实际进行变更的过程。处理变更的整体方法必须与立项申请人、[客户]达成一致。一般来说，它制定怎样进行变更请求，当需要正式的批准时，为处理变更估计留出冗余空间等等。在整个方法的背景下，当需求变更到来时，需要执行需求变更管理过程。
4.2 过程规范
参与人员：项目经理，立项申请人、[客户]、开发团队；
注：项目经理对将变更纳入项目中所需的过程执行负主要责任。立项申请人、[客户]以及开发队伍也需要参与这个过程。
入口准则：收到立项申请人提交的《需求变更请求单》
出口准则：变更已列入新的《软件需求说明书》，并体现在新的《软件项目计划中》； 输入：《需求变更请求单》
输出：根据《需求变更请求单》，在充分协商与的基础上，提交新的《软件需求说明书》，并提交《软件项目计划变更表》；
活动：
记录需求变更请求，记录项中应包括变更请求数、变更的简要描述、变更的影响、变更请求的状态和关键数据；
分析变更请求对工作的影响； 估计变更请求需要的工作量； 修改项目计划，重新估计交付时间； 对总的成本花费的影响进行估计；
将修改过的项目计划提交立项申请人，并获得确认。相关模板： 《项目计划变更表》 5.配置管理过程规范
软件项目在其执行过程会产生大量的工件，包括各种文档、程序、数据和手册。所有这些工件都是易于改变的。这是软件一个独有的特点。正如“需求变更管理”章节中所述，在软件项目中，在项目执行过程中的任何时候，需求本身都会发生变更。为避免项目在变更时失控，正确控制和管理变更是很必要的。配置管理（Configuration Management，CM）又称为软件配置管理，是项目管理中专用于关注系统地控制项目进行中发生的变更的那些部分，由用来识别机构软件产品并控制其修改的一系统活动构成。
配置管理需要满足项目基本目标之一：为客户提交高质量的软件产品。这个提交的产品，包括各种资源以及构成资源或目标代码的目标文件，还包括以这些文件来构建工作系统的脚本以及相关文档。在项目中，资源和文档通常以很多独立文件的方式来维护。
当项目进展时，文件发生了改变，产生了不同的版本。在种情况下，即使将项目的各部分组合起来，构建成系统，也是很困难的任务，怎样保证合并的是源程序的正确版本以及没有遗漏任何源程序？还有，怎样保证传送的文档的版本是正确的，该版本和最终交付的软件是一致？对于这类型的情况，必须正确跟踪软件开发过程中的各种中间产品、其版本以及软件产品的版本。没有这些信息，交付最终系统就成为繁重的任务。这个活动不是由开发过程完成的，而需要一个独立的过程，那就是配置管理过程。
5.1 配置管理的目标
配置管理过程，需要达到以下目标： 能够随时给出程序的最新版本；
能够处理并发的文档、程序的更新/修改请求； 能够根据需要撤消程序的修改；
能够有效防止未授权的程序员对文档、程序进行变更或删除； 能够有效地显示变更的情况。
5.2 配置管理过程规范
配置管理过程包括两个主要阶段：配置管理计划、实施配置管理。5.2.1 配置管理计划
参与人员：项目经理，配置管理团队； 入口准则：《软件需求规格说明书》已经确认； 出口准则：完成项目配置管理计划； 输入：《软件需求规格说明书》 输出：《配置管理计划》 活动：
识别配置项，配置项的典型例子包括需求规格、设计文档、源代码、测试计划、测试脚本、测试规程、测试数据、项目使用的编码、用户接口规范、验收报告等；
定义为配置项命名和编号的计划：如果使用CM工具，那么有时由工具处理版本编号，否则，在项目中必须明确地进行版本编号；
定义CM所需的目录结构； 定义访问控制； 定义变更控制规程；
确定CM工作人员的责任和权利； 定义跟踪配置项状态的方法； 定义备份制度 定义发布制度；
确定将配置项转移到基线的原则。相关模板：
《软件配置管理计划》
5.2.2 实施配置管理
参与人员：项目经理，配置管理团队、开发项目组队成员； 入口准则：《软件配置管理计划》已批准，项目开始； 出口准则：项目结束； 输入：《软件配置管理计划》 活动： 接受变更请求；
Check out需要变更、修改的配置项，并进行修改； Check in变更、修改过的配置项。
6.附件
附件包括各种文档模板与工作指南。所有附件以单独的文档形式存储，文档名为xxxx模板、xxxx工作指南。具体包括：
6.1 文档模板 6.1.1 项目管理类
《软件项目计划模板》、《工作任务卡模板》、《时间日志模板》、《缺陷日志模板》、《项目进度周报模板》、《项目总结模板》、《项目绩效考核表模板》、《项目计划变更表模板》、《软件配置管理计划》
6.1.2 开发过程类
《软件需求规格说明书模板》、《高层设计说明书模板》、《详细设计说明书模板》、《单元测试计划模板》、《单元测试报告模板》、《集成计划模板》、《集成测试计划模板》、《集成测试报告模板》、《系统测试计划模板》、《系统测试报告模板》、《验收测试报告模板》。
6.2 工作指南
《软件需求分析工作指南》、《软件项目计划工作指南》、《软件需求管理工作指南》、《软件配置管理工作指南》
第二篇：软件过程管理总结
第1章 软件过程规范（这章主要是概念）
1、软件过程：过程的定义P2、软件过程的分类和组成P2、软件过程定义的层次性P4
2、过程规范：过程规范的涵义P5、内容P6、影响及作用P7
3、软件生命周期的过程需求：理解ISO/IEC15504所定义的软件过程的5大需求，并进一步理解其子过程
工程过程P9 支持过程P11 管理过程P14 组织过程P16 客户-供应商过程 P17
4、软件生命周期标准：了解ISO和IEEE两大软件生命周期标准体系 P19-P22
5、软件过程建模：掌握软件过程模型的定义P23，了解软件过程模型(4种)P23-P28 软件过程P2
第2章 软件过程成熟度----重要 1．过程成熟度标准：P31-P32 掌握软件过程能力、软件过程性能、软件过程成熟度的概念，了解成熟和不成熟过程的特点 2．能力成熟度模型：重点掌握CMM，了解其起源，掌握其基本内容和结构P34。理解CMMI的目标P37 3．过程成熟度级别：理解CMM/CMMI成熟度的5个等级P38及其过程特征P42，了解CMMI过程域P43 4．软件过程框架：了解软件过程环境中的活动，掌握软件过程环境内容P49、软件组织的层次P50，掌握组织、过程和环境的关系P50，了解软件过程文化P51。掌握PSP/TSP和CMM组成的软件过程框架 P52 软件过程能力 软件过程性能 P31 CMM-软件过程能力成熟度模型(P33)CMMI(P43)软件过程能力成熟度模型集成 PSP:个体软件过程 personal software Process(p52)TSP团队软件过程(P53)简述CMM和ISO9000的概念P33以及二者之间的区别 P55
第3章 软件过程的组织管理
1．组织过程的焦点：了解组织过程焦点的基础、活动和评估P56-P59 2．组织过程定义：理解组织过程定义的概念P59、了解软件过程定义基础P60、掌握剪裁标准软件过程指南和准则P62 3．PSP过程框架和成熟度模型：
理解PSP概念P62、原则和思想P63，掌握PSP过程框架P64及其成熟度模型P66并能在实际中实施
4．TSP结构和启动过程：理解TSP概念P53、原则和思想P74，掌握TSP结构P75及其启动过程P76和工作流程P79
第4章 软件过程的需求管理---重要
1．需求管理的模型和流程：理解软件需求的三个不同层次和需求过程系统模型 P83-P84 2．需求开发：了解需求获取的过程和方法P86，掌握基于用例的需求获取和分析方法P87 3．需求管理：掌握需求管理流程，并能结合实际案例运用所学知识进行分析P93 软件项目需求管理要遵循的5条原则是什么？ P99
第5章 软件过程的技术管理
1．软件过程的技术架构：理解软件过程的技术架构定义P100、层次、内容P101，了解软件资源管理P102 2．软件过程的问题分析和决策方法：
掌握系统分析过程逻辑结构P104、了解原因分析和缺陷分析P105、决策分析与决定P106 3．软件过程的技术路线：掌握软件项目过程的技术解决流程的主要内容P109，了解其过程P110 4．知识传递：掌握知识传递的有效方法P119 Oosp(面向对象的软件开发过程)cosp（面向构件的软件开发过程）adp（敏捷开发过程）p102 P115 验证 确认 测试
第6章 软件过程的项目管理---重要
1．软件配置管理：变更控制流程P131，了解软件配置管理中经常使用的一些基本概念P126 2．掌握WBS的分解步骤、工作编码，并能进行实际分解P143-P145。
掌握软件项目估算的概念P133，理解规模P134、成本P135、进度估算，重点掌握进度估算。
网络图的形式及特点，并能结合实际项目制定开发计划。P137 3．项目风险评估：风险的概念P139、分类，了解风险识别P140、风险评估P141、风险计划、风险控制与管理过程，结合实际项目进行风险管理P139。
4．项目跟踪和监督：项目跟踪包括的内容P148，项目跟踪的基本步骤。了解项目过程的跟踪和控制。P149 SCM(软件配置管理)P125 基线P127 LOC(代码行)P134 资源管理P137 WBS(工作分解结构表P143)什么是基线？P127 基线管理的两个基本功能是什么？P127 软件项目团队中项目经理的主要职责是什么？ P138 软件项目资源管理包含哪些方面？P137-139 软件风险应对策略有哪些？P143 成本的基本估算方法（成本有直接成本和间接成本）P135-P137
第7章 软件过程的质量管理
1．质量管理概述：理解三种不同的管理方式P152，软件的质量P153。
2．软件质量方针和计划：掌握质量计划的输入因素P155，质量计划的制定步骤P155，质量计划的方法和技术P156。3．软件评审过程和方法：评审的入口条件包含的内容P158，软件评审流程的6个步骤P159。掌握常用的软件评审方法，并能在软件开发过程的不同阶段应用P161-P163。
掌握好的缺陷管理系统的特点P163，了解缺陷发展趋势图、缺陷分布图P164-P165，掌握鱼骨图分析法，并能结合项目画出完整的鱼骨图P166。了解两种比较常见的缺陷预防方法P167。
了解质量度量的主要作用P169和其所包括的主要度量的含义P170。掌握PSP中预防缺陷的三种方法。P176 如何衡量软件的质量？ P152
第8章 软件过程的集成管理 1．集成项目管理
理解软件过程的项目综合管理和软件产品的集成管理不同P177，掌握软件项目集成的主要内容P178和集成管理流程的子阶段P178以及集成管理活动中所使用的主要工具P180 2．集成项目的合成计划：合成项目涉及的管理内容P180，掌握组间协调的最佳实践P184。3．产品集成的过程管理：理解产品集成的3个阶段P185，了解产品集成的管理流程P187。4．集成产品开发模式：掌握IPD核心思想P191以及IPD的过程框架模式P192。IPD(集成产品开发模式)P190 IPMT(集成组合管理团队)PDT(产品开发团队)P192
第9章 软件过程的评估和改进 1．过程模型的剪裁：掌握3种不同类型的过程剪裁P202，掌握CMMI模型的两种表示法P203。了解过程模型剪裁的基本用途P204。
2．软件过程度量：掌握过程度量的内容P206和过程度量流程P207，了解过程度量的方法P208，掌握过程度量技术P209。3．过程评估参考模型：
了解ISO/IEC15504评估模型的内容构成、评估方法、评估等级P213-P216，掌握了解ISO/IEC 15504评估模型的3种应用模式P216。理解Bootstrap、Trillium评估模型P216-P218 4．过程评估：理解过程评估的目标P221，评估输入、输出所包括的信息P221，了解评估内容和范围P222。掌握评估类型P223、评估方式P224、评估方法P225
5．过程改进的模型和方法：重点掌握IDEAL模型P227和6 Sigma方法P231 6．组织和技术革新：了解其相关内容P234-P237 7．软件过程改进的实施
理解过程改进的原则和策略P238，了解过程改进的组织支持和改进计划P241，掌握过程改进的具体实施步骤P242。
第三篇：过程检验规范
过程检验规范
1.目的：
1.1 阻止不良产品进入下一道工序；
1.2 预防不合格品产生；
1.3 发现不合格品时，不合格品按《不合格品控制程序》和《纠正和预防措施控制程序》的有关要求进行处理；
1.4对制成管制的结果进行分析，以便导入持续改善，进而不断提升产品品质；
2.适用范围：
适用于冲压、精加工、部装、总装配的过程监视和控制。
3.职责：
3.1 品质部：
3.1.1 检验产品（包括外协），合格进仓，开具不合格品处理单，进行标识和隔离；
3.1.2 制成考核；
3.1.3 提供工样样品；
3.1.4 进行全尺寸监视；
3.1.5 评估关键尺寸的制成能力；
3.1.6 对出现的质量问题组织相关人员进行改善；
3.2 技术部：
3.2.1 编制各岗位检验作业指导书；
3.2.2协助不合格事件的原因调查与改善对策。
3.3 生产部：
3.3.1 依照标准组织生产活动；
3.3.2 对在制品进行质量监控，包括首末件检查，定期自主检查，主管不定期的检查；
3.3.3 主管制成考核
3.3.4 不合格事件的纠正和预防措施
4.检验内容
4.1首、末件检验：
4.1.1每道工序均要求首、末件检验，当设备维修后，及夹具调试维修后均要求首检；
4.1.2操作工在加工产品前首先确定机械设备的加工能力、设备的状况、条件设定、模具制定状况，适合产品型号、规格的要求，对照图纸的尺寸要求及样件，对开始加工的第一件产品
必须进行首检，反复检验，做到认真、仔细、负责。符合质量要求后，经检验员确认后方可继续生产。并填写好制成检验记录，其目的是及早发现质量问题。
4.1.3每天下班前操作工应检查最后一个工件，并将结果记录在制成检查记录单。
4.1.4每个生产批的最后一件产品检查后，连同模具一起保存，以便下次模具重新使用时与生产首件进行对比，比对完成后，新的末件取代该末件，该末件做适当处理。
4.2自主检查/巡回检查/全尺寸检查
4.2.1在生产过程中，操作工对自己加工的每一件产品的尺寸，按图纸标出的尺寸项目进行测量，检验员按一定的时间间隔对产品的各道工序进行抽检，检验结果要记录在巡检记录上。
4.3抽样检验：
4.3.1每一道工序（含外协）的产品加工完毕后，检验员按抽样计划对本道工序完工产品进行抽样检查；
4.3.2 检验合格后方可转入下道工序，并做好标识。各工序加工完毕，经检验员检验合格后，填写好“产品制造流程卡”，转入下一道工序；
4.3.3 对不合格品，检验员开具不合格处理单，进行隔离、标识，并通知生产部、品质部、技术部等相关单位落实三现主义，对于外协厂，必要时必须组织相关人员进驻外协厂。
4.3.4 不得将未完成过程抽样检验的产品转入下一道工序，如生产急需来不及检验，而转入下一道工序，须经顾客代表批准后，进行标识，做好记录，并留下部分产品继续检验，方可放行。
4.4 制成考核：
4.4.1品质部依照相关作业标准制作过程考核检查表，交由检验员实施过程考核
4.5 过程能力评估：
检验员应每周至少一次依照顾客的要求和产品的重要程度选择关键尺寸，依机台类别进行制成能力评估，将评估结果记录在制成能力诊断表上。
4.6 不合格品处理：
4.6.1 操作工在上产过程中所生产出的不合格品要放在不合格箱内（红色）里面。
4.6.2 操作工在自主检查中如发现两个都合格，就继续生产；两个都不合格就停止生产；一个合格，一个不合格就再抽两个，第二次只要发现一个不合格，就停止生产。
4.6.3 只要发现任何不合格品，对已经生产的产品都要进行全部检查，检查需追溯到上次检查都合格的时间。
4.6.4 根据不合格程度，对不合格品做出返工、挑选、报废、重检等处理，参照《不合格品控制程序》
4.7 产品制造过程中出现的质量问题，品质部主管立即组织生产部、技术部、车间主任等相关人员实施三现，参照“纠正和预防措施控制程序”。
5.参考文件：
5.1《不合格品控制程序》
5.2《纠正和预防措施控制程序》
6.使用表单：
6.1不合格品处理单
6.2首/末件检验记录
6.3 巡回检验记录
6.4产品制成流程卡
6.5过程考核检查表
过程检验管理程序
1.目的：
验证工序加工的产品（半成品、零件）是否满足规定的要求。
2.范围：
适用于整流桥事业部内部工序加工的半成品、零件（包括冲压件、机加工等）的检验。
3.术语：
3.1首件：指操作者每班（或生产过程中更换品种，或调整设备、工夹具、刀具等）以正常工艺状况加工几个产品（一般为3～5件），当自检确认状态一致时，可将其中一件作为首件产品。
3.2单工序完工产品：指一个零部件，只需完成某一道工序的产品。
3.3末件：上一批生产的最后一件产品。
4.职责：
4.1品质部负责对工序加工的产品进行检验和试验（包括首检、巡检、完工检）。
4.2生产工人对自己加工的产品负责进行“三自一控”[ 三自：自检（首检、中间检、完工检）、自分合格品与不合格品、自作标记或隔开，一控：保证一次交检合格率 ]。
5.控制程序
5.1过程接收准则规定：凡属于计数值的抽样方案，其接收标准为（0，1）方案；如有其它状况（如：外观封样等）的接收准则，必须以文件形式规定，外观封样接收准则参照外观封样程序。
5.2首件检验：
5.2.1 操作者应对首件产品进行自检，首件自检合格后送检验员确认，检验员应做好首检记录。首件检验员检验合格后方可正常生产，若首件检验员检验不合格，操作者必须重新调整加工参数后再进行自检、检验员检验，直至检验合格。对更换品种，或调整设备、工夹具、刀具等后的首件，自检合格后还应送检验员确认。
5.2.2操作者首件经检验员检验合格后，将首件放置在指定的地点，一般情况，首件随该班次流入下道工序。
5.2.3检验员监督操作者做好自检工作，对更换品种，或调整设备、工夹具、刀具等后的首件检验后，也应做首检记录。异常时，立即停止生产并上报；
5.2.4 对装配流水线作业工序，有产品作业验证要求时，检验员应在同一批次产品装配的初始和结束做好产品作业验证，并在“产品作业验证”表上作记录，初始验证后才能装配。如果作业条件（如：工艺装配、方法、零件批次、操作人员等）调整或改变应重新应重新作出验
证。
5.3过程检验：
5.3.1操作者在生产过程中必须进行定期自检。自检频率若工艺文件中有规定，则按工艺文件要求自检，无要求的根据产品质量状况由操作者自己把握，但每天不得少于4次（记录可以不做），若自检中发现不合格或异常时，立即停工，相关人员分析原因，排除故障后复工。对已加工的产品追溯检查，并报相关人员处理。
5.3.2 检验员在产品加工过程中应进行巡检，除对实物进行检验外，还应对过程（工艺）参数进行检查，并做好巡检记录。巡检的频次一般为每班不少于两次。
5.3.3 检验员在巡检中发现加工产品不合格，应通知操作者停止加工，协助操作者查找原因，排除异常后恢复加工。造成批量不合格或异常不能及时排除，操作者或检验员应向相关人员报告。同时，隔离产品，并复查，做好记录。
5.4完工检验
5.4.1操作者本道工序加工完后，应对自己加工的产品进行自检。自检合格后，在“流转卡”上填写相应的内容后，“流转卡”连同产品一起送到指定地点（待检区），交检验员检验。“流转卡”填写不完整，检验员有权拒检。
5.4.2对操作者送检的单工序完工产品，检验员按“检验作业指导书”相关内容进行检验，合格后在“流转卡”检验栏签字（或盖章），作为合格产品流入下道工序的依据；若送检产品为零（部）件完工产品（最后一道工序产品），检验员按“检验作业指导书”对该产品所有规定内容进行检验，并做好记录，产品经检验合格后，检验员应在“流程卡”上签字（或盖章），同时出具“检验单”作为入库的依据；
5.4.3 对于模具加工产品（如冲压等）应记录末件关键尺寸，便于与下批产品首件对比，本批的末件随同模具一并保存及管理。
5.5 对检验中发现的不合格品按《不合格品控制程序》执行。
5.6 针对特殊特性（顾客指定或事业部技术部确定）必须采取SPC、防差错系统或目视管理等方式来预防不合格的发生。
5.7 组织必须保持顾客生产件程序的制造过程能力或绩效，确保有效实施控制计划和过程流程图，记录重要的过程活动，如更换工具或修理机器等。当控制计划不稳定时启动反应计划，适当时反应计划必须包括遏制产品和100%检验。为确保过程变得稳定和有能力，组织制定完成进度和责任要求纠正和预防措施计划，顾客有此要求时，此计划将由顾客评审和批准，并保持过程更改生效日期的记录。
5.8 工序检验依据：
5.8.1 工序检验依据为“检验作业指导书”，对未进入批量生产的产品，按图纸、控制计划等技术文件检验。
5.8.2 工序“检验作业指导书”由技术负责人组织主管技术人员编制，质量部门相关人员会签，技术负责人审批。
5.9 委托试验或检测
5.9.1 事业部不具备条件的检验/试验项目，由事业部检验员填写“委托试验书”，经主管领导审批后送计量测试中心检验/试验。
5.9.2 计量测试中心接到“委托试验书”后，应按要求的期限完成试验和检测任务。如无法按委托期限完成，或无法承担的试验和检测的项目，需委托外单位进行的，由计量测试中心用书面工作联络单与委托单位联系、协调。
5.9.3 需委托外单位进行试验和检测的项目，由计量测试中心统一安排，填写“委托试验审批书”，按《实验室管理程序》的规定执行。
5.10 例外转序
5.10.1 对于已送检或试验（包括委托外单位）结果没出来而生产又急需的，按《紧急放行/例外转序程序》执行。
5.11 统计分析报告
检验员应对当日发生的不合格品、不合格品率等质量状况进行分析汇总，作成《质量日报表》报主管领导，必要时提供给有关人员，对异常问题由车间主任组织技术人员、检验员、操作者召开质量分析会，落实质量改进措施。
6.
第四篇：软件售后服务规范
软件售后服务规范
软件售后服务规范
一、适用范围
一、服务要求
原则：礼貌、热情、周到、细致、耐心
1、服务前充分了解用户的服务需求，并作出合理承诺；
2、服务时要切实解决用户遇到的问题，使用户能够继续无忧地使用；
3、服务后要适时检验是否真的完全解决了用户的问题；
4、任何时候不能说“不行”、“不知道”、“不清楚”；
5、任何服务人员都不得指责用户的使用方法，要委婉指出；
6、要站在客户的立场考虑问题，在服务政策允许的范围内为用户提供最大的方便；
7、在接听电话时态度要亲切、语言要温和；
8、回答用户问题时要专业、自信；
9、严禁使用不文明的用语；
10、严禁相互推托责任。
二、培训服务规范：
1、按售后服务协议中的服务承诺提供服务；
2、培训管理员在培训前，编制培训计划，做好培训环境的准备工作，准备好培训资料
和考试资料，培训期间保证培训设施的正常运行和培训的后勤保障工作，组织好培训考核，培训后做好培训工作总结；
3、培训教员根据培训计划做好培训教案和培训讲义，以保证培训的教学质量，确保用
户对培训内容的掌握程度达到85％以上，并能正确使用《YYY系统》；
4、在用户培训过程中，服务监督员要进行培训质量监督，培训工作结束后要做好培训
质量调查。
三、热线服务规范
（一）热线服务要求
1、按用户数2‰的比率设置热线服务值班岗位及电话，并将服务热线电话告知用户；
2、服务期间必须保证电话畅通，热线值班人员要做好热线值班记录（记录包括用户单
位名称、地址、电话、联系人姓名、用户反映问题的具体内容及处理情况），服务
期间不得擅自离开工作岗位；
3、热线值班人员回答用户问题时必须热情、耐心和有礼貌，不得说任何与解答问题无
关的话；
4、无法用电话解决的问题，应在接到用户电话24小时内安排服务人员上门解决；
5、服务满意度应大于85％。
（二）行为规范
1、值班经理必须提前半天安排好热线值班工作。
2、热线值班工程师必须按公司规定的上班时间准时到岗就坐，10分钟内做好值班准
备（记录单、电话、笔、环境整理）。
3、工作时间不得随意走动，未经许可不得擅自离岗。
4、电话铃响三声内必须接听。
5、完成电话咨询必须立即挂好电话，保持电话畅通。
6、每个来电必须记录。
（三）答询规范
1、接听电话第一句话“您好，XX公司，我是x x号值班员。请您留下您的联系电话
以便以后联系，记录好单位名称、地址、电话、联系人之后，“请问您有什么问题？”
2、用户叙述问题时不得打断用户叙述，未听明白时，“对不起，我没听清楚，请您再
说一遍好吗？”。
3、用户问题必须耐心、热情，不得说任何与解答问题无关的话。
4、电话中无法解决时，“对不起，您的问题电话中无法解决，我们三天内派人上门解
决可以吗？”。
5、用户同意，询问用户“这三天内您都在单位吗？”，填“现场服务请求单”。
6、用户不同意，并提出具体要求，“您的要求我记下了，我请值班经理为您安排，值
班经理安排好后，会电话通知您。”
7、用户要求当日上门和次日上门的请求，必须马上交值班经理，值班经理必须在一
个小时之内回电话。
四、上门服务规范
（一）服务要求
1、按售后服务协议中的上门服务承诺提供服务；
2、服务工程师上门服务必须挂牌；
3、服务满意度应大于85％。
(二)服务规范
1、确认：接到派发的服务单后，确认服务单上记录的问题自己能否解决，用户的地址
自己是否知晓。如不能确认，须向热线值班工程师请教或查清用户地址后方
可上门。
2、挂牌：到达用户场所，在见到联系人之前，将公司的服务标识牌挂在胸前。
3、敲门：找到用户办公室后，轻轻叩门三声，等主人允许后进门，并礼貌地询问：“对
不起，打扰了，我是XX服务工程师，请问XXX先生（女士、小姐）在吗？”
4、介绍：见到用户联系人后，证实联系人身份，介绍自己：“请问，您是XXX先生
（女士，小姐）吗？（朝前拿起服务标识牌说）我是XX服务工程师，我姓
X叫XX，很高兴能为贵单位服务。”如是多次服务的熟人，可免去自我介绍
过程、直接说：“很高兴能再次为您服务。”
5、问题：向联系人询问，核实服务单上记录的问题和故障，以及使用过程中遇到的其
它问题和疑惑，并请用户开机演示问题和故障。
6、解决：首先做好用户文档和数据备份，然后查找原因、解决问题，排除故障，解答
疑惑。如遇自己无法解决难题时，一面向用户歉意地解释问题复杂，解决需
要花费一定时间，取得用户谅解，一面即刻向热线值班经理请求支持，尽快
拟定方案，予以解决。
7、试运：请用户操作试运行软件系统，当面检验解决结果。
8、讲解：向用户详细讲解问题和故障产生的原因，排除和解决的方法，以及今后使用
中应注意的事项。
9、签字：请用户在服务单上签字认可本次服务，并对服务质量进行评价。
10、辞别：向用户告辞。规范用语为：“今后有问题，请随时打服务热线电话联系，再见。”
五、技术支持规范
1、必须以书面的方式（可传真）向XXX公司提出请求支持，服务请求要盖有服务商公
司公章和服务代表签字。
2、提出申请后必须向XXX公司确认是否收到技术支持请求（以免这些资料在传递过程
中丢失导致问题无法得到及时的解决）。
3、获得了问题的解决方案后，服务人员应立即告知用户，必要时再次上门对用户进行现
场服务，直至问题完全解决。
4、各地服务商的热线值班人员和现场服务工程师要定期整理《YYY系统》常见问题及解
决方案建议并以书面方式反馈给XXX公司实施服务中心，以便核查和向用户公布。
第五篇：咨询案例过程
咨询过程
（注：我们组只有两个人，扮演咨询师的同时也扮演者记录员）
咨询师：你今天想咨询什么问题？（探问技术，开放式问题）来访者：这个学期在学校觉得很累。
咨询师：再具体说说，让我更清楚你的问题。（具体化技术）来访者：这个学期课堂压力大，课后作业压力也大，大三了，朋友聚 会也多了起来。不知道该怎么办？
咨询师：你刚刚提到你有课堂压力的问题，有作业压力的问题，好像又有和朋友聚会的压力，是这样的吗？(探问技术)来访者：是啊，朋友聚会特别多的。
咨询师：能多说说你和朋友聚会的事？（具体化技术）
来访者：每周都有朋友聚会，和朋友在一起的期间感觉很棒。但每次去参加又都不能不喝很多的酒，而且都聚得很晚才散，回来后又很难受睡不着，早上又起来上课，基本上休息很少。
咨询师：听起来你和朋友相聚在一起，你觉得很开心。你的问题似乎不是在朋友矛盾之间，而是在你参加聚会喝酒多，回来晚有关，是这样的吗？（初层次通情达理技术，探问技术）
来访者：应该是跟喝酒有关。其实我是很喜欢和朋友相聚的，只是我不喜欢喝酒。咨询师：我还是不明白你的问题，跟朋友相聚和喝酒有什么关系？（具体化技术）来访者：当然有关系，朋友相聚就得喝很多的酒。
咨询师：什么原因让你和朋友相聚时要喝很多的酒？（具体化技术）来访者：大家都觉得喝很多的酒才够哥们，而我又不能喝太多的酒。
咨询师：我这样了解你的问题对不对？你的问题是因为你喝不了酒，朋友聚会有多，又不好意思不硬着头皮喝酒。所以回来后身体不舒服睡不着。你想知道有什么办法增加酒量或不用喝酒，以至于回来后好好休息，我这样了解你看对不对？（探问技术，封闭式问题）
来访者：对极了，比如说，我喜欢跟以前的高中同学一起坐坐，聊聊天这类的，可是我讨厌坐在一起聊天就得喝酒，尤其是很多的人聚在一起时，我看大家都不想喝酒，但是还是拼命的喝，还说什么“不喝不够朋友，不够哥们”。还有，宿舍的舍友每次一起出去吃东西都非得喝不可，这样我觉得很无奈。
咨询师：只要喝酒你就觉得烦，觉得无奈。其实我也觉得朋友相聚喝酒很无奈。
（共情技术）
来访者：对！就是这样。喝完回来后就吐得一塌糊涂，吃下去的都吐出来完了。咨询师：我把我们刚刚谈的内容，做个整理，看看我对你的了解是否正确。你的问题似乎跟喝酒有关，而且喝酒给你带来难受，睡不着。但你又喜欢跟朋友相聚，朋友相聚你就得喝很多的酒（概述技术）
来访者：是的。所以我为了和朋友相聚，就得逼自己喝很多的酒
咨询师：每次和朋友相聚喝酒让你觉得很难受，然后当晚就睡不着。（情感反应技术）
来访者：对。那要怎么办？
咨询师：这个问题似乎让你好苦恼。（情感反应技术）来访者：是。我不知道该怎么办。
咨询师：你是说，如果能不喝酒或喝少量的就没事了，是这样吗？（探问技术）来访者：对！如果和朋友相聚不喝酒或喝多少都随意，我会觉得很开心，因为我根本不能喝太多的酒。
咨询师：你根本不能喝酒。（重复性技术）来访者：对啊！要喝酒很难受。
咨询师：朋友相聚开心是最重要的，所以大家都觉得喝酒就能开心。我和我的朋友相聚也都要喝酒，我也不能喝酒，觉得喝酒给自己带来很难受。（共情技术）来访者：（沉默）
咨询师：刚刚我看见你沉默了一会，在你沉默间，你一定是在思想什么问题？（沉默技术）
来访者：我在想，为什么朋友相聚一定就非要喝酒呢？
咨询师：你能想想，有哪次和朋友相聚不用喝酒的？（探问技术）来访者：（沉默）
咨询师：我看你沉默了一会，想到有哪次相聚不用喝酒的了？（沉默技术）来访者：有好几次呢
咨询师：想到那几次和你相聚的都是你的那些朋友呢？（具体化技术）来访者：我记得都是我最好的朋友，很了解我的朋友。
咨询师：那在说说你经常聚在一起而且非喝酒不可的那些朋友吗？（具体化技术，探问技术）
来访者：应该都是一些在大学认识的，而且不经常在一起的人，有的也是认识不
久的人，也有的通过朋友间接认识的人，反正有很多。
咨询师：一提到这些朋友，我看见你的表情有一种浮躁，是不是他们这些人都不太了解你呢（情感反应技术，探问技术）来访者：对
咨询师：看来，我们下一次谈的主题是朋友相互了解方面的······ 自己的感想
我们组只有两个人，也就是说没有记录员。我们以作为咨询师的人自己记录，所以，我只能以咨询师感受来谈谈我在着整个过程中的感受。
我们第一次进行的时候还很难说的下去，但是我们经过第一次的经历后，第二次就觉得很好了，以上就是我们进行谈话的整个过程，谈话期间有时很慢，但是效果很是很好的。我的感受是，作为咨询师在讲每句话时都要考虑到来访者的感受，不能给来访者压力，不能讲来访者犯错误之类的话，要给来访者一种安全的，自由的环境。要深刻的了解来访者的情况，不能急着给来访者下定义或解决方案，总是要用话来套着来访者转进自己的咨询方案里面去。而且在来访者对视是不能表露出任何的不敬之表情。
点击咨询 