Thoughts on Software Engineering Ph.D. Research

I would say that there are 3 main characteristics for a successful Ph.D. in Software Engineering:

• It should be guided by Ethics
• It should be anchored on shoulders of giants, but digging deeper
• Be visionary, be bold

A must:

A software researcher must understand that software evolves, as it is been built, by a social process for a social purpose

Some other observations:

• Industry is a lighthouse, but auxiliary
• The researcher should be ethical in bringing new knowledge to society
• Keep in mind Aristotle’s beginning, middle, end
• Satisfice Transparency (aim to make your work transparent)
• Data is dear, ideas are good, code is king
• Useful OR Insightful?  The difficult challenge of producing valid work that is novel or/and of interest.  This is particular important when dealing with industry related projects.

From the point of view of the advisor:

• Tell the researcher that to succeed there must be a passion for the topic
• Tell the researcher that it is hers/his work
• Guide towards ethics, shoulders and vision

Requirements Elicitation

In the requirements literature there is a lot of confusion about termininology, which is perfectly fine, since this is a young discipline.  In addition, requirements engineering has been approached from different perspectives and viewpoints.

One point that brings different terminology and discussion is about Requirements Elicitation.

I believe that Requirements Elicitaton may be performed by three main strategies: 

1.  model-driven elicitation (where the elicitors gather what the syntax of the modeling language demands), 
2. uncompromised elicitation (where the elicitors gather information from the Universe of Discourse, without any predefined standard/language), and 
3. a mix of the two.

Another aspect that it is also confusing is: what is to be elicited.  Some authors make a distinction among requirements and domain. However, some  mix the idea of domain (a general knowledge that applies to several instances) to context information (knowledge specific to a given environment of a domain).

Although the term requirements have been a placeholder for different semantics, I opt for understanding that a  requirement is a sentence with a unique identifier. 

I gave a keynote talk at Istar'15 that tackles part of the issue: Elicitation Awareness in Conceptual Modeling: The Role of Transparency.

Below I list a series of papers that tackles the issue of Elicitation:

1. Proceedings of the Seventh International Workshop on Computer-Aided Software Engeneering, IEEE Computer Society Press, pp. 260-269, (1995), FAES: A CASE Tool for Information Acquisition. Gilvaz, A.P., Leite, J.C.S.P.
2. WER 2007 p. 25-34 (2007) A Strategy for Information Source Identification. Leite, J.C.S.P., Moraes, E.A., Castro, E.P.S. 
3. Proceedings of the 29th Annual ACM Symposium on Applied Computing (SAC '14) p. 1001-1006 (2014) Eliciting concepts from the Brazilian access law using a combined approach. Engiel, P, Cappelli, C., Leite, J.C.S.P. 
4. Requirements Engineering, 2015, V. 20, I. 2 p. 139-161 (2015), Early identification of crosscutting concerns with the Language Extended Lexicon.  Antonelli, L., Rossi, G., Leite, J.C.S.P., Araújo, J.

Why do I like the means-end relationship in istar (i*)?

In the picture below there is a light comparision among different modeling languages for representing the idea that a customer has to be registered by a software system.

The Case of Healthcare.gov

Last Sunday, returning from the great 3rd Global Conference on Transparency Research held at HEC, Paris, I heard for the first time about  the Healthcare.gov case.

I was reading  the French newspaper JDD, when a news story caught my attention:
"De l'autre, Cheryl Campbell, dont la société CGI Federal a reçu près de 200 millions de
dollars (145 millions d'euros) pour développer et veiller au bon
fonctionnement du site. "Nous n'avons pas bénéficié d'assez de temps
pour tester le site, a-t-elle accusé. Seulement deux semaines.""

http://www.lejdd.fr/International/USA/Obamacare-tourne-t-il-au-fiasco-635832

I did laugh.

After the trip I went on to look at Slate; and look what it says: "Everyone at the
hearing, contractors and representatives alike, seemed ignorant of what
is demanded by this sort of testing, with the exception of Jerry
McNerney, D-Calif., a mathematics Ph.D. and ex-programmer. He asked
about such specifications for integrations. Campbell said, “There were
use-cases and things of that sort,” evidently unfamiliar with what
specifications are (hint: not use-cases). Slavitt said, “We believe we
received appropriate specifications.”"

http://www.slate.com/articles/technology/bitwise/2013/10/healthcare_gov_problems_house_committee_hearing_is_a_spectacle_of_tech_illiteracy.2.html

No comments.

But there is more: "On his Friday call, Zients differentiated between
healthcare.gov’s “scale” issues and its “functionality” issues. I
believe this marks the first time that the administration has admitted
that healthcare.gov’s problems went far beyond the site being
overloaded. Zients said that account creation had now been fixed, with
more than 90 percent of users now able to create accounts. But only 30
percent have been able to complete an actual insurance application. And
that’s not even to say that the application is correct, owing to reports
of children getting listed as multiple spouses and the like."

http://www.slate.com/articles/technology/bitwise/2013/10/healthcare_gov_tech_surge_the_uninsured_are_now_unpaid_alpha_testers_for.html

I will comment about these paragraphs, soon.  They are good examples of the lack of proper Requirements Engineering.

Toyota Software

Here is what the LAT says:

“Investigations by the National Highway Traffic Safety Administration, NASA and the National Academy of Sciences found no flaws in the automaker's electronics that could provoke the problem.  

But many vehicle owners continue to claim that a software or wiring bug could be the root of the problem. In preparation for trial, attorneys have been examining the source code for Toyota's throttle management system and consulting with engineers and electronics and software experts.”

Toyota to pay big to settle suits
By Ken Bensinger and Ralph Vartabedian,
Los Angeles Times December 26, 2012, 6:06 p.m.

On the other hand, the NYT says:

“But the class-action case contended that Toyota’s electronics systems were at fault. After a long investigation, government officials concluded last year that there was no evidence that faulty electronics systems contributed to the acceleration issues. But a subsequent review of that inquiry by a branch of the National Academy of Sciences found that federal regulators had lacked the expertise to monitor electronic controls in automobiles.”

Toyota Agrees to Settle Lawsuit Tied to Accelerations
By BILL VLASIC Published: December 26, 2012

The LAT mentions software but fails to say that there was a subsequent review, on the other hand the NYT talks about electronics systems, without referring to software at all.

So, was the problem a software one?

Parnas on Requirements Engineering

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

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

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

Amazing. Read it

Cobol as an Obstacle for the Terminator

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

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

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

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

Requirements Engineering´s Roots

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

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

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

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

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

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

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.