Unit I

Software Engineering Model

 Unit Outline
• Introduction to Software Engineering : The evolving role of
software, Changing Nature of Software, Software myths.

• A Generic view of process : Software engineering- A layered

technology, a process framework, The Capability Maturity Model
Integration (CMMI), Process patterns, process assessment, personal
and team process models.

• Process models : The waterfall model, Incremental process models,

Evolutionary process models, The Unified process.
 Chapter 1
Introduction to Software Engineering
 Chapter 1
Introduction to Software Engineering
 What is Software
 The Evolving Role of Software
 Changing Nature of Software
 Software Myths
 What is Software?
Software is a program and other operating
information used by a computer.

• Software is instructions (computer programs) that when executed provide

desired function and performance

• Software is documents that describe the operation and use of the

programs.

• Software is a set of items or objects that form a “configuration” that

includes programs, documents, data
 Software products
Generic products
– Stand-alone systems that are marketed and sold to any customer who
wishes to buy them.
– Examples – PC software such as editing, graphics programs, project
management tools; CAD software; software for specific markets such
as appointments systems for dentists.

Customized products
– Software that is commissioned by a specific customer to meet their
own needs.
– Examples – embedded control systems, air traffic control software,
traffic monitoring systems.
 Characteristic of software
• Its characteristics that make it different from other things human being build.

• Software is developed or engineered, it is not manufactured in the classical

sense which has quality problem.

• Software doesn't "wear out.”

but it deteriorates (due to change). Hardware has bathtub curve of failure rate
( high failure rate in the beginning, then drop to steady state, then cumulative
effects of dust, vibration, abuse occurs).

• Although the industry is moving toward component-based construction (e.g.

standard screws and off-the-shelf integrated circuits), most software continues
to be custom-built.

Modern reusable components encapsulate data and processing into software

parts to be reused by different programs. E.g. graphical user interface, window,
pull-down menus in library etc.
 Changing nature of Software
• Embedded Software: Embedded Software resides in read only memory and is used to control
products and systems for the consumer and industrial markets. It has very limited and
mysterious functions and control capability.

• Product-line Software: It is designed to provide a specific facility for use by many different
customers.
Ex:(word processing, spread sheets, graphics, multimedia etc.,)

• Web based Software: The Web pages retrieved by a browser are software that includes
executable instructions.
Ex:(Html, JavaScript, Perl etc.,)

• Artificial Intelligence(AI) Software: AI Software makes use of non numerical algorithms to

solve complex problems.
Ex: (Expert Systems, Pattern Recognition, Games etc.,)
 Software Myths
What are Myths?
• "Myths are stories told by people about people: where they
come from, how they handle major disasters, how they cope with what
they must and how everything will end. If that isn't everything what else is
there?"
(or)
• Myth is a Strong belief which is not true.
 Types of myths
Software Myths are of three types:
• Management Myths
• Customer Myths
• Practitioner's Myths
 Management Myth
Managers with software responsibility, like managers in most disciplines, are
often under pressure to maintain budgets, keep schedules from slipping,
and improve quality.

• Myth-1: We already have a book that's full of standards and procedures

for building software, won't that provide my people with everything
they need to know?

• Reality: The book of standards may very well exist, but is it used? Are
software practitioners aware of its existence? Does it reflect modern
software engineering practice? Is it complete? Is it streamlined to improve
time to delivery while still maintaining a focus on quality? In many cases,
the answer to all of these questions is "no."
 Management Myth
• Myth-2: If we get behind schedule, we can add more programmers and
catch up (sometimes called the Mongolian horde concept).

• Reality: Software development is not a mechanistic process like

manufacturing. In the words of. At first, this statement may seem
counterintuitive. However, as new people are added, people who were
working must spend time educating the newcomers, thereby reducing the
amount of time spent on productive development effort. People can be
added but only in a planned and well-coordinated manner.
 Management Myth
• Myth-3: If I decide to outsource the software project to a third party, I
can just relax and let that firm build it.

• Reality: If an organization does not understand how to manage and

control software projects internally, it will invariably struggle when it
outsources software projects.
 Customer Myths
• Customers may be defined as follows:

 An outside company that has requested software under contract.

 A person next to your desk.
 A technical group.
 A marketing or sales group.

• Customer Myths lead to false expectations (by the customer) and

ultimately, dissatisfaction with the developer.
 Customer Myths
• Myth-1: A general statement of objectives is sufficient to begin writing
programs— we can fill in the details later.

• Reality: A poor up-front definition is the major cause of failed software

efforts. A formal and detailed description of the information domain,
function, behavior, performance, interfaces, design constraints, and
validation criteria is essential. These characteristics can be determined
only after thorough communication between customer and developer.
 Customer Myths
• Myth 2: Project requirements continually change, but change can be
easily accommodated because software is flexible.

• Reality: It is true that software requirements change, but the impact of

change varies with the time at which it is introduced.
 Unit 1
Topic 4
Practitioner’s Myths
• A Practitioner may be planning group, Development group, Verification
group, Support group, Marketing/Sales.

• Myth-1: Once we write the program and get it to work, our job is done.

• Reality: Someone once said that "the sooner you begin 'writing code', the
longer it'll take you to get done." Industry data indicate that between 60
and 80 percent of all effort expended on software will be expended after it
is delivered to the customer for the first time.
 Practitioner’s Myths
• Myth-3: The only deliverable work product for a successful project is the
working program.

• Reality: A working program is only one part of a software configuration

that includes many elements. Documentation provides a foundation for
successful engineering and, more important, guidance for software
support.
 Practitioner’s Myths
• Myth-2: Until I get the program "running" I have no way of assessing its
quality.

• Reality: One of the most effective software quality assurance mechanisms

can be applied from the inception of a project—the formal technical
review. Software reviews are a "quality filter" that have been found to be
more effective than testing for finding certain classes of software defects.
 Practitioner’s Myths
• Myth-4: Software engineering will make us create voluminous and
unnecessary documentation and will invariably slow us down.

• Reality: Software engineering is not about creating documents. It is about

creating quality. Better quality leads to reduced rework. And reduced
rework results in faster delivery times.
 Chapter 2
Generic View of process
 Chapter 2
Chapter 2 Topics

A Generic View of Process

 Software Engineering- A layered technology,
 A process framework
 The Capability Maturity Model Integration (CMMI)
 Process patterns
 Process assessment
 Personal and team process models.
 Introduction
• Software is a logical rather than a physical system element.

• Characteristic-1: Software is developed or engineered, it is not

manufactured in the classical sense.

• Characteristic-2: Software doesn't "wear out".

• Characteristic-3: Although the industry is moving toward

component-based assembly, most software continues to be custom
built.
 What is Software Engineering
• The seminal definition:
– [Software engineering is] the establishment and use of sound
engineering principles to obtain software with better quality
possible with in the estimated budget and the stipulated time.
 Goal of Software Engineering
Goal of Software Engineering is:

• The software produce high quality software at low cost

Software Engineering: A Layered
Technology
 Software Engineering: A Layered
Technology
• Process: a collection of work activities, actions and tasks reside
within a frame work or a model

• Methods: Provide the technical "how to" for building software; rely
on a set of basic principles; encompass a broad array of tasks;
include modeling activities

• Tools: Provide automated or semi-automated support for the

process and methods (i.e., CASE tools)
 A Process Framework
• A common process framework is established by defining a small number
of framework activities that are applicable to all software projects,
regardless of their size or complexity.

• Umbrella activities are independent of any one framework activity and

occur through out the process.

• A number of task sets—each a collection of software engineering work

tasks, project milestones, work products, and quality assurance points—
enable the framework activities to be adapted to the characteristics of the
software project and the requirements of the project team.

• Finally, umbrella activities—such as software quality assurance, software

