Different SDLC Model

7/29/2019 Different SDLC Model

http://slidepdf.com/reader/full/different-sdlc-model 1/35

The waterfall model



The waterfall model

• The classic way of looking at S.E. that accounts for

the importance of requirements, design and

quality assurance.

– The model suggests that software engineers should

work in a series of stages.

– Before completing each stage, they should perform

quality assurance (verification and validation).

– The waterfall model also recognizes, to a limited

extent, that you sometimes have to step back to

earlier stages.



Limitations of the waterfall model

– The model implies that you should attempt tocomplete a given stage before moving on to the nextstage

• Does not account for the fact that requirements constantly

change.• It also means that customers can not use anything until the

entire system is complete.

– The model makes no allowances for prototyping.

–

It implies that you can get the requirements right bysimply writing them down and reviewing them.

– The model implies that once the product is finished,everything else is maintenance.



Waterfall Strengths

• 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



When to use the Waterfall Model

• Requirements are very well known

• Product definition is stable

•

Technology is understood• New version of an existing product

• Porting an existing product to a new platform.



The spiral model



The spiral model

• It explicitly embraces prototyping and an iterative approachto software development. – Start by developing a small prototype.

– Followed by a mini-waterfall process, primarily to gatherrequirements.

– Then, the first prototype is reviewed.

– In subsequent loops, the project team performs furtherrequirements, design, implementation and review.

– The first thing to do before embarking on each new loop is riskanalysis( includes development cost overruns, operating cost

miscalculations or any other factor that leads to less thansatisfactory final product)

– Maintenance is simply a type of on-going development.

– Intended for large, expensive and complicated projects



Spiral Model Weaknesses

• Time spent for evaluating risks too large for small orlow-risk projects

• Time spent planning, resetting objectives, doing riskanalysis and prototyping may be excessive

•

The model is complex• Risk assessment expertise is required

• Spiral may continue indefinitely

• Developers must be reassigned during non-development phase activities

• May be hard to define objective, verifiable milestonesthat indicate readiness to proceed through the nextiteration



When to use Spiral Model

• When creation of a prototype is appropriate

• When costs and risk evaluation is important

• For medium to high-risk projects

•Long-term project commitment unwise becauseof potential changes to economic priorities

• Users are unsure of their needs

• Requirements are complex

• New product line• Significant changes are expected (research and

exploration)



Prototyping Model

• A prototype is a working model that isfunctionally equivalent to a component of theproduct.

•reflects an attempt to increase the flexibility of the development process by allowing the client tointeract and experiment with a workingrepresentation of the product

• developmental process only continues once theclient is satisfied with the functioning of theprototype



Overview

• Identify basic requirements. Determine basic requirementsincluding the input and output information desired. Details,such as security, can typically be ignored.

• Develop Initial Prototype. The initial prototype isdeveloped that includes only user interfaces.

• Review The customers, including end-users, examine theprototype and provide feedback on additions or changes.

• Revise and Enhancing the Prototype. Using the feedbackboth the specifications and the prototype can be improved.

If changes are introduced then a repeat of steps #3 and #4may be needed.



Types of Prototyping

• Throwaway prototype

Creation of a model that will eventually be discarded rather

than becoming part of the finally delivered software

• Evolutionary prototype

To build a very robust prototype in a structured manner and

constantly refine and rebuilt it

•

Incremental prototypeFinal product is built as separate prototypes. At the end the

separate prototypes are being merged in an overall design



The evolutionary model



The evolutionary model

• It shows software development as a series of hills, each representing a separate loop of thespiral.

–

Shows that loops, or releases, tend to overlap eachother.

– Makes it clear that development work tends to reacha peak, at around the time of the deadline forcompletion.

– Shows that each prototype or release can take

• different amounts of time to deliver;

• differing amounts of effort.



Evolutionary Prototyping Steps

• A preliminary project plan is developed

• An partial high-level paper model is created

• The model is source for a partial requirements specification

• A prototype is built with basic and critical attributes

• The designer builds – the database

– user interface

– algorithmic functions

• The designer demonstrates the prototype, the userevaluates for problems and suggests improvements.

• This loop continues until the user is satisfied



Evolutionary Prototyping Strengths

• Customers can “see” the system requirements asthey are being gathered

• Developers learn from customers

• A more accurate end product• Unexpected requirements accommodated

• Allows for flexible design and development

•Steady, visible signs of progress produced

• Interaction with the prototype stimulatesawareness of additional needed functionality



Evolutionary Prototyping Weaknesses

• Tendency to abandon structured program

development for “code-and-fix” development

• Bad reputation for “quick-and-dirty” methods

• Overall maintainability may be overlooked

• The customer may want the prototype

delivered.

• Process may continue forever (scope creep)



When to use

Evolutionary Prototyping

• Requirements are unstable or have to be

clarified as the requirements clarification

stage of a waterfall model

• Develop user interfaces

• Short-lived demonstrations

• New, original development

• With the analysis and design portions of

object-oriented development.



Incremental Model



Incremental Model

• It introduces the notion of incremental

development.

– After requirements gathering and planning, the

project should be broken into separate subprojects, or phases.

– Each phase can be released to customers when ready.

– Parts of the system will be available earlier than when

using a strict waterfall approach.

– However, it continues to suggest that all requirements

be finalized at the start of development.



Incremental Model Strengths

• Develop high-risk or major functions first

