Metodología de desarrollo de software dirigida a equipos de trabajo reducidos para su aplicación en los proyectos integradores y tesis en Uniandes Extensión Ibarra

(1)

UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES

“UNIANDES – IBARRA”

FACULTAD DE SISTEMAS MERCANTILES

CARRERA DE SISTEMAS

TESIS DE GRADO PREVIA A LA OBTENCIÓN DEL TÍTULO DE

INGENIERO EN SISTEMAS E INFORMÁTICA

TEMA: METODOLOGÍA DE DESARROLLO DE SOFTWARE

DIRIGIDA A EQUIPOS DE TRABAJO REDUCIDOS PARA SU

APLICACIÓN EN LOS PROYECTOS INTEGRADORES Y TESIS EN

UNIANDES EXTENSIÓN IBARRA.

AUTOR:

VARGAS ALMENDÁRIZ LUIS MIGUEL

ASESOR:

ING. CHECA MARCO.

(2)

(3)

(4)

DEDICATORIA

El presente trabajo lo dedico a nuestro padre Dios por brindarme la vida y la oportunidad de llegar a la culminación de una meta en mi vida, a mi madre, mis hermanos, sobrinos y toda mi familia quienes me han brindado el apoyo y el impulso para llegar a la culminación de mis estudios y obtener una carrera, con la cual creceré como persona y profesional para el engrandecimiento de mi país, también se lo dedico a mis abuelitos que aunque ya no se encuentran entre nosotros, desde el cielo me han bendecido.

(5)

AGRADECIMIENTO

Mi agradecimiento a la Universidad Regional Autónoma de los Andes UNIANDES y a los señores catedráticos por sus enseñanzas y experiencias impartidas en las aulas de estudio.

(6)

ÍNDICE GENERAL

INTRODUCCIÓN……… 1

Antecedentes de la investigación ……… .. 1

Planteamiento del problema ……… .. 1

Formulación del problema………. 2

Delimitación del problema..………. .. 2

Objeto de investigación y campo de acción……….. . 2

Identificación de la línea de investigación..……… .. 2

Objetivo general y específicos..……… . 2

Idea a defender.……… .. 2

Justificación del tema..………. .. 2

Explicación de la metodología investigativa………. 3

Resumen de la estructura de la tesis……….. 3

Novedad, aporte teórico y significación práctica………. .. 3

CAPÍTULO I. MARCO TEÓRICO………... 4

1.1. Origen y evolución del objeto de investigación. ... 4

1.2. Análisis de las distintas posiciones teóricas sobre el objeto de investigación... 5

1.3. Valoración crítica de los conceptos principales de las distintas posiciones teóricas sobre el objeto de investigacion. ... 6

1.3.1. Ingeniería de software…..……….. .. 6

1.3.1.1. Conceptos básicos ... 6

1.3.1.2. Análisis y gestión del riesgo ... 7

1.3.1.3. Principios del análisis de riesgos ... 9

1.3.1.4. Principios de diseño de riesgos ... 9

1.3.2. Metodología RUP...10

1.3.2.2. Ciclo de vida ... 10

1.3.2.3. Fase de la metodología ... 10

1.3.2.4. Artefactos ... 11

(7)

1.3.3.2. Fases de la metodología ... 12

1.3.3.3. Roles de la metodología ... 13

1.3.4. Metodología SCRUM..………...14

1.3.4.2. Etapas de la metodología ... 14

1.3.4.3. Responsabilidades de la metodología ... 15

1.3.5. Modelo en cascada….……… 17

1.3.5.1. Conceptos y características ... 17

1.3.5.2. Fases del modelo ... 18

1.3.5.3. Ventajas y desventajas ... 19

1.3.6. Modelo espiral….………...19

1.3.6.2. Características ... 20

1.3.6.3. Fases del modelo ... 20

1.3.6.4. Ventajas y desventajas ... 21

1.3.7. Modelo ágil de desarrollo de software…...……… 21

1.3.7.1. Manifiesto por el desarrollo ágil de software. ... 21

1.3.7.2. Principios del manifiesto ágil. ... 22

1.3.7.3. Prácticas de agilidad. ... 23

1.4.Conclusiones parciales del capítulo. ... 24

CAPÍTULO II. MARCO METODOLÓGICO Y PLANTEAMIENTO DE LA PROPUESTA. ... 25

2.1. Caracterización del sector, rama, empresa, contexto institucional o problema seleccionado para la investigación. ... 25

2.2. Descripción del procedimiento metodológico para el desarrollo de la investigación. ... 25

2.2.1. Metodología……….………...25

2.2.2. Población y muestra…..………. 26

2.2.3. Técnicas y herramientas………...……….. 26

2.2.4. Análisis de encuestas y entrevistas…...………..27

(8)

2.2.4.2. Entrevista al coordinador. ... 32

2.3.Propuesta del investigador. ... 33

CAPÍTULO III. VALIDACIÓN Y/O EVALUACIÓN DE RESULTADOS DE SU APLICACIÓN. ... 35

3.1.Procedimiento de la aplicación de los resultados de la investigación. ... 35

3.1.1. Antecedentes en Uniandes Ibarra………... 35

3.1.2. Diagnóstico en Uniandes Ibarra...……….. 35

3.1.3. Análisis del diagnóstico en Uniandes Ibarra……….. 36

3.1.4. Propuesta para Uniandes Ibarra…..………....37

3.1.5. Desarrollo de propuesta para Uniandes Ibarra…..………. 37

3.1.5.1. Determinación de requerimientos. ... 37

3.1.5.2. Evaluación de requerimientos. ... 37

3.1.5.3. Metodología orientada a desarrollo con equipos reducidos (MODER)... 38

3.2.Análisis de los resultados finales de la investigación. ... 67

3.2.1. Evaluación de moder..……….... 67

3.2.1.1. Primera evaluación ... 67

3.2.1.2. Segunda evaluación ... 71

CONCLUSIONES GENERALES ... 74

RECOMENDACIONES ... 75 BIBLIOGRAFÍA

(9)

ÍNDICE DE TABLAS

Tabla 1.Artefactos de RUP. Fuente. Autor ... 12

Tabla 2. Herramientas y población. Fuente. Autor ... 26

Tabla 3. Resultados de encuesta pregunta 1. Fuente. Autor ... 27

Tabla 4.Tabulación encuesta pregunta 2. Fuente. Autor ... 27

Tabla 12.Tabulación encuesta pregunta 10. Fuente Autor ... 31

Tabla 13.Parametros de valoración de metodologías. Fuente. Autor ... 68

Tabla 14. Orientación tradicional vs orientación ágil. Fuente. Autor ... 68

Tabla 15. Resumen de resultado final primera evaluación. Fuente. Autor ... 69

Tabla 16. Tabla de calificaciones. Fuente. Autor ... 71

Tabla 17. Resultados de complejidad y riegos de sistemas desarrollados en Uniandes Ibarra. Fuente. Autor ... 72

