Capítulo 2

Programa para
el desarrollo de
la industria del
software

51
2.1 Definición de modelos de procesos y de
evaluación apropiados para la industria del
software mexicano

Cuando hablamos de la calidad de los procesos de desarrollo de software

se busca elevar su rendimiento para corregir problemas y extender la
competitividad del país aplicando alguna estrategia: una de ellas es
elevar los procesos definidos en las empresas dedicadas al desarrollo del
software, buscando así disminuir los costos de desarrollo, aumentar la
productividad y elevar la calidad en los productos generados, así
podemos lograr que México pueda contar con una industria competitiva a
nivel internacional, adoptando ciertos modelos y estándares de
capacidad de procesos, obteniendo una mayor productividad y al mismo
tiempo una mejor calidad de éstos.
Al controlar estos procesos que intervienen en el desarrollo de un producto
de software se busca el estado deseado de los objetivos que se pretenden
alcanzar para cubrir las necesidades del operador haciéndolo eficiente y
convirtiendo el producto de un software de buena calidad.

Para lograr resultados exitosos al desarrollar software, se requiere la ayuda

de una disciplina en cuanto a los procesos; para obtenerlo se necesita de:

1. Contar con los procesos adecuados para la industria del software,

recopilando las mejores prácticas ya reconocidas a nivel mundial.

2. Tener mecanismos de evaluación correspondientes a los modelos.

Para desarrollar software se están usando modelos de procesos como:

SW CMM, PSP, TSP, ISO/ IEC TR 15504 y MOPROSOFT, este último diseñado y
orientado únicamente para áreas que se dediquen al desarrollo y
mantenimiento del software en una empresa.

Los modelos SW-CMM, ISO/ IEC TR 15504 cuentan con un modelo de

evaluación en cuanto a la capacidad de los procesos.

Encontramos que la ISO 9001:2000 es una norma internacional para la

administración de la calidad en cualquier organización, puede ser

52
aplicada a la industria del software, esta norma se acompaña de un
mecanismo de certificación.
Esta norma no se enfoca únicamente al desarrollo de software
específicamente y por ende su implementación y entendimiento se podría
tornar tedioso.

La norma se encuentra orientada a evaluar la capacidad de la

organización para cumplir los requisitos del cliente.

ISO/ IEC TR 15504: Es una norma que está orientada plenamente al

mantenimeitno y desarrollo de software, su estructura se encuentra
constituida por procesos, 24 para ser exactos, pero tiene sus contras, ya
que no es tan práctico, ni tan fácil de usar, además, no tiene un
mecanismo de evaluación, sólo dispone de los requerimientos para uno.

El SW-CMM determina el nivel de madurez de la organización.

También es específico para el desarrollo de software, a su vez éste dispone

de un modelo de evaluación para verificar si se están cumpliendo con las
pautas de la norma.

Las desventajas que encontramos son las siguientes:

 Una norma extranjera no es tan sencilla de entender

 No fue desarrollada pensando en empresas pequeñas y éstas son las

que más operan en México, he aquí la dificultad de aplicar la norma

 La manera de organizar los procesos no se ajustan plenamente a

empresas pequeñas

 Su evaluación resulta costosa

53
2.2 Modelos y estándares de procesos
Al hacer la evaluación de la adopción de los métodos más conocidos,
surge como una de las siete iniciativas de PROSOFT, alcanzar niveles
internacionales en capacidad de procesos y al ver que no se cumplían
todos los requisitos expresados por la industria del software, decidió
desarrollar un modelo nacional basado en los modelos evaluados. A
continuación se hablará de cada norma, ver figura 11.

ISO/ IEC TR 15504

ISO 9001:2000
MOPROSOFT

SW-CMM

Figura 11. MOPROSOFT basado en modelos de calidad de software.

ISO/ IEC TR 15504

Este estándar establece cuáles son los requerimientos para llevar a cabo
una evaluación de los procesos de desarrollo de software, para mejorarlos
y determinar su capacidad.

Se compone de 5 partes:

 Conceptos y vocabulario
 Realización de la evaluación

54
  Guía para la realización de la evaluación
 Guía sobre el uso para la mejora del proceso y la determinación de
éste
 Un ejemplo de evaluación de procesos

Para evaluar cada proceso se tiene un modelo de referencia externo

formado por otro conjunto de procesos divididos en 5 categorías:

 Cliente proveedor
 Ingeniería
 Soporte
 Administración
 Organización

Se usa otro marco para evaluar la capacidad de cada proceso:

Nivel 0 Inmadura
Nivel 1 Básica
Nivel 2 Gestionada
Nivel 3 Establecida
Nivel 4 Predecible
Nivel 5 Optimizado

Para cada proceso perteneciente a cada nivel de capacidad se realiza

una evaluación para ubicarlo en una escala:

N No conseguido
P Parcialmente conseguido
L Ampliamente conseguido
F Completamente conseguido

Entre las desventajas encontramos que, no es práctico ni fácil de aplicar,

no cuenta con un mecanismo para evaluar y no es una norma
internacional por ahora.

55
ISO 9001:2000

La Organización Internacional de Normalización (ISO) se integra por más

de 50 países, su misión consiste en el desarrollo y promoción de estándares
comunes a nivel mundial.

