You are on page 1of 25

Object oriented system

development life cycle


Software Development Process

Software development can be viewed as a


process.
Development is a process of change, refinement,
transformation or addition to existing product.
Each process can be divided into small, interacting
Sub-processes.
must be defined in such a way that each activity be
performed as independently as possible from other
sub-processes.
Each sub-process must have the following
 Description in terms of how it works
 Specification of input required for the process
 Specification of the output to be produced
 Software development process can be viewed as a
series of transformations, where the output of one
transformation becomes the input of the subsequent
transformation.
Transformation 1 (Analysis)
translates user’s need into system’s requirements & responsibilities.
 how they use system can give insight into requirements,

Transformation 2 (Design)
begins with problem statement, ends with detailed design that can
be transformed into operational system.
includes development activity, definition on how to build software,
its development, its testing.
Also includes design descriptions, programs and testing material.

Transformation 3 (Implementation)
 refines detailed design into system deployment that will satisfy
users needs.
represents how to embed software product within its operational
environment
Example of Software Development Process
Why Waterfall Model Fails

Assumes requirements are known before design


begins.
Assumes requirements remain static over
development cycle.
Assumes sufficient design knowledge to build
product.
Problem , if environment changes.
Building High Quality Software
High Quality Products
Must meet user's need and expectations.
This should be attained with
 minimal or no defects
 Concentrate on improving the products (or services) prior to delivery
rather than correcting after delivery.
To achieve high quality software, we need to be able to
answer the following questions.
How do we determine when the system is ready for use?
Is it an operational system that satisfies user's needs?
Is it correct and operating as we thought it should?
Does it pass an evaluation process?
Four Quality Measures (By Blum)
Correspondence:
measures how well the delivered system matches the needs
of the operational environment as described in the original
requirements statement.
Validation :
Am I building the right product?
 Correctness :
measures the consistency of the product requirements with
respect to design specification.
Verification :
exercise of determining correctness.
Am I building the product right?
Object-Oriented Systems Development: Use-Case Driven Approach

Object-Oriented software development life


cycle (SDLC) consists of three macro processes.
 Object-Oriented Analysis
 Object-Oriented Design
 Object-Oriented Implementation
OOSDLC

Object-Oriented systems development includes the


following activities.
 Object-Oriented Analysis – Use Case Driven
 Object-Oriented Design
 Prototyping
 Component Based Development
 Incremental Testing
Object-Oriented Analysis – Use Case Driven

Concerned with determining the systems


requirements and identifying classes and their
relationships to other classes in the problem domain.
 User need -> System needs -> objects & classes
Scenario's can be used to help analysts understand
requirements.
Jacobson's concept of use-case can be used to
describe the user-computer system interaction.
Object-Oriented Analysis – Use Case Driven

Use Case, is a name for a scenario to describe the user–


computer system interaction.
To understand system requirements need to
identify
 who are the actors ?
 How do they use system ?
Use case model represents the user's view of the system or
user's needs.
Developing use cases is iterative.
Documentation must also be carried out. It
should be as short as possible.
80-20 rule
 80% work can be done with 20% documentation
 20% easily accessible, 80% available to few who needs to know
 good modeling implies good documentation
Object-Oriented Design

Goal is to design the classes identified during the


analysis phase and the user interface.
Additional objects and classes that support
implementation of the requirements are also identified
and defined.
First, build the object model based on objects and
their relationships, then iterate and refine the model:
 Design and refine classes
 Design and refine methods
 Design and refine structures
 Design and refine associations
Guidelines to use OO Design
 Reuse rather than build a new class.
 Design a large no. of simple classes rather than a small no. of
complex classes.
 Fully understand what you have proposed. If possible, go back
& refine the classes.
Prototyping

A prototype is a version of a software product developed in the early


stages of the product's life cycle for specific, experimental purpose.
Categories of Prototype
 Horizontal Prototype
• Is a simulation of the interface but contains no functionality.
• Advantages:
 Quick to implement.
 Provides a good overall feel of the system.
 Allows users to evaluate the interface on the basis of their normal, expected perception of
the system.
Vertical Prototype
• Is a subset of the system features with complete functionality.
• Advantages
 Few implemented functions can be tested in greater depth.
The prototype can be reviewed by end users and
management members. Purpose of review
 To demonstrate that the prototype has been developed
according to the specification and that the final specification is
appropriate.
 To collect information about errors or other problems in the
system.
 To give management and everyone connected with the project
the glimpse of what the technology can provide.
Implementation

Move from custom development to assembly from


prefabricated components.
Can produce large markets, low cost, high quality
products.
Moving value & differentiation gained by rapid
customization to targeted customers.
Software component

Functional units of programs, building block offering


collection of reusable services.
 Can request service form another component or
deliver its own services on request.
 Delivery of services is independent, components
work together to accomplish task.
Components may depend on one another without
interfering with each other.
Each component is unaware of context/inner
workings of other components.
Implementation: Component Based Development

Industrialized approach to system development,


move form custom development to assembly of pre-
built, pre-tested, reusable software components that
operate with each other.
Idea of CBD:
 Application development improved significantly if applications
assembled quickly from prefabricated software components.
 Increasingly large collection of interpretable software
components could be made available to developers in both
general & specialist catalogs.
Incremental Testing

After each phase carry out the testing process to


detect bugs if any.
This reduces the overall time and cost.
Reusability

Major benefit of OO system development.


For objects to be reusable, much effort must be spent in
designing itself.
Effectively evaluate existing software components for reuse
 Has my problem been solved ?
 Has my problem been partially solved ?
 What has been done before to solve problem similar to this one ?
Benefits
 Increased reliability.
 Reduced time and cost for development
 Improved consistency
Reuse Strategy

Information hiding.
 Conformance to naming standards.
 Creation & administration of an object repository.
 Encouragement by strategic management of reuse
as opposed to constant redevelopment.
Establish target for percentage of the objects in the
project to be reused.

You might also like