Software Development Methodologies - Report Example

While advocates of both traditional and ‘agile’ software development methodologies often claim that their preferred method is ‘correct’, in fact both types of methodology are valid and can produce good results in appropriate circumstances. In inappropriate circumstances, however, even the best software methodology can result in anything from significant waste of resources to project failure—so it is obviously necessary to choose the correct methodology for use in any given situation. (It is worth noting as well that no methodology provides an absolute guarantee of good results if it is not implemented properly.) In order to make good methodology choices, it is important to understand the assumptions underlying each broad category of methodology; the methodology whose assumptions more closely match the situation being addressed is more likely to be successful. Traditional Methods: ‘The Waterfall Model’ Traditional software development methodologies were developed—or evolved—in the relatively early days of software development for business and industrial use. Several important factors that strongly influenced software development at that time are no longer true: The only non-academic organizations that owned computers were large businesses and government agencies; computers themselves were large, expensive, and not very capable by today’s standards. The tasks to be computerized were ones that had previously been performed by hand, such as payroll, accounting, inventory management, and so on. The goal of management when computerizing these processes was not so much to do something different, but to do the same thing faster, at less cost, and more accurately. The requirements for these applications changed only infrequently; the same was true (or was assumed to be true) for the structure of the organizations computerizing their processes. Because software was developed on a custom or semi-custom basis for (and often by) individual organizations, and because software was used basically as a more efficient way of carrying out old tasks rather than as a way to deliver new products and services, there was no particular pressure to be the ‘first to market’ for a given application. Given the cost and capabilities of computers, as well as the expense of software development, only vital organizational functions were computerized. In these applications, errors could be extremely costly. Home computers did not exist, and, outside of a small cadre of computer professionals, ‘computer literacy’ was extremely rare. Most workers felt threatened rather than liberated by computerization; even the change from cumbersome pen-and-paper processes to first-generation computerized processes that duplicated the same concepts and procedures met a great deal of resistance from the workers who had to deal with the new technology. Traditional software development methodologies reflect these realities and perceptions. At least in their unmodified ‘hard’ form, they assume a relatively rigid, hierarchical, compartmentalized staff structure, and an environment in which any non-trivial software change incurs a significant cost to the organization in both technical and social terms. More subtly, these methodologies implicitly assume that the correct functional design for a computer application is already ‘out there’ in the real world—and thus that the process of analysing requirements and producing a design to implement these requirements is more a matter of discovery than invention or creativity. By implication, if correct design is a response to a kind of ‘Platonic ideal’ of the system’s requirements, the creation and implementation of a computer application should not in any way change these requirements. According to this model, changes should occur only as a response to bugs or design flaws, or as a response to occasional ‘real world’ changes such as new regulations that impact the requirements of the system. Under this set of assumptions, the best development methodology was considered to be a thorough investigation of the requirements that the system must meet, followed by a series of sequential development stages to produce, implement, and support the software. This approach, eventually labelled the ‘waterfall model’, typically consists of the following phases: 1. Requirements analysis 2. System design 3. Coding 4. Integration (sometimes combined with coding and together labelled ‘implementation’) 5. Testing and debugging (also referred to as ‘validation’ or ‘verification’) 6. Installation (sometimes left out or combined with ‘implementation’) 7. Maintenance and support Each of these phases is meant to be completed before the next begins; and each phase typically involves different staff (although there is normally some overlap). Further, some phases involve multiple sub-phases: for example, testing might be divided into unit testing, integration testing, acceptance testing, and regression testing of post-release software changes—each handled by different staff, with its own set of test cases. At all points in the process, traditional methodologies stress the importance of thorough documentation, which must be updated in parallel with the software itself. The goal of traditional development methodologies is ‘to get it right the first time’, on the assumption that software flaws and post-release software changes are very expensive, and thus that it is worth a considerable investment at the outset to avoid such flaws and changes. This philosophy gave rise to another nickname for traditional methodologies: BDUF, standing for ‘Big Design Up Front’. Agile Software Development Methodologies It was not long before criticism of traditional software development methodologies began to appear. Critics found these methodologies to be slow, cumbersome, unresponsive, expensive, bureaucratic, and inappropriate for dealing with real-world needs and personalities. There was never any question that the traditional methodologies were largely intended to avoid mistakes; but according to critics, these methodologies often avoided mistakes mostly by avoiding getting any real work done. These criticisms eventually led to the creation of ‘agile software development’ methodologies. Agile methodologies nowadays are based upon their own set of facts and assumptions: Computers are now cheap and ubiquitous, and while not everybody loves them, the vast majority of potential users are relatively familiar with them and have come to accept (more or less happily) a process of ongoing, rapid technological change. The capabilities of computer software and hardware are now such that they can provide services and experiences far beyond what can be achieved without computers. As a result, the idea that the requirements for computer application design can be ‘discovered’ at the outset of the development process is no longer applicable (to the degree it ever was); once users have a chance to interact with a piece of software, they routinely come up with ‘wouldn’t it be nice if...’ ideas that, when implemented, generate even more new ideas. Software development is now a competitive industry. In the case of ‘shrink wrap’ software, establishing an early market presence can be much more important than avoiding all bugs; and even in the case of software developed for corporate use, new applications and features can lead to significant competitive advantage. Time-to-market is thus a much more important factor than it was in the early days of computerization. Many of the uses to which computers are put today are such that minor ‘glitches’ or design flaws are not all that serious a problem. For some types of software, ‘beta testing’ can be used to achieve market presence and even dominance without even having to claim that the released version is fully tested and debugged. In traditional development methodologies, a tremendous amount of time typically goes to waste. Reams of documentation are produced and never read (and, all too often, the documentation is obsolete and thus inaccurate by the time anyone does attempt to use it). Test plans and test cases are painstakingly created, and then fail to catch bugs and design flaws that quickly become apparent when the software is released for real-world use. Projects take so long that applications are often obsolete (or at least obsolescent) by the time they are delivered. And endless person-years are spent in meetings that produce little value. Programmers—who are, after all, the key to producing computer software—almost unanimously hate traditional design methodologies. Programmers do not, as a rule, work best in a hierarchical, highly-structured environment; they hate writing documentation, and they almost never read it. Worst of all, programmers hate being micro-managed (as tends to occur under traditional development methodologies); in fact, many talented programmers can hardly be managed at all, and do their best work when nobody tries very hard to manage them. The key characteristics of agile development are that it is adaptive, iterative, and people-centred. Instead of assuming that there is a ‘true’ set of requirements waiting to be discovered, agile methodologies recognize that needs change frequently, in large part as a result of what has already been delivered; the development cycle is thus a continual process of adapting to change (including, of course, changes in the capabilities of technological platforms). Because requirements and technologies are constantly shifting while there is a strong need to deliver products rapidly, development must consist of a many iterations of small-scale design-implement-test-release cycles rather than a Big Design Up Front followed by a single long development process. And agile methodologies recognize that the people involved in the design and implementation of computer software work better if they are not treated as elements in a huge, rigid, bureaucratic machine. As stated in the Agile Manifesto, agile developers value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The principles underlying this manifesto include—among other things—the frequent provision of working software, close cooperation between businesspeople and software developers, and a welcoming attitude to changing requirements at any stage in the development process. Agile development thus focuses on small, mixed, ‘self-organising’ teams, delivering updates or portions of a larger project at frequent intervals, responding rapidly to changing circumstances rather than aiming for a monolithic ‘get it right once’ solution. Advantages and Disadvantages In reality, traditional and agile development methodologies are better viewed as opposite ends of a spectrum rather than as completely different entities; and most real-world software development practice lies somewhere in between the two extremes. Even relatively traditional software projects typically make some accommodation to the fact that a perfect analysis of all requirements before development begins is rarely possible, for example; and even ‘agile’ projects usually involve some degree of structure and documentation, albeit at a much lower level than is found under traditional development models. The choice of the correct methodology is thus better visualized as turning a dial rather than flipping a switch. Both agile and traditional methodologies tend to cause problems when taken to an extreme. If traditional methodologies can be inefficient because of their overly rigid, unresponsive structure, agile methodologies can be inefficient if ‘looseness’ degenerates into total chaos. The correct ‘dial setting’ between traditional and agile methodology will depend on a large number of variables—some of which will be more or less important depending on the situation: If the central task of the software to be developed is well defined and relatively unchanging, such as administering bank accounts or keeping track of inventory, a somewhat traditional approach is likely to be appropriate—at least for the core functions that must conform to a pre-existing model of functionality. This is especially true if the software will be performing mission-critical business functions. If the software is addressing a more nebulously-defined need, or the situation is one in which less-than-perfect versions can be released and then replaced by better versions without causing damage or incurring heavy costs, then a more agile approach would be preferable. Obviously, even mission-critical software is best produced by agile methods if the requirements change frequently—for example, some businesses must cope with constantly-changing regulations that make it impossible to rely on infrequent ‘Big Design Up Front’ software releases. Software to be sold in ‘shrink-wrapped’ form typically needs to be brought to market quickly in order to grab and maintain market share, and even after release it must be kept up to date on a frequent basis. This situation favours agile development—although it is important to note that buggy or otherwise unsatisfactory releases of software can sometimes cause a great deal of damage, so software publishers should avoid letting agility degenerate into slovenliness. While it is theoretically possible to perform agile development within large, bureaucratic organizations, it is generally difficult to create and defend the kind of ‘garage’ atmosphere advocated by agile-development enthusiasts in the midst of a very different organizational culture. Sometimes, then, ‘agile’ must be reinterpreted to mean ‘as agile as possible’. Finally, it is worth noting that the choice of the ‘dial setting’ between traditional development methodology and agile software development should itself be treated in a somewhat ‘agile’ manner—that is, the correct mixture of structure and agility is likely to change from project to project, and even within the same project over time. Really good software development managers are flexible enough to recognize the merits of both traditional and agile approaches, and will combine elements of both approaches to meet changing circumstances. References Abrahamsson, P., Salo, O., Ronkainen, J. & Warsta, J., 2002, Agile software development methods, VTT Publications 478, available at http://www.pss-europe.com/P478.pdf . Ambler, S., 2006-2009, ‘The TAGRI (They Aren't Gonna Read It) Principle of Software Development’, available at http://www.agilemodeling.com/essays/tagri.htm . Beck, K. et al., 2001, ‘Manifesto for Agile Software Development’, available at http://agilemanifesto.org/ . Beck, K. et al., 2001, ‘Principles behind the Agile Manifesto’, available at http://agilemanifesto.org/principles.html . Centers for Medicare and Medicaid Services (CMS), U.S. Department of Health and Human Services, 2005 (revalidated 2008), ‘Selecting a Development Approach’, available at http://www.cms.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdf or http://tinyurl.com/3al9hcu . Marks, D., 2002, ‘Development Methodologies Compared’, N-Cycles Software Solutions, available at http://www.ncycles.com/e_whi_Methodologies.htm . Rosenberg, D., 2002, ‘Emperor's New Code’, available at http://www.softwarereality.com/lifecycle/xp/emperors_new_code.jsp . Sorensen, R., ‘A Comparison of Software Development Methodologies’, Crosstalk, Software Technology Support Center , January 1995, available at http://www.stsc.hill.af.mil/crosstalk/1995/01/comparis.asp . Waters, K., 2007 (?), ‘Agile Principle #5: How Do You Eat An Elephant?’, Agile Development Made Easy!, http://www.agile-software-development.com/2007/03/agile-principle-5-how-dyou-eat-elephant.html or http://tinyurl.com/2w5ocwr . Read More