CSC-324 Syllabus (2025 spring)

I'm excited to teach Software Design and Development for my second time this semester! I grew up in Ohio, went to college in Maine, then moved to Washington state to work in software industry and get my PhD. My PhD dissertation is about students building a sense of belonging in college computer science, and it is deeply important to me to build a classroom that is welcoming to all. I have 15 year old tortoiseshell cat named Mocha.

Mentors

Section 01

Destany Best (she/her)

Heyyyy, I am Destany and I am a fourth year double major in Computer Science and French. I am active on campus in the Black Student Union, the long form improv team, and Girls Who Code! I learned a lot during my experience taking 324 and I am excited to be a part of your experience. Feel free to reach out to me anytime!

Section 02

Elliot Swaim (he/him)

Greetings! My name is Elliot. I'm a fourth year CS major hoping to one day develop 3D applications. I took CSC 324 with Leah last spring, and I'm super excited to be back as a mentor! I'm one of the leaders Gateway Grinnell, a Christian club that does Bible Studies every week. I also love to sing in choir and to swing dance! Let me know any questions, quandaries, quams, or otherwise quaggy queries to quaere, and I'd be happy to quell the quagmire.

(back to top)

Learning Objectives

These learning objectives are common to all sections of CSC 324 at Grinnell:

Acquire sound knowledge of software development focusing on software architectural design and requirements to architect a new solution.
Produce software appropriate for inclusion in a portfolio via implementing the source code of new solutions or adding functionality to an existing one.
Acquire experience with developing software solutions to meet a customer’s needs and understand how having a human in the decision-making loop impacts such an application. (The “customer” can either be a technical or a non-technical client.)
Make deeper use of a collaborative version control system and work as a team to develop software solutions for a customer.
Explain the practical and ethical problems associated with a real-world software project.
Gain familiarity with Agile methodologies and apply Agile software development practices and tools to develop software solutions to meet a customer’s needs.
Deepen analytical skills in testing and debugging source code.
Create technical materials to represent and explain the code and design of built applications.
Demonstrate the ability to employ active listening and team communication skills in the collaborative software development process.

Customers

In this section of CSC 324, the "customer" will not be a real person, but rather an abstract role played by your peers, mentor, and instructor to represent users who might use your product. We will use various exercises to take the perspective of software users other than yourself and support inclusive design.

(back to top)

Communication

Announcements [TBD] -- We'll decide together on the first day of class which mode of communication to use for class announcements.

Getting in touch with the instructor -- If you need to get in touch with me, send me an email. I try to reply to messages within about 24 hours, excluding weekends and holidays. If you do not hear back within that amount of time, please send a reminder. You can also schedule an office hour appointment using my calendly link at the top of this page.

Gradescope -- You will submit assignments via gradescope. Please confirm that you have been added to this class on gradescope.

(back to top)

Rhythm of the class

Class meetings -- The class meets for 1h 50m, three times per week, for a total of 5h 30m per week. About half this time will be traditional classroom instruction with the instructor presenting material. The rest will be "lab time" where students complete exercises or group work. The amount of the class period used for instruction versus lab time will vary by day and by week.

Team meetings -- Some of our lab time will be dedicated to weekly meetings of your team, unstructured time for you to work on milestones and get help from the instructor and mentor.

Instructor and mentor meetings (check-ins) -- Each team will meet weekly with the instructor or mentor, during part of our lab time.

Sprints -- A sprint is a cycle in which a team plans, completes, and reflects on shared work. Once teams are formed, we will complete one sprint every two weeks. Every sprint, teams will complete milestones specified by the instructor and additional work of their own selection.

(back to top)

Deliverables

Project proposal -- Working in teams of 2, you will produce a written document and short video pitch describing a vision for a possible group project.

Proposal feedback and preference -- You will give feedback on some of the proposals and produce a ranked list of which projects you would like to work on and teammates you would like to work with. The instructor will choose which proposals become projects based on feasibility and student feedback. The instructor will assign groups based on student preference.

