Review and Verification for Maintaining Software

[arin_2323]

Hi Friends and colleagues!!!!

My organization is an E commerce service provider in B2B and B2C scenarios. We have a software design and development team which caters to the software development as well as maintenance.

My question is regarding the Review and verification of the software patches incorporated based on the internal requirements. How can I differentiate between the review and verification stages of maintenance related development works?

In the present scenario the individual developers carry out the testing.Records are ofcourse not documented, but it is made sure that the application is generating the required output, after this step the package is haded over to the internal customer ..and upon successful testing the customer hands over a "successful incorporation clearence" back to the technology team and the applications are uploaded to the live server.

The tech team head suggests it is not possible for him to document each and every review process as the quantum of job work is huge..and review and verification are one and only the same.

I understand these two things are different, but could not establish some solid analogy.

How to differentiate between the review and verification in this kind of scenario??? And can anybody suggest me some simple formats for both???

Cheers

Arindam

[BradM]

Can anyone provide assistance for Arindam?

[arin_2323]

Come on covites........this is the first time a thread is unattended for so long. Please help me out in solving this riddle as the external asessment is approaching fast..in the 2nd week of August.

Cheers

Arindam

[Coury Ferguson]

I have moved this post to this forum because it is asking questions regarding software. You may get better responses.

[BradM]

Arindam, why do you have to differentiate? Are these two distinct steps in your QMS system?

Why don't the developers document their work? NOTE: I am not currently in software. However, in my system integration days, I was around enough programmers to know they don't get along with documentation. However, when you have a QMS, their supervisor will have to initiate some level of documentation for them.

When the application generates the desired output, could someone not check a box to say that a review has been made?

Could you accept the customer's clearance as a verification?

I know these are questions, and you need answers. But I'll try to help. Too, while you did an excellent job of typing a good post, maybe you can provide a little different angle on this, so others can help.

Sorry I have not been as helpful as I would like to be.

[arin_2323]

Originally Posted by BradM

Arindam, why do you have to differentiate? Are these two distinct steps in your QMS system?

Why don't the developers document their work? NOTE: I am not currently in software. However, in my system integration days, I was around enough programmers to know they don't get along with documentation. However, when you have a QMS, their supervisor will have to initiate some level of documentation for them.

When the application generates the desired output, could someone not check a box to say that a review has been made?

Could you accept the customer's clearance as a verification?

I know these are questions, and you need answers. But I'll try to help. Too, while you did an excellent job of typing a good post, maybe you can provide a little different angle on this, so others can help.

Sorry I have not been as helpful as I would like to be.

Hi buddy Brad!!!


My sincerest thanx to you for the excellent mental support provided by you, you are quite right in saying that in software development paradigm it's really very hard to differentiate between the review and verification processes...both of this terms sound so similar..meaning wise and application wise.

As per my understanding of the standard goes, in the design and development lifecycle of a product, the activities till the verification stage is generally carried out before the product is put into service / operation. Validation is generally done when it is operating in the real time environment.

For classical production process the issue can be very easily sorted out by offering a pilot lot to the customer..then after the adequate validation is done on the product, it is produced in batches.

Moreover if the organization is claiming the design patent then the customer clearence is noway coming within the organization's design life cycle...rather the customer test results can be more closely associated with the customer feedback. The customer after thorough testing will come up with some comments on whether he is satisfied / dis-satisfied / or there is some oppurtunity for improvement.

If he is satisfied then the application can be straightway put into service. But if not so the pointer will once again placed at element no. 7.3.2.

It is quite obvious theat the technology head wants to reduce his documentation process by mentioning review and verification as same...but in doing so isn't the design & development cycle is broken??????

Hope I am sucsessful in creating more confusion in your mind , but pal ,I can assure you we need to crack our brain real hard in finding out the broken pieces of this apparently simple looking yet complicated jigsaw..................

Thanking you once again .

Cheers

[harry]

Hi Arindam,

First I must state that I am not a software guy. One question I would like to ask is isn't review and verification one and the same thing? Or are you talking about verification and validation, the so-called V&V?

[arin_2323]

Originally Posted by harry

Hi Arindam,

First I must state that I am not a software guy. One question I would like to ask is isn't review and verification one and the same thing? Or are you talking about verification and validation, the so-called V&V?

Dear Harry,

I am not talking about V&V, as the issue of validation apparently seems to be addressed in my present system. . The issue we are debating on is Review and verification.

The Clause no. 7.3.3 of ISO 9004 is providing some gudileines and having specific mention about the software development...but not very clearly defined.

What best I could find out are following keywords in the review topic as follows:

1. Progress of planned design and development process : May be pointing towards the records maintained and the dvelopment plan during design.

2. Meeting Verification and validation goals: Seems from this point , verification is somewhat different from review

3. Life cycle data on performance of the product: May be hinting at the internal project data and progress report.

4. control of changes and their effect during the design and development process.

Similarly for Verification :


1.Comparative methods , such as alternative design and development calculation : How????? I am not quite sure

2.Evaluation against similar products : In software development process every module is differnt from the other, the software developed for internal use makes the scenario even more difficult to practice.

3. Testing Simulations............: Yes, possible but who does it?

4. Evaluation against lessons learned from past process experience such as non conformities and defficiencies : Again same problems like point no. 2.

All these are making the scenario different from a conventional production design.

Hope now we can claim with confidence, review and verification are not same.

Am I successful to convince you ??? Or you can suggest a different kinda thought process. Eager to learn from you, Brad and all other experienced covites.

Cheers

Arindam