Sunday, May 13, 2007

Software Engineering Course Design

The media and other commentators are finally coming to grips with the fact that secondary science and mathematics education in Australian middle schools is failing to adequately prepare students for senior high school let alone university. Teachers and curriculum designers have watched dumbfounded as the system they participate in has continued to decline in quality under the combined pressures from adventurous educational administrators influenced by progressive reformers without much respect for the history of science and mathematics, the community they claim to serve, and little common sense.

An article in The Australian points out that middle school education in Queensland is pre-Newtonian insofar as middle school science is taught almost in an almost purely descriptive fashion absent the analytical approach founded by Newton, lacking the modern scientific approach of Bacon. Let alone Einstein's physics of the twentieth century with the generalisation of Maxwell's work unifying electromagnetism to the invariance of electromechanics in inertial and non-inertial frames. Advances in chemistry since Mendeleev codified the periodic table of the elements, the development of quantum mechanics being the foundational theory for chemistry and influencing every area of modern science.

From an engineering perspective many of the most important developments in control and communication systems, mathematics, information theory and computing occurred in the pre and post first and second world war periods. Developments in Bertrand Russell's codification of mathematics and Godel's counter theory on incompleteness, Shannon's information theory, the practical developments in mechanics and radio theory as a result of military advances in radar, ballistics, coding and code-breaking, Turing's work on computability and von Neumann giving us the essentials of our modern computer architectures.

The accreditation of university degrees is predicated on meeting a number of requirements including adequate coverage and rigour in course content. The measure in software engineering accreditation, the metric against which the technical content of such degrees are assessed is comparison against standardised bodies of knowledge, for instance, the Software Engineering Body of Knowledge (SWEBOK) - assessed against the SWEBOK Guide. Many professional areas of practice are assessed against standardised knowledge including accounting, law, medicine and we may even consider aviation pilot training and building trades like plumbing, carpentry and electrical trades.

The distinguishing feature for university degrees in science and engineering is the necessary emphasis on the foundational bases in mathematics and the sciences. The tension between these foundations and the practical knowledge bases is not replicated in any of the other fields. Competent engineering practitioners need to be educated in mathematics and relevant sciences in addition to being well versed in the necessary methods and practices associated with the body of knowledge for the profession.

Each area of engineering practice has its own knowledge base, customs and traditions. Clearly mechanical, civil and electrical engineering are significantly different in usual practice even if we recognise that each shares foundations in maths and physics, statics, dynamics, mechanics, thermodynamics, and so on. For instance, civil and structural engineers are interested in loadings on structures with some interest in mechanical elements that are of greater interest to mechanical engineers who utilise electrical instrumentation and power systems that may be of primary concern to electrical engineers - all related but distinct fields.

There is a close relationship between software and systems engineering. Both are involved with complexity of requirements, analytical rigour as far as is necessary, significant design and associated documentation. When one speaks of external interfaces as a facet of requirements alongside user interface, functional and nonfunctional requirements software and systems become interchangeable. Most nontrivial systems employ software components and most nontrivial software systems interact with non-software components. Where does one discipline begin and the other one end?

No comments: