EasySDI Publish. Software requirements & specifications

Transcription

1 EasySDI Publish Automation of Geoservice creation Antoine Elbel Author Rémy Baud Author Bruno Magoni / Depth SA Technical expert bruno.magoni@depth.ch Xavier Mérour Customer xavier.merour@asitvd.ch Beatrice Amrhein BFH-Expert beatrice.amrhein@bfh.ch Change Management Date Version Reason of changes Person Structure of the document AE/RB Submitted for Review to B. Amrhein AE/RB Submitted for Review to X. Merour and B.Magoni AE First release AE/RB nd Upload on the SWS portal AE/RB Document & source repository Type Software Location Version control system SVN svn://asitvd.ch/master Forge Redmine Antoine Elbel & Rémy Baud page 1 sur 45

2 Table of content 1. Introduction Goal, scope of this document Global context Product scope Product context Foreseen Application Architecture Recommended Reading Used definitions, acronyms, Glossary Definitions / Glossary Acronyms Referenced Documents Competitive products, existing market Stakeholder definition Stakeholder profile User profile Licensing & legal notice General Overview Product functionalities Overview Business use cases Requirement / functionality Conventions Requirement template Description Naming Type Version V Priority P Subsystems Use cases UsUC01 Create Service UsUC02 Update Geoservice UsUC03 List Created geoservices UsUC04 Delete Geoservice UsUC05 Quick-View UsUC06 Upload Dataset UsUC07 Transform Dataset, UsUC08 Store Dataset UsUC09 Handle geoservice UsUC10 Publish geoservice AdUC01 Configure OWS Other non-functional requirements Specific location requirement Antoine Elbel & Rémy Baud page 2 sur 45

3 4. Documentation User s guide Online Help Administrator s guide Test concept Goal of testing Overview of planned tests Smoke testing Acceptance test System test Integration Tests Project activity Project plan Effort estimation Resource Plan Risk Management Annex Table of figures Antoine Elbel & Rémy Baud page 3 sur 45

4 1. Introduction 1.1 Goal, scope of this document This document shall support the development process of EasySDI Publish. All requirements and agreements shall be formulated as precise, complete, traceable and unambiguous as possible. Because a good picture is better than a thousand words, this document should avoid following situations: Figure 1: Communication problems in product development Global context In order to describe the environment in which EasySDI Publish belongs, a general overview of its domain is presented using a top-down approach The INSPIRE directive as root motivation. INSPIRE stands as the directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE). The general situation on Antoine Elbel & Rémy Baud page 4 sur 45

5 spatial information in Europe is one of fragmentation of datasets and sources, gaps in availability, lack of harmonisation between datasets at different geographical scales and duplication of information collection. These problems make it difficult to identify access and use data that is available. To counter this actual state, the initiative intends to trigger the creation of a European spatial information infrastructure that delivers to the users integrated spatial information services. These services should allow the users to identify and access spatial or geographical information from a wide range of sources, from the local level to the global level, in an inter-operable way for a variety of uses. The target users of INSPIRE include policy-makers, planners and managers at European, national and local level and the citizens and their organisations. Possible services available in a spatial data infrastructure (SDI) are: Discovery services making it possible to search for spatial datasets and spatial data services. Catalogue services, making it possible to search, browse metadata that describe datasets. View services making it possible to display, overlay spatial datasets and to display legend information. Download services, enabling copies of spatial datasets to be downloaded. Transformation services, enabling spatial datasets to be transformed. Invoke spatial data services services, enabling data services to be invoked, for spatial-analysis purpose. Further guidelines ensure that: Infrastructures should make it possible that spatial data are stored, made available and maintained at the most appropriate level. It is possible to combine spatial data from different sources across the Community in a consistent way and share them between several users and applications. It is possible for spatial data collected at one level of public authority to be shared between all the different levels of public authorities. Spatial data are made available under conditions that do not unduly restrict their extensive use. That it is easy to discover available spatial data, to evaluate their fitness for purpose and to know the conditions applicable to their use. (Source: INSPIRE directive) Figure 2: Inspire architecture Services are built on datasets which users and applications access via a standardized and interoperable way (mostly ISO and OGC standards). Queries are granted and filtered by the right management layer, which restricts request possibilities and accessible contents to user rights. The Inspire directive applies to the European Union member states, but its concept and vision may be extended to a larger scope of organisations which deal with spatial data infrastructure. Antoine Elbel & Rémy Baud page 5 sur 45

