Communication between customers, designers and manufacturers is a key to success in product realisation. Ideally engineering students should have the opportunity to experience the exhilaration (or humiliation) of product realisation. It is a central learning experience for the designer. Unfortunately most engineering students seldom experience as part of their course the delight or disappointment of making and testing a product they design against customer expectations. One exemption is in electronic and computer systems engineering, where the small size, low cost and inherent modularity of electronic components make it a simple matter for students to realise their design concepts in hardware.
In mechanical engineering courses however, the time, resources and expense involved in realising machine components or systems place severe restrictions on providing students with a realistic experience of the whole product development process. Construction kits and rapid prototyping technology affords a partial solution (Teakle and Radcliffe, 1994) by providing a relatively quick means of realising design ideas in hardware. While realistic prototypes of mechanical artefacts can be produced using such techniques, their form, function and feel may not have the authenticity to enable the design ideas to be thoroughly tested.
This paper describes a novel use of the World Wide Web (WWW) as a prototyping and production medium. Students work in teams to design, develop, prototype and deliver a complete WWW product. This approach overcomes the resource constraints inherent in realising mechanical products while still providing an authentic experience of contemporary product development.
Frequently products had to be radically re-designed or even re-conceived well into the process due to such errors, omissions or misunderstandings. This serial method of product realisation is referred to as "over-the-wall". The reference is to the metaphorical or literal passing of information or documents over the wall between separate departments, i.e. marketing, design, manufacturing as depicted in figure1. This is a compartmentalised view of engineering practice.
Concurrent engineering aims to overcome the inefficiencies and communication errors inherent in the "over-the-wall" method by carrying out in parallel as many of the functions in the product realisation process as possible. Process including marketing, liasing with suppliers, design, proceduction planning and manufacturing should be overlapped. Rather than waiting for the outcomes of one task to be fully resolved a "flying start" is made on the next task. This flying start is based on best available information at the time from the upstream activity. In this way the commercial imperatives are met by reducing the time to market of the new product. This is illustrated in figure 2.
Concurrent engineering is a process. It has to be experienced to be appreciated. The educational challenge it to devise learning experiences which enable students to make connections between the concept of concurrency and its practice in product realisation. Mechanical engineering artefacts are generally large, involve complex manufacturing processes and take a considerable amount of time to fabricate. For students to be able to experience a complete design and manufacture cycle during a one semester course we must turn to surrogate artefacts and manufacturing techniques. Construction kits such as LEGO, LEGO Dacta and Fishertechnik provide such a mechanism. This lead to the thought that the WWW might also provide a convenient vehicle by which mechanical students could experience the product realisation process in a convenient time frame.
By experiencing how concurrent engineering might be implemented in the product development process and then contrasting this with published accounts and models of the process, you will gain a deeper understanding of concurrent engineering. Your experience of concurrent engineering will be gained in a simulated product development environment.
The students work in teams. Team processes are supported by discussions and information on team formation, team work, and team maintenance. It is explicitly acknowledged that each person has a preferred learning style; a way of gaining knowledge and transforming it for use in circumstances other than that in which you gained the knowledge (Kolb, 1984). Students are encouraged to enlarge their individual learning style by providing opportunities to gain new knowledge by both concrete experiences and analysis of abstract models of the product development process. Further, they are encouraged to transform the knowledge gained in these ways by reflecting on it and actively applying it in new situations; becoming a reflective practitioner (Schon, 1983).
A secondary aim is to develop oral and written communication and evaluation skills in students. The class meets regularly during the semester to have mini-lectures on aspects of concurrent engineering and to allow the students to conduct project reviews and presentations. The pedagogical foundations of CEL are shared with the students as part of the course. Such explicit discussion of the underpinnings of subject is unusual in undergraduate engineering programs.
The students undertake two product realisation tasks as part of CEL. In their first exercise they design, prototype and document a device that can measure up to five body dimensions, a so-called bodiometer (Brereton, et al, 1993). The bodiometer is fabricated from a standard box of LEGO Technic. Teams of students first perform the role of a design group and subsequently that of a manufacturing enterprise. The exercise culminates with the bodiometers being used and evaluated by a "customer". This whole exercise last four weeks. Through the bodiometer exercise the students experience the difficulties inherent in the serial method of product realisation. They also begin to appreciate the importance of thorough and clear documentation in design.
The nature of the second CEL exercise changes from year to year. In 1995 the "product" developed in the second exercise was a WWW homepage on concurrent engineering.
The students were asked to create a WWW homepage on concurrent engineering. The product brief was;
To create a document on the World-Wide-Web that presents the principles and practice of concurrent engineering to an educated, non technical audience.
They were expected to demonstrate, articulate and reflect on their product realisation experiences. The emphasis was on process. The importance of the technical outcome, i.e. the WWW product, was deliberately down played in order to focus on their process. The students were encouraged to reflect on their work, to develop reflection-in-action (Schon, 1987). This behaviour was encouraged through the assessment requirements. Firstly, they had to demonstrate and explain the logic behind their document on the WWW. This was done to an audience of their peers and staff from the Multimedia Facility of the University of Queensland library. Subsequently they had to submit a Reflective Report on the processes involved in preparing the WWW document. This report was to critically analyse the CE practices of the team including the degree of concurrency in their team's work, and the impact of this on their planning processes.
The product is the web document in the project metaphor. The roles of a concurrent engineering team that might exist in developing a mechanical product are mapped to the context of creating a web document. This is depicted in figure 3.
There were four teams each comprising 5 or 6 students. The roles in each team were distributed amongst the three specialist functions (a) marketing and suppliers, (b) design (engineering) and (c) production, usually with two students per role.
It was intended that the first of these functions be concerned equally with identifying the needs and the preferences of potential users of the document and with locating sources of supply of potential material for inclusion the document. This material could be in conventional text sources in libraries or on the WWW. The designers were responsible for creating the basic form of the document, the layout concept, the central arguments and elements of CE to be included. The production group were to implement the WWW document. They were expected to tackle this task by first becoming familiar with HTML and tools (e.g text and other editors) available for creating documents for the WWW.
The CEL classes were scheduled in the Training Room of new Multimedia Facility at the University of Queensland. This room contains 24 Power Macintoshes with DOS compatibility. The students could therefore choose to work in either Mac or Windows as preferred. The facility is equipped with a video projection facility which was used by the students in presenting their final document to the class. The students also had access to two suites of PCs with network cards in our Department on a random access basis. Many had their own computers at home connected to Web via modems.
The familiarity of the students with the Web varied widely, from basic awareness of the "information superhighway" through to those who had their own home pages on the Web. We provided a basic hands-on introduction to the WWW and HTML to the whole class in the Training Room. As a starting point the class explored the WWW version of Bill Mitchell's City of Bits [HREF3]. While being far more sophisticated than the anticipated deliverable of the student teams, it nevertheless provided a helpful example of what is possible in Web documents and of the difference between paper documents (the coffee table version of City of Bits) to hypertext documents.
| Team | Product Concept | Sources and Links | Style and Features |
|---|---|---|---|
| 1 | Core document with links via lists to supplementary files on specific topics (e.g. Quality Function Deployment, Design for Manufacture, Total Quality Management) | Material in documents taken from published literature No links to sites on WWW |
Basic text Dot point lists |
| 2 | Short core document with links to external sites | Very little from published literature Links to international sites |
Eye catching graphics at heading of the document and other places throughout |
| 3 | Single linear document with internal navigation using NAME anchors | Extensive links to related | Simple format Dot point lists |
| 4 | Planetary concept; central hub with satellite documents providing more detail | Linked to numerous sites worldwide Links to lists on the Web related to CE |
Elaborate background Inserted tables into their core document |
The fact that the four teams produced quite different documents illustrates the mantra of design classes that there is "no single correct solution" to a design task. Both the wide variety in the solution principles chosen by the teams and differences in their design details provided powerful reinforcement of this truism.
For example, they used overlap analysis (Krishnan et al., 1993) to examine the relationship between upstream and downstream activities based on their inherent characteristics. This relates back to the decision as to when to overlap tasks (figure 2). They were seeking answers to the questions; which of these tasks evolved quickly and which evolved slowly? Which were highly sensitive to changes in the immediate upstream activity and which had a low sensitivity? How far could you develop a design concept for the document without knowing what was feasible using HTTP? This form of analysis caused the most difficulty for students.
One team deduced that design was a slowly evolving task in this project and that it had a low sensitivity to its upstream activities, marketing and supplier issues. This is indicative of iterative overlapping which is what happened. The production task was found to have a relatively constant rate of evolution, neither slow nor fast. It was seen as being of low sensitivity to design changes. This suggests quite high rates of concurrency between production and design. Although based on a limited data set this example illustrates how simple analytical tools can elicit insight.
The students also analysed their allocation of resources to each task, marketing, design and manufacture, so-called phase analysis (Hales, 1987). This analysis was supported by data from the teams' working documents including plans, task allocation, workbooks and their work products. If the three tasks were carried out in a serial fashion, the phase diagram would have three separate peaks, one for marketing, one for design and one for manufacturing, with relatively little overlap. For most teams there was a substantial peak in each but also considerable spread and overlap. This indicates a degree of concurrency between tasks.
The costs expended in product realisation typically rise more steeply in the later stages of a project as it moves from design and engineering into production. Paradoxically, these costs come about as a result of decisions made in the early stages of design, at a time when the cost expended are relatively small. Consequently there is a gap between the costs committed (which rise rapidly early in the product realisation) and the cost expended to that point. The ideal situation would be to have committed and expended costs tracking each other.
In the case of the WWW documents the incurred cost curve rose linearly, indicating a relatively steady input of effort week by week averaged across the team. The committed costs rose more quickly. This cost structure differs from that of a typical manufactured product, as would be expected. Nevertheless still serves to illustrate the issue of cost committed versus cost expended in product development.
It is often assumed that introducing new information and telecommunications technologies into teaching pratices is extremely difficult and time consuming. The very steep learning curve that must be climbed in order to master new teaching technologies or to create CAL applications is daunting for staff.. Most academics feel that they must be in full command of all aspects of the detail of new techniques before they introduce them to their students. It is a question perhaps of pride, or credibility or perceived authority. This may help to explain why some new teaching and learning technologies are slow to be adopted. The Web exercise reported here shows that the unknown of the new technology can be turned from a problem to an opportunity. If staff are willing to accept the risk of entering on the learning journey with the students, then much can be achieved. Rather than being threats to the pride or prestige of the staff involved, the pre-existing knowledge and skills of some students in HTML and the Web was welcomed. They were accepted as resources that could help the whole class to develop skills in this medium.
On the down side, the students focused heavily on suppliers to the possible detriment of potential customers. That is most teams spent proportionally more time on locating and evaluating likely WWW sites for inclusion in the product than they did on assessing the needs of likely users of their WWW document. Given the current fascination with the Web is distortion is probably inevitable.
In shifting from a physical prototyping medium to the Web, there was a danger that the principles and practices would not understood in the new medium. A number of tools and techniques including Design for Manufacture and Design for Assembly introduced in CEL are described in terms of mechanical engineering hardware and technology. Would these concepts be appreciated in the WWW project metaphor.
Based on the Reflective Reports, it seems that there was an appreciation of the adaptation of such concepts to the Web application. For instance, one team wrote in their Reflective Report under the sub-heading Design for Manufacture;
"The body of the document was inserted into a text file and set out so that it was a simple process for the producer (production function) to install it into the Web document. This saved a lot of time for the producer, as there were two team members assigned to the design stage and only one to the production."
and under the heading, Design for Function;
"The information was put into the document in the form so that users could easily assess the information on particular topics on concurrent engineering or read the entire document in a serial form".
The success of a subject like this one depends on the relationship between several essential factors. First and foremost it is founded on a clear, relevant and explicitly stated model of learning. Onto this foundation of learning theory is grafted a coherent model of the processes we want them to experience, i.e. concurrent engineering. The third layer in the subject structure is the active learning environment that the students experience. This environment contains four crucial elements as illustrated; engaging exercises, reflection, coaching and most importantly the innate enthusiasm of the students. This enthusiasm of the students is a powerful resource that is not always fully engaged in engineering courses. As contemporary engineering courses shift their emphasis from teaching and instruction to learning and facilitation much more effective use must be made of this latent potential. A key to this engagement is the provision of exercises that excite them, relevant exercises in a realistic context. The WWW provides this context.
This exercise was a product of its time. It occurred at an auspicious conjunction of events. The WWW was just becoming widely available. We had access to a new multi-media computing facility. There was an established theory framework and infrastructure in the form of the subject CEL. The metaphor of Web as protopying media was a new and fresh idea. Could this exercise be repeated? The answer must be yes, but not in the same form. The WWW has evolved. Java has become established. More students have more familiarity with the Web. While making a homepage may have captured the imagination of students in 1995, we would need a different challenge in 1996. Nevertheless the Web remains an exciting medium in which the principles of concurrent engineering can be experienced and explored.
The WWW engages the innate enthusiasm of the students. This can then be harnessed through the provision of mechanisms for reflection on their experience and processes vis-a-vis the concepts underlying concurrent engineering. Strong evidence of learning via these means has been presented.
The application of the principles of concurrent engineering to the development of the Web documents by the students show the potential for the application of such principles and methods to the production of professional Web or other multimedia products in engineering and other fields of education.
JR Hartley (1992) "Concurrent Engineering", Productivity Press, Cambridge, Mass.
DA Kolb (1984) "Experiential Learning", Prentice-Hall, Englewood Cliffs, New Jersey.
V Krishnan, SD Eppinger and DE Whitney (1993) "Overlapping Product Development Activities by Analysis of Information Transfer Practice", Proc ICED 93, The Hague, Vol 2, pp 685-688..
DF Radcliffe and P Teakle (1993) "Contextual Experiences in Concurrent Engineering Learning", Proc. Aust. Assoc. Engng Educ, Auckland, December, pp 665-670.
P Ramsden (1992) "Learning to Teach in Higher Education", Pub. Routledge, London.
DA Schon (1983) "The Reflective Practitioner", Jossey-Bass, San Francisco.
DA Schon (1987) "Educating the Reflective Practitioner", Jossey-Bass, San Francisco.
SME (1991) "Tool and Manufacturing Engineers Handbook", 4th Ed, Vol 6, SME, Dearborn, MI
Teakle, P. and Radcliffe, D.F., 1994, "Reinventing the Undergraduate Laboratory: the MaD Experience", Proc. Aust. Assoc. Engng Educ., UTS, December, pp 614-620.
| Pointers to Abstract and Conference presentation | |||||
|---|---|---|---|---|---|
| Abstract | Conference Presentation | Interactive Version | Papers & posters in this theme | All papers & posters | AusWeb96 Home Page |
AusWeb96 The Second Australian World Wide Web Conference ausweb96@scu.edu.au