There is a diverse set of models and methodologies for different types of software development and choosing the right one for a particular work is an important task.
A system development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses thus one system development methodology is not necessarily suitable for use by all projects.
Each of the available models and methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations and that’s why methodology may well be the most vital factor in determining the probability of success in the project overall.
We, at ProfIT Labs Ltd., consider each of the major models (i.e. Waterfall, Spiral, Iterative) and methodologies (RUP, MSF, SCRUM, CMMI) in context with our client’s business and in conjunction with a system to be developed.
The following three figures represent the Waterfall, Spiral and Iterative models:
The Waterfall Model
The Spiral Model *
* B.W. Boehm, “A Spiral Model of Software Development and Enhancement”.
The Iterative RAD Model
Having provided software development services using all major traditional methodologies (RUP, MSF, SCRUM, CMMI) we have gained solid experience utilizing these methods in our software development practices.
The efficiency and scalability of the SCRUM methodology had shown to be the most suitable for the majority of the projects we are performing.
The SCRUM significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.
The SCRUM methodology assumes that the analysis, design, and development processes in the Sprint phase are unpredictable. Thus, a control mechanism is used to manage the unpredictability and control the risk.
Flexibility, responsiveness, and reliability are the results.
The SCRUM Methodology
The SCRUM is an agile, lightweight process that we use at ProfIT Labs Ltd. in majority of our projects to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, the SCRUM generates the benefits of agile development with the advantages of a simple implementation.
The SCRUM consists of the following 3 group of phases (see Figure 4. below):
- Planning — definition of a new release based on currently known backlog, along with an estimate of its schedule and cost. If a new system is being developed, this phase consists of both conceptualization and analysis. If an existing system is being enhanced, this phase consists of limited analysis.
- Architecture — design how the backlog items will be implemented. This phase includes system architecture modification and high level design.
II. Game (Development)
- Development Sprints (see Figure 5. below) — development of new release functionality, with constant respect to the variables of time, requirements, quality, cost, and competition. Interaction with these variables defines the end of this phase. There are multiple, iterative development sprints, or cycles, that are used to evolve the system.
- Closure — preparation for release, including final documentation, pre-release staged testing, and release.
The SCRUM Phases
Characteristics of the SCRUM Methodology
- The first and last phases (Planning and Closure) consist of defined processes, where all processes, inputs and outputs are well defined. The knowledge of how to do these processes is explicit. The flow is linear, with some iterations in the planning phase.
- The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or uncontrolled. It is treated as a black box that requires external controls. Accordingly, controls, including risk management, are put on each iteration of the Sprint phase to avoid chaos while maximizing flexibility.
- Sprints are nonlinear and flexible. Where available, explicit process knowledge is used; otherwise tacit knowledge and trial and error is used to build process knowledge. Sprints are used to evolve the final product.
- The project is open to the environment until the Closure phase. The deliverable can be changed at any time during the Planning and Sprint phases of the project. The project remains open to environmental complexity, including competitive, time, quality, and financial pressures, throughout these phases.
- The deliverable is determined during the project based on the environment.
Sprints Development Schema
The SCRUM Roles
There are three roles used in the SCRUM:
- Product Owner
- (Project) Team
The Product Owner:
- Defines the features of the product
- Decides on release date and content
- Responsible for the profitability of the product (ROI)
- Prioritizes features according to market value
- Adjusts features and priority as needed
- Accepts or rejects work results.
The ScrumMaster has three primary responsibilities in addition to leading the Daily Scrum meetings:
- The ScrumMaster follows tasks that have been completed, tasks that have started, any new tasks that have been discovered, as well as any estimates that may have changed. This makes it possible to update the Burndown Chart which shows the cumulative work remaining day by day. The ScrumMaster also observes the number of open tasks in progress and takes actions accordingly to achieve lean productivity gains.
- Surfaces dependencies and blocks which are impediments to the SCRUM and implements a remediation plan.
- Responsible to solve any problems within the SCRUM team to ensure team’s full functionality and productivity.
The (Project) Team:
- Develops the functionality
- Cross-functional, with seven (plus/minus two) members;
- Selects the Sprint goal and specifies work results;
- Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal;
- Organizes itself and its work; and
- Demos work results to the Product Owner.
The SCRUM Artifacts
The Product Backlog (or "Backlog") is the requirements for a system, expressed as a prioritized list of Product Backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the Product Backlog, it is the sole responsibility of the Product Owner to prioritize the Product Backlog.
During a Sprint planning meeting, backlog items are moved from the Product Backlog into a Sprint, based on the Product Owner's priorities.
The Sprint Backlog is an artifact of the Sprint Planning Meeting. When the Scrum Team has selected and committed to deliver a set of top priority features from the Product Backlog, the Product Backlog's features are broken down into a Sprint Backlog: a list of the specific development tasks required to implement a feature.
These tasks are broken down into pieces that will require less than two days (or sixteen developer-hours) of work. When the Sprint Backlog is complete, the total work estimated is compared with original estimates from the Product Backlog. If there is a significant difference, the team negotiates with the Product Owner to get the right amount of work to take into the Sprint with a high probability of success.
The Burndown Chart shows the cumulative work remaining in a Sprint, day-by-day. At the Sprint Planning Meeting the Scrum Team identifies and estimates specific tasks that must be completed for the Sprint to be successful. The total of all Sprint Backlog estimates of work remaining to be completed is the cumulative backlog.
When tasks are completed as the Sprint proceeds, the ScrumMaster recalculates the remaining work to be done and the Sprint Backlog decreases, or burns down over time. If the cumulative Sprint Backlog is zero at the end of the Sprint, the Sprint is successful.
The Burndown Chart is used as a tool to guide the development team to successful completion of a Sprint on time with working code that is potentially shippable as a product.
Advantages of the SCRUM Methodolog
Traditional development methodologies are designed only to respond to the unpredictability of the external and development environments at the start of an enhancement cycle. Such newer approaches as the Boehm spiral methodology and its variants are still limited in their ability to respond to changing requirements once the project has started.
The SCRUM methodology, on the other hand, is designed to be quite flexible throughout. It provides control mechanisms for planning a product release and then managing variables as the project progresses. This enables organizations to change the project and deliverables at any point in time, delivering the most appropriate release.
The SCRUM methodology frees developers to devise the most ingenious solutions throughout the project, as learning occurs and the environment changes. Small, collaborative teams of developers are able to share tacit knowledge about development processes.