Aseguramiento de la Calidad del Software

Presentación del tema: "Aseguramiento de la Calidad del Software"— Transcripción de la presentación:

1 Aseguramiento de la Calidad del Software
M.C. Juan Carlos Olivares Rojas @jcolivares Enero 2010

2 Competencias 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.

3 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.

4 Temario 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.

5 Temario Roles y responsabilidades de los equipos de desarrollo.
Habilidades y capacidades del personal del SQA. Actividades del SQA. Métodos y herramientas.

6 Evidencias 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%

7 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%

8 Equipos 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.

9 Equipos E5: Carlos Fabié

10 Para ello debemos probar sus especificaciones
¿Qué tiene más calidad? Los dos tienen la misma calidad siempre y cuando cumplan con sus requerimientos Para ello debemos probar sus especificaciones

11 Introducción Conceptos básicos
Los errores del software le salen muy caros a Estados Unidos: 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 millones de dólares. Conceptos básicos

12 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. Calidad del Software

13 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 Calidad del Software

14 Concepto popular de calidad
Introducción 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 Concepto popular de calidad

15 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 Calidad del software

16 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 Calidad del software

17 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) Calidad del Software

18 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. Calidad del Software

19 Introducción Calidad del Software ¿Existen Tipos de calidad?
Más bien enfoques Calidad del Software GESTIÓN DE LA CALIDAD

20 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 Calidad del software

21 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”. Calidad del software

22 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 Calidad del Software

23 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 Calidad del Software

24 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 Calidad del software

25 Introducción Calidad del Software
Sólo el % 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? Calidad del Software

26 Ciclo Deaming (mejora continua)
PLANEAR ACTUAR ACTUAR DE FORMA CORRECTIVA DEFINIR METAS DEFINIR METODOS VERIFICAR LOS RESULTADOS EJECUTAR LA TAREA EDUCAR Y ENTRENAR COMPROBAR HACER

27 Calidad del Software 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) Conceptos básicos

28 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

29 Calidad del Software Calidad del Software Perspectivas de la caldad
Funcionalidad Costo Oportunidad

30 Calidad del Software 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

31 Calidad del Software 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 del Software

32 Calidad del Software Calidad 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 Software

33 Calidad del Software Calidad 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. Calidad de Software

34 Calidad del Software

35 Calidad del Software ¿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.

36 Calidad del Software Puede hacerlo una sola persona Requiere:
Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples Calidad no tan demandante

37 Calidad del Software Construida eficientemente y en un tiempo
Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas Calidad Requerida

38 Calidad del Software No cualquier persona o grupo de persona lo realiza. Imposible sin técnicas de Ingeniería Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."

39 Calidad del Software 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] Calidad del Software

40 Calidad del Software 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.

41 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. Calidad del Software en México

42 Calidad del Software en México
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. Calidad del Software en México

43 Calidad del Software en México
Clasificación de empresas desarrolladoras de software: Calidad del Software en México 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% Grande Más de 100 114 8%

44 Calidad del Software en México
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. Calidad del Software en México

45 Calidad del Software en México
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. Calidad del Software en México

46 Calidad del Software en México
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. Calidad del Software en México

47 Calidad del Software en México
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 Calidad del Software en México

48 Calidad del Software en México
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? Calidad del Software en México

49 Calidad del Software en México
Evidencia 2 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). Calidad del Software en México

50 Calidad del Software en México
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 Calidad del Software en México

51 Radiografía Industria Sw Mex
Tipos de Organización

52 Esquema de Contratación
Radiografía Industria Sw Mex Esquema de Contratación

53 Radiografía Industria Sw Mex
Edad

54 Radiografía Industria Sw Mex
Escolaridad

55 Radiografía Industria Sw Mex
Género

56 Radiografía Industria Sw Mex
Antigüedad

57 Radiografía Industria Sw Mex
Salarios

58 Radiografía Industria Sw Mex
Salarios

59 Radiografía Industria Sw Mex
Población

60 Salario Internacional
Radiografía Industria Sw Mex Salario Internacional

61 Salario Tipo de Organización
Radiografía Industria Sw Mex Salario Tipo de Organización

62 Radiografía Industria Sw Mex
Salario por Función

63 Radiografía Industria Sw Mex
Salario por Rango Edad

64 Salario Grado de Estudios
Radiografía Industria Sw Mex Salario Grado de Estudios

65 Conocimiento y Habilidades
Radiografía Industria Sw Mex Conocimiento y Habilidades

66 Conocimiento y Habilidades
Radiografía Industria Sw Mex Conocimiento y Habilidades

67 Radiografía Industria Sw Mex
Plataformas

68 Radiografía Industria Sw Mex
BD

69 Radiografía Industria Sw Mex
Otras habilidades

70 Radiografía Industria Sw Mex
Certificaciones

71 Radiografía Industria Sw Mex
Certificaciones

72 Especificaciones 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? Gestión de la Calidad

73 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. Gestión de la Calidad

74 Calidad del Software 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

75 Calidad del Software 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

76 Gestión de la Calidad ISO 9000
Calidad del Software Gestión de la Calidad ISO 9000 PARTICIPACION DEL PERSONAL LIDERAZGO ENFOQUE AL CLIENTE ENFOQUE DE PROCESO ENFOQUE DE SISTEMA PARA LA GESTION ALIDAD MEJORA CONTINUA RELACIONES MUTUAMENTE BENEFICIOSAS CON EL PROVEEDOR ENFOQUE BASADO EN HECHOS PARA LA TOMA DE DECISION

77 Uso de Mejores Prácticas
Nos orientan hacia mejores resultados

78 Calidad del Software

79 Calidad del Software 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?

80 Calidad del Software 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

81 Calidad del Software La forma más fácil es a través de una metodología para realizar nudos de corbatas como la planteada en 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.

82 Tipos de Nudos Simple Doble

83 Tipos de Nudos Windsor Medio Windsor

84 Calidad del Software 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.

85 Evitar Fracaso/Rechazo

86 Definiciñon del Problema/ Reto
Historia de Éxito Cada buen final requiere de un buen inicio Definiciñon del Problema/ Reto

87 Historia de Éxito ¿Qué camino seguiremos? Modelos de Desarrollo

88 Análisis Requerimientos y Especificaciones
Historia de Éxito El planteamiento es lo importante, no la velocidad Análisis Requerimientos y Especificaciones

89 Diseño del Sw y Metodologías
Historia de Éxito ¿Cómo debo hacerlo? Diseño del Sw y Metodologías

90 Sistemas de Alta Integridad
Historia de Éxito Sigamos un método confiable y seguro Sistemas de Alta Integridad

91 Historia de Éxito Métodos Formales
Cálculos precisos, especificación matemática Métodos Formales

92 Administración de Proyectos de Sw
Historia de Éxito Una buena administración siempre nos llevará por el camino adecuado Administración de Proyectos de Sw

93 Aseguramiento de Calidad (SQA)
Historia de Éxito Se debe tener un buen manejo de “calidad” Aseguramiento de Calidad (SQA)

94 Ambientes de Desarrollo de Software
Historia de Éxito Una buena herramienta no tiene precio Ambientes de Desarrollo de Software

95 Mantenimiento y Evolución del Sw
Historia de Éxito El modelo de Mantenimiento debe ser preparado Mantenimiento y Evolución del Sw

96 Sólo así se puede mantener el éxito
Historia de Éxito Cada buen final requiere de un buen inicio Sólo así se puede mantener el éxito

97 SGSI

98 SGSI 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

99 SGSI

100 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.

101 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

102 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.

103 Registros y Evidencias.
SGSI Se tiene una jerarquía de seguridad informática: CIA Políticas Planes Procedimientos Tareas y Operaciones Registros y Evidencias.

104 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.

105 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.

106 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.

107 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.

108 SGSI A continuación se muestran las principales versiones del estándar: ISO Vocabulario y Glosario ISO Estándar certificable ISO Relevo del ISO/IEC 17799:2005

109 SGSI ISO 27003 Guía de implantación ISO 27004 Métricas e indicadores
ISO Gestión de Riesgos ISO Requerimientos para las entidades de auditoría y certificación.

110 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

111 SGC para el Desarrollo Sw
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.

112 Calidad en el Desarrollo Sw
Calidad del proceso Herramientas Calidad del Recursos de desarrollo producto invertidos Calidad del grupo de trabajo Ian Sommerville

113 Calidad en el Desarrollo Sw

114 Calidad en el Desarrollo Sw
Análisis Requerimientos Diseño del Sistema Diseño de Objetos Codificación Pruebas Instalación Mantenimiento Modelo Lineal/Cascada

115 Calidad en el Desarrollo Sw
Análisis de los Requerimientos Mantenimiento Diseño del Sistema Instalación Diseño de Objetos Pruebas Codificacion Realmente no es tan lineal

116 Relación Ing. de Sw con SQA
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.

117 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.

118 Relación Ing. de Sw con SQA
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:

119 Relación Ing. de Sw con SQA
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.

120 Relación Ing. de Sw con SQA
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

121 Relación Ing. de Sw con SQA
Se verifica objetivamente la correspondencia de los productos y actividades SW con estándares, procedimientos y requisitos. Plan de SQA El grupo SQA revisa las actividades de ISW para cumplimiento SDP Procs. estado desviaciones Grupo SQA: Cumplimiento productos designados Producto para entregar reqs stds., procs. SDP El grupo SQA participa y revisa plan del proyecto

122 Relación Ing. de Sw con SQA
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

123 Relación Ing. de Sw con 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

124 Calidad Sw en el Ciclo de Vida
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.

125 Calidad en el Desarrollo Sw
Ciclo de Vida de un Producto Diseño Producción Entrega Orientada al diseño de nuevos productos Orientada al control del proceso (prevención) Orientada al control de productos (inspección) (innovación)

126 Calidad Sw en el Ciclo de Vida
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.

127 Rúbrica 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.

128 Evidencia 3 Descripción del puesto de SQA. Entrega Lunes 8 de Febrero.
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.

129 Debate ¿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.

130 Dinámica del Viernes 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.

131 Roles y Responsabilidades SQA
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.

132 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)

133 Habiidades y Capacidades 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.

134 Plan SQA ANSI/IEEE El plan para el aseguramiento de calidad de productos de software consta de 15 pasos que a continuación se mencionan. Objetivos Objetivos del plan. Productos de software incluídos. Alcance en el ciclo de vida de cada producto.

135 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

136 Plan SQA ANSI/IEEE Administración Documentación
Estructura organizacional. Actividades de medición de Calidad del ciclo de vida de cada producto. Asignación de responsabilidades. Documentación Objetivos. Documentación mínima aceptable para cada producto:

137 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)

138 Plan SQA ANSI/IEEE Estándares, prácticas y normas Revisión y auditoría
Objetivos. Estándares, prácticas y normas de diseño, programación, medición y pruebas para cada producto. (Ejemplos: Open UP, MSF Model, etc) Revisión y auditoría Nivel mínimo aceptable de revisión y auditoría para cada producto:

139 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

140 Plan SQA ANSI/IEEE Pruebas Reporte de problemas y acciones correctivas
Actividades y pruebas no inlcuídas en la sección 4.2 (SVVP). Reporte de problemas y acciones correctivas Actividades y procedimientos para reportar, dar seguimiento y resolver problemas del producto y del proceso. Asignación de responsabilidades.

141 Plan SQA ANSI/IEEE Herramientas, técnicas, y metodologías
Objetivo y uso de herramientas de software, técnicas, y metodologías de apoyo al plan de SQA (Ejemplos: PSP, TSP, CMMi, etc…) Control del código Objetivo y uso de herramientas para dar mantenimiento, almacenar, conservar, y documentar diferentes versiones del código. NOTA: Puede ser parte del SCMP.

