The development approach taken for this project is inspired from Dynamic System Development Method (DSDM) Agile methodology. The following could be seen as mostly theory or hardly applicable for the EoC Modding Project. But it's not the case. Principles and phases should be read with having the project's context in mind. Thus, some principles and activities may be less important or even skipped compared to a "standard" Agile project but the logic remains.

DSDM provides a project lifecycle as well as a system lifecycle: DSDM Lifecycle Diagram

Principles

The following principles are the foundations on which DSDM is based. Each one of the principles is applied as appropriate in the various parts of the method.

Principle	Description
1 Active user involvement is imperative	DSDM is a user-centred approach. If users are not closely involved throughout the development lifecycle, delays will occur as decisions are made and users may feel that the final solution is imposed by the developers and/or their own management. Users are not outside the development team acting as suppliers of information and reviewers of results but are active participants in the development process.
2 DSDM teams must be empowered to make decisions	DSDM teams consist of both developers and users. They must be able to make decisions as requirements are refined and possibly changed. They must be able to agree that certain levels of functionality, usability, etc. are acceptable without frequent recourse to higher-level management.
3 The focus is on frequent delivery of products	A product-based approach is more flexible than an activity-based one. The work of a DSDM team is concentrated on products that can be delivered in an agreed period of time. This enables the team to select the best approach to achieving the products required in the time available. By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products. Note: Products include interim development products, not just delivered solutions.
4 Fitness for business purpose is the essential criterion for acceptance of deliverables	The focus of DSDM is on delivering the necessary functionality at the required time. The computer system can be more rigorously engineered later if such an approach is acceptable. Traditionally the focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and the business needs may have changed since the start of the project.
5 Iterative and incremental development is necessary to converge on an accurate business solution	DSDM allows systems to grow incrementally. Therefore the developers can make full use of feedback from the users. Moreover partial solutions can be delivered to satisfy immediate business needs. Iteration is inherent in all software development. DSDM recognises this and, by making it explicit, uses iteration to continuously improve the system being developed. When rework is not explicitly recognised in a development lifecycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down. Since rework is built into the DSDM process, the development can proceed more quickly during iteration.
6 All changes during development are reversible	To control the evolution of all products (documents, software, test products, etc.), everything must be in a known state at all times. This means that configuration management must be all-pervasive. Backtracking is a feature of DSDM. However in some circumstances it may be easier to reconstruct than to backtrack. This depends on the nature of the change and the environment in which it was made. The ability to reverse changes is limited to within the development of an increment.
7 Requirements are baselined at a high level	Baselining high-level requirements means "freezing" and agreeing the purpose and scope of the system at a level that allows for detailed investigation of what the requirements imply. Further, more detailed baselines can be established later in the development, although the scope should not change significantly. Changing the scope defined in the baselined high-level requirements usually requires escalation.
8 Testing is integrated throughout the lifecycle	Testing is not treated as a separate activity. As the system is developed incrementally, it is also tested and reviewed by both developers and users incrementally to ensure that the development is moving forward not only in the right business direction but is technically sound. Early in DSDM, the testing focus is on validation against the business needs and priorities. Towards the end of a project, the focus is on verifying that the whole system operates effectively.
9 A collaborative and co-operative approach between all stakeholders is essential	The nature of DSDM projects means that low-level requirements are not necessarily fixed when the developers are originally approached to carry out the work. Hence the short-term direction that a project takes must be quickly decided without recourse to restrictive change control procedures. The stakeholders include not only the business and development staff within the project, but also other staff such as Service Delivery or resource managers. When development is procured from an external supplier, both the vendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the pre-contract phase and when the contracted work is carried out.

Phases

Functional Model Iteration

The focus of Functional Model Iteration is on refining the business-based aspects of the computer system, i.e. building on the high-level processing and information requirements identified during the Business Study. To this end both standard analysis models and software are produced.

Both the Functional Model Iteration and the Design and Build Iteration consist of cycles of four activities:

Identify what is to be produced.
Agree how and when to do it.
Create the product.
Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the software).

The Functional Model that is built up in these cycles consists both of analysis models and of software components, which contain the major functionality and will satisfy some of the non-functional requirements, particularly the requirements relating to ease of use.

The software parts of the Functional Model are tested as they are produced. This includes technical unit testing, but should also include as many other classes of testing as possible including mini-acceptance tests by the Ambassador Users as soon as new components are available. The focus of testing in the Functional Model is necessarily on what the components do (however limited that is) and whether or not they form the basis of a usable set of functionality. Non-functional aspects such as performance are tested in the Design and Build Iteration. This gives rise to the backwards arrow in the process diagram above from the Design and Build Iteration to the Functional Model Iteration.

Any non-functional requirements not captured already should be captured during the Functional Model Iteration ready for the Design and Build Iteration.

It will often be easier, and indeed more sensible, to address the detail of an area of functionality together with its non-functional aspects in one chunk before addressing the detail of another area. The extent to which the Functional Model Iteration and Design and Build Iteration merge, overlap and move backwards and forwards between each other will depend largely on how the application being built can be partitioned into smaller functioning areas and the facilities of the development environment.

The preconditions for moving from functional modelling to design and build include agreement of a Functional Prototype that may or may not be fully automated. The Functional Prototype may be for only part of the Functional Model. This means that design and build activities may happen concurrently with the functional prototyping activities. Similarly, in a large DSDM project, the subsequent Implementation may be phased, so design and build may be concurrent with some implementation.

Design and Build Iteration

The Design and Build Iteration is where the computer system is engineered to a sufficiently high standard to be safely placed in the hands of the users. The major product here is the Tested System. The DSDM process diagram does not show testing as a distinct activity because testing is happening throughout both the Functional Model Iteration and the Design and Build Iteration. Some environments or contractual arrangements will require separate testing phases to be included at the end of the development of the increment, but this should not be the major activity encountered in more traditional approaches to development. Testing is just as important in DSDM and consumes just as much effort, but it is spread throughout development.

The Tested System will not necessarily satisfy all the identified requirements, but it will satisfy all the requirements that have been agreed for the current increment. Due to the time constraints, some lesser parts of the system will have been agreed to be left to a later date. However, the core of requirements (what DSDM calls the minimum usable subset) will be contained in the Tested System, with as many other parts as time allows.

Implementation

The Implementation phase covers the cutover from the development environment to the operational environment. This includes training the users who have not been part of the project team. Iteration of the Implementation phase is applicable when the system is being delivered to a dispersed user population over a period of time.

The products of this phase include the Delivered System that contains all the agreed documentation, including the User Documentation. The User Documentation is completed in this phase but must have been started earlier during the Design and Build Iteration. One of the responsibilities of the Ambassador Users is to ensure the correct production of the User Documentation and training, thus ensuring that the correct perspective is present.

The other product of this phase is the Increment Review Document. This is produced immediately the computer system or increment is deemed complete. The Increment Review Document is used to summarize what the project has achieved in terms of its short- objectives. In particular, it reviews all the requirements that have been identified during development and assesses the position of the system in relation to those requirements. There are four possible outcomes (three of which are shown by returning arrows on the DSDM process diagram above). The four outcomes are:

All requirements have been satisfied. Hence, no further work is currently needed - and no returning arrow.
A major area of functionality was discovered during development that had to be ignored for the time being in order to deliver on the required date. This means returning to the Business Study and taking the process on from there.
Lower priority functionality, which was known, had to be left out because of the timescale. This is now to be added, so the process returns to the Functional Model Iteration.
An area of lesser technical concern was omitted again due to time pressure, but can now be addressed by returning to the Design and Build Iteration.

Key Concepts

For the Project The following concepts are key success factors. The Project Planning is built over these concepts.

Prioritization (MoSCoW Rules)

Delivering on a guaranteed date (without working overtime) means that what was originally envisaged for an individual delivery may have to be left out. However it is important that essential work is done and that only less critical work is omitted. The method of ensuring that this is true is clear prioritization of the requirements.

The simple MoSCoW rules are used to achieve this. The o's in MoSCoW are just there for fun. The rest of the word stands for:

Must have for requirements that are fundamental to the system. Without them the system will be unworkable and useless. The Must Haves define the minimum usable subset. A DSDM project guarantees to satisfy all the minimum usable subset.
Should have for important requirements for which there is a workaround in the short term and which would normally be classed as mandatory in less time-constrained development, but the system will be useful and usable without them.
Could have for requirements that can more easily be left out of the increment under development.
Want to have but Won't have this time for those valuable requirements that can wait till later development takes place; in other words, the Waiting List. All of these requirements are needed for the full system. The "wish list" does not appear in the categorization.

The MoSCoW rules provide the basis on which decisions are made about what the project team will do over the whole project, within an increment of the project and during a timebox within an increment. As new requirements arise or as existing requirements are defined in more detail, the decision must be made as to how critical they are to the success of the current work using the MoSCoW rules.

All priorities should be reviewed throughout the project to ensure that they are still valid. It is essential that not everything to be achieved within a project or a timebox is a Must Have. It is the lower level requirements that enable teams to deliver on time by dropping out lower priority requirements when problems arise.

Prioritized Requirements List

The Prioritized Requirements List defines what the proposed solution must do and how well it must do it.

It provides the foundations for all planning decisions throughout the project. It is used to determine:

the order in which increments take place
which products will be essential to achieve project success
what timeboxes will deliver.

All requirements are prioritized using the MoSCoW rules.

Initially (in the Feasibility and Business Studies), the requirements will all be high-level, they will be refined and amended throughout the project. In particular, the non-functional requirements are defined in detail during Functional Model Iteration activities.

Purpose

To provide the Functional Model Iteration with a prioritized list of requirements (both functional and non-functional) for investigation.

To identify the minimum usable subset of functionality that will support the business. (This subset is guaranteed to be delivered.)

Quality Criteria

