Is text-mining a good way to elicit requirements?

Yes, it is.

A landmark work on this topic is AbstFinder. Several other strategies exist. Original documents from the Universe of Discourse are information sources to be used in eliciting requirements. They are of fundamental importance.

However, we must be careful when and how to use text-mining. Way back a simple text-mining strategy was commonly used by some OO practicioners: underlining words in a given text, usually a requirements document in natural language written by clients.
Such strategy is not the best choice.

See what Mitchell Lubars, Colin Potts, and Charles Richter wrote in a 1993 ICSE paper.

"Some protagonists of OOA advocate a bottom-up
strategy in which the analys tunderlines or highlights all
the noun phrases in the source material[Rum91].
This produces a list of candidate objects that must then
be pruned according to certain guidelines. This strategy
is sensible for small problems: objects are likely to be
referred to by noun phrases; making the list requires
little judgement and is almost trivial: and object-oriented
methods make many useful recommendations to help the
analyst prune the list.

However,these tasks become overwhelming for problems
of the size we faced. Listing the noun phrases in a
500-page requirements document is a daunting task
of questionable value. A long, unorganized list is
not a good starting point for the next stages of analysis."

Software Engineering as a Discipline

Some believe that Information Systems should be treated as a discipline in itself. In a recent article at the CACM, Katerattanakul, Han and Rea report that Information System is growing from “an applied discipline drawing upon other disciplines” to “…the new perception that IS is a reference discipline for others”.

They used a cross-reference analysis to show that papers being published in IS journals are being cited in other fields of knowledge. Although most citation came from the field itself and to the seeds disciplines of computer science and management, it is interesting to point out that IS is being cited in journals from engineering, sociology and medicine.

The study used the following approach: selected 1120 articles published in the one of the following journals (as representative of the area): CACM, EJIS, ISJ, ISR, I&M and MISQ; trace references to these articles in two large repositories, SSCI and SCI; the citation source was then classified by areas.

The following areas provided more references to these 1120 articles: IS – 43.9%, Computer Science – 28%, Management 7,6%, Engineering, 5,8%, Sociology, 2,6% and Others with 3,2%.

My understanding from the data is that the authors may have a point, but still most of the references are still too much multidisciplinary instead of interdisciplinary. I was surprised with the difference of Computer Science and Management. I would suppose that most of the citations would come from Management, but… A possible explanation is that from the sample of 1,120 there could have a large set of articles really more on computer science than in information systems, but these just show us how blurred are these distinctions.

Why did I post this note?

Well, I believe if somebody did a similar study of software engineering, it would stand even better as a reference discipline. The previous post on Jackson is one of the reasons why I believe SE is a discipline by itself (see a previous post on the topic).

The Machine

Michael Jackson has been a fundamental contributor to the field of software engineering.

I first learned from Michael with JSP, Jackson Structured Programming and after with JSP, Jackson System Development. I have taught several editions of my course at PUC-Rio using the JSD book.

I use to say that Michael´s writings have evolved in a truly computer science way, that is: bottom up. He started with JSP, then move to JSD, then to the great book on Software Requirements and Specifications and recently to the real abstract book: Problems Frames.

I regret that the great book on Requirements used the “and” in its title: lack of cohesion. However, this is symptomatic of the confusion that these terms bring to the software engineer.

Anyway, this note is to call your attention to a must read paper by Jackson: “Some Basic Tenets of Description”. It is short, 7 pages, and it is aimed at the “heart” of software engineering: modeling.

Let me start by the conclusion. Here Jackson brings out 3 important mantras, of his own. They are:

• "Distinguish the machine from the problem domain"
• "Don’t restrict description to the machine", and
• "State explicitly what is described".

I would add another 4, extracted from the Section titles of the article.

• “Requirements Are Not Given Properties”
• “The Model Is Not the Reality”
• “The Problem Is Not at the Interface”
• “Describing the Machine Is Not Enough”

