OBJECT ORIENTED SOFTWARE

ENGINEERING
COURSE CODE :MCA 2005
• BRIDGE COURSE
• SYLLABUS
• CO-PO MAPPING
• INTRODUCTION TO OBJECT ORIENTED
SOFTWARE ENGINEERING

1
 Object Oriented Software Engineering
Module : 1 Software Engineering
1.1 Software Engineering:
1.2 The nature of software
1.3 Stakeholders in software engineering
1.4 Types of Software,
1.5 Software Engineering Projects,
1.5 Software Engineering Activities,
1.6 Software Process Models
1.7 SDLC Process Models
1.8 Waterfall Model,
1.9 RAD Model,
1.10 Agile Software Development Model,
1.11 RUP Model, 2
 SOFTWARE ENGINEERING
OUTLINE

� Introduction
� Learning Objectives(Course Objectives)
� Syllabus
� Learning Outcomes (Course Outcomes)
� Program Outcomes
� Program Specific Outcomes
� Course Articulation Matrix (CO-PO mapping)
� Target
� Assessment Process

3
COURSE SPECIFICATION

4
CO : COURSE OUTCOMES

5
 SYLLABUS
MODULE 1 AND MODULE 2
NO OF HOURS : 11 HOURS

6
SYLLABUS MODULE 3
HOURS: 10 SESSIONS

7
SYLLABUS MODULE 4
HOURS: 12 SESSIONS

8
SYLLABUS MODULE 5
HOURS: 10 SESSIONS

9
MODE OF TEACHING AND
EVALUATION

10
Text Books:

11
Reference Books:

12
 MODULE : 1 TOPICS AS PER SYLLABUS
SOFTWARE ENGINEERING

� Software Engineering:
� The nature of software
� Stakeholders in software engineering
� SDLC Process Models
� Waterfall,
� RAD
� Agile Software Development.
� RUP

Time : 5 Hours
COURSE OUTCOMES : CO1, CO2, CO3
PROGRAM OUTCOMES : PO1, PO2,PO3,PO4,PO5 and PSO2

13
 Object Oriented Software Engineering
Module : 1 Software Engineering
1.1 Software Engineering:
1.2 The nature of software
1.3 Stakeholders in software engineering
1.4 Types of Software,
1.5 Software Engineering Projects,
1.5 Software Engineering Activities,
1.6 Software Process Models
1.7 SDLC Process Models
1.8 Waterfall Model,
1.9 RAD Model,
1.10 Agile Software Development Model,
1.11 RUP Model, 14
 Project based
Object Oriented Software Engineering and Software Reuse

Project based Object Oriented Software Engineering and Software Reuse

focuses on outcome based Student centric Projects. The Project case studies,
mini Projects and UML Designs, OO Analysis and System Design. The real time
Project analysis and Design of n of Projects are explained in multidisciplinary
projects.
Chapter 1 Object Oriented Software Engineering and System Design

1.1 Software Engineering:

1.2 The nature of software
1.3 Stakeholders in software engineering
1.4 Types of Software,
1.5 Software Engineering Projects,
1.5 Software Engineering Activities,
1.6 Software Process Models
1.7 SDLC Process Models
1.8 Waterfall Model,
1.9 RAD Model,
1.10 Agile Software Development Model,
1.11 RUP Model.
SUMMARY

� Learning Objectives were set from the Faculty

perspective
� Learning Outcomes were set from the
Students perspective
� Course Articulation Matrix (CO-PO mapping)
was defined
� Target was set for the Current Academic Year
for the course Database systems
� Assessment Process was discussed

16
� REFERENCE :

� ..\1.OOSE Syllabus, LT, CDS\SE-SYLABUS.pdf

� ..\1.OOSE Syllabus, LT, CDS\SE_Lesson

Plan.pdf

17
 MCA2005 MODULE 1 : INTRODUCTION TO
OBJECT ORIENTED SOFTWARE ENGINEERING

� Software Engineering Basics

� Need and Characteristics of Software
Engineering
� Nature of Software Engineering

� Types of Software

� Software Engineering Projects & Activities

� Software Process Models

18
SOFTWARE ENGINEERING AND
TYPES OF SOFTWARE

19
 WHAT IS SOFTWARE?
� Computer programs and associated documentation

� Software products may be developed for a particular

customer or may be developed for a general market.

20
TYPES OF SOFTWARE
� Three types of software:
(a) Custom Software:
❖ For a specific customer/single customer.
❖ Software for managing the specialized finances of large
organizations.
❖ It accommodate customer‟s particular expectations.

❖ Examples like:

(i) Hospitals: Maintain health record, Keep patients blood

group and billing.
(ii) Education: Maintain student admission details, Transfer
certificates, Examination records, etc.
(iii) Retail: Billing is the common use of custom software.

