Software Development Methodologies Part1

In software engineering, a software development methodology (also known as a system development methodology, software development life cycle, software development process, software process) is a splitting of software development work into distinct phases (or stages) containing activities with the intent of better planning and management. It is often considered a subset of the systems development life cycle. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.
Common methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, extreme programming and various types of agile methodology. Some people consider a life-cycle "model" a more general term for a category of methodologies and a software development "process" a more specific term to refer to a specific process chosen by a specific organization. For example, there are many specific software development processes that fit the spiral life-cycle model.

A variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One software development methodology framework is not necessarily suitable for use by all projects. Each of the available methodology frameworks are best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system.

There are the following methodologies:

• Agile Software Development
• Crystal Methods
• Dynamic Systems Development Model (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Joint Application Development (JAD)
• Lean Development (LD)
• Rapid Application Development (RAD)
• Rational Unified Process (RUP)
• Scrum Model
• Spiral Model
• V- Model
• Incremental Model
• Iterative Model
• Prototyping Model
• Waterfall (a.k.a. Traditional)
• Systems Development Life Cycle (SDLC)

Agile Software Development Methodology

Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methodologies e.g. Crystal Methods, Dynamic Systems Development Model (DSDM), and Scrum.
 Most agile methods attempt to minimize risk by developing software in short time boxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities.
 Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish the software. At a minimum, this includes programmers and the people who define the product such as product managers, business analysts, or actual customers. The bullpen may also include testers, interface designers, technical writers, and management.
 Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods.

Advantages of Agile model:

• Customer satisfaction by rapid, continuous delivery of useful software.
• People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.
• Working software is delivered frequently (weeks rather than months).
• Face-to-face conversation is the best form of communication.
• Close, daily cooperation between business people and developers.
• Continuous attention to technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed

Disadvantages of Agile model:

• In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.
• There is lack of emphasis on necessary designing and documentation.
• The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
• Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

When to use agile model:

• When new changes are needed to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced.
• To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it.
• Unlike the waterfall model in agile model very limited planning is required to get started with the project. Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world. Changes can be discussed and features can be newly effected or removed based on feedback. This effectively gives the customer the finished system they want or need.
• Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; meaning the project can continue to move forward without fear of reaching a sudden standstill.

"Agile software development" refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve via collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.
There are many agile methodologies, including:

• Dynamic systems development method (DSDM)
• Kanban
• Scrum

Crystal Methods Methodology

Alistair Cockburn developed the Crystal Methods approach. His focus is on the people, interaction, community, skills, talents, and communications with the belief that these are what have the first-order effect on performance. Process, he says, is important, but secondary.
 Cockburn's philosophy translate into a recognition that each team has a different set of talents and skills and therefore each team should use a process uniquely tailored to it. And it means that the process should be minimized - barely significant.
 The use of the word “crystal” refers to the various facets of a gemstone - each a different face on an underlying core. The underlying core represents values and principles, while each facet represents a specific set of elements such as techniques, roles, tools, and standards. Cockburn also differentiates between methodology, techniques, and policies. A methodology is a set of elements (practices, tools); techniques are skill areas such as developing use cases; and policies dictate organizational “musts”.

Dynamic Systems Development Model Methodology (DSDM)

The Dynamic Systems Development Model was developed in the U.K. in the mid-1990s. It is the evolution of rapid application development (RAD) practices. DSDM boasts the best-supported training and documentation of any of the agile software development techniques, at least in Europe. DSDM favors the philosophy that nothing is built perfectly the first time and looks to software development as an exploratory endeavor.

The nine principles of DSDM are:

• Active user involvement.
• Empowered teams that the authority to can make decisions.
• A focus on frequent delivery of products.
• Using fitness for business purpose as the essential criterion for acceptance of deliverables.
• Iterative and incremental development to ensure convergence on an accurate business solution.
• Reversible changes during development.
• Requirements that is baselined at a high level.
• Integrated testing throughout the life cycle.
• Collaboration and cooperation between all stakeholders.

Extreme Programming (XP) Methodology

XP is a methodology for creating software within a very unstable environment. It allows flexibility within the modelling process.
 The main goal of XP is to lower the cost of change in software requirements. With traditional system development methodologies, like the Waterfall Methodology, the requirements for the system are determined and often “frozen” at the beginning of the development project. This means that the cost of changing the requirements at a later stage in the project - something that is very common in the real-world can be very high.
 XP Core Practices
The core practices of Extreme Programming, as described in the first edition of “Extreme Programming Explained” can be grouped into four areas (12 practices) as follows:
 Fine scale feedback

• Test driven development
• Planning game
• Whole team
• Pair programming

 Continuous process rather than batch

• Continuous Integration
• Design Improvement
• Small Releases

Shared understanding

• Simple design
• System metaphor
• Collective code ownership
• Coding standards or coding conventions

 Programmer welfare

• Sustainable pace (i.e. forty hour week)

 In the second edition of “Extreme Programming Explained” a set of corollary practices are listed in addition to the primary practices.
The core practices are derived from generally accepted best practices, and are taken to extremes:

• Interaction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site, who specifies and prioritizes work for the team, and who can answer questions as soon as they arise. (In practice, this role is sometimes fulfilled by a customer proxy.)
• If learning is good, take it to extremes: Reduce the length of development and feedback cycles. Test early.
• Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs at the present time in a project, and go to some lengths to reduce complexity and duplication in their code.
• If simple code is good, re-write code when it becomes complex.
• Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves communication) so that all code is reviewed as it is written.
• Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered complete when it passes the tests (but then it needs refactoring to remove complexity). The system is periodically, or immediately tested using all pre-existing automated tests to assure that it works. See test-driven development.

 It used to be thought that Extreme Programming could only work in small teams of fewer than 12 persons. However, XP has been used successfully on teams of over a hundred developers.