“Es un estándar genérico que se aplica a cualquier organización que

desee mejorar la calidad general de los productos, sistemas o servicios que
provee. Por lo tanto, se aplica de modo directo a compañías y
organizaciones de software.”1

Esta familia de normas se generó para asistir a todo tipo de organización

en cuanto a tipo y tamaño en la implantación y operación de sistemas de
gestión de la calidad (SGC). Lo forman un conjunto de elementos
relacionados y recursos necesarios para administrar la calidad, su
efectividad se refleja cuando es debidamente implantado.

El proceso de implementación consta de seis fases:

 Diagnóstico
 Planeación
 Documentación
 Implementación
 Certificación
 Mejora continua

Es una norma que nos sirve para evaluar la capacidad de la organización

y cumplir con las necesidades del cliente. Cuenta con un mecanismo de
certificación, aunque no se especifica para la industria del software, no es
fácil de entender, aplicar y no está definida como un conjunto de
procesos.

SW-CMM

Este modelo SW-CMM, Modelo de Madurez de Capacidades, surgió como

auxiliar de las organizaciones desarrolladoras de software para ayudar a
mejorar sus procesos y poder determinar la madurez de éstos apoyando a
la mejora continua.

1 Pressman S. Roger; Ingeniería de Software; McGraw-Hill, 6ta. edición. México, 2005, pág. 38.

56
Fue creado por el Software Engineering Institute (SEI) en conjunto con
Carnegie Mellon University.

La primera versión se publicó en 1994. SW-CMM describe un camino

evolutivo en 5 niveles de mejora de procesos para lograr su madurez.

Cubre prácticas de planeación, ingeniería y administración del desarrollo y

mantenimiento de software.

Niveles de madurez niveles para una mejora continua de procesos:

o Inicial. Proceso impredecible, pobremente controlado y reactivo. El

éxito depende del esfuerzo de los individuos

o Administrado. Proceso caracterizado por proyectos y a menudo

reactivo

o Definido. Proceso caracterizado porque la organización es

proactiva, se incluyen procesos de administración de ingeniería de
software

o Administrado. Cuantitativamente proceso medido y controlado para

medir la calidad y desempeño de los proyectos

o Optimizado. Mejoramiento del proceso. No es simplemente detectar

y resolver defectos, sino prevenirlos y evitarlos al implementar
actividades proactivas

La ventaja es que ya es específico para el desarrollo y mantenimiento del

software.

Tiene un modelo de evaluación, desde 1998 comenzó a ser popular en

México, ya hay empresas evaluadas.

Cubre prácticas de planeación, ingeniería y administración del desarrollo y

mantenimiento de software.

En cuanto a las desventajas encontramos que es un modelo extranjero, no

es fácil de entender y aplicar en organizaciones pequeñas, no se enfoca a
objetivos de negocios, la evaluación es costosa y se está abandonando
por CMMI.

57
Cada nivel requiere la implementación de ciertas áreas de proceso que
permiten madurar a la organización en general.

Las áreas que se seleccionan son las que interesan madurar a la

organización y se evalúan independientemente, contando con 6 niveles
de capacidad de proceso.

La mayoría de las empresas certificadas con SW-CMM son grandes y

multinacionales.

2.3 MOPROSOFT modelo de procesos de software

El objetivo de éste modelo es utilizar las mejores prácticas en gestión e
ingeniería de software, que al aplicarse en las organizaciones, éstas
obtengan y ofrezcan productos de buena calidad.
MOPROSOFT determina el nivel de madurez de la capacidad de cada
proceso a través de una evaluación, que permite colocar a la empresa en
uno de los siguientes 5 niveles los cuales se detallan en el capítulo 3.
EVALPROSOFT.

 Nivel 1. Proceso realizado

 Nivel 2. Proceso administrado

 Nivel 3. Proceso establecido

 Nivel 4. Proceso predecible

 Nivel 5. Optimización del proceso

También existe el nivel 0, que indica que el proceso está incompleto

(caos). El nivel de una empresa corresponde al nivel máximo al que están
todos sus nueve procesos.

 Gestión de negocio
 Gestión de procesos
 Gestión de proyectos
 Gestión de recursos

58
  Recursos humanos y ambiente de trabajo
 Bienes, servicios e infraestructura
 Conocimiento de la organización
 Administración de proyectos específicos
 Desarrollo y mantenimiento de software

Para pasar de un nivel al siguiente, la empresa debe cumplir todos los

requisitos de los niveles anteriores más los del nuevo nivel.

Entre las características importantes de este modelo encontramos que:

 Es específico para el área de desarrollo y mantenimiento del

software

 Fácil de entender

 Definido como un conjunto de procesos

 Orientado a mejorar procesos

 Aplicable como norma mexicana

 Cuenta con un mecanismo de evaluación o certificación

“Para su elaboración se siguieron algunos lineamientos.

 Generar una estructura de procesos de acuerdo a la estructura de la

organización.

 Destacar el rol de Alta dirección, para el buen funcionamiento de la

empresa.

 Considerar a la Gestión como un proveedor de los recursos, para el

buen cumplimiento del objetivo.

 Considerar a la Operación como el encargado de llevar a cabo los

proyectos de desarrollo y mantenimiento de software.

 Integrar todos los elementos necesarios para definir a los procesos.