configuration management, and measurement—overlay the process
model.
A Process Framework
 A Process Framework
• Umbrella activities are independent of any one framework activity and occur throughout the process.

Umbrella Activities:
 Software requirements management
 Software project planning
 Software project tracking and oversight
 Software quality assurance
 Software configuration management
 Software subcontract management
 Formal technical reviews
 Risk management
 Measurement – process, project, product
 Reusability management (component reuse)
 Work product preparation and production
 Generic Process Framework
Applicable to almost all software projects
• Communication
• Planning
• Modelling
• Construction (coding & testing)
• Deployment
 The Capability Maturity Model
Integration(CMMI)

• Capability Maturity Model Integration (CMMI) is a process

improvement approach that helps organizations improve their
performance. CMMI can be used to guide process improvement across
a project, a division, or an entire organization.

• CMMI in software engineering and organizational development is a

process improvement approach that provides organization with the
essential elements for effective process improvement. CMMI is
registered in the U.S. Patent and Trademark Office by Carnegie Mellon
University.
The Capability Maturity Model
Integration(CMMI)
 The Capability Maturity Model
Integration(CMMI)
• Level 1: Initial : The process area is either or not performed or the
goals not achieved

• Level 2: Manageable : All level 1 criteria have been satisfied. In

addition all work associated with the process are confined to
organizational defined policy

• Level 3: Defined: All level 1 criteria have been satisfied. In addition,

the process is tailored from the organisation set of standard
processes
 The Capability Maturity Model
Integration(CMMI)
• Level 4: Quantitatively Managed :All level 3 criteria have been
satisfied. In addition, the process area is controlled and improved
using measurement and quantitative measurement.

• Level 5: Optimizing. All level 4 criteria have been satisfied. In

addition, the process area is adapted and optimized using
quantitative measurement to meet change in customer needs.
 Process Pattern
• Process patterns define a set of activities, actions, work tasks, work
products and related behaviors that must be done to complete the
project.

• In general process pattern defines a template

Template for defining a process pattern: (by Ambler):

- Pattern name : The pattern is provided with a meaningful name to
describe the function in software process (E.g.: Customer communication)
- Type: The type of pattern
1. Task pattern : Defines a software engineering action or work task
2. Stage pattern : Defines a framework activity for the process
3. Phase pattern : Defines the sequence of framework activities that occur
with the process
- Initial Context : Conditions initialized before applying to the pattern
 Process Assessment
• The existence of software process doesn’t give guarantee that
software will be delivered on time , meet requirements

• The assessment is a solution to test the above

 Process Assessment
Software
Process

Is examined by
SPA Identifies Capabilities and
Identifies modification risk of SP
To SPA Software Process
Assessment

Leads to
Leads to

Software Process Capability

Improvement Determination
Motivates
 Process Assessment
Different approaches to software process assessment:
• Standard CMMI assessment method for process Improvement
(SCAMPI)
• CMM- Based Appraisal for Internal Process Improvement (CBA IPI)
• SPICE (ISO/IEC 15504)

• International Organization for Standardization (ISO 9001:2000) for

Software :
- Applies to any organization that wants to improve overall quality of
the product , system.
- Plan-do-check-act cycle
 Personal Process Models
• The Personal Software Process (PSP) is a structured software
development process that is intended to help software engineers
understand and improve their performance, by using a "disciplined,
data-driven procedure".

• The PSP was created by Watts Humphrey to apply the underlying

principles of the Software Engineering Institute's (SEI) Capability
Maturity Model (CMM) to the software development practices of a
single developer.

• It claims to give software engineers the process skills necessary to

work on a Team Software Process (TSP) team.
 Personal Process Models
• The PSP helps software engineers to:
 Improve their estimating and planning skills.
 Make commitments they can keep.
 Manage the quality of their projects.
 Reduce the number of defects in their work.

• The goal of the PSP is to help developers produce zero-defect,

quality products on schedule. Low-defect and zero defect products
have become the reality for some developers and TSP teams.
 5 framework activities of PSP
• Planning : Requirement -> size and resource estimation, defect
estimation.
-All metrics are recorded on worksheet or template.

• High level design : Prototype are build when needed.

• High level design review : Formal verification methods are applied to

identify errors

• Development : Component level design is refined and reviewed

• Postmortem : Using measures and metrics collected , the effectiveness

of the process is determined
 Team Software Process (TSP)
• Build self-directed, managers, software process, improvement
guidance, teaching.

• The TSP is intended to improve the levels of quality and productivity

of a team's software development project
 Team Software Process (TSP)
TSP helps organizations to
• Build self directed team that plan and track the work.

• Show managers how to coach and motivate their team and

sustain peak performance

• Accelerate software process improvement

• Provide improvement guidance to high maturity organization

• Facilitate university teaching of industrial grade team skills

 Framework for TSP
• Launch
• High level design
• Implementation
• Integration
• Test
• Postmortem

TSP makes use of wide variety of

Scripts, forms and standards

Team must a full commitment to the process and undergo training to

apply properly
 Unit I
Chapter 3
Process Models
 Chapter 3
Process Models
Introduction :

• A process model specifies a general process, usually as a set of stages

in which a project should be divided
• The order in which the stages should be executed

• Any other constraints and conditions on the execution of stages.

Selection of process model is based on:

• the nature of the project and application.
• the methods and tools to be used
• the controls and deliverables
 Process Model
 Linear Sequential Model
The Waterfall Model

 Incremental Process Models

Incremental Model
RAD Model

 Evolutionary Process Models

Prototyping Model
Spiral Model
Concurrent Development Model

 The Unified Process

Linear Sequential Model

Waterfall Model
 Waterfall model
• The waterfall model is also called as linear sequential model

• To clearly identify the end of the phase and beginning of the

next stage
 Feature of waterfall model
• A waterfall is easy to flow

• It can be implemented for any size of project

• Every stage has to be done separately at the right time so you

cant jump stages

• Documentation is produced at the every stage of a waterfall

model allowing people to understand what has been done

• Testing is done at every stage

 Phases of waterfall model
• Waterfall model has 5 different phases, they are

1. Requirement gathering
2. Design
3. Coding
4. Testing
5. Maintenance
Phases of waterfall model
 Requirement analysis
• This is the 1st phase in the waterfall model which include
meeting the customer and understanding his requirements

• This is the crucial stage as any misinterpretation at this stage

may give rise to problem later

• Software definition must be detailed and accurate

• Important to understand the customer requirement and

expectation
 Design
• The customer requirements are broke down into logical
modules

• Software and hardware requirements for every module are

identified and designed accordingly

• Also inter relation of between various logical modules is

established

• Fundamentals for programming and implementation

 Design
• It is an intermediate step between requirements analysis and
coding

• Design focuses on attributes such as

– Data structures
– Software architecture
– Algorithm

• The design needs to be documented for future use

 Coding
• Coding is the step ; design is translated into machine readable
form

• If design is done with sufficient details then coding can be

efficient.

• Coding is done in small module rather than doing for the

whole software

• According to design , programmers do code, class and

structure for whole software
 Testing
• In this stage, both individual components and the integrated
ones are verified to ensure they are error free

• Testing is done for both the

1.Hardware
2.software
 Maintenance
• This is the final stage of the waterfall model, in which the
completed software is handed over to the client

• After deployment it is the duty of the developer is to

undertake frequent maintenance activities

• If the customer suggests changes the software process has to

be performed all over again
 Advantage of waterfall model
• The waterfall model is easy to implement

• For implementation of small systems waterfall will be useful

• The project requires the fulfillment of one phase before

proceeding to the next

• It is easier to develop various software through method in

short span of time
 Disadvantages of waterfall model

• The requirement analysis is done initially and sometimes it is

not possible to state all the requirements at the beginning

• The customer can see the working model only at the end

• If we want to go back track it is not possible

• It is difficult is difficult to follow the sequential flow in

software development process
Incremental Model
 Incremental Model
• Incremental model is one which combines the elements of
waterfall model which then are applied in iterative manner

• It delivers a series of releases called increments which provide

more functionality for the clients as each increment is
delivered
 Waterfall in incremental model

Co m m u n ic a t io n
p ro je c t in it ia t io n Planning
re q u ire m e n t g a t h e 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 u p p o rt
f e e dba c k
Increments or builds
 Advantages
• Sequences
– It proceeds from one phase to the next in sequential
manner
• Easier to debug
– As there are different builds, so it is easier to debug
• Lower cost
– Initial product delivery is faster and lower costs
• Work with fewer people
– Ever increment can be implemented with fewer people
• Less use of hardware
– May be able to plan every increment in the same way that
avoids the use of hardware
Incremental Model

RAD Model
 RAD model
• Rapid Application Development emphasizes on short
development cycle

• It’s a high speed adaption of the waterfall model

• Rapid development is possible by using component based

construction

• Requirements are well understood and the scope is

constrained
 Phases of RAD model
• Communication
• Planning
• Modelling
• Construction
• Deployment
RAD model

60 – 90
days
 Communication
• To understand the business problem and the information
characteristics that the software must have
 Planning
• Planning is essential for multiple software teams work in
parallel
 Modelling
• Establishes design representation that serves as the basis for
RAD’s construction

• It is further more encompasses into three phases

– Business modelling
– Data modelling
– Process modelling
 Business modelling
• The information flow among business functions is defined by
answering questions like
• what information drives the business process
• what information is generated
• who generates it
• where does the information go
• who process it and so on
 Data modelling
• The information collected from business modeling is refined
into a set of data objects (entities) that are needed to support
the business

• The attributes (character of each entity) are identified and the

relation between these data objects (entities) is defined.
 Process modelling
• The data object defined in the data modeling phase are
transformed to achieve the information flow necessary to
implement a business function

• Processing descriptions are created for adding, modifying,

deleting or retrieving a data object.
 Construction
• Emphasizes the use of pre existing software components and
the application of automatic code generation.
 Deployment
• Establishes a basic subsequent iteration.
 Advantages
• Quick initial reviews are possible.

• Constant integration isolate problems and encourage

customer feedback.

• Flexible and adaptable to changes.

• RAD realizes an overall reduction in project risk.

• RAD generally incorporates short development cycles - users

see the RAD product quickly.
 Disadvantages
• Requires a systematic approach for modularized.

• Requires highly skilled and well-trained developers.

• Product may lose its competitive edge because of insufficient

core functionality and may exhibit poor overall quality.
Evolutionary Process Model
 Evolutionary Process Model
• Requirements often change as development proceeds
• Classic process models are not designed to deliver a
production system due to their assumption on the following
– A complete system will be delivered after the linear
sequence is completed
– Customers know what they want at the early stage
 Evolutionary Process Model
• The reality in software development process is that
– a lot of requirement changes during the production
courses
– A lot of iterative activities and work because of the
evolutionary nature of the software production
Evolutionary Model

Prototype Model
 Prototype Model
• Before carrying out the development of the actual software ,
a working prototype of the system should be built.

• A prototype is a toy implementation of the system

Prototype Model
 Communication
• A prototyping model begins with requirements analysis , and
the requirements of the system are defined in detail. The user
is interviewed in order to know the requirements of the
system.
 Quick design
• When requirements are know , a preliminary design or quick
design for the system is created . It is not a detailed design ,
however , and includes the important aspects of the system,
which gives an idea of the system to the user
 Construction
• Information gathering from quick design is modified to form a
prototype . It represents a ’rough’ design of the required
system.
 Deployment delivery & feedback
• the proposed system is presented to the user for
consideration as part of the development process.

• Once the user evaluates the prototype, it is refined according

to the requirements .When the user is satisfied with the
developed prototype , a final system is developed based on
the final prototype

• The final system is thoroughly evaluated and tested followed

by routine maintenance on a continuing basis to prevent
large-scale failures and to minimize downtime
 Advantages
 Provides a working model to the user early in the process ,
enabling early assessment and increasing user confidence.

 The developer gains experience and insight by developing a

prototype , thereby resulting in better implementation of
requirements.

 Helps in reducing risks associated with the project.

 Disadvantages
 If the user is not satisfied with the developed prototype, then
a new prototype is developed . This process goes on until a
perfect prototype evolves . Thus , this model is time
consuming and expensive.

 The developer loses focus of the real purpose of prototype

and compromises on the quality of the product . For example ,
he may apply some of the inefficient algorithms or
inappropriate programming languages used in developing the
prototype .
Evolutionary Model

Spiral Model
 Spiral Model
• Proposed by Boehm
• Couples the iterative nature of prototype with systematic
approach of the linear sequential model
• Has same potential of the RAD model
• Using the spiral model software is developed in a series of
incremental releases
• During early iteration, increments will be a paper or prototype
release
• During later iteration, increasingly more complete versions of
the engineering system are produced
• Spiral model is divided into number of framework activities
called tasks regions
 Phases of spiral model
• Communication
• Planning
• Risk analysis
• Engineering
• Construction and release
• Customer evaluation
Evolutionary Process Model

Spiral Model
Spiral model
 Communication
• Task required to establish effective communication between
developer and customer
 Planning
• Task required to define resources, timeline and other project
related information
 Risk analysis
• Tasks required to access both technical and management risks
 Engineering
• Tasks required to build one or more representations of the
application
 Construction and release
• Tasks required to construction, test, and provide user support
 Customer evaluation
• Task required to obtain customer feedback based on
evaluation of the software representation created during the
engineering stage and implemented during the installation
stage.
Evolutionary Model

Concurrent Model
 Concurrent Development Model
• Provides an accurate state of the current state of project

• Focus on concurrent engineering activities process such as

prototyping ,analysis modelling, requirement specification
• Series of technical activities, tasks
 2 ways to achieve the concurrency
• System and component activities occur simultaneously can be
modeling using state – oriented approach

• A typical client / server application is implemented with many

component ; each can be designed and realized concurrently.
Concurrent Development Model
Unified Model
 Unified Model
• Proposed by Ivar Jacobson ,Grady Booch and
James Rambaugh
• Use case driven, architecture centric, iterative
and incremental in nature
Unified Model
 Phases of Unified Model
The Unified Process consists of four phases:
• Inception,
• Elaboration,
• Construction and
• Transition.
• Each phase is completed in a series of
iterations.
 Inception
• A vision of the product is created. Questions
discussed are:
• What is the product supposed to do?
• Why should my organization embark on a project
to build this particular product?
• Does my organization have the resources to build
this product?
• Is it feasible to do so?
• How much will this product cost and how much will
it bring in?
• What will be the duration of the project?
• Risk analysis is performed.
• Decision whether to go ahead with the project or
not is taken.
 Elobration
• System to be built is analyzed in detail.
• Use cases used to document the requirements.
Main aim: Get the core architecture and as
many use cases as possible.
• The core architecture is coded, verified with
user and baselined.
• Other high-risk requirements are identified and
coded.
• A project plan is drawn in this phase, resources
are allocated and a schedule is planned.
• UML diagrams are used to model the system
under design.
 Construction
• Remaining use cases are implemented.
• If any new use cases are discovered, they are
implemented.
• Test cases are written, actual tests are carried
out and a test report is prepared.
• Documentation for the system as well as
guides for the users are written.
 Transition
• System is installed in its environment and
beta-tested.

• Feedback is received and System is refined and

tuned to adapt in response to the feedback.

• It also includes activities like marketing of the

product and training of users.