-
软件开发管理平台技术案
随着软件应用水平的
提高，软件规模越来越庞大，软件开发的过程日益复杂，而软件开发的模式依旧停留
在传
统的以技术人员为核心的式下的，不可避免的会暴露出多问题：
?
没有完善的对需求变更及问题追踪的流程和管理手段
目前对需求变更及问题追踪流程没有完善的管理法及有效的管理手段。对于业务人员、运维人员<
/p>
提出的各种需求和缺陷以及系统问题没有一个管理机制和经验积累。
?
无法保证发布版本的完整性
没有完善
的部产品版本控制、发布、上线、运维、变更的管理体系，无法记录和追踪需求、产品、
文档、流程的变更过程，这样造成的直接后果是无从判断项目版本状态，系统的故障诊断难度加
< br>大。容易发生开发人员未经授权修改代码或文档，留下系统故障隐患。
?
缺乏沟通，难于控制项目状态
项目开
发过程中各部门之间，各部门与集成商之间缺乏有效的沟通手段，无法实现流程的自动化
操作。无法记录完整的管理信息，造成各级领导、业务人员和项目管理者，没有办法及时、自动
< br>地了解项目管理状态，量化部项目人员及供应商项目组成员工作量，工作进度。
本技术案书针对目前软件公司开发团队普遍面临的问题，通过制定一个自动化、可管理、
可追踪的流程，
提供一种高度协作化式的，迭代化的、增量式的开发手段，在最低费用的
情况下及时的生产满足需要的高
质量软件。从而达到
IT
和业务目标紧密结合，并引导业务的创新和发展。
< br>为了建立敏捷的开发流程，达到
IT
和业务目标紧密结合
，并引导业务的创新和发展，必须建立一个能从需
求人员、项目经理、开发人员、配置管
理人员到测试团队的端到端的流程，并且这个流程必须自动化、可
管理并且可追踪。
?
?
?
?
?
?
流程需要保证项目的连贯性
保证随时可以得到项目状态
流程需要多次循环
确保闭环的流程
确保质量问题被预先发现和解决
需要和已有的工具集成（配置管理、测试）
< br>在本案中我们会使用一个“漏斗”模型，将信息部门面临的成千上万的问题通过流程梳理，分类、排序，< /p>
最终形成各个角色日常工作的工作任务，使得正确的人在正确的时间做正确的工作。从而保
证信息部门的
工作有条不紊，系统上线胸有成竹。下图所示为流程的分类模型。
专业资料
该流程包括：
问题管理
?
由业务部门或任使用
IT
系统的部门提交的相关问题，如系统使用问题、网络问题、改进请求等。
这些问题可能是由于业务人员不熟悉系统，或是系统没有提供便的使用式，或是系统的一
个缺陷
等
需求管理
?
需求改进或新增需求申请，由业务部门提出或由于新技术的产生而对系统产生的改进要求
，由专
门的需求小组提出并分析
缺陷管理
?
系统上线后由业务部门提交的问题经确认是系统缺陷，或测试人员在产品上线前在测试过
程中发
现的软件缺陷
测试管理
?
验证软件系统是否和完整实现了需求并且满足性能要求，可以持续地，自动地进行回归测
试
上线管理
?
保证上线版本的有效性、可靠性并进行过相应的审批过程。
专业资料
流程管理是软件开发管理平台的集线器
(HUB)
，通过将所有
人员的工作统一有序的管理之后，我们可以在
不同的流程环节集成不同的工具。从而将所
有人员日常工作的容通过流程驱动，并将相关数据自动纳入流
程管理畴，为量化的管理、
量化的分析提供信息来源，从而形成不断流程改进的源泉。
除了流程以外，软件开发管理平台还需要三个重要的工具配合集成使用：需求管理工具、
配置管理工具和
测试管理工具。
需求管理工具：
?
无论开发种产品，需求仍是驱动开
发进程的重要因素，需求管理的粒度决定了软件交付的期和质
量。在软件开发的过程中，
围绕需求主要进行需求的定义和分析、需求跟踪、需求变更这三面的
工作。
配置管理工具：
?
在实现需求或需求改进或是修复缺
陷时，我们通常会修改源代码、测试脚本、设计文档、操作手
册等。第一代的配置管理工
具支持基于文件（
File
Based
）的版本控制、支持
check-
out/check-in
模型和简单分支。通过流程驱动将配置管理推向最先进的基于
项目库和活动的配置管理。通过抽
象层次的提升简化了软件开发，从而使得软件开发团队
从更高的层次根据活动（
activity
）来管理
变更。一个开发活动可以自动地同其变更集（封装了所有用于实现该活动的项目工件）相关联，
这样避免了管理人员手动跟踪所有文件变更。
测试管理工具：
?
在测试管理中可以进行测试计划、
测试设计、测试实现、测试执行并得到测试报告。在测试实现
中会将设计好的测试用例用
测试工具（功能测试、手工测试和其他测试工具）进行实现，如录制，
脚本修改等。当关
联了测试用例及测试实现后，即可通过测试管理流程调用测试工具执行测试，
同时将测试
结果收录在流程中提供后期分析，通过集成不同的测试工具，可以统一测试流程建立
企业
级的测试规程。
流程分析
1
问题管理
问题管理
,
负责处理从业务部门或任系统使用人员提出的问题
，
该流程可以提供一个
SERVICEDESK
的能力，
是联系业务部门和
IT
部门的纽带。
专业资料
动作
动作描述
负责人
状态
系统使
已提
用人员
交
打开
系统支持人员开始解决该问题
系统支
已打
持人员
开
处理完
通
过或现场支持解决问题，非系统问题，如使用人员使用不当、网络问题等
毕
接受
问题提交人员确认问题已经被解决
系
统支
已处
持人员
理
问题提
已
关
交人
闭
提交
提交问题，输入问题描述、系统、紧急程度等
提交缺
处理人员发现是系统缺陷，提交一个缺陷记录并等待解决，此时该问题处
理在“已打开状态”，并且
系统支
已打
陷
可以看到有提交的缺陷相关联，该问题如果有”
WORKAROUND
”式可以提供给使用人员，在提交人
持人员
开
接受的前提下可以关闭，否则需等待缺陷解决后才能关闭
提交需
处理人员发现该系统功能设计不合理或是该问题会引发其他的
需求，此时可以提交需求变更请求。
等待需求变更解决后才能关闭
2
需求管理
需求管理
< br>,
包括新建需求和需求改进。通过需求流程，可以帮助需求分析小组审核、分析并
且对需求进行优
先级排序，确定需求在哪个阶段（版本）中实现，并通过分配给相应的开
发人员，可以从需求的提交一直
追踪到完成。
系统支
已打
求变更
该问题如果有”
WORKAR
OUND
”式可以提供给使用人员，在提交人接受的前提下可以关闭，否则需
持人员
开
专业资料
动作
提交
审核
设计
动作描述
提交需求，输入需求描述、影响大小等
确认该需求需要实现并确定实现版本
对需求进行分析和设计，
确定需现的法，
在此阶段会分析该需求
对系统的影响，
包括是否会影响系统架构，由此定义该需现的难度、日期、人员等
分配
打开
完成
验证
拒绝
推迟
分析
项目经理根据需求设计分配相应人员
表示开始实现该需求
完成该需求并已通过开发人员自我测试
对该需求进行接受测试并验证通过
没有验证通过，通知开发人员重新开发
在任意阶段都可以推迟该需求
对一些
影响较大的需求需要进行进一步分析，确定工作量是否在可控的围
项目经理
开发人员
开发人员
测试人员
测试人员
相关人员
需求分析组
已分配
已打开
已完成
关闭
已分配
已推迟
已分析
负责人
系统使用人员
需求审核组
需求分析组
状态
已提交
已审核
已设计
3
缺陷管理
缺陷管理
< br>,
确保系统每一个缺陷都被流程所管理。项目经理通过对需求状态的分析可以指导
项目的进展情
况、稳定性趋势。并可以定义项目上线的缺陷指标确定系统是否符合上线要
求。
专业资料
动作
提交
分配
打开
解决
验证
拒绝
推迟
重复
测试组成员递交一个软件缺陷
项目经理分配相应开发人员予以解决
表示开始修复此缺陷
表示已经修复了此缺陷并且通过了开发人员的自我测试
对该缺陷进行接受测试并验证通过
没有验证通过，通知开发人员重新开发
在任意阶段都可以推迟该缺陷的修复
在系统中有相同的缺陷已经存在
动作描述
负责人
测试组
项目经理
开发人员
开发人员
测试人员
测试人员
相关人员
项目经理
状态
已提交
已分配
已打开
已解决
关闭
已分配
已推迟
已重复
4
测试管理
测试管理，为一个系统确定
需要的测试类型，如功能测试、性能猜测等。通过测试用例的设计和实现，为
每一次测试
工作做好准备。
专业资料
测试计划包括创建测试用例、测试用例的生命期管理、对测试资产的组织。测试设计包括
使用具开发测试
脚本、
将测试脚本与测试用例进行关联、
创建测试套件。
测试执行包括运行已配置的测试用例或测试套件、
察看运行过程、分析执行结果。测试报告给测试经理一个统一的报告。
当有测试请求（一个缺陷的修复、需求的实现、上线前测
试），都需要对系统进行一定程度的测试。下面
的测试流程描述了当接受到测试任务到测
试结束的整个过程。
动作
测试请求
配置
实现
执行
分析
通过
提交缺陷
专业资料
动作描述
用户接受测试或其他需要测试时提出请求
从用例库中配置出需要测试的套件
对经配置但未实现的用例进行用例实现
执行测试
分析测试结果
如果测试通过
测试发现问题时提交缺陷请求
负责人
测试经理
测试设计人员
测试人员
测试人员
测试人员
测试经理
测试人员
状态
已提交
已配置
已实现
已测试
已分析
已通过
已分析
-
-
-
-
-
-
-
-
-
上一篇：思科路由器BFD配置命令详解
下一篇：DMA 网卡零拷贝实现的设计与