Normas y estándares aplicables a

proyectos de TI
L.I. José Raymundo Ceja Vázquez
 Introducción
• Las empresas que desarrollan software no pueden ignorar
que su negocio es un negocio de software, y que el modelo
que cada una adopte para las actividades de desarrollo y
mantenimiento tiene implicaciones relevantes en la eficiencia
general del negocio.
 Introducción
• Posibles problemas al implantar métodos más eficientes:

– El tener poca experiencia

– Desorientación al seleccionar modelo de calidad
– Elegir el proceso más adecuado
– Realizar técnicas de trabajo
 Introducción
• Calidad del software: concepto complejo
– el producto desarrollado cumple su especificación:
criterio insuficiente
• la especificación se centra en las características
“Somos lo queporhacemos
deseadas de yforma
el usuario, repetitiva.
se suelen olvidar La
otras
importantes
excelencia, (porno
entonces, ejemplo, mantenimiento)
es un acto, sino un hábito.”
• difícil especificar detalladamente y de forma medible
ciertas características de calidad (facilidad de uso,
Aristóteles
mantenimiento,...)
• cuando la especificación del software es incompleta,
el usuario percibe falta de calidad

– diferentes atributos de la calidad (mantenibilidad,

eficiencia, portabilidad, rendimiento, fiabilidad,...)
 Introducción
• Administradores: administración de la calidad

– responsabilidad de asegurar el nivel de calidad requerido

en los productos

– definición de procedimientos y estándares y asegurar su

cumplimiento

– implantar una “cultura de la calidad”: motivación de cada

persona responsable del desarrollo para lograr un alto
nivel de calidad del producto
Introducción
 Administración de la calidad
• aseguramiento de la calidad
– establecimiento de un marco de trabajo de
procedimientos y estándares corporativos
Aseguramiento de la
calidad
que conduzcan a la obtención de software
de alta calidad

• planificación de la calidad
Planificación de la
calidad
– selección de procedimientos y estándares
adecuados a partir de ese marco de trabajo
y adaptación de éstos para un proyecto de
software específico

Control de la calidad • control de la calidad

– definición y aplicación de los procesos que
aseguren que los procedimientos y
estándares son seguidos por el equipo de
desarrollo
 Administración de la calidad
• Permite comprobación independiente de los procesos de desarrollo

• Los productos resultantes de los procesos se introducen en el

proceso de administración de la calidad para asegurar su
consistencia con estándares y objetivos de calidad

• El equipo de aseguramiento y control: independientes de los

equipos de desarrollo
– responsabilidad de la administración de la calidad
– visión objetiva del proceso
– informan de problemas y dificultades a los administradores
principales de la organización
Aseguramiento de la calidad y estándares
• Actividades de aseguramiento de la calidad (SQA)
– definir un marco de trabajo para lograr la calidad del
software: definir o seleccionar estándares aplicables al
proceso de desarrollo o a los productos de software
Aseguramiento de la
calidad
• Importancia de los estándares
– ofrecen un conjunto de las mejores prácticas, evitando
repetir errores anteriores y capturando el conocimiento
de valor para la organización
Planificación de la – ofrecen un marco de trabajo alrededor del que se
calidad implementa el proceso de SQA
– ayudan a la continuidad del trabajo de unos ingenieros
a otros

• Desarrollo de estándares
– proceso largo y complicado
Control de la calidad
– organizaciones nacionales e internacionales diferentes
(ANSI, IEEE, OTAN, Agencia Espacial, NASA,
Departamento de Defensa de EE.UU., ...)
– los equipos de SQA de las empresas desarrollan un
“manual de estándares” basado en estándares
nacionales e internacionales
 SQA: estándares
Estándares del producto Estándares del proceso

Formulario para revisión del diseño Conducto para la revisión del diseño

Estructura del documento de

Sometimiento de documentos a revisiones
requerimientos

Formato del encabezado del procedimiento Proceso de entrega de las versiones

Proceso de aprobación del plan del

Estilo de programación en Java
proyecto

Formato del plan del proyecto Proceso de control del cambio

