Your SlideShare is downloading. ×
0
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Introduction and life cycle models
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introduction and life cycle models

4,906

Published on

Ppt about software devlopment life cycle.

Ppt about software devlopment life cycle.

Published in: Technology
2 Comments
1 Like
Statistics
Notes
  • Which life cycle modelwould you follow?• A well-understood data processing application. 76
    77. • Classical Waterfall model• Iterative Waterfall model• Evolutionary model• Prototype model• Spiral model 77
    78. Which life cycle modelwould you follow?• A new software product that would connect computers through satellite communication. Assume that your team has no previous experience in developing satellite communication software. 78
    79. Which life cycle modelwould you follow?• A compiler for a new language. 79
    80. • An object oriented s/w development effort. 80
    81. • The graphical user interface part of a large s/w product. 81
    82. • A new text editor. 82
    83. • An extremely large s/w that would provide monitor, and control cellular communication among its subscriber using a set of revolving satellites. 83
    84. • If the company has already experienced in developing payroll s/w for different organizations and now want to develop a payroll system for some organization. 84

    i want the answer plz..
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • cn u plz snd me tz slides to my email....ramportia@gmail.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
4,906
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
95
Comments
2
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. What is S/W Engineering?• It discusses systematic and cost effective techniques to software development.• The techniques are developed from4.New innovations5.Past mistakes so that they are not repeated in future while developing similar software. 1
  • 2. Program versus S/W product• Programs are small in size with limited functionality. It is for individual’s personal use. It doesn’t have good user interface and proper documentation. 2
  • 3. • A software product has large no. of users, properly designed, good user-interface, proper user manuals or user guides. They are developed by a group of engineers in a team. 3
  • 4. Software Life Cycle Models (SDLC) 4
  • 5. • A software life cycle model is a descriptive and diagrammatic representation of the software life cycle.• It maps the different activities performed while developing a s/w. 5
  • 6. Classical Waterfall Model• Classical waterfall model divides life cycle into phases: − feasibility study, − requirements analysis and specification, − design, − coding and unit testing, − integration and system testing, − maintenance. 6
  • 7. Classical Waterfall Model Feasibility Study Req. Analysis Design Coding Testing Maintenance 7
  • 8. Feasibility Study• Main aim of feasibility study:determine whether developing the product − financially worthwhile − technically feasible.• First roughly understand what the customer wants: − different data which would be input to the system, − processing needed on these data, − output data to be produced by the system, − various constraints on the behavior of the system. 8
  • 9. Activities during FeasibilityStudy • Work out an overall understanding of the problem. • Formulate different solution strategies. • Examine alternate solution strategies in terms of: ∗ resources required, ∗ cost of development, and ∗ development time. 9
  • 10. Activities during FeasibilityStudy • Perform a cost/benefit analysis: − to determine which solution is the best. − you may determine that none of the solutions is feasible due to: ∗ high cost, ∗ resource constraints, ∗ technical reasons. 10
  • 11. Requirements Analysis andSpecification • Aim of this phase: − understand the exact requirements of the customer, − document them properly. • Consists of two distinct activities: − requirements gathering and analysis − requirements specification. 11
  • 12. Goals of RequirementsAnalysis • Collect all related data from the customer: − analyze the collected data to clearly understand what the customer wants, − find out any inconsistencies and incompleteness in the requirements, − resolve all inconsistencies and incompleteness. 12
  • 13. Requirements Gathering • Gathering relevant data: − usually collected from the end- users through interviews and discussions. − For example, for a business accounting software: ∗ Interview/discuss with all the accountants of the organization to find out their requirements. 13
  • 14. Requirements Analysis (CONT.) • The data you initially collect from the users: − would usually contain several contradictions and ambiguities: − each user typically has only a partial and incomplete view of the system. 14
  • 15. Requirements Analysis (CONT.) • Ambiguities and contradictions: − must be identified − resolved by discussions with the customers. 15
  • 16. Requirements specification• Next, requirements are organized: − into a Software Requirements Specification (SRS) document. 16
  • 17. Requirements specification (CONT.)• Engineers doing requirements analysis and specification: −are designated as analysts. 17
  • 18. Design• Design phase transforms requirements specification: − into a form suitable for implementation in some programming language. 18
  • 19. Design• In technical terms: − during design phase, software architecture is derived from the SRS document.• Two design approaches: − traditional approach, − object oriented approach. 19
  • 20. Traditional DesignApproach• Identify all the functions to be performed.• Identify data flow among the functions.• Decompose each function recursively into sub-functions. − Identify data flow among the subfunctions as well. 20
  • 21. Structured Analysis (CONT.)• Carried out using Data flow diagrams (DFDs).• After structured analysis, carry out structured design: − architectural design (or high-level design) − detailed design (or low-level design). 21
  • 22. Object Oriented Design • First identify various objects (real world entities) occurring in the problem: − identify the relationships among the objects. − For example, the objects in a pay-roll software may be: ∗ employees, ∗ managers, ∗ pay-roll register, ∗ Departments, etc. 22
  • 23. coding and unittesting• Purpose of coding and unit testing phase: − translate software design into source code. 23
  • 24. coding and unittesting• During the implementation phase: − each module of the design is coded, − each module is unit tested ∗ tested independently as a stand alone unit, and debugged, − each module is documented. 24
  • 25. Integration and SystemTesting • Different modules are integrated in a planned manner: − modules are almost never integrated in one shot. − Normally integration is carried out through a number of steps. • During each integration step, − the partially integrated system is tested. 25
  • 26. Integration and SystemTesting M1 M2 M3 M4 26
  • 27. System Testing• After all the modules have been successfully integrated and tested: − system testing is carried out.• Goal of system testing: − ensure that the developed system functions according to its requirements as specified in the SRS document . 27
  • 28. Types of testing• Alpha-testing- performed by the development team.• Beta-testing- performed by friendly set of customers• Acceptance testing- performed by the customer himself after the product is delivered to him/her. 28
  • 29. Maintenance• Maintenance of any software product: − requires much more effort than the effort to develop the product itself. − development effort to maintenance effort is typically 40:60. 29
  • 30. Relative Effort for Phases • Phases between feasibility study and testing 60 − known as development 50 Relative Effort phases. 40 • Among all life cycle phases 30 − maintenance phase consumes maximum effort. 20 Maintenance for long lasting 10 softwares like OS requires 0 Req. Sp Maintnce Design Coding T est lots of time. 30
  • 31. For some software like certain business application and the business itself gets obsolete. In that case, proportion of maintenance effort will be low.• Among development phases,− testing phase consumes the maximum effort. 31
  • 32. Maintenance (CONT.)• Corrective maintenance: − Correct errors which were not discovered during the product development phases.• Perfective maintenance: − Improve implementation of the system as suggested by customer ex: GUI − enhance functionalities of the system.• Adaptive maintenance: − Port software to a new environment, ∗ e.g. to a new computer or to a new operating system. 32
  • 33. Shortcomings of classical waterfallmodel• It assumes that no defect is introduced during any development activity but in practice defects do get introduced in almost every phase of the life cycle.• Developer need to go back to the phase where defect had occurred and redo some work and also in later phases. 33
  • 34. Classical Waterfall Model Feasibility Study Req. Analysis Design Coding Testing Maintenance 34
  • 35. Cntd…• It assumes that all the requirements are defined in the beginning of the project, but customer requirements keep on changing.• All the phases might not be sequential i.e., two phases might overlap. Example design and testing phase might overlap after requirements have been specified. 35
  • 36. Iterative Waterfall Model(CONT.) • Once a defect is detected: − we need to go back to the phase where it was introduced − redo some of the work done during that and all subsequent phases. • Therefore we need feedback paths in the classical waterfall model. 36
  • 37. Iterative Waterfall Model(CONT.) Feasibility study Req. Analysis Design Coding Testing Maintenance 37
  • 38. Iterative Waterfall Model(CONT.) • There is no feedback path to the feasibility stage as feasibility study errors cant be corrected. • Errors should be detected in the same phase in which they are introduced. • For example: • if a design problem is detected in the design phase itself, the problem can be taken care of much more easily than if it is identified at the end of the integration and system testing phase. 38
  • 39. Phase containment oferrors• Reason: rework must be carried out not only to the design but also to code and test phases.• The principle of detecting errors as close to its point of introduction/occurrence as possible is known as phase containment of errors.• Iterative waterfall model is by far the most widely used model. − Almost every other model is derived from the waterfall model. 39
  • 40. Shortcomings of I.W.M.• Cannot handle satisfactorily various risks that a real life project suffer from. Example: it assumes that all the requirements are specified completely before development starts but it is not so every time.• Rigid phase sequence may lead to resource or man power wastage. 40
  • 41. Prototyping Model• Before starting actual development, − a working prototype of the system should first be built.• A prototype is a toy implementation of a system: − limited functional capabilities, − low reliability, − inefficient performance. 41
  • 42. Reasons for developing aprototype • Illustrate to the customer: − input data formats, messages, or reports. • It helps in gaining better understanding of customers requirement. • Especially useful in developing the GUI part of the system. It becomes easier with working model rather than just imagining. 42
  • 43. • For example, we are developing compiler for a command language and none of the team member have written a compiler before. In that case, writing a compiler program for a very small language first helps us to understand the issues associated with developing a compiler. 43
  • 44. • Examine technical issues associated with product development: − Often major design decisions depend on issues like: ∗ response time of a hardware controller, ∗ efficiency of a sorting algorithm, etc. 44
  • 45. Prototyping Model (CONT.)• The third reason for developing a prototype is: − it is impossible to ``get it right the first time, − we must plan to throw away the first product ∗ if we want to develop a good product. 45
  • 46. Prototyping Model (CONT.) Build Prototype Requirements Customer Customer Quick Design Evaluation of Design Gathering Prototype acceptance Refine Implement Requirements Test Maintainance 46
  • 47. Prototyping Model (CONT.)• Start with approximate requirements.• Carry out a quick design.• Prototype model is built using several short-cuts: − Short-cuts might involve using inefficient, inaccurate, or dummy functions. ∗ A function may use a table look-up rather than performing the actual computations. 47
  • 48. Prototyping Model (CONT.)• The developed prototype is submitted to the customer for his evaluation: − Based on the user feedback, requirements are refined. − This cycle continues until the user approves the prototype.• The actual system is developed using the iterative waterfall approach. 48
  • 49. Prototyping Model (CONT.)• Requirements analysis and specification phase becomes redundant: − final working prototype (with all user feedbacks incorporated) serves as an animated requirements specification.• Design and code for the prototype is usually thrown away: − However, the experience gathered from developing the prototype helps a great deal while developing the actual product. 49
  • 50. Prototyping Model (CONT.)• Even though construction of a working prototype model involves additional cost --- overall development cost might be lower for: − systems with unclear user requirements, − systems with unresolved technical issues.• Many user requirements get properly defined and technical issues get resolved: − This minimizes the change requests from customer and massive redesign costs. 50
  • 51. Evolutionary Model• Evolutionary model (aka successive versions or incremental model): − Software requirements is broken down into several modules which can be incrementally implemented and delivered.• First develop the core modules (those which don’t need service from other modules) of the system. 51
  • 52. • The initial product skeleton is refined into increasing levels of capability: − by adding new functionalities in successive versions. 52
  • 53. Evolutionary Model (CONT.)• Successive version of the product: − functioning systems capable of performing some useful work. − A new release may include new functionality: ∗ also existing functionality in the current release might have been enhanced. 53
  • 54. Evolutionary Model (CONT.) C A A A B B 54
  • 55. Advantages of EvolutionaryModel• Users get a chance to experiment with a partially developed system much before the full working version is released• Helps finding exact user requirements: − much before fully working system is developed. − requests for changes after complete s/w becomes less• Core modules get tested thoroughly: − reduces chances of errors in final product. 55
  • 56. Disadvantages ofEvolutionary Model• Often, difficult to subdivide problems into functional units: − which can be incrementally implemented and delivered. 56
  • 57. This model is suited for……- very large problems, where it is easier to find modules for incremental implementation.- Situations when the customer prefers to receive the product in increments so that he/she can start using different features as and when they are developed rather than waiting all the time for full product.- Object-oriented software development projects. 57
  • 58. Spiral Model• Proposed by Boehm in 1988.• Each loop of the spiral represents a phase of the software process: − the innermost loop might be concerned with system feasibility, − the next loop with system requirements definition, − the next one with system design, and so on.• There are no fixed phases in this model, that is why it is much more flexible compared to other models. 58
  • 59. Spiral Model (CONT.) Identify & Determine Resolve Risks Objectives Customer Evaluation and plan for next phase Develop Next Level of Product 59
  • 60. Spiral Model (CONT.)• The team must decide: − how to structure the project into phases.• Start work using some generic model: − add extra phases ∗ for specific projects or when problems are identified during a project.• Each loop in the spiral is split into four sectors (quadrants). 60
  • 61. Objective Setting (FirstQuadrant)• Identify objectives of the phase, they are investigated, elaborated, and analyzed.• Examine the risks associated with these objectives. − Risk: ∗ any adverse circumstance that might hamper/hinder successful completion of a software project . 61
  • 62. ex: the risk involved in accessing data from a remote database can be that the data access rate might be too slow.• Find alternate solutions possible. 62
  • 63. Spiral Model (CONT.) Identify & Determine Resolve Risks Objectives Customer Evaluation and plan for next phase Develop Next Level of Product 63
  • 64. Risk Assessment and Reduction (SecondQuadrant)• For each identified project risk, − a detailed analysis is carried out.• Steps are taken to reduce the risk.• For example, if there is a risk that the requirements are inappropriate: − a prototype system may be developed. − Ex: database risk can be resolved by building a prototype of data access subsystem and experimenting with the exact data access rate. 64
  • 65. Spiral Model (CONT.)• Development and Validation (Third quadrant): quadrant − identified features are implemented. − develop and validate the next level of the product. 65
  • 66. Spiral Model (CONT.) Identify & Determine Resolve Risks Objectives Customer Evaluation and plan for next phase Develop Next Level of Product 66
  • 67. • Review and Planning (Fourth quadrant): quadrant − review the results achieved so far with the customer and plan the next iteration around the spiral.• With each iteration around the spiral: − progressively more complete version of the software gets built. 67
  • 68. • The radius of the spiral at any point represent the cost incurred in the project so far, and the angular dimension would represent the progress made so far in the current phase. 68
  • 69. Pros and Cons of spiral model• It is more complex model to follow, since it is risk-driven and more complicated than other models.• Requires more knowledgeable staff.• Adv: for project involving many unknown risk, this model is more appropriate as risks will be known and resolved as and when identified. 69
  • 70. Spiral Model as a Metamodel • Subsumes all discussed models: − a single loop spiral represents waterfall model. − uses an evolutionary approach -- ∗ iterations through the spiral are evolutionary levels. − enables understanding and reacting to risks during each iteration along the spiral. − uses: ∗ prototyping as a risk reduction mechanism ∗ retains the step-wise approach of the waterfall model. 70
  • 71. Spiral Model (CONT.) Identify & Determine Resolve Risks Objectives Customer Evaluation and plan for next phase Develop Next Level of Product 71
  • 72. Comparison of Different Life CycleModels • Iterative waterfall model − most widely used model. − But, suitable only for well-understood problems. − not for very large projects and for those which involves risks. 72
  • 73. Comparison of Different Life CycleModels (CONT.)• Prototype model is suitable for projects not well understood: − user requirements − technical aspects − all risks identified before project starts. − especially popular for development of user interface part of project. 73
  • 74. Comparison of Different Life CycleModels (CONT.)• Evolutionary model is suitable for large problems: − can be decomposed into a set of modules that can be incrementally implemented, − incremental delivery of the system is acceptable to the customer. − Object oriented development projects. 74
  • 75. Comparison of Different Life CycleModels (CONT.)• The spiral model: − suitable for development of technically challenging software products that are subject to several kinds of risks that are difficult to discover at the start of the project. 75
  • 76. Which life cycle modelwould you follow?• A well-understood data processing application. 76
  • 77. • Classical Waterfall model• Iterative Waterfall model• Evolutionary model• Prototype model• Spiral model 77
  • 78. Which life cycle modelwould you follow?• A new software product that would connect computers through satellite communication. Assume that your team has no previous experience in developing satellite communication software. 78
  • 79. Which life cycle modelwould you follow?• A compiler for a new language. 79
  • 80. • An object oriented s/w development effort. 80
  • 81. • The graphical user interface part of a large s/w product. 81
  • 82. • A new text editor. 82
  • 83. • An extremely large s/w that would provide monitor, and control cellular communication among its subscriber using a set of revolving satellites. 83
  • 84. • If the company has already experienced in developing payroll s/w for different organizations and now want to develop a payroll system for some organization. 84

×