Estudio de Factibilidad
-
Upload
jcesar-cusi-alvarado -
Category
Documents
-
view
220 -
download
1
description
Transcript of Estudio de Factibilidad
-
ESTUDIO DE FACTIBILIDAD
Se lleva a cabo con el fin de implantar un sistema de informacin comercial
PASOS PARA EL ESTUDIO DE FACTIBILIDAD
1. Anlisis del sistema 2. Diseo de Sistemas 3. Seleccin del Equipo
PROPOSITO DEL ESTUDIO DE FACTIBILIDAD
- Determinar La FACTIBILIDAD O No factibilidad de aplicar nuevos procedimientos de datos y/o Equipo a reas funcionales seleccionadas de una
organizacin
ESTABLECIMIENTO DEL COMIT DE ESTUDIO DE FACTIBILIDAD
La alta gerencia forma un grupo que haga el estudio de factibilidad.
Y est formado de la siguiente manera:
CANTIDAD DE PARTICIPANTES DEL COMIT DE ESTUDIO DE
FACTIBILIDAD
La Cantidad de Participantes depender de los siguientes factores:
1. El Tamao de la Organizacin 2. La Cantidad de divisiones y departamentos 3. El Grado de centralizacin y descentralizacin 4. La cantidad de Funciones Comerciales Consideradas para las nuevas
aplicaciones del procesamiento de datos
5. Las Habilidades y Aptitudes del personal de La Organizacin 6. Las Restricciones del Presupuesto 7. Las Consideraciones de Tiempo.
DEFIICION DEL ALCANCE DE ESTUDIO DE FACTIBILIDAD
El Comit Ejecutivo Define el Alcance del estudio del procesamiento de datos. (Estudio
de Factibilidad)
ETAPAS DE LA INVESTIGACION EXPLORATORIA:
Seleccin de Los Objetivos Deseados
Definicin del Problema
Determinacin de Un Programa de Avance Realista.
Comite ejecutivo
Presidente del Consejo de Administracion
Presidente Ejecutivo
Vise-Presidentes
-
DISEO E IMPLEMENTACIN DE SISTEMAS
El objetivo de esta fase es realizar las actividades necesarias para poner a disposicin de
los usuarios el sistema de informacin.
El cumplimiento de los requerimientos de implantacin definidos en el Catalogo de Requerimientos y especificados en la actividad Establecimiento
de Requerimientos de Implantacin.
La estrategia de transicin del sistema antiguo al nuevo.
Finalmente, se realizan las acciones necesarias para el inicio de la puesta en produccin
del sistema de informacin
ACTIVIDAD 1: DEFINICIN DEL PLAN DE IMPLANTACIN
En esta actividad se revisa la estrategia de implantacin para el sistema. Se analizan las
posibles dependencias con otros Sistemas, que puedan condicionar el plan de
implantacin.
Participantes de esta actividad: Analista de Atencin a Usuarios, Operador, Equipo de
Usuarios, Analista de Soporte Tcnico, Analista de Sistemas.
Responsable de esta actividad: Analista de Atencin a Usuarios
Tarea 1.1: Definicin del Plan de Implantacin La estrategia de implantacin del sistema se habr determinado basndose en
la informacin acumulada de las anteriores fases.
Una vez analizada la informacin anterior, se define un plan de , Dicho plan
debe contemplar todas las tareas relacionadas con:
La capacitacin necesaria para la implantacin al equipo de trabajo que se
encarga de realizar la implantacin.
La preparacin de la infraestructura necesaria para la incorporacin del
sistema al entorno de produccin.
La instalacin de todos los componentes y procedimientos manuales y
automticos asociados a cada sistema de informacin implicados en la
implantacin.
La ejecucin de los procedimientos de carga inicial y migracin de datos,
si se determin su necesidad.
Prcticas
Sesiones de trabajo
Tarea 1.2: Especificacin del Equipo de Implantacin Se constituye el equipo de implantacin que son integrantes del Equipo de
trabajo necesario para llevar a cabo la implantacin del sistema, segn el plan
de implantacin establecido en la tarea anterior.
-
ACTIVIDAD 2: PREPARACIN DEL ENTORNO DE PRODUCCIN Aqu El objetivo es planificar que todos los recursos estn disponibles para la puesta en
produccin de los Sistemas de Informacin.
Participantes de esta actividad: Analista de Soporte Tcnico, Analista de Atencin a
Usuarios, Analista de Sistemas, Operador.
Responsable de esta actividad: Analista de Soporte Tcnico.
Tarea 2.1: Preparacin del Entorno de Produccin En esta tarea se disponen todos los recursos necesarios para realizar la puesta
en produccin de los componentes y subsistemas que conforman el sistema de
informacin.
ACTIVIDAD 3: CAPACITACIN PARA LA IMPLANTACIN Aqu se prepara y se imparte la capacitacin al equipo que participar en la implantacin
del sistema, y al personal de Atencin a Usuarios que realizar las actividades de Post-
Implantacin. Se realiza tambin el seguimiento de la capacitacin de los usuarios finales,
de esta forma, se asegura que la implantacin se llevar a cabo correctamente.
Participantes de esta actividad: Analista de Atencin a Usuarios, Analista Funcional
Responsable de esta actividad: Analista de Atencin a Usuarios
Tarea 3.1: Preparacin de la Capacitacin del Equipo de Implantacin
Se define la Capacitacin necesaria para el equipo de trabajo responsable de la implantacin del sistema, estableciendo el esquema de capacitacin para
cada tipo de perfil dentro del equipo y la duracin estimada de los cursos.
Asimismo, se aseguran los recursos humanos, tcnicos y materiales necesarios para realizar la capacitacin al equipo de implantacin.
Por ltimo, se convoca a las personas que deben asistir a los cursos de capacitacin y se espera la confirmacin de las personas seleccionadas para la
capacitacin.
Tarea 3.2: Capacitacin del Equipo de Implantacin
En esta tarea se lleva a cabo la capacitacin del equipo que va a ser responsable de la implantacin del sistema, segn el Plan de Capacitacin que se haya
establecido en la tarea anterior, asegurando la asistencia y evaluacin de todos
sus integrantes.
Tarea 3.3: Preparacin de la Capacitacin al rea de Atencin a Usuarios, Soporte Tcnico y Operaciones Se define la Capacitacin necesaria para los miembros del rea de Atencin a
Usuarios y el personal de Soporte Tcnico y Operaciones, tenindose en
cuenta la asistencia informtica que brindar esta rea a los usuarios con
respecto al sistema que se est implantando. Por lo tanto la capacitacin
debera integrar conocimientos de todos los aspectos del sistema con el fin de
poder resolver las consultas de los usuarios finales, e identificar cules de estas
consultas sern derivadas al rea de Desarrollo de Sistemas.
-
Tarea 3.4: Capacitacin del rea de Atencin de Usuario, Soporte Tcnico y Operaciones En esta tarea se lleva a cabo la capacitacin del rea de Atencin a Usuarios,
Soporte Tcnico y Operaciones, segn el plan aprobado en la tarea anterior,
asegurando la asistencia y evaluacin de todos sus integrantes.
Tarea 3.5: Preparacin de la Capacitacin a Usuarios finales En funcin del plan de implantacin establecido, se revisa el esquema de
capacitacin a los usuarios finales, elaborado en la actividad Definicin de la
Capacitacin de Usuarios Finales. Se asegura que se cuenta con los recursos
humanos, tcnicos y materiales necesarios para realizar la capacitacin
correspondiente.
Se determina, los contenidos definitivos que tienen los cursos, cundo deben
impartirse, quines han de recibirlos y con qu prioridad.
Tarea 3.6: Seguimiento de la Capacitacin a Usuarios Finales Es necesario llevar a cabo su seguimiento con el fin de asegurar el
cumplimiento del Plan de Capacitacin previsto e informar de las posibles
desviaciones para tomar las medidas oportunas, para esto se debe realizar
evaluaciones a los usuarios participantes en la capacitacin y hacer un
seguimiento de la asistencia al mismo.
ACTIVIDAD 4: PUBLICACION DE PROCEDIMIENTOS NORMATIVOS Aqu el Analista Funcional conjuntamente con el Lder y el Ejecutivo del Proyecto deben
realizar todas las acciones necesarias para que el titular de la institucin apruebe y ordene
publicar estos procedimientos en el menor tiempo posible.
Participantes de esta actividad: Analista Funcional, Coordinador del Proyecto, Analista
de Atencin a Usuarios
Responsable de esta actividad: Analista Funcional
Tarea IMS 4.1: Publicacin de los Procedimientos Normativos En esta tarea se publica los procedimientos aprobados en la tarea CPS 8.1
Evaluacin de Procedimientos Normativos.
ACTIVIDAD 5: INSTALACION DEL SISTEMA Esta actividad tiene como objetivo establecer el punto de inicio en que el sistema pasa a
produccin. Para ello es necesario que, se disponga del entorno de produccin
perfectamente instalado en cuanto a hardware y software de base, componentes del nuevo
sistema y procedimientos manuales y automticos.
Participantes de esta actividad: Operador, Analista de Soporte Tcnico, Analista de
Telecomunicaciones, Analista de Atencin a Usuarios.
Responsable de esta actividad: Operador
Tarea 5.1: Revisin del Pase a Produccin En esta tarea se proceder a verificar la estructura del documento de Pase a
Produccin, revisando los datos relevantes del contenido del mismo, luego del
cual se proceder a ejecutar el Pase de Produccin.
-
Tarea 5.2: Ejecucin del Pase a Produccin En esta tarea se proceder a ejecutar la instalacin de acuerdo al pase de
produccin. Se registrar el resultado de la instalacin y las incidencias que
ocurran durante el proceso y la conclusin del pase a produccin.
ACTIVIDAD 6: PUESTA EN MARCHA DEL SISTEMA En esta actividad se pone en marcha el sistema y estar a cargo del equipo de Usuarios.
Participantes de esta actividad: Equipo de Usuarios, Analista de Atencin a Usuarios.
Responsable de esta actividad: Equipo de Usuarios
ACTIVIDAD 7: REUNION DE GESTION El objetivo de esta actividad es asegurar que exista una Reunin de Gestin entre el
Coordinador del Proyecto, el Lder Usuario y el Ejecutivo del Proyecto en donde se revise
la Formulacin del Proyecto y de haber alguna modificacin o ajuste a este documento,
ste deber ser aprobado por el Comit de Gestin. En esta reunin se buscar la
aprobacin formal de la implantacin del sistema por parte del Lder Usuario.
EL MODELO 4+1
La arquitectura software trata el diseo e implementacin de la estructura de alto nivel
del software.
Perry y Wolf (1992) describen una arquitectura software como:
Arquitectura Software = Elementos, Formas, Fundamento/Restricciones
Una vista es una presentacin de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva (Kruchten, 1995). El modelo ms aceptado a la hora de establecer las vistas necesarias para describir una arquitectura
software es el modelo 4+1 (Kruchten, 1995).
Este modelo define 4 vistas principales:
Vista Lgica (Logical View), modelo de objetos, clases, entidad relacin, etc.
Vista de Proceso (Process View), modelo de concurrencia y sincronizacin.
Vista de Desarrollo (Development View), organizacin esttica del software en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.).
Vista Fsica (Physical View), modelo de correspondencia software - hardware (aspectos de distribucin en mquinas, por ejemplo)
El modelo 4+1 aplica la ecuacin de Perry y Wolf (1992) de forma independiente
para cada vista, por ejemplo, cada vista puede definir un conjunto de elementos para
su uso (componentes, contenedores y conectores).
Y por ltimo, tambin comentar que el modelo de vistas 4+1 es genrico: otras notaciones y herramientas a parte de UML pueden usarse, y cualquier mtodo de
diseo, especialmente para las descomposiciones lgicas y de proceso.
-
1. ARQUITECTURA LGICA (LOGICAL ARCHITECTURE)
Soporta el anlisis y la especificacin de los requisitos funcionales: lo que el sistema
debera proporcionar en trminos de servicios a sus usuarios
En esta vista se usan comnmente los diagramas de clases, los de interaccin y
objetos.
Notacin: La notacin ms usada es UML, y dentro de esta diagramas de clases
y paquetes.
Estilo: El estilo ms usado para la vista lgica es el Orientado a Objetos.
2. ARQUITECTURA DE PROCESOS (PROCESS ARCHITECTURE) Se tratan algunos requisitos no funcionales. Ejecucin, disponibilidad, tolerancia a
fallos, integridad, etc.
La vista se centra por tanto en la concurrencia y distribucin de procesos.
Notacin: La notacin ms usada es UML, y dentro de esta diagramas estados,
actividad y similares.
Estilo: pueden encajar varios estilos. Por ejemplo, tomando la taxonoma de
Garlan y Shaw (1993), pueden usarse tuberas y filtros Cliente Servidor. Para sistemas ms complejos puede usarse un estilo similar a la ISIS system's process
groups, como describe Kenneth Birman (1994) .
3.- ARQUITECTURA DE DESARROLLO (DEVELOPMENT ARCHITECTURE)
La vista de desarrollo o despliegue se enfoca en la organizacin de los mdulos
software en el entorno de desarrollo.
Esta organizacin del software se suele apoyar en diagramas de mdulos o de
subsistemas que muestran las relaciones de exportacin (export) e importacin
(import).
Y destacar que podr describirse la vista de desarrollo por completo solamente
despus de haber identificado todos los elementos software.
Notacin: La notacin ms usada es UML, y dentro de esta diagramas de
componentes y paquetes.
Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista de
desarrollo. Una regla de diseo es que un subsistema puede solamente depender
de subsistemas en la misma capa o en las menores. Esto minimiza las
dependencias entre mdulos a favor de una ms simple estrategia capa capa.
4. ARQUITECTURA FSICA (PHYSICAL ARCHITECTURE) La vista fsica se centra en los requisitos no funcionales, tales como la disponibilidad
del sistema, la fiabilidad (tolerancia a fallos), ejecucin y escalabilidad. Y tambin
presenta cmo los procesos, objetos, etc., corresponden a nodos de proceso:
Componentes: nodos de proceso.
Conectores: LAN, WAN, bus, etc.
Contenedores: subsistemas fsico
-
5. ESCENARIOS (SCENARIOS) La vista de escenarios corresponde con instancias de casos de uso que unifican todas
las vistas. As, desde casos de uso se debiera poder hacer una trazabilidad a todos los
componentes del sistema software, viendo, por ejemplo, que mquinas, o clases, o
componentes, o .jar, o procesos, son los responsables de que el sistema cubra una
cierta funcionalidad.
6. RELACIN ENTRE LAS VISTAS
Como sucede en otras muchas ocasiones, si bien el modelo no es una metodologa s
que "sugiere" un mtodo de trabajo. Parece lgico que la vista de escenarios o casos
de uso sea la de arranque, y que de ah se pase a la vista lgica.
7. ARQUITECTURA Y UML Se ha ido exponiendo a lo largo de la explicacin de cada una de las vistas su
translacin a un lenguaje de modelado concreto como UML. Hay que tener en cuenta
que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no exista una
clara relacin entre ambos, lo que a menudo produce confusin al diseador que en
la actualidad quiere modelar una arquitectura con ambas herramientas. A modo de
resumen la translacin se presenta en la siguiente tabla:
Vista UML
Escenarios Casos de Uso
Lgica Clases, de Estados y Colaboracin
Desarrollo Componentes
Fsica Despliegue
Procesos Actividad, Estados, Secuencia
XITO Y FRACASO DE LOS SISTEMAS: IMPLEMENTACIN
FRACASO DE LOS SISTEMAS DE INFORMACIN
Sistemas que no tienen el desempeo esperado, que no est funcionando en el plazo especfico.
Puede considerase que hasta el 75% de los sistemas constituye fracasos operativos
Muchos sistemas no se estn empleando como deban hacerlo.
REAS PROBLEMAS DE LOS SISTEMAS DE INFORMACIN
Son:
Area de Operaciones Area de Diseo Area de Datos Area de Costos
-
MEDICIN DEL XITO DE LOS SISTEMAS
cmo es posible saber si un sistema tiene xito o no?
Los investigadores de MIS tienen diferentes criterios para medir el xito de un sistema de informacin, pero consideran que estas 5 medidas son las ms
apropiadas:
o Niveles Altos del Uso del Sistema
o Satisfaccin de los usuarios con el sistema
o Actitud Favorables hacia la Funcin de IS
o Logro de Objetivos del Sistema
o Recompensa Financiera
CAUSAS DEL XITO Y FRACASO DE LOS SI
Muchos sistemas fracasaron debido a la posicin del entorno, o bien, a la situacin interna
Los SI tienen impactos a las conductas y la organizacin.
Implementacin.- Todas las actividades de la organizacin encaminadas a adoptar,
administrar y hacer rutinaria una innovacin.
Agente de Cambio.- En el contexto de la implementacin, la persona que acta como
catalizador durante el proceso de cambio, para asegurar el xito en la adaptacin de la
organizacin a un sistema nuevo o una innovacin.
ACTORES EN EL PROCESO DE INNOVACIN
El unico Protagonista es La Conducta Innovadora
CAUSAS DE XITO Y FRACASO DE LA IMPLEMENTACIN
Puede estar determinado en gran medida por los siguientes factores:
El rol de los usuarios en el proceso de implementacin
El grado en que la administracin apoya la labor de implementacin
El nivel de complejidad y riesgo del proyecto de implementacin
La calidad de administracin del proceso de implementacin
FACTORES PARA EL XITO O FRACASO DE LOS SI
Participantes e influencia de los usuarios (Diseo)
Apoyo administrativo (Costo)
Nivel de Complejidad/Riesgo (Operaciones)
Manejo de Proceso de Implementacin (Datos)
1.- PARTICIPACIN E INFLUENCIA DE LOS USUARIOS
Esto tiene varios resultados positivos
Si los usuarios participan ms intensamente en el diseo, tienen ms oportunidades de modelarlo.
Produce mejores soluciones
-
Brecha de comunicaciones usuario-diseador
Los usuarios y especialistas en sistemas suelen tener diferentes antecedentes,
intereses y prioridades que obstaculiza la comunicacin y resolucin de problemas.
2.- APOYO Y COMPROMISO DE LA ADMINISTRACIN
El respaldo de la administracin asegurar que le apoyo del proyecto de sistemas recibir el financiamiento y los recursos suficientes para tener xito.
Hay ocasiones en que este se compromete demasiado con un proyecto e invierte recursos excesivos en una labor de desarrollo de sistemas.
Es menos indispensable en caso de negocios pequeos
3.- NIVEL DE COMPLEJIDAD/RIESGO
Los sistemas difieren drsticamente en su tamao, alcance, nivel de complejidad y componentes tcnicos y de organizacin.
Los investigadores han identificado tres dimensiones clave que influyen en el nivel de riesgo de los proyectos:
Tamao del proyecto (a mayor tamao, mayor riesgo)
Estructura del proyecto (salidas y procesos)
Experiencia del proyecto (conocimientos tcnicos)
4.- ADMINISTRACIN DEL PROCESO DE IMPLEMENTACIN
El desarrollo de un sistema nuevo se debe manejar y orquestar con mucho cuidado
Es preciso evaluar costos, beneficios y calendarios del proyecto
Mal Manejo=Costos Excesivos, Plazo No Cumplido, Deficiencias Tcnicas que Perjudican el desempeo y No Producen Los Beneficios Esperados.
Por qu se manejan tan mal los proyectos?
a. Ignorancia y optimismo.- Las tcnicas para estimar el tiempo requerido no estn bien desarrolladas.
b. El mito del mes-hombre.- Unidad de medicin tradicional que emplean los diseadores de sistemas para estimas el tiempo que requiere el desarrollo de un
proyecto.
EL RETO DE LA REINGENIERA DE PROCESOS DE NEGOCIO (BPR) Y LA
PLANIFICACIN DE RECURSOS DE EMPRESA (ERP)
El 70% de todos los proyectos de reingeniera de procesos de negocios no proporcionan los beneficios prometidos
Los problemas tanto del BPR como de ERP forman parte del mayor conflicto de la implementacin en las organizaciones y el manejo del cambio.
-
EL PROCESO DE IMPLEMENTACIN: QU PUEDE SALIR MAL?
Los siguientes problemas se consideran tpicos de cada etapa del desarrollo de sistemas,
cuando no se maneja correctamente el proceso de implementacin
1) ANLISIS
No se asign tiempo, dinero ni recursos a investigar el problema
Poco o ningn tiempo a la planificacin preliminar
Personal inadecuado
Promesa de resultados imposibles de entregar
documentacin insuficiente
Malas entrevistas
2) DISEO Los usuarios no contribuyen a sta El sistema est diseado nicamente para satisfacer las necesidades actuales Cambios drsticos sin un anlisis de impacto Las especificaciones funcionales no estn debidamente documentadas
3) PROGRAMACIN Se subestima el tiempo y el dinero necesario Especificaciones incompletas Poco tiempo al desarrollo de la lgica de los programas Los programadores no aprovechan plenamente las tcnicas de diseo
estructurado o O.O.
Los programadores no se documentan debidamente No se programan los recursos necesarios 4) PRUEBAS Se subestima el tiempo y dinero necesarios para realizar suficientes pruebas. El equipo de proyecto no prepara un plan de pruebas organizados Los usuarios no participan lo suficiente en las pruebas El equipo de implementacin no prepara pruebas de aceptacin adecuadas
5) CONVERSIN Poco tiempo y dinero para las actividades de conversin No todas las personas que usarn el sistema participan antes de iniciarse la
conversin
Para compensar los excedentes de costos y retrasos, se pone en funcionamiento el sistema antes de que est listo
La documentacin del sistema y los manuales de usuario son incompletos No se realizan evaluaciones ni se establecen normas de desempeo Las estipulaciones de manejo del sistema son insuficientes.
MANEJO DE LA IMPLEMENTACIN
Es factible aumentar la posibilidad de xito, si se anticipan los posibles problemas de implementacin y se aplican estrategias de correccin apropiadas.
-
CONTROL DE FACTORES DE RIESGO
Se deben adoptar un enfoque de contingencias para la administracin de
proyectos y manejar cada proyecto con las herramientas y metodologas adecuadas.
Existen cuatro tcnicas bsicas de administracin de proyectos:
1. Herramientas de integracin externa que enlazan la labor del equipo de implementacin con la de los usuarios en todos los niveles de la organizacin.
2. Herramientas de integracin interna que garantizan que el equipo de implementacin como una sola unidad integrada.
3. Herramientas de planificacin formal para estructurar y ordenar las tareas, al estimar por adelantado el tiempo, el dinero y los recursos tcnicos necesarios
para llevarlas a cabo.
4. Herramientas de control formal que ayudan a monitorear el avance hacia las metas.
COMO SUPERAR LA RESISTENCIA DE LOS USUARIOS
Capacitando a los usuarios para usar correctamente el sistema de informacin, as es
ms probable que se sientan satisfechos de l.
Los investigadores han explicado la resistencia de los usuarios con una de tres teoras:
Teora orientada hacia las personas. Estrategia deliberada para frustrar la implementacin de un sistema de informacin o de una innovacin en una
organizacin.
Teora orientada hacia los sistemas. Factores inherentes al diseo crean resistencia al sistema entre los usuarios.
Teora de interaccin. La resistencia se debe a la interaccin de factores de personas y sistemas
DISEO PARA LA ORGANIZACIN
El propsito de un sistema es mejorar el desempeo de la organizacin.
ste debe considerar explcitamente las formas en que la organizacin cambia cuando se instale el nuevo sistema.
Anlisis de impacto de la organizacin.- Explica como un sistema propuesto afecta la
estructura, las actitudes, la toma de decisiones y las operaciones de la organizacin.
FACTORES ORGANIZACIONALES EN LA PLANIFICACIN E
IMPLEMENTACIN DE SISTEMAS
Participacin e inters de los empleados Diseos propuestos Estndares y monitoreo de desempeo Ergonoma (Incluido equipo, interfaces con el usuario y entorno de trabajo) Procedimientos para resolver quejas de empleados Salud y seguridad Cumplimiento con disposiciones gubernamentales
-
CONSIDERACIN DEL FACTOR HUMANO
La calidad de los sistemas de informacin se debe evaluar en trminos de los criterios de los usuarios, no de los criterios del personal de SI
Las reas en los que el usuario interacta con el sistema se debe disear con mucho cuidado y considerar aspectos de ergonoma.
DISEO SOCIO TCNICO
Establece objetivos humanos para el sistema, que producen una mayor satisfaccin en el trabajo
Disear para producir sistemas de informacin que combinan eficiencia, tcnica con sensibilidad, para las necesidades de la organizacin y de las personas.
-
Integracin de CMMI y PMBOK
Los pasos sugeridos para el proceso de implementacin de CMMi desde la gerencia de
proyectos con PMBOK, los hemos conceptualizado as:
1) DETERMINACIN DEL OBJETIVO DEL MEJORAMIENTO Siempre el objetivo debe estar ligado a una meta de negocio, no a mejorar por mejorar. A travs
de la definicin de la meta de negocio se obtiene el nivel de madurez deseado.
2) ESTABLECIMIENTO DE LA SITUACIN ACTUAL EN ADMINISTRACIN DE PROYECTOS Podemos apoyarnos en el Organizational Project Management Maturity Model (OPM3), otro
de los estndares de gerencia de proyectos del PMI, que nos permite evaluar el nivel de madurez
de la organizacin en cuanto a la gerencia de proyectos se refiere.
3) ESTABLECIMIENTO DE LA SITUACIN ACTUAL EN INGENIERA En esta rea el PMBOK no aporta en su totalidad por lo que deberemos referirnos a las reas de
proceso de ingeniera y a las mejores prcticas de la industria especfica en que se lleve a cabo el
mejoramiento.
4) ESTABLECIMIENTO DE LA SITUACIN ACTUAL EN GESTIN DE PROCESOS Nos permite establecer los trabajos previos de definicin de estndares, documentacin, archivos
de procesos, biblioteca de procesos y dems elementos de soporte a la definicin, documentacin
y despliegue de procesos y prcticas.
PAs: Process Areas
OPD: Organizational Process Definition
OPF: Organizational Process Focus
5) SOCIALIZACIN DE LA SITUACIN ACTUAL DE LA ORGANIZACIN Aqu se presenta la situacin actual y el objetivo de mejoramiento establecido, indicando el nivel
de compromiso que se requiere para llegar a la meta y una estimacin del tiempo del esfuerzo a
realizar, bajo los supuestos adecuados de disponibilidad de personal y compromiso de la alta
gerencia.
6) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN ADMINISTRACIN DE PROYECTOS Aqu establecen los puntos de entrenamiento en gerencia de proyectos, se sugiere siempre llevar
este entrenamiento al pblico ms amplio posible y de la manera ms completa en los logros que
se ha planteado la organizacin.
7) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN INGENIERA Con base en las mejores prcticas que se ha identificado que requieren mejoramiento o
implantacin, cubriendo siempre las PAs de ingeniera del nivel deseado de madurez y
apoyndose en las mejores prcticas de la industria objetivo de la organizacin.
4P: Personas, Procesos, Producto, Proyecto
8) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN GESTIN DE PROCESOS Si se requiere capacitar a la organizacin o a un rea especfica que se encargar de la
administracin de los procesos, se lleva a cabo este plan de entrenamiento
9) EJECUCIN DE PLANES DE ENTRENAMIENTO Los entrenamientos planteados se llevan a cabo manteniendo un rastreo a los participantes,
seguimiento al desarrollo de cada entrenamiento y una medicin de efectividad y relevancia a lo
largo de todo el proyecto, proveyendo los refuerzos que se requieran a lo largo del mismo.
-
10) DEFINICIN DE LOS EQUIPOS DE TRABAJO DE MEJORAMIENTO Una vez dictados los entrenamientos, o a la par con los mismos, se definen los equipos que
llevarn a cabo la definicin de procesos, prcticas y el pilotaje y despliegue de los mismos.
11) DESARROLLO DEL PLAN DE IMPLEMENTACIN DE GESTIN DE PROCESOS Este plan es especfico para el equipo de mejoramiento de procesos y define la forma de atacar
los puntos de mejora encontrados, el orden, la prioridad y las reglas del equipo.
12) DESARROLLO DEL PLAN DE MEJORAMIENTO DE GERENCIA DE PROYECTOS Especficamente para el grupo a cargo del mejoramiento de la gerencia de proyectos. Es
importante que en este grupo participen todos los gerentes, lderes o coordinadores de proyectos
de la organizacin, quienes conocen la forma especfica de trabajo.
13) DESARROLLO DEL PLAN DE MEJORAMIENTO DE INGENIERA Enfocado en los puntos de mejora de ingeniera, se desarrolla con los practicantes tcnicos de la
organizacin, indicando las prcticas a implantar, seleccionadas de los entrenamientos y acordes
con la compaa.
14) DISEO DE PRCTICAS Cada uno de los equipos de mejoramiento disea, entonces, las prcticas adecuadas para cubrir
las oportunidades de mejora
15) VERIFICACIN DE PRCTICAS DISEADAS CONTRA MODELO CMMI Antes de pilotar las prcticas debe verificarse que cubran las brechas encontradas en la evaluacin
contra las prcticas de las PAs de CMMi
16) PILOTAJE DE PRCTICAS Una vez definidas las prcticas, se pilotan en proyectos especficos o situaciones que permitan
evaluar su correccin, completitud y relevancia para el objetivo de la organizacin.
17) AJUSTE DE PRCTICAS Como resultado del pilotaje se obtendrn puntos de mejora o ajuste a las prcticas definidas. Una
vez ajustadas se establecen como lnea base del proceso.
18) DESPLIEGUE DE PRCTICAS El despliegue de prcticas estar a cargo de los equipos de mejoramiento quienes establecern,
tambin, la forma en que sern incorporadas.
19) OBTENCIN DE EVIDENCIAS Durante la utilizacin de las prcticas debe mantenerse un levantamiento de evidencias tendiente
a generar la Base de Datos de los Indicadores de Implementacin de Proceso (PIIDB).