Diseño y propuesta de una metodología de desarrollo de software by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica – Escuela de Sistemas

Portada DISEÑO Y PROPUESTA DE UNA METODOLOGÍA DE DESARROLLO DE SOFTWARE PARA EL ÁREA DE PROGRAMACIÓN DE LA PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR, SEDE SANTO DOMINGO PUCE SD

Disertación de grado previa la obtención del título de Ingeniero de Sistemas y Computación.

Línea de investigación: Estudio, Diseño e Implementación de Software.

Autor: FAUSTO ROBERTO SOTO JARAMILLO

Asesor: MG. ANDRADE SALAZAR MILTON TEMISTÓCLES

Santo Domingo – Ecuador Abril, 2015

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica – Escuela de Sistemas

HOJA DE APROBACIÓN

DISEÑO Y PROPUESTA DE UNA METODOLOGÍA DE DESARROLLO DE SOFTWARE PARA EL ÁREA DE PROGRAMACIÓN DE LA PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR, SEDE SANTO DOMINGO PUCE SD

Línea de investigación: Estudio, Diseño e Implementación de Software.

Autor: FAUSTO ROBERTO SOTO JARAMILLO

Milton Temistocles Andrade Salazar, Mg. f. DIRECTOR DE LA DISERTACIÓN DE GRADO Adrián Rolando Cevallos Dueñas, Mg. CALIFICADOR

Margoth Elisa Guaraca Moyota, Ing. CALIFICADOR

Rodolfo Sirilo Córdova Galvez, Mg. DIRECTOR DE LA ESCUELA DE SISTEMAS

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Fausto Roberto Soto Jaramillo portador de la cédula de ciudadanía No. 1722421029 declaro que los resultados obtenidos en la Investigación que presento como informe final, previo la obtención del Grado de INGENIERO DE SISTEMAS Y COMPUTACIÓN son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Fausto Roberto Soto Jaramillo C.I 1722421029

DEDICATORIA El presente trabajo quiero dedicar primeramente a mi padre celestial, a mi querida madre que luch贸 para que pueda estudiar, a mis abuelos por haberme cuidado y al resto de mi familia, los cuales me han brindado todo su apoyo para que pueda culminar esta disertaci贸n de grado. Fausto Soto

AGRADECIMIENTO Este trabajo de investigación se llevó a cabo gracias al mejoramiento continuo que la PUCE SD requiere en sus departamentos de investigación, como lo es el departamento de Dirección de Tecnologías de la Información (DTI).

Agradecer, a mi familia que ha sido mi sustento durante todo mi proceso de estudios. Al Mg. Milton Andrade, mi Director de tesis, por guiarme en el desarrollo de mi disertación. Fausto Roberto Soto Jaramillo

RESUMEN El objetivo de este trabajo es el plantear una propuesta de una metodología de desarrollo de software para el área de programación de la Pontificia Universidad Católica del Ecuador Sede Santo Domingo, llamada DTI (Dirección de Tecnología de la Información). Para ello se realizó una investigación y análisis situacional en cuál se evidenció la falta de una metodología de desarrollo de software en el que consten procedimientos que permitan un control adecuado de los procesos realizados y faciliten el desarrollo de software. Se determinó que la mejor metodología de desarrollo de software ágil es la XP (Programación Extrema), ya que su estructura y características permiten que se adapte mejor al tipo de trabajo que utilizan las instituciones y empresas que están realizando continuamente sistemas o a su vez modificando su estructura. Y en caso de proyectos de largo alcance y tiempo se estableció la metodología tradicional RUP debido a su adaptabilidad en diferentes niveles de aptitud y diferentes tamaños de proyectos. Con la implementación de la metodología XP y RUP se optimizarán los procesos y el tiempo en el desarrollo de las aplicaciones que se realicen en el área de software; a la vez que se optimizará la administración de las mismas.

vii

ABSTRACT The objective of this work is to establish a proposal of a methodology of development of software in Programming area of Pontificia Universidad Cat贸lica del Ecuador, Sede Santo Domingo, called DTI (Information Technology Department). To do this, it was carried out a research and a situational analysis in which it provided evidence of lack of a methodology of development of software in which has procedures that permit an adequate control of processes executed and facilitate a development of software. It was determined that the better methodology of development of agile software is XP (Extreme Programming), due to its structure and features permit to be better adapted to the kind of work used by institutions and enterprises that are continuously developing systems or at the same time modifying their structure. And in a case of long-term and time projects, it was established a RUP traditional methodology because of its adaptability in different proficiency levels and different sizes of projects. With implementation of XP and RUP methodology it will be optimized processes and time in developing applications that are carried out in the software area; at the same time it will be optimized the management of them.

viii

TABLA DE CONTENIDOS Portada……… .............................................................................................................. i Hoja de aprobación ...................................................................................................... ii Declaración de autenticidad y responsabilidad ........................................................... iii Dedicatoria… .............................................................................................................. iv Agradecimiento ............................................................................................................ v Resumen……. ............................................................................................................. vi Abstract……. ............................................................................................................. vii Tabla de contenidos................................................................................................... viii Índice de ilustraciones ................................................................................................ xii Índice de tablas .......................................................................................................... xiv Índice de anexos ......................................................................................................... xv

I INTRODUCCIÓN ................................................................................................... 1

II PLANTEAMIENTO DEL PROBLEMA............................................................. 3

2.1

Antecedentes del problema de investigación .......................................... 3

2.2

Delimitación del Problema de Investigación. ......................................... 4

2.3

Justificación de la Investigación. ............................................................ 5

2.4

Objetivos de la Investigación. ................................................................. 6

2.4.1

Objetivo General. .................................................................................... 6

2.4.2

Objetivos Específicos. ............................................................................ 7

III MARCO REFERENCIAL. ................................................................................. 8 3.1

Revisión de la literatura o fundamentos teóricos. ................................... 8

3.1.1

Ingeniería de Software. ........................................................................... 8

3.1.2

Metodología. ........................................................................................... 9

3.1.2.1

Metodologías de Desarrollo de Software................................................ 9

3.1.2.2

Cronología de Metodologías de Desarrollo de Software. ..................... 11

3.1.2.3

Clasificación de las metodologías......................................................... 12

3.1.2.3.1.

Metodologías Tradicionales. ................................................................. 12

3.1.2.3.2.

Metodologías Ágiles. ............................................................................ 13

3.1.3

Ciclo de vida del software. ................................................................... 16

3.1.3.1

Procesos primarios del ciclo de vida del software. ............................... 16

3.1.4

Modelos para el Desarrollo de Software............................................... 17

3.1.4.1

Modelos Genéricos de Desarrollo de Software. ................................... 18

3.1.4.1.1.

Modelo en Cascada. .............................................................................. 18

3.1.4.1.2.

Modelo de Prototipos. ........................................................................... 19

3.1.4.1.3.

Modelo de Desarrollo Evolutivo........................................................... 20

3.1.4.1.4.

Modelo en Espiral. ................................................................................ 21

3.1.4.1.5.

Modelo de desarrollo basado en componentes. .................................... 22

3.1.4.1.6.

Modelo de métodos formales. ............................................................... 23

3.2

Investigaciones o experiencias empíricas vinculadas con el problema de investigación. ........................................................................................ 23

3.3

Hipótesis del trabajo. ............................................................................ 24

IV METODOLOGÍA DE LA INVESTIGACIÓN. ............................................... 25 4.1

Diseño/Tipo de investigación. .............................................................. 25

4.1.1

Contexto. ............................................................................................... 25

4.1.2

Tipo de la investigación. ....................................................................... 26

4.1.3

Diseño de la investigación. ................................................................... 26

4.1.4

Métodos de investigación. .................................................................... 27

4.2

Determinación de la Población/Universo. ............................................ 31

4.2.1

Población. ............................................................................................. 31

4.2.2

Muestra. ................................................................................................ 31

4.3

Determinación de la muestra. ............................................................... 32

4.4

Tipos de fuentes de información. .......................................................... 32

4.5

Técnicas e Instrumentos de recogida de datos. ..................................... 33

4.6

Propuestas de metodologías de desarrollo de software para el DTI. .... 34

4.6.1

Propuesta de una metodología RUP. .................................................... 34

4.6.1.1

Herramientas a utilizar para aplicar RUP. ............................................ 34

4.6.1.1.1.

Rational Rose. ....................................................................................... 34

4.6.1.2

Aplicación de RUP. .............................................................................. 36

4.6.1.2.1.

Modelado del negocio. .......................................................................... 36

4.6.1.2.2.

Definición de los requerimientos. ......................................................... 41

4.6.1.2.3.

Modelo del sistema. .............................................................................. 42

4.6.1.2.4.

Diseño e implementación del sistema. .................................................. 43

4.6.2

Propuesta de una metodología XP. ....................................................... 44

4.6.2.1

Herramientas a utilizar para aplicar XP. ............................................... 45

4.6.2.1.1.

Sprintometer.......................................................................................... 45

4.6.2.2

Pasos de la metodología XP.................................................................. 46

4.6.2.3

Fases de la metodología XP. ................................................................. 48

4.6.2.3.1.

Primera Fase: Planificación del Proyecto. ............................................ 48

4.6.2.3.2.

Segunda Fase: Diseño. .......................................................................... 50

4.6.2.3.3.

Tercera Fase: Codificación. .................................................................. 51

4.6.2.3.4.

Cuarta Fase: Pruebas. ............................................................................ 52

V RESULTADOS ..................................................................................................... 54 5.1

Discusión y análisis de resultados. ....................................................... 54

5.2

Conclusiones. ........................................................................................ 57

5.3

Recomendaciones. ................................................................................ 58

Fuentes de referencia.................................................................................................. 59 Anexos……… ........................................................................................................... 61

xii

ÍNDICE DE ILUSTRACIONES Ilustración 1

Principios de Manifiesto Ágil ........................................................ 15

Ilustración 2

Modelo en Cascada ........................................................................ 19

Ilustración 3

Modelo de Prototipos ..................................................................... 20

Ilustración 4

Modelo Incremental ....................................................................... 21

Ilustración 5

Modelo en Espiral .......................................................................... 22

Ilustración 6

Modelo de desarrollo basado en componentes .............................. 22

Ilustración 7

Modelo de métodos formales......................................................... 23

Ilustración 8

Diagrama de casos de uso del negocio .......................................... 38

Ilustración 9

Diagrama de Actividades de Casos de Uso ................................... 39

Ilustración 10

Diagrama de Actividades – revisar expediente.............................. 40

Ilustración 11

Diagrama de clases del modelo de objetos .................................... 41

Ilustración 12

Diagrama de casos de uso por paquetes ........................................ 43

