Learn Software Development » Development

Explain the waterfall model of software testing. What are its advantages and disadvantages?

ashish — Sun, 20 May 2012 19:17:40 +0000

There are a number of models that have been developed for the software testing like the waterfall model, spiral model, agile model and so on. The discussion in this article is limited to the waterfall model of software testing along with its advantages and disadvantages. You must have seen a waterfall and how the water flows in it ! In a similar way to the water fall, this software development model progresses and so has been named as the water fall model of software development. Like a waterfall, it follows some sequence of flow and therefore is considered to be a sequential design process which is generally used in the software development life cycle or the SDLC which require the flow of the development to be downwards like in a water fall – progressive and steady through different phases like those mentioned below:
1. Conception
2. Initiation
3. Analysis
4. Design
5. Construction
6. Testing
7. Production
8. Implementation
9. Maintenance etc.
This model has a flow similar to that of a real water fall. Now below we list out all the phases of the software development process that implements a water fall model:
1. Requirements
2. Specifications
3. Architecture
4. Design
5. Implementation
6. Testing
7. Deployment, and lastly
8. Maintenance
Now below we are mentioning some of the common methodologies apart from the water fall model of software development that too are used in the software development process:
1. Agile
2. Clean room
3. Iterative
4. RAD or rapid application development
5. RUP or rational unified process
6. Spiral
7. XP
8. Lean
9. Scrum
10. V model
11. TDD or test driven development
The below mentioned tools are used for the implementation of the water fall model of software development:
1. Compiler
2. Debugger
3. Profiler
4. IDE or integrated development environment
5. GUI or graphical user interface designer.

When a water fall model of software development has been implemented, the software system or application under development can move to the higher stages only if the preceding one has been successfully completed and all the issues discovered in the preceding stage have been identified and fixed. So many types of water fall models have been developed with different ways and order of implementation of the common steps. The most popular waterfall model of software development is that of the “Royce’s final model”. Other types of the waterfall model have been derived from this model only. Now we list some advantages and disadvantages of the waterfall model of software development:

Advantages:
1. Waterfall model insists on spending time on the early stages of development since it open ups the option of greater economy at the succeeding stages regarding the money, efforts and time.
2. It employs the idea of fixing the bug earlier with spending less efforts and money rather than spending huge amounts of time and efforts later.
3. It employs the idea of the big design upfront model.
4. It makes sure that the preceding stages have been perfectly completed before the development moves on to the next stage.
5. It involves the identification of all the requirements and resources before the beginning of the development process so the development in progress won’t fall short of resources and thus saves the potential wastage of the efforts.

Disadvantages:
1. Most of the times it has been considered as a bad idea to be followed in the practical implementation since it is not possible for any project to complete the preceding level 100 percent before moving on to the next one.
2. The designers stay unaware of the future implementation difficulties while designing a software product that has not been implemented.

Rapid Development: Taming Wild Software Schedules	The Mythical Man-Month	The Waterfall Method (Kindle)

Providing enough time and infrastructure for people to discuss and resolve items ..

ashish — Fri, 18 May 2012 20:08:57 +0000

This seems like a very odd item to write a software post about. However, this is based on a lot of experience that I have seen over the years, and also discussed with many other people (those that have seen problems where there was not enough infrastructure, and other cases where there was enough of this infrastructure). Consider a case where a company is running a traditional software development unit, where the development team runs into challenges often enough and needs to do a fair amount of thinking to resolve issues and work through complicated design and architectural solutions.
However, it is not as easy as it sounds. This is not routine work of software maintenance; in a lot of cases nowadays where people work on complicated stuff and try to be as innovative as possible, there is the need to do a lot of new stuff. New stuff means that you need some real good developers, those who can think of new solutions, who can work the things out. However, for this kind of work, you need people who do a lot of discussion with each other, trying out new stuff, working through architectural problems and looking at alternate solutions.
Now, what does this need ? I already mentioned the need for some people for the development team, but there are other infrastructural stuff that is needed to ensure that the developers have the right environment. A big deal for this is the need for place to discuss things, some good recreation stuff (such as games and the like), and so on. In this post, the focus is on the discussion. One empirical fact was that if you go to most places where developers are present and there are tough solutions, you will find a lot of the boards having discussions and architectural alternatives being discussed. Having enough whiteboards near the developer community enables these discussions to happen, also resulting in solutions and decisions.
Not having this sort of infrastructure in place inhibits the development team from these sort of discussions among the team, and does play a role in a resulting slowdown of the pace of solutions of issues. I have seen organizations where both of these situations were present, and there is an effect of having these infrastructure in place. I would recommend that organizations that have a lot of development work have enough infrastructure in place to support the development team.

What happens when your product is not stable close to release date ? – Part 4

ashish — Thu, 10 May 2012 15:24:28 +0000

In this series, I have been writing about the problems that arise when a product (deemed very significant for the organization) are near release. In the last post (deferral of bugs near the release date), I talked about the rate of deferral of bugs in the end game, and how this time of the schedule means that bugs are evaluated much more carefully to review whether these need to be fixed or can be deferred (and there is a lot of review to ensure that bugs are not let through which could cause a risk to the release).
In this post, I will talk more about some of the measures that management should be having in the organization in order to ensure that there are no sudden surprises and information moves up the organization structure to the management chain about the current status over the period of time. If such a process is not in place, then the organization will keep on running into cases where they don’t know about problems that may be causing a risk to the release schedule of the application, and will be hit with those problems when they least expect it. And you certainly don’t want to be in such a position where the senior managers don’t know about potential problems and suddenly come to know about it. In such cases, the responses that you get from the management chain may be of managers trying to get a quick handle on the situation and how to address these problems, which is not at all a nice position for the team to be in.
So how do you prevent the problems that has been outlined in the previous post ? Well, the first and most important way is to ensure that there is a process for status discussions up and down the management chain to the level of the team involved in the actual execution of the application development. In addition, there should be a clear way for the managers involved in the chain of command to be able to highlight risk points and do this in such a way that more serious issues get moved up quickly up to the level of senior management. This starts right at the team level. The team should be having a regular status discussion where the current status of the application development (including the dependencies) is discussed within the management structure of the team and if there are issues that are deemed significant and could imperil the release schedule of the team, those should be raised up the team manager upto the next level of the structure, along with a background on the issue and potential mitigation steps. If there are no mitigation steps or is out of the control of the team (with external dependencies, or other issues such as resources), these also need to be emphasized along with suggested steps about what is needed to be done.
In addition to this, the team should be sending out a regular status report that is highlighted to senior management with a summary of the top issues and whether the team feels that there are issues that could cause problems. A combination of these steps at the various parts of the application could ensure that senior management knows about the issues and is not surprised when these pop up.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

What happens when your product is not stable close to release date ? – Part 3

ashish — Wed, 09 May 2012 20:16:20 +0000

In the previous post in this series (Getting advice from the team about status), I talked about the importance of making sure that feedback from the team is not crushed, and that people are not put in a position where they feel that they are doing something against the organization when they report status that is not comfortable, or where they say that according to them, the product is not in a good position.
Now, for a large product, there will be several layers of organization that will be working on the product, and it is good to remember that all of them have some fact and some information that may be relevant or may not be. In fact, in today’s world where user forums are a quick way for a problem to be reported and then more me-too’s to quickly join in through social networking, it is very hard to determine which issue is a huge problem and which is the one that can be safely ignored. It may seem strange to those outside the industry, but it is very much possible that a defect in the program that may be irritating to that specific user or cause some problems may not be something that the team considered worthy of fixing.
The next few lines will not be about the decision making, just more about what goes on as the team nears the release date. As the product gets closer to release, and the situation is not such that there is absolutely no chance of release (if the team is indeed in such a bad situation, it will be visible to everybody and decision making will be much easier), the status with regard to defects in the application will become much more complicated. It is a known part of the software development process that when the team gets near the release date, selecting which bugs will get fixed and which ones will not be fixed (or will be deferred from the current release) gets tricky. Closer to the release date, the problems associated with enhanced risk for every defect that is fixed become critical. What this means is that unless the defect is evaluated to be sure that this is needed to be fixed, and that the actual fix will not end up destabilizing something else, the team may well decide that the problems sought to be taken away by fixing the bug are not worth the risk, and a larger proportion of bugs will be deferred (and not fixed).
Deciding which of these bugs need to be fixed and which one needs to be deferred is critical. However, this should be an independent decision by the Bug review committee having the Product Management representative, and (to emphasize), it should not be under enormous pressure to defer bugs in order to meet the schedule. What this means is that it can happen easily enough that the management team relays the pressure down to the team that it needs to increase the rate at which bugs are being deferred in order to meet the schedule. This tactic runs the risk of letting through such bugs that can be bad for specific sets of users and bring about a lot of condemnation on user forums and among user groups.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

More about this in the next post (link) ..

What happens when your product is not stable close to release date ? – Part 2

ashish — Tue, 08 May 2012 19:57:02 +0000

In the previous post in this series (Making the right decisions), I talked about some of the decisions that the senior management team has to make when they are near the release of a major product, and the balancing act that they need to make while making the right decision (in a situation where the wrong decision can break their career and cause huge damage to their companies). With such risks, it is a wonder that these managers are able to make a decision at all, and yet you see people making such decisions under these high pressure situations all the time.
So in this post let us talk about what should not happen. Given the tremendous pressure that exists to ensure that the schedule is met, there is a basic mental tendency to be optimistic and hope for the best, and this can get projected in a way that there is reluctance to hear bad news. You know the type – the QE team or other executing team members are told that they are free to report the exact situation that exists and there should be no hesitation in providing the correct situation rather than hiding stuff that they feel that senior managers would not like.
This is one of the biggest challenges that an organization can face. With large releases, there is a lot of emphasis on the importance of this release, on how the future of the company depends on this release and so on, and implicit is the suggestion that everybody should contribute to ensuring that the date is met, and not be the roadblock in meeting the schedule. This puts a huge pressure on teams which are by nature seen as reporting bad news (which is actually a bad representation of what the QE team does, but we need to be realistic on how many people see this all important function), enough that QE team members would be hesitant in being the bearer of bad news. As a result, there needs to be a lot of positive affirmation by the senior managers that it is critical for the exact status to be projected by the team members, that if there are apprehensions and worries from the team members, it needs to be known to the senior managers along with the reasons for the same.
What happens is that if the QE team members report some problems, or near the end, start making some suggestions that the product is not of good quality, there should be an environment already existing where such worries are evaluated by a core committee, where QE team members are invited to present their viewpoints and then the decision is made about these worries in a way that people are convinced.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –