topics in software engineering

University of Malta

Topics in Software

Engineering (Software Engineering II)

Software Engineering Management, Risk, Software quality

assurance, Stochastic analysis, Reliability and availability

measurement, Algorithmic estimation techniques, Real-time

systems.

This document © 2005-2008 Dr. Ernest Cachia

Faculty of ICT

Ernest Cachia

Department of Computer Science

CSA3203

University of Malta

Slide 2 of 61

CSA3170 - Unit Aims

The intention of this study unit is to introduce students to the

fundamental issues and techniques involved in the control and

estimation of quality and complexity of industry-scale software

development effort. This unit will also introduce some

advanced topics used in the modelling of reliability and

availability as well as in the development of real-time systems.

The study unit will deal with both the human and the technical

dimension of software development and will include such

issues as the scope of management, the concept of team

structure and culture, process control and measurement as

well as resource and effort estimation and quality assurance.

Ernest Cachia

Department of Computer Science Faculty of ICT

University of Malta

Slide 3 of 61

Session 1

General Refresher and Introduction

This should serve as a general reminder of what you SHOULD

already be well aware of as well as informing you of what lies

ahead. However, the road-map for this study unit is high-level

and practicality necessitates that I reserve the right to change it

within limits and as needs dictate.

Ernest Cachia


University of Malta

Slide 4 of 61

In this session

The aim of this session is to refresh some Software Engineering knowledge, at the same time introducing you to the basic scope and underlying fundamental principles of software project management. In particular:

• To get you to recognise the need for management of any human

activity that involves the construction of sophisticated, cost-

effective solutions through the collaboration of individuals.

• To extend this to incorporate software projects

• To relate the software product to the software process

• To appreciate the particularities of software project management in

the context of “traditional” management

• To isolate the criteria determining a software product and the

requirements of a development process

Ernest Cachia


University of Malta

Slide 5 of 61

Session Contents

• Modern software development

• What is a system and its development process

• Development phases and Software Development

Life-Cycles (SDLCs)

• Aspects of management

• Project properties

Ernest Cachia


University of Malta

Slide 6 of 61

Modern Software Development

• A very appropriate definition

“The multi-person construction of multi-version

software” (Parnas, D. L., Software Conference, 1987)

• The final goal of software engineering can

be seen as:

To be to build software systems of demonstrable high

quality.

Ernest Cachia


University of Malta

Slide 7 of 61

Attributes of Sound Systems

Software solutions are made up of software

systems, and a sound modern system is:

• Sophisticated

• Structured hierarchically

• Usefully observed at various levels of abstraction

• Made up of recurring components in different

configurations

• Not internally complex

• Evolved from simpler versions

• Effectively verified

Ernest Cachia


University of Malta

Slide 8 of 61

An Unsustainable Situation

• On one hand… – People build software systems using no particular method

– People build fragile software systems

– People build inaccurate software systems

– Software system development is expensive

– Software system development requires considerable planning and effort

• On the other hand… – Modern software systems are ever-increasing in

sophistication

– Demands on software systems is always rising

– Software systems are what make a computing entity

– People consciously or unconsciously rely on software for most of their social activities

Ernest Cachia


University of Malta

Slide 9 of 61

Tools

The Software Crisis

PROCESS

Q

+ Methods Q

Ernest Cachia


University of Malta

Slide 10 of 61

The “Wrongness” of Our Ways

Unmanaged development is not effective for modern system development.

- No process control

- No product or process guarantees

- No true management

- No client confidence

- No process visibility / traceability

- No metrication

- No communication

no quality!

Ernest Cachia


University of Malta

Slide 11 of 61

Phased Development

Monolithic process (?) No management potential!

Phased process

Phase “i” Phase “i+1” … Phase “n”

Milestone “i” Milestone “i+1” Milestone “n”

…

Structured & focused management

Ernest Cachia


University of Malta

Slide 12 of 61

Breaking the Monolithic Model

• Done by introducing “steps” into the software

development process.

• Steps in the development process are called

“phases” (or “stages”).

• Phases must be self contained and pre-

defined.

• Phases should decrease abstraction as they

progress.

Ernest Cachia


University of Malta

Slide 13 of 61

A Software Development Phase

A software development phase:

• Is a delimited period of time within the process

of development of a software system.

• Has a definite starting set of data and a

definite set of results.

• Is based on the results set of earlier phases.

Ernest Cachia


University of Malta

Slide 14 of 61

Advantages of Phased Development

• Phased development

– Offers benchmarking

– Offers insight

– Offers mile-stoning niches

– Offers a documentation-building framework

– Offers a definite progression sequence

– Offers possibilities for prototyping

– Allows end-user and client participation

– Offers possibilities for better testing strategies

Ernest Cachia


University of Malta

Slide 15 of 61

A Development Milestone

• A software development milestone is a scheduled event… – for which some project team member (or leader) is

accountable.

– is used to measure progress.

• A milestone typically includes: – a formal review.

– the issuance of documents.

– the delivery of a (sometimes intermediate) product.

Ernest Cachia


University of Malta

Slide 16 of 61

Typical Software Development Phases

Installation Requirements

Analysis

Feasibility

Design

Implementation

Testing

Maintenance

Retirement

Statement

Elicitation

Strategy planning

Feasibility study

Detailed

System

Integration

Component

Support

Operations

Detailed

System

Ernest Cachia


University of Malta

Slide 17 of 61

Phases and Life-Cycle

Testing

Requirements

Analysis

Design Implementation

Feasibility

Maintenance

Ernest Cachia


University of Malta

Slide 18 of 61

The Life-Cycle

As defined by the ANSI / IEEE Standard 729-1983

• A life-cycle…

– is a finite and definite period of time.

– starts when a software product is conceived.

– ends when the product is no longer available or effective

for use.

• Any life-cycle is organised in, and by implication,

composed of, phases

Ernest Cachia


University of Malta

Slide 19 of 61

Main SDLC Types

Remember these?...

Development model definition (personal): A particular interaction configuration of development phases leading to a final software product. – Waterfall (and Enhanced Waterfall)

– V-model

– Evolutionary Prototyping (aka Incremental)

– Throw-away Prototyping (aka Rapid)

– Rapid Application Development (RAD) – leading to many agile forms

– Spiral

– Reuse-oriented

– Formal (aka Transformational)

Ernest Cachia


University of Malta

Slide 20 of 61

Management in General

These life-cycles do not “simply happen” or get

used in the “right” way. They must be managed.

A possible (personal and informal) definition of

management

The strategic deployment, organisation, monitoring and

control of specific resources involved in a particular

activity.

Ernest Cachia


University of Malta

Slide 21 of 61

Why Bother Managing?

Assumption 1: Resources can be used in any

number of ways

Assumption 2: The way resources are used can

impact positively or negatively on

their efficiency

Assumption 3: The way resources are used is

entirely dependant on the way they

are managed

Therefore…

Ernest Cachia


University of Malta

Slide 22 of 61

Concluding from previous

A planned, objective and scientific approach to

resource management is of paramount importance

for the success of human effort involving multiple

resources and/or more than one person. It is therefore understood that management entails great

responsibility. Misjudgements at this level can have dire and far-

reaching repercussions.

Remember that…

Eagles may soar, but weasels don't get sucked into jet engines.

(quoted from John Benfield)

Ernest Cachia


University of Malta

Slide 23 of 61

What is to be Managed?

• This depends on the nature of what is being developed. Some examples:

• Retail outlet: stock management, accounting, etc.

• Vehicle repair: job flow, stock management, etc.

• University: lecture management, staff activity, admin., etc.

• Hospital: doctor allocation, stock management, admin, etc.

In software development, projects are managed – hence the term “project management”.

Ernest Cachia


University of Malta

Slide 24 of 61

Project Management

• First of all, what is a project? In general a planned activity – however, this is a very

subjective definition and requires further qualification

• We need to extract the main project properties to be

able to understand the nature of a “project”.

• One should keep in mind that: 1. All project properties are not necessarily present in every

project

2. Project properties can themselves be graded (i.e. not

simply considered as a “toggle” value)

Ernest Cachia


University of Malta

Slide 25 of 61

Project Properties (1/2)

So, what makes a particular activity a project?

• Is made up of, or contains some, non-routine tasks

• Can include novel approaches and/or techniques

• Necessitates a degree of planning

• The work involved is phased

• Milestones, deliverables and timescales are set

throughout

Ernest Cachia


University of Malta

Slide 26 of 61

Project Properties (2/2)

Some more project properties:

• The work involved is of a commissioned nature

• Amalgamates and brings to focus various specialities

and/or cultural backgrounds

• Work resources are pre-defined

• The work involved is large-scale and/or high-sophistication

[Some of this list is loosely adapted from Hughes & Cotterell]

Ernest Cachia


University of Malta

