What are different Myths and Misconceptions surrounding Agile Model Driven Development (AMDD)?

The agile version of the model driven development or AMDD (agile model driven development) is now being recognized one of the most popular development models in the field of software engineering. This agile model driven development methodology was born out of a need of a combined development process of the agile methodology and the test driven development or TDD. 

The agile development in this combination is supposed to make the addressing of the cross entity issues easy while the TDD (test driven development) counterpart is suppose to focus exclusively on each and every individual entity of the software system or application. 

About Agile Model Driven Development

The agile model driven development lately has been known to suffer a lot of criticism giving way to the birth of several myths and misconceptions regarding it.

- The agile model driven development methodology has been characterized as an obsolete agile software development methodology to some extent though not so much. 

- The agile model driven development is thought to involve only a little bit of modeling but quite a lot of coding.

- The iterating efforts are deemed to be spread between the coding activities and the software modeling activities.

- Here a feel like illusion of majority of the designing being carried out as a part of the implementation efforts is created. 

- Such situations are also true for many other traditional software development methodologies. 

- In situations like this what happens is that the designers ultimately put the blame on the developers without questioning their own way of processing the software development.

- One of the misconception regarding the agile model driven development is that it does not specifies what all types of the software models are to be created.

- Even though it is always specified by the agile model driven development that only the right artifact is to be applied, it never does specify what that particular artifact really is. 

- One of the myths is that the agile model driven development works perfectly well with the UCDD (use case driven development) and the FDD (feature driven development). 

Myths and Misconceptions of Agile Model Driven Development

Below mentioned are some of the other myths and misconceptions surrounding the agile model driven development:

1. The agile models do not fulfill their purpose well.
2. It is very difficult to understand the agile models.
3. The agile models do not exhibit sufficient consistency.
4. The agile models are not sufficiently detailed.
5. The accuracy of the agile models is not so high.
6. The agile models exhibit a characteristic complexity.
7. Sometimes negative values are provided by the agile models.

Point of Argument

- Another most argued concept of agile model driven development is that the agile documents and models seem to be sufficient for carrying out the development.

- For this, the people develop false assumptions that the software is not as good as it portraits and expectations regarding the quality of the software artifact. 

- It is also thought that if the artifact has fulfilled the purpose which was intended then any more work that can be carried out on it is considered to be a useless bureaucracy. 

Benefits of Agile Model Driven Development

- The agile model driven development is known to take a more realistic approach and give a description of how the developers and stake holders are supposed to work together in cooperation to create good models.

- Agile model driven development is quite a flexible technology in the way that it allows the use most primitive and unsophisticated development tools for the creation of the models like papers and white boards as mentioned above.

- The agile model driven development is supposed to be independent of any sophisticated CASE tools even though they can be used effectively by the experts. 

Misconceptions of the Capability Maturity Model (CMM)

CMM is the most widely used Software Process Improvement model. It was developed by Carnegie Mellon University’s Software Engineering Institute (SEI). A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level provides a layer in the foundation for continuous process improvement.
In CMMI models with a staged representation, there are five maturity levels designated by the numbers 1 through 5.
- Initial
- Managed/Repeatable
- Defined
- Quantitatively Managed
- Optimizing

Misconceptions About Maturity Levels
- If you are at Level 1, you are pond scum.
Being Level 1 does not mean that the members of a software organization are barely breathing. It does mean that the organization's projects are likely to have less predictability, more rework, more defects, and more schedule slippage than those in a higher maturity organization.
- Level 2 is mostly about software engineering activities, such as requirements analysis, design, coding, and testing.
- You have to perform all of the activities and practices defined at some maturity level in order to achieve that level.
- Software measurement is not required until you are approaching Level 4.
- The SEI certifies an organization at a specific maturity level.
- The CMM requires that you use specific software development practices, tools, and methodologies.
- The CMM mandates a waterfall life cycle model.
- The Software Quality Assurance KPA is mostly about testing.
- The CMM requires that you perform software inspections to achieve Level 3.
- Having a "tailorable" process really means that you can do whatever you want.
- Requirements management is the same thing as requirements engineering.
- You cannot work on improving KPAs more than one maturity level higher than your current level.
- The CMM mandates bureaucracy and wasteful paperwork.
- The CMM is a quick fix for short-term problems.
- CMMI is proprietary for the US military use.
- CMMI is the next release of CMM.
- Everyone uses the Staged Representation.
- You cannot use CMMI if you already use some other improvement model.
- CMMI is not suitable for small organizations.
- CMMI is used only to get an appraisal rating.
- CMMI is not suitable for companies using Agile methods.
- CMMI implementation takes long and is expensive and does not pay off.
- CMMI is a process model.