Have all the currently identified requirements been prioritized?
Have all the priorities been assigned in collaboration with team members?
If the development is in one project, does user management accept the possibility that solutions to low priority requirements may not be delivered (at least initially)?
If the development is a set of projects, does user management the possibility that solutions to low priority requirements may not be delivered until a later?

Timeboxing

Timeboxing is a very important aspect of DSDM projects. Without timeboxing, project teams can lose their focus and run out of control. Timeboxing is a process by which defined objectives are reached at a pre-determined and immovable date through continuous prioritisation and flexing of requirements using the MoSCoW rules.

There are various levels at which timeboxing takes place.

The project end-date is fixed and the overall business objectives to be achieved by that date are defined
The end date for each increment within the project is fixed and the prioritised set of business and technical requirements to be satisfied by that date are defined
The end date for phase level activities is fixed, e.g. for the Feasibility Study, and the objectives for this project defined
The end date for part of the prototyping activity is fixed and the prototype is created, reviewed and tested according to the objectives defined in the timebox schedule contained in the Development Plan
The end time for a workshop, meeting or review is fixed and the participants work to the predefined and prioritised objectives.

None of these is possible without the ability to prioritise what must be achieved within the given timeframe (see Prioritization above). This enables items of lesser importance to be dropped (or items with greater importance to be added) as more is learnt about what needs to be done to satisfy the predefined objectives of the timebox.

A timebox must have an agreed scope and clear objectives based on a subset of the Prioritised Requirements List. An important aspect of timeboxes is that control is not activity-based. The aim of a timebox is to make something. How that thing is put together will be decided by the people doing the work, as long as the project's standards and procedures are followed.

A timebox will produce something visible in order for progress and quality to be assessed. Examples of what such a timebox could deliver include a part of the Functional Model, a partial system component or an early version of the system. All necessary reviews and tests are contained within the timebox, otherwise it will be difficult to fit any necessary rework or change into subsequent timeboxes. This means that a timebox contains at least one complete cycle of the Functional Model Iteration or the Design and Build Iteration, though possibly for only part of the total system.

Timeboxes are typically between two and six weeks in length: the shorter the better. However these limits are not mandatory. A major advantage of keeping timeboxes short is that the amount of work to be achieved within a timebox is smaller and therefore a greater degree of confidence is possible in effort estimates.

Timeboxes work through the effective application of empowerment. The team working in the timebox must agree the objectives and the developers and testers must themselves estimate the time required. At the deadline, the users must be able to approve the delivery of the products covered by the timebox. If it appears that deadlines could be missed, the deliverable should be de-scoped dropping the lower priority items, i.e. Should Have and Could Have requirements can slip and timing never does. Team must decide whether a requirement must be included in the current timebox or could be dropped from the increment or (worst case to be avoided if at all possible) slipped to a later timebox, which means that the whole timebox schedule needs to be revisited. (Note: the slippage of Must Have requirements usually necessitates escalation).

The one factor that does not change is the timebox deadline. This approach leads to the frequent delivery of products to the users on the project. It gives good project control, but makes management more intense. The detailed planning of a subsequent timebox containing dependent work cannot be started before the current timebox is complete. This is because the current timebox may deliver something that is incomplete. This could affect the objectives and activities of the dependent timebox. The timebox works best when the development team has good tool support that enables speedy delivery of products, be they models, documents or software. The teams must be able to build and evolve products quickly without being hampered by the technology they are using.

Modelling the system

Modelling helps the DSDM development team gain a good understanding of the business (aka game environment) domain. An image worthing a thousand words, more importantly, Models are essential communication tools to develop a common and mutually shared understanding over which collaborative working can take place. Through common understanding and sharing problems, more accurate models can be iteratively produced which reflect the ever changing realities of the EoC Universe that grows under collaborator/contributor creativity. So, sketching a problem is easier and faster than writing a document or posting comments in a forum.

Understanding can be gained by analyzing the problem from different viewpoints. Alternative viewpoints also helps the team describes and shares problems and opportunities in a coherent and cohesive manner amongst its members. Five common views, which can be used to generate differing levels of models, are:

the business view, which uses a selection of techniques to understand and interpret the business need and to model the business from a future perspective. Use of techniques such as business modelling, SWOT analysis and Critical Success Factors would be included in this view.
the processing view, which models the system as a set of business processes, or activities, which transform input data items to output data items. Processes can be either combined to form higher level processes, which in turn can be combined again to form yet higher level processes, or decomposed into their constituent sub-processes. This corresponds to the traditional "Why, What and How" type of questioning used during requirements elicitation.
the data view, which models the business information as a set of objects, or entities, and the relationships that exist between these objects
the behavioural view, which models the behavioural characteristics of the system in terms of a set of events and states, where events cause changes in the states of the system. Events may be generated within or external to the system.
the user interface view, which models the interactions and interfaces between the system user and the system itself.

For the Project Efforts will be made in parallel to produce pertinent supporting models in order to achieve our goal but also provide a base for future development cycles (iterations). The formalism used in the project will be UML 2.0.

Complete documentation

A free online version is available at :http://www.dsdm.org/version4/2/public/