Breaking the Kubernetes Kill Chain: Host Path Mount
Software cycles
1.
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.
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.
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
19.
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
23.
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
27. Quadrant 4: Plan next phases.
Typical activities
• Develop project plan
• Develop configuration management
plan
• Develop a test plan
• Develop an installation plan
28.
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
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”
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
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
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
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
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
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
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
