Chapter 1
Introduction to OOSAD
2
Chapter one - Objective
Review of Software, Systems and System
thinking.
Structured Vs object oriented paradigm
The potential benefits of object orientation
The potential drawbacks of object
orientation
The object oriented software process
models
7/6/2021
Chapter 1 Introduction to OOSAD
3
1. What is System, System thinking??
 A system is an interrelated set of business procedures
(or components) used within one business unit, working
together to achieve some purpose.
 Read about the 7 important characteristics of a system.??
 Systems thinking is the ability to see organizations and
information systems as systems.
 Systems thinking provides a framework from which to
see the important relationships among information
systems, the organizations they exist in, and the
environment in which the organizations themselves exist.
7/6/2021
Chapter 1 Introduction to OOSAD
Systems, System thinking cont’d…
Important systems concepts:
 Decomposition- Breaking a system into smaller subsystems
(Components).
 Modularity- This is a direct result of decomposition. It refers
to dividing a system into chunks or modules of a relatively
uniform size
 Coupling: Subsystems should be as independent as
possible (Loose Coupling)
 Cohesion: This is the extent to which a subsystem performs
a single function- separation of concern (Highly
Cohesiveness)
7/6/2021
Chapter 1 Introduction to OOSAD
4
Software – Product Vs Process
 The product
 Information system
 Software
 The process
 System development
 Software engineering
7/6/2021
Chapter 1 Introduction to OOSAD
5
6
Software Cont’d…
 System development ultimate objectives
 Problem solving
 Supporting processes
 Participants and roles in system/software
production






Users
Mangers (owners)
Analysts
Designers
Programmers
Consultants
7/6/2021
Chapter 1 Introduction to OOSAD
Factors Initiating Software Development
Scenarios initiating system/software
development
 Real problem on the day-to-day task
 By end users
 Looking for effectiveness and efficiency
 By mangers
 Sensing new opportunities and technologies
 By technical personnel
7/6/2021
Chapter 1 Introduction to OOSAD
7
8
The Inherent Nature of Software Complexity
 Some software systems are not complex.
 These are the largely forgettable applications that are specified,
constructed, maintained, and used by the same person( Amateur
or Professional).
 This is not to say that all such systems are crude and inelegant,
nor do we mean to belittle their creators.
 Such systems tend to have a very limited purpose and a very short
life span.
 More interested in the challenges of developing what we will call
industrial-strength software.
 Applications that exhibit a very rich set of behaviors
 Applications that maintain the integrity of hundreds of thousands of records of information
while allowing concurrent updates and queries.
 Systems for the command and control of real-world entities, such as the routing of air or
railway traffic.
7/6/2021
Chapter 1 Introduction to OOSAD
Software Complexity Cont’d…
 Such Complex Software systems tend to have a
long life span, and over time, many users come to
depend on their proper functioning.
 In the world of industrial-strength software, we also
find frameworks that simplify the creation of
domain-specific applications, and programs that
mimic some aspect of human intelligence.
 Such Systems are complex, for they are the means
and artifacts of incremental and exploratory
development.
7/6/2021
Chapter 1 Introduction to OOSAD
9
Distinguishing characteristic of industrialstrength software –Complex Systems
 Complex systems are Intensely difficult, if not impossible for the
individual developer to comprehend all the subtleties of its
design.
 The complexity of such systems exceeds the human intellectual
capacity.
 Unfortunately, this complexity we speak of seems to be an
essential property of all large software systems.
 We may master how to solve this complexity, but we cannot
avoid.
 Hence, the complexity of large software is an essential property,
not an accidental one.
7/6/2021
Chapter 1 Introduction to OOSAD
10
Inherent complexity derives from four
elements
 The complexity of the problem domain
 competing, perhaps even contradictory requirements
 Arbitrary non-functional requirements( external requirements)
 The difficulty of managing the development process.
 Systems are developed with hundreds of thousands or even millions of
lines of code .
 This amount of work demands that we use a team of developers, and
ideally we use as small a team as possible.
 However, no matter what its size, there are always significant challenges
associated with team development.
 Having more developers means more complex communication and hence
more difficult coordination
7/6/2021
Chapter 1 Introduction to OOSAD
11
Elements of Software Complexitycont’d…
 The flexibility possible through software.
 Should I acquire the building blocks like a construction company or develop them
myself?
 Software offers the ultimate flexibility, so it is possible for a developer to express
almost any kind of abstraction by himself- seductive property of software
development.
 In other industries, such as in construction, there are some standards about the
type or size of steel used, the bricks molded etc.
 Few such standards exist in the software industry. As a result, software
development remains a labor-intensive business.
 The problems of characterizing the behavior of discrete systems
 Discrete systems such as digital computers systems have unrollable inter-state
phase that we don’t find in analog states. This could corrupt the system
accidentally if proper event interaction between the different objects is not carefully
crafted.
7/6/2021
Chapter 1 Introduction to OOSAD
12
13
Attributes of Complex Systems
There are five common characteristics of
Complex Systems.
 Hierarchic Structure
 Frequently, complexity takes the form of a hierarchy,
whereby a complex system is composed of interrelated
subsystems that have in turn their own subsystems, and so
on, until some lowest level of elementary components is
reached.( System thinking?!)
 The architecture of a complex system is a function of its
components as well as the hierarchic relationships among
these components.
7/6/2021
Chapter 1 Introduction to OOSAD
Hierarchical(Canonical) form of complex
systems
7/6/2021
Chapter 1 Introduction to OOSAD
14
Attributes of Complex Systems Cont’d…
Relative Primitives
 The nature of the primitive components of a
complex system is relative(subjective).
 The choice of what components in a system are
primitive is relatively arbitrary and is largely up to
the discretion of the observer of the system.
 What is primitive for one observer may be at a
much higher level of abstraction for another.
7/6/2021
Chapter 1 Introduction to OOSAD
15
Attributes of complex systems Cont’d…
Separation of Concerns
 Hierarchic systems are decomposable because they can be
divided into identifiable parts(nearly decomposable
because their parts are not completely independent).
 Intracomponent linkages are generally stronger than
intercomponent linkages.(Loose Coupling and High
Cohesion)
 This difference between intra- and intercomponent
interactions provides a clear separation of concerns
among the various parts of a system, making it possible to
study each part in relative isolation.
7/6/2021
Chapter 1 Introduction to OOSAD
16
Attributes of complex systems Cont’d…
Common Patterns
 Hierarchic systems are usually composed of only a
few different kinds of subsystems in various
combinations and arrangements.
 In other words, complex systems have common
patterns.
 These patterns may involve the reuse of small
components.
7/6/2021
Chapter 1 Introduction to OOSAD
17
Attributes of complex systems Cont’d…
Stable Intermediate Forms
 Complex systems tend to evolve over time
 A complex system that works is consistently
found to have evolved from a simple system that
worked
 As systems evolve, objects that were once
considered complex become the primitive objects on
which more complex systems are built
7/6/2021
Chapter 1 Introduction to OOSAD
18
19
Human Capacity in Dealing with Complexity
If we know what the design of complex
software systems should be like, then why
do we still have serious problems in
successfully developing them?
Humans have limited capacity for dealing
with the complexity.
The concept of the organized complexity of
software is the issue- Object Model
7/6/2021
Chapter 1 Introduction to OOSAD
20
Software Complexity -Solution
 The complexity of the software systems we are asked to develop is
increasing, yet there are basic limits on our ability to cope with this
complexity.
 Hence we need a mechanism to cope with this complexity.
 The technique of mastering complexity has been known since ancient times:
“divide et impera (divide and rule)”
 Hence, solution is Decomposition
 Two types
 Algorithmic -top-down structured design, and so we approach decomposition – as a
simple algorithmic decomposition where in each module in the system denotes a major
step in some overall process.
 Object-Oriented -according to the key abstractions ( concepts) in the problem
domain. Rather than decomposing the problem into steps such as Get formatted
update and Add checksum, we can identify objects such as Master File and Checksum,
which derive directly from the vocabulary of the problem domain
7/6/2021
Chapter 1 Introduction to OOSAD
OO Decomposition vs Algorithmic Decomposition
 Algorithmic Decomposition
7/6/2021
 OO Decomposition
Chapter 1 Introduction to OOSAD
21
22
Characteristics of Good Software
7/6/2021
Chapter 1 Introduction to OOSAD
23
Software Quality and the Stakeholders View
Customer:
solves problems at
an acceptable cost in
terms of money paid and
resources used
User:
easy to learn;
efficient to use;
helps get the work done
QUALITY
SOFTWARE
Developer:
easy to design;
easy to maintain;
easy to reuse its parts
7/6/2021
Development manager:
sells more and
pleases customers
while costing less
to develop and maintain
Chapter 1 Introduction to OOSAD
24
Software Failure Crisis
 “The "software crises" came about when people
realized the major problems in software
development were … caused by communication
difficulties and the management of complexity”
(Budd)
 Evidence over the years has shown that some of
the most common reasons software projects fail
center around poor or nonexistent communication
between the key stakeholders.(Booch)
7/6/2021
Chapter 1 Introduction to OOSAD
25
7/6/2021
Chapter 1 Introduction to OOSAD
26
Software Industry Success status( 2004)
 How well are systems built?
 Total Failure
15%
 “Challenged”
51%
 Successful
34%
 In 1994 “Successful” was only 17%!
 Challenged means…
 Failure to meet time, budget, or critical
features/requirements
7/6/2021
Chapter 1 Introduction to OOSAD
2. Structed vs OO development
Approaches
 Structured Paradigm
 Structured methods for design were developed in the 1970s
and 1980s and were the precursor to the UML and objectoriented design.
 Modeling process and data separately
 Suitable for small sized software
 Object Oriented Paradigm
 Things are made up of objects
 Objects are identified as having data and function
 Is a software development strategy based on the idea of
building systems/software from reusable components called
objects
7/6/2021
Chapter 1 Introduction to OOSAD
27
28
Structured (Paradigm)Approach
 The structured paradigm is a development strategy
based on the concept that a system should be separated
into two parts: data (modeled using a data model) and
functionality (modeled using a process model).
 applications in which data are separate from behavior both in the design
model and in the system implementation (that is, the program)
 Examples of structured technologies include the COBOL,
BASIC and FORTRAN programming languages.
 Is it also possible to do structured programming with any
of the modern programming language??- findout
7/6/2021
Chapter 1 Introduction to OOSAD
Structured Analysis and Design Cont’d…
Philosophy of structured analysis and
design
 Analysts attempt to divide large, complex problems
into smaller, more easily handled ones. “Divide and
Conquer”
 Top-Down approach to program development
 Functional view of the problem.
 Analysts use graphics to illustrate their ideas whenever
possible
7/6/2021
Chapter 1 Introduction to OOSAD
29
Structured analysis and design Cont’d…
Goals of SAD
 Improve Quality and reduce the risk of system
failure
 Establish concrete requirements specifications
and complete requirements documentation
 Focus on Reliability, Flexibility, and Maintainability
of system
7/6/2021
Chapter 1 Introduction to OOSAD
30
Structured analysis and design Cont’d…
 Elements of Structured Analysis and Design
 Essential Model: Model of what the system must do.
 Does not define how the system will accomplish its purpose.
 Is a combination of the environmental and behavioral model
 Environmental Model
 Defines the scope of the proposed system.
 Defines the boundary and interaction between the system and the outside
world.
 Composed of: Statement of Purpose, Context Diagram, and Event List.
7/6/2021
Chapter 1 Introduction to OOSAD
31
Structured analysis and design Cont’d…
Essential Model Cont’d…
 Behavioral Model
 Model of the internal behavior and data entities of the
system.
 Models the functional requirements.
 Composed of Data Dictionary, Data Flow Diagram,
Entity Relationship Diagram, Process Specification, and
State Transition Diagram.
7/6/2021
Chapter 1 Introduction to OOSAD
32
Structured analysis and design Cont’d…
Implementation Model
 Maps the functional requirements to the hardware
and software.
 Determines which functions should be manual and
which should be automated.
 Defines the Human-Computer Interface.
 Defines non-functional requirements.
 Tool: Structure Charts
7/6/2021
Chapter 1 Introduction to OOSAD
33
34
Structured analysis and design
Advantages of structured analysis and
design
 Visual, so it is easier for users/programmers to
understand
 Makes good use of graphical tools
 A mature technique
 Simple and easy to understand and implement
7/6/2021
Chapter 1 Introduction to OOSAD
Structured Analysis and Design Cont’d…
Disadvantages of Structured analysis
and design
 Not enough user-analyst interaction
 It depends on dividing system to sub systems but it
is hard to decide when to stop decomposing
7/6/2021
Chapter 1 Introduction to OOSAD
35
36
OO Paradigm (Approach)
The object-oriented (OO) paradigm
(pronounced “para-dime”) is a development
strategy based on the concept that systems
should be built from a collection of reusable
parts (components) called objects
Examples of OO languages and technologies
include the Smalltalk, Java, C#, and C++
programming languages and the Enterprise
JavaBeans (EJB) framework.
7/6/2021
Chapter 1 Introduction to OOSAD
37
OO Paradigm Cont’d…
The main concept behind the object-oriented
paradigm is that
 Instead of defining systems as two separate parts (data and
functionality), you now define systems as a collection of
interacting objects.
 Objects do things (that is, they have functionality) and they
know things(they have data).
 It requires a different way of thinking about decomposition –
OO Decomposition as opposed to algorithmic(functional)
decomposition.
 A bottom-up approach to program development
7/6/2021
Chapter 1 Introduction to OOSAD
38
OO Paradigm Cont’d…
Benefits are Greater:
 Productivity
 Reliability
 Maintainability
 Manageability
7/6/2021
Chapter 1 Introduction to OOSAD
39
OO Paradigm Cont’d…
 Direct mapping of concepts in the problem domain
to software units and their interfaces
 Viewing the world as objects is more natural since
it is closer to the way humans think
 Objects are more stable than functions…
 Supports information hiding, data abstraction, and
encapsulation
 Easily modified, extended, and maintained…
 if your product was designed correctly
7/6/2021
Chapter 1 Introduction to OOSAD
40
OO Paradigm Cont’d…
OO Model is a “new” way of thinking about
what it means to compute and how
information can be structured
Systems are viewed as cooperating objects
that encapsulate structure and behavior in
a hierarchical construction (Canonical
Form)
Functionality achieved by messages
passing between objects.
7/6/2021
Chapter 1 Introduction to OOSAD
41
OO Paradigm Cont’d…
 For system/software developer in object
orientation
 Object oriented Programming
 Object Oriented Analysis, design
 Object Oriented CASE tools
7/6/2021
Chapter 1 Introduction to OOSAD
42
Object-Oriented analysis and design
 Object-Oriented analysis and design is becoming
popular because of its ability to thoroughly represent
complex relationships, as well as represent data and
data processing with a consistent notation
 Object-Oriented analysis and design blends analysis
and design in an evolutionary process
 It allows you to deal with the complexity inherent in a
real-world problem by focusing on the essential and
interesting features of an application
7/6/2021
Chapter 1 Introduction to OOSAD
43
Object-Oriented analysis and design Cont’d…
Process of progressively developing
representation of a system component (or
object) through the phases of analysis,
design and implementation
The model is abstract in the early stages
As the model evolves, it becomes more
and more detailed and concrete.
7/6/2021
Chapter 1 Introduction to OOSAD
44
Object-Oriented analysis and design Cont’d…
 Object-Oriented systems development life cycle
 The Object-Oriented development life cycle consists of
progressively developing an object representation through three
phases analysis, design, and implementation.
 Analysis Phase
 Object-oriented analysis is a popular approach that sees a system from the
viewpoint of the objects themselves as they function and interact
 Model of the real-world application is developed showing its important properties
 Model specifies the functional behavior of the system independent of
implementation details
7/6/2021
Chapter 1 Introduction to OOSAD
45
Object-Oriented analysis and design Cont’d…
Design Phase
 Analysis model is refined and adapted to the
environment
 Can be separated into two stages
 System design
 Concerned with overall system architecture
 Object design
 Implementation details are added to system design
Implementation Phase
 Design is implemented using a programming language
or database management system
7/6/2021
Chapter 1 Introduction to OOSAD
Structured analysis and design vs. object
oriented analysis and design
Similarities
 Both SAD and OOAD had started off from programming techniques.
 Both techniques use graphical design and graphical tools to analyze
and model the requirements.
 Both techniques provide a systematic step-by-step process for
developers
 Both techniques focus on documentation of the requirements
7/6/2021
Chapter 1 Introduction to OOSAD
46
Structured analysis and design vs. object
oriented analysis and design
Differences
 SAD is Process-Oriented
 OOAD combines data and the processes
 OOAD encapsulates as much of the system’s data
and processes into a single construct called
objects, while SAD separates between them.
7/6/2021
Chapter 1 Introduction to OOSAD
47
Summary of Structured vs OO
Paradigms
 Structured analysis treats data and processes as separate components
 The Environmental Model:
- Statement of Purpose, Context Diagram, and Event List
 The Behavioural Model:
- Data Flow Diagram, Process Specification, Data
Dictionary, and Entity-Relationship Diagram
 The Implementation Model:
- Structure Diagram
 Object-oriented (O-O) analysis, combines data and processes into
objects.
7/6/2021
-The Object-Oriented development life cycle consists of progressively developing an object
representation through three phases analysis, design, and implementation
Chapter 1 Introduction to OOSAD
48
49
3. The OO Software Process Models
 Software Process:
 A structured set of activities required to develop a software system(
product).
 i.e. the steps we go through to develop a software product is called a
software process.
 We have many different software processes, but all involve the
following activities.
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the system
and implementing the system;
 Verification and Validation – checking that the software does what the
customer wants;
 Evolution – changing the system in response to changing customer
needs.
7/6/2021
Chapter 1 Introduction to OOSAD
50
Software Process - Activities
 Real software processes are inter-leaved sequences of
 technical,
 collaborative and
 managerial activities
with the overall goal of specifying, designing, implementing,
testing(verification and validation), and maintaining a software system.
 The four basic software process activities: specification,
development, verification and validation and evolution
are organized differently in different development processes.
 In the waterfall model, they are organized in sequence,
whereas in incremental development they are inter-leaved.
7/6/2021
Chapter 1 Introduction to OOSAD
Software Process Activities Specification
 The process of establishing what services are required and the constraints on
the system’s operation and development.
 Requirements Engineering Process
 Feasibility study
 Is it technically and financially feasible to build the system?
 ROI, product Vision, what market share are we after? Urgency of development?
 Requirements elicitation and analysis
 What do the system stakeholders require or expect from the system?
 Recognition that the client must be satisfied. Have checkbook.
 Requirements Specification
 Defining the requirements in detail. These are the ‘whats’ of a system!!!
 Requirements Validation
 Checking the validity of the requirements
 Are they feasible, testable, sufficient, necessary, consistent ...
7/6/2021
Chapter 1 Introduction to OOSAD
51
52
The Requirements Engineering Process
7/6/2021
Chapter 1 Introduction to OOSAD
53
Software Processes Activities - Software Design and Implementation
 The process of converting the system specification into an
executable system.
 Software Design (inputs: specifications)
 Design a software structure that realizes the specification;
 Implementation
 Translate this model / structure into an executable app;
 Programming is the implementation of the design.
 The activities of design and implementation are closely related and
may be inter-leaved and definitely are using many modern
development processes. (more to come on this)
7/6/2021
Chapter 1 Introduction to OOSAD
A General Model of the Design Process
7/6/2021
Chapter 1 Introduction to OOSAD
54
55
Software Process Activities - Software Validation
 Involves checking and review processes and system
testing.
 Verification and validation (V & V) is intended to show
that a system conforms to its specification and meets the
requirements of the system customer.
 Look up the difference between verification and validation??
 System testing involves executing the system with test
cases that are derived from the specification of the real data
to be processed by the system.
 Testing is the most commonly used “V & V” activity.
 Test First Development approach integrates testing,
programing and debugging.
7/6/2021
Chapter 1 Introduction to OOSAD
56
Software Process Activities - Software Validation(2)
 Stages of Test Specifications and Testing
7/6/2021
Chapter 1 Introduction to OOSAD
57
Software Evolution
Software is inherently flexible and can change.
As requirements change through changing
business circumstances, the software that
supports the business must also evolve and
change.
Although there has been a demarcation between
development and evolution (maintenance) this
is increasingly irrelevant as fewer and fewer
systems are completely new (greenfield
engineering is rare).
7/6/2021
Chapter 1 Introduction to OOSAD
58
Systems Development Methodology
 Systems Development methodology is a set of
comprehensive guidelines for SDLC that includes specific
models, tools, and techniques.
 Models: are representations of an important aspect of the real
world. Sometimes, the term abstraction is used because we
abstract (separate out) an aspect that is of particular importance .
 Tools: Are software support that helps create models or other
components required in the project. Integrated development
environments (IDEs) include many tools to help with programming
tasks.
 Techniques: Are collections of guidelines that helps an analyst
complete an activity or task
7/6/2021
Chapter 1 Introduction to OOSAD
Models, Tools, and Techniques Cont’d…
 Some models of system components







Flowchart
Data flow diagram (DFD)
Entity-relationship diagram (ERD)
Structure chart
Use case diagram
Class diagram
Sequence diagram
 Some models used to manage the development process
 Gantt chart
 Organizational hierarchy chart
 Financial analysis models – Net Present Value(NPV), payback period
7/6/2021
Chapter 1 Introduction to OOSAD
59
Models, Tools and Techniques Cont’d…
Examples of Tools.
 Project management application
 Drawing/graphics application
 Word processor/text editor
 Visual modeling tool
 Integrated development environment (IDE)
 Database management application
 Reverse-engineering tool
 Code generator tool
7/6/2021
Chapter 1 Introduction to OOSAD
60
Models, Tools and Techniques Cont’d…
 Examples of Techniques
 Strategic planning techniques
 Project management techniques
 User interviewing techniques
 Data-modeling techniques
 Relational database design techniques
 Structured programming technique
 Software-testing techniques
 Process modeling techniques
 Domain modeling techniques
 Use case modeling techniques
 Object-oriented programming techniques
 Architectural design techniques
 User-interface design techniques
7/6/2021
Chapter 1 Introduction to OOSAD
61
62
Methodology (Models, tools and Techniques)
7/6/2021
Chapter 1 Introduction to OOSAD
63
Software Process Model
 Software development life cycle (SDLC) encompasses the
phases/processes that a software developer goes through when
developing software.
 Phases: Systems Planning and Selection  Systems Analysis  Systems
Design Systems Implementation and Operation.
 A software process model is an abstract representation of a software
process. It presents a description of a software process from some
particular SDLC Methodology perspective.(Development Paradigm
 Structured Vs OO)
 Software Process descriptions involve activities such as specifying a
data model, designing a user interface, etc. and the ordering of these
activities.
7/6/2021
Chapter 1 Introduction to OOSAD
64
Software Process
Process descriptions may also include:
 Products, which are the outcomes of a process
activity;
 Roles, which reflect the responsibilities of the
people involved in the process;
 Pre- and post-conditions, which are statements
that are true before and after a process activity has
been enacted or a product produced.
7/6/2021
Chapter 1 Introduction to OOSAD
Plan-driven and Agile Processes
a.k.a. Heavy-Weight versus Light-Weight Models
 Plan-driven processes are processes where all of the process
activities are planned in advance and progress is measured against
this plan.
 Plan drives everything!
 Separate and distinct phases of specification and development.
 In Agile Processes, planning is incremental and it is easier to
change the process to reflect changing customer requirements.
 Specification and development are interleaved
 In practice, most practical processes include elements of both plandriven and agile.
 There are no right or wrong software processes!
7/6/2021
Chapter 1 Introduction to OOSAD
65
Plan Driven vs Agile Processes Characteristics
Agile
Plan Driven
Project is small (5–10 people).
Project is large (more than 10 people).
Experienced teams with a wide range of
abilities and skills take part
Teams include varied capabilities and skill sets.
Project is an in-house project, and the team is
co-located.
Project is of strategic importance (e.g., an
enterprise initiative); scope crosses the
organization. Teams are geographically
distributed and/or outsourced.
System is new, with lots of unknowns.
System is well understood, with a familiar
scope and feature set.
Requirements and environment are volatile,
with high change rates.
Requirements are fairly stable (low change
rates) and can be determined in advance.
Relationship with customer is close and
collaborative.
System is large and complex, with critical
safety or high reliability requirements.
Customer is readily available, dedicated, and
co-located.
Project stakeholders have a weak relationship
with the development team.
7/6/2021
Chapter 1 Introduction to OOSAD
66
Plan Driven vs Agile Processes Characteristics
Agile
Plan Driven
Rapid value and high-responsiveness are
required.
Focus is on strong, quantitative process
improvement.
High trust environment exists within the
External legal concerns (e.g., contracts, liability,
development teams, between the development formal certification against specific industry
teams, and with the customer.
standards) exist.
End-user environment is flexible.
Predictability and stability of process are
important.
Definition and management of process are
important.
7/6/2021
Chapter 1 Introduction to OOSAD
67
68
Software Process Models
There are hundreds of different
process models to choose from
The following are some Examples
 Waterfall, •
 Spiral •
 Rapid prototyping •
 Agile methods: extreme programming (XP), Scrum,
RUP
7/6/2021
Chapter 1 Introduction to OOSAD
Waterfall( Structured, Traditional)
process
7/6/2021
Chapter 1 Introduction to OOSAD
69
70
Heavy-Weight Process Model- Waterfall.
 Example: The Waterfall Model









7/6/2021
Plan-driven model.
Separate and distinct phases of specification and development.
Heavily oriented towards documentation (documentation-intensive)
Progress often measured through documentation completion and reviews
(many)
Lockstep approach
Little chance for Change!
Oftentimes discover major flaws too late.
Delivered as Big Bang
Still exists in spades – but modified to a degree.
Chapter 1 Introduction to OOSAD
71
Waterfall Phases
7/6/2021
Chapter 1 Introduction to OOSAD
72
Waterfall Problems
7/6/2021
Chapter 1 Introduction to OOSAD
Waterfall Problems Cont’d…
 There are separate identified phases in the waterfall
model:





Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
 The main drawback of the waterfall model is the difficulty
of accommodating change after the process is underway.
In principle, a phase has to be complete before moving
onto the next phase.
 But many issues are true too, such as risk addressing.
7/6/2021
Chapter 1 Introduction to OOSAD
73
74
Waterfall Model Problems
 Inflexible partitioning of the project into distinct stages makes
it difficult to respond to changing customer requirements.
 Therefore, this model is only appropriate when the requirements are wellunderstood and changes will be fairly limited during the design process.
 However, Few business systems have stable requirements.
 The waterfall model is mostly used for large systems
engineering projects where a system is developed at several
sites.
 In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.
7/6/2021
Chapter 1 Introduction to OOSAD
Iterative and Incremental (Evolutionary)
development
 It is a cyclic software development process developed in response
to the weaknesses of the waterfall model.
 Evolutionary Developments can be
 Type 1: Exploratory Development: customer assisted development
that evolves a product from ignorance to insight, starting from core,
well understood components.(Spiral Model, Agile Methods…are
examples)
 Type 2: Throwaway Prototyping: customer assisted development
that evolves requirements from ignorance to insight by means of
lightweight disposable prototypes.( Rapid Prototyping is an example)
 Iteration is an essential part of the current Rational Unified
Process(RUP), the Dynamic Systems Development Method(DSDM),
Extreme Programming(XP) and generally the agile software
development.
7/6/2021
Chapter 1 Introduction to OOSAD
75
Iterative and Incremental (Evolutionary)
development
7/6/2021
Chapter 1 Introduction to OOSAD
76
Boehm’s Spiral Model - heavyweight
model
 Process is represented as a spiral rather than as a sequence of
activities with backtracking.
 Extends waterfall model by adding iteration to explore/manage
risk
 Each loop in the spiral represents a phase in the process.
 No fixed phases such as specification or design - loops in the
spiral are chosen depending on what is required.
 Risks are explicitly assessed and resolved throughout the
process.
 This was the motivation behind developing the Spiral Model – Risk
 Key idea: on each iteration, identify and solve the subproblems with the highest risk.
7/6/2021
Chapter 1 Introduction to OOSAD
77
78
Boehm’s Spiral Model of the Software Process
7/6/2021
Chapter 1 Introduction to OOSAD
79
Spiral Model- the Sectors
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the key risks.
 Development and validation
 A development model for the system is chosen which can be any of the
generic models. Development takes place.
 Planning
 The project is reviewed and the next phase of the spiral is planned.
7/6/2021
Chapter 1 Introduction to OOSAD
80
Spiral Model Usage Context
 It is a software development process combining
elements of both prototyping-in-stages and sequential
waterfall models
 combines advantages of top-down and bottom-up concepts.
 is intended for large, expensive and complicated
projects.
 Spiral model has been very influential in helping people
think about iteration in software processes and
introducing the risk-driven approach to development.
 In practice, however, the model is rarely used as
published for practical software development.
7/6/2021
Chapter 1 Introduction to OOSAD
81
Rapid Prototyping - Heavyweight Model
Building a scaled-down working version of the
system
 Analysts work with users to determine the initial &
basic requirements for the system.
 The analyst then quickly builds a prototype.
 When the prototype is complete, the users work with
him/her & tell what they like & don’t like about it.
 The analyst uses this feedback  improve the prototype &
takes the new version back to the users
 This iterative process continues until the users are
relatively satisfied.
7/6/2021
Chapter 1 Introduction to OOSAD
Rapid Prototyping Cont’d…
 Advantages:
 Users are involved in the A&D process
 Captures requirements in concrete form, rather than
verbal/abstract form
 Disadvantages






7/6/2021
Insufficient analysis
User confusion of prototype and finished system
Developer misunderstanding of user objectives
Developer attachment to prototype
Excessive development time of the prototype
Expense of implementing prototyping
Chapter 1 Introduction to OOSAD
82
Great Dissatisfaction with Heavy-Weight
Models
Delivered late,
over budget,
Failure to meet functional and non-functional requirements,
not responsive to change,
poor assessment of risk, ....
Discovery of major problems late….
Thinking about Process…..Want to refine the way we develop systems
Hierarchy:
Successful, Challenged; Failed
Few systems totally successful
Many ‘challenged’
Too many failures
Many famous practitioners starting at Process in more detail
How can we do better?
7/6/2021
Chapter 1 Introduction to OOSAD
83
Agile Methods – lightweight Methods
7/6/2021
Chapter 1 Introduction to OOSAD
84
85
Agile Manifesto ( Agile Principles)
7/6/2021
Chapter 1 Introduction to OOSAD
Different Agile Development
Methodologies
RUP
SCRUM
XP
FDD
DSDM
Kanban
Crystal
7/6/2021
Chapter 1 Introduction to OOSAD
86
87
The Unified Process(UP)
 The unified process (Jacobson, Booch, and
Rumbaugh 1999) is a framework from which
software development processes are instantiated,
 Two such instantiations are the
 Rational Unified Process(RUP)
 A four-phased (inception, elaboration, construction, transition),
prescriptive process whose scope is software development process
 Is also one of the most popular realizations of the iterative approach for
object-oriented development.
 Enterprise Unified Process (EUP)
 Extends RUP to make it a full-fledged IT process( beyond
development)
7/6/2021
Chapter 1 Introduction to OOSAD
88
Rational Unified Process(RUP) Model
 Is based on the process of UML and standard OOAD.
 Unlike the waterfall model where phases are equated with process
activities, phases in the RUP are more closely related to business
rather than technical concerns.
 Four Phases




Inception
Elaboration
Construction
Transition
These indicate the state of the system at each phase NOT the
activities involved at that point in development
7/6/2021
Chapter 1 Introduction to OOSAD
89
RUP Process Perspectives
The RUP recognizes that conventional process
models present a single view of the process.
In contrast, the RUP is normally described
from three perspectives:
1. A dynamic perspective, which shows the phases of the model over
time.
2. A static perspective, which shows the process activities that are
enacted.
3. A practice perspective, which suggests good practices to be used
during the process.
7/6/2021
Chapter 1 Introduction to OOSAD
90
Rational Unified Process(RUP)- Phases
Phases (stages) of Development
 Inception – the initial work required to set up and agree
terms for the project.
Includes establishing the business case
 Feasibility
 Basic risk assessment
 Scope of the system to be delivered
7/6/2021
Chapter 1 Introduction to OOSAD
91
Rational Unified Process(RUP)
Phases (stages) of Development
 Inception
 Elaboration – deals with putting the basic architecture of the system in
place
 All main project risks are identified
 Develop an understanding of the problem domain and the system architecture.
 Construction
 Transition
7/6/2021
Chapter 1 Introduction to OOSAD
92
Rational Unified Process(RUP)
Phases (stages) of Development
 Inception
 Elaboration
 Construction – involves bulk of work on building the system
 System design, programming and testing
 Ends with beta-release of system
 Transition
7/6/2021
Chapter 1 Introduction to OOSAD
93
Rational Unified Process(RUP)
Phases (stages) of Development
 Inception
 Elaboration
 Construction
 Transition – process involved in transferring the system to the
clients and users
 Deploy the system in its operating environment
7/6/2021
Chapter 1 Introduction to OOSAD
Rational Unified Process(RUP) Workflows
 The activities implied by the stages in a traditional structured process modelling
approach are referred to as Workflows in the (RUP) object-orientated approach.
 RUP Workflows Basic Workflows:
 Business modelling
 Requirements




Analysis
Design
Implementation
Testing
 Deployment
Support Workflows
 Configuration and Change Management
 Project Management
 Environment
