Trabajo Gerencial

NIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS
“ANÁLISIS DEL SISTEMA DEL TRÁMITE DOCUMENTARIO

INTERNO APLICANDO CMMI EN LA M.P.H, 2017"
CURSO : Sistemas de Información Gerencial (IS 446)

PROFESOR : Ing. PERALTA SOTOMAYOR, Karel
INTEGRANTES :
 BARZOLA YUPANQUI, Mardonio
 MARTINEZ OSCORIMA, Guisela Roxana
 QUISPE CUCHURI, Enrique
 SANCHEZ QUISPE, Zoraida Jesusa
 TRISTAN QUISPE, Ricardo
AYACUCHO – PERÚ
2017
CONTENIDO
CONTENIDO ........................................................................................................... ii
RESUMEN ............................................................................................................. iv
INTRODUCCION .................................................................................................... v
CAPÍTULO I ........................................................................................................... 6
1 OBJETIVOS DE LA INVESTIGACIÓN ............................................................ 6
1.1 OBJETIVO GENERAL .............................................................................. 6
1.2 OBJETIVOS ESPECIFICOS ..................................................................... 6
1.3 DELIMITACIÓN ......................................................................................... 6
1.4 MARCO TEÓRICO.................................................................................... 6
1.5 ANTECEDENTES DE LA INVESTIGACIÓN ............................................. 7
CAPITULO II .......................................................................................................... 8
2 ELABORACIÓN DEL PROYECTO .................................................................. 8
2.1 CUERPO DE LA INVESTIGACIÓN........................................................... 8
2.1.1 RESUMEN EJECUTIVO DE LA EMPRESA ....................................... 8
3 SISTEMA DE TRAMITE DOCUMENTARIO – SISTDOC .............................. 17
4 SISTDOC ....................................................................................................... 17
4.1 OBJETIVOS DEL SISTDOC ................................................................... 19
4.2 ARQUITECTURA TECNOLOGICA ......................................................... 23
4.3 DIAGRAMA DE LA ARQUITECTURA TECNOLOGICA.......................... 24
4.4 METODOLOGÍA CMMI DEV ................................................................... 26
4.4.1 CMMI ................................................................................................ 26
4.4.2 CMMI DEV ........................................................................................ 27
4.4.3 SCAMPI ............................................................................................ 58
ii
4.5 APLICACION DEL NIVEL DE MADURES DE CMMI A LA ORGANIZACIÓN
60
CAPITULO III ....................................................................................................... 87
PRESUPUESTO Y CRONOGRAMA ................................................................... 87
4.6 CRONOGRAMA DE ACTIVIDADES ....................................................... 87
4.7 PRESUPUESTOS ................................................................................... 87
BIBLIOGRAFÍA .................................................................................................... 88
iii
RESUMEN
El presente Proyecto evaluara el sistema de tramite documentario interno de

la Municipalidad Provincial de Huamanga que pertenece al área de subgerencia
de Sistemas y Tecnologías, donde se plantea aplicar el Modelo de Madurez de la
Capacidad Integrado (CMMI) realizando una evaluación para determinar en qué
nivel del CMMI se encuentra el sistema de tramite documentario interno, además
se evaluara el flujo del proceso de tramite documentario, realizando análisis tales
como el funcionamiento antes de ser automatizado y que no exista duplicidad de
tareas.
Esta evaluación nos permitirá conocer en qué nivel del CMMI se encuentra el
sistema del presente caso de estudio, analizando detalladamente los documentos
de gestión de desarrollo con los que cuenta el sistema.
iv
INTRODUCCION
En la actualidad las organizaciones tienen deficiencias en la implantación de

sistemas de información, tales como la falta de capacitación al personal en el uso
de Sistemas de Información, existen Sistemas que no cumplen con el análisis de
requerimientos , sabiendo que estos son pieza clave en el desarrollo de Sistemas
de información también los procesos manuales no son automatizados
correctamente , no cuentan con documentación detallada del desarrollo de software
y por este motivo se debería aplicar la gestión de procesos de negocio (BPM) ,
CMMI que es un conjunto de modelos basados en las mejores prácticas en la
gestión de los procesos, estos modelos establecen 5 niveles de madurez de las
organizaciones en función si cumplen o no los niveles que detalla el CMMI y de
acuerdo a esta evaluación se les otorgara el nivel de madurez en el que se
encuentra el sistema.
v
CAPÍTULO I
1 OBJETIVOS DE LA INVESTIGACIÓN
1.1 OBJETIVO GENERAL

Analizar el software del “Tramite Documentario Interno” aplicando el CMMI
para determinar si cumple con el nivel de madurez y en el caso que no cumpla se
brindara sugerencias para la mejora del sistema.
1.2 OBJETIVOS ESPECIFICOS

 Aprender y aplicar la metodología CMMI.
 Conocer la filosofía del negocio.
 Analizar el flujo del proceso de tramite documentario interno.
 Conocer los procesos que automatice el Sistema.