The article is concise and right to the point. It distinguishes the machine, the problem domain (which I rather name Universe of Discourse) and explicitly points that requirements are desired needs of a set of actors, such that they must reflect a bridge from the problem domain to the machine.

p.s. In searching for the links to JSP and JSD, I found this commentary by Michael on the rationale for both methods.

UML Usage

In a recent article at the CACM, Dobing and Parsons report on the analysis of a UML usage survey (182 respondents) . 171 responses came from UML users and 11 came from partial UML users.

Of the several findings of the article, I would like to stress the following ones:

1) Respondents, on average, have been involved in 27 projects, of which only 6.2 used UML.

2) Class Diagram (73%) is the most frequently used technical description, followed by Use Case Diagram and Sequence Diagram.

3) Use Cases Narratives (87%), Activity Diagrams (77%) and Use Case Diagrams (74%) are the preferred means with regard to client involvement.

4) Class Diagram (93%), Sequence Diagram (91%) and Statechart Diagram (82%) are the preferred means with regard to clarify technical understanding.

7) In asking the question, “reasons for not using some UML components”, some findings are intriguing:
a. 50% said that Class Diagrams were not well understood by analysts, 48% said that Activity Diagrams were not well understood by analysts.
b. 42% said that Statechart Diagrams were not useful for most projects.
c. 42% said that Use Case Diagrams have insufficient value to justify cost and that were not useful with programmers.
d. 49% said that Collaboration Diagrams would capture redundant information.

8) “The median “typical” UML project had a budget of around $1, 000,000 and 6.5 person-years and required 50,000 lines of code”

Some observations:

1) Although being the most used UML component, Class Diagram is also the top misunderstood component! If the data collection and treatment is trustful, then this looks like to be a major contradiction. How a team would claim to use UML, and as such be object-oriented, if their team members do not understand the Class Diagram?

2) Of respondents´previous projects, 27 (average), only 6, 2 (23%) used UML!

3) Use Case Narratives were preferred over Use Case Diagrams as a way to communicate with clients. This is a surprise, since common belief is that Use Case Diagrams, given its iconic character, is the most used medium by OO developers when dealing with clients.

4) The data collected by Dobing and Parsons shows a productivity of 7,692 lines of code per year. Above to the industry averages of 2001, according to Gartner ( as cited in the Msdn Blog by EldarM), which is of 6,200. This brings the productivity at the rate of 32 LOC per day per person (240 working days). Of course, it is widely known that LOC is not the best productivity measure, since different context yields different numbers.

Software Transparency

I have recently presented a keynote address ( in Portuguese) at the Brazilian Software Engineering Conference.

During the talk I reffered to 3 different videos. All of them are very much related to
the concept of transparency.

The first is one of the more transparent communications I ever watched, the second is a TV news reporting that individuals are becoming more willing to be transparent, and the third one is a ingenious and transparent way of understanding buble sort.

IT Unconsciousness

In the July edition of CACM, there is an article with a glowing title: “Managerial IT Unconsciousness”. It is a report on “software failure”, but with a distinct flavor; it is presented from an “IT” perspective. Although, it is still another report on how the lack of software engineering practices does hurt business, it does not mention the term software engineering at all.

The article presents three cases: a) Sydney Water a public company that lost around 61 million dollars, b) RMIT a educational institution who budget 12, 6 million for an academic management system spent 47, 3 and had to re-launch the project and c) One.Tel a company that went bankrupt with problems with its billing system. The amounts are in Australian dollars.

Out of the article I selected three statements from the stakeholders of these systems: a) from RMIT: “The project reports that came through to me and then went on to the council showed that the project was on time, on budget, and meeting its milestones. We all thought that this project was actually OK”, b) from Sydney Water: “There was a belief in Sydney Waters that IT projects of this nature and complexity would inevitably go over budget and be delayed”, and c) from One.Tel “Why bother with petty concerns like faulty billing systems – when you can be thinking about global communications”. Citations pointers are available in the references of the CACM article.

