Mapa de historiadores

Sobre nuestro proyecto

JISELA ANDREA TORRES

CESAR OVIEDO

Somos un par de estudiantes de ultimo semestre de Ingeniería de Sistemas de la Universidad Santiago de Cali en Colombia, con grandes habilidades para el levantamiento y análisis de requerimientos de software, contamos con mas de 6 años de experiencia en el área en sectores como salud, financieros, productivo, entre otros.

Nuestro proyecto de grado se trata de la creación de una iniciativa empresarial en consultoría y asesoría en ingeniería de requerimientos, con este proyecto se pretende apoyar a las empresas desarrolladoras de software en la etapa de requerimientos.

El objetivo de nuestro proyecto es proponer un modelo de negocio que permita la creación de una iniciativa empresarial dedicada a la consultoría y asesoría de ingeniería de requerimientos que ayude a disminuir la poca eficiencia de los sistemas de información debido a las fallas presentadas en el análisis del negocio.

OBJETIVOS ESPECÍFICOS

* Realizar una segmentación de clientes a los que estarán dirigidos los servicios de la empresa.
* Plantear las métricas que permitirán una evaluación de la propuesta de valor y servicio mínimo viable.
* Ejecutar las capacitaciones básicas que exige la metodología para validar su efectividad.
* Proponer la organización que soporte la funcionalidad de la iniciativa empresarial incluyendo los costos requeridos diseñándolos para que respondan a la propuesta de valor y el servicio mínimo viable

Estado del arte ingenieria de requerimientos

En la siguiente tabla se realiza una análisis comparativo de las mejores prácticas en ingeniería de requerimientos:

Aunque el concepto de requerimientos no ha cambiado, los modelos utilizados para realizar ingeniería de requerimientos han ido evolucionando; en los años 70, una época en que el desarrollo de software se opacó por los costos del hardware se utilizó el modelo secuencial o en cascada nombrado así debido a la cascada de una fase a otra (Sommerville, 2005), en este modelo la realización la documentación y la definición de requisitos se realizan en la etapa inicial del proceso, esto quiere decir que los requerimientos ya no serán modificados en ninguna de las próximas etapas.

En los años 90, se comienza a utilizar el modelo de desarrollo iterativo, este modelo contrario al modelo en cascada, permite identificar en fases más tempranas cambios en los requerimientos en función de las necesidades de los stakeholders, este método se enfoca en construir software en varias iteraciones, estas iteraciones son pequeños proyectos, el objetivo es entregar una parte del sistema completo, probado y estable.
En 2001, Kent Beck y otros 16 notables desarrolladores (grupo conocido como la “Alianza Ágil”) firmaron el manifiesto del desarrollo ágil del software (Beck, y otros, 2001), en el que se establecía lo siguiente:
“Estamos descubriendo formas mejores de desarrollar software, por medio de hacerlo y de dar ayuda a otros para que lo que hagan. Ese trabajo nos ha hecho valorar:
* Los individuos y sus interacciones sobre los procesos valorar:
* El software que funciona, más que la documentación exhaustiva
* La colaboración con el cliente, y no tanto la negociación del contrato
* Responder al cambio, mejor que apegarse a un plan.
Según (Pressman, 2010) los métodos agiles combinan una filosofía con un conjunto de lineamientos para el desarrollo. La filosofía pone el énfasis en: la satisfacción del cliente y en la entrega rápida de software incremental, los equipos pequeños y muy motivados para efectuar el proyecto, los métodos informales, los productos del trabajo con mínima ingeniería de software y la sencillez general en el desarrollo.
El método ágil más adoptado ha sido XP, cuya mayor premisa técnica es la incorporación del cliente en todo el desarrollo, incrementos cortos de desarrollo, diseños simples, programación por pares y la integración continua, estos disminuyen los costos de cambio frente a los tiempos, sin embargo, los datos reportado hasta el momento indican que esta disminución no tiene lugar para proyectos de mayor envergadura. Un buen ejemplo fue proporcionado por un sistema de dirección de una fábrica de arrendamiento, presentado en CISE 2002,
cuando el tamaño del proyecto alcanzó más de 1000 historias, 500.000 líneas de código, y 50 personas, con algunos cambios donde se tocaron más de 100 objetos, el coste del cambio aumentó inevitablemente. Esto requirió añadir al proyecto planes un poco más explícitos, controles y representaciones de arquitectura de alto nivel (Boehm, 2006).

Éxito en proyectos de desarrollo de software

Basado en los resultados de Verner, J.M. Podemos afirmar que la definición de requerimientos es uno de los factores clave para que un proyecto de software sea exitoso, es decir, si se tienen requerimientos completos y correctos al inicio del proyecto, con alcances bien definidos de todas las partes la probabilidad de fracasar es muy poca. (Verner, 2005) Sus resultados además ratifican que los requerimientos continúan siendo un grave problema para el correcto desarrollo de sistemas de información y una de las principales causas de los fracasos de muchos proyectos.

Para 2015, el Chaos Report informa de una tasa de éxito en los proyectos del 29% (proyectos en tiempo, presupuesto y cumpliendo con requisitos y especificaciones). Indica también que el 52% concluye, pero con retrasos o sobrecostos o cumpliendo parcialmente con los requerimientos y las especificaciones; y que un 19% fracasa completamente (son cancelados o entregan productos pero estos no son usados), este estudio se realiza a aproximadamente 50.000 proyecto alrededor del mundo (Lynch, 2015)

Si bien el porcentaje de éxito en los proyectos de desarrollo ha ido mejorando al transcurrir de los años, la taza de error aún sigue siendo muy alta, como podemos evidenciar en el siguiente gráfico:

Tasa de éxito en proyectos de desarrollo

Fuente: (Lynch, 2015)

¿Porqué una StartUp?

Las startup estan diseñadas para crear nuevos productos y servicios en unas condiciones de extrema incertidumbre, estas pueden funcionar con empresas de cualquier tamaño, incluso en compañías muy grandes de cualquier sector o actividad; estas no solo existen para producir cosas, ganar dinero o atender a los consumidores, existen para aprender cómo crear negocios sostenibles, su actividad principal es convertir ideas en productos o servicios, medir como responden los consumidores y aprender a pivotar o perseverar (Ries, 2011).

Estamos en una época de oportunidad sin precedentes para la innovación con la llegada del internet, la computación en la nube, el software de código abierto, entre otros, sin embargo, las probalidades de construir productos o servicios de éxito no han mejorado mucho, 9 de cada 10 empresas fallan y de las que tienen éxito más de dos tercios cambian sus planes drásticamente en el camino, el Lean Canvas se enfoca en encontrar un plan inicial (Plan A) que funcione antes de quedarse sin recursos, la ejecución de este es un proceso sistemático para la iteración del Plan A a un plan que funcione (Maurya, 2012).

Las Pymes, conjuntamente con las microempresas, representan al menos el 90 por ciento del parque empresarial nacional y generan el 73 por ciento del empleo y el 53 por ciento de la producción bruta de los sectores industrial, comercial y de servicios (Rodriguez, 2003).

¿Que es la ingeniería de requerimientos?

Existen distintas definiciones de Ingeniería de Requerimientos (IR), para nuestro caso hemos tomado las siguientes:

Para el Instituto de Ingenieros en Electricidad y Electrónica (IEEE) la ingeniería de requerimientos se define como:
La ciencia y disciplina relacionada con el análisis y documentación de requerimientos, incluyendo el análisis de necesidades, el análisis de requerimientos y la especificación de requerimientos. También proporciona los mecanismos adecuados para facilitar las actividades de análisis, documentación y verificación de estos.

Para (Nuseibeh, 2000) la (IR) es la rama de la ingeniería de software que descubre los objetivos del mundo real de un sistema, por medio de la identificación de los stakeholders y sus necesidades, y documentándolos de forma adecuada para el análisis, la comunicación y la posterior implementación. También se determina por las relaciones entre la función del sistema y las restricciones que este tiene, con el fin de precisar especificaciones del comportamiento del software a medida que pasa el tiempo y que llegan nuevas versiones.

Para (Borrell, 2006) La Ingeniería de Requerimientos (IR) es definida como: "La disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema”.

La (IR) toma gran importancia en los proyectos de desarrollo de software debido a que se obtienen beneficios como: (Macaulay, 1996)

* Permitir la gestión de las necesidades del proyecto en forma estructurada: Cada actividad de la Ingeniería de Requerimientos consiste de una serie de pasos organizados y bien definidos.
* Mejorar la capacidad de predecir cronogramas de proyectos, así como sus resultados: La Ingeniería de Requerimientos proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.
* Disminuir los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.
* Mejorar la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
* Mejorar la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.
* Evitar rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Sus actividades principales son:

* Elicitación
* Documentación
* Validación y negociación