� Advantage: Most efficient system for specific needs. 21

� Dis-advantage: Time & Cost.

TYPES OF SOFTWARE
(b) Generic Software:
❖ Software readily available to the public.
❖ Perform many different tasks and is not limited to one particular
application.
❖ Sold on open market to perform the functions that many people
need, and to run on general purpose computers.
❖ Often called as COTS ( Commercial Off The Shelf).

❖ Examples like:

(i) Spreadsheet: is generic because it is useful for multiple purposes

without modification, such as a calculating tool for engineers or a
finance tool for accountants.
(ii) consider the data structure called a stack. A stack is a collection
of data, all of the same type, which implements a Last In, First Out
concept. Multiple items may be “pushed” onto the stack. When a
value is “popped” off the stack the value returned is the most recent
value “pushed” onto the stack. 22
TYPES OF SOFTWARE (CONTD.)
(c) Embedded Software:
❖ Built into hardware.
❖ Hard to change.

❖ Eg: washing machines, DVD players, microwave ovens and

automobiles.

DIFFERENCE BETWEEN CUSTOM, GENERIC & EMBEDDED SOFTWARE

23
TYPES OF SOFTWARE (CONTD.)
(d) Real-Time Software:
❖ Must react immediately (Faster).
❖ Safety is taken care

❖ Eg: Control & monitoring systems - pushing of buttons by the

user, or a signal from a sensor

(e) Data-Processing Software:

❖ Used to run business.
❖ Accuracy & Security of data are key.

� Some software has both real-time and data processing aspects.

For example: a telephone system has to manage phone calls in
real time, but billing for those calls is a data processing
activity. 24
SOFTWARE ENGINEERING
� Software is more than just a program code.

�A program is an executable code, which serves some

computational purpose.

� Softwareis considered to be collection of executable

programming code, associated libraries and
documentations.

� Software, when made for a specific requirement is

called software product.

� Engineering on the other hand, is all about developing

products, using well-defined, scientific principles and
methods. 25
SOFTWARE ENGINEERING
� Software Engineering is an engineering branch
associated with development of software product using
well-defined scientific principles, methods and
procedures.
� The outcome of software engineering is an efficient and
reliable software product.

26
WHAT IS SOFTWARE ENGINEERING?
� The term Software Engineering is defined as
following 4 key points:
❖ solving customers‟ problems.
❖ systematic development and evolution.

❖ large, high-quality software systems.

❖ cost, time and other constraints.

� The process of solving customers’ problems by the

systematic development and evolution of large,
high-quality software systems within cost, time and
other constraints.

27
SOFTWARE ENGINEERING PARADIGMS
� Software paradigms refer to the methods and steps,
which are taken while designing the software.

� Programming paradigm is a subset of Software design

paradigm which is further a subset of Software
development paradigm. 28
SOFTWARE ENGINEERING PARADIGMS (CONTD.)
� Software Development Paradigm: It includes various
researches and requirement gathering which helps the
software product to build. It consists of :
� Requirement gathering
� Software design

� Programming

� Software Design Paradigm: This paradigm is a part of

Software Development and includes :
� Design
� Maintenance

� Programming

� Programming Paradigm: This paradigm is related closely

to programming aspect of software development. This includes:
� Coding
� Testing 29
� Integration
NEED OF SOFTWARE ENGINEERING
� The need of software engineering arises because of higher rate
of change in user requirements and environment on which the
software is working.
� Large software: As the size of software become large, engineering
has to step to give it a scientific process.
� Scalability: If the software process were not based on scientific
and engineering concepts, it would be easier to re-create new
software than to scale an existing one.
� Cost: As hardware industry has shown its skills and huge
manufacturing has lower down he price of computer and electronic
hardware. But the cost of software remains high if proper process
is not adapted.
� Dynamic Nature: If the nature of software is always changing,
new enhancements need to be done in the existing one. This is
where software engineering plays a good role.
� Quality Management: Better process of software development
provides better and quality software product. 30
CHARACTERISTICS OF GOOD SOFTWARE
� A software product can be judged by what it offers and how
well it can be used.

� Any software must satisfy on the following three parameters:

(a) Operational: How well the software works based on the
measures like – Budget, Usability, Efficiency, Correctness,
Functionality, Security, Safety.

(b) Transitional: Important when software is moved from one

platform to another based on – Portability, Reusability,
Adaptability.

(c) Maintenance: How well a software is maintained itself

based on the capabilities like: Modularity, Maintainability,
31
Flexibility, Scalability.
 MODULE : 1
SOFTWARE ENGINEERING
 Software Engineering:
 The nature of software
 Stakeholders in software engineering
 Types of Software,
 Software Engineering Projects,
 Software Engineering Activities,
 Software Process Models
 SDLC Process Models
 Waterfall,
 RAD
 Agile Software Development. 32
 RUP
