Amazing

Parnas on Requirements Engineering

2011-07-31T11:16:00.000-07:00

A must read article from David Parnas on the CACM of Jun/11 tackles the problem of lack of discipline in performing proper Software Engineering.

I am quoting below some of the important remarks, but go ahead and read the full article (here).

“Software development suffers from an infirmity best called Premature
Termination; the symptoms are that developers begin to do something
useful but stop too soon. The result is something that is not only
not very useful, but often harmful.“

“Nowhere is premature termination more evident than in
the field sometimes called "Requirements Engineering" (RE).”

“Programmers are chosen for their ability to design good algorithms and data structures as well as their knowledge of specific programming languages and
support environments. They should not be expected to understand the needs
and characteristics of the future users. Often, a programmer makes incorrect
guesses about the detailed requirements and, consequently, extensive
revisions are required (either before deployment or after users complain).”

“Such lists are a good start but considerable work must be done before one
has resolved the conflicts and ambiguity in such a list to produce a
complete and precise software requirements document, one that tells the
programmers what they must build to satisfy the agreed wishes. It isn't
wrong to produce a wish list but it is wrong to hand it over to the
programmers as a requirements document.”

The Risks of Stopping Too Soon
David Lorge Parnas Communications of the ACM
Vol. 54 No. 6, Pages 31-33

Thoughts on the new shape of social networks -- Delicious X Twitter

2010-12-18T18:09:00.000-08:00

When I started this blog, back in 2006, I was very much certain that tagging was a powerful concept towards building a shared ontology: “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”. At the time del.icio.us was the innovation and the motor behind tagging.

I was motivated and I, myself, spent, like millions of others, a certain amount of time tagging and commenting on whatever I found of interest over the Web. Consulting my delicious account, I would say that my drive started to fade around 2009, where I just catalogued 11 entries in my delicious account. In May of 2009 I entered the bookmark for my Twitter account. In 2010 I just stored 1 entry in delicious. From February of 2006 to 2010 I stored 284 bookmarks and had used 458 tags. From May 2009 to today I have tweeted 654 tweets.

I have to say that I basically use Twitter as a downgrade delicious. I just comment on some site I find of interest and use a shorten link to post it. So I mostly use Twitter as bookmark software. Very seldom I use Twitter for personal communication, but I do use the follow links to stay in touch with what is of my interest. The question is why did I stop using delicious? I do not have a straight answer, but I guess that most of it, was due to my use of Twitter, because I could do it quickly. Like me a lot of Twitter users do use Twitter as bookmark software. However, Twitter does allow #tags, they are not encouraged, since it will use your 140 limit and do not have special support for tagging like delicious.

Conclusion: I left delicious, and are not tagging anymore. I missed that, but maybe I did not see much return, neither a growing enthusiasm over this tagging spree which took me from 2006 to 2009. I missed that, but worse, I believe we missed an opportunity of building a great infrastructure for a shared ontology.

So, in my opinion Twitter contributed in a major way to the decadence of delicious, but I believe the important reason is that delicious did not react on time. Why? Maybe some tech historians will write about, but it is sad that Yahoo is thinking of discontinuing delicious. It was, is, a great idea, but for some reason it got stuck and did not move fast enough. Let´s hope that this decision be overturned and Yahoo care to invest in research and development to revamp the great delicious idea.

Software Engineering for Helping Hospitals

2010-12-12T12:57:00.000-08:00

In 2007, at the Monterey Workshop on Requirements Engineering I heard a talk by Lori Clarke, where she presented the number of “preventable errors in hospitals” as indexed by Jumbo Jet crashes.

In 2008 she and co-authors have published a paper at ICSE telling how Software Engineering technology could help tackling this problem. It is a must read. We understand that there is yet a lot that can be done from a software engineering perspective as to meliorate this catastrophe.

Clarke, in her paper, cites 1999 data, which were around 95K lost lives per year. Googling I found a number that is almost twice the 1999 one, by this site the number is 195k! Using the Jumbo metrics, it is like to say that 40 Jumbo Jet do crash per month (195k/400)/12!

Amazing.

Lula on WikiLeaks

2010-12-08T18:21:00.000-08:00

Amazing. Read it

Cobol as an Obstacle for the Terminator

2010-07-03T05:14:00.000-07:00

Amazing at least!