Avison, Gregor and Wilson believe that three common themes/causes emerge from the study: a) “Complexity of application system software”, b) “Poor IT governance”, and c) “Relatively inexperienced and/or powerless IT staff lacking clout among corporate decision makers”. The article concludes stating:

“Management may be seduced by the abstract nature
of software,the ubiquity of PCs on every desktop,
and the availability of genericapplications into
thinking that IT doesn’t matter. ...
Software is flexible,
and IS specialists can develop systems to support
almost any business application. By they are complex
and need rigorous design, carefulconstruction, and
exhaustive testing to ensure they actually do what
they are intended to do. Management must
understand, track, review,and control their progress,
particularly their impact on the rest of the organization.”

In the article there is no mention to the field of software engineering nor to requirements engineering. CMM is mentioned in the comparison table in the article as IT maturity, and as: “CMM Level 1-2” or “CMM Level 1”. I did not know about the 1,5 grade in the CMM scale! Anyhow, this is not the central point. The central point is that in 2006 we still see reports of the type of the failures that have long been reported.

In a previous note, we recall of the LAS case and the lessons learned and published to the community. The last two sentences of the quotation above show that the authors believe that software must implement their requirements and that one has to manage software using a requirements baseline (requirements management is a pre-condition to CMM level 2).

Yes, technology transfer is hard (read about it here and here)!

We need to keep pushing, but sometimes it is a little bit frustrating.

After all, what have we learned?

The Never Ending Story

Recently, Claudia Capelli called my attention to an IEEE Software Article with the title "Nurturing Requirements". The article was written by Dave Thomas and Andy Hunt who call themselves "T h e P r a g m a t i c P r o g r a m m e r s". The short article can be found here.

Claudia, who is working towards her Ph. D., liked the way the article points out to the fact that requirements are in constant change. The article is straight to the point.

Foster, bring up, nourish requirements. Is that the right way? I believe it is. Remember: requirements are a never ending story.

Is it ok to conclude the article with the sentence: "So, while you’re reading the rest of this issue about requirements and process, remember one thing. Requirements aren’t engineered; they’re nurtured."?

It is not! Despite the fact that requirements will evolve as " a complex, multi loop
multilevel feedback system" (using M. Lehman words), requirements elicitation, modeling and analyis must be done the proper way.

Which is this proper way? Answer: use a requirements engineering process. What is the catch? The catch is on using a proper process, which must be tuned to the case at hand.

Requirements evolution, or better software evolution has been a research topic dear to me for almost 10 years. We have introduced the concept of a requirements baseline which is in constant change, but is also the base for the required software.

By the way: if the title reminds you of something, probably it is the movie, or its originator´s book.

An Example of Transparency

Recently I became a flickr fan. Wonderful place to share views of the world.
There, I found out that, once you take a digital photo, your camera records, together with the picture, a series of information.
If your camera has been set with date information, you will be able to see this information as well as other related to the camera used and the characteristics of the given picture.

Want to see it?
a. go to explore flickr
b. go to the month of august
c. choose the picture of august, 5th
d. under "additional information" click on more properties (Oooopsss... The settings were changed, so it is not transparent anymore. See this one instead) (10-14-06).

Software Transparency III

Continuing on Software Transparency ...

I just recalled that seeing it from a requirements engineeing perspective, the work of Steve Fickas and Martin Feather is of fundamental importance.
I am referring to their classical paper Requirements Monitoring in Dynamic Environments.

I beliieve it is also important to take a look at Requirements-based monitors for real-time systems from Peters and Parnas.

Another research is worth mentioning: Bill Robison is working with monitors for some time, a recent work from him is: Implementing Rule-Based Monitors within a Framework for Continuous Requirements Monitoring.

Software Transparency II

After posting a brief description of what I believe Software Transparency should mean, I found several references to this keyword (using Google).

