21/01/2019

Taller de preparación de
propuestas para proyectos
de investigación
Xavier Franch, PhD.
franch@essi.upc.edu

Quito, Ecuador. Enero 2019

Bio
2

 Profesor Catedrático en la UPC

 Doctor en Informática por la UPC
 Docencia:
 Ingeniería del software
 Estructuras de datos

 Introducción a la programación

 Coordinador del grupo de investigación GESSI

 Dirección de gran número de proyectos

1
 21/01/2019

El grupo de investigación GESSI

3

 Creado en 1992
 Evolución desde Sistemas de Información a Ingeniería del
Software y de los Servicios
 Actualmente también en temas Procesamiento de Datos

https://gessi.upc.edu/en

Proyectos competitivos europeos

4

H2020
Acronym Name Partners End Position
OpenReq Intelligent Recommendation U. Hamburg, Dec. WP leader
Decision Technologies for Nokia, … 2019
Community-Driven RE
Q-Rapids Quality-aware rapid software Fraunhofer, Oct. Project
development Nokia, … 2019 coordinator
SUPERSEDE SUpporting evolution and FBK April Scientific
adaptation of PERsonalized Siemens- 2018 manager
Software by Exploiting Austria,
contextual Data and End-user ATOS, …
feedback
FP7
RISCOSS Managing Risk and Costs in FBK, OW2, Dec. Project
OSS Adoption Ericsson-Italy 2015 coordinator
S-Cube Software Services and Lead by M. Feb. UPC
Systems Network (NoE) Papazoglou and 2012 Represen-
K. Pohl tative

2
 21/01/2019

Proyectos competitivos españoles

5

Acrónimo Nombre Partners Periodo

GENESIS Generation and Evolution of Smart APIs N/A Enero ’17 – Dic. ‘20
EOSSAC Engineering Open Source Services and N/A Enero ’14 – Dic. ‘16
Apps for the Citizens
ProS-Req Requirement-based production of service- UPV Enero ’11 – Dic. ‘13
oriented software (València)
ADICT Acquisition, Development, Integration and N/A Oct. ’07 – Dic. 10
Customization of Heterogeneous
Components for Information Systems
UPIC Towards a Unified framework for the UIC Dic. ’04 – Dic. ‘07
Procurement and Implementation of (Barcelona)
information system Components
DALÍ Methodologies and tools for the N/A Dic. ’01 – Dic. ‘04
Development, Acquisition, evaLuation and
Integration of software components
ComProLab A Component Programming Laboratory N/A Oct. ’97 – Dic. ‘00

Tarjeta de visita
Xavier Franch

Universitat Politècnica de Catalunya

franch@essi.upc.edu

https://www.essi.upc.edu/~franch/

@franch.xavier

xavier.franch

3
 21/01/2019

Who are you?

7

Who are you?

8

Nombres Apellidos Institución a la que pertenece Titulación

Germán Eduardo Rodríguez Galán Escuela Politécnica Nacional MSc en Redes de Comunicaciones, Doctorando en Informática
Jhonattan Javier Barriga Andrade Escuela Politécnica Nacional MSc. in Computer Forensics and Systems Security
Gabriel Roberto López Fonseca Escuela Politécnica Nacional Magister en Gestión de las Comunicaciones y Tecnologías de la Información
Franklin Leonel Sánchez Catota Escuela Politécnica Nacional Master en Ingeniería Telemática
Sang Guun Yoo Escuela Politécnica Nacional Ph.D. in Computer Science and Engineering (Sogang University, Corea del Sur)
Hugo Oswaldo Moreno Aviles Escuela Superior Politécnica de Chimborazo Ph.D. en Ingeniería Informática y Sistemas
jose morales Escuela Superior Politécnica de Chimborazo Master en Sistemas de Control y Automatización Industrial
Edgar Giovanny Cuzco Silva Unach Master en Formulación, evaluación y Sesión de proyectos Sociales y Productivos
Eduardo Fernandez Uniandes Master en Ingeniería de Sistemas
María de Lourdes Cedillo Armijos Universidad Católica de Cuenca Dra. en Psicología clínica y Mgst. en Educación.
Wilson Clodoveo  García Guevara Universidad Católica de Cuenca Doctor en Ciencias de la Educación Especialidad Psicología Educativa/Magister en Educación Superior
Patricia Elizabeth Venegas Izquierdo Universidad Católica de Cuenca Doctor en Ciencias de la Ingeniería (Universidad Católica de Lovaina, Bélgica)
Susana Graciela Cadena Vela Universidad Central del Ecuador Doctor en Informática
ROBERT ARTURO ENRIQUEZ REYES Universidad Central del Ecuador Doctor en informática
Jorge Luis Merchán Lima Universidad de Cuenca Ingeniero de Sistemas
Aldrin Geovany Acosta Fernandez Universidad de las Fuerzas Armadas ‐ ESPE Magister en Educación y Desarrollo Social; Ing. en Empresas Turísticas y Áreas Naturales
Rolando Marcelo Álvarez Veintimilla Universidad de las Fuerzas Armadas ‐ ESPE Magister en Redes en Comunicaciones
Alyssa Krupskaia Cadena Gómez Universidad de las Fuerzas Armadas ‐ ESPE Ingeniera de Sistemas
Caterine Isabel Donoso Quimbita Universidad de las Fuerzas Armadas ‐ ESPE Magister en calidad, seguridad y ambiente
Efraín Rodrigo Fonseca Carrera Universidad de las Fuerzas Armadas ‐ ESPE Doctor en Software y Sistemas
Walter Marcelo Fuertes Díaz Universidad de las Fuerzas Armadas ‐ ESPE Doctor en Ingeniería Informática y de Telecomunicación
Tatiana Marisol Gualotuña Alvarez Universidad de las Fuerzas Armadas ‐ ESPE Doctor en Tecnologías de la Información
Diego Miguel Marcillo Parra Universidad de las Fuerzas Armadas ‐ ESPE Doctor en Tecnologías de la Información y sus Aplicaciones
Geovanni Ninahualpa Quiña Universidad de las Fuerzas Armadas ‐ ESPE Magister en Evaluación y Auditoria de Sistemas Tecnológicas
HUGO LEOPOLDO PEREZ VACA Universidad de las Fuerzas Armadas ‐ ESPE Magister en Pensamiento Estratégico y Prospectiva para la Educación Superior
Dorys Soledad Quiroz Corrales Universidad de las Fuerzas Armadas ‐ ESPE Diplomado internacional en competencias docentes
Jorge Geovanny Raura Ruiz Universidad de las Fuerzas Armadas ‐ ESPE Master en Ingeniería de Software
ROLANDO PATRICIO REYES CHICANGO Universidad de las Fuerzas Armadas ‐ ESPE Master en Software y Sistemas (Universidad Politécnica de Madrid, España)
Freddy Mauricio Tapia León Universidad de las Fuerzas Armadas ‐ ESPE Doctorando en Ingeniería Informática y de Telecomunicaciones.
Paola Maritza Velasco Sanchez Universidad de las Fuerzas Armadas ‐ ESPE Magister en Redes de Comunicaciones
Adriana del Pilar León Pesántez Universidad del Azuay Mgst. en Intervención y Educación Inicial
Luis Tello Oquendo Universidad Nacional de Chimborazo Doctor en telecomunicaciones
RAFAEL EDUARDO RODRIGUEZ JARA Universidad Nacional de Educación Magister en Investigación Educativa
Efrén Leandro  Lema Condo Universidad Politécnica Salesiana  Ingeniero Electrónico
Fausto Mauricio  Tamayo Vásquez Universidad Técnica de Ambato Master en Gerencia de Proyectos educativos y Sociales
Fredy Maximiliano Jordán Cordonez Universidad Técnica de Babahoyo  Maestría en Informática empresarial
ESTEVAN RICARDO GOMEZ TORRES UTE Master en Gerencia de Sistemas
Oswaldo Vicente Moscoso Zea UTE MASTER OF SCIENCE IN INFORMATION SYSTEMS
Diego Antonio Ordóñez Camacho UTE Doctor en Ciencias de la Ingeniería
PABLO SAA UTE MBA, Mgt. en Sistemas de la Información.

4
 21/01/2019

Tres tipos de inscritos

9

Informática 22
Informática 7
Ingeniería de sistemas 3
Tecnologías de la información 3
Ingeniería del software 2
Sistemas de información 2
Computer science 1
Seguridad de sistemas 1
Evaluación y auditoría 1
Gerencia de sistemas 1
Informática empresarial 1
Otras ingenierías 8
Telemática/Telecomunicacione 2
Ciencias de la ingeniería 2
Redes en comunicaciones 2
Electrónica 1
Automática 1
Sociales 10
Educación 6
Proyectos 2
Psicología 1
Calidad 1

Objetivos del curso

10

 Analizar en detalle todas las partes que componen un

proyecto de investigación típico
 Entender los factores de éxito más importantes en la
redacción de propuestas de proyectos de investigación
 Conocer una serie de hábitos y costumbres (tips) que
pueden dar apoyo al tratamiento de dichos factores
de éxito
Usaremos proyectos de ingeniería del software como
ejemplo de aplicación

5
 21/01/2019

Agenda
11

 Concepto de proyecto de investigación

 Planteo del proyecto

 Impacto

 Diseminación, comunicación y colaboración (DCC)

 Explotación

 Gestión del proyecto

 Tips – Algunos consejos (en base a la experiencia)

 Conclusiones

Metodología docente
12

 Presentación de conceptos
 Ejemplificación mediante texto “real”

 Ejercicios prácticos en grupo

6
 21/01/2019

Hora de comenzar
13

Pero antes...

DISCLAIMER
14

Este taller se basa en la experiencia personal del

ponente/moderador en la solicitud de proyectos
como coordinador
 El contexto puede variar
 La tipología de proyectos puede variar
 Los evaluadores pueden seguir diversos criterios
 Y ninguno de ustedes es mi clon!
Por lo tanto, es su trabajo contextualizar todo el
conocimiento y habilidades compartidas en este curso
a su propia experiencia
 No se devuelve el dinero :-P

7
 21/01/2019

Hora de comenzar (ahora sí!)

15

8
 21/01/2019

Concepto de proyecto de
investigación

Definición
2

Un proyecto de investigación es un
procedimiento científico destinado a
recabar información y formular
hipótesis sobre un determinado
fenómeno social o científico

1
 21/01/2019

Tipología de proyectos de investigación

3

 Proyecto individual
 Concurso opositor a plaza universitaria
 Petición de beca

 Proyecto de grupo de investigación

 Proyecto nacional de investigación básica
 Proyecto colaborativo
 Proyecto transnacional de investigación puntera
 Proyecto de investigación aplicada
 Proyecto de innovación con consorcio multinacional
…

Ejemplos de proyectos de investigación

4

 Gestión de riesgos en proyectos Open Source

 Gestión de los requisitos de calidad en metodologías
ágiles
 Y el suyo?

2
 21/01/2019

Parte práctica: configuración inicial

5

Objetivo: formar equipos entre 4 y 5 personas para

trabajar conjuntamente durante el taller

Dichos equipos han de acordar:

 Tipología de proyecto

 Ámbito del proyecto

 Especializado, si existe interés mutuo

 Piensen en algún proyecto que luego puedan desarrollar
 Por ejemplo, un proyecto basado en investigación actual
 Genérico, si no existe
 Deportes, cocina, familia, …

Parte práctica: configuración inicial

6

Qué equipos, tipología y ámbito han salido?

3
 21/01/2019

Estructura general de un proyecto

7

El detalle de la estructura general va a depender (como

mínimo) de la tipología del proyecto y de las
características de la convocatoria

Pero a nivel general, podemos distinguir tres partes:

 Núcleo central de la propuesta

 Impacto del proyecto

 Gestión del proyecto

Todas estas partes son igualmente importantes

Núcleo central
8

Presenta la idea central del proyecto de investigación

Pregunta clave: qué problema científico resuelve mi

proyecto que actualmente no está resuelto?

Qué debe mostrar:

 Preámbulo: contexto, motivación y objetivo general

 Hipótesis y preguntas de investigación

 Estado de la cuestión

 Método de investigación

4
 21/01/2019

Impacto del proyecto

9

Justifica la necesidad del proyecto

Pregunta clave: qué beneficio reporta mi proyecto a la

comunidad científica y/o a la sociedad?

Qué debe mostrar:

 Diseminación

 Comunicación

 Colaboración

 Explotación

Gestión del proyecto

10

Desarrolla la estructura organizativa del proyecto

Pregunta clave: cómo debo gestionar el proyecto para

conseguir sus objetivos?

Qué debe mostrar:

 Plan de trabajo

 Consorcio

 Procedimientos

 Recursos necesarios

5
 21/01/2019

Éxito de la propuesta
11

En base a estos tres elementos:

 Una buena idea bien presentada

 Con objetivos claros y apropiados

 Con impacto adecuado tanto científico como social

 Con una metodología y un equipo de trabajo que

muestren la viabilidad de la propuesta
 Y con algo de suerte, al final…

Para completar la propuesta…

12

No olvidemos:
 Portada

 Resumen

 Referencias

 Agradecimientos

 Apéndices

 Recursos adicionales

6
 21/01/2019

El primer desafío…
13

Cuanto espacio se dedica a cada parte?

Va a depender de la convocatoria:
 Espacio total vs.

 Espacio por capítulos/secciones

En todo caso, la habilidad de comunicar las

ideas esenciales en espacio limitado es uno de
los retos más importantes en la escritura de una
propuesta

La convocatoria
14

Gran parte del éxito de la propuesta radica en

conocer todos los aspectos de la convocatoria
 Temática
 Detalle de las propuestas (tipología, estructura)
 Histórico de resultados
 Fechas
 Proceso de envío
 Proceso de evaluación
 Saber popular
 Apoyo

7
 21/01/2019

Conocer en detalle el programa

15

Fuente: FP7 programme

Conocer en detalle los presupuestos

16

Fuente: FP7 programme

8
 21/01/2019

Conocer en detalle el financiamiento

17

Fuente: FP7 programme

Conocer en detalle los instrumentos

18

Fuente: FP7 programme

9
 21/01/2019

Conocer en detalle la tasa de éxito

19

Fuente: FP7 programme

Conocer en detalle la estructura

20

Fuente: FP7 programme

10
 21/01/2019

Conocer en detalle las fechas y budget

21

Fuente: FP7 programme

Conocer en detalle los recursos

22

Fuente: FP7 programme

11
 21/01/2019

Conocer en detalle la evaluación

23

Fuente: FP7 programme

Parte práctica: conocer la convocatoria

24

Objetivo: entender la importancia y la dificultad para

localizar la información de una convocatoria determinada

Output: preparar un breve informe con un resumen de los

puntos clave de la convocatoria para usar en el resto del
ejercicio práctico
 Pueden tomarse alguna licencia si así lo desean

12
 21/01/2019

Ya podemos empezar!
25

13
 21/01/2019

Núcleo del proyecto

Estructura
2

El núcleo de la propuesta debe mostrar claramente

 Contexto del problema

 Enunciado del problema

 Objetivos / Preguntas de investigación

 Desarrollo de la solución. Resultados

 Avance sobre el estado del arte

 Método de investigación. Evaluación

La forma de combinar estos elementos determina

en gran manera el éxito de la propuesta

1
 21/01/2019

Contexto del problema

3

Es necesario poner al lector en situación:

 Cuál es la temática del proyecto?

 Qué conceptos básicos necesita dominar el lector?

Prepara correctamente la presentación del problema

Adjetivos clave:
 Conciso

 Claro

 Atractivo visualmente

 Motivador

 Sustanciado

Ejemplo
4

Importancia del àrea [OSS]

Open Source Software (OSS) has become a strategic asset for a number of
reasons, such as its short time-to-market software service and product delivery,
reduced development and maintenance costs, and its customization capabilities.
Open source technologies are currently embedded in almost all commercial
software – by 2013, they will be included in 85% of all commercial software
packages [Gar11b].

2
 21/01/2019

Ejemplo
5

Contexto [insuficiente gestión del riesgo]

In spite of the increasing strategic importance of OSS technologies, IT companies
and organizations face numerous difficulties and challenges when making the
strategic move to integrate in their work processes the open source way of
working. Among them, it stands that OSS is about freedom and choice, but
freedom and choice introduce risk [Gar11a]. The risks that IT companies face
when integrating OSS components into their solutions are not to be neglected and
incorrect decisions may lead to expensive failures. In 2008, forecasting studies
predicted that by 2011 less than 50% of Global 2000 IT organizations would
implemented a formal OSS adoption and manage-ment policy as part of their
enterprise software asset management strategy [Gar08b]. An indeed, insufficient
risk management has recently been reported as one of the five topmost
mistakes to avoid when implemen-ting OSS-based solutions [Gar11c]. In fact,
according to the most popular OSS portal, SourceForge, most OSS projects have
ended in failure: 58% do not move beyond the alpha developmental stage, 22%
remain in the planning phase, 17% remain in the pre-alpha phase, and some
become inactive. Similar results have been reported by the World Bank study
which cites a failure rate of more than 50% for OSS projects [LKG09]. With
proper risk management and mitigation, failure could be reduced or impact cost
minimized.

Parte práctica: describir contexto

6

Esbozar en dos párrafos el contexto necesario para

comprender el problema que se piensa abordar

Evaluación:
 Contexto bien descrito?

 Fundamentado con datos?

3
 21/01/2019

Enunciado del problema

7

Descripción breve del problema a resolver

Adjetivos clave:
 Conciso

 Claro

 Atractivo visualmente

 Motivador

 Alineado (continuación natural del contexto)

Ejemplo
8

Presentación del problema [riesgo asociado a integración]

To maximize the advantage of OSS adoption, the understanding and
management of all the risks becomes necessary since they directly impact
business, with strong effects on customer satisfaction, revenue, brand image, and
time-to-market. Such risks can be manifold and might include evaluation,
integration, context, process, quality and evolution risks [RH01]. Empirical
studies [LCS+08] show in particular that the underestimation of integration
efforts is one of the most challenging problems still requiring further
investigation. The risk management strategy is always a problem that need to be
taken care of throughout the whole lifetime of OSS-based solutions, and is even
more valuable during their maintenance phase. This takes into consideration the
fact that the cost of maintenance is high, because maintenance is a time-
consuming activity. Moreover, OSS-based solutions are not developed and do not
exist in isolation. Instead, they exist in the wider context of an organization and
of various OSS communities forming, larger OSS-based software ecosystems,
which include groups of projects that are developed and co-evolve within the
same environment, but also further beyond, their context, including the
organization itself, OSS communities, regulatory bodies, etc., forming a wider
and more strategic business ecosystem.

4
 21/01/2019

Parte práctica: describir problema

9

Describir en tres líneas el problema que se pretende

abordar en la propuesta

Evaluación:
 Problema alineado con contexto?

 Parece realmente un problema abierto?

Uso de un caso de estudio

10

Consiste en describir un ejemplo práctico del contexto y el

problema mediante un caso de estudio
Ventajas:
 Añade nivel de detalle

 Ilustra que se trata de un problema práctico

 Eventualmente, muestra compromiso de un participante

(empresa)

5
 21/01/2019

Ejemplo
11

Descripción del contexto y problema

Consider for example a project at one of the project partners, AAA. AAA
develops regulatory products, including state-of-the-art products for data
retention and lawful interception, belonging to the regulatory solutions
product family. For each product within the product family, AAA maintains
two release versions (under maintenance mode) and a third one under
development. Moreover products are typically adapted to meet the needs of
different customers, because different operators (in particular operators in
different countries) manage the telecommunication network nodes differently.
This introduces the need to systematically identify and manage variability
besides the common part of the product. Each single product release version
(and/or variant) contains a long list of third-party products, many of them OSS
components, potentially different (for versions, patch level, etc.) from each
other.

Ejemplo
12

Desafíos abiertos

Taken together, AAA is managing a complex ecosystem where several

questions emerge, e.g.:
 How to design the possible viewpoints from which one can look at an
ecosystem in order to collect relevant information for managing the evolution
for the OSS products embedded in AAA’s applications?
 How to secure that specific features of AAA do not harm business
strategies and their underlying business models?
 How to implement a systematic approach toward understanding and
representing dependencies that involve AAA components for assessing all
kinds of risk?

6
 21/01/2019

Ejemplo
13

Necesidad
The answer to these questions requires the clear
understanding of OSS-based ecosystems from a
strategic and operational perspective, with clear
identification of relevant strategic and operational
dependencies (i.e. not just software dependencies) in
order to control and mitigate all the risks coming from
the adoption of OSS components, throughout the lifetime
of the different products and components that are part of
the OSS ecosystems.

Parte práctica: presentar caso

14

Esbozar en dos párrafos un caso (real o imaginario) que

describa un ejemplo del contexto y el problema.

Evaluación:
 El caso está alineado con el problema?

 Es un caso comprensible?

 Es un caso motivador?

7
 21/01/2019

Esbozo de la solución
15

Esbozo de la idea sobre la que gira el proyecto para

solucionar el problema presentado
Sirve de nexo entre el problema y los objetivos

Ubicarlo después del caso presentado es una manera

natural de presentarlo

Ejemplo
16

The XXX project will provide tools and methods for

community-based and industry-supported OSS
development, composition and life cycle management that
enables industrial stakeholders to:
– practicing an effective management of OSS integration related
risks;
– controlling and reducing the costs derived from the adoption
of OSS;
– pushing for innovation to take the best of this strategic
movement
To accomplish these objectives, the XXX project will design
and test a risk-aware decision-making infrastructure that will
work over a management-oriented view of the organization
projects’ ecosystem. This infrastructure will be fed by a
software platform integrating different techniques for analysing
and evaluating OSS-based systems and risks.

8
 21/01/2019

Parte práctica: esbozar solución

17

Esbozar en un párrafo la solución al problema

presentado

Evaluación:
 La solución está alineada con el caso presentada?

 Parece factible?

Objetivos / Preguntas de investigación

18

Establecimiento del motivo de ser del proyecto

 Qué se pretende conseguir con el proyecto?

Objetivos vs. preguntas de investigación: más o menos

intercambiables

Normalmente los objetivos siguen un proceso para su

identificación:
 Descomposición

 Estratificación

Ambas alternativas son combinables

9
 21/01/2019

Alternativa 1: descomposición
19

Se definen uno o más objetivos al mismo nivel

Cada objetivo se descompone en diversos subobjetivos
Por ejemplo (extracto):
Objective O2. Risk management of OSS projects. Support to the establishment
of practices and processes, based on innovative software engineering and
statistical assessment and measurement techniques, for the management of risk in
a continuous and incremental way. It decomposes into three sub-objectives.
O2.1 Offer light weight assessment techniques usable in small businesses
and OSS communities as well as in-depth measurement and optimization
techniques applicable in large enterprise organizations and communities.
O2.2. Offer techniques to support the identification and analysis of risk
related costs and benefits when adopting OSS in software projects.
O2.3. Offer guidance to organizations for designing and implementing a
continuous improvement plan to support risk mitigation during the life of
software systems, from conception to retirement.

Alternativa 2: estratificación
20

Se definen objetivos a diferentes niveles

Los objetivos de un nivel inducen los del nivel
inmediatamente inferior
Por ejemplo:

10
 21/01/2019

Objetivos transversales
21

Opcionalmente, se pueden mencionar otros objetivos

relacionados con aspectos transversales del proyecto, por
ejemplo:
 Objetivos tecnológicos

 Objetivos de evaluación

 Objetivos de impacto

Ejemplo
22

Objective O4. Deployment of a software engineering platform for supporting decision-making.

Construction of an open-source platform integrating the methods, models and techniques developed in
the context of the project.
O4.1. Deliver an IT platform for analysing and managing OSS-based ecosystems with the
purpose of supporting the objectives O1-O3 related to OSS development, composition and life-
cycle management.
O4.2. Integrate and test existing OSS-based technologies with the purpose of reducing the
development effort.
O4.3. Specify, design, implement and test new methods and techniques that do not exist or
cannot be reused that are necessary for achieving the objectives O1-O3.
O4.4. Build the platform on top of a software architecture respecting the following principles:
Openness. Build the platform as an OSS system with a community growing.
Usability. Facilitate the use of the platform by end-users.
Interoperability. Facilitate information interchange with other tools through a standard data
exchange protocol (API) and using standard data formats.
Objective O5. Industrial validation of project results. Demonstrate the results of the project in a
number of representative use cases, drawn from different application domains, involving the appropriate
actors.

11
 21/01/2019

Parte práctica: fijar objetivos

23

Identificar los objetivos del proyecto. Seguir alguna de

las alternativas introducidas. No olvidar objetivos
transversales

Evaluación:
 Los objetivos parece correctos?

 Todos juntos, son coherentes?

 Solucionan el problema planteado?

Desarrollo de la solución
24

Describe el nudo de la propuesta destinada a

resolver los objetivos identificados

Debe identificar métodos, técnicas, procesos,

herramientas y un marco formal que conlleven a la
consecución de los objetivos

Debe ser convincente y apoyarse en referencias

bibliográficas adecuadas

12
 21/01/2019

Ejemplo
25

1.1.3 The XXX Framework in the context of OSS-based ecosystems

James F. Moore in his award winning Harvard Business Review article [Moo93], coined
the term business ecosystem to describe: “an economic community supported by a
foundation of interacting organizations and individuals—the organisms of the
business world. …”.
Business ecosystems have their counterpart at the technological level. Messerschmitt
and Szyperski [MS03] used the term software ecosystem to describe the broader
commercial, legal (regulatory) and market context in which traditional software systems
operate. Companies such as Apple and Google …. Key arguments why companies
adopt a software ecosystem approach to support their products and services offerings
include [Bos09]: increase value of the core offering to existing users; …. The links
between more strategic business ecosystems and more IT-oriented software ecosystems
is one of the focal points of the XXX project.
When it comes to OSS, both types of ecosystems have their peculiarities. …. Helander
& Rissanen [HR05] focus on the co-creation of value in OSS value networks, thus
highlighting an aspect of OSS-based ecosystems that is important especially for
businesses. .... There are a number of diverse actors that can form an OSS value
network ….
The XXX project aims to advance the research on the formulation and analysis of OSS-
based ecosystems with the ultimate business goal of improving current practices in OSS
risk management with the purpose of reducing OSS adoption and implementation
costs…

Figura central
26

Es conveniente articular la idea de la solución alrededor de

una figura central:
 Elementos principales

 Interrelaciones

Dicha figura puede utilizarse en otros puntos de la

propuesta:
 Estado de la cuestión

 Plan de trabajo

 …

13
 21/01/2019

Ejemplo
27

Fig. 1.2 elaborates on the concept of OSS value chain to

describe the approach. It is supported by a collaborative
platform, the XXX platform, that provides the entry-point for
describing, analysing and performing decisions in OSS business
ecosystems. The XXX platform is composed of two tiers, the
decisional tier that provides assessment to companies, and the
technological tier that embeds the software system and
provides observations to the decisional tier for decision making.
The open source software system integrates components
coming from OSS communities, whose adoption requires a
negogiation between the community and the interested
company. This negotiation is undertaken under perceptions of a
shared conceptualization that can be different, difficulting the
inderstanding among the parties.

Otros estilos
28

Más simple Más operacional

Más profesional

14
 21/01/2019

Parte práctica: desarrollo de la solución

29

Sinteticen la idea de la solución en una figura central

Evaluación:
 La figura comunica claramente la solución pensada?

Alineamiento con la convocatoria

30

Es conveniente argumentar explícitamente que el

proyecto esta alineado con la convocatoria:
 No dejen nada a la imaginación del revisor

Dependiendo del espacio, puede ser más o menos

exhaustiva:
 Desde un par de frases generales…

 …a un análisis pormenorizado de cada frase de la

convocatoria

15
 21/01/2019

Ejemplo
31

The project results will have a high impact in relation to one of the topics mentioned
in the call, namely “Fast innovation cycles in service industry, e.g. through the
use of Open Source development models”. We are targeting the problems related
with OSS adoption whose solution is a must in order to implement those innovation
cycles. In other words, it is not enough for a project to claim that they deliver an
OSS solution if there are no clear means to deploy and manage over time this
solution in the adopting organization.

Ejemplo
32

Call text: Novel development approaches which would drastically increase development
productivity and various dimensions of software quality such as security, reliability,
performance, scalability and adaptability
The project proposes a novel development approach characterized by the management of NFRs in the
context of software processes with very short delivery cycles. The main novel traits are: 1) Evidence
based (SO1): Data gathered from several sources are used as evidence to drive the consideration of
quality aspects and the full development process. 2) Conceptual simplicity (SO2): The objective of
leveraging QRs with functional requirements in the software process addresses one of the most well-
known drawbacks in all type of software development methods, namely being waterfall based, agile or
rapid. 3) Strategic dimension (SO3): The elaboration of basic quality-related data into strategic key
indicators, together with the capabilities provided by a powerful dashboard, empower decision makers
to make more effective decisions regarding release planning, resource allocation and so on. All in all,
the project drastically increases development productivity. Given that the approach is generic with
respect to quality, it is well prepared to deal with the diversity of QR types, including security,
reliability, performance, scalability and adaptability.

16
 21/01/2019

Avance sobre el estado del arte

33

Todo proyecto científico debe justificar cuáles son sus

avances sobre el estado del arte:

Para ello debe establecerse:

 El estado del arte en sí

 Los desafíos que quedan abiertos

 La manera en que el proyecto propone avances en

dichos desafíos

Estado del arte

34

La forma de conducir el estado del arte dependerá

sobre todo de dos cuestiones:
 El nivel de conocimiento que se disponga

 La necesidad de consultar fuentes más allá de

literatura científica

17
 21/01/2019

Revisiones sistemáticas de literatura

35

Una metodología consolidada para localizar los artículos

más relevantes sobre un tema basada en definir:
 Pregunta de investigación

 Cadena de búsqueda

 Bibliotecas digitales sobre las que buscar

 Formularios de extracción de datos

 Criterios de inclusión y exclusión

 Posiblemente, estrategia de avalancha (snowballing)

Los artículos localizados se analizan usando alguna

variante más o menos rigurosa de análisis de contenidos

Más allá de la literatura científica

36

No toda la información relevante para un proyecto está en

literatura científica
Otras fuentes a controlar son:
 Artículos de divulgación (grey literatura)

 Informes de consultoras (Gartner, Forrester, …)

 Herramientas

 Blogs (si son fiables)

Todas estas fuentes tienen problemas asociados, pero no

deben desdeñarse

18
 21/01/2019

Relación con otros proyectos

37

Es importante mencionar en el estado del arte posibles

proyectos existentes en la misma temática
Objetivos:
 Convencer al revisor que se conocen

 Evitar producir resultados que dichos proyectos ya han

producido
 Identificar posibles sinergias

 Utilizar resultados si ya han acabado

 Plantear colaboraciones si están en marcha

Ejemplo
38

Possibility to integrate or communicate with into

FP project Points of contact with the project
FP6
 Metrics for OSS engineering
EDOS  Interdependencies among components
 Software process models for OSS
FLOSSMETRICS  Evaluation of metrics on OSS projects
 Methods and tools to improve OSS quality
QualiPSO  Methods, development processes, and business
models to facilitate the use of OSS by industry
 Quality assessment method to assess risk (as the
QualOSS difference among thresholds and answers to
selected questions, for different indicators)
SQO-OSS  Software quality assessment models and tools
FP7
 Knowledge about bugs as reported by involved
ALERT (ongoing)
communities (focus on workflow)
 OSS evolution risks
MANCOOSI  OSS-based system models with focus on inter-
dependencies among components
the project, or interesting input for it
 EDOS indicators for OSS engineering issues
 Formal component dependency description model and
tool support (SODIAC)
 Process Reference Model that captures the activities,
roles and resources of the OSS process (with API)
 Empirical data from thousands of projects
 Bug tracking retrieval tool (Bicho)
 SME guide to OSS
 OWL-ontology of OSS licences (with tool support)
 Communication with selected functionalities of the
QualiPSO factory
 QualOSS quality model
 QualOSS plaftorm (spreadsheet importing facilities +
visualization tools)
 SQO-OSS quality model
 The Alitheia Core tool and associated plug-ins for
obtaining statistics about OSS projects
 Techniques for maintaining awareness on community
activities
 Model for a reactive platform
 Ontology for conceptual dependencies between
community, content and interactions
 Different algorithms for analysing the effects of
updates (e.g., EVOSS for model-based upgrade
simulation)

19
 21/01/2019

Ejemplo
39

While OSS-based software ecosystems offer key benefits, the successful

adoption or integration into business ecosystems poses to companies
strategic challenges and risks that go far beyond traditional relationship
management in the marketplace [YD11].
Since research in ecosystems from a software engineering perspective is quite
new [JFB09], little work to-date has been done …

While these aforementioned approaches offer different kinds of deeper

understanding of software ecosystems, they do not specifically deal with the
strategic aspects of organizations around the software ecosystem, in particular
the potential synergies and conflicts of ecosystem participants in terms of their
individual and collective interests, goals and strategies.

Recent work outlined an approach to model and analyze business ecosystems

using i* [YD11].

Ejemplo
40

Challenges posed by the current state of the art

 Q1. What are the foundational concepts that are to be managed by the technique?
 Q2. What are the analytical methods to be applied for discovering relevant
ecosystem properties?
 Q3. How can this notation be effectively adopted in an industrial setting with usual
scalability and learning curve problems?
 Q4. What is the mapping between software and business ecosystems?

Progress beyond the state of the art

 Q2. Adopt goal-oriented analysis methods like backward or forward analysis [HY10],
model measures [Fra06] and logical reasoning [GMNS02] to uncover interesting
properties in goal-oriented models. These general-purpose concepts need to be tailored
to the context of interest and in particular, they have to be grounded on the foundational
ontology defined above. In particular, analysis of legal, cost and risk related aspects will
be of utterly interest. Integration of the proposal with existing business modeling
approaches will be target of analysis too.

20
 21/01/2019

Método de evaluación
41

(Más bien, métodos...)

Define el alfa y el omega del proyecto:
 Alfa: el proyecto se fundamenta en datos sólidos

 Omega: el proyecto proporciona los resultados

esperados

En un proyecto típico, la evaluación se fundamenta

sobre unos casos piloto

Casos piloto
42

Dos grandes casos:

 Proyecto de investigación básica

 Normalmente, experimentos
 Proyecto de colaboración industrial
 Mayor variedad de métodos
 Es necesario asegurar diversidad de los pilotos

21
 21/01/2019

Ejemplo
43

PAIS TAMAÑO TIPO AREA

AAA IT VERY LARGE COMPAÑÍA • Programa de gestión de riesgos
• Seguridad
BBB FR LARGE ORGANIZACIÓN Riesgos integrados en un programa
NO LUCRATIVA integral de gestión de la calidad
CCC FR MEDIUM COMPAÑÍA Apoyo metodológico a la gestión de
riesgos durante el desarrollo
DDD ES MEDIUM ADMINISTRACIÓN • Migración a OSS
PÚBLICA • Code release
EEE ES SMALL SPIN-OFF Evolución risk-aware de una plataforma
UNIVERSIDAD de e-learning

Ejemplo
44

Comp A Comp B Comp C Comp D

TRL planned 7 6 7 6
Use case title A holistic transparency on Modelio Case Study - Quality of a A process change for engineering Reconciling improved quality
embedded software systems life long lifetime software product line non-functional requirements checking process with rapid
cycle releases approach
Use case Multiple products, product lines and Single long lifetime software Multiple product lines each having their Multiple independent software
setting platforms with hardware and product line own products combining hardware and products
software components software components
Quality Management of Multi-Product Line Management of Single Software Management of Very Large System Management of Software Product
requirements Quality Requirements and Shared Product Line QRs Quality Requirements and Management of Line QRs
management Platform QRs Shared Corporate Level Common QRs
Product Unified development process for all Software development process Release-based development process Scrum methodology. The creation
development products based on Scrum & Kanban based on Scrum methods based on agile and lean principles with process embraces the full life-
process methods variations in individual product lines cycle, from conceptualization to
framework deployment.
Software Distributed systems in defence, Tools for model-based software Distributed systems in telecommunication Simulation and decision support
product public safety & security, telecom, development networks system for crisis management,
domain embedded special devices, health monitoring, tool for cyber
wearables and IOT solutions security audits
Use case Quality requirements life-cycle Product line quality, quality Common corporate and system level QRs Software quality assurance and
specific process transparency, operational assurance in multiple platforms, design and status traceability within and data security in rapid release
issues to be efficiency and shortening of the product and maintenance costs between product lines in cycles
addressed release cycles (time-to-market) reduction telecommunication systems development
Use case Develop decision making support Product quality improvement with Develop methodo-logical support to Software development and security
specific key with life-cycle data mining, analysis early detection of anomalies and manage common requirements. Analyse (sensitive customer data)
objectives tools and methods with multiple regression. Customer product and determine what kind of tool support is assurance process improvement,
stakeholder, platform and product usage data analysis for future required and draw the necessary require- development related issue
line consideration requirements and market ments for tools to be suitable for the deve- prediction
predictions lopment environment

22
 21/01/2019

Descripción de los casos piloto

45

Se recomienda usar una plantilla como:

 Contexto organizativo

 Desafíos actuales

 Objetivos específicos

 Instrumentación