I do recall that after I watched “The Terminator” in 1984 I did comment with friends that it was funny that the code that was shown on the movie, as the code for the robot, was written in Cobol. I did recognize Cobol right away, and of course, the language was the most inappropriate for handling real time systems. Anyway. It took some time to find a confirmation of my memory, but I found it. It is here.

Well, it happens that the California State Payroll system is a legacy system written in Cobol, as I first guessed and found confirmation by googling. See it here. As Ira Baxter, chief scientist at Semantic Designs, pointed out, this crisis started in 2008. See different sources on the same topic: 1, 2, 3, 4.

Now, 26 (twenty six) years after I watched the movie, I read on the LA Times the following statement from Controller John Chiang: “The state's wheezing payroll system, he says, cannot easily be reprogrammed to make immediate, large-scale salary adjustments.”. It happens that the California State Controller is refusing to follow Gov. Arnold Schwarzenegger orders to cut the state workers’ pay to the federal minimum wage.

Software is, slowly, showing its importance to society at large.

Software Transparency: the Case of AgorithmicTrading

2010-05-09T16:05:00.000-07:00

On May, 6th, 2010 the Dow Jones industrial average, which had been down about 400 points just before 2:45 p.m., plunged nearly 1,000 points in a matter of minutes.
As of now, no explanation has been provided. There are guesses; even conspiracy theory has been evocated. However, the real issue is briefly explained in this quotation from Robert Reich.

…the nation’s and the world’s capital markets have become a vast out-of-control casino in which fortunes can be made or lost in an instant — which would be fine except for the fact that most of us have put our life savings there. Pension funds, mutual funds, school endowments — the value of all of this depends on a mechanism that can lose a trillion dollars in minutes without anyone having a clear idea why. So much of the market now depends on computer programs and mathematical models that no one fully understands…

Algorithmic trading, flash trading and high frequency algorithmic trading are practices made possible by the role of software in the stock market. As stock trading and other financial transactions became more and more digitalized there was a window of opportunity for automated strategies in dealing with finance.

October, 19th of 1987 was the first time the world, at large, became aware of the effects of program trading, which is, trading performed by software. As a result, the NYSE introduced the circuit breaker, a forced halt to avoid a deadlock state on a selling spree.

Since 1987, financial organizations have built teams of gifted young Ph.D.s who specialized on implementing different sorts of strategies, based on mathematics and statistics, using advances on data structures, algorithms and hardware. These people are known as quants. Quants do not necessarily have a degree in Computer Science, but do write algorithms or work closely with people who does.

The use of software over the time span of computer´s networks opened a series of new possibilities in the trading business, where a combination of a huge amount of data and speed played a crucial role bringing new possibilities on volume and price volatility. Exploring this is more akin to gamming than to real trading.

However, the crucial point is that by mixing different sorts of strategies and relying on software over a complex network is a risk business. Of course those institutions are aware of the risks, but we are not sure of how much software engineering knowledge is being used in these systems as to avoid losses.

Notwithstanding, if the market is seen as a game, it is hard to know if you win by luck (an error on the other trading party) or by a fair strategy.

On the other hand, society must have some way of monitoring the quality of trading as to avoid huge mistakes, as per the 1987 crisis and the May, 6th incident. It is seems that the solution used in 1987, halting the market, did not work in 2010, maybe because the speed is different, or maybe because the transactions provided a way of working around the circuit breaker. The point is that there is a need for other type of policy to avoid such problems.

We believe that transparency is the best way to do it. In the specific case, the idea of Software Transparency, that is software has to be transparent to the people who may be affected by it, seems one to explore.

Read more about Software Transparency on a recent paper at the BISE journal (here).

Climate Change

2009-11-27T01:17:00.000-08:00

Just found out the blog maintained by Steve Easterbrook on matters related to climate change. Professor Easterbrook has been studying how requirements engineering may help dealing with the huge problem of climate change, in special by providing modeling capabilities at a level of abstraction distinct from the models usually built by climate scientists.

Anyway, I am adding his blog to the Links bar.

Software Transparency

2009-10-13T11:17:00.000-07:00

Check the Software Transparency portal at PUC-Rio. Click here, or follow the link on the Links sidebar.

Requirements Engineering´s Roots

2009-07-11T08:09:00.000-07:00

I am honored to be among the first researchers to be involved in the Requirements Engineering area. We were involved in the first RE conference as well as on the starting of IFIP W.G. 2.9.