1.3 DELIMITACIÓN
Este proyecto de investigación abarcara el análisis del software del trámite
documentario interno que se encuentra en el área subgerencia de Sistemas y
Tecnologías de la Municipalidad Provincial de Huamanga.
1.4 MARCO TEÓRICO
LA MUNICIPALIDAD
Es la institución del estado, con personería jurídica, facultada para ejercer el
gobierno de un distrito o provincia, promoviendo la satisfacción de las necesidades
de la población y el desarrollo de su ámbito.
TECNOLOGIA DE INFORMACION
Son las tecnologías que se necesitan para la gestión y transformación de la
información, y muy en particular el uso de ordenadores y programas que permiten
crear, modificar, almacenar, proteger y recuperar esa información.
Las TICs, como elemento esencial de la Sociedad de la Información habilitan la
capacidad universal de acceder y contribuir a la información, las ideas y el
conocimiento.
6
IMPORTANCIA DE LA IMPLEMENTACION DE LA TECNOLOGIA DE LA
INFORMACION
La incorporación de la tecnología puede llevar a que empresas densas y
rutinarias se transformen en ligeras, debido a la disminución de los costos de
producción y a la apertura de nuevos canales para llegar a los clientes vía internet.
La tecnología se convierte en una herramienta que coadyuva a cumplir las
estrategias empresariales, más aún si estamos en una época de cambios, en la que
se exige a las empresas ser más competitivas en los mercados local y global.
La empresa será más poderosa en la medida en que tenga buenas bases de datos
de clientes, productos y de otras empresas, lo que le posibilitará entrar a otras redes
empresariales y así desarrollar nuevos negocios.
Además, Las TICs generan ventajas múltiples tales como un público instruido,
nuevos empleos, innovación, oportunidades comerciales y el avance de las
ciencias. Desde el punto de vista de la educación, las TICs elevan la calidad del
proceso educativo, derribando las barreras del espacio y del tiempo, permitiendo la
interacción y colaboración entre las personas para la construcción colectiva del
conocimiento, y de fuentes de información de calidad (aprendizaje colectivo.
1.5 ANTECEDENTES DE LA INVESTIGACIÓN

Para realizar el trabajo se tuvo como referencia la siguiente investigación:
AUTOR: CARLOS JIMENES FABRA de la Universidad Politécnica de Valencia con
el siguiente tema:
“DESARROLLO DE PLATAFORMA WEB DE REALIZACIÓN DE SCAMPI CON

CMMI DEV”
El proyecto habla acerca de las formas de evaluar los procesos de desarrollo de
una empresa mediante la realización de SCAMPI , para poder responder a
interrogantes como : como se está haciendo, para luego verificar si cumple o no
con las mejores prácticas descritas en los modelos CMMI a través del desarrollo de
una herramienta web que desarrolla el autor del proyecto y que será capaz de
gestionar las preguntas realizadas por SCAMPI, almacenar resultados, analizar y
verificar que practicas se están cumpliendo correctamente de acuerdo al modelo
CMMI-DEV y finalmente mostrar estos resultados.
7
CAPITULO II
2 ELABORACIÓN DEL PROYECTO
2.1 CUERPO DE LA INVESTIGACIÓN
2.1.1 RESUMEN EJECUTIVO DE LA EMPRESA
HISTORIA
La Municipalidad Provincial de Huamanga, entra en vigencia por acuerdo de la
Constitución de 1924, ratificado con la Ley de Municipalidades de 1822, D.L. No 51,
posteriormente por la Ley Orgánica de Municipalidades No 23853 (como Órgano
de Gobierno Local), en épocas de gobiernos no constitucionales algunos Alcaldes
de esta Municipalidad han sido designados por el Gobierno Central y de acuerdo a
la Constitución otros han sido elegidos luego de participar en elecciones
Municipales.
Desde la creación hasta la fecha, el ámbito de jurisdicción de la Municipalidad
Provincial, ha sufrido cambios, en un inicio el gobierno abarcaba toda la Provincia,
porque aún no se creaban los distritos.
Actualmente el ámbito de jurisdicción, como Municipalidad Provincial de
Huamanga, es a nivel de 16 distritos como responsable de promover el desarrollo
y cumpliendo funciones acordes a la Ley Orgánica de Municipalidades. Sin
embargo, como gestión local y pliego es ejercido en distrito capital de Ayacucho.
DESCRIPCION DE LA ORGANIZACIÓN
La Municipalidad Provincial de Huamanga es un gobierno local, que promueve
el desarrollo, brindando servicios públicos de calidad mediante la planificación
participativa y concertada.
GIRO DE NEGOCIO
Orientación básica: promover el desarrollo integral y sostenible de una Huamanga
más humana, segura, ordenada, saludable, turística y productiva
8
MISIÓN
Somos un gobierno local, promotor del desarrollo integral y sostenible de una
Huamanga más humana, segura, ordenada, saludable, turística y productiva,
basados en una gestión municipal, con identidad cultural y de participación vecinal
que brinda servicios de calidad
VISIÓN
Municipalidad sólida, moderna, reconocida por la población por ser eficiente, ágil,
que cuenta con un equipo humano competitivo.
9
ORGANIGRAMA INSTITUCIONAL
Figura 1: ORGANIGRMA DE LA MPH 2017
10
ESTRUCTURA ORGANICA
 SUBGERENCIA DE OBRAS
Responsable de la Ejecución, Evaluación y Monitoreo de los programas,
proyectos y obras que ejecuta la Municipalidad Provincial, cautelando la correcta
utilización de los recursos presupuéstales asignados, generando la información
oportuna sobre el avance físico de los proyectos de inversión.
 LA SUBGERENCIA DE ORDENAMIENTO TERRITORIAL Y CATASTRO

Responsable de formular, actualizar e implementar el Plan de
Acondicionamiento Territorial Provincial, Plan de Desarrollo Urbano y Rural, Plan
de Desarrollo de Asentamiento Humanos, y el Plan de lenificación y Usos de Suelo,
así como elabora, administrar y mantener actualizado el Catastro Municipal.
 SUBGERENCIA DE CENTRO HISTÓRICO

Responsable de las actividades de normar, regular, otorgar y fiscalizar
autorizaciones, derechos y licencias de construcción, remodelación o demolición
de inmuebles, ubicación de avisos publicitarios y propaganda política y
fortalecimiento del proceso del saneamiento físico legal, así como proteger y
conservar el patrimonio histórico, cultural y paisajístico dentro del Centro Histórico
de Ayacucho.
 SUBGERENCIA DE CONTROL URBANO Y LICENCIAS ES LA UNIDAD

Responsable de normar, regular, otorgar y fiscalizar autorizaciones, derechos
y licencias de habilitación urbana, edificación, remodelación o demolición de
inmuebles, ubicación de avisos publicitarios y propaganda política, y fortalecimiento
del proceso del saneamiento físico legal, de predios ubicados fuera del Centro
Histórico.
 SUBGERENCIA DE DERECHOS DE LAS POBLACIONES VULNERABLES

E INCLUSIÓN SOCIAL
Ejerce funciones en materia de desarrollo, inclusión social, igualdad de
oportunidades, responsable de gestionar las actividades relacionadas a la defensa,
11
protección, promoción, atención primaria de la salud y vigilancia de los derechos de
los niños, adolescentes, personas con discapacidad, adultos mayores, mujeres y
personas en situación de vulnerabilidad y riesgo social en la Provincia de
Huamanga.
 SUBGERENCIA DE JUVENTUD, EDUCACIÓN Y DEPORTE

Responsable de impulsar acciones a favor de los jóvenes desde sus distintos
sectores, así como la promoción, difusión y ejecución de las actividades Educativas,
Recreativas y Deportivas.
 SUBGERENCIA DE PROGRAMAS ALIMENTARIOS Y NUTRICIÓN

Responsable de Conducir los Programas de Complementación Alimentaría,
dirigido a la población en situación de riesgo y vulnerabilidad.
 LA SUBGERENCIA DE REGISTRO CIVIL

Responsable de programar, ejecutar y evaluar las acciones del Registro del
Estado Civil.
 SUBGERENCIA DE PARTICIPACIÓN VECINAL Y CIUDADANÍA

Responsable de formular y proponer los objetivos, políticas y estrategias para
la organización y promoción de los vecinos en la participación del desarrollo local.
 SUBGERENCIA DE PROMOCIÓN EMPRESARIAL Y DESARROLLO

RURAL
Responsable de normar, dirigir, ejecutar, supervisar y promover la
productividad y competitividad de la micro y pequeña, empresa y asociaciones de
los sectores económicos productivos y artesanales de las zonas urbanas y rurales
dentro de la Jurisdicción
 SUBGERENCIA DE COMERCIO, LICENCIAS Y FISCALIZACIÓN

Responsable de gestionar, regular y controlar el cumplimiento de las normas
de acopio, distribución, almacenamiento y comercialización de alimentos y bebidas,
comercio ambulatorio, administrar los mercados municipales, autorizar y fiscalizar
12
el funcionamiento de los establecimientos de actividad comercial, industrial y de
servicios, así como también los espectáculos públicos no deportivos en el ámbito
de la jurisdicción.
 SUBGERENCIA DE CULTURA, TURISMO Y ARTESANÍA

Responsable de formular, dirigir, administrar y evaluar la actividad turística
sostenible, artesanal; así como promover y difundir las expresiones culturales, el
patrimonio cultural, la identidad cultural de sus ciudadanos, la promoción del artista
y de las expresiones de cultura viva comunitaria.
 SUBGERENCIA DE ECOLOGÍA Y MEDIO AMBIENTE

Responsable de gestionar el cumplimiento de las actividades concernientes a
promover el manejo, cuidado, protección y conservación del medio ambiente y de
sus recursos naturales en el ámbito de su jurisdicción.
 LA SUBGERENCIA DE DERECHOS DE LAS POBLACIONES

VULNERABLES E INCLUSIÓN SOCIAL
Ejerce funciones en materia de desarrollo, inclusión social, igualdad de
oportunidades, responsable de gestionar las actividades relacionadas a la defensa,
protección, promoción, atención primaria de la salud y vigilancia de los derechos de
los niños, adolescentes, personas con discapacidad, adultos mayores, mujeres y
personas en situación de vulnerabilidad y riesgo social en la Provincia de
Huamanga.
 SUBGERENCIA DE SISTEMAS Y TECNOLOGÍA

Responsable de planear, organizar, dirigir, ejecutar y supervisar el diseño,
implementación y mantenimiento de la infraestructura tecnológica de la Entidad,
fomentando protocolos de comunicación estandarizada.
VISIÓN
Oficina líder en la administración de las tecnologías de información que sirva de
modelo al sistema municipal de Huamanga en el desarrollo, uso y adopción de las
tecnologías de información a la vanguardia en los procesos administrativos;
13
colaborando al desarrollo tecnológico institucional, a través del sostenimiento,
innovación e implementación de sistemas de información de avanzada tecnología.
MISIÓN
Apoyar la gestión administrativa de la Municipalidad Provincial de Huamanga,
utilizando las herramientas que ofrecen las tecnologías de informática y de
telecomunicaciones. Ello se logra mediante el diseño, el desarrollo y la prestación
de servicios de informática y de telecomunicaciones, que satisfagan las
necesidades informáticas, con el propósito de apoyar a los usuarios de manera
eficiente, efectiva, automatizada y oportuna en sus funciones y en los procesos
administrativos, fomentando su aprovechamiento adecuado y velando por su
correcta implementación.
OBJETIVOS
Apoyar a la Municipalidad en la adquisición y el uso de tecnologías de informática
y de telecomunicaciones, para el apoyo a la administración.
Analizar, evaluar, planear, diseñar y ejecutar los proyectos que favorezcan el
desarrollo de la informática y las telecomunicaciones en la Municipalidad.
Crear y mantener un sistema de información institucional integral y consistente, de
apoyo a la toma de decisiones de la Sub Gerencia de Sistemas y Tecnología.
Asesorar en la utilización de servicios de informática y de telecomunicaciones a las
dependencias de la Municipalidad.
Socializar y capacitar a los usuarios en el uso de los servicios de informática y de
telecomunicaciones.
Brindar soporte a nivel de mantenimiento de equipos de cómputo, servicios Internet,
sistemas de información y sistemas de comunicación.
Fomentar y velar por el buen aprovechamiento de los recursos de servicios de
informática y de telecomunicaciones.
Velar por el cumplimiento de estándares, normas y leyes de uso de servicios de
informática y de telecomunicaciones.
14
FUNCIONES DE LA MUNICIPALIDAD PROVINCIAL
a. Planificar integralmente el desarrollo local y el ordenamiento territorial en

el nivel provincial, las municipalidades provinciales son responsables de promover
e impulsar el proceso de planeamiento para el desarrollo integral correspondiente
al ámbito de su provincia, recogiendo las prioridades propuestas en los procesos
de planeación de desarrollo local de carácter distrital.
b. Promover, permanentemente la coordinación estratégica de los planes

integrales de desarrollo distrital.
c. Promover, apoyar y ejecutar proyectos de inversión y servicios públicos

municipalidades que presenten, objetivamente, externalidades o economías de
escala de ámbito provincial.
d. Emitir normas técnicas generales, en materia de organización de espacio

físico y del uso del suelo, así como sobre la protección y conservación del ambiente.
OBJETIVOS ESTRATEGICOS
OBJETIVO ESTRATÉGICO 1:
Lograr que los usuarios reciban una atención adecuada y sin discriminación.
Modernizar la gestión con tecnologías de información y comunicación con la
participación de la población.
OBJETIVO ESTRATÉGICO 02.

Desarrollar servicios que se adapten y respondan a las necesidades de la
población.

Consolidar el liderazgo de la municipalidad en el desarrollo de la Provincia basada
en una gestión de procesos y resultados.
15
Mejorar la productividad de puestos de trabajo y de los trabajadores.
OBJETIVO ESTRATÉGICO 05
Incrementar los recursos financieros de la municipalidad y utilizarlos con eficiencia
y transparencia.
Promover el aprovechamiento de oportunidades y emprendimiento empresarial.
Contribuir de manera efectiva en el clima de negocios de la provincia.
Gestionar la cultura organizacional de manera participativa, motivadora y que
promueva la seguridad ciudadana.
Desarrollar una infraestructura vial adecuada, articulada y policéntrica.
Implementar la gestión ambiental en todos sus programas y proyectos.
Desarrollar la gestión municipal de riesgo de desastres.
OBJETIVOS ESTRATÉGICOS DEL ÁREA DE SISTEMAS Y TECNOLOGÍA

Planear, organizar, dirigir, ejecutar y supervisar el diseño, implementación y
mantenimiento de la infraestructura tecnológica de la Entidad, fomentando
protocolos de comunicación estandarizada.
16
PROCESO DE TRÁMITE DOCUMENTARIO DE LA MPH
3 SISTEMA DE TRAMITE DOCUMENTARIO – SISTDOC
4 SISTDOC
Sistema de Tramite Documentario que maneje la gestión documentaría en la
Municipalidad Provincial de Huamanga desde un trámite que genera un
Administrado bajo el ingreso en Mesa de Partes, Hasta los documentos internos
que generan los trabajadores de la Municipalidad. Administra los Procesos
Externos como:
 TUPA
 RAISA
 NO TUPA
Administra la Comunicación Interna y Generación de documentos por usuario.
Figura 1 Proceso Del trámite documentario en la MPH
17
Figura 2 Proceso de tramite documentario Externo de la MPH
Figura 3 Proceso de tramite documentario Interno de la MPH.
18
Figura 4 MÓDULOS DEL SISTDOC
4.1 OBJETIVOS DEL SISTDOC

El sistema permite monitorear el flujo de los documentos administrativos
dentro de la institución, para una atención más eficiente al administrado.
Soporta a las siguientes gerencias.
1. SUB GERENCIA DE BIENES PATRIMONIALES
Para realizar el trámite de cualquier compra de bienes se realiza lo siguiente:
a. La secretaria recepciona el documento, verifica y registra y deriva al jefe de
área.
b. El jefe de área revisa da proveído y lo deriva.
c. La secretaria recibe el documento lo registra y lo deriva al técnico
administrativo.
d. El técnico administrativo recepciona, realiza la compra hace un reporte y lo
deriva a la secretaria.
e. Se genera un reporte.
19
2. GERENCIA DESARROLLO ECONOMICO Y AMBIENTAL
El tramite documentario que se desarrolla en la gerencia de desarrollo económico
y ambiental es como sigue:
a. La secretaria decepciona el documento, deriva al sub gerente del área.
b. El subgerente revisa y deriva el documento.
c. La secretaria recibe el documento lo registra y lo deriva al técnico de comercio.
d. El técnico de comercio recepciona, y genera un documento y lo deriva a la
secretaria.
e. La secretaria recepciona y deriva al subgerente el documento emitido por el
técnico de comercio.
f. El subgerente revisa el documento y resuelve.
20
3. Oficina de control interno
El trámite documentario del control interno se da de la siguiente manera:
a. La secretaria recepciona, registra y prepara el memorándum, deriva al
responsable y comisión auditora.
b. El responsable y la comisión auditora recepciona, revisan, verifican el PAC y
deriva a la secretaria.
c. La secretaria recibe, registra y deriva al jefe de área.
d. El jefe recepciona, revisa, analiza, corrige, y dispone la presentación de la
comisión.
e. La secretaria recepciona y registra, prepara el informe u oficio
f. Se genera un informe.
21
4. SUBGERENCIA DE REGISTRO CIVIL
El trámite que se hace en la subgerencia de registro civil es como sigue:
a. En mesa de partes se recepciona el documento se revisa y se deriva a la
secretaria de la subgerencia.
b. La secretaria recepciona el documento, registra y lo deriva al sub gerente del
área.
c. El subgerente revisa y deriva el documento a la secretaria.
d. La secretaria recibe el documento lo registra y lo deriva al asistente
administrativo.
e. El asistente administrativo recepciona y proyecta la resolución y lo deriva a la
secretaria.
f. La secretaria recepciona y deriva el documento al registrador y deriva a la
secretaria.
g. El registrador registra la partida revisa y resuelve.
22
4.2 ARQUITECTURA TECNOLOGICA
Nombre Descripción
SQL El lenguaje de consulta estructurado o SQL (por sus siglas en
inglés Structured Query Language) es un lenguaje declarativo de
acceso a bases de datos relacionales que permite especificar
diversos tipos de operaciones en ellas.
Spring El Spring Web no es como otros muchos frameworks web MVC, sino
MVC que está impulsado y diseñado en torno a un Servet central que
distribuye las solicitudes de los controladores y ofrece otras
funcionalidades que facilitan el desarrollo de aplicaciones web.
Html5 HTML5 es un lenguaje markup (de hecho, las siglas de HTML
significan Hyper Text Markup Language) usado para estructurar y
presentar el contenido para la web.
Css3 Las hojas de estilo nos permiten definir de manera eficiente la
representación de nuestras páginas y es uno de los conocimientos
fundamentales que todo diseñador web debe maneja.
JavaScrip JavaScript es un lenguaje de programación que permite el script de
t eventos, clases y acciones para el desarrollo de aplicaciones
23
Internet entre el cliente y el usuario. JavaScript permite con nuevos
elementos dinámicos ir más allá de clicar y esperar en una página
Web. Los usuarios no leerán únicamente las páginas sino que
además las páginas ahora adquieren un carácter interactivo.
Jquery es una biblioteca de JavaScript, creada inicialmente por John Resig,
que permite simplificar la manera de interactuar con los documentos
HTML, manipular el árbol DOM, manejar eventos, desarrollar
animaciones y agregar interacción con la técnica AJAX a páginas
web.
Jquery Es un framework que depende de jQuery al puro estilo jQueryUI que
Mobile busca llevar el ideal de “write less, do more” a los distintos
navegadores a la hora de generar el contenido, aplicando unos
estilos simples e intuitivos, que se asemejan en gran medida a la
interfaz que propone Apple con iOS, sin necesidad de tener que
generar estilos para botones, o barras de navegación que se
adapten a las diferentes resoluciones.
Phonegab PhoneGap es un framework para el desarrollo de aplicaciones
móviles producido por Nitobi, y comprado posteriormente por Adobe
Systems. Principalmente, PhoneGap permite a los programadores
desarrollar aplicaciones para dispositivos móviles utilizando
herramientas genéricas tales como JavaScript, HTML5 y CSS3.
Apache Es un framework de licencia libre que cuenta con muchas Apis de
cordova diversos dispositivos móviles para desarrollar aplicaciones nativas
dentro de un smartphone. Cada vez está tomando más énfasis en
el mundo de los programadores y es que para el desarrollo de las
aplicaciones se utilizan las tecnologías web HTML, CSS y
JavaScript.
4.3 DIAGRAMA DE LA ARQUITECTURA TECNOLOGICA
24
Petición
Capa infraestructura
Respuesta
Petición Respuesta
Seguridad
CAPA DE PRESENTACION
(Html5, Css3, JavaScript, Jquery, Jquery Mobile)
Operaciones
(Logging) CAPA DE LOGICA DE NEGOCIO
Java (Spring MVC)
CAPA DE ACCESO A DATOS

SQL (PostgreSQL)
BD
AGREGAR CUALES SON LOS PROCESOS CRITICOS DE LA ORGANIZACIÓN,

COMO FUNCIONAN, COMO FUCIONA EL AREA DE TRAMITE
DOCUMENTARIO.
25
4.4 METODOLOGÍA CMMI DEV
4.4.1 CMMI
El CMMI consiste en mejores prácticas que abordan el desarrollo y

mantenimiento de productos y servicios, cubriendo su ciclo de vida desde la
concepción hasta la entrega y el mantenimiento.
CMMI integra cuerpos de conocimiento (o disciplinas) que son esenciales al
desarrollar productos, pero han sido abordados separadamente en el pasado.
Integrando estos cuerpos de conocimiento, CMMI provee una solución global para
el desarrollo y mantenimiento de productos y servicios.
Una organización debe seleccionar aquellas disciplinas que correspondan a los

procesos que quiere mejorar. CMMI soporta dos enfoques o representaciones
(escalonadas y continuas).
Una organización debe seleccionar la representación que más se adecue a su

situación. El modelo proporciona un método de apreciación CMMI estándar para
mejora de procesos (SCAMPI).
¿QUÉ ES CMMI?
El CMMI es un modelo de buenas prácticas que ayudan a las organizaciones

a mejorar sus procesos. Estos modelos son desarrollados por equipos de producto
con miembros procedentes de la industria, del gobierno y del Software Engineering
Institute.
Las áreas de proceso se agrupan en cinco niveles de madurez, de modo que una
organización que tenga institucionalizadas todas las prácticas incluidas en un nivel
y sus inferiores.
Importante del uso del modelo para el Desarrollo de Software

La importancia del uso de un modelo radica principalmente en el hecho de
que es precisamente lo que permite comprender cuáles son los elementos
específicos de una organización, a la vez que ayuda a formular y hablar de qué es
lo que se debe mejorar dentro de la misma y de cómo se pueden lograr dichas
26
mejoras. Dicho esto, algunas de las ventajas del uso de un modelo que valen la
pena mencionar son las siguientes:
 Proporciona un marco y un lenguaje común, lo que se traduce en la ruptura de

las barreras de la comunicación en el interior de las organizaciones.
 Permite que los usuarios puedan enfocarse específicamente en la mejora, ya
que ayudan a que no pierdan la idea global.
 Aporta años de experiencia.
 Ayudan a mejorar la satisfacción del cliente.
 Permiten producir productos y servicios de alta calidad.
Beneficios de CMMI
Hacer uso del modelo CMMI para el desarrollo de software, no solo permite
optimizar procesos de negocios, sino que también trae consigo una serie de
beneficios, entre ellos los siguientes:
 La gestión y la ingeniería de las actividades se encuentran entrelazadas de una
manera explícita, tan es así que facilita el reconocimiento de los objetivos del
negocio.
 Permite hacer la incorporación de la experiencia adquirida en otras zonas de las
mejores prácticas. Algunos ejemplos serían la medición, gestión de riesgos y de
proveedores.
 Poder aplicar prácticas de alta madurez mucho más robustas.
 Cumplir de forma mucho más completa con las normas ISO.
4.4.2 CMMI DEV

Es un modelo de referencia que cubre las actividades del desarrollo y
mantenimiento aplicadas tanto a los productos como servicios, el CMMI para el
desarrollo contiene practicas que cubren la gestión de proyectos, la gestión de
procesos, la ingeniería de sistemas, la ingeniería de hardware, la ingeniería de
software, y otros procesos de soporte utilizados en el desarrollo y el mantenimiento.
Existen dos grupos dentro del CMMI están el CMMI + IPPD y CMMI sin IPPD
El CMMI +IPPD abarca el CMMI para desarrollo más todas las adiciones de IPPD,
en cambio el que no comparte el IPPD solo usara el CMMI para el desarrollo.
27
El CMMI permite aproximarse a la mejora de procesos y a las evaluaciones usando
dos representaciones diferentes, la representación continua y la representación por
etapas.
OBJETIVOS GLOBAL DEL CMMI
Proporcionar un marco que comparta las mejores prácticas y aproximaciones
de mejora de procesos de manera coherente, pero lo suficientemente flexible como
para satisfacer las necesidades en constante evolución de la comunidad.
LA REPRESENTACIÓN CONTINÚA
La representación continua permite a una organización seleccionar un área
de procesos y mejorar los procesos relacionados con este, esta representación
utiliza unos niveles de capacidad para caracterizar la mejora concerniente a un área
de proceso individual.
LA REPRESENTACIÓN POR ETAPAS

La representación por etapas utiliza conjuntos predefinidos de áreas de
proceso para definir un camino de mejora para una organización. Este camino de
mejora se caracteriza por diversos niveles de madurez proporcionando un conjunto
de áreas de proceso que caracterizan diferentes comportamientos organizativos.
Esta representación ofrece una manera sistemática y estructurada de aproximarse
a la mejora de procesos basada en el modelo etapa a etapa, el logro de cada etapa
permite escalar a la siguiente etapa.
Esta representación prescribe un orden para implementar las áreas de proceso
según los niveles de madurez, alcanzar un nivel de madurez asegura que se ha
establecido un funcionamiento adecuado para el siguiente nivel de madurez
permitiendo una mejora incremental y duradera.
Ventajas de la representación por etapas

 Permite a las organizaciones tener una trayectoria predefinida y probada de
mejora
 Resume resultados de la mejora de procesos en un simple número de nivel
de madurez.
 Se construye sobre una historia relativamente larga del uso que incluye casos
de estudio y datos que demuestran el retorno de la inversión.
28
 Los niveles de madurez se usan para establecer un objetivo y realizar el
seguimiento de la mejora de procesos.
FACTORES DE DECISIÓN PARA ESCOGER LA REPRESENTACIÓN

Existen tres categorías de factores que influencian en la decisión al
seleccionar la representación, estos son:
 factores de negocio, si la organización tiene un conocimiento maduro acerca
de sus propios objetivos estratégicos es probable que tenga coherencia entre sus
procesos y sus objetivos, a este tipo de organizaciones se le puede aplicar la
representación continua para evaluar sus procesos y determinar si los procesos de
la organización soportan y satisfacen sus objetivos estratégicos de una manera
adecuada.
En el caso de las organizaciones guiadas en base a línea de productos que decide
mejorar sus procesos para toda la organización, podría ser mejor aplicando la
representación por etapas.
La consideración más importante radica en los objetivos estratégicos que se desea
desarrollar en un programa de mejora de procesos y como los objetivos pueden
alinearse con las dos representaciones.
 factores culturales, es la capacidad de una organización para desplegar un

programa de mejora de procesos, si la organización tiene poca experiencia en la
mejora de procesos se puede elegir la representación por etapas, la cual
proporcionara una ayuda adicional sobre el orden en el cual se deben producir los
cambios.
 factores de herencia, es la experiencia que tiene una organización al aplicar un

tipo de representación, si ya se tiene antecedentes de que se ha aplicado, invertido
recursos y desplegado procesos de un tipo de representación entonces lo más
conveniente y lógico es continuar aplicando determinada representación.
APLICACIÓN DEL CMMI AL SOFTWARE DE SUBSISTEMA DE TRAMIE

DOCUMENTARIO INTERNO DE LA MUNICIPALIDAD PROVINCICAL DE
HUAMANGA
29
Se ha decidido aplicar la representación por etapas porque ofrece una manera
sistemática y estructurada de aproximarse a la mejora de procesos basada en el
modelo etapa a etapa, el logro de cada etapa permite escalar a la siguiente etapa
y además se aplica a organizaciones donde la organización tiene poca experiencia
en la mejora de procesos.
Comprendiendo los niveles de madurez
Un nivel de madurez consta de prácticas relacionadas específicas y genéricas para
un conjunto predefinido de áreas de proceso que mejoran el rendimiento global de
la organización, el nivel de madurez de una organización proporciona un camino
para predecir el rendimiento en una disciplina dada o un conjunto de disciplinas.
Cada nivel de madurez madura un subconjunto importante de procesos de la
organización, reparándola para pasar al siguiente nivel de madures, los niveles de
madurez se miden mediante el logro de metas específicas y genéricas asociadas a
cada conjunto predefinido de áreas de proceso.
Existen 5 niveles de madurez, siendo cada una de ellas una capa de cimentación
de la mejora de procesos en curso.
Figura 5 Nivel de madurez de CMMI
Nivel 5 Optimizar
Nivel 4 Administrado Cuantitativamente
Nivel 3 Definido
Nivel 2 Administrado
Nivel 1 Inicial
Nivel de Madurez 1: Inicial

El éxito en estas organizaciones depende de la competencia y heroicidad del
personal de la organización y no del uso de procesos probados, a pesar de los
problemas que se puedan presentar, las organizaciones producen productos y
servicios que funcionan; sin embargo, frecuentemente exceden sus presupuestos
y no cumplen sus calendarios.
Nivel de Madurez 2: Gestionado
30
Los proyectos de la organización han asegurado que los procesos se
planifican y realizan de acuerdo a políticas, los proyectos emplean personal con
habilidad que dispone de recursos adecuados para producir resultados controlados,
involucran las partes interesadas relevantes, monitorizan, controlan, revisan y
evalúan en cuanto a las descripciones de su proceso.
Se deberían establecer compromisos entre las partes interesadas relevantes y se
revisan, según sea necesario. Los productos de trabajo se controlan de forma
apropiada de acuerdo a las descripciones de procesos especificadas.
Nivel de Madurez 3: Definido

Los procesos son bien caracterizados y comprendidos, se describen en
estándares, procedimientos, herramientas y métodos, se aplican la consistencia de
los procesos estándar para establecer la consistencia en toda la organización, en
este nivel los procedimientos del proyecto son más consistentes.
Los procesos se gestionan más proactivamente utilizando una comprensión de las
interrelaciones de las actividades del proceso y las medidas del proceso, sus
productos de trabajo y servicio.
En este nivel las organizaciones deben madurar más las áreas de procesos del
nivel de madurez 2, para lograr este nivel de madurez se aplican prácticas
genéricas asociadas con la meta genérica 3 que no fueron tratadas en el nivel de
madurez 2.
En este nivel los procesos son generalmente predecibles cualitativamente.
Nivel de Madurez 4: Gestionado Cuantitativamente.

La organización y los proyectos establecen objetivos cuantitativos en cuanto
al rendimiento de calidad y del proceso, y los utilizan como criterios en la gestión
de los procesos, los objetivos cuantitativos se basan en las necesidades del cliente,
usuarios finales, organización e implementación del proceso.
El rendimiento de calidad y de proceso se comprende en términos estadísticos y se
gestionan durante la vida de los procesos.
Las medidas de rendimiento de calidad y del proceso se incorporan en el repositorio
de medición de la organización, para dar soporte a la toma de decisiones basada
en hechos.
31
Se deben identificar las causas especiales de variación para corregir las fuentes de
las causas especiales para prevenir sus futuras ocurrencias.
Una distinción crítica entre los niveles de madurez 3 y4 es la predictibilidad del
rendimiento de proceso.
En conclusión, en este nivel de madures el rendimiento de los procesos se controla
utilizado técnicas estadísticas y otras técnicas cuantitativas, y es predecibles
cuantitativamente.
Nivel de Madurez 5: En Optimización.

La organización mejora continuamente sus procesos basándose en una
comprensión cuantitativa de las causas comunes de variación inherentes a los
procesos.
Este nivel se centra en mejorar continuamente el rendimiento de procesos mediante
mejoras incrementales e innovadoras de proceso y tecnología, los objetivos
cuantitativos de mejora de procesos se establecen, se revisan continuamente para
reflejar el cambio a los objetivos del negocio, y se utilizan como criterios para la
mejora de procesos, luego los efectos de las mejoras de los procesos se deben
evaluar frente a los objetivos cuantitativos de mejora de procesos.
En este nivel la organización se interesa en tratar las causas comunes de variación
del proceso y en cambiar el proceso para cambiar las medias de rendimiento del
proceso o reducir las variaciones inherentes del proceso experimentado, para
mejorar el rendimiento del proceso y para alcanzar sus objetivos cuantitativos de
mejora de procesos establecidos.
A medida que la organización logra las metas genéricas y específicas para el

conjunto de áreas de proceso en un nivel de madurez, aumenta su madurez
organizativa y recoge los beneficios de la mejora de procesos, dado que cada nivel
de madurez forma una base necesaria para el siguiente nivel, tratar de saltar niveles
de madurez es generalmente contraproducente.
METAS GENÉRICAS Y PRÁCTICAS GENÉRICAS
32
Las metas específicas y genéricas ofrecen un resumen de alto nivel de los
objetivos específicos y practicas específicas. La meta específica y práctica resumen
es un componente informativo.
El texto completo de las metas genéricas y de las prácticas genéricas no se repite
en las áreas de proceso (es decir, se omiten las su prácticas, las notas, los ejemplos
y las referencias). En cambio, sólo aparecen los títulos y las declaraciones de la
meta genérica y de la práctica genérica. Cuando trate cada área de proceso,
consúltese esta para ver los detalles de todas las prácticas genéricas.
SG: Meta especifica
GG: Meta genérica
SP: Practica específica
GP: Practica genéricas
1. METAS GENERICAS (Generic Goals)

Metas que se denominan genéricas debido a que aparecen en varias áreas
de proceso. El logro de una meta genérica en un proceso significa control mejorado
en planeación e implementación de los procesos asociados con el área de proceso.
2. PRACTICAS GENERICAS (Generic Practices)

Buscan la institucionalización para asegurar que los procesos asociados al
área de proceso sean eficaces, reutilizables y durables. Las prácticas genéricas
son categorizadas por las metas genéricas y las características comunes.
3. METAS ESPECIFICAS (Specific goals)

Las metas específicas se aplican o definen sobre un área de proceso y se
ocupan de describir las características únicas que deben ser implementadas para
satisfacer el área de proceso.
4. PRACTICAS ESPECIFICAS (Specific Practices)

Es la descripción de una actividad que se considera importante para alcanzar
el objetivo específico asociado. Las prácticas específicas describen las actividades
que se esperan como resultado en el logro de los objetivos específicos de un área
de proceso.
33
COMPONENTES DEL AREA DE PROCESO
Un área de procesos es un grupo de prácticas relacionadas en una rea que,
cuando se implementan de forma conjunta, satisfacen un grupo de objetivos
considerados importantes para la mejora de esa área.
GESTIÓN DE REQUERIMIENTOS (REQM)

Un área de proceso de Ingeniería en el nivel de madurez 2
El propósito de la Gestión de requerimientos (REQM) es gestionar los
requerimientos de los productos y de los componentes del producto del proyecto, e
identificar inconsistencias entre esos requerimientos y los planes y productos de
trabajo del proyecto.
Los procesos de gestión de requerimientos gestionan todos los requerimientos
recibidos o generados por el proyecto, incluyendo tanto requerimientos técnicos
como no técnicos, así como aquellos requerimientos impuestos al proyecto por la
organización. En particular, si se implementa el área de proceso de Desarrollo de
requerimientos, sus procesos generarán requerimientos de producto y de
componentes del producto que también serán gestionados por los procesos de
gestión de requerimientos.
Durante las áreas de proceso, donde se usan los términos producto y componentes
del producto, sus significados previstos también comprenden los servicios y sus
componentes. Cuando las áreas de proceso de Gestión de requerimientos, de
Desarrollo de requerimientos y de Solución técnica se implementan todas, sus
procesos asociados pueden estar estrechamente ligados y ser realizados de forma
concurrente.
El proyecto toma las medidas apropiadas para asegurar que el conjunto de
requerimientos acordados se gestiona para dar soporte a las necesidades de
planificación y de realización del proyecto. Cuando un proyecto recibe
requerimientos de un proveedor de requerimientos aprobado, se revisan éstos con
el proveedor de requerimientos para resolver los problemas y para prevenir
malentendidos antes de que los requerimientos se incorporen en los planes del
proyecto. Una vez que el proveedor y el receptor de los requerimientos alcanzan
un acuerdo, se obtiene un compromiso sobre los requerimientos por parte de los
participantes en el proyecto. El proyecto gestiona los cambios a los requerimientos
34
a medida que evolucionan e identifica cualquier inconsistencia que ocurra entre los
planes, los productos de trabajo y los requerimientos.
Parte de la gestión de requerimientos es documentar los cambios a los

requerimientos y la razón, y mantener trazabilidad bidireccional entre los
requerimientos fuente y todos los requerimientos de producto y de componentes
del producto.
Todos los proyectos de desarrollo tienen requerimientos. En el caso de un proyecto
que se enfoque en actividades de mantenimiento, los cambios al producto o a los
componentes del producto se basan en los cambios existentes a los
requerimientos, al diseño o a la implementación.
Los cambios de los requerimientos, si existen, podrían documentarse en peticiones
de cambio del cliente o de los usuarios, o podrían tomar la forma de nuevos
requerimientos recibidos del proceso de desarrollo de requerimientos.
Independientemente de su fuente o forma, las actividades de mantenimiento que
son conducidas por los cambios a los requerimientos se gestionan
consecuentemente.
Resumen de Metas y prácticas específicas

SG 1 Gestionar los requerimientos.
SP 1.1 Obtener una comprensión de los requerimientos.
SP 1.2 Obtener el compromiso sobre los requerimientos.
SP 1.3 Gestionar los cambios de los requerimientos.
SP 1.4 Mantener la trazabilidad bidireccional de los requerimientos.
SP 1.5 Identificar las inconsistencias entre el trabajo del proyecto y los
requerimientos.
Prácticas específicas por meta

SG 1 GESTIONAR LOS REQUERIMIENTOS
Los requerimientos son gestionados y las inconsistencias con los planes y con
los productos de trabajo del proyecto son identificadas.
El proyecto mantiene un conjunto actual y aprobado de requerimientos durante la
vida del proyecto mediante:
 La gestión de todos los cambios a los requerimientos.
35
 El mantenimiento de las relaciones entre los requerimientos, los planes del
proyecto y los productos de trabajo.
 La identificación de las inconsistencias entre los requerimientos, los planes del
proyecto y los productos de trabajo.
 La toma de acciones correctivas.
SP 1.1 OBTENER UNA COMPRENSIÓN DE LOS REQUERIMIENTOS

Desarrollar una comprensión del significado de los requerimientos con los
proveedores de los requerimientos.
A medida que el proyecto madura y se derivan los requerimientos, todas las
actividades o disciplinas recibirán requerimientos. Para evitar el flujo continuo de
requerimientos, se establecen criterios para designar los canales apropiados, o las
fuentes oficiales, de las cuales recibir requerimientos. Las actividades de recepción
conducen al análisis de los requerimientos con el proveedor de los requerimientos
para asegurar que se alcanza una comprensión compatible y compartida del
significado de los requerimientos. El resultado de este análisis y diálogo es un
conjunto acordado de requerimientos.
SP 1.2 OBTENER EL COMPROMISO SOBRE LOS REQUERIMIENTOS

Obtener el compromiso de los participantes de proyecto sobre los
requerimientos. Cuando se crean equipos integrados, los participantes del proyecto
son los equipos integrados y sus miembros. El compromiso sobre los
requerimientos para interactuar con otros equipos integrados es tan importante para
cada equipo integrado como sus compromisos con el producto y con otros
requerimientos del proyecto.
SP 1.3 GESTIONAR LOS CAMBIOS DE LOS REQUERIMIENTOS

Gestionar los cambios a los requerimientos a medida que evolucionan durante
el proyecto. Durante el proyecto, los requerimientos cambian por una variedad de
razones. A medida que las necesidades cambian y el trabajo avanza, se derivan
requerimientos adicionales y es posible que se tengan que hacer cambios a los
requerimientos existentes. Es esencial gestionar estas adiciones y cambios,
eficiente y eficazmente. Para analizar con eficacia el impacto de los cambios, es
necesario que se conozca la fuente de cada requerimiento y que la razón para
36
cualquier cambio esté documentada. Sin embargo, el jefe de proyecto puede querer
seguir medidas apropiadas de volatilidad de los requerimientos para juzgar si son
necesarios controles nuevos o corregidos.
SP 1.4 MANTENER LA TRAZABILIDAD BIDIRECCIONAL DE LOS

REQUERIMIENTOS
Mantener la trazabilidad bidireccional entre los requerimientos y los productos
de trabajo. La intención de esta práctica específica es mantener la trazabilidad
bidireccional de los requerimientos para cada nivel de descomposición del
producto. Cuando los requerimientos se gestionan bien, la trazabilidad puede
establecerse desde el requerimiento fuente hasta sus requerimientos de más bajo
nivel y desde los requerimientos de más bajo nivel de vuelta hasta su fuente. Esta
trazabilidad bidireccional ayuda a determinar que todos los requerimientos fuente
se han tratado totalmente y que todos los requerimientos de nivel más bajo pueden
trazarse hacia una fuente válida. La trazabilidad de los requerimientos también
puede cubrir las relaciones a otras entidades, tales como productos de trabajo
intermedios y finales, cambios en la documentación de diseño y planes de pruebas.
La trazabilidad puede cubrir relaciones horizontales, tales como entre interfaces,
así como relaciones verticales. La trazabilidad se necesita particularmente cuando
se lleva a cabo la evaluación del impacto de los cambios de los requerimientos
sobre las actividades y los productos de trabajo del proyecto.
SP 1.5 IDENTIFICAR LAS INCONSISTENCIAS ENTRE EL TRABAJO DEL

PROYECTO Y LOS REQUERIMIENTOS
Identificar las inconsistencias entre los planes del proyecto, los productos de
trabajo y los requerimientos.
Esta práctica específica encuentra las inconsistencias entre los requerimientos, los
planes del proyecto y los productos de trabajo e inicia la acción correctiva para
corregirlas.
PLANIFICACION DE PROYECTO (PP)

El propósito de la Planificación de proyecto (PP) es establecer y mantener
planes que definan las actividades del proyecto.
El área de proceso de Planificación de proyecto implica:
37
• Desarrollar el plan del proyecto.
• Interactuar con las partes interesadas de forma apropiada.
• Obtener el compromiso con el plan.
• Mantener el plan.
La planificación comienza con los requerimientos que definen el producto y el
proyecto.
La planificación incluye la estimación de los atributos de los productos de trabajo y
de las tareas, la determinación de los recursos necesarios, la negociación de los
compromisos, la elaboración de un calendario, y la identificación y el análisis de los
riesgos del proyecto.
Para establecer el plan del proyecto, puede ser necesario realizar iteraciones sobre
estas actividades. El plan del proyecto proporciona la base para realizar y controlar
las actividades del proyecto dirigidas a los compromisos con el cliente del proyecto.
El término “plan del proyecto” se usa durante todas las prácticas genéricas y
específicas en esta área de proceso para referirse al plan global para controlar el
proyecto.
RESUMEN DE METAS Y PRÁCTICAS ESPECÍFICAS
SG 1 ESTABLECER ESTIMACIONES
SP 1.1 Estimar el alcance del proyecto.
SP 1.2 Establecer las estimaciones de los atributos del producto de trabajo y de las
tareas.
SP 1.3 Definir el ciclo de vida del proyecto.
SP 1.4 Determinar las estimaciones de esfuerzo y de coste.
SG 2 DESARROLLAR UN PLAN DE PROYECTO

SP 2.1 Establecer el presupuesto y el calendario.
SP 2.2 Identificar los riesgos del proyecto.
SP 2.3 Planificar la gestión de los datos.
SP 2.4 Planificar los recursos del proyecto.
SP 2.5 Planificar el conocimiento y las habilidades necesarias.
SP 2.6 Planificar la involucración de las partes interesadas.
SP 2.7 Establecer el plan de proyecto.
38
SG 3 OBTENER EL COMPROMISO CON EL PLAN
SP 3.1 Revisar los planes que afectan al proyecto.
SP 3.2 Reconciliar los niveles de trabajo y de recursos.
SP 3.3 Obtener el compromiso con el plan.
PRÁCTICAS ESPECÍFICAS POR META

Las estimaciones de los parámetros de la planificación del proyecto son
establecidas y mantenidas.
Los parámetros de la planificación del proyecto incluyen toda la información
necesaria para realizar la necesaria planificación, organización, asignación de
personal, dirección, coordinación, información y preparación de presupuestos.
SP 1.1 Estimar el alcance del proyecto

Establecer una estructura de descomposición del trabajo (WBS) de alto nivel
para estimar el alcance del proyecto.
La WBS debería permitir la identificación de los siguientes elementos:
• Riesgos identificados y sus tareas de mitigación.
• Tareas para los entregables y las actividades de soporte.
• Tareas para la adquisición de habilidades y conocimiento.
• Tareas para el desarrollo de planes de soporte necesarios, tales como los planes
de gestión de la configuración, de aseguramiento de la calidad y de verificación.
• Tareas para la integración y la gestión de los elementos que no son de desarrollo.
SP 1.2 Establecer las estimaciones de los atributos del producto de trabajo y

de las tareas
Establecer y mantener las estimaciones de los atributos de los productos de
trabajo y de las tareas. Las estimaciones deberían ser consistentes con los
requerimientos del proyecto para determinar el esfuerzo, el coste y el calendario
del proyecto. Para cada atributo de tamaño, debería asignarse un nivel relativo de
dificultad o complejidad.
39
SP 1.3 Definir el ciclo de vida del proyecto
Definir las fases del ciclo de vida del proyecto en las que encuadrar el esfuerzo
de la planificación. La determinación de las fases del ciclo de vida del proyecto
proporciona periodos planificados de evaluación y de toma de decisiones. Éstos
normalmente se definen para dar soporte a los puntos lógicos de decisión, en los
cuales se realizan los compromisos significativos, en relación a los recursos y al
planteamiento técnico. Tales puntos proporcionan eventos planificados en los que
se pueden realizar correcciones sobre el curso del proyecto, y determinaciones de
futuros alcances y costes.
SP 1.4 Determinar las estimaciones de esfuerzo y de coste

Estimar el esfuerzo y el coste del proyecto para los productos de trabajo y
para las tareas, basándose en estimaciones razonadas.
Las estimaciones de esfuerzo y de coste generalmente están basadas en los
resultados del análisis usando modelos o datos históricos aplicados al tamaño,
actividades y otros parámetros de la planificación. La confianza en estas
estimaciones está basada en el razonamiento sobre el modelo seleccionado y la
naturaleza de los datos. Pueden existir ocasiones donde los datos históricos
disponibles no se puedan aplicar, tales como cuando los esfuerzos no tengan
precedentes o cuando el tipo de tarea no encaje con los modelos disponibles. Un
esfuerzo no tiene precedentes (hasta cierto punto) si nunca ha sido desarrollado un
producto o componente similar. Un esfuerzo puede también no tener precedentes
si el grupo de desarrollo nunca ha realizado tal producto o componente.

Un plan de proyecto es establecido y mantenido como la base para gestionar
el proyecto. Es un documento formal, aprobado, que se usa para gestionar y
controlar la ejecución del proyecto. Está basado en los requerimientos del proyecto
y en las estimaciones establecidas.
Algunos recursos de infraestructura son:
• Recursos críticos de cómputo (p. ej., memoria, capacidad en disco y de red,
periféricos, canales de comunicación y las capacidades de éstos).
• Entornos y herramientas de ingeniería (p. ej., herramientas para el prototipo,
ensamblaje, diseño asistido por computador (CAD) y simulación).
40
• Instalaciones, maquinaria y equipamiento (p. ej., bancos de pruebas y dispositivos
de grabación). El plan del proyecto debería considerar todas las fases del ciclo de
vida del proyecto. La planificación del proyecto debería asegurar que todos los
planes que afectan al proyecto sean consistentes con el plan global del proyecto.
SP 2.1 Establecer el presupuesto y el calendario

El presupuesto y el calendario del proyecto están basados en las estimaciones
desarrolladas y aseguran que se da un tratamiento adecuado a la asignación del
presupuesto, la complejidad de las tareas y las dependencias entre éstas.
SP 2.2 Identificar los riesgos del proyecto

Los riesgos se identifican o descubren y se analizan para dar soporte a la
planificación del proyecto. Para asegurar que todas las partes interesadas están
interactuando adecuadamente sobre los riesgos identificados, esta práctica
específica debería ampliarse a todos los planes que afecten al proyecto. La
identificación y el análisis de riesgos en la planificación del proyecto normalmente
incluyen:
• La identificación de los riesgos.
• El análisis de los riesgos para determinar el impacto, la probabilidad de ocurrencia
y el marco temporal en el cual es probable que ocurran los problemas.
• La asignación de prioridad a los riesgos.
SP 2.3 Planificar la gestión de los datos

Los requerimientos de datos para el proyecto deberían establecerse tanto
para los elementos de datos a crear como para su contenido y forma, basándose
en un conjunto común o estándar de requerimientos de datos. Los requerimientos
de contenido y de formato uniformes para los elementos de datos facilitan la
comprensión de su contenido y ayudan a una gestión consistente de los recursos
de los datos.
SP 2.4 Planificar los recursos del proyecto

Los procesos usados para gestionar un proyecto deben identificarse, definirse
y coordinarse con todas las partes interesadas relevantes para asegurar
operaciones eficientes durante la ejecución del proyecto.
41
SP 2.5 Planificar el conocimiento y las habilidades necesarias
La entrega de conocimiento a los proyectos implica tanto la formación del
personal del proyecto como la adquisición de conocimiento desde fuentes externas.
Los requerimientos de personal dependen del conocimiento y de las habilidades
disponibles para dar soporte a la ejecución del proyecto.
SP 2.6 Planificar la involucración de las partes interesadas
Las partes interesadas se identifican en todas las fases del ciclo de vida del
proyecto mediante la identificación del tipo de personas y funciones que requieren
de una representación en el proyecto y la descripción de su importancia y del grado
de interacción para las actividades específicas del proyecto. Un formato
conveniente para lograr esta identificación es una matriz bidimensional con las
partes interesadas a lo largo de un eje y las actividades del proyecto a lo largo del
otro. La relevancia de la parte interesada con la actividad en una fase particular de
proyecto y la cantidad de interacción esperada deberían mostrarse en la
intersección del eje de la actividad de la fase del proyecto y el eje de las partes
interesadas.
SP 2.7 Establecer el plan de proyecto

Para alcanzar la comprensión mutua, el compromiso y el rendimiento de las
personas, grupos y organizaciones que deben ejecutar o dar soporte a los planes
es necesario un plan documentado que trate todo el elemento relevante de
planificación. El plan generado para el proyecto define todos los aspectos del
esfuerzo, uniendo todo de una manera lógica: consideraciones sobre el ciclo de
vida del proyecto; tareas técnicas y de gestión; presupuestos y calendarios; hitos;
gestión de datos, identificación de riesgos, requerimientos de recursos y
habilidades; e identificación e interacción de partes interesadas. Las descripciones
de infraestructura incluyen relaciones de responsabilidad y de autoridad para el
personal del proyecto, la gerencia y las organizaciones de soporte.

Para ser eficaces, los planes requieren el compromiso de aquellos que son
responsables de implementar y dar soporte al plan.
42
SP 3.1 Revisar los planes que afectan al proyecto
Los planes desarrollados dentro de otras áreas de proceso normalmente
contendrán información similar a la referenciada en el plan global del proyecto.
Estos planes pueden proporcionar una guía detallada adicional y deberían ser
compatibles con y dar soporte al plan global del proyecto para indicar quién tiene la
autoridad, la responsabilidad, da cuenta y control. Todos los planes que afectan al
proyecto deberían revisarse para asegurar una comprensión común del alcance,
objetivos, roles y relaciones que son requeridas para que el proyecto tenga éxito.
Muchos de estos planes se describen por la práctica genérica.
SP 3.2 Reconciliar los niveles de trabajo y de recursos

Para establecer un proyecto que sea factible, obtenga el compromiso de las
partes interesadas relevantes y reconcilie cualquier diferencia entre los recursos
estimados y los disponibles. La reconciliación normalmente se logra disminuyendo
o aplazando los requerimientos de rendimiento técnico, negociando más recursos,
encontrando formas de incrementar la productividad, subcontratando, ajustando la
mezcla de las habilidades del personal, o revisando todos los planes que afectan al
proyecto o a los calendarios.
SP 3.3 Obtener el compromiso con el plan.

Obtener el compromiso implica la interacción entre todas las partes
interesadas relevantes, tanto internas como externas al proyecto. El individuo o
grupo que hace un compromiso debería tener la confianza de que el trabajo puede
ejecutarse dentro de las restricciones de coste, de calendario y de rendimiento. A
menudo, un compromiso provisional resulta adecuado para permitir que el esfuerzo
comience y que se investigue para incrementar la confianza al nivel apropiado
necesario para obtener un compromiso completo.
MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC)

