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 WP

WP4 relationships

TASKS

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.1 Requirements 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!

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 Pau Minov CTX | pau.m t.net 21/5/

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.2 Software 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

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.

Traditional vs. Agile RequirementsDesignImplementationVerificationMaintenance Pau CTX | Start What do you think the user wants What can be done… What the user really needs…

Traditional vs. Agile RequirementsDesignImplementationVerificationMaintenance Pau CTX |

Traditional vs. Agile Pau CTX | Start What do you think the user wants What the user needs

SCRUM RolesArtifactsMeetings Team MemberProduct BacklogSprint Planning, Retrospective Scrum MasterSprint BacklogDaily Scrum Product OwnerScrum boardSprint Review Pau CTX |

SCRUM Meetings Scrum Planning Daily ScrumSprint review Scrum retrospective Sprint Pau CTX |

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 Importance Estimate Pau CTX |

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 Pau CTX |

SCRUM Meetings Scrum planning: Pau CTX |

T5.1 + T5.2 + T6.2 + T7.1 SA1 Software Refinement T5.1 + T5.2 + T6.2 + T7.1 SA1 Software Refinement T5.1 + T5.2 + T6.2 + T7.1 SA1 Software Refinement Development Deployment / Installation Usage / Testing / Demos Feedback The Feedback cycle

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 Pau CTX |

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!