Software EngineeringSoftware Engineering

Summary

The Nature of SoftwareThe Nature of Software

Software is a set of items or objects that form a “configuration” that includes: Programs Documents Data

Software Characteristics: Software is developed or

engineered, rather than being manufactured.

Although the industry is moving toward component-based assembly, most software continues to be custom built.

Software doesn’t wear out. Software is complex.

The ProductThe Product

Software Myths: Managers are under pressure, tend to grasp at myths.

Myths held by customers often lead to false expectations and, ultimately, dissatisfaction.

Early attitudes to programming have become entrenched among practitioners.

Professional and ethical responsibilities: Software engineering involves wider responsibilities

than simply the application of technical skills.

Confidentiality, competence, intellectual property rights, computer misuse.

The ProcessThe Process

Software Engineering defined: The establishment and use of sound engineering principles in order

to obtain economically software that is reliable and works efficiently on real machines.

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Generic Phases: Definition (“what”): Establish what the requirements of the system

are. Development (“how”): Establish how the system is to be realized –

design and build Support: Handle changes as the software environment evolves

This process is complemented by a number of umbrella activities.

Process ModelsProcess Models

A framework of tasks applied during software engineering: Linear (Waterfall): Based on conventional engineering

Prototyping: Build a system to clarify requirements

Rapid Application Development (RAD): Well defined 60-90 day projects

Incremental: Deliver increasing functionality at each iteration

Spiral (Boehm): Similar set of tasks applied for each turn of the spiral.

Component based: Aimed at producing and reusing OO components

analysis design code test

AnalysisAnalysis

analysis design code test

Process Model Output

1. Elicit customer requirements and identify use-cases

Use-Case Diagrams

2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy

Class Responsibility Collaborator (CRC) Cards

3. Build an object-relationship model (structural)

Conceptual Class Diagram

4. Build an object-behaviour model (dynamic)

Interaction and State Diagrams

Analysis PrinciplesAnalysis Principles

begin by focusing on the essence of the problem without regard to implementation details

Examine “What” rather than “how” Understand the problem before you begin to create the

analysis model. Develop prototypes that enable a user to understand how

human-machine interaction will occur. Record the origin of and the reason for every requirement. Use multiple views of requirements. Prioritize requirements. Work to eliminate ambiguity. (Primary advantage of

Formal Mathematical Specification)

Use Case DiagramsUse Case Diagrams

Graphically shows use-cases, actors and their relationships.

Use CaseCommunication

Relationship

Actor

Analyze Risk

Trader

Price Deal

Capture Deal

Valuation

Limits Exceeded

<<extends>>

<<uses>>

<<uses>>

Uses Relationship

Extends Relationship

Class Responsibility Collaborator Class Responsibility Collaborator CardsCards

Benefits: They are portable. No computers are required so they can be used

anywhere. Even away from the office.

They allow the participants to experience first hand how the system will work.

Stages: Identify potential classes with a grammatical parse for nouns.

Apply a set of requirement to determine acceptable classes.

Determine class types, characteristics, responsibilities (attributes and methods) and collaborators.

Do a CRC review (walkthrough) of the model.

Example: CRC CardExample: CRC Card

class name: Sensor

class type: external entity

class characteristics: tangible, atomic, concurrent, guarded

responsibilities: collaborators:

keep sensor informationassign sensor informationsignal sensor event

Class DiagramsClass Diagrams

Descendent of Entity-Relationship Diagrams Show the static structure of the model

the entities that exist internal structure relationship to other entities

Static View Do not show temporal information

Used in both analysis (conceptual) and design (specification and implementation).

Conceptual class diagrams only require a subset of the full UML notation.

Derived from CRC Cards.

Example: Class DiagramExample: Class Diagram

Class

Association

Label and Navigability

Multiplicity

system

audible alarm

control panel sensor

sensor event

contains polls

recognizes produces

1 1 1 1..*

1

*

1

*

Object-Behavioural ModellingObject-Behavioural Modelling

CRC and object-relationship model static Object-behaviour model dynamic (function of

specific events and time) Process:

1. Evaluate use-cases to understand the sequence of system interaction

2. Identify events that drive the interaction sequence and relate these to specific objects

3. Create an interaction diagram for each use-case

4. Build a state diagram for the system

5. Review model to verify accuracy and consistency

Sequence DiagramsSequence Diagrams

Homeowner Control Panel

System

system ready

enters password

ready for activation/deactivation

selects stay or away

ready for next action

initiates beep

activate/deactivate sensors

red light on request

Object

Life Line

Active Event

Collaboration DiagramsCollaboration Diagrams

