biblioteca.uci.ac.cr · figura 3 ubicaciÓn geogrÁfica de minera san cristÓbal s.a. (global...
TRANSCRIPT
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
PROPUESTA DE MEJORA AL DISEÑO DE LOS PROCEDIMIENTOS DE
ADMINISTRACIÓN DE PROYECTOS DE DESARROLLO DE SISTEMAS DE
INFORMACIÓN DE MINERA SAN CRISTÓBAL
EKAR RODRIGO ZAVALA YAÑEZ
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO
PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN
ADMINISTRACIÓN DE PROYECTOS
San José, Costa Rica
JULIO de 2011
i
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como
Requisito parcial para optar al grado de Máster en Administración de Proyectos
__________________________
Marlon Velásquez
PROFESOR TUTOR
_________________________
Juan Carlos Gómez Sánchez S. MAP, MAE
LECTOR No.1
__________________________
Ing. Sergio Villalobos Álvarez, MBA
LECTOR No.2
________________________
Ekar Zavala Yañez
SUSTENTANTE
ii
DEDICATORIA
A mi familia, por todo el apoyo que me dan,
a mis sobrinos por toda la alegría que me dan y las ganas de vivir,
y a todos los que siempre estuvieron para darme una mano en la vida.
iii
RECONOCIMIENTOS
A Dios, por todos los milagros realizados.
Al profesor Marlon Velásquez por el apoyo positivo, el tiempo y la confianza
otorgada.
iv
ÍNDICE DE CONTENIDO 1 INTRODUCCIÓN ......................................................................................................................................... 3
1.1 ANTECEDENTES. .............................................................................................................................. 3 1.2 PROBLEMÁTICA ................................................................................................................................ 5 1.3 JUSTIFICACIÓN DEL PROYECTO .................................................................................................... 6 1.4 OBJETIVO GENERAL ........................................................................................................................ 6 1.5 OBJETIVOS ESPECÍFICOS ............................................................................................................... 6 1.6 ENTREGABLES .................................................................................................................................. 7
2 MARCO TEÓRICO ...................................................................................................................................... 8 2.1 MARCO REFERENCIAL ..................................................................................................................... 8 2.2 MISIÓN ............................................................................................................................................... 8 2.3 VISIÓN ................................................................................................................................................ 9 2.4 VALORES ........................................................................................................................................... 9 2.5 POLITICA DE GESTIÓN DE MINERA SAN CRISTOBAL ................................................................... 9 2.6 NORMA ISO 9000-3 ......................................................................................................................... 10
2.6.1 RESEÑA .................................................................................................................................. 10 2.6.2 BENEFICIOS ........................................................................................................................... 10 2.6.3 GENERALIDADES, CAMPO DE APLICACIÓN Y ALCANCE .................................................. 11 2.6.4 ANÁLISIS DE LA ISO 9000-3 .................................................................................................. 11 2.6.5 BENEFICIOS ........................................................................................................................... 11 2.6.6 ESTRUCTURA DE LA ISO 9000-3 .......................................................................................... 12 2.6.7 DESCRIPCIÓN DE LAS SECCIONES ..................................................................................... 12
2.7 ADMINISTRACIÓN DE PROYECTOS .............................................................................................. 14 2.7.1 DEFINICIÓN DE PROYECTO ................................................................................................. 14 2.7.2 PROYECTOS Y TRABAJOS OPERATIVOS ........................................................................... 15 2.7.3 PROYECTOS Y PLANIFICACIÓN ESTRATÉGICA ................................................................. 15 2.7.4 ADMINISTRACIÓN DE PROYECTOS ..................................................................................... 16 2.7.5 CICLO DE VIDA DEL PROYECTO Y LA ORGANIZACIÓN ..................................................... 17 2.7.6 RELACIONES DEL CICLO DE VIDA DEL PROYECTO Y DEL PRODUCTO .......................... 17 2.7.7 ESTRUCTURA DE LAS ORGANIZACIONES .......................................................................... 17 2.7.8 SISTEMA DE GESTIÓN DE PROYECTOS ............................................................................. 18 2.7.9 PROCESOS DE DIRECCIÓN DE PROYECTOS ..................................................................... 18 2.7.10 AREAS DE CONOCIMIENTO DE LA ADMINISTRACIÓN DE PROYECTOS .......................... 20
2.8 LENGUAJE UNIFICADO DE MODELADO UML ............................................................................... 23 2.8.1 DIAGRAMAS UML ................................................................................................................... 23 2.8.2 MODELANDO PROCEDIMIENTOS DE NEGOCIO CON UML ................................................ 25 2.8.3 MODELANDO PROCEDIMIENTOS DE NEGOCIO MEDIANTE DIAGRAMAS DE ACTIVIDAD 25
3 MARCO METODOLÓGICO ....................................................................................................................... 29 3.1 FUENTES DE INFORMACIÓN ......................................................................................................... 29 3.2 MÉTODOS DE INVESTIGACIÓN ..................................................................................................... 30
3.2.1 DESCRIPCIÓN DE LAS HERRAMIENTAS ............................................................................. 30 4 DESARROLLO .......................................................................................................................................... 32
4.1 SOLICITUD A IS&T ........................................................................................................................... 32 4.2 ESTRUCTURA ORGANIZACIONAL ................................................................................................. 33 4.3 IDENTIFICACIÓN DEL PROCESO ACTUAL .................................................................................... 34
4.3.1 ANÁLISIS DE NECESIDADES ................................................................................................ 34 4.3.2 PLANIFICACIÓN DE PROYECTO ........................................................................................... 37 4.3.3 DISEÑO ................................................................................................................................... 39 4.3.4 DESARROLLO (DEL SISTEMA) .............................................................................................. 41 4.3.5 VALIDACIÓN ........................................................................................................................... 42 4.3.6 VERIFICACIÓN PRUEBA ........................................................................................................ 43
4.4 HISTORIAL DE PROYECTOS EN MSC ........................................................................................... 44 4.5 DIAGNÓSTICO DE LA GESTIÓN ACTUAL ...................................................................................... 48
4.5.1 IDENTIFICACIÓN DE OPORTUNIDADES DE MEJORA ......................................................... 50 4.6 PROPUESTA DE MEJORA .............................................................................................................. 54
4.6.1 ESTRUCTURA ORGANIZACIONAL PROPUESTA ................................................................. 54 4.6.2 PROCEDIMIENTO GENERAL DE GESTIÓN DE PROYECTOS ............................................. 55 4.6.3 CICLO DE VIDA DE DESARROLLO DE SOFTWARE ............................................................. 69 4.6.4 INDICADORES DE DESEMPEÑO........................................................................................... 76
5 CONCLUSIONES ...................................................................................................................................... 82 6 RECOMENDACIONES.............................................................................................................................. 84 7 BIBLIOGRAFÍA.......................................................................................................................................... 86 8 ANEXOS ................................................................................................................................................... 87
v
ÍNDICE DE FIGURAS FIGURA 1 MACRO PROCESOS DE GESTIÓN DE PROYECTOS EN MSC (MSC, 2010) 5
FIGURA 2 CICLO DE VIDA DEL PROYECTO Y ENTREGABLES 7
FIGURA 3 UBICACIÓN GEOGRÁFICA DE MINERA SAN CRISTÓBAL S.A. (GLOBAL INFOMINE, 2010) 8
FIGURA 4 CONTEXTO DE PROYECTOS (PMI, 2008) 15
FIGURA 5 PROCESOS DE DIRECCIÓN DE PROYECTOS (PMI, 2008) 16
FIGURA 6 EJEMPLO DIAGRAMA DE ACTIVIDADES (SPARX, 2011) 26
FIGURA 7 REPRESENTACIÓN DE UNA ACTIVIDAD (SPARX, 2011) 26
FIGURA 8 REPRESENTACIÓN DE NODOS DE DECISIÓN Y COMBINACIÓN (SPARX, 2011) 27
FIGURA 9 REPRESENTACIÓN DE NODOS DE BIFURCACIÓN Y UNIÓN (SPARX, 2011) 27
FIGURA 10 REPRESENTACIÓN DE UN OBJETO (SPARX, 2011) 27
FIGURA 11 REPRESENTACIÓN DE UN NODO INICIAL (SPARX, 2011) 28
FIGURA 12 REPRESENTACIÓN DE UN NODO FINAL (SPARX, 2011) 28
FIGURA 13 PROCEDIMIENTOS IDENTIFICADOS EN EL ÁREA DE IS&T 32
FIGURA 14 ESTRUCTURA ORGANIZACIONAL DE MSC 33
FIGURA 15 SECUENCIA DE PROCESOS IDENTIFICADOS 34
FIGURA 16 ANÁLISIS DE NECESIDADES 35
FIGURA 17 PLANIFICACIÓN DEL PROYECTO 37
FIGURA 18 DISEÑO DE LA SOLUCIÓN 39
FIGURA 19 DESARROLLO DE LA SOLUCIÓN 41
FIGURA 20 PRUEBAS DE LA SOLUCIÓN DESARROLLADA 42
FIGURA 21 VALIDACIÓN 43
FIGURA 22 DISTRIBUCIÓN DE PROYECTOS IS&T 44
FIGURA 23 DIAGRAMA DE ESPINA DE PESCADO 50
FIGURA 24 ESTRUCTURA ORGANIZACIONAL PROPUESTA 55
FIGURA 25 PROPUESTA PROCESO GENERAL DE GESTIÓN DE PROYECTOS 55
FIGURA 26 INICIACIÓN 57
FIGURA 27 PLANIFICACIÓN 58
FIGURA 28 ESTABLECER ESTIMACIONES 59
FIGURA 29 DESARROLLAR EL PLAN DEL PROYECTO 62
FIGURA 30 EJECUCIÓN 64
FIGURA 31 SEGUIMIENTO Y CONTROL 66
FIGURA 32 CIERRE 68
FIGURA 33 CICLO DE VIDA DE DESARROLLO DE SOFTWARE 69
FIGURA 34 PRE PROYECTO CICLO DE VIDA 70
FIGURA 35 EVOLUCIÓN 71
FIGURA 36 ANÁLISIS Y DISEÑO LÓGICO DE EVOLUCIÓN 72
FIGURA 37 AJUSTE 73
FIGURA 38 CONSTRUCCIÓN Y PRUEBAS INTERNAS 74
FIGURA 39 ACEPTACIÓN Y PASE A PRODUCCIÓN 75
FIGURA 40 HERRAMIENTAS TECNOLÓGICAS UTILIZADAS 77
FIGURA 41 INSUMOS UTILIZADOS 78
FIGURA 42 FORMULARIOS UTILIZADOS 79
FIGURA 43 ENTREGABLES DE PROYECTOS DE SISTEMAS DE INFORMACIÓN 80
FIGURA 44 MODELOS SOLICITADOS PARA EL DESARROLLO DE SOFTWARE 81
vii
DEFINICIONES Y ABREVIACIONES ABREVIACIONES EDT: Estructura de desglose de trabajo (WBS).
IS&T: Sistemas de Información y tecnología
MSC: Minera San Cristóbal
PFG: Proyecto Final de Grado
PMI: Project Management Institute
PMO: Project Management Office
QA: Aseguramiento de Calidad (Quality Assurance)
UML: Lenguaje Unificado de Modelado (Unified Model Language).
DEFINICIONES Ajuste: Se entiende como un ajuste a los desarrollos o implementaciones de
menor escala tales como correcciones de defectos, re-configuraciones,
afinaciones o menores extensiones a un Sistema ya existente. El criterio
principal para clasificar una solicitud como ajuste es no tener la necesidad de
realizar un proceso de selección de solución.
Calidad: Según ISO 8402, “Calidad son todas las características que permiten
que un producto satisfaga necesidades explicitas o implícitas a un costo
aceptable.” De esta manera podemos decir que la calidad de los productos
puede ser medida a través de la comparación de sus características y atributos.
Casos de uso: Son representaciones del comportamiento de la aplicación o
módulo; el objetivo es proveer al diseño una explicación del valor agregado de
la aplicación hacia entidades externas; como los actores.
Evolución: Es un comportamiento posible como resultado de una solicitud.
Para atender la solicitud se requerirá desarrollos o implementaciones a mayor
escala. El criterio principal para clasificar una solicitud como una evolución es
tener la necesidad de realizar un proceso de selección donde se analiza los
requerimientos y elige el tipo de solución.
ISO: La Organización Internacional para la Estandarización es la agencia
especializada en estandarización más grande a nivel mundial, establecida en
1947 con la finalidad de promover la estandarización internacional para facilitar
el intercambio de bienes y servicios así como de desarrollo científico y
tecnológico. Actualmente ISO abarca los estándares nacionales de 159
países. ISO comprende alrededor de 180 comités técnicos encargados de
vii
desarrollar desde las abreviaturas de los sistemas de medición hasta la
especificación detallada de los productos a evaluar.
Modelo: Es una representación gráfica, visual y abstracta de una realidad
actual o virtual. La herramienta para modelar aplicaciones en MSC es
Enterprise Architect.
Modelo de Componentes: Es la representación gráfica de los componentes
utilizados como entregables para el pase a producción de la aplicación.
Modelo Físico: Es la representación física de la composición y ubicación de
los datos a ser utilizados en el modelo; es el diagrama del repositorio de
información fuente a ser trabajada. Puede tratarse de una base de datos
relacional o ad-hoc.
Modelo Lógico: Es la representación de la lógica de la aplicación o módulo,
tiene tres componentes principales: el componente de usuario, las reglas de
negocio y el componente de datos.
Pool de Proyectos: Piscina de proyectos. Son todos los proyectos a realizar
más su priorización.
Prototipo: Es una representación burda del modelo final, no contiene la
funcionalidad final su único propósito es lograr una vista inicial de la aplicación
para el usuario final de manera que se puedan trabajar en detalles antes de
empezar la construcción.
1
RESUMEN EJECUTIVO
Minera San Cristóbal tiene la visión de ser una empresa minera boliviana de
clase mundial. Parte de su estrategia de negocio incluye mantener la triple
certificación ISO 9000, ISO 14000 y OSHAS 18000. Para mantener la ISO
9000 se cuenta con un sistema de gestión basado en procedimientos,
indicadores y su continua mejora.
Dentro de los procedimientos vigentes, se encuentra el procedimiento general
de Administración de Proyectos del cual se desprende los procedimientos de
Administración de Proyectos de Desarrollo de Sistemas de Información.
El uso de los procedimientos de Administración de Proyectos de Desarrollo de
Sistemas de Información tiene detallado el ciclo de vida de desarrollo de
software a seguir, sin embargo se evidencia el retraso de los proyectos a causa
la gestión de los proyectos.
Con base en esta necesidad, se propuso mejorar el proceso actual de
Administración de Proyectos de Desarrollo de Sistemas de información
agregando actividades de gestión de proyectos basados en el PMBOK que
ayuden a los administradores a gestionar tiempo, alcance y costos.
Para este trabajo se utilizó el método de investigación Objetivo-Subjetivo. Se
analizó la documentación de los procedimientos vigentes más su respectiva
evidencia de cumplimiento. Este análisis ayudó a identificar oportunidades de
mejora.
Posteriormente, se plantearon nuevos procedimientos de Administración de
Proyectos de Desarrollo de Sistemas de Información que incluyen las
oportunidades de mejora identificadas. Los procedimientos planteados cuentan
con actividades de administración de proyectos incluyendo sus respectivos
insumos, responsables, actores, entregables e indicadores. Además, se
muestra la forma que se debe almacenar la evidencia de su cumplimiento. Los
procedimientos sirven de una guía de las actividades y herramientas mínimas
que se deben seguir para administrar un proyecto, además de ser una
herramienta para contar con insumos para proyectos futuros e incrementar la
probabilidad de proyectos exitosos.
Es importante destacar que dentro de los procedimientos planteados, las
actividades de administración de proyectos están totalmente separadas del
2
ciclo de vida de desarrollo de sistemas de información. Se ve conveniente
mantener esta individualidad para dar mejor entendimiento de las actividades
de administración de proyectos y las actividades de desarrollo de software ya
que por la naturaleza cíclica de la administración de proyectos, las actividades
de administración de proyectos, consumen las actividades del ciclo de vida de
desarrollo de software.
En caso que se decida implementar los nuevos procedimientos, se recomienda
realizar un plan de cambio que facilite la coordinación de las actividades y el
control de las acciones de todos sus integrantes. Del mismo modo, se
recomienda implementar una estructura matricial equilibrada con el fin de
otorgar mayor poder al administrador de proyectos especialmente los recursos.
3
1 INTRODUCCIÓN
1.1 ANTECEDENTES. Minera San Cristóbal S.A. (MSC) es una empresa minera boliviana.
Actualmente es subsidiaria de Sumitomo Corporation Japón. MSC es el
segundo proyecto minero más grande del mundo para explotación de minerales
de zinc y plomo. Por la magnitud y tecnología de sus instalaciones, este
proyecto se constituye actualmente en la obra de infraestructura minera más
grande de Sudamérica.
La mineralización explotada es de baja ley pero de gran volumen y, por esta
razón, el método de explotación usado es el de tajo abierto. La operación está
orientada a la producción de minerales concentrados de zinc-plata y plomo-
plata y a su posterior envío a mercados internacionales. (MSC, 2010)
Por sus características, MSC no sólo cumple con los estándares ambientales
bolivianos, sino también con la norma de gestión ambiental ISO14001 y acata
estrictamente la legislación laboral vigente en el país y aplica los más altos
estándares mundiales de seguridad industrial y salud ocupacional, entre ellos la
norma de seguridad OHSAS18001. (MSC, 2010)
Las operaciones de MSC se basan en el uso de tecnología de punta que
permite maximizar el aprovechamiento de los yacimientos con el mínimo riesgo
para la seguridad de los trabajadores y manteniendo los impactos ambientales
dentro de los límites permisibles.
MSC tiene 10 años de compromiso con Bolivia, proporcionando tecnología,
experiencia, conocimiento e inversión. (Global Infomine, 2010)
MSC busca convertirse en el referente de la nueva minería en Bolivia, aquélla
que no sólo explota los yacimientos, sino que deja un aporte tangible al
desarrollo sostenible de las zonas donde opera.
MSC construyó un proyecto que es el más grande en la historia de la minería
en Bolivia.
En fecha 9 de noviembre de 1998, se da inicio a las obras de construcción del
nuevo pueblo San Cristóbal las cuales estuvieron a cargo del consorcio Tauro –
Alto – Tecnoplan. La finalización de la construcción del pueblo se cumplió de
acuerdo a las fechas establecidas en el contrato, el 7 de junio de 1999. De
acuerdo con los documentos de licitación, los contratistas cumplieron con todas
4
las regulaciones establecidas incluyendo beneficios sociales, impuestos,
seguridad industrial y medio ambiente. El 9 de junio de 1999 se realiza el acto
de entrega del nuevo pueblo San Cristóbal.
Al finalizar la construcción se entregaron: 145 casas, 1 Escuela, 1 Hospital, 1
Capilla, Casa de Gobierno, Campos deportivos, 1 Hotel, Caminos,
Instalaciones sanitarias, Instalaciones eléctricas. (MSC, 2010)
En la etapa de construcción de la planta de tratamiento y de la infraestructura
relacionada, MSC ocupó a 5.000 personas aproximadamente. Además, se
crearon aproximadamente 12.000 empleos indirectos.
Actualmente MSC cuenta con aproximadamente 1.000 trabajadores
permanentes y genera alrededor de 3.000 empleos indirectos. (MSC, 2010).
El Departamento de Sistemas de Información y Tecnología IS&T en MSC es
responsable de proveer a la empresa los servicios, recursos e infraestructura
de Tecnología de Información y de esta manera contribuir al logro de sus
objetivos (MSC, 2010).
Uno de los recursos más importantes que administra el departamento de
Sistemas de Información y Tecnología (IS&T) es la información, que como el
resto de los activos de la institución, tiene un alto valor para MSC. Por esta
razón, la Gestión del Departamento de IS&T se basa bajo los siguientes
criterios según estándares y normas internacionales:
• Confidencialidad. Garantizar que la infirmación sea accesible solo a
aquellas personas autorizadas a tener acceso a ella.
• Integridad. Salvaguardar la exactitud y totalidad de la información y los
métodos de procesamiento.
• Disponibilidad. Garantizar que los usuarios autorizados tengan acceso a
la infirmación y alos recursos relacionados con ella, toda vez que se
requiera.
5
1.2 PROBLEMÁTICA Minera San Cristóbal actualmente cuenta con procedimientos vigentes en
administración de proyectos de desarrollo de sistemas de información basados
en seis macro procesos detallados en la siguiente figura:
Figura 1 Macro procesos de gestión de proyectos en MSC (MSC, 2010)
Al aplicar los procedimientos vigentes, se identifican las siguientes
oportunidades:
• La mayoría de los proyectos están retrasados y no hay fechas reales
que indiquen su culminación. Los proyectos están con mucho retraso
frente a las fechas que se los necesita haberlos terminado.
• Los proyectos que están en cola no tienen una fecha estimada de
atención. Actualmente no hay una fecha estimada de inicio de los
proyectos en cola y se necesita saber cuándo se los irá a iniciar para
cumplir con las fechas que se solicita sus respectivos productos.
• Los solicitantes de proyectos no están cómodos con los retrasos. A
causa de este punto, hay pérdida de confiabilidad por parte de los
solicitantes hacia el área de IS&T.
• Los administradores de proyectos toman decisiones respecto al alcance,
tiempo y costo solo a criterio sin usar herramientas que apoyen a la
toma de decisiones. Se toman decisiones demasiado tarde o
equivocadas, que al final no ayudan al correcto desarrollo del proyecto.
• Los administradores de proyectos no tienen una guía de las actividades
mínimas que deben cumplir para poder administrar un proyecto. Es
necesario contar con una guía mínima de administración de proyectos
de tal forma en que se tenga evidencia de la gestión de proyectos
homogénea entre proyectos ejecutados.
• Las desviaciones de lo planificado contra lo ejecutado solo se evidencian
al final del proyecto y es difícil tomar medidas correctivas justo a tiempo
para cumplir con lo planificado.
6
El proyecto final de grado (PFG) se enfoca en presentar una propuesta de
mejora a los procedimientos de administración de proyectos de desarrollo de
sistemas de información que ayude a cubrir las oportunidades mencionadas.
1.3 JUSTIFICACIÓN DEL PROYECTO Los proyectos atendidos entre el año 2010 y 2011 por el departamento de IS&T
fueron aproximadamente en total 51. Dichos proyectos presentan un promedio
de 204 días de retraso frente a la fecha requerida de sus respectivos
productos.
Dada esta diferencia, se considera necesario mejorar los procedimientos de
administración de proyectos de desarrollo de sistemas de información para
cumplir con los requerimientos de los usuarios a tiempo haciendo uso eficiente
de los recursos propios como externos.
1.4 OBJETIVO GENERAL Con base en la problemática expuesta se propone el siguiente objetivo:
Mejorar los procedimientos de Administración de Proyectos de Desarrollo de
Sistemas de Información aplicando actividades y herramientas establecidas por
el PMBOK para contar con una guía de gestión de desarrollo de proyectos de
sistemas de información.
1.5 OBJETIVOS ESPECÍFICOS 1. Identificar los procedimientos vigentes de administración de proyectos
de desarrollo de sistemas de información de MSC.
2. Diagnosticar aspectos de mejora a los procesos identificados enfocados
en actividades de administración de proyectos, herramientas a usar y su
almacenamiento.
3. Mejorar los procedimientos de administración de proyectos de desarrollo
de sistemas de información incluyendo actividades, herramientas e
indicadores con base en el diagnóstico ejecutado.
7
1.6 ENTREGABLES Los entregables del PFG son los siguientes:
1. Información teórica de la investigación. Investigación de fundamentos
teóricos para poder desarrollar el proyecto.
2. Aspectos metodológicos empleados para la consecución de los
objetivos. Establecimiento de la metodología de trabajo con la que se
realiza el desarrollo del proyecto.
3. Procedimientos de sistemas de información identificados.
Procedimientos vigentes con los que MSC está trabajando en
administración de proyectos de desarrollo de sistemas de información.
4. Oportunidades de mejora Identificadas. Oportunidades de mejora
identificadas al los procedimientos vigentes.
5. Procesos propuestos. Propuesta de procedimientos desarrollados con
base en las oportunidades de mejora identificadas.
6. Resultados terminados. Conclusiones y recomendaciones.
La siguiente figura presenta el ciclo de vida del PFG más los entregables que
se deben terminar en cada fase del desarrollo.
Figura 2 Ciclo de vida del proyecto y entregables
8
2 MARCO TEÓRICO
2.1 MARCO REFERENCIAL MSC, está ubicada en la provincia Nor Lípez del departamento de Potosí, a
aproximadamente 500 kilómetros al sur de la ciudad de La Paz y a 90
kilómetros al sudoeste del pueblo de Uyuni.
Figura 3 Ubicación geográfica de Minera San Cristóbal S.A. (Global Infomine, 2010)
2.2 MISIÓN Desarrollar una minería modelo a través de operaciones seguras, de bajo
costo, con tecnología innovadora, con compromiso social y respeto por el
medio ambiente, que crea valor para los accionistas, los empleados, la región
en la que opera el país. (MSC, 2010)
9
2.3 VISIÓN Ser una empresa minera boliviana de clase mundial. (MSC, 2010)
2.4 VALORES Los valores de MSC son (MSC, 2010):
Confianza
Integridad
Trabajo en equipo
Honestidad
Profesionalismo
Mejoramiento continúo
Respeto mútulo
Transparencia
Compromiso con la seguridad, el medio ambiente y la
responsabilidad social.
2.5 POLITICA DE GESTIÓN DE MINERA SAN CRISTOBAL En Minera San Cristóbal S.A. se desarrollan actividades orientadas a la
producción de minerales concentrados de zinc-plata y plomo-plata para su
exportación.
Los principios y valores de MSC son la base de su Sistema de Gestión con un
enfoque en proceso de mejora continua. La satisfacción de sus clientes, la
salud y seguridad de su personal, el cuidado del medio ambiente y la
responsabilidad social forman parte integral de su Sistema de Gestión.
Con el compromiso, los recursos necesarios y la revisión permanente de la
gerencia, en el cumplimiento con las normas internacionales ISO 9001, OHSAS
18001, ISO 14001 y la guía ISO 26000, MSC se compromete a (MSC, 2010a):
1. Promover el establecimiento de objetivos y mecanismos de evaluación
de desempeño en todos sus procesos.
2. Identificar, evaluar y asegurar el control de los riesgos relacionados con
la seguridad del personal, contratistas y visitantes, con la finalidad de
prevenir daños y deterioro de su salud.
3. Respetar el medio ambiente asegurando una gestión ambiental que
identifica, evalúa y maneja los riesgos, previene la contaminación y
10
mitiga impactos negativos, con la finalidad de hacer un uso racional,
eficiente y sostenible de los recursos naturales.
4. Contribuir al desarrollo sostenible implementando principios de
responsabilidad social que aseguren relaciones de mutuo respeto,
transparencia y cumplimiento de compromisos y que generen beneficios
a sus accionistas, sus trabajadores, las comunidades y el país.
5. Proveer productos que cumplan con los requerimientos de sus clientes.
6. Cumplir con los requisitos legales y normativos en todas sus actividades.
7. Asegurar la difusión, comprensión y cumplimiento de esta política por el
personal y hacerla disponible a otras partes interesadas.
MSC reconoce que el éxito de su Sistema de Gestión y de sus operaciones
depende del esfuerzo construido y de la participación de todo el personal y de
sus contratistas (MSC, 2010a).
2.6 NORMA ISO 9000-3
2.6.1 RESEÑA Los estándares ISO 9000 son un grupo de 5 estándares internacionales de
administración y aseguramiento de calidad genéricos, es decir, aplicables a
cualquier producto.
2.6.2 BENEFICIOS Entre los beneficios de la norma ISO 9000-3 podemos destacar los siguientes
(ISO9000-3, 2000):
• Garantiza la calidad del producto.
• Evita costos de inspecciones finales, costos de garantías y reproceso.
• Se reduce el número de auditorías de los clientes a los procesos de
producción.
• Mayor aceptación por parte del cliente y acogida en los mercados tanto
nacionales como internacionales.
11
2.6.3 GENERALIDADES, CAMPO DE APLICACIÓN Y ALCANCE La norma ISO 9000-3 es el estándar utilizado para el desarrollo, suministro y
mantenimiento del software.
Su ámbito de aplicación es (ISO9000-3, 2000):
• Desarrollo de Sistemas de Información
• Procesos del Ciclo de vida
• Calidad de Software
Con la norma se busca dar orientaciones en situaciones en las que se exija la
demostración de la capacidad de un proveedor para desarrollar, suministrar y
mantener productos de software. La norma sugiere clases de control y
métodos para la producción de software que satisfaga los requisitos
establecidos (Behrouz Homayoun Far, 2010).
2.6.4 ANÁLISIS DE LA ISO 9000-3 La ISO9000-3 sirve para interpretar la norma ISO 9001 en el ámbito de la
Ingeniería de Software. De hecho, su nombre es “Guía para la aplicación de
ISO 9001 para el desarrollo, la aplicación y mantenimiento de software.”
La norma ISO 9000-3 es requerida por todas las compañías desarrolladoras de
software para:
• Incursionar en el mercado europeo.
• Cubrir las expectativas de los clientes.
• Obtener beneficios de calidad.
• Como estrategia de mercado.
• Para reducir costos de producción.
2.6.5 BENEFICIOS Entre los beneficios que Behrouz (2010) señala al obtener la certificación de la
Norma ISO9000-3 son:
• Mejor documentación de los sistemas.
• Cambio cultural positivo.
• Incremento en la eficiencia y productividad.
• Mayor percepción de calidad.
• Se amplía la satisfacción del cliente.
• Se reducen las auditorías de calidad.
12
• Agiliza el tiempo de desarrollo de un sistema.
2.6.6 ESTRUCTURA DE LA ISO 9000-3 La estructura de la ISO 9000-3 es (ISO9000-3, 2000):
• Gestión de la responsabilidad.
• Sistemas de calidad.
• Auditorías internas al sistema de la calidad.
• Revisión de contratos.
• Control de documentos y datos.
• Planificación del diseño y el desarrollo.
• Inspección y pruebas.
• Control del producto no conforme.
• Acciones correctivas y preventivas.
• Control de los registros de calidad.
• Capacitación.
• Estadísticas.
2.6.7 DESCRIPCIÓN DE LAS SECCIONES
2.6.7.1 Gestión de la Responsabilidad La dirección de la empresa debe definir y documentar su política y sus
objetivos con respecto a la calidad.
Las responsabilidades, autoridades y relaciones entre todo personal, cuyo
trabajo afecte la calidad del producto, deben ser definidas.
2.6.7.2 Sistemas de Calidad La empresa debe establecer y mantener un sistema de calidad documentado
que debe incluir:
• Instructivos para la preparación de procedimientos del sistema de
calidad.
• Instrucciones para la aplicación efectiva de los procedimientos.
13
2.6.7.3 Auditorías internas al sistema de calidad. La empresa debe llevar un sistema de auditorías internas de calidad y sus
resultados deben ser documentados.
2.6.7.4 Revisión de Contratos La empresa debe establecer y mantener procedimientos para la revisión de los
contratos y para la coordinación de estas actividades. De esta forma asegurar
que la empresa tiene la capacidad de cumplir con todos los requerimientos
contractuales.
2.6.7.5 Control de Documentos y Datos La empresa debe establecer y mantener procedimientos para controlar todos
los documentos y datos.
Todo documento debe estar disponible, y los documentos obsoletos deben ser
removidos.
2.6.7.6 Planificación del diseño y el desarrollo Esta clausula exige la definición de un proceso disciplinado o metodología.
2.6.7.7 Inspección y pruebas La empresa debe asegurar que los productos no se utilicen o procesen hasta
que sean inspeccionados y verificados.
Se deben establecer y mantener registros que contengan el criterio de
aceptación del producto.
Control, Calibración y Mantenimiento de los equipos de inspección, medición y
pruebas utilizados por la empresa.
2.6.7.8 Control del producto no conforme Los productos que no cumplan los requerimientos, especificados no deben ser
instalados, usados o puestos en producción.
2.6.7.9 Acciones correctivas y preventivas La empresa debe establecer, documentar y mantener procedimientos para lo
siguiente:
• Investigar la causa de no conformidad y las acciones correctivas
necesarias para prevenir la recurrencia.
14
• Analizar todos los procesos, operaciones de trabajo, registros de
calidad, reportes de servicios y reclamaciones de clientes para
determinar y eliminar causas potenciales de productos no conformes.
• Iniciar sesiones de prevención para manejar problemas a un nivel
acorde al riesgo encontrado.
• Aplicar controles para asegurar que las acciones correctivas sean
tomadas y que sean efectivas.
• Implantar y registrar los cambios en los procedimientos que sean
resultado de acciones correctivas.
2.6.7.10 Control de los registros de calidad La empresa debe establecer y mantener procedimientos para identificar,
recolectar, indexar, llenar, archivar y desechar los registros de calidad. Todos
los registros deben ser legibles e identificables con el producto del que se trate.
El tiempo que deberán mantenerse esos registros debe ser definido y
registrado.
2.6.7.11 Capacitación La empresa debe establecer y mantener procedimientos para identificar las
necesidades de capacitación y proveer entrenamiento a todo el personal, que
además debe ser calificado con base a su educación, entrenamiento o
experiencia.
2.6.7.12 Estadísticas La empresa debe mantener un registro de estadísticas adecuadas para
verificar el estado del proceso.
2.7 ADMINISTRACIÓN DE PROYECTOS
2.7.1 DEFINICIÓN DE PROYECTO Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un
producto, servicio o resultado único.
Temporal significa que cada proyecto tiene un comienzo definido y un final
definido.
Un proyecto crea productos entregables únicos. Productos entregables son
productos, servicios o resultados.
15
La elaboración gradual es una característica de los proyectos que acompaña a
los conceptos de temporal y único. “Elaboración gradual” significa desarrollar
en pasos e ir aumentando mediante incrementos (PMI, 2008).
2.7.2 PROYECTOS Y TRABAJOS OPERATIVOS El trabajo en las organizaciones generalmente involucra operaciones o
proyectos, aunque los dos se puedan traslapar. Las operaciones y los
proyectos comparten muchas características. Pueden compartir varias de las
siguientes características:
• Realizados por personas.
• Restringidos por la limitación de los recursos.
• Planificados, ejecutados y controlados.
Los proyectos y las operaciones difieren primordialmente en que las
operaciones son continuas y repetitivas, mientras que los proyectos son
temporales y únicos (PMI, 2008).
2.7.3 PROYECTOS Y PLANIFICACIÓN ESTRATÉGICA Los proyectos son una forma de organizar actividades que no pueden ser
tratadas dentro de los límites operativos normales de la organización. Por lo
tanto, los proyectos se usan a menudo como un medio de lograr el plan
estratégico de la organización, ya esté empleado el equipo del proyecto por la
organización o sea un proveedor de servicios contratado.
Figura 4 Contexto de proyectos (PMI, 2008)
16
2.7.4 ADMINISTRACIÓN DE PROYECTOS La gestión de proyectos es la aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades de un proyecto para satisfacer los
requisitos del proyecto. La gestión de proyectos se logra mediante la aplicación
e integración de los procesos de dirección de proyectos (PMI, 2008).
Figura 5 Procesos de dirección de proyectos (PMI, 2008)
El director del proyecto es la persona responsable de alcanzar los objetivos del
proyecto.
La gestión de un proyecto incluye:
• Identificar los requisitos.
• Establecer unos objetivos claros y posibles de realizar.
• Equilibrar las demandas concurrentes de calidad, alcance, tiempo y
costes.
• Adaptar las especificaciones, los planes y el enfoque a las diversas
inquietudes y expectativas de los diferentes interesados.
Los directores del proyecto a menudo hablan de una “triple restricción” —
alcance, tiempos y costos del proyecto — a la hora de gestionar los requisitos
concurrentes de un proyecto. La calidad del proyecto se ve afectada por el
equilibrio de estos tres factores. Los proyectos de alta calidad entregan el
producto, servicio o resultado requerido con el alcance solicitado, puntualmente
y dentro del presupuesto. La relación entre estos tres factores es tal que si
cambia cualquiera de ellos, se ve afectado por lo menos otro de los factores.
Los directores de proyectos también gestionan los proyectos en respuesta a la
incertidumbre. El riesgo de un proyecto es un evento o condición inciertos que,
si ocurre, tiene un efecto positivo o negativo al menos en uno de los objetivos
de dicho proyecto.
Es importante destacar que muchos de los procesos incluidos en la dirección
de proyectos son repetitivos debido a la existencia o a la necesidad de elaborar
gradualmente el proyecto durante el ciclo de vida del proyecto. Esto significa
17
que, a medida que un equipo de dirección del proyecto conoce más en
profundidad un proyecto, el equipo puede luego dirigirlo con un mayor nivel de
detalle (PMI, 2008).
2.7.5 CICLO DE VIDA DEL PROYECTO Y LA ORGANIZACIÓN Porque los proyectos son tareas únicas, involucran cierto nivel de
incertidumbre. Las organizaciones ejecutoras de proyectos generalmente
dividen los proyectos en fases. El conjunto de estas fases se conoce como el
ciclo de vida del proyecto. Muchas organizaciones identifican un conjunto de
ciclos de vida específicos para usarlos en todos sus proyectos (PMI, 2008).
El ciclo de vida del proyecto generalmente define:
• El trabajo técnico que se debe realizar en cada fase.
• Cuándo se deben generar los productos entregables de cada fase y
cómo se revisa, verifica y valida cada producto entregable.
• Quién está involucrado en cada fase (por ejemplo, la ingeniería
concurrente requiere que los implementadores estén involucrados en las
fases de requisitos de diseño).
• Cómo controlar y aprobar cada fase.
2.7.6 RELACIONES DEL CICLO DE VIDA DEL PROYECTO Y DEL PRODUCTO Debe tenerse cuidado en distinguir entre el ciclo de vida del proyecto y el ciclo
de vida del producto. El ciclo de vida del proyecto atraviesa una serie de fases
para crear el producto. Proyectos adicionales pueden incluir una actualización
del rendimiento del producto. En algunas áreas de aplicación, tales como el
desarrollo de nuevos productos o el desarrollo de software, las organizaciones
consideran el ciclo de vida del proyecto como parte del ciclo de vida del
producto (PMI, 2008).
2.7.7 ESTRUCTURA DE LAS ORGANIZACIONES La estructura de la organización ejecutante del proyecto con frecuencia
restringe la disponibilidad de recursos, abarcando un espectro desde funcional
a orientado a proyectos, con diversas estructuras matriciales en el medio. La
siguiente tabla muestra las características clave relacionadas con los proyectos
de los principales tipos de estructura de la organización (PMI, 2008).
18
Cuadro 1 Influencia de la estructura de la organización en los proyectos (PMI, 2008)
CARÁCTERÍSTICAS DEL PROYECTO/
ESTRUCTURA DE LA ORGANIZACIÓN
FUNCIONAL MATRICIAL
ORIENTADA A PROYECTOS MATRICIAL
DEBIL MATRICIAL
EQUILIBRADA MATRICIAL
FUERTE
AUTORIDAD DEL DIRECTOR DEL PROYECTO
Poca o ninguna Limitada Baja o moderada Moderada a
alta Alta a casi total
DISPONIBILIDAD DE RECURSOS
Poca o ninguna Limitada Baja o moderada Moderada a
alta Alta a casi total
QUIÉN CONTROLA EL PRESUPUESTO DEL PROYECTO
Gerente funcional
Gerente funcional Combinación Director del
proyecto Director del
proyecto
ROL DEL DIRECTOR DEL PROYECTO
Dedicación parcial
Dedicación parcial
Dedicación completa
Dedicación completa
Dedicación completa
PERSONAL ADMINISTRATIVO DE LA DIRECCIÓN DE PROYECTOS
Dedicación parcial
Dedicación parcial
Dedicación parcial
Dedicación completa
Dedicación completa
2.7.8 SISTEMA DE GESTIÓN DE PROYECTOS El sistema de gestión de proyectos es el conjunto de herramientas, técnicas,
metodologías, recursos y procedimientos utilizados para gestionar un proyecto.
Puede ser formal o informal, y ayuda al director del proyecto a gestionar de
forma eficaz un proyecto hasta su conclusión. El sistema es un conjunto de
procesos y de las funciones de control correspondientes, que se consolidan y
combinan en un todo funcional y unificado.
El plan de gestión del proyecto describe cómo se va a usar el sistema de
gestión de proyectos. El contenido del sistema de gestión de proyectos variará
dependiendo del área de aplicación, influencia de la organización, complejidad
del proyecto y disponibilidad de los sistemas existentes. Las influencias de la
organización conforman el sistema para ejecutar los proyectos dentro de esa
organización. El sistema se ajustará o adaptará a cualquier exigencia impuesta
por la organización (PMI, 2008).
2.7.9 PROCESOS DE DIRECCIÓN DE PROYECTOS La dirección de proyectos es la aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades del proyecto para satisfacer los
requisitos del mismo. La dirección de proyectos se logra mediante la ejecución
de procesos, usando conocimientos, habilidades, herramientas y técnicas de
dirección de proyectos que reciben entradas y generan salidas (PMI, 2008).
Para que un proyecto tenga éxito, el equipo del proyecto debe:
• Seleccionar los procesos apropiados dentro de los Grupos de Procesos
de la Dirección de Proyectos (también conocidos como Grupos de
19
Procesos) que sean necesarios para cumplir con los objetivos del
proyecto.
• Usar un enfoque definido para adaptar las especificaciones del producto
y los planes de tal forma que se puedan cumplir los requisitos del
proyecto y del producto.
• Cumplir con los requisitos para satisfacer las necesidades, deseos y
expectativas de los interesados.
• Equilibrar las demandas concurrentes de alcance, tiempo, costes,
calidad, recursos y riesgos para producir un producto de calidad.
Un proceso es un conjunto de acciones y actividades interrelacionadas que se
llevan a cabo para alcanzar un conjunto previamente especificado de
productos, resultados o servicios. El equipo del proyecto es quien está a cargo
de ejecutar los procesos de dirección de proyectos, que por lo general
pertenecen a una de estas dos categorías principales:
• Los procesos de la dirección de proyectos comunes a la mayoría de los
proyectos por lo general están relacionados entre sí por el hecho de que
se llevan a cabo para un propósito integrado. El propósito es iniciar,
planificar, ejecutar, supervisar y controlar, y cerrar un proyecto. Estos
procesos interactúan entre sí de formas complejas que no pueden
explicarse completamente en un documento o con gráficos. Los
procesos también pueden interactuar en relación con el alcance, el
coste, el cronograma del proyecto, etc., que se denominan Áreas de
Conocimiento.
• Los procesos orientados al producto especifican y crean el producto del
proyecto. Los procesos orientados al producto se definen normalmente
por el ciclo de vida del proyecto y varían según el área de aplicación.
Los procesos de la dirección de proyectos y los procesos orientados al
producto se superponen e interactúan durante el proyecto. Por ejemplo,
no se puede definir el alcance del proyecto si no se tiene una
comprensión básica acerca de cómo crear el producto especificado.
Los procesos de dirección de proyectos se dividen en cinco grupos, definidos
como los Grupos de procesos de la Dirección de Proyectos:
20
Grupo de Procesos de Iniciación. Define y autoriza el proyecto o una fase del
mismo.
Grupo de Procesos de Planificación. Define y refina los objetivos, y planifica
el curso de acción requerido para lograr los objetivos y el alcance pretendido
del proyecto.
Grupo de Procesos de Ejecución. Integra a personas y otros recursos para
llevar a cabo el plan de gestión del proyecto para el proyecto.
Grupo de Procesos de Seguimiento y Control. Mide y supervisa
regularmente el avance, a fin de identificar las variaciones respecto del plan de
gestión del proyecto, de tal forma que se tomen medidas correctivas cuando
sea necesario para cumplir con los objetivos del proyecto.
Grupo de Procesos de Cierre. Formaliza la aceptación del producto, servicio
o resultado, y termina ordenadamente el proyecto o una fase del mismo.
2.7.10 AREAS DE CONOCIMIENTO DE LA ADMINISTRACIÓN DE PROYECTOS Las Áreas de Conocimiento de la Administración de Proyecto describen el
conocimiento y las prácticas de la administración de proyectos en términos de
sus componentes de proceso. Estos procesos han sido organizados en nueve
áreas de conocimiento:
1. Administración de la Integración de Proyectos, describe los procesos
requeridos para asegurar que los elementos varios de un proyecto están
coordinados apropiadamente. Consiste del desarrollo de un plan de
proyecto, ejecución del plan de proyecto, y el control de cambios en
general.
2. Administración del Alcance del Proyecto, describe el proceso requerido
para asegurar que el proyecto incluye todo trabajo requerido, y sólo el
trabajo requerido, para completar el proyecto de manera exitosa.
Consiste de la iniciación, planeación del alcance, definición del alcance,
verificación del alcance, y control de cambio al alcance.
3. Administración del Tiempo del Proyecto, describe los procesos
requeridos para asegurar la terminación a tiempo del proyecto. Consiste
en la definición de las actividades, secuencia de las actividades,
21
estimación de duración de las actividades, desarrollo del cronograma y
control de la programación.
4. Administración de los Costos del Proyecto, describe los procesos
requeridos para asegurar que el proyecto es completado dentro del
presupuesto aprobado. Consiste en la planificación de recursos,
estimación de costos, presupuesto de costos, y control de costos.
5. Administración de la Calidad del Proyecto, describe los procesos
requeridos para asegurar que el proyecto satisfaga las necesidades para
lo cual fue desarrollado. Consiste en la planeación de la calidad,
aseguramiento de la calidad, y control de calidad.
6. Administración de los Recursos Humanos del Proyecto, describe los
procesos requeridos para hacer el uso más eficiente de las personas
involucradas en el proyecto. Consiste en la planeación organizacional,
adquisición de staff, y desarrollo del equipo.
7. Administración de las Comunicaciones del Proyecto, describe los
procesos requeridos para asegurar la generación apropiada y a tiempo,
colección, diseminación, almacenamiento, y la disposición final de la
información del proyecto. Consiste en la planeación de la comunicación,
distribución de la información, reportes de desempeño, y el cierre
administrativo.
8. Administración de Riesgo del Proyecto, describe los procesos
concernientes con la identificación, análisis, y respuesta al riesgo del
proyecto. Consiste en la identificación del riesgo, cuantificación del
riesgo, desarrollo de la respuesta al riesgo, y en el control de la
respuesta al riesgo.
9. Administración del abastecimiento del Proyecto, describe los procesos
requeridos para adquirir bienes y servicios de fuera de la organización
ejecutora. Consiste en la planeación de la gestión de la procuración,
planear la solicitación, la solicitación, selección de proveedores,
administración de contratos, y cierre de contratos.
22
Cuadro 2 Tabla de administración (PMI, 2008)
Áreas de Conocimiento
Grupos de procesos de gestión de proyectos Grupos de
procesos de iniciación
Grupo de procesos de planificación
Grupo de procesos de ejecución
Grupo de procesos de seguimiento y
control
Grupo de procesos de cierre
Gestión de la integración del proyecto
Desarrollar el acta de constitución del proyecto. Desarrollar el enunciado del alcance del proyecto.
Desarrollar el plan de gestión del proyecto.
Dirigir y gestionar la ejecución del proyecto
Supervisar y controlar el trabajo del proyecto. Control integrado de cambios.
Cerrar proyecto.
Gestión del alcance del proyecto
Planificación del alcance Definición del alcance Crear EDT
Verificación del alcance. Control del alcance.
Gestión del tiempo del proyecto
Definición de las actividades. Establecimiento de la secuencia de las actividades. Estimación de recursos de las actividades. Estimación de la duración de las actividades. Desarrollo del cronograma.
Control del cronograma.
Gestión de los costos del proyecto.
Estimación de costes. Preparación del presupuesto de costos.
Control de costos.
Gestión de la calidad del proyecto.
Planificación de la calidad.
Realizar aseguramiento de la calidad.
Realizar control de calidad.
Gestión de los recursos humanos del proyecto.
Planificación de los recursos humanos.
Adquirir el equipo del proyecto. Desarrollar el equipo del proyecto.
Gestionar el equipo del proyecto.
Gestión de las comunicaciones del proyecto.
Planificación de las comunicaciones.
Distribución de la información.
Informar el rendimiento. Gestionar a los interesados.
Gestión de los riesgos del proyecto.
Planificación de la gestión de riesgos. Identificación de riesgos. Análisis cualitativo de riesgos. Análisis cuantitativo de riesgos. Planificación de la respuesta a los riesgos.
Seguimiento y control de riesgos.
Gestión de las adquisiciones del proyecto.
Planificar las compras y adquisiciones. Planificar la contratación.
Solicitar respuesta de vendedores. Selección de vendedores.
Administración del contrato.
Cierre del contrato.
23
2.8 LENGUAJE UNIFICADO DE MODELADO UML El Lenguaje Unificado de Modelado (UML) es un estándar que define reglas y
notaciones para especificar sistemas de negocios y software. La notación
provee una rica gama de elementos gráficos para modelar sistemas orientados
a objetos, y las reglas establecen como los elementos pueden estar
conectados y usados. UML es un lenguaje visual para comunicar, modelar,
especificar y definir sistemas (Pender, 2003).
UML describe la notación para clases, componentes, nodos, actividades, flujos
de trabajo, casos de uso, objetos, estados y cómo modelar la relación entre
esos elementos. UML también soporta extensiones personalizadas a través
elementos estereotipados (Pender, 2003).
UML es simplemente un lenguaje designado para ser flexible, extensible y
comprensivo, siento tan genérico que puede ser usado para modelar cualquier
sistema (Pender, 2003).
2.8.1 DIAGRAMAS UML Los diagramas UML son una representación de los componentes o elementos
de un sistema o proceso, y dependiendo del tipo de diagrama, cómo esos
elementos están relacionados o interactúan desde una perspectiva particular
(Pender, 2003).
Hay dos grupos de diagramas UML:
Diagramas estructurales. Representan las características estáticas de un
sistema. Las características incluyen clases y asociaciones, objetos y
colaboraciones (Pender, 2003).
Diagramas de comportamiento. Representan vistas dinámicas del sistema,
mostrando las características de comportamientos del sistema o proceso de
negocio (Pender, 2003).
Entre los diagramas estructurales se encuentran (Pender, 2003):
Diagrama de Clases. Capturan la estructura lógica de un sistema, las clases y objetos que
conforman el sistema, describiendo lo que existe, los atributos y el
comportamiento que tiene.
24
Diagrama de Estructura Compuesta. Reflejan la colaboración de las clases, interfaces y componentes para describir
su funcionalidad.
Diagrama de Componentes. Ilustran las partes de un sistema y su organización y dependencias.
Diagrama de Despliegue. Muestran cómo y dónde el sistema es desplegado. Es decir, la arquitectura de
ejecución.
Diagrama de Objetos. Muestra instancias de clases y sus relaciones en un punto determinado de
tiempo.
Diagrama de Paquete. Muestra la organización de elementos de un sistema en paquetes y sus
dependencias.
- Entre los diagramas de comportamiento se encuentran (Pender, 2003):
Diagrama de Actividades. Modela el comportamiento de un sistema y la forma en que este
comportamiento está relacionado como un flujo integral de un todo.
Diagrama de Caso de Uso. Captura Casos de Uso y relaciones entre los actores y el sistema. Describen
los requerimientos funcionales del sistema, la manera en la cual los operadores
interactúan con el sistema y la respuesta del sistema.
Diagrama de Estado. Ilustra como un elemento puede moverse de un estado a otro, clasificando su
comportamiento de acuerdo a gatilladores de comportamiento.
Diagramas de Tiempos. Define el comportamiento de diferentes objetos dentro una escala de tiempo
proveyendo una representación visual de los cambios de estados de los
objetos y sus interacciones a lo largo del tiempo.
Diagramas de Secuencia. Muestra la interacción de un conjunto de objetos en una aplicación a través del
tiempo y se modela para cada caso de uso.
25
Diagrama de Comunicaciones. Muestra las interacciones entre elementos en tiempo real, visualizando
relaciones entre objetos.
Diagrama de Interacción. Visualizan la cooperación entre otros diagramas para ilustrar el flujo de control
para mostrar un propósito.
2.8.2 MODELANDO PROCEDIMIENTOS DE NEGOCIO CON UML Un modelo es una abstracción de la realidad. Un modelo permite eliminar los
detalles irrelevantes y enfoque en uno o más aspectos. Los modelos efectivos
facilitan las discusiones entre los interesados en el negocio, permitiéndoles
trabajar por objetivos. Modelando procedimientos de negocio con UML ha sido
aceptado y establecido como una forma de analizar y diseñar sistemas para su
entendimiento y para su mejora (Geoffrey Sparks, 2011).
Un modelo de negocio, permite capturar los eventos, las entradas, los recursos
y las salidas más importantes vinculadas con el procedimiento de negocio. Es
posible construir un modelo completamente trazable mediante la posterior
conexión de elementos de diseño al modelo de negocio a través de conectores
de implementación, desde la generalidad del proceso de negocio a los
requisitos (Geoffrey Sparks, 2011).
Un modelo de procedimiento de negocio típicamente define los siguientes
elementos:
• El objetivo o el motivo del proceso.
• Las entradas específicas.
• Las salidas específicas.
• Los recursos consumidos.
• La secuencia de las actividades.
• Los eventos que dirigen el proceso.
2.8.3 MODELANDO PROCEDIMIENTOS DE NEGOCIO MEDIANTE DIAGRAMAS DE ACTIVIDAD Un diagrama de actividad se usa para mostrar la secuencia de actividades. Los
diagramas de actividades muestran el flujo de trabajo desde el punto de inicio
hasta el punto final detallando muchas de las rutas de decisiones que existen
26
en el progreso de eventos contenidos en la actividad. Estos también pueden
usarse para detallar situaciones donde un procedimiento paralelo puede ocurrir
en la ejecución de algunas actividades. Los Diagramas de Actividades son
útiles para el Modelado de Negocios donde se usan para detallar el proceso
involucrado en las actividades de negocio (Sparx, 2011).
Un ejemplo de un diagrama de actividades se muestra a continuación:
Figura 6 Ejemplo diagrama de actividades (Sparx, 2011)
Las partes que conforman un diagrama de actividades son las siguientes:
Actividades. Una actividad es la especificación de una secuencia parametrizada de
comportamiento. Una actividad muestra un rectángulo con las puntas
redondeadas adjuntando todas las acciones, flujos de control y otros elementos
que constituyen la actividad.
Figura 7 Representación de una actividad (Sparx, 2011)
27
Nodos de Decisión y Combinación. Los nodos de decisión y combinación tienen la misma notación: una forma de
diamante. Los dos se pueden nombrar. Los flujos de control que provienen de
un nodo de decisión tendrán condiciones de guarda que permitirán el control
para fluir si la condición de guarda se realiza. El siguiente diagrama muestra el
uso de un nodo de decisión y un nodo de combinación.
Figura 8 Representación de nodos de decisión y combinación (Sparx, 2011)
Nodos de Bifurcación y Unión. Las bifurcaciones y uniones tienen la misma notación: tanto una barra
horizontal como vertical (la orientación depende de si el flujo de control va de
derecha a izquierda o hacia abajo y arriba. Estos indican el comienzo y final de
hilos actuales de control. El siguiente diagrama muestra un ejemplo de su uso.
Figura 9 Representación de nodos de bifurcación y unión (Sparx, 2011)
Flujos de Objetos. Un flujo de objeto es la ruta a lo largo de la cual pueden pasar objetos o datos.
Un objeto se muestra cómo un rectángulo.
Figura 10 Representación de un objeto (Sparx, 2011)
28
Nodo Inicial. Un nodo inicial o de comienzo se describe por un gran punto negro, como se
muestra a continuación.
Figura 11 Representación de un nodo inicial (Sparx, 2011)
Nodo Final. Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo
final de actividad se describe como un círculo con un punto dentro del mismo.
Figura 12 Representación de un nodo final (Sparx, 2011)
29
3 MARCO METODOLÓGICO Dentro de esta sección se identifica y se detalla las fuentes de información
clasificadas como primarias y secundarias, además se describe el tipo de
método a utilizar para la investigación conjuntamente con las herramientas a
utilizar para generar los entregables del trabajo.
3.1 FUENTES DE INFORMACIÓN Para obtener evidencia directa de los procesos de desarrollo de sistemas de
información y detección de oportunidades de mejora, se tomaron datos de
primera mano de las siguientes fuentes:
• El patrocinador
• El director de proyecto
• Los clientes
• Los usuarios
• Procedimientos e instructivos vigentes en MSC.
• Evidencia disponible de la ejecución de los proyectos.
Como referencia del proceso evolutivo de los procedimientos y prácticas
ejecutadas en el desarrollo de sistemas de información se tomaron como
fuentes de información secundaria a:
• Versiones antiguas de procedimientos e instructivos.
Como fundamento teórico se tomaron a las siguientes fuentes documentales:
• Documentos de administración de proyectos. Comprende libros,
publicaciones en internet que ayuden al desarrollo del proyecto. La
información recolectada de estos medios fueron los insumos necesarios
para poder establecer los procedimientos correspondientes,
estableciendo así el proceso a seguir para maximizar el recurso.
De acuerdo con las fuentes de información identificadas, se estableció que el
tipo de investigación es mixta. El proyecto está basado en la guía de los
fundamentos de la administración de proyectos PMI (2008), en la búsqueda de
técnicas, herramientas y soluciones, que permitan al equipo de proyecto
trabajar con una metodología de administración de proyectos, logrando de esta
forma la obtención de la mayor cantidad de información por parte de los
involucrados y a la vez contar con una mejora al proceso actual de sistemas de
información.
30
3.2 MÉTODOS DE INVESTIGACIÓN Las condiciones del proyecto hacen que el método más adecuado para la
investigación sea el Objetivo-Subjetivo. Este es el procedimiento de
investigación que se basa en lo real para lo Objetivo (observación de hechos y
fenómenos reales) y en lo supuesto e intangible para lo subjetivo (estudio de
hechos y fenómenos mediante observaciones personales (Muñoz Razo, 1998).
3.2.1 DESCRIPCIÓN DE LAS HERRAMIENTAS
3.2.1.1 Entrevistas Formales De acuerdo al método de Objetivo Subjetivo (Muñoz Razo, 1998), se aplica
entrevistas formales a personas claves del proceso tales como el administrador
de proyectos, el patrocinador, los usuarios y los clientes. La información
recolectada es la base para el análisis del proceso.
3.2.1.2 Juicios de Expertos. Es una consulta que se realiza a ciertas personas con un alto grado de
conocimiento sobre el tema de desarrollo de negocios. Las consultas se
ejecutan en forma verbal a manera de recomendación o sugerencia y fortalecer
la información recolectada en las entrevistas, que pueden servir para la
evaluación de dudas o búsqueda de soluciones a oportunidades de mejora que
puedan surgir, reforzando así toda la información recolectada en las
entrevistas.
3.2.1.3 Estructura de Desglose de Trabajo (EDT) Es una herramienta gráfica que estructura cómo se debe realizar el proyecto
iniciando con el entregable principal, el cual se desglosa en sub entregables, y
estos en tareas. (PMI,2008)
El nivel de desglose de la herramienta dependerá de cuanto quiera el equipo
controlar su gestión. Además permite establecer una línea base del
cronograma del proyecto.
3.2.1.4 Cronograma de trabajo Es la herramienta que describe cada una de las tareas que se van a realizar
dentro el proyecto, donde se muestra la duración, el tiempo para realizar cada
una y terminarlas con éxito, la relación entre estas, y por lo tanto el avance o
31
retraso que puedan surgir en las diferentes tareas. También, muestra los
recursos, al igual que establece la ruta crítica del proyecto.
3.2.1.5 Diagrama de espina de pescado Herramienta que permite apreciar con claridad las relaciones entre un tema o
problema y las posibles causas que pueden estar contribuyendo para que él
ocurra.
3.2.1.6 Diagrama de actividades Herramienta que se usa para modelar negocios. Se muestra la secuencia de
actividades de los procesos desde el punto de inicio hasta el punto final,
detallando muchas de las rutas de decisiones que existen en el progreso de
eventos contenidos en la actividad.
3.2.1.7 Software Dentro del software por usar se destaca:
• WBS Chart Pro. Herramienta de apoyo para crear una EDT.
• Microsoft Project. Aplicación de Microsoft que ayuda al usuario
gestionar proyectos.
• Enterprise Architect. Herramienta utilizada para modelar procesos.
32
4 DESARROLLO Se identifica el proceso actual más los formularios, herramientas e indicadores
que lo conforman. Con base en el proceso actual identificado, se analizan las
oportunidades de mejora y se desarrolla un nuevo procedimiento incluyendo las
oportunidades de mejora. Se presentan diagramas de todo el trabajo realizado.
4.1 SOLICITUD A IS&T Todo el proceso se inicia cuándo el área de IS&T recibe una solicitud mediante
el sistema Track IT. La solicitud contiene información inicial como ser el
solicitante, el aprobador en caso de ser necesario y una descripción de la
necesidad. El objetivo principal de la solicitud es asegurar que cada solicitud
tenga claramente identificados su origen, el problema que se intenta resolver y
la ruta a tomarse para su resolución.
La solicitud es llenada por el área responsable o usuario autorizado por medio
de un correo o un formulario diseñado en Outlook.
La siguiente figura muestra la relación de los procesos identificados.
Figura 13 Procedimientos identificados en el área de IS&T
33
4.2 ESTRUCTURA ORGANIZACIONAL El área de IS&T se divide en tres ramas, una de administración de redes y
servidores, otra de seguridad de información y una de Sistemas de Información
que se encarga del desarrollo de soluciones de software y soporte de tercer
nivel. Está última división está estructurada matricialmente donde se cuenta
con un supervisor, dos administradores de proyectos y los analistas a los
cuales se los asigna a los proyectos según la decisión del supervisor y la
planificación de los administradores.
Figura 14 Estructura organizacional de MSC
Gerente Comercial
Superintendente Desarrollo de Negocios
Superintendente IS&T
Superintendente Comercial
Supervisor Sistemas de Información
Supervisor de Seguridad
Supervisor de Redes y Servidores
Administrador de Proyectos 1
Administrador de Proyectos 2
Analistas
34
4.3 IDENTIFICACIÓN DEL PROCESO ACTUAL En esta sección se identifican los procesos vigentes, las actividades que los
comprenden más las herramientas usadas, los roles y responsables de cada
actividad.
Los procesos identificados en el área de IS&T de MSC son los siguientes:
1. Análisis de Necesidades
2. Planificación de Proyecto
3. Diseño
4. Desarrollo
5. Validación
6. Verificación prueba
La siguiente figura muestra la secuencia de los procesos identificados
gráficamente:
Figura 15 Secuencia de Procesos Identificados
4.3.1 ANÁLISIS DE NECESIDADES Este procedimiento tiene el objetivo de definir los pasos a seguir para lograr
un correcto análisis de necesidades de un requerimiento solicitado a IS&T. El
proceso contiene el registro de un requerimiento como proyecto, la
identificación de los requerimientos y una propuesta de solución. La siguiente
figura muestra el proceso identificado.
35
Figura 16 Análisis de necesidades
36
4.3.1.1 Formularios Identificados Los formularios identificados son los siguientes:
• Identificación de los requerimientos. El formulario contiene:
La descripción del procedimiento actual.
El Modelo Conceptual.
Los requerimientos funcionales.
Descripción de la solución planteada.
4.3.1.2 Herramientas Tecnológicas Las herramientas tecnológicas usadas son:
• Track IT. Sirve como fuente inicial para identificar el solicitante más la
descripción inicial del problema hecha por el solicitante.
• Share Point. Se crea una carpeta para guardar toda la documentación
generada.
• Matriz de prioridades. Es un formulario Excel el cual contiene una lista
de proyectos identificados más sus prioridades de atención.
4.3.1.3 Métricas Identificadas
• No existen métricas identificadas.
37
4.3.2 PLANIFICACIÓN DE PROYECTO El objetivo de este procedimiento es definir los pasos a seguir dentro de IS&T
para realizar una correcta planificación de proyectos. El procedimiento
contiene el registro de las tareas, los responsables de realizarlas, la definición
de tiempos y la identificación de riesgos. La siguiente figura muestra el
proceso identificado.
Figura 17 Planificación del proyecto
38
4.3.2.1 Formularios Identificados Los formularios identificados son los siguientes:
• Análisis de riesgos. El formulario contiene:
Una tabla de criterios y análisis.
Una matriz de riesgos con la identificación del riesgo, la
posibilidad de ocurrencia y el impacto de ocurrencia.
4.3.2.2 Herramientas Tecnológicas Las herramientas tecnológicas usadas son:
• Jira. Se definen las tareas más los responsables de realizar la tarea.
4.3.2.3 Métricas Identificadas
• No existen métricas identificadas.
39
4.3.3 DISEÑO El objetivo de este proceso es definir los pasos a seguir dentro de IS&T para
realizar un correcto diseño de la solución a desarrollar o implementar. El
proceso consiste en desarrollar los modelos Físico, Lógico y Componentes de
tal forma que representen la solución a desarrollar. También se desarrollan los
casos de uso donde se detectan los actores y la forma en que se usará el
sistema. En algunos casos puede ser necesario crear un prototipo de la
solución. La siguiente figura muestra el proceso identificado:
Figura 18 Diseño de la solución
40
4.3.3.1 Formularios Identificados Los formularios identificados son los siguientes:
• Análisis Y Diseño. El formulario contiene:
Modelos.
Casos de uso.
Prototipos.
4.3.3.2 Herramientas Tecnológicas Las herramientas tecnológicas usadas son:
• Enterprise Architect. La herramienta ayuda a elaborar los modelos y
genera documentación.
4.3.3.3 Métricas Identificadas
• No existen métricas identificadas.
41
4.3.4 DESARROLLO DEL SISTEMA El objetivo de este procedimiento es definir los pasos a seguir dentro de IS&T
para realizar un correcto desarrollo de la solución. El procedimiento consiste
en desarrollar la solución y elaborar los manuales. La siguiente figura muestra
el procedimiento identificado:
Figura 19 Desarrollo de la solución
4.3.4.1 Formularios Identificados No existen formularios identificados.
4.3.4.2 Herramientas Tecnológicas No están identificadas las herramientas tecnológicas de apoyo al
procedimiento.
4.3.4.3 Métricas Identificadas
• No existen métricas identificadas.
42
4.3.5 VALIDACIÓN El objetivo de este procedimiento es definir los pasos a seguir dentro de IS&T
para realizar un correcto plan de pruebas y ejecución de las mismas. El
procedimiento consiste en identificar un ambiente de pruebas donde se
ejecutará la guía de pruebas diseñada. Incluye la elaboración de la guía de
pruebas. La siguiente figura muestra el procedimiento identificado.
Figura 20 Pruebas de la solución desarrollada
4.3.5.1 Formularios Identificados Los formularios identificados son los siguientes:
• Pruebas de Usuario. El formulario contiene:
Identificación de casos de uso. Un caso de uso tiene un estado, las
entradas, criterio de aceptación y los resultados.
4.3.5.2 Herramientas Tecnológicas No están identificadas las herramientas tecnológicas de apoyo al
procedimiento.
4.3.5.3 Métricas Identificadas
• No existen métricas identificadas.
43
4.3.6 VERIFICACIÓN PRUEBA El objetivo de este procedimiento es definir los pasos a seguir dentro de IS&T
para realizar una correcta validación y pase a producción de las aplicaciones
desarrolladas o implementadas. El procedimiento consiste en difundir el
resultado final a todos los interesados y realizar el formulario de pase a
producción.
Figura 21 Validación
4.3.6.1 Formularios Identificados Los formularios identificados son los siguientes:
• Pase a Producción. El formulario contiene:
Actividades de pase a producción. Son todas las tareas a realizar para
dejar el sistema operativo dentro de la plataforma de producción.
4.3.6.2 Herramientas Tecnológicas No están identificadas las herramientas tecnológicas de apoyo al proceso.
4.3.6.3 Métricas Identificadas No existen métricas identificadas.
44
4.4 HISTORIAL DE PROYECTOS EN MSC La distribución de número de proyectos del área de IS&T del año 2010 fue de
la siguiente manera: Cuadro 3 Distribución de proyectos IS&T (MSC, 2010)
TIPO PROYECTOS DISTRIBUCIÓN DE
PROYECTOS IS&T (%) Tecnología 20 Redes 10 Desarrollo Sistemas de Información 40 Adquisición de Sistemas de Información 30
Con base en el cuadro anterior se muestra la distribución de forma gráfica:
Figura 22 Distribución de proyectos IS&T
Los proyectos realizados entre el año 2010 y 2011 son un total de 51. Dichos
proyectos tienen una desviación promedio de 204 días frente a las fechas que
se solicitaban sus respectivos productos. La siguiente tabla muestra el detalle
de los proyectos implementados destacando la fecha de en que se terminó el
proyecto (fecha de producción), la fecha en que se necesitaba el producto
(Fecha requerido) y la desviación entre ambas fechas.
Tecnología20%
Redes10%
Desarrollo Sistemas de Información
40%
Adquisición de Sistemas de Información
30%
DISTRIBUCIÓN DE PROYECTOS IS&T
45
Cuadro 4 Proyectos ejecutados en MSC (MSC, 2010)
Tipo Gerencia Fecha Avance Mes Previsto
de Entrega Año
Fecha Producción
Mes de Entrega Fecha Inicio Mes Requerido Fecha Requerido
Fecha producción -
Fecha Requerido
Implementación Mina 3/31/2010 100.00% Marzo 2010 3/31/2010 201003 200911 11/12/2009 139
Implementación Finanzas 3/31/2010 100.00% Marzo 2010 6/30/2010 201006 200910 10/15/2009 258
Desarrollo QHS 3/31/2010 100.00% Marzo 2010 3/31/2010 201003 201001 1/28/2010 62
Implementación Mantenimiento 9/26/2010 90.00% Septiembre 2010 9/25/2010 201009 7/10/2010 201007 7/10/2010 77
Implementación Comercial 3/31/2010 100.00% Marzo 2010 3/31/2010 201003 200907 7/16/2009 258
Desarrollo Finanzas 5/17/2010 100.00% Mayo 2010 5/31/2010 201005 200911 11/1/2009 211
Implementación Comercial 8/31/2010 95.00% Agosto 2010 9/27/2010 201009 200808 8/15/2008 773
Implementación RRHH 12/31/2010 100.00% Diciembre 2010 12/31/2010 201012 4/1/2008 200804 4/1/2008 1004
Implementación QHS 3/31/2010 100.00% Marzo 2010 3/31/2010 201003 200904 4/17/2009 348
Implementación Mantenimiento 3/31/2011 100.00% Marzo 2011 3/31/2011 201103 3/3/2010 201003 3/3/2010 393
Desarrollo QHS 5/31/2011 100.00% Mayo 2011 5/31/2011 201105 8/7/2010 200907 7/29/2009 671
Desarrollo IS&T 80.00% TBD NA 2/23/2011 201102 5/1/2009 200905 5/1/2009 663
Desarrollo Mantenimiento 4/30/2010 100.00% Abril 2010 4/24/2010 201004 200904 4/24/2009 365
Desarrollo Supply Chain 3/31/2010 100.00% Marzo 2010 3/31/2010 201003 3/10/2010 201001 1/8/2010 82
Implementación Comercial 10/12/2010 100.00% Octubre 2010 10/12/2010 201010 9/29/2010 200901 1/11/2009 639
Desarrollo Comercial 1/31/2011 100.00% Enero 2011 1/31/2011 201101 8/9/2010 201006 6/25/2010 220
Desarrollo Mina 3/31/2010 100.00% Marzo 2010 3/31/2010 201003 2/20/2010 200910 10/21/2009 161
Implementación Supply Chain 4/30/2010 100.00% Abril 2010 4/24/2010 201004 200904 4/24/2009 365
Desarrollo DSRC 4/30/2010 Abril 2010 5/31/2010 201005 4/15/2010 200911 11/15/2009 197
Desarrollo Supply Chain 7/31/2010 100.00% Julio 2010 7/31/2010 201007 200911 11/28/2009 245
Desarrollo RRHH 7/29/2010 100.00% Julio 2010 7/29/2010 201007 200912 12/15/2009 226
46
Tipo Gerencia Fecha Avance Mes Previsto
de Entrega Año
Fecha Producción
Mes de Entrega Fecha Inicio Mes Requerido Fecha Requerido
Fecha producción -
Fecha Requerido
Implementación Finanzas 12/31/2010 100.00% Diciembre 2010 12/31/2010 201012 3/8/2010 201003 3/14/2010 292
Implementación Comercial 10/31/2010 100.00% Octubre 2010 11/30/2010 201011 6/7/2010 201006 6/20/2010 163
Implementación IS&T 4/30/2010 100.00% Abril 2010 4/20/2010 201004 200905 5/15/2009 340
Desarrollo Finanzas 4/30/2010 100.00% Abril 2010 4/30/2010 201004 4/10/2010 201004 4/4/2010 26
Desarrollo QHS 8/30/2010 100.00% Agosto 2010 8/30/2010 201008 201004 4/8/2010 144
Desarrollo Supply Chain 5/31/2011 100.00% Mayo 2011 5/15/2011 201105 5/12/2010 201004 4/20/2010 390
Desarrollo Finanzas 5/3/2010 100.00% Mayo 2010 5/7/2010 201005 4/23/2010 201004 4/22/2010 15
Desarrollo Mantenimiento 7/31/2010 100.00% Julio 2010 7/31/2010 201007 201004 4/24/2010 98
Desarrollo Finanzas 5/31/2010 Mayo 2010 5/7/2010 201005 5/6/2010 201005 5/6/2010 1
Desarrollo QHS 12/31/2010 100.00% Diciembre 2010 12/31/2010 201012 7/1/2010 201005 5/7/2010 238
Desarrollo Finanzas 6/30/2010 100.00% Junio 2010 6/30/2010 201006 5/15/2010 201005 5/24/2010 37
Desarrollo Mina 7/18/2010 100.00% Julio 2010 7/21/2010 201007 201006 6/10/2010 41
Desarrollo Finanzas 8/31/2010 100.00% Agosto 2010 10/10/2010 201010 201008 8/4/2010 67
Desarrollo Mina 9/30/2010 100.00% Septiembre 2010 10/11/2010 201010 201007 7/15/2010 88
Desarrollo RRHH 9/30/2010 100.00% Septiembre 2010 9/19/2010 201009 8/12/2010 201006 6/22/2010 89
Implementación Mina 1/31/2010 100.00% Enero 2010 1/31/2010 201001 8/5/2009 200908 8/5/2009 179
Desarrollo Planta 10/15/2010 100.00% Octubre 2010 9/30/2010 201009 9/6/2010 201009 9/3/2010 27
Desarrollo Comercial 12/31/2010 100.00% Diciembre 2010 12/31/2010 201012 201010 10/10/2010 82
Desarrollo Comercial 1/31/2011 100.00% Enero 2011 1/31/2011 201101 201011 11/6/2010 86
Implementación IS&T 12/31/2010 100.00% Diciembre 2010 12/31/2010 201012 12/6/2010 201009 9/5/2010 117
Implementación Mina 5/31/2011 100.00% Mayo 2011 5/31/2011 201105 11/1/2010 201010 10/27/2010 216
Implementación Finanzas 11/30/2010 100.00% Noviembre 2010 12/10/2010 201012 9/22/2010 201009 9/22/2010 79
Desarrollo DSRC 2/10/2011 100.00% Febrero 2011 2/8/2011 201102 1/15/2011 201012 12/9/2010 61
Desarrollo Planta 1/31/2011 100.00% Enero 2011 1/31/2011 201101 1/11/2011 201101 1/11/2011 20
47
Tipo Gerencia Fecha Avance Mes Previsto
de Entrega Año
Fecha Producción
Mes de Entrega Fecha Inicio Mes Requerido Fecha Requerido
Fecha producción -
Fecha Requerido
Desarrollo IS&T 2/17/2011 100.00% Febrero 2011 2/21/2011 201102 201102 2/17/2011 4
Desarrollo Supply Chain 4/14/2011 100.00% Abril 2011 4/17/2011 201104 201102 2/4/2011 72
Desarrollo Finanzas 4/30/2011 100.00% Abril 2011 4/30/2011 201104 4/4/2011 201104 4/12/2011 18
Desarrollo Comercial 6/17/2011 100.00% Junio 2011 6/26/2011 201106 201104 4/30/2011 57
Desarrollo Finanzas 5/25/2011 100.00% Mayo 2011 5/31/2011 201105 5/23/2011 201105 5/22/2011 9
Desarrollo Planta 6/19/2011 100.00% Junio 2011 6/19/2011 201106 201106 6/19/2011 0
48
4.5 DIAGNÓSTICO DE LA GESTIÓN ACTUAL Los procedimientos identificados, están enfocados en actividades de desarrollo
de software. Los procedimientos dan los lineamientos de diseño y construcción
de aplicaciones informáticas. El proceso se lo considera como importante ya
que el desarrollo interno como externo se basa en éste, al igual que los ajustes
realizados a las aplicaciones que están en la plataforma de producción.
La historia de los proyectos claramente identifica el retraso de los productos
frente a sus respectivas fechas de requerimiento.
Según entrevistas con los usuarios del proceso de administración de proyectos
de sistemas de información, los causantes comunes de los retrasos en los
proyectos son los siguientes (MSC, 2010):
• Dimensionamiento pobre de tareas. Las tareas son mayores a lo que
inicialmente se había pensado.
• Cambios de alcance a solicitud de los usuarios. Los cambios de alcance
normalmente requieren de más tiempo para su implementación.
• Retraso en asignación de recursos a causa de solicitudes tardías.
• Falta de información en identificación de tareas.
• Tareas ejecutadas en mayor tiempo que el que se pensaba.
• Dependencia de otros administradores de proyectos que tienen
información histórica de proyectos similares y tardanza en su entrega a
los interesados. Este problema no permite gestionar mejor los nuevos
proyectos que incluso en algunos casos son similares.
• Los involucrados en las tareas no están disponibles por falta de
coordinación.
• No hay control oportuno de las desviaciones de lo planificado contra lo
ejecutado.
• No existe una guía de las actividades mínimas que se debe cumplir para
poder administrar un proyecto.
49
Entre las causas identificadas por los problemas mencionados se encuentran:
• Definición de alcance.
La definición del alcance identifica todo lo que cubre el proyecto
inicialmente. Cualquier cambio que se realice puede afectar positiva o
negativamente al proyecto, siendo cualquier cambio gestionado por un
control de cambios.
• Planificación y ejecución de proyectos.
La planificación de proyectos detallada identifica las tareas, tiempos,
recursos necesarios para estimar el tiempo de proyectos. Una buena
planificación puede ayudar a predecir la ejecución de proyectos en cola.
También ayuda a planificar la disponibilidad de recursos y contratos.
• Control de proyectos.
Con el conocimiento oportuno de las desviaciones entre lo planificado y
lo ejecutado, se puede tomar acciones correctivas de forma proactiva
que ayuden a los proyectos culminar en el tiempo planificado.
Todo cambio solicitado debe ser analizado, evaluado y aprobado antes
de ser ejecutado.
• Cierre de proyectos.
El cierre de proyectos confirma que se cumplió con el alcance del
proyecto, se formaliza el producto y completa las lecciones aprendidas
que incluye lo que se realizó bien y lo que se realizó mal como una
bitácora para futuros proyectos.
• Almacenamiento de información.
Con el lugar de almacenamiento de información generada respecto al
proyecto debidamente identificado, se puede contar con historial de la
ejecución de proyectos al igual que la facilidad de acceso de consulta a
todo interesado. La información histórica sirve como un insumo para
futuros proyectos de similares características.
• Procedimientos.
Con la guía de actividades a seguir, se garantiza el seguimiento de las
tareas de gestión de proyectos y homogeneidad en el desarrollo de
proyectos.
50
El siguiente diagrama de espina de pescado ayuda a identificar e ilustrar
claramente la necesidad de contar con actividades de gestión de proyectos
para reducir los retrasos en los proyectos. En las terminales se identifican los
puntos que se deben atacar para obtener una mejoría en el desarrollo de los
proyectos y en sus ramas las oportunidades que se van a atacar.
Gestión de proyectos
Planificación de proyectos
Definición de alcance
Ejecución de proyectos
Control de proyectos
Identificación de detalle de tareas
Planificación de recursos
Cambios de alcance (nuevos o modificación
de requerimientos)
Retraso en asignación de recursos
Falta de mejora continua
Cierre de proyectos
Falta de información en identificación
de tareas
Tareas ejecutadas en mayor tiempo que
el que se pensaba
Disponibilidad de involucrados
Almacenamiento de información
Pérdida de información histórica
(activos empresariales)
Control de cambios
Control oportuno de las desviaciones
de lo planificado contra lo ejecutado
Identificación de actividades
de gestión de proyectos
Estimación de ejecución de nuevos proyectos
Procesos
Estimación de tiempos desproporcionados
con la realidad
Registro delecciones aprendidas
Homogeneidad en administración de proyectos
Dependencia de información histórica de administradores
de proyectos
Figura 23 Diagrama de espina de pescado
4.5.1 IDENTIFICACIÓN DE OPORTUNIDADES DE MEJORA Con base en el diagnóstico de la gestión actual y el PMBOOK, se identifican
algunas propuestas de mejora que impactan en la gestión de proyectos de
desarrollo de software.
a. Desarrollar acta de constitución del proyecto.
El acta ayuda a autorizar formalmente el proyecto, el alcance, los
stakeholders de tal forma en que sus necesidades sean incorporadas
en el proyecto. De esta forma se delimita formalmente el proyecto.
Cualquier cambio que modifique el alcance se hará una evaluación
costo beneficio y de esta forma se modificará el proyecto. Un cambio
de alcance puede afectar las variables costo y tiempo.
b. Desarrollar el plan de gestión del proyecto.
El plan de gestión de proyectos define las tareas a realizar, los
tiempos y los recursos utilizados. Estos puntos se encuentran
específicamente en el desarrollo de un cronograma de proyecto.
51
Con el cronograma del proyecto se puede saber todas las tareas que
se tienen que cumplir para terminar el proyecto. También se
determina el equipo del proyecto, predecir los recursos necesarios
para cumplir con cada tarea sus roles y responsabilidades, y el
tiempo oportuno de su adquisición o contratación.
El plan también contiene cómo se realizarán las comunicaciones, la
gestión de riesgos, contratos y adquisiciones.
c. Desarrollar el grupo de procesos de ejecución para completar el
trabajo definido en el plan de gestión del proyecto y cumplir con los
requisitos del proyecto.
La ejecución del proyecto se realiza de acuerdo a lo planificado. Se
produce el alcance del proyecto, se ejecutan los contratos y
adquisiciones garantizando la disponibilidad de los mismos el
momento que se los necesita. Se realizan el control de calidad donde
se realizan los ajustes para cumplir con el plan.
Los retrasos de los proyectos pueden ser identificados de forma
oportuna y gestionados para que no afecten del desarrollo del
proyecto. En el caso que los retrasos o algún otro factor impacten
negativamente el proyecto y no pueda ser gestionado sin afectar el
normal desarrollo del proyecto, se debe aplicar el control de cambios.
d. Desarrollar los procedimientos de seguimiento y control para
identificar los problemas oportunamente y adoptar las acciones
correctivas.
El procedimiento de seguimiento y control, ayuda a analizar las
desviaciones que tiene el proyecto contra lo identificado, establecer
acciones correctivas y formalizar aplicación. También incluye el
control de cambios que debe incluir un análisis costo beneficio y su
respectiva aprobación antes de efectuar la ejecución. El control de
proyectos debe ser realizado de forma continua de tal forma que se
pueda tomar acciones correctivas de forma oportuna y de esta forma
cumplir con lo planificado.
e. Desarrollar los procedimientos de cierre de proyectos.
Desarrollar los procedimientos de cierre del proyecto finaliza todas
las actividades de todos los grupos de procesos y así cierra
52
formalmente el proyecto. También se identifican las lecciones
aprendidas las cuales ayudan a contar con un activo empresarial
valioso para futuros proyectos ya que son una referencia de las
buenas prácticas que ayudaron al éxito de los proyectos y también
factores de mejora que se pueden tomar en cuenta en los nuevos
proyectos.
f. Identificación de proceso.
Con el modelado de los procedimientos se identifica claramente las
actividades, los roles, recursos, entradas, salidas y herramientas a
utilizar incluyendo su respectivo almacenamiento de la información
generada. De esta forma se tiene establecido un marco
metodológico que ayude a gestionar los proyectos y no omitir tareas
importantes.
Como punto adicional y en apoyo al medio ambiente:
g. Usar herramientas de colaboración que eviten el uso innecesario de papel. En el desarrollo de los procedimientos se pondrá énfasis intrínseco en buscar alternativas que ayuden a conservar el medio ambiente.
El siguiente cuadro resume el diagnóstico de las oportunidades de mejora más
las propuestas de mejora que se plantean para mejorar la gestión de proyectos
de desarrollo de software.
53
Cuadro 5 Resumen del diagnóstico de oportunidades de mejora y propuesta de mejora
CAUSA EFECTO OPORTUNIDAD DE MEJORA
Definición de alcance
- Nuevas tareas a realizar por cambio de alcance.
- Modificación de requerimientos.
Desarrollar acta de constitución del proyecto.
Planificación y Dimensionamiento pobre de tareas.
- Estimación de tiempos desproporcionados con la realidad.
- Pobre identificación de tareas.
- Falta de información en identificación de tareas.
- No se puede estimar la ejecución de nuevos proyectos.
Desarrollar el plan de gestión de proyecto.
Ejecución de proyectos
- Tareas ejecutadas en mayor tiempo que el planeado.
- Los involucrados en las tareas no están disponibles por falta de coordinación.
- No existe disponibilidad de involucrados.
Desarrollar el grupo de procesos de ejecución para completar el trabajo definido en el plan de gestión del proyecto y cumplir con los requisitos del proyecto.
Falta de control de proyectos
- No hay control oportuno de las desviaciones de lo planificado contra lo ejecutado de forma proactiva.
- No hay ningún control de cambios.
Desarrollar los procedimientos de seguimiento y control para identificar los problemas oportunamente y adoptar las acciones correctivas.
Falta de cierre de proyectos - No existe un registro de
lecciones aprendidas. - Falta de mejora continua.
Desarrollar los procedimientos de cierre de proyectos.
No hay guía mínima de actividades para administrar proyectos (Identificación de procedimientos).
- No hay homogeneidad en el desarrollo de proyectos.
- No existe una guía de actividades mínimas que se debe cumplir para poder administrar un proyecto
Identificación del proceso.
Almacenamiento de información disperso.
- Pérdida de activos empresariales.
- Dependencia de información histórica de proyectos similares de administradores de proyectos.
Identificación del proceso.
54
4.6 PROPUESTA DE MEJORA La propuesta de mejora se basa en establecer un procedimiento que ayude a
guiar las tareas de administración de proyectos de desarrollo de software.
Con base en la identificación de oportunidades de mejora, se propone un
nuevo modelo de procedimientos de gestión de proyectos. La propuesta
separa las actividades de gestión de proyectos y el ciclo de vida de desarrollo
de software. También incluye un balanced scored card que ayude a maximizar
la probabilidad de proyectos exitosos.
4.6.1 ESTRUCTURA ORGANIZACIONAL PROPUESTA Se propone una estructura matricial equilibrada donde el administrador de
proyectos tenga control de los recursos y poder de decisión sobre el proyecto.
Respecto al control de recursos, el administrador de proyectos coordina
estrechamente con el administrador funcional el tiempo de uso de acuerdo al
cronograma propuesto para evitar recursos ociosos durante el desarrollo de
proyectos.}
Cualquier gerente funcional es el patrocinador del proyecto. En caso que
exista varias áreas funcionales involucradas en un proyecto, el patrocinador es
el que tiene más interés en realizar el proyecto.
55
Director ejecutivo
Gerente funcional
Gerente funcional
Gerente funcional
Personal
Personal
Personal
Personal
Personal
Personal
Personal
Personal
Personal
IS&T
Supervisor del proyecto
Analistas
Administrador del proyecto
Coordinador del proyecto
Figura 24 Estructura organizacional propuesta
4.6.2 PROCEDIMIENTO GENERAL DE GESTIÓN DE PROYECTOS Se propone un nuevo macro proceso ya que el anterior excluye al análisis de
necesidades de la gestión de proyectos. Si el análisis de necesidades es
bastante ambiguo como para planificar de forma exacta, se puede dividir en un
sub proyecto que esté bajo el mismo proceso propuesto.
Figura 25 Propuesta proceso general de gestión de proyectos
56
4.6.2.1 Iniciación Se crea una carpeta repositorio de documentación digital en Sharepoint más
los respectivos permisos de acceso a todos los involucrados en el proyecto.
Con base en la solicitud, los activos empresariales de la empresa y los
procedimientos, se procede a realizar el acta de inicio del proyecto. El
patrocinador del proyecto informa el inicio del proyecto a todos los interesados.
Responsable: El administrador de proyectos es el responsable de crear la carpeta de
proyectos, Realizar el acta de inicio del proyecto y actualizar el pool de
proyectos.
Actores: El patrocinador del proyecto, el Supervisor de proyectos y el administrador del
proyecto firman el acta de inicio del proyecto.
Los expertos de encargan de apoyar al administrador de proyectos a definir el
alcance del proyecto.
Todo interesado identificado debe ser parte del acta del proyecto para
identificar el correcto alcance del proyecto.
57
Figura 26 Iniciación
Nombre y permisos
58
4.6.2.2 Planificación En la planificación se estima el trabajo a realizar, los entregables, tareas y
recursos. Con base en el resultado, se crea y mantiene un plan de proyecto
formal y aprobado. Finalmente se busca y obtiene el compromiso con todos los
interesados.
La planificación se divide en tres etapas:
• Establecer las estimaciones.
• Desarrolla el plan del proyecto.
• Obtener compromiso con el plan.
Figura 27 Planificación
4.6.2.3 Establecer Estimaciones Se crean las fases, entregables y tareas. Las tareas contemplan estimaciones
de tiempos y recursos. Incluye toda la información necesaria para desarrollar
la planificación, organización, staffing, dirección, coordinación, reporting y
presupuesto.
Los insumos que son típicamente utilizados durante la estimación son:
• Requerimientos del proyecto.
• Alcance del proyecto.
• Juicio y aproximación de expertos.
• Modelo de ciclo de vida.
• Procedimientos.
• Datos históricos.
59
Responsable: El administrador de proyectos es el encargado de definir el alcance, definir el
ciclo de vida, y estimar los esfuerzos, coste y calendario del proyecto.
Actores: Los expertos ayudan al administrador de proyectos definir los entregables y las
tareas que hay que hacer para llegar a ellos. También ayudan a estimar los
tiempos y recursos de las tareas.
Figura 28 Establecer estimaciones
Establecer• Responsables• Herramientas• Actores
60
4.6.2.4 Desarrollar el Plan del Proyecto Se crea y mantiene el calendario y el presupuesto del proyecto. El presupuesto
y el calendario del proyecto están basados en las estimaciones y asegura que
se gestionará de forma adecuada el presupuesto, la complejidad de las tareas
y las dependencias entre ellas.
Entre las principales acciones que se pueden realizar están
• Identificar los hitos
• Identificar aquellas tareas cuya estimación no es muy especifica
• Identificar las restricciones de tiempo, de recursos, entradas y salidas
• Identificar la dependencia entre tareas
• Definir el presupuesto y el calendario
• Definir recursos
• Definir las comunicaciones
• Establecer unos criterios para las acciones correctivas que determinarán
que constituye una desviación significativa. Los riesgos deben ser identificados y analizados de cara a que sean tenidos en
cuenta a la hora de la planificación del proyecto.
Los riesgos deben ser priorizados en función del impacto que pueden tener en
el proyecto para tomar las acciones de mitigación necesarias.
Planificar la gestión de datos. Se entiende como Datos las distintas formas de
documentación necesaria para el correcto entendimiento de la aplicación. Se
puede presentar en múltiples medios (impreso, digital, multimedia, etc.)
Los requisitos de datos para el proyecto deben estar establecidos tanto los
ítems de datos como su contenido y forma.
Planificar los recursos. Planificar los recursos necesarios para el desarrollo del
proyecto.
Se deben definir los recursos (personas, maquinas, materiales, etc.) y las
cantidades necesarias para desarrollar las actividades del proyecto definidas
en la estimación inicial y aportar información adicional que pueda ser utilizada
para refinar el WBS utilizado para la gestión de proyecto.
61
Establecer el plan del proyecto. Establecer y mantener la planificación del
proyecto completo.
Es necesario un plan documentado que tenga en cuenta todos los planes
importantes, de cara a alcanzar un entendimiento mutuo, entre los planes,
compromiso y un rendimiento adecuado de los individuos, grupo y
organizaciones que tienen que ejecutar o dar soporte al plan.
El plan creado para el proyecto debe definir todos los aspectos de esfuerzo:
ciclo de vida del proyecto, tareas de gestión y técnicas, presupuestos y
planificación temporal, conocimientos y recursos necesarios, hitos, gestión de
datos, identificación de riesgos e identificación de los interesados. La
descripción de las infraestructuras incluye las relaciones de responsabilidad y
autoridad para el equipo técnico, de gestión y soporte del proyecto.
Responsable: El administrador de proyectos es el encargado de desarrollar el plan del
proyecto.
Actores: Los expertos ayudan a establecer todas las tareas necesarias para cumplir con
los objetivos del proyecto.
Los interesados se encargan de velar porque el plan del proyecto cumple con
todo lo establecido en el acta del proyecto.
62
Figura 29 Desarrollar el plan del proyecto
63
4.6.2.5 Ejecución Se establece una línea base en el cronograma del proyecto. Esto es con el fin
de hacer un control entre lo planificado y lo ejecutado.
Dirigir y gestionar la ejecución del proyecto. Consiste en ejecutar el trabajo
definido en el plan de gestión del proyecto para lograr los requisitos del
proyecto. Los analistas son los encargados de informar los avances del
proyecto.
También se desarrolla las capacidades necesarias del equipo del proyecto para
asegurar la calidad de los distintos productos software obtenidos durante el
proceso de desarrollo.
El departamento de contratos se encarga de realizar la selección y adquisición
de los proveedores. Finalmente el grupo QA verifica que los entregables
cumplen con los estándares especificados. Si es necesario realizar cambios, se
establece lo que es necesario para corregir los defectos.
Responsable: El administrador de proyectos es el encargado de gestionar la ejecución del
proyecto.
Actores: Los analistas se encargan de ejecutar las tareas para llegar a cumplir con el
proyecto. Se encargan de actualizar el estado de las tareas e informar las
variaciones en las tareas o los entregables.
El grupo QA verifica la calidad del proceso.
64
Figura 30 Ejecución
65
4.6.2.6 Seguimiento y Control Con base en el cronograma del proyecto, se supervisa el avance de las tareas.
Todo cambio registrado como incidencia se lo gestiona a través del control
integrado de cambios. También se realiza el control del trabajo en términos de
costos utilizando Earned Value. Se controla los entregables contra los
requerimientos, se gestiona el equipo del proyecto y finalmente se informa en
rendimiento a todos los interesados.
Responsable: El administrador de proyectos es el encargado del seguimiento y control del
proyecto.
Actores: El grupo QA se encarga de realizar el control de calidad a todos los
entregables. También se encarga de ayudar al administrador de proyectos
gestionar el control integrado de cambios.
El supervisor de proyectos se interesa en que el proyecto esté marcando según
lo planificado.
Los interesados se encargan de que la calidad de los productos sean los
establecidos.
66
Figura 31 Seguimiento y control
67
4.6.2.7 Cierre Incluye finalizar todas las actividades completadas a lo largo de todos los
grupos de procesos de dirección de proyectos para cerrar formalmente el
proyecto o una fase del proyecto, y transferir el proyecto completado o
cancelado según corresponda. Involucra las siguientes actividades:
Confirmar que el trabajo está terminado respecto a los requerimientos
verificando que se cumple con todo lo establecido inicialmente. Se termina
toda la documentación de respaldo y se coordina formalmente la aceptación del
producto. Es necesario hacer un análisis de lecciones aprendidas y las
recomendaciones para la mejora de los procesos, para poder aplicarla en la
planificación e implementación de situaciones futuras.
El cierre del contrato respalda a la actividad de cerrar proyecto ya que incluye
la verificación de que todo el trabajo y todos los productos entregables han sido
aceptables. El cierre del contrato también incluye actividades como
actualizaciones de registros para reflejar los resultados finales y archivo de
dicha información para su uso en el futuro. Se actualiza el pool de proyectos.
El cierre del contrato aborda cada contrato aplicable al proyecto o una fase del
proyecto. Se desvinculan todos los recursos.
Responsable: El administrador de proyectos es el encargado de cerrar el proyecto.
Actores: Todo el personal involucrado en el proyecto.
68
Figura 32 Cierre
69
4.6.3 CICLO DE VIDA DE DESARROLLO DE SOFTWARE La metodología de desarrollo de sistemas de información de MSC es la
siguiente:
• Análisis
• Diseño
• Desarrollo
• Pruebas
• Pase a producción
La metodología mencionada se la identifica como las fases que se requieren
para desarrollar un sistema, es decir el ciclo de vida del proyecto.
Los grupos de procesos de administración de proyectos usan las fases de
desarrollo de sistemas de información para iniciar, planificar, ejecutar, controlar
y cerrar el proyecto.
Para proyectos pequeños puede ser necesario ejecutar una vez el grupo de
procesos de administración de proyectos para todas las fases, mientras que
para proyectos grandes, usualmente necesitan ser divididos por fases y por
cada fase necesita ejecutar una vez el grupo de procesos de administración de
proyectos.
Figura 33 Ciclo de vida de desarrollo de software
70
4.6.3.1 Diagnóstico Dentro del diagnóstico de la solicitud se tienen dos posibilidades:
• Que se realicen modificaciones mayores a la estructura de un sistema o
el desarrollo de un nuevo sistema (Evolución).
• Que se realicen correcciones de menor escala sobre los sistemas como
correcciones de defectos, mejoras pequeñas, extensiones de un módulo
(Ajuste).
Figura 34 Pre proyecto ciclo de vida
71
4.6.3.2 Evolución La evolución es el posible resultado de un diagnostico de una solicitud. Este
tipo de proyecto cubre desarrollos a mayor escala que representen nuevos
requerimientos, la derivación de un módulo en otro nuevo o incluso un nuevo
sistema.
El criterio principal para clasificar una solicitud como una evolución es tener la
necesidad de realizar las actividades de análisis de negocio y/o conceptual,
realizar modificaciones mayores en la estructura de un módulo o implementar
un nuevo desarrollo.
Figura 35 Evolución
72
4.6.3.3 Análisis y Diseño Lógico de Evolución El analista realiza el análisis de los procesos de negocio, requerimientos y
modelo conceptual.
Se establece la especificación de los requisitos funcionales y no funcionales.
Constituye el modelo primario para el diseño y construcción del software.
Asimismo, los procesos, información, actores y roles se relacionan con las
funciones que van a desempeñar en el sistema a desarrollar.
El modelo conceptual se muestra el dominio del problema y se explican los
conceptos en forma de clases conceptuales significativas. Este modelo es una
base para la elaboración posterior de los diseños. Es una actividad paralela al
Desarrollo de Requerimientos.
Se desarrolla el Modelo de Diseño Lógico, es decir, se descompone
lógicamente el sistema (componente lógicos) con base en el Modelo de
Especificación de Requerimientos y el Modelo Conceptual.
Figura 36 Análisis y diseño lógico de evolución
73
4.6.3.4 Ajuste Se entiende como un ajuste a los desarrollos de menor escala tales como
correcciones de defectos, mejoras pequeñas, afinaciones o menores
extensiones a un módulo ya existente.
El criterio principal para clasificar una solicitud como ajuste es no tener la
necesidad de realizar análisis de negocio (o conceptual) o modificaciones
mayores en estructura de un módulo.
Las partes componentes de esta etapa son: Análisis de un ajuste, Diseño del
Ajuste, Construcción y Pruebas Internas, Aceptación y Pase a producción.
Con base en la Solicitud del cliente, el analista realiza un análisis detallado con
el objetivo de llegar a un entendimiento completo de los requerimientos y se los
detalla en el Modelo de Requerimientos y se ajusta el modelo Físico.
Las construcción, aceptación y pase a producción se realizan de igual forma
que una evolución.
Figura 37 Ajuste
74
4.6.3.5 Procedimientos Comunes Construcción y Pruebas Internas Dentro de la construcción se debe tener en consideración los estándares de
desarrollo establecidos.
El analista prepara los casos de prueba a ser ejecutados de forma paralela a la
programación.
Con base en el diseño físico (componentes físicos), el analista diseña el
Modelo de de Pase a Producción para el apoyo a las tareas de instalación.
También prepara todos los paquetes de instalación de la solución.
Figura 38 Construcción y pruebas internas
75
Aceptación y Pase a Producción Cuando el analista certifica que cumple con las pruebas, los key users
proceden con las pruebas de aceptación de usuario. El resultado de esta
actividad puede ser la aceptación o no de un producto, prosiguiendo con el
pase a producción o regresando a la etapa de análisis, diseño o construcción
en caso de encontrar un error o defecto.
Se prepara el paquete de instalación. El administrador de seguridad se
encarga de pasar a producción. Para realizar el pase a producción, el
administrador de seguridad certifica que se está cumpliendo con el
procedimiento y los entregables estipulados.
Figura 39 Aceptación y pase a producción
76
4.6.4 INDICADORES DE DESEMPEÑO En ayuda al control y toma de decisiones oportunas respecto a la
administración de proyectos, se propone implementar un Balance Scorecard
bajo las siguientes perspectivas:
1. Financiera.
2. Clientes.
3. Procesos internos.
4. Aprendizaje y crecimiento. Cuadro 6 Indicadores de desempeño
PERSPECTIVA INSUMOS METAS METRICAS
Financiera Grupo de
procesos de
planidifación,
ejecución y
control.
No sobrepasar los
costos planificados
para la elaboración
del producto.
Earned Value
Clientes Modelos de
Desarrollo
de software.
No modificar el
diseño de la
solución.
Número de
modificaciones al
diseño de la
solución.
Procesos Internos Grupo de
procesos de
control.
Anticipar los
problemas de
planificación.
Asegurar la calidad
de los productos
entregados.
Porcentaje de
actividades en las
que se ha
detectado errores
de planificación.
Porcentaje de
productos 0
defecto.
Aprendizaje y
Crecimiento
Grupo de
procesos de
planificación,
ejecución y
control.
Proveer
entrenamiento
adecuado al
personal de acuerdo
a los roles y
responsabilidades.
Horas de
entrenamiento por
persona de
acuerdo a lo
planificado.
77
4.6.4.1 Herramientas Identificadas en los procedimientos Las herramientas tecnológicas identificadas en el proceso son las siguientes:
Enterprise Architect. Herramienta utilizada para modelar sistemas.
ISOKEY. Herramienta que sirve para la gestión del sistema de gestión de
MSC.
Jira. Herramienta que sirve para registrar y hacer seguimiento a tareas.
MS Excel. Hoja de cálculo que sirve para hacer formularios.
MS Project. Herramienta que sirve para gestionar proyectos.
Outlook. Herramienta de correos y formularios.
Sharepoint. Herramienta colaborativa que sirve para publicar y compartir
contenido empresarial.
Track IT. Herramienta que sirve para centralizar solicitudes de soporte. En
MSC, la herramienta está integrada con el servidor de correos.
WBS Chart Pro. Herramienta utilizada para desarrollar EDTs.
Figura 40 Herramientas tecnológicas utilizadas
78
4.6.4.2 Insumos El siguiente diagrama muestra los insumos utilizados más su respectivo lugar
de almacenamiento.
Figura 41 Insumos utilizados
79
4.6.4.3 Formularios El siguiente diagrama muestra los formularios utilizados más su respectivo
lugar de almacenamiento.
Figura 42 Formularios utilizados
80
4.6.4.4 Entregables El siguiente diagrama muestra los entregables que se debe contar al final de
cada proyecto de sistemas de información más su lugar de almacenamiento.
Los entregables sirven como activos de conocimiento para futuros proyectos y
a la vez evidencia para auditorías de cumplimiento al procedimiento.
Figura 43 Entregables de proyectos de sistemas de información
81
4.6.4.5 Modelos El siguiente diagrama muestra los modelos que se deben tener al desarrollar
un software.
Figura 44 Modelos solicitados para el desarrollo de software
82
5 CONCLUSIONES El desarrollo de este proyecto identificó las oportunidades de mejora con base
en el detalle del proceso actual y realizando un análisis de los problemas que
se atraviesan. Las oportunidades de mejora identificadas fueron traducidas en
una propuesta para mejorar los procedimientos de Administración de Proyectos
de Desarrollo de Sistemas de Información aplicando actividades y herramientas
establecidas por la guía del PMBOK para mejorar la gestión de los proyectos
de información de MSC.
En cumplimiento con los objetivos:
1. Se logró el primer objetivo, el cual consiste en la identificación de los
procedimientos vigentes de desarrollo de sistemas de información de
MSC.
Los procesos vigentes identificados son:
1.1. Análisis de Necesidades
1.2. Planificación de Proyecto
1.3. Diseño
1.4. Desarrollo
1.5. Validación
1.6. Verificación prueba
De cada proceso, se detallaron sus respectivas actividades, insumos,
salidas, responsables, formularios, herramientas y métricas.
2. Con el segundo objetivo el cual consiste en diagnosticar aspectos de
mejora a los procesos identificados enfocados en actividades de
administración de proyectos, herramientas a usar y su almacenamiento,
se identificaron los causantes comunes de los retrasos de los proyectos
y sus efectos. La causa raíz detectada es la gestión de proyectos y de
forma específica se identificó la que con la definición de actividades de
alcance, planificación, ejecución y control, y cierre de proyectos se
improvisaría las dificultades por las que actualmente MSC está
atravesando en el desarrollo de proyectos de de desarrollo de sistemas
de información.
3. Con el tercer objetivo que consiste en mejorar los procedimientos de
administración de proyectos de desarrollo de sistemas de información
incluyendo actividades, herramientas e indicadores con base en el
83
diagnóstico realizado, contar con un modelo de procesos de ciclo de
vida de desarrollo de sistemas de información conjuntamente ligados a
una metodología de administración de proyectos basados en el PMBOK.
Los procesos cuentan con diagramas de actividades que muestren las
tareas más sus respectivos insumos, resultados, responsables, actores y
almacenamiento. Las actividades indicadas son una guía para los
administradores de proyectos para administrar un proyecto.
4. A partir de lo anterior, se generaron dos puntos importantes a mencionar
que se consideran como factores importantes para aumentar la
probabilidad de éxito en el desarrollo de proyectos de sistemas de
información:
4.1. Los entregables de los procedimientos propuestos forman parte
de los activos empresariales y sirven como insumos para futuros
proyectos e incrementar la probabilidad de proyectos exitosos.
4.2. Los indicadores propuestos en el proyecto fueron orientados a ser
proactivos y ayudar a la toma de decisiones oportuna.
84
6 RECOMENDACIONES
• Cambiar el macro proceso de gestión de proyectos incluyendo al macro
proceso Análisis de Necesidades dentro de la gestión de proyectos. El
macro proceso de Análisis de Necesidades necesita también ser
gestionado dentro de un proyecto y como el ciclo de gestión de
proyectos es cíclico, entonces este macro proceso puede ser tratado
como un sub proyecto.
• Como la organización de MSC es funcional, se recomienda implementar
una estructura organizacional matricial equilibrada con el fin de otorgar
mayor poder al administrador de proyectos sobre los recursos
especialmente los humanos.
• Mantener la mejora continua de los procedimientos, buscando siempre
ajustes que puedan simplificar el proceso y agilizar los entregables sin
perder la calidad.
• Mantener un registro de los proyectos como parte de los activos
empresariales ya que el trabajo realizado por los administradores de
proyectos sirven como insumos a proyectos similares.
• Delimitación clara de responsabilidades, recursos y participación con
conocimiento de las relaciones y dependencias entre el trabajo de todos
los involucrados. Prever cómo el incumplimiento de una unidad puede
afectar el desempeño del proyecto.
• Para implementar los procesos, tomar en cuenta lo siguiente:
- Gestionar el cambio de los procesos con el área de desarrollo de
negocios.
- Definir una línea base que corte la ejecución de los procesos
vigentes y se reemplace los nuevos procesos.
- Definición de Pilotos de ejecución de los procesos que permitan
detectar fallas, deficiencias y oportunidades de mejoría antes de
que su corrección sea muy costosa o su impacto negativo sea
significativo.
- La implementación de los procesos deben contar con
evaluaciones periódicas que permitan detectar a tiempo
85
problemas, debilidades y limitaciones e iniciar procesos formales
para su corrección a tiempo.
- Definición de Plan de gestión del cambio. El plan debe buscar la
participación de todos los afectados y gestionar las iniciativas.
También debe contener actividades de concientización y difusión.
86
7 BIBLIOGRAFÍA Geoffrey Sparks, S. S. (n.d.). Modelo de Proceso de Negocio. Recuperado el
22-05, 2011, de Craftware:
http://www.craftware.net/es/descargas/modelo_de_proceso_de_negocio.pdf
Global Infomine. (2010). Recuperado el 2010, de
http://www.infomine.com/careers/eoc/SanCristobal.asp
ISO9000-3. (2000). Guía para la aplicación de ISO 9001 para el desarrollo, la
aplicación y mantenimiento de software.
MSC. (2010). Recuperado el 2010, de http://www.minerasancristobal.com/es/
MSC. (2010a). Recuperado el 2010, de
http://www.minerasancristobal.com/es/?page_id=6
Muñoz Razo, C. (1998). ¿Cómo Elaborar y Asesorar Una Investigación de
Tesis? México: Pearson Education / Prentice Hall. 300p.
Pender, T. (2003). UML Bible. Indianapolis, United States of America: Wiley
Publishing Inc.
PMI. (2008). A guide to the project management knowledge: PMBOK guide 4th
edition. Newton Square, Pennsylvania 19073-3293 USA: Project Management
Institute Inc.
Sparx, S. (n.d.). UML 2 Activity Diagram. Recuperado el 22-05, 2011, de
Enterprise Architect - Herramienta de Modelado y Diseño:
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_activitydiagram.ht
ml
87
8 ANEXOS ANEXO I CHARTER DEL PROYECTO Información principal y autorización de proyecto
Fecha: 17/04/2010 Nombre de Proyecto: Propuesta de Mejora Al Diseño de los Procedimientos de Administración de Proyectos de Desarrollo de Sistemas de Información de Minera San Cristóbal.
Áreas de conocimiento / procesos: - Administración de proyectos a) Integración del proyecto b) Gestión del Alcance c) Gestión del Tiempo d) Gestión de Costos e) Gestión de calidad f) Gestión de Recursos humanos g) Gestión de las comunicaciones h) Gestión de los riesgos i) Gestión de las adquisiciones - Mapeo de procesos - Norma ISO 9000
Área de aplicación (sector / actividad): Departamento de Sistemas de Información de Minera San Cristóbal.
Fecha de inicio del proyecto: 12/04/2010
Fecha tentativa de finalización del proyecto: 31/05/2011
Objetivos del proyecto (general y específicos): General Mejorar los procedimientos de Administración de Proyectos de Desarrollo de Sistemas de Información aplicando actividades y herramientas establecidas por el PMBOK para contar con una guía de gestión de desarrollo de proyectos de sistemas de información. Específicos
1. Identificar los procedimientos vigentes de administración de proyectos de desarrollo de sistemas de información de MSC. 2. Diagnosticar aspectos de mejora a los procesos identificados enfocados en actividades de administración de proyectos,
herramientas a usar y su almacenamiento. 3. Mejorar los procedimientos de administración de proyectos de desarrollo de sistemas de información incluyendo actividades,
herramientas e indicadores con base en el diagnóstico ejecutado. Descripción del producto: Los entregables de este proyecto son los siguientes:
1. Información teórica de la investigación. Relevamiento de fundamentos teóricos para poder desarrollar el proyecto. 2. Aspectos metodológicos empleados para la consecución de los objetivos. Establecimiento de la metodología de trabajo con
la que se realiza el desarrollo del proyecto. 3. Procesos de sistemas de información identificados. Procedimientos vigentes con los que MSC está trabajando en
administración de proyectos de desarrollo de sistemas de información. 4. Oportunidades de mejora Identificadas. Oportunidades de mejora identificadas al los procedimientos vigentes. 5. Procesos propuestos. Propuesta de procedimientos desarrollados con base en las oportunidades de mejora identificadas. 6. Resultados terminados. Conclusiones y recomendaciones.
Necesidad del proyecto (lo que da origen): Los proyectos atendidos entre el año 2010 y 2011 por el departamento de IS&T fueron aproximadamente en total 51. Dichos proyectos presentan un promedio de 204 días de retraso frente a la fecha requerida de sus respectivos productos. Dada esta diferencia, se considera necesario mejorar los procedimientos de administración de proyectos de desarrollo de sistemas de información para cumplir con los requerimientos de los usuarios a tiempo haciendo uso eficiente de los recursos propios como externos. Justificación de impacto (aporte y resultados esperados): - Mejora de los procedimientos de administración de proyectos de desarrollo de software incluyendo actividades de administración de proyectos. El nuevo procedimiento de administración de proyectos de desarrollo de sistemas de información consistirá de lo siguiente: Actores. Roles de los involucrados en el proceso. Tareas. Actividades a realizar para la administración de proyectos. Entregables. Productos entregables de tareas realizadas. Indicadores. Establecimiento de indicadores que ayuden a ser proactivos al momento de detectar retrasos en los proyectos. - Contar con activos empresariales que sirvan como insumos a proyectos similares. Restricciones / limitantes / factores críticos de éxito: - Las horas de desarrollo del trabajo son limitadas y las fechas de entrega son ajustadas para todas las tareas a realizar. - Se cuenta con horas limitadas de revisión del trabajo de los miembros del proyecto. - Hay mucha probabilidad de incrementar las horas laborales del estudiante lo cual puede afectar el desempeño y las horas invertidas. Suposiciones del proyecto: Compromiso de los involucrados para revisar el avance del trabajo realizado. Identificación de grupos de interés (stakeholders): Cliente(s) directo(s): Nelson Terrazas (Gerente Comercial) Walter Aguilar (Superintendente IS&T) Christian Daza (Supervisor de sistemas de Información) Marcelo Morales, Enrique Jauregui (Administradores de Sistemas de Información) Tutores UCI. Clientes indirectos: Analistas de sistemas, Departamento de proyectos, Departamento de Gestión de calidad. Nombre Estudiante: Ekar Zavala Yañez
Firma:
Aprobado por:
Firma:
88
ANEXO II ESTRUCTURA DE DESGLOSE DEL TRABAJO EDT
89
ANEXO III CRONOGRAMA DE DESARROLLO DEL PROYECTO
90
ANEXO IV FORMULARIOS a) Solicitud cliente.
91
b) Acta de inicio del proyecto. Información principal y autorización de proyecto Fecha: Nombre de Proyecto:
Áreas de conocimiento / procesos:
Área de aplicación (sector / actividad):
Fecha de inicio del proyecto: Fecha tentativa de finalización del proyecto:
Objetivos del proyecto (general y específicos): General
Descripción del producto: .
Necesidad del proyecto (lo que da origen):
Justificación de impacto (aporte y resultados esperados):
Restricciones / limitantes / factores críticos de éxito:
Suposiciones del proyecto:
Identificación de grupos de interés (stakeholders): Cliente(s) directo(s):
Aprobado por (patrocinador): Firma:
Nombre Supervisor de proyectos: Firma:
Nombre Administrador de Proyecto: Firma:
92
c) Matriz de riesgos.
Identificación Riesgos Evaluación riesgos sin medidas control Medidas de Control Riesgo residual despues de
medidas control
N°
Áre
a/ P
roce
so
Act
ivid
ad /
Tare
a
Condición Normal,
Anormal o Emergencia
Peligro/ Aspecto
Consecuencia/ Impacto
Legislación Aplicable o
Partes Intersas
Afectadas Expo
sici
ón
Posi
bilid
ad
Prob
abili
dad
Seve
ridad
Res
ulta
do d
e Ev
aluc
ión
Niv
el d
e R
iesg
o
Obj
etiv
os y
Met
as
Form
ació
n
Com
unic
ació
n
Con
trol
Ope
rativ
o
Plan
Con
tinge
ncia
Segu
imie
nto
y M
edic
ión
Medidas de Prevención, Control y Mitigación
Expo
sici
ón
Posi
bilid
ad
Prob
abili
dad
Seve
ridad
Res
ul- t
ado
de
Eval
ució
n
Niv
el d
e R
iesg
o A
ctua
l
93
d) Acta de reunión del proyecto. ACTA DE REUNIÓN DEL PROYECTO
Gerencia:
Código de control (si aplica): No. Contrato/ OT (si aplica): Proyecto (si aplica):
Lugar:
Fecha:
Hora
De:
A:
Tipo de Reunión (marcar con una X)
Ordinaria Extraordinaria Informativa Emergencia Coordinación Conferencia Análisis Crítico Semanal Otro (describir)
PARTICIPANTES PERSONAL MSC INVITADOS/CONTRATISTA
Nombres y Apellidos Firma (opcional)
Nombres y Apellidos Firma (opcional)
AGENDA
TEMAS TRATADOS
DECISIONES
TAREA RESPONSABLE FECHA DE
CUMPLIMIENTO
Observaciones / Sugerencias
RECORDATORIOS: (en caso de existir temas a ser cumplidos a largo plazo)
94
e) Pruebas de aceptación de usuario.
PRUEBAS DE ACEPTACIÓN DE USUARIO
Espacios que deben ser llenados por Sistemas de Información antes de realizarse las pruebas
Proyecto Fecha: / /
Usuarios Clave involucrados en las pruebas:
Casos de Uso a Probar
<<El administrador del proyecto proporcionará una lista de los casos de uso a probar>>
Caso de uso Prueba número
<<N correlativo según numero de
prueba>>
Espacios que deben ser llenados por el usuario líder después de realizadas la pruebas
Nombre usuario Fecha: / /
Comentarios de patrocinador
<<El usuario líder llenará algún comentario que ayude a entender o aclare los resultados obtenidos por las pruebas; si el producto no cumple
con lo esperado un comentario es obligatorio para entender por qué>>
¿El proyecto cumple con las pruebas y puede pasar a producción? Sí No
Firma patrocinador Firma administrador de proyecto
Aclaración de Firma Aclaración de Firma
Fecha: / / Fecha : / /
Acta de Aceptación:
Yo <patrocinador del proyecto> al firmar este documento, doy conformidad a las pruebas y certifico que el producto cumple con los requerimientos
planteados; entiendo que si encontrase algún defecto u omisión cuando el producto este en producción esto puede ocasionar la apertura de otro
proyecto que requerirá una nueva priorización por parte de mi gerencia.
Plan de Pruebas
Pruebas
1.1 Caso de prueba
Key-User:
Fecha de Ejecución:
Estado:
Firma:
1.1.1 Nombre prueba Dar de alta un artículo en el almacén de consignación
Estado:
Entradas:
Criterio de Aceptación:
Resultado:
95
f) Pase a producción.
PASE A PRODUCCIÓN
Proyecto Fecha Planificada: / /
CheckList de componentes
Fecha de Pase: / /
Preparación previa
Actividad Ejecutor Comentarios
Respaldos
Actividad Ejecutor Comentarios
Actividades de Pase
Actividad Ejecutor Comentarios
Pruebas de Funcionamiento
Actividad Ejecutor Comentarios
Firma Administrador Proyecto Firma Supervisor IS
Aclaración de Firma Aclaración de Firma
Fecha: / /
Fecha : / /
96
g) Lecciones aprendidas
LECCIONES APRENDIDAS
Nombre proyecto
Administrador del proyecto:
Fecha:
El propósito de este documento es ayudar al equipo del Proyecto compartir el conocimiento adquirido de la experiencia para el beneficio de toda la organización. A. El equipo del Proyecto debe comenzar a utilizar este documento desde el inicio de la primera
reunión. El registro continuo de las lecciones aprendidas durante todo el Proyecto es la mejor forma de asegurar que están objetivamente registradas. Los temas a considerar son los siguientes (se puede cambiar la lista). ADMINISTRACIÓN DE PROYECTOS
ADMINISTRACIÓN TÉCNICA
FACTORES HUMANOS
MISCELANEOS
Planificación de proyectos
Requerimientos Comunicación Satisfacción del cliente
Administración de recursos
Especificaciones Experiencias de equipo Éxito técnico
Administración del riesgo
Plan de pruebas Interacción con el patrocinador
Calidad del producto
Control de cambios Desarrollo Interacción con los usuarios
Aceptación del producto
Adquisiciones Pruebas Interacción con el administrador
Proyecto a tiempo
Control de calidad Cambios Soporte administrativo Proyecto dentro el presupuesto.
Reportes de estados Capacitación Calidad de reuniones Cumplimiento de objetivos
Selección de proveedores
Documentación Interacción con proveedores
Cumplimiento de objetivos de negocio
Administración de proveedores
B. Al final del Proyecto, resumir la experiencia. Durante la reunión de cierre: • Ser positivo • No culpar • Enfocarse en éxitos y fallas • Indicar las estrategias que contribuyeron al éxito • Recomendar estrategias que puedan contribuir a tener un mejor impacto
1. Diario del proyecto
Estrategias y procesos que llevaron al éxito
Fecha Descripción
Identificación de mejoras
Fecha Descripción
97
2. Reunión de cierre
Al final del Proyecto, reunir a todos los involucrados del Proyecto para una reunión de lecciones
aprendidas.
A. Listar los éxitos más grandes del proyecto.
Descripción Factores que contribuyeron al éxito
B. Listar otros éxitos que el equipo está interesado en mencionar:
Descripción Factores que contribuyeron al éxito
C. Listar las mayores mejoras que podrían ayudar al desarrollo del proyecto:
Descripción Factores que contribuyeron al éxito
D. Ingresar otros comentarios:
3. Firma de los participantes
Se está conforme con la información del documento:
Nombre Cargo Firma Fecha