According to a 2015 survey, 5% of capstone design course instructors indicated that their courses involve students from more than one engineering discipline [1]. Students in these courses may hear presentations on topics of common interest and work together on project teams that require knowledge and skills from more than one discipline. Some courses make use of occasional breakout sessions in which discipline-specific topics (such as U.S. Food and Drug Administration regulations) of greater value to students in a particular discipline are presented during class sessions where only students of that discipline meet [2].
In industry, teams typically consist of members from a variety of engineering and other disciplines, such as marketing, finance, regulatory affairs, manufacturing engineering, production, and quality assurance. These are truly multidisciplinary teams that, in an academic setting, are extremely difficult (if not impossible) to duplicate. Due to various issues (curricular, departmental, financial, and infrastructure), most capstone design teams are composed of only engineering students from a single discipline (homogeneous teams). Creating teams of students from different engineering disciplines may not duplicate the industrial team experience, but it can help students learn about and appreciate other fields of engineering as well as prepare them for careers in industry. It can also improve the team’s ability to handle a variety of technical issues, not just those of a particular discipline.
There are advantages and disadvantages to creating homogeneous or multidisciplinary engineering teams and having students from different engineering disciplines meet to hear lectures of common interest. These tradeoffs can impact student learning and team experiences and also result in a few problems.
During 17 years of teaching a multidisciplinary capstone design course, I have dealt with the four problems discussed in the next sections. Our course at Marquette University includes biomedical, computer, electrical, and mechanical engineering and computer science students. It is taught by a team consisting of faculty from each of the participating disciplines, as has been described in detail elsewhere [2].
Problem 1
Students Complain That Presentations on Topics in Areas Other Than Their Own Are Not Relevant to Their Careers or Their Projects
Example: A guest speaker from a local medical device company discussed the field of human factors and its importance in design. This is an important topic to all disciplines. To explain concepts, he used examples of medical devices with which he had experience during his career. After the first slide (which read “Human Factors in Medical Device Design”) was presented, many of our nonbiomedical engineering students seemed to tune the speaker out and failed to see the relevance of human factors to their disciplines.
To prevent this reaction during future presentations, students are now asked to focus on how the topic might apply to their projects or careers, and not on the specific examples presented. To improve learning outcomes, guest speakers are asked to do the following:
- refer to the course schedule to see all topics covered during the semester, when each will be presented, and how their topic supports the course objectives
- create an awareness among students of their topic and show them how the topic will be used in the performance of their jobs as engineers
- associate the topic with each of the disciplines participating in the course and show students why this is important to their disciplines
- provide a practical perspective of the topic so students will understand
- how they are expected to perform in real-life career situations (professional practice)
- how they are to conduct themselves in organizations (professional conduct).
Speakers are also advised that, upon completion of the presentation, students should be able to
- understand why the topic is important to their careers as engineers
- associate theory with professional practice
- apply what they learned toward improving their analysis and design skills and/or helping them manage their careers
- understand the need for continuous learning throughout their careers.
The medical device industry employs more nonbiomedical than biomedical engineers, and there are many opportunities for mechanical, computer, and electrical engineers in these companies. Students don’t know where their careers will lead them, so understanding something about other engineering disciplines will make them more versatile and well-rounded engineers who can provide greater value to their employers.
Problem 2
Students State That Their Projects Require Knowledge Outside of Their Discipline, and They Conclude That Because No One on Their (Homogeneous) Team Has This Knowledge, They Cannot Complete Their Projects
Example: At Marquette University, biomedical engineering students choose a track in either biomechanics, bioelectronics, or biocomputers. They can form their teams, which may consist of all biomedical engineering students in the same track. This can lead to complaints that their team consists of all biomechanics majors while the project requires some simple circuit design; therefore, the team cannot complete the project unless they are able to add an electrical engineering or bioelectronics student to the team. A similar complaint is heard from teams consisting of all bioelectronics students, who feel that they are unable to select a motor or other mechanical component without adding a biomechanics or mechanical engineering student to the team.
This problem reflects a common attitude among engineering students that their abilities are limited by their engineering discipline and that they cannot cross the “disciplinary” line. This may be true in some situations, such as bridge design, digital electronics, and other areas that require higher-level engineering courses, but it should not be true with simple analog circuit design, tensile or compressive load calculations, or other more fundamental engineering tasks and skills. In cases where the team may lack these skills, they are encouraged to learn them on their own or seek help from their faculty project advisors, other engineering faculty, students in other engineering disciplines, or other sources.
It is important for students to understand that being a successful engineer includes learning how to learn, developing new skills on their own—sometimes by teaching themselves a new method or by figuring out how to use a new engineering tool. These are examples of lifelong learning, which is important to one’s engineering career. In industry, the design engineer is responsible for solving the problem and encouraged to seek help where needed, either from in-house experts or outside consultants.
To help students reach out and become comfortable with seeking advice and assistance when needed, we as faculty should encourage and allow this kind of outreach to faculty, students, industry advisors, and others to help students solve problems associated with their capstone design projects. If students seek assistance only in areas of their teams’ weaknesses and do not ask others to do the work for them, this could serve as a valuable lesson in problem solving.
Problem 3
Students Fail to Apply Knowledge Gained and Skills Developed in Previous Coursework or Experiences
Example: Project teams are required to submit an experimental verification document that describes test procedures, presents results, and draws conclusions regarding how well the team’s prototype meets all performance requirements. They are asked to determine appropriate sample sizes and use appropriate statistical methods to conclude whether specifications have been met. Many teams seem to forget what they learned in their statistics course during the previous year, and they fail to apply their statistical knowledge or use the statistical tools they learned in the course when proving that specifications have been met. This may be due to forgetting the course material or simply not making the connection between what they learned in the course and its applicability to verification activities.
Some students may feel that any tools needed for a class will be presented as part of that class. To dispel this idea, each year, students are told that the capstone design course is about problem solving and that they should draw upon everything they have learned since kindergarten to resolve challenges. Some students learned about computer-aided design (CAD) in high school; others learned how to write code in junior high or high school. Students are encouraged to use any tool if they think it will help solve the problem. This includes free body diagrams, circuit analysis, finite element analysis, CAD modeling, three-dimensional printing, and other engineering tools they learned about as undergraduates or before college.
This is the essence of the capstone design course: to apply all knowledge gained, all skills developed, and all tools made available to them during their undergraduate courses and co-op or internship experiences to solve a design problem.
Problem 4
Students Complain That the Traditional Methods of Project Management Taught in Our Course Are More Appropriate for the Design of Physical Objects, Not for Software-Based Capstone Design Projects
Example: Over the last few years, I have noticed an emerging trend regarding software-based biomedical engineering capstone design projects. A few students working on these projects told me that the more traditional project management methods taught in the class are not representative of the methods used to develop software in their co-op companies. This causes some students to conclude that some of the course deliverables are not relevant to careers in software development.
Our course curriculum has been endorsed by members of our Industrial Advisory Committee, including companies involved in software development. The process we teach is not only relevant but required by International Organization for Standardization Standards 9000 and 13484. Moreover, it reflects current practices used in the medical device industry. To ensure that we have an up-to-date and relevant course curriculum related to soft- ware projects, I have solicited comments from students with co-op experience in software development to identify the methods they used in their co-op jobs (Agile, Scrum, and others) and determine whether these methods should be formally included in our senior capstone design course for software-based projects. I also plan to dis- cuss this with faculty members who have software development experience as well as industry representatives from medical device companies that develop software.
Feedback is Welcome
In summary, combining students from different engineering disciplines in the classroom and on project teams can provide many benefits to student learning and preparation for careers in industry. This approach has tradeoffs and can lead to some complaints from students.
If you are a capstone design course instructor and your course includes soft- ware-based projects, are you receiving feedback from students regarding the use of traditional project management methods for these types of projects? Are there specific software-related deliverables that you require of your software project teams, or do all teams, regardless of the focus, have the same course requirements? Please share your feedback with me at jay.goldberg@mu.edu so I can share this with readers in a future column.
References
- S. Howe, S. L. Poulos, and L. M. Rosen- bauer, “The 2015 capstone design survey: Observations from the front lines,” presented at the 2016 American Society for Engineering Education Annu. Conf. Exposition, New Orleans, LA, June 2016.
- J. Goldberg, V. Cariapa, G. Corliss, and K. Kaiser, “Benefits of industry involvement in multidisciplinary capstone design courses,” Int. J. Eng. Educ., vol. 30, no. 1, pp. 6–13, 2014.