One of my colleagues was asking me the other day "does software decay over time?". He asked me this question because I am a Computer Scientist but to be honest I didn't know how to answer this. To me the answer can be both yes and no, but to further investigate this I turned to the ACM DL. I found a very interesting paper published in 1994 at the 16th international conference on Software engineering. The author says "Programs, like people, get old", but was this convincing as being a scientists means you look for how? why? what? in which sense? and does this depend on the hardware? If you are also interested in these questions, then this paper provides an interesting discussion about the topic. Reading this paper also made me think "does accessibility software decay faster or slower over time compared to other kinds of software?"

Software aging

"Programs, like people, get old. We can't prevent aging, but we can understand its causes, take steps to limits its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable. A sign that the Software Engineering profession has matured will be that we lose our preoccupation with the first release and focus on the long term health of our products. Researchers and practitioners must change their perception of the problems of software development. Only then will Software Engineering deserve to be called Engineering."

Full Paper: Software aging
Full Proceedings: Proceedings of the 16th international conference on Software engineering, Italy, 1994.

Labels: aging, software, Software engineering

This month I would like to talk about a paper published on a topic which I personally don't know a great deal about: aspect-oriented software design and development. To some of you this might not be a left-field topic, but unfortunately it is to me. This year at the International Conference on Software Engineering, a workshop was held about aspect-oriented requirements engineering and architecture design. I found a paper presented in this workshop that talks about how tagging can be used to identify and organise concerns during pre-requirements analysis. I thought that this was really related to accessibility. For example, how can we use tagging to highlight accessibility issues at the requirements gathering stage of software design? Would this be useful? Would it be a way to explain to people what kind of accessibility issues can potentially occur based on the requirements?, etc.

Using tagging to identify and organize concerns during pre-requirements analysis

Before requirements analysis takes place in a business context, business analysis is usually performed. Important concerns emerge during this analysis that need to be captured and communicated to requirements engineers. In this paper, we take the position that tagging is a promising approach for identifying and organizing these concerns. The fact that tags can be attached freely to entities, often with multiple tags attached to the same entity and the same tag attached to multiple entities, leads to multi-dimensional structures that are suitable for representing crosscutting concerns and exploring their relationships. The resulting tag structures can be hardened into classifications that capture and communicate important concerns.

Full Paper: http://dx.doi.org/10.1109/EA.2009.5071580
Full Proceedings: International Conference on Software Engineering, Proceedings of the 2009 ICSE Workshop on Aspect-Oriented Requirements Engineering and Architecture Design, 25-30, 2009.

Labels: aspect-oriented, Software engineering, tagging

This month I have two left-field articles to discuss. One is a very technical paper and the other is from an ACM Web-based publication called Ubiquity. The first article introduces a technique to derive a GUI model for automated testing. It is a very well written paper published in the highly influential ACM Transactions on Software Engineering and Methodologies. As the authors highlighted in the synopsis, this article "attempts to systematically generate potentially problematic sequences by empirically understanding event sequences that lead lead to successful fault detection". After I read this article, I wondered if the authors had considered disabled users and what would have been the generated problematic sequences? Would they be different? Would they identify more problematic sequences?

The second article, entitled as titled as "Why Does Time Go Faster As We Get Older?", is not as technically rich as the first article. I have been thinking about this question for a while and I thought other SIGACCESS members might also feel the same way and would be interested to read this short note.

Using a pilot study to derive a GUI model for automated testing

Graphical user interfaces (GUIs) are one of the most commonly used parts of today's software. Despite their ubiquity, testing GUIs for functional correctness remains an understudied area. A typical GUI gives many degrees of freedom to an end-user, leading to an enormous input event interaction space that needs to be tested. GUI test designers generate and execute test cases (modeled as sequences of user events) to traverse its parts; targeting a subspace in order to maximize fault detection is a nontrivial task. In this vein, in previous work, we used informal GUI code examination and personal intuition to develop an event-interaction graph (EIG). In this article we empirically derive the EIG model via a pilot study, and the resulting EIG validates our intuition used in previous work; the empirical derivation process also allows for model evolution as our understanding of GUI faults improves. Results of the pilot study show that events interact in complex ways; a GUI's response to an event may vary depending on the context established by preceding events and their execution order. The EIG model helps testers to understand the nature of interactions between GUI events when executed in test cases and why certain events detect faults, so that they can better traverse the event space. New test adequacy criteria are defined for the EIG; new algorithms use these criteria and EIG to systematically generate test cases that are shown to be effective on four fielded open-source applications.

Full Paper: http://doi.acm.org/10.1145/1416563.1416567
Full Proceedings: ACM Transactions on Software Engineering and Methodology (TOSEM), Volume 18, Issue 2, 2008.
Why Does Time Go Faster As We Get Older?

...Finally, I decided to sit quietly and ponder the matter myself. This turned about to be a wise decision, because I think I found the solution. It's really quite simple. It all has to do with "anticipation" and "retrospection"...

Full Proceedings: Volume 9, Issue 39 (October 28 - November 3, 2008).

Labels: automated testing, Software engineering, ubiquity