Documento orientador

Unidad 1

Requerimientos de ​software

Yerson Faber Torres Cubillos

yefatocu84@gmail.com

Cesión de derechos de autor a la Corporación Universitaria Iberoamericana

Los requerimientos de ​software ​son la parte más importante y el punto de partida

para cualquier desarrollo de sistema, ​software​, aplicación o solución tecnológica a

realizar, pues es en esta etapa donde se analiza el problema a abordar, se comprende

este problema y se tienen en cuenta todas las características y, para continuar hablando

en términos técnicos, los requerimientos funcionales y no funcionales que debe

contemplar la solución a generar, todo orientado por las personas involucradas y

quienes se verán beneficiadas por el producto realizado.

En este documento se realizará el abordaje de las siguientes temáticas:

● Fundamentos.

● Procesos.

● Captura.

● Análisis.

● Especificación.

● Validación.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 ● Consideraciones prácticas.

Y donde se desarrollará de manera general los conceptos propuestos en el

Swebok, documento orientador a tener en cuenta desde la concepción de la ingeniería de

software ​para todo lo relacionado con los requerimientos de ​software ​y parte de la

bibliografía necesaria para la unidad.

1.1 Fundamentos de los requerimientos de ​software

Como fundamentos de requerimientos de ​software ​podemos entender que son

todas las técnicas y los procedimientos que se utilizan desde la ingeniería de ​software

para recolectar la información de un problema a solucionar y cuya solución apunta al

desarrollo de un proyecto de ​software​, de esta etapa del proyecto se deriva la definición

de lo que se pretende desarrollar, el cual debe estar directamente conectado con las

necesidades de los usuarios que se beneficiarán con el producto, resultado del proyecto.

En la figura 1 podemos evidenciar las características que nos comparte Arias

(2005) que deben tener los requerimientos de ​software ​para que queden bien formulados

o la necesidad de continuar trabajando en su definición hasta que se cumpla con estas

características.

Figura 1. Necesidades de los requerimientos de software

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 Estos requerimientos de ​software ​no surgen del azar, se deben elaborar con

autores o personas que están directamente relacionadas con el problema a mitigar o

resolver y es con ellos con quienes se construyen utilizando diferentes procesos que se

presentan a continuación.

1.2 Procesos de requerimientos de ​software

Hemos analizado que el proceso de los requerimientos es una de los puntos más

importantes el desarrollo de un proyecto de ​software​, esto se debe a que mediante la

experiencia, se ha podido determinar que los principales errores que se pueden presentar

en un proyecto se debe a que esta etapa tuvo falencias que derivaron en una solución

que no se ajusta a las necesidades de los usuarios. Y que en una etapa posterior a la

programación o diseño de ​software ​podrá generar costos y dependiendo del tamaño del

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

proyecto estos pueden ser altos, además de los incumplimientos en los cronogramas y

entregas del producto final.

Existen diferentes técnicas utilizadas en la recolección de los requerimientos,

desde las tradicionales aún vigentes como algunas transformaciones y evoluciones

realizadas a las mismas. Es importante reconocer que sin importar el proyecto y el área

en la que se trabaje, muchas de estas técnicas pueden ser enriquecidas, modificadas,

ajustadas al proyecto o incluso surgir nuevas técnicas que se deriven de la actividad o

naturaleza del problema a solucionar.

Entre estos procesos Pérez, Salamado y Valencia (2012) nos mencionan las

entrevistas, que son reuniones con los autores involucrados en los procesos para

determinar requerimientos, tanto funcionales como no funcionales. Otro procedimiento

son los prototipos, estos por lo general aumentan el costo del proyecto puesto que

incluyen diseños previos al definitivos para que sean evaluados y ajustados por los

autores involucrados en el proyecto. Las herramientas del lenguaje unificado modelado

(UML) es un procedimiento estandarizado por su naturaleza gráfica pero muy técnica,

que no permite facilitar el cumplimiento de las características analizadas de los

requerimientos anteriormente descritos, por la dificultad de que sean simples y claros

para los autores del proyecto. Por último, se menciona el modelado de procesos que se

realiza también mediante estándares para entender los procesos del negocio o problema

a solucionar y es una representación gráfica común, tanto para el equipo de desarrollo

de ​software ​como para los actores del proyecto.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

1.3 Captura de requerimientos de ​software

En la captura de requerimientos de ​software ​se analizan las fuentes de los

requerimientos, además de las técnicas a desarrollar según los procedimientos definidos

para el problema, estos varían y dependen de cada naturaleza del proyecto, algunos se

ajustan más a ciertas necesidades.

Los autores del proyecto se denominan ​stakeholders.​ Rodríguez, Gómez y

Angarita (2015) presentan en su artículo denominado “Método para interactuar con los

stakeholders en el proceso de captura de requerimientos de software” cuatro actividades

para realizar el proceso de captura y las cuales se resumen a continuación:

1. Identificar la técnica de captura adecuada según mencionamos en los

procesos de requerimiento de ​software.​

2. Relacionamiento con los ​stakeholders ​que se implementarán según los

procesos de requerimiento de ​software.​

3. Identificar los requerimientos que cumplan con las características de

requerimientos de la figura 1.

4. Entregar documento final de la fase de captura.

1.4 Análisis de requerimientos de ​software​.

En el numeral anterior mencionamos de manera general cómo se realiza la

captura de los requerimientos y cuatro actividades claves para hacer esta captura,

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

posterior a tener este proceso listo en la fase de requerimientos de ​software,​ se continúa

con el análisis de estos requerimientos, en donde se tendrán de manera clara los

procedimientos de automatización que realizará el ​software ​y de qué manera deben

realizarse las operaciones que generen los resultados esperados por nuestro cliente o

usuario del sistema, ​software ​o aplicación. En esta fase ya se tendrá claro cuál es el

producto final a entregar y con todas las características que se deben considerar, todo

gracias a una buena comunicación con todos los ​stakeholders q​ ue están involucrados en

el proceso.

En esta fase, como lo mencionan Molina y Torres (2010), se describen todas las

actividades que realizará el ​software c​ on sus entradas, operaciones y salidas esperadas,

así como las personas que son responsables de alimentar el proceso. Posterior a esto, se

categorizan los procesos según el modelo de negocio denominado “Proceso de negocio

modelado” conocido por sus siglas en inglés BPMN ​(Business Process Model and

Notation)​ que se esté abordando y la problemática que se esté solucionando. Después se

realiza un procedimiento para detallar cada una de las actividades y los subprocesos que

se derivan de cada actividad. Para estos procedimientos es importante realizar mapas de

procesos y documentar cada uno de los procedimientos para que sean aprobados por los

autores involucrados.

1.5 Especificación de requerimientos de ​software

En la especificación de los requerimientos de ​software s​ e hace referencia a la

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

elaboración de un documento donde todo el procedimiento realizado con la información

suministrada por los ​stakeholders,​ validado con ellos y, al igual, aprobado. Por lo

general, esto se delimita en diferentes documentos que se pueden identificar como

“definición del sistema”, que es donde se define el objetivo que tiene el sistema y debe

ser escrito en un lenguaje natural, de fácil comprensión para los directivos y autores

involucrados en el proyecto. El segundo documento se denomina “sistema de

requisitos”, hace referencia a todos los componentes del negocio que van a ser

automatizados, abordados o afectados por el ​software ​o producto del proyecto, es decir,

la visión, y por último, el documento de “requisitos del ​software​”, es donde está

definida toda la funcionalidad del software y es donde se indica a detalle todos los

componentes del software, sus costos, tiempos de producción, los posibles riesgos y la

fecha de entrega. Es importante resaltar que para la elaboración de estos documentos

existen estándares dados por la IEEE que indican de manera técnica los datos e

información que debe contener cada documento.

1.6 Validación de requerimientos de ​software

En esta etapa, es donde se mantiene abierta la comunicación entre los actores

involucrados en el proyecto y los desarrolladores de ​software,​ puesto que es donde se

validan conceptos, procesos, procedimientos, entradas, salidas e información que deberá

estar contemplada en el ​software y​ que debe coincidir con las fases anteriores y todo el

proceso de los requerimientos de ​software y​ a documentados. Validar los requisitos

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

permite evitar problemas a futuro y más cuando ya se han destinado recursos para

trabajar o avanzar en el proyecto. En esta fase se realiza la revisión de los requisitos, en

algunos casos sí fueron acordados con el cliente, el prototipado, se realiza la validación

del modelo y pruebas de aceptación.

1.7 Consideraciones prácticas

Para culminar, los requisitos de ​software s​ on los que delimitan todo el ciclo de

vida del ​software y​ será la clave de un excelente trabajo realizado por un ingeniero de

software ​o una compañía dedicada al desarrollo de soluciones digitales. Todo este

procedimiento documentado en cada una de las fases permitirá siempre tener por escrito

cada uno de los procedimientos realizados, es por ello que entre más clara y completa

esté la documentación, más fácil será entregar un producto que se ajuste a las

necesidades del cliente.

Existe una naturaleza iterativa del proceso de los requisitos donde el cliente

desea tener desarrollos a corto plazo, los productos son necesarios y en ocasiones

obligatorios para el funcionamiento de las empresas, por lo cual, en oportunidades, por

tanta celeridad en el proceso se tiende a cometer errores en el levantamiento de

requerimientos en los procesos de ​software​. Hay que tener claro que en un proceso

como estos es muy probable que algunos requerimientos cambien y debe desarrollarse

una habilidad para el cambio y rápido ajuste de los requerimientos. Por ello, la gestión

del cambio es primordial en este tipo de proyectos y esto se debe a cada una de las

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

etapas mencionadas en la validación de los requerimientos.

Los requisitos tienen cualidades, las cuales deben estar claramente identificadas

y con un estricto control de cambio y modificaciones que pudo tener cada uno de los

requisitos, con ello se tiene el seguimiento de cuándo un requisito cambió y por quién

fue modificado. Tener este tipo de seguimiento y conocer la cantidad de requisitos

permitirá generar el costo del proyecto y el costo que puede tener el mantenimiento del

producto resultado del proyecto de ​software.​

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 Referencias

Arias Chaves, M. (2005). La ingeniería de requerimientos y su importancia en el

desarrollo de proyectos de software. ​InterSedes: Revista de las Sedes Regionales, 6​

(10), 1-13.

Molina, J. C., & Torres Moreno, M. E. (2010). Análisis de requerimientos usando

BPMN. ​Revista Colombiana De Computación​, 1 1(1), 85-97.

Pérez-Virgen, H. L., Salamando-Mejía, C. A., & Valencia-Ayala, L. S. (2013).

Levantamiento De Requerimientos Basados En El Conocimiento Del Proceso.

Revista Científica, ​2 (16), 42-51.

Rodríguez, J. P. (2015). Método para interactuar con los stakeholders en el proceso de

captura de requerimientos de software. En R, Llamosa Villalba (Ed.). Revista

Gerencia Tecnológica Informática, 14 (40), 47-56.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 Documento orientador

Unidad 2

Design thinking

Yerson Faber Torres Cubillos

yefatocu84@gmail.com

Cesión de derechos de autor a la Corporación Universitaria Iberoamericana

2.1 Fundamentos

Airbnb, Ikea, Zara y Apple son algunas de las empresas más reconocidas que en

su modelo de negocio han utilizado ​design thinking c​ omo parte de la estrategia para

tener éxito, todo gracias al triángulo efectivo que presenta esta metodología entre

conocer de manera clara las necesidades de las personas, construir una solución

estratégica que sea viable dentro del negocio y que tecnológicamente sea factible. Por

estas razones, en la ingeniería de ​software e​ s importante conocer metodologías que son

exitosas para otras empresas como Apple que es un gran referente en la industria de

diseño, ​software,​ aplicaciones y experiencia. En la unidad 2 del módulo utilizaremos la

metodología ​design thinking​ como parte del proceso para el conocimiento del contexto

donde se desarrollará una solución, la recolección de los requerimientos que tendrá el

sistema mediante un mapa de contexto, cómo se realiza la elicitación de los requisitos y

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

qué resultados debe arrojar el proceso de documentación y estándares internacionales a

seguir.

2.2 Límites del contexto y del sistema

El punto de partida para todo proyecto de ​software ​y, como se hizo referencia en

la unidad 1 del curso, es la fase de los requerimientos de ​software,​ de este proceso

depende la efectividad del producto que se va a desarrollar y la manera más asertiva

para construirlo y que se ajuste a las necesidades de las personas quienes lo requieren.

Una importante tarea que fortalece la característica del ​design thinking​ es la empatía y

conocer muy bien el contexto que tendrá el ​software​, al igual que el identificar a todos

los actores que estarían involucrados en el proyecto, tanto beneficiarios como posibles

opositores del proyecto como la competencia (otras empresas en la misma naturaleza

del cliente) para evaluar que hacen bien para nosotros poder hacerlo mejor. De este

proceso es donde se generan los lineamientos viables para la recolección de los

requerimientos, se seleccionan las técnicas a utilizar, con qué autores se deberán

implementar estas técnicas y cuál será el resultado de la fase de requerimientos. En esta

unidad se elaborará un mapa de contexto para analizar un problema en un contexto real

y que la solución desencadene en el diseño y desarrollo de una aplicación móvil.

2.2.1 Mapa de contexto

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 El mapa de contexto tiene como objetivo definir los límites que tendrán el

proyecto y, de manera específica, la aplicación a diseñar. Hace parte de una de las

técnicas de ​design thinking e​ n las etapas de empatía y definición.

Con los miembros del equipo de desarrollo de ​software s​ e deberán definir los

aspectos que son importantes para definir el contexto, entre estos se podrían tener en

cuenta:

● tecnológicos,

● sociales,

● políticos,

● personales,

● funcionales,

● incertidumbre,

● o alguno que se considere importante según el problema.

La elaboración de este mapa se realiza de manera que todos los miembros del

equipo, por medio de fichas, fotos, imágenes, colores y demás elementos que

consideren importantes incluir para su elaboración, compartan sus apreciaciones frente a

los aspectos seleccionados y se van agrupando en un espacio de tablero, cartelera o

medio digital, esto está también a discreción de los miembros del equipo. Es importante

incluir aspectos de incertidumbre, que son todos los temas que son desconocidos por

todos o por un miembro del equipo, para determinar de qué manera se resuelven las

dudas, inquietudes o vacíos y con ello se comprende de una manera detallada el

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

contexto. Este mapa se elabora después de algunas reuniones con las personas quienes

requieren el proyecto o que están involucradas en la problemática a solucionar.

Para tener una idea adicional que recree el proceso se podría contemplar algo

como lo relacionado en la figura 2.

Figura 2. Mapa de contexto

2.3 Elicitación de requisitos

La mayor parte de los problemas de un ​software ​o una aplicación radican en la

recolección de los requerimientos de ​software ​y ajustar o corregir un error en etapas

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

posteriores a esta, puede generar costos altos en el proyecto de ​software.​ Las tareas de

elicitación demandan la construcción de documentos que permitan la formalización de

los requerimientos, ya que permite tener acuerdos por escrito entre los participantes del

proyecto, las necesidades o problemáticas y los desarrolladores del ​software.​

Los procesos de ingeniería son reconocidos a nivel universal y son

recomendados por el Institute of Electrical and Electronics Engineers reconocidos por

sus siglas IEEE y traducido al español como Instituto de Ingeniería Eléctrica y

Electrónica, quienes definen estándares para los procesos de la ingeniería y para la

elicitación de requisitos que hace parte de las labores de la ingeniería de ​software​. En

cada una de las acciones de la elicitación existen formatos recomendados por la IEEE

para la elaboración de estas etapas, que sirven de guía y orientación para el proceso y

que derivan en los documentos formales que se requieren en los procesos de

requerimientos de ​software​. Para este curso y el proceso de requerimientos utilizaremos

el estándar IEEE 830-1998. Se recomienda revisar toda la bibliografía de la unidad 2 del

curso para ver casos de uso y la aplicación de los formatos en algunos proyectos de

software​.

En la siguiente tabla realizada por Diéguez, Sepúlveda y Canullan (2010, p. 3)

se presentan algunas de las técnicas utilizadas durante la etapa de elicitación con su

respectiva descripción.

Tabla 1. Técnicas etapas de elicitación.

Técnicas Descripción

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 Permite al analista tomar conocimiento

del contexto problema y comprender los

Entrevistas objetivos de la solución deseada. A través

de esta, el equipo se aproxima al

problema de una forma natural.

Es una práctica grupal que se desarrolla

durante varios días e involucra a:

analistas, usuarios, administradores de

sistema, clientes, etc. Está basada en

Desarrollo de aplicaciones conjuntas - cuatro principios fundamentales:

JAD dinámicas de grupo, uso de medios

visuales para mejorar la comunicación,

llevar un proceso ordenado y una

filosofía de documentación del tipo

WYSIWYG.

Organizada para reuniones de grupo en

las que los participantes den a conocer

libremente sus ideas sobre el sistema, sin

Lluvia de ideas
ningún tipo de juicio sobre ellas. Además

provee una vista general de las

necesidades del sistema, pero no sirve

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 para establecer detalles específicos, por

lo cual es usualmente utilizada para las

primeras reuniones de trabajo.

Consiste en construir grafos en los cuales

los vértices representan conceptos y los

arcos representan posibles relaciones

Mapeo de conceptos entre estos conceptos. Estos grafos son

desarrollados con el usuario y sirven para

clarificar los conceptos relacionados con

el sistema en desarrollo.

Inicialmente desarrollado como técnica

para la definición de requerimientos,

algunos autores proponen usarlos como

técnica para capturarlos. Pueden mostrar

Casos de uso
los límites del sistema y quienes

intervienen con él (actores), así como las

funcionalidades que este debe entregar

(requerimientos funcionales).

Consiste en redactar un documento con

Encuestas o listas de chequeo preguntas cuyas respuestas sean cortas y

concretas o incluso cerradas por unas

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 cuantas opciones en el propio

cuestionario. Este será completado por el

grupo de personas entrevistadas o usado

para recoger información en forma

independiente de una entrevista.

Técnicas basadas en observación pueden

ser usadas para entender requerimientos

de tipo socio-organizacional. Llamada

Etnografía también simplemente “observación”, es

el analista quien se encuentra inmerso en

el ambiente organizacional donde el

sistema será usado.

Es utilizada en forma complementaria,

para obtener consenso respecto de la

terminología a ser usada en el proyecto

de desarrollo. Llamada también como

Glosario de términos “comparación de terminología”, intenta

resolver uno de los problemas que se

presentan durante la etapa de elicitación,

donde los usuarios y expertos fallan en

comprenderse mutuamente debido a

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 problemas en la terminología usada.

2.4 Documentación de requisitos

Lista de documentos a entregar en la unidad 2 con respectiva definición, se

recomienda empezar a diseñar los formatos con la información que consideren

pertinente para retomar de manera posterior.

Como se mencionó anteriormente, el estándar que se recomienda en este curso

en la etapa de documentación es el IEEE 830-1998, si considera que para su proyecto,

de manera particular, se ajusta otro estándar, se puede adecuar y en la entrega de la

actividad justificar el por qué la modificación del estándar. A continuación, se explican

siete documentos como parte de la documentación básica y mínima a entregar en un

proyecto de ​software​, depende de la naturaleza y magnitud del proyecto, esta

documentación crece en número de manera exponencial.

1. Dominio del problema: es el documento donde se define el problema,

por lo general se pueden tener como referencia la información brindada por los autores

y se amplía con una búsqueda bibliográfica, reuniones con expertos y demás acciones

que permitan el alto dominio y conocimiento del problema. De este documento se

obtiene la información del sistema.

2. Sesiones de elicitación: son las notas que se recopilan de las reuniones o

técnicas seleccionadas para la elicitación, de acá se obtiene el objetivo del proyecto de

software​, los requerimientos y los conflictos.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 3. Objetivos del sistema: en este documento se tienen los objetivos del

sistema, al igual que los riesgos que se presentan en el proyecto y cómo los indicadores

de calidad del proyecto.

4. Objetivos de la información: en este documento se obtienen los

requerimientos de información y las restricciones que deberá tener la información

dentro del sistema.

5. Requerimientos funcionales: en este documento están de manera

explícita los autores que intervienen en el proyecto, los casos de uso y los procesos que

desarrollará el ​software.​

6. Requerimientos no funcionales: de esta documentación se obtienen los

elementos de diseño y calidad del ​software.​

Es importante aclarar que existen muchos más documentos dentro de la fase de

documentación, para el ejercicio práctico del curso se consideraron mencionar estos

como parte de los más importantes, si requiere utilizar, diseñar o crear nuevos formatos.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 Referencias

Diéguez, M., Sepúlveda, S. & Canullan, D. (2010). ​Diseño de un documento para la

elicitación y especificación de requerimientos: caso práctico. [3] Workshop EIG

2010.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 Documento orientador

Unidad 3

Elevator pitch

Yerson Faber Torres Cubillos

yefatocu84@gmail.com

Cesión de derechos de autor a la Corporación Universitaria Iberoamericana

Las competencias comunicativas son importantes a la hora de conseguir

inversionistas para un proyecto, al igual que para vender una idea o poner en marcha un

proyecto de desarrollo de ​software.​ El presente documento orientador servirá de guía

para realizar un excelente ​elevator pitch​ y desarrollar excelentes competencias que

como ingeniero de ​software ​necesita para poder vender sus proyectos de desarrollo

tecnológico, para este caso particular una aplicación móvil que brinde la solución a una

problemática cercana o de personas de un contexto conocido, al finalizar este

documento se presentarán algunos buenos ejemplos de ​elevator pitch e​ ncontrados en la

web y algunos errores frecuentes que se cometen en estas experiencias.

Elevator pitch

Es una herramienta utilizada aproximadamente en 1980 y consiste en aprovechar

al máximo el tiempo con algún inversionista y la oportunidad de acercamiento que se

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

pueda tener, para dar a conocer un producto o proyecto y para nuestro caso particular un

proyecto de ​software​, la técnica hace referencia en el tiempo que se demore un trayecto

promedio en un elevador, poder presentar la información más importante de un proyecto

de ​software,​ generar intriga y poder atraer la atención de un posible inversionista, no

necesariamente se debe utilizar la técnica literalmente cuando la situación se presente en

un elevador, estas oportunidades pueden surgir en un congreso de tecnologías, en un

evento académico, en una feria tecnológica o cualquier espacio al que asistan

inversionistas, con interés en realizar inversiones en el sector tecnológico y conocido

actualmente como uno de los eslabones de la economía naranja.

La economía naranja hace referencia a que una idea para solucionar un problema o

una necesidad, se materialice en un producto o servicio y que esté directamente

involucrados derechos de autor, derechos de uso, de reproducción o patentes, productos

de la propiedad intelectual, es decir, que la mayoría de proyectos de ​software p​ or su

naturaleza innovadora y que termina en ofrecer servicios o un producto resultado de la

propiedad intelectual del equipo de ​software,​ se enmarca en este tipo de economía.

Características del ​elevator pitch

Es importante conocer cuáles son las características imperdibles que se deben

tener en cuenta en un ​elevator pitch,​ estas son:

- Ser muy claro.

- Generar interés.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 - No superar un minuto.

- Dar respuesta a cualquier inquietud.

- Aspectos diferenciales.

- Identificarse.

- Autoridad en la temática.

- Conocer hacia quién va dirigido.

- Identidad y marca personal.

- Solución que aporta.

Guión para la elaboración del ​elevator pitch

A continuación, se presenta, a manera de tabla, la cual se puede utilizar en la

realización del guión del​ elevator pitch​, se cuenta con un aproximado de segundos, la

información, el orden de la información y un ejemplo de cómo se podría realizar un

elevator pitch.​ Se invita, a manera de práctica, a que grabe un mensaje de audio donde

se lea solo la información que se encuentra entre comillas para ver la coincidencia en el

tiempo de duración del ​elevator pitch.​ Al finalizar la tabla, se presentará el ​elevator

pitch​ de manera completa, para que realice el ejercicio práctico.

Tabla 2. Guión del elevator pitch

Tiempo (en Información

segundos)

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

2 Saludo, se recomienda ser formal con un “buenos días”, “buenas

tardes”, “buenas noches”.

7 Presentación: “Soy Yerson Faber Torres Cubillos, Ingeniero de

Software y tengo una compañía de desarrollo de soluciones

tecnológicas”

6 Público hacia quién está dirigida la solución: “Trabajo ayudando a

personas que tienen problemas de sobrepeso a mejorar su calidad de

vida y de salud”

6 Experiencia en el área: “Para ello cuento con un equipo de

nutricionistas, deportólogos, endocrinólogos y entrenadores

deportivos”

4 En qué se materializa la solución: “Quienes se encargan de realizar

un diagnóstico personalizado”

3 Se presenta el ​software:​ “Por medio de una aplicación móvil”

7 Forma de contacto: “Si quiere conocer de manera amplia sobre el

proyecto, mantengamos contacto por Instagram, mi usuario es

IngSoftware2020”

35 Total del tiempo del ​elevator pitch (​ 35 segundos)

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

Texto del​ elevator pitch p​ ara ejercicio práctico:

Buenos días, soy Yerson Faber Torres Cubillos, Ingeniero de ​Software ​y tengo una

compañía de desarrollo de soluciones tecnológicas. Trabajo ayudando a personas que

tienen problemas de sobrepeso a mejorar su calidad de vida y de salud, para ello cuento

con un equipo de nutricionistas, deportólogos, endocrinólogos y entrenadores

deportivos quienes se encargan de realizar un diagnóstico personalizado, por medio de

una aplicación móvil. Si quiere conocer de manera amplia sobre el proyecto,

mantengamos contacto por Instagram, mi usuario es IngSoftware2020.

Buenos ejemplos

Para conocer tres buenos ejemplos de ​elevator pitch,​ para tres diferentes nichos de

mercado, puede visitar la página de la escuela de negocios ESERP de Madrid, España,

al igual que se presentan recomendaciones adicionales para la elaboración del ​elevator

pitch​.

Es importante reconocer que el ​elevator pitch ​puede cambiar de esencia

dependiendo hacia quién va dirigido, no necesariamente el mismo discurso y redactado

de la misma manera generará el mismo impacto con diferentes inversionistas, es por eso

que la labor de analizar y conocer el perfil del inversionista para conocer los aspectos

más importantes que contempla a la hora de tomar la decisión en un negocio.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

Errores frecuentes

Gracias a que no es un proceso con pocos años utilizado como estrategia de

negocio y por la gran efectividad para emprendedores quienes han multiplicado en poco

tiempo las ganancias de una compañía, gracias a una buena herramienta que satisface

una necesidad, se tienen algunas características comunes que permiten identificar los

errores frecuentes de los ​elevator pitch.​ A continuación se presentan algunos.

1. Ir directo a la solución que ofrece el ​software o​ la aplicación sin contextualizar

el problema y por qué es importante realizar una acción pronta para dar solución al

problema, cuando no se demuestra que el producto es una necesidad para el mercado, un

inversionista pierde el interés debido a que no ve una rápida o acertada rentabilidad en

su inversión, ciertamente lo que busca el inversor por muy clara que sea la necesidad, es

el porcentaje de recuperación de la inversión, entre menos corto tiempo se recupera

mejor y el porcentaje de beneficio que va a obtener a un corto plazo.

2. Dar datos que se puedan cuestionar y que provengan de fuentes poco creíbles,

cuando se trate de datos hay que ir a la fuente oficial, con mayor conocimiento del tema,

con buena reputación por la transparencia de sus resultados y números y de donde esas

cifras oficiales apoyan la necesidad y en ocasiones la urgencia de intervenir en un

problema específico.

3. No tener un análisis del mercado, si no conocemos la competencia o las

diferentes alternativas que se han trabajado en la problemática tendemos a parecer

incrédulos y a dejar un amplio espacio donde se demuestre que otra compañía, producto

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

o desarrollo, puede tener mejores soluciones, es por ello que se deben conocer de

manera amplia las diferentes alternativas que existen para el mismo problema y

volviendo a reforzar el error dos, se debe remitir a cifras oficiales y de acceso

comprobable.

4. Demostrar poca experiencia, en ocasiones, la falta de herramientas de

comunicación dan una idea equivocada sobre el conocimiento que se tiene sobre la

oportunidad de negocio que se presenta, el no demostrar seguridad en la temática puede

terminar en la falsa apariencia de ser novato y esto hace que un inversor considere que

sería un alto riesgo invertir en un proyecto liderado por alguien con poca experiencia.

Cuando de inversiones se trata, se debe brindar seguridad de que la inversión está a

salvo y que tendrá un retorno asegurado.

5. No tener claros lo objetivos del proyecto, cuando no se tiene claridad de los

objetivos del proyecto, del alcance y del potencial que tiene el producto y para nuestro

caso particular, la aplicación, es como el famoso dicho “​Cuando no sabemos para

dónde vamos, cualquier bus nos sirve​” es tener un barco a la deriva y con recursos que

debemos asegurar un retorno y entre más pronto, mejor, esto demuestra profesionalismo

y crea confianza para nuevas posibles inversiones.

6. No disfrutar lo que se hace, cuando no se siente pasión por el proyecto, cuando

no mueva fibras, es difícil asegurar que se defenderá con capa y espada la propuesta y

que se encontrarán mil una soluciones a mil problemas que se puedan presentar porque

el objetivo es dar solución al problema, obtener mayor cantidad de población impactada

y beneficiada y tener una rentabilidad asegurada.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

 7. Demostrar necesidad, si se demuestra que se requiere mucho de la inversión

puede generar en el inversor desconfianza de querer robar su patrimonio o querer

obtener un beneficio personal, siempre se puede pensar que si no se obtiene la inversión

con un posible inversionista no significa que todo está acabado, pueden haber otras

oportunidades, con mejores condiciones con otro inversionista, el cual hay que buscarlo

sin demostrar la necesidad. Una manera de que esto se logre es teniendo la aplicación

funcionando, con buenos resultados, proveedores reales y personas interesadas pero que

no satisfacen las expectativas del proyecto.

8. Dar muchos datos sin tener claro el norte, cuando damos más información de la

que se requiere, no somos ordenados en la información que brindamos y no conectamos

la información con el objetivo tendemos a demostrar que somos dispersos y, al mismo

tiempo, que no podemos concentrarnos en una única cosa, esto hace parte de demostrar

que podemos tener todo bajo control, que las habilidades para trabajar bajo presión

están en nuestro alcance y que hay precisión en los datos tanto en tiempo como en la

calidad de los mismos.

9. Pretender ser quien no eres, vender la idea equivocada de quién realmente eres

con intención de encajar o generar confianza, tiene un resultado inverso, cuando eres tú

mismo en todo momento, generas credibilidad y el inversionista puede resaltar o ver

virtudes, incluso, en lo que usted considera desventajas.

10. Por último, y no por ser menos importante, perder el interés, cuando no se

logra conectar y captar el interés del inversionista, la posibilidad de esa cita para

ampliar detalles del inversionista, escuchar un ​feedback ​o retroalimentación del mismo

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN

proveniente de alguien con tanta experiencia sería nula, hay que generar interés desde la

primera oportunidad.

Recuerde que este documento es solamente una orientación para fortalecer

competencias de comunicación a la hora de buscar inversión, vender una idea,

convencer a alguien de que le escuche y pueda abrirse la oportunidad de generar

rentabilidades que desencadenan en una excelente calidad de vida.

La cuarta revolución industrial es ahora y en el desarrollo de ​software,​

aplicaciones y estar adelante de las necesidades de las personas es donde radica el éxito

y el prepararnos para el futuro, hay que hacer planes de vida a largo plazo y, así mismo

con las empresas, tener visiones a futuro y aprender de los grandes, por ejemplo, Apple

antes de presentar los últimos dispositivos cada año, ya conoce las características y

necesidades de sus usuarios en los próximos cinco, diez, quince y hasta veinte años,

gracias a los datos, se logran hacer predicciones como la velocidad de navegación que

podremos tener en cinco años, la capacidad de almacenamiento que requerimos en la

nube, la cantidad de datos que demandamos cada mes y, en fin, definir y trazar el

camino y los desarrollos que son útiles para la humanidad y que permitirán continuar en

esta evolución acelerada desde la creación del Internet.

P.J. No. 0428 del 28 de Enero 1982 - MEN I VIGILADA MINEDUCACIÓN