CEN3031 Software Engineering I is the course where programming becomes engineering — the processes, practices and judgement required to build software in teams, at a size where no one person holds the whole system in their head.
The course is offered at a small number of Florida institutions, including Florida Gulf Coast University, the University of Florida and the University of West Florida. ⚠ Institution count is low, so expect variation — particularly in which process model and which technology stack the course uses.
The University of West Florida titles it Software Engineering I, places it in the College of Science and Engineering, Department of Computer Science at 3 semester hours, requires COP 3022 OR COP 4331, and covers "preparation of software planning, specifications, design, coding, testing and maintenance," with "familiarization with the team approach to large software system development with an emphasis on software process and methodology."
Florida Gulf Coast University titles it Software Engineering Fundamentals at 3 credits: "the software engineering process stages are studied and applied to the development of a significant computer application using object-oriented design," including "requirements, design, prototyping, implementation, documentation, testing, code reviews, maintenance, and enhancements." The University of Florida carries it as Introduction to Software Engineering.
⚠ Note UWF's "I" — it signals a two-course sequence (UWF also carries CEN3032, Software Engineering II) where FGCU's and UF's titles do not. See Special Information; this is a sequence-position signal worth checking before transferring.
What the course is actually about, and why students frequently resist it at first. Every prior programming course had a specification handed to you, a correct answer, and a deadline you could meet alone. Software engineering exists because none of those hold at scale. Requirements are ambiguous and change; there is no single correct design, only trade-offs; and the work is done by teams whose members must coordinate, communicate and hand work to one another. ⚠ The course's uncomfortable central claim is that the coding is not the hard part — and students who have only ever been graded on working code find that genuinely disorienting.
Requirements engineering comes first and is where most real projects fail. Eliciting what stakeholders need — as distinct from what they first ask for — specifying it unambiguously, distinguishing functional from non-functional requirements (performance, security, usability, maintainability), and managing change. ⚠ The empirical finding the course rests on is that defects introduced in requirements are enormously more expensive to fix later than defects introduced in code, which is the entire argument for doing this work deliberately rather than starting to type.
Process models are the course's organising framework, and the honest treatment is comparative. The waterfall model — sequential phases — is taught first because it names the activities clearly, and then criticised because it assumes requirements can be fixed in advance, which they usually cannot. Iterative and incremental models follow. Agile methods — Scrum and Kanban in practice — now dominate industry, and the course teaches them as a response to waterfall's failures rather than as an unqualified improvement. ⚠ A good course says plainly that agile is not a licence to skip design, and that "we're agile" is frequently used to excuse exactly the absence of engineering the course is teaching.
Design is taught as the management of change. Modularity, coupling and cohesion — low coupling and high cohesion — is the oldest and most durable idea in the field, and it exists because the real cost of software is in modification, not in initial construction. Design patterns, architectural styles, and the SOLID principles follow from it.
Testing is treated as a discipline rather than an afterthought. Unit, integration and system testing; test-driven development; the distinction between verification (are we building it right?) and validation (are we building the right thing?); and coverage — with the honest caveat that coverage measures what was executed, not what was checked.
⚠ The team project is the course, not an assignment within it. Both UWF and FGCU name team development explicitly. You will experience the coordination problems the course describes rather than merely reading about them — including the ones nobody enjoys: unequal contribution, merge conflicts, a teammate who disappears, and the discovery that your beautiful design does not survive contact with someone else's code.
⚠ Florida employers: the defence and aerospace base — L3Harris (Melbourne, Palm Bay), Lockheed Martin (Orlando), Northrop Grumman, and the Space Coast contractors — where rigorous process and documentation are contractual requirements rather than preferences; the financial technology sector in Jacksonville, Tampa and Miami; healthcare IT across the large systems; the simulation and training cluster in Orlando; and a growing startup scene in Miami and Tampa.
⚠ Practical advice: your public repository is your portfolio. A well-structured project with tests, meaningful commit history, a real README and evidence of code review demonstrates everything this course teaches, and it is what a hiring engineer actually looks at.
| Institution | Title | Sequence? |
|---|---|---|
| UWF | Software Engineering I | ⚠ Yes — CEN3032 Software Engineering II follows |
| FGCU | Software Engineering Fundamentals | title implies a single course |
| UF | Introduction to Software Engineering | title implies a single course |
| Statewide | Software Engineering I | — |
⚠ The "I" is not decoration. Where a two-course sequence exists, the first course typically covers process, requirements and design, with implementation and the larger project falling to the second — which means a single-course version must compress all of it, and a two-course version's first half covers less ground than a standalone course would.
Practical consequences:
CEN3031: you have the first half of a sequence. ⚠ A receiving institution's single "software engineering" requirement may or may not be satisfied by it — the credit articulates on the number, but the coverage may be thinner than the requirement assumed.CEN3032, or you may be asked to take CEN3031 anyway.UWF requires COP3022 OR COP4331 — an intermediate programming course, with the alternative suggesting the department accepts more than one route in.
⚠ The prerequisite is genuine content, and the unlisted part matters more. This course assumes you can already program competently in an object-oriented language and have written something larger than a single-file assignment. A student whose experience is a series of two-hundred-line exercises will find the team project disorienting — not because the concepts are hard, but because they have never had to read someone else's code or return to their own after three weeks.
⚠ Data structures is the other genuinely useful preparation, and any prior exposure to Git pays for itself immediately — students who meet version control for the first time during a team project lose days to it.
The course sits in the junior year of a computer science or software engineering programme. ⚠ It is an ABET-relevant course: accredited computing programmes must demonstrate that students can function on teams and apply engineering practice, and this is normally where that is evidenced.
3 credits, 45 contact hours — lecture plus substantial project work. ⚠ No C suffix, so the project time comes out of your own week rather than a scheduled laboratory.
⚠⚠ Expect 10–12 hours per week outside class, and expect it to be unevenly distributed and partly outside your control. Team coordination costs real time — meetings, reviews, merges, waiting for a teammate — and it does not compress. This is the course most likely to be derailed by a scheduling conflict with teammates rather than by difficulty.
Assessment typically includes the team project across the full lifecycle, deliverable documents (requirements, design, test plan), individual examinations, and frequently peer evaluation of contribution.
Team project problems are the single most common source of grief in this course, and most are preventable.
CEN3031 is a 3000-level upper-division course, not generally offered at Florida College System institutions, and taken after transfer. The number is used consistently at the three Florida institutions that carry it, so SCNS articulation is clean — subject to the sequence issue above.
⚠ ABET note. Software engineering practice and teamwork are required components of an accredited computing programme. If you are transferring between accredited and non-accredited programmes, the requirement is enforced at programme level regardless of how credit articulates — ask the department.
⚠ Prefix note. CEN is software engineering and systems; COP programming; CDA computer organisation; CAP applied computing; CIS computer information systems; CGS general computing; EEL electrical and computer engineering. ⚠ Software engineering is numbered under CEN at most Florida institutions but appears under CIS or EEL at some — search by subject rather than prefix when checking a requirement. Related: CEN3032 (Software Engineering II at UWF), CEN4020 and CEN4072 at other institutions.
⚠⚠ Software engineering is the discipline most directly and immediately changed by AI coding tools, and a course taught now that does not address it is failing its students.
What has actually changed. AI code assistants are in widespread professional use, and the evidence is reasonably consistent: they produce meaningful productivity gains on well-specified, routine and boilerplate work — scaffolding, test stubs, familiar patterns, unfamiliar API syntax — and much less on novel design, on debugging subtle behaviour, and on work requiring understanding of a large existing codebase.
⚠ The course-relevant point is that this maps precisely onto the distinction the course exists to teach. The tools are good at coding. The course's subject is engineering — deciding what to build, how to structure it so it can be changed, how to know it works, and how to coordinate people. Those remain human, and their relative value has risen rather than fallen.
Where they genuinely help in this course: generating boilerplate and scaffolding; writing unit tests — a good use, since test writing is tedious and the generated tests are a starting point you then extend; explaining unfamiliar code, which is directly relevant when you inherit a teammate's module; drafting documentation; and learning a new framework's syntax.
⚠ Where they fail, and these are the failures the course is best placed to explain:
⚠ The professional obligation is unchanged and worth stating: you are responsible for code you submit, regardless of what generated it. The ACM/IEEE Software Engineering Code of Ethics requires that engineers approve software only if they have a well-founded belief it is safe and meets specifications. You cannot hold that belief about code you have not understood.
Academic integrity. ⚠ Read the syllabus carefully — policies in this subject vary more than in any other, from prohibition to required use with disclosure, and some instructors deliberately assign AI-assisted development to teach review and verification. Where use is permitted, disclose it; where it is not, note that code plagiarism detection in computing is mature and that generated code has recognisable characteristics.
⚠ One practical warning specific to team projects: a teammate who submits large volumes of generated code they do not understand creates a maintenance problem for the whole team and a review burden on everyone else. Agree a team position on AI use in week one, alongside your meeting times. It is a genuine coordination issue now, and it is better decided in advance than argued about in week twelve.
Generated September 8, 2026 · Updated September 8, 2026