The Importance of Comprehension for Software Quality

The complete, accurate and concise documenting of requirements is of vital, perhaps paramount importance (Glass 1998) within software quality because errors made in this phase are often considered the most difficult to solve and most costly to fix (Bray 2002). Hence, the potential benefits of successful comprehension (Graesser et al. 1994) promise improvements in software quality, stakeholder satisfaction and development costs. However, comprehension is ‘a complex interaction of basic cognitive processes’ (Fletcher et al. 1996) which can be regarded as ‘one of the most complex and uniquely human of cognitive activities’ (Van Den Broek et al. 1996) and which are vital for developing computational thinking.

 

One area that offers a valid means of investigating comprehension is that of Discourse Process. Bamberg and Moissinac (2003) define discourse as ‘broadly taken to mean the use of language beyond that of a single sentence’. Discourse Process analyses the way in which sequences of sentences combine to produce coherent sections of language, and thus extends the traditional linguistic study of the construction of individual sentences (Crystal 1997; Graesser et al. 1997).

 

Requirements techniques aim to communicate sets of concepts and meanings which have been constructed, often within sizeable documents, to various stakeholders in a system. Moreover, they typically capture the interaction between an actor and the system in order to accomplish the actor’s goal across a number of statements (Cockburn 2001; Kulak and Guiney 2000). Therefore, discourse process is particularly relevant for the understanding, and improvement, of requirements.

 

References

1. Bray, I. K. (2002). An introduction to requirements engineering. Harlow: Addison-Wesley.
2. Cockburn, A. (2001). Writing effective use cases. London: Addison-Wesley.
3. Crystal, D. (1997). The Cambridge encyclopaedia of language. Cambridge: Cambridge University Press.
4. Fletcher, C. R., Van Den Broek, P., & Arthur, E. J. (1996). A model of narrative comprehension and recall. In B. K. Britton & A. C. Graesser (Eds.), Models of understanding text (pp. 141–163). Mahwah, NJ: Lawrence Erlbaum Associates.
5. Glass, R. (1998). Software runaways. Harlow: Prentice Hall.
6. Graesser, A. C., Singer, M., & Trabasso, T. (1994). Constructing inferences during narrative text comprehension. Psychological Review, 101(3), 371–395.
7. Kulak, D., & Guiney, E. (2000). Use cases: Requirements in context. London: ACM Press.
8. Van Den Broek, P., Risden, K., Fletcher, C. R., & Thurlow, R. (1996). A ‘‘landscape’’ view of reading: Fluctuating patterns of activation and the construction of a stable memory representation. In B. K. Britton & A. C. Graesser (Eds.), Models of understanding text (pp. 165–187). Mahwah, NJ:

Teaching Software Architectures

The traditional way to begin talking about something is to outline the history, broad principles, and the like. When someone does that at a conference, I get sleepy most of the times. My mind starts wandering with a low-priority background process that polls the speaker until he or she gives an example. The examples wake me up because it is with examples that I can see what is going on. With principles it is too easy to make generalizations, too hard to figure out how to apply things. An example helps make things clear.

So is with teaching and more so teaching IT. I wasted a Semester of sitting dumb in a class of Software Architecture where my teacher only talked about different architectures / models. I never figured out how architecting works in programming until I worked out the carefully crafted examples. Only ‘doing’– ‘not sitting in a class listening’ - that has finally given me a sense of the process of architectures and afterwards, the lecture slides.

Again what I mean by ‘carefully crafted’ examples? If I pick a large program, describing its architectural design can become too complicated for any student to work through. (I tried and even a slightly complicated example runs to more than a hundred pages.) However, if I pick a program that is small enough to be comprehensible, architecture does not look like it is worthwhile. Thus I favour a classic mix of describing techniques that are useful for real-world scenarios. 

Teaching Programming

Programming has been described by many authors as the new Latin of the school syllabus, a kind of mental whetstone for developing minds. As such, it was assumed that students would develop their general problem-solving skills through learning programming. However, reports from teachers of programming and results from some empirical studies now suggest that the teaching of programming has created significant difficulties even for university students, and has failed to catalyze the development of higher order thinking skills.

What has gone wrong? It is wise for teachers of IT to review  some of the challenges of both teaching and learning programming. The programmer's objective, for beginners and expert alike, is first to specify a detailed plan that can be carried out. That is, the programmer has to decompose the initial task. This is not trivial: Many people are quite unable to say how they perform certain tasks. For instance, many students in introductory programming classes are unable to explain how they are able to select the smallest of a series of integers. 

Next, the programmer must map this plan into the constructs of the target programming language. There are two points to be made about this mapping process.

1.      First, for the process to be "clean," the programmer needs to have a very clear idea of the abstract plan and of the constructs available in the programming language. One study of beginner programmers showed that many beginners had very fuzzy notions about a programming language—substantial misunderstandings had occurred with regard to virtually every construct in the language.

2.      Second, task decomposition and program coding are not as neatly decoupled as we might think. A simple example: If arrays are not available in the target programming language, then a plan that assumes this capability would be badly flawed. A thorough knowledge of the facilities provided by the programming language is needed even at the stage of formulating the task plan. 

Debugging a program is similarly complex and demands a variety of skills, including an ability to coordinate information derived from sources such as error messages, the program plan, the program specification, and the actual code.

There are some resources to help:

1.    John Anderson and Edward Skwarecki's "The Automated Tutoring of Introductory Computer Programming" demonstrates that intelligent computer-assisted instruction (ICAI) technology can be a more effective way of teaching introductory programming courses—for certain populations.

2.    Elliot Soloway's "Learning to Program = Learning to Construct Mechanisms and Explanations" challenges conventional wisdom by taking a fresh look at assumptions about the art of programming.

3.    Soloway advocates a more explicit approach to the teaching of problem-solving skills, which is based on the actual skills experienced programmers use in addressing real tasks.

4.    "Boxer: A Reconstructible Computational Medium," by Andrea A. diSessa and Harold Abelson, proposes a radically new kind of computational medium—one that would be highly tailorable, and able to accommodate a wide range of users, from a seven-year-old to an experienced nonprofessional.

Recent experiments have suggested that the domain knowledge of experienced programmers is organized in a radically different way from the domain knowledge of beginner programmers; analogous results have also been reported for chess and music. In all cases, experts use larger chunks of knowledge. An important instructional question is how to bring beginners up to the expert's level of domain knowledge. Aside from teaching details of the syntax and semantics of a particular programming language, it is necessary to explicitly and concurrently explain why and how programs work, the goal of any given program, what plan segments are, strategies for decomposing tasks, rules that well-formed programs adhere to, and design strategies. If followed, this approach would produce several radically different types of programming courses.