(10)

ÍNDICE DE FIGURAS

Figura 1. Tabulación encuesta pregunta 1. Fuente. Autor ... 27

Figura 3.Tabulación encuesta pregunta 3. Fuente. Autor ... 28

Figura 11. Ubicación de las metodologías en relación al nivel de formalidad. Fuente. ESTELLER, Víctor, (2011),” Procesos de desarrollo de software y materiales educativos computarizados”. ... 39

Figura 12. Relación número de personas, criticidad y tamaño de la metodología. Fuente. COCKBURN, Alistair, (2001),”Agile Software Development”. ... 40

Figura 13. Fases de MODER. Fuente. Autor ... 50

Figura 14. Disciplinas del análisis previo. Fuente. Autor ... 51

Figura 15.Disciplinas de MODER. Fuente. Autor ... 54

Figura 16. Viabilidad. Fuente. Autor ... 56

Figura 17. Diseño de arquitectura. Fuente. Autor ... 58

(11)

RESUMEN EJECUTIVO

MODER (METODOLOGÍA ORIENTADA A DESARROLLO CON EQUIPOS REDUCIDOS), se presenta como alternativa a las metodologías utilizadas en UNIANDES Ibarra, porque los proyectos se hacen en parejas o solos aplicando metodologías tradicionales que no son recomendables para estos casos, de ahí surge la necesidad de tener una nueva metodología que se adapte a la construcción de software con equipos de desarrollo reducidos.

La creación MODER es importante porque se basa en procesos ágiles que están revolucionando la forma de realizar software, ya que permiten mayor adaptabilidad al desarrollo volátil del mismo.

MODER al presentarse como un método ágil muestra su actualidad ya que estos modelos están a la vanguardia en la construcción de software, demostrando buena adaptación a cambios y necesidades en el desarrollo de la nueva generación de software.

En el presente trabajo se aplicó el método inductivo-deductivo, para identificar los problemas al momento de construir un software, con este método se ha llegado a conocer nuevas propuestas que simplifican la creación del software.

Igualmente se aplicó la investigación cualitativa-cuantitativa que permitió obtener la descripción del problema y sus causas, también fue necesaria la aplicación de encuestas y entrevistas, a fin de valorar el grado de conocimiento de los estudiantes de la carrera de sistemas con respecto a los procesos metodológicos de desarrollo de software.

(12)

(13)

1 INTRODUCCIÓN

Hoyen día se presentan numerosas propuestas metodológicas que inciden en el proceso de desarrollo de software, estas han demostrado ser efectivas y necesarias en un gran número de proyectos, a continuación se hace referencia algunas de ellas: modelo cascada (1970) de Winston Royce considerada un enfoque clásico para desarrollo de sistemas, el modelo espiral (1986) impulsada por Barry Boehm que propone un desarrollo iterativo e incremental por medio de la construcción de prototipos, RUP con Ivar Jacobson a la cabeza hasta su lanzamiento oficial en 1998 como propiedad de IBM, XP (1996) de Ken Beck la cual propone desarrollo rápido de software, SCRUM (1996) presentada por Ken Schwaber que también muestra un desarrollo ágil de software.

En cuanto al desarrollo de metodologías dentro del país, no se ha encontrado registro alguno sobre creación de un nueva metodología para desarrollo de software o por lo menos no se ha encontrado ninguna publicación sobre el tema, en la Universidad Uniandes extensión Ibarra tampoco se ha realizado ningún trabajo que permita elaborar una metodología de desarrollo de software adaptable para equipos de trabajo reducidos, al contrario se utilizan las ya existentes en los proyectos integradores y tesis de la carrera de sistemas, aunque la que más se aplica es RUP, cabe mencionar que en Uniandes Ibarra se ha realizado una adaptación de esta metodología intentando reducir los procesos y la carga documental, aunque esto se ha realizado sin tener un estudio técnico sobre las afectaciones que tendría esta adaptación dentro del proyecto, también se aplica la metodología XP, aunque los resultados son difíciles de evaluar ya que recientemente se ha propuesto su inclusión.

(14)

2

En basea lo ya mencionado se pone en evidencia que le problema radica en la Inexistencia de una metodología de desarrollo de software dirigida a equipos de trabajo reducidos para su aplicación en los proyectos integradores y tesis en Uniandes extensión Ibarra.

La investigación se realizó en la Universidad Regional Autónoma de los Andes extensión Ibarra en la carrera de sistemas durante el año 2014 y 2015.

El objetode estudio presente en este trabajo es la Metodología de desarrollo de software, que sirve como guía para construcción de programas de computadora, así también se presenta como campo de acción la Ingeniería de software.

La línea de investigativa se ha enmarcado en el desarrollo software y programación de sistemas por lo que este estudio se lo realizó en el ámbito de las metodologías de desarrollo de software.

El presente proyecto permitió implementar una metodología para desarrollo de software dirigida a equipos de trabajo reducidos para la aplicación en proyectos integradores y tesis en Uniandes Ibarra, para lo cual fue necesario la fundamentación teóricamente a cerca de las metodologías de desarrollo de software más utilizadas actualmente, así también se diagnosticó el actual manejo y utilización de la metodología aplicada en el desarrollo de proyectos integradores y tesis dentro de Uniandes Ibarra, en base a lo mencionado anteriormente se realizó una metodología para desarrollo de software teniendo en cuenta los equipos de trabajo reducidos y su aplicación en proyectos integradores y tesis dentro de la Uniandes extensión Ibarra y se validó la propuesta por medio de la aprobación del proyecto por parte de los lectores.

En base a los objetivos anteriormente presentados se pretende dar una evaluación sobre el manejo actual en el desarrollo de software en Uniandes Ibarra para lo cual se planteó la idea de ¿Cómo optimizar los procesos metodológicos de desarrollo de software con equipos de trabajo reducidos en la Universidad Uniandes extensión Ibarra?

(15)

3

Para la realización del presente trabajo se aplicó el método inductivo-deductivo, ya que gracias a este se pudo identificar el problema de fondo en la aplicación de las metodologías para el desarrollo de software, gracias a este método se ha llegado a conocer las distintas propuestas utilizadas para la creación del software.

Así mismo se aplicó la investigación cualitativa-cuantitativa por medio de la cual se obtuvo la descripción del problema y sus causas, se hizo necesario crear y aplicar encuestas y entrevistas a fin de obtener la información necesaria que permita valorar el grado de conocimiento de los estudiantes de la carrera de sistemas en Uniandes Ibarra con respecto a los procesos metodológicos de desarrollo de software.

Esta investigación inicia con una introducción en la que se da a conocer el problema motivo de transformación, además de contener puntos concretos como son los antecedentes de la investigación, el planteamiento del problema, los objetivos y la justificación, además está compuesto por tres capítulos. En el capítulo uno, se hace referencia a conceptos y definiciones de los diferentes estudiosos y expertos acerca del tema, en base a estos se ha desarrollado el marco teórico. En el capítulo dos se hace conocer sobre la metodología de investigación empleada, los resultados obtenidos de la aplicación de las encuestas y las entrevistas, así como el planteamiento de la propuesta. El capítulo tres contiene el desarrollo de la propuesta investigativa, misma que tiene la elaboración de una metodología de desarrollo de software llamada MODER.

