Analisis De Software

Contenido

UNIDAD 4- ANALISIS DEL PROYECTO DE SOFTWARE 1

4.1. MODELADO: ANÁLISIS, DISEÑO, DOCUMENTACIÓN. 3

4.2. CONSTRUCCIÓN: CODIFICACIÓN, PRUEBAS Y EVALUACIÓN, MANUAL DEL USUARIO, MANUAL TÉCNICO. 5

4.3. MEDIDA, MÉTRICA E INDICADOR. 9

4.4. TIPOS DE MÉTRICAS: MÉTRICAS DE PROCESO, MÉTRICAS DE PROYECTO, MÉTRICAS ORIENTADAS A PUNTO DE FUNCIÓN, MÉTRICAS ORIENTADAS AL TAMAÑO, MÉTRICAS PARA LA CALIDAD DEL SOFTWARE. 10

4.5. IMPLEMENTACIÓN Y MANTENIMIENTO: ENTREGA, RETROALIMENTACIÓN DEL CLIENTE. 12

4.1. MODELADO: ANÁLISIS, DISEÑO, DOCUMENTACIÓN.

Un software siempre se crea para dar solución a un problema. Ahora bien, no todos los problemas planteados por los humanos se pueden informatizar. Para determinar si esto es posible, lo primero que hay que hacer es analizar el problema en cuestión. Esto implica determinar cuales son las exigencias del problema y estudiar si se puede resolver poniendo en práctica las técnicas y conocimientos científicos que se pueden usar en la Ingeniería del Software.

En el caso de que sí se considere viable, se debe realizar un análisis muy exhaustivo del problema, fruto del cual se obtendrá una documentación, en donde se especificará, claramente, cuales son los requisitos que el programa deberá tener, entendidos estos como características que el programa poseerá.

A dicho documento se le llama Especificación de Requisitos Software (ERS) y en él quedará escrito qué tiene que hacer el programa que se va a desarrollar, tanto en lo que se refiere al comportamiento interno (gestión de los datos) como al externo (interacción con el usuario y con otras aplicaciones).

Analisis:

Es la primera representación técnica de un sistema. Cuando se detecten problemas y fallas en está fase es necesario agregarle los siguientes objetivos:

• Los productos del análisis deben tener una elevada facilidad de mantenimiento.

• Los problemas de gran tamaño deben tratarse con un modelo efectivo de partición.

• Deben utilizarse gráficas cuando sea posible.

• Diferenciar entre consideraciones lógicas (esenciales) y físicas (de implementación).

Análisis de requisitos: Genera las especificación de características operacionales de software; indica la interfaz del software con otro elementos del sistema, y establece las restricciones que debe tener el software.

El putno clave en el modelo de análisis y la especificación de requisitos proporciona un medio para evaluar la calidad una vez que el software esté construido.

Diseño:

El diseño de software tiene un papel importante en el desarrollo de software, ya que permite que ingenieros de software produzcan modelos distintos que moldean una clase de plano de la solución a ser implementado. Podemos analizar y valorar a estos modelos para determinar cual de estos permitirá o no, cumplir con una gama de requerimientos

Es cuando se traducen los requerimientos funcionales y no funcionales en una representacion de software.El diseño es el primer paso en la fase de desarrollo o cualquer producto o sistema de ingenieria.

De acuerdo con Pressman el objetivo del diseño es producir un modelo o representacion de una entidad que va a construir posteriormente.

De acuerdo con McGlaughlin hay tres caracteristicas que sirven como parametros generales para la evaluacion de un buen diseño:

• El diseño debe implementar todos los requerimientos explicados obtenidos en la etapa de analisis.

• El objetivo debe ser una guia que puedan leer y entender los que construyenel codigo y los prueban y mantienen el software.

• El diseño debe proporcionar una idea completa de lo que es el software.

¿Por qué es importante el diseño?

Permite al ingeniero de software modelar el sistema o producto que se va a construir. Este modelo puede evaluarse en relación con su calidad y mejorarse antes de generar código, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El diseño es el sitio en el que se establece la calidad del software.

Documentacion

Para que el mantenimiento de una aplicación informática sea lo más fácil posible, es conveniente disponer de toda su documentación, esto es, de todos los documentos que se han ido generando en todas las etapas anteriores: ERS, algoritmos, códigos fuentes, manuales de usuario, etc. A todo este tipo de documentación se le considera externa. Además, existe otro tipo de documentación llamada interna.