NATURE OF SOFTWARE ENGINEERING
� Software Engineers design software systems. But the
software differs in important ways from the types of
artifacts produced by other types of engineers like:
❖System Software
❖Application Software

❖Engineering & Scientific Software

❖Embedded Software

❖Product-like Software

❖Web-applications

❖Artificial intelligence Software

33
 NATURE OF SOFTWARE ENGINEERING (CONTD.)
� Software is largely intangible – you cant feel the shape of
a piece of software and its design can be hard to visualize. So,
its difficult for people to assess its quality and hard to
understand development effort.

� Mass-production of duplicate pieces of software –

Engineers are very concerned about the cost of each item and
labour to manufacture it.

� Untrained people can hack something together - It is

too easy for an inadequately trained software developer to
create a piece of software that is difficult to understand and
modify.

� Software is easy to modify - because of its complexity but

it is very difficult to make changes that are correct.

� Software is easy to reproduce – Cost is in its development34

 1.2 STAKEHOLDERS IN
SOFTWARE ENGINEERING
 1.2 STAKEHOLDERS IN SOFTWARE
ENGINEERING
Four major roles:
1. Users - Those who use the software.
2. Customers - Those who pay for the software.
3. Software developers – design, testing,
maintenance, etc.
4. Development Managers – keep the team on
track daily basis, responsible for project
delivery.

All four roles can be fulfilled by the same 36

person.
 STAKEHOLDERS IN SOFTWARE ENGINEERING
 Customers/Users: The individuals or organizations who will use the
finished software product. Their needs and expectations drive the
development process.

 Business Owners/Investors: The individuals or organizations who

fund the software development project. They are interested in the
project's return on investment and overall business value.

 Software Developers: The engineers and programmers who write the

code, test the software, and build the product. They have expertise in
technology and development methodologies.

 Project Managers: Responsible for planning, coordinating, and

monitoring the software development project. They ensure the project
stays on track, within budget, and meets its goals.
37
 STAKEHOLDERS IN SOFTWARE ENGINEERING
 Project Managers: Responsible for planning, coordinating, and
monitoring the software development project. They ensure the
project stays on track, within budget, and meets its goals.
 Quality Assurance (QA) Testers: Ensure the software quality by
identifying and fixing bugs and defects.
 User Interface (UI)/User Experience (UX) Designers: Create the
look and feel of the software, focusing on usability and user
satisfaction.
 Technical Writers: Document the software functionality and user
manuals.
� IT Operations/Deployment Team: Responsible for deploying
38
the software into production and ensuring its ongoing
maintenance and support.
SOFTWARE ENGINEERING PROJECTS

39
SOFTWARE ENGINEERING PROJECTS
� Software engineering work is normally organized into projects.

� For a small software system, there may only be a single

team of three or four developers working on the project.

� For a larger system, the work is usually subdivided into

many smaller projects.

� Software projects are divided into three major categories:

1) those that involve modifying an existing system;
2) those that involve starting to develop a system from scratch, and
3) those that involve building most of a new system from existing
components, while developing new software only for missing
details.
40
SOFTWARE ENGINEERING PROJECTS (CONTD.)
� Most projects are:
(a) Evolutionary or maintenance projects – modifying an
existing system.

(b) Green-field projects

(c) Projects that involve building on a framework or a set

of existing components.

41
SOFTWARE ENGINEERING PROJECTS (CONTD.)
(a) Evolutionary or maintenance projects
� Corrective projects: fixing defects.

� Adaptive projects: changing the system in response to

changes in environment:
❖ Operating system

❖ Database

❖ Rules and regulations

� Enhancement projects: adding new features for users

� Reengineering or perfective projects: changing the

system internally so it is more maintainable.
42
SOFTWARE ENGINEERING PROJECTS (CONTD.)
(b) Green-field projects
Development of entirely new software system from scratch are
less.
� New development
� The minority of projects
� not constrained by the design decisions and errors
� lot of work to build a complex system from scratch.

43
SOFTWARE ENGINEERING PROJECTS (CONTD.)
(c) Projects that involve building on a framework or a set
of existing components.
� The framework is an application that is missing some
important details.
� E.g. Specific rules of this organization.
� Some projects:
❖ Involve plugging together components that are:

❖ Already developed.

❖ Provide significant functionality.

❖ Benefit from reusing reliable software.

❖ Provide much of the same freedom to innovate found in

green field development.

44
SOFTWARE ENGINEERING ACTIVITIES

45
ACTIVITIES COMMON TO SOFTWARE ENGINEERING
Seven Major Activities:
(i) Requirement & Specification
(ii) Design
(iii) Modeling
(iv) Programming
(v) Quality Assurance
(vi) Deployment
(vii) Managing the Process