La novedad se hace notar en el desarrollo de la nueva metodología en la que se aplicó conocimientos avanzados de ingeniería de software a más de tener como referencia la aplicación de varias las metodologías de desarrollo de software.

(16)

4 CAPÍTULO I. MARCO TEÓRICO.

1.1. ORIGEN Y EVOLUCIÓN DEL OBJETO DE INVESTIGACIÓN.

Desde que se empezó a trabajar sobre el desarrollo de programas, aparecieron ciertos métodos que permitían producir un buen proyecto, estas metodologías eran simples, solo se preocupaban por los procesos más no por los datos. Durante los años sesenta predominaba el modelo de procesos que consistía en codificar y corregir, si al terminar se descubría que el diseño era incorrecto, la solución era desecharlo y volver a empezar, el modelo en cascada surge como respuesta ya que tiene más disciplina basado en el análisis, diseño, pruebas, mantenimiento.

Para la década de los ochenta es la época marcada por las metodologías dirigida a datos cuya importancia va tomando cuerpo en las organizaciones. Para los años 90 se quiere dar respuesta al entorno siempre cambiante y rápida evolución de los programas informáticos, lo cual da lugar a trabajar en ciclos cortos como si se tratara de mini proyectos mismo que implementan una parte de las funcionalidades, pero sin perder el rumbo general del proyecto global. Por otra parte las metodologías de desarrollo comienzan a interesarse no sólo en lograr que el proyecto sea puesto en funcionamiento sino en minimizar costos durante su desarrollo y sobre todo durante su mantenimiento, los nuevos métodos van buscando minimizar riesgos, puesto que los errores más perjudiciales se producen en los primeros pasos se comienza desde la fase más general del estudio por analizar los riesgos que significa seguir con las siguientes fases del desarrollo.

(17)

5

1.2. ANÁLISIS DE LAS DISTINTAS POSICIONES TEÓRICAS SOBRE EL OBJETO DE INVESTIGACIÓN.

Awad expone su criterio y manifiesta: “Metodologías imponen un proceso disciplinado en el desarrollo de software con el objetivo de hacer que el desarrollo de software más predecible y más eficiente” (Awad, 2011, p. 1).

Como se puede apreciar, Awad argumenta que las metodologías sirven como una guía base para el desarrollo de software de forma eficiente por lo que muestra como un proceso disciplinado, es decir que se toma los procesos de la ingeniería como cualquier otra rama del conocimiento, pero en este caso para la construcción de programas de computadora.

Según el instituto de comunicaciones español aporta diciendo que “Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo.” (Instituto Nacional de Telecomunicaciones, 2009, p. 18).

En este caso, INTECO muestra a las metodologías como un conjunto de técnicas y métodos que debe estar presente en todas las etapas del proyecto de software para poder enfrentar de mejor manera las actividades necesarias con referencia al desarrollo del proyecto, el ciclo de vida hace referencia al software desde sus inicios hasta su implementación como un producto real y que pueda ser explotado y utilizado.

Hoffer dice que una “Metodología se refiere a un proceso estándar seguido en una organización para llevar a cabo todos los pasos necesarios para analizar, diseñar, implementar y mantener sistemas de información” (Hoffer, 2010, p. 50).

Según Hoffer, muestra como un proceso estandarizado, mismo que ofrece organización, análisis, diseño y mantenimiento del software, es decir, durante todo el ciclo de vida del proyecto, con la finalidad de obtener un producto acorde a la realidad de los usuarios, también se puede destacar el mantenimiento del sistema y para este autor no solo es desarrollar el producto sino también mantenerlo a lo largo de su vida útil.

(18)

6

requiere hacerlo de forma ordenada, realizando análisis y mostrando los riesgos que puede abarcar la construcción del software que sea útil, estable y más que nada que cumpla con las necesidades y resuelva los problemas para los que fue concebido y también pueda ser utilizado sin ningún inconveniente por parte de los usuarios.

1.3. VALORACIÓN CRÍTICA DE LOS CONCEPTOS PRINCIPALES DE LAS DISTINTAS POSICIONES TEÓRICAS SOBRE EL OBJETO DE INVESTIGACIÓN.

1.3.1. INGENIERÍA DE SOFTWARE 1.3.1.1. CONCEPTOS BÁSICOS

Antes de poder indicar los conceptos básico de lo que es la ingeniería de software debemos conocer lo que es el software, algunos autores lo definen como:

“El software de computadora es el producto que construyen los programadores profesionales y al que después le dan mantenimiento durante largo tiempo”. (Pressman, 2009, p. 1).

“Programas de ordenador y la documentación asociada. Los productos de software se pueden desarrollar para algún cliente en particular o un mercado en general”. (Sommerville, 2010, p. 5).

“Programas, procedimientos, documentación y datos asociados, relacionados con la operación de un sistema informático” (Ieee Standar 610, 1993, p. 66).

A partir de las definiciones anteriormente presentadas, el software se puede definir como un conjunto de instrucciones, datos y documentos que proporcionan una funcionalidad deseada con la finalidad de solucionar determinados problemas, ahí es cuando se pone en evidencia la realidad actual del software como un recurso importante para cualquier persona o empresas porque gestionan su información utilizando programas de computadora, también se puede decir que el software se desarrolla mas no se fabrica ya que se construye para cumplir requisitos únicos de un cliente.

(19)

7

software, todavía no hay un acuerdo unánime sobre una definición exacta para este término, por lo que a continuación se han recopilado algunas de ellas:

“La ingeniería de software es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de este después de que se utiliza”. (Sommerville, 2010, p. 6).

“La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software”. (Ieee Standar 610, 1993, p. 30).

“La ingeniería de software es el establecimiento y uso de principios fundamentales de la ingeniería con objeto de desarrollar en forma económica software que sea confiable y que trabaje con eficiencia en máquinas reales”. (Pressman, 2009, p. 11) .

Como se puede apreciar cada autor tiene sus diferentes criterios y formas de analizar y dar un concepto a lo que es la ingeniería de software, aunque la mayoría de ellos se enfocan esencialmente en la misma idea basándose en la producción de software aunque ninguno de los autores pone énfasis de sobre los aspectos técnicos de sobre la calidad del software.

1.3.1.2. ANÁLISIS Y GESTIÓN DEL RIESGO

Primeramente debemos empezar conociendo que es un riesgo y para lo cual según Pressman lo presenta como “Un riesgo es un problema potencial: puede ocurrir, puede no ocurrir” (Pressman, 2009, p. 640), dado que son cuestiones impredecibles y no se sabrá el resultado del riesgo, lo más importante es identificarlo, valorar su posible impacto, ocurrencia y definir un plan de continencia en el caso que ocurra, siempre hay que estar preparados para cualquier eventualidad que salga durante el desarrollo, por esto también es importante la participación de todo el equipo que intervendrá en el proyecto.

Para la gestión de riesgos agregan varios puntos que se deben tomar en cuenta, para de esta forma proponer un plan de continencia que permita mitigar el riesgo y reducir su afectación durante el transcurso del proyecto, a continuación se muestran varios puntos:

(20)

8

Aquí se pone énfasis en detectar el riesgo de manera temprana, si es posible antes de que aparezcan afectaciones, para esto es importante la participación de las personas que intervienen en el proyecto, para que propongan normas de control de calidad para prevenir el riesgo de la forma más eficiente y segura.

“Analizar: es la conversión de los datos de riesgo en datos de información de riesgo para la toma de decisiones.” (Arefeen, 2011, p. 50).

En este punto se debe realizar una revisión, priorización y selección de los riegos que sean más críticos por lo que cada una se hace un análisis de costos del mismo a nivel rendimiento y calidad del producto.

“Plan: la planificación convierte la información del riesgo en decisiones y acciones para el presente y futuro.” (Arefeen, 2011, p. 50).

La planificación es importante ya que en este punto se toman las medidas que permitan enfrentar al riesgo de forma individual, para esto es necesario considerar las consecuencias futuras de las decisiones que se toman hoy.

“Seguimiento: consiste en hacer un monitoreo del estado del riesgo y las medidas para mitigarlos.” (Arefeen, 2011, p. 50).

Este aspecto es importante ya que dar un seguimiento adecuado a un riesgo tiene un valor significativo, porque así se puede evidenciar si el riesgo tendrá un coste mínimo o elevado, ya sea este a nivel económico, de organización o tiempo de desarrollo, así también se pondrá en evidencia la calidad de las medidas que se tomaron para evitar o minimizar las afectaciones del riesgo.

“Control: el control de riesgo se basa en la gestión del proyecto con acciones de control de procesos, corrigiendo las variaciones, respondiendo a eventos y mejorar el proceso de la gestión de riesgos.” (Arefeen, 2011, p. 50).

En este caso el control es importante ya que, se propone un ajuste constante y adaptación al cambio cuando un riesgo lo requiera, permitiendo renovar los planes de acción para combatirlos y así evitando en mayor medida el impacto de riesgo.

(21)

9

En este punto es muy importante el mantener la comunicación constante durante todo el manejo del riesgo ya si esto falla, no será posible tener una gestión viable y útil, en si la comunicación es una de las partes vitales para el éxito de un buen manejo del riesgo.

1.3.1.3. PRINCIPIOS DEL ANÁLISIS DE RIESGOS

Según Pressman (Pressman, 2009, p. 642), dentro de la gestión de riesgos se incluyen 7 principios generales por medio de los cuales se puede realizar la gestión de riesgos de manera más efectiva aplicando los siguientes principios:

“Mantener una perspectiva global: ver los riesgos del software dentro del contexto de un sistema donde el riesgo es un componente y el problema empresarial que se pretende resolver.” (Pressman, 2009, p. 642)

Tener una visión previsora: Pensar en que el riesgo puede aparecer en cualquier momento para lo cual se debe proponer planes de contingencia que hagan al riesgo más manejable en el futuro.

Alentar la comunicación abierta: Esto es muy importante ya que siempre es bueno tomar en cuenta los criterios de los demás y lo mejor es tener en cuenta todos los riesgos para más pequeños o simples que se los vea, así mismo incentivar a los usuarios y participantes a proponer riesgos en todo momento que sea posible.

Integración: Siempre se debe integrar la consideración de riesgos durante todo el análisis y desarrollo del software.

Enfatizar un proceso continuo: El equipo debe estar atento durante todo el proceso de desarrollo del proyecto para modificar los riesgos identificados y agregar nuevos que se presente o se tomen en cuenta.

Desarrollo de una visión conjunta del producto: Todos los participantes deben tener la misma visión del software para poder identificar y evaluar de mejor manera el riesgo. Alentar el trabajo en equipo: Este punto es sumamente importante ya que se deben combinar los talentos, habilidades y conocimientos de todos los participantes para tener una buena gestión de riesgos.

1.3.1.4. PRINCIPIOS DE DISEÑO DE RIESGOS

(22)

10

para el entorno, según Sommerville se los puede clasificar en 3 grupos (Sommerville, 2010, p. 179)

Intolerable: El sistema se debe diseñar de tal forma que si el riesgo ocurre no ocasione mayores inconvenientes y la solución a este sea de forma rápida y efectiva.

Razonablemente práctico: El sistema debe diseñarse para que la probabilidad de que ocurra algún problema sea mínima, estos riesgos tienen menos consecuencias y también menos probabilidad de que ocurran.

Aceptable: El sistema se diseña de tal forma que se realizan todos los posibles pasos para reducir la probabilidad de que aparezca un riesgo, estos pasos no deben incurrir en costes y tiempos de entrega o en otros atributos funcionales del sistema.

1.3.2. METODOLOGÍA RUP

1.3.2.1. CONCEPTOS BÁSICOS

La metodología RUP se puede definir como: “Conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software” (Torossi, 2005, p. 3).

En si el proceso unificado Rational (RUP) es un marco de trabajo de proceso de desarrollo de software iterativo creado por Rational Software Corporation, incluye una base de conocimiento con artefactos y descripciones detalladas para diferentes tipos de actividades.

1.3.2.2. CICLO DE VIDA

En el ciclo de vida RUP se realiza una adaptación del desarrollo en espiral, es decir que en el ciclo de vida se establecen tareas en fases e iteraciones dentro de las cuales se realizan varias iteraciones.

En las fases de Inicio y Elaboración se enfocan en entender el problema y la tecnología, la delimitación del ámbito del proyecto, la mitigación de riesgos críticos y establecer una base inicial para el proyecto.

1.3.2.3. FASE DE LA METODOLOGÍA a. Fase de inicio

(23)

11

En esta fase lo que se hace es definir cuál es el alcance del proyecto, así también se definirán los riegos así como el análisis para escoger la arquitectura y la tecnología en la que se desarrollará el proyecto.

b. Fase de elaboración:

“En la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura”. (Torossi, 2005, p. 8)

Como se puede apreciar, este autor expone que se debe tener un dominio del problema que se va a resolver, así como los posibles riesgos, por lo que la finalizar esta fase se obtendrá un modelado de los requerimientos del sistema.

c. Fase de desarrollo:

“Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta convertirse en el sistema completo” (Torossi, 2005, p. 8).

Para esta parte de la metodología RUP es donde se realiza el diseño de los programas con sus respectivas pruebas, es aquí donde se desarrolla e integran las partes del sistema.

d. Fase de transición:

