UNIT-I INTRODUCTION

UNIT-I INTRODUCTION
UNIT-I INTRODUCTION
UNIT-I INTRODUCTION
 UNIT-I INTRODUCTION

Software engineering emerged as a distinct discipline in response to the growing complexity

and criticality of software systems. Here are some key milestones and factors that contributed
to its development:

1. Early Days of Computing (1940s-1950s)

● Initial Focus on Hardware: The earliest computers were custom-built machines, and
much of the effort was focused on hardware.
● Ad Hoc Software Development: Software development was done in an ad hoc
manner, with little formal methodology.

2. Software Crisis (1960s)

● Increasing Complexity: As computers became more powerful, the complexity of

software grew.
● Project Failures: Many software projects ran over budget, were delivered late, or
failed to meet user requirements.
● Recognition of Problems: The term "software crisis" was coined to describe these
issues.

3. NATO Conferences on Software Engineering (1968, 1969)

● Defining the Discipline: These conferences were crucial in defining software

engineering as a distinct discipline.
● Introduction of Methodologies: Emphasis was placed on the need for systematic
approaches to software development.

4. Development of Formal Methods (1970s-1980s)

● Structured Programming: Techniques like structured programming were

introduced to improve code clarity and reliability.
● Software Development Models: Models like the Waterfall Model were developed to
provide a structured approach to software development.
● Tools and Techniques: Development of tools and techniques for requirements
analysis, design, coding, testing, and maintenance.

5. Object-Oriented Programming and Design (1980s-1990s)

● Shift in Paradigm: The introduction of object-oriented programming (OOP) brought

a new way to conceptualize and structure software.
● UML and Design Patterns: Unified Modeling Language (UML) and design patterns
became important tools for designing software systems.

6. Agile Methodologies (1990s-Present)

 UNIT-I INTRODUCTION

● Agile Manifesto (2001): Emphasis on flexibility, customer collaboration, and

iterative development.
● Popular Frameworks: Frameworks like Scrum and Extreme Programming (XP)
gained popularity for their effectiveness in handling changing requirements.

7. Modern Trends

● DevOps: Integration of development and operations to improve collaboration and

efficiency.
● Microservices: Architectural style that structures an application as a collection of
loosely coupled services.
● AI and Machine Learning: Increasing use of AI and machine learning in software
development.

8. Professionalization

● Certification and Education: Emergence of certifications (e.g., Certified Software

Development Professional) and formal education programs.
● Ethics and Standards: Development of codes of ethics and standards by
organizations like the IEEE and ACM.

The evolution of software engineering as a discipline reflects the ongoing need to manage the
complexity, quality, and scale of software systems in a systematic and professional manner.

Historical Development from Jackson Structured Programming to Agile Development

1. Jackson Structured Programming (JSP) - 1970s

o Overview: JSP, developed by Michael A. Jackson in the 1970s, is a method
for structured programming, focusing on the logical structure of the data and
the program.
o Key Concepts: Program structure diagrams (PSDs), data structure diagrams,
and stepwise refinement.
o Impact: JSP provided a disciplined approach to programming, emphasizing
the relationship between data structures and program structures.
2. Structured Analysis and Design (SADT) - 1970s
o Overview: Structured Analysis and Design Technique (SADT) was
developed by Douglas T. Ross. It provides a way to represent system
functions and data flows.
o Key Concepts: Hierarchical decomposition, data flow diagrams (DFDs), and
activity diagrams.
o Impact: SADT facilitated clear communication between stakeholders and
provided a structured approach to system design.
3. Waterfall Model - 1970s
o Overview: The Waterfall model, introduced by Winston W. Royce, is a
sequential development process that flows downward through phases such as
requirements, design, implementation, testing, deployment, and maintenance.
 UNIT-I INTRODUCTION

o Key Concepts: Linear, phase-driven approach, heavy documentation.