El propósito de la Monitorización y control de proyecto (PMC) es proporcionar
una comprensión del progreso del proyecto para que se puedan tomar las acciones
correctivas apropiadas, cuando el rendimiento del proyecto se desvíe
significativamente del plan. El término “plan de proyecto” se usa en todas estas
prácticas para hacer referencia al plan global para controlar el proyecto.
43
SG 1 Monitorizar el proyecto frente al plan
SP 1.1 Monitorizar los parámetros de planificación del proyecto.
SP 1.2 Monitorizar los compromisos.
SP 1.3 Monitorizar los riesgos del proyecto.
SP 1.4 Monitorizar la gestión de datos.
SP 1.5 Monitorizar la involucración de las partes interesadas.
SP 1.6 Llevar a cabo revisiones de progreso.
SP 1.7 Llevar a cabo revisiones de hitos.
SG 2 Gestionar las acciones correctivas hasta su cierre

SP 2.1 Analizar problemas.
SP 2.2 Llevar a cabo las acciones correctivas.
SP 2.3 Gestionar las acciones correctivas.

SG 1 MONITORIZAR EL PROYECTO FRENTE AL PLAN
El rendimiento y el progreso real del proyecto son monitorizados frente al plan
del proyecto.
SP 1.1 Monitorizar los parámetros de planificación del proyecto
Los parámetros de la planificación del proyecto constituyen indicadores típicos
del progreso y del rendimiento del proyecto, e incluyen atributos de los productos
de trabajo y tareas, coste, esfuerzo y calendario.
Los atributos de los productos de trabajo y de las tareas incluyen elementos tales
como tamaño, complejidad, peso, forma, ajuste o función.
La monitorización normalmente involucra la medición de los valores reales de los
parámetros de la planificación del proyecto, la comparación de los valores reales
con los estimados en el plan, y la identificación de desviaciones significativas.
Registrar los valores reales de los parámetros de planificación del proyecto incluye
el registro de la información contextual asociada que ayuda a comprender las
medidas. En la segunda meta específica y sus prácticas específicas de este área
de proceso, se maneja un análisis del impacto que tienen las desviaciones
significativas para determinar qué acciones correctivas tomar.
44
SP 1.2 Monitorizar los compromisos
Monitorizar los compromisos frente a aquellos identificados en el plan de
proyecto. Lo cual se da por lo siguiente:
1. Revisar los compromisos (tanto internos como externos) con regularidad.
2. Identificar los compromisos que no han sido satisfechos o que están en riesgo
significativo de no ser satisfechos.
3. Documentar los resultados de las revisiones de los compromisos
SP 1.3 Monitorizar los riesgos del proyecto

