软件开发管理平台技术方案

1、软件开发管理平台技术方案随着软件应用水平的提高，软件规模越来越庞大，软件开发的过程日益复杂，而软件开发的模式依旧停留 在传统的以技术人员为核心的方式下的，不可防止的会暴露出许多问题：没有完善的对需求变更及问题追踪的流程和管理手段目前对需求变更及问题追踪流程没有完善的管理方法及有效的管理手段。对于业务人员、运维人 员提出的各种需求和缺陷以及系统问题没有一个管理机制和经验积累。无法保证发布版本的完整性没有完善的内部产品版本控制、发布、上线、运维、变更的管理体系，无法记录和追踪需求、产 品、文档、流程的变更过程，这样造成的直接后果是无从判断工程版本状态，系统的故障诊断难 度加大。容易发生开发人员未经

2、授权修改代码或文档，留下系统故障隐患。缺乏沟通，难于控制工程状态工程开发过程中各部门之间，各部门与集成商之间缺乏有效的沟通手段，无法实现流程的自动化 操作。无法记录完整的管理信息，造成各级领导、业务人员和工程管理者，没有方法及时、自动 地了解工程管理状态，量化内部工程人员及供给商工程组成员工作量，工作进度。本技术方案书针对目前软件公司开发团队普遍面临的问题，通过制定一个自动化、可管理、可追踪的流程,提供一种高度协作化方式的，迭代化的、增量方式的开发手段，在最低费用的情况下及时的生产满足需要 的高质量软件。从而到达和业务目标紧密结合，并引导业务的创新和开展。为了建立敏捷的开发流程，到达和业务目标

3、紧密结合，并引导业务的创新和开展，必须建立一个能从需求 人员、工程经理、开发人员、配置管理人员到测试团队的端到端的流程，并且这个流程必须自动化、可管 理并且可追踪。在本方案中我们会使用一个“漏斗模型，将信息部门面临的成千上万的问题通过流程梳理，分类、排序,最终形成各个角色日常工作的工作任务，使得正确的人在正确的时间做正确的工作。从而保证信息部门的 工作有条不紊，系统上线胸有成竹。下列图所示为流程的分类模型。流程需要保证工程的连贯性保证随时可以得到工程状态流程需要屡次循环确保闭环的流程确保质量问题被预先发现和解决需要和已有的工具集成配置管理、测试u 神土朝如成MAS该流程包括:问题管理?由业务部

4、门或任何使用系统的部门提交的相关问题，如系统使用问题、网络问题、改良请求等。这些问题可能是由于业务人员不熟悉系统，或是系统没有提供方便的使用方式，或是系统的一个 缺陷等需求管理? 需求改良或新增需求申请，由业务部门提出或由于新技术的产生而对系统产生的改良要求，由专 门的需求小组提出并分析缺陷管理? 系统上线后由业务部门提交的问题经确认是系统缺陷，或测试人员在产品上线前在测试过程中发 现的软件缺陷测试管理? 验证软件系统是否和完整实现了需求并且满足性能要求，可以持续地，自动地进行回归测试上线管理? 保证上线版本的有效性、可靠性并进行过相应的审批过程。流程管理是软件开发管理平台的集线器 ，通过将所

5、有人员的工作统一有序的管理之后，我们可以在不同的流程环节集成不同的工具。从而将所有人员日常工作的内容通过流程驱动，并将相关数据自动纳入流程 管理范畴，为量化的管理、量化的分析提供信息来源，从而形成不断流程改良的源泉。除了流程以外，软件开发管理平台还需要三个重要的工具配合集成使用：需求管理工具、配置管理工具和 测试管理工具。需求管理工具：? 无论开发何种产品，需求仍是驱动开发进程的重要因素，需求管理的粒度决定了软件交付的周期 和质量。在软件开发的过程中，围绕需求主要进行需求的定义和分析、需求跟踪、需求变更这三 方面的工作。配置管理工具：? 在实现需求或需求改良或是修复缺陷时，我们通常会修改源代码

