需求和技术解决方案.ppt

《需求和技术解决方案.ppt》由会员分享，可在线阅读，更多相关《需求和技术解决方案.ppt（54页珍藏版）》请在三一办公上搜索。

1、中国建设银行厦门开发中心,工程实施,培训目标,经过本课程的培训，学员可以：了解CMMI工程实施过程组的组成了解CMMI定义和工程实施过程组各过程域的特殊目标学习标准过程体系中是如何实现的,CMMI工程实施过程组的组成,工程过程域,需求管理需求开发技术解决方案产品集成验证确认,课程内容,需求开发（RD）需求管理（REQM）技术解决方案（TS）产品集成（PI）验证（VER）确认（VAL）体系其他过程,需求开发（RD）,目标,产生并分析客户、产品以及产品组件需求。,失效征兆,需求不明确，客户和开发团队不能正确理解需求；设计、实现和测试的工作产品和需求产生不一致；难于对产品设计达成共识，花费更长的不必

2、要的时间。,失效后果,交付产品的不可用和客户的不满意会导致未来业务流失；时间和资源的浪费会影响我们的绩效；需求不稳定而导致不停地返工使团队很厌烦失去信心；当你不能很好理解需求的时候，客户会对你失去信任。,需求开发,分析并确认需求,开发客户需求,确认客户需求,确认产品、产品组件和接口需求,开发产品需求,利益干系人的需要,SG1-开发客户需求,SP 1.1 诱导需要在产品生命周期的所有阶段诱导利益干系人需要，期望，约束条件以及接口SP 1.2 开发客户需求 将利益干系人的需要、期望、约束条件和接口转化成为客户需求,SG2-开发产品需求,SP 2.1 建立产品和产品组件需求 建立并维护产品和产品组件

3、需求，这些需求是基于客户需求SP 2.2 分配产品组件需求 给每个产品组件分配需求SP 2.3 识别接口需求识别接口需求,SG3-分析并确认需求,SP 3.1 建立操作概念和场景建立并维护操作概念和相关场景 SP 3.2 建立需求功能性定义建立并维护需求功能性定义SP 3.3 分析需求分析需求确保其必要充分SP 3.4 分析需求以达平衡分析需求以达到利益干系人需要和约束条件之间的平衡SP 3.5 确认需求 确认需求以确保开发出的产品在预期的使用环境中正常运作,RD在标准过程体系中的实现,任务1：业务需求分析,业务需求分析是后续项目开发和测试的基础。业务需求说明书是一个集成文件，它包含两个附件，

4、非功能需求分析说明书和业务需求优先级及风险分析表。业务需求分析后及时更新项目风险列表。它由项目团队共同完成，并达成共识。,相关角色主要执行者：系统分析师其他执行者：项目经理、技术经理、业务经理、需求分析工程师、干系人,工作产品输入：项目任务书、项目说明书、项目章程输出：业务需求说明书、业务需求整合分析报告、项目风险管理列表,需求开发的核心原则,为获得项目的成功，干系人和项目成员须就下述三个要素达成清晰的理解和共识：需要解决的问题项目在成本、进度、资源、政策上的约束解决方案的约束关键实践：识别你的听众问题和解决方案的分离创建业务领域的共享理解使用场景和用例来捕获需求 建立和维护需求优先级列表 使

5、取舍价值最大化 管理项目范围 知道停下来的时候,需求分析方法论Zachman框架,术语：业务,业务目标：一个或多个资源期望达到的状态。目标联系着 整个业务以及业务中的过程。业务流程：企业为了达到其业务目标所进行的一系列活动。业务规则：定义或约束业务某些方面的声明，代表着业务信息。它对业务怎样运行（业务功能如何实现）进行管理。业务功能：为了实现企业的某些目标而采取的行为。是企业一套相关的和正在进行的活动。,业务需求分析方法论,需求分析技术,结构化分析方法一种面向数据流进行需求分析的方法，结构化分析方法适合于数据处理类型软件的需求分析。具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据

