Ingeniería del software (página 2)

METRICAS

Métricas de calidad. El concepto de métrica es el termino que describe muchos y muy variados casos de medición. Siendo una métrica una medida estadística (no cuantitativa como en otras disciplinas ejemplo física) que se aplica a todos los aspectos de calidad de software, los cuales deben ser medidos desde diferentes puntos de vista como el análisis, construcción, funcional, documentación, métodos, proceso, usuario, entre otros.

Para iniciar los elementos de medición, para nuestro caso se desarrollan tres diferentes tipos de medición, métricas técnicas, métricas Bang y métricas de punto de función.

Métricas Técnicas. Estas se presentan en el libro de Ingeniería del software de Pressman página 58. Estas métricas se derivan de una relación empírica según las medidas contables del dominio de información del software y de evaluaciones de complejidad. Ejemplo,

Número de entradas usuario – cada una de las entradas de datos.

Número de salidas usuario – cada una de las salidas de datos.

Número de peticiones usuario – cada generación de un evento.

Número de archivos – cada tabla, archivo, …

Número de interfaces externas – son interfaces, discos, copias de seguridad, transmisiones de datos.

Estas métricas poseen un modelo de valoración entre cero (0) y cinco (5), y por decisión del equipo de trabajo, se puede asumir una valoración en porcentajes como se muestra en la tabla siguiente así :

Esta valoración es usada para calificar 15 puntos de evaluación :

2. Facilidad de operación.

1. Valoración	Pregunta : ¿Se requiere de comunicación de datos?
   0	Aplicación es batch exclusivamente
   1 – 2	Impresión o entrada de datos remota
   3 – 5	Teleproceso (TP) interactivo
   3	TP interfaces a un proceso batch
   5	La aplicación es interactiva predominantemente

2. Comunicación de los datos. Los datos o información de control que la aplicación utiliza se envía o recibe a través de los facilidades de comunicación.

   Valoración	Pregunta : ¿Existen funciones de procesamiento distribuido?
   0	La aplicación no ayuda a la transferencia de datos o a la función de procesamiento entro los componentes del sistema.
   1	La aplicación prepara datos para el usuario final de otro procesador.
   2 – 4	Los datos se preparan para transferencia, se transfieren y se procesan en otro componente del sistema.
   5	Las funciones de procesamiento se realizan dinámicamente en el componente más apropiado del sistema.

3. Función distribuida. "Distribuida" significa que los componentes (o los datos) de la aplicación están distribuidos en dos o más procesadores diferentes (esto incrementa el factor anterior).

   Valoración	Pregunta : ¿Es crítico el rendimiento?
   0 – 3	Análisis y diseño de las consideraciones del rendimiento son estándar. No se precisan requerimientos especiales por parte del usuario.
   4	En la fase de diseño se incluyen tareas del análisis del rendimiento para cumplir los requerimiento del usuario.
   5	Además se utilizan herramientas de análisis del rendimiento en el diseño, desarrollo e instalación.

4. Rendimiento. Referido a la importancia de respuesta dentro de todo el sistema.

   Valoración	Pregunta : ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?
   0 – 3	La aplicación corre en una maquina estándar sin restricciones de operación.
   4	Restricciones de operación requieren características específicas de la aplicación en el procesador central.
   5	Además hay restricciones específicas a la aplicación en los componentes distribuidos del sistema.

5. Configuración utilizada masivamente. Referente a la importancia del entorno. Esto es, si hay restricciones de memoria o del hardware.

   Valoración	Pregunta :
   0 – 3	Las tasas son tales que las consideraciones de análisis de rendimiento son estándares.
   4	En la fase de diseño se incluyen tareas de análisis de rendimiento para verificar las altas tasas de transacciones.
   5	Además se utilizan herramientas de análisis del rendimiento.

6. Tasas de transacción. Una alta llegada de transacciones provoca problemas más allá de los de las características.

   Valoración	Pregunta : ¿Requiere el sistema entrada de datos interactiva?
   0 – 2	Hasta el 15% de las transacciones tienen entrada interactiva.
   3 – 4	15% al 30% tienen entrada interactiva.
   5	30% al 50% tienen entrada interactiva.

7. Entrada de datos On-line. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones?

   Valoración	Pregunta :
   0 – 3	No se especifican requerimientos especiales
   4	Se incluyen tareas de diseño para la consideración de factores humanos
   5	Además se utilizan herramientas especiales o de prototipado para promover la eficiencia.

8. Diseño para la eficiencia de usuario final.

   Valoración	Pregunta : ¿Se actualizan los archivos maestros de forma interactiva?
   0	Nada
   1 – 2	Actualización on-line de los archivos de control. El volumen de actualización es bajo y la recuperación fácil.
   3	Actualización on-line de la mayoría de los archivos internos lógicos.
   4	Además es esencial la protección contra la pérdida de datos.
   5	Además se considera el costo de recuperación de volúmenes elevados.

9. Actualización on-line.
10. Complejidad del procesamiento. Esto es, complejidad interna más allá de la media en lo referente a la entrada, salida o lógica de procesamiento. ¿Qué características tiene la aplicación?

