SOFTWARE ENGINEERING

UNIT - I
by
Mrs A.Aruna Jyothi
Assistant Professor
Department of Information Technology

BVRIT HYDERABAD College of Engineering for Women

Name of the Course Software Engineering
Course Code CS502PC
Year & Semester B.Tech III Year I Sem
Section IT – B
Name of the Faculty Mrs.A.Aruna Jyothi
Lecture Hour | Date 1st | 13.09.2022
Name of the Topic The evolving role of software
Session Outcome(s) Illustrate software process framework and models for the
development of software application.

BVRIT HYDERABAD College of Engineering for Women

 Unitthis
Why Should I Study I Syllabus
course?
Introduction to Software Engineering : The evolving
Examples
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 : Waterfall Model, Incremental
models, Evolutionary models, Specialized models,
Unified Process
BVRIT HYDERABAD College of Engineering for Women
 Introduction
Why Should to software
I Study this course? Engineering
What it is?
Examples
Computer software is the product that software professionals build
and then support over the long term.
It encompasses programs that execute within a computer of any size
and architecture, content that is presented as the computer
programs execute, and descriptive information in both hard copy
and virtual forms that encompass virtually any electronic media.

BVRIT HYDERABAD College of Engineering for Women

 Introduction
Why Should to software
I Study this course? Engineering
Who does it?
Examples
Software engineers build and support software, and virtually
everyone in the industrialized world uses it either directly or
indirectly.
Why is it important?
Software is important because it affects nearly every aspect of our
lives and has become extensive in our commerce, our culture, and
our everyday activities.

BVRIT HYDERABAD College of Engineering for Women

 Introduction
Why Should to software
I Study this course? Engineering
What are the steps?
Examples Customers and other stakeholders express the need for computer
software, engineers build the software product, and end users
apply the software to solve a specific problem or to address a
specific need.
What is the work product?
A computer program that runs in one or more specific environments
and services the needs of one or more end users.
How do I ensure that I’ve done it right?
If you’re a software engineer, apply the ideas whatever you are
learning in this subject. If you’re an end user, be sure you
understand your need and your environment and then select an
application that best meets them both.
BVRIT HYDERABAD College of Engineering for Women
Why Should I THE NATURE
Study OF SOFTWARE
this course?
The Evolving role of software
Examples
• Dual role of Software

1. A Product
- software is an information transformer — producing, managing, acquiring,
modifying, displaying, or transmitting information

2. A Vehicle for delivering a product

- Control of computer (operating system), the communication of information

(networks) and the creation of other programs

BVRIT HYDERABAD College of Engineering for Women

• Software is defined as
1. Instructions
- Programs that when executed provide desired function
2. Data structures
-Enable the programs to adequately manipulate information
3. Documents
-Describe the operation and use of the programs.

BVRIT HYDERABAD College of Engineering for Women

• Definition of Engineering
-Application of science, tools and methods to find cost effective
solution to problems
Definition of SOFTWARE ENGINEERING
- SE is defined as systematic, disciplined and quantifiable approach for the
development, operation and maintenance of software

BVRIT HYDERABAD College of Engineering for Women

• Characteristics of softwareSoftware is developed or
engineered, it is not manufactured in the classical sense.
• Software does not wear out. However it deteriorates due to
change.
• Software is custom built
• rather than assembling existing components.
-Although the industry is moving towards component based
construction, most software continues to be custom built

BVRIT HYDERABAD College of Engineering for Women

CHARACTERISTICS OF HARDWARE

“Infant
Failure rate

mortality” “Wear out”

Time

Fig: FAILURE CURVE FOR HARDWARE

BVRIT HYDERABAD College of Engineering for Women

 Failure curve for hardware
• Figure 1.1 depicts failure rate as a function of time for hardware.
• The relationship, often called the “bathtub curve,” indicates that
hardware exhibits relatively high failure rates early in its life
(these failures are often attributable to design or manufacturing
defects);
• Defects are corrected and the failure rate drops to a steady-state
level (hopefully, quite low) for some period of time.
• As time passes, however, the failure rate rises again as hardware
components suffer from the cumulative effects of dust, vibration,
abuse, temperature extremes, and many other environmental
maladies. Stated simply, the hardware begins to wear out.z

BVRIT HYDERABAD College of Engineering for Women

 Fig: FAILURE CURVE FOR SOFTWARE

BVRIT HYDERABAD College of Engineering for Women

 Failure curves for software
• Software is not susceptible to the environmental maladies that
cause hardware to wear out.
• In theory, therefore, the failure rate curve for software should
take the form of the “idealized curve” shown in Figure 1.
• Undiscovered defects will cause high failure rates early in the life
of a program.
• However, these are corrected and the curve flattens as shown.
• The idealized curve is a gross over-simplification of actual failure
models for software.
• However, the implication is clear—software doesn’t wear out.
But it does deteriorate!

BVRIT HYDERABAD College of Engineering for Women

 Software Application Domains
• Seven Broad Categories of software are challenges for software
engineers
System software
Application software
Engineering and scientific software
Embedded software
Product-line software
Web-applications
Artificial intelligence software

BVRIT HYDERABAD College of Engineering for Women

 Software Application Domains

• System software. a collection of programs written to service other programs.

• Some system software (e.g., compilers, editors, and file management utilities)
processes complex, but determinate, information structures.
• Other systems applications (e.g., operating system components, drivers,
networking software, telecommunications processors) process largely
indeterminate data.
• Application software — stand-alone programs that solve a specific business
need.
• Applications in this area process business or technical data in a way that
facilitates business operations or management/technical decision making.

BVRIT HYDERABAD College of Engineering for Women

 Software Application Domains

• Engineering/scientific software — a broad array of “number-crunching

programs that range from astronomy to volcanology, from automotive
stress analysis to orbital dynamics, and from computer-aided design to
molecular biology, from genetic analysis to meteorology.
• Embedded software— resides within a product or system and is
used to implement and control features and functions for the
end user and for the system itself.
• Embedded software can perform limited and esoteric functions
(e.g., key pad control for a microwave oven) or provide significant
function and control capability (e.g., digital functions in an
automobile such as fuel control, dashboard displays, and braking
systems).
BVRIT HYDERABAD College of Engineering for Women
 Software Application Domains

• Product-line software —designed to provide a specific capability

for use by many different customers.
• Product-line software can focus on a limited and esoteric
marketplace (e.g., inventory control products) or address mass
consumer.
• Web/Mobile applications — this network-centric software
category spans a wide array of applications and encompasses
both browser-based apps and software that resides on mobile
devices.

BVRIT HYDERABAD College of Engineering for Women

 Software Application Domains

• Artificial intelligence software— makes use of non-numerical

algorithms to solve complex problems that are not amenable to
computation or straightforward analysis.
• Applications within this area include robotics, expert systems,
pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing.

BVRIT HYDERABAD College of Engineering for Women

 LEGACY SOFTWARE

• Legacy software are older programs that are developed decades

ago.

• The quality of legacy software is poor because it has inextensible

design, convoluted code, poor and nonexistent documentation,
test cases and results that are not achieved.

BVRIT HYDERABAD College of Engineering for Women

 LEGACY SOFTWARE

• As time passes legacy systems evolve due to following reasons:

ADOPTABILITY: The software must be adapted to meet the needs of new
computing environment or technology.
ENHANCEMENT: The software must be enhanced to implement new
business requirements.
EXTENSIBILITY: The software must be extended to make it interoperable
with more modern systems or database
REARCHITECTURE: The software must be re-architected to make it
viable within a network environment.

BVRIT HYDERABAD College of Engineering for Women

 THE CHANGING NATURE OF SOFTWARE
• Four broad categories of software are evolving to dominate the
industry.

1. WebApps
2. Mobile Applications
3. Cloud Computing
4. Product Line Software

BVRIT HYDERABAD College of Engineering for Women

 Software Evolution

• Software evolves due to changes

• Changes occur due to correction, adaption and enhancement
• 8 Laws of unified theory
 The Law of Continuing Change.
 The Law of Increasing Complexity.
 The Law of Self-Regulation
 The Law of Conservation of Organizational Stability.
 The Law of Conservation of Familiarity
 The Law of Continuing Growth
 The Law of Declining Quality
 The Feedback System Law

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE MYTHS
• Myth: Widely held but false view ( wrong belief)
• Propagate misinformation and confusion
• Software Myth: is nothing but myth about s/w and the process used to build
it.
• Myths have no.of attributes that causes problems to s/w

• Three types of mythS

- Management mythS
- Customer mythS
- Developer/Practitioner’s mythS

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE MYTHS

• Customer mythS
- What is the belief of customer think about the software or process
- The customer view about software myth:
- Always he think that s/w development or process is easy.
- He may think that changing requirements is enough.

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE MYTHS

• Management mythS
- The management belief is that some standards and procedures to build s/w is enough
- They may think that, using some standard tools are sufficient to develop s/w.
- They think, they have latest computers
- A good manager can manage any project.

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE MYTHS

• Developer/Practitioner mythS
- they may think that,
- If they forget/miss something, they may think that we can fix it later.
- Once the program is written and running, They may think that my job for today is finished.
- If the delivered program is running properly, then his task is finished.

BVRIT HYDERABAD College of Engineering for Women

 MANAGEMENT MYTHS

• Myth(1): BOOK OF STANDARDS

-The available book standards and procedures
for software are enough.
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?
• Myth(2): STATE OF ART SOFTWARE
-Each organization feel that they have state-of-art software development tools since they
have latest computer.
• Myth(3): SCHEDULE
-Adding more programmers when the work is behind schedule can catch up.
If we get behind schedule, we can add more programmers and catch up (sometimes called
the “Mongolian horde” concept)

• Myth(4): THIRD PARTY

-Outsourcing the software project to third party, we can relax and let that party build it.
If I decide to outsource the software project to a third party, I can just relax and let that fi rm
build it.

BVRIT HYDERABAD College of Engineering for Women

 CUSTOMER MYTHS
• Myth(1) : OBJECTIVE
- General statement of objective is enough to begin writing programs, the
details can be filled in later.
• Myth(2) : EASY/FLEXIBILITY
-Software is easy to change because software is flexible
Software requirements continually change, but change can be easily
accommodated because software is flexible

BVRIT HYDERABAD College of Engineering for Women

 PRACTITIONER’S MYTHS

• Myth(1): PROGRAMMING IS ALL

-Once the program is written, the job has been done.
• Myth(2) : LATE ASSESSMENT
-Until the program is running, there is no way of assessing the quality.
• Myth(3):WORKING PROGRAM
-The only deliverable work product is the working program
• Myth(4): DOCUMENTATION
-Software Engineering creates voluminous and unnecessary documentation
and invariably slows down software development.

BVRIT HYDERABAD College of Engineering for Women

 PRACTITIONER’S MYTHS

• Myth(1): PROGRAMMING IS ALL

-Once the program is written, the job has been done.
• Myth(2) : LATE ASSESSMENT
-Until the program is running, there is no way of assessing the quality.
• Myth(3):WORKING PROGRAM
-The only deliverable work product is the working program
• Myth(4): DOCUMENTATION
-Software Engineering creates voluminous and unnecessary documentation
and invariably slows down software development.

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING
- Software Engineering : (1) The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application
of engineering to software.
- Software engineering is a layered technology.
- Refer the following figure:

BVRIT HYDERABAD College of Engineering for Women

SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY

Fig: Software Engineering-A layered technology

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING
- The foundation for software engineering is the process layer.
- The software engineering process is the glue that holds the
technology layers together and enables rational and timely
development of computer software.
- Process defines a framework that must be established for
effective delivery of software engineering technology.
- The software process forms the basis for management
control of software projects and establishes the context in
which technical methods are applied, work products
(models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured, and
change is properly managed.

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING
- Software engineering methods provide the technical
how-to’s for building software.
- Methods encompass a broad array of tasks that include
communication, requirements analysis, design modeling,
program construction, testing, and support.
- Software engineering methods rely on a set of basic
principles that govern each area of the technology and
include modeling activities and other descriptive
techniques. .

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING
- Software engineering tools provide automated or semi-
automated support for the process and the methods.
- When tools are integrated so that information created by
one tool can be used by another, a system for the
support of software development, called computer-
aided software engineering, is established.

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY
• Quality focus:
- Bedrock that supports software Engineering.
• Process:
- Foundation for software Engineering
• Methods:
- Provide technical How-to’s for building software
• Tools:
- Provide semi-automatic and automatic support to methods-Automation

BVRIT HYDERABAD College of Engineering for Women

 THE SOFTWARE PROCESS
- A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created
- An activity strives to achieve a broad objective (e.g., communication with
stakeholders) and is applied regardless of the application domain, size of the
project, complexity of the effort, or degree of rigor with which software
engineering is to be applied.
- An action (e.g., architectural design) encompasses a set of tasks that
produce a major work product (e.g., an architectural model).
- A task focuses on a small, but well-defined objective (e.g., conducting a unit
test) that produces a tangible outcome.
- In the context of software engineering, a process is not a rigid prescription
for how to build computer software.
- Rather, it is an adaptable approach that enables the people doing the work
(the software team) to pick and choose the appropriate set of work actions
and tasks. The intent is always to deliver software in a timely manner and
with sufficient quality to satisfy those who have sponsored its creation and
those who will use it.

BVRIT HYDERABAD College of Engineering for Women

 The Process Framework
- A process framework establishes the foundation for a complete
software engineering process by identifying a small number of
framework activities that are applicable to all software projects,
regardless of their size or complexity.
- In addition, the process framework encompasses a set of
umbrella activities that are applicable across the entire software
process.
- A generic process framework for software engineering
encompasses five activities:

BVRIT HYDERABAD College of Engineering for Women

 The Process Framework
- Communication
- Planning
- Modeling
- Construction
- Deployment.

BVRIT HYDERABAD College of Engineering for Women

 The Process Framework
- Communication.
- Before any technical work can commence, it is critically
important to communicate and collaborate with the customer
(and other stakeholders).
- The intent is to understand stakeholders objectives for the
project and to gather requirements that help define software
features and functions
- A stakeholder is anyone who has a stake in the successful
outcome of the project—business managers, end users, software
engineers, support people, etc. Rob Thomsett jokes that, “a
stakeholder is a person holding a large and sharp stake . . . If you
don’t look after your stakeholders, you know where the stake will
end up.”

BVRIT HYDERABAD College of Engineering for Women

 The Process Framework
- Planning. Any complicated journey can be simplified if a map
exists.
- A software project is a complicated journey, and the planning
activity creates a “map” that helps guide the team as it makes
the journey.
- The map—called a software project plan—defines the software
engineering work by describing the technical tasks to be
conducted, the risks that are likely, the resources that will be
required, the work products to be produced, and a work
schedule.

BVRIT HYDERABAD College of Engineering for Women

 The Process Framework
- Modeling. Whether you’re a landscaper, a bridge builder, an
aeronautical engineer, a carpenter, or an architect, you work with
models every day.
- You create a “sketch” of the thing so that you’ll understand the
big picture—what it will look like architecturally, how the
constituent parts fit together, and many other characteristics.
- If required, you refine the sketch into greater and greater detail
in an effort to better understand the problem and how you’re
going to solve it.
- A software engineer does the same thing by creating models to
better understand software requirements and the design that
will achieve those requirements.

BVRIT HYDERABAD College of Engineering for Women

 The Process Framework
- Construction. What you design must be built.
- This activity combines code generation (either manual or automated)
and the testing that is required to uncover errors in the code.
- Deployment. The software (as a complete entity or as a partially
completed increment) is delivered to the customer who evaluates the
delivered product and provides feedback based on the evaluation.
- These five generic framework activities can be used during the
development of small, simple programs, the creation of Web
applications, and for the engineering of large, complex computer-
based systems. The details of the software process will be quite
different in each case, but the framework activities remain the same.

BVRIT HYDERABAD College of Engineering for Women

 A PROCESS FRAMEWORK

• Establishes the foundation for a complete software process

• Identifies a number of framework activities applicable to all software
projects
• Also include a set of umbrella activities that are applicable across the entire
software process.

BVRIT HYDERABAD College of Engineering for Women

 A PROCESS FRAMEWORK

Common process framework

Framework activities

TTTasks

Milestones, deliverables

SQA points

Umbrella activities

BVRIT HYDERABAD College of Engineering for Women

 A PROCESS FRAMEWORK

• Used as a basis for the description of process models

• Generic process activities
Communication
Planning
Modeling
Construction
Deployment

BVRIT HYDERABAD College of Engineering for Women

 A PROCESS FRAMEWORK

• Generic view of engineering complimented by a number of

umbrella activities

• In general, umbrella activities are applied throughout a software

project and help a software team manage and control progress,
quality, change, and risk.
• Typical umbrella activities include:

BVRIT HYDERABAD College of Engineering for Women

 A PROCESS FRAMEWORK

• Software project tracking and control—allows the software team to assess progress against
the project plan and take any necessary action to maintain the schedule.
• Risk management—assesses risks that may affect the outcome of the project or the quality
of the product.
• Software quality assurance—defines and conducts the activities required to ensure
software quality.
• Technical reviews—assess software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
• Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs; can be used in conjunction
with all other framework and umbrella activities.
• Software configuration management—manages the effects of change throughout the
software process.
• Reusability management—defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
• Work product preparation and production—encompass the activities required to create
work products such as models, documents, logs, forms, and lists.

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING PRACTICE
• Generic framework activities— communication, planning,
modeling, construction, and deployment—and umbrella
activities establish a skeleton architecture for software
engineering work.
• But how does the practice of software engineering fit in?
• Now, you’ll gain a basic understanding of the generic concepts
and principles that apply to framework activities.

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING PRACTICE

• The Essence of Practice :

• How to Solve It, written before modern computers existed,
George Polya [Pol45] outlined the essence of problem solving,
and consequently, the essence of software engineering practice:

• 1.Understand the problem (communication and analysis).

• 2. Plan a solution (modeling and software design).
• 3. Carry out the plan (code generation).
• 4. Examine the result for accuracy (testing and quality
assurance).

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE ENGINEERING PRACTICE

• Understand the problem. It’s worth spending a little time

answering a few simple questions:
• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns? What data, functions, and features are required to properly
solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems
that may be easier to understand?
• Can the problem be represented graphically? Can an analysis model be created?

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE E NGINEERING PRACTICE

• Plan the solution. Now you understand the problem (or so you think),
and you can’t wait to begin coding.
• Before you do, slow down just a bit and do a little design:

• Have you seen similar problems before? Are there patterns that are recognizable in
a potential solution? Is there existing software that implements the data, functions,
and features that are required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can subproblems be defined? If so, are solutions readily apparent for the
subproblems?
• Can you represent a solution in a manner that leads to effective implementation?
Can a design model be created?

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE E NGINEERING PRACTICE

• Carry out the plan. The design you’ve created serves as a road
map for the system you want to build. There may be unexpected
detours, and it’s possible that you’ll discover an even better
route as you go, but the “plan” will allow you to proceed without
getting lost.
• Does the solution conform to the plan? Is source code traceable to the
design model?
• Is each component part of the solution provably correct? Has the design and
code been reviewed, or better, have correctness proofs been applied to the
algorithm?

BVRIT HYDERABAD College of Engineering for Women

 SOFTWARE E NGINEERING PRACTICE

• Examine the result. You can’t be sure that your solution is

perfect, but you can be sure that you’ve designed a sufficient
number of tests to uncover as many errors as possible.

• • Is it possible to test each component part of the solution?

Has a reasonable testing strategy been implemented?
• • Does the solution produce results that conform to the data,
functions, and features that are required? Has the software
been validated against all stakeholder requirements?

BVRIT HYDERABAD College of Engineering for Women

 THE SOFTWARE PROCESS

• In this part of Software Engineering: A Practitioner’s Approach you’ll

learn about the process that provides a framework for software
engineering practice.
• These questions are addressed in the chapters that follow:
• What is a software process?
• What are the generic framework activities that are present in every software
process?
• How are processes modeled and what are process patterns?
• What are the prescriptive process models and what are their strengths and
weaknesses?
• Why is agility a watchword in modern software engineering work?
• What is agile software development and how does it differ from more
traditional process models?

BVRIT HYDERABAD College of Engineering for Women

 CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

• The Capability Maturity Model Integration (CMMI) helps organizations streamline process improvement,
encouraging a productive, efficient culture that decreases risks in software, product, and service
development.

• Developed by SEI (Software Engineering institute)

• Assess the process model followed by an organization and rate the organization with different levels
• A set of software engineering capabilities should be present as organizations reach different levels of
process capability and maturity.
• CMMI process meta model can be represented in different ways
1.A continuous model
2.A staged model

Continuous model:
-Lets organization select specific improvement that best meet its business objectives and minimize risk
-Levels are called capability levels.
-Describes a process in 2 dimensions
-Each process area is assessed against specific goals and practices and is rated according to the following capability levels.

BVRIT HYDERABAD College of Engineering for Women

 SEI – CMM
CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

• The Capability Maturity Model Integration (CMMI) helps organizations

streamline process improvement, encouraging a productive, efficient culture
that decreases risks in software, product, and service development.

• Developed by SEI (Software Engineering institute)

• Helped organizations to improve the quality of s/w they developed
• SEI - CMM can be used in 2 ways
• - capability evaluation – provides a way to access the s/w process capability in an
organization
• - Software process assessment – It is used by an organization with the objective is to
improve the process capability

BVRIT HYDERABAD College of Engineering for Women

 SEI – CMM
CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

• SEI – CMM classifies the s/w development industries in 5 maturity levels

• Level-1: Initial – a s/w development organization at this level is
characterized by adhoc activities
• Level-2: Repeatability – at this level, the basic project m/m practices such as
tracking cost of project and, schedule are established.
• Level-3: Defined – the organization is defined, at this level, process for both
m/m and development activities are defined and documented.
• Level-4: Managed – it indicating that, at this is level, the focus is on s/w
metrics, they raise ups and downs of the project
• Level-5: Optimizating – if an organization is in optimize level. i.e at this
stage, process and product metrics are collected.

BVRIT HYDERABAD College of Engineering for Women

 SEI – CMM
CAPABILITY MATURITY MODEL INTEGRATION(CMMI)

• SEI – CMM classifies the s/w development industries in 5 maturity levels

• Level-1: Initial – a s/w development organization at this level is characterized by adhoc
activities
• - undocumented, low communication,
• Level-2: Repeatability – at this level, the basic project m/m practices such as tracking
cost of project and, schedule are established.
• - Functional process
• Level-3: Defined – the organization is defined, at this level, process for both m/m and
development activities are defined and documented.
• - Documented, Integration
• Level-4: Managed – it indicating that, at this is level, the focus is on s/w metrics, they
raise ups and downs of the project
• - Measures / metrics
• Level-5: Optimizing – if an organization is in optimize level. i.e at this stage, process and
product metrics are collected.
• - Continual Improvement

BVRIT HYDERABAD College of Engineering for Women

 CMMI

• Six levels of CMMI

• Level 0:Incomplete
• Level 1:Performed
• Level 2:Managed
• Level 3:Defined
• Level 4:Quantitatively managed
• Level 5:Optimized

BVRIT HYDERABAD College of Engineering for Women

 CMMI

• INCOMPLETE
-Process is adhoc. Objective and goal of process areas are not known
• Performed
-Goal, objective, work tasks, work products and other activities of software process are carried
out
• Managed
-Activities are monitored, reviewed, evaluated and controlled
• Defined
-Activities are standardized, integrated and documented
• Quantitatively Managed
-Metrics and indicators are available to measure the process and quality
• Optimized
- Continuous process improvement based on quantitative feed back from the user
- Use of innovative ideas and techniques, statistical quality control and other methods for
process improvement.

BVRIT HYDERABAD College of Engineering for Women

 CMMI

Staged model
- This model is used if you have no clue of how to improve the process for
quality software.
- It gives a suggestion of what things other organizations have found
helpful to work first
- Levels are called maturity levels

BVRIT HYDERABAD College of Engineering for Women

 LEVEL FOCUS PROCESS AREA
Optimizing Continuous process -Organizational Innovation and
Improvement
Deployment
-Causal Analysis and Resolution

Quantitatively Quantitative management -Organizational process performance

managed -Quantitative project management
Defined Process standardized Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Risk Management

BVRIT HYDERABAD College of Engineering for Women

 −Integrated Teaming
−Integrated Supplier
Management
−Decision Analysis and
Resolution
−Organizational Environment
for Integration
Managed Basic project management Requirements Management
Project Planning
Project Monitoring and
Control
Supplier Agreement
Measurement and Analysis
Process and Product
Quality Assurance
Configuration Management
Performed

BVRIT HYDERABAD College of Engineering for Women

 PROCESS PATTERNS
• Software Process is defined as collection of Patterns
• Process pattern provides a template
• Process Template
-Pattern Name
-Intent
-Type
-Task pattern
- Stage pattern
-Phase Pattern
• Initial Context
• Problem
• Solution
• Resulting Context
• Related Patterns

BVRIT HYDERABAD College of Engineering for Women

 PROCESS ASSESSMENT

• Does not specify the quality of the software or whether the software will be
delivered on time or will it stand up to the user requirements.
• It attempts to keep a check on the current state of the software process
with the intention of improving it.

BVRIT HYDERABAD College of Engineering for Women

 PROCESS ASSESSMENT

Software Process

Software Process
Assessment

Software Process Motivates Capability determination

improvement

BVRIT HYDERABAD College of Engineering for Women

 APPROACHES TO SOFTWRE ASSESSMENT

• Standard CMMI assessment (SCAMPI)

• CMM based appraisal for internal process improvement
• SPICE(ISO/IEC 15504)
• ISO 9001:2000 for software

BVRIT HYDERABAD College of Engineering for Women

 Personal and Team Software Process

• Team software process

 Goal of TSP
- Build self-directed teams
- Motivate the teams
- Acceptance of CMM level 5 behavior as normal to accelerate software process
improvement
- Provide improvement guidance to high maturity organization

BVRIT HYDERABAD College of Engineering for Women

 PROCESS MODELS
• Process models were originally proposed to bring order to the chaos of
software development.
• These models have brought a certain amount of useful structure to
software engineering work
• They provided a reasonably effective road map for software teams.
• However, software engineering work and the products that are produced
remain on “the edge of chaos.”

BVRIT HYDERABAD College of Engineering for Women

 PROCESS MODELS
• There are many kinds of process models for meeting different
requirements. We refer to these as SDLC models (Software Development
Life Cycle models).
• The most popular and important SDLC models are as follows:

• Waterfall model
• V model
• Incremental model
• RAD model
• Agile model
• Iterative model
• Prototype model
• Spiral model

BVRIT HYDERABAD College of Engineering for Women

 PROCESS MODELS - The waterfall model
The waterfall model, sometimes called the 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, culminating in ongoing support of
the completed software.

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – The V-model
• A variation in the representation of the waterfall model is called the V-model.
• Represented in Figure 4.2 , the V-model [Buc99] depicts the relationship of
quality assurance actions to the actions associated with communication,
modeling, and early construction activities.
• As a software team moves down the left side of the V, basic problem
requirements are refined into progressively more detailed and technical
representations of the problem and its solution.
• Once code has been generated, the team moves up the right side of the V,
essentially performing a series of tests (quality assurance actions) that validate
each of the models created as the team moves down the left side.
• In reality, there is no fundamental difference between the classic life cycle and
the V-model.
• The V-model provides a way of visualizing how verification and validation actions
are applied to earlier engineering work.
BVRIT HYDERABAD College of Engineering for Women
PROCESS MODELS – The V-model

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – The waterfall model
• The waterfall model is the oldest paradigm for software engineering.
• However, over the past four decades, criticism of this process model has
caused even ardent supporters to question its efficacy [Han95].
• Among the problems that are sometimes encountered when the waterfall
model is applied are:
• 1. Real projects rarely follow the sequential flow that the model proposes. Although
the linear model can accommodate iteration, it does so indirectly. As a result,
changes can cause confusion as the project team proceeds.
• 2. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of many projects.
• The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the
working program is reviewed, can be disastrous.

BVRIT HYDERABAD College of Engineering for Women

 Incremental Process Models

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – The Incremental Process Models

There are many situations in which initial software requirements are

reasonably well defined, but the overall scope of the development effort
precludes a purely linear process.
In addition, there may be a compelling need to provide a limited set of
software functionality to users quickly and then refine and expand on that
functionality in later software releases.
In such cases, you can choose a process model that is designed to produce
the software in increments.

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – The Incremental Process Models

The incremental model combines the elements’ linear and parallel process
flows
Referring to Figure 4.3 , the incremental model applies linear sequences in a
staggered fashion as calendar time progresses.
Each linear sequence produces deliverable “increments” of the software

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – The Incremental Process Models

BVRIT HYDERABAD College of Engineering for Women

 Evolutionary Process Models

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models

Software, like all complex systems, evolves over a period of time.

Business and product requirements often change as development proceeds,
making a straight line path to an end product unrealistic; tight market
deadlines make completion of a comprehensive software product
impossible, but a limited version must be introduced to meet competitive
or business pressure; a set of core product or system requirements is well
understood, but the details of product or system extensions have yet to be
defined.
In these and similar situations, you need a process model that has been
explicitly designed to accommodate a product that grows and changes.

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models

Evolutionary models are iterative.

They are characterized in a manner that enables you to develop increasingly
more complete versions of the software.
We present two common evolutionary process models.

1. Prototyping
2. The Spiral Model

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models

Prototyping.
Often, a customer defines a set of general objectives for software, but does
not identify detailed requirements for functions and features.
In other cases, the developer may be unsure of the efficiency of an algorithm,
the adaptability of an operating system, or the form that human-machine
interaction should take.
In these, and many other situations, a prototyping paradigm may offer the
best approach.

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models

The prototyping paradigm ( Figure 4.4 ) begins with communication.

You meet with other stakeholders to define the overall objectives for the software,
identify whatever requirements are known, and outline areas where further definition is
mandatory.
A prototyping iteration is planned quickly, and modeling (in the form of a “quick design”)
occurs.
A quick design focuses on a representation of those aspects of the software that will be
visible to end users (e.g., human interface layout or output display formats).
The quick design leads to the construction of a prototype.
The prototype is deployed and evaluated by stakeholders, who provide feedback that is
used to further refine requirements.
Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders,
while at the same time enabling you to better understand what needs to be done.

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models
The Spiral Model.
Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary
software process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model.
It provides the potential for rapid development of increasingly more complete
versions of the software. Boehm [Boe01a] describes the model in the following
manner:
The spiral development model is a risk-driven process model generator that is used
to guide multi-stakeholder concurrent engineering of software intensive systems.
It has two main distinguishing features. One is a cyclic approach for incrementally
growing a system’s degree of definition and implementation while decreasing its
degree of risk. The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory system solutions

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models
The Spiral Model.
A spiral model is divided into a set of framework activities defined by the software
engineering team.
For illustrative purposes, we use the generic framework activities discussed earlier.
Each of the framework activities represent one segment of the spiral path
illustrated in Figure 4.5 .
As this evolutionary process begins, the software team performs activities that are
implied by a circuit around the spiral in a clockwise direction, beginning at the
center.
Risk is considered as each revolution is made.
Anchor point milestones—a combination of work products and conditions that are
attained along the path of the spiral— are noted for each evolutionary pass.

BVRIT HYDERABAD College of Engineering for Women

PROCESS MODELS – Evolutionary Process Models
The Spiral Model.

BVRIT HYDERABAD College of Engineering for Women

 PROCESS
Why Should I Study MODELS
this course?
• Help in the software development
Examples
• Guide the software team through a set of framework activities
• Process Models may be linear, incremental or evolutionary

BVRIT HYDERABAD College of Engineering for Women

Why Should ITHE WATERFALL
Study MODEL
this course?
• Used when requirements are well understood in the beginning
Examples
• Also called classic life cycle
• A systematic, sequential approach to Software development
• Begins with customer specification of Requirements and progresses through
planning, modeling, construction and deployment

BVRIT HYDERABAD College of Engineering for Women

Why Should ITHE WATERFALL
Study MODEL
this course?
This Model suggests a systematic, sequential approach to SW development
Examples
that begins at the system level and progresses through analysis, design,
code and testing

Communication
Project initiation
requirement gathering
Planning
Estimating
Scheduling
tracking Modeling
Analysis
design Construction
Code
test Deployment
Delivery
Support
92
feedback

BVRIT HYDERABAD College of Engineering for Women

 PROBLEMS
Why Should I StudyIN WATERFALL
this course? MODEL
This Model suggests a systematic, sequential approach to SW development
Examples
that begins at the system level and progresses through analysis, design,
code and testing

• Real projects rarely follow the sequential flow since they are always iterative
• The model requires requirements to be explicitly spelled out in the
beginning, which is often difficult
• A working model is not available until late in the project time plan
 THE INCREMENTAL
Why Should PROCESS MODEL
I Study this course?
• Linear sequential model is not suited for projects which are iterative in
Examples
nature
• Incremental model suits such projects
• Used when initial requirements are reasonably well-defined and compelling
need to provide limited functionality quickly
• Functionality expanded further in later releases
• Software is developed in increments
Why Should I The Incremental
Study Model
this course?
Communication
Planning
Examples
Modeling Increment # n
Software functionality and features

Construction Communication

Deployment
Planning
Modeling
Analysis Construction
design Deployment
Code Delivery
test Support
feedback

delivery of
nth increment
Increment#2

Communication
Planning
Modeling
Analysis Construction
Increment # 1 design Code
test
Delivery of
Deployment
Delivery
nd
2 increment
Support
feedback

Communication
Planning
Modeling
Analysis Construction
design Code
test
delivery of
Deployment
Delivery
Support
ST
1 increment
feedback

Project calendar time

Why ShouldTHE INCREMENTAL
I Study MODEL
this course?
• Software releases in increments
Examples
• 1st increment constitutes Core product
• Basic requirements are addressed
• Core product undergoes detailed evaluation by the customer
• As a result, plan is developed for the next increment
Plan addresses the modification of core product to better meet the needs
of customer
• Process is repeated until the complete product is produced
 THE RAD IMODEL
Why Should Study(Rapid
thisApplication
course? Development)
• An incremental software process model
Examples
• Having a short development cycle
• High-speed adoption of the waterfall model using a component based
construction approach
• Creates a fully functional system within a very short span time of 60 to 90
days
 THE RAD IMODEL
Why Should Study(Rapid
thisApplication
course? Development)
Team # n
Modeling
Business modeling
Data modeling
Examples Process modeling

Construction
Team # 2 Component reuse
automatic code
generation
Communication Modeling testing

Business modeling
Data modeling
Process modeling

Construction
Planning Team # 1 Component reuse
automatic code
generation
testing
Modeling
Business modeling Deployment
Data modeling integration
Process modeling delivery
feedback

Construction
Component reuse
automatic code
generation
testing
 THE RAD IMODEL
Why Should Study(Rapid
thisApplication
course? Development)
• Multiple software teams work in parallel on different functions
Examples
• Modeling encompasses three major phases: Business modeling, Data
modeling and process modeling
• Construction uses reusable components, automatic code generation and
testing
• Problems in RAD
 Requires a number of RAD teams
 Requires commitment from both developer and customer for rapid-fire completion
of activities
 Requires modularity
 Not suited when technical risks are high
Why Should EVOLUTIONARY
I Study this PROCESS
course?MODEL
• Software evolves over a period of time
Examples
• Business and product requirements often change as development proceeds
making a straight-line path to an end product unrealistic
• Evolutionary models are iterative and as such are applicable to modern day
applications
• Types of evolutionary models
• Prototyping
• Spiral model
• Concurrent development model
Why Should I StudyPROTOTYPING
this course?
• Mock up or model( throw away version) of a software product
Examples
• Used when customer defines a set of objective but does not identify
input,output,or processing requirements
• Developer is not sure of:
• efficiency of an algorithm
• adaptability of an operating system
• human/machine interaction
Why Should IEvolutionary
Study this Models: Prototype
course?
Quick
Examples Communication Plan

Modeling
Quick design

Construction
Deployment of prototype
delivery &
feedback
 STEPS this
Why Should I Study IN PROTOTYPING
course?
• Begins with requirement gathering
Examples
• Identify whatever requirements are known
• Outline areas where further definition is mandatory
• A quick design occur
• Quick design leads to the construction of prototype
• Prototype is evaluated by the customer
• Requirements are refined
• Prototype is turned to satisfy the needs of customer
Why Should ILIMITATION
Study thisOFcourse?
PROTOTYPING

• In a rush to get it working, overall software quality or long term

Examples
maintainability are generally overlooked
• Use of inappropriate OS or PL
• Use of inefficient algorithm
 THE this
Why Should I Study SPIRAL MODEL
course?
• An evolutionary model which combines the best feature of the classical life
Examples
cycle and the iterative nature of prototype model
• Include new element : Risk element
• Starts in middle and continually visits the basic tasks of communication,
planning,modeling,construction and deployment
Why Should IEvolutionary
Study this Models:
course?The Spiral

Examples
 THE this
Why Should I Study SPIRAL MODEL
course?
• 1.COMMUNICATION
*Tasks required are establish effective communication between developer
Examples
• 2.PLANNING
*Estimation
*Scheduling
*Risk analysis
• MODELING
*Analysis
*Design
• CONSTRUCTION
• *Code
• *Test
• DEPLOYMENT
• *Delivery
• *Feedback
 THE this
Why Should I Study SPIRAL MODEL
course?
• Realistic approach to the development of large scale system and software
Examples
• Software evolves as process progresses
• Better understanding between developer and customer
• The first circuit might result in the development of a product specification
• Subsequent circuits develop a prototype
• And sophisticated version of software
 THE CONCURRENT
Why Should I Study thisDEVELOPMENT
course? MODEL
• Also called concurrent engineering
Examples
• Constitutes a series of framework activities, software engineering action,
tasks and their associated states
• All activities exist concurrently but reside in different states
• Applicable to all types of software development
• Event generated at one point in the process trigger transitions among the
states
 THE UNIFIED
Why Should I Study PROCESS
this course?
• Evolved by Rumbaugh, Booch, Jacobson
Examples
• Combines the best features their OO models
• Adopts additional features proposed by other experts
• Resulted in Unified Modeling Language(UML)
• Unified process developed Rumbaugh and Booch
• A framework for Object-Oriented Software Engineering using UML
Why Should I PHASES
StudyOF UNIFIED
this PROCESS
course?
• INCEPTION PHASE
Examples
• ELABORATION PHASE
• CONSTRUCTION PHASE
• TRANSITION PHASE
 The Unified
Why Should I Study this Process
course?(UP)

Examples
 UNIFIED
Why Should PROCESS
I Study WORK PRODUCTS
this course?
• Tasks which are required to be completed during different phases
Examples
• Inception Phase
• *Vision document
• *Initial Use-Case model
• *Initial Risk assessment
• *Project Plan
• Elaboration Phase
• *Use-Case model
• *Analysis model
• *Software Architecture description
• *Preliminary design model
• *Preliminary model
 UNIFIED
Why Should PROCESS
I Study WORK PRODUCTS
this course?
• Construction Phase
Examples
• *Design model
• *System components
• *Test plan and procedure
• *Test cases
• *Manual
• Transition Phase
• *Delivered software increment
• *Beta test results
• *General user feedback
 Thank you

BVRIT HYDERABAD College of Engineering for Women