o Impact: The Waterfall model was one of the first formal methodologies,
providing structure but often criticized for its inflexibility and inability to
accommodate changes.
4. Spiral Model - 1980s
o Overview: Barry Boehm introduced the Spiral model, combining iterative
development with systematic aspects of the Waterfall model.
o Key Concepts: Risk analysis, iterative refinement, and prototyping.
o Impact: The Spiral model emphasized risk management and iterative
refinement, making it more adaptable to changes.
5. Rapid Application Development (RAD) - 1980s
o Overview: RAD focuses on quick development and iteration, involving user
feedback and prototyping.
o Key Concepts: Prototyping, user involvement, time-boxing.
o Impact: RAD reduced development time and improved user satisfaction by
involving users throughout the development process.
6. Unified Process (UP) - 1990s
o Overview: The Unified Process, particularly the Rational Unified Process
(RUP), is an iterative software development process framework.
o Key Concepts: Use-case driven, architecture-centric, iterative and
incremental.
o Impact: UP/RUP provided a customizable and scalable framework that
balanced risk and flexibility.
7. Agile Development - 2000s
o Overview: Agile methodologies emphasize flexibility, collaboration, and
customer satisfaction. The Agile Manifesto, published in 2001, outlined core
values and principles.
o Key Concepts: Iterative development, user stories, continuous integration,
sprints.
o Impact: Agile methodologies, including Scrum and Extreme Programming
(XP), transformed software development by promoting adaptive planning,
evolutionary development, and early delivery.

Below is a simplified timeline diagram illustrating the evolution of software engineering

methodologies:

|-----------------------------------------------|
| 1970s | 1980s | 1990s | 2000s |
|-------------|-----------|-----------|---------|
| JSP | Spiral | UP | Agile |
| SADT | RAD | RUP | |
| Waterfall | | | |
|-----------------------------------------------|

Jackson Structured Programming (JSP) - 1970s

 UNIT-I INTRODUCTION

Jackson Structured Programming (JSP) is a method for program design and modeling “in the
small”. It begins with considerations about what is known and develops a program design
that becomes more complete as the model is put through continues iterations. It emerged in
the 1970’s as a design method that concentrated on the structure of data using data-structure
methods. Because it builds the program design from an incomplete model. JSP structures the
programs and data in terms of sequences, iterations and selection. The method begins by
describing a program’s inputs in terms of the four fundamental component types
(fundamental operations, sequences, iterations, selections) it then goes on to describe the
program’s outputs in the same way. JSP uses a diagramming notation to describe the
structure of inputs, outputs and programs with diagram elements for each of the fundamental
component types.

A simple operation is drawn as a box.

A sequence of operations is represented by boxes connected with lines. In the example

below, operation A consists of the sequence of operations B, C and D.

A sequence is a composite component that has two or more parts occurring once each, in a
specific order. Take the following diagram as an example
 UNIT-I INTRODUCTION

Take the following structure diagram for example:

Pseudocode can be written as:

Begin sport
Do
Cricket;
Do
Footbal
l; Do
Tennis;

End Sport
Begin Cricket
Do
Batting
; Do
Bowlin
g;
End Cricket

An Iteration is again represented with joined boxes.In addition, the iterated

operation has a star in the top right corner of its box. An iteration is a composite
component that consist of one part that repeats zero or more times. In the example below,
operation A consists of an iteration of zero or more invocations of operation B.
 UNIT-I INTRODUCTION

A selection is similar to a sequence, but with a circle drawn in the top right hand
corner of each optional operation. A selection is a composite component that consists of 2 or
more parts, only one of which is selected once. In the example, operation A consists of one
and only one operations B, C or D.

Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation that is

designed to help people understand the system. The basic goal of SA/SD is to improve
quality and reduce the risk of system failure. It establishes concrete management
specifications and documentation. It focuses on the solidity, pliability, and maintainability of
the system

IDENTIFY CHANGE
ABILITY NEEDS
 UNIT-I INTRODUCTION

MODEL THE
SYSTEM

DETERMINE THE
BEST CONFIGURE

RECONFIGURE
THE SYSTEM

Waterfall Model

The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.

Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In this Waterfall model, typically, the outcome
of one phase acts as the input for the next phase sequentially.

The following illustration is a representation of the different phases of the Waterfall Model.
 UNIT-I INTRODUCTION

The sequential phases in Waterfall model are

● Requirement Gathering and analysis

● System Design

● Implementation

● Integration and Testing

● Deployment of system

● Maintenance

Spiral Model - 1980

The Spiral Model is a combination of the waterfall model and the iterative model. It provides
support for Risk Handling
 UNIT-I INTRODUCTION

Each phase of the model is categorised into four quadrants. Let’s dive deeper to understand
the functions of these four quadrants in-depth-

1) Define objectives and discover alternate solutions

The first phase determines the project’s scope and creates a plan for the subsequent iteration
of the spiral. It involves tasks like gathering requirements and analysis. Depending on these
requirements, objectives are stated, and various alternate solutions are recommended.

2) Risk analysis and resolution

This phase analyses all the recommended solutions. Moreover, any potential risk is
recognised, analysed, and resolved. An alternative solution is discussed and executed based
on the risks that arise.

It also involves prototype creation. In addition to identifying potential risks, it also arranges
and finalises the risk mitigation strategy.

3) Develop and test

This phase is the core of the spiral model process. This is because it implements various
essential features. All the executed features are verified with exhaustive testing. Once the
product development completes, the phase tests, codes, and deploys software on the client
side.

4) Evaluation& Review and plan the next phase

This phase evaluates the software to learn if it fulfils the customer’s requirements and
whether it is of high quality or not. It also involves recognising risks. The customer evaluates
the developed software in this phase. Based on the evaluation outcomes, the subsequent
iteration of the spiral starts with a new planning phase.

The RAD (Rapid Application Development) model

 UNIT-I INTRODUCTION

is based on prototyping and iterative development with no specific planning involved. The
process of writing the software itself involves the planning required for developing the
product.

Rapid Application Development focuses on gathering customer requirements through

workshops or focus groups, early testing of the prototypes by the customer using iterative
concept, reuse of the existing prototypes (components), continuous integration and rapid
delivery.

Business Modelling

The business model for the product under development is designed in terms of flow of
information and the distribution of information between various business channels. A
complete business analysis is performed to find the vital information for business, how it can
be obtained, how and when is the information processed and what are the factors driving
successful flow of information.

Data Modelling

The information gathered in the Business Modelling phase is reviewed and analyzed to form
sets of data objects vital for the business. The attributes of all data sets is identified and
defined. The relation between these data objects are established and defined in detail in
relevance to the business model.

Process Modelling

The data object sets defined in the Data Modelling phase are converted to establish the
business information flow needed to achieve specific business objectives as per the business
model. The process model for any changes or enhancements to the data object sets is defined
in this phase. Process descriptions for adding, deleting, retrieving or modifying a data object
are given.

Application Generation

The actual system is built and coding is done by using automation tools to convert process
and data models into actual prototypes.

Testing and Turnover

The overall testing time is reduced in the RAD model as the prototypes are independently
tested during every iteration. However, the data flow and the interfaces between all the
components need to be thoroughly tested with complete test coverage. Since most of the
programming components have already been tested, it reduces the risk of any major issues.
 UNIT-I INTRODUCTION

The Unified Process (UP)

is a software development framework used for Object oriented model. The framework is also
known as Rational Unified Process (RUP) and the Open Unified Process (Open UP). Some
of the key features of this process include:

● It defines the order of phases.

● It is component-based, meaning a software system is built as a set of software

components. There must be well-defined interfaces between the components for
smooth communication.
● It follows an iterative, incremental, architecture-centric, and use-case driven approach

1.Inception -defining the project scope and objectives

2. Elaboration- analysing the problem domain and establishing an architectural

foundation

3.Construction -developing and building the product

4. Transition -delivering the product to users and ensuring it meets their needs

Rational Unified Process (RUP)

is a framework for software engineering processes. RUP is an Iterative and

incremental approach to improving problem knowledge through consecutive revisions. It is
 UNIT-I INTRODUCTION

an architecture-centric and use-case-driven approach that manages risk and is flexible to

change. RUP incrementally improves an effective solution through repeated iterations.

Inception –
Communication and planning are the main ones.
Identifies the scope of the project using a use-case model allowing managers to estimate
costs and time required.
Customers’ requirements are identified and then it becomes easy to make a plan for the
project.
The project plan, Project goal, risks, use-case model, and Project description, are made.
The project is checked against the milestone criteria and if it couldn’t pass these criteria
then the project can be either cancelled or redesigned.
Elaboration –
Planning and modelling are the main ones.
A detailed evaluation and development plan is carried out and diminishes the risks.
Revise or redefine the use-case model (approx. 80%), business case, and risks.
Again, checked against milestone criteria and if it couldn’t pass these criteria then again
project can be cancelled or redesigned.
Executable architecture baseline.
Construction –
The project is developed and completed.
System or source code is created and then testing is done.
Coding takes place.
Transition –
The final project is released to the public.
 UNIT-I INTRODUCTION

Transit the project from development into production.

Update project documentation.
Beta testing is conducted.
Defects are removed from the project based on feedback from the public.
Production –
The final phase of the model.
The project is maintained and updated accordingly.

Agile Model In Designing System

The Agile model in the context of system design is a flexible and adaptive approach to
designing systems that can respond to changing requirements and customer needs. The key
objective is to create a functioning system as soon as possible and to refine it depending on
input from stakeholders. The agile model also promotes customer and developer
involvement, which helps guarantee that the system being created satisfies end-user
requirements.
● The agile model emphasizes iterative and incremental development, customer and
developer communication, and flexible response to evolving needs.
● The Agile model typically consists of several iterations or sprints, each of which is
focused on delivering a specific set of features or functionality.
● The stakeholders evaluate the work completed at the conclusion of each sprint and offer
feedback, which is then utilized to plan and prioritize the following batch of tasks.

Planning:

● Goal: Plan the first sprint, define user stories, and prioritize them. The team sets a
goal for the sprint and identifies tasks to complete.
● Activities:
 UNIT-I INTRODUCTION

o Sprint planning meetings

o User story writing and estimation
o Task breakdown and assignment

3. Design:

● Goal: Create a design or prototype based on user stories. The design is often minimal
and focuses on getting feedback quickly.
● Activities:
o Collaborative design sessions
o Creating wireframes or prototypes
o Refining requirements based on design feedback

4. Development:

● Goal: Build the functionality according to the design and requirements. Development
is done in small, iterative cycles.
● Activities:
o Coding
o Unit testing
o Continuous integration

5. Testing:

● Goal: Ensure the developed features meet the acceptance criteria. Testing is
integrated throughout the sprint to catch issues early.
● Activities:
o Automated and manual testing
o Bug tracking and resolution
o User acceptance testing (UAT)

6. Review/Demo:

● Goal: Present the completed work to stakeholders. The team demonstrates the
functionality and gathers feedback.
● Activities:
o Sprint review meetings
o Product demonstrations
o Feedback collection

7. Release (optional):

● Goal: Deploy the completed increment to production. This step may occur after
several sprints, depending on the project's release strategy.
 UNIT-I INTRODUCTION

● Activities:
o Final testing and bug fixes
o Deployment to production
o Release notes and documentation

8. Maintenance (optional):

● Goal: Provide ongoing support, fix any post-release bugs, and plan for future
enhancements.
● Activities:
o Bug fixing
o Minor updates
o Planning for next iterations or phase

Agile Software Engineering:

Concepts of Agile Methods
An agile methodology is an iterative approach to software development. Each iteration of
agile methodology takes a short time interval of 1 to 4 weeks. The agile development process
is aligned to deliver the changing business requirement. It distributes the software with faster
and fewer changes.
The single-phase software development takes 6 to 18 months. In single-phase development,
all the requirement gathering and risks management factors are predicted initially.
The agile software development process frequently takes the feedback of workable product.
The workable product is delivered within 1 to 4 weeks of iteration.
 UNIT-I INTRODUCTION

