>>> ontology capturing terms related to the
>>> software development process (01)
This is an amazing idea, and for development teams also. I have been a
software developer (primarily web applications) for over half of my life time,
so it would be highly interesting to follow this if anyone is actively working
on this? (02)
Also a lot of dev teams consider themselves to adopting an "Agile" methodology
which is a vague terminology set and workflow it self open to many styles of
interpretations. (03)
But it would be a popular basis to work on. (04)
Matthew M. Kaufman
http://mkfmn.com
1-503-881-6906 (05)
Sent from my iPhone (06)
On Oct 12, 2011, at 9:02 AM, Ed Barkmeyer <edbark@xxxxxxxx> wrote: (07)
>
>
> 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.
>>
>
> 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.
>
> 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.
>
> 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.
>
>> 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.
>>>
>
> Conversely, in the area of software engineering, I favor Pope's
> well-known aphorism:
>
> "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."
>
>
> 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.)
>
> 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.
>
> 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'.
>
> -Ed
>
>>
>> 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
>>
>>
>
> --
> 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
>
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
>
> _________________________________________________________________
> 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
> (08)
_________________________________________________________________
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 (09)
|