Ilustración 13

Diseño de una BD .......................................................................... 44

Ilustración 14

Proceso de la Metodología XP ...................................................... 45

Ilustración 15

Fases de la Metodología XP .......................................................... 53

Ilustración 16

Diagrama de Actividades - Solicitar reportes ................................ 63

Ilustración 17

Diagrama de Actividades - Revisar expediente de equipo ............ 64

Ilustración 18

Diagrama de Actividades - Solicitar registro ................................. 65

Ilustración 19

Diagrama de Actividades - Solicitar registro de software ............. 66

Ilustración 20

Diagrama de Actividades - Realizar control interno ..................... 67

Ilustración 21

Diagrama de Actividades - Solicitar historial de incidencias ........ 68

Ilustración 22

Control Interno............................................................................... 69

Ilustración 23

Gestionar Historial de incidencias ................................................. 70

Ilustración 24

Registro de control de acceso ........................................................ 70

xiii

Ilustraci贸n 25

Diagrama de Clases ....................................................................... 71

Ilustraci贸n 26

Dise帽o de una BD .......................................................................... 72

xiv

ÍNDICE DE TABLAS Tabla 1

Actores del negocio .............................................................................. 37

Tabla 2

Trabajadores del negocio ...................................................................... 38

Tabla 3

Actores del sistema ............................................................................... 42

Tabla 4

Matriz Selección de metodología tradicional ....................................... 56

Tabla 5

Matriz de Selección de metodología ágil .............................................. 56

Tabla 6

Historias de Usuario - autenticación ..................................................... 73

Tabla 7

Historias de Usuario - inventario de activos ......................................... 74

Tabla 8

Historias de Usuario - selección de préstamos ..................................... 74

Tabla 9

Tareas de Usuario - diseño interfaz ...................................................... 75

Tabla 10

Tareas de Usuario - listado de préstamos ............................................. 75

Tabla 11

Historias de Usuarios - Administrador ................................................. 76

Tabla 12

Historias de Usuario - secretaría ........................................................... 76

Tabla 13

Tareas .................................................................................................... 77

Tabla 14

Requerimientos ..................................................................................... 78

Tabla 15

Descripción de los Riesgos ................................................................... 80

Tabla 16

Análisis de Riesgos ............................................................................... 82

Tabla 17

Criterio de Valoración de Probabilidad ................................................ 83

Tabla 18

Impuesto del Riesgo.............................................................................. 83

Tabla 19

Exposición del Riesgo .......................................................................... 83

Tabla 20

Prioridad del Riesgo.............................................................................. 83

Tabla 21

Exposición del Riesgo .......................................................................... 84

ÍNDICE DE ANEXOS Anexo 1

Comparación entre las metodologías tradicionales y las ágiles. ........... 61

Anexo 2

Entrevista .............................................................................................. 62

Anexo 3

Ejemplo de Análisis de un proyecto con metodología RUP ................. 63

Anexo 4

Ejemplo de Análisis Funcional y de Riesgos de un proyecto con ........... metodología XP .................................................................................... 73

I INTRODUCCIÓN

Las metodologías de desarrollo de software desde su aparición, se las considera como una herramienta de gran ayuda para los desarrolladores de software y en la actualidad para las empresas e instituciones que poseen departamentos de sistemas. Su función principal es la de agilizar y mejorar los procesos existentes.

Para que una metodología de desarrollo de software se la considere flexible, debe permitir que el encargado de un proyecto cubra las necesidades del mismo, mediante la selección adecuada de los procesos, evitando la realización de actividades innecesarias y acentuando las que resulten más significativas.

Este proyecto busca brindar a la Universidad, específicamente al Departamento de Tecnología de la Información (DTI), una optimización en el control de los cambios realizados en un proyecto de software, ya que todos los procesos realizados actualmente en el departamento no siguen una metodología específica que optimice sus recursos. Por lo que se propone establecer dos metodologías, dependiendo del tiempo de desarrollo y alcance del proyecto. Si el proyecto de desarrollo de algún software requiere de mucho tiempo por su complejidad se propondrá una metodología tradicional como la RUP y si a su vez, el tiempo y alcance del proyecto es relativamente corto se propondrá una metodología ágil como la XP (Programación Extrema).

La estructura del documento inicia con el planteamiento del problema que formaliza la idea de la investigación para determinar los alcances y objetivos. Posteriormente se desarrolla una parte que contiene los conceptos y definiciones de las teorías relevantes al tema en estudio especificando las fuentes bibliográficas, luego se procede a realizar una investigación de campo en el DTI para detectar, analizar y seleccionar las metodologías más adaptables a su trabajo. Con la implementación de la metodología XP y RUP se optimizarán los procesos, la administración y el tiempo en el desarrollo de las aplicaciones que se realicen en el área de software del DTI.

II PLANTEAMIENTO DEL PROBLEMA.

2.1 Antecedentes del problema de investigación

Desde el aparecimiento del software se ha procurado a desarrollarlo mediante metodologías que ajusten el proceso de desarrollo, por lo cual se crearon las metodologías pesadas o tradicionales y las metodologías ágiles. El desarrollo de los sistemas tradicionales de ciclo de vida se inició en la década de 1960 para desarrollar sistemas de negocio para las grandes empresas. La idea primaria era la de seguir el desarrollo de los sistemas de información de una manera estructurada y metódica, mediante cada una de las etapas del ciclo de vida.

Uno de los pasos más importantes dados en la industria del software fue aquel en el que se cristalizó el modelo en cascada, el cual fue determinante para la formulación del análisis estructurado.

Posteriormente los centros de investigación de empresas, Universidades entre otros, se vieron en la necesidad de optimizar los procesos de desarrollo de software por lo que surgen las metodologías de desarrollo de software ágiles o Programación Extrema. Esta metodología nació con el fin de reemplazar a las viejas metodologías de desarrollo como el famoso modelo en Cascada o Waterfall. Una de sus principales características es la de responder a los cambios más que seguir estrictamente un plan. 3

Planificar el trabajo a realizar es muy útil y las metodologías ágiles consideran actividades específicas de planificación a corto plazo.

Nuestro país posee Universidades que en la actualidad constan de centros de investigación de tecnología, los cuales desarrollan sus propios sistemas mediante metodologías de desarrollo de software. Entre las principales se encuentra la ESPOL de Quito y la Yachay conocida como Ciudad del Conocimiento.

2.2 Delimitación del Problema de Investigación.

En la actualidad las grandes instituciones académicas que se encuentran en constante expansión, se ven en la necesidad de optar por estrategias que les permitan mejorar los procesos de desarrollo de software en el área de investigación de programación.

Hay un gran número de factores que repercuten en la persona que trabaja dentro de un entorno de desarrollo software. Los cambios en el sistema operativo, el lenguaje de programación, la organización del proyecto, o los estándares establecidos para los diferentes aspectos del ciclo de vida de un proyecto pueden influir tanto en el trabajador como en la cantidad de trabajo que puede realizar.

La productividad, cómo una medida cuantitativa de la cantidad de trabajo que puede ser realizada por una persona, se puede alterar de distintas maneras, alguna de ellas tan simple como, por ejemplo, enseñar a todos los implicados en el trabajo a escribir a máquina. Este hecho, sin ir más lejos, podría tener un mayor impacto en la

productividad que el de introducir unas nuevas herramientas software o técnicas de diseño.

Por todos estos factores, el uso de una metodología de desarrollo de software es tan importante para la institución donde se la implante como para los trabajadores que la ejecuten, ya que facilita el tiempo de desarrollo, minimiza el fallo de errores y reduce los procesos.

Debido a todos estos inconvenientes la Pontificia Universidad Católica del Ecuador sede Santo Domingo, se ha visto en la necesidad de utilizar una metodología de desarrollo de software para la optimización de sus procesos. Por lo que se determinó el estudio y diseño de dos metodologías de desarrollo de software que se adapten mejor al tipo de trabajo; una metodología tradicional en caso de un proyecto de largo plazo o una metodología ágil en caso de un proyecto de corto plazo.

2.3 Justificación de la Investigación.

La implementación de una metodología de desarrollo de software en el área de programación de la PUCE SD es una necesidad, por motivo que no existe una estructuración en la manera de implementar o modificar un sistema. Los procesos no tienen un seguimiento estructurado como lo deben tener las instituciones de prestigio.

Los principales beneficios de tener una metodología que se adapte a las necesidades de la universidad, es precisamente eso, la adaptabilidad a procesos existentes pero

con un mejor funcionamiento, facilitará la corrección de errores ya que al estar trabajando con una plataforma metodológica tenemos panorama a inspeccionar cada uno de los procesos ya estructurados que proporciona este tipo de metodologías.

Otras de las principales ventajas de contar con una metodología de desarrollo son:

•

La visión del producto, todas las personas deben conocer lo que el equipo está tratando de hacer, como debe de ser el producto final, las bases de la estrategia del producto y cuando el producto será entregado.

•

Plan de desarrollo, un documento con un plan para organizar los requisitos y cuestiones relacionadas con la calidad. Los ítems de este plan deben ser lo suficientemente detallados para que los desarrolladores de software puedan desarrollar sus tareas de codificación de un modo no ambiguo. Un proceso para añadir y modificar el documento se debe especificar, como mínimo para mantener un histórico de los cambios.

•

Métricas para evaluar la calidad, este proceso no es tan solo para encontrar fallos, produce indicadores de la robustez del producto y cuanto se aproxima a las especificaciones iniciales.

2.4 Objetivos de la Investigación.

2.4.1 Objetivo General.

Elaborar una propuesta de una metodología de desarrollo de software para el departamento de Dirección de Tecnologías de la Información (DTI) de la PUCE SD

en el período 2013 para la optimización del alcance y tiempo de desarrollo de software.

2.4.2 Objetivos Específicos.

•

Realizar un análisis de los procesos existentes en el DTI y evaluarlos.

•

Seleccionar un número de metodologías ágiles y tradicionales para su estudio.

•

Identificar un conjunto de criterios para la comparación de las metodologías.

•

Documentar una propuesta en base a la metodología seleccionada.

III MARCO REFERENCIAL.

3.1 Revisión de la literatura o fundamentos teóricos.

3.1.1 Ingeniería de Software.

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software con el fin de mejorar la calidad de los productos de software, aumentar la productividad y trabajo de los ingenieros del software, facilitar el control del proceso de desarrollo de software y suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente. (Alvarez, 2007)

Según la IEEE: La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación, y mantenimiento del software.

Es el estudio de un esquema sistemático que se rige disciplinadamente al desarrollo, operación y mantenimiento de software. Abarca ciencias de la computación, matemáticas, entre otras ciencias.