6 The OGC standards While ISO provides standards for a wide array of components, as in our case for data structures and models, OGC deals with standardization of geospatial content and services, data processing and sharing. There are currently 28 standards in the baseline, including: WMS: Web Map Service: Service used to request and retrieve an image representation of an underlying image or vector dataset. Figure 3: A WMS sample from NASA server The request supplied to retrieve this image was: mosaic&styles=pseudo&format=image/png&bgcolor=0xffffff&transparent=true&srs=e PSG:4326&BBOX= , , , &WIDTH=841&HEIGHT=927 WFS: Web Feature Service: Service used to request and retrieve a subset of vector data and related attributes, encapsulated into the open GML format. CSW: Service making it possible to access dataset metadata catalogue. WPS: Web Processing Service: Service enabling analyses and calculations on datasets. Most services use the remote procedure call principle based on HTTP, accepting both post and get methods. They also support SOAP and some services even comply with the REST principle. For instance, all services must implement a GetCapabilities method which returns the service capabilities (methods, parameters, content) as an xml description. Furthermore, other methods are mandatory depending on the type of the service (GetMap to retrieve an image from a WMS). Antoine Elbel & Rémy Baud page 6 sur 45

7 The EasySDI project EasySDI aims to implement the INSPIRE directive. It enables the realization of a geoportal based on a spatial data infrastructure which allows spatial data sharing in a standardized way across several providers and consumers, without imposing any specific tool or technology. Figure 4: EasySDI s concept Providers can enter products or metadata based on their available datasets. The portal enables the consumer to browse, query and view metadata, as well as order related products. The portal s services are accessible through a web-browser connecting to the website (Content Management System) or through a GIS software. In both cases the access request goes through the right management layer represented by the proxy. The CMS contains web-based features, so called Joomla! Components, that perform specialized business tasks. These are described in the picture below. Antoine Elbel & Rémy Baud page 7 sur 45

8 Figure 5: EasySDI stack and EasySDI Publish place. Existing features: Proxy: encryption, authentication and content filtering on OGC Web services (right management level). Shop: online order of datasets from multiple providers. Catalogue: online browsable metadata repository for datasets. Core: user, role and right definition over EasySDI and implements common features. Future or actual developments: Map: a cartographic website where datasets can be viewed, searched and queried. Billing: an online payment facility, billing upon geoservice consumption. Geoservice monitoring: a remote geoservice watching, uptime reports, alarms, actions and notifications in case of service failures. Report: reporting and statistics of accessed and used data. Installing the core component is mandatory, the other ones are optional The customer EasySDI Publish is developed to match the needs of the ASIT-VD (Association pour le system d information du territoire Vaudois -- Association for the geographic information system in the canton of Vaud). The main goal of this organization is to provide services for promoting geodata exchange and visibility for the interested partner inside the state of "Vaud". It provides an entry point, from which it is possible to get information about all geodata and services available for this canton. The ASIT-VD affiliates about 300 partners which are city-councils, cantons, the state, Antoine Elbel & Rémy Baud page 8 sur 45

9 engineering firms (geometers, architects, urban planners, and geologist), infrastructure providers (gas, electricity, and public transportation), specialized and federal institutes, software development firms, and private people. To accomplish this task of promotion, the association already provides a searchable catalogue through a web portal for browsing and ordering geodata of its partner community. Each member who wants to make public its data can fill in the catalogue online, and then interested people may browse and order datasets. 1.2 Product scope EasySDI Publish main goals: Facilitate datasets distribution upon standardized geoservices (WMS/WFS) for a large, inexperienced public. Share an infrastructure for datasets diffusion through geoservices. This shall bring the following benefits: Decrease the complexity of creating such geoservices by offering: o Simple creation and configuration, comparable to ordering a book from an online store. o Only most relevant data to be configured. By sharing a diffusion infrastructure, no need of additional IT knowledge, no server cost and maintenance by the end user will be required. Promote significantly datasets exchange and in consequence, value-added services upon these datasets (downloading, querying, analysing, combining them). EasySDI Publish innovates with the creation of geoservice based on datasets, allowing first to transform their format and reshape their model. Datasets format needs to be transformed. Datasets have to be stored in a consistent way in database to meet optimal diffusion performance, service maintainability, backups. Therefore EasySDI Publish must be able to transform various datasets into a specified DB format (like PostGIS). Datasets model needs to be reshaped. In a first approach, it might be sufficient to make only the transformation step. It would work with certainty for well-designed datasets that come from GIS applications. On the other hand, the application might have to deal with less structured datasets such as those coming from Computer-Aided Design (CAD), which provides no topological rules, no themed structure and no real data model. Because it is not possible to publish such data on a geoservice, it may be possible to reshape their structure before publishing them Product context The extended EasySDI stack diagram points out what the EasySDI Publish functionalities are: Antoine Elbel & Rémy Baud page 9 sur 45

