Chapter 1

Introduction

By Sisay N.
 Contents
What Orthogonal view of Software?
Software development process models
Software Process, Software life cycle and
process models, process assessment models
Software process Metrics
Object oriented system development
methodology
Why an object oriented, Overview of the unified
approach
An Object orient Methodology
Basic concepts of an object and Attributes of an
object
2 Its state and properties
 Two Orthogonal view of software

• Refers to two independent perspectives of a

system.
• Changes in one view should not affect the other.
• Commonly includes:
• Function-based view – Focuses on operations
and processes.
• Object-oriented view – Emphasizes data and
interactions.
• Ensures separation of concerns for better modularity
and maintainability.

3
 Continued…
 Meaning of "orthogonal":
In geometry, orthogonal lines are perpendicular, signifying
independence.
In software, it means that components or features can be modified
without impacting other parts of the system.
 Example of orthogonal views:
Traditional view (functional): Focuses on the system's functions and
data flow, breaking down the system into processes and algorithms
Object-oriented view: Focuses on objects with encapsulated data and
methods, where each object represents a real-world entity and its
interactions with other objects.

4
 Continued…
 Orthogonal View in Software Development
In computing, orthogonality means independent functionality
without unintended effects.
Allow changes in one operation without affecting others.
Example Executing Operation A has no impact on Operation B.
Simplifies debugging by preventing ripple effects in dependent
operations.
Encourages minimalistic design with a limited set of combinable
components.
Reduces errors and improves readability and learning for
developers.

5
 Benefits of using orthogonal
views
Improved maintainability:
By keeping components independent, changes
in one part of the system are less likely to
require modifications in other parts.
Enhanced reusability:
Well-defined, independent components can be
reused in different parts of the application or
even in other projects.
Simplified debugging:
Isolating issues to specific components
becomes easier when they have clear
boundaries.
6
 Software Process Models
Software process
- Coherent sets of activities for specifying, designing,
implementing and testing software systems
-A structured set of activities required to develop a
software system specification, design, validation and
evolution.
A software process model-
-An abstract representation of a process and
presents a description of a process from some
particular perspective.
 Software Development Life
Cycle (SDLC)

8
 Software Development Life
Cycle (SDLC)

9
 Phases of SDLC
1.Planning and Requirement Analysis
• Senior team members gather input from stakeholders.
• Identifies risks and quality assurance requirements.
• Results in the Software Requirement Specification
(SRS) document.
2.Designing the Software
• Converts requirements into a structured system design.
• Ensures feasibility and alignment with business
objectives.
3.Development (Coding Phase)
• Actual programming begins based on the design.
• Developers follow coding guidelines and use necessary
tools.

10
 Phases of SDLC
5.Testing
• Ensures the software meets requirements and is bug-free.
• Includes unit testing, integration testing, system testing,
and acceptance testing.
6.Deployment
• Software is deployed to users after certification.
• May include enhancements based on user feedback.
7.Maintenance
• Addresses real-world issues and provides updates.
• Ensures long-term functionality and efficiency.
 This structured approach enhances software quality,
reduces risks, and ensures project success.

11
 SDLC Models
More other process
models
Build-and-fix model
Evolutionary process
models
 Rapid prototyping model
 Spiral model
Object-oriented life-
cycle models
 Unified Process

12
 SDLC Models
Software Development Life Cycle (SDLC) is a
structured framework used in project
management that outlines the stages involved in
developing an information system, from initial
feasibility analysis to ongoing maintenance of
the final product.
Various SDLC models exist, each defining a unique
approach to software development.
These models, also known as Software
Development Process Models, follow distinct
phases to ensure a systematic and efficient
development process.
13
 Build-and-Fix Model
Problems
No specifications
No design
Totally unsatisfactory
High cost
Difficult maintenance

14
 Waterfall Model

15
 Waterfall Model
Five distinct phases:
1.Requirements Analysis and Specification – This
phase focuses on gathering and documenting
customer requirements in a Software
Requirement Specification (SRS) document. It
defines what the system should do, not how it
should be implemented.
2.Design Phase – The collected requirements are
translated into a Software Design Document
(SDD), which outlines the system architecture,
including high-level and detailed designs to guide
implementation.
16
 Waterfall Model
Five distinct phases:
3.Implementation and Unit Testing – The software is
developed based on the SDD. Individual components are
coded and unit-tested to ensure they function correctly.
4.Integration and System Testing – All modules are combined
and tested for their interactions to ensure the system
works as expected. Comprehensive testing helps improve
product quality and reduce maintenance costs.
5.Operation and Maintenance – Once deployed, the software
enters the maintenance phase, where bug fixes, updates,
and improvements are handled based on user feedback.

17
 When to Use the Waterfall
Model?
• The Waterfall Model is best suited when;
• Requirements are well-defined and unlikely
to change.
• Projects are short and straightforward.
• The environment is stable, with minimal
external influences.
• Technology and tools remain consistent
throughout development.
• Sufficiently prepared resources are
available.
18
 Advantages of the Waterfall
Model
Simple and easy to implement, requiring
minimal resources.
Clearly defined requirements that
remain unchanged throughout development.
Well-structured phases with fixed start
and end points, making progress tracking
easy.
 Predictable cost and timeline due to
predefined schedules.
Strict documentation provides clarity and
control over the project.
19
 Disadvantages of the Waterfall
Model
High risk and inflexibility, making it
unsuitable for large or complex projects.
Changes in requirements are difficult
to accommodate once development starts.
Going back to previous phases is
challenging once the project progresses.
 Late-stage testing makes it harder to
identify and mitigate risks early.

20
 Rapid Prototyping Model
Prototyping is defined as the
process of developing a working
replication of a product or system
that has to be engineered.
It offers a small scale replica of the
end product and is used for
obtaining customer feedback as
described below:

21
 Rapid Prototyping Model…

22
 Rapid Prototyping Model (contd.)
 Rapid prototype characteristics:
Used in the requirements phase
Evaluated by the customer/user
Then, it is discarded -do not turn into
product
 Rapid prototyping model is not proven
and has its own problems
Possible solution
Rapid prototyping for defining
requirements
Waterfall model for rest of life cycle

23
 Incremental Model
 Incremental Model is a process of software
development where requirements are broken down
into multiple standalone modules of software
development cycle.
 Each iteration passes through the requirements,
design, coding and testing phases.
 Typical product takes from 5 to 25 builds (iterations).

24
 Incremental Model (contd.)

25
 Incremental Model…
Waterfall and rapid prototyping models
Deliver complete product at the end
Incremental model
Deliver portion of the product at each stage
Advantages
The software will be generated quickly during the
software life cycle
It is flexible and less expensive to change
requirements and scope
Throughout the development stages changes can
be done
This model is less costly compared to others
A customer can respond to each building
Errors are easy to be identified

26
 Incremental Model…
Disadvantages:
It requires a good planning designing
Problems might arise due to system
architecture as not all requirements
collected up front for the entire software
lifecycle
Each iteration phase is rigid and does not
overlap each other
Correcting a problem in one unit requires
correction in all the units and consumes a
lot of time

27
 When to use Incremental
models?
Requirements of the system are clearly
understood
When demand for an early release of a
product arises
When software engineering team are not
very well skilled or trained
When high-risk features and goals are involved
Such methodology is more in use for web
application and product based companies

28
 Spiral Model
 The spiral model is a risk-driven software
development process model.
 Based on the unique risk patterns of a given project,
the spiral model guides a team to adopt elements of one
or more process models, such as incremental, waterfall,
or evolutionary prototyping.
 Risk Analysis: Identification of potential risk is done
while risk mitigation strategy is planned and finalized
 Precede each phase by
Alternatives
Risk analysis
 Follow each phase by
Evaluation
Planning of next phase

29
 Simplified Spiral Model

30
 When to use Spiral
Methodology?
When project is large
When releases are required to be frequent
When creation of a prototype is applicable
When risk and costs evaluation is important
For medium to high-risk projects
When requirements are unclear and
complex
When changes may require at any time
When long term project commitment is not
feasible due to changes in economic priorities

32
 Advantages of Spiral Model
Additional functionality or changes can be
done at a later stage
Cost estimation becomes easy as the
prototype building is done in small
fragments
Continuous or repeated development helps
in risk management
Development is fast and features are added
in a systematic way
There is always a space for customer
feedback
33
 Disadvantages of Spiral
Model
Risk of not meeting the schedule or
budget
It works best for large projects only also
demands risk assessment expertise
For its smooth operation spiral model
protocol needs to be followed strictly
Documentation is more as it has
intermediate phases
It is not advisable for smaller project, it
might cost them a lot
34
 Agile Process Models

35
 Agile Process Models
Agile software engineering combines a
philosophy and a set of development guidelines
Philosophy
Encourages customer satisfaction and early
incremental delivery of the software
Small highly motivated project teams
Informal methods
Minimal software engineering work products
Overall development simplicity
Development guidelines
Stress delivery over analysis and design
Active and continuous communication
between developers and customers

36
 Agile Process Models
 The term Agile means swift and versatile. The Agile process
model is a software development approach that emphasizes
iterative development, breaking tasks into smaller iterations
without long-term planning.
 The scope and requirements of the project are established at the
start, and the number of iterations, their duration, and scope are
predefined.
 Each iteration typically lasts between one to four weeks, ensuring
faster delivery and risk minimization.
 Agile follows a full software development cycle in each iteration,
including planning, requirements analysis, design, coding,
and testing, before presenting a working product to the client.

37
 Phases of the Agile Model
1. Requirements Gathering – Identify business opportunities,
evaluate technical and economic feasibility, and define
project requirements.
2. Design the Requirements – Collaborate with stakeholders
to refine requirements using user flow diagrams or UML
diagrams.
3. Construction/Iteration – Developers and designers build an
initial version with minimal functionality, gradually
improving the product.
4. Testing/Quality Assurance – The QA team verifies
product performance and resolves bugs.
5. Deployment – The software is released for user
implementation.
6. Feedback – Gather user feedback and iterate on
38 improvements.
 Agile Testing Methods

39
 Agile Process Models…

40
 When to use Agile model…
 When new changes need to be implemented. The
freedom agile gives to change is very important. New
changes can be implemented at very little cost
because of the frequency of new increments that are
produced.
 To implement a new feature the developers need to
lose only the work of a few days, or even only hours,
to roll back and implement it.
 Both system developers and stakeholders alike, find
they also get more freedom of time and options than
if the software was developed in a more rigid
sequential way.
 Having options gives them the ability to leave
important decisions until more or better data or even
entire hosting programs are available; meaning the
project can continue to move forward without fear of
reaching a sudden standstill.
41
 When to Use the Agile Model (in
short)?
• Frequent requirement changes are
expected.
• A highly experienced team is available.
• Clients can engage regularly with
developers.
• Project size is small to medium.

42
 Advantages/Disadvantages
of Agile Model
 Advantages of Agile  Disadvantages of
Model Agile Model
 Frequent Delivery of Lack of formal
functional software. documentation may
Direct cause confusion.
 Key decisions can
Communication with
clients. be misinterpreted at
Efficient design that different stages.
Project
meets business needs.
maintenance
 Flexibility for
challenges if original
changes at any stage. developers leave.
 Reduced
development time.
43
 Agile vs. Waterfall Method
Agile Model Waterfall Model
Agile method proposes Development of the software
incremental and iterative flows sequentially from start
approach to software design point to end point.
The agile process is broken into The design process is not broken
individual models that designers into an individual models
work on
The customer has early and The customer can only see the
frequent opportunities to look at product at the end of the project
the product and make decision
and changes to the project
Agile model is considered Waterfall model are more secure
unstructured compared to the because they are so plan
waterfall model oriented
44
 Agile vs. Waterfall Method (contd.)
Agile Model Waterfall Model
Small projects can be All sorts of project can be
implemented very quickly. For estimated and completed.
large projects, it is difficult to
estimate the development time.
Error can be fixed in the middle Only at the end, the whole
of the project. product is tested. If the
requirement error is found or any
changes have to be made, the
project has to start from the
beginning
Development process is The development process is
iterative, and the project is phased, and the phase is much
executed in short (2-4) weeks bigger than iteration. Every
iterations. Planning is very less. phase ends with the detailed
description of the next phase.
45 Documentation attends less Documentation is a top priority
priority than software and can even use for training
 Agile vs. Waterfall Method (contd.)
Agile Model Waterfall Model
In agile testing when an iteration All features developed are
end, shippable features of the delivered at once after the long
product is delivered to the implementation phase.
customer. New features are
usable right after shipment. It is
useful when you have good
contact with customers.
Testers and developers work Testers work separately from
together developers
At the end of every sprint, user User acceptance
acceptance is performed is performed at the end of the
project.
It requires close communication Developer does not involve in
with developers and together requirement and planning
analyze
46 requirements and process. Usually, time delays
 Advantages of Agile Model
Customer satisfaction by rapid, continuous delivery of useful
software.
People and interactions are emphasized rather than process
and tools. Customers, developers and testers constantly
interact with each other.
Working software is delivered frequently (weeks rather than
months).
Face-to-face conversation is the best form of
communication.
Close, daily cooperation between business people and
developers.
Regular adaptation to changing circumstances.
Even late changes in requirements are welcomed.

47
 Disadvantages of Agile model
In case of some software deliverables, especially the
large ones, it is difficult to assess the effort required at
the beginning of the software development life cycle.
There is lack of emphasis on necessary designing and
documentation.
The project can easily get taken off track if the
customer representative is not clear what final outcome
that they want.
Only senior programmers are capable of taking the kind
of decisions required during the development process.
Hence it has no place for newbie programmers, unless
combined with experienced resources.
48
 How to Choose between SDLC
Methods?

49
 How to Choose between SDLC
Methods?
To know which is the best model out of all the
different types of SDLC models, it is important to
understand that each of these approaches
are suitable for different projects, environments,
and requirements.
For example, if your project is simple and
straightforward with set requirements that do not
need to be changed, then Waterfall is best suited
for it.
However, if your project is large-scale and consists
of multiple components and segments, then
choosing Iterative or Spiral methodology would
suit your project better.
50
 How to Choose between
SDLC Methods?
To answer the question simply, there is
no ONE model is best from all the
SDLC models discussed.
A preference of one method over the
others cannot be determined.
However, to select the right SDLC
methodologies, you should know all the
types of SDLC models, assess the
requirements of all the stakeholders and
then decide on a method that best fits
your needs.
51
 Criteria for deciding on a model
include
Criteria for deciding on a model include
Product Complexity
Product Size
Magnitude of Changes
Frequency of Changes
Skills of the Dev Team
Time constraints
Access to Users

52
 Software process metrics
Software process metrics refer to quantitative
measures that are used to assess, analyze, and
improve the software development process.
Designed to help development teams
understand and control various aspects of the
software engineering process, including
efficiency, quality, cost, and performance.
The primary goal is to make informed decisions,
identify potential areas for improvement, and
ensure that the software development process is
effective, predictable, and capable of meeting
the desired outcomes.

53
 Key Purposes of Software
Process Metrics
1. Monitoring and Control: By tracking different metrics, teams
can assess the health of the development process and ensure that
projects stay on track in terms of budget, timeline, and quality.
2. Continuous Improvement: Metrics provide insights that can be
used to refine and improve the software development processes
over time. This can lead to better software quality, increased
productivity, and more efficient use of resources.
3. Decision Making: Metrics provide objective data that assist
project managers, developers, and other stakeholders in making
informed decisions regarding process adjustments, resource
allocation, or risk management.
4. Predictability: Metrics help teams understand patterns in their
development process, enabling them to predict project timelines,
costs, and potential issues based on historical data.

54
 Types of Software Process
Metrics
1. Process Metrics: These focus on the overall performance of the
development process itself. They include measurements like defect
density, cycle time, and process efficiency.
2. Product Metrics: These assess the quality and characteristics of the
software product being developed. Examples include lines of code
(LOC), defect removal efficiency, and code churn.
3. Project Metrics: These measure the overall progress and success of
a software project. Metrics such as effort estimation, schedule
variance, and cost performance index (CPI) fall under this category.
4. Quality Metrics: These metrics measure the quality of the software,
including test coverage, defect arrival rate, and mean time to failure
(MTTF).
5. Team Performance Metrics: These focus on the effectiveness and
productivity of the development team, such as velocity in Agile
teams, work in progress (WIP), and team collaboration.

55
 Examples of Software
Process Metrics
Defect Density: Number of defects per unit
of software size (e.g., defects per 1000 lines
of code).
Cycle Time: The time it takes to complete a
specific software development phase (e.g.,
design, coding, testing).
Velocity: The amount of work completed by
a team in a given period (e.g., number of
user stories completed in an Agile sprint).
Test Coverage: Percentage of the code
that is covered by automated tests.
56
 Software process metrics

57
 Software process metrics

58
 Software process metrics
2. Product Metrics…
Function Points: A measure of the functionality
delivered by the software, focusing on the inputs,
outputs, user interactions, data, and external
interfaces. This is more reflective of the software's
complexity and functionality than LOC. Read more
Defect Removal Efficiency (DRE): Measures the
efficiency of the software testing process in detecting
and removing defects.

Higher DRE indicates that the testing process is

effective in removing defects.
59
 Software process metrics
2. Product Metrics…
Code Churn: Measures the frequency with
which code changes. High code churn may
indicate instability or frequent modifications,
which could affect the software’s reliability
and maintenance.

60
 Software process metrics
3. Project Metrics
These metrics measure the overall progress, cost,
and effectiveness of the software project.
Effort Estimation: Tracks the amount of time
and effort required to complete a project or a
phase. It helps in forecasting future resource
requirements. Formula:

Schedule Variance (SV): Measures the

difference between the planned and actual
progress of a project in terms of time.
Formula:

61
 Software process metrics
3. Project Metrics
Cost Performance Index (CPI): Measures
cost efficiency by comparing the work
performed to the actual costs incurred.

A CPI greater than 1 indicates that the

project is under budget.
Schedule Performance Index (SPI):
Measures schedule efficiency by comparing
the work performed to the planned schedule.

62
 Software process metrics
4. Quality Metrics
Quality metrics help assess the reliability,
maintainability, and performance of the software
product.
Defect Arrival Rate: Measures how often
defects are identified during testing. It helps to
determine whether the software is improving or
getting worse over time. Formula:

Test Coverage: Measures the percentage of the

software code that is tested by unit tests. Higher
test coverage means more of the code is being
tested, which typically results in higher software
quality.
63
 Software process metrics
4. Quality Metrics…
Mean Time to Failure (MTTF): Measures the
average time between failures in the system. It
is used to assess the reliability of the software.

Mean Time to Repair (MTTR): Measures the

average time taken to fix defects after they are
identified. It helps evaluate the maintainability
of the software.

64
 Software process metrics
5. Team Performance Metrics
These metrics focus on how well the development team
is performing and how efficiently they are collaborating.
Velocity: In Agile projects, this metric measures the
amount of work a team can complete in a given
iteration or sprint. It's often measured in story points or
user stories.
Burndown Chart: A visual representation showing
the amount of work left versus time. It is used in Agile
to track progress during sprints.
Work In Progress (WIP): Measures the amount of
work the team is actively working on at any given time.
It helps identify if the team is overloaded or if there are
bottlenecks in the process.

65
 Process Assessment
Models (PAMs)
• are frameworks used to evaluate and improve
processes in various domains, such as software
development, business operations, or manufacturing.
• These models provide structured methodologies for
assessing the maturity, efficiency, and effectiveness
of processes within an organization.
• Key Aspects of Process Assessment Models:
1. Standardized Framework – PAMs are often based
on international standards like ISO/IEC 330xx
(formerly ISO/IEC 15504, also known as SPICE)
or CMMI (Capability Maturity Model Integration).
2. Maturity Levels – Many PAMs use maturity levels to
indicate how well a process is defined, implemented,
and optimized.
3. Process Capability Evaluation – They assess
whether a process meets certain performance criteria
and how it can be improved.

66
 Process Assessment
Models (PAMs) …
4. Gap Analysis – Identifies strengths and weaknesses
in current processes and provides recommendations
for improvement.
5. Continuous Improvement – Helps organizations
refine their processes over time for better efficiency
and quality.
 Examples of Process Assessment Models:
ISO/IEC 330xx (SPICE) – Used for software process
improvement and capability determination.
CMMI (Capability Maturity Model Integration) –
Measures process maturity in software and systems
development.
ITIL (Information Technology Infrastructure Library)
– Assesses IT service management processes.
Lean Six Sigma – Focuses on process efficiency and
reducing waste.
Business Process Maturity Model (BPMM) – Evaluates
business processes.

67
 Object oriented system development
methodology
Object-Oriented System Development Methodology
(OOSDM) is an approach to system development that
integrates object-oriented principles throughout the
software development lifecycle.
It emphasizes modular, reusable, and maintainable
software design by treating both data and behavior as
encapsulated objects.
Advantages of OOSDM
 Reusability – Objects and classes can be reused in multiple projects
 Scalability – Supports complex system expansion with minimal code changes.
 Maintainability – Easier debugging and modification due to modularity.
 Flexibility – Supports iterative and incremental development.
 Better Real-World Mapping – Aligns well with real-world entities, making
system modeling intuitive.

68
 Object oriented system development
methodology…
Key Principles of OOSDM
1. Encapsulation – Bundling data and methods
together into objects.
2. Abstraction – Hiding implementation details
and exposing only necessary features.
3. Inheritance – Enabling new classes to reuse
existing class properties and methods.
4. Polymorphism – Allowing a single interface to
represent different underlying implementations.
5. Modularity – Structuring a system as a
collection of independent and reusable objects.

69
 Object oriented system development
methodology…
Phases of Object-Oriented System Development
1. Object-Oriented Analysis (OOA)
 Identifies system requirements.
 Defines key objects and their relationships.
 Uses UML (Unified Modeling Language) diagrams like
use case diagrams and class diagrams.
2. Object-Oriented Design (OOD)
 Transforms analysis models into a system design.
 Defines class structures, object behaviors, and interactions.
 Uses design patterns to improve reusability and
efficiency.
3. Object-Oriented Programming (OOP)
 Implements the design using object-oriented programming
languages (e.g., Java, Python, C++).
 Encapsulates functionalities within classes and objects.
70
 Object oriented system development
methodology…
Phases of Object-Oriented System
Development…
4.Object-Oriented Testing (OOT)
 Validates individual objects, class interactions,
and system functionalities.
 Uses techniques like unit testing (for
classes), integration testing (for object
interactions), and system testing.
5. Object-Oriented Maintenance
 Enhances and updates the system while preserving
object integrity.
 Uses version control and refactoring techniques for
long-term sustainability.

71
 Object oriented system development
methodology…
Popular Object-Oriented Methodologies
1. Booch Method – Emphasizes iterative
development with object modeling.
2. Rumbaugh’s Object Modeling Technique
(OMT) – Focuses on analysis, design, and
implementation using object models.
3. Jacobson’s Object-Oriented Software
Engineering (OOSE) – Introduced the Use Case
Model for requirement analysis.
4. Unified Process (UP) – A widely used
methodology that integrates OOA, OOD, and OOP.
5. Agile and Object-Oriented Development –
Modern Agile methodologies often incorporate
object-oriented design principles.
72
 Object oriented system development