“Cubre el periodo en el cual el producto se convierte en la versión beta. Las iteraciones en esta fase continúan agregando características aun sistema que el usuario está utilizando activamente”. (Torossi, 2005, p. 9).

En esta fase lo que se hace es mover el sistema del desarrollo al usuario y hacerlo trabajar en un entorno real y mostrando que funciona correctamente en un entorno operativo.

1.3.2.4. ARTEFACTOS

La metodología RUP en cada una de sus fases realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema, algunos de los artefactos son:

Fases Artefactos

Inicio Documento de visión, documento especificación de requerimientos, Diagramas de casos de uso.

Elaboración Documento de arquitectura, diagramas de clases, secuencia, estados, colaboración, modelo entidad relación.

(24)

12 Transición Pruebas finales, puesta en producción.

Tabla 1.Artefactos de RUP. Fuente. Autor 1.3.3. METODOLOGÍA XP

La programación extrema (XP) es una metodología para desarrollo de software propuesta por Kent Beck, es la más reconocida dentro de los procesos ágiles de desarrollo de software, esta metodología pone mayor énfasis en la adaptabilidad a más de centrarse en potenciar las relaciones interpersonales como clave para el éxito, promueve el trabajo en equipo.

1.3.3.2. FASES DE LA METODOLOGÍA

El ciclo de vida de XP consiste de 5 fases: Exploración, Planeación, Iteraciones, Producción, Mantenimiento.

a. Exploración

“En esta fase, los clientes plantean las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses”. (Sánchez, 2004)

b. Planificación de la Entrega (Release)

(25)

13 c. Iteraciones

“Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración. Al final de la última iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores”. (Sánchez, 2004)

d. Producción

“La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación”. (Sánchez, 2004)

e. Mantenimiento

“Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura”. (Sánchez, 2004)

1.3.3.3. ROLES DE LA METODOLOGÍA

“Programador: Escribe las pruebas unitarias y produce el código del sistema”. (Toro, 2013, p. 24)

(26)

14

implementan en cada iteración centrándose en apoyar mayor valor al negocio”. (Toro, 2013, p. 24)

“Encargado de pruebas (tester): Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas, difunde los resultados en el equipo y es responsable de las herramientas de soporte para las pruebas”. (Toro, 2013, p. 24)

“Encargado de seguimiento (tracker): Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración”. (Toro, 2013, p. 24)

“Entrenador (coach): Es el responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente”. (Toro, 2013, p. 24)

“Consultor: Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas”. (Toro, 2013, p. 24) “Gestor (big boss): es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación”. (Toro, 2013, p. 24)

1.3.4. METODOLOGÍA SCRUM 1.3.4.1. CONCEPTOS BÁSICOS

Scrum es un proceso metodológico ágil, incremental e interactivo que se puede usar para gestionar y controlar desarrollos complejos de software y productos o gestionar cualquier trabajo.

1.3.4.2. ETAPAS DE LA METODOLOGÍA

Para desarrollar la metodología Scrum se presentan las siguientes etapas:

a. Planificación de la iteración

“El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes:

(27)

15

 Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas”. (Albaladejo, 2008)

b. Ejecución de la iteración

“Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del equipo inspecciona el trabajo que el resto está realizando para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido.

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con su compromiso y de que no se pierda la productividad su productividad, ya que se elimina obstáculos que el equipo no puede resolver por sí mismo y también protege al equipo de interrupciones externas que puedan afectar su productividad”. (Albaladejo, 2008)

c. Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración esta etapa se divide en dos partes:

 Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo, en función de los resultados mostrados y de los cambios que haya habido en el proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya sea desde la primera iteración o replanificando el proyecto. (Albaladejo, 2008)

 Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar, mejorando su productividad. El Facilitador se encargara de ir eliminando los obstáculos identificados. (Albaladejo, 2008)

1.3.4.3. RESPONSABILIDADES DE LA METODOLOGÍA Las responsabilidades en las etapas del Scrum son:

a. Cliente (Product Owner)

“Las responsabilidades del Cliente que puede ser interno o externo a la organización son:  Ser el representante de todas las personas interesadas en los resultados del proyecto y

(28)

16  Definir los objetivos del producto o proyecto.

 Dirigir los resultados del proyecto y maximizar su ROI (Return Of Investment).

A más de esto el cliente también cumple otras funciones para colaborar en un mejor desarrollo del proyecto algunas de estas funciones son:

 En si el cliente es el propietario de la planificación del proyecto: crea y mantiene la lista priorizada con los requisitos necesarios para cubrir los objetivos del producto o proyecto, conoce el valor que aportara cada requisito y calcula el ROI a partir del coste de cada requisito que le proporciona el equipo.

 Reparte los objetivos y requisitos en iteraciones y establece un calendario de entregas.  Antes de iniciar cada iteración replanifica el proyecto en función de los requisitos que

aportan más valor en ese momento

 Participar en la reunión de planificación de iteración, proponiendo los requisitos más prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se comprometer a hacer.

 Estar disponible durante el curso de la iteración para responder a las preguntas que puedan aparecer.

 No cambiar los requisitos que se están desarrollando en una iteración, una vez esta iniciada.

 Participar en la reunión de demostración de la iteración, revisando los requisitos completados”. (Albaladejo, 2008)

b. Facilitador (Scrum Master)

“Lidera al equipo llevando a cabo las siguientes responsabilidades:

 Velar para que todos los participantes del proyecto sigan las reglas y proceso de Scrum, encajándolas en la cultura de la organización, y guiar la colaboración intraequipo y con el cliente de manera que las sinergias sean máximas. Esto implica:

 Asegurar que la lista de requisitos priorizada esté preparada antes de la siguiente iteración.

 Facilitar las reuniones de Scrum (planificación de la iteración, reuniones de sincronización del equipo, demostración, retrospectiva), de manera que sean productivas y consigan sus objetivos.

(29)

17

 Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteración y poder finalizar el proyecto con éxito. Estos obstáculos se identifican de manera sistemática en las reuniones diarias de sincronización del equipo y en las reuniones de retrospectiva.

 Proteger y aislar al equipo de interrupciones externas durante la ejecución de la iteración, de esta manera, el equipo puede mantener su productividad y el compromiso que adquirió sobre los requisitos que completaría en la iteración

 Asegurar que los requisitos se desarrollan con calidad”. (Albaladejo, 2008)

c. Equipo (Team)

“Grupo de personas que desarrollan el producto del proyecto. Tienen un objetivo común, comparten la responsabilidad del trabajo que realizan en cada iteración y en el proyecto. El tamaño del equipo está entre 5 y 9 personas. Por debajo de 5 personas cualquier interrupción sobre un miembro del equipo compromete seriamente el compromiso que han adquirido y, por tanto, el resultado que se va a entregar al cliente al finalizar la iteración. Por encima de 9 personas, la comunicación y colaboración entre todos los miembros se hace más difícil en este caso lo más recomendable es formar subgrupos de trabajo”. (Albaladejo, 2008)

