Quality is delighting customers
do yo wan the detailed emplanation?
There are various models like Water Flow model, Spiral Model,V-Model, Rad(Rapid Application development), Prototype model and Hybrid Model(Which can be combination of any two or more models).
Do you wanna a detailed explanation of all these?
Software Development Models
There are many models an organisation can use as the basis of their approach to developing software. There are three main groups of development approaches under which a number of development models can be placed:
The common expectation is that Agile is a model of itself in a similar way to the Waterfall or Spiral models. This is incorrect and thinking Agile is a model of itself leads to constant confusion for organisations trying to adopt it.
Clearly defining which of the development models are in use within an organisation is critical for overall project success. The Project Manager will plan and order tasks based on the model being used, development and test teams will do the same.
Expectations about what artefacts will be created and when, how project communication will be conducted, when teams will be engaged and so on is all dependent on the model used.
No one model is necessarily better or worse than another. As always the selection of a particular model is correct only in the context of the organisation or the product under development.
Correct selection is to a great degree dependant on having a clear understanding of the groups and types of development models. This is of further importance given that it’s highly unlikely that any organisation will follow a model strictly. Most organisations will opt to use a hybrid form that fits the capabilities of their staff and meets the needs of their business.
Unstructured or Ad-hoc
Development can be approached without any great attention to organising activities, resources or to the planning and analysis of what will actually be involved in delivering an item of development work.
An organisation can simply pour into a project the required elements of people, money and time then set off working in the hope that something useful will be produced. Alternatively they can enter a loop of finding and fixing issues until the product is deemed ‘good enough’.
This is the essence of unstructured and ad-hoc development approaches. Despite the apparently chaotic nature they can the best approach in certain circumstances.
The simplest form of development model is the Big Bang model. There is little in the way of formal process and the focus is on expending the organisations energy to develop the final software. Defined phases, gateway criteria, documentation, testing, etc. are all considered non essential and are likely not to exist.
This model does not allow for cyclic clarification of requirements, iteration of code, bug fixes or any other repeated activity we’ve come to accept as the norm today. Big Bang is a onetime only set of activities.
An organisation may say its development approach is Big Bang to describe the way development may send the test team a completed product for testing. Development are finished coding and ‘throw it over the fence’ to the test team who most likely have no previous knowledge of what’s been developed.
This is an erroneous use of the term Big Bang but as consultants we need to understand why an organisation may think in these terms. Testing to find bugs and deliver fixes won’t be done in a strictly Big Bang approach, because if it is then the organisation has moved into a Code & Fix model.
Code & Fix
A step forward from Big Bang would be to recognise that the product should be tested before release. This then sees the organisation delivering what they believe is completed code to the test team for testing.
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.
The Code & Fix model.
Code & Fix is often the default model within organisations that have not established a formal development approach. It’s important to realise that while Code & Fix is a model of itself it’s also a mode which organisations adopt at given phases of other models.
Whether an organisation is following Waterfall, Spiral or Agile they will all typically drop into Code & Fix at some point. It’s not uncommon to have three cycles of Code & Fix intentionally planned between builds, iterations or increments as a standard.
Despite this most organisations will still state they’re following their development model and not recognise the deviation. As mentioned before this may not be technically correct but it is contextually correct and we must remain flexible in our thinking in understanding this.
Heavyweight or Predictive
Given that software development is considered an engineering practice it was perhaps inevitable thinking from other forms of engineering would be applied to it.
What’s more as the organisation sought to make the whole process of software development more predictable it was also inevitable that project management thinking would be drawn on.
Combine the two and it’s easy to see that the approach will require greater process, planning, documentation and reporting quickly becoming a ‘heavyweight’ approach.
Of all development models the Waterfall model is probably the most well known. Having been presented in 1970 it’s been around forever in computing industry terms. The Waterfall describes a series of sequential stages that follow each other with no overlap.
The Waterfall Model.
The Waterfall provides organisations 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. There for from a business perspective the Waterfall is an attractive model that looks good on paper.
The main issues with the Waterfall model in practice are that to use it in such a prescriptive manner can be near impossible. Phases will over run, requirements and resources will change. In the classic implementation of the model it is an entirely linear, non-incremental flow. Any Entry and Exit criteria not met, such as documents not being ready, will halt the process.
Interestingly when Dr Royce presented the Waterfall model he had already thought about the problem a linear flow may cause and proposed the model should be used in an iterative fashion. Here’s an abstract from the paper he presented:
“Figure 3 portrays the iterative relationship between successive development phases for this scheme. The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence.
The virtue of all of this is that as the design proceeds the change process is scoped down to manageable limits. At any point in the design process after the requirements analysis is completed there exists a firm and close-up, moving baseline to which to return in the event of unforeseen design difficulties.”
The Waterfall was meant to be iterative and allow the return to a previous phase, while ensuring a clear deliverable was produced in each phase.
Next to the Waterfall the V-model is perhaps the most well known and referenced by testers. The V-model is essentially a Waterfall that has the post coding activities shown in relation to the pre-coding activities.
Showing the relationship of activities in this way is useful to remind the organisation that the development of software is more than just software development by the development team.
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.
These artefacts may be subject to change as the project progresses but getting them in place early has a number of benefits;
After coding is completed testing the activities on the right of the model will be performed. As the test team or more likely to be well prepared to test not only is testing more effective but the project is more likely to be kept on track.
Other teams such as Support can also be involved in a similar way to the test team. Taking on the planning and execution of Maintenance tasks for example.
Lightweight, Adaptive or Agile
It was mentioned at the beginning of this document that considering ‘Agile’ as a development model was incorrect and causes great confusion amongst developers, testers and their organisations.
Part of the reason for this confusion is that ‘Agile’ does not exist in the same way as the Waterfall or Spiral models do. 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 2001in 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.
It will be a rare occurrence for us to work with an organisation that can clearly state which recognised form of agile they are following. Most will adopt a hybrid form that takes elements from the various agile approaches and fits with the organisation’s culture and makes sense to the organisations team members.
As test consultants we need to be constantly mindful that:
In this section the Spiral model is included as it is mid-way between heavyweight and lightweight models and can be considered both predictive and adaptive.
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 first iteration of ‘Planning, Design, Test and Deploy‘ delivers a core product that is tested, essentially feature complete to the level understood at that point in the lifecycle and if necessary could be released by the organisation. Further iterations add more features that are designed, developed and tested there by constantly evolving the product.
With this evolutionary development model the increasing complexity and costs of development and testing can be managed more easily. Inevitable changes to requirements can be factored in as full specification, design, coding and testing of features isn’t done until they’re needed.
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.
Extreme Programming (XP)
XP is a customer / developer focused form of agile development centred 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.
As coding progresses Acceptance Tests can be run and Feedback gained from these and the customer which will direct the Coding and inform Refactoring of the code. 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 iterativly as the project progresses. This approach is central to the idea of XP being ideal for projects where requirements are not stable or known.
As test consultants our approach to performing test tasks in an XP environment needs to account for this lack of up front definition, the impact on tests of continual refactoring of code and that Unit and Acceptance tests will not provide full system coverage yet are typically expected to do so.
The 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 artefacts 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 prioritised 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.
Organisations using Scrum for development still require testing as before however the way in which that testing is delivered will vary. As test consultants it’s important to understand the scope of use of Scrum and model the test methodology to fit, while ensuring that testing practice is not compromised.
Models and Methodologies
When discussing software development models there are two additional points that should be kept in mind, one we’ve already mentioned:
As test consultants we need to be listening out for customers who, when asked to describe the methodology they apply, say they follow the V-Model, Spiral, etc.
We discussed that these models can be Predictive or Adaptive but another aspect is whether they are Prescriptive or Descriptive. The V-Model for example is more Prescriptive than Descriptive, in that it states the phases and implies the use of certain artefacts and techniques. Conversely XP is more Descriptive about the process flow, techniques and artefacts to be used.
Against the V-Model the organisation imposes additional rules such as the use of IEEE829 test documentation, it agrees when they should be produced and what needs to be in place to produce them, complete the activity and move on.
In doing so the organisation starts to build its own Software Development Methodology. This is the key;
In stating a choice of model for its software development methodology the organisation will predicate the use of certain practices. Our understanding of the various models and practices will be invaluable in ensuring the models and practices chosen are going to produce a congruent methodology.
To put the whole thing together as a diagram I propose it looks something like this:
It should be noted that the Approach chosen is usually done in combination with another based on the level ofimportance that's placed on Bug Finding or Confidence, as described below.
References and further reading:
Managing the Development of Large Software Systems. Dr. Winston W. Rovce, 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
A Spiral Model of Software Development and Enhancement , Barry Boehm, 1988.http://www.cs.usu.edu/~supratik/CS%205370/r5061.pdf
Agile Software Development, Martin Fowler, 2005, http://martinfowler.com/articles/newMethodology.html
Introduction to Extreme Programming , http://www.extremeprogramming.org
The Case Against XP, Matt Stephens, 2003 http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp
Nice explanation about all methodologies ,thank you providing this valuable information.
Very Good Info from Mark, thanks for sharing.