Integration of Agile Methodologies and Model-Driven Development

Author(s):  
Imane Essebaa ◽  
Salima Chantit ◽  
Mohammed Ramdani

Agile methods (AM) and model-driven engineering (MDE) are two principal domains of software development. AM proposes best practices in information programming, while MDE focuses on technical part of software development. Both of these domains are in the way of improvement and evolution in order to facilitate the development of IT projects. However, these areas evolve separately despite the great number of researches that focus on improving development project' techniques. Thus, in this chapter the authors present an overview of their approach “Scrum with MoDAr-WA”, that aims to improve Scrum Agile methodology by combining two variants of MDE: model-driven architecture and mode-based testing with the V development lifecycle used to deal with sprint development in Scrum methodology. Then they present a comparison study between the standard Scrum process and Scrum with MoDAr-WA approach in order to highlight the authors' contribution to improve agile methodologies.

Author(s):  
John McAvoy ◽  
David Sammon

Discussions on agile software development methodologies have a tendency to develop into an argument between proponents of agile methods and proponents of more traditional process-oriented methodologies. The terminology used in these debates is often unhelpful, and in many cases are inaccurate and biased representations. It needs to be accepted that there are no “silver bullets” providing universal solutions (Jeffries, 2001). Bearing this in mind, the decision to adopt a particular software development methodology is a difficult one, and the decision to choose an agile method is no exception. In theory, as in practice, definitions and descriptions of the various agile methods are presented, yet the factors considered in the decision to adopt, or not adopt, an agile method are not addressed. While agile methodologies try to avoid the excessive use of procedures or tools (Beck & Fowler, 2001), one agile methodology, dynamic systems development method (DSDM), does recommend the use of appropriate tools during the development process (Coesmans, 2003). However, it appears that none of the available agile methodologies suggest a tool to assist decision makers at the project initiation phase, therefore, the debate on agile suitability is usually a debate on agile versus traditional methods (DeMarco & Boehm, 2002), rather than an examination of the suitability of agile methods for a particular project. While the “agile debate” rages, individual projects are not adequately assessed prior to the adoption of a method.


2020 ◽  
Author(s):  
CRS Kumar

In the game of Golf, a player is challenged to take the minimum strokes to complete a round of 18 holes under varying playing conditions. Players use different clubs depending on their skill levels to achieve the desired distance while taking shots at the golf ball from the start (tee off) to the hole (pin). Unlike other games which have a standardized playing area, the terrain in a golf course comprises of various natural and manmade features viz. fairways, bunkers, trees, water bodies etc, which increase the difficulty level of the game and keep the players challenged.The game of golf has a fascinating similarity to a software development life cycle. If the holes on a golf course are considered akin to milestones in a development project then most of the Software Engineering models focus on software development in groups. Thus, we propose SOLF i.e Software Development Lifecycle model based on Golf, as a SDLC ideal for individuals or a small group of 2-3 developers. The proposed model is easy to comprehend, flexible and optimally adjustable in a dynamic environment.SOLF divides the project into 18 stages wherein each stage of the project will have 3 to 6 tasks which are required to be completed within a fixed timeline. The stages are managed by creating checklists at the start akin to the pre-shot routines in golf and the customer feedback is received on reaching each of the milestones similar to applause in the game of golf. Terrain of the golf course is reflected as risk list which are varying for each of the stages.SOLF achieves 10x speedup in software development and research projects as it creates an environment of challenges and drives the developer towards self excellence. It also inculcates a spirit of competition and sportsmanship by challenging the developers on various 'terrains' of development.


Author(s):  
Martin Monperrus ◽  
Jean-Marc Jézéquel ◽  
Joël Champeau ◽  
Brigitte Hoeltzener

Model-Driven Engineering (MDE) is an approach to software development that uses models as primary artifacts, from which code, documentation and tests are derived. One way of assessing quality assurance in a given domain is to define domain metrics. We show that some of these metrics are supported by models. As text documents, models can be considered from a syntactic point of view i.e., thought of as graphs. We can readily apply graph-based metrics to them, such as the number of nodes, the number of edges or the fan-in/fan-out distributions. However, these metrics cannot leverage the semantic structuring enforced by each specific metamodel to give domain specific information. Contrary to graph-based metrics, more specific metrics do exist for given domains (such as LOC for programs), but they lack genericity. Our contribution is to propose one metric, called s, that is generic over metamodels and allows the easy specification of an open-ended wide range of model metrics.


Author(s):  
Zaidoun Alzoabi

