项目共通作业流程基础知识培训.ppt
,BD阶段规约,2,BI阶段规约,1,DD&CTD阶段规约,3,CT阶段规约,5,MK阶段规约,4,共通关注点,6,1 BI阶段,BI阶段在V型开发模型项目过程中的位置,1.1 BI阶段-定义,本阶段的目的 通过调查与分析，获取用户需求并使之规格化、具体化，最终输出为产品需求，在其中确定所开发软件的功能、性能以及其他要求，以作为后续软件设计和系统测试的依据。关键说明：用户需求 系统需求,1.2 BI阶段-作业流程,1.3 BI阶段-作业流程-需求评估,规定在需求评估完发现工作量超过原项目工作量的5%的，则需要由项目经理持该评估报告协同市场部人员和客户进行沟通，以进行最终决策；需求评估与需求评审的区别：,1.3 BI阶段-作业流程-需求评估,2）CQ上“分析”环节新增的填写信息：,1.3 BI阶段-作业流程-挖掘隐含需求,注意挖掘隐含需求：1）在描述需求过程中要注意：用户提出的需求可能是经过用户自己思考加工过的内容，属于含混性需求，可能不全面并可能不具有概括性，未意识到真正需求或未能真正表达出来，因此要帮客户挖掘出真正的需求。如：用户提出要提供2个月的报表各一张，但是需求人员经过挖掘和调查完以后发现用户要这2个月报表的数据是为了进行2个月的各种产品销售量对比，此时我们应该将需求定位为开发双柱状图表以供用户比对。2）用户提出的需求可能只局限于目前的使用情况，但是要根据项目研发经验以及业务发展趋势做一些前瞻性的考虑，为系统设计预留扩展性，这样等用户真正提出这样的需求的时候不会对架构产生大的影响。,1.4 BI阶段-角色与职责（1/3）,项目经理负责协调需求组所需的配合工作；根据需求组的评审请求组织评审；负责监控需求组工作情况。负责协调测试组所需的配合工作；根据测试组的评审请求组织评审；负责监控测试组工作情况。需求组长负责安排需求组工作，并对日常需求开发过程监控；负责需求调研过程中信息的及时发布和共享；负责发起对用户需求分析书、系统需求书、系统测试清单（初版）进行评审。,1.4 BI阶段-角色与职责（2/3）,需求分析师负责与客户/最终使用者之间的需求调查及分析；负责用户需求分析书及系统需求书的编写。负责系统测试清单（初版）的编写；参与系统测试清单及系统测试步骤书的讨论和评审，并提供认可意见或修改建议。客户/最终使用者负责提供必要的需求信息；参与用户需求分析书及系统需求书的讨论和评审，并提供认可意见或修改建议。,1.4 BI阶段-角色与职责（3/3）,设计组长/系统设计员了解项目相关业务背景、技术知识；参与用户需求分析书及系统需求书的讨论和评审，并提供认可意见或修改建议。参与系统测试清单及系统测试步骤书的讨论和评审，并提供认可意见或修改建议。测试组长/测试设计员/测试人员参与 系统需求书、系统测试清单（初版）的讨论和评审，并提供认可意见或修改建议。负责在系统测试清单（初版）的基础上修订系统测试清单和发起评审，编写系统测试步骤书和发起评审。,1.5 BI阶段-输入,合同（协议、订单）中的顾客需求或技术规范书；顾客提出的功能规格书，或顾客无明确规格要求时由需求分析师提出并征得顾客认可的文档化用户需求；有关的法律、法规要求或行业标准；公司以往类似项目中导出的有关信息。,1.6 BI阶段-输出,用户需求分析书系统需求书 对应以上文档的核查报告、完成报告以及必要的中间记录或文档。,BD阶段规约,2,BI阶段规约,1,DD&CTD阶段规约,3,CT阶段规约,5,MK阶段规约,4,共通关注点,6,2.1 BD阶段,BD阶段在V型开发模型项目过程中的位置,2.2 BD阶段-定义,基本设计阶段的目的是按用户需求的分析结果和系统需求的框架定义，逐步细化所有的系统功能，明确系统需求书中每一功能的具体实现设计，粒度上应兼顾开发组、测试组的要求；同时根据基本设计输出物进行集成测试设计。根据电信信息化部项目特点，可将基本设计输出文档按功能性质划分，分为总册、前台、后台等部分；同时后续集成测试设计也应参考同样划分原则进行处理。关键说明：功能细化、适度划分、技术引导、兼顾多方。,2.3 BD阶段-作业流程,2.4 BD阶段-角色与职责（1/2）,项目经理负责协调组间的配合工作；负责监控各组总体工作情况。设计组长负责安排设计组工作，并对日常过程监控；负责设计过程中信息的及时发布和共享；负责发起对基本设计书、集成测试清单（初版）进行评审。参与集成测试清单及集成测试步骤书的讨论和评审，并提供认可意见或修改建议。,2.4 BD阶段-角色与职责（2/2）,系统设计员负责基本设计书及集成测试清单（初版）的编写。参与集成测试清单及集成测试步骤书的讨论和评审，并提供认可意见或修改建议。测试组长/测试设计员/测试人员参与基本设计书、集成测试清单（初版）的讨论和评审，并提供认可意见或修改建议。负责在集成测试清单（初版）的基础上修订集成测试清单和发起评审，编写集成测试步骤书和发起评审。开发组长/开发人员参与基本设计书的讨论和评审，并提供认可意见或修改建议。,2.5 BD阶段-输入,用户需求分析书；系统需求书；系统测试清单；系统测试步骤书；经评审认可的其他文档及程序代码。,2.6 BD阶段-输出,基本设计书（包含内容：采用的操作系统、采用的第三方模块、采用的共通构件、采用的核心的技术平台和技术架构、使用的数据库、以及主要的业务功能流程、用户界面等）；完成报告、核查报告以及必要的中间记录或文档。,BD阶段规约,2,BI阶段规约,1,DD&CTD阶段规约,3,CT阶段规约,5,MK阶段规约,4,共通关注点,6,3.1 DD&CTD阶段-定义,详细设计的目的是根据基本设计书中的功能设计要求，确定每一功能及功能内部细分的功能单元的算法、数据结构；同时根据详细设计输出物进行单元测试设计。根据电信信息化部项目特点，可将详细设计输出文档按功能性质划分，分为总册、前台、后台等部分。同时后续单元测试设计也应参考同样划分原则进行处理。,3.2 DD&CTD阶段-作业流程,3.3 DD&CTD阶段-角色与职责（1/2）,项目经理负责协调组间的配合工作；负责监控各组总体工作情况。开发组长负责安排开发组工作，并对日常过程监控；负责详细设计过程中信息的及时发布和共享；负责发起对详细设计书、单元测试清单及单元测试步骤书（可选）的讨论和评审。,3.3 DD&CTD阶段-角色与职责（2/2）,开发人员负责详细设计书、单元测试清单及单元测试步骤书（可选）的编写。负责详细设计书、单元测试清单及单元测试步骤书（可选）的评审。设计组长/系统设计员建议参与详细设计书的评审。测试组长/测试设计员建议参与单元测试清单及单元测试步骤书（可选）的评审。,3.4 DD&CTD阶段-输入,用户需求分析书；系统需求书；基本设计书；经评审认可的其他文档。,3.5 DD&CTD阶段-输出,详细设计书；单元测试清单、单元测试步骤书（可选）；完成报告、核查报告以及必要的中间记录文档。,BD阶段规约,2,BI阶段规约,1,DD&CTD阶段规约,3,CT阶段规约,5,MK阶段规约,4,共通关注点,6,4.1 MK阶段-定义,编码阶段的目的是根据基本设计书、详细设计书进行具体的编码，生成可以提交测试的代码。单元测试阶段的目的是对所有的程序单元进行测试，按照测试计划要求达到足够的测试覆盖率，以保证程序单元能按预定方式正确处理数据；在此过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，对应的开发人员应当及时消除缺陷（改错）。,4.2 MK阶段-作业流程,4.3 MK阶段-角色与职责（1/2）,项目经理负责协调组间配合工作；负责监控开发组工作情况；开发组长负责开发任务的细化分配；负责跟踪开发进度，解决开发中碰到的各种技术、资源方面的问题；组织召开代码评审负责开发结束后完成报告编写和总结评审的发起；负责生成代码发布说明初稿；,4.3 MK阶段-角色与职责（2/2）,开发人员负责具体编码，并且负责更新相应模块的版本变更说明；进行代码基本调测，确保提交的代码可以用于后继测试；配置管理员提供开发组要求的基准版本；,4.4 MK阶段-输入,用户需求分析书；系统需求书；基本设计书详细设计书经评审认可的其他文档及程序代码。,4.5 MK阶段-输出,基本调测通过的代码以及版本发布说明文件完成报告,BD阶段规约,2,BI阶段规约,1,DD&CTD阶段规约,3,CT阶段规约,5,MK阶段规约,4,共通关注点,6,5.1 CT阶段-定义,单元测试阶段的目的是对所有的程序单元进行测试，按照测试计划要求达到足够的测试覆盖率，以保证程序单元能按预定方式正确处理数据；在此过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，对应的开发人员应当及时消除缺陷（改错）。目前单元测试均由开发人员自行负责，开发组长可综合考虑开发组成员的工作状况，安排交叉测试等方式，有效保证程序的质量。,5.2 CT阶段-作业流程,5.3 CT阶段-角色与职责（1/2）,项目经理负责推进测试发现缺陷的解决；开发组长负责单元测试工作的安排和监控；负责测试日报、缺陷记录等单元测试结果的发布和共享；负责推进测试发现缺陷的解决；负责在单元测试工作完成后的评审发起、组织编写完成报告。,5.3 CT阶段-角色与职责（2/2）,开发人员根据安排执行单元测试，并及时记录测试结果。,5.4 CT阶段-输入,单元测试清单单元测试步骤书（可选）；详细设计书；经评审认可的其他文档及程序代码。,5.5 CT阶段-输出,消除了缺陷的程序单元；完成报告以及必要的中间记录文档，如测试日报（可选）、测试进度报告（可选）、单元测试缺陷记录等。,BD阶段规约,2,BI阶段规约,1,DD&CTD阶段规约,3,CT阶段关注点,5,MK阶段规约,4,共通关注点,6,6.1 需求与产品版本双向追溯,需要做好需求与版本的对应关系的管理。包括两方面，在开发阶段，需要进行规划，确定 规划版本所要实现的功能点。另外，在投放阶段，需要做好版本投放履历，知道当前投放了什么版本，从而知道当前实现了那些功能点。研发使用版本规划表，记录研发版本所包含的新开发的功能点。投放使用版本投放履历表，记录投放版本所包含的新开发的功能点。在该需求的需求评估通过后，在CQ系统上需要填写该需求规划的版本。通过以上改动，实现双向的对应。,6.2 产品组件应用评估与管理,构件复用与生成：在系统设计阶段，应该考虑充分利用现有控件库中的构件，争取重用构件，提交开发效率。如果没有现有构件可以利用，并且该功能有构件的特征，应考虑从构件的角度进行设计开发，以后面提交构件，供大家复用。构件管理：修订共通构件管理规范，以规划部作为共通构件的管理部门，修改构件入库、复用、维护升级、向研发中心提交或获取构件的流程环节内容。复用环节中包含了构件复用评估的环节。修订共通构件使用登记表，包含了构件版本发布、构件复用登记的功能。,6.3 决策分析管理,新增决策分析指导书，对软件过程中的重要问题和所确定的多项候选方案进行决策，含场景、准则、过程指导。新增决策分析记录表，记录评估议题、备选方案概要、评估方法、决策过程、结论。,6.3 决策分析管理-场景,场景（详见指导书的“5.入口准则”）,研发过程,架构,/,平台方案评估,系统范围界定评估,组件选择评估,。,风险管理过程,风险应对方案评估,维护过程,重大问题,/,需求的,应对方案评估,项目前期,项目计划评估,项目管控,6.3 决策分析管理-实施流程,过程（详见指导书“7.工作流程”）,6.3 决策分析管理-准则,准则（详见指导书“7.3.1 准则类型”）,选择解决方案的准则一般涉及成本（例如，时间、人员、金钱）、效益（例如，性能、能力、效率）和风险（例如，可执行性、技术、成本、进度等方面的风险）。可考虑的准则类型包括：用户方标准、人力分析、系统技术分析、项目管控。,6.4 需求与设计的评审,需求和设计完成后都需要进行评审，需求和设计评审应用CheckList，评审的记录要完整，对评审出的问题作闭环跟踪管理。电信部提供了共通的需求和设计评审的CheckList作为参考，各项目组应根据项目组的特点进行调整，形成适用于项目组的CheckList；项目组的CheckList应该在项目组的使用过程中持续完善。评审的结果可以按照公司SF-100-014_核查报告模版进行会议记录及评审问题点记录，也可以在PMS系统上进行会议记录及评审问题点记录。在使用核查报告时，可以把CheckList作为TAB页并入核查报告文档。,附.公司对“技术方案评审会”的要求,公司期望领导要求PMO和质量保证部一起调查各部门在项目开始时 是否有开展技术和解决方案的评审会流程规定；是否有认真按照流程进行实施；是否有本部门(或邀请公司内)的经验人士参加；是否有对评审效果进行回顾和经验总结。公司期待通过技术和解决方案的评审会解决或达成：1.提高技术和解决方案的质量，确保系统运行稳定、减少维护量等；2.可以利用公司或部门以往项目经验，规避项目风险；3.可以有效利用和形成构件，减少开发量，提高开发效率。,
