3/25/2023

Chapter Content
Chapter One: Introduction Introduction Object oriented system
development methodology.
Software development  Why an object oriented
process models  Overview of the unified
approach.
Course Title: Software Engineering Software Process  An object-oriented
Software life cycle philosophy
 Basic concepts of an object
and process models Attributes of an object, its state
and properties.

Instructor: Belilign Teferi

3/25/2023 Chapter One: Introduction 2

1.1 Introduction: Overview of Software

Definition
1.Software is instructions on computer programs
that when executed provide desired function and
performance
2.Software is a data structure that enables the
instructions to adequately manipulate information
3.Software is a document that describes the
operations and use of instructions
Introduction: Characteristics of software
To gain more understanding of software, it is important
to examine its characteristics that make it different
from hardware.
 When hardware is built the human creative process
(analysis, design, construction, testing) is ultimately
translated into a physical form. If we build a new
computer, our initial sketches, formal design
drawings, and bread boarded prototype evolve into a
physical product (chips, circuit boards, power supplies
etc.). Software is a logical system than physical one.
Therefore, it is obvious that software has different
characteristics compared to hardware:

3/25/2023 Chapter One: Introduction 3 3/25/2023 Chapter One: Introduction 4


Characteristics of software…
Software is developed or engineered; it is not
manufactured in the classical sense.
In both software development and hardware manufacturing
high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality
problems that is nonexistent ( or easily corrected) for
software.
Both activities are dependent on people, but the
relationship between people applied and work
accomplished is entirely different.
Both activities requires the construction of a “product” but
the approaches are different
Software costs are concentrated in engineering. This means
that software projects cannot be managed as if they were
manufacturing projects
3/25/2023 Chapter One: Introduction
Characteristics of software contd..
The failure rate curve for software should take the
form of the “idealized curve”
 The curve indicates that undiscovered defects will cause high
failure rates early in the life of a program.
 However, these are corrected (ideally without introducing
other errors) and the curve flattens as shown. The idealized
curve is a gross oversimplification of actual failure models for
software.
 Generally, software doesn’t wear out rather it deteriorates.
During its life software will undergo change (maintenance). As
changes are made, it is likely that some new defects will be
introduced, causing the failure rate curve to spike as shown in
the actual curve shown below
3/25/2023 Chapter One: Introduction
3/25/2023
Characteristics of software contd..
The failure rate for hardware depicted by a “bathtub
curve”
 indicates that hardware exhibits relatively high failure rates
early in its life (these failures are often attributable to design or
manufacturing defects); defects are corrected and the failure
rate drops to a steady state level ( ideally quite low) for some
period of time.
 But as time passes the failure rate rises again as hardware
components suffer from the cumulative effects of dust,
vibration, abuse, temperature extremes, and many other
environmental maladies. Simply the hardware begins to wear
out
 Unlike hardware, software is not susceptible to the
environmental maladies that cause hardware to wear out
5 3/25/2023 Chapter One: Introduction 6
Characteristics of software contd..
Failure Rate :idealized curve
 Before the curve can return to the original steady-state failure
rate, another change is requested, causing the curve to spike
again. Slowly, the minimum failure rate level begins to rise.
Hence the software is deteriorating due to change
7 3/25/2023 Chapter One: Introduction 8
 3/25/2023

Characteristics of software contd.. Characteristics of software contd..

When a hardware component wears out, it is replaced

Bathtub Curve Idealized curve by a spare part. There are no software spare parts.
Every software failure indicates an error in design or in
increased failure
rate due to side effects the process through which design was translated into
Failure
rate machine executable code. Therefore, software
maintenance involves considerably more complexity
change
that hardware maintenance
actual curve

idealized curve

Time

3/25/2023 Chapter One: Introduction 9 3/25/2023 Chapter One: Introduction 10

1.2. Software Development Process Models 1.2.1 History of Software Development

System Development refers to all activities that go into Early stage

producing an information systems solution.
System development activities consists of system
analysis, modeling, design, implementation, testing and
maintenance.
A software development methanoyl is a series of
processes that, if followed , can lead to the
development of an application.
The software process describe how the work is to be
carried out to achieve the original goal based on the
system requirements. Further each process consists of
a number of steps and rules that should be performed
during development.
 In the early days of computing, software development was mainly a
single-person task.
 The problem to be solved (very often of a mathematical nature) was
well understood, and there was no distinction between the
programmer and the end user of the application (software).
 The end users (very often a scientist or an engineer) developed their
own software
 The application, by today’s standards, was rather simple. Thus software
development consisted only of coding in some low level language.
 They code and fix method

3/25/2023 Chapter One: Introduction 11 3/25/2023 Chapter One: Introduction 12

 3/25/2023

History of … History of …

New software development age

Code and Fix model  As hardware capacity grew, the desire to apply computers in more
 It’s a development process that is neither precisely formulated application domains, such as business administration, let to
nor carefully controlled. software being used in less and less understood environments.
 A sharp separation arose between software developers and end
 Software production in this model consists of the iteration of two users. End users with little or no technical background in science
steps and mathematics, such as sales agents and personnel
 Write the code and administrators, could not be expected to develop their own
 Fix it to eliminate errors, enhance existing functionality, or add applications, due to both
new features  Software is developed not for personal use, but for people with
little or no back ground in computers. Sometimes software is
 This model is weak. developed in response to a request from a specific customer; other
 In particular, after a sequence of changes, the code structure becomes times , it is developed for the general market. Both of these
so messy that subsequence fixes become harder to apply and the situations add new dimensions to the software that were not
results become less reliable. present in the previous age. Now software is a product that must be
 These problems, however, were not that much serious by the fact that
marketed, sold and installed on different machines at different
sites. Users must be trained in its use and must be assisted when
software were rather simple and the application were well understood something unexpected happens.
by the engineers.

3/25/2023 Chapter One: Introduction 13 3/25/2023 Chapter One: Introduction 14

History of … History of …

New software development age New software development age

 Software is developed not for personal use, but for people
with little or no back ground in computers.
 Sometimes software is developed in response to a request
from a specific customer; other times , it is developed for the
general market.
 Both of these situations add new dimensions to the software
that were not present in the previous age.
 Now software is a product that must be marketed, sold and
installed on different machines at different sites. Users must
be trained in its use and must be assisted when something
unexpected happens.
 Another sharp difference from the previous age is that
software development has become a group activity. Group
work requires carefully taught-out organizational structures
and standard practices, in order to make it possible to predict
and control developments.
 The code and fix process model was inadequate to deal with
the new software age.
 First, the increased size of the systems being developed
made it difficult to manage the complexity in an
unstructured way.
 This problem was made worse by the turnover of software
personnel working on projects.
 Adding new people to an ongoing project was extremely
difficult because of the poor documentation available to
guide them in the task of understanding the application
properly.

3/25/2023 Chapter One: Introduction 15 3/25/2023 Chapter One: Introduction 16


History of …
New software development age
 Inadequacy of the code and fix process model…
 Second, fixing code was difficult because no anticipation of change
was taken into account before the start of coding. Similarly it was
difficult to remove errors that required major structuring of the
existing code. These problems underscored the need for the
design phase prior to coding
 Another problem that makes the code and fix process model
inadequate to the new age is that frequent discovery, after the
system is developed, that the software did not match the user’s
expectations. So the product either was rejected or had to be
redeveloped to achieve the desired goals. Software development
becomes a sort of never ending activity.
 As a result, the development process was unpredictable and
uncontrollable, and products were completed over schedule and
over budget and did not meet quality expectations. Consequently,
it was realize that a more detailed and careful analysis of the
requirements necessary before design and coding started.
3/25/2023 Chapter One: Introduction 17
History of …
 Software Crisis
 Software Crisis
 Problems:
1. Schedule and cost estimates are often grossly inaccurate.
2. The “productivity” of software people hasn’t kept pace with
demand for their services.
3. The quality of software is sometimes less than adequate
4. With no solid indication of productivity, we can’t accurately
evaluate the efficiency of new tools, methods or standards
5. The software maintenance task devours the majority of all
software cost
3/25/2023 Chapter One: Introduction 19
3/25/2023
History of …
New software development age
 The failure of the code and fix process model led to the recognition
of the so-called software crisis (caused by the fact that large
software projects were universally over budget and behind
schedule) and, in turn, contribute to the birth of software
engineering as a discipline (to address software crisis).
Software Crisis
 It is also known as software affliction
 The term includes a set of problems that are encountered in the
development of computer software. The problems are not limited
to software that doesn’t function properly. Rather, the affliction
encompasses problems associated with how we develop software,
how we maintain a growing volume of existing software and how
we can keep pace with the growing demand for more software.
3/25/2023 Chapter One: Introduction 18
History of …
 Causes:
1. Software is a logical rather than a physical system element; therefore,
success is measured by the quality of a single entity rather than by the
quality of many manufactured entities.
2. The intellectual challenge of software development is certainly one cause of
the affliction that affects software but the problems discussed above have
been caused by more mundane human failings.
3. A good manager can manage any project. If he or she is willing to learn
milestones that can be used to measure progress, apply effective methods
of control, disregard mythology and become conversant in rapidly changing
technology.
4. Communication between managers and customers, software developers,
support staff etc. can break down because the special characteristics of
software and the problems associated with its development are
misunderstood
5. The software people responsible for tapping that potential often change
when is discussed and resist change when it is introduced
3/25/2023 Chapter One: Introduction 20

1.2.2 Software processes and Models
From the era of software crisis it was learnt that having structured process
models for system developments is a must to bring change in the software
development industry. It then became the birth of Software Engineering as a
discipline.
What is Software Engineering?
1. is the field of computer science that deals with the building of software
systems that are so large or so complex that they are built by a team or
teams of engineers. Usually these systems exist in multiple versions and
are in service for many years. During their life time, they undergo many
changes: to fix defects, to enhance existing features, to add new
features, to remove old features or to be adapted to run in a new
environment.
2. More precisely, the IEE STD 610.12-1990’s standard glossary for
software engineering terminology (ANSI) defines software engineering s
the application of systematic, disciplined quantifiable approach to the
development, operation and maintenance of software.
3/25/2023 Chapter One: Introduction 21
Software processes…
A software process model is an abstraction of the actual process,
which is being described. It can also be defined as a simplified
representation of a software process. Each model represents a
process from a specific perspective. Basic software process
models on which different type of software process models can
be implemented:
Boehm [1988] the goal of structured process models for system
development are to determine the order of stages involved in
software development evolution, and to establish the transition
criteria for progressing from one stage to the next. These include
completion criteria for the current stage plus choice criteria and
entrance criteria for next stage. According to this view point,
process models have a twofold effect:
 They provide guidance to system development on the order in which
the various technical activities should be carried out within a project
 They provide framework for managing development and maintenance,
in that they enable us to estimate resources, define intermediate
milestones, and monitor progress.
3/25/2023 Chapter One: Introduction 23
3/25/2023
Software processes…
Software processes in software engineering refer to the methods
and techniques used to develop and maintain software.
In software engineering, a software development process is a
process of dividing software development work into smaller, parallel,
or sequential steps or sub-processes to improve design and/or
product management. It is also known as a software development
life cycle (SDLC) or Model.
To solve actual problems in an industry setting, a software engineer
or a team of engineers must incorporate a development strategy
that encompasses the process, methods and tools layers required to
solve the problem. This strategy often referred to as a process model
or a software engineering paradigm.
3/25/2023 Chapter One: Introduction 22
Software processes…
There are various types of software process models
for software Engineers to choose from, taking factors
such as budget, requirement nature, technology used,
complexity of the problem etc. into consideration.
 Waterfall Model
 Incremental Process Models( the incremental model and the RAD model)
 Evolutionary Models(prototyping, the spiral model and concurrent
development Model)
 Specialized Process Models (component based development, formal
methods model and aspect oriented software development)
 Unified Process Model
 Agile Process Models( scrum, XP, TDD and FDD )
3/25/2023 Chapter One: Introduction 24

Software processes…
Waterfall Model
 It was introduced by Winston Royce in 1970 and is currently the most
commonly used model for software development
 It is also referred to as a linear-sequential life cycle model.
 It is very simple to understand and use.
 It is based on developing software in a set of sequential phases.
 Each phase must be completed before the next phase can begin and
there is no overlapping in the phases
 It is the most straight forward model and it is document driven ( at the
end of each phase a document is produced that will be used in the next
phase)
 It views software development as series of processes that are expected
to be done only once for the project. They are to be done in the proper
order and the results are
 One of the most critical features of the Waterfall Model is that the phases do
not overlap.
3/25/2023 Chapter One: Introduction
Software processes…
Waterfall Model: processes..
 Implementation or coding: With inputs from system design, the system is
first developed in small programs called units, which are integrated in the
next phase. Each unit is developed and tested for its functionality which is
referred to as Unit Testing.
 Integration and Testing: All the units developed in the implementation
phase are integrated into a system after testing of each unit. Then the
entire system is tested for any faults and failures. The system is tested by
using the requirement specification document released at the early stage.
Testing can be carried out by different ways
 Alpha testing: Carried out by test team inside the organization
 Beta testing: Performed by a selected group of friendly customers
 Acceptance testing: Performed by the customers who finance the product
 Deployment of system: Once the functional and non functional testing is
done, the product is deployed in the customer environment or released
into the market.
3/25/2023 Chapter One: Introduction
3/25/2023
Software processes…
Waterfall Model: processes
 Requirement Gathering: All possible requirements of the system to be
developed are captured in this phase.
 Requirement analysis and Specification ( what to solve) : All collected
requirements are analyzed, modeled and documented in a requirement
specification doc. Some of the things to be done in this phase are
 Identifying the functional ( what the product does) and the non functional
requirements ( qualities that the product has to posses)
 Expressing the functionalities and behaviors using models
 Defining requirements for system test procedure
 System Design (How to solve): The requirement specifications from first
phase are studied in this phase and system design is prepared. System
Design helps in
 Specifying hardware and system requirements
 Defining 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.
25 3/25/2023 Chapter One: Introduction 26
Software processes…
Waterfall Model: processes..
 Maintenance: There are some issues which come up in the client
environment. To fix those issues patches are released. Also to enhance the
product some better versions are released. Maintenance is done to deliver
these changes in the customer environment. It is actually a lifelong process
and considered as the most costly phase of the model. Maintenance can
be in either of the three forms below
 Integration and Testing: All the units developed in the implementation
phase are integrated into a system after testing of each unit. Then the
entire system is tested for any faults and failures. The system is tested by
using the requirement specification document released at the early stage.
Testing can be carried out by different ways
 Alpha testing: Carried out by test team inside the organization
 Beta testing: Performed by a selected group of friendly customers
 Acceptance testing: Performed by the customers who finance the product
 Deployment of system: Once the functional and non functional testing is
done, the product is deployed in the customer environment or released
into the market.
27 3/25/2023 Chapter One: Introduction 28
 3/25/2023

Software processes… Software processes…

Pros and Cons of Waterfall Model
Pros Cons

 Simple and easy to understand and use
 Easy to manage due to the rigidity of the
model.
 Each phase has specific deliverables and
a review process.
 Phases are processed and completed one
at a time.
 Works well for smaller projects where
requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well
documented.
3/25/2023 Chapter One: Introduction 29 3/25/2023 Object Oriented System Analysis and Design
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long projects.
 Not suitable for the projects where requirements are at a
moderate to high risk of changing. So risk and uncertainty is high
with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 No working software is produced until late in the life cycle.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't
allow identifying any technological or business bottleneck or
challenges early.
30

Software processes… Process Models……: Prototyping

When should we use waterfall Model?

Every software developed is different and requires a
suitable SDLC approach to be followed based on the internal
and external factors. Some situations where the use of
Waterfall model is most appropriate are:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the
product.
 The project is short.
 Works well for projects that are repeats of earlier works like new
versions of a software
 Quite suitable for developing products with which the development
team have experience with similar projects.
The Software Prototyping refers to building software
application prototypes which display the functionality
of the product under development but may not actually
hold the exact logic of the original software.
Software prototyping is becoming very popular as a
software development model, as it enables to
understand customer requirements at an early stage of
development.
It helps get valuable feedback from the customer and
helps software designers and developers understand
about what exactly is expected from the product under
development

3/25/2023 Object Oriented System Analysis and Design 31 3/25/2023 Object Oriented System Analysis and Design 32

Process Models……: Prototyping
Prototype is a working model of software with some
limited functionality.
The prototype does not always hold the exact logic
used in the actual software application and is an extra
effort to be considered under effort estimation.
Prototyping is used to allow the users evaluate
developer proposals and try them out before
implementation.
It also helps understand the requirements which are
user specific and may not have been considered by the
developer during product design
3/25/2023 Object Oriented System Analysis and Design 33
Process Models…….Phases in Prototyping
 Basic Requirement Identification: involves understanding the very basics product
requirements especially in terms of user interface. The more intricate details of the
internal design and external aspects like performance and security can be ignored at
this stage.
 Developing the initial Prototype: The initial Prototype is developed in this stage,
where the very basic requirements are showcased and user interfaces are provided.
These features may not exactly work in the same manner internally in the actual
software developed and the workarounds are used to give the same look and feel to
the customer in the prototype developed.
 Review of the Prototype: The prototype developed is then presented to the customer
and the other important stakeholders in the project. The feedback is collected in an
organized manner and used for further enhancements in the product under
development.
 Revise and enhance the Prototype: The feedback and the review comments are
discussed during this stage and some negotiations happen with the customer based on
factors like, time and budget constraints and technical feasibility of actual
implementation. The changes accepted are again incorporated in the new Prototype
developed and the cycle repeats until customer expectations are met.
3/25/2023 Object Oriented System Analysis and Design 35
3/25/2023
Process Models…… Prototyping: Dimension
 Horizontal prototype displays the user interface for the
product and gives a broader view of the entire system,
without concentrating on internal functions.
 are used to get more information on the user interface level
and the business requirements. It can even be presented in
the sales demos to get business in the market.
 Vertical prototype on the other side is a detailed
elaboration of a specific function or a sub system in the
product.
 technical in nature and are used to get details of the exact
functioning of the sub systems. For example, database
requirements, interaction and data processing loads in a
given sub system.
3/25/2023 Object Oriented System Analysis and Design 34
Process Models…… Types of software Prototyping
 Throwaway/Rapid Prototyping: Throwaway prototyping is also
called as rapid or close ended prototyping. This type of
prototyping uses very little efforts with minimum requirement
analysis to build a prototype. Once the actual requirements are
understood, the prototype is discarded and the actual system is
developed with a much clear understanding of user
requirements.
 Evolutionary Prototyping: Evolutionary prototyping also called
as breadboard prototyping is based on building actual
functional prototypes with minimal functionality in the
beginning. The prototype developed forms the heart of the
future prototypes on top of which the entire system is built.
Using evolutionary prototyping only well understood
requirements are included in the prototype and the
requirements are added as and when they are understood.
3/25/2023 Object Oriented System Analysis and Design 36
 3/25/2023

Process Models…… Types of software Prototyping

 Incremental Prototyping: Incremental prototyping

refers to building multiple functional prototypes of Quick

the various sub systems and then integrating all the plan