Slide 27 of 61

Software Project Structure

Generic software project structure

Project

System 1 System 2 System n . . .

Sub-system 1 Sub-system 2 . . .

Module 1 Module 2

. . .

. . .

Ernest Cachia


University of Malta

Slide 28 of 61

A s/w Project vs. any Project

• In the case of a s/w project…

– Progress is not always visible

– Abstraction plays a central and permeating role

– In terms of cost, s/w products are more complex than

traditional ones

– Deals in subjectivity

– Have to contend with conflicting or ill-formed requirements

– Is always expected to accommodate the physical

components of a system (i.e. is subject to change as per

design)

Ernest Cachia


University of Malta

Slide 29 of 61

Summary (Session 1)

• Modern software development needs to be collaborative,

transparent and manageable.

• A system provides a solution to a real-world issue, and is

produced as a result of a project which, in turn, has

distinguishing properties (most important of which is its sub-

division into phases).

• Software Development Life-Cycles (SDLCs) are standardised

roadmaps indicating how a project is to reach its goal. An SDLC

is made up of phases.

• Management is not simply directing. There are many tasks

associated with this generic activity.

• A software project is fundamentally different from a “traditional”

project.

Ernest Cachia


University of Malta

Slide 30 of 61

Session 2

Project Management and Risk Issues

This session should serve as an eye-opener to the issues

involved in managing software projects of certain calibre and

the importance of taking risk management seriously enough to

plan, categorise and mitigate it.

Ernest Cachia


University of Malta

Slide 31 of 61

Session Aims

The aim of this session is to introduce you to some fundamental concepts of project planning and associated risk issues. In particular:

• To make you aware that project planning is a very crucial aspect of

project management.

• To drive home the fact that planning will always entail a risk

dimension.

• To make you appreciate, analyse and categorise software

development risks.

• To acquaint you with risk mitigation.

Faculty of ICT

Ernest Cachia


University of Malta

Slide 32 of 61

Session Contents

• Management Responsibilities

• Typical project cycle

• Project Planning

• Risk management

Faculty of ICT

Ernest Cachia


University of Malta

Slide 33 of 61

Activity 1

Carry out the activity from handout “CSA3170-A” (Use the criteria explained in slides 25 & 24 from session 1)

Faculty of ICT

Ernest Cachia


University of Malta

Slide 34 of 61

Activity: “CSA3203-A”

(Adapted from Hughes)

Prioritise the following ten activities in order of merit of the description “project”.

That is, arrange the list such that the activities you consider most worthy of the

description “project” are at the top of the list in order of merit. You should write

down any reasons that may support your ordering.

• Amending a financial computer system to deal with the Euro

• Producing an edition of a newspaper

• Building the Channel Tunnel

• Planning/preparing your marriage

• A research project into what makes a good Human Computer Interface

• An investigation into the reason why a user has a problem with a

computer

• A first or second year programming assignment in a computing course

• Servicing a customer at a supermarket check-out point

• Writing an OS for a new computer

• Installing a new version of word-processor in an organisation

• Doing this task

Faculty of ICT

Ernest Cachia


University of Malta

Slide 35 of 61

Manageable components of a s/w project

How do

we do it?

Feasibility

study Plan

Project

execution

Is it worth

doing?

Do it!

Faculty of ICT

Ernest Cachia


University of Malta

Slide 36 of 61

Management Responsibilities (1/3)

Nine responsibilities are identified (over the next 3 slides)

• Planning

Deciding what to do by defining tasks, milestones,

products and meta-products

• Scheduling

Deciding when things happen by setting deadlines and

sequences

• Monitoring

Checking on progress by maintaining watch on quality,

timeliness, and cost

Faculty of ICT

Ernest Cachia


University of Malta

Slide 37 of 61


• Directing

Issuing instructions to guide development along agreed-upon lines and standards

• Controlling

Taking action whenever necessary to correct what’s being monitored if it strays from the set parameters

• Organising

Making arrangements to organise available resources to promote efficient development

Faculty of ICT

Ernest Cachia


University of Malta

Slide 38 of 61


• Staffing

Populating project development by selecting appropriately qualified and suited people and delegating them to the right jobs

• Innovating

Being able to “break the mould” whenever necessary to come up with new approaches and solutions

• Representing

Offer good project Public Relations (PR), or maybe more precisely Client Relations (CR)

Faculty of ICT

Ernest Cachia


University of Malta

Slide 39 of 61

Activity: “CSA3203-B”

