ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] any ontology for software development/engineering ou

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Wed, 12 Oct 2011 12:02:04 -0400
Message-id: <4E95B9FC.2070603@xxxxxxxx>


John F. Sowa wrote:
> On 10/12/2011 7:58 AM, Erick Antezana wrote:
>   
>> I was asked to come up with an ontology capturing terms related to the
>> software development process...
>>     
>
>  From Cory C:
>   
>> There are some software process standards of interest that could be turned 
>into Ontologies:
>> OMG SPEM: http://www.omg.org/spec/SPEM/2.0/
>> ISO/IEC 15288, ISO/IEC 24744 and ISO/IEC 12207
>> And an interesting activity: Software Engineering Method and Theory (Semat) 
>http://www.semat.org
>>     
>
>  From Dave B:
>   
>> You may want to check these out ...
>>
>> 
>http://swoogle.umbc.edu/index.php?option=com_frontpage&service=search&queryType=search_swd_ontology&searchString=Software+Development&searchStart=1
>>     
>
>  From Marc W:
>   
>> You might also want to consider the Software Assurance Evidence Metamodel 
>(SAEM)
>>
>> http://www.omg.org/spec/SAEM/1.0/Beta1/
>>     
>
> That's the greatest thing about standards -- you can always find one
> that is incompatible with everybody else's.
>       (01)

I share John's general concern about the plethora of standards, but my 
particular concern is primarily with competing exchange standards, which 
only serve to reduce interoperability of software tools.  In that area, 
one standard may be productive; two standards is necessarily 
counterproductive.    (02)

In the area of software development, the cited specifications, and the 
models they contain, reflect variants in software engineering practice.  
In software engineering, as in most engineering disciplines, different 
people have discovered somewhat different approaches that work well 
(within certain target parameters) for certain kinds of projects.  Some 
authors who were highly regarded for their contributions in the 1970s 
and 1980s are less esteemed now, because the environment and supporting 
technologies have changed.     (03)

So, where these methodologies coincide, one can recognize widely 
accepted engineering practice, and where they differ or conflict, one 
has to ask what the motivations, resources and target products are 
like.  The engineering practice for a 3-year greenfield project with a 
team of 50 and a 10% annual staff turnover is going to be different from 
the practice for a 2-man 6-month feature addition to an existing 
software product, managed in parallel with remedial maintenance and 
related new product development.    (04)

> I often quote a remark that Terry Longstreth made at a database
> conference in 1980:
>
>   
>> Any one of those tools, by itself, is a tremendous aid to productivity.
>> But any two of them together will kill you.
>>         (05)

Conversely, in the area of software engineering, I favor Pope's 
well-known aphorism:    (06)

"A little learning is a dangerous thing;
 Drink deep, or taste not the Pierian spring;
 There shallow draughts intoxicate the brain,
 And drinking largely sobers us again."    (07)


I have seen several projects fail, because they were led by 'experts' 
who brought to the project a religious methodology that was ill-suited 
to the problem and staff at hand.  As John will confirm, at least 3 
different IBM project managers of the 1970s and 80s published the 
software engineering methodologies they used for different successful 
projects.  There were no two alike, but neither were the projects.  (Of 
course, there were dozens of overpriced underperforming systems and 
outright disasters in the same time frame, but everyone was trying to 
learn how to do software engineering, often without benefit of any prior 
engineering experience.)    (08)

In the 1990s, NIST did a study of the 'manufacturing engineering' (how 
to make the product) practices in the automotive industry, and published 
a fairly elaborate engineering process model.  Several industry 
reviewers made essentially the same comment on it:  "This is no one's 
process.  Everyone does most of these things, somewhat differently 
organized, and each of us puts emphasis on the areas that represent our 
biggest cost sources or our biggest competitive advantage."  I also 
appreciated the response that read:  "This is not exactly what we do, 
but it is a lot closer to what we actually do than what our official 
engineering process model says we do."  I would expect the situation in 
software engineering to be similar.    (09)

This diversity does not mean that an ontology for software engineering 
is doomed to be shelfware.  The trick is to recognize and clearly 
specify the common concepts, and segregate the well-defined concepts 
that are method-dependent and may therefore be ignored or superseded by 
other methodologies, and may conflict with some of the concepts in 
them.  The ontological term for this segregation, developed long ago by 
the Cyc folk, is 'microtheories'.    (010)

-Ed    (011)

>
> The conceptual schema, which was a hot topic in those days, was supposed
> to solve the incompatibility problem.  Then ontologies began to address
> the problem.  Then we got the Semantic Web.
>
> The more solutions we get, the worse the problem becomes.
>
> John
>
>  
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/ 
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>  
>       (012)

-- 
Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                Cel: +1 240-672-5800    (013)

"The opinions expressed above do not reflect consensus of NIST, 
 and have not been reviewed by any Government authority."    (014)


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (015)

<Prev in Thread] Current Thread [Next in Thread>