Extreme Programming (XP)

Extreme Programming (XP) is an Agile software development methodology that focuses on
delivering high-quality software through frequent and continuous feedback, collaboration,
and adaptation. XP emphasizes a close working relationship between the development team,
the customer, and stakeholders, with an emphasis on rapid, iterative development and
deployment.
 UNIT-I INTRODUCTION

Agile development approaches evolved in the 1990s as a reaction to documentation and

bureaucracy-based processes, particularly the waterfall approach. Agile approaches are based
on some common principles, some of which are:
1. Working software is the key measure of progress in a project.
2. For progress in a project, therefore software should be developed and delivered rapidly in
small increments.
3. Even late changes in the requirements should be entertained.
4. Face-to-face communication is preferred over documentation.
5. Continuous feedback and involvement of customers are necessary for developing good-
quality software.
6. A simple design that involves and improves with time is a better approach than doing an
elaborate design up front for handling all possible scenarios.
7. The delivery dates are decided by empowered teams of talented individuals.
Extreme programming is one of the most popular and well-known approaches in the family
of agile methods. an XP project starts with user stories which are short descriptions of what
scenarios the customers and users would like the system to support. Each story is written on a
separate card, so they can be flexibly grouped.

Basic Principles of Extreme programming

XP is based on the frequent iteration through which the developers implement User Stories.
User stories are simple and informal statements of the customer about the functionalities
needed. A User Story is a conventional description by the user of a feature of the required
system. It does not mention finer details such as the different scenarios that can occur. Based
on User stories, the project team proposes Metaphors. Metaphors are a common vision of
how the system would work. The development team may decide to build a Spike for some
features. A Spike is a very simple program that is constructed to explore the suitability of a
solution being proposed. It can be considered similar to a prototype. Some of the basic
activities that are followed during software development by using the XP model are given
below:
● Coding: The concept of coding which is used in the XP model is slightly different from
traditional coding. Here, the coding activity includes drawing diagrams (modeling) that
 UNIT-I INTRODUCTION

will be transformed into code, scripting a web-based system, and choosing among several
alternative solutions.
● Testing: The XP model gives high importance to testing and considers it to be the
primary factor in developing fault-free software.
● Listening: The developers need to carefully listen to the customers if they have to
develop good quality software. Sometimes programmers may not have the depth
knowledge of the system to be developed. So, the programmers should understand
properly the functionality of the system and they have to listen to the customers.
● Designing: Without a proper design, a system implementation becomes too complex, and
very difficult to understand the solution, thus making maintenance expensive. A good
design results elimination of complex dependencies within a system. So, effective use of
suitable design is emphasized.
● Feedback: One of the most important aspects of the XP model is to gain feedback to
understand the exact customer needs. Frequent contact with the customer makes the
development effective.
● Simplicity: The main principle of the XP model is to develop a simple system that will
work efficiently in the present time, rather than trying to build something that would take
time and may never be used. It focuses on some specific features that are immediately
needed, rather than engaging time and effort on speculations of future requirements.
● Pair Programming: XP encourages pair programming where two developers work
together at the same workstation. This approach helps in knowledge sharing, reduces
errors, and improves code quality.
● Continuous Integration: In XP, developers integrate their code into a shared repository
several times a day. This helps to detect and resolve integration issues early on in the
development process.
● Refactoring: XP encourages refactoring, which is the process of restructuring existing
code to make it more efficient and maintainable. Refactoring helps to keep the codebase
clean, organized, and easy to understand.
● Collective Code Ownership: In XP, there is no individual ownership of code. Instead,
the entire team is responsible for the codebase. This approach ensures that all team
members have a sense of ownership and responsibility towards the code.
● Planning Game: XP follows a planning game, where the customer and the development
team collaborate to prioritize and plan development tasks. This approach helps to ensure
that the team is working on the most important features and delivers value to the
customer.
● On-site Customer: XP requires an on-site customer who works closely with the
development team throughout the project. This approach helps to ensure that the
customer’s needs are understood and met, and also facilitates communication and
feedback.
 UNIT-I INTRODUCTION

Life Cycle of Extreme Programming (XP)

The Extreme Programming Life Cycle consist of five phases:

1. Planning: The first stage of Extreme Programming is planning. During this phase, clients
define their needs in concise descriptions known as user stories. The team calculates the
effort required for each story and schedules releases according to priority and effort.
2. Design: The team creates only the essential design needed for current user stories, using
a common analogy or story to help everyone understand the overall system architecture
and keep the design straightforward and clear.
3. Coding: Extreme Programming (XP) promotes pair programming i.e. wo developers
work together at one workstation, enhancing code quality and knowledge sharing. They
write tests before coding to ensure functionality from the start (TDD), and frequently
integrate their code into a shared repository with automated tests to catch issues early.
4. Testing: Extreme Programming (XP) gives more importance to testing that consist of
both unit tests and acceptance test. Unit tests, which are automated, check if specific
features work correctly. Acceptance tests, conducted by customers, ensure that the overall
system meets initial requirements. This continuous testing ensures the software’s quality
and alignment with customer needs.
5. Listening: In the listening phase regular feedback from customers to ensure the product
meets their needs and to adapt to any changes.

Agile Process Model - Scrum, Feature; Scenarios and Stories.

The Agile process model encompasses various frameworks, each with its own practices and
methodologies to facilitate agile project management. Two widely used frameworks within
Agile are Scrum and Feature-Driven Development (FDD). Additionally, scenarios and user
stories are crucial components in Agile methodologies for capturing requirements and
guiding development.
What is a scrum in software development?
Scrum is a management framework that teams use to self-organize tasks and work towards a
common goal. It is a framework within which people can address complex adaptive problems
while the productivity and creativity of delivering products are at the highest possible value.
Scrum is a management framework that teams use to self-organize and work towards a
common goal.
 UNIT-I INTRODUCTION

● Scrum allows us to develop products of the highest value while making sure that we
maintain creativity and productivity.
● The iterative and incremental approach used in scrum allows the teams to adapt to the
changing requirements.
Silent features of Scrum
● Scrum is a light-weighted framework

● Scrum emphasizes self-organization

● Scrum is simple to understand
● Scrum framework helps the team to work together
● Lifecycle of Scrum

● Sprint: A Sprint is a time box of one month or less. A new Sprint starts immediately
after the completion of the previous Sprint. Release: When the product is completed, it
goes to the Release stage.
● Sprint Review: If the product still has some non-achievable features, it will be checked
in this stage and then passed to the Sprint Retrospective stage.
● Sprint Retrospective: In this stage quality or status of the product is checked. Product
Backlog: According to the prioritize features the product is organized.
● Sprint Backlog: Sprint Backlog is divided into two parts Product assigned features to
sprint and Sprint planning meeting.
Advantage of Scrum framework
● Scrum framework is fast moving and money efficient.

● Scrum framework works by dividing the large product into small sub-products. It’s like a
divide and conquer strategy
● In Scrum customer satisfaction is very important.

● Scrum is adaptive in nature because it have short sprint.

 UNIT-I INTRODUCTION

● As Scrum framework rely on constant feedback therefore the quality of product increases
in less amount of time
Disadvantage of Scrum framework
● Scrum framework do not allow changes into their sprint.

● Scrum framework is not fully described model. It can be difficult for the Scrum to plan,
structure and organize a project that lacks a clear definition.
● The daily Scrum meetings and frequent reviews require substantial resources.
Roles
● Product Owner: Responsible for maximizing the value of the product by managing the
product backlog, prioritizing features, and ensuring the team delivers value to the
customer.
● Scrum Master: Facilitates the Scrum process, removes impediments, and helps the team
adhere to Scrum practices. Acts as a coach for the team.
● Development Team: A cross-functional group responsible for delivering potentially
shippable increments of the product at the end of each sprint.
● Events

