Software

Engineering
Introduction

06/30/09

Mzuzu university

Topics
Understanding software
Issues in software industry
Software engineering concepts
Ethics in software engineering

06/30/09

Mzuzu university

software
Software is a combination of
computer program
data
documentation(system,user)

Types of software
Generic
Custom
Embedded

06/30/09

Mzuzu university

Categories of Software
By development
Generic
Custom
Embedded

Processing focus
Data processing-Transforming,arranging and storing
data
Real Time Processing-Control processes/devices in
real time

06/30/09

Mzuzu university

Issues in software
System Software
Application software
Embedded software
Product Line Software
Web Applications
Artificial Intelligence
Scientific software
Net Sourcing
Open source
Ubiquitous computing
06/30/09

Mzuzu university

Software Crisis
was used to describe the impact of rapid increases in
computer power and the complexity of the problems which
could be tackled.
It refers to the difficulty of writing correct, understandable, and
verifiable computer programs.
The root causes complexity, expectations, and change.

06/30/09

Mzuzu university

Software Crisis
Symptoms
Unmanageable
Over budget
Late
Poor quality

06/30/09

Mzuzu university

Software Engineering
Advances in hardware capability have enabled increasingly
complex software. Our ability to intellectually manage this
complexity has always lagged the advances in software
complexity.
Software engineers continually require better tools.
CASE (Computer Assisted Software Engineering) tools.
Intellectual tools -- Software engineering techniques.

06/30/09

Mzuzu university

Definition
The establishment and use of sound engineering
principles in order to obtain economically software that
is reliable and works efficiently on real machines. (Fritz
Bauer, at the First NATO Conference on Software
Engineering, 1969)
engineering principles - it is a disciplined effort
economically ... reliable .... efficiently ... it has built in
quality
real machines solves a user problem

06/30/09

Mzuzu university

SOFTWARE ENGINEERING IS ...

engineering principles
It is a disciplined effort that:
systematically uses methodologies, techniques and tools, and a
store of relevant knowledge, architectures and components
uses a modular approach to system building
applies appropriate project management techniques
economically...reliable...efficiently
It has built-in quality that:
Meets cost, time and other constraints has meaningful quality
assurance (e.g., standards
does formal testing of modules and the system as a whole
real machines
It solves a real user problem (implied), therefore:
development is focused on meeting user requirements

06/30/09

Mzuzu university

10

Goals of software Engineering

Maintainability the ability to easily make changes, enhancements, or
improvements.
Dependability the ability to rely on the software to function properly
when needed.
Efficiency the ability for software to use computing resources
effectively (mainly space and time).
Usability the ability for the end user to easily and effectively put the
software to proper use.

06/30/09

Mzuzu university

11

Principles of software engineering

Modularity divide and conquer.
Encapsulation hide the implementation.
Localization collect similar things together.
Abstraction provide an illusion.
Uniformity make everything look similar.
Completeness do everything required.
Confirm ability be able to prove that the software
works properly.

06/30/09

Mzuzu university

12

Software Engineering Ethics

Principles
Public
S/w engineers shall act consistently with the public
interest.

Client and employer

S/W engineers shall act in a manner that is in the best
interests of their client and employer and that is
consistent with the public interest.
Product

s/w engineers shall ensure that their products and

related modifications meet the highest professional

standards possible.

06/30/09

Mzuzu university

13

Software Engineering Ethics

Principles
Judgement
S/W engineer shall maintain integrity and
independence in their professional judgement
Management

S/W engineer managers and leaders shall subscribe to

and promote an ethical approach to the management

of s/w development and maintenance.
Profession
S/W engineers shall advance the integrity and
reputation consistent with the public interest.

06/30/09

Mzuzu university

14

Software Engineering Ethics

Principle
Colleagues
S/w engineers shall be fair to and supportive
of their colleague.

Self
S/W engineers shall participate in lifelong
learning regarding the practice of the
profession and promote an ethical approach
to the practice of the profession.

06/30/09

Mzuzu university

15

Summary
Software engineering involves modelling and
documenting system requirements and solutions.

06/30/09

Mzuzu university

16

Software
Software Engineering
Engineering

Software
Software Process
Process

06/30/09

Mzuzu university

17

Software Process
Objectives
Understanding software process
Activities present in every software
process
Process models, and their strengths and
weaknesses

06/30/09

Mzuzu university

18

Process Model
A software process model is an
abstract representation of the
development process.
Consists of a structured set of activities
required to build software.
It presents a description of a process
from a particular perspective.

06/30/09

Mzuzu university

19

Types of Models
Descriptive
Describes the history of how a particular
system was developed.
Used as a basis for understanding and
improving s/w process.
Used for building prescriptive models.

06/30/09

Mzuzu university

20

Prescriptive Model
Prescribes how software should be
developed.
Used as guidelines to organize and
structure how s/w activities should be
performed, and in what order.

06/30/09

Mzuzu university

21

Generic Software Models

The waterfall Model
Separate and distinct phases of specification and
development.

Evolutionary development
Specification, development and validation are
interleaved.

Specialised Models
Component based software Engineering
The system is assembled from existing components.

Agile Models

Emphasises on customer collaboration, incremental

delivery, small development teams.
06/30/09

Mzuzu university

22

Build and Fix

Build systems without specification.
Build first version and repeat maintenance
until customer is satisfied.
Adv
Dis

Does not waste time in planning and

documentation.
Underestimation of project attributes.

06/30/09

Mzuzu university

23

Waterfall Model
Also called Classic Life
cycle.

Requirements
Engineering

Requirements well
defined(fixed) and stable.

Software
Design

Phases
Requirements Engineering
software design

Implementation and Unit

Testing

Implementation and unit testing

Integration and system testing

Integration and system testing

Maintenance

Maintenance
06/30/09

Mzuzu university

24

Drawbacks
Real projects are iterative.
Difficult for customer to state all
requirements explicitly.
Requires customer patience.
Blocking state.

06/30/09

Mzuzu university

25

Drawbacks
Inflexible partitioning of the project into distinct stage
makes it difficult to respond to changing customer
requirements.
Therefore, this model is only appropriate when the
requirements are well-understood and changes will be
fairly limited during the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems
engineering projects.

06/30/09

Mzuzu university

26

Evolutionary Process Models

Iterative
Prototyping
Throw away prototyping or exploratory
Objective is to understand the system requirements.
Should start with poorly understood requirements to clarify
what is really needed.

Evolutionary prototype
Objective is to work with customers and to evolve a final
system from an initial outline specification. Should start
with well-understood requirements and add new features
as proposed by the customer.

06/30/09

Mzuzu university

27

Prototyping
Customer defines a general objective of the software without
identifying details.
Feedback from prototypes is used to refine requirements for
the software.
Iteration is used to tune prototypes to satisfy customer needs,
while enabling the developer to better understand what needs
to be done.
Used with systems with a considerable emphasis on user
interface and user interaction.
Users and designers must be well aware of the prototyping
approach and its pitfalls.
should be planned and controlled.
06/30/09

Mzuzu university

28

Prototyping

Outline
description

06/30/09

Specification

Initial Version

Development

Intermediate
Version

Validation

Final version

Mzuzu university

29

Prototypes
Advantages
The resulting system is easy to use and maintain.
User needs are better accommodated
The design is of higher quality
The development incurs less effort.
Problems are detected earlier

Disadvantages
The resulting system harder to maintain.
The performance of the resulting system is worse.
The design is of less quality
The development incurs more effort.
The approach requires more experienced team members
06/30/09

Mzuzu university

30

Spiral Model
Proposed be Boehm (BOE88).
Evolutionary model with iterative nature of prototyping and systematic
aspects of waterfall model.
Process is represented as a spiral rather than as a sequence of
activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral
are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process.

06/30/09

Mzuzu university

31

Model sectors
Objective setting
Specific objectives for the phase are identified.

Risk assessment and reduction

Risks are assessed and activities put in place to
reduce the key risks.

Development and validation

A development model for the system is chosen
which can be any of the generic models.

Planning
The project is reviewed and the next phase of the
spiral is planned.
06/30/09

Mzuzu university

32

Spiral Model

06/30/09

Mzuzu university

33

Incremental Process Model

Combines elements of waterfall model applied in iterative
fashion.
Each linear sequence produce deliverable increments of
the software.
The first increment called the core product addresses
basic requirements.
Delivers a working product with each increment.

06/30/09

Mzuzu university

34

Assign
requirements
to
increments

Define outline
Specification

Develop
system
increment

Validate
increment

Design System
Architecture

Integrate
Increment

Validate
System

System Incomplete

06/30/09

Mzuzu university

35

The Rapid Application Development (RAD)

Model
Incremental model that emphasizes on short
development life cycle.
High speed waterfall using component based
construction.
It emphasizes user involvement, prototyping, reuse, the
use of automated tools and small development teams.
Employs time box, a fixed time frame within which
activities are done.

06/30/09

Mzuzu university

36

RAD Model
Life cycle activities
Requirements planning
User design
Construction
Cut over
Use Joint requirements planning and Joint application Design
Joint requirements planning workshops
to get requirements

Joint application Design workshops

To build the initial design of the system
06/30/09

Mzuzu university

37

RAD Model
Disadvantages
Requires sufficient human resources
Requires dedication
System need to be properly modularised
Not for high performance systems
Should not be used when technical risks are high.

06/30/09

Mzuzu university

38

Component based Development

Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) components.

Process stages
Requirements Engineering
System design with reuse
Component analysis/Qualification
Adaptation
Assembly and integration.
Evolution and maintenance
This approach is becoming increasingly used as
06/30/09
Mzuzu university
component standards have
emerged.

39

Formal Model
The approach follows the waterfall model
but use formal language to engineer the
software.
Requirements Engineering.
Formal Specification Requirements are
specified mathematically.
Formal Transformation The requirements
are refined until converted to a real
program.

06/30/09

Mzuzu university

40

Software
Engineering
Process
Activities

06/30/09

Mzuzu university

41

Software Process
A set of activities whose goal is the
development or evolution of software.
Software Specification-what the system
should do and constraints.
Software design and Implementationproduction of the software.
Software Validation-Checking if what the
customer needs.
Software Evolution-Changing the s/w in
response to changing demands.

06/30/09

Mzuzu university

42

Software Specification
Process of establishing what services are required and
the constraints on the systems operation and
development.
Requirements Engineering
Feasibility study;
Requirements elicitation and analysis;
Requirements documentation;
Requirements validation.

06/30/09

Mzuzu university

43

Software Engineering
Feasibility Study

Requirements
Elicitation and
Analysis

Requirements
Specification

Feasibility
Report

Requirements
Validation
System Models
User and Requirements
Specification
Requirements
Document

06/30/09

Mzuzu university

44

Software Design and Implementation

The process of converting the system
specification into an executable system.
Software design
Design a software structure that realises the
specification;

Implementation
Translate this structure into an executable
program;

The activities of design and implementation

are closely related and may be inter-leaved.
06/30/09

Mzuzu university

45

Software Design Activities

Architectural design
Abstract specification
Interface design
Component design
Data structure design
Algorithm design

06/30/09

Mzuzu university

46

Software Design Activities

Requirements
Specification

Architectural
Design

Architectural
specification

06/30/09

Abstract
Design

Abstract
Specification

Component
Design

Data
structure
Design

Component
specification

Data
Structure
Specification

Mzuzu university

Interface
Design

Interface
specification

Algorithm
Design

Algorithm
Specification

47

Programming
Translating a design into a program and
removing errors from that program.
Programming is a personal activity - there
is no generic programming process.
Programmers carry out some program
testing to discover faults in the program
and remove these faults in the debugging
process.

06/30/09

Mzuzu university

48

Software Validation
Verification and validation (V & V) is
intended to show that a system conforms to
its specification and meets the requirements
of the system customer.
Involves checking and review processes and
system testing.
System testing involves executing the
system with test cases that are derived from
the specification of the real data to be
processed by the system.
06/30/09

Mzuzu university

49

Testing Stages
Component or unit testing
Individual components are tested independently;
Components which may be functions or objects
or coherent groupings of these entities.

System testing
Testing of the system as a whole. Testing of
emergent properties is particularly important.

Acceptance testing
Testing with customer data to check that the
system meets the customers needs.

06/30/09

Mzuzu university

50

Software Evolution
Software is flexible and can change.
As requirements change through
changing business circumstances,
the software that support the
business must change.

06/30/09

Mzuzu university

51

Software Evolution
Define System
Requirements

Assess
Existing System

Propose System
Changes

Existing System

06/30/09

Modify System

New System

Mzuzu university

52

Agile Software Processes

06/30/09

53

Agile Software Development

an alternative to conventional software engineering

for certain classes of software and certain types of
software projects
deliver successful systems quickly
Encourages continuous communication and
collaboration among developers and customers

06/30/09

54

Agile Software Development

Agile software engineering embraces a philosophy
that encourages customer satisfaction, incremental
software delivery, small project teams (composed of
software engineers and stakeholders), informal
methods, and minimal software engineering work
products
Agile software engineering development guidelines
stress on-time delivery of an operational software
increment over analysis and design

06/30/09

55

The agile Development Manifesto

The four core values:
Individuals and interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
06/30/09

56

What is agility
Agility is dynamic, content specific, aggressively change
embracing and growth oriented [Steven Goldman et al]

An agile team is able to respond to changes

during project development
Agile development recognizes that project plans
must be flexible
Agility encourages team structures and attitudes
that make communication among developers and
customers more facile
Eliminates the separation between customers and
developers
06/30/09

57

What is agility?
Agility emphasizes the importance of rapid
delivery of operational software and deemphasizes importance of intermediate work
products
Agility can be applied to any software process
as long as the project team is allowed to
streamline tasks and conduct planning in way
that eliminate non-essential work products
06/30/09

58

Agility Principles - 1
Highest priority is to satisfy customer through early
and continuous delivery of valuable software
Welcome changing requirements even late in
development, accommodating change is viewed as
increasing the customers competitive advantage
Delivering working software frequently with a
preference for shorter delivery schedules (e.g. every
2 or 3 weeks)
Business people and developers must work together
daily during the project
06/30/09

59

Agility Principles - 2
Build projects around motivated individuals, given
them the environment and support they need, trust
them to get the job done
Face-to-face communication is the most effective
method of conveying information within the
development team
Working software is the primary measure of progress
Agile processes support sustainable development,
developers and customers should be able to continue
development indefinitely
06/30/09

60

Agile Process
Based on three key assumptions
1. It is difficult to predict in advance which
requirements or customer priorities will change
and which will not
2. For many types of software design and
construction activities are interleaved
(construction is used to prove the design)
3. Analysis, design, construction and testing are not
as predictable from a planning perspective as
one might like them to be
06/30/09

61

Agile Process
Agile processes must be adapted
incrementally to manage
unpredictability
Incremental adaptation requires
customer feedback based on evaluation
of delivered software increments
(executable prototypes) over short time
periods
06/30/09

62

Agility Principles - 3
Continuous attention to technical excellence
and good design enhances agility
Simplicity (defined as maximizing the work
not done) is essential
The best architectures, requirements, and
design emerge from self-organizing teams
At regular intervals teams reflects how to
become more effective and adjusts its
behaviour accordingly

06/30/09

63

Traits of Agile Team Members

Competence
Common focus
Collaboration
Decision-making ability
Fuzzy-problem solving ability
Mutual trust and respect
Self-organization
06/30/09

64

Agile Process Models

Extreme Programming (XP)
Adaptive Software Development (ASD)
Dynamic Systems Development Method
(DSDM)
Scrum
Feature Driven Development (FDD)
Agile Modeling (AM)
06/30/09

65

Extreme Activities
Framework activities
Planning
user stories created and ordered by customer value

Design
simple OO designs preferred
Difficult design problem is solved using spike solution.
CRC cards and design prototypes are only work products
encourages use of refactoring

Coding
emphasizes use of pairs programming to create story
code
continuous integration and smoke testing is utilized
06/30/09

66

XP Activities
Testing
focuses on unit tests to exercise stories
unit tests created before coding are implemented
using an automated testing framework to
encourage use of regression testing
integration and validation testing done on daily
basis
acceptance tests focus on system features and
functions viewable by the customer
06/30/09

67

XP Process
User stories
values
Acceptance test criteria
iteration plan

Design

Simple design
CRC Cards

Refactoring