I have recovered, and made available, a literature survey on Requirements. This survey, "A Survey on Requirements Analysis", preceded my Ph.D. thesis. The document contributed to the amalgamation of the different sources that shaped the area. I was one of the first to stress the problem of using the phrase “analysis” to denote the semantics of building requirements. The survey was popular at some point of time, as to be listed on Amazon.

The text is a collection of around 200 bibliography entries, which are summarized and briefly commented.

During the preparation for a talk I gave at Professor John Mylopoulos´s Festschrift I needed to recollect his importance to Requirements Engineering, and as such I went to reread the report. From there it was clear the importance of Mylopoulos to the area, specially because of the book “On Conceptual Modeling, Perspectives from Artificial Intelligence, Databases, and Programming Languages”. Coming back to the Survey I came to the conclusion that it would be a good idea to make it available.

Systems Analysis versus Requirements Engineering

2009-05-24T09:14:00.001-07:00

I have been teaching and preaching that the
phrase "systems analysis" is not a proper term for the task of
building requirements. In reality it causes a lot of
misunderstandings for young professionals.

In fact, the phrase "systems analysis" was used since, in the past,
reverse engineering an "existing system" or "old system" was the
popular way to gain insight about the Universe of Discourse.

Check some of the arguments in a brief summary of a panel
at WER 04.

Tag Oriented Search

2009-04-24T21:08:00.000-07:00

Way back I wrote “Delicious may be a great undertaking by people in building a shared ontology. Let’s see.”

I just have read an article on Computer Magazine that explores this possibility. The article uses a meta-tagging strategy implemented by a tool called “Mr. Taggy”.

It is worth checking it up.

United States CTO

2009-04-18T12:53:00.000-07:00

I just learned from the La Times that the new CTO was finally
appointed. As the CIO, he also comes from Virginia. His name
is Aneesh Chopra (see also a note about him 4 years ago).

This is what President Obama is expecting from this nomination:

"Aneesh and Jeffrey will work closely with our
Chief Information Officer, Vivek Kundra, who
is responsible for setting technology policy across the
government, and using technology to improve
security, ensure transparency, and lower costs.
The goal is to give all Americans a voice in
their government and ensure that they know exactly
how we’re spending their money – and can hold us
accountable for the results. "

I marked the phrase "ensure transparency" above.

The same LA Times news reports on the new position in
federal government, the Chief Performance Officer.

Read more about the new CTO from Tim O'Reilly´s blog, which
includes a video where Chopra talks about Open Government, data
mining, data standards, legacy, broadband, health systems and
so on.

It seems that his strong point is the vision that government
should be in the upfront usage of new technology and not behind it,
as it seems it is in the United States, as well as in other countries.

Bringing the possibilities of IT to government is his main drive.

Interesting as well is his view on approaching R&D as support for
attracting new industries, a policy applied in Virginia for the case
of the Rolls Royce jet engine plant.

Open Government

2009-03-28T04:18:00.000-07:00

President Obama issued a memorandum directing the Chief Technology Officer, in coordination with the Director of the Office of Management and Budget (OMB) and the Administrator of General Services to produce a Open Government Directive.

The major goals of this initiative are:

Government should be transparent
Government should be participatory
Government should be collaborative

Although the major focus will be information transparency we hope that at same point the work group do also point out the need for process transparency, which will lead to the discussion of software transparency.

Let’s hope that the idea of Open Government does flourish and be an example to other countries.

P.S.
During the process of writing the above note, I went on searching to find the link to the Chief Technology Officer site. I could not find one. However, I found out that there will be a Chief Information Officer. I could not find a site for the US CIO, but found out the site for the Council of US CIOs.

Information is Power

2009-03-16T05:39:00.000-07:00

Incredible!

Just read this, in the awakening of the AIG debts. The U.S. government invested over US$ 150 billion on the company as a way of protecting the whole financial system. Press and citizens are crying out: why the company use part of this money to pay bonuses to its financial department? I am quoting the LA Times: "AIG names firms that got bailout cash" by By E. Scott Reckard and Tom Petruno, March 16, 2009.

"AIG did reduce some of its bonus payments last week
under pressure from Treasury Secretary
Timothy F. Geithner but said it was legally obligated
to pay $165 million to the financial products employees,
or else they not only could seek punitive damages
but might quit. That could cause even higher losses,
the insurer said, because these are the only employees
with the knowledge to "unwind" AIG's complex financial deals."

This is, yet, another example of the importance of process transparency.

Information Transparency

