An Introduction to Software

Engineering
 What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
What is Software?


software is engineered

software doesn’t wear out

software is complex
What are the attributes of good software?


The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and acceptable.

Maintainability
• Software must evolve to meet changing needs;

Dependability
• Software must be trustworthy;

Efficiency
• Software should not make wasteful use of system resources;

Acceptability
• Software must accepted by the users for which it was designed. This
means it must be understandable, usable and compatible with other
systems.
 Software’s Dual Role

Software is a product
• Delivers computing potential
• Produces, manages, acquires, modifies, displays, or transmits
information

Software is a vehicle for delivering a product
• Supports or directly provides system functionality
• Controls other programs (e.g., an operating system)
• Effects communications (e.g., networking software)
• Helps build other software (e.g., software tools)
 The Changing Nature of Software

System Software. Operating Systems, Compilers

Application Software. Railway Reservation

Engineering / Scientific Software. CAD, Mat-Lab

Embedded Software. Key Stroke - Character

Product - Line Software. Ms.Office, Editors , Games

WebApps (Web applications Browser). Yahoo

Artificial Intelligence software: Robotics , Expert Systems

Ubiquitous Computing. Present every where

Netsourcing. Downloading using Internet
 Legacy Software
Why must it change?
• software must be adapted to meet the needs
of new computing environments or
technology.
• software must be enhanced to implement
new business requirements.
• software must be extended to make it
interoperable with other more modern
systems or databases.
• software must be re-architected to make it
viable within a network environment.
 Software Myths

If I decide to out source the software project to the third party,
I can just relax and let that firm build it.
 Manage & Control


If we get behind Schedule, we can add more programmers
and catch up.
 People can be added but only in a planned and

well coordinated manner


Once we write the program and get it to work, our job is done
 Software should be modify (changes) at any time
 Chapter 2

Process: A Generic View

A Process defines who is doing what, when, and how to reach the goal
A Layered Technology

Software Engineering

tools

methods

process model

a “quality” focus
A Process Framework

Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
Framework Activities

Communication

Planning

Modeling
• Analysis of requirements
• Design

Construction
• Code generation
• Testing

Deployment
 Umbrella Activities

Software project management

Formal technical reviews

Software quality assurance

Software configuration management

Work product preparation and production

Reusability management

Measurement

Risk management
Generic process frame work used as a basics
for the description of process models.

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
THE CAPABILITY MATURITY MODEL
INTERATION
(CMMI)
 The CMMI

The CMMI defines each process area in terms of
“specific goals” and the “specific practices” required
to achieve these goals.

Specific goals [SG] establish the characteristics
that must exist if the activities implied by a process
area are to be effective.

Specific practices [SP] refine a goal into a set of
process-related activities.
 For Example: PROJECT PLANNING
SG1 : Establish Estimates

SP1.1. Estimate the scope of the project.

SP1.2. Establish estimates of work product
and task attributes.
SP1.3. Define Project life Cycle.
SP1.4. Determine estimates of effort and cost.
 For Example: PROJECT PLANNING
SG2 : Develop a project Plan

SP2.1. Establish the budget and schedule.

SP2.2. Identify project risks
SP2.3. Plan for the data management
SP2.4. Plan for the project Resources
SP2.5. Plan for needed knowledge and skills
SP2.6. Plan stakeholder involvement
SP2.7. Establish the project plan
 For Example: PROJECT PLANNING
SG3 : Obtain commitment to the plan

SP3.1. Review plans that affect the project.

SP3.2. Reconcile work and resource levels.
SP3.3. Obtain plan commitment
Process Assessment and Improvement
Software Process

identifies is examined by identifies capabilities

modifications to and risk of

Software Process
Assessment

Capability
Software Process leads to leads to
Determination
Improvement
motivates
 Chapter 3

Prescriptive Process Models

 Prescriptive Models

The Water Fall Model.

Incremental Process Model.

The RAD( Rapid Application Development)
Model.

Evolutionary Process Models.
• Prototyping
• The Spiral Model
• The Concurrent Development Model.
1. The Water Fall Model.
2. Incremental Process Model.
3. The RAD( Rapid Application Development)
Model.
 Water Fall Model

The Waterfall Model sometimes called as
Classic life cycle, suggests a systematic
sequential approach to software
development that begins with customer
specification of requirements and
progresses through planning ,modeling,
construction and deployment.

The Waterfall model is the oldest paradigm
for software engineering.
 The Waterfall Model

Co m m u n ic a t io n
p ro je c t in it ia t io n Planning
re qu ire m e n t g a t he rin g estimating Mo d e lin g
scheduling
a na lys is Co n s t ru c t io n
tracking
de s ign De p lo y m e n t
c ode
t es t d e liv e ry
s up p o rt
f e e d ba c k
 Waterfall model phases

Requirements analysis and definition

System and software design

Implementation and unit testing

Integration and system testing

Operation and maintenance

The main drawback of the waterfall model is the
difficulty of accommodating change after the
process is underway. One phase has to be
complete before moving onto the next phase.
 Waterfall model problems

Inflexible partitioning of the project into distinct stages
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 where a system is developed at
several sites.
Problems occurred in waterfall model

Real projects rarely follow the sequential flow. As
the result, changes can cause confusion as the
project team proceeds.

It is often difficult for the customer to state all
requirements explicitly.

The customer must have the patience.

A working version of the program (s) will not be
available until late in the project time span.
 The Incremental Model

incre m e nt # n
Co m m u n i c a t i o n
Pla n n in g
M o d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n
code De p lo y m e n t
t est d e l i v e ry
fe e d b a c k

d e liv e ry o f
n t h in cre me n t
incre m e nt # 2

Co m m u n ic a t i o n
Pla n n in g
Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n code De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
d e liv e ry o f
incre m e nt # 1 2 n d in cre me n t

Co m m u n i c a t i o n
Pla n n in g
Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n code
d e liv e ry o f
De p lo y m e n t
t est d e l i v e ry
fe e d b a c k
1 s t in cre me n t

project calendar t ime

 Incremental Process Model

The incremental model applies linear
sequences in a fashion as calendar time
progress.

Each linear sequence produces deliverable
“increments” of the software.

Example: To develop the Word Processing Software.
i. File Management , Editing & Document production
functions. (Core product)
ii. Spelling & Grammar checking.
iii. Page Layout.
iv. Advance page Layout
 Incremental Process Model

The delivery date of the project is uncertain.

Early increments can be implemented with
fewer people. If the core product is well
received, additional staff (if required) can be
added to implement the next increment.

It might be possible to plan early increments in
a way that avoids the use of hardware, thereby
enabling partial functionality to be delivered to
end-users
 The RAD Model
Te am # n
Mo d e lin g
bu s in e s s m o de lin g
da t a m o de lin g
pro c e s s m o d e ling

C o n s t ru c t io n
c om p o ne n t re u s e
Te am # 2 a ut om a t ic c o de
Co m m u n ic at io n ge n e ra t ion
t e s t in g
Mo d e li ng
b u s in e s s m o d e lin g
d a t a m o d e lin g
p ro ce ss m o d e lin g

Plan n in g
Co ns t ruc t io n De p lo ym e n t
Te am # 1 co m p o n e n t re u se in t e g rat io n
a u t o m a t ic co d e
g e n e ra t io n d e liv e ry
Mo d e lin g t e st in g fe e d b ack
b u s in e s s mo d e lin g
d at a mo d e lin g
p ro ce s s mo d e lin g

Co n s t ru c t io n
co mp o n e n t re u s e
au t o mat ic co d e
g e n e rat io n
t e s t in g

6 0 - 9 0 d ay s
 RAD Model

RAD is the incremental software process model
that emphasizes a short development cycle.
The RAD model is a “high - speed “ adaptation
of the water fall model, in which rapid
development is achieved by using a component
based construction approach.

If requirements are well understood and the
project scope is well constrained , the RAD
process enables a development team to create
a “ fully functional system” within a short period
of time.
 RAD Model

The RAD approach maps into the
generic frame work activities.
• Communication works understand the
business problems and information
characteristics that the software must
accommodate.
• Planning is essential because multiple
software teams work in parallel on
different system functions.
 RAD Model

Modeling encompasses 3 major phases:
• Business Modeling.
• Data Modeling.
• Process Modeling.
• Construction emphasizes the use of pre
existing software components and the
application of automatic code generation.
• Deployment establishes a basis for
subsequent iterations, if required.
Problems occurred in RAD model
1. For large , but scalable projects , RAD requires
sufficient human resources to create the right
number of RAD teams.
2. If developers and customers are not committed
total the system will fail.
3. RAD may not be appropriate when technical
risks are high( e.g ., when a new application
makes heavy use of new technology).
 Evolutionary Process Models

1. Prototyping
2. The Spiral Model
3. The Concurrent Development Model.
 Prototyping

Quick
Qu ic k p la n
plan
Co m m u n ic at io n
communication

MoModeling
d e lin g
Quickicdesign
Qu k d e s ig n

De p loym e nt
Deployment
De live ry&
delivery
&feedback
Fe e d b ac k Co n s t ru c t io n
Construction
of
of prototype
p ro t o t yp e
 Prototyping

A Prototyping can be used as a standalone
process model, it is more commonly used a
technique that can be implemented within the
context of anyone of the process models.

The prototyping paradigm assists the software
engineer and the customer to better understand
what is to be built when requirements are fuzzy.
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test
Evolutionary Models: Concurrent
none

Mode ling a c t ivit y

rep res ents the s tate

Unde r o f a s o ftware eng ineering
activity o r tas k
de ve lopm e nt

Awa it ing
c ha nge s

Unde r re vie w

Unde r
re vis ion

Ba s e line d

Done
 Still Other Process Models

• Component based development

• Commercial -off -the -Shelf
( COTS) software components ,
developed by vendors who offer
them as products , can be used
when software is built.
• The process to apply when reuse
is a development objective
 Still Other Process Models

• Formal Methods Models—

1. Formal Methods enable a software
engineer to specify , develop and
verify a computer based system by
applying a rigorous , mathematical
notation.
2.Emphasizes the mathematical
specification of requirements
 Still Other Process Models

AOSD (Aspect Oriented Software
Development) —provides a process and
methodological approach for defining,
specifying, designing, and constructing
aspects

Unified Process—a “use-case driven,
architecture-centric, iterative and
incremental” software process closely
aligned with the Unified Modeling
Language (UML)
 The Unified Process (UP)
elaboration
Ela b o ra t io n

Inc e p t io n
inception

inception
c o ns t ruc t io n
Re le a s e
t ra ns it io n
s oft wa re inc re m e nt

p ro d uc t io n
 UP Phases
UP Phases
In ce pt ion Elaborat ion Cons t ruct ion Trans it io n Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n
 Inception Phase
1. Vision Document
2. Initial use case model
3. Initial project glossary
4. Initial business case
5. Initial risk assessment
6. Project Plan
Phases and Iterations
7. Business Model
If necessary
One or more prototypes
 Elaboration Phase
1. Use case Model
2. Supplementary
requirements including non
- functional
3. Analysis Model
4. Software Architecture
description
5. Executable architectural
prototype
6. Preliminary design
7. Revised risk list
 Elaboration Phase

8. Project Planning including

Iteration plan
Adapted workflow , milestones
Technical work products
Preliminary user manual
 Construction Phase
1. Design Model
2. Software components
3. Integrated software
increment
4. Test plan and procedure
5. Test cases
6. Support documentation
user manuals
Installation manuals
description of current
increment
 Transition Phase
1. Delivered Software
increment
2. Beta test Reports
3. General user feed Back
Software Requirements
 Software Requirements

User requirements

System requirements

Functional and non-functional requirements

Interface specification

The software requirements document
 What is a requirement?

The requirements for a system are the description of
the services provides by the system and its operational
constraints.

These reflect the needs of customers for a system that
helps solve some problems such as controlling a
device, placing an order of finding information.

The process of finding out, analysing, documenting and
checking these services and constraints is called
requirements engineering (RE)
Requirements readers different types of
specification

Client Managers
System end- users
Client Engineers
User Requirements Contractor Managers
System Architects

System end- users

Client Engineers
System developers
System Requirements
System Architects
 Types of requirement

User requirements are statements
• Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers.

System requirements
• A structured document setting out detailed
descriptions of the system’s functions, services and
operational constraints. Defines what should be
implemented so may be part of a contract between
client and contractor.
 User requirement definition
1. LIBSYS (Library Information System )shall keep
track of all data required by copyright licensing
agencies in the country and elsewhere.
 System Requirement Specification

1) On making a request for a document from LIBSYS, the requestor shall

be presented with a form that records details of the user and the request
made.
2) LIBSYS request forms shall be stored on the system for five years from
date of request.
3) All LIBSYS request must be indexed by user, the name of the material
requested and by the supplier of the request.
4) LIBSYS shall maintain a log of all requests that have been made to the
system.
 Functional requirements

Describe functionality or system services.

Functional user requirements may be high-level statements
of “what the system should do”

These requirements depend on the type of software being
developed, the expected users of the software and the
general approach taken by the organisation when writing the
requirements.

The requirements are usually describe in a fair abstract way.

Statements of services the system should
provide, how the system should react to
particular inputs and how the system should
behave in particular situations.
Requirements completeness and consistency


In principle, requirements should be both complete and
consistent.

Complete
• They should include descriptions of all facilities
required.

Consistent
• There should be no conflicts or contradictions in the
descriptions of the system facilities.

In practice, it is impossible to produce a complete and
consistent requirements document.
 Non-functional requirements
1. It is related to emergent system properties such as
reliability , response time and store occupancy.

2. However , failing to meet a non – functional

requirement can mean that the whole system is
unusable.
For Example : if an air craft system does not meet its
reliability requirements, it will not be certified as safe
for operation; if a real time control system fails to meet
its performance requirements, the control functions wil
not operate correctly.
 Non-functional classifications

Product requirements
• Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirements
• Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.

External requirements
• Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Non-functional requirement types

Non - Functional
Requirements

Product Organizational External

Requirements Requirements Requirements
 Product requirement types

Product
Requirements

Reliability
Usability Efficiency Portability
Requirements
Requirements Requirements Requirements

Performance
Space
Requirements
Requirements
Organizational Requirement types

Organizational
Requirements

Delivery Implementation Standards

Requirements Requirements Requirements
 External requirement types

External
Requirements

Legislative
Inter Operability Implementation Ethical
Requirements
Requirements Requirements Requirements

Privacy Safety
Requirements Requirements
 SYSTEM GOAL


The system should be easy to
use by experienced controllers
and should be organised in
such a way that user errors are
minimised.
 Domain requirements


Requirements that come from
the application domain of the
system and that reflect
characteristics of that domain.
They may be a functional or
Non - functional requirements
 Domain requirements

Derived from the application domain and
describe system characteristics and features that
reflect the domain.

Domain requirements be new functional
requirements, constraints on existing
requirements or define specific computations.

If domain requirements are not satisfied, the
system may be unworkable.
 Domain requirements problems

Understandability
• Requirements are expressed in the language of the
application domain;
• This is often not understood by software engineers
developing the system.

Implicitness
• Domain specialists understand the area so well that
they do not think of making the domain requirements
explicit.
 Problems with natural language
( Requirements )

Lack of clarity
• Precision is difficult without making the document
difficult to read.

Requirements confusion
• Functional and non-functional requirements tend to
be mixed-up.

Requirements amalgamation
• Several different requirements may be expressed
together.
Software requirements document

The requirements document is the official
statement of what is required of the system
developers.

Should include both a definition of user
requirements and a specification of the system
requirements.

It is NOT a design document. As far as possible,
it should set of WHAT the system should do
rather than HOW it should do it
Users of a requirements document

System Customers
Specify the requirements and read them to check
that they meet their needs. Customers specify
changes to the requirements

Managers
Use the requirements document to plan a bid for the
System and to plan the system development process.
Users of a requirements document

System Engineers

Use the requirements to understand what system

is to developed.

System Test Engineers

Use the requirements to develop validation tests for the
system
Users of a requirements document

System Maintenance Engineers

Use the requirements to understand the system and

the relationships between its parts.
 IEEE requirements standard

Defines a generic structure for a requirements
document that must be instantiated for each
specific system.
• Introduction.
• General description.
• Specific requirements.
• Appendices.
• Index.
 IEEE requirements standard

Introduction.

• Purpose of the requirements document.

• Scope of the Project.
• Definitions and abbreviations.
• References
• Overview of the remainder of the document.
 IEEE requirements standard

General Description

• Product Perspective.
• Product Functions
• User Characteristics
• General Constraints.
• Assumptions and dependencies.
 IEEE requirements standard

Specific Requirements

• Functional & non Functional Requirements.

• Appendices
• Index
Requirements document structure

Preface

Introduction

Glossary

User requirements definition

System architecture

System requirements specification

System models

System evolution

Appendices

Index
 Key points

Requirements set out what the system should do and
define constraints on its operation and implementation.

Functional requirements set out services the system
should provide.

Non-functional requirements constrain the system being
developed or the development process.

User requirements are high-level statements of what the
system should do. User requirements should be written
using natural language, tables and diagrams.
 Key points


System requirements are intended to
communicate the functions that the system
should provide.

A software requirements document is an agreed
statement of the system requirements.

The IEEE standard is a useful starting point for
defining more detailed specific requirements
standards.