- Gestión de calidad del
software - Las normas ISO
9000:2000 - Estrategia para la
aplicación de la ISO 9000:2000 aplicada a PYMES de
Software - Conclusiones
- Bibliografía
A lo largo del tiempo el
concepto de
calidad ha adquirido un carácter multidimensional, debido a que los
diferentes autores, conocidos como los gurús del tema, lo
han enfocado desde puntos de vistas diferentes: Deming, como
el grado predecible de uniformidad y conformidad a un bajo
costo que se
ajuste a las necesidades del mercado; Crosby,
como cumplir con los requisitos; Feigenbaum, como el conjunto
total de las características del producto de
marketing,
ingeniería, fabricación y mantenimiento
a través del cual el producto en uso satisfará las
expectativas del cliente y
Jurán, como la idoneidad o aptitud para el
uso.
En todas estas definiciones se valoran elementos comunes
como la satisfacción de necesidades o perspectivas del
cliente y la existencia de rasgos o requisitos para
satisfacerlas.
Para alcanzarla se ha decursado por varios estadios,
comenzando con la verificación y terminando en la calidad total,
pasando por el control y el
aseguramiento de la calidad. La tendencia internacional actual
está fundamentada en la aplicación y
certificación sobre la base de las normas ISO
9000 que suponen un lenguaje
común, adoptado ya por un elevado número de
países.
De ahí, que se pueda considerar como el concepto
más actual de calidad el definido por la ISO 9000:2000 ,
que la define como grado en el que un conjunto de
características inherentes cumplen con los
requisitos.
Además de las normas ISO 9000, para
lograr una efectiva gestión
de la calidad en determinados sectores es necesario
compatibilizarlas con otras normas específicas adecuadas
al tipo de actividad que desarrollan. Tal es el caso de las
empresas de la
industria del
software donde se
usan metodologías tan extendidas como el CMM y la ISO
SPICE, entre otros modelos.
Finalmente, la naturaleza
intangible de este negocio y el hecho de que el software
constituye un producto del conocimiento
de difícil estandarización, hace necesaria la
aplicación de otros modelos que prevén la
inclusión de la gestión del
conocimiento y su integración a los modelos de calidad, como
es el caso del EFQM de Excelencia, base del Premio Europeo de
Calidad.
Ante esta abundancia de modelos
teóricos y de normas de certificación las
pequeñas empresas de software o las principiantes se ven
ante el dilema de cuál es el mejor camino a escoger, el
más rápido y menos costoso que le permita asegurar
la calidad de su productos.
En este trabajo se
propone una estrategia
concreta que pretende esclarecer los conceptos y trazar un camino
para este tipo de empresas en aras de la difícil meta de
la calidad.
La calidad del software es definida por Pressman
(1998) como la concordancia con los requisitos funcionales
y de rendimiento explícitamente establecidos, con los
estándares de desarrollo explícitamente
documentados y con las características
implícitas que se esperan de todo software
desarrollado profesionalmente.A partir de esta definición vale la pena
señalar que no sólo afecta la calidad el
incumplimiento de los requisitos del cliente y los
explícitamente definidos por la ingeniería
de software, sino que los requisitos implícitos
también deben ser considerados. Téngase en
cuenta que pocas veces el cliente está en condiciones
reales de explicitar todo lo que se puede esperar del
producto, muchas veces por desconocimiento y otras por la
asunción tácita de muchas
funcionalidades.La gestión de la calidad se puede entender
como el conjunto de actividades y medios
necesarios para definir e implementar un sistema de
la calidad, por una parte y responsabilizarse de su control,
aseguramiento y mejora continua, por otra.
(Fernández & Alarcón, 1999). El control
está dirigido al cumplimiento de requisitos, el
aseguramiento a inspirar confianza en que se cumplirá
el requisito pertinente y el mejoramiento al aumento de su
eficiencia y
eficacia.La gestión
de calidad a nivel de la
organización en entidades de software ha seguido
dos líneas que pueden perfectamente complementarse
entre sí. Por una parte, se ha seguido la línea
marcada por las entidades internacionales de
estandarización para todos los productos y servicios
a través de las normas ISO 9000 y por otra, el mundo
del software ha creado su propia línea de trabajo en
la gestión de la calidad, trabajando sobre los
procesos
de producción de software como medio de
asegurar la calidad del producto final.Cuando los estándares de calidad se
orientaban sobre todo al control, en las organizaciones dedicadas al software aparecen
un grupo de
modelos específicos con ese fin: Modelo de
Boehm [Boehm et al., 1978], Modelo FCM
(Factors/Criteria/Metrics) [McCall et al.,
1977], Marco ISO 9126 [ISO/IEC, 1991], Paradigma
GQM (Goal-Question-Metric) [Basili y Rombach,
1988], Modelo de Gilb [Gilb, 1988].En los últimos años en que los
estándares de calidad internacionales se han
reorientado hacia el aseguramiento de la calidad, han
aparecido en la industria del software dos importantes
modelos de referencia que tienen en común la evaluación de la capacidad de los
procesos en niveles de desarrollo o madurez: Modelo
CMM (Capability Maturity Model) [Paulk, 1993] y
Modelo SPICE (Software Process Improvement and
Capability determination) [Rout, 1995], [SPICE,
1999].Estadísticas del Software Engineering
Institute (SEI) reportan que del total de empresas que
aplican CMM el 81 % se encuentra en el nivel 1, el 12 % en el
nivel 2 y el 7 % en el nivel 3. Ninguna ha alcanzado los
niveles 4 y 5. (Tinnirello, 1998). Esto da cuenta de la
rigurosidad del modelo y
de las pocas posibilidades que tendría las PYMES de
ubicarse en los niveles superiores.Las grandes empresas ya consolidadas pueden disponer
a su voluntad, y de hecho lo hacen, la implantación de
otras metodologías o esquemas propios para lograr la
calidad y la mejora continua de sus procesos productivos, sin
embargo, para las pequeñas y medianas empresas de
software la implantación de sistemas
de la calidad basados en las normas ISO 9000 puede constituir
el mejor camino a seguir pues estas normas definen los
requisitos básicos de la organización y por otro lado la
certificación le confiere un prestigio importante ante
sus clientes.La solución ideal para los que comienzan es
integrar ambos enfoques en la medida de los posible bajo el
principio de especificar en la ISO 9000 todas aquellas
características propias del producto de software que
se contemplan en las otras metodologías.- Gestión de
calidad del software. - Las normas ISO
9000:2000.
En 1947 se creó la International Organization for
Standartization, que es una federación mundial de
organismos nacionales de normalización, cuya sede actual está
en Ginebra.
En 1987 se publicaron por primera vez la familia de
normas ISO 9000 para el aseguramiento de la calidad, compuesta
por la norma ISO 8402: Vocabulario, la norma ISO 9000:
Directrices para la selección
de los modelos para el aseguramiento de la calidad y los tres
modelos ISO 9001, 9002 y
9003 que planteaban los requisitos para los sistemas de
calidad aplicables a empresas cuya actividad se enmarcaba en
determinadas etapas del ciclo de vida
del producto. Además apareció el modelo ISO 9004
dirigido al aseguramiento de la calidad en el orden
interno.
En el año 1994 se realizó una
revisión de estas normas y se introdujeron algunos cambios
que no variaron de manera sustancial la estructura
original de la familia del
año1987 , y en el año 2000 apareció la
última versión (vigente en la actualidad) en la
cual se introdujo el enfoque de procesos y los tres modelos (ISO
9001, ISO 9002 e ISO 9003) se unieron en el modelo ISO 9001:2000
aplicable a cualquier organización. Además la norma
ISO 8402 se sustituyó por la ISO 9000: Vocabulario y la
ISO 9004 se convirtió en el modelo para la mejora del
desempeño. La otra integrante de la familia
ISO 9000 (norma ISO 19011 para Auditorias de
los sistemas de gestión de la calidad y medioambientales)
amplió su alcance y se compatibilizó con las ISO 14
000.
¿Qué son las normas ISO?
Un conjunto de normas internacionales genéricas
que establecen sistemas de gestión de la calidad aplicados
por organizaciones de cualquier tipo o tamaño que fabrican
productos o componentes (hardware) ,fabrican
software, fabrican materiales
procesados, ofrecen servicios, desempeñan funciones de
administración
pública.
¿Qué no son las normas ISO?
- No son Especificaciones de Calidad de
Productos. - No son obligatorias.
- No es un programa de
corta duración. - No es el punto final de la mejora
continua
El modelo de un sistema de gestión de la calidad
basado en procesos que se muestra a
continuación ha servido a las organizaciones para enfocar
sus esfuerzos en aquellos procesos que aportan valor al
cliente y garantizan la satisfacción de sus necesidades
declaradas e implícitas:
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
El proceso de
Responsabilidad de la Dirección se identifica con los procesos
estratégicos que aportan directivas al resto de los
procesos, tales como la definición de políticas,
objetivos,
responsabilidad y autoridad,
comunicación, así como el compromiso
de la dirección y la revisión del sistema por parte
de ésta.
La gestión de recursos se
refiere a la infraestructura y los recursos
humanos, materiales y financieros que se identifica con los
procesos de apoyo que soportan los procesos de
realización, donde se manifiesta la cadena de
valor que transforma las necesidades y expectativas de los
clientes en productos que satisfagan sus expectativas.
Luego la medición, análisis y mejora permitirá
determinar la eficacia, eficiencia y efectividad del resto de los
proceso, y aportará la información necesaria para la toma de
decisiones y la mejora continua del producto, los procesos y
el sistema.
Es importante no ver estos procesos en orden
cronológico ni como correspondientes a diferentes partes
de la estructura de la organización, sino que son procesos
simultáneos, íntimamente relacionados y extensivos
a toda la organización.
Es común que las empresas que acometen la
implantación de sistemas de calidad ISO 9000 se enfrenten
a las siguientes situaciones:
- Se contratan consultores externos que aunque conozcan
la calidad a nivel gerencial desconocen las especificidades de
los procesos de software. Esto dificulta la adaptación
eficaz de la norma a la organización y afecta la
eficiencia del proceso de implantación. - El exceso de documentación provoca un rechazo general
a la aplicación de la norma. - Se pretende comenzar la implantación de arriba
hacia abajo, de modo que transcurre mucho tiempo en llegar al
proceso concreto de
realización del producto. Esto hace que no se vean
resultados a corto plazo. - Se da más importancia a las cuestiones
organizativas de la
administración que a las del propio proyecto. - No se consideran las especificidades del proceso
productivo como proceso de conocimiento: difícil
estandarización, intervención del cliente
prácticamente durante todo el proceso, mayor importancia
del servicio
posventa.
Para acometer la gestión de la calidad con
resultados intermedios que permitan a la empresa ir
obteniendo madurez en la medida en que avanza la
implantación de las normas, se propone definir 5 niveles,
ya no específicos al proceso de desarrollo del producto
como da cuenta el CMM, sino referentes a la gestión de la
calidad a nivel de toda la organización:
- Nivel inicial
- Nivel de proyecto.
- Nivel de gestión total de calidad
- Nivel de certificación
- Nivel de referencia
Nivel inicial
Toda empresa de
software aplica al menos un mínimo control de la calidad
de sus productos y establece algunos parámetros
mínimos como requisitos del producto.
Las empresas que trabajan a este nivel se caracterizan
por:
- Definición de políticas elementales de
contratación. - Obtención de las especificaciones de los
clientes. - Formación empírica de equipos de
trabajo de acuerdo a la disponibilidad de personal que se
tenga. - Compromisos de plazos de entrega sin criterios bien
fundamentados. - Uso de herramientas
de ingeniaría de software a voluntad de los
desarrolladores. - Empleo de los lenguajes de
programación en que se tiene experiencia, al no ser
que el cliente exija lo contrario. - Mínima documentación.
- Acta de aceptación del cliente quien
generalmente no está en condiciones de evaluar
adecuadamente el producto. - Deficiente organización del mantenimiento
posventa del producto.
Nivel de proyecto
En este nivel se incluyen: evaluaciones, revisiones y
auditorias, normas, procedimientos de
control y seguimiento de errores, así como el registro de la
información como vía de retroalimentación para la calidad del
proyecto. Algunas acciones
importantes que no pueden dejar de realizarse son: asegurar que
los procesos de ingeniería de software sean usados durante
todo el ciclo de vida del proyecto; evaluar mediante
métricas, los requerimientos de calidad de los productos;
chequear mediante métricas las condiciones anormales en
los procesos y eliminarlas antes de terminar el producto;
analizar las pérdidas de calidad para definir acciones
para el mejoramiento continuo del proceso de desarrollo de
software.
El siguiente modelo de Pressman (1998) muestra
fehacientemente como asegurar a nivel de proyecto la calidad de
proceso de desarrollo de software:
Para ver
el gráfico seleccione la opción "Descargar" del
menú superior
Es necesario partir de un pequeño número
de actividades del marco de trabajo que son aplicables a
todos los proyectos de
software, con independencia
de su tamaño y complejidad. Un conjunto de tareas
que permiten que las actividades del marco de trabajo se adapten
a las características del proceso de software y a los
requisitos del equipo de proyecto. Finalmente las actividades
de protección tales como la gestión de la
calidad del software, gestión de configuración del
software y la medición. Estas actividades serán
independientes del cualquier actividad del marco de trabajo y
deben aparecer durante todo el proceso.
A este nivel pudiera organizarse la actividad de la
forma siguiente:
- Establecer políticas y procedimientos
generales para: negociación del proyecto, decisión
de plazos de entrega, formación del equipo de proyecto,
decisión de plataformas de trabajo y lenguajes de
programación, documentación
mínima necesaria, herramientas comunes e imagen
corporativa implícita en el software a
desarrollar. - Planificar y organizar las tareas a ejecutar,
definiendo las métricas del proyecto, los hitos, las
pruebas a
realizar en cada uno. - Ejecución del proyecto.
- Control de calidad en cada uno de los hitos definidos
y al final. (el control incluye la verificación y
corrección).
Se definirán políticas en aquellos
aspectos donde se requiera un alto nivel de flexibilidad como
la negociación del proyecto y la decisión de
plataformas de trabajo y lenguajes de
programación.Pudiera definirse por ejemplo política de precios,
requisitos de los contratos y
todo lo que se relacione con el contacto directo con el
cliente, de modo que no se establezcan camisas de fuerza que
atenten finalmente contra su satisfacción con el
servicio que se le ofrece.Se definirán procedimientos en aquellos
aspectos donde sea posible regular cada uno de los pasos a
dar y las alternativas posibles a evaluar.Para la definición de plazos de entrega
pudiera trabajarse con rutas críticas o con las
herramientas del Microsoft
Project, por ejemplo. Para la formación del equipo de
proyecto sería necesario establecer un procedimiento
que permita establecer las competencias
que requiere el proyecto de sus especialistas, la
evaluación de esas competencias en el personal del que
se pueda disponer y las métricas de medición de
la inteligencia
emocional del equipo. Los documentos
mínimos pueden establecerse sobre la base de depurar
las metodologías de análisis de sistema
conocidas y definir lo que la organización considera
necesario y con qué estructura. La imagen
corporativa implícita en el software debe establecerse
como criterio inicial que facilite los diseños de las
diferentes interfaces. Las herramientas serán
definidas con el objetivo
de lograr una estandarización a nivel de la
organización.Para desarrollar este marco de trabajo pueden
crearse grupos de
especialistas donde la experiencia cuente en primer lugar y
obtenerse las políticas y procedimientos a partir de
sesiones de trabajo. El Consejo Técnico Asesor de la
Gerencia
puede ser una vía propicia.- Políticas y procedimientos
generales.Se definirán cada una de las tareas del
proyecto, se asignarán responsables, participantes,
plazos y formas de control. Las formas de control se
determinan a partir de definir las métricas en cada
etapa.Es importante que los controles se realicen en los
hitos previamente definidos de manera que no se entorpezca el
desarrollo del proyecto.Los períodos de control y corrección
deben preverse en el cronograma de desarrollo del
proyecto. - Planificación y organización de las
tareas. - Ejecución del proyecto.
Además de cumplir con las políticas y
procedimientos trazados así como con la planificación realizada, es importante
tener en cuenta dos aspectos: la ingeniería del software y
la documentación.
La ingeniería del software establece los
requerimientos tecnológicos del diseño.
Debe lograrse en la organización que todos sus
especialistas dominen las técnicas y
herramientas necesarias.
Teniendo en cuenta las diferencias profesionales y de
experiencia de los especialistas, es importante realizar acciones
de gestión del conocimiento y seguir, al menos, los
principios
básicos que garanticen la continua conversión del
conocimiento tácito en explícito y
viceversa.
Par ese fin se recomiendan algunas acciones de
fácil implementación:
- Integrar los equipos con personal de diferente nivel
de experiencia de modo que se trasmitan los conocimientos por
la mejor vía posible que es la
práctica. - Formar equipos multidisciplinarios en relación
con el proyecto, de manera que se compartan conocimientos de
acuerdo al know how no informático que se
requiere. - Estimular por diferentes vías la
compartición de los conocimientos, el desarrollo de
clases y objetos para uso común y conformar una biblioteca
compartida. - Discusiones en equipo de las soluciones
informáticas complejas y su explicitación por
escrito, de modo que no se requiera reinventar la
rueda. - Formación inicial de los especialistas de
reciente incorporación con políticas,
procedimientos, soluciones técnicas
documentadas. - Formación del cliente y empatía de modo
que se incorpore como un miembro del equipo, en posición
constructiva y proactiva.
Un aspecto vital tanto para la calidad del proyecto como
para ir sentando una cultura con
vistas a la futura implantación de sistemas de calidad a
nivel organizacional, es la documentación de cada una de
las etapas en paralelo al desarrollo, de forma que se eviten
omisiones o que la documentación sea una carga a realizar
una vez terminado el software.
Es necesario insistir en que a este nivel debe
establecerse la documentación mínima necesaria que
garantice la trazabilidad del proceso de desarrollo y que deje
constancia, sobre todo, de todos los contactos con el cliente.
Debe tenerse presente que en esta industria, a diferencia de la
mayoría, la interacción con el cliente se da a todo lo
largo del proceso.
- Control de calidad.
El control de
calidad en cada uno de los hitos debe realizarse por personal
especialmente dedicado a esta función.
Debe escogerse los técnicos de mayor
experiencia.
El control de calidad al final se recomienda lo realicen
círculos de calidad creados ad hoc para cada
proyecto.
La separación de las actividades de
análisis, programación e implantación es de
gran ayuda al permitir lograr de forma natural una contrapartida
permanente que sirva de retroalimentación durante todo el
proceso de desarrollo. Sin mencionar otros beneficios como el
incremento de los niveles de productividad.
Nivel de gestión total de
calidad.
Una vez superada la etapa de lograr la calidad en los
proyectos, la empresa estará en condiciones de revisar las
normas ISO 9000 de manera detallada y comenzar a adecuar sus
actividades y procesos a los requisitos mínimos que ellas
establecen.
Aquí es importante tener en cuenta:
- Como la norma admite que la documentación
puede estar en cualquier formato o tipo de medio, revisar los
diseños de la intranet y
de los sistemas de
información digital que minimicen la burocracia del
exceso de documentación con el que generalmente se
acompaña la implantación de estas
normas. - Dentro de la gestión de recursos, prestar la
máxima atención a la gestión del capital humano
(gestión del conocimiento a nivel de toda la
organización y control de indicadores
de capital
intelectual). - Revisar el proceso de materialización del
producto que se definió a nivel de proyecto a la
luz de la
norma. - Conceder especial importancia dentro de la
revisión de requisitos relacionados con el producto a
los no explícitos por parte del cliente y a los de
ingeniería de software. - El control de cambios de diseño y desarrollo
mediante los registros
adecuados garantizará la calidad del proceso de
mantenimiento del software. - La identificación y trazabilidad que establece
la norma se garantizará con una adecuada gestión
de la configuración. - La propiedad
del cliente requiere un respeto
riguroso: habrá que precisar la confidencialidad de la
información que se maneja y hasta donde llega la
participación del cliente en el know how no
informático del producto. - En la preservación de producto orientarse
especifican mete al control de versiones. - La medición, análisis y mejora se da en
dos etapas: durante el desarrollo del software utilizando las
métricas que proporcionan los múltiples modelos
existentes y el seguimiento y medición
posterior. - Se requiere implementar adecuados sistemas de
satisfacción del cliente que permita retroalimentarse
con el desempeño posterior del producto. Debe tenerse en
cuenta que estos productos demuestran su eficacia sobre todo en
momentos posteriores a su implementación cuando se
requieren cambios de su configuración o cuando el
volumen de
datos
procesados se hace significativamente grande. - Es importante implementar que la liberación
del producto la realice personal distinto al encargado de su
desarrollo.
Nivel de certificación.
Por la gran variabilidad de los procesos de desarrollo
de software, es importante buscar una estabilidad del nivel
anterior antes de pasar a este nivel.
Por otro lado, los procesos de desarrollo de software
ocurren en plazos mucho mayores que los procesos productivos y de
servicios convencionales, de ahí que para demostrar
resultados con vistas a la certificación hay que esperar
un tiempo mayor.
Una vez certificada la entidad tendrá que ser
capaz en el tiempo de demostrar su aptitud para mantener la
certificación otorgada en las auditorias recurrentes que
establecen las normas.
Nivel de referencia.
Existe una tendencia a considerar el proceso de
desarrollo de software como un proceso de I + D lo que no se
considera exacto. El verdadero proceso de investigación y desarrollo se da en el
software cuando se trabaja en nuevas herramientas de
ingeniería y en nuevos métodos de
trabajo que permitan obtener resultados superiores.
Las empresas de alto desempeño se convierten en
referencia para otras que comienzan a partir de convertir sus
métodos y experiencias en estándares de
trabajo.
Por otro lado, el desarrollo de software propicia la
producción de herramientas de ingeniería y de
codificación que hacen mas efectivos y
productivos los procesos.
- Muchas empresas prestigiosas de software implementan
sus propios modelos de calidad. - Para las pequeñas y medianas empresas de
software la implantación de sistemas de la calidad
basados en las normas ISO 9000 puede constituir el mejor camino
a seguir pues estas normas definen los requisitos
básicos de la organización y por otro lado la
certificación le confiere un prestigio importante ante
sus clientes. - La solución ideal para empresas principiantes
es integrar en la ISO 9000 todas aquellas
características propias del producto de software que se
contemplan en las otras metodologías. - La implantación de sistemas de calidad ISO
9000 en empresas de software debe hacerse por niveles de
desarrollo. - El nivel de proyecto constituye el núcleo de
la gestión de calidad en empresas de software ya que
cada proyecto es a su vez una
empresa. - La inclusión de la gestión del
conocimiento dentro del sistema de calidad es un requisito
básico para las empresas de software.
Basili, V.R. y Rombach, H.D., "The TAME Project:
Towards Improvement-Oriented Software Environments", IEEE
Transaction on Software Engineering,14(6), 758-73
1988.
Boehm, B.W., Kaspar, J.R. y otros "Characteristics of
Software Quality", TRW Series of Software Technology,
1978.
Boehm, B.W., Clark, B., Horowitz, E. et al., "Cost
Models for future life cycle processes: COCOMO 2.0", Annals
of Software Engineering 1(1), pp 1-24, 1995.
DeMarco, T., "Controlling Software Projects",
Yourdon Press, 1982.
Dolado, J.J. y Fernández, L. (coordinadores).
"Medición para la Gestión en la
Ingeniería del Software". Ra-ma, 2000.
Farbey, B., "Software Quality metrics: considerations
about requirements and requirements specification",
Information and Software Technology, 32 (1), pp 60-64,
1990.
Fernández, Luis y Miren Idoia Alarcón.
Necesidades de medición en la gestión y
aseguramiento de calidad del software. [en línea:
05/04/04] http://www.sc.ehu.es/jiwdocoj/remis/docs/aseguracal.htm
Gilb, T. "Principles of Software Engineering
Management", Addison-Wesley, 1988.
ISO/IEC "Information Technology – Information
Resources Dictionary System (IRDS) – Framework", ISO/IEC
intl. Standard edition, 1990.
ISO/IEC 9126, "Software Product Evaluation –
Quality Characteristics and Guidelines for their Use ",
1991.
Lorenz, M. and Kidd, J., "Object_oriented Software
Metrics", Prentice Hall 1994.
McCall, J.A., Richards, P.K. and Walters, G.F.
"Factors in Software Quality", RADC TR-77-369, US Rome Air
Development Center Reports NTIS AD/A-049 014, 015, 055,
1977.
Paulk, M., Curtis, B., Chrissis, M., and Weber, C.
"Capability Maturity Model for Software: Version 1.1".
Technical Report SEI-93-TR-24, Software Engineering Institute,
Carnegie Mellon University, Pittsburgh, Pennsylvania, USA,
1993.
Pressman, Roger S. (1998) Ingeniería de
software. Un enfoque práctico. Cuarta Edición, Madrid, Mc
Graw-Hill Interamericana de España
S.A.
Rout, T.P. "Software Process Improvement and
Practice", 1(1), pp 57-66, 1995.
Samson, W.B., Nevill, D.G. Y Dugard, P.I., "Predictive
software Metrics based on a Formal Specification", Software
Engineering Journal, 5(1), 1990.
SPICE, "SPICE Document Suite, Software Process
Improvement and Capability determination", , 1999.
Tinnirello, Paul C.,How's Your IT: Teetering Or
Leading-Edge PC Week May 11, v15 n19 p77, 1998
M.Sc. Abilio Marrero Rodríguez