6、传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止原型化分析方法 在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。它分成废弃型和演化型(追加型),结构化方法,结构化分析方法是一种建模技术,原型化方法,回顾,以上我们介绍了：CMMI中需求开发过程域的SG 标准过程体系中需求开发过程所含任务 需求开发的关键技术,课程内容,需求开发（RD）需求管理（REQM）技术解决方案（TS）产品集成（PI）验证（VER）确认（VAL）体系其他过程,需求管理过程域（REQM）,目标,管理项目的产品或产品组件的需求，并识别需求与项目计划及工作产品之间的不一致

7、方面。,失效征兆,项目过程中有很高的返工水平；团队可能会接受任何没有经过授权的需求；项目有需求急剧蔓延的风险；无法保证产品满足客户需求。,失效后果,缺乏对干系人真实需求的理解会增加项目开发时间和成本；交付的产品极有可能不正确不完整；频繁的需求变更是客户看得见的资源浪费；需求跟踪不到位会导致产品交付前的测试不完整不正确。,获取对需求的理解,获取对需求的承诺,识别项目工作和需求的不一致,维护需求双向跟踪,管理需求变更,需求,跟踪矩阵,需求管理内容,管理需求,SG 1 管理需求,SP 1.1 获取对需求的理解与需求提供者就需求的含义开发对需求的理解SP 1.2 获取对需求的承诺从项目的参与者处获取承

8、诺SP 1.3 管理需求变更当需求在项目中逐渐被开发时，管理需求变更SP 1.4 维护双向的需求跟踪在需求和工作产品之间维护双向的可跟踪性SP 1.5 识别项目工作和需求之间的不一致识别存在与项目计划、工作产品和需求之间的不一致,术语：,需求跟踪：是在用户需求与系统实现之间双向跟踪，也可以在系统内部的层次和模块之间双向跟踪。从用户需求，到具体模块的实现，建立了一条需求跟踪链。需求跟踪矩阵：是需求跟踪链的具体化，能够反映需求文档和后续工作成果（包括概要设计文档、测试需求等）的对应关系。需求跟踪矩阵分为：纵向跟踪矩阵，包括：需求之间的派生关系（客户需求到产品需求）、实现与验证关系（需求到设计，需求

9、到测试需求等）、需求的责任分配关系（需求由谁来实现）；横向跟踪矩阵，需求之间的接口关系。,RM在标准过程体系中的实现,任务：需求跟踪矩阵建立和维护,需求跟踪矩阵建立：需求管理员在系统分析师和需求分析工程师的协助下负责客户需求到产品需求的需求跟踪矩阵建立。需求跟踪矩阵的维护：需求管理员负责组织需求跟踪矩阵的维护，测试需求的编写人员负责需求到测试需求的需求跟踪矩阵建立，设计人员负责需求到设计的需求跟踪矩阵的建立等等。需求跟踪矩阵要纳入基线管理。,相关角色主要执行者：需求管理员其他执行者：系统分析师、需求分析工程师,工作产品输入：业务需求说明书、技术方案、测试需求输出：需求跟踪矩阵,关键点：如何平衡

10、收入和产出？,需求工程,回顾,以上我们介绍了：CMMI中需求管理过程域的SG标准过程体系中需求管理过程所含任务,课程内容,需求开发（RD）需求管理（REQM）技术解决方案（TS）产品集成（PI）验证（VER）确认（VAL）体系其他过程,技术解决方案过程域（TS）,目标,按照需求进行设计、开发和实现解决方案。解决方案、设计和实现的内容包括产品、产品组件和产品相关生命周期的单一或组合的过程。,失效征兆,决定的方案缺乏可行性；有些产品不能满足技术性能要求和用户需要；解决设计或架构问题会增加测试工作量或返工；客户对从他们需求而来的解决方案非常惊讶，这是我要的吗？,失效后果,测试工作量增加或者返工导致成

11、本增加；性能不能满足客户需求有业务流失风险；产品不能适应技术发展和未来业务发展。,技术解决方案内容,需求开发,设计细节文档,开发产品,备选设计评估标准,选择产品组件解决方案,开发设计,实施产品设计,SG 1 选择产品组件解决方案,SP 1.1 开发备用解决方案和选择标准开发备用选择方案和选择标准SP 1.2 选择产品组件解决方案选择最能满足以确立的选择标准的产品组件解决方案,SG2 开发设计,SP 2.1 设计产品或产品组件 开发产品或产品组件的设计SP 2.2 建立技术数据包 建立并维护技术数据包SP 2.3 使用标准设计接口使用已经确立的标准设计产品组件接口SP 2.4开展自制、外购或重用

