软件生命周期模型描述及团队工作指南.doc

软件生命周期模型描述及团队工作指南软件生命周期模型描述及团队工作指南文件状态： 草稿 正式发布 正在修改文件名称：当前版本：完成日期：拟制：审核：批准：版本历史文档修订记录版本号文档状态简要说明（变更内容和变更范围）日期变更人*文档状态：R发布，D修改文档状态对应的版本号规则：发布的版本号只有x.y,处于修改状态的号则为x.y.z的方式。如：V1.0 发布 V1.0.1 修改- 37 -目 录1总则41.1 目的和意义41.2 适用范围41.3 名词解释41.4 本文档使用方法52团队工作指南62.1项目团队组成与管理62.2项目团队角色与职责73生命周期模型的选择114瀑布模型134.1模型综述134.2模型示意图164.3里程碑点及基线设置164.4各阶段描述174.4.1 立项与启动阶段174.4.2需求与计划阶段214.4.3设计阶段264.4.4实现阶段284.4.5系统测试阶段294.4.6试生产阶段324.4.7项目验收阶段354.4.8运行与维护阶段385迭代模型405.1模型综述405.2模型示意图415.3里程碑点及基线设置415.4各阶段描述416推广模型426.1模型综述426.2模型示意图436.3里程碑点及基线设置436.4各阶段描述446.4.1立项与启动阶段446.4.2部署与初验阶段506.4.3系统演化阶段516.4.4试生产和终验阶段557模型的裁剪571 总则1.1 目的和意义为规范成都三泰电子实业股份有限公司软件开发类项目的管理与实施，形成一套行之有效的、规范化的工作方法，提高工作效率，明确项目组成员的职责，保证项目的质量，满足顾客要求，确保项目目标保质保量实现，促使公司获得良好的综合效益，根据本公司的质量目标、质量方针及质量程序文件的要求，特制定本文档。1.2 适用范围本文档适用于成都三泰电子实业股份有限公司研发中心承担的各类软件开发类项目及综合类项目中软件开发子项目（包括开发类、升级类）的项目管理与实施。开发类项目是指公司承接的、由顾客提出的；由公司自主立项的、有明确需求的项目。该类项目一般有比较完整的软件生命周期。公司主要的开发类项目新产品开发和软件收费项目两种。升级类项目是指公司对已经交付顾客使用的系统所进行的升级、改造项目，项目的主要内容可能包括前期系统的缺陷修复、功能增强、新功能开发等等。1.3 名词解释1. 顾客：本文中顾客或顾客单位有两种，即公司的客户和公司领导层。当项目为公司内部新产品开发的项目时，项目中没有产生实际销售与合同，这时候的顾客是指公司领导层或市场代表人员；当项目为软件收费项目时，项目会产生特定的服务对象，产生合同双方，这时候的顾客是指公司客户。2. CM：配置管理人员3. PPQA：质量保证人员4. 同行评审：即由工作产品创建者的同行们检查该工作产品，识别产品的缺陷，改进产品的不足。5. 基线：在配置项的生存周期内的某一特定时刻已正式指定和固定的且经正式批准的配置项的一个版本。6. 系统测试：也称为用户接受测试，即系统上线试运行前项目组与顾客对系统的功能进行完备性、可用性、正确性的测试。7. 生命周期模型：一个包含过程、活动和任务的框架，这些过程、活动和任务涉及软件产品的开发、运行与维护，跨越从需求定义到终止使用的系统生存周期。8. EPG组：Engineering Process Group。本公司负责建立、维护和日常管理组织过程资产库、推进软件过程改进的工程过程小组。由公司公司牵头。9. 组织过程资产库：本公司关于项目管理与实施的所有方针、手册、文档、规程、文档模版与表格、历史项目信息的集合。10. 里程碑评审：在选定的里程碑点处，评审项目的成就和结果。11. 项目（需求）变更：项目内容的变更或待开发系统需求变更。有下列三种情况需要区别对待： 变更涉及到顾客、不引发软件系统变化的：由变更提出方填写项目（需 求）变更表；项目经理及相关人员评估项目变更影响、决定是否执行变更；执行变更并与顾客共同验证。 变更涉及到顾客并引发软件系统变化的：执行需求开发与管理规程中8.2.3需求变更控制流程。 变更不涉及到顾客：按照变更控制规程进行。1.4 本文档使用方法项目经理在接手一个软件开发项目后，应遵循以下步骤完成项目的组织管理与实施。1、根据项目招投标文件、市场反馈信息或合同书中对项目（含产品）的描述和与顾客（含公司内部顾客）进行初步接触所掌握的信息，确定项目范围和要求，与上层主管协商可投入本项目的资源（人、财、物）。2、根据项目特点和资源状况，选择适用的软件生命周期模型（瀑布模型、迭代模型、推广模型），依据本文档第四、五、六章给出的各软件开发过程项目活动的描述和裁剪指南，定义项目各阶段活动及产生的文档，形成项目已定义过程，并得到本部门QA人员批准。如果项目对产品和过程的裁剪超出组织定义的范围，在使用之前需得到公司EPG组的批准。如果本文档中所提供的几种模型不适合项目的特点，项目经理可以另行建立适用的生命周期模型，但是需得到公司EPG组的批准。3、按照项目计划与监控规程、项目估计规程的有关要求，进行项目估算与规划，确定项目计划。4、根据上环节确定的项目计划，按照项目计划与监控规程、需求开发与管理规程、系统设计与实现规程、软件测试规程等相关要求，组织和控制项目实施。软件开发项目活动分三大类：项目管理活动、工程活动和项目支持活动。本文档主要列出各阶段项目管理和工程类活动。项目支持类活动不做重点描述，可以参见配置管理手册、质量保证手册、度量与分析手册。此外项目风险管理和项目货物采购活动参见风险管理手册和采购与外包管理手册。2 团队工作指南2.1项目团队组成与管理项目成立时，因为项目的性质与目标不同，项目组成员的组成与数量可能不一样。通常一个项目至少需要包括项目经理、系统架构、软件开发、用户体验设计、配置管理工和测试方面的人员。如果项目需要做硬件开发，则需要加入硬件开发和结构设计人员；如果项目为新产品，则需要加入产品应用和产品标准化人员；如果为现场实施项目，则需要加入项目实施工程师、系统培训和项目服务人员。公司研发中心采用的是职能式组织架构，按照产品和职能进行划分，硬件开发、工业设计、测试部门独立于产品线和软件开发人员，平时的管理与考核工作以职能部门为汇报线进行管理。公司项目立项时，项目组成员采用矩阵式管理结构，项目中的人员分别来自不同的部门，有着不同技能、承担不同的责任，共同为了项目的目标完成项目相关的工作。一个员工可能同时参与多个项目，这样对员工的管理就存在多个主管同时安排工作的情况。为了降低多方管理带来的矛盾，确定基本的管理思路如下：1、 员工的日常管理、月度考核、季度考核和组织级的相关管理以直线职能部门主管为准，考核权在直线职能部门主管。2、 项目经理有权对项目组成员进行项目考核，有权决定是否需要该成员以及有权决定该成员的项目奖金数量。3、 项目经理有权将员工在项目参与过程中表现情况想该员工的直线职能部门主管反应，作为日常考核的参考。2.2项目团队角色与职责角色职责技术总监 负责项目立项计划和结项管理审批 负责项目变更申请的审批研发中心经理 参与项目重要需求评审、设计评审、测试评审和产品发布评审 监督项目经理的工作，审批项目经理的各种申请 组织协调跨部门或与外部客户之间的工作交流与问题处理项目经理 组织制定项目的总体计划和阶段计划； 协调项目组资源和内部工作关系，安排项目组成员工作； 跟踪、检查项目组成员工作质量； 为保障项目正常运作，与客户、项目组成员之间进行必要的沟通； 负责控制项目，保证项目在预算成本范围内按规定的质量和进度达到项目目标。系统架构师 深入分析和归纳用户需求，总结翻译出系统需求； 负责将系统需求整理成软件需求规格说明书； 负责解决软件需求规格说明书被评审后发现的问题； 深度剖析系统需求，抽象出应用系统架构模型，确定应用系统实现模式； 利用当前先进、成熟的计算机应用技术，负责设计和实现稳健、实用、灵活、高效的应用系统（技术）架构； 指导项目组相关人员了解并灵活使用（技术）架构； 协助测试人员进行系统架构测试。开发经理 负责制定从需求分析开始到系统测试前的开发计划； 在开发计划的约束下，协调项目组相关资源，完成系统分析、架构设计、系统设计、模块设计、代码实现、单元测试和集成测试工作； 在项目开发阶段，跟踪、检查项目组成员的工作质量； 负责重点代码检查和单元测试； 负责组织相关人员执行集成测试并提交集成测试报告；需求调研员 根据需求调研计划进行需求调研； 收集整理客户需求，负责编写用户需求说明书； 负责解决用户需求说明书被评审后发现的问题； 就用户需求说明书的内容与项目组、用户达成一致并得到用户的确认。测试经理 独立编写测试计划； 独立编写测试用例； 安排和指导测试工程师/测试员的工作； 协调测试团队内部的工作以及与开发团队之间的工作。测试工程师 在测试经理的安排和指导下，编写测试计划； 在测试经理的安排和指导下，编写测试用例； 在测试经理的安排下，独立完成“执行测试”的工作； 在测试经理的指导下，掌握较深层次的测试方法、测试技术和较复杂的业务流程。开发工程师 在系统设计师的指导下，负责进行模块设计（包括功能界面布局设计和人机交互界面设计）和编写设计文档； 根据系统模块设计进行代码实现； 编写单元测试用例和单元测试脚本； 负责执行代码走读和单元测试，记录单元测试结果； 负责完成应用系统的集成测试并编写集成测试报告；配置管理工程师 负责部门项目配置管理库的管理并承担大型项目的配置管理活动； 对配置管理流程进行监督、跟踪，并提供优化改进建议。 据软件项目计划制定配置管理计划； 在配置管理计划约束下，负责配置项、基线的生成、变更和相关管理； 开发和维护项目管理标准、方法和程序； 审核项目组提交的各种文档，并对使用说明书进行测试； 组织项目阶段性评审； 保存项目过程中的相关文件和数据； 项目版本的标准化及发布； 标准化项目过程中产生的各种文档，并在结项后进行归档，形成研发中心的积累；硬件开发工程师 协助编写需求分析说明书，并根据需求分析说明书编写硬件相关的概要设计方案、详细设计方案； 完成项目中的硬件设计开发工作，提供PCB 板图、电路原理图、线缆图； 不择负责编写产品物料清单BOM和产品关键元器件清单： 解决bugfree指派给自己的BUG，详细说明出现原因及解决办法。 提供硬件相关的检验规程； 提供硬件成果明细清单。结构设计工程师 根据需求分析说明书编写结构相关的设计方案； 提供生产用结构文件； 跟踪样机生产过程、样机装调； 提供整机连线图、装配图； 提供与结构相关的检验规程； 提供与结构相关成果的明细清单。 解决bugfree指派给自己的BUG，详细说明出现原因及解决办法。MA工程师 参与制定和维护MA计划 加工度量数据 选择表示形式 协助项目经理进行综合度量分析 编制度量与分析报告PPQA工程师 负责被分派项目的质量审计； 负责被分派的过程改进工作； 负责过程工具的研究、推广与维护。 负责被分派项目的质量审计； 负责过程工具的研究、推广与维护，负责过程数据库维护工作。 在评价过程或评价工作产品（和服务）中发现的不符合项，PPQA工程师必须跟踪其处理情况，直至解决。对于项目组不能解决的不符合项上报到高层经理。 详细记录过程和产品质量保证活动，分析不符合项的质量趋势，以便了解活动状态和结果。 根据需要参与项目组例会、阶段评审、关键技术讨论会、项目组内部评审等重要活动。 发现过程体系可能有缺陷时，向EPG经理汇报。用户体验设计工程师 通过分析项目产品的用户需求、产品需求，设计项目的用户体验方案 组织对用户体验方案的评审 负责完成用户体验方案中的界面图片设计，配合开发工程师提供需要的图片和设计。产品应用工程师 负责项目产品应用方案的编写； 负责项目产品应用方案的讲解； 负责根据用户的要求撰写技术（方案）建议书。 策划并独立完成目标客户的拜访和沟通； 定期分析、整理客户需求，制定有针对性的方案； 负责竞争对手产品分析，提出产品与市场相比的优劣性 负责产品对外宣传与推广，开拓市场，提高产品品牌知名度和认可度；产品标准化工程师 按项目要求对生产发文进行整理、发文； 跟踪小批量生产全过程； 提供生产所需的技术支持； 归档生产发文资料； 提供整机BOM单； 按项目要求准备型检、3C或企业标准的相关资料、设备； 跟踪型检、3C及企业标准的全过程；实施工程师 负责制定项目实施计划； 在项目实施计划的约束下，协调项目组相关资源，完成系统实施相关工作（包括 系统安装、用户培训、系统上线、系统试运行等）； 在项目实施阶段，跟踪、检查实施人员的工作质量； 负责编写用户手册、操作手册和相关培训教材； 负责协助用户进行“用户确认测试”和编写确认测试报告。培训工程师 根据公司发展战略，总结出可能有的培训需求 定期或不定期从项目组获取培训需求，制定培训计划并实施 维护培训资料库服务工程师 负责项目软件在客户现场的安装、配置和运行 负责跟踪软件运行情况，并反馈运行结果记录 负责反馈软件运行过程中出现的问题3 生命周期模型的选择生命周期是指产品或系统从产生、投入使用到被淘汰的全过程。生命周期模型是描述产品或系统开发全部过程、活动和任务的结构框架。比较常见的生命周期模型有瀑布模型、增量模型、原型模型和迭代模型等。结合本公司软件开发项目的特点，本文档定义了三类开发过程（即生命周期模型）：第四章的瀑布模型、第五章的迭代模型和第六章的推广模型。项目开发过程的选择是项目管理的重要组成，不同的生命周期模型会有不同的WBS分解和进度安排，同时也涉及到后续项目的跟踪和监控方法的不同。为开发项目选择适用的生命周期模型进而确定项目开发过程的各项活动，是每一个项目经理接手项目后的一项重要的工作。模型的选择与项目本身的特点、顾客的特点、项目组成员的经验技能情况、环境等各种要素都相关。在选择开发过程的时候，项目经理需要考虑以下因素： 项目需求清晰性、完整性、稳定性 项目规模 项目类型（开发类、升级类） 系统复杂度 项目用到的新技术 项目成员的技能 顾客对开发过程的理解程度。瀑布模型一般是用于结构化开发，前一阶段的输出是后一阶段的输入。具有清晰的阶段结构，便于项目的跟踪、管理。如果项目的需求清晰、完整、稳定，使用瀑布模型目标明确，项目计划将非常清晰。适宜采用瀑布模型的软件项目： 需求明确、需求是预知的、需求定义完好的中型或大型项目 软件实现方法是成熟的 需求比较简单的小型项目本文第五章提供的迭代模型，可用于大中型项目或新进入的、应用复杂的业务领域。迭代模型在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。通过每个迭代过程不断地演化出新的系统。迭代模型要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。根据经验，每个开发循环迭代以六周到八周为适当的长度。迭代模式主要针对事先不能完整定义需求的开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用，并提出精化系统、增强系统能力的需求。开发人员根据用户的反馈，实施开发的迭代过程。每一个迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。表 11 典型情况下生命周期模型的选择选择要素项目是瀑布模型迭代模型需求容易被定义或熟知？YN需求可以在早期被完整定义？YN需要是通过DEMO来定义功能吗？NY需要通过DEMO来验证操作概念？NY需求功能复杂？NY功能模块之间接口清晰？YY软件要求高可靠性？YN项目会发生非预期的修改和变化？NY项目可以严格按照计划执行？NN有可重用部件？NY有资源不足问题？NY项目工期紧？NY项目必须采用大量新技术？YN是系统集成项目？NN产品在组织中有一个长的生命周期？YN项目是已有系统的一个升级版？NY项目是已有产品的推广？NY用户代表在项目期间很少参与？YN用户代表对定义新系统很陌生？NY用户代表是问题领域的专家？NY用户希望全程参与项目？NY大部分成员对项目要使用的工具不了解？YN项目组成员在项目过程中会另有安排？NY需要时，项目组人员会得到有效的培训？NY项目组适应于结构化的工作方式？YY项目经理有类似项目经验？YY项目开发模型选择的结果是：项目特征（每个要素的Y/N）与模型特征（每个要素的Y/N）匹配最多的那个模型。对已有产品推广使用型项目，只适用于推广模型。4 瀑布模型4.1模型综述瀑布模型把软件开发过程划分成若干阶段，每个阶段的任务相对独立，各个阶段不连续也不交叉。便于不同人员分工协作，从而降低了整个软件开发工程的难度。在每个阶段结束之前，都从技术和管理两个角度进行严格的审查，经确认之后才开始下一阶段的工作。项目是按照一定的顺序执行。在实际应用中这样不允许回溯的模型是有其局限性的。因此本公司采用改进的（允许回溯的）瀑布模型。改进的瀑布模型是最常用的软件开发模型，它的各个阶段是按线性序列组织并可以回溯到上一级。尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行，阶段间的依赖性由入口准则来确定。开发过程被划分为项目立项与启动、需求与计划、设计、编码与测试、系统测试、培训与试运行、项目验收、运行与维护等8个阶段。改进的瀑布模型的每个阶段均具有以下特征： 阶段性：包含8个独立的预定义阶段，各阶段由一些预定义的活动组成，分别实现一定的目标。 线性执行：在每个阶段结束时进行出口准则检查（在里程碑点上进行里程碑检查），以判断是否可以启动下一阶段工作。如果检查结果是项目尚未准备好，项目就停留在当前阶段，直至当前阶段工作完成。不但阶段和阶段之间存在严格的线性关系，阶段内的活动之间也存在线性关系。 顺序性：任一阶段都利用作为上一阶段输出的工作产品作为输入，实施应完成的动作，并产生本阶段的工作产品，作为输出传给下一阶段。 文档驱动：各阶段的主要工作成果通过文档从一个阶段传递到下一个阶段，因此模型是文档驱动的，开发过程中会产生大量的文档。 验证性：阶段之间存在验证的关系，以确保所开发的产品满足既定的需求、设计，从而保证开发了“正确的产品”。 回溯性：某阶段执行中发现问题时，可即刻停止并回溯到上一阶段，甚至更前阶段。但由于这种回溯通常代价很大，其实际的可回溯性是较弱的。模型优点： 当项目拥有稳定的需求定义和易于理解的技术方案时，瀑布模型特别适合。在这种情况下，瀑布模型可以帮助项目及早发现问题，降低项目的成本。因为瀑布模型为开发活动提供了相对稳定的需求，而这正是开发人员的梦想。如果要对一个定义得很好的版本进行维护，或将一个产品移植到一个新的平台，瀑布模型是快速开发的一个恰当选择。对于易于理解但很复杂的项目，瀑布模型也比较适合。因为项目团队可以采用顺序的方法处理复杂的问题。在质量要求高于成本要求和进度要求的时候，瀑布模型表现尤为出色。由于在项目进展过程中基本上不会产生需求的变更，因此瀑布模型回避一个常见的、巨大的潜在错误来源。当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适宜，因为它为项目提供了一种工作模式，帮助团队尽量减少返工和浪费。瀑布模型能降低计划管理费用，因为项目管理人员可预先制订所有计划。虽然要到生命周期结束时才能提供有形的工作产品，但文档的完成可反映生命周期的实际进展。模型缺点： 瀑布模型的主要问题就是缺乏灵活性。瀑布模型要求项目必须在一开始就说明全部需求，而在项目开始时、设计工作完成前、代码完成前，通常实际上很难充分地描述顾客需求。作为需求提供者的顾客，往往要等到看见实际运行的产品，才想起忘记了一些看起来简单的要求。而如果采用瀑布模型，这种看似简单的需求遗漏可能要付出非常高的代价。而且模型对需求很少变化的要求可能导致非常长的需求时间。使用瀑布模型的项目在开发过程中没有给顾客提供观摩系统的机会，等开发结束才能获得来自顾客的反馈，一旦这种反馈是负面意见，可能导致所完成的工作全盘推倒重来。瀑布模型将阶段视为独立的不连续过程，严格控制阶段的启动和退出，导致某些需要跨越阶段的工具、方法、活动很难适应，资源也难以充分利用。对于要求快速开发的项目，瀑布模型可能导致过多的文档；而如果项目想尽量增加灵活性，则对文档的维护会成为一项专门的、累赘的工作。4.2模型示意图立项与启动运行维护系统测试实现设计试运行与中试项目验收瀑布模型需求与计划图 3-1瀑布模型示意图4.3里程碑点及基线设置根据公司大多数项目情况，我们利用瀑布模型将整个项目生命周期划分为8个阶段，分别为：立项与启动、需求与计划、设计、编码实现、系统测试、试运行/中试、项目验收、运行与维护。在需求与计划、设计、实现、项目验收等4个阶段结束时设置项目里程碑点。在需求与计划阶段结束时，建立需求基线；在设计阶段结束时，建立设计基线；在系统测试结束时，建立产品基线。4.4各阶段描述4.4.1 立项与启动阶段1、阶段基本要素要素名称内容描述阶段目标启动项目，项目建议书得到批准，有项目计划的初稿入口准则公司确定某项新产品立项开发或签订项目合同出口准则1、项目经理已任命2、合同评审问题关闭、合同签订（合同类项目）3、项目启动会召开4、立项评审通过所需资源1、文档生成工具PPT、Word、Excel等本阶段度量要求1、 计划开始时间和结束时间2、 本阶段的工作量本阶段适用的标准规范1、合同管理办法2、采购与外包管理手册3、合同评审流程4、项目监控过程定义归档文件必有1、项目合同（合同类项目必有，新产品项目不要求） 2、项目建议书3、立项评审记录4、启动会会议纪要5、项目计划初稿适用时1、项目中标通知书 2、项目经理任命书3、项目范围说明书4、申请采购计划表5、采购合同7、合同评审记录8、采购计划执行及问题跟踪表2、阶段流程图参考项目立项流程文件描述。3、活动、任务及角色职责分配环节主要工作内容责任人主要输入主要输出备注1、任命项目经理1、项目级别确认、任命项目经理研发中心经理1、项目合同2、项目招投标文件3、公司产品规划1、项目经理任命书2、签发项目经理任命书2、确定项目范围与目标1、项目经理与客户或公司产品规划人员进行内部交接，了解项目具体情况和要求，确定项目范围。项目经理、客户、产品规划人员1、项目招标文件2、项目投标文件3、公司制式合同文本1、项目合同草案2、项目范围说明书1、项目内部交接包括前期项目资料、顾客关系的交接。2、如果顾客单位指定了合同文本，沿用；如果顾客单位没有指定合同文，使用本公司的制式合同3、立项、成立项目组1、合同正本交公司备案项目经理1、项目合同1、项目财务编号2、在财务系统报本月预算3、项目计划书交财务立项，分配财务编号4、成立项目组项目经理4、采购（适用时）1、拟定设备申请采购计划项目经理 1、项目合同2、合格供方名录3、采购合同1、申请采购计划表2、采购合同3、采购计划执行及问题跟踪表1、对于采购周期较长的、合同里已经明确的设备应在合同签订后进行采购。2、采购计划审核、确认物流部经理3、签订采购合同采购人员5、制定初步的项目计划1、参照项目合同要求及公司类似项目数据，选择生命周期模型，定义项目活动；制定初步项目计划； 项目经理1、项目合同2、项目范围说明书3、立项建议书1、初步项目计划2、项目过程定义1、项目计划主要关注点是满足项目工期要求、强调与顾客相关的活动时间安排2、制定初步配置管理计划CM3、制定初步质量保证计划PPQA6、项目计划报批1、组织内部启动会，介绍项目基本情况，讨论项目活动定义和项目计划项目经理1、初步的项目计划1、内部启动会会议纪要2、项目计划提交顾客或公司内部领导7、召开项目启动会1、会前准备（参与人员及分工安排）项目经理1、启动会会议纪要2、参加项目启动会3、整理会议纪要4、会议纪要分发4、本阶段重点工作说明1）合同谈判与评审 合同谈判：包括商务、技术、其它条款谈判。对相关的货物进出口、运输、交货、保险、税务、验收、不可抗力、付款条件；对项目的工作范围和内容、技术方案、系统配置、项目进度、顾客单位培训、成果形式和内容、验收方法和质量标准；甲乙双方权利、责任、义务，违约及赔付，不可抗力，纠纷的解决方式、项目变更流程等与项目顾客单位进行商讨。在合同文本中尽可能地对合同范围和内容进行明确界定，给出清晰描述。必要时可以形成专门的补充文件。 公司内部合同评审：按照公司合同评审流程的要求进行。 一般来说上述两个步骤交叉进行。2）合同软硬件采购 按照公司采购与外包管理手册的要求进行。3）项目启动会项目启动会是整个项目过程中重要的里程碑，与会者为项目各干系方代表。它标志着项目从启动阶段进入实施阶段，顾客单位、承建单位、监理机构以及项目其他的干系方的合作从此拉开序幕。通过召开项目启动会来明确项目实施的意义，说明项目实施成功的关键因素，确定各方人员职责，规范项目日常管理机制。项目启动会的发起和组织者是顾客单位。三泰公司项目组应协助顾客进行会议筹备工作。 启动会前的准备n 对于合同类项目，会前拜访顾客，递交项目计划，商讨确定项目启动会的参会人员、时间、地点、日程、会议议程，重点在于必须明确的项目管理制度和各方责任分工、工作配合要求等。访谈结束后，可协助顾客拟制会议日程、会议通知等文档。n 对于公司内部的新产品项目，需要将项目计划提交公司领导，并与技术总监进行项目计划沟通，商讨确定项目启动会的参会人员、时间、地点、日程、会议议程，重点在于必须明确的项目管理制度和各方责任分工、工作配合要求等。n 安排好项目组出席会议的人员及其分工，准备会议签到表。n 项目经理的工作日志至少从拜访顾客这一天就开始记录，直到项目结束。由于软件项目一般历时较长，每天记录项目进展和项目活动，有助于在需要时对项目发展过程或重要事件进行回溯。 启动会的议程内容n 顾客或公司领导代表宣布项目正式启动。介绍项目背景、内容、要求和顾客（或公司内部市场）项目组成员及其分工。n 项目经理介绍项目组成员及其分工、项目计划、项目开发方法，使得顾客能够了解项目开发的阶段、各个阶段要发布的成果以及需要配合的工作等。n 讨论确定项目管理制度、流程。比如项目变更流程、承建单位向顾客或公司领导汇报项目进展及情况的方式、途径、频率、内容等。 其他注意事项n 会后需要做好会议记要、存档。n 由于项目启动会议主要是信息展示而不是讨论，一般时间控制在2个小时以内，因此一些需要与会各方确认或承诺的事宜，需要在启动会议前沟通清楚。n 会前准备好签到表，会后及时整理项目联络单，注明各方人员的姓名、职务、联系方式（电话、邮件），并发送各方备查。4）关于项目计划的说明项目计划报送顾客审批的目的有两个：1）就重要项目活动（尤其是需要顾客参与完成的，比如需求调研、需求评审、系统测试、试运行/中试）时间安排达成一致；2）向顾客申明需其配合完成工作的时间要求。因此报送顾客的项目计划应该是项目计划的子集，内容参见文档模版项目计划。4.4.2需求与计划阶段1、阶段基本要素要素名称内容描述阶段目标产生和分析用户需求、软件需求和软件构件需求，完成项目估计与详细计划，并对需求开发过程进行有效的管理、度量和控制。入口准则1合同生效、2.项目计划发布、3.项目人员到位出口准则1、用户需求说明书通过评审2、产品需求说明书通过评审3、项目过程定义经批准4、项目计划经批准并发布所需资源1、文件编写软件2、项目管理软件本阶段度量要求1、 本阶段工时2、 工作包完成百分比3、 初始基线需求数本阶段适用的标准规范1、配置管理过程2、质量保证过程3、度量和分析过程4、项目监控过程5、项目估计规程（软件、硬件和结构估算规程）6、同行评审流程归档文件必有1. 项目计划2. 项目计划产品审查记录表及同行评审报告3. 用户需求说明书4. 用户需求说明书产品审查记录表及同行评审报告5. 产品需求说明书6. 产品需求说明书产品审查记录表及同行评审报告7. 项目周报8. 项目过程定义9. 测试方案10. 项目估计记录表11. 里程碑总结报告12. 项目进度表适用时1、 需求调研表2、 需求调研报告3、 项目（需求）变更申请表2、阶段流程图参见需求开发过程定义、需求管理过程定义、项目策划过程定义3、活动、任务及角色职责分配环节主要工作内容责任人主要输入主要输出备注1、提交本阶段详细计划1、编制本阶段详细工作进度计划项目经理1、项目计划2、项目范围说明书1、本阶段详细进度计划1、促成顾客以正式发文方式通知被调研对象调研时间安排。2、阶段计划报顾客备案3、促成顾客完成调研对象选择、调研时间安排。2、需求获取1、编写需求调研表需求负责人/项目成员1、项目范围说明书2、阶段计划1、需求调研记录2、需求调研报告3、用户需求说明书1、如果调研中有需要顾客明确的问题，需求调研报告书面提交给顾客单位。，必要时可以会议方式进行汇报，以促使其中的问题能够尽快得到解决。2、顾客访谈和现场勘查3、整理调研记录，编写需求调研报告4、分析调研所得，编写用户需求说明书3、需求评审1、用户需求说明书内部评审评审组长1、同行评审流程2、用户需求说明书3、用户需求说明书评审检查单1、用户需求说明书（修改）2、同行评审报告3、需求跟踪矩阵1、用户需求说明书顾客审批方式可以是书面提交或会议交流方式。2、用户需求说明书应要求顾客签字确认。2、评审问题修改，必要时补充调研项目成员3、报顾客单位审查、批准项目经理4、用户需求说明书纳入配置管理CM4、需求分析1、编写产品需求说明书需求分析人员1、 同行评审流程2、 产品需求说明书3、 产品需求说明书评审检查单1、同行评审报告2、产品评审记录表3、产品需求说明书（修订）产品需求说明书应要求顾客签字确认。2、产品需求说明书评审项目经理3、评审问题修改项目成员4、产品需求说明书纳入配置管理CM5、需求管理1、建立需求跟踪矩阵需求分析人员1、 用户需求说明书2、 产品需求说明书3、 PPQA检查单4、 需求跟踪矩阵2、需求跟踪矩阵符合性检查PPQA6、项目变更（适用时）1、若项目建设内容发生变化，可参照需求管理过程定义、配置管理流程中有关需求变更处理流程进行项目变更。项目经理CCB1、变化的需求1、项目（需求）变更申请表1、变更申请表需与顾客单位共同签署并通告相关方7、项目估计与计划1、做项目估算，进行项目整体规划项目经理1、项目计划2、产品需求说明书3、同行评审流程4、项目计划评审检查单1、项目估计记录2、项目计划3、项目进度表4、产品评审记录表5、项目周报6、项目进度计划1、项目计划作为项目后续实施、管理、度量的基准。2、项目进度计划就是Project生成的进度表格，有模板。2、修订配置管理计划CM3、修订质量保证计划PPQA4、编写测试计划测试人员5、整合项目计划、组织项目计划评审并发布。项目经理6、建立项目进度计划8、测试用例编写1、编写系统测试计划和用例2、编写性能测试计划测试人员1、产品需求说明书2、测试流程测试方案9、阶段总结1、需求阶段工作总结（里程碑评审）项目经理1、里程碑总结报告（需求）1、本阶段结束时建立项目需求基线4、本阶段重点工作说明1）项目估计与计划 项目估计n 项目估计的基础是本公司资产库中类似项目的数据、公司的管理要求。n 估计过程由以下步骤组成：估计规模估计工作量估计进度审查和批准跟踪和报告估计度量和改进估计。n 项目估计的具体内容和方法参见项目估计规程。 制定项目计划n 项目计划制定的依据：公司一体化管理手册、程序文件、本文档、项目度量库、项目计划。n 项目计划包括项目概述、项目任务、验收准则、项目组织、项目的生命周期及阶段划分、项目估计、开发环境、测试环境、进度计划、资源使用计划、测试计划、需求管理计划、质量保证计划、同行评审计划、监控计划、培训（项目组成员）计划、度量分析计划、配置管理计划、风险管理计划、项目计划变更与重估计约定等，详细内容参见项目计划模版。n 制定项目计划，首先要估计项目规模、得出总工作量，然后按照生命周期模型进行工作分解，建立项目进度表。n 项目计划的具体内容与方法参见项目策划过程。2）工作日志、项目周报、例会制度从本阶段开始项目组成员需要记录每天的工作，每周提交项目经理；项目经理编写项目周报。项目经理组织召开周例会，检查项目进展，进行每周工作总结，评审项目的进展、存在的问题和讨论解决方案。3）用户需求调查对象甄选 甄选被调研对象。向不同层次的用户代表收集不同层次的需求，是需求调研落到实处的关键。不可能对所有的用户都进行需求获取，所以要识别出不同层次的用户作为被调研对象。每类调研对象应是能真正代表这类系统用户需求、能够做出决策的人。用户代表往往是顾客中三种角色：有决定权的领导（高层和中层）、熟悉业务流程的专家、系统最终用户。高层领导会针对需求描述一个蓝图、中层领导会描述本部门的管理需求、一线业务人员会描述更多业务细节和操作细节，如需要什么报表，如何保证单据的准确性，需要查询哪些信息等更细更小的需求。调研开始前还要理清被调研对象之间的行政隶属和日常工作之间的关系、理清被调研对象的工作目标、被调研对象内部的主体业务活动等。4）用户需求说明书确认 顾客确认的必要性：签字是顾客单位同意需求的标识性行为。通过了正式评审的用户需求说明书是项目接下来的工作基础，这个基础在顾客单位和承建单位开发人员之间确立了一个需求约定，是应用系统建设的基石。 确认的重要性：用户需求说明书不仅仅是今后项目开发的基线，更是项目验收的标准。一般来说项目的招标文件都对项目建设内容做出或详细或简练的规定，项目合同书一般也会包含项目建设内容和验收条件，但是无论招标文件还是项目合同都很难完全界定系统的全部需求。经过需求调研，一方面细化了顾客单位的需求，另一方面如果项目从立项到实施的时间间隔比较长的话，可能顾客业务会出现调整，从而造成调研结果与招投标文件、项目合同之间的差异，因此，这时的用户需求说明书书实际上是深化、补充和修订了项目建设目标和内容，因此也就成为了项目终验的主导标准。 确认的先决条件：用户需求说明书的质量将直接影响到应用系统的质量和项目合同的全貌履约。用户需求说明书的编写是否条理清晰、简洁明了，将直接决定顾客单位对文档的理解，甚至直接决定他们对于签字确认的态度。编写文档时，句子和段落要简练，使用正确的语法、拼写、标点符号，排版整齐美观。使用术语要保持一致性，并在术语表中定义它们。尽量采用建设/顾客单位使用的业务语言对需求进行描述,尽量不出现软件领域内的专业词汇，必要时可以利用图表形式。通过浏览文档，能够完全理解所要解决的具体问题和该问题的一般性解决方案。 确认的一些技巧和变通：n 对于需求不明确的情况，可借用原形法用简单的界面展现系统的轮廓,让顾客模糊的思想逐渐变得清晰。n 如果需求无法和顾客确认，或者制作了简单的界面，顾客也没有提出什么建议或更改。可以考虑这样做，和顾客约定一个需求封闭时间，在封闭时间之后提出的需求都作为需求变更来处理。n 以会议的方式由承建单位需求负责人向顾客单位人员讲述用户需求（如果能够配合未来系统的主要界面展示更好），在讲述过程中纠正调研中理解的偏差，补充遗漏的事项。n 化整为零，对于多个部门的需求，可以分别找对应的顾客单位签字。n 将调研记录作为用户需求说明书附件，提供佐证信息。 不能用形式上的签字代替对需求内容的验证顾客代表在上签字确认的前提条件是对其内容的认可，因此在顾客代表签字之前，项目经理应确保顾客已经明了用户需求说明书中所述内容。5）需求管理在项目实施过程中，要求项目经理（或项目经理指派专人）对用户需求进行跟踪管理，以识别出需求与项目工作产品的不一致。具体工作内容及要求参见需求管理过程定义。6）关于产品需求说明书产品需求是能满足顾客需求，并对软件产品规格进行了详细描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。产品需求包括功能需求，性能需求，潜在需求，约束，接口（外部接口和内部接口）。产品需求一般使用技术术语描述，并供设计决策所使用。产品组件需求是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等，这些可以认为是产品组件需求。一般来说，我们写的产品需求说明书都会包含产品需求和产品组件需求。4.4.3设计阶段1、阶段基本要素要素名称内容描述阶段目标将需求转换为未来系统的设计，逐步开发系统构架。入口准则1、用户需求说明书、产品需求说明书、项目计划通过评审出口准则设计说明书（软件包括概要设计和详细设计）得到评审和批准并置于配置管理之下所需资源1、文档生成工具Word、Excel等2、软件设计工具建议采用UML、MS Visio、亿图。本阶段度量要求1、 工作量2、 工时3、 工作包完成百分比4、 需求项变更次数5、 需求变更率本阶段适用的标准规范1. 配置管理过程2. 质量保证过程3. 度量和分析过程4. 项目监控过程5. 硬件设计和实现流程6. 结构设计和实现流程7. 软件设计和实现流程8. 决策分析过程归档文件必有1. 概要设计说明书2. 概要设计说明书产品审查记录表及同行评审报告3. 详细设计说明书4. 详细设计说明书产品审查记录表及同行评审报告5. 数据库设计说明书6. 数据库设计说明书产品审查记录表及同行评审报告7. 设计与实现规范8. 决策分析表9. 设计开发输入/输出清单10. 项目周报11. 里程碑总结报告适用时1、 硬件设计说明书2、 嵌入式软件设计说明书3、 结构概要设计说明书4、 样机外型5、 变更请求及跟踪报告2、阶段流程图参见软件设计和实现过程定义、硬件设计和实现过程定义、结构设计和实现过程定义。3、活动、任务及角色职责分配环节主要工作内容