Aseguramiento de la Calidad del Software M.C. Juan Carlos Olivares Rojas [email protected]...

Aseguramiento de la Calidad del SoftwareM.C. Juan Carlos Olivares Rojas

[email protected]://antares.itmorelia.edu.mx/~jcolivar/

@jcolivares

Enero 2010

mailto:[email protected]

http://antares.itmorelia.edu.mx/~jcolivar/

• Comprende la importancia de la calidad y su aseguramiento en el desarrollo de software.

• Genéricas

• Instrumentales: Capacidad de análisis y síntesis, Solución de problemas, Toma de decisiones.

Competencias

• Interpersonales: Capacidad de trabajar en equipo interdisciplinario, Compromiso ético.

• Sistémicas: Capacidad de aplicar los conocimientos en la práctica, Habilidades de investigación, Capacidad de generar nuevas ideas (creatividad), Liderazgo, Capacidad para diseñar y gestionar proyectos, Iniciativa y espíritu emprendedor, Preocupación por la calidad, Búsqueda del logro.

Competencias

• Conceptos básicos.

• Relación de la Ing. de Software con SQA.

• Definición y propósito del SQA.

• Problemas que resuelve la SQA.

• Calidad del software en el ciclo de vida del mismo.

Temario

• Roles y responsabilidades de los equipos de desarrollo.

• Habilidades y capacidades del personal del SQA.

• Actividades del SQA.

• Métodos y herramientas.

Temario

• Definición propia de Calidad 5%

• Catálogo de empresas que han implementado controles de calidad en sus procesos de desarrollo de software. 5%

• Documento escrito con la descripción del puesto de SQA. 10%

• Análisis FODA de los procesos de desarrollo de software de una empresa. 10%

Evidencias

• Hoja de control de calidad estadístico con las variables de Líneas de Código, Errores y Tiempo de Codificación en el desarrollo de un software específico. 10%

• Otras actividades 10%

• Actividad Evaluadora Parcial 50%

Evidencias

• E1: Víctor Hernández y David Sandoval: Proyecto Mitecua

• E2: Dante Solorio y Huber Duarte, Proyecto “Interprendedor”

• E3: María Guadalupe Orozco, Módulo de Tutores

• E4: Jose Cid y Jose García: Sistema de Control y Registro de Incidencias.

Equipos

• E5: Carlos Fabié Equipos

• ¿Qué tiene más calidad?

Los dos tienen la misma

calidad siempre y cuando

cumplan con sus

requerimientos

Para ello debemos

probar sus especificacione

s

Conceptos básicos• Los errores del software le salen muy caros a Estados Unidos: 59 500 millones de dólares al año.

• 50% de los fallos corresponde a los usuarios el resto a los programadores y vendedores.

• Las pruebas al inicio del ciclo reducirían los costos por fallos en 22 200 millones de dólares.

Introducción

Calidad del Software• 80% de los costos de desarrollo de programas se dedican a detectar y corregir defectos.

• La Academia de Ciencias de Estados Unidos pidió al Congreso una ley que atribuya a las casas de software una responsabilidad civil por daños y perjuicios a las empresa.

Introducción

Calidad del Software• La industria del software presenta algunas deficiencias como:

• Falta de competitividad• Débil gestión administrativa• No se aplican estándares internacionales

Introducción

Concepto popular de calidad• Calidad para la mayoría de las personas:

• Producto bueno

• Sinónimo de bien construido o fabricado

• “Lo mejor”• Lo contrario de engaño

• La tienen las cosas caras

Introducción

Calidad del software• La calidad es un concepto muy asbtracto de definir. Generalmente, es transparente cuando está presente, pero fácilmente reconocible en su ausencia.

• Algunas definiciones básicas de calidad:

• Cualidad o conjunto de cualidades de una persona o cosa que permiten compararla con otras de su especie

Introducción

Calidad del software• “I do not worry whether something is cheap or expensive. I only worry if it is good. If it is good enough, the public will pay you back for it”

• Walt Disney

• ¿Cómo se distinguen las empresas de otras?

• A través de orientar sus mejores prácticas hacia los clientes

Introducción

Calidad del Software• Adecuación (del producto) al uso (Juran)

• Conformidad con requisitos y confiabilidad en el funcionamiento (Deming)

• Cero defectos (Crosby)

• Pérdida económica que un producto supone para la sociedad desde el momento de su expedición (Taguchi)

Introducción

Calidad del Software• Grado en el que un conjunto de características inherentes cumple con los requisitos (ISO 9000:2000).

• Un buen producto no es el que cumple con una determinada especificación, sino el que es bien recibido por el cliente (Drucker)

• La calidad no es absoluta, es multidimensional.

Introducción

Calidad del Software• ¿Existen Tipos de calidad?• Más bien enfoques

GESTIÓN DE LA CALIDAD

Introducción

Calidad del software• Algunos ejemplos de falta de calidad en el software:

• El programa no está probado

• El sistema operativo está incompleto

• No están escritos los requisitos

• Estamos fuera de tiempo en un proyecto

Introducción

Calidad del software• En el pasado las empresas veían a la calidad como un gasto.

• Cada vez más, las empresas se dan cuenta de que invertir en calidad es una de las inversiones más rentables que pueden hacer

