0707.321 Principles of Software Engineering

Chapter 3: Software Development Processes

The software development activities

1. Specification
2. Design
3. Implementation
4. Validation
5. Maintenance and Evolution

Waterfall model

A software process model, where the software development task is divided into distinct phases, each of which is completed in turn. If an error or oversite necessitates a return to a previous phase, the process continues from that earlier point.

Evolutionary development model

System is continually refined based on (continual) user input. Specification, development and testing are performed concurrently.

Incremental development model

Attempt to blend structure of waterfall-like model with flexibility of evolutionary model. System is developed incrementally (as in evolutionary model), but each generation is composed of distinct specification, development and testing phases.

Extreme Programming

Based around development and deployment of small increments of functionality. Includes notion of pair-wise programming, where actual programming is done in groups of two, to promote quality.

Spiral development model

Well-structured process model accounting for return to various tasks. Modeled as a path along a spiral, each loop traveling through four sectors: objective setting; risk assessment and reduction; development and validation; planning. Successive loops introduce more tasks.

Formal systems development

Express system as formal (mathematical) properties, which are refined through successive transformation into program.

The five stages of the software system testing process

Unit testing

The first stage of testing, where individual software components (e.g., C++ functions) are tested independently

Module testing

Where tightly-related components (e.g., C++ class and its functions) are tested as a group, independent of other modules.

Subsystem testing

Where the relationship among modules are tested, and the subsystem interfaces (in isolation from each other) exercised.

System testing

Where the entire system is assembled and validated against the system requirements (functional and non-functional). Interface mismatch problems between subsystems are also tested.

Acceptance testing

The final stage. The system is tested against data supplied by the customer (rather than the test data developed for System Testing). Problems with the system requirements may be exposed at this stage.

Chapter 5: Software Requirements

User requirement

High-level statement of requirements of system, in natural language. Must be understandable to the non-technical reader.

System requirement

More detailed and precise statements. Specifies a contract between buyer and developer.

Mandatory requirement

A requirement that must be satisfied for the system to be acceptable to the customer

Desirable requirement

A requirement that is desired, but not so critical that the system would not be accepted without it

Functional requirement

A statement of services that the system should (or should not) provide

Non-functional requirement

Constraints on services or functions offered by the system (e.g., timing constraints, development environment constraints, standards). Can be subclassified as:

Product requirement

Specify product behavior (e.g., performance, hardware requirements)

Organizational requirement

Originating in policies or procedures of customer or developer (e.g., choice of programming language, development process)

External requirement

(e.g., legal, regulatory, or ethical restrictions)

Domain requirement

Requirement (either functional or non-functional) that come from the application domain of the system, reflecting characteristics of the domain. (e.g. physical laws, regulatory standards)

Chapter 6: Requirements Engineering Processes

Software Requirements Document

A.k.a. Software Requirements Specification (SRS). The official statement of what the system developers must accomplish. Includes both user and system requirements. Read (in part) by people of different skill sets

Feasibility study

A short-term short study examining whether the project is worth doing (considering match with organizational goals, resource and technology limitations, integration with existing systems)

Requirements elicitation and analysis

Act of soliciting, collecting and organizing requirements. Can be subdivided into:

Domain understanding

Requirements collection

Requirements classification

Conflict resolution

Prioritization

Ranking requirements by importance (can help resolve conflict)

Requirements checking

Early validation (see Requirements Validation below)

Requirements specification

Documenting user and system requirements

Requirements validation

Demonstrating that requirements as a whole define the system the customer wants (validity), and that they are:

Consistent

Requirements don't conflict

Complete

Requirements cover all perceived needs

Realistic

Requirements can be satisfied with current technology and available resources

Verifiable

Requirements can be tested for

Stakeholder

Anyone who should have direct or indirect influence over the system requirements

Event scenario

Real-life example of interactions with system

Ethnographic study

Studying prospective customers to understand social and environmental requirements

Enduring requirement

Requirements deriving from core activity of system domain, and are therefore unlikely to change

Volatile requirement

Requirements likely to change while system is being developed

Chapter 7: System Models

System model

Diagrams that help in the specification of system requirements

Context model

Identifies the boundary between the system and its environment (typically, other systems)

Architectural model

Identifies the principal sub-systems of the system

Data-processing model (Data-flow diagrams)

How data is processed at different stages by the system

Composition model (Entity-Relationship diagrams)

How system entities are composed of other entities

Classification model (Class/inheritance diagrams)

How entities share characteristics

Stimulus-response model (State transition diagrams)

How the system reacts to internal and external events

Chapter 8: Prototyping

Throw-away prototype

A tool to help with the development of system requirements, the concrete artifact complementing the mental visualization. It is useful when the requirements are (initially) poorly understood.

Evolutionary prototype

Prototype developed quickly and modified as requirements are refined, ultimately becoming the production system.

Component Assembly

Prototype is built out of pre-existing components which are integrated using a common control and communications framework