1. A company that registered the term transparency software as a trade mark. They sell database reverse engineering tools.
2. A blog note by Dana Blankenhorn on ZDNet commenting on the announcement by Palamida of an auditing product that helps software transparency. It also mentions GroundWork, a company that sells IT infrastructure monitoring.
3. Reflective is a company that sells software testing technology, it uses the term in a restricted way, for the consuption of software developers.
4. Eric Sink reporting on the concept of transparency at Microsoft. It is not a conincidence that it comes from the Visual Studio group.
5. A note from Dana Blankenhorn on Corante with the title "Open Source Transparency", brings up the key point: "you can see the code". However, who will understand it, and yet, who guarantees that the code you see is the code that is running.
   
6. Prof. Tanimoto presented a keynote at VL/HCC 05 where he links transparency to interfaces:

Transparency is an aspect of software comprising openness in design, glass-box features, and support for interactive inspection.

---
03/20/09

Please see other notes on the topic following the tags.

More details on software transparency are available here.

Requirements Engineering Digital Library

Last week, the 9th edition of WER was held in Rio de Janeiro.

WER is a workshop designed to discuss requirements engineering (RE) in the ibero-american context, and uses three different languages (Portuguese, Spanish and English).

One of the main characteristics of WER is its open acess digital library, WERpapers.

There, you will be able to find peer reviewed articles in several RE topics. Most of the material is in Spanish or Portuguese, but some are in English.

Another useful resource of peer reviewed material is the Time Constrained Requirements Engineering (TCRE) workshop held at RE´02. It is also open acess.

Enjoy them.

Software Transparency

Transparency has been, for long, a general requirement for democratic societies. The right to be informed and to have access to the information has been an important issue on modern societies.

People want to be informed in a proper way. As such, transparency is a well regard characteristic for organizations.

However, as software permeates several aspects of our society, at some point in the future, software engineers will need to deal with yet another demand: transparency. In such foreseen environment, engineers will need to have methods, techniques and tools to help make transparent software.

I am starting to work on the idea of software transparency. If you may: look at your browser under view and and under view code, this is an initial idea towards the big challenge that lies ahed: how to make transparent software. I will soon post a more detailed note about the topic.

If you are also interesed on that, drop a comment.

What is the 5W1H or 5W2H framework?

Lots of writers do use the 5W1H/5W2H framework.

It is an amazing tool in different situations where one needs to clarify or understands something in more depth.

• What?
• Why?
• Where?
• When?
• Who?
• How?
• How much?

As you see from above: there are 5 questions starting with W and 2 starting with H.

This framework is paramount in requirements elicitation, and is widely used in TQM and QCC, which are the pillars of the Total Quality Movement.

I have been trying to find a reference that tells me where these questions came from. Although I suspect that they are from ancient times, I failed to find a reference that would point where they were first enumerated.

The oldest reference was found in Creatingminds.org, where they believe that those questions came from a Rudyard Kipling poem: “I Keep Six Honest
Serving Men ...". Beautiful poem, but I doubt that the 5W1H came from there.

If you happen to know a better origin for the 5W1H, let me know.

(07/07): As pointed out by Charlie Nguyen-Duc in his comment below,it seems that the origins of 5w1h are linked to Marcus Fabius Quintilianus.

Should universities have degrees in software engineering?

In a recent note to the ACM column Inside Risks (January, 2006), Professors John C. Knight and Nancy G. Leveson provide a list of deficiencies in the computer science and computer engineering degree programs regarding a software engineering education.

Although they do not provide any data on the number of programs they have analyzed, we understand that these programs are from several different universities in the US. These programs are responsible for the elite of professionals that will work in the software industry. As such, it is really provoking that so many important points are not been properly covered.

One possibility, long advocated by Professor David Parnas, is the existence of degrees in software engineering as there are degrees in civil engineering, aeronautics engineering, electric engineering, and nuclear engineering. These are some of the so many particular engineering domains where very specific knowledge is needed, but with a solid basis of engineering.