En 2004, la U. S. Bureau of Labor Statistics (Oficina de Estadísticas del Trabajo de Estados Unidos) contó 760 840 ingenieros de software de computadora.

3.1.2 Metodología.

Según el autor (Gutierrez, 2011) define: Es el conjunto de procedimientos, técnicas, herramientas y un soporte documental que beneficia a los desarrolladores a realizar un nuevo software.

Una metodología es la agrupación de técnicas, procedimientos y documentos que facilitan a los desarrolladores en la realización de un nuevo software. Puede guiarse en uno o varios modelos de ciclo de vida, en otras palabras el ciclo de vida determina lo que hay que obtener a lo largo del desarrollo del proyecto pero no como realizarlo.

3.1.2.1 Metodologías de Desarrollo de Software.

En la década de 1970 aparecen modelos formales para explicar el proceso de software, como el conocido Modelo en Cascada. Los procesos que siguen el Modelo en Cascada se encuentran divididos en diferentes etapas, las cuales no pueden estar traslapadas.

Estas etapas son:

•

Requisitos de sistema.

•

Requisitos de software.

•

Análisis.

•

Diseño.

•

Codificación.

•

Pruebas.

•

Puesta en marcha.

El desarrollo iterativo e incremental ha estado presente por mucho tiempo en la aplicación de la ingeniería. En 1976 Tom Gilgs discute la práctica de la “gestión de proyectos evolutiva”, introduce por primera vez el término “evolución”.

Según (Gilbs, 2006) define: “Evolución es una técnica para producir la apariencia de estabilidad. Un sistema complejo tendrá más éxito si es implementado en pequeños pasos, y si cada paso tiene una clara medida de logro, así como la posibilidad de "retiro" a un paso exitoso anterior, en caso de fallo. Además existe la oportunidad de recibir alguna retroalimentación del mundo real antes de entregar todos los recursos destinados a un sistema, y corregir posibles errores de diseño…”

A medida que evolucionaba la Ingeniería de Software, se establecieron metodologías más formales de aplicación del diseño iterativo e incremental. Durante la década de 1990 el Desarrollo Iterativo e Incremental tuvo gran acogida en la comunidad de software, a través de varias formas, por ejemplo, el prototipado rápido, Desarrollo Rápido de Aplicaciones o RAD y el Proceso Unificado de Rational o RUP.

3.1.2.2 Cronología de Metodologías de Desarrollo de Software.

En la década de 1960 se originó el desarrollo de los sistemas tradicionales de ciclo de vida para trabajar en los sistemas de negocios de las grandes empresas de esa época. Lo principal era seguir el desarrollo de los sistemas de información estructurada y metódicamente, reiterando cada una de las etapas del ciclo de vida.

En 1970: •

Programación estructurada desde 1969.

•

Programación estructurada Jackson desde 1975.

En 1980: •

Structured System Analysis and Methodology (SSADM) desde 1980.

•

Structured Analysis and Desing Technique (SADT) desde 1980.

•

Ingeniería de la información (IE/IEM) desde 1981.

En 1990: •

Rapid application development (RAD) desde 1991.

•

Programación orientada a objetos (OOP) a lo largo de la década de los 90’s.

•

Virtual finite state machine (VFSM) desde 1990.

•

Dynamic System Development Method desarrollado en UK desde 1995.

•

Scrum (desarrollo), en la última parte de los 90’

Nuevo milenio: •

Programación extrema desde 1999.

•

Enterprise Unified Process (EUP) extensiones RUP desde 2002.

•

Rational Unified Process (RUP) desde 2003.

•

Constructionist desings methodology (CDM) desde 2004 por Kristinn R. Thórisson.

•

Agile Unified Process (AUP) desde 2005 por Scott Ambler.

3.1.2.3 Clasificación de las metodologías.

Las metodologías se clasifican según su diversidad de propuestas y diferencias en el grado de detalle. Se pueden clasificar de diferentes maneras, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos dividirlas en dos grupos:

•

Metodologías Estructuradas.

•

Metodologías Orientadas a Objetos.

Mientras que, por otra parte si consideramos su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el nombre de: •

Metodologías Tradicionales o Pesadas.

•

Metodologías Ágiles.

3.1.2.3.1. Metodologías Tradicionales.

Estas metodologías imponen una disciplina de trabajo sobre el proceso de desarrollo de software, con el fin de conseguir un software más eficiente. Para ello se hace

énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto de software. (Sommerville, 2006)

Se enfocan especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada.

Entre las principales metodologías tradicionales o pesadas podemos citar: •

RUP (Rational Unified Procces).

•

MSF (Microsoft Solution Framework).

•

Win-Win Spiral Model.

•

Iconix.

3.1.2.3.2. Metodologías Ágiles.

Según (Martinez, 2011): El desarrollo ágil de software refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos autoorganizados y multidisciplinarios.

Debido a la sociedad actual se ha adaptado un manifiesto ágil de las metodologías tradicionales, en otras palabras, tener la capacidad de proveer respuestas rápidas y ser adaptables al cambio. Estas dos cualidades, siempre han sido deseables, pero en el entorno de negocio actual resultan indispensables. Este requerimiento de agilidad en

las empresas, gobiernos y cualquier otra organización provoca que el software también deba ser desarrollado de manera ágil.

Las necesidades de un cliente pueden sufrir cambios importantes del momento de contratación de un software al momento de su entrega; y es mucho más importante satisfacer estas últimas que las primeras. Esto requiere procesos de software diferentes que en lugar de rechazar los cambios sean capaces de incorporarlos.

Los procesos ágiles son una buena elección cuando se trabaja con requisitos desconocidos o variables. Si no existen requisitos estables, no existe una gran posibilidad de tener un diseño estable y de seguir un proceso totalmente planificado, que no vaya a variar ni en tiempo ni en dinero. En estas situaciones, un proceso adaptativo será mucho más efectivo que un proceso predictivo. Por otra parte, los procesos de desarrollo adaptativos también facilitan la generación rápida de prototipos y de versiones previos a la entrega final, lo cual agradará al cliente.

Las metodologías ágiles proporcionan una serie de pautas y principios junto a técnicas pragmáticas que puede que no curen todos los males pero harán la entrega del proyecto menos complicada y más satisfactoria tanto para los clientes como para los equipos de entrega. En la Ilustración 1 se muestran los principios que rigen el desarrollo ágil.

Entre los principales principios del desarrollo ágil están: •

Bienvenida a los cambios.

•

Comunicación cara a cara.

•

La simplicidad es esencial.

•

Entregas frecuentes de software.

Ilustración 1 Principios de Manifiesto Ágil

Fuente: (Martinez, 2011) Elaborado por: Fausto Soto

Entre las metodologías ágiles más destacadas hasta el momento se pueden nombrar: •

XP (Extreme Programming).

•

Scrum.

•

Crystal Clear.

•

DSDM (Dynamic Systems Development Method).

•

FDD (Feature Driven Development).

•

ASD (Adaptive Software Development).

•

XBreed.

•

Extreme Modeling.

En el anexo 1 se muestra una comparación entre las metodologías tradicionales y las ágiles.

3.1.3 Ciclo de vida del software.

De acuerdo a la IEEE 1074: Una aproximación lógica a la adquisición, el suministro, el desarrollo, la experiencia y el mantenimiento del software.

De acuerdo a la ISO 12207-1: Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso.

El ciclo de vida de software determina el estado de las fases mediante las cuales se maneja un proyecto de desarrollo de software.

3.1.3.1 Procesos primarios del ciclo de vida del software.

Los procesos primarios en el ciclo de vida del software son: •

Adquisición, proceso global que sigue el adquiriente para obtener el producto.

•

Suministro, proceso global que sigue el suministrador para proporcionar el producto.

•

Desarrollo, proceso empleado por el suministrador para el diseño, construcción y pruebas del producto.

•

Operación, proceso seguido por el operador en el “día a día” para el uso del producto.

•

Mantenimiento, proceso empleado para mantener el producto, incluyendo tanto los cambios en el propio producto como en su entorno de operación.

•

Documentación, actividades empleadas para registrar información específica empleada por otros procesos.

•

Aseguramiento de la calidad, actividades empleadas para garantizar de forma objetiva que el producto y los procesos son conformes a los requisitos documentados y a las planificaciones.

•

Verificación, actividades empleadas para verificar el producto.

•

Validación, actividades empleadas para validar el producto.

•

Reuniones de revisión, empleadas por las dos partes para evaluar el estado del producto y de las actividades.

•

Auditorías, actividades para determinar que el proyecto cumple con los requisitos, planes y contratos.

•

Resolución de problemas, actividades para analizar y resolver problemas relativos al proyecto, sea cual sea su fuente y naturaleza.

3.1.4 Modelos para el Desarrollo de Software.

“Para resolver los problemas reales de una industria, un ingeniero de software o un equipo de ingenieros debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas” (Rosell, 2007).

Un modelo para el desarrollo de software es una representación abstracta de un proceso. Cada modelo representa un proceso desde una perspectiva particular y así proporcione información parcial sobre el proceso.

Una organización podría variar su modelo de proceso para cada proyecto, según: •

La naturaleza del proyecto.

•

La naturaleza de la aplicación.

•

Los métodos y herramientas a utilizar y los controles y entregas requeridas.

3.1.4.1 Modelos Genéricos de Desarrollo de Software.

Los Modelos de Desarrollo de software se clasifican en: •

Modelo de Cascada.

•

Prototipos.

•

Desarrollo Evolutivo e Incremental.

•

En Espiral.

•

Desarrollo basado en componentes y Métodos formales.

3.1.4.1.1. Modelo en Cascada.

Este modelo sugiere un enfoque sistemático, secuencial, para el desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

Ilustración 2 Modelo en Cascada

Fuente: http://modelo-cascada.blogspot.com/ Elaborado por: Fausto Soto

3.1.4.1.2. Modelo de Prototipos.

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. (Pressman, 2006)

Según (Pressman, 2006) aconseja: “Cuando el cliente tiene una necesidad legítima, pero está desorientado sobre los detalles, el primer paso es desarrollar un prototipo”.

Se trata de un modelo que se acopla a proyectos de poco tiempo, usando los programas adecuados y no se debe utilizar demasiados recursos.

Ilustración 3 Modelo de Prototipos

Fuente: http://ingsoft2013.blogspot.com/ Elaborado por: Fausto Soto

3.1.4.1.3. Modelo de Desarrollo Evolutivo.

El modelo incremental es la combinación del modelo en cascada con la filosofía interactiva de construcción de prototipos.

