Before jumping into calculating or estimating a Project Timeline, I will go through the steps of how a software should be executed, so that whatever is estimated, actually works out that way.
In the present day scenario where Time-to-Market issues achieve greater precedence over other issues, which we have learnt over the years, the developers’ productivity and quality of the software go out of the window. Has anyone thought why more and more open-source projects are gaining such popularity compared to their proprietary counterparts?
The simple reason is the desire to build robust and good quality software where revenue earned is not the major criteria. Open-source developers have a different mindset, they code without selfishness, however that’s a different story.
Coming back to the topic, the software life cycle consists of: -
1. Analysis
2. Design
3. Construction
4. Deployment
5. Maintenance
Each of the phases is tightly coupled with each other and a slippage in any of the phases will always carry down to the following phases. This brings us to the first phase, i.e. Analysis.
Phase 1 – Analysis
This is where the whole story begins. Analysis is the process of understanding the customer’s requirement and mapping it to the use cases. The most essential requirement of this phase is effective communication, however this fact is normally ignored. It must be understood that not all people are good at everything. Allocating the brightest brain in the organization for the Requirement Analysis may not be the best idea. By communicate effectively I mean a person who can give a patient listening rather than showing his oratory skills and of course one who is experienced in doing such kind of a job.
Phase 2 – Design
Once the foundation is laid with good use cases, it’s not that difficult a task to design the system. However one must keep in mind to use the best tools available for creating the software model. It is wise not to architect something new and venture into unseen territory to prove one’s designing skills, rather than use accepted models and architecture, which have matured over the years. Putting one’s designing prowess to test is best done with personal or open-source projects. Following the standards of designing will always result in a stable model.
Phase 3 – Construction
Again as the skills of developers vary, the only way we can get good consistent code is by following high class coding and documentation standards. A good practice is to have an independent Code Reviewer, who is well versed with the coding and documentation standards, and who will do the review as the programs are being written so that the developers will not run a mock with their code with the attitude that ‘It will be done later’. This actually never happens. Once a code is written it always stays that way. The other important implementation during this phase is Unit testing and System testing. It sounds synonymous but there is a difference between the two, Unit testing is testing the performance of the methods of a class whereas System testing is the performance of a class when accessed from another class. This is important at this stage, as a bug is less expensive when found at an early stage as compared to when found during Functional testing. By implementing these simple measures, the Quality of software will definitely be enhanced.
Phase 4 – Deployment
One of the most critical steps in the software lifecycle is the deployment process. This is often a customer’s first experience with a product and a bad experience can have lasting effects. Successful deployment depends on good System design and architecture of the project, which brings us back to the design phase. It is during the design phase itself deployment considerations should be kept in mind so that there are no hiccups during deployment.
Phase 5 – Maintenance
This phase will be a breeze if the Analysis, Design, Construction and Deployment have gone off smoothly. The reason is that the issues to deal with, during this phase, will be considerably reduced.
There are many software processes formulated over the years, which deal with building robust and stable software of which the Rational Unified Process (RUP) and the Agile Unified Process (AUP) are widely used. Extreme Programming is also gaining popularity these days. No matter which process is being used by the organization, it has to be followed sincerely without making any exceptions.
Calculating the Project Time
The reason why I had elaborated on the phases of the software development cycle was to stress upon the fact that whichever method you use for estimating the timeline for a project, the project will be on schedule if and only if the aforesaid are implemented with sincerity.
Making good time estimations requires a combination of qualities, which are experience, intuition and good technical skills.
The method I am illustrating is the one by Derek C Ashmore, from his book titled the “The J2EE Architect’s Handbook”, which states that the approximate time for a project can be calculated by:
a. The total number of screens multiplied by 2 man-weeks each
b. The total number of External application interfaces multiplied by 4 man-weeks each
c. The total number of Database tables multiplied by 2 man-weeks each
d. The total number of Tables or files updated multiplied by 2 man-weeks each
This will give the base estimate for a single developer. Multiply the base estimate by 2.5 to include analysis and testing activities for each usecase, lets call this figure as the total estimate for a single developer. Now for each developer added to the project multiply the total estimate with 1.20 (As each developer added increases Communication and Management time, which is also time consumed for the project).
At times when implementing the above strategy, some time estimations for certain modules of the project may seem a bit too inflated. In these circumstances adjust the assumptions made in a, b, c, d for those specific modules.
Hope these inputs will be helpful to those interested.
In the present day scenario where Time-to-Market issues achieve greater precedence over other issues, which we have learnt over the years, the developers’ productivity and quality of the software go out of the window. Has anyone thought why more and more open-source projects are gaining such popularity compared to their proprietary counterparts?
The simple reason is the desire to build robust and good quality software where revenue earned is not the major criteria. Open-source developers have a different mindset, they code without selfishness, however that’s a different story.
Coming back to the topic, the software life cycle consists of: -
1. Analysis
2. Design
3. Construction
4. Deployment
5. Maintenance
Each of the phases is tightly coupled with each other and a slippage in any of the phases will always carry down to the following phases. This brings us to the first phase, i.e. Analysis.
Phase 1 – Analysis
This is where the whole story begins. Analysis is the process of understanding the customer’s requirement and mapping it to the use cases. The most essential requirement of this phase is effective communication, however this fact is normally ignored. It must be understood that not all people are good at everything. Allocating the brightest brain in the organization for the Requirement Analysis may not be the best idea. By communicate effectively I mean a person who can give a patient listening rather than showing his oratory skills and of course one who is experienced in doing such kind of a job.
Phase 2 – Design
Once the foundation is laid with good use cases, it’s not that difficult a task to design the system. However one must keep in mind to use the best tools available for creating the software model. It is wise not to architect something new and venture into unseen territory to prove one’s designing skills, rather than use accepted models and architecture, which have matured over the years. Putting one’s designing prowess to test is best done with personal or open-source projects. Following the standards of designing will always result in a stable model.
Phase 3 – Construction
Again as the skills of developers vary, the only way we can get good consistent code is by following high class coding and documentation standards. A good practice is to have an independent Code Reviewer, who is well versed with the coding and documentation standards, and who will do the review as the programs are being written so that the developers will not run a mock with their code with the attitude that ‘It will be done later’. This actually never happens. Once a code is written it always stays that way. The other important implementation during this phase is Unit testing and System testing. It sounds synonymous but there is a difference between the two, Unit testing is testing the performance of the methods of a class whereas System testing is the performance of a class when accessed from another class. This is important at this stage, as a bug is less expensive when found at an early stage as compared to when found during Functional testing. By implementing these simple measures, the Quality of software will definitely be enhanced.
Phase 4 – Deployment
One of the most critical steps in the software lifecycle is the deployment process. This is often a customer’s first experience with a product and a bad experience can have lasting effects. Successful deployment depends on good System design and architecture of the project, which brings us back to the design phase. It is during the design phase itself deployment considerations should be kept in mind so that there are no hiccups during deployment.
Phase 5 – Maintenance
This phase will be a breeze if the Analysis, Design, Construction and Deployment have gone off smoothly. The reason is that the issues to deal with, during this phase, will be considerably reduced.
There are many software processes formulated over the years, which deal with building robust and stable software of which the Rational Unified Process (RUP) and the Agile Unified Process (AUP) are widely used. Extreme Programming is also gaining popularity these days. No matter which process is being used by the organization, it has to be followed sincerely without making any exceptions.
Calculating the Project Time
The reason why I had elaborated on the phases of the software development cycle was to stress upon the fact that whichever method you use for estimating the timeline for a project, the project will be on schedule if and only if the aforesaid are implemented with sincerity.
Making good time estimations requires a combination of qualities, which are experience, intuition and good technical skills.
The method I am illustrating is the one by Derek C Ashmore, from his book titled the “The J2EE Architect’s Handbook”, which states that the approximate time for a project can be calculated by:
a. The total number of screens multiplied by 2 man-weeks each
b. The total number of External application interfaces multiplied by 4 man-weeks each
c. The total number of Database tables multiplied by 2 man-weeks each
d. The total number of Tables or files updated multiplied by 2 man-weeks each
This will give the base estimate for a single developer. Multiply the base estimate by 2.5 to include analysis and testing activities for each usecase, lets call this figure as the total estimate for a single developer. Now for each developer added to the project multiply the total estimate with 1.20 (As each developer added increases Communication and Management time, which is also time consumed for the project).
At times when implementing the above strategy, some time estimations for certain modules of the project may seem a bit too inflated. In these circumstances adjust the assumptions made in a, b, c, d for those specific modules.
Hope these inputs will be helpful to those interested.
No comments:
Post a Comment