The final sentence of the note says: “A better alternative might be for more institutions to do what a few have done already, develop degrees in software engineering.”. However, there are very few institutions with a particular degree in software engineering. Why is this so? One reason, I believe, is the dispute from the viewpoints of computer science and engineering. It is hard from faculty on these two different camps to agree on what should be core knowledge, and several from computer science camp do not see the value on down to earth engineering practices. It is also usually said that to graduate a software engineer it would be necessary to have stronger basis, like calculus and physics, and there are not such stronger basis in computer science.

I am for university programs in software engineering. I believe that society needs better software engineers, but this pressure is not that clear, maybe because it is hard to understand what are the responsibilities of a software engineer (see my previous note on why software engineering is a must).

How widespread is UML?

I have been asked why I believe UML is not widespread as we may think it is.

There are several reasons; basically I formed my opinion on my own experience. I have adopted UML as a central focus in my SE undergraduate course at PUC-Rio in 1998, and since 2002, UML is not the central focus anymore. My post does not deal with the ups and downs of UML. If you are interest in this discussion see the UML fever debate. Here, I want to share some data I have found.

Professor Freeman likes to say: “Ideas are cheap, data is dear”. Well, I embarked on a quest for finding some data. My tools were two search engines and a basic protocol formed by the words: uml, data, usage, survey, and industrial. Opportunistic mining for some hint, given by the search engines, was used sporadically.

Here is what I have found.

1) General statement of 15% usage. (Computerworld: Carol Sliwa)

“Although the UML/MDA approach is gaining increasingly wider adoption by
application architects, UML usage includes no more than 15% of developers,
according to several analysts’ estimates. Critics say its complexity can be
daunting, and the cultural change for IT shops accustomed to pounding out code
can be difficult to negotiate.”

2) A Scottish survey finds 30% of UML usage.

3) March, 05 Computerworld survey points to 30%.

“Almost half, 48%, selected “No” when asked if their company was using Unified
Modeling Language (UML), and 33% reported that UML is in use at their
organization. Thirteen percent said that there plans for future use.”

4) A small survey done by ESL an electronics product design firm, points to 3%.

5) A survey on a Visual Basic community despite not referring to UML directly point out that support for technical documentation is not a top priority.

6) Data from Austria point to a 30% figure. (Software Development inAustria: Results of an Empirical Study among Small and Very Small Enterprises by Christian Hofer)

7) Other data, from 2002, also points to the 30% figure. (SDTimes Modeling Usage Low; Developers Confused About UML 2.0, MDA By Alan Zeichick)


“The survey, conducted by BZ Research in late June, was completed by 226
individuals. BZ Research is a sister organization of SD Times. According to the
results, 34 percent of developers presently use UML-based modeling for
applications development; of that group, 2 percent said they use UML to model
all applications, and 32 percent said that UML is used only for modeling some
applications.”

8) Booch (Rational founder) and Selic (involved in the OMG UML 2.0 group) kind of agree with 10%. (Sidebar: Waiting for UML 2.0 News Story by Carol Sliwa)

” Many say UML adoption has been slow, in the range of 10%. Why do you
think it has been slow?”

Selic: “One of the most significant factors is that
there is a tremendous
investment in existing technologies, both corporate and
personal, and
jumping to UML does require some incremental costs and investments on top of the
existing one. …. So the adoption has to increase, and we are
certainly
seeing other large vendors that are realizing that model-driven
development
is something that has to happen.”

Booch: “Ten percent is not
necessarily a bad thing, if we consider the
worldwide developer market according
to IDC is approximately 13 million or
so IT professionals. Ten percent’s a nice
healthy number. That’s a great
penetration in the sense that we’re dealing here
with the community of
people that worry about abstraction and design, and if we
limit ourselves to
just that community, I would dare say that the UML has a
tremendous
penetration. If you look at the community at large, perhaps it is
10%, 20%
we’ve seen in some other cases. … … Ergo, modeling becomes
fundamental, and
the UML is indeed the open standard of choice for
modeling.”