Según (Pressman, 2006) aconseja: “El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas incrementos. En general, cada incremento se construye sobre aquel que ya ha sido entregado”.

El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para una implementación completa en la fecha límite que se haya

establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas.

Ilustración 4 Modelo Incremental

Fuente: http://modelosevolutivosprocesosoftware.blogspot.com/2013/05/modelo-incremental.html Elaborado por: Fausto Soto

3.1.4.1.4. Modelo en Espiral.

El modelo en espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas del sistema diseñado. (Rosell, 2007)

Este modelo se conforma en una espiral, en el cual cada iteración representa un conjunto de actividades, comenzando por el bucle interior.

Ilustraci贸n 5 Modelo en Espiral

Fuente: http://www.codejobs.biz/es/blog/2013/06/01/modelo-de-proceso-evolutivo Elaborado por: Fausto Soto

3.1.4.1.5. Modelo de desarrollo basado en componentes.

El modelo de desarrollo basado en componentes incorpora muchas de las caracter铆sticas del modelo en espiral y exige un enfoque iterativo para la elaboraci贸n del software. Sin embargo, este modelo configura aplicaciones desde componentes preparados de software.

Ilustraci贸n 6 Modelo de desarrollo basado en componentes

Fuente: http://www.paginasprodigy.com/escomino/Sinapsys/sinapsysMetodologia.htm Elaborado por: Fausto Soto

3.1.4.1.6. Modelo de métodos formales.

“En ingeniería de software un método formal es un camino a la construcción y análisis de modelos matemáticos que permitan una automatización del desarrollo de sistemas informáticos”. (Michael G. Hinchey, 2010)

El modelo de métodos formales está formado por un conjunto de actividades que conducen a la especificación matemática del software de computadora. Permiten que un ingeniero en sistemas especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática.

Ilustración 7 Modelo de métodos formales

Fuente: http://quintomodelos.blogspot.com/ Elaborado por: Fausto Soto

3.2 Investigaciones o experiencias empíricas vinculadas con el problema de investigación.

En este tiempo de desarrollo tecnológico, las empresas grandes en general que poseen un área de sistemas se ven en la necesidad de implementar una estructuración de pasos a seguir para la realización de sus diferentes actividades.

El área de sistemas en las empresas se ha convertido en una de las fuentes principales para alcanzar un óptimo desarrollo, por lo que la mayoría de empresas han optado por la implementación de una metodología que agilice la realización de los procesos.

Particularmente la empresa Mundialo Ltda, Distribuidora de telefonía móvil de la empresa Claro, buscaba diferentes medios para agilizar sus procesos, uno de ellos del área de sistemas. Mediante una investigación en dicha compañía, se optó por una metodología que se adapte a los procesos existentes y que disminuyera el tiempo de realización de los mismos. La metodología seleccionada fue la XP, ya que ésta debido a su tipo de ejecución nos permitía no solo agilizar el trabajo sino que también nos permitió mejorarlo en base a su estructura de revisión continua y pequeñas mejoras en cada proceso. En otras palabras, no solo realizaba más rápido el trabajo, sino que también lo mejoraba a la vez.

La metodología XP es muy adaptable a las empresas debido a su forma de trabajo continuo del desarrollador con el cliente.

3.3 Hipótesis del trabajo.

Con la implementación de la metodología XP y RUP se optimizarán los procesos, la administración y el tiempo en el desarrollo de las aplicaciones que se realicen en el área de software del DTI.

IV METODOLOGÍA DE LA INVESTIGACIÓN.

El marco metodológico describe el modo de cómo se realiza nuestra investigación para la determinación de la metodología de desarrollo de software que mejor se adapte al trabajo del área de software del DTI, describiendo cada método, técnica e instrumento que se utilizó en el proyecto para obtener el conocimiento necesario.

4.1 Diseño/Tipo de investigación.

4.1.1 Contexto.

La investigación se desarrolla desde un punto de vista metodológico dentro del paradigma interpretativo, el cual trata de analizar e interpretar la realidad en un contexto y tiempo definido, mediante descripciones y detallados registros, de manera que posteriormente, en base a los antecedentes e investigaciones se tomen decisiones que mejoren los procesos de desarrollo de software del DTI en el campo de software.

La Pontificia Universidad Católica del Ecuador sede Santo Domingo, trabaja en forma normal y responsable de acuerdo a la ley de Educación, por lo que sus departamentos

de investigación deben estar en

constante modernización,

específicamente el área de software.

De acuerdo a la estructura del proyecto de investigación, se empieza a seguir los pasos correspondientes para empezar a aplicar los instrumentos de recolección de

datos para la investigación. En primera instancia se solicita autorización del departamento de Dirección Académica representada por el Dr. Marcos Santibáñez, por el Director de Escuela, el Ing. Carlos Gamarza y el por la persona encargada de la administración del DTI, el Ing. Franklin Carrasco, para realizar el “Diseño y propuesta de una Metodología de desarrollo de software para el área de programación de la Pontificia Universidad Católica del Ecuador, Sede Santo Domingo PUCE SD”.

Para el levantamiento de información en el DTI área de programación de la PUCE – SD; se realizó una entrevista al Ing. Franklin Carrasco encargado de la administración de éstos departamentos de investigación, donde se recopila, las necesidades y beneficios de poseer una metodología de desarrollo de software.

4.1.2 Tipo de la investigación.

El tipo de investigación que posee esta disertación es proyectiva, la cual consiste en el diseño y estudio de alguna metodología de desarrollo de software para el área de software del DTI en la PUCE SD.

De esta misma manera el trabajo tiene un enfoque cualitativo porque identifica el problema que existe en el DTI, obteniendo la información directamente de las personas involucradas.

4.1.3 Diseño de la investigación.

La investigación posee como objetivo principal recopilar información sobre la manera en que el equipo de programadores del DTI desarrolla algún software y que

necesidades existen para agilizar su procedimiento, con la finalidad de optimizar los procesos que conlleva la realización de un programa.

Toda investigación tiene un propósito, por tal razón se hace necesario la planificación o el diseño de los procesos que darán lugar al cumplimiento de los objetivos del estudio; en la presente investigación se procedió a seleccionar o desarrollar el diseño de investigación que se adapta a lo establecido en la guía propuesta por la PUCE SD.

Esta investigación tiene un diseño no experimental que posee las siguientes características: •

Es exploratoria debido a que se realiza a empresas que hayan implementado este tipo de proyecto para así mejorar los conocimientos referentes al tema de la disertación.

•

Es descriptiva, porque se detalla las características de algunas metodologías seleccionadas mediante la recopilación, comparación, análisis e interpretación de los datos específicos para la toma de decisiones.

4.1.4 Métodos de investigación.

Según (Luis, 2007) : “Es una especie de brújula en la que no se produce automáticamente el saber, pero que evita perdernos en el caos aparente de los fenómenos, aunque solo sea porque nos indica como no plantear los problemas y como no sucumbir en el embrujo de nuestros prejuicios predilectos”.

No se poseen reglas comunes ni precisas para la realización de una investigación en cuanto a una metodología. Por tal razón, se considera la siguiente metodología en la realización de este trabajo, los cuales ayudarán a explicar de manera general, los métodos más conocidos y prácticos de investigación.

Se determinó en este caso los siguientes métodos como los que mejor se adaptan para llevar la presente investigación:

•

Analítico

“Se distinguen los elementos de un fenómeno y se procede a revisar ordenadamente cada uno de ellos por separado. La física, la química y la biología utilizan este método; a partir de la experimentación y el análisis de gran número de casos se establecen leyes universales. Consiste en la extracción de las partes de un todo, con el objeto de estudiarlas y examinarlas por separado, para ver, por ejemplo las relaciones entre las mismas”. (Luis, 2007)

El Método analítico es aquel método de investigación que consiste en la desmembración de un todo, descomponiéndolo en sus partes o elementos para observar las causas, la naturaleza y los efectos. El análisis es la observación y examen de un hecho en particular. Es necesario conocer la naturaleza del fenómeno y objeto que se estudia para comprender su esencia. Este método nos permite conocer más del objeto de estudio, con lo cual se puede: explicar, hacer analogías, comprender mejor su comportamiento y establecer nuevas teorías.

Permitió realizar un estudio detallado de todas sus características generales y particulares, para luego definir los diferentes conceptos y componentes en el campo investigativo, así como considerar cada una de las variable motivo de estudio.

Se procedió a utilizar este método para analizar la forma en que el DTI trabaja y determinar sus ventajas y desventajas. A partir de esto se realizó un estudio de las posibles metodologías de desarrollo de software que optimizarán sus trabajos cotidianos.

•

Sintético

“Es un proceso mediante el cual se relacionan hechos aparentemente aislados y se formula una teoría que unifica los diversos elementos. Consiste en la reunión racional de varios elementos dispersos en una nueva totalidad, este se presenta más en el planteamiento de la hipótesis. El investigador sintetiza las superaciones en la imaginación para establecer una explicación tentativa que someterá a prueba”. (Luis, 2007)

Es un proceso de razonamiento que tiende a reconstruir un todo, a partir de los elementos distinguidos por el análisis; se trata en consecuencia de hacer una explosión metódica y breve, en resumen. En otras palabras debemos decir que la síntesis es un procedimiento mental que tiene como meta la comprensión cabal de la esencia de lo que ya conocemos en todas sus partes y particularidades.

Este método ayudó en la realización del análisis del trabajo investigativo, desde sus partes principales hasta sus secundarias para luego llegar a realizar la reconstrucción en una sola unidad de análisis de los procesos que se efectúan en el DTI.

•

Inductivo

“Es el razonamiento que, partiendo de casos particulares, se eleva a conocimientos generales. Este método permite la formación de hipótesis, investigación de leyes científicas, y las demostraciones. La inducción puede ser completa o incompleta”. (Luis, 2007)

Este método de igual manera permitió realizar el análisis de los contenidos establecidos en el proyecto, que principalmente es la determinación de una metodología de desarrollo de software, desde sus particularidades para luego realizar una visión global del rumbo de la investigación, tanto en el diagnóstico como en el proceso en general.

•

Deductivo

“El método deductivo consiste en la totalidad de reglas y procesos, con cuya ayuda es posible deducir conclusiones finales a partir de unos enunciados supuestos llamados premisas si de una hipótesis se sigue una consecuencia y esa hipótesis se da, entonces, necesariamente, se da la consecuencia”. (Bunge, 2006)

Este método consiste en encadenar conocimientos que se suponen verdaderos de manera tal, que se obtienen nuevos conocimientos, es decir, obtener nuevas proposiciones como consecuencias lógicas de otras anteriores.