También es conveniente una figura que los presente

en una frase

Ejemplo
46

23
 21/01/2019

Ejemplo
47

Context. The OSS project Moodbile aims to enable mobile learning applications (and other kinds
of applications for education) to work together with the Moodle Learning Management System
(LMS) (http://moodle.org, a high profile OSS LMS), which is used as host LMS platform in the
first stage of the project. Rather than just creating mobile applications that replicate the LMS
functionalities on a mobile device, Moodbile provides the developers of applications for
education with the necessary tools to communicate with the LMS (http://moodbile.org).
The motivation of the Moodbile project is to open up the most commonly used e-learning
platforms and LMS, originally designed as monolithic or layered systems, to the service
paradigm. This work is an interoperability solution to extend LMS to other environments such as
the mobile world. Its aim is to contribute in adapting LMS to the current generation of e-learning
2.0.
The Moodbile community also publishes the Moodbile Spec: a specification of a protocol
agnostic web services API. The Moodbile Spec is intended to be a bottom up breed standard for
integrating LMS with mobile apps.

Ejemplo
48

Current issues. The Moodbile server for Moodle is a component deeply integrated with the
official Moodle distribution. In 2010 Moodle.org adopted the SCRUM development methodology
and has started to ship new minor releases every six months. Moodbile has to keep compatibility
with each new release, while evolving the Moodbile feature set has to be done keeping backwards
compatibility with itself. On its last major release (v0.2) in November 2011, Moodbile is
supporting two versions of Moodle: 2.0 and 2.1, and Moodle.org just released a new version in
December 2011: Moodle 2.2 with significant changes in the core system and web services
component on which Moodbile Server for Moodle depends.
Moodbile’s purpose as a community is to innovate on LMS – Mobile Apps integration. Hence,
needs to iterate quickly incorporating new features and capabilities. But at the same time has to
provide a reliable product for the members of the community that have begun to use Moodbile in
education and training.
We expect difficulties maintaining compatibility with all versions of Moodle (and other host LMS
that will come into the scene), the own Moodbile clients and third part clients that have stared to
use Moodbile as a platform. The Moodbile community needs to correctly manage these risks in
order to succeed.

24
 21/01/2019

Ejemplo
49

Specific Objectives. The Moodbile community has the following objectives for the project:
 To manage the internal backwards compatibility risks between the 4 components developed
and maintained by the community (see below) without compromising the ability to innovate
and experiment.
 To manage the compatibility with the on-going releases of Moodle and other host-LMS to be.
 To manage the community requirements for evolution of the product balancing the resources
with the focus on reliability, stability and support for the released versions.

Instrumentation. This use case will work with the 4 main components that Moodbile currently
releases: (1) Moodbile server for Moodle, a plug-in for the Moodle LMS that implements a
protocol-independent web services API that allows integration with mobile clients. (2) Moodbile
HTML 5 Client Moodbile Client that runs on most mobile browsers. Moodbile HTML 5 Client
runs on the same web server as the LMS and provides a Mobile Web friendly limited front, using
the Moodbile Spec (web)services. (3) Android native client. (4) iOS native client.

Parte práctica: descripción de pilotos

50

Definan brevemente dos o tres pilotos (reales o

imaginarios) para su proyecto. Identifiquen las
características que crean conveniente

Evaluación:
 Adecuación del caso a los objetivos del proyecto

 Diversidad de tipología

 Diversidad de tamaño

 Otras diversidades

 Diversidad geográfica (si aplica)

25
 21/01/2019

Métodos de investigación
51

Es fundamental identificar los métodos a utilizar

durante el proyecto
Common “In the Lab” Common “In the Wild”
Methods Methods
• Controlled Experiments • Quasi Experiments
• Simulations • Case Studies
• Survey Research
• Ethnographies
• Action Research
• Artifact/Archive Analysis (“mining”), eg. Systematic
Literature Reviews (SLR)

Ejemplo
52

From the methodological perspective, the main type of instrument to be used in the
project is case studies. Case studies will provide a common platform for evaluating the
framework by focusing on different aspects of software development. According to [15],
case studies are “…an empirical inquiry that investigates a contemporary phenomenon
within its real-life context, especially when the boundaries between phenomenon and
context are not clearly evident” (p. 13). Case studies as applied in the use cases are
categorized as feasibility studies. For this context, the case studies will focus on
evaluating whether results can be applied in software development practice, whether the
different technological aspects are seamlessly integrated, whether the implemented tools
support the approach and on identifying improvement potential.
Other instruments that will be used in the project are the following [16]:
 Surveys. Surveys enable the collection of standardized information from (or a sample
of) a specific population. They will be used to determine the current states of practice
with practitioners either through questionnaires or interviews.
 …

26
 21/01/2019

Proceso de evaluación
53

 Los métodos por sí solos no garantizan la evaluación:

 Es necesario definir un plan alineado con el progreso científico

Características:
 Recogida de requisitos

 Implicación de los partners que proveen los pilotos

 Esencial visitarlos in-situ

 Evaluación iterativa  alimenta el proyecto

 Eval. formativa: pequeña escala, in-lab, desagregada
 Eval. sumativa: el producto completo en su contexto

 Se miden indicadores de impacto (v. más adelante)

Parte práctica: evaluación

54

Diseñen un programa de evaluación para su proyecto.

Haga referencia a los elementos anteriores (p.e., métodos
de investigación)

Evaluación:
 Planteamiento general de la evaluación

 Adecuación de los métodos elegidos a la situación de

los partners

27