CMSC 435: SOFTWARE ENGINEERING

Catalog Description

A study of processes and design methods behind the engineering of software applications. Laboratory experience in applying the techniques covered. Product assurance, specification and design techniques, iterative enhancement, design and code inspection techniques, correctness, development tools. The development of a large software project.

Prerequisites

CMSC 330.

Topics

Motivation --- Why SE instead of ad hoc techniques?
Terminology; Introduction to process models and configuration management
Basic principles of quality assurance and risk reduction
Requirements capture and analysis
Specification and design techniques
Implementation issues
Unit test techniques
System integration and testing techniques
Correctness; Verification
Support tools and automated systems; CASE tools
Measurement and costing issues; Planning and scheduling
Standards
Human factors
Maintenance

Course Text

Carlo Ghezzi, Mehdi Jazayeri and Dino Mandrioli, Fundamentals of Software Engineering, Prentice Hall, 1991.
Bryan and Siegel, Software Product Assurance: Techniques for Reducing Software Risk, Elsevier, 1988.
Barnes, Programming in Ada, Addison Wesley, Third Edition, 1989.

Typical Grading and Workload

The class will be divided into teams of three and four students each. On the first day of class, all students will be given an initial set of `customer generated' requirements for a desired system. The system has several major phases that must be completed, and there is a deliverable associated with the end of each phase. (These phases are requirements analysis, initial design and specification, implementation and unit testing, and system integration.) However, whereas each team will undertake all phases, each phase will be performed on a different component from the overall application, e.g., each team will write a requirements document for the first component, do initial design and specification for the second component, and subsequently implement the third component. Finally, each team is responsible for providing support during system integration. In this way, team members gain experience in having to manipulate software items that they did not themselves create. To accomplish this, the `deliverables' from each phase will be redistributed among teams following each phase. Changes in the materials given out after each phase can only be approved by a class-run configuration review board, which will only consider requests made in writing and is likely to make judgements on a weekly basis.