6、、测试脚本、设计文档、操作手册等。第一代的配置管理工具支持基于文件的版本控制、支持模型和简单分支。通过流程驱动将配置管理推向最先进的基于工程库和活动的配置管理。通过抽象层次的提升简化了软件开发，从而使得软件开发团队从更高的层次根据活动来管理变更。一个开发活动可以自动地同其变 更集封装了所有用于实现该活动的工程工件相关联，这样防止了管理人员手动跟踪所有文件 变更。测试管理工具：? 在测试管理中可以进行测试方案、测试设计、测试实现、测试执行并得到测试报告。在测试实现中会将设计好的测试用例用测试工具功能测试、手工测试和其他测试工具 进行实现，如录制,脚本修改等。当关联了测试用例及测试实现后，即可通过

7、测试管理流程调用测试工具执行测试， 同时将测试结果收录在流程中提供后期分析，通过集成不同的测试工具，可以统一测试流程建立 企业级的测试规程。流程分析1问题管理问题管理，负责处理从业务部门或任何系统使用人员提出的问题，该流程可以提供一个的能力，是联系业务部门和部门的纽带。问题处理流程动作动作描述负责人状态提交提交问题，输入问题描述、系统、紧急程度等系统使用人员已提交翻开系统支持人员开始解决该问题系统支持人员已打开处理完 毕通过或现场支持解决问题，非系统问题，如使用人员使用不当、网络问题等系统支持人员已处理接受可题提交人员确认问题已经被解决1可题提交人已关闭提交缺 陷处理人员发现是系统缺陷，提交一

8、个缺陷记录并等待解决，此时该问题处理在“已翻开状态，并且 可以看到有提交的缺陷相关联，该问题如果有 方式可以提供给使用人员，在提交人接受的前提下 可以关闭，否那么需等待缺陷解决后才能关闭系统支持人员已打开提交需求变更处理人员发现该系统功能设计不合理或是该问题会引发其他的需求，此时可以提交需求变更请求。该问题如果有 方式可以提供给使用人员，在提交人接受的前提下可以关闭，否那么需等待需求变更解决后才能关闭系统支持人员已打开2需求管理需求管理，包括新建需求和需求改良。通过需求流程，可以帮助需求分析小组审核、分析并且对需求进行优 先级排序，确定需求在哪个阶段版本中实现，并通过分配给相应的开发人员，可以

9、从需求的提交一直 追踪到完成。动作动作描述负责人状态提交提交需求，输入需求描述、影响大小等系统使用人员已提交审核确认该需求需要实现并确定实现版本需求审核组已审核设计对需求进行分析和设计， 确定需求实现的方法， 在此阶段会分析该需求对系统 的影响，包括是否会影响系统架构，由此定义该需求实现的难度、日期、人员 等需求分析组已设计分配工程经理根据需求设计分配相应人员工程经理已分配翻开表示开始实现该需求开发人员已翻开完成完成该需求并已通过开发人员自我测试开发人员已完成验证对该需求进行接受测试并验证通过测试人员关闭拒绝没有验证通过，通知开发人员重新开发测试人员已分配推迟在任意阶段都可以推迟该需求相关人员

10、已推迟分析对一些影响较大的需求需要进行进一步分析，确定工作量是否在可控的范围需求分析组已分析3缺陷管理缺陷管理，确保系统每一个缺陷都被流程所管理。工程经理通过对需求状态的分析可以指导工程的进展情况、稳定性趋势。并可以定义工程上线的缺陷指标确定系统是否符合上线要求。动作动作描述负责人状态提交测试组成员递交一个软件缺陷测试组已提交分配工程经理分配相应开发人员予以解决工程经理已分配翻开表示开始修复此缺陷开发人员已翻开解决表示已经修复了此缺陷并且通过了开发人员的自我测试开发人员已解决验证对该缺陷进行接受测试并验证通过测试人员关闭拒绝没有验证通过，通知开发人员重新开发测试人员已分配推迟在任意阶段都可以推