1.3.5. MODELO EN CASCADA

1.3.5.1. CONCEPTOS Y CARACTERÍSTICAS

“El modelo de la cascada sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado”. (Pressman, 2009, p. 34).

El mismo hecho de ser lineal provoca inconvenientes en el desarrollo del software ya que no puede ser corregido con gran facilidad pues no puede dar retrocesos, a pesar de esto fue utilizado de los años 70, este modelo es uno de los más antiguos y que aún está en vigencia.

Entre las características de este modelo tenemos:

(30)

18

 Para que el proyecto tenga éxito debe desarrollarse todas las fases y cumplírselas a cabalidad.

 Las fases continúan hasta que los objetivos se han cumplido.

 Si se cambia de orden las fases, el producto final será de menor calidad”. (Shuttleworth, 2008)

1.3.5.2. FASES DEL MODELO

a. Análisis y definición de requerimientos

“En esta etapa se definen los requisitos y requerimientos del sistema software a partir de consultas con los clientes y los usuarios del futuro sistema software. De esta etapa surge el documento de especificación de requisitos que contiene toda la especificación del sistema sin entrar en detalles de diseño”. (Belmonte, 2010)

b. Diseño del sistema y del software

“En esta etapa se dividen los requerimientos en subsistemas, se establece una arquitectura completa y se identifican y describen las relaciones fundamentales del sistema software. De esta etapa surge el documento de diseño del software que contiene toda la descripción del sistema desde el punto de vista del diseño”. (Belmonte, 2010)

c. Implementación

“En esta etapa el diseño del software se lleva a cabo implementándolo en un lenguaje de programación. Aquí se implementa el código fuente, se crean las bibliotecas y se reutilizan los componentes”. (Belmonte, 2010)

d. Pruebas

“En esta etapa, los programas se integran y se prueban como un sistema completo para asegurar que se cumplen los requerimientos del software. Después de las pruebas el sistema se entrega al cliente”. (Belmonte, 2010)

e. Mantenimiento

(31)

19 1.3.5.3. VENTAJAS Y DESVENTAJAS

Las ventajas más evidentes del modelo cascada son las siguientes:

 “Buena organización y no se mezcla las fases.

 Es adecuado para proyectos rígidos donde se especifiquen muy bien los requerimientos y se conozca la herramienta a utilizar.

 La planificación es sencilla.

 La calidad de producto es alta”. (Shuttleworth, 2008)  Los usuarios los pueden comprender fácilmente.

Las desventajas de este modelo son las siguientes:

 “Iteraciones costosas tanto en consumo de tiempo y recursos económicos.  Los problemas que se presentan son corregidos posteriormente.

 Puede que el software no cumpla con los requerimientos.

 Es difícil de incorporar nuevas cosas si se quiere actualizar”. (Shuttleworth, 2008)  Es normal detenerse en su desarrollo y seguir con otras fases.

 Se tarda mucho tiempo en pasar todo el ciclo.

 Las revisiones de proyectos de gran complejidad son muy difíciles.

1.3.6. MODELO ESPIRAL

“El modelo en espiral del proceso del software que fue propuesto por Boehm (1988), este modelo es una de las metodologías más recomendables para el desarrollo y creación de un programa ya que consta de pocas fases que se van realizando en una manera continua y cíclica”. (Arvai, 2009)

Dentro de este modelo cada iteración del proyecto sigue varios pasos:

“Determinar o fijar los objetivos: En este paso se definen los objetivos específicos para luego identificar las limitaciones del proceso y del sistema, además se diseña una planificación detallada de gestión y se identifican los riesgos.

(32)

20

Desarrollar, verificar y validar: Después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo codifica.

Planifica: En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto”. (Fariño, 2011)

1.3.6.2. CARACTERÍSTICAS

Dentro de las características del modelo espiral aparecen:

 Mejorar los ciclos de vida clásicos y prototipos.

 Puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo).  En cada giro se construye un nuevo modelo del sistema completo.

 El análisis de riesgo requiere la participación de personal con alta cualificación.  Incorpora objetivos de calidad y gestión de riesgos

 Elimina errores y alternativas no atractivas al comienzo  Permite iteraciones, vuelta atrás y finalizaciones rápidas

 Cada ciclo empieza identificando los objetivos de la porción correspondiente, las alternativas y restricciones.

1.3.6.3. FASES DEL MODELO

El modelo en espiral esta compartida en varias actividades estructurales, también llamadas regiones de tareas. Existen seis regiones de tareas que son:

“Comunicación con el cliente: esta es una tarea requerida para establecer comunicación entre el desarrollador y el cliente.

Planificación: esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos. Análisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto.

Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la aplicación.

(33)

21

Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de implementación creada durante la etapa de instalación.” (Fariño, 2011)

1.3.6.4. VENTAJAS Y DESVENTAJAS Dentro de las ventajas del modelo espiral tenemos:

 “No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.

 En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.

 Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo”. (Fariño, 2011)

Las desventajas del modelo espiral son:

 “Complicación cuando se evalúa los riesgos.

 Se requiere la participación continua por parte del cliente.

 Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software”. (Fariño, 2011)

1.3.7. MODELO ÁGIL DE DESARROLLO DE SOFTWARE

1.3.7.1. MANIFIESTO POR EL DESARROLLO ÁGIL DE SOFTWARE.

Es el resultado de una reunión encabezada por Kent Beck en el febrero de 2001, a la que acudieron diecisiete críticos de los modelos de mejora del desarrollo de software basado en procesos y así propusieron los principios sobre los que se basan los métodos alternativos, lo que fue denominado como Manifiesto Ágil.

Así también se destaca el enunciado principal que da inicio a este manifiesto de agilidad propuesto por todos los participantes que acudieron a la reunión:

(34)

22

 Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”. (Beck, 2001).

Como se puede apreciar, este manifiesto de agilidad, surge ante la necesidad de tener unas formas de desarrollar software ya que las que existían hasta ese momento no lograban satisfacer las necesidades metodológicas que se requerían, este manifiesto revoluciono la forma en la que se construye el software actualmente.

1.3.7.2. PRINCIPIOS DEL MANIFIESTO ÁGIL.

El manifiesto ágil se sienta en doce principios, los cuales se nota claramente que se da mayor importancia a las personas que al mismo procesos y todo gira en torno al desarrollo en equipos y la importancia de dar interactuar entre ellas, así como a la entregas cortas de avances del proyecto, a continuación se hace una cita textual de los principios del manifiesto ágil:

 “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

 Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

 Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

 Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.

 Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

 El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

 El software funcionando es la medida principal de progreso.

 Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

(35)

23

 La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.  Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.  A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a

continuación ajustar y perfeccionar su comportamiento en consecuencia”. (Beck, 2001).

1.3.7.3. PRÁCTICAS DE AGILIDAD.

Las prácticas de agilidad de basan en cuatro principios que permiten promover la adaptación a los cambios, la comunicación constante entre el equipo y los clientes o encargados del proyecto, la confianza en las personas que participan en el proyecto y la eficiencia con la que desarrollan las tareas asignadas a ellos.

 Adaptación Regular