2009-02-28T14:22:00.000-08:00

In discussing software transparency, we have differentiated the concept of information transparency from process transparency.

A recent article in Wired does tackle the issue of information transparency. It points out that, allowing access to huge volumes of data is not sufficient for transparency, the information also needs to be understandable. In our definition of transparency as a network of softgoals, we list auditability, understandability, informativeness, usuability and accessibility as required steps towards transparency.

The article mentions the use of XBRL , a domain language for financial data on top of XML, as a possible way of organizing data, and as such contributing for a better understandability as well as allowing for automated processes (software) to interpret them. Although this is positive, it is just a small part of the overall problem.

Traceability

2009-02-25T08:41:00.000-08:00

Well we all know how important requirements traceability is for software engineering.

I just found a curious example of traceability that has a lot to do with business processes and how the financial market does operate. I came to it from watching a video on foreclosures from ABC news.

The written material is here. It is an example of the lack of a proper process for keeping traceability. A side effect: for some people, it is becoming a possible relief, or at least a way of postponing losing their homes.

Cars are Hungry for Code

2009-02-20T12:30:00.000-08:00

Recently, I have quoted Prof. Broy with respect to the amount of processors embeded in cars. Anyway, I just found out that IEEE Spectrum run an news article on the subject. Prof Broy and other experts are cited.
Bottom line: some of the top cars are getting out with around 100 M lines of code!
It is more than amazing, it is almost crazy. Anyway.

Transparency on the LA Times

2009-02-14T10:52:00.000-08:00

Just read a note in the LA Times regarding the lack of transparency on the negotiation for the
bailout bill.

Interesting to notice a link to President Obama white paper on transparency, but the given link does not work.

However, the link to a 9 page (PDF) document is working, in there, one page details the ideas behind: "Create a Transparent and Connected Democracy".

Software Transparency

2009-02-06T06:33:00.000-08:00

Our group at PUC-Rio just finished the first version of a Software Transparency site. Although the site is still in Portuguese, there are links to English material.

There will be, soon, an English version.

If you are concerned with children education

2008-12-06T04:56:00.000-08:00

Below is the Conclusion Section of an article (The efect of video game violence on physiological desensitization to real-life violence) dealing with the effects of violent video games on people.

"The present experiment demonstrates that violent video
game exposure can cause desensitization to real-life violence.
In this experiment, violent game players were less
physiologically aroused by real-life violence than were nonviolent
game players. It appears that individuals who play
violent video games habituate or “get used to” all the violence
and eventually become physiologically numb to it.
The integration of systematic desensitization processes
and models of helping behavior with GAM is heartening in
the insights provided to a long-standing and somewhat
muddled research literature. But it is also frightening in
some of its implications. The existing rating systems (Bushman
& Cantor, 2003), the content of much entertainment
media, and the marketing of those media combine to yield a
powerful desensitization intervention on a global level.
Children receive high doses of media violence. It initially is
packaged in ways that are not too threatening, with cute
cartoon-like characters, a total absence of blood and gore,
and other features that make the overall experience a pleasant
one, arousing positive emotional reactions that are
incongruent with normal negative reactions to violence.
Older children consume increasingly threatening and realistic
violence, but the increases are gradual and always in a
way that is fun. In short, the modern entertainment media
landscape could accurately be described as an eVective systematic
violence desensitization tool. Whether modern societies
want this to continue is largely a public policy
question, not an exclusively scientific one (Anderson et al.,
2003; Gentile & Anderson, 2006)."

N.L. Carnagey et al. / Journal of Experimental Social Psychology 43 (2007) 489–496

America Lives

2008-11-05T05:40:00.000-08:00

Just heard Mr. Obama. Congratulations America!
Let´s hope that change will come, for peace and for a better world all together.

I just picked some parts of the speech that seems to further strenght our belief in better times.

It's the answer that -- that led those who've been told for so long by so many to be cynical and fearful and doubtful about what we can achieve to put their hands on the arc of history and bend it once more toward the hope of a better day. It's been a long time coming, but tonight, because of what we did on this day, in this election, at this defining moment, change has come to America.

It grew strength from the young people who rejected the myth of their generation's apathy

And above all, I will ask you to join in the work of remaking this nation the only way it's been done in America for 221 years -- block by block, brick by brick, calloused hand by calloused hand.

So let us summon a new spirit of patriotism, of responsibility where each of us resolves to pitch in and work harder and look after not only ourselves, but each other.