• “Cuesta mucho menos que no hacer nada”.

Introducción

Calidad del Software• Se tienen creencias erróneas de Calidad:

• Analogía de la calidad con el sexo (Crosby):

• Todo el mundo es partidario

• Todo el mundo cree que la entiende• Todo el mundo cree que los problemas en

esta área son culpa de otros

Introducción

Calidad del Software• No puede medirse / Puede medirse su economía

• La calidad cuesta / Retorno de inversión favorable

• Los problemas los provocan los empleados / Todo el mundo está implicado

• La calidad se origina en el Departamento de Calidad / Todos deben colaborar

Introducción

Calidad del software• Una mejor definición de calidad es: “grado en que un conjunto de características inherentes cumplen con unos requisitos.”

• En pocas palabras: SATISFACER NECESIDADES Y EXPECTATIVAS DE LOS CLIENTES

• Calidad = cliente satisfecho

Introducción

Calidad del Software• Sólo el 10 - 15 % de las compañías miden la satisfacción de sus clientes. El resto mide la insatisfacción: quejas, reclamaciones, devoluciones, reparaciones, etc.

• La retroalimentación por parte del cliente del producto es importante ¿qué métodos consideras que pueden implementarse?

Introducción

PPLANEARLANEAR

DEFINIRMETAS

DEFINIRMETODOS

HHACERACER

CCOMPROBAROMPROBAR

VERIFICAR LOSRESULTADOS

AACTUARCTUAR

ACTUARDE FORMA

CORRECTIVA

EDUCAR YENTRENAR

EJECUTARLA TAREA

Ciclo Deaming (mejora continua)

Conceptos básicos• El objetivo fundamental del Desarrollo Estructurado de Proyectos es lograr la calidad del software.

• Por calidad se entienden muchas cosas. Para nuestro curso lo entenderemos como realizar 100% bien las cosas en el menor tiempo posible (eficacia y eficiencia)

Calidad del Software

Calidad del Software• La calidad es relativa a las personas, a su edad, a las circunstancias de trabajo, el tiempo…

• Un caramelo para un niño.

• El tiempo varia las percepciones.

• La calidad tiene diferentes perspectivas.


Calidad del Software• Perspectivas de la caldad

Funcionalidad

Oportunidad

Costo


Calidad del Software• Vistas de la calidad, Garvin (1984):

• Transcedental (calidad = excelencia innata)

• Basada en el usuario (adecuación al propósito)

• Basada en el fabricante (conformidad con requisitos)


Calidad del Software• Basada en el producto (económica)

• Basada en el valor (precio asequible)

• Se necesita de los tres enfoques para lograr la calidad total


Calidad de SoftwareCalidad de Software• En general la Ing. Sw tiene los objetivos de que el software sea correcto, utilizable y costo-efectivo.

• Sinónimos de calidad es que esté libre de errores. Muchas de las metodologías de software actuales se basan en esta premisa.


Calidad de SoftwareCalidad de Software• ¿Por qué es difícil lograr la calidad del software?

• El software es un producto intangible el cual se logra a través de un proceso creativo ya que programar es un arte, el cual no puede ser sistematizado del todo.


• ¿Por qué es importante el Desarrollo de Proyectos de forma Metodológica? El software es cada vez más complejo y costosos que se compara con construir un edificio.

• En 1968 se da un hito importante al ocurrir la “crisis del software” y definirse la Ingeniería de Software como tal.


Puede hacerlo una sola personaRequiere:

Modelado mínimoProceso simpleHerramientas simples

Calidad no tan demandante


Construida eficientemente y en un tiempo razonable por un equipoRequiere:

ModeladoProceso bien definidoHerramientas más sofisticadas

Calidad Requerida


No cualquier persona o grupo de persona lo realiza.Imposible sin técnicas de Ingeniería


Calidad del Software• Para lograr la calidad de un producto de desarrollo de software se necesita que la organización se gestione de forma sistemática y transparente. Para ello, ha surgido lo que se conoce como Sistema de Gestión de Calidad (SGC).

• Tarea: ¿En qué consiste el SGC del Tecnológico de Morelia? próximo jueves. En equipos de dos personas presentar un resumen (abstract). [no ocupa de más requerimientos]


• De acuerdo con cifras oficiales, el gasto

total en productos de software y tecnologías de información en México durante 2008 fue cercano a los 1,000 millones de dólares; sin embargo, sólo una fracción de esta demanda fue satisfecha por empresas nacionales.


Calidad del Software en México

• Las elevadas importaciones se deben, en parte, al alto número de empresas consultoras de origen extranjero.

• Las empresas filiales de compañías extranjeras representan alrededor del 30 por ciento de sus asociados pero concentran alrededor del 75 por ciento de las ventas.



• El perfil actual de la industria nacional resulta mayoritariamente de micro y pequeñas empresas (83%).

• Las empresas desarrolladoras de software (definición del PROSOFT), son de un tamaño muy inferior al promedio internacional que es de 250 empleados.



• Clasificación de empresas desarrolladoras de software:

Número de

Empleados

Número de

Empresas

Porcentaje

Micro 1 a 10 619 41%

Pequeña 11 a 50 629 42%

Mediana 51 a 100 130 9%

GrandeMás de

100114 8%



• Factores críticos de éxito de la industria de software en México:

