02 different approaches

39
Approaches to the SDLC

description

 

Transcript of 02 different approaches

Page 1: 02 different approaches

Approaches to the SDLC

Page 2: 02 different approaches

Software Methodology is the machine we use to make software

¡  Structured programming ¡ Cap Gemini SDM ¡  SSADM ¡  RAD ¡  Scrum ¡  XP ¡  USDP

Page 3: 02 different approaches

Essential Activities ¡  Regardless of the process, method or lifecycle, the

following activities are performed in creating quality requirements: ¡  Gather includes activities associated with the collection

of the requirements from the various sources including document and stakeholders.

¡  Analyze includes activities associated with the negotiation and determination of what the requirements actually mean and which stakeholdersʼ’ requirements take priority. It determines which requirements should be addressed in this project.

¡  Organize is the documentation and organizing of the requirements. Normally requirements can be classified into functional and non-functional requirements.

¡  Approve is the confirmation and signoff from the stakeholders that these are the requirements they want to be addressed in this project.

Page 4: 02 different approaches

But there are different ways to put these activities together

¡  Three main SDLC methods ¡  Waterfall ¡  Iterative ¡  Any combination of the above

Page 5: 02 different approaches

Waterfall processes are highly structured ¡  Projects with very well defined and stable

requirements should consider selecting the waterfall lifecycle.

¡  Some problems with the waterfall: ¡  Late validation means mistakes cost more. The

customer does not see the product until the projectʼ’s end during user acceptance tests. If requirements were incorrect, the wrong product may have been built, requiring costly rework.

¡  Errors are not found in the phase where generated. ¡  The waterfall does not reflect the way systems are

really developed. Frequent iterations are often necessary.

Page 6: 02 different approaches

Iterative processes are flexible

¡  Incremental development ¡  The system as specified in the requirements

documents is partitioned into subsystems by functionality.

¡  Each release adds a new functionality to the system. ¡  Iterative development ¡  Delivers a full system at the very beginning and then

changes the functionality of each subsystem with each new release.

Page 7: 02 different approaches

Combinations can combine the best of both

¡  Tune it to your organization

Page 8: 02 different approaches

Let's look at two examples ¡  SSADM is a waterfall methodology ¡  USDP is an iterative methodology

Page 9: 02 different approaches

SSADM is one of the originals ¡ Developed for the UK Central Computer and

Telecommunications Agency starting in 1980 ¡ Made mandatory in 1983 ¡  Revamped and renamed Business System

Development in 2000

Page 10: 02 different approaches

The feel of SSADM ¡  High structure ¡  High ceremony ¡  High accountability ¡ Deep reach

Page 11: 02 different approaches

SSADM has seven stages ¡  Feasibility study ¡  Investigation of the current

environment ¡  Business system options ¡  Requirements specification ¡  Technical systems options ¡  Logical design ¡  Physical design

Page 12: 02 different approaches

Stage 0: Feasibility Study ¡  Product: a decision … should we even do this? ¡  Sometimes it is a no-brainer. We must do it. ¡ Questions we ask: ¡ What else will have to change? ¡  Is it worth the investment? ¡  Is it the 'right' thing to do? Is it ethical? ¡  Can we get the talent and equipment?

Page 13: 02 different approaches

Stage 1: Investigation of the Current Environment ¡  Product: An analysis of where we are vs. where we need to be

Page 14: 02 different approaches

Stage 2: Business System Options ¡  Product: List of top 2-3 options to make the

output of Stage 1 happen. ¡ All options are entertained. ¡ Criteria ¡  Costs vs. Benefits ¡  Ease of implementation

¡ Data: Logical data structure is documented

Page 15: 02 different approaches

Stage 3: Requirements Specification ¡  Product: A full logistical spec document for the

new system. ¡ Must be free from: ¡  error ¡  ambiguity ¡  inconsistency

¡ Most difficult stage ¡ Data: ERDs and Data flow diagrams

Page 16: 02 different approaches

Stage 4: Technical System Options

¡  Product: Again, 2-3 options on big picture tech specifications

¡  This is after considering all options ¡ Data: Which RDBMS

Options on: – Hardware – Software – Staffing – Physical

space – Power

needs – Deployment – UX

Page 17: 02 different approaches

Stage 5: Logical Design ¡  Product: A design document including user

interface screens, Step-by-step flow, and data designs

¡ We now know what every screen looks like ¡ Data: The full data catalog

Page 18: 02 different approaches

Stage 6: Physical Design ¡  Product: Design document – tells developers how

to write the software and engineers how to put together the system

¡  Final stage ¡  Logical design is translated into real-world ¡  Logical data -> ERD ¡  Logical needs of the system -> machine, network,

software specs

Page 19: 02 different approaches

Why use SSADM? ¡  Established ¡ Well-defined ¡  Higher focus on data ¡  Sometimes you have no choice

Page 20: 02 different approaches

Why not use SSADM? ¡  Expensive ¡  Slow ¡  Rigid

Page 21: 02 different approaches

Structured Software Analysis and Design Methodology ¡ A well-established and proven methodology ¡  Highly structured ¡  Creates accountability and thoroughness ¡  Creates friction to progress

¡ Does not lend itself to agile development

Page 22: 02 different approaches

Now let's look at an iterative methodology, USDP

Page 23: 02 different approaches

USDP Phases and Iterations

Page 24: 02 different approaches

Use cases drive USDP

Page 25: 02 different approaches

The Iterative Life Cycle …

¡  Hacking away at code ¡ A playpen for

developers ¡  Redesigning the same

thing over and over until it is perfect

¡ An excuse for not planning and managing a project

¡  Something that affects only the developers on a project

¡  Planned ¡ Managed ¡  Predictable ¡ Change-tolerant ¡  Inclusive - It involves

the user/customer throughout the process

¡  Risk driven

is not … is …

Page 26: 02 different approaches

Iterative development should have … ¡  Frequent releases of genuine functionality ¡ Continuous integration ¡  Not done in one lump near the delivery date

¡  Early and continual reduced risks

Page 27: 02 different approaches

Regular releases force the team to closure ¡ We have freedom to postpone

issues to near future iterations, giving us time to solve them

¡ Non-developer support team members can schedule

¡ No 80/20 situation

Page 28: 02 different approaches

Risk

Transition

Inception

Elaboration

Construction

Preliminary Iteration

Architect. Iteration

Architect. Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

Transition Iteration

Transition Iteration

Post- deployment

Waterfall

Time

Some risks are eliminated almost immediately

Page 29: 02 different approaches

Inception Elaboration Construction Transition

Iteration 1 Iteration 2 Iteration 3

Iteration Planning Rqmts Capture

Analysis & Design Implementation

Test Prepare Release

“Mini-Waterfall” Process

Use Cases Drive the Iteration Process

Page 30: 02 different approaches

The Iteration Life Cycle: A Mini-Waterfall

•  Results of previous iterations •  Up-to-date risk assessment •  Controlled libraries of models,

code, and tests

Release description Updated risk assessment Controlled libraries

Iteration Planning

Requirements Capture

Analysis & Design

Implementation

Test

Prepare Release

Selected scenarios

Page 31: 02 different approaches

Iteration Life Cycle Activities

¡  Iteration planning ¡  Before the iteration begins, the general objectives of

the iteration should be established based on ¡  Results of previous iterations ( if any) ¡  Up-to-date risk assessment for the project

¡  Determine the evaluation criteria for this iteration ¡  Prepare detailed iteration plan for inclusion in the

development plan ¡  Include intermediate milestones to monitor progress ¡  Include walkthroughs and reviews

Page 32: 02 different approaches

Iteration Life Cycle Activities ¡  Requirements Capture ¡  Select/define the use cases to be implemented in this iteration ¡  Update the object model to reflect additional domain classes and

associations discovered ¡  Develop a test plan for the iteration

Page 33: 02 different approaches

Iteration Life Cycle Activities

¡ Analysis & Design ¡  Determine the classes to be developed or updated

in this iteration ¡  Update the object model to reflect additional

design classes and associations discovered ¡  Update the architecture document if needed ¡  Begin development of test procedures

¡  Implementation ¡  Automatically generate code from the design

model ¡  Manually generate code for operations ¡  Complete test procedures ¡  Conduct unit and integration tests

Page 34: 02 different approaches

Iteration Life Cycle Activities

¡  Test ¡  Integrate and test the

developed code with the rest of the system (previous releases)

¡  Capture and review test results ¡  Evaluate test results relative to

the evaluation criteria ¡  Conduct an iteration assessment

¡  Prepare the release description ¡  Synchronize code and design

models ¡  Place products of the iteration in

controlled libraries

Page 35: 02 different approaches

Work Allocation Within an Iteration

¡  Work to be accomplished within an iteration is determined by ¡  The (new) use cases to be implemented ¡  The rework to be done

¡  Packages make convenient work packages for developers ¡  High-level packages can be assigned to teams ¡  Lower-level packages can be assigned to individual

developers ¡  Use Cases make convenient work packages for test

and assessment teams ¡  Packages are also useful in determining the

granularity at which configuration management will be applied ¡  For example, check-in and check-out of individual

packages

Page 36: 02 different approaches

Iteration Assessment

¡ Assess iteration results relative to the evaluation criteria established during iteration planning: ¡  Functionality ¡  Performance ¡  Capacity ¡  Quality measures

¡ Consider external changes that have occurred during this iteration ¡  For example, changes to requirements, user needs,

competitorʼ’s plans ¡ Determine what rework, if any, is required and

assign it to the remaining iterations

Page 37: 02 different approaches

How many iterations should I have?

¡  There is no right answer ¡  Typically, the more the better ¡  The shorter the iterations the better

Page 38: 02 different approaches

Make your first iteration super-easy to hit

¡  It sets the tone for subsequent iterations ¡  The first iteration contains the highest learning

curve ¡  Implementation errors happen here ¡  So, put a small number of features in the first

iteration

Page 39: 02 different approaches

Conclusion ¡  Every methodology contains these stages ¡  Analysis ¡  Design ¡  Coding ¡  Testing ¡  Implementation

¡  You can do them serially (waterfall - SSADM, eg.) or iteratively (agile – USDP, eg.) or some combination of the two

¡ Waterfall is more structured but agile reduces risk of all kinds

¡  Use cases form the basis of an agile project