OBJECT ORIENTED SYSTEM

ANALYSIS AND DESIGN

Mulugeta A.

1
 CHAPTER -ONE
Outline
 Introduction
 SW characteristics
 History
 Issues
 Software Engineering
 Process model
 Selection of process model
 Comparison of process model

2
Characteristics
Building SW is inherently different from HW or any other
engineering system

1. SW is developed, not manufactured in the traditional

sense since it is intangible

 Although some similarities exist between software

development and hardware manufacturing, the two
activities are fundamentally different
 High quality can be achieved through good design in both
 Both are dependent on people
 Manufacturing for HW can introduce quality problems,
but can be corrected for SW
3
Characteristics (Cond..)
2. HW wears out
Failure rate Vs time for
HW
Bathtub curve
Bathtub curve Infant Wear out Failure rate
Failure Rate
Mortality
exhibits rises again as
relatively high time passes due
failure rate early to cumulative
in its life due to effects of dust,
design/manufact Time vibration etc on
uring defects Failure rate drops to a steady state HW
for some time as defects are components
corrected
HW begins to wear out – can be replaced with a spare part
4
Characteristics (Cond..)
2. SW does not wear out – not susceptible to environmental changes
Idealized curve exhibits relatively
high failure rate early in its life
Increased failure
due to undiscovered defects
rate due to side
effects Failure rate drops and flattens as
Failure

defects are corrected – according

Actual to theory
Rate

curve SW will undergo changes during its

change lifetime.
Idealized
curve As changes are introduced, it may
result in new defects causing the
Time failure rate curve to spike.
Failure rate Vs time for SW
Slowly, the minimum failure rate
level begins to rise

SW deteriorates due to change – due to error in process/ design

5
History
 Small programs – single person – easy to implement
the application
 User + Programmer – no other person involved –
 Late 1960’s – 360 OS project – resulted in over
budget, behind schedule – SW crisis
 Relies much on experience and judgment rather than
on mathematical techniques .
Realized – SE should be approached like other
engineering disciplines

6
Initial Software Model

 Early days of Computing – code and fix

model

 Denotes a development process neither

preciously formulated nor carefully
controlled;
 consisted of 1) write code, 2) fix it to
eliminate errors
 Source of many difficulties and deficiencies,
messy for subsequent fixes, less reliable
7
Issues – in building large systems
 Not well understood by everyone
 Lot of time spent in communicating with one another rather
than writing code
 People left the project in between – affected the people who
worked under them
 Change in original system requirements affected the system
delivery
 Difficulty for SW projects to meet delivery deadlines
 High cost of SW development
 Errors in delivered SW after extensive testing
 High cost in time and effort in maintaining software
 Problems in measuring progress during development and
maintenance

8
 Solutions
New Approaches
 Development of current SW engineering practice
 Better management techniques
 Different team organization
 Better tools

Term – Software Engineering – coined in 1968 –

Response to a desolate state of the art of developing
quality software on time and budget

Emphasis shifted from coding to development of

practices, methodologies, tools etc

9
 Software Engineering
Software Engineering is defined as the systematic approach to the development,
operation, and maintenance of software
– IEEE Software Engineering Standards

Systematic Approach :
Implies that methodology are used for developing
software which are repeatable
Goal :
 To take SW development closer to science and engineering
and away from ad-hoc approaches for development whose
outcomes are not predictable
 To systematically develop software to satisfy the needs of
clients (the people whose needs are to be satisfied by the
software)
10
Initial Software Model (Cond..)
 Code and Fix model was not suitable to deal with
the new SW age. Why?
 Increased size of the system being developed

 Turnover of SW professionals from the working

project
 Training difficult – due to poor documentation

 Fixing code – no anticipation changes

 Removing errors – requires major restructuring

of the existing code

Need for a design phase before coding

11
 Frequent Discovery – SW did not match the
user’s expectations, product rejected/re-
developed;
 Never ending activity; development process
was unpredictable; over schedule, over
budget, did not meet quality expectations

Need more detailed and careful

analysis of the requirements before
designing and coding
12
Initial Software Model (Cond..)
Failure of code and fix model – led to the recognition
of SW crisis- in turn to the birth of SW engineering as
a discipline

In particular – recognition of a lack of methods in

SW production process – led to the concept of SW life
cycle

There are many steps and activities involved in

building a software product.
The order in which the steps are performed defines
life cycle
13
Initial Software Model (Cond..)
Software Production Process : Suggests a systematic sequential
approach to SW development that begins at the system level
and progresses through analysis, design, coding, testing and
support

SW Process models have a twofold effect :

 they provide guidance to software engineers on the order in
which the various technical activities should be carried out
within a project

 provide a framework for managing development and

maintenance- enable to estimate resources, define
intermediate milestones, monitor progress etc

14
Process Models

 Code and Fix model

 Waterfall/Linear Sequential model
 Prototype model
 Evolutionary model
 Spiral model

15
Waterfall Model
Feasibility
FeasibilityStudy
Study

Requirement
RequirementAnalysis
Analysis
And Specification
And Specification
Design
Designand
and
Specification
Specification
Coding and
Coding and
Module Testing
Module Testing
 Document Driven Integration
Integrationand
and
System Testing
System Testing
 The phases don't overlap
Delivery
Delivery
 i.e design can’t begin until analysis is
finished Maintenance
Maintenance

16
Feasibility Study
 Main aim – determine whether developing the product is
financially and technically feasible
 Purpose is to produce a feasibility study document that
evaluates the costs and benefits of the proposed application
 Document should contain
 Definition of the problem
 Formulation of different solution strategies
 Alternative solutions and their expected benefits
 Cost/benefit analysis performed – determine which
solution is the best
 Any solution – not feasible – due to high cost, resource
constraints etc
 Required resources, costs, delivery dates in each proposed
alternative solutions
17
Requirement Analysis and Specification (What to solve)

 Studied by the customer and developer .

 New project – much interaction is required between
the user and the developer
 Functional Requirements : what the product does
 Non- Functional Requirements : This may be
classified into the following categories: Reliability
(availability, integrity etc), accuracy, performance,
operating constraints, human-computer interface
issues, portability issues etc
 18
Design Specification (How to solve)

 Description of architecture, module description

and relationships

High level /architectural design : Deals with overall

module structure and organization, rather than the
details of the modules

Detailed design : High level design is refined by

designing each module in detail

19
Coding and Testing
Individual modules are tested before being delivered
to the customers

 Alpha Testing : Carried out by the test team

inside the organization
 Beta Testing : Performed by a selected group of
friendly customers
 Acceptance Testing : Performed by the customer
to determine whether or not to accept the deliver
of the system

20
Maintenance
 Requires much more effort than development phase
 Development : Maintenance effort = 40:60 ratio
 Involves performing any one/more of the following
activities:

Corrective Maintenance : Correcting errors – not
discovered during the product development phase

Perfective Maintenance : Improving the
implementation and enhancing the functionalities
according to customer’s requirements

Adaptive Maintenance : Porting the SW to a new
environment
21
 Strength of Waterfall Model (WFM)
 It is document driven
 It is a good model to use when requirements are well understood
and are quite stable.
 Late changes to requirements or design are limited
 Implementing the product should be postponed until
understanding the objectives well.

Weakness of Waterfall model (WFM)

 The model is inflexible for change as each phase results are
frozen.
This model forces the software developer to completely fulfill the
scope of each phase before moving on.
Requirements must be well-reviewed early
22
Weakness of Waterfall model (con’d)
 Ideal Model - Difficult to practice. Model is
– Linear : Not possible. Need feedback
– Rigid : results of each phase are frozen before proceeding
to the next phase
– Monolithic : All planning is oriented to a single delivery date

When to use Waterfall model

 It works well for products that are well understood.
 It works well for projects that are repeats of earlier work.
 It is suitable with which the development team have a lot of
experience.

23
Prototype Model
 Working prototype of the system should be built first
before the actual SW

 Usually exhibiting limited functionalities, low reliability,

inefficient performance

 In the case where requirements are not clear, Prototyping

may be the most suitable approach.
 Such situations as the following require prototyping:
 
- Users do not have clearly defined procedures and
processes.
- Systems are complex and are not amenable to clear
analysis.
- Requirements are changing due to various reasons:
(markets, regulations, uncommitted management, etc.)
24
Prototype Model

 Reasons for developing prototype:

 To illustrate the input data formats, messages,

reports etc – valuable mechanism to gain better
understanding of the customer’s needs

 Much easier for the customer to form opinion by

experimenting with a working model

 Helps to critically examine the technical issues

associated with the product development (efficiency
of the sorting algorithm, response time of a HW
controller)

25
Building a Prototype Model
 Begins with requirements gathering

 Developer + customer meet and define overall

objectives

Identify the known requirements + mark ones

which needs further discussion

 Quick design occurs

 Prototype evaluated – requirements refined

Prototype serves as a mechanism for identifying

software requirements
26
Building a Prototype Model
Requirements gathering

Quick design

Refine Requirements Build prototype

Customer
suggestions Customer evaluation –
prototype
Acceptance by user
Design

Implement, Test

Iterative Process
Maintain

27
Prototype Model
 Actual system developed using classical waterfall model

 In development effort, requirement analysis and specification

phase becomes redundant.

 Prototype code – thrown away

 However, experience gained - helps in developing actual system

 Prototype construction – additional cost. But, overall cost

lower than developed using Waterfall model

 Experimenting with prototype - user requirements properly

defined, technical issues satisfactorily resolved

Minimizing change requests & redesign costs after the system is delivered to customer

28
Strengths of the Prototyping Model
• There is a much lower risk of confusion in terms of
miscommunication, misunderstanding user requirements or
system features.

• New or unexpected user requirements can easily be

incorporated.

• Prototyping development costs are offset by avoidance of the

usual high cost of rework and repair.

• The prototype can be used as a formal specification because it

is tangible and well tried.

29
 Weaknesses of the Prototyping Model
• Lack of early planning may cause project management
problems: unknown schedules, budgets and deliverables.
• This Model results in potentially longer development cycles.
• Seeing functions in working mode early in the life cycle
stimulates users into requesting additional functions.

When to use the Prototyping Model?

• When requirements are not known at the beginning of the
project.
• When requirements are unstable and constantly changing.
• When users, for various reasons, do not have the capability of
expressing their requirements clearly.
• When user requires proof of concept

30
Evolutionary Model
 Also known as successive version model
 System – first broken into several modules or
functional units – incrementally developed and
delivered
 Developers first develop core modules – i.e., basic
requirements are addressed, but many
supplementary features remain undelivered
 Initial product skeleton – refined into increasing
levels of capability by adding new functionalities in
successive versions

31
Evolutionary Model
 Each version is a functioning system capable of
performing some more useful work.

 Core modules will be tested thoroughly.

 Disadvantage : difficult to subdivide the problem

 Useful only for very large problems – where it is
easier to identify modules for incremental
implementation

Evolves over a period of time

32
Evolutionary Model

A A A
B
B C

A, B, C are modules of a SW product that are incrementally

developed and delivered
Increment 1

Analysis Design Code Test

Delivery of 1st increment

Increment 2 Delivery of 2nd increment

Analysis Design Code Test

Delivery of 3rd increment

Increment 3
Analysis Design Code Test
Delivery of 4th
Increment 4
Analysis Design Code Test increment

33
Spiral Model
• Focuses on identifying and eliminating high risk problems by
careful process design (Requirement analysis and Design
Phases)
• Consequently, minimum and manageable risks filtered into
development phase

Development cycle is divided into 4 task areas

 Requirement analysis – (identifies the objectives of the portion
of the product, in terms of qualities to achieve, identifies
alternatives – design, buy, reuse )
Risk analysis – (alternatives are evaluated and potential areas
are identified and dealt with)
 Prototype and detailed designing
 Construction, testing and implementation

34
Spiral Model (Cond..)
• Different categories of risks are considered.
• Project risks threaten the project plan.
– That is, if project risks become real, it is likely that project
schedule will slip and that costs will increase.
– Project risks identify potential budgetary, schedule,
personnel (staffing and organization), resource, customer
and requirements problems and their impact on a software
project.

• Technical risks threaten the quality and timeliness

of the software to be produced.
• If a technical risk becomes a reality, implementation may
become difficult or impossible.
• Technical risks identify potential design, implementation,
interface, verification, and maintenance problems.

35
Spiral Model (Cond..)
• Business risks threaten the feasibility of the
software to be built.
• Business risks often put in danger the project or the
product.
• Candidates for the top five business risks are:
– building a excellent product or system that no one really
wants (market risk)
– building a product that no longer fits into the overall
business strategy for the company (strategic risk)
– building a product that the sales force doesn't understand
how to sell
– losing the support of senior management due to a change
in focus or a change in people (management risk)
– losing budgetary or personnel commitment (budget risks).

36
Spiral Model (Cond..)
1- Requirement Analysis
4 5 2 -Risk Analysis
3 -Prototype 1
1 2
4 - Software Requirement
Analysis
9
3 5 - Risk Analysis
6 6- Prototype 2
8 7-Detailed Design
7
8-Construction
9-Testing and Evaluation
 Expects lot of rework in reverting to an earlier phase and incorporating
client feedback
 Needs to perform risk analysis effectively

 To eliminate losses arising due to uncertain dev models, resource req,

time etc
37
Selection of a Process Model
Following criteria can be considered:

Business goals of the organization - Indicates the mindset of an organization

 Past history of developing projects in accordance with well
defined plans – Waterfall
 If it is used to work in an experimental and constant
feedback mode – Prototype
Expected size of the project
 Large size, customers expect all the features at the first
delivery - Waterfall
 Customers want to start unit testing – Evolutionary
(Incremental)
 Size is doubtful – Prototype/Spiral (These models help to
develop projects with vague and uncertain project size)

38
Selection of a Process Model
Customer needs and project requirements
 Customer needs and requirements – certain and approved –

waterfall
 Customer needs and requirements – uncertain and likely to

change in the future –Spiral / Prototype/ Incremental

Availability of funds and development staff

 Adequate resources at the start of the project – Waterfall /

Prototype
 Expecting additional funds and resources – Incremental /

Spiral
Risks perceived in the project
 Risks and impacts are minimum – Waterfall / Incremental

model
 Risks and impacts are high – Spiral model

39
Comparison of Process Models
Strengths Weaknesses Types of projects
Waterfall 
Requirements frozen 
For well

Simple early understood problems

Easy to execute 
Disallows changes 
Short duration project

Cycle time too long 
Automation of

May choose outdated existing manual
HW technology system

User feedback not
allowed
Prototyping 
Front heavy process 
Systems with novice

Helps in 
Possible higher cost users
requirements 
Disallows later changes 
When uncertainties in
refinement requirements

Reduces risk 
When UI very

Lead to a better important
system
40
THANK YOU

?
41