software cycles

Development cycles

Waterfall, Agile, Prototyping, Spiral

Waterfall

1. History of water fall model.

2. Features of water fall model.

3. Phase of water fall model.

4. Brief description of phases.

5. Advantages.

6. Disadvantages.

History of waterfall

1)The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce

2)Royce did not use the term "waterfall" in this article.

3)Royce presented this model as an example of a flawed, non-working model.

http://en.wikipedia.org/wiki/Winston_W._Royce

Features of waterfall model

1. A Water Fall Model is easy to flow.

2. It can be implemented for any size of project.

3. Every stage has to be done separately at the right time so you cannot jump stages.

4. Documentation is produced at every stage of a waterfall model allowing people to understand what has been done.

5. Testing is done at every stage.

Waterfall model

Phases of waterfall model

Waterfall model has 5 different phases, Which are following.

1. Requirement gathering and Analysis.

2. Design.

3. Coding.

4. Testing.

5. Maintenance.

Brief description of phase

1) Requirement gathering and Analysis.

This is the first phase of waterfall model which includes a meeting with the customer to understand his requirements.

This is the most crucial phase as any misinterpretation at this stage may give rise to validation issues later.

The software definition must be detailed and accurate with no ambiguities.

It is very important to understand the customer requirements and expectations so that the end product meets his specifications.


Requirement gathering and Analysis phase the basic requirements of the system must be understood by software engineer, who is also called ANALYST.

All this requirements are then well documented and discussed further with the customer for reviewing.


2) Design.

The customer requirements are broken down into logical modules for the ease of implementation. Hardware and software requirements for every module are Identified and designed accordingly.

Also the inter relation between the various logical modules is established at this stage. Algorithms and diagrams defining the scope and objective of each logical model are developed.

In short, this phase lays a fundamental for actual programming and implementation


It is a intermediate step between requirements analysis and coding.

Design focuses on program attribute such as-

1) Data Structure.

2) Software Architecture.

3) Algorithm Details etc…….The requirements are translated in some easy to

represent form using which coding can be done effectively and efficiently.

The design needs to be documented for further use.


3) Coding.

Coding is a step in which design is translated into machine-readable form.

If design is done in sufficient detail then coding can be done effectively. Programs are created in this phase.

In this phase all software divided into small module then after doing coding for that small module rather than do coding whole software.

According to design programmers do code and make class and structure of whole software.


4) Testing.

In this stage, both individual components and the integrated whole are methodically verified to ensure that they are error-free and fully meet the requirements outlined in the first step.

In this phase testing whole software into two parts 1) HARDWARE & 2) SOFTWARE.

Type of testing is 2-types 1) Inside test. 2) Outside test.


5) Maintenance.

This is the final phase of the waterfall model, in which the completed software product is handed over to the client after alpha, beta testing.

After the software has been deployed on the client site, it is the duty of the software development team to undertake routine maintenance activities by visiting the client site.

If the customer suggests changes or enhancements the software process has to be followed all over again right from the first phase i.e requirement analysis.


The usually the longest stage of the software. In this phase the software is updated to:

a) Meet the changing customer needsb) Adapted to accommodate changes in the external environmentc) Correct errors and oversights previously undetected in the testing phasesd) Enhancing the efficiency of the softwareObserve that feed back loops allow for corrections to be incorporated into the model.

Advantages of waterfall model

The water fall model is easy to implementation.

For implementation of small systems water fall model is use full.

The project requires the fulfillment of one phase, before proceeding to the next.

It is easier to develop various software through this method in short span of time.

Disadvantages of waterfall model

The requirement analysis is done initially and sometimes it is not possible to state all the requirement explicitly in the beginning.

The customer can see working model of the project only at the end.

If we want to go backtrack then it is not possible in this model.

It is difficult to follow the sequential flow in software development process.

Spiral model

•The spiral model was defined by Barry Boehm in 1988 . •It was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. •the iterations were typically 6 months to 2 yearslong.

History

When to use The spiral Model

• The user has experience to refine the requirements .

• Some parts of the implementation may depend on future technology

• New user requirements are anticipated but not yet known

• Some user requirements may be significantly more difficult to meet than others, and it is decided not to allow them to delay a usable delivery

Spiral Model VS Waterfall Model

• Risk factor is considered in the Spiral Model but in water fall Model it is not considered.

• In Waterfall the requirements are freezed but this not happens in the Spiral Model.

• Waterfall Model is linear sequential model where Spiral Model works in loop.

• Spiral Model is costly as Risk factor is covered.

• In spiral model there is a better communication between developer and customer.

Spiral Model VS prototype model• number of phases of spiral model is not

fixed-whereas in prototype model number of phases is fixed .

• Risk factor is considered in the Spiral Model but in water fall Model it is not considered

• Spiral model includes many prototype models

• Spiral model is used when requirement is not clear and needs conformation while in prototype model requirement is clear but complex

• In spiral model customer interaction continous to move together. in other hand prototype model customer interaction needs till the prototype is app

Quadrant 1: Determine objectives, alternatives, and constraints:

Spiral Model Description

Objectives: performance, hardware/software interface , functionality, etc.

Alternatives: design, reuse, buy, etc.

constraints : imposed on technology, cost, schedule, support, and risk.

Once the system‘s objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed

Quadrant 2: Evaluate alternatives, identify, resolve risks:

The focus here is on risk study. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions

• Study alternatives relative to objectives and constraints

• Identify risks (lack of experience, new technology, tight schedules, poor process, etc.

• Resolve risks (evaluate if money could be lost by continuing system development

Quadrant 3: Develop, verify, next-level product.

Typical activities

Create a design

Review design

Develop code

Inspect code

Test product

Quadrant 4: Plan next phases.

Typical activities

• Develop project plan

• Develop configuration management plan

• Develop a test plan

• Develop an installation plan

Summary of Spiral steps:• Each successive phase in the project as a new spiral

includes a four steps or phases.• Software requirements in the design are gradually

developed through a series of prototypes. • The exact number of spirals necessary for the

project is flexible and depends on the number of prototypes needed to reach a satisfactory design.

• Since each face requires a certain level of commitment a cumulative cost of the project represented by the width of the spiral

• Once a satisfactory design is reached the software is constructed according the final three process of the waterfall model (Programming – Integration-Delivery)

Advantages

• Provides early indication of insurmountable risks, without much cost

• Users see the system early because of rapid prototyping tools

• 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• Cumulative costs assessed frequently

Disadvantages

Time spent for evaluating risks too large for small or low-risk projects

Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive

The model is complex Risk assessment expertise is requiredSpiral may continue indefinitelyDevelopers must be reassigned during non-

development phase activitiesMay be hard to define objective, verifiable

milestones that indicate readiness to proceed through the next iteration

•Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.

•It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).

•The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.

•Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

Scrum in 100 words

Scrum has been used by:•Microsoft•Yahoo•Google•Electronic Arts•High Moon Studios•Lockheed Martin•Philips•Siemens•Nokia•Capital One•BBC•Intuit

•Intuit•Nielsen Media•First American Real Estate•BMC Software•Ipswitch•John Deere•Lexis Nexis•Sabre•Salesforce.com•Time Warner•Turner Broadcasting•Oce

Scrum has been used for:Commercial software

In-house development

Contract development

Fixed-price projects

Financial applications

ISO 9001-certified applications

Embedded systems

24x7 systems with 99.999% uptime requirements

the Joint Strike Fighter

Video game development

FDA-approved, life-critical systems

Satellite-control software

Websites

Handheld software

Mobile phones

Network switching applications

ISV applications

Some of the largest applications in use

Characteristics

Self-organizing teams

Product progresses in a series of month-long “sprints”

Requirements are captured as items in a list of “product backlog”

No specific engineering practices prescribed

Uses generative rules to create an agile environment for delivering projects

One of the “agile processes”

Scrum

CancelGift wrap

Return

Sprint2-4 weeks

Return

Sprint goal

Sprint backlog

Potentially shippableproduct increment

Productbacklog

CouponsGift wrapCoupons

Cancel

24 hours

Putting it all together

Sprints

• Scrum projects make progress in a series of “sprints”• Analogous to Extreme Programming iterations

• Typical duration is 2–4 weeks or a calendar month at most

• A constant duration leads to a better rhythm• Product is designed, coded, and tested during

the sprint

No changes during a sprint

• Plan sprint durations around how long you can commit to keeping change out of the sprint

Change

Scrum framework

•Product owner•ScrumMaster•Team

Roles

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts

Artifacts

Scrum framework


Ceremonies


Artifacts


Roles

Product owner

• Define the features of the product• Decide on release date and content• Be responsible for the profitability of the

product (ROI)• Prioritize features according to market value • Adjust features and priority every iteration,

as needed • Accept or reject work results

The ScrumMaster

• Represents management to the project• Responsible for enacting Scrum values and

practices• Removes impediments • Ensure that the team is fully functional and

productive• Enable close cooperation across all roles

and functions• Shield the team from external interferences

The team• Typically 5-9 people• Cross-functional:

• Programmers, testers, user experience designers, etc.

• Members should be full-time• May be exceptions (e.g., database

administrator)

The team

• Teams are self-organizing• Ideally, no titles but rarely a possibility

• Membership should change only between sprints


Roles Scrum framework


Artifacts


Ceremonies

Sprint planning• Team selects items from the product

backlog they can commit to completing• Sprint backlog is created

• Tasks are identified and each is estimated (1-16 hours)

• Collaboratively, not done alone by the ScrumMaster

• High-level design is consideredAs a vacation planner, I want to see photos of the hotels.

Code the middle tier (8 hours)Code the user interface (4)Write test fixtures (4)Code the foo class (6)Update performance tests (4)

The daily scrum• Parameters

• Daily

• 15-minutes

• Stand-up

• Not for problem solving• Whole world is invited

• Only team members, ScrumMaster, product owner, can talk

• Helps avoid other unnecessary meetings

Everyone answers 3 questions

• These are not status for the ScrumMaster• They are commitments in front of peers

What did you do yesterday?1

What will you do today?2

Is anything in your way?3

The sprint demo

• Team presents what it accomplished during the sprint

• Typically takes the form of a demo of new features or underlying architecture

• Informal• 2-hour prep time rule

• No slides

• Whole team participates• Invite the world

Sprint retrospective• Periodically take a look at what is and is not

working• Typically 15–30 minutes• Done after every sprint• Whole team participates

• ScrumMaster• Product owner• Team• Possibly customers and others


Roles

Scrum framework


Ceremonies


Artifacts

Product backlog• The requirements• A list of all desired

work on the project• Ideally expressed such

that each item has value to the users or customers of the product

• Prioritized by the product owner

• Reprioritized at the start of each sprint

This is the product backlog

A sample product backlogBacklog item Estimate

Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-per-available-room)

