Newsletters:

Why Software Development Projects Fail, Part III: Methodology - Page 1

Feb 18, 2009
By

Drew Robb






This series of five articles takes a closer look at software development, the reasons for failure and how to avoid them.

 

The previous article in this series dealt with the importance of project requirements. Once you have that nailed down, it is time to select the development methodology. While there are many different methods to choose from, each of which does work, picking the wrong one for a particular project could cause it to stall or, worse, fail.


 

Slow

 

Project managers have several different methods to choose from when selecting a software development model. One early method, which is still in use, is called the waterfall model. In 1970 Winston Royce, who worked on space mission planning software in the 1960s, described this method in a technical paper titled “Managing the Development of Large Software Systems.” The waterfall method consists of seven steps: requirements specification, design, coding, integration, validation, installation and maintenance. In this model, each step is fully completed before moving on to the next.

 

The advantage of waterfall development is that the requirements and design are finalized before moving into coding, which saves time later in the process. The disadvantage of waterfall is, in most cases, it is difficult to fully conceive of the end product before development and testing begins to take place.

 

“Large, heavily regulated organizations, such as in banking and insurance, are more conditioned to traditional waterfall: move everything from point A to point B and don’t move on until everyone is at point B,” said Jeff Monteforte, co-founder of Exential, an IT management consulting firm in Cleveland, Ohio. “Waterfall matches that type of a culture and organization.”

 

Faster

 

To overcome the slow pace of waterfall, several iterative approaches were created. The spiral model, developed by software engineer Barry Boehm while working for TRW in the 1980s, involves building a series of prototypes. It starts by defining an initial set of system requirements, creating a preliminary design and then a prototype. That first prototype is then tested and evaluated, and the requirements, design and construction phases are repeated to create a second prototype. The process is again repeated to create an operational prototype and finally a release product.

 

Fastest

 

Both waterfall and spiral development models are suited for large and lengthy projects. For faster results there is agile development which started gaining popularity in the 1990s. Agile development is typically done by small, multidisciplinary teams that put the software through a number of rapid iterations. This method makes it easier to respond to changes in requirements, but may not be suited to larger, mission-critical projects.

 

“When you have a small rapidly growing company that is doing a lot of work over the Web, their expectations for incremental functionality and value is so high, you have no choice but to do iterations or agile programming,” said Monteforte.

 

The basic waterfall, spiral and agile models each have a wide variety of offshoots and variations designed to meet different specific needs. "All these are great techniques,” said Monteforte. “It is a matter of matching up the right techniques to the right situation, client, culture, priorities and expectations.”

 

Mix and Match

 

So, how do you select the best method for a specific project? The choice depends on a number of factors including the stability of the requirements, whether your team is in one location or distributed, and the size of the project. But there are some general guidelines: when the specifications are likely to change, agile programming works best; when there is a formal and procedure-based customer culture (such as government or military), use waterfall; product development tends to use a spiral approach. But these methods can overlap, such as using iterations and daily planning in a waterfall project, or thoroughly documenting an agile one.

 

“Every methodology should be considered as a set of techniques, which can be combined and applied differently, depending on your customer and project needs,” said Mikhail Bykov, CTO of Luxoft, a Russian application development outsourcer. “The best solution here is not to follow some methodology blindly, but understand its strength and reasons, and use them consciously.”

 

Abid Ali Neemuchwala, VP and head of Global Process Excellence at Tata Consultancy Services (TCS), said that while his firm selects the technology in consultation with the customer, there are very well defined guidelines they use to make the final decision.

 

Page 1 of 2


Tags: collaboration, programming, IT architecture, Agile programming, software quality,
 

0 Comments (click to add your comment)
Comment and Contribute

Your comment has been submitted and is pending approval.

Author:

Comment:

 (click to add your comment)

Comment and Contribute

Your name/nickname

Your email

Comment:

(Maximum characters: 1200). You have characters left.