Established as per the Section 2(f) of the UGC Act,

1956
Approved by AICTE, COA and BCI, New Delhi

SOFTWARE ENGINEERING
M20CA1060
I SEM MCA
School of CSA

Dr.Hemanth.K.S
AGENDA

✓ What is Software? ❖ Software Process Structure

✓ Software Applications ✓ A Generic Process Model

✓ Why must it change? ✓ Defining A Framework Activity

✓ What is Software Engineering? ✓ Identifying A Task Set

✓ Software process ✓ Process Patterns

✓ Software Engineering Practice ✓ Process Assessment And Improvement

✓ Software Engineering Myths

AGENDA

✓ Process Models ✓ Specialized Process Models

✓ Prescriptive Process Models ▪ Component-based Development
▪ The Waterfall Model ▪ The Formal Methods Model
▪ Incremental Process Models ▪ Aspect-oriented Software
Development
▪ Evolutionary Process Models
✓ The Unified Process
▪ Concurrent Models
▪ History & Phases Of The Unifi Ed
▪ A Final Word On Evolutionary Process
Processes
What is Software?
Software is:

❖ instructions (computer programs) that when

executed provide desired features, function,
and performance;

❖ data structures that enable the programs to

adequately manipulate information and

❖ documentation that describes the operation

and use of the programs.

4
What is Software?

❖ Software is developed or engineered, it

is not manufactured in the classical
sense.

❖ Software doesn't "wear out."

❖ Although the industry is moving toward

component-based construction, most
software continues to be custom-built.

5
Wear vs. Deterioration

6
Software Applications Domains
❖ System software: a collection of programs written to service other programs for
computer itself.

✓ Example: operating system, compiler, editor, file management utilities. Drivers,

networking software.

❖ Application software: stand-alone programs that solve a specific business need for
users. Applications in this area process business or technical data in a way that facilitates
business operations or management/technical decision make

✓ Example :point-of-sale transaction processing, real-time manufacturing process control

7
Software Applications Domains
❖ Engineering/scientific software : has been characterized by “number crunching” algorithms.
Applications range from astronomy to volcanology, from automotive stress analysis to space
shuttle orbital dynamics, and from molecular biology to automated manufacturing.

✓ Example Computer-aided design, system simulation, and other interactive applications have
begun to take on real-time and even system software characteristics

❖ 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.

✓ Example key pad control, digital functions in an automobile such as fuel control, dashboard
displays, and braking systems

8
Software Applications Domains

❖ Product-line software: designed to provide a specific capability for use by many different
customers.

✓ Example: word processing, spreadsheets, computer graphics, multimedia, entertainment,

database management.

❖ WebApps (Web applications): “WebApps” this network-centric software category spans a wide
array of applications. WebApps can be little more than a set of linked hypertext files that present
information using text and limited graphics.

✓ Example: stand-alone features, computing functions, and content to the end user

❖ AI software
9
Software Applications Domains

❖ AI software: makes use of non numerical algorithms to solve complex problems that are not
amenable to computation or straight forward analysis.

✓ Example: robotics, expert systems, pattern recognition (image and voice), artificial neural
networks, theorem proving, and game playing.

10
 Software Applications: New
Categories
❖ Open world computing—pervasive, distributed computing

❖ Ubiquitous computing—wireless networks

❖ Netsourcing—the Web as a computing engine

❖ Open source

❖ Data mining, Grid computing

❖ Cognitive machines

❖ Software for nanotechnologies

11
 Why changes required in Software?

❖ 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.

12
 What is Software Engineering?

Some realities:

❖ a concerted effort should be made to understand

the problem before a software solution is developed

❖ design becomes a pivotal activity

❖ should exhibit high quality

❖ should be maintainable

13
 Software Engineering: Definition
❖ The seminal definition:

✓ the establishment and use of sound engineering principles in order to obtain

economically software that is reliable and works efficiently on real machines.

❖ The IEEE definition of Software Engineering:

✓ The application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software; ie. the application of
engineering to software.

✓ Note: A “systematic, disciplined, and quantifiable” approach applied by one software

team may be burdensome to another. We need discipline as well as adaptability and
agility.

14
 Software engineering is a layered technology

quality focus: The bedrock that supports software TOOLS

engineering.

process layer: The foundation for software engineering METHODS

and defines a framework.

PROCESS MODEL
Methods: provide the technology for building software.
And includes communication, requirements analysis,
A “QUALITY” FOCUS
design modeling, program construction, testing.

Tools provide automated or sem-automated support for

the process and the methods.

15
 What is Software Process?
❖A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.

✓ Activity: Strives to achieve a broad objective 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. (Example. Communication with
Stakeholders)

✓ Action: encompasses a set of tasks that produce a major work Activity Action
product. (Example. Architectural Design)

✓ Task: focuses on a small, but well-defined objective that

Task
produces a tangible outcome. (Example. Conducting a Unit
Test) 16
 Software Process

❖A 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.

➢ A generic process framework for software engineering encompasses five activities

✓ Communication
✓ Planning.
✓ Modelling.
✓ Construction.
✓ Deployment.

17
 Software Process
Communication
❖A Process Framework

1. Communication: Before any technical work can

Deployment
commence, it is critically important to communicate and Planning

Process
collaborate with the customer and other stakeholders. Framework

2. Planning: the planning activity creates a “map” that helps

guide the team as it makes the journey. The map called a
Construction Modelling
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

18
 Software Process
Communication
❖A Process Framework

3. Modelling: Create a “sketch” of the thing so that it

understand the big picture. A software engineer does the
Deployment Planning
same thing by creating models to better understand
software requirements and the design that will achieve Process
Framework
those requirements
4. Construction:This activity combines code generation
(either manual or automated) and the testing that is
required to uncover errors in the code. Construction Modelling

5. Deployment:The software is delivered to the customer

who evaluates the delivered product and provides
feedback based on the evaluation.

19
 Software Process
A Process Framework : umbrella activities

Software engineering process framework activities are

Software project
tracking and control
complemented by a number of umbrella activities.
Work product
preparation and Risk Management
Typical umbrella activities include production

1. Software project tracking and control

2. Risk management
Reusability Software quality
management assurance
3. Software quality assurance
4. Technical reviews
5. Measurement Software
Technical reviews
configuration
6. Software configuration management management
Measurement
7. Reusability management
8. Work product preparation and production
20
 Software Process
A Process Framework : umbrella activities

21
 Software Process
A Process Framework : umbrella activities

22
 Software Process
Adapting a Process Model
A process adopted for one project might be significantly different than a process adopted for
another project. Among the differences are

❖the overall flow of activities, actions & tasks and the interdependencies.

❖ the degree to which actions and tasks are defined within each framework

❖the degree to which work products are identified and required

❖the manner which quality assurance activities are applied

❖the manner in which project tracking and control activities are applied

❖the overall degree of detail and rigor with which the process is described

❖the degree to which the customer and other stakeholders are involved

❖the level of autonomy given to the software team

❖the degree to which team organization23

and roles are prescribed
Software Engineering Practice:
The Essence of Practice

❖ George Polya [Pol45] outlined the Understand • Communication & Analysis

the problem
essence of problem solving , and
consequently suggests: Plan a • Modeling and Software design
solution

Carry out • Code Generation

the plan

• Testing &
Examine the Quality
result Assurance

24
Software Engineering Practice:
The Essence of Practice
1. Understand the Problem
❖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?

25
Software Engineering Practice:
The Essence of Practice

2. Plan the Solution

❖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?

26
Software Engineering Practice:
The Essence of Practice
3. Carry Out the Plan
❖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
algorithm?

27
Software Engineering Practice:
The Essence of Practice
4. Examine the Result

❖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?

28
Software Engineering Practice:
David Hooker’s General Principles

The Reason It All Exists

KISS (Keep It Simple, Stupid!)

Maintain the Vision

What You Produce, Others Will Consume

Be Open to the Future

Plan Ahead for Reuse

Think!

29
Software Myths
❖ Software development myths—erroneous beliefs about

software and the process that is used to build it—can

be traced to the earliest days of computing. Myths have

a number of attributes that make them insidious.

❖ Affect managers, customers (and other non-technical

stakeholders) and practitioners

❖ Are believable because they often have elements of ❖Three types of Myths are:
truth, but …Invariably lead to bad decisions, therefore ✓Management myths.
… ✓Customer myths.

❖ Insist on reality as you navigate your way through ✓Practitioner’s myths.

software engineering
30
Software Myths
Management Myths: Managers with software

responsibility, like managers in most disciplines, are

often under pressure

✓ to maintain budgets,

✓ keep schedules from slipping, Myth 1 Myth 2 Myth 3

and • We already have a • If we get behind • If I decide to

book that's full of schedule, we can add outsource the
standards and more programmers software project to a
✓ improve quality. procedures for and catch up third party, I can just
building software. relax and let that firm
Won't that provide build it.
my people with
everything they need
to know?

31
Software Myths
Customer Myths: Myths lead to false

expectations (by the customer) and, ultimately,

dissatisfaction with the developer. Myth 1

A general statement of objectives is sufficient to begin

writing programs—we can fill in the details later.

Myth 2

Software requirements continually change, but change can

be easily accommodated because software is flexible.

Myth 3

If I decide to outsource the software project to a third

party, I can just relax and let that firm build it.
32
Software Myths
Practitioner’s Customer Myths: Myths lead to false expectations (by the

customer) and, ultimately, dissatisfaction with the developer.

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

Myth 2 Until I get the program “running” I have no way of assessing its quality.

The only deliverable work product for a successful project is the working
Myth program.
3

Myth Software
4 engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.

33
How It all Starts?
SafeHome:

❖Every software project is precipitated by some business need—

✓ the need to correct a defect in an existing application;

✓ the need to the need to adapt a ‘legacy system’ to a changing business environment;

✓ the need to extend the functions and features of an existing application, or

✓ the need to create a new product, service, or system.

34
How It all Starts?

35
Software Process Structure
❖ Howard Baetjer Jr. [Bae98] comments on the software process:
“ Because software, like all capital, is embodied knowledge, and because that
knowledge is initially dispersed, tacit, latent, and incomplete in large measure,
software development is a social learning process “.
❖ The process is a dialogue in which the knowledge that must become the
software is brought together and embodied in the software.
❖ The process provides interaction between users and designers, between users
and evolving tools, and between designers and evolving tools [technology].
❖ It is an iterative process in which the evolving tool itself serves as the medium
for communication, with each new round of the dialogue eliciting more useful
knowledge from the people involved.

36
Software Process Structure
❖ A software process is a framework for the activities, actions, and tasks that are
required to build high-quality software.
❖ Is “process” synonymous with “software engineering”? The answer is yes and
no.
❖ A software process defines the approach that is taken as software is
engineered whereas software engineering also encompasses technologies that
populate the process—technical methods and automated tools.
❖ More important, software engineering is performed by creative,
knowledgeable people who should adapt a mature software process so that it
is appropriate for the products that they build and the demands of their
marketplace.

37
A Generic Process Model

38
Process Flow

39
Defining A Framework
Activity
❖a software team would need significantly more information before it
could properly execute any one of these activities as part of the
software process. The key question is :
❖What actions are appropriate for a framework activity ?
✓ given the nature of the problem to be solved,
✓ the characteristics of the people doing the work, and
✓ the stakeholders who are sponsoring the project?

40
Identifying a Task Set

A task set defines the actual work to be done to accomplish the objectives
of a software engineering action.
✓ A list of the task to be accomplished
✓ A list of the work products to be produced
✓ A list of the quality assurance filters to be applied

41
Process Patterns
• A process pattern
– describes a process-related problem that is encountered during software engineering
work,
– identifies the environment in which the problem has been encountered, and
– suggests one or more proven solutions to the problem.
• Stated in more general terms, a process pattern provides you with a template [Amb98]—
a consistent method for describing problem solutions within the context of the software
process.

42
Process Pattern Types

• Stage patterns—defines a problem associated with a framework activity for the

process.
• Task patterns—defines a problem associated with a software engineering action
or work task and relevant to successful software engineering practice
• Phase patterns—define the sequence of framework activities that occur with the
process, even when the overall flow of activities is iterative in nature.

43
Process Assessment and Improvement
• Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a
five step process assessment model that incorporates five phases: initiating, diagnosing,
establishing, acting and learning.
• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a diagnostic
technique for assessing the relative maturity of a software organization; uses the SEI CMM as
the basis for the assessment [Dun01]
• SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process. [ISO08]
• ISO 9001:2000 for Software—a generic standard that applies to any organization that wants
to improve the overall quality of the products, systems, or services that it provides. Therefore,
the standard is directly applicable to software organizations and companies. [Ant06]
44
Process Models
• Process models were originally proposed to bring order to the chaos of
software development.

• History has indicated that these models have brought a certain amount of
useful structure to software engineering work and have 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.”

• Each process model described tries to strike a balance between the need to
impart order in a chaotic world and the need to be adaptable when things
change constantly.

45
The SDLC Model

46
Prescriptive Models
• A prescriptive process model strives for structure and order in software development.

• Prescriptive process models advocate an orderly approach to software engineering.

• We call them “prescriptive” because they prescribe a set of process elements—

framework activities, software engineering actions, tasks, work products, quality
assurance, and change control mechanisms for each project.

• Each process model also prescribes a process flow (also called a work flow ) in which the
process elements are interrelated to one another.

• All software process models can accommodate the generic framework activities, but
each applies a different emphasis to these activities and defines a process flow that
invokes each framework activity in a different manner.

47
Prescriptive Models
The Waterfall Model (linear-sequential life cycle model)

48
Prescriptive Models

49
Prescriptive Models
The Incremental Model
Prescriptive Models
The Incremental Model

51
 When we use the Incremental Model?

• When the requirements are superior.

• A project has a lengthy development schedule.
• When Software team are not very well skilled or trained.
• When the customer demands a quick release of the product.
• You can develop prioritized requirements first.
 Advantage of Incremental Model

• Errors are easy to be recognized.

• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.
 Disadvantage of Incremental Model

• Need for good planning

• Total Cost is high.
• Well defined module interfaces are needed.
•
 Prescriptive Models
Evolutionary Models: Prototyping

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,
Construction
need a process model that has been of prototype
explicitly designed to accommodate a product that evolves over
time.

55
 Prescriptive Models
Evolutionary Models: Prototyping

Construction
of prototype

56
 Steps of Prototype Model

• Requirement Gathering and Analysis

• Quick Decision
• Build a Prototype
• Assessment or User Evaluation
• Prototype Refinement
• Engineer Product
 Advantage of Prototype Model

• Reduce the risk of incorrect user requirement

• Good where requirement are changing/uncommitted
• Regular visible process aids management
• Support early product marketing
• Reduce Maintenance cost.
• Errors can be detected much earlier as the system is made side by
side.
 Disadvantage of Prototype Model
• An unstable/badly implemented prototype often becomes the final
product.
• Require extensive customer collaboration
– Costs customer money
– Needs committed customer
– Difficult to finish if customer withdraw
– May be too customer specific, no broad market
• Difficult to know how long the project will last.
• Easy to fall back into the code and fix without proper requirement
analysis, design, customer evaluation, and feedback.
• Prototyping tools are expensive.
• Special tools & techniques are required to build a prototype.
• It is a time-consuming process.
 Prescriptive Models
Evolutionary Models: The Spiral

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

The spiral model is a realistic approach to the

development of large-scale systems
and software

60
 Spiral Model

• The spiral model combines the idea of iterative development with

the systematic, controlled aspects of the waterfall model.

• It allows incremental releases of the product or incremental

refinement through each iteration around the spiral.
 Spiral Model - Design

• Identification
• Design
• Construct or Build
• Evaluation and Risk Analysis
Uses of a Spiral Model

• When there is a budget constraint and risk evaluation is important.

• For medium to high-risk projects.

• Long-term project commitment because of potential changes to economic priorities as

the requirements change with time.

• Customer is not sure of their requirements which is usually the case.

• Requirements are complex and need evaluation to get clarity.

• New product line which should be released in phases to get enough customer feedback.

• Significant changes are expected in the product during the development cycle.
Prescriptive Models
Concurrent Models

Concurrent Models are software development process

models that focus on developing software that can execute
multiple tasks simultaneously.

These models are designed to handle the complexity of

developing concurrent software, which is software that
must perform multiple tasks at the same time, often on
different threads or processes.

64
Prescriptive Models
Concurrent Models

Concurrent Models typically involve breaking down the

software system into smaller components, which can be
executed concurrently.

These models also often include synchronization and

communication mechanisms to ensure that the different
components of the software system work together
seamlessly.

Concurrent Models are essential for developing software systems that can handle
concurrent execution. These models can be complex and require careful management,
but can help to create highly efficient and scalable software systems.
65
Prescriptive Models
Concurrent Models

If we take waterfall model as an example, you will not know the activities going on in each phase,
only after the phase is over, you get a work product or a document.

Suppose we want to know the state of activities of the design phase and at the same time we
want to know about testing phase activities. Which ones are complete and which are not?

The concurrent process model shows the current state of activities, tasks and their associated
states that remain in different phases.

66
Prescriptive Models
Concurrent Models

For example

‘Design Phase’ may be at an ‘awaiting state’ and ‘customer communication’ is in ‘under revision’
state.

The customer wants some changes to the design, then ‘communication’ goes to ‘awaiting
changes’ and ‘design’ goes to the ‘under-development’ stage again.

The benefit of this model is that project managers know each phase is what state and why.

Main Point – Maintain information about each phase at the activity level.

67
Specialized Process Models

• Specialized process models take on many of the characteristics of one or more of

the traditional models.
• Unlike generic process models such as the Waterfall model or Agile model,
specialized process models are designed to be highly flexible and adaptable to
the unique characteristics of each project.
• Specialized process models are designed to help organizations improve the
quality and efficiency of their software development processes by providing
tailored guidance and best practices that are specific to their industry and project
needs.

68
Specialized Process Models
Component-Based Development

❖ The component-based development model incorporates many of the characteristics of

the spiral model, evolutionary in nature [Nie92], demanding an iterative approach to
the creation of software.

❖ Component-Based Development (CBD) is a software engineering approach that

involves building software systems by combining pre-existing, reusable software
components.

❖ This approach aims to improve the efficiency, quality, and maintainability of software
systems by leveraging existing software components that have already been tested and
proven to be reliable.
69
Specialized Process Models
Component-Based Development

❖ CBD involves decomposing a software system into smaller, self-contained components

that can be independently developed, tested, and deployed.

❖ These components can be created using different programming languages, tools, and
platforms, and can be assembled together to create complex software systems.

70
Specialized Process Models
Component-Based Development
The benefits of CBD include:
• Reusability: By using pre-existing components, software developers can save time and
effort that would otherwise be spent creating new code from scratch.

• Scalability: CBD allows software systems to be easily scaled up or down by adding or

removing components, without affecting the overall system functionality.

• Maintenance: CBD simplifies the maintenance of software systems by allowing developers

to modify or replace individual components without affecting other parts of the system.

• Quality: CBD promotes the use of tested and proven components, which can improve the
overall quality and reliability of software systems.

71
Specialized Process Models
Component-Based Development

Some of the challenges associated with CBD include:

• Integration: CBD requires careful planning and management to ensure that components
are properly integrated and work together seamlessly.

• Component selection: Choosing the right components for a software system can be a
complex and time-consuming process.

• Standards: CBD relies heavily on standards and conventions for interoperability, and
different components may not always adhere to the same standards.

72
Specialized Process Models
The Formal Methods Model

❖ The Formal Methods Model is a software development approach that

emphasizes the use of mathematical techniques to design and verify software
systems.

❖ This approach aims to improve the reliability, safety, and security of software
systems by providing rigorous methods for specifying, modeling, and
verifying system requirements and behavior.

73
Specialized Process Models
The Formal Methods Model
The Formal Methods Model involves the following steps:

• Specification: This step involves defining the functional and non-functional

requirements of the software system using precise mathematical language and notation.
• Modeling: In this step, the software system is modeled using formal mathematical
notations, such as predicate logic, set theory, or automata theory. This step helps to
ensure that the system requirements are well-defined and unambiguous.
• Verification: The software system is rigorously analyzed and tested to ensure that it
meets the specified requirements. Formal verification techniques, such as model
checking or theorem proving, are used to verify that the system satisfies the specified
properties.
• Implementation: After the system has been specified and verified, it can be implemented
using any programming language or platform. The implementation should adhere to the
formal specification and model of the system to ensure that it is correct.
74
Specialized Process Models
The Formal Methods Model

The benefits of the Formal Methods Model include:

• Reliability: Formal methods can help to ensure that software systems are correct and
free from errors, which can improve the reliability of the system.

• Safety and security: Formal methods can help to identify potential safety and security
issues in software systems and provide techniques for addressing them.

• Clarity and precision: The use of formal mathematical notations can help to ensure that
the system requirements and behavior are well-defined and unambiguous.

• Maintenance: Formal methods can help to simplify the maintenance of software systems
by providing a clear and well-defined specification and model of the system.

75
Specialized Process Models
The Formal Methods Model

the Formal Methods Model also has some limitations, including:

• Complexity: The use of formal methods can be complex and time-consuming, which can
increase the cost and time required for software development.

• Expertise: Formal methods require specialized expertise in mathematical notations and

techniques, which may not be readily available in all organizations.

• Scope: Formal methods are most effective for critical and safety-critical systems, but may
not be necessary or appropriate for all software systems..

76
Specialized Process Models
Aspect-Oriented Software Development
❖ Aspect-oriented software development (AOSD), often referred to as aspect-oriented
programming (AOP) or aspect-oriented component engineering is a relatively new
software engineering paradigm that provides a process and methodological approach
for defining, specifying, designing, and constructing aspects —“mechanisms beyond
subroutines and inheritance for localizing the expression of a crosscutting concern.

❖ Aspect oriented process will adopt characteristics of both evolutionary and

concurrent process models because the evolutionary model is appropriate as aspects are
identified and then constructed and concurrent development is essential when aspects
are engineered independently.

77
Unified Process Models
❖ A “use-case driven, architecture-centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language (UML)

❖ the Unified Process is an attempt to draw on the best features and characteristics of
traditional software process models, but characterize them in a way that implements many
of the best principles of agile software development.

❖ The Unified Process recognizes the importance of customer communication and

streamlined methods to describe the customer’s view of a system.

❖ It emphasizes the important role of software architecture and “helps the architect focus
on understandability, reliance to future changes, and reuse” .

❖ It suggests a process flow that is iterative and incremental, providing the evolutionary
feel that is essential in modern software development.
78
Unified Process Models
Brief History
❖ During the early 1990s James Rumbaugh [Rum91], Grady Booch [Boo94], and Ivar
Jacobson [Jac92] began working on a “unified method” that would combine the best
features of each of their individual object-oriented analysis and design methods and
adopt additional features proposed by other experts in object-oriented modeling.

❖ The result was UML—a unified modeling language that contains a robust notation
for the modeling and development of object- oriented systems.

❖ By 1997, UML became a de facto industry standard for object-oriented software

development.

79
Unified Process Models
UP Phases

Elab o r at io n
elaboration

Incep t io n
inception

co nst r uct io n
Release
t r ansit io n
soft ware increment

p r o d uct io n

The Unified Process Phases(UP)

Unified Process Models
UP Phases
Incept ion phase

Elaborat ion phase

V ision document
Init ial use-case model
Init ial project glossary Const ruct ion phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-f unct ional Transit ion phase
Design model
Project plan, Analy sis model Sof t ware component s
phases and it erat ions. Sof t ware archit ect ure Deliv ered sof t ware increment
Int egrat ed sof t ware
Business model, Descript ion. increment Bet a t est report s
if necessary . Execut able archit ect ural General user f eedback
Test plan and procedure
One or more prot ot y pes prot ot y pe.
I nc e pt i o
Test cases
n Preliminary design model Support document at ion
Rev ised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan descript ion of current
adapt ed workf lows increment
milest ones
t echnical work product s
Preliminary user manual

UP Work Products
81
Unified Process Models
UP Phases

UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

82
THANK YOU