(Adapted from Hughes)

Consider the following hypothetical scenario:

Joe Borg is the manager of a software development section. On Tuesday at 1000 hrs he

and his fellow section managers have a meeting with their group manager about the

staffing requirements for the coming year. Joe has already drafted a staff request

document. This document is based on the work planned for his section for the next year.

The document is discussed at the meeting. At 1400 hrs Joe has a meeting with his senior

staff about an important project his section is undertaking. One of the programming staff

has just had a road accident and will be hospitalised for some time. It is decided that the

project can be kept on schedule by some nifty rescheduling and by transferring another

team member from less urgent work to this project. A temporary replacement is to be

brought in to do the less urgent work, but this may take a week or so to arrange. Joe has

to phone both the personnel manager about getting a replacement and the client, for

whom the less urgent work is being done, explaining why it is likely to be delayed.

Identify which of the nine management responsibilities (as discussed in the lecture slides)

Joe was responding to at different points during his day. Not all the nine responsibilities

are necessarily included in the above scenario.

Faculty of ICT

Ernest Cachia


University of Malta

Slide 40 of 61

The Project Control Cycle

Collecting

data

Adapted from Hughes

Processing

data

Taking decisions

and making plans

Implementing

Defining

objectives

Modelling

Faculty of ICT

Ernest Cachia


University of Malta

Slide 41 of 61

Project Planning, Scheduling and Control

Client

Management

Developers

products

reports

controls

statistics

analysis

pro

ducts

require

ments

condu

ct

“meta” data

Software development is a set of technical activities which should be managed if they are to be effective.

Faculty of ICT

Ernest Cachia


University of Malta

Slide 42 of 61

Project Planning

• Scope of project

• Project estimates • Effort

• Cost

• Time

• Human resources

• Resource management

• Risk analysis

• Scheduling issues

• Staff organisation

All the above should be continuously monitored because project information is constantly being received as development progresses.

Faculty of ICT

Ernest Cachia


University of Malta

Slide 43 of 61

Other Project Plans

• Quality

• Configuration management

• Staff development

• Exception

• Maintenance

Faculty of ICT

Ernest Cachia


University of Malta

Slide 44 of 61

Quality Planning

In general: The setting of the stage to ensure that a standardised and quality-oriented approach to development is used throughout the organisation. Amongst other things, this plan should include:

– Reference to industry-wide standards (e.g. the ISO 9000 series)

– Management tasks and responsibilities

– Transparency (i.e. audits and visibility)

– Staff-orientation (i.e. training)

– Communication framework

– Risk management

– Inbuilt checking structure

– Documentation issues

– Development tools and methods

– Testing issues

Faculty of ICT

Ernest Cachia


University of Malta

Slide 45 of 61

Project Planning Techniques

• Option Analysis (Goal aspect) • Weighing various (sometime conflicting) goals against each other.

• Risk Management (Problem probability aspect) • Determining, analysing, planning for, and controlling unwanted

(detrimental) events.

• Milestone Setting (Product aspect) • Determination and setting of (meta) deliverables.

• Scheduling (Activity/Timing aspect) • Setting conditions for task activation and termination.

Faculty of ICT

Ernest Cachia


University of Malta

Slide 46 of 61

Risk Management

One must first understand: • What risk is

• How can one identify risk

• What types of risk are possible

• The likely sources of risk

• The likely effects of risk

• The probability and severity of a given risk

• Possible precautions and mitigating actions

Faculty of ICT

Ernest Cachia


University of Malta

Slide 47 of 61

Risk Dissection

• Risk identification

− Define the risk

• Probability (chance) of occurrence

− Subjective but can be based on solid experience

• Severity (developmental impact)

− Should be clearly discernable and prognostic

• Manageable and mitigate-able

− To what extent is it controllable?

Faculty of ICT

Ernest Cachia


University of Malta

Slide 48 of 61

Software Project Risk Types

Although risk will effect all aspects of software development,

one must determine the “point of first impact” of any particular

risk. Knowing this will help create preventive measures where it

matters. One can narrow the “point of first impact” for any

software management effort as follows:

• The product

• The project

• The business

Faculty of ICT

Ernest Cachia


University of Malta

Slide 49 of 61

Risk Classification

Risk type examples

• Changes in management: Project

• Fluctuation of requirements: Project & Product

• Staff movement: Project

• Technology shifts: Business

• Wrong usage or inadequacy of

modelling tools: Product

• Hardware resource unavailable: Project

