1. Mantychore FP7 WP4 (SA1) - Software Refinement

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

3. The Software WP

4. WP4 relationships

5. TASKS

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

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

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

9. 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)

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

11. TASKS – T4.1 Requirements Analysis

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

13. 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!

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 Pau Minov es @ CTX | pau.m inoves @i2ca t.net 21/5/2010 14

15. SA Gantt

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

18. TASKS – T4.2 Software Refinement

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

20. SCRUM

21. 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 RequirementsDesignImplementationVerificationMaintenance Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201022 Start What do you think the user wants What can be done… What the user really needs…

23. Traditional vs. Agile RequirementsDesignImplementationVerificationMaintenance Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201023

24. Traditional vs. Agile Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201024 Start What do you think the user wants What the user needs

25. SCRUM RolesArtifactsMeetings Team MemberProduct BacklogSprint Planning, Retrospective Scrum MasterSprint BacklogDaily Scrum Product OwnerScrum boardSprint Review Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201025

26. SCRUM Meetings Scrum Planning Daily ScrumSprint review Scrum retrospective Sprint Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201026

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 Importance Estimate Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201027

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 Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201028

29. SCRUM Meetings Scrum planning: Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201029

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

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 Pau Minoves @ CTX | pau.minoves@i2cat.net21/5/201031

32. EFFORT DISTRIBUTION

33. Effort Distribution

35. FORESEEN RISKS

36. 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!

37. THANKS!