Semi-Agile Model-Driven Development (SAMDD)

Stakeholders

A stakeholder is any person or organization interested in the project's outcome.

The principle stakeholders are the customer, users, and developers. The customer commissions the developers to build the system. The users use the system.

Team Structure/Dynamics

Team size: 4 - 6

Team roles:

chief programmer vs. team facilitator
librarian (captures and manages all artifacts)
specialists (GUI, Dbase, Platform)

Team Activities:

Brainstorming
Reviews
Pairs programming
Parties

Artifacts

Specification

The specification is a document that consists of the following sections:

System Overview
Requirements Model
Functional Requirements (Use Case Diagrams)
Use Case Elaborations (Sequence Diagrams)
Non-Functional Requirements
Usability, Reliability, Performance, Supportability
Domain Model (Class and Object Diagrams)
Business Process Model (Activity Diagrams)
Glossary

Design

The design is a document that consists of the following models:

System or Architectural Model (Package diagrams)
Subsystem Models (Class & Package Diagrams)
Deployment Model (Deployment diagrams)
System and subsystem Dynamics (Sequence diagrams)

System Test

The system test consists of the tests for each subsystem.

A subsystem test consists of tests for each class and sub-subsystem.

A class test consists of tests for each non-private method and can be traced back to one or more use cases.

A method test invokes a method on several inputs and compares the actual outputs with the expected outputs (as determined by an oracle). The method test fails if any discrepancy is found that exceeds the error tolerance. In this case the class test fails. This causes the subsystem test to fail, which causes the system test to fail.

The system test should be run each time a change is made. This is called regression testing.

The System Test is only a functional or black box test. More errors are detected during the design and code reviews, which involve inspections and walk-throughs by the developer as well as by the team.

Release

The release consists of source code and executable code. Source code consists of package, class, and interface declarations. The source code should be commented and formatted according to some style guideline. The source code should be self-documenting. The executable code should pass the system test and should meet some agreed upon subset of requirements called a milestone. The release should be on time, even if it means some requirements won't be met.

Other Documents

In addition to the specification and design documents, the system also includes user and programmer manuals. Although these documents are produced by technical writers, the programmer manual usually includes API documentation for each package, class, interface, field, and method. The API documentation can be automatically generated from properly formatted source code comments.

Tools

A source code control system such as CVS should be used to manage all artifacts.

A configuration control system such as ANT or MAKE should be used to build, deploy, and test the system.

An IDE such as Eclipse should be used to edit, debug, and refactor the system.

A CASE tool such as Rose should be used to create the system models.

The system should customize a framework such as MFC.

Refactoring tools should be used to automate the refactoring process.

A testing framework such as JUNIT should be used to automate the testing process.

API Document generators like javadoc should be used.

Process

Our process is an agile, model-driven, iterative-incremental process:

Notice that there is no maintenance phase in which new features are added to the code. This is because our process iterates until the system is retired or aborted. New features can be added during any iteration.

Implementation is actually a macro-phase consisting of a number of micro-phases:

Model-driven development means that code and tests are derived from (UML) models.

Agile development means that design is deemphasized. Design inadequacies can be corrected by refactoring. Models are only good enough to serve their purpose. Details are left to code. Often the models are discarded after they have served their purpose.

Agile development is often test-driven, which means that tests are implemented before requirements are implemented. The code is only good enough to pass the tests and is refactored to accommodate new tests.

Iterations are short in agile development, typically one or two weeks. Deadlines never slip, although promised requirements may not make the promised release.

Agile development assumes stakeholder participation. The customer decides which how requirements should be prioritized.

Our process is only semi-agile because we spend a bit more time on design and code and assumes a bit less involvement from the customer.