You can use agile development with MDriven when you build business applications that need to absorb requirements discovered through testing and use.

Agile development in MDriven

Agile development is an iterative way of developing software: you make a small change, run and test it, learn from the result, and make the next change. It is appropriate when the correct business behavior becomes clearer as the project progresses.

In MDriven, the model is the central place for business structure and behavior. You can change the domain model, adapt a Turnkey ViewModel, test the result, and deploy the changed definitions.

For example, a ticket application may initially allow users to create tickets but not record who created them. After testing the application, you can add a Creator association from Ticket to User, show the creator name in the ticket view, and update the create action to assign the current user.

Manage Think-bugs

A Think-bug is a defect or missing behavior that comes from an incomplete understanding of how the business solution should work. It is not necessarily caused by poor initial analysis. It often appears when users test a working application and identify a requirement that was difficult to predict.

The ticket creator example is a Think-bug: the application can create and find tickets, but testing reveals that the business needs each ticket to identify its creator.

Traditional approaches attempt to prevent such issues through a detailed up-front specification. Agile work instead reserves room to revise the solution as the team's understanding improves.

Model-driven development reduces the investment in repeated implementation work around business objects. This can make it easier for the team to revise a solution rather than defend an earlier implementation.

A change-and-test cycle

Use this cycle for each small requirement that you discover:

1. Run the application and test the current user task.
2. Record the missing behavior as a concrete requirement. For example: A newly created ticket must have the logged-in user as its creator.
3. Change the model in MDriven Designer. In the example, add the association between User and Ticket.
4. Change the relevant ViewModel definition. Add an action that opens a new ticket, and show the creator name as non-editable information in the ticket view.
5. Add or revise the action behavior. In the example, use OCL so the create action assigns Ticket.Creator from the current user obtained through the Global singleton, then returns the new ticket for the ticket window.
6. Update the generated code and evolve the database schema when the model change requires it. Adding Ticket.Creator requires a foreign key in the ticket table.
7. Run the application again and verify the complete task: create a ticket, confirm that its creator is populated, search for the ticket, and open it.
8. Deploy the tested change. Turnkey publishing uploads the changed definitions and opens the deployed application URL.

Watch the ticket-application change cycle.

Keep business knowledge visible

Agile delivery can produce many small changes from user stories. If those changes exist only in code, tickets, or individual developers' knowledge, the team loses an overview of the application.

Keep the business structure and rules in the model and its related definitions. For example, the Creator association documents that a ticket has a creating user; the ticket create action documents when that association is assigned; and the ticket ViewModel documents where users see the creator.

In Turnkey, you can inspect a deployed ViewModel definition at https://<yoursite>/Turnkey/Development. This supports review of the definitions that make up a running view. See Documentation:Development info in runtime.

Scope changes so they remain testable

Keep each iteration small enough to test as a complete user task.

Change	Testable outcome
Add an Add ticket action to the ticket search ViewModel.	A user can open a new ticket window from ticket search.
Add the Creator association.	A ticket can store a reference to the user who created it.
Assign Creator in the create action.	A newly created ticket displays the logged-in user's name.
Change the ticket search presentation.	Search results show creator name instead of ticket ID where that is the intended information.

Do not treat a successful schema update as sufficient verification. Test the business behavior after the schema and ViewModel changes are deployed.

See also

• Documentation:MDriven Developer's Guide: Model-Driven Development Simplified
• Documentation:Development info in runtime
• Documentation:Learn OCL