Higher Quality Software through Enhanced Process

Software quality is a very subjective term and means many different things to many different people. Consistently, a part of the definition of software quality includes whether or not the software was delivered on time, and whether or not the software was delivered on budget. The evolution of software development processes has resulted in software that is much more consistently delivered both on time as well as on budget.

The Standish Group is an organization with years of experience in assessing risk, cost, return and value for information technology investments. Formed in 1985, the Standish Group’s vision was to collect case information on real life information technology (IT) project failures and environments to deliver advice based on collective wisdom. In 1994, The Standish Group published The Chaos Report which was focused on identifying the scope of software project failures, the major factors that cause software projects to fail and the key ingredients that can reduce project failures. The Chaos Report surveyed IT executive managers representing all sizes of companies across major industry segments, including banking, manufacturing, retail, and healthcare (Standish, 1994).

The Chaos Report classifies projects into three resolution types. First, successful projects are completed on-time and on-budget, with all features and functions as initially specified. Second, challenged projects that are completed and operational, but over-budget, over the time estimate, and offer fewer features and functions than originally specified. Lastly, impaired projects are projects that have been cancelled at some point during the development cycle. Successful projects account for only 16.2% of respondents, while challenged projects accounted for 52.7%. Cancelled projects accounted for 31.1% (Standish, 1994). To put that another way, 83.8% of software projects that started were not successful.

Since 1970, the most common process used to develop software is called the waterfall process. Initially used for developing computer hardware, it is called the waterfall process due to the way the process emphasizes completion of a phase of development prior to proceeding to the next phase (Sorensen, 1995). The waterfall development process is best known for its well-defined and demarcated phases to development.

According to Sorensen (1995), the waterfall development process strongly emphasizes a formal, top-down model, which is composed of independent phases to be done sequentially. The most common phases to the waterfall model as it relates to software development are planning and analysis, development, followed by testing and deployment. To complete the planning and analysis phase, the expectation is placed on the customer to know all required features of the system in advance. Only when every feature has been planned and analyzed are the software engineers engaged to develop the software application. Once the entire software application has been developed it is turned over to a quality assurance group to perform testing of the application.

Certain strengths have been identified to support the waterfall model for software development, including reporting capabilities, workforce specialization and the ability to predict resource allocations. However, the stronger weaknesses discussed above have led to recommendations like “the application of the waterfall model should be limited to situations where the requirements and the implementation of those requirements are very well understood” (Sorensen, 1995).

In 2001, several prominent software developers, including Martin Fowler, Ward Cunningham and Alistair Cockburn realized that there were many inherent problems with the waterfall model and sought ways to make the software development process more nimble, or agile. This group came together to form the Manifesto for Agile Software Development. The Manifesto for Agile Software Development (2001) is committed to “uncovering better ways of developing software by doing it and helping others do it”. To this end, the manifesto defines four core values which are intended to enhance software quality. First, agile methods value individuals and interactions over process and tools. Second, working software is valued over comprehensive documentation. Third, customer collaboration is valued over contract negotiation. Lastly, agile methods prefer responding to change over following a plan.

There are two primary differences between agile and the waterfall models. The waterfall model is very predictive as it tries to anticipate every requirement prior to beginning development. The predictive model works very well until things change, so very often waterfall models are resistant to change. Agile methods rely on an adaptive model for developing software, in which the development of the software applications adapts to changes in customer requirements. Agile methods welcome change, adapt and thrive on change, going even so far as to changing themselves. The second primary difference between agile and waterfall models is that agile methods are people-oriented rather than process oriented. The waterfall model is intended to work well by anyone implementing it. Rather than try to be all things to everyone, agile methods support the development team by allowing them to respond quickly to change. (Fowler, 2005).

There are numerous agile development methodologies, although the most common methodology uses a combination of Scrum for project management and Extreme Programming (XP) for specific practices that software engineers can use in their day-to-day tasks. Scrum is a simple method for the management of complex projects which allows practitioners to embrace change, release creativity and increase productivity.

Standish Group founder and Chairman Jim Johnson (1999) states that there are three metrics that can determine the potential for success of a given project: project size, project duration, and team size. Research confirms that small projects have higher success probability than large projects. Smaller teams and shorter projects have also been confirmed to result in more successful projects. Scrum places emphasis on all three of these pillars.

