SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) AND OOAD

Software Development Life Cycle (SDLC)

Software development life cycle (SDLC) is a structured process that is used to

design, develop, and test good-quality software. SDLC, or software development life
cycle, is a methodology that defines the entire procedure of software development
step-by-step. The goal of the SDLC life cycle model is to deliver high-quality,
maintainable software that meets the user's requirements. SDLC in software
engineering models outlines the plan for each stage so that each stage of the
software development model can perform its task efficiently to deliver the software
at a low cost within a given time frame that meets users requirements. In this
article we will see Software Development Life Cycle (SDLC) in detail.

Stages of the Software Development Life Cycle

SDLC specifies the task(s) to be performed at various stages by a software engineer

or developer. It ensures that the end product is able to meet the customer's
expectations and fits within the overall budget. Hence, it's vital for a software
developer to have prior knowledge of this software development process. SDLC is a
collection of these six stages, and the stages of SDLC are as follows:

Page 1 of 32
Software Development Life Cycle Model SDLC Stages

The SDLC Model involves six phases or stages while developing any software.

Stage-1: Planning and Requirement Analysis

Planning is a crucial step in everything, just as in software development. In this

same stage, requirement analysis is also performed by the developers of the
organization. This is attained from customer inputs, and sales department/market
surveys.

The information from this analysis forms the building blocks of a basic project. The
quality of the project is a result of planning. Thus, in this stage, the basic project is
designed with all the available information.

Page 2 of 32
Stage-1 : Planning and Requirement Analysis

Stage-2: Defining Requirements

In this stage, all the requirements for the target software are specified. These
requirements get approval from customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This is a sort of
document that specifies all those things that need to be defined and created during
the entire project cycle.

Stage-2 : Defining Requirements

Stage-3: Designing Architecture

SRS is a reference for software designers to come up with the best architecture for
the software. Hence, with the requirements defined in SRS, multiple designs for the
product architecture are present in the Design Document Specification (DDS).

This DDS is assessed by market analysts and stakeholders. After evaluating all the
possible factors, the most practical and logical design is chosen for development.

Page 3 of 32
Stage 3: Design

Stage-4: Developing Product

At this stage, the fundamental development of the product starts. For this,
developers use a specific programming code as per the design in the DDS. Hence, it
is important for the coders to follow the protocols set by the association.
Conventional programming tools like compilers, interpreters, debuggers, etc. are
also put into use at this stage. Some popular languages like C/C++, Python, Java,
etc. are put into use as per the software regulations.

Stage 4: Development

Page 4 of 32
Stage-5: Product Testing and Integration

After the development of the product, testing of the software is necessary to ensure
its smooth execution. Although, minimal testing is conducted at every stage of
SDLC. Therefore, at this stage, all the probable flaws are tracked, fixed, and
retested. This ensures that the product confronts the quality requirements of SRS.

Documentation, Training, and Support: Software documentation is an essential

part of the software development life cycle. A well-written document acts as a tool
and means to information repository necessary to know about software processes,
functions, and maintenance. Documentation also provides information about how to
use the product. Training in an attempt to improve the current or future employee
performance by increasing an employee's ability to work through learning, usually
by changing his attitude and developing his skills and understanding.

Stage 5: Testing

Stage-6: Deployment and Maintenance of Products

After detailed testing, the conclusive product is released in phases as per the
organization’s strategy. Then it is tested in a real industrial environment. It is
important to ensure its smooth performance. If it performs well, the organization
sends out the product as a whole. After retrieving beneficial feedback, the company
releases it as it is or with auxiliary improvements to make it further helpful for the

Page 5 of 32
customers. However, this alone is not enough. Therefore, along with the
deployment, the product's supervision.

Stage 6: Deployment and Maintenance

Software Development Life Cycle Models

To this day, we have more than 50 recognized SDLC models in use. But None of
them is perfect, and each brings its favorable aspects and disadvantages for a
specific software development project or a team.

The top five most popular SDLC models:

1. Waterfall Model

It is the fundamental model of the software development life cycle. This is a very
simple model. The waterfall model is not in practice anymore, but it is the basis
for all other SDLC models. Because of its simple structure, the waterfall model is
easier to use and provides a tangible output. In the waterfall model, once a phase
seems to be completed, it cannot be changed, and due to this less flexible nature,
the waterfall model is not in practice anymore.

