Software Engineering

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

Programs became larger - Multiperson teams, with multiple components and may kLOC

High Complexity - complicated ideas with a large amount of detail

Evolution Expected - modelling real world processes which are dynamic & flexibility is required

Efficient - staged delivery, code reuse, lots of off the shelf software components, quality assurance, flexibility, reduced cost

Team/Multi-team - roles/responsibilities/rules /structure

Increased Usability

Requirement Engineering

Design

Implementation

Testing

Maintenance

Requirement Engineering - Requirement Specification

Design process - Design Specification

Implementation - System

Testing - Working System

A document driven and plan driven approach where milestones are marked by the appropriate documentation

Ridged and as a result indicate one stage must be completed before the next

No allowance for changing requirements, feedback or delays

A development of the simple lifecycle model which includes iteration and feedback from one stage to the next and back

A process which assures that a system meets the requirements of stakeholders/clients

i.e. is the right system being built

A process which evaluates a system to ensure it complies with quality standards, regulations and conditions - attempting to eliminate defects/bugs/deviations from specification

i.e. is the system being built right

Clear set of user requirements upfront

Costs set

Developer time more easily scheduled

Document driven so there is a clear audit trail

Document driven so there is a clear set of milestones

Inflexible so user requirements cannot change

No quick wins

Reduces innovation

No customer feedback

Testing too late

Poor at managing risks

Short 'inspect and adapt' cycles

Frequent, short feedback loops

Throw Away Prototyping - building a throw away demo and then product is built separately

Evolutionary Prototyping - use prototype to build full functionality

Difficult to plan

No guarantee an end will be reached

Architecture could get unclear

RE = Probability of a failure/loss occurring x the size/cost of the loss

A risk driven software development model with four repeating stages:

1. Determine objectives/alternatives/constraints

2. Evaluation alternatives/identify and resolve risk

3. Develop and verify product

4. Plan the next Phase

1. Risk Identification

2. Risk Assessment

3. Risk Prioritisation

4. Risk Resolution

5. Risk Monitoring

Requirements are split up into separate priority levels - high/medium/low or more

Each priority level is designed, coded and tested as a separate development cycle/stage with the highest first leaving the end of each stage with stable releasable software

An iterative and incremental software development model with each iteration viewed as a mini-project each with:

1. Requirement Analysis

2. Design

3. Implementation

4. Testing

The stage/sprint is integrated with the last.

1 - 4 Weeks

- Feedback from previous iterations & new information allows for refinement & adaption

-Frequent feedback from the customer

-Working code early in the process

-Realistic idea of progress and enables planning accordingly

-Low complexity & therefore risk

-Timeboxing increase productivity

20/80 Rule e.g. 20% of requirements take 80% of time or 20% of features are used 80% of the time

The idea that by restricting the amount of time available productivity is higher.

If time available is longer, the time required to complete tasks will expand to meet the available time.

1. Satisfy customer early and continuous development

2. Welcome changing requirements

3. Deliver working software frequently

4. Business people and developers working together

5. Motivate individuals

6. Have face to face conversations

7. Working software primary measure of progress

8. Sustainable development - maintain pace

9. Technical Excellence and good design

10. Simplicity

11. Teams are self-organising

12. Reflect on progress and tune/adjust behaviour

eXtreme Programming (XP)

Scrum

Crystal

DynamicSystems Development Methodology (DSDM)

FeatureDriven Development (FDD)

AdaptiveSoftware Development (ASD)

RationalUnified Process (RUP)

AgileModelling

LeanDevelopment

It documents the initial stage of project development.

Contents are:

1. Introduction - background/key deliverables etc

2. Process Model - (e.g. Agile/Waterfall)

3. Organisation of Project - roles/schedule

4. Standards, guidelines and procedures

5. Management Activities

6. Risks - Identification, estimate, mitigate etc

7. Staffing

8. Methods and techniques - design approach

9. Quality Assurance - Metrics

10. Work Packages - Who owns what tasks

11. Resources - hardware/software/offices etc

12. Budgeting and Schedule - network analysis

13. Changes - dependent on model

14. Delivery - handover/installation support

Indicators of progress/improvement/quality/efficiency

Lines of Code (LOC)

Effort (person-months)

Cost (£)

Pages of documentation

No. of errors

Errors per kLOC (errors per thousand lines of code)

Cost per kLOC

Errors per person-months

DRE = E/(E+D)

Where:

DRE = defect removal efficiency

E = Number of errors before delivery

D = Number of errors after delivery

Ideally, DRE = 1 or all errors should be before delivery rather than after

Conformance, C = (Number of Defects) / kLOC

Integrity

Integrity, I = SUM[1 - threat x ( 1 - security)]

Where:

threat = probability that an attack of a particular type will occur at a given time

security = probability that an attack of that type will be repelled

Probability that an attack of a particular type will occur at a given time

Probability that an attack of a particular type will be repelled

Fan In is the number of calling functions

Fan Out is the number calls

High fan in & fan out indicates high coupling and as a result complexity

Where:

Length is any measure of progress e.g. LOC

Measure of complexity of language in documentation by measuring the length of sentences and number of complex words

Gunning Fog = 0.4 x ((words/sentence)+100(complex words/words))

ES - Earliest Start

D - Duration

EF - Earliest Finish

LS - Latest Start

F - Float (Latest Start - Duration)

LF - Latest Finish

It is a Agile Technique which focuses on delivering the highest business value in shortest time

Product Owner

Scrum Master

Scrum Team - developers, UX designers, testers etc...

Define product features

Release date and content

Profitability - ROI of each story

Prioritise features

Accept/Reject results of development

Has authority over process

Enacts Scrum values and practices

Removes impediments

Ensure that their team is fully functional and productive

Enables close cooperation across all roles and functions

Shields team from external interferences

3-9 people

Cross functional - programmers, testers, UX designers etc...

Full Time members

Self Organising

Membership fixed during a sprint

Sprint Planning - decide goals/backlog/estimate

Sprint Review - Sprint Team presents what it accomplished (Product)

Sprint Retrospective - Reviews teams performance (People/Resources)

1. What did you do yesterday?

2. What are you going to do today?

3. Are the any impediments or blockers?

Team decides how to achieve sprint goals

Create the Sprint Backlog for Product Backlog

Estimate time required to complete stories from the Sprint Backlog

A presentation of the accomplishments of the sprint

A demonstration of product features

Discussion of issues encountered and solutions

Project Owner feedback

Remaining Project Backlog

Next step - Release/Sprint etc...

Inspect how sprint went in terms of people, relationships, processes and tools

Identify major items that went well & potential improvements

Create a plan for making improvements

Product Backlog

Sprint Backlog

Sprint Burndown

A list of project requirements expressed in terms of 'Value to Users' (with story points) prioritised by product owner and reprioritised at the start of each sprint

User stories to be completed during the current sprint with the Estimated remaining time complete updated daily

Chart which Indicates the progress of the sprint for each person/pair of people for each sprint task

A concise written description of a piece of functionality that will be valuable to a User (or Owner) of the software

Developers as a group/team estimate the difficulty in completing the Story by assigning points (often thought of as ideal programming days)

One method is using planning poker (cards with increasing values to indicate difficulty)

After estimating the story points, customers/product owner prioritise requirements in terms of importance/value

Independent

Negotiable

Valuable

Estimable

Brief

Testable (Acceptance Tests)

Process of determining the goals/needs/desires that a customer has for software and ensure that software will meet/exceed their expectations

Interviews

Questionnaires

Observation

Joint Application Design

Use-Case Analysis

Prototyping

ADV: Provide the best information

DISADV: Expensive

ADV: Good if wide range of users

DISADV: Often poor response rate

ADV: Accurate if done well

