Types of software life cycle model

Types of software life cycle model
Classic Waterfall model
Iterative Lifecycle model
Prototyping model

1. Software Engineering Mrs. R.K.Santhia /Assistant Professor-CSE

2. Types of software life cycle model Classic Waterfall model Iterative Lifecycle model Prototyping model Evolutionary model Spiral model

3. WATERFALL MODEL -Sandesh Jonchhe 2

4. WATERFALL MODEL Alternative to SDLC Most basic lifecycle model Is a sequential software development model Development is seen as flowing steadily downwards(like waterfall) through several phases In this model whole application is developed in a sequential approach Each phase must be completed fully before the next phase begin 3

5. 4

6. HIS T O R Y First formal description of the waterfall model is often cited as 1970 article by Winston W Royce Royce did not use the term “waterfall” in this model  “…I believe in this concept, but the implementation described above is risky and invites failure.” 5

7. WHEN TO USE Requirements are very well known, clear and fixed Product definition is stable Technology is understood There are no ambiguous requirements The project is short 6

8. WATERFALL MODEL DIAGRAM 7

9. 8

10. DIFFERENT PHASES OF WATERFALL MODEL Requirements analysis Check with the client and confirm the system specifications Misinterpretation at this stage may give rise to complications later The software definition must be detailed and accurate with no ambiguities All the requirements are then well documented and discussed further with the customer for reviewing 9

11. Design Decide on the system architecture, or the big picture/skeleton. Customer requirements are broken down into logical modules for the ease of implementation This phase lays a fundamental for actual programming and implementation Requirements are translated in some easy to represent form using which coding can be done effectively and efficiently DIFFERENT PHASES(contd..)

12. DIFFERENT PHASES(contd..)  Implementation (Coding)  Write the actual software itself/ coding  Design is translated into machine-readable form  If design is done in sufficient detail then coding can be done effectively 10

13.  Verification  Same thing as testing.  The entire system will be tested for any faults and failures  Verification/testing mainly focuses on Internal efficiency External efficiency DIFFERENT PHASES(contd..)

14. DIFFERENT PHASES(contd..)  Maintenance  After the system/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  Fix any bugs or issues that come up during operation.  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 11

15. ADVANTAGES Simple and easy to understand and use Easy to manage due to the rigidity of the model Phases are processed and completed one at a time Works well for smaller projects where requirements are very well understood Implementers have to follow the design accurately As everything is documented a new team member can easily understand what is to be done 12

16. DISAD V AN T AGES You cannot go back a step; if the design phase has gone wrong, things can get very complicated in the implementation phase High amounts of risk and uncertainty Not a good model for complex and object oriented projects Poor model for long and on-going projects Not suitable for the projects where requirements are at a moderate to high risk of changing Customer can see the working model of the project only at the end 13

17. ITER A TIVE MODEL 29

18. ITERATIVE MODEL Also called Incremental Model Project is broken into small modules which can be delivered A working version of software is produced during the first module. Each subsequent release of the module adds functionality to the previous release. The process continues till the complete system is achieved. Model very successfully when working with new technology Multiple life cycle makes it like a “multi waterfall” cycle. 30

19. ITERATIVE MODEL

20. 31 Requirements Design Testing Release & Maintenance Requirements Design Testing Release & Ma i nt e n a nce Requirements Design Testing Release & Ma i nt e n a nce Release 1 Release 2 Release 3

21. 32

22. Planning Phase:  This is the first stage of the iterative model, where proper planning is done by the team, which helps them in mapping out the specifications documents, establish software or hardware requirements and generally prepare for the upcoming stages of the cycle . DIFFERENT PHASES OF ITERATIVE MODEL Analysis and Design Phase:  Once the planning is complete for the cycle, an analysis is performed to point out the appropriate business logic, database models and to know any other requirements of this particular stage. Moreover, the design stage also occurs in this phase of iterative model, where the technical requirements are established that will be utilized in order to meet the need of analysis stage.

23. Implementation Phase:  This is the third and the most important phase of the iterative model. Here, the actual implementation and coding process is executed. All planning, specification, and design documents up to this point are coded and implemented into this initial iteration of the project. Testing Phase:  After the current build iteration is coded and implemented, testing is initiated in the cycle to identify and locate any potential bugs or issues that may have been in the software. Evaluation Phase:  The final phase of the Iterative life cycle is the evaluation phase, where the entire team along with the client, examine the status of the project and validate whether it is as per the suggested requirements. DIFFERENT PHASES(contd..)

24. 33 FOR EXAMPLE

25. 34

26. WHEN TO USE? Requirement of the main system are clearly defined and understood When the project is big Major requirement must be defined ; however, some details can evolve with time 35

27. ADVANTAGES 36 Software is produced early which facilitates customer evaluation and feedback Less costly to change requirements as compared to other models Easier to develop and test when iterations are small Customer can give his feedback during developing stage With every increment, operational product is delivered. Better suited for large and mission critical projects

28. DISAD V AN T AGES Comparatively more resources are required Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle Cost is higher than Waterfall model Not suitable for smaller project 37

29. THANK YOU 38