59
  Integrar elementos para la ingeniería de productos del software
incluyendo los procesos de verificación, validación, documentación.

 Destacar la importancia de la Gestión de recursos, en particular los

productos generados, la documentación de cada proceso y la
información recolectada a partir de lecciones aprendidas.”

MOPROSOFT se ha enfocado a procesos que se encuentran divididos de

acuerdo a un área en específico, también llamadas categorías: Alta
dirección, Gerencia y Operación, esta última se integra de dos procesos: la
de administración de proyectos específicos y la del desarrollo y
mantenimiento del software.

En cada uno de los procesos y subprocesos se especifican los roles que son
los responsables de llevar a cabo cada proceso. Encontramos al cliente,
usuario, grupo directivo.

“Entre los principales productos a analizar tenemos:

◦ Productos de software. Se genera en el proceso de desarrollo y

mantenimiento del software, éstos se clasifican de manera
general como especificación de requerimientos, análisis y diseño,
software, prueba, registro de rastreo y manual.

◦ Configuración de software. Es un conjunto consistente de

productos de software.

◦ Plan. Se enlistan las actividades y responsabilidades a realizar por

calendario.

◦ Reporte. Informe del resultado de las actividades llevadas a

cabo.

◦ Registro. Evidencia de actividades desempeñadas.

◦ Lección aprendida. Experiencia positiva o negativa obtenida

durante la realización de la actividad.”2

2 Oktaba Hanna, et al. Modelo de procesos para la industria del software MOPROSOFT. Versión 1.5. Secretaria de
Economía, México, 2005, pág. 4.

60
Para cada uno de los nueve procesos, tenemos los siguientes elementos
involucrados en el patrón de procesos, el cual nos sirve de base para
documentar cada proceso.

Patrón de procesos

Nos ayuda para la documentación del proceso, proporcionándonos un

esquema de elementos que nos servirán de apoyo para la estandarización
de los procesos.

Está constituido por tres partes:

1. Definición general del proceso

2. Prácticas y
3. Guías de ajuste

“A continuación, se describen los elementos del patrón con mayor detalle.

1. Definición general del proceso

 Proceso. Nombre del proceso, precedido por un acrónimo.

 Categoría. Tipo de proceso.

 Propósito. Objetivos generales medibles y resultados esperados de la

implantación efectiva del proceso.

 Descripción de actividades. Descripción general de las actividades y

productos que componen el flujo de trabajo del proceso.

 Objetivos. Objetivos específicos cuya finalidad es asegurar el

cumplimiento del propósito del proceso. Los objetivos se identifican
como O1, O2, etc.

61
 Indicadores. Definición de los indicadores para evaluar la
efectividad del cumplimiento de los objetivos del proceso. Los
indicadores se identifican como I1, I2, etc. Y entre paréntesis se
especifica una o más identificaciones de los objetivos a los que dan
respuesta.

 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.

 Entradas. Se refiere a un producto, y se obtiene como resultado de

un proceso.

Nombre Fuente

Nombre del producto Referencia al origen

del producto

 Salidas. Se refiere a un producto o recurso.

Nombre Descripción Fuente

Nombre del producto Descripción y Referencia al

características destinatario del
del producto producto

 Referencias bibliográficas. Fuentes que sustentan el proceso.

62
2. Prácticas

Aquí se tienen a los roles involucrados con su capacitación, sus

actividades, también un diagrama de trabajo, verificaciones y
validaciones que van asociados con los productos generados, su
incorporación a la base de conocimiento, los recursos de infraestructura, la
capacitación necesaria para los roles involucrados, situaciones
excepcionales y las lecciones aprendidas durante la implantación de las
practicas.

 Roles involucrados y capacitación. Identificación de roles

involucrados y capacitación requerida.

Rol Abreviatura Capacitación

Responsable del generador Abreviatura del rol Capacitación requerida por

de reporte el rol para poder ejecutar el
proceso

 Actividades. Se asocian a los objetivos y describen las tareas y los

roles responsables para realizar cada actividad.

Rol Descripción

A1. Nombre de la actividad (O1, O2,…)

Abreviatura
del(os) A1.1 Descripción de tarea 1
rol(es)

A1.2 Descripción de tarea 2

A2. Nombre de la actividad (O1, O2, ...)

A2.1 Descripción de tarea 1

A2.2 Descripción de tarea 2

63
  Diagrama de flujo de trabajo. Diagrama de actividades, donde se
especifican las actividades del flujo de trabajo y los productos.

 Verificaciones y validaciones. Se identifican los defectos que deben

corregirse antes de continuar con las actividades posteriores.

Verificación o Actividad Producto Rol Descripción

validación

Identificación Identificación Nombre Abreviatura Descripción de la

de la de la tarea del del rol verificación o validación
verificación o producto responsable que se hará al producto
validación de realizar la
verificación o
Ver1 o Val1 validación

Ver2 o Val2

 Incorporación a la base del conocimiento. Repositorio de todos los

productos tales como productos de software, planes, reportes y otros
documentos.

Producto Forma de aprobación

Nombre del producto Identificación de la verificación,

validación o descripción

 Recursos de infraestructura. Conjunto de servicios necesarios para la

creación y funcionamiento de una organización.

Actividad Recurso

Identificación de la actividad o tarea Requerimientos de herramientas de

software y hardware

64
  Mediciones. Mediciones establecidas para evaluar a los indicadores
del proceso. Se identifican como M1, M2.

 Capacitación. Reglas para proporcionar la capacitación necesaria

a los roles involucradas.

 Situaciones excepcionales. Se refiere a la circunstancia que impide

que se realice una actividad.

 Lecciones aprendidas. Definición de los mecanismos para

aprovechar las lecciones aprendidas durante la ejecución de un
proceso.” 3

3. Guías de ajuste

Se hace mención de los cambios hechos al proceso los cuales no deben

afectar sus objetivos.

Modificación preestablecida a los roles, prácticas, entradas y salidas de un

proceso que no afecte al cumplimiento de sus objetivos.

A continuación tenemos el proceso tomado de la norma MOPROSOFT

“Conocimiento de la organización” basado en el patrón propuesto por
MOPROSOFT.

1. “Definición general del proceso

 Proceso. CONOCIMIENTO DE LA ORGANIZACIÓN.

 Categoría. Gerencia (GER).

 Propósito. El propósito de la organización es mantener disponible y

administrar la base del conocimiento que contiene la información y
los productos generados por la organización.

3
Oktaba Hanna, et al. Método de Evaluación de procesos para la industria de software EvalProSoft. Secretaria de
Economía, México, 2004, pág. 22.

65
  Descripción. En función del plan operativo de conocimiento de la
organización y acciones correctivas de Gestión de recursos se
realizan las siguientes actividades:

Las cuales se detallan en el diagrama de flujo de trabajo más adelante

donde se relacionan las siguientes actividades mencionadas.

 A1 O1Planificación

Entrada: Plan operativo de conocimiento de la organización

Actividades: Establecimiento del diseño de la base de conocimiento.

A1.1 Identificar, documentar o actualizar las actividades para la definición

o modificación del modelo conceptual de la base de conocimiento
(BC) de acuerdo al plan operativo de conocimiento de la
organización y acciones correctivas.

A1.2 Identificar usuarios de cada proceso y documentar o actualizar sus

requerimientos.

A1.3 Identificar los mecanismos de alimentación, consulta, mantenimiento

y respaldo para cada tipo de repositorio, en función de los
requerimientos de los usuarios.

A1.4 Integrar el plan de administración de la base de conocimiento.

A1.5 Validar el plan de administración de la base de conocimiento (Val1).

Salida: Plan de administración de la base de conocimiento con base en el

reporte de validación y obtener la aprobación de las correcciones.

 A2 Realización (O1)

Entrada: Plan de administración de la base de conocimiento.

Actividades:

A2.1 Diseñar o actualizar el modelo conceptual, incluyendo su meta

modelo, de la base de conocimiento, en función de los
requerimientos de los procesos.

66
A2.2 Definir o actualizar los mecanismos de alimentación, consulta,
mantenimiento y respaldo para cada tipo de repositorio, en función
de los requerimientos de los procesos.

A2.3 Integrar y documentar el diseño de la base de conocimiento de la

organización.

A2.4 Validar el diseño de la base de conocimiento (Val2).

A2.5 Corregir los defectos encontrados en el diseño de la base de

conocimiento con base en el reporte de validación y obtener la
aprobación de las correcciones.

A2.6 Poner en operación y dar mantenimiento a la base de conocimiento

para que se incorporen y consulten los productos aprobados
provenientes de todos los procesos y proyectos.

Salida: Diseño de la base de conocimiento y reporte de validación.

 A3 Evaluación y control (O1)

Entrada: Base del conocimiento, plan operativo de conocimiento de la

organización, plan de procesos.

Actividades:

A3.1 Revisar si el uso de la base de conocimiento se realiza acorde con los

mecanismos de alimentación, consulta, mantenimiento y respaldo
definidos.

A3.2 Generar un reporte del estado de la base de conocimiento, en

función del plan operativo de conocimiento de la organización.

A3.3 Generar el reporte de mediciones y sugerencias de mejora de este

proceso en función del plan de mediciones de procesos.

Salida: Reporte de estado de la base de conocimiento, reporte de

mediciones y sugerencia de mejora, lecciones aprendidas.

67
  Objetivos

O1. Proporcionar a la organización la base de conocimiento de forma

confiable, oportuna y segura mediante el cumplimiento del plan de
administración de la base de conocimiento.

 Indicadores

I1 (O1) Grado de satisfacción de los usuarios con respecto a los

mecanismos de alimentación, modificación y mantenimiento de la
base de conocimiento.

I2 (O1) Grado de satisfacción de los usuarios con respecto a los

mecanismos de consulta de la base de conocimiento.

I3 (O1) Grado de satisfacción de los usuarios con respecto a los

mecanismos de control de acceso y respaldo de la base de
conocimiento.

 Metas cuantitativas

Valor numérico o rango de satisfacción por indicador.

 Responsabilidad y autoridad

Responsabilidad: Responsable de Conocimiento de la Organización

Autoridad: Responsable de Gestión de recursos

 Procesos relacionados

Todos los procesos

68
 Entradas

Nombre Fuente

Productos del apartado Gestión de negocio

Incorporación a la base de
conocimiento Gestión de procesos