46
ACTIVITIES COMMON TO SOFTWARE ENGINEERING
(i) Requirement & Specification:
� Includes
❖ Domain analysis
❖ Defining the problem

❖ Requirements gathering

❖ Obtaining input from as many sources as possible

❖ Requirements analysis

❖ Organizing the information

❖ Requirements specification

❖ Writing detailed instructions about how the software

should behave

47
ACTIVITIES COMMON TO SOFTWARE ENGINEERING
(ii) Design:
� Deciding how the requirements should be implemented,
using the available technology

� Includes:
❖ Systems engineering: Deciding what should be in
hardware and what in software
❖ Software architecture: Dividing the system into
subsystems and deciding how the subsystems will
interact
❖ Detailed design of the internals of a subsystem

❖ User interface design

❖ Design of databases

48
ACTIVITIES COMMON TO SOFTWARE ENGINEERING
(iii) Modeling:
� Creating representations of the domain or the software
❖ Use case modeling

❖ Structural modeling

❖ Dynamic and behavioural modeling

(iv) Programming:
� Integral part of software engineering.
� It involves the translation of higher-level designs into
particular programming languages.

(v) Quality Assurance:

� Reviews and inspections
� Testing 49
ACTIVITIES COMMON TO SOFTWARE ENGINEERING
(vi) Deployment:
� Deployment involves distributing and installing the software
and any other components of the system such as databases,
special hardware etc.
� It also involves managing the transition from any previous
system.

(vii) Managing the Process:

� Managing software projects is considered an integral
part of software engineering.
❖ Estimating the cost of the system.
❖ Planning.

50
 MODULE : 1
SOFTWARE ENGINEERING
 1.1 Software Engineering:
 1.2 The nature of software
 1.3 Stakeholders in software engineering
 1.4 Types of Software,
 1.5 Software Engineering Projects,
 1.5 Software Engineering Activities,
 1.6 Software Process Models
1.7 SDLC Process Models
 1.8 Waterfall Model,
 1.9 RAD Model,
 1.10 Agile Software Development Model,
 1.11 RUP Model, 51
 MODULE 1.3 SDLC PROCESS
MODELS
SDLC Process Models:

• There are various SDLC (Software

Development Life Cycle) models that define
the stages and activities involved in developing
software.

• Each model has its own strengths and

weaknesses, and the choice of model depends
on the specific project requirements and
52
context.
SOFTWARE PROCESS MODELS
o A simplified representation of a software process, presented
from a specific perspective.
� Examples of process perspectives:
• Workflow perspective - represents inputs, outputs and
dependencies.
� Data-flow perspective - represents data transformation
activities.
� Role/action perspective - represents the roles/activities
of the people involved in software process.
� A structured set of activities required to develop a
software system:
� Specification

� Design

� Validation

� Evolution

� A software process model is the sequence of phases for the 53

entire lifetime of a product.

SOFTWARE PROCESS MODELS

 Waterfall Model
 RAD
 Agile Software Development.
 RUP
 Opportunistic Model
 Phased Released Model
 Spiral Model
 Evolutionary Model
 Concurrent Engineering Model
54
 WATERFALL MODEL

Waterfall Model:

 Sequential stages: Requirements, design,

development, testing, deployment, and maintenance
follow a strict sequential order.
 Fixed deadlines: Each stage has defined deadlines
and deliverables.
 Little flexibility: Changes are difficult and expensive
to implement once a stage is complete.
 Suitable for: Well-defined projects with stable
requirements and a predictable scope. 55
(A) WATERFALL MODEL (CONTD.)
� Requirements gathering and analysis
� System‟s services, constraints, and goals are established by
consultation with system user.
� Specification & System design
� Partitions the requirement to either hardware or software system.
� Establish the overall system architecture.
� Software design involves in identifying the fundamental software
system abstractions and their relationships.
� Implementation and unit testing
� Software design is realized as a set of programs or program units.
� Unit testing involves verifying that each unit meets its specification.
� Integration and deployment
� Individual program/s are integrated and tested as a complete system
to ensure that the product is deployed/released into the market.
� Operation and maintenance
56
� There are some issues which come up in the client environment.
To fix those issues, patches are released.
(A) WATERFALL MODEL (CONTD.)
� Inflexible partitioning of the project into distinct
stages.
� This makes it difficult to respond to changing customer
requirements.
� Therefore, this model is only appropriate when the
requirements are well-understood.

Waterfall model describes a process of stepwise

refinement
� Based on hardware engineering models.
� Widely used in military and aerospace industries.

❖The drawback of the waterfall model is the

difficulty of accommodating change after the 57
process is underway.
(A) WATERFALL MODEL (CONTD.)
Advantages of waterfall model:
� Simple & Easy to understand and use.
� Easy to manage.

� Phases are processed & completed one at a time.

� Requirements are very well understood.

� Clearly defined stages.

58
WATERFALL MODEL
(A) WATERFALL MODEL (CONTD.)
Dis-advantages of waterfall model:
� Once an application is in the testing stage, it is very
difficult to go back and change something that was not
well-thought out in the concept stage.
� 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 and ongoing projects.

� Not suitable for the projects where requirements are at a

moderate to high risk of changing.
60
(A) WATERFALL MODEL (CONTD.)
� Examples: Waterfall model was used to develop enterprise
applications like:
� Customer Relationship Management (CRM) systems,
� Human Resource Management Systems (HRMS),
� Supply Chain Management Systems,
� Inventory Management Systems,
� Point of Sales (POS) systems for Retail chains etc.

� Development of Department Of Defense (DOD), military and

aircraft programs followed Waterfall model in many
organizations.

� This is because of the strict standards and requirements that

have to be followed.
61
 RAPID APPLICATION DEVELOPMENT
(RAD)

Rapid Application Development (RAD) is

a software development methodology
that emphasizes prototyping, iteration,
and quick feedback to deliver functional
applications in a shorter timeframe
compared to traditional sequential
models.
2. RAD (RAPID APPLICATION DEVELOPMENT)
MODEL:
� Prototyping: Iterative development based on

building and refining prototypes to gather user

feedback.
� Fast feedback: Focuses on early and ongoing

user involvement for rapid feedback and

adaptation.
� Shorter cycles: Development occurs in short

iterative cycles, allowing for flexibility and

adaptation.
� Suitable for: Projects with rapidly changing

requirements or where early user feedback is

crucial.
63
 KEY PRINCIPLES OF RAD:
� Prototyping: Building rough but functional versions
of the system early and often allows for quick user
feedback and rapid course correction.
� Iteration: The development process is iterative, with
features added and refined in successive cycles based
on feedback.
� Timeboxing: Fixed-length development cycles
(sprints) provide a sense of urgency and focus.
� Teamwork: Collaborative teams with diverse skills
work together to rapidly deliver results.
� Adaptive planning: Requirements and plans are
flexible and adapt to changing needs and feedback.
 REQUIREMENTS GATHERING:
� Requirements Gathering: High-level requirements are
identified through workshops and interviews.
� Rapid Prototyping: A basic, functional prototype is developed
in a short timeframe.
� User Feedback: Users evaluate the prototype and provide
feedback for improvement.
� Design and Development: Iterations refine the design,
architecture, and development based on user feedback.
� Testing and Deployment: Each iteration undergoes testing and
refinement before deployment.
� Feedback and Maintenance: Ongoing feedback and user
involvement inform future updates and maintenance.
� RAD is a powerful methodology for projects requiring speed,
flexibility, and user involvement. However, it's essential to
carefully consider its suitability for your specific project needs
and ensure proper planning and implementation to reap its
full benefits.
� I hope this explanation and diagram help you understand RAD
in more detail. Feel free to ask if you have any further
questions!
 BENEFITS OF RAD:
� Reduced time to market: Early prototypes enable
user feedback and iterative improvement, leading to
faster completion.
� Improved user satisfaction: User involvement
throughout the process ensures the software meets
their needs and expectations.
� Reduced risk of failure: Early identification and
correction of potential issues minimizes development
risks.
� Increased flexibility: Adaptability to changing
requirements makes RAD suitable for dynamic
environments.
 Challenges of RAD:

� High initial investment: Requires skilled

professionals and robust prototyping tools, which can
be expensive.
� Requires strong project management: Efficiently
managing iterations and feedback loops is crucial for
success.
� Risk of scope creep: Constant adaptation can lead to
feature overload if not carefully managed.
� May not be suitable for all projects: Complex systems
with stringent requirements might benefit from a
more structured approach.
 3. AGILE SOFTWARE DEVELOPMENT:

� Agile Software Development is a

collaborative and iterative approach to
building software that emphasizes
flexibility, adaptation, and continuous
improvement.
� Unlike traditional sequential models,
Agile embraces change and focuses on
delivering working software in small,
incremental releases with regular
feedback from stakeholders.
69
 3. AGILE SOFTWARE DEVELOPMENT:

� Incremental delivery: Focuses on delivering

working software in small, incremental releases
with regular feedback from stakeholders.
� Cross-functional teams: Self-organizing teams
work collaboratively with frequent
communication and knowledge sharing.
� Adaptive approach: Embraces change and
iterations are encouraged to adjust to evolving
requirements.
� Suitable for: Projects with complex
requirements, uncertainty, or a need for rapid
adaptation.
70
 3. CORE PRINCIPLES OF AGILE:
