RESUMEN

Desde la aparición de las metodologías de desarrollo de software, los procesos de desarrollo tienen como base la metodología padre: “El desarrollo en cascada”(Ian Sommerville, 1997). Actualmente se presentan diversas metodologías de desarrollo de Software, las metodologías ágiles, ahora bien ¿Por qué la vigencia actual de una forma de trabajo que aparece en el año 1990?, los resultados a corto plazo y el alcance de los objetivos propuestos(Pérez-Virgen, Salamando-Mejía, & Valencia-Ayala, 2013a). Según la tesis el objetivo de Scrum(Qumer & Henderson-Sellers, 2008) es logrado mediante la optimización del proceso de desarrollo mediante la identificación de las tareas, la gestión del tiempo más eficaz. Se establece como la Metodología en Cascada como la base, como el padre de todas las metodologías. El problema que se identifica en la presente investigación es la replanificación de los requerimientos en la fase de Planificación de desarrollo de software, como consecuencia se produce un alto índice de replanificaciones. La crítica que se realiza es la falta de artefactos que garanticen la viabilidad del proyecto desde la fase de Planificación. Como solución en la presente investigación se presentan filtros, entregables en cada etapa de Planificación, de tal manera que se garanticen la calidad de reuniones, entendimiento, checklists. Por último, la demostración se realizará al término de todo el proyecto, en la fase de cierre, evaluando y analizando los controles de cambios, el tiempo y la puesta en marcha de la postproducción del proyecto. .

Palabras Clave: Scrum, software, planificación, desarrollo.

ABSTRACTSince the emergence of software development methodologies, development processes are based on the parent methodology: “Cascade development”(Ian Sommerville, 1997). Currently there are several software development methodologies, agile methodologies, now why the current validity of a form of work that appears in the year 1990? The short-term results and the scope of the proposed objectives(Pérez-Virgen et al., 2013a). According to the thesis the goal of Scrum is achieved by optimizing the development process by identifying the tasks, the most e ffective time management. It is established as Cascade Methodology as the basis, as the father of all methodologies. The problem that is identified in this research is the replanning of the requirements in the software development planning phase, as a consequence there is a high rate of replanning. The criticism that is made is the lack of artifacts that guarantee the viability of the project from the Planning phase. As a solution in the present investigation, filters are presented, deliverables in each stage of Planning, in such a way as to guarantee the quality of meetings, understanding, checklists. Finally, the demonstration will be carried out at the end of the whole project, in the closing phase, evaluating and analyzing the change controls, the time and the start-up of the post-production of the project

Since the emergence of software development methodologies, development processes are based on the parent methodology: “Cascade development”(Ian Sommerville, 1997). Currently there are several software development methodologies, agile methodologies, now why the current validity of a form of work that appears in the year 1990? The short-term results and the scope of the proposed objectives(Pérez-Virgen et al., 2013a). According to the thesis the goal of Scrum is achieved by optimizing the development process by identifying the tasks, the most effective time management. It is established as Cascade Methodology as the basis, as the father of all methodologies. The problem that is identified in this research is the replanning of the requirements in the software development planning phase, as a consequence there is a high rate of replanning. The criticism that is made is the lack of artifacts that guarantee the viability of the project from the Planning phase. As a solution in the present investigation, filters are presented, deliverables in each stage of Planning, in such a way as to guarantee the quality of meetings, understanding, checklists. Finally, the demonstration will be carried out at the end of the whole project, in the closing phase, evaluating and analyzing the change controls, the time and the start-up of the post-production of the project.

Keywords: Standards, asparagus, quality, safety.

INTRODUCCIÓN

En el mundo, desde la aparición de las herramientas para realizar desarrollos de software, se presentan inconvenientes que provocan retraso sistemático en los plazos establecidos, ocasionando de esa forma que se exceda en el presupuesto, se entregue con una alta tasa de errores y su utilidad sea inferior a la esperada(Arruzazabala, Dapozo, & Thomas, 2012). En cuanto magnitud esta problemática es atribuible a defectos en los procesos utilizados para recoger, documentar, acordar y modificar los requisitos del sistema(Alarcon & Sandoval, 2011).

Una gran variedad de investigaciones coincide en que la mayor parte de los errores de un sistema se originan al comienzo del ciclo de vida, y que entre el 40% y 60% de los defectos en un proyecto de software están relacionados con los requerimientos del sistema(Sánchez & Velthuis, 2012).

Según Franck Agger(Aggeri & Labatut, 2010) en su investigación demuestra la importancia de la gestión de requerimientos dentro del proceso de desarrollo de software y se verifica la actividad de la revisión de los requerimientos del software como un factor clave dentro del ciclo de vida.

Una de las más preponderantes investigaciones realizadas a múltiples organizaciones en el mundo, que mide los distintos factores que interfieren en el desarrollo de soluciones, que es elaborada por “The Standish Group”(The Standish Group, 1995), identificó que la gestión de requerimientos sigue siendo la etapa de mayor problema para la mayoría de las organizaciones y que las prácticas asociadas alos requisitos son deficientes en el 74% de todas las empresas(Borrell, 2006).

Dicha investigación ha identificado que la causa principal de la baja calidad, alto coste y problemas de entrega del producto sigue siendo por factores asociados a la gestión de requerimientos y entre esos factores se encuentra: La deficiencia en entender las necesidades del cliente, una incompleta especificación de los requerimientos y la falta de una correcta gestión de cambios de los mismos.

Ahora bien, ya citada la importancia de la gestión de requerimientos en el desarrollo de una solución de software, se verifica un modelo para la mejora del proceso de gestión de Requerimientos, que ha sido probada en las organizaciones(6), es utilizar modelos de buenas prácti- cas, tales como, CMMI-DEV, ISO-15504(2003; 2004; 2008; 2012), ISO-12207(2008). Se presentan demostraciones de casos de éxito en donde la implementación y el uso de estos modelos ha permitido disminuir los problemas de entrega y calidad de un producto software(Peruana, 2004).

Prosiguiendo con la situación en Latinoamérica, en una investigación realizada por Borrell Caridad Racero, en Medellín, Colombia, se presenta la necesidad y la problemática idéntica a Europa. La omisión de pasos importantes en el ciclo de vida de desarrollo del software, entre tantas, la correcta definición de requerimientos. Lo que se pretende con la investigación es cubrir los requi sitos de la fase de especificación y sus principales actividades durante el proceso de desarrollo de software(Borrell, 2006).

En el Perú, según la Norma Técnica Peruana(Peruana, 2004), existe una proliferación de marcos de trabajo referenciales para el desarrollo de software.Para la gestión de requerimientos menciona principalmente el proceso de Adquisición donde conviene que los requisitos del sistema incluyan requisitos de negocio, organizativos, de usuario,así como de seguridad física y de acceso y otros requisitos críticos.

La Norma Técnica peruana proporciona la etapa de Adquisición y sus fases para la gestión de requerimientos: Inicio, Preparación de la solicitud de propuestas, Preparación y actualización del contrato, Seguimiento del proveedor, aceptación y finalización(9). De acuerdo con la Oficina Nacional de Gobierno Electrónico e Informática brinda la puesta en marcha de la Norma Técnica Peruana “NTP- ISO 12207:2008 Tecnología de Información, Proceso del ciclo de vida del desarrollo de software, 1era edición” para que se aplique(Irrazabal, Vásquez, Díaz, & Garzás, 2011)

MÉTODOS Y MATERIALES

A. Metodología en Cascada:

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior(Ian Sommerville, 1997).

La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985 (Letelier, Canós, Sánchez, & Penadés, 2003).

Un ejemplo de una metodología de desarrollo en cascada es:

- Análisis de requisitos.

- Diseño del Sistema.

- Diseño del Programa.

- Codificación.

- Pruebas.

- Verificación.

- Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

La presente investigación enfoca las dos primeras fases; Análisis de requisitos y diseño del sistema. Las mismas que engloban la etapa de Planificación. En dicha etapa se presente el volcamiento de la información, reuniones de trabajo, uso de cronograma de actividades, checklists.

B. Metodologías de desarrollo Ágiles, Scrum:

En la actualidad y en los últimos años varias iniciativas internacionales orientadas específicamente para armar pequeñas y medianas empresas, los procesos y los métodos ágiles han sido identificados.

Del mismo modo, diferentes estudios han identificado la correlación entre las metodologías ági- les y modelos de procesos de desarrollo de software como CMMI-DEV e ISO / IEC 12207, pero los estudios relacionados con la norma ISO / IEC 12207(ISO, IEC, & IEEE, 2008) se basan en la versión de 1995(Irrazabal et al., 2011). Por lo tanto, este trabajo se centra en la relación entre las prácticas ágiles, especialmente scrum(Cockburn & Highsmith, 2001), y un subconjunto de pro- ceso de la versión 2008 de la norma ISO / IEC 12207(Irrazabal et al., 2011).