• México cuenta con buena dotación de capital humano e infraestructura tecnológica, pero la calidad de la mano de obra y el costo de acceso a la infraestructura son un freno para la competitividad de la industria.



• Puntos Fuertes:

• La matrícula en áreas de TI crece de manera exponencial.

• Se tiene la mejor infraestructura tecnológica en latinoamérica después de Brasil.



• Puntos débiles:

• Existe poca investigación y falta de acceso a créditos.

• La mano de obra es calificada pero requiere de mucho tiempo de entrenamiento.

• A pesar de que se cuenta con mucha infraestructura de TI, el uso de ésta es cara.



• La oferta de la industria está muy orientada a la provisión de servicios.

• Las servicios con mayor contribución a la oferta son:

• Desarrollo e Integración

• Mantenimiento y Soporte de Software• Consultoría



• En México como en muchos países subdesarrollados la brecha digital es muy marcada.

• ¿por qué los Estadounidenses y Canadienses prefieren la mano de obra Hindú si al final de cuentas en México se tienen muchos factores críticos de éxito como: la cercanía, afinidad cultural, menores costos de mano de obra y fácil traslado?



• Catálogo de Empresas que han implementado controles de calidad en el desarrollo de software.

• En parejas, encontrar una empresa de la ciudad, estado, o región cercana que desarrolle software con controles de calidad. Investigar que controles de calidad tiene y COMO LOS IMPLEMENTA (dar ejemplos). 80% (los porcentajes se dividen con respecto al número de controles).

Evidencia 2


• Se revisará la originalidad del trabajo (que no esté repetido) 5% extra. Además de premiar la investigación de campo 5% extra (anexando evidencias respectivas).

• Se necesita que se dé una explicación lo más simple de los controles de calidad. 10%

• Se aplicarán las mismas reglas en cuestión de ortografía 10%

• Entrega: miércoles 3 de febrero

Evidencia 2

Tipos de OrganizaciónTipos de Organización

Radiografía Industria Sw Mex

Esquema de ContrataciónEsquema de Contratación


EdadEdad


EscolaridadEscolaridad


GéneroGénero


AntigüedadAntigüedad


SalariosSalarios


PoblaciónPoblación


Salario InternacionalSalario Internacional


Salario Tipo de OrganizaciónSalario Tipo de Organización


Salario por FunciónSalario por Función


Salario por Rango EdadSalario por Rango Edad


Salario Grado de EstudiosSalario Grado de Estudios


Conocimiento y HabilidadesConocimiento y Habilidades


PlataformasPlataformas


BDBD


Otras habilidadesOtras habilidades


CertificacionesCertificaciones


CertificacionesCertificacionesRadiografía Industria Sw Mex

Gestión de la Calidad• Características/Requerimientos que necesitan ser evaluados para medir la calidad.

• La innovación es un factor clave que determina calidad.

• ¿Qué es el Project Natal?

Especificaciones

Gestión de la Calidad• Sensor de movimiento en forma de barra horizontal de 36 cm con una cámara RGB camera, sensor de profundidad, mcrófono multiarreglo, procesador personalizado corriendo software propietario que permte captura de movimientos completos en 3D, reconocimiento facial y de voz.

Especificaciones

Gestión de la Calidad• ¿Qué se debe de hacer para lograr la calidad de un proceso?– Identificar los procesos críticos.– Encontrar la mejor forma de hacerlo– Llegar a acuerdos

• Un sistema de calidad consta de dos partes. La primera parte es la Documentación y se incluyen elementos como manuales, procedimientos y formas de registro.


Gestión de la Calidad• La segunda parte es la actividad práctica consistente en aspectos físicos como herramientas, computadoras, etc.; y aspectos humanos: formación del equipo de trabajo.

• Los factores de calidad pueden ser internos y externos dependiendo del grado de requerimientos si estos son funcionales o no funcionales.


Gestión de la Calidad ISO 9000

ALIDADALIDAD

LIDERAZGOLIDERAZGOLIDERAZGOLIDERAZGO

EENFOQUE NFOQUE ALAL CLIENTECLIENTE

EENFOQUE NFOQUE ALAL CLIENTECLIENTE

ENFOQUE ENFOQUE DEDEPROCESOPROCESO

ENFOQUE ENFOQUE DEDEPROCESOPROCESO

ENFOQUE ENFOQUE BASADO BASADO EN EN HECHOSHECHOS PARA LAPARA LATOMA DETOMA DEDECISIONDECISION

ENFOQUE ENFOQUE BASADO BASADO EN EN HECHOSHECHOS PARA LAPARA LATOMA DETOMA DEDECISIONDECISION

PARTICIPACIONPARTICIPACIONDELDEL PERSONALPERSONAL

PARTICIPACIONPARTICIPACIONDELDEL PERSONALPERSONAL

ENFOQUEENFOQUEDEDESISTEMASISTEMAPARAPARA LALA GESTIONGESTION

ENFOQUEENFOQUEDEDESISTEMASISTEMAPARAPARA LALA GESTIONGESTION

MEJORAMEJORACONTINUACONTINUAMEJORAMEJORACONTINUACONTINUA

RELACIONES RELACIONES MUTUAMENTE MUTUAMENTE BENEFICIOSABENEFICIOSAS CON EL S CON EL PROVEEDORPROVEEDOR

