THE SETUP

Overview:

In six pairs of two the developers have implemented toy banking systems using their own Java based approach. There where four phases during the development of the software, as shown in figure 1. Each phase introduced new requirements that the implementations had to be adjusted for.

4 phases overview
Fig1. - A overview of the 4 phases.

After the second phase most teams split up and continued the implementation of the extension in different orders. The result is 10 different code bases that implement the same requirements using a different approach. See the result page for more info. Below we give more information into how the project was setup and the software/requirements that where implemented.

The software development:

The software system developed in this project a toy banking system. The main idea of the initial system is that a consumer should be able to open and use a bank account through this system. Initially the developers where given a short set of functionality requirements that the system should support and were asked to develop their own approach towards implementing this functionality.

After the developers had developed this initial system, the functionality of their systems converged by specifying a communication protocol that their systems should implement. This communication protocol made all functionality requirements more specific and reduced ambiguity.

In the last part the developers where subjected to two sets of functionality extension/alterations that they had to implement in order without knowing the next extension. These extensions cosistently altered requirements of the initial system or previous extensions, testing the agility of the system.

Additional requirements:

In addition to the set of functionality requirements that the developers had to implement, there was another set of requirements that the developers had to work with.
- The software should be written in Java. They were however free to use frameworks/libraries of their choosing.
- They had to use git as a version control system and tag different versions of their systems.
- They had to register the effort required for each part through the number of hours.
- They had to reflect on how all changing requirements impacted their approach.

The details:

On top of the initial set of requirements there have been 13 extensions defined that update the systems requirements. Based on all these requirements we have defined four different progress points (pp). For each progression point an increasing set of requirements has been implemented. Below you can find the (set of) requirements for each progress point in the project. Not all extensions where implemented in sequential order. All teams did first develop a system for the initial requiremets (step 0) and update this system for the protocol extension (step 1). But after these steps the teams split up and there were two routes defined in which the remaining extensions could be implemented. See below for an overview of these routes.

Route 1 Route 2 Progress point
Step 0 Initial system PP1
Step 1 Protocol Extension PP2
Step 2 Extension 2 Extension 3
Step 3 Extension 4 Extension 4
Step 4 Extension 5 Extension 2
Step 5 Extension 7 Extension 5
Step 6 Extension 6 Extension 6
Step 7 Extension 3 Extension 7
Test suite 1 PP3
Step 8 Extension 8 Extension 9
Step 9 Extension 11 Extension 8
Step 10 Extension 10 Extension 12
Step 11 Extension 9 Extension 13
Step 12 Extension 13 Extension 11
Step 13 Extension 12 Extension 10
Test Suite 2 PP4