10 Figure 6: Easy SDI Publish business functionalities The scope of EasySDI Publish is to provide to a publisher the ability to create WMS or WFS geoservice on his dataset and therefore, it DOES provide: Dataset upload, format and model transformation, data storage. WFS / WMS deployment on dataset. Service configuration (end-point name, layer name, style). Update or delete a created geoservice. Preview a created service. System configuration for the administrator. Because the following functionalities are already usable or in development phase in EasySDI, EasySDI Publish DOES NOT provide: User administration. Geoservice authentication and encryption. Geoservice discovery and cataloguing. Usage reporting, consumption statistic for billing purpose. Service monitoring. Antoine Elbel & Rémy Baud page 10 sur 45

11 1.2.2 Foreseen Application Architecture This paragraph lists the used technologies in EasySDI and where EasySDI Publish is positioned: Figure 7: EasySDI used technologies overview User interface: JOOMLA! 1.5 is used as content management system, it requires o PHP. o MySQL. Business tier: o Java and PHP. o Servlet container: Default is Tomcat, but other ones are supported. o Of course, any needed technology that supports OGC standards. Data tier: o No condition, because a MySQL database is required to run Joomla, EasySDI Publish may use this database for its own needs. The exact technology choice is not in the scope of the requirements, and the diagram above is non-committing Recommended Reading As mentioned previously, the specification assumes that the reader has some background knowledge on the domain of problems common to the world of Geographical Information System, and the common solutions to these problems. Useful URLs that the reader might be interested to look at are: INSPIRE directive INSPIRE implementing rules OGC s WMS OGC s WFS OGC s WPS Joomla Antoine Elbel & Rémy Baud page 11 sur 45

12 EasySDI Fme PostGIS geotools geoserver 1.3 Used definitions, acronyms, Glossary Definitions / Glossary Authentication Encryption Dataset Geodata Geoservice Shape (ESRI) DXF KML Identification process performed with user name and password. Use of SSL transport layer. Data which has a geographic content or not. Data which has a geographic content. A generic term to design an OGC's web service. Pseudo-standard format for GIS application data. Drawing exchange format. Pseudo-standard format for CAD application data. Keyhole Markup Language. Google s geodata format Acronyms ASIT-VD GUI WMS WFS OGC EPSG INSPIRE SDI OWS SOAP WPS REST ESRI Association pour le Système d Information du territoire Vaudois. Graphical User Interface. Web Mapping Service. Web Feature Service. Open Geospatial Consortium. European Petroleum Survey Group. Infrastructure for SPatial InfoRmation in Europe. Spatial Data Infrastructure. OGC Web Service. Web Service Messaging Framework (historically Simple Object Access Protocol). Web Processing Service. REpresentational State Transfer. GIS software development company 1.4 Referenced Documents [1] EasySDI Presentation [2] INSPIRE technical note Government/Files/inspire_technical_architecture [3] INSPIRE directive [4] OGC Web Mapping Service specifications [5] OGC Web Feature Service specifications Antoine Elbel & Rémy Baud page 12 sur 45

13 [6] OGC Web Processing Service specifications Competitive products, existing market Solutions, open source or proprietary, that exist to implement fully or partially a spatial data infrastructure are numerous. Most relevant are: Proprietary software: ESRI s ArcGIS publisher for geoservices. Conterra.de for an SDI suite. Open source software: Degree for a decentralised data infrastructure. Proprietary software may fit customers that have a big structure and financial resources. In some cases, experiments turned into really good realisations, for example in the canton of Geneva. On the other hand, standards have been sometimes loosely interpreted or only partially integrated. Proprietary solutions have sometime restrictions on data conversion possibilities and support. Hence the user is dependent on a manufacturer and may pay for something that finally doesn t really belong to him. The user can t extend the product the way he wants. In the case of Open-Source software, almost only the Degree project implements partially the INSPIRE stack. It is already possible to create geoservices from a web frontend with a simple tool, but until now only proprietary solutions are available. 1.6 Stakeholder definition Stakeholder profile Type Spokesperson Designation / Responsibilities Customer Xavier Mérour Defines the feature to bring in the software. ASIT-Vd s member Find some muppet Gives feedback about the application s usability. EasySDI s steering Bruno Magoni / Checks the project orientation to match optimal EasySDI project community Depth consultant integration. ASIT-Vd Xavier Mérour Checks the project orientation to match optimal association s goals. EasySDI Maintainer Bruno Magoni Represents Depth SA s interests User profile Type Administrator Designation / Responsibilities Manages and monitors the system. Does maintenance tasks. Antoine Elbel & Rémy Baud page 13 sur 45

14 Geoservice creator Geoservice operator Geoservice consumer Prepares datasets for exposure to the service and creates the geoservice. Publishes the geoservice and manages the service policies (right management layer). Consumes geoservice data with a web client or a heavy client (GIS application). 1.7 Licensing & legal notice As part of the EasySDI project and towards the possible future project incubation, EasySDI Publish must be licensed without further restriction - under the GNU GPL V.3 license. Terms and conditions are available under: Antoine Elbel & Rémy Baud page 14 sur 45

15 2. General Overview 2.1 Product functionalities Overview Publisher Existing features Features on wish list Administrator Figure 8: The EasySDI Framework and product functionalities overview Business use cases User profile and actor mappings User profile Administrator Geoservice creator Geoservice operator Geoservice consumer Actor in use cases Administrator. Publisher (distinction is made in requirement description). Publisher (distinction is made in requirement description). Consumer. Antoine Elbel & Rémy Baud page 15 sur 45

16 Publisher Figure 9: Publisher s use cases. Antoine Elbel & Rémy Baud page 16 sur 45

17 Administrator Figure 10: Administrator s use cases Consumer Figure 11: Consumer Use Case Because this project aims to publish geoservices, the consumer part is not part of the work and won t be handled. Antoine Elbel & Rémy Baud page 17 sur 45

18 CAD, GIS tools and existing map viewers will be able to access the dataset using the OGC standardized interface (the geoservice) that Easy SDI Publish has built after the creation process. This use case is drawn in order to display the complete life cycle of the geodata. Antoine Elbel & Rémy Baud page 18 sur 45

19 3. Requirement / functionality 3.1 Conventions Description Requirement descriptions follow a template. The structure of this template is: Requirement template [T]UC[a] Name Description Type V P Naming Notation Description [T]UC[a]FR[x] UC: Use case of partial system T. [a] counter for the use case. FR: Functional Requirement. [x]counter for the requirement. GUI-NF01 Non-functional requirement that are more general and not described in the use cases. They are classified regarding the system component: (SYStem, GUI, COMmunication, SOFTware interfaces) Type Notation Description Product GUI EasySDI All requirements for the product. All requirements for the GUI. All requirements for the framework (extension). Antoine Elbel & Rémy Baud page 19 sur 45

20 3.1.5 Version V Notation Description 1.0 Features of the first version, implemented in this work. 2.0 Features wished Priority P Notation Description 1 Implementation of the Must point (shall), basis functionality. 2 Wish point (should). 3 Proposition (can). 4 Intention (will). 3.2 Subsystems Notation Description Us Ad All requirements for the Publish User. All requirements for the Publish Administrator. Antoine Elbel & Rémy Baud page 20 sur 45

21 3.3 Use cases UsUC01 Create Service Description: The publisher wants to create a geoservice. Actor: The publisher. Pre-condition: The publisher is logged in. The publisher disposes of sufficient rights. Event-Flow: Post-condition: A geoservice is created Name Description Type V P UsUC01 FR1 The system shall handle the upload of one dataset, contained into one file for Product Antoine Elbel & Rémy Baud page 21 sur 45