• Mucho procesamiento matemático y lógico
• Procesamiento complejo de las entradas
• Procesamiento complejo de las salidas
• Muchas excepciones de procesamiento, muchas transacciones incompletas y mucho procesamiento de las transacciones.
• Procesamiento de seguridad y/o control sensitivo.

1. Utilizable en otras aplicaciones. El código se diseña para que sea compartido o utilizable por otras aplicaciones.

1. Valoración	Pregunta : ¿Están incluidas en el diseño la conversión y la instalación?
   0 – 1	No se requieren por parte del usuario facilidades especiales de conversión e instalación.
   2 – 3	Los requerimientos de conversión e instalación fueron descritos por el usuario y se proporcionaron guías de conversión e instalación.
   4 – 5	Además se proporcionaron y probaron herramientas de conversión e instalación.

2. Facilidad de instalación.

   Valoración	Pregunta : ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?
   0	El usuario no requiere la consideración de más de un puesto.
   1 – 3	Se incluyeron necesidades de varios puestos en el diseño.
   4 – 5	Se proporciona documentación y plan de apoyo para soportar la aplicación en varios lugares.

3. Puestos múltiples.
4. Facilidad de Cambio. Esfuerzo especifico de diseño para facilitar cambios futuros.

Estas valoraciones dadas a cada uno de estos puntos permiten aproximar una medida del sistema a través de la siguiente ecuación :

PF = Cuenta_total * [0,65 + 0,01*∑(Fi)], cuenta total es la valoración para cada uno de las preguntas, y la sumatoria representa el total generado por toda la valoración.

Métricas bang. Estas ayudan a evaluar el análisis y diseño, proporcionan medidas de la complejidad, y ayudan a diseñar pruebas más efectivas. Estas métricas se dividen en : Medidas del análisis, medidas de especificación, medidas de diseño.

• Medidas del software según el análisis, el propósito es evaluar el conjunto de primitivas, es decir los elementos más bajos del análisis que no se pueden subdividir más.
• • Primitivas funcionales (PFu) – Nivel inferior
  • Elementos de datos (ED) – Atributos de objetos
  • Objetos (OB) – Objetos de datos
  • Relaciones (RE) – Conexiones entre objetos de datos
  • Estados (ES) – Estados – Diagrama de transición
  • Transiciones (TR) – Número de transacciones – Diagrama de transición.
• Primitivas modificadas de función manual (PMFu), funciones externas que modifican para adaptarse al nuevo sistema.
• • Elementos de datos de entrada (EDE) – Introduce al sistema
  • Elementos de datos de salida (EDS) – Datos que saca el sistema
  • Elementos de datos retenidos (EDR) – Datos almacenados
  • Muestras (tokens) datos (TCi) – Elementos que existen en la línea X. token por primitiva. Símbolos léxicos diferentes visibles en cada primitiva.
  • Conexiones relación (REi) – conexiones entre objetos

Para este caso la pretensión es que el usuario plantee sus propias medidas con base en los elementos que se desea medir, ejemplo

TCavg = (∑ Tci) / Pfu, esta funcion determina el promedio de elementos individuales tokens existentes contra la cantidad de primitivas funcionales.

• Métricas de calidad de especificación, valoran y modelan los requisitos.

nr – número requisitos en una especificación

nf – número de requisitos funcionales

rnf – número de requisitos no funcionales (rendimiento)

Asociados a la ecuación nr = nf + rnf

Especificidad – Q1 = nui / nr, siendo nui son los requisitos donde coinciden las revisiones.

Complexión – Q2 = nu /(ni*ns) Este es el porcentaje de funciones necesarias con base en las especificaciones del sistema.

nu– requisitos funcionales únicos

ni – número de entradas

ns – número de estados especificados

Grado de validación – Q3 = nc / (nc + nnv)

nc – número de requisitos considerados validos

nnv – número de requisitos no validos

• Métricas de diseño
• • Complejidad estructural, S(i) = Fout 2 (i), siendo Fout(i) la expansión del módulo (i), definiendo expansión como la cantidad de módulos inmediatamente subordinados al módulo i, o como el número de módulos invocados por el módulo i.
  • Complejidad de los datos, D(i) = V(i) / [Fout(i) + 1], siendo V(i) el número de variables de entrada y salida del módulo (i).
  • Complejidad del sistema, C(i) = S(i) + D(i)

Métricas de punto de función de Albrecht. Miden la aplicación desde una perspectiva del usuario dejando de lado los detalles de codificación, estos evalúan con fiabilidad :

• El valor comercial de un sistema para el usuario
• Tamaño del proyecto, costo y tiempo de desarrollo
• Calidad y productividad del programados
• Esfuerzo de adaptación, modificación y mantenimiento
• Posibilidad de desarrollo propio
• Beneficios de implementación en 4GL

El proceso requiere dos etapas fundamentales :

2. Se identifican las funciones disponibles para el usuario y se organizan en cinco grupos así :

• Salidas
• Consultas
• Entradas
• Archivos
• Interfaces

1. Se ajusta este total de acuerdo con unas características del entorno.

