Engineering and technology learning projects
This is an overview of engineering and technology learning projects instructor/student interactions and grading. A list of the projects can be found here.
Problem
[edit | edit source]Engineers are hidden from the public like precious jewelry whether working on military projects or commercial projects. Sometimes the engineering work is kept secret. Documentation is unique to the company and exists only for internal purposes.
This is a wiki. Everything on it is public. Everything here can be used for commercial purposes. The goal is to capture engineering project documentation and provide a method for grading it. The transparency and public nature of this documentation is unique. The goals of this engineering project documentation are:
- Repeat success or failure by reading this documentation (not talking)
- Others can jump in, find a starting point and push the project forward
- Set starting point expectations, capture next steps and assume projects never end
- Trust future people working on these project to join the wikiversity community and leverage/polish existing documentation
- Evolve the documentation tools and organization so that it is attracts a growing community of people wanting to experience engineering projects
Below are issues associated with designing an environment for engineering projects within an educational organization.
Conceive
[edit | edit source]Project versus Labs
|
|---|
|
The words project and lab have too many different meanings. Project in this context means open ended. Students need unique tasks that are managed by instructors. Students have to recommend materials needed for the project. Instructors have no particular experience with the technologies and tasks required. Lab in this context has the objective of replicating previous success. Materials are ordered beforehand. Instructors have done the lab over and over. All students do the same thing. Documentation consists of one boring step after the next with boxes to write numbers in. A group mind left over from the previous semester absorbs the new students whose only method of distinguishing themselves is to do the labs really fast. The joy of engineering is feeling the inspiration associated with solving problems. But freshmen associate inspiration with freedom to do what they want. The narrative of a freshman engineering class is to mature them, transition them to documenting failure with inspiration and joy. |
Hands On transition to Design
|
|---|
|
The term "Design" is used here to generally describe the gateway between freshman engineers and materials/tools. The D of CDIO is a much more specific/narrow definition. Freshmen are first inspired by the outside world of things. Teaching "Design" should not cripple them by imposing a random business processes between the engineering experience and hands on experiences. Bloating "Design procedures" to the point where students are deprived of hands on experiences until the last weeks will turn freshmen off to engineering. Let the project context, it's history, the materials on hand, the talents and abilities, the enthusiasms and conversations, narratives and presentations guide the design/hands-on oscillation. Have a design gateway that evolves as students mature away from the need for hands-on and into design. The gateway (a drawing, schematic, list of materials/vendors, etc.) should be justified by the project, not the course syllabus. Bring up the design/hand-on conversation in the context of project needs rather than individual maturity. Exactly when the hands on experiences occur is ancillary, incidental and should not impact a students grade. Hands on experiences only exist to provide a reason for meeting as a team, creating tasks and documenting something. Student feelings have to be matured (don't wait for seduction), their source of inspiration has to change (frustration as inspiration), their definitions of engineering success (documenting what doesn't work) need to change. Hands on experiences are expensive. The focus on design is not a marginalization of implementation or operation. Design can occur within implementation or operation. CDIO can go on with C or inside D or inside I or O. The bulk of engineering is in implementation and operation. |
Not DIY Tutorials
|
|---|
|
Most of the world expects tutorials with steps that lead to success. Engineering projects can result in tutorials, but tutorials are not engineering documentation. Documenting what hasn't worked is more difficult, and ultimately more important to a successful project involving many engineers. Engineers document failure. So what is engineering project documentation if not DIY tutorials? Engineering is a creative process that involves an objective that has never been tried before, a guess at what to do, clear descriptions of dead ends and failure, proposed next steps and an occasional tutorial celebrating a success. In this format, projects are open ended, never ending and more driven by a sense of art than science and business. Open ended projects are driven first inspiration, not requirements. Requirements are the discussions after inspiration and before perspiration. The goal is to capture a knowledge base of attempts (failures) rather than successes (tutorials). |
Scientific Method Kills Engineering
|
|---|
|
The scientific method is a close cousin when focusing on replication and reverse engineering. But otherwise, it cripples freshman engineering students if referenced. Asking for a hypothesis creates a competitive, idea ownership, territory grabbing conversation. Most of the silent people don't feel qualified to even talk ... and these are the most careful, thoughtful and respectful students. The best potential engineers say nothing. Slackers and cave dwellers are created rather than teams of engineers working together. Try encouraging questions. Admit not knowing yourself. Begin suffering the conversations that trail after "But you are our teacher." Students have been taught that questions are a sign of "not doing your own work." Questions are a sign of weakness. Admitting no knowledge doesn't cause a loss of respect among engineers. Engineering is everyone on the edge of the unknown, asking questions, harvesting the collective mind, working as a team. Reputation is enhanced by facilitating conversations; not by owning solutions; not by claiming command because of prior experience. Asking for procedures causes students to try and visualize 20 steps before doing something the first time, or forces students to write after the fact. Visualizing procedures beforehand leads to feelings of inadequacy. Writing after the fact focuses on success, not failure and most detail is lost. Demand that students write what they are going to do, before they do it. Ask that they write while doing and then stop and reflect, analyze and figure out the next steps (RANT). This is done in a notebook. It will be chaotic, random and full of wrong turns, blind alleys and frustration. The weekly report written electronically in a student wikiversity user space is a summary of this chaos. Out of this chaos, progress that pushes a project forward has to mined. Don't ask for conclusions or analysis. It causes panic attacks in some students. Instead of going inside themselves and reflecting, they automatically look outside themselves for expectations, form, boundaries, detail level, error analysis and lots of other context that exists in other educational experiences. But engineering analysis is vague on purpose. It could merely inspire next steps. It could expose a empirical pattern. It rarely traces back to already existing analysis. The scientific method has morfed into GoingToDo, Doing, RANT triplets in an engineering notebook. The "triplets" typically occupy 1/3 of a page, take about 15 or 20 minutes to write and should be fun for the students and a minimal requirement (more design may be needed) before touching any materials. |
Reduce Scaffolding
|
|---|
|
Scaffolding (teaching students something so they feel confident moving forward) was necessary in the pre-Internet world. Before the Internet, only a small minority of people had both access and talent to learn on their own. After the Internet, everyone has access. Information exists to enhance all talents. Students know this. They can guess your direction, mine the Internet and know more about the subject than you ... before the words finish coming out of your mouth. Some can build presentations in real time. Others need to be taught how. Homogenizing students by regaling them with random detail is the worst thing one can do to prepare them to become engineers. Projects should put boundaries or context around the knowledge that is needed. A freshman course needs to explore this boundary rather than detail titillation which grows weaker every generation. Suppose every project appears to be using an arduino. Don't create a scaffolding exercise in class involving every student that teaches them the arduino. Instead, seed the knowledge by demonstrating to a few that can understand it with the least work on your part. Then promote this few to spread this knowledge. Create a group competence within the classroom this way. There will always be some students that are slow. Identify them positively by figuring out what they are inspired to do rather than label them negatively by failing a group exercise. Students should own the content of their first engineering class. Don't fill it up with scaffolding and then add a token engineering project at the end. This is bait and switch. It does nothing to teach the joy of engineering. It would be better to going back to teaching drawing or Fortan as the first class. |
Textbook
|
|---|
|
There is a text associated with these projects in wikibooks. Quizzes exist that can be captured and put in a school LMS. The text book describes how handwritten, physical computation notebooks are to be written in and how they are graded. The first step in a project is learning how to write in an notebook before, during and after any engineering activity. Then projects can be documented. |
Foster Cohorts
|
|---|
|
Ideally, students know each other. They register together a semester early. They meet before class starts for the purpose of negotiating projects. They produce material lists a month early so materials will arrive before the first class meets. If this is impossible, create projects yourself. Order enough materials for a starting point that involves some hands on experiences. Don't try to do the projects. Don't expect or even try to order all the material necessary. Allow three weeks (or 12 hours class time) for students to get to know each other through one-day mini projects. Put a twist on each project/challenge. Make some competitive. Make some sign up .. Form teams randomly, then let them self select. Encourage them to think about what project they want to do the rest of the semester. Give them a list of starting points. Ask them to think about who they want to do the project with. |
Instructor Owns The Projects
|
|---|
|
Students want to be told what to do. If ownership is left open ended, then the project task setting agenda will be get mired in opinion conflicts with no clear way to resolve them. Instructor has to be the boss, call the shots and ultimately determine weekly tasks. The instructor has to publish the project (move out of user space) in wikiversity. Ideally students create/modify/improve a project document that instructor doesn't have to edit. |
Documentation Handoff
|
|---|
|
The concept of documentation improvement by forcing hand off of the project from one team to another team of students within the same section does cause conversations about engineering documentation style, clarity, usefulness. Have these conversations when they crop up. But forcing a change of individuals on teams isn't necessary to cause these conversations. Changing a few members of a team can cause the engineering documentation quality conversation. Forcing completion every four weeks in order to be able "to present at any time" can cause these conversations. The following immature behaviors derail documentation improvement conversations:
Opening up the possibility of changing projects due to "like/dislike" will cause at a minimum a scaffolding challenge. Asking students to climb the scaffolding quickly results in them wanting to start over. This has to be channeled into improving the scaffolding which isn't as sexy as working on the edge of the unknown. Changing teams can also result in "ownership" issues. Previous team members, particularly those identified with the success of the past project will still try to own this success. Other students will respect this. Creating the ability to both find problems and still respect previous success is a mature behavior. Opening projects up to this dynamic should minimized in a first year experience. Instead promote students with specific talents/gifts to "help/serve" other projects (see Promotion below, or Reduce Scaffolding above). Instead leave the most vested students on a project and move the least vested around to see if they stick to another project. In any case, students will want to wrap the project in a context they control. It is hard to stop this from happening in a brand new project. Most projects attempted should be building on top of previous projects so that the context obviously has to be learned. |
Success: Pushing Projects Forward
|
|---|
|
The goal is to get students to improve/add/push demos and documentation forward. This means the wikiversity documentation has to be the root of the project. Success in physical space should not be rewarded in the grading system. Success in physical space is an opportunity to document .. which is rewarded. Success, competence and feelings of contributing to the well-being of the world should come from the documentation, presentations and demonstrations. Success feelings do not come from hands on experiences. Success in physical spaces is that of a temporary performance. Documentation success lives forever. Create a set of unique/different projects for each team of 3 or 4 students before the class starts. Make the classes large enough (15 to 20) so there are 4 or 5 projects to choose from. If these projects are unique to each section, then a school with 5 sections could have 20 to 25 unique projects. Attempt to find a starting point for each and associated materials. Attempt to line up a real world client beforehand for each project. If this is impossible institutionally, then use internet DIY projects as a starting point. |
Design
[edit | edit source]Scaffolding Double Bind
|
|---|
|
Engineers explore the unknown from a scaffolding of previous experiences. The goal is to know how to build upon this scaffolding. Most students have been taught they have no scaffolding and perpetually need to be educated. This creates a double bind in their mind:
Maturity is working within this double blind. Instructors can speed up this maturation process with these snippets or sound bytes:
The brightest students have learned how to derail everything by bringing up this double blind. They can play dumb/incompetent through the first and second, plead ignorance on the third, but students generally have not "valued their ignorance." The fifth visualizes what results from maturing through this double bind. |
First three weeks
|
|---|
|
Don't have students do long introductions. Instead start with this Ethical Code. Then form small teams randomly of three or four to talk about the Ethical Code and give them a little project to do in class. Next class form different random teams and repeat. But have them work over the first weekend and present next class as a team. Then form new teams that do a project for the rest of the week and next weekend. Third week starts with presentations and then negotiation of final teams and the projects they will hopefully do for the reset of the year. By this time, students ideally will self select into teams of three or four, choose a project from a list and then approach the instructor. The instructor should have a variety of projects select from. A good engineer should be able to contribute to any type of project. The best engineers are delighted when they can get a project they have no experience on. They get to learn something new! Most engineers select projects based upon how much they can:
Freshman make the mistake of selecting projects where they can:
|
Reforming teams during Semester
|
|---|
|
The best projects are where the same group of students stays together the entire semester and works on the same thing. A bonus should be given to groups that stay together. And a bonus should be given when the talents of a student are needed in another project and the student moves to another team for this reason. In some classes, one third of the students drop or stop participating. Under performing groups and groups that have shrunk to one person need to be reassigned. Sometimes a project reaches a standstill where nothing more can be done and a new project has to be created. Sometimes materials are ordered for another group of students that continue the project next semester. With this in mind, it is good to have planned boundaries upon which team documentation captures the individual student's weekly work. A good boundary is four weeks for a class that meets four hours per week. Students mature during these conversations about reforming teams. Make sure the conversations happen. |
Promotion
|
|---|
|
Students will only experience success when they can present ... when they can say look at what I did. This has to be coupled to documentation. Only allow Presentations from project documentation. The tension of a presentation exposes a student's character or personality. Mature behavior needs to be promoted. Here are some signs of mature behavior:
Typically instructors are trained to focus on the behavior that needs to be changed and let the mature students do what they want. The idea here is to promote the mature students. Identify strengths as soon as possible. Then give these people tasks that are outside of their normal team. For example, someone figures out how to test if an arduino is working. Send this student to spread this skill into the group mind by jump starting other teams using the arduino. Don't give it a name. Promote by giving them more visible, respectable tasks. Something as silly as "Go listen to Nancy .. she learns best by talking" is a form of promotion if it is something you as an instructor, would have to do. The best promotion is letting them choose teammates when it becomes necessary to re-form teams. Promotion does not have to be graded. The respect created is enough to motivate more mature behavior. |
Classroom Activities
|
|---|
|
Project grading has to be done continuously in a freshman class. This promotes continuous work on projects. Otherwise, nobody works until the last moment and the chances for personal interaction and conversations are greatly diminished. Most of face to face class time should be talking about projects, documenting projects, negotiating who is doing what for the team outside of class time. The focus of face to face class time is on task negotiation, CDIO document names/outlines, notebook grading and presentations .. not working on projects. The instructor first meets with each project team quietly, sitting down, talking about who is doing what, finding sources of materials, and harmonizing expectations of the wikiversity documentation. Then the students finish the wikiversity documentation, stand up present to the entire class from the wikiversity documentation. Optimal class size is around 16. |
Materials and Tools
|
|---|
|
Students are going to want to build first. Slow down. This is not the first step. Gathering materials, touching things happens after design. It happens after Team meetings, individual tasks, and writing in a notebook. Unfortunately student enthusiasm will overwhelm any speed bump between them and a hands on experience. Access to tools and materials has to be through a physical gateway. But this gateway has to be tailored to the individual student. The context of the project and the "Hands On" starting point of the student will mix to form a gray scale. A universal and fair gateway will cripple a class. So this has to be a private thing between an instructor and each student or group of students. Materials feel like presents. Giving students something to take home inspires them. But only let students with a very good attendance record take things home. Track these things with a sheet of paper students sign. Penalize them through the same system as the school library if not brought back on time. |
Materials or Hands On Double Bind
|
|---|
|
Introduction to engineering students need a junk pile to get started. But the goal is to design first and then find material that fits the design. So a transition has to occur. This maturation can not happen unless the junk pile is only sufficient to force identification of material that needs to be acquired. This creates the opportunity to order materials and starts the materials double bind because someone has to answer this question: "what do I do while waiting?" All engineering students need to experience this double blind because of the immature need for "hands-on" experiences.
Students cope with this by
Instructors have to watch for and respond to these behaviors by:
Ultimately this is handled by an Engineering Lab Policy Manual. |
Implement
[edit | edit source]The grading system should be set up so that a student that shows up to every class, participates in every group meeting, attempts to write in their notebook but contributes nothing gets a C. Here is a 2000 point grade system:
- 100 class attendance
- 400 seminar
- 400 assignments
- 250 weekly
- 250 notebook
- 200 presentations
- 400 projects
Assignments are graded by instructors after the due dates. Weekly memos are graded outside of class time at the beginning of each week before the first class. Notebooks are graded once a week, at any time, upon the initiative of the student during class. Experiments will begin fall 2014 with students grading presentations through clickers and cell phone apps. Projects are graded by instructors looking at proposed project documentation at three or four intervals during the semester.
Engineering Seminar
|
|---|
|
An engineering seminar is where all engineers on campus gather once a week in a big auditorium. The goals of the engineering seminar are:
The presentations have the following benefits:
Outside of the seminar, students are encouraged to build their social network. Social networks are built by encouraging and rewarding students that participate in SWE, NSBE, AIAA, IEEE and other student chapters of engineering societies. Social networks are built by encouraging and rewarding students that participate in hacker space and museum activities, go on tours, find internships, etc. The 400 points are typically split up into:
The social networking points are built up by reporting on what happened to the class (not seminar) in a short presentation. |
Assignments
|
|---|
|
Assignments are unique to the college, scaffolding, projects and mandates of institutions transferring to and/or upper division class prerequisites. |
Individual weekly memo
| ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Instructors grade weekly individual memos at the beginning of the week. Instructors look for a narrative that describes what the assigned task was and what actually happened written from the "I" perspective. They look for words, pictures and videos that can be cut and pasted onto the projects page. The goals of individual weekly memos are:
Grading individual weekly memos outside of class is fun. It sets the stage for conversations with in the classroom for the entire week. The grading rubric is form/task/push.
Ideally students write their weekly memos in their own user space. The instructor creates a "section" or "course" page in their own user space that points to the individual student's weekly memos. The instructor gives feed back on the student's weekly memo and encourages students to look at this part of each other's feedback. This is pure fun from an instructors point of view. It sets the stage for the discussions in class in the team context. Class time prioritizes team meetings, presentations and wiki documentation. Actual work on projects should only occur if there is time left. Instructors should also work at pushing projects forward in class. Students that begin idle, non-engineering talk should be focused first by example and then by re-tasking if they can not always find something to push a project forward. |
Notebook Grading
|
|---|
|
Grade notebooks in class once a week. The rubric is to give points for following the format, drawings and GoingToDo, Doing, Rant triplets. Again, the grade is open ended so grading has to be done by points. Write the rubric, (form, drawing, project) on even pages, total the number, record in your gradebook, date and sign.
Graphics grading starts off counting the number of arrows connecting descriptions to the drawings. Repeated drawing of the same thing reduces the count. Only differences increase the count. Notebook drawings should never be a substitute for drawing with software.
Triplets are graded by counting rants and then multiplying by three. Initiate notebook grading at any time. But leave it the responsibility of students to get their notebook graded. If students don't get their notebook graded, they loose form points only, not drawing or triplet project points. If nothing is done, no notebook points are awarded. If a student completes one triplet, it is 13 points. This can be done in class. If notebooks are required for entrance into the classroom, then it is easy for students to get 16 points a week. 15 weeks *16 = 240 points. So for basically participating the entire semester, this point category can be maxed out. The better students are going to max out their notebook points well before the end of the course. It is expected that the notebook will continue to be used, even though it is not graded. |
Presentation Grading
|
|---|
|
Any project should willing, able and want to present at any time. Presentations longer than 5 minutes should be penalized. Presentations should be practiced in the classrooms. Instructors may even give the presentation. Presentations should not be limited to the specific project working on, but could be project proposals or engineering experiences encountered out in the community. Presentation opportunities are not limited to the engineering seminar and projects day but to presentations around campus during engineering week, during celebrations such as Ada Lovelace Day, World Toilet Day, π Day, etc. Unique presentations to internal organizations such as buildings and grounds or the college board of directors may be rewarded. External presentations to organizations in the form of papers at engineering conferences, project customers, etc. can also be rewarded. Rubric: These are something an instructor can capture that aren't subjective:
These are subjective items that an audience could be asked .. through clickers, cell phone texting or smart phone apps
Presentations in the seminar and on projects day should have the rubric applied. Presentations should be a reward for good work. Not every team or every person should expect the opportunity to present. If two 100 point presentations are give and 5-10 point presentations are allowed in class, then it should be easy for most students to obtain the maximum of 200 presentation points. |
Project Grading
|
|---|
|
Good attendance, participation and support of those on the team, along with minimal weekly memos, minimal notebook work and no project push should result in a C. Project grading is what separates B and A students. If students max out all other point categories, they can get a B without pushing a project forward ever. Every individual on a team gets the same project grade. However, this project grade is a percentage of their weekly push points. If the team gets a project grade of 100%, each individual's weekly push points are added to their project grade which has a maximum of 400 points. If the team gets 50%, then half of the individual's weekly push points are added to the project grade. The teams project percentage grade starts off with checking to see if all the push point information makes into the project documentation. Here is the negative rubric. To see the positive, look at the syllabus.
|
Operate
[edit | edit source]Open Ended Success
|
|---|
|
Engineering projects are never finished. It is wrong to assume that projects start, go through some process and are finished, then documented. Documentation has to happen continuously. Presentations have to be done with only a 2 minute notice. There are always unrealistic expectations. Part of engineering is breaking the unknown into starting points and doable chunks. Hopefully it pushes the project forward. One may be merely documenting what is impossible. Expectations are constantly being renegotiated during tasking. Unknown requirements creep into the tasking and then make their way into the problem statement through the back door. The point is that success is not "finishing" a project. Success is presenting. Success is presenting something new, wonderful, world changing, world improving at a moments notice. Get noticed. Get a job. Get in front of the public and wow them. |
CDIO
|
|---|
|
CDIO is described in the wikibook associated with this course. Project pages should be dominated by an accumulated history of all work on the project (even by other teams from past semesters). This is the outline:
The first and the last are the most interesting. The details of what happened are usually found in the middle. |
Demo
[edit | edit source]Typical Syllabus
Next Steps
[edit | edit source]- Increase number of schools/instructors using this
- Get this published through NSEE
- NSF Grants to spread this documentation format
- Leverage to build projects in all engineering classes
- Promote use by PLTW
- Propose as high school/college freshman best practice to ABET and CDIO
- Promote to wikiversity editors as best practice project documentation