Explain Agile Model Driven Development (AMDD) lifecycle?

“AMDD” is the abbreviated form of the “agile model driven development” and nowadays is quite popular among the developers and programmers in the field of software engineering and technology.

AMDD took its birth from the “MDD” or the “model driven development” as its agile version that makes use of the agile models rather than using the extensive models in the pure model driven development. 

The agile model driven development was formulated out of model driven development since it was thought that the iterative development with the model driven development is possible. And since it constituted of the iterations, it was categorized under the category of agile software development methodologies. 

The agile models that drive the whole development procedure are good enough to take care of the development efforts. The agile model driven development is one of the most sought after beyond the small agile software scaling development methodologies.

Agile Model Driven Development Lifecycle

To understand this whole agile model driven development one needs to familiarize himself/ herself with the life cycle of this development model. This article is focused up on the life cycle of the agile model driven development only!

The life cycle of the agile model driven development is of quite a high level. So let us see what all are the various stages in the life cycle of the agile model driven development:

1. Envisioning: 

This stage of the life cycle is comprised of two more sub stages namely: the zeroth and the first iteration. These iterations usually come in to play during the first few weeks of the development process. This stage is actually included in to the life cycle with the purpose of the identification of the scope of the system and what kind of architecture will be suitable for developing the project. For this the following two sub stages come in to process:

(a)  Initial requirements envisioning or modeling: 

This stage may take up to several days for the identification of the high level requirements. Apart from just identifying the requirements the scope of the release product is also determined at this stage only. For carrying out with this stage the developer may require some type of usage model in order to see how the software project will be used by the customers or the users.

(b) Initial architecture modeling: 

This stage is all about setting up of a proper technical direction for the development of your software project.

      2. Iteration Modeling: 

     This stage involves planning for what is to be done with the current iteration. Often the modeling techniques are ignored by the developers while planning objectives for the iteration that is to be carried out next. The requirements in every agile model as we know are implemented in the order of their priority.

     

      3. Model Storming: 

      As mentioned in the agile manifesto the development team should consist of only a few members who are the ones who discuss the development issues by sketching it up on a white board or paper. The sessions which involve activities such as those are called the model storming sessions. These sessions are short enough to last for at most half an hour.

   

     4. Test driven development involving the executable specifications: this stage involves the coding phase using the re-factoring and test first design (TFD). The agile development helps you address cross entity issues whereas with the test driven development you can focus up on each and every single entity. Above all the technique of re-factoring the design, it is ensured that the high quality of the software project is not hampered at all.

Explain agile model-driven development (AMDD)?

AMDD stands for the agile model driven development which is not all to be confused with the agile model of software development. The model driven development or MDD is a separate development model and the AMDD i.e., the agile model driven development is its agile version. 

Not many of us familiar with this model. This article is dedicated to the agile model driven development model only. 

About Model Driven Development

- The model driven development involves the creation of the extensive software models before the actual coding is done.

- The best example for this is given by the Object Management Group (OMG’s) model driven architecture standard.

- Model driven development is quite famous with the developers who follow the traditional approaches whereas the agile model driven development has made it mark with the agile followers.

- After going through a research on the RUP/ EUP, it was observed that the model driven development can do with an iterative approach and thus the agile model driven development was born. 

- The basic difference here lies in the creation of the models.

- In the agile model driven development the agile models of the software are created rather than creating extensive models like in the case of the model driven development.

- These agile software models are good enough to drive the whole lot of the development efforts. 

- The agile model driven development is a methodology that has adopted for scaling of the agile software development. 

Activities included in life cycle of an agile project

Below mentioned are the activities that are included in the life cycle of an agile project:

1. Identification of the high level scope
2. Identification of the initial requirements stack
3. Identification of an architectural vision
4. Iteration modelling
5. Model storming
6. Test driven development (TDD)

Iteration activities In AMDD

The following are the iteration activities in an agile model driven development method:

