Picking up the thread from a
previous post on structured software design and CASE, it’s worth examining some of the major development methodologies and their evolution. Where SA/SD and CASE deal with the process of designing and creating software products, methodologies are concerned with the process of getting them built. They exist within the realm of project management and as such, are concerned with managing a host of entities, not the least of which is people.The human element of a typical software project takes the form of customers, often referred to as stakeholders, project manager(s), development team, test team, configuration management personnel, tech writers, other management, and just about anyone else looking to join in the fun from the guy who sweeps the floors to the HR department. If there’s a physical component involved then folks from the hardware team will be included. And if any hardware is involved, you can be assured that the delivery timeline will be doubled. Just kidding, or am I?As you might imagine, managing such a diverse set of personnel can get challenging in a hurry. Throw Mr. Murphy's law into the mix and project schedules and deliveries can quickly get blown to bits. Early on in the game, the need for managing the chaos associated with a software development effort quickly became apparent.In this post I’ll provide a very broad overview in order to at least get the discussion going. It would be impossible to cover all of the existing methodologies. Without exaggeration, there are more
methodologies in existence than there are obscure sects of every world religion combined! Not to mention, that the adherents of each are just as passionate as any religious zealot.For now, let’s take a 30,000 foot overview of the methodology landscape and just examine a few of the major approaches and how each evolved.
Waterfall Model
Not long after the first digital computers came into existence, approaches for managing software development projects emerged. The forebear was a linear process consisting of discrete phases which has become known as the “waterfall” model. It was a development process that had its origins in the manufacturing industry and consists of the following steps or phases:
- Requirements
- Design
- Implementation
- Verification
- Maintenance
When diagrammed, it’s easy to visual how progression through the model proceeds like a cascading waterfall. Such a model requires that each step be completed prior to advancing to the next in the cascade. It also relies heavily on extensive documentation. This latter step often adds time to the overall project but pays dividends in the event of staff turnover: new members can quickly get up to speed by reading over the design documents. The waterfall model is also easier to manage due to its clearly-defined steps, however, such rigidity also comes with considerable disadvantages.Going back to the manufacturing industry, it's critical to get the stuff up front nailed down and right the first time. Discovering that the car you’re building would work better as a four-door rather than sporting two doors is an expensive proposition. The same holds true for software: changes to requirements after the project has tumbled down to the latter stages of the waterfall are costly to implement. In many cases, it requires tearing up the design, throwing out months of work and starting from scratch. Despite many of its drawbacks, the waterfall method was mandated for many years as the development process of record for U.S. Department of Defense (DoD) contracts.
Variations on a themeThe aforementioned rigidity and attendant drawbacks associated with the waterfall model eventually led to several modified spinoffs. A more flexible approach capable of adapting to inevitable requirements changes was sorely needed. Two of the more prominent variations on the waterfall model are the incremental and spiral development models.The hallmark of the incremental model is short development cycles that essentially progress through the major phases of the waterfall model at a much faster pace thus reducing the risk and cost of any subsequent changes. Things that are learned during each “mini” dev cycle are then applied to the next one with the product growing in complexity until complete, similar to a snowball picking up size as it rolls downhill.The spiral model is essentially a type of incremental development model and is often a hybrid of several models such as waterfall, incremental, and evolutionary prototyping. Its distinguishing characteristic is its risk-driven nature. The risks of a particular project determine which sub-models, or more accurately, process models, will be incorporated into the final development approach. These next generation development methodologies evolved to contend with the risk inherent in every software development project as a result of shifting product requirements.
Agile: built to handle changeDuring the early 1990s, an explosion of new development methodologies appeared on the scene. The motivation, as was the case with incremental and spiral methodologies, was to finally come to grips with the ever-changing nature of product requirements. During the same time period, there was also an explosion in the variety of computing platforms and types of applications that ran on them. Pressure to deliver quickly began to put the squeeze on delivery schedules. Software had to be delivered fast and it had to be bug-free.A new concept in software development methodologies emerged known as “agile” development. Proponents of agile methodologies can be quite strident about how their beloved approach is the ultimate one and anything else isn’t worth the time to consider. The religious zeal in the agile community is strong. There’s even an Agile Manifesto.Key agile methodologies are scrum, Kanban, extreme programming (XP), rapid application programming (RAD), feature-driven development, and the agile unified process. What they all have in common is an ancestry with incremental development. They were all developed to deal with change. Close participation with customers and other stakeholders in the development process is typical of the agile approach. Stakeholders get to examine a working product - no matter how simple - at frequent stages of the project. This allows for more timely feedback and design adaptation. Agile is built for change and in fact, welcomes it! The scrum methodology operates on short, intense design cycles know as "sprints" ranging from 2-4 weeks. A working product is demonstrated to stakeholders at the end of each sprint.Despite its disparagement and well-established drawbacks, the waterfall model is still the most heavily model in use today, though the DoD has finally moved away from it and now prefers an agile approach. With such a wealth of development methodologies, there was no conceivable way that I could have done them justice in a single post. Rather than map out a rigid set of posts at this juncture on more in-depth coverage, I think I’ll adopt an agile approach and see what evolves from this one. In the meantime, if this is a topic that interests you and you’d like to learn more, Cybrary.it has you covered with courses on
Project Management (PM) and
secure coding practices. Dig in!
