Sample Software Quality Issue

One of the major Software Quality issue that I experienced is with product xyz which my current employer deployed as the Version control and Change control system (SCCM). xyz is one of the major players (not the top performer) which offers composite package of Version control and Software Change Control management (SCCM). Our company was lured into its usage based on the current requirements to establish formal PM processes and integrated business process framework. Even though the deployment found to be exciting to me in the beginning, there are (yes these quality issues are still getting fixed) three major quality issues that affected the entire development team (including me) – Usability, Correctness and Availability.

Usability: The software is a full blown out version of an SCCM. Even though version control is also built in, it was totally different from the current CVS that we were using. Many features were new to the current team and was incompatible with the current working procedures. Balanced approach was taken to change the current procedures and to customize the software features. The customization work didn’t go well since many of the changes suggested were too difficult to be incorporated to improve usability, especially the version control aspect. So, the team was left with almost the original product with some minor modifications. The net effect of the quality issue was decrease in the level of productivity, when many of the features didn’t seem to fit well with the current work procedures and user reluctance to use the product.

Correctness: The hasty customization work lead to several defects related to display (incorrect grouping of requests in user in-box, incorrect pedigree display etc) and file deployment to the servers (file corruption, incorrect versions deployed). The cycle of change requests to fix the bugs was initiated and this incurred wastage of time and effort.

Availability: The product is Java based and requires client side installation which has huge memory requirements to start and run. Sometimes, toward the end of the day, the development PC had to be restarted for releasing the memory. The product had also issues with clearing out resource contention and deadlocks, which literally wanted the server to be rebooted every alternate days. The net effect was that the application was least available during critical times of work process and created much user resentment in using the system. Recently, the company fired the contract person (poor guy) who was managing the product deployment and maintenance, to account for the losses and poor performance.

What could have been done?
I guess, all of the above mentioned quality issues could have been effectively handled by just focusing on what the users actually wanted while customizing the product (user involvement) and ensuring that the users formally approved/signed off/tested for quality, the final customized software product. The quality issue could have been effectively handled if more time was allocated to initial customization and user training. In our case, it was just about a month, which I would say would be sufficient for only the analysis part.