Conocimiento Base ProSoftCol - Trabajos de Grado | Ingeniería de

Conocimiento Base ProSoftCol
Ximena Higuera Moriones
Este documento pretende que todo el conocimiento que pueda ser aplicable
al proyecto ProSoftCol:Guía Metodológica de Mejora de Procesos de Construcción de Software Adaptada para MIPyMES_DS Colombianas quede descrito y
bien establecido. Se presentan los 3 modelos que serán la base para el proyecto:
CMMI, MoProSoft y CompetiSoft. Para cada modelo se especicará su precedencia o justicación de existencia, su estructura, sus patrones de proceso y sus
aportes a ProSoftCol (aunque esto último no hace parte del conocimiento base).
Introducción
Para entender el alcance de los modelos de mejora de procesos presentados
aquí, es necesario tener claro 2 conceptos: Modelo y Proceso. Un modelo es
considerado un lineamiento con las mejores prácticas que han sido encontradas
y aplicadas por organizaciones altamente funcionales y exitosas; no contiene
una secuencia de pasos necesarios para implementar un programa de mejora de
procesos, simplemente dice "esto es algo bueno para hacer " [1]. Para el Software
Engineering Institute existen 3 dimensiones en las que una organización puede
enfocar una mejora: Personas, Procedimientos y Métodos, y Herramientas y
Equipos. Lo que encierra a éstas 3 dimensiones se llama proceso, el proceso que
se usa dentro de una organización y que permiet alinear la forma en la que se
dirige la organización, ya que provee una forma de incorporar el conocimiento
de "cómo hacer mejor las cosas". Enfocarse en los procesos permite lidiar con
el cambio constante y trabajar de una forma más inteligente (no más dura ni
exhaustiva). Con esto se llega a una armación que se ha sostenido por años:
"La calidad de un sistema o de un producto está altamente inuenciada por la
calidad del proceso que se utiliza para desarrollarlo y mantenerlo y ésta es la
premisa fundamental de CMMI [2].
1
2
CMMI
Capability Maturity Model Integration es un modelo para mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de
software creado por el Software Engineering Institute (SEI), diseñado para integrar la gran cantidad de modelos que han sido creados a través de los años por
ésta y otras organizaciones [1]. Provee un conjunto de prácticas reconocidas por
la industria para la productividad, desempeño y costo de desarrollo de software
[3] , su objetivo es el logro de procesos óptimos repetibles en el desarrollo de
software.
En la actualidad hay 3 áreas de interés cubiertas por los modelos de CMMI,
éstas son Desarrollo, Adquisición y Servicios.
CMMI for Development (CMMI-DEV)
•
Modelo de referencia que cubre el desarrollo y mantenimiento de las
actividdes de aplicación a productos y servicios.
•
Prácticas
◦
◦
◦
◦
◦
Proyectos
Procesos
Ingeniería de Sistemas
Ingenieria de Software
Ingeniería de Hardware
CMMI for Services (CMMI-SVC)
•
Guías para reducir costos y mejorar la calidad
CMMI for Acquisition (CMMI-ACQ)
•
Mejora de gestión de abastecimiento de servicios y productos
•
Adquirir soluciones que satisfagan necesidades de la organización
Disciplinas de CMMI
Actualmente 4 Bodies of Knowledge (Cuerpos de Conocimiento) estan cubiertas cuando se planea mejorar los procesos con CMMI [2]:
Ingeniería de Sistemas: Cubre el desarrollo de los sistemas, puede o no
incluir software.
Ingenieria de Software: Cubre el desarrollo de sistemas de software.
Desarrollo Integrado de Productos y Procesos: Es un acercamiento sistemático que logra una colaboración de los stakeholders relevantes a través
de la vida del producto para satisfacer las necesidades, expectativas y
requerimientos del cliente.
3
Proveedores: Cubre la adquisición de productos que se realiza por medio
de los proveedores.
Estructura de CMMI
CMMI está estructurado de la siguiente manera [1] :
Niveles de Madurez (Representación Escalonada) o Niveles de Capacidad
(Representación Continua)
Áreas de Proceso: Sus componentes están agrupados en 3 categorías
•
Requeridos
•
Esperados
•
Informativos
Metas: Genéricas y Especícas
Características Comunes
Prácticas: Genéricas y Especícas
Representación Escalonada
Usa niveles de madurez y conjuntos predenidos de áreas de proceso para
denir el camino de mejora [2]. Un nivel de madurez signica el desempeño que
puede ser esperado de una organización, por ejemplo: organizacionez con nivel
de madurez 1 tienen procesos ad-hoc y organizaciones con nivel de madurez 2
tienen una gestión de proyectos básicas.
Existen 5 niveles de madurez, y cada uno consuste de varias áreas de proceso
[1]:
1 - Inicial
Las organizaciones no tienen un proceso estructurado, su desarrollo es
caótico y ad-hoc; los presupuestos y el calendario se exceden con frecuencia
y la calidad del producto no puede ser predicha.
En términos generales no hay absolutamente nada estructurado, y se podría decir que encontrarse en este nivel es algo no deseado, por esto ninguna organización busca obtener una valoración en un nivel de madurez
1 de CMMI.
2 - Controlado
Los procesos básicos de gestión son llevados a cabo y además son seguidos
y documentados.
Es intuitivo, el proceso depende de los inviduos.
4
3 - Denido
La organización tiene un conjunto propio de procesos estándar.
Las siguientes características de los procesos son claramente denidas:
Propósito, entradas, criterios de entrada, actividades, roles, medidas, pasos
de vericación, saludas y criterios de salida.
La diferencia entre este nivel y el 2 es que en éste los procesos son descritos
en más detalle y más rigurosamente. Además, este nivel es más sosticado
y organizado, ya se ha desarrollado una identidad de la organización.
4 - Cuantitativamente Controlado
La organización controla sus procesos con estadísticas y otras técnicas
cuantitativas.
La calidad del producto, del servicio y el desempeño del proceso son entendidos en términos estadísticos y son controlados durante el ciclo de vida
del proceso.
Se concentra en el uso de métricas para tomar decisiones, para medir si
hay progreso dentro de la organización y si algún producto mejora.
Meintras que en el nivel anterior (3) los procesos son cualitativamente
predecibles, aquí son cuantitativamente predecibles.
5 - Optimizado
Los procesos son constantemente mejorados, basándose en un entendimiento común de las causas de variación de los mismos.
Todas las personas son miembros productivos del equipo, los defectos son
reducidos y el producto es entregado a tiempo y con presupuesto planeado.
Cómo Alcanzar un Nivel de Madurez
Si se quiere alcanzar un nivel de madurez n, se deben satisfacer todas las
metas del nivel n-1 y del nivel n. Cada nivel consiste de una cierta cantidad
de áreas de proceso (no siempre es la misma cantidad), y cada área de proceso
tiene metas para ser cumplidas, que a la vez tienen prácticas asociadas como l
muestra la Figura 1.
5
Fig. 1: Representación Escalonada CMMI [1, 2]
Representación Continua
Usa niveles de capacidad y permite a la organización elegir un área particular
de proceso y mejorar en ella. Provee libertad para escoger el orden de mejora
que se adapte mejor a los objetivos de negocio de la organización [4]. Un nivel de
capacidad se enfoca en madurar la habilidad de una organización para realizar,
controlar y mejorar su desempeño en un área de proceso.
Existen 6 niveles de capacidad [1]:
0 - Incompleto
Un proceso incompleto no implementa en su totalidad las prácticas ni
genéricas ni especícas del nivel de capacidad 1.
Es semejante al nivel 1 de madurez en la representación escalonada.
1 - Desarrollado
Es un proceso que se espera que desarrolle todas las prácticas genéricas y
especícas de este nivel.
Signica que se está haciendo algo, pero no se puede probar si está funcionando o no.
2 - Controlado
Se tienen algunas métricas que son constantemente recolectadas y aplicadas.
6
Un proceso controlado es planeado, ejecutado, monitoreado y controlado
para proyectos individuales, grupos o procesos que alcanzan un propósito
dado.
Controlar o administrar los procesos logra tanto los objetivos del modelo para el proceso, tanto como otros objetivos como costo, calendario y
calidad.
3 - Denido
En este punto existe una forma organizacional de hacer el trabajo, de
hacer las cosas, que diere de la forma en que las otras organizaciones lo
hacen. Esta forma de hacer las cosas debe estar documentada y medida;
las personas deben estar entrenadas en ella y los resultados deben ser
rastreados.
4 - Cuantitativamente Controlado
Es un proceso denido que es controlado por medio de técnicas estadísticas.
Calidad del producto, del servicio, desempeño del proceso y otros objetivos de negocio son entendidos en términos estadísticos y son controlados
durante todo el ciclo de vida.
5 - Optimizado
Es un proceso que está cuantitativamente controlado y además mejorado,
basándose en un entendimiento de las causas comunes de las variaciones
del proceso que sean relevantes para el mismo.
Se enfoca en mejorar continuamente el desempeño del proceso, a través de
mejoras incrementales e innovadoras.
Tanto el proceso denido como el conjunto de procesos estándares de la
organización son objetivos de mejora.
Cómo Alcanzar un Nivel de Capacidad
Para alcanzar un nivel de capacidad se deben cumplir las prácticas especícas
del área de proceso en la que se quiere alcanzar dicho nivel y además deben ser
implementadas todas las prácticas genéricas que existen para dicho nivel de
capacidad. Las prácticas genéricas pertenecen a muchas áreas de proceso y no
sólo a una, de modo que incluso en esta representación hay conexión y relación
entre las áreas de proceso (así la organización escoja una sóla para mejorar) ;
tal como lo ilustra la Figura 2.
7
Fig. 2: Representación Continua CMMI [2, 1]
La Tabla 1 ilustra las principales diferencias entre la representación escalonada y la continua
Tab. 1: Comparación Representaciones CMMI [2]
Representación Escalonada Representación Continua
La
organización
selecciona
las
áreas de proceso según los niveles
de madurez
La
organización
selecciona
las
áreas de proceso y los niveles de
capacidad según sus objetivos de
mejora de procesos.
La mejora se mide utilizando ni-
La mejora se mide utilizando ni-
veles de madurez, que:
veles de capacidad, que:
Moden la madurez de un
Miden la madurez de un
conjunto de procesos en to-
proceso particular en toda
da la organización
la organización
Se calican de 1 a 5
Se calican de 0 a 5
Los niveles de madurez se usan
para establecer un objetivo y realizar el seguimiento de la mejora
de procesos.
Los perles de nivel de capacidad
se usan para establecer un objetivo y realizar el seguimiento del
rendimiento de la mejora de procesos.
8
Componentes Áreas de Proceso
Las áreas de proceso son un clúster de las buenas prácticas en un área, que
cuando se implementan colectivamente satisfacen un conjunto de metas consideradas importantes para tener una mejora relevante [2] . Para dar soporte a las
organizaciones que eligen la representación continua, las áreas de proceso son
clasicadas en 4 categorías, y cada área de proceso pertenece exclusivamente a
una categoría dependiendo de la funcionalidad que desempeña; dichas categorías se pueden observar en la columna 2 de la Figura 3. A su vez, cada categoría
tiene áreas de proceso fundamentales y progresivas (las fundamentales deben
ser implementadas antes que las progresivas para garantizar el cumplimiento de
los pre-requisitos); la excepción es la categoría de Ingeniería, en la que las áreas
de proceso son recursivas. Esto se puede observar en la columna 4 de la Figura
3 [2, 1].
Para aquellas organizaciones que escogen la representación escalonada se
establecen los niveles de madurez, que sirven como fronteras del proceso, por
ejemplo: las áreas de proceso del nivel 2 no pertenecen al nivel 3 y viceversa
(esto no indica que no exista relación entre ellas) ; esto quiere decir que en
la representación escalonada un área de proceso pertenece a un único nivel de
madurez; en la columna 3 de la Figura 3 estos se distinguen por diferentes
colores (verde para el nivel de madurez 2, amarillo para el 3, rosa para el 4,
y azul para el 5). Si una organización quisiera alcanzar el nivel de madurez 2
deberá implementar todas las áreas de proceso de color verde.
Fig. 3: Áreas de Proceso y sus Categorías - Niveles de Madurez CMMI [2, 5]
9
PATRÓN DE PROCESOS
A continuación se describen los componentes de las áreas de proceso [2] , a
su vez esta descripción representa el patrón de procesos de CMMI (la forma en
la que se documenta un área de proceso):
Requeridos
Describen lo que una organización debe alcanzar para satisfacer un área de
proceso, dicho logro debe ser visiblemente implementado en los procesos de la
organización. Los componentes requeridos de CMMI son:
Metas Especícas: Describen las características únicas que deben ser tenidas en cuenta para satisfacer un área de proceso.
Metas Genéricas: Describen las características que deben ser tenidas en
cuenta para institucionalizar los procesos que implementan un área de
proceso. Aparecen al nal del área de proceso y se llaman así porque la
misma declaración aparece en múltiples áreas de proceso.
El cumplimiento de metas es utilizado en las evaluaciones como base para decidir
si el área de proceso ha sido alcanzada o satisfecha.
Esperados
Describen lo que una organización típicamente implementaría para alcanzar
un componente requerido, aquí se incluyen:
Prácticas Especícas: Describen las actividades que son consideradas importantes en el logro de la meta especíca asociada a dicha práctica.
Prácticas Genéricas: Describen las actividades que son consideradas importantes en el logro de una meta genérica asociada a dicha práctica.
Aparecen al nal del área de proceso y son llamadas así porque la misma
práctica aparece en varias áreas de proceso.
Guían a aquellos que implementan las mejoras o realizan las evaluaciones.
Informativos
Proveen detalles que ayudan a la organización a empezar a pensar en cómo
alcanzar los componentes esperados y requeridos. Son:
Declaración de Propósito: Describe el propósito de un área de proceso.
Notas Introductorioas: Describe los conceptos más importantes en el área
de proceso.
Áreas de Proceo Relacionadas: Lista las referencias a las áreas de proceso
relacionadas y reeja las relaciones de alto nivel entre las áreas de proceso.
10
Sub-Prácticas: Es una descripción detallada que provee una guía para
interpretar e implementar una práctica especíca.
Productos de Trabajo: Listan las salidas o una muestra de las salidas de
una práctica especíca.
Amplicaciones de la Disciplina: Es una pieza de información que es relevante para una disciplina en particular.
Elaboraciones de Práctica Genérica: Aparece después de una práctica genérica en un área de proceso para proveer una guía de cómo dicha práctica
genérica debería ser aplicada en dicha área de proceso.
Títulos de Meta y Práctica: Son los títulos de los componentes requeridos
y esperados.
Notas de Meta y Práctica: Es texto que puede proveer más detalle acerca
de algo.
Apoyo a Componentes Informativos
Ejemplos: Aclara un concepto o una actividad.
Notas: Es texto que provee más detalle.
Ampliaciones de la Disciplina: Es una pieza de información que es relevante a una disciplina en particular.
Referencias: Es un apuntador a información adicional.
La Figura 4 muestra una relación de todos los componentes anteriormente descritos.
11
Fig. 4: Componentes Áreas de Proceso CMMI[2, 1]
Desgloce Áreas de Proceso
A continuación se muestra una breve descripción de cada área de proceso
del modelo, clasicadas en su categoría y además en su tipo: fundamental o
progresiva [2, 5, 1] :
Gestión de Procesos
Contiene las actividades del proyecto cruzadas relacionadas con la denición, planeacióm, despliegue, implementación, monitoreo, control, evaluación,
medición y evaluación de los procesos.
Áreas Fundamentales
Proveen a la organización la capacidad de documentarse y compartir las
mejores prácticas.
Denición de Procesos Organizacionales
Establece y mantiene el conjunto de proceso estándar de la organización,
basándose en las necesidades del proceso y los objetivos de la organización.
Enfoque de Procesos Organizacionales
Ayuda a la organización a planear e implementar la mejora de procesos
organizacionales basándose en un entendimiento de las fortalezas y debilidades
de los procesos actuales de ésta.
12
Entrenamiento Organizacional
Identica las necesidades de entrenamiento estratégico de la organización y
también las necesidades de entrenamiento táctico.
Áreas Progresivas
Desempeño del Proceso Organizacional
Brinda objetivos cuantitativos para el desempeño de la calidad del proceso
desde los objetivos de negocio de la organización.
La organización provee las métricas y debe analizarlas para desarrollar un
entendimiento de la calidad del producto, del servicio y desempeño de procesos.
Innovación y Desempeño Organizacional
Selecciona y despliega nuevas mejoras.
Gestión de Proyectos
Cubre las actividades relacionadas con planeación, monitoreo y control del
proyecto.
Áreas Fundamentales
Dirigen las actividades relacionadas con establecer y mantener el plan del
proyecto, compromisos, monitorear los progresos versus el plan, tomar acciones
correctivas y administrar los acuerdos con los proveedores.
Planeación del Proyecto
Incluye:
Desarrollar el plan del proyecto
Involucrar a los stakeholders
Adquirir compromiso con el plan
La planeación comienza con los requerimientos que denen el producto y el
proyecto.
Monitoreo y Control del Proyecto
Incluye el monitoreo de las actividades y el tomar acciones correctivas. El
plan especica el nivel de monitoreo que hay que tener y la frecuencia de las
retroalimentaciones.
13
Administración de Acuerdos con Proveedores
Maneja las necesidades que existen dentro del proyecto de obtener porciones
de trabajo que seran producidas por proveedores. Una vez el componente de
un producto es identicado y el proveedor que lo producirá es seleccionado, el
acuerdo es establecido y mantenido (monitoreado).
Áreas Progresivas
Dirigen actividades como establecer un proceso denido que es adaptado del
conjunto de procesos estándar de la organización, como coordinación y colaboración con stakeholders relevantes (incluyendo proveedores), administración de
riesgos, etc.
Cada área de proceso progresiva de la categoría de gestión de proyectos
depende de la habilidad de planear, monitorear y controlar el proyecto. Las
áreas de proceso fundamentales de ésta misma categoría proveen esta habilidad.
Administración de Riesgos
Desarrolla e implementa una estrategia proactiva para identicar, evaluar,
priorizar y manejar riesgos del proyecto.
Administración Cuantitativa del Proyecto
Aplica técnicas estadísticas cuantitativas para manejar el desempeño del
proceso y la calidad del producto.
Administración Integrada del Proyecto
Adapta los procesos organizacionales al proyecto y establece la visión compartida del mismo.
Ingeniería
Cubre las actividades de desarrollo y mantenimiento que son compartidas a
través de las disciplinas de ingeniería. Integra procesos de Ingeniería de Sistemas
y de Software.
Desarrollo de Requerimientos
Identica las necesidades del cliente y las traduce a requerimientos del producto, estos son analizados para producir una solución conceptual de alto nivel.
Administración de Requerimientos
Maneja y administra los requerimientos de los productos del proyecto y de
los componentes del producto. Identica inconsistencias entre los requerimientos
y el plan de proyecto y productos de trabajo.
14
Soluciones Técnicas
Su propósito es desarrollar, diseñar e implementar soluciones para los requerimientos del producto.
Integración del Producto
Combina los componentes del producto y se asegura que éste (cuando esté
integrado) funcione correctamente.
Vericación
Asegura que los productos de trabajo seleccionados cumplan con sus requerimientos, asegura también que las cosas se hayan hecho bien.
Validación
Asegura que el producto cumple con lo que se esperaba de éste, asegura que
se esté haciendo lo correcto de acuerdo a los requerimientos.
Soporte
Cubre las actividades que soportan/apoyan el desarrollo del producto y su
mantenimiento.
Áreas Fundamentales
Mediciones y Análisis
Establece un programa de métricas para proveer resultados objetivos que
puedan ser utilizados para la toma de decisiones y para el establecimiento de
acciones correctivas.
Aseguramiento de la Calidad y del Producto
Proporciona prácticas para evaluar objetivamente los procesos, productos y
servicios.
Administración de la Conguración
Apoya a todas las áreade proceso estableciendo y manteniendo la integridad
de todos los productos de trabajo utiliznado la identicación de conguración,
control de conguración, y auditorías de conguración.
Áreas Progresivas
Análisis Causal y Resolución
Identica las causas de los defectos y de otros problemas, y toma acciones
para prevenir que ocurran en el futuro.
15
Análisis de Decisiones y Resolución
Apoya a todas las áreas de procso determinando cuales sucesos deben ser
sometidos a una evaluación de proceso y luego aplicando dicha evaluación a
éstos.
CMMI en las Organizaciones
CMMI es considerado el modelo de mejora de procesos más comprensible y
más conocido [6]. Sin embargo, las organizaciones pueden ver este modelo de 2
formas:
1. Vista de la Valoración
2. Vista de Mejora de Procesos
Si una organización ve este modelo con ojos de "valoración" se enfocará en
satisfacer los requerimientos mínimos que se deben cumplir para pasar la prueba
o evaluación SCAMPI. Por el contrario, si se tiene una vista de una mejora real,
la organización se enfocará en lo que es mejor para sí misma y lo que necesitan
para mejorar. La experiencia establece que las organizaciones que tienen la vista
1 fallarán en el intento, especialmente en "satisfacer" el modelo por la falta de
institucionalización del mismo. Tal vez la vista 2 requiera trabajar duro, pero
es el único camino a la mejora.
CMMI tiene 2 problemas para las organizaciones: Su interpretación y las
decisiones organizacionales. Este modelo fue escrito para cubrir muchas organizaciones y muchos proyectos distintos, por eso puede llegar a ser ambiguo. Sin
embargo, esto también puede ser visto como una ventaja, ya que permite denir
a cada organización cómo hacer las cosas y lo que quiere obtener de sus acciones
[1] .
16
MoProSoft
El Modelo de Procesos para la Industria del Software: MoProSoft fue desarrollado a solicitud de la Secretaría de Economía, que inició el Programa para
el Desarrollo de la Industria de Software: PROSOFT , para servir como base de
la Norma Mexicana de la Industria de Desarrollo y Mantenimiento de Software
bajo el convenio con la Facultad de Ciencias de la Universidad Autónoma de
México ; y con el objetivo de fortalecer la industria del software en México [7, 8]
.
Dentro de las estrategias de PROSOFT existe una sexta (6) que estipula
"alcanzar niveles internacionales en capacidad de procesos" , para esto fue necesaria una denición de un modelo de procesos y evaluación apropiado para la
industria del software mexicana que debería cumplir con los siguientes requerimientos:
Especíco para desarrollo y mantenimiento de software
Fácil de entender
Denido como conjunto de procesos
Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas
Orientado a mejorar los procesos para contribuir a los objetivos de negocio
y no simplemente ser un marco de referencia de certicación
Debe de tener un mecanismo de evlauación o certicación, que indique un
estado real de una organización durante un período de vigencia especíco.
Aplicable como norma mexicana
Ser la base para alcanzar evaluaciones exitosas con otros modelos, tales
como ISO 9000 : 2000 ó CMMI v1.1
La razón del establecimiento de los requerimientos anteriores es que la industria
del software en México es en su mayoría pequeña y mediana, el 90 % de las empresas desarrolladoras de software se encuentran en dichas categorías y además
son volátiles, cuentan con pocos recursos y tienen procesos no estandarizados
que dependen del personal que los ejecuta [9] . Luego de hacer un estudio de
los modelos existentes y una comparación de sus características versus aquellas deseadas para el modelo, el resultado fue que ningún modelo satisfacía los
requerimientos; se opta entonces por crear uno, tomando como base algunas
características de éstos.
MoProSoft está fundamentado en ISO 9000:2000, SW-CMM y el reporte
técnico ISO/IECTR 15504 , por lo que la adopción de este modelo habilida la
obtención de un certicado ISO 9000 y reduce la brecha para la obtención de
una valoración en CMMI Nivel 2 [9] . Después de 5 años de implantación como
norma, este modelo ha permitido a las organizaciones seguir un camino más
claro y denido en su búsqueda de la mejora continua de procesos de software,
17
pues cubre en gran medida los requisitos de CMMI y de ISO/IEC 12207 así
como el 80 % de los requisitos denidos por el grupo WG24 [8].
Estructura
Este modelo consta de una sóla representación y utiliza niveles de capacidad
de procesos [10], de forma similar a la representación continua de CMMI.
Modelo de Capacidades de Procesos
La capacidad de un proceso se evalúa en niveles en una escala de 0 a 5, así
[11]:
0 - Incompleto
El proceso no esta implantado o falla en alcanzar el propósito del proceso.
1 - Realizado
El proceso implantado logra su propósito
2 - Administrado
El proceso Realizado se implanta de manera administrada y sus productos
de trabajo están apropiadamente establecidos, controlados y mantenidos.
3 - Establecido
El proceso Administrado es implantado mediante el proceso denido, el
cual es capaz de lograr los resultados del proceso.
4 - Predecible
El proceso Establecido opera dentro de límites para lograr sus resultados.
5 - Optimizado
El proceso Predecible es continuamente mejorado para lograr las metas de
negocio actuales y futuras relevantes.
Cómo Alcanzar un Nivel de Capacidad
La medición de capacidad se obtiene a través de un conjunto de Atributos
de Procesos, que se usan para determinar cuándo un proceso ha alcanzado una
capacidad; cada atributo mide un aspecto particular de un proceso [11].
18
Patrón de Procesos
Es un esquema de elementos que describe la forma en que se documentan
los procesos y está constituido por 3 partes : Denición general del proceso,
prácticas y guías de ajuste [10].
Denición General del Proceso
Proceso: Nombre del proceso, precedido por el acrónimo establecido en la
denición de los elementos de la estructura del modelo de procesos.
Categoría: Nombre de la categoría a la que pertenece el proceso y el acrónimo entre paréntesis.
Propósito: Objetivos generales medibles y resultados esperados del proceso.
Descripción: Descripción general de las activiades y productos que componen el ujo de trabajo del proceso.
Objetivos: Objetivos especícos cuya nalidad es asegurar el cumplimiento
del propósito del proceso.
Indicadores: Denición de los indicadores para evaluar la efectividad del
cumplimiento de los objetivos del proceso.
Metas Cuantitativas: Valor numérico o rango de satisfacción por indicador.
Responsabilidad y Autoridad: Responsabilidad es el rol principal responsable por la ejecución del proceso. Autoridad es el rol responsable por
validar la ejecución del proceso y el cumplimiento de su propósito.
Sub-procesos: Lista de procesos de los cuales se compone el proceso en
cuestión. Este es opcional.
Procesos Relacionados: Nombres de los procesos relacionados.
Entradas: Para cada entrada nombre del producto o recurso, y fuente.
Salidas: Para cada salida nombre del producto generado y utilizado en el
propio proceso, descripción y destino.
Productos Internos: Para cada producto generado y utilizado en el propio
proceso, nombre y descripción.
Referencias Bibligrácas: Bibliografía que sustenta el proceso.
Prácticas
Roles Involucrados y Capacitación
Identicación de roles involucrados y capacitación requerida.
19
Actividades
Se asocian los objetivos y describen las tareas y roles responsables.
Diagrama de Flujo de Trabajo
Diagrama de actividades UML, donde se especican las actividades del
ujo de trabajo y los productos.
Vericaciones y Validaciones
Se denen las vericaciones y validaciones asociadas a los productos generados en las actividades que se mencionan.
En la vericación como en la validación se identican los defectos que
deben corregirse antes de continuar con las actividades posteriores.
La validación de un producto puede ser interna (dentro de la organización)
o externa (por el cliente) con la nalidad de obtener su autorización.
Incorporación a la Base del Conocimiento
Se establecen los productos y el momento a partir del cual estarán bajo
control en la base del conocimiento de la organización.
Recursos de Infraestructura
Se especica para cada actividad los requerimientos de herramientas de
software y hardware.
Mediciones
Mediciones que se establecen para evaluar los indicadores del proceso.
Capacitación
Denición de las reglas para proporcional la capacitación necesaria a los
roles involucrados en el proceso.
Situaciones Excepcionales
Denición de los mecanismos para el manejo de las situaciones excepcionales durante la ejecución del proceso.
Lecciones Aprendidas
Denición de los mecanismos para aprovechar las lecciones aprendidas
durante la ejecución el proceso.
20
Guías de Ajuste
Descripción de posibles modicaciones al proceso que no deben afectar los
objetivos del mismo.
Modelo de Referencia de Procesos
Para denir la estructura de este modelo se realizó un análisis de la estructura
de las empresas mexicanas desarrolladoras de software, en el que se concluyó que
"en la mayoría de empresas, incluso en las micro con menos de 10 personas, la
alta dirección toma las decisiones acerca del rumbo de los negocios, la dirección
media es responsable del control de recursos y proyectos, y el sector operacional
desarrolla los proyectos" [12].
Teniendo en cuenta estos resultados, MoProSoft tiene 3 categorías: Alta Dirección (Top Management), Gerencia (Middle Management), y Operación (Opperations), que abarcan 9 procesos en total, como lo ilustra la Figura 5 .
Fig. 5: Diagrama de Categorías de Procesos MoProSoft[10]
ALTA DIRECCIÓN
Esta es una característica que le da un distintivo a éste modelo;su objetivo
principal es organizar las actividades de los ejecutivos de las PyMES introduciendo prácticas de administración y de ingeniería de software modernas [13].
21
También dirige y recibe reportes de la categoría de Gerencia [12] y se ha demostrado que el compromiso de las personas que caben dentro de esta categoría
juega un papel crucial en la implementación de un modelo de mejora de procesos
de software [13].
Gestión del Negocio
Su propósito es establecer la razón de ser de la organización, sus objetivos
y las condiciones para lograrlos.
Habilita a la organización para responder a un ambiente de cambio, y a
sus miembros para trabajar en función de los objetivos establecidos [9].
GERENCIA
Está alineada con las metas de negocio de la categoría de alta dirección; también con la categoría de operación ya que provee elementos para el desempeño
de procesos operacionales, recibe y evalúa la información que dichos procesos
generan, e informan a alta dirección acerca de los resultados [12].
Gestión de Procesos
Su propósito es establecer los procesos de la organización en función de
los procesos requeridos identicados en el plan estratégico. Busca denir,
planear e implantar las actividades de mejora en los éstos [10].
Gestión de Proyectos
Su propósito es asegurar que los proyectos contribuyan al cumplimiento
de los objetivos y estrategias de la organización [10].
Gestión de Recursos
Su nalidad es apoyar el cumplimiento de los objetivos del plan estratégico
de la organización. Así como conseguir y dotar la organización de los
recursos humanos, infraestructura, ambiente de trabajo y proveedores [7].
Incluye 3 sub-procesos:
•
Recursos Humanos y Ambiente de Trabajo: Busca proporcionar los
recursos humanos adecuados para cumplir las responsabilidades asignadas dentro de la organización, así como la evaluación del ambiente
de trabajo.
•
Bienes, Servicios e Infraestructura: Su propósito es proporcionar proveedores de bienes, servicios e infraestructura que satisfagan los requisitos de adquisición de los procesos y proyectos de la organización.
22
•
Conocimiento de la Organización: Su n es mantener disponible y
administrar la base del conocimiento que contiene la información y
los productos generados por la organización.
OPERACIÓN
Dirige las prácticas de los proyectos de desarrollo y mantenimiento de software, se alinea con la categoría de gerencia entregando reportes y productos de
software generados [12].
Administración de Proyectos Especícos
Su propósito es establecer y llevar a cabo sistémicamente las actividades
que permitan cumplir con los objetivos de un proyecto en tiempo y costo
esperados.
Desarrollo y Mantenimiento de Software
Su propósito es la realización sistémica de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos
o modicados cumpliendo con los requerimientos especícos.
La Figura 6muestra la relación entre los 9 procesos de este modelo:
Fig. 6: Diagrama de Relación entre Procesos MoProSoft[10]
Modelo de Evaluación
Una vez se realizó el modelo se hizo la misma vericación del cumplimiento
de las características deseadas, dando como resultado que todavía hacía falta la
23
"Evaluación con vigencia" que fuera "Aplicable como norma" [9]. Por esto fue
denido EvalProSoft en el 2003, basado en ISO/IEC 15504-2.
En el 2005 se estableció la norma mexicana NMX-059-NYCE bajo el nombre:
Tecnología de la Información-Software-Modelos de procesos y de evaluación para
desarrollo y mantenimiento de software, que consta de 4 partes [8]:
1. Denición de Conceptos y Productos
2. Requisitos de Procesos: MoProSoft
3. Guía de Implantación de Procesos
4. Directrices para la Evaluación: EvalProSoft
Esta parte 4 del estándar provee un método para evaluar una organización y
establecer un perl de su nivel de capacidad para los 9 procesos implementados
y un nivel de capacidad de la madurez [13]. Los niveles de capacidad alcanzables
y sus atributos de proceso están divididos en una escala de 6 niveles como lo
muestra la Figura 7.
Fig. 7: Niveles de Capacidad y Atributos de Proceso MoProSoft [14]
A continuación en la Tabla 2 se muestra la escala con la cual es calicado el
grado de cumplimiento de un atributo de proceso:
Tab. 2: Calicación Atributos de Proceso MoProSoft [11]
Letra
Calicación
Porcentaje % de Alcance
N
No Alcanzado
0 - 15 % del alcance
> 15 % hasta el 50 % del alcance
P
Parcialmente Alcanzado
A
Ampliamente Alcanzado
> 50 % hasta 85 % del alcance
C
Completamente Alcanzado
> 85 % hasta el 100 % del alcance
24
Por último, el nivel de capacidad que se alcanza es derivado de la calicación
de la Tabla 2, para lo que se toma como referencia la Figura 8 .
Fig. 8: Calicación del Nivel de Capacidad del Proceso MoProSoft[11]
Esto quiere decir que para alcanzar un nivel de capacidad n en un proceso se
necesita cumplir con los atributos del nivel n con una calicación de "Ampliamente Avanzado - A" y además cumplir con los atributos de proceso del nivel
n-1 con una calicación de "Completamente Alcanzado - C" [11] .
El proceso de Gestión de Procesos, en la categoría de Gestión dene, implanta, controla y mejora los procesos de la organización, por lo que el nivel
de capacidad de los demás procesos de la organización dependen del nivel de
capacidad de éste proceso. Es por esto que el nivel de madurez de capacidades
de la organización se dene como el nivel de capacidad del proceso de Gestión
de Procesos [11].
Aportes a ProSoftCol
Es claro que este modelo presenta múltiples ventajas si de su posible adaptación a PyMES se trata:
Categorías de Procesos
Estas categorías corresponden a los niveles organizacionales de administración, que es común en muchas organizaciones. Sin embargo, esto es válido para
el contexto mexicano, no se puede asegurar que para el colombiano. El aporte
que brinda es el de "pensar" en el término de categoría de proceso y de alinearlo
a la estructura de las organizaciones colombianas de desarrollo de software.
25
Procesos Integrados y Relacionados
Esto no es nuevo en un modelo, ya que en CMMI todos los procesos tienen
relaciones establecidas. El aporte consiste en la reducción del número de procesos
de 22 a 9.
Conocimiento de la Organización
Este proceso administra una base de conocimiento, que controla y asegura la
disponibilidad de los productos de trabajo a través de un mecanismo común. El
aporte es el de "pensar" en algo similar para ProSoftCol, un repositorio común
para la organización.
Distinción en Administraciones
Se distingue entre la administración a nivel de proyecto : Administración de
Proyecto Especíco en la categoría de Operación; y la gestión del portafolio de
proyectos de la organización: Gestión de Proyectos en la categoría de Gestión. El
aporte que hace es el de separar estas administraciones para tener más claridad
sobre las actividades y tareas de cada una, pues en una MIPyME_DS a veces
la persona encargada de éstos 2 tipos de administración es la misma.
26
CompetiSoft
En 2005 investigadores y practicantes reconocieron la importancia de un
marco de mejora y certicación para las MIPyMES, y se propuso CompetiSoft :
Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana
Industria del Software de Iberoamérica, como un modelo. Este se construyó sobre
las prácticas de las iniciativas latinoamericanas como MoProSoft y Brazilian
Process Improvement Model; Métrica v3 de España fue tenido en cuenta también
[15]. En la Figura 9 se ilustra la visión general de este modelo:
Fig. 9: Visión General de CompetiSoft[12]
Los requerimientos que debía cumplir CompetiSoft fueron:
Fácil de entender
Fácil de aplicar
No costoso en su adopción
Se la base para alcanzar evaluaciones exitosas con otros modelos o norma,
tales como ISO 9000 : 2000 o CMM v1.1
Su objetivo general es incrementar el nivel de competitividad de las PyMES
Iberoamericanas productoras d esoftware mediante la creación y difusión de un
marco metodológico común que, ajustado a sus necesidades especícas, pueda
llegar a ser la base sobre la que establecer un mecanismo de evaluación y certicación de la industria del software reconocido en toda Iberoamérica. Como
objetivo especíco relevante existe uno que nunca se había planteado en un
proyecto de éste tipo: "Denir la cultura de procesos mediante la formación de
27
investigadores, docentes y profesionales" [16]. Valela pena resaltar que CompetiSoft no es sólo un modelo de referencia, este proyecto se divide en 3 partes
[17]:
Modelo de Referencia de Procesos
Modelo de Evaluación
Modelo de Mejora
Estructura
Este modelo, al igual que MoProSoft, sólo tiene una representación que mide
la capacidad de los procesos[16] .
Modelo de Capacidad de Procesos
La capacidad de un proceso se evalúa de 0 a 5, en donde cada número se
asocia a un nivel (al igual que en MoProSoft) , así [16] :
0 - Incompleto
El proceso no está implantado o falla en alcanzar el propósito del proceso.
1 - Realizado
El proceso implantado logra su propósito.
2 - Administrado
El proceso Realizado se implanta de manera administrada y sus productos
de trabajo estan apropiadamente establecidos, controlados y mantenidos.
3 - Establecido
El proceso Administrado es implantado mediante el proceso denido, el
cual es capaz de lograr los resultados del proceso.
4 - Predecible
El proceso Establecido opera dentro de límites para lograr sus resultados.
5 - Optimizado
El proceso Predecible es continuamente mejorado para lograr las metas de
negocio actuales y futuras relevantes.
28
Cómo Alcanzar un Nivel de Capacidad
La medición de capacidad se obtiene a través de un conjunto de Atributos de Proceso (AP), los cuales se utilizan para determinar cuándo un proceso
ha alcanzado una capacidad. Cada atributo mide un aspecto particular de un
proceso [16].
Patrón de Procesos
El patrón de procesos es un esquema de elementos que sirve para la documentación de los procesos. Este es casi igual al de MoProSoft ( para ver la
denición de cada elemento dirigirse a Patrón de Procesos de MoProSoft en la
página 18), con la diferencia que se excluyen algunos elementos. Está constituido
por 3 partes: Denición general del proceso, Prácticas, y Guías de ajuste [16].
Denición General del Proceso
Proceso
Categoría
Propósito
Descripción
Objetivos
Indicadores
Metas Cuantitativas
Responsabilidad y Autoridad
Sub-Procesos
Procesos Relacionados
Entradas
Salidas
Productos Internos
En este modelo se excluye el elemento "Referencias Bibliográcas" (presente en
MoProSoft).
29
Prácticas
Roles Involucrados y Competencias
Actividades
Diagrama de Flujo de Trabajo
Vericaciones y Validaciones
Recursos de Infraestructura
Mediciones
Diere del patrón de procesos de MoProSoft en que cambia el nombre de "Roles
Involucrados y Capacitación" a "Roles Involucrados y Competencias"; no incluye "Incorporación a la Base del Conocimiento", "Capacitación", "Situaciones
Excepcionales" y "Lecciones Aprendidas".
Guías de Ajuste
Descripción de posibles modicaciones al proceso que no deben afectar los
objetivos del mismo.
Modelo de Referencia de Procesos
Este modelo se puede ver como una evolución del modelo de referencias de
procesos de MoProSoft [12], pues su estructura es casi igual. La única diferencia
es la existencia de 1 proceso más dentro de la categoría de Operación: Mantenimiento de Software, para un total de 10 procesos. Las categorías de proceso
siguen siendo las mismas: Alta dirección, gerencia y operación; esto porque se
asume que esa estructura general de las empresas mexicanas desarrolladoras de
software aplica a las organizaciones iberoamericanas.
Si se toman en cuenta las Figuras y 10 se notará que tal vez ni siquiera sea
"un proceso más" lo que se hizo con CompetiSoft, sino más bien la separación del
proceso "Desarrollo y Mantenimiento de Software" en "Desarrollo de Software"
y "Mantenimiento de Software", respectivamente.
30
Fig. 10: Diagrama de Categorías de Procesos CompetiSoft[16]
ALTA DIRECCIÓN
Establece la razón de ser de la organización, lo que desea ser y las estrategias
para serlo, con la ayuda de un plan estratégico[12].
Gestión de Negocio
Su propósito es alinear los objetivos de negocio con su tecnología de información [16].
GERENCIA
Se encarga de crear planes de acción para instrumentar las estrategias en
cuanto a proyectos, procesos y recursos necesarios para alcanzar los objetivos
estratégicos. Monitorea y retroalimenta a la categoría de operación y a su vez,
retroalimenta a la de alta dirección[16].
31
Gestión de Procesos
El aporte más signicativo, y una diferencia con la gestión de procesos de
MoProSoft, es un cuestionario de auto-asesoría que ayuda a las organizaciones
en su primer contacto con las asesorías y mejoras de su madurez de procesos[12].
Gestión de Proyectos
Se seleccionan métricas e indicadores básicos que se pueden alinear a los objetivos de los procesos, en especial a la administración de proyectos especícos[12,
16].
Gestión de Recursos
Este, al igual que MoProSoft tiene 3 sub-procesos:
Gestión de Recursos Humanos
Gestión de Bienes e Infraestructura
Gestión de Conocimiento
Trata de crear una guía para las organizaciones a partir de la experiencia de
otras[12].
OPERACIÓN
Se encarga de llevar a cabo de los proyectos de desarrollo y mantenimiento
de software establecidos en la categoría de gerencia[12].
Administración de un Proyecto Especíco
Se enfoca en cumplir con los compromisos establecidos con el cliente en
tiempo y costo[12].
Desarrollo de Software
Se basa en lineamientos para desarrollo de requerimientos, análisis y diseño,
pruebas y construcción, para facilitar su aplicación en pequeñas organizaciones.
Las características más sobresalientes de este proceso son[12]:
Técnicas Especícas y Productos de Trabajo
Se sugieren herramientas de trabajo
Recomendación de bibliografía
Provee ejemplos de aplicación
32
Mantenimiento de Software
Tiene como objetivo llevar a cabo de forma ágil los cambios solicitados a un
producto se software de tal forma que no se pierda la consistencia, y que cumpla
con las necesidades del cliente [16]. Por eso se dice que es clave separar mantenimiento de desarrollo, ambos tienen naturalezas y características diferentes ( tal
vez este sea uno de los aportes más signicativos de CompetiSoft). Al separar
el mantenimiento se hizo notorio que muchas técnicas, herramientas y modelos
de proceso, no son aplicables a éste [12].
Se desarrolló un proceso de mantenimiento adoptando técnicas de Scrum y
Mantema, en las que se divide este proceso en 2 niveles:
Básico
•
Mantenimiento Urgente
•
Mantenimiento No Urgente
•
Mantenimiento Perfectivo
Avanzado
•
Mantenimiento Adaptativo
•
Mantenimiento Preventivo
Un ejemplo de estos niveles es: Una petición de modicación puede ser una solicitud de cambio (perfectivo, adaptativo y preventivo) o un informe de problema
correctivo urgente, o no urgente.
Este proceso tiene varias ventajas:
Permite los cambios durante el camino, y considera una retroalimentación
constante con el cliente junto con una entrega rápida y periódica de atención a las peticiones de mantenimiento que permita cumplir con los niveles
de servicio solicitados.
Considera el mecanismo para recibir, alcanzar y dar seguimiento a las peticiones de modicación. Las peticiones se atienden por grupos en ciclos, los
cuales se clasican en planicable y no planicable. Cada ciclo es conocido
como SprintM, que está basada en Sprint de Scrum [16].
La Figura 11 muestra la relación existente entre los 10 procesos de este modelo.
33
Fig. 11: Diagrama de Relación entre Procesos de CompetiSoft [16]
Modelo de Evaluación
Este modelo de evaluación está basado en EvalProSoft, el modelo de evaluación de MoProSoft. Para diseñar este modelo se tuvo en cuenta un problema
que es general a las organizaciones: las métricas. El medir algo correctamente y utilizar dichas medidas para el bien de la organización puede llegar a ser
subjetivo o ambiguo, especialmente si la organización es pequeña. Sin embargo,
desde que se diseñó CMMI se trató de "hacerlo simple" [1]. Por esto, la meta
era denir un conjunto de medidas para estimar la capacidad y desempeño de
los procesos de software que redujera la subjetividad del proceso y a la vez lo
hiciera más formal.
En este modelo existen 2 tipos de medida:
Capacidad
Usa los indicadores de un atributo de proceso para evaluar la capacidad de
los procesos de la organización de 0 a 5.
Desempeño
Basado en propósito, descripción, productos de trabajo, y actividades del
modelo de referencia CompetiSoft. Propone utilizar como marco general para la
evaluación a la norma internacional ISO/IEC 15504 : Performing an Assessment.
34
Este modelo exactamente igual al de MoProSoft, para más detalle sobre la
evaluación en CompetiSoft diríjase a Modelo de Evaluación de MoProSoft en la
página 22 .
Modelo de Mejora
PmCompetiSoft está basado en Agile SPI, y dene los elementos necesarios
para conducir la mejora de procesos en una pequeña organización de software
de una forma ágil, económica, con pocos recursos y en poco tiempo [12].
Está basado en un enfoque iterativo e incremental ( altamente inuenciado
por eXtreme Programming ), de tal forma que se pueda tener una entrega temprana y continua de mejoras que den visibilidad de los resultados a la categoría
de Alta Dirección. El proceso de mejora continua considera ciclos de mejora en
donde cada uno incluye las actividades de instalación, diagnóstico, formulación
de mejoras, ejecución de mejoras y revisión de ciclo [12].
Aportes a ProSoftCol
El aporte más grande para ProSoftCol es el cuestionario de auto-asesoría
en la Administración de Proyectos Especícos, pues es muy completo y
además considera las posibles respuestas (SI/NO) y dependiendo de esto
se genera un ujo de preguntas.
Las métricas utilizadas en Gestión de Proyectos y las técnicas de estimación también son un aporte, porque son para PyMES y en este proyecto
se ha hecho énfasis en la importancia de las mediciones.
35
Conclusiones
El objetivo al realizar una recolección de información acerca de éstos 3 modelos era entenderlos por completo, para luego en el momento de tener los requerimientos especícos de una MIPyME_DS poderlos aplicar al diseño de la guía,
es decir, el artefacto en términos de la ciencia del diseño. Decidí adentrar más en
CMMI porque aunque yo creía conocerlo en su totalidad, me percaté que no era
así y que por el contrario me tomó bastante tiempo entenderlo completamente.
Tener claridad y lograr un entendimiento de MoProSoft me ayudó a reducir un poco más el marco de ProSoftCol, a saber qué quiero y que no quiero
especícamente. Luego de documentarme sobre CMMI y de darme cuenta que
se han escrito libros para "ayudar a entender el modelo" me dije: Yo no quiero
esto, quiero algo que una persona pueda entender una vez lo haya leído. De
modo que ProSoftCol comparte algunos de los requerimientos o lo que eran las
características esperadas de MoProSoft, como:
Especíco para desarrollo y mantenimiento de software
Fácil de entender
Denido como conjunto de procesos
Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas.
Orientado a mejorar los procesos para contribuir a los objetivos de negocio.
MoProSoft está dirigido a pequeñas o medianas empresas o áreas internas de
organizaciones muy grandes de desarrollo y/o mantenimiento de software [13, 7]
; ProSoftCol es dirigido a micro, pequeñas y medianas empresas de desarrollo
de software que no cuenten con procesos establecidos.
Lo que más rescato de esta iteración del ciclo de Rigor es que yo me podría
identicar con una organización X que un día decide mejorar sus procesos y
documentarse al respecto. Probablemente acudiría a CMMI (como yo lo hice en
principio) pero surgirían muchos interrogantes, dudas y sería necesaria una gran
inversión de tiempo para entender el modelo y más aún para tener una idea de
cómo aplicarlo a la organización.
Mientras yo realizaba mi investigación, tenía en mente esto: ¾Cómo aplicar
todo esto a una MIPyME_DS Colombiana? De modo que las preguntas que me
surgieron en el camino serían las mismas que una organización X se haría, y la
respuesta o guía para resolverlas será el aporte de mi artefacto, de ProSoftCol.
Me atrevo a decir que una forma de medir la claridad y facilidad de entendimiento de cada modelo es la que yo experimenté: buscando fuentes de
información de dichos modelos (se hizo en la asignatura Seminario Metodología
de la Información), y luego haciendo un ltro de la información contenida en
dichas fuentes para tomar lo que se consideró relevante y no repetitivo. Luego
se organizó toda la información y plasmarla en este documento de manera que
fuera clara y que se entendiera a profundidad cada modelo y cómo está conformado. El grado de complejidad de esta tarea fue elevado, pues al iniciar con
36
CMMI no sabía de qué forma explicar la estructura del modelo: ¾explicar qué
es un área de proceso primero y luego las 2 representaciones? o ¾al revés? Finalmente debo decir que todavía no estoy convencida de que cualquier persona
que lea este documento entienda completamente el modelo CMMI.
El grado de complejidad fue bajando y mucho, tan sólo en el modelo MoProSoft, ya que éste es mucho más claro en su estructura y sólo tiene una
representación, no 2 como CMMI. Lo que más me ayudó fue la asimilación con
la estructura de una empresa para denir las categorías de procesos y dentro de
ellas cada proceso.
Comprender CompetiSoft no fue para nada difícil, teniendo en cuenta que
es casi igual a MoProSoft en su estructura, solo que enfatiza más en algunos
aspectos como el mantenimiento de software y métricas. Tomar dichas categorías ( Alta Dirección - Gerencia - Operación ) puede llegar a ser muy útil para
el entendimiento de un modelo. Sin embargo, a pesar de que se han realizado
algunas implementaciones de CompetiSoft en PyMES Iberoamericanas [15], es
claro que el objetivo de este proyecto no se ha cumplido; las razones son desconocidas para mí, pero en mi opinión hace falta algo más, algo como una guía
más cercana a cada tipo de organización.
37
Referencias
[1] M. Kulpa and K. Johnson,
Approach, C. Press, Ed.
Interpreting the CMMI: A Process Improvement
Auerbach Publications, 2003.
CMMI:Guidelines for Process
Integration and Product Improvement, Pearson, Ed. Addison Wesley, 2003.
[2] M. B. Chrissis, M. Konrad, and S. Shrum,
[3] M. West,
Real Process Improvement Using the CMMI, C. Press, Ed.
Auer,
2004.
Process Improvement Essentials, M. O'Brien and T. Apandi, Eds.
[4] J. Persse,
O'Reilly, September 2006.
[5] M. Chrissis, M. Konrad, and S. Shrum. (2009) Cmmi: Guía para la
integración de procesos y la mejora de productos. [Online]. Available:
http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf
[6] P. Mongkolnam, U. Silparcha, N. Waraporn, and V. Vanijja, A push for
software process improvement in thailand, in Proc. Asia-Pacic Software
Engineering Conf. APSEC '09, 2009, pp. 475481.
[7] H. Oktaba, C. Alquicira, A. Su Ramos, A. Martinez, A. Quintanilla,
M. Ruvalbaca, F. Lopez, M. Rivera, M. Orozco, Y. Fernandez, and
M. Flores, Modelo de procesos para la industria de software moprosoft,
no. 1.3.
Universidad Nacional Autonoma de Mexico, Agosto 2005. [Onli-
ne]. Available: http://www.comunidadmoprosoft.org.mx/COMUNIDAD_
MOPROSOFTADM/Documentos/V1.3_MoProSoft.pdf
[8] H. Oktaba. (2008, Mayo) Moprosoft sin fronteras. Universidad Nacional
Autónoma de México.
[9] H. e. a. Oktaba. (2005) Moprosoft: Modelo de procesos para la industria
de software.
[10] H. Oktaba, C. Alquicira, A. Su Ramos, A. Martinez, A. Quintanilla,
M.
Ruvalbaca,
F.
López,
M.
Rivera,
México
Std.
M.
Orozco,
Y.
Fernandez,
Modelo de Procesos para la Industria del Software
MoProSoft por Niveles de Capacidad de Procesos, Universidad
and
M.
Flores,
Nacional
Autónoma
Available:
de
1.3,
Agosto
2005.
[Online].
http://www.comunidadmoprosoft.org.mx/COMUNIDAD_
MOPROSOFTADM/Documentos/V_1.3_MoProSoft_por_niveles_de_
capacidad_de_procesos.pdf
[11] H.
Oktaba,
C.
Alquicira,
A.
Su
Ramos,
F.
López,
J.
Pa-
Método de Evaluación de procesos
para la Industria del Software EvalProSoft, Universidad Naciolacios,
nal
and
Autónoma
C.
Pérez,
de
México
Std.
1.1,
2004.
[Online].
Available:
http://materias.utags.edu.mx/claroline/backends/download.php?url=
38
L0FydGljdWxvcy9FdmFsUHJvU29mdHYxMS5wZGY%3D&cidReset=
true&cidReq=CALS_IVET
[12] H. Oktaba, F. Garcia, M. Piattini, F. Ruiz, F. J. Pino, and C. Alquicira, Software process improvement: The competisoft project,
Computer,
vol. 40, no. 10, pp. 2128, 2007.
[13] B. L. F. Rios, M. A. A. Vargas, J. M. O. Espinoza, and M. d. C. Peralta, Experiences on the implementation of moprosoft and assessment of
processes under the nmx-i-059/02-nyce-2005 standard in a small software
development enterprise, in
ENC '08, 2008, pp. 323328.
Proc. Mexican Int. Conf. Computer Science
[14] Itera. (2006) Moprosoft. Web Page. Itera IT Business Process. [Online].
Available:
http://www.iteraprocess.com/index.php?option=com_
content&task=view&id=23&Itemid=44
[15] A. Aguirre, C. Pardo, W. Pantoja, M. Maria, and F. Pino, Reporte de
experiencias de la aplicación de competisoft en cinco mipymes colombianas,
Revista Escuela de Ingeniería de Antioquia, vol. 13, pp. 107122, Julio
2010.
Competisoft: Mejora de Procesos Software para Pequeñas y Medianas Empresas y
Proyectos, Ra-Ma, Ed. AlfaOmega, 2009.
[16] M. Piattini, H. Oktaba, F. Pino, M. Orozco, and C. Alquicira,
[17] H. Oktaba. (2009, Noviembre) Una aportacion latina a estandares internacionales para la industria de software.