Waterfall1. History of water fall model.2. Features of water fall model.3. Phase of water fall model.4. Brief description ...
History of waterfall1)The first formal description of the waterfall model isoften cited as a 1970 article by Winston W. Ro...
Features of waterfall model1. A Water Fall Model is easy to flow.2. It can be implemented for any size of project.3. Every...
Waterfall model
Phases of waterfall modelWaterfall model has 5 different phases, Which arefollowing.1. Requirement gathering and Analysis....
Brief description of phase1) Requirement gathering andAnalysis. This is the first phase of waterfall model which includes...
Brief description of phase Requirement gathering and Analysisphase the basic requirements of thesystem must be understood...
Brief description of phase2) Design. The customer requirements are broken down into logicalmodules for the ease of implem...
Brief description of phaseIt is a intermediate step between requirementsanalysis and coding.Design focuses on program att...
Brief description of phase3) Coding. Coding is a step in which design is translated into machine-readable form. If desig...
Brief description of phase4) Testing. In this stage, both individual components and theintegrated whole are methodically ...
Brief description of phase5) Maintenance. This is the final phase of the waterfall model, in which thecompleted software ...
Brief description of phaseThe usually the longest stage of the software. In thisphase the software is updated to:a) Meet...
Advantages of waterfall model The water fall model is easy to implementation.For implementation of small systems water f...
Disadvantages of waterfall model The requirement analysis is done initially and sometimes it isnot possible to state all ...
Spiral model
•The spiral model was defined by Barry Boehm in1988 .•It was not the first model to discuss iterativedevelopment, but it w...
When to use The spiral Model• The user has experience to refine therequirements .• Some parts of the implementation maydep...
Spiral Model VS Waterfall Model• Risk factor is considered in the Spiral Model butin water fall Model it is not considered...
Spiral Model VS prototype model• number of phases of spiral model is not fixed-whereas in prototype model number of phases...
Quadrant 1: Determine objectives,alternatives, and constraints:Spiral Model DescriptionObjectives: performance,hardware/so...
Quadrant 2: Evaluate alternatives,identify, resolve risks:The focus here is on risk study.Each alternative isinvestigated ...
Quadrant 3: Develop, verify, next-levelproduct.Typical activities Create a design Review design Develop code Inspect c...
Quadrant 4: Plan next phases.Typical activities• Develop project plan• Develop configuration managementplan• Develop a tes...
Summary of Spiral steps:• Each successive phase in the project as a new spiral includes afour steps or phases.• Software r...
Advantages• Provides early indication of insurmountable risks, withoutmuch cost• Users see the system early because of rap...
Disadvantages Time spent for evaluating risks too large for small orlow-risk projects Time spent planning, resetting obj...
Scrum
• Scrum is an agile process that allows us to focus ondelivering the highest business value in the shortest time.• It allo...
Scrum has been used by:•Microsoft•Yahoo•Google•Electronic Arts•High Moon Studios•Lockheed Martin•Philips•Siemens•Nokia•Cap...
Scrum has been used for:Commercial softwareIn-house developmentContract developmentFixed-price projectsFinancial applicati...
CharacteristicsSelf-organizing teamsProduct progresses in a series of month-long “sprints”Requirements are captured as ite...
ScrumCancelGift wrapReturnSprint2-4 weeksReturnSprint goalSprintbacklogPotentially shippableproduct incrementProductbacklo...
Putting it all together
Sprints• Scrum projects make progress in a series of“sprints”• Analogous to Extreme Programming iterations• Typical durati...
No changes during a sprint• Plan sprint durations around how long you can committo keeping change out of the sprintChange
Scrum framework•Product owner•ScrumMaster•TeamRoles•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting...
Scrum framework•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meetingCeremonies•Product backlog•Sprint ba...
Product owner• Define the features of the product• Decide on release date and content• Be responsible for the profitabilit...
The ScrumMaster• Represents management to the project• Responsible for enacting Scrum valuesand practices• Removes impedim...
The team• Typically 5-9 people• Cross-functional:• Programmers, testers, user experiencedesigners, etc.• Members should be...
The team• Teams are self-organizing• Ideally, no titles but rarely a possibility• Membership should change only betweenspr...
•Product owner•ScrumMaster•TeamRolesScrum framework•Product backlog•Sprint backlog•Burndown chartsArtifacts•Sprint plannin...
Sprint planning• Team selects items from the product backlogthey can commit to completing• Sprint backlog is created• Task...
The daily scrum• Parameters• Daily• 15-minutes• Stand-up• Not for problem solving• Whole world is invited• Only team membe...
Everyone answers 3questions• These are not status for the ScrumMaster• They are commitments in front of peersWhat did you ...
The sprint demo• Team presents what it accomplished during thesprint• Typically takes the form of a demo of newfeatures or...
Sprint retrospective• Periodically take a look at what is and is not working• Typically 15–30 minutes• Done after every sp...
•Product owner•ScrumMaster•TeamRolesScrum framework•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting...
Product backlog• The requirements• A list of all desired work onthe project• Ideally expressed suchthat each item has valu...
A sample product backlogBacklog item EstimateAllow a guest to make a reservation 3As a guest, I want to cancel areservatio...
A sprint burndown chartHours
Prototyping
System prototyping• Prototyping is the rapid development of a system• In the past, the developed system was normallythough...
Prototyping benefits• Misunderstandings between software users anddevelopers are exposed• Missing services may be detected...
Prototyping benefits• Improved system usability• Closer match to the system needed• Improved design quality• Improved main...
Prototyping in the softwareprocess• Evolutionary prototyping• An approach to system development where an initialprototype ...
Evolutionary prototypingBuild prototypesystemDevelop abstractspecificationUse prototypesystemDeliversystemSystemadequate?Y...
Evolutionary prototyping advantages• Accelerated delivery of the system• Rapid delivery and deployment are sometimes morei...
Throw-away prototyping• Used to reduce requirements risk• The prototype is developed from an initialspecification, deliver...
Throw-away prototypingOutlinerequirementsDevelopprototypeEvaluateprototypeSpecifysystemDevelopsoftwareValidatesystemDelive...
Key points• A prototype can be used to give end-users a concreteimpression of the system’s capabilities• Prototyping is be...
Key points• Rapid development of prototypes is essential. Thismay require leaving out functionality or relaxing non-functi...
Any Questions?
Software cycles
Software cycles
Software cycles
Software cycles
Upcoming SlideShare
Loading in …5
×

Software cycles

1,209 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,209
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software cycles

  1. 1. Waterfall1. 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.
  2. 2. History of waterfall1)The first formal description of the waterfall model isoften cited as a 1970 article by Winston W. Royce2)Royce did not use the term "waterfall" in this article.3)Royce presented this model as an example of aflawed, non-working model.
  3. 3. Features of waterfall model1. 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 righttime so you cannot jump stages.4. Documentation is produced at every stage of awaterfall model allowing people to understandwhat has been done.5. Testing is done at every stage.
  4. 4. Waterfall model
  5. 5. Phases of waterfall modelWaterfall model has 5 different phases, Which arefollowing.1. Requirement gathering and Analysis.2. Design.3. Coding.4. Testing.5. Maintenance.
  6. 6. Brief description of phase1) Requirement gathering andAnalysis. This is the first phase of waterfall model which includes ameeting with the customer to understand his requirements. This is the most crucial phase as any misinterpretation atthis stage may give rise to validation issues later. The software definition must be detailed and accurate withno ambiguities. It is very important to understand the customerrequirements and expectations so that the end productmeets his specifications.
  7. 7. Brief description of phase Requirement gathering and Analysisphase the basic requirements of thesystem must be understood by softwareengineer, who is also called ANALYST. All this requirements are then welldocumented and discussed further withthe customer for reviewing.
  8. 8. Brief description of phase2) Design. The customer requirements are broken down into logicalmodules for the ease of implementation. Hardware andsoftware requirements for every module are Identifiedand designed accordingly. Also the inter relation between the various logicalmodules is established at this stage. Algorithms anddiagrams defining the scope and objective of each logicalmodel are developed. In short, this phase lays a fundamental for actualprogramming and implementation
  9. 9. Brief description of phaseIt is a intermediate step between requirementsanalysis and coding.Design focuses on program attribute such as-1) Data Structure.2) Software Architecture.3) Algorithm Detailsetc…….The requirements are translated in some easy torepresent form using which coding can be doneeffectively and efficiently.The design needs to be documented for further use.
  10. 10. Brief description of phase3) 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. Programsare created in this phase. In this phase all software divided into small module then after doing coding for thatsmall module rather than do coding whole software. According to design programmers do code and make class and structure of wholesoftware.
  11. 11. Brief description of phase4) Testing. In this stage, both individual components and theintegrated whole are methodically verified to ensure thatthey are error-free and fully meet the requirementsoutlined in the first step. In this phase testing whole software into two parts 1)HARDWARE & 2) SOFTWARE. Type of testing is 2-types1) Inside test.2) Outside test.
  12. 12. Brief description of phase5) Maintenance. This is the final phase of the waterfall model, in which thecompleted software product is handed over to the client afteralpha, beta testing. After the software has been deployed on the client site, it is theduty of the software development team to undertake routinemaintenance activities by visiting the client site. If the customer suggests changes or enhancements thesoftware process has to be followed all over again right fromthe first phase i.e requirement analysis.
  13. 13. Brief description of phaseThe usually the longest stage of the software. In thisphase the software is updated to:a) Meet the changing customer needsb) Adapted to accommodate changes in the externalenvironmentc) Correct errors and oversights previouslyundetected in the testing phasesd) Enhancing the efficiency of the softwareObserve that feed back loops allow for correctionsto be incorporated into the model.
  14. 14. Advantages of waterfall model The water fall model is easy to implementation.For implementation of small systems water fallmodel is use full.The project requires the fulfillment of one phase,before proceeding to the next.It is easier to develop various software through thismethod in short span of time.
  15. 15. Disadvantages of waterfall model The requirement analysis is done initially and sometimes it isnot possible to state all the requirement explicitly in thebeginning. The customer can see working model of the project only atthe end. If we want to go backtrack then it is not possible in this model. It is difficult to follow the sequential flow in softwaredevelopment process.
  16. 16. Spiral model
  17. 17. •The spiral model was defined by Barry Boehm in1988 .•It was not the first model to discuss iterativedevelopment, but it was the first model to explainwhy the iteration matters.•the iterations were typically 6 months to 2 yearslong.History
  18. 18. When to use The spiral Model• The user has experience to refine therequirements .• Some parts of the implementation maydepend on future technology• New user requirements are anticipated butnot yet known• Some user requirements may be significantlymore difficult to meet than others, and it isdecided not to allow them to delay a usabledelivery
  19. 19. Spiral Model VS Waterfall Model• Risk factor is considered in the Spiral Model butin water fall Model it is not considered.• In Waterfall the requirements are freezed butthis not happens in the Spiral Model.• Waterfall Model is linear sequential modelwhere Spiral Model works in loop.• Spiral Model is costly as Risk factor is covered.• In spiral model there is a better communicationbetween developer and customer.
  20. 20. Spiral Model VS prototype model• number of phases of spiral model is not fixed-whereas in prototype model number of phasesis fixed .• Risk factor is considered in the Spiral Model butin water fall Model it is not considered• Spiral model includes many prototype models• Spiral model is used when requirement is notclear and needs conformation while in prototypemodel requirement is clear but complex• In spiral model customer interaction continousto move together. in other hand prototype modelcustomer interaction needs till the prototype is
  21. 21. Quadrant 1: Determine objectives,alternatives, and constraints:Spiral Model DescriptionObjectives: 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, Quadrant2 (Evaluate alternatives, identify, andresolve risks) is performed
  22. 22. Quadrant 2: Evaluate alternatives,identify, resolve risks:The focus here is on risk study.Each alternative isinvestigated and prototypedto reduce the risk associatedwith the developmentdecisions• Study alternatives relative toobjectives and constraints• Identify risks (lack ofexperience, new technology,tight schedules, poor process,etc.• Resolve risks (evaluate if moneycould be lost by continuingsystem development
  23. 23. Quadrant 3: Develop, verify, next-levelproduct.Typical activities Create a design Review design Develop code Inspect code Test product
  24. 24. Quadrant 4: Plan next phases.Typical activities• Develop project plan• Develop configuration managementplan• Develop a test plan• Develop an installation plan
  25. 25. Summary of Spiral steps:• Each successive phase in the project as a new spiral includes afour steps or phases.• Software requirements in the design are gradually developedthrough a series of prototypes.• The exact number of spirals necessary for the project isflexible and depends on the number of prototypes needed toreach a satisfactory design.• Since each face requires a certain level of commitment acumulative cost of the project represented by the width of thespiral• Once a satisfactory design is reached the software isconstructed according the final three process of the waterfallmodel (Programming – Integration-Delivery)
  26. 26. Advantages• Provides early indication of insurmountable risks, withoutmuch cost• Users see the system early because of rapid prototypingtools• 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
  27. 27. Disadvantages Time spent for evaluating risks too large for small orlow-risk projects Time spent planning, resetting objectives, doing riskanalysis 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 milestonesthat indicate readiness to proceed through the nextiteration
  28. 28. Scrum
  29. 29. • Scrum is an agile process that allows us to focus ondelivering the highest business value in the shortest time.• It allows us to rapidly and repeatedly inspect actualworking software (every two weeks to one month).• The business sets the priorities. Teams self-organize todetermine the best way to deliver the highest priorityfeatures.• Every two weeks to a month anyone can see real workingsoftware and decide to release it as is or continue toenhance it for another sprint.Scrum in 100 words
  30. 30. 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
  31. 31. Scrum has been used for:Commercial softwareIn-house developmentContract developmentFixed-price projectsFinancial applicationsISO 9001-certifiedapplicationsEmbedded systems24x7 systems with 99.999%uptime requirementsthe Joint Strike FighterVideo game developmentFDA-approved, life-criticalsystemsSatellite-control softwareWebsitesHandheld softwareMobile phonesNetwork switching applicationsISV applicationsSome of the largest applications inuse
  32. 32. CharacteristicsSelf-organizing teamsProduct progresses in a series of month-long “sprints”Requirements are captured as items in alist of “product backlog”No specific engineering practicesprescribedUses generative rules to create an agileenvironment for delivering projectsOne of the “agile processes”
  33. 33. ScrumCancelGift wrapReturnSprint2-4 weeksReturnSprint goalSprintbacklogPotentially shippableproduct incrementProductbacklogCouponsGift wrapCouponsCancel24 hours
  34. 34. Putting it all together
  35. 35. Sprints• Scrum projects make progress in a series of“sprints”• Analogous to Extreme Programming iterations• Typical duration is 2–4 weeks or a calendar monthat most• A constant duration leads to a better rhythm• Product is designed, coded, and tested during thesprint
  36. 36. No changes during a sprint• Plan sprint durations around how long you can committo keeping change out of the sprintChange
  37. 37. Scrum framework•Product owner•ScrumMaster•TeamRoles•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meetingCeremonies•Product backlog•Sprint backlog•Burndown chartsArtifacts
  38. 38. Scrum framework•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meetingCeremonies•Product backlog•Sprint backlog•Burndown chartsArtifacts•Product owner•ScrumMaster•TeamRoles
  39. 39. 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, asneeded• Accept or reject work results
  40. 40. The ScrumMaster• Represents management to the project• Responsible for enacting Scrum valuesand practices• Removes impediments• Ensure that the team is fully functionaland productive• Enable close cooperation across allroles and functions• Shield the team from externalinterferences
  41. 41. The team• Typically 5-9 people• Cross-functional:• Programmers, testers, user experiencedesigners, etc.• Members should be full-time• May be exceptions (e.g., database administrator)
  42. 42. The team• Teams are self-organizing• Ideally, no titles but rarely a possibility• Membership should change only betweensprints
  43. 43. •Product owner•ScrumMaster•TeamRolesScrum framework•Product backlog•Sprint backlog•Burndown chartsArtifacts•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meetingCeremonies
  44. 44. Sprint planning• Team selects items from the product backlogthey can commit to completing• Sprint backlog is created• Tasks are identified and each is estimated (1-16hours)• Collaboratively, not done alone by the ScrumMaster• High-level design is consideredAs a vacation planner, I wantto 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)
  45. 45. The daily scrum• Parameters• Daily• 15-minutes• Stand-up• Not for problem solving• Whole world is invited• Only team members, ScrumMaster, product owner, cantalk• Helps avoid other unnecessary meetings
  46. 46. Everyone answers 3questions• These are not status for the ScrumMaster• They are commitments in front of peersWhat did you do yesterday?1What will you do today?2Is anything in your way?3
  47. 47. The sprint demo• Team presents what it accomplished during thesprint• Typically takes the form of a demo of newfeatures or underlying architecture• Informal• 2-hour prep time rule• No slides• Whole team participates• Invite the world
  48. 48. 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
  49. 49. •Product owner•ScrumMaster•TeamRolesScrum framework•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meetingCeremonies•Product backlog•Sprint backlog•Burndown chartsArtifacts
  50. 50. Product backlog• The requirements• A list of all desired work onthe project• Ideally expressed suchthat each item has valueto the users or customersof the product• Prioritized by the productowner• Reprioritized at the start ofeach sprintThis is theproduct backlog
  51. 51. A sample product backlogBacklog item EstimateAllow a guest to make a reservation 3As a guest, I want to cancel areservation.5As a guest, I want to change the dates ofa reservation.3As a hotel employee, I can run RevPARreports (revenue-per-available-room)8Improve exception handling 8... 30... 50
  52. 52. A sprint burndown chartHours
  53. 53. Prototyping
  54. 54. System prototyping• Prototyping is the rapid development of a system• In the past, the developed system was normallythought of as inferior in some way to the requiredsystem so further development was required• Now, the boundary between prototyping and normalsystem development is blurred and many systems aredeveloped using an evolutionary approach
  55. 55. Prototyping benefits• Misunderstandings between software users anddevelopers are exposed• Missing services may be detected and confusingservices may be identified• A working system is available early in the process• The prototype may serve as a basis for deriving asystem specification• The system can support user training and systemtesting
  56. 56. Prototyping benefits• Improved system usability• Closer match to the system needed• Improved design quality• Improved maintainability• Reduced overall development effort
  57. 57. Prototyping in the softwareprocess• Evolutionary prototyping• An approach to system development where an initialprototype is produced and refined through a number ofstages to the final system• Throw-away prototyping• A prototype which is usually a practical implementationof the system is produced to help discover requirementsproblems and then discarded. The system is thendeveloped using some other development process
  58. 58. Evolutionary prototypingBuild prototypesystemDevelop abstractspecificationUse prototypesystemDeliversystemSystemadequate?YESN
  59. 59. Evolutionary prototyping advantages• Accelerated delivery of the system• Rapid delivery and deployment are sometimes moreimportant than functionality or long-term softwaremaintainability• User engagement with the system• Not only is the system more likely to meet userrequirements, they are more likely to commit to the useof the system
  60. 60. Throw-away prototyping• Used to reduce requirements risk• The prototype is developed from an initialspecification, delivered for experiment then discarded• The throw-away prototype should not be consideredas 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 tomaintain
  61. 61. Throw-away prototypingOutlinerequirementsDevelopprototypeEvaluateprototypeSpecifysystemDevelopsoftwareValidatesystemDeliveredsoftwaresystemReusablecomponents
  62. 62. Key points• A prototype can be used to give end-users a concreteimpression of the system’s capabilities• Prototyping is becoming increasingly used for systemdevelopment where rapid development is essential• Throw-away prototyping is used to understand thesystem requirements• In evolutionary prototyping, the system is developedby evolving an initial version to the final version
  63. 63. Key points• Rapid development of prototypes is essential. Thismay require leaving out functionality or relaxing non-functional constraints• Prototyping techniques include the use of very high-level languages, database programming and prototypeconstruction from reusable components• Prototyping is essential for parts of the system such asthe user interface which cannot be effectively pre-specified. Users must be involved in prototypeevaluation
  64. 64. Any Questions?

×