EXPERIENCES FROM A MULTICULTURAL DESIGN, BUILD, TEST PROJECT

1
(No Transcript)
2
EXPERIENCES FROM A MULTI-CULTURAL DESIGN, BUILD,
TEST PROJECT

• Thomas Gustafsson
• School of Engineering, Jönköping University
• thomas.gustafsson_at_jth.hj.se
• Adam Lagerberg
• School of Engineering, Jönköping University
• adam.lagerberg_at_jth.hj.se
• 5th International CDIO Conference, 7-9 June 2009,
  Singapore

3
Outline

• DBT Project Context
• DBT Project Task
• Experiences round one and adaptations for round
  two
• Experiences round two
• Conclusions

4
DBT Context

• 2 year Masters program in embedded systems
• Prerequisites include bachelor degree in
  Electrical engineering
• No room for a separate DBT project in the
  curriculum
• DBT project given in the context of laboratory
  work of two parallel 10-week courses
• Software engineering Software project management
• Mechatronics Control theory and Hardware

5
DBT Context, continued

• 100 foreign students (middle East, Africa, east
  Asia, Europe, north America)
• Often not used to work in groups or on open
  problems
• Students took a course in Multicultural
  communication
• The DBT project has been given two times

6
DBT Task

• Course-related goals
• Work in a (multicultural) project group
• Practice project model
• Technical goals
• Microprocessor based control system for hanging
  or inverted pendulum
• Graphical user interface for pendulum

7
Model driven development approach
8
DBT Task, continued

• Students were randomly divided into groups
• Each group should deliver some artifacts
• Project documents, e.g., software requirements
  specification
• Presentations
• The end product

9
Grading

• Group grade weighted average of
• Project documents
• Presentations/demonstrations
• Meetings
• Individual grade weighted average of
• Fellow assessment average
• Supervisor adjustment
• Final project (individual) grade
• Group members average grade adjusted to the
  groups grade.
• Course grading
• Weighted average of Project and Written
  Examination

10
Experiences Round One

• Students have problems in
• Dividing a problem into subproblems
• Working independently on subproblems
• Move on even if stuck on some part of the
  problem
• The amount of documentation seemed to, partly,
  hinder the students to focus on the problem
  solving
• Some students thought it was awkward to do peer
  student assessment

Project management document Software requirements
specification Software architecture Software
design Software test specification Software test
report Software requirements tracing document
Hand-over documentation
11
Adaptations for Second Round

• Reduced amount of documentation required from
  each group
• Control free hanging pendulum instead of inverted
  pendulum
• Early presentation, which could force the student
  groups to work more iteratively
• Each group had to include the risk student is
  not doing allocated task

12
Experiences from Second Round

• Many students didnt work independently
• It seems the students cannot divide the problem
  into subproblems and then work on these problems
  independently
• One effect was that the groups got stuck in
  developing a plant model and running experiments
  in Matlab/Simulink, even though their time plans
  had independent branches
• Reducing the documentation gave the effect that
  students didnt see the benefits of working
  systematically The task too simple/uncomplex??

13
Conclusions

• Multicultural aspects Project execution could
  have been better
• When is a DBT project succesful?
• Course-related goals
• Work in a (multicultural) project group got the
  experience
• Practice project model got the experience,
  often good results
• Technical goals
• Microprocessor based control system for hanging
  or inverted pendulum got the training, mostly
  failed results
• Graphical user interface for pendulum got the
  training, mostly success
• Motivate students to work hard and independently
  failed (partly)

14
Questions?
15
Equipment

• NI I/O board
• FPGA reading angle sensor and position sensor
• FPGA communicates sensor values to MCU using SPI
• MCU communicates motor value using SPI
• MCU should send sensor values on serial comm.
  port to PC