Monitorizar los riesgos frente a aquellos identificados en el plan de proyecto.
Para ello se debe revisar periódicamente la documentación de los riesgos en el
contexto del estado y de las circunstancias actuales del proyecto, Corregir la
documentación de los riesgos, a medida que se va disponiendo de información
adicional, para incorporar los cambios, Comunicar el estado de los riesgos a las
partes interesadas relevantes.
SP 1.4 Monitorizar la gestión de datos

Monitorizar la gestión de los datos del proyecto frente al plan de proyecto. Una
vez que los planes para la gestión de los datos del proyecto se realizan, la gestión
de esos datos debe monitorizarse para asegurar que se cumplen esos planes.
SP 1.5 Monitorizar la involucración de las partes interesadas

Monitorizar la involucración de las partes interesadas frente al plan de
proyecto. Una vez que han sido identificadas las partes interesadas y se especifica
la extensión de su involucración dentro del proyecto en su planificación, esa
involucración debe monitorizarse para asegurar que están ocurriendo las
interacciones adecuadas.
SP 1.6 Llevar a cabo revisiones de progreso

Revisar periódicamente el progreso, el rendimiento y los problemas del
proyecto. Las revisiones de progreso son revisiones sobre un proyecto para
mantener informadas a las partes interesadas. Estas revisiones del proyecto
pueden ser revisiones informales y pueden no estar especificadas explícitamente
en los planes de proyecto.
45
SP 1.7 Llevar a cabo revisiones de hitos
Revisar los logros y los resultados del proyecto en los hitos seleccionados del
proyecto. Las revisiones de los hitos se planifican durante la planificación del
proyecto y son normalmente revisiones formales.
SG 2 Gestionar las acciones correctivas hasta su cierre

Las acciones correctivas son gestionadas hasta su cierre cuando el
rendimiento o los resultados del proyecto se desvían significativamente del plan.
SP 2.1 Analizar problemas

Recoger y analizar los problemas y determinar las acciones correctivas
necesarias para tratarlos, los problemas se recogen de las revisiones y de la
ejecución de otros procesos, y la acción correctiva se requiere cuando el problema,
si se deja sin resolver, puede impedir al proyecto cumplir sus objetivos.
SP 2.2 Llevar a cabo las acciones correctivas

Llevar a cabo acciones correctivas sobre los problemas identificados, y
determinar, documentar las acciones apropiadas necesarias para tratar los
problemas identificados.
Las acciones potenciales son:
• Modificar la declaración de trabajo.
• Modificar los requerimientos.
• Corregir las estimaciones y los planes.
• Renegociar los compromisos.
• Añadir recursos.
• Cambiar los procesos.
• Corregir los riesgos del proyecto.
SP 2.3 Gestionar las acciones correctivas.

Gestionar las acciones correctivas hasta su cierre y monitorizar las acciones
correctivas hasta su terminación luego analizar los resultados de las acciones
correctivas para determinar su eficacia, determinar y documentar las acciones
apropiadas para corregir las desviaciones de los resultados planificados para las
acciones correctivas. Las lecciones aprendidas como resultado de tomar una
46
acción correctiva pueden ser entradas a los procesos de planificación y de gestión
de riesgos.
GESTIÓN DE ACUERDOS CON PROVEEDORES (SAM)

El propósito de la Gestión de acuerdos con proveedores (SAM) es gestionar
la compra de productos.
El área de proceso de Gestión de acuerdos con proveedores involucra:
 Determinar el mecanismo de compra.
 Seleccionar los proveedores.
 Establecer y mantener los acuerdos con los proveedores.
 Realizar el acuerdo del proveedor.
 Monitorizar los procesos del proveedor.
 Evaluar los productos suministrados por el proveedor.
 Aceptar la entrega de los productos adquiridos.
 Entregar los productos al proyecto.
Esta área de proceso trata principalmente la compra de los productos y de los
componentes del mismo que se entregan al cliente del proyecto.
En todas las áreas de proceso donde usamos los términos producto y componente
de producto, sus significados previstos engloban también a los servicios y a sus
componentes.
Para minimizar los riesgos del proyecto, esta área de proceso puede tratar también
la compra de productos y de componentes del producto importantes no entregados
al cliente del proyecto, pero usados para desarrollar y mantener el producto o
servicio (por ejemplo, herramientas de desarrollo y entornos de prueba).
Normalmente, los productos a adquirir por el proyecto se determinan durante las
etapas iniciales de la planificación y del desarrollo del producto. El área de proceso
de Solución técnica proporciona soluciones para determinar los productos y los
componentes del producto que pueden adquirirse de los proveedores.
Esta área de proceso no trata directamente los acuerdos en los cuales el proveedor
está integrado en el equipo del proyecto y usa los mismos procesos e informes para
la misma gestión como los desarrolladores del producto (por ejemplo, equipos
integrados).
Normalmente, estas situaciones se tratan por otros procesos o funciones,
posiblemente externas al proyecto, aunque algunas de las prácticas específicas de
47
esta área de proceso pueden ser útiles en la gestión del acuerdo formal con tal
proveedor.
SG 1 Establecer los acuerdos con proveedores.
SP 1.1 Determinar el tipo de compra.
SP 1.2 Seleccionar los proveedores.
SP 1.3 Establecer los acuerdos con el proveedor.
SG 2. Satisfacer los acuerdos del proveedor.
SP 2.1 Realizar el acuerdo del proveedor.
SP 2.2 Monitorizar los procesos seleccionados del proveedor.
SP 2.3 Evaluar los productos de trabajo seleccionados del proveedor.
SP 2.4 Aceptar los productos adquiridos.
SP 2.5 Transferir los productos.

