02-09-2025

Unit - I Basics of Software Engineering

 1.1 Software, software engineering as layered approach, characteristics of software, types of software

 1.2 Software development framework: Software generic process framework activities and umbrella
activities

 1.3 Software engineering core principles, communication practices, planning practices, modelling
practices, construction practices, software deployment practices

 1.4 Prescriptive process models: Waterfall model, incremental model, RAD model, prototyping
model, spiral model

 1.5 Agile software development: Agile process, and its importance, extreme programming, scrum

 1.6 Selection criteria for software process model

What is Software? Software

 Defining Software

Software is: (1) instructions (computer

programs) that when executed provide

desired features, function, and

performance; (2) data structures that

enable the programs to adequately

manipulate information; and (3)

descriptive information in both hard copy

and virtual forms that describes the

operation and use of the programs.

Characteristics of “Software” in Software Engineering

1. Software is developed 2. The software 3. The software continues

or engineered; it is not doesn’t “wear out.” to be custom-built.

manufactured in the

classical sense.

1
 02-09-2025

Characteristics of the Software

 It is intangible, meaning it cannot be seen or touched.

 It is non-perishable, meaning it does not degrade over time.

 It is easy to replicate, meaning it can be copied and distributed easily.

 It can be complex, meaning it can have many interrelated parts and features.

 It can be difficult to understand and modify, especially for large and complex systems.

 It can be affected by changing requirements, meaning it may need to be updated or modified as

the needs of users change.

 It can be impacted by bugs and other issues, meaning it may need to be tested and debugged to Failure curve for hardware Failure curves for software
ensure it works as intended.

Software Engineering
Software Engineering: The application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software; that is, the application of engineering to

software.

A “systematic, disciplined, and quantifiable” approach applied by one software team may be

burdensome to another.

So we need discipline, but we also need adaptability and agility.

Software Engineering Layers

 Software engineering is a layered technology. Any
engineering approach (including software
engineering) must rest on an organizational
commitment to quality.
 Total quality management (TQM) or Six Sigma,
and similar philosophies that foster a culture of
continuous process improvement.
 It is this culture that ultimately leads to more
effective approaches to software engineering.
 The bedrock that supports software engineering is a
quality focus.

2
 02-09-2025

Software Engineering Layers Software Engineering Layers

 The foundation for software engineering is the process  Software engineering methods provide the
layer.
technical how to’s for building software.
 The software engineering process is the glue that holds
 Methods encompass a broad array of tasks that
the technology layers together and enables rational and
timely development of computer software. include communication, requirements
 Process defines a framework that must be established for analysis, design modelling, program
effective delivery of software engineering technology. construction, testing, and support.
 The software process forms the basis for management
 Software engineering methods rely on a set of
control of software projects and establishes the context in
which technical methods are applied, work products basic principles that govern each area of the
(models, documents, data, reports, forms, etc.) are technology and include modelling activities
produced, milestones are established, quality is ensured, and other descriptive techniques.
and change is properly managed.

Software Engineering Layers

 Software engineering tools provide automated

or semi-automated support for the process and
the methods.
 When tools are integrated so that information
created by one tool can be used by another, a
system for the support of software
development, called computer-aided software
engineering.

Software Application Domains / Types of Software Software Application Domains / Types of Software
System software. Engineering/scientific software.
A collection of programs written to service other programs. Some system software (e.g., compilers, editors, A broad array of “number-crunching” or data science programs that range from astronomy to volcanology,

and file management utilities) processes complex, but determinate, information structures. Other systems from automotive stress analysis to orbital dynamics, from computer-aided design to consumer spending

applications (e.g., operating system components, drivers, networking software, telecommunications habits, and from genetic analysis to meteorology.

processors) process largely indeterminate data.

Embedded software.
Application software. Resides within a product or system and is used to implement and control features and functions for the end

Stand-alone programs that solve a specific business need. Applications in this area process business or user and for the system itself. Embedded software can perform limited and esoteric functions (e.g., keypad

technical data in a way that facilitates business operations or management/technical decision making. control for a micro- wave oven) or provide significant function and control capability (e.g., digital functions

in an automobile such as fuel control, dashboard displays, and braking systems).

3
 02-09-2025

Software Application Domains / Types of Software Software Application Domains / Types of Software
Product-line software. Legacy Software
Composed of reusable components and designed to provide specific capabilities for use by many different Legacy software systems – were developed decades ago and have been continually modified to meet changes

customers. It may focus on a limited and esoteric marketplace (e.g., inventory control products) or attempt to in business requirements and computing platforms. The proliferation of such systems is causing headaches

address the mass consumer market. for large organizations who find them costly to maintain and risky to evolve.

Web/mobile applications. However, as time passes, legacy systems often evolve for one or more of the following reasons:

This network-centric software category spans a wide array of applications and encompasses browser-based  The software must be adapted to meet the needs of new computing environments or technology.

apps, cloud computing, service-based computing, and software that resides on mobile devices.  The software must be enhanced to implement new business requirements.

Artificial intelligence software.  The software must be extended to make it work with other more modern systems or databases.

 The software must be re-architected to make it viable within an evolving computing environment.
Makes use of heuristics to solve complex problems that are not amenable to regular computation or

straightforward analysis.

The Process Framework The Process Framework

A process framework establishes the foundation for a Communication.

complete software engineering process by identifying a
Before any technical work can commence, it is critically
small number of framework activities that are applicable to
important to communicate and collaborate with the
all software projects, regardless of their size or complexity.
customer (and other stakeholders). The intent is to
In addition, the process framework encompasses a set of
understand stakeholders’ objectives for the project and to
umbrella activities that are applicable across the entire
gather requirements that help define software features and
software process.
functions.
A generic process framework for software engineering

encompasses five activities:

The Process Framework The Process Framework

Planning. Modeling.
Any complicated journey can be simplified if a map exists. Whether you are a landscaper, a bridge builder, an

A software project is a complicated journey, and the aeronautical engineer, a carpenter, or an architect, you work

planning activity creates a “map” that helps guide the team with models every day.

as it makes the journey. The map—called a software project A software engineer does the same thing by creating models
plan— defines the software engineering work by describing to better understand software requirements and the design
the technical tasks to be con- ducted, the risks that are that will achieve those requirements.
likely, the resources that will be required, the work products

to be produced, and a work schedule.

4
 02-09-2025

The Process Framework The Process Framework

Construction. Deployment.
What you design must be built. This activity combines code The software (as a complete entity or as a partially

generation (either manual or automated) and the testing that completed increment) is delivered to the customer who

is required to uncover errors in the code. evaluates the delivered product and provides feedback

based on the evaluation.

Umbrella Activities Umbrella Activities

Software project tracking and control.

 Allows the software team to assess progress against the project plan and take any necessary action to maintain the
Umbrella activities are schedule.
applied throughout a
Risk management.
software project and help a
 Assesses risks that may affect the outcome of the project or the quality of the product.
software team manage and
Software quality assurance.
control progress, quality,
 Defines and conducts the activities required to ensure software quality.
change, and risk.
Technical reviews.

 Assess software engineering work products in an effort to uncover and remove errors before they are propagated to the
next activity.

Umbrella Activities Software Engineering Practice –

Measurement.

 Defines and collects process, project, and product measures that assist the team in delivering software that meets
stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities.

Software configuration management.

 Manages the effects of change throughout the software process.

Reusability management.

 Defines criteria for work product reuse (including software components) and establishes mechanisms to achieve

reusable components.

Work product preparation and production.

 Encompasses the activities required to create work products such as models, documents, logs, forms, and lists.

5
 02-09-2025

Software Engineering Practice – Software Engineering Practice –

2. Plan the Solution.

1. Understand the Problem
 Have you seen similar problems before? Are there patterns that are
 Who has a stake in the solution to the problem? That is, who are the
recognizable in a potential solution? Is there existing software that
stake- holders?
implements the data, functions, and features that are required?
 What are the unknowns? What data, functions, and features are required
 Has a similar problem been solved? If so, are elements of the solution
to properly solve the problem?
reusable?
 Can the problem be compartmentalized? Is it possible to represent
 Can sub problems be defined? If so, are solutions readily apparent for
smaller problems that may be easier to understand?
the sub problems?
 Can the problem be represented graphically? Can an analysis model be
 Can you represent a solution in a manner that leads to effective
created?
implementation? Can a design model be created?

Software Engineering Practice – Software Engineering Practice –

4. Examine the Result.

3. Carry Out the Plan.
 Is it possible to test each component part of the
 Does the solution conform to the plan? Is
solution? Has a reasonable testing strategy
source code traceable to the design model?
been implemented?
 Is each component part of the solution
 Does the solution produce results that conform
provably correct? Has the design and code
to the data, functions, and features that are
been reviewed, or better, have correctness
required? Has the software been validated
proofs been applied to the algorithm?
against all stake- holder requirements?

A software process framework

Software Engineering Core Principles :
A generic process framework for software engineering defines five framework
 1st Principle: The Reason It All Exists activities—communication, planning, modeling, construction, and deployment.

 2nd Principle: KISS (Keep It Simple, In addition, a set of umbrella activities—project tracking and control, risk
management, quality assurance, configuration management, technical reviews,
Stupid!)
and others—are applied throughout the process.
 3rd Principle: Maintain the Vision
Each framework activity is populated by a set of software engineering actions.
 4th Principle: What You Produce, Others
Each software engineering action is defined by a task set that identifies the work
Will Consume tasks that are to be completed, the work products that will be produced, the

 5th Principle: Be Open to the Future quality assurance points that will be required, and the milestones that will be
used to indicate progress.
 6th Principle: Plan Ahead for Reuse

 7th Principle: Think!

6
 02-09-2025

Process flow – Process flow –

Process flow – describes how the framework activities and the actions and tasks that occur within each framework activity
are organized with respect to sequence and time.

A linear process flow executes each of the five framework activities in sequence, beginning with An iterative process flow repeats one or more of the activities before proceeding to the next.
communication and culminating with deployment.

Process flow – Process flow –

An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five A parallel process flow executes one or more activities in parallel with other activities (e.g., modeling for
activities leads to a more complete version of the software. one aspect of the software might be executed in parallel with construction of another aspect of the software).

The Process Framework The Process Framework

Communication Principles. Planning Principles.
1. Listen. 1. Understand the scope of the project.

2. Prepare before you communicate. 2. Involve stakeholders in the planning activity.

3. Someone should facilitate the activity. 3. Recognize that planning is iterative.

4. Face-to-face communication is best. 4. Estimate based on what you know.

5. Take notes and document decisions. 5. Consider risk as you define the plan.

6. Strive for collaboration. 6. Be realistic.

7. Stay focused; modularize your discussion. 7. Adjust granularity as you define the plan.

8. If something is unclear, draw a picture. 8. Define how you intend to ensure quality.

9. (a) Once you agree to something, move on. (b) If you can’t agree to something, move on. (c) If a feature or 9. Describe how you intend to accommodate change.
function is unclear and cannot be clarified right now, move on. 10. Track the plan frequently, and make adjustments as required.
10. Negotiation is not a contest or a game.

7
 02-09-2025

The Process Framework The Process Framework

Modelling Principles. Construction Principles.
1. The primary goal of the software team is to build software, not create models. The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for

2. Travel light—don’t create more models than you need. delivery to the customer or end user.

3. Strive to produce the simplest model that will describe the problem or the software.

4. Build models in a way that makes them amenable to change. In modern software engineering work, coding may be: (1) the direct creation of programming language source code, (2)
the automatic generation of source code using an intermediate design like representation of the component to be built, or
5. Be able to state an explicit purpose for each model that is created.
(3) the automatic generation of executable code using a fourth-generation programming language.
6. Adapt the models you develop to the system at hand.

7. Try to build useful models, but forget about building perfect models..
The initial focus of testing is at the component level, often called unit testing. Other levels of testing include (1)
8. Don’t become dogmatic about the syntax of the model. If it communicates content successfully, representation is
integration testing (conducted as the system is constructed), (2) validation testing that assesses whether requirements
secondary..
have been met for the complete system (or software increment), and (3) acceptance testing that is con- ducted by the
9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have reason to be
customer in an effort to exercise all required features and functions.
concerned.

10. Get feedback as soon as you can.

The Process Framework The Process Framework

Construction Principles - Coding Principles. Construction Principles - Coding Principles.

Preparation Principles: Before you write one line of code, Coding Principles: As you begin writing code, be sure you:
be sure you: 6. Constrain your algorithms by following structured
1. Understand the problem you’re trying to solve. programming practice.

2. Understand basic design principles and concepts. 7. Consider the use of pair programming.

3. Pick a programming language that meets the needs of 8. Select data structures that will meet the needs of the
the software to be built and the environment in which design.
it will operate. 9. Understand the software architecture and create
4. Select a programming environment that provides interfaces that are consistent with it.
tools that will make your work easier.

5. Create a set of unit tests that will be applied once the

component you code is completed.

The Process Framework The Process Framework

Construction Principles - Coding Principles. Construction Principles - Coding Principles.
Validation Principles: After you’ve completed your first Testing -
coding pass, be sure you:  Testing is a process of executing a program
10. Conduct a code walkthrough when appropriate. with the intent of finding an error.
11. Perform unit tests and correct errors you’ve
 A good test case is one that has a high
uncovered.
probability of finding an as-yet- undiscovered
12. Refactor the code to improve its quality.
error.

 A successful test is one that uncovers an as-yet-

undiscovered error.

8
 02-09-2025

The Process Framework The Process Framework

Construction Principles - Coding Principles. Deployment Principles.
Testing Principles. The deployment activity encompasses three actions: delivery, support, and feedback.

1. All tests should be traceable to customer requirements. 1. Customer expectations for the software must be managed.

2. Tests should be planned long before testing begins. 2. A complete delivery package should be assembled and tested.

3. The Pareto principle applies to software testing. 3. A support regimen must be established before the software is delivered.

4. Testing should begin “in the small” and progress toward testing “in the large.” 4. Appropriate instructional materials must be provided to end users.

5. Exhaustive testing is not possible. 5. Buggy software should be fixed first, delivered later.

6. Apply to each module in the system a testing effort commensurate with its expected fault density.

7. Static testing techniques can yield high results.

8. Track defects and look for patterns in defects uncovered by testing.

9. Include test cases that demonstrate software is behaving correctly.

PRESCRIPTIVE PROCESS MODELS

 Prescriptive process models define a predefined set of process elements and a predictable process work flow.
PRESCRIPTIVE PROCESS  Prescriptive process models strive for structure and order in software development. Activities and tasks occur

MODELS sequentially with defined guidelines for progress.

 “Prescriptive” because they prescribe a set of process elements— framework activities, software engineering
actions, tasks, work products, quality assurance, and change control mechanisms for each project.
 Each process model also prescribes a process flow (also called a work flow)—that is, the manner in which

The Waterfall Model the process elements are interrelated to one another.
 All software process models can accommodate the generic framework activities, but each applies a different
emphasis to these activities and defines a process flow that invokes each framework activity (as well as
software engineering actions and tasks) in a different manner.

The Waterfall Model The Waterfall Model

 There are times when the requirements for a problem are well understood—when work flows from
communication through deployment in a reasonably linear fashion.
 This situation is sometimes encountered when well-defined adaptations or enhancements to an existing
system must be made (e.g., an adaptation to accounting software because it needs to accommodate changes
to mandated government regulations).
 It may also occur in a limited number of new development efforts, but only when requirements are well
defined and reasonably stable.
 The waterfall model, sometimes called the linear sequential model (classic life cycle), suggests a systematic,
sequential approach to software development that begins with customer specification of requirements and
progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the
completed software.

9
 02-09-2025

1. Requirement Analysis
 Understand and identify the exact requirements which end users are expecting and document
them properly
 Note down all the techniques, functions, features, and characteristics of this software
 Brainstorm, study, and analyze the demanded requirements instructed by a client
 Generate a software requirement specification (SRS), a detailed document of the software’s
purpose and task.

2. Design
 Transform the collected requirements into a structuralized form, which helps the developer in
coding the programming language.
 Give a structured design to the whole software based on the detailed requirements collected in the
first phase. Also, specify the software, hardware, architecture, user interface, and system
requirements.

3. Implementation 5. Deployment
 This phase is also called the coding phase  Deploy the final product in the customer environment
 Implement coding based on software design specification  Do a sanity check of the customer environment to see it’s functioning properly
 This phase will run unit testing to ensure each component works perfectly.

4. Testing 6. Maintenance
 All the units will be tested separately and will integrate into one system.  Main task is to ensure software performance in the customer environment
 The developer will run both functional and non-functional testing to ensure whether or not the  Provide maintenance, operational and installation support of the software
system meets the requirements.  Note and fix issues identify by the customer
 Run a comprehensive system testing to determine the quality of the product.  Keep in constant update with latest update
 Use application lifecycle management and traceability matrix to track the testing progress.

Advantages Of Waterfall Model – Disadvantages Of Waterfall Model –

 Simple, easy to understand, and implement

 Not recommendable for large or complex projects
 Require a minimal amount of resources for software development.
 Have to face difficulties in the software development process if the client requirements aren’t clear or
 Each phase has its individual testing process to ensure everything works properly before moving to the next
variable.
phase.
 It is challenging to go back to the previous for any change.
 Best suitable for smaller projects and well-documented for large projects
 There is no prototype for demonstration; it might take longer to deliver the final product. Any type of
 Every phase must be completely done before moving to the next phase, so it’s better not to be careless or hurry to
working on software until late during the life cycle
complete the project.
 The whole software project will suffer because of any small change or error in any completed phase.
 Task assignment is easy since every phase has different functions and responsibilities and performs differently.
 Every phase holds multiple documents, and the development process takes time for developers and
 It is easy to forecast the cost and deadline of a software project.
testers.
 Unit testing can be run in the middle of the software development process to ensure each phase is working
 Unit testers perform integration processes at the last phase of SDLC; hence, it becomes difficult to fix or
properly.
identify issues of the previous phases.
 An elaborate and well-documented will be created in every phase, making it easy to find and fix various issues.
 The maintenance phase (last phase) has the opportunity to fix the issues/bugs faced by the end-users.

10
 02-09-2025

The Waterfall Model

The waterfall model is the oldest paradigm for software engineering. However, over the past five decades, Incremental Model
criticism of this process model has caused even ardent supporters to question its efficacy. Among the
problems that are sometimes encountered when the waterfall model is applied are:
1. Real projects rarely follow the sequential work flow that the model proposes.
2. It is often difficult for the customer to state all requirements explicitly at the beginning of most
projects.
3. The customer must have patience because a working version of the program(s) will not be available
until late in the project time span.
4. Major blunders may not be detected until the working program is reviewed.

Today, software work is fast paced and subject to a never-ending stream of changes (to features, functions,
and information content). The waterfall model is often inappropriate for such work.

Incremental Process Models Incremental Process Models

 There are many situations in which initial software requirements are reasonably well defined, but the overall scope of the
 When an incremental model is used, the first increment is often a core product.
development effort precludes a purely linear process.
 That is, basic requirements are addressed but many supplementary features (some known, others unknown)
 In addition, there may be a compelling need to provide a limited set of software functionality to users quickly and then
refine and expand on that functionality in later software releases. In such cases, you can choose a process model that is remain undelivered.

designed to produce the software in increments.  The core product is used by the customer (or undergoes detailed evaluation).
 The incremental model combines elements of linear and parallel process flows, the incremental model applies linear  As a result of use and/or evaluation, a plan is developed for the next increment.
sequences in a staggered fashion as calendar time progresses.  The plan addresses the modification of the core product to better meet the needs of the customer and the
 Each linear sequence produces deliverable “increments” of the software in a manner that is similar to the increments delivery of additional features and functionality.
produced by an evolutionary process flow.
 This process is repeated following the delivery of each increment, until the complete product is produced.
 For example, word-processing software developed using the incremental paradigm might deliver basic file
 The incremental process model focuses on the delivery of an operational product with each increment.
management, editing, and document production functions in the first increment; more sophisticated editing and
document production capabilities in the second increment; spelling and grammar checking in the third increment; and
advanced page layout capability in the fourth increment. It should be noted that the process flow for any increment can
incorporate the prototyping paradigm.

The Incremental Model Incremental Process Models

 Incremental development is particularly useful when staffing is unavailable for a complete implementation by the
business deadline that has been established for the project.
 Early increments can be implemented with fewer people. If the core product is well received, then additional staff (if
required) can be added to implement the next increment. In addition, increments can be planned to manage technical
risks.
 For example, a major system might require the availability of new hardware that is under development and
whose delivery date is uncertain. It might be possible to plan early increments in a way that avoids the use of this
hardware, thereby enabling partial functionality to be delivered to end users without inordinate delay.
Note –
 The incremental model delivers a series of releases, called increments, that provide progressively more functionality
for the customer as each increment is delivered.
 Your customer demands delivery by a date that is impossible to meet. Suggest delivering one or more increments by
that date and the rest of the software (additional increments) later.

11
 02-09-2025

Advantages of Incremental Process Model Disadvantages of Incremental Process Model

The Incremental Model of software development builds a system in small, manageable sections (increments), making it a
good choice for many projects. Incomplete Requirement Gathering Can Cause Design
Effective Risk Management Issues
 Risks can be identified and handled early due to the staged Requires a Skilled Team and Proper  If all requirements are not identified early, the
Faster Software Delivery approach. Planning system architecture may not support future needs.
 Initial working versions of the software can be  Each increment allows for testing and validation, reducing  Successful implementation demands an  Inadequate upfront design can lead to rework and
delivered quickly. the impact of unforeseen issues. experienced team. architectural mismatches.
 Early delivery increases customer satisfaction Flexible Criteria and Scope  Poor planning or coordination can lead
and feedback opportunities.  Requirements can be adjusted without a major cost increase. Lack of Smooth Flow Between Increments
to confusion between increments.  Each iteration may function independently, which
Clear Understanding for Clients  Better scope management helps keep the project aligned
with business goals.
Cost Can Increase Over Time can create inconsistencies.
 Clients get to see parts of the system at each
stage. Cost-Effective  Due to repeated testing, redesign, and  There might be integration challenges when
 This visibility ensures that the final product  Compared to models like the Waterfall, the incremental integration in every cycle, the overall combining all the increments into a unified product.
meets their expectations. model is generally more cost-efficient. project cost may rise. High Effort to Fix Repeated Issues
Easy to Implement Changes  Budget is spread across stages, making it easier to manage  Continuous iteration involves added  A defect in one increment may exist in others.
 Requirements can evolve, and changes can be finances. overhead  Fixing the same issue across multiple units can be
incorporated in subsequent increments. Simpler Error Identification time-consuming and resource-intensive.
 It supports flexibility without heavily  Since development is done in parts, it's easier to pinpoint
disrupting earlier stages. and fix errors within a specific increment.
 Testing each module separately enhances quality and
reliability.

When is an Incremental Model Used?

 Requirements are clearly specified, understood and are known up-front. Certain
requirements, however, require time.
 There is a requirement to release the product early or get it to the market early.
 Engineering team lacks the required skill set, or the resources are unavailable.
 Product-based companies develop their own products.
 New technologies are used.
 High risk goals or features are involved.
 Projects have long development schedules.

RAD Model –

• RAD Model stands for rapid application development model. The methodology of RAD model is
similar to that of incremental or waterfall model. It is used for small projects.
• The main objective of RAD model is to reuse code, components, tools, processes in project
development.

• Rapid Application Development (RAD) is a software development method that prioritizes iterative
prototyping and user collaboration. It uses short cycles to create working prototypes and refine them
based on iterative feedback. RAD's flexibility adapts to changing requirements, encourages early user
engagement, and reduces targeting errors. While RAD is effective for rapid delivery, it can be difficult • If the project is large then it is divided into many small projects and these small projects are planned one by
for larger projects or due to limited user availability. one and completed. In this way, by completing small projects, the large project gets ready quickly.
• In RAD model, the project is completed within the given time and all the requirements are collected before
starting the project. It is very fast and there are very less errors in it.

12
 02-09-2025

Different Phases of RAD Model Different Phases of RAD Model

1. Business Modeling 2. Data Modeling 3. Process Modeling 4. Application Generation 5. Testing and Turnover
The first phase involves In this phase, developers During the process modeling In this stage, the software’s actual The final phase involves rigorous
gathering information about the analyze the data requirements phase, developers design the coding and development occur. application testing to identify and
business processes and and design the data structures software processes to manipulate Developers use various tools, fix any issues or bugs. This
workflows while identifying necessary for the application. and manage data. This involves languages, and frameworks to build includes unit testing, integration
areas where the application is This includes defining data creating flowcharts, process applications based on the data and testing, and user acceptance
expected to provide solutions or objects, their relationships, and diagrams, and pseudocode process models created in the previous testing (UAT). Once the
improvements. This step is data management rules. The representing the various phases. Rapid construction techniques, application has passed all tests and
crucial for understanding the data modeling phase is algorithms and functions required such as code reuse and integrated received user approval, it is
business context and aligning the essential for ensuring that the to achieve the desired functionality. development environments (IDEs), are deployed to the production
software development with the application can efficiently Process modeling ensures that the employed to accelerate the environment, and user training is
organization’s goals and manage and process the application’s logic is well- development process. provided as needed.
objectives. required data. structured and efficient.

Advantages of RAD Model Disadvantages of RAD Model

When to use RAD Methodology?
Flexible and adaptable to changes It can’t be used for smaller projects

• When a system needs to be produced in a short span of time (2-3 months) It is useful when you have to reduce the overall project risk Not all application is compatible with RAD

It is adaptable and flexible to changes When technical risk is high, it is not suitable
• When the requirements are known
It is easier to transfer deliverables as scripts, high-level If developers are not committed to delivering software on
• When the user will be involved all through the life cycle abstractions and intermediate codes are used time, RAD projects can fail

Due to code generators and code reuse, there is a reduction of Reduced features due to time boxing, where features are
• When technical risk is less
manual coding pushed to a later version to finish a release in short period
• When there is a necessity to create a system that can be modularized in 2-3 months of time Reduced scalability occurs because a RAD developed
Due to prototyping in nature, there is a possibility of lesser
application begins as a prototype and evolves into a finished
• When a budget is high enough to afford designers for modeling along with the cost of defects
application

automated tools for code generation Progress and problems accustomed are hard to track as such
Each phase in RAD delivers highest priority functionality to
there is no documentation to demonstrate what has been
client
done

With less people, productivity can be increased in short time Requires highly skilled designers or developers

Examples of scenarios where the RAD model in

software engineering could be used: Health care information system: Prototyping Process Model
In the field of health care, a hospital may need to
Mobile App Development: develop a patient information management system. RAD helps

Consider a startup developing a new social quickly create a prototype that includes essential features,

networking app. Because of rapidly changing user allowing nursing staff to interact with the system and provide

expectations and the need for a compelling user interface, feedback.

RAD can be used to quickly prototype key application Online Learning Platform:
features and gather user feedback before finalizing the The university wants to start an online learning
design. platform. With RAD, the development team can quickly build
E-Commerce Platform: and improve the platform based on the needs of teachers and

A retail company decides to open an online students, and add new features as the platform gains traction.

store with unique features. RAD can be used to develop Event Management System:
an initial version of the platform that allows customers to Imagine an event management company that wants to
browse and shop. The platform could then be create a system to manage event registration, ticket sales, and
continuously improved based on user interaction and attendees. RAD can be used to rapidly prototype basic features
feedback. and iteratively add features as the system evolves.

13
 02-09-2025

Prototyping. The prototyping paradigm The prototyping paradigm begins with communication. You
meet with other stakeholders to define the overall objectives

Often, a customer defines a set of general objectives for software, but does not identify detailed requirements for for the software, identify whatever requirements are known,

functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability and outline areas where further definition is mandatory. A

of an operating system, or the form that human-machine interaction should prototyping iteration is planned quickly, and modeling (in the

take. In these, and many other situations, a prototyping paradigm may offer the best approach. form of a “quick design”) occurs. A quick design focuses on a

Although prototyping can be used as a stand-alone process model, it is more commonly used as a technique representation of those aspects of the software that will be

that can be implemented within the context of any one of the process models noted in this chapter. Regardless of the visible to end users (e.g., human interface layout or output

manner in which it is applied, the prototyping paradigm assists you and other stakeholders to better understand what display formats). The quick design leads to the construction of

is to be built when requirements are fuzzy. a prototype. The prototype is deployed and evaluated by
stakeholders, who provide feedback that is used to further
refine requirements. Iteration occurs as the prototype is

Note - When your customer has a legitimate need, but is clueless about the details, develop a prototype as a first step. tuned to satisfy the needs of various stakeholders, while at
the same time enabling you to better understand what needs
to be done.

Types of Prototyping Model: The prototyping paradigm

1. Rapid throwaway prototype 3. Incremental prototype

In an incremental prototype, several individual parts make For example, a fitness app developed using incremental
Rapid throwaway prototyping allows developers to use
the final product. The design for each section happens
the preliminary requirement and explore ideas to prototypes might deliver the basic user interface screens
separately before merging to create the final product. This
envision the final prototype. Constant customer
method helps to reduce the time between user feedback needed to sync a mobile phone with the fitness device and
feedback helps eliminate any design faults. The
and the implementation of the changes by the development
developed rapid throwaway prototype helps improve display the current data; the ability to set goals and store the
team.
the quality of the prototype but often gets discarded.
fitness device data on the cloud might be included in the
second prototype, creating and modifying the user interface
2. Evolutionary prototype 4. Extreme prototype
screens based on customers feedback; and a third prototype
The evolutionary prototype is where the prototype Building an extreme prototype helps in web development.
might include social media integration to allow users to set
requires an incremental refinement after every customer There are three phases to it. It begins with creating a
feedback. It helps save time, as every iteration is a prototype for all the existing pages in the hypertext fitness goals and share progress toward them with a set of
modified version of its predecessor. An evolutionary markup language(HTML) format. The prototype service
friends.
prototype helps when adopting a new technology that layers help stimulate and test data processing. After
requires trials. It is also beneficial when the requirements approval, the developers integrate the services into the
are not clear or when the functionality requires constant final prototype.
checking.

Prototyping. Advantages of Prototyping Disadvantages of Prototyping

There is insufficient requirement analysis as a complete
Due to user involvement, the product risk to fail decreases.
prototype is in use.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is
to be built, you can make use of existing program fragments or apply tools (e.g., report generators and window As there is a basic model, users will have a better Confusion can be there between the prototype and the final
understanding of the final system. product.
managers) that enable working programs to be generated quickly.
But what do you do with the prototype when it has served the purpose described earlier? Brooks [Bro95] provides one Less time and cost as the errors are known earlier, and This methodology may increase the system’s complexity as
corrections are made. the scope of the system expands beyond the actual plans.
answer:
In most projects, the first system built is barely usable. It may be too slow, too big, awkward in use or all Developers can use the prototype as the final product,
User feedback helps in developing a better solution.
which can lead to technical issues.
three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these
problems are solved. Functionalities can be verified, and the missing ones can be The time invested in a prototype can be wasted if it is not
added. implemented efficiently.
The prototype can serve as “the first system.” The one that Brooks recommends you throw away. But this
may be an idealized view. Although some prototypes are built as “throwaways,” others are evolutionary in the sense Complex functions can be identified and made more The improvement at every stage needs to be done quickly,
straightforward. or the prototype cannot be moved to the next step.
that the prototype slowly evolves into the actual system.
A prototype can be used as a resource to educate future
users.
It gives scope for innovations and designs.

14
 02-09-2025

Spiral Model

Spiral Model  The spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model. It provides the potential for rapid development of
increasingly more complete versions of the software.
 Using the spiral model, software is developed in a series of evolutionary releases.
 During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete
versions of the engineered system are produced.
 The first circuit around the spiral (beginning at the inside streamline nearest the center) might result in the
development of a product specification; subsequent passes around the spiral might be used to develop a prototype and
then progressively more sophisticated versions of the software. Each pass through the planning region results in
adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after
delivery. In addition, the project manager adjusts the planned number of iterations required to complete the software.
 Other process models that end when software is delivered, the spiral model can be adapted to apply throughout the
life of the computer software. The spiral model is a realistic approach to the development of large-scale systems and
software.

 Spiral model is a combination

of iterative development
process model and sequential
linear development model i.e.
the waterfall model with a
very high emphasis on risk This model is
particularly useful for
analysis. software engineering
 It allows incremental releases projects that involve
multiple iterations,
of the product or incremental allowing for refinement
and evolution of
refinement through each
software products.
iteration around the spiral.
 It uses prototyping as a risk
reduction mechanism.

Planning Phase (Identify Objectives) Risk Analysis Phase

 In the planning phase, goals and requirements are defined.  Following the definition of objectives, the team conducts a
 This includes specifying the project scope, understanding thorough risk analysis to identify potential challenges that
user needs, and outlining potential risks associated with the may affect the project.
project.  Risks can stem from technical hurdles, resource limitations,
 This phase sets the foundation for risk assessment, which or evolving requirements.
continues throughout the lifecycle.  The development team formulates strategies to mitigate
 This initial phase focuses on establishing the goals for the identified risks, ensuring that adequate measures are in place
current iteration. to handle potential setbacks.
 Teams define the software requirements, expected  This crucial phase helps developers create strategies to
functionalities, and constraints, ensuring that stakeholder manage uncertainties, ensuring a more robust and resilient
feedback is incorporated to align with user needs. project.
 Engagement with stakeholders is crucial, as it sets the  Risks can be assessed using quantitative and qualitative
foundation for the project and clarifies what success looks techniques, allowing teams to prioritize which risks need
like for the ensuing development cycle. addressing.

15
 02-09-2025

Product Development Phase

Evaluation Phase (Plan Next Iteration)
 Once risks have been analyzed and strategies in place, the
 Once the evaluation of the current iteration is complete, the
development phase begins.
team prepares for the subsequent spiral.
 In this phase, the project team develops and tests the
 The final phase involves reviewing the product against initial
software according to the specified objectives.
goals and capturing customer feedback.
 The actual coding, integration, and testing take place here.
 They review lessons learned, re-assess objectives, identify
 This stage employs a mini-Waterfall approach, meaning that
new risks, and make necessary adjustments to project scope
design, coding, and testing occur in a sequential manner.
and timelines.
 Afterward, the results are evaluated against the objectives to
 This ongoing cycle continues until the software development
determine if the project is on track and to uncover any
project reaches its conclusion.
immediate issues.
 This phase ensures that the software meets the established
 Feedback from customer involvement and initial prototypes
requirements and allows for necessary changes before
aids in refining the software product through iterative cycles
moving forward.
of development.

Advantages of the Spiral Model Disadvantages of the Spiral Model

 Risk Management: Continuous risk assessment throughout the development process  Cost: The continuous risk analysis and iterative development can make the Spiral model
allows teams to address potential challenges before they escalate into critical issues. more expensive than other SDLC methodologies.
 Flexibility: The model's inherent iterative nature supports modifications and
enhancements at every stage of development, facilitating an adaptive approach.  Time-Consuming: The model's cyclic nature can prolong the development process.
 Customer Involvement: Regular feedback loops with stakeholders ensure that the final
software product meets client expectations and needs effectively.  Complexity: The Spiral model can be challenging to manage, especially for smaller
 Improved Quality: The iterative cycle promotes continuous refinement, leading to a teams or projects with well-defined requirements.
higher-quality output through regular inspections and adaptations.
 Early Error Detection: The model emphasizes early testing, which enhances the ability to  Lack of Documentation: The focus on iterative development may lead to inadequate
identify and resolve problems proactively. documentation.

When to Use the Spiral Model The spiral model is best fit
for high risk project Agile Software Development
The Spiral Model is particularly effective in scenarios such as: because it detects possible

 Large projects with extensive and detailed problems early but at the Agile Software Development is a Software Development Methodology that values flexibility,
cost of time-consuming and collaboration, and customer satisfaction. It is based on the Agile Manifesto, a set of principles for software
specifications. expensive. This model
development that prioritize individuals and interactions, working software, customer collaboration, and
 Situations requiring frequent releases and validation applies to complex projects
responding to change.
that have continually
from users.
changing requirements, it
 Projects that deal with significant risks and uncertain may be too much for some
Agile Software Development is an iterative and incremental approach to Software Development that
requirements. smaller projects due to its emphasizes the importance of delivering a working product quickly and frequently. It involves close
high demands on collaboration between the development team and the customer to ensure that the product meets their needs
 When flexibility is needed throughout the development
documentation and and expectations.
process. planning.

16
 02-09-2025

Why is Agile Used?

Agile is used because it helps teams deliver value quickly and continuously. By prioritizing the delivery of
difficult results early in the project, customers benefit from seeing and using the product sooner, allowing for
quick feedback and adjustments. Agile also encourages teams to focus on what truly matters, concentrating
on tasks that add value and avoiding unnecessary work.

Agile Software Development is widely used by software development teams and is considered to be a
flexible and adaptable approach to software development that is well-suited to changing requirements and
the fast pace of software development. Agile is a time-bound, iterative approach to software delivery that
builds software incrementally from the start of the project, instead of trying to deliver all at once.

Advantages Agile Software Development Disadvantages Agile Software Development

 Increased collaboration and communication: This leads to improved understanding, better alignment, and  Lack of predictability: Agile Development relies heavily on customer feedback and continuous iteration, which can
increased buy-in from everyone involved. make it difficult to predict project outcomes, timelines, and budgets.
 Flexibility and adaptability: Agile methodologies are designed to be flexible and adaptable, making it  Limited scope control: Agile Development is designed to be flexible and adaptable, which means that scope changes
can be easily accommodated.
easier to respond to changes in requirements, priorities, or market conditions. This allows teams to
 Lack of emphasis on testing: Agile Development places a greater emphasis on delivering working code quickly,
quickly adjust their approach and stay focused on delivering value. which can lead to a lack of focus on testing and quality assurance. This can result in bugs and other issues that may
 Improved quality and reliability: Agile methodologies place a strong emphasis on testing, quality go undetected until later stages of the project.
assurance, and continuous improvement. This helps to ensure that software is delivered with high quality  Risk of team burnout: Agile Development can be intense and fast-paced, with frequent sprints and deadlines. This can
and reliability, reducing the risk of defects or issues that can impact the user experience. put a lot of pressure on team members and lead to burnout, especially if the team is not given adequate time for rest
 Enhanced customer satisfaction: Agile methodologies prioritize customer satisfaction and focus on and recovery.
delivering value to the customer. By involving customers throughout the development process, teams can  Lack of structure and governance: Agile Development is often less formal and structured than other development
ensure that the software meets their needs and expectations. methodologies, which can lead to a lack of governance and oversight. This can result in inconsistent processes and
 Increased team morale and motivation: Agile methodologies promote a collaborative, supportive, and practices, which can impact project quality and outcomes.
 In the case of large software projects, it is difficult to assess the effort required at the initial stages of the software
positive work environment. This can lead to increased team morale, motivation, and engagement, which
development life cycle.
can in turn lead to better productivity, higher quality work, and improved outcomes.  Agile Development is more code-focused and produces less documentation.
 Deployment of software is quicker and thus helps in increasing the trust of the customer.  Agile development is heavily dependent on the inputs of the customer. If the customer has ambiguity in his vision of
 Can better adapt to rapidly changing requirements and respond faster. the outcome, it is highly likely that the project to get off track.
 Helps in getting immediate feedback which can be used to improve the software in the next increment.  Face-to-face communication is harder in large-scale organizations.
 People - Not Process. People and interactions are given a higher priority than processes and tools.  Only senior programmers are capable of making the kind of decisions required during the development process.
 Continuous attention to technical excellence and good design. Hence, it's a difficult situation for new programmers to adapt to the environment.

Advantages of Agile over traditional software development approaches

 Increased customer satisfaction: Agile development involves close collaboration with the customer, which helps to ensure
that the software meets their needs and expectations. Agile Methodologies
 Faster time-to-market: Agile development emphasizes the delivery of working software in short iterations, which helps to
There are different types of agile methodologies, each with its own approach to managing work, improving
get the software to market faster.
 Reduced risk: Agile development involves frequent testing and feedback, which helps to identify and resolve issues early collaboration, and delivering high-quality software.
in the development process.
 Improved team collaboration: Agile development emphasizes collaboration and communication between team members,
which helps to improve productivity and morale.  Scrum
 Adaptability to change: Agile Development is designed to be flexible and adaptable, which means that changes to the
 Extreme Programming (XP)
project scope, requirements, and timeline can be accommodated easily. This can help the team to respond quickly to
changing business needs and market demands.  Adaptive Software Development (ASD)
 Better quality software: Agile Development emphasizes continuous testing and feedback, which helps to identify and
resolve issues early in the development process. This can lead to higher-quality software that is more reliable and less  Dynamic Systems Development Method (DSDM)
prone to errors.
 Feature-Driven Development (FDD)
 Increased transparency: Agile Development involves frequent communication and collaboration between the team and the
customer, which helps to improve transparency and visibility into the project status and progress. This can help to build  Kanban
trust and confidence with the customer and other stakeholders.
 Higher productivity: Agile Development emphasizes teamwork and collaboration, which helps to improve productivity  Behaviour Driven Development (BDD)
and reduce waste. This can lead to faster delivery of working software with fewer defects and rework.
 Improved project control: Agile Development emphasizes continuous monitoring and measurement of project metrics,
which helps to improve project control and decision-making. This can help the team to stay on track and make data-driven
decisions throughout the development process.

17
 02-09-2025

Scrum – Scrum –
Scrum is a framework within the Agile methodology. It uses time-boxed cycles called sprints to deliver Scrum also relies on practices called Scrum artifacts to keep everything organized. There are three main
incremental improvements and emphasizes regular feedback through sprint reviews. Scrum artifacts:
 Product backlog: The complete, prioritized list of tasks, features, or requirements for the project, managed
Scrum roles and responsibilities
by the product owner
Scrum in Agile requires particular roles and responsibilities. Each Scrum team member has a specific role to
 Sprint backlog: A subset of the product backlog that includes tasks chosen for a specific sprint
play, ensuring that everyone knows what they’re responsible for. The Scrum process includes the
 Product increment: The result of work completed during a sprint
following roles:

 Product Owner: The product owner represents the customer’s best interest. This person has the ultimate
authority over the final product.
 Scrum master: This person is a facilitator, responsible for arranging the daily meetings, improving team
interactions, and maximizing productivity. The project manager often takes on the role of Scrum Master,
but they can delegate it to anyone on the team who is a Scrum expert and strong facilitator.

Scrum –

Other key activities in the Scrum process include:

 Sprint: A sprint is a set time frame for completing each set of tasks from the backlog. Every
sprint should be the same length. Two weeks is typical, but a sprint can be anywhere between
one to four weeks long, depending on the team and project needs.
 Daily standup: A Scrum project team is expected to meet every day to discuss progress. These
meetings are typically referred to as a daily Scrum or daily standup.
 Sprint review: This is a meeting where development teams show the work that was completed in
an individual sprint and focus on how they can deliver a better product.
 Sprint retrospective: In the retrospective meeting, the team reviews their overall system and
processes and how they can be improved for the next sprint.

Scrum – Scrum process flow –

 Scrum principles are consistent with the agile manifesto and are used to guide development activities
within a process that incorporates the following framework activities: requirements, analysis, design,
evolution, and delivery.
 Within each framework activity, work tasks occur within a process pattern called a sprint.
 The work conducted within a sprint (the number of sprints required for each framework activity will
vary depending on product complexity and size) is adapted to the problem at hand and is defined and
often modified in real time by the Scrum team.
 Scrum emphasizes the use of a set of software process patterns that have proven effective for projects
with tight timelines, changing requirements, and business criticality.

18
 02-09-2025

Scrum – Scrum –

Backlog – a prioritized list of project requirements or features that provide business value for the customer. Items can be
A team leader, called a Scrum master, leads the meeting and assesses the responses from each person. The
added to the backlog at any time (this is how changes are introduced). The product manager assesses the backlog and
updates priorities as required. Scrum meeting helps the team to uncover potential problems as early as possible. Also, these daily meetings

Sprints – consist of work units that are required to achieve a requirement defined in the backlog that must be fit into a lead to “knowledge socialization” and thereby promote a self-organizing team structure.
predefined time-box(typically 30 days). Demos – deliver the software increment to the customer so that functionality that has been implemented can
Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint allows team members to work be demonstrated and evaluated by the customer. It is important to note that the demo may not contain all
in a short-term, but stable environment. planned functionality, but rather those functions that can be delivered within the time-box that was
Scrum meetings – are short (typically 15 minutes) meetings held daily by the Scrum team. Three key questions are asked
established.
and answered by all team members:
 What did you do since the last team meeting?
 What obstacles are you encountering?
 What do you plan to accomplish by the next team meeting?

Advantages of Scrum Methodology Disadvantages of Scrum Methodology

 Adaptability - Scrum provides exceptional flexibility in handling customer-requested changes and allows for the seamless
transition of development steps at any stage of the project.  Commitment: Scrum requires a strong commitment from all team members to ensure the success of the project.
 Budget-friendly - The cost-effective nature of the Scrum methodology makes it a budget-friendly choice for organizations
looking to maximize their resources.  Implementation across large teams: Larger teams often face difficulties in implementing Scrum effectively due to the
 Client access: Scrum ensures clients have transparent access to processes, enabling them to trace progress and measure complexity of coordinating many members.
productivity effectively.  New or inexperienced teams: New or inexperienced teams may struggle to understand and apply Scrum principles, leading
 Daily meetings: The importance of daily meetings in Scrum lies in their ability to identify and resolve challenges promptly, to confusion and inefficiency.
keeping the project on track.  Pressure on team members: Scrum can increase pressure and time commitment for team members, potentially leading to
 Documentation: Scrum proves successful in businesses with challenging data-driven documentation requirements by burnout.
maintaining clear and concise records throughout the development process.
 Scope creep: Issues such as scope creep can arise from a lack of strict project deadlines and demanding managers pushing
 Efficiency: Scrum helps teams achieve better end results while saving time through its streamlined processes and iterative
for additional features (Forbes).
approach.
 Error resolution: Scrum’s framework allows for the removal or resolution of mistakes without disrupting the overall  Team autonomy: There is a risk that overreaching Scrum Masters can limit the autonomy of the team, undermining the
workflow, ensuring continuous progress. collaborative spirit of Scrum.
 Quality testing: The implementation of simple and effective testing procedures in Scrum leads to improved output and  Team dynamics: The effectiveness of Scrum can be significantly impacted by absent team members or high employee
higher product quality. turnover, disrupting the flow of the project.
 Team motivation: Scrum encourages a team-first approach, fostering motivation and collaboration among team members.  Unpredictability: Scrum can present challenges due to its lack of fixed time limits or cost valuations, making project
 Timely project completion: The structured nature of Scrum ensures that projects are completed on time, meeting deadlines planning and budgeting unpredictable.
and satisfying client expectations.
 Transparency: Scrum enhances visibility into all stages of project development, providing stakeholders with a clear
understanding of progress and potential issues.

Extreme Programming (XP) To achieve simplicity, XP restricts developers to design only for immediate needs, rather than
consider future needs. The intent is to create a simple design that can be easily implemented in
Extreme Programming (XP), the most widely used approach to agile software development. code).
More recently, a variant of XP, called Industrial XP (IXP) has been proposed.
IXP refines XP and targets the agile process specifically for use within large organizations.
Feedback is derived from three sources: the implemented software itself, the customer, and other
software team members.
XP Values
As new requirements are derived as part of iterative planning, the team provides the customer with
A set of five values that establish a foundation for all work performed as part of XP –
rapid feedback regarding cost and schedule impact.
 communication,
 simplicity,
 feedback, Certain XP practices demands courage. A better word might be discipline. For example, there is
 courage, and often significant pressure to design for future requirements. An agile XP team must have the
 respect. discipline (courage) to design for today, recognizing that future requirements may change
Each of these values is used as a driver for specific XP activities, actions, and tasks. dramatically, thereby demanding substantial rework of the design and implemented code.

To achieve effective communication between software engineers and other stakeholders (e.g., to The agile team inculcates respect among it members, between other stakeholders and team
establish required features and functions for the software), XP emphasizes close, yet informal members, and indirectly, for the software itself. As they achieve successful delivery of software
(verbal) collaboration between customers and developers, the establishment of effective metaphors increments, the team develops growing respect for the XP process.
for communicating important concepts, continuous feedback, and the avoidance of voluminous
documentation as a communication medium.

19
 02-09-2025

The XP Process
Lean Software Development
Extreme Programming uses an object-oriented approach as its preferred development paradigm with
Lean software development is more flexible than Scrum or XP, with fewer strict guidelines, rules, or methods.
a set of rules and practices that occur within the context of four framework activities:
Lean is based on a set of principles developed to ensure value and efficiency in production in the mid 20th
 planning,
century and has evolved into the software setting. Lean relies on five principles of Lean management:
 design,
1.Identify value
 coding, and
2.Value stream mapping
 testing.
3.Create continuous workflow
4.Create a pull system
5.Continuous improvement
Lean particularly emphasizes eliminating waste. In the context of software development, that includes cutting
out wasted time and unproductive tasks, efficiently using team resources, giving teams and individuals
decision-making authority, and prioritizing only the features of a system that deliver true value.

Kanban
Kanban focuses on helping teams work together more effectively to enable continuous delivery of quality
products. Kanban is unique, however, for offering a highly visual method for actively managing the creation of
Crystal
products. The Crystal Agile methodology focuses more on the interactions of the people involved in a project versus the

The Kanban Agile methodology relies on six fundamental practices: tools and techniques of development. A lightweight model, Crystal emphasizes interaction, people, community,

1.Visualize the workflow skills, communications, and talents.

2.Limit work in progress Crystal categorizes projects based on three criteria:

3.Manage flow 1.Team size

4.Make process policies explicit 2.System criticality

5.Implement feedback loops 3.Project priorities

6.Improve collaboratively The approach is similar to other Agile methodologies in its attention to early and often delivery of software,

Kanban achieves these practices through the use of a Kanban board. The Kanban board facilitates the visual high involvement of users, and removal of red tape. Crystal’s assertion that every project is unique, however,

approach to Agile using columns to represent work that is To Do, Doing, and Done. This Agile methodology has led to its reputation as one of the most flexible Agile methodologies.

improves collaboration and efficiency and helps define the best possible team workflow.

Dynamic Systems Development Method (DSDM)

Feature-Driven Development (FDD)
DSDM originated in the 1990s as a way to provide a common industry framework for rapid software delivery.
Feature-Driven Development, or FDD, provides a framework for product development that starts with an overall model and
gets progressively more granular. DSDM revolves around:

Like other Agile methodologies, FDD aims to deliver working software quickly in a repeatable way.  Business needs and value
It uses the concept of “just enough design initially” (JEDI) to do so, leveraging two-week increments to run “plan by  Active user involvement
feature, design by feature, build by feature” iterations.  Empowered teams
 Frequent delivery
Organizations that practice Agile like Feature-Driven Development for its feature-centric approach and its scalability.  Integrated testing
 Stakeholder collaboration
The DSDM framework is particularly useful for prioritizing requirements. It also mandates that rework is to be
expected, so any development changes must be reversible. DSDM relies on sprints, similar to other Agile
methodologies, and is often used in conjunction with approaches like Scrum and XP.

20
 02-09-2025

Adaptive Project Framework (APF) Selection criteria for software process model –
Not every project has clearly defined goals from the start. The Adaptive Project Framework (APF) leans into this Selection Process parameters plays an important role in software development as it helps to choose the
uncertainty with an approach that embraces the change that inevitably occurs as a project moves forward. best suitable software life cycle model. Following are the parameters which should be used to select a SDLC
Instead of trying to define everything upfront, teams using APF deliver small parts of the project in short cycles, (Software Development Life Cycle).
get stakeholder feedback, and adjust the plan for the next cycle.

1. Requirements characteristics 1. Project requirements.

Behavioral Driven Development (BDD) 2. Development team 2. Project size.
An Agile software development process that is derived from the TDD (Test Driven Development) methodology. 3. User involvement in the project 3. Customer involvement.
BDD is considered a test to illustrate the behavior of the system. It encourages the use of conversation and 4. Project type and associated risk 4. Project complexity.
concrete examples in simple language for everyone involved in the development to bring better clarity to the
5. Cost of delay.
behavior of the system. In this development, techniques define various ways to develop a feature based on the
6. Familiarity with technology.
system’s behavior, and the techniques are combined from Test Driven Development (TDD) and Domain Driven
7. Project resources.
Development (DDD).

1. Requirements 2. Development team :  3. User involvement 4. Project type and

characteristics :  Team size in the project : associated risk :
 Reliability of  Experience of developers  Expertise of user in  Stability of funds
Requirements on similar type of project  Tightness of project
 How often the projects  Involvement of user schedule
requirements can  Level of understanding of in all phases of the  Availability of resources
change user requirements by the project  Type of project
 Types of requirements developers  Experience of user in  Size of the project
 Number of  Environment similar project in the  Expected duration for the
requirements  Domain knowledge of past completion of project
 Can the requirements be developers  Complexity of the
defined at an early stage  Experience on project
 Requirements indicate technologies to be used  Level and the type of
the complexity of the  Availability of training associated risk
system

21