Forum for Academic Software Engineering Volume 5, Number 21, Fri Sep 8 15:09:03 CDT 1995 Topics: Report on SEEW-4 at ICSE-17, April 1995 A------------------------------------------------------- From: Pete Mellor Subject: Report on SEEW-4 at ICSE-17, April 1995 Dear All, Please find appended (at last!) the report on the Software Engineering Education Workshop in Seattle in April. I am sorry to have kept you waiting so long for this. If you detect any mistakes, and in particular, if there are any significant omissions, please let me know, and I will correct and reissue the report. The report is in Latex format. If this causes a problem, please tell me, as I can very easily create a plain ASCII text version, send the corresponding postcript file, or post a hard copy. I hope I have got everyone's e-mail address correct. (In some cases I am not sure if I have managed to decipher the hand-written addresses on the list of attendees!) Regards, Peter Mellor, Centre for Software Reliability, City University, Northampton Square, London EC1V 0HB Tel: +44 (171) 477-8422, Fax.: +44 (171) 477-8585, E-mail (JANET): p.mellor@csr.city.ac.uk -----------------------Cut Here------------------------------ % Report on Software Engineering Education workshop, Seattle, 29th April 1995. % % Pete Mellor, CSR, 15.08.95 %------------------------------------------------------------------------------ - \documentstyle[a4wide]{article} \title{Report\\ SOFTWARE ENGINEERING EDUCATION WORKSHOP\\ ICSE-17, Seattle, 29th April 1995} \author{Peter Mellor} \date{15th August 1995} \begin{document} \maketitle \section{Introduction} The Software Engineering Education Workshop was one of the parallel sessions on the final day of ICSE-17 (17th International Conference on Software Engineering) at the Westin Hotel, Seattle, WA. It was organised by John Jenkins, Head of Business Computing Systems Department, City University, London, England, and was attended by 23 delegates from the USA, Canada, Australia, Japan, Hong-Kong, Spain, Germany, and the UK, most of whom submitted position papers for the workshop pack. John began by welcoming the delegates, and deploring the tendency of international conferences to become institutionalised, so that even small workshops like SEEW were automatically assumed to be annual events, with SEEW-3 due next year. Nevertheless, an SEEW is planned for ICSE-18. He then introduced the invited speakers who were to lead the discussions: Nancy Mead, June Verner, and Ross Jeffery. Although the emphasis was intended to be on postgraduate education, many of the position papers concerned undergraduate programmes, which, John said, was not necessarily a bad thing. (This was a relief to this rapporteur, whose own position paper was about undergraduate group projects!) \section{University Industrial Partnerships} Nancy Mead (Software Engineering Institute, Carnegie Mellon University) gave a short presentation on recent experiences of collaboration between universities and industry in the area of software engineering. She personified ``industry'' as someone holding an armful of dollars and saying ``I want programmers with C++ and UNIX!'', and academia as a magician waving a wand and saying ``Give me a grant and I will work wonders!'' The problem is the mismatch between the requirements of these two groups. Industry wants training in software engineering with the emphasis on practice and engineering. Academia wants to provide education in computer science with the emphasis on theory and science. (The difference between science and engineering cropped up again in the final panel discussion.) The main questions Nancy posed were ``Where are we now?'', ``Where are we going?'' and ``How do we get there?''. (It was noted in passing that only three of those around the table could count as ``industrial''.) Several other delegates shared their experiences of such collaborations. The discussion centred on the ways in which collaborative efforts between industry and academia are started, ideas for controlling them, and problems that can arise, as follows:- \begin{enumerate} \item Started by:-- \begin{enumerate} \item State initiative, e.g., The State of Oregon's initiative to set up ``Silicon Forest'' in conjunction with the University of Oregon. (Judy Bamberger) \item Industrial pressure, e.g., the Consortium for Graduate Education in Software Engineering (CONGESE), described by David Wortman (University of Toronto), in which industrial firms' requirement for a degree in software engineering led to six universities collaborating to design a cooperative degree programme at the provincial level in Ontario, with the courses taught by industrial people. \item Key individuals/grassroots: less formal collaborations can arise from lower level contacts between industrial workers and academics. \end{enumerate} \item Driving ideas:-- \begin{enumerate} \item Industrial Advisory Boards (IABs). June Verner (City University, Hong Kong) gave as an example the government funded Master's programme which is run with the assistance of an IAB. In fact, most people around the table who were involved in similar programmes made use of an IAB, and this are important in reconciling the real needs of industry with the academics' initial assumptions about what is needed. The IAB in HK is regarded as being sufficiently important that it does not consist solely of industrial people whose time is expendable to their companies! However Raymond Offen (Macquarie University and CSIRO) remarked that in Australia, theoreticians could not cope with IABs since they would not prostitute themselves to people who make money! The presence of alumni on IABs was considered useful. \item Students' Companies. The involvement of the companies who are the ``customers'' for the course and sponsor their employees' studies is essential in any ``needs analysis''. \item Different degree programmes. There is a need to tailor programmes to specific customer's requirements, to distinguish between Computer Science and Software Engineering programmes, and to have accredited SE programmes. Karl Reed (La Trobe University) remarked that in Australia it is illegal to call oneself a ``software engineer''! . \item Industry ``institute'' membership by academics is valuable in many situations. \end{enumerate} \item Problems:-- \begin{enumerate} \item Getting real projects.\\ Several useful points about this were raised. There are important distinctions between projects carried out by individual students and group projects, and between real industrial projects and carefully selected projects to illustrate specific points. Both real projects and selected projects are used in Australia (Karl Reed). Real projects are sometimes done by final year undergraduates in City University, London, particularly where students have spent the previous year in industrial training and the work they were doing provides a suitable topic (Peter Mellor). Raymond Offen emphasised the need to bring in individual student projects from industry. In other places, the third year is totally devoted to a group project (Dan Hoffman, University of Victoria), and local industry is touted for real projects which have to be non-critical, and subject to a ``non-sue'' agreement. Some Australian Universities (e.g., Griffith) adopt a similar approach. It is essential to teach human factors in connection with group projects. \item Student background.\\ By the time students do a mid-career masters degree, their knowledge is around 15 years out of date, and undergraduate level revision is necessary. Also, time needs to be spent on management (Nancy Mead). A studio project does not constitute a master's thesis. Fred Mowle (Purdue University, Indiana) had found that work experience in software engineering was not being properly measured. David Umphress (Seattle University) said that their professional master's degree programme (100 enrolled) had a prerequisite of 2 years experience in software engineering. Elena Schultz stated that Nova Southeastern University's programme was aimed at experienced students, but the experience did not necessarily have to be in that area. It was necessary to make a judgement on the basis of resum\'es, portfolios of experience, etc. The requirements for Computer Science and Software Engineering programmes are different. \item Industry/university tensions\\ Several of the problems that arise between industry and academia are connected with projects. There is the problem of confidentiality where real projects are concerned, e.g., hiding the existence of a software reuse programme within the firm (Nancy Mead). Also, some firms tend to resent students returning after the degree programme with bright new ideas about the development process and ``rocking the boat'', although there are some positive examples where the infusion of new ideas has been useful and welcomed by the company. Also, in order to break specific ingrained habits of work gained in industry, student projects would need to be more prescriptive regarding the development process (Nancy Mead). Other problems arise from the different expectations of industry and academia, mentioned above. \end{enumerate} \end{enumerate} The session ended with a brief discussion on the distribution of ideas. Use of the WorldWide Web was one suggestion, and of course the FASE newsletter is already flourishing. \section{Management Education for Software Engineers} This discussion was led by June Verner, who began by describing the master's degree programme at City University, Hong Kong, which currently offers 60 places (against 900 applicants!) per year. This is effectively an ``MBA in Software Engineering'' and is run by the business faculty. The IAB had clearly expressed a wish that the degree programme should stay there (otherwise the University administration would have moved it, arguing that a degree related to software should be in a technical faculty). The programme is funded by government money. The IAB, which sets the requirements for the programme, includes some very important people. The problems that had to be addressed were ``What kind of management education should the programme offer?'' and ``What kind of technical education?''. A number of ethical problems arose in connection with the business culture in Hong Kong, where the emphasis is strongly on making money in the short term, and the management of human resources is appalling. There is a specific need for education in information systems management and change management, and for awareness of technology to permeate to the middle levels of management. The programme is aimed at teaching technical people to become managers, rather than vice versa. The IAB is concerned about redressing the tendency of the Chinese to be interested in technology to the exclusion of management. The customers of the programme are the students, not companies. The programme caters for experienced students (at least 2 years at project leader level). There are three course themes:-- \begin{enumerate} \item Development of management skills and knowledge (as in other, general, management education). \item Technical methods and management. \item Chinese information systems. (The language poses particular problems of its own in computer systems.) \end{enumerate} Following the discussion of points arising from June's presentation (during which most of the comments were supportive of the emphasis on management), the workshop was divided into three groups to discuss aspects of information systems (IS) management and report back to the plenary. \subsection{Group 1} In industry there are both technical and managerial promotion ladders, both of which require some technical background, however. Many universities (particularly in the USA) are offering degree programmes in technology management. Sometimes these programmes are deficient in particular technical areas, of which configuration management is one example. There are various chains of progression that must be catered for:-- \begin{itemize} \item First degree to master's degree. \item People moving from other areas into software. \item People who have been in industry for long periods who require further knowledge in order to progress to senior positions. \end{itemize} There was disagreement about the extent to which those with IS related degrees are taken up by industry and promoted. It was argued that there is a trend in industry away from recruiting people with specific computer science qualifications towards those with general engineering qualifications. Against this it was pointed out that IT firms (e.g., Motorola) had experienced problems in teaching IT concepts and particularly software concepts to employees who lacked the relevant background. Although technical graduates do get to board level eventually, the tendency is still apparent in the UK (as a result of the anti-technical bias in the British academic system) for technical qualifications to be under represented at the top levels of management. A manager makes it possible for others to work, and requires different skills from those of the technical expert. Technicians tend to be promoted to their own level of managerial incompetence. There is a need for managers with a thorough technical background. There is also a need for technicians to be trained in management if for no other reason than that they should know how to be managed! A ``classical'' engineering degree programme includes three strands:-- \begin{itemize} \item Science: mathematics, logic, physics, chemistry, etc. -- the basic principles. \item Engineering: abstraction, modelling, paradigms, safety concepts -- their application. \item Management: control of the process. \end{itemize} The possible need for two different types of programme was suggested: the engineering model as above, and the MBA type as run in City University, Hong Kong, both with software content. Eventually, the project management type of subjects which should be compulsory in any such programme were identified as:-- \begin{itemize} \item Managing human resources. \item Communication skills. \item Financial management. \item Team project (involving cooperation with other team members, the giving of presentations, and exercising of interpersonal communication skills). \item Training in interpersonal skills. \item Ethics (including the cultural problems that affect ethical considerations). \end{itemize} In addition, various technical subjects should be in the core curriculum. \subsection{Group 2} The discussion in the second group centred on the nature of the market for Software Engineering MSc programmes, and three types of customer were identified:-- \begin{enumerate} \item Those who have been in the workforce a short time, mainly technical software engineers. \item Those who have been in the workforce a long time and have some management experience, and who are highly competent in their own speciality, but whose general technical knowledge is out-of-date. \item Long-time technical people who are new to management. \end{enumerate} Certain managerial topics should be covered in the core curriculum, but to a depth depending on the culture, the type of customer, or both! \begin{itemize} \item Organisation development. \item Quality and process management. \item Legal aspects. \item Ethical aspects. \item Economics. \item Technical communication. \item Inspection, testing, and other techniques. \end{itemize} \subsection{Group 3} The third group considered the extent to which we require a technical background to consume and evaluate technology, and identified three different career ``tracks'':-- \begin{itemize} \item Management. \item Software engineering process group (SEPG). \item Technical (practitioners). \end{itemize} These different tracks require different levels of four categories of knowledge:-- \begin{itemize} \item IS management (i.e., project management). \item Technical. \item General management. \item Process/product management. \end{itemize} The levels can be assigned as follows:-- \medskip \begin{tabular}{|l||l|l|l|} \hline Category: &Management: &SEPG: &practitioners:\\ \hline IS management &Mastery &Mastery &Experiential\\ Technical &Experiential &Mastery &Mastery\\ General management &Mastery &Awareness &Awareness (general)\\ Process/product management &Mastery &Mastery (in depth) &Mastery\\ \hline \end{tabular} \subsection{Plenary} A rapporteur from each group presented its conclusions, and there was a general discussion. The point was raised that the economics of the programmes from the university's point of view had not been discussed, The problems remained of who was to teach on such programmes, and the fact that universities would not look kindly on programmes which cost them money! \section{Teaching Research Design} Ross Jeffery of the University of New South Wales led this discussion, and described graduate education in Software Engineering Research. This consists of two 14 week courses (3 contact hours per week) in research methods:- \begin{itemize} \item Research Topics 1 (RT1): how to plan, design, and execute case studies, laboratory experiments, field studies, surveys, etc. \item Research Topics 2 (RT2): collection and analysis of data, application of parametric and non-parametric tests using statistical software packages such as SPSS. \end{itemize} Particular use is made of Yin R.K. ``Case Study Research: design and methods'' (a topic which has exploded in the last 5 years). The courses are a compulsory part of any research degree (BSc Honours, masters or PhD) and must be taken either before or concurrently with thesis planning and proposal. It is a methodological, rather than substantive, course. Four or five people around the table said that they taught similar topics as part of computer science degree programmes. Various questions were raised following Ross' description. In particular, what kind of coursework topics are set? This includes such things as carrying out inspections and studying the kinetic effects of team composition on their effectiveness. Data presentation is emphasised, particularly the ``visualising'' of data. The discussion then broadened to cover more general aspects of software engineering teaching. The question was raised of how to train students in problem solving. This was distinguished from decision making. James Hook (Oregon GIST) gave an example of an exercise in which students were asked to make a go/no go decision for the development of a real example system, given certain information. Raymond Offen distinguished the type of problem solving or decision making in software engineering from problem solving in physics, where the search is for excellence rather than conformance. The degree programme at Macquarie includes a ``problem solving'' paper, but this is not based on any formal course. It was interesting to see that the ``outward bound'' type of course has been found to be extremely useful for software engineering students in bringing them out of themselves and fostering team spirit and cooperation. Students are sent on such courses both at Macquarie (where the course is sponsored by Kellogg's who also use it for training managers) and at the University of Wales. There was a discussion of the nature of models as used in software engineering. Raymond Offen distinguished between the scientific view of a model (analytic, and an essential prerequisite of any measurement) and mathematical ideas of modelling. Computer science is driven by the mathematical concept, and students are not taught how to measure. Peter Mellor criticised the way in which a plethora of different models are applied to software (flowcharts, DFD's and other diagrammatic methods) without students being taught a firm conceptual foundation. The idea of measurement is catching on in software engineering, however, as shown by the widespread use of Fenton N. ``Software Metrics: a rigorous foundation''. The problem is how to validate software engineering methods. Students are taught the need to measure, but not shown how to analyse systems. There was then some general discussion of the timing and delivery of courses: periodic, continuous, full time, part time, etc. There is need for practice between contacts. A mixture of delivery methods is required for the working student, not solely 3 to 5-day intensive courses. It is necessary to organise courses so as to maximise the long term retention of what has been taught. The perennial question of whether the 13-week semester is the way to go, also received attention. \newpage \section{Panel Discussion} \begin{center} {``Can we {\em teach\/} Software Engineers in a University?''} \end{center} The consensus seemed to be that we cannot teach students to become software engineers, but we can help them to learn how to become software engineers! (Again, it was pointed out that in some states it is illegal to call oneself a software engineer!) The panel was split over whether it is possible to teach software engineering at the undergraduate level. June and Raymond were of the opinion that it was not possible, due to the lack of industrial experience of the students and their difficulty in grasping what it is like to be involved in a large development project. There were 5 main threads in the discussion:-- \subsection{How to organise team projects} June pointed out the need to design the teams, balancing them to obtain a fair mixture of abilities, sexes, maturity, etc. Peter Mellor described some of the problems that had arisen with the 2nd year undergraduate group projects at City University, where it was the practice to assign students totally at random to teams. Unfortunately in the past year this had led to one group having an above average number of weak students, and almost failing to deliver. Other groups had been driven by one or two strong characters who had dominated the other members, and in some cases almost excluded them from making a contribution. Team projects should proceed from specification right through to implementation, and should involve the use of tools, test plans, etc. Examples of documents from real software developments should be provided as a guide to students. It is necessary to be able to assume programming ability on the part of the team members. \subsection{What else is required?} The discussion of group project organisation led to a consideration of group dynamics and interpersonal skills. At Macquarie, laboratory sessions are run specifically to exercise interpersonal skills, and Raymond stated that unless these are specifically taught, and consciously practised during the team projects, then we are only doing half the job. The social dimension to software engineering is absolutely essential, more so than in any other field of engineering. \subsection{The difference between CS and SE} The difference between Computer Science and Software Engineering can be considered from the point of view of the more general difference between ``science'' and ``engineering''. This was usefully summarised in the statement that, although engineers spend a lot of their time learning the scientific and mathematical bases of their discipline, and scientists spend a lot of their time building equipment, ``the scientist builds in order to learn, whereas the engineer learns in order to build''. \subsection{The core curriculum for SE} Judy Bamberger raised the question of the core competencies that any software engineer should possess. This had been covered to some extent in the earlier group discussions. No specific list of core subjects appeared from this part of the workshop. \subsection{Is there any such thing as Software Engineering? } This is another frequently asked question! The consensus was that there is such a discipline, despite the disagreement over exactly what the core syllabus should be, and what scientific and mathematical principles underly it. Software is a real artefact once loaded into a system becomes an essential component thereof, with a physical representation. Its construction does deserve the status of an engineering discipline. \section{Conclusion} It was generally agreed that the workshop had been useful and stimulating. The number of people around the table had been about right to enable the type of informal exchange of ideas that was intended, and to allow everyone to participate in the discussion. Everyone concerned looked forward to a similar successful event at next year's ICSE in Berlin. \end{document} E------------------------------------------------------------------- FASE Volume 5 Number 21 Send newsletter articles to fase-submit@d.umn.edu or fase@d.umn.edu Send requests to add, delete, or modify a subscription to fase-request@d.umn.edu Send problem reports, returned mail, or other correspondence about this newsletter to fase-owner@d.umn.edu or kpierce@d.umn.edu You can retrieve back issues by anonymous FTP from from ricis.cl.uh.edu. You can access them through WWW at URL http://ricis.cl.uh.edu/FASE/ Keith Pierce, Editor Laurie Werth, Advisory Committee Department of Computer Science Dept. of Computer Science University of Minnesota, Duluth Taylor Hall 2.124 Duluth, MN 55812-2496 University of Texas at Austin Telephone: (218) 726-7194 Austin, Texas 78712 Fax: (218) 726-6360 Telephone: (512) 471-9535 Email: kpierce@d.umn.edu Fax: (512)471-8885 Email: lwerth@cs.utexas.edu David Eichmann, FASE Archivist Asst. Prof. / RBSE Director of R & D Web: http://ricis.cl.uh.edu/eichmann/ Software Engineering Program Phone: (713) 283-3875 University of Houston - Clear Lake fax: (713) 283-3810 Box 113, 2700 Bay Area Blvd. Email: eichmann@rbse.jsc.nasa.gov Houston, TX 77058 or: eichmann@cl.uh.edu RBSE on the Web: http://rbse.jsc.nasa.gov/eichmann/rbse.html