Software Design and Development I

Course Description

Software Design and Development I addresses techniques used in analysis, design, and development of computer system software through data flow analysis and the system development life cycle, including traditional and object-oriented analysis, requirements analysis, specification, systems design, implementation, and maintenance.

Within the SCNS taxonomy, CEN is the Computer Systems and Software Engineering prefix. Daytona State publishes this as CEN2002 at 3 credits, offered spring.

⚠ The requirement is a prerequisite or corequisite

Daytona State states the requirement as "Prerequisite or Corequisite: (COP2800 or COP2360 or CGS2820) and COP2700" — meaning the programming and database courses may be taken in the same term as this one rather than before it. That is a genuine scheduling flexibility and it is easy to miss when reading a curriculum plan quickly. Confirm with an advisor before assuming either reading, and note that taking them concurrently is more demanding than taking them in sequence.

The reason analysis and design get a whole course before anyone writes production code is that requirements failures dominate software project failure. Projects rarely fail because a developer could not implement a specification; they fail because the specification described something nobody wanted, or described it ambiguously enough that two people read it differently. And the cost of fixing that rises by orders of magnitude the later it is caught — a misunderstanding corrected in a requirements conversation costs minutes; the same misunderstanding discovered after deployment costs a rewrite.

⚠ Two contact-hour figures apply here — make sure you use the right one

Daytona State publishes the unsuffixed form of this course at 3 credits, which at its lecture convention of 15 contact hours per credit gives approximately 45 hours — CEN4010, CEN3722, CNT2402, OST2401 and CGS1570 are all live at 3 credits and 45 hours.

The queued number carries a C suffix, which marks a combined lecture-and-laboratory course and normally implies scheduled laboratory time on top of the lecture. The figure shown in this guide is therefore priced at the combined-course convention of 20 contact hours per credit, giving 60 — the ratio this repository records consistently for C-suffixed courses across ETD, ETS, CTS and other prefixes.

⚠ Both figures are given deliberately. If you are looking at Daytona State's unsuffixed course, 45 is the figure; if you are looking at the C-suffixed course at another institution, 60 is the estimate and the offering institution's own catalog is authoritative. Confirm before relying on either.

Learning Outcomes

Required Outcomes

• Describe the system development life cycle and its phases.
• Compare life cycle models and describe when each suits a project.
• Describe agile and iterative approaches and how they differ from sequential ones.
• Elicit requirements from stakeholders using appropriate techniques.
• Distinguish functional from non-functional requirements.
• Write requirements that are unambiguous, testable, and traceable.
• Identify conflicting and missing requirements.
• Manage requirements change and describe its effect on scope.
• Perform data flow analysis and construct data flow diagrams.
• Model processes and data at appropriate levels of abstraction.
• Construct entity relationship models.
• Apply structured analysis techniques.
• Apply object-oriented analysis and identify classes and responsibilities.
• Construct use cases and describe actor interactions.
• Use UML diagrams appropriate to what is being communicated.
• Produce a specification document.
• Design a system architecture and justify its structure.
• Design modules with appropriate cohesion and coupling.
• Design user interfaces with the user's task in mind.
• Design data storage to support the required operations.
• Plan implementation, testing, and deployment.
• Describe maintenance and the majority of a system's lifetime cost.
• Estimate effort and describe why estimates are systematically optimistic.
• Document design decisions and their rationale.

Optional Outcomes

• Describe formal verification at an awareness level.
• Describe design patterns.
• Describe software quality assurance and metrics.
• Describe configuration management and version control practice.
• Describe risk management in software projects.
• Participate in a team development project.

Major Topics

Required Topics

• The system development life cycle
• Life cycle models
• Agile and iterative approaches
• Requirements elicitation
• Functional and non-functional requirements
• Writing good requirements
• Conflicting and missing requirements
• Requirements change and scope
• Data flow analysis
• Process and data modelling
• Entity relationship modelling
• Structured analysis
• Object-oriented analysis
• Use cases
• UML diagrams
• Specification documents
• Architecture design
• Cohesion and coupling
• User interface design
• Data storage design
• Implementation, testing, deployment planning
• Maintenance and lifetime cost
• Estimation
• Documenting design rationale

Optional Topics

• Formal verification
• Design patterns
• Quality assurance and metrics
• Configuration management
• Risk management
• Team project

Resources & Tools

• Build things and keep them. In computing the portfolio is the qualification — a public repository of working projects with readable code and a clear README does more for employment than a transcript.
• Git and a public repository host — free; version control is expected of every candidate, and using it from your first course is the cheapest habit to acquire.
• Free-tier cloud accounts (AWS, Azure, Google Cloud, Oracle) — real infrastructure to practise on at no cost; set a billing alert before you start.
• Virtualisation and containers — VirtualBox and Docker are free, and a broken lab you can rebuild in a minute is what makes experimentation cheap.
• Official documentation — language, database, and framework docs are authoritative and version-correct in a way that copied answers are not. Learning to read documentation is the skill that separates practitioners.
• Vendor certifications — Microsoft, AWS, Oracle, CompTIA and Cisco credentials are named by employers in job advertisements; many have free training paths and student pricing.
• Your instructors and the lab — supervised time on real systems is the part you cannot get from a video.
• Internships and co-op placements — the strongest single predictor of employment at graduation. Start looking a year before you think you should.

Career Pathways

