SDLC is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
Stages are:
- Planning (Concept development & Planning);
- Analysis (Requirements gathering & Analysis);
- Design (Architecture & Specifications);
- Development (Development; Test; Implementation);
There are three main groups of development approaches (No one model is necessarily better or worse than another):
- Unstructured or Ad-hoc – Big-bang, Code & Fix
- Heavyweight or Predictive – Waterfall, V-Model
- Lightweight, Adaptive or Agile – Spiral, XP, SCRUM
Big Bang is the simplest form of development model.
There is little in the way of formal process and the focus is on expending the organizations energy to develop the final software. Defined phases, gateway criteria, documentation, testing, etc. are all considered non essential and are likely not to exist.
Code & Fix A step forward from Big Bang would be to recognize that the product should be tested before release.
The test team find bugs, send the product back for fixing, developers do some coding to deliver fixes and send the product back for testing. The cycle repeats until some usually undefined point, perhaps where the number and/or severity of bugs being found is to an acceptable level or project time runs out. Code & Fix is often the default model within organizations that have not established a formal development approach. It’s important to realize that while Code & Fix is a model of itself it’s also a mode which organizations adopt at given phases of other models.
Waterfall model is a sequential SD process, in which progress is seen as flowing steadily downwards through the phases of Requirements Gathering, Analysis, Design, Coding, Testing, Implementation, and Maintenance.
Waterfall model is probably the most well known. Has been presented in 1970. The Waterfall provides organizations a way to clearly define each step of the development process and greatly simplify resourcing, scheduling and planning. They can also set Entry and Exit criteria between each phase.
Advantages
- Easy to explain to the user
- Structures approach.
- Stages and activities are well defined
- Helps to plan and schedule the project
- Verification at each stage ensures early detection of errors / misunderstanding
- Each phase has specific deliverable
Disadvantages
- Assumes that the requirements of a system can be frozen
- Very difficult to go back to any stage after it finished.
- Little flexibility and adjusting scope is difficult and expensive.
- Costly and required more time, in addition to detailed plan
The V-model is essentially a Waterfall that has the post coding activities shown in relation to the pre-coding activities.
Following the V-Model the test team are involved right at the start of the development life cycle and remain integrated and involved until the end.
As each key phase is entered parallel planning occurs for each of the related activities.
For example, when User Requirements are established the User Acceptance Tests can be written. When the Functional Specification is published the System Test Plan and Cases can be written.
Spiral
In the Spiral model there are a series of key phases similar to those within the Waterfall model. As with the Waterfall they are worked through in sequence and require similar inputs and outputs in order to allow progression to the next phase.
However, the major difference is that within the Spiral model the phases are performed in an iterative fashion, not a single run.
The Spiral model still requires that both code and artefacts such as specifications, test plans, etc. are produced. The key is that they’re not all done up-front as in the Waterfall.
As test consultants it’s important to understand the Spiral model as it can provide acceptable middle ground for a client, sitting between the predictive and adaptive models of Waterfall and Agile. The Spiral model can act as a stepping stone from a heavyweight approach to a more lightweight one.
Agile is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
Agile is not a single model, at best there are a number of them. It’s more correct to consider Agile to be a philosophy and approach towards software development.
The word ‘Agile’ was adopted in 2001 in preference to the word ‘lightweight’ which was felt to miss the central point of the thinking being done around how to approach software development in a less predictive or heavyweight manner.
XP is a customer / developer focused form of agile development centered on fundamental development practices. These are described in a set of five Values supported by more elaborate Principles and Practices.
The start point of XP development is the collation of requirements in the form of User Stories from which Acceptance Tests are derived, some of which may be automated. User Stories are different to Use Cases.
The Stories are two to three line high-level descriptions of the functionality a customer wants. Estimations of the time to implement each Story are fed into the Release Plan. With the Release Plan in place the Stories that will be coded for each iteration are then planned.
Before coding begins developers sit with on-site customers to understand the fine detail of these requirements and Unit Tests are written that cover all functionality described in the Stories. This ‘Test Driven Development’ is a key feature of XP.
Once the iteration is complete customers can run the Acceptance Tests and an incremental delivery of the software can be completed.
XP discourages the creation of formal documents such as the Requirements document and Design up front and relies on these being created iteratively as the project progresses. This approach is central to the idea of XP being ideal for projects where requirements are not stable or known.
Scrum model primarily focuses on the management of agile projects and not so much on how agile development will be done, unlike XP.
It uses a simple process ‘skeleton’ and requires a limited set of artifacts to be produced during the process.
At the start of the project a Product Owner compiles a Backlog of changes that will form the scope of the project. These are then prioritized and broken down into Sprint Backlogs that the team plans to deliver in the agreed time.
Each Sprint usually lasts between two to four weeks and includes both development and test activities. Each Sprint must deliver a working increment of agreed functionality. Other dissimilarities to XP are; requirements in a Sprint are expected to be frozen for the duration of the Sprint and refactoring is an exception not a rule.
The Scrum approach changes the need for certain roles within the project. Project Manager and Test Manager are two examples. These roles will most likely exist outside of the Scrum team as non-Scrum participants who are there to support the Scrum team.
To maintain communication there are daily Stand-up meetings where what was done the previous day, is planned for the coming day and issues encountered or expected are shared. The Scrum Master takes on the task of managing the issues the team has raised in a similar way to how the Project Manager or Test Manager might usually do.
Measurement of progress is displayed on Burndown Charts that show whether the Sprint Backlog will be completed on or before the target date. A Sprint Retrospective is held after each Sprint as a lessons learned and to improve the way of working for future sprints.
Kanban is another Agile-based methodology.
It is a flow-oriented methodology, but at the same time it is much less declarative than Scrum. Kanban has the following differences compared to the Scrum methodology:
- No iterations/Sprints. Kanban development is based on task flow which moves through the development team.
- Workflow visualization. Kanban uses a special board which shows the current state of the project with ‘Backlog, ‘In progress’ and ‘Done’ tasks. An example of the Kanban board can be found below.
- Work-in-progress (to-do tasks) is limited at each stage. This approach allows us to find bottlenecks and fix them as immediately.
- Time saving. Estimations are not created as they are unnecessary. Workflow does not stop at the end of the iteration which keeps team working full-time.
- No roles defined. The Project team and Client can specify any roles they need for the project.
- Ability to add any other rules and practices from Scrum, XP and other methods.