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

...