Modelos
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Modelos

on

  • 259 views

 

Statistics

Views

Total Views
259
Views on SlideShare
254
Embed Views
5

Actions

Likes
0
Downloads
11
Comments
0

1 Embed 5

http://aspectosanalistadesistema.blogspot.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Modelos Document Transcript

  • 1. Universidad Regional Autónoma de los Andes “UNIANDES”     Facultad: Sistemas Mercantiles Carrera: Sistemas Materia: Desarrollo de Proyectos informáticos   Docente: Ing. Julieta Campi M. Alumno: Jonathan Cevallos G. Nivel: 6 Semestre
  • 2. Modelo Cascada En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el                              enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de                          software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa                                    anterior. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce                            necesariamente al rediseño y nueva programación del código afectado, aumentando los costos                        del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el                                esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. ● Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un                              sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos                        del sistema y luego asignando algún subconjunto de estos requisitos al software. ● Análisis de los requisitos del software: El proceso de recopilación de los requisitos se                            centra e intensifica especialmente en el software. El ingeniero de software debe                        comprender el ámbito de la información del software, así como la función, el rendimiento                            y las interfaces requeridas. ● Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la                            estructura de los datos, la arquitectura del software, el detalle procedimental y la                          caracterización de la interfaz.  ● Codificación: el diseño debe traducirse en una forma legible para la máquina. El paso de                              codificación realiza esta tarea. 
  • 3. ● Prueba: La prueba se centra en la lógica interna del software, y en las funciones                              externas, realizando pruebas que aseguren que la entrada definida produce los                      resultados que realmente se requieren. ● Mantenimiento: El software sufrirá cambios después de que se entrega al cliente. Los                          cambios ocurrirán debido a que hayan encontrado errores, a que el software deba                          adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o                        debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Modelo Espiral El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso                              de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los                            aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el                      potencial para el desarrollo rápido de versiones incrementales del software que no se basa en                              fases claramente definidas y separadas para crear un sistema. 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. Tipos El modelo espiral tuvo varias modificaciones que son: ● Modelo Original de Boehm. ● Modelo Tipico de Seis Regiones. ● Modelo WINWIN. Modelo original BOEHM No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión                              de proyecto.
  • 4. Cada vuelta se divide en 4 sectores: ● Planificació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. Modelo Típico de seis regiones A diferencia del modelo de proceso clásico que termina cuando se entrega el software, el                              modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de                                computadora. Una visión alternativa del modelo en espiral puede ser considerada examinando el                          eje de punto de entrada en el proyecto. Las regiones de tareas que componen este modelo son: ● Comunicación con el cliente: las tareas requeridas para establecer comunicación entre                      el desarrollador y el cliente.
  • 5. ● Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones                        relacionadas con el proyecto. Son todos los requerimientos. ● Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras                        informaciones relacionadas con el proyecto. ● Ingeniería: las tareas requeridas para construir una o más representaciones de la                        aplicación. ● Construcción y adaptación: las tareas requeridas para construir, probar, instalar y                      proporcionar soporte al usuario. ● Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la                            evaluación de las representaciones del software creadas durante la etapa de ingeniería e                          implementación durante la etapa de instalación. Modelo WINWIN El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al                              principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación                              con el cliente se definen las siguientes actividades: ● Identificación del sistema o subsistemas clave de los directivos. ● Determinación de las condiciones de victoria de los directivos.
  • 6. ● Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto                            de condiciones para todos los afectados (incluyendo el equipo del proyecto de software). El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que                                ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de                              decisión antes de continuar el proyecto de 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.
  • 7. ● Modelo costoso. ● Requiere experiencia en la identificación de riesgos. Modelo Prototipo El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El                                prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar                                muchos recursos. 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. 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.
  • 8. ● 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. 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. Modelo Orientado a hitos Consiste en introducir hitos entregables al cliente durante el desarrollo del proyecto.
  • 9. Ventajas  El cliente va viendo los resultados.  Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor  prioridad con esta técnica. Desventajas Se analiza todo el sistema al principio, y se puede perder mucho tiempo en la especificación y  diseño de funcionalidades que al final no nos da tiempo a implementar. Modelo de Transformación (Evolutivo) El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va                                refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del                              usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de                            separarse. Existen dos tipos de desarrollo evolutivo: 1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para                            explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del                              sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos                      propuestos por el cliente. 2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es                        comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los                          requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos                          del cliente que no se comprenden del todo. Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas                                en comparación con un enfoque en cascada ya que el sistema se va ajustando a las                                necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin                              embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos                            grandes problemas: 1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir                              el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos                          que reflejen cada versión del sistema.
  • 10. 2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a                            corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en                              una tarea difícil y costosa. Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas                        pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo                            dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que                                puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo                            mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada. Modelo Mixto El modelo de desarrollo mixto combina dos o más modelos de desarrollo de software. Entre                              estos modelos tenemos el modelo incremental. El modelo incremental es una unión de las mejores funcionalidades del modelo de cascada y                              del modelo de prototipos. A medida que se presenta un prototipo se produce un “incremento”,                              que es una iteración del proceso anterior pero aplicando las experiencias aprendidas del                          proceso anterior. A diferencia del modelo de prototipos, los prototipos de este modelo están                            orientados a ser operacionales en cada incremento y no ser solo una “previa” de cómo sería el                                  sistema en su versión final.