Software Quality for a Moving Target

>>>Software Quality for a Moving Target

Developing a software system is a complex endeavor. In an ideal world, the customer knows exactly what they want the system’s functionalities to be and engineers understand exactly what is needed to deliver it. In reality though, things are quite different. The assigned software team is often presented with an idea or maybe a few broad requirements. When the system begins to take shape – the customer often realizes that they require changes and maybe a few extra features (‘the Moving Target’). What they don’t realize is that typically these changes come at a considerable cost and schedule adjustment. It is the responsibility of the software development team to communicate the impacts to them. Often, engineers are not great at providing estimates – underestimating the time required to make changes is usually one of the largest pitfalls for engineers. To effectively quantify the time required to deliver changes, the team needs to collect information to learn from past and present projects. This enables the team to have a rational discussion with the customer about the changes and their impact to the project based on experience.

Forrester defines software quality as: “Software that meets business requirements, provides a satisfying user experience, and has fewer defects”. Note that it does not say, “provides the perfect user experience or has zero defects”. However, both the ‘satisfactory user experience’ and the ‘fewer defects’ need to be quantified. The earlier these expectations are set, the easier it is for both the customer and the software delivery team. To keep expectations in check and provide the highest quality of service, I have listed 7 best practice tips that help with the moving target, from my experience, which will be provided over this 2-part series:

  1. Quantify expectations when defining the Service Level Agreement (SLA). This includes a timeline of deliverables and should include functional, internal testing, and bug fixes. The size and complexity of the functionality with respect to the number and capability of the resources should also be measured when providing this estimate. Since requirements can be subject to change, it is recommended that you incorporate a timeline to receive, understand, and effectively estimate change requests.
  2. Determine clear criteria for sign off dates. Once again, quantify the criteria and set these dates at optimum intervals.
  3. Plan for contingency when there is a risk of not meeting the SLA.  Use experience from past projects to analyze the complexity of functionality to avoid such risks. However, if a potential risk crops up, open communication lines and possible mitigation options as quickly as possible. The sooner the risk is communicated, the better it is received and understood. Keeping the client involved at a high level and discussing possible resolutions helps to build solid relations and increase confidence in the team. Software development is a team effort; cooperation and trust are the basic building blocks for the team’s success.

Take some time to think about these first three tips and then check back for the final four best practices that help with software quality for the moving target.

Roshni Datta is a Consultant II at SDLC Partners, a leading provider of business and technology solutions. Please feel free to contact Roshni at with any questions on this blog post or to further discuss software development.