• Software developer — SOC 15-1252.
• Computer systems analyst — SOC 15-1211; the requirements-and-design role.
• Database administrator and architect — SOC 15-1242 and 15-1243.
• Data analyst, business intelligence developer, and data engineer — strong demand and a common entry route for people who like data more than application code.
• Network architect — SOC 15-1241; and network and systems administrator, SOC 15-1244.
• Information security analyst — SOC 15-1212; strong growth, and systems or database work is the usual route in.
• Data scientist and machine learning practitioner — SOC 15-2051.
• Systems integration and enterprise applications — frequently overlooked by students and consistently well paid.
• Florida's defence, space, and simulation sector, plus healthcare, hospitality, financial services and a large public sector — ⚠ many defence roles require U.S. citizenship and some a security clearance.
• Managed service providers and consultancies — broad exposure quickly, and a common early career step.
• Continue to a bachelor's or graduate degree — Daytona State's computing bachelor's programmes are the direct route.

Special Information

⚠⚠ Requirements failures dominate project failure — and they are cheap to prevent

• The defects that cost the most are the ones introduced earliest and found latest. A misunderstanding caught in a requirements conversation costs a conversation; the same misunderstanding found after deployment costs a rewrite, and the ratio is orders of magnitude.
• ⚠ Users cannot tell you what they want in the abstract, and it is unreasonable to expect them to. They can tell you what is wrong with something you show them — which is why prototypes, mock-ups and iterations exist, and why an early ugly prototype beats a beautiful specification.
• Watch what people actually do, not only what they say they do. The documented process and the real one differ almost everywhere, and the workarounds people have invented are the requirements nobody wrote down.
• ⚠ Ambiguity is the enemy. Words like "fast", "user-friendly", "secure", and "as needed" are not requirements — if you cannot write a test for it, it is not a requirement yet.
• Ask who is not in the room. The people who will actually use the system are frequently not the people who commissioned it, and their needs are the ones missed.
• Write down the assumptions you are making, and circulate them. Assumptions that go unstated become disputes.
• Expect requirements to change, and design a process for it rather than pretending they will not. Uncontrolled change is the problem; change itself is normal.
• ⚠ Say no to scope creep explicitly, in writing, with a cost. Silent acceptance of additions is how projects die.
• Trace requirements through to tests. If nothing tests a requirement, nobody will notice when it stops working.

⚠ Most of a system's life is maintenance — design for the person who inherits it

• The majority of the total cost of a successful system is spent after it is first delivered, on maintenance, modification and support. Designing as though delivery is the end is designing for the smaller half.
• Write for the reader. Code is read far more often than it is written, and the reader is frequently you, eighteen months later, with no memory of why.
• Aim for high cohesion and low coupling. Modules that do one thing and depend on few others are the ones that can be changed safely.
• ⚠ Document the why, not the what. The code says what it does; what is lost is why that approach was chosen and what was rejected — and that is exactly what the next person needs.
• Record decisions as you make them. A short note per significant decision is worth more than a large document written afterwards.
• Prefer boring, obvious solutions. Cleverness is expensive to maintain, and the clever developer is frequently not the one maintaining it.
• Estimate honestly and pad for the unknown. Software estimates are systematically optimistic, and the parts nobody thought about are the parts that take the time.
• Design for failure. What happens when the network drops, the input is wrong, or the dependency is unavailable is part of the design, not an afterthought.

⚠⚠ The queued number carries a C suffix that Daytona State does not

• The statewide inventory carries this course as CEN2002C. Daytona State publishes it as CEN2002, titled "Software Design and Development I", with no C suffix — and the C-suffixed URL does not resolve in its catalog.
• ⚠⚠ Under Rule 22 the C suffix is part of the course number, and equivalency does not cross it. CEN2002C and CEN2002 are distinct SCNS numbers, so credit for one does not automatically satisfy a requirement written for the other.
• The suffix normally signals a combined lecture-and-laboratory structure. An institution publishing the C form may therefore run it with scheduled laboratory time and a different credit or contact-hour value from Daytona State's.
• The figures in this guide are Daytona State's. Confirm the credit value, structure, and prerequisites with the institution you are actually enrolling at or transferring to.
• Raise it in advance if you are transferring in either direction. Departments resolve this routinely when asked early and badly when asked at registration.

⚠⚠ Authorisation is the line between a computing professional and a defendant

• Never access, scan, modify, or extract data from a system you do not have permission to touch. The technical knowledge these courses give you is exactly what makes unauthorised access easy, which is why the rule matters more in this field than in most.
• Federal exposure: the Computer Fraud and Abuse Act criminalises unauthorised access to a protected computer, and "exceeding authorised access" has been read broadly.
• ⚠⚠ Florida exposure is separate and additional: the Florida Computer Crimes Act, Chapter 815, Florida Statutes, makes offences against computer users, systems and data punishable under state law independently of federal law.
• Having credentials is not the same as having authorisation. Being technically able to query a table or read a record does not mean you may, and systems log that you did.
• Use the lab and build your own. A local database, a virtual machine, or a personal cloud account costs little or nothing and lets you practise lawfully anything that would be unlawful elsewhere.
• Get scope in writing before any authorised testing or administrative engagement.
• ⚠ Rule 11 applies — computer crime and privacy law changes; verify rather than relying on a course guide.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement — and it is live here, since Daytona State offers both associate-level and bachelor of science coursework in these prefixes.

CEN2002C is published by Daytona State as CEN2002 at 3 credits and approximately 45 contact hours, offered spring.

⚠ Note both the suffix divergence and the prerequisite-or-corequisite construction — see the notes above.