142 Plan SQA ANSI/IEEE Control de Medios Control de proveedores
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. Control de proveedores Estrategias para asegurar que los productos de software y los desarrolladores de proveedores externos cumplen con los estándares requeridos.

143 Plan SQA ANSI/IEEE Organización y retención de documentos y reportes
Criterios para seleccionar, conservar y proteger la documentación generada como parte del Plan de SQA. (Ejemplo: Kintana, The Test Oracle, etc…) Capacitación y entrenamiento Actividades para desarrollar las habilidades y actitudes necesarias del personal que participa en el Plan de SQA.

144 Plan SQA ANSI/IEEE Administración de riesgos
Actividades y procedimientos para identificar, monitorear, evaluar y controlar factores de riesgo para cada producto en el Plan de SQA.

145 Revisión del Software 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.

146 Revisión del Software 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.

147 Herramientas de la Calidad
Existen una infinidad de herramientas de calidad: Básicas De gestión De creatividad Estadísticas De diseño De medición

148 Calidad del Software en México
Análisis FODA de la industria del software en México Calidad 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

149 Evidencia 4 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.

150 Calidad del Software en México
Herramientas de la Calidad Diagrama de flujo Diagrama causa-efecto Diagrama de Pareto Hoja de chequeo Grafo de control Histograma Diagrama de dispersión Calidad del Software en México

151 Calidad del Software en México
Herramientas de la Calidad Diagramas de Causa-Efecto Calidad del Software en México Definir el efecto que se quiere analizar Determinar causas/subcausas (5 M: Método, Material, Maquinaria, Mano de obra, Medio ambiente) Revisar causas y su interacción Seleccionar las causas según su grado de contribución al efecto

152 Calidad del Software en México
Herramientas de la Calidad 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. Calidad del Software en México

153 Calidad del Software en México
Tarea Traer impresa al menos dos hojas en formato horizontal de 80 columnas x 25 Filas. Calidad del Software en México

154 Calidad del Software en México
Actividad Calidad del Software en México

155 Calidad del Software en México
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). Calidad del Software en México

156 Calidad del Software en México
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. Calidad del Software en México

157 Calidad del Software en México
Número complejo Suma, Resta, Multiplicación, división, igualdad y multiplicación por un escalar Calidad del Software en México (a,b) – (c,d) = (a-c)+(b-d)i

158 Calidad del Software en México
Actividad 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. Calidad del Software en México

159 Calidad del Software en México
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) Calidad del Software en México

160 Calidad del Software en México
Actividad División: (2+3i) / (3-5i) = ( i) 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. Calidad del Software en México

161 Calidad del Software en México
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 Calidad del Software en México

162 Calidad del Software en México
ELOC 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; } Calidad del Software en México

163 Calidad del Software en México
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 Calidad del Software en México

164 Calidad del Software en México
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. Calidad del Software en México

165 JUnit 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.

166 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.

167 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.

168 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.

169 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.

170 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 para indicar cuando se utilizan los métodos auxiliares

171 JUnit La clase de prueba no extiende de ninguna otra pero cada caso de prueba debe utilizar la Se recomienda realizar los casos de prueba de manera separada uno por uno y dejarlos siempre presente.

172 Calidad del Software en México
Evidencia 5 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. Calidad del Software en México

173 Calidad del Software en México
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% Calidad del Software en México

174 Calidad del Software en México
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% Calidad del Software en México

175 Calidad del Software en México
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% Calidad del Software en México

176 Calidad del Software en México
Pendientes Jueves 11 y Viernes 12 de Febrero Evidencia 5 Examen Escrito Teórico-Práctico Viernes 19. Calidad del Software en México

177 Calidad del Software en México
Referencias 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.  Calidad del Software en México

178 Calidad del Software en México
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 Calidad del Software en México

179 Dudas