8

Improve exception handling 8

... 30

... 50

A sprint burndown chartH

ours

Prototyping

System prototyping

• Prototyping is the rapid development of a system• In the past, the developed system was normally

thought of as inferior in some way to the required system so further development was required

• Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach

Prototyping benefits

• Misunderstandings between software users and developers are exposed

• Missing services may be detected and confusing services may be identified

• A working system is available early in the process• The prototype may serve as a basis for deriving a

system specification• The system can support user training and system

testing

Prototyping benefits

• Improved system usability• Closer match to the system needed• Improved design quality• Improved maintainability• Reduced overall development effort

Prototyping in the software process

• Evolutionary prototyping• An approach to system development where an initial

prototype is produced and refined through a number of stages to the final system

• Throw-away prototyping• A prototype which is usually a practical implementation

of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process

Evolutionary prototyping

Evolutionary prototyping advantages

• Accelerated delivery of the system• Rapid delivery and deployment are sometimes more

important than functionality or long-term software maintainability

• User engagement with the system• Not only is the system more likely to meet user

requirements, they are more likely to commit to the use of the system

Throw-away prototyping

• Used to reduce requirements risk• The prototype is developed from an initial

specification, delivered for experiment then discarded• The throw-away prototype should not be considered

as a final system• Some system characteristics may have been left out• There is no specification for long-term maintenance• The system will be poorly structured and difficult to

maintain

Throw-away prototyping

Key points

• A prototype can be used to give end-users a concrete impression of the system’s capabilities

• Prototyping is becoming increasingly used for system development where rapid development is essential

• Throw-away prototyping is used to understand the system requirements

• In evolutionary prototyping, the system is developed by evolving an initial version to the final version

Key points

• Rapid development of prototypes is essential. This may require leaving out functionality or relaxing non-functional constraints

• Prototyping techniques include the use of very high-level languages, database programming and prototype construction from reusable components

• Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified. Users must be involved in prototype evaluation

Any Questions?

software cycles

Technology

phase of waterfall model

water fall model

waterfall model isoften

brief description of

stage of awaterfall

brief description of

formal description

customer requirements