DISADV: Expensive

ADV: Accurate

DISADV: Away from desk therefore, expensive for both client and developer

Identify Actors

Identify Scenarios

Identify Use Cases

Refine Use Cases

Identify relationships among Use Cases

Identify non-functional requirements

Initiate uses cases - anything that needs to interact with the system to exchange information

Concrete examples of how the system will be used

Used to communicate with users about the requirements for the system

Generating descriptions of all possible behaviour in the system

Abstractions unlike scenarios which are specific

Contains the behaviour without considering how the details of the behaviour will be coded

Ensuring completeness including exceptions and error paths

Significant set of sequences of interaction between the actor and the system that yields observable results

Represents an overview of actors and behaviour of a system

Use Case diagrams do not describe the internal details of the software system

Behaviour that is used by more than one Use Case and is included in the flow of those Use Cases

Extends the behaviour of a Use Case, for exceptional or optional behaviour

Splitting requirements into separate priority levels:

Must have - top priority

o

Should have - highly desirable

Could have - if time allows

p

Won't have - not today

Given that all requirements are often not possible, priorities are based on business analysis (ROI)

Different releases can have subsets of requirements, often with reprioritisation between releases.

A product/software development requirement prioritisation model based on customer satisfaction

Requirements are split into groups, requirements which are:

Attractive (exciting) - satisfaction when fulfilled but not expected

Must-be (basic) - taken for granted - dissatisfied when not fulfilled

One-dimensional (performance) - improves satisfaction when fulfilled/ reduces satisfaction when unfulfilled

Indifferent - negligible difference in satisfaction

Reverse - the opposite to expected results

1. Developers use planning poker to assign cost/effort estimate

2. Customer assigns business value

3. Customer estimates ROI

4. Requirements sorted by ROI

Requirements are:

Readable and understandable

Non-ambiguous

Complete

Verifiable

Consistent

Modifiable

Traceable

IEEE Standard 130

System services which are expected by users

Set of constraints the system must satisfy:

Speed

Size

Ease of use

Reliability

Robustness

Portability

Inspection of the requirement specification with respect to correctness, completeness, consistency, accuracy, readability and testability

Structural Walkthrough

Prototypes

Develop a test plan

A maximally clear, complete description of WHAT is wanted by users/client

Elicitation

Specification

Validation

Negotiation

Move from a lack of detail/abstract view (Use-Case) regarding internal structure & interactions to a design which can be impletemented

Starting point for class model but

- incomplete (require more classes/attributes)

- no operations (require further behaviour - domain model likely contains just real world operations)

Object are characterised by their responsibilities:

- maintain data (attributes)

- support some processing

These responsibilities should all be closely related (cohesion)

Systems are divided up:

- with different subsystems having different responsiblities

- interfaces between each layer

An interaction diagram which shows how processes operate with one another and the order

Blueprints for constructing programs

Entity (distinguishable objects of some type with attributes) Relationship (association between 2 or more entities) modelling

Model system in terms of states and transitions between those states

The structure of a system

The behaviour of the system in operation

- Class Relationship

- Component

- Deployment

- Interaction Overview

- Object

- Package

- Activity

- Communication

- Composite Structure

- Sequence

- State

- Timing

- Use Case

A set of entities with similar attributes and behaviours

An instance of a class

Invoked when an object calls a method in another object (message passing)

A set of accessible methods

- Specialisation - Generalisation

Has-a relationship:

- Aggregation (white diamond)

- Composition (black diamond)

Specialisation - generalisation (Parent-Child)

Hierarchy - superclass & subclass

A composition relationship i.e. An object can be:

- an aggregation (made up of parts)

- composition (consist of - destroy whole, destroy parts)

1. Class Name

2. Attributes : Variable Type

3. Methods (passed arguments)

+ indicate public

- indicate private

Specialisation

Generalisation

Extension

Variance

Specification

