RE: [sdd] [glossary] interesting finding while parsing the glossary

[Randy George <randyg@us.ibm.com>]

I would take "Solution" out
of the problem space.  Otherwise, I would expect an instance and the
operations that you would do on it as part of the problem domain.  You
also have composition as part of the "solution space".  
A composition and a solution sound like they should be in the same space.

Regards,
Randy George

Senior Technical Staff Member
Provisioning Architecture
Tivoli Software, IBM Software Group
Austin, TX  
(512) 838-0752     T/L 678-0752

"Danielson, Debra J" <Debra.Danielson@ca.com>

01/26/2006 01:39 PM

To	Christine Draper/Austin/IBM@IBMUS, <sdd@lists.oasis-open.org>
cc
Subject	RE: [sdd] [glossary] interesting finding while parsing the glossary

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

Please respond to
jay

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