If you want to buy the project management book mail
[email protected] for
more details or call any of our book shops MUMBAI-22078296/97/022-22070989,
KOLKATA-22826518/19 HYDERABAD-24756967,24756400,BANGALORE-25587923,
25584641,AHMEDABAD-26421611,BHATINA(PUNJAB)-2237387,CHENNAI-28410796,28550491,DELHI/NEWDELHI-23254990/91,23325760,26415092,24691288.If
you want to write to the author directly email at
[email protected]
Note :- Never say that risk is high through out the project.
Risk is high at the start of projects, but by proper POC (Proof of concept), risk is brought in control. Good project managers always have proper risk mitigation plan at the start of project. As the project continues one by one, risks gets eliminated thus bringing down the risk.
Figure:- Risk % according to project phases
Every activity has a life cycle and software development process is not an exception for the same. Even if you are not aware of SDLC you still must be following it unknowingly. But if a software professional is aware about SDLC he can execute the project in a much controlled fashion. One of the big benefits of this awareness is that hot blooded developers will not start directly execution (coding) which can really lead to project running in an uncontrolled fashion. Second it helps customer and software professional to avoid confusion by anticipating the problems and issues before hand. In short SDLC defines the various stages in a software life cycle.
But before we try to understand what SDLC is all about. We need to get a broader view of the start and end of SDLC. Any project started if it does not have a start and end then its already in trouble. It’s like if you go out for a drive you should know where to start and where to end or else you are moving around endlessly.
Figure: - Entry, SDLC and Exit in action
Above is a more global view of the how the start and end of SDLC. Any project should have entry criteria and exit criteria. For instance a proper estimation document can be an entry criteria condition. That means if you do not have a proper estimation document in place the project will not start. It can be more practical, if half payment is not received the project will not start. So there can be list of points which needs to be completed before a project starts. Finally there should be end of the project also which defines saying that this is when the project will end. For instance if all the test scenarios given by the end customer is completed that means the project is finished. In the above figure we have the entry criteria as an estimation document and exit criteria as a signed document by the end client saying the software is delivered.
Below is the figure that shows typical flow in SDLC which has five main models .As per use project managers can select model for their project.
Let’s have a look on Waterfall model which is basically divided into two subtypes:-
As the name suggests Waterfall means flow of water always goes in one direction so when we say waterfall model we expect every phase/stage is freezed.
Big Bang waterfall model
The figure shows waterfall Big Bang model which has several stages and are described as below:-
Figure: - SDLC in action (Waterfall big bang model)
In water fall big bang model, it is assumed that all stages are freezed that means it’s a perfect world. But in actual projects such processes are impractical.
Phased Waterfall model
In this model the project is divided into small chunks and delivered at intervals by different teams. In short, chunks are developed in parallel by different teams and get integrated in the final project. But the disadvantage of this model if there is improper planning may lead to fall of the project during integration or any mismatch of co-ordination between the team may cause huge failure.
Iterative model was introduced because of problems faced in Waterfall model.
Now let’s try to have a look on Iterative model which also has a two subtype as follows:-
Incremental model
In this model work is divided into chunks like phase waterfall model but the difference is that in Incremental model one team can work on one or many chunks which was unlike in phase waterfall model.
Spiral model
This model uses series of prototype which refine on understanding of what we are actually going to deliver. Plans are changed if required as per refining of the prototype. So every time in this model refining of prototype is done and again the whole process cycle is repeated.
In Incremental and Spiral model the main problem is for any changes in between SDLC cycle we need to iterate the whole new cycle. For instance, During the final(Deliver)stage customer demands for change we iterate the whole cycle again that means we need to update all the previous (Requirement, Technical documents, Source code & Test plan) stages.
In Evolutionary model, we divide software into small units which can be earlier delivered to the customer’s end which means we try to fulfill the customer’s needs. In the later stages we evolve the software with new customers needs.
This type of model was developed by testers to emphasis the importance of early testing. In this model testers are involved from requirement stage itself. So below is the diagram (V model cycle diagram) which shows how for every stage some testing activity is done to ensure that the project is moving as planned.
For instance,
Lets try to understand every of this testing phase in more detail.
Unit Testing
Starting from the bottom the first test level is "Unit Testing". It involves checking that each feature specified in the "Component Design" has been implemented in the component.
In theory an independent tester should do this, but in practice the developer usually does it, as they are the only people who understand how a component works. The problem with a component is that it performs only a small part of the functionality of a system, and it relies on co-operating with other parts of the system, which may not have been built yet. To overcome this, the developer either builds, or uses special software to trick the component into believe it is working in a fully functional system.
Integration Testing
As the components are constructed and tested they are then linked together to check if they work with each other. It is a fact that two components that have passed all their tests, when connected to each other produce one new component full of faults. These tests can be done by specialists, or by the developers.
Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in the "System Design". The "System Design" defines relationships between components.
The tests are organized to check all the interfaces, until all the components have been built and interfaced to each other producing the whole system.
System Testing
Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it.
In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact it is one giant component.
System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non-functional requirements:
If you want to buy the project management book mail
[email protected] for
more details or call any of our book shops MUMBAI-22078296/97/022-22070989,
KOLKATA-22826518/19 HYDERABAD-24756967,24756400,BANGALORE-25587923,
25584641,AHMEDABAD-26421611,BHATINA(PUNJAB)-2237387,CHENNAI-28410796,28550491,DELHI/NEWDELHI-23254990/91,23325760,26415092,24691288.If
you want to write to the author directly email at
[email protected]