RELACIONES RELACIONES MUTUAMENTE MUTUAMENTE BENEFICIOSABENEFICIOSAS CON EL S CON EL PROVEEDORPROVEEDOR


• Nos orientan hacia mejores resultadosUso de Mejores Prácticas

• El profesor se encuentra actualmente ante una necesidad de extrema importancia. Necesita realizar una corbata para ir a una junta en donde se encontrarán altos empresarios del sector informático, el detalle es que no sabe a ser un nudo de corbata

• ¿Cómo podría resolver el problema?


• La solución más fácil es realizar outsorcing (que lo hagan otros).

• Sino se puede, se deberá realizar en base a tres formas básicas de solución de problemas:

• Conocimiento• Experiencia• Sentido Común


• La forma más fácil es a través de una metodología para realizar nudos de corbatas como la planteada en http://www.nudo-de-corbata.com/

• Lo primero que se tiene que saber es si debe ser un tipo especial de corbata o no. Los tipos pueden ir desde nudo de corbata simple, doble, windsor, medio windsor, nudo pequeño.


http://www.nudo-de-corbata.com/

Tipos de Nudos

Simple Doble

Tipos de Nudos

Windsor Medio Windsor

• Las metodologías son un conjunto de mejores prácticas que si no se llevan a la práctica o se hacen a medias es muy difícil que se tenga calidad.

• Aun siguiendo las recomendaciones, una metodología no garantiza que un producto tenga calidad.


Evitar Fracaso/Rechazo

• Cada buen final requiere de un buen inicio

Historia de Éxito

Definiciñon del Problema/ Reto

• ¿Qué camino seguiremos?Historia de Éxito

Modelos de Desarrollo

• El planteamiento es lo importante, no la velocidad

Historia de Éxito

Análisis Requerimientos y Especificaciones

• ¿Cómo debo hacerlo?Historia de Éxito

Diseño del Sw y Metodologías

• Sigamos un método confiable y seguroHistoria de Éxito

Sistemas de Alta Integridad

• Cálculos precisos, especificación matemática

Historia de Éxito

Métodos Formales

• Una buena administración siempre nos llevará por el camino adecuado

Historia de Éxito

Administración de Proyectos de Sw

• Se debe tener un buen manejo de “calidad”

Historia de Éxito

Aseguramiento de Calidad (SQA)

• Una buena herramienta no tiene precioHistoria de Éxito

Ambientes de Desarrollo de Software

• El modelo de Mantenimiento debe ser preparado

Historia de Éxito

Mantenimiento y Evolución del Sw

• Cada buen final requiere de un buen inicio

Historia de Éxito

Sólo así se puede mantener el éxito

• ISO 17799- ISO 27001– Política de seguridad– Aspectos organizativos para la seguridad– Clasificación y control de activos– Seguridad ligada al personal– Seguridad física y del entorno– Gestión de comunicaciones y operaciones– Control de accesos– Desarrollo y mantenimiento de sistemas– Gestión de incidentes de seguridad– Gestión de continuidad de negocio– Conformidad

SGSI

• La seguridad es un proceso. Se necesita de un Sistema de Gestión de Seguridad de la Información (SGSI).

• La información es un recurso vital en el mundo globalizado de hoy en día.

SGSI

• SSE/CMM (Systems Security Engineering/ Capability Maturity Model) define:

• Nivel 0: Nada de seguridad

• Nivel 1: Prácticas de seguridad realizadas de manera informal

• Nivel 2: Planificación y seguimiento de las prácticas de seguridad

SGSI

• Nivel 3: Definición y coordinación de las políticas y procedimientos de seguridad.

• Nivel 4: Seguridad controlada a través de distintos controles y objetivos de calidad.

• Nivel 5: Implantación de un proceso de mejora continua.

SGSI

• Se tiene una jerarquía de seguridad informática:

• CIA• Políticas• Planes

• Procedimientos• Tareas y Operaciones

• Registros y Evidencias.

SGSI

• Ejemplo de seguridad CIA

• Política: protección del servidor Web de la organización contra accesos no autorizados.

• Procedimiento 1: Actualización del software del servidor Web.

• Tarea1: Revisión diaria de los parches publicados por el fabricante.

SGSI

• Tarea2: Seguimiento de las noticias sobre posibles fallos de seguridad.

• Procedimiento 2: Revisión de los registros de actividad en el servidor.

• Tarea1: revisión semanal de los “logs” del servidor para detectar anomalías.

SGSI

• Tarea2: Configuraciones de alertas de seguridad que permitan reaccionar de forma urgente ante determinados tipos de ataques e intentos de intrusión.

• Inventario de soportes físicos. Destructor de Discos Duros.

SGSI

• Un SGSI se encuentra estandarizado en la norma ISO 27001:2005.

• La ISO 17799:2005 define buenas prácticas de SI pero en si no es certificable como tal. Se utilizó hasta antes de definirse el ISO 27001:2005

• Está basado en la norma británica BS7799 utilizada en seguridad de SI.

SGSI

• A continuación se muestran las principales versiones del estándar:

• ISO 27000 Vocabulario y Glosario

• ISO 27001 Estándar certificable

• ISO 27002 Relevo del ISO/IEC 17799:2005

SGSI

• ISO 27003 Guía de implantación

• ISO 27004 Métricas e indicadores

• ISO 27005 Gestión de Riesgos

• ISO 27006 Requerimientos para las entidades de auditoría y certificación.

SGSI

• Se debe realizar un Plan de Continuidad del Negocio, el cual puede contener:

• DRP Disaster Recovery Planning• BRP Business Resumption Planning

• COOP Continuity Operations Planning

• CP Contingence Planning• ERP Emergency Response Planning

SGSI

• En base a lo visto de SGC desarrolla un pequeño modelo de SGC para garantizar la calidad del software.

• El modelo desarrollado deberá contener los elementos vistos en clase de un SGC y se deberán describir al menos tres controles de aseguramiento de calidad.

• En equipos de dos personas. Entrega al finalizar la clase.

SGC para el Desarrollo Sw

Calidad en el Desarrollo Sw

Calidad del proceso

Herramientas Calidad del Recursosde desarrollo producto invertidos

Calidad del grupo de trabajo

Ian Sommerville

Calidad en el Desarrollo SwAnálisis

Requerimientos

Diseño delSistema

Diseño deObjetos

Codificación

Pruebas

Instalación

Mantenimiento

Modelo Lineal/Cascada


Realmente no es tan lineal

Análisis de losRequerimientos

Diseño del Sistema

Diseño deObjetos

CodificacionPruebas

Instalación

Mantenimiento

• SQA forma parte fundamental de los procesos de la Ing. de Software.

• El proceso de aseguramiento de calidad se debe de dar en cada uno de los procesos de la Ingeniería de Software y no sólo hasta el final.

• El SQA es el principal control de calidad y consiste en la realización de pruebas a todos niveles.

Relación Ing. de Sw con SQA

• El Software Quality Assurance tiene como objetivo el lograr la calidad del software.

• SQA se define por un conjunto de mejores prácticas que llevan la verificación y validación del software desarrollado.

• El proceso de SQA aunque se enfoca más en la medición y control del código fuente aunque tiene que ver con las demás áreas del proceso.


• El SQA logra resolver la mayoría de los errores que se podrían presentar en el software, asegurando que este sea confiable, usable y costo-efectivo.

• SQA se compone de muchas actividades pero la primera de ellas es el proceso de planeación. Otras actividades son las siguientes:


• Participación en el desarrollo de la descripción del proceso de software del proyecto

• Revisión de las actividades de ingeniería de software para verificar su ajuste al proceso de software.

• Registrar lo que no se ajusta a los requisitos e informar a los superiores.


• Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software.

• Asegurar que las desviaciones del trabajo y los productos de software se documentan y se manejan de acuerdo con un procedimiento establecido


• Se verifica objetivamente la correspondencia de los productos y actividades SW con estándares, procedimientos y requisitos.


Plan de SQA

SDP

reqs

stds., procs.

Producto para entregar

estado desviaciones

Procs.

SDPEl grupo SQA revisa las actividades de ISW para cumplimiento

Grupo SQA: Cumplimiento productos designados

El grupo SQA participa y revisa plan del proyecto

• Las personas y los grupos afectados son informados de las actividades y resultados del SQA.


Grupo de ISW

Plan de SQA

El grupo de SQA revisa periódicamente sus actividades y hallazgos con SQA del cliente

El grupo de SQA informa periódicamente de los resultados

Estatuto de SQA

• Problemas de incumplimiento no resueltos dentro del proyecto se escalan a la alta dirección.


Desviaciones

no resueltas

Proc.

- resueltas a nivel de

responsable o PM

- “g & c”- escaladas al director y revisadas hasta su resolución

Desviaciones en actividades,productos, son documentadas y tratadas Ac 7 responsables

de tarea, mandos intermedios SW, PM

director designado

• La calidad se logra desde el inicio y el inicio se da a través de la organización de un equipo de desarrollo por medio de la persona.

• Existen metodologías que se enfocan al desarrollo de las actividades de la persona como PSP, en equipos de trabajo como TSP y a nivel organizativo CMMI.

Calidad Sw en el Ciclo de Vida

• Ciclo de Vida de un ProductoCalidad en el Desarrollo Sw

Entrega Producción Diseño

Orientada alcontrol de productos(inspección)

Orientada alcontrol delproceso(prevención)

Orientada aldiseño denuevosproductos (innovación)

• Ejemplo: una de las primeras actividades al momento de realizar cualquier desarrollo de software es la Ingeniería de Requerimientos.

• Una técnica de obtención de requerimientos así como de verificación son las rúbricas.

• Son más avanzadas que las listas de cotejo (checklist) ya que definen el grado de calidad.

Calidad Sw en el Ciclo de Vida

• Una rúbrica es un elemento que nos permite definir en forma tabular los requisitos que debe tener un producto en general y evaluarlos en base a un criterio determinado.

Rúbrica

• Descripción del puesto de SQA. Entrega Lunes 8 de Febrero.

Evidencia 3

Rubro A (100) B (85) C (70) Z (0)

Revisión de Fuentes Bibliográficas (20%)

Consulta al menos tres fuentes bibliográficas formales y las cita adecuadamente (libros, revistas, artículos técnicos)

