Introduction

Adaptive vs. Predictive software development

Traditional Software development process
◦ Waterfall model
◦ Iterative Incremental Model
◦ Spiral Model

Agile Software development process

◦ Extreme Programming Model
◦ SCRUM Model
Conclusion
Software Development process (lifecycle)
◦ Is a structure imposed on the development
of a software product
Requirements
specification

Analyses and
Maintenance
Design

Deployment Implementation

Testing
Software Development Process

Traditional Agile

Incremental Extreme
Waterfall Spiral SCRUM
iterative programming
Adaptive methods focus on adapting quickly
to change

When the project requirement change the

adapted team also change

An adaptive team can not report exactly what

tasks are being done next week

An Example of adaptive methods is Agile

Predictive method focus on planning the
future in details

Predictive team can report exactly what

features and tasks are planned for the entire
length of the development process

Predictive team have difficulty changing

direction, the plan is typically optimized for
the original destination and changing
direction can require completed work to be
started over
Waterfall
Clean Room
DSDM (Dynamic System Development Method)
Iterative Incremental
RAD (Rapid Application Development)
RUP (Rational Unified Process)
Spiral
V-Model
FDD (Feature Driven Development)
Waterfall
Clean Room
DSDM (Dynamic System Development Method)
Iterative Incremental
RAD (Rapid Application Development)
RUP (Rational Unified Process)
Spiral
V-Model
FDD (Feature Driven Development)
Is a sequential design process, often used in
software development processes

Originates in the manufacturing and

construction industries; highly structured
physical environments

The Idea behind the waterfall model is

Waterfall Model Phases :
Requirement

specification
Proceeds from one phase to the next in a
sequential manner

You only move to next phase when the current

phase is completed and perfected

Time spent early in the Software production cycle

can lead to greater economy at later stages

A bug found in the early stages is cheaper in

money , effort and time

Design documents is very important as

source code
Why Waterfall
◦ Provides a structured approach, it progress
linearly, easily, understandable and explainable

◦ Provides easily markable milestones in the

development process

◦ Suites the stable, unchanging

requirements
Why not Waterfall
◦ Many people think that waterfall model is a bad
idea in practice

◦ It is impossible for any project to finish a phase of

a software products lifecycle perfectly before
moving to the next phase

Client may not know exactly

what requirements he need
and he will need to change his
requirements at any time
Why not Waterfall
◦ Many people think that waterfall model is a bad
idea in practice

◦ It is impossible for any project to finish a phase of

a software products lifecycle perfectly before
moving to the next phase

Designers may not be aware of

future Implementation
Why not Waterfall
◦ Many people think that waterfall model is a bad
idea in practice

◦ It is impossible for any project to finish a phase of

a software products lifecycle perfectly before
moving to the next phase

Stockholders may not be fully

aware of the capabilities of the
technology being
implemented
Developed in response to the weaknesses of the
waterfall model

Starts with initial planning and ends with

deployment with the cycle interactions
in between

Iterative & incremental development is essential

parts of the extreme programming & generally
the Agile Development

The project is delivered through cross discipline

work from the requirement to the deployment
 Initial Planning
Deployment Evaluation Planning

Testing Requirements

Analysis &
Implementation
design
The basic idea is to develop a system through
repeated cycles (Iterative) and in smaller portions at a
time (Incremental)

Allowing developers to take advantage of what was

learned during the development of earlier
portions

Start with simple implementation of a subset of the

software requirements and iteratively enhance the
evolving version until the full system is implemented

At each iteration, design modifications are made

and new functional capabilities are added
Initialization
• Create a base version of the system
• The goal is to create a product to which the user can react
•Offer a sampling of the key aspects of the problem & provide

Step a simple solution easily to understand and implement

Project
• It’s the result of the analysis phase
•Include item of new features to be implemented and also
the areas of redesign of the existing solution

Control List
•Redesign and implement of tasks from the control list

Iteration and analyses the current system

• The goal of any iteration is to be (simple, straight

Step
forward,
modular and supporting redesign)
In a light weight iterative project the code represent the
main documentation

In a mission critical iterative project a formal software

design document used

The analysis of iteration is based on user feedback

It involves analysis of the structure modularity, usability,

reliability, efficiency and achievement of goals
Inception

• Identify project scope, risks, requirements (functional and

non functional), at a high level with enough details to be able
to estimate

Elaboration

• Deliver a working architecture that mitigates the top risks

and fulfills the non functional requirements

Construction

• Fills in the architecture with production ready code produced

from analysis, design, implementation and testing

Transition

• Delivers the system into the production operating

system
 Waterfall Iterative Incremental

Complete each step before

Backtracking is possible
moving to the next step

Business value is delivered

all at once

Backtracking means waste

in time, effort, money
Implementation Guidelines
◦ Any difficulty in design, coding & testing means the
need of redesign and modification

◦ Modifications should fit easily isolated and easy to

find modules

◦ The existing implementation should be analyzed

frequently to determine how well it measures up to
project goals
The spiral model was defined by Barry Boehm

This model was not the first model to discuss iteration,

but it was the first model to explain why the iteration
matters

aims at risk reduction by any means in any phase. The

spiral model is often referred to as a risk-driven model

Introducing prototyping in a Software Process aims at risk

reduction at the requirements level

There is always an element of risk involved in the other

phases of development
Quadrant 1
◦ Determining objectives of that phase, alternatives
and constraints
◦ This is a way to define a strategy for achieving the
goals of this iteration

Quadrant 2
◦ The strategy is analyzed form the viewpoint of risk,
and solutions to minimize these risks are
investigated
Quadrant 3
◦ A solution is put into practice to produce the
artifacts necessary to reach the goals identified in
quadrant 1

Quadrant 4
◦ The results of the risk-reduction strategies are
assessed, and if all risks are resolved, the
next phase is planned and started

◦ If some risks are left unsolved, another iteration

can be made to continue to work
Advantages
◦ Emphasis on alternatives and constraints supports the
reuse of existing solutions.

◦ Targets testing by treating it as a risk, which has to be

addressed.

◦ Maintenance is just another phase of the spiral model.

It
is treated in the same way as development.

◦ Estimates (budget and schedule) get more realistic as

work progresses, because important issues are
discovered earlier.
Disadvantages

◦ Only intended for internal projects (inside a company),

because risk is assessed as the project is developed.

◦ In case of external software development, all risk

analysis must be performed by both client and
developers before the contract is signed

◦ Spiral model is risk driven. Therefore it requires

knowledgeable staff.
◦
◦ Suitable for only large scale software
development.
Group of software development methodologies
based on iterative and incremental development

Requirements and solutions evolve through

collaboration between self organizing, cross
functional teams

Introduced in 2001

It’s a light weight as a reaction against the heavy

weight methods
SCRUM (1995
Crystal clear )
Extreme Programming (1996
Adaptive software development )
Feature driven development
Dynamic system development method
(1995)
Open source software development
SCRUM (1995
Crystal clear )
Extreme Programming (1996
Adaptive software development )
Feature driven development
Dynamic system development method
(1995)
Open source software development
Agile Manifesto
◦ We are uncovering better ways of developing
software by doing it and helping other to do

Agile Values
◦ Individuals & interactions over process &
tools
◦ Working software over comprehensive
documentation
◦ Customer collaboration over contract
negotiation
◦ Responding to change over following a plan
Agile Principles

Customer satisfaction by rapid

delivery of useful software
Agile Principles

Welcome changing requirements

even late in development
 Agile Principles

Working software is the

principal measure of
progress
Agile Principles

Daily cooperation between

business people & developers
 Agile Principles

Face to Face conversation

is the best form of
communication
Agile Principles

Self-organized team that have

motivated and trusted individuals
BREAK 5-10 MINUTES
Characteristics
◦ Break tasks into small increments with minimal planning

◦ Iteration are short time frames from (1  4) weeks

◦ Each iteration involves a team working through a full

software development cycle

◦ By the end of the iteration a demo will be represented to

stack holders

◦ One iteration may not add enough feature to market

release but the goal is to have a release with minimal
bugs
Characteristics
◦ Team is usually cross functional and self organizing

◦ Team member take the responsibility of the task

◦ Face-to-face conversation for team in the same

location and video for different locations that
produce less written documents

◦ All team working in an open office called

(bullpen)

◦ Small team size from (5  9) person

Characteristics
◦ Each team have a customer representative to
answer mid iteration problems

◦ By the end of the iteration stockholders view demo

and re evaluate the priorities of features

◦ Formal daily face to face communications to answer

three questions (what they did the previous day?
What they intend to do today? What their road
blocks?)
Techniques to improve the quality and agility
of project like:

◦ Unit test
◦ Pair programming
◦ Test driven Development
◦ Domain Driven Design
◦ Code refactoring
Its one of the agile development methods

It’s the skeleton that includes a set of

practices and predefined roles
In short, scrum is a framework for effective
collaborations among teams working on
complex products. Scrum is a type of agile
technology that consists of meetings, roles,
and tools to help teams working on complex
projects collaborate and better structure and
manage their workload.
 SCRUM Roles

Pig Chicken

Product SCRUM
Team Users Managers Stockholders
Owner Master
Pig role
◦ The ones committed to the project in the scrum
process

Chicken role
◦ Not a part of the scrum process but must be taken
into account
Product Owner
◦ Represent the voice of the customer

◦ Ensure that the scrum teams works with the write

things from a business perspective

◦ Write user stories, prioritize them and add them

to
product backlog
SCRUM Master
◦ Help the team to deliver the sprint goal

◦ Is not the leader of the team but he is self organizer

◦ Ensure that the SCRUM process is used as intended

◦ He is the enforcer of rules

Team
◦ Deliver the project

◦ Made up of (5  9) people with cross functional to

do the actual work (Developers, Designers, Testers)
Users
◦ The users of the product, and his participation is
very important for feedback to review and plan
sprint

Stockholders
◦ The people who enable the project and the are
important in sprint review

Managers
◦ People who will set up the environment for
the
product
User Requirements Product Product
Owner
backlog

Meeting
Sprint
backlog
Team
Sprint
◦ (2  4) week period and it is decided by team

◦ In the sprint the team create an increment of usable

software

◦ During the sprint no one can change the sprint

backlog
Product Backlog
◦ High level document of the entire project that
include a broad description of all required
features and wish list items

◦ Prioritized by business value of each feature

◦ Editable by anyone

◦ Contains rough estimates of both business

value (product owner )and development effort
(team members)
Burn down
◦ The burn down chart is publically showing
remaining work in the sprint backlog

◦ Updated every day

◦ Give a simple view of the sprint progress

Sprint Backlog
◦ Features are broken down into tasks

◦ Best practice that tasks are normally estimated

between 4h and 16h

◦ The whole team understand exactly the

business
logic of each task

◦ Any one them can pick task from task list, tasks in
the task list are never assigned
 SCRUM
Meetings

Sprint
Daily SCRUM Sprint review Sprint
Planning
Meeting meeting Retrospective

meeting
Daily SCRUM Meeting

◦ Project status meeting

◦ Starts precisely on time. And there is a punishment for

late

◦ All are welcomed but only pig may speak

◦ The meeting is between (15 - 20) minutes

◦ All attendees should stand to make it short

◦ Happen in the same time, same location every day

Daily SCRUM Meeting

◦ Every one should answer three questions

🞄 What have you done since yesterday?

🞄 What are you planning to do today?

🞄 Do you have any problem preventing you from

accomplish your goal?
Sprint Planning Meeting
◦ Hold at the beginning of each sprint

◦ Decide what work is to be done

◦ Prepare the sprint backlog

◦ 8 hour limits
Sprint review meeting
◦ Hold at the end of the sprint

◦ Review the complete and incomplete work

◦ Present the completed work to stockholders

◦ 4 hour limits
Sprint Retrospective meeting
◦ All team members reflects on the past sprint

◦ Every member should answer

🞄 What went well during the sprint?
🞄 What could be improved in the next sprint
Intended to improve software quality and responsiveness to
changing customer requirements

Intended to improve productivity and introduce checkpoints

where new customer requirements can be adopted

Programming in pairs or doing extensive code review

Unit testing of all code (End of day testing)

Avoiding programming of features until they are actually

needed

Simplicity and clarity in code

Expecting changes in the customer's requirements

Frequent communication with the customer and among

programmers
Concepts

◦ Organizes people to produce higher quality

software more productively

◦ Attempts to reduce the cost of change by having

multiple short development cycles, rather than one
long one

◦ Introduces a number of basic values, principles and

practices on top of the agile programming
framework
 Activities

Coding Testing Listening Designing

Coding
◦ Software instructions a computer can interpret. Without
code, there is no working product

◦ Coding can also be used to figure out the most suitable

solution

◦ Coding can also help to communicate thoughts about

programming problems

◦ Code must be always clear and concise and cannot be

interpreted in more than one way

◦ Other programmers can give feedback on this code

by
also coding their thoughts
Testing
◦ if a little testing can eliminate a few flaws, a lot of
testing can eliminate many more flaws

◦ Unit tests
🞄 determine whether a given feature works as
intended.
🞄 writes as many automated tests as they can
think of that
might "break" the code
🞄 if all tests run successfully, then the coding is
complete.

◦ Acceptance tests
🞄 verify that the requirements as understood by
the
programmers satisfy the customer's actual
requirements.
Designing

◦ The system becomes too complex and the

dependencies within the system cease to be clear

◦ Avoid this by creating a design structure that

organizes the logic in the system

◦ Good design will avoid lots of dependencies within

a system
Listening

◦ Programmers must listen to what the customers

need the system to do

◦ They must understand business logic needs well

enough to give the customer feedback about
the technical aspects of how the problem might
be solved
 Communication

Simplicity

Feedback

Values

Courage

Respect

Rules
Communication

◦ This task is accomplished through documentation

◦ The goal is to give all developers a shared view of

the system which matches the view held by the
users of the system

◦ extreme programming favors simple designs,

common metaphors, collaboration of users and
programmers, frequent verbal communication, and
feedback
 Simplicity

◦ Encourages starting with the simplest solution

◦ the focus on designing and coding for the needs of today

instead of those of tomorrow, next week, or next month

◦ This is sometimes summed up as the

(YAGNI) approach

◦ Coding and designing for uncertain

future requirements
implies the risk of spending resources on something that
might not be needed

◦ A simple design with very simple code could be easily

understood by most programmers in the team
Feedback

◦ Feedback from the system: by writing unit tests or

running periodic integration tests

◦ Feedback from the customer: The functional tests

(acceptance tests) are written by the customer and
the testers

◦ Feedback from the team: When customers come up

with new requirements the team directly gives an
estimation of the time that it will take to implement
Courage

◦ Courage enables developers to feel comfortable

with refactoring their code when necessary

◦ This means reviewing the existing system and

modifying it so that future changes can be
implemented more easily

◦ courage to remove source code that is obsolete, no

matter how much effort was used to create that
source code
Respect

◦ The respect value includes respect for others as

well as self-respect

◦ Programmers should never commit changes that

break compilation, that make existing unit-tests
fail, or that otherwise delay the work of their
peers

◦ Members respect their own work by always striving

for high quality and seeking for the best design
for the solution at hand through refactoring
Rules

◦ Business people and developers do joint work

◦ Our highest priority is customer satisfaction
◦ Deliver working software frequently
◦ Working software
◦ Global awareness
◦ The team must act as an effective social network