Análisis estático con herramientas (K2 - entender, explicar , razonar)

Objetivos:

1. Retener defectos y errores típicos identificados mediante el análisis estático y compararlos con los de las revisiones dinámicas (K1).
2. Describir, mediante ejemplos, los beneficios típicos del análisis estático (K2).
3. Enumerar los defectos de código y diseño típicos que pueden identificarse mediante herramientas de análisis estático (K1).

Términos usados en este artículo: COMPILADOR, FLUJO DE CONTROL, FLUJO DE DATOS, ANÁLISIS ESTÁTICO.

Antecedentes.

El objetivo del análisis estático es detectar defectos en el código fuente del software y en los modelos de software. 

El análisis estático se realiza sin que la herramienta llegue a ejecutar el software objeto de la revisión; en las pruebas dinámicas SÏ se ejecuta el código de software.

El análisis estático permite identificar defectos difíciles de encontrar mediante pruebas dinámicas. 

Al igual que sucede con las revisiones, el análisis estático encuentra defectos en lugar e fallos.

Las herramientas de análisis estático analizan el código del programa (por ejemplo, el flujo de control y flujo de datos) y las salidas generadas, tales como HTML o XML.

Definición: 

Es aquella tarea que consiste en analizar un objeto de prueba (por ejemplo código fuente, script, [guión], ...requisito ) sin ejecutar el objeto de prueba.

Posibles aspectos a ser comprobados con análisis estático:

• Reglas y estándares de programación.
• Diseño de un programa (análisis de flujo de control).
• Uso de datos (análsis del flujo de datos).
• Complejidad de la estructura de un programa (métricas , por ejemplo número ciclomático).

El valor del análisis estático es:

1. La detección temprana de defectos antes de la ejecución de las pruebas.
2. Advertencia temprana sobre aspectos sospechosos del código o del diseño mediante el cálculo de métricas, tales como una medición de alta complejidad.
3. Identificación de defectos que no se encuentran fácilmente mediante pruebas dinámicas.
4. Detectar dependencias e inconsistencias en modelos de software, como enlaces.
5. Mantenibilidad mejorada del código y del diseño.
6. Prevención de defectos , si se aprende la lección en la fase de desarrollo. 

Entre los defectos habitualmente detectados por la herramienta de análisis estático se encuentran:

1. Referenciar una variable con un valor indefinido.
2. Interfaces inconsistentes entre módulos y componentes.
3. Variables que no se utilizan o que se declaran de forma incorrecta.
4. Código inaccesible (muerto).
5. Ausencia de lógica o lógica errónea (posibles bucles infinitos).
6. Construcciones demasiado complicadas.
7. Infracciones de los estándares de programación.
8. Vulnerabilidad de seguridad.
9. Infracciones de sintaxis del código y modelos de software.

Las herramientas de análisis estático generalmente las utilizan los desarrolladores (cotejar con las reglas predefinidas o estándares de programación) antes y durante las pruebas de componente y de integración, o durante la comprobación del código, para configurar las herramientas de análisis estático pueden producir un gran número de mensajes de advertencias que deben ser bien gestionados para permitir el uso más efectivo de la herramienta.

Los compiladores pueden constituir un soporte para los análisis estáticos, incluyendo el cálculo de métricas.

Aspectos Generales.

Todos los objetos de prueba deben tener una estructura formal.

• Esto es especialmente importante cuando se utilizan herramientas de pruebas.
• Con mucha frecuencia no se generan documentos formalmente.
• En la práctica, lenguajes de modelados, programación y de creación de scripts ("scripting languaje") cumplen con la regla, de la misma forma que algunos diagramas.

El análisis estático de un programa mediante el uso de herramientas se desarrolla con un esfuerzo menor que el necesario en una inspección.

• Por tanto con mucha frecuencia , el análisis estático se ejecuta de forma previa a que tenga lugar una revisión.
• Para detectar lógica ausente o errónea (bucles potencialmente infinitos).
• Para detectar construcciones excesivamente complicadas. Vulnerabilidad en el ámbito de la seguridad, interfaces inconsistentes, etc.

 El valor del análisis estático es la prevención de defectos:

• Para encontrar defectos tan pronto como sea posible antes de la ejecución de pruebas.
• Para advertir sobre aspectos sospechosos del código.
• Para detectar discrepancias en el diseño a través del cálculo de métricas como la medida de alta complejidad.
• Estos defectos pueden no ser encontrados fácilmente con pruebas dinámicas.
• Para comprobar la mantenibilidad del código o diseño. 

Herramientas que deben ser utilizadas :

• Compiladores y
• herramientas de análisis (analizadores).

Compilador:

• Detecta errores sintácticos en el código fuente de un programa.
• Crea datos de referencia del programa (por ejemplo lista de referencia cruzada, llamada jerárquica, tabla de símbolos).
• Comprueba la consistencia entre los tipos de variables.
• Detecta variables no declaradas y código inaccesible (código muerto).

Analizador: trata aspectos adiconales tales como:

• Convenciones y estándares.
• Métricas de complejidad.
• Acoplamiento de objetos.

Proceso de revisión (K2 - entender, explicar , razonar)

Objetivos:

1. Retener las actividades, funciones y responsabilidades de una revisión formal estándar (K1).
2. Explicar las diferencias entre los distintos tipos de revisión: revisión informal, revisión técnica, revisión guiada e inspección (K2).
3. Explicar los factores para llevar a cabo revisiones con éxito.

Términos usados en este artículo: CRITERIOS DE ENTRADA, REVISIÓN INFORMAL, INSPECCIÓN, MÉTRICA, MODERADOR, REVISIÓN ENTRE PARES, REVISOR, ESCRIBA, REVISIÓN TÉCNICA, REVISIÓN GUIADA.

Antecedentes.

 Los distintos tipos de revisiones varían desde informales, que se caracterizan porque los revisores carecen de instrucciones escritas, hasta sistemáticas, que se caracterizan por incluir la participación del equipo, resultados documentados de la revisión y procedimientos documentados para llevar a cabo la revisión. La formalidad de un proceso de revisión está relacionada con factores tales como la madurez del proceso de desarrollo, cualquier requisito legal o normativo o la necesidad de un rastro de auditoria.

La forma en la que se lleva a cabo una revisión dependerá de los objetivos de la revisión (por ejemplo, encontrar defectos, comprender, formar probadores y nuevos miembros del equipo, o debatir y decidir por consenso).

Actividades de una revisión formal (K1)

Una revisión formal típica incluye las siguientes actividades principales:


1.- Planificar:

• Definir los criterios de revisión.
• Seleccionar al personal.
• Asignar función.

2.- Definir los criterios de entrada y salida para más tipos de revisión formal (como por ejemplo, las inspecciones).

• Seleccionar qué partes de los documentos deben revisarse.

3.- Inicio:

• Repartir los documentos.
• Explicar los objetivos, procesos y documentos a los participantes.

4.- Comprobar los criterios de entrada (para tipos de revisión más formales).

5.- Preparación individual.

• Prepararse para la reunión de revisión repasando los documentos.

6.- Prestar especial atención a posibles defectos, preguntas y comentarios.
7.- Examen/evaluación/registro de los resultados (reunión de revisión):

• Debatir o registrar, mediante resultados documentados o actas (para tipos de revisión más  formales).
• Prestar especial atención a los defectos, hacer recomendaciones sobre cómo manejar los defectos, tomar decisiones al respecto.

8.- Examinar/evaluar y registrar durante reuniones físicas o de seguimiento de los grupos comunicaciones electrónicas.
9.-  Adaptar:

• Corregir los defectos detectados (normalmente a cargo del autor).
• Registrar el estado actualizado de los defectos (en revisiones formales).

10.- Hacer un seguimiento:

• Comprobar que los defectos han sido tratados.
• Recopilar métricas.

11.- Comprobar los criterios de salida (para tipos de revisión más formales).

Funciones y responsabilidades (K1)

Una revisión formal típica incluirá las siguientes funciones:

