Week 1 - Software in the Information Society - Summary and Review

Section 1 - Problems with Software

The approach of this section seems to boil down towards a one line statement:
The application of software has not led to the expected benefits promised from said software.
This rather sweeping statement was born out of economic analysis - investment vs. return on investment was not matching up in the way expected (Thomas Landauer, 1995). Industrialisation of production, and the mechanisation and streamlining of many processes and business practices had increased the GNP, of many countries, including the US and Japan. This growth was manifest up to approximately 1970, when a noticeable dip occured.
The phenonemnon was aptly summarised by another researcher, Castells in the following quote:

Even if we account for the specificity of some countries, what appears clealry is that we observe a downward trend of productivity growth starting roughly around the same time that the Informatiion Technology Revolution took shape in the early 1970's (Castells, 1996, p.71)

A case study is given to highlight the issue - the Therac radiation treatment disaster (Leveson + turner, 1993)
The background to this story seems to hinge on the following:

1. The engineers who created the system for these previously exclusively hardware controlled machines, were electrical engineers - the implication here is that they did not possess either the necessary skillset or mindset to work in a software engineering framework
2. Safety controls that had previously been only available through the hardware were now manipulable through the medium of the command line - safety checks and lockouts were not considered fully, giving rise to the following situations:

• Parameters that could be changed on the system, the on the user interface, could still be altered in the machine, giving rise to a condition where the parameters on screen were not the ones in use - a patient in for a minor dose of radiation could in theory (and in reality) receive a much stronger, lethal dose.
• System counter - a counter was implemented to keep track of how many times the machine had been used; unfortunately the machine could only count to 256, so on the 257th pass it would revert to 0, which also happened to be the engineers override facility - all safety locks would be disengaged, and the patient would receive a massive dose.

What the previous statements and examples seem to be telling us is that there were two main factors at work:

1. The necessary framework for developing stable and (relatively) bug free code, was not yet in place.
2. A shift to utilise software as a fully integrated part of the business system had not yet materialised - it was still in use as something of a crutch, or aid, rather than an essential and integral part of the process.

This is backed up by the next section, where software became more prevalent as a business essential.


Section 2 - Ubiquity of Software

Case Study 1.2: Payroll systems

The case study provided in this case revolves around the prevalence of payroll clerks in the 50's and 60's, and the replacing of same by new calculating machines. Punch card systems were developed to automate tasks, and from such beginnings there arose systems and software specifically developed for payrole and various human resource problems. This, due to not all companies being wealthy enough to afford their own systems, led to the advent of computer bureaus - companies which placed themselves in such a way so as to offer their service (based solely on the development of standardised, and then more specialised, payroll software) to companies who did not have their own systems. Payroll clerks began to disappear, being replaced by software systems built to do the same.

The material goes on to mention how most people would hardly be aware whether their salary is handled by computer or clerk, but I would dispute this - with the penetration into society, and especially into business, I would be very suprised if there were more than 1 in 5 who believed there was a person at the end of the wage chain.

Case Study 1.3: Distance Education

Distance Education in its current form grew out of the much older practice of correspondence courses, i.e. mail based. The demand emerged out of a growth in the number of people who could now access higher level education, but could not do so in the traditional manner.
The success of the system is attributed to two things:

1. The available of quality material published and reviewed by academics
2. support - in the form of a tutor, to provide help and insight into course material

The internet (currently one of the single greatest tools for the purpose of education) was employed as an information exchange medium in the early 90's. the opportunity was given to not only enhance, but to redesign the way that courses, etc. were structured. An important consideration in the use of computers - compatability. Platform had to be considered, plus factors like the lowest common denominator, i.e. any software provided not only had to be compatable with a student's computer, it had to be light enough on resources to run on older systems too.


Case Study 1.4: The Insurance Industry

The evolution theme is continued in case study 1.4, the case here being Royal Insurance, founded in 1845. The basis of the case given here is that of the mergers. Over the lifetime of the company there were several changes: its sister bank was taken over, and over again, controlling shifting numerous times. A merger between both bank and insurer was at one point put about, but it was believed that the Bank of England would not take kindly to such a merger. Changes in the way services could be offered meant that there could now be a shift in the way insurance was dealt with as a whole - the model could change: see the case of Direct Line for an example...

With mergers continuing around the country and throughout Europe, the idea of software system merging also needed to arise - for example, the Royal Insurance and Sun Alliance merge in 1996 meant two disparate systems in use - consolidation of these systems was needed.


Basically what this section tell us is that not only will software continue to evolve after first procurement, there will also come times when a choice of one over another of two (or more) production systems - change is inevitable and natural. With this comes the issues of globalisation and localisation, a mounting challenge in today's multi-national business world.



Section 1.4 Rationality and Limitations

What we need now are techniques for managers and other innovators to apply to the design and deployment of computer applications that will ensure they they [computers] fulfill their promise. They are available. I've called them user-centred methods.
Landauer (1995, p. 193)

The entirety of this section is based around the concept that engineering, and software in particular, can be developed by the application of rational thoughts and process. This theory follows on from the Enlightenment Project, involving the natural philosophers of the day such as Newton and Leibniz. This theory now lives on known as modernism, and can apparently be seen most prominently in architecture.


Case Study 1.5: From modernism to postmodernism in architecture

This case study deals with the falling off of the modernism approach in architecture and the taking up of postmodernism - basically, applying a human intuitive approach to the process when the rational has come up short. Reducitonism, being the scientific approach of breaking down w problem into its constituent parts, and building it back up from the base, is commonly applied to software problems. What the example here appears to be trying to tell us is that the you can break down a problem , rebuild it, and attempt to solve with rational processes, but it can still not be enough. A human perspective is often required, giving rise to the postmodernism tag.


Section 1.5: Uncertainty and Change in the software world

Part 1 of the course: Social and Organisational Context in which software is used - how the software will be used, what factors will need to be taken into account to cover for the changing software landscape, and how to evolve with your software.

Part 2: Focus on the software and the process of acquiring same. Involves acquiring(commercial, free, bespoke, etc..), developing, and maintaining.

Part 3: Management process involed in making Part 2 work - managing the entire process, deployment, staff training, etc...


Section 1.6: Summary

1. Software has not fully delivered on the promise to make life easier. Largely due to the way it is used, obtained, developed and deployed.
2. Badly written/understood software can fail disastrously.
3. Software is impotrant for the automation of business tasks and processes - when used correctly provides a substantial increase in productivity.
4. Software offers new opportunities to deliver services, and thereby ehance profits and market share.
5. Rate of change in the market place has increased with the advent of computer systems in general and software in particular - these changes must be planned and provided for.
6. A good process will involve a solid rational/scientific basis, plus a human perspective to put the final polish on.
   

First Post

This blog will be used to track my course progress through the Open University MSc in Software Development (F26). I am currently enrolled in a pre-requisite course, Managing the Software Enterprise (M882).

My intention in starting this blog is to give me the opportunity to use an online tool as a study aid. I will be journaling my study/review of the course material as and when I finish each section. I will be making the first post on the Course Guide and Chapter 1 of the course text within the week (as per course calendar guidelines).

If anyone reads this, and would like to comment on the assumptions/summaries I have drawn from the course text, please feel free. I'm also open to questions at any time, being a firm believer in the idea that the best way to test how well you have learned something is to try and explain it to someone else.

I'll be back soon with the first proper installment.