La documentación interna de un programa son los comentarios que el programador puede escribir en el código fuente de un programa y que el compilador no tendrá en cuenta, ya que, no son instrucciones. Los comentarios de un programa son explicaciones o aclaraciones que ayudarán al programador en un futuro, cuando quiera revisar o modificar el código fuente de dicho programa, y todavía serán de más ayuda si la modificación la tiene que realizar un programador distinto al que escribió el código fuente en un primer momento.

La documentación en un proyecto es muy importante ya que es la única forma tangible de representar al software y su proceso. Los documentos estandarizados tienen una apariencia, estructura y calidad consistentes y, por lo tanto, son más fáciles de leer y de comprender.

Existen tres tipos de estándares de documentación:

1. Estándares del proceso de documentación. Definen el proceso a seguir para la producción del documento.

2. Estándares del documento. Gobiernan la estructura y presentación de los documentos.

3. Estándares para el intercambio de documentos. Aseguran que todas las copias electrónicas de los documentos sean compatibles.

4.2. CONSTRUCCIÓN: CODIFICACIÓN, PRUEBAS Y EVALUACIÓN, MANUAL DEL USUARIO, MANUAL TÉCNICO.

Construcción:

El término de construcción de software hace referencia a la creación detallada del software básico, a través de una combinación de codificación, comprobación, prueba de unidad, pruebas de integración, y depuración.

Lenguajes de construccion pueden ser varias clases:

• De configuracion.

• De Toolkits.

• De programacion.

Los principios fundamentales de la construcción de software son:

• Minimizar la complejidad

• Anticipar los cambios

• Pensar en la verificación posterior

• Aplicar estándares

Codificacion:

Una vez que los algoritmos de una aplicación han sido diseñados, ya se puede iniciar la fase de codificación. En esta etapa se tienen que traducir dichos algoritmos a un lenguaje de programación específico; es decir, las acciones definidas en los algoritmos hay que convertirlas a instrucciones.

Para codificar un algoritmo hay que conocer la sintaxis del lenguaje al que se va a traducir. Sin embargo, independientemente del lenguaje de programación en que esté escrito un programa, será su algoritmo el que determine su lógica.

La escritura del codigo fuente es el principal esfuerzo de costruccion de software:

• Aplicar tecnicas para crear codigo fuente comprensible

• Manejar condiciones de error

• Prevenir brechas de seguridad a nivel de codigo

• Uso eficiente de recursos escasos

• Organizar el codigo fuente

• Documentar el codigo

Pruebas:

Una vez obtenido el código ejecutable de un programa depurado lo máximo posible, hay que comprobar, exhaustivamente, su funcionalidad. Para ello, se tiene que ejecutar tantas veces como se considere necesario, proporcionándole, cada vez, datos de entrada distintos, y comprobando si los datos de salida son siempre los esperados.

Frecuentemente realizadas por los mismos que escriben el codigo.El proposito de estas pruebas es reducir el tiempo entre el momento en el que los fallos se insertan en el codigo y el momento en el que son detectados

Implica la ejecucion del programa permite:

• Evaluar la calidad de un producto.

• Mejorarlo identificando defectos y problemas.

El ambito o destino de las pruebas de software pueden variar en tres niveles:

• Modulo unico:Pruebas unitarias

• Grupo de modulos:Pruebas de integracion

• Sistema completo:Pruebas del sistema

Evaluacion:

Durante el desarrollo de software, las distintas técnicas de evaluación son las principales estrategias para detectar faltas y fallos. Por tanto, son métodos de control de la calidad. En términos generales, se pueden distinguir dos tipos de evaluaciones durante el proceso de desarrollo: Verificaciones y Validaciones. Según el IEEE Std 729-1983 éstas se definen como:

• Verificación: Proceso de determinar si los productos de una determinada fase del desarrollo de software cumplen o no los requisitos establecidos durante la fase anterior.

• Validación: Proceso de evaluación del software al final del proceso de desarrollo para asegurar el cumplimiento de las necesidades del cliente.

Así, la verificación ayuda comprobar si se ha construido el producto correctamente, mientras que la validación ayuda a comprobar si se ha construido el producto correcto. En otras palabras, la verificación tiene que ver típicamente con errores de los desarrolladores que no han transformado bien un producto del desarrollo en otro. Mientras que la validación tiene que ver con errores de los desarrolladores al malinterpretar las necesidades del cliente. Así la única

...