AGILE SOFTWARE DEVELOPMENT:
� Iterative development: The project is broken down into short
cycles (sprints) typically lasting 1-4 weeks, with each sprint
delivering a working and potentially shippable portion of the
software.
� Incremental delivery: Features are prioritized and delivered in
small increments, allowing for early and continuous feedback.
� Continuous improvement: Each sprint provides opportunities to
learn, adapt, and refine the product based on feedback and
changing needs.
� Cross-functional teams: Self-organizing teams with diverse skills
(developers, testers, designers, etc.) work closely together
throughout the process.
� Continuous communication: Frequent communication and
collaboration among team members and stakeholders are
71
essential for success.
 3. BENEFITS OF AGILE:
AGILE SOFTWARE DEVELOPMENT:
� Faster time to market: Frequent releases enable early
delivery of valuable features and feedback loops that
guide development.
� Increased flexibility: Ability to adapt to changing
requirements and priorities easily due to the iterative
nature.
� Improved quality: Continuous testing and feedback
loops lead to higher quality software.
� Enhanced team morale: Increased ownership and
involvement boost team morale and productivity.
� Better risk management: Early identification and
resolution of issues minimize project risks. 72
 3. CHALLENGES OF AGILE:
AGILE SOFTWARE DEVELOPMENT:
� Requires strong leadership: Effective project
management and Agile coaching are crucial to
facilitate efficient collaboration and prevent scope
creep.
� Disciplined planning: Prioritization and managing
expectations with stakeholders demands effective
communication and clear understanding of goals.
� Can be chaotic: Adapting to change and embracing
ambiguity might feel unsettling for teams
accustomed to rigid methodologies.
� May not be suitable for all projects: Highly regulated
or large-scale projects with strict compliance
requirements might benefit from a more structured73
approach.
74
 AGILE MODEL DIAGRAM EXPLANATION
� Product Backlog: Prioritized list of user stories and features
representing the desired functionality.
� Sprint Planning: Team selects high-priority items from the
backlog for the next sprint and defines the sprint goal.
� Daily Stand-up Meetings: Short daily meetings for team
members to share progress, identify roadblocks, and ensure
alignment.
� Development and Testing: Teams work on assigned tasks
iteratively, with continuous testing and integration throughout
the sprint.
� Sprint Review: Demo and review of completed work from the
sprint with stakeholders, gathering feedback and adapting for
the next iteration.
� Sprint Retrospective: Team reflects on the sprint, identifies areas
for improvement, and adjusts processes for future cycles.
� Agile Software Development offers a flexible and adaptable
approach to software development, promoting continuous
improvement and stakeholder engagement. However, success
requires strong leadership, disciplined planning, and a
comfortable embrace of change and iterative refinement.
 1.8 Waterfall Model,
 1.9 RAD Model,
 1.10 Agile Software Development Model,
 1.11 RUP Model,
 MODULE 1.11 RUP (RATIONAL UNIFIED
PROCESS):

� The Rational Unified Process (RUP) is an

iterative and object-oriented software
development methodology created by Rational
Software (now IBM).

� It provides a structured framework for

managing large and complex software projects
while emphasizing flexibility and risk
management.
 RUP (RATIONAL UNIFIED PROCESS):
� Iterative and incremental: Similar to Agile, but
with more predefined phases and artifacts.
� Use-case driven: Requirements are defined using
use cases, representing user interactions with the
system.
� Architecture-centric: Emphasizes architectural
design throughout the development process.
� Suitable for: Large and complex projects requiring
a structured and disciplined approach.
� These are just some of the popular SDLC models.
Selecting the right model for your project requires
careful consideration of the project size,
complexity, budget, resources, and risk tolerance.
78
 1.11 CORE PRINCIPLES OF RUP:
� Use-case driven: Requirements are defined and
analyzed through use cases, representing user
interactions with the system.
� Iterative and incremental: Development occurs in
four main phases (Inception, Elaboration,
Construction, Transition) with each phase delivering
increasing increments of functionality.
� Architecture-centric: Emphasis is placed on designing
and refining the system architecture throughout the
process.
� Risk-driven: Proactive identification and mitigation
of risks are integral to the methodology.
� Tool-supported: Utilizing various tools and artifacts
guides and facilitates development activities.
 BENEFITS OF RUP:
� Reduced risk: The structured approach and
risk management focus minimize project risks
and uncertainties.
� Improved quality: Iterative development with
continuous testing and feedback ensures
higher quality software.
� Predictability: Defined phases and milestones
provide a clear roadmap for project progress.
� Adaptability: The process allows for adjusting
plans and incorporating changes due to its
iterative nature.
� Scalability: Suitable for managing large and
complex projects with diverse teams.
 CHALLENGES OF RUP:
� Complexity: Can be perceived as more
complex and demanding compared to simpler
Agile methodologies.
� Documentation overhead: Requires detailed
documentation and artifacts, which can be
time-consuming.
� Less flexible: Adapting to significant changes
in requirements might be more challenging
compared to pure Agile approaches.
� Tool dependence: Relies on specific tools and
technologies, which can require additional
investment and learning.
 RUP model diagram
• Inception: Identify business goals, vision, and feasibility. Develop high-
level use cases and architecture. Create a project plan and risk
assessment.
• Elaboration:Refine use cases and architecture. Design key system
components and interfaces. Develop a detailed project plan and risk
mitigation strategies.
• Construction:Implement and test the system in iterative cycles.
Integrate and deploy completed features. Conduct thorough system
testing and defect resolution.
• Transition:Release the software to end users and provide support.
Conduct post-release reviews and lessons learned analysis.
• Plan for future maintenance and enhancements.
RUP offers a well-defined and risk-conscious approach to software
development, particularly for large, complex projects requiring thorough
planning and documentation.
• However, its structured nature and reliance on specific tools might
need careful consideration in comparison to lighter, more agile
methodologies.
(B) OPPORTUNISTIC MODEL
� Opportunistic model is what occurs when an organization does
not follow good engineering practices.
� It does not acknowledge the importance of working out the
requirements and the design before implementing a system.

� There is no explicit recognition of the need for systematic

testing and other forms of quality assurance.
� The above problems make the cost of developing and
maintaining software very high.
� Since there are no plans, there is nothing to aim towards this
84
approach, so it‟s a bad approach mode.
(C) PHASED - RELEASE MODEL
� It introduces the notion of incremental development.
� After requirements gathering and planning, the project
should be broken into separate subprojects, or phases.
� Each phase can be released to customers when ready.
� Parts of the system will be available earlier than when
using a strict waterfall approach.
� It continues to suggest that all requirements be finalized
at the start of development.

85
(C) PHASED - RELEASE MODEL (CONTD.)

86
(D) SPIRAL MODEL
� It explicitly embraces prototyping and an iterative approach to
software development.
� Start by developing a small prototype.
� Followed by a mini-waterfall process, primarily to gather
requirements.
� Then, the first prototype is reviewed.
� In subsequent loops, the project team performs further
requirements, design, implementation and review.
� The first thing to do before embarking on each new loop is
risk analysis.
� Maintenance is simply a type of on-going development.

87
(D) SPIRAL MODEL(CONTD.)

88
(D) SPIRAL MODEL(CONTD.)
Advantages of Spiral model:
� High amount of risk analysis hence, avoidance of Risk is
enhanced.
� Good for large and mission-critical projects.
� Strong approval and documentation control.
� Additional Functionality can be added at a later date.
� Software is produced early in the software life cycle.

Disadvantages of Spiral model:

� Can be a costly model to use.
� Risk analysis requires highly specific expertise.
� Project‟s success is highly dependent on the risk analysis
phase.
89
� Doesn‟t work well for smaller projects.
(E) EVOLUTIONARY MODEL
� Itshows software development as a series of hills, each
representing a separate loop of the spiral.
� Shows that loops, or releases, tend to overlap each other.
� Makes it clear that development work tends to reach a peak,
at around the time of the deadline for completion.
� Shows that each prototype or release can take
� different amounts of time to deliver,

� differing amounts of effort.

90
(E) EVOLUTIONARY MODEL (CONTD.)

91
(E) EVOLUTIONARY MODEL (CONTD.)
� Problems
� Lack of process visibility
� Systems are often poorly structured
� Special skills (e.g. in languages for rapid prototyping) may be
required

� Applicability
� For small or medium-size interactive systems
� For parts of large systems (e.g. the user interface)
� For short-lifetime systems

92
(E) EVOLUTIONARY MODEL (CONTD.)
Advantages:
� In evolutionary model, a user gets a chance to experiment
partially developed system.
� It reduces the error because the core modules get tested
thoroughly.

Disadvantages:
� Sometimes it is hard to divide the problem into several
versions that would be acceptable to the customer which can
be incrementally implemented and delivered.

93
(F) CONCURRENT ENGINEERING MODEL
� It explicitly accounts for the divide and conquer
principle.
� Each team works on its own component, typically following a
spiral or evolutionary approach.
� There has to be some initial planning, and periodic
integration.

94
INTRODUCTION TO OBJECT
ORIENTATION

95
INTRODUCTION TO OBJECT ORIENTATION
� The procedure of identifying software engineering
requirements and developing software specifications in
terms of a software system‟s object model, which
comprises of interacting objects.
� The primary tasks in object-oriented analysis (OOA) are:−
� Identifying objects.
� Organizing the objects by creating object model diagram.

� Defining the internals of the objects, or object attributes.

� Defining the behavior of the objects, i.e., object actions.

� Describing how the objects interact.

96
BASIC CONCEPTS OF OBJECT-ORIENTED
(a) Classes
(b) Objects
(c) Inheritance
(d) Polymorphism
(e) Data Abstraction
(f) Data Encapsulation Objects
Data
Encapsulation
Classes
OOP
Features
Data
Abstraction Inheritance
97
Polymorphism
(A) CLASSES
� User-defined data types on which objects are created.
� Objects with similar properties & methods are grouped
together to join a class.
� Example:
Class Name:
Class Book
Attributes:
Book
Book Title: String
Language: English
Author Name: String
S/w
S/w Testing S/w Quality Operations:
Engineering
addbook( )
Object 1 Object 2 Object 3 deletebook( )
updatebook( )
view( )

98
NAMING CLASSES
� Use capital letters
� E.g. BankAccount not bankAccount

� Use singular nouns

� Use the right level of generality

� E.g. Municipality, not City

� Make sure the name has only one meaning

� E.g. ‘bus’ has several meanings

99
(B) OBJECTS
� Run-time entities that may represent a person, place or
any item.
� Each object contains data & code to manipulate the data.

� Data represents the attributes of that object and

functions represent the behaviour of that object.

Attributes Data

Data

Functions Code

� Objectstake up space in memory and have an associated

add like structure in C.
100
(B) OBJECTS (CONTD.)
� When a program is executed the object interact by sending
messages to one another.
Object 1
Data
&
Functions

Object 2 Object 3
Data Data
& &
Functions Functions

101
DIFFERENCE B/W CLASS & OBJECT

Class Object
Class is a data type. Object is an instance of class.
It generate objects. It gives life to class by adding
features.
Class doesn‟t occupy memory Objects occupy memory
location. locations.
Class cannot be manipulated Objects can be manipulated.
since it is not available in
memory.

102
(C) INHERITANCE
� Each derived class inherits the attributes of its base class &
its process is known as inheritance.
� The existing classes are called the base classes/parent
classes/super-classes, and the new classes are called the derived
classes/child classes/subclasses.
� Example: Class Name: Member
Attributes:
ID: long
Name: String
DOB: Date
Phone: long
addmem( )
deletemem( )
updatemem( )
view( )

Student Faculty Employee

Rollno.: ID.: ID.: 103
School: School: Division:
(C) INHERITANCE (CONTD.)
� Inheritance is the process by which object of one class
acquire the properties of object of another class.
� We can add additional features to an existing class
without modifying it.
� The advantage of inheritance is:
� It express commonality among class/objects.
� Allows code reusability.

� Highlights relationships.

� Helps in code organization.

104
ORGANIZING CLASSES INTO INHERITANCE
� Superclasses
� Contain features common to a set of subclasses.

� Inheritance hierarchies
� Show the relationships among superclasses and subclasses
� A triangle shows a generalization.

� Inheritance
� The implicit possession by all subclasses of features defined in
its superclasses.

105
EX: INHERITANCE HIERARCHY OF MATHEMATICAL
OBJECTS

106
(D) POLYMORPHISM
� Polymeans „Many‟, morphism means „forms‟.
� Representing any item in many forms.

� Two types: compile-time & run-time.

� Requires that there be multiple methods of the same

name.

107
INHERITANCE, POLYMORPHISM & VARIABLES

108
OBJECT ORIENTATED PARADIGMS
�Two different paradigms:
�Procedural paradigm
�Object-oriented paradigm

� An approach to the solution of problems in which all

computations are performed in the context of objects.

� The objects are instances of classes, which:

� are data abstractions.

� contain procedural abstractions that operate on the

objects.

�A running program can be seen as a collection of objects

collaborating to perform a given task. 109
OBJECT ORIENTATION PARADIGMS
�Procedural paradigm:
� Softwareis organized around the notion of procedures
� Procedural abstraction
� Works as long as the data is simple
� Adding data abstractions
� Groups together the pieces of data that describe some entity
� Helps reduce the system‟s complexity.

� Such as Records and structures

�Object-oriented paradigm:
� Organizing procedural abstractions in the context of data
abstractions

110
A VIEW OF TWO PARADIGMS
Procedural paradigm Object-oriented paradigm

111
 Module 1 Summary
Object oriented Software engineering
So far in this Module, we discussed the following concepts..

1.1 Software Engineering:

1.2 The nature of software
1.3 Stakeholders in software engineering
1.4 Types of Software,
1.5 Software Engineering Projects,
1.5 Software Engineering Activities,
1.6 Software Process Models
1.7 SDLC Process Models
1.8 Waterfall Model,
1.9 RAD Model,
1.10 Agile Software Development Model,
1.11 RUP Model, 112
112