FACULTAD DE CIENCIAS EMPRESARIALES CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS EMPRESARIALES “ANÁLISIS DE REQUISITOS PARA EVITAR REPROCESOS EN ADP PAYROLL PERÚ AÑO 2019” Trabajo de investigación para optar el grado de Bachiller en Ingeniería de Sistemas Empresariales Integrantes: Hans Farro Castillo LIMA- PERÚ 2019 1 2 INDICE DE CONTENIDO INDICE DE CONTENIDO 3 Índice de tablas…………………………………………………………………………………… 4 Índice de figuras………………………………………………………………………………….. 5 INTRODUCCION 6 CAPÍTULO I: DESCRIPCIÓN DEL PROBLEMA 7 1.1. Descripción de la realidad problemática ........................................................... 7 1.2. Objetivos del proyecto ...................................................................................... 7 1.2.1. Objetivo general 7 1.2.2. Objetivos específicos 7 1.3. Justificación del proyecto ....................................................................................... 7 CAPITULO II: MARCO TEORICO 8 2.1. Antecedentes ........................................................................................................ 8 2.1.1 Antecedentes Nacionales: 8 2.1.2 Antecedentes Internacionales: 9 2.2. Bases teóricas ..................................................................................................... 11 2.3. Definiciones conceptuales ................................................................................... 13 CAPÍTULO III: DESARROLLO DEL PROYECTO 15 3.1. Arquitectura empresarial (Seguimiento de solicitud de cambio) ........................... 15 3.1.1. Arquitectura de Información (Datos) ................................................................. 15 3.1.2. Arquitectura de Negocios (Procesos) AS-IS ..................................................... 16 3.1.3. Arquitectura de aplicación ................................................................................ 18 3.1.4. Arquitectura de Tecnológica ............................................................................. 21 3.1.5. Factibilidad Económica ..................................................................................... 21 CAPITULO IV: RECURSOS Y CRONOGRAMA 27 4.1. Recursos ............................................................................................................. 27 CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES 30 5.1. Conclusiones ....................................................................................................... 30 5.2. Recomendaciones ............................................................................................... 30 CAPITULO VI: FUENTES DE INFORMACION 31 6.1. Referencias bibliográficas .................................................................................... 31 ANEXOS 33 3 Índice de tablas TABLA 1: Detalle del proceso de solicitudes de cambio. TABLA 2: Flujo de caja TABLA 3: ANALISIS FODA TABLA 4: Recolección de requerimientos TABLA 5: Capacidad de atención de requerimientos TABLA 6: Clasificación de requerimientos TABLA 7: MATRIZ DE TRAZABILIDAD TABLA 8: PLANTILLAS O PATRONES TABLA 9: GLOSARIO DE TERMINOS TABLA 10: RECURSOS TABLA 11: CRONOGRAMA DE PLAN DE TESIS TABLA 12: Plan del proyecto de mejora de análisis de requisitos 4 Índice de figuras Figura 1: Esquema de la metodología DoRCU Figura 2: DFD LOGICO NIVEL 1 Figura 3: DFD FISICO NIVEL 1 Figura 4: SOLICITUD DE CAMBIOS AS-IS Figura 5: Aplicación de seguimiento de solicitud TO-BE Figura 6: Login de aplicación Figura 7: Lista de actividades Figura 8: TO DO Figura 9: DONE Figura 10: Ingresar nueva solicitud Figura 11: Arquitectura de web aplicación Figura 12: Requisitos por tipo Figura 13: Requisitos por estado 5 INTRODUCCION Actualmente, las empresas buscan que sus proyectos no estén fuera del presupuesto o tiempo, realizando prácticas de metodologías tradicionales o ágiles que les permitan garantizar el beneficio del proyecto. Sin embargo, suelen tropezar en la primera fase del ciclo de vida del desarrollo de software (análisis) la cual implica el análisis de los requisitos o requerimientos esto se podría evitar si se logra aplicar la ingeniería de requisitos o requerimientos de la mejor manera posible con una metodología. Según el PMI (2014), menciona que “el 47% de los proyectos fracasan por tener una mala gestión de requisitos” (p.5); lo cual demanda a muchas a empresas que desarrollan software a llevar adecuadamente su proceso de análisis de requisitos. A esto le podemos sumar el tedioso trabajo que tendrán que volver a definir los involucrados en el proyecto. “Los proyectos de software actuales gastan entre 40 y 50 por ciento de su esfuerzo en retrabajos evitables” (Boehm & Basili, 2001, p.135). Eso conlleva a gastar tiempo corrigiendo los requisitos mal definidos lo que se supone que debió ser la base para las demás fases. Esto es la razón del surgimiento de este tema el cual espera que mediante una buena aplicación de la ingeniería de requerimientos siguiendo una metodología se evite los reprocesos en los proyectos. Para demostrar eso, se aplicará la metodología de ingeniería de requisitos llamada DoRCU a la empresa ADP PAYROLL PERÚ la cual brinda servicios relacionados a la gestión de capital humano (HCM). La empresa tiene que lidiar con solicitudes de cambios en sus soluciones brindadas por lo que rehacer el procedimiento de solicitud de cambio ocasiona que el cliente no confié en la empresa debido a su demora u otros factores. La presente investigación presentará la descripción del problema, antecedentes de otros autores, fundamento teórico, desarrollo de la metodología DoRCU y de una aplicación para el seguimiento a los requerimientos, cronograma y presupuesto para implementar la mejora de análisis de requisitos y las conclusiones de la investigación. 6 CAPÍTULO I: DESCRIPCIÓN DEL PROBLEMA 1.1. Descripción de la realidad problemática Actualmente, existe una gran demanda de tener la mejor calidad en un software por parte de las empresas debido a que en el transcurso del desarrollo de software se suelen cometer errores que empiezan por el análisis de requisitos. Además, tener la habilidad de transmitir las necesidades del cliente al equipo de desarrollo se vuelve tedioso, por ello muchos proyectos necesitan de técnicas de ingeniería de requisitos. Dichas técnicas se encuentran en la metodología DoRCU la cual está compuesta por etapas que guiarán al ingeniero de requisitos a evitar inconvenientes durante el transcurso del proyecto. La empresa ADP PAYROLL no tiene el conocimiento de técnicas de ingeniería de requisitos la cual es omitida o tomada con menos importancia por parte de los involucrados en el proyecto. Además, de no conocer y seguir una metodología de ingeniería de requisitos la cual guíe al ingeniero de requisitos hacia la una correcta documentación de requisitos orientada al usuario. 1.2. Objetivos del proyecto Esta investigación se realiza para mejorar los requisitos progresivos para que la empresa ADP PAYROLL pueda evitar reprocesos en sus proyectos de soluciones tecnológicas. 1.2.1. Objetivo general Identificar como el análisis de requisitos evitara reprocesos en ADP Payroll Perú año 2019 1.2.2. Objetivos específicos 1) Diagnosticar como la reducción de ambigüedades prevé problemas de calidad del software en ADP Payroll Perú año 2019 2) Identificar como la adherencia al proceso prevé problemas de calidad del software en ADP Payroll Perú año 2019 1.3. Justificación del proyecto La presente investigación aplicará bien el análisis de requisitos siguiendo la Metodología DoRCU con la cual se obtendrá cierta mejora en las técnicas de ingeniería de requisitos que se aplicarán a los Servicio & Productos. Lo cual 7 traerá como beneficio una menor probabilidad de que se reprocese el producto software como en la empresa ADP PAYROLL que a veces tiene que volver a la fase de desarrollo o de diseño cuando define mal sus requisitos. Se quiere demostrar que el análisis de requisitos puede ayudar a la empresa a cumplir con las peticiones del cliente eficientemente, quiénes recibirán un software como se pensó desde el principio. CAPITULO II: MARCO TEORICO 2.1. Antecedentes 2.1.1 Antecedentes Nacionales: Porras, E. (2017). Desarrollo una investigación titulada “Metodología Ágil Iconix en la calidad del producto software, Lima,2017”. Esta investigación resalta la importancia de aplicar una metodología ágil para llevar a cabo la entrega del producto de software de calidad respetando los requisitos iniciales del cliente. Además de aplicar técnicas de ingeniería de software y agile que entreguen valor a los proyectos de software que son gestionados por empresas grandes o medianas. La investigación consistió de la participación de 20 expertos en metodologías agiles y proyectos de software donde Iconix intervino como solución. La metodología de investigación es Cuasi experimental. Obteniendo como resultado que al aplicar esta metodología ágil junto a otras técnicas mejoraba la calidad del producto obteniendo como beneficio la reducción de tiempos y costos en el desarrollo e implementación de la solución. Se llegaron a varias conclusiones dentro de las cuales el análisis de requisitos que fue mejorado por la IR, patrones de diseño en el desarrollo del producto y la implementación de técnicas de programación avanzada mejoraron la calidad del producto. Cribilleros, J. & Pumachaico, K. (2015). Desarrollaron una investigación titulada “Análisis de requerimientos para el área de contabilidad de la empresa productos avicola chicama SAC. basado en ingeniería de requerimientos”. La investigación aplico la ingeniería de requerimientos (IR) dentro del proceso de facturación y mercadería lo cual se esperaba que ayude notablemente a entender los requerimientos y especificaciones del ERP dentro del área de Contabilidad, la investigación se apoya de una metodología DoRCU que permita 8 que la aplicación de la IR traiga beneficios en el desarrollo del producto a la avicola. Dicho estudio se realizó en Trujillo-Perú. Se contó con la participación de colaboradores directamente relacionados al proceso de desarrollo entre otros. La metodología de investigación es Investigación Descriptiva. Como resultados se revelaron que la documentación de procedimientos que llevaban a cabo en el área mejoro después de la implementación de IR y que se cumplieron la mayoría de requerimientos de usuario mejorando a comparación de los errores que tenía el sistema ERP. Se llegó a la conclusión que aplicar la metodología de IR ayudo a la empresa a conocer el proceso a fondo, obteniendo beneficios al reducirse la mayoría de errores que tenía el sistema ERP. Por lo que realizar un buen análisis de los requerimientos existentes permiten no solo conocer mejor nuestro proceso sino también a nuestros clientes internos es decir los colaboradores que se benefician internamente con la identificación y especificación de los requerimientos del proyecto. Además, realizar una comparativa entre el antes y después del sistema dejó en claro la importancia del análisis de requerimientos en las empresas peruanas. 2.1.2 Antecedentes Internacionales: De la cruz, C. & Castro, G. (2015). Realizaron una investigación titulada “Metodología para la adquisición y gestión de requerimientos en el desarrollo de software para pequeñas y medianas empresas (PYMES) del departamento de Risaralda”. Esta investigación se centra en la importancia de la IR en las empresas como en las universidades de Risaralda aplicando una metodología en el cual empresas y egresados participan demostrando su conocimiento sobre la IR en el desarrollo del software. La metodología de investigación fue Cuasi experimental. Los resultados que se encontraron fue que las empresas no aplicaban un estricto procedimiento en elicitacion, gestión y análisis de los requerimientos y aplicaban el mismo procedimiento para cualquier proyecto de software que realizaban. Además, los egresados no conocían sobre la ingeniería de requerimientos ni concepto ni técnicas que permitan mejorar o llevar mejor el ciclo de vida del desarrollo de software. Algunos egresados no llevaron cursos relacionados a esta rama de la ingeniería de software. Finalmente, llegaron a la conclusión que la metodología de adquisición y gestión requerimientos ayudaba a las empresas a reducir los tiempos muertos que llevaban en rehacer el producto software beneficiando a 9 los colaboradores para no cubrir horas extra o contratación de personal adicional para continuar con el desarrollo del software. La falta de interés en las empresas como en los futuros actores del cambio respecto a la IR hace que se retrabaje sobre las mismas condiciones sin medir las consecuencias. La metodología orienta a los usuarios a enfocarse en el brindarle al cliente final un estricto procedimiento en el cual puede confiar en que su producto durante la elicitacion, diseño, desarrollo y pruebas sean centradas en él. Méndez V., Cruz F. (2015) desarrollaron una investigación titulada “Mejora al control de acceso para laboratorios”. La investigación tiene como objetivo desarrollar adecuadamente la mejora de los procesos e identificación de requerimientos por lo cual se opta por metodologías que reduzcan el tiempo y costo de reserva de solicitud en el laboratorio y faciliten la identificación y análisis de requisitos asociados a la mejora del proceso. La investigación tuvo como muestra alumnos y docentes de la Universidad Andrés Bello. Los resultados que obtuvieron después de aplicar las metodologías fue el eficaz funcionamiento del sistema que fue probado las veces que fueron necesarias teniendo en cuenta la aprobación de los docentes y estudiantes que realizaban solicitudes para el acceso a los 40 laboratorios y se redujeron los tiempos que tardaban las aplicaciones en procesar la información siguiendo las normativas de la universidad. Por último, se realizó pruebas de uso y concepto lo cual fue satisfactorio ya que tanto docentes como estudiantes manejaron y entendieron mejor el procedimiento de reserva. Como conclusión se llegó a que la identificación y análisis de requisitos bajo la metodología DoRCU permitió identificar mejor a los requisitos asociados a la mejora de laboratorios y la Metodología IDEAL ayudo a que el proceso de reserva en los laboratorios se reduzca en tiempo y costos. 10 2.2. Bases teóricas 2.2.1 DoRCU (Documentación de Requisitos Centrada en el Usuario) Baez (2012) define DoRCU como “una metodología para la Ingeniería de Requerimientos caracterizada por su flexibilidad y orientación al usuario” (p.210). La metodología permite que los requerimientos que se definan se orientan al usuario, el cual se obtiene mediante etapas como Elicitacion, Análisis, Especificación y Validación. Dentro de la cuales poseen técnicas y métodos que ayuda a que la metodología cumpla con su propósito. Figura 1: Metodología DoRCU en la IR Fuente: Recuperado de https://bit.ly/3abeXck 2.2.1.1 Elicitacion de Requisitos Esta etapa es donde se tiene más de cerca al usuario, debido a las herramientas que hacen posible eso como las entrevistas, prototipos y escenarios. Herramientas que en el transcurso del proceso acercan los requerimientos como piensa el cliente. Es un proceso que no solo requiere de la participación del cliente con el entrevistador, también de un product owner que puede listar los requerimientos apropiadamente facilitando la comprensión de los interesados o cualquier persona en la empresa. Se debe informar sobre las reuniones que se llevaran con el cliente o interesados en el proyecto y no tomar mucho tiempo en la siguiente etapa se puede mejorar. 11 2.2.1.2 Análisis de Requisitos Fórmula las características operacionales que tendrá el sistema. Haciendo uso de técnicas que permitirán capturar la necesidad del cliente mediante el tratamiento de requisitos y matrices de interacción. Se toma los requerimientos de la etapa anterior y se corrige las posibles ambigüedades que tengan los equipos de desarrollo al leer el requerimiento. En este punto el requerimiento o requerimientos deben ser los más claros posibles en lo técnico, para evitar futuras confusiones en desarrollo o pruebas del producto. 2.2.1.3 Especificación de Requisitos Una vez corregido los requerimientos y pasando a lo técnico se debe especificar mediante una descripción y adjuntando archivos o imágenes que permitan entender los RF’s o RNF’s, además se debe especificar el objetivo y restricciones que podría tener los requerimientos clasificándolo por evolutivos o correctivos. De presentarse problemas para definir lo anteriormente mencionado se recomienda volver a la etapa anterior para garantizar la fiabilidad de cliente. 2.2.1.4 Validación de Requisitos Todo el esfuerzo realizado durante las etapas anteriores puede darse por perdido si no es manifestado en forma correcta, ya que cualquier mala interpretación puede echar por tierra hasta el proceso de Ingeniería de Requerimientos más consistente, desvirtuando la naturaleza de lo que fue, hasta el momento de su declaración, un buen requerimiento. (Báez.G. & Barba S. ,2012, p.219) 2.2.2 Reducción de Ambigüedades La reducción de ambigüedades está fuertemente relacionada la especificación y claridad con la que se expresa alguien. Por ello lograrla conlleva a un profundo entendimiento de los requerimientos u otros conceptos, la comunicación efectiva entre equipos y del líder al equipo conlleva a tomar decisiones correctas respecto al trabajo que desempeñara cada uno ya que enlaza a todos bajo el mismo objetivo. Evitamos generar desconfianza y promueve la comunicación en todos los niveles. 2.2.3 Adherencia al proceso 12 La adherencia al proceso significa que se debe seguir un riguroso monitoreo del proceso para identificar los principales problemas relacionados y hallar el motivo del incumplimiento para luego desarrollar una solución a través de estrategias que involucren a los responsables de las principales actividades dentro del proceso. Dando como resultado una notable mejora en los niveles de rendimiento del proceso deseado. 2.2.4 Reproceso Se puede aclarar que el reproceso busca que el producto sea terminado según los requisitos del cliente/usuario. El producto será entregado cuando cumpla todos esos requisitos de lo contrario volverá al proceso en el que falló o incluso volviendo al inicio del proceso y se seguirá repitiendo hasta que el producto esté acorde a las necesidades del cliente/usuario. Debido a esto el reproceso en el desarrollo de software ocasiona retrasos en la presentación del producto de software. 2.2.5 Problemas de calidad de software Empresas que desarrollan software ven necesario aplicar continuamente un plan de pruebas que permita identificar los problemas o probables conflictos cuando se pase a producción ya que existen problemas que afectan el rendimiento y funcionabilidad del software. Por ello identificarlos a tiempo permite asegurar que la entrega del software es correcta y que no habrá problemas en el funcionamiento. 2.3. Definiciones conceptuales 1) Análisis de Requisitos Fórmula las características operacionales que tendrá el sistema. Haciendo uso de técnicas que permitirán mejorar la confianza entre el cliente/usuario y el equipo de desarrollo. 2) Metodología DoRCU Su uso permite que los requisitos estén orientados al usuario, lo cual permite satisfacer sus necesidades. 3) Ingeniería de Requisitos o Requerimientos: La ingeniería de requisitos forma parte de la ingeniería de software que está enfocada en alcanzar objetivos reales, 13 responsabilidades, y restricciones de un sistema de software. Esta rama de la ingeniería se ocupa en indagar sobre la calidad de los requisitos siguiéndolos desde su definición, planteamiento de objetivos del requisito, y su evolución sobre el tiempo a través del desarrollo de software. (Hickey & Davis, 2004, p.65-84) 4) Reproceso “Acción tomada sobre un producto para que cumpla con los requisitos y que es distinto a una reparación el cual afecta o cambia partes del producto” (ISO 9000,2005) 5) Metodología SCRUM Permite entregables parciales y regulares del producto final para reducir la complejidad en el desarrollo usando técnicas que permitan recibir comentarios rápidos sobre el avance del proyecto para corregirlo y lograr satisfacer a los clientes. 6) Reparación Acción sobre un producto que no cumple con las características que solicita el cliente para volverlo en un producto aceptable. Se realiza un mantenimiento preventivo del producto para que no ocurra un posible error durante el uso del producto. 7) Adherencia al proceso: La adhesión a un proceso significa que el proceso se sigue en la medida que garantiza el cumplimiento del proceso. Si no se puede seguir el proceso, se detiene o se pone en espera hasta que se resuelva el problema y se alcance el cumplimiento. Se debe llevar a cabo una auditoría del estado y los problemas del proceso para definir el motivo del incumplimiento y luego desarrollar una solución para abordar los problemas y volver el proceso a los niveles de rendimiento deseados. 14 CAPÍTULO III: DESARROLLO DEL PROYECTO 3.1. Arquitectura empresarial (Seguimiento de solicitud de cambio) 3.1.1. Arquitectura de Información (Datos) DFD LÓGICO (Proceso de solicitud de cambios) El flujo comienza con el Stakeholder(entidad) el cual completa los campos requeridos para la solicitud de cambios en el sistema SIEBEL, el cual será aceptado por el área de Contact Center para revisarlo y priorizarlo. Se puede crear más requerimientos para cumplir la solicitud. El requerimiento se asignará al Product Owner quien creará la historia del usuario para que el área de desarrollo codifique y realice pruebas de regresión. Se liberará el producto mejorado. Figura 2: DFD LOGICO NIVEL 1 FUENTE: Propia DFD FÍSICO (Seguimiento de requisitos) Rally Stakeholder Producto Stakeholder Software Log in Selección de solicitud Situacion actual en Kanban 1 2 3 Seguimiento Consultar Respuesta del Mostrar Encontrar tarjetas del Estado en proceso estado de sistema estado de TO DO,DOING Y DONE solicitud solicitud asociadas a la solicitud Figura 3: DFD FISICO NIVEL 1 FUENTE: Propia 15 3.1.2. Arquitectura de Negocios (Procesos) AS-IS Figura 4: SOLICITUD DE CAMBIOS AS-IS FUENTE: Propia TABLA 1: Detalle del proceso de solicitudes de cambio. Actividad Descripción Tiempo Actor(es) Solicitar Cliente solicita un nuevo 8 min Stakeholder modificación requerimiento rellenando los campos Priorizar solicitud Se posiciona la solicitud del 2 min Área de Contact cliente sobre las demás para Center evaluarla. Resolver realizando El área de soporte procede a 30 min Área de soporte cambios de orientar al usuario en la (aprox) configuración configuración. Identificar defectos Los encargados del área 15 min Área de Producto o nuevos examinan si realizar el requerimientos cambio conlleva a más cambios. Asignar El encargado del área de 3 min Área de Producto requerimiento producto asigna el requerimiento al Product Owner Analizar Realiza el análisis del 2 horas Producto Owner requerimiento requerimiento analizando su (aprox) factibilidad Responder y Se especifica las razones de 15 min Área de Contact Justificar las la declinación del Center razones requerimiento Aprobar la Recibe las razones del área 2 min Stakeholder justificación de de Contact Center factibilidad 16 Crear y priorizar Se crea la historia del 60 min Product Owner historia en Rally usuario y se detalle de los (aprox) cambios a nivel funcional, mockup y criterios Analizar las Recibe la historia del usuario 25 min Área de Desarrollo historias del para identificar el costo y los (aprox) product backlog roles Entregar estimación El encargado del área 30 min Área de Desarrollo de tiempo de entrega cuanto tiempo (aprox) resolución (estado terminaran de des Rally :Ready) Codificar(estado Se lleva a cabo a el 2-4 días Área de Desarrollo Rally :In Dev) desarrollo del requerimiento (aprox) Pruebas QA El equipo de QA realiza 4 horas Área de Desarrollo (estado Rally :In pruebas de la modificación Test) en el sistema Verificar los Realizar las pruebas de 1 hora Product Owner cambios en UAT aceptación del usuario Cambiar el estado Analizar y comprobar los 10 min Product Owner a Rally:Completed resultados de las pruebas Validar solución Cliente da el visto bueno al 3 min Stakeholder producto. Realizar pruebas Encontrar bugs y verificar 15 min Área de desarrollo de regresión en que los casos de prueba ambiente pre - anteriores no hayan alterado producción el producto Generar solicitud Desarrollo manda solicitud 10 min Área de desarrollo de liberación para publicar la nueva versión del sistema Revisar CAB (para El CAB se encarga de 1 hora Área de las solicitudes de revisar la solicitud de TI,Desarrollo cambio) liberación. Enviar solicitud de Cliente solicita un nuevo 10 min Stakeholder urgencia requerimiento(emergencia) Revisar solicitud Se revisa la nueva solicitud 1 hora Contact Center (justificación y para implementarla. motivo) Describir cambios a Realización de cambios 3 horas Product Owner realizar y razones (emergencia) del sistema (aprox) de negocio Liberar a Comunicar la nueva versión 30 min Área de T.I. producción del sistema 17 TO-BE (Aplicación de seguimiento de solicitud) Figura 5: Aplicación de seguimiento de solicitud TO-BE Fuente propia Actividad Tiempo Ingresar a la aplicación 20 seg Devuelve formulario de registro 5 seg Rellenar formulario 8 min Crear nuevo usuario 10 min Ingresar usuario y contraseña 10 seg Consultar estado de solicitud 40 seg Cargar estado de la solicitud 20 seg Realizar seguimiento 5 min 3.1.3. Arquitectura de aplicación Figura 6: Login de aplicación 18 Figura 7: Lista de actividades Figura 8: TO DO 19 Figura 9: DONE Figura 10: Ingresar nueva solicitud 20 3.1.4. Arquitectura de Tecnológica Figura 11: Arquitectura de web aplicación Fuente: Propia 3.1.5. Factibilidad Económica TABLA 2 Flujo de caja 3.2. Aplicación de la Metodología Dorcu TABLA 3: ANALISIS FODA FORTALEZAS DEBILIDADES ● Servicios Premium ● Clientes constantemente insatisfechos ● Liderazgo en los equipos de los servicios ● Realización de nóminas para más ● Pequeñas relaciones de negocio de 500 empresas ● Falta de diversificación geográfica 21 ● 20% cuota de mercado de la industria (HRM) ● Servicio basado en la nube OPORTUNIDADES AMENAZAS ● Crecimiento de la industria ● Intensa competitividad ● Llegar a los propietarios de ● Falta de Seguridad pequeños negocios ● Competidores que pueden ● Alianzas para adquisiciones relacionarse con negocios pequeños ● Regulaciones gubernamentales 3.2.1 ETAPA 1: ELICITACIÓN O CAPTURA DE REQUERIMIENTOS TABLA 4: Recolección de requerimientos TIEMPO TIEMPO Requerimientos del usuario PLANEADO REAL Incluir masivamente ingresos y descuentos adicionales. 15 días 15 días Reconocer el seteo del campo: ¿Aun en 0? 10 días 10 días Corregir variable que permite traer el nombre del representante legal 8 días 6 días Habilitar certificados de 5ta, CTS y Trabajo para empleados con menos de 1 mes laborado. 10 días 3 días Habilitar el pago de gratificaciones fijas y variables para clientes IBM y Unilever 8 días 10 días Habilitar el pago de vacaciones en base a 22 días para el cliente IBM 10 días 10 días Estandarizar el reporte resumen para que sea igual al reporte del módulo individual o masivo 8 días 2 días Estandarizar el reporte certificado 5ta para que sea igual al reporte del módulo LBS individual o masivo 8 días 2 días Corregir el cálculo del impuesto de 5ta desde las rentas recibidas y devoluciones realizadas en el año en curso 10 días 10 días Calcular el pago de CTS con 2 bases computables 15 días 14 días Corregir defecto al generar reporte usando un conjunto con condición 8 días 8 días Corregir defecto al generar reporte usando conjunto TODOS 8 días 10 días Validar los respalde de fechas solo con las solicitudes que estén pendientes de aprobación 8 días 8 días Incorporar cambios promulgados por AFIP 8 días 8 días Corregir el cálculo del aporte ESSALUD para que reconozca la condición actual del tipo de afiliación 15 días 12 días Corregir la generación de periodos de vacaciones y saldo del periodo trunco 15 días 4 días Corregir la visualización de saldo por periodo pendiente 8 días 8 días Promediar de los ítem de tipo variable 8 días 2 días 22 TABLA 5: Capacidad de atención de requerimientos Prioridad Requerimientos Alta 12 Media 22 Baja 30 TOTAL 62 TABLA 6: Clasificación de requerimientos FUENTE: PROPIA TABLA 7: MATRIZ DE TRAZABILIDAD 23 3.2.2. ETAPA 2: ANÁLISIS DE REQUERIMIENTOS TABLA 8: PLANTILLAS O PATRONES 24 DASHBOARDS Figura 12: Requisitos por tipo El gráfico presenta que el requerimiento correctivo tiene un 56 % por encima del 44% de requerimientos evolutivos. En conclusión, en el mes de octubre se presentaron más requerimientos correctivos que otros debido a que el producto (Sistema eXpert) tiene que corregir errores o falencias encontradas por los usuarios. Figura 13: Requisitos por estado El gráfico presenta que de los requerimientos 72% fueron completados, seguido por un débil 11% que fueron aplazados, un 6% entre En desarrollo y Testeado ,por último un 5% fueron rechazados. En conclusión, en Octubre la mayoría de requerimientos fueron hechos 25 satisfactoriamente, sin embargo existe un 11% que fueron aplazados ya sea por nivel de complejidad o porque no aportan algo significativo al negocio. 3.2.3. ANÁLISIS DE REQUERIMIENTOS TABLA 9: GLOSARIO DE TÉRMINOS EXPRESIÓN DEFINICIÓN Requerimiento Es como el sistema debe reaccionar y comportarse Funcional frente a ciertas entradas. Requerimiento de Especifica el comportamiento del producto producto Requerimiento de Describe la necesidad del interesado en el proyecto interesados Requerimiento Su propósito es mejorar el sistema evolutivo Requerimiento Es una solicitud de mantenimiento al sistema correctivo Backlog Lista de requerimientos pendientes. CTS(Compensación Es el pago beneficio que tiene pagar el empleador al por Tiempo de trabajador durante la quincena Servicios) de mayo y noviembre de cada año Product Owner (PO) Responsable de la definición del producto desde la perspectiva del usuario, definiendo un backlog con los requerimientos y estableciendo su prioridad. Scrum Metodología ágil de desarrollo de software basada en el desarrollo incremental del producto. Rally Sistema utilizado por las áreas de Producto y Desarrollo para la gestión del Backlog y el estado los requerimientos. Criterios de Documento revisado por los stakeholders que Aceptación proporciona las características más relevantes para la (CA) aceptación del producto, proceso o servicio Release Notes Es un documento suplementario que se entrega a los stakeholders cada vez que un error (bug) se corrige o se hace una mejora en el producto. Hotfix Un hotfix es un paquete de correcciones al producto que se fabrica fuera del ciclo normal de desarrollo y pruebas, y que sirve para resolver bugs específicos dentro de una aplicación informática. Historia de usuario Describe la funcionalidad que se debe incorporar al sistema y que aporta valor al interesado QA(Quality Assurance) Son un conjunto de actividades basadas en normas que buscan cumplir con las necesidades que fueron definidos por el PO. UAT Son pruebas que tienen por objetivo que el cliente valide los requerimientos que pidió. Pruebas de regresión Permite controlar los componentes modificados para que las modificaciones no produzcan errores. Se repite pruebas anteriores hasta no encontrar defectos 26 CAB(Change Advisory El comité de aprobación de liberaciones es el Board) encargado de revisar las solicitudes de cambio a los sistemas, este comité está conformado por colaboradores del área de Desarrollo, Tecnología, Producto y Servicios. Mockup Es un diseño o prototipo que sigue los requerimientos dados por el cliente. Liberación Publicar la nueva versión del sistema informando al cliente sobre el lanzamiento mediante el sistema. El cual debe de cumplir con un estricto de plan de pruebas del producto Big Data Datos en gran cantidad (volumen masivo) StakeHolders Quienes solicitan o pueden ser afectados por las (Interesados) modificaciones de los productos, incluye las diferentes organizaciones/departamentos de la compañía. CAPITULO IV: RECURSOS Y CRONOGRAMA 4.1. Recursos TABLA 10: RECURSOS 27 4.2. Cronograma de ejecución 4.2.1 Cronograma del plan de tesis Tabla 11: Cronograma del plan de tesis 28 4.2.2 Cronograma de plan del proyecto de mejora de análisis de requisitos TABLA 12: Plan del proyecto de mejora de análisis de requisitos 29 CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES 5.1. Conclusiones Se concluye, que aplicar la metodología DoRCU para la mejora del análisis de requisitos mejorará el proceso de solicitud de cambios y junto a la aplicación otorgará una nueva experiencia al cliente. Según el resultado de las encuestas, los empleados creen que aplicar la Ingeniería de Requerimientos facilitara la labor del Propietario del producto y evitara reprocesos. Ofreciendo mejor comunicación entre el Propietario del producto, Scrum Master y Equipo de desarrollo. A partir del 4to mes se recuperará la inversión. En mes y medio la implementación de la metodología DoRCU. Los requerimientos cada mes son más correctivos esto significa que el sistema Expert será obsoleto pronto y se tendrá que relanzar un nuevo sistema. Además, esta investigación puede ser investigada más a fondo (metodología descriptiva) para futuras investigaciones que provean más información a ADP Payroll para que mejore completamente la fase de análisis de requerimientos. 5.2. Recomendaciones La investigación provee información para mejorar el análisis de requerimientos en ADP Payroll recomendaría aplicarlo ya que ayudará a que los proyectos tengan menos probabilidad de fracasar, la solución que sigue una metodología de Ingeniería de Requerimientos, pero se aconseja realizar la investigación con otra empresa fuera del rubro de la empresa (servicios de Gestión del Capital Humano), con el fin de comparar los resultados de ambos lados al aplicar esta solución Otra recomendación, para futuras investigación experimentar con otras metodologías de Ingeniería de Requerimientos con el fin de observar el comportamiento de las variables durante su aplicación. En especial con proyectos que usan metodologías ágiles ya que aplicar la ingeniería de requerimientos permitiría que no se generen más Iteraciones (Sprint)para corregir a última hora el producto software 30 CAPITULO VI: FUENTES DE INFORMACION 6.1. Referencias bibliográficas PMI (2014). PMI’s Pulse of che Profession: Requirements Management - A Core Competency for Project and Program Success [El pulso de la profesión de PMI: Gestión de requisitos: una competencia fundamental para el éxito de proyectos y programas]. Recuperado de https://www.pmi.org/- /media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements- management.pdf Boehm, B. & Basili, V. (2001). Software Defect Reduction Top 10 List [Lista Top 10 de reducción de defectos de software].Recuperado de https://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf Porras, E. (2017). Metodología ágil iconix en la calidad del producto software, Lima, 2017.(Tesis de doctorado, Universidad Nacional Federico Villarreal).Recuperado de http://repositorio.unfv.edu.pe/bitstream/handle/UNFV/2956/PORRAS%20FLORES %20EFRAIN%20ELIAS%20-%20DOCTORADO.pdf?sequence=1&isAllowed=y Cribilleros, J. & Pumachaico, K. (2017). Análisis de requerimientos para el área de contabilidad de la empresa productos avicola chicama SAC. basado en ingeniería de requerimientos.(Tesis de grado, Universidad Privada Antenor Orrego).Recuperado de http://repositorio.upao.edu.pe/bitstream/upaorep/2822/1/RE_ING_SIST_JAIME.CR IBILLEROS_KORY.PUMACHAICO_DATOS.PDF De la cruz, C.& Castro, G. (2015). Metodología para la adquisición y gestión de requerimientos en el desarrollo de software para pequeñas y medianas empresas (PYMES) del departamento de Risaralda. (Tesis de maestría, Universidad Tecnológica de Pereira).Recuperado de http://repositorio.utp.edu.co/dspace/bitstream/handle/11059/5589/0053D278.pdf?s equence=1&isAllowed=y Méndez, V. & Cruz, F. (2015). Mejora al control de acceso para laboratorios. Recuperado de https://www2.informatik.uni- hamburg.de/~cruznaranjo/06_VMendez_FCruz_2010_Chile.pdf 31 Báez.G. & Barba S. (2012). Metodología DoRCU para la Ingeniería de Requerimientos. Recuperado de http://www.inf.puc-rio.br/~wer01/Mod-Req-1.pdf Hickey A. & Davis A. (2004). A Unified Model of Requirements Elicitation [Un modelo unificado de elicitacion de requerimientos], Journal of Management Information Systems, Number 4/Spring. Recuperado de https://bit.ly/33Kbz74 ISO 9000 (2005). Sistemas de gestión de la calidad — Fundamentos y vocabulario. Recuperado de https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:es:term:3.2.5 32 ANEXOS Matriz de Consistencia 33 ENCUESTA FORMATO Nombre: ____________________________________________________ Cargo: _________________________ Pregunta 1: ¿Cree que al aplicar la ingeniería de requerimientos en ADP Payroll ayudara en la identificación y análisis de requerimientos? Si No Pregunta 2: ¿Cuál sería la consecuencia de no definir bien los requerimientos? Baja calidad del producto Reproceso Ambiguedad en el equipo Otro: ________________________________________________________ Pregunta 3: ¿Si fuera usted el cliente le gustaría hacer el seguimiento del avance de su solicitud? Si No Pregunta 4: ¿Se podría aplicar la ingeniería de requerimientos en metodologías ágiles? Si No Pregunta 5: 34 ¿Cree usted que la ingeniería de requerimientos ayudara al Product Owner a definir mejor los requerimientos del cliente? Si No Pregunta 6: ¿Para realizar el seguimiento a los requerimientos ,se podría usar una aplicación móvil que proporcione información del estado de los requisitos? Si No RESULTADOS ENCUESTA 35 RESULTADO PREGUNTA 2 Cuenta de Pregunta 2: Consecuencia de no definir bien Etiquetas de fila req Ambigüedad en el equipo 1 Calidad del producto 3 Demora del proceso 1 Reproceso 8 Total general 13 Ambigüedad en el equipo 8% Calidad del producto 23% Demora del proceso 61% 8% Reproceso RESULTADO PREGUNTA 3 Etiquetas de fila Cuenta de Pregunta 3: Seguimiento del req No 2 Si 11 Total general 13 11 2 NO SI 36 RESULTADO PREGUNTA 4 Etiquetas de fila Cuenta de Pregunta 4: IR en SCRUM No 5 Si 8 Total general 13 38% No Si 62% RESULTADO PREGUNTA 6 Etiquetas de fila Cuenta de Pregunta 6: Aplicación para el seguimiento No 3 Si 10 Total general 13 23% No Si 77% 37 PLAN DE IMPLEMENTACION Implementación de la metodología de Ingeniería de Requerimientos DoRCU y el desarrollo de una aplicación o app de seguimiento de solicitud de requisitos para evitar reprocesos en el desarrollo del producto software. Actividad Descripción Intervienen Tiempo Entrevista de Reunión para establecer Involucrados en 6 horas diagnostico los objetivos del el proceso de proyecto, establecer solicitud de responsables y cambios principales problemas en análisis de requerimientos. Modelamiento del Establecer lean canvas Ingeniero de 2 días negocio del negocio con la nueva Requerimientos (6 horas propuesta y realizar y Jefes del Área cada día) diagrama UML del de Producto y proceso de solicitud de Desarrollo cambios. Elicitacion de Realizar una matriz de Ingeniero de 3 días requerimientos trazabilidad de los Requerimientos requerimientos actuales, y Jefe del Área recolectar , evaluar , de Producto priorizar y validar requerimientos. Análisis de Establecer y aplicar Ingeniero de 16 días requerimientos técnicas de apoyo a la Requerimientos reducción de ambigüedades, plantillas o patrones y traducción a de los requerimientos a uno entendible por programadores, líder técnico y QA. Además de abordar un modelo lógico. Especificacion de Clasificar los Ingeniero de 7 días requerimientos requerimientos y elegir Requerimientos herramienta de especificación. Validación y Seleccionar la Ingeniero de 6 días certificación de documentación asociada Requerimientos los requerimientos al requerimiento(s) para certificarlos a través de la conformidad del usuario. Establecer plan Realizar el plan para la Ingeniero de 2 días para aplicación aplicación de apoyo y Requerimientos 38 de seguimiento de seguimiento del proceso y Jefes de solicitud de solicitud de cambios. Producto, Establecer alcance, Desarrollo y objetivos y presupuesto Pruebas de del proyecto ,además Software definir requerimientos funcionales y no funcionales de la aplicación. Diseño de la Seguir los Diseñador 8 días aplicación móvil requerimientos de la UI/UX y Jefe de aplicación aplicando un Producto diseño acorde a la necesidades del usuario final. Desarrollo de la Desarrollar la aplicación Desarrolladores 31 días aplicación móvil cumpliendo los y Jefe de requerimientos Producto funcionales y no funcionales Pruebas e Realizar pruebas de Testers y Jefe 15 días implementación Interfaz del de Pruebas de aplicación Usuario(UI),acciones de móvil usuario , de usabilidad y accesibilidad Capacitación y Realizar capacitación de Ingeniero de 10 días Resultado del uso al equipo de Requerimientos proyecto producto de la nueva y Jefe de aplicación de Producto seguimiento de solicitudes. 39 METODOLOGIA DE IMPLEMENTACION 1.Inicio del proyecto Reunión Inicial con el cliente - Acta de inicio - Levantamiento de requerimientos - Diagrama de proceso de solicitud de cambios (AS IS) 2.Planificacion Aplicación de la metodología DoRCU - Elicitacion de requisitos - Análisis de requisitos - Especificación de requisitos - Validación y aseguramiento de los requisitos 3.Desarrollo Plan y diseño de app móvil Desarrollo de la app de seguimiento de solicitud Plan de Pruebas 4.Implementacion Matriz de pruebas y Plan de pruebas funcionales Acta de capacitación Aceptación de usuarios a través de pruebas de usabilidad y accesibilidad 5. Producción Proyecto piloto de la aplicación móvil con casos de uso Aprobación del piloto Acta de cierre Gestión del cambio Gestión de Riesgo y Comunicaciones 40