COMPANY CONSULTING Terms of Reference Development of an Open Innovation Portal for UTFSM FSM1402 Science-Based Innovation FSM1402AT8 I.

Transcription

1 COMPANY CONSULTING Terms of Reference Development of an Open Innovation Portal for UTFSM FSM1402 Science-Based Innovation FSM1402AT8 I. BACKGROUND 1.1 General overview of the project in which the Consulting Service is framed. The program Institutional Improvement Plan on Innovation in Higher Education, (PMI-InES), identifies the areas of Electronics, Physics, Information Technology, Biotechnology and Environment, and the combination and synergy that relate these disciplines to priority areas in mining, energy and the environment, as an opportunity in which Universidad Técnica Federico Santa María (UTFSM) can achieve outstanding results at the Latin American and global levels in terms of Science-based Innovation. This can be seen by the fact that between , 52 applications for patents were submitted, 71% of which were concentrated in the abovementioned areas, and a total of 46 patents granted, 85% of which in said areas. Based on these lines of development, UTFSM has created centers of excellence and centers for technological innovation, such as the Dr. Daniel Alkalay Lowitt Biotechnology Center (CB-DAL), the Environmental Technology Center (CETAM, in Spanish), the Advanced Center for Electrical and Electronic Engineering (AC3E), the Automation and Supervision Center for the Mining Industry (CASIM) and the Valparaiso Technological Science Center (CCTVAL), which currently constitute the key technology nuclei that will form the basis for strengthening science-based innovation in order to improve the country s competitiveness at the international level. This proposed objective requires the implementation of a strategic and highly focused approach on enhancing the available technology transfer mechanisms, based on the creation of spin-offs, joint ventures, patents and technological licenses, on the one hand, and specialized technological services and human resource training on the other. All of these mechanisms are currently organized within the Department of Research, Innovation and Graduate Studies (DGIIP) and the Department of Technical Assistance (DGAT), with results in the medium and long-term in the case of the former ( > 1 year), and in the short-term in the case of the latter (< 1 year). However, these efforts are not enough to respond to the development requirements of the production sector in order to participate in the transfer and licensing of technology suites. This gap is evidenced by the significant number of high-impact scientific publications and a low number of patents or products with a substantial impact on the industry. 1.2 Identification of the problem or situation to be addressed The program Institutional Improvement Plan on Innovation in Higher Education, (PMI-InES), identifies universities problems in terms of innovation, specifically science-based innovation. It this type of innovation in which Universidad Técnica Federico Santa María (UTFSM) can achieve outstanding results at the Latin American and global levels. To obtain these results, UTFSM needs to improve and expand its ties to the industries, to enhance the processes existing at the time of project application and management, and to transfer the technologies developed by USM. For this reason, UTFSM needs to increase and improve communication with the industry to be able to understand their problems and provide a solution according to the institution s capabilities. In order to achieve the necessary expansion and improvement, it is important to resolve the following challenges: To exhibit UTFSM s capabilities, technologies, recognitions, etc. To create a space where industry can discuss its technological challenges. To provide collaborative work tools to improve and increase the quantity of project profiles.

2 To improve the communication channels between the university and the industry. Finally, it is important that the Open Innovation Portal be user-friendly and intuitive, so that industry users have no problem using it and can easily obtain the information they are looking for. II. GENERAL OBJECTIVE The general objective of the Open Innovation Portal is to provide a platform to facilitate the interaction and collaboration between the University and Industry, in order to create, expand and improve innovation. III. SPECIFIC OBJECTIVES To provide a virtual collaboration environment to facilitate the innovation process To provide functional features for managing the innovation process. To facilitate the presentation of the challenges faced by the platform s participants. To offer the participating entities skills, technologies, products and services. To facilitate the integration of innovation ecosystem applications through the use of an API-first design model. V. DESCRIPTION OF THE OPEN INNOVATION Domain model To comprehend the associations provided in the domain model, figure 1, these must be read according to the system presented by Craig Larman (Applying UML and Patterns, 1998): o From top to bottom. For example, Challenge is presented by the Participating Entity. o From left to right. For example, Participating Entity creates Request for Collaboration. o From left to right takes priority over top to bottom. For example, Participating Entity seeks Source of Financing. o The associations can, therefore, also be understood inversely. For example, Subsidiary Entity offers Source of Financing. Figure 1: Domain diagram 2

3 Use Case Diagram Figure 2: Functional diagram The functional diagram in figure 2 shows the relationships among the actors involved in the Open Innovation Platform. The following describes the actors and use cases included in the diagram. The reader should note that the functions assigned to each actor correspond to those in which the actor plays a primary role in the case execution (that is, the actor has direct interaction with the System and is the main beneficiary). 3

4 o Participating entity: Any organization that registers a profile within the system. The profile shall represent the organization. Functions: Show an offer. Present a challenge. Begin collaboration. Obtain financing information. Obtain entity recommendations. Manage the innovation process. Define business case. Scan for protection. Manage development. Manage development validation. Manage development launch. o External entity: Person or organization that shows interest in the scientific-technological offer of any Participating Entity, but which is not formally incorporated in the platform. Functions: Review capabilities. Review products. Review services. Review technologies. Use case Apply for profile registration Actors External user, Participating entity Description An external user applies for profile registration as a Participating Entity on the Platform. The Systems solicits profile details and the External User enters them. The System validates and grants a Participating entity credential to the User who applied for registration. Use case Review offer Actors External User, Participating entity Description An External User or Participating Entity search on the System for a list of some of the elements offered (products, services, technologies, capabilities). The System asks the External User or Participating Entity for the search attributes. The External User or Participating Entity enters the values for the parameters requested, the System performs the search and responds with a list of elements offered that meet the search attributes or criteria. 4

5 Use case Prerequisites Actors Description Exhibit offer Participating Entity profile - created and active Participating Entity A Participating Entity asks the system to record and exhibit its offer (products, services, technologies, capabilities). The System requests details to describe the capabilities, records these details and presents them to other Participating Entities. Use case Present challenge Actors Participating Entity Description A Participating Entity asks the system to record and present a challenge to the other Entities. The System requests details to describe the challenge, record it and present it to the other Participating Entities. Use case Manage the innovation process Actors Participating Entity Description A Participating Entity asks the system to perform an operation related to the management of the innovation process (roles, activities, work products). The System presents management options. The Participating Entity selects a management option, enters the information required for the option, and the System executes the corresponding actions. Use case Prerequisites Actors Description Define business case Request for collaboration created Participating Entity A Participating Entity asks the system to write one or more elements of a business case. The System opens a case request in association with a request for collaboration and asks the Entity to enter the case elements. The Entity enters the data and the System records the case and communicates it to the related Entities. Use case Scan for protection Actors Participating entity Description A Participating Entity asks the system to perform a scan for protection of any particular technology or product. The System executes the search by consulting external and internal systems and presents the search results. 5

6 Use case Manage development Actors Participating Entity Description A Participating Entity asks the system to perform any operation related to development management. The System presents the management options. The Participating Entity selects a management option, enters the information required for the option and the system executes the corresponding actions. Use case Manage validation of development Actors Participating Entity Description A Participating Entity asks the system to observe or record the development validation status. The System solicits data related to the development validation. The Participating Entity enters the data solicited and the System presents or records the information. Use case Manage development launch Actors Participating entity Description A Participating Entity asks the system to observe or record the development launch status. The System solicits data related to the development launch. The Participating Entity enters the data solicited and the System presents or records the information. Use case Prerequisites Actors Description Obtain financing information Challenge presented Participating entity A Participating Entity asks the system for information on possible forms of financing for a particular Challenge. The System searches for subsidy options and presents a list with a description of each option. Use case Obtain recommendation of Participating Entities Actors Participating entity Description A Participating Entity asks the system for a list of Entities that could help face any need (challenge) of the Participating Entity who initiates the case. The System searches for Entities and presents a list of these. Use case Prerequisites Actors Description Initiate a request for collaboration Declaration of interest in participating in an innovation process Participating entity A Participating Entity asks the system to the initiate a request for collaboration. The System creates the collaboration space (to be defined in technical terms) and notifies the innovation process Participating Entities of its creation. The Participating Entities begin collaboration. 6

7 Expected Architecture The Open Innovation Platform is framed within an overarching effort aimed at technological standardization and integration within Universidad Técnica Federico Santa María. In this context, its architecture is expected to be oriented towards representational state transfer (REST). This expected architecture is described, in general terms, by the deployment diagram in figure 3. Applicants must note that the system to be developed (i.e., Open Innovation Platform) appears in the diagram within the UTFSM OI2 Node. Nevertheless, it also presents the interaction (see details below) with another system that will provide information on: o Patents o Technologies developed o Financing The University is responsible for developing the external system (SGPIITT). Figure 3: Deployment diagram for the expected architecture The deployment diagram allows applicants to observe the following architectural aspects: Priority given to an API-First-type design model, where the communication between Back-End and Front-End is performed mostly through interfaces (API), in order to avoid the replication of access points. UTFSM SGPIITT represents a Management System for Research, Innovation and Technology Transfer Projects which does NOT need to be developed as part of this service, but does need to be considered given that the information on the University s Patents and Technologies and Financing Options must be obtained from the Back-End associated with this external system. 7

8 The architecture is expected to be resource-oriented (REST), with a JSON exchange format. Other data exchange formats are optional. VI. Each component in the Back-End reflects a set of functionalities grouped by topic and described with use cases and a diagram for these (see Use Cases). Acceptance Criteria The bidder must specify in detail if its technological solution depends on third party libraries or software, which must be installed in order to execute the proposed software. Also indicate the license needed and its acquisition cost (if not considered within the bid). Otherwise, the bidder must explicitly state that there is no external dependence. The minimal and optimal hardware requirements must be defined as a product of the project development. Upon agreement by the parties, a set of acceptance tests shall be defined in accordance with the requirements established in the present document, before issuing any deliverable. An operational trial run shall be performed for the period of time to be specified according to the characteristics of the solution presented by the bidder. It shall be extended subject to the correct operation of the software implemented, during which time prompt technical support shall be required according to the critical nature of the problem detected. The bidder is responsible for assuming and explicitly specifying the costs, tasks, resources and activities related to the configuration and subsequent implementation of the software; as well as training sessions on how to use the software. The trial run must be carried out at least 6 weeks prior to the project end date, and the technical service corresponding to this period shall respond to all events as per the following chart: Severity of the Type Response time incident Minor Defect reported at the user level (possibly the user interface 1 business day level) as a result of an error made by the development team, but which does not prevent the application or any part thereof from being used, nor does it affect its performance. Medium Severe Defect which limits the use of the application to a minor degree. Defect which prevents the majority or the entire platform from being used. 12 hours The bidder is required to issue a warranty commitment for the correct operation of the software for the period of 1 year, from the date of final implementation (after the trial run phase). The warranty and technical support must apply in all cases. The technical service attention and response time must be 24/7 or one business day, depending on the severity of the incident reported (see chart below). 24/7 Severity of the incident Minor Type Defect reported at the user level (possibly the user interface level) as a result of an error made by the development team, but which does not prevent the application or any part thereof from being used, nor does it affect its performance. Response time 1 business day 8

9 Medium Severe Defect which limits the use of the application to a minor degree. Defect which prevents the majority or the entire platform from being used. 12 hours Upon compliance with all requirements listed in this section, the software shall be considered to be accepted. The bidder also agrees to provide a proper mechanism for the incident reporting (for example, an Issue Tracker). 24/7 VII. SCOPE OF THE REQUIRED SERVICES Critical Activities/Tasks According to the objectives established, the bidder must perform the following activities: Activity Identification: Identification of processes and requirements Specification: Design and specification of solution architecture and systems engineering Implementation: Development and configuration Consolidation: Trial run, training, and documentation Support: warranty period, support period Modality On-site Remote Remote On-site / Remote On-site / Remote These activities must be executed within a maximum period of eleven (11) months. The parties shall agree on periodic meetings for coordination, follow-up and control. Meetings shall be held at least every 15 business days. Some project activities may be developed online and remotely, coordinating via the Internet as needed. VIII. METHODOLOGY The bidder may propose the work methodologies it deems most suitable to perform the work in the best way possible. These shall be reviewed and validated by evaluators designated for this process. All on-site activities shall be held at the UTFSM main campus, and depending on the tasks to be performed, these may also be carried out at any UTFSM campus or site. IX. OTHER INSTITUTIONAL SERVICES The UTFSM shall provide all necessary information in a timely manner to correctly execute the Development of the Management System for Research, Innovation and Technology Transfer Projects. X. CONSULTANTS CONTRIBUTION TO EXPANDING OR IMPROVING THE T.R. The consultant may agree with the institutional counterpart team to expand or improve the terms of reference indicated for this advisory service, but not to reduce them. This shall apply only to the company who is awarded the contract. XI. EXPECTED RESULTS/PRODUCTS/REPORTS Each phase ends on a given date or Deadline. This date shall be established at the moment the project begins, considering the estimated times presented in the phase summary table. Each Deadline is 9

10 associated with one or more deliverables which, as a whole, are known as the Report and which shall be required by the University to evaluate compliance with the objectives of each phase (see Table 1). The deliverables, especially those associated with phases 1 and 2, shall not be considered final and, therefore, may be updated as new information surfaces during the course of the project, particularly during the Implementation phase. For each Deadline of each phase, the Report to be submitted must include the following deliverables: Deadline 1: Backlog with all requirements (functional and non-functional) and elements needed for system implementation (including prioritization based on the identification phases). Elements reflecting the functional and non-functional requirements collected (e.g., use cases, sequence diagrams, etc.). Matrix of stakeholders and strategies for communicating with them. Deadline 2: Diagram for the architecture model, reflecting the main design decisions for the platform to support the functional and non-functional requirements. Justification of the main design decisions. Initial planning of the Implementation phase (including development methodology, work estimates, quality and testing plan, and production deployment plan). Specification of the deployment components and mechanism to be used (for example, Cloud). Deadline 3: Functional software versions (the specific frequency of these submissions shall be decided by the bidder, but may not be less than every 2 or greater than every 4 weeks). Report of requirements implemented versus requirements planned for implementation in the partial delivery. Justification of requirements not implemented in the partial delivery. Documentation of APIs and system modules. Review and update (if applicable) of previous elements and reports (particularly the platform architecture). Note: Deadline 3 is composed of a series of partial deliveries. Deadline 4: Report of activities performed for the trial run process (including training). Evaluation of training activities by users. Documentation and/or system tutorials. Documentation of system production deployment (including a description of the proposal for deployment and granting of the University s proprietary access to the deployed solution). Deadline 5: Report of defects found. Report of defects corrected by the bidder. 10

11 Justification of defects not corrected by the bidder. The bidder may propose revisions to the reports as long as these meet the following conditions: The Reports must be submitted by phase end date. That is, on the associated Deadline as agreed upon by the parties. Compliance with all guidelines of the Ministry of Education and UTFSM Guarantee that the contents of the defined reports are fully aligned with the fulfillment of the objectives established for the project. The project considers a referential calendar divided into five (5) phases. The following indicates the estimated time need to complete each phase, and the payment percentage associated with each. Each payment shall be made upon acceptance of the Report. That is, upon receipt of the Report, it will be reviewed by the contracting party, which shall then notify the contractor of its acceptance or if corrections need to be made. Phases and Objectives Estimated Time Phase 1 - Identification of requirements 4 weeks - Identification of functional and non-functional requirements. - Executive meeting to review project status and submit Report by deadline 1. Phase 2 Specification of the Architecture and Initial Planning - Specification of the platform Architecture. - Initial planning for phase 3. - Executive meeting to review project status and submit Report by deadline 2. Phase 3 Implementation - Development and/o configuration. - Review of functional versions. - Review and update (if applicable) of previous deliverables. - Executive meeting to review project status and submit Report by deadline 3. Phase 4 Consolidation - Platform trial run period. - User training. - PMI InES Team Training for future system maintenance and administration. - Executive meeting to review project status and submit Report by deadline 4. Phase 5 - Warranty and Support - Software warranty period (1 year) 4 weeks 30 weeks 6 weeks 12 months 11

12 - Support period (1 year) - Executive meeting to review project status and submit Report by deadline 5. Table 1: Phases, objectives, estimated time and payments. XII. XIII. XIV. XV. FORMAT/PRESENTATION/QUANTITIES All reports must be submitted in the format to be given to them at the beginning of the project. All presentations given must be submitted in.ppt format (Power Point) and PDF. All deliverables must be sent to the technical counterpart indicated in point XV. In the case of phase 3, the proposal must consider functional demonstrations of partial versions of the software system. The frequency of these demonstrations may be determined by the bidder, but must not be less than every 2 or greater than every 4 weeks. ESTIMATED DATES FOR DELIVERY OF THE SERVICES The services must be delivered according to the estimate provided by the companies, which shall be evaluated as described in the administrative terms and conditions. Considering a total project duration of 9 months, the estimated dates are as follows: Coordination Meetings: held periodically as established by the Parties. Reports Date Payment Report No. 1 September 24, %, 30 days after acceptance of the report. Report No. 2 October 16, %, 30 days after acceptance of the report. Report No. 3 May 10, %, 30 days after acceptance of the report. Report No. 4 June 30, %, 30 days after acceptance of the report. Report No. 5 June 18, 2020 Already included in previous payment statements CONTRACTING PARTY S CONTRIBUTION TO THE CONSULTANT S WORK UTFSM shall contribute to the consultant s work as follows: Attend coordination, follow-up and control meetings Provide all information needed for the project, in a correct and timely manner. Manage meetings with different internal areas to identify the processes and requirements. Provide a physical space with Internet access. Review and give timely feedback on the Reports and other information needing its approval. CONSULTANT PROFILE 12

13 The bidder must include the company s résumé and that of all professionals who will participate in the project development. The consultant will have the following demonstrable experience: o Bidder with 5 or more years of experience in software development. o Bidder with experience in systems architecture and integration. o Bidder with experience in the development and administration of open innovation portals. o Bidder with experience in innovation in companies or educational institutions. o Bidder with experience in the development and implementation of collaborative work tools. o Bidder with experience in web search technologies (Web semantics, recommendation systems, etc.). The consultant firm s team must have the following members, as a minimum: project manager, an expert in process modelling, a software engineer and a support professional. Professional Training Project Manager o Technical degree in IT, equivalent or higher. o Certification or graduate certificate in project management. o Four years or more work experience as a project manager. o Management of five or more IT projects. Open innovation expert o Technical degree in business administration or industrial engineering, equivalent or higher. o Certification in technological innovation. o Four years or more work experience in technological innovation. o Experience in collaborative work tools. o Experience in open innovation. Software engineer o Technical degree in IT, equivalent or higher. o Certification or graduate certificate in software engineering. o At least three years work experience in software engineering. o Experience in identifying requirements. Support professional o Technical degree in IT, equivalent or higher. o At least two years work experience in the technologies to be used. o Participation in at least 2 projects linked to the area of technological solutions. 13

14 XVI. XVII. TECHNICAL COUNTERPART Mr. Ignacio Villacura de la Paz, Civil IT Engineer, shall be responsible for the technical coordination of the project PMI InES. CONTRACT TYPE Once the project has been awarded, the parties must sign a contract establishing each of the Parties rights and responsibilities, within the framework of the required objectives, the proposal presented by the company to whom the project has been awarded, and the approved timeframes and budget. The economic value must include all related costs, including professional fees, transportation, meals, accommodations, materials, etc. ADMINISTRATIVE REQUIREMENTS Invoices should be made out to: Name: Universidad Técnica Federico Santa María RUT: Address: A. España 1680, Valparaíso Line of Business (Giro): Education 14