Presentation is loading. Please wait.

Presentation is loading. Please wait.

Basic SDLC Models.

Similar presentations


Presentation on theme: "Basic SDLC Models."— Presentation transcript:

1 Basic SDLC Models

2 Agenda SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods

3 SDLC definition SDLC abbreviation stands for “software development life cycle” SDLC is a structured methodology used in the development of software products and packages. This methodology is used from the conception phase through to the delivery and end of project delivering software product.

4 Waterfall SDLC diagram

5 Waterfall SDLC brief description
The relationship of each stage to the others can be roughly described as a waterfall, where the outputs from a specific stage serve as the initial inputs for the following stage. During each stage, additional information is gathered or developed, combined with the inputs, and used to produce the stage deliverables. It is important to note that the additional information is restricted in scope; “new ideas” that would take the project in directions not anticipated by the initial set of high-level requirements are not incorporated into the project. Rather, ideas for new capabilities or features that are out-of-scope are preserved for later consideration. The waterfall provides an orderly sequence of development steps and helps ensure the adequacy of documentation and design reviews to ensure the quality, reliability, and maintainability of the developed software. While almost everyone these days disparages the "waterfall methodology" as being needlessly slow and cumbersome, it does illustrate a few sound principles of life cycle development.

6 Waterfall pros and cons
Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

7 Waterfall pros and cons
Waterfall Cons: All requirements must be known upfront Deliverables created for each phase are considered frozen – inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development Integration is one big bang at the end Little opportunity for customer to preview the system

8 V-Shape SDLC diagram

9 V-Shape SDLC brief description
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

10 V-Shape pros and cons V-Shape Pros: Simple and easy to use Each phase has specific deliverables Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle Works well for small projects where requirements are easily understood Project management can track progress by milestones

11 V-Shape pros and cons V-Shape Cons: Very rigid, like the waterfall model Little flexibility and adjusting scope is difficult and expensive Software is developed during the implementation phase, so no early prototypes of the software are produced Model doesn’t provide a clear path for problems found during testing phases

12 Spiral SDLC diagram

13 Spiral SDLC brief description
The spiral model starts with an initial pass through a standard waterfall lifecycle, using a subset of the total requirements to develop a robust prototype. After an evaluation period, the cycle is initiated again, adding new functionality and releasing the next prototype. This process continues, with the prototype becoming larger and larger with each iteration. Hence, the “spiral.” The spiral methodology reflects the relationship of tasks with rapid prototyping, increased parallelism, and concurrency in design and build activities. The spiral method should still be planned methodically, with tasks and deliverables identified for each step in the spiral. Iterates cycles of these project phases: Requirements Definition Risk Analysis Prototyping Simulate, benchmark Design, implement, test Plan next cycle (if any)

14 Spiral pros and cons Spiral pros: Strong approval and documentation control Implementation has priority over functionality Additional functionality can be added at a later date 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 Avoidance of risk is enhanced

15 Spiral pros and cons Spiral cons: Highly customized limiting of re-usability Applied differently for each application Risk of not meeting budget or schedule Possibility to end up implemented as the Waterfall framework 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

16 RUP SDLC diagram RUP – Rational Unified Process

17 RUP SDLC brief description
RUP is based on a set of building blocks, or content elements, describing what are to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved. The main building blocks, or content elements, are the following: Roles (who) – A Role defines a set of related skills, competencies, and responsibilities. Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process. Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result. Within each iteration, the tasks are categorized into nine disciplines: six "engineering disciplines" (Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment) and three supporting disciplines (Configuration and Change Management, Project Management, Environment).

18 RUP pros and cons RUP pros: Valuable and coherent portions of the system (use cases) are developed, providing business value to users Users can easily comprehend the project plan as it is based on things they do Developers learn the business while they implement use cases

19 RUP pros and cons RUP cons: Use cases are not complete definition of requirements End-user is not directly involved All use cases aren’t equal Re-use is complicated

20 Agile methods Continuum of Development methods
Adaptive methods focus on adapting quickly to changing realities. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. Adaptive Predictive Continuum of Development methods AGILE Location Staff knows

21 Agile and other methods comparison
Agile home ground: Low criticality Senior developers Requirements change very often Small number of developers Culture that thrives on chaos Plan-driven home ground: High criticality Junior developers Low rate of requirements change Large number of developers Culture that demands order

22 Agile usage Agile techniques are:
Used to speed up or bypass one or more life cycle phases Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined methods Implementation examples (most popular): Scrum Extreme Programming (XP) Feature Driven Development (FDD) Rapid Application Development (RAD)


Download ppt "Basic SDLC Models."

Similar presentations


Ads by Google