Este documento presenta información sobre la prevención de defectos en software. Describe diferentes tipos de defectos como defectos de especificaciones, diseño, código y documentación. También cubre técnicas para prevenir defectos como revisiones de código, control de versiones y tener un programador senior realizando el lanzamiento a producción. Finalmente, presenta dos modelos para la inspección de software, el modelo de Fagan y el modelo de Gilb, los cuales incluyen pasos como planeación, inspección, registro y seguimiento.
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010SaraEAlcntaraR
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010 correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010SaraEAlcntaraR
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010 correspondiente a la Unidad II.- Ingeniería de Requisitos del Saber Ingeniería del Software II, dictado en el PNF en Informática de la UPTP "Luis Mariano Rivera".
Objetivo: Analizar la especificación a fin de garantizar que todos los requerimientos sean enunciados sin ambigüedades; detectar y corregir las inconsistencias, las omisiones y los errores, y que los productos del trabajo se presentan conforme a los estándares establecidos para el proceso, el proyecto y el producto.
Una metodología de Desarrollo es como una receta de cocina, hay se visualizan los requerimientos, las herramientas y técnicas a utilizar para crear el platillo (software). De su buen eso depende el éxito del proyecto.
Metricas del proyecto de Software - introduccionJose Diaz Silva
Introducción al manejo de las métricas de proyectos de software, considerando los aspectos de tamaño y los elementos de funcionalidad. Se explora la diferencia entre error y defecto , aclarando los conceptos de medida, medición, métrica e indicador. De la misma manera se exploran las métricas privadas y las públicas. Las ventajas y desventajas de estas métricas son mencionadas
Objetivo: Analizar la especificación a fin de garantizar que todos los requerimientos sean enunciados sin ambigüedades; detectar y corregir las inconsistencias, las omisiones y los errores, y que los productos del trabajo se presentan conforme a los estándares establecidos para el proceso, el proyecto y el producto.
Una metodología de Desarrollo es como una receta de cocina, hay se visualizan los requerimientos, las herramientas y técnicas a utilizar para crear el platillo (software). De su buen eso depende el éxito del proyecto.
Metricas del proyecto de Software - introduccionJose Diaz Silva
Introducción al manejo de las métricas de proyectos de software, considerando los aspectos de tamaño y los elementos de funcionalidad. Se explora la diferencia entre error y defecto , aclarando los conceptos de medida, medición, métrica e indicador. De la misma manera se exploran las métricas privadas y las públicas. Las ventajas y desventajas de estas métricas son mencionadas
Pergamo Software para Gestión Integral de Bibliotecas y Centros de DocumentaciónDeysi Yadira
Un Software para la automatización integral de bibliotecas que combina facilidad y simplicidad en el uso con profesionalidad.
Concebido con estrecha participación de bibliotecarios.
Desarrollado en Argentina y presente en el mercado desde 1998.
Orientado a brindar respuesta a las particularidades y necesidades comunes de todo tipo de bibliotecas (públicas, universitarias, populares, escolares, etc.) en y que cuenta con instituciones en todo el país y en el exterior.
Origen y evolucion de la ingenieria industrialRoberlozano
EN ESTA PRESENTACIÓN SE EXPONE TODO LO REFERENTE A LA HISTORIA DE LA INGENIERÍA INDUSTRIAL, PARTIENDO DESDE SUS ORÍGENES, Y CULMINANDO CON LO QUE ES HOY EN DÍA
Esta presentación es parte del contenido del curso de Programación Avanzada impartido en la Universidad Rafael Landívar durante el año 2015.
Incluye los temas:
• Técnicas de programación
• Estilo y codificación
• Documentación
• Depuración
• Pruebas
Creado por Ing. Alvaro Enrique Ruano
El desarrollo y mantenimiento de aplicaciones empresariales, más que una profesión se ha convertido en todo un arte al darles soporte y mantenimiento, cobra mayor importancia y trascendencia cuando: diferentes desarrolladores modifican la funcionalidad, se utilizan versiones de API´s y frameworks diferentes sobre la misma aplicación sólo porque a "alguien" se le ocurrió, se duplica código por el desconocimiento de la aplicación y por si fuera poco....... existe código muerto en las diferentes capas de la aplicación (si es que se puede identificar alguna) una situación que nunca sucede en nuestro ámbito. Si el panorama no fuera ya de por si complejo, el realizar las pruebas (de todos los módulos de la aplicación) y promover la liberación de una nueva funcionalidad resulta en ocasiones más costoso en tiempo y recursos que la nueva funcionalidad por si misma. La presente sesión demuestra por medio de casos de éxito las ventajas que proporciona el someter aplicaciones existentes y nuevas sobre un proceso de integración contínua estandarizando: el versionado del código, el uso de herramientas de construcción, la automatización de pruebas, la evaluación de código y promoción de nuevas liberaciones de aplicaciones productivas. Todo esto sobre un ciclo iterativo, controlado y auditado para un objetivo final, producir aplicaciones con calidad de código.
Solución de problemas y ciclo de vida del desarrollo de softwareAlvaro Enrique Ruano
Esta presentación es parte del contenido del curso de Programación Avanzada impartido en la Universidad Rafael Landívar durante el año 2015.
Incluye los temas:
* Abstracción y resolución de problemas
* Introducción al ciclo de vida del software
Creado por Ing. Alvaro Enrique Ruano
Presentacion sobre cómo elaborar procesos de QA en proyectos de desarrollo de software desde una etapa temprana hasta la validación final del software.
Se realizará caso práctico con Selenium.
EL MODELO EN CASCADA DE INGENIERIA DE SOFTWARE UEB
Prevención de defectos
1. Escuela Politécnica Nacional
Facultad de Ingeniería de Sistemas
CALIDAD DE SOFTWARE
Prevención de Defectos
Grupo 3
Integrantes:
● Ibadango Dina
● Ordoñez Hernán
● Roldan Marcelo
● Suquillo Diego
2. ¿Qué es prevenir?
● “antes de venir”,
actuar para que un
problema no aparezca
o al menos para que
disminuyan sus efectos.
3. ¿Qué es defecto?
● Es el resultado de un
fallo o deficiencia
durante el proceso de
creación de programas
de ordenador o
computadora.
4. Clasificación de defectos
● Defectos críticos
Aquellos que violan leyes,
agreden al consumidor o
hacen inservible al
producto.
5. Clasificación de defectos
● Defectos mayores
Disminución en el
correcto funcionamiento
o utilización del producto
y es notado por el
consumidor
6. Clasificación de defectos
● Defectos menores
Disminución leve en el
correcto funcionamiento
o utilización del producto,
probablemente no lo note
el consumidor.
7. TIPOS DE DEFECTOS
1 DEFECTOS EN ESPECIFICACIONES / REQUISITOS
● Requisitos o
especificaciones
● Funcionalidad
● Interfaz de Usuario,
Software y Hardware
● Descripción funcional
8. TIPOS DE DEFECTOS
2 DEFECTOS DE DISEÑO
● Los errores pueden
ocurrir enalgoritmos,
lógica de control,
estructuras de datos,
acceso a bases de
datos, formularios
deentrada y salida,
descripción de la
interfaz.
9. TIPOS DE DEFECTOS
2 DEFECTOS DE DISEÑO
● Hardware, software e interfaz
de usuario
● Descripción Funcional
● Comunicaciones entre procesos
● Definición de datos
● Diseño del módulo
● Descripción de la lógica
● Chequeo de errores
● Estándares
10. TIPOS DE DEFECTOS
3 DEFECTO DE CÓDIGO
● Errores causados por
una pobre comprensión
del diseño o mala
elección de
lasestructuras de datos
y algoritmos, o errores
de lógica o sintaxis.
11. TIPOS DE DEFECTOS
3 DEFECTO DE CÓDIGO
● Errores o equivocaciones en
la implementación de un
programa.
● Lógica
● Problemas de computación
● Problemas de manipulación
de datos
● Implementación / interfaz del
módulo
● Estándares
12. TIPOS DE DEFECTOS
4 DEFECTOS DE DOCUMENTACIÓN
● Errores en manuales,
instrucciones de
instalación,
demostraciones, todos
ello centrado al cliente.
13. TIPOS DE DEFECTOS
5 DEFECTOS DEL ENTORNO DE APOYO
● Software de pruebas
● Hardware de pruebas
● Herramienta de
desarrollo
● Software de
integración
14. Prevención de defectos
● Hacer un plan para
evitar que los fallos que
se puedan presentar
durante la etapa de
desarrollo y
codificación de un
programa, produzca
consecuencias graves
que afecten la calidad
del producto.
27. MODELOS
Modelo de Fagan (1976)
Revisión sistemática de
código o de artefactos
relacionados, tales como
requisitos y documentos de
diseño.
28. Para Fagan es necesario un equipo de inspección
que consiste en un:
● Asesor
● Lector
● Inspector
● Autor
29. Proceso de Inspección de Fagan
Consta de los pasos siguientes, cada uno con
objetivos específicos:
● Planeamiento
● Descripción
● Preparación
● Inspección
● Reanudación
● Seguimiento.
30. Planificación
Cuando los materiales para
ser inspeccionados pasan
por los criterios de entrada.
31. Descripción
● Se dan instrucciones
previas a los miembros
del equipo del material
a ser inspeccionado, y
se asignan los papeles.
32. Preparación
Los miembros del equipo
estudian el material
individualmente para
prepararse para satisfacer
los papeles asignados.
33. Inspección
El equipo realiza una reunión
de inspección para encontrar
defectos, y registrarlos.
Cuyo propósito es la detección
de los defectos o de
violaciones de estándares, y
cualquier tentativa.
34. Remodelar
El autor revisa el resumen de los defectos detectados,
clarificando cuales son realmente defectos y que son mal
entendidos en el proceso de la inspección.
35. Seguimiento
El asesor o el equipo
entero de inspección
repasa el producto otra
vez, para asegurar que
todos los arreglos son
eficaces y de que no se ha
introducido ningún
defecto adicional durante
la remodelación.
36. MODELOS
Modelo de Tom Gilb (1993)
El modelo que describen se
basa, obviamente, en el
trabajo de Fagan; sin
embargo, también incorpora
otros pasos. “Un paso
adicional es el proceso de la
prevención del defecto”.
37. Proceso de Inspección de Gilb
El modelo de inspección de Gilb consiste en los siguientes
pasos:
● Planeamiento y documentos de entrada
● Reunión rápida
● Inspección o comprobación
● Registro
● Tormenta de ideas
● Edición
● Seguimiento
● Salida
38. Planeamiento y documentos de entrada
Líder determina a los
participantes de la
inspección y designa a 3-4
como inspectores.
Elabora las listas
necesarias de la
documentación, las reglas,
los estándares y programa
las reuniones.
39. Reunión rápida
Escala de tiempo de realización para la inspección y
otras instrucciones a los inspectores y al autor.
41. Registro
La reunión de registro
(máximo 2 horas) donde
se mencionan todos los
defectos y su aceptación o
rechazo en el registro
general de la inspección.
42. Tormenta de ideas
Donde se trata de dar solución o ideas a los defectos
encontrados para su remodelación.
43. Edición
Se espera que el autor emprenda la edición del
análisis y la acción de corrección.
44. Seguimiento
El líder de la inspección realiza un seguimiento a los
cambios que debe realizar el autor manteniendo un
contacto con este.
45. Salida
Se entrega el producto y está listo para la salida de la
inspección cuando todos los puntos discutidos en la
tormenta de ideas y el registro se han corregido y
trabajado satisfactoriamente
48. En general es imposible escribir programas sin
defectos.Sin embargo, es posible mejorar la calidad
del software
49. Eliminación de Defectos
● Revisiones de diseño
(“design reviews”)
● Verificación de programas
(“program verification”)
● Inspección de código
(“code inspections”)
● Pruebas del sistema
(“system testing”)
50. Tolerancia a Defectos
●
● Tolerancia a defectos
completa
●
● Degradación aceptable o
falla suave
●
● Parada segura
51. ● El grado de tolerancia necesario en el sistema
depende de la aplicación
52. Redundancia
La tolerancia de fallos se
basa en la redundancia. Se
utilizan componentes
adicionales para:
● detectar los fallos y
● recuperar el
comportamiento
correcto.
La inspección ha sido acertada, probada en varios usos industriales y está muy difundida en la industria delSoftware, por estos motivos las inspecciones de Fagan han marcado un camino hacia el mejoramiento del proceso de software.
El asesor desempeña un papel muy importante de la dirección y debe asegurarse de que la preparación del equipo se centre en la detección de defectos sin desviarse (por ejemplo, sugiriendo correcciones necesarias o resaltar detalles importantes). El lector es parafrasear (explicar y leer) el producto que es inspeccionado a un paso razonable. Si no, el equipo puede inspeccionar muy rápido y superficialmente lo inspeccionado. El autor en las reuniones de la inspección, generalmente se considera beneficiosa, porque (1) el autor puede asistir al equipo de la inspección para entender mejor el producto, y (2) el autor está preparado para entender la naturaleza exacta de los defectos en los hallazgos del equipo. El papel de un inspector es examinar el software desde el punto de vista de un usuario. El inspector es el responsable de velar por los intereses del usuario. Un equipo que realice una inspección es más productivo cuando sus miembros trabajan en armonía y satisfacen los papeles asignados.
(por ejemplo, el código fuente compila con éxito sin errores de sintaxis), miembros del equipo de inspección se seleccionan, y se establecen los horario de la inspección (por ejemplo, tiempo y lugar).
Entonces, el autor debe modificar para corregir los defectos
El asesor o el equipo entero de inspección repasa el producto otra vez. Muchas variaciones se han propuesto sobre el método de inspección de Fagan. Sin embargo, se elige este método en el mundo porque es el más aplicable en la industria del software.
Uno de los textos más comprensivos en inspecciones del software es el de Gilb y de Graham. El modelo que describen se basa, obviamente, en el trabajo de Fagan; sin embargo, también incorpora otros pasos. “Un paso adicional es el proceso de la prevención del defecto explicada por Jones” [46]. Hay tres papeles definidos en este tipo de inspección. El líder (Jefe de Aseguramiento de Calidad) está en el puesto principal del proceso y es el que realiza el planeamiento y garantiza el funcionamiento de la inspección. El autor del documento es un participante requerido en la reunión de registro y debe ser parte de la verificación. Los miembros restantes del equipo son los inspectores, que su deber es simplemente encontrar y divulgar defectos en el documento o en el artefacto. Durante la reunión de registro, se asigna el papel de escribano a uno de los inspectores y registra los defectos encontrados durante la inspección. El modelo de inspección de Gilb consiste en los siguientes pasos:
El líder comienza con asegurarse que los criterios de inicialización están satisfechos. Esto asegura que la inspección esté con los documentos fundamentales y no se pierda ningún detalle. Es seguido por el planeamiento de la inspección, donde el líder determina... Esta fase produce un plan maestro para la inspección entera.
El Jefe de Aseguramiento de Calidad organiza una rápida reunión de 15 minutos, donde él da una escala... , explica en términos generales la estructura de la documentación y el propósito de la inspección
Cuando los inspectores han acabado la comprobación en la fecha convenida el líder de la inspección organiza
Una reunión de tormenta de ideas (5-30 minutos) sigue poco después de la reunión de registro.
De la descripción anterior se puede ver la diferencia entre este proceso de Tom Gilb y el de Fagan, es la etapa de la detección de los defectos, es decir durante la fase individual por cada inspector.