The document provides details about the waterfall model of software development. It discusses the history and key phases of the waterfall model including requirement gathering and analysis, design, coding, testing, and maintenance. It also outlines the advantages and disadvantages of the waterfall model such as it being easy to implement but inflexible to changes. Overall, the document gives an overview of the waterfall model software development lifecycle.

2. Waterfall
1. History of water fall model.
2. Features of water fall model.
3. Phase of water fall model.
4. Brief description of phases.
5. Advantages.
6. Disadvantages.

3. History of waterfall
1)The first formal description of the waterfall model is
often cited as a 1970 article by Winston W. Royce
2)Royce did not use the term "waterfall" in this article.
3)Royce presented this model as an example of a
flawed, non-working model.

4. Features of waterfall model
1. A Water Fall Model is easy to flow.
2. It can be implemented for any size of project.
3. Every stage has to be done separately at the right
time so you cannot jump stages.
4. Documentation is produced at every stage of a
waterfall model allowing people to understand
what has been done.
5. Testing is done at every stage.

5. Waterfall model

6. Phases of waterfall model
Waterfall model has 5 different phases, Which are
following.
1. Requirement gathering and Analysis.
2. Design.
3. Coding.
4. Testing.
5. Maintenance.

7. Brief description of phase
1) Requirement gathering and
Analysis.
 This is the first phase of waterfall model which includes a
meeting with the customer to understand his requirements.
 This is the most crucial phase as any misinterpretation at
this stage may give rise to validation issues later.
 The software definition must be detailed and accurate with
no ambiguities.
 It is very important to understand the customer
requirements and expectations so that the end product
meets his specifications.

8. Brief description of phase
 Requirement gathering and Analysis
phase the basic requirements of the
system must be understood by software
engineer, who is also called ANALYST.
 All this requirements are then well
documented and discussed further with
the customer for reviewing.

9. Brief description of phase
2) Design.
 The customer requirements are broken down into logical
modules for the ease of implementation. Hardware and
software requirements for every module are Identified
and designed accordingly.
 Also the inter relation between the various logical
modules is established at this stage. Algorithms and
diagrams defining the scope and objective of each logical
model are developed.
 In short, this phase lays a fundamental for actual
programming and implementation

10. Brief description of phase
It is a intermediate step between requirements
analysis and coding.
Design focuses on program attribute such as-
1) Data Structure.
2) Software Architecture.
3) Algorithm Details
etc…….
The requirements are translated in some easy to
represent form using which coding can be done
effectively and efficiently.
The design needs to be documented for further use.

11. Brief description of phase
3) Coding.
 Coding is a step in which design is translated into machine-readable form.
 If design is done in sufficient detail then coding can be done effectively. Programs
are created in this phase.
 In this phase all software divided into small module then after doing coding for that
small module rather than do coding whole software.
 According to design programmers do code and make class and structure of whole
software.

12. Brief description of phase
4) Testing.
 In this stage, both individual components and the
integrated whole are methodically verified to ensure that
they are error-free and fully meet the requirements
outlined in the first step.
 In this phase testing whole software into two parts 1)
HARDWARE & 2) SOFTWARE.
 Type of testing is 2-types
1) Inside test.
2) Outside test.

13. Brief description of phase
5) Maintenance.
 This is the final phase of the waterfall model, in which the
completed software product is handed over to the client after
alpha, beta testing.
 After the software has been deployed on the client site, it is the
duty of the software development team to undertake routine
maintenance activities by visiting the client site.
 If the customer suggests changes or enhancements the
software process has to be followed all over again right from
the first phase i.e requirement analysis.

14. Brief description of phase
The usually the longest stage of the software. In this
phase the software is updated to:

a) Meet the changing customer needs
b) Adapted to accommodate changes in the external
environment
c) Correct errors and oversights previously
undetected in the testing phases
d) Enhancing the efficiency of the software
Observe that feed back loops allow for corrections
to be incorporated into the model.

15. Advantages of waterfall model
 The water fall model is easy to implementation.
For implementation of small systems water fall
model is use full.
The project requires the fulfillment of one phase,
before proceeding to the next.
It is easier to develop various software through this
method in short span of time.

16. Disadvantages of waterfall model
 The requirement analysis is done initially and sometimes it is
not possible to state all the requirement explicitly in the
beginning.
 The customer can see working model of the project only at
the end.
 If we want to go backtrack then it is not possible in this model.
 It is difficult to follow the sequential flow in software
development process.

17. Spiral model

18. •The spiral model was defined by Barry Boehm in
1988 .
•It was not the first model to discuss iterative
development, but it was the first model to explain
why the iteration matters.
•the iterations were typically 6 months to 2 years
long.
History

20. When to use The spiral Model
• The user has experience to refine the
requirements .
• Some parts of the implementation may
depend on future technology
• New user requirements are anticipated but
not yet known
• Some user requirements may be significantly
more difficult to meet than others, and it is
decided not to allow them to delay a usable
delivery

21. Spiral Model VS Waterfall Model
• Risk factor is considered in the Spiral Model but
in water fall Model it is not considered.
• In Waterfall the requirements are freezed but
this not happens in the Spiral Model.
• Waterfall Model is linear sequential model
where Spiral Model works in loop.
• Spiral Model is costly as Risk factor is covered.
• In spiral model there is a better communication
between developer and customer.

22. Spiral Model VS prototype model
• number of phases of spiral model is not fixed-
whereas in prototype model number of phases
is fixed .
• Risk factor is considered in the Spiral Model but
in water fall Model it is not considered
• Spiral model includes many prototype models
• Spiral model is used when requirement is not
clear and needs conformation while in prototype
model requirement is clear but complex
• In spiral model customer interaction continous
to move together. in other hand prototype model
customer interaction needs till the prototype is

24. Quadrant 1: Determine objectives,
alternatives, and constraints:
Spiral Model Description
Objectives: performance,
hardware/software interface , functionality,
etc.
Alternatives: design, reuse, buy, etc.
constraints : imposed on technology, cost,
schedule, support, and risk.
Once the system„s objectives, alternatives,
and constraints are understood, Quadrant
2 (Evaluate alternatives, identify, and
resolve risks) is performed

25. Quadrant 2: Evaluate alternatives,
identify, resolve risks:
The focus here is on risk study.
Each alternative is
investigated and prototyped
to reduce the risk associated
with the development
decisions
• Study alternatives relative to
objectives and constraints
• Identify risks (lack of
experience, new technology,
tight schedules, poor process,
etc.
• Resolve risks (evaluate if money
could be lost by continuing
system development

26. Quadrant 3: Develop, verify, next-level
product.
Typical activities
 Create a design
 Review design
 Develop code
 Inspect code
 Test product

27. Quadrant 4: Plan next phases.
Typical activities
• Develop project plan
• Develop configuration management
plan
• Develop a test plan
• Develop an installation plan

29. Summary of Spiral steps:
• Each successive phase in the project as a new spiral includes a
four steps or phases.
• Software requirements in the design are gradually developed
through a series of prototypes.
• The exact number of spirals necessary for the project is
flexible and depends on the number of prototypes needed to
reach a satisfactory design.
• Since each face requires a certain level of commitment a
cumulative cost of the project represented by the width of the
spiral
• Once a satisfactory design is reached the software is
constructed according the final three process of the waterfall
model (Programming – Integration-Delivery)

30. Advantages
• Provides early indication of insurmountable risks, without
much cost
• Users see the system early because of rapid prototyping
tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently

31. Disadvantages
 Time spent for evaluating risks too large for small or
low-risk projects
 Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-
development phase activities
 May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration

32. Scrum

33. • Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to
determine the best way to deliver the highest priority
features.
• Every two weeks to a month anyone can see real working
software and decide to release it as is or continue to
enhance it for another sprint.
Scrum in 100 words

34. Scrum has been used by:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce

35. Scrum has been used for:
Commercial software
In-house development
Contract development
Fixed-price projects
Financial applications
ISO 9001-certified
applications
Embedded systems
24x7 systems with 99.999%
uptime requirements
the Joint Strike Fighter
Video game development
FDA-approved, life-critical
systems
Satellite-control software
Websites
Handheld software
Mobile phones
Network switching applications
ISV applications
Some of the largest applications in
use

36. Characteristics
Self-organizing teams
Product progresses in a series of month-
long “sprints”
Requirements are captured as items in a
list of “product backlog”
No specific engineering practices
prescribed
Uses generative rules to create an agile
environment for delivering projects
One of the “agile processes”

37. Scrum
Cancel
Gift wrap
Return
Sprint
2-4 weeks
Return
Sprint goal
Sprint
backlog
Potentially shippable
product increment
Product
backlog
CouponsGift wrap
Coupons
Cancel
24 hours

38. Putting it all together

39. Sprints
• Scrum projects make progress in a series of
“sprints”
• Analogous to Extreme Programming iterations
• Typical duration is 2–4 weeks or a calendar month
at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the
sprint

40. No changes during a sprint
• Plan sprint durations around how long you can commit
to keeping change out of the sprint
Change

41. Scrum framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts

42. Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Product owner
•ScrumMaster
•Team
Roles

43. Product owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product
(ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as
needed
• Accept or reject work results

44. The ScrumMaster
• Represents management to the project
• Responsible for enacting Scrum values
and practices
• Removes impediments
• Ensure that the team is fully functional
and productive
• Enable close cooperation across all
roles and functions
• Shield the team from external
interferences

45. The team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience
designers, etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)

46. The team
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between
sprints

47. •Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies

48. Sprint planning
• Team selects items from the product backlog
they can commit to completing
• Sprint backlog is created
• Tasks are identified and each is estimated (1-16
hours)
• Collaboratively, not done alone by the ScrumMaster
• High-level design is considered
As a vacation planner, I want
to see photos of the hotels. Code the middle tier (8 hours)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)

49. The daily scrum
• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, ScrumMaster, product owner, can
talk
• Helps avoid other unnecessary meetings

50. Everyone answers 3
questions
• These are not status for the ScrumMaster
• They are commitments in front of peers
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3

51. The sprint demo
• Team presents what it accomplished during the
sprint
• Typically takes the form of a demo of new
features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world

52. Sprint retrospective
• Periodically take a look at what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• ScrumMaster
• Product owner
• Team
• Possibly customers and others

53. •Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts

54. Product backlog
• The requirements
• A list of all desired work on
the project
• Ideally expressed such
that each item has value
to the users or customers
of the product
• Prioritized by the product
owner
• Reprioritized at the start of
each sprintThis is the
product backlog

55. A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a
reservation.
5
As a guest, I want to change the dates of
a reservation.
3
As a hotel employee, I can run RevPAR
reports (revenue-per-available-room)
8
Improve exception handling 8
... 30
... 50

56. A sprint burndown chart
Hours

57. Prototyping

58. System prototyping
• Prototyping is the rapid development of a system
• In the past, the developed system was normally
thought of as inferior in some way to the required
system so further development was required
• Now, the boundary between prototyping and normal
system development is blurred and many systems are
developed using an evolutionary approach

59. Prototyping benefits
• Misunderstandings between software users and
developers are exposed
• Missing services may be detected and confusing
services may be identified
• A working system is available early in the process
• The prototype may serve as a basis for deriving a
system specification
• The system can support user training and system
testing

60. Prototyping benefits
• Improved system usability
• Closer match to the system needed
• Improved design quality
• Improved maintainability
• Reduced overall development effort

61. Prototyping in the software
process
• Evolutionary prototyping
• An approach to system development where an initial
prototype is produced and refined through a number of
stages to the final system
• Throw-away prototyping
• A prototype which is usually a practical implementation
of the system is produced to help discover requirements
problems and then discarded. The system is then
developed using some other development process

62. Evolutionary prototyping
Build prototype
system
Develop abstract
specification
Use prototype
system
Deliver
system
System
adequate?
YES
N

63. Evolutionary prototyping advantages
• Accelerated delivery of the system
• Rapid delivery and deployment are sometimes more
important than functionality or long-term software
maintainability
• User engagement with the system
• Not only is the system more likely to meet user
requirements, they are more likely to commit to the use
of the system

64. Throw-away prototyping
• Used to reduce requirements risk
• The prototype is developed from an initial
specification, delivered for experiment then discarded
• The throw-away prototype should not be considered
as a final system
• Some system characteristics may have been left out
• There is no specification for long-term maintenance
• The system will be poorly structured and difficult to
maintain

65. Throw-away prototyping
Outline
requirements
Develop
prototype
Evaluate
prototype
Specify
system
Develop
software
Validate
system
Delivered
software
system
Reusable
components

66. Key points
• A prototype can be used to give end-users a concrete
impression of the system’s capabilities
• Prototyping is becoming increasingly used for system
development where rapid development is essential
• Throw-away prototyping is used to understand the
system requirements
• In evolutionary prototyping, the system is developed
by evolving an initial version to the final version

67. Key points
• Rapid development of prototypes is essential. This
may require leaving out functionality or relaxing non-
functional constraints
• Prototyping techniques include the use of very high-
level languages, database programming and prototype
construction from reusable components
• Prototyping is essential for parts of the system such as
the user interface which cannot be effectively pre-
specified. Users must be involved in prototype
evaluation

68. Any Questions?