mantychore fp7 wp4 (sa1) - software refinement. objectives main duties – analysis of user...

Mantychore FP7

WP4 (SA1) - Software Refinement

Objectives

• Main duties– Analysis of User Requirements– Implementation– Support and bug fixing

This activity will focus on the analysis of the user requirements (from NRENs and virtual research communities) and implement them. The implementation phase will include a subtask to solve the bugs that later can be found when the service will be deployed in an operational environment and used by the NRENs and the virtual research communities.

SA1 Software Refinement

• How?• SCRUM Development methodology

Requirements Bug Reports

Working Software

The Software WPManagement

10

Service56

Software39.5

Marketplace17

GSN14.5

Dissemination10.5 Users

9

WP4 relationships

Tasks

• SA4 Tasks:– T4.1 Requirements Analysis– T4.2 Software Development: tools integration and

refinement• Related Tasks:– T5.1 Deployment and operation of MANTYCHORE– T5.2 Using MANTYCHORE services– SA2 Dissemination (Demos)– T6.2 Implementation of the Marketplace prototype– T7.1 Integration between MANTYCHORE and GSN

Tasks

T4.2 Software Refinement

T4.1 Requirements

Analysis

SA2 Dissemination

T6.2 Marketplace

T7.1 GSN Integration

T5.2 Using MANTYCHORE

Services

•Specification•Bug Reports•Feature Requests•Feature feedback

Requirements Working Software

•Deployable•Usable•Complete

Milestones and Deliverables

• MS14 Requirements analysis completed – Month 5– D4.1 Requirements Analysis report

• Contains the requirements– Clearified– Structured– Prioritized!

• MS15 Marketplace integrated in IP Network Services– Month 22 • MS16 Zero-Carbon virtual infrastructures integrated in IP

Network services – Month 27• MS17 Software development completed – Month 30

– D4.2 Software development report (R/P)• Summary of the software tools created• Software packaged version

Milestones and Deliverables

• MS14 Requirements analysis completed – Month 5– D4.1 Requirements Analysis report

• MS15 Marketplace integrated in IP Network Services– Month 22 • MS16 Zero-Carbon virtual infrastructures integrated in IP Network services –

Month 27• MS17 Software development completed – Month 30

– D4.2 Software development report (R/P)

Dependencies on Deliverables• JRA1 – Marketplace– MS21 D6.1 – Infrastructure Marketplace Mechanisms

Study M14– MS22 D5.2 – Implementation of the Marketplace

Report M20• JRA2 – GSN– MS24 D7.1 – Integration between MANTYCHORE and

GSN Report M16– MS25 D7.2 – Networks Migration Tests Report M25

TASKS – T4.1Requirements Analysis

T4.1 Requirements Analysis

• Each NREN needs to create initial list of requirements– And Users!

• On site– Meet and discuss• Developers <-> Users

– Gather requirements by observing operators work

T4.1 Requirements Analysis

• Leader HEAnet.• Needs to contain:– Functional requirements– Non functional requirements

• Cost of failure• Expensive!

– Expected operational environments• Vendors• Setups• pilot < dev

• We need to define use cases!

Pau Minoves @ CTX | [email protected] 14

Crisis? Which crisis?

• Some numbers:– On average, only 42% of initially proposed features are delivered.– Developers average 10 lines of code per day.– ¾ don’t meet customer requirements.– Between 50% and 200% of projects cost spend on maintenance.

The Standish Group Caos Report 199

52.7%

31.1%

16.2%

Projects

Costs or takes twice

Cancelled

Successful

21/5/2010

SA Gantt

Partners

• Work expected from each partner– Provide requirements?

• Requirements from the Infrastructure provider and operator:– HEAnet (leads T4.1)– NORDUnet

• Requirements from the Infrastructure user and operator– UNI-C– Uessex– TCD

TASKS – T4.2Software Refinement

T4.2 Software Development

• We use SCRUM– Iterative

• Initial Objectives– Integration with Argia / Ether– Implementation of NRENs requirements– Implementation of research communities requirements– Integration with EduGAIN (AAI Infrastructure)– Implementation of GSN requirements

SCRUM facts

• SCRUM is an Agile Methodology• Agile Methodologies are very famous since >2001

– Focus on getting things done.• Working Software vs. “Complete” documentation• Customer involvement vs. Conctract negotiation• Evolving and adapting vs. Early “Big Plan”

• It is very popular.– 40% of companies that go Agile, go SCRUM.

• Created in Toyota in 1985• Huge implementation ratio in Germany and Scandinavian

contries– For instance, SAP, Microsoft, Ericsson, etc.

22

Traditional vs. Agile

Requirements Design Implementation Verification Maintenance

Pau Minoves @ CTX | [email protected] 21/5/2010

Start

What do you think the

user wants

What can be done…

What the user really

needs…

23


Requirements Design Implementation Verification Maintenance


24



StartWhat do you think the user

wants

What the user needs

25

SCRUMRoles Artifacts Meetings

Team Member Product Backlog Sprint Planning, Retrospective

Scrum Master Sprint Backlog Daily Scrum

Product Owner Scrum board Sprint Review


26

SCRUM Meetings

Scrum Planni

ng

Daily Scru

m

Sprint revie

w

Scrum retrospective

Sprint


27

SCRUM Sprint

• Sprint “rules”:– 2-4 weeks– No changes• Scrum Master’s responsibility

– Must have a goal– Must end with a demo• Must end with something shippable

– Do not disturb• Focus

Story

Scope

Impo

rtanc

eEstimate


28

SCRUM Meetings

• Sprint planning, the standard:– Presential meeting– The most important meeting.

• Bad planning == bad sprint

– ~ 4-8 hours– Decide which stories go (and fit) inside the sprint.– Setup a goal and a demo date at least.

• Define and agree on demo’s “done”.

– Scrum is and adaptative methodology

• Periodically take a look at what is and is not working


29

SCRUM Meetings

• Scrum planning:


• SA1 Software Refinement


• T5.1 + T5.2 + T6.2 + T7.1

• T5.1 + T5.2 + T6.2 + T7.1


• T5.1 + T5.2 + T6.2 + T7.1

Development Deployment / Installation

Usage / Testing / Demos

Feedback

The Feedback cycle

31

SCRUM Meetings

• Sprint planning, our implementation:– One month sprints– We’ll ship a working version at the end of each sprint– Users have until next planning meeting to:

• Evaluate on their networks, provide feedback• Fill bug reports

– In the monthly planning meeting we:• Discuss current working version• Prioritize next sprint requirements

– Define a scope and a goal

– Use the issue tracker!• Keep the meetings short


EFFORT DISTRIBUTION

Effort Distribution

FORESEEN RISKS

Foreseen Risks• R4.1 Delay on Requirements analysis– Plan in advance!

• The more advanced the project is, the harder it will be for SA1 to handle your feedback

• R4.2 Delay on Software Development– We’ll work to ship early versions soon– In any point in time, there must be a working version

• I’ll add my own:– Development test bed not representing user’s test bed.– We need to simulate a use case in order to develop for it!

THANKS!

mantychore fp7 wp4 (sa1) - software refinement. objectives main duties – analysis of user...

Documents