Group project milestones -- Working in teams of 4-6 students, formed in week 3, you will complete milestones every 2 weeks toward the design and development of your software. For each milestone, you will be putting into practice concepts from recent lectures.

Group project demos -- A few times in the second half of the semester, your group will present to the class by demonstrating features of your software and describing your development process.

Group project sprint reports -- Your team will submit brief reports relating to your progress and process for each sprint.

Individual reflections and evaluations -- You will reflect on and evaluate your own contributions to group work, your teammates' contributions, and your team's process.

AI Project -- You will work with a team (potentially different from your course project team) to investigate and reflect on a certain use case of generative AI. You will report your findings to the class and recommend an update to the AI policy based on your findings.

(back to top)

Late Work

Late Days are a currency you can spend to turn in some assignments late. You can think of it as a no-questions-asked extension for many situations that may come up such as a short illness, forgetting an assignment, travel, etc. The late day policy is intended to reduce logistical workload around minor lateness -- it spares students and instructors from negotiating an extension.

You may spend up to 8 late days over the course of the semester.
You may spend one late day to submit one assigment up to 24 hours late.
Late days may be used on any assignment that has a late deadline on gradescope.
To spend a late day, do not ask permission. Just turn in your assignment within the period after the regular deadline and before the late deadline.
The maximum number of late days that you may use per assignment is determined by the late deadline (usually 1).
For group work, every group member spends a late day to submit late.
You are responsible for keeping track of your own late days.
After spending all your late days, late work will not be accepted without an extension.

Extensions

If you need to turn in work late in a way that falls outside the late day policy (e.g. extended illness or absence, out of late days, etc.), talk to your instructor to request an extension.
Unless your extension is due to an emergency, I expect you to approach me well before the deadline to make your request.

(back to top)

Grading

Group work will make up most of your grade. In well-functioning teams that share work equitably, team members will earn the same grades on group work. However, it is possible for different teammates to earn different grades on group work, depending on their contributions, as reported in individual reflections. More information forthcoming on the specifics of grading.

Detailed policy

80% Course project

~60% Milestone & Sprint deliverables
~10% Team Group Work Norms
~10% Sprint planning & retrospectives

5% Proposal

includes proposal and reviews

15% Individual Work

Self evaluations
Teammate evaluations
Pulse checks
Reading responses
Reflections

Adjustments after calculating your grade as a percentage

Add points if there is evidence that you were extraordinarily helpful on your team and went out of your way to support others
Subtract points if there is a lack of evidence you have contributed meaningfully and equitably to your team's work

If you are entirely freeloading in the group work, you CAN fail the course.
Instructor will consider evidence from sprint planning and retrospective reports, commits and code reviews in version control, issue tracker, teammate evaluations, office hour conversations, and observations in class
If your teammates agree that you are making meaningful contributions to the project and there is observable evidence of your contributions in the channels listed above, you have nothing to worry about.
Contributing equitably does not mean contributing equally, so if you have one team member who is going above and beyond, that will not hurt you.

Percent to grade

A 93–100%
A- 90–93%
B+ 87–90%
B 83–87%
B- 80–83%
C+ 77–80%
C 70–77%
D 60–70%
F 0–60%

(back to top)

Attendance

I expect you to attend class every day, but I will not grade you explicitly on attendance. More importantly, your teammates will probably miss you if you don't show up, and will hold you accountable according to your team's established norms.

If you need to plan absences for religious observance, athletics, travel, etc. let me know far in advance. Any day that you will miss class unexpectedly, please email me before class (or after class on the same day) so I know you're ok. If you miss a few days in a row, I'll start to worry about your wellbeing and how your absence might affect your learning and your team's success. Please stay home if you are sick.

(back to top)

Access Needs

I strive to meet access needs for everyone in the class. If you would like to talk about your access needs, let's chat!

(back to top)

AI Policy

Philosophy

Prof. Perlmutter believes that AI can be put to good use for teaching and learning; however, more investigation is needed to figure out which uses support learning and which uses undermine learning.