A continuación se hace la explicación de los elementos que componen este tipo de valoración.

SALIDAS

Se debe contar cada dato único de usuario o salida de control generado proceduralmente y que sale del límite de la aplicación. Esto incluye informes y mensajes a otras aplicaciones y usuarios.

Una salida se considera única si :

1. Tiene formato diferente
2. Tiene el mismo formato que otra salida pero requiere diferente lógica de procesamiento.

Además de las pantallas y listados (papel o pantalla), también pueden ser salidas :

• Archivo de transacción enviado a otra aplicación
• Facturas
• Cheques
• Fichas perforadas
• Transacciones automáticas
• Mensajes al usuario
• Cintas
• Gráficos
• Archivos de Back-Up, entro otros.

No se deben considerar como salidas :

• Cabeceras de columnas, títulos, números de página
• Mensajes individuales (información, confirmación o respuestas a consultas de error)
• Salida en igual formato y lógica que ya se haya contado para otro soporte (procesos anidados).

ENTRADAS

Se debe contar cada dato único de usuario o entrada de control que se introduce en los límites de la aplicación y actualiza un archivo lógico interno, conjunto de datos, tabla o dato independiente. Esto incluye archivos de entrada y transacciones recibidas de otras aplicaciones.

Una entrada se considera única si :

1. Tiene un formato diferente
2. Tiene el mismo formato que otra entrada pero requiere una lógica diferente de procesamiento, o se modifica un archivo interno lógica diferente.

Sea el caso, se tienen dos pantallas de entrada, cada una con el mismo formato pero con diferente lógica de procesamiento. Se cuenta cada pantalla como una entrada diferente; pero si tuvieran la misma lógica sólo se contaría una. Lo mismo sucede con la repetición de pantallas.

Supóngase que existe una pantalla cuya función es actualizar un fichero o un conjunto de datos. Puesto que cada una de las tres funciones de actualización (Insertar, modificar, borrar) requiere diferente lógica de procesamiento se tienen tres entradas, no una. Cada archivo tendrá tres entradas, así como una salida (el archivo formateado de salida) y una consulta.

Los tipos de entrada pueden ser :

• El ratón
• Documentos
• Transacciones de cintas
• Pantallas sensitivas
• Lectores de código de barras, etc

CONSULTAS

Se debe contar cada combinación única de entrada/salida en la que la entrada on-line definida por el usuario genera una salida inmediata on-line. Las consultas se pueden proporcionar a o desde otra aplicación; por ejemplo, responder a otra aplicación que pregunta por el precio de un producto se contaría como una consulta.

Una consulta se considera única sí :

1. Tienen un formato diferente de otras, bien en su entrada o salida.
2. Tienen el mismo formato, tanto entrada como salida, que otra consulta, pero requiere diferente lógica de procesamiento en cualquiera de las dos.

Una consulta directa de una base de datos o archivo maestro es aquella que :

2. Utiliza claves simples para recuperar datos específicos – esto es , un registro simple o grupo de registros, no un rango –
3. Requiere respuesta inmediata
4. No realiza funciones de actualización (aunque se pueden efectuar calculos)

Las consultas pueden aparecer en :

• Consultas de usuario/pantalla sin actualización de archivos u otra entidad lógica.
• Archivos de transacción que salen del límite de la aplicación si está accesible al usuario on-line.
• Pantalla de selección de menú (todas las pantallas de menú cuentan como una consulta)
• Mensajes de información o pantallas de ayuda.

ARCHIVOS

Se debe contar cada grupo lógico mayor de datos de usuario o de información de control mantenidos dentro de los límites de la aplicación. Esta medición distingue entre dos tipos de archivos : Archivos con transacciones temporales y archivos con registros lógicos de datos permanentes. Sólo los almacenamientos de datos permanentes se ven como archivos lógicos. Cuando se mantienen dentro de la aplicación se clasifican como "Archivos internos lógicos". Si se comparten entre aplicaciones se clasifican como interfaces y como archivos internos lógicos.

Las transacciones por el contrario, se consideran que son sucesos que desencadenan cambios en los archivos lógicos internos; no se clasifican como archivos. Un archivo de transacción se puede clasificar como entrada si es leído para actualizar datos en un archivo lógico interno. Un archivo de transacción puede ser una interfaz o una salida si transfiere transacciones de actualización a otra aplicación.

Cuando se utiliza análisis estructurado cada almacén de datos contendrá al menos un archivo lógico interno. Hay que enfatizar que se habla de archivos lógicos. Supóngase que un archivo físico contienen dos llaves diferentes, entonces se contarían dos archivos lógicos internos, puesto que cada camino presenta diferente información. Del mismo modo, cada vista lógica del usuario en una base de datos se cuenta como un archivo.

Se pueden encontrar archivos en :

• Bases de datos : uno por cada vista lógica o camino de acceso
• Archivos maestros : uno por cada grupo de claves
• Tablas mantenidas por los usuarios : estados, tarifas, mensajes, etc.
• Archivos de procesamiento batch
• Índices de referencias cruzadas

INTERFACES

