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. 

Open Plan School..

The visit to Albany Senior High School the other day was quite stimulating. It was good to hear things happening. However, it could have been better if the trip was possible when the 'action' was still on (It was quiet during our visit; it's the exam time, isn't it?) More questions keep emerging after the actual trip.

A search to see if this was the first of its kind, Google gave me a few thousand hits and discussion of issues. One such was the discussion on hearing difficulty tied to the accoustics of these new schools. Portugal came with the idea of the OPen Plan School much earler and there is a lot of discussion going on as to the success or failure of these 'innovations'. Someone calls it 'old wine in a new bottle'. In some other discussion these new schools were compared to post World War schools where the need for such school was driven by country's economic conditions. Sokmeone else called it 'Lurching from Fad to Fad' and the article argued that it wouldn't work in an elementary level. It in fact created pandemoneum apparently. It wasn’t long before distraught teachers appeared in droves at principals’ doors pleading for walls or partitions to deaden the sound, lessen the confusion and lower the stress level of teaching young children in this mass of humanity.

Another article discusses the variety of activities that could happen in an open learning space: a girl is curled up with a book in one corner; in another corner a small group of boys concentrate on the brief outline of the day's science project that the teacher is chalking up on a portable board; a dozen children sit in carrles, earphones in place, listening to the recordings of their lessons they missed; in the centre of the space, six boys and girls work round a table discussing the newspaper clippings and so on.

The heterogenity in the tools used, platforms used, software used, learning styles, units of learning, learning intentions - how does it work that they 'pass' or 'fail' a course and an industry can view all these results with some uniformity.

a creative vision...

It is not the technology that inspires or even transforms education - it is the teacher. Someone explained it this way: using a chisel or a paintbrush is not in itself inspirational or transformational. It is the skilled hands of the sculptor or the painter that changes a lump of stone or a bare wall into the work of art. Similarly, computers, social media, any web tools we get our hands on, can only be used in this way if the practitioner has a creative vision. The video of 'Hole in the Wall' we watched in the class the other day reinforced this thought in me much more.

The need to repurpose education in the face of a changing world offers those working with technologies to support and enhance learning a range of opportunities previously unknown. The range of technologies is bewildering with social and mobile technologies, personal web-based tools and corporate systems all having things to offer. However who chooses the systems in any given context is also changing fast, with agendas like life-long learning and work-based learning introducing ever more stakeholders into the learning experience, and individuals being increasingly able to "opt-out" of using institutional systems.
How will institutions cope with this "new world" where not everything is under the control of the institution and increasingly both staff and students can "do their own thing"? A conflict of control between the individual and the institutional is growing, and the danger of innovation being stifled by the drive for "School regulations" is very real. The answer will be found in policies - but what policies are needed and who will frame them?
Reference:
Hole in the Wall (Full Report from TED): http://www.ted.com/talks/sugata_mitra_shows_how_kids_teach_themselves.html