Hi all,
I went through the glossary and this is my opinion on what is problem
domain vs solution domain.
Term
|
Disposition
|
Comments
|
Artifact
|
Solution
|
I think that there may be a need for us to select a
term to generally mean “payload”. I think that the term “artifact”
should be reserved as a term for the solution space.
|
Baseline Compatibility
|
Problem
|
|
Composition
|
Solution
|
Same basic comment as Artifact, I think that we
should use the term “Solution” to mean the generic aggregate of
software, and reserve “composition” for the solution.
|
Configure
|
Problem
|
|
Configuration
|
Problem
|
|
Deploy
|
Problem
|
|
Deployment Lifecycle
|
Problem
|
|
Default configuration
|
Problem
|
|
End User License Agreement
|
Problem
|
|
Entitlement
|
Problem
|
|
Fix
|
Problem
|
|
Hosting Environment
|
Solution
|
I think that there is a need to have a term which
refers to this in the problem domain, and would suggest that target or
platform be used and reserve “hosting environment” for the
Solution.
|
Initial Configuration
|
Problem
|
|
Installable Unit
|
Solution
|
|
Installation Program
|
Problem
|
|
Install
|
Problem
|
|
Instance
|
Problem
|
Definition is currently framed in solution terms,
but I think that the term should be defined in the problem space.
|
Integration
|
Problem
|
|
License
|
Problem
|
|
License Enforcement Technology
|
Problem
|
|
License Registration
|
Problem
|
|
Lifecycle
|
Problem
|
|
Migration
|
Problem
|
|
Package
|
Problem
|
Definition is currently framed in solution terms,
but I think that the term should be defined in the problem space
|
Physical Package
|
Problem
|
|
Physical Package Content
|
Problem
|
|
Product
|
Problem
|
|
Provisioning Application
|
Problem
|
|
Resource
|
Solution
|
|
Smallest Installable Unit
|
Solution
|
|
Software Package
|
Problem
|
|
Solution
|
Problem
|
Definition is in Solution terms, but I think that we
should define this term in the problem space.
|
Solution Instance
|
Solution
|
|
Solution Instance Lifecycle Management
|
Solution
|
|
Target
|
Problem
|
Current definition is in solution terms, but I think
we should define this in the problem space.
|
Target Installer
|
Problem
|
|
Uninstall
|
Problem
|
|
Update
|
Problem
|
Current definition is in solution terms, but I think
we should define this in the problem space.
|
Upgrade
|
Problem
|
Current definition is in solution terms, but I think
we should define this in the problem space.
|
All Roles
|
Problem
|
|
Regards,
Debra
From: Christine
Draper [mailto:cdraper@us.ibm.com]
Sent: Thursday, January 26, 2006
1:35 PM
To: sdd@lists.oasis-open.org
Subject: Re: [sdd] [glossary]
interesting finding while parsing the glossary
Jay,
I agree with the principle, but some of the glossary terms are referenced
indirectly - e.g. configure is one of the lifecycle operations, and many of the
requirements refer to "lifecycle operations".
We need to make the paragraph at the start of Reqts Section 2.1 consistent with
the set of lifecycle operations in the glossary - unless we mean something
different by "lifecycle management phases"....
Regards,
Christine
Senior Technical Staff Member
IBM, 11501 Burnet Road,
Mail Point 901-6B10
Austin, TX
78758
1-512-838-3482 tl 678-3482
Jay Nash
<jay@o-ms.com>
Jay
Nash <jay@o-ms.com>
01/26/2006 12:15 PM
|
To
|
sdd@lists.oasis-open.org
|
cc
|
|
Subject
|
[sdd] [glossary]
interesting finding while parsing the glossary
|
|
-----BEGIN
PGP SIGNED MESSAGE-----
Hash: SHA1
Folks,
I decided to use a text analysis script to compare
the terms we have
used in the Requirements Documentation (v.04) with
the terms we are
defining in the glossary. It turned up some
interesting data (short list)
Artifact(s) = 3 uses
Baseline Configuration = 0 uses
Composition = as a noun, 3 uses
Configure = 0 uses
Default Configuration = 0 uses
My understanding of the group consensus is that if
we are not using the
term within the SDD, then we probably don't want
to spend time defining
it our paperwork.
As such, I propose that any terms with ZERO use in
the requirements
document be expunged from the glossary. If
we need them later, we can
always add them back in.
Regards,
Jay Nash
- --
- --
Jay Nash, CTO
OMS SafeHarbor
128
Warren St
Lowell MA 01852
978.937.2363 ext.111
978.937.3784 fax
This message (including any attachments) contains
confidential
information intended for a specific individual and
purpose, and is
protected by law. If you are not the
intended recipient, you should
delete this message and are hereby notified that
any disclosure,
copying, or distribution of this message, or the
taking of any action
based on it, is strictly prohibited.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFD2RHJHsIa/RmVc78RAi6kAJsE4duWL76HIIcFfY/Vk4Y/vFxNeACfc6/O
BdpMUmUl3jiviwjiwLMUtrY=
=6a4R
-----END PGP SIGNATURE-----