methodology…
 Why Use an Object-Oriented Approach?
 The Object-Oriented Approach (OOA, OOD, OOP) is widely used in
software development because it models real-world entities more
naturally, leading to reusable, scalable, and maintainable software
systems. Reason for preferred:
1.Real-World Modeling – Objects represent real-world entities, making
systems intuitive and easier to design.
2.Encapsulation – Data and behavior are bundled together, improving
security and modularity.
3.Reusability – Code can be reused across different parts of a system or
in new projects, reducing development time.
4.Scalability and Flexibility – The system can grow by adding new
objects and relationships without affecting existing components
significantly.
5.Maintainability – Well-structured object-oriented code is easier to
debug, update, and extend.
6.Improved Software Quality – Concepts like inheritance and
73 polymorphism allow efficient reuse and reduce redundancy, leading
to a more structured and efficient codebase.
 Object oriented system development
methodology…
Overview of the Unified Approach (UA)
The Unified Approach (UA) is a software
development methodology that integrates
different object-oriented techniques into a
structured framework.
It combines concepts from various object-
oriented methodologies, such as Booch
Method, Rumbaugh’s Object Modeling
Technique (OMT), and Jacobson’s Object-
Oriented Software Engineering (OOSE),
leading to what is now known as the Unified
Process (UP).
74
 Object oriented system development
methodology…
Key Characteristics of the Unified Approach
Iterative and Incremental Development – Software
is developed in multiple cycles (iterations) instead of a
single phase.
Unified Modeling Language (UML) – Uses
standardized UML diagrams for analysis, design, and
implementation.
Use Case Driven – Focuses on defining system
behavior through use cases.
Architecture-Centric – Emphasizes a well-defined
software architecture using object-oriented design
principles.
Risk-Driven – Addresses high-risk aspects early in the
75 development cycle.
 Object oriented system development
methodology…
Phases of the Unified Approach (Unified
Process)
1.Inception Phase – Define system goals,
feasibility, and scope.
2.Elaboration Phase – Identify system
architecture, use cases, and potential risks.
3.Construction Phase – Implement and develop
the system in iterations.
4.Transition Phase – Deploy the system and
provide user training.

76
 Object oriented system development
methodology…
Advantages of the Unified Approach
 Combines Best Practices – Integrates multiple
object-oriented methodologies.
 Flexible and Scalable – Adapts well to complex
and evolving software projects.
 Well-Defined Process – Uses UML and a
structured development cycle.
 Minimizes Risks – Addresses project risks early
through an iterative approach.
 Ensures High-Quality Software – Focuses on
architecture, testing, and gradual refinement.

77
 Object oriented system development
methodology…
Basic Concepts of an Object
In Object-Oriented Programming (OOP), an object is
a self-contained unit that represents a real-world entity.
It consists of attributes (data) and methods
(behaviors) that define its characteristics and
functionalities.
Key Characteristics of an Object:
1. Identity – Each object has a unique identity, distinguishing it from
other objects.
2. State – The values stored in an object's attributes at a given time.
3. Behavior – The methods or functions that define what an object
can do.
For example, consider an object: "Car“
 Attributes (Properties): color, brand, model, speed
 Methods (Behaviors): accelerate(), brake(), turn()
78
 Object oriented system development
methodology…
Attributes of an Object
An attribute (also known as a property or field)
represents data associated with an object.
Attributes define an object's state and properties.
Example: "Car" Object and its Attributes

State of an Object ,, next slides

79
 Object oriented system development
methodology…
State of an Object
The state of an object refers to the current values
of its attributes at a specific point in time. It
changes when the object undergoes modifications
through methods.
Properties of an Object
The properties of an object refer to its
characteristics that help define it. These
properties are stored as attributes.

80
 Object oriented system development
methodology…

81