In conjunction with the founder of the scrum methodology, Softhouse (2006) defines the three primary roles in a scrum team as the product owner, the scrum team and the scrum master. The product owner acts as the voice of the customer and ensures that the team is working on the correct things as they relate to the business. The product owner administers a product backlog, which is “a current to-do list where all the specifications for a product are listed according to how profitable they are deemed to be” (Softhouse, 2006). The scrum team is a group of 5-9 people who function as the problem solvers and designers. The scrum team is a self-managing team; the team members decide how to arrange the work and who performs the work. The scrum master is the scrum coach for the development team. The responsibility of the scrum master is to remove any speed impediments from the scrum team and makes sure that the scrum team has the best possible working circumstances to achieve their goals.

Scrum is centered on what are called iterations or sprints. A sprint is a time-boxed focus on a specific set of goals. Although the prescribed sprint time is 30 days, a sprint can be anywhere between one and six weeks in duration. Prior to the beginning of the sprint, a product owner creates a product backlog, which is a prioritized list of all functionality desired for the product. Once the product backlog is ready, a scrum team forms which contains the people who are responsible for the success or failure of the sprint. During the sprint, discussions are had with the product owner to determine the goal of the sprint and to break down prioritized functionality to the task level. After the team has determined the tasks and required time to complete the sprint, the product owner steps away. Now the scrum team is completely self-managing and collectively responsible to the success or failure of the iteration. Every day, at a time set by the team, the scrum team has a brief meeting with the scrum master. Each member of the team is expected to answer three questions: What has the team member done since the last meeting? What will the team member do between now and the next meeting? Is there anything preventing the team member from doing what was planned? The first two questions provide a commitment from the individual to the rest of the team as well as giving the scrum master insight into the progression of the project. The last question provides insight to the scrum master into problems that the individual is having and serves as a starting point for problem-solving. At the end of the sprint, a feedback or demonstration session is held with a larger group, consisting of not only the product owner, but also users and corporate representatives. This session serves as the starting point for the next sprint (Softhouse, 2006).

Scrum has done very well to establish itself as an effective project management tool for software development. Extreme Programming operates more at the tactical level and provides guidelines for how the team develops the software. Certain principles, such as user involvement and daily meetings, dovetail into the scrum philosophy as well. The benefits of XP as an agile method to develop high quality software are found in the principles around the coding and testing phases.

In the coding phase, XP states that code must be written to agreed standards to help keep a consistent format. Consistent formatting makes understanding the code easier and quicker for everyone on the team. In addition, all production code is written by a pair of developers working together at a single workstation. Some people will argue that this is counter-intuitive, but these two people working at a single computer will produce as much functionality as two working separately. The difference is that the quality of output will be much higher, because the pair is consistently getting feedback by having two sets of eyes on the project. Lastly, XP emphasizes a collective code ownership paradigm which allows any member of the team to add functionality or fix bugs. In this way, no single person becomes the bottleneck. The strong benefit from this is that the entire system is not held in the mind of a single person but rather the collective mind of the team (Wells, 1999).

In the testing phase, XP emphasizes unit tests on all production code and all code must pass all unit tests before it can be released. Unit tests are defined as a piece of code that tests the production code in the system and makes sure that the code under test performs exactly in the way that it was intended to. Developers working in an Extreme Programming model very often will write unit tests first. A developer will create on test to define a small aspect of the problem, after which the developer will create the simplest code possible to make that test pass. After that a second test is added, and once again, the developer writes the simplest code possible to make that new test pass. This continues on until there is nothing left to test, at which time the developer knows that he is done. The advantage to writing tests first is that at any time the overall quality of the software system can be known (Wells, 1999).

Research published by The Standish Group in the previously mentioned Chaos Report states that for successful projects, 15.9% of the respondents believe that user involvement was the primary cause for success. 13% of respondents believe that a clear understanding of user requirements was the primary cause for success. In projects that were ultimately delivered but were late, over-budget, or some other way devoid of the initial expectation, 12.8% of respondents believe that lack of user input was the primary cause for the project being challenged. 12.3% of respondents believe that incomplete user requirements were the cause. In projects which were cancelled, the numbers are very similar. 13.1% of respondents believe that incomplete requirements were the cause of failure, while 12.4% believe that lack of user involvement were to blame.

Agile development methodologies address both of these causes of project failure. Jim Johnson (2006) states that he is “a big believer in Agile, having introduced the iterative process in the early 90s and followed with the CHAOS reports on quick deliverables”. Agile development has helped by breaking down projects into manageable pieces. If something goes wrong, the organization is aware of it early rather than much later in the project. Constant interactions with the user of the software leads to building exactly the software that the user is expecting. The adaptive nature of the agile development methodologies ensure that when a customer does change their mind, the development can continue effectively, without major effects on the timeline or on the budget. The iterative approach that agile development emphasizes in conjunction with the constant feedback that is solicited from the customer makes this methodology very effective in delivering high quality, on-time and on-budget software.

References