Una de las prácticas es la adaptación regular a los cambios, esto no quiere decir que se tenga que desechar el plan que ya se ha hecho, al contrario esto permite ajustar de manera óptima y de acuerdo a la realidad, para así poder obtener mejores resultados a menor costo de recursos, además que esto es acorde a la realidad ya que los proyectos reales nunca se desarrollan en forma lineal.

 Confianza

Esta práctica es importante ya que el éxito se alcanza por individuos motivados que se comunican entre sí, esto sucede en una cultura de confianza y que el trabajo realizado se haciendo de la mejor manera en todas las partes del proyecto.

 Comunicación

(36)

24  Eficiencia

En el ambiente de trabajo ágil, simplicidad se define como el arte de maximizar la cantidad de trabajo realizado. Esto significa que la energía no se desperdicia en actividades improductivas, y lo que se hace es aprovechado para el máximo efecto.

1.4. CONCLUSIONES PARCIALES DEL CAPÍTULO.

 El software es uno de los pilares fundamentales de la sociedad moderna por lo que es necesario realizarlo con altos niveles de calidad y es ahí donde las metodologías para desarrollo de software ofrecen una guía que permita construirlo acorde a las necesidades y requerimientos para los que fue concebido.

 Con el avance del tiempo y la tecnología se han presentado nuevas soluciones metodológicas que permiten adaptarse de mejor manera a la creciente complejidad del software actual.

 De acuerdo a los criterios de varios autores, queda en evidencia que aún no existe una única definición sobre lo que es una metodología de software, pero también se hace ver es que tienen coincidencias en algunos enfoques como son la inclusión de un proceso, documentación y que una rama de la ingeniería.

(37)

25

CAPÍTULO II. MARCO METODOLÓGICO Y PLANTEAMIENTO DE LA PROPUESTA.

2.1. CARACTERIZACIÓN DEL SECTOR, RAMA, EMPRESA, CONTEXTO INSTITUCIONAL O PROBLEMA SELECCIONADO PARA LA INVESTIGACIÓN.

La Universidad Autónoma de los Andes extensión Ibarra, es una institución de educación superior que se encuentra ubicada en la Juan de Salinas y Miguel Oviedo, cuya actividades están centradas en la educación superior de la zona norte del país. Al tratarse de una institución educativa se desarrollan proyectos integradores durante todos los semestres, pero en la carrera de sistemas estos son en base a desarrollo de software para lo cual se aplican metodologías que permiten la realización de estos por lo que es necesario adoptar una nueva propuesta ágil acorde con las necesidades actuales de la institución en cuanto a desarrollo de software.

2.2. DESCRIPCIÓN DEL PROCEDIMIENTO METODOLÓGICO PARA EL DESARROLLO DE LA INVESTIGACIÓN.

2.2.1. METODOLOGÍA.

Durante la realización del presente trabajo investigativo, se aplicó el método inductivo-deductivo, por medio del cual se pudo identificar el problema al momento de desarrollar software con metodologías pesadas como la RUP, con este método se pudo conocer nuevas propuestas metodológicas para construcción de software que ayudan y mejoran el proceso de creación del mismo.

También se aplicó el método cualitativo-cuantitativo por medio del cual permitió obtener la descripción del problema y sus causas con la finalidad de conocer los inconvenientes al desarrollar software.

(38)

26 2.2.2. POBLACIÓN Y MUESTRA.

Para obtener información necesaria para llevar a cabo la presente investigación se tomó como población a los estudiantes desde tercero hasta noveno semestre y coordinador de la carrera de sistemas de Uniandes Ibarra, no fueron tomados en cuenta los estudiantes de primero y segundo semestre ya que a ellos aún no se les imparte ninguna cátedra sobre el uso de metodologías de desarrollo de software por este motivo fueron descartados del presente estudio, teniendo una población de veinte y nueve estudiantes y un coordinador de carrera (ver tabla 2).

Para la muestra se mantienen la población antes mencionada y no se aplicará ninguna fórmula para obtener la muestra ya que para esto se necesita un número mínimo de ciento cincuenta personas que solicita la estadística para estos casos y dado al pequeño universo poblacional, se descarta el uso de esta fórmula.

Población Herramienta

Estudiantes 29 Encuesta

Coordinadora de la carrera de sistemas (Ing. Rita Díaz) 1 Entrevista Tabla 2. Herramientas y población. Fuente. Autor

2.2.3. TÉCNICAS Y HERRAMIENTAS.

Durante el desarrollo del presente trabajo se utilizaron técnicas de investigación como son las encuestas dirigidas hacia los estudiantes de la carrera de sistemas, por medio de las cuales se pudo recolectar la información necesaria para evaluar el nivel de conocimiento sobre la aplicación de metodologías de desarrollo de software, también se utilizó la entrevista dirigida a la Ing. Rita Díaz coordinadora de la carrera de sistemas, con la finalidad de conocer la situación actual en relación al uso y aplicación de las metodologías de desarrollo de software en los proyectos integradores y tesis.

(39)

27

2.2.4. ANÁLISIS DE ENCUESTAS Y ENTREVISTAS. 2.2.4.1. ENCUESTAS A ALUMNOS.

1. ¿Para el desarrollo de proyectos integradores o tesis, cuantas personas intervienen en el desarrollo del mismo?

PREGUNTA 1

1 persona 2 personas 3 personas 4 personas TOTAL

3 22 2 2 29

Tabla 3. Resultados de encuesta pregunta 1. Fuente. Autor

Figura 1. Tabulación encuesta pregunta 1. Fuente. Autor

Como se puede apreciar la mayoría de los estudiantes encuestados han contestado que los proyectos integradores se los realiza en grupos de dos personas, salvo que se de algún caso especial que se les permita hacer en grupos de tres hasta cuatro personas, aquí también se muestra que también se realizan las tesis de forma individual.

2. ¿Qué grado de complejidad tienen los proyectos integradores que ha desarrollado? PREGUNTA 2

Baja Media Alta TOTAL

1 20 8 29

Tabla 4.Tabulación encuesta pregunta 2. Fuente. Autor

De acuerdo a los resultados obtenidos se demuestra que los proyectos integradores que se realizan en Uniandes se los puede considerar de una complejidad media.

3

22

2 2 29

1 persona

2 personas

3 personas

4 personas

1 ₂₀

8

29 Baja

Media

(40)

28

3. ¿Qué metodología para desarrollo de software ha utilizado? PREGUNTA 3

Cascada RUP XP Otras TOTAL

13 19 16 0 48

Figura 3.Tabulación encuesta pregunta 3. Fuente. Autor

Los valores obtenidos destacan que hay cuarenta y ocho anotaciones ya que se dio la opción de escoger varias de las respuesta y por lo que se puede verificar es que se utiliza las metodologías RUP, Cascada y XP, siendo entre estas la metodología RUP la que obtiene mayor uso para el desarrollo de los proyectos integradores y tesis en Uniandes Ibarra.

