UNIVERSIDAD NACIONAL DE TRUJILLO Facultad de Ciencias Físicas y Matemáticas
Escuela Profesional de Informática
Diseño de una metodología mixta de desarrollo de software para la automatización de los procesos de las pymes peruanas
TESIS
PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO INFORMÁTICO
AUTOR(ES): Barrantes Goicochea Josue David Cabrera Sánchez Cristian Steve ASESOR: Mg. Castillo Diestra Carlos Enrique
TRUJILLO - PERÚ 2022
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Dedico esta tesis a:
A mis padres Luis y Lilia, y a mi hermana Vanessa, quienes, con su amor, pa- ciencia y esfuerzo me han permitido llegar a cumplir un sueño más, gracias por inculcar en mí, el esfuerzo y valentía, de no temer las adversidades porque Dios está conmigo siempre.
Josue D. Barrantes Goicochea
A mis padres, quienes me inculcaron a tener fe y amor a Dios y me formaron con valores a lo largo de mi vida, gracias por creer mí, en todo lo que pude lograr con esfuerzo, fe y dedicación.
A mis hermanos, por su apoyo incondicional, en todo momento y circunstancia, gracias por ser mi gran motivación para ser parte de esta prestigiosa universidad.
Cristian S. Cabrera Sánchez
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Agradecimientos
Agradecemos a Dios todopoderoso quien nos bendice todos los días y nos ilu- minó para la realización de esta tesis.
A nuestros profesores del Departamento de Informática, quienes nos impartie- ron los conocimientos fundamentales para nuestra formación como profesionales.
A nuestro asesor Ing. Carlos Castillo Diestra, quien nos brindó su apoyo moral y profesional, que fué indispensable para la realización de esta tesis.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
En la ciudad de Trujillo, en la Sala Virtual https://meet.google.com/agz-qcxr-osu, siendo las 11 horas, del día miércoles 23 de marzo de 2022, se reunió el Jurado conformado por:
Presidente (a): IRIS AUREA CRUZ FLORIAN Secretario (a): JOSE ARTURO DIAZ PULIDO
Miembro: CARLOS ENRIQUE CASTILLO DIESTRA Para el acto de: (Marcar el que corresponde)
1. (X ) Sustentación de Tesis intitulada:
“DISEÑO DE UNA METODOLOGÍA MIXTA DE DESARROLLO DE SOFTWARE PARA LA AUTOMATIZACIÓN DE LOS PROCESOS DE LAS PYMES PERUANAS”
Con el fin de optar al Título Profesional de INGENIERO INFORMATICO (a) por el/la graduado/a (os, as):
Br. BARRANTES GOICOCHEA JOSUE DAVID Br. CABRERA SANCHEZ CRISTIAN STEVE
Después de concluido el acto de sustentación y luego de que el (los) mencionado(s) ha (n) dado respuesta a las preguntas respectivas, el Jurado Evaluador, declara:
1. ( ) Aprobado, con mención honrosa. La cual amerita su publicación 2. ( X ) Aprobado, por unanimidad
3. ( ) Aprobado, por mayoría 4. ( ) Desaprobado
Según el Art. 13º del Reglamento de Grados y Títulos de la Escuela de Informática, Facultad de Ciencias Físicas y Matemáticas de la Universidad Nacional de Trujillo.
Por lo tanto el, los/la/las Graduado (a, as, s) se encuentra (n) expeditos ( X ), impedidos ( ) para realizar los trámites correspondientes para la obtención del Título Profesional de INGENIERO (a) INFORMÁTICO
Siendo las 12:23 pm, se dio por terminado el acto de sustentación.
Presidente (a) Secretario(a)
Iris Aurea Cruz Florian José Arturo Díaz Pulido
Miembro
Carlos Enrique Castillo Diestra
PARA OPTAR EL TÍTULO DE INGENIERO INFORMÁTICO
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Resumen
La presente tesis tuvo como objetivo el diseño de una metodología mixta de desarrollo de software enfocada a desarrollar productos de software que se ajusten a los requerimientos de las PYMES. Esta investigación está basada en el uso de la técnica documental, con la cual se recopilaron artículos científicos, libros, revistas y otras publicaciones en internet. Luego se usó el método analítico-sintético, con el fin de descomponer todo lo recopilado en partes, analizar cada una de estas y posteriormente consolidarlas en un compendio, que es en el cual se basa esta te- sis. Se investigaron algunas metodologías ágiles y tradicionales de desarrollo de software propuestas para pymes. Al contar con las metodologías investigadas y en base al muestreo no probabilístico por conveniencia, se seleccionó a la metodolo- gía ágil de desarrollo de software XP y a la metodología tradicional de desarrollo de software MSF, las cuales se propusieron a proyectos pequeños y medianos, que concuerdan con los proyectos de las pymes. Posteriormente, se procedió a diseñar la metodología mixta de desarrollo software en base al compendio y a algunas de las técnicas de las metodologías seleccionadas. La metodología diseñada se aplicó exitosamente a un caso de estudio de una pyme, con la finalidad de ejemplificar su uso. Por último, la metodología fue evaluada mediante juicios de expertos, que consistió en aplicar un cuestionario a profesionales en desarrollo de software, los valores obtenidos a partir de esta evaluación expresan la gran importancia de esta metodología.
Palabras claves: Diseño, metodología mixta, PYMES, procesos, automatización.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Abstract
The objective of this thesis was to design a mixed software development metho- dology focused on developing software products that meet the requirements of SMEs. This research is based on the use of the documentary technique, with which scientific articles, books, magazines and other publications on the internet were collected. Then the analytical-synthetic method was used, in order to break down everything compiled into parts, analyze each of these and later consolidate them into a compendium, which is the one on which this thesis is based. Some agile and traditional software development methodologies proposed for SMEs were inves- tigated. By having the investigated methodologies and based on non-probabilistic convenience sampling, the agile XP software development methodology and the traditional MSF software development methodology were selected, which were proposed to small and medium projects, which are consistent with SME projects.
Subsequently, the mixed software development methodology was designed based on the compendium and some of the techniques of the selected methodologies. The designed methodology was successfully applied to a case study of an SME, in order to exemplify its use. Finally, the methodology was evaluated through expert judg- ments, which consisted of applying a questionnaire to professionals in software development, the values obtained from this evaluation express the great importance of this methodology.
Keywords: Design, mixed methodology, SMEs, processes, automation.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Índice de figuras
2.1. Tipos de sistema de gestión informatizado (software) que tiene la empresa, 2014 . . . 10
2.2. Uso de página web, redes sociales y Linkedin, 2014 . . . 10
2.3. Empresas que tienen acceso a internet, intranet y extranet, 2014 . . . 11
2.4. Ejemplo de un Diagrama de Caso de Uso . . . 14
2.5. Diagrama de Caso de Uso . . . 15
2.6. Ejemplo de un Diagrama de Caso de Uso . . . 15
2.7. Atributo public de una clase . . . 16
2.8. Atributo private de una clase . . . 16
2.9. Atributo protected de una clase . . . 16
2.10. Atributo public de una clase . . . 17
2.11. Atributo private de una clase . . . 17
2.12. Atributo protected de una clase . . . 17
2.13. Ejemplo de una relación de herencia entre clases . . . 18
2.14. Ejemplo de una relación de composición entre clases . . . 18
2.15. Ejemplo de una relación de agregación entre clases. . . 19
2.16. Ejemplo de una relación de dependencia o instanciación entre clases . . . 19
2.17. Ejemplo de una relación de asociación entre clases . . . 20
2.18. Ejemplo de un diagrama de secuencia . . . 20
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.19. Ejemplo de un diagrama de despliegue. . . 21
2.20. Comparación entre metodologías ágiles y tradicionales . . . 25
2.21. Extreme Programming (XP) . . . 26
2.22. Modelo de equipo de trabajo - MSF . . . 34
2.23. Fases de la metodología MSF . . . 35
2.24. Ciclo de vida MSF . . . 36
2.25. Gestión del riesgo - MSF . . . 37
2.26. Gestión de cambios - MSF . . . 37
3.1. Secuencia de la Metodología. . . 47
3.2. Historia de Usuario. . . 49
3.3. Tabla de estimación de horas por historia de usuario . . . 51
3.4. Tabla de estimación de horas de actividades adicionales . . . 51
3.5. Formato de cronograma del proyecto . . . 52
3.6. Estructura de la portada del acuerdo de entendimiento . . . 53
3.7. Estructura del contenido del acuerdo de entendimiento . . . 54
3.8. Formato de acta de reunión . . . 57
3.9. Historia de usuario del módulo de servicios. . . 61
3.10. Historia de usuario del módulo de clientes. . . 61
3.11. Historia de usuario del módulo de proveedores. . . 62
3.12. Historia de usuario del módulo de registro de ingresos en base a los servicios. . . 62
3.13. Historia de usuario del módulo de registro de la compra de productos. . . 63
3.14. Historia de usuario del módulo de reporte gerencial . . . 63
3.15. Estimación de tiempo de horas para la historia de usuario: Módulo de servicios . . . . 64
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
3.16. Estimación de tiempo de horas para la historia de usuario: Módulo de clientes. . . 64
3.17. Estimación de tiempo de horas para la historia de usuario: Módulo de proveedores . . 64
3.18. Estimación de tiempo de horas para la historia de usuario: Módulo de registro de los ingresos en base a los servicios . . . 65
3.19. Estimación de tiempo de horas para la historia de usuario: Módulo de registro de la compra de productos . . . 65
3.20. Estimación de tiempo de horas para la historia de usuario: Módulo de reporte gerencial 65 3.21. Estimación de horas de actividades adicionales. . . 66
3.22. Cronograma del proyecto. . . 67
3.23. Portada del acuerdo de entendimiento . . . 68
3.24. Página 1 del acuerdo de entendimiento. . . 69
3.25. Página 2 del acuerdo de entendimiento. . . 70
3.26. Página 3 del acuerdo de entendimiento. . . 71
3.27. Página 4 del acuerdo de entendimiento. . . 72
3.28. Página 5 del acuerdo de entendimiento. . . 73
3.29. Diagrama de casos de uso según los requerimientos de las historias de usuario . . . . 74
3.30. Diagrama de clases del caso de estudio . . . 75
3.31. Diagrama de secuencia de inicio de sesión . . . 76
3.32. Diagrama de secuencia de servicios . . . 77
3.33. Diagrama de secuencia de clientes . . . 78
3.34. Diagrama de secuencia de proveedores . . . 79
3.35. Diagrama de secuencia de ingresos . . . 80
3.36. Diagrama de secuencia de compras . . . 81
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
3.37. Diagrama de secuencia de reporte gerencial . . . 82
3.38. Diagrama de despliegue . . . 83
3.39. Acta de reunión de la presentación del módulo de servicios . . . 84
3.40. Acta de reunión de la presentación del módulo de clientes . . . 85
3.41. Acta de reunión de la presentación del módulo de proveedores . . . 86
3.42. Acta de reunión de la presentación del módulo de registro de los ingresos en base a los servicios . . . 87
3.43. Acta de reunión de la presentación del módulo de registro de la compra de productos . 88 3.44. Acta de reunión de la presentación del módulo de reporte gerencial . . . 89
3.45. Acta de reunión de la capacitación sobre el uso del prototipo del sistema a un grupo de usuarios . . . 90
3.46. Acta de reunión de la última capacitación sobre el uso del sistema a los usuarios . . . 92
3.47. Acta de reunión de despliegue del sistema en los servidores de la pyme . . . 93
4.1. Sección 1 de la estructura del cuestionario de evaluación de juicio de expertos. . . 98
4.2. Sección 2 de la estructura del cuestionario de evaluación de juicio de expertos. . . 99
4.3. Primera parte de la sección 3 de la estructura del cuestionario de evaluación de juicio de expertos . . . 100
4.4. Segunda parte de la sección 3 de la estructura del cuestionario de evaluación de juicio de expertos . . . 101
4.5. Tercera parte de la sección 3 de la estructura del cuestionario de evaluación de juicio de expertos . . . 102
4.6. Gráfico de resumen de respuestas a la primera pregunta del cuestionario . . . 103
4.7. Gráfico de resumen de respuestas a la segunda pregunta del cuestionario . . . 104
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
4.8. Gráfico de resumen de respuestas a la tercera pregunta del cuestionario . . . 104
4.9. Gráfico de resumen de respuestas a la cuarta pregunta del cuestionario . . . 105
4.10. Gráfico de resumen de respuestas a la quinta pregunta del cuestionario . . . 105
4.11. Gráfico de resumen de respuestas a la sexta pregunta del cuestionario . . . 106
4.12. Gráfico de resumen de respuestas a la séptima pregunta del cuestionario . . . 106
4.13. Gráfico de resumen de respuestas a la octava pregunta del cuestionario . . . 107
4.14. Gráfico de resumen de respuestas a la pregunta de confirmación de pertenencia de las respuestas brindadas del cuestionario . . . 107
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Índice de tablas
3.1. Técnicas empleadas durante el ciclo de la metodología diseñada. . . 42 3.2. Consideraciones para la estimación de fechas del desarrollo de cada historia de usuario. 50
4.1. Escala de Likert. . . 98 4.2. Lista de expertos que completaron el cuestionario. . . 103 4.3. Suma, valor porcentual y promedio de los puntajes obtenidos de las respuestas a las
preguntas del cuestionario . . . 108 4.4. Valor promedio, porcentual y de desviación estándar de la evaluación de la metodología 108
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Índice general
Dedicatoria I
Agradecimientos II
Resumen III
Abstract IV
Índice de Figuras IX
Índice de Tablas X
1. Introducción 1
1.1. Justificación de la investigación . . . 3
1.2. Formulación del problema . . . 3
1.3. Hipótesis . . . 3
1.4. Objetivos . . . 4
1.4.1. General . . . 4
1.4.2. Específicos . . . 4
1.5. Estructura de la tesis . . . 4
2. Materiales y métodos 6
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.1. Marco Teórico . . . 6
2.1.1. La pymes . . . 6
2.1.1.1. Definición . . . 6
2.1.1.2. Características . . . 7
2.1.1.3. Uso de Tecnologías de Información y Comunicaciones . . . 8
2.1.1.4. Uso de software, redes sociales e internet . . . 9
2.1.2. Ingeniería de software . . . 11
2.1.2.1. Definición de Ingeniería . . . 11
2.1.2.2. Definición del Software . . . 12
2.1.2.3. Definición de la Ingeniería de Software . . . 12
2.1.2.4. Lenguaje Unificado de Modelado (UML) . . . 12
2.1.2.4.1. Diagrama de Caso de Uso . . . 13
2.1.2.4.2. Diagrama de Clases . . . 14
2.1.2.4.3. Diagrama de Secuencia . . . 20
2.1.2.4.4. Diagrama de Despliegue . . . 21
2.1.3. Metodologías de desarrollo de software . . . 22
2.1.3.1. Definición de metodología . . . 22
2.1.3.2. Metodologías Tradicionales . . . 23
2.1.3.3. Metodologías Ágiles . . . 24
2.1.3.4. Diferencias entre metodologías ágiles y tradicionales . . . . 24
2.1.4. Metodologías enfocadas al desarrollo de software en pymes . . . 25
2.1.4.1. Metodología XP . . . 26
2.1.4.1.1. Prácticas de la metodología . . . 26
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.1.4.1.2. Reglas en cada fase de la metodología . . . 27
2.1.4.2. Microsoft Solution Framework (MSF) . . . 31
2.1.4.2.1. Características . . . 31
2.1.4.2.2. Principios fundamentales . . . 32
2.1.4.2.3. Modelos . . . 33
2.1.4.2.4. Fases . . . 34
2.1.4.2.5. Gestión de requerimientos . . . 35
2.1.4.2.6. Ciclo de vida . . . 36
2.1.4.2.7. Disciplinas . . . 36
2.2. Método de la investigación . . . 38
2.2.1. Población . . . 38
2.2.2. Muestra . . . 38
2.2.3. Etapas de la investigación . . . 38
3. Diseño de una metodología mixta de desarrollo de software para automatizar los procesos de las pymes peruanas 40 3.1. Selección y adaptación de técnicas de las metodologías XP y MSF . . . 41
3.2. Ciclo de vida . . . 46
3.2.1. Etapas de la Metodología . . . 47
3.2.1.1. Obtención y Análisis de Requerimientos . . . 47
3.2.1.1.1. Obtención de Requerimientos . . . 47
3.2.1.1.2. Análisis de Requerimientos . . . 48
3.2.1.2. Planificación . . . 49
3.2.1.2.1. Estimación de tiempos de desarrollo . . . 49
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
3.2.1.2.2. Elaboración y aprobación del acuerdo de entendi-
miento . . . 52
3.2.1.3. Modelado y Desarrollo . . . 55
3.2.1.3.1. Modelado . . . 55
3.2.1.3.2. Desarrollo . . . 55
3.2.1.4. Despliegue . . . 57
3.2.1.5. Producción . . . 58
3.2.2. Aplicación de la metodología diseñada a un caso de estudio . . . 59
3.2.2.1. Caso de estudio . . . 59
3.2.2.2. Obtención y análisis de requerimientos . . . 60
3.2.2.2.1. Obtención de requerimientos . . . 60
3.2.2.2.2. Análisis de requerimientos . . . 60
3.2.2.3. Planificación . . . 64
3.2.2.3.1. Estimación de tiempos de desarrollo . . . 64
3.2.2.3.2. Elaboración y aprobación del acuerdo de entendi- miento . . . 67
3.2.2.4. Modelado y Desarrollo . . . 73
3.2.2.4.1. Modelado . . . 73
3.2.2.4.2. Desarrollo . . . 83
3.2.2.5. Despliegue . . . 89
3.2.2.6. Producción . . . 90
4. Resultados y Discusión de la tesis 94 4.1. Resultados Teóricos . . . 94
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
4.2. Resultados Computacionales . . . 97
5. Consideraciones finales 109
5.1. Conclusiones . . . 109 5.2. Trabajos Futuros . . . 110
A. Interfaces del sistema desarrollado 114
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Capítulo 1 Introducción
En el Perú, las pymes representan el 96 % del sector económico del país (Retail, 2017). Se pueden automatizar los procesos de las pymes mediante el uso de productos de software.
En el 2016 se registraron 60 desarrolladoras a nivel nacional para cumplir este objetivo (Mendoza Riofrío, 2016), pero en 2012 usando MoproSoft, se evaluó a varias desarrolladoras de software, dando como resultado que estas no siguen un proceso definido, afirmando que la aplicación de las metodologías existentes no estaban enfocados a pymes, además que existe mala gestión y dirección de proyectos, comunicación insuficiente y falta de compromiso entre los desarrolladores y los clientes (Coque-Villegas et al., 2018; FRED, 2015), debido a esto, el éxito de desarrollo de software solo es de 20 % (Coque-Villegas et al., 2018). Cada pyme tiene su propia idea de negocio, las cuales influyen en sus procesos y áreas pertenecientes, y para automatizar sus procesos se necesitaría una metodología simple y flexible.
Debido a esto nos enfrentamos al siguiente problema: ¿Cómo desarrollar software para automatizar los procesos de las pymes peruanas?.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Existen criterios de éxito de desarrollo de software, tales como el bajo costo del desarrollo inicial, el mantenimiento debe ser sencillo, junto con la portabilidad a un nuevo hardware, y por último es que el software cumpla con los requerimientos de los clientes (Tinoco Gómez et al., 2010).
Existen metodologías que establecen roles y actividades muy rigurosas, sin embargo, estos deben adaptarse a la realidad actual de los proyectos de software, donde los requerimientos de los clientes son muy cambiantes y se exige reducir los tiempos de desarrollo y manteniendo la alta calidad del producto (Colombani et al., 2016; Rujana et al., 2016). Las metodologías ágiles enfocan su interés a los puntos mencionados, afirman que se centran en el factor humano y el producto software a construir, permitiendo la interacción entre el cliente y el equipo desarrolla- dor y en donde se realizan entregas incrementales del producto. Las metodologías tradicionales por su parte siguen una estructura ordenada y bien definida, las cuales ofrecen otro tipo de desa- rrollo de software, pero aplicadas a pymes, no son tolerantes a cambios, genera documentación que es innecesaria y demanda mucho tiempo en el modelado de sistemas (Jiménez, 2017).
Si bien se cuentan con estos dos tipos de metodologías, también se incluye las híbridas o mixtas, éstas marcan la nueva tendencia en el área de Ingeniería de Software. Las metodologías híbridas o mixtas retoman las ventajas de las metodologías ágiles y tradicionales, de esta ma- nera son una combinación de las mejores prácticas existentes dentro de ellas (Jiménez, 2017).
Esta propuesta es atribuida a Ivar Jacobson, uno de los tres creadores de UML (Unified Mode- ling Language), creador de UP (Unified Process, Proceso Unificado), y ahora creador de EssUP (Essential Unified Process), en el año 2011, la cual es una metodología híbrida que combina
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
RUP con Scrum (Jiménez, 2017).
Con lo anterior expuesto, optamos por el diseño de una metodología mixta de desarrollo de software, de la cual sus prácticas serán tomadas de una metodología ágil y una tradicional.
1.1. Justificación de la investigación
Existen distintas metodologías para el desarrollo del software, pero aun así con estas, las pymes peruanas no encuentran la forma de automatizar sus procesos en poco tiempo, a bajo costo y que haga realmente las tareas a su manera como se pretendió al elaborar su software.
Por ello es necesario diseñar una nueva metodología, la cuál será mixta, para la automatiza- ción de los procesos de las pymes.
1.2. Formulación del problema
¿Cómo desarrollar software para automatizar los procesos de las pymes peruanas?
1.3. Hipótesis
El diseño de una metodología mixta permitirá automatizar los procesos de las pymes perua- nas.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
1.4. Objetivos
1.4.1. General
Diseñar una metodología mixta de desarrollo de software para automatizar los procesos de las pymes peruanas.
1.4.2. Específicos
Investigar metodologías ágiles y tradicionales de desarrollo de software propuestas a py- mes y seleccionar las que se utilizarán para esta tesis.
De las metodologías seleccionadas, tomar algunas de sus técnicas para el diseño de la metodología mixta de desarrollo de software.
En base a las técnicas tomadas, establecer el ciclo de vida de la metodología mixta de desarrollo de software para la automatización de procesos de las pymes peruanas.
Aplicar la metodología mixta de desarrollo de software a un caso de estudio de una pyme con la finalidad ejemplificar su uso y lograr automatizar los procesos de la pyme.
Evaluar la metodología mixta mediante el juicio de expertos.
1.5. Estructura de la tesis
El presente trabajo está dividido en cinco capítulos. El primer capítulo presenta los aspectos generales del tema abordado: la justificación de la investigación, la formulación del problema, la hipótesis, los objetivos y la estructura de la tesis.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
En el capítulo dos se presenta el referencial teórico, el cual es la base del tema, abarcando definiciones de la pyme, ingeniería de software, metodologías de desarrollo de software (ágil y tradicional), las metodologías XP y MSF y el método de la investigación.
El tercer capítulo consiste en el diseño de la metodología mixta de desarrollo de software pa- ra automatizar los procesos de las pymes, aplicando en su ciclo de vida algunas de las prácticas adaptadas de las metodologías XP y MSF enfocadas al desarrollo de software en pymes. Tam- bién se presenta la aplicación de la metodología a un caso de estudio, con el fin de ejemplificar su uso y lograr automatizar los procesos de la pyme.
En el cuarto capítulo se presentan los resultados teóricos y computacionales obtenidos en esta investigación.
En el capítulo cinco se exponen las consideraciones finales conseguidas en este trabajo, que incluyen las conclusiones y los trabajos a realizar a fututo involucrados con el tema en cuestión.
Finalmente se presentan las referencias bibliográficas empleadas para la investigación en esta tesis.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Capítulo 2
Materiales y métodos
2.1. Marco Teórico
2.1.1. La pymes
2.1.1.1. Definición
Cardozo y Martín (2012) definen a las pequeñas y medianas empresas (Pymes) como tipos de empresas con características distintivas; tienen dimensiones con ciertos límites ocupacio- nales y financieros prefijados por los estados o regiones. Son agentes con lógicas, culturas, intereses y un emprendedor específico.
Según Cardozo y Martín (2012), las principales razones de la existencia de las pymes son:
Realizan productos individualizados en contraposición con las grandes empresas que se enfocan más en productos estandarizados.
Sirven de tejido auxiliar a las grandes empresas. La mayor parte de las grandes empresas se valen de empresas subcontratadas menores para realizar servicios u operaciones que de estar incluidas en el tejido de la gran corporación redundaría en un aumento de coste.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Porque existen actividades productivas donde es más apropiado trabajar con empresas pequeñas, como por ejemplo en el caso de las cooperativas agrícolas.
Benites Vargas (2014) menciona que, en el Perú, las pymes representan el 99.5 % del total de empresas del país, son responsables de más del 50 % de la producción nacional y producen el 49 % del PBI nacional. Las pymes concentran el 77 % de los empleos totales, siendo la micro- empresa la que más empleos genera (55 % de la PEA ocupada a escala nacional). Participan en el proceso productivo del país y realizan un conjunto de actividades económicas heterogéneas.
El comercio y los servicios concentran la mayor cantidad de las pymes (49 % y 33 %, respecti- vamente), seguido de manufactura (11 %), y más atrás están agropecuario y construcción (3 % cada uno).
2.1.1.2. Características
Cardozo y Martín (2012) mencionan las siguientes características de las pequeñas y media- nas empresas:
Pequeña empresa: Se caracteriza por el predominio de manufacturas para mercados lo- cales, su tamaño es limitado, es intensiva en mano de obra no calificada, sus productos son generalmente bienes de consumo final y su organización es simple. Según D.L. 1086: De uno (1) hasta cien (100) trabajadores, inclusive, y ventas anuales hasta el monto máximo de 1700 Unidades Impositivas Tributarias (UIT).
Mediana empresa: Es una categoría intermedia entre pequeña y gran empresa. El número de personas ocupadas por ella puede hasta los 200, generalmente se ubica en las grandes ciuda- des, su tecnología en algunos casos es elemental; en otros sofisticados, con ventas anuales que superan 1700 Unidades Impositivas Tributarias (UIT).
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.1.1.3. Uso de Tecnologías de Información y Comunicaciones
Según PRODUCE (2016), el nivel de tamaño de empresa, el uso de computadoras por parte de las microempresas se reduce a 69.6 % y crece a casi 100 % en las grandes empresas. A nivel sectorial, casi la totalidad de empresas de los sectores de enseñanza e información y comunica- ciones poseen computadoras, en contraste con el sector de alojamiento y servicio de comida que reporta la menor incidencia en el uso de computadoras (59.3 %). En el año 2014, respecto a las diversas tecnologías de información y comunicación a las que tuvieron acceso las empresas, el 93.5 % de las empresas tuvo acceso a internet, el 8.6 % a intranet, el 3.0 % a extranet y el 6.5 % no tiene acceso a estas tecnologías. Por tamaño de empresa, el 90 % de las microempresas tiene acceso a internet mientras que, en los demás estratos, el porcentaje bordea el 100 %. Otro punto importante en las comunicaciones de la empresa es el uso de redes sociales. Sólo la tercera parte de las empresas utilizaron sitios web o redes sociales en el 2014. El sector servicios es el que tiene mayor uso de páginas web y redes sociales (50.1 % y 36.4 % respectivamente). Además, sólo el 20.5 % de las microempresas han utilizado páginas webs mientras que más de las dos terceras partes de las medianas y grandes empresas lo usaron. Las empresas del sector servi- cios lideran el uso de páginas webs mientras que sólo el 7 % de las de los sectores de pesca y acuicultura lo utilizan. En las últimas décadas, el uso de Terminal de Pago (POS) para realizar ventas se ha extendido en la mayor parte de establecimientos en la zona urbana. En el 2014, sólo 1 de cada 10 empresas utilizaba este servicio. Solo el 10.4 % de las empresas peruanas han usado esta tecnología en el 2014. Existen brechas por estrato empresarial dado que a mayor nivel de venta existe mayor capacidad para cubrir los costos del uso de POS. A nivel sectorial, las actividades artísticas, de entretenimiento y recreativas, así como las de alojamiento y de servicio de comidas son las que poseen mayor proporción de empresas que usan el terminal de
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
pago (35 % y 33.5 % respectivamente).
2.1.1.4. Uso de software, redes sociales e internet
Según PRODUCE (2016), el 48.5 % de las empresas no maneja ningún tipo de sistema de gestión informatizado (software). A nivel sectorial, las actividades financieras lideran el porcen- taje de empresas que poseen al menos un sistema de gestión informatizado (80 %). De acuerdo con el tamaño empresarial, el 35.7 % de las microempresas posee un sistema de gestión infor- matizado; mientras que la cifra bordea el 100 % en el caso de las grandes empresas. De acuerdo con EMYPE 2013, cerca de la tercera parte de las MYPES del sector manufactura disponían de algún sistema de gestión informatizado en su empresa en el 2012. En el 2014, esta cifra habría aumentado a la mitad. De las empresas que sí manejan al menos un tipo de software, el más usado es el contable tributario. El 64.5 % de las empresas del sector minería posee este software y lidera en porcentaje al resto de sectores.
El comercio electrónico también se ha convertido en una herramienta clave para el creci- miento de las empresas. Esta adopción tecnológica incrementa la productividad e impulsa la formalización, lo que finalmente genera mayores niveles de venta. Esto es posible gracias a que el uso de medios electrónicos como el Internet y las redes sociales permiten ingresar a nuevos mercados reduciendo significativamente el costo de transacción para la empresa. Por ello, el uso de redes sociales y otras herramientas a través de Internet se ha incrementado significativamente en la última década, pese a que aún se mantiene un rezago respecto a los países más importan- tes de la región Latinoamericana. A nivel nacional, todavía existe una brecha significativa para incorporar a las empresas al mundo de internet a través del uso de página web, redes sociales y Linkedin, ya que sólo la tercera parte de las empresas utilizaron sitios web o redes sociales en el 2014. El sector servicios es el que tiene mayor uso de páginas web y redes sociales (50.1 %
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
y 36.36 % respectivamente). Además, sólo el 20.5 % de las microempresas ha utilizado páginas web para fines comerciales o de coordinación. En el caso de las medianas y grandes empresas, esta cifra alcanza los dos tercios. El uso del servicio de páginas web o redes sociales posee dis- tintos fines, entre los que destacan la búsqueda de productos, servicios e información, el soporte a los clientes, la promoción de los productos, la comunicación, la banca electrónica, entre otros.
La brecha de uso de redes sociales según tamaño empresarial se reduce puesto que el porcentaje en las microempresas aumenta a 25.8 %, en tanto en las grandes y medianas asciende a 37.3 % y 43.7 % respectivamente.
Figura 2.1:Tipos de sistema de gestión informatizado (software) que tiene la empresa, 2014 Fuente: PRODUCE (2016)
Figura 2.2:Uso de página web, redes sociales y Linkedin, 2014 Fuente: PRODUCE (2016)
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
En el año 2014, respecto a las diversas tecnologías de información y comunicación a las que tuvieron acceso las empresas, el 93.5 % de las empresas que tuvieron una computadora o laptop tuvieron acceso a internet, mientras que el acceso a intranet y extranet está por debajo del 9 %.
El porcentaje de las que no tienen acceso asciende a 9.9 % en el caso de las microempresas y 0.3 % en el caso de las grandes empresas. Según la EMYPE, en el 2012, el porcentaje de las MYPES manufactureras que tuvieron acceso a internet ascendió a 90 % de modo que en el transcurso de tres años no se ha registrado un cambio significativo.
Figura 2.3:Empresas que tienen acceso a internet, intranet y extranet, 2014 Fuente: PRODUCE (2016)
2.1.2. Ingeniería de software
2.1.2.1. Definición de Ingeniería
Es la actividad de transformar el conocimiento en algo práctico. La ingeniería es el conjunto de conocimientos y técnicas científicas aplicadas al desarrollo, implementación, mantenimiento y perfeccionamiento de estructuras (tanto físicas como teóricas) para la resolución de problemas que afectan la actividad cotidiana de la sociedad (Maida y Pacienzia, 2015).
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.1.2.2. Definición del Software
Según Maida y Pacienzia (2015), el software es el equipamiento lógico e intangible de un sistema informático, que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos que son llamados hardware.
2.1.2.3. Definición de la Ingeniería de Software
Es la disciplina o área de la informática, que hace uso razonable de los principios de in- geniería con el objetivo de obtener soluciones informáticas económicamente factible y que se adapte a las necesidades de las empresas reales, tomando en cuenta los procesos de produc- ción y mantenimiento de software que son desarrollados y modificados en el tiempo y con los costos estimados. Se relaciona con áreas muy diversas de la informática y de las Ciencias de la Computación, tales como construcción de compiladores, Sistemas Operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Información y aplicables a infinidad de áreas, tales como: negocios, investigación científica, medicina, producción, logística, banca, entre otras (Maida y Pacienzia, 2015).
2.1.2.4. Lenguaje Unificado de Modelado (UML)
Según (Ortega Ochoa, 2014), es el lenguaje de modelado de sistemas de software más cono- cido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software.
UML ofrece un estándar para describir un "plano"del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
de software reutilizables.
(Orallo, 2002), menciona las siguientes funciones de UML:
Visualizar: Permite expresar de una forma gráfica un sistema de manera que otro lo puede entender.
Especificar: Permite especificar cuáles son las características de un sistema antes de su construcción.
Construir: A partir de los modelos especificados se pueden construir los sistemas dise- ñados.
Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.
UML cuenta con una gran variedad de diagramas, los cuales muestran distintos aspectos de las entidades representadas. A continuación se definen los diagramas que se emplean para el presente trabajo de investigación.
2.1.2.4.1. Diagrama de Caso de Uso
De acuerdo con (Ortega Ochoa, 2014), un diagrama de caso de uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad de un sistema respecto a su interacción externa.
Actores
Un actor es una entidad externa a un sistema que interacciona con el mismo. Se simboliza mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.).
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Casos de uso
Un caso de uso describe la secuencia de interacciones que se producen entre un actor y un sistema, para llevar a cabo una tarea específica. Se representa mediante una elipse con el nombre del caso de uso en su interior, el cual refleja la tarea específica que el actor llevará a cabo usando el sistema.
Relaciones entre casos de uso
Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en forma de triángulo y con una etiqueta «extiende» (cuando un caso de uso especializa a otro extendiendo su funcionalidad) o «usa» (cuando un caso de uso utiliza a otro) según sea el tipo de relación.
Figura 2.4:Ejemplo de un Diagrama de Caso de Uso Fuente: Orallo (2002)
2.1.2.4.2. Diagrama de Clases
Según Flores Cueto y Bertolotti Zuñiga (2009), un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargarán del funcionamiento y la relación entre uno y otro. En un diagrama de clases se pueden distinguir principalmente dos elementos: clases y sus relaciones.
Clases:
La clase es la unidad básica que abarca toda la información de un objeto a través de la cual se puede modelar el entorno en estudio, en UML se representa en un rectángulo que posee tres divisiones (nombre, atributos y métodos de una clase).
Figura 2.5:Diagrama de Caso de Uso Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
Figura 2.6:Ejemplo de un Diagrama de Caso de Uso Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Los atributos o características de una clase pueden ser de tres tipos, estos definen su grado de comunicación y visibilidad con el entorno, estos son:
public: Denota que el atributo será visible tanto dentro como fuera de la clase (es accesi- ble desde cualquier lado).
Figura 2.7:Atributo public de una clase Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
private: Indica que el atributo únicamente será accesible desde dentro de la clase (sólo sus métodos pueden manipularlo).
Figura 2.8:Atributo private de una clase Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
protected: Significa que el atributo no será accesible desde fuera de la clase, pero si podrá ser manipulado por métodos de la clase y de sus subclases.
Figura 2.9:Atributo protected de una clase Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
Los métodos u operaciones de una clase representan interacción con su entorno, sus carac- terísticas son las siguientes:
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
public: Denota que el método será visible tanto dentro como fuera de la clase (es accesi- ble desde cualquier lado).
Figura 2.10:Atributo public de una clase Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
private: Indica que el método únicamente será accesible desde dentro de la clase (sólo sus métodos pueden manipularlo).
Figura 2.11:Atributo private de una clase Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
protected: Significa que el método no será accesible desde fuera de la clase, pero si podrá ser manipulado por métodos de la clase y de sus subclases.
Figura 2.12:Atributo protected de una clase Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
Relaciones:
1. Herencia (Especialización/Generalización): Indica que una clase (clase derivada) here- da los métodos y atributos especificados por una clase (clase base), por lo cual una clase derivada además de tener sus propios métodos y atributos, podrá acceder a las caracte- rísticas y atributos visibles de su clase base (public y protected). Por ejemplo, la figura
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.13 especifica que las clases Alumno y Profesor heredan de la clase Persona, es decir, Alumno y Profesor podrán acceder a las características de Persona.
Figura 2.13:Ejemplo de una relación de herencia entre clases Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
2. Composición: La composición es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye (el objeto base se construye a partir del objeto incluido, es decir, es parte/todo).
Figura 2.14:Ejemplo de una relación de composición entre clases Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
3. Agregación: La agregación es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye (el objeto base utiliza al incluido
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
para su funcionamiento).
Figura 2.15:Ejemplo de una relación de agregación entre clases Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
4. Dependencia o Instanciación: Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada. El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del objeto Ventana está condicionado a la instanciación proveniente desde el objeto Aplicación).
Figura 2.16:Ejemplo de una relación de dependencia o instanciación entre clases Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
5. Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Figura 2.17:Ejemplo de una relación de asociación entre clases Fuente: Flores Cueto y Bertolotti Zuñiga (2009)
2.1.2.4.3. Diagrama de Secuencia
Según (Ortega Ochoa, 2014), un diagrama de secuencia expone una interacción conforme a una secuencia temporal de eventos. Singularmente, muestra una interacción entre los objetos participantes y los mensajes que intercambian ordenadamente según su secuencia en el tiempo.
El eje vertical representa el tiempo (el cual fluye de arriba hacia abajo), mientras que en el eje horizontal se sitúan los objetos y actores participantes en la interacción, sin considerar un orden prefijado. Cada objeto o actor cuenta con una línea vertical, y los mensajes se simbolizan mediante flechas entre los objetos que componen el diagrama.
Figura 2.18:Ejemplo de un diagrama de secuencia Fuente: Navarro (2003)
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.1.2.4.4. Diagrama de Despliegue
De acuerdo a lo expuesto por Navarro (2003), un diagrama de despliegue muestra la arqui- tectura física del hardware y el software en un sistema. Se compone de nodos (representados en cubos), que pueden ser computadoras u otros dispositivos, además de las conexiones (re- presentadas en líneas) y tipos de conexiones (descritas textualmente en cada línea) existentes entre ambos. Dentro de los nodos se encuentran los componentes ejecutables y objetos con la finalidad de mostrar las unidades de software ejecutadas y los nodos en donde se encuentran.
Se pueden utilizar objetos en forma de papel para agregar descripciones sobre los elementos de un diagrama de despliegue (ver figura 2.19).
Figura 2.19:Ejemplo de un diagrama de despliegue Fuente: Navarro (2003)
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.1.3. Metodologías de desarrollo de software
2.1.3.1. Definición de metodología
Según Maida y Pacienzia (2015), una metodología es un conjunto integrado de técnicas que permiten abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Se basan en una combinación de los modelos de proceso genéricos. Definen artefactos, roles y actividades, junto con prácticas y técnicas recomendadas.
La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de éxito. Una metodología para el desarrollo de software comprende los procesos a seguir sistemáticamente para idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado.
Una metodología aplicada a la ingeniería del software:
Optimiza el proceso y el producto software.
Se compone de métodos que guían en la planificación y en el desarrollo del software.
Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un pro- yecto.
Los elementos que forman parte de una metodología son:
Fases: tareas o actividades a realizar en cada fase o etapa.
Productos: entradas y salidas de cada fase, documentos.
Procedimientos y herramientas: contribuyen a la realización de cada tarea.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Criterios de evaluación del proceso y producto: permite constatar si se han logrado los objetivos.
Una metodología de desarrollo de software o metodología de desarrollo de sistemas en ingeniería de software es un marco de trabajo que se usa para estructurar, planificar y controlar el proceso de desarrollo de un sistema de información.
El marco de trabajo de una metodología de desarrollo de software comprende:
Una filosofía de desarrollo de software, con el enfoque o enfoques del proceso de desa- rrollo de software.
Múltiples herramientas, modelos y métodos para ayudar en el proceso de desarrollo de software.
2.1.3.2. Metodologías Tradicionales
Las metodologías tradicionales se centran en llevar una documentación exhaustiva de to- do el proyecto, la planificación y control de este, en especificaciones precisas de requisitos y modelado y en cumplir con un plan de trabajo, definido todo esto, en la fase inicial del desarro- llo del proyecto. Imponen una disciplina rigurosa de trabajo sobre el proceso de desarrollo del software, con el objetivo de obtener 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 software. Se centran principalmente en el control del proceso, mediante una estricta definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. No se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
predecirse o bien pueden variar, además de los altos costes al implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es volátil (Maida y Pacienzia, 2015).
2.1.3.3. Metodologías Ágiles
Las metodologías ágiles proporcionan una serie de pautas y principios junto a técnicas prag- máticas que permiten que la entrega del proyecto sea menos complicada y más satisfactoria tan- to para los clientes como para los miembros de los equipos de trabajo, evitándose los caminos burocráticos de las metodologías tradicionales, generando poca documentación y no haciendo uso de métodos formales. Nacen como respuesta a los problemas que puedan ocasionar las me- todologías tradicionales, basándose en dos aspectos fundamentales: el retraso las decisiones y la planificación adaptativa. Un modelo de desarrollo ágil, generalmente es un proceso Incremental (entregas frecuentes con ciclos rápidos), Cooperativo (en donde los clientes y los desarrollado- res trabajan constantemente con una comunicación muy fina y constante), Sencillo (el método es fácil de aprender y modificar para el equipo) y Adaptativo (capaz de permitir cambios de último momento) (Maida y Pacienzia, 2015).
2.1.3.4. Diferencias entre metodologías ágiles y tradicionales
A continuación, se muestra una tabla que contiene una comparativa entre estos dos grupos de metodologías:
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Figura 2.20:Comparación entre metodologías ágiles y tradicionales Fuente: Maida y Pacienzia (2015)
2.1.4. Metodologías enfocadas al desarrollo de software en pymes
De acuerdo con esta investigación, se encontraron propuestas de metodologías de desarrollo de software enfocadas en las pymes tales como la metodología denominada Columna Vertebral del Software, diseñada por (Pérez y Castelló, 2006) y la metodología propuesta por (Colombani et al., 2016), estas se basan en la metodología ágil Programación Extrema (XP). También se halló la propuesta de (Arévalo y Atehortúa, 2012), la cual consiste en una adaptación de la metodología tradicional Microsoft Solutions Framework (MSF). A continuación se definen las metodologías anteriormente mencionadas.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
2.1.4.1. Metodología XP
La metodología XP es una de las metodologías representativas de las metodologías ágiles.
La imagen 2.21 se muestra el flujo de las fases junto a sus estados, las cuales se detallan más adelante
Figura 2.21:Extreme Programming (XP) Fuente: Wells (2000)
2.1.4.1.1. Prácticas de la metodología
Las prácticas en las que se basa la metodología son:
Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas, incluyen- do pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codifica- ción.
Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Frecuente integración del equipo de programación con el cliente o usuario: Se reco- mienda que un representante del cliente trabaje junto al equipo de desarrollo. Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código: Es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad, pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
Propiedad del código compartido: En vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
Simplicidad del código: Es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias: Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuan- to más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programa- dores.
2.1.4.1.2. Reglas en cada fase de la metodología
Fase I - Planificación del Proyecto
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Historias de usuario: El primer paso de cualquier proyecto que siga la metodología XP.
Consiste en 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 3 o 4 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 1 y 3 semanas.
Release Planning: Después de tener ya definidas las historias de usuario es necesario crear un plan de lanzamiento, en inglés “Release plan", donde se indiquen que historias de usuario se crearán para cada versión del programa y las fechas en las que se publicarán estas ver- siones. 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 im- plementadas 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 lanzarse las versiones del programa.
El número de personas que trabajarán en el desarrollo
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
La evaluación de calidad del trabajo realizado.
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 desa- rrolla 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 se puede controlar que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo “Release Planning".
Fase II - Diseño
Diseños Simples: La metodología XP sugiere que hay que conseguir diseños simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un di- señ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 am- pliaciones y la reutilización del código.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Riesgos: Si surgen problemas potenciales durante el diseño, XP sugiere utilizar una pa- reja 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 contie- nen funcionalidades que no serán usadas y diseños obsoletos.
Fase III - Codificación
El cliente es una parte más del equipo de desarrollo; su presencia es indispensable en las distintas fases de XP. A la hora de codificar una historia de usuario su presencia es aún más ne- cesaria. No se debe olvidar 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 escalabi- lidad.
Fase IV - Pruebas
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Uno de los pilares de la metodología XP es el uso del test para comprobar el funcionamiento de los códigos que se vayan implementando. El uso de los test en XP 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 tests se deben subir al repositorio de código acompañados del códi- go que verifican. Los test mencionados anteriormente sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario.
2.1.4.2. Microsoft Solution Framework (MSF)
Según Vergara C. y Mario (2014) esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas. MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información.
2.1.4.2.1. Características
Adaptable: Es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Escalable: Puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnología Agnóstica: Porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.
2.1.4.2.2. Principios fundamentales
Pérez (2011) menciona que los principios de MSF son 8 valores y normas, los cuales contri- buyen a mejorar el trabajo en equipo y a centrarse en mantener el objetivo del proyecto siempre en marcha, estos principios son:
Fomentar la comunicación abierta: El mantener un buen flujo de información entre los integrantes del equipo, pueden reducir las posibilidades de malentendidos y contribuir a la so- lución colectiva de problemas.
Trabajar hacia una visión compartida: El equipo de trabajo debe comprender y trabajar hacia las metas y objetivos del proyecto.
Empoderar a los miembros del equipo: Los miembros del equipo deben tener funciones claras, de tal manera que puedan desenvolverse como un grupo creativo, eficaz y capaz de cumplir sus propios objetivos, al igual que resolver sus dificultades.
Establecer la rendición de cuentas claras y la responsabilidad compartida: Cada equipo tiene funciones claras y son responsables de una parte de la solución, así como del éxito global del proyecto, trabajando desde la individualidad en procura de objetivos colectivos.
Centrarse en ofrecer valor empresarial: El equipo de trabajo debe procurar ofrecer solu- ciones reales que satisfagan necesidades y beneficien al comprador del producto, pues entregar un producto bien elaborado y que cumpla los requerimientos para el cual fue diseñado es el
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
objetivo a alcanzar.
Mantenerse ágil, en espera de un cambio: El cambio constante debe ser aceptado, es decir, el equipo debe estar preparado para afrontar estas situaciones y ofrecer soluciones eficaces. MSF acepta la combinación de caos y orden lo cual deja entrever las altas posibilidades de que los proyectos software se salgan de control.
Invertir en la calidad: El equipo debe mantener la mentalidad centrada en la calidad, se debe invertir en las personas, en los procesos y las herramientas, pues esta inversión puede retribuir en resultados de mayor calidad.
Aprender de todas las experiencias: Tener una mentalidad abierta para aprender del éxito o fracaso de proyectos propios y ajenos.
2.1.4.2.3. Modelos
Los modelos describen esquemas realizar para la organización de los equipos de trabajo y los procesos del proyecto, estos son:
Equipo de trabajo
Este modelo se centra de organizar los miembros del equipo para que realicen el trabajo y se asegura que todas las metas del proyecto se cumplan, comprende:
Principios: Todos los miembros del equipo son compañeros por lo tanto no hay jefes, se deben tener las funciones y las responsabilidades claras. Procurar evitar los defectos en los procesos relacionados con el equipo y tener una mentalidad de calidad orientada a la satisfacción del cliente, así como tener voluntad y capacidad de aprender.
Roles: Un rol define comportamientos y actividades de cada individuo o grupo, cada per- sona puede tomar más de un rol y múltiples personas pueden tomar un rol, en este modelo se describen seis roles con sus respectivas actividades, las cuales se relacionan en la figura 2.22.
BIBLIOTECA DE
CIENCIAS
FÍSICAS
Y MATEMÁTICAS
Figura 2.22:Modelo de equipo de trabajo - MSF Fuente: Pérez (2011)
Proceso
Este modelo se encarga de organizar los procesos necesarios para lograr llevar a término una solución. Esto se logra dividiendo las tareas del proyecto en cinco fases, las cuales proporcio- nan herramientas para mejorar el control sobre el proyecto, minimizar el riesgo y aumentar la calidad del producto. Al igual que el proceso RUP, MSF también tiene sus prácticas inherentes al desarrollo de software, tales como la especificación, el desarrollo, la validación y la evolución del software. Los principios relacionados con el proceso MSF, son: el manejo de versiones, la gestión del riesgo, dividir el proyecto en partes y realizar construcciones diarias.
2.1.4.2.4. Fases
MSF está compuesta por cinco fases, las cuales se muestran en la figura 2.23 y se detallarán a continuación.