Software Engineering Exam 1

Software

Computer program, config data and files, user and system documentation

Software Engineering

An engineering discipline which is concerned with all aspects of software production

Software Engineering vs Computer Science

Computer science is concerned with theory and fundamentals, whereas software engineering is concerned with practical aspects of developing and delivering software

Software Engineering Challenges

Coping with legacy systems, increasing diversity (many types of hardware/software), and with faster and cheaper hardware

Software Process

A set of activities and associated results which produce a software product. An abstract representation of a software (roadmap)

Four Fundamental Software Process Activities

1. Software Specification

2. Software Development

3. Software Validation (does what it intended to do)

4. Software Evolution (changes/maintenance)

Software Process Model

A representation of a software process from a specific perspective

Software Process Model Examples

Workflow model

Data-flow model

Role/Action model

Workflow Model

Sequence of activities in the process along with their inputs, outputs and dependencies

Data-flow Model

A set of activities that carry out some data transformation (input→ output)

Role/Action Model

Represents roles of people involved in the software process and activities for which they are responsible

Software Development Models

The Waterfall Approach

Evolutionary Development

Formal Transformation

System Assembly From Reusable Part

Incremental Method

Waterfall Approach

Complete one phase (req, design, code, test) before going to the next. Also referred to as “Life-cycle” conducted in five stand-alone phases

Five Phases of Waterfall

1. Requirements

2. Software Design

3. Code & Unit Test

4. Integration & Testing

5. Maintenance

Advantages of Waterfall

Simple to follow

Simple to track progress

Good structural design

Disadvantages of Waterfall

Phases often overlap

Hard to modify and implement changes

Need to complete requirements from customers to start (biggest challenge)

Evolutionary Development

Develop an initial implementation, expose to users comments, refine until satisfied (Build quick, modify, and redo component until completion)

Two Types of Evolutionary Development

Exploratory Development

Throw-away Prototyping

Exploratory Development

Start with requirements that are well defined and add new features when customers propose new requirements

Throw-away Prototyping

Under customer requirements, use prototyping to focus on poorly understood requirements, redefine as you progress

Evolutionary Development Advantages

Happier customers (you’re helping them define requirements)

Flexibility in modifying requirements

Evolutionary Development Disadvantages

Hard to trace the process, not cost-effective

Formal Transformation

Transformation specifications, using mathematical methods, to a program; guarantee correctness

Reuse-oriented Development

Relies on a large base of reusable software components. Design systems to capitalize on the existing components

Reuse-oriented Development Advantages

Reduced cost and risk

Fast Delivery

Incremental Method

A hybrid model where the software specification, design, implementation, and testing is broken down into a series of increments which are developed and delivered

Incremental Development Advantages

Products delivered incrementally hence faster

Lower risk of overall project failure

Spiral Development

A hybrid model where the development of the system spirals outward from an initial outline through to the final developed system. Each loop represents a phase

Four Spiral Development Loop Sectors

1. Object Setting

2. Risk assessment

3. Development and validation

4. Planning

Spiral Loops: Object Setting

Set specific object for that phase

Spiral Loops: Development and validation

Select a development model based on risk levels

Spiral Loops: Planning

Decide if a next loop is required

Attributes of Good Software

Maintainability

Dependability

Efficiency

Usability

Ethical Responsibility

Confidentiality

Competence

Intellectual Property

Computer Misuse

Software Validation Activities

1. Unit testing

2. Module testing

3. Sub-system testing

4. System testing

5. Acceptance testing

Computer-Aided Software Engineering (CASE)

Software used to support software process activities such as requirements engineering, design, program development and testing

Computer-Aided Software Engineering Examples

Design editors, compilers, data dictionaries, debuggers, etc

Reason Software Management More Difficult Than Other Engineering

Software product is intangible

There are no standard software processes

Software project are usually different from previous projects

Stages for Managing Risks

1. Risk Identification

2. Risk Analysis

3. Risk Planning

4. Risk Monitoring

Three Types of Software Requirements

Functional

Non-Functional

Domain

Functional Requirements

Describe system services or functions. Services the system should provide

Non-Functional Requirements

A constraint on the system or on the development process. (speed, time to market)

Domain Requirements

Related to the application domain of the system (may be functional or non-functional) (What happens to fiber optics line in case of sever weather during winter?)

System Requirements

Structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor

Software Specifications

A detailed description which can serve as a basis for a design or implementation. Written for developers

User Requirement Targets

Client Managers

System End-Users

Contract Managers

System Architects

System Requirements Targets

System End-Users

Client Engineers

System Architects

Software Developers

Software Specification Targets

Client Engineers

System Architects

Software Developers

Non-Functional Requirement Classifications

Product Requirements (Efficiency, reliability…)

Organizational Requirements (Delivery, Implementation…)

External Requirements (Ethics, Safety…)

Alternatives to NL Specification (Natural Language)

Structured Natural Language

Program Description Language

Use-Cases

Mathematical Specification (finite-state machines)

Program Description Language

Defined operationally using a language like a programming language but with more flexibility of expression

When Appropriate to Use PDL

Where an operation is a sequence of actions and the order is important

When hardware and software interfaces have to be specified

(ATM machine)

PDL Disadvantages

Not sufficiently expressive to express system functionality in an understandable way

Only understood by programmers

Requirement Documents

The official statement of what is required of the system developers. Should include both a definition and a specification of requirements. (WHAT the system does not HOW it should)

Requirements Engineering Processes

Requirement Elicitation

Requirement Analysis

Requirements Validation

Requirements Management

Ethnography

An Observational technique that can be used to understand social and organizational requirements

Enduring Requirements

Stable requirements derived from the core activity of the customer organization (hospitals will always have doctors and nurses)

Volatile Requirements

Requirements which change during development or when the system is in use (requirements from health-care policy)

Classification of Requirements

Mutable

Emergent

Consequential

Compatibility

Mutable Requirements

Requirements that change due to the system’s environment

Emergent Requirements

Requirements that emerge as understanding of the system develops

Consequential Requirements

Requirements that result from the introduction of the computer system

Compatibility Requirements

Requirements that depend on other systems or organizational processes

UML

The standard language for specifying, visualizing, constructing, and documenting all the artifacts of a software system

Activity Diagrams shows:

Flow of control

Swimlanes

Shows ownership. Clearly illustrates to what group is responsible for what activity

Actor

Someone (or thing) that is external to system that must interact with the system

Use Case

A sequence of related transaction performed by an actor in the system (Ovals)

Use Case Diagrams

Created to visualize the relationship between actors and use cases

Sequence Diagram

Displays object interactions arranged in a time sequence

Collaboration Diagram

Displays object interactions organized around objects and their links to one another

Class Diagram Components

Class name - first component

Attributes (structure) - second component

Operations (behavior) - third component

Three Types of UML Relationships

Association (line)

Aggregation (closed diamond)

Dependency (open diamond)

Association

Bi-directional connection between classes (line) (i know you’re there)

Aggregation

Stronger form where the relationship is between a whole and its parts (closed diamond)

Dependency

Weaker form showing the relationship between a client and a supplier where the client does not have semantic knowledge of supplier (open diamond) (i need you, but don’t know you exist)

Model Types

Context

Behavioral

Semantic Data

Object

Context Model

Illustrate the operational context of a system (what lies outside the system boundaries)

Behavioral Model

Describes the overall behavior of a system

Two Types of Behavioral Models

Data Processing - how data processed through system

State Machine - shows the systems response to events

Semantic Data Models

Describe the logical structure of data processed by the system (widely used in database design)

Object Models

Natural ways of reflecting the real-world entities manipulated by the system

Architectural Design

The design process for identifying the sub-systems making up a system and the frameworks for sub-system control and communication

Software Architecture

The output of the architectural design process

Two Widely Used Organizational Models

Data Repository

Client-Server

Data Repository Model

Sub-systems must exchange data. Shared data is held in a central database and may be accessed by all sub-systems (used when there’s a large amount of data)

Client-Server Model

Model which shows how data and processing is distributed across a range of components. Servers provide services. Client call these services

Object Models

Structure the system into a set of loosely coupled objects with well-defined interfaces

Verification

“Are we building the product right”

The software should conform to its specifications

Validation

“Are we building the right product”

The software should do what the user really requires

Software Inspections

Examining to find anomalies and defects without execution of system. (functional characteristics only (not performance etc))

Software Testing

Concerned with exercising and observing product behavior

Inspection Roles

Code Author / Owner (2x)

Code Inspectors (2x)

Reader & Sciber (1x)

Session Moderator (1x) (HR)

Static Analysers

Software tools for source text processing. They parse the program text and try to discover potential erroneous conditions and bring these to the attention of the V&V team

Cleanroom Software Development

The philosophy is defect avoidance rather than defect removal (solve before it becomes a problem)

Cleanroom Process Teams

Specification - developing and maintaining system specs

Development - developing and verifying hardware (not compiled)

Certification - developing statistical tests to exercise software

Two Phases of System Testing

Integration Testing

Release Testing

Integration Testing

The system is tested as components are integrated

Release Testing

The test team tests the complete system to be delivered as a black-box. Testing a release of a system that will be distributed to customers. (USUALLY A BLACK-BOX)

Stress Testing

Exercises the system beyond its maximum design load. Causing defects to come to light