11、迟该缺陷的修复相关人员已推迟重复在系统中有相同的缺陷已经存在工程经理已重复4测试管理测试管理，为一个系统确定需要的测试类型，如功能测试、性能猜想等。通过测试用例的设计和实现，为 每一次测试工作做好准备。却-我由厦%?%? MBMB LHLIW*LHLIW*那么试首理流程测试方案包括创立测试用例、测试用例的生命周期管理、对测试资产的组织。测试设计包括使用具开发测 试脚本、将测试脚本与测试用例进行关联、创立测试套件。测试执行包括运行已配置的测试用例或测试套 件、观察运行过程、分析执行结果。测试报告给测试经理一个统一的报告。当有测试请求一个缺陷的修复、需求的实现、上线前测试，都需要对系统进行一定程度

12、的测试。下面 的测试流程描述了当接受到测试任务到测试结束的整个过程。动作动作描述负责人状态测试请求书户接受测试或其他需要测试时提出请求测试经理已提交配置火用例库中配置出需要测试的套件测试设计人员已配置实现时经配置但未实现的用例进行用例实现测试人员已实现执行火行测试测试人员已测试分析分析测试结果测试人员已分析通过如果测试通过测试经理已通过提交缺陷测试发现问题时提交缺陷请求测试人员已分析5配置管理测试方案JPR在流程中集成配置管理是为了更好的管理开发者的工作空间、实现和谐的团队协作、更频繁的交付和集成 软件工作。通过流程驱动将配置管理推向最先进的基于工程库和活动的配置管理。通过抽象层次的提升简 化

13、了软件开发，从而使得软件开发团队从更高的层次根据活动来管理变更。通过和配置管理的集成可 以轻松实现：开发人员在共享及公共代码工件上的隔离和协作；将一起开发、集成和发布的相关工件组按构件进行组织；在工程里程碑创立构件基线并根据所建立的质量标准来提升基将变更组织为变更集；将活动管理和工件管理集成在一起；按工程来组织软件开发并支持多工程之间的代码共享；5.1 团队的隔离和协作隔离不稳定的变更对于将错误最小化是非常关键的，但是将所有的变更集成到一个所有开发团队成员均可 访问的公共工作区域却是团队开发环境下的一个根本要求。今天基于构件的软件开发方法论的广泛应用以 及代码变更频率和幅度的增加都要求开发团队

14、能经常和较早地将各个开发人员的工作进行集成。以便在尽 早解决可能出现的问题。配置管理应该可以根据不同用途来建立分支，如开发人员分支，新特性分支、缺陷修复分支、新需求分支 等等，从而开发团队可以根据需要建立适于自身情况的分支模型，灵活实现软件配置管理流程。上图所示是一个典型的配置管理策略，四个分支定义如下策略可以根据公司开发情况而设定开发流:私有开发流为开发人员提供了相互隔离的工作空间，该空间在最开始由满足一定质量标准的基线进行初始 化。开发人员使用这些私有工作空间来进行工件的变更，构建和测试。当开发人员对他们的变更感到满意 时，他们可以将这些变更交付到集成流上，在交付时以活动为单位，改变了传统

15、的已文件提交的方式。 为了使开发人员同其他人员的进度同步，开发人员也可以用来自工程公共集成流上最新的稳定基线来变基他们的私有工作流。开发人员可以选择什么时候进行交付和变基。?集成测试流：实际上工程集成流充当了所有开发人员的所有变更的协调点。为了更好地协调所有开发人员的变更集成， 引入基线的概念作为对工程进度的度量。基线是一次构建或配置的抽象表示，它实际上是工程的 一个版本，而工程是相关工件的集合。工程开发团队在开发过程期间不断地创立和提升基线。随着不同开 发人员交付变更给集成流，他们交付的变更将被逐一收集到工程基线中。随着基线的构建、测试和批准， 它们可以被逐步提升到不同的基线级别。基线提升级别具有两方面的功能：第一，它使工程经理或工程管 理人员可以建立软件质量标准。由于当基线到达某种预定义的质量标准时就可以被标以某种基线级别，因 此工程经理可以设置工程策略，标识出在哪一个基线级别如“通过测试的开发人员可以执行变基操 作。第二，基线提升级别就具体的开发人员应该如何同其所开发的工件进行交互提供了指导。例如，根据 某条基线通过某些冒烟测试的时间可以帮助测试人员确定什么时候开始测试。?试