Objects are shown as icons, arrows indicate messages and sequence is indicated by a decimal numbering scheme.

Otherwise similar to sequence diagrams

Example:

HomeownerControl Panel System

1: enters password

1.2: ready for (de)activation

2: selects stay or away

2.3: ready for next action

1.1: initiates beep

2.1: activate/deactivate sensors

2.2: red light on request

State DiagramsState Diagrams

stop

/ctr := 0stop [user quits]

Final State

Done

Ready

Transition

Initial Pseudostate

Action

Event

State

Guard

Design SummaryDesign Summary

analysis design code test

Process Model Output

1. Subsystem Design: partition the system into components

A Package Diagram

2. Class and Object Design: define class hierarchies

Specification Class Diagram

3. Message Design: convert the object-relationship model into a set of class messages

Message Descriptions

4. Responsibility Design: specify the internal structure of classes

Specification Class Diagram with full attribute and method syntax

C++ Class Headers

Design ConceptsDesign Concepts

Abstraction: Enables a problem to be addressed at a high-level of generalization without worrying about low-level details.

Refinement: Process of gradual top-down elaboration of detail.

Abstraction and refinement are complementary. Modularity: Software subdivided into separately named and

addressable components. Coupling: The degree to which a module is connected to other

modules in the system. Cohesion: The degree to which a module performs one and

only one function. Information Hiding: Portions of the internal structure of a

component are hidden and inaccessible from outside.

OO DesignOO Design

Object-relationship

model

Object-BehaviorModel

CRCIndex Cards

Attributes, operations,collaborators

THE ANALYSIS MODEL

responsibilitiesdesign

messagedesign

Class and objectdesign

subsystemdesign

THE DESIGN MODEL

Use cases

Testing SummaryTesting Summary

analysis design code test

Process Technique

1. Class Testing: test methods and state behaviour of classes

Random, Partition and White-Box Tests

2. Integration Testing: test the interaction of sets of classes

Random and Behavioural Testing

3. Validation Testing: test whether customer requirements are satisfied

Use-case based black box and Acceptance tests

4. System Testing: test the behaviour of the system as part of a larger environment

Recovery, security, stress and performance tests

White-Box TestingWhite-Box Testing

Goal: Ensure that all statements

and conditions have been executed at least once

Derive test cases that:1. Exercise all independent

execution paths

2. Exercise all logical decisions on both true and false sides

3. Execute all loops at their boundaries and within operational bounds

4. Exercise internal data structures to ensure validity

Black-Box TestingBlack-Box Testing

Complementary to white box testing. Derive external conditions that fully exercise all functional requirements

requirementsrequirements

eventseventsinputinput

outputoutput

Class TestingClass Testing

Smallest testable unit is the encapsulated class (a single operation needs to be tested as part of a class hierarchy)

Approach: methods within the class are tested

the state behavior of the class is examined

Unlike conventional unit testing which focuses on input-process-output, class testing focuses on designing sequences of methods to exercise the states of a class

Integration TestingIntegration Testing

OO does not have a hierarchical control structure so conventional top-down and bottom-up integration tests have little meaning

integration applied three different incremental strategies thread-based testing: integrates classes required to respond to one

input or event

use-based testing: integrates classes required by one use case

cluster testing: integrates classes required to demonstrate one collaboration

Validation TestingValidation Testing

Are we building the right product? Validation succeeds when software functions in a manner that can be reasonably expected by the customer.

Focus on user-visible actions and user-recognizable outputs

Details of class connections disappear at this level Apply:

use-case scenarios from the software requirements spec black-box testing to create a deficiency list Acceptance tests through alpha (at developer’s site) and

beta (at customer’s site) testing with actual customers

System TestingSystem Testing

Software may be part of a larger system. This often leads to “finger pointing” by other system development teams.

Types of System Testing: Recovery testing: how well and quickly does the system

recover from faults Security testing: verify that protection mechanisms

built into the system will protect from unauthorized access (hackers, disgruntled employees, fraudsters, etc)

Stress testing: place abnormal load on the system Performance testing: investigate the run-time

performance within the context of an integrated system

Project ManagementProject Management

An umbrella activity.

Planning, organizing, controlling and monitoring software development.

Elements of Project Management (the 4 P’s): Product (the software to be built)

Process (the set of framework activities and software engineering tasks to get the job done)

People (the most important element of a successful project)

Project (all work required to make the product a reality)

Tightly interrelated (each depends on the other)

MetricsMetricsAgainst:

Collecting metrics is too hard ... it’s too time consuming ... it’s too political ... they can be used against individuals ... it won’t prove anything

For:

In order to characterize, evaluate, predict and improve the process and product a metric baseline is essential.

“Anything that you need to quantify can be measured in some way that is superior to not measuring it at all”

A good manager measures.

Some Important Metrics and Some Important Metrics and MeasuresMeasures

Defect Removal Efficiency: Relationship between errors (E) found during software

development and defects (D) found after release. The ideal is a DRE of 1

Lines of Code (size oriented): errors per KLOC (thousand lines of code), defects per KLOC, R

per LOC, page of documentation per KLOC, errors / person-month, LOC per person-month, R / page of documentation

Function Point (complexity oriented): errors per FP, defects per FP, R per FP, pages of documentation

per FP, FP per person-month

Quality Oriented: less tangible aspects such as correctness, maintainability, usability,

integrity.

)/( DEEDRE

McCall’s Triangle of QualityMcCall’s Triangle of Quality

PRODUCT TRANSITIONPRODUCT TRANSITIONPRODUCT REVISIONPRODUCT REVISION

PRODUCT OPERATIONPRODUCT OPERATIONCorrectness

Reliability

Usability

IntegrityEfficiency

Maintainability

Flexibility

Testability

Portability

ReusabilityInteroperability

Object Oriented MetricsObject Oriented Metrics

The following characteristics require that special OO metrics be developed: Encapsulation—the packaging of data and processing. Concentrate on

classes rather than functions or data structures. Example: Class size (total number of methods and attributes)

Encapsulation— the way in which information about operational details is hidden by a secure interface. Example: Percent public and protected.

Inheritance—the manner in which the responsibilities of one class are propagated to another. A pivotal indication of complexity. Example: Number of children.

Abstraction—the mechanism that allows a design to focus on essential details. Metrics need to measure a class at different levels of abstraction and from different viewpoints.

Project PlanningProject Planning

Scope—understand the problem and the work that must be done. Estimation—how much effort? how much time? Risk—what can go wrong? how can we avoid it? what can we do

about it? Schedule—how do we allocate resources along the timeline?

what are the milestones? Control strategy—how do we control quality? how do we

control change?

SoftwareProject

Plan

Project ScopeEstimatesRisksScheduleControl strategy

EstimatesEstimates

Project scope must be explicitly defined. If not, the project may be infeasible.

Task and/or functional decomposition is necessary. Historical measures (metrics) are very helpful. Triangulation: At least two different techniques should be

used. Remember that uncertainty is inherent in early estimates. Techniques:

1. Delay estimation until late in the project (not advisable)

2. Base estimates on similar projects that have already been completed.

3. Use relatively simple decomposition techniques (LOC or FP).

4. Use one or more empirical models for software cost.

RISK

RisksRisks

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack

Look for potential risks due to product, process, business, technology, people

Estimate probability and impact

mitigation, monitoring and management plans

ScheduleSchedule

Definition: Once the scope, process model, work estimates and deadline are in place the schedule is used to connect them into a network of SE tasks.

Many SE tasks can be undertaken simultaneously (parallelism) and some may have a profound effect on subsequent tasks (dependency). Difficult to manage without a schedule.

Once a task network showing parallelism and dependency has been created CPM and PERT can be applied and a schedule produced.

Earned Value Analysis is used to track adherence to the schedule.

90-90 Rule. The first 90% of a project is complete in 90% of the scheduled time. The other 10% is also completed in 90% of the time.

Software Quality AssuranceSoftware Quality Assurance

Aspects of SQA:1. Software requirements are the foundation from which quality is

measured. Lack of conformance to requirements is lack of quality.

2. Specified standards must be followed.

3. A set of implicit requirements often goes unmentioned (e.g. ease of use). If software conforms to explicit requirements but fails to meet implicit requirements, software quality is suspect.

Formal Technical Reviews: Principal SQA activity

Can be up to 75% effective in uncovering design flaws (which cover 50-65% of all errors)

Software Configuration ManagementSoftware Configuration Management

Identification: Software Configuration Items (SCI) must be separately named and related.

Version Control: recording different versions of an SCI.

Change Control: managing the way in which changes are carried out using a check-in check-out procedure

Auditing and Reporting: making sure that change is properly implemented and accounted for.

Software EngineeringSoftware Engineering

a TQM foundation

procedures

methods

tools

SCMSCM• identification• version control• change control• auditing• reporting

Exam StructureExam Structure

100 marks in 3 hours (1 mark every 1.8 minutes): Each question counts 10 marks

Software Engineering (answer 4 out of 5 questions) Counts 40%

Covers entire course (no spotting!)

Mix of practical and theoretical questions

Human Computer Interaction (answer 2 out of 3 questions)

Architecture (answer 4 out of 5 questions)