Thanks … Brenda

However, once software is deployed, defect costs may explode due to cost of support, cost of upgrade cycle, reputation and opportunity cost if your software is truly buggy, etc. If your software is embedded in another product (e.g. a gas pump), then costs of remediation can skyrocket. And if your software is mission critical, then the defects can be astonishingly expensive (e.g. crashed and destroyed Mars lander)

During the dev cyle there is sometimes a geometric increase in cost due to building on software that has to later be rewritten. Depending on the nature of the defect, cost to fix can be trivial, massive, or anywhere in between.

To your recommendation, yes, test early and test often is the best way to minimize overall development and maintenance cost. This includes unit and regression testing, as well as ad-hoc and performance/stress testing.

The biggest quality- and cost-related mistakes we see dev teams make are:
- no or weak test plan or consideration of how to test during the design phase
- no or weak unit testing, leading to a house of cards when software is integrated
- no or weak or late in cycle regression testing, leading to regressions (defects where the software worked previously) that are not found immediately after builds, leading in turn to the issues in the original article above
- no or weak or late in cycle automation of regression testing, leading to slow and expensive regression testing
- stress testing and performance testing as an afterthought, if done at all, leading to last-minute and often substantial schedule delays (if done late) or field problems on deployment (if not done at all)
- inadequate or non-existent defect tracking, measurement, and communication tools and processes
- failure to set quality targets and metrics at the start of the project, leading to last-minute, often poor decisions under pressure to release without the quality metrics or targets to support the decisions

It gets down to thinking about and planning for quality from the start and all the way through, putting the right processes and tools in place to support quality engineering, and instilling the passion for quality in the entire project team.

Gordon

One of the strangest I’ve seen recently is the new “National Intrepid Center of Excellence” (http://www.fallenheroesfund.org/National-Intrepid-Center-of-Excellence.aspx). A wonderful concept, but an odd name since “intrepid” is an adjective. It’s just not clear what the center does. Wonder why they didn’t choose something like, “Polytrauma Center of Excellence?”

I agree that a lot of people are not very good at the above, but does that mean we have to eliminate this step altogether? It’s all about following a certain tested and proven document (for example, here’s one on the TRS in Web Projects).

I think the constant communication with the client is a good idea and will increase the chance for a project’s success, but starting with a solid requirements specifications is, IMO, always good, even if the requirements are changing over time.

Thank you for your consideration. http://www.workxpress.com

Jake

We would like to cross-post your article. As with other authors, we would publish your entire article on EndUserSharePoint.com giving you full attribution with links.

Please let me know if this is something you would be interested in.

Best Regards,
Natasha