As a practitioner, I would focus on the annex specific to my area as the To unsubscribe from the SAC-PSG-DSEEP list, click the following link:
framework for my efforts, and then use the architecture-specific annex
as reference to understand the terminology and for any process guidance
unique to that architecture. So, if I am a VV&A person working on a DIS
exercise, I would use the VV&A annex as my primary guide for the
activities I need to perform (for all types of applications), and then
use the DIS annex for any DIS-specific interpretations of these
activities. More generally, anyone can use whatever annexes may be
helpful to them in performing their assigned responsibilities.
From: SAC-PDG-FEDEP: Katherine Morse
[mailto:[log in to unmask]]
Sent: Friday, July 20, 2007 2:46 PM
Subject: Re: DSEEP Annexes (Again)
From: "Katherine Morse" ([log in to unmask])
*** This message was generated from SAC-PDG-FEDEP ***
How would this work procedurally for the practitioner? For
example, I9m a
VV&A professional working on an HLA federation. I start from the
the DSEEP. Would I first translate to HLA via one annex and then
via another? Would this be part of the HLA annex? Would there be
specific to HLA VV&A? An annex specific to VV&A?
Katherine L. Morse, Ph.D.
FCS M&S Chief Software Engineer
10260 Campus Point Drive, MS A1G, San Diego, CA 92121
(858)826-6728; (858)826-2084 (fax); (858)775-8651 (cell)
> From: "Robert Lutz" ([log in to unmask])
> *** This message was generated from SAC-PDG-FEDEP ***
> Another issue has arisen with respect to the DSEEP annexes
that I would like
> your opinion on. As you know, our current thinking has been
> would be tied to the architectures/protocols that employ the
DSEEP, like HLA,
> DIS, and TENA. However, I have begun to get inquiries about
the potential for
> having annexes also dedicated to the perspectives of the
> disciplines that have roles within the process, such as
testing and/or VV&A.
> If we allowed this, I suppose that things like
project-specific case studies
> of the process could be next. The issue is how restrictive we
want to be
> regarding what we include as annexes. We could either stick
with our current
> path (architecture-specific views only), or we can allow all
comers to define
> annexes of any type if they feel it would be useful for their
> anything in-between. Thoughts?
> To reply: [log in to unmask]
> To start a new topic: [log in to unmask]
> To view discussion:
> > 6>
> To (un)subscribe: Send a message to
> [log in to unmask] with the
> in the message body.
> Important: the unsubscribe email needs to be in plain text
format, and needs
> to have no subject line.
> SISO: http://www.sisostds.org/
To reply: [log in to unmask]
To start a new topic: [log in to unmask]
To view discussion:
To (un)subscribe: Send a message to
[log in to unmask] with the word
unsubscribe in the message body.
Important: the unsubscribe email needs to be in plain text
format, and needs to have no subject line.
To unsubscribe from the SAC-PSG-DSEEP list, click the following link: