Skip to main content
2 of 2
replaced http://pm.stackexchange.com/ with https://pm.stackexchange.com/

According to Wikipedia, you should quantify the main characteristics of your software, try to measure them, and to score each characteristic. After this scoring you would be able to find out how about the quality of your software. I suggest you to look through this house of quality graph, I think it is very useful.

In my experience a software quality can be measured in two main categories: the small (low priority) bugs and the critical (high priority) bugs. You cannot solve only one category and say that you solved the half of the bugs. This only can describe your project's situation. (Let's say, you have 50 low priority bugs, such as wrong interface offsets, typos, and 35 high priority bugs, such as crashes and application freezing. If you solve all the 35 critical bugs, you cannot say that you almost done the half of the bugs, only that your application is critical bug-free).

Another personal experience about bugs: the number of total bugs is pondering with 65-70% low priority bugs and 30-35% of critical bugs. After solving all of them, other bugs are generated, in my experience this number is the 33% of the previously solved bugs' number.

To make your software as good quality it can be, I suggest you to broke it in smaller parts, if you have about 1 year, I suggest you to broke it in 4 or 5 smaller releases. Each part should contain a specification part (15%), a development part (30%), bug fixing (40%) and final review with code freeze (15%). In the final review don't forget to discuss with your team the weak and strong points of the project, and try to avoid/improve in the next level the weak ones. Don't forget about the hard deadlines of these smaller parts.

Although, I suggest you to let about 1 month at the final of this 1 year project for the final fixes, to discuss with the customer in each final review, to confirm the already done parts of the project.

I also suggest you this chapter to read, I think is very useful.

Edit: I think your question is highly connected with risk measurement, here you can find a pretty good approach of risk management.

MMMM
  • 639
  • 3
  • 10