available prototypes to form a complete system.

communication

Modeling

 Extreme Prototyping: Extreme prototyping is used in

Quick design

the web development domain. It consists of three

sequential phases. First, a basic prototype with all the
existing pages is presented in the html format. Then Deployment Fig: Evolutionary
the data processing is simulated using a prototype delivery &
feedback Construction
Prototype

services layer. Finally the services are implemented

of prototype

and integrated to the final prototype. This process is

called Extreme Prototyping used to draw attention to
the second phase of the process, where a fully
functional UI is developed with very little regard to
the actual services.
3/25/2023 Object Oriented System Analysis and Design 37 3/25/2023 Object Oriented System Analysis and Design 38

Fig: Throwaway Prototype Pros and Cons of prototyping

Pros Cons
Requirement Elicitation
or Gathering  Increased user involvement in the product  Risk of insufficient requirement analysis owing

Quick Prototype Design even before implementation to too much dependency on prototype
 Since a working model of the system is  Users may get confused in the prototypes and
Prototype displayed, the users get a better understanding actual systems.
Implementation
of the system being developed.  Practically, this methodology may increase the
Prototype Evaluation
By Customer  Reduces time and cost as the defects can be complexity of the system as scope of the
detected much earlier. system may expand beyond original plans.
REQUIREMENTS FOR
Requirements NO CORRECTIONS, CHANGES
Fulfilled ?
 Quicker user feedback is available leading to  Developers may try to reuse the existing
AND ADDITIONS
YES better solutions. prototypes to build the actual system, even
System Design , Coding
and Testing  Missing functionality can be identified easily when its not technically feasible
 Confusing or difficult functions can be  The effort invested in building prototypes may
System Deployment
identified be too much if not monitored properly
SYSTEM OPERATION
AND MAINTENANCE

3/25/2023 Chapter One: Introduction 39 3/25/2023 Object Oriented System Analysis and Design 40

Process Models…… Incremental(Iterative)
In Incremental model, iterative process starts with a
simple implementation of a small set of the software
requirements and iteratively enhances the evolving
versions until the complete system is implemented
and ready to be deployed.
An iterative life cycle model does not attempt to
start with a full specification of requirements.
Instead, development begins by specifying and
implementing just part of the software, which is then
reviewed in order to identify further requirements.
This process is then repeated, producing a new
version of the software at the end of each iteration of
the model.
3/25/2023 Object Oriented System Analysis and Design
Process Models…… Incremental(Iterative)
Iterative and Incremental development is a
combination of both iterative design or iterative
method and incremental build model for
development.
 "During software development, more than one
iteration of the software development cycle may
be in progress at the same time." and "This
process may be described as an "evolutionary
acquisition" or "incremental build" approach."
In incremental model the whole requirement is
divided into various builds.
3/25/2023 Object Oriented System Analysis and Design
3/25/2023
Process Models…… Incremental(Iterative)
Iterative process starts with a simple
implementation of a subset of the software
requirements and iteratively enhances the
evolving versions until the full system is
implemented.
At each iteration, design modifications are made
and new functional capabilities are added.
The basic idea behind this method is to develop a
system through repeated cycles (iterative) and in
smaller portions at a time (incremental).
41 3/25/2023 Object Oriented System Analysis and Design 42
Process Models…… Incremental(Iterative)
During each iteration, the development module goes
through the requirements, design, implementation and
testing phases
Each subsequent release of the module adds function
to the previous release.
The process continues till the complete system is ready
as per the requirement.
The key to successful use of an iterative software
development lifecycle is rigorous validation of
requirements, and verification & testing of each version
of the software against those requirements within each
cycle of the model.
43 3/25/2023 Object Oriented System Analysis and Design 44

Process Models…… Incremental(Iterative)
Fig: Incremental
Model
3/25/2023 Object Oriented System Analysis and Design 45
Process Models…… Incremental(Iterative)
Pros Cons
 Some working functionality can be developed quickly  More resources may be required.
 Although cost of change is lesser but it is
and early in the life cycle.
not very suitable for changing
 Results are obtained early and periodically.
requirements.
 Parallel development can be planned.
 More management attention is required.
 Progress can be measured.
 System architecture or design issues may
 Less costly to change the scope/requirements. arise because not all requirements are
 Testing and debugging during smaller iteration is easy. gathered in the beginning of the entire life
cycle.
 Risks are identified and resolved during iteration; and
 Defining increments may require definition
each iteration is an easily managed milestone.
of the complete system.
 Easier to manage risk - High risk part is done first.
3/25/2023 Object Oriented System Analysis and Design 47
3/25/2023
Process Models…… Incremental(Iterative)
The advantage of this model is that there is a working
model of the system at a very early stage of
development which makes it easier to find functional or
design flaws. Finding issues at an early stage of
development enables to take corrective measures in a
limited budget.
The disadvantage with this SDLC model is that it is
applicable only to large and bulky software
development projects. This is because it is hard to
break a small software system into further small
serviceable increments/modules.
3/25/2023 Object Oriented System Analysis and Design 46
Process Models…… Incremental(Iterative)
Pros Cons
 With every increment operational product is delivered.  Not suitable for smaller projects.
 Issues, challenges & risks identified from each increment can be  Management complexity is more.(
utilized or applied to the next increment.
unknown schedules, budgets and
 Risk analysis is better.
deliverables)
 It supports changing requirements.
 End of project may not be known,
 Initial Operating time is less.
Better suited for large and mission-critical projects. which is a risk.

 During life cycle software is produced early which facilitates  Highly skilled resources are required
customer evaluation and feedback. for risk analysis.
 Budget is spread in to the versions so that initial delivery costs  Project’s progress is highly dependent
are much lower
upon the risk analysis phase.
3/25/2023 Object Oriented System Analysis and Design 48
 3/25/2023

Process Models…… Incremental(Iterative) Process Models…… Incremental(Iterative)

When is best to Use incremental model? When is best to Use incremental model?
Requirements of the complete system are clearly defined
and understood. There are some high risk features and goals which may
change in the future (when it is too risky to develop the
Major requirements must be defined; however, some
functionalities or requested enhancements may evolve with overall system as one block).
time. (some requirements may change during the project With software applications that are regarded by the users
life cycle)
with doubt. Early increments can create the necessary early
With lengthy projects. consensus on the usefulness of the application.
There is a time to the market constraint.
When there is budget constraint to complete the whole
A new technology is being used and is being learnt by the
development team while working on the project. project once
Resources with needed skill set are not available and are
planned to be used on contract basis for specific iterations.

3/25/2023 Object Oriented System Analysis and Design 49 3/25/2023 Object Oriented System Analysis and Design 50

1.3. Object Oriented Information System

Development Methodology
1.3.1 Orthogonal View of a software
Information systems are an outgrowth of a process of
organizational problem solving. An information system is
built as a solution to some type of problem or set of Two Approaches, exist to develop a software
problems the organization perceives it is facing. system :Traditional Approach (structured view)
Systems development refers to all the activities that go into &Modern Approach(Objected-Oriented View)
producing an information systems solution to an The traditional approach views a system as a
organization problem or opportunity. collection of programs where as the object oriented
System development activities consists of system analysis, view consider a systems as a collection of
modeling, design, implementation, testing and interacting objects.
maintenance.
A software development methodology is a series of
processes that, if followed , can lead to the development of
an application

3/25/2023 Object Oriented System Analysis and Design 51 3/25/2023 Chapter One: Introduction 52

1.3.2 System Development Paradigm
Depending on how we view the system the system development
approach also can be structured or object oriented approach.
The Structured Approach
 Views a system in terms of what it is intended to do and then
develop models of procedures and data.
 Is a strategy based on the concept that a system should be
separated into two parts: data(modeled using a data/
persistence model) and functionality( modeled using a
process model)
 Structured methods are action oriented (data flow diagrams);
or data oriented (entity-relationship diagrams); But not both
 Therefore using structured approach we develop applications
in which data are separated from behavior in both the design
model and implementation phase.
3/25/2023 Object Oriented System Analysis and Design
System development..
Modern Approach: OO software development
Methodology
 Took its shape from the initial concept of a new programming
approach, while the interest in design and analysis methods came
much later.
 The object-oriented paradigm The first object–oriented language
was Simula (Simulation of real systems) that was developed in 1960
by researchers at the Norwegian Computing Center.
 In 1970, Alan Kay and his research group at Xerox PARK created a
personal computer named Dynabook and the first pure object-
oriented programming language (OOPL) - Smalltalk, for
programming the Dynabook.
 In the 1980s, Grady Booch published a paper titled Object Oriented
Design that mainly presented a design for the programming
language, Ada. In the ensuing editions, he extended his ideas to a
complete object–oriented design method.
3/25/2023 Object Oriented System Analysis and Design
3/25/2023
System development
Traditional Approach( Structured Approach)
 Views a system in terms of what it is intended to do and
then develop models of procedures and data.
 Is a strategy based on the concept that a system should
be separated into two parts: data(modeled using a
data/ persistence model) and functionality( modeled
using a process model)
 Structured methods are: Action oriented (data flow
diagrams); or Data oriented (entity-relationship
diagrams); But not both
 Therefore using structured approach we develop
applications in which data are separated from behavior
in both the design model and implementation phase.
53 3/25/2023 Object Oriented System Analysis and Design 54
OO system development..
OO Approach
 In the 1990s, Coad incorporated behavioral ideas to object-
oriented methods.
 The other significant innovations were Object Modelling
Techniques (OMT) by James Rumbaugh and Object-Oriented
Software Engineering (OOSE) by Ivar Jacobson.
The approach
 De-emphasizes procedures. The focus shifts from modeling
business processes and data to combining data and
procedures into objects.
 system is considered as a collection of classes and objects and
the relationship among them.
 A development strategy based on the concept that systems
should be built from a collection of reusable components
called objects.
55 3/25/2023 Object Oriented System Analysis and Design 56
 3/25/2023

OO system development.. OO system development..

OO Approach Object-oriented System analysis and Design
 Object is a concept that encapsulate data as well as their behaviour. (OOAD) is a popular technical approach for
 Each object has attributes (properties) and method (procedures) analyzing, designing an application, or system by
 Objects grouped in to classes and object is responsible for itself.
applying the object oriented paradigm and visual
Proponents of object-oriented development claim that users can modeling throughout the development life cycles
more easily understand objects than traditional representations of a
system. for better communication and product quality.
Object oriented analysis and design are based on these objects and Object-oriented programming (OOP) is a method
are believed to model the real world better than previous methods, based on the concept of “objects", which are data
which describe a system in terms of inputs, outputs, and data flows.
structures that contain data, in the form of fields
However, some research show that objects oriented software
development methods may be more difficult to use for specifying often known as attributes; and code, in the form of
information requirements than traditional structured methods. procedures, often known as methods

3/25/2023 Object Oriented System Analysis and Design 57 3/25/2023 Object Oriented System Analysis and Design 58

OO system development.. OO system development..

Why Object Orientation? Benefits
 Improved Quality
Using Object oriented approach has so many benefits:  Quality systems are on time, on budget and meet or exceed the
expectations of their users. Improved quality comes from increased
 Increase the level of abstraction participation of users in systems development. OO development
 Modeling the real world and provides us with the stronger techniques provide greater opportunity for users to participate in the
equivalence of the real world‘s entities (objects). development process.
 Increased reusability  Financial Benefits
 Object orientation enables us to build better faster and cheaper(BFC) systems
 OO paradigm provides opportunities for reuse through the concepts of
inheritance, polymorphism, encapsulation, modularity, coupling and  Increased chance of project success
cohesion
 Reduce maintenance burden
 Objects are reusable; hence reduce the time and cost of writing software
as well as the incidence of defects.  Managed complexity
 we can build complex software from a well-designed reusable objects.
 Faster development
 Increased Extensibility  Adapts to changing requirement
 Because classes have both data and functionality when you add a new features  Seamless transition among different phases of software
to the system, you only need to make changes in one place: the applicable class development.
 Encouragement of good programming technique

3/25/2023 Object Oriented System Analysis and Design 59 3/25/2023 Object Oriented System Analysis and Design 60

OO system development..
Though it has listed of benefits, opponents of OO claims the
following list of drawbacks
 OO requires a greater concentration on requirements, analysis and
design
 Developers must work closely with users
 Many OO benefits are long-term
 OO demands up-front investments in training, education and tools
3/25/2023 Object Oriented System Analysis and Design
Understanding Basics of..
2. Class:
The structure and behaviors of similar objects are
defined in their common class; so we can define class
as
 A group of related objects.
 A software abstraction of similar objects
 A template from which objects are created
The constituents of a class are
 A set of attributes for the objects that are to be
instantiated from the class. Generally, different objects
of a class have some difference in the values of the
attributes. Attributes are often referred as class data.
 A set of operations that portray the behavior of the
objects of the class. Operations are also referred as
functions or methods.
3/25/2023 Object Oriented System Analysis and Design
3/25/2023
1.3.3. Understanding Basics of Object
Orientation
1. Objects:
An object is a real-world element in an object–oriented
environment that may have a physical or a conceptual existence.
Objects can be modelled according to the needs of the
application.i,.e an object might be a person, place, thing, event,
concept, screen or report.
An object has state, behavior, and identity;
 Identity that distinguishes it from other objects in the system.
 State that determines the characteristic properties of an object as
well as the values of the properties that the object holds.
 Behavior that represents externally visible activities performed by
an object in terms of changes in its state.
 The terms instance and object are interchangeable".
 In practical terms, this means that an object is defined by the messages
it can receive and send; the methods that handle these messages
comprise the object's sole interface to the outer world.
61 3/25/2023 Object Oriented System Analysis and Design 62
Understanding Basics of..
Examples University Registrar System
If we take one class Student- Student class has ID, Name, DoB etc as attributes
and addCourse(), dropCourse, reigisterfoCourse(), etc as a method
One instance of the class Student Objectstudent an Object having the
following behaviours
i.e Objectstuden_Id=IT/001/2011, Objectstuden_Name= Lemma, etc… is an
Object
3. Instantiation
 To create objects from class definitions
4. Abstraction
 The process of extracting the essential characteristics of an item. Class is
constructed from objects through abstraction.
5. Method and Attribute
 A method can be thought as either a function or procedure.
 It is a process implemented by a class that performs an action of value.
 Attribute: something that the class knows
63 3/25/2023 Object Oriented System Analysis and Design 64

Understanding Basics of..
6. Data Hiding
 Typically, a class is designed such that its data (attributes) can be
