Towhidul Haque Roni– Software Engineering Senior Analyst, Accenture
The software development process is a creative process and we need adaptive method to successful at it. The software development process has been evolved over 80 years. During these periods, lots of software development methodology emerged and gone extinct. Each one has or had some pros and some cons.
Initially programmers wrote code and delivered it directly to the client and waited for any error occurrence either from clients dissatisfaction by not meeting their requirements or application malfunction. Then they rewrote the code and delivered it to the client. It was challenging job, more over the size of the code was getting bigger and complex. To manage these challenges, the waterfall methodology came in 1956, though the term “waterfall” coined at 1976. In the waterfall methodology, the software development process is split to several phases, such as – 1) Requirements Analysis 2) Design 3) Coding 4) Testing and 5) Deployment. In this methodology, each phase must be completed before the next phase began. In addition, the phases do not overlap and once you have completed a phase, you cannot go back to any previous phase, just like waterfall flows in one direction. This methodology is suitable when requirements are well organized, fixed and clear, and the technology is clearly understood.
In practical, sometimes clients do not aware of what they exactly want before watching a workable software and so they change their requirements, which leads to redesign and development and increased costs. Also the designer sometimes could not predict the upcoming difficulties and requires redesign with addressing the new constrains. That is why pure waterfall is not suitable for complex, long, and ongoing projects. Also not recommended where there is a high chance of requirements change. Most important thing in this methodology is the limited involvement of the customer, which can cause to miss the market need.
Since 80s, software engineers were searching for any good alternative to waterfall and experiments with “Iterative” and “Incremental” approaches where small chunk of workable code regularly delivered and capture the feedback to improve the delivery consecutively. In 1988, the “Spiral Model” was introduced which was the combination of the “Iterative” and “Waterfall”.
In spiral model, the development process has four phases, where a software project repeatedly passes through the phases in iterations called Spiral. The phases are 1) Identification 2) Design 3) Construct and build 4) Evaluation and Risk Analysis. This model allows requirements change, uses prototypes, allow user to see the system earlier and most important thing is it divided the development into smaller parts, which help to identify the risky part earlier. The problems of this methodology are the management is more complex and this is not suitable for low risk or small projects. It also requires huge documentation during the intermediate stages.
In1991, another type of incremental model, named Rapid Application Development (RAD) model, came. In this model, features or the components are developed in parallel as if they were small discrete projects. This is suitable when there is urgency of quick software development, availability of high budget and skilled resources. In 1986, Scrum mythology comes and in 1999 Extreme programming (XP) introduced. Both methodology follow the short iteration which lead to small incremental releases with focusing on successfully serve the business.
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss these lightweight development methods. They introduce the ‘Agile’ methodology which is more flexible, efficient, team-oriented and each iteration in the development cycle “learned” from the previous iteration. Although rapid application development (RAD), unified process (UP) and dynamic systems development method (DSDM), Scrum, Crystal Clear and extreme programming (XP) and feature-driven development originated before the publication of the Agile Manifesto, they are now collectively referred to as agile software development methods. All the agile methods follows the Agile Manifesto and twelve core principles.
The Agile Manifesto
Based on their combined experience of developing software and helping others do that, the seventeen signatories to the manifesto proclaimed that they 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
That is, while there is value in the items on the right, they value the items on the left more.
Agile software development core principles
The Manifesto for Agile Software Development is based on the following twelve principles –
- Customer satisfaction by early and continuous delivery of valuable software
- Welcome changing requirements, even in late development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
Agile definitely a cool thing but you have to understand in which circumstances you should use and when not to use. I have define and redefine many IT companies engineering process, which includes startup to fortune 100 company. For example, few years back I have revamped engineering process of GrameenPhone IT, which awarded as CMMI level 3. In that organization, for the VAS (Value Added Service) campaign development I used the waterfall methodology as the effort was less than 20 days and the requirements were pretty specific. But in the same organization, when we developed any large telco product or any COTS product, I preferred the agile. Unlike the waterfall model in agile model, very limited planning is required to get started with the project but this planning is very much important. Before jumping to agile, an organization must think why do they will chose agile methodology? Is it beneficial? What are the challenges that this organization will face? Sometimes organization just chose agile but do not train their people or do not choose proper tools. It is very important to choose right tools and train all the people, not limited to the developers only. Considering the above facts, a project can be chosen for agile if it has an aggressive deadlines, a high degree of complexity, and a high degree of uniqueness.
- Why Agile? - March 3, 2018
- IoT Security - May 4, 2017