22 the new service. The publisher shall provide the format name and projection code, in which its data are described. UsUC01 FR2 The system shall provide the ability to create the new geoservice with following configuration elements: Geoservice end-point name. Geoservice type (WFS OR WMS). Fields layer's attribute name and layer name (mapping between database field and human readable name presented in the service). Contact info + address for the responsible manager of the service. A username and password to access the service end-point. Product Map Default Colour. Layer colours and line, point, fill colour and patterns. Product UsUC01 FR3 UsUC01 FR4 UsUC01 FR5 UsUC01 FR6 UsUC01 FR7 The system shall provide the ability to upload vector-based dataset in various formats for the WFS or WMS data source. Mandatory formats are: ESRI shape. Autodesk DXF. Google's KML. The system can provide the ability to upload an image-based dataset in various formats for the WMS data source. The wished formats are: Erdas ECW. GeoTIF. MrSid. JPEG2000. The system shall be able to support the following projections for WMS/WFS rendering: EPSG (CH1903 / LandVermessung 03). EPSG 2056 (CH1903+ / LandVermessung 95). EPSG 4326 (WGS 84). EPSG 3785 (900913) (Google s Web Mercator, used in Google Maps). The system shall be able to return detailed messages in case of a configuration error, leading the publisher to correct them. The system can provide the ability to set basic security policies and authentication in the EasySDI proxy for the created service. This includes: Access restriction with user name and password. Geographic Boundary limitations. Geoservice operator and Data operator roles can be differentiated: o Geoservice operator: Opens the service and manages the right management. o Data operator: Prepares data and service. Product Product Product Product EasySDI Proxy Antoine Elbel & Rémy Baud page 22 sur 45

23 UsUC01 FR8 If there is no configuration available, the system creates a default configuration where the dataset field names are copied into the configuration field. Product Antoine Elbel & Rémy Baud page 23 sur 45

24 3.3.2 UsUC02 Update Geoservice Description: The publisher changes some properties of an already existing geoservice or the publisher updates service s dataset. Actor: The publisher. Pre-condition: Publisher is logged in. A service exists. Publisher owns sufficient right on this service. Event-Flow: Post-condition: The geoservice is updated. Name Description Type V P Antoine Elbel & Rémy Baud page 24 sur 45

25 UsUC02 FR1 The system shall provide the possibility to update the configurable elements of a geoservice as describe in UsUC01 FR2. Product UsUC02 FR2 UsUC02 FR3 The System shall provide the ability to update the data source of a geoservice and shall perform checks to determine if the new data source is compatible with the current geoservice configuration and accordingly display appropriate error messages accordingly. If the new data source is not compatible, the system shall provide the choice to keep the existing data source and configuration OR to keep the new data source and fill the configuration with default values. By editing a geoservice, the system shall provide the possibility to EITHER configure the geoservice OR upload a new data source. Product Product UsUC02 FR4 The system should be able to manage different roles, for creating the geoservice (data operator) and for publishing, and securing the geoservice (geoservice operator). Product Antoine Elbel & Rémy Baud page 25 sur 45

26 3.3.3 UsUC03 List Created geoservices Description: The publisher requests a list of the services currently published. Actor: The publisher. Pre-condition: Publisher is logged in. Event-Flow: The System displays a list of published geoservices. Post-condition: If one or more services are available, a list is displayed. Name Description Type V P UsUC03 FR1 UsUC03 FR2 The system shall provide the possibility to display a list of all geoservices managed by the publisher. The list shall contain at least: Service name. Service end point. Date of creation. Date of last dataset update. Date of last changes in the configuration. The system should provide the possibility to view a list of all published geoservices. Product Product From this view, the system shall provide the possibility to turn a service online and offline. Product UsUC03 FR3 Search and filter functionalities should be available for sorting purpose. Product UsUC04 Delete Geoservice Description: A publisher erases a service that had been previously created by him. Actor: The publisher. Pre-condition: At least one service must exist. The publisher is logged in. Event-Flow: (include UsUC03) System displays a list of geoservices. The publisher chooses the geoservice he wants to delete in the list. (extend UsUC11) Delete the dataset if no other service references this dataset. Post-condition: The geoservice is deleted. Name Description Type V P Antoine Elbel & Rémy Baud page 26 sur 45

27 UsUC04 FR1 The system should provide a mean to delete an already created geoservice. If no geoservice references the dataset the latter shall also be deleted. Product UsUC04 FR2 The system shall delete all the fields corresponding to this service and configuration elements. It shall emit a warning before deletion. Product UsUC05 Quick-View Description: The publisher visualizes the created service on a map within the browser window. Actor: The publisher. Pre-condition: At least a service is available. Event-Flow: (include UsUC03) System displays a list of geoservices. Publisher chooses the geoservice he wants to visualize. Post-condition: A map displays the geoservice. Name Description Type V P UsUC05 FR1 The system shall provide a map with the following navigation elements: Zoom In. Zoom Out. Pan (move the visible map extends). Zoom to full extent. Product UsUC05 FR2 A background image shall be displayed. A possible data source for this image could be googlemap or yahoo maps service. Product Antoine Elbel & Rémy Baud page 27 sur 45

28 3.3.6 UsUC06 Upload Dataset Description: The system transfers a dataset. Actor: The system. Pre-condition: UsUC01 (service being created) and UsUC02 (service being updated). Event-Flow: N/A. Post-condition: A dataset is uploaded, and stands ready for transformation (UsUC07). Name Description Type V P UsUC06 FR1 The system shall provide a mean to transfer a file from the local machine to the server where EasySDI Publish resides. Product UsUC06 FR2 UsUC06 FR3 The system can provide a mean to synchronise a dataset automatically with a configurable time interval. The system shall check the restrictions defined by the administrator, in accordance with use case AdUC01. Product Product Antoine Elbel & Rémy Baud page 28 sur 45

29 3.3.7 UsUC07 Transform Dataset, UsUC08 Store Dataset Description: A dataset is transformed and stored in a database. Actor: The system. Pre-condition: A dataset is uploaded successfully. Event-Flow: The system detects that a new dataset is ready. The system transforms the dataset. The system stores the dataset in a database. Post-condition: The dataset is successfully stored in the database. Name Description Type V P UsUC07(8) FR1 UsUC07(8) FR2 The system shall provide a mean to perform format-based conversion of the dataset in the database: Shape -> PostGIS. The system should provide a mean to perform model-based conversion of the dataset, before storing it in the database: Dxf -> PostGIS. Product Product Antoine Elbel & Rémy Baud page 29 sur 45

30 3.3.8 UsUC09 Handle geoservice Description: The system checks and stores the configuration of the geoservice. Actor: The system. Pre-condition: A new geoservice is being created, or an existing geoservice is being updated. Event-Flow: Post-condition: The geoservice configuration is stored. Name Description Type V P Antoine Elbel & Rémy Baud page 30 sur 45

31 UsUC09 FR1 The system shall store the configuration elements described in UsUC01 FR5. Product UsUC09 FR2 The system shall check the coherence between the dataset and the geoservice configuration. If incoherence is detected an error shall be thrown, and no modification shall be stored. Product UsUC10 Publish geoservice Description: The system finalizes the geoservice publication. Actor: The system. Pre-condition: A modified dataset and/or configuration are available. Event-Flow: Data are transferred on the publication server. Post-condition: Geoservice is online. Name Description Type V P UsUC10 FR1 The system shall copy the data to the underlying publication server Product UsUC10 FR2 The system configures the geoservice on the underlying publication server. Product AdUC01 Configure OWS Description: The administrator performs system management tasks. Actor: The administrator. Antoine Elbel & Rémy Baud page 31 sur 45

32 Pre-condition: Administrator is logged in. Event-Flow: Configuration available over a browser page. Post-condition: The system is configured. Name Description Type V P AdUC01 FR1 Following elements shall be made configurable: Upload file size limitation. Upload file type limitation. Max services per publisher. Product And following elements in conformance with UsUC02 FR4: Role defined through allowed actions. User's role. Product AdUC01 FR2 The system shall provide to the administrator the ability to display a list of all available geoservices. Product AdUC01 FR3 Search and filter functionalities should be available for sorting purpose. Product AdUC01 FR4 The system can report on uptime, usage statistics can alert, restart server, (This would belong to a monitoring component) EasySDI Antoine Elbel & Rémy Baud page 32 sur 45

33 3.4 Other non-functional requirements Name Description Type V P SYS-NF01 Joomla Concepts of module/plug-in/component shall be used. Product SYS-NF02 SYS-NF03 The configuration s serialization and storage shall be done in the Joomla! Database. The system shall use the EasySDI framework for the user authentication. Therefore the installation of the EasySDI core component is a prerequisite. Product Product SYS-NF04 EasySDI Publish shall support the following web browsers: Firefox 3.0. Internet Explorer 7.0. Product Product GUI-NF01 SOFT-NF02 Defined localization strings shall be used. Localization strings are stored in a separate file. The system shall be designed independently from a particular WMS/WFS publication server. Product Product SOFT-NF03 Geoserver shall be supported as a publication server. The system should be able to support many dataset transformation tools (for example FME or geotools). Product COM-NF01 The system shall use only one publication server that is physically on the same machine as EasySDI publish. Product The system can use one or many WMS-WFS publication servers. Product COM-NF02 The geoservice creation process shall be implemented as an OGC s WPS (Web Processing Service). Product Access to this service shall be done over SSL and shall be protected with a login. Product Access to this service shall be done through the EasySDI-Proxy, which provides encryption and authentication. EasySDI- Proxy COM-NF03 In addition to the authentication for accessing a service end-point (the created geoservice), as described in UsUC01 FR2, the transport layer for accessing the service end-point should be encrypted with SSL. Product Specific location requirement In addition to the EasySDI requirement, it shall be taken into account that: Servers are Linux based. Antoine Elbel & Rémy Baud page 33 sur 45

34 The ASIT-VD has no intention to compete with a service provider, which may be a partner. The former aims to provide a service that no one else offers. For instance, there are firms who already provide geoservices diffusion hosting, but do not provide a simple way for the creation process and configuration. These two different tasks shall be separated and it should be possible to run them on different servers, where the association provides a way to create the service. A third firm may provide the service storage and diffusion. Antoine Elbel & Rémy Baud page 34 sur 45

35 4. Documentation 4.1 User s guide The goal of the application is to be intuitive in the way it is presented to the user, by using GUI ergonomics best practices. Hence, a user guide is not planned. 4.2 Online Help docuc1.1fr1 Help on the full process of the geoservice creation, embedded into a GUI. Product Administrator s guide docuc1.1fr2 The following documents are foreseen: An EasySDI Publish installation guide. A components configuration guide. An administrative tasks guide. Product Antoine Elbel & Rémy Baud page 35 sur 45

36 5. Test concept 5.1 Goal of testing The test plan goal is to consistently check the different views of the finished product: The acceptance tests will verify the user requirements. The system tests will verify the system requirements. The integration tests will confront the system design. And the unit tests will check the implementation as much as possible. 5.2 Overview of planned tests At this stage of the project only the acceptance and system tests can be formalised because they directly depend on the content of the present document. To the contrary, the other tests depend on the design and the implementation Smoke testing As part of the development process, Smoke Tests will have to be run successfully by each developer before checking changes in the subversion source control server Acceptance test Acceptance tests aim to minimize the risk that the user ends up with a product different to the one he opted for. To avoid this scenario, following elements may be tested with the involvement of both a representative user and ASIT-VD contractor. Test Object: GUI Interface Administrator Tasks Interface Test Description: Present a prototype to a user and to the expert. Present a prototype to the ASIT-VD contractor System test Test Object: UsUC01 Create Service UsUC02 Update Geoservice UsUC03 List Created geoservices UsUC04 Delete Geoservice UsUC05 Quick-View UsUC06 Upload Dataset UsUC07 Transform Dataset UsUC08 Store Dataset UsUC09 Handle geoservice Test Description Dedicated test scenario. Dedicated test scenario. Dedicated test scenario. Dedicated test scenario. Dedicated test scenario. Dedicated test scenario. Unit Test. Unit Test. Dedicated test scenario. Antoine Elbel & Rémy Baud page 36 sur 45

37 UsUC10 Publish geoservice AdUC01 Configure OWS A useful mean for testing the WFS service at system level is provided by the online client at: Dedicated test scenario Integration Tests These tests directly depend on the chosen design. Therefore integration tests planning will be made at a later stage of the project. It is however reasonable to think that reviews and unit tests are the two methods that will be used to cover them. Antoine Elbel & Rémy Baud page 37 sur 45

38 6. Project activity 6.1 Project plan The next picture describes with coarse granularity the time that will be spent on the main milestones. Project reviews, documentation and testing are taken into account and are merged into the different tasks. Milestones are defined, each with a set of deliverables: Requirement phase: deliverable: Requirement and specification document De-risking phase: deliverable: A chapter of the master thesis final report dealing with the prototypes that were elaborated and the role they played in the overall proof of concept. Design phase: deliverable: A chapter of the master thesis final report dealing within the concept and reasoning behind the design decision. Implementations: deliverable: The EasySDI Publish itself Testing phase: deliverable: Successfully Executed test cases Documentation: deliverable: Final Report Presentation Figure 12: Project planning overview 6.2 Effort estimation The effort estimation is based on a PERT analysis that takes the previous milestones and describes them more in depth. To convert the duration from day to hour the following formula is used: 1 working day = 2 persons that work 8h = 16 hours Non-functional requirements do not appear in the PERT analysis, because they are implicitly included in the implementation of the functional requirements. Antoine Elbel & Rémy Baud page 38 sur 45

