General Format and Scope

Format. The exam will consist primarily of short answer questions along with a few true/false or multiple choice questions.
Scope. The exam will focus on the lecture notes and in-class discussion. This is backed-up by your readings in Schach as well as your preparation and learning experiences from the first three assignments.
NOTE: this review sheet is not a substitute for looking at the notes!

Specific Materials Covered

1. Lecture Notes: topics 1 though 7.

2. Assignments one, two and three.

3. Readings from Schach text: specified sections of the following chapters:

• chapter 1
• chapter 2
• chapter 3
• chapter 5
• chapter 9
• chapter 10, sections 1-7 & 11-13
• chapter 13, sections 9 & 11

4. Readings from Mythical Man-Month, first half

Software Engineering Scope

Software engineering is multi-person construction of multi-version software.

Software costs and problems: typically delivered late, over budget, and faulty.

Software engineering attempts to provide the tools to consistently fashion software to solve appropriate problems in an orderly, predictable manner.

Software development requires a broad range of skills; systems are too complex to be developed by an individual.

Requirements must address all of user needs; design decomposition is critical to mastering complexity.

Testing and maintenance costs are outrageously high, addressed in part by lifecycle validation, test planning, and anticipating change.

Software is unique.

Software Engineering Principles

Software Qualities

Software Production

Basic phases: requirements analysis and specification, architectural and detailed design, implementation and integration, operation and maintenance.

Software lifecycle consists of phases, intermediate products, and reviews.

Build and Fix approach is not a lifecycle model.

Stagewise and Waterfall lifecycle models develop software in successive phases.

The spiral model is a metamodel guided by risk assessment.

A software process is a device for producing a software product; a software process description can be multiply instantiated.

Lifecycle V&V

Validation is comparison to [informal] user needs, while verification is comparison to a produced [formal] specification.

Test planning must determine what properties should be tested, who should perform the testing, when does testing stop.

Testing should be done in phases that roughly correspond to the development phases, where planning for each testing phase should be done in the corresponding development phase. Testing phases are performed in reverse order of the development phases.

Lifecycle reviews can be done at any phase. Walkthroughs are a two-step process, while inspections are a five-step process.

Cleanroom is the ultimate lifecycle review process.

Prototyping and Scenarios

Prototyping and scenario building are knowledge acquisition activities.

Both are mockups of the eventual software product, which help to ensure that the users and client play an active role in requirements analysis so that their needs are elicited.

A rapid prototype is a hastily coded (read hacked up), executable software mockup that exhibits some key functionality.

Scenarios are typically user interaction mockups, a series of diagrams depicting a series of events and the reaction of the system.

Mockups demonstrate the behavior of the system in a way eventual users can comprehend.

Mockups in requirements analysis address completeness, adequacy, usability, consistency, feasibility.

Mockups are especially useful in exploratory programming and prototyping software lifecycle models.

Prototyping can be done throughout the lifecycle: from analyzing and acquiring requirements knowledge, to take the place of the requirements specification, to evaluating design alternatives, to providing an initial implementation that is refined. Which are good uses?

Prototyping tools include: executable specification languages, very high-level languages, 4th generation languages, graphical user interface toolkits, domain-specific application generators.

Cognitive Walkthroughs help to "test" the usability of an interactive system by evaluating the mockup on sample human-computer interactions. The focus is on the tasks and interface and analyzing usability attributes such as learnability, efficiency, memorizability, error recovery, user satisfaction.

Requirements Analysis and Specification

Requirements analysis addresses client/users' needs, considers both functional and non-functional requirements, and develops a contract between client and developer.

Requirements state what and not how. A requirements specification should be abstract, complete, consistent, unambiguous, precise, feasible, even, modifiable, reference tool. Each of these present common problems in requirements specification.

Requirements specification components (purposes, desirable characteristics)

• description/background
• functional
• environmental
• performance
• accuracy
• robustness
• security
• safety
• timing

Requirements analysis techniques range from interviews to system modeling; the important thing to remember is that the client is in charge while the developer learns and organizes.

Acceptance test plans are developed during requirements analysis; system test plans, which are more comprehensive, are developed during refinement of the requirements specification.

Requirements Specification Models

System models enable understanding by abstractly describing the system in a notation the user can also comprehend.

Structured Systems Analysis is a structured (semi-formal), graphical technique with a functional perspective based on hierarchical dataflow diagrams.

Entity-Relationship Models are a structured (semi-formal), graphical technique with a data orientation that is often used to supplement dataflow diagrams.

Finite state machines are a [semi-]formal, graphical technique based on specifying states and transitions between states.

Petri Nets are a formal, graphical technique that provides the capability to specify synchronization and timing for concurrent and real-time systems.

Use Cases are descriptions of a small task the user (actor) would do when using the system, often corresponding ot a feature of the system.