Chapter 1- Introduction to software engineering for CS.ppt

Chapter 1
Introduction
By Sisay N.
By Sisay N.

 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
 Its state and properties
Contents
2

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
- 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 Process Models

Software Development Life Cycle
(SDLC)
8

Software Development Life Cycle
(SDLC)
9

Phases of SDLC
10
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.

Phases of SDLC
11
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.

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

SDLCModels
13
 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.

Build-and-Fix Model
14
 Problems
 No specifications
 No design
 Totally unsatisfactory
 High cost
 Difficult maintenance

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 (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…
 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

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
 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 improvements.
38

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 Model
 Frequent Delivery of
functional software.
 Direct Communication with
clients.
 Efficient design that meets
business needs.
 Flexibility for changes at
any stage.
 Reduced development
time.
 Disadvantages of Agile
Model
 Lack of formal
documentation may cause
confusion.
 Key decisions can be
misinterpreted at different
stages.
 Project maintenance
challenges if original
developers leave.
43

Agile vs. Waterfall Method
Agile Model Waterfall Model
Agile method proposes incremental and
iterative approach to software design
Development of the software flows
sequentially from start point to end point.
The agile process is broken into individual
models that designers work on
The design process is not broken into an
individual models
The customer has early and frequent
opportunities to look at the product and make
decision and changes to the project
The customer can only see the product at the
end of the project
Agile model is considered unstructured
compared to the waterfall model
Waterfall model are more secure because they
are so plan oriented
44

Agile vs. Waterfall Method (contd.)
Small projects can be implemented very
quickly. For large projects, it is difficult to
estimate the development time.
All sorts of project can be estimated and
completed.
Error can be fixed in the middle of the
project.
Only at the end, the whole 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 iterative, and the
project is executed in short (2-4) weeks
iterations. Planning is very less.
The development process is phased, and the
phase is much bigger than iteration. Every
phase ends with the detailed description of the
next phase.
Documentation attends less priority than
software development
Documentation is a top priority and can even
use for training staff and upgrade the software
with another team
45

Agile vs. Waterfall Method (contd.)
In agile testing when an iteration end,
shippable features of the product is delivered
to the customer. New features are usable right
after shipment. It is useful when you have
good contact with customers.
All features developed are delivered at once
after the long implementation phase.
Testers and developers work together Testers work separately from developers
At the end of every sprint, user acceptance is
performed
User acceptance is performed at the end of
the project.
It requires close communication with
developers and together analyze requirements
and planning
Developer does not involve in requirement
and planning process. Usually, time delays
between tests and coding
46

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 polymorphism allow
efficient reuse and reduce redundancy, leading to a more structured and efficient codebase.
73

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

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
development cycle.
75

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

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

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

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

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

methodology…
81

Chapter 1- Introduction to software engineering for CS.ppt

Recommended

More Related Content

Similar to Chapter 1- Introduction to software engineering for CS.ppt (20)

More from SisayNegash4 (7)

Recently uploaded (20)

Chapter 1- Introduction to software engineering for CS.ppt

Editor's Notes