Author: Patrick Lam
| 0900-0930 | Breakfast |
| 0930-0945 | State of the SE Program (PL) |
| 0945-1015 | What should an SE grad be able to do? |
| 1015-1045 | New technology trends in the world |
| 1045-1100 | Break |
| 1100-1130 | Years 2-3 |
| 1130-1230 | Student engagement |
| 1230-1315 | Lunch |
| 1315-1345 | Year 1 changes |
| 1345-1445 | CS 247 / SE 465-464-463 sequence |
| 1445-1500 | Break |
| 1500-1530 | Capstone Design Symposium |
| 1530-1600 | Communications (or overflow from earlier) |
| 1600-1630 | Student wellness |
| 1630-1645 | Wrap-up |
For discussion: I'd like to come to some sort of consensus on what we expect a Bachelor of Software Engineering to be able to do.
This includes both technical and non-technical skills. I'd also like to have some discussion about the level at which we expect them to perform.
For technical skills, I'd expect to talk about core Computer Science knowledge; specific Software Engineering knowledge; Computer Engineering (notably circuits and feedback control); cognate disciplines like math and stats; and natural sciences (although we'll talk about physics specifically later).
I also want to talk about a liberal education and non-technical knowledge. This includes complementary studies (impact of society on technology; economics; humanities and social sciences) as well as more nebulous aspects like teamwork, leadership, and communication. Ethics should be in there also.
Derek Wright (Graduate Attributes Lecturer) writes:
My input would be:
· Don't worry about Graduate Attributes - I can do that mapping afterwards.
· Don't worry too much about how to measure things – we have lots of measurement instruments that are quite good
· I would like to review whatever you come up with and help tweak the language to improve specificity in the expectations
· Yes, I will propose a new streamlined process hopefully before May
P.S. How do we measure something like "knowing how to think critically"?
P.P.S. Should we do something different in marketing BSE vs BCS? It is clear that "you can get a PEng" is not, upon exit, where graduates find value.
For discussion: Are there any ATEs that ought to exist? Are there any topics that we should move from elective to core?
I realize that new-ATE development is most driven by new faculty hiring. But I think it's still a useful discussion to have.
Charlie Clarke writes, informed by his Facebook sabbatical experiences:
- We should cover the basics of SQL really early. Maybe as part of a 0.25 credit SE 102 course
- Some exposure to machine learning should be required
- Targeting a deep understanding of C++ is a real plus of our program, but it needs to be more STL focused [how is CS 247 doing after the 2016 changes?]
Here is a list of core courses that students take in years 2-3.
Some thoughts (technical):
I agree with Charlie that the students need to know SQL and the basics of relational algebra early. Whether that is 348 or something earlier, that can be discussed.
But in 451, I launch directly into talking about data warehouses - I just assume they know things like primary/foreign key relationships and the difference between an inner and outer join.
To guarantee they get this, it's currently CS 348, so from that perspective, it should be a pre-req.
SE might be a different bunch from general CS, but if we remove CS 348 as a pre-req for 451, I could conceivably have students walk in without ever having written an SQL statement...
-Jimmy
Some thoughts (non-technical):
ECE 192 LEC, TUT 0.25 Engineering Economics and Impact on Society The course teaches engineering economics and the impact of engineering on the society at large. Important concepts of engineering economics including cash flow diagrams, present worth, quantification of impact costs and rate of return analysis are presented. The course will discuss real-life engineering cases that cover the above aspects and provide a broad perspective on the issues. Energy supply scenarios and the environment, global energy use and supply, and environmental impacts of engineering projects are discussed. [Offered W, S, First Offered Winter 2019]Here is the requirement for impact (per Simar):
According to Mark Aagaard, we need 6 hours of impact; we are at about 9 hours. We also plan to talk about impact in ECE 190, which is the concepts course. Impact is also covered now in Engineering design days; and Prototyping Lab in 2B in a practical way. Further, impact is something the students have to consider in FYDP. So there is impact in different forms throughout the program.
For discussion: Which changes should we make in years 2-3?
We certainly have many very engaged students. Data point: at March Break Open House we had 35-40 volunteers (most of any program).
The minimal level of engagement that we ask from our students is that they hand in assignments/projects, write exams and, in first year, do labs. Some students can do fine and even get top marks without even going to lecture. In some sense, Waterloo is not providing them much except for a credential and perhaps some support around the co-op process.
I'd say students are very engaged if they:
Our students are currently being asked to do the National Survey of Student Engagement, although Patrick White reports that many immediately deleted the email upon reception. (I'd like to think that if I sent the invitation it might be a bit better; in general I think students are more connected with program-level initiatives).
For discussion: Should we take measures to improve student engagement? How far can/should we go?
Recently, our students have been doing extraordinarily well in their first-year courses.
| 1A mean | 1A 1st dec | 1A fails | 1B mean | 1B 1st dec | 1B fails | |
| 2021 | 85.4 | 95.8 | 2 | |||
| 2020 | 81.3 | 93.0 | 4 | 78.7 | 91.6 | 4 |
| 2016 | 75.5 | 90.3 | 9 | 71.4 | 88 | 22 |
Current 1A courses = CS 137 (Programming Principles); MATH 115 (Linear Algebra); MATH 117 (Calculus 1); ECE 105 (Classical Mechanics); ECE 140 (Linear Circuits); SE 101 (concepts).
Current 1B courses = CS 138 (Data Abst & Impl); MATH 135 (Algebra); MATH 119 (Calculus 2); ECE 106 (E&M); ECE 124 (Digital Circuits)
Starting in 2017: ECE 140 moves to 1B, MATH 135 moves to 1A
Simar Saini writes:
ECE 106 is a bit harder than PHYS 122 as we cover some topics like boundary conditions not covered in 1st year physics courses. However, these extra topics also make the problems really interesting and relevant. Without understanding boundary conditions; you do get problems in 1st year physics which are erroneous or overly simplified. I have also heard depending on who is teaching it; PHYS 122 may sometimes be not calculus based (Firas, can you please confirm or refute this) while ECE 106 has strong calculus in it and requires lots of deep thinking.
Firas Mansour writes:
The first 5 weeks of Phys 122 are dedicated to oscillations and waves, the course does E and M. The course is calculus based, however, we cannot cover all the topics we cover in ECE 106. It does cover DC circuits which ECE 106 does not (and does not need to as they see in 1 A). Simar is correct in that it does not cover boundary conditions, an important topic, and adds much depth, however, ECE 106 is unique in that it does so at first year level. Phys 122 does not cover Faraday's Law or induction.
An important differentiator as, Simar mentioned, is the level of the problems which is higher in ECE 106 than in Phys 122.
Hope this helps,
PS, There is also Phys 112, the algebra based version of Phys 121.
For discussion: ECE 106 is hard and causes student stress. It is a terminal physics course and has no successors except for possible technical electives. Courses with ECE 106 with requisites: ECE 209 (materials), taken by 6 students in 2010-2011; ECE 240 (Electronic Circuits 1), never taken by an SE student; ECE 361 (Power Systems); ECE 375 (EM Fields and Waves); ECE 403 (Thermal Physics)
I asked students about keeping ECE 106 vs replacing with an easier course and perhaps adding a first-year project course.
| keep 106 | 122 + proj | 122, no proj | |
| 2021s | 25% | 70% | 5% |
| 2019s | 50% | 33% | 16% |
The three-course sequence SE 465/464/463 (testing/design/requirements) distills the core of the academic subfield of software engineering. SE faculty believe that this is what SE students should be coming here to do. Yet, these courses are unpopular among students, as reflected both anecdotally and in course evaluation numbers.
Engineering Q17: "What is your overall appraisal of this course?"
| median | |
| SE350 | 71 |
| SE380 | 57 |
| SE464 | 57 |
| SE465 | 62 |
| MATH213 | 75 |
| MSCI261 | 61 |
| ECE390 (not SE) | 53 |
| ECE356 (not SE) | 72 |
Math Q7: "Did you find the course interesting?
| very int | v int + int | not int | |
| SE463 | 7 | 41 | 58 |
Did you find the course interesting (very interesting/interesting/not interesting) SE 463 S16=3/14/73, F14=2/2/96, F13=0/38/62, F12=9/43/49, F11=4/38/58, F10=10/60/29, F09=21/43/36 CS 348 F16=3/71/26, F15=4/37/59, F14=12/84/4, F13=11/60/29 CS 247 S16=6/43/52, S15=14/62/23, S14=17/60/24, S13=19/60/22, S12=7/88/5 CS 138 W16=43/50/6, W15=46/47/6, W14=60/35/5, W13=35/55/11 CS 343 F16=61/36/2, F15=64/30/6, F14=60/37/3, F13=59/40/2 CS 341 W16=36/57/6, W15=50/45/6, W14=20/65/15, W13=45/48/6
Course outlines:
First of all, if we are supposed to be training software engineers, we absolutely have to include some content on requirements. Even if students think that it's 2017 and requirements are passé. They're not.
Having said that, this course comes up extremely often as a pain point; it is the most-often cited "don't like" in the 2017 exit surveys. uwflow ratings are abysmal.
The most recent offering (by Jo) asked the students to use their FYDP as the system for which they are eliciting requirements. Derek Rayside has heard positive comments about that choice during the most recent offering as he was teaching the FYDP course. uwflow got the negative comments, Derek got the positive comments.
From uwflow:
I was lucky enough to take this course with Jo Atlee, who is one of the better SE professors; however, even not Mother Teresa could make a miracle out of this one.
From 2017 exit survey:
I wish that I knew the things we learned in SE 463 at the beginning of our 4A term when we should have been eliciting the requirements of our FYDP from our clients. Learning them later that term was great but we'd already invested a ton of time into a solution which turns out was incorrect. Perhaps if we'd known the elicitation techniques before hand then we wouldn't have had to restart our FYDP.
I submit that it doesn't need Mother Teresa. Kenny Wong at Alberta definitely is not Mother Teresa and offers a 4-week Coursera course with Coursera ratings of 4.7. (Coursera average is allegedly 4.5 and the lower bound for Coursera might be around 3.9, according to this source.)
I don't know really where to start, but two possibilities are the list of topics and the project. Clearly a requirements course has got to be in the context of some project. We've had projects imposed by the instructor and FYDP-as-course-project in the past. It is true that some FYDPs are less suited for SE 463, but they are probably more suited than students think.
I solicited some thoughts from an SE 2009 grad. Industrial perspective on requirements
It's also possible to vary the amount of formal methods used in this course.
Refresher for those of us who aren't software engineers. Andy Ko writes about requirements and specifications.
For discussion: What do we do?
Students often feel like there is a lot of overlap between CS 247 and SE 464, since both talk about design patterns. Faculty disagree.
Jo Atlee writes:
I would be really sad if design patterns were removed from CS247. For one thing, the OO design patterns are all related to small collections of related classes, and this is exactly the size of program that CS 247 is all about. And the OO design patterns nicely build on the OO design principles that we cover in the course. Design in CS247 nicely progresses from (1) design of individual classes to encapsulate (mostly) data representation, to (2) design principles for OO programs, to (3) design patterns for encapsulating lots of other small design decisions. [Werner agrees]
Werner Dietl writes:
Many students complained about design patterns being a repeat from SE 247 (or some such) even though we discussed many additional patterns; that architecture in the abstract was too high-level, even though we discussed concrete examples. I discussed several topics I though would be exciting later in the course (like microservices), but already had lost most students. The feedback from the class reps didn't reflect what I see in the written overall feedback. I see a lot of the criticism about my offering of the course was also given for previous iterations.
I discussed various ideas for improving SE 464 with Werner before the retreat. Some of the ideas are fully within the purview of the individual instructor. Points that are more useful for the retreat:
If we remove the Gang of Four design patterns and the open-ended program design project from SE464, there will be space for new ideas.
Most design patterns are focused on fitness for future: why this design will be robust to certain kinds of anticipated future change. Fitness for purpose often takes a secondary role in the design pattern literature. One possibility is that we could expand SE464 in the direction of fitness for purpose.
Model-checking is one technology that can be used for establishing a design's fitness for purpose. We have successfully taught how to use model-checkers in SE464 before: in the summers of 2010 and 2011 we taught Spin and Alloy in SE464.
There could be other ideas in the direction of fitness for purpose.
Andy Ko on architecture and program comprehension.
My impression: it's not perfect, but putting it in 3A was good. I like what I've done with the course this term—first part is about choosing what to put in test suites; second part is about engineering test suites; third part is about tools.
My perception is that things went very well this year.
Derek has worked very hard to increase the quality of the projects. We have a flexible incentive/marking scheme which includes multiple paths to excellence. I want to talk about both the top groups and the average groups.
We gave two first prizes this year: one in the Entrepreneurial category to Dynalist, which is developing software for collaborative, hierarchical to-do lists, and one in the Research category to Manifold, which is working on synthesis of microfluidics circuits. Manifold had a paper accepted to CCECE. We gave third prizes to a group that developed working Scantron-replacement technology and a group that "probably did something publishable" in the computer graphics space. Honourable mentions went to teams that showed a great depth of understanding about sheet music composition and that implemented significant code for image migration in the Xen hypervisor.
It's also important to focus on the average-quality project. Derek has done excellent work here. All else being equal, the groups that I refereed were probably average groups. Derek has gotten the message across that students absolutely have to talk to users if they are doing a technically-straightforward project. That showed up quite strongly here: both of my groups had been deploying their code for about a month and had some actual arms-length users. This definitely improved the quality of their projects and it's what software engineering really should be about: meeting the needs of end users.
The only concern I should mention is that we've noticed a couple of students who have switched out either to avoid the Capstone Design Project, or because they felt that they weren't pulling their weight on the team. I don't think this is a problem, but this is something that should be noted.
For discussion: I propose that we ratify what we're currently doing.
For discussion: Do our SE graduates have enough experience with both oral and written communication, and in the appropriate forms?
I'd like to reach a consensus on what our students actually need to be able to do in terms of communication. Writing reports is not the same as writing descriptions of pull requests.
Oral communication: students must do a Technical Presentation Milestone (15 minutes), and, in groups, they must orally present their Capstone Design Project (20 minutes). Many students also take a SPCOM class as their communications elective. SPCOM is about non-technical oral communication.
Written communication: I believe that work reports are the only mandatory written communication from our students. Courses may have written deliverables, but none of them are structurally guaranteed. Is this appropriate for their needs? Too much? Wrong form? What about ENGL 210E?
For discussion: What more can we do to promote student wellness, particularly mental health?
Software Engineering is a high-workload program. At the March Break Open House, our current students were reassuring the prospective students and their parents that it's doable. Which is true. We have 800+ grads, after all. But SE is not easy.
As I see it, there are three main factors.
An important aspect of student wellness is having friends. I think our students are fairly supportive, and the cohort system undoubtedly helps with this. I don't care if students have friends within the program or not, but I don't want students to have no friends. How do we reach students with no friends?
Derek Wright writes:
For student wellness, I would like you to consider proactive measures, like teaching sessions on Cognitive Behavioural Therapy and Mindfullness techniques. It’s super easy and there is tons of research showing the benefits.
[PL] SE 101 would be a great time to do this.
SE 2017 partial exit survey: results minus text and salaries
Desiye Collier (class of 2015) on SE culture: [google doc]
Bilal Akhtar (class of 2019) on imposter syndrome: medium