• Each release delivers an operational product

• Customer can respond to each build

• Uses “divide and conquer” breakdown of tasks

• Lowers initial delivery cost

• Initial product delivery is faster

• Customers get important functionality early

• Risk of changing requirements is reduced



When to use the Incremental Model

• Risk, funding, schedule, program complexity, orneed for early realization of benefits.

• Most of the requirements are known up-front but

are expected to evolve over time• A need to get basic functionality to the market

early

• On projects which have lengthy development

schedules

• On a project with new technology



Rapid Application Model (RAD)

• Gathering requirements using workshops or focusgroups

• Prototyping and early, reiterative user testing of

designs• The re-use of software components

• A rigidly paced schedule that defers designimprovements to the next product version

• Less formality in reviews and other teamcommunication



RAD Model Phases

• Requirements planning phase (a workshoputilizing structured discussion of businessproblems)

•

User description phase – automated toolscapture information from users

• Construction phase – productivity tools, such ascode generators, screen generators, etc. inside a

time-box. (“Do until done”) • Cutover phase -- installation of the system, user

acceptance testing and user training



RAD Strengths

• Reduced cycle time and improved productivity withfewer people means lower costs

• Time-box approach mitigates cost and schedule risk

•

Customer involved throughout the complete cycleminimizes risk of not achieving customer satisfactionand business needs

• Focus moves from documentation to code.

•

Uses modeling concepts to capture information aboutbusiness, data, and processes.

• Reuse of existing components



RAD Weaknesses

• Risk of never achieving closure

• Documentation never exist

•

Requires a system that can be modularized• Developers and customers must be committed

to rapid-fire activities in an abbreviated time

frame.



When to use RAD

• Reasonably well-known requirements

• User involved throughout the life cycle

• Project can be time-boxed

• Functionality delivered in increments

• High performance not required

• Low technical risks

• System can be modularized

• Experienced programmers and analysts team



Joint Application Development

• JAD, is a process originally developed for designinga computer-based system.

• It brings together end users and IT professionals in

a highly focused workshop.• The advantages of JAD include a dramatic

shortening of the time it takes to complete a project.

• It also improves the quality of the final product by

focusing on the up-front portion of the developmentlifecycle, thus reducing the likelihood of errors thatare expensive to correct later on.



Features of JAD

• JAD centers around a structured workshop session.

• Participants get together in a room to discuss theproblem/project.

• Everyone hears what the rest of the group has to say.

• JAD can eliminate many of the problems with traditional meetings.

• Meetings are not well regarded as a productive forum.

• JAD turns meetings into workshops.

– They are less frequent

– More structured, and productive

– An agenda provides the structure

– The facilitator directs the process – Visual aids clarify concepts being discussed and the group dynamics,

with constant feedback, stimulates creativity



• JAD Purpose: to define the project, design a solution,and monitor the project until it reaches completion.

• JAD Philosophy: The JAD process is based on foursimple ideas:

1.People who actually do a job have the bestunderstanding of that job.

2.People who are trained in information technologyhave the best understanding of the possibilities of thattechnology.



3. Information systems and business processes rarely exist in isolation --they transcend the confines of any single system or office and effectwork in related departments. People working in these related areashave valuable insight on the role of a system within a larger community.

4. The best information systems are designed when all of these groupswork together on a project as equal partners.

• JAD Scope

1. The JAD should cover the complete development life cycle of asystem.

2. The JAD is usually a 3 to 6 month well-defined project.

3. For large-scale projects, it is recommended that the project beapproached incrementally, and that separate JAD's be used for eachincrement.



Basic Components of a JAD Session

• JAD sessions:1. Are more focused.

2. Are conducted in a dedicated environment.

3. Quickly drive major requirements.

4. Help better develop the "look & feel“ of the interface.

• JAD participants typically include:

– Project sponsor

– Project lead

– Facilitator

–

End users – Developers

– Observers

– Subject matter experts



Guidelines for a Successful JAD

• A clear purpose shared by all team members - the project charter

• A diverse team, representative of all areas effected by this project.

• Every person in the group has equal responsibility and decisionmaking power.

•

Every idea is valuable. Throughout the JAD, listen and acknowledgeeach idea and concern. Evaluating ideas during a brainstormingsession will shut down the creative process. The best idea maynever get said out of fear of being shot down.

• Participation by everyone is very important. Encourage quieter

members to speak, they often have the best ideas. Don't allow 1 or 2members to dominate. This is the facilitators responsibility as well asthe whole teams' responsibility.



• Listen when others speak, don't interrupt or talk while others aretalking (side conversations may have great ideas...we don't want tomiss them).

• Maintain a parking lot to record important issues that are not withinthe scope of this project.

• Don't hold meetings, just to hold meetings. Only meet when there issomething substantial to talk about.

• Don't let more than 3 or 4 weeks pass between meetings, you willloose momentum. Remember, each meeting is a motivation for theteam to complete tasks assigned. It is no fun to come to a meetingand admit you didn't finish your task.

• Decisions are reached by consensus. We are here to create awin/win solution...win/lose solutions aren't good enough.



BENEFITS OF JAD

– Enhanced communication and relationship between businessend users and IT personnel

– Build consensus and ownership

– Reduced system cost and development time

–

Improved system quality and productivity – Helps project teams get focused and stay focused

– Helps you get the right job done at the right time!

Documents

Different SDLC Model