Paradigmas de la ingeniería de Software

Los documentos y material en este sitio pueden ser usados con fines académicos, haciendo referencia al documento. En cada página del menú encuentras el material relacionado. Ensayos, mapas conceptuales, artículos, gráficos, esquemas y trabajos. Material de mi autoría que he querido compartir.

PARADIGMAS DE LA INGENIERÍA DEL SOFTWARE.

♪ PARADIGMA “Modelo Lineal Secuencial” (ciclo de vida clásico)

Este modelo o paradigma, exige el modelo secuencial del desarrollo de software, que consta básicamente de las siguientes actividades:

◘ Ingeniería y Análisis del Sistema: Suponiendo que el Software es parte de un sistema mayor, por tanto se comienza estableciendo sus componentes como las entidades, roles, funciones, y demás de los que intervienen en el sistema, se identifican los requisitos del sistema que por definición son todo lo que deberá hacer y para lo que se hace el sistema aunque de manera global dado que el detalle se desglosa con exactitud en la siguiente fase que es el análisis de requisitos.

◘ Análisis de Requisitos del Software: Esta fase debería ser gestionada o liderada por un profesional con alta capacidad de comprensión desde los puntos de vista del usuario y los desarrolladores pues es donde se recopilan los requisitos específicos del Software, como la gestión de la información y las interfaces de usuario y en general tener la visión del Software ya terminado y funcionando. Saber si será un software de escritorio, una aplicación Web, o una aplicación para equipos móviles que hoy día están tan de moda y son tan útiles. Entender realmente que es lo que se pretende solucionar u optimizar y saber comunicarlo a todo el equipo; es sabido que en este caso no es conveniente asignar cargos por nepotismo dado que podría ser muy costoso para el proyecto.

Entonces se sugiere las siguientes tres etapas inter-dependientes para este modelo o paradigma:

· El Diseño del sistema o Software: Vale la pena dedicarle el tiempo necesario al análisis y diseño dado que aquí es donde se aclaran todas las dudas para el equipo de desarrollo y los usuarios y es mejor tener claridad exacta de que es lo que se quiere y no por ir demasiado rápido llegar demasiado lejos pero al lugar equivocado y entonces haber perdido el tiempo. Ahora si veamos de que se trata el diseño. Básicamente es donde se traducen los requisitos en una representación de software que pueda ser codificada y se podría aplicar la metodología del UML que es maravillosa desde mi punto de vista, para el análisis y el diseño de sistemas como se puede observar en la pestaña dedicada al lenguaje de modelado unificado UML. En este punto es importante mencionar que ahora hay mucho software pago y libre que permite modelar en UML por mencionar algunos está el Rational Rose y el Argo UML, entre muchos más, lógicamente con sus diferentes bondades cada uno.

· La Codificación: Consiste en traducir el diseño minuciosamente realizado a código fuente escrito en un lenguaje de programación que se halla seleccionado por conveniencia de los interesados.

· Las Pruebas: Son en pocas palabras la verificación de que las funciones del software producen los resultados que realmente se requieren aunque si se ha hecho un buen análisis y diseño hay una muy alta probabilidad de que así será.

· El Mantenimiento: El mantenimiento es conveniente mencionarlo dado que siempre aparecerán ajustes y en este mundo tan cambiante es lógico que el software no sea la excepción y consiste en hacer los cambios y modificaciones que se requieran.

Algunas de las ventajas del modelo lineal secuencial son que:

ü Se define desde el comienzo un orden a seguir que permite tener una idea del producto final. Y

ü Se definen todos los requisitos del software desde un comienzo.

Algunas de las desventajas del modelo lineal secuencial son que:

Ø En la realidad un proyecto casi nunca por no decir nunca siguen el flujo secuencial propuesto, aunque en mi opinión si es un marco de trabajo muy bueno si es que el proyecto es muy pequeño.

Ø Es muy difícil para el cliente o usuario tener con claridad todos los requisitos.

Ø Solo hasta las etapas finales de desarrollo hay una versión operativa del software.

Ø Difíciles de revisar si son proyectos grandes.

♪Inicio del sitio ♫Proyectos♫Informática♫UML ♫Diseño Web♫Computación Gráfica♫Habilidades Gerenciales ♫Varios ♫Robótica ♫Psicología ♫Marketing ♫Inicio de esta página ♪

♪ PARADIGMA CONSTRUCCIÓN DE PROTOTIPOS:

En este modelo se empieza con la recolección de requisitos y se implementa un diseño “rápido” que reúna los aspectos visibles al usuario, como pantallas, informes, y todo lo más general. Se desarrolla el prototipo y se evalúa por parte del cliente y las observaciones se usan para refinar los requisitos del software que se necesita.

Algunas de las ventajas de los prototipos son:

ü Permite despejar muchas dudas e identificar los requisitos del software.

ü Es un proceso iterativo que facilita la comprensión de usuarios y desarrolladores.

ü Se identifican problemas y se pueden corregir desde el origen del proyecto en el prototipo.

Algunas de las desventajas de los prototipos son:

Ø Se presta para decepciones iniciales dado que el usuario al ver tanto maquillaje e interfaz puede confundirse con el producto ya funcional y es solo el prototipo.

Ø Además por el lado del equipo desarrollador se pueden definir cosas importantes de manera herrada dado a la rapidez de la entrega del prototipo, como puede ser al escoger el lenguaje de programación y como mencionábamos en el modelo secuencial, es conveniente escoger bien debido a la naturaleza del software porque podría ser de escritorio, para móviles, aplicación web y esto alteraría mucho por ejemplo el tiempo y/o el costo del proyecto.

♪ PARADIGMA DRA (Desarrollo Rápido de Aplicaciones)

Se trata de la construcción basada en componentes, lo que da una gran velocidad. Es como ensamblar un vehículo cuando cada uno de sus componentes está listo.

Algunas de las ventajas del Desarrollo Rápido de Aplicaciones:

ü El ciclo de desarrollo es muy corto.

Algunas de las Desventajas del Desarrollo Rápido de Aplicaciones:

Ø No se puede aplicar al desarrollo de todo tipo de software.

Ø Requiere del compromiso de todos los participantes, tanto del equipo de desarrollo como del cliente o usuario.

♪ PARADIGMA MODELO EN ESPIRAL:

Este modelo está enmarcado en cuatro fases, que son la planificación, el análisis de riesgo, Ingeniería y la evaluación del cliente o usuario:

♪ En la planificación, es donde se deben definir los objetivos generales se podría decir que es donde se enfoca la visión del proyecto y se planifica como se alcanzarán estos objetivos, es decir se define cuál o cuáles serán los posibles caminos a seguir y se escoge el más óptimo. En esta etapa también es muy importante identificar lo que NO va a ir o a hacer parte del proyecto, para aclarar con más precisión lo que hará el software o lo que se requiere que haga y no tener ambigüedades entre el equipo de desarrollo y los usuarios finales.

♪ En el análisis de riesgo, se debe identificar todos los posibles riesgos que podrían aparecer antes durante y después de la implementación del software para hacer fracasar el proyecto y de igual forma se identifican todas las posibles soluciones para mitigar cada uno de los riesgos y que no se conviertan en problemas. Es importante mitigar al máximo cada uno de los riesgos y los que hay que asumir dejarlos muy mitigados, es decir muy reducidos y hacer un plan de contingencia para cada uno de manera que en caso de que alguno se llegue a materializar saber exactamente como enfrentarlo “y es donde se hace necesario contar con personal preparado en proyectos y lógicamente esto debe incorporar la mitigación de riesgos” recordemos que el nepotismo al asignar cargos en la ingeniería de software vale la pena evitarlo.

♪ Ingeniería, primero en base al plan, se hace la ingeniería del producto (análisis de los requerimientos, diseño y desarrollo) listos ahora si pasamos al desarrollo del producto y pruebas; importante enfatizar en la escogencia del lenguaje de programación adecuado al caso y si la planificación y el análisis de riesgos se hizo adecuadamente, será un éxito.

♪ Evaluación del cliente, consiste en valorar los resultados y luego hacer los ajustes pertinentes.

Algunas de las ventajas del modelo en espiral:

ü Al dedicar tiempo suficiente al plan del proyecto y al análisis de riesgos, se mitigan muchos riesgos del proyecto y eso tiene mucho valor.

ü Desde un comienzo se definen objetivos reales y de calidad, identificando la visión del proyecto y enmarcando los posibles caminos a seguir y seleccionando el más óptimo.

ü Se pueden incorporar mejoras y nuevos requerimientos dado que es un paradigma dinámico y es permitido realizar ajustes al plan.

Algunas de las desventajas del modelo en espiral:

Ø Son proyectos bastante demorados en su implementación.

Ø Es un modelo muy costoso dado a su flexibilidad.

Ø Se requiere personal con conocimientos específicos en proyectos y especialmente en el análisis de de riesgos.

Recordemos que lo mencionado aquí son algunos de los paradigmas que existen en la ingeniería de Software y HAY MUCHOS MÁS con sus ventajas y desventajas cada uno, y que desde mi punto de vista generalmente no se aplica uno en especial sino que se opta por la combinación de varios modelos de desarrollo de Software según se vea la necesidad, pero es bueno conocer varios y así saber qué y cómo hacer un Software de calidad siguiendo uno o varios paradigmas de desarrollo de software.

Estoy de acuerdo con mucho de cada modelo y desde mi punto de vista vale la pena profundizar en cada uno y tomar lo mejor de ellos porque creo y soy partidario de seguir la metodología del PMI para la gestión de proyectos incorporando el lenguaje de modelado unificado UML para el análisis y diseño de sistemas y lo que se requiera de los modelos aquí mencionados y los muchos más que existen. Me refiero a que prefiero la combinación de modelos, aunque soy consciente de que esto toma más tiempo especialmente para el análisis y el diseño sin embargo también creo que es conveniente dedicar tiempo a estas dos fases y así ir más a la fija y tener menor cantidad de sorpresas poco gratas sobre la marcha. Ya profundizaremos un poco más en la pestaña que tenemos dedicada a proyectos en este sitio.

Por: Fredy Olaya

Paginas consultadas para el anterior artículo:

Ø http://es.wikipedia.org/wiki/Modelo_de_prototipos

Ø http://es.wikipedia.org/wiki/Desarrollo_en_espiral

Bibliografía consultada:

☻Módulo de Ingeniería del Software de la UNAD del año 2010