SDLC AND AGILE RECAP

Hope you enjoyed this learning journey.

SDLC AND AGILE RECAP

• Fire exits• Toilets • Breaks

HOUSEKEEPING

“The process of taking a set of business requirements through a series of structured stages and translating them into an operational IT system.”

‘Developing Information Systems’

What is Systems Development?

4

Elements of a framework method

Philosophy

Principles

Pro

cess

Peo

ple

Pro

du

cts

Pra

ctic

es

5

Elements of the System Development Lifecycle

Context

S/W Lifecycle

Techniques

Process Roles Deliverables

Context

Must be considered before startingRelease plan – Single or multipleLevel of skills and expertise – Preferred delivery styleLocation of teams and stakeholders – Single site or dispersedRequirements – Audit, quality, regulatory, complexity and stabilityTechnology to be used – Tried and tested or new?

6

Context

S/W Lifecycle

Techniques


Lifecycle

Describes stages to follow: Plan, design, build, test, and deliverBasic approachesLinear – Sequential, or step-by-stepEvolutionary – Iterative evolving through prototypes and progressive versions

7

Context

S/W Lifecycle

Techniques


Process

Set of steps and actions followed to deliver outcomes within stagesMethods and standards support the framework within SDLCInclude defined roles, deliverables, techniques, modelsPrescriptive – Specific SDLCsAgnostic – Various SDLCsDependent on context and lifecycle chosen

8

Context

S/W Lifecycle

Techniques


Roles

People that carry out tasks within various SDLCsSpecific to particular SDLC or generic – Various titlesInclude Business, Project, Technical and Support roles

9

Context

S/W Lifecycle

Techniques


Deliverables

People that carry out tasks within various SDLCsSpecific to particular SDLC or generic – Various titlesInclude Business, Project, Technical and Support roles

10

Context

S/W Lifecycle

Techniques


Deliverables

Numerous – Choice dependent on team, organisation, SDLCExamplesMilitary – Ministry of Defence Architecture Framework (MoDAF)Commercial payment milestones and reviews – Waterfall Rapid prototypes – AgileMany SDLCs – Strengths / weaknesses, suit particular projects

11

Context

S/W Lifecycle

Techniques


Initiation

Systems Concept

and Developme

nt

Planning Requirements Analysis

Design

Development

Integration and Test

Implementation

Operations and

Maintenance

Disposition

Main Stages of System Development – More Detailed

Not to be confused with a Software Development Lifecycle – end to end perspective

Alternative view of a System Development Life Cycle - Detail

A System Development Life Cycle (SDLC) is a framework describing a process to…

• Understand• Plan• Build• Test• Deploy

…an information system

Can apply to• Hardware• Software• Both

13

Feasibility Study

Requirements Analysis

Design

Testing

Code Development

Deployment / Implementation

Maintenance

Requirement Analysis

Gain understanding of what the business needs the proposed system to doBusiness Analysts elicit, analyse, document, and validate requirementsDecide how to store, manage, access, and update requirementsKey input to design; requirements traced through SDLCLevel of detail influenced by SDLCAlso known as Requirements EngineeringMake use of tools such as UML

14

Feasibility Study


Design

Testing

Code Development


Maintenance

Design

Evaluate possible solutions that meet requirements

Chosen design elaborated on to sufficient detail To allow the start of development

Make use of tools such as UML

15

Feasibility Study


Design

Testing

Code Development


Maintenance

Code Development

Hardware and software technical components created, procured or configured

Follow design to ensure system does what is required

Also known as Programming or Build

Make use of tools such as automated build tools and code coverage and testing frameworks

16

Feasibility Study


Design

Testing

Code Development


Maintenance

Testing

Components produced tested to ensure working properly and does what supposed to do]

Different levels of testing• Unit• Integration• System• User Acceptance


17

Feasibility Study


Design

Testing

Code Development


Maintenance


Completed system needs to be commissioned in ‘live’ environment

• Also known as operation or production environment

• Developed in ‘test’ environment to protect ‘live’ systems

Needs to be carefully planned, understood and managed


18

Feasibility Study


Design

Testing

Code Development


Maintenance

Maintenance

More than just correcting faults or keeping the system in good running order

• 20% Corrective• 80% Enhancements

Depends on• Development strategy• Lifetime of operation

Maintenance Types• Corrective• Adaptive• Perfective• Preventative

19

Feasibility Study


Design

Testing

Code Development


Maintenance

Agile Approach

Each slice an increment of the product

Analysis

Design

Code

Code

Time

Makes heavy use of tools such as automated build tools and code coverage and testing frameworks

What is Important in Agile?

Values Principles Practices Rules

Agile PrinciplesHighest priority is to satisfy customer through early and continuous delivery of working software

Welcome requirement changes during development which enhance competitive advantage

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

Business people and developers must work together daily throughout the project

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Agile PrinciplesWorking software is the primary measure of progress

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