The term Agile Method of software development was coined in the 2001.This approach is characterized with creativity, flexibility, adaptability, responsiveness, and human-centricity. Researchers have suggested that the complex, uncertain, and ever-changing environment is pushing developers to adopt agile methods rather than traditional software development. Agile methodologist claim that their Agile methods is the answer for the software engineering chaotic situation, in which projects are exceeding their time and budget limits, requirements are not fulfilled, and consequently ending up with unsatisfied customers. In this chapter we will explain agile methodology, its general characteristics, and quick description of the famous agile methods known in the industry and research.


Author(s):  
Torstein Nicolaysen ◽  
Richard Sassoon ◽  
Maria B. Line ◽  
Martin Gilje Jaatun

In this article, the authors contrast the results of a series of interviews with agile software development organizations with a case study of a distributed agile development effort, focusing on how information security is taken care of in an agile context. The interviews indicate that small and medium-sized agile software development organizations do not use any particular methodology to achieve security goals, even when their software is web-facing and potential targets of attack. This case study confirms that even in cases where security is an articulated requirement, and where security design is fed as input to the implementation team, there is no guarantee that the end result meets the security objectives. The authors contend that security must be built as an intrinsic software property and emphasize the need for security awareness throughout the whole software development lifecycle. This paper suggests two extensions to agile methodologies that may contribute to ensuring focus on security during the complete lifecycle.


2020 ◽  
Vol 10 (10) ◽  
pp. 2473-2480
Author(s):  
Waqar Mehmood ◽  
Muhammad Shafiq ◽  
Muhammad Qaiser Saleem ◽  
Ali Saeed Alowayr ◽  
Waqar Aslam

Model-driven engineering (MDE) paradigm considers models as central artifacts for software development lifecycle during which models evolve. Developing an e-health solution using MDE poses challenges of model version control, model differencing and model merging, which requires appropriate software configuration management (SCM). In this paper we focus on model-driven merging, which refers to combining two or more versions of a model into a single consolidated version. SCM for model-driven merging leverages evolution of valid configurations, which is a highly desired behavior. Our investigation is based on the features that are required for model-driven SCM realization. Initially, we identify these features using which the existing model-driven merging techniques are evaluated. It is observed that though various proposals are made by academia and research community, a standard model-driven SCM solution that can cater to the needs of industry is still absent. This is in contrary to the situation of traditional SCM systems where standard solutions exist. We also present the usefulness of each technique along with the tradeoffs involved. Finally, guidelines are provided to select techniques appropriate for given circumstances.


Adoption of Agile methodologies in IT organizations has revolutionized software development. It has improved speed of development, quality of final product, customer satisfaction, project control and reduced risk and wastage. Agile methodology is however not just a process but it is a philosophy that has a deep impact on the behavior and mindset of employees. Current paper attempts to study this impact and deduce whether it has a positive impact on Trust, Knowledge Sharing and Collaboration.


2021 ◽  
Author(s):  
◽  
Angela Michelle Martin

<p>eXtreme programming (XP) is one of a new breed of methods, collectively known as the agile methods, that are challenging conventional wisdom regarding systems development processes and practices. Practitioners specifically designed the agile methods to meet the business problems and challenges we face building software today. As such, these methods are receiving significant attention in practitioner literature. In order to operate effectively in the world of vague and changing requirements, XP moves the emphasis away from document-centric processes into practices that enable people. The Customer is the primary organisational facing role in eXtreme Programming (XP). The Customer's explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing). Unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. This thesis presents a grounded theory of XP software development requirements elicitation, communication, and acceptance, which was guided by three major research questions. What is the experience of being an XP Customer? We found that teams agree that the on-site customer practice is a drastic improvement to the traditional document-centric approaches. Our results indicate, however, that the customers are consistently under pressure and commit long hours to the project in order to fulfil the customer role. So while this approach to requirements is achieving excellent results, it also appears to be unsustainable and thus constitutes a great risk to XP projects. Who is the XP Customer? The initial definition of XP resulted in many people interpreting the onsite customer to be a single person. This research has highlighted that a customer team always exists, and goes further to outline the ten different roles that were covered on the team, which range from the recognised "Acceptance Tester" role to the less recognised roles of "Political Advisor" and "Super-Secretary". What are the practices that support an XP Customer to perform their role effectively on a software development project? An additional eight customer-focused practices have been uncovered to supplement the existing XP practices. These customer-focused practices together enable customers to sustainably drive XP projects to successful completion. The practices range from those that specifically focus on interaction (both with the programmer team and the larger organisation) e.g. "Programmer On-site" and "Roadshows" to those that specifically look to the well-being and effectiveness of the customer (e.g. "Pair Customering") to those that highlight the key steps or activities that need to occur along the way (e.g. "Big Picture Up-Front" and "Recalibration").</p>


Sign in / Sign up

Export Citation Format

Share Document