39 Figure 13: Effort Estimation Antoine Elbel & Rémy Baud page 39 sur 45

40 6.3 Resource Plan Since the project is run within the frame of a Master Thesis, the workload should be planned around fixed resources of approximately 720 hours. This time quantum is distributed according to the following figure: Figure 14: Resource Plan per person, day count Antoine Elbel & Rémy Baud page 40 sur 45

41 Figure 15: Ressource Plan, Calendar View Antoine Elbel & Rémy Baud page 41 sur 45

42 7. Risk Management A successful project involves the realisation of a task within a given time and costs limit. Therefore it is important to define a contingency plan to make sure that the work described in this document is feasible within the limited time and costs. Major risks have been identified and are presented in the tables below, along with a solution. Probability High Impact High Description: Learning Curve of the geoservice diffusion technology is too steep. Objectives: Avoid losing time because of choosing an inadequate technology. Approach: Make sure the technical needs for this project are understood. Plan enough time for a proof of concept prototype where the critical parts of the server API are used. Responsibilities: Organize the knowledge acquisition by splitting areas of expertise between the team members and presentations to spread it. Contingency Plan and Trigger: Trigger: More than 16 hours to get a service running. Plan: Use hours from the end buffer to get it running at all costs. Probability Medium Impact High Description: Learning Curve of the CMS Joomla and its programming environment is too steep. Objectives: Avoid losing time. Approach: Plan teaching hours from one project team member who masters this technology to the other. Responsibilities: Rémi to teach Antoine basic programming concepts in JOOMLA. Contingency Plan and Trigger: Trigger: Sleepless Night Plan: Use hours from the end buffer to get it running at all costs. Probability Medium Description: Project implementation eating over documentation time. Objectives: Avoid hurrying over the final report. Approach: Impact High Antoine Elbel & Rémy Baud page 42 sur 45

43 Start early with the final report, by agreeing on a structure as soon as possible. Responsibilities: Antoine to propose a final report structure. Contingency Plan and Trigger: Trigger: Half of the planned hour spent without a line in the documentation and the final report. Plan: work overtime Probability Low Impact High Description: Daytime job putting the project resources under pressure. Objectives: Avoid having to face tight deadline both in the master thesis and in the professional employment sphere. Approach: Agree with employer on free time, early on in the project. Responsibilities: Antoine to propose a clear calendar and schedule to the end of the project. Contingency Plan and Trigger: Trigger: Unplanned emergency in the daytime job. Plan: 3 days of buffer planned at the end of the project. Status: Agreement with School-Expert and Employer on a time plan. (cf sheet diplom_arbeit.xls) Date: 20/03/09 Probability Medium Impact High Description: Wrong technical decision in the choice of the geographical data format transformation. Objectives: Avoid losing time because of choosing a not adequate technology. Approach: Agree with the customer to support only a limited number of transformation types, but structuring the design to allow easy future extensions. Early prototype to understand better the data transformation problem domain. Responsibilities: Rémi to investigate for the available tools in the proprietary and open-source world. Contingency Plan and Trigger: Trigger: Technology workflow not understood at the beginning of the implementation phase. Plan: work overtime Probability Medium Description: Learning Curve of the PostGIS database is too steep. Impact High Antoine Elbel & Rémy Baud page 43 sur 45

44 Objectives: Avoid losing time because of the technology intricacies. Approach: Early prototype to understand better the geographical database concepts. Responsibilities: One team member to devise an exercise and explain the solution to the other. Contingency Plan and Trigger: Trigger: Not understanding it quickly enough. Plan: Work Overtime. Antoine Elbel & Rémy Baud page 44 sur 45

45 8. Annex 8.1 Table of figures Figure 1: Communication problems in product development Figure 2: Inspire architecture... 5 Figure 3: A WMS sample from NASA server... 6 Figure 4: EasySDI s concept... 7 Figure 5: EasySDI stack and EasySDI Publish place Figure 6: Easy SDI Publish business functionalities Figure 7: EasySDI used technologies overview Figure 8: EasySDI Framework and product functionalities overview Figure 9: Provider s use cases Figure 10: Administrator s use cases Figure 11: Consumer Use Case Figure 12: Project planning overview Figure 13: Effort Estimation Figure 14: Resource Plan per person, day count Figure 15: Ressource Plan, Calendar View Antoine Elbel & Rémy Baud page 45 sur 45