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