Improving Software Quality in 1, 2, 3 & 4!

Quality can’t be simply defined objectively or subjectively. It is not enough to say that a product is of a high quality just because it had met the standards given.  Even though a product produced was made by meeting the standards, it’s possible that the customers’ tastes/standards were not considered thus failing to fulfill customer satisfaction which is in fact the purpose of the product – to satisfy the customers’ needs or wants. However, it is also not enough to define quality subjectively because only fulfilling customer satisfaction will also mean that the quality of your product is contingent on customers’ tastes or levels of satisfaction or standards. Pure contingency is chaotic because you don’t have a solid ground to defend the quality of your product, you don’t have a measurable basis for it. Moreover, as many people said “You cannot improve what you cannot measure”. Thus, to have a high quality product or deliverable, you must able to meet the standards given and fulfill customer satisfaction, and if it’s not possible, then do necessary trade-offs between the two depending on your priority. And to assure the quality of your product, instead of focusing only the product itself, it’s best to focus on the process or the activities within your process. The following are the activities that may help you produce a high quality product/deliverable:

1. Describe your goals explicitly

• By describing your goals explicitly, the programmers/developers will have a clear understanding of what the client/stakeholders expect from them.  Moreover, this is also helpful to the client/stakeholder for they’ll also know what to expect from the programmers/developers. This also helps the programmers/developers in setting priorities, like what software quality characteristic they should improve or maximize. With this, errors brought by ambiguous/unclear objectives/requirements are avoided or at least minimized, thus producing a product/deliverable which has a quality that is consistent to what is required/specified.

2. Test, test, test!

• Testing is essential in producing a high quality product/deliverable for it will help minimize bugs. Even as early as during the conceptualization of product, it is better to test if the functions or the design that will be used is correct. Moreover, it also better to test first every little part of a module before integrating them all so that it will be easier and quicker to track and fix bugs.  Moreover, the sooner a bug is found and fixed, the lesser the cost and effort will be.  Thus, in finding a bug in your program, the sooner the better.

  3. Conduct Technical Reviews

• Although technical reviews take time and energy, it is worth it. With technical reviews, you can gauge the quality of your product at the current stage and determine if it’s good enough to continue to the next stage.  If it’s not yet good enough, then you should improve it until it’s good enough to proceed to the next stage. However, the development process must not be completely frozen because of the reviews. “Good enough” doesn’t necessarily mean that you’re 100% good enough to proceed, it might mean 20% of critical project requirements are met and it depends on the nature of your project if that’s enough for you to proceed to the next stage.

  4. Manage change

• One of the scariest things in the world is change and it’s inevitable.  Same can be said for the [software] development process, at a certain point of time, there can be changes on the scope of the project or of the architecture/design of the product.  And change always comes with risks. In [software] development process, uncontrolled changes in requirements can result in disruption to design and coding which in turn causes the inconsistencies in the code/design that makes the product/deliverable defective. To avoid this, one must be able to handle change effectively so that there will be no disruption to the development process and thus producing a high quality product.

Source:

McConnell, Steven C. Code Complete, 2nd Edition, Microsoft Press, 2004.