Of course that the examples listed are few and scattered in different contexts, but they are reported as data.

How well could we measure such usage pattern is certainly not a trivial matter, and I am not expert on that. Of course that one of the issues would be type of software, type of industry, for instance.

I just want to share what I have found and ask: if do you have any pointers to other data, please send it to me. Thanks

What has software engineering learned from the Y2K problem?

In my lectures I mention the y2k problem and year by year more and more students have not heard about it.

Back in 1999 I was certain that the y2k event and all the media it was generating would be important to the dissemination of software engineering. I am not certain that this was the case.

I remember listening to a talk by Ed Yourdon where he mentioned that cars could have problems, elevators, … and so on. I remember a page at Vassar College where students were advised to have flash-lights, cash and food! Anyway, the hype about the problem had generated massive media, as well as huge investments on avoiding the crisis.

The 2000 started and no big event did happen regarding the y2k. Was it a victory of software engineering? I doubt it. I strongly recommend the reading of a report by Prof. Finkelstein. He was one of the few, at the time, that were questioning all the hype about the y2k.

Anyway, back to 2006. In trying to remember what did happen I decided to use my “memory”. I could not find the page at Vassar, but found a page at NC State where there was a list of y2k links. I decided to follow two links that I had visited last century: the U.S. President's Council on Y2k and the U.S. Senate Special Committee on the Year 2000 Technology Problem. Both of them were unreachable. However, the way back machine (as suggested by Finkelstein) did come handy.

The archive on the U.S. President Council has a list of lessons learned, but, using the last entrance on the archive, there are several missing links. Fortunately the U.S. DOD report is still available.

Well … we should think about it: what have software engineering learned from the y2k?

Why is Software Engineering a Must?

Software engineering is a very rich knowledge field, that expands each day. Different proposals, different paradigms, different representation languages are proposed over and over. Some of them are incremental progress, some of them are just brand new ideas and some are just old stuff with new clothes. It is hard to separate the wheat from the chaff. That is exactly where a sound knowledge in software engineering will come into play.

Teaching software engineering for undergraduate students is considered, by several, a challenge, since at this level of maturity it is hard to convince people that producing software is not just hacking. Worse is the task of communicating to society, what is the role of software engineering and why is it a must.

Usual motivation found in books, special interest groups (see Risks) and in tech-transfer courses are stories from previous projects that somehow failed and that the failure can be traced back to software.

Most of this literature is anedoctal, since it does not provide the details of exactly where the failured ocurred and the reason for it. One of the exceptions, is the London Ambulance inquiry report. I and my co-authors have used this report to gain more insight on failures related to requirements. There are other reports, but mostly of the accounts are of anedoctal nature. This is not a criticism, since all reports that help clarifiying the complexity of software production are more than welcomed.

Software is pervasive, it is everywhere, and its use is increasing at an astonishing rate. However, do you know of a software product that gives warranties about its correct behaviour? Well, if you do, let me know.

My master thesis, back in 1979, was on software costs. I have proposed, at that time, a cost accounting strategy to help software developers keep annotations about work being developed according to cost centers. Well, it was an academic exercise, but I believed it could have helped software engineers. Maintaining a history of annotations would provide a repository for future cost estimation. Well ... I could not convince companies to adopt my proposal, and it took several years that such proposals started to become popular in organizations. An excelent example of this kind of maturity, is its enactament in the micro -- Humphrey´s PSP, which helps the build up of the human resources for mature software organizations. However, it is not trivial to have a process to keep track of workhours and cost centers in sofware organizations.

More and more, we listen to speakers and read writers that tell us of the complex social web of producing software. It is a fact that the technological approach is just part of the picture.

Well, what is the point of this post, "why is software engineering a must?". The point is that we, software practioners, software educators and software researchers must try to make software engineering more transparent to the society at large. Only, by understanding how complex is software production, will society value software engineering.

