software metrics

Feb 27 2009   9:54AM GMT

Software Quality vs Project Quality

Posted by: Jaideep
software quality, project quality, quality standards, quality measures, quality metrics, software metrics, Project Management, Software Project, customer requirements, software product, software design, business requirements, functional requirements, software delivery, Project Delivery, project execution, project initiation, Project Development, project implementation, software strategy, test strategy, test case, Test Plan, test scenarios, test results, fixing of bugs, project close-out, post implementation phase of project

The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.

In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.

In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.

The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.

Feb 25 2009   10:02AM GMT

Top 20 End Objectives of any Software Project

Posted by: Jaideep
Software Project, software business, software project management, project objectives, business survival, growth, revenues, profits, maturity, Project Lifecycle, standards and methodology, software metrics, stakeholders, transparency, project completion, project sign-off, customer satisfaction, customer delight, customer requirements, software requirements, Team building, team role, team responsibility, team accountability, software quality, project quality, first time right, project overrun, continuous learning, Increase in revenue, Avoid revenue loss, Reduce costs, Avoid cost increases, Improved service

Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):

1. Control on Project Lifecycle

2. Standards and Methodology

3. Metrics

4. Stakeholders rights

5. Transparency

6. Pro-active approach to avoid post-mortem

7. Universal approach for similar projects

8. Timely completion, sign-offs and payments

9. Customer satisfaction and delight

10. Customer requirements and both end clarity on objectives of the product

11. Team building

12. Roles, responsibilities and accountability

13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall

14. First time right approach

15. Quality right from start – ongoing – every step

16. Increase in revenue

17. Avoid revenue loss

18. Reduce costs

19. Avoid cost increases

20. Improved service

Feb 23 2009   10:43AM GMT

Top 15 Pain Areas in a Software Project Lifecycle

Posted by: Jaideep
Software Project Lifecycle, pain areas of a software project, Software Project, customer requirements, software project management, software metrics, Methodology and Standards, documentation, Customer requirements understanding, Measurement of Overrun, Project Status review, Role clarity, Risk analysis, Team building, Project Repository, Learning from Past, Post implementation support, Quality – man, methods, approach and deliverables, Version Control

Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.

In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)

1. Methodology and Standards
2. Documentation
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control