1. Requirements envisioning
2. Architecture envisioning
3. Initial set up and planning
4. Investigative testing
5. Release
6. Production

- The envisioning is done usually in the first week of the development of a software project with the goal of identification of the scope of the software system or application and its architecture. 

- For this both the high level architecture modelling and the high level requirements modelling are required. 

- Envisioning is a means for exploring the requirements and develops a strategy for the development of your project. 

What is to be done in each iteration should be decided well before beginning with the iteration process?

- The agile software development principles insist that the requirements are implemented in the order of their priority levels.

- This is what is called as the iteration planning. 

- For the accurate estimation of the requirement it is required that you understand the work needed to be done for its implementation and this is where the modelling comes to help. 

- The model storming sessions are usually like some impromptu sessions which do not last for more than thirty minutes.

- It involves the discussion over an issue until all the members are satisfied with their understanding of the issue. 

- After this they again get back to coding process. 

- Model storming is often called as the JIT modelling or “just in time” modelling.

- During the whole development process several agile methodologies are followed like:

1. Test first design (TFD)
2. Refactoring etc.

- The above two agile methodologies combined together are known as the test driven development. 

- This is the stage in the agile model driven development where much of the time is spent. 

- Here the detailed modelling is carried out with the help of development tests, customer tests, executable specifications and so on. 

- The customers tests here are nothing but the agile acceptance tests. 

Software Development Methodology - Joint Application Development (JAD)

- Joint Application Development(JAD)is a process that is originally used to develop computer based systems.
- Joint Application Development is a process that accelerates the design of information technology solutions.
- JAD uses customer involvement and group dynamics to accurately depict the user's view of the business need and to jointly develop a solution.
- JAD is thought to lead to shorter development times and greater client satisfaction because the client is involved throughout the development process.
- JAD centers around a workshop session that is structured and focused. Participants of these sessions would typically include a facilitator, end users, developers, observers, mediators and experts.
- In order to get agreement on the goals and scope of the project, a series of structured interviews are held.
- The sessions are very focused, conducted in a dedicated environment, quickly drive major requirements.

Concept of Joint Application Development

- User who do the job have the best understanding of that job.
- The developers have the best understanding of the technology.
- The software development process and business process work in the same way.
- When all groups work equal and as one team with a single goal, the best software comes out.

Principles of JAD Process

- Define session objectives.
- Prepare for the session.
- Conduct the JAD session.
- Procedure the documents.
JAD improves the final quality of the product by keeping the focus on the upfront of the development cycle thus reducing the errors that are likely to cause huge expenses.

Advantages of Joint Application Development

- JAD decreases time and costs associated with requirements elicitation process.
- The experts get a chance to share their views, understand views of others, and develop the sense of project ownership.
- The techniques of JAD implementation are well known as it is the first accelerated design technique.
- Easy integration of CASE tools into JAD workshops improves session productivity and provides systems analysts with discussed and ready to use models.
- Enhances quality.
- Creates a design from the customer's perspective.

What is Long Session Soak Testing ?

When an application is used for long periods of time each day, the above approach should be modified, because the soak test driver is not logins and transactions per day, but transactions per active user for each user each day. This type of situation occurs in internal systems, such as ERP and CRM systems, where user logins and stay logged in for many hours, executing a number of business transactions during that time. A soak test for such a system should emulate multiple days of activity in a compacted time frame rather than just pump multiple days worth of transactions through the system.

Long session soak tests should run with realistic user concurrency, but the focus should be on the number of transactions processed. VUGen scripts used in long session soak testing may need to be more sophisticated than short session scripts, as they must be capable of running a long series of business transactions over a prolonged period of time.

The duration of most soak tests is often determined by the available time in the test lab. There are many applications that require extremely long soak tests. Any application that must run, uninterrupted for extended periods of time, may need a soak test to cover all of the activity for a period of time that is agreed to by the stakeholders. Most systems have a regular maintenance window, and the time between such windows is usually a key driver for determining the scope of soak test.