项目过程管理国内外研究现状
项目过程管理国内外研究现状20研究生论文用项目过程管理国内外的研究现状!谢谢,不要单纯项目管理的急用,谢谢...研究生论文用 项目过程管理国内外的研究现状!
谢谢,不要单纯项目管理
急用,谢谢展开
现状研究,只能就工具方面给你参考了。原文地址:http://www.cloudtopo.com/corp/integrated-develop-platform.html

集成化的研发协作平台发展趋势
研发协作平台正在向高度集成化方向发展,在2008年6月份左右,作为企业研发协作平台的业界老大IBM,向全球软件客户强力推出了他们的下一代面向软件交付技术的研发协作平台Jazz,IBM 力图在不久的将来将IBM Rational的所有产品都逐步迁移到Jazz新平台下。高度集成化研发活动的各种点工具正成为集成化研发协作平台的一个新趋势。希望本文能够给读者了解集成化研发协作平台带来一些帮助。
在具体分析集成化的研发协作平台之前,我们先来了解一下绝大多数软件研发团队的一个典型工作情景:

软件开发人员通过代码走查活动发现一个BUG,他需要将这个BUG记入缺陷跟踪系统;另外一个开发人员(代码的作者)需要根据这个缺陷汇报修改好代码提交到版本库中;版本经理发布一个测试版本,需要知道这次版本中包含了这次修改;测试人员在拿到该版本后需要对这个BUG导致的代码修改设计针对性的测试用例,这个测试用例可能是自动测试用例,也可能是人工测试用例,总之测试人员需要在测试管理系统来记录这个BUG修改的验证过程;一切就绪后,版本经理向客户发布版本时还需要提供release notes以指明该版本中的这个改动(假设该BUG对用户可见)。到此,对于多数研发团队来说好像工作已经结束了,但是对于复杂系统的开发团队而言工作还远没结束!代码走查发现的所有BUG,应该被QA仔细分析原因,如果是典型问题,还需要将该问题写入开发经验库,并通过知识共享的形式分享给所有团队成员;一个开发人员的代码如果被统计出问题较多,还应该对该开发人员开发的代码采取补救和预防措施,要么加强测试,要么给他一些培训,要么他根本不适合这个职位应该走人;对于这个开发人员的上司,他应该如何评价这个犯错的下属,因为几个BUG就认为他的工作不称职显然是不正确的,还有他如何衡量这个开发人员的工作量,是否是该员工工作量太多导致了该员工的代码质量不高?他还想知道该员工在引入这个BUG时当时的工作任务是否过于紧迫? 当然,他也可能想分析一下这个典型的BUG引入会导致多少额外的工作量产生?

好复杂!是的,这就是研发工作的特点!如果仔细分析上面的活动过程,这些工作的背后涉及到的点工具(point tool)不下10个,而这一切都只是因为一个开发人员的某行代码有一个BUG触发的。没有一个对各种点工具进行高度整合的协同系统,这个工作的触发源信息将在很多地方断裂,而在很多环节,我们又不能让这个信息链断裂,例如测试工作就不应该忽略掉任何代码修改,于是唯一的方法就是通过低效率的手工劳动来弥补这些断裂的信息,但却也为此付出了不少代价。而在整合良好的研发协作系统中,这个信息链条应该尽可能自动或者每个工作环节付出极小的代价就可以被良好的维持,并根据维持好的信息链,让所有人的工作协同起来,并让所有研发工作做到可追踪,可分析,可度量,从而更好的协助团队持续进行过程改善,并最终帮助团队走向卓越。这样的研发协同系统即是下一代的研发协作系统的发展趋势,我们称之为集成化的研发协作平台。

什么是集成化的研发协作平台?
所谓集成化的研发协作平台,即是将研发生命周期中的各个阶段的活动涉及的点工具高度集成到一个统一的管理系统平台下,从而可以更好地协助研发团队更加高效率地开展研发活动。集成化研发协作系统有以下几个特点:
首先它是一个研发活动管理平台。

既然是一个管理平台,设计良好的集成化研发协作系统需要提供各种研发活动的工作流支持,这里说的工作流可小可大。小到如发起一个请假,然后经理审批一下这种两个状态节点的流程实例,也可能是类似一次正规代码走查这种从“发起- 专家检视- 问题确认- 问题跟踪- 关闭”这种多状态的流程,值得一提的是,作为一个协作平台应该具有流程定制的能力,即系统应该可以通过二次开发或用户定制的方式为不同类型的研发团队提供不同工作流支持。离开了工作流,就不能称之为协同平台,充其量只能算是一组工具而已。