• Competition: Business

• Problems in specification chain: Project & Product

Faculty of ICT

Ernest Cachia


University of Malta

Slide 50 of 61

Time and Cost Overrun Risks

When a software project overruns its planned delivery

time and budget, this can usually be traced back to one

of the following reasons:

– Estimation inaccuracies (could be inherent in the methods used)

– Planning assumptions

– Unforeseen events

Faculty of ICT

Ernest Cachia


University of Malta

Slide 51 of 61

Estimation Inaccuracies

Estimation methods are exactly that – an estimation. Therefore, some lack of accuracy is inherent, indeed expected. Estimation techniques are a typical “love-hate” fact associated with project management, in that:

Love them because…

• It is a forecasting tool, hence indispensible

• Can work at various levels of abstraction, hence refine-able

• Can be rendered more accurate by incorporating experience

and historical data

Hate them because…

• Can rely on some subjective data at times

• Can take on an idealistic (naïve) outlook

• It can be frustrating in their data requirements

Faculty of ICT

Ernest Cachia


University of Malta

Slide 52 of 61

Typical Project Planning Misjudgements

• Over optimistic schedule

• Stakeholder unavailability

• Resource unavailability

• Weak monitoring

• Taking a “for obvious” stance to expertise

• Letting personal views effect objectivity

• Staff augmentation (especially on an already late project)

Faculty of ICT

Ernest Cachia


University of Malta

Slide 53 of 61

Sources of Software Project Risks (1/2)

• Generic

– Applicable and common to all types of software project, but

might provide different levels of accuracy across projects

of different type

• Specific

– Applicable and more appropriate to specific types of

project, but will require closer involvement by project team

members

Faculty of ICT

Ernest Cachia


University of Malta

Slide 54 of 61

Sources of Software Project Risks (2/2)

Whatever the type of risks being considered, the following are

a list of the main risk categories that are to be considered (adapted from a generic list in Hughes):

• The nature of the application being built

• Staff morale, skills, experience, motivation and availability

• Project culture and procedure/methods

• Hardware and platform/OS requirements

• Implementation and changeover issues

• Third-party dependency

• Real-world requirement shift

Faculty of ICT

Ernest Cachia


University of Malta

Slide 55 of 61

Traditional Software Engineering Risks (Boehm, 1989)

• Personnel shortfalls

• Unrealistic schedules and budgets

• Developing the wrong software functions

• Developing the wrong user interface

• Gold plating

• Continuing stream of requirements

• Shortfalls in externally furnished components and tasks

• Real-time performance shortfalls

• Straining computer science capabilities

Faculty of ICT

Ernest Cachia


University of Malta

Slide 56 of 61

Boehm’s Risk Management Breakdown

Also known as Boehm’s “Risk Engineering” model

Faculty of ICT

Ernest Cachia


University of Malta

Slide 57 of 61

Risk Exposure

The importance attached to a particular risk is known as

risk exposure (RE). This is calculated as follows:

Risk exposure (RE) = risk probability x risk impact

Units: €/£/$/… <none> €/£/$/…

or 1 .. 10 <none> 1 .. 10

Faculty of ICT

Ernest Cachia


University of Malta

Slide 58 of 61

Risk Reduction Leverage

A measure of the balance between the perceived benefits

of reducing (or removing) a risk and the cost of doing so,

called the risk reduction cost (RRC), is called the risk

reduction leverage (RRL). This can be calculated as

follows:

RRL = (REbefore – REafter) / RRC

All units are monetary

Faculty of ICT

Ernest Cachia


University of Malta

Slide 59 of 61

Risk Control and Mitigation

Finally, one should be aware of the five techniques that are

commonly used to reduce/control risk should they occur.

• Hazard prevention The removal or rendering to insignificance the possibility of particular hazards

ever arising

• Likelihood reduction Taking every precaution to ensure that the chance of a negative event

happening is the least possible

• Risk avoidance Taking measures to ensure that the risk is not encountered in the first place

• Risk transfer The movement of a particular risk factor to other (non-project) entities

• Contingency planning What to do when the unavoidable (and some things are) happens!

Faculty of ICT

Ernest Cachia


University of Malta

Slide 60 of 61

Summary (Session 2)

• The various responsibilities (nine in all)

• The steps a typical project goes through in a real-world

context

• Risk management: Its understanding, analysis,

classification and avoidance or mitigation

Faculty of ICT

Ernest Cachia


topics in software engineering

Documents