- Resumen
- Introducción
- Análisis crítico de propuestas existentes
- Normas ISO
- Modelo FMEA (Failure mode and effects analysis)
- Modelo EFQM (European Foundation for Quality Management)
- Conclusiones
- Recomendaciones
- Referencias bibliográficas
Resumen
En los últimos años ha aumentado considerablemente la producción de software debido a la alta demanda del uso de las tecnologías de la información en lo económico, político y social; contar con modelos y estándares para medir la calidad adquiere importancia relevante para cualquier empresa desarrolladora de software. El objetivo principal del trabajo ha sido presentar los modelos y estándares más importantes para la validación, verificación y calidad de software. El resultado de esta investigación se alcanzó usando metodologías basadas fundamentalmente en la búsqueda, síntesis y análisis crítico de la información; después de revisar los modelos y estándares para la validación, verificación y calidad de software encontradas en la literatura se ponen a disposición los detalles técnicos más relevantes a los equipos de desarrolladores y empresas en general dedicadas a la producción de software para que cuenten con alternativas en la selección y aplicación adecuada de los modelos y estándares durante el control de calidad.
Palabras claves: Expectativas, Capacidad, Compromiso, Revisión.
Abstract
In the last years it has increased the software production considerably due to the discharge it demands of the use of the technologies of the information in the economic, political and social; to have models and standards to measure the quality acquires outstanding importance for any software developing company. The main objective of the work has been to present the models and more important standards for the validation, verification and software quality. The result of this investigation was reached using methodologies based fundamentally on the search, synthesis and critical analysis of the information; after revising the models and standards for the validation, verification and software quality found in the literature they put on to disposition the most outstanding technical details to the teams of developers and companies in general dedicated to the software production so that they count with alternative in the selection and appropriate application of the models and standard during the control of quality.
Key word: Expectation, Ability, Commitments, Review.
Introducción
Uno de los grandes problemas que enfrenta la producción de software tan necesario para el desarrollo de las Tecnologías de la información (TI) es el costo de desarrollo y la calidad con que estos son entregados a usuarios finales para su puesta en explotación. En la actualidad una de las disciplinas que propician contar con programas o aplicaciones de funcionalidad probada que garantiza el desarrollo de las TI es previamente la gestión de la calidad en el proceso de desarrollo de software.
Desde los primeros momentos en que se comenzó a desarrollar programas de aplicaciones; los errores y defectos que estás presentaban a la hora de la entrega y puesta en explotación dejaron clara la necesidad de propiciar un ambiente de gestión de la calidad con el objetivo de garantizar el funcionamiento óptimo de las aplicaciones, mejorando el proceso de desarrollo para entregar al usuario un producto con calidad.
A partir de esta problemática, el presente trabajo tiene el objetivo de identificar un grupo de modelos y estándares que pueden ser utilizados por los especialistas dedicados a tareas de calidad inmersos en procesos de desarrollo o auditorias de software. En la gestión de la calidad de los procesos y proyectos se utilizan métricas para medir características del producto y tomar después las decisiones en cuanto a la eliminación de los defectos, evitando costos innecesarios y entregas prolongadas del producto en desarrollo.
Los modelos y estándares de calidad más difundidos en la actualidad con los cuales se garantiza dar seguimiento a los atributos de funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad y conformidad son CMM – CMMI (Modelo para medir capacidades y madurez en los procesos), Normas ISO 9000 (referencias a los modelos de calidad), entre las que podemos encontrar especificaciones para la calidad de un producto, así como de los procesos en los que se creó dicho producto.
Análisis crítico de propuestas existentes
Desde el año 1977 en que McCall y Cavano establecieron los factores de calidad como los primeros pasos hacia el desarrollo de métricas de la calidad del software, todos los estándares y modelo se sustentaron en dichos factores de calidad.
En este contexto, los modelos de calidad son sistemas basados en estudios experimentales de mejores prácticas que ayudan a una organización a implantar un sistema de aseguramiento de la calidad. Los modelos de calidad se dividen en modelos de referencia, que indican cuáles son las prácticas pero no cómo se consiguen, y los modelos de implantación que se enfocan en cómo se consiguen aquellas prácticas.
Teniendo en cuenta que para las compañías un producto o servicio es de calidad cuando satisface las necesidades y expectativas del cliente otorgando a éste seguridad sobre el uso del mismo, fiabilidad de las funciones esperadas y confianza en un producto o servicio sin fallos y duradero según tiempos establecidos y acordados, en torno a estos elementos gira el concepto de calidad; y para medir por decirlo de alguna forma la calidad del software existen actualmente una serie de modelos de calidad de los cuales queremos hacer un breve análisis.
CMMI (Modelo de Madurez de Capacidades) es un modelo de referencia que a diferencia de otros modelos por el hecho de estar basado en prácticas ajustables a cualquier dominio de producción y poseer un enfoque global e integrado de la organización, con el propósito de alcanzar los objetivos del negocio, esto hace que este modelo de calidad sea engorroso para la implantación del mismo en las empresas. (Donde las características y condiciones de desarrollo de software son muy específicas para cada entorno).
El Software Engineering Institute (SEI) de la Carnegie Mellon University de los Estados Unidos, creador del modelo CMMI y de la mayoría de sus predecesores, ha elaborado sus modelos bajo la premisa que la calidad de un producto o servicio está altamente influenciada por la calidad de los procesos que los producen y los mantienen, incrementando el nivel de capacidad y madurez de una organización. Los procesos en conjunto transitan desde procesos no definidos, es decir, procesos cuya organización cuenta con poca capacidad y con inmadurez para realizarlos, a procesos disciplinados cuya organización cuenta con la capacidad y madurez suficiente para desarrollarlos con calidad probada. Luego una organización es capaz de definir su calidad total por medio del nivel de madurez de capacidades en que se encuentre de acuerdo a sus procesos.
La representación usada en CMMI entrega una guía para efectuar las actividades de mejora de los procesos y es utilizada en el método de evaluación. Según el modelo se tienen dos formas para mejorar. Una forma es mejorar un proceso específico o un conjunto de ellos usando la Representación Continua (Continuous Representation) y la otra es la mejora de la organización completa según los procesos definidos y ocupados usando la Representación Escalonada o por Etapas (Staged Representation). En la tabla No. 1 se muestran los niveles para estos dos tipos de representaciones.
Tabla No. 1: Niveles de Representación continua y escalonada.
Representación Continua | Representación Escalonada | |||||
Nivel de capacidad | Nivel de Madurez | |||||
Nivel 0 | Incompleto | |||||
Nivel 1 | Realizado | Inicial | ||||
Nivel 2 | Manejado | Manejado | ||||
Nivel 3 | Definido | Definido | ||||
Nivel 4 | Manejado cuantitativamente | Manejado cuantitativamente | ||||
Nivel 5 | Optimizado | Optimizado |
Representación continua: La representación continua se focaliza en la mejora de un proceso o un conjunto de ellos relacionados estrechamente a un área de proceso en que una organización desea mejorar, por lo tanto una organización pude ser certificada para un área de proceso en cierto nivel de capacidad. Existen seis niveles de capacidad por donde transitan los procesos asociados a un área de proceso y cada nivel es construido sobre el nivel anterior, es decir para que un proceso alcance un nivel de capacidad necesariamente debe haber alcanzado el nivel anterior.
Representación escalonada: En la representación escalonada o por etapas se ofrece un método estructurado y sistemático de mejoramiento de procesos, que implica mejorar por etapas o niveles. Al alcanzar un nivel, la organización se asegura de contar con una infraestructura robusta en términos de procesos para optar a alcanzar el nivel siguiente. Por lo tanto es una organización la que puede ser certificada bajo un nivel, en este caso llamado nivel de madurez. Según esta representación un nivel de madurez está compuesto por áreas de procesos (ver tabla 2) en donde los objetivos asociados a ese nivel deben ser cumplidos para que la organización pueda certificarse en aquel nivel de madurez. Se implementan cinco niveles de madurez por los que se van evaluando las entidades según las condiciones para el desarrollo de sistemas de aplicaciones, en cada nivel se evaluará el nivel de madurez alcanzado.
El modelo CMMI constituye un modelo de validación de calidad ya que al aplicarse a las área de proceso estas transitan de un nivel inferior a un nivel más alto de calidad lo que hace posible agregar una valor de calidad superior a los productos software que son elaborados bajo estos estándares. Desde el punto de vista del desarrollo de software existe un mejoramiento por etapas o ciclos de desarrollo alcanzándose un nivel de madurez superior aplicando métricas establecidas en el modelo CMMI el cual está orientado fundamentalmente a la mejora continua del proceso influyendo positivamente estas mejoras en la calidad, no desde el punto de vista de los desarrolladores, si no, que al mejorar continuamente el proceso evaluando cada una de las etapas por las cuales transita el producto (software) existen en ellas un aumento de la calidad ya que la misma es verificada durante estas.
Utilizando CMMI en el área de desarrollo de software se valida la gestión de proyectos, se logra durante la fase inicial de desarrollo un despliegue de los requerimientos donde se asegura la calidad de los procesos y productos desde edades tempranas del desarrollo, al utilizar este estándar se prevé una medición y análisis constante de la calidad del software en desarrollo, así como, el monitoreo y control de los proyectos en ejecución por grupos o direcciones y a nivel gerencial.
Las acciones que provee la aplicación de este estándar para validación son específicas para cada una de las áreas de procesos para lograr alta calidad y prever mejoras continuas en el producto en desarrollo teniendo presente que la validación de requerimientos se realiza tempranamente con los usuarios para obtener certeza de que los requerimientos permitirán guiar el desarrollo que resulte en una validación final exitosa demostrando que el producto (software), componentes del producto (componentes del software) y los artefactos utilizados se corresponden con las especificaciones iníciales para su uso. Las organizaciones con un grado de madurez aceptable realizara la validación de requerimientos de una manera más sofisticada aplicando diversas técnicas y aplicarán la base de la validación para incluir necesidades y expectativas de otras partes interesadas (usuarios del futuro software, terceros y proveedores de software al equipo de desarrollo u organización).
También existen en el modelo CMMI acciones encaminadas a la verificación que demuestran que el producto (software), componentes del producto (componentes del software) y los artefactos utilizados cumplen con los requerimientos establecidos. Durante la realización de pruebas sean estas de Caja Negra o Caja Blanca se propicia un escenario ideal para la verificación de los requerimientos desde que el producto o software comienza a responder a los requisitos funcionales que lo proveen de funcionalidad; además utilizando este modelo se verifica bajo qué condiciones el producto es capaz de responder exitosamente a las solicitudes del usuario final, también se tendrán en cuenta los datos de confiabilidad arrojados de los análisis estadísticos realizados durante el ciclo de pruebas para verificar si cumple los parámetros especificados al inicio, lo que se utilizarán para determinar si el producto podrá ser entregado o no a los clientes cumpliendo determinados parámetros de funcionalidad, calidad y confiabilidad.
Una evaluación de CMMI
corresponde al estudio y análisis de uno o más procesos realizados
por un equipo capacitado de profesionales, utilizando un modelo de referencia
de evaluación como base para determinar fortalezas y debilidades dentro
de una organización. Un método de evaluación puede ser
aplicado para distintos propósitos, incluyendo evaluaciones internas
para mejora de los procesos, evaluaciones de capacidad de selección de
proveedores, evaluaciones de monitoreo de procesos, entre otros enfoques. Para
ello se han publicado documentos que sirven de guía para realizar una
evaluación CMMI.
En los documentos se relacionan un conjunto de requerimientos considerados esenciales para realizar una evaluación CMMI, definiendo tres clases de evaluaciones: clase A, clase B y clase C. las clases definen los requerimientos que deben cumplir una evaluación de cierta complejidad.
La clase A corresponde al método de evaluación que satisface el 100 % de los requerimientos que el documento define y es la única evaluación que se considera oficial para otorgar un nivel de certificación de CMMI en una organización.
La evaluación clase B está basada en la evaluación clase A. la evaluación clase B ayuda a una organización a comprender, con relativamente alto grado de confianza, el estado de los procesos relativos a CMMI.
La evaluación clase C es menos formal aún, es de menor duración y con muy poca información, además es realizada por sólo una persona y tiene por objetivo evaluar pequeños aspectos de la organización que quieren apoyarse en bases más sólidas.
Hay cuatro grupos o categorías de áreas de procesos que ayudan a guiar el proceso de mejora de la organización. Estos grupos están formados por áreas de proceso que se interrelacionan fuertemente y tienen características comunes asociadas a objetivos de negocio tradicionales. Estas categorías son las indicadas en la tabla No. 2 para cada área de proceso. En el caso de las áreas de procesos de ingeniería pueden integrar los procesos asociados con diferentes disciplinas de ingeniería cuando el producto final es consecuencia de ellas, dando así un soporte para estrategias organizacionales orientadas al producto.
El modelo CMMI es engorroso de implementar en procesos de desarrollo, se requiere de personal altamente cualificado en sus documentos rectores, pero una vez creadas las condiciones para su implementación no sólo se logran certificar las áreas de proceso, si no, que se obtendrán productos de alta calidad y se implantaron las bases para la instauración de métricas de procesos las cuales estarán disponibles para futuros desarrollos de software.
Normas ISO
Las normas ISO (Organización Internacional para los Estándares) han desarrollado una serie de norma y modelos para la evaluación de la calidad de productos aplicables a productos generales, adaptándose casuísticamente al área de producción de software, en las que se exponen los conceptos de calidad para aplicarlos mejor al producto terminado (software) que al proceso de desarrollo. Estas normas hacen posible que se sigan patrones de calidad generalmente aceptados con los que se logran métricas para determinar las cualidades de un producto, teniendo en cuenta que en la práctica existen dos tipos de calidad:
Calidad externa, que corresponde a la satisfacción de los clientes. El logro de la calidad externa requiere proporcionar productos o servicios que satisfagan las expectativas del cliente para establecer lealtad con el cliente y de ese modo mejorar la participación en el mercado. Los beneficios de la calidad externa son los clientes y los socios externos de una compañía. Por lo tanto, este tipo de procedimientos requiere escuchar a los clientes y también debe permitir que se consideren las necesidades implícitas que los clientes no expresan.
Calidad interna, que corresponde al mejoramiento y validación de las operaciones internas de una compañía. El propósito de la calidad interna es implementar los medios para permitir la mejor descripción posible de la organización, validar y detectar funcionamientos incorrectos. Los beneficios de validar y verificar la calidad interna son de la administración y los empleados de la compañía. La validación y verificación de la calidad interna pasa generalmente por una etapa participativa en la que se identifican y formalizan los procesos internos.
La norma ISO 8402-94 define la calidad como:
El conjunto de características de una entidad que le otorgan la capacidad de satisfacer necesidades expresas e implícitas. Como podemos interpretar de este concepto estos modelos de calidad que se exponen en esta norma no son específicos para evaluar la calidad durante el desarrollo de un software, son procesos que evalúan la calidad desde un punto de vista general, sirviendo más bien a productos generales.
Esta norma más bien está orientada a la realización de auditorías sobre el proceso de desarrollo de software por lo que se pueden realizar auditorías internas y externas según se realicen o no en el seno de la estructura de una misma organización, condiciéndose con propósitos internos o externos, además las auditorias que se realizan al producto consistente en la realización de una re inspección o inspección paralela de materiales o productos realizada por técnicos independientes. Su objeto se limita a determinar el grado de conformidad de la inspección y no a la aceptación o no del producto. El proceso consiste en una verificación del nivel de calidad de un proceso o si el proceso trabaja al nivel exigido.
La norma ISO 9000:2000 también tiene otra definición muy parecida a la anterior norma, generalizando de igual forma el proceso de calidad para productos generales y no de software.
La norma mencionada anteriormente define la calidad como el conjunto de características intrínsecas para satisfacer requisitos.
En todas estas normas el propósito de calidad es proporcionarle al cliente una oferta apropiada con procesos controlados y al mismo tiempo garantizar que esta mejora no se traduzca en costos adicionales. Es posible mejorar un gran número de problemas a un bajo costo. Sin embargo, cuando más cerca se está de la perfección, más se elevan los costos.
Al revisar la norma cubana NCISO/IEC 9126 en su referencia 14598 podemos analizar como en ambas se da tratamiento a los conceptos de calidad referidos directamente al proceso de desarrollo de software y al producto, especificando en la referencia 14598 detalladamente que medir para cada una de las cualidades del proceso y el producto. Estas normas posibilitan establecer estándares para la validación, verificación y calidad de software; ya que define parámetros y atributos de calidad generalmente aceptados que hacen posible la utilización de determinado producto bajo dichos estándares de calidad. En la norma cubana de referencia se han establecido estándares de calidad que servirán de patrones para la verificación y validación de la calidad durante el desarrollo del software desde su fase inicial hasta la etapa de pruebas.
Estándar ISO 9126 del IEEE y la Mantenibilidad
El modelo de calidad establecido en la primera parte del estándar ISO 9126-1 ha sido desarrollado en un intento de identificar los atributos claves de calidad para el software: funcionabilidad, fiabilidad, usabilidad, eficiencia, Mantenibilidad y portabilidad. Estos atributos son mencionados en muchos de los estándares, pero el IEEE (Instituto de Ingeniería de Electricidad y Electrónica) lo hace de una forma clara precisando en cada uno de los atributos que características del software deben ser revisados, además se identifican para cada atributo los subatributos logrando un estándar dentro de los modelos para la validación, verificación y calidad de software.
El estándar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software; no obstante, cada organización tendrá la tarea de especificar precisamente su propio modelo. Esto debería ser hecho especificando los objetivos a alcanzar según las métricas de calidad, las cuales evalúan el grado de presencia de los atributos de calidad.
ISO 9126 distingue entre fallos y no conformidad, siendo un fallo el no cumplimiento de los requisitos previos, mientras que la no conformidad afecta a los requisitos especificados. Una distinción similar es hecha entre la validación y la verificación. Este estándar está pensado para los desarrolladores, adquirentes, personal que asegure la calidad y evaluadores independientes, responsables de especificar y evaluar la calidad del producto software, por tanto, puede servir para validar la completitud de una definición de requisitos, identificar requisitos de calidad de software, objetivos de diseño y prueba, criterios de aseguramiento de la calidad. La calidad de cualquier proceso del ciclo de vida del software influye en la calidad del producto software que, a su vez, contribuye a mejorar la calidad en el uso del producto.
Modelo FMEA (Failure mode and effects analysis)
El desafío es diseñar con calidad y confiabilidad temprano en el ciclo de desarrollo de software, el análisis de los modos y de los efectos de fallo (FMEA) es una metodología para analizar problemas potenciales de la confiabilidad temprano en el ciclo de desarrollo donde es más fácil tomar acciones para superar estas ediciones, de tal modo realzando confiabilidad con diseño. FMEA se utiliza para identificar modos de fallos potenciales en los sistemas, para determinar su efecto sobre la operación del producto, y para identificar acciones correctivas para atenuar las faltas.
Por lo que se recomienda el uso temprano y constante de FMEA en el proceso del diseño para que el ingeniero diseñe sin faltas y produzca productos agradables, confiables, seguros, y de alta calidad. FMEA también nos ayuda a capturar la información histórica que se convertirán en métricas para el uso en la mejora futura del producto.
Hay varios tipos de FMEA, algunas se utilizan mucho más que otras. FMEA debe ser hecho siempre que las faltas significaran daño o lesión potencial al usuario del sistema que es diseñado. Los tipos de FMEA son: Sistema (focos en funciones globales del sistema), Diseño (focos en componentes y subsistemas), Proceso (focos en procesos de la fabricación y de asambleas), Servicio (focos en funciones del servicio), Software (focos en funciones del software).
FMEA provee al ingeniero de una herramienta que pueda asistir al abastecimiento confiable, seguro, los productos agradables y los proceso del cliente. Teniendo la ayuda de FMEA el ingeniero identifica el producto potencial o faltas del proceso, en la siguiente utilidad: desarrollan el producto o los requisitos de proceso que reducen al mínimo la probabilidad de estas faltas, evalúe los requisitos obtenidos del cliente o de otros participantes en el proceso del diseño para asegurarse de que esos requisitos no introducen faltas potenciales, identificar las características del diseño que contribuyen a las faltas y las diseñan fuera del sistema o reducen al mínimo por lo menos los efectos que resultan, desarrollan los métodos y los procedimientos para desarrollar y para probar el producto o proceso para asegurarse de que las faltas se han eliminado con éxito, sigue y maneja los riesgos potenciales en el diseño. Seguir los riesgos contribuye al desarrollo de la memoria corporativa y del éxito de los productos futuros también, asegúrese de que cualquier falta que podría ocurrir no dañe o afecte seriamente a cliente del producto o proceso.
Concluimos que este es un modelo muy eficaz dentro de los estándares que se pueden seguir para realizar validación y verificación de software en desarrollo para registrar correctamente todas las faltas en que se incurre durante el desarrollo de un producto software por lo que será de importancia relevante en el momento de identificar métricas para futuros desarrollos, por lo que se considera altamente beneficioso el aplicar FMEA a los procesos de cualquier empresa de producción de software que se quiera certificar con el estándar CMMI o aplicar las normas ISO 9000.
Modelo EFQM (European Foundation for Quality Management)
La Fundación Europea para la Gestión de la Calidad (EFQM) fue fundada en 1988 con el objetivo de elevar la calidad de los procesos. La EFQM constituye un marcho de trabajo propicio para la autoevaluación de las organizaciones y la mejora continua de la calidad de los productos; no se considera un estándar propiamente de validación, verificación y calidad de software ya que fue creado inicialmente para gestionar la calidad de cualquier producto, sistema o servicio. Este es un modelo de excelencia que se aplica a los procesos industriales en general, pero en materia de calidad pude ser aplicado a los procesos de desarrollo de software ya que tienen en cuenta un rol clave; la mejora de la efectividad y la eficiencia de las organizaciones al reforzar la importancia de la calidad en todos los aspectos de sus actividades. También contribuye asistiendo y estimulando el desarrollo de políticas para el mejoramiento de la calidad. El modelo europeo es un modelo no normativo que sirve a las organizaciones como una autoevaluación y mejora continua de la calidad de sus productos.
Posibles problemas de investigación
1) Evaluación de calidad en software de gestión de contabilidad y finanzas.
2) Aplicación del modelo FMEA en diseño de sistemas de bases de datos.
3) Creación de plantillas para recoger métricas de calidad en el entorno de desarrollo .Net.
Conclusiones
El uso CMM – CMMI es una importante herramienta de trabajo en función de la calidad para orientar a las empresas de desarrollo de software.
La aplicación de los modelos y estándares disponibles para el control de la calidad del software deben ser valorados durante la aplicación de los mismos tomando en consideración la experiencia del personal de desarrollo, composición del equipo, exigencias y expectativas de los usuarios y las dimensiones del software asegurándonos de seleccionar correctamente el modelo o estándar que más se ajuste para la validación, verificación y control de la calidad en los procesos de desarrollo de software.
Aplicar el modelo FMEA es importante para las empresas desarrolladoras que deseen hacer análisis de las faltas cometidas durante el proceso de desarrollo de software para generar futuras métricas para el proceso de calidad.
Recomendaciones
Preparar el escenario idóneo en las empresas desarrolladoras de software para la aplicación de los modelos CMMI transitando por los diferentes niveles hasta alcanzar el nivel óptimo para garantizar un producto de alta calidad.
Referencias bibliográficas
[1-18]
1. AMITI (2002) AMITI, Asociación Mexicana de la Industria de Tecnologías de Información. Volume,
2. C., B.L., Property-based software engineering measurement. IEEE Transaction on Software Engineering. 1996. 68 -85.
3. Genero M., P.M.y.C.C., Metrics for Sotware Conceptual Models. 2004, Londres: Imperial College Press.
4. Glick, B., An SQA quality tracking methodology. En: Journal, 1990, 1990.
5. Gonzálo, C.A., Gestión del Proceso de Software. 2003, Madrid, España.
6. Hambling, B.F., Verification, validation and the achievement of quality: a holistic approach. En: Journal, 1991, 1991.
7. Ince, D., Introduction to software project management and quality assurance. En: London; New York, 1993.
8. Ivar Jacobson, G.B., James Rumbaugh, El Proceso Unificado de Desarrollo de Software. 2000: Addison Wesley Longman Inc.
9. M., G.F.y.P., Calidad en el desarrollo y mantenimiento de software. 2003, España, Ra-Ma.
10. Mario G. Piattini, F.O.G.R., Calidad en el desarrollo y mantenimineot del software. 2007, España. 344.
11. Mascorro, A.H., Manual del FMEA (AMEF). 2005.
12. Minguet Melián, J.M., La Calidad del software y su medida. 2008, Madrid, España. 264.
13. Perry, W.E., Quality assurance for information systems. En: QED technical publishing group, 1991.
14. Piattini, F.-M.E.y.M., Specification of Security Constraints in UML. Actas del 35th anual 2001 IEEE International Carnahan conference on Security Technology (ICCST 2001). 2001, Londres (Reino Unido). 163-171.
15. Piattini, F.-M.E.y.M., Designing Secure Database for OLS. Actas del Database and Expert Systems Applications: 14th International Conference, DEXA 2003. 2003, Springer-Verlag Berlin Heidelberg New York.
16. Pressman, R.S., Ingenieria de software, un enfoque práctico. Quinta Edición ed. 2002, Madrid: Mc Graw-Hill, Interamericana de España, S.A.
17. Stamatis, D.H., FMEA from theory to execution. 2003. 455.
18. Stockman, G.S., A Framework for software quality Measurement. En: Journal, 1990, Febrero 1990. Volumen 8; Número 2: p. 224-233.
Autor:
Ángel Eduardo Pentón Saucedo.
1) Desarrollador. Especialista "B" en Ciencias Informáticas. Empresa Comercializadora de Combustible Matanzas.
2) Profesor Adjunto. Universidad Central de Ciencias Pedagógicas de Matanzas.