sdlc models bessy charles meera vijayaraghavan cognizant technology solutions l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SDLC Models Bessy Charles & Meera Vijayaraghavan Cognizant Technology Solutions PowerPoint Presentation
Download Presentation
SDLC Models Bessy Charles & Meera Vijayaraghavan Cognizant Technology Solutions

Loading in 2 Seconds...

play fullscreen
1 / 54

SDLC Models Bessy Charles & Meera Vijayaraghavan Cognizant Technology Solutions - PowerPoint PPT Presentation


  • 1008 Views
  • Uploaded on

SDLC Models Bessy Charles & Meera Vijayaraghavan Cognizant Technology Solutions Software Development Life Cycle A series of steps that organizes the development of a software product Duration can take several days or years

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SDLC Models Bessy Charles & Meera Vijayaraghavan Cognizant Technology Solutions' - arleen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software development life cycle
Software Development Life Cycle
  • A series of steps that organizes the development of a software product
  • Duration can take several days or years
  • Phases provide manageability & organization. At a bare minimum, a development life cycle should have the following phases & their respective outputs:
    • Requirements - Software Requirements Specification
    • System Design - Design Document
    • Program Implementation - Code
    • Testing - Test Report, Change Requests
  • Life cycle components are the 4Ps - People, Process, Product, Phases
life cycle models
Life Cycle Models
  • Life cycle models make software development predictable, repeatable, measurable & efficient
  • A high-quality model based on the life cycle increases the chance of a high-quality deliverable
  • Provides framework for a standard set of terminology, activities & deliverables
  • Increases ease of tracking project progress by all stake holders
  • Provides a formal basis for planning, estimating & scheduling
definitions
Definitions
  • METHODOLOGY = MODEL + TECHNIQUE
  • A methodology is composed of 1 or more models used in conjunction with 1 or more techniques
  • Model identifies the various phases & inter-connections that the life cycle will have
  • A technique is a way to implement the model
  • A model dictates that the requirements should be collected. If the JAD technique is applied, the requirements would be collected over a series of face to face sessions with all the key stake holders
  • A model dictates that defects should be removed. If the Clean Room technique is applied, it achieves this through formal inspections & automated syntax checks
models
Models

Common Models

  • Waterfall
  • Incremental
  • Incremental/Iterative - Design to Schedule
  • Spiral Model
  • Rapid Application Development – RAD
  • Evolutionary Prototyping
what is waterfall
What is Waterfall?
  • Origins
    • Proposed in the early 70s & widely used even today
    • Based strongly on the way hardware systems are designed & implemented
  • A model of the software development process in which the constituent activities - concept, requirements, design, development, testing & installation- are performed in a linear order.
  • There is a single pass through each phase. Overlap between these phases is neither precluded nor mandated.
  • There is little or no iterative development
  • Ergo, each phase “pours over” to the next.
model schematic

Planning &

Definition

Requirements

Analysis

Design

Code &

Unit Test

Formal

Test

Implement

TIME

Model Schematic
  • Embark on a life cycle phase.
  • Conduct formal reviews with the client after completing a phase. Check progress made. Incorporate review comments.
  • Freeze the deliverables from the phase
  • Start the next phase.
waterfall with back flow

Requirements

Req. Change

Verify

Design

Verify

Implementation

Operations

Test

Retirement

Waterfall with Back-flow
  • Modification an attempt to make the linear model more flexible to change.
  • If a problem is detected/scope is changed in 1 phase, corresponding changes should be made to the previous phase.
constraints
Constraints
  • No phase is complete until the documentation for that phase has been completed& the products of that phase have been approved by the SQA
  • A formal change control procedure is needed to address changes that might arise in any of the prior deliverables
  • Once the product has been accepted, any change constitutes maintenance
  • Software configuration consists of specification, design, code, user manual, operations manual, test procedure & results
  • In the pure waterfall, each major phase begins only after the previous phase has finished. In the modified waterfall a feedback loop permits modifications to the previous phase(s)
candidate projects
Candidate Projects
  • Requirements are stable, clear & unambiguous. Customers know what they want & they are ready to commit.
  • Technology & methodology are well understood by the development team. This is crucial, as Waterfall does not tolerate reopening prior baselines
  • Problem is complex (so, it warrants a heavy methodology) & well understood (so there will not be many regrettable mistakes)
  • When smaller software applications are being developed (so scope change will not occur)
advantages
Advantages
  • Enforces a disciplined, engineering approach
  • A formal process makes progress measurable
  • Produces software artifacts that can be reused in other projects
  • Experience in applying steps in past projects can be used in estimating the duration of steps in future projects
  • Discourages jumping ahead
  • Emphasizes planning and good requirements.
  • It is possible to create a clean design from the requirements
  • Verification is done after each phase
  • Increases visibility of the process through increased documentation
  • Documentation produced can reduce maintenance costs
disadvantages
Disadvantages
  • Requirements must be fully specified up front
  • Product is not delivered till the end
  • It is difficult & expensive to repeat phases
  • Sequential process means certain parts may be stalled while waiting for upstream parts to complete
  • Generates few visible signs of progress until the very end. Feedback happens too late in the life-cycle.
  • Since the Waterfall model prevents iterative development, it suffers from the following problems:
    • Inflexible. Every phase creates a deliverable, which is frozen at the end of the phase.
    • Requirements change over time. A model which relies on frozen baselines has little tolerance for scope creep.
    • A linear project is long drawn. The business objectives of an organization might have changed in the mean time.
what is an incremental model
What is an Incremental Model?
  • Also called Staged Delivery Model
  • Performs the waterfall in overlapping sections, attempting to compensate for the length of projects by producing usable functionality earlier
  • All the requirements are collected in one-shot. The technical architecture is finalized up-front
  • The objectives are divided into several increments or builds.
  • The 1st build is developed & delivered. This is followed by the next portion till all the objectives have been met.
model schematic16

Planning &

Definition

Know what is going to be built

Requirements

Analysis

Architectural

Design

Detailed Design

Release 1

Detailed Design

Code

…..

…..

Code

Test

Test

Deliver

Deliver in stages or increments

Release N

Deliver

Model Schematic
  • Plan the project, finalize objectives
  • Requirements Collection
  • Technical architecture
  • Divide the objectives into increments

For each increment:

  • High level & Detailed Design
  • Implementation in Code & Unit testing
  • System & Integration testing
  • Deliver the build
what is design to schedule
What is Design to Schedule?
  • Also called Iterative/Incremental.
  • Very similar to the incremental model:
    • The full product is planned up-front.
    • All the requirements are collected
    • The technical architecture is finalized
    • Delivery is staged
  • The differences are:
    • Staged delivery is based on priority. Features with the highest priority are implemented first.
    • All the stages or increments may not be delivered. Features with the lowest priority may never be developed.
    • Every increment is iterative - the build is divided into several pieces & developed 1 by one. Iterations are delivered together, in 1 final build
what is design to schedule19
What is Design to Schedule?

Summing up, the fundamental differences between an “iteration” &

an “increment” are:

  • Each iteration implements a subset of requirements through the test phase
  • Each iteration adds new functionality and/or refines existing functionality
  • Each increment corresponds to a release with new functionality
  • Each increment has gone through several iterations
  • Note that iterations need neither involve nor preclude prototypes
model schematic20

Planning &

Definition

Requirements

Analysis

High priority features

Architectural

Design

Detailed Design

Code

Test

Medium priority features

Detailed Design

Code

Delivery Date

Detailed Design

Low priority features

Test

Code

Test

Deliver

Model Schematic
  • Plan the project, finalize objectives
  • Requirements Collection
  • Technical architecture
  • Divide the objectives into increments

For each increment:

    • Divide the increment into iterations
    • For each iteration
      • High level & Detailed Design
      • Implementation in Code & Unit testing
      • System & Integration testing
  • Consolidate all iterations & deliver the build
constraints21
Constraints
  • The system must enable splitting an increment into smaller modules
  • There must be few inter-dependent modules & interfaces with other applications
  • Iterative development of non-trivial systems is not easy. A lot of planning is needed to split a build into components
  • It requires a lot of coordination if multiple iterations are carried out in parallel
  • The design of the higher priority items must be air-tight. Otherwise, it would conflict later with the later iterations
  • The stake holders should decide the overall priorities - not the development team
  • The organization has good change control, configuration management & integration plans
  • Objective measures of tracking progress are needed
  • An overall architecture team which stresses on reuse, defines the architecture & ensures clear understanding of the high level design
candidate projects22
Candidate Projects
  • Clients are sure of the priority of their objectives
  • Clients need feedback after deployment to decide when to stop development
  • Clients are unsure of the ROI for each set of priorities
  • Ideally suited for mass market products - such as web browsers or B2C sites, where early, high priority features could be introduced
  • Any experimental market, where the ROI is not guaranteed
  • Application can be fabricated as a series of fairly independent modules
  • Clients are willing to participate full fledged in the testing & deployment of the iterations
  • Infrastructure changes can not be developed in this model in a cost effective manner
sample methodologies based on these models
Sample Methodologies based on these models

Industry Methodologies based on (some of) these models

  • Rational Unified Process – RUP
  • SUMMIT
  • Agile Methodologies etc.
sample case study
Sample Case Study
  • Today’s Business Need
    • Speed
    • Agility
    • No compromise with quality
  • Client’s Situation
    • A web-based reporting tool for generating / viewing web based reports for Sales, Labor, Profit and Loss, Sales Items figures and 52 week trend for their respective stores and roll-ups
    • 14 person month project needed to be executed within in 3 month
    • Objective : to deliver business results in the right cycle time
  • Expected Outcome :
    • Shortened turnaround time
    • Increased productivity
results highlights of implementation
Results- highlights of implementation
  • The project was executed in 11 cycles
    • Original plan : 7 cycles
  • 39 % change in effort
    • Initial effort 14.1 Person Month (PM) & final effort 19.6 PM
  • 56 % addition in requirement
    • 9 new requirements were added to the originally foreseen 16 requirements

Contd.

results highlights of implementation26
Results- highlights of implementation
  • The Quality of software delivered was high. The proportion of defects reported in the cycle end QA feedback from the client was only 10%. The rest were all change requests and went as high as 90+ items.
  • The net effort and schedule variation at the end of cycle 11 was 6% (well within the Control Limit of 10%)
  • The average productivity for the project stood at 12.6 FP/PM.
results
Results

Cycle Effort variation

results28
Results

Cycle Schedule variation

results29
Results

Cycle Defect Density Trend

results30
Results

Productivity

rational unified process
Rational Unified Process

The basic tenets of RUP are:

  • Develop Software in an iterative & Incremental mode
    • See the advantages of the “iterative model” (Design to schedule) & the advantages of the “Incremental model”
  • Manage Requirements
    • All the stake holders must have the same expectations, to avoid scope creep
  • Use component based architecture
    • Use prototypes that evolve into the final system
    • Approach the architecture methodically
    • To reduce the development time, buy & integrate
problems addressed by rup
Problems Addressed by RUP
  • Visually model software
    • UML does not describe how to develop software
    • RUP describes how to use UML effectively for modeling
    • It describes the models needed, why they are needed & how to construct them
  • Continuously verify software quality
    • RUP stresses on process quality & product quality
    • RUP does not predicate how this should be done, though
  • Control changes to software
    • This is crucial in an iterative development environment, to keep everything in sync.
    • RUP suggests a robust configuration management, change control, issue tracking & metrics collection to accomplish ultimate control over an iterative project
what is rup
What is RUP?
  • RUP is a Software Engineering Framework that can be customized & tailored to suit the needs of an organization.
  • It is an object oriented Process Product that is integrated with the Rational suite of products
  • It captures many of the best practices harvested by Rational over the years
  • It is tightly integrated with UML. RUP itself was designed & documented using UML
  • It is delivered online using web technology. Regular upgrades are released by Rational approximately twice a year
principles of operation
Principles of Operation

In RUP, the development lifecycle is presented from 2 perspectives:

  • Management Perspective or the Horizontal Dimension
    • This indicates changes that happen to the project over time
    • System development goes through 4 lifecycle phases - Inception, Elaboration, construction & Transition
    • Shows the dynamic aspect of the process expressed in terms of cycles, phases, iterations or milestones
principles of operation35
Principles of Operation
  • Development Perspective or the Vertical Dimension
    • This shows the unwavering project management principles that should be applied throughout the life cycle
    • Iterative versions of the system are built in increments.
    • The activities performed during an iteration have are grouped into a set of 5 core work-flows - Business Modeling, Requirements, Analysis & Design, Implementation

& Test

    • Each core workflow describes some aspect of the system, resulting in a model of the system, or a set of documents
    • Shows the static aspect of the process components in terms of activities, disciplines, artifacts & roles
work flow details
Work Flow Details
  • Business engineering
    • The purpose is to assess the organization in which the system will be used, to understand the needs and problems that is to be solved by the system.
    • The result is a business use-case model and a business object model.
    • This workflow is optional for simplistic organizations.
  • Requirements
    • The purpose is to capture and evaluate the requirements, placing usability in focus.
    • This results in a use-case model, with actors representing external units communicating with the system, and use cases representing transaction sequences.
  • Analysis & Design
    • The purpose is to investigate the implementation environment and the effect it will have on the construction of the system.
work flow details37
Work Flow Details
    • This results in an object model (the design model), including use-case realizations that show how the objects communicate to perform the flow of the use cases. This might include interface definitions for classes and subsystems, specifying their responsibilities in terms of provided operations.
  • Implementation
    • The purpose is to implement the system in the prescribed implementation environment.
    • This results in source code, executables, and files.
  • Test
    • The purpose is to ensure that the system is the one intended, and that there are no errors.
    • This results in a certified system that is ready for delivery.
model schematic38
Model Schematic

Source :http://www-306.ibm.com/software/rational

model schematic39

Understand Stakeholder

Needs

Define the System

Manage Scope of the System

Refine System

Definition

Architectural Analysis

Manage changing

requirement

Architectural Design

Plan and Design Test

Database Design

Plan Integration

Structure the implementation Model

Implement Classes

Integrate each subsystem

Execute Integration test

Evaluate test

Integrate the System

Execute System Test

Model Schematic
agile methodology
Agile Methodology

Agile is the label given to a growing number of methodologies with names like Scrum, Crystal, Adaptive, Feature-Driven Development and Dynamic Systems Development Method (DSDM).

These new development approaches are based on the premise that if you hire competent developers, presumably they know how to write code. Any problems your developers encounter, therefore, aren't coding issues but organizational and communications ones, and those are what the agile approaches attempt to address.

agile programming systems
Agile Programming Systems

Extreme Programming

Built around 12 basic practices ranging from pair programming to frequent refactoring, this approach is more prescriptive than the others. For more information, visit www.extremeprogramming.org and www.xprogramming.com or read Extreme Programming Explained: Embrace Change, by Kent Beck (Addison Wesley Longman Inc., 1999).

Scrum

Based on the empirical process control model, Scrum programming relies on self-directed teams and dispenses with much advanced planning, task definition and management reporting. To learn more, visit www.controlchaos.com or read Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle (Prentice Hall PTR, 2001).

Crystal

This approach empowers the team to define the development process and refine it in subsequent iterations until it's stable. To learn more, visit crystalmethodologies.org/ or read Agile Software Development: Software Through People, by Alistair Cockburn (Addison Wesley Longman, 2001).

agile programming systems contd
Agile Programming Systems…Contd.

Adaptive:

Based on adaptive rather than deterministic theories, this approach offers a series of frameworks to apply adaptive principles and encourage collaboration. For more information, visit www.adaptivesd.com or read Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, by James A. Highsmith III (Dorset House Publishing, 2000).

Dynamic Systems Development Method

Conceived as a methodology for rapid application development, DSDM relies on a set of principles that include empowered teams, frequent deliverables, incremental development and integrated testing. For more information, visit www.dsdm.org or read DSDM: The Method in Practice, by Jennifer Stapleton (Addison Wesley Longman, 1997).

sample agile methodology feature driven development history
Sample Agile MethodologyFeature Driven development - History

FDD was initially devised by Jeff De Luca to meet the specific needs of a 15 month, 50 person software development project at a large Singapore bank in 1997. What Jeff De Luca delivered was a set of five processes that covered the development of an overall model and the listing, planning, design and building of features. The first process is heavily influenced by Peter Coad´s approach to object modeling. The second process incorporates Peter Coad´s ideas of using a feature list to manage functional requirements and development tasks. The other processes and the blending of the processes into a cohesive whole is a result of Jeff De Luca´s experience. Since its successful use on the Singapore project there have been several implementations of FDD.

feature driven development overview
Feature Driven development- Overview
  • FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities.
  • FDD describes five basic activities that are performed within the software development process.
    • Develop Overall Model
    • Build Feature List
    • Plan By Feature
    • Design By Feature
    • Build By Feature
feature driven development activities develop overall model
Feature-Driven Development-Activities -Develop Overall Model
  • The project starts with a high-level walkthrough of the scope of the system and its context is performed. Next, detailed domain walkthroughs are held for each modeling area. In support of each domain, walkthrough models are then composed by small groups which are presented for peer review and discussion. One of the proposed models or a merge of them is selected which becomes the model for that particular domain area. Domain area models are merged into an overall model, the overall model shape being adjusted along the way.
    • Form modeling Team
    • Conduct Domain walkthrough
    • If requirements not clear, study the documentation
    • Develop small group models
    • Develop team models
    • Refine overall object model
    • View Models
feature driven development activities build feature list
Feature-Driven Development-Activities -Build Feature List

The knowledge that is gathered during the initial modeling is used to identify a list of features. This is done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form <action> <result> <object>, for example: ´Calculate the total of a sale´ or ´Validate the password of a user´. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces.

  • Form feature list teams
  • Build feature list
feature driven development activities plan by feature
Feature-Driven Development-Activities -Plan by feature

Now that the feature list is complete, the next step is to produce the development plan. Class ownership is done by ordering and assigning features (or feature sets) as classes to chief programmers.

  • Form planning team
  • Design Development Sequence
  • Assign business activities to chief programmers
  • Assign classes to developers
feature driven development activities design by feature
Feature-Driven Development-Activities -Design by feature

A design package is produced for each feature. A chief programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held.

  • Form feature team
  • Conduct domain walkthrough
  • Study referenced documents
  • Develop sequence diagrams
  • Refine object model
  • Write class and method overview
  • Design Inspection
feature driven development activities build by feature
Feature-Driven Development-Activities -Build by Feature

After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. The class owners develop the actual code for their classes. After a unit test and a successful code inspection, the completed feature is promoted to the main build.

  • Implement classes and methods
  • Inspect code
  • Conduct Unit Test
  • Promote to build
feature driven development milestones
Feature-Driven Development - Milestones

Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is however important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. In the table below the milestones (and their completion percentage) are shown. A feature that is yet to be coded is 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%).

agile fdd methodology
Agile FDD Methodology

The Five Processes of FDD

Develop

An

Overall Model

Build a

Feature list

Plan by

Feature

Design by

Feature

Build by

Feature

references
References
  • Software Engineering by Roger Pressman
  • www.Agilemanifesto.org
  • http://www-306.ibm.com/software/rational

Thank you