Form of software reuse in which a new class is created by absorbing an existing class's members and embellishing them with new or modified behaviour

New class is in specialised form of the parent but satisfies the specifications of the parent in all aspects

Child class modifies or overrides some of the behaviour provided by the parent

Two classes with similar implementations such that hierarchy doesn't matter (arbitrary)

Subclasses are not just subtypes but realisations of an incomplete abstract specification

Software reusability (no need to rewrite code)

Code sharing (different projects, same code)

Consistency of interface

Software components (libraries)

Rapid Prototyping (build quickly reusing code)

Information hiding:

- limit access to data/methods

- bundling data/methods

Resuse of code without having to know specifics/internal mechanics

Process objects differently depending on datatypes therefore components are reusable

Execution Speed Slower - inherited methods which deal with arbitrary subclasses often slow than speciailised code

Coupling Increased - where one module inherits from another there is coupling

Message Passing Slower

Reduced program understanding - takes longer for programmer to understand prewritten code due to increased complexity

Noun - Class

Proper Noun - Instance

Doing Verb - operation (method)

Being Verb - inheritance

Having Verb - aggregation

Modal Verb - constraint

Adjective - attribute

Class diagram with stereotype components used to identify larger entities and their connection

Represent classes which are in a different states i.e. how the class behaviour changes with state

State diagrams represent ONE class within a class diagram - but how it's state changes throughout a program

Active State - current state

Firing - transition to another state

Triggers - events which cause a transistion between states

A class can be in multiple states at the one time i.e. superstate and substate

i.e. record player can be Not Playing & Close or Not Playing and Open

Most Efficient, maintainable, cheapest & reliable software possible

Should be modular, distinct and separable representations of procedure & data, independent and derived from the requirement specification

How well a module fits together (GOOD attribute)

How dependent one module is on another (BAD attribute)

Measure strength of interconnections between system modules

Ease of maintenance and reuse

Name of module expresses clearly what it does

Complexity of interface is reduced

Coincidental Cohesion (weak)

Logical Association (weak)

Temporal Cohesion (weak)

Procedureal Cohesion (weak)

Communication Cohesion (medium)

Sequential Cohesion (medium)

Functional Cohesion (strong)

Object Cohesion (strong)

Module parts bundled together

Elements which perform similar functions are grouped

Elements which are activated at the same time are grouped

Elements in a module constitute a single control module

All elements in a control module constitute a single control sequence

The output from one part of the module is the input to another part

Each element of a module is necessary from the execution of a single function

Each method within the module provides functionality which allows object attributes to be modified or inspected

Means a module is unlikely to affect another module

State Decentralisation (objects)

Module communication via parameters or message passing

Data coupling: Passing data from one module to another via arguments in methods

Stamp Coupling - more data than necessary passed via arguments

Control Coupling - flag passed from one module to another

Common coupling - 2 or more modules access same global data

Content coupling - call module can directly modify a data element defined internally in the called module

Security - layered architecture with critical assets in inner layers

Safety - localise safety critical features

Availability - include redundant components

Maintainability - use fine grain replaceable components

Representations of system data/service sharing, reuse and knowledge

System split into:

Model - manage system data and associated operations

View - defines and manages how user is presented with data

Controller - manages user interaction

ADV:

Allows data to change independently of its representation and vice versa

Able to present same data in different ways

DISADV:

Additional code & complexity

Organises system into layers with related functionality associated with each layer

Lowest layer represents core services used through whole system

Building new facilities on top of existing systems

If development is spread across several dev teams each responsible for a layer

Multilevel security required

Allows replacement of entire layers as long as interface is maintained

Redundant facilities can be provided to each layer to increase dependability

Clean separation is difficult - high level layer may bypass intermediate layers

Performance can be reduced due to multiple levels of interpretation of a service request

All data in a system is managed through a central repository that is accessible to all system components

Components do not interact directly - only through the repository

Use in systems which handle large amounts of data are being generated and stored for a long time