• Jefe: decide sobre la ejecución de las revisión, asigna el tiempo en los calendarios del proyecto y determina si se han logrado los objetivos de la revisión.
• Moderador: es la persona que lidera la revisión de documento o serie de documentos, incluyendo la planificación de la revisión, la celebración de la reunión y el seguimiento después de la reunión. En caso necesario, el moderador podrá mediar entre los distintos puntos de vista y , con frecuencia, es la persona de la que depende el éxito de la revisión.
• Autor: es el escritor o la persona con máxima responsabilidad de los documentos  a revisar.
• Revisores: se trata de personas con una experiencia especifica en el ámbito técnico o comercial (también denominados evaluadores o inspectores) que, tras la necesaria preparación, identifican y describen las conclusiones (por ejemplo, los defectos) sobre el producto objeto de la revisión. Los revisores deben seleccionarse de manera que representen distintas perspectivas y funciones en el proceso de revisión, y deben participar en todas las reuniones de revisión. 
• Escriba (o registrador): documenta todos los problemas, asuntos y puntos abiertos que se han identificado durante la reunión.

Abordar los productos de software o productos de trabajo asociados desde distintas perspectivas y utilizar listas de comprobación puede contribuir a la efectividad y eficiencia de las revisiones. Asi por ejemplo, disponer de una lista de comprobación basada en distintas perspectivas como las del usuario, el mantenedor, el probador o las operaciones, o contar con una lista de comprobación que incluya los problemas típicos de requisitos puede ayudar a desvelar problemas no detectados anteriormente.

Tipos de revisiones (K2)(IEE 1028)

Un único producto de software o producto de trabajo asociado puede ser objeto de varias revisiones. si se utiliza más de un tipo de revisión, el orden puede variar. Así por ejemplo, puede llevarse a cabo una revisión informal antes de la revisión técnica, o la inspección de una especificación de requisitos antes de una revisión guiada con el cliente. Las principales características, opciones y objetivos de los tpos de revisión disponibles son:

1.- Revisión Informal.

• Ausencia de un proceso formal.
• Puede adoptar la forma de programación por pares o una revisión por parte de un líder técnico de los diseños y el código.
• Los resultados pueden estar documentados.
• Su utilidad varía en función de los revisores.
• Objetivo principal: forma barata de obtener beneficios.

2.- Revisión guiada.

• Reunión liderada por el autor.
• Puede adoptar la forma de escenarios, simulacros o participación de grupo de pares.
• Sesiones abiertas.
•    Preparación opcional de revisores previa a la reunión.
•    Preparación opcional de un informe de revisión en el que se incluya la lista de conclusiones.
• Escriba opcional (distinto autor).
• Puede variar en la práctica desde bastante informal hasta muy formal.
• Objetivos principales:aprender , entender, encontrar defectos.

3.- Revisión técnica.

• Proceso documentado y definido para la detección de defectos que incluye la participación de pares y expertos técnicos, siendo la participación de la dirección opcional.
• Puede llevarse a cabo como una revisión entre pares sin la participación de la dirección.
• Idealmente está dirigida por un moderador formado (distinto del autor).
• Preparación previa a la reunión por parte de los revisores.
• Uso opcional de listas de comprobación.
• Elaboración de un informe de revisión en el que se incluya la lista de conclusiones, el veredicto de si el producto de software cumple los requisitos y , si procede, recomendaciones en base a las conclusiones.
• Puede variar en la práctica desde bastante informal hasta muy formal.
• Objetivos principales: debatir, tomar decisiones, evaluar alternativas, encontrar defectos , resolver problemas técnicos y comprobar la conformidad con las especificaciones, los planes, la normativa y los estándares.

4.- Inspección.

• Dirigida por un moderador formado (distinto del autor).
• Generalmente celebrada como un examen entre pares.
• Funciones definidas.
• Incluye una recopilación de métricas.
• Proceso formal basado en normas y listas de comprobación.
• Criterios de entrada y salida especificados para la aceptación del producto de software.
• Preparación previa a la reunión.
• Informe de inspección en el que incluye una lista de las conclusiones.
• Proceso de seguimiento formal.
•      Proceso de mejora de componentes opcional.
• Lector opcional.
• Objetivo principal: identificar defectos.