Permitió realizar el reconocimiento de datos, el análisis y contenidos investigados sobre el proyecto desde aspectos más generales para luego determinar sus detalles en el marco teórico del proyecto de investigación. Se lo aplicó al momento de determinar la metodología de desarrollo de software que mejor se adapte al DTI.

•

Estadístico

“Un genio es alguien que descubre identidades entre hechos contradictorios”. Ernesto Sábato

La estadística es un método científico que enseña los procedimientos lógicos, prácticos y útiles a seguir para recolectar, elaborar, analizar, interpretar y presentar datos del fenómeno, expresados en detalle o síntesis a través del número, cuadro, y gráfico, con sus correspondientes notas explicativas.

Se lo aplicó en la representación de los datos analizados en la tabla de resultados, permitiéndonos una mejor visión en la tabulación, ya que los datos fueron representados en forma cuantitativa y cualitativa.

4.2 Determinación de la Población/Universo.

4.2.1 Población.

Es un conjunto de todos los elementos que estamos analizando, acerca de los cuales intentamos determinar sus conclusiones y observaciones.

4.2.2 Muestra.

Es una parte de la población a estudiar que sirve para representarla.

Para poder calcular la muestra no se aplica la fórmula ya que la población consta de cuatro personas que son: El administrador general del DTI y tres desarrolladores de software. Por lo tanto la muestra es igual a la población por ser muy pequeña.

4.3 Determinación de la muestra.

Es una parte de la población a estudiar que sirve para representarla.

4.4 Tipos de fuentes de información.

Es toda información relacionada con nuestro trabajo que nos sirve como apoyo para la elaboración de la propuesta y diseño de una metodología de software. Para el desarrollo de la metodología de investigación se seleccionó fuentes primarias como: •

Bibliográficas, dan a conocer el lugar, sitio Web, o libro de donde se saca la información, aportando la página exacta de donde es recopilada. En este caso se utilizaron libros y páginas web para la recopilación de información referente a este proyecto.

•

Hemerográficas, son textos o consultas donde puedes obtener datos, en este proyecto se utilizaron: entrevistas personales, tesis y disertaciones de grado.

4.5 Técnicas e Instrumentos de recogida de datos.

Las investigaciones en general necesitan técnicas de investigación que permite recopilar información y observar directamente el objeto de estudio. Para la investigación de este trabajo se realizó la siguiente técnica:

•

La entrevista.

Según (Pelachano, 2007) definen: “Es una relación directa entre personas por la vía oral, que se plantea unos objetivos claros y prefijados, al menos por parte del entrevistador, con una asignación de papeles diferenciales, entre el entrevistador y el entrevistado, lo que supone una relación asimétrica”.

La entrevista es una técnica de investigación que tiene como objetivo la interrogación verbal que se le realiza a la muestra seleccionada con la finalidad de obtener información necesaria para una investigación.

Las fases en la elaboración de una entrevista son: •

Describir los objetivos de la entrevista.

•

Muestreo de las personas a entrevistar.

•

Planificación del desarrollo de la entrevista.

Se empleó para obtener información mediante una serie de preguntas verbales con respuestas explícitas o detalladas en un tiempo determinado, tuvo su aplicación en el momento del diagnóstico del trabajo investigativo, proporcionando datos que nos ayudaron a establecer las bases para la propuesta de la metodología de desarrollo de software para el DTI.

En el anexo 2 ver el cuestionario de preguntas empleadas en la entrevista.

4.6 Propuestas de metodologías de desarrollo de software para el DTI.

4.6.1 Propuesta de una metodología RUP.

Se propone la utilización de la metodología de desarrollo de software RUP, en caso de que la población aumente a un número considerable en el DTI y se desee desarrollar proyectos a largo alcance.

4.6.1.1 Herramientas a utilizar para aplicar RUP.

Para la construcción de sistemas y a causa del auge de las metodologías se han elaborado herramientas que facilitan el trabajo a los desarrolladores y automatizan en gran parte del proceso. Además mejoran la calidad de los desarrollos y aumentan la productividad de los equipos de trabajo. Por lo cual, se ha optado por utilizar Rational Rose y agilizar el proceso de desarrollo de sistemas en el DTI.

4.6.1.1.1. Rational Rose.

Actualmente, muchas empresas se han extendido a la adquisición de herramientas CASE (Ingeniería Asistida por Computadora), con el fin de automatizar los aspectos claves de todo el proceso de desarrollo de un sistema, desde el inicio hasta el final.

Rational Rose es una herramienta CASE que da soporte al modelado visual mediante UML ofreciendo distintas perspectivas del sistema. Realiza soporte al Proceso Unificado de Rational para el desarrollo de los proyectos de software, desde la etapa de Ingeniería de Requerimientos hasta la etapa de pruebas. (Kendall, 2008)

Para cada una de estas etapas existe una herramienta que ayuda en la administración de los proyectos.

Rose es la herramienta de Rational para la etapa de análisis y diseño de sistemas. (Kendall, 2008)

•

Modelado de Negocios.

•

Captura de Requisitos (parcial).

•

Análisis y Diseño (completo).

•

Implementación (como ayuda).

•

Control de cambio y gestión de configuración.

Rational Rose muestra un diseño manejado por modelos que redundan en una mayor productividad de los desarrolladores, admitiendo el lenguaje de modelado UML y técnicas de modelado de objetos (OMT). También favorece el diseño centrado en casos de uso y enfocado al negocio que genera un software de mayor calidad. Utiliza un lenguaje estándar común a todo el equipo de desarrollo que facilita la comunicación. Posee capacidades de ingeniería inversa. Con Rational Rose el modelo y código permanece sincronizado en todo el ciclo de desarrollo. Además se encuentra disponible en múltiples plataformas.

4.6.1.2 Aplicación de RUP.

Al utilizar la metodología RUP en el desarrollo de un sistema se deben seguir los flujos de trabajo en los que se han agrupado las actividades.

Pasos para aplicar la metodología RUP: 1.- Modelado del negocio. 2.- Definición de los requerimientos. 2.1.- Definir requisito. 2.2.- Análisis. 2.3.- Diseño. 2.4.- Implementación. 2.5.- Prueba e integración. 3.- Modelo del Sistema. 4.- Diseño e implementación del Sistema

4.6.1.2.1. Modelado del negocio.

Es una técnica que permite comprender los procesos de negocio de la organización y se desarrolla en dos pasos:

•

Confección de un modelo de casos de uso del negocio que identifique los actores y casos de uso del negocio que utilicen los actores.

•

Desarrollo de un modelo de objetos del negocio compuesto por trabajadores y entidades del negocio que juntos realizan los casos de uso del negocio.

Modelo de casos de uso del negocio, o CUN describe los procesos de una empresa en términos de casos de uso y actores del negocio en correspondencia con los procesos del negocio y los clientes, respectivamente. El modelo de casos de uso presenta un sistema la perspectiva de su uso y esquematiza cómo proporciona valor a sus usuarios. Este modelo permite a los modeladores comprender mejor qué valor proporciona el negocio a sus actores.

Este modelo es definido a través de tres elementos: el diagrama de casos de uso del negocio, la descripción de los casos de uso del negocio y el diagrama de actividades.

Un actor del negocio es cualquier individuo, grupo, entidad, organización, máquina o sistema de información externos; con los que el negocio interactúa. Lo que se modela como actor es el rol que se juega cuando se interactúa con el negocio para beneficiarse de sus resultados.

Los actores del negocio se listan a continuación:

Tabla 1 Actores del negocio Actores

Justificación

Directivo

Solicita registros de los controles que se realizan en la entidad.

Responsabilidad

informática general (RSIG)

seguridad

Solicita expedientes de equipos, registros de controles, registros de software instalados entre otros resultados de procesos en cuestión. Es el principal beneficiado con los resultados del negocio.