And to all those who have wondered if America's beacon still burns as bright: tonight we proved once more that the true strength of our nation comes not from the might of our arms or the scale of our wealth, but from the enduring power of our ideals -- democracy, liberty, opportunity and unyielding hope.
That's the true genius of America, that America can change. Our union can be perfected. And what we have already achieved gives us hope for what we can and must achieve tomorrow.

Discussion

2008-10-10T05:04:00.001-07:00

Complexity (New frontiers)

–Very hard problem (several levels)

–Requirements from several levels

•Platform Strategies (vs the usual Product Line)

–Architectural Styles (different levels, different contexts)

•Simulation at Different Stages (embedded systems)

–Change management

Complexity: Architecture vs Requirements

2008-10-10T05:02:00.000-07:00

•Themes:

–Architectural Sytles/ Organization Principles 2

–Architecture Control/Stability/Modularity 3

–Validation/Prototyping 2

–Consistency/Change Control/Sustainable/Granularity 2

Whom to hire: Requirements Engineers or Lawyers?

2008-04-27T05:41:00.000-07:00

I just learned about the Waste Management versus SAP lawsuit from a Chris Balavessov´s post. If you Google over the issue you will see that this topic did produce lots of reactions. Mine is one of them.

I strongly recommend everyone interest in Requirements Engineering to read the original petition in the civil case brought to the courts of Texas. It is an amazing document.

It is incredible how industry still make the same mistakes over and over again. More than 10 years ago the audit report on the London Ambulance System (LAS) was made public. Several researchers, including myself, did study that amazing report. The LAS report made clear the need for requirements engineering.

Waste Management is suing one of the largest software vendors because the software it was expecting to work in a promised date did not work even more than one year late. The lawyers, in the petition, decided to follow an argument of fraud, saying that the software vendor deceived the client. If you read the petition, it seems that the lawyers do have a strong case, but this is just one side of the story.

At same point the document says: "but instead merely a fabricated "mock-up" of the actual software." and "was demonstrating fake software at the Palo Alto meeting". These two fragments are there to convince the courts that SAP was acting perpetrating fraud. However, one could argue that a “mock-up” is just what is necessary for helping customers to clarify what they want, and is a good practice in early validation. It is interesting that using the lawyers’ argument a prototype may be named “fake software”.

ERP systems have been discussed widely over the trade press and by scientific research as well (see here and here). SAP is a huge success because businesses need that type of solution. However, what seems to be forgotten is that even when buying a COTS system (an ERP is a big COTS), you do need the expertise of requirements engineers.

It may be that the plaintiff supposed that buying an ERP was possible without a proper elicitation and analysis of possibilities. If that was the case, the plaintiff was too naïve, but, as we have seen in the LAS case, this does happen.

In any case, this civil action may work as one more evidence of why we need software transparency.

Brainstorming

2008-03-31T11:07:00.000-07:00

When teaching about requirements elicitation, I do speak of brainstorming as one of the ways of conducting a meeting. Meetings are one of the key techniques for conducting requirements elicitation.

I have recently conducted a web survey on brainstorm and found some interesting posts. I am sharing what I have found:

An article at the The Heart of Innovation.
A trade press article that is easy to ready.
Donald Clark introduction to the topic.
A vendor description of the technique.
Last, but not least: a chapter of a book where you can find a real example of the use of brainstorming. Of the notes cited above, this one is the only one that describes how brainstorming did solve a real problem.

Need for Transparency

2008-03-24T09:42:00.000-07:00

Professor Ricardo Reis posted a note, in the Brazilian Computer Society e-mail list, regarding the issue of citation counting. He cited the paper "Show me the Data" published by the Journal of Cell Biology, as a must read for those interested in the politics of research dissemination.

The article, "Show me the data", is an excellent example of the clamor for transparency.

As I have being saying: software transparency is a key issue for society.

I gave a talk at the IFIP 2.9 addressing this issue. It already shows progress on our research on software transparency.

Words of Wisdom

2008-01-28T05:02:00.000-08:00

I have recently watched the movie Bobby by Emilio Esteves.

Looking at youtube I have found the last five minutes
of the movie, where the
Robert Kennedy speech of April, 5th, 1968 can be heard.

They are words of wisdom, but without enough listeners.

I do quote here some of those words.

