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
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
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
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
Traditional vs. Agile
Requirements Design Implementation Verification Maintenance
Pau Minoves @ CTX | [email protected] 21/5/2010
24
Traditional vs. Agile
Pau Minoves @ CTX | [email protected] 21/5/2010
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
Pau Minoves @ CTX | [email protected] 21/5/2010
26
SCRUM Meetings
Scrum Planni
ng
Daily Scru
m
Sprint revie
w
Scrum retrospective
Sprint
Pau Minoves @ CTX | [email protected] 21/5/2010
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
Pau Minoves @ CTX | [email protected] 21/5/2010
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 | [email protected] 21/5/2010
• SA1 Software Refinement
• SA1 Software Refinement
• T5.1 + T5.2 + T6.2 + T7.1
• T5.1 + T5.2 + T6.2 + T7.1
• SA1 Software Refinement
• 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
Pau Minoves @ CTX | [email protected] 21/5/2010
EFFORT DISTRIBUTION
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!