Las revisiones guiadas, las revisiones técnicas y las inspecciones pueden llevarse a cabo dentro de un mismo grupo de pares, es decir, entre colegas de un mismo nivel organizativo.

Este tipo de revisiones recibe el nombre de "revisión entre pares".

Factores de éxito de las revisiones (K2).

Entre los factores de éxito de las revisiones se encuentran los siguientes:

• Todas las revisiones tienen objetivos claros y predefinidos.
• Se cuenta con la participación de las personas adecuadas para los objetivos de la revisión.
• Los probadores constituyen revisores valiosos que contribuyen a la revisión y aprenden sobre el producto, lo que les permitirá preparar pruebas en una fase más temprana.
• Los defectos detectados son bienvenidos y se expresan de manera objetiva.
• se afrontan los problemas de personal y los aspectos psicológicos (por ejemplo, haciendo que sea una experiencia positiva para el autor).
• La revisión se lleva a cabo en una atmósfera de confianza ya que el resultado no se utilizará para evaluar a los participantes.
• se aplican las técnicas de revisión adecuadas para lograr los objetivos y para el tipo y nivel de productos de trabajo de software y los revisores.
• Se utilizan listas de comprobación o funciones si procede para aumentar la efectividad del proceso de identificación de defectos.
• Se ofrece formación sobre técnicas de revisión, especialmente por lo que respecta a las técnicas más formales como la inspección.
• La dirección respalda la implantación de un buen proceso de revisión (por ejemplo, asignando el tiempo adecuado a las actividades de revisión en los calendarios del proyecto).
• se hace hincapié en el aprendizaje y en la mejora del proceso.

Resumiendo:

1. Las revisiones se realizan con el objeto de mejorar la calidad del producto. (Las revisiones se utilizan para verificar la correcta transición de una fase a la siguiente, según está definido en el lado izquierdo del modelo V).
2. La detección temprana de errores ahorra costes.
3. En el transcurso de la revisiones se podrían detectar los siguientes defectos:

• Defectos en las especificaciones de requerimientos.
• Defectos en el diseño y arquitectura del software.
• Defectos en las especificaciones de interfaces.
• Mantenibilidad insuficiente.
• Desviaciones con respecto a estándares acordados (por ejemplo guías de programación).

Ventajas:

1. Costes más bajos y un alto potencial de ahorro.
2. Los defectos en la documentación son detectados y corregidos de forma temprana.
3. Los documentos de alta calidad mejoran el proceso de desarrollo.
4. Mejora el índice de comunicación / intercambio de conocimiento ("know-how").

Desventajas:

1. Se podrían presentar situaciones de tensión en el caso de enfrentamientos directos con el autor.
2. Los expertos involucrados en las revisiones deben adquirir conocimientos específicos del producto, es necesario una buena preparación.
3. Inversión considerable de tiempo (del 10% - 15% del presupuesto total).
4. Moderador y participantes influyen directamente en la calidad de la revisión.

Actividades de una revisión:

1.  Planificación (Definición de los criterios de la revisión, selección del personal, asignación de roles y tiempo en el calendarios del proyecto).
2. Definición de los criterios de entrada y salida para revisiones formales (selección de partes del documentos serán revisadas)
3. Inicio ("Kick-off") (Distribución de documentos, explicación de los objetivos, proceso y documentos).
4. Comprobación de los criterios de entrada (para revisiones más formales).
5. Preparación individual (identificación de elementos que requieren aclaración).
6. Identificación de defectos potenciales, preguntas y comentarios.
7. Reunión de revisión
8. Examen / Evaluación / Registro.
9. Reconstrucción ("rework") (el autor corrige cualquier defecto identificado por los inspectores, registro actualizado de defectos).
10. Seguimiento ("follow up") (comporbación de que los defectos han sido tratados / recogidos de métricas, segunda reunión de revisión si es necesario).
11. Comporbación de los criterios de salida (revisiones formales, V°B°).

Roles y responsabilidades:

1. Jefe de proyecto (o manager, inicia revisión , asigna tiempo, determona alcance de objetivos).
2. Moderador (o moderator, dirige la reunión, es mediador en una discusión, concluye, planifica la revisión, ejecuta la revisión, seguimientos porsteriores).
3. Autor (o author, redacta o es responsable de la revisión, expone su trabajo a la crítica y lleva a cabo los cambios recomendados).
4. Revisor (o reviewer, inspector o comprobador, detector de defectos, desviaciones, área con conflictos, muestran diferentes perspectivas y roles del proceso, asisten a todas las reuniones).
5. Escriba (o scribe, documentador universal, proyecta en reuniones las revisiones).
6. Lista de comprobación (checklist de seguimiento de las revisiones).               

Tipos de revisiones (IEE 1028)

1. Inspección ("inspection") (vetajas: sesiones formales y organizadas con roles bien definidos, requiere de actividades intensivas de preparación y seguimiento, son necesarios el moderador y el escriba, su objetivo principal es detectar defectos utilizando un método estructurado).
2. Revisión guiada ("walkthrough") (preparación de los revisores previa a la reunión, sesiones abiertas, visualización de escenarios, demos, participación entre pares, reunión dirigida por el autor, no es necesario un moderador, a lo largo de la presentación por parte del autor , los revisores tratan de detectar desviaciones y / o áreas en conflictos ya sea en documentos, diseños, o modelos de datos ).
3. Revisión técnica ("thecnical review") (¿es apto para el uso?, se requieren expertos externos, revisión entre pares o peer review, liderado por un moderador entrenado en su función no por el autor, preparación previa a la reunión por parte de los revisores, uso de lista de comprobación o lista de hallazgos, sus objetivos son: discutir durante la revisión, evaluar alternativas, detectar defectos, resolver problemas técnicos, comprobar la conformidad - estándares- planes- especificaicones- normativas ).
4. Revisión informal ("informal review") (iniciada por el autor, involucrados los revisores, no es necesario una reunión, resultados pueden plasmarse en una lista, se inicia con un solicitud de revisión de un documento o compañero de trabajo, revisión entre pares, fácil de ejecutar, rentable, no requiere protocolo).
5. Revisión de Gestión - Proceso de desarrollo de SW (Cmmi, ISO/IE 15504, TPI ).
6. Documentos / Productos.

Factores de éxito de una revisión:

1. Las revisiones deben ser orientadas al logro de los objetivos.
2. El autor del objeto revisado debe ser motivado de una forma positiva por la revisión.
3. Uso sistemático de las técnicas y plantillas implantadas.
4. Uso de listas de comporbación mejoran la eficiencia de la revisión.
5. El presupuesto de la revisión debe abarcar un 10% - 15 % del costo total de la revisión.
6. Utilizar las experiencias aprendidas y hacer uso de retroalimentación en la mejora contínua.
7. Se deben realizar en un ambiente de confianza.
8. Los probadores son revisores valorados que contribuyen con la revisión.
9. Involucrar a la gente adecuada en función de los objetivos  de la revisión.

Pregunta de examen:

24 Which of the following statements is NOT true:
a) inspection is the most formal review process
b) inspections should be led by a trained leader
c) managers can perform inspections on management documents
d) inspection is appropriate even when there are no written documents-->NOK, es la falsa
e) inspection compares documents with predecessor (source) documents

24 ¿Cuál de las siguientes afirmaciones no es verdadera :

a) la inspección es el proceso de  revisión mas formal.
b ) Las inspecciones deben ser dirigidos por un líder capacitado
c ) los administradores pueden llevar a cabo inspecciones en los documentos de gestión 
d ) la inspección es apropiado incluso cuando no hay documentos escritos-->NOK, es la falsa
e) inspección compara documentos con predecesoras ( ) documentos fuente

29 Unreachable code would best be found using:
a) code reviews-->OK
b) code inspections
c) a coverage tool
d) a test management tool
e) a static analysis tool


29 El código inaccecible, es mejor encontrarlo usando:
a) las revisiones de código-->OK
b) Las inspecciones de código
c) una herramienta de cobertura
d ) una herramienta de gestión de pruebas
e) una herramienta de análisis estático

32 Which expression best matches the following characteristics or review processes:
1. led by author
2. Undocumented
3. No management participation
4. Led by A trained moderator or leader
5. uses entry exit criteria

s) inspection
t) peer review
u) informal review
v) walkthrough

a) s = 4, t = 3, u = 2 and 5, v = 1
b) s = 4 and 5, t = 3, u = 2, v = 1-->OK
c) s = 1 and 5, t = 3, u = 2, v = 4
d) s = 5, t = 4, u = 3, v = 1 and 2
e) s = 4 and 5, t = 1, u = 2, v = 3

32 ¿Qué expresión se adapta mejor a los siguientes procesos  o características de revisión :
1. liderado por el autor
2. indocumentados
3. Sin la participación de la gestión
4. dirigido por un moderador o líder entrenado
5. utiliza criterios de salida de entrada

s) inspección
t) la revisión por pares
u) revisión informal
v ) tutorial

a) s = 4, t = 3, u = 2 and 5, v = 1
b) s = 4 and 5, t = 3, u = 2, v = 1-->OK
c) s = 1 and 5, t = 3, u = 2, v = 4
d) s = 5, t = 4, u = 3, v = 1 and 2
e) s = 4 and 5, t = 1, u = 2, v = 3

Técnicas estáticas y el proceso de pruebas (K2 - entender, explicar , razonar)

Objetivos:

1. Reconocer los productos de trabajo de software que pueden estudiarse en base a las distintas técnicas (K1).
2. Describir la importancia y el valor de emplear técnicas estáticas para evaluar los productos de trabajo de software (K2).
3. Explicar la diferencia entre técnica estáticas y técnicas dinámicas, teniendo en cuenta los objetivos, los tipos de defectos a identificar y la función de estas técnicas en el marco del ciclo de vida del software (K2).

Términos usados en este artículo:PRUEBAS DINÁMICAS , PRUEBAS ESTÁTICAS.

Antecedentes.

Al contrario que las pruebas dinámicas, que exigen la ejecución de software, las técnicas de pruebas estáticas se basan en el examen manual (revisiones) y en el análisis automatizado (análisis estático) del código o de cualquier otra documentación del proyecto sin ejecutar el código.

Las revisiones constituyen una forma de probar los productos de trabajo del software (incluyendo el código) y pueden realizarse antes de ejecutar las pruebas dinámicas. Los defectos detectados durante las revisiones al principio del ciclo (por ejemplo, los defectos encontrados en los requisitos)  a menudo son mucho más baratos de eliminar que los detectados durante las pruebas realizadas ejecutando el código.

Una revisión podría hacerse íntegramente como una actividad manual, pero también existen herramientas de soportes.

La principal actividad manual consiste en examinar un producto de trabajo y hacer comentarios al respecto. Cualquier producto de trabajo de software puede ser objeto de una revisión como por ejemplo:

1. Las especificaciones de requisitos , 
2. Las especificaciones de diseño,
3. El código, 
4. Los planes de pruebas, 
5. Las especificaciones de pruebas,
6. Los casos de pruebas ,
7. Los guiones de pruebas, 
8. Las guías de usuario o las páginas web.

Los beneficios de las revisiones incluyen la detección y corrección temprana de defectos, el desarrollo de mejoras de productividad, la reducción de los tiempos de desarrollo, el ahorro de tiempo y dinero invertido en pruebas, el menor coste de la vida, menos defectos y comunicación mejorada. Las revisiones pueden encontrar omisiones , por ejemplo,, en requisitos, que no suelen encontrarse en pruebas dinámicas.

Las revisiones, el análisis estáticos y las pruebas dinámicas tienen  el mismo objetivo:

1. Identificar defectos.
2. Se trata de procesos complementarios.
3. Las distintas técnicas pueden encontrar distintos tipos de defectos de una manera eficiente y efectiva,
4. En comparación con las pruebas dinámicas , las técnicas estáticas localizan las causas o los fallos (defectos) más que los propios fallos.

Entre los defectos típicos que resultan más fáciles de localizar en revisiones que en las pruebas dinámicas se incluyen: 

1. Desviaciones de los estándares,
2. Defectos de requisitos,
3. Defectos de diseño, 
4. Mantenibilidad insuficiente y
5. Especificaciones de interfaz incorrectas.

Resumiendo:

• Las técnicas estáticas de pruebas comprenden varios métodos que no ejecutan el componente o sistema objeto de la prueba.
• Las pruebas estáticas incluyen:

1.     Revisiones ("reviews") (actividad manual).
2.     Análisis estático ("static analysis") (actividad basada en herramientas, ejemplo Sonar, JSmeter).

• Las técnicas estáticas complementan los métodos dinámicos:

1.    Las pruebas estáticas detectan causas de los fallos (defectos) en lugar de fallos.
2.    Los conceptos también son analizados, no sólo el código ejecutable.
3.    Los defectos / desviaciones son detectados en una fase temprana antes de que sean implementados en el código.
4.  Las pruebas estáticas pueden descubrir defectos que no fueron detectables en las pruebas dinámicas.

• Documento de alta calidad conducen a productos de alta calidad.

1.    Incluso si una especificación revisada no contiene ningún defecto, la interpretación de la especificación y creación del diseño pueden ser defectuosas.

Pregunta de examen:

18 What can static analysis NOT find?

a) The use of a variable before it has been defined

b) Unreachable (“dead”) code

c) Whether the value stored in a variable is correct-->OK

d) The re-definition of a variable before it has been used

e) Array bound violations

18 ¿Qué no puede encontrar el análisis estático?

a) El uso de una variable antes de que haya sido definida

b )código " muerto" inalcanzable 

c) Si el valor almacenado en una variable es correcta-->OK

d ) antes de que se ha utilizado la re- definición de una variable

e) Arreglos de reglas no permitidas.

Pruebas de mantenimiento (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar las pruebas de mantenimiento (pruebas a un sistema existente) con las pruebas de una aplicación nueva por lo que respecta a los tipos de pruebas, los desencadenantes de las pruebas y la cantidad de las pruebas (K2).  
2. Reconocer los indicadores de las pruebas de mantenimiento (modificación, migración y retirada) (K1).
3. Describir la función de las pruebas de regresión y el análisis de impacto en el mantenimiento.

Términos usados en este artículo: ANÁLISIS DE IMPACTO, PRUEBAS DE MANTENIMIENTO.

Antecedentes.

Una ves desplegado, un sistema de software suele estar en servicio durante años o décadas. Durante todo ese tiempo, el sistema , sus datos de configuración o su entorno son objeto de frecuentes modificaciones o ampliaciones. La planificación anticipada de versiones es crucial para el éxito de las pruebas de mantenimiento. Debe realizarse una distinción entre versiones planificadas y arreglos urgentes. Las pruebas de mantenimiento se realizan en un sistema operativo existente, y se activan a partir de modificaciones, casos de migración o la retirada del software o del sistema.

 Entre las modificaciones se incluyen modificaciones de mejora planificadas (como por ejemplo, en base a las versiones), modificaciones correctivas y de emergencia y modificaciones de entorno, tales como actualizaciones previstas de sistema operativo previsto o bases de datos, actualizaciones previstas de software comercial de distribución masiva, o parches para corregir vulnerabilidades recientemente expuestas o descubiertas en el sistema operativo.

Las pruebas de mantenimiento para retirada de un sistema pueden incluir pruebas de migración de datos o archivos si se requieren largos períodos de retención de datos.

Además de probar lo que se ha modificado, las pruebas de mantenimiento incluyen pruebas de regresión ampliadas a partes del sistema que no han sido objeto de modificaciones. El alcance de las pruebas de mantenimiento variará en función de riesgos de la modificación, el tamaño del sistema existente y las dimensiones de la modificación. En función de las modificaciones , las pruebas de mantenimiento podrán realizarse en todos o en cualquier nivel de prueba y en todos o en cualquier tipo de prueba. La determinación de cómo el sistema existente podrá verse afectado por las modificaciones recibe el nombre de análisis de impacto y sirve para ayudar a decidir cuántas pruebas de regresión son necesarias. El análisis de impacto puede utilizarse para establecer el juego de pruebas de regresión.

Las pruebas de mantenimiento pueden resultar difíciles en caso de que no se disponga de especificaciones, o éstas estén desactualizados, o no haya probadores con conocimiento de dominio disponible.  

Evolución del software.

La flexibilidad de los sistemas de software es una de las principales razones por la que más y más software se incorporan a los sistemas grandes y complejos. Una vez que se decide adquirir hardware, es muy costoso hacer cambios en su diseño. sin embargo, se pueden hacer cambios al software en cualquier momento durante o después del desarrollo del sistema. aún cambios importantes son todavía más económicos que los correspondientes de los sistemas hardware.

Históricamente, siempre ha existido una separación entre el proceso de desarrollo y el proceso de evolución del software (mantenimiento del software). La gente considera el desarrollo de software como una actividad creativa en la cual un sistema de software se desarrolla desde un concepto inicial hasta que se pone en funcionamiento. sin embargo, a veces consideran el mantenimiento del software como algo aburrido y sin interés. aunque los costos de "mantenimiento" son a menudo varias veces los costos iniciales de desarrollo, el proceso de mantenimiento se considera a veces menos problemático que el desarrollo del software original.

Esta distinción entre el desarrollo y el mantenimiento es cada vez más irrelevante. Hoy en día, pocos sistemas de software son completamente nuevos, lo que implica que tiene más sentido ver el desarrollo y el mantenimiento como actividades continuas. Más que dos procesos separados, es más realista considerar a la ingeniería del software como un proceso evolutivo en el cual el software se cambia continuamente durante su periodo de vida como respuesta a los requerimientos cambiantes y necesidades del usuario. 

Resumiendo:

Pruebas posteriores a la aceptación del producto:

• El cliente ha aprobado el producto y es puesto en producción.

1.     El ciclo de desarrollo inicial, incluidos las pruebas asociados, ha sido completado.

• El mismo software se encuentra al comienzo del ciclo de vida:

1.    Será utilizado por muchos años, será ampliado.
2.    Es muy probable que aún contenga defectos, por lo tanto será modificado y corregido.
3.    Necesitará adaptarse a nuevas condiciones y deberá integrarse a nuevos entornos.
4.    Necesitará cambiar o extender los datos de configuración.
5.    Será retirado, se extraerá del entorno de producción.

CUALQUIERA NUEVA VERSIÓN DEL PRODUCTO, CADA NUEVA ACTUALIZACIÓN Y CADA CAMBIO DEL SOFTWARE REQUIERE PRUEBAS ADICIONALES.

Configuración:

• Composición de un componente o de un sistema definido como el número, naturaleza e interconexiones de las partes que lo constituyen.

Análisis de impacto:

• Valoración del cambio en las capas de documentación de desarrollo, documentación de pruebas y componentes, con el objeto de implementar un cambio dado en requisitos especificados.

Pruebas de mantenimiento:

1. Pruebas de los cambios en un sistema en operación o el impacto de un entorno modificado para un sistema en operación.

• El mantenimiento de software cubre dos campos diferenciados:

1.     Mantenimiento tal como : corrección de errores o implementación de "hot - fixes" que han sido parte de la versión inicial del software  
2.     Distribución de software planificados : adaptaciones como resultado una modificación / cambio del entorno o nuevos requisitos del cliente.

• Alcance de las pruebas de mantenimiento.

1.    "Hot Fixes" y la corrección de defectos requiere la recepción de pruebas ("re - test").
2.    La ampliación de la funcionalidad requiere nuevos casos de prueba.
3.    La migración a otra plataforma requiere pruebas operativas ("operational testing").
4.    Adicionalmente, son necesarias pruebas de regresión intensivas.

• El alcance de las pruebas depende del impacto del cambio.

1.    El análisis de impacto se utiliza para determinar las áreas afectadas con el objeto de decidir la cantidad de pruebas de regresión.
2.    Pueden ocurrir problemas si la documentación del software antiguo falta o es incompleto.

• Retirada.

1.    Las pruebas tras la retirada del software puede incluir:

•      Pruebas de migración de datos.
•      Verificación del archivo de datos y programas.
•     Pruebas en paralelo de sistemas nuevo y su antecedente.