04_Normas y Est and Ares de Proyectos de TI

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


– 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



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,...)


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


• 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


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)



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


• 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


• 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

04_Normas y Est and Ares de Proyectos de TI

Documents

Transcript of 04_Normas y Est and Ares de Proyectos de TI