Yet we seemingly tolerate a rising level of violence that ignores our common humanity and our claims to civilization alike. We calmly accept newspaper reports of civilian slaughter in far-off lands. We glorify killing on movie and television screens and call it entertainment. We make it easy for men of all shades of sanity to acquire whatever weapons and ammunition they desire.

For there is another kind of violence, slower but just as deadly destructive as the shot or the bomb in the night. This is the violence of institutions; indifference and inaction and slow decay. This is the violence that afflicts the poor, that poisons relations between men because their skin has different colors. This is the slow destruction of a child by hunger, and schools without books and homes without heat in the winter.

I have not come here to propose a set of specific remedies nor is there a single set. For a broad and adequate outline we know what must be done. When you teach a man to hate and fear his brother, when you teach that he is a lesser man because of his color or his beliefs or the policies he pursues, when you teach that those who differ from you threaten your freedom or your job or your family, then you also learn to confront others not as fellow citizens but as enemies, to be met not with cooperation but with conquest; to be subjugated and mastered.

Our lives on this planet are too short and the work to be done too great to let this spirit flourish any longer in our land. Of course we cannot vanquish it with a program, nor with a resolution.

But we can perhaps remember, if only for a time, that those who live with us are our brothers, that they share with us the same short moment of life; that they seek, as do we, nothing but the chance to live out their lives in purpose and in happiness, winning what satisfaction and fulfillment they can.

Surely, this bond of common faith, this bond of common goal, can begin to teach us something. Surely, we can learn, at least, to look at those around us as fellow men, and surely we can begin to work a little harder to bind up the wounds among us and to become in our own hearts brothers and countrymen once again.

Robert F Kennedy
On the Mindless Menace of Violence
City Club of Cleveland, Cleveland, Ohio
April 5, 1968

The Magical Number

2007-08-21T13:11:00.000-07:00

I was introduced to the concept of the magical number back in the late 70´s. I heard about it in classes, but only in the XXI century I had the chance of reading the paper.

The idea of this magic number has been used in several areas. I read books in software engineering using the concept to deal with decomposition of modules and in business using the concept to talk about the scope of responsibility for a given manager. In both applications of the concept, the idea is straightforward: avoid the complexity of interactions among parts of a given set. The justification was based on the magical number.

In my work on the usage of natural language in requirements, with the LEL (Language Extended Lexicon) and with Ontology, I became aware of Wordnet, and have been using its on-line version as an on-line dictionary. It helps me a lot, since English is not my native language.

I recently became a user of AdSense for a blog of mine, in Portuguese, that publishes notes on Information Systems.

What all those things do have in common? The answer is Professor George A. Miller.

More amazing yet, is finding out that Professor Peter Naur, in his 2005 Turing Award recipient speech, says the following:

“Communications of the ACM, November 1995, brought an article by the psychologist G. A. Miller: WordNet: A Lexical Database for English, describing a so far unsuccessful project to develop a computer program that supposedly processes natural languages as people do. Miller describes language in terms of words, word senses, and linguistic contexts. By this manner of describing the linguistic activity he gets stuck.”

Is text-mining a good way to elicit requirements?

2006-11-30T10:24:00.000-08:00

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

2006-11-27T04:13:00.000-08:00

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

2006-11-27T02:33:00.000-08:00

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

2006-11-10T12:43:00.000-08:00

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

2006-10-24T14:42:00.000-07:00

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

2006-08-30T04:42:00.000-07:00

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

2006-08-09T10:00:00.000-07:00

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

2006-08-08T03:16:00.000-07:00

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

2006-07-30T12:30:00.000-07:00

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

2006-07-19T03:48:00.000-07:00

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

A company that registered the term transparency software as a trade mark. They sell database reverse engineering tools.
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.
Reflective is a company that sells software testing technology, it uses the term in a restricted way, for the consuption of software developers.
Eric Sink reporting on the concept of transparency at Microsoft. It is not a conincidence that it comes from the Visual Studio group.
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.
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

2006-07-17T02:49:00.000-07:00

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

2006-07-06T06:35:00.000-07:00

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?

2006-05-21T11:35:00.000-07:00

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?

2006-05-03T03:38:00.000-07:00

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?

2006-04-01T02:07:00.000-08:00

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?

2006-03-23T02:35:00.000-08:00

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?

2006-03-08T09:42:00.000-08:00

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

2006-02-28T15:22:00.000-08:00

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

2006-02-25T06:20:00.000-08:00

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

2006-02-21T03:00:00.000-08:00

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.