Planning

Coding
Pair programming

Release
Software
increment
Velocity
computed

06/30/09

Test

Unit testing
Continuous integration
Acceptance test

68

Adaptive Software Development

Features
Self-organization arises when independent
agents cooperate to create a solution to a
problem that is beyond the capability of any
individual agent
Adaptive cycle characteristics
Mission-driven
Component-based
Iterative
Time-boxed
Risk driven and change-tolerant
06/30/09

69

Adaptive Software Development - 1

Speculation
project initiated
risk driven adaptive cycle planning takes place

Collaboration
requires teamwork from a jelled team
joint application development is preferred
requirements gathering approach
minispecs created
06/30/09

70

Adaptive Software Development - 2

Learning
components implemented and tested
focus groups provide feedback
formal technical reviews
postmortems

06/30/09

71

Dynamic Systems Development

Method
Provides a framework for building and maintaining
systems which meet tight time constraints using
incremental prototyping in a controlled environment
Uses Pareto principle (80% of project can be
delivered in 20% required to deliver the entire project)
Each increment only delivers enough functionality to
move to the next increment
Uses time boxes to fix time and resources to
determine how much functionality will be delivered in
each increment
06/30/09

72

Dynamic Systems Development Method Life

Cycle - 1
Feasibility study
establishes requirements and constraints

Business study
establishes functional and information
requirements needed to provide business value

Functional model iteration

produces set of incremental prototypes to
demonstrate functionality to customer
06/30/09

73

Dynamic Systems Development Method Life

Cycle - 2

Design and build iteration

revisits prototypes to ensure they provide
business value for end users
may occur concurrently with functional
model iteration

Implementation
latest iteration placed in operational
environment
06/30/09

74

Scrum Principles
Small working teams used to maximize
communication and minimize overhead
Process must be adaptable to both technical and
business challenges to ensure best product produced
Process yields frequent increments that can be
inspected, adjusted, tested, documented and built on
Development work and people performing it are
partitioned into clean, low coupling partitions
Testing and documentation is performed as the
product is built
Ability to declare the product done whenever required
06/30/09

75

Scrum - 1
Backlog
prioritized list of requirements or features that
provide business value to customer
items can be added at any time

Sprints
work units required to achieve one of the backlog
items
must fit into a predefined time-box(30 days)
affected backlog item are frozen.
06/30/09

76

Scrum - 2
Scrum meetings
15 minute daily meetings
what was done since last meeting?
what obstacles were encountered?
what will be done by the next meeting?

Demos
deliver software increment to customer for
evaluation
06/30/09

77

06/30/09

78

Feature Driven Philosophy

Emphasizes collaboration among team members
Manages problem and project complexity using
feature-based decomposition followed by integration
of software increments
Technical communication using verbal, graphical, and
textual means
Software quality encouraged by using incremental
development, design and code inspections, SQA
audits, metric collection, and use of patterns
(analysis, design, construction)
06/30/09

79

Feature Driven Design - 1

Develop overall model
contains set of classes depicting business model of
application to be built

Build features list

features extracted from domain model
features are categorized and prioritized
work is broken up into two week chunks

Plan by feature
features assessed based on priority, effort, technical issues,
schedule dependencies
06/30/09

80

Feature Driven Design - 2

Design by feature
classes relevant to feature are chosen
class and method prologs are written
preliminary design detail developed
owner assigned to each class
owner responsible for maintaining design document for his
or her own work packages

Build by feature
class owner translates design into source code and performs
unit testing
integration performed by chief programmer
06/30/09

81

FDD Process

06/30/09

82

Agile Modeling - 1
Practice-based methodology for effective modeling
and documentation of software systems in a lightweight manner
Modeling principles
Model with a purpose
Use multiple models
Travel light (only keep models with long-term value)
Content is more important than representation
Know the models and tools you use to create them
Adapt locally
06/30/09

83

Agile Modeling - 2
Requirements gathering and analysis modeling
Work collaboratively to find out what customer wants to do
Once requirements model is built collaborative analysis
modeling continues with the customer

Architectural modeling
Derives preliminary architecture from analysis model
Architectural model must be realistic for the environment and
must be understandable by developers

06/30/09

84