Agile Frameworks

RUP and FDD

Some of the key Agile methodologies
• Extreme Programming or XP
• Scrum
• Crystal
• Dynamic System Development Methodology or DSDM Atern
• Feature Driven Development or FDD
• Agile Project Management or APM
• Lean Kanban
• OpenUp
Rational Unified Process (RUP)
• RUP is a risk-driven, use-case-based, and architecture-centric,
iterative software development process. RUP embodies industry-
standard management and technical methods and techniques to
provide a software engineering process particularly suited to creating
and maintaining component-based software system solutions. RUP
communicates roles, activities, and artefacts organized by process
workflows that guide project teams through software engineering
disciplines under the purview of operational business phases and
decision-making milestones.
Rational Unified Process (RUP)
• RUP's foundation consists of three key elements: the role, the activity,
and the artefact.

• The role performs activities and produces artefacts. Each role is

primarily responsible for a set of activities and artefacts. But all roles
will contribute to other activities and artefacts. Roles, activities, and
artefacts are used repeatedly during the execution of workflows. The
workflows form a sequence of tasks unique to each of the nine
software disciplines in the RUP iterative development software
lifecycle framework
Process Overview
Phases and Iterations – The Time Dimension
RUP's foundation consists of three key elements: the role, the activity, and the
artefact.
This is the dynamic organization of the process along time.
The software lifecycle is divided into cycles with each cycle working on a new
generation of the product. The Rational Unified Process divides one
development cycle in four consecutive phases
• Inception phase
• Elaboration phase
• Construction phase
• Transition phase
Phases and Iterations – The Time Dimension
• Each phase is concluded with a well-defined milestone—a point in time
at which certain critical decisions must be made, and therefore key goals
must have been achieved

• The role performs activities and produces artefacts. Each role is primarily
responsible for a set of activities and artefacts. But all roles will
contribute to other activities and artefacts. Roles, activities, and artefacts
are used repeatedly during the execution of workflows. The workflows
form a sequence of tasks unique to each of the nine software disciplines
in the RUP iterative development software lifecycle framework
Static structure of the process
• Each phase is concluded with a well-defined milestone—a point in
time at which certain critical decisions must be made, and therefore
key goals must have been achieved
• A process describes who is doing what, how, and when. The Rational
Unified Process is represented using four primary modelling elements:
• Workers, the ‘who’
• Activities, the ‘how’
• Artefacts, the ‘what’
• Workflows, the ‘when’
Static structure of the process
• The role performs activities and produces artefacts. Each role is
primarily responsible for a set of activities and artefacts. But all roles
will contribute to other activities and artefacts. Roles, activities, and
artefacts are used repeatedly during the execution of workflows. The
workflows form a sequence of tasks unique to each of the nine
software disciplines in the RUP iterative development software
lifecycle framework
Core Workflows
• There are nine core process workflows in the Rational Unified
Process, which represent a division of all workers and activities into
logical groupings.
• The core process workflows are divided into six core “engineering”
workflows:
1. Business modelling workflow

2. Requirements workflow
Core Workflows
3. Analysis & Design workflow

4. Implementation workflow

5. Test workflow

6. Deployment workflow
Core Workflows
And three core “supporting” workflows:

1. Project Management workflow

2. Configuration and Change Management workflow

3. Environment workflow
Core Workflows
Although the names of the six core engineering workflows may evoke
the sequential phases in a traditional waterfall process, we should keep
in mind that the phases of an iterative process are different and that
these workflows are revisited again and again throughout the lifecycle.
The actual complete workflow of a project interleaves these nine cores
workflows and repeats them with various emphasis and intensity at
each iteration.
Core Workflows
Although the names of the six core engineering workflows may evoke
the sequential phases in a traditional waterfall process, we should keep
in mind that the phases of an iterative process are different and that
these workflows are revisited again and again throughout the lifecycle.
The actual complete workflow of a project interleaves these nine cores
workflows and repeats them with various emphasis and intensity at
each iteration.
Feature Drive Development (FDD)
Although the names of the six core engineering workflows may evoke
the sequential phases in a traditional waterfall process, we should keep
in mind that the phases of an iterative process are different and that
these workflows are revisited again and again throughout the lifecycle.
The actual complete workflow of a project interleaves these nine cores
workflows and repeats them with various emphasis and intensity at
each iteration.
Feature Drive Development (FDD)
Feature Driven Development (FDD) is an agile framework that, as its
name suggests, organizes software development around making
progress on features. Features in the FDD context, though, are not
necessarily product features in the commonly understood sense.
• Advantages 
• Simple five-step process allows for more rapid development
• Allows larger teams to move products forward with continuous success
• Leverages pre-defined development standards, so teams can move quickly
Feature Drive Development (FDD)
Feature Driven Development (FDD) is an agile framework that, as its
name suggests, organizes software development around making
progress on features. Features in the FDD context, though, are not
necessarily product features in the commonly understood sense.
• Disadvantages 
• Does not work efficiently for smaller projects
• Less written documentation, which can lead to confusion
• Highly dependent on lead developers or programmers
Life cycle
1. Develop an overall model
Client and the development team make an overall model. Detailed domain models are
created and then these models are progressively merged into overall model. Guided
by a chief architect, team members get a good understanding of the complete model.

2. Build a features list

Information gathered in previous step is now deduced to make a list of required
features. A feature is a small, client valued output. The whole project is thereby
divided into features. A feature needs to be delivered every two weeks. Therefore, any
feature the team decides to work on must take less than two weeks to be
implemented.
Life cycle
3. Plan by feature
Once the development of features is planned, it’s all about in which order the features will be
implemented. Teams are selected and assigned with feature sets.

4. Design by feature
Chief programmer chooses the features and the domain classes that will be involved in designing the
feature. Sequence diagrams are drawn, and general designs of the features are also finalised. Class and
method prologues are written. This is all followed by a design inspection.

5. Build by feature
After the design inspection, the domain expert explains the specifics. Class owners start building and
implementing all the items necessary to support the design. Code is developed, unit tested, inspected
and approved by Chief Programmer who then approves it and then the completed feature is added to the
main build.
Test Driven Development (TDD)
Test-driven development (TDD), which is rooted in extreme
programming, is all about satisfying your team that the code works as
expected for a behaviour or use case. Instead of aiming for the
optimum solution in the first pass, the code and tests are iteratively
built together one-use case at a time. Development teams use TDD as
part of many coding disciplines to ensure test coverage, improve code
quality, set the groundwork for their delivery pipeline, and support
continuous delivery.
Test Driven Development (TDD)
The basic concept of TDD is that all production code is written in
response to a test case. Robert C. Martin, who is known as Uncle Bob,
describes these Three Laws of TDD:
• You are not allowed to write any production code unless it is to make
a failing unit test pass.
• You are not allowed to write any more of a unit test than is enough to
fail; and compilation failures are failures.
• You are not allowed to write any more production code than is
enough to pass the one failing unit test
Benefits
• It can enable faster innovation and continuous delivery because the
code is robust.
• It makes your code flexible and extensible. The code can be
refactored or moved with minimal risk of breaking code.
• The tests themselves were tested. A key characteristic of a test is that
it can fail, and the development team verifies that each new test fails.
• The code that is produced is, by design, easy to test.
• The requirements are implemented with little to no wasted effort
because only the function that is needed is written.
Life cycle
• A TDD cycle incorporates Uncle Bob's
three TDD rules and adds a
refactoring step after the tests pass:
• TDD practitioners refer to this cycle
as the Red/Green/Refactor cycle. In
the article TDD - What it is and what
it is not, Andrea Koutifaris describes
this cycle:
Life cycle
• Red phase: You write an automated test for a behaviour that you're
about to implement. Based on the user requirement, you decide how
you can write a test that uses a piece of code as if it were
implemented. This is a good opportunity to think about the externals
of the code, without getting distracted by filling in the
implementation. Think about what the interface should look like?
What behaviours should a caller of that interface expect? Is the
interface clean and consumable?
Life cycle
• Green phase: You write production code, but only enough production code to pass
the test. You don't write algorithms, and you don't think about performance. You can
duplicate code and even violate best practices. By addressing the simplest tasks, your
code is less prone to errors and you avoid winding up with a mix of code: some tested
(your minimalist functions) and some untested (other parts that are needed later).

• Refactor phase: You change the code so that it becomes better. At a minimum, you
remove code duplication. Removing duplication generally leads to abstraction. Your
specific code become more general. The unit tests provide a safety net which
supports the refactoring, because they make sure that the behaviour stays the same
and nothing breaks. In general, tests should not need to be changed during the
refactor stage.
Types of Tests
• If your team is hesitant to skip traditional unit tests, remember: TDD
drives the code development, and every line of code has an associated
test case, so unit testing is integrated into the practice. Unit testing is
repeatedly done on the code until each unit functions per the
requirements, eliminating the need for you to write more unit test cases.

• At IBM, teams found that the built-in unit testing produces better code.
One team recently worked on a project where a small portion of the team
used TDD while the rest wrote unit tests after the code. When the code
was complete, the developers that wrote unit tests were surprised to see
that the TDD coders were done and had more solid code.
Types of Tests
• Unlike unit testing that focuses only on testing the functions, classes,
and procedures, TDD drives the complete development of the
application. Therefore, you can also write functional and acceptance
tests first.

• To gain the full benefits of unit testing and TDD, automate the tests by
using automated unit test tools. Automating your tests is essential for
continuous integration and is the first step in creating an automated
continuous delivery pipeline.
Scrum
• By now, you’ve most probably known about the term – “Scrum”. It is a
popular agile project management methodology which focuses on
defining key features and its objectives in the beginning of each
sprint.

• Simply put, Scrum was introduced to reduce the overall risk in a

software project, while also providing the value faster.
Definition and History of Scrum
• Scrum methodology is one of the leading Agile techniques developed in the 1990s by Ken
Schwaber and Jeff Sutherland. It is a term used in Rugby game and refers to an interlocked
team working together to push a rugby ball into the hands of their team members, so they
can move it down the field and score.

• In the context of software development, Scrum is a method of project management in an

agile development process to keep the focus on delivering the highest business value to
stakeholders in the shortest possible time.

• The Scrum process helps ensure that the most valuable remaining features are built next,
and it emphasizes that work always be completed to the point of being deliverable. Work is
structured in two-to-four-week sprints, or iterations, with working software produced by
the end of each sprint.
Overview of Scrum
• Scrum is an iterative and incremental approach to software development, meaning that a large project is
split into a series of iterations called “Sprints”, where in each sprint, the goal is to complete a set of tasks to
move the project closer to completion.

• Each sprint typically lasts 2 to 4 weeks or a calendar month at most. Building products one small piece at a
time encourages creativity and enables teams to respond to feedback and change and to build exactly what
is needed.

• In scrum, product is designed, coded and tested in the sprint.

• A key principle of Scrum is its recognition that: during a project the customers can change their minds about
what they want or need, and that unpredicted challenges cannot be easily addressed in a traditional
predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem
cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly
and respond to emerging requirements.
Kanban
• Many development teams use the Kanban method to manage their
work. Fundamentally, Kanban is a visual representation of work in
progress. A Kanban board can be as simple as sticky notes and lanes
on a whiteboard or your team may adopt web-based tools that can be
accessed by everyone on your team. On-line Kanban boards are
especially useful if your team is not co-located.
History & Overview
• Kanban has two important principles: the workflow is visible to the
entire team and the work in progress is limited to the capacity of the
people who are doing the work. You can't keep adding work to the
queue and expect it to get done—or done well.
• By following the Kanban method, teams can deliver features quickly,
reduce the inefficiencies of multitasking, and identify bottlenecks and
dependencies.
History & Overview
• The basic Kanban workflow is as follows:
• New: Work that is new to the team and has not yet been added to the
backlog.
• Ranked backlog: Work that is waiting to be started, ranked in order of
importance and size.
• Work in progress: Work that is in progress by a team member.
• Under review: Another member of the team checks the work.
• Done: If review goes well, the work is complete and ready for production.
• Repeat: A team member takes the next item from the backlog.
Overview
Kanban board
• The format of your Kanban board might change depending on the group you're working with.
For example, a management team might use a board
• to track epic stories or broad ideas. A development team might use its board to track the backlog
and work that is in progress and completed.
• Types of Kanban boards:
• Three types of Kanban walls and headers are common:
•  Portfolio walls: For management-level tracking of whole projects or epics across a larger
organization
• Headers: Idea, In Discovery, In Delivery
•  Program walls: For project-management-level tracking of a project across several teams
• Headers: Backlog, In-progress, under review, Done
• Team walls: For team-level tracking of work
• Headers: Backlog, In-progress, under review, Done
Kanban board
• Types of Kanban boards:
• Three types of Kanban walls and headers are common:
•  Portfolio walls: For management-level tracking of whole projects or
epics across a larger organization
• Headers: Idea, In Discovery, In Delivery
•  Program walls: For project-management-level tracking of a project
across several teams
• Headers: Backlog, In-progress, under review, Done
• Team walls: For team-level tracking of work
• Headers: Backlog, In-progress, under review, Done