Se debe contar como uno cada archivo lógico de otro grupo de datos (o información de control) que se envía fuera de los límites de la aplicación, o se comparte o es recibido desde otra aplicación. Los archivos que se comparten entre aplicaciones se cuentan como archivos y como interfaces en cada aplicación en la que se utilizan; de otro modo sólo se indican como archivos en aquella aplicación que utilice o mantenga el archivo (la otra sólo recibirá puntos de interfaz). Esto es, cada archivo interfaz debe ser también un archivo lógico en esa aplicación, en otra o en ambas; o puede ser un archivo transacción o de impresión generado en la propia aplicación. Las interfaces presentan una de estas situaciones :

1. Datos o información de control se pasa del archivo A al archivo B. En A se indica como archivo e interfaz y en B sólo como interfaz.
2. Datos o información de control se pasa del archivo B a A. En b se indica como archivo e interfaz y en A sólo interfaz.
3. Datos o información de control se comparte entre A y B. A y B reciben puntos de archivo e interfaces.

Las interfaces habitualmente involucran archivos maestros, no transacciones. Hay diferencia entre archivos maestros lógicos y ficheros transacción. Si las aplicaciones se relacionan a través de transacciones entonces se indican entrada, salida, y/o consulta, y, quizá interfaz. Si lo hacen a través de archivos maestros entonces se indica interfaz, y, quizá archivo. Un archivo de transacción no se contará como interfaz si el formato con el que lo recibe el otro programa es el mismo (no hay conexión). El programa receptor lo contaría como entrada. Si el programa que lo envía realiza el trabajo de conversión entonces se contará (para éste) una salida y una interfaz.

Las interfaces se pueden encontrar en :

• Archivos lógicos internos accesibles desde otra aplicación
• Archivos lógicos internos accesibles en otra aplicación
• Bases de datos compartidas
• Lista de parámetros compartida
• Archivos de impresión exportados
• Archivos de transacción compartidos que requiere conversión

Se contarán como interfaz

• Archivo de registros de otra aplicación – en la otra aplicación (+1 archivo. +1 interfaz)