4. ¿Qué metodología para desarrollo de software le es más fácil aplicar? PREGUNTA 4

Cascada RUP XP Otras TOTAL

9 7 13 0 29

En este caso se muestra un clara inclinación de la mayoría de los encuestados por la metodología ágil XP como la más fácil de aplicar para los proyectos integradores y tesis.

(41)

29

5. ¿Considera necesario utilizar todos los diagramas de UML para aplicar la metodología RUP?

PREGUNTA 5

SI NO TOTAL

13 16 29

En este caso se da una clara tendencia hacia la utilización de todos los diagramas de UML dentro de la metodología RUP, esta situación permitirá tomarlo en cuenta para la realización de la propuesta de la investigación.

6. ¿Ha tenido algún inconveniente en aplicar de forma correcta las todas las fases de la metodología RUP?

PREGUNTA 6

SI NO TOTAL

27 2 29

Según la información recolectada se puede determinar que la mayoría de los encuestados ha tenido algún tipo de problemas para aplicar las fases de la metodología RUP, esto demuestra que es un poco complicada implementarla con equipos de trabajo reducidos.

13

16

29 SI

NO

TOTAL

27

2

29 SI

NO

(42)

30

7. ¿Ha tenido algún inconveniente para aplicar la fase de inicio de la metodología RUP?

PREGUNTA 7

SI NO TOTAL

20 9 29

Aquí se puede apreciar claramente que los estudiantes que han utilizado la Metodología RUP, en algún momento han tenido problemas al implementar la fase de inicio.

8. ¿En el documento de visión, ha tenido algún inconveniente para identificar los stakeholders?

PREGUNTA 8

SI NO TOTAL

23 6 29

En relación con los datos obtenidos se hace notar que la gran mayoría se le ha presentado algún tipo de inconveniente para identificar los stakeholders en la fase de inicio.

20

9

29 SI

NO

TOTAL

23

6

29 SI

NO

(43)

31

9. ¿Qué inconvenientes ha tenido para desarrollar los casos de uso? PREGUNTA 9

DESCONOCIMIENTO IDENTIFICAR PROCESOS TOTAL

13 16 29

En esta pregunta se la dejo abierta pero durante la tabulación de la mismas se pudo definir dos tendencia por parte de los estudiantes, estas tendencias son el desconocimiento la otra es la definición de los procesos que les permita desarrollar los casos de uso y por la tanto se pude deducir hay casi un equilibrio entre el desconocimiento y la identificación de procesos.

10. ¿Considera que se debe mantener el uso de la metodología RUP para desarrollo de proyectos integradores y tesis?

PREGUNTA 10

SI NO TOTAL

11 18 29

Tabla 12.Tabulación encuesta pregunta 10. Fuente Autor

Aquí se puede ver claramente que los estudiantes preferían utilizar otra propuesta metodológica diferente a la de RUP para el desarrollo de los proyectos integradores y tesis.

13

16 29

DESCONOCIMIENTO

IDENTIFICAR PROCESOS

TOTAL

11

18

29 SI

NO

(44)

32

2.2.4.2. ENTREVISTA AL COORDINADOR (Ing. Luis Suárez delegado por la Ing. Rita Díaz).

1. ¿Qué problemas ha tiene sobre la metodología RUP al aplicarla en los proyectos integradores y tesis?

Es una metodología de desarrollo de software compleja y extensa para proyectos de corta duración como los que se realizan en la institución.

2. Cree que es factible la utilización de la metodología RUP con en equipos de trabajo reducidos y proyectos de poco alcance. ¿Por qué?

No es tan factible, se debería acoplar o utilizar una metodología acorde a las circunstancias de los proyectos integradores.

3. ¿Por qué se aplica la metodología RUP, si se sabe que no es factible utilizarla para trabajar en parejas?

Se utilizaba anteriormente, pero actualmente es de libre elección acorde con el proyecto por lo que el estudiante puede escoger la que más le convenga.

4. ¿Piensa que se está aplicando de forma correcta la metodología RUP en el desarrollo de los proyectos integradores?

No es tan correcto, ya que se debe resumir al máximo la metodología para poder aplicar, pero como son proyectos cortos no es una buena opción.

5. ¿Cuáles son los problemas que más incurren los estudiantes en la fase de inicio de la metodología RUP?

El problema es que la tendencia es saltarse los pasos de levantamiento de requerimientos y otras, no se lo toma muy enserio, por lo tanto ya en la fase de desarrollo se evidencian estos problemas.

6. ¿Cuáles son los problemas que más incurren los estudiantes en la fase de elaboración de la metodología RUP?

(45)

33

7. ¿Cuáles son los problemas que más incurren los estudiantes en la fase de construcción de la metodología RUP?

Aquí se van evidenciando las falencias de las fases anteriores y se siguen acumulando los problemas que se debían solucionar en las primeras fases del proyecto.

8. ¿Cuáles son los problemas que más incurren los estudiantes en la fase de transición de la metodología RUP?

No se ha tomado muy en cuenta aspectos de implantación como: equipos, personal capacitado, capacitadores, comunicaciones y redes, infraestructura tecnología, etc.

9. Cree que la carga documental de la metodología RUP es demasiado extensa, sabe cuál es la causa para esto?

No me parece extensa, se lo ve así por el tipo de proyecto que generalmente es de corto impacto en donde no beneficia en gran manera la documentación de RUP.

10.En base a que parámetros o criterios se realizaría una adaptación de la metodología RUP para equipos de trabajo reducidos?

Para esto se ha tomado en cuenta algunos parámetros como son: tiempo, complejidad, grupo de trabajo, requerimientos de la empresa.

11. Cree que es necesario cambiar el uso de la metodología RUP por otra propuesta metodológica para equipos de trabajo reducidos. ¿Por qué?

Sí, hay en la actualidad metodologías ágiles que se adaptan al tipo de proyecto que se tiene en la Universidad, incluso el estudiante podría adaptar una metodología hibrida en el desarrollo de su proyecto en base a experiencia de otros proyectos.

2.3. PROPUESTA DEL INVESTIGADOR.

(46)

34

determinar las fases, disciplinas, roles y documentación que se incluirán en la metodología MODER, con la finalidad de dar una solución sustentable a los problemas encontrados y que sirven como base para el desarrollo de la investigación.

2.4. CONCLUSIONES PARCIALES DEL CAPÍTULO.

 Se realizó un estudio sobre del uso y aplicación de las metodologías de desarrollo de software en Uniandes Ibarra.

 Se puso en evidencia varios inconvenientes ocasionados por utilizar la metodología RUP con grupos de trabajo con un máximo de cuatro personas a cargo del proyecto.  Se planteó la necesidad de desarrollar con una metodología ágil que permite adaptarse

de mejor manera a equipos de trabajo reducidos.