其次是它需要集成研发各个阶段的点工具。集成端到端的各种点工具,是集成化研发协作平台的一个必要条件。例如,对于研发工作涉及到的通用点工具就包括:需求管理工具,任务管理工具,文档管理工具,技术分享工具,技术讨论工具,评审工具,工时统计工具等,具体到软件开发团队,涉及到的点工具还进一步包括:单元测试工具,代码查看工具,代码走查工具,版本管理系统,自动构建系统,持续集成系统等;具体到测试团队,就包括测试系统和自动测试系统等;具体到硬件开发团队来说,涉及到的点工具就包括:PCB设计工具,研发物料管理工具,BOM管理工具等。一个集成化的研发协作系统,要么在系统中直接实现这些支撑研发活动的点工具,要么与业界已有的各种优秀的点工具紧密集成,从而可以让开发人员在工作中通过组合应用这些点工具来高效率地完成单个独立工具所不能完成的工作。

最后它应该是对集成的点工具进行高度整合。下一代的集成化研发协作平台,是通过对各种点工具进行高度整合以实现各种研发活动无缝集成的系统。简单整合各种工具系统并不困难,举个简单的例子,有些系统提供一个项目工作面板,将一些点工具的状态即时呈现到该项目工作面板中,如自动构建的状态,当前项目的任务燃尽图或甘特图,当前项目的缺陷情况分布情况。即使类似于项目工作面板这种简单的各个点工具的状态整合,已经能够给项目带来不少帮助,甚至成为很多研发管理系统的一个卖点。但是仅仅做到各个点工具的状态的汇集还远远不够。如本文最前面描述的软件团队的典型工作场景所示,任何一个活动环节的过程信息都应该尽可能靠集成化的研发协作系统自动维持以减少手工维持信息的代价,从而更加高效地开展研发活动。

典型研发集成化协作平台

下面介绍几个具有代表性的集成化研发协作平台,这些系统都是商业系统,设计思路上基本满足上面的三个条件。当然,作为下一代的协作平台的代表,这些系统大都推出不久,很难说得上完善,离上面所讨论的也还有不少差距,然而随着这些系统不停改进,相信在不久的将来就会有一些成熟的集成化研发协作平台出现在所有研发工作者面前。如果你有时间关注一下这些系统的发展,相信你会对下一代集成化研发协作平台的发展趋势有更深入的了解。

产品:JIRA Studio
公司: Atlassian
简介:JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。JIRA创建的问题类型包括New Feature、Bug、Task和Improvement四种,还可以自己定义,所以它也一是过程管理系统。JIRA融合了项目管理、任务管理和缺陷管理。Atlassian公司的产品分解成了多个产品JIRA(Issue tracking)、FishEye(Source Code Search)、Confluence(Enterprise Wiki)、Greenhopper(Agile Planning)、Bamboo(Continuous Integration)、Crucible(Peer Code Review),Atlassian的产品可以相互协同起来,从而构成一个面向软件交互的协作平台。
(以上信息来源于Atlassian官方网站:(http://www.atlassian.com/studio/)

产品:Jazz
公司:IBM
简介:Jazz 是 IBM Rational 面向软件交付技术的下一代协作平台。Jazz 平台专门面向全球化和跨地域团队开发,通过这一全新的平台,地理上分隔的开发人员将能互相协作,共同构建软件。从而使得软件交付实现更加协作化、高效率和无缝衔接。Jazz 是一个用于整个软件生命周期的团队协作平台,旨在支持跨所有软件生命周期阶段的任务的无缝集成。Jazz 平台不仅旨在集成现有的点工具,而且还旨在提供一个平台,在该平台上可以构建比以前更加集成的生命周期工具功能。当以这种方式在整个生命周期中集成开发工具时,使用一组结合在一起的点解决方案 (point solution) 来完成难以想象的事情将成为可能。像这样的集成端到端工具可以帮助团队更有效地构建软件,并使得软件开发活动更加令人愉快。
(以上信息来源于IBM中文官方网站:http://www.ibm.com/developerworks/cn/rational/jazz/r-jazz-what-is-jazz.html#process)

产品:Topo
公司:Cloudtopo
简介:不同于前两个面向软件交付技术的协作平台,Topo是Cloudtopo公司推出的面向整个研发管理的协作平台(涵盖软件交付技术)。该协作平台整合的面向通用研发团队的点工具支持包括需求管理工具,任务管理工具,文档管理工具,技术分享工具,技术讨论工具,评审工具,工时统计工具等,而面向软件交付领域的支持包括:版本管理,源代码库深度查看工具,代码走查工具,自动构建系统,自动测试系统,测试管理系统。面向硬件团队的工具包括:研发物料管理工具,BOM管理工具等。 TOPO研发管理系统在每一个功能设计中均注重“整合+协作+重用”的设计思路,力争将每一个功能做到贴近研发团队实际需要,为企业研发团队带来创新性的研发协同整体解决方案。

立即开始连接业务与财务数据

使用企企管理云连接业务与财务数据,帮助企业进行经营管理决策