Continuous attention to technical excellence and good design enhances agility

Simplicity – the art of maximising the amount of work not done – is essential

The best architectures, requirements, and designs emerge from self-organising teams

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

Traditional vs Agile

Traditional Agile

Expects that low-level requirements evolve through understanding

Low-Level requirements are defined up front

Delivers increments of system in an iterative manner

Delivers fully developed system

Contingency in prioritised requirements

Contingency in resource

Planned active user involvement throughout the lifecycle

Typical user involvement at start and end of project

Traditional vs Agile

Traditional Agile

Testing Integrated throughout lifecycle

Discreet testing phase at end of project

Prefers co-located teamsDispersed teams

Skills and roles used across lifecycle - no hand-offsSkills and roles related to stages

Product based planningActivity based planning

Turning Convention Upside Down

Requirements(Functionality & Quality)

Time Resources

Agile

ResourcesTime

variable

fixed

Requirements(Functionality & Quality)

Waterfall

“The aim of Kanban is to make troubles come to the surface and to link them

to a Kaizen Activity.”

– Talichi Ohno

LEAN AND KANBAN

Regular communication

New information, changing priorities, progress updates are communicated daily between the business owner and the implementation team

The team meets every day in the same time and place –the daily stand-up meeting

28

USE AGILE AND LEAN TO DEMONSTRATE PROGRESS

Behaviour Checklist

Behaviour To Encourage Behaviour to Discourage

Allow freedom of expression Closed and secretive environments

Encourage everyone to have their say Ignore what you are being told

Be patient with quiet folks Using feedback in a negative or nefarious way

Ensure management and HR understand why change is needed Being impatient

Refine surveys or create new ones Do as I say, not as I do!

Get management to contribute

30

A measurement system helps make the software product more visible

Reference

VISUALISE WHAT YOU DO

31

A lightweight agile project management method formalised by Ken Schwaber in 1996

Key characteristics include:

• Small, cross functional teams• Close working• 30 day sprints deliver incremental releases• Self-directed, empowered teams• Scrum Master facilitates work and reinforces principles• Product backlog prioritises sprint activities

SCRUM

Scrum Process Overview

SprintBacklog

ProductBacklog Potentially

ShippableProduct

Increment

2-4 Weeks

Scrum board

Task A

Story #1

Task B Task D

Task C Task B

Task C

Task A Task B

Task A

Task C

Story #1

Story #1

StoriesNot

started In progress Done

Kanban Boards

----------------

-----

----------------

-----

----------------

-----

----------------

-----

----------------

-----

----------------

-----

----------------

-----

----------------

-----

Backlog Research Implement Validate Release

In progress done In progress done In progress done

“If you focus on driving utilisation up,

things will slow down.”

– Mary and Tom Poppenbeck

LIMIT WORK IN PROGRESS

“When we emphasise flow, we focus on queues rather than timelines.”

– Taiicho Ohno

MANAGE THE FLOW

“Ignoring feedback merely means that the system will eventually experience a

massive unpleasant surprise rather than a small unpleasant surprise.”

John Gall

IMPLEMENT FEEDBACK LOOPS

38

Agile Roles Product owner – custodian of the vision for the product, represents the customer

Scrum Master – helps the team best use Scrum to build the product, shields the team from outside influence

Development team – build the product

39

Product Owner The voice of the customer, acting as an expert to the development teamDefines the work to be done, and prioritises that workUnderstands what’s important to the customer

The real customer

The Product Owner

Customers can be a very varied group of people

Scrum MasterHelps the team best use Scrum to build the productHelps them to focus on the project• Protects them from organisational disruptions and internal distractions like an area where

the teach cannot focusEnsure that the team execute the Scrum process in spirit• They control the process, not to be confused with the role of the project manager who is

responsible for the workload

40

Development TeamScrum Master

41

Development Team

Self-organisedWork with Scrum master to develop the productPrioritise the product backlogDefine the number of sprintsDefine the stories to be tackled in each sprintDefine DONE

Requirements to StoriesRequirements come in varied formsScrum team translate those requirements in StoriesStory is structured as:• As a <role>• I want <capability>• So that <value>• Optional: <acceptance criteria>

42

As a Trader I want to be able to view the streamed data at a later point in time so that to provide evidence to audit / regulators when being audited

Acceptance criteria: Historic data is displayed in a tabular and graphical manner

Story Points NOT TimeTraditionally when prioritising and scheduling tasks, analysts would use Complexity and Time as key factors

This has proven to be a unsatisfactory way of prioritising and scheduling workloads

Recommended approach – story points• A notional value assigned to a task that represents its complexity and perceived time to deliver

Techniques for assigning story points• Estimation Poker - https://www.planningpoker.com/

43

https://www.planningpoker.com/

Hope you enjoyed this learning journey.

THANK YOU

Documents

SDLC AND AGILE RECAP