Forma de petición de cambios Proceso de registro de las pruebas

 SQA: estándares de documentación
• Importancia de los documentos estandarizados
– documentos: única forma tangible de representar el software y el proceso del software
– documentos estandarizados: apariencia, estructura y calidad consistentes; más fáciles de
leer y comprender

• Tipos de estándares
– estándares del proceso de documentación:
• proceso a seguir para la producción del documento
• documentos de trabajo: no es necesario aplicar procesos formales de calidad
• documentos formales (para desarrollos posteriores o a entregar al cliente):
necesario adoptar un proceso formal de calidad

– estándares del documento:

• estructura y presentación de los documentos
• deben tener un estilo y apariencia consistente, y los del mismo tipo deben tener
una estructura consistente con los del proyecto y la organización

– estándares para el intercambio de documentos:

• aseguran que todas las copias electrónicas de los documentos sean compatibles
• utilización de herramientas concretas para elaborar los documentos (hojas de
cálculo, procesadores de texto, herramientas de diagramación,...)
 SQA: estándares de documentación
Proceso formal de producción de un documento

Incorporar Rehacer
Crear borrador Revisar
comentarios a documento
inicial borrador
la revisión borrador
Etapa 1: creación
Documento aprobado

Producir Comprobar
Corregir texto
borrador final borrador final

Etapa 2: refinamiento

Documento aprobado
Producir
Arreglar texto Revisar arreglos patrones de Imprimir copias
impresión

Etapa 3: producción
 SQA: estándares de documentación
• estándares de identificación de documentos: cada documento debe identificarse de
forma única
– documentos formales: identificador formal definido por el administrador de la
configuración
– documentos informales: identificador definido por el administrador del proyecto

• estándares de la estructura del documento: secciones, numeración de páginas,

encabezados, información de pies de página, numeración de secciones,...

• estándares de presentación de documentos: tipos de letra y estilos, logotipos y

nombres de la compañía, utilización del color,...

• estándares para actualizar los documentos: utilización de una forma consistente para
indicar los cambios en el documento (colores en la portada para indicar nuevas
versiones, utilización de los márgenes para indicar párrafos modificados o agregados,...)
 Ejemplo: estructura de documento
Documento de Requerimientos de Usuario
1. Introducción
a) Objetivo del documento
b) Ámbito del software
c) Definiciones, acrónimos y abreviaciones
d) Referencias
e) Resumen del documento

2. Descripción general
a) Perspectiva del producto
b) Capacidades generales
c) Restricciones generales
d) Características de usuario
e) Entorno operativo
f) Supuestos y dependencias

3. Requerimientos específicos
a) Requerimientos de capacidad
b) Requerimientos de restricciones
 Ejemplo: plantilla de formulario
SOFTWARE CHANGE REQUEST SCR NO
DATE
ORIGINATOR
RELATED SPRs

1. SOFTWARE ITEM TITLE:

2. SOFTWARE ITEM VERSION/RELEASE NUMBER

3. PRIORITY: CRITICAL / URGENT / ROUTINE (underline choice)

4. CHANGES REQUIRED:

5. RESPONSIBLE STAFF:

6. ESTIMATED START DATE, END DATE AND MANPOWER EFFORT

7. ATTACHMENTS:

8. REVIEW DECISION: CLOSE / UPDATE / ACTION / REJECT (underline choice)

 Ejemplo: plantilla de formulario

DOCUMENT CHANGE RECORD DCR NO

DATE

ORIGINATOR

APPROVED BY

1. DOCUMENT TITLE:
2. DOCUMENT REFERENCE NUMBER:
3. DOCUMENT ISSUE/REVISION NUMBER:
4. PAGE 5. PARAGRAPH 6. REASON FOR CHANGE
 Calidad del proceso y del producto
• mejora de la calidad:
1. identificar productos de calidad
2. examinar el proceso utilizado para desarrollarlos
3. generalizar esos procesos para aplicarlos a otros proyectos

• fabricación: relación clara entre calidad de proceso y del producto

