W2 : Analysis W3: Design

1. W2: AnalysisW3: Design 24.05.2018 Funded by the Erasmus+ Program of the European Union. However, European Commission and Turkish National Agency cannot be held responsible for any use which may be made of the information contained therein.

2. Agenda 1: • Introduction 2: • Software Requirements Specification 3: • Software Requirements Review 4: • Software Development Plan 5: • User Documentation Description 6: • W3: Design

3. Introduction • Overview of Work Package 2 • Overview of Requirements

4. Overview of W2 eVET is an online VET platform on which VET providers (VET schools, workplaces, governmental organizations, VET centers, non-profit organizations, etc.) can connect and collaboratively develop KA1 VET projects. The VET providers will specify their criteria to find the most suitable VET providers to arrange vocational education and training opportunities for the studentsand the staff. This platform is prepared for the VET providers in any Erasmus+ Programme countries.

5. Overview of Requirements In order to determine, product scope, and product functions, first a detailed Internet research was performed. Two sites (eTwining and ErasmusIntern) were investigated. eTwinning is a platform that promotes collaboration of schools. ErasmusIntern is a platform where interns and internships meet. eVET differs from them since this platform aims to create collaboration all types of VET providers (schools, companies, governmental organizations and non-profit organizations).

6. Overview of Requirements • Secondly interviews were conducted with different VET providers (schools and companies that have or have not prepared an Erasmus+ project) in Turkey, Germany and Italy. • These interviews have highlights for Erasmus+ projects as: • Useful to let people get a mobility work placement in Europe • Enhance a foreign language • Boost sector-skills • Intercultural experience and awareness

7. Overview of Requirements • What is important? • Reliable partnership and mutual trust • Logistics and accommodation (guidance for students <18) • Willingness of companies • Experienced internship supervisor at companies • Memorandum of Understanding with all the partners

8. Overview of Requirements • What is required for search options? • Field of study, area, sector, branch, company type • Training workplace type (office, field, plant, etc.) • Mobility project experience, previous activities and references/ratings/feedbacks • Company and student profile descriptions • Country, city, municipality • Age group, gender, language • Duration of mobility, time period, • Number of students/instructors, • Payment amount, allowances

9. Overview of Requirements • Type of documents/tips to be included: • Project templates, agreement examples, certificate examples (e.g. Europass mobility), worst practices/best practices • Useful tips, links for support institutions • Potential problems: • Different school systems • Partners not sharing contacts • The quality of the final certification of the competences acquired

10. Software Requirements Specification • Context Diagram / Environment • Use Case Diagram / Functions

11. Context Diagram / Environment

12. Use Case Diagram / Functions

13. Software Requirements Review • Review Form

14. Review Form

15. Review Form

16. Software Development Plan

17. SDP Overview • The software development process chosen for the project is the waterfall. Waterfall methodology follows a sequential, linear process and is the most popular version of the systems development life cycle (SDLC) for software engineering and IT projects • A fully virtualized private server with following specifications will be used: • 2 GB RAM • 40 GB SSD Storage • 2.00 Ghz x 2 Cores CPU • 100 Mbps internet connection • Centos 7 OS • PHP 7 • MariaDB 5.5 • Apache 2.4

18. SDP Overview • Toolsto be used for software design: • Microsoft Visio • MySQL Workbench • phpMyAdmin • Tools to be used for coding and automated tests: • PHPStorm for coding • Travis CI for automated tests • Tools to be used for configuration management and bugs management: • Github will be used for version control and issue tracking • Obsolescence of software development tools will be: • updated when a new version comes up

19. SDP Overview • Coding Standards • PSR-1 and PSR-2 coding standards and the PSR-4 autoloading standard will be followed. • PHPDoc • Below is an example of a valid documentation block. Note that the @param attribute is followed by two spaces, the argument type, two more spaces, and finally the variable name: • /** * Register a binding with the container. * @param string|array $abstract * @param \Closure|string|null $concrete * @param bool $shared * @return void */public function bind($abstract, $concrete = null, $shared = false){ // }

20. User Documentation Description

21. UDD Overview • This User Guide is addressed for: • End users: Experience for end users is not required, usage of web browsers should be sufficient. • Administrators: System administration, security and performance sections are related to system administrators. • This User Guide will be prepared in multiple languages. • General Operations • This part will include general operations as: register as a new user, login the system, change a password, obtain help and report a fault. • Administrative Operations • This part will include administrative operations as: user administration and support, security administration, protection against viruses and other malevolent agents, system installation, data back‑up and recovery, control of system operation.

22. User Information • Training Request Information • File Types • Contracts • Software Design Description (SDD) • Software Design Review (SDR) • Responsibilities W3: Design

23. User Information

24. Training Request Info.

25. File Types • Downloadable file types are: • PDF • MS Word • Downloadable files: • Project Example • Agreement Example • Certificate Example • Help Files: • Useful tips • User guide

26. Agreements Registered VET providers would be able to create agreements after they find possible partners. Agreements will be entered by only one partner. Partners will receive a call when they are specified as a partner to an agreement. An agreement can be edited by entering partner. Agreements will be finalized when entering partner specifies as done. Entering partner may delete the agreement. Automatic emails will be sent to get information about project proposals and project proposal acceptances/rejects.

27. SDD • This Template is the property of Cyrille Michaud. Templates are free to download and fill to produce technical documentation. The documents produced by filling the templates are outside the scope of the license found at http://blog.cm-dm.com/post/2011/11/04/License Table of Contents 1. Introduction 2. System Overview 3. System Architecture 4. Data Design 5. Component Design (DLL) 6. Human Interface Design (Screens) 7. Traceability Requirements Matrix 8. Resource Estimates 9. Definitions, Acronyms, and Abbreviations

28. SDR • Karl E. Wiegers, 2001. Permission is granted to use, modify, and distribute. • Retrieved from: • http://www.cs.toronto.edu/~sme/CSC340F/2005/assignments/inspections/reqts_checklist.pdf • Checklist for Architecture Reviews • Checklist for High-Level Design Reviews • Checklist for Detailed Design Reviews • Checklist for Code Reviews

29. Responsibilities

30. THANK YOU!