Linea De Tiempo

Sistemas Operativos on Dipity.

Modelos De Procesos De Software

Los Modelos De Procesos De Software

• Es una representación abstracta de un proceso del software Cada modelo de proceso representa un proceso desde una perspectiva particular y así proporciona solo una información parcial sobre ese proceso. Es un conjunto de actividades y resultados asociados que conducen a la creación de un producto de software

Imagen: http://scastor.files.wordpress.com/2012/10/vision.jpg

La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software.

Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo. Este documento se conoce como especificación funcional.

Modelos : 

Modelo Lineal Secuencial o De Cascada

Modelo De Contruccion De Prototipos

Modelo De Desarrollo De Aplicaciones

Modelos Evolutivos

Modelos Formales

Click para ver su contenido

imagen: http://us.123rf.com/400wm/400/400/justaa/justaa1204/justaa120400011/13134499-cabeza-humana-con-la-pregunta-de-muchos-el-pensamiento-abstracto.jpg

Bibliografias:

• http://html.rincondelvago.com/modelos-de-procesos-de-software.html
• http://www.portaleducativo.hn/pdf/aplicandomodelosprocesossoftwarehipermedia.pdf
• http://avellano.usal.es/~mmoreno/ASTema2.pdf
• http://www.youtube.com/watch?v=3snLZQ0Zg-U
• http://www.youtube.com/watch?v=9ZyeCvGy5aQ
• http://www.youtube.com/watch?v=aGXixpsRxjE
• http://www.ctic.uni.edu.pe/files/insoft01.pdf
• http://ocw.um.es/ingenierias/fundamentos-de-ingenieria-del-software/material-de-clase/skinless_view
• http://www.kybele.etsii.urjc.es/docencia/IS4/2012-2013/Material/IS4.11.12.TEMA%20II%20Ciclo%20de%20vida%20del%20Sw.pdf
• http://es.scribd.com/doc/21945705/Resumen-de-Modelos-de-Procesos-de-Software
• http://es.scribd.com/doc/94934934/MODELOS-DE-PROCESOS-DE-INGENIERIA-DE-SOFTWARE

Autores: John Alexander Montaño

              Harol Sastoque

Modelos Formales

Modelos Formales

Es un camino a la construcción y análisis de modelos matemáticos que permitan una automatización del desarrollo de sistemas informáticos. Los métodos formales se caracterizan por emplear técnicas y herramientas matemáticas para lograr una facilitación a la hora de encarar la construcción o el análisis de un modelo matemático de un sistema.

Se pueden encontrar multitud de métodos y técnicas formales con lo que los criterios de clasificación son bastante variados. 

El uso de métodos formales está creciendo en el área del desarrollo de sistemas críticos, en donde las propiedades emergentes del sistema tales como seguridad, fiabilidad y protección son muy importantes. El alto coste de los fallos de funcionamiento en estos sistemas implica que las compañías están dispuestas a aceptar los costes elevados iniciales de los métodos formales para asegurar que su software es tan confiable como sea posible.

imagen: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmA9ZgXT_zVMPEPxxCkXv9LKATLOdpY26H5IEbl6hXYcH85U2419mE0wJcDaRsjpD_yffIUxWDah8RThMt-4dnMIF6JBUTXVqJUDEajtLzCdlSXTFNwVvhW_wSKXueLki4GM52SWKLGHma/s1600/Imagen1.png

Ventajas:

• Se comprende mejor el sistema.
• La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario.
• El sistema se describe de manera más precisa.
• El sistema se asegura matemáticamente que es correcto según las especificaciones.
• Mayor calidad software respecto al cumplimiento de las especificaciones.
• Mayor productividad

Desventajas

• El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios.
• Los investigadores por lo general no conocen la realidad industrial.
• Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático.
• Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

Bibilografia: http://es.wikipedia.org/wiki/M%C3%A9todo_formal

Modelos Evolutivos

Modelos Evolutivos 