– proceso fácil de estandarizar y supervisar
– una vez definido el proceso de fabricación se ejecuta una y otra vez para producir el
mismo producto con el mismo nivel de calidad

• software: existe relación, pero menos directa

– proceso más creativo que mecánico: influencia de habilidades individuales y
experiencia
– factores externos (novedad de la aplicación, presión comercial,...)
– el proceso puede ser inapropiado para un tipo de software
• por ejemplo, un estándar puede indicar que la especificación tiene que estar
terminada y aprobada para implementar, pero puede hacer falta realizar
prototipos.
 Control de la calidad
• vigilar el proceso de desarrollo para asegurar que se
siguen los procedimientos de SQA y estándares de
calidad ajustándose al plan de calidad
Aseguramiento de
la calidad • dos enfoques complementarios
– revisiones técnicas: el software, documentación
y procesos son revisados por un grupo de
Planificación de la personas
calidad
– valoración: normalmente automática, con algún
tipo de herramienta
• el software y los documentos se procesan y
Control de la
calidad
se comparan con los estándares que se
aplican a ese proyecto
• implica una medida cuantitativa de de
algunos atributos del software (medición y
métricas)
Control de calidad: revisiones técnicas formales

Se revisa UN producto
(especificación, módulo, listado,...) Poca gente, preparación y
duración breves

Decisión final: Participantes: jefe de revisión, revisores

- Aceptación (ingenieros,programadores,...) y productor
- Rechazo
- Aceptación condicionada a pequeñas
modificaciones
 Revisiones técnicas formales
• Objetivos:

Descubrir errores en la función, lógica o implementación de cualquier representación

del software

Verificar el cumplimiento de los requisitos

Garantizar el cumplimiento de los estándares

Conseguir un desarrollo uniforme del software

Obtener proyectos que hagan más sencillo los trabajos técnicos (análisis que permitan
buenos diseños, diseños que permitan implementaciones sencillas, estrategias de
pruebas que faciliten éstas,...)
 Revisiones técnicas formales
RTFs: son un filtro que permite “purificar” las actividades de ingeniería de
software:
– se aplican en diversos momentos del desarrollo para detectar
defectos.
– diseño: entre el 50 y el 60% de los errores del desarrollo.
– aprovecha la diversidad de un grupo de personas para:
• señalar la necesidad de mejoras en el producto de ingeniería
(diagramas del análisis, diccionario de datos, diseño, código,
estrategia de pruebas,...)
• confirmar las partes en las que no es necesaria una mejora.
• conseguir un trabajo técnico de calidad más uniforme.
– efectividad: se calcula que son efectivas en un 75%
Revisiones técnicas formales
Errores Coste
Número Total
encontrados unitario
Llevando a cabo revisiones
Durante el diseño 22 1,5 33
Antes de la prueba 36 6,5 234
Durante la prueba 15 15,0 315

Tras la distribución 3 67,0 201

783
Sin revisiones
Antes de la prueba 22 6,5 143
Durante la prueba 82 15,0 1230
Tras la distribución 12 67,0 804
2177
 Revisiones técnicas formales
DOCUMENTOS GENERADOS
LISTA DE SUCESOS DE REVISIÓN
INFORME SUMARIO DE REVISIÓN

• Directrices de la revisión: Comprobaciones en la revisión

– Revisión del producto, no del Análisis: seguimiento de requisitos del
productor sistema, consistencia y corrección de la
– Fijar una agenda y mantenerla representación.
– Limitación del debate e Diseño: revisión de la arquitectura e
impugnaciones inspección del diseño procedimental
– No se resuelve el problema, sólo se Codificación: traducción correcta del diseño
identifica al código, errores mecanográficos,
– Limitar el número de participantes estándares de codificación, comentarios,...
– Desarrollar una lista de Prueba: validación del plan o procedimiento
comprobaciones de prueba que se haya establecido
– Destinar recursos y agenda para las Mantenimiento: consideración de las
RTF en la planificación consecuencias del cambio, documentación
– Entrenamiento de los revisores del mismo, aceptación final del cambio
– Repaso de revisiones anteriores
Ejemplo de informe sumario
Identificación de la revisión
Proyecto: Controlador del CM en tiempo real Número revisión: D-004
Fecha: 11/07/95 Lugar: Edif. 4, Desp. 3 Hora: 10:00AM