● Sprint: A time-boxed iteration (usually 1-4 weeks) during which the team works to
complete a set of selected product backlog items.
● Sprint Planning: A meeting where the team selects product backlog items to work on
during the sprint and defines a sprint goal.
● Daily Scrum: A short daily meeting (15 minutes) where the team discusses progress,
plans for the day, and identifies any impediments.
● Sprint Review: A meeting at the end of the sprint where the team demonstrates the
completed work to stakeholders and receives feedback.
● Sprint Retrospective: A meeting held after the Sprint Review where the team reflects on
the sprint and identifies ways to improve processes.
● Product Backlog: A prioritized list of features, enhancements, bug fixes, and
requirements maintained by the Product Owner.
● Sprint Backlog: A list of tasks and items selected from the product backlog for the
current sprint, along with a plan for delivering them.
● Increment: The sum of all completed product backlog items during a sprint, which must
be in a usable and potentially shippable state.

Feature-Driven Development (FDD)

FDD stands for Feature-Driven Development. It is an agile iterative and incremental model
that focuses on progressing the features of the developing software. The main motive of
feature-driven development is to provide timely updated and working software to the client.
In FDD, reporting and progress tracking is necessary at all levels.
 UNIT-I INTRODUCTION

Processes

1. Develop an Overall Model: Establishing a high-level understanding of the system

and its architecture.
2. Build a Feature List: Creating a comprehensive list of features that the system
should have.
3. Plan by Feature: Prioritizing features and creating a plan for their implementation.
4. Design by Feature: Detailing the design for each feature before development starts.
5. Build by Feature: Developing and testing features in small, manageable chunks.

Characteristics of FDD
● Short iterative: FDD lifecycle works in simple and short iterations to efficiently finish
the work on time and gives good pace for large projects.
● Customer focused: This agile practice is totally based on inspection of each feature by
client and then pushed to main build code.
● Structured and feature focused: Initial activities in lifecycle builds the domain model
and features list in the beginning of timeline and more than 70% of efforts are given to
last 2 activities.
● Frequent releases: Feature-driven development provides continuous releases of features
in the software and retaining continuous success of the project.
Advantages of FDD
● Reporting at all levels leads to easier progress tracking.

● FDD provides continuous success for larger size of teams and projects.
● Reduction in risks is observed as whole model and design is build in smaller segments.
 UNIT-I INTRODUCTION

● FDD provides greater accuracy in cost estimation of the project due to feature
segmentation.
Disadvantages of FDD
● This agile practice is not good for smaller projects.

● There is high dependency on lead programmers, designers and mentors.

● There is lack of documentation which can create an issue afterwards.

Scenarios and Stories

User Stories
User stories are short, simple descriptions of a feature or requirement from the end-user's
perspective. They typically follow the format: "As a [user], I want [goal] so that [benefit]."
User stories are placed in the product backlog and prioritized by the Product Owner.
Scenarios
Scenarios provide more detailed descriptions of how users will interact with the system in
specific situations. They often include context, steps, and expected outcomes. Scenarios help
to clarify user stories and guide the development process.
Example of a User Story and Scenario
User Story:

● "As a registered user, I want to reset my password so that I can regain access to my
account if I forget it."

Scenario:

● Context: The user is on the login page and has forgotten their password.
● Steps:
1. The user clicks on the "Forgot Password" link.
2. The system prompts the user to enter their registered email address.
3. The user enters their email address and clicks "Submit."
4. The system sends a password reset link to the user's email.
5. The user receives the email and clicks on the reset link.
6. The system prompts the user to enter a new password and confirm it.
7. The user enters and confirms the new password and clicks "Submit."
● Expected Outcome: The system successfully updates the user's password, and the
user can log in with the new password.

Scrum, FDD, user stories, and scenarios are fundamental components of the Agile process
model. Scrum focuses on iterative development and team collaboration, while FDD
emphasizes feature-centric development. User stories and scenarios help capture
requirements and guide the development process, ensuring that the final product meets user
needs and expectations.
UNIT-I INTRODUCTION