El software, al igual que todos los sistemas complejos, evoluciona con el tiempo. El modelo lineal secuencial se diseña para el desarrollo en línea recta. En esencia, este enfoque en cascada asume que se va entregar un sistema completo una vez que la secuencia lineal se haya finalizado. El modelo de construcción de prototipos se diseña para ayudar al cliente (o al que desarrolla) a comprender los requisitos. En general, no se diseña para entregar un sistema de producción. En ninguno de los paradigmas de ingeniería del software se tiene en cuenta la naturaleza evolutiva del software. Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más completas del software.

imagen: http://www.saludalia.com/Uploads/saludalia.com/Imagenes/pensamiento.jpg

Modelo Espiral

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.

Grafico:

Cada vuelta se divide en 4 sectores:

• Planeación : determinación de los objetivos, alternativas y restricciones
• Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos
• Ingeniería : desarrollo del producto hasta "el siguiente nivel".
• Evaluación : valoración por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez más completas.

Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de los resultados del software.

Ventajas

• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
• El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
• En la utilización de grandes sistemas a doblado la productividad.

Desventajas

• Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
• Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos

Modelo Concurrente

El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.

imagen: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjb_-ofUPkvunSUS4tA3IxvQAnvHQtcG4kHd81j1croSTvuG3vjdveQ969gLRDFda96aYG2rVY1XYAWDMZeQa21Hz8lTQipp7qQfUKIJULcEJdDIPHpgArY7tk_hpb4WP34YVCWAIjrNmI/s1600/concurrente.gif

La imagen anterior proporciona una representación esquemática de una actividad(análisis) como se puede observar todas las actividades existen concurrentemente, pero residen en estados diferentes, al principio es la comunicación con el cliente (no esta plasmada en la figura) y esta en estado de cambios en espera.La actividad de análisis esta en ninguna significa que ya se ha hecho la comunicación con el cliente luego hace una transición al estado bajo desarrollo. sin embargo si el cliente indica que se deben hacer cambios en requisitos , la actividad de análisis cambia del estado bajo desarrollo al estado cambios en espera.

El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software.

Características:

• se puede expresar de manera esquematizada
• las actividades llevan procesos concurrentes
• es aplicable a todo tipo de desarrollo de software
• es un modulo aplicable para cliente soñador
• esta dirigido por las necesidades del usuario
• es aplicable al cliente servidor

Ventajas:

• Excelente para proyectos en los que se conforman grupos de trabajo independientes.
• Proporciona una imagen exacta del estado actual de un proyecto.

Desventajas:

• Si no se dan las condiciones señaladas no es aplicable.
• Si no existen grupos de trabajo no se puede trabajar en este método

Modelo Incremental

El Modelo Incremental para el desarrollo del software, consiste en crear funcionalidad por pequeña que sea de modo que a partir de ella, las creaciones posteriores en base a la que primero fue creada, tendrán una característica (o características) funcionales, lo cual hace que se constituya en base a elementos que funcionan y que va siendo cada vez más compleja su funcionalidad.

Los avances son entregados mediante fechas programadas, de modo que cada incremento posee nuevas funcionalidades a comparación de un incremento anterior.

Este modelo posee etapas tales como:

• Definición de requirimientos
• Asignar los requerimientos a los incrementos.
• Diseño del incremento a partir de los requirimientos.
• Desarrollo del incremento.
• Validar incrementos.
• Integrar incrementos.
• Validar funcionamiento.

Las ideologías del modelo incremental pretende dar pautas en la creación del software mediante incrementos pequeños, permitiendo su fácil administración, así como su sencilla comprensión y sus correspondientes pruebas, esto implica que el desarrollo inicial se logra más temprano obteniendo resultados de inversión en poco tiempo, otro aspecto a considerar es que este modelo se presta a posibles cambios debido a que los incrementos de van adaptando de acuerdo a los requerimientos que se obtienen en base a las nuevas necesidades que van surguiendo.

imagen: http://ldc.usb.ve/~vtheok/cursos/ci3711/apuntes/99-01-14/Info/esquema5.gif

Ventajas:

• Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
• También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
• El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
• Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
• Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
• Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.
  
  

Desventajas:

• El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
• Requiere de mucha planeación, tanto administrativa como técnica.
• Requiere de metas claras para conocer el estado del proyecto.