SG 1 ESTABLECER LOS ACUERDOS CON PROVEEDORES
Se establecen y mantienen los acuerdos con los proveedores.
SP 1.1 DETERMINAR EL TIPO DE COMPRA
Determinar el tipo de compra para cada producto o componente del producto
a adquirirse.
SP 1.2 SELECCIONAR LOS PROVEEDORES
Seleccionar los proveedores en base a una evaluación de su capacidad para
cumplir los requerimientos especificados y los criterios establecidos.
SP 1.3 ESTABLECER LOS ACUERDOS CON EL PROVEEDOR
Establecer y mantener los acuerdos formales con el proveedor.
SG 2 SATISFACER LOS ACUERDOS DEL PROVEEDOR
Los acuerdos con los proveedores deben satisfacer tanto al proyecto como al
proveedor.
SP 2.1 REALIZAR EL ACUERDO DEL PROVEEDOR
Desarrollar las actividades tal y como se especifican en el acuerdo suscrito
con el proveedor.
SP 2.2 MONITORIZAR LOS PROCESOS SELECCIONADOS DEL PROVEEDOR
Seleccionar, monitorizar y analizar los procesos del proveedor que son
aplicables en la colaboración establecida.
48
SP 2.3 EVALUAR LOS PRODUCTOS A MEDIDA SELECCIONADOS DEL
PROVEEDOR
Seleccionar y evaluar los productos hechos a medida por el proveedor.
SP 2.4 ACEPTAR LOS PRODUCTOS ADQUIRIDOS
Asegurar que el acuerdo establecido con el proveedor se cumple antes de
aceptar el producto adquirido.
SP 2.5 TRANSFERIR LOS PRODUCTOS
Transferir los productos adquiridos del proveedor al proyecto.
MEDICION Y ANALISIS (MA)

El propósito de la Medición y análisis (MA) es desarrollar y sustentar una
capacidad de medición que se utiliza para poder dar soporte a las necesidades de
información de la gerencia.
El área de proceso de Medición y análisis involucra:
 Especificar los objetivos de medición y análisis de modo que estos estén
alineados con las necesidades de información y los objetivos identificados.
 Especificar las medidas, las técnicas de análisis y los mecanismos para la
recogida de datos, almacenamiento de datos, informes y realimentación.
 Implementar la recogida, almacenamiento, análisis e informes de los datos.
 Proporcionar resultados objetivos que puedan utilizarse en la toma de decisiones
informadas y en la toma de acciones correctivas apropiadas.
La integración de las actividades de medición y análisis en los procesos del

proyecto da soporte a:
 La planificación y estimación objetivas.
 El seguimiento del rendimiento real frente a los planes y objetivos establecidos.
 La identificación y resolución de problemas relativos al proceso.
 El suministro de una base para incorporar la medición en procesos adicionales
en el futuro.
El personal requerido para implementar una capacidad de medición puede o no
estar integrado dentro de un programa constituido a nivel organizativo por
separado. La capacidad de medición puede integrarse dentro de proyectos
individuales o dentro de otras funciones de la organización (p. ej. en aseguramiento
de la calidad).
49
El enfoque inicial para las actividades de medición se encuentra a nivel de proyecto.
Sin embargo, una capacidad de medición puede resultar útil para tratar las
necesidades de información de la organización y/o de toda la empresa. Para poder
dar soporte a esta capacidad, las actividades de medición deberían dar soporte a
las necesidades de información a varios niveles, incluyendo el negocio, la unidad
organizativa y el proyecto, para minimizar el re trabajo a medida que madura la
organización.
Los proyectos pueden decidir almacenar datos y resultados específicos del
proyecto en un repositorio específico del proyecto.
Cuando los datos se comparten más ampliamente entre los proyectos, éstos
pueden residir en el repositorio de medición de la organización.
La medición y el análisis de los componentes del producto proporcionados por los
proveedores son fundamentales para la gestión eficaz de la calidad y de los costes
del proyecto. Es posible, con una gestión minuciosa de los acuerdos con el
proveedor, proporcionar la visión de los datos que dan soporte al análisis del
rendimiento del proveedor.

SG 1 Alinear las actividades de medición y análisis.
SP 1.1 Establecer los objetivos de medición.
SP 1.2 Especificar las medidas.
SP 1.3 Especificar los procedimientos de recogida y de almacenamiento de datos.
SP 1.4 Especificar los procedimientos de análisis.
SG 2 Proporcionar los resultados de la medición.
SP 2.1 Recoger los datos de la medición.
SP 2.2 Analizar los datos de la medición.
SP 2.3 Almacenar los datos y los resultados.
SP 2.4 Comunicar los resultados.

SG 1 ALINEAR LAS ACTIVIDADES DE MEDICIÓN Y ANÁLISIS
Los objetivos y las actividades de medición están alineados con las
necesidades de información y los objetivos identificados.
50
Las prácticas específicas cubiertas bajo esta meta específica pueden tratarse
concurrentemente o en cualquier orden:
 Cuando se establecen los objetivos de medición, a menudo los expertos prevén
los criterios necesarios para especificar las medidas y los procedimientos de
análisis. Al mismo tiempo, también consideran las limitaciones impuestas por los
procedimientos de recogida y de almacenamiento de datos.
 Con frecuencia es importante especificar los análisis necesarios que se llevarán
a cabo antes de ocuparse de los detalles de la especificación de medición, de la
recogida de datos o del almacenamiento.
SP 1.1 ESTABLECER LOS OBJETIVOS DE MEDICIÓN

Establecer y mantener los objetivos de medición que se derivan de las
necesidades de información y de los objetivos identificados.
Los objetivos de medición documentan la motivación existente para llevar a cabo la
medición y el análisis, y especifican los tipos de acciones que se pueden tomar
basándose en los resultados de los análisis de datos.
Las fuentes de los objetivos de medición pueden ser necesidades de gestión,
técnicas, del proyecto, del producto o de implementación del proceso.
Las modificaciones a las necesidades de información y los objetivos identificados
pueden, a su vez, estar indicadas como una consecuencia del proceso y de los
resultados de la medición y el análisis.
Fuentes de las necesidades de información y de los objetivos incluyen:
 Planes del proyecto.
 Monitorización del rendimiento del proyecto.
 Entrevistas con los gestores y otros que tengan necesidades de información.
 Objetivos de gestión establecidos.
 Planes estratégicos.
 Planes de negocio.
 Requerimientos formales u obligaciones contractuales.
 Problemas recurrentes o de gestión o técnicos.
 Experiencias de otros proyectos o unidades de la organización.
 Comparativas con empresas del sector.
 Planes de mejora del proceso.
51
SP 1.2 ESPECIFICAR MEDIDAS
Especificar las medidas para tratar los objetivos de medición.
Los objetivos de medición se refinan en medidas precisas y cuantificables.
Las medidas pueden ser “base” o “derivadas”. Los datos para las medidas base se
obtienen por medición directa. Los datos para las medidas derivadas provienen de
otros datos, típicamente por combinación de dos o más medidas base.
Las medidas derivadas se expresan normalmente como ratios, índices compuestos,
u otras medidas resumen agregadas. A menudo, son cuantitativamente más fiables
y se interpretan de modo más significativo que las medidas base utilizadas para
generarlas.
SP 1.3 ESPECIFICAR LOS PROCEDIMIENTOS DE RECOGIDA Y DE

ALMACENAMIENTO DE DATOS
Especificar cómo se obtendrán y almacenarán los datos de la medición.
La especificación explícita de los métodos de recogida ayuda a asegurar que los
datos correctos se recogen apropiadamente. Puede también ayudar en una
clarificación posterior de las necesidades de información y de los objetivos de
medición.
Una adecuada atención a los procedimientos de almacenamiento y de recuperación
ayuda a asegurar que los datos están disponibles y accesibles para uso futuro.
SP 1.4 ESPECIFICAR LOS PROCEDIMIENTOS DE ANÁLISIS

Especificar cómo se analizarán e informarán los datos de medición.
Especificando previamente los procedimientos de análisis se asegura que se
llevarán a cabo e informarán los análisis apropiados para tratar los objetivos de
medición documentados (y por tanto, las necesidades y los objetivos de medición
sobre los cuales se basan). Esta aproximación proporciona también un
comprobante de que los datos necesarios serán, en efecto, recogidos.
SG 2 PROPORCIONAR LOS RESULTADOS DE LA MEDICIÓN

Los resultados de la medición que tratan las necesidades de información y los
objetivos identificados son proporcionados.
La razón principal para hacer medición y análisis es tratar las necesidades de
información y los objetivos identificados. Los resultados de la medición basados en
52
la evidencia objetiva pueden ayudar a monitorizar el rendimiento, satisfacer las
obligaciones contractuales, tomar decisiones técnicas y de gestión informadas, y
permitir la toma de acciones correctivas.
SP 2.1 RECOGER LOS DATOS DE LA MEDICIÓN

Obtener los datos de la medición especificados.
Los datos necesarios para el análisis se obtienen y se comprueba su completitud e
integridad.
SP 2.2 ANALIZAR LOS DATOS DE LA MEDICIÓN

Analizar e interpretar los datos de la medición.
Los datos de la medición se analizan conforme a la planificación, se realizan
análisis adicionales según sea necesario, se revisan los resultados con las partes
interesadas relevantes y se anotan las revisiones necesarias para análisis futuros.
SP 2.3 ALMACENAR LOS DATOS Y LOS RESULTADOS

Gestionar y almacenar datos de la medición, especificaciones de la medición
y resultados del análisis. Almacenar la información relacionada con la medición
permite que el uso futuro de datos y resultados históricos tenga un coste efectivo y
oportuno. También es necesaria la información para proporcionar un contexto
adecuado para la interpretación de los datos, los criterios de medición y los
resultados del análisis.
La información almacenada incluye normalmente:
 Planes de medición.
 Especificaciones de medidas.
 Conjuntos de datos que han sido recogidos.
 Informes de análisis y presentaciones.
SP 2.4 COMUNICAR LOS RESULTADOS

Informar de los resultados de las actividades de medición y análisis a todas
las partes interesadas relevantes.
53
Los resultados del proceso de medición y análisis se comunican a las partes
interesadas relevantes de forma utilizable y oportunamente para soportar la toma
de decisiones y ayudar en la toma de acciones correctivas.
Las partes interesadas relevantes incluyen a los usuarios previstos, a los
patrocinadores, a los analistas de datos y a los proveedores de datos.
GESTIÓN DE ACUERDOS CON PROVEEDORES (SAM)

El propósito de la Gestión de acuerdos con proveedores (SAM) es gestionar
la compra de productos.
El área de proceso de Gestión de acuerdos con proveedores involucra:
 Determinar el mecanismo de compra.
 Seleccionar los proveedores.
 Establecer y mantener los acuerdos con los proveedores.
 Realizar el acuerdo del proveedor.
 Monitorizar los procesos del proveedor.
 Evaluar los productos suministrados por el proveedor.
 Aceptar la entrega de los productos adquiridos.
 Entregar los productos al proyecto.
Esta área de proceso trata principalmente la compra de los productos y de los
componentes del mismo que se entregan al cliente del proyecto.
En todas las áreas de proceso donde usamos los términos producto y componente
de producto, sus significados previstos engloban también a los servicios y a sus
componentes.
Para minimizar los riesgos del proyecto, este área de proceso puede tratar también
la compra de productos y de componentes del producto importantes no entregados
al cliente del proyecto, pero usados para desarrollar y mantener el producto o
servicio (por ejemplo, herramientas de desarrollo y entornos de prueba).
Normalmente, los productos a adquirir por el proyecto se determinan durante las
etapas iniciales de la planificación y del desarrollo del producto. El área de proceso
de Solución técnica proporciona soluciones para determinar los productos y los
componentes del producto que pueden adquirirse de los proveedores.
Esta área de proceso no trata directamente los acuerdos en los cuales el proveedor
está integrado en el equipo del proyecto y usa los mismos procesos e informes para
54
la misma gestión como los desarrolladores del producto (por ejemplo, equipos
integrados).
Normalmente, estas situaciones se tratan por otros procesos o funciones,
posiblemente externas al proyecto, aunque algunas de las prácticas específicas de
esta área de proceso pueden ser útiles en la gestión del acuerdo formal con tal
proveedor.

SG 1 Establecer los acuerdos con proveedores.
SP 1.1 Determinar el tipo de compra.
SP 1.2 Seleccionar los proveedores.
SP 1.3 Establecer los acuerdos con el proveedor.
SG 2. Satisfacer los acuerdos del proveedor.
SP 2.1 Realizar el acuerdo del proveedor.
SP 2.2 Monitorizar los procesos seleccionados del proveedor.
SP 2.3 Evaluar los productos de trabajo seleccionados del proveedor.
SP 2.4 Aceptar los productos adquiridos.
SP 2.5 Transferir los productos.

SG 1 ESTABLECER LOS ACUERDOS CON PROVEEDORES
Se establecen y mantienen los acuerdos con los proveedores.
SP 1.1 DETERMINAR EL TIPO DE COMPRA
Determinar el tipo de compra para cada producto o componente del producto
a adquirirse.
Hay muchos tipos diferentes de compra que pueden usarse para adquirir productos
y componentes del producto que serán empleados por el proyecto.
En el caso en que se deseen productos COTS, el cuidado en la evaluación y la
selección de estos productos y del vendedor puede ser crítico para el proyecto. A
tener en cuenta en la decisión de selección aspectos como propiedad intelectual y
disponibilidad de los productos.
55
SP 1.2 SELECCIONAR LOS PROVEEDORES
Seleccionar los proveedores en base a una evaluación de su capacidad para
cumplir los requerimientos especificados y los criterios establecidos. Deberían
establecerse criterios para tratar factores que son importantes para el proyecto.
SP 1.3 ESTABLECER LOS ACUERDOS CON EL PROVEEDOR

Establecer y mantener los acuerdos formales con el proveedor. Un acuerdo
formal es cualquier acuerdo legal entre la organización (representando al proyecto)
y el proveedor. Este acuerdo puede ser un contrato, una licencia, un acuerdo de
nivel de servicio o un memorándum de acuerdo.
El contenido del acuerdo debería especificar las revisiones, la monitorización, las
evaluaciones y las pruebas de aceptación a realizar, si tales actividades son
apropiadas para la compra o para el producto.

Los acuerdos con los proveedores deben satisfacer tanto al proyecto como al
proveedor.
SP 2.1 REALIZAR EL ACUERDO DEL PROVEEDOR
Desarrollar las actividades tal y como se especifican en el acuerdo suscrito
con el proveedor.
SP 2.2 MONITORIZAR LOS PROCESOS SELECCIONADOS DEL PROVEEDOR

Seleccionar, monitorizar y analizar los procesos del proveedor que son
aplicables en la colaboración establecida. En situaciones donde debe haber una
alineación estrecha entre alguno de los procesos implementados por el proveedor
y los del proyecto, la monitorización de estos procesos ayudará a prevenir los
problemas. La selección debe considerar el impacto de los procesos del proveedor
en el proyecto. En grandes proyectos, con subcontrataciones importantes para el
desarrollo de componentes críticos, hay que monitorizar los procesos clave. Para
la mayoría de acuerdos con proveedores, el proceso de selección puede determinar
que la monitorización no es la apropiada según afecte al producto final o a
componentes menos críticos o más pequeños. Entre estos extremos, se debería de
tener en cuenta el riesgo global a la hora de seleccionar los procesos a ser
monitorizados.
56
Los procesos seleccionados para la monitorización deberían incluir los procesos de
ingeniería, los de gestión del proyecto (incluyendo la contratación) y los de soporte
que son críticos para el éxito del rendimiento del proyecto.
La monitorización, si no se realiza con el cuidado adecuado, puede en un extremo
ser invasiva y gravosa, o en el otro extremo no ser informativa ni eficaz. Debería
existir suficiente monitorización para detectar los problemas, tan pronto como sea
posible, que puedan afectar a la capacidad del proveedor para satisfacer los
requerimientos del acuerdo del proveedor.
El análisis de los procesos seleccionados involucra la toma de datos obtenidos de
la monitorización de los procesos seleccionados del proveedor y su análisis para
determinar si hay problemas graves.
SP 2.3 EVALUAR LOS PRODUCTOS A MEDIDA SELECCIONADOS DEL

