Validation is not a software process

"Doing things right" versus "Are we doing the right thing"; Verification versus Validation ... easy to get lost, right?

DO-178B makes life easy.

How? Check out section 6.0 of DO-178B. What does it say? Verification Processes. Not Verification and Validation Processes.

So, whatever you do to satisfy Section 6.0 is verification. Reviews, Analysis, Low-Level testing, High-Level Testing, Hardware-Software Integration, etc. are all verification processes. Within the domain of DO-178B, you never ever validate the software.

Validation belongs to the Systems Domain. 

Comments

[bikramdas]

To scope and define an adequate validation procedure the URS has to be detailed sufficiently for various assessments to be made. The main assessment that concerns us with software validation documentation is the risk assessment. This assessment is only concerned with ensuring that the degree of validation that is proposed; is compliant with the regulatory requirements.
So at this early stage it is required to execute a risk assessment against the URS to see what category the software validation is going to be.more information

[sanjayadashd]

This in itself should not be an issue unless viewing DO-178B in total isolation, as the “standards” covering system processes (typically ARP4754) address the validation activities.
http://www.automateandvalidate.com

[sanjayadashd]

The above example is for testing. But this is true for all other phases. When you are reviewing low-level requirements against high-level requirements, for instance, the high-level requirements are a given. You check if the low-level requirements have correctly elaborated the high-level requirements or not.

http://www.automateandvalidate.com/

[Amitabh]

@RMH, I agree.
Software and Systems processes cannot be seen as water-tight compartments.
It's just that this particular blog focuses more on DO-178B and it does give me some kind of kick to see people react the way they do when I say Validation is beyond their scope of work. :)

[RMH]

Amitabh is quite correct in that validation, per se, is beyond the scope of DO-178B as it is considered to be an activity undertaken by the systems process. This in itself should not be an issue unless viewing DO-178B in total isolation, as the “standards” covering system processes (typically ARP4754) address the validation activities.

DO-178 needs to be seen as one of a suite of “standards” covering airborne systems and equipment development – it was just first to the table with ARP4754, ARP4761 and DO-254 arriving much later. Do not always see a wall between systems and software processes as it is perfectly acceptable to claim certification credit for system verification or system validation performed as part of the software life cycle.

Note that DO-178B is being updated to DO-178C and ARP4754 to ARP4754A.

[Amitabh]

@Software Testing Services,
thanks for your comment. Your comment is similar to Ammiraju's (see first comment). I have responded to that already.
I know this comes as a shock to most software testers. But the fact remains that as per DO-178B, validation is NOT a software process.
Ok, perhaps I got it wrong. Please do me a favour. Please tell me which paragraph of DO-178B discusses validation and in what context. If someone can point out to the relevant paragraph, I will retract my stand.

[Software Testing Services]

Validation is called as if we are doing the right things and verification is checking the work done is right or not. Verification is done at the testing phase in SDLC.

[Amitabh]

@Ammiraju, we are talking processes here. Validation is beyond DO)-178B. When you ask the question: "Am I writing test cases as intended?" you are actually asking, "Am I writing test cases to test the correct implementation of the requirement being tested?" That's all. Strictly speaking, at that stage, the requirement is not questioned. You do not ask, "Is the requirement right?" This is true for all stages of the SDLC.
The above example is for testing. But this is true for all other phases. When you are reviewing low-level requirements against high-level requirements, for instance, the high-level requirements are a given. You check if the low-level requirements have correctly elaborated the high-level requirements or not.
One might argue that checking SW Requirements against Systems Requirements is validation. Again, unfortunately, it is not. You do not question is the Systems requirements are correct or not, and as required. Verification assumes that the input is correct.
For a software engineer it is difficult to digest that validation is beyond his/her scope of work, but that's how it is. Validation can only be done at the Systems Level.
Check out the definition of Validation in the glossary of the DO-178B. Also, trace the word "validation" using the index to see under what context validation is used.
In fact, when I first told this to a person who was involved in the DO-178B committee (and is now involved in the DO-178C development), that person too had similar reaction. But on checking the glossary and the index, that person came around.

[Ammiraju]

I would never agree with this...

Validation is " Are we doing right things" can be done even in Do-178B. It is part and parcel of game.
When Writing Test Cases/Code/Requirments, you can ask a quetsion that Am I writing Test Cases as intended. My SW is Level B am I writing test cases for Level C or A.? This can be a classic example for Validation.