12、分析根据已经确立的标准评估产品组件是自行开发、外购还是重用,SG3-实施产品设计,SP 3.1 实施设计实施产品组件的设计SP 3.2 开发产品支持文档 开发并维护最终用户手册,术语：架构,企业总体架构：在流程、技术与业务接口、信息标准化上的最佳管理与实施的理论与方法，为了改善组织的综合能力与企业在IT发展和运行上的投资。由企业战略和业务驱动，资源包括战略、业务、人员和IT技术多个方面。企业总体架构架构的模块和组件模块之间的关系构架治理原则 业务架构：是建设银行全面的IT 战略和IT 体系架构的基础，因为业务架构是数据、应用、技术架构的决定因素。业务架构将高层次的业务目标转换成可操作的业务模型

13、，描述业务应该以何种方式运作才能满足成功必须的能力和灵活性。业务架构流程+数据+位置+角色+业务规则+时序应用架构：定义支持关键业务的主要的应用，按照银行业应用架构的层次模型细划为各个应用/应用群的功能模块和应用范围、应用之间及与外围系统的关联关系、应用/应用群的分布模式、接口定义及数据流向。,术语：架构,安全架构：包括：物理、网络、系统、应用、数据层面的身份认证、访问管理、加密、防恶意代码、加固、监控、审核跟踪和备份恢复。技术架构：业务架构基础上提供了一个贯穿与信息数据、应用和基础设施的框架，为发展和开发一个在企业一级交互不同的部门和领域的、在技术层面上的、与业务相一致的解决方案提供了一个基

14、础。保持了企业在技术标准、技术选型、应用设计、供应商产品的选择等等一切技术层面的组合和组件与企业的战略规划、业务架构和各个业务领域的实际需求的一致性。数据架构：提供了银行业务对信息数据需求的内容。保证数据有效的共享和交换是企业总体架构的主要目的之一。数据架构描述了我行的业务现在和未来是如何使用数据的。,TS在标准过程体系中的实现（1）,TS在标准过程体系中的实现（2）,TS在标准过程体系中的实现（3）,TS在标准过程体系中的实现（4）,任务一：技术方案编制,新建系统建议识别3个以上的备选技术方案，并在其中进行选择。对于续建系统，如果不涉及架构的调整，只需要调整相应内容，不需要做备选方案和决策分

15、析。在设计备选方案时，要保证方案的可行性。,相关角色主要执行者：技术经理其他执行者：评审专家、系统分析师、系统管理员、项目总监、组织架构师,工作产品输入：业务需求说明书输出：技术方案、技术方案计分卡、架构控制检查表、评审记录、项目风险管理列表,任务二：高层设计,高层设计和低层设计可以根据项目规模合并进行。（规模小项目）在高层设计时重点要保证接口的正确定义。（外部接口和内部接口）,相关角色主要执行者：技术经理其他执行者：评审专家、项目经理、设计工程师,工作产品输入：技术方案、业务需求说明书输出：概要设计说明书、编码规范、评审记录、网络及系统实施说明书,任务三：低层设计,详细设计说明书可以与概要设

16、计说明书一起提交评审。,相关角色主要执行者：设计工程师其他执行者：评审专家、项目经理、技术经理,工作产品输入：概要设计说明书输出：评审记录、详细设计说明书,任务四：开发与单元测试,单元测试通常被当作是附属于代码开发的步骤。单元测试脚本设计在源代码被开发完毕后开始。因为一个构件本身不是一个单独的程序，所以必须为每个单元测试开发驱动程序/和桩模块软件。,相关角色主要执行者：编码工程师其他执行者：系统管理员、集成工程师,工作产品输入：概要设计说明书、集成测试控制表、详细设计说明书输出：测试案例、集成测试控制表、源代码,任务五：用户支持材料编制,业务用户支持材料主要包括：系统操作手册、系统用户手册；技