PROVEEDOR
Seleccionar y evaluar los productos hechos a medida por el proveedor. El
alcance de esta práctica específica se limita a los proveedores que proporcionan al
proyecto productos hechos a la medida, particularmente los que presentan algún
riesgo para el programa debido a la complejidad o a la criticidad. La intención de
esta práctica específica es evaluar productos producidos por el proveedor para
ayudar a detectar problemas, lo antes posible, que puedan afectar a la capacidad
del proveedor para satisfacer los requerimientos del acuerdo. La evaluación debería
incluir productos críticos, componentes del producto y actividades que determinen
los problemas de calidad tan pronto como sea posible.
SP 2.4 ACEPTAR LOS PRODUCTOS ADQUIRIDOS

Asegurar que el acuerdo establecido con el proveedor se cumple antes de
aceptar el producto adquirido. Se deberían de completar las revisiones, las pruebas
de aceptación, y las auditorías de configuración antes de aceptar el producto según
se define en el acuerdo con el proveedor.
SP 2.5 TRANSFERIR LOS PRODUCTOS

Transferir los productos adquiridos del proveedor al proyecto. Antes de que el
producto adquirido sea transferido al proyecto para la integración, debería ocurrir
57
una adecuada planificación y evaluación para asegurar una transición sin
problemas.
4.4.3 SCAMPI
¿Qué es una evaluación SCAMPI?

Es el método oficial de calificación de SEI (Software Engineering Institute)
Una SCAMPI es la forma mediante la que se pueden detectar las áreas de mejora
que existen en una empresa según el modelo CMMI escogido, detectando por lo
tanto fortalezas y debilidades en una empresa de acuerdo a las áreas de proceso
sobre las que se realiza SCAMPI.
Este proceso permite mejorar el estado de los procesos de a empresa, así como el
uso eficiente que se hace de los recursos que dispone aumentando la eficiencia de
su actividad. Cuando se lleva a cabo un SCAMPI en una empresa, el resultado es
un análisis del proceso de la empresa, puesto que la calificación que se obtiene es
sobre el cumplimiento del modelo CMMI. De evaluar de cómo una Empresa que
trabaja con procesos y metodologías para ejecutar sus procesos cumple con un
modelo de la familia de CMMI. Es decir, una evaluación SCAMPI es una forma para:
 Identificar qué haces;

 Entender cómo lo haces;
 Verificar que haces lo que dices, como dices que lo haces;
 Verificar que esta forma de ejecutar los procesos se apega a lo que dice algún
modelo de CMMI.
La evaluación SCAMPI es un acrónimo de “Método estándar de Evaluaciones

basadas en CMMI para la Mejora de Procesos.
Una evaluación SCAMPI se puede utilizar para diagnósticos internos y/o para la
evaluación de proveedores y es capaz de producir un perfil de capacidades con
base en algunas áreas de proceso o bien un nivel de madurez para una
organización.
.
58
FUNCIONES
1.1. Analizar:
 Ver el enfoque de los procesos hacia el modelo CMMI-DEV.
 Las evaluaciones estabilizan el proceso y priorizan el cambio
1.2. Motivar:
 Sirven como soporte al cambio
 Se realiza en las organizaciones un esfuerzo de auto-análisis.
1.3. Transformar:
 Contribuye que personas diferentes vean las mismas cosas de la misma forma.
 Se le otorga libertad al personal de pensar acerca de que se hace de forma
equivocada y cómo corregirlo
1.4. Educar:
 Se le suministra a las organizaciones las mejores prácticas a nivel mundial
 Proporciona a las personas un amplio conocimiento de su organización.
2. Clases de SCAMPI
Existen 3 clases de SCAMPI (A, B y C) que pueden ser utilizados dependiendo del
objetivo de la evaluación.
El SCAMPI clase A
Tiene un foco primario en la institucionalización. Es el método más riguroso y
completo de las tres clases y es usado para evaluaciones en profundidad. Permite
evaluar y brindar una puntuación sobre el nivel de madurez de la organización.
Requiere muchos recursos de tiempo y personas.
El SCAMPI clase B
Tiene un foco primario en el despliegue (“deployment”). Es un método que
resulta ser útil previo a la implementación masiva de nuevos procesos. Sin
59
embargo, no proporciona una puntuación sobre el nivel de madurez de la
organización.
El SCAMPI clase C
Tiene un foco en el acercamiento o aproximación (“approach”). Es el menos
riguroso de todos, rápido y el que demanda menos recursos. No proporciona
puntuación sobre el nivel de madurez de la organización.
Elección de SCAMPI
Este proyecto utiliza SCAMPI de tipo B por las siguientes razones:
 Es más flexible que las de tipo A.
 Proporciona un resultado parecido al tipo A, viendo cual podría ser el resultado
oficial.
 No se necesita demasiado personal ni recursos.
 Es más riguroso que el tipo C.
Las diferencias entre el tipo B y C son pocas, pero importantes. Principalmente, lo

que diferencia al tipo B del tipo C es la granularidad del proceso. El tipo C puede
aplicarse a cualquier alcance del modelo, pudiendo situarse en prácticas o metas,
mientras que el tipo B podría aplicarse a cualquier alcance, el proyecto se centra
en el cumplimiento de las áreas de proceso por completo por lo que este nivel de
granularidad es el correcto dentro de los SCAMPI de tipo B.
4.5 APLICACION DEL NIVEL DE MADURES DE CMMI A LA ORGANIZACIÓN
GESTIÓN DE REQUISITOS (REQM)

GESTIÓN DE INDICADORES
REQUISITOS SUBPRACTICAS JUSTIFICACIÓN DE
(REQM) CUMPLIMIENTO
SG1 GESTIONAR LOS REQUISITOS
El en formato de lista de
Establecer
requerimientos señala el
SP 1.1 Obtener criterios para
nombre del proyecto y la
una comprensión distinguir a los
identificación de los Buena
de los proveedores
usuarios, descripción del
requerimientos. apropiados de
requerimiento y la
requisitos
importancia del
60
requerimiento. Obtenidas de
las distintas áreas,
agrupadas en 8 módulos
funcionales para realizar los
trámites documentarios
internos.
La subgerencia de sistemas
y tecnología, llevan a cabo
reuniones con los
responsables del ´proyecto
de tramite documentario
Establecer
interno en el cual se generan
criterios objetivos
los documentos:
para la
evaluación y Buena.
 Formato de análisis de
aceptación de los
requerimiento. El cual
requisitos.
describe los
requerimientos
funcionales, alcances,
modificaciones, y
mantenimiento evolutivo.
Se efectúan reuniones con
los responsables de las
distintas áreas de la
Alcanzar una
organización con el fin de
comprensión de
tratar la aprobación de los
los
requisitos que se desarrollan
requerimientos
en especial los días
con el proveedor
miércoles donde se genera
de requerimientos Buena
el documento de:
para que los
 Formato de actas de
participantes del
reunión. Contiene la
proyecto puedan
fecha de realización,
comprometerse
nombre del personal
con ellos.
responsable, la
dependencia, el lugar y la
hora.
Los participantes del
Evaluar el proyecto evalúan los
SP 1.2 Obtener el impacto de los requerimientos, en casos de
compromiso requerimientos no ser factible se modifican
Buena
sobre los sobre los estos o realizan acciones
requerimientos. compromisos correctivas que están
existentes. contenidas en el formato de
análisis de requerimientos
61
El sub gerente de sistemas y
tecnólogo convoca a la una
reunión con los miembros
responsables del proyecto
Negociar y para que se comprometan
registrar los con el requerimiento. Buena
compromisos Mediante los formatos:
 Formato de acta de
reuniones.
 Formato de análisis de
requerimientos.
Los Cambios tecnológicos,
Documentar
Cambios en las estrategias o
todos los
prioridades del negocio
requerimientos y
(tupa), Modificaciones en
los cambios a los
leyes y/o regulaciones Regular
requerimientos
(unidad de racionalización).
que son dados o
Se documentan a través de
generados por el
los formatos de análisis de
proyecto.
requerimientos.
Documentan los detalles de
los requisitos para sus
cambio, modificación y
Evaluar el
evaluación de los
impacto de los
requerimientos o nuevos
cambios de
requerimientos en el formato
requerimientos
de análisis de requerimiento regular
desde el punto de
y el formato de acta de
vista de las partes
requerimiento para el plan
interesadas
de sub sistema de trámite
relevantes.
interno de las páginas 17 al
19 las cuales siguen un
procedimiento.
Mantener la No se cuenta con una matriz
trazabilidad de los de análisis que nos brinde la
SP 1.4 Mantener requisitos desde medida en la cual se puede
la trazabilidad un requisito a sus establecer una relación en el
bidireccional de requisitos proceso de desarrollo Malo
los inferidos y a la referida a la habilidad de
requerimientos. asignación a los seguir el ciclo de un
productos de requerimiento, tanto para
trabajo. atrás como hacia delante.
SP 1.5 Identificar Revisar los No se especifica con
las planes del documentación para dicho
inconsistencias proyecto, las ítem, solo se sobre entiende Malo
entre el trabajo actividades y los de acuerdo a reuniones
del proyecto y los productos de establecidas para las
62
requerimientos. trabajo en cuanto modificaciones planteadas o
a la consistencia por la integración de
con los requisitos requisitos.
y los cambios
Realizados sobre
ellos.
PLANIFICACION DE PROYECTO(PP)
PLANIFICACION INDICADORES
DE SUBPRACTICAS RESULTADOS DE
PROYECTO(PP) CUMPLIMIENTO
Sí se ha menciona la
descomposición de la
Desarrollar una
estructura de trabajo, pero
estructura de
no hay una descripción
descomposición del
detallada de algunos
trabajo (WBS)
componentes de la fase del
basado en la
proyecto.
arquitectura del
Fuente:
producto Buena
 Plan de Desarrollo de
STDI, pag. 15.
Sí se ha desarrollado los
roles, responsabilidades,
SP 1.1 Estimar
pero el desarrollo de la
el alcance.
calendarización no es
Identificación de realista porque en la fase de
paquetes de trabajo desarrollo se dice que se
para estimaciones desarrolló en 5 semanas y
de tareas, para la magnitud de este
responsabilidades y proyecto esta delimitación
calendarización del es irreal.
proyecto Fuente:
 Plan de desarrollo del Regular
STDI v1.0, pag.13.
 Plan de proyecto de STDI
v1.0, pag. 19.
Sí cumple, se tiene una
definición exacta de del
SP 1.2 software y hardware de
Determinar el
Establecer desarrollo a aplicarse al
planeamiento
estimaciones de proyecto de acuerdo a la
técnico para Excelente
los productos gestión de requerimientos,
proyecto
de trabajo. llegando a la conclusión de
desarrollar una arquitectura
cliente- servidor.
63
Fuente:
 Plan de desarrollo para el
STDI v1.0, pag. 13.
Sí cumple, los métodos

validados usados para
determinar el tamaño y la
Usar métodos complejidad del software
apropiados para son el análisis de
determinar los requerimientos,
atributos de los centrándose en
productos de características como su
trabajo complejidad y cantidad, Buena
pero no cuenta con una
matriz de trazabilidad de
requerimientos.
Las fases del ciclo de vida
que contempla el proyecto
son: Gestión de Proyecto,
Análisis, Diseño, Desarrollo,
Pruebas y Cierre, las fases
del proyecto están bien
Definir las fases del
especificadas, pero no tiene
ciclo de vida del
SP 1.3 Definir el los respectivos tiempos que
proyecto en las que
ciclo de vida del cada uno de las fases
encuadrar el
proyecto. necesita además no hay un Buena
esfuerzo de la
tiempo de contingencia para
planificación
resolver posibles
problemas.
Fuente:
 Plan de desarrollo de
sistema de tramite
documentario, pag.19
No cumple, ya que no
presenta documentación de
múltiples modelos y
métodos, se tiene
información escasa,
Recoger datos
SP 1.4 además no hay documentos
históricos para
Determinar las formales para la estimación
transformar los
estimaciones del costo de la
atributos de los
del esfuerzo y implementación del
productos de
costo. software, y tampoco se
trabajo y las tareas. Malo
cuenta con algún dato
histórico que nos ayude a
analizar el esfuerzo, el
cronograma de actividades.
64
Sí cuenta con una
infraestructura de soporte,
al inicio del proyecto se
realizó el planeamiento de
infraestructura tecnológica,
se cuenta también con
Incluir las recursos suficientes para
necesidades de la los entornos de prueba y
infraestructura de producción del proyecto,
soporte al estimar pero solo existe
el esfuerzo y el documentación para el
coste planeamiento de
infraestructura tecnológica
en la fase de desarrollo y ya Buena
no se especifica en la fase
de prueba y producción por
que ya se sobreentiende,
pero sí se debería
considerar.
En la calendarización no se
especifican los hitos, solo
muestran el tiempo que les
Identificar los hitos tomara el desarrollo de
principales cada entregable.
Fuente: Malo
 Plan de desarrollo del
STDI v1.0, pag.24.
Si se tiene especificado,
pero presentan
inconsistencias en la
calendarización para el
SP 2.1
desarrollo del sistema,
Establecer el Identificar los
programando solo 5
presupuesto y supuestos del
semanas para su
el calendario. calendario Malo
culminación, generando
problemas en el proyecto.
Fuente:
 Plan de desarrollo del
STDI v1.0, pag.13.
No se especifica en la
Identificar las
documentación del Malo
restricciones
proyecto.
Si se especifican las tareas
Identificar las
en el documento, pero no se
dependencias de
sabe cuáles son las tareas
las tareas
predecesoras y sucesoras,
65
además no se cuenta con Regular
una secuencia ordenada.
Fuente:
 Plan de desarrollo para el
STDI v1.0, pag. 24.
Establecer los No hay una documentación
criterios de acción de las acciones correctivas
Malo
correctiva en el plan del proyecto.
No se cuenta con un
SP 2.2 Identificar,
documento formal que
Identificar los documentar, revisar
especifique todo acerca de
riesgos del y corregir los
la identificación de los Malo
proyecto. riesgos
riesgos en el proyecto.
No se cuenta con un plan
para la gestión del control
Establecer los
SP 2.3 Planificar de acceso a los datos, pero
requerimientos y
la gestión de si se cuenta con una
los procedimientos
datos. calendarización para el
de los datos Regular
recojo de los datos del
proyecto.
Si se cuenta con
requerimientos de los
Determinar los
procesos necesarios.
requerimientos del
Fuente:
proceso Buena
 plan de desarrollo
del STDI pag 11.
Sí se cuenta con los
requerimientos del personal
Determinar los para el desarrollo del
SP 2.4 Planificar requerimientos de proyecto.
Buena
los recursos del personal Fuente:
proyecto.  plan de desarrollo
del STDI pag 13.
Si se cuenta con los
requerimientos de las
Determinar los instalaciones y tecnología a
requerimientos de usar durante el desarrollo e
instalaciones y implantación del proyecto.
equipamiento Fuente: Buena
 Plan de desarrollo
del STDI pag 14.
Sí se ha realizado la
SP 2.5 Planificar Identificar y evaluar
identificación de los
el conocimiento el conocimiento y
requerimientos de
y las habilidades
conocimientos de personal
habilidades necesarias para
de acuerdo a los
dadas ejecutar el proyecto
lineamientos del proyecto,
66
pero no se tiene
documentación acerca de Regular
cómo se ha evaluado el
desempeño del personal,
tampoco se especifica los
mecanismos aplicados para
capacitar al personal.
Fuente:
 Plan de desarrollo
del STDI pag 20.
Sólo existe la planificación
del personal involucrado en
Planificar la el desarrollo del software
SP 2.6 Planificar
involucración de las más no los clientes quienes
la involucración
partes con las fases usaran el sistema como las Mala
de las partes
del desarrollo del diferentes dependencias.
interesadas
proyecto Fuente:
Plan de desarrollo del STDI
pag 20.
SP 2.7 Establecer y Sí se tiene un plan, pero
Establecer el mantener el está incompleto, no
Malo
plan del contenido del plan contempla todas las
proyecto. del proyecto global prácticas.
No hay compatibilidad entre
el plan global del proyecto y
SP 3.1 Revisar Registro de las
los demás planes, además
los planes que revisiones de los
no se cuenta con planes
afectan al planes que afectan Malo
específicos del equipo de
proyecto. al proyecto
desarrollo siendo éste
crítico para el proyecto.
No se tiene documentación
Reconciliar el plan acerca de algún
SP 3.2
de proyecto para presupuesto renegociado,
Reconciliar los
reflejar los tampoco formas de
niveles de
recursos incrementar la
trabajo y de
disponibles y productividad del personal y Malo
recursos
estimado actualizar la
calendarización.
No se ha documentado de
SP 3.3 Obtener Obtener el
manera completa a todas
compromiso compromiso de
las partes interesadas en el Malo
con el plan las partes
proyecto.
MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC)

