System Development Life Cycle (SDLC)

October 2016

2

Agenda

1) A.S. Watson Group Introduction

2) System Development Life Cycle (SDLC)

3

A.S. Watson Group Introduction

4

A.S. Watson Group Introduction

12,800

Anniversary

175th

Retail Stores Worldwide

25

Markets

13

Retail Brands

5

A.S. Watson Group Introduction

6

INSTANCES

Asia 64 Europe 180

244 628 Asia 297

Europe 331

10,072

DATABASES

12,800 Asia 6,949

Europe 5,851

Group Information Technology in ASW

7

Group IT Solutions

Digital & CRM

CLPE RSIM

Store Systems

WES

Merchandising Systems Dashboard Systems WINS

People Counter

8

System Development Life Cycle (SDLC)

9

WHY? System Development Life Cycle

Why do we need SDLC?

10

WHY SDLC?

1) Ensure an application meets the needs of it’s users

2) Complete within Schedule & Budget

11

WHAT is SDLC?

A Process used to Analyze, Design, Develop, Test & Deploy

12

SDLC Methodologies

V-Shaped Waterfall Iterative

Spiral Big Bang Agile

The six most common SDLC Methodologies:

13

SDLC Methodologies

V-Shaped Waterfall Iterative

Spiral Big Bang Agile

The widely used:

14

Waterfall Waterfall

Process of software development is divided into separate phases

Typically, the outcome of one phase acts as the input for the next

phase sequentially

Video

15

Agile Agile

Tasks are divided to time boxes (small time frames) to deliver

specific features for a build/release

Iterative approach, working software build is delivered after each

iteration

Video

16

Waterfall vs Agile

17

Waterfall vs Agile (Summary)

Waterfall Agile

Phased Iterative and Incremental

Working software in Final Phase Working Software every build

Different People in Different Phases (Communication Overhead induced)

Same Set of People (Less overhead in Communication)

Verification is Done at Final Phase Verifiable in Every Build

Predictive Planning Adaptive Planning

Less Potential for Rework Customer Collaboration and Acceptance of

each feature as it’s developed

18

When to use Waterfall or Agile

Requirements are very well documented, clear and fixed

Product definition is stable

Technology is understood and is not dynamic

There are no ambiguous requirements

Ample resources with required expertise are available to support

the product

Use Waterfall:

19

When to use Waterfall or Agile

Requirements are very limited when project starts

Customer can commit extensive involvement

Budget and/or schedule are flexible

Rapid “Time to Market”

Use Agile:

20

~ Q & A~