Well, like most posts, this is a first draft on my thoughts on that subject. What did trigger this writing? I found, in delicious, a tag pointing to a IEEE Spectrum article on the September, 2005 issue. Nothing new to software engineers, but this is the kind of anedoctal report that helps society understand why is software engineering a must.

Ontology, taxonomy, typology

Notes taken from reading some entries in the Encyclopedia Britannica 1972 edition.

Ontology: a term created by Christian Wolff, german philosopher in the 18th century. The intetion was to denote a sub-area of philosophy to study the theory of being. An ontology states a false or true statment about he world.

Taxonomy, the science of classification in a broad sense, is usually restricted to biological classification and specially to the classification of plants, ans animals. Is name come from Greek: taxis (arragement) and nomn (law) . The seven basic (obligatory) taxonomic categories to identify and classify organisms are:
Kingdon, Phylum, Class, Order, Family, Genus, Species.

Typology: a system of grouping, usually called types, which aid demostratin or inquiring by establishing a limited relationship among phenomena. A typology elicits a particular order depending on the purposes of the investigator and the phenomena so arranged.

To view in more detail: Linnaean system.

Indexes: Medlars, Shepard´s Citation (law), KWIC (Keyword in Context)

Facets is a more versatile scheme than the Dewey Decimal (usually the one libraries use).

I also found: "Owing to a classification error, the location identifier of that simple drawer containing all of recorded human knowledge was lost beyond recall" in a note about science fiction (Hal Draper "MS FND A LBRY".

Using Google I found :

"In Hal Draper's 'Ms Fnd in a Lbry' (1961, in Mowshowitz 1977) information technology is both the effect and the cause of the information explosion. New technology is used to reduce the volume of physical storage required for information sources. But this leads to an ever increasing need for bibliographies, indexes, indexes of indexes, bibliographies of bibliographies and so on. In the end errors lead to the complete collapse of the system."

(cutted and pasted from Imagining Futures, Dramatizing Fears by Daniel Chandler)

Amazing: this triggered my recollection of the Guide (Do not panic!) , a wonderful Douglas Adams creation (see h2g2, as well).

Tagging

I just came across an article by Clay Shirky that relates ontology and delicious. I found it a little bit naive, with regard to ontology, but it does present an interesting example of the problems of seeing the world through the lens of General Systems Theory. AOP has found that out, sort of, in a more painful way. See Michael Jacksonbook for an insightful critique of both systems and object oriented modeling paradigms.
Shirky´s observations are on the same path of my quick note. I was amazed that it was the topic of an IEEE Spectrum article (see previous post). Shirky article is a nice way of explanning delicious from the point of view of what is tagging. I am sure we are scratching the possibilities.
I also agree with Shirky in the case of tagging, as more tags you get the better you will be. If this is right, it is yet another evidence that folksonomy, or tagging by the masses is the way to go.
Choosing the tag, tagging, on delicious, I came across an interesting piece by Rashmi on cognitive processes behind tagging. I just glimpsed over it. However from there I found out a very very interesting concept: Game-like Elicitation Methods. I need to look at it more closely.
By the way. I found a nice link for those that like to read more about ontology.

Begin

I have a blog at wordpress.com with the same objective as this one: share some of my views about software engineering in general. There, I use Portuguese. I may post similar observations on the two, but there is no aim to completley mirror each other.

My first observation is the role of google as my extended memory and of delicious as my meta memory.

I recently have found delicious and believe it may be a way of constructing an ontology by the masses. I also have noticed that delicious has a way of directing the construction of consensus by using the principle of a cow-path, that is, the most used path is the best candidate to be the paved path.

Delicious may be a great undertaking by people in building a shared ontology. Let´s see.

Interesting that my observation has a similar understanding by others. Yesterday, I read the last IEEE Spectrum. Amazing,! I found the following article, Folk Wisdom , by Paul McFedries , which address the same issue.

I am curious to see how delicious will evolve, and how the data it collects will be used. It may turn out to be the next google.