MONITORIZACIÓN INDICADORES
SUBPRACTICAS JUSTIFICACIÓN
Y CONTROL DEL DE
67
PROYECTO (PMC) CUMPLIMIENTO
SG1 Monitorizar el proyecto frente al plan.
No se cuenta con una
Monitorizar el calendarización que
progreso frente al establezca el control real de Malo
calendario las actividades desarrolladas
en el proyecto.
Se cuenta con un
presupuesto general la que se
elabora en el periodo para el
siguiente año laboral, en la
que se especifica los
requerimientos económicos
Monitorizar el
sustentados por el área de la
coste y el
subgerencia de sistemas y
esfuerzo gastado Buena.
tecnología. Pero no se
en el proyecto.
detallan los porcentajes de
costes por actividades ni los
tiempos gastos que se
tendrán.
SP 1.1 Monitorizar
los parámetros de
En el plan del proyecto de
planificación del
Monitorizar los trámite interno de trabajo solo
proyecto.
atributos de los señala algunas pautas, pero
productos de no se cuenta con un plan bien Buena
trabajo y de las elaborado y las
tareas. documentaciones respectivas
para su estimación..
Monitorizar los Cuentan con un plan de
recursos contingencia. donde se
Buena
proporcionados y detallan los equipos y
los usados. recursos usados en el área
El caso de la MPH, realiza la
convocatoria de un personal
Monitorizar el con los requerimientos
conocimiento y especificados por el área
las habilidades solicitante en este caso la
Regular
del personal del subgerencia de sistemas y
proyecto. tecnología para cubrir la
función que requiere el área.
Para realizar una buena
monitorización se debe:
Documentar las No se cuenta con una
desviaciones documentación ni un formato
Malo
significativas en para guardar dichas
los parámetros de desviaciones, tan solo se
68
la planificación cuenta con versiones de
del proyecto. modificación de software que
modifica una falencia o
cambia de acuerdo a los
requerimientos.
Se realizan reuniones que son
Revisar los
anotadas en el formato de
compromisos
acta de reuniones, en el plan
SP 1.2 Monitorizar (tanto externos
de tramite documentarios Regular
los compromisos. como internos)
especifica la los roles y no se
con
señalan las revisiones del
Regularidad.
cumplimiento de acuerdos.
En el plan de trámite
Revisar documentario y plan de
periódicamente la trámite documentario interno
documentación señalan sobre el análisis de
SP 1.3 Monitorizar de riesgos en el riesgos. Pero no se cuenta
los riesgos del contexto del con documentación especifica Buena
proyecto. estado y de las de los registros de riesgo,
circunstancias además en las reuniones solo
actuales del se acuerdan que acciones
proyecto. tomar, pero; no son
documentadas.
Revisar
periódicamente
SP 1.4
las actividades de
MONITORIZAR LA No se cuenta con
gestión de los Malo
GESTIÓN DE LOS documentación preparada,
datos frente a su
DATOS
descripción en el
plan de proyecto.
Revisar
SP 1.5 Cuenta con un cronograma de
periódicamente el
MONITORIZAR LA actividades que es irrealista y
estado de la
INVOLUCRACIÓN no cuenta con hitos, y no Malo
involucración de
DE LAS PARTES satisface la documentación
las partes
INTERESADAS que lo contiene.
interesadas.
Comunicar con
regularidad a las Se reúnen en periodos
partes definidos (los días miércoles)
SP 1.6 LLEVAR A interesadas se hace seguimiento al
CABO relevantes el avance revisando las
Buena
REVISIONES DE estado de las variables establecidas.
PROGRESO actividades y los Realizan la revisión de los
productos de problemas que requiere
trabajo atención.
asignados.
69
Tienen reuniones con los
Revisar los miembros de las áreas
SP 1.7 LLEVAR A
compromisos, el involucradas y el equipo del
CABO
plan, el estado y proyecto, para revisar lo Buena
REVISIONES DE
los riesgos del alcanzado, y aceptarlo
HITOS
proyecto. formalmente y evaluar los
pasos siguientes.
SG1 gestionar las accesiones correctivas hasta su cierre.
SP 2.1 ANALIZAR En el formato de análisis de
Recopilar las
LOS requerimientos listan los
cuestiones para Regular
PROBLEMAS. problemas identificados y sus
su análisis.
responsables
Determinar y
documentar las En el formato de análisis de
SP 2.2 LLEVAR A acciones requerimientos no se
CABO LAS apropiadas especifica las acciones
Regular
ACCIONES necesarias para correctivas a los problemas ni
CORRECTIVAS tratar las fechas estimadas a su
cuestiones realización.
identificadas.
SP 2.3 El documento de formato de
GESTIONAR LAS análisis de requerimientos no
ACCIONES especifica las acciones que
Monitorizar las
CORRECTIVAS indique el resultado del
acciones
seguimiento de acciones Regular
correctivas hasta
correctivas y del problema.
su finalización.
Solo menciona en el plan de
subsistema de trámite interno
pág. 21.
GESTION DE ACUERDOS CON PROVEEDORES (SAM)

La organización desarrolla su propio software, sin embargo, no cuenta con documentación
para la gestión de los proveedores, es así que ellos deberían contar con estos puntos para
la adquisición de algún producto hardware o software.
GESTION DE ACUERDOS CON PROVEEDORES (SAM)

ÁREAS DE
SUBPRACTICAS COMO DEBE SER
PROCESO
La compra debe ser de acuerdo a los
Determinar el tipo de
procesos que definen a la
SP 1.1 determinar compra para cada
organización, se debe tener en cuenta
el tipo de compra producto o componente
hasta donde abarca la disponibilidad
del producto a adquirirse
del producto a adquirirse.
70
Se debe tener en cuenta la
Establecer y documentar
localización geográfica del proveedor,
los criterios para la
experiencia del proveedor en
evaluación de proveedores
proyectos similares
Se debe analizar las ventajas,
Estudio de mercado u otro desventajas y riesgos asociados con
registro de criterios de los proveedores candidatos, se debe
evaluación contar con una lista de proveedores
candidatos.
Se debe hacer la investigación de
mercado para identificar a los
Identificar proveedores proveedores potenciales además se
SP 1.2
potenciales debe especificar claramente la razón
Seleccionar los
por la que se selecciona a un
proveedores
determinado proveedor
Aplicar métodos como: evaluación de
la experiencia pasadas del proveedor,
evaluación de logros obtenidos para
la mejora de procesos del producto en
Evaluar la capacidad de los otras organizaciones, evaluación de la
proveedores propuestos capacidad de gestión, evaluación de
para realizar el trabajo personal disponible, evaluación de las
instalaciones y recursos disponibles,
costo de los productos a adquirir,
requerimientos de seguridad,
Luego de realizar el levantamiento de

los requisitos del software o hardware,
Corregir los éstos se deben alinear con los
requerimientos proveedores porque serán estos los
que nos brinden los productos y
servicios
Documentar el acuerdo del proveedor
Debe incluir declaraciones de las actividades , especificaciones,
términos y condiciones, lista de entregables, calendarización de
SP 1.3 Establecer actividades, presupuesto y proceso de aceptación definido,
los acuerdos con identificar a los responsables de ambas partes para hacer cambios
el proveedor al proyecto, identificar como se comunican y gestionan los cambios
de requerimientos, identificar los estándares y procedimientos que se
seguirán, identificar el tipo y la profundidad de supervisión del
producto, procedimientos y criterios aplicados al momento de la
monitorización del rendimiento del producto, los tipos de revisiones
que se llevaran a cabo con el proveedor, las responsabilidades del
proveedor con el mantenimiento, garantía y derechos de uso de los
productos adquiridos, identificar los criterios de aceptación.
Documentar el acuerdo del proveedor de productos
Se deben tener en cuenta las licencias del producto, descuentos para
71
las grandes cantidades de compras, cobertura de las partes
interesadas más relevantes bajo el acuerdo de la licencia, incluyendo
los proveedores miembros del equipo y clientes, planes para futuras
mejoras, soporte de mantenimiento para las consultas y problemas.
Esta revisión permitirá contrastar los
Revisar periódicamente el
acuerdos entre el proveedor y el
acuerdo del proveedor
proyecto, e identificar los riesgos.
Asegurar que las partes en el acuerdo
Asegurar los acuerdos comprenden y aceptan los
requerimientos.
Se debe evaluar y corregir el acuerdo
con el proveedor según sea
necesario, para relejar los cambios a
Evaluación continua los procesos y corregir los planes y los
compromisos del proyecto, para
reflejar el acuerdo vigente entre el
proveedor y la organización.
Se debe monitorizar los avances de
acuerdo a la calendarización, coste,
Monitorizar el progreso del
rendimiento técnico, todo esto de
proveedor
acuerdo a los acuerdos establecidos
con el proveedor.
Para tener revisiones optimas se
deben considerar las siguientes
etapas: asegurar que las partes
interesadas y encargas se encuentran
Llevar a cabo revisiones durante la revisión, identificar,
con el proveedor documentar y seguir todos los
elementos de acción hasta el cierre,
preparar y distribuir un informe
SP 2.1 Realizar el resumen de la revisión a las partes
acuerdo del interesadas relevantes.
proveedor Revisar los procedimientos técnicos
del proveedor y verificar que la
interpretación e implementación de los
Llevar a cabo revisiones requisitos son consistentes de
técnicas con el proveedor acuerdo a las necesidades, verificar
que los requisitos se cumplen y si
existiesen problemas se comuniquen
para luego resolverlos.
La gerencia debe revisar las
Llevar a cabo revisiones
dependencias críticas, los riesgos del
técnicas con el proveedor
proyecto que involucran al proveedor
por parte de la gerencia
como también revisar el calendario y
del proyecto
el presupuesto.
Usar los resultados de las Esta información será crítica para
72
revisiones para mejorar el fomentar las relaciones a largo plazo
rendimiento del proveedor con los proveedores.
Monitorizar los riesgos Esta información permitirá tomar
que involucran al acciones correctivas para minimizar
proveedor los riesgos.
SP 2.2
Identificar, monitorizar y Toda esta información debe estar
Monitorizar los
analizar los resultados de alineada a los requerimientos del
procesos
la monitorización los acuerdo, detectar y prevenir
seleccionados
procesos del proveedor problemas,
del proveedor
Se debe tener mayor énfasis en los:
requerimientos, análisis, arquitectura
Identificar productos
de desarrollo y la documentación, para
críticos
ayudar a detectar los problemas de
SP 2.3 Evaluar manera oportuna.
los productos a Se evaluaran los productos críticos
medida para asegurar que, los requerimientos
seleccionados derivados sean trazables, la
del proveedor Evaluar los productos arquitectura sea viable y satisfaga el
seleccionados crecimiento futuro, documentación
para operar y dar soporte al producto,
productos y componentes del
producto hechos a la medida.
Se debería definir los procedimientos
de aceptación para luego revisarlos y
obtener un acuerdo de las partes
Asegurar que el acuerdo interesadas, se debe verificar que los
SP 2.4 Aceptar establecido con el productos adquiridos satisfacen los
los productos proveedor se cumpla requerimientos, confirmar los
adquiridos antes de aceptar el acuerdos de mantenimiento,
producto adquirido documentar los resultados de las
revisiones, establecer y mantener el
acuerdo con el proveedor si el
producto no pase la aceptación.
Se debe asegurar que haya
instalaciones apropiadas para recibir,
almacenar, usar y mantener los
productos adquiridos, asegurar que se
Transferir los productos
imparte capacitación para los usuarios
adquiridos del proveedor
encargados de la recepción,
SP 2.5 Transferir al proyecto (antes de la
almacenamiento, uso y mantenimiento
los productos transferencia es
de los productos adquiridos, asegurar
importante evaluar lo
que los procedimientos de los
siguiente)
productos adquiridos se realiza de
acuerdo a los términos y condiciones
especificadas en el acuerdo con el
proveedor.
73
4. MA: MONITORIZACION Y ANALISIS
El propósito de la Medición y análisis (MA) es desarrollar y sustentar una capacidad
de medición que se utiliza para poder dar soporte a las necesidades de información de la
gerencia.
MONITORIZACION Y ANALISIS (MA)

