We shall touch upon four issues of software engineering (SE): domain engineering, formal techniques, SE sociology, and academic software architects. First, before software can be designed one must understand its requirements; but before requirements can be formulated one must understand the domain. So we assume that requirements development is based on first having established models of the (application) domain. We illustrate facets of the railway domain. Second, we touch upon all of the three phases: domain engineering, requirements engineering and software design also being done formally, however "lite". Third, despite 35 years of formal methods, the SE industry, maturity-wise still lags far behind that of other engineering disciplines. So we examine why. Finally, in several areas, in health care, in architecture, and others, we see that major undertakings are primarily spearheaded by senior academic staff. Professors of medicine daily perform specialized surgery and treatments at hospitals. Professors of architecture design new, daring buildings for industry, and professors of civil engineering head the engineering structural design of new, daring bridges. So we speculate what a similar approach would entail for SE. The paper is provocative, it postulates, but most claims are not (but can and will be) substantiated.
|Title of host publication||SEEM2005, 3rd IEEE Intl. Conference on Software Engineering and Formal Methods|
|Publication status||Published - 2005|
|Event||Third IEEE International Conference on Software Engineering and Formal Methods - Koblenz, Germany|
Duration: 7 Sept 2005 → 9 Sept 2005
Conference number: 3
|Conference||Third IEEE International Conference on Software Engineering and Formal Methods|
|Period||07/09/2005 → 09/09/2005|