02 different approaches
-
Upload
rap-payne -
Category
Technology
-
view
424 -
download
3
description
Transcript of 02 different approaches
Approaches to the SDLC
Software Methodology is the machine we use to make software
¡ Structured programming ¡ Cap Gemini SDM ¡ SSADM ¡ RAD ¡ Scrum ¡ XP ¡ USDP
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.
But there are different ways to put these activities together
¡ Three main SDLC methods ¡ Waterfall ¡ Iterative ¡ Any combination of the above
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.
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.
Combinations can combine the best of both
¡ Tune it to your organization
Let's look at two examples ¡ SSADM is a waterfall methodology ¡ USDP is an iterative methodology
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
The feel of SSADM ¡ High structure ¡ High ceremony ¡ High accountability ¡ Deep reach
SSADM has seven stages ¡ Feasibility study ¡ Investigation of the current
environment ¡ Business system options ¡ Requirements specification ¡ Technical systems options ¡ Logical design ¡ Physical design
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?
Stage 1: Investigation of the Current Environment ¡ Product: An analysis of where we are vs. where we need to be
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
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
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
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
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
Why use SSADM? ¡ Established ¡ Well-defined ¡ Higher focus on data ¡ Sometimes you have no choice
Why not use SSADM? ¡ Expensive ¡ Slow ¡ Rigid
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
Now let's look at an iterative methodology, USDP
USDP Phases and Iterations
Use cases drive USDP
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 …
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
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
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
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
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
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
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
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
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
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
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
How many iterations should I have?
¡ There is no right answer ¡ Typically, the more the better ¡ The shorter the iterations the better
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
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