Session 4.

Software Development LifecycleRAM N SANGWAN

WWW.RNSANGWAN.COM

YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA

TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM

1

Agenda

• SDLC and SDLC Models

• Waterfall Model

• Incremental Model

• Agile SDLC Models

• Rational Unify Process (RUP)

• Extreme Programming (XP)

• Feature Driven Development (FDD)

• Adaptive Software Development (ASD)

• Rapid Application Development (RAD)

• V-Shaped SDLC Model

2

SDLC

The Software Development Life Cycle (SDLC),

“is the entire process of formal, logical steps taken to develop a

software product. The concept generally refers to computer or

information systems.”

3

4

SDLC Model (s)

A framework (s) that describes the activities performed at each

stage of a software development project.

5

Waterfall Model

• Requirements – defines needed

information, function, behavior,

performance and interfaces.

• Design – data structures, software

architecture, interface representations,

algorithmic details.

• Implementation – source code,

database, user documentation, testing.

6

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

7

Waterfall Deficiencies

• All requirements must be known upfront

• Deliverables created for each phase are considered frozen –inhibits flexibility

• Can give a false impression of progress

• Does not reflect problem-solving nature of softwaredevelopment – iterations of phases

• Integration is one big bang at the end

• Little opportunity for customer to preview the system (until it maybe too late)

8

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.

9

Incremental Model

• Construct a partialimplementation of a totalsystem

• Then slowly add increasedfunctionality

• The incremental modelprioritizes requirements of thesystem and then implementsthem in groups.

10

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

11

Incremental Model Weaknesses

• Requires good planning and design

• Requires early definition of a complete and fully functionalsystem to allow for the definition of increments

• Well-defined module interfaces are required (some will bedeveloped long before others)

• Total cost of the complete system is not lower

12

When to use the Incremental Model

• Risk, funding, schedule, program complexity, or need 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

13

Iterative and incremental process ExampleSuppose a customer wants to develop a word processing package

• Incremental approach:

provide just Creation functions in Release 1, then both Creation andOrganization in Release 2, finally add Formatting in Release 3, …

• Iterative approach:

provide primitive forms of all three functions in Release 1, thenenhance them in subsequent releases

Many organizations combine iterative and incremental approaches

14

Agile SDLC’s

• Speed up or bypass one or more life cycle phases

• Usually less formal and reduced scope

• Used for time-critical applications

• Used in organizations that employ disciplined methods

15

Some of Agile Methods

• Rational Unify Process (RUP)

• Extreme Programming (XP)

• Feature Driven Development (FDD)

• Adaptive Software Development (ASD)

• Rapid Application Development (RAD)

16

Rational Unified Process (RUP)

• Developed by “three amigos” at Rational Software (IBM)

• Grady Booch, Ivar Jacobson, and Jim Rumbaugh

• Unified Modeling Language (UML) is a set of graphical and linguistic

notations for modeling systems, not a process or method

• The three amigos also developed Rational Unified Process (RUP)

• Interestingly different from the traditional waterfall model

• Highly iterative and incremental process

• Software product is not released in one big bang at end of project

• Instead, developed and released in pieces (prototypes, partial releases,beta, etc.)

17

Extreme Programming - XP

For small-to-medium-sized teams developing software with vagueor rapidly changing requirements

Coding is the key activity throughout a software project

• Communication among teammates is done with code

• Life cycle and behavior of complex objects defined in testcases – again in code

18

XP Practices

1. Planning game – determine scope of the next release bycombining business priorities and technical estimates

2. Small releases – put a simple system into production, then releasenew versions in very short cycle

3. Metaphor – all development is guided by a simple shared story ofhow the whole system works

4. Simple design – system is designed as simply as possible (extracomplexity removed as soon as found)

5. Testing – programmers continuously write unit tests; customers writetests for features

6. Refactoring – programmers continuously restructure the systemwithout changing its behavior to remove duplication and simplify

19

XP Practices

7. Pair-programming -- all production code is written with twoprogrammers at one machine

8. Collective ownership – anyone can change any codeanywhere in the system at any time.

9. Continuous integration – integrate and build the system manytimes a day – every time a task is completed.

10. 40-hour week – work no more than 40 hours a week as a rule

11. On-site customer – a user is on the team and available full-timeto answer questions

12. Coding standards – programmers write all code in accordancewith rules emphasizing communication through the code

20

XP is “extreme” because

Commonsense practices taken to extreme levels• If code reviews are good, review code all the time (pair

programming)

• If testing is good, everybody will test all the time

• If simplicity is good, keep the system in the simplest design thatsupports its current functionality. (simplest thing that works)

• If design is good, everybody will design daily (refactoring)

• If architecture is important, everybody will work at defining andrefining the architecture (metaphor)

• If integration testing is important, build and integrate test severaltimes a day (continuous integration)

• If short iterations are good, make iterations really, really short

21

Feature Driven Design (FDD)

Five FDD process activities

1. Develop an overall model – Produce class and sequence diagrams from chiefarchitect meeting with domain experts and developers.

2. Build a features list – Identify all the features that support requirements.Features are functions that can be developed in two weeks and expressed inclient terms with the template: <action> <result> <object>

i.e. Calculate the total of a sale

3. Plan by feature -- the development staff plans the development sequence offeatures

4. Design by feature -- the team produces sequence diagrams for the selectedfeatures

5. Build by feature – the team writes and tests the code

22

Prototyping model

• The prototyping model requires that before carrying out the

development of the actual software , a working prototype of the

system should be built.

A prototype is a toy implementation of the system.

• In many instances the client only has a general view of what is

expected from the software product. In such a scenario where

there is an absence of detailed information regarding the input to

the system, the processing needs and the output requirements, the

prototyping model may be employed.

23

Iterative developmentDesign

Implement

Test

Maintain

Acceptance By customer

Prototype development

Requirements

gathering

Quick design

Build prototypeRefine requirements

incorporating

Customer suggestion

Customer evaluation

Of prototype

24

Steps of Prototyping Model1. Requirements Gathering and Analysis: : The requirements of the system are

defined in detail. The user is interviewed in order to know the requirements of the

system.

2. Quick Design: A preliminary design or quick design for the system is created . It

includes the important aspects of the system, which gives an idea of the system to

the user.

3. Build Prototype : Information gathering from quick design is modified to form a

prototype .

4. Assessment or user evaluation: Next , the proposed system is presented to the userfor consideration as part of the development process.

5. Prototype Refinement: Once the user evaluates the prototype, it is refined

according to the requirements .

6. Engineer Product : The final system is thoroughly evaluated and tested followedby routine maintenance on a continuing basis to prevent large-scale failures and

to minimize downtime.

25

Advantages of Prototyping Model

• Provides a working model to the user early in the process, enabling

early assessment and increasing user confidence.

• The developer gains experience and insight by developing a

prototype , thereby resulting in better implementation of

requirements.

• Helps in reducing risks associated with the project.

• The prototyping model serves to clarify requirements , which are not

clear , hence reducing ambiguity and improving communication

between the developer and the user.

• There is a great involvement of users in software development .

Hence, the requirement of the users are met to the greatest extent.

26

Disadvantages of Prototyping Model

• If the user is not satisfied with the developed prototype, then a new

prototype is developed . Thus, time consuming and expensive.

• The developer loses focus of the real purpose of prototype and

compromises on the quality of the product.

• Prototyping can lead to false expectations. It often creates a

situation where the user believes that the development of the

system is finished when it is not.

• The primary goal of prototyping is rapid development. Thus , the

design of the system may suffer as it is built in a series of layers

without considering integration of all the other components.

27

When to use Prototype Model

• 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.

28

V-Shaped SDLC Model

• A variant of the Waterfall

that emphasizes the

verification and validation of

the product.

• Testing of the product is

planned in parallel with a

corresponding phase of

development

29

V-Shaped Steps

1. Project and Requirements Planning – allocate resources

2. Product Requirements and Specification Analysis – complete specification of thesoftware system

3. Architecture or High-Level Design – defines how software functions fulfill thedesign

4. Detailed Design – develop algorithms for each architectural component

5. Production, operation and maintenance – provide for enhancement andcorrections

6. System and acceptance testing – check the entire software system in itsenvironment

7. Integration and Testing – check that modules interconnect correctly

8. Unit testing – check that each module acts as expected

9. Coding – transform algorithms into software

30

V-Shaped Strengths

• Emphasize planning for verification and validation of the

product in early stages of product development

• Each deliverable must be testable

• Project management can track progress by milestones

• Easy to use

31

V-Shaped Weaknesses

• Does not easily handle concurrent events

• Does not handle iterations or phases

• Does not easily handle dynamic changes in requirements

• Does not contain risk analysis activities

32

When to use the V-Shaped Model

• Excellent choice for systems requiring high reliability – hospitalpatient control applications

• All requirements are known up-front

• When it can be modified to handle changing requirementsbeyond analysis phase

• Solution and technology are known.

33

ThankyouWWW.RNSANGWAN.COM

34