Desarrollo De Proyectos De Software (1)

Originalmente este artículo fue publicado en nuestro blog el Dom, 10/12/2014 – 20:29 (electronicaml.com.ve/?q=node/79#) y era el primero de una serie de 12, que pretendían ser una guía de estudio para mis antiguos alumnos de un curso On-Line sobre Proyectos De Sistema O Software.

Por lo tanto, sería justo considerar que este material es una actualización del material original; ya que serán incluidas y mostradas en 6 entradas correlativas, las respectivas actualizaciones que evidentemente han acontecido en los últimos años.

Básicamente los temas serán abordados bajo el siguiente esquema:

  • Arquitectura De Software.
  • Diagrama De Flujo De Datos.
  • Diccionario De Datos.
  • Diseño De Datos.
  • Diseño Procedimental.
  • Interfaz De Usuario.
  • Modelos De Datos.
  • Programación Estructurada.
  • Pruebas De Integración.
  • Pruebas Unitarias.

¿Qué es un proyecto de Sistema o Software?

Básicamente, es el proceso de gestión para la creación de un Sistema o Software; el cual encierra un conjunto de actividades, una de las cuales es la estimación. Estimar, es echar un vistazo al futuro y aceptar cierto grado de incertidumbre. Aunque la estimación, es más un arte que una ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada.

Objetivos de la Planificación del Proyecto.

El objetivo de la Planificación del proyecto de Software, es proporcionar un marco de trabajo que permita al gestor, hacer estimaciones razonables de recursos y costos, así como una planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado, al comienzo de un proyecto de software y deberían actualizarse regularmente, a medida que progresa el proyecto.

El desarrollo de un programa o de un conjunto de aplicaciones, se basa en un concepto llamado ciclo de vida. Son unas series de etapas o fases, que hay que seguir secuencialmente.

Las fases o etapas son:

  • Análisis.
  • Diseño.
  • Codificación o construcción.
  • Implantación o explotación.
  • Mantenimiento.

ANÁLISIS

En esta fase se establece el producto a desarrollar, siendo necesario especificar los procesos y estructuras de datos que se van a emplear. Debe existir una gran comunicación entre el usuario y el analista, para poder conocer todas las necesidades que precisa la aplicación. En el caso de falta de información por parte del usuario, se puede recurrir al desarrollo de prototipos; para saber con más precisión sus requerimientos.

En el análisis estructurado se pueden emplear varias técnicas como:

  • Diagramas de flujo de datos: Sirven para conocer el comportamiento del sistema mediante representaciones gráficas.
  • Modelos de datos: Sirven para conocer las estructuras de datos y sus características. (entidad – relación y formas normales)
  • Diccionario de datos: Sirve para describir todos los objetos utilizados en los gráficos, así como las estructuras de datos.
  • Definición de los interfaces de usuario: Sirven para determinar la información de entrada y salida de datos.

Al final de esta fase, tenemos que tener claro las especificaciones de la aplicación.

DISEÑO

El diseño, es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería.

El diseño de software; al igual que los métodos de diseño de todas las ingenierías, cambian continuamente al aparecer nuevos métodos, mejores análisis y al ampliar los conocimientos. El problema, es que el diseño de software se encuentra en una etapa relativamente temprana en su evolución. La idea de realizar diseño de software; en lugar de “programar”, surgió a principios de los años 60. Por lo que a las metodologías de diseño, les falta la profundidad y la flexibilidad que tiene el diseño en otras ingenierías; pero ya existen técnicas de diseño de software, para poder evaluar la calidad del software.

Una vez que se han establecido los requisitos del software, el diseño es la primera de tres actividades técnicas: diseño, codificación y prueba. Cada actividad transforma la información, de forma que al final se obtiene un software validado. El diseño es técnicamente la parte central de la ingeniería del software. Durante el diseño se desarrollan, revisan y se documentan los refinamientos progresivos de las estructuras de datos, de la estructura del programa y de los detalles procedimentales. El diseño da como resultado representaciones, cuya calidad puede ser evaluada.

Mediante algunas metodologías de diseño se realiza el diseño de datos, el diseño arquitectónico y el diseño procedimental.

  • El diseño de datos: transforma el modelo de campo de información, creado durante el análisis y en las estructuras de datos que se van a requerir para implementar el software.
  • El diseño arquitectónico: define las relaciones entre los principales elementos estructurales del programa.
  • El diseño procedimental: transforma los elementos estructurales en una descripción procedimental del software.

Sin diseño, nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeños cambios, un sistema que sea difícil de probar, un sistema cuya calidad no pueda ser evaluada hasta más adelante, cuando quede poco tiempo y ya sea haya gastado mucho dinero. Al final de esta etapa, se obtiene el denominado cuaderno de carga.

CODIFICACIÓN

Consiste en traducir los resultados obtenidos a un determinado lenguaje de programación, teniendo en cuenta las especificaciones obtenidas en el cuaderno de carga. Se deben de realizar las pruebas necesarias para comprobar la calidad y estabilidad del programa. Las pruebas se pueden clasificar en:

  • Pruebas unitarias: Sirven para comprobar que cada módulo realice bien su tarea.
  • Pruebas de integración: Sirven para comprobar el funcionamiento correcto del conjunto de programas que forman la aplicación (el funcionamiento de todo el sistema).

En un proyecto, ésta es la etapa más sencilla (en contra de lo que suele suponer cualquier persona, que comienza a aprender un lenguaje de programación). Si el diseño es adecuado y suficientemente detallado, la codificación de cada módulo es algo casi automático.

Una de las principales decisiones a tomar en esta fase, es la del lenguaje a emplear; aunque a veces en el diseño, ya está de alguna forma implícito. Desde hace tiempo, la tendencia es a utilizar lenguajes de más alto nivel; sobre todo, a medida de que se dispone de compiladores más eficientes.
Esto ayuda a los programadores, a pensar más cerca de su propio nivel que del de la máquina y la productividad, suele mejorarse.

Como contrapartida a este tipo de lenguajes, son más difíciles de aprender. Y además, hay que tener en cuenta que los programadores suelen ser conservadores y reacios a aprender nuevos lenguajes: prefieren usar los que ya conocen.

La existencia en una organización, de una gran cantidad de programas desarrollados en un determinado lenguaje; hace muy dura la decisión, de cambiar a uno nuevo. Evaluar la calidad de la codificación no es una tarea, para nada fácil; para un mismo diseño, son posibles muchas implementaciones diferentes. Y no hay criterios claros, que permitan decidir cuál es la mejor.

En este punto, las métricas del software pueden ser utilizadas en nuestra ayuda. Cuando intervienen varias personas, pueden aparecer problemas a la hora de realizar modificaciones; debido a que cada uno tiene su propio estilo. Por eso se hace necesario definir estándares de estilo, para facilitar la legibilidad y claridad del software producido.

EXPLOTACIÓN

En esta fase, se realiza la implantación de la aplicación en el sistema o sistemas físicos, donde van a funcionar habitualmente; y su puesta en marcha, para comprobar el buen funcionamiento.
Actividades a tener en cuenta o realizar:

  • Instalación del o de los programas.
  • Pruebas de aceptación al nuevo sistema.
  • Conversión de la información del antiguo sistema al nuevo (si hay una aplicación antigua)
  • Eliminación del sistema anterior.

Al final de esta fase, se debe completar la información al usuario; respecto al nuevo sistema y a su uso. Así como facilitarle toda la documentación necesaria, para una correcta explotación del sistema (manual de ayuda, manual de uso, guía de la aplicación, etc.)

MANTENIMIENTO

Esta es la fase que completa el ciclo de vida, y en ella nos encargaremos de solventar los posibles errores o deficiencias de la aplicación. Existe la posibilidad de que ciertas aplicaciones necesiten reiniciar el ciclo de vida.

Tipos de mantenimiento:

  • Mantenimiento correctivo: Consiste en corregir errores no detectados en pruebas anteriores y que aparezcan con el uso normal de la aplicación. Este mantenimiento puede estar incluido en la garantía o mantenimiento de la aplicación.
  • Mantenimiento adaptativo: Consiste en modificar el programa, a causa de cambio de entorno gráfico y lógico en el que estén implantados (nuevas generaciones de ordenadores, nuevas versiones del sistema operativo, etc.).
  • Mantenimiento perfectivo: Consiste en una mejora sustancial de la aplicación, al recibir por parte de los usuarios propuestas sobre nuevas posibilidades y modificaciones de las existentes.

Los tipos de mantenimiento adaptativo y perfectivo reinician el ciclo de vida, debiendo proceder de nuevo al desarrollo de cada una de sus fases, para obtener un nuevo producto.

Arquitectura De Software

En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal; debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software.

En el libro “An introduction to Software Architecture” David Garlan y Mary Shaw, definen que la Arquitectura es un nivel de diseño que hace foco en aspectos “más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema”.

Arquitectura

  • La Arquitectura del Software, es el diseño de más alto nivel de la estructura de un sistema.
  • Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco.
  • Una arquitectura de software se selecciona y diseña con base en objetivos (requerimientos) y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones, derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías; mientras que otras tecnologías, no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas, para implementar sistemas en tiempo real.
  • La arquitectura de software, define de manera abstracta los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.

La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada, para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema; así como requerimientos no funcionales, como la confiabilidad.

Modelos O Vistas

Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar, que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable, que exista cierto solapamiento entre ellos. Esto es así, porque todas las vistas deben ser coherentes entre sí; es evidente, que describen la misma cosa.

Cada paradigma de desarrollo, exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:

  • La visión estática: describe qué componentes tiene la arquitectura.
  • La visión funcional: describe que hace cada componente.
  • La visión dinámica: describe como se comportan los componentes a lo largo del tiempo y cómo interactúan entre sí.
  • Las vistas o modelos: pueden expresarse mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista.

Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible).

Arquitecturas Más Comunes

Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida, en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:

  • Descomposición Modular. Donde el software se estructura en grupos funcionales muy acoplados.
  • Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes, pero sin reparto claro de funciones.
  • Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente.

Otras arquitecturas afines menos conocidas son:

  • Modelo Vista Controlador.
  • En pipeline.
  • Entre pares.
  • En pizarra.
  • Orientada a servicios.
  • Dirigida por eventos.
  • Máquinas virtuales.

>>>>>

Redes Sociales...
Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone

En Electrónica ML utilizamos cookies para que usted obtenga una mejor experiencia como usuario de nuestra web. Si continúa navegando, está dando su consentimiento para la aceptación y uso de las mencionadas cookies y la aceptación de nuestra política de cookies, click en el enlace para mayor información.

ACEPTAR
Aviso de cookies
Soporte Técnico