universidad peruana union - core.ac.uk · 2.3.5 bpmn vs. uml ... 2.5 cobit 4.1 ... coso:committee...
TRANSCRIPT
UNIVERSIDAD PERUANA UNION
ESCUELA DE POSGRADO
UNIDAD DE POSGRADO DE INGENIERIA DE SISTEMAS
IMPLEMENTACIÓN DE UN MODELO BASADO EN FUNDAMENTOS DE S3M®
PROCESS MODEL ALINEADO A BUSINESS PROCESS MODELING Y SU
INFLUENCIA EN EL PROCESO DE MANTENIMIENTO DE SOFTWARE
APLICADO AL ÁREA DE DESARROLLO DE SISTEMAS DE DIGESI
UNIVERSIDAD PERUANA UNIÓN, FILIAL JULIACA.
Tesis presentada para optar el grado de magister en Ingeniería de Sistemas
con mención en Tecnologías de Información
Autor
Omar Santillán Aching
Lima, diciembre de 2014
ii
DEDICATORIA
A mí querida esposa, Graciela y mis hijos Joseph y Hannah,
quienes iluminan mis días y los hacen más felices
iii
AGRADECIMIENTOS
En primer lugar, quiero agradecer a Dios por
guiar mi camino.
A mi querida madre, por su apoyo desde el
principio y por creer en mí.
Al Mg. Sergio Valladares, porque que con su
ayuda y colaboración se realizó este trabajo de
investigación.
Al Dr. Guillermo Mamami, por darme la
oportunidad de llevar a cabo ésta
investigación.
A los doctores: Leonor Bustinza y Juan
Choque, por depositar su confianza en mí y
por darme la oportunidad de prepararme más y
capacitarme como profesional.
iv
INDICE GENERAL
DEDICATORIA ............................................................................................................... ii
AGRADECIMIENTOS ................................................................................................... iii
LISTA DE ABREVIATURAS, SIGLAS Y ACRONIMOS ............................................ x
RESUMEN ..................................................................................................................... xii
ABSTRACT .................................................................................................................. xiv
CAPÍTULO I .................................................................................................................... 1
INTRODUCCIÓN A LA INVESTIGACIÓN ................................................................. 1
CAPITULO II ................................................................................................................... 2
MARCO TEÓRICO ......................................................................................................... 2
2.1 Antecedentes de la Investigación ....................................................................... 2
2.1.1 Tesis de Fernanda Scalone ......................................................................... 2
2.1.2 Tesis de María Isabel Marante Estellés ...................................................... 2
2.1.3 Tesis de Patricia Bazán ............................................................................... 2
2.1.4 Tesis de Ann-Sofie Jansson ........................................................................ 3
2.2 Mantenimiento de software ............................................................................... 4
2.2.1 Tipos de mantenimiento ............................................................................. 5
2.2.2 Problemas de mantenimiento de software .................................................. 5
2.2.3 Definición de mantenimiento de software ................................................ 13
2.2.4 Diferencias entre operaciones, desarrollo y mantenimiento ..................... 15
2.2.5 Estado de software de mantenimiento de práctica.................................... 19
2.3 Gestión de procesos de negocio ....................................................................... 23
¿Qué es un proceso? ................................................................................................ 23
2.3.1 Procesos de negocio ................................................................................. 23
2.3.2 BPMN, BPD y el modelado de los procesos de negocios ........................ 26
2.3.3 Importancia de BPMN .............................................................................. 26
2.3.4 Destinatarios de BPMN ............................................................................ 26
2.3.5 BPMN Vs. UML ...................................................................................... 28
2.3.6 Elementos del lenguaje ............................................................................. 29
2.3.7 Diagramas BPM ....................................................................................... 30
2.3.8 Ciclo de vida de los procesos de negocios ............................................... 34
2.3.9 Clasificación de los procesos de negocios ................................................ 36
2.3.10 Ciclo de vida Business Process Managemen ............................................ 38
2.3.11 Estrategia de procesos de negocio (BPS) ................................................. 39
v
2.3.12 Diseño de procesos de negocio ................................................................. 39
2.3.13 Implementación de procesos de negocio .................................................. 39
2.3.14 Monitoreo de procesos de negocio ........................................................... 40
2.3.15 Gestión de cambio ........................................................................................ 40
2.3.16 Beneficios de BPM ................................................................................... 40
2.3.17 Tipos de Procesos BPMN ......................................................................... 40
2.3.18 Simbología BPMN ................................................................................... 41
2.4 Fundamentos de S3m® Process Model ........................................................... 44
2.5 COBIT 4.1 ....................................................................................................... 45
CAPÍTULO III ............................................................................................................... 55
MÉTODO DE LA INVESTIGACIÓN .......................................................................... 55
3.1 Problema general ............................................................................................. 55
3.2 Objetivo general ............................................................................................... 55
3.2.1 Objetivos específicos ................................................................................ 55
3.3 Hipótesis general .............................................................................................. 55
3.3.1 Hipótesis específicas................................................................................. 56
3.4 Tipo de Investigación ....................................................................................... 56
3.4.1 Investigación científica ............................................................................. 56
3.4.2 Investigación correlacional ....................................................................... 56
3.5 Diseño de Investigación ................................................................................... 57
3.5.1 Integración entre los Fundamentos de S3m® Process Model y Business
Process Modeling (BPM) ........................................................................................ 59
CAPÍTULO IV ............................................................................................................... 62
CONSTRUCCIÓN ......................................................................................................... 62
4.1 Primera Fase: Análisis y evaluación del proceso de mantenimiento actual del
área de Desarrollo de Software - DIGESI de tal forma que se puedan mejorar sus
procesos ...................................................................................................................... 62
4.1.1 Levantamiento de la información ............................................................. 62
4.1.2 Descripción y diseño de los procesos actuales de mantenimiento de
software área de Desarrollo y Soporte de Sistemas DIGESI – FJ .......................... 65
4.1.3 Evaluación de los procesos ....................................................................... 67
4.2 Segunda fase: Propuesta de un nuevo modelo alineado al modelo BPM y S3m®
Process Model ............................................................................................................. 68
4.3 Tercera fase: Comparación de los procesos de mantenimiento actuales de
acuerdo a la normativa de S3m® Process Model ....................................................... 68
4.4 Cuarta fase: Elaboración de un plan piloto de acuerdo a BPM y S3m® Process
Model 70
vi
4.4.1 Implementar una normativa en relación a las negociaciones entre los
usuarios y los mantenedores de software con las SLA (Interfaz 2 -S3m® Process
Model) 70
4.4.2 Implementación del servicio de mantenimiento por adelantado y Helpdesk
75
4.4.3 Elaboración del acuerdo SLA (Service Level Agreement) para el área de
Desarrollo Soporte de Sistemas –DIGESI (Ver anexo N° 6) .................................. 76
4.4.4 Implementación del proceso del Servicio de desarrollo de software (Interfaz
4- S3m® Process Model) ........................................................................................ 76
CAPÍTULO V ................................................................................................................ 78
VALIDACIÓN Y RESULTADOS ................................................................................ 78
5.1 Hipótesis específicas ........................................................................................ 78
5.1.1 He1: La implementación del modelo basado en Fundamentos de S3m®
Process Model alineado a Business Process Modeling influye positivamente en la
mejora del tiempo de resolución de pedidos de los clientes de Desarrollo y Soporte
DIGESI Universidad Peruana Unión Filial Juliaca. ................................................ 78
5.1.2 He2: La implementación del modelo basado en Fundamentos de S3m®
Process Model alineado a Business Process Modeling influye positivamente en la
mejora del número de atención de usuarios del Área de Desarrollo y Soporte de
Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca. ............................ 82
5.1.3 Hipótesis general ...................................................................................... 87
CONCLUCIONES Y RECOMENDACIONES ............................................................. 92
REFERENCIAS BIBLIOGRÁFICAS ........................................................................... 94
ANEXOS ........................................................................................................................ 97
vii
INDICE DE FIGURAS
Figura N° 1 - Diagrama de Mantenimiento de Software .............................................. 19
Figura N° 2- ¿Que es un proceso? ................................................................................ 23
Figura N° 3 - Representación gráfica de un proceso de compra simple ................ 24
Figura N° 4- Interpretación entre procesos de negocio .................................................. 25
Figura N° 5 - Elementos rotacionales de BPMN ........................................................... 30
Figura N° 6- Subtipos de mensaje en la modelización por eventos ............................. 31
Figura N° 7: Muestra el grado de detalle que puede obtenerse de un diagrama BPM en
función del nivel de abstracción que los modeladores deseen reflejar. ......................... 32
Figura N° 8 - Ejemplo de un proceso simple ............................................................... 33
Figura N° 9 - Segmento de un proceso con detalle ..................................................... 33
Figura 10 - Ciclo de vida de los procesos de negocio ................................................... 34
Figura N° 11 - Ciclo de vida de BPM .......................................................................... 39
Figura N° 12 - Diagrama de Calles o Simlanes Artefactos .......................................... 41
Figura N° 13- Objetos de flujo ..................................................................................... 42
Figura N° 14- Objetos de conexión ............................................................................... 43
Figura N°15 - Diagrama de Calles ................................................................................ 43
Figura N° 16 - Artefactos ............................................................................................... 44
Figura N° 17 -Administración de la información .......................................................... 48
Figura N°18 -Áreas de enfoque del Gobierno de TI ..................................................... 49
Figura N° 19 -Productos COBIT .................................................................................. 52
Figura N° 20 - Interrelaciones de los componentes de COBIT .................................... 53
Figura N° 21 - Integración BPM y S3m® Process Model ............................................. 61
Figura N° 22 - Proceso de mantenimiento de software ................................................. 67
Figura 23 - Diagrama Bizagi- Integración de los Fundamentos S3m® Process Model y
BPM ............................................................................................................................... 68
Figura N° 24- FreshDesk ............................................................................................... 76
viii
INDICE DE TABLAS
Tabla N ° 1: Problemas según el personal de mantenimiento de software .................... 10
Tabla N° 2: Definiciones generales aceptadas de mantenimiento de software ............. 14
Tabla N° 3: Metodología del proyecto .......................................................................... 57
Tabla N° 4: Integración de BPM alineado a los Fundamentos del S3m ....................... 60
Tabla N° 5: Comparación de los proceso de mantenimiento de software según S3m®
Process Model ................................................................................................................ 69
Tabla N° 6: Datos estadísticos según Hipótesis He1 ...................................................... 79
Tabla N° 7: Prueba de Kolmogorov-Smirnov para He1 ............................................... 80
Tabla N° 8: Estadísticas de muestras emparejadas para He1 ......................................... 80
Tabla N° 9: Correlaciones de muestras emparejadas para He1 ..................................... 81
Tabla N° 10: Prueba de muestras emparejadas para He1 ............................................... 81
Tabla N° 11: P-valor en SPSS ....................................................................................... 81
Tabla N° 12: Datos estadísticos según Hipótesis He2 .................................................... 84
Tabla N° 13 : Prueba de Kolmogórov-Smirnov para He2 ............................................... 85
Tabla N° 14: Estadísticas de muestras emparejadas para He2 ........................................ 85
Tabla N° 15: correlaciones de muestras emparejadas para He2 ..................................... 85
Tabla N° 16: P-Valor en SPSS ....................................................................................... 86
Tabla N° 17: Datos estadísticos según Hipótesis general .............................................. 87
Tabla N° 18: Prueba de Kolmogórov-Smirnov para hipótesis general ......................... 88
Tabla N° 19: Estadísticas de muestras emparejadas para hipótesis general .................. 89
Tabla N° 20: Correlaciones de muestras emparejadas ................................................... 89
Tabla N° 21: Prueba de muestras emparejadas para hipótesis general .......................... 89
Tabla N° 22 : P-Valor en SPSS ...................................................................................... 90
ix
ÍNDICE DE ANEXOS
Anexo 1 Presupuesto del Proyecto: ................................................................................ 97
Anexo 2- Entrevistas ...................................................................................................... 98
Anexo 3- Imágenes de proceso de mantenimiento de software ................................... 107
Anexo 4 - MOF de DIGESI .......................................................................................... 111
Anexo 5- Estado situacional de Soporte y Desarrollo de Sistemas 2014 ..................... 118
Anexo 6- SLA para Soporte y Desarrollo de Sistemas ................................................ 119
Anexo 7- Instalación de Bizagi Xpress ........................................................................ 124
x
LISTA DE ABREVIATURAS, SIGLAS Y ACRONIMOS
CMMi: Capability Maturity Model Integration
BPM: Business Process Management.
BPMN: Business Process Model and Notation
IMCM: Integración del Modelo de Capacidad y Madurez
MCM: Modelo de capacidad y madurez
IIS: Ingenierías de Software.
S3m® Process Model: Modelo de madurez de mantenimiento de software
DIGESI: Dirección General de Sistemas
SLA: Acuerdo de nivel de servicios
SMmm. Modelo de Madurez de Mantenimiento de Software
KPA. Proceso de Área Clave
FIPS: Federal Information Processing Standard (estándares federales de procesamiento
de la información)
ISO: International Organization for Standardization
IEEE: Instituto de Ingeniería Eléctrica y Electrónica
SWEBOK: Software Engineering Body of Knowledge
ITIL: Information Technology Infrastructure Library
Help-Desk: Mesa de ayuda.
ERP: Enterprise Resource Planning
SI/TI: Tecnologías de la información, Sistemas de Información
OMG: Object Management Group.
BPEL-WS: Business Process Execution Language
xi
BPD: Diagrama de Procesos de Negocio
SEI: Software Engineering Institute
BPMS: Business Process Management Suite
ACID: Atomicity, Consistency, Isolation, Durability
IEEE: Institute of Electrical and Electronics Engineers
SOA: Arquitectura orientada a servicios.
COSO:Committee Of Sponsoring Organisations Of The Treadway Commission
xii
RESUMEN
El presente trabajo de investigación muestra una solución respecto a la implementación
de un modelo basado en Fundamentos de S3m® Process Model alineado a Business
Process Modeling (BPM) y su influencia en el proceso de mantenimiento de software
aplicado al área de Desarrollo de Sistemas de DIGESI Universidad Peruana Unión Filial
Juliaca.
En primer lugar se levanta la información actual existente, en caso no existieren
documentos plasmados sobre el proceso de mantenimiento de software, se describen cada
uno de los procesos de mantenimiento de software, de la misma forma se realiza una
evaluación respectiva a través de los Fundamentos de S3m® Process Model alineado a
Business Process Modeling (BPM), de tal forma que se pueda apreciar su implementación
con el diseño actual del proceso de mantenimiento de software.
En segundo lugar, se presenta las propuestas de mejoras a través de una automatización
de los procesos, tomando las pautas de Fundamentos de S3m® Process Model. La parte
de diseño se realizará usando la nomenclatura BPMN y la aplicación que se usará es a
través de Bizagi, éste software nos ayudará a plasmar el diseño donde se pueda apreciar
el diseño de los nuevos procesos de mantenimiento de software.
En tercer lugar se efectuará las comparaciones respectivas a través de los Fundamentos
de S3m® Procesos Model respecto al modelo actual del proceso de mantenimiento de
software.
En cuarto lugar se realiza un plan piloto para la implementación a través de los
Fundamentos de S3m® Procesos Model alineado a Business Process Modeling (BPM)
donde se observan las mejoras respectivas en el proceso de mantenimiento de software.
Los cuales tienen como propósito principal determinar en cuánto influye el modelo de
Fundamentos de S3m® Procesos Model alineado a Business Process Modeling (BPM)
en los procesos de mantenimiento de software, es decir respecto a la integración de los
Fundamentos de S3m® Procesos Model y Business Process Modeling (BPM).
xiii
Donde se ven plasmado grandes resultados de la solución planteada, en caso el Área de
Desarrollo y Soporte determine el cumplimiento de las especificaciones propuestas,
dentro de ellos podemos mencionar: una buena documentación, mejora de los procesos
de mantenimiento de software y la eficiencia en los procesos de mantenimiento de
software.
Entonces podemos decir que la integración de los Fundamentos de S3m® Process Model
alineado a Business Process Modeling (BPM), si influye en el proceso de mantenimiento
de software aplicado al Área de Desarrollo y Soporte de Sistemas de DIGESI Universidad
Peruana Unión Filial Juliaca. Concluyendo que si es muy beneficiosa la implementación
planteada.
PALABRAS CLAVES: Mantenimiento, proceso, proceso de mantenimiento de software,
mantenimiento de software, automatización de procesos, BPM, BPMN, S3m® Process
Model, Business Process Model.
xiv
ABSTRACT
This research shows a solution regarding to the implementation of a system based on
Fundamentals of Process Model S3m® model aligned to Business Process Modeling
(BPM) and its influence on software maintenance process applied to the area of Systems
Development DIGESI Peruvian Union University Filial Juliaca.
First the existing current information is taken, if there were no proper documents reflected
on the process of software maintenance, describes each of the processes of software
maintenance, the same way a respective assessment is performed through the Basics of
S3m® aligned process Model Business Process Modeling (BPM), so you can appreciate
its implementation with the current design of software maintenance process.
Second, it is presented proposals for improvements through process automation taking
S3m® Basics Process Model patterns. The design part will be held using the BPMN
nomenclature and the application that being used is through Bizagi, this software will
help us to embody the design where you can appreciate the design of new software
maintenance processes.
Thirdly the respective comparisons will be carried out through the Fundamentals of
Process Model S3m® over the current model of software maintenance process.
Fourthly a pilot scheme for implementation is performed through the Basis aligned S3m®
Process Model Business Process Modeling (BPM) where the respective improvements
have been observed in the software maintenance process.
Which are mainly aimed at determining how much influence the model S3m® Process
Fundamentals aligned Model Business Process Modeling (BPM) in software maintenance
processes, i.e. the integration regarding Fundamentals of Process Model and S3m®
Business Process Modeling (BPM).
In which great results of the proposed solution are embodied, if the Department of
Development and Support determine compliance with the proposed specifications, among
them include: good documentation, improvement in software maintenance process and
efficiency in software maintenance processes.
xv
Then we can say that the integration of the Fundamentals of Process Model S3m® aligned
to Business Process Modeling (BPM), influences the process of software maintenance
Area Development and Support Systems DIGESI Peruvian Union University Filial
Juliaca. Concluding that is extremely beneficial the proposed implementation.
KEYWORDS: maintenance, process, software maintenance process, software
maintenance, process automation, BPM, BPMN, S3m® Process Model, Business Process
Model
1
CAPÍTULO I
INTRODUCCIÓN A LA INVESTIGACIÓN
El área que se ha elegido para el desarrollo de la investigación está ubicado en los
ambientes del Área de Desarrollo y Soporte de Sistemas- DIGESI Universidad Peruana
Unión Filial Juliaca.
Según [1]. Menciona lo siguiente: "Hoy en día vivimos en el mundo de negocios
cada vez más exigente, la necesidad de un mantenimiento completo de software nunca ha
sido mayor". El mercado mundial, ha resultado ser un mercado muy confuso respecto a
los proveedores de software, donde las empresas tienen hoy más que nunca la necesidad
de recibir un servicio de mantenimiento de software completo. La gran preocupación de
los empresarios es el mantenimiento del software de una manera más rentable y oportuna
mientras permanecen competitivos, dentro del presupuesto. Además se identifica otro
problema que las empresas de software no tienen ningún proceso definido para sus
actividades de mantenimiento de software, además los jefes de sistemas, consideran el
mantenimiento de software como pequeños proyectos. Generalmente, los proyectos de
software requieren del tiempo suficiente del personal, desde algunos días hasta algunos
meses, la cual colectivamente podrían mantener ocupado hasta la mitad de los analistas y
el personal de programación. El Área de Desarrollo y Soporte de Sistemas DIGESI
Universidad Peruana Unión Filial Juliaca, no está lejos de esa realidad.
De manera que este trabajo de investigación, se centrará en la implementación de
un modelo que busque las mejoras en el proceso de mantenimiento de software que
ofrezca soluciones a sus principales problemas, que hoy se enfrenta, a través de un modelo
basado en Fundamentos de S3m® Process Model alineado a Business Process Modeling
(BPM) y su influencia en el proceso de mantenimiento de software.
2
CAPITULO II
MARCO TEÓRICO
2.1 Antecedentes de la Investigación
Tenemos como antecedentes a los siguientes investigadores:
2.1.1 Tesis de Fernanda Scalone
En la tesis titulada: Estudio comparativo de los modelos y estándares de calidad
del software, donde menciona: “El mantenimiento del software es mucho más complejo
que el mantenimiento del hardware”, además que cuando un componente de hardware se
deteriora se sustituye por una pieza de repuesto, pero cada fallo en el software implica un
error en el diseño o en el proceso mediante el cual se tradujo el diseño en código de
máquina ejecutable”, por lo que podemos decir que el mantenimiento de software es una
etapa muy importante tomando en cuenta las etapas de Ingeniería de Software que muchos
no están tomando en cuenta. [2]
2.1.2 Tesis de María Isabel Marante Estellés
En la tesis titulada: Estudio comparativo de los modelos y estándares de calidad
del software, donde menciona que: “El mantenimiento del software es mucho más
complejo que el mantenimiento del hardware”. Menciona que cuando un componente de
hardware se deteriora se sustituye por una pieza de repuesto, pero cada fallo en el software
implica un error en el diseño o en el proceso mediante el cual se tradujo el diseño en
código de máquina ejecutables” [3]
2.1.3 Tesis de Patricia Bazán
En la tesis titulada: Un modelo de integrabilidad con SOA y BPM, donde
menciona que, “El enfoque abordado en este trabajo está orientado al diseño de procesos
y servicios, promoviendo la reutilización de código, la mejora continua de los procesos y
la especificación de requerimientos, comprometiendo todo el ciclo de vida de los
3
proyectos e integrando funcionalidades nuevas y existentes. El marco metodológico
propuesto se orienta a servicios y a procesos de negocio gestionados por tecnologías SOA
y BPM”. [4]
2.1.4 Tesis de Ann-Sofie Jansson
En la tesis titulada: Software Maintenance and Process Improvement by CMMI.
Donde menciona que: “Los sistemas de software están integrados a una amplia medida
en la sociedad. A medida que se implementan la necesidad de mantenimiento de software
surge. El esfuerzo y el gasto invertido en software de mantenimiento son de gran
magnitud. Organizaciones de software están tratando de evolucionar para ser más
eficiente y mejorar los resultados sobre sus clientes y las partes interesadas. Una forma
prometedora de lograr esto es la adopción de un modelo de mejora de procesos. Esta tesis
investiga el apoyo para el mantenimiento del software en el proceso de marco de mejora
CMMI (Capability Maturity Model Integration) creado por el SEI (Software Engineering
Institute). Los métodos utilizados son una revisión de la CMMI documentación y un
estudio de caso de una organización CMMI acreditado. La revisión se llevó a cabo
mediante la lectura y la búsqueda de apoyo de mantenimiento en la documentación. Se
fue encontrando apoyo explícito en las cotizaciones que se presentan con la discusión
relativa a los posibles trabajos de mantenimiento con los beneficios que podrían alcanzar.
El caso de la tesis se trata de una gran compañía de software con acreditación CMMI.
Hubo 23 empleados que contestan a un cuestionario sobre el mantenimiento y CMMI. La
revisión da la conclusión de que los beneficios son para ganar de adopción CMMI para
organizaciones de realizar el mantenimiento del software, sino que el apoyo no es que
detallado y el beneficio llega a un nivel general no explícitamente a las tareas básicas de
mantenimiento del software. El estudio de caso muestra las dificultades en materia de
mantenimiento y mejoras potenciales. Los cambios debidos a CMMI han introducido una
mayor carga de trabajo, sino también mejoras en la gestión de la configuración, la
documentación y los procesos más estables. No ha habido muchos estudios previos
realizados en el mantenimiento del software y CMMI. Los nuevos resultados de esta tesis
son la revisión del marco CMMI que diga explícitamente capear el apoyo que existe y en
qué medida. El caso de estudio de la tesis muestran nuevos resultados cualitativos en la
mejora de software mantenimiento y cambios en el proceso debido a CMMI”. [5]
4
2.2 Mantenimiento de software
En ingeniería del software, el mantenimiento de software es la modificación de un
producto de software después de la entrega, para corregir errores, mejorar el rendimiento,
u otros atributos. El mantenimiento del software es una de las actividades más comunes
en la ingeniería de software. Una percepción común del mantenimiento es que se trata
meramente de la corrección de defectos. Sin embargo, un estudio indicó que la mayoría,
más del 80%, del esfuerzo de mantenimiento es usado para acciones no correctivas [6].
Esta percepción es perpetuada por usuarios enviando informes de problemas que en
realidad son mejoras de funcionalidad al sistema. El mantenimiento del software y la
evolución de los sistemas fueron abordadas por primera vez por Meir M. Lehman en
1969. Durante un período de veinte años, su investigación condujo a la formulación de
las leyes de Lehman [7]. Principales conclusiones de su investigación incluyen que el
mantenimiento es realmente un desarrollo evolutivo y que las decisiones de
mantenimiento son ayudadas por entender lo que sucede a los sistemas (y al software)
con el tiempo. Lehman demostró que los sistemas continúan evolucionando con el
tiempo. A medida que evolucionan, ellos crecen más complejos a menos que se toman
algunas medidas como refactorización de código para reducir la complejidad.
Los problemas claves de mantenimiento de software son administrativos y
técnicos. Problemas clave de administración son: alineación con las prioridades del
cliente, dotación de personal, cuál organización hace mantenimiento, estimación de
costos. Son cuestiones técnicas claves: limitado entendimiento, análisis de impacto,
pruebas (testing), medición de mantenibilidad. El mantenimiento de software es una
actividad muy amplia que incluye la corrección de errores, mejoras de las capacidades,
eliminación de funciones obsoletas y optimización. Debido a que el cambio es inevitable,
se debe desarrollar mecanismos para la evaluación, controlar y hacer modificaciones. Así
que cualquier trabajo realizado para cambiar el software después de que esté en operación
es considerado trabajo de mantenimiento. El propósito es preservar el valor del software
sobre el tiempo. El valor puede ser mejorado ampliando la base de clientes, cumpliendo
requisitos adicionales, siendo cada vez más fácil de usar, más eficiente y empleando más
nuevas tecnología. El mantenimiento puede abarcar 20 años, mientras que el desarrollo
puede estar entre 1 y 2 años.
5
2.2.1 Tipos de mantenimiento
Según [8] menciona los siguientes tipos de mantenimiento de software:
Correctivo: Localiza y corrige defectos en un programa tras su entrega (ej. IVA al
15 %, agujeros de seguridad). Puede ser urgente o no urgente.
Adaptativo: Modificación para adaptarse a un cambio en el entorno (ej. Euro,
pantallas táctiles).
Perfectivo: Modificación para detectar y corregir fallos latentes antes de que se
conviertan en carencias. Modificación para modificar o añadir nuevas
funcionalidades. (Ej. firma digital en banca online).
Preventivo: Modificación para detectar y corregir fallos latentes antes de que se
conviertan en fallos operacionales. Mejorar las propiedades del software [9]. (Ej.
recodificar para aplicar patrones de diseño).
2.2.2 Problemas de mantenimiento de software
Varios autores han identificado (problemas) relacionados con el mantenimiento
que afecta el manejo y procesos de recursos de mantenimiento y sus herramientas/técnicas
específicas. Los problemas reportados en la información varían de acuerdo al punto de
vista de los autores quienes los identificaron y describieron. Estos problemas pueden ser
clasificados basados en dos puntos de vista:
Externo: Percepción de los clientes (por ejemplo: usuarios y accionistas)
Interno: Percepción de los administradores e ingenieros de mantenimiento de
software.
Desde el punto de vista del cliente (externo), los problemas principales informados
son de costo elevado, una entrega lenta de servicios, incoherencia de priorización ilógica
(las prioridades de sistemas de información interna y tecnología de información versus
las prioridades de los usuarios) [6]. Desde el punto de vista del personal de mantenimiento
(interno), los problemas claves de mantenimientos incluyen el software que ha sido mal
diseñado y programados, y la gran carencia de documentación de software [10]. Además,
se ha observado muy a menudo que el problema más grande en el mantenimiento de
software no es técnico sino su manejo. Examinemos ambos puntos de vista con más
detalle.
6
Percepciones de los usuarios acerca de los problemas de mantenimiento de
software. Se ha informado que una gran porción de costos de un ciclo de vida del software
de 50 a 90% vienen del mantenimiento de software, y Boehm declara que por cada dólar
gastado en desarrollo, se necesitarán dos para el mantenimiento [11]. También se ha
informado que gran parte de la percepción de los usuarios acerca del costo elevado de
mantenimiento pueden ser el resultado de una comunicación inadecuada por parte de los
administradores de mantenimiento acerca del tipo de trabajo de mantenimiento realizado
en beneficio de los clientes. Los administradores de mantenimiento agrupan con
frecuencia al mejoramiento con el trabajo correctivo juntos en su informe de manejo,
estadística y presupuesto, los que afectan los costos tanto en presupuestos como en
informes de mantenimiento. Esta suma mantiene los malos entendidos de los clientes
acerca de los servicios de mantenimiento y continúa la percepción errónea que el
mantenimiento de software está principalmente interesado con la corrección defectiva del
software. El mantenimiento de software tiene ciertas peculiaridades cuando se comparan
con el mantenimiento en otros dominios: mientras que el hardware y los componentes
mecánicos se deterioran cuando no hay mantenimiento, el software, por contraste, se
deteriora como resultado de múltiples actividades de mantenimiento [10]. Debido a que
las prácticas de software no han madurado al grado de las prácticas de hardware, el
mantenimiento se realiza al identificar uno o muchos componentes y reparándolas. El
mantenimiento de software a menudo requiere la reelaboración de muchas, si no es de
todas las partes del software. A múltiples actividades de mantenimiento se les culpa de
degradar aún más la estructura interna del software y de hacer las futuras actividades de
mantenimiento progresivamente más complicadas. Si no se pone en marcha ninguna
estrategia para controlar estos efectos, la calidad y estructura del software continúa en
deterioro. El Software en esta exposición a menudo se denomina como un software de
legado. El mantenimiento de software es también una labor intensa, con la mayoría de los
gastos derivados de los sueldos del programador. De hecho, con el coste del hardware ya
no representa la porción más grande de costos de IS/IT, el de la contratación de
programadores expertos ahora ocupa el primer lugar (por ejemplo más de $1.500 por día
para los servicios de consulta de un programador especializando en ERP el idioma del
software). Por el contrario, las percepciones de los usuarios de los costos también se ven
influenciadas por las molestias de servicios, lo que puede muchas veces tener un impacto
considerable en la percepción de los usuarios acerca de ambos la calidad de servicios y
sus costos. Por ejemplo, la carencia de producción y los errores de aplicaciones en el
7
soporte de software. Así como los retrasos y los costos altos en la implementación de los
cambios funcionales menores se citan a menudo como áreas de problema en el
mantenimiento de software. Además, las fallas del sistema de producción para el software
bajo mantenimiento ocurre al azar, y las peticiones se presentan en forma irregular.
Sin mecanismos de gestión de colas previamente acordado y maduro apoyado por
acuerdos detallados de nivel de servicio (SLA), los usuarios suelen obtener el servicio
que no cumple con sus prioridades reales y explícitas. Cuando obtienen un servicio de
mantenimiento pobre, algunos usuarios exageran y clasifican todas las peticiones como
alta prioridad y exigen que todos los problemas y peticiones sean abordados al mismo
tiempo.
Dadas que las fallas del sistema de producción son eventos al azar, y necesitan ser
abordados primero, dichos usuarios perciben que el trabajo en sus peticiones no está
progresando como ellos esperaban. Cuando los clientes se sienten frustrados con la
lentitud de los servicios, algunos considerarán en desarrollar una solución local para
resolver sus problemas, o podrían considerar que el mantenimiento de subcontratación o
de externalización trabaje por completo. Algunas de las percepciones de los usuarios
acerca de la lentitud de los servicios se basan en parte en un malentendido de la diferencia
fundamental entre el mantenimiento del hardware de la computadora electrónica y el
dominio de mantenimiento de software. Por ejemplo, un usuario de software no tiene una
idea clara de lo que constituye una actividad de mantenimiento de software, describiendo,
por ejemplo, cómo la reparación de una impresora o un componente de computadora
pueden implicar simplemente una actividad sustitutiva de componentes. También podría
observar que el diseño de equipos electrónicos se basa en una minuciosa
“modularización” de componentes que no crean efectos secundarios durante las
actividades de mantenimiento. Por otra parte, cuando está bien diseñado, el hardware
permite una evaluación completa y diagnóstico de componentes con sólo pulsar un botón!
Muchos usuarios, que no son familiares con el dominio de software, pueden percibir que
el software se mantiene de una manera similar. Desafortunadamente, el software aún no
ha madurado a esta etapa. Quedan muchos retos para la existencia de modularidad y auto-
evaluación en el software, particularmente debido a su falta de madurez; además, la
mayoría de software en la actualidad en uso tiene más de una década de antigüedad y no
incorpora este tipo de tecnología arquitectónica.
8
¿Es esta una representación de la percepción del usuario acerca del trabajo real
del personal de mantenimiento? ¿Está el personal de mantenimiento pasando más tiempo
en corregir los errores de software o en la prestación de servicios sobre el valor añadido?
Ya en el año 1980, Lienz and Swanson fueron los primeros en señalar que el 55%
de las peticiones, son dirigidas para que las organizaciones de mantenimiento se
preocupen más en las nuevas funciones en lugar de las correcciones de las fallas. El
modelo S3m propuesto aborda las correcciones de las fallas y nuevas funciones, así como
muchas otras actividades relacionadas con el mantenimiento. Esto fue confirmado diez
años después en otro estudio, basado en datos recopilados a lo largo de algunos años y
para cada categoría de actividad de mantenimiento [12]. De modo parecido [13] también
observa que en lugar de gastar desde un 50% hasta un 80% de sus esfuerzos en corregir
los problemas, pasan la mayor parte de su esfuerzo en la evolución del software, en
aumentar la funcionalidad de las peticiones de los usuarios, y en responder todo tipo de
preguntas acerca las reglas de negocio de software de aplicación. Desafortunadamente,
tales actividades sobre el valor añadido son mal comunicados y rara vez se informa en
detalle a los clientes como logros de mantenimiento mensual. En resumen, la percepción
de los usuarios no necesariamente indican bien el trabajo real del personal de
mantenimiento: “La porción más sustancial de los costos de mantenimiento se dedica a
acomodar los cambios funcionales necesarios en el software para mantener el ritmo con
las necesidades cambiantes de los usuarios”. Basado en los datos que habíamos revisado,
también observamos que los sistemas con el software bien estructurado eran capaces de
acomodar tales cambios”. El tiempo real, las peticiones de mantenimiento radical rara vez
incluye grandes mejoras utilizando técnicas de gestión de proyectos que puede tomar
múltiples años. El manejo de mantenimiento de software debería, por lo tanto, hacer un
trabajo mejor de comunicar las muchas actividades de mantenimientos, especialmente las
que tienen que ver con el valor añadido. Para hacer esto, es importante que la
administración entienda los procesos y servicios del personal de mantenimiento y sus
muchos desafíos. El personal de mantenimiento de software debe establecer y comunicar
mejor, que hay una cola eficiente y justa, y procesos prioritarios en su lugar que
administra y supervisa el estado de cada petición/evento de mantenimiento. Este proceso
de manejo en el mantenimiento de software tiene muchas entradas y fuentes de
interrupción, tales como:
Operadores que informan fallas del sistema.
9
Usuarios que se dan cuenta la degradación del servicio.
Los directores de proyectos de desarrollo que requieren información actual sobre
el software y entradas en estudios de reingeniería.
Clientes que requieren una información urgente.
Y cuando hay contención en las solicitudes para sus servicios, el personal de
mantenimiento de software deberá hacer referencia a la SLA y claramente indicar el
proceso en su lugar para gestionar prioridades basadas en criterios de servicio acordado
Las percepciones del personal de mantenimiento acerca de los problemas de
mantenimiento de software. El personal de mantenimiento a menudo se confronta con un
millón de líneas de la fuente de otra persona. Ellos deben familiarizarse rápidamente y
procesar los cambios urgentes sin perturbar el servicio. Para hacer el trabajo de
mantenimiento aún más desafiante, el software recién desarrollado frecuentemente tiene
una cantidad de cambios urgentes pendientes que los desarrolladores de software no
pudieron incluir en el desarrollo inicial, ya que habían estado bajo presión para entregar.
En un contexto en la que los recursos financieros son limitados, el análisis, diseño, y
prueba de las fases del proyecto inicial de desarrollo de software todos están bajo presión
y están a menudo parcialmente completados. Tales omisiones necesariamente conducen
a consecuencias graves para el mantenimiento de software. El personal de mantenimiento
siente que tiene poco o nada de control sobre la calidad del código heredado. Desde hace
tiempo se ha reconocido que un proceso inmaduro de desarrollo de software crea un sin
número de problemas en el producto final enviado al cliente y a las organizaciones de
mantenimiento, mientras un proceso maduro que claramente captura y dirige los
requisitos y los resultados de la especificación, un diseño estable bajará el costo de
mantenimiento. El uso de los procesos inmaduros crea trabajos atrasados que necesitan
ser abordados, en forma prioritaria, durante los primeros meses/año de operación del
nuevo software. En la industria se observa que procesar este trabajo atrasado crea un gran
incremento en el número de códigos durante los primeros tres años del mantenimiento de
software; Ésta es reconocida como una causa de un aumento de los costos de
mantenimiento y la insatisfacción de los clientes. La edad del software también tiene un
impacto en el costo de mantenimiento cuando el software se construye con las técnicas
más antiguas que no tomaron en cuenta los conceptos modernos arquitectónicos, con
estructuras complejas, códigos no estandarizados, y una pobre documentación, que guían
a una mayor dificultad en el trabajo de mantenimiento. La estructura de mantenimiento
10
de software también llega a ser cada vez más complejo ya que se modifica con el tiempo:
como el tamaño y la complejidad del software aumenta, se requiere un número cada vez
mayor de recursos para mantenerlo. Los problemas de mantenimiento de software pueden
ser agrupados en tres categorías: (1) problemas de alineamiento con los objetivos de la
organización, (2) los problemas de proceso, (3) problemas técnicos. Otro estudio de
participantes en las conferencias de mantenimiento de software presenta una lista de 19
problemas claves de mantenimiento, clasificados por su importancia, según la percepción
de los ingenieros de mantenimiento de software. La mayoría de los problemas reportados
por este estudio se puede categorizar en el proceso de mantenimiento y las categorías de
manejo.
Se ha identificado un segundo grupo de problemas como procedentes del proceso
de desarrollo de software. Cuando la calidad de desarrollo es deficiente, el software aún
se transfiere a la organización de mantenimiento con trabajos retrasados de cambio y
problemas que deberían haber sido abordados por los desarrolladores y las cuales son
difíciles de manejar con una pequeña cantidad de personas. Otros problemas que se
derivan de la misma fuente son:
Una deficiente trazabilidad a los procesos y productos que crearon el software.
Cambios que rara vez son documentados
Dificultad de manejo de cambio y monitoreo
Efectos dominó de los cambios de software.
Tabla N ° 1: Problemas según el personal de mantenimiento de software
Rank Problemas de mantenimiento
1 Administrando las prioridades de cambio (M)
2 Técnicas inadecuadas de Evaluación (T)
3 Dificultad para medir el rendimiento (M)
4 Ausencia o documentación incompleta de software (M)
5 Adaptación a cambios rápidos en organizaciones de usuarios (M)
6 Una gran cantidad de trabajos acumulados de peticiones para un cambio (M)
7 Dificultad en medir y demostrar la contribución del equipo de mantenimiento (M)
11
8 Moral baja debido a la falta de reconocimiento y respeto para el ingeniero de
mantenimiento (M)
9 No hay muchos profesionales en el dominio, especialmente unos con experiencia
(M)
10 Poca metodología, pocos estándares, procedimientos y herramientas específicas para
el mantenimiento (T)
11 Código de fuente en la existencia del software complejo y estructurado (T)
12 Integración, superposición e incompatibilidad de sistemas existentes (T)
13 Poco entrenamiento disponible para los ingenieros de mantenimiento (M)
14 No hay planes estratégicos para el mantenimiento (M)
15 Dificultad en la comprensión y la satisfacción de las expectativas del usuario (M)
16 Falta de comprensión y apoyo de los administradores de IS/IT (M)
17 El mantenimiento de software se ejecuta con tecnologías y sistemas obsoletas (T)
18 Poca voluntad o apoyo para la reingeniería de software existente (M)
19 Pérdida de experiencia cuando un ingeniero de mantenimiento deja el equipo o la
compañía (M)
(M): Problema de administración (T): Problema técnico
Fuente: problemas según el personal de mantenimiento de software [1]
12
Como los procesos de desarrollo de software mejoran progresivamente, hay un
interés renovado en la mejora de la pre-entrega y procesos de transición. Este proceso es
solicitado por el personal de mantenimiento para protegerlos de hacerse cargo de un
software no terminado o de baja calidad. La pre-entrega y actividades de transición
abordan el mantenimiento relacionado con los problemas identificados durante el proceso
del desarrollo del software para asegurar la alta calidad la cual, con suerte, facilitará la
transición final del software para el mantenimiento. Mediante el uso de un proceso, el
personal de mantenimiento asegura que el desarrollador eliminará los defectos antes de
que éstos surjan o antes de que el tiempo o presupuesto se acaben sin abordarlos. La pre-
entrega y procesos de transición pueden ser considerados como proceso de control de
calidad. La carencia de tal proceso puede guiar a costosos contratos de mantenimiento.
Muchos mantenedores de software también consideran que su estado profesional se
percibe como inferior a la de los desarrolladores; por ejemplo, a menudo se meten en un
aprieto y no tienen otra opción que aceptar el software recién desarrollado siendo forzados
en ellos. Los mantenedores también informan que son equipados, apoyados, y
comprendidos deficientemente por la administración, mientras son responsables las 24
horas del día/ los 7 días de las semana del funcionamiento y manejo apropiado de
software, y lo que es más importante, del soporte de todos problemas relacionados con el
cliente. La solicitudes de cambio frecuentes por parte de los usuarios, también son
identificados como una fuente de problemas; ambos el mundo de los negocios y la
tecnología evolucionan rápidamente, respaldados por un cambio rápido en el software y
también en el hardware. Finalmente, la dificultad en la comprensión y la satisfacción de
las expectativas de los usuarios es el decimoquinto clasificado. También se informa en
algunas organizaciones que los factores primarios que contribuyen a los costos altos de
mantenimiento de software son: la cantidad de programadores y sus experiencias, la
calidad de la documentación técnica y la documentación de usuario, las herramientas que
mantienen los ingenieros de mantenimiento, la estructura y a mantenibilidad del software,
y finalmente, los compromisos contractuales que gobiernan el mantenimiento de un
producto. Otro problema es el impacto de ambiente de trabajo en la productividad del
programador. Se han reportado que el ambiente físico (ruido e interrupciones) dificulta
su desempeño. Del mismo modo, hay insuficiente enseñanza de habilidades de
mantenimiento de software en los colegios, y lo que se enseña no siempre refleja lo que
el mantenimiento de software es en realidad, esto conlleva a una mano de obra con falta
de conocimiento acerca del mantenimiento relacionado con los procesos y técnicas.
13
¿Hay también un factor cultural que podría explicar por qué el mantenimiento de
software no es suficientemente visible y no se promueve? Por ejemplo, un estudio en
Japón describe cómo las percepciones de administradores, basados en la noción de que
las mejoras de software aumentan la satisfacción en una base diaria, parecen ser un
concepto más importante en una organización Japonesa que en una Europea o Americana
[14].
Sin un buen mantenimiento de software, estas organizaciones Japonesas informan
que perderían rápidamente la cuota del mercado. Cuando la cultura de calidad como por
ejemplo en Japón, las actividades de mantenimiento se benefician de una mayor
visibilidad y logran un mayor reconocimiento: la moral de un ingeniero de mantenimiento
es más alto y la administración de mantenimiento es más visible, para ambos
administradores y clientes [15] .En resumen:
Se han identificado y clasificado diecinueve problemas por el personal de
mantenimiento, y la mayoría de ellos son de gestión.
Los informes de las prácticas actuales en el mantenimiento de software no
destacan las actividades de valor agregado de mantenimiento de software.
El costo de los especialistas es significativa y creciente.
Todavía hay una pobre comprensión de la naturaleza y contribución del
mantenimiento de software.
La complejidad del software aumenta y la calidad disminuye con un
mantenimiento múltiple, si no hay una acción específica llevada a cabo para
abordar este problema.
El desarrollo de baja calidad tiene un impacto directo en los costos de
mantenimiento.
La cultura de la organización local y su percepción de la contribución del
mantenimiento tiene un impacto en su visibilidad y en la moral del personal de
mantenimiento.
Hay una falta de pruebas automatizadas y herramientas de diagnóstico para una
implementación exitosa del cambio. Hay una falta de capacitación de
mantenimiento de software a nivel de pregrado.
2.2.3 Definición de mantenimiento de software
El ciclo de vida de software se puede dividir en dos partes distintas:
14
El desarrollo inicial del software
El mantenimiento y uso del software
[16]. Afirma que “los cambios obligan a evolucionar a las aplicaciones de
software, o de lo contrario progresivamente llegarían a ser menos útiles y obsoletos”. El
mantenimiento es, por lo tanto, considerado inevitable para la aplicación de software que
se utiliza a diario por los empleados de todo el mundo en una organización cambiante.
Algunos conceptos y definiciones básicas de mantenimiento de software se
introducen ahora. El mantenimiento de software a menudo se enfoca en el software de
aplicación en nuestras organizaciones. Por ejemplo, el software de aplicación contiene
normas de negocio traducidas en funcionalidad que se usa y se desarrolla por las empresas
para llevar a cabo sus operaciones diarias. Es bastante diferente de otros tipos de software
que no están bajo el control directo de la organización o no contiene ninguna norma de
negocio. (Por ejemplo; los sistemas operativos, los sistemas de gestión de base de datos).
No decimos que estos tipos de software no requieren mantenimiento pero no es la
organización empresarial típica que los mantiene. La figura 1.3 presenta un panorama de
las definiciones a menudo citadas acerca del mantenimiento de software
(cronológicamente organizada)
Tabla N° 2: Definiciones generales aceptadas de mantenimiento de software
Definición- Interpretación Autor Año
“Cambios que se hacen a un software después de
su entrega al usuario”
Martin & McLure
(Martin 1983)
1983
“La totalidad de las actividades requeridas para
mantener al software en un estado operativo
después de su entrega”
FIPS (FIPS 1984) 1984
“El mantenimiento cubre el ciclo de vida del
software comenzando desde su implementación
hasta su retiro”
von Mayrhauser (von
Mayrhauser 1990)
1990
“La modificación de un código y documentación
asociada debido a un problema o la necesidad
para una mejoría. El objetivo es modificar el
ISO12207 (ISO 1995)
1995
15
producto de software existente mientras se
preserva su integridad”.
“La modificación de un producto de software
después de la entrega para corregir fallas, para
mejorar el rendimiento u otros atributos, o
adaptar el producto a un ambiente modificado”.
IEEE1219 (1EEE
1998a)
1998
“La totalidad de actividades requeridas para el
soporte, al costo más bajo, del software. Algunas
actividades empiezan durante su desarrollo
inicial pero la mayoría de las actividades son
aquellas después de su entrega”.
SWEBOK (Abran
2005)
2005
Fuente: Definiciones generales aceptadas de mantenimiento de software [1]
2.2.4 Diferencias entre operaciones, desarrollo y mantenimiento
En un contexto organizacional, el mantenimiento y desarrollo, del día a día, de
aplicación del software desarrollado internamente son típicamente la responsabilidad de
una unidad de soporte operativo dentro de la organización del software. Para el software
adquirido externamente, el mantenimiento de software no se realiza por una organización
utilizando el software. A veces hay una confusión acerca de quién lleva a cabo el
mantenimiento y dónde comienzan y terminan las actividades de mantenimiento. Las
actividades de operaciones informáticas son consideradas tan distintas de las actividades
de mantenimiento; Por ejemplo, el ISO 14764 los estándares internacionales de
mantenimiento de software especifica que las actividades operacionales (las copias de
seguridad, la recuperación y la administración de sistemas) son manejados por el equipo
de operaciones informáticas, y por lo tanto, quedan fuera del ámbito de estándares de
mantenimiento de software. Este ámbito es similar a lo que se menciona en la literatura
y, en práctica, gerentes o clientes distinguen claramente las operaciones
Informáticas de las actividades de mantenimiento de software. Todavía existe, sin
embargo, interfaces importantes entre los dos, para garantizar que la infraestructura de
soporte del software sea operativa y eficiente (Por ejemplo, los cambios de
administración, las llamadas de soporte concerniente a las fallas de sistema, recuperación
del entorno y de los datos en caso de desastres, recuperación de datos y reiniciar el trabajo,
16
las investigaciones de tiempo de procesamiento, programación automática, y la gestión
de espacio de disco y bibliotecas de cintas) [17]
Las diferencias entre el mantenimiento de software y las actividades de desarrollo
de software son a veces más difíciles de distinguir claramente. El desarrollo de software
posee una interfaz con el mantenimiento de software, la cual en algunas organizaciones a
veces es impreciso y mal definido.
A veces se confunden las diferencias cuando el desarrollador de software también
está involucrado, así como con el mantenimiento del software. Esta confusión es causada
por ciertas actividades de mantenimiento que son similares a aquellos encontrados en el
desarrollo (análisis, diseño, codificación, administración de configuración, pruebas,
revisión y documentación técnica). Aunque algunas actividades sean similares en teoría,
todavía deben adaptarse a un contexto de mantenimiento; Por ejemplo, tareas pequeñas
de mantenimiento están siendo realizadas por uno o dos programadores. Las
corporaciones que dependen de los ingresos del desarrollo y mantenimiento de software
se enfrentan ahora a una nueva cara, a nivel mundial el mercado competitivo con clientes
cada vez más exigentes. Con los servicios y productos disponibles a partir los vendedores
de todo el mundo, los clientes están insistiendo en que estos servicios y productos sean
de alta calidad, el costo lo menos posible, e ir acompañada de servicios de apoyo que
desafían a la competencia. Para satisfacer estas necesidades, la organización dinámica se
enfrenta a dos desafíos: debe tener la capacidad de desarrollar y mantener el software para
satisfacer las necesidades del cliente, y además debe tener acceso a un software que apoye
los procesos de negocio de la compañía. Ambas perspectivas de software (externos e
internos) deben ser fiables y bien mantenidas. Mantener el software de misión crítica de
una organización no es una tarea fácil y requiere la existencia de un Sistema de Gestión
para el Mantenimiento del Software. Un sistema adecuado de mantenimiento del software
tiene que satisfacer una serie de necesidades (los criterios de servicio de clientes de una
empresa y los criterios técnicos del dominio), así como maximizar el impacto estratégico
y optimizar el costo de las actividades de mantenimiento de software. Esto requiere que
la organización se comprometa a la mejora continua de los procesos de mantenimiento de
software. Según [18] sigue siendo cierto hoy en día: "El mayor problema de
mantenimiento del software no es técnica, sino gerencial”. Los problemas técnicos no se
quedan atrás. Ha existido muchas investigaciones en el área de los recursos, procesos y
las herramientas para el mantenimiento del software. Los problemas de la documentación
17
varían de acuerdo con la perspectiva del autor que describe los problemas. En general,
existen dos perspectivas: La percepción externa de los clientes, y la percepción interna de
los empleados y jefes de mantenimiento de software. Abordamos cada uno a su vez.
Desde la perspectiva externa, una serie de problemas de mantenimiento puede ser
identificada. De acuerdo a [6], el coste de mantenimiento es demasiado alto, la velocidad
del servicio de mantenimiento es demasiado lento y hay dificultad en la gestión de la
prioridad de las solicitudes de cambio. Desde la perspectiva interna, el trabajo de las
fuerzas de entorno de los mantenedores para trabajar en software mal diseñado y
codificado. También se informa que hay una tremenda falta de documentación. Según
[14], Los mantenedores de software encuentran tres categorías de problemas: Problemas
de organización de alineación percibidos, los problemas del proceso y los problemas
técnicos. Para agravar aún más estos problemas y mucho menos la investigación se ha
realizado para el software de mantenimiento que para el desarrollo. También hay un
menor número de libros y artículos de investigación sobre el tema, y muchos que son
comúnmente citados son 20 o más años de edad. Por otra parte, un gran número de los
más libros recientes de ingeniería de software sólo se refieren al mantenimiento de
software marginalmente, ya que se centran en un punto de vista de los desarrolladores.
Los libros más recientes son la nueva edición de [19] y dos obras editadas. Por desgracia,
también es un problema actual la falta de modelos de mejoras específicas, adaptables a
los procesos para el mantenimiento del software. Para abordar este problema y los otros
de mantenimiento presentado anteriormente, se propone un Modelo de Madurez para el
Mantenimiento del Software siguiendo el modelo del Capability Maturity Modelo de
integración (CMMi) del Software Engineering Institute. Las contribuciones de este
documento son tres: Primero identificamos las actividades únicas de mantenimiento de
software. Segundo examinamos las normas, la literatura seminal, y modelos de madurez
actuales para su posible contribución al mantenedores. Por último, se introduce un modelo
de madurez propuesta específica para el mantenimiento del software ye presentará su
validación industrial inicial. El documento está organizado de la siguiente manera. Nos
fijamos en el estado de la práctica de software de mantenimiento e identificar sus procesos
clave y sobre todo lo que hace que el mantenimiento único y diferente del desarrollo de
software. Les presentamos un inventario del Modelo de Madurez de Ingeniería de
Software, identifica aquellos que incluyen temas de mantenimiento de software, y se
analiza el modelo CMMi limitaciones con respecto a las actividades únicas de
mantenimiento de software. A continuación, se presenta una visión general de una
18
Propuesta de Modelo de Madurez de Mantenimiento de Software (SMmm) y su
arquitectura. Para ilustrar detalles de este modelo, los objetivos y las prácticas detalladas
de un Proceso de Área Clave (KPA).
19
Figura N° 1 - Diagrama de Mantenimiento de Software [1]
2.2.5 Estado de software de mantenimiento de práctica
En esta sección se discute el contexto de mantenimiento de software, sus
procesos claves y sus actividades únicas.
2.2.5.1 Contextos de mantenimiento de software
Es importante entender el alcance de las actividades de mantenimiento y el
contexto en el que el software de mantenedores trabaja sobre una base diaria.
Se presenta varias interfaces en un software típico de mantenimiento en el
contexto organizacional:
Los clientes y usuarios de mantenimiento de software (etiquetado 1)
Mantenimiento por adelantado y mesa de ayuda (con la etiqueta 2)
Departamento de Operaciones de Computadoras (con la etiqueta 3)
Clientes y
Usuarios Proveedores
Departamento de Desarrolladores de software
Aplicación de
mantenimiento de
Software
Mantenimiento por
adelantado y ayuda
de escritorio
Departamento de Operaciones de Computadoras
Nivel de Acuerdo de Servicio
Servicios de Mantenimiento
1 4
5
Apoyo en Proyectos de Desarrollo
Transición
inicial
Problemas de
resolución de
comunicaciones
Problemas
de tickets
Fallas en
llamadas
Requisitos
Estado 2
3
20
Desarrolladores (etiquetada 4)
Proveedores (marcada 5)
Teniendo en cuenta estas interfaces, cada una de las cuales requieren servicios
diarios, el jefe de mantenimiento debe de mantener las aplicaciones funcionando sin
problemas, quien debe de reaccionar rápidamente para restablecer el servicio cuando hay
producción problemas, cumplen o superan el nivel acordado de servicio, y mantienen a
la comunidad de usuarios confiados que tienen un equipo de soporte dedicado y
competente a su disposición que está en el seno del presupuesto acordado. Las
características clave de la naturaleza y el manejo de pequeñas peticiones de
mantenimiento tienen ha destacado en, por ejemplo:
Peticiones de mantenimiento vienen de más o menos al azar y no se pueden
explicar de forma individual en el proceso anual de planificación del presupuesto.
Peticiones de mantenimiento se revisan y se asignan las prioridades, a menudo a
nivel operacional la mayoría no requieren de la participación de la alta dirección.
La carga de trabajo de mantenimiento no se gestiona mediante técnicas de gestión
de proyectos, sino más bien técnicas de gestión de colas.
El tamaño y la complejidad de cada de pequeños solicitudes de mantenimientos
son tales que por lo general se puede manejar por uno o dos recursos.
La carga de trabajo de mantenimiento es para el usuario de servicios orientados y
aplicación corresponsabilidad orientados.
Las prioridades se pueden desplazar alrededor en cualquier momento y las
peticiones de mantenimiento de corrección de aplicación puede tener prioridad
sobre otros trabajos en curso.
Examinemos cada una de las interfaces del mantenedor de software típico. Una
primera interfaz importante se ocupa de los clientes y usuarios del software en
mantenimiento.
El cliente interfaz opera entre los directivos de las dos organizaciones.
Normalmente consiste en definir y la gestión de los servicios de mantenimiento de
software que se ofrecen. Se realizan mediante la negociación o discusiones sobre el
alcance del servicio, objetivos y prioridades, presupuestos, fijación de precios y las
actividades relacionadas con la satisfacción del usuario. Puede ser documentado en un
acuerdo contractual (o interna) llamado Acuerdo de Nivel de Servicio (SLA). Una vez
21
que este acuerdo está en su lugar, los usuarios pueden tener acceso a los servicios de
apoyo del personal de mantenimiento de software sobre una base diaria. La interfaz con
los usuarios difiere de la interfaz del cliente, ya que es más operativa en la naturaleza. Se
pueden localizar en muchas organizaciones diferentes de acuerdo a diferentes modelos
organizativos. El servicio Help-Desk a veces se ha encontrado para ser parte de la
organización de mantenimiento, a veces parte de la organización de las operaciones y a
veces situado en otra organización de soporte de producto independiente (organizaciones
de mantenimiento por adelantado. Lo que actualmente es popular es el Sistema de
Información / Tecnología de la Información (SI / TI) las organizaciones tienden a ofrecer
un recurso de ayuda centralizada para sus usuarios. El problema es la presentación de
informes de actividades realizadas a través de esta interfaz, han sido bien documentados
como parte de una taxonomía de gestión de problemas publicado por [20]. Para ser eficaz,
uno de los problemas mecanizados del proceso de presentación de informes que se utiliza
asegura una comunicación eficiente, para la resolución rápida de las fallas y otras
solicitudes de apoyo. A petición del usuario específico, a veces llamado un «billete»,
típicamente circular entre el servicio de asistencia, mantenimiento de software, y las
operaciones con el fin de aislar un problema.
Un tercero trata de la interfaz de mantenimiento importante con la organización
de operaciones con computadoras. Las operaciones de la computadora son los custodios
de la infraestructura de soporte de las aplicaciones de software. Por lo general se encargan
de todas las operaciones y los problemas de mantenimiento de apoyo relacionados con
las estaciones de trabajo, redes y plataformas. Llevan a cabo actividades tales como copias
de seguridad, recuperación y el sistema de administración de usuarios. Rara vez es
consciente de lo relacionados, con el intercambio de la información interna entre los
mantenedores de software y las operaciones. Esta interfaz incluye también actividades
menos frecuentes, como la coordinación de la recuperación del servicio tras fallos o
desastres con el fin de ayudar a restaurar el acceso a los servicios, dentro de los términos
acordados y condiciones de SLA.
La cuarta interfaz describe la relación entre los desarrolladores de software y los
mantenedores. Algunos desarrolladores se reservan el mantenimiento del software que
desarrollan. En este caso la interfaz entre el desarrollo de software y mantenimiento del
software no existe. Muchas organizaciones eligen tener una organización independiente
para el desarrollo y mantenimiento. Cuando existe esta interfaz, la raíz causa de varios
22
problemas de mantenimiento se puede remontar al desarrollo, y se reconoce que los
mantenedores deben participar y ejercer alguna forma de control durante la pre-entrega y
transición del software desde el desarrollo hasta el mantenimiento. Otros servicios que se
intercambian a través de esta interfaz. Muchas contribuciones son hechas por los
mantenedores para apoyar simultáneamente, y a veces puede ser involucrado en una serie
de grandes proyectos de desarrollo.
El conocimiento del mantenedor del software y carteras de datos es de gran valor
para los desarrolladores que necesitan para reemplazar o interfaz con el legado del
software.
Por ejemplo, algunas de las actividades claves del personal de mantenimiento serían:
El desarrollo de estrategias de transición para reemplazar el software existente;
El diseño de las interfaces temporales o nuevas a la herencia software
La verificación de las reglas de negocio o la ayuda en la comprensión de los datos
de legado existente del software
La asistencia en la migración de datos y el cambio o corte de nuevo software.
La última interfaz, se ocupa de las relaciones con un número cada vez mayor de
proveedores, Subcontratistas y Planificación de Recursos Empresariales (ERP)
Los mantenedores tienen un número de diferentes relaciones con los
proveedores. Por ejemplo:
Con subcontratistas que forman parte del equipo de mantenimiento y proporcionar
conocimientos específicos y mano de obra adicional durante las horas pico.
Con proveedores que tienen un contrato de mantenimiento anual que prestan
servicios de apoyo específicos para su software ya con licencia (es decir, ERP y
software propietario).
Con subcontratistas de mantenimiento que podrían reemplazar, parcial o
completamente, un software de la organización del mantenimiento de algunos
programas de la cartera de SI / TI.
Para garantizar un buen servicio a los usuarios, los mantenedores de software,
deben de desarrollar una buena comprensión de varios tipos de contratos y gestionar de
23
manera eficiente, para asegurar el desempeño del proveedor, que a menudo afecta a la
calidad de los servicios de apoyo.
2.3 Gestión de procesos de negocio
¿Qué es un proceso?
La Real Academia Española (RAE, n.d.) Afirma que un proceso es un conjunto
de las fases sucesivas de un fenómeno natural o de una operación artificial.
“Es cualquier actividad, o conjunto de actividades, que utiliza recursos para transformar
elementos de entrada en resultados”. ISO 9000:2005
(Perez, 2007) asegura que es una secuencia ordena de actividades repetitivas cuyo
producto tiene valor intrínseco para su usuario o clientes. A continuación se explicará
gráficamente en la siguiente figura.
Figura N° 2- ¿Que es un proceso? [21]
2.3.1 Procesos de negocio
Esta representación textual de actividades no otorga un orden a las mismas siendo
más apropiado representar este ordenamiento gráficamente. Esta representación gráfica
del proceso muestra un conjunto de actividades realizada en forma coordinada. La
24
coordinación entre las actividades se realiza por una representación explícita del proceso
usando las restricciones de ejecución. Para representar esta situación es preciso acordar
una notación posible de modo que cada símbolo tenga un significado unívoco. Esta
notación se conoce como BPMN (Business Process Modeling Notation).
Esta representación gráfica constituye un molde para el proceso de negocio. Todos
los procesos de órdenes de compra se instanciarán con este molde. La siguiente figura
muestra el diagrama del proceso de negocio (BPD Business Process Diagram) para un
proceso de seguimiento de orden compra simple. [4]
Figura N° 3 - Representación gráfica de un proceso de compra simple [22]
Siguiendo con las definiciones dadas por [23] indica que un modelo de proceso
de negocio constituye un conjunto de modelos de actividades y las restricciones de
ejecución entre ellas. Una instancia de proceso de negocio representa un caso concreto
dentro de los procesos operativos de una compañía. Estos procesos se componen de un
conjunto de instancias de actividades. Cada modelo de proceso de negocio es un molde
para múltiples instancias de tales procesos y cada modelo de actividad, lo es también para
múltiples instancias de actividades. Por abuso de lenguaje suele denominarse proceso de
negocio y actividad tanto al modelo como a la instancia de cada uno de ellos. Un modelo
de proceso de negocio, como se muestra en la figura anterior, puede usarse para
configurar un BPMS que asegurará que todas las instancias del modelo se ejecuten según
la especificación del mismo. Muchas organizaciones plasman en un BPMS todas sus
actividades como un componente de software centralizado. Este control centralizado es
conocido como orquestación de procesos. Aquí se representa las actividades del proceso
que lleva a cabo un vendedor cuando recibe la orden de compra. El proceso de negocio
del comprador se inicia con la ubicación de una orden de compra. Luego, en paralelo, se
25
recibe la factura y el producto. A continuación de la recepción de la factura se abona la
misma.
Figura N° 4- Interpretación entre procesos de negocio [22]
La interacción entre los distintos procesos de negocio se denomina coreografía.
Este término indica la ausencia de un agente central que controle las actividades
involucradas en el proceso. La interacción solamente envía y recibe mensajes. Para
realizar una interacción correcta los procesos deben acordar la coreografía. La realización
de los procesos de negocio vistos desde el punto de vista de sus participantes, permiten
aplicar cambios a sus actividades sin que cambie el proceso en sí mismo. Por ejemplo:
supongamos que se quiere aplicar como regla del negocio para el proceso de orden de
compra del vendedor, el hecho de que el producto no es enviado hasta tanto se abone la
factura. En este caso, el modelo de proceso del vendedor y su interacción con el
comprador, prácticamente no cambian. Lo que cambia es la orquestación interna del
proceso del vendedor.
26
2.3.2 BPMN, BPD y el modelado de los procesos de negocios
BPMI (Business Process Management Initiative) es un organismo sin fines de
lucro que ha desarrollado el estándar BPMN (Businnes Process Modeling Notation). La
primera especificación de dicho estándar fue publicada en mayo del 2004. Luego, en junio
de 2005, la BPMI se fusionó con la OMG para trabajar en conjunto sobre temas de BPM
(http://www.bpmi.org/). El objetivo primario de BPMN fue proveer una notación que sea
legible y entendible para todos los usuarios de negocios, desde los analistas que realizan
el diseño inicial de los procesos y los responsables de desarrollar la tecnología que
ejecutará estos procesos, hasta los gerentes de negocios encargados de administrar y
realizar el monitoreo de los procesos. BPMN también soporta un modelo interno que
permite generar ejecutables BPEL4WS [24]. Así, BPMN crea un puente estandarizado
para cubrir el hueco provocado por las diferencias entre el diseño de los procesos de
negocios y su implementación. BPMN define un diagrama de procesos de negocio (BPD)
basado en una técnica adaptada de diagramas de flujo para la creación de modelos
gráficos de operaciones de procesos de negocio. Un modelo de procesos de negocio, es
una red de objetos gráficos que representan las actividades (por ejemplo tareas) y los
controles de flujo que definen su orden de ejecución.
2.3.3 Importancia de BPMN
El mundo de los negocios ha cambiado drásticamente en los últimos años. Los
procesos son coordinados dentro de los límites naturales de las organizaciones y a su vez
pueden interactuar con procesos de otras organizaciones. Actualmente un proceso de
negocio abarca múltiples participantes y la coordinación puede ser compleja. Hasta la
aparición de BPMN no existía un estándar sobre técnicas de modelado desarrollado para
estos fines. BPMN ha sido desarrollado para proveer a los usuarios de una notación
estándar de forma análoga a como UML estandarizó el mundo de la ingeniería del
software [25].
2.3.4 Destinatarios de BPMN
BPMN está dirigido a los analistas de negocios en el alto nivel y a los
implementadores de procesos en el bajo nivel. Los analistas de negocio deberían entender
fácilmente un diagrama de proceso de negocio en BPMN. Los implementadores de
27
procesos deberían poder complementar el diagrama de proceso de negocio con mayor
detalle con la intención de representar el proceso en una implementación ejecutable.
BPMN está dirigido a usuarios y proveedores de servicios que requieren comunicar los
procesos de negocio de una forma estándar [26] [25]
28
2.3.5 BPMN Vs. UML
El advenimiento de BPMN, BPMS y sus lenguajes de ejecución no deja obsoleta
la necesidad de desarrollos de sistemas, como los que se logran utilizando UML (Unified
Modeling Languaje). Los desarrollos de sistemas siguen teniendo un rol importante en la
arquitectura de procesos en el ámbito empresarial. UML es un lenguaje que facilita a los
desarrolladores la especificación, visualización y documentación de modelos de sistemas
de software. Está dirigido en líneas generales a los arquitectos de software e ingenieros
de software. Fue desarrollado como un medio para mejorar el proceso de desarrollo de
software, desde el diseño de la arquitectura hasta la implementación de la aplicación, para
ser utilizado por personas con conocimientos técnicos (analistas de sistemas y
programadores) [27]. BPMN está dirigido a los analistas de negocio, arquitectos de
sistemas e ingenieros de software. Fue desarrollado para mejorar todo el ciclo de vida del
desarrollo de procesos desde el diseño de los mismos. Por su parte, UML es un lenguaje
desconocido para la mayoría de los analistas de negocio. UML define un número de
diagramas que se pueden clasificar en las siguientes categorías: estructura estática de la
aplicación, comportamiento dinámico y administración y organización de soluciones de
software. De estas tres categorías, el comportamiento dinámico es el utilizado para
modelar los procesos de negocio; los diagramas asociados son el de actividad UML y los
de casos de uso. BPMN está emparentado con UML por el hecho que ambos definen una
notación gráfica para los procesos de negocio similar a los diagramas de comportamiento
de UML. Sin embargo, BPMN y UML usan enfoques muy diferentes para modelar
procesos de negocio. Si bien los diagramas de actividad constituyen la herramienta UML
para modelar actividades de procesos, UML, en general, ofrece un enfoque orientado a
objetos para modelar aplicaciones. Mientras que BPMN toma un enfoque centrado en los
procesos. Este enfoque es mucho más natural e intuitivo para los analistas de negocios.
Con BPMN, el control y los mensajes de flujo entre procesos son primeramente
modelados. Luego, se definen implícitamente los modelos de objetos para los procesos
en vez de hacerse explícitamente como en UML. BPMN también ofrece la opción de
explicitar el modelado de objetos de negocio que pueden ser expuestos a través de
servicios de negocio en el flujo del proceso.
Otro aspecto que marca una fuerte diferencia es que UML no posee una vista de
implementación de los modelos de negocios. UML es un ensamblado de diagramas que
conforman un conjunto de buenas prácticas colectivas. Desafortunadamente, esto
29
significa que sus diagramas no fueron diseñados específicamente para trabajar
conjuntamente unos con otros. Como consecuencia, los desarrolladores sólo pueden
modelar una parte de sus aplicaciones con UML, el nivel de implementación detallado no
está cubierto. En contraste, BPMN define un único tipo de diagrama que posee múltiples
vistas derivadas de la misma meta-modelo de ejecución del proceso. Como resultado, la
implementación es una vista lógica del proceso en un lenguaje de ejecución de procesos
de negocio (BPML) [26] [28].
2.3.6 Elementos del lenguaje
Un diagrama de proceso de negocio está compuesto por un conjunto de elementos
gráficos. Los elementos utilizados para construir los diagramas fueron elegidos para ser
distinguibles unos de otros y utilizar las figuras que son familiares a la mayoría de los
diseñadores. Por ejemplo, las actividades se representan mediante rectángulos y las
decisiones mediante rombos. Cabe destacar que uno de los objetivos del desarrollo de
BPMN fue crear un mecanismo sencillo para la creación de modelos de procesos de
negocio y al mismo tiempo ser capaz de manejar la complejidad inherente de los mismos.
El enfoque adoptado para manejar estos dos requisitos fue la organización de la gráfica
de los aspectos de la notación en categorías específicas. Éste provee un pequeño conjunto
de categorías de notación que permite al lector del diagrama de procesos de negocio
reconocer fácilmente los elementos básicos y comprender el diagrama. Dentro de las
categorías básicas de elementos se pueden incluir variaciones adicionales o información
para soportar requerimientos complejos sin tener un cambio drástico en la mirada y
sentido básico del diagrama. Las cuatro categorías básicas de elementos son:
Flow objects (objetos que representan el flujo)
Connecting objects (objetos conectores)
Swimlanes (andariveles)
Artifacts [26](artefactos)
Las cuales se encuentran representadas en la figura siguiente [26] [28]
30
Figura N° 5 - Elementos rotacionales de BPMN [22]
2.3.7 Diagramas BPM
La notación BPM permite construir diagramas fáciles de leer y que además
manejen la complejidad traduciendo el diagrama en algún lenguaje de ejecución [28].
Para modelar un flujo sólo se modelan los eventos que ocurren. Las decisiones entre flujos
se modelan con gateways. El modelado está centrado en flujos y eventos, pero
principalmente en eventos, que son los elementos disparadores de determinadas
situaciones. Un proceso en el flujo puede contener subprocesos que cuando son atómicos
se denominan tareas. Los eventos se dividen en iniciales, intermedios y finales según se
desencadene al inicio, durante o al finalizar el flujo del proceso. Además, se puede
especificar “quién hace qué”, ubicando los procesos en pools que denotan quién hace la
tarea pudiendo particionar el pool en lanes o senderos. Típicamente un pool que
31
representa a toda la organización mientras que el lane representa un departamento dentro
de la misma. Puede extrapolarse esto mismo a funciones, aplicaciones y sistemas. Para
mejorar el poder expresivo, a estos tres tipos de eventos básicos se los divide a su vez en
eventos más complejos en función de la tarea que realizan. Esta sub-clasificación agrega
restricciones al modelo. Ejemplo: un evento “timer” nunca finaliza un flujo.
Figura N° 6- Subtipos de mensaje en la modelización por eventos [5]
La tabla anterior contiene los distintos sub-tipos de mensajes que pueden
utilizarse para novelizar los eventos.
32
Figura N° 7: Muestra el grado de detalle que puede obtenerse de un diagrama BPM en
función del nivel de abstracción que los modeladores deseen reflejar. [26]
33
Figura N° 8 - Ejemplo de un proceso simple [26]
El proceso graficado anteriormente, representa el proceso de recepción del pago
de un cliente. El proceso se inicia con la actividad de identificar la forma de pago. Se
prevén dos posibles formas de pago: en efectivo o con tarjeta de crédito. En cada caso se
aplica la actividad de aceptar el pago según la forma del mismo y se pasa a la actividad
de empaque de la mercadería, finalizando así el proceso.
Figura N° 9 - Segmento de un proceso con detalle [7]
En la figura anterior se representa una porción del proceso de “evaluación de
presupuestos”, mostrando el lazo iterativo de análisis de cada proveedor. Como se ve, se
detallan las sub-actividades consideradas dentro del proceso de “análisis del proveedor”
34
que encierra las actividades “Enviar requerimientos”, “Recibir cotización” y “Agregar
cotización”. Además intervienen eventos intermedios que consideran el tiempo dentro de
dicho proceso.
2.3.8 Ciclo de vida de los procesos de negocios
El ciclo de vida de los procesos de negocios se compone de fases cíclicas que no
implican necesariamente un orden temporal, pero sí una dependencia lógica, según lo
define M.Weske en [23]. Muchas de las actividades de diseño y desarrollo se llevan a
cabo dentro de cada fase. Es frecuente también que varias actividades concurrentes se
realicen dentro de cada etapa en forma gradual y evolutiva.
Figura 10 - Ciclo de vida de los procesos de negocio [5]
En la figura anterior se observa claramente un lazo iterativo sin fin donde ninguna
de las fases graficadas con rectángulos presenta un orden ni tampoco una condición de
salida. La administración como etapa central, sin flujo que la atraviese, pone de
manifiesto la presencia de esa fase en cualquiera de las anteriores. La fase de Diseño y
Análisis consiste en el estudio de la situación tanto desde el punto de vista técnico como
organizacional. Sobre la base de este estudio, se identifican, revisan, validan y representan
los procesos de negocios en un modelo. Sobre la base de este modelo se valida, se simula
y se verifica el proceso, siendo éstas las actividades de análisis. En la etapa de
configuración entra en juego la elección o no de un BPMS para dar soporte a la
implementación y despliegue de los procesos. En el caso de no utilizar un BPMS las
35
políticas y procedimientos (reglas del negocio) que deban cumplirse, tendrán que ser
desarrolladas como un componente más de la solución de software. La configuración y
sobre todo la integración con los sistemas operacionales, es un aspecto de mucha
importancia ya que muchos procesos de negocio están soportados actualmente sobre
sistemas de software existentes. Por otra parte, la configuración de un BPMS también
puede incluir aspectos transaccionales en el sentido estricto de la palabra y el
cumplimiento de las propiedades ACID (Atomicity, Consistency, Isolation, Durability).
Éste, si bien es un tópico resuelto en los sistemas de gestión de bases de datos, no lo es
aún en un BPMS. La Promulgación del sistema se asocia por analogía con la
promulgación de una ley o disposición, que consiste en hacer pública la misma. Esto
otorga al proceso de negocio un carácter diferente al del simple despliegue de una pieza
de software que implementa un proceso de negocio. Las instancias generadas con cada
modelo de un proceso de negocio, se ejecutan de una manera única y repetitiva
cumpliendo siempre las mismas restricciones y ejecutando la misma lista de actividades.
El BPMS controla y monitorea la ejecución de cada instancia de proceso de negocio. Esta
etapa requerirá de un BPMS necesariamente. La Evaluación de los modelos de procesos
de negocios constituye una etapa imprescindible para completar el ciclo de mejora
continua de los procesos. Requiere disponer de los registros de ejecución de dichos
procesos y la posibilidad de evaluar y simular cambios. Por último, la administración es
una fase permanente, por lo tanto se visualiza en el centro del ciclo ya que posee una
mirada directa a cada etapa y su complejidad variará en función del soporte de software
con que se cuente, el número de procesos que se modelen y las características propias de
la organización. Este modelo de ciclo de vida, pone de manifiesto cinco etapas que
marcan la necesidad de contar con varios participantes, cada uno de ellos con perfiles bien
marcados. M.Weske enumera algunos de dichos perfiles como: dueño del proceso,
diseñador, participante, responsable, arquitecto del sistema, experto en el negocio y
desarrollador. Lo importante de este ciclo de vida es facilitar que los participantes
cooperen en el diseño y despliegue de una solución que represente el proceso de negocio.
Sin duda este es un ciclo de vida muy vasto que amerita la necesidad de esbozar un marco
metodológico para su aplicación en la construcción de software.
En una arquitectura orientada a servicios, la funcionalidad de los aplicativos se
provee a través de servicios. Éstos se especifican de modo tal que puedan estar
desacoplados de la implementación. Este esquema es muy utilizado en arquitecturas para
36
integración de aplicaciones ya que torna reusable gran parte del código escrito con
anterioridad. Además, potencia la funcionalidad de las aplicaciones ocultando sus detalles
tecnológicos, una característica muy útil a la hora de disponer de funcionalidad básica
“vía Web”. Siguiendo con la definición de Weske, se describen a continuación los actores
o roles que intervienen en la definición del modelo del proceso de negocio. En esta tabla
se analiza la intervención de cada actor en cada una de las etapas del ciclo de vida de los
procesos de negocios. Es claro que el Dueño del Proceso tiene una participación
permanente, mientras que los demás actores presentan intervenciones específicas. Es
importante destacar la diferencia entre el Ingeniero del Negocio y el Diseñador del
Proceso. El primero presenta un perfil más analítico y no participa, al menos en forma
directa, de la fase de Configuración. Por su parte el Diseñador del Proceso adquiere una
intervención un poco más vinculada a lo técnico, si bien mantiene un perfil conceptual.
Los perfiles que ocupan la etapa de Promulgación como los Trabajadores del
Conocimiento, Responsables del proceso, Arquitectos y Desarrolladores, adquieren un
rol un poco más vinculado al área de IT, no llegando a ser eminentemente técnicos, salvo
el caso de los desarrolladores.
2.3.9 Clasificación de los procesos de negocios
Los procesos de negocio pueden clasificarse utilizando diversos enfoques.
Describimos en esta sección una taxonomía planteada por M.Weske en [6] que aborda
una gama bastante amplia de casos.
2.3.9.1 Según el nivel de granularidad
Desde este punto de vista, los procesos de negocios pueden calificarse como
organizacionales, cuando describen en el ámbito global los procesos de la organización y
marcan o delinean grandes objetivos, en contraposición con los procesos operacionales
que presentan un mayor nivel de detalle y suelen concluir en un modelo completo del
proceso de negocio. Claramente los procesos organizacionales representan el primer nivel
de abstracción posible en el análisis y los procesos operacionales son la explotación del
nivel anterior. La aplicación de metodologías iterativas y evolutivas sobre estos dos tipos
de procesos constituiría un modelo de procesos de negocio altamente detallado.
37
2.3.9.2 Según el alcance corporativo
Este aspecto permite clasificar a los procesos de negocios según se circunscriban
a la organización en sí misma, o la trasciendan hacia otras organizaciones. Esta
clasificación identifica procesos intraorganizacionales e interorganizacionales, marcando
la diferencia existente entre orquestación y coreografía de procesos como se describe. Los
procesos interorganizacionales son soportados generalmente por sistemas de gestión de
workflow en su versión tradicional o, en versiones más modernas, implementados o
desplegados como un conjunto de servicios ejecutados bajo un motor de orquestación.
Los procesos interorganizacionales requieren una coreografía de procesos donde se
requiere establecer contratos entre las partes que interactúan. En el caso en que se deba
interactuar con otras organizaciones, estamos en presencia de coreografía de procesos
donde se requiere establecer contratos con las partes con las que se interactúa.
2.3.9.3 Según el grado de automatización
El grado de automatización de un proceso de negocio permitiría clasificarlos en
totalmente automatizados, parcialmente automatizados o manuales. Este aspecto también
marca el grado de interacción humana que requiere la promulgación del proceso. Los
Trabajadores del Conocimiento (actores involucrados en la etapa de administración)
permiten marcar claramente el próximo paso a seguir para llevar a cabo un proceso, por
lo tanto, a la hora de construir un software es el indicado para determinar el flujo de la
interacción con el usuario.
2.3.9.4 Según el grado de repetición
Este aspecto permite tener una medida temprana del ROI (Return Of Investment)
de la aplicación de metodologías con enfoque en los procesos de negocio. Cuando el
grado de repetición es alto, la inversión hecha en su modelización y promulgación está
justificada ya que habrá muchas instancias que cumplen el mismo modelo. En el caso en
que no exista un alto grado de repetición, como puede suceder con procesos como el
diseño de un avión, se duda acerca de la justificación de la inversión. En estos casos se
puede poner el foco en modelizar la interacción entre personas mediante procesos de
negocio colaborativos, donde el objetivo de modelar y promulgar no está en la eficiencia
sino en obtener una traza de su ejecución para analizar los datos arrojados por la misma.
38
2.3.9.5 Según el grado de estructuración
Un proceso de negocio estructurado es el que prescribe las actividades a realizar
y las restricciones de ejecución de una única manera. Las decisiones que se toman durante
la promulgación del proceso fueron tomadas en tiempo de diseño. Los workflow de
producción son un ejemplo de tales procesos. Los procesos estructurados no permiten
saltear actividades no requeridas o ejecutar concurrentemente actividades definidas como
secuenciales. Para dar soporte a estas ideas surge el concepto de actividades ad-hoc,
donde el Trabajador del Conocimiento decide el orden y el momento de su ejecución
dentro de un proceso. Es en estos casos que adquiere mayor relevancia el uso de BPMS,
sobre todo aquellos que incluyen herramientas para realizar monitoreo de procesos (BAM
Business Activity Monitoring).
2.3.10 Ciclo de vida Business Process Management
[29] Sugiere los siguientes pasos para el ciclo de vida de BPM, lo cual varía
según las necesidades de la empresa
1. Estrategia de procesos de negocio.
2. Diseño de procesos de negocio.
3. Implementación de procesos de negocio.
4. Monitoreo de procesos de negocio.
5. Gestión de cambio.
Como se puede apreciar en la siguiente figura:
39
Figura N° 11 - Ciclo de vida de BPM [29]
2.3.11 Estrategia de procesos de negocio (BPS)
Este paso es fundamental para la empresa es como el eje principal para que todo
marche bien. En este paso se identifica la cantidad de procesos a mejorar, los factores
críticos de éxito y se adoptan los pasos a seguir con cada uno de ellos
2.3.12 Diseño de procesos de negocio
Es el análisis y optimización de los procesos relevantes identificados en la fase
anterior. El objetivo de esta fase es analizar los procesos ya existentes e identificar las
posibles mejoras, a dichos procesos, que se puedan realizar. Con esto se logra mejor
entendimiento del negocio.
Esta etapa es realizada por los analistas o por el propietario del negocio.
2.3.13 Implementación de procesos de negocio
Esta es la fase en la cual se busca implementar las mejoras ya diseñadas en las
fases anteriores como también implementar las posibles mejoras planteadas
anteriormente.
40
Es aquí cuando el proceso es documentado para así brindar futuros
mantenimientos al mismo, como también entrenamiento.
2.3.14 Monitoreo de procesos de negocio
Consiste en monitorear de manera continua los procesos de negocio que están
siendo ejecutados, con el propósito de encontrar indicadores claves de rendimiento y
poder ver los cambios y así mejorar estratégicamente de forma continua.
2.3.15 Gestión de cambio
Viene a ser la optimización de proceso, gracias al análisis de las fortaleza y
debilidades, rendimiento del proceso real y la utilización de métricas de estos se tendrá
una mejora continua tanto como en los sistemas, métodos, materiales, equipos, sistemas
de información y el cambio de mentalidad de las personas.
2.3.16 Beneficios de BPM
Los principales beneficios que trae consigo BPM son:
Adquirir la habilidad para diseñar, simular y monitorear procesos de manera
automática y sin la participación de usuarios técnicos.
Mejora la interacción con los clientes, satisface sus requerimientos y facilita el
camino hacia la superación de sus expectativas.
Permite gestionar adecuadamente los recursos, acorde con los requerimientos de
los procesos.
2.3.17 Tipos de Procesos BPMN
[30] Expresa que: El desarrollo de la implementación del modelado de procesos
se apoya en los siguientes paquetes:
Los elementos básicos BPMN.
Diagramas de proceso, que incluyen los elementos definidos en el proceso, las
actividades, datos, y la interacción humana.
Los diagramas de colaboración, que incluyen pools y flujo de mensajes.
Diagramas de comunicación, que incluyen pools, mensajes, y enlaces de
mensajes.
41
Como alternativa a la plena conformidad del modelado de procesos, existen tres
sub-categorías que se definen:
Descriptivo: Se refiere a los elementos visibles y los atributos utilizados en el
modelado de alto nivel. Está orientado a los analistas que han utilizado
herramientas Business Process Analysis (BPA) en los diagramas de flujo.
Analítica: Contiene a más de la mitad de construcciones que dan conformidad al
modelado de procesos. Tanto el enfoque descriptivo como el analítico se
concentran en los elementos visibles y en un subconjunto mínimo de apoyo a los
atributos o elementos.
Ejecutables: Se centra en lo que se necesita para la ejecución de los modelos del
negocio.
2.3.18 Simbología BPMN
Son cuatro las categorías básicas de elementos. Como podemos apreciar en la
figura.
Objetos de Flujo
Objetos de conexión
Figura N° 12 - Diagrama de Calles o Simlanes Artefactos [30]
42
Objetos de Flujo
Pueden ser de 3 tipos como podemos apreciar en la siguiente figura:
Objeto Descripción Figura
Evento
Es algo que sucede dentro de un proceso
de negocio. Estos eventos afectan al flujo
del proceso y tienen generalmente una
causa (trigger) o un impacto (result).
Existen tres tipos de eventos inicial,
intermedio y final
Actividades
Es un término genérico para un trabajo
ejecutado. Una actividad puede ser un
proceso del negocio, un proceso
secundario o una tarea
Gateway o
entradas
Es un elemento en forma de diamante que
representa decisiones, bifurcaciones de las
funciones o uniones dentro del diagrama.
Figura N° 13- Objetos de flujo [30]
Objetos de conexión
Los objetos de flujo se relacionan entre sí, en un diagrama para crear el esqueleto
básico de la estructura de un proceso de negocio. En la figura 6 podemos apreciar los 3
tipos de conexión con las que cuenta la BPMN
43
Objeto Descripción Figura
Flujo de
secuencia
Se usan para mostrar el orden de
los eventos que se realizan dentro
del proceso de negocio
Flujo de
mensajes
Se usan para indicar el flujo de
mensajes entre distintas entidades
de procesos
Flujo de
asociación
Usados para asociar diferentes
artefactos con objetos de flujo
Figura N° 14- Objetos de conexión [30]
Diagrama de Calles
Los swimlanes o diagrama de calles son utilizados por muchas técnicas de
modelado como mecanismo de organización de actividades en categorías visuales
separadas para ilustrar las diferentes capacidades funcionales o responsabilidades. En la
figura 15 se puede apreciar con mayor detalle.
Objeto Descripción Figura
Piscinas
Las piscinas identifican los
participantes dentro del flujo de
trabajo y son diferentes a las
actividades de otras piscinas
Carriles
Los carriles que están dentro de
una piscina, indican quién
realiza qué dentro de la empresa
y dónde ocurres estas
actividades, con el fin de dar
una mejor vista general del
proceso
Figura N°15 - Diagrama de Calles [30]
44
Artefactos
BPM cuenta con 3 tipos de artefactos como se puede apreciar en la figura N° 16.
Objeto Descripción Figura
Objetos de
datos
El objeto de datos es un
mecanismo para mostrar como
los datos son requeridos y
producidos por las actividades.
Son conectados a las
actividades asociadas
Grupo
Un grupo es representado por
un rectángulo y puede ser
usado para finalidades de
documentación o de análisis
Anotaciones
Las anotaciones son un
mecanismo para incluir
información adicional para el
lector de un diagrama BPMN.
Figura N° 16 - Artefactos [30]
2.4 Fundamentos de S3m® Process Model
[1]Indica lo siguiente: Recientemente, se dio inicio al método revolucionario de
mejora del mantenimiento de software del Dr. April y el Dr. Abran: El Modelo de
Madurez del Mantenimiento de Software (S3m).Los modelos de capacidad y madurez
(MCM) no son ideas nuevas, han estado presente desde inicios de los años 90. Los más
conocidos fueron ambos desarrollados por el Instituto de Ingenierías de Software (IIS) de
la Universidad Carnegie Mellon: El original (MCM) para el software y su sucesor, la
Integración del Modelo de Capacidad y Madurez (iMCM). La última versión es el iMCM
1.1, que forma la base para este modelo de madurez completo, propuesto única y
recientemente para el mantenimiento de software y esto es lo que creo que convertirá al
S3m en un éxito.
45
El (SEI) ha compilado una enorme cantidad de datos empíricos que claramente
muestran los beneficios de la mejoría de procesos, incluido la productividad mejorada,
costo, calidad, la satisfacción del cliente y el rendimiento de la inversión. Como un
instructor autorizado de (SEI) y un evaluador de (CMMi), he visto directamente los
resultados que pueden ser alcanzados por organizaciones que con entusiasmo adoptan
(CMMi), convirtiéndome así en un creyente firme en los modelos de madurez. Los
autores Dr. April and Dr. Abran han hecho una cantidad exhaustiva de investigaciones en
el desarrollo del S3m. Ellos han examinado las publicaciones por 30 años, analizando
minuciosamente modelos de madurez propuestos anteriormente, comenzando con el
trabajo revolucionario de mantenimiento de software de la pionera Mira Kajko Mattsson,
y compilando una lista completa de las mejores prácticas que abarcan cada aspecto del
mantenimiento del software. Las entrevistas con los especialistas y administradores
actuales de mantenimiento de software refuerzan lo que el personal de mantenimiento
necesita y busca en un modelo de madurez de mantenimiento de software. El modelo
resultante incluye cuatro dominios de proceso: El manejo de procesos de mantenimiento
de software, el manejo de petición de mantenimiento de software, ingeniería de la
evolución del software y el soporte a la ingeniería de la evolución del software. Aquellos
que en el campo del mantenimiento del software, quieren acotar sus esfuerzos en
mantenimiento, deberían considerar implementar este modelo en primer lugar. El Dr.
April y el Dr. Abran han expuesto las mejores prácticas en todo el mundo, creando una
guía básica que revolucionará la manera en que se trabaja.
2.5 COBIT 4.1
Para muchas empresas, la información y la tecnología que las soportan representan
sus más valiosos activos, aunque con frecuencia, son poco entendidos. Las empresas
exitosas reconocen los beneficios de la tecnología de información y la utilizan para
impulsar el valor de sus interesados (stakeholders). Estas empresas también entienden y
administran los riesgos asociados, tales como el aumento en requerimientos regulatorios,
así como la dependencia crítica de muchos procesos de negocio en TI. La necesidad del
aseguramiento del valor de TI, la administración de los riesgos asociados a TI, así como
el incremento de requerimientos para controlar la información, se entienden ahora como
elementos clave del Gobierno Corporativo. El valor, el riesgo y el control constituyen la
esencia del gobierno de TI. El gobierno de TI es responsabilidad de los ejecutivos, del
consejo de directores y consta de liderazgo, estructuras y procesos organizacionales que
46
garantizan que TI en la empresa sostiene y extiende las estrategias y objetivos
organizacionales. Más aún, el gobierno de TI integra e institucionaliza las buenas
prácticas para garantizar que TI en la empresa soporta los objetivos del negocio. De esta
manera, el gobierno de TI facilita que la empresa aproveche al máximo su información,
maximizando así los beneficios, capitalizando las oportunidades y ganando ventajas
competitivas. Estos resultados requieren un marco de referencia para controlar la TI, que
se ajuste y sirva como soporte a COSO (Committee Of Sponsoring Organisations Of The
Treadway Commission) Marco de Referencia Integrado – Control Interno, el marco de
referencia de control ampliamente aceptado para gobierno corporativo y para la
administración de riesgos, así como a marcos compatibles similares. Las organizaciones
deben satisfacer la calidad, los requerimientos fiduciarios y de seguridad de su
información, así como de todos sus activos. La dirección también debe optimizar el uso
de los recursos disponibles de TI, incluyendo aplicaciones, información, infraestructura
y personas. Para descargar estas responsabilidades, así como para lograr sus objetivos, la
dirección debe entender el estatus de su arquitectura empresarial para TI y decidir qué
tipo de gobierno y de control debe aplicar.
Los Objetivos de Control para la Información y la Tecnología relacionada
(COBIT®) brindan buenas prácticas a través de un marco de trabajo de dominios y
procesos, y presenta las actividades en una estructura manejable y lógica. Las buenas
prácticas de COBIT representan el consenso de los expertos. Están enfocadas fuertemente
en el control y menos en la ejecución. Estas prácticas ayudarán a optimizar las inversiones
habilitadas por TI, asegurarán la entrega del servicio y brindarán una medida contra la
cual juzgar cuando las cosas no vayan bien.
Para que TI tenga éxito en satisfacer los requerimientos del negocio, la dirección debe
implementar un sistema de control interno o un marco de trabajo. El marco de trabajo de
control COBIT contribuye a estas necesidades de la siguiente manera:
Estableciendo un vínculo con los requerimientos del negocio
Organizando las actividades de TI en un modelo de procesos generalmente
aceptado
Identificando los principales recursos de TI a ser utilizados
Definiendo los objetivos de control gerenciales a ser considerados
47
La orientación al negocio que enfoca COBIT consiste en alinear las metas de
negocio con las metas de TI, brindando métricas y modelos de madurez para medir sus
logros, e identificando las responsabilidades asociadas de los dueños de los procesos de
negocio y de TI. El enfoque hacia procesos de COBIT se ilustra con un modelo de
procesos, el cual subdivide TI en 34 procesos de acuerdo a las áreas de responsabilidad
de planear, construir, ejecutar y monitorear, ofreciendo una visión de punta a punta de la
TI. Los conceptos de arquitectura empresarial ayudan a identificar aquellos recursos
esenciales para el éxito de los procesos, es decir, aplicaciones, información,
infraestructura y personas. En resumen, para proporcionar la información que la empresa
necesita para lograr sus objetivos, los recursos de TI deben ser administrados por un
conjunto de procesos agrupados de forma natural. Pero, ¿cómo puede la empresa poner
bajo control TI de tal manera que genere la información que la empresa necesita? ¿Cómo
puede administrar los riesgos y asegurar los recursos de TI de los cuales depende tanto?
¿Cómo puede la empresa asegurar que TI logre sus objetivos y soporte los del negocio?
Primero, la dirección requiere objetivos de control que definan la meta final de
implementar políticas, procedimientos, prácticas y estructuras organizacionales diseñadas
para brindar un aseguramiento razonable de que:
Se alcancen los objetivos del negocio.
Se prevengan o se detecten y corrijan los eventos no deseados.
En segundo lugar, en los complejos ambientes de hoy en día, la dirección busca
continuamente información oportuna y condensada, para tomar decisiones difíciles
respecto a riesgos y controles, de manera rápida y exitosa. ¿Qué se debe medir y cómo?
Las empresas requieren una medición objetiva de dónde se encuentran y dónde se
requieren mejoras, y deben implementar una caja de herramientas gerenciales para
monitorear esta mejora. La Figura 1 muestra algunas preguntas frecuentes y las
herramientas gerenciales de información usadas para encontrar las respuestas, aunque
estos tableros de requieren indicadores, los marcado puntuación requieren mediciones y
los Benchmarking requieren una escala de comparación.
48
Figura N° 17 -Administración de la información [31]
Una respuesta a los requerimientos de determinar y monitorear el nivel apropiado
de control y desempeño de TI son las definiciones específicas de COBIT de los siguientes
conceptos:
Benchmarking de la capacidad de los procesos de TI, expresada como modelos de
madurez, derivados del Modelo de Madurez de la Capacidad del Instituto de
Ingeniería de Software
Metas y métricas de los procesos de TI para definir y medir sus resultados y su
desempeño, basados en los principios de Balanced Scorecard de Negocio de
Robert Kaplan y David Norton
Metas de actividades para controlar estos procesos, con base en los objetivos de
control detallados de COBIT
La evaluación de la capacidad de los procesos basada en los modelos de madurez
de COBIT es una parte clave de la implementación del gobierno de TI. Después de
identificar los procesos y controles críticos de TI, el modelo de madurez permite
identificar y demostrar a la dirección las brechas en la capacidad. Entonces se pueden
crear planes de acción para llevar estos procesos hasta el nivel objetivo de capacidad
deseado. COBIT da soporte al gobierno de TI al brindar un marco de trabajo que garantiza
que:
TI está alineada con el negocio
TI habilita al negocio y maximiza los beneficios
Los recursos de TI se usan de manera responsable
49
Los riesgos de TI se administran apropiadamente
La medición del desempeño es esencial para el gobierno de TI. COBIT le da
soporte e incluye el establecimiento y el monitoreo de objetivos que se puedan medir,
referentes a lo que los procesos de TI requieren generar (resultado del proceso) y cómo
lo generan (capacidad y desempeño del proceso). Muchos estudios han identificado que
la falta de transparencia en los costos, valor y riesgos de TI, es uno de los más importantes
impulsores para el gobierno de TI. Mientras las otras áreas consideradas contribuyen, la
transparencia se logra de forma principal por medio de la medición del desempeño.
Figura N°18 -Áreas de enfoque del Gobierno de TI [31]
Las áreas de enfoque son las siguientes:
Alineación Estratégica: Se enfoca en garantizar la alineación entre los planes de
negocio y de TI; en definir, mantener y validar la propuesta de valor de TI; y en alinear
las operaciones de TI con las operaciones de la empresa.
50
Entrega de valor: Se refiere a ejecutar la propuesta de valor a todo lo largo del ciclo de
entrega, asegurando que TI genere los beneficios prometidos en la estrategia
concentrándose en optimizar los costos y en brindar el valor intrínseco de la TI.
Administración de Recursos: Se trata de la inversión óptima, así como la administración
adecuada de los recursos críticos de TI, aplicaciones, información, infraestructura y
personas. Los temas claves se refieren a la optimización de conocimiento y de
infraestructura.
Administración de Riesgos: Requiere conciencia de los riesgos por parte de los
altos ejecutivos de la empresa, un claro entendimiento del apetito de riesgo que tiene la
empresa, comprender los requerimientos de cumplimiento, transparencia de los riesgos
significativos para la empresa, y la inclusión de la responsabilidades de administración
de riesgos dentro de la organización.
Medición de desempeño: Rastrea y monitorea la estrategia de implementación,
la terminación del proyecto, el uso de los recursos, el desempeño de los procesos y la
entrega del servicio, con el uso, por ejemplo, de Balanced Scorecard que traducen la
estrategia en acción para lograr las metas medibles más allá del registro convencional.
Estas áreas de enfoque de gobierno de TI describen los tópicos en los que la
dirección ejecutiva requiere poner atención para gobernar a TI en sus empresas. La
dirección operacional usa procesos para organizar y administrar las actividades cotidianas
de TI. COBIT brinda un modelo de procesos genéricos que representa todos los procesos
que normalmente se encuentran en las funciones de TI, ofreciendo un modelo de
referencia común entendible para los gerentes operativos de TI y del negocio. Se
establecieron equivalencias entre los modelos de procesos COBIT y las áreas de enfoque
del gobierno de TI (vea Apéndice II, Equivalencia entre procesos de TI y las áreas de
enfoque del gobierno de TI, COSO, recursos TI de COBIT y criterios de información
COBIT), ofreciendo así un puente entre lo que los gerentes operativos deben realizar y lo
que los ejecutivos desean gobernar.
Para lograr un gobierno efectivo, los ejecutivos esperan que los controles a ser
implementados por los gerentes operativos se encuentren dentro de un marco de control
definido para todo los procesos de TI. Los objetivos de control de TI de COBIT están
51
organizados por proceso de TI; por lo tanto, el marco de trabajo brinda una alineación
clara entre los requerimientos de gobierno de TI, los procesos de TI y los controles de TI.
COBIT se enfoca en qué se requiere para lograr una administración y un control
adecuado de TI, y se posiciona en un nivel alto. COBIT ha sido alineado y armonizado
con otros estándares y mejores prácticas más detallados de TI, (vea Apéndice IV). COBIT
actúa como un integrador de todos estos materiales guía, resumiendo los objetivos clave
bajo un mismo marco de trabajo integral que también se alinea con los requerimientos de
gobierno y de negocios.
COSO (y marcos de trabajo compatibles similares) es generalmente aceptado
como el marco de trabajo de control interno para las empresas. COBIT es el marco de
trabajo de control interno generalmente aceptado para TI.
Los productos COBIT se han organizado en tres niveles según Figura N°19,
diseñados para dar soporte a:
Administración y consejos ejecutivos
Administración del negocio y de TI
Profesionales en Gobierno, aseguramiento, control y seguridad.
Brevemente, los productos COBIT incluyen:
El resumen informativo al consejo sobre el gobierno de TI, 2ª Edición—Diseñado
para ayudar a los ejecutivos a entender por qué el gobierno de TI es importante,
cuáles son sus intereses y cuáles son sus responsabilidades para administrarlo.
Directrices Gerenciales / Modelos de madurez. Ayudan a asignar
responsabilidades, medir el desempeño, llevar a cabo benchmarks y manejar
brechas en la capacidad.
Marco de Referencia—Explica cómo COBIT organiza los objetivos de gobierno
y las prácticas de TI con base en dominios y procesos de TI, y los alinea a los
requerimientos del negocio.
Objetivos de control—Brindan objetivos a la dirección basados en las mejores
prácticas genéricas para todas los procesos de TI
Guía de Implementación de Gobierno de TI: Usando COBIT y Val TI 2ª Edición.
Proporciona un mapa de ruta para implementar gobierno TI utilizando los recursos
COBIT y Val TI
52
Prácticas de Control de COBIT: Guía para Conseguir los Objetivos de Control
para el Éxito del Gobierno de TI 2ª Edición – Proporciona una guía de por qué
vale la pena implementar controles y cómo implementarlos.
Guía de Aseguramiento de TI: Usando COBIT – Proporciona una guía de cómo
COBIT puede utilizarse para soportar una variedad de actividades de
aseguramiento junto con los pasos de prueba sugeridos para todos los procesos de
TI y objetivos de control.
El diagrama de contenido de COBIT mostrado según la Figura N°19, aquí se
presenta las audiencias principales, sus preguntas sobre gobierno TI y los productos que
generalmente les aplican para proporcionar las respuestas. También hay productos
derivados para propósitos específicos, para dominios tales como seguridad o empresas
específicas.
Figura N° 19 -Productos COBIT [31]
53
Todos estos componentes de COBIT se interrelacionan, ofreciendo soporte para
las necesidades de gobierno, de administración, de control y de auditoría de los distintos
interesados, como se muestra en la Figura N° 20.
Figura N° 20 - Interrelaciones de los componentes de COBIT [31]
COBIT es un marco de referencia y un juego de herramientas de soporte que
permiten a la gerencia cerrar la brecha con respecto a los requerimientos de control,
temas técnicos y riesgos de negocio, y comunicar ese nivel de control a los Interesados
(Stakeholders). COBIT permite el desarrollo de políticas claras y de buenas prácticas
para control de TI a través de las empresas. COBIT constantemente se actualiza y
armoniza con otros estándares. Por lo tanto, COBIT se ha convertido en el integrador de
las mejores prácticas de TI y el marco de referencia general para el gobierno de TI que
ayuda a comprender y administrar los riesgos y beneficios asociados con TI. La
estructura de procesos de COBIT y su enfoque de alto nivel orientado al negocio
brindan una visión completa de TI y de las decisiones a tomar acerca de la misma.
Los beneficios de implementar COBIT como marco de referencia de gobierno
sobre TI incluyen:
Mejor alineación, con base en su enfoque de negocios
Una visión, entendible para la gerencia, de lo que hace TI
Propiedad y responsabilidades claras, con base en su orientación a procesos
Aceptación general de terceros y reguladores
54
Entendimiento compartido entre todos los Interesados, con base en un lenguaje
común
Cumplimiento de los requerimientos COSO para el ambiente de control de TI
El resto de este documento brinda una descripción del marco de trabajo COBIT,
así como todos los componentes esenciales organizados por los dominios TI de COBIT
y 34 procesos de TI. Esto proporciona un útil libro de referencia para toda la guía
principal de COBIT. También se ofrecen varios apéndices como referencias útiles.
55
CAPÍTULO III
MÉTODO DE LA INVESTIGACIÓN
3.1 Problema general
¿De qué manera la Implementación de un modelo basado en Fundamentos de
S3m® Process Model alineado a Business Process Modeling influye en el proceso de
mantenimiento de software aplicado al área de Desarrollo y Soporte de Sistemas de
DIGESI Universidad Peruana Unión Filial Juliaca?
3.2 Objetivo general
Determinar la manera en que la implementación del modelo basado en
Fundamentos de S3m® Process Model alineado a Business Process Modeling influye
en el proceso de mantenimiento de software aplicado al área de Desarrollo y Soporte de
Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca.
3.2.1 Objetivos específicos
OE1: Determinar la manera en que la implementación del modelo basado en
Fundamentos de S3m® Process Model alineado a Business Process Modeling influye
en la mejora del tiempo de resolución de pedidos de los clientes de Desarrollo y Soporte
de Sistemas DIGESI Universidad Peruana Unión Filial Juliaca.
OE2: Determinar la manera en que la implementación del modelo basado en
Fundamentos de S3m® Process Model alineado a Business Process Modeling influye
en la mejora del número de atención de usuarios de Desarrollo y Soporte de Sistemas
DIGESI Universidad Peruana Unión Filial Juliaca.
3.3 Hipótesis general
La implementación del modelo basado en Fundamentos de S3m® Process
Model alineado a Business Process Modeling (BPM) influye positivamente en el
proceso de mantenimiento de software aplicado al área de Desarrollo y Soporte de
Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca.
56
3.3.1 Hipótesis específicas
He1: La implementación del modelo basado en Fundamentos de S3m® Process
Model alineado a Business Process Modeling influye positivamente en la mejora del
tiempo de resolución de pedidos de los clientes de Desarrollo y Soporte de Sistemas de
DIGESI Universidad Peruana Unión Filial Juliaca.
He2: La implementación del modelo basado en Fundamentos de S3m® Process
Model alineado a Business Process Modeling influye positivamente en la mejora del
número de atención de usuarios de Desarrollo y Soporte de Sistemas de DIGESI
Universidad Peruana Unión Filial Juliaca.
3.4 Tipo de Investigación
Por la naturaleza la tesis reúne las características principales para ser
denominada como una investigación tecnología mixta, es decir investigación científica
y correlacional.
3.4.1 Investigación científica
Según Mario Bunge: Hemos convenido en que un enunciado fáctico general
susceptible de ser verificado puede llamarse hipótesis, lo que suena más respetable que
corazonada, sospecha, conjetura, suposición o presunción, y es también más adecuado
que estos términos, ya que la etimología de “hipótesis” es punto de partida, que
ciertamente lo es una vez que se ha dado con ella.
3.4.2 Investigación correlacional
La utilidad y le propósito principal de los estudios correlaciónales son saber
cómo se pueden comportar un concepto o variable conociendo el comportamiento de
otras variables relacionadas. Este tipo de estudio mide las dos o más variables que se
desea conocer, si están o no relacionadas con el mismo sujeto y así analizar la
correlación.
Dos variables están correlacionadas cuando al variar una variable la otra varia
también. Esta correlación puede ser positiva o negativa, es positiva cuando los sujetos
con altos valores en una variable tienden a tener altos valores en la otra variable, y es
negativa cuando los sujetos con altos valores en una variable tienden a mostrar bajos
57
valores a en la otra variable. Este tipo de estudio evalúa el grado de relación entre dos
variables. [32]
3.5 Diseño de Investigación
La metodología aplicada para la solución del problema está basada en el Modelo
Business Process Modeling (BPM) alineado a los Fundamentos de S3m® Process
Model en la siguiente tabla se describe paso por paso la metodología y lo que involucra
a través de 4 fases importantes:
FASE 1: Análisis y evaluación del proceso de mantenimiento actual del área de
Desarrollo y Soporte de Sistemas de DIGESI Universidad Peruana Unión, de tal forma
que se pueden mejorar sus procesos.
FASE 2: Propuesta de un nuevo modelo alineado al modelo BPM y la normativa de
S3m® Process Model
FASE 3: Comparación y Alineación los procesos del modelo BPM y la normativa de
S3m® Process Model a los procesos de mantenimiento de Software de DIGESI
FASE 4: Elaboración de un Plan Piloto del modelo BPM y S3m® Process Model
Tabla N° 3: Metodología del proyecto
FASE 1 - ANÁLISIS Y EVALUACIÓN DEL PROCESO DE MANTENIMIENTO
ACTUAL DEL ÁREA DE DESARROLLO Y SOPORTE DE SISTEMAS DE
DIGESI DE TAL FORMA QUE SE PUEDEN MEJORAR SUS PROCESOS
Entrevistas y
reuniones
Levantamiento de la información a través de entrevistas,
reuniones dirigidas al personal de Desarrollo y Soporte de
Sistemas.
Evaluación del
mapas de procesos
de Mantenimiento
de Software
Se realizó una evaluación de los procesos de Mantenimiento de
software actuales con las que cuenta el área respectiva.
58
Diseñar los
procesos, en caso
no hubiera.
Se diseñó lo procesos actuales de Mantenimiento de software
FASE 2. PROPUESTA DE UN NUEVO MODELO ALINEADO AL MODELO
BPM Y LA NORMATIVA DE S3M® PROCESS MODEL
Elaboración de
normativas y
diseño de procesos
alineado BPM y
S3m Process
Model.
Se elabora la documentación pertinente, teniendo en cuenta las
normativas de S3m Process Model
Elaboración de
nuevo diseño de
procesos alineado
al modelo BPM y
la normativa de
S3m® Process
Model
Después de haber realizado la entrevista respectiva, se diseñó
los nuevos procesos de Mantenimiento de software siguiendo
los lineamientos de S3m® Process Model. Usando como
herramienta la aplicación Bizagi.
FASE 3. COMPARACION Y ALINEACION DE LOS PROCESOS DEL MODELO
BPM Y LA NORMATIVA DE PROCESS MODEL S3M A LOS PROCESOS DE
MANTENIMIENTO DE SOFTWARE DE DIGESI
Alineación de
nuevos procesos
Una vez diseñado el nuevo mapa de procesos de Mantenimiento
de Software. Se presenta en una reunión para buscar la
aprobación de la nueva documentación que va a ingresar. Aquí
se validan los documentos.
FASE 4. ELABORACIÓN DE UN PLAN PILOTO DEL MODELO BPM Y
PROCESS MODEL S3M
59
Elaboración de
plan piloto Con la presentación del plan con la nueva forma de trabajo.
Realizar talleres
Se invita a todo el equipo de trabajo, para la realización de
talleres que incentiven y motiven a la adaptación de las nuevas
formas de trabajo.
Validación Se valida todos los documentos del plan.
Fuente: Adaptación propia [33]
3.5.1 Integración entre los Fundamentos de S3m® Process Model y Business Process
Modeling (BPM)
Para realizar la integración respectiva se ha separado los siguientes componentes:
Componentes de usuarios: Se realiza el primer proceso de mantenimiento de
software, los usuarios interactúan en este proceso son: el Área que provee en
servicio de mantenimiento de software y los usuarios. Se va a tener en cuenta el
SLA(Acuerdo de nivel de servicios)
Componente de mantenimiento por adelantado y Helpdesk. Aquí lleva acabo los
procesos ,donde se efectúa la recepción de los pedidos, evaluación de los pedidos
urgentes y los no urgentes, además se maneja un sistema de gestión de colas,
solución con tikets , en caso de que el pedido sea para temas de operaciones de
computadores, el pedido es transferido al área respectiva. Acondicionamiento del
Freshdesk para solución con tikets.
Componente de Servicios de mantenimiento de operaciones de computadoras. En
caso de que el Helpdesk o mantenimiento por adelantado recibe un pedido por
parte del usuario, en entonces el pedido es transferido al Área de Servicios de
mantenimiento de operaciones de computadoras.
Componente de Desarrollo. El Área de Desarrollo y Soporte de Sistemas, deberá
tener fuertes lazos de relacionamiento con el área de Mantenimiento de software,
aquí se realiza la entrega de la documentación de cada uno de los sistemas
correspondientes, esto se da al finalizar el desarrollo respectivo de los sistemas.
60
Tabla N° 4: Integración de BPM alineado a los Fundamentos del S3m
Usuarios Mantenimiento por
adelantado y Helpdesk
Servicio de
mantenimiento de
operaciones de
computadoras
Desarrollo
Áreas
académicas,
administrativas.
Cumplimiento
de
SLA(Servicio
de nivel de
Acuerdo)
Recepción de
pedidos
Evaluación de
pedidos
Transferencias de
pedidos
Documentación
Técnicas de gestión
de colas
Solución con tickets
Problemas de
mantenimiento
de redes, copias
de seguridad,
plan de
contingencias.
Relaciones con
área de
Mantenimiento
Entrega de
documentación
Fuente: Integración de BPM y Fundamentos del S3m® Process Model [33]
61
Figura N° 21 - Integración BPM y S3m® Process Model [33]
USUARIOS
•Áreas académicas,
administrativas.
•Cumplimiento de SLA
(Acuerdo de nivel de Servicios)
BPM
Business Process
Management
MANTENIMIENTO POR
ADELANTADO Y
HELPDESK
•Recepción de pedidos
•Evaluación de pedidos
•Transferencias de pedidos
•Documentación
•Técnicas de gestión de colas
•Solución con tickets
SERVICIO DE
MANTENIMIENTO DE
OPERACIONES DE
COMPUTADORAS
•Problemas de
mantenimiento de redes,
copias de seguridad, plan de
contingencias
DESARROLLO
Relaciones con área de
Mantenimiento
Entrega de documentación
62
CAPÍTULO IV
CONSTRUCCIÓN
En este capítulo se presenta las fases del proceso de construcción de la solución
de Implementación del modelo basado en Fundamentos de S3m® Process Model alineado
a Business Process Modeling (BPM) para la eficiencia en el proceso de mantenimiento
de software aplicado al área de Desarrollo de Sistemas de DIGESI UPeU- Filial Juliaca.
Para lo cual seguiremos con desarrollo de las siguientes fases que a continuación
describiremos:
4.1 Primera Fase: Análisis y evaluación del proceso de mantenimiento actual del área
de Desarrollo de Software - DIGESI de tal forma que se puedan mejorar sus procesos
En el desarrollo de esta fase se realizó lo siguiente:
Se realizó el levantamiento de la información a través de entrevistas, reuniones al
personal de Desarrollo y Soporte de Sistemas.
Descripción y diseñó de los procesos actuales de mantenimiento de software.
Evaluación de los procesos de Mantenimiento de software actuales
4.1.1 Levantamiento de la información
Consiste en la recolección de documentación y datos existentes del Área de
Desarrollo y Mantenimiento de Software.
Con el objetivo de conocer la estructura funcional del área, se solicitó al Director
de DIGESI el MOF respectivo del área.
DIGESI Filial Juliaca (Dirección General de Sistemas) Es el área especializada
en asesoría y soporte de las tecnologías de la información, para la Universidad Peruana
Unión, cuyo objetivo principal es brindar un soporte informático en los diferentes
procesos que realiza esta casa de estudios. En nuestros centros de aplicación está
conformado según las actividades que cumple, las cuales son:
63
Área de Redes y conectividad.
Es el área encargada de instalar, configurar, mantener y administrar las redes
informáticas de distintos tamaños y complejidad. Además cuenta con los conocimientos
necesarios para diseñar, evaluar, supervisar y ejecutar proyectos de conectividad. Para
una segura y eficiente gestión de la empresa.
Coordinación de Servicios computacionales
Es la encargada de la administración de los laboratorios de cómputo, la cual
estructura los planes de servicio requeridas por las unidades usuarios, además de
controlar el rendimiento de software y hardware que reúnen los rasgos de calidad que le
permiten que le permiten dar un servicio continúo.
Soporte y comunicaciones
Ejecuta un plan integral de operatividad de equipos de hardware, software y
comunicaciones, garantizando los servicios que brinda la Universidad a los usuarios.
El Área de Desarrollo y Soporte de Sistemas
Es el responsable de dar soporte y mantenimiento de los sistemas de información
que existen, así como también automatizar los requerimientos de información de
aquellas unidades usuarias, que por el alcance de sus operaciones dentro la Universidad
Peruana Unión, necesitan ser satisfechas mediante el desarrollo de sistemas
informáticas. Además es el ente de apoyo a las diferentes áreas, velando por el buen
funcionamiento de los sistemas:
Enseguida presentamos una lista de los sistemas principales, a las cuales se
presta mantenimiento de software.
Sistema académico
Sistema contable
Sistema de matrícula UPeU
Sistema de matrícula CAT
Sistema de Biblioteca
Sistema de pedidos (SIM)
Sistema de residencias
64
Sistema integral para institutos (idiomas)
Administración de los usuarios y accesos
Esta área cuenta con 4 personas que laboran en horario completo, las cuales
tienen la siguiente responsabilidad:
01 Jefe de Desarrollo de Sistemas.
01 Analista programador, priorizando sistema académico.
01 Analista programador, priorizando sistema contable.
01 Analista programador, dedicado al sistema integral para institutos.
Cada Integrante del área de desarrollo cuenta con una computadora personal.
Sistema Operativo
Windows 8.
Mac Os.
Fedora
Lista de software que se utiliza en el área:
SQL developer
SPRING
Netbeans.
Sublime Text
BlueFish
Microsoft Office
Putty
Xming
Limitaciones que se encuentra en el área:
Los nuevos módulos implementados en la Sede Lima, no cuentan con un manual
de funcionamiento que sean compartidos con la filial.
No se cuenta con un servidor de pruebas (base de datos y aplicaciones).
No se cuenta con servidor de archivos (almacenamiento versionado de las
aplicaciones).
65
No se cuenta con un UPS.
No se cuenta con un modem para la continuidad de la conexión.
No se cuenta con software licenciado.
En esta área se desarrollara la investigación, teniendo en cuenta que es una de las
áreas más importantes, la cual necesita la realización de nuevas propuestas e
implementación en sus procesos.
4.1.2 Descripción y diseño de los procesos actuales de mantenimiento de software
área de Desarrollo y Soporte de Sistemas DIGESI – FJ
El mantenimiento de software es una de las actividades primordiales del Área de
Desarrollo y Soporte de Sistemas DIGESI-FJ, quien nunca paraliza sus actividades
porque de ella depende el soporte continuo de sus principales sistemas, las solicitudes de
parte del usuario, surgen durante todo el año.
Los procesos de mantenimiento y soporte, según su diagrama actual de procesos se
presentan de la siguiente manera:
Recepción de Pedidos
Él área de Mesa de Servicio, es el encargado de la recepción de los pedidos que
realizan los clientes (Áreas solicitante) frente a la búsqueda de una solución de un
problema suscitado en un sistema. La cual se solicita generalmente vía correo electrónico
al Área de Desarrollo y Soporte de Sistemas con copia al Director de DIGESI-FJ. o
solicitud dirigida al Director de DIGESI-FJ.
Evaluación del pedido
El Jefe de Desarrollo y Soporte de Sistemas, es el encargado de evaluar el
pedido, para la verificación de la viabilidad del pedido, en este proceso el evaluador se
pregunta lo siguiente ¿El pedido es viable?, Si la respuesta es no, se da por terminado el
proceso comunicando al área solicitante, que el pedido no es viable. Caso contrario se
procede a responder la siguiente pregunta ¿El pedido es de soporte? Si la respuesta es
positiva, se ejecuta el pedido, caso contrario, surge otra pregunta ¿Es de desarrollo?
Cabe resaltar que se evalúan en base a la clasificación de 2 tipos:
66
Si son urgentes y la solución está al alcance, se coloca dicho pedido en la lista de
urgentes, y se efectúa inmediatamente la solución. Si el pedido es clasificado como no
urgente se coloca en la lista de no urgentes, la cual no prioriza (Indica que puede
esperar).
Elaboración de listas de necesidades de la universidad
Es el proceso mediante el cual el Área de Desarrollo y Soporte planifica las
actividades a desarrollar respecto al Mantenimiento de Software, las cuales son
seleccionados según las prioridades y las necesidades de la Universidad. Una vez
efectuada este procedimiento se hace la siguiente pregunta ¿Es de soporte? Si la
respuesta fuere si, el pedido es ejecutado, caso contrario nos volvemos a preguntar ¿Es
de desarrollo? Si fuere esta respuesta positiva, se captura los requerimientos, caso
contrario lo gestiona al área.
Ejecución del pedido
Es el proceso mediante el cual se lleva a cabo la actividad misma de la
realización del pedido según lo pactado con el área solicitante, esto es una vez que el
pedido fue clasificado como pedido de tipo soporte de Sistemas.
Entrega del pedido y pruebas
Una vez culminado el trabajo, se comunica al área solicitante, para que realice
las pruebas correspondientes, si la respuesta fuere positiva. Dando por finalizado el
proceso. Es por ello que se pide al cliente que nos devuelva su respuesta generalmente
vía correo electrónico, indicando conformidad de resolución del pedido.
67
Figura N° 22 - Proceso de mantenimiento de software [33]
4.1.3 Evaluación de los procesos
Para realizar la evaluación respectiva, la cual cumple lo siguiente:
Se observó la ausencia o falta de documentación de software. Como ya es de
conocimiento, el Área Desarrollo y Soporte de Sistemas de DIGESI FJ, cuenta
con 5 principales sistemas a las cuales presta el servicio de mantenimiento de
software. La falta de estos documentos salta el grado de formalidad, pues generan
un problema, porque no hay forma de evidenciar la recepción de los sistemas que
serán administrados por el área, donde quede establecido que no se encontró
defecto alguno respectivo.
La no existencia de manuales de ninguno de los sistemas a las cuales se presta
mantenimiento de software, de manera formal, además de que las personas que
realizan este trabajo, no tienen donde consultar encuentren plasmados los
procesos actuales de mantenimiento de software.
No existe procedimientos donde especifique cada proceso de mantenimiento de
software.
No hay evidencia sobre el uso de modelos de procesos para el mantenimiento de
software respectivo.
68
Existe un diagrama elaborado desactualizado, donde se puede apreciar los
procesos de Desarrollo y Soporte de Sistemas.
Existencia de cuellos de botella en el proceso de resolución de pedidos.
4.2 Segunda fase: Propuesta de un nuevo modelo alineado al modelo BPM y S3m®
Process Model
Se elabora la documentación pertinente, teniendo en cuenta las normativas de
S3m® Process Model
Después de haber realizado la entrevista respectiva, se diseñó los nuevos
procesos de mantenimiento de software siguiendo los lineamientos S3m® Process
Model. Usando como herramienta la aplicación Bizagi.
Figura 23 - Diagrama Bizagi- Integración de los Fundamentos S3m® Process Model y
BPM [33]
4.3 Tercera fase: Comparación de los procesos de mantenimiento actuales de acuerdo
a la normativa de S3m® Process Model
Una vez diseñado el nuevo mapa de procesos de Mantenimiento de Software. Se
convoca a una reunión para buscar la aprobación de la nueva documentación que va a
ingresar. Aquí se validan los documentos.
69
Tabla N° 5: Comparación de los proceso de mantenimiento de software según S3m®
Process Model
Proceso de Mantenimiento actual Proceso de Mantenimiento según S3M®
Process Model
Ninguna interfaz de negociaciones de
clientes y usuarios
Cuenta con interface de negociaciones de
clientes y usuarios
Los clientes lo representan las áreas
respectivas
Consiente clientes interfaces
No se consiente las SLA Se consiente las SLA
Los procesos se desarrollan a una
realidad más pequeña
Los procesos se desarrollan a una
realidad más grande
Existe el área de Helpdesk Existe el área de Helpdesk y
mantenimiento por adelantado
Existe un servicio de mantenimiento de
Operaciones por Computadores llamado
Soporte TI
Existe un servicio de mantenimiento de
Operaciones por Computadores
En el área de Desarrollo de software, no
existe la pre-entrega y transición del
software
El área de Desarrollo de software, existe
la pre-entrega y transición del software
No existencia de Servicio de Proveedores Existencia de Servicio de Proveedores
Fuente: Comparación de los procesos de mantenimiento de software según Process
Model S3m® [33]
70
4.4 Cuarta fase: Elaboración de un plan piloto de acuerdo a BPM y S3m® Process
Model
4.4.1 Implementar una normativa en relación a las negociaciones entre los usuarios y
los mantenedores de software con las SLA (Interfaz 2 -S3m® Process Model)
Para el desarrollo de la primera parte del plan Piloto BPM y S3m® Preces
Model, seguiremos las normativas COBIT 4.1, bajo el dominio número 01 de Entregar y
dar soporte (DS).
Entregar y dar soporte (DS)
Este dominio cubre la entrega en sí de los servicios requeridos, lo que incluye la
prestación del servicio, la administración de la seguridad y de la continuidad, el soporte
del servicio a los usuarios, la administración de los datos y de las instalaciones
operativos.
Por lo general cubre las siguientes preguntas de la gerencia:
¿Se están entregando los servicios de TI de acuerdo con las prioridades del
negocio?
¿Están optimizados los costos de TI?
¿Es capaz la fuerza de trabajo de utilizar los sistemas de TI de manera productiva
y segura?
¿Están implantadas de forma adecuada la confidencialidad, la integridad y la
disponibilidad?
Entregar y dar soporte:
DS1 Definir y administrar los niveles de servicio
Definir y administrar los niveles de servicio DS1
Descripción del proceso
DS1 Definir y administrar los niveles de servicio
Contar con una definición documentada y un acuerdo de servicios de TI y de
niveles de servicio, hace posible una comunicación efectiva entre la gerencia de TI y los
71
clientes de negocio respecto de los servicios requeridos. Este proceso también incluye el
monitoreo y la notificación oportuna a los interesados (Stakeholders) sobre el
cumplimiento de los niveles de servicio. Este proceso permite la alineación entre los
servicios de TI y los requerimientos de negocio relacionados.
Control sobre el proceso TI:
Definir y manejar niveles de servicio
Que satisface el requerimiento del negocio de TI para:
Asegurar la alineación de los servicios claves de TI con la estrategia del negocio
Enfocándose en:
La identificación de requerimientos de servicio, el acuerdo de niveles de servicio
y el monitoreo del cumplimiento de los niveles de servicio
Se logra con:
La formalización de acuerdos internos y externos en línea, con los requerimientos
y las capacidades de entrega.
La notificación del cumplimiento de los niveles de servicio (reportes y reuniones)
La identificación y comunicación de requerimientos de servicios actualizados y
nuevos para la planeación estratégica
Y se mide con:
El porcentaje de interesados satisfechos de que la entrega del servicio cumple con
los niveles previamente acordados.
El número de servicios entregados que no estén en catálogo
El número de reuniones formales de revisión del Acuerdo de Niveles de Servicio
(SLA) con las personas de negocio por año
Objetivos de control
DS1. Definir y Administrar los Niveles de Servicio
DS1.1 Marco de Trabajo de la Administración
72
Definir un marco de trabajo que brinde un proceso formal de administración de
niveles de servicio entre el Cliente y el Prestador de servicio. El marco de trabajo
mantiene una alineación continua con los requerimientos y las prioridades de negocio y
facilita el entendimiento común entre el cliente y el prestador de servicio. El marco de
trabajo incluye procesos para la creación de requerimientos de servicio, definiciones de
servicio, acuerdos de niveles de servicio (SLAs), acuerdos de niveles de operación
(OLAs) y las fuentes de financiamiento. Estos atributos están organizados en un catálogo
de servicios. El marco de trabajo define la estructura organizacional para la
administración del nivel de servicio, incluyendo los roles, tareas y responsabilidades de
los proveedores externos e internos y de los clientes.
DS1.2 Definición de Servicios
Definiciones base de los servicios de TI sobre las características del servicio y
los requerimientos de negocio, organizados y almacenados de manera centralizada por
medio de la implantación de un enfoque de catálogo/portafolio de servicios.
DS1.3 Acuerdos de Niveles de Servicio
Definir y acordar convenios de niveles de servicio para todos los procesos
críticos de TI con base en los requerimientos del cliente y las capacidades en TI. Esto
incluye los compromisos del cliente, los requerimientos de soporte para el servicio,
métricas cualitativas y cuantitativas para la medición del servicio firmado por los
interesados, en caso de aplicar, los arreglos comerciales y de financiamiento, los roles y
responsabilidades, incluyendo la revisión del SLA. Los puntos a considerar son
disponibilidad, confiabilidad, desempeño, capacidad de crecimiento, niveles de soporte,
planeación de continuidad, seguridad y restricciones de demanda.
DS1.4 Acuerdos de Niveles de Operación
Asegurar que los acuerdos de niveles de operación expliquen cómo serán
entregados técnicamente los servicios para soportar los SLA(s) de manera óptima. Los
73
OLAs especifican los procesos técnicos en términos entendibles para el proveedor y
pueden soportar diversos SLAs.
DS1.5 Monitoreo y Reporte del Cumplimiento de los niveles de Servicio
Monitorear continuamente los criterios de desempeño especificados para el nivel
de servicio. Los reportes sobre el cumplimiento de los niveles de servicio deben emitirse
en un formato que sea entendible para los interesados. Las estadísticas de monitoreo son
analizadas para identificar tendencias positivas y negativas tanto de los servicios
individuales como de los servicios en conjunto.
DS1.6 Revisión de los Acuerdos de Niveles de Servicio y de los Contratos
Revisar regularmente con los proveedores internos y externos los acuerdos de
niveles de servicio y los contratos de apoyo, para asegurar que son efectivos, que están
actualizados y que se han tomado en cuenta los cambios en requerimientos.
Modelo de madurez
DS1. Definir y Administrar los Niveles de Servicio
La administración del proceso de Definir y administrar niveles de servicio que
satisfacen el requerimiento de negocio para TI de asegurar la alineación de servicios
claves de TI con la estrategia de negocio es:
0 No Existente cuando
La gerencia no reconoce la necesidad de un proceso para definir los niveles de
servicio. La responsabilidad y la rendición de cuentas sobre el monitoreo no está
asignada.
1 Inicial / Ad Hoc cuando
Hay conciencia de la necesidad de administrar los niveles de servicio, pero el
proceso es informal y reactivo. La responsabilidad y la rendición de cuentas sobre la
74
definición y la administración de servicios no están definidas. Si existen las medidas para
medir el desempeño son solamente cualitativas con metas definidas de forma imprecisa.
La notificación es informal, infrecuente e inconsistente.
2 Repetible pero Intuitivo cuando
Los niveles de servicio están acordados pero son informales y no están revisados.
Los reportes de los niveles de servicio están incompletos y pueden ser irrelevantes o
engañosos para los clientes. Los reportes de los niveles de servicio dependen, en forma
individual, de las habilidades y la iniciativa de los administradores. Está designado un
coordinador de niveles de servicio con responsabilidades definidas, pero con autoridad
limitada. Si existe un proceso para el cumplimiento de los acuerdos de niveles de servicio
es voluntario y no está implementado.
3 Definido cuando
Las responsabilidades están bien definidas pero con autoridad discrecional. El
proceso de desarrollo del acuerdo de niveles de servicio está en orden y cuenta con puntos
de control para revalorar los niveles de servicio y la satisfacción de cliente. Los servicios
y los niveles se servicio están definidos, documentados y se ha acordado utilizar un
proceso estándar. Las deficiencias en los niveles de servicio están identificadas pero los
procedimientos para resolver las deficiencias son informales. Hay un claro vínculo entre
el cumplimiento del nivel de servicio esperado y el presupuesto contemplado. Los niveles
de servicio están acordados pero pueden no responder a las necesidades del negocio.
4 Administrado y Medible cuando
Aumenta la definición de los niveles de servicio en la fase de definición de
requerimientos del sistema y se incorporan en el diseño de la aplicación y de los ambientes
de operación. La satisfacción del cliente es medida y valorada de forma rutinaria. Las
medidas de desempeño reflejan las necesidades del cliente, en lugar de las metas de TI.
Las medidas para la valoración de los niveles de servicio se vuelven estandarizadas y
reflejan los estándares de la industria. Los criterios para la definición de los niveles de
servicio están basados en la criticidad del negocio e incluyen consideraciones de
75
disponibilidad, confiabilidad, desempeño, capacidad de crecimiento, soporte al usuario,
planeación de continuidad y seguridad. Cuando no se cumplen los niveles de servicio, se
llevan a cabo análisis causa-raíz de manera rutinaria. El proceso de reporte para
monitorear los niveles de servicio se vuelve cada vez automatizado. Los riesgos
operativos y financieros asociados con la falta de cumplimiento de los niveles de servicio,
están definidos se entienden claramente. Se implementa y mantiene un sistema formal de
medición de los KPIs y los KGIs.
5 Optimizado cuando
Los niveles de servicio son continuamente reevaluados para asegurar la alineación
de TI y los objetivos del negocio, mientras se toma ventaja de la tecnología incluyendo la
relación costo-beneficio. Todos los procesos de administración de niveles de servicio
están sujetos a mejora continua. Los niveles de satisfacción del cliente son administrados
y monitoreados de manera continua. Los niveles de servicio esperados reflejan metas
estratégicas de las unidades de negocio y son evaluadas contra las normas de la industria.
La administración de TI tiene los recursos y la asignación de responsabilidades necesarias
para cumplir con los objetivos de niveles de servicio y la compensación, está estructura
para brindar incentivos por cumplir con dichos objetivos. La alta gerencia monitorea los
KPIs y los KGIs como parte de un proceso de mejora continua.
4.4.2 Implementación del servicio de mantenimiento por adelantado y Helpdesk
Creación de nuevo puesto de trabajo: Con la adecuación de un puesto de trabajo del
personal actual
Recepción de pedido: Encargado en primera instancia de la recepción de los pedidos
Evaluación de los pedidos: Es en ente encargado de evaluar los pedidos si están en
condiciones de resolverlas y si sin prioritarios.
Uso de sistemas de gestión por tikets: Con la instalación de FreshDesk, como
herramienta de aplicación.
76
Figura N° 24- FreshDesk [33]
Transferencia de pedidos: Cuando la solicitud no está relacionado mantenimiento de
software.
Documentación: El encargado de este puesto documentara el proceso de la resolución
de pedido ejecutados en el día.
Trabajo en base al cumplimiento de los SLA: El encargado realizara sus actividades en
base al cumplimiento del SLA
4.4.3 Elaboración del acuerdo SLA (Service Level Agreement) para el área de
Desarrollo Soporte de Sistemas –DIGESI (Ver anexo N° 6)
Tanto las partes del Cliente como del Personal de Desarrollo y Soporte de
Sistemas, se comprometen a cumplir con el contrato del SLA. Con la autorización de las
Administración de la institución.
4.4.4 Implementación del proceso del Servicio de desarrollo de software (Interfaz 4-
S3m® Process Model)
77
Los Desarrolladores necesitan estar en constante relación con el personal de
Mantenimiento de Software por lo cual proponemos:
Firma de cargo en la recepción de nuevo software para uso de la institución, con
adjunto de manuales respectivos
Si para el encargado de mantenimiento por adelantado y HelpDesk le resulta
difícil resolver una solicitud de mantenimiento de software, se transfiere el pedido
al Área de Desarrollo de software.
78
CAPÍTULO V
VALIDACIÓN Y RESULTADOS
Las pruebas que realizaremos a continuación están sujetas a pruebas de t de
Student, también llamados diferencias de medias. Comúnmente llamado el antes y
después.
5.1 Hipótesis específicas
5.1.1 He1: La implementación del modelo basado en Fundamentos de S3m® Process
Model alineado a Business Process Modeling influye positivamente en la mejora del
tiempo de resolución de pedidos de los clientes de Desarrollo y Soporte DIGESI
Universidad Peruana Unión Filial Juliaca.
Construcción de las hipótesis:
Ho: No existe diferencia significativa en la implementación del modelo basado
en Fundamentos de S3m® Process Model alineado a Business Process Modeling antes y
después de que influye positivamente en la mejora del tiempo de resolución de pedidos
de los clientes del Área de Desarrollo y Soporte de DIGESI Universidad Peruana Unión
Filial Juliaca.
He1: Hay diferencia significativa en la implementación del modelo basado en
Fundamentos de S3m® Process Model alineado a Business Process Modeling antes y
después de que influye positivamente en la mejora del tiempo de resolución de pedidos
de los clientes de Desarrollo y Soporte de DIGESI Universidad Peruana Unión Filial
Juliaca.
Ho: Ua-Ud ≤ 0; Ud ≤ 0
He1: Ua-Ud > 0; Ud > 0
79
Datos:
Se hizo una evaluación con una muestra de 30 individuos:
La prueba se realiza respecto al tiempo de resolución de pedidos en 02 momentos:
El primero se realiza antes de aplicar la implementación del modelo basado en
Fundamentos de S3m® Process Model alineado a Business Process Modeling y el
segundo después de aplicar el modelo antes mencionado.
Tabla N° 6: Datos estadísticos según Hipótesis He1
Personal Tiempo_A Tiempo_D
1 08:00 04:00
2 04:00 02:00
3 04:00 02:00
4 04:00 02:00
5 08:00 04:00
6 08:00 04:00
7 08:00 04:00
8 04:00 02:00
9 04:00 02:00
10 16:00 08:00
11 12:00 06:00
12 08:00 04:00
13 08:00 04:00
14 04:00 02:00
15 04:00 02:00
16 04:00 02:00
17 08:00 04:00
18 08:00 04:00
19 08:00 04:00
20 12:00 06:00
21 04:00 02:00
22 08:00 04:00
23 08:00 04:00
24 08:00 04:00
25 08:00 04:00
26 04:00 02:00
27 04:00 02:00
28 04:00 02:00
29 08:00 04:00
30 08:00 04:00
Fuente: Elaboración propia [33]
El supuesto de normalidad:
80
Pruebas de Npar:
Tabla N° 7: Prueba de Kolmogorov-Smirnov para He1
TIEMPO_
A
TIEMPO_
D
N 30 30
Parámetros normalesa,b Media 6:56 3:28
Desviación
estándar
2:57 1:28
Máximas diferencias
extremas
Absoluta ,259 ,259
Positivo ,259 ,259
Negativo -,241 -,241
Estadístico de prueba ,259 ,259
Sig. asintótica (bilateral) ,000c ,000c
Fuente: Elaboración propia [33]
Según la tabla N° 7 observamos que para ambos casos el p valor es > = 0.05 para
el antes y el después
Es decir los datos provienen de una población normalmente distribuida.
Una vez aplicado la prueba de normalidad recién aplicamos la prueba t:
Prueba t:
Tabla N° 8: Estadísticas de muestras emparejadas para He1
Media N
Desviación
estándar
Media de
error estándar
Par 1 TIEMPO_
D
3:28 30 1:28 0:16
TIEMPO_
A
6:56 30 2:57 0:32
Fuente: Elaboración propia. [33]
81
Tabla N° 9: Correlaciones de muestras emparejadas para He1
N Correlación Sig.
Par 1 TIEMPO_D &
TIEMPO_A
30 1,000 ,000
Fuente: Elaboración propia. [33]
Tabla N° 10: Prueba de muestras emparejadas para He1
Diferencias emparejadas
t gl
Sig.
(bilatera
l)
Medi
a
Desviac
ión
estándar
Media
de error
estándar
95% de intervalo
de confianza de la
diferencia
Inferior Superior
Par
1
TIEMPO_D -
TIEMPO_A
-3:28 1:28 0:16 -4:01 -2:54 -
12,83
5
29 ,000
Fuente: Elaboración propia. [33]
Según la tabla N° 10 observamos que el p valor es 0, lo cual nos quiere decir que
hay diferencia significativa entre el antes y el después. Luego podemos decir que el
después tiene mayor rendimiento que el antes.
La hipótesis del después tiene mayor rendimiento que el antes.
Tabla N° 11: P-valor en SPSS
H1 Signo de t P-VALOR EN SPSS
Significancia asintótica bilateral
> + Significancia asintótica bilateral ½
> - 1-Significancia asintótica bilateral ½
< + 1-Significancia asintótica bilateral ½
< - Significancia asintótica bilateral ½
Fuente: Elaboración propia [33]
Interpretación para Hipótesis He1:
82
La significancia es < = 0,05 entonces se rechaza la H0
La significancia es > 0,05 entonces no se rechaza la H0
Es decir que: Rechazamos la Hipótesis nula y aceptamos la Hipótesis alternativa He1
La interpretación en He1 es:
Con un nivel de significancia del 5%, decimos que si hay diferencia significativa
en la implementación del modelo basado en Fundamentos de S3m® Process Model
alineado a Business Process Modeling después de que influye positivamente en la
mejora del tiempo de resolución de pedidos de los clientes del Área de Desarrollo y
Soporte de Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca.
En conclusión en He1 es:
Por cuanto la implementación del modelo basado en Fundamentos de S3m®
Process Model alineado a Business Process Modeling influye positivamente después de
la mejora del tiempo de resolución de pedidos de clientes del área de Desarrollo y
Soporte de DIGESI Universidad Peruana Unión Filial Juliaca, concluimos que sería
muy adecuado se implemente la solución planteada en esta investigación.
5.1.2 He2: La implementación del modelo basado en Fundamentos de S3m® Process
Model alineado a Business Process Modeling influye positivamente en la mejora del
número de atención de usuarios del Área de Desarrollo y Soporte de Sistemas de
DIGESI Universidad Peruana Unión Filial Juliaca.
Construcción de las Hipótesis:
Ho: No existe diferencia significativa positiva en la implementación del modelo
basado en Fundamentos de S3m® Process Model alineado a Business Process Modeling
antes y después de la mejora del número de atención de usuarios del Área de Desarrollo
y Soporte de Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca.
83
He2: Existe diferencia significativa positiva en la implementación del modelo
basado en Fundamentos de S3m® Process Model alineado a Business Process Modeling
antes y después de la mejora del número de atención de usuarios del Área de Desarrollo
y Soporte de Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca.
Ho: Ua-Ud ≤ 0; Ud ≤ 0
He2: Ua-Ud > 0; Ud > 0
Datos:
Se hizo una evaluación con una muestra de 30 individuos:
En primer lugar se cotejó un test de prueba a un grupo de 30 usuarios de la
Universidad Peruana Unión, antes de la implementación del modelo basado en
Fundamentos de S3m® Process Model alineado a Business Process Modeling y cada uno
de ellos referían la suma de veces al día, que fueron atendidos por el área de Desarrollo y
Soporte de Sistemas, y luego de la implementación del modelo basado en Fundamentos
de S3m® Process Model alineado a Business Process Modeling se les tomó otro test.
84
Tabla N° 12: Datos estadísticos según Hipótesis He2
Fuente: Elaboración propia. [33]
N° de
Orden Días Antención_A Antención_D
1 1 10 21
2 2 12 20
3 3 13 24
4 4 15 36
5 5 10 20
6 6 11 22
7 7 10 23
8 8 12 25
9 9 13 27
10 10 12 25
11 11 11 22
12 12 11 22
13 13 10 21
14 14 18 36
15 15 23 45
16 16 19 46
17 17 23 48
18 18 25 56
19 19 25 57
20 20 26 58
21 21 29 54
22 22 30 63
23 23 25 52
24 24 22 43
25 25 26 54
26 26 27 54
27 27 26 56
27 28 27 70
29 29 24 68
30 30 26 69
85
Tabla N° 13 : Prueba de Kolmogórov-Smirnov para He2
Atencion_
A
Atencion_
D
N 30 30
Parámetros normalesa,b Media 19,03 41,23
Desviación
estándar
7,122 17,310
Máximas diferencias
extremas
Absoluta ,202 ,195
Positivo ,202 ,195
Negativo -,178 -,136
Estadístico de prueba ,202 ,195
Sig. asintótica (bilateral) ,003c ,005c
Fuente: Elaboración propia. [33]
Según la tabla N° 13, observamos que para ambos casos el p valor es > = 0.05
para el antes y el después.
Por lo cual decimos que los datos provienen de una población normalmente
distribuida.
Una vez aplicado la prueba de normalidad aplicamos la prueba t:
Prueba t:
Tabla N° 14: Estadísticas de muestras emparejadas para He2
Media N
Desviación
estándar
Media de
error estándar
Par 1 Atencion_A 19,03 30 7,122 1,300
Atencion_D 41,23 30 17,310 3,160
Fuente: Elaboración propia [33]
Tabla N° 15: correlaciones de muestras emparejadas para He2
86
N Correlación Sig.
Par 1 Atencion_A &
Atencion_D
30 ,952 ,000
Fuente: Elaboración propia [33]
Según la tabla N° 15 las muestras emparejadas que observamos es de p valor es
0 (Sig. Bilateral =0), lo cual estadísticamente nos indica que si hay diferencia
significativa entre el antes y el después. Luego podemos decir que el después tiene
mayor rendimiento que el antes.
La hipótesis del después tiene mayor rendimiento que el antes.
Tabla N° 16: P-Valor en SPSS
H1 SIGNO DE T P-VALOR EN SPSS
Significancia asintótica bilateral
> + Significancia asintótica bilateral 1/2
> - 1-Significancia asintótica bilateral 1/2
< + 1-Significancia asintótica bilateral 1/2
< - Significancia asintótica bilateral 1/2
Fuente: Guías de Bioestadística [34]
Diferencias emparejadas
t gl
Sig.
(bilateral
)
Medi
a
Desviaci
ón
estándar
Media de
error
estándar
95% de intervalo de
confianza de la
diferencia
Inferior Superior
Par
1
Atencion_A -
Atencion_D
-
22,20
0
10,749 1,963 -26,214 -18,186 -
11,31
2
29 ,000
87
La hipótesis del después tiene mayor rendimiento que el antes.
Interpretación de Hipótesis según He2:
La significancia < = 0,05 entonces rechazo la H0
La significancia > 0,05 entonces no rechazo la H0
Por lo tanto: Rechazamos la hipótesis nula y aceptamos la hipótesis alternativa.
La interpretación es:
Con un nivel de significancia al 5%, hay diferencia significativa positiva en la
implementación del modelo basado en Fundamentos de S3m® Process Model alineado
a Business Process Modeling después de que influye positivamente en la mejora del
número de atención de usuarios del Área de Desarrollo y Soporte de DIGESI
Universidad Peruana Filial Juliaca.
En conclusión:
Por cuanto la implementación del modelo basado en Fundamentos de S3m® Process
Model alineado a Business Process Modeling influye positivamente después de la
mejora del número de atención de usuarios del Área de Desarrollo y Soporte de DIGESI
Universidad Peruana Unión Filial Juliaca, sería muy adecuado se implemente la
solución planteada en esta investigación.
5.1.3 Hipótesis general
La implementación del modelo basado en Fundamentos de S3m® Process Model
alineado a Business Process Modeling (BPM) influye positivamente en el proceso de
mantenimiento de software aplicado al área de Desarrollo y Soporte de Sistemas de
DIGESI Universidad Peruana Unión Filial Juliaca.
Tabla N° 17: Datos estadísticos según Hipótesis general
N°
Indiv. Calif_SLA_A Calif_SLA_D
1 1 3
2 2 4
3 2 3
4 1 5
88
5 3 4
6 1 3
7 3 4
8 2 5
9 1 4
10 2 4
11 1 5
12 2 4
13 1 5
14 3 3
15 1 4
16 3 4
17 2 4
18 1 4
19 2 5
20 1 5
21 2 5
22 1 3
23 1 3
24 1 3
25 1 4
26 1 4
27 2 4
28 1 3
29 1 4
30 2 5
Fuente: Elaboración propia [33]
Tabla N° 18: Prueba de Kolmogórov-Smirnov para hipótesis general
Calif_Inf_SL
A1
Calif_Inf_SL
A2
N 30 30
Parámetros normalesa,b Media 1,60 4,00
Desviación
estándar
,724 ,743
Máximas diferencias
extremas
Absoluta ,330 ,233
Positivo ,330 ,233
Negativo -,204 -,233
Estadístico de prueba ,330 ,233
Sig. asintótica (bilateral) ,000c ,000c
Fuente: Elaboración propia [33]
Según el cuadro N°18 observamos que para ambos casos el p valor es > = 0.05
para el antes y el después.
89
Entonces se afirma que los datos provienen de una población normalmente
distribuida.
Una vez aplicado esta prueba de normalidad aplicamos la prueba t:
Prueba t:
Tabla N° 19: Estadísticas de muestras emparejadas para hipótesis general
Media N
Desviación
estándar
Media de
error estándar
Par 1 Calif_Inf_SL
A2
4,00 30 ,743 ,136
Calif_Inf_SL
A1
1,60 30 ,724 ,132
Fuente: Elaboración propia [33]
Tabla N° 20: Correlaciones de muestras emparejadas
N Correlación Sig.
Par 1 Calif_Inf_SLA2 &
Calif_Inf_SLA1
30 ,064 ,736
Fuente: Elaboración propia [33]
Tabla N° 21: Prueba de muestras emparejadas para hipótesis general
Diferencias emparejadas
t gl
Sig.
(bilatera
l)
Medi
a
Desviac
ión
estándar
Media
de error
estándar
95% de intervalo
de confianza de la
diferencia
Inferior
Superio
r
Par
1
Calif_Inf_SL
A2 -
Calif_Inf_SL
A1
2,40
0
1,003 ,183 2,025 2,775 13,1
00
29 ,000
Fuente: Elaboración propia [33]
Según la tabla N° 21 las muestras emparejadas que observamos es de p valor es
0 (Sig. Bilateral =0), lo cual estadísticamente nos indica que si hay diferencia
90
significativa entre el antes y el después. Luego podemos decir que el después tiene
mayor rendimiento que el antes.
La hipótesis seria del después tiene mayor rendimiento que el antes.
Tabla N° 22 : P-Valor en SPSS
H1 SIGNO DE T P-VALOR EN SPSS
Significancia asintótica bilateral
> + Significancia asintótica bilateral 1/2
> - 1-Significancia asintótica bilateral 1/2
< + 1-Significancia asintótica bilateral 1/2
< - Significancia asintótica bilateral 1/2
Fuente: Elaboración propia [33]
La interpretación en hipótesis general es:
Si mi significancia < = 0,05 entonces rechazo la H0
Si mi significancia > 0,05 entonces no rechazo la H0
Por lo tanto hipótesis seria que el después tiene mayor calificación que el antes.
Interpretación según Hipótesis general:
La significancia < = 0,05 entonces rechazo la H0
La significancia > 0,05 entonces no rechazo la H0
De acuerdo a esta interpretación: Rechazamos la hipótesis nula y aceptamos la
hipótesis alternativa.
Es decir:
Con un nivel de significancia al 5%, si existe diferencia significativa positiva en la
implementación del modelo basado en Fundamentos de S3m® Process Model alineado
a Business Process Modeling después de que influye positivamente en la calificación
91
del SLA que se usa en los proceso de mantenimiento de software aplicado al área de
Desarrollo y Soporte de Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca.
En conclusión:
Se ha comprobado que con la implementación del modelo basado en Fundamentos de
S3m® Process Model alineado a Business Process Modeling teniendo en cuenta el SLA
si influye positivamente en el proceso de mantenimiento de software aplicado al área de
Desarrollo y Soporte de Sistemas de DIGESI Universidad Peruana Unión Filial Juliaca,
por lo tanto es muy beneficioso la implementación de este proyecto de investigación.
92
CONCLUCIONES Y RECOMENDACIONES
La implementación del modelo basado en Fundamentos de S3m® Process Model
alineado a Business Process Modeling influye positivamente después de la mejora
del tiempo de resolución de pedidos de clientes del área de Desarrollo y Soporte
de DIGESI Universidad Peruana Unión Filial Juliaca. Por lo tanto recomendamos
se implemente la solución planteada de manera inmediata
La implementación del modelo basado en Fundamentos de S3m® Process Model
alineado a Business Process Modeling influye positivamente después de la mejora
del número de atención de usuarios del Área de Desarrollo y Soporte de DIGESI
Universidad Peruana Unión Filial Juliaca, por ello recomendamos que la apoye
con un presupuesto extra para hacer realidad este proyecto de investigación.
La implementación del modelo basado en Fundamentos de S3m® Process Model
alineado a Business Process Modeling teniendo en cuenta el SLA influye
positivamente en el proceso de mantenimiento de software aplicado al área de
Desarrollo y Soporte de Sistemas de DIGESI Universidad Peruana Unión Filial
Juliaca, por lo tanto recomendamos la aplicación el SLA según Cobit 4.1 tal como
sugiere este trabajo de investigación
Recomendamos al área Desarrollo de Sistemas de DIGESI Universidad Peruana
Unión Filial Juliaca que se debe cumplir con las especificaciones del SLA la cual
ayudaría en la optimización en el proceso de mantenimiento de software.
Se recomienda al área de Soporte y Desarrollo de Sistemas DIGESI Universidad
Peruana Unión Filial Juliaca, realizar encuestas de satisfacción de usuarios de
manera continua con el objetivo de mejoras los procesos de los servicios que
ofrece.
Recomendamos al área de DIGESI agilizar la formalización de este trabajo de
investigación para aplicarlo en el área de Soporte y Desarrollo de DIGESI de
manera que se pueda fortalecer los procesos claves.
93
Se recomienda a la institución que tome en cuenta capacitaciones al personal que
labora en el área Soporte y Desarrollo de DIGESI Universidad Peruana Unión
Filial Juliaca en temas de procesos, teniendo en cuenta S3m® Process Model,
BPM o Bizagi.
Se recomienda al área de Soporte y Mantenimiento de software, realizar talleres
o simulacros continuos donde se tomen en cuenta los casos típicos y atípicos de
los problemas de solicitudes de mantenimiento de software a fin de mantener muy
bien entrenado al personal
La integración del modelo S3m® Process Model y BPM influye en el procesos de
mantenimiento de software del área de Desarrollo y Soporte de Sistemas de
DIGESI Universidad Peruana Unión, Filial Juliaca
94
REFERENCIAS BIBLIOGRÁFICAS
[1] A. A. Alain Abran, Software Maintenance Management: Evaluation and Continuous
Improvement, Wiley-IEEE Computer Society Press, 2008.
[2] F. Scalone, junio 2006. [En línea]. Available:
http://laboratorios.fi.uba.ar/lsi/scalone-tesis-maestria-ingenieria-en-calidad.PDF.
[Último acceso: 16 noviembre 2013].
[3] M. I. Marante Estrellés, diciembre 2009. [En línea]. Available:
https://riunet.upv.es/bitstream/handle/10251/11896/Tesis%20Maria%20Isabel%20Marante.
pdf?sequence=1.
[4] P. Bazan, diciembre 2009. [En línea].
[5] J. Ann-Sofie , diciembre 2007. [En línea]. Available:
http://www.utn.uu.se/sts/cms/filarea/0801_ann-sofie_jansson.pdf.
[Último acceso: 17 Noviembre 2014].
[6] Pigosky, 1997. [En línea]. Available: https://prezi.com/-gyn3gp_2r0j/mantenimiento/.
[7] Lehman, 1997. [En línea]. Available: http://webquest.carm.es/majwq/wq/ver/70350.
[8] ISO/IEC/IEEE, «Software engineering – software life cycle processes – maintenance.,»
Technical Report International Standard ISO/IEC 14764:2006, 2006.
[9] M. Piattini, J. Villalba, F. Ruiz y T. Bastanchury. [En línea]. Available:
http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/materiales/tema8-
mantenimientoSistemasSoftware.pdf.
[10] Glass, 1992.
[11] Boehm, 1987.
[12] Abraham, 1991.
[13] Pressman, 2004.
[14] Bennett, 2000.
[15] Azuma, 1994.
95
[16] Lehman, 1980.
[17] ITIL, 2007.
[18] Colter, 1987.
[19] P. Grubb y T. Armstrong a, Software Maintenance: Concepts and Practice, 2003.
[20] Kajko-Mattsson, ISO/IEC 14764 and SWEBOK, 2002.
[21] J. Perez , Gestion de Procesos, 2007.
[22] Bazan, 2009.
[23] M. Weske , «Business Process Management: Concepts, Languages,Architectures,» 2008.
[En línea]. Available:
http://wicc2000.info.unlp.edu.ar/Carreras/Magisters/Redes_de_Datos/Tesis/Bazan_Patricia.pdf.
[24] M. B. Juric , 2007. [En línea].
[25] BPM Group, «BPM Group Snoop Consulting. BPM Group,» Junio 2008. [En línea].
[26] S. A.White, «Introduction to BPMN. IBM Corporation.,» 2009.
[En línea]. Available: http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf .
[27] «Unified Modeling Language (UML), version 2.2 OMG,» 2009. [En línea].
Available: http://www.omg.org/technology/documents/formal/uml.htm. 2009. (al.
[28] Martin Owen and Jog Raj, BPMN and Business Process Management Introduction
to the New Business Process Modeling Standard, Popkin Software, 2003.
[29] Gutiérrez y Marchessi , Diseño de un modelo de desarrollo de proyectos estrategicos
utilizando metodologia BPM, 2009.
[30] E. Tocto, «Implantación de soluciones de mejora de procesos basadas en BPM e ITIL V3
en un contexto Universitario: Caso Universidad Peruana Unión,» 2011.
[31] IT Governance Institute, «Cobir 4.1,» 2007. [En línea].
Available: http://cs.uns.edu.ar/~ece/auditoria/cobiT4.1spanish.pdf.
[32] F. y. B. Hernandez, 2006. [En línea].
Available: http://catarina.udlap.mx/u_dl_a/tales/documentos/lcp/texson_a_gg/capitulo4.pdf.
[33] N. O. Santillan Aching, «Implementación de un modelo basado en Fundamentos de
S3m® Process Model alineado a Business Process Modeling y su influencia en el proceso
96
de mantenimiento de software aplicado al área de Desarrollo de Sistemas de DIGESI
Universidad Peruana Unión Filial J,» Lima, 2014.
[34] C. b. estadística, «guiaspss,» [En línea]. Available:
http://www.ugr.es/~bioestad/guiaspss/practica6/.
[35] G. Córdoba, «Entelequia, revista interdisciplinar,» 2008. [En línea].
Available: http://www.eumed.net/entelequia/pdf/2012/e14a09.pdf.
[36] Chacín y Padrón, 1996. [En línea]. Available:
http://www.eumed.net/entelequia/pdf/2012/e14a09.pdf.
[37] Bello, 2006. [En línea]. Available: http://www.eumed.net/entelequia/pdf/2012/e14a09.pdf.
[38] Dekleva, 1992.
[39] [En línea]. Available: http://www.omg.org/spec/BPMN/1.2. 2009. (al 16/10/2009).
97
ANEXOS
Anexo 1 Presupuesto del Proyecto:
Descripción Detalle Observación TOTAL
Personal
Asesor 1000,00
Experto en S3m 3800,00
Experto en Bizagy 3000,00
Hardware
1 PC Dell i5, 4G Ram, 500GB HD 4500,00
1 Impresora HP Laserjet P4014 2200,00
1 Disco Duro Externo Toshiba 1 TB
Canvio Basics Black 350,00
1 USB 3.0 DT100G3/64GB DataTraveler
– Negro 150,00
1 Millar de papel bond A-4 25,00
3 Lapiceros pilot. 15,00
2 Cartuchos para la Impresora 500,00
Materiales de escritorio
Fotocopias 100,00
Libros, Manuales, artículos. 0,00
Servicio de Internet 100,00
Bizagi licencia 1300,00
SPSS Versión 22.00 1200,00
Capacitaciones 1000,00
Viáticos y pasajes 200,00
98
TOTAL 19440.00
Anexo 2- Entrevistas
99
100
101
102
103
104
105
106
107
Anexo 3- Imágenes de proceso de mantenimiento de software
Proceso de mantenimiento de software. Imagen 1
108
Proceso de mantenimiento de software - imagen 2
109
Proceso de Mantenimiento de Software – imagen 3
Proceso de Mantenimiento de Software – imagen 4
110
Proceso de Mantenimiento de Software - imagen 5
111
Proceso de mantenimiento de Software imagen 6
Anexo 4 - MOF de DIGESI
DEL DIRECTOR DE DIGESI
Es responsable de administrar los sistemas informáticos y tecnológicos de
la Universidad Peruana Unión - Filial Juliaca garantizando que se mantengan
operativos y actualizados, así mismo mantenerlo en un ambiente tecnológico
actualizado que satisfaga los requerimientos de información de todas las unidades de la
institución a corto, mediano y largo plazo.
FUNCIONES
Velar por la adecuada utilización, seguridad y conservación de los software,
hardware e información de las distintas unidades de la Filial.
112
Supervisar las actividades relacionadas con el soporte, mantenimiento y
monitoreo de software, cableado de datos, circuito eléctrico.
Dirigir las actividades de mantenimiento preventivo y correctivo de los equipos
de cómputo.
Verificar la actualización de equipos y sistemas operativos y de procesamiento
automático de datos, recomendando modificaciones y ampliaciones de los
mismos.
Supervisar el desarrollo, mejora, implementación y correcto funcionamiento de
los sistemas informáticos, verificando que cumplan las normas y estándares
establecidos.
Que Identificar oportunidades para la mejora de procedimientos y procesos de
acuerdo con el estándar adoptado.
Coordinar con los Especialistas de cada área la implementación de acciones
correctivas.
Elaborar en coordinación con cada Especialista programas de minimización de
errores y satisfacción a los usuarios.
Realizar estudios de factibilidad de los proyectos y requerimientos informáticos
Estructurar el plan de capacitación para los colaboradores del Área.
Estructurar las necesidades de inversión para su gestión con la
administración de la Filial.
Elaborar el plan de acción (plan operativo y presupuesto) del departamento.
Supervisar que el desarrollo tecnológico de la institución se adapte a una
estandarización de tecnologías de información y comunicaciones.
Buscar proveedores para la adquisición de equipos de calidad.
Asistir a presentaciones de hardware y software nuevos en el mercado.
Asumir cualquier otra tarea que le sea encomendada por el Director General
COMPETENCIAS LABORALES
Formación Básica:
Formación Profesional: Ingeniero en Ingeniería de Sistemas
Condición Complementaria: Especialización en Tecnologías de la Información
113
Experiencia Requerida: 4 años en el departamento respectivo
Idioma Extranjero: Ingles Nivel Intermedio
COORDINADOR DE DESARROLLO Y SOPORTE DE SISTEMAS
Gestionar los requerimientos de información de las unidades de la universidad,
que por el alcance de sus operaciones, volúmenes de datos y requerimientos específicos
de servicio, necesitan ser satisfechas mediante el desarrollo de sistemas informáticos.
FUNCIONES
Verificar que los resultados de los programas, satisfagan los requerimientos de
información de los usuarios.
Evaluar la funcionalidad de los métodos de trabajos establecidos y regulares de
las deficiencias detectadas.
Establecer mecanismos de medición que le permitan detectar a tiempo
desviaciones en los calendarios de compromisos, para establecer
correctivos oportunos.
Evaluar el nivel técnico de su personal y analizar si es congruente con la magnitud
de los proyectos en cartera.
Establecer los requerimientos de capacitación necesarios para sus grupos de
trabajo.
Elaborar el plan de trabajo del área.
Verificar que los métodos de trabajo establecidos sean respetados y puestos en
práctica.
Asignar las actividades de los proyectos en función de la importancia de servicio
de cada sistema.
Verificar que los procedimientos establecidos conduzcan a trabajos con la calidad
suficiente y que permitan labores seguras de mantenimiento.
Analizar las fallas en los sistemas puestos en producción, determinando las causas
y las acciones por emprender.
114
Investigar, analizar y evaluar las aplicaciones de nuevos sistemas y
procedimientos técnicos tendientes a mejorar, agilizar, modernizar y
actualizar los servicios de información ofrecidos a las diferentes áreas.
Participar de los procesos académicos de la institución gestionando el correcto
desarrollo (matrícula, admisión, evaluación docente, entre otros).
Evaluar las necesidades de apoyo informático y reunirse con los
responsables para definir los resultados a obtener en cada trabajo a
elaborarse.
Planificar que los requerimientos de hardware y software involucrados en el
desarrollo de los sistemas, se encuentren disponibles en las fechas en que serán
utilizados.
Establecer, junto con el responsable de cada unidad usuaria, el plan estratégico
para el inicio y desarrollo de los sistemas.
Analizar el alcance de los proyectos de sistemas que consideren inversiones no
previstas con anterioridad, a fin de lograr su autorización.
Precisar los objetivos, alcances, normas y políticas que regirán cada sistema.
Administrar en conjunto con el usuario, la puesta en marcha de los módulos de
cada sistema.
Verificar que las pruebas de módulos cubran todas las condiciones determinadas
para el proceso de los datos de cada sistema.
Participar en seminarios administrativos y técnicos que le permitan conocer la
evolución de los recursos de cómputo para que los diseños se apeguen a los
métodos modernos.
COMPETENCIAS LABORAL
Formación Profesional: Licenciatura en Ingeniería de Sistemas
Condición Complementaria:
Certificación en Administración de Proyecto
Conocimiento de soporte, hardware, y reingeniería de procesos
Experiencia Requerida: 2 años en el área respectiva
Idioma Extranjero: Ingles Nivel Intermedio
DEL ANALISTA DESARROLLADOR DE SISTEMAS ACADÉMICOS
115
Diseñar detalladamente los requerimientos del sistema académico, programando
nuevos módulos, reportes o actualizaciones de módulos.
FUNCIONES
Realizar investigaciones y entrevistas a nivel usuario operativo, para desarrollar
el diseño detallado de los módulos del sistema académico.
Elaborar el calendario de actividades detallado para el diseño y
programación de los módulos asignados.
Desarrollar el diseño detallado de los módulos del sistema.
Coordinar las pruebas con el Coordinador de Desarrollo de Sistemas sobre los
módulos por liberar.
Realizar la programación y prueba de cada programa resultante del diseño
detallado.
Documentar el diseño detallado con base en los estándares establecidos.
Participar en seminarios de actualización que le permitan mejorar sus diseños y
programación.
Realizar la prueba integral de cada módulo asignado.
Capacitar a los usuarios en la implementación de los módulos del sistema
asignado.
Realizar el mantenimiento necesario para los módulos de su
responsabilidad.
COMPETENCIAS LABORALES
Formación Profesional: Licenciatura en Ingeniería de Sistemas
Conocimiento de análisis y programación
Conocimiento de diseño web
Experiencia Requerida: 2 años en el área respectiva
Idioma Extranjero: Ingles Nivel Intermedio
DEL ANALISTA DESARROLLADOR DE SISTEMA CONTABLE
116
Diseñar detalladamente los requerimientos del sistema contable, programando
nuevos módulos, reportes o actualizaciones de módulos.
FUNCIONES
Realizar investigaciones y entrevistas a nivel usuario operativo, para desarrollar
el diseño detallado de los módulos del sistema contable.
Elaborar el calendario de actividades detallado para el diseño y
programación de los módulos asignados.
Desarrollar el diseño detallado de los módulos del sistema.
Coordinar las pruebas con el Coordinador de Desarrollo de Sistemas sobre los
módulos por liberar.
Realizar la programación y prueba de cada programa resultante del diseño
detallado.
Documentar el diseño detallado con base en los estándares establecidos.
Participar en seminarios de actualización que le permitan mejorar sus diseños y
programación
Realizar la prueba integral de cada módulo asignado.
Capacitar a los usuarios en la implementación de los módulos del sistema
asignado.
Realizar el mantenimiento necesario para los módulos de su
responsabilidad.
COMPETENCIAS LABORALES
Formación Profesional: Ingeniero en Ingeniería de Sistemas
Conocimiento de análisis y programación
Conocimiento de diseño web
Conocimientos en Contabilidad a nivel intermedio
Experiencia Requerida: 1 año en el área respectivo
Idioma Extranjero: Ingles Nivel Intermedio
117
DEL ANALISTA PROGRAMADOR
Diseñar detalladamente los requerimientos del sistema, programando nuevos
módulos, reportes o actualizaciones de módulos.
FUNCIONES
Realizar investigaciones y entrevistas a nivel usuario operativo, para desarrollar
el diseño detallado de los módulos del sistema.
Elaborar el calendario de actividades detallado para el diseño y programación de
los módulos asignados.
Desarrollar el diseño detallado de los módulos del sistema.
Coordinar las pruebas con el Coordinador de Desarrollo de Sistemas sobre los
módulos por liberar.
Realizar la programación y prueba de cada programa resultante del diseño
detallado.
Documentar el diseño detallado con base en los estándares establecidos.
Participar en seminarios de actualización que le permitan mejorar sus diseños y
programación.
Realizar la prueba integral de cada módulo asignado.
Capacitar a los usuarios en la implementación de los módulos del sistema
asignado.
Realizar el mantenimiento necesario para los módulos de su responsabilidad.
COMPETENCIAS LABORALES
Formación Básica:
Formación Profesional: Ingeniero en Ingeniería de Sistemas
Condición Complementaria:
Conocimiento de análisis y programación
Conocimiento de diseño web
Conocimientos en Contabilidad a nivel intermedio
Experiencia Requerida: 1 año en el área respectiva
Idioma Extranjero: Ingles Nivel Intermedio
118
Con el fin de conocer parte de la realidad, se solicitó al Área de Soporte y
Desarrollo de Sistemas un documento donde se pueda observar el diagnóstico
situacional y sus limitaciones.
Anexo 5- Estado situacional de Soporte y Desarrollo de Sistemas 2014
Diagnóstico y Limitaciones del Área
El área de Desarrollo y Soporte de Sistemas de la DIGESI UPeU Filial Juliaca,
es el ente de apoyo a las diferentes áreas, velando por el buen funcionamiento de los
siguientes sistemas:
Sistema académico
Sistema contable
Sistema de matrícula UPeU
Sistema de matrícula CAT
Sistema de biblioteca
Sistema de pedidos (SIM)
Sistema de residencias
Sistema integral para institutos (idiomas)
En esta área se cuenta con 4 personas que laboran en horario completo, las
cuales tienen la siguiente responsabilidad:
01 Jefe de Desarrollo de Sistemas.
01 Analista programador, priorizando sistema académico.
01 Analista programador, priorizando sistema contable.
01 Analista programador, dedicado al sistema integral para institutos.
Lista de Software que el Area utiliza:
Sql developer
SPRING
Netbeans
Sublime Text
BlueFish
119
Microsoft office
Putty, Xming
Limitaciones:
Los nuevos módulos implementados en la Sede Lima, no cuentan con un manual
de funcionamiento que sean compartidos con la filial.
No se cuenta con un servidor de pruebas (base de datos y aplicaciones).
No se cuenta con servidor de archivos (almacenamiento versionado de las
aplicaciones).
No se cuenta con un modem para la continuidad de la conexión.
Falta de capacitación en temas emergentes.
Anexo 6- SLA para Soporte y Desarrollo de Sistemas
Descripción general
1. Introducción
Mantenimiento: Consiste en un centro de atención telefónico y por correo
electrónico para la comunicación y resolución de problemas, consultas e incidencias.
Los técnicos encargados están capacitados para la detección y definición de problemas
asociados con los productos y su resolución, así como para la instalación, en su caso, de
las sucesivas actualizaciones de los productos. Puede requerir el acceso remoto a los
sistemas del Cliente para realizar su tarea
2. Mantenimiento vs. Soporte
Se entiende como servicio de Mantenimiento aquellas acciones que el Área de
Desarrollo y Soporte de Sistemas se compromete a realizar de forma:
Preventiva: Mediante el desarrollo de actualizaciones de seguridad y de funcionamiento
del software y la cesión de las mismas a sus clientes.
120
Evolutiva: Mediante el versionado del aplicativo, tanto en mejoras internas y de
interface del usuario, como en nuevas funcionalidades.
Reactiva: Mediante un servicio Helpdesk por diversas vías de comunicación (teléfono,
e-mail-web,etc.) para ayudar a los usuarios
a solucionar averías del hardware y funcionamientos incorrectos del software, así como
la logística necesaria para las reparaciones físicas y la distribución de mejoras de
software.
Se entiende como Servicio de Soporte y no contemplado en el contrato de
mantenimiento:
La consultoría informática, ayudando al cliente y al distribuidor a diseñar instalaciones
particulares.
La atención helpdesk sobre consultas de configuración del software, diferentes de las
asociadas a un mal funcionamiento del producto.
Las asistencias técnicas en instalaciones y la ejecución de puestas en marcha de nuevas
instalaciones del producto.
Las asistencias técnicas asociadas a reconfiguraciones y mejoras de productos ya
instalados y no asociadas a averías ni a fallos del software.
Para los servicios de Soporte no contemplados como servicio de Mantenimiento, se
facturará según las tarifas vigentes en el momento del servicio y que se pondrán a
disposición del cliente cuando éste las solicite.
3. Período de servicio y finalización
Duración: El presente SLA entra en vigor desde la fecha desde el 1 de
noviembre del 2014, siendo prorrogable por períodos anuales si se decide renovar el
servicio, salvo indicación expresa de cualquiera de las partes, que deberá ser notificada
por escrito a la otra parte con una antelación mínima de 3 meses a la fecha de
finalización del plazo inicial o de cualquiera de sus prórrogas.
4. Garantía de los servicios
121
El Área de Desarrollo y Soporte de Sistemas garantiza la prestación del servicio
de mantenimiento, en los términos especificados en este SLA, de forma adecuada a cada
caso y con observancia de la diligencia profesional y técnica debida.
5. Cesión y subcontratación
El Área de Desarrollo y Soporte de Sistemas queda autorizada a ceder o
subcontratar con terceras empresas el servicio de mantenimiento contratado, sin
necesidad de comunicación ni consentimiento del Cliente y sin que ello implique
modificación de las condiciones establecidas en este contrato.
6. Confidencialidad
Cualquiera de las partes que reciba información confidencial de la otra, deberá
mantenerla de forma reservada y utilizarla única y exclusivamente de acuerdo con la
finalidad para la que haya sido revelada. En especial, el Área de Desarrollo y Soporte de
Sistemas se compromete y obliga a respetar, no utilizar y considerar como secreto de
empresa toda información que le sea suministrada o de la que tenga conocimiento como
consecuencia del desarrollo de las actividades establecidas en el presente contrato, tanto
información general del Cliente como claves de acceso informático y configuración de
las instalaciones, respondiendo de cualquier actuación contraria a dicha obligación
efectuada por cualquiera de sus trabajadores o personal.
Servicios provistos y responsabilidad
1. Modalidad de Mantenimiento
Mantenimiento prestado por el Área de Desarrollo y Soporte de Sistemas, a
todas los Departamentos de la UPeU que usan los sistemas Académico y Contable, en
horario, de Lunes a jueves de 7:30 hrs. -12:00 hrs y 14:00 y de 18:30 y viernes de 7:30
hrs. a 13:00 hrs., los días laborables, no festivos nacionales en Perú, y con el contenido
concreto que se especifica en el cuadro anexo de Desarrollo y Soporte de Sistemas.
2. Criticidad de la Incidencia
Los tiempos de respuesta para los distintos tipos de contrato, en función de la
criticidad de la incidencia.
122
Se entiende como tiempo de respuesta el tiempo máximo para emprender una acción
correctora de la incidencia, a contar a partir del momento de recibir la petición de
asistencia.
La criticidad de la incidencia se decidirá en el momento de recepción de la misma en
función de la afectación de servicio que suponga para el cliente:
Criticidad alta: aquellas incidencias con afectación de servicio visible para los usuarios
del sistema (que afecte su trabajo habitual con la red o los sistemas).
Criticidad media: incidencias con afectación de servicio que no sea visible para los
usuarios del sistema (que no afecte su modo habitual de trabajo).
Criticidad baja: otras incidencias sin afectación de servicio.
Para todo ello, el Área de Desarrollo y Soporte de Sistemas, dispone de los siguientes
métodos de contacto:
Teléfonos de Soporte y Mantenimiento:
RPM Mesas de ayuda : 951292515.
RPM Soporte de Sistemas : 950302636
e-mail: [email protected], [email protected], para poder prestar los
servicios descritos en este SLA. En un plazo máximo de 30 minutos, el cliente debe
haber podido contactar con un técnico cualificado del Área de Desarrollo y Soporte de
Sistemas, que se hará cargo de la incidencia.
3. Precio
El Cliente satisfará, en concepto de precio por los servicios de mantenimiento, el
importe que corresponda a la modalidad de mantenimiento contratada y al equipo sobre
el que se preste dicho mantenimiento, según precios propuestos.
4. Evaluación del Servicio
Área de Desarrollo y Soporte de Sistemas, evaluará internamente, los servicios
prestados a sus clientes, con el objetivo de realizar un seguimiento de:
Evolución general del servicio.
123
Calidad de servicio.
Volumen de incidencias y tipología.
Evolución y mejora del mismo.
También y, a petición del cliente, se podrán realizar evaluaciones puntuales si se
estiman necesarias.
5. Responsabilidad
Área de Desarrollo y Soporte de Sistemas, responderá frente al cliente de
cualquier perjuicio que, por actuación incorrecta o negligente, pudiera causarle en la
ejecución de las actividades establecidas en el presente contrato.
6. Jurisdicción
Todos aquellos litigios o controversias relativos al presente sitio o servicios
relacionados con la misma, se resolverán mediante la legislación Peruana, a la que se
someten expresamente las partes, siendo competentes para la resolución de todos los
conflictos derivados o relacionados con su uso los Juzgados y Tribunales del Perú.
Implementación del Servicio de mantenimiento por adelantado y Helpdesk
Para realizar la implementación de este servicio, se formalizará la creación de un
responsable en el tema, para desempeñar esta labor. Del cuerpo del personal ya
existente, se va a delegar a una persona, quien se dedicará a tiempo completo para
mantener las aplicaciones en perfecto funcionando, quien debe de reaccionar
rápidamente para restablecer el servicio, cuando se produce un problema, el cual debe
de cumplir con el nivel acordado de servicio (SLA).
El encargado debe de manejar este servicio mediante técnicas de gestión de colas.
A petición del usuario específico, a veces llamado un «billete», típicamente circular
entre el servicio de asistencia, mantenimiento de software, y las operaciones con el fin
de aislar un problema
124
Anexo 7- Instalación de Bizagi Xpress
1. Ejecute el instalador
Ejecute BizagiXpressexe para comenzar el proceso de instalación.
El instalador debe ser ejecutado con una cuenta con derechos de administrador
(miembro del grupo de Administradores del servidor).
125
Seleccione el idioma para la instalación (inglés o español)
El asistente del instalador aparecerá:
126
2. Proceda con la instalación
Cuando la ventana de Bienvenida del instalador se abra, haga clic en lo siguiente:
127
3. Lea el acuerdo de licencia
Acepte el acuerdo de la licencia de Bizagi y haga clic en Siguiente.
128
4. Seleccione la base de datos a utilizar
La instalación detectará si ya hay una instancia de Servidor SQL instalada.
Si este no es el caso, usted puede seleccionar la opción para incluir una instalación de
SQL Server Express 2008 Service pack 3 (seleccionando "Instalar SQL Server Express
2008 SP3").
Cuando se instale el SQL Server Express 2008 SP3 incluido en la instalación, las credenciales por defecto para acceder
el servidor son:
●LOGIN: sa
●PASSWORD: Bizagi10GO
129
Si usted prefiere no incluir esta instalación de SQL Server o si usted ya posee una
instancia de este, puede seleccionar la opción "Verificar acceso a una base de datos SQL
Server ya instalada".
Con dicha opción, es necesario que provea el Nombre de Usuario y contraseña
(autenticación SQL Server) para esta conexión, en la ventana que emergerá.
Después de ingresar la información, dé clic en Login para verificar la conexión.
Una ventana se muestra para informar el éxito de la misma.
Dé clic en OK para continuar.
130
5. Ingrese la información de usuario
Ingrese el nombre de usuario (User Name) y el nombre de la compañía (Company
Nace) para la instalación. Clic en Siguiente.
131
6. Seleccione el Ambiente de Instalación
En el Tipo de Configuración seleccione la instalación de componentes para Ambiente
de desarrollo o Ambiente de pruebas/producción de acuerdo a sus necesidades.
Seleccione desarrollo (Ambiente de Autoría) si la instalación se utilizará para modelar y
automatizar Procesos, donde será necesario utilizar Bizagi Studio.
De lo contrario, seleccione ambientes de producción o pruebas para instalar el Servidor
BPM de Bizagi y la Consola de Administración de Bizagi (pero no Bizagi Studio).
Luego dé clic en siguiente para continuar.
132
7. Seleccione la ruta de instalación
Haga clic en Siguiente si usted desea instalar Bizagi en la carpeta de destino por defecto
("C:\Program Files\...").
De lo contrario, para seleccionar una ubicación diferente, dé clic en Examinar y
seleccione el directorio deseado.
8. Revise las preferencias
En la siguiente ventana, revise la configuración si no desea que Bizagi le notifique de
manera automática cuando hay una nueva versión disponible.
Para que Bizagi revise si hay nueva versión y le notifique, asegúrese de tener marcada la
casilla Comprobar si hay actualizaciones.
Haga clic en Siguiente.
133
134
9. Inicie el proceso de instalación
En la siguiente ventana, haga clic en Instalar para comenzar con la instalación.
Bizagi instalará los componentes requeridos como: Framework 4.0 de .NET y Visual C++ 2008 Redistributable, si no
se encuentran instalados previamente.
135
136
10. Finalice la instalación
La instalación de Bizagi comenzará:
137
La siguiente ventana aparecerá cuando la instalación haya terminado.
Clic en el botón Finalizar.
138
Empezar a utilizar la edición Xpress de Bizagi
Para empezar la automatización de su proceso (crear un nuevo proyecto en Bizagi),
utilice Bizagi Studio Enterprise para ambientes de desarrollo. Usted puede empezar a
utilizar Bizagi Xpress dando clic en el ícono de Bizagi Studio (acceso rápido) como se
muestra a continuación.
También se puede ejecutar Bizagi Studio navegando por el menú de Inicio.
139