Work Product Audits in the Software Industry

[venkatn]

Hi all,

Can some one help me with when we will do a work product Audit in software industry ? Should we perform work product audit after the work product has been reviewed and approved or before it is send for approval ?

I understand that a work product can be done on customer deliverables as well as non deliverables to the customer. If it's deliverable then work product audit will be performed before the delivery and if not a deliverable should be performed before we send the same for approval.

Please correct me if my understanding is wrong.

Thanks in advance
-Venkat

[Stijloor]

In Reply to Parent Post by venkatn

Hi all,

Can some one help me with when we will do a work product Audit in software industry ? Should we perform work product audit after the work product has been reviewed and approved or before it is send for approval ?

I understand that a work product can be done on customer deliverables as well as non deliverables to the customer. If it's deliverable then work product audit will be performed before the delivery and if not a deliverable should be performed before we send the same for approval.

Please correct me if my understanding is wrong.

Thanks in advance
-Venkat

Can someone help?

Thank you!!

Stijloor.

[yodon]

Well, I'll give it a shot. I'll admit though, I'm not sure what you're asking (maybe others feel that way and hence the lack of replies?). So I'll set the stage a bit.

Work products from software include such items as software requirements, software design documents, software architecture documents, code, unit and integration tests, formal tests, installation instructions, installation media, etc.

Normally, when I think of 'audit' I think of assessment of compliance to a process. Certainly your process can call out any or all of the above work products. The process could also describe how those work products move through the system for approval and release.

So from a process compliance perspective, you can audit at any point in the process to determine if you are complying. Something may be in the approval process and that would be fine as long as it's progressing through the flow as expected.

You would not be able to fully assess compliance, though, unless everything has been through the full workflow. So from that perspective, your audit may not be complete if you do an in-process audit. However, it would certainly be better to audit to find any non-compliances during the process rather than after the process concludes.

Now if you're talking about auditing a work product to assess if it meets some internal criteria; e.g., code meets coding standards, again, you can do in-process checks or post release checks. As with the above, it will be less costly to find any non-compliances during the process rather than after.

So it really depends on your process. You can release products to customers and risk finding a NC after you release (or have the customer find the NC). Same goes for internal work products but any NCs there may manifest themselves in other work products released to customers.

Does that help? If I'm off track, please reply with clarifications and I'll try again.

[venkatn]

Hi yodon,

Thanks a lot for your reply, you have actually cleared most of my doubts with respect to the question i posted. Your response has been very detailed and useful.

One more question that I have is , When we perform work product Audit, should we only look at the process that is being followed in generating the work product or I can look into the process being followed and also the work product generated?

I believe we can look into both. Please correct me.

[yodon]

It may be getting down now to terminology and common language.

The work products produced during software development fall under the "design" category and, as such, would normally be reviewed for technical content.

Auditors would likely not have the experience of background to do a technical review of a design artifact. However, auditors will examine the artifacts to assess compliance to the defined process. Focus areas for an audit with respect to the work product would be things like was the work product reviewed / is there evidence of the review, was the work product approved at the appropriate time (e.g., requirements approved before tests), etc. So in that respect, yes, an auditor would review the work product; just not for technical content, necessarily.

[20110611a]

The concept of work product audit has emerged from the level 2 process area PPQA (Process and Product Quality Assurance) of the CMMI model.

Process Quality Assurance is, I believe, well understood. Process audits, process compliance checks, assessments, etc. belong to this category.

Product Quality Assurance is a concept where confusions arise. And as explained in an earlier reply the process auditors may not have the competency and charter to determine product issues as they go about performing a process audit. Work Product Audit (WPA) addresses this need.

WPA is a hybrid audit where the focus is not only on basic compliance to defined process but also to the completeness and high-level correctness of the work-products created. WPA can be logically seen as the check performed before exiting a phase/major activity to enter the next phase/major activity. Checks on randomly sampled work-products is a good example of WPA. Some other examples include - final inspection, delivery audit, test witnessing, product demo, etc.