Fuente: (http://ceds.nauta.es/Catal/Products/caselist2.htm) Elaborado por: Fausto Soto

Diagramas de casos de uso del negocio, para comprender los procesos de negocio se elabora el diagrama de casos de uso del negocio en el que aparece cada proceso del negocio relacionado con su actor.

Ilustración 8 Diagrama de casos de uso del negocio

Fuente: (http://ceds.nauta.es/Catal/Products/caselist2.htm) Elaborado por: Fausto Soto

Trabajadores del negocio, un trabajador del negocio es una abstracción de una persona o personas, una máquina o un sistema automatizado, que actúa en el negocio realizando una o varias actividades, interactuando con otros trabajadores del negocio y manipulando entidades del negocio. Representa un rol.

Tabla 2 Trabajadores del negocio Trabajadores

Justificación

Responsables de seguridad informática del

Encargado de realizar los diferentes registros y

área

controles que se llevan a cabo en el proceso del negocio

Informático General

Encargado de actualizar el registro de incidencias

Usuario

Es el responsable

las tecnologías,

responsable de realizar el control interno a la PC Fuente: (http://ceds.nauta.es/Catal/Products/caselist2.htm) Elaborado por: Fausto Soto

Casos de Uso, representa la forma en como un cliente (Actor) opera con el sistema en desarrollo, adem谩s de la forma, tipo y orden en como los elementos interact煤an (http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html)

Ilustraci贸n 9 Diagrama de Actividades de Casos de Uso

Fuente: (http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_XP) Elaborado por: Fausto Soto

Diagrama de Actividades, es un grafo que contiene los estados en que puede hallarse la actividad a analizar. Cada estado de la actividad representa la ejecuci贸n de una sentencia de un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo.

En resumen describe el proceso que explora el orden de las actividades que logran los objetivos del negocio.

IlustraciĂłn 10 Diagrama de Actividades â&#x20AC;&#x201C; revisar expediente

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Diagrama de clase del modelo de objetos, un modelo de objetos del negocio es un modelo interno a un negocio. Describe como cada caso de uso del negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y unidades de trabajo.

Una entidad del negocio representa algo, que los trabajadores toman, examinan, manipulan, crean o utilizan en un caso de uso del negocio. El diagrama de clases del

modelo de objeto, es un artefacto que se construye para describir el modelo de objetos del negocio, que en este caso se muestra a continuación. (Kendall, 2008)

Ilustración 11 Diagrama de clases del modelo de objetos

Fuente: (http://ceds.nauta.es/Catal/Products/caselist2.htm) Elaborado por: Fausto Soto

4.6.1.2.2. Definición de los requerimientos.

Requerimientos funcionales, permiten expresar una especificación más detallada de las responsabilidades del sistema que se propone. Ellos permiten determinar, de una manera clara, lo que debe hacer el mismo. (Kendall, 2008)

Requerimientos no funcionales, especifican cualidades, propiedades del sistema; como restricciones del entorno o de la implementación, rendimiento, dependencias de la plataforma, etc. (Kendall, 2008)

Los requerimientos no funcionales del sistema propuesto son los siguientes:

•

Requisitos de interfaz.

•

Requerimientos de seguridad.

•

Requerimientos de software.

•

Requerimientos de hardware.

4.6.1.2.3. Modelo del sistema.

Modelo de casos de uso del sistema, el modelo de casos de uso permite que los desarrolladores del software y los clientes lleguen a un acuerdo sobre los requisitos, es decir, sobre las condiciones y posibilidades que debe cumplir el sistema. Describe lo que hace el sistema para cada tipo de usuario.

Actores del sistema, un actor no es más que un conjunto de roles que los usuarios de Casos de Uso desempeñan cuando interaccionan con estos Casos de Uso. Los actores representan a terceros fuera del sistema que colaboran con el mismo. Una vez que hemos identificado los actores del sistema, tenemos identificado el entorno externo del sistema.

Tabla 3 Actores del sistema Actores Administrador

Justificación Es el encargado de gestionar las cuentas de los usuarios del sistema, realizar el control interno, gestionar los codificadores y los cuestionarios, dar bajas técnicas a equipos y gestionar los componentes de los mismos.

Encargado

Es el encargado de realizar alguna función. En este caso de gestionar los datos de las PC.

Fuente: (http://ceds.nauta.es/Catal/Products/caselist2.htm) Elaborado por: Fausto Soto

Casos de uso del sistema, la forma en que interactúa cada actor del sistema con el sistema se representa con un Caso de Uso. Los Casos de Uso son “fragmentos” de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. De manera más precisa, un Caso de Uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia.

Ilustración 12 Diagrama de casos de uso por paquetes

Fuente: (http://ceds.nauta.es/Catal/Products/caselist2.htm) Elaborado por: Fausto Soto

4.6.1.2.4. Diseño e implementación del sistema.

Una implementación según (Reynoso, 2007) es: “Una implementación es la instalación de una aplicación informática, realización o la ejecución de un plan, idea, modelo científico, diseño, especificación, estándar, algoritmo o política”.

El diseño de sistemas se define como el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema, con suficientes detalles como para permitir su interpretación y realización física.

Diseño de la Base de Datos, debido a la importancia de los datos manejados en los módulos es necesario realizar un buen diseño de la información almacenada.

Ilustración 13 Diseño de una BD

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

En el anexo 3, ver un ejemplo de diagramas de la metodología RUP.

4.6.2 Propuesta de una metodología XP.

Se propone una metodología de desarrollo de software XP, en caso de que el grupo de trabajo se mantenga de pocas personas y se desarrolle proyectos a corto plazo.

Ilustración 14 Proceso de la Metodología XP

Fuente: (http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_XP) Elaborado por: Fausto Soto

Según (Sommerville I. , 2006) La Programación Extrema (XP) es posiblemente el método ágil más conocido y ampliamente utilizado. El nombre fue acuñado por Beck (Beck 2000) debido a que el enfoque fue desarrollado utilizando buenas prácticas reconocidas, como el desarrollo iterativo, y con la participación del cliente en niveles extremos.

4.6.2.1 Herramientas a utilizar para aplicar XP.

4.6.2.1.1. Sprintometer.

Sprintometer es una aplicación simple y fácil de usar en el desarrollo ágil de proyectos. Es una herramienta para la gestión y el seguimiento de XP y Scrum. Con el fin de simplificar el intercambio de datos con programas externos todas las hojas de cálculo en Sprintometer se pueden exportar a Microsoft Excel, también se puede utilizar el formato XML para los archivos locales. (Kendall, 2008)

Algunas de las principales características de este software son: •

Seguimientos de proyectos con XP y Scrum.

•

Moderno y fácil de usar con una interfaz estilo Microsoft Office 2007.

•

Aumento de información en los gráficos.

•

Seguimiento separado de desarrollo y pruebas.

•

Seguimiento de iteraciones (Sprint) en equipos de composición variable.

•

Predicción de la desviación prevista de la iteración de la fecha de finalización.

•

Asignación de recursos a tareas e historias de usuarios.

•

Exportación para Microsoft Excel de todos los gráficos y las hojas de cálculo.

•

Exportación / Importación de los datos del proyecto en formato XML.

4.6.2.2 Pasos de la metodología XP.

Según (Sommerville I. , 2006) la metodología XP o Programación Extrema se divide en los siguientes pasos: •

Planificación Incremental, los requerimientos se registran en tarjetas de historias y las historias a incluir en una entrega se determinan según el tiempo disponible y su prioridad relativa.

Los desarrolladores de software dividen estas historias en tareas de desarrollo: •

Entregas Pequeñas, el mismo conjunto útil de funcionalidad que proporcione valor de negocio se desarrolla primero. Las entregas del sistema son frecuentes e incrementalmente añaden funcionalidad a la primera entrega.

•

Diseño Sencillo, Solo se lleva a cabo el diseño necesario para cumplir los requerimientos actuales.

•

Desarrollo previamente probado, Se utiliza un sistema de pruebas de unidad automatizado para escribir pruebas para nuevas funcionalidades antes de que estas se implementen.

•

Refactorización, Se espera que todos los desarrolladores refactoricen el código continuamente tan pronto como encuentren posibles mejoras en el código.

Para conservar el código sencillo y mantenible. •

Programación en Parejas, los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro proporcionando la ayuda necesaria para hacer siempre un buen trabajo.

•

Propiedad Colectiva, las parejas de desarrolladores trabajan en todas las áreas del sistema, de modo que no desarrollen islas de conocimiento y todos los desarrolladores posean todo el código. Cualquiera puede cambiar cualquier cosa.

•

Integración Continua, en cuanto acaba el trabajo en una tarea, se integra en el sistema entero.

Después de la integración, se deben pasar al sistema todas las pruebas de unidad. •

Ritmo Sostenible, no se consideran aceptables grandes cantidades de horas extras, ya que a menudo el efecto que tienen es que se reduce la cantidad del código y la productividad a medio plazo.

•

Cliente Presente, debe estar disponible al equipo de la XP un representante de los usuarios finales del sistema (el cliente) a tiempo completo. En un proceso de la programación externa, el cliente es miembro del equipo de desarrollo y es

responsable de formular al equipo los requerimientos del sistema para su implementación.

4.6.2.3 Fases de la metodología XP.

Según (Beck, 2006) las fases de la metodología XP son:

4.6.2.3.1. Primera Fase: Planificación del Proyecto.

Historias de Usuario, el primer paso de cualquier proyecto que siga la metodología X.P es definir las historias de usuario con el cliente. Las historias de usuario tienen la misma finalidad que los casos de uso pero con algunas diferencias: Constan de tres o cuatro líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles; no se debe hablar ni de posibles algoritmos para su implementación ni de diseños de base de datos adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la aplicación que describen. También se utilizan en la fase de pruebas, para verificar si el programa cumple con lo que especifica la historia de usuario. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha historia.

El tiempo de desarrollo ideal para una historia de usuario es entre una y tres semanas. En este caso los desarrolladores de software del DTI realizarán estas historias de usuarios con las personas de otros departamentos que requieran algún sistema informático.

Release Planning, después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en inglés "Release plan", donde se indiquen las historias de usuario que se crearán para cada versión del programa y las fechas en las que se publicarán estas versiones. Un "Release plan" es una planificación donde los desarrolladores y clientes establecen los tiempos de implementación ideales de las historias de usuario, la prioridad con la que serán implementadas y las historias que serán implementadas en cada versión del programa. Después de un "Release plan" tienen que estar claros estos cuatro factores: los objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las versiones del programa, el número de personas que trabajarán en el desarrollo y cómo se evaluará la calidad del trabajo realizado.

En esta etapa los desarrolladores de software del DTI planearán los tiempos y alcance del tipo de sistema informático solicitado.

Iteraciones, todo proyecto que siga la metodología XP se ha de dividir en iteraciones de aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que serán implementadas. También se seleccionan las historias de usuario que no pasaron el test de aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario son divididas en tareas de entre 1 y 3 días de duración que se asignarán a los programadores.

La Velocidad del Proyecto, es una medida que representa la rapidez con la que se desarrolla el proyecto; estimarla es muy sencillo, basta con contar el número de historias de usuario que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta medida cada tres o cuatro iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan".

Programación en Parejas, la metodología X.P. aconseja la programación en parejas pues incrementa la productividad y la calidad del software desarrollado.

Reuniones Diarias, es necesario que los desarrolladores se reúnan diariamente y expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y todo el mundo tiene que tener voz y voto.

4.6.2.3.2. Segunda Fase: Diseño.

Diseños Simples, la metodología X.P sugiere que hay que conseguir diseños simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseño fácilmente entendible e implementable que a la larga costará menos tiempo y esfuerzo desarrollar.

Glosarios de Términos, usar glosarios de términos y una correcta especificación de los nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores ampliaciones y la reutilización del código.

Riesgos, si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese problema.

Funcionabilidad extra, nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.

Refactorizar, refactorizar es mejorar y modificar la estructura y codificación de códigos ya creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo estos códigos para procurar optimizar su funcionamiento. Es muy común rehusar códigos ya creados que contienen funcionalidades que no serán usadas y diseños obsoletos.

4.6.2.3.3. Tercera Fase: Codificación.

Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo; su presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que serán implementadas. Antes del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen que la historia implementada cumple la funcionalidad especificada.

La codificación debe hacerse ateniendo a estándares de codificación ya creados. Programar bajo estándares mantiene el código consistente y facilita su comprensión y escalabilidad.

4.6.2.3.4. Cuarta Fase: Pruebas.

Uno de los pilares de la metodología X.P es el uso de test para comprobar el funcionamiento de los códigos que vayamos implementando. El uso de los test en X.P es el siguiente:

•

Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo específico para test.

•

Hay que someter a test las distintas clases del sistema omitiendo los métodos más triviales.

•

Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado anterior se explicó la importancia de crear antes los test que el código.

•

Un punto importante es crear test que no tengan ninguna dependencia del código que en un futuro evaluará.

•

Como se comentó anteriormente los distintos test se deben subir al repositorio de código acompañados del código que verifican.

•

Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario.

•

Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se harán test que analicen partes de las mismas, sino que las pruebas se realizarán para las funcionalidades generales que debe cumplir el programa especificado en la descripción de requisitos.

Ilustración 15 Fases de la Metodología XP

Fuente: (http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_XP) Elaborado por: Fausto Soto

En el anexo 4, Ejemplo de análisis de un proyecto XP.

V RESULTADOS

5.1 Discusión y análisis de resultados.

Para el desarrollo de aplicaciones informáticas, cualquier empresa que sea seria y que necesite optimizar gastos operativos; es necesario hacer uso de metodologías de desarrollo de software que nos servirán para mejorar los procesos inherentes al desarrollo de estas aplicaciones.

Para poder seleccionar entre las varias metodologías de desarrollo de software existentes en el mercado; se obtuvo información tanto de empresas dedicadas a desarrollo de software en la parte práctica; y de distintos libros, y páginas Web en la parte teórica. Para ello se deben analizar algunas variables que nos llevarán a la toma de decisión, de con que metodología de desarrollo se va a trabajar. Lógicamente para ello hay que analizar fundamentalmente el tiempo y la envergadura de la aplicación a desarrollar.

•

Identificación de variables para la evaluación de las metodologías a ser utilizadas en el desarrollo de software.

“Para construir o elegir una metodología se han de considerar unos requisitos deseables, que se mencionan a continuación”.

•

La metodología debe ajustarse a los objetivos.

•

La metodología debe cumplir el ciclo entero de desarrollo de software.

•

La metodología debe integrar distintas fases del ciclo de desarrollo.

•

La metodología debe incluir la realización de validaciones.

•

La metodología debe soportar la determinación de la exactitud del sistema a través del ciclo de desarrollo.

•

La metodología debe funcionar en un entorno dinámico orientado al usuario.

•

La metodología debe especificar claramente los responsables de los resultados.

•

La metodología debe poder emplearse en un entorno amplio de proyectos de software.

•

La metodología debe estar soportada por herramientas CASE.

•

La metodología debe contener actividades conducentes a mejorar el proceso de desarrollo de software.

Mediante la respectiva investigación se pudo determinar el grado de importancia para la selección de una metodología:

Se la determinó por medio de puntuaciones del 1 al 5 en donde los valores más altos representan mayor valoración, en base a tres parámetros: vista del sistema como algo cambiante, tener en cuenta la colaboración entre los miembros del equipo y características más específicas de la propia metodología como son simplicidad, excelencia técnica, resultados, adaptabilidad, etc.

Matriz de selección de metodología tradicional.

Tabla 4 Matriz Selección de metodología tradicional RUP Factores clave de éxito Puntuación La metodología debe ajustarse a

MSF Puntuación

los objetivos. La metodología debe cumplir el ciclo entero de desarrollo de software. La metodología debe integrar distintas fases del ciclo de desarrollo. La metodología debe incluir la realización de validaciones. La metodología debe soportar la determinación de la exactitud del sistema a través del ciclo de desarrollo. Fuente: Investigación por el autor Elaborado por: Fausto Soto

Matriz de selección de metodología ágil.

Tabla 5 Matriz de Selección de metodología ágil XP

SCRUM

Factores clave de éxito

Puntuación

La metodología debe ajustarse a

De acuerdo a la matriz de evaluación de metodologías se determinó que la mayor puntuación se presentó en los procesos de desarrollo ágil. Esto obedece a que actualmente las instituciones y empresas buscan optimizar en tiempo y alcance el desarrollo de software.

Dentro de las metodologías de desarrollo ágil, los procesos que obtuvieron la mayor ponderación es la XP, sin embargo esta metodología es aplicada para proyectos con diferencias de duración, es decir la XP es para proyectos cortos y que se deseen implementar con rapidez.

Dentro de las metodologías convencionales o tradicionales la que obtuvo mayor puntuación es la RUP debido a su adaptabilidad en diferentes niveles de aptitud y diferentes tamaños de proyectos.

5.2 Conclusiones.

•

Las metodologías de desarrollo de software continúan evolucionando y actualizándose por lo que cada vez se adecúan o cubren de mejor manera las necesidades y requerimientos de los proyectos de esta índole.

•

Se identificaron distintas metodologías usadas para el desarrollo de software, con sus respectivas características, obteniendo las ventajas y desventajas que cada una de ellas presentan para evaluarlas y elegir las adecuadas.

•

Es necesario implementar una metodología de desarrollo de software en el DTI para la optimización de sus procesos.

•

Los factores a ser evaluados en cada metodología pueden ser elaborados por el grupo de desarrollo en función a las características que puede tener un proyecto en específico.

5.3 Recomendaciones.

•

Si el número de personal encargado para el desarrollo de software es pequeño, la metodología a ser aplicada debería ser una de tipo ágil como la XP que se adapta más a grupos pequeños mientras que, si el número de personal encargado para el desarrollo de software es grande y su alcance y tiempo son extensos, la metodología a ser aplicada debería ser una de tipo tradicional o pesada como la metodología RUP.

•

Se recomienda capacitar a los Desarrolladores de Software en las dos metodologías a utilizar en el DTI.

•

Es factible seguir cada uno de los pasos de la metodología a utilizar en un proyecto de desarrollo de software, para evitar errores y agilizar el proceso.

FUENTES DE REFERENCIA

Bibliografias

•

Alvarez, J. (2007). Ingeniería de Software. España: CENGAGE Learning.

•

Beck, K. (2006). Metodología XP. New York: Mc Graw Hill Companies. Inc.

•

Bunge, M. (2006). La investigación científica. México: Pearson Prentice Hall.

•

Gilbs, T. (2006). Software Metrics. New York.

•

Gutierrez, D. (2011). Métodos de Desarrollo de Software.

•

Jacobson, K. (2008). Proceso Unificado. EEUU: Companies. Inc.

•

Kendall, K. &. (2008). Analisis Y Diseño De Sistemas. México: Pearson Educación Hispanoramericana S.A.

•

Luis, L. C. (2007). Método e hipótesis científicas. España: Creaciones Copyright, S. L.

•

Martinez, G. (2011). Coding, quality check and documentation .

•

Michael G. Hinchey, J. P. (2010). Formal Methods. In Philip A. Laplante (ed.).

•

Pelachano, S. y. (2007). Malaga: Vértice.

•

Pressman. (2006). Modelos de Proceso. EEUU

•

Reynoso, C. (2007). Métodos Heterodoxos en Desarrollo de Software. Madrid: DYKINSONG, S.L. Melendez Valdés, 61- 28015 Madrid.

•

Rosell, B. (2007). Modelos del proceso del software.

•

Sommerville, I. (2006). Ingeniería del software. Madrid.

Lincografías

•

Anónimo.

Recuperado

Octubre

2010,

http://ceds.nauta.es/Catal/Products/caselist2.htm. (s.f.). •

Patricio Salinas. Casos de Uso (Use Case). Recuperado el 30 de febrero de 2009, de http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html. (s.f.).

•

Wikipedia.

Recuperado

noviembre

2007,

http://wiki.monagas.udo.edu.ve/index.php/Metodolog%C3%ADas_SCRUM_y_ XP.(s.f.) •

Software Engineering Institute. Recuperado el 23 de marzo del 2007, de http://www.sei.cmu.edu/cmm/obtain.cmm.html. (s.f.).

ANEXOS

Anexo 1 Comparación entre las metodologías tradicionales y las ágiles. Metodologías Ágiles

Metodologías Tradicionales

Basadas en heurísticas provenientes de prácticas de producción de código.

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo.

Especialmente preparados para cambios durante

Cierta resistencia a cambios.

el proyecto. Impuestas internamente (Por el equipo).

Impuestas externamente.

Proceso menos controlado, con pocos principios.

Proceso

mucho

más

controlado,

con

numerosas políticas y normas. No existe contrato tradicional o al menos es

Existe un contrato prefijado.

bastante flexible. El cliente es parte del equipo de desarrollo.

El cliente interactúa con el equipo de desarrollo mediante reuniones.

Grupos pequeños (<10 integrantes) y trabajando

Grupos grandes y posiblemente distribuidos.

en el mismo sitio. Pocos artefactos, más artefactos.

Pocos roles, más roles.

Pocos roles.

Más roles.

Menos énfasis en la arquitectura del software.

La arquitectura del software es esencial y se expresa mediante modelos.

Anexo 2 Entrevista

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS Entrevista

OBJETIVO: El motivo de la entrevista es obtener información sobre la forma en que el DTI gestiona sus trabajos y proyectos cotidianamente.

Entrevista realizada al encargado del DTI. 1.- ¿Cuántas personas trabajan en el àrea de software del DTI? 2.- ¿Qué metodología utilizan en el desarrollo de sus proyectos? 3.- ¿Qué proyectos de desarrollo de software están realizando actualmente? 4.- ¿Por qué se dio el requerimiento de la implementación de una metodología de desarrollo de software para el DTI? 5.- ¿En qué beneficiaría la implementación de una metodología de desarrollo de software en el DTI?

Anexo 3 Ejemplo de Análisis de un proyecto con metodología RUP

Diagrama de Actividades del Caso de Uso

Ilustración 16 Diagrama de Actividades - Solicitar reportes

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 17 Diagrama de Actividades - Revisar expediente de equipo

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 18 Diagrama de Actividades - Solicitar registro

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 19 Diagrama de Actividades - Solicitar registro de software

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 20 Diagrama de Actividades - Realizar control interno

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 21 Diagrama de Actividades - Solicitar historial de incidencias

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Prototipos – diseños de Pantalla Ilustración 22 Control Interno

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 23 Gestionar Historial de incidencias

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 24 Registro de control de acceso

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 25 Diagrama de Clases

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Ilustraci贸n 26 Dise帽o de una BD

Fuente: (Kendall, 2008) Elaborado por: Fausto Soto

Anexo 4 Ejemplo de Análisis Funcional y de Riesgos de un proyecto con metodología XP

Módulos del proyecto: •

Módulo de Autenticación

•

Módulo de Inventario

•

Módulo de Préstamo y Devolución

•

Módulo de Seguridad y Administración

•

Módulo de Reportes

Historias de Usuario. Tabla 6 Historias de Usuario - autenticación

Historia de Usuario Número: 1

Usuario: Secretaria o Encargado

Nombre historia: Verificación de autenticación (estudiante) Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 4

Iteración asignada: 1

Programador responsable: Por Asignar Descripción: Se verifica o autentica si la persona que solicita el préstamo se encuentre matriculado en la PUCE SD y por lo tanto conste en la base de datos.

Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 7 Historias de Usuario - inventario de activos

Historia de Usuario Número: 2

Usuario: Secretaria o Encargado

Nombre historia: Inventario de activos disponibles en la BD (estudiante) Prioridad en negocio: Alta

Riesgo en desarrollo: Baja

Puntos estimados: 3.5

Iteración asignada: 1

Programador responsable: Por Asignar Descripción: Accede a la base de datos mostrando los activos disponibles para la realización del préstamo.

Observaciones:

Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 8 Historias de Usuario - selección de préstamos

Historia de Usuario Número: 3

Usuario: Secretaria o Encargado

Nombre historia: Selección de préstamos a procesar (estudiante) Prioridad en negocio: Alta

Riesgo en desarrollo: Baja

Puntos estimados: 3.5

Iteración asignada: 1

Programador responsable: Por Asignar Descripción: Accede a la interfaz de préstamos y se verifica si existe el producto, en caso de existir se procede al proceso de préstamo.

Observaciones:

Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 9 Tareas de Usuario - diseño interfaz

Tarea Número tarea: 1

Número historia: 3

Nombre tarea: Diseño interfaz selección de préstamo Tipo de tarea : Desarrollo

Puntos estimados: 0.5

Fecha inicio: 02/06/14

Fecha fin:

02/06/14

Programador responsable: Por Asignar Descripción: Se diseñara una ventana que muestre un listado con los todos los activos. Se deberá habilitar además de los botones habituales un botón para seleccionar el préstamo y otro para mostrar los artículos. Por lo tanto, también se diseñará otra ventana que se abrirá a partir de está en el cual se mostrarán los artículos que tiene asociados un préstamo o en concreto. Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 10 Tareas de Usuario - listado de préstamos

Tarea Número tarea: 2

Número historia: 2

Nombre tarea: Listado de todos los préstamos de la BD Tipo de tarea : Desarrollo

Puntos estimados: 0.5

Fecha inicio: 03/06/14

Fecha fin: 04/06/14

Programador responsable: Por Asignar

Descripción: Se muestran en el dw apropiado todos los préstamos que actualmente se encuentren en la BD así como el estado en el que se encuentra cada préstamo: completo/incompleto, en el almacén Si/No. Se habilitarán dos botones. Uno para mostrar los artículos de un préstamo determinado. Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 11 Historias de Usuarios - Administrador

Historia de Usuario Número: 4

Usuario: Administrador o Superusuario

Nombre historia: Seguridad y Administración de datos Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 3.5

Iteración asignada: 2

Programador responsable: Por Asignar Descripción: Existirá restricción de usuarios según su rol.

Observaciones:

Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 12 Historias de Usuario - secretaría

Historia de Usuario Número: 5

Usuario: Secretaria o Encargado

Nombre historia: Reportes Prioridad en negocio: Alta

Riesgo en desarrollo: Baja

Puntos estimados: 3.5

Iteración asignada: 2

Programador responsable: Por Asignar Descripción: Se imprimirán reportes según la necesidad del usuario. Observaciones:

Fuente: Por el autor Elaborado por: Fausto Soto

Release Planning.

Nombre de la tarea

Tabla 13 Tareas Comienzo

Fin

ANÁLISIS

Lun 17/06/14

Lun 24/06/14

Mar 25/06/14

Vie 25/07/14

Lun 28/07/14

Lun 26/08/14

Mar 27/08/14

Mar 03/09/14

Mie 04/09/14

Mar 17/09/14

Planteamiento del problema

Requerimientos(Historias

Usuario) Selección de Herramientas

DISEÑO Diseño de Diagrama de Objetos Diseño de Diagrama de Base de Datos Diseño de Diagrama de Clases Diseño

Diagrama

Interfaces IMPLEMENTACIÓN Codificación del software

Pruebas

INSTALACIÓN Instalación de equipos

Instalación del sistema

EVALUACIÓN Manual Técnico

Manual de Usuario

Fin del proyecto Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 14 Requerimientos N° 1

REQUERIMIENTOS

RESPONSABLES

El sistema funcionara en cualquier plataforma mediante la

Analista y Desarrolladores

Web 2

El sistema debe ser desarrollado bajo HTML5, lenguaje de

Analista y Desarrolladores

programación PHP 3

El gestor de base de datos será POSTGRE SQL

Analista y Desarrolladores

El sistema utilizara RUBY RAIS como framework

Jefe de Proyecto

El sistema utilizara la librería FPDF para los reportes

Desarrolladores

necesarios 6

El sistema utilizara iconos de acceso rápido

Desarrolladores

Entregar manuales (Usuario y Técnico), script BDD

Jefe de Proyecto

El sistema debe ser parametrizable

Analista y Desarrolladores

Validar los tipos de datos en cada formulario

Sistema

El sistema debe controlar el acceso al sistema (login)

Sistema

El sistema tendrá un menú principal

Desarrolladores

Las contraseñas de usuarios de sistema serán encriptados

Sistema

El sistema debe permitir al administrar usuarios

Administrador

El sistema debe administrar las dependencias con sus

Administrador

respectivos usuarios 15

El sistema permite administrar el inventario de artículos

Administrador

El sistema facilita en el préstamo de los artículos

Administrador

El Sistema debe llevar un historial de los movimientos de

Sistema

items similar a un kardex 18

Visualizar lista negra

Visualizar

prestamos

Administrador realizados

durante

periodo

Administrador

determinado 20

Visualizar el historial de entregas de los artículos

Administrador

El sistema debe permitir crear reportes

Administrador

Fuente: Por el autor Elaborado por: Fausto Soto

Diseño. Riesgo del Proyecto Amenaza el plan de proyecto

Ejemplos: Los posibles riesgos son del presupuesto, planificación, recursos, personal.

Consecuencia: Retraso en la planificación

Riesgo técnico Amenaza la calidad del software.

Ejemplos: Mal idea de los requerimientos, utilización de aplicaciones o herramientas obsoletas.

Consecuencia: Insatisfacción del Cliente.

Riesgo de Negocio Amenaza la factibilidad del Software

Consecuencia: Construir un producto y no cumpla la meta de la empresa, perder presupuesto construir un producto que nadie quiera usar y perder el apoyo de alta gerencia.

IDENTIFICACIÓN

Tabla 15 Descripción de los Riesgos DESCRIPCIÓN DEL CATEGORÍA

CONSECUENCIA

RIESGO R1

Mal diseño de la BDD

Retraso en la entrega del Proyecto

Falta de información por

parte de los usuarios R3

Retraso en el análisis del Proyecto

Equipos de actualizados

Construcción del programa en

plataforma

inadecuada R4

Interfaces no adecuados

Difícil manejo para los usuarios

Usuarios finales se rehúsan

a usar el sistema R6

Perdida de sistema en venta

Cambio de jefe de proyecto

Demora en el desarrollo del sistema

Inconformidad

las

salidas de información R8

Reestructurar nuevamente el sistema

Mala planificación en el

Demora en el análisis

Realizar

tipo de desarrollo R9

Inconformidad

desarrolladores R10

codificación

Inadecuado ambiente de

trabajo R11

mal

cumplir

con

los

requerimientos

Mala distribución de tareas

Sistema sin concordancia

No facilitar la información

a los desarrolladores R12

Falta de experiencia en el manejo de Herramientas

de la forma adecuada

CASE R13

Desinterés

actualizar

componentes

Sistema obsoleto

Pérdida

programación R14

El sistema no cumple con los

requerimientos

del

Tiempo

Recursos

cliente R15

sistema

parametrizado totalidad

no en

está su

No concuerda con los parámetros

R16

Interfaces

del

utilizan

sistema

colores

muy

por

usuario al ver colores que

fogosos. R17

Inconformidad

afectan a la vista

Falta de experiencia en la

herramienta de desarrollo

Pérdida

Tiempo

Recursos

del sistema R18

Salida de mensajes que no ajustan

con

los

cumple

con

los

requerimientos

requerimientos especificados R19

Poco conocimiento con el

gestor de la base de datos

Capacitación al personal y pérdida

recursos

tiempo R20

Utilización

muchos

componentes

los

El usuario no entiende muy bien la aplicación

formularios R21

El sistema se demora al cargar

formulario

mal

administradas a la base de

principal R22

Conexiones

datos

El sistema no cuenta con

Falta de análisis

Falta de documentación y

excepciones R23

El sistema no tiene el versiona miento adecuado

R24

Los

formularios

análisis y

componentes del sistema no

tienen

Pérdida

Tiempo

Recursos

tamaño

apropiado R25

La seguridad en el sistema

Fácil ingreso al sistema

Sistema sin concordancia

y permisos de acceso no están

controlados

correctamente R26

La validación de datos en los formularios del sistema no

correctamente Fuente: Por el autor Elaborado por: Fausto Soto

realizan

Tabla 16 An谩lisis de Riesgos Probabilidad Impacto

Identificaci贸n %

Valor

Probabilidad

Valor

Impacto

Baja

Moderado

Alta

Exposici贸n del riesgo Valor

Exposici贸n 2

Baja

Critico

Alta

Critico

Alta

Baja

Bajo

Baja

Media

Moderado

Media

Baja

Bajo

Baja

Media

Moderado

Media

Baja

Moderado

Baja

Media

Moderado

Media

Bajo

Baja

Bajo

Baja

Alta

Moderado

Alta

Media

Moderado

Media

Baja

Critico

Media

Baja

Moderado

Baja

Bajo

Baja

Alta

Alto

Alta

Baja

Moderado

Alta

Media

Alto

Alta

Baja

Bajo

Baja

Media

Moderado

Media

Moderado

Media

Alto

Alta

Baja

Bajo

Baja

Media

Alto

Alta

Media

Moderado

Media

Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 17 Criterio de Valoración de Probabilidad RANGO DE PROBABILIDAD DESCRIPCIÓN

VALOR

1% - 33%

Baja

34% - 66%

Media

67% -100%

Alta

Fuente: Por el autor Elaborado por: Fausto Soto

Impuesto

Impacto en costo

Tabla 18 Impuesto del Riesgo Retraso Impacto técnico

Bajo

<1%

1 semana

Valor

Ligero impacto en el desarrollo

del SW Moderado

<5%

2 semanas

Moderado

impacto

Severo impacto en el desarrollo

desarrollo del SW Alto

<10%

1 mes

del SW Crítico

>10%

>1 mes

Proyecto no puede ser

Fuente: Por el autor Elaborado por: Fausto Soto

EXPOSICIÓN RIESGO

Tabla 19 Exposición del Riesgo VALOR

COLOR

Baja

1o2

Verde

Media

3o4

Amarillo

Alta

mayor a 6

Rojo

Fuente: Por el autor Elaborado por: Fausto Soto

Proba/ Impacto

Tabla 20 Prioridad del Riesgo Bajo 1 Moderado 2

Alto 3

Critico 4

Alta =3

Media = 2

Baja =1

Fuente: Por el autor Elaborado por: Fausto Soto

Tabla 21 Exposición del Riesgo PROBABILIDAD IMPACTO EXPOSICIÓN 3

Fuente: Por el autor Elaborado por: Fausto Soto