Identificación del producto

Material revisado: Diseño detallado. Módulos de control de movimiento

Productor: Juan Pérez
Breve descripción: tres módulos para el control de movimiento en los ejes x, y,z

Material revisado:

1. Descripciones del diseño procedimental: módulos MOVIMX, MOVIMY, MOVIMZ

2. Codificación de los módulos

Equipo de revisión

Nombre Firma
1. M. Pérez Pérez _______________
2. J. García Conde _______________
3. E. Sánchez _______________

Aprobación del producto

Aceptado: como está ( ) con modificaciones menores ( x)

No aceptado: revisión principal ( ) revisión secundaria ( )
Revisión no terminada (explicación a continuación)

Material adicional adjuntado

Lista de sucesos (X) Materiales de producción anotados (X)

Otros (especificar)
Ejemplo de lista de sucesos
Número revisión: D-004
Fecha: 11/07/95
Jefe de revisión: M. Pérez Pérez

Lista de sucesos

1. Los prólogos de los módulos MOVIMX, MOVIMZ no son consistentes con los estándares de
diseño. Se debe establecer explícitamente el propósito del módulo y se debe especificar la
declaración de los elementos de datos.

2. El contador de bucle para la interpolación de los ejes X, Y, Z se incrementa una vez más de lo
necesario para el control de paso del motor. El equipo de revisión recomienda otra comprobación
de las especificaciones de paso del motor y la corrección (como sea preciso) del contador de
bucle.

3. Error de tipo en la referencia a la posición actual en X, X.POSICIÓN, en los módulos MOVIMX y

MOVIMZ.

4. Se debe ampliar una sentencia de seudocódigo. La sentencia “converger a posición de control

adecuada como en MOVIMX” contenida en los módulos MOVIMY y MOVIMZ debe ser ampliada
para los controles específicos de movimiento en Y y Z.

5. El equipo de revisión recomienda una modificación del algoritmo de “comparación de posición”

para mejorar el rendimiento en tiempo de ejecución. El diseñador tiene sus reservas sobre las
modificaciones y analizará el posible impacto antes de implementar los cambios.
 Control de calidad: métricas

Número de parámetros
del procedimiento
Proceso de Producto de
Mantenibilidad Complejidad software software
ciclomática
Fiabilidad Métricas de Métricas de
Tamaño del programa
control predicción
Portabilidad en líneas de código
Usabilidad Número de mensajes Decisiones
de error administrativas
Extensión del manual
de usuario
 Modelos de calidad del software

• Objetivo: mejora de procesos software

• Diversos modelos que buscan:

– Determinar las fuerzas y debilidades en una organización

– Reunir esfuerzos para conseguir acuerdos sobre lo que es

un buen proceso
 Modelos de calidad del software
• ISO 9001 y 9000-3:
– muy útil en compañías que además de software fabrican equipos
– define los procesos de calidad tanto en compañías de hardware
como de software
– muy utilizado en Europa

• Capability Maturity Model (CMM) del Instituto de Ingeniería del

Software
– el modelo más empleado y maduro
– valora el desarrollo de software en sistemas de gran complejidad
– visión completa del proceso de madurez organizacional
– incluye mecanismos para mejora continua de los procesos
 Modelos de calidad del software
• Bootstrap:
– enfocado a pequeñas y medianas empresas
– valora la madurez global de una organización
– examina procesos individuales de software y valora la
conveniencia y el impacto de nuevas tecnologías

• SPICE:
– combina elementos de ISO, CMM y Bootstrap
– enfocado a estudiar el nivel de madurez de los procesos
individuales (tiene en cuenta el contexto de los procesos
evaluados).
– objetivo: definir un marco común de referencia en el que convivan
el resto de los modelos mencionados.
– Produce un perfil del proceso, en vez de un resultado válido/no
válido
PREGUNTAS