Pavithra, The issue regarding terms such as “capability” and “enterprise” is that they are often used to convey implicit context and scope. But the context and scope is best left to a separate set of modifiers (or dimensional specifiers). You’ll note that the “C” in the name of the NCOIC “SCOPE” model stands for “Capability”. The point of doing that was to highlight that all of the terms in the SCOPE acronym are usually associated with implicit scope, but they really don’t specify any explicit scope by themselves. For example, an enterprise can be something that an individual embarks upon, or even just the individual him/herself. But of course, most people use the term “enterprise” to convey a fairly large scale entity or activity, something on the order of hundreds or thousands of people, say, or even larger. Similarly, the term capability as used in today’s session primarily originated in the defense domain to convey large scale ability/potential to accomplish operational mission objectives (the airplane “performance envelop” example used being actually a fairly small-scale illustration of that usage). Of course, you are correct that in a more constrained scope context, capability might be a feature of a specific product or system (other words contributing to the SCOPE acronym). SCOPE was intended to serve as a semi-quantitative framework for describing (or exploring/investigating/eliciting) the scope of any such entity or activity (the “O” in SCOPE being “Operation”, but it could be “Ontology” with a little bit of modification), rather than relying on people intuiting some particular scope from the term used to represent the entity or activity implicitly. Hans From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Pavithra
Sent: Thursday, March 14, 2013 6:26 PM
To: Ian Bailey; Ontology Summit 2013 discussion
Subject: Re: [ontology-summit] Thank you. Ian,
I don;t want to repeat, but in
In general for software development, a capability is a "feature" or a " function" or a "service" that the product or software is capable of providing. As you said, it is used at a strategic level and later mapped to requirements and systems and so forth.
An use case specifies the usage. It is developed in futuristic way to help the designers to capture how that "feature" or a " function" or a "service" be used by the users ( actor or system when automated) and the behavior of the product or software. It is developed during detail requirement stage!
Scenarios should capture all different ways that "feature" or a " function" or a "service" can be used and exceptions and error handling.
Test cases should include all the scenarios with unique sets of data to capture all possible types of input and exceptions and error handling.
Matrices are developed based on the correct behavior of the test cases .. 0 tolerance is one such matrix.
It was part of RUP development life cycle.. . Rational Rose developed Use case modeling initially. They also supported Object Oriented Modeling and UML. hope that helps.
Thanks,
Pavithra
Folks, The concept of capability as a tool for strategic planning originates in the military. I think McKinsey did the original work on this in the 90s for UK MOD and also some work in US DoD. Capability is explicitly NOT about process. The whole idea is to allow strategic thinking without resorting to design of processes. Capabilities should be expressed in terms of outcomes - what, not how. Once you've worked out your capabilities, you can think about the processes and systems needed to deliver the capability. The concept has now found much wider use in the commercial world - see http://hbr.org/2010/06/the-coherence-premium/ar/1 and it also seems to have found a home in IT for portfolio management and application rationalisation, though whether those guys stick to the process-independence rule is somewhat questionable. It's a very tricky concept to model in an ontology. In IDEAS we take the approach that a capability is the set of all possible things that are capable of achieving a particular outcome. Capabilities can have measures of effectiveness which constrain the members of the set. This approach seems to work for military architectures and strategic acquisition planning. We then have the concept of a capability configuration (people, systems and processes) that deliver the capability (these become subtypes of the capability) and finally fielded capabilities - physical things that are instances of the capability configuration and also therefore instances of the capability. MODAF works this, and I think DoDAF does too. Chris Partridge did a lot of work on this for us - esp. around the dispositional aspects of capability. Regards
www.modelfutures.com
www.integrated-ea.com
tel: +44 7768 892362 Model Futures Limited is a company registered in England and Wales with company number 05248454 Registered Company Address: 1 Nelson Street, Southend-On-Sea, Essex, SS1 1EG VAT Number: 848 7357 75, D-U-N-S Number : 73-998-0352 MOD FATS 4: FATS/4/MFL, DGFM Supplier Code: 56945 |
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (01)
|