1. MyOcean2 First Annual Meeting – 17-18 April 2013 WP2.3 Service Engineering MyOcean2 First Annual Meeting – Cork /16-17 April 2013

2. Service engineering -“WHAT”: Define a solution that answers Service Definition (Products & all user interfaces) - “HOW” : Methodology to reach the defined solution Service Engineering Main Objectives (1/4)

3. MyOcean2 First Annual Meeting – 17-18 April 2013 Provide methods and means to be sure that MyOcean partners share the same... - Understanding of Users needs & Stakeholders expectations - Vision of solution (technical and process parts) - Methodology to reach MyOcean Solution - (Operation + Development + Project) x (Technical + Processes) Service Engineering Main Objectives (2/4)

4. Service Engineering Main Objectives (3/4) MyOcean2 First Annual Meeting – 17-18 April 2013 About sub-systems: - Allocate requirements to sub-systems (42 PUs, 24 DUs, 1 CIS) - Mainly at interfaces with other sub-systems - Organize and make Integration of sub-systems - Organize and make Verification and Validation of the integrated solution

5. Service Engineering Main Objectives (4/4) MyOcean2 First Annual Meeting – 17-18 April 2013 - Define and Allocate roles to service desks, service managers, product managers,... - Organize continuous improvement of these Operational processes - Work with project management on Project & Development processes About processes:

6. Service Engineering Partnership WP2.3 Service Engineering Technical Activities WP2.3.1 Interface with PMO for technical management tasks WP2.3.2 CLS Edisoft CLS System engineering Service engineering Testing Altamira Edisoft WP2 – WP2.1 lead Service Evolution, management and support Mercator-Ocean WP2.2 Service Definition WP2.4 Service transition WP2.5 Service operation, Service Desk WP2.5 Service monitoring

7. Service Engineering Partnership WP2.3 Service Engineering Technical Activities WP2.3.1 Interface with PMO for technical management tasks WP2.3.2 CLS Edisoft CLS System engineering Service engineering Testing Altamira Edisoft WP2 – WP2.1 lead Service Evolution, management and support Mercator-Ocean WP2.2 Service Definition WP2.4 Service transition WP2.5 Service operation, Service Desk WP2.5 Service monitoring After more than 3 years, Top-Level Engineering activities are really shared between MyOcean Partners After more than 3 years, Top-Level Engineering activities are really shared between MyOcean Partners

8. Achievements (1/5)  DU: Download / Visualization  Service Management Tools : tools to manage incidents, user requests, CRM, …  DU: Download / Visualization  Service Management Tools : tools to manage incidents, user requests, CRM, …  Processes for Service Desks  Incident Mngt, …  All processes needed for service management  Processes for Service Desks  Incident Mngt, …  All processes needed for service management  Product Management  Product Quality Management  Product Management  Product Quality Management  PU  Product Validation tools  PU  Product Validation tools Products User Interface Services MyOcean Operational System Automated Operational Processes User point of view

9. Achievements (2/5) Impact on Testing, Transition, Release

10. Achievement (3/5) Failure impact analysis  Very strong constraints on Central Authentication System  Need of a central service desk and tool (CRM) to manage user requests and be sure that someone has answered ...

11. MyOcean2 First Annual Meeting – 17-18 April 2013 Operational processes Good improvement of OPM (Operational Process Manual) Still relying on ITIL recommendations, With strong implication of all process owners Good V3 sub-system acceptance (mid January 2013) Good level of deliverables (product quality report, system description, test reports on interfaces,...) Most V3 systems ready for V3 tests and integration while V2 ones operational Information to analyse change impacts Improvement of system description, Description of product dependencies. Achievements (4/5)

12. MyOcean2 First Annual Meeting – 17-18 April 2013 Improvement of product organization and search functionality. It is a collective task impossible in such time without specification, organization, share and understanding of the same objective. Users ! Service Definition, Product managers, Technical teams in charge of DUs, CIS team, Service managers, Transition team, Communication, Service Desk Users Achievements (5/5)

13. Next Steps (1/4) No new functionality About the solution : No new functionality but improvement of existing  Improve performances (Download and View too slow) Requirements and OLA Not yet within SLA  Increase efficiency and integration of main functions interfaces (Search-Discovering – View-Download) while keeping geographical distributed architecture  Increase technical cooperation with SeaDataNet

14. Next Steps (2/4) About schedule:  Provide top-level requirements sooner: To prepare and animate discussion at Executive Committee, To allocate requirements in time to sub-systems, To be on time at V4 Top-level PDR.

15. Next Steps (3/4) Method and organization  Improve Tests to find inconsistencies between Specification, Information provided to users (catalogue, PUM, QUID), and.... the reality.  Improve Integration & Verification tests and phase organization: Too long for double production, double dissemination, Not enough time at top-level to tests every things  Improving testing organization  Be more strict on sub-system acceptances  Reduce release content More minor releases and a Smaller major release

16. Next Steps (4/4) Method and organization  Improvement of release management (WP1 with Engineering support) Take advantage that now (V3), it is easy to modify catalogue content Define all different transition types (with Service Transition team & Product managers) : what is a new product, a product upgrade, with double production, with double dissemination, with double catalogue entries, Associated tests need according to release type,...  Keep constructive relationships with High level review groups, with EC evaluators and external experts.

17. Thank you