软件开发管理平台关键技术专项方案.docx
- 文档编号:13610148
- 上传时间:2023-06-15
- 格式:DOCX
- 页数:13
- 大小:202.52KB
软件开发管理平台关键技术专项方案.docx
《软件开发管理平台关键技术专项方案.docx》由会员分享,可在线阅读,更多相关《软件开发管理平台关键技术专项方案.docx(13页珍藏版)》请在冰点文库上搜索。
软件开发管理平台关键技术专项方案
软件开发管理平台技术方案
随着软件应用水平提高,软件规模越来越庞大,软件开发过程日益复杂,而软件开发模式仍旧停留在老式以技术人员为核心方式下,不可避免会暴露出许多问题:
∙没有完善对需求变更及问题追踪流程和管理手段
当前对需求变更及问题追踪流程没有完善管理办法及有效管理手段。
对于业务人员、运维人员提出各种需求和缺陷以及系统问题没有一种管理机制和经验积累。
∙无法保证发布版本完整性
没有完善内部产品版本控制、发布、上线、运维、变更管理体系,无法记录和追踪需求、产品、文档、流程变更过程,这样导致直接后果是无从判断项目版本状态,系统故障诊断难度加大。
容易发生开发人员XX修改代码或文档,留下系统故障隐患。
∙缺少沟通,难于控制项目状态
项目开发过程中各部门之间,各部门与集成商之间缺少有效沟通手段,无法实现流程自动化操作。
无法记录完整管理信息,导致各级领导、业务人员和项目管理者,没有办法及时、自动地理解项目管理状态,量化内部项目人员及供应商项目构成员工作量,工作进度。
本技术方案书针对当前软件公司开发团队普遍面临问题,通过制定一种自动化、可管理、可追踪流程,提供一种高度协作化方式,迭代化、增量方式开发手段,在最低费用状况下及时生产满足需要高质量软件。
从而达到IT和业务目的紧密结合,并引导业务创新和发展。
为了建立敏捷开发流程,达到IT和业务目的紧密结合,并引导业务创新和发展,必要建立一种能从需求人员、项目经理、开发人员、配备管理人员到测试团队端到端流程,并且这个流程必要自动化、可管理并且可追踪。
∙流程需要保证项目连贯性
∙保证随时可以得到项目状态
∙流程需要多次循环
∙保证闭环流程
∙保证质量问题被预先发现和解决
∙需要和已有工具集成(配备管理、测试)
在本方案中咱们会使用一种“漏斗”模型,将信息部门面临成千上万问题通过流程梳理,分类、排序,最后形成各个角色寻常工作工作任务,使得对的人在对的时间做对的工作。
从而保证信息部门工作有条不紊,系统上线胸有成竹。
下图所示为流程分类模型。
该流程涉及:
问题管理
∙由业务部门或任何使用IT系统部门提交有关问题,如系统使用问题、网络问题、改进祈求等。
这些问题也许是由于业务人员不熟悉系统,或是系统没有提供以便使用方式,或是系统一种缺陷等
需求管理
▪需求改进或新增需求申请,由业务部门提出或由于新技术产生而对系统产生改进规定,由专门需求小组提出并分析
缺陷管理
▪系统上线后由业务部门提交问题经确认是系统缺陷,或测试人员在产品上线前在测试过程中发现软件缺陷
测试管理
▪验证软件系统与否和完整实现了需求并且满足性能规定,可以持续地,自动地进行回归测试
上线管理
▪保证上线版本有效性、可靠性并进行过相应审批过程。
流程管理是软件开发管理平台集线器(HUB),通过将所有人员工作统一有序管理之后,咱们可以在不同流程环节集成不同工具。
从而将所有人员寻常工作内容通过流程驱动,并将有关数据自动纳入流程管理范畴,为量化管理、量化分析提供信息来源,从而形成不断流程改进源泉。
除了流程以外,软件开发管理平台还需要三个重要工具配合集成使用:
需求管理工具、配备管理工具和测试管理工具。
需求管理工具:
▪无论开发何种产品,需求仍是驱动开发进程重要因素,需求管理粒度决定了软件交付周期和质量。
在软件开发过程中,环绕需求重要进行需求定义和分析、需求跟踪、需求变更这三方面工作。
配备管理工具:
▪在实现需求或需求改进或是修复缺陷时,咱们普通会修改源代码、测试脚本、设计文档、操作手册等。
第一代配备管理工具支持基于文献(FileBased)版本控制、支持check-out/check-in模型和简朴分支。
通过流程驱动将配备管理推向最先进基于项目库和活动配备管理。
通过抽象层次提高简化了软件开发,从而使得软件开发团队从更高层次依照活动(activity)来管理变更。
一种开发活动可以自动地同其变更集(封装了所有用于实现该活动项目工件)有关联,这样避免了管理人员手动跟踪所有文献变更。
测试管理工具:
▪在测试管理中可以进行测试筹划、测试设计、测试实现、测试执行并得到测试报告。
在测试实现中会将设计好测试用例用测试工具(功能测试、手工测试和其她测试工具)进行实现,如录制,脚本修改等。
当关联了测试用例及测试实现后,即可通过测试管理流程调用测试工具执行测试,同步将测试成果收录在流程中提供后期分析,通过集成不同测试工具,可以统一测试流程建立公司级测试规程。
流程分析
1问题管理
问题管理,负责解决从业务部门或任何系统使用人员提出问题,该流程可以提供一种SERVICEDESK能力,是联系业务部门和IT部门纽带。
动作
动作描述
负责人
状态
提交
提交问题,输入问题描述、系统、紧急限度等
系统使用人员
已提交
打开
系统支持人员开始解决该问题
系统支持人员
已打开
解决完毕
通过电话或现场支持解决问题,非系统问题,如使用人员使用不当、网络问题等
系统支持人员
已解决
接受
问题提交人员确认问题已经被解决
问题提交人
已关闭
提交缺陷
解决人员发现是系统缺陷,提交一种缺陷记录并等待解决,此时该问题解决在“已打开状态”,并且可以看到有提交缺陷有关联,该问题如果有”WORKAROUND”方式可以提供应使用人员,在提交人接受前提下可以关闭,否则需等待缺陷解决后才干关闭
系统支持人员
已打开
提交需求变更
解决人员发现该系统功能设计不合理或是该问题会引起其她需求,此时可以提交需求变更祈求。
该问题如果有”WORKAROUND”方式可以提供应使用人员,在提交人接受前提下可以关闭,否则需等待需求变更解决后才干关闭
系统支持人员
已打开
2需求管理
需求管理,涉及新建需求和需求改进。
通过需求流程,可以协助需求分析小组审核、分析并且对需求进行优先级排序,拟定需求在哪个阶段(版本)中实现,并通过度派给相应开发人员,可以从需求提交始终追踪到完毕。
动作
动作描述
负责人
状态
提交
提交需求,输入需求描述、影响大小等
系统使用人员
已提交
审核
确认该需求需要实现并拟定实现版本
需求审核组
已审核
设计
对需求进行分析和设计,拟定需求实现办法,在此阶段会分析该需求对系统影响,涉及与否会影响系统架构,由此定义该需求实现难度、日期、人员等
需求分析组
已设计
分派
项目经理依照需求设计分派相应人员
项目经理
已分派
打开
表达开始实现该需求
开发人员
已打开
完毕
完毕该需求并已通过开发人员自我测试
开发人员
已完毕
验证
对该需求进行接受测试并验证通过
测试人员
关闭
回绝
没有验证通过,告知开发人员重新开发
测试人员
已分派
推迟
在任意阶段都可以推迟该需求
有关人员
已推迟
分析
对某些影响较大需求需要进行进一步分析,拟定工作量与否在可控范畴
需求分析组
已分析
3缺陷管理
缺陷管理,保证系统每一种缺陷都被流程所管理。
项目经理通过对需求状态分析可以指引项目进展状况、稳定性趋势。
并可以定义项目上线缺陷指标拟定系统与否符合上线规定。
动作
动作描述
负责人
状态
提交
测试构成员递交一种软件缺陷
测试组
已提交
分派
项目经理分派相应开发人员予以解决
项目经理
已分派
打开
表达开始修复此缺陷
开发人员
已打开
解决
表达已经修复了此缺陷并且通过了开发人员自我测试
开发人员
已解决
验证
对该缺陷进行接受测试并验证通过
测试人员
关闭
回绝
没有验证通过,告知开发人员重新开发
测试人员
已分派
推迟
在任意阶段都可以推迟该缺陷修复
有关人员
已推迟
重复
在系统中有相似缺陷已经存在
项目经理
已重复
4测试管理
测试管理,为一种系统拟定需要测试类型,如功能测试、性能猜测等。
通过测试用例设计和实现,为每一次测试工作做好准备。
测试筹划涉及创立测试用例、测试用例生命周期管理、对测试资产组织。
测试设计涉及使用品开发测试脚本、将测试脚本与测试用例进行关联、创立测试套件。
测试执行涉及运营已配备测试用例或测试套件、察看运营过程、分析执行成果。
测试报告给测试经理一种统一报告。
当有测试祈求(一种缺陷修复、需求实现、上线前测试),都需要对系统进行一定限度测试。
下面测试流程描述了当接受到测试任务到测试结束整个过程。
动作
动作描述
负责人
状态
测试祈求
顾客接受测试或其她需要测试时提出祈求
测试经理
已提交
配备
从用例库中配备出需要测试套件
测试设计人员
已配备
实现
对经配备但未实现用例进行用例实现
测试人员
已实现
执行
执行测试
测试人员
已测试
分析
分析测试成果
测试人员
已分析
通过
如果测试通过
测试经理
已通过
提交缺陷
测试发现问题时提交缺陷祈求
测试人员
已分析
5配备管理
在流程中集成配备管理是为了更好管理开发者工作空间、实现和谐团队协作、更频繁交付和集成软件工作。
通过流程驱动将配备管理推向最先进基于项目库和活动配备管理。
通过抽象层次提高简化了软件开发,从而使得软件开发团队从更高层次依照活动(activity)来管理变更。
通过和配备管理集成可以轻松实现:
∙开发人员在共享及公共代码工件上隔离和协作;
∙将一起开发、集成和发布有关工件组按构件(component)进行组织;
∙在项目里程碑创立构件基线(baseline)并依照所建立质量原则来提高基
∙将变更组织为变更集(changeset);
∙将活动管理和工件管理集成在一起;
∙按项目来组织软件开发并支持多项目之间代码共享;
5.1团队隔离和协作
隔离不稳定变更对于将错误最小化是非常核心,但是将所有变更集成到一种所有开发团队成员均可访问公共工作区域却是团队开发环境下一种基本规定。
今天基于构件软件开发办法论广泛应用以及代码变更频率和幅度增长都规定开发团队能经常和较早地将各个开发人员工作进行集成。
以便在尽早解决也许浮现问题。
配备管理应当可以依照不同用途来建立分支,如开发人员分支,新特性分支、缺陷修复分支、新需求分支等等,从而开发团队可以依照需要建立适于自身状况分支模型,灵活实现软件配备管理流程。
上图所示是一种典型配备管理方略,四个分支定义如下(方略可以依照公司开发状况而设定):
∙DEV开发流:
私有开发流为开发人员提供了互相隔离工作空间,该空间在最开始由满足一定质量原则基线进行初始化。
开发人员使用这些私有工作空间来进行工件变更,构建和测试。
当开发人员对她们变更感到满意时,她们可以将这些变更交付(DELIVER)到INT集成流上,在交付时以活动为单位,变化了老式已文献提交方式。
为了使开发人员同其她人员进度同步,开发人员也可以用来自项目公共集成流上最新稳定基线来变基(REBASE)她们私有工作流。
开发人员可以选取什么时候进行交付和变基。
∙INT集成测试流:
事实上项目集成流充当了所有开发人员所有变更协调点。
为了更好地协调所有开发人员变更集成,引入基线(baseline)概念作为对项目进度度量。
基线是一次构建(build)或配备抽象表达,它事实上是项目一种版本,而项目是有关工件集合。
项目开发团队在开发过程期间不断地创立和提高基线。
随着不同开发人员交付变更给集成流,她们交付变更将被逐个收集到项目基线中。
随着基线构建、测试和批准,它们可以被逐渐提高到不同基线级别。
基线提高级别具备两方面功能:
第一,它使项目经理或项目管理人员可以建立软件质量原则。
由于当基线达到某种预定义质量原则时就可以被标以某种基线级别,因而项目经理可以设立项目方略,标记出在哪一种基线级别(如“通过测试”)开发人员可以执行变基操作。
第二,基线提高级别就详细开发人员应当如何同其所开发工件进行交互提供了指引。
例如,依照某条基线通过某些冒烟测试时间可以协助测试人员拟定什么时候开始测试。
∙CBET试运营流:
试运营流是运营部门为系统上线前做最后准备,可以在小范畴内运营系统(该系统版本为在INT集成流上通过测试某个版本),运营部门可以很以便拿到特定需要试运营版本,该流上不需要修改权限,当发现缺陷时可以直接提交系统缺陷。
∙CREL正式发布流:
正式发布流上存储都是正式上线系统版本,涉及紧急修复(Hotfix)。
5.2团队寻常操作
∙从项目某个基线1.0加入项目
∙查看自己负责工作任务
∙功能增强或缺陷修复(修改代码)
∙以工作任务为单位提交自己工作
∙测试人员在集成流上做集成测试工作
∙通过测试后可以创立新基线2.0
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 管理 平台 关键技术 专项 方案