SCRUM(Pernstål, Gorschek, Feldt, & Florén, 2015) es uno de los métodos más populares y ágiles es un proceso iterativo incrementales. Estas dos características hacen dividir el proyecto en fases o iteraciones y la entrega incremental del proyecto.

Las relaciones indicadas en el presente trabajo se obtienen a través de trabajos previos y experiencia en consultoría a 25 empresas que cumplen con los resultados estándar de aplicación de metodologías ágiles(Irrazabal et al., 2011). El objetivo principal del estudio es conocer el grado en que las prácticas ágiles ayudan en la realización de las prácticas indicadas en este modelo de proceso(Irrazabal et al., 2011).

La metodología scrum es uno de los métodos más usados en el mundo, particularmente en el Perú, su llegada ha sido tardía, existen diversos esfuerzos para establecer buenas prácticas en las organizaciones, pero el tema cultural es una gran barrera que distorsiona el objetivo principal del marco de trabajo, que es el de brindar valor en etapas tempranas.

Asimismo existen esfuerzos separados por países para establecer los pilares del marco en las organizaciones: grupos de trabajo, comunidades.

C.Norma Técnica Peruana ISO 12207: 2008:

Para la gestión de requerimientos menciona principalmente el proceso de Adquisición donde conviene que los requisitos del sistema incluyan requisitos de negocio, organizativos, de usuario, así como de seguridad física y de acceso y otros requisitos críticos.

La Norma Técnica peruana proporciona la etapa de Adquisición y sus fases para la gestión de requerimientos: Inicio, Preparación de la solicitud de propuestas, Preparación y actualización del contrato, Seguimiento del proveedor, aceptación y finalización(Arruzazabala et al., 2012).

De acuerdo con la Oficina Nacional de Gobierno Electrónico e Informática brinda la puesta en marcha de la Norma Técnica Peruana “NTP- ISO 12207:2008 Tecnología de Información, Proceso del ciclo de vida del desarrollo de software, 1era edición” para que se aplique(Chaves, 2011).

RESULTADOS

El artefacto a presentar va permitir analizar y diagnosticar el rendimiento productivo de la metodología propuesta para el manejo de requerimientos de gran complejidad.

La metodología scrum(Irrazabal et al., 2011) cuenta con una estructura secuencial y repetitiva que se caracteriza por presentar ciclos reducidos, cortos en alcance, con el fin de concretar entre- gables visibles para el usuario final, de tal manera que la percepción del trabajo sea constante y la validación de los entregables se realicen al final de cada ciclo, con la evaluación de las actividades realizadas, con aprobaciones de los entregables y las metas establecidas.

Cada ciclo de trabajo se llama Sprint, donde cada sprint se puede comparar como un pequeño entregable, el cual posee alcance, estimación, tiempos

Según se observa en la Figura N° 1, cada sprint es un ciclo de trabajo reducido, que presenta entradas (inputs), salidas (outputs) y fases internas de análisis y desarrollo. En dicha figura se represen- tan como 5 fases por cada sprint.

Según la Figura N° 1, expuesta en la introducción, existe una correlación del marco metodológico de Scrum(Irrazabal et al., 2011) con la metodología de desarrollo Cascada.

Figura N°1: Diagrama de la Metodología scrum desplegado bajo la metodología en cascada

Fuente: Elaboración propia.

Si realizamos la función de una lupa imaginaria podemos expandir cada uno de los sprints. De acuerdo a la Figura N° 2, Se observa que a modo de ejemplo se toman 3 entradas: Entrada A, Entrada B y Entrada C, y luego se presentan 3 Salidas: Salida A, Salida B y Salida C. En el ínterin se presentan 5 fases de actividad que son: Requerimientos, diseño, codificación, pruebas de aceptación. Cada una comprende de manera singular a las etapas propias de la metodología de desarrollo de software en Cascada: Desarrollo de Requisitos, diseño de solución, desarrollo y pruebas.

Figura N°2: Metodología Scrum Híbrida – Cascada

Entonces, las dos primeras etapas que son Requerimientos y Diseño son las dos únicas fases que para esta investigación comprenden en cuanto al alcance. En vista que en ellas se presenta el estable- cimiento de los requerimientos y el diseño de la solución

Para la etapa de Requerimientos se cuenta con:

• programación de reuniones
• Cuestionario desarrollo de requisitos
• Checklist Aseg-Doc – Alcance
• Reporte de hallazgos Aseg-Doc – Alcance
• Seguimiento y cierre de hallazgos Aseg-Doc- Alcance
• Seguimiento de pendientes