a s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s

1. By: Amira Elsayed Ismail

2.  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

3.  Software Development process (lifecycle)
◦ Is a structure imposed on the development
of a software product
Requirements
specification
Analyses and
Design
Implementation
Testing
Deployment
Maintenance

4. Software Development Process
Traditional
Waterfall
Incremental
iterative
Spiral
Agile
SCRUM
Extreme
programming

5.  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

6.  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

7.  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)

8.  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)

9.  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

10. Requirement
specification
Design
Construction
(Implementation)
Integration
Testing &
Debugging
Installation
Maintenance
 Waterfall Model Phases :

11. 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

12.  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

13.  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

14.  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

15.  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

16.  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

17. Planning
Requirements
Analysis &
design
Implementation
Testing
Evaluation
Initial Planning
Deployment

18.  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

19. •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 a
simple solution easily to understand and implement
Initialization
Step
•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
Project
Control List
•Redesign and implement of tasks from the control list and
analyses the current system
•The goal of any iteration is to be (simple, straight forward,
modular and supporting redesign)
Iteration Step

20. 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

21. •Identify project scope, risks, requirements (functional and non
functional), at a high level with enough details to be able to
estimate
Inception
•Deliver a working architecture that mitigates the top risks and
fulfills the non functional requirements
Elaboration
•Fills in the architecture with production ready code produced from
analysis, design, implementation and testing
Construction
•Delivers the system into the production operating system
Transition

22. Waterfall
Complete each step before
moving to the next step
Business value is delivered
all at once
Backtracking means waste
in time, effort, money
Iterative Incremental
Backtracking is possible

23.  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

24.  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

26.  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

27.  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

28.  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.

29.  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.

30.  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

31.  SCRUM (1995)
 Crystal clear
 Extreme Programming (1996)
 Adaptive software development
 Feature driven development
 Dynamic system development method (1995)
 Open source software development

32.  SCRUM (1995)
 Crystal clear
 Extreme Programming (1996)
 Adaptive software development
 Feature driven development
 Dynamic system development method (1995)
 Open source software development

33.  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

34.  Agile Principles
Customer satisfaction by rapid
delivery of useful software

35.  Agile Principles
Welcome changing requirements
even late in development

36.  Agile Principles
Working software is the
principal measure of
progress

37.  Agile Principles
Daily cooperation between
business people & developers

38.  Agile Principles
Face to Face conversation
is the best form of
communication

39.  Agile Principles
Self-organized team that have
motivated and trusted individuals

40.  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

41.  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

42.  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?)

43.  Techniques to improve the quality and agility
of project like:
◦ Unit test
◦ Pair programming
◦ Test driven Development
◦ Domain Driven Design
◦ Code refactoring

44.  Its one of the agile development methods
 It’s the skeleton that includes a set of
practices and predefined roles

45. SCRUM Roles
Pig
Product
Owner
SCRUM
Master
Team
Chicken
Users Managers Stockholders

46.  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

47.  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

48.  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

49.  Team
◦ Deliver the project
◦ Made up of (5  9) people with cross functional to
do the actual work (Developers, Designers, Testers)

50.  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

51. User Requirements Product
Owner
Product
backlog
Meeting
Sprint
backlog
Team

52.  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

53.  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)

54.  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

55.  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

56. SCRUM
Meetings
Daily SCRUM
Meeting
Sprint
Planning
meeting
Sprint review
meeting
Sprint
Retrospective

57.  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

58.  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?

59.  Sprint Planning Meeting
◦ Hold at the beginning of each sprint
◦ Decide what work is to be done
◦ Prepare the sprint backlog
◦ 8 hour limits

60.  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

61.  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

62.  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

64.  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

65. Activities
Coding Testing Listening Designing

66.  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

67.  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.

68.  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

69.  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

70. Values
Communication
Simplicity
Feedback
Courage
Respect
Rules

71.  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

72.  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

73.  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

74.  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

75.  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

76.  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