accessed only by its class methods and insulated from direct outside
access. This process of insulating an object’s data is called data hiding or
information hiding.
7. Encapsulation
 is the process of binding both attributes and methods together within a
class. Through encapsulation, the internal details of a class can be hidden
from outside. It permits the elements of the class to be accessed from
outside only through the interface provided by the class. The same is true
of a package.
8. Inheritance
 Inheritance is the mechanism that permits new classes to be created out
of existing classes by extending and refining its capabilities.
 The existing classes are called the base classes/parent classes/super-
classes, and the new classes are called the derived classes/child
classes/subclasses.
3/25/2023 Object Oriented System Analysis and Design
3/25/2023 Object Oriented System Analysis and Design
3/25/2023
Understanding Basics of..
 The subclass can inherit or derive the attributes and
methods of the super-class(es) provided that the
superclass allows so. Besides, the subclass may add its own
attributes and methods and may modify any of the super-
class methods.
 Inheritance defines an “is – a” relationship
 Types of Inheritance
a. Single Inheritance − A subclass derives from a single superclass.
b. Multiple Inheritance − A subclass derives from more than one super-classes.
c. Multilevel Inheritance − A subclass derives from a super class which in turn
is derived from another class and so on.
d. Hierarchical Inheritance − A class has a number of subclasses each of which
may have subsequent subclasses, continuing for a number of levels, so as to
form a tree structure.
e. Hybrid Inheritance − A combination of multiple and multilevel inheritance
so as to form a lattice structure
65 3/25/2023 Object Oriented System Analysis and Design 66
Understanding Basics of..
9. Polymorphism
Polymorphism is originally a Greek word that means the ability to
take multiple forms.
In object-oriented paradigm, polymorphism implies using
operations in different ways, depending upon the instance they
are operating upon.
Polymorphism allows objects with different internal structures to
have a common external interface. Polymorphism is particularly
effective while implementing inheritance.
Example: Let us consider two classes, Circle and Square, each with
a method findArea(). Though the name and purpose of the
methods in the classes are same, the internal implementation,
i.e., the procedure of calculating area is different for each class.
When an object of class Circle invokes its findArea() method, the
operation finds the area of the circle without any conflict with the
findArea() method of the Square class.
67 3/25/2023 Object Oriented System Analysis and Design 68
 3/25/2023

Understanding Basics of..

10. Generalization and Specialization
 Generalization and specialization represent a hierarchy of relationships
between classes, where subclasses inherit from super-classes.
A. Generalization
 In the generalization process, the common characteristics of classes
are combined to form a class in a higher level of hierarchy, i.e.,
subclasses are combined to form a generalized super-class. It
represents an “is – a – kind – of” relationship. For example, “car is a
kind of land vehicle”, or “ship is a kind of water vehicle”.
B. Specialization
 Specialization is the reverse process of generalization. Here, the
distinguishing features of groups of objects are used to form
specialized classes from existing classes. It can be said that the
subclasses are the specialized versions of the super-class.
 The following figure shows an example of generalization and
specialization.

3/25/2023 Object Oriented System Analysis and Design 69 3/25/2023 Object Oriented System Analysis and Design 70

Understanding Basics of.. Understanding Basics of..

11. Abstract Vs Concrete Class 13. Persistence:
 Abstract Class: A class that does not have objects instantiated from it.
 Concrete Class: A class that has objects instantiated from it  The storing of objects to permanent storage, for
12. Coupling and Cohesion example files, databases etc.
 Coupling 14. Persistence Vs Transitory Objects
 is a measure of how much two items such as classes or methods are
interrelated Persistence Object: An object saved to permanent
 When one class depends on another class, we say they are strongly storage
coupled.
 When one class interact with another class but doesn’t know any of the Transitory object: An object not saved to permanent
implementation of another class, we say they are loosely coupled. storages
 Loosely coupled components are desirable for good designed systems.
 Cohesion
Ex StudentsRegistartionForm1 is transitory object and
 is a measure of how much an item, such as a class or method makes ObjectStudent1 is Persistence object
sense.
15. Pattern:
 A good measure of cohesiveness of something is how long it takes to
describe in one sentence, the longer it takes the less cohesive it likely is.  A reusable solution to a common problem taking
Classes and methods are expected to be highly cohesive. relevant forces into account.
3/25/2023 Object Oriented System Analysis and Design 71 3/25/2023 Object Oriented System Analysis and Design 72
 3/25/2023

References
1. Brahmin, Ali (1999), Object oriented System development, McGraw Hill, USA.
2. Roger Pressman. 2010. Software Engineering: A Practitioner’s Approach. 6th
Edition. McGraw-Hill.
3. Ambler, S. W. (2004). The Object primer: The Application Developer’s Guide
to Object Orientation and the UML 3rd edition. New York. Cambridge
University Press

3/25/2023 Object Oriented System Analysis and Design 73