Amy King

For the final requirement of my master's program, I wrote a paper on the practial use of software development process models. The paper's executive summary is below. The full version is available as a PDF.

Executive Summary

Uncertainty in business or system requirements seems an inescapable occurrence in software development projects. In 1970, when no standard process for software development existed, the Waterfall model, based on successful, established hardware development practices, was introduced to bring structure and discipline to software development.

Waterfall's rigid succession of phases requires careful, up-front planning of business requirements and technical constraints but provides no means to address change once system design and implementation have begun. Identifying inconsistencies or gaps in the system is left until Waterfall's later verification phase, at which time changes to the system's design or implementation can be costly. Waterfall is appropriate for certain types of projects such as those to develop a new system with requirements similar to a previously implemented system or a complex or expensive system requiring strict documentation and control. Waterfall's forced discipline is often cited as instructive and thus appropriate for inexperienced project managers, however, inexperience on the part of the project manager is likely to result in the very gaps in requirements which lead to Waterfall's failing. Even despite proper diligence, a project may still succumb to changes in requirements as the system is implemented or tested.

This fundamental flaw in Waterfall gave rise to agile models such as Spiral, Scrum, and Extreme Programming, each of whose central premise is that an iterative approach to software development best accommodates change. These models are widely recognized for their ability to allow a project to adapt as business and technical requirements evolve, however agile models require a shift in team and organizational culture which can be difficult to cultivate. Scrum and Extreme Programming especially rely on team communication and collaboration to move a project forward, an ability which requires small team size, good team rapport, and an enlightened organizational policy which empowers teams to self-organize and deliver product features incrementally rather than in a single, large release. If these conditions can be met, agile models can greatly boost both customer and management confidence in a project and can ensure the customer's satisfaction with the final delivered system. The Spiral model is especially applicable for projects requiring risk avoidance such as in the development of safety-critical or innovative systems. Scrum and Extreme Programming each offer the benefit of fast delivery of system features and close monitoring of customer satisfaction, making them well suited to projects whose business or technical requirements are expected to evolve during the course of the project.

When choosing a software development process model, an organization must consider its own compatibility with the model's key practices. Both an organization's culture and its policies for reporting or documentation must be weighed against the model's practices and requirements for success.

Unit testing is certainly an important practice, but the unspoken caveat is that a unit test is only as reliable as it is thorough.

During a recent Extreme Programming project where three teams (user interface, core business, and persistence) collaborated to develop an agile project management system, each team was responsible for writing unit tests for the interfaces they provided to another team. During integration, the comment I often heard from other teams in response to a report of a defect was,

"What do you mean it's throwing an exception? The unit test passes."

It was difficult to convince teams to revisit their code because the unit tests they had written were passing. The teams pointed to their successful unit tests as evidence their interfaces were fine.

The problem was the unit tests they had written didn't necessarily test an interface's behavior under application-realistic conditions. As seen in information security and other business areas, if the entity with the power to change a process and the entity which suffers pain when the process fails are not the same entity, the empowered entity has no incentive to change the process. If we apply this lesson to unit testing, perhaps the entity consuming an interface should write its unit tests. The consumer of an interface has incentive to write thorough tests. The producer of an interface has incentive to correct the interface when tests fail.