• Archivos de registro a otra aplicación (+1 archivo) (en la otra aplicación +1 interfaz)
• Archivos de registro a varias aplicaciones (+1 archivo) – afecta el peso de la complejidad.
• Archivo de registros compartido entre dos o más aplicaciones (+1 archivo) (para las otras aplicaciones : +1 interfaz + 1 archivo – en cada aplicación si realizan mantenimiento.
• Bases de datos compartidas con otras aplicaciones (+1 archivo) 1 interfaz por cada vista realmente enviada (para la otra aplicación: +1 archivo. +1 interfaz por cada vista utilizada)
• Bases de datos compartidas de otras aplicaciones (+1 archivo) 1 interfaz por cada vista utilizada (para la otra aplicación : +1 archivo, +1 interfaz por vista)
• Archivo de transacciones de otra aplicación con conversión de datos (+1 entrada)
• Archivo de transacción enviados a otra aplicación con concesión de datos (+1 salida). Los archivos de transacción sólo se cuentan en una aplicación (no en las dos).
• Lista de parámetros

Validación del proceso.

Esta característica se asocia con dos procesos asociados con el ciclo de vida del software llamados la implantación y control del sistema.

La implantación esta determinada en dos fases :

• Construcción del nuevo sistema
• La entrega del nuevo sistema

Estos elementos van relacionados con fases de construcción, entrega y los demás elementos del ciclo de vida. Todos en función de :

• Propósitos y objetivos
• Tareas y actividades a realizarse
• Secuencia y solapamiento de actividades
• Técnicas usadas
• Técnicas para completar las fases
• Manejo del tiempo invertido

El proceso de validación se define como la construcción del nuevo sistema y la entrega de dicho sistema a producción este.

Para alcanzar este propósito es necesaria la verificación y guía a través de cuatro fases, las cuales se aplican en el proceso de desarrollo las cuales poseen responsables del grupo de trabajo elegido para alcanzar el objetivo, estas son :

Cada una de estas fases esta compuesta por actividades, las cuales son llevadas a cabo por los responsables indicados en la tabla.

Fase 1. Construir y probar redes y bases de datos. Es esta fase es necesario se verifique la existencia de redes y bases de datos, en caso de estas estar implantadas y en funcionamiento este elemento no es tenido en cuenta; ésta afirmación es verdad en parte, ya que es necesario garantizar las condiciones del sistema, y que sea necesaria una actualización tanto de redes como de bases de datos, provocaría una modificación en los parámetros existentes.

• Actividad 1. Red. Es primordial determinar las necesidades y sus detalles. Es necesario : La validación de dispositivos, velocidad de transmisión, topología, diseño del sistema eléctrico, seguridad, respaldo, protocolos, medios de transmisión a utilizar.
• Actividad 2. Bases de datos. Es primordial determinar los esquemas y sus detalles (estructuras de archivos), tener en cuenta las características de los sistemas distribuidos. En este caso es necesario se determinen los elementos compartidos de mayor estabilidad en el sistema, estos son los datos, a los cuales es necesario verificarles : Equipos de hardware donde estará implantado, herramienta de software requerida, validación del sistema operativo, manejador de base de datos (SGDB), software de comunicaciones. En forma adicional de la base se verifican archivos lógicos y físicos, la producción de la base de datos, interfaces con otros sistemas o bases de datos, además de verificar los diccionarios de datos y flujos. Estos entre otros elementos que sean considerados con base en las necesidades y características del sistema.

Fase 2. Construir y probar programas. Los objetivos de esta fase son: Planear el desarrollo y pruebas del sistema, y desarrollar programas que respondan a las necesidades. Para esta fase se encuentran definidas dos actividades que se desprenden de la aplicación de métodos de análisis y diseño, y del uso de ciclos de vida.

• Actividad 1. Plan de programación. Es este se incluyen tres etapas, en las cuales se ve involucrada la toma de decisiones por parte del personal responsable es decir los programadores.
• • Etapa 1. Revisión del diseño. Al realizar esta actividad de garantía en el proceso de desarrollo, los diseñadores toman la decisión de congelar los diseños realizados, ya que con estos los programadores inician el trabajo de generación del código en lenguajes de programación, esta acción de congelar se hace para que no existan mejoras posteriores que obliguen a una retroalimentación del proceso y sea necesario extender los tiempos definidos en el cronograma.
  • Etapa 2. Organización del equipo de programación. Es importante recordar que los jefes de equipo no son estables, esto se presenta cuando existe suficiente personal. Ahora ¿qué ocurre cuando no existe suficiente personal en la organización?. Se plantean dos elementos importantes a ser evaluados : La existencia de suficiente personal permite que este sea distribuido según las necesidades y conocimientos; al no existir suficiente personal es necesario determinar las características del cronograma y como se resuelven las necesidades según el sistema a desarrollar.
  • Etapa 3. Plan de programación detallado. Es necesario sea asignado el personal, o se definan un cronograma adecuado. Para este caso es necesario se asuman políticas de trabajo como :
  • Uso de versiones del programa
  • Procesos o actividades en orden de importancia
  • Normas de programación (estándares)
  • Datos de prueba.
• Actividad 2. Escribir y probar programas. En esta actividad se determinan :
• • Componentes a ser reutilizables.
  • Documentación de los programas (Revisiones)
  • Recomendaciones y requisitos de calidad

En esta actividad se hace una revisión del ciclo de vida que se esta aplicando al problema, en los módulos de : Diseño de algoritmos, codificación y pruebas. Esta última se puede desarrollar bajo cualquiera de sus modalidades, entre algunas de ellas están :

• Individuales – programas, subrutinas, bloques, ..
• Unidades o programas – Módulos
• Sistema – Integración, donde la salida de unos es la entrada de otros.

Es importante no dejar de lado el uso de técnica de programación, como hashing, backtraking, entre otras.

Fase 3. Instalar y probar el nuevo sistema. Esta responsabilidad la cual recae sobre los programadores, encargados estos de determinar las características finales del sistema. A este grupo de trabajo, se le asignan cuatro actividades que permiten llevar a buen término ésta fase.

• Actividad 1. Instalación y prueba del sistema. Es necesario se haga el ejercicio mental, acerca de si la solución acerca del sistema de información fue desarrollado o comprado, esto ya que es necesaria la actualización de bibliotecas y documentación propias de la empresa que será la beneficiaría del sistema, además estas entregas deben estar dilucidadas en el contrato del desarrollo del proyecto, es importante que las especificaciones correspondan con un estándar el cual debe estar definido.
• Actividad 2. Integración. Este numeral aparece en dos casos : Las necesidades de integración y la documentación del programa. Es necesario se evalúen los posibles casos que se presentan, como existencia de sistemas anteriores, montaje y ejecución en maquinas de bajo desempeño, posibles casos de error y sus respuestas. En caso de ser comprado, validar la adaptación e integración a las necesidades de la empresa.
• Actividad 3. Prueba completa. El caso a ser verificado es la necesidad que el sistema funcione como un conjunto, a través de un grupo de datos de prueba seleccionados y determinados tanto en el diseño como en la codificación.
• Actividad 4. Conversión y entrega. En este caso es necesario se garantices las conversiones de bases de datos, archivos y todos los elementos físicos y lógicos de manejo de información, Generalmente este caso se presenta al convertir sistemas antiguos a nuevos.

Fase 4. Entregar el sistema para explotación. Este es el paso final donde se lleva el sistema a la organización y a los usuarios finales, es allí donde el sistema toma el tinte de usable. Esta responsabilidad entregada a los analista esta compuesta de cuatro actividades :

• Actividad 1. Instalar archivos y base de datos. Es necesario existan o se desarrollen las interfaces de conversión de archivos y bases de datos. Evaluando el tiempo de conversión y las necesidades de información de los puestos de trabajo.
• Actividad 2. Capacitación. Para este caso es necesario tener presente : Documentación apropiada, Manuales de usuario, Capacitación o formación del usuario final. Es importante recordar que el usuario final es un actor que se encuentra involucrado desde el inicio del desarrollo del proyecto, en cual el se sentirá comprometido con el proyecto y parte de él.

Recordar, al escribir documentación "es necesario escribir para los demás como si lo hubiese escrito otra persona para usted".

• Actividad 3. Conversión. Para este paso se plantean las siguientes estrategias :

• Actividad 4. Evaluación. En este punto se evalúa el proyecto y el proceso. Los elementos a evaluar son :
• • Cumplimiento de los objetivos iniciales
  • Que las transacciones e informes, ayuden a la toma de decisiones
  • Que sean claros los beneficios
  • Validez desde el punto de vista del usuario
  • Son requeridas mejoras inmediatas, en caso de ser positiva la respuesta estas mejoras se manejan por prioridades.
  • El sistema es auditable

Finalmente y como recomendación, para cualquier trabajo de desarrollo de sistemas que pretenda solucionar problemas de procesamiento y transmisión de datos e información, es necesario que estos sean desarrollados bajo las características técnicas y de aseguramiento de la calidad de entidades internacionales como ISO, IEEE, ITU.

A continuación se presenta un descripción de la norma ISO 9000-3 aplicada a desarrollos de sistemas de información. Tomado de http://campus.fortunecity.com/defiant/114/iso9000.htm#norma

Generalidades

Título – Normas de gestión de la calidad y garantía de la calidad

Parte 3 – Orientaciones para la aplicación de la Norma ISO 9001 al desarrollo, suministro y mantenimiento del software

Naturaleza – Norma internacional

Ámbito – Desarrollo de Sistemas de Información. Procesos del ciclo de vida. Calidad del software.

Campo de aplicación y alcance

Esta parte de la ISO 9000 contiene orientaciones que facilitan la aplicación de la Norma ISO 9001 a las organizaciones dedicadas al desarrollo, suministro y mantenimiento del software.

Se pretende con ella dar orientaciones en relación con situaciones en las que un contrato entre dos partes exija la demostración de la capacidad de determinado proveedor para desarrollar, suministrar y mantener productos de software.

Tales orientaciones describen las clases de control y los métodos sugeridos para la producción del software, que satisfagan los requisitos establecidos. Esto será posible principalmente a través de la prevención de "no-conforme" a lo largo de todas las fases del proceso, desde el desarrollo hasta el mantenimiento.

Estructura

• Sistema de la calidad – estructura.
• Responsabilidad de la gestión.
• Sistema de la calidad.
• Auditorías internas al sistema de la calidad.
• Acciones correctivas.
• Sistema de la calidad – actividades a lo largo del ciclo de vida.
• General.
• Análisis del contrato.
• Especificación de los requisitos del comprador.
• Planificación del desarrollo.
• Planificación de la calidad.
• Proyecto e implementación.
• Pruebas y validaciones.
• Aceptación.
• Reproducción, entrega e instalación
• Mantenimiento.
• Sistema de la calidad – actividades de apoyo (independientes de cualquier fase)
• Gestión de la configuración
• Control de documentos
• Registros de la calidad
• Medición
• Reglas, prácticas y convenciones
• Herramientas y técnicas
• Aprovisionamiento
• Productos de software incluidos

Conexión con otras normas

ISO 8402: 1994, Gestión y garantía de la calidad – vocabulario.

ISO 9001: 1987, Sistemas de la calidad – modelo de garantía de la calidad en el proyecto/ desarrollo, producción, instalación y post-venta.

ISO 10011-1: 1990, Líneas de orientación para auditorías de sistemas de la calidad – Parte 1: Auditorías.

ISO 8402: 1994, Gestión y garantía de la calidad – vocabulario.

ANÁLISIS DETALLADO

Desde que la ISO 9001 fue escrita para ser utilizada por toda clase de industrias, es regularmente difícil interpretarla para el desarrollo de software, por lo cual se publicó la ISO 9000-3 "Guía para la aplicación de ISO 9001 para el desarrollo, implementación y mantenimiento de software".

El objetivo de la ISO 9001 es construir un sistema de calidad el cual contenga la estructura de la organización, responsabilidades, procedimientos, procesos y recursos para implementar una dirección de calidad. Mientras que el de la ISO 9000-3 es proveer las especificaciones de cómo aplicar la ISO 9001 al desarrollo del software, implementación y mantenimiento. Se incluyen algunos temas que no se encuentran en las normas ISO 9000 genéricas, tales como Administración de la Configuración o Planeación de Proyectos. Sería poco probable lograr resultados de calidad en un proyecto de desarrollo software de tamaño mediano, sin haber tomado las provisiones necesarias para el control de configuración. Esto implica que para ciertos productos o servicios, la especificación de requerimientos contenida en las normas genéricas ISO 9000 no es suficiente para asegurar la calidad, y esto justifica la necesidad de otras normas o guías más específicas.

La norma ISO 9000-3 es requerida por todas las compañías desarrolladoras de software:

• Para poder incursionar en la competencia del mercado europeo.
• Como un medio para cubrir las expectativas de los clientes.
• Para obtener beneficios de calidad y ventajas competitivas en el mercado.
• Como parte de la estrategia del mercado.
• Estrategia para reducir los costos de producción

Dentro de los beneficios que se obtienen de la certificación ISO 9000-3, se encuentran:

• Mejor documentación de los sistemas.
• Cambio cultural positivo.
• Incremento en la eficiencia y productividad.
• Mayor percepción de calidad.
• Se amplía la satisfacción del cliente.
• Se reducen las auditorías de calidad de los clientes.
• Agiliza el tiempo de desarrollo de un sistema.

Secciones de la Norma ISO-9003

Responsabilidades de la dirección:

La dirección de la empresa debe definir y documentar su política y sus objetivos con respecto a la calidad. :la empresa debe asegurarse que esta política es conocida, entendida e implementada en todos los niveles de la organización.

Las responsabilidades, autoridades y relaciones entre todo personal, cuyo trabajo afecte la calidad del producto, deben ser definidas: particularmente de aquéllos quienes necesitan de la libertad organizacional y autoridad.

Sistemas de calidad:

La empresa debe establecer y mantener un sistema de calidad documentado (un manual interior como guía de operaciones del sistema de calidad) como medio de asegurar que los productos cumplen con los requerimientos especificados, y debe incluir:

• La preparación de procedimientos e instructivos del sistema de calidad de acuerdo con los requerimientos de esta especificación
• La aplicación efectiva de los procedimientos y de las instrucciones documentadas del sistema de calidad.

Revisión del contrato:

La empresa debe establecer y mantener procedimientos para la revisión de los contratos y para la coordinación de estas actividades. Cada contrato debe ser revisado por la empresa para asegurar que:

• Los requisitos están adecuadamente definidos y documentados
• Sean definidos los requerimientos diferentes de aquellos mencionados en la propuesta.
• La empresa tenga la capacidad de cumplir con todos los requerimientos contractuales.

Control de documentos y datos:

La empresa debe establecer y mantener procedimientos para controlar todos los documentos y datos que se relacionen con esta norma. Incluyendo documentos externos como especificaciones de clientes, etc. Este control debe asegurar que:

• Los documentos y su emisión correcta están disponibles en todo lugar pertinente.
• Los documentos obsoletos sean removidos rápidamente de los lugares de uso o emisión.

Productos provistos por el comprador:

La empresa debe establecer y mantener procedimientos para la verificación, almacén y mantenimiento de productos provistos por el comprador para ser incorporados al producto final. Cualquiera de estos productos que se pierda, dañe, o que sea no apto para usarse, debe ser reportado al proveedor.

Identificación y trazabilidad del producto:

Donde sea apropiado la empresa debe establecer y mantener procedimientos para identificar el producto desde la etapa de diseño hasta la entrega e instalación, pasando por todas las etapas de producción. Cuando la trazabilidad del producto sea un requisito especificado, los productos individuales o los, lotes deben tener una identificación única. Este identificador debe ser registrado.

Inspección y pruebas:

La empresa debe asegurar que los productos adquiridos no se utilicen o procesen hasta que sean inspeccionados o verificados que cumplen con los requerimientos específicos. Las verificaciones deben estar de acuerdo con el plan de calidad y los procedimientos documentados.

Cuando los productos son enviados a producción por situaciones de urgencia sin ser antes inspeccionados, éstos deben identificarse y registrarse para que en caso de no conformidad sean rápidamente reconocidos y reemplazados.

La empresa debe establecer o mantener registros que contengan el criterio de aceptación del producto.

Equipos de Inspección, medición y pruebas:

La empresa debe controlar, calibrar y mantener el equipo de inspección, medición y pruebas (sin importar si el equipo es propiedad de la empresa, rentado o si es provisto por el comprador) para verificar la conformidad del producto con los requerimientos especificados. El equipo debe ser usado de una manera que asegure que la incertidumbre de medición sea conocida y que esté dentro de la capacidad de medición requerida. La empresa debe:

• Precisar las mediciones a efectuar, con la exactitud requerida y además, seleccionar el equipo adecuado de inspección y pruebas.
• Identificar, calibrar y ajustar a intervalos definidos todo el equipo de inspección, medición y pruebas y los elementos que afectan la calidad del producto. Esta calibración se efectúa contra equipo certificado que tenga una relación con patrones internacionales. Cuando no exista esa norma o patrón, la base utilizada para la calibración deberá ser documentada.
• Establecer, documentar y mantener los procedimientos de calibración que incluyan detalles del equipo en cuanto tipo, identificación, número, ubicación, frecuencia de verificación, criterios de aceptación y las acciones a tomar cuando los resultados no sean satisfactorios.
• Asegurarse de que el equipo de inspección, medición y pruebas registra la exactitud, el error y la precisión requerida.
• Identificar al equipo de inspección, medición y pruebas con un indicador que muestre el status de la calibración del equipo.
• Mantener registros de calibración del equipo de inspección, medición y pruebas.
• Auditar y documentar la validez de los resultados de las inspecciones y pruebas cuando los equipos de medición, inspección y pruebas sean encontrados sin calibración.
• Asegurar los equipos de inspección, medición y pruebas para evitar ajustes que invaliden la calibración. Esto incluye a los programas computacionales de pruebas.

Estado de Inspección y pruebas:

El estado de inspección y pruebas del producto debe ser identificado mediante marcas, etiquetas autorizadas, sellos, rótulos, registros de inspección, programas computacionales de pruebas , localizaciones físicas, etc.

Estos elementos deben indicar la conformidad o no-conformidad del producto con respeto a las pruebas e inspecciones efectuadas. La identificación del estado y pruebas debe ser mantenida en el proceso de producción e instalación del producto para asegurar que sólo los que hayan pasado las pruebas e inspecciones requeridas sean entregados al cliente.

Control de producto no conforme:

La empresa debe mantener y controlar los procedimientos que aseguren que los productos que no cumplan los requerimientos especificados, no sean usados o instalados inadvertidamente. Se deben controlar las actividades de identificación, documentación, evaluación, segregación (cuando sea practico) y desecho de productos no-conformes, sin olvidar la notificación a las áreas y funciones interesados.

Acciones correctivas y preventivas:

La empresa debe establecer, documentar y mantener procedimientos para lo siguiente:

• Investigar la causa de no conformidad y las acciones correctivas necesarias para prevenir la recurrencia.
• Analizar todos los procesos, operaciones de trabajo, registros de calidad, reportes de servicios y reclamaciones de clientes para determinar y eliminar causas potenciales de productos no conformes.
• Iniciar sesiones de prevención para manejar problemas a un nivel acorde al riesgo encontrado.
• Aplicar controles para asegurar que las acciones correctivas sean tomadas y que sean efectivas.
• Implantar y registrar los cambios en los procedimientos que sean resultado de acciones correctivas.

Manejo, almacenaje, empaque, preservación y embarque:

La empresa debe establecer, documentar los procedimientos para el manejo, almacén, empaque y embargue de los productos.

La empresa debe proveer métodos y medios para prevenir daños y deteriorización durante el manejo, almacén, empaque y embargue de los productos.

La empresa debe proveer áreas de almacén seguras para prevenir daños de los productos que estén pendientes de usarse o de entregarse. Se deben definir métodos apropiados para automatizar la recepción y la entrega de y hacia esas áreas. Se debe revisar periódicamente las condiciones del producto.

La empresa debe controlar el empaque, la conservación y el marcado hasta el grado necesario para asegurar que el producto cumpla con los requisitos especificados. Se debe identificar conservar y mantener todo el producto desde el recibo hasta que la responsabilidad de la empresa termine.

Control de registros de calidad:

La empresa debe establecer y mantener procedimientos para identificar, recolectar, indexar, llenar, archivar y desechar los registros de calidad Todos los registros deben ser legibles e identificables con el producto del que se trate. El tiempo que deberán mantenerse esos registros debe ser definidos y registrados.

Auditorias internas de calidad:

La empresa debe llevar un sistema de auditorias internas de calidad, planeado y documentado, para verificar que las actividades de calidad cumplan con lo planeado y que determine la efectividad del sistema de calidad. Las auditorias deben programarse de acuerdo con la importancia de la actividad. La auditoria y el seguimiento deben llevarse a cabo de acuerdo a los procedimientos documentados. El resultado de las auditorias debe ser documentado y mostrado al personal que tenga responsabilidad en el área auditada. El personal administrador responsable del área debe tomar acciones correctivas sobre las deficiencias encontradas por la auditoría.

Capacitación:

La empresa debe establecer y mantener procedimientos para identificar las necesidades de capacitación y proveer entrenamiento a todo el personal que realice tareas especificas debe ser calificado con base en su educación, entrenamiento y/o experiencia, Se deben mantener registros apropiados de capacitación.

Técnicas estadísticas:

Cuando sea apropiado, la empresa debe establecer los procedimientos para identificar técnicas estadísticas adecuadas, requeridas para verificar la capacidad de proceso y características del producto

BIBLIOGRAFÍA

ALBA CASTRO, Mauricio Fernando. Calidad en la producción de software. En : Calidad de Software. Primer Congreso Nacional de Estudiantes de Ingeniería de Sistemas. Universidad de Manizales. Mayo 1992.

BOOCH, Grady. Object Oriented Design with Applications. Prentice Hall. 1991.

COAD, Peter y YOURDON, Edward. Object Oriented Analysis. Prentice Hall. 1990.

DUNN, Robert. Software Quality. Prentice Hall. 1990. Cap 1.

CROSBY, Philip. Quality is Free. McGraw Hill. 1979.

HUMPHREY, Watts S. A discipline for software engineering. 1.999.

MCGARRY, John. Practical Software Measurement. Addisson Wesley. 2001.

MEYER, Bertrand. Object Oriented Software Constructions. Englewood Cliffs, Prentice Hall. 1998.

PRESSMAN, Roger S. Ingeniería del Software, Un enfoque practico. Tercera edición. McGraw Hill Cap 12.

VILLALOBOS, Jorge. La programación orientada por objetos : El paradigma del futuro. En Revista : Sistemas N. 48. 1991.

Juan Pablo Giraldo Rendón

Ingeniero de Sistemas

UNIVERSIDAD DE MANIZALES