Participants in this course will work on an AI Project (during sprint 4) in which we co-construct a set of recommendations for using AI, based on our thoughtful and reflective experimentation with AI in activities that are explicitly part of the AI Project. Within the AI Project, there will be many opportunities to experiment with AI, following your interests and curiosity. For course related activities outside the AI Project, use of AI is strictly limited. Our collective findings from the AI Project will be used to update this policy.

Essentially what this means is that if you see a possible use case of AI that you would like to pursue, you will have the opportunity to propose a thoughtful experiment to investigate that use case, conduct and reflect on that experiment, report your findings to the class, and recommend a corresponding update to this policy.

Attribution

Like any other source, you must cite AI when you use it for scholarly work.

Using AI without citation is a breach of academic integrity and can lead to a hearing before the committee on academic standing. Such a hearing can result in your team getting a 0 on the assignment, a penalty to your final course grade, academic probation, etc.
Using AI with citation, on an assignment where you weren't supposed to use AI, is a failure to follow directions and can lead to a lower grade on the assignment.

Generative use

You may not use AI to generate text that you turn in. Prohibited use of AI includes but is not limited to:

generating text for write-ups, reflections, or reading responses
generating source code or documentation in your source code files
using an AI assistant to partially generate code or documentation

Informational use

You may use AI to get answers to your questions by entering short queries.
You may use AI to get feedback on text that you and your teammates have composed yourselves.
You may use the answers and feedback from the AI for your information, provided that you cite appropriately and do NOT copy AI output into a document that you later turn in for credit.

Exceptions

Specific assignments might make exceptions for you to use AI in ways not otherwise allowed by this policy. You must follow this policy unless explicitly told otherwise.

(back to top)

Schedule

This schedule is approximate and subject to change. Bold indicates a milestone with a presentation.

Week	Topics	Deliverable/Milestone
1	Introduction, Project proposals, Doing software well	Proposals
2	Software development lifecycle, Requirements	Group formation
3	Team group work norms, User stories	Requirements
4	Version control, Agile development, Prototyping	Github setup
5	Storyboarding, Getting feedback on your design	Paper prototyping
6	Accessibility	Feedback & Iteration
7	Architecture, Code Design, Build Systems	Design & Architecture
	Spring Break
8	Testing, Team reflection	Testing & CI
9	Testing	(work on release 1)
10	Feedback and critique, Documentation	Release 1 and demo
11	Code Review, Refactoring and technical debt	Documentation
12	Team reflection	Code Review and demo
13	Software Licensing and open source, Bug logging	Wrap up
14	Presentations	Final Presentation
15	Finals week	Final release

(back to top)

Milestones, Sprints, and Presentations

Uncertainty alert: This calendar is for rough planning purposes only. Future dates are approximate and subject to change.

	Theme	Start date	Sprint Planning due	Pulse check due	Main deliverables due (incl sprint review as applicable)	Sprint retrospective due
P	Proposal	Wed 1/22	-	-	Mon 1/27	-
R	Proposal review	Mon 1/27	-	-	Wed 1/29	-
M1	Requirements & User Stories	Mon 2/3	-	-	Thurs 2/6	-
M2	Github Setup	Mon 2/10	-	-	Sat 2/15	-
S1	Paper Prototyping, Feedback & Iteration	Mon 2/17	Wed 2/19	Fri 2/28	Sun 3/2	Mon 3/3
S2	Design & Architecture, Testing & CI (spans spring break)	Mon 3/3	Wed 3/5	Fri 3/28	Sun 3/30	Mon 3/31
S3	Initial Release	Mon 3/31	Wed 4/2	Fri 4/11	Tues 4/8	Mon 4/14
	Interlude: Demo 1 Presentation				Fri 4/11
S4	Documentation Use of AI	Mon 4/14	Wed 4/16	Fri 4/25	Sun 4/27	Mon 4/28
	Demo 2 Presentation				Fri 4/25
S5	Wrap up	Mon 4/28	Wed 4/30	n/a	Wed 5/14	n/a
	Final Presentations				Wed 5/7 Fri 5/9