Feature Driven Development Methodology (FDD)

Jeff De Luca and Peter Coad were both greatly involved in developing the Feature Driven Development methodology. Peter describes FDD as having just enough process to ensure scalability and repeatability while encouraging creativity and innovation.
 More specifically, Feature Driven Development asserts that:

• A system for building systems is necessary in order to scale to larger projects.
• A simple, but well-define process will work best.
• Process steps should be logical and their worth immediately obvious to each team member.
• “Process pride” can keep the real work from happening.
• Good processes move to the background so team members can focus on results.
• Short, iterative, feature-driven life cycles are best.

FDD proceeds to address the items above with this simple process (numbers in brackets indicate the project time spent):
 1. Develop an overall model (10 percent initial, 4 percent ongoing)
2. Build a features list (4 percent initial, 1 percent ongoing)
3. Plan by feature (2 percent initial, 2 percent ongoing)
4. Design by feature
5. Build by feature (77 percent for design and build combined)

 Joint Application Development (JAD) Methodology

 JAD is a requirements-definition and user-interface design methodology in which end-users, executives, and developers attend intense off-site meetings to work out a system's details. So the Joint Application Development (JAD) methodology aims to involve the client in the design and development of an application. This is accomplished through a series of collaborative workshops called JAD sessions. Two employees of IBM, Chuck Morris and Tony Crawford, developed the JAD methodology in the late 1970s and began teaching the approach in to the 1980s.

 JAD focuses on the business problem rather than technical details. It is most applicable to the development of business systems, but it can be used successfully for systems software. It produces its savings by shortening the elapsed time required to gather a system's requirements and by gathering requirements better, thus reducing the number of costly, downstream requirements changes. Its success depends on effective leadership of the JAD sessions; on participation by key end-users, executives, and developers; and on achieving group synergy during JAD sessions.
 In contrast to the Waterfall approach, JAD is thought to lead to shorter development times and greater client satisfaction, both of which stem from the constant involvement of the client throughout the development process. On the other hand, with the traditional approach to systems development, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews.
 Rapid application development (RAD), a variation on JAD, attempts to create an application more quickly through strategies that include fewer formal methodologies and reusing software components.

Lean Development (LD) Methodology

Lean Development focuses on the creation of change-tolerant software. This methodology embodies the notion of dynamic stability which can be thought of as similar to how Scrum embraces controlled chaos. Bob Charette, the originator, writes that the measurable goal of LD is to build software with one-third the human effort, one-third the development hours and one-third the investment as compared to what SEI (Software Engineering Institute) CMM Level 3 organization would achieve.
There are 12 principles of Lean Development:
1. Satisfying the customer is the highest priority.
2. Always provide the best value for the money.
3. Success depends on active customer participation.
4. Every LD project is a team effort.
5. Everything is changeable.
6. Domain, not point, solutions.
7. Complete, don't construct.
8. An 80 percent solution today instead of 100 percent solution tomorrow.
9. Minimalism is essential.
10. Needs determine technology.
11. Product growth is feature growth, not size growth.
12. Never push LD beyond its limits.

Rapid Application Development (RAD) Methodology

“Rapid-development language” is a general term that refers to any programming language that offers speedier implementation than do traditional third-generation languages such as C/C++, Pascal, or FORTRAN. Rapid-Development Languages (RDLs) produce their savings by reducing the amount of construction needed to build a product. Although the savings are realized during construction, the ability to shorten the construction cycle has project wide implications: shorter construction cycles make incremental lifecycles such as Evolutionary Prototyping practical. Because RDLs often lack first-rate performance, constrain flexibility, and are limited to specific kinds of problems, they are usually better suited to the development of in-house business software and limited-distribution custom software than systems software.
 RAD (rapid application development) proposes that products can be developed faster and of higher quality by:

• Using workshops or focus groups to gather requirements.
• Prototyping and user testing of designs.
• Re-using software components.
• Following a schedule that defers design improvements to the next product version.
• Keeping review meetings and other team communication informal.

There are commercial products that include requirements gathering tools, prototyping tools, software development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development.

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business information flow to achieve some specific business objective. Description are identified and created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the actual system.
Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

·         Reduced development time.

·         Increases reusability of components

·         Quick initial reviews occur

·         Encourages customer feedback

·         Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

·         Depends on strong team and individual performances for identifying business requirements.

·         Only system that can be modularized can be built using RAD

·         Requires highly skilled developers/designers.

·         High dependency on modeling skills

·         Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

 When to use RAD model:

RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time. It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).

Rational Unified Process (RUP) Methodology

The Rational Unified Process attempts to capture many of modern software development's best practices in a form suitable for a wide range of projects and organizations. This process recognizes that the traditional waterfall approach can be inefficient because it idles key team members for extended periods of time. Many feel that the waterfall approach also introduces a lot of risk because it defers testing and integration until the end of the project lifecycle. Problems found at this stage are very expense to fix.
 By contrast, RUP represents an iterative approach that is superior for a number of reasons:

• It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project.
• Integration is not one “big bang” at the end; instead, elements are integrated progressively.
• Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
• Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
• Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning.
• When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
• Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
• The development process itself can be improved and refined along the way. The assessment at the end of iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration.