Proceso de Desarrollo de Software, Desarrollo del Software II

    El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo". Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo" [Jacobson 1998].

Para desarrollar software es necesario:

·         Entender la naturaleza del software naturaleza del software.

·         Utilizar un proceso de desarrollo proceso de desarrollo bien definido y probado (adaptado a las características del software a desarrollar).

·         Gestionar el desarrollo Gestionar el desarrollo de software como un proyecto de ingeniería.

Codificación del Software.

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 lógica de un programa establece cuáles son sus acciones y en qué orden se deben ejecutar. Por tanto, es conveniente que todo programador aprenda a diseñar algoritmos antes de pasar a la fase de codificación.

Durante la fase de programación, el código puede adoptar varios estados, dependiendo de la forma de trabajo y del lenguaje elegido, a saber:

Código fuente: es el escrito directamente por los programadores en editores de texto, lo cual genera el programa. Contiene el conjunto de instrucciones codificadas en algún lenguaje de alto nivel. Puede estar distribuido en paquetes, procedimientos, bibliotecas fuente, etc.

Código objeto: es el código binario o intermedio resultante de procesar con un compilador el código fuente. Consiste en una traducción completa y de una sola vez de éste último. El código objeto no es inteligible por el ser humano (normalmente es formato binario) pero tampoco es directamente ejecutable por la computadora. Se trata de una representación intermedia entre el código fuente y el código ejecutable, a los fines de un enlace final con las rutinas de biblioteca y entre procedimientos o bien para su uso con un pequeño intérprete intermedio.

El código objeto no existe si el programador trabaja con un lenguaje a modo de intérprete puro, en este caso el mismo intérprete se encarga de traducir y ejecutar línea por línea el código fuente (de acuerdo al flujo del programa), en tiempo de ejecución. En este caso tampoco existen el o los archivos de código ejecutable. Una desventaja de esta modalidad es que la ejecución del programa o sistema es un poco más lenta que si se hiciera con un intérprete intermedio, y bastante más lenta que si existen el o los archivos de código ejecutable.

Código ejecutable: Es el código binario resultado de enlazar uno o más fragmentos de código objeto con las rutinas y bibliotecas necesarias. Constituye uno o más archivos binarios con un formato tal que el sistema operativo es capaz de cargarlo en la memoria RAM (eventualmente también parte en una memoria virtual), y proceder a su ejecución directa. Por lo anterior se dice que el código ejecutable es directamente «inteligible por la computadora». El código ejecutable, también conocido como código máquina, no existe si se programa con modalidad de «intérprete puro».

Procesamiento de Errores.

    A la hora de tratar los errores los errores que nuestro programa genere nos surgen generalmente tres grandes escenarios:

·         Que el usuario comenta un error a la hora de comunicarse con el programa (por ejemplo en la entrada de datos).

·         Que el programador no diseñe bien el programa y esté por tanto mal programado o bien que el sistema sobre el que se ejecuta el programa sea inestable o no esté funcionando correctamente.

Efectos de software con defectos.

    Tenemos que tener claro que cuando hablamos de prevenir las cosas lo que vamos a prevenir son los defectos en el software. Los defectos del software no son simples “molestias”:

   - Un producto con defectos deja de usarse

  - Puede producir enormes pérdidas (incluso de vidas humanas, si muchos accidentes la NASA son por este motivo un software desarrollado con defectos)

  - Producen retrasos en las entregas, enormes dificultades técnicas… y son responsables de muchas horas extraordinarias.

Debemos tener claro que nuestro objetivo es evitar producir programas defectuosos mediante 4 pasos:

·           -  Fundamentos del desarrollo (análisis, diseño, buena codificación).

·           -  Depuración.

·           -  Buen tratamiento de errores.

·           -  Pruebas y documentación.

Mecanismos.

Un mecanismo para controlar los errores de ejecución debe ser:

Robusto: El mecanismo debe obligar al programador a escribir código para manejar los errores de ejecución. Por ejemplo: ¿qué sucede si un archivo no se puede abrir?

Reusable: Podemos reutilizar el código, implementando diferentes manejadores de error en diferentes escenarios o siguiendo nuestra terminología, estos mecanismos los podremos utilizar en todas nuestras clases.

Extensible: Permita añadir nuevos tipos de errores y extender los ya existentes (nosotros esto ya sabemos como hacerlo: con la herencia).

Procesos de Validación.

Validación es el proceso de evaluación intensa que se lleva a cabo justo antes de entregar el producto al cliente, su objetivo es determinar si el producto en su totalidad satisface sus especificaciones.

Dentro del proceso de verificación y validación se utilizan dos técnicas de comprobación y

análisis de sistemas:

·       Inspecciones del software: analizan y comprueban las representaciones del sistema como el documento de requerimientos, los diagramas de diseño y el código fuente del programa. Las inspecciones de software y los análisis automatizados son técnicas estáticas puesto que no requieren que el sistema se ejecute.

·      Las pruebas del software: Llevan a cabo una implementación del software con losdatos de prueba y examinan las salidas del software y su comportamiento operacional para comprobar que se desempeñe conforme a lo requerido.

Pruebas.

·         Prueba de interfaz: Muchas fallas de aplicaciones se deben a problemas con las interfaces, por lo que es recomendable la aplicación de estas pruebas.

·         Prueba del sistema: La prueba del sistema es la culminación de las pruebas de integración. Consiste en pruebas que validan la aplicación completa, contra sus requerimientos.

·         Prueba de utilidad: Una buena interfaz puede mejorar mucho el valor de una aplicación. La prueba de utilidad valida la aceptación de la aplicación por los usuarios.

·         Prueba para los requerimientos de interfaz de usuario: La tarea principal de las pruebas de utilidad es asegurar que la aplicación satisface los requerimientos establecidos.

·         Pruebas de instalación: El hecho de que se haya probado la aplicación en el entorno propio no asegura que trabaje de marera apropiada.

Documentación de Software.

    La documentación de sistemas es el conjunto de información que nos dice qué hacen los sistemas, cómo lo hacen y para quién lo hacen.

La documentación consiste en material que explica las características técnicas y la operación de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el sistema y a los operandos como hacerlo funcionar.

Manual Administrativo.

Sirve como punto de partida al Sistema propuesto, ya que será función de la gerencia, de acuerdo con los usuarios de dicho Sistema, determinar silo expuesto en él satisface los requerimientos del propio sistema. Una vez lograda la aprobación, se estará en condiciones de iniciar el desarrollo del Sistema propuesto e ir integrando el resto de la documentación.

El manual tiene como finalidad el permitir a la alta gerencia tener la información necesaria y suficiente sobre un sistema en particular y servir como fuente dc consulta una vez que el Sistema ha sido implantado.

Contenido

-       Nombre del sistema.

-       Describir el nombre del sistema a implantar en la empresa.

-Equipo Encargado Del Sistema.

- Nombre del personal encargado del análisis y diseño del sistema.

- Resumen Administrativo.

Manual De Usuario

Expone los procesos que el usuario puede realizar con el sistema implantado. Para lograr esto, es necesario que se detallen todas y cada una de las características que tienen los programas y la forma de acceder e introducir información. Permite a los usuarios conocer el detalle de qué actividades ellos deberán desarrollar para la consecución de los objetivos del sistema. Reúne la información, normas y documentación necesaria para que el usuario conozca y utilice adecuadamente la aplicación desarrollada.

Objetivos

-       Que el usuario conozca cómo preparar los datos de entrada.

-       Que el usuario aprenda a obtener los resultados y los datos de salida.

-       Servir como manual de aprendizaje.

-       Servir como manual de referencia.

-       Definir las funciones que debe realizar el usuario.

-       Informar al usuario de la respuesta a cada mensaje de error.

Contenido.

Diagrama general del sistema.

Muestra en forma condensada el flujo general de la información y de las actividades que se realizan en el sistema. Proporciona una visión general del sistema. Representar los diagramas utilizando para ello diagramas de bloques.

Diagrama particular detallado.

Presentar gráficamente todos los pasos que se efectúen dentro del departamento usuario a quien está dirigido este manual. Deben especificarse los archivos de entrada, salida, los resultados, revisiones y procesos manuales.

Explicación Genérica De Las Fases Del Sistema,

En este punto se explica en forma específica y detallada todas las operaciones que aparecen representadas en forma gráfica en el diagrama particular. Se analizan cada una de las fases señalando:

-       El proceso principal que se desarrolla.

-       La entrada de la información.

-       La obtención de un resultado parcial.

-       El envío de información a otra dependencia.

Manual De Captación.

Permite tener una clara visión del proceso de Captación de los datos fuentes previo al procesamiento electrónico de los mismos.

Objetivos.

-           Documentar al usuario a cerca del recorrido a través de las pantallas del sistema.

-       Conocer la forma cómo el usuario puede utilizar el equipo necesario para la ejecución del sistema.

Contenido.

-          Diagrama General Del Sistema.

Este diagrama debe ser presentado gráficamente y en forma sencilla. Representar los diagramas utilizando para ello diagramas de bloques ( es el mismo diagrama que se presenta en el Manual Administrativo).

-          Diagramas De Pantalla.

Presentar en este punto el flujo del sistema en las pantallas utilizadas por cada módulo.

Plan de Mantenimiento.

El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como “la modificación de un producto software después de haber sido entregado [a los usuarios o clientes] con el fin de corregir defectos, mejorar el rendimiento u otros atributos, o adaptarlo a un cambio en el entorno”.

Tipos de Mantenimiento.

Mantenimiento Correctivo: El mantenimiento correctivo tiene por objetivo localizar y eliminar los posibles defectos de los programas. Un defecto en un sistema es una característica del sistema con el potencial de causar un fallo. Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la especificación.

 Entre otros, los fallos en el software pueden ser de:

 Procesamiento, por ejemplo, salidas incorrectas de un programa.

 Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una búsqueda de información.

 Programación, por ejemplo, inconsistencias en el diseño de un programa.

 Documentación, por ejemplo, inconsistencias entre la funcionalidad de un programa y el manual de usuario.

Mantenimiento Adaptativo:

Este tipo de mantenimiento consiste en la modificación de un programa debido a cambios en el entorno (hardware o software) en el cual se ejecuta.

Mantenimiento Perfectivo: Algunos autores dividen este tipo de mantenimiento en dos:

 Mantenimiento de Ampliación: orientado a la incorporación de nuevas funcionalidades.

 Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecución.

 Este tipo de mantenimiento aumenta cuando un producto software tiene éxito comercial y es utilizado por muchos usuarios, ya que cuanto más se utiliza un software, más peticiones de los usuarios se reciben demandando nuevas funcionalidades o mejoras en las existentes.

Mantenimiento Preventivo: consiste en la modificación del software para mejorar sus propiedades (por ejemplo, aumentando su calidad y/o su mantenimiento) sin alterar sus especificaciones funcionales.