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