Normas y estándares aplicables a proyectos de TIproyectos de TI
L.I. José Raymundo Ceja Vázquez
Introducción
• Las empresas que desarrollan software no pueden ignorarque su negocio es un negocio de software, y que el modeloque cada una adopte para las actividades de desarrollo ymantenimiento tiene implicaciones relevantes en la eficienciageneral 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– 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
deseadas por el usuario, y se suelen olvidar otrasimportantes (por ejemplo, mantenimiento)
• difícil especificar detalladamente y de forma medible
“Somos lo que hacemos de forma repetitiva. Laexcelencia, entonces, no es un acto, sino un hábito.”“Somos lo que hacemos de forma repetitiva. Laexcelencia, entonces, no es un acto, sino un hábito.”
• difícil especificar detalladamente y de forma medibleciertas características de calidad (facilidad de uso,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,...)
AristótelesAristóteles
Introducción
• Administradores: administración de la calidad
– responsabilidad de asegurar el nivel de calidad requeridoen los productos
– definición de procedimientos y estándares y asegurar sucumplimiento
– implantar una “cultura de la calidad”: motivación de cadapersona responsable del desarrollo para lograr un altonivel de calidad del producto
Introducción
Administración de la calidad• aseguramiento de la calidad
– establecimiento de un marco de trabajo deprocedimientos y estándares corporativosque conduzcan a la obtención de softwarede alta calidad
• planificación de la calidad
Aseguramiento de la calidad
• planificación de la calidad– selección de procedimientos y estándares
adecuados a partir de ese marco de trabajoy adaptación de éstos para un proyecto desoftware específico
• control de la calidad– definición y aplicación de los procesos que
aseguren que los procedimientos yestándares son seguidos por el equipo dedesarrollo
Planificación de la calidad
Control de la calidad
Administración de la calidad
• Permite comprobación independiente de los procesos de desarrollo
• Los productos resultantes de los procesos se introducen en elproceso de administración de la calidad para asegurar suconsistencia con estándares y objetivos de calidadconsistencia con estándares y objetivos de calidad
• El equipo de aseguramiento y control: independientes de losequipos de desarrollo
– responsabilidad de la administración de la calidad
– visión objetiva del proceso
– informan de problemas y dificultades a los administradoresprincipales 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 alproceso de desarrollo o a los productos de software
• Importancia de los estándares– ofrecen un conjunto de las mejores prácticas, evitando
repetir errores anteriores y capturando el conocimientode valor para la organización
– ofrecen un marco de trabajo alrededor del que se
Aseguramiento de la calidad
– ofrecen un marco de trabajo alrededor del que seimplementa el proceso de SQA
– ayudan a la continuidad del trabajo de unos ingenierosa otros
• Desarrollo de estándares– proceso largo y complicado– 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ándaresnacionales e internacionales
Planificación de la calidad
Control de la calidad
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 requerimientos
Sometimiento de documentos a revisiones
Formato del encabezado del procedimiento Proceso de entrega de las versiones
Estilo de programación en JavaProceso de aprobación del plan del
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
Crear borrador inicial
Rehacer
borrador
Rehacer documento borrador
Incorporar
la revisión
Incorporar comentarios a la revisión
Revisar borrador
Etapa 1: creaciónDocumento aprobado
Proceso formal de producción de un documento
Comprobar borrador final
Producir borrador final
Corregir texto
Producir
impresión
Producir patrones de impresión
Revisar arreglosArreglar texto Imprimir copias
Etapa 2: refinamiento
Etapa 3: producción
Documento aprobado
SQA: estándares de documentación
• estándares de identificación de documentos: cada documento debe identificarse deforma única
– documentos formales: identificador formal definido por el administrador de laconfiguración
– documentos informales: identificador definido por el administrador del proyecto
• estándares de la estructura del documento: secciones, numeración de páginas,• 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 ynombres de la compañía, utilización del color,...
• estándares para actualizar los documentos: utilización de una forma consistente paraindicar los cambios en el documento (colores en la portada para indicar nuevasversiones, utilización de los márgenes para indicar párrafos modificados o agregados,...)
Ejemplo: estructura de documento
Documento de Requerimientos de Usuario1. Introducción
a) Objetivo del documentob) Ámbito del softwarec) Definiciones, acrónimos y abreviacionesd) Referenciase) Resumen del documento
2. Descripción general2. Descripción generala) Perspectiva del productob) Capacidades generalesc) Restricciones generalesd) Características de usuarioe) Entorno operativof) Supuestos y dependencias
3. Requerimientos específicosa) Requerimientos de capacidadb) Requerimientos de restricciones
Ejemplo: plantilla de formulario
SOFTWARE CHANGE REQUEST SCR NODATEORIGINATORRELATED 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)
DOCUMENT CHANGE RECORD DCR NO
DATE
ORIGINATOR
APPROVED BY
1. DOCUMENT TITLE:
2. DOCUMENT REFERENCE NUMBER:
Ejemplo: plantilla de formulario
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 decalidad ajustándose al plan de calidad
• dos enfoques complementarios
– revisiones técnicas: el software, documentacióny procesos son revisados por un grupo de
Aseguramiento de la calidad
y procesos son revisados por un grupo depersonas
– valoración: normalmente automática, con algúntipo de herramienta
• el software y los documentos se procesan yse comparan con los estándares que seaplican a ese proyecto
• implica una medida cuantitativa de dealgunos atributos del software (medición ymétricas)
Planificación de la calidad
Control de la calidad
Control de calidad: revisiones técnicas formales
Poca gente, preparación y duración breves
Se revisa UN producto (especificación, módulo, listado,...)
Decisión final:- Aceptación- Rechazo- Aceptación condicionada a pequeñas
modificaciones
Participantes: jefe de revisión, revisores (ingenieros,programadores,...) y productor
Revisiones técnicas formales• Objetivos:
� Descubrir errores en la función, lógica o implementación de cualquier representacióndel software
� Verificar el cumplimiento de los requisitos� 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 permitanbuenos diseños, diseños que permitan implementaciones sencillas, estrategias depruebas que faciliten éstas,...)
Revisiones técnicas formalesRTFs: son un filtro que permite “purificar” las actividades de ingeniería de
software:
– se aplican en diversos momentos del desarrollo para detectardefectos.
– 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 encontrados
NúmeroCoste unitario
Total
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
• Directrices de la revisión:
– Revisión del producto, no delproductor
DOCUMENTOS GENERADOS
LISTA DE SUCESOS DE REVISIÓN
INFORME SUMARIO DE REVISIÓN
Comprobaciones en la revisión
Análisis: seguimiento de requisitos delsistema, consistencia y corrección de larepresentación.– Fijar una agenda y mantenerla
– Limitación del debate eimpugnaciones
– No se resuelve el problema, sólo seidentifica
– Limitar el número de participantes
– Desarrollar una lista decomprobaciones
– Destinar recursos y agenda para lasRTF en la planificación
– Entrenamiento de los revisores
– Repaso de revisiones anteriores
representación.
Diseño: revisión de la arquitectura einspección del diseño procedimental
Codificación: traducción correcta del diseñoal código, errores mecanográficos,estándares de codificación, comentarios,...
Prueba: validación del plan o procedimientode prueba que se haya establecido
Mantenimiento: consideración de lasconsecuencias del cambio, documentacióndel mismo, aceptación final del cambio
Ejemplo de informe sumarioIdentificación de la revisiónProyecto: Controlador del CM en tiempo real Número revisión: D-004Fecha: 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 movimientoProductor: Juan PérezBreve 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, MOVIMZ2. Codificación de los módulos2. Codificación de los módulos
Equipo de revisión
Nombre Firma1. 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 sucesosNúmero revisión: D-004Fecha: 11/07/95Jefe 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 dediseño. Se debe establecer explícitamente el propósito del módulo y se debe especificar ladeclaració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 lo2. El contador de bucle para la interpolación de los ejes X, Y, Z se incrementa una vez más de lonecesario para el control de paso del motor. El equipo de revisión recomienda otra comprobaciónde las especificaciones de paso del motor y la corrección (como sea preciso) del contador debucle.
3. Error de tipo en la referencia a la posición actual en X, X.POSICIÓN, en los módulos MOVIMX yMOVIMZ.
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 ampliadapara 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 lasmodificaciones y analizará el posible impacto antes de implementar los cambios.
Control de calidad: métricas
Mantenibilidad
Fiabilidad
Número de parámetros del procedimiento
Complejidad ciclomática
Tamaño del programa
Proceso desoftware
Proceso desoftware
Producto desoftwareProducto desoftware
Métricas deMétricas deMétricas deMétricas deFiabilidad
Portabilidad
Usabilidad
Tamaño del programa en líneas de código
Número de mensajes de error
Número de mensajes de error
Extensión del manual de usuario
Métricas depredicciónMétricas depredicción
Métricas decontrol
Métricas decontrol
Decisionesadministrativas
Decisionesadministrativas
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 esun 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 delSoftware– 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 procesosevaluados).
– objetivo: definir un marco común de referencia en el que convivanel resto de los modelos mencionados.
– Produce un perfil del proceso, en vez de un resultado válido/noválido
PREGUNTAS