Phases of Waterfall Model

Page 6 of 32
Classical Waterfall Model divides the life cycle into a set of phases. The
development process can be considered as a sequential flow in the waterfall. The
different sequential phases of the classical waterfall model are follow:

Waterfall Model-Software Engineering

Phases in detail :

1. Requirements Analysis and Specification

Requirement Analysis and specification phase aims to understand the exact

requirements of the customer and document them properly. This phase consists of
two different activities.

1. Requirement Gathering and Analysis: Firstly all the requirements regarding

the software are gathered from the customer and then the gathered requirements
are analyzed.

The goal of the analysis part is to remove incompleteness (an incomplete

requirement is one in which some parts of the actual requirements have been
omitted) and inconsistencies (an inconsistent requirement is one in which some part
of the requirement contradicts some other part).

2. Requirement Specification: These analyzed requirements are documented in

a software requirement specification (SRS) document. SRS document serves as a
Page 7 of 32
contract between the development team and customers. Any future dispute
between the customers and the developers can be settled by examining the SRS
document.

2. Design

The goal of this Software Design Phase is to convert the requirements acquired
in the SRS into a format that can be coded in a programming language. It includes
high-level and detailed design as well as the overall software architecture.
A Software Design Document is used to document all of this effort (SDD).

 High-Level Design (HLD): This phase focuses on outlining the broad

structure of the system. It highlights the key components and how they
interact with each other, giving a clear overview of the system’s architecture.

 Low-Level Design (LLD): Once the high-level design is in place, this phase
zooms into the details. It breaks down each component into smaller parts and
provides specifics about how each part will function, guiding the actual
coding process.

3. Development

In the Development Phase software design is translated into source code using
any suitable programming language. Thus each designed module is coded. The unit
testing phase aims to check whether each module is working properly or not.

 In this phase, developers begin writing the actual source code based on the
designs created earlier.

 The goal is to transform the design into working code using the most suitable
programming languages.

 Unit tests are often performed during this phase to make sure that each
component functions correctly on its own.

4. Testing and Deployment

1. Testing: Integration of different modules is undertaken soon after they have

been coded and unit tested. Integration of various modules is carried out
incrementally over several steps. During each integration step, previously planned

Page 8 of 32
modules are added to the partially integrated system and the resultant system is
tested. Finally, after all the modules have been successfully integrated and tested,
the full working system is obtained and system testing is carried out on this. System
testing consists of three different kinds of testing activities as described below.

 Alpha testing: Alpha testing is the system testing performed by the

development team.

 Beta testing: Beta testing is the system testing performed by a friendly set
of customers.

 Acceptance testing: After the software has been delivered, the customer
performs acceptance testing to determine whether to accept the delivered
software or reject it.

2. Deployment: Once the software has been thoroughly tested, it's time to deploy
it to the customer or end-users. This means making the software ready and
available for use, often by moving it to a live or staging environment.

During this phase, we also focus on helping users get comfortable with the software
by providing training, setting up necessary environments, and ensuring everything
is running smoothly. The goal is to make sure the system works as expected in real-
world conditions and that users can start using it without any hitches.

5. Maintenance

In Maintenance Phase is the most important phase of a software life cycle. The
effort spent on maintenance is 60% of the total effort spent to develop a full
software. There are three types of maintenance.

 Corrective Maintenance: This type of maintenance is carried out to correct

errors that were not discovered during the product development phase.

 Perfective Maintenance: This type of maintenance is carried out to

enhance the functionalities of the system based on the customer’s request.

 Adaptive Maintenance: Adaptive maintenance is usually required for

porting the software to work in a new environment such as working on a new
computer platform or with a new operating system.

Page 9 of 32
Example of real-world example of the Waterfall Model.

Real-Life Example of Waterfall Model: Developing an Online Banking

System

1. Analysis

This phase will be tasked with gathering all the information available on customer
banking requirements, transactions, security protocols, and devising the different
parameters that’ll be used for determining the core functionalities of the online
banking system, such as account management, fund transfers, bill payments, and
loan applications.

2. Design

In this example of the Waterfall Model, the design phase is all about fine-tuning the
parameters established in the analysis phase. The system’s architecture will be
designed to manage sensitive data securely, avoid transactional errors, and ensure
high performance. This includes database structure, user interface design,
encryption protocols, and multi-factor authentication to protect user accounts.

3. Implementation

This all-important phase involves doing dummy runs of the online banking system
with a provisional set of banking transactions and customer data to see the
accuracy with which the system can handle transactions, balance inquiries, fund
transfers, and bill payments. These results should be matched with results from
banking experts and auditors who ensure compliance with banking regulations and
accuracy in transactions.

4. Testing

As with any example of the Waterfall Model, the testing phase is about ensuring that
all features of the online banking system function smoothly. This includes testing for
security vulnerabilities, transaction accuracy, performance under heavy load, and
user interface responsiveness. Special attention is given to testing secure logins,

Page 10 of 32
data encryption, and ensuring that sensitive data is handled correctly throughout
the system.

5. Maintenance

In the final phase, the online banking system should be checked for any necessary
updates or alterations that may be required, besides the expected inclusion of new
features or changes in banking regulations. Regular updates will also be needed for
security patches, performance improvements, and the addition of new services like
mobile banking, instant loans, or personalized financial advice.

Advantages of Waterfall Model

The classical waterfall model is an idealistic model for software development. It is

very simple, so it can be considered the basis for other software development life
cycle models. Below are some of the major advantages of this SDLC model.

 Easy to Understand: The Classical Waterfall Model is very simple and easy
to understand.

 Individual Processing: Phases in the Classical Waterfall model are

processed one at a time.

 Properly Defined: In the classical waterfall model, each stage in the model
is clearly defined.

 Clear Milestones: The classical Waterfall model has very clear and well-
understood milestones.

 Properly Documented: Processes, actions, and results are very well

documented.

 Reinforces Good Habits: The Classical Waterfall Model reinforces good

habits like define-before-design and design-before-code.

 Working: Classical Waterfall Model works well for smaller projects and
projects where requirements are well understood.

Disadvantages of Waterfall Model

Page 11 of 32
The Classical Waterfall Model suffers from various shortcomings we can’t use it in
real projects, but we use other software development lifecycle models which are
based on the classical waterfall model. Below are some major drawbacks of this
model.

 No Feedback Path: In the classical waterfall model evolution of software

from one phase to another phase is like a waterfall. It assumes that no error
is ever committed by developers during any phase. Therefore, it does not
incorporate any mechanism for error correction.

 Difficult to accommodate Change Requests: This model assumes that all

the customer requirements can be completely and correctly defined at the
beginning of the project, but the customer's requirements keep on changing
with time. It is difficult to accommodate any change requests after the
requirements specification phase is complete.

 No Overlapping of Phases: This model recommends that a new phase can

start only after the completion of the previous phase. But in real projects, this
can't be maintained. To increase efficiency and reduce cost, phases may
overlap.

 Limited Flexibility: The Waterfall Model is a rigid and linear approach to

software development, which means that it is not well-suited for projects with
changing or uncertain requirements. Once a phase has been completed, it is
difficult to make changes or go back to a previous phase.

 Limited Stakeholder Involvement: The Waterfall Model is a structured and

sequential approach, which means that stakeholders are typically involved in
the early phases of the project (requirements gathering and analysis) but
may not be involved in the later phases (implementation, testing, and
deployment).

 Late Defect Detection: In the Waterfall Model, testing is typically done

toward the end of the development process. This means that defects may not
be discovered until late in the development process, which can be expensive
and time-consuming to fix.

Page 12 of 32
  Lengthy Development Cycle: The Waterfall Model can result in a lengthy
development cycle, as each phase must be completed before moving on to
the next. This can result in delays and increased costs if requirements change
or new issues arise.

Applications of Waterfall Model

Here are some application of SDLC waterfall model:

 Large-scale Software Development Projects: The Waterfall Model is

often used for large-scale software development projects, where a structured
and sequential approach is necessary to ensure that the project is completed
on time and within budget.

 Safety-Critical Systems: The Waterfall Model is often used in the

development of safety-critical systems, such as aerospace or medical
systems, where the consequences of errors or defects can be severe.

 Government and Defense Projects: The Waterfall Model is also commonly

used in government and defense projects, where a rigorous and structured
approach is necessary to ensure that the project meets all requirements and
is delivered on time.

 Projects with well-defined Requirements: The Waterfall Model is best

suited for projects with well-defined requirements, as the sequential nature of
the model requires a clear understanding of the project objectives and scope.

 Projects with Stable Requirements: The Waterfall Model is also well-

suited for projects with stable requirements, as the linear nature of the model
does not allow for changes to be made once a phase has been completed.

2. Agile Model

The agile model in SDLC was mainly designed to adapt to changing requests quickly.
The main goal of the Agile model is to facilitate quick project completion. The agile
model refers to a group of development processes. These processes have some

Page 13 of 32
similar characteristics but also possess certain subtle differences among
themselves.

Steps in the Agile Model

The Agile Model is a combination of iterative and incremental process models. The
phases involve in Agile (SDLC) Model are:

1. Requirement Gathering

2. Design the Requirements

3. Construction / Iteration

4. Testing / Quality Assurance

5. Deployment

6. Feedback

1. Requirement Gathering

In this step, the development team must gather the requirements, by interaction
with the customer. development team should plan the time and effort needed to
build the project. Based on this information you can evaluate technical and
economical feasibility.

 Meet with the customer to really understand their needs and what they
expect from the software.

Page 14 of 32
  Identify the key requirements and business goals to make sure everyone is on
the same page.

 Estimate how much time and effort it will take to develop the software.

 Assess if the project is technically possible and whether it's worth the
investment from both a technical and economic standpoint.

2. Design the Requirements

In this step, the development team will use user-flow-diagram or high-level UML
Diagrams to show the working of the new features and show how they will apply to
the existing software. Wireframing and designing user interfaces are done in this
phase.

 Designing the system: Once the requirements are gathered, the next step
is to design the system’s overall architecture based on those needs. This
helps to verify the software is structured in a way that meets the user’s
expectations.

 Creating wireframes: Next, wireframes for the user interface (UI) are
created. These are simple blueprints that show how the software will look and
how users will interact with it, ensuring it’s user-friendly and easy to
navigate.

 High-level design with UML diagrams: At this stage, high-level designs

using UML (Unified Modeling Language) diagrams are created to visually
represent the software’s structure and how different parts will work together.

 Prototyping for feedback: Prototypes are made to give stakeholders an

early look at the software. This helps gather feedback early in the process
and allows for adjustments before the full development begins.

3. Construction / Iteration

In this step, development team members start working on their project, which aims
to deploy a working product. Each cycle typically consist between 1-4 weeks, and
at the end, the team delivers a working version of the software.

Page 15 of 32
  Development of Features: The team works on the features identified
during the requirement and design phases.

 Coding and Implementation: New functionalities are coded and integrated

into the software based on the goals for that specific iteration.

 Delivering a Working Product: After each iteration, a usable version of the

software is ready.

 Incremental Improvement: With every cycle, the software is enhanced,

adding more features and refining existing ones.

4. Testing / Quality Assurance

Testing involves Unit Testing, Integration Testing, and System Testing, Which help in
the agile development models:

 Unit Testing: Unit testing is the process of checking small pieces of code to
ensure that the individual parts of a program work properly on their own. Unit
testing is used to test individual blocks (units) of code.

 Integration Testing: Integration testing is used to identify and resolve any

issues that may arise when different units of the software are combined.

 System Testing: Goal is to ensure that the software meets the requirements
of the users and that it works correctly in all possible scenarios.

5. Deployment

In this step, the development team will deploy the working project to end users.

Once an iteration is finished and fully tested, the software is ready to be released to
the end users. In Agile, deployment isn't a one-time event—it's an ongoing process.
Updates and improvements are rolled out regularly, making sure the software keeps
evolving and getting better with each release.

 Deploy the software to a test or live environment so that it can be used by

customers or end-users.

 Make the software accessible to users, verifying they can start using it as
expected.

Page 16 of 32
  Verify the deployment goes smoothly and fix any issues that come up quickly

6. Feedback

This is the last step of the Agile Model. In this, the team receives feedback about
the product and works on correcting bugs based on feedback provided by the
customer.

 Take feedback from customers, users, and stakeholders after each iteration.

 Understand how well the product meets user needs and identify areas for
improvement.

 Check for bugs or issues that need fixing.

 Make adjustments to the development plan based on feedback to improve

the product further.

Advantages of the Agile Model

 Working through Pair programming produces well-written compact programs

which have fewer errors as compared to programmers working alone.

 It reduces the total development time of the whole project.

 Agile development emphasizes face-to-face communication among team

members, leading to better collaboration and understanding of project goals.

 Customer representatives get the idea of updated software products after

each iteration. So, it is easy for him to change any requirement if needed.

 Agile development puts the customer at the center of the development

process, ensuring that the end product meets their needs.

Disadvantages of the Agile Model

 The lack of formal documents creates confusion and important decisions

taken during different phases can be misinterpreted at any time by different
team members.

 It is not suitable for handling complex dependencies.

Page 17 of 32
  The agile model depends highly on customer interactions so if the customer
is not clear, then the development team can be driven in the wrong direction.

 Agile development models often involve working in short sprints, which can
make it difficult to plan and forecast project timelines and deliverables. This
can lead to delays in the project and can make it difficult to accurately
estimate the costs and resources needed for the project.

 Agile development models require a high degree of expertise from team

members, as they need to be able to adapt to changing requirements and
work in an iterative environment. This can be challenging for teams that are
not experienced in agile development practices and can lead to delays and
difficulties in the project.

 Due to the absence of proper documentation, when the project completes

and the developers are assigned to another project, maintenance of the
developed project can become a problem.

3. Iterative Model

In the Iterative model in SDLC, each cycle results in a semi-developed but

deployable version; with each cycle, some requirements are added to the software,
and the final cycle results in the software with the complete requirement
specification.

4. Spiral Model

The spiral model in SDLC is one of the most crucial SDLC models that provides
support for risk handling. It has various spirals in its diagrammatic representation;
the number of spirals depends upon the type of project. Each loop in the spiral
structure indicates the Phases of the Spiral model.

Phases of the Spiral Model

Page 18 of 32
The Spiral Model is a risk-driven model, meaning that the focus is on managing risk
through multiple iterations of the software development process. Each phase of
the Spiral Model is divided into four Quadrants:

Spiral Model - SDLC

1. Objectives Defined

In first phase of the spiral model we clarify what the project aims to achieve,
including functional and non-functional requirements.

Requirements are gathered from the customers and the objectives are identified,
elaborated, and analyzed at the start of every phase. Then alternative solutions
possible for the phase are proposed in this quadrant.

2. Risk Analysis and Resolving

In the risk analysis phase, the risks associated with the project are identified and
evaluated.

During the second quadrant, all the possible solutions are evaluated to select the
best possible solution. Then the risks associated with that solution are identified and
the risks are resolved using the best possible strategy. At the end of this quadrant,
the Prototype is built for the best possible solution.

3. Develop the next version of the Product

Page 19 of 32
During the third quadrant, the identified features are developed and verified
through testing. At the end of the third quadrant, the next version of the software is
available.

In the evaluation phase, the software is evaluated to determine if it meets the

customer's requirements and if it is of high quality.

4. Review and plan for the next Phase

In the fourth quadrant, the Customers evaluate the so-far developed version of the
software. In the end, planning for the next phase is started.

The next iteration of the spiral begins with a new planning phase, based on the
results of the evaluation.

The Spiral Model is often used for complex and large software development
projects, as it allows for a more flexible and adaptable approach to Software
development. It is also well-suited to projects with significant uncertainty or high
levels of risk.

The Radius of the spiral at any point represents the expenses (cost) of the project
so far, and the angular dimension represents the progress made so far in the
current phase.

Example of Spiral Model

Here we can take a Real world example of the Spiral Model.

Real-Life Example of Spiral Model: Developing an E-Commerce Website

1. First Spiral - Planning and Requirements:

In this first phase, the team gathers the basic requirements for the e-commerce
website, like product listings, shopping carts, and payment options. They also
identify potential risks, like security issues or scalability concerns.

To get started, they build a simple prototype, like a homepage with a basic product
catalog, to see how users interact with it and spot any initial design problems.

2. Second Spiral - Risk Analysis and Refining the Design

Page 20 of 32
After getting feedback from the first prototype, the team moves to the next phase.
They add more features and address the problems that were found earlier.

This includes verifying secure payment processing and testing how the site handles
more users. They also add a basic shopping cart and user registration system, and
they run tests with dummy transactions to make sure everything is secure.

3. Third Spiral - Detailed Implementation

With more feedback in hand, the team adds advanced features, like order tracking,
customer reviews, and a search function. They also revisit any remaining risks,
especially around scalability making sure the website can handle a growing number
of users.

During this phase, the team tests the site to verify it can handle large orders,
especially during busy times like sales or holidays.

4. Final Spiral - Full Deployment

In the last phase, the website is fully implemented, tested properly, and then
launched to the public. Any remaining risks, like potential crashes or user feedback
issues, are closely monitored and dealt with.

This example shows how the Spiral Model allows for continuous improvement, with
feedback and risk assessment at each step to make sure the final product is solid
and reliable.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.

1. Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development
model to follow due to the risk analysis and risk handling at every phase.

2. Good for large projects: It is recommended to use the Spiral Model in large
and complex projects.

3. Flexibility in Requirements: Change requests in the Requirements at a

later phase can be incorporated accurately by using this model.

Page 21 of 32
 4. Customer Satisfaction: Customers can see the development of the product
at the early phase of the software development and thus, they habituated
with the system by using it before completion of the total product.

5. Iterative and Incremental Approach: The Spiral Model provides an

iterative and incremental approach to software development, allowing for
flexibility and adaptability in response to changing requirements or
unexpected events.

6. Emphasis on Risk Management: The Spiral Model places a strong

emphasis on risk management, which helps to minimize the impact of
uncertainty and risk on the software development process.

7. Improved Communication: The Spiral Model provides for regular

evaluations and reviews, which can improve communication between the
customer and the development team.

8. Improved Quality: The Spiral Model allows for multiple iterations of the
software development process, which can result in improved software quality
and reliability.

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.

1. Complex: The Spiral Model is much more complex than other SDLC models.

2. Expensive: Spiral Model is not suitable for small projects as it is expensive.

3. Too much dependability on Risk Analysis: The successful completion of

the project is very much dependent on Risk Analysis. Without very highly
experienced experts, it is going to be a failure to develop a project using this
model.

4. Difficulty in time management: As the number of phases is unknown at

the start of the project, time estimation is very difficult.

5. Complexity: The Spiral Model can be complex, as it involves multiple

iterations of the software development process.

Page 22 of 32
 6. Time-Consuming: The Spiral Model can be time-consuming, as it requires
multiple evaluations and reviews.

7. Resource Intensive: The Spiral Model can be resource-intensive, as it

requires a significant investment in planning, risk analysis, and evaluations.

5. V-Shaped Model

The V-shaped model in SDLC is executed in a sequential manner in V-shape. Each

stage or phase of this model is integrated with a testing phase. After every
development phase, a testing phase is associated with it, and the next phase will
start once the previous phase is completed, i.e., development & testing. It is also
known as the verification or validation model.

6. Big Bang Model

The Big Bang model in SDLC is a term used to describe an informal and
unstructured approach to software development, where there is no specific
planning, documentation, or well-defined phases.

Real Life Example of SDLC

Developing a banking application using SDLC:

 Planning and Analysis: During this stage, business stakeholders'

requirements about the functionality and features of banking application will
be gathered by program managers and business analysts. Detailed SRS
(Software Requirement Specification) documentation will be produced by
them. Together with business stakeholders, business analysts will analyse and
approve the SRS document.

 Design: Developers will receive SRS documentation. Developers will read

over the documentation and comprehend the specifications. Web pages will
be designed by designers. High level system architecture will be prepared by
developers.

 Development: During this stage, development will code. They will create the
web pages and APIs needed to put the feature into practice.

Page 23 of 32
  Testing: Comprehensive functional testing will be carried out. They will
guarantee that the banking platform is glitch-free and operating properly.

 Deployment and Maintenance: The code will be made available to

customers and deployed. Following this deployment, the customer can access
the online banking. The same methodology will be used to create any
additional features.

How to Choose an SDLC Model?

Choosing the right SDLC (Software Development Life Cycle) model is essential for
project success. Here are the key factors to consider:

1. Project Requirements:

 Clear Requirements: Use Waterfall or V-Model if requirements are

well-defined and unlikely to change.

 Changing Requirements: Use Agile or Iterative models if

requirements are unclear or likely to evolve.

2. Project Size and Complexity:

 Small Projects: Use Waterfall or RAD for small, simple projects.

 Large Projects: Use Agile, Spiral, or DevOps for large, complex

projects that need flexibility.

3. Team Expertise:

 Experienced Teams: Use Agile or Scrum if the team is familiar with

iterative development.

 Less Experienced Teams: Use Waterfall or V-Model for teams

needing structured guidance.

4. Client Involvement:

 Frequent Client Feedback: Use Agile, Scrum, or RAD if regular

client interaction is needed.

Page 24 of 32
  Minimal Client Involvement: Use Waterfall or V-Model if client
involvement is low after initial planning.

5. Time and Budget Constraints:

 Fixed Time and Budget: Use Waterfall or V-Model if you have

strict time and budget limits.

 Flexible Time and Budget: Use Agile or Spiral if you can adjust
time and budget as needed.

6. Risk Management:

 High-Risk Projects: Use Spiral for projects with significant risks and
uncertainties.

 Low-Risk Projects: Use Waterfall for projects with minimal risks.

7. Product Release Timeline:

 Quick Release Needed: Use Agile or RAD to deliver products

quickly.

 Longer Development Time: Use Waterfall or V-Model for projects

with no urgent deadlines.

8. Maintenance and Support:

 Long-Term Maintenance: Use Agile or DevOps for projects needing

continuous updates and support.

 Minimal Maintenance: Use Waterfall or V-Model if little future

maintenance is expected.

9. Stakeholder Expectations:

 High Stakeholder Engagement: Use Agile or Scrum if stakeholders

want ongoing involvement.

 Low Stakeholder Engagement: Use Waterfall or V-Model if

stakeholders prefer involvement only at major milestones.

Note:

Page 25 of 32
  Waterfall: Best for clear, stable projects with minimal changes.

 V-Model: Good for projects with clear requirements and a strong focus on
testing.

 Agile/Scrum: Ideal for projects with changing requirements and frequent

client interaction.

 Spiral: Suitable for high-risk projects with evolving requirements.

 RAD: Useful for projects needing rapid development.

 DevOps: Best for continuous integration and ongoing support

OBJECT-ORIENTED ANALYSIS AND DESIGN (OOAD)

OOAD is based on the concepts of object-oriented programming (OOP) and is an

organized and systematic approach to designing and developing software systems.
It is a software engineering paradigm that integrates two distinct but closely related
processes: Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD).

Important Aspects of OOAD

Below are some important aspects of OOAD:

 Object-Oriented Programming: In this the real-world items are

represented/mapped as software objects with attributes and methods that
relate to their actions.

 Design Patterns: Design patterns are used by OOAD to help developers in

building software systems that are more efficient and maintainable.

 UML Diagrams: UML diagrams are used in OOAD to represent the different
components and interactions of a software system.

 Use Cases: OOAD uses use cases to help developers understand the
requirements of a system and to design software systems that meet those
requirements.

Object-Oriented Analysis

Page 26 of 32
Object-Oriented Analysis (OOA) is the process of understanding and analyzing the
system requirements by looking at the problem scenario in terms of objects.

 These objects represent real-world entities or concepts that are relevant to

the system being developed.

 During OOA, the goal is to identify the objects, their attributes, behaviors,
and relationships, without focusing on how the system will be implemented.

For example: Lets say you're building a game:

 OOA helps you figure out all the things you need to know about the game
world - the characters, their features, and how they interact.

 It's like making a map of everything important.

 OOA also helps you understand what your game characters will do. It's like
writing down a script for each character.

 Every program has specific tasks or jobs it needs to do. OOA helps you list
and describe these jobs.

 In our game, it could be tasks like moving characters or keeping score. It's
like making a to-do list for your software.

 OOA is smart about breaking things into different parts. It splits the job into
three categories: things your game knows, things your game does, and how
things in your game behave.

Object-Oriented Design

In the object-oriented software development process, the analysis model, which is

initially formed through object-oriented analysis (OOA), undergoes a transformation
during object-oriented design (OOD) i.e implementation of the conceptual model
developed in OOA. This evolution is crucial because it shapes the analysis model
into a detailed design model.

Furthermore, as part of the object-oriented design process, it is essential to define

specific aspects:

 Data Organization of Attributes:

Page 27 of 32
 o OOD involves specifying how data attributes are organized within the
objects.

o This includes determining the types of data each object will hold and
how they relate to one another.

 Procedural Description of Operations:

o OOD requires a procedural description for each operation that an

object can perform.

o This involves detailing the steps or processes involved in carrying out

specific tasks.

Below diagram shows a design pyramid for object-oriented systems. It is having the
following four layers.

1. The Subsystem Layer: It represents the subsystem that enables software

to achieve user requirements and implement technical frameworks that meet
user needs.

Page 28 of 32
 2. The Class and Object Layer: It represents the class hierarchies that enable
the system to develop using generalization and specialization. This layer also
represents each object.

3. The Message Layer: This layer deals with how objects interact with each
other. It includes messages sent between objects, method calls, and the flow
of control within the system.

4. The Responsibilities Layer: It focuses on the responsibilities of individual

objects. This includes defining the behavior of each class, specifying what
each object is responsible for, and how it responds to messages.

Benefits of Object-Oriented Analysis and Design(OOAD)

 It increases the modularity and maintainability of software by encouraging

the creation of tiny, reusable parts that can be combined to create more
complex systems.

 It provides a high-level, abstract representation of a software system, making

understanding and maintenance easier.

 It promotes object-oriented design principles and the reuse of objects, which

lowers the amount of code that must be produced and raises the quality of
the program.

 Software engineers can use the same language and method that OOAD
provides to communicate and work together more successfully in groups.

 It can assist developers in creating scalable software systems that can adapt
to changing user needs and business demands over time.

Challenges of Object-Oriented Analysis and Design(OOAD)

 Because objects and their interactions need to be carefully explained and

handled, it might complicate a software system.

 Because objects must be instantiated, managed, and interacted with, this

may result in additional overhead and reduce the software's speed.

 For beginner software engineers, OOAD might have a challenging learning

curve since it requires a solid grasp of OOP principles and methods.

Page 29 of 32
  It can be a time-consuming process that involves significant upfront planning
and documentation. This can lead to longer development times and higher
costs.

 OOAD can be more expensive than other software engineering methodologies

due to the upfront planning and documentation required.

Real world applications of Object-Oriented Analysis and Design(OOAD)

Some examples of OOAD's practical uses are listed below:

 Banking Software: In banking systems, OOAD is frequently used to

simulate complex financial transactions, structures, and customer
interactions. Designing adaptable and reliable financial apps is made easier
by OOAD's modular and scalable architecture.

 Electronic Health Record (EHR) Systems: Patient data, medical records,

and healthcare workflows are all modeled using OOAD. Modular and flexible
healthcare apps that may change to meet emerging requirements can be
made through object-oriented principles.

 Flight Control Systems: OOAD is crucial in designing flight control systems

for aircraft. It helps model the interactions between different components
such as navigation systems, sensors, and control surfaces, ensuring safety
and reliability.

 Telecom Billing Systems: In the telecom sector, OOAD is used to model

and build billing systems. It enables the modular and scalable modeling of
complex subscription plans, invoicing rules, and client data.

 Online Shopping Platforms: E-commerce system development frequently

makes use of OOAD. Product catalogs, user profiles, shopping carts, and
payment procedures are all modeled, which facilitates platform maintenance
and functionality expansion.

Phases of Object-Oriented Analysis and Design:

1. Requirements Gathering

Page 30 of 32
This phase involves gathering and documenting the requirements of the system
from stakeholders, including users, customers, and other relevant parties.
Requirements are typically captured in a document called the Software
Requirements Specification (SRS).

2. Analysis

In this phase, the focus is on understanding the problem domain and identifying the
objects, classes, and their relationships that will be part of the software system.
Requirements gathered in the previous phase are analyzed to identify the key
functionalities and constraints of the system.

3. Design

The design phase focuses on translating the analysis model into a design model.
This includes defining the architecture of the system, designing the individual
classes and their relationships, and specifying how the system will be implemented.

4. Implementation

In this phase, the design is implemented in code. Object-oriented programming

languages such as Java, C++, or Python are commonly used for implementation.
The implementation phase also involves testing and debugging to ensure that the
software meets the specified requirements.

5. Testing

The testing phase involves verifying that the software functions correctly and meets
the requirements specified in the SRS. Various testing techniques, such as unit
testing, integration testing, and system testing, are used to ensure the quality of
the software.

6. Deployment

Once the software has been tested and approved, it is deployed to the production
environment. This may involve installing the software on users' computers, servers,
or other devices, and ensuring that it operates correctly in the production
environment.

7. Maintenance

Page 31 of 32
The maintenance phase involves updating the software to fix bugs, add new
features, or improve performance. This phase is ongoing throughout the life cycle of
the software.

Page 32 of 32