AREAS DE
SUBPRACTICAS JUSTIFICACIÓN CUMPLIMIENTO
PROCESO
SG1 Alinear las actividades de medición y análisis
No existe una buena
Documentar las documentación de las
necesidades de necesidades de
Malo
información y de información y los
objetivos. objetivos claramente
definidos.
SP 1.1 Priorizar las
Establecer los necesidades de No hay una priorización
Malo
objetivos de información y los de las necesidades de
medición. objetivos. la información.
No existen las
Documentar, revisar revisiones y las
y actualizar los actualizaciones de los
Malo
objetivos de objetivos debido que no
medición. hay una buena
documentación.
Identificar las
medidas cantidades No se identifican las
en base a los medidas candidatas en
Malo
objetivos de base a los objetivos de
medición medición documentaria.
documentados.
Identificar las No se cuentan con las
medidas existentes medidas existentes, en
Malo
que ya tratan los cualquier otra parte de
objetivos de la organización.
medición.
No se consideran las
Especificar las definiciones operativas
definiciones debidas de la falta de Malo
SP 1.2
operativas para las compromiso del parte
Especificar las
medidas. de los involucrados del
medidas
desarrollo del software.
Priorizar, revisar y
actualizar las Se ve poco priorización Regular
medidas. de las especificaciones
74
de las medidas y no se
actualizan de una
manera adecuada.
La identificación de las
Identificar las fuentes de datos ha sido
fuentes de datos considerad0 de la
existentes que se experiencia misma de
generan a partir de los proyectistas, los
Regular
los productos de mecanismos de
trabajo, los procesos recogida de datos son
o las transacciones criterio de la lluvia de
actuales. ideas del grupo de
SP 1.3 trabajo.
Especificar los Se hizo una poca
procedimientos Especificar cómo consideración en el
de recogida y de recoger y almacenar recojo y
Regular
almacenamiento los datos para cada almacenamiento de
de datos. medida requerida. datos para la medida
requerida.
Se ve poca recogida de
datos tales como
formularios y plantillas
Crear mecanismos y
manuales, debido a
guías de proceso de Regular
estas se ve la
recogida de datos.
deficiencia en la
elaboración del
proyecto.
No se consideró las
Seleccionar los
herramientas para el
métodos y las
buen manejo del control
herramientas Malo
apropiado del análisis
apropiados de
de datos, tales como un
análisis de datos.
análisis estadístico.
Se especificó una
SP 1.4 identificación y
Especificar los Especificar los determinación de los
procedimientos procedimientos grupos responsables
de análisis administrativos para del análisis de datos y la
Bueno
analizar los datos y presentación de
para comunicar los resultados, tales como
resultados. las reuniones de
progreso, informes de
progreso, memos.
Revisar y actualizar No se cuenta con
el contenido y el personal que se Malo
formato propuesto encargue de las
75
de los análisis e actualizaciones del
informes contenido y el formato
especificados. propuesto de los
informes.
SG 2 Proporcionar los procedimientos de recogida y de almacenamiento de
datos.
Los datos existentes de
recogieron de los
registros de proyectos
Obtener los datos
existentes de otras
para las medidas Regular
organizaciones con el
base.
mismo giro de negocio
similares a esta
organización de trabajo.
SP 2.1 Recoger
No se realizan las
los datos de la
comprobaciones de
medición.
Realizar las integridad de datos.
comprobaciones de La sugerencia es que se
integridad de datos puedan medir los
Malo
lo más cerca posible errores una vez
a la fuente de los identificados y de tal
mismos. manera dar solución
para una mejora de
procesos continuos.
Se analizó, interpreto
Llevar a cabo los
los datos iniciales de
análisis iniciales,
una manera poco
interpretar los
considerable, para la Regular
resultados y sacar
interpretación de los
las conclusiones
SP 2.2 Analizar resultados y
preliminares.
los datos de la conclusiones.
medición. No se cuenta con una
Revisar los
revisión apropiada de
resultados iniciales
los resultados iniciales
con las partes Malo
para la interpretación y
interesadas
comunicación de alguna
relevantes.
falla que tuviese.
La poca información
almacenada que se
Almacenar los datos obtuvo para el
SP 2.3
conforme a los desarrollo de este
Almacenar los
procedimientos de proyecto se encuentra Regular
datos y los
almacenamiento de disponibles para las
resultados
datos. partes interesadas, que
requieran de esta
información.
76
No se cuentan con
mantener informadas
los resultados de los
Mantener
procesos de mediciones
informadas
y análisis a las partes
SP 2.4 regularmente a las
interesadas.
Comunicar los partes interesadas Malo
Se aconseja de informar
resultados relevantes de los
regularmente los
resultados de la
resultados de medición
medición.
a las partes interesadas,
para una buena toma de
decisiones.
ASEGURAMIENTO DE LA CALIDA DE PROCESO Y DE PRODUCTO(PPQA)
CONTROL DE
INDICADORES
CALIDAD DE
SUBPRACTICAS JUSTIFICACION DE
PROCESOS Y
CUMPLIMIENTO
PRODUCTOS
SG 1 Evaluar objetivamente los procesos y los productos de trabajo
En el proyecto de sistema de
tramite documentario interno,
el grupo de corrección y el
grupo de análisis de control
Incentivar a los
de calidad identifica los
empleados en la
problemas de calidad del
identificación y
producto software informando Malo
comunicación de
al jefe del proyecto para que
los problemas de
pueda realizar las correcciones
calidad
pero no cuentan con un
documento que contenga los
problemas de calidad del
producto software.
En el transcurso del desarrollo
del desarrollo del software los
grupos del proyecto y los
usuarios directos(secretaria de
SP 1.1 Evaluar las distintas áreas) estuvieron
Identificar cada
objetivamente inconformes en el momento de
no conformidad
los procesos realizar pruebas y las Malo
encontrada
evaluación del producto
durante la
software encontrando
evaluación.
Fallas, errores informando al
jefe del proyecto pero no
cuentan con un documento
donde registren las
77
inconformidades en el
momento de la evaluación.
El grupo de revisión convoca a
una reunión en donde los
Identificar las demás grupos del proyecto
lecciones informan los problemas que
aprendidas que tienen y las dificultades para
podrían mejorar que los procesos sean
Malo
los procesos para eficientes para poder dar una
futuros productos solución factible pero no cuenta
y servicios. con un documento de las
soluciones que podrían mejorar
los procesos futuros.
SP 1.2 Para la evaluación de producto
EVALUAR utilizan el criterio de evaluar al
OBJETIVAMEN Usar los criterios usuario directo (secretario de
TE LOS definidos durante las distintas áreas) que utilicen
Malo
PRODUCTOS las evaluaciones el software para ver si cumple
DE TRABAJO de los productos con los requisitos del área y si
Y LOS de trabajo. no cumple enviar una solicitud
SERVICIOS de cambio al jefe del proyecto.
Los grupos de control de
calidad y control de
correcciones están en
constante trabajo con los
usuarios directos realizando
pruebas, evaluando el producto
Evaluar los
software e informando
productos de
semanalmente un informe al Malo
trabajo antes de
jefe del proyecto para dar
que sean
soluciones factibles pero no
entregados al
cuentan con un documento de
Cliente y trabaja
las evaluaciones de producto
con los hitos.
antes de entregar al usuario
directo (la secretaria de las
distintas áreas).
SG 2 PROPORCIONA UNA VISION OBJETIVA
En el proyecto existe
SG 2.1 inconformidades por parte de
COMUNICAR Y Resolver cada no los usuarios, jefes del proyecto
ASEGURAR LA conformidad con y el grupo de corrección en
RESOLUCION los miembros cuanto a la calidad del producto
Malo
DE LAS NO apropiados del software o en los procesos de
CONFORMIDA Personal donde desarrollo del software que dan
DES sea posible. una solución factible en las
reuniones que se les cita a los
miembros del grupo pero no
78
existe un documento que
contenga las inconformidades
de los participantes del
proyecto.
Analizar las no En el transcurso del desarrollo

conformidades del producto software Habían
para ver si existe inconformidades por parte del
alguna tendencia usuario y el grupo del proyecto
de calidad que sobre la calidad del software Malo
pueda informando al analista de
identificarse y control de calidad.
tratarse.
Asegurar que las en proyecto de desarrollo del
partes sistema de tramite interno
interesadas Todas áreas de la
relevantes son municipalidad de huamanga
informadas de utilizan el software realizando
los resultados de pruebas y solo le informa sobre
las evaluaciones y la evaluación al jefe del
Malo
de las tendencias proyecto y al grupo de
de calidad de corrección.
Manera oportuna. Pero no cuentan con un
documento sobre los
resultados de las evaluaciones
de las partes involucradas.
Registrar las En grupo de análisis control de
actividades de calidad no existe un
aseguramiento de documento en donde registre
la calidad de las actividades para asegurar
proceso y de la calidad del producto
producto con software y los procesos de
SP 2.2 suficiente detalle forma detallada en el
ESTABLECER de forma que documento de plan de
REGISTRO sean conocidos el desarrollo para el sub sistema
estado y los de tramite Documentario
Malo
resultados. interno encontramos los
proceso de desarrollo que
están de forma resumida.
Corregir el estado En el área de control de calidad
y la historia de las no existe un documento en
actividades de donde realice las correcciones
aseguramiento de de la calidad de producto Malo
la calidad según software solo se le informa
sea necesario. grupo del proyecto para la
solución del problema.
79
GESTION Y CONFIGURACION
GESTION DE INDICADORES
CONFIGURACION DE
SUBPRACTICAS RESULTADOS
(CM) CUMPLIMIENTO
SG 1 ESTABLECER LINEAS DE BASE
Si cuenta con elementos de

configuración como una
interfaz, un código fuente,
Seleccionar los
base de datos, los
elementos de
requerimientos, pero no
configuración y
todo está correctamente
los productos
documentado solo alguna Bueno
de trabajo,
de ellas tiene un detalle
basándose en
completo tal es el análisis
criterios
de requerimientos.
documentados.
Fuente:
Plan de proyecto de STDI
v1.0, pag.8
Asignar Cada uno de los elementos
identificadores de configuración no cuenta
únicos a los con indicadores no hay un
Malo
elementos de documento donde se ve la
configuración. aplicación de los
indicadores
Para saber las
características de cada
elemento de configuración
se tener en cuenta primero
una buena documentación y
Especificar las estos a la vez deben contar
características con un autor, un breve
importantes de detalle del tipo de
cada elemento documento o el tipo de
de archivo pero vemos que en Malo
Configuración. cada uno de los
documentos no tienen estas
características.
Especificar
SP 1.1
cuándo cada No hay una especificación
IDENTIFICAR
elemento de detallada de los tiempos
ELEMENTOS DE
configuración se usados en cada una de las Malo
CONFIGURACION
pone bajo gestión etapas del ciclo de vida.
de configuración.
80
Si tiene responsables en
Identificar al cada uno de los elementos
propietario de configuración.
Buena
responsable de Fuente:
cada elemento Plan de proyecto de STDI
de configuración. v1.0, pag.20
Establecer un No hay un nivel de control
mecanismo para ya que para ello se
gestionar selecciona normalmente en
múltiples niveles base a los objetivos de cada
Malo
de control en la elemento d configuración,
gestión de la no hay un análisis de
SP 1.2
configuración riesgos y/o recursos del
ESTABLECER UN
proyecto.
SISTEMA DE
Almacenar y
GESTION DE No hay un almacenamiento
recuperar
CONFIGUACION ni una documentación del
versiones
cual se puede recuperar Malo
archivadas de
datos guardados de los
elementos de
elementos de configuración.
configuración
SI cuentan con un
documento que tiene por
escrito la autorización para
crear o liberar líneas de
base y es el Jefe del
Líneas base y Proyecto, y es el mismo
SP 1.3 CREAR O quien hace la
descripción de
LIBERAR LINEAS documentación respectiva.
las líneas base. Excelente
BASE
Fuente:
Plan de desarrollo de
sistema de tramite
documentario, pag.19
SG 2 SEGUIR Y CONTROLAR LOS CAMBIOS
si se da los registros de las

Iniciar y registrar nuevas peticiones de
las peticiones de cambio gracias al formato
SP 2.1. SEGUIR cambio en la de listado de
LAS PETICIONES base de datos de requerimientos
DE CAMBIO peticiones de fuente: Excelente
cambio. Formato de listado de
requerimientos
Historial de No se da un control de los
SP 2.2. revisiones de los cambios a los elementos de
CONTROLAR elementos de configuración a lo largo de Malo
LOS ELEMENTOS configuración. la vida del producto.
81
DE Archivos de las No se cuenta con archivos
Malo
CONFIGURACION líneas base. de líneas de base.
SG 3 ESTABLECER LA INTEGRIDAD
No cuenta con un historial

Historial de
de revisión de los elementos
revisión de los
de configuración, pero si
elementos de
tienen un documento donde Regular
configuración
se describen algunos
elementos de configuración.
SP 3.1
ESTABLECER Registro de
REGISTROS DE cambios, copia No hay documentación
GESTION DE de peticiones, detallada de los estados de
CONFIGURACION estado de los los elementos de
elementos de configuración, las
configuración y diferencias entre ellas, las Malo
las diferencias líneas de base que priman
entre líneas de en cada una.
base.
Resultados de la
SP 3.2
auditoria de
REALIZgAR
configuración y No realizan auditoria de los
AUDITORIAS DE
elementos de elementos de configuración.
CONFIGURACION Malo
acción.
82
Análisis de resultados de la evaluación
OPORTUNIDADES DE MEJORA IDENTIFICADAS:

 No se tiene documentado los procedimientos de validación para cada
componente del producto o artefacto.
 No se tiene un documento con los defectos encontrados en el proceso de
validación.
 Todo se reporta a través de correos electrónicos.
 Todo el desarrollo se guarda en un repositorio versionado
 No hay una política organizacional documentada para esta área de
proceso.
 No se utiliza ninguna herramienta para la administración de la
configuración a nivel organizacional para el proceso de validación.
 No se lleva un control según el plan establecido por cada grupo de
proyecto.
 No se guarda información de mejora con respecto al Área de Proceso.
 No se evalúa objetivamente la adherencia del proceso.
83
84
85
86
CAPITULO III
PRESUPUESTO Y CRONOGRAMA
4.6 CRONOGRAMA DE ACTIVIDADES

FECHA ACTIVIDAD
22 de Setiembre del 2017 Propuesta y Elección del proyecto.
03 y 06 de Octubre del 2017 Elaboración del perfil del proyecto final.
13 de Octubre del 2017 Presentación del perfil de proyecto final.
Primera parte, análisis e investigación de los

14 Octubre del 2017 procesos de la Municipalidad Provincial de
Huamanga.
Elaboración del cuerpo de la

15 de Octubre del 2017
investigación (Documentación).
Distribución de actividades entre miembros del

16 de Octubre del 2017
grupo.
21 de Octubre del 2017 Revisión de actividades entre miembros del grupo.
28 de Octubre del 2017 Consolidación de actividades
02 de Diciembre del 2017

03 de Diciembre del 2017 Revisión final del proyecto y realización de los
09 de Diciembre del 2017 archivos de presentación.
14 de Diciembre del 2017 Exposición y entrega final de proyecto.
4.7 PRESUPUESTOS
Al ser un trabajo con fines académicos no se realizó una estimación en los costos
de la aplicación de la metodología.
87
BIBLIOGRAFÍA
Carnegie Mellon University. (2010). CMMI para Desarrollado, versión 1.3. (C. M.
University., Ed.) Software Engineering Institute, 555.
Carnegie Mellon University. (2011). Standard CMMI Appraisal Method for Process
Improvement (SCAMPI) Versión 1.3. Software Engineering Institute, 276.
88

Trabajo Gerencial

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Trabajo Gerencial

Загружено:

Авторское право:

Доступные форматы

NIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA

FACULTAD DE INGENIERÍA DE MINAS GEOLOGÍA Y CIVIL

“ANÁLISIS DEL SISTEMA DEL TRÁMITE DOCUMENTARIO

CURSO : Sistemas de Información Gerencial (IS 446)

1 OBJETIVOS DE LA INVESTIGACIÓN ............................................................ 6

1.1 OBJETIVO GENERAL .............................................................................. 6

1.2 OBJETIVOS ESPECIFICOS ..................................................................... 6

1.3 DELIMITACIÓN ......................................................................................... 6

1.4 MARCO TEÓRICO.................................................................................... 6

1.5 ANTECEDENTES DE LA INVESTIGACIÓN ............................................. 7

2 ELABORACIÓN DEL PROYECTO .................................................................. 8

2.1 CUERPO DE LA INVESTIGACIÓN........................................................... 8

2.1.1 RESUMEN EJECUTIVO DE LA EMPRESA ....................................... 8

3 SISTEMA DE TRAMITE DOCUMENTARIO – SISTDOC .............................. 17

4.1 OBJETIVOS DEL SISTDOC ................................................................... 19

4.2 ARQUITECTURA TECNOLOGICA ......................................................... 23

4.3 DIAGRAMA DE LA ARQUITECTURA TECNOLOGICA.......................... 24

4.4 METODOLOGÍA CMMI DEV ................................................................... 26

4.4.1 CMMI ................................................................................................ 26

4.4.2 CMMI DEV ........................................................................................ 27

4.4.3 SCAMPI ............................................................................................ 58

CAPITULO III ....................................................................................................... 87

PRESUPUESTO Y CRONOGRAMA ................................................................... 87

4.6 CRONOGRAMA DE ACTIVIDADES ....................................................... 87

4.7 PRESUPUESTOS ................................................................................... 87

El presente Proyecto evaluara el sistema de tramite documentario interno de

En la actualidad las organizaciones tienen deficiencias en la implantación de

1.1 OBJETIVO GENERAL

1.2 OBJETIVOS ESPECIFICOS

1.4 MARCO TEÓRICO

1.5 ANTECEDENTES DE LA INVESTIGACIÓN

“DESARROLLO DE PLATAFORMA WEB DE REALIZACIÓN DE SCAMPI CON

2 ELABORACIÓN DEL PROYECTO

2.1 CUERPO DE LA INVESTIGACIÓN

2.1.1 RESUMEN EJECUTIVO DE LA EMPRESA

 LA SUBGERENCIA DE ORDENAMIENTO TERRITORIAL Y CATASTRO

 SUBGERENCIA DE CENTRO HISTÓRICO

 SUBGERENCIA DE CONTROL URBANO Y LICENCIAS ES LA UNIDAD

 SUBGERENCIA DE DERECHOS DE LAS POBLACIONES VULNERABLES

 SUBGERENCIA DE JUVENTUD, EDUCACIÓN Y DEPORTE

 SUBGERENCIA DE PROGRAMAS ALIMENTARIOS Y NUTRICIÓN

 LA SUBGERENCIA DE REGISTRO CIVIL

 SUBGERENCIA DE PARTICIPACIÓN VECINAL Y CIUDADANÍA

 SUBGERENCIA DE PROMOCIÓN EMPRESARIAL Y DESARROLLO

 SUBGERENCIA DE COMERCIO, LICENCIAS Y FISCALIZACIÓN

 SUBGERENCIA DE CULTURA, TURISMO Y ARTESANÍA

 SUBGERENCIA DE ECOLOGÍA Y MEDIO AMBIENTE

 LA SUBGERENCIA DE DERECHOS DE LAS POBLACIONES

 SUBGERENCIA DE SISTEMAS Y TECNOLOGÍA

a. Planificar integralmente el desarrollo local y el ordenamiento territorial en

b. Promover, permanentemente la coordinación estratégica de los planes

c. Promover, apoyar y ejecutar proyectos de inversión y servicios públicos

d. Emitir normas técnicas generales, en materia de organización de espacio

OBJETIVO ESTRATÉGICO 02.

OBJETIVO ESTRATÉGICO 03:

OBJETIVOS ESTRATÉGICOS DEL ÁREA DE SISTEMAS Y TECNOLOGÍA

Administra la Comunicación Interna y Generación de documentos por usuario.

Figura 1 Proceso Del trámite documentario en la MPH

Figura 3 Proceso de tramite documentario Interno de la MPH.

4.1 OBJETIVOS DEL SISTDOC

4.3 DIAGRAMA DE LA ARQUITECTURA TECNOLOGICA

CAPA DE ACCESO A DATOS

AGREGAR CUALES SON LOS PROCESOS CRITICOS DE LA ORGANIZACIÓN,

El CMMI consiste en mejores prácticas que abordan el desarrollo y