ADV

Components can be independent

All data managed consistently

DISADV

Repository is a single point of failure

Inefficiencies in routing all info through repository

Functionality separated into services with each service delivered from a separate server

Clients can use these services and access servers to make use of them

ADV

Services can be distributed across a network

General functionality can be available to all clients

DISADV

Each service is a single point of failure so susceptible to denial of service attack or failure

Performance may be unpredictable - depends on Network and OWN system

Tools/central repository which stored source code with each iteration/revision being date-stamped, commented and with ownership

Allows multiple people to work on code for a project at the same time

Changes by each person can be quickly integrated

Old versions can be retrieved in the event of code loss/bug

Automatic revision with dates

Revisions associated with programmer so traceable

Centralised Store

Historical Record

Retrieval of old versions

Parallel team development

Code synchronisation

Multiple version management

Changes associated with individuals

Only works best when users supply log of changes between revisions

Without frequent backups - no change management

Any deviation from expected behaviour

System is in a state where further processing will lead to a failure

Cause of an error

The systematic attempt to find faults in a planned way in the implemented software

Exercising and observing product behaviour (executing code)

Analysis of static system representation to discover problems (Reading source code to find issues)

Unit - Developers test individual subsystems/classes with test data

Integration - developers test groups of subsystems

System - Developers test entire systems to ensure it meets customer requirements

Acceptance - Client/Product Owner evaluate system delivered by developers - developers demonstrate software to ensure it meets the specification

Walkthrough (informal presentation)

Code inspection (formal presentation)

Automatic tools

Black box

White Box

Equivalence Partitioning

Test cases applied based off system specification

No knowledge of program

Derivation of test cases based off knowledge of program structure

Execute all program statements:

- Statement Testing (test single statements)

- Loop Testing (test loop 1, 2, ..., n times)

- Path Testing (Execute every path)

- Branch Testing (Every condition tested)

Partition inputs and outputs into equivalence sets i.e. if input between 4 and 10

input 1 number less than 4

input 1 number between 4 and 10

input 1 number greater than 10

Choose test cases based on boundary conditions

Test the failure behaviour of the system which only occur at high volume

Three types:

Bottom up

Top Down

Sandwich testing

1. Lowest layer subsystems tested individually

2. Next layer tested that call those systems

3. Repeat until all subsystems tested

Require Test Driver

DISADV

Test most important systems last

ADV

Good from integrating OO systems

1. Test top layer first (controlling layer)

2. Test each of the called systems

3. Repeat until all subsystems incorporated

Requires replacing called missing systems with stubs

DISADV

Writing stubs can be difficult

Large number of stubs to generate

ADV

Test cases defined in terms of systems

Combination of top down and bottom up testing

DISADV

Does not test all subsystems thoroughly before integration

ADV

Parallel top and bottom layer tests

Testing of complete, integrated system to evaluate the system's compliance with its specified requirements.

Function testing (Black box)

Structure testing (White box)

Performance testing (Speed and effectiveness)

Acceptance testing

Installation testing

More explicit requirements make system testing easier

Quality of use cases determines ease of function testing

Quality of subsystem decomposition determine easy of structure testing

Quality of non-functional requirements and constraints determine ease of performance tests

Stress testing (test limits - max users, peak demand)

Volume testing (large amounts of data)

Configuration testing (various software and hardware configurations)

Compatibility testing (test backward compatibility with existing systems)

Security testing (try violate security requirements)

Timing testing (evaluate response times and performance times)

Environmental testing (test tolerances for heat/humidity/motion etc)

Quality testing (reliability, maintainability and availability)

Recoverability (test response to errors)

Human factor testing (test UI with users)

Tests performed by clients/customers to ensure that it meets their interpretation of their specification/requirements

Sponsor uses software at developers site

Controlled setting with developers on hand to fix bugs

Conducted at sponsor site

Software gets a realistic workout at target environment

Potential customer might get discouraged