Turning computer science students into software engineers

As part of my Digital Education Leadership master’s program, we are asked to create or modify a learning activity that integrates technology in a meaningful way. My project focuses on group assignments in computer science courses. Often, group assignments do not achieve the goal of giving students a real-world experience of building software with multiple programmers.  One of the biggest issues is that the instructor typically starts a group project by describing the chapter to cover in a text book or the learning activity to be achieved.  Such group assignments suffer from all of the failures described in Understanding by Design by Wiggins and McTighe (2005), also referred to as backwards design.

Too often, computer science instructors use trivial games or a partial application as the basis of a group assignment.  Such assignments miss out on giving students critical, real-world experiences such as: investigating requirements, designing a solution, costing out the solution (in programmer time and difficulty), implementing the solution with fellow students/developers, integrating/testing the solution, and delivering the solution.

For my project, I want to follow the backward design process (Wiggins and McTighe, 2005) to give students a more real-world experience.  The backward design approach can be summed up by the following diagram, in which the educator is the designer:

Stages of backward design defined by Wiggins and McTighe Understanding by Design

I want to turn group programming assignments into a project-based learning experience for my students. As it turns out, the Information Technology group at my institution is in regular need of either new features to existing software or new software to address a specific scenario.  My proposal is to have students pick up one of these software projects, participating in all of the phases required in a real-world software development project – i.e., requirements, design, implementation, integration, testing, and delivery.

There are challenges with this project proposal.  First off, the software projects must not be too complex or too large such that the group of students cannot make any reasonable headway in the time given.  This may require picking only projects that are achievable, given the student’s timeline and skill levels. Another approach is to break down large projects into smaller projects, parts of which are given to different student groups.  Finding the correct approach will likely involve my working closely with members of the IT department to develop a list of potential projects. Today, I am not sure if any IT projects will be possible candidates for my students.

The positive side of this project choice is the opportunities it presents to the instructor to implement the ISTE Student Standard 2 Digital Citizen.  Students will have to develop an identity in the open source community in order to access required software in the public domain.  This will require students to use positive, safe, legal, and ethical behavior when engaging with other members of the open source community.  Students will have to manage their personal data and be aware of the consequences of using and sharing software with members of the open source community.

Stage 1 of backward design defined by Wiggins and McTighe Understanding by Design
See Appendix: Stage1 key – Results classification
Stage 2 of backward design defined by Wiggins and McTighe Understanding by Design
Stage 3 of backward design defined by Wiggins and McTighe Understanding by Design
See Appendix: Stage 2 key – WHERETO

Reflection

My initial plan for my project was to create a single lesson plan focused on requirements gathering.  However, in following the backwards design process, I quickly realized that students needed visibility into the entire process to understand this initial lesson plan.  The lesson plan then turned into the unit plan defined above, covering the major components of the software development cycle. While this turned out to be much more work than I had initially estimated, the end result is something much more useful and meaningful to instructors and students in three major ways.

First, the unit plan provides students a much deeper understanding of software development process.  Understanding by Design by Wiggins and McTighe (p. 84) gives these six facets of deeper understanding:

  1. Can explain—via generalizations or principles, providing justified and systematic accounts of phenomena, facts, and data; make insightful connections and provide illuminating examples or illustrations.
  2. Can interpret—tell meaningful stories; offer apt translations; provide a revealing historical or personal dimension to ideas and events; make the object of understanding personal or accessible through images, anecdotes, analogies, and models.
  3. Can apply—effectively use and adapt what we know in diverse and real contexts—we can “do” the subject.
  4. Have perspective—see and hear points of view through critical eyes and ears; see the big picture.
  5. Can empathize—find value in what others might find odd, alien, or implausible; perceive sensitively on the basis of prior direct experience.
  6. Have self-knowledge—show metacognitive awareness; perceive the personal style, prejudices, projections, and habits of mind that both shape and impede our own understanding; are aware of what we do not understand; reflect on the meaning of learning and experience.

The various lessons in the unit plan provides computer science students the ability to explore the first five of these six facets.  In particular, the prototyping phase touches the first five facets by having the students work with a customer to understand requirements, define prototypes, and present results.  The last facet – self-knowledge – is obtained by asking the students to reflect on the unit, and suggest ways to improve or enhance any lesson in the unit. Software development is not a strict, universal process.  The goal is for students to find the process that works best for the team and realize that changes to the process are inevitable.

Second, the unit allows students to explore many aspects of the ISTE Student Standard 2 Digital Citizen standard.  Many people assume that computer science students are inherently aware of all aspects of being a digital citizen.  However, I have found that this not to be the case. I have several instances of students including code in their programming project developed by another person, and not providing any references.  Instead, the student puts their name at the top of the file, indicating that they are the sole developer of the code. When I ask the student questions about the code, it quickly becomes apparent that the student did not author the code.  When I ask the student if they would put their name on top of a writing assignment in which they simply copied and pasted content from a web site, they universally answer ‘no’, and recognize this as plagiarism. I then point out that, from a software point of view, that is exactly what they have done in their programming assignment.  This analogy is very useful in having students understand and respect the rights and obligations of using and sharing all intellectual property, including software.

Third, and lastly, the unit allows me to further explore the possibilities of project-based learning, moving my class form a teacher-centered process to a learner-driven experience.  In their series on making learning personal, Bray and McClaskey provide a spectrum that students move through as they reach the ultimate, entrepreneur stage:

  1. Participant – The teacher or a computer program provides a menu of options for learners.  The choices offered provide learners opportunities to showcase what they know from writing a paper to creating a performance.
  2. Co-designer – The teacher provides learning possibilities and then gets out of the way for learners to go on their own journey.
  3. Designer – The learner chooses topics and direction for what they plan to design based on personal interests.
  4. Advocate – The learner chooses a challenge or problem that they are passionate about.
  5. Entrepreneur – The learner self-regulates, adjusts, and determines learning based on what they want to do with their lives.

Students that become entrepreneurs have a world of possibilities open up to them.  Our role as educators is to provide as many opportunities as possible for students to progress through this spectrum, realizing that students will not follow the same path, at the same speed, with the same instruction.

Resources

Appendix

Stage 1 Key – Results classification

  • G – Established Goals
    • What standards or objectives are being addressed?
  • Q – Essential Questions
    • What essential questions will be considered?
  • U – Understandings: Students will understand that…
    • What understandings are desired?
  • K – Knowledge: Students will know that…
  • S – Skills: Students will be able to…
    • What key knowledge and skills will students acquire as a result of this unit? (aka Students will know… and Students will be able to…)

(Wiggins and McTighe, 2005)

Stage 3 key – WHERETO

How will the design…

  • W = Help the students know WHERE the unit is going and WHAT is expected? Help the teacher know WHERE the students are coming from (prior knowledge, interests)?
  • H = HOOK all students and HOLD their interests?
  • E = EQUIP students, help them EXPERIENCE the key ideas and EXPLORE the issues?
  • R = Provide opportunities to RETHINK and REVISE their understandings and work?
  • E = Allow students to EVALUATE their work and its implications?
  • T = Be TAILORED (personalized) to the different needs, interests, and abilities of learners?
  • O = Be ORGANIZED to maximize initial and sustained engagement as well as effective learning.

(Wiggins and McTighe, 2005)

Leave a Reply

Your email address will not be published. Required fields are marked *