Gestión de proyectos

Gestión de recursos

Recursos humanos y
ambiente de trabajo

Bienes, servicios e
infraestructura

Conocimiento de la
organización

Administración de
proyectos específicos

Desarrollo y
mantenimiento de
software

Plan de procesos Gestión de procesos

Plan de mediciones de procesos

Plan operativo de conocimiento Gestión de recursos

de la organización

Acciones correctivas Gestión de recursos

69
  Salidas

Nombre Descripción Destino

Base de Contiene los siguientes repositorios:
Conocimiento Todos los
Negocio: documentación utilizada y generada en el procesos
proceso de gestión de negocio

Procesos: documentación utilizada y generada en el

proceso de gestión de procesos

Proyectos: documentación utilizada y generada en el

proceso de gestión de proyectos y administración de
proyectos específicos

Desarrollo y Mantenimiento: productos de software

generados en el proceso de desarrollo y mantenimiento
de software

Recursos: documentación utilizada y generada en el

proceso de gestión de recursos

Recursos humanos: documentación utilizada y generada

en el subproceso de recursos humanos y ambiente de
trabajo

Bienes adquiridos y proveedores: documentación utilizada

y generada en el subproceso de bienes, servicios e
infraestructura

Documentación BC: documentación utilizada y generada

acerca de su estructura, contenido y operación

Opcionalmente puede además contener:

Conocimiento tecnológico (terminología, conceptos,

metodologías)

Bibliotecas de reuso

Reporte de Registro que contiene: Gestión de

Mediciones y procesos
sugerencias Mediciones de los indicadores del proceso de
de mejora conocimiento de la organización (ver mediciones)
sugerencias de mejora al proceso de conocimiento de la
organización (métodos, herramientas, formatos,
estándares, entre otros)

Lecciones Registro de mejores prácticas, problemas recurrentes y Conocimiento

Aprendidas experiencias exitosas, durante la implantación de este de la
proceso organización

70
  Productos internos

Nombre Descripción

Plan de administración Descripción de actividades que lleven a definición o

de la base de modificación de los siguientes elementos de la BC:
conocimiento
(BC) · Modelo conceptual de la BC, usuarios de cada proceso y sus
requerimientos
· Mecanismos de operación, verificación, validación en función
de los requerimientos de los usuarios

Diseño de la base de Contiene el diseño del modelo conceptual, incluyendo su meta,

conocimiento y la definición de los mecanismos de operación: alimentación,
consulta, control de acceso, mantenimiento y respaldo para
cada tipo de repositorio

Reporte(s) de Registro de participantes, fecha, lugar, duración y defectos

validación encontrados

 Referencias bibliográficas

1. ISO 9001:2000 Sistemas de gestión de la calidad requisitos.

2. The Capability Maturity Model: Guidelines for Improving the Software

Process. Carnegie Mellon University, Software Engineering Institute.
1994. Addison Wesley.

3. ISO/ IEC TR 15504-2: 1998(E) Information Technology Software process

assessment. Part 2: A reference model for process and process
capability, v. 3.3.

71
2. Prácticas

 Roles involucrados y capacitación

Rol Abreviatura Capacitación

Responsable de gestión de RGR Conocimiento en el esfuerzo

recursos necesario para la administración
de la BC

Responsable del conocimiento RCO Conocimiento de definición y

de la organización administración de repositorios
documentales o automatizados

GRP
Grupo de responsables de Conocimiento de necesidades
Procesos del proceso con respecto a la
base de conocimiento

 Actividades


Rol Descripción

A1. Planificación (O1)

RCO A1.1 Identificar, documentar o actualizar las actividades para la definición

o modificación del modelo conceptual de la BC de acuerdo al plan
operativo de conocimiento de la organización y acciones correctivas

RCO A1.2 Identificar usuarios de cada proceso y documentar o actualizar sus

GRP requerimientos

RCO A1.3 Identificar los mecanismos de alimentación, consulta, mantenimiento

GRP y respaldo para cada tipo de repositorio, en función de los
requerimientos de los usuarios

RCO A1.4 Integrar el plan de administración de la BC

72
RGR A1.5 Validar el plan de administración de la BC (Val1)
GRP

RCO A1.6 Corregir los defectos encontrados en el plan de administración de la

base de conocimiento con base en el reporte de validación y
obtener la aprobación de las correcciones

A2. Realización (O1)

RCO A2.1 Diseñar o actualizar el modelo conceptual, incluyendo su meta

modelo, de la base de conocimiento, en función de los
requerimientos de los procesos

RCO A2.2 Definir o actualizar los mecanismos de alimentación, consulta,

mantenimiento y respaldo para cada tipo de repositorio, en función
de los requerimientos de los procesos

RCO A2.3 Integrar y documentar el diseño de la base de conocimiento de la

organización

GRP A2.4 Validar el diseño de la base de conocimiento (Val2)

RCO A2.5 Corregir los defectos encontrados en el diseño de la base de

conocimiento con base en el Reporte de validación y obtener la
aprobación de las correcciones

RCO A2.6 Poner en operación y dar mantenimiento a la base de conocimiento

para que se incorporen y consulten los productos aprobados
provenientes de todos los procesos y proyectos

A3. Evaluación y Control (O1)