17、术用户支持材料主要包括：安装实施工艺、常见问题处理手册、应用系统安装配置手册、技术手册、运行维护手册。,相关角色主要执行者：项目经理其他执行者：技术经理、评审专家、项目成员、业务经理,工作产品输入：概要设计说明书、技术方案、网 络及系统实施说明书、详细设计说明书、业务需求说明书输出：技术用户支持材料、评审记录、业务用户支持材料,解决方案核心原则,根据你至今了解的一切来创建架构 提升抽象的级别来应付复杂性 让问题驱动解决方案 按照组件松耦合高聚集的方式组织架构 重用存在的资产 发挥架构作为协作工具的优势,如果没有一个架构基础，软件系统开发将会是低效和偶然的。这样项目将是低效推进、缺乏重用且充满返

18、工。这样的项目同时也无法有效组织项目成员，并使技术成员将其注意力集中于共同技术目标。因此，我们需要采用架构来统一项目成员的兴趣和目标的焦点。伴随着架构的持续成长，我们必须清晰明白地记录重要的技术决策。,设计定义,数据设计是把分析过程中产生的信息域模型转化成执行软件所需要的数据结构。数据对象和数据关系被定义在E-R图里，数据字典中详细描述的数据内容提供了数据设计活动的基础。架构设计定义了主要的程序结构化的模块之间的关系。设计说明-模块框架-可由多个分析模型和在分析模型中定义的子系统交互中得到。接口设计描述了软件本身如何自我通信，和其他系统的交互以及和使用者的交互。数据和控制流程图提供了接口设计所

19、需要的信息。流程设计把程序架构的结构化组件转化成软件部件的流程描述,设计：使用不同的技术和原理来定义一个设备，一个过程或者是一个系统的过程。设计要足够详细以保证物理实现。,由McGlaughlin建议优秀设计的三个特点：设计必须体现所有包含在分析模型中的明确的需求，同时也必须考虑客户期望的隐含的需求；对于软件的编码、测试和维护人员而言，设计必须是易读的、易懂的指南；设计必须提供软件完整的描述，从执行的角度描述数据、功能性和执行性。,优秀设计的特点,设计的质量标准,设计应该展示一个有层次的组织架构，体现出在软件的模块之间的智能化的控制（好的面向对象的设计不需有此特点）设计应该是模块化的软件应该是

20、逻辑化的分割成多个实现功能和子功能的模块设计应该包含数据和流程的抽象,设计应该使系统分解为可展示独立功能特点的多个模块设计应该减少模块之间、模块和外部环境之间的连接的复杂度应该通过一种可重复的方法生成设计，这种方法是由在软件需求分析过程中获得的信息来驱动。,设计注意事项,不能以狭窄的视角来做设计-而是应该在设计决定之前评估多种方法设计应该可以回溯到分析模型设计不应该是全新的活动-复用已有的设计组件设计应该使软件和问题之间距离最小化，就像它在现实生活中存在的那样。设计应该体现一致性和统一性,设计应该是结构化以适应变更设计应该是即使遇到错误数据事件或者错误操作时也能平滑过渡。设计不是编码编码不是设

21、计设计应该在创建时评价其质量而不是创建之后设计应该经过评审，减少语义错误,组件划分准则,要求的抽象等级依赖于实际的问题环境和解决方案定位（例如，实施的接近性）要求的架构描述结构化的/功能化的/动态的（例如，外部事件依赖等）取得竞争优势可以使用的现有和未来的产品技术要求的控制层次,信息隐藏比如在一个组件内部的数据和过程，对于其他的组件不可访问要求内聚的程度（例如，单个任务的关注的范围限制在每个组件的内部）组件之间必要的偶合程度现有近似产品的架构,4+1View,逻辑视图：描述系统/软件架构以支持功能需求。开发视图：在开发环境中描绘出软件的静态结构 过程视图：描述系统/软件架构以支持非功能需求，例如并发性、同步性、系统集成性、容错性和可用性。物理视图：软件到硬件的映射以及分布的样子。,回顾,以上我们介绍了：CMMI中技术解决方案过程域的SG 标准过程体系中技术解决方案所含任务 技术解决方案的关键技术,