Modelo De Desarrollo Rapido De Aplicaciones

Modelo De Desarrollo Rapido De Aplicaciones (DRA)

El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoquede construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases: Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas:

¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

imagen: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRhkXpg-5tKJo_-e-GUmwHx4mLAPaECvSfWvifnYle87sZjJPuRKUpXqqKq03alZzNYwz5UTseUvrZAAJZNc7-IMXJP9id0ITm9gh9N6t_RyFB1yAvmAgxcg3g5V2AzOjGijiq8r6XZDU/s1600/rda.png

Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o

recuperar un objeto de datos. Es la comunicación entre los objetos.

Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Características De Rad

Entre las principales características del RAD tenemos:

·         Equipos Híbridos

o   Equipos compuestos por alrededor de seis personas, incluyendo

o   desarrolladores y usuarios de tiempo completo del sistema así como

o   aquellas personas involucradas con los requisitos.

o   Los desarrolladores de RAD deben ser "renacentistas": analistas,

o   diseñadores y programadores en uno.

·         Herramientas Especializadas

o   Desarrollo "visual"

o   Creación de prototipos falsos (simulación pura)

o   Creación de prototipos funcionales

o   Múltiples lenguajes

o   Calendario grupal

o   Herramientas colaborativas y de trabajo en equipo

o   Componentes reusables

o   Interfaces estándares (API)

o   Control de versiones

·         "Timeboxing"

o   Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

·         Prototipos Iterativos y Evolucionarios

o   Reunión JAD (Joint Application Development):

§  Se reúnen los usuarios finales y los desarrolladores.

§  Lluvia de ideas para obtener un borrador inicial de los requisitos.

o   Iterar hasta acabar:

o   Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.

o   Los diseñadores revisan el prototipo.

o   Los clientes prueban el prototipo, depuran los requisitos.

o   Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar solicitudes de cambios.

o   Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es necesario para cumplir el calendario.

·         Notas:

o   Cada iteración dura entre un día y tres semanas.

o   Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.

Ventajas de RAD

·         Comprar puede ahorrar dinero en comparación con construir.

·         Los entregables pueden ser fácilmente trasladados a otra plataforma.

·         El desarrollo se realiza a un nivel de abstracción mayor.

·         Visibilidad temprana.

·         Mayor flexibilidad.

·         Menor codificación manual.

·         Mayor involucramiento de los usuarios.

·         Posiblemente menos fallas.

·         Posiblemente menor costo.

·         Ciclos de desarrollo más pequeños.

·         Interfaz gráfica estándar.

Desventajas de RAD

·         Comprar puede ser más caro que construir.

·         Costo de herramientas integradas y equipo necesario.

·         Progreso más difícil de medir.

·         Menos eficiente.

·         Menor precisión científica.

·         Riesgo de revertirse a las prácticas sin control de antaño.

·         Más fallas (por síndrome de "codificar a lo bestia").

·         Prototipos pueden no escalar, un problema mayúsculo.

·         Funciones reducidas (por "timeboxing").

·         Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales.

Modelo De Construcción de Prototipos

Modelo De Construcción de Prototipos:

 El Modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros podemos iniciar el verdadero desarrollo del software.

imagen:http://upload.wikimedia.org/wikipedia/commons/3/3f/Construccion_de_prototipos.JPG

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

imagen:http://kaprilindustrial.com/imagenes/uc.jpg

Características:

Consiste en construir un prototipo que sirva para identificar los requisitos del software antes de desarrollar la aplicación definitiva. Los prototipos se construyen y supervisan con la ayuda de los usuarios, siendo, por tanto, una técnica orientada al USUARIO. 

Además, permite abordar riesgos tecnológicos del proyecto antes de su desarrollo,Por otro lado, facilita la creación de un modelo del software que se tiene que construir. Puede tener una de las formas siguientes:

•  o En papel o un modelo basado en computador que describa la interacción hombre/máquina de forma que dé al usuario una idea básica de cómo se realizará la interacción. 
• o Un prototipo que implemente algunas de las funcionalidades del sistema. o Un prototipo que ejecute parte o toda la funcionalidad deseada pero con características por mejorar.
• Tipos de prototipos: 
•  Evolutivos: Se van añadiendo funcionalidades hasta que el prototipo se convierte en el sistema final.
• Desechables: Se utiliza para determinar las necesidades del usuario y todo o parte de él es re diseñado con el objetivo de obtener un sistema más eficiente. 
• Totales: Se construye para el sistema completo. 
• Parciales: Se construye sólo para modelar una parte del sistema.

imagen: http://usaconet.com/img/ventajas_img.png

Ventajas:

• Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
• También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

imagen: http://www.zonalibreinfo.com/images/ventajas-zonalibre.jpg

Desventajas:

• El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función.
• Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.
• En áreas de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.
• Porque es muy difícil y complejo realizarlo.

imagen: https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcR29wswxtXowSboR8EjvwqKch5Q95kEj18hdEiSpNByjjd8Ld8J

Modelo Lineal O Cascada

Modelo Lineal Secuencial De Cascada

Modelo mas antiguo de todos los modelos de ingeniería de software, este presenta una estructura secuencial, es decir que el producto evoluciona a través de una secuencia de faces ordenadas en forma lineal, permitiendo interacciones al estado anterior.

Grafico:

Imagen: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKAPlgCzn08VqLQPX2KzAMPLgWwG2HJxfon6Cl5sra9_JL_laYdu2DrWaGbvf1eeLMEGSfVxDPrH6QiQbZVgojzduTzFFBeVkIpFHW2dv2DXFv3d8JES4eyF0tysKyV03_2qak4HXeJ1Y/s1600/modelo-en-cascada.png

Análisis de requerimientos

Esta es una fase muy importante ya que en esta se analizan las necesidades primordiales de los usuarios finales del software para determinar los requerimientos que debe cubrir. En consecuencia surge un documento de especificación de requisitos en el cual plasmamos la especificación completa de lo que nuestro software deberá realizar.
Esta fase es primordial para las siguientes etapas ya que a mitad del proceso de elaboración no podrán agregarse requerimientos del software.

Diseño del sistema

En esta fase se realiza un segmentado del sistema por módulos para su tratamiento por separado con la finalidad del desarrollo en equipo, esta labor trae como consecuencia el documento de diseño del software  la cual contiene la descripción de la estructura global del sistema y la especificación de la función que cumple cada uno de los módulos, así como comunicación entre las mismas.

Imagen: http://cabezasgraficas.com.ar/wp-content/uploads/2011/07/diseno_grafico1.jpg

Esta fase se caracteriza por el desarrollo de los algoritmos para el cumplimiento de los requerimientos del usuario así como saber escoger las herramientas de desarrollo para la codificación respectiva.

Implementacion

En esta fase donde se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

imagen: http://www.neosistemassrl.com/neosistemas_15/images/stories/implementacion-de-software.png

Pruebas

En esta fase se ensamblan todos los módulos, elementos del sistema ya programados y se comprueba correcto funcionamiento de este y que cumple con los requisitos.

Mantenimiento

Esta viene a ser la fase final del modelo en la cual se da el respectivo soporte al sistemas así como el mantenimiento respectivo.

imagen: https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcRcipLqCqvV6uNEibQ2t9A_0spAsGlGwhF60Wr9OaKDXDzarhfo

Con esta metodología los errores de diseño detectados en la etapa de pruebas se someten a un rediseño lo cual trae como consecuencia el incremento de los costes del desarrollo, para un mejor entendimiento procederemos a explicar cada una de las fases de este método.

Caracteristicas:

• Cada face empieza cuando ha terminado la anterior
• es util como control de fechas de entrega
• al final de cada fase el personal tecnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto

Ventajas:

• La documentacion se produce en cada fase y que este cuadrada con otros procesos de ingenieria

Desventajas:

• Su inflexibilidad al dividir el proyecto es distintas etapas
• Se debe hacer compromisos en la etapas iniciales, lo que hace dificil responder a los cambios en los requerimientos del cliente