RCO A3.1 Revisar si el uso de la base de conocimiento se realiza acorde con

los mecanismos de alimentación, consulta, mantenimiento y
respaldo definidos

RCO A3.2 Generar un reporte del estado de la base de conocimiento, en

función del plan operativo de conocimiento de la organización

RCO A3.3 Generar el reporte de mediciones y sugerencias de mejora de este

proceso en función del plan de mediciones de procesos

73
 RCO A3.4 Identificar las lecciones aprendidas de procesos e integrarlas a la
base de conocimiento. Ejemplo, se pueden considerar mejores
prácticas, experiencias exitosas de manejo de riesgos, problemas

 Diagrama de flujo de trabajo

A1 Planificación

PlanificaciónPlanif
icación
Plan operativo de conocimiento de la Plan de administración de la
organización base de conocimiento

Acciones
correctivas Diseño de la base
Reporte de conocimiento A2 Realización
de
validación

Base de
Se genera y utiliza conocimiento
en A1 y A2 (en operación)

Producto
(aprobado)

A3 Evaluación y control
Plan de
mediciones
de procesos
Reporte de mediciones
y sugerencias de
Reporte del estado de mejora
la base de
conocimiento

Lecciones
aprendidas

74
  Verificaciones y validaciones

Verificación Actividad Producto Rol Descripción

o
validación

Val 1 A1.5 Plan de RGR, Validar que todos los elementos del
Administración GRP plan de procesos sean viables y que
de la base de correspondan a las necesidades de
conocimiento los procesos

Los defectos encontrados se

documentan en un reporte de
validación

Val2 A2.4 Diseño de la GRP Validar que todos los elementos del
base de diseño de la base del conocimiento
conocimiento corresponden a las necesidades de
los procesos.

Los defectos encontrados se

documentan en un reporte de
validación

 Incorporación a la base del conocimiento

Producto Forma de aprobación

Plan de administración de la base de Val1

conocimiento

Diseño de base de conocimiento Val2

Reporte del estado de la base de conocimiento Ninguna

Reporte de mediciones y sugerencias de mejora

Lecciones aprendidas Ninguna

Reportes de validación Ninguna

75
  Recursos de infraestructura

Actividad Recurso

A1 A3 Herramienta para documentación

A2 A3 Herramientas automatizadas o no automatizadas de diseño, puesta

en operación y mantenimiento de la BC

 Mediciones

Con base en plan de mediciones de procesos se genera un reporte

periódico del avance de los indicadores del proceso referente a las metas
cuantitativas definidas, se sugieren las siguientes mediciones:

M1 (I1) Realizar encuestas a los usuarios para conocer la satisfacción

referente a los mecanismos de alimentación, modificación y
mantenimiento de la base de conocimiento.

M2 (I2) Realizar encuestas a los usuarios para conocer la satisfacción a los

mecanismos de consulta de la base de conocimiento.

M3 (I3) Realizar encuestas a los usuarios para conocer la satisfacción

referente a los mecanismos de control de acceso y respaldo de la
base de conocimiento.

 Capacitación

El responsable del conocimiento de la organización (RCO) deberá ofrecer

las facilidades para que el personal que está involucrado en el subproceso
de Conocimiento de la Organización (CO) participe en las actividades del
plan de capacitación actual de la base del conocimiento.

 Situaciones excepcionales

Los roles involucrados en este subproceso deberán notificar de manera

oportuna, las situaciones que les impidan el desarrollo de las actividades
asignadas.

76
El RCO deberá dar respuesta a estas situaciones y en caso de no poder
resolverlas o no sean de su competencia deberá escalarlas al RGR.

 Lecciones aprendidas

Antes de iniciar las actividades asignadas, los roles deberán consultar las
lecciones aprendidas en la base de conocimiento para aprovechar la
experiencia de la organización y disminuir la posibilidad de incurrir en
problemas recurrentes.

3. Guías de ajuste

 Base de conocimiento

De acuerdo al tamaño de la organización (en términos de personal y de

cantidad de proyectos que se desarrollan) la BC puede iniciarse de
manera simplificada manteniéndola en forma documental total o
parcialmente. Sin embargo se puede trabajar en un diseño conceptual
que permita su adecuado manejo y su eventual automatización con
apoyo de herramientas de manejo de bases de datos.

 Diseño de la base de conocimiento

La estructura de los repositorios puede ser ajustada a las necesidades o a

la estructura de base la de conocimiento ya establecida en la
organización. ”4

Ya que se definió a detalle cada parte que conforma la estructura del

patrón propuesto por MOPROSOFT, ahora se muestran dos ejemplos.

4
Oktaba Hanna, et al. Modelo de procesos para la industria del software MOPROSOFT. Secretaria de Economía, México,
2005, pág. 73.

77
1. Nombre: Reportes para funcionales.

 Propósito:

Diseñar un sistema que genere números de reportes para la atención

de multifuncionales con fallas en sitio.

Ordenar la información por grupos pertenecientes a cada

coordinador de cada estado de la república, mostrar datos de serie
del equipo, modelo, domicilio, falla, números de reporte tanto para
el cliente como para servicio técnico.

 Descripción:

Obtener el número de reporte al ingresar la serie y corroborar datos

y falla del equipo para su pronta atención.

 Objetivos:

O1 Contar con la herramienta de software necesaria para correr la

aplicación.

 Indicadores:

I1 (O1) Se obtuvo el número de reporte adecuadamente mostrando

la información solicitada completa.

Metas cuantitativas:

 Responsabilidad y autoridad:

Persona responsable de generar el reporte del área de servicio.

 Procesos relacionados:

 Solicitar número de serie del equipo y validarla

78
  Solicitar datos de domicilio y falla, corroborarla

 Corroborar localidad para direccionar a la carga del coordinador

correcto

 Enviar información al coordinador para que este proporcione el

reporte al ingeniero de servicio de cada área para dar la atención
oportuna en tiempo

 Entradas

Nombre Fuente

# Serie del equipo Cliente

Equipo inoperante Cliente

 Salidas

Nombre Fuente

# Reporte para el cliente Persona que levanta

reporte

# Reporte para ingeniero de Persona que levanta el

servicio reporte

Equipo reparado Ingeniero

 Productos internos

Nombre Descripción

Esfuerzo físico Desgaste que sufre el cuerpo humano al momento de elevar el

automóvil, quitar la llanta ponchada y poner la llanta no ponchada

79
  Referencias bibliográficas

Listas de modelos, listas de series, información de coordinadores por

localidad y grupos correspondientes, cursos de ingenieros, cobertura por
ingeniero.

2. Prácticas

 Roles involucrados y capacitación

Rol Abreviatura Capacitación

Responsable del RGR Conocimiento del sistema

generador de reporte

Responsable del RCOOR Conocimientos del sistema

coordinador

Responsable de la ING Conocimientos de electrónica, sistemas, y

reparación cursos de los equipos multifuncionales

 Actividades

Rol Descripción

A.1 Solicitar número de serie

RGR A.1.1 Ingresar en sistema la serie, y validar

vigencia de contrato o garantía

RGR A.1.2 Solicitar datos de domicilio

RGR A.1.3 Corroborar datos como domicilio, grupo, y

coordinador

RGR A.1.4 Generar número de reporte para el cliente y

servicio técnico

RGR A.1.5 Proporcionar ambos números de reporte al

80
 coordinador para su seguimiento

A.2 Proporcionar datos al ingeniero de servicio

RCOOR A.2.1 Verificar datos para direccionar

RCOOR A.2.2 Pasar datos al ingeniero y el número de

reporte

RCOOR A.2.3 Despachar servicio

A.3 Reparación de equipos

ING A.3.1 Tomar datos

ING A.3.2 Tomar reporte

ING A.3.3 Hacer diagnóstico y reparar el equipo

ING A.3.4 Obtener firma de conformidad del cliente

ING A.3.5 Proporcionar estatus del servicio

A.4 Conclusión reporte

RCOOR A.4.1 Ingresar datos de tiempos de visita y estatus

RCOOR A.4.2 Cerrar reporte

Las actividades se muestran en el diagrama de flujo de trabajo siguiente.

81
  Diagrama de flujo

Entradas Salidas
Solicitar número de serie

# Reporte para el cliente

# Serie del Equipo
equipo inoperante
Proporcionar datos al
ingeniero de servicio

# Reporte para
ingeniero de servicio

Reparación de equipos

Equipo reparado

Conclusión reporte

 Verificaciones y validaciones

Verificación o Actividad Producto Rol Descripción

validación

Val 1 A. 1.5 Reporte del RGR Verificar la

cliente generación
correcta del
reporte

Val 2 A. 2.2 Reporte del RGR Verificar el

ingeniero de número de
servicio reporte

Val 3 A. 3.5 Equipo ING Verificar el

funcionando funcionamiento
del equipo

82
  Incorporación a la base de conocimiento

 No aplica

 Recursos de infraestructura

Actividad Recurso

A.1.1, A.1.3, A.1.4, A.2.1, A.2.3 Computadora

A. 3.3 Herramienta para reparar

equipo

 Mediciones

 Generar correctamente el reporte

 Funcionamiento del equipo al 100%

 Capacitación

 Haber pasado por un curso intensivo del manejo del sistema y

generación de reportes
 Que las personas que reparen los equipos tengan un perfil ingenieril
 Que los ingenieros hayan aprobado los cursos para el diagnóstico y
reparación de multifuncionales

 Situaciones excepcionales

 Los equipos no están dados de alta, no tienen garantía o contrato

vigente, adeudo
 Los grupos donde corresponde cada equipo por coordinador no
están correctos
 No aparece la nómina del ingeniero en sistema
 Condiciones externas para la atención del reporte, tráfico, tiempo
de traslado, etc
 Falla en el automóvil

83
  Lecciones aprendidas

 Platica tus experiencias

 El cliente no proporciona serie correcta
 El equipo cuente con póliza de servicio
 No se corroboran datos, hay errores en el número de calle o teléfono
 Canalizar adecuadamente el reporte

3. Guías de ajuste

 Referencias bibliográficas

 No se cuenta en el momento con alguna documentación formal

que sustente el proceso

 Base de conocimiento

 Esta base debe contener información del uso del sistema,

conocimiento de equipos por modelo
 Cursos de los ingenieros
 Fallas en equipos multifuncionales

A continuación, se enuncia otro ejemplo más común para su mejor

