Análisis de correctitud Modelado y análisis de requerimientos del

software

Equipo No. 4

225654 Canales Tarango Irving Manuel225673 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.

UNIVERSIDAD AUTONOMA DE CHIHUAHUAFACULTAD DE INGENIERIA

Contenido

Objetivo.................................................................................................................................3

!Introducción..........................................................................................................................3

Desarrollo.............................................................................................................................3

!! Análisis de correctitud................................................................................................3! !

! ! Simulación y prototipado............................................................................................6

! Verificación del modelo..............................................................................................8

Conclusión............................................................................................................................9

Recomendaciones................................................................................................................9

Referencias.........................................................................................................................10

2

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

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áticoDefectos 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

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

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

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

Prototipado

Herramientas de gestión de prototipoLos 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 prototipadoVentaja

●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

• 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ónEl 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.

RecomendacionesQueremos 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

ReferenciasJintao 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