Software Engineering — ECE (WL) 30861¶
Purdue West Lafayette / Indianapolis · School of Electrical and Computer Engineering · Fall 2026
Course Information¶
- Meeting location: ME 1061 (West Lafayette) and Lecture Hall 105 (Indianapolis)
- Meeting days and time: Tuesday / Thursday, 1:30–2:45 PM (TR / 1330–1445)
- BoilerCast: A BoilerCast stream of the West Lafayette section will be available.
Instructor Information¶
James Davis — Instructor, West Lafayette section
- Email: davisjam@purdue.edu
- Student consultation hours: To be announced.
Steve France — Instructor, Indianapolis section
- Email: sfrance1@purdue.edu
- Student consultation hours:
- Indianapolis: Tuesdays, 3–4 PM, SL 164Q
- West Lafayette: Wednesdays, 1–2 PM, BHEE 248
Course Description¶
Credit hours: 3.00.
Introduction to the technical and social aspects of software engineering principles, with special emphasis on the process, methods, and tools needed to develop and test quality software products and systems.
Prerequisites¶
Undergraduate level, ECE 36800, minimum grade of D-.
Course Learning Outcomes¶
By the end of the course, you will be able to:
- Conduct object-oriented design and use unified modeling language.
- Understand different models of software development processes.
- Analyze requirements and write project specifications.
- Develop a team software project on time and meet the specifications successfully.
Human society runs on software. Software — mutable logic — underlies domains as diverse as communication, business management, transportation, commerce, finance, and romance. Software engineering is the study of how to design, implement, evaluate, and maintain the software that society does and will rely on. Like any engineering discipline, software engineering is hard. Software engineers work in diverse teams to create and comprehend complex information, such as requirements, design, implementation (and rationale), dynamic software behavior, change impact analysis, and team dynamics.
Teaching Philosophy¶
About Prof. Davis:
In 2012 I completed a BSc in Computer Science and a BSc in Mathematics. I worked at IBM as a software engineer (GPFS), full-time from 2012–2015 and part-time from 2016–2019. I completed my PhD in Computer Science & Applications at Virginia Tech in 2020 and then started as an assistant professor here at Purdue University in 2020. During my PhD I spent some time at IBM Research (2018) and at Microsoft Research (2019).
I believe that computing has already revolutionized human societies, and will continue to do so in the 21st century. Software engineering — a systematic approach to realizing the software part of computer-intensive systems — is of critical importance in ensuring that this revolution benefits people. My research interests are in understanding what software engineering looks like in practice (e.g., artifacts and processes) and identifying means of improving the quality of software (e.g., more correct and more secure). You can find a description of my research on my website: http://davisjam.github.io.
About Prof. France:
I have been an Assistant Professor of Engineering Practice here at Purdue University since Fall of 2023. I have an M.S. in Computer Science from California Polytechnic State University, San Luis Obispo, and over 25 years' experience in software development and engineering leadership for companies in both commercial and defense industries. From 2008–2021 I worked at General Atomics Aeronautical Systems, developing mission and flight-critical systems for medium altitude long endurance RPAs. My experience includes the development, integration, and system/ground/flight test of UAS capabilities for USAF, Navy, UK MoD, CBP and NATO customers. In my free time, I like to be outdoors: running, hiking, mountain biking and traveling with my wife.
How to Succeed in this Course¶
Much of the grade for the course is derived from a substantial team project. Successful teams generally make regular progress each week towards their milestones.
Another large fraction of the grade is obtained through two oral exams. Although lectures are recorded to facilitate student travel, job interviews, etc., your attendance is strongly encouraged to give you practice engaging orally with the course topics.
Learning Resources, Technology & Texts¶
Primary texts:
- Model-Based Agentic Software Engineering — James C. Davis. 1st edition, 2026. Read online
- Software Engineering at Google: Lessons Learned from Programming Over Time — Titus Winters, Tom Manshreck, Hyrum Wright. O'Reilly Media, 1st edition, 2020. ISBN 9781492082798. Read online
Other readings — some other texts from which readings may be assigned:
- Software Engineering — Sommerville, Pearson, 2016. The text has undergone major revisions over the years. We will refer to the 10th edition. The 9th edition has a similar table of contents and should be comparable. We would not recommend a version earlier than the 9th edition.
- The Mythical Man-Month: Essays on Software Engineering — Brooks. Reflections on his decades of engineering (IBM) and research (UNC) experiences. An e-edition is available through the library.
- Design Patterns — Gamma, Helm, Johnson, Vlissides. No need to read this one start-to-finish, but the Introduction and excerpts from the catalog will help shape your design thinking. An e-edition is available through the library.
- Code Complete 2 — McConnell (especially if you have not taken ECE 30862 Object-Oriented Programming). Good advice from decades of software engineering experience at Microsoft.
Additional readings may come from blog posts and research papers. Software engineering is a discipline characterized by change, and the specific readings are updated in each offering.
Equipment¶
You are expected to have at least a $20/mo subscription to OpenAI or Anthropic or Google or similar, or access to comparable open-model capabilities. This course will teach you how to do software engineering with those capabilities. Their effective use is a differentiator for anyone working in the field.
Assignments¶
The course has three main classes of assessment:
- In-class activities (formative)
- Semester-long course project (summative)
- Oral examination (formative and summative)
Given the learning outcomes of this course, the course takes a project-based learning approach, and specifically a team-based one. The bulk of the grade is derived from performance on the project. Typically, all team members receive the same grade on the course project. There are two kinds of exceptions:
- Team members who do not sign the honor code as part of team submissions will receive a 0 on that submission.
- Some team members might perform notably worse on oral examinations than their teammates do. In particular, they might do so in a way that indicates a lack of involvement with the project. In such a case, the active members of a team may have their project grade increased by up to two letter grades, and the inactive members may have their project grade decreased by up to two letter grades, at the discretion of the instructor.
Grading¶
Grade breakdown¶
The course grade is derived as follows:
- 75% — Course project
- 7.5% — Oral exam 1
- 7.5% — Oral exam 2
- 10% — Class engagement (in-class activities, reading quizzes)
Grading scale¶
Per the Purdue University Academic Regulations, the following grades may be assigned by the instructors and reported when called for by the registrar: A+, A, A-, B+, B, B-, C+, C, C-, D+, D, D-, E, F.
- A — Highest passing grade.
- D- — Lowest passing grade; marginally passing minimal objectives of the course.
- E — Conditional failure; failure to achieve minimum objectives, but only to such limited extent that credit can be obtained by examination or otherwise without repeating the entire course. This grade represents failure in the course unless and until the record is duly changed within one semester. It cannot be improved to a grade higher than D. When an instructor reports a grade of E, they shall file in the departmental office a statement of what is required of the student to receive the passing grade.
- F — Failure; failure to achieve minimal objectives of the course. The student must repeat the course satisfactorily in order to establish credit in it.
Attendance Policy¶
The course does not have a formal attendance policy, except insofar as there will be several in-class activities that are graded. If you do not attend class and have not contacted the instructor in advance to explain your absence, you will receive a 0 on those activities.
The course staff will endeavor to make recordings of the lectures available on Brightspace. This will be best-effort, and the technology may fail.
The assignments in this course have deadlines. However, this is an upper-level course, and you will be treated as an adult. Adults manage their time to complete their work by their deadlines. Surprises and emergencies of many kinds — including health, finances, and family matters — are all excellent reasons to proactively or retroactively request an accommodation. If you have a plausible need for an extension or accommodation, contact the course GTAs to request it. Contacting the GTAs is generally sufficient for an individual assignment, subject to the approval of your instructor. If you have a more substantial need, you or your representative should contact the Office of the Dean of Students.
Appropriate extensions will be provided to students with any of Purdue's forms of excused absence. Extensions in other circumstances are at the discretion of the course staff. We reserve the right to assess a late penalty on an extension.
Course Schedule¶
The following calendar is subject to change.
Note that Phases 0, 1, and 2 are specified by the instructors. Phases 3, 4, and 5 are designed by the teams themselves based on the scope of work they select, and hence they are not detailed in this schedule. Some automated testing must be completed in Phases 3–5 in order to receive full marks for that milestone. See the project description for more information.
Project-phase deadlines are Sunday night at the end of the listed week.
Act I — Foundations¶
What are the fundamental activities and structures of software engineering?
| Week | Topics | Concepts | Project milestone |
|---|---|---|---|
| 1 — Aug 24 | Course, Project & GenAI. Tue: syllabus, project rationale/description, speed dating. Thu: GenAI as an engineering tool; course perspective | Engineering vs. implementation; role of judgment; why software needs engineering | Phase 0: team formation; regulatory preferences; regulation pods |
| 2 — Aug 31 | Software Process; software as an engineered medium; lifecycle activities; Waterfall; iterative/incremental; Spiral/risk-driven; Agile/continuous development; process selection; implications of GenAI | Feedback; uncertainty; iteration; cost of change; relationship between medium and process | Phase 1: Study & Scoping begins |
| 3 — Sep 7 | Requirements & Specification; stakeholders and elicitation; functional/nonfunctional requirements; constraints and obligations; specification; scoping and feasibility; requirements negotiation | Obligation vs. preference; ambiguity; completeness; explicit/tacit/unknown/free; degrees of freedom | Phase 1 due: full requirements; feasible subset + business case; competitive analysis |
| 4 — Sep 14 | Software Architecture; decomposition; components/interfaces; coupling/cohesion; information hiding; architectural styles; quality attributes; deployment architecture | Modularity; locality; boundaries; allocation of responsibility; quality-attribute tradeoffs | Phase 2: Specification & Planning begins; pod negotiation |
| 5 — Sep 21 | Design Principles + Fundamentals of SWE with GenAI; abstraction/modularity; interfaces/contracts; design principles and patterns; models and realization; alignment and evidence; incremental realization | Representation; separation of concerns; changeability; obligations vs. implementation freedom; cheap analysis before expensive realization | Phase 2 due: final spec + validation targets + cost estimate + incremental timeline + deployment plan |
Act II — Building Systems & Governing Changes¶
How do we build out our designs and construct an environment in which humans and agents can review and change them safely?
| Week | Topics | Concepts | Project milestone |
|---|---|---|---|
| 6 — Sep 28 | Implementation & Representation; build vs. buy vs. reuse; libraries/frameworks/services; alternative representations of a design; structures and costs imposed by representations; code smells as structural evidence | Representation choice; ownership; dependency tradeoffs; locality; legibility; accidental vs. essential complexity | Phase 3 begins; initial realization + test runs |
| 7 — Oct 5 | Agentic Engineering & Governed Change; agents as engineering actors; context/instructions; agent hooks; git hooks; code review; linters/static checks; tests; CI; permissions/gates; receipts/logging | What must the actor know? What may it choose? Where can violations be detected/prevented? Authority; affordances; controllability; reviewability; reversibility | Phase 3 development |
| 8 — Oct 12 (Fall Break — no class Tuesday) | Thu: Validation & Assurance; testing as evidence; testability and oracles; limits of testing; fuzzing/differential testing; static analysis; model checking/formal methods | What justifies confidence? Evidence strength; cost of evidence; selecting assurance mechanisms appropriate to obligations | Phase 3 delivery with scored test run |
| 9 — Oct 19 (Oral Exam 1 — no regular lectures) | Oral Exam 1 | Defend obligations → architecture → design → realization → engineering environment → evidence | Phase 4 begins |
Act III — Software in the World¶
How do software systems operate, survive, and change in real environments?
| Week | Topics | Concepts | Project milestone |
|---|---|---|---|
| 10 — Oct 26 | Deployment, Operations & Observability; CI/CD in deployment; environments/configuration; rollout/rollback; logging; metrics; tracing; monitoring; runtime evidence | Observability; controllability; reversibility; system boundary; knowing what happened vs. assuming what happened | Phase 4 delivery/test run |
| 11 — Nov 2 | Security & Adversarial Engineering; threat modeling; attack surfaces; trust boundaries; least privilege; defense in depth; CVEs; security response | Adversarial reasoning; risk; exposure; prevention vs. detection; security as a cross-cutting obligation | Phase 5 begins |
| 12 — Nov 9 | Maintenance & Evolution; understanding unfamiliar systems; software archaeology; evolving requirements; compatibility; optimization; technical debt; architectural erosion | Changeability; comprehensibility; accumulated constraints; cost of change; preserving knowledge | Phase 5 development |
| 13 — Nov 16 | Engineering Capital & Sustained Evolution; recurring failures; converting judgment into durable mechanisms; models and implementation evolving together; traceability; automation boundaries | Engineering capital; governance conversion; traceability; model–realization alignment; when to automate; preserving useful degrees of freedom | Phase 5 delivery/test run |
| 14 — Nov 23 (Thanksgiving Break — no class Thursday) | Tue: Engineering in Practice; guest speaker / industrial case / major failure case; technical mechanisms in organizational context | Organizational constraints; incentives; tradeoffs; judgment under incomplete information | Phase 6 begins |
| 15 — Nov 30 | Professional Judgment, Ethics & Synthesis; professional codes; failure case studies; responsibility under delegation; limits of automation; what makes software engineering engineering? | Professional responsibility; consequential judgment; uncertainty; evidence; authority; delegation | Phase 6 development |
| 16 — Dec 7 (Quiet Week / Oral Exam 2 — no regular lectures) | Oral Exam 2 | Defend the complete engineering system: how models, realization, evidence, and environment evolved; what recurring reasoning became mechanisms; what remains judgment | Phase 6: Final deliverable (docs, system) |
| 17 — Dec 14 (Finals Week) | No written exam | — | — |
Academic Integrity¶
This course mandates the use of Generative AI across the software engineering lifecycle. Students are responsible for oversight, judgment, and being able to explain the full stack of decisions.
All team submissions are accompanied by an honor code cover page. Signing that page by typing your name is a statement that you have contributed equitably to the assignment.
AI Policy¶
Generative AI technology is transforming the discipline of software engineering. Mastery of this tool — and the software engineering knowledge needed to wield it well — is becoming the primary differentiator of engineers. Engineers who figure out how to use this tool well are more likely to experience professional success.
Nondiscrimination Statement¶
Purdue University is committed to maintaining a community that recognizes and values the inherent worth and dignity of every person; fosters tolerance, sensitivity, understanding, and mutual respect among its members; and encourages each individual to strive to reach his or her potential. A hyperlink to Purdue's full Nondiscrimination Policy Statement is included in the Academic Resources table on your Brightspace homepage.
Accessibility¶
Every member of our course should be able to access, use, and learn from the materials we share. This includes all course-related digital content that you and I share in the course. This approach helps promote equal access for everyone at Purdue and is mandated federally by Title II of the Americans with Disabilities Act (ADA). We will work together to provide this access within our Brightspace course.
- My part, as the instructor, is to make sure all course materials shared to Brightspace — such as documents, slides, videos and audio, and images — meet accessibility guidelines, and to assist you in making sure anything you share is accessible. If we can do anything further to support your access to and engagement with course materials, please notify me.
- Your role, as a student, is to make sure anything you post for other students to engage with is also accessible, such as peer grading, peer feedback, and discussion board posts. This expectation is built into all course assignments that require you to post to Brightspace.
- A good starting place for students and instructors is to bookmark and review the Innovative Learning Accessibility Checklist for guidance on creating accessible materials. We need to work together to make sure all materials on our course Brightspace are accessible.
- If you select materials to share on our Brightspace from Purdue Libraries catalog or databases, best practices include choosing items that:
- Can be downloaded in full
- Are available in EPUB or HTML formats
- Include alternative text for written materials or captions for audio/visual content
Accommodations¶
Purdue University strives to make learning experiences accessible to all participants. If you anticipate or experience physical or academic barriers based on disability, you are encouraged to contact the Disability Resource Center at drc@purdue.edu or by phone at 765-494-1247, as soon as possible.
If the Disability Resource Center (DRC) has determined reasonable accommodations that you would like to utilize in my class, you must release your Course Accommodation Letter to me. Instructions on sharing your Course Accommodation Letter can be found by visiting "How To Use Your Course Accommodation Letter." Additionally, you are strongly encouraged to contact me as soon as possible to discuss implementation of your accommodation.
Mental Health / Wellness Statement¶
If you find yourself beginning to feel some stress, anxiety and/or feeling slightly overwhelmed, try Therapy Assistance Online (TAO), a web- and app-based mental health resource available courtesy of Purdue Counseling and Psychological Services (CAPS). TAO is available to all students at any time by creating an account on the TAO Connect website, or downloading the app from the App Store or Google Play. It offers free, confidential well-being resources through a self-guided program informed by psychotherapy research and strategies that may aid in overcoming anxiety, depression and other concerns. It provides accessible and effective resources including short videos, brief exercises, and self-reflection tools.
If you need support and information about options and resources, please contact or see the Office of the Dean of Students. Call 765-494-1747. Hours of operation are M–F, 8 a.m.–5 p.m.
If you find yourself struggling to find a healthy balance between academics, social life, stress, etc., sign up for free one-on-one virtual or in-person sessions in West Lafayette with a Purdue Wellness Coach at RecWell. Student coaches can help you navigate through barriers and challenges toward your goals throughout the semester. Sign up is free and can be done on BoilerConnect. Students in Indianapolis will find support services curated on the Vice Provost for Student Life website.
If you're struggling and need mental health services: Purdue University is committed to advancing the mental health and well-being of its students. If you or someone you know is feeling overwhelmed, depressed, and/or in need of mental health support, services are available. For help, such individuals should contact Counseling and Psychological Services (CAPS) at 765-494-6995 during and after hours, on weekends and holidays, or by going to the CAPS offices in West Lafayette or Indianapolis.
Emergency Preparedness¶
In the event of a major campus emergency, course requirements, deadlines and grading percentages are subject to changes that may be necessitated by a revised semester calendar or other circumstances beyond the instructor's control. Relevant changes to this course will be posted onto the course website or can be obtained by contacting the instructors or TAs via email or phone. You are expected to read your @purdue.edu email on a frequent basis.
See Purdue's Information on Emergency Preparation and Planning. This website covers topics such as Severe Weather Guidance, Emergency Plans, and a place to sign up for the Emergency Warning Notification System. I encourage you to download and review the Emergency Procedures Guide.
On the first day of class, I will review the Emergency Preparedness plan for our specific classroom.
Grade Appeals Process¶
Students who believe their grade does not accurately reflect their achievement of the learning objectives may discuss this with their instructor.
The University's Grade Appeal Process is outlined in the University Catalog and is also referenced on the website for the Office of Student Rights and Responsibilities (OSRR).
Course Evaluation¶
Please provide feedback on the course and the instructor using Purdue's standard mechanisms. Otherwise it is hard for us to improve.
If you have serious concerns about the course, please raise them earlier so we have time to respond during the semester.
This syllabus is subject to change. You will be notified of any changes as far in advance as possible via an announcement on Brightspace. Monitor your Purdue email daily for updates.