1. UNIVERSIDAD AUTONOMA DE CHIHUAHUA
FACULTAD DE INGENIERIA
Análisis de correctitud
Modelado y análisis de requerimientos del
software
Equipo No. 4
225654 Canales Tarango Irving Manuel
225673 Najera Chavira Daniel Giovanni
225690 Ibarra Garcia Carlos Antonio
Octubre - 2011
El documento pretende describir y recordar temas anteriores que hemos visto durante la
carrera, en el documento usted observara diagramas, se dará una descripción y se darán
referencias para indagar mas en el tema.
3. Objetivo
El objetivo es indagar en los temas de la exposición la mayoría de la información se
encuentra dentro de temas importantes que corresponden a la ingeniería de software, los
apartados son sumamente precisos se recolecto un gran numero de información con el
objetivo de extraer y asociar lo mejor para que el interesado comprenda de una mejor
manera los temas.
Introducción
Al momento en que analizamos inspeccionamos con la finalidad de entender las
propiedades y las capacidades de ese algo en el que indagamos.
En términos de software el análisis caracteriza a un grupo de ejecución. También está
basado en un modelo del producto en lugar del propio producto, así abstrae elementos
que podrían ser cruciales.
Desarrollo
Analisis de correctitud (Correctness):
Un programa es funcionalmente correcto si se comporta de acuerdo a la especificación de
las funciones (especificación de requerimientos funcionales) que debería proveer. Esta
definición de correctitud asume que existe una especificación de requerimientos
funcionales del sistema y que es posible determinar en forma no ambigua si las cumple o
no. Se presentan diversas dificultades cuando no existe dicha especificación, o si existe
pero está escrita informalmente utilizando, por ejemplo, lenguaje natural por lo que es
posible que contenga ambiguedades.
La correctitud es una propiedad matemática que establece la equivalencia entre el
software y su especificación, por lo que cuanto más riguroso se haya sido en la
especificación, más precisa y sistemática podrá ser su evaluación. Posteriormente se
verá que la correctitud puede ser evaluada mediante diversos métodos, algunos de
enfoque experimental como las pruebas, otros de enfoque analítico como verificación
formal de la correctitud. Es de notar que esta definición de correctitud no toma en
consideración el que la especificación en sí misma puede ser incorrecta por contener
inconsistencias internas, o no corresponder de forma adecuada a las necesidades para
las que fue concebido el programa.
Análisis Estático (Somerville, 2005)
Un análisis estático es la examinación de un programa sin ejecutarlo. Las inspecciones a
menudo están dirigidas por listas de comprobación de errores y heurísticas que identifican
errores comunes en diferentes lenguajes de programación.
Por lo tanto, es una técnica que se aplica directamente sobre el código fuente tal cual, sin
transformaciones previas ni cambios de ningún tipo. La idea es que, en base a ese código
fuente, podamos obtener información que nos permita mejorar la base de código
manteniendo la semántica original.
3
4. El analizador estático de código recibirá el código fuente de nuestro programa, lo
procesará intentando averiguar qué es lo que queremos que haga y nos dará sugerencias
con las que podamos mejorar ese código.
Básicamente al realizar un análisis estático, se obtiene una facilidad de mantenimiento y
de desarrollo, ya que su objetivo es minimizar la deuda técnica del proyecto.
Algunas comprobaciones que se pueden detectar mediante análisis estático son:
Encontrar partes de codigo que puedan
●Reducir el rendimiento.
●Provocar errores en el software.
●Complicar el flujo de datos.
●Tener una excesiva complejidad.
●Suponer un problema en la seguridad.
Clase de defecto Comprobación del análisis estático
Defectos de datos Variables utilizadas antes de su inicialización.
Variables declaradas pero nunca utilizadas.
Variables asignadas dos veces pero nunca
utilizadas entre asignaciones.
Posibles violaciones de los límites de los
vectores.
Variables no declaradas.
Defectos de control Código no alcanzable.
Saltos incondicionales en bucles.
Defectos de entrada/salida Las variables salen dos veces sin intervenir
ninguna asignación.
Defectos de interfaz Inconsistencias en el tipo de parámetros.
Inconsistencias en el número de parámetros.
Los resultados de las funciones no se utilizan.
Existen funciones y procedimientos a los que
no se les llaman.
Defectos de gestión de almacenamiento Punteros sin asignar.
Aritmética de punteros.
4
5. Las etapas implicadas en el análisis estático comprenden:
1.Análisis del flujo de control. Esta etapa identifica y resalta bucles con múltiples
salidas o puntos de entrada y código no alcanzable. El código no alcanzable es
código que se salta con instrucciones goto no condicionales o que está en una
rama de una sentencia condicional en la que la condición nunca es cierta.
2.Análisis del uso de los datos. Esta etapa revela cómo se utilizan las variables del
programa. Detecta variables que se utilizan sin inicialización previa, variables que
se asignan dos veces y no se utilizan entre asignaciones, y variables que se
declaran pero nunca se utilizan. El análisis del uso de los datos también descubre
pruebas inútiles cuando la condición de prueba es redundante. Las condiciones
redundantes son condiciones que son siempre ciertas o siempre falsas.
3.Análisis de interfaces. Este análisis comprueba la consisitencia de las declaraciones
de funciones y procedimientos y su utilización. No es necesario si se utiliza para la
implementación un lenguaje fuertemente tipado como Java, ya que el compilador
lleva a cabo estas comprobaciones. El análisis de interfaces puede detectar errores
de tipos en lenguajes débilmente tipados como C. El análisis de interfaces también
puede detectar funciones y procedimientos que se declaran y nunca son llamados
o resultados de funciones que nunca se utilizan.
4.Análisis del flujo de información. Esta fase del análisis identifica las dependencias
entre las variables de entrada y salida. Mientras no detecte anomalías, muestra
cómo se deriva el valor de cada variable del programa a partir de otros valores de
variables. Con esta información, una inspección de código debería ser capaz de
encontrar valores que han sido calculados erróneamente. El análisis de flujo de
información puede tambien mostrar las condiciones que afectan al valor de una
variable.
5.Análisis de caminos. Esta fase del análisis semántico identifica todos los posibles
caminos en el programa y muestra las sentencias ejecutadas en dicho camino.
Esencialmente desenreda el control del programa y permite que cada posible
predicado sea analizado individualmente.
Los analizadores estáticos son particularmente valiosos cuando se utiliza un lenguaje de
programación como C. Este lenguaje no tiene reglas de tipo estrictas, y la comprobación
que puede hacer el compilador es limitada. Por lo tanto, es fácil para los programadores
cometer errorres, y la herramienta de análisis estático puede automáticamente descubrir
un gran numero de errores potenciales y reducir los costes de prueba de forma
significativa.
Por otro lado los lenguajes de programación modernos como Java han eliminado algunas
características propensas a error. Todas las variables deben ser inicializadas; no hay
sentencias goto, y la gestion de almacenamiento es automática.Esta aproximación para
evitar errores en llugar de detectarlos es mas efectiva a la hora de mejorar la fiabilidad del
programa.
Análisis manual
Deberíamos tratar de realizar el análisis manual cada vez que vayamos a crear una nueva
funcionalidad en nuestro software, preguntándonos en este caso si la arquitectura actual
nos permite implementarla con facilidad, si disponemos de las librerías adecuadas o si
podemos modificar la base de nuestro código para facilitar el desarrollo de esta nueva
funcionalidad. Es decir, lo reservaremos para situaciones concretas.
5
6. Análisis automatizado
puede ser realizado con una mayor periodicidad ya que no requiere de intervención
humana y, lo que es mejor, puede ser programado y repetido tantas veces como sea
necesario. Además obra con objetividad, siempre nos va a devolver la misma respuesta
ante el mismo código fuente de entrada.
(Exposito, 2010)
Simulación y prototipado
Las herramientas PRO/SIM (de prototipos y simulación) proporcionan al ingeniero del
software la capacidad de predecir el comportamiento de un sistema en tiempo real antes
de llegar a construirlo. Además, capacitan al ingeniero del software para desarrollar
simulaciones del sistema de tiempo real que permitirán al cliente obtener ideas acerca de
su funcionamiento, comportamiento y respuesta antes de la verdadera implementación.
Debemos ubicarnos en el ciclo de vida en espiral, a en la siguiente pagina remarcamos
donde nos encontramos como ingenieros de software:
6
7. Para recordar un poco de este ciclo colocamos lo siguiente, remarcando el tercer
punto:
Ventajas:
●Inclusión de de análisis de riesgos a lo largo del proceso
●Desarrollo de software = proceso evolutivo
●Uso de prototipos, uso de simulaciones
●El cliente ve evolucionar el proyecto
●Tratamiento del mantenimiento al mismo nivel que el desarrollo (se trata de otra
espiral más)
Problemas:
●Difícil de convencer al cliente de su utilidad (hay que realizar muchos tests y esto
cuesta dinero)
●Implantación muy compleja
●Necesita gran habilidad en la valoración de riesgos
●Método muy nuevo
7
8. Prototipado
Herramientas de gestión de prototipo
Los prototipos son utilizados ampliamente en el desarrollo de aplicaciones, para la
evaluación de especificaciones de un sistema de información, o para un mejor
entendimiento de cómo los requisitos de un sistema de información se ajustan a los
objetivos perseguidos.
Ciclo de vida con prototipado
Ventaja
●Mejora la comunicación analista - cliente
●Mejor identificación de los requerimientos del cliente
●Satisface la curiosidad del cliente (en seguida puede ver cosas)
Problemas
●Identificación del prototipo con el producto final
●Prototipo no reaprovechable
●Técnicas inapropiadas con el fin de prototipar más rápidamente
Verificacion del modelo
Uno de los mayores retos de a los que se enfrentan los proyectos de ingeneria es el
creciente tamano y la complejidad de los sistemas.
La verificación se hace para asegurar que:
- El modelo está programado correctamente
- Los algoritmos se han implementado correctamente
- El modelo no contiene errores, omisiones o errores
• La verificación asegura que la especificación es completa y que los errores no se han
implementado en la aplicación del modelo
8
9. • La verificación no asegura el modelo:
- Resuelve un problema importante
- Cumple con un conjunto específico de requisitos del modelo
- Refleja correctamente el funcionamiento del mundo real.
Verificacion formal y metodos formales
La verificación formal evalúa la exactitud de los algoritmos que se basa el sistema.
Verificación de software evalúa qué tan bien software satisface los requisitos definidos y la
verificación de los modelos evalúa la correctitud de los modelos. Los metodos formales se
basan en representaciones matematicas del software, normalmente como una
especificacion formal.
Los metodos formales requieren un análisis muy detallado de las especificacion del
sistema y del programa, y su uso consume a menudo tiempo y resulta caro.
Estos metodos formales se ocupan principalmente del analisis matematico de la
especificacion; de transformar la especificacion a una representacion mas detallada
semanticamente equivalente o de verificar formalmente que una representacion del
sistema es semanticamente equivalente a otra representacion.
Los metodos formales pueden utilizarse en diferentes etapas en el proceso V&V:
1.Puede desarrollarse una especficacion formal del sistema y analizarse
matematicamente para buscar inconsistencias. Esta tecnica es efectiva para
descrubir errores y omisiones de especificacion.
2.Puede verificarse formalmente, utilizando argumentos matematicos, que el codigo de
sistema software es consistente con su especificacion. Esto requiere una
especificacion formal y es efectiva para descubrir algunos errores de diseno y
programacion.
El objetivo final de la verificacion del modelo es que proporciona informacion precisa,
informacion sobre el sistema que se modela y hace que el sistema se utilice.
Conclusión
El equipo logro recordar procesos de la ingeniería de software que estudiamos en
semestres anteriores, indagamos de una manera mas profunda en procesos mas
específicos y nos dimos cuenta de que el buen modelado es parte fundamental para la el
proceso de desarrollo de software.
Recomendaciones
Queremos hacer la invitación a que vean la siguiente presentación http://
webdiis.unizar.es/~zarazaga/workPage/docencia/ingSoft1/trasparencias/is1_01.pdf y así
tener una mejor noción del por que de la materia y en que parte o mas bien dicho fase
nos estudiando la ingeniería de software.
9
10. Referencias
Jintao Pan (1999) Software testing ece.cmu.edu/. Recuperado el 2 de Octubre del 2011
http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/
Monzon Diaz, J.L Fernandez Sanchez (2006) Decimo congreso internacional de ingenieria
de proyectos ppooa.com.es/ Recuperado el 2 de Octubre del 2011 http://
www.ppooa.com.es/vmis.pdf
Somerville, I. (2005). INGENIERÍA DEL SOFTWARE. Séptima edición. Madrid: PEARSON
EDUCACIÓN.
Exposito, R. (2010). RaulExposito.com. Recuperado el 4 de Octubre del 2011, de http://
raulexposito.com/files/documentos/AnalisisEstaticoCodigo.pdf
E-Clases (2004) eclases.tripod.com/ Recuperado el 3 de octubre del 2011 http://
eclases.tripod.com/id12.html
F. Javier Zarazaga Soria y Javier Nogueras Iso (2008) Introduccion a la ingenieria de
software http://webdiis.unizar.es/ Recuperado el 3 de Octubre del 2011 http://
webdiis.unizar.es/~zarazaga/workPage/docencia/ingSoft1/trasparencias/is1_01.pdf
10