7/6/2021
Chapter 1 Introduction to OOSAD
94
RUP Phases and Workflows –
interactions
7/6/2021
Chapter 1 Introduction to OOSAD
95
96
Schedule-oriented terms in the UP
development cycle
iteration
inc.
elaboration
milestone
An iteration endpoint when some
significant decision
or evaluation
occurs.
7/6/2021
phase
construction
transition
release
increment
A stable executable
subset of the final
product. The end of
each iteration is a
minor release.
The difference
(delta) between the
releases of 2
subsequent
iterations.
Chapter 1 Introduction to OOSAD
final production
release
At this point, the
system is released
for production use.
RUP- Phases, Milestones, workflows and
Iterations overtime
7/6/2021
Chapter 1 Introduction to OOSAD
97
98
The shifting focus of Iteration rounds
7/6/2021
Chapter 1 Introduction to OOSAD
99
RUP Basic Workflows
Workflow
Description
Business modelling The business processes are modelled using business use cases
Requirements
Actors who interact with the system are identified and use cases are
developed to model the system requirements.
Analysis and
design
A design model is created and documented using architectural models,
component models, object models, and sequence models.
Implementation
The components in the system are implemented and structured into
implementation sub-systems. Automatic code generation from design
models helps accelerate this process.
Testing
Testing is an iterative process that is carried out in conjunction with
implementation. System testing follows the completion of the
implementation.
Deployment
A product release is created, distributed to users, and installed in their
workplace
7/6/2021
Chapter 1 Introduction to OOSAD
100
RUP Support Workflows
Workflow
Description
Configuration and change
management
This supporting workflow manages changes to the system
Project management
This supporting workflow manages the system
development
Environment
This workflow is concerned with making appropriate
software tools available to the software development team.
7/6/2021
Chapter 1 Introduction to OOSAD
Rational Unified Process(RUP) –iteration
cycles
Iterative Process  Workflows may be carried out during any phase of the system
development
 In each phase, a range of workflows (activities) may be carried out
several times before moving on to the next phase.
 The concept of an iteration is pretty much the same across most
software development methods. What differs is the recommended
duration for each iteration.
 XP recommends that iterations be one or two weeks long, if
possible.
 SCRUM specifies that all iterations (sprints) should be 30 days
long.
 RUP recommends that iterations be two to six weeks long.
7/6/2021
Chapter 1 Introduction to OOSAD
101
Enterprise Unified Process(EUP)- Enactment of RUP – read more if
interested
7/6/2021
Chapter 1 Introduction to OOSAD
102
103
OO Software development best practices
 The practice perspective on the RUP describes
good software development practices that are
recommended for use in systems development.
 Six fundamental best practices are recommended:
 Develop software iteratively.
 Manage requirements Explicitly
 Use component-based architectures(re-usable)
 Visually model software.
 Verify software quality.
 Control changes to software
7/6/2021
Chapter 1 Introduction to OOSAD
104
Water fountain for OO Software Development
Water fountain life cycle
describes the inherent
iterative and incremental
qualities of object-oriented
development methods
7/6/2021
Chapter 1 Introduction to OOSAD
105
Process Patterns
 A process pattern describes a collection of general techniques, actions, and/or tasks
for developing object-oriented software.
 Process patterns are an excellent mechanism for communicating approaches to
software development that have proven to be effective in practice.
 Process patterns are the reusable building blocks from which your organization will
develop a tailored software process that meets its exact needs.
 three types of process patterns
 Task process patterns: depicts the detailed steps to perform a specific task, such as the Technical
Review and Reuse
 Stage process patterns: depicts the steps, which are often performed iteratively, of a single project
stage(A project stage is a higher-level form of process pattern- often composed of several task process
patterns)
 Phase process patterns: depicts the interactions between the stage process patterns for a single
project phase, such as the inception and transition phases in RUP
7/6/2021
Chapter 1 Introduction to OOSAD
106
Process Patterns examples
 The Technical Review task process pattern describes how to organize,
conduct, and follow through on the review of one or more deliverables.
 The stage process pattern, Program describes the iterative
tasks/activities of programming( writing a code).
 There is more to this stage than simply writing source code: you need to
understand the models, then seek out reusable artifacts to reduce your work load,
then document what you are going to write, then write the code, then inspect and
improve it, then test and fix it, and then finally package it.
7/6/2021
Chapter 1 Introduction to OOSAD
107
Process Patterns examples
 Phase Process Patterns – Construction
 The Construction phase effectively ends when a code/development freeze has been
declared.
 For a code/development freeze to be official, the following deliverables must be in place
(when applicable):




Models (Class Model, Use-Case Model, Sequence Diagrams, …),
Requirements Allocation Matrix (RAM),
Source code,
Master Test/QA Plan,




User Documentation,
Operations Documentation,
Support Documentation, t
he software itself,
 Training Plan,
 Release Plan, and
 Lessons Learned.
7/6/2021
Chapter 1 Introduction to OOSAD
End of Chapter 1
7/6/2021
Chapter 1 Introduction to OOSAD
108