entendimiento.

1. Nombre: Cambiar llanta ponchada de un automóvil estándar.

 Propósito

Cambiar una llanta ponchada por una en buen estado.

84
  Descripción

El cambio de llanta ponchada se ocupa de sustituir una llanta que sufrió un

daño que la inhabilita operacionalmente para seguir funcionando. Contar
con una llanta en buen estado, quitar la llanta ponchada, colocarla llanta
en buen estado y guardar la chanta ponchada.

 Objetivo

O1 Contar con la llanta en buen estado.

 Indicadores

I1 (O1) La llanta fue colocada correctamente para su operación normal.

Metas cuantitativas

 Responsabilidad y autoridad

 Responsable de cambio de llanta

 Procesos relacionados

 Conseguir llanta no ponchada

 Conseguir herramienta
 Guardar herramienta
 Transportar llanta ponchada a vulcanizadora
 Vulcanizar la llanta

 Entradas

Nombre Fuente

Llanta en buen estado Cajuela

85
  Salidas

Nombre Fuente

Llanta ponchada Cajuela

 Productos internos

Nombre Descripción

Esfuerzo físico Desgaste que sufre el cuerpo humano al momento de elevar el

automóvil, quitar la llanta ponchada y poner una llanta en buen
estado

 Referencias bibliográficas

 No aplica

2. Prácticas

 Roles involucrados y capacitación

Rol Abreviatura Capacitación

Responsable de cambio de RCL Conocimiento del esfuerzo requerido

llanta para cambiar una llanta

86
 Actividades

Rol Descripción

A.1 Quitar llanta ponchada

RCL A.1.1 Aflojar birlos

RCL A.1.2 Colocar el gato en la posición correcta

RCL A.1.3 Elevar el automóvil

RCL A.1.4 Desatornillar completamente los birlos

RCL A.1.5 Sacar llanta ponchada de..

A.2 Colocar llanta no ponchada

RCL A.2.1 Poner llanta en…

A.2.2 Colocar birlos con la mano hasta donde sea

RCL posible

RCL A.2.3 Bajar automóvil

RCL A.2.4 Retirar gato

RCL A.2.5 Atornillar birlos con la llave

87
  Diagrama de flujo

Entrada Salida

Llanta en buen Llanta

estado ponchada

Quitar llanta ponchada

Colocar llanta no ponchada

ponchadaponchada

Aquí se enlistan cada una de las actividades realizadas para llevar a cabo
el proceso para la obtención del objetivo deseado.

 Verificaciones y validaciones

Verificación Actividad Producto Rol Descripción

o validación

Val 1 A.1.5 Llanta RCL Verificar visualmente

ponchada que la llanta está
ponchada

 Incorporación a la base de conocimiento

 No aplica

88
  Recursos de infraestructura

Actividad Recurso

A.1.1, A.1.4, A.2.5 Llave

A.1.2, A.1.3, A.2.3, A.2.4 Gato

 Mediciones

 Que la llanta no se salga

 Que la llanta gire sin oscilar

 Capacitación

Haber pasado por un curso intensivo de cambiar dos veces una llanta.

 Situaciones excepcionales

 Los birlos se barren, inflar la llanta con el aerosol maravilla y llevar el

automóvil a la vulcanizadora

 Los birlos no se pueden desatornillar porque están muy apretados,

poner afloja todo al birlo y esperar o utilizar compresora
 Los birlos no se pueden desatornillar porque no corresponde la llave,
conseguir la llave correspondiente

 Lecciones aprendidas

 Se platica lo sucedido

89
3. Guías de ajuste

 Referencias bibliográficas

 No se cuenta en el momento con alguna documentación formal

que sustente el proceso

 Base de Conocimiento (BC)

Al parecer no aplica esta sección al proceso debido a las características

que tiene, ya que se hace de manera empírica.

Con el paso del tiempo los procesos deben evolucionar con base en las
sugerencias, para así alcanzar el objetivo establecido en el plan
estratégico de la organización, con metas más ambiciosas, de esta
manera se va alcanzando la madurez a través de la mejora continua de
procesos y al mismo tiempo se puede pensar en innovaciones de
productos.

En el capítulo 2, Programa para el desarrollo de la industria del software, se

definen y analizan los modelos como ISO 9001:2000, ISO/IEC TR 15504
usados para desarrollar software, se describieron los elementos principales
de la norma que forman la estructura de cada proceso contenidos en el
patrón de procesos, así como la importancia de su documentación y uso
del modelo en dos ámbitos diferentes, necesarios para la implantación en
una organización.

La documentación es el soporte del sistema de gestión de la calidad, pues

en ella se plasman no sólo las formas de operar de la organización, sino
toda la información que permite el desarrollo de todos los procesos y
proporcionan la información necesaria para la adecuada toma de
decisiones.

También se hace mención de las principales características del modelo

MOPROSOFT y los lineamientos que se siguieron para su elaboración.

Se muestran dos ejemplos usando el patrón propuesto para su

documentación, definiendo cada punto que lo confirman para el uso
adecuado, pues es de suma importancia para mostrar los productos
involucrados en cada proceso, los planes seguidos por la organización,
reportes registros y lecciones aprendidas evidencias que demuestran el
correcto orden para la generación del producto de software.

90