Pat,

That was you? Wow, who knew? (8>

Regards,
Rob L.
--- In cmmi_process_improvement@yahoogroups.com, "Patrick OToole"
<PACT.otoole@...> wrote:
>
>
> Rob,
>
> As long as we're handing out credit, I would like to take full
credit for inventing CAPITAL and lowercase letters. Perhaps I am
revealing something about my age here. Never mind...
>
> Regards,
>
> Pat
>
> ----- Original Message -----
> From: Rob Leinen
> To: cmmi_process_improvement@yahoogroups.com
> Sent: Wednesday, November 19, 2008 8:12 PM
> Subject: [CMMi Process Improvement] Re: A query on VALIDATION
>
>
> Btw. As much as I would like to take credit, it is not my
> interpretation. The interpretation is just as Mr. Juran defined
it
> when he authored the "goodness-of-fit" quality model.
>
> --- In cmmi_process_improvement@yahoogroups.com, Andre Heijstek
> <andre.heijstek@> wrote:
> >
> > Hi Rob,
> >
> > I think your interpretation of VAL corresponds to what Pat has
> just
> > called "small v" validation.
> > A form which he, and I, would NEVER accept as the full
solution,
> > leading to a ML3 rating.
> > That does not mean to say, small v validation is a bad thing to
> do.
> > But, big V validation is still needed as well.
> >
> > Regards, andre.
> >
> > On 18 nov 2008, at 00:18, Rob Leinen wrote:
> >
> > > Andrea,
> > >
> > > Please see Pat's and David's responses. They both are saying
the
> > > same thing (I doubt I could explain it any better), and Pat
gives
> an
> > > excellent example.
> > >
> > > Regards,
> > > Rob L.
> > > --- In cmmi_process_improvement@yahoogroups.com, Andre
Heijstek
> > > <andre.heijstek@> wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > Factually you are probably right. But I still don't like
it,
> which
> > > > means I might issue a CR towards the CMMI.
> > > >
> > > > Given your interpretation of the model, what is really the
> > > difference
> > > > between VER and VAL?
> > > > E.g. reviewing a design spec by programmers could be
interpreted
> > > as
> > > > VAL: the programmers are the users of the spec, and the
> environment
> > > is
> > > > the desk of the programmers.
> > > > But, you could also see this review as pure VER SG2. It
should
> be
> > > a
> > > > main rule for everyone to get the stakeholders involved in a
> > > review,
> > > > and programmers are stakeholders of designs.
> > > >
> > > > If we would take my definition, this review would only
qualify
> as
> > > VAL
> > > > when "real" customers would participate in the review (next
to
> > > > programmers and others). The customers would review the
design
> > > spec
> > > > with completely other intentions than the programmers.
> Programmers
> > > > will look for clarity: "does this spec allow me to do a good
> > > > programming job, does it delineate the modules well from
each
> > > other,
> > > > etc.". The customers would look for compliance with their
> intended
> > > > requirements.
> > > >
> > > > In my view, having these customers participate in the
review,
> > > offers a
> > > > tremendous advantage over 'just' involving the programmers.
And
> > > that
> > > > is not to say that reviewing designs by programmers is a
bad
> idea.
> > > Not
> > > > at all, it is great VER, but it shouldn't quality for VAL.
> > > >
> > > > Regards,
> > > > André Heijstek
> > > > andre.heijstek@
> > > > www.improvementfocus.com
> > > > Mobile: +31 648 476 451
> > > > Marga Klompéstraat 23
> > > > 2805 CZ Gouda
> > > > The Netherlands
> > > >
> > > >
> > > >
> > > >
> > > > On 14 nov 2008, at 22:55, Rob Leinen wrote:
> > > >
> > > > > Actually Andre,
> > > > >
> > > > > CMMI states that validation should be performed with
the "end
> > > users"
> > > > > and "relevant stakeholders" of a product (or product
> component);
> > > it
> > > > > does not use the term "customer". In my response customer
is
> > > > > synonymous with end user and relevant stakeholder,
customer is
> > > what
> > > > > the Juran Quality Handbook refers to product/work product
> users
> > > as.
> > > > >
> > > > > The problem as I see it, is that too many interpret
> validation as
> > > > > only involving the paying customer or the end users of
the
> final
> > > > > product and forget there are many other users of the
products
> > > > > (including work product) that depend on their goodness.
> > > > >
> > > > > Regards,
> > > > > Rob L.
> > > > > --- In cmmi_process_improvement@yahoogroups.com, Andre
> Heijstek
> > > > > <andre.heijstek@> wrote:
> > > > > >
> > > > > > > Hi Rob,
> > > > > > >
> > > > > > > Interesting thought to take a wide interpretation
> > > of 'customer',
> > > > > but
> > > > > > > it is not according to my understanding of the model.
> > > > > > > If I read the definition of customer in the glossary,
it
> > > states:
> > > > > > > The party (individual, project, or organization)
> responsible
> > > > > > > for accepting the product or for authorizing payment.
The
> > > > > > > customer is external to the project (except possibly
when
> > > > > > > integrated teams are used, as in IPPD), but not
> necessarily
> > > > > > > external to the organization. The customer may be a
higher
> > > > > > > level project. Customers are a subset of
stakeholders.
> (See
> > > > > > > also "stakeholder.")
> > > > > > >
> > > > > > > This clearly defines customers as people outside the
> project,
> > > > > and
> > > > > > > people authorising payment.
> > > > > > > It would also violate the core intent of VAL: "making
sure
> > > that
> > > > > the
> > > > > > > customer gets what he intended to get, but was not
able to
> > > > > specify
> > > > > > > correctly".
> > > > > > > (That definition is not in the glossary, it carries my
> > > > > copyright ;-)
> > > > > > >
> > > > > > > Regards, Andre.
> > > > > > >
> > > > > > > On 14 nov 2008, at 14:50, Rob Leinen wrote:
> > > > > > >
> > > > > > >> Ali,
> > > > > > >>
> > > > > > >> First, designs can be validated through prototyping
and
> > > > > simulation.
> > > > > > >>
> > > > > > >> Beyond that, you also need to ask yourself who are
the
> > > consumers
> > > > > (aka
> > > > > > >> clients) of the design outputs. Your validation
> activities of
> > > > > these
> > > > > > >> artifacts should also focus on how well it meets the
> > > consumers
> > > > > > >> needs. In the case of design, are they written in a
way
> that
> > > the
> > > > > > >> development team can write their coding
specifications
> and
> > > build
> > > > > the
> > > > > > >> solution, and are they written to where a test team
can
> > > create
> > > > > test
> > > > > > >> cases? If not the goodness-of-fit criteria for these
> > > artifacts
> > > > > is not
> > > > > > >> met, as they do not satisfy their expected needs
when
> placed
> > > in
> > > > > the
> > > > > > >> envionment for which they will be used.
> > > > > > >>
> > > > > > >> For validation, the customer can be any consumer of
the
> > > > > product/work
> > > > > > >> product and not just the end client/user.
> > > > > > >>
> > > > > > >> Regards,
> > > > > > >> Rob L.
> > > > > > >> --- In cmmi_process_improvement@yahoogroups.com,
zubair
> Ali
> > > > > > >> <zubhh@> wrote:
> > > > > > >> >
> > > > > > >> > Pat, you are making validation sound like a PMC
that is
> > > applied
> > > > > > >> througout the project life cycle. For example there
is
> > > planning
> > > > > > >> phase, req analysis , design, build(coding), testing,
> > > Deployment
> > > > > and
> > > > > > >> UAT.
> > > > > > >> > Thats most typical life cycle. How can u get ur
design
> > > > > validated
> > > > > > >> by the client if it's totally internal engineering
> process.
> > > Then
> > > > > > >> comes the coding phase (unless a client has asked
> > > particularly
> > > > > for
> > > > > > >> the review of design and coding). How about the
planning
> > > phase. I
> > > > > > >> think a validation can be of schedule, project plan
as
> it is
> > > > > shared
> > > > > > >> with the client.
> > > > > > >> > May be its a matter of internal process how the
> validation
> > > is
> > > > > > >> applied and differs from company to company.
> > > > > > >> > Can u pls clarify how it is applied thoughout the
life
> > > cycle?
> > > > > and
> > > > > > >> how would u cover the coding and the design phase for
> > > validation
> > > > > ( if
> > > > > > >> the its internal and doesnt requie client review or
> > > involvement)
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > --- On Wed, 11/12/08, Patrick OToole
<PACT.otoole@>
> wrote:
> > > > > > >> >
> > > > > > >> > From: Patrick OToole <PACT.otoole@>
> > > > > > >> > Subject: Re: [CMMi Process Improvement] Re: A
query on
> > > > > VALIDATION
> > > > > > >> > To: cmmi_process_improvement@yahoogroups.com
> > > > > > >> > Date: Wednesday, November 12, 2008, 3:07 AM
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > 
> > > > > > >> > Â
> > > > > > >> > The active involvement of the client in the
> establishment
> > > and
> > > > > > >> validation of the requirements sounds like a good
> practice
> > > that
> > > > > is
> > > > > > >> meeting your need, and one that certainly supports
the
> > > assertion
> > > > > that
> > > > > > >> the RD practices have been implemented.
> > > > > > >> > Â
> > > > > > >> > I'm a bit concerned that, after the customer
finally
> signs
> > > off
> > > > > on
> > > > > > >> the requirements, the next time they are involved is
> UAT.Â
> > > Given
> > > > > > >> that I have limited insight into your overall
process (as
> > > > > indicated
> > > > > > >> by my lack of insight into the very active customer
> > > involvement
> > > > > in
> > > > > > >> establishing the requirements) , it is likely that
there
> are
> > > > > > >> additional validation activities throughout your
> development
> > > > > process,
> > > > > > >> but the way you stated it in your post, there is no
> > > indication of
> > > > > > >> that.
> > > > > > >> > Â
> > > > > > >> > The bottom line is that Validation is expected to
be
> > > performed
> > > > > > >> throughout the life cycle. If you have questions
about
> the
> > > > > adequacy
> > > > > > >> of your implementation, you might be well-served to
have
> an
> > > > > > >> authorized lead appraiser evaluate your
implementation
> and
> > > > > provide
> > > > > > >> insightful feedback regarding how well it meets the
> model's
> > > > > intent.
> > > > > > >> > Â
> > > > > > >> > Regards,
> > > > > > >> > Â
> > > > > > >> > Pat
> > > > > > >> > Â
> > > > > > >> > Â
> > > > > > >> >
> > > > > > >> > ----- Original Message -----
> > > > > > >> > From: zubair Ali
> > > > > > >> > To: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > Sent: Tuesday, November 11, 2008 9:56 PM
> > > > > > >> > Subject: Re: [CMMi Process Improvement] Re: A
query on
> > > > > VALIDATION
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > I think what i was trying to relay has been
> misunderstood.
> > > > > > >> > Well the issue resolution process we go through
for RS
> and
> > > FS
> > > > > are
> > > > > > >> just not document review.First the clients are fully
> > > involved in
> > > > > it.
> > > > > > >> The draft is being worked on with the client until
all
> the
> > > > > issues are
> > > > > > >> resolved. Whats being assumed here is that its just a
> > > document
> > > > > > >> review. Thats not the case.To clarify requirement as
u
> > > said "to
> > > > > get
> > > > > > >> into the customers head" is very true and we make
sure
> that
> > > > > happens.
> > > > > > >> They are result of requirements workshops, accessing
the
> > > client
> > > > > > >> application for further clarifiction but still
working
> on the
> > > > > > >> document and updating it when req become clear.
> > > > > > >> > RD is fully applied in that sense.
> > > > > > >> > In the end you have to get the custsomer to
formally
> agree
> > > to
> > > > > a set
> > > > > > >> of requirements (mutually worked upon) otherwise
changes
> > > would be
> > > > > > >> nightmare from scope creep perspective
> > > > > > >> >
> > > > > > >> > Plus in the UAT phase clients gets he access to
> > > application for
> > > > > > >> full testing for their satisfaction.
> > > > > > >> >
> > > > > > >> > --- On Sat, 11/8/08, Patrick OToole <PACT.otoole@
> att.net>
> > > > > wrote:
> > > > > > >> >
> > > > > > >> > > From: Patrick OToole <PACT.otoole@ att.net>
> > > > > > >> > > Subject: Re: [CMMi Process Improvement] Re: A
query
> on
> > > > > VALIDATION
> > > > > > >> > > To: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > > Date: Saturday, November 8, 2008, 1:00 PM
> > > > > > >> > > Zubair (and also responding to Pankajakshan' s
most
> > > > > > >> > > recent question directed to me):
> > > > > > >> > >
> > > > > > >> > > It's a bit hard for me to swallow that simply
having
> > > > > > >> > > the client review and approve the requirement
spec
> > > should be
> > > > > > >> > > considered validation - and if it is, it should
be
> > > > > > >> > > considered a very light version thereof.
> > > > > > >> > >
> > > > > > >> > > RD SG3 has 5 practices, so it's hard to say that
the
> > > > > > >> > > "customer review and approval of requirements"
> > > > > > >> > > addresses all 5 practices. One other thing to
> consider -
> > > > > > >> > > according to the RD Introductory Notes, RD SG3 is
> > > intended
> > > > > > >> > > to be performed concurrently with both RD SG1
(that
> is,
> > > > > > >> > > customer requirements are validated) and with RD
SG2
> > > (that
> > > > > > >> > > is, product requirements are also validated).
> > > > > > >> > >
> > > > > > >> > > One of the characteristics of the ML3 process
areas,
> and
> > > > > > >> > > therefore a characteristic of ML3 organizations,
is
> > > > > > >> > > proactivity. Validation should be a proactive and
> > > > > > >> > > interactive exploration of the mutual
understanding
> of
> > > the
> > > > > > >> > > customers wants, needs, expectations, and
constraints
> > > > > > >> > > throughout the life cycle so that we increase the
> > > > > > >> > > probability of hitting the mark with the end
product.
> > > > > > >> > >
> > > > > > >> > > The trick is to "get inside the customer's
> > > > > > >> > > head" to extract that which provides a more
robust
> > > > > > >> > > understanding of what they are really looking
for in
> the
> > > > > > >> > > product. Scenario based discussions (i.e., use
cases
> and
> > > > > > >> > > such) often reveal subtleties that might
otherwise be
> > > > > > >> > > overlooked. Prototypes and simulations can have
a
> similar
> > > > > > >> > > result.
> > > > > > >> > >
> > > > > > >> > > Just having the customer read and sign-off on the
> > > > > > >> > > requirements is better than nothing, but it
feels way
> > > light
> > > > > > >> > > to me.
> > > > > > >> > >
> > > > > > >> > > Regards,
> > > > > > >> > >
> > > > > > >> > > Pat
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > ----- Original Message -----
> > > > > > >> > > From: zubair Ali
> > > > > > >> > > To: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > > Sent: Saturday, November 08, 2008 2:19 AM
> > > > > > >> > > Subject: RE: [CMMi Process Improvement] Re: A
query
> on
> > > > > > >> > > VALIDATION
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Hi All,
> > > > > > >> > >
> > > > > > >> > > It's an interesting topic. Validation has to be
> > > > > > >> > > taken for the whole project life cycle or SDLC
(100%
> > > > > > >> > > agreement wth PAT )whenever there is something
to be
> > > > > > >> > > validated from the customer side(Iterations are
> > > included).
> > > > > > >> > > Examples are as follows:
> > > > > > >> > > Requirment Specifictaions( High Level
Requirements)
> > > > > > >> > > have to be signed off by the client or agreed
upon
> by the
> > > > > > >> > > customer. That's Validation on RS.
> > > > > > >> > > Functional Specification and other requiments for
> > > > > > >> > > the project which need customer's approval.
> > > > > > >> > > Then the last one is the built product(Product
plus
> > > > > > >> > > its environment) to be validated and accepted or
> signed
> > > off
> > > > > > >> > > by the customer/actual user)
> > > > > > >> > >
> > > > > > >> > > If the customer does not approve in the
> > > > > > >> > > Requirments/ funtonal specifcations then its a
> defect in
> > > the
> > > > > > >> > > product(work product which leads to the ultimate
> product)
> > > > > > >> > > because the business logic is not right from the
very
> > > > > > >> > > beginning.( hence validation has already
started).
> > > > > > >> > > For our projects we go through the issue
resolution
> > > > > > >> > > process with open and closed items for our
requirment
> > > > > > >> > > analysis phase.It's very similar to finding a
defect
> but
> > > > > > >> > > at a very inital stage when the cost would be
far
> less to
> > > > > > >> > > remove it before starting to build it.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Regards
> > > > > > >> > > Zubair
> > > > > > >> > > --- On Fri, 11/7/08, Heather Oppenheimer
> > > > > > >> > > <heather@oppenpartne rs.com> wrote:
> > > > > > >> > >
> > > > > > >> > > From: Heather Oppenheimer
> > > > > > >> > > <heather@oppenpartne rs.com>
> > > > > > >> > > Subject: RE: [CMMi Process Improvement] Re: A
> > > > > > >> > > query on VALIDATION
> > > > > > >> > > To: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > > Date: Friday, November 7, 2008, 9:46 PM
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Hi - Actually, check the introductory notes at
> > > > > > >> > > the beginning of the VAL process area: It
says "The
> > > > > > >> > > methods employed to accomplish valiataion can be
> applied
> > > to
> > > > > > >> > > work products as well as to the product and
product
> > > > > > >> > > components.. . The work products (e.g.
requirements,
> > > > > > >> > > designs, and prototypes) should be selected on
the
> basis
> > > of
> > > > > > >> > > which will satisfy user needs and this
validation is
> > > > > > >> > > performed early and incrementally throughout the
> product
> > > > > > >> > > lifecyle."
> > > > > > >> > >
> > > > > > >> > > It may be easiest to understand validation in the
> > > > > > >> > > context of the final end product being executed
in a
> test
> > > > > > >> > > environment that reproduces the actual
environment
> (or
> > > even
> > > > > > >> > > the environment itself), but validation can and
> should be
> > > > > > >> > > done as early as possible throughout the
lifecycle.
> In
> > > many
> > > > > > >> > > cases, it's prohibitively expensive (and/or
> dangerous,
> > > > > > >> > > as Pat is implying below!) to wait until the end
to
> make
> > > > > > >> > > sure the product/service will work as intended
once
> it is
> > > > > > >> > > deployed.
> > > > > > >> > >
> > > > > > >> > > Heather Oppenheimer
> > > > > > >> > > www.oppenpartners. com
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > ------------ --------- --------- --------- ------
---
> ----
> > > ----
> > > > > - -
> > > > > > >> > > From: cmmi_process_ improvement@ yahoogroups.
> > > > > > >> > > com [mailto:cmmi_ process_improvem
ent@yahoogroups.
> com]
> > > On
> > > > > > >> > > Behalf Of Nanda Kishore Panakanti
> > > > > > >> > > Sent: Thursday, November 06, 2008 10:09 PM
> > > > > > >> > > To: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > > Subject: {Disarmed} RE: [CMMi Process
> > > > > > >> > > Improvement] Re: A query on VALIDATION
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > I think we are deviating from basics and
> > > > > > >> > > getting into - who, what, when and where -
performs
> > > > > > >> > > Validation or Verificationâ?¦
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > We need to look at how verification or
> > > > > > >> > > validation is applied on application under test
â?"
> its
> > > > > > >> > > applicationâ?¦ CMMi material states verification
is
> > > against
> > > > > > >> > > work products and validation is against end
> productâ?¦
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Thank you,
> > > > > > >> > >
> > > > > > >> > > Nanda
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > ------------ --------- --------- --------- ------
---
> ----
> > > ----
> > > > > - -
> > > > > > >> > >
> > > > > > >> > > From: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > > [mailto: cmmi_process_ improvement@ yahoogroups.
> com ] On
> > > > > > >> > > Behalf Of Patrick OToole
> > > > > > >> > > Sent: Friday, November 07, 2008 4:01 AM
> > > > > > >> > > To: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > > Subject: Re: [CMMi Process Improvement] Re: A
> > > > > > >> > > query on VALIDATION
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Orhan,
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > So how do companies working on the Space Shuttle
> > > > > > >> > > validate their product components? Or people
working
> on
> > > > > > >> > > nuclear weapons?
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > How do offshore developers who are working on
> > > > > > >> > > products to be used by customers thousands of
miles
> away
> > > > > > >> > > validate their products?
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > I think your perspective is a bit too
> > > > > > >> > > restrictive.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Regards,
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Pat
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > ----- Original Message -----
> > > > > > >> > >
> > > > > > >> > > From: Orhan Kalayci
> > > > > > >> > >
> > > > > > >> > > To: cmmi_process_ improvement@ yahoogroups. com
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > Sent: Thursday, November 06, 2008 2:16 PM
> > > > > > >> > >
> > > > > > >> > > Subject: [CMMi Process Improvement] Re: A query
> > > > > > >> > > on VALIDATION
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > For me:
> > > > > > >> > >
> > > > > > >> > > Involvement of customer is one thing.
> > > > > > >> > >
> > > > > > >> > > The other important thing is the where it takes
> > > > > > >> > > place. If it does not
> > > > > > >> > > take place in the customer environment i.e.
> > > > > > >> > > real environment where the
> > > > > > >> > > product or service will actually be used.
> > > > > > >> > >
> > > > > > >> > > If these two are not exist together at the same
> > > > > > >> > > time then it is not a
> > > > > > >> > > validation for me.
> > > > > > >> > >
> > > > > > >> > > How to prevent burn outs:
> > > > > > >> > > Well, one can replace customer with customer
> > > > > > >> > > representatives, sales
> > > > > > >> > > people, etc. And the real environment can be
> > > > > > >> > > replaced by simulated ones.
> > > > > > >> > >
> > > > > > >> > > Bottom line:
> > > > > > >> > > If it is performed by (real) customer in the
> > > > > > >> > > (real) environment then
> > > > > > >> > > it is a validation.
> > > > > > >> > >
> > > > > > >> > > Q: How a validation can be performed in early
> > > > > > >> > > phases of life cycle?
> > > > > > >> > > A: See iterative development.
> > > > > > >> > >
> > > > > > >> > > Peace,
> > > > > > >> > > Orhan
> > > > > > >> > > Toronto
> > > > > > >> > > http://groups. yahoo.com/ group/SPIRITofCM MI/
> > > > > > >> > >
> > > > > > >> > > --- In cmmi_process_ improvement@ yahoogroups.
> > > > > > >> > > com, "Pankajakshan Nair R
> > > > > > >> > > (Quality Operations), Chennai"
> > > > > > >> > > <PankajakshanR@ ...> wrote:
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > Dear All,
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > This is my first posting to this group.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > I have a query on VALIDATION as used in
> > > > > > >> > > CMMI.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > The difference between VERIFICATION &
> > > > > > >> > > VALIDATION (Please correct me if I
> > > > > > >> > > > my understanding is wrong) is involvement
> > > > > > >> > > of the end-users in validating
> > > > > > >> > > > requirements which happens in VALIDATION
> > > > > > >> > > and not in VERIFICATION.
> > > > > > >> > > > Different activities that could be
> > > > > > >> > > considered as VALIDATION activities
> > > > > > >> > > > are -
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > * POC or Prototypes or Simulations that
> > > > > > >> > > are validated by the
> > > > > > >> > > > customer
> > > > > > >> > > > * Joint reviews and/or walkthrough of work
> > > > > > >> > > products with the
> > > > > > >> > > > customer.
> > > > > > >> > > > * Testing the product or product component
> > > > > > >> > > in the intended
> > > > > > >> > > > environment of use.
> > > > > > >> > > > * Acceptance Testing, where customer also
> > > > > > >> > > participates.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > The purpose of VALIDATION is to ensure
> > > > > > >> > > right product is built,
> > > > > > >> > > > customer's need is met and it fulfills
> > > > > > >> > > its intended use. Given this
> > > > > > >> > > > scenario, can we also include offline
> > > > > > >> > > review of work products by
> > > > > > >> > > > customer as a VALIDATION activity? Are the
> > > > > > >> > > activities mentioned above
> > > > > > >> > > > part of VALIDATION? Is there anything else
> > > > > > >> > > that can be considered as
> > > > > > >> > > > VALIDATION? Request your views and help.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > Quality starts with me - I am responsible
> > > > > > >> > > for quality in deliveries.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > Thanks and Regards
> > > > > > >> > > >
> > > > > > >> > > > Pankajakshan Nair R
> > > > > > >> > > >
> > > > > > >> > > > Quality Operations
> > > > > > >> > > >
> > > > > > >> > > > HCL Technologies Ltd.
> > > > > > >> > > >
> > > > > > >> > > > ODC-500, 5th Floor, Sterling Technopolis,
> > > > > > >> > > 4/293 Rajiv Gandhi Road ,
> > > > > > >> > > > Kandanchavadi, Chennai - 600096 ( India )
> > > > > > >> > > >
> > > > > > >> > > > Tel: +91-44-24546600 Extn. (5165)
> > > > > > >> > > >
> > > > > > >> > > > Direct: +91-44-43957665
> > > > > > >> > > >
> > > > > > >> > > > Mob: +91-9790 96 8601
> > > > > > >> > > >
> > > > > > >> > > > www.hcl.in <http://www.hcl. in>
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > PConsider the environment - please
> > > > > > >> > > don't print this E-Mail unless you
> > > > > > >> > > > really need to - let us be eco-friendly.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > Disclaimer: This message and any
> > > > > > >> > > attachment(s) contained here are
> > > > > > >> > > > information that is confidential,
> > > > > > >> > > proprietary to HCL Technologies and
> > > > > > >> > > > its customers. Contents may be privileged
> > > > > > >> > > or otherwise protected by law.
> > > > > > >> > > > The information is solely intended for the
> > > > > > >> > > individual or the entity it
> > > > > > >> > > > is addressed to. If you are not the
> > > > > > >> > > intended recipient of this message,
> > > > > > >> > > > you are not authorized to read, forward,
> > > > > > >> > > print, retain, copy or
> > > > > > >> > > > disseminate this message or any part of
> > > > > > >> > > it. If you have received this
> > > > > > >> > > > e-mail in error, please notify the sender
> > > > > > >> > > immediately by return e-mail
> > > > > > >> > > > and delete it from your computer.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > DISCLAIMER:
> > > > > > >> > > >
> > > > > > >> > > ------------ --------- --------- ---------
> > > > > > >> > > --------- --------- -
> > > > > > >> > > >
> > > > > > >> > > > The contents of this e-mail and any
> > > > > > >> > > attachment(s) are confidential
> > > > > > >> > > and intended for the named recipient(s) only.
> > > > > > >> > > > It shall not attach any liability on the
> > > > > > >> > > originator or HCL or its
> > > > > > >> > > affiliates. Any views or opinions presented in
> > > > > > >> > > > this email are solely those of the author
> > > > > > >> > > and may not necessarily
> > > > > > >> > > reflect the opinions of HCL or its affiliates.
> > > > > > >> > > > Any form of reproduction, dissemination,
> > > > > > >> > > copying, disclosure,
> > > > > > >> > > modification, distribution and / or publication
> > > > > > >> > > of
> > > > > > >> > > > this message without the prior written
> > > > > > >> > > consent of the author of this
> > > > > > >> > > e-mail is strictly prohibited. If you have
> > > > > > >> > > > received this email in error please delete
> > > > > > >> > > it and notify the sender
> > > > > > >> > > immediately. Before opening any mail and
> > > > > > >> > > > attachments please check them for viruses
> > > > > > >> > > and defect.
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > ------------ --------- --------- ---------
> > > > > > >> > > --------- --------- -
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > > Disclaimer:
> > > > > > >> > > This email and any files attached hereto are
> > > > > > >> > > confidential and intended for the sole use of the
> > > individual
> > > > > > >> > > or entity to which they are addressed. If the
reader
> of
> > > this
> > > > > > >> > > message is not the intended recipient, you are
hereby
> > > > > > >> > > notified that any unauthorized disclosure,
> dissemination,
> > > > > > >> > > distribution, copying or the taking of any
action in
> > > > > > >> > > reliance on the information herein is strictly
> > > prohibited.
> > > > > > >> > > If you are not the intended recipient, please
> contact the
> > > > > > >> > > sender and delete all copies.
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> > Groet,
> > Gruß,
> > Regards,
> > André Heijstek
> > andre.heijstek@
> > www.improvementfocus.com
> > Mobile: +31 648 476 451
> > Marga Klompéstraat 23
> > 2805 CZ Gouda
> > The Netherlands
> >
>