DIAGRAMA DE SECUENCIAS

INTRODUCCIÓN

El diagrama de secuencias UML muestra la mecánica de la interacción con base en tiempos. Es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso.

Muestra de forma ordenada la acción a realizar con un tiempo de respuesta estimado y los subprocesos que conllevan dicha acción que a su vez tendrán su tiempo en ejecución.

Estos diagramas facilitan la estimación de muchos factores para que el cliente pueda entender sin esfuerzo alguno debido a que es muy sencillo de hacer y de visualizar también.  

MARCO TEÓRICO

Si tiene un diagrama de casos de uso en el que se resumen los usuarios del sistema y sus objetivos, puede dibujar diagramas de secuencia para describir el modo en que los principales componentes del sistema interactúan para lograr el objetivo de cada caso de uso.

Un diagrama de secuencias es aquel que hace referencia al tiempo en el que las interacciones entre objetos y clases se realizan, es decir que se mide el tiempo de la interacción de los elementos del sistema.

Se dice que un diagrama de secuencias cuenta una historia, para esto tiene como elementos, objetos y la línea de vida de estos, entre otros.

ELEMENTOS CON LOS QUE CUENTA UN DIAGRAMA DE SECUENCIA.

• Rol de la clase: describe la manera en que un objeto se va a comportar en el contexto. No se listan los atributos del objeto.
• Activación: Los cuadros de activación representan el tiempo que un objeto necesita para completar una tarea.
• Mensajes entre los objetos: Es la comunicación entre los objetos, representadas por una flecha.
• Línea de vida del objeto: Indican la presencia del objeto durante el tiempo.
• Destrucción de Objetos: Los objetos se pueden eliminar.
• Loops: Indican las condiciones para salir.

Las líneas pueden ser:

Un ejemplo de un Diagrama de secuencias:

CONCLUSIÓN.

Puede verse con facilidad cómo se distribuyen las tareas entre los componentes, generando que cualquier persona que vea el diagrama entienda rápidamente las acciones, además de los procesos y el tiempo que conllevan al mismo para que ejecute dicha acción que se especifica.

Pueden identificarse los modelos de interacción que dificultan la actualización de software, para hacer más entendible a otros desarrolladores en caso de que el programa requiera alguna modificación.

Los diagramas de secuencias tienen cierta forma de elaboración, de manera que sean mejor entendidos y así el software sea mejor diseñado, por lógica simple un diagrama de secuencias no puede tener una línea de activación más grande que la línea de vida de un objeto.

BIBLIOGRAFÍA.

Pressman, R. Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805.

Montiel, M; Ríos, F; Moyano, F; Martínez, R y Rodríguez, I. 2009. Diagramas UML. (En línea). ES. Consultado el 11 de Jul. 2015. Formato PDF. Disponible en: http://www.danielstolfi.com/vigia/archivos/diagramasuml.pdf

Núñez. 2000. Modelado de objetos con UML. (En línea). VE. Consultado el 11 de Jul. 2015. Formato PDF. Disponible en: http://exa.unne.edu.ar/informatica/anasistem1/public_html/TUTORIAL_UML[1].pdf

RELACIONES ENTRE CLASES

INTRODUCCIÓN

Como se mencionaba anteriormente el concepto de relaciones entre clases es importante sobre todo luego de haber explicado los diagramas de clases, en la sección anterior, que explicando los detalles de las relaciones entre clases se entenderá de mejor manera.

Es importante para el desarrollador entender los diferentes tipos de relaciones entre clases que existen y como aplicarlo para su proyecto, porque un buen diagrama de clases implica que se va por buen camino para el producto final, y esto implica que las relaciones entre las clases estén desarrolladas de manera adecuada, en caso de no tener claro cómo desarrollar las relaciones entre clases para el diagrama se tendrá problemas a futuro.

MARCO TEÓRICO

Las relaciones son un pilar fundamental en el que se basan los Diagramas de Clases, después de las clases mismas y los interfaces. Las relaciones se aplican exclusivamente entre clases y pueden ser binarias o de orden superior.

Decir que dos clases están relacionadas entre sí viene a significar que esas clases tienen algo que ver entre sí. De cómo sea la naturaleza de la relación definirá un tipo u otro de vinculación. De lo que se trata aquí es de identificar, caracterizar y ejemplarizar cada una de ellas.

Los tipos de relaciones entre clases que existen son las siguientes:

·         Generalización o especialización.

·         Asociación.

·         Agregación.

·         Composición.

GENERALIZACIÓN O ESPECIALIZACIÓN.

Indica que una subclase hereda los métodos y atributos especificados por una súper clase, por ende la subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la súper Clase (pública y privada), ejemplo:

ASOCIACIÓN:

Enlace entre objetos de las clases implicadas, también se puede definir como una conexión entre clases que define los roles o dependencias entre objetos.

Existen 3 tipos de Asociación que son:

AGREGACIÓN:

Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

COMPOSICIÓN.

Es un tipo de asociación en donde el ciclo de vida de la parte [PARTE] está vinculado del ciclo de vida de la parte [TODO], de tal manera que cuando desaparece la parte [TODO] la parte [PARTE] también desaparece. A este tipo de vinculación se la denomina también asociación fuerte o asociación existencial.

Para ejemplarizar este tipo de relación considérese el caso expuesto anteriormente respecto de los cónyuges y el matrimonio:

CONCLUSIÓN.

Se debe tener en cuenta cada una del tipo de relaciones entre clases y los requerimientos o necesidades del cliente para tener una buena base del software que se va a desarrollar, este aspecto es fundamental ya que se parte desde ahí para luego comenzar a desarrollar los diversos aspectos o características que va a tener el programa.

El saber realizar un buen diagramas de clases con relaciones bien establecidas es de mucha importancia para cualquier programa que se desarrolla, por eso la importancia de conocer detalladamente las relaciones entre clases.

BIBLIOGRAFÍA.

Pressman, R. Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill.

Gutiérrez, D. 2011. UML Diagramas de clases. (En línea). VE. Consultado, 05 de Jul. 2015. Formato PDF. Disponible en: http://www.codecompiling.net/files/slides/UML_clase_04_UML_clases.pdf

Kendall, K y Kendall, J. 2011. Análisis y diseño de sistemas. 8 ed. México. Pearson Education. p 600.

Berzal, F. 2004. Relaciones entre clases: Diagrama de clases UML. (En línea). ES. Consultado, 04 de Jul. 2015. Formato PDF. Disponible en: http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

DIAGRAMAS DE CLASES

INTRODUCCIÓN

Es importante al momento de la elaboración del software la documentación de lo que se está desarrollando, debido a que suele darse el caso de que una vez finalizado y entregado el proyecto, el software requiera alguna mejora o mantenimiento que en ciertos casos no la realiza el mismo desarrollador, he ahí la importancia de los diagramas de clases que agilizan que otro desarrollador comprenda y pueda aplicarle los cambios deseados.

En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.

MARCO TEÓRICO

Los diagramas de clases son diagramas de estructura estática que muestran las clases del sistema y sus interrelaciones (incluyendo herencia, agregación, asociación, etc.). Los diagramas de clase son el pilar básico del modelado con UML, siendo utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo puede ser construido (diseño). El diagrama de clases de más alto nivel, será lógicamente un dibujo de los paquetes que componen el sistema. Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos. Las relaciones entre clases se documentan con una descripción de su propósito, sus objetos que intervienen en la relación y su opcionalidad (cuando un objeto es opcional el que intervenga en una relación).

CLASE.

Resumiendo que para obtener un diagrama de clases, se debe comenzar por conocer que es una clase, en pocas palabras una clase es el pilar fundamental para la programación y representan las características, métodos y demás aspectos que tenga una entidad, un buen ejemplo de cómo representar una clase sería una persona con sus atributos: brazos, piernas, etc., y sus métodos pueden ser: caminar, tocar.

MIEMBROS.

Los métodos y atributos son los miembros con los que cuenta una clase, además de cierta información de los mismos. Además en una clase los miembros no suelen tener las mismas características que pueden ser público, privado, etc., por ejemplo:

GRÁFICO DE UN DIAGRAMA DE CLASES.

Cabe indicar que se muestran en el gráfico ciertos tipos de relaciones, que se explicaran en la siguiente entrada.

CONCLUSIÓN.

Es de vital importancia en la actualidad en cada desarrollo de software el uso de diagramas de clases, que genera que el desarrollador avance en el proyecto y si tiene alguna duda mientras lo hace puede revisar su diagrama para aclararlas. Es de gran ayuda tanto para el desarrollador como para el cliente, el desarrollador generara una buena reputación si realiza un buen trabajo y más aún si lo detalla en un diagrama de clases, debido a que el cliente estar más conforme, ya que se puede citar la oportunidad que otra persona o desarrollador intervenga en el software para aplicar alguna modificación, lo primero que hará el mismo será consultar con el diagrama de clases con el que cuenta el software para aplicarle los cambios necesarios, mientras que esto no se podrá dar tan ágil si el creador del software no le agrego a su trabajo un diagrama de clases, dañando así su imagen y reputación como desarrollador.   

BIBLIOGRAFÍA.

Pressman, R. Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805.

García, F y Pardo, C. 2013. Diagramas de Clase en UML 1.1. (En línea). ES. Consultado, 13 de Jun. 2015. Formato PDF. Disponible en: http://gredos.usal.es/jspui/bitstream/10366/121969/3/DIA_GarciaPenalvo_PardoAguilar_DClase.pdf.

CASOS DE USO.

INTRODUCCIÓN

Cada vez que se está desarrollando algún software se debe tener claro el objetivo a cumplir, pero no siempre suele ser lo que el cliente desea, es ahí donde es de mucho beneficio aplicar los casos de uso, que explica detalladamente cada uno de los eventos que desempeñara el software, así como los actores y funciones que intervienen en dichos eventos, en otras palabras define el flujo del programa de manera que el cliente pueda entender cada funcionalidad, para que de esta manera le saque el mejor beneficio al software, generando beneficios tanto como para el desarrollador como para el cliente. En caso de que el cliente no esté de acuerdo con algún detalle también podría considerarse una ventaja de usar los diagramas de casos de uso, para poder llegar a un acuerdo a tiempo. 

Los diagramas de casos de uso se hicieron famosos por decirlo de cierta forma por el año 1992 gracias a Jacobson, aunque es verdad que fueron diseñados por el año 1984.

Son muchas las ventajas que nos presentan los diagramas de casos que se detallaran a continuación en el resto de esta sección.

MARCO TEÓRICO

Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con él; un ejemplo de actor podría ser un usuario o cualquier otro sistema.

ELEMENTOS QUE POSEE UN MODELO DE CASO DE USO.

• Actor: Son los que intervienen o no en una acción estos pueden ser: primarios, secundarios e iniciadores. 
• Casos de uso: Es la acción que se va a llevar a cabo, estos pueden ser: resumidos, extendidos, esenciales, de implementación y reales.
• Relaciones:

Gráficos:

EJEMPLOS DE DIAGRAMAS DE CASOS DE USO CON TABLA DE DOCUMENTACIÓN.

Proyecto:	Nombre del proyecto
Paquete	Detalle del diagrama de caso de uso (Autenticación de usuario).
Caso de Uso:	Detalle del caso de uso o acción (Login).
Autores:	Quien realiza el software.
Fecha:	Indica la fecha de creación.
Descripción: Pequeño detalle delo que realiza el diagrama de caso de uso, en las que interviene el actor y las acciones.
Actores: Quien ejecuta la acción.
Precondiciones: Lo que debe de tenerse en cuenta antes de proceder
Poscondiciones: Lo que está por defecto en el sistema.
Flujo Normal: La secuencia de cómo realizar la acción.
Flujo de Evento alternativo: Detalla lo que se debe realizar en caso de fallo.

CONCLUSIÓN.

Los diagramas de casos de uso son muy utilizados por la importancia que genera que el cliente sepa la manera de trabajar del producto que desea adquirir, por la que se pueden desprender las diferentes formas de garantizar una entrega satisfactoria de un producto final al momento de la transacción entre el cliente y el desarrollador.

El desarrollador debe tomar en cuenta con cuidado cada uno de los requerimientos del cliente y plasmar de la misma manera lo que el programa que pensó en base a las necesidades va a realizar, en otras palabras debe tener cuidado también a la hora de realizar el diagrama de caso de uso debido a que se puede malinterpretar las funcionalidades del software que se esta desarrollando.

BIBLIOGRAFÍA.

Pressman, R. Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805.

UML

INTRODUCCION

El seudónimo UML proviene del lenguaje de modelado unificado o por sus siglas en inglés (Unified Modeling Language), es un estándar para crear diseños de software.

Dicho de otra manera es la herramienta que usan los desarrolladores para que las personas a quien se le presenta dicho diseño pueda entender lo que se va a desarrollar, es como el plano que un arquitecto crea antes de comenzar con el proyecto, y de esta manera el cliente entiende y opina de lo que se va a realizar al respecto. Como detalla anteriormente es un lenguaje creado para que desarrolladores y usuarios se comuniquen en un mismo idioma, por decirlo de cierta manera.

UML es un lenguaje para describir modelos. Básicamente, un modelo es una simplificación de la realidad que construimos para comprender mejor el sistema que queremos desarrollar. Un modelo proporciona los “planos” de un sistema, incluyendo tanto los que ofrecen una visión global del sistema como los más detallados de alguna de sus partes.

MARCO TEÓRICO

Como se mencionó anteriormente UML utiliza diversos diagramas para el uso de modelado del software que se detallaran en una breve descripción, a continuación:

DIAGRAMAS DE CLASE

Para modelar clases, incluidos sus atributos, operaciones, relaciones y asociaciones con otras clases, el UML proporciona un diagrama de clase, que aporta una visión estática o de estructura de un sistema, sin mostrar la naturaleza dinámica de las comunicaciones entre los objetos de las clases.

Esto permite de manera gráfica las funciones que desempeña cada uno delos componente, además que el usuario vea el flujo de información y el medio de transmisión de la misma, para entender de mejor manera al software.

DIAGRAMAS DE IMPLEMENTACIÓN

Es aquel que se enfoca en la estructura de un sistema de software y al mismo tiempo muestra de manera sencilla, la forma de desempeño del hardware a través del software a desarrollarse.

Suponga, por ejemplo, que desarrolla un paquete de renderizado de gráficos basado en web. Los usuarios de su paquete usarán su navegador web para ir a su sitio web e ingresar la información que se va a renderizar. Su sitio web renderizaría una imagen gráfica de acuerdo con la especificación del usuario y la enviaría de vuelta al usuario. Puesto que las gráficas renderizadas pueden ser computacionalmente costosas, usted decide mover el renderizado afuera del servidor web y hacia una plataforma separada. Por tanto, habrá tres dispositivos de hardware involucrados en su sistema: el cliente web (la computadora que corre un navegador del usuario), la computadora que alberga el servidor web y la computadora que alberga el motor de renderizado.

CONCLUSIÓN.

El lenguaje UML aporta de manera significativa, al modelado de un proyecto de software, debido a sus múltiples atributos, este no solo ayuda al desarrollador a crear de mejor manera, sino que también mejora la comunicación entre ambas partes de la negociación, generando que disminuya de manera importante la probabilidad de un software que no satisfaga las necesidades del cliente.

El cliente conlleva un roll muy importante a la hora de evaluar si lo que el desarrollador a planificado hacer, se encuentra de manera adecuada como se mencionó anteriormente, además se puede reducir el riesgo de que el desarrollador se demore más de lo estimado por causas de un programa o software no satisfactorio.

BIBLIOGRAFÍA.

Pressman, R. Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805.

Gutiérrez, D. 2011. Métodos de Desarrollo de Software. (En línea). VE. Consultado, 19 de abril de 2015. Formato PDF. Disponible en: http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdf

DESARROLLO AGIL

INTRODUCCION

Los ingenieros de software desde mucho tiempo antes se han preocupado por el producto final, pero para ello se debe tener en cuenta mucho la metodología que se emplea en el desarrollo del mismo, cosa que muy pocos toman en cuenta a la hora de trabajar en este tema se puntualiza, ciertos métodos de desarrollo de un proyecto que en según los criterios que se deben tomar en cuenta, que son características de cada uno de ellos, para lo cual se debe hacer énfasis en cada una de las fases que detallan en cada uno de ellos.

Basado en lo que indica (Pressman, R). Es frecuente que en la economía moderna sea difícil o imposible predecir la forma en la que evolucionará un sistema basado en computadora (por ejemplo, una aplicación con base en web). Las condiciones del mercado cambian con rapidez, las necesidades de los usuarios finales se transforman y emergen nuevas amenazas competitivas sin previo aviso. En muchas situaciones no será posible definir los requerimientos por completo antes de que el proyecto comience.

Se debe ser suficientemente ágil para responder a lo fluido que se presenta el ambiente de negocios.  

MARCO TEÓRICO

La fluidez implica cambio, y el cambio es caro, en particular si es descontrolado o si se administra mal. Una de las características más atractivas del enfoque ágil es su capacidad de reducir los costos del cambio durante el proceso del software.

PROGRAMACIÓN EXTREMA (XP).

A fin de ilustrar un proceso ágil con más detalle, daremos un panorama de la programación extrema (XP), el enfoque más utilizado del desarrollo de software ágil. Aunque las primeras actividades con las ideas y los métodos asociados a XP ocurrieron al final de la década de 1980, el trabajo fundamental sobre la materia había sido escrito por Kent Beck [Bec04a]. Una variante de XP llamada XP industrial [IXP] se propuso en una época más reciente [Ker05]. IXP mejora la XP y tiene como objetivo el proceso ágil para ser usado específicamente en organizaciones grandes.

EL PROCESO XP.

Al igual que en los procesos del software el XP utiliza sus procesos, como la mayoría de las metodologías agiles que son los siguientes:

1.      Planeación: Es en donde se contacta con el cliente, para atender los requerimientos que el mismo desea suplir, de manera que el equipo XP puedan entender las necesidades del cliente y las funcionalidades que debe tener el programa, en la que se evaluará cada costo de las características así como el tiempo estimado en realizarse.

2.      Diseño: El XP usa una ideología que se debe de mantener un diseño sencillo, además de usar las tarjetas CRC (Clase-Responsabilidad-Colaborador), con el fin de definir, en que secciones se va a desempeñar cada uno de los integrantes del grupo, todo esto para que cada uno cumpla con lo que saben mejor, de esta manera el proyecto se lleva a cabo de mejor manera y el producto final es de mejor calidad y eficacia.

3.      Codificación: En esta fase se evalúa lo que se va a realizar, para posteriormente llevar al desarrollo, lo cual este método recomienda que sea en pareja, para mejorar la calidad del producto, y cada funcionabilidad implementada se le va realizando sus respectivas pruebas, antes de implementarla al módulo final.

4.    Pruebas: Ya se dijo que la creación de pruebas unitarias antes de que comience la codificación es un elemento clave del enfoque de XP.

Al final de cada producto se debe evaluar el funcionamiento global del producto, con el fin de garantizar que nuestro proyecto es sostenible y a la vez eficaz.

SCRUM

Scrum (nombre que proviene de cierta jugada que tiene lugar durante un partido de rugby). Es un método de desarrollo ágil de software concebido por Jeff Sutherland y su equipo de desarrollo a principios de la década de 1990. En años recientes, Schwaber y Beedle [Sch01a] han desarrollado más los métodos Scrum.

Es una de las metodologías utilizadas para guiar las actividades de desarrollo, de manera que se mejore la experiencia en el desarrollo de un software, para lo cual incorpora las actividades: requerimientos, análisis, diseño, evolución y entrega.

En cada una de estas actividades se realizan de forma detallada lo que el grupo de desarrollo debe tomar en cuenta, ya sea desde el levantamiento de la información hasta terminar con las pruebas correspondientes del software.

En la imagen se detalla las características más relevantes de Scrum acotando además que los sprints son las unidades de trabajo que se necesitan para suplir o cumplir con un requerimiento, en el cual tiene la característica de ser máximo de 30 días, y no se introducen cambios, es decir no se puede agregar cierta característica de un día para otro mientras se esté realizando el sprint, las reuniones son dirigidas por un Scrum master, que es el director del proyecto por decir de cierta forma.

CONCLUSION.

Las metodologías de desarrollo ágil, se enfocan en ser un conjunto de pasos, para que los desarrolladores se guíen de buena manera para conseguir finalizar un buen software, las herramientas tanto de XP como las de Scrum suelen ser factibles dependiendo del proyecto que se esté llevando a cabo, siempre y cuando se realice cada acción de manera cautelosa, se puede llegar a cumplir de buena manera todos los objetivos propuestos, y usando bien todas estas características se llega a lo óptimo, con respecto a un trabajo de un software.   

BIBLIOGRAFÍA.

Pressman, R. Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805.

Gutiérrez, D. 2011. Métodos de Desarrollo de Software. (En línea). VE. Consultado, 19 de abril de 2015. Formato PDF. Disponible en: http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdf

MODELOS DEL PROCESO

INTRODUCCION

Los modelos del proceso ayudan a llevar a cabo un adecuado transcurso, según lo que el desarrollador desea realizar, para cada software existe un modelo adecuado que genera que se realice de manera eficaz lo que se desea, debido a que existen diversos tipos de programas, así, por lo tanto el proceso que debe llevar tiende a ser similar, pero el modelado del proceso debe ser de acuerdo a lo que se está trabajando, porque la planificación en la realización de un proyecto es muy importante para que al final del mismo, se obtengan resultados satisfactorios, pero para saber qué modelo se debe elegir se debe estudiar cada uno de los parámetros que estos muestran en consecuencia se puede hacer un análisis de manera oportuna para determinar uno a seguir, más adelante se detallan unos de los más importantes modelos de procesos, con el fin de dar a conocer en qué tipos de programas o software se debe aplicar.

Según (Pressman, R). Debido a que el software, como todo capital, es conocimiento incorporado y a que el conocimiento originalmente se halla disperso, tácito, latente e incompleto en gran medida, el desarrollo de software es un proceso de aprendizaje social. El proceso es un diálogo en el que el conocimiento que debe convertirse en software se reúne e incorpora en éste. El proceso genera interacción entre usuarios y diseñadores, entre usuarios y herramientas cambiantes, y entre diseñadores y herramientas en evolución tecnológica. Es un proceso que se repite y en el que la herramienta que evoluciona sirve por sí misma como medio para la comunicación: con cada nueva ronda del diálogo se genera más conocimiento útil a partir de las personas involucradas.      

MARCO TEÓRICO

Anteriormente se definió a un proceso como la colección de actividades de trabajo, acciones y tareas que se realizan cuando va a crearse algún producto terminado. Cada una de las actividades, acciones y tareas se encuentra dentro de una estructura o modelo que define su relación tanto con el proceso como entre sí.

Cada uno de estos modelados implican las acciones anteriormente nombradas tales como: comunicación, planeación, modelado, construcción y despliegue. De alguna u otra manera los modelos de los procesos realizan cada una de estas actividades para la correcta realización de un software, ya sea lineal, evolutivo, iterativo, etc.

MODELOS DE LOS PROCESOS PRESCRIPTIVOS.

Son estos modelos los llamados a poner orden al momento de desarrollar software. Debido a que anteriormente y en ciertos casos de la actualidad se desarrolla un software sin usar un modelo de desarrollo. Este tipo de modelo ha dado una estructura general para el desarrollo según lo indican los hechos históricos, sin embargo aún se sigue en caos.

A continuación definiremos los modelos de los procesos prescriptivos que se precisan como más comunes:

·        MODELO DE LA CASCADA: En términos menores es aquel que se enfoca en llevar a cabo cada proceso de forma sistemática, es decir ejecuta una acción y una vez finalizada esta, continua con la otra, para mejorar lo antes mencionado observar la siguiente figura:

Este es un modelo que puede ser usado en proyectos pequeños, que no requieran de interactuar varias veces con el cliente, o también en aquellos programas finalizados, para realizarles una mejora.

·         MODELOS DE PROCESO EVOLUTIVO: Son aquellos en que uno o más de los 5 pasos del proceso del desarrollo se lo ejecuta en más de una vez, con el fin de optimizar la función del producto final, y a la vez satisfacer de mejor manera con los requerimientos del cliente para con el software. Debido al avance tecnológico, los requerimientos de la sociedad y de las empresas también es mayor, por lo tanto realizar un buen sistema actualmente se necesita de un adecuado proceso y a veces repetir el mismo para suplir con todas las necesidades. Este tipo de modelos se usa en proyectos de tipo medio y grande, que sería lo ideal para ellos.

Los modelos evolutivos son iterativos es decir, se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. A continuación se presentan dos modelos comunes de proceso evolutivo:

1.    Hacer prototipos: En la mayoría de proyectos es raro que el primer sistema elaborado sea utilizable. Tal vez sea muy lento, muy grande, difícil de usar o todo a la vez. No hay más alternativa que comenzar de nuevo, con más inteligencia, y construir una versión rediseñada en la que se resuelvan los problemas.

      

2.    El modelo espiral: Es aquel que mientras se vaya avanzando en el proyecto, su medida de riesgo va disminuyendo debido a la implementación detallada de cada una de las peticiones que el cliente detalla en la comunicación y posterior a ella, si se da el caso. Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del sistema cuya ingeniería se está haciendo.

     

CONCLUSION.

El uso adecuado de los modelos del proceso del software es la clave para el óptimo provecho de un desarrollador, debido a que es responsabilidad de el mismo cumplir con su deber en el tiempo acordado entre ambas partes, y si no lleva un adecuado modelo, como consecuencia podría obtener un programa no tan satisfactorio para el usuario, ocasionando que el mismo le reclame por incumplimiento al responsable, en este caso deberá realizar correcciones, perdiendo mucho más tiempo de lo planificado, lo que acarrea menos beneficios para el desarrollador.

Tomando en cuenta el tipo de proyecto que se va a llevar cabo, se debe elegir el correcto modelo de los procesos, como se menciona anteriormente cada una de las cualidades de los mismos podremos saber cuál es el ideal para lo que se desea hacer. 

BIBLIOGRAFÍA.

Pressman, R. Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805.

Gutiérrez, D. 2011. Métodos de Desarrollo de Software. (En línea). VE. Consultado, 19 de abril de 2015. Formato PDF. Disponible en: http://www.codecompiling.net/files/slides/IS_clase_13_metodos_y_procesos.pdf