Consultó fuentes pero fueron menos de tres o no estuvieron bien citadas

Consulto alguna fuente bibliográficas que no eran formal

No citó o consulto fuentes

Presentación del Trabajo (10%)

El trabajo se entrega con un portada, índice, introducción, desarrollo y conclusiones propias

Faltó una sección o está mal planteada.

Faltaron dos secciones o están mal planteadas

Faltaron 3 o más secciones

Ejemplificación de las funciones del SQA (70%)

Se cuentan con al menos tres descripciones de puestos ejemplificando con organizadores gráficos u otro tipo de evidencia sustancia las funciones del SQA

Una descripción de puestos no está ejemplificada adecuadamente

Dos descripciones de la funciones del SQA no están ejemplificadas adecuadamente

Tres descripciones no están ejemplificadas adecuadamente.

• ¿El software libre tiene calidad? La mayoría de la industria dice que no.

• Defender una postura argumentada al respecto. Traer la evidencia que sustente dicha postura.

• Sugerencia: lectura del Artículo: “La Catedral y el Bazar” de Eric S. Raymond. De forma personal escribir los tres principios que más llamaron mi atención.

Debate

• Traer el compilador de Java o IDE

• Instalar un analizador de protocolos de red como Wireshark.

• Leer sobre el proceso de auditoría en el desarrollo del software.

Dinámica del Viernes

• El desarrollo de software es una actividad que requiere de roles y de responsabilidades, esas responsabilidades deben estar bien delimitadas.

• Los roles y responsabilidades varían de empresa a empresa y están dados por las metodologías y características de los equipos de trabajos.

Roles y Responsabilidades SQA

• Ejemplos típicos de personal involucrado en equipos de desarrollo: gerente o líder de proyecto, analista, programador, diseñador, tester, SQA.

• ¿Qué diferencia existe entre un programador junior y senior?

• Salario• Conocimientos• Experiencia (índices de productivad,

tiempos)

Roles y Responsabilidades SQA

• Para ser SQA se debe cumplir preferentemente con las siguientes características:

• Conocimiento de todo el proceso de desarrollo de software

• Experiencia en varios roles dentro de la organización

• Ser proactivo• Capacidad de seguimiento de actividades• Capacidad de trato con la gente.

Habiidades y Capacidades SQA

• El plan para el aseguramiento de calidad de productos de software consta de 15 pasos que a continuación se mencionan.

1.Objetivos1. Objetivos del plan.2. Productos de software incluídos.3. Alcance en el ciclo de vida de cada

producto.

Plan SQA ANSI/IEEE

• 2. Referencias

• Lista de documentos y estándares a los que se hace referencia en el plan. Por ejemplo:

• ANSI/IEEE Standard for Software Requirements Specification

• ANSI/IEEE Standard for Software Unit Testing

Plan SQA ANSI/IEEE

3. Administración1. Estructura organizacional.2. Actividades de medición de Calidad del ciclo

de vida de cada producto.3. Asignación de responsabilidades.

4. Documentación1. Objetivos.2. Documentación mínima aceptable para

cada producto:

Plan SQA ANSI/IEEE

• Software requirements specification (SRS)• Software design description (SDD)• Software verification and validation plan

(SVVP)• Software verification and validation report

(SVVR)• User documentation• Software configuration management plan

(SCMP)

Plan SQA ANSI/IEEE

5. Estándares, prácticas y normas 1. Objetivos.2. Estándares, prácticas y normas de diseño,

programación, medición y pruebas para cada producto. (Ejemplos: Open UP, MSF Model, etc)

6. Revisión y auditoría 1. Objetivos.2. Nivel mínimo aceptable de revisión y

auditoría para cada producto:

Plan SQA ANSI/IEEE

• Software requirements review (SRR)• Preliminary design review (PDR)• Critical design review (CDR)• Software verification and validation plan

review (SVVPR)• Software configuration management plan

review (SCMPR)• Functional audit, Physical audit, In-

process audit• Managerial reviews, Post Mortem reviews

Plan SQA ANSI/IEEE

7. Pruebas– Actividades y pruebas no inlcuídas en la

sección 4.2 (SVVP).

8. Reporte de problemas y acciones correctivas1.Actividades y procedimientos para reportar,

dar seguimiento y resolver problemas del producto y del proceso.

2.Asignación de responsabilidades.

Plan SQA ANSI/IEEE

9. Herramientas, técnicas, y metodologías1. Objetivo y uso de herramientas de software,

técnicas, y metodologías de apoyo al plan de SQA (Ejemplos: PSP, TSP, CMMi, etc…)

10. Control del código1. Objetivo y uso de herramientas para dar

mantenimiento, almacenar, conservar, y documentar diferentes versiones del código. NOTA: Puede ser parte del SCMP.

Plan SQA ANSI/IEEE

11.Control de Medios1. Objetivo y uso de dispositivos para

almacenar, conservar, copiar y proteger el acceso a diferentes versiones del código. NOTA: Puede ser parte del SCMP.

12.Control de proveedores1. Estrategias para asegurar que los productos

de software y los desarrolladores de proveedores externos cumplen con los estándares requeridos.

Plan SQA ANSI/IEEE

13.Organización y retención de documentos y reportes

1. Criterios para seleccionar, conservar y proteger la documentación generada como parte del Plan de SQA. (Ejemplo: Kintana, The Test Oracle, etc…)

14.Capacitación y entrenamiento1. Actividades para desarrollar las habilidades

y actitudes necesarias del personal que participa en el Plan de SQA.

Plan SQA ANSI/IEEE

15.Administración de riesgos1. Actividades y procedimientos para

identificar, monitorear, evaluar y controlar factores de riesgo para cada producto en el Plan de SQA.

Plan SQA ANSI/IEEE

• Es el proceso de inspección más básico que existe en el desarrollo de software.

• Del software proporcionado encontrar si hay errores. Tip: puedes utilizar un analizador de protocolos para ver si ocurre algo diferente.

• Es difícil realizar la revisión de algo sin un plan pero es más difícil no tener una norma de referencia para poder auditarlo.

Revisión del Software

• Existen una infinidad de herramientas de calidad:

• Básicas• De gestión• De creatividad• Estadísticas• De diseño• De medición

Herramientas de la Calidad


• Análisis FODA de la industria del software en México

FORTALEZAS•Uso horario similar•Afinidad cultural•Proximidad y fácil traslado•Menores costos de mano de obra•Buena infraestructura aunque más costosa

•TLCAN•Estabilidad política•Bajo riesgo geopolítico

DEBILIDADES•Oferta limitada de mano de obra calificada

•Escaso manejo del inglés•Niveles de certificación de las empresas mexicanas

•Estructura de la industria de TI •Temas de seguridad y corrupción•Falta de experiencia de las empresas en proyectos grandes de México

•Acceso a capital•Carga y legislación laboral

OPORTUNIDADES•Asociación con jugadores globales de desarrollo de TI canadienses

•Amplio espacio para el apoyo efectivo del gobierno

•Generar una masa crítica de mano de obra calificada

AMENAZAS•Alta competencia de países emergentes en el mercado de TI (Brasil, Rusia, China y Filipinas)

• Incrementos en el costo de la mano de obra

•Constante innovación tecnológica


• Del catálogo de empresas de la evidencia 2, desarrollar un análisis FODA de las técnicas de aseguramiento de la calidad de la empresa.

• Se evaluará que se haga la comparativa de los tres controles de calidad y las cruzas de FD, FA y OD.

• Fecha de entrega miércoles 10 de febrero de 2010.

Evidencia 4


• Diagrama de flujo

• Diagrama causa-efecto• Diagrama de Pareto

• Hoja de chequeo• Grafo de control

• Histograma• Diagrama de dispersión



• Diagramas de Causa-EfectoHerramientas de la Calidad

1. Definir el efecto que se quiere analizar

2. Determinar causas/subcausas (5 M: Método, Material, Maquinaria, Mano de obra, Medio ambiente)

3. Revisar causas y su interacción

4. Seleccionar las causas según su grado de contribución al efecto

EFECTO

Categoria 1

Categoria 2

Categoria 3

Categoria 5

Categoria 4


• Algunos ejemplos de herramientas de calidad aplicadas al software más específicos son:

• Auditorías (revisión en la parte del proceso)

• Control estadísticos de errores de codificación.

• Encuestas• Benchmarking• Realización de pruebas de escritorio.



• Traer impresa al menos dos hojas en formato horizontal de 80 columnas x 25 Filas.

Tarea


Actividad


• Realizar un programa que permita realizar operaciones aritméticas entre números complejos (6 operaciones).

• Se deberá tener una clase complejo que tenga como métodos las propiedades solicitadas.

• El programa será dado en modo texto o bien con JOptionPane (es indiferente la interface).

Actividad


• El programa se deberá codificar renglón por renglón, cuadro por cuadro en el formato de hoja de codificación.

• Tener la seguridad de lo que se está haciendo está bien.

Actividad


• Suma, Resta, Multiplicación, división, igualdad y multiplicación por un escalar

Número complejo

(a,b) – (c,d) = (a-c)+(b-d)i


• De la hoja de codificación dada, realizar la implementación necesaria. Tomar el tiempo de inicio de la codificación.

• Correr el programa. Si presenta errores de “dedo” (faltó un punto y coma, está mal un carácter en mayúsculas y debe ser en minúsculas, etc.) corregirlos hasta que se pueda ejecutar. Tomar el tiempo de finalización de la codificación hasta que el programa compile.

Actividad


• CONTABILIZAR todas las modificaciones realizadas.

• Correr el programa con las siguientes valores de caso de prueba:

• Suma: (2+3i) + (3-5i) = (5-2i)

• Resta: (2+3i) + (3-5i) = (-1+8i)

• Multiplicación: (2+3i) * (3-5i) = (21-i)

Actividad


• División: (2+3i) / (3-5i) = (-0.2647+0.5588i)

• Igualdad: (2+3i) <> (3-5i) y (2+3i) = (2+3i)

• Multiplicación por escalar: 3 (2+3i) = 6+9i

• Indicar si con estos casos de prueba son suficientes. Si no es suficiente, indicar que otros casos complementarios se necesitan.

Actividad


• Sino se ejecuta bien tomar tiempo de inicio de reparación y hasta que esté correcto, tomar tiempo final de reparación

• Sumar tiempos de codificación y de reparación.

• Contabilizar LOCs del programa final. Dividir las LOCs entre el tiempo. Por ejemplo: 100LOCs/4 horas = 25 LOC/hr

Actividad


• Líneas de código efectivas. El siguiente código puede llegar a tener 6 LOC pero solo 2 ELOC.

public int suma (int a, int b){ int c; c = a+b; return c;}

ELOC


• Se simplifica en: public int suma(int a, int b) { return a +b; }

• No cuentan: • Declaración de variables o atributos• Ni inicialización

• Si:• Llamadas a métodos

ELOC


• Contabilizar las ELOC del programa.

• Las líneas de código no cuentan

• En la vida real este estimado se ignora dado que se asume que la codificación es de calidad.

• Implementar los 4 casos de pruebas a través de un test con JUnit.

ELOC

• Es el framework de pruebas unitarias para Java más utilizado en el mundo.

• En IDEs como Netbeans y Eclipse viene de manera predeterminada.

• Para crearlo en Netbeans es muy fácil sólo se escoge la opción de crear una prueba unitaria de una clase existente y crea un bosquejo de prueba con cada método impelementado.

JUnit

• Existen dos versiones populares a manejar la 3.x (anticuada pero ampliamente utilizada) y la 4.x (que maneja anotaciones pero no es compatible con versiones viejas).

• La ventaja de utilizar pruebas unitarias es que nos permite corroborar nuestro código sin necesidad de crear una aplicación.

JUnit

• En la versión 3.x las pruebas unitarias tienen la siguiente forma:

• Se importa la clase junit.framework.TestCase;

• La clase de prueba hereda de TestCase

• Se puede utilizar utilizar un constructor para inicializar datos.

JUnit

• Se utiliza el método setUp() para realizar un conjunto de acciones antes de evaluar un caso de prueba.

• Se utiliza el método tearDown() para realizar acciones una vez finalizado el caso de prueba

• Se utiliza el método fail() que recibe una cadena de mensaje de error para forzar a una falla.

JUnit

• Se utiliza el método assertEquals(valoresperado, valorresultante) para saber si el método se ejecutó de manera exitosa.

• Se puede utilizar el método assertNotNull(objeto) para saber si un objeto no es nullo.

• Para tipos de datos flotantes el método assertEquals utiliza un parámetro adicional delta para indicar la presición.

JUnit

• La diferencia con la versión 4.x de Junit radica en lo siguiente:

• Se importan las siguientes clases: org.junit.After, org.junit.AfterClass, org.junit.Before, org.junit.BeforeClass, org.junit.Test, org.junit.Assert.*;

• Se utilizan las anotaciones @BeforeClass, @AfterClass, @Before, @After para indicar cuando se utilizan los métodos auxiliares

JUnit

• La clase de prueba no extiende de ninguna otra pero cada caso de prueba debe utilizar la anotación @Test

• Se recomienda realizar los casos de prueba de manera separada uno por uno y dejarlos siempre presente.

JUnit


• Programación en Java y/o C++ de las Raíces de una ecuación de segundo por fórmula general.

• Programación en Pares: Actividad Desarrollada por dos personas (en caso de que queden un individuo, este se realiza de forma individual –no parejas de tres-).

• Diferenciar roles de trabajos. Programador y Registro de Actividades.

Evidencia 5


• Se entregará un reporte escrito al finalizar la clase.

• Evidencia de un modelado previo del problema 20% (diagramas de UML –casos, actividades, secuencia-, de bloques, de flujo, etc.) debe de considerar toda la complejidad del problema.

• Evidencia Estimación de Líneas de Código, de Tiempo, errores posibles. 10%

Evidencia 5


• Evidencia de Toma de Tiempo y rastreo de líneas de código que se agregaron y se eliminaron. 10%

• Codificación del programa (sin interfaces gráficas) que resuelva el problema. 20%

• Contabilización de corridas funcionando incorrectamente (realización de pruebas unitarias). Se dan los resultados previamente. Registro 20%

Evidencia 5


• Contabilización de errores de compilación. Registro 5%

• *Reflexión Por qué A no puede ser 0. Valor 5%

• Termino a tiempo (horario de clases). Valor 10%

Evidencia 5


• Jueves 11 y Viernes 12 de Febrero Evidencia 5

• Examen Escrito Teórico-Práctico Viernes 19.

Pendientes


• Roger S. Pressman, Ingeniería de software un enfoque práctico.Ed. McGraw Hill.

• • Piattini M.G. y F.O, Calidad en el

desarrollo y mantenimiento del software. Ed. RAMA.

• • Hernández Ballesteros, J. F. Y Minguet

Melían J. La calidad del software y su medida, Ed. CERASA.

Referencias


• IEEE Std. 730, IEEE Standard for Software Quality Assurance Plans, New York, IEEE Computer Society, 1989

• IEEE Std. 1059, IEEE Guide for Software Verification and Validation Plans, New York, IEEE Computer Society, 1993

• IEEE Std. 1074, Standard for Developing Software Life Cycle Processess, New York, IEEE Computer Society, 1991

Referencias

Aseguramiento de la Calidad del Software M.C. Juan Carlos Olivares Rojas [email protected]...

Documents

Transcript of Aseguramiento de la Calidad del Software M.C. Juan Carlos Olivares Rojas [email protected]...