文摘
灵活性和改变采用面向服务的体系结构(SOA)的关键属性和敏捷软件开发流程。尽管敏捷性的概念是完全可见的两边,还是两个不同概念的集成(体系结构框架和开发过程)应该雇佣他们之前认为的一个软件开发项目。为此,本研究旨在分析两种不同的软件体系结构框架和开发的方法,也就是说,SOA和Scrum流程模型,分别在软件项目开发集成环境设置的角度对工业物联网(IIoT)。这个研究还分析共性在Scrum流程模型和SOA体系结构框架来确定Scrum和SOA之间的兼容性,因此Scrum过程可以建设性地用于基于SOA项目。这项研究还考察了Scrum过程的适当的设计和设置适合大型基于SOA项目。为此,基于SOA的研究和开发项目被选中作为一个案例研究使用Scrum作为软件开发过程。项目开发和部署的角度包括八个核心模块,构成整个项目框架。
1。介绍
在当下时代的动态业务环境,灵活地欢迎改变和适应高效和成本有效的相关的任何商业组织的成功。面向服务的体系结构(SOA)是一种体系结构方法来设计、开发、管理和部署的软件应用程序和基础设施的所有应用程序的结构到业务服务网络可访问和可执行1]。灵活性和改变采用SOA和敏捷软件开发过程的关键属性。尽管敏捷性的概念是完全可见的两边,还是两个不同概念的集成(体系结构框架和开发过程)应该想到之前雇佣他们为软件开发项目(2]。因此,使用一个合适的基于SOA的应用程序开发的敏捷过程,采取重大需求修改和变化即使在应用程序构建软件优势和质量守恒定律,是至关重要的(3]。敏捷过程(基于敏捷宣言(4])倾向于关注迭代和客户建议以提高性能和允许不同需求的可预测性。敏捷软件开发(ASD)是一个系统的开发过程是开发高效、快速通过定期、频繁,完整版本允许参与者和利益相关者获得应用程序(5,6]。综述了应用程序和流程和测试通过敏捷回顾会议。通过这种方式,一个原型是发展成有用的进步和创新系统通过一个迭代和增量的过程,即是由利益相关者的反馈,基于快速连续版本的软件。
迭代压力的交付可工作的软件,提供品位和价值客户和项目。它还生产其他有关构件都是有价值的客户和项目。敏捷过程的目的是提供可行的交付在一个动态的方式。支持者认为,在敏捷过程中提供可交付成果和工作产品的主要关心的是在一个动态的方式没有强调在设计模型和文档的角度7,8]。Scrum是一种敏捷方法,这是一个标准的方式引入敏捷性由于其灵活性和坦率9]。这是一个流行的敏捷管理方法。敏捷开发的应用程序在企业周围可能是一个挑战,因为团队成员和他们的环境的复合性质(10]。Scrum过程有助于发现更好的方法来开发软件通过促进个人以及团队(11]。Scrum开发过程分为迭代,叫做冲刺,冲刺强调工作的交付产品,提供项目和客户价值(12]。Scrum,作为最常用的敏捷过程,强调经验反馈,团队自我管理,努力构建适当的测试产品在短迭代增量(13]。产品所有者,Scrum团队,在Scrum Scrum master是主要的三个角色。传统的项目经理角色的责任之间划分这三个Scrum角色(14]。Scrum master的维护团队的过程中,Scrum会议,并确保流程独秀的Scrum的所有规则和原则。Scrum团队是一个跨职能团队(在不同的领域有不同的专长)包括开发人员、设计人员、测试人员和分析师。这个团队负责整个项目,也参与发展。产品所有者的代表最终用户的利益和其他感兴趣的产品。
Scrum是基于Scrum master的定期会议,产品负责人(s),第三方开发者,开发过程讨论不同的有关问题。这些会议如下:sprint计划会议上,每日Scrum会议,sprint回顾会议,和sprint回顾会议。Sprint计划会议在每个Sprint周期的开始。在这次会议期间,产品所有者和Scrum团队定义sprint目标冲刺将尝试实现(15]。sprint的成功后将评估在sprint中对sprint回顾会议的目标。在sprint回顾会议结束时每个sprint团队演示完成功能和显示他们在sprint中完成。在sprint回顾会议,团队成员审查小组的工作方式和交互,行为方面,和提高技术技能,以便后续的冲刺速度更快,等等。
Scrum过程是一个黑盒方法,在团队和过程动态,发现在项目工作,而不灵活的方法如瀑布模型所指的白盒自然流程模型从管理的角度来看(14]。计划和后期阶段很重要,因为这些识别目标和输出在短跑。规划是至关重要的克服任何障碍在任何阶段或过程的发展。在敏捷术语,后期会议称为回顾是重要的观察过程和创建知识库通过最佳实践。图1显示了白盒和黑盒的类比过程模型的性质。
(一)
(b)
不灵活开发软件的开发方法是重量级过程。这些方法都是基于一系列连续的步骤,例如,要求解释,解决方案的结构,测试和部署。传统方法对大量文档和定义一组固定的需求在项目的开始。有各种各样的传统方法如瀑布、螺旋模型,双赢的螺旋模型,统一的过程。重量级过程需要详细的前期计划,沉重的文档,和广泛的预先设计。仍然传统方法有其效用的大型项目预定义的和相当固定的需求,尽管从业者也开始为这些项目采用敏捷方法(16]。
SOA是一种体系结构框架和方法来设计、开发、管理和部署软件应用程序。它是一种软件基础设施,所有应用程序结构化到业务逻辑被称为服务网络可执行和访问。换句话说,SOA同意集成的应用程序中,用户和现有系统变成一个灵活的体系结构,可以很容易地适应变化时,需要在系统(13]。SOA被认为是分布式应用程序开发的最佳方法之一。SOA允许重用现有系统的功能,而不是建筑再从头开始。这个特性的基于SOA的应用程序中的可重用性最大化经济效益的组织(14]。每个服务在SOA执行自主但不孤立的整体。每个服务封装了一个特定问题域逻辑。SOA的其他特性是松散耦合、服务合同,自主权,抽象,可发现性,和无状态性17]。
尽管SOA和敏捷方法一般认为与相关问题,仍然没有明确的组织的定义和设置这两种方法在单个IIoT环境。真正少的信息提供什么将会影响这个集成实现的重要因素,如生产力、质量、灵活性和创新性。
基于上述索赔和当前市场的需求,本研究分析共性在Scrum流程模型和SOA体系结构框架来确定Scrum和SOA之间的兼容性,因此Scrum过程可以建设性地用于基于SOA项目。这个研究还调查了Scrum过程的适当的设计和设置适合大型基于SOA项目。为此,基于SOA的研究和开发项目被选中作为一个案例研究使用Scrum作为软件开发过程。项目开发和部署的角度包括八个核心模块,构成整个项目框架。
本研究组织在七个部分。当前部分介绍了主要术语用于这项研究。第二部分介绍了在Scrum和SOA方法分析现有的研究深入的理解。第三部分是致力于研究设计和设置,分析SOA和Scrum和Scrum和SOA的集成。第四部分是关于集成分析;第五部分是讨论SOA和Scrum集成,而整体研究的结论和未来的工作提出了第六届和第七部分,分别。
2。文学研究
敏捷流程计划提前保养和快速发展的软件应用程序。这是通过在迭代工作(9]。反复强调的交付工作软件为客户提供价值以及该项目。迭代开发周期短,生产工作软件和其他工件有价值的客户和项目9]。敏捷流程的主要担忧是动态的方式提供可交付成果和工作产品没有强调设计模型和文档的角度(7]。
传统开发过程的专家得出结论,当文档和分析过程是被忽视的,它会导致企业丧失记忆,尤其是复杂和大型的软件开发。但是敏捷的专家确认,遵循敏捷软件开发全球软件交付,导致更好的结果在获得有关目标(18,19]。很明显,组织将不得不面对一些挑战在协调和集成灵活性和全球服务交付,但也使组织能够提供快速和无错误的软件,满足业务需求(20.]。
介绍了敏捷软件开发方法提供答案有关商界要求轻质、更迅速、更灵活的软件开发方法(21]。因此,敏捷开发方法是专门为敏捷,敏捷,渴望发展(22]。根据牛津字典,敏捷过程投入的重要性被敏捷,意愿的运动,在运动灵活,活动,和技巧12]。一些敏捷方法的极限编程和Scrum承认客户满意度可以通过关注流程的明度(12]。
Scrum是一种敏捷管理方法最常用。根据最后三敏捷调查,采用Scrum强调经验反馈,团队自我管理,努力构建全面测试产品在短迭代增量(23,24]。Scrum是一种敏捷方法的最标准的方法引入敏捷性由于其灵活性和坦率和一个受欢迎的管理敏捷方法在工业。敏捷软件开发过程促进更好的方法来开发软件通过促进个人工作以及团队合作(11]。敏捷流程计划保持早期和快速发展的软件应用程序。这是通过将开发过程划分为冲刺,冲刺强调在工作的交付产品,提供价值的项目和客户25]。敏捷开发的应用程序在企业周围的复合性质可能是一个挑战,因为团队成员和他们的环境(11]。
SOA同意的集成应用程序、用户和现有系统到一个灵活的体系结构,可以很容易地适应变化时需要一个系统(14]。SOA被认为是一个最好的方法为分布式应用程序开发(26]。SOA允许重用现有系统的功能而不是再次从头开始27]。这个特性基于SOA的应用程序中的可重用性最大化经济利益的组织。每个服务在SOA执行自主,但从整个系统不是孤立的。每个服务封装了一个特定问题域逻辑。SOA的主要特点是可重用性,松散耦合、服务合同、自主性、抽象,可发现性,和无状态性28]。
研究人员和专业人士有一个混合的意见相似度和兼容性的两种方法。批评者强调SOA和敏捷方法之间的区别,认为SOA和敏捷是站在不同的发展方向:SOA架构和敏捷方法(24,26];SOA在自上而下的方式工作,而敏捷本质上是一种自底向上的方法(29日,30.]。SOA是一种体系结构框架和遵循的原则,而敏捷流程模型和工作实践水平(31日]。基于这种观点,支持者的SOA和敏捷集成显示相结合的一种方法是使用SOA框架和指导原则的敏捷实践服务开发(32,33]。一些研究人员还声称,基于SOA的系统开发和部署不同于传统系统(21]。也有很多挑战等利益相关者的参与,业务和IT的对齐,和重用资产。为了克服这种类型的问题,更好地整合敏捷性和面向服务是(34,35]。值得注意的是,Scrum和SOA分享类似的担忧,如响应变化,新的工作方式,灵活性,和业务理解36]。
SOA和Scrum技术评估和规范需要注意的因素以及它们之间的关系,组织相关业务(37)和消费者个人信息。等需求的灵活性和易用性等方面的定义类型的系统特性,可以测量和设计38,39]。
3所示。设计基于SOA和Scrum IIoT环境
Scrum开发过程和SOA作为一种体系结构框架处理类似问题,例如,灵活性和快速响应变化与深厚的业务方向。尽管这固有的操作相似相当明显,仍然没有足够的研究已经取得了在分析最优的解决方案的集成这两种方法来获得合并后的好处(40,41]。同时,需要调查的影响采用SOA对于提高生产力和有效利用的时间和资源使用Scrum方法。
调查这种情况下,一个案例研究已经被选择,Scrum流程模型作为开发方法的发展一个基于SOA的软件系统。基于SOA项目命名m4(矿产资源、映射建模和管理系统)。项目开发和部署的角度包括八个核心模块,构成整个项目框架。系统后,系统的开发步骤,详细讨论了在接下来的段落。
本研究评估通过识别、确定和使用最好的组合在软件工程中,设计基于SOA,使用高效开源框架和工具,通过敏捷开发方法,开发和部署客户端和云应用程序的组合。
Scrum一直作为敏捷过程不断发展和改进后改变要求细化工作原型迭代(42,43]。使用SOA应用程序的目的是确保案例研究系统模块可以通过服务接口作为独立的子系统。SOA促进利用Scrum和SOA的特征和功能集成、定制和绑定所需的设计框架和工具,矿产资源的映射,建模和管理系统(m4);最终这个系统基础设施的部署阶段互动沟通的性质,服务的可伸缩性和可靠性。
这些部署需求通过云基础设施和分布式计算。开发应用程序的模块被设计用来作为可互操作的服务,可以单独使用并重新组合成其他模块导致多个相干模块的集成。数据银行矿产、资源和应用程序来管理这些数据银行专门为m4设计系统。这些数据库,库和应用程序设计作为开源工具。
Scrum方法用于确保有一个透明的m4的分析和设计过程和利益相关者的参与,也确保了项目的不同组件之间的动态交互。使用敏捷和开源系统(OSS)开发和项目管理原则允许针对不同社区的利益相关者通过多边联络的学术界,政府和行业。这些不同的合作演员扮演了主要角色在m4开发中,连同个人贡献者的次要角色。
讨论在信息通信技术研发项目命名m4 (https://www.openm4s.org),m4的核心框架利用开源库,服务、服务器、应用程序、数据库管理系统,和一个开源企业资源规划(ERP)如图2。客户机-服务器体系结构和基于浏览器的客户端是基于的原则和开放标准的互操作性。图还显示了组件和信息流在m4。
Scrum-driven敏捷软件开发方法是用于管理和组织发展的模块(15]。Scrum在这个案例研究中使用指定的角色和团队组织在以下部分:流程设置决定根据敏捷Scrum的规范。下面是一个简短的描述角色,因为这些在Scrum过程存在和工作环境。(一)Scrum master的Scrum会议,维护团队的流程,并确保流程方面所有Scrum的原则(44,45]。(b)Scrum教练也促进会议,帮助团队达成共识,并负责质量方面的开发环境和团队。(c)Scrum团队是一个跨职能团队由开发人员、测试人员、架构师和分析师。这个团队负责项目结果作为一个整体和全面参与开发。团队负责开发功能根据质量和功能需求46]。(d)产品负责人是一个人代表了最终用户和股东的利益。产品所有者负责质量方面与用户需求相关。一个典型的sprint周期呈现在图3。
3.1。m4过程的团队组织
团队组织的m4过程如表所示1为项目的发展。产品所有者提供路线图、业务用例、发布计划,和建筑的方向。Scrum master的知识体系结构框架,使用上下文的需求和m4的特性。他们进行业务分析和质量保证任务,除了管理sprint周期。
关键项目中每个成员的角色和责任如下:PD(项目总监)负责规划、监控和管理项目活动。Co-PD (coproject总监)负责监控项目活动,建立联络,协调与政府和工业合作伙伴。软件和计算机系统专家负责指导软件架构设计和质量保证。工程管理专家负责指导项目管理和质量保证活动。团队领导负责调度和执行设计、开发和部署的任务。开发团队负责开发、测试验证和文档的模块。Coproject主任负责保持联络和协调与政府和工业合作伙伴。矿业和软件专家(兼职)负责m4及其模块的测试和验证。导师(学生主管)负责监督和指导UG和PG的学生,在m4相关项目工作。兼职开发人员负责开发、测试和验证的模块。被监禁者正致力于各种特性的m4作为他们的研究项目和分配的项目开发和记录。
工作分解结构(WBS),以及为每个块活动负责人员,m4的项目如图4。
以下是Scrum过程的细节和它的不同特性应用于该项目。(一)用户故事一个用户故事捕获用户想要通过系统实现什么目标。这一目标转换成用户故事从客户的角度来看47]。按照用户故事,验收测试卡是由产品负责人(项目总监和导演)和开发人员实现那些故事。验收测试卡包含一组测试用例实现的用户故事的测试。一个用户故事将被视为完成只有在验收测试是令人满意的。一旦准备好了,用户故事变成了系统特性(17]。一个特性的意思是“工作要做”或一块功能系统中实现。在m4项目中,单个特性被分解成更小的任务。然后故事卡片设计为每个单独的任务。一项任务的完成时间是建议从五到十五个工作日,和通常由八小时工作日。通常一个或两个团队成员正在一次只有一个故事卡片。每个故事或任务分配优先级根据其重要性。团队成员选择的故事,他们的首要任务基本完成。图5描述了两个故事之前完成下一个故事的选择。(b)冲刺根据Scrum过程,发展分为两个——或者four-week-long时期称为冲刺。sprint是实现定时开发迭代中选择任务(37]。任务被分配到sprint在sprint计划会议在每一次冲刺的开始阶段基于订单的状态。一周sprint(也称为sprint 0)建议开始前m4项目发展。这允许开发人员熟悉开发环境,技术解决方案和现有组件的重用。第一个模块的m4完成七个冲刺。第一冲刺由总9的故事,在这七个故事在冲刺完成时间框,而剩下的两个故事都包含在第二个冲刺下完成。每个sprint的目的是在Microsoft Excel表,其中包含关于每个故事的所有信息,团队成员在一个特定的故事,时间需要完成一个特定的故事,等等。图6描述了第一个sprint作为示例如下。
Scrum方法论是基于产品负责人定期会议,Scrum团队,第三方,Scrum master讨论/应计在开发时间面对不同的问题。会议举行的目的是确保项目平稳运行和维护/维护的整体质量阶段开发系统。Scrum流程模型采用五种会议daily Scrum会议,sprint回顾会议,sprint回顾会议,sprint计划会议,和sprint发布会议。这五个会议也在m4和维护实现在不同的情况下。这些会议将一个接一个在以下小节讨论。
3.1.1。Sprint计划会议
总共七个sprint计划工作会议已经完成sprint。通常每两周后举行的一次会议。在这次会议期间,Scrum团队和产品所有者(m4项目主管&监视点)定义“疾跑”目标。sprint的成就是后评价在sprint回顾会议。产品负责人工作优先考虑故事卡片,来描述优先级最高的故事指向Scrum团队。最后,Scrum团队需要准备sprint计划和sprint backlog细节所花费的时间(做这工作48]。
3.1.2。每日例会
每日Scrum会议举行,它的主要目的是确保应用程序的功能是实现根据计划议程。这次会议通常发生在每个sprint工作的起始时间和持续约20到35分钟。会议安排在精确的固定时间。在这个会议上,每个成员的团队将成功回答三个问题:(我)什么,你做了多少工作了从昨天?(2)今天的工作计划是什么?(3)是什么将防止实现目标的障碍?
如果有任何问题发生,那么团队领导者的责任(正式称为Scrum团队)来简化并解决这些并发症。尚未解决的问题是rediscussed在另一个会议。这次会议是在同一个地方举行,同时,对于相同的时间。
3.1.3。“疾跑”审查会议
这次会议是在每个sprint之后举行。在此次会议中,团队成员显示他们都做了什么,取得了在完成sprint。通常,这个会议发生在最近研制的示范的形式特征。在m4项目中,Scrum团队已经完成了至少95%的产品待办事项列表获取故事点冲刺,和团队取得了大部分的“疾跑”目标。在每个模块的m4项目中,98%的特性,满足“完成”标准接受并标记为完成。剩下的2%的功能不完全指定的改期未来短跑冲刺。项目总监(产品所有者)是由98%满意的完成;然后功能关闭,下一个待办事项列表是更新,包括功能需要进一步发展。(一)每个sprint的已经完成的故事是接受m4项目总监和coproject导演(产品负责人)。(b)完成的功能是接受项目负责人在会议期间。(c)所有的验收测试竞选冲刺有关的故事。(d)整个代码是通过代码审查的过程。(e)没有找到关键缺陷的缺陷积压。(f)所有完成的故事点释放被接受。(g)产品测试正常,没有发现任何严重的bug。(h)一个成功的备份。(我)大多数部署文档是最新的。
3.1.4。Sprint回顾
在这个会议上,m4团队成员重读团队运作的方法,相互关系,行为特征,和精炼方法技巧,以便接下来的冲刺更快速,等等。Scrum团队和团队领导(Scrum master)讨论了三件事:顺利,什么并不顺利,什么改进可以被认为是下一个sprint。团队的整体性能评估的形式(度量)和改善策略(kpi)的形式被识别出来,调整我们的前一篇文章。建议团队成员应该分享技术技能和知识,应该与产品所有者保持持续沟通,等等。这次会议是在每个sprint的末尾,持续大约两到三个小时。
3.1.5。发布计划
发布计划会议是一个连续不间断的过程描述,优先,把系统功能在一个发行版计划安排中。这包括识别和承诺如下:(一)发布的目标。(b)优先的一组用户故事(功能开发)。(c)用户故事的粗略估计。(d)发布日期。
主要输入步骤期间举行这次会议在m4项目如下:(一)团队成员估计用户故事,即。,make rough estimates of the relative size of the stories.(b)建立速度,即。,determine how many story points are completed in each sprint; the details are given in our other article.(c)计算预测,即。,date-based release is estimated to complete (velocity × number of sprints) story points. Functionality-based releases are estimated to complete in (total story points ÷ velocity) sprints.
优先级最高的故事,其总和不超过故事点的数量(如前所述)计算,选择。功能发布,如果预计竣工日期(计算)是可以接受的,所有的故事都是选择的释放。
4所示。SOA和Scrum集成
本节分析了Scrum的集成,软件开发过程,和SOA架构风格。SOA引入了一个有组织的和良好定义的软件设计,改变是支持通过敏捷的原则以及应用程序的设计模式和标准实现的质量、效率和生产力(9]。服务的可重用性和抽象是申请设计灵活和适应性强的系统(16]。SOA使用敏捷性在设计水平新服务的设计和旧的进化在底层架构,而不是通过改变架构本身。Scrum允许在增量发展,促进更快的反馈客户和开发团队之一。Scrum和SOA都支持企业过程,促进建立企业和发展战略保持一致。
Scrum和SOA的分析过程在m4项目开发环境表明,Scrum和SOA使用类似的原则达到的共同目标所需的软件开发。尽管SOA运行在一个有组织和控制设置,它可以受益于Scrum敏捷的同时,没有任何不合适的重叠。一个清晰的策略引入增量的变化,然而,被设计。
使用Scrum传统应用程序或传统的体系结构也可能通过描述需求的积压和增量交付客户。不过,预计发展努力,项目整体成本增加(49]。
提出利益和最大输出通过敏捷过程,应该牢记的是,底层软件架构和组织环境也支持过程的响应能力和成本。否则,该组织可能只得到最小从敏捷过程中受益。
正如已经讨论的,SOA和Scrum方法遵循不同的方向。在服务开发场景中,SOA方法遵循自顶向下方法(服务是构建在SOA系统的顶端),同时Scrum遵循自底向上方法(从最初的规划到原型交付),使用过程开发方法。以下问题:这些不同的方法是如何互相兼容开发过程当工作在一起吗?另一个问题是,SOA也遵循敏捷性就像Scrum过程?如果答案是肯定的,那么如何?最后,这两种方法怎么可能相互集成的个人提供的好处吗?这部分指的是这些问题,还讨论了SOA和Scrum指标有共性。SOA和Scrum典型发展框架如图7。
表2标识SOA和Scrum最重要的指标,它可以提供更多的商业价值和那些目标是使用SOA和Scrum在软件开发风险。
Scrum和SOA的一些指标用于共同的目的,即集成用于Scrum和SOA组合。这些指标是Scrum和SOA集成形式指标用于相同的目的,但使用不同的术语。通过这些指标,可以简化开发过程中采取适当的措施,这将提供更多的业务敏捷性,灵活性和兼容性为SOA和Scrum的环境。
“故事与计划完成指标的Scrum和“新服务创建和使用比例的总服务”度量SOA的测量产品的生产使用比例和百分比作为规模设备。他们都是用于服务或工作的测量,但使用不同的术语。团队速度的三个指标,开发时间,平均开发时间开发一个服务团队进步的冲刺和时间要求完成的服务在一个特定的时间内冲刺。由于这些指标的共同目标,这些可以组合成团队速度指标将被视为一个度量SOA和Scrum集成。质量测量、Scrum和SOA使用单独的指标,但目的是一样的;因此这两个指标可以作为质量保证指标测量使用Scrum流程模型服务的质量。
团队的热情度规措施团队成员是否高兴,急切地或不工作。当团队成员快乐和工作在一个舒适的环境中,他们会心甘情愿地工作,遵循free-planned架构策略和规则。他们将在协作环境中工作。团队成员之间的沟通总是会积极工作时急切地幸福。
5。Scrum和SOA讨论的兼容性
SOA和Scrum的主要目的是使整个企业敏捷通过使用服务的软件应用程序的构建块(50]。也通过Scrum软件开发过程模型意味着增加组织灵活性通过结合Scrum实践可以增加沟通、协作和反馈(13,14]。已经讨论过,Scrum和SOA通常被类似的担忧,但仍存在一些多样性以及这两种方法之间不兼容的问题。讨论了这两种方法的兼容性和共性,使地面的集成开发方法。
5.1。Scrum和SOA的兼容性
这听起来令人困惑为什么有必要找到相似点和Scrum和SOA之间的兼容性。Scrum和SOA是两种不同的范例之一是一个过程,另一个是一种架构风格。不过,找到两者的兼容性是合乎逻辑的和相关的一起使用时,例如,使用Scrum开发一个基于SOA的系统软件开发方法,虽然大多数SOA团队是下意识地意识到的方式设计和开发服务。整个重点围绕服务设计策略。SOA的自然激发特定团队化妆和风格的沟通团队根据政策就像Scrum实践(15,51]。可以说,Scrum就像人类的手,使用手套,而SOA这样的手套。据悉,大多数Scrum和SOA原则相互并不冲突,因为他们都是自适应的方法2]。同时SOA使用传统的方法,例如,瀑布模型,预测,预测方法完全依赖于需求分析和仔细的规划周期的开始。任何改变,包括将通过严格的变更控制管理和优先级。
敏捷模型使用一个自适应方法,没有详细的规划,只有明确未来的任务是那些必须开发的相关特征。团队适应动态变化的产品需求。产品经常测试,减少未来的重大错误的风险。与客户交互的强项是敏捷方法和开放的沟通和最小的文档是敏捷开发环境的典型特征。团队紧密合作,通常位于相同的地理空间。因此,敏捷模型更适合自适应服务在SOA项目开发的快速发展。应用程序开发通过Scrum没有明确的目标和强大的组织将是无用的。SOA没有明确的形象如何设计和建造使用Scrum流程模型规则是浪费资源和时间。也使用SOA作为一个普遍的策略,对于开发软件应用程序正在增加,因为它集中在应对变化的能力。自适应变化是SOA开发的不可或缺的概念以及敏捷开发,使用敏捷方法似乎是一种天然的适合开发SOA应用程序。
因此,Scrum和SOA是关于敏捷性,可以通过应用一起使用的规则和原则,不互相冲突。这样他们彼此保持平衡。
5.2。Scrum和SOA共性
已经讨论过的,SOA是一种体系结构方法侧重于商业组织必须聪明,可以应对快速变化的业务。通过发展服务,一个可以达到接近软件重用的模糊不清的目标。在SOA方法中,不同的团队构建个人服务,然后这些服务集成在一个应用程序中。(49,52]。同时Scrum是一种敏捷过程模型应用程序的开发,强调在应对变化(8]。通过引进技术和非技术两实践,团队能够支持企业成为敏捷。Scrum和SOA方法配对性质和份额总体目标。在这两种情况下,变化适应性强,和组织需要有效应对这一变化。因此,Scrum可以选择在构建基于SOA的应用程序。
5.3。SOA和Scrum的逆境
尽管Scrum和SOA是兼容的,仍然有一些主要的差别在两种方法中,应该理解和处理与SOA和Scrum项目中一起工作时(53]。的一个主要原因是,这两种方法有不同的起源和多样化的方向。Scrum是传统small-project-based,虽然过程改进和经验的从业者已经获得知识和学习经验适应Scrum宣言的规则也适用于大型软件开发项目。SOA是一种自顶向下和分治法的应用程序开发方法。“鸿沟”部分自然导致较低的团队之间的沟通。有三个主要地区Scrum和SOA互相冲突。(1)SOA鼓励建筑设计前期,而在Scrum社区大设计前期(BDUF)被认为是一种反模式。(2)SOA鼓励团队根据功能的分离,而Scrum鼓励跨职能团队。(3)SOA并没有任何正式的反馈和开发团队之间的沟通,当Scrum集中在频繁的反馈在技术层面和个人层面。
当使用SOA在一个大型的设置中,它可能是复杂影响任何改变(54]。可能还有其他问题超出了软件的灵活性和成本,例如,缺乏团队沟通和服务的可发现性。所以我们应该争取团队之间的密切合作和坦诚。每个团队将提供一个简单的修改版本的服务供内部测试。从服务服务团队将单独的测试数据,所以它生存,即使代码是搞砸了。服务团队将提供清洁和简单的文档如何添加新的调用服务存根。
6。结论
面向服务的体系结构(SOA)允许重用现有系统的功能,而不是建筑再从头开始。这个特性基于SOA的应用程序中的可重用性最大化经济利益的组织。Scrum流程模型,另一方面,往往关注的是迭代和客户建议以提高性能和允许不同需求的可预测性。研究分析的基础上确定共性和兼容性Scrum和SOA过程来实现组织的最大好处Scrum管理过程对于基于SOA的应用程序开发。研究建立,大部分的Scrum和SOA原则并不冲突。Scrum和SOA都是关于敏捷性,可以应用使用规则和原则,不要互相冲突。确认这种兼容性,Scrum和SOA集成开发环境的性能可以通过正式的测试基于个人kpi Scrum和常用度量SOA Scrum和SOA软件开发行业的从业者。这些kpi将提供一个正式的方法来衡量敏捷性,复杂性,效率和Scrum和SOA的价值对于那些想要使用Scrum团队和SOA集成环境。尽管的输出研究完成后,研究人员确定一些限制之前应该考虑一个工业应用结果Scrum和SOA集成项目。
7所示。未来的工作
以下是一些重要的点为未来工作基于这项研究的结果:(1)找出的影响将Scrum和SOA集成项目性能如果在分布式环境中使用。(2)定义一个正式的流程确定评估指标和kpi将和分布式Scrum和SOA集成项目。
数据可用性
没有数据是可用的。
的利益冲突
作者宣称没有利益冲突有关的出版。