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:cool:

Arindam

Can anyone provide assistance for Arindam?

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:cool:

Arindam

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

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.

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 :lmao:, 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:cool:

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?

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:cool:

Arindam

Hi Arindam,

My view is verification consist of many steps (dependent on your type of design) each of which requires a review to make sure its properly or correctly done.

I dug out some old materials and some relevant ones are:
Verification Means Audit the process for proper implementation. Whereas, Validation evaluate the developed product.

Some examples of review are:
Verification Approaches:--(a)Requirement Review: At the end of this review we are ready with our reviewed requirement documents (b) Design Review: At the end of this we are ready with our reviewed design docs. (c) Code Inspection : (d) Code walk through:... Last two approaches are formal and informal analysis of code....

I suppose you can just have a simple form with check boxes to tick when each review is completed. With regards to what other items that may need review, your technical boys should know better.

In reading more of your information, I would tend to agree with you about having steps in the cycle.

I would think a review is in order to demonstrate that what was asked was completed. Did someone develop the software in accordance with the specifications? Were there deviations from the specifications? Was all the documentation of actions completed by the group? I would think a review (albeit rudimentary) would be in order by the technical lead of the group.

Verification would then occur to assure that the software is functional, and works as intended. Or something like that. Like Harry said, I'm not much of a software guy. But, I'll always try my best at helping out.

My interest is going down a little different path. Why is this technical lead so reticent about signing review documentation? Is the paperwork laborious and cumbersome? Does he/she feel it's not their responsibility to review the product up to that point?

Bottom line, if the tech lead won't agree to signing review documentation, and you do not have the power to force it to happen, you might be better served working around that component.

My interest is going down a little different path. Why is this technical lead so reticent about signing review documentation? Is the paperwork laborious and cumbersome? Does he/she feel it's not their responsibility to review the product up to that point?

Bottom line, if the tech lead won't agree to signing review documentation, and you do not have the power to force it to happen, you might be better served working around that component.


Dear Brad,

Thats a millon dollar question hovering arround my mind..that why he is reluctant.... well I admit it's not very easy to follow every theoretical step in practicality when the work volume is large and resources are too few, but what is the harm in giving it a try?

Pal..I understand papaerwork is never laborious unless the the owner makes it cumbersome...I consider this to be my greatest faliure that I am not able to convince him that customer review can never be termed as verification..thats wrong!!!! Terribly wrong!!!!

I dont have any problem in accepting the verdict....may be I will be sucessful in cajoling the external auditor too!!! But we covites find our solace in posting the ambiguos topics in the forum (especially the issues pooh poohed by our superiors)..and feel proud to find a few like minded views from all over the globe. In that process gather some knowledge as well.

Nevermind the sentimental side of arindam..:rolleyes: our quest will continue on this topic.

Cheers:cool:

Arindam