Test Driven Development

Inspired by the “test first” philosophy from XP, Test Driven Development (TDD) starts the development process by coding automated test cases for the software features that are to be produced. Then, production code is developed iteratively until all the tests are passed. After each cycle (iteration), all of the tests are re-run to ensure that new functionality is well integrated. Refactoring is performed to maintain quality and remove duplication in both production and test code. Figure 9 illustrates this process as practiced by a software development group at IBM (Maximilien & Williams 2003).

TDD’s test-first approach is reported to have a significant impact on defect prevention, but more importantly it influences the design of the software. Since developers must focus on the interfaces of their modules (this helps in developing modules to pass the unit tests) it means that they must employ a type of “Design by Contract” (often referred to as “DbC”) approach to software development. Test-first code tends to be more cohesive and less coupled than code in which testing isn’t part of the intimate coding cycle (Beck 2001). In a nutshell, Kent Beck, the creator of XP and TDD, lists the benefits of a test-first approach as follows:

·         Encourages you to be explicit about the scope of the implementation,

·         Helps separate logical design from physical design from implementation,

·         Grows your confidence in the correct functioning of the system as the system grows.

·         Simplifies your designs.

Feature Driven Development

Feature Driven Development (FDD) is described as having “just enough process to ensure scalability and repeatability and encourage creativity and innovation all along the way” (Highsmith 2002a). As shown in Figure 10, FDD breaks the system into feature sets, and iterates to produce incremental client-valued pieces of functionality. FDD can be summarized by its eight “best practices”:

·         Domain object modelling: Since FDD was developed originally in 1997 for a Java language-based project, it is tailored to an Object-Oriented (OO) approach. FDD calls for building class diagrams to capture the attributes and relationships between the significant objects in the problem space.

·         Developing By Feature: The system is broken up into a set of features which can be developed incrementally. In FDD, a feature is a small, client valued function that can be implemented in two weeks (Goyal 2007).

·         Individual class ownership: Unlike XP, which calls for “collective code ownership”, FDD asks that each class (a unit of code in OO programming) is assigned to an individual who is ultimately responsible for it.

·         Feature teams: Features are developed by teams comprised of feature owners and a combination of the class owners needed to implement the given feature.

·         Inspections: formal code reviews are held to prevent defects and ensure quality.

·         Regular builds: Allows early detection of integration problems, and makes sure there is always a current build available to demo to the customer.

·         Configuration management: The use of source control and version tracking.

·       Reporting and visibility of results: Progress for each feature is based on the completion of development milestones (e.g. Design completion, Design Inspection Completion, etc.) Progress of the feature sets is regularly reported.

FDD is similar to the “agile modelling” methodology since it relies on a UML (Unified Modelling Language) model of the system.

Crystal Methods

On a quest to develop an effective software methodology, Alistair Cockburn interviewed and studied project teams for 10 years. He found that “people-centric methodologies” do better than “process-centric” methodologies, and that one must choose and tailor the methodology to the team and the assignment - no methodology fits all projects. (Cockburn 2004) The result is Crystal, which is actually a family of methods, rather than a single methodology, developed to address the variability between projects. Projects are sized along two dimensions: team size, and program criticality. A version of Crystal is subsequently chosen and adapted to the specifics of the project. See Figure 11.

Team Size accounts for the fact that as a team gets larger communication costs rise and face to face communication becomes less effective. More management and coordination become required. Criticality on the other hand measures the system’s “potential for causing damage” ranging from “loss of life” to “loss of comfort.” The combination of team size and the criticality directs a given development effort towards a corresponding Crystal methodology. There are only two rules that govern the practice of the Crystal family of methods.

1) Incremental cycles cannot exceed four months.

2) Reflection workshops must be held after every delivery so that the methodology is self-adapting.

Crystal “focuses on people, interaction, community, skills, talents, and communication as first order effects on performance. Process remains important, but secondary” (Highsmith 2002a)