jueves, 29 de septiembre de 2016
MODELO EN CASCADA
Primer modelo empleado.
También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial.
El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores. Esto es utópico debido a que el software tiene un carácter evolutivo, cambiante y difícilmente es libre de errores.3
Si sufre algún cambio durante la ejecución en alguna etapa en el modelo en cascado puro implicaría empezar desde 0 todo el ciclo de nuevo, lo cual implica altos costos de tiempo y desarrollo.1
El modelo consta de las siguientes etapas:
Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios para los que va destinado el sistema. Se busca hacer esta definición lo más detallado posible.
Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican, se describen las abstracciones y relaciones de los componentes del sistema.
Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.
Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.
Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.4
En lugar de usar el modelo en cascada puro, se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida, así no afectando si hay cambios o evoluciones durante el ciclo de vida.
La interacción entre las etapas se muestra en la Figura 1.
Figura1: Modelo en cascada puro.
En la Figura 2 se muestra la misma interacción entre las etapas pero con una realimentación que es como comúnmente se utiliza este método.
Figura 2: Modelo en cascada realimentado.
Ventajas
De partida se cuenta con los requerimientos muy completos y consistentes.
Disminuye el efecto bola de nieve al reducir el mantenimiento considerando que se tienen unas especificaciones completas y correctas.
Desventajas
El prototipo sólo puede ser aprovechado en su aspecto externo. Los aspectos funcionales son muy reducidos.2
El tiempo que se invierte en crear el prototipo incluyendo un costo adicional de la inversión debido a que supone es la creación de un desechable.
MODELO EVOLUTIVO
INCREMENTAL
Introducción:
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:
Método de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Método de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:
Análisis
Diseño
Código
Prueba
imagen.png
Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
ESPIRAL
INTRODUCCIÓN
Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.
definición :
DEFINICION
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.
MODELO DRA
Modelo DRA (Desarrollo Rápido de Aplicaciones):
El modelo DRA, es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto (Es una adaptación a alta velocidad del modelo lineal secuencial). El proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos muy cortos de tiempo.
El DRA comprende las siguientes etapas:
Modelado de Gestión: aquí se modela el flujo de información entre las funciones de gestión. Este flujo debe "responder" a preguntas tales como ¿Qué información conduce el proceso de gestión?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?
Modelado de datos: se definen las características (atributos) de cada objeto, formado a partir del flujo de información, y las relaciones entre ellos.
Modelado del proceso: las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos.
Generación de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de programas ya existentes o crea componentes reutilizables.
Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y probados, lo cual permite que el tiempo de duración de las pruebas sea menor. Todo esto no impide que se tenga que probar cada uno de los nuevos componentes.
Desventajas:
Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el número suficiente de equipos.
Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el tiempo necesario.
No es adecuado cuando los riesgos tecnicos son muy alto.
Representacion Gráfica del Modelo
Primer modelo empleado.
También conocido como modelo clásico, modelo tradicional o modelo lineal secuencial.
El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores. Esto es utópico debido a que el software tiene un carácter evolutivo, cambiante y difícilmente es libre de errores.3
Si sufre algún cambio durante la ejecución en alguna etapa en el modelo en cascado puro implicaría empezar desde 0 todo el ciclo de nuevo, lo cual implica altos costos de tiempo y desarrollo.1
El modelo consta de las siguientes etapas:
Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios para los que va destinado el sistema. Se busca hacer esta definición lo más detallado posible.
Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican, se describen las abstracciones y relaciones de los componentes del sistema.
Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.
Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.
Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.4
En lugar de usar el modelo en cascada puro, se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida, así no afectando si hay cambios o evoluciones durante el ciclo de vida.
La interacción entre las etapas se muestra en la Figura 1.
Figura1: Modelo en cascada puro.
En la Figura 2 se muestra la misma interacción entre las etapas pero con una realimentación que es como comúnmente se utiliza este método.
Figura 2: Modelo en cascada realimentado.
Ventajas
De partida se cuenta con los requerimientos muy completos y consistentes.
Disminuye el efecto bola de nieve al reducir el mantenimiento considerando que se tienen unas especificaciones completas y correctas.
Desventajas
El prototipo sólo puede ser aprovechado en su aspecto externo. Los aspectos funcionales son muy reducidos.2
El tiempo que se invierte en crear el prototipo incluyendo un costo adicional de la inversión debido a que supone es la creación de un desechable.
MODELO EVOLUTIVO
INCREMENTAL
Introducción:
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollocomo una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo se conoce también bajo las siguientes denominaciones:
Método de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Método de atacar el problema por ramas.
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:
Análisis
Diseño
Código
Prueba
imagen.png
Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
ESPIRAL
INTRODUCCIÓN
Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.
definición :
DEFINICION
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.
MODELO DRA
Modelo DRA (Desarrollo Rápido de Aplicaciones):
El modelo DRA, es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto (Es una adaptación a alta velocidad del modelo lineal secuencial). El proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos muy cortos de tiempo.
El DRA comprende las siguientes etapas:
Modelado de Gestión: aquí se modela el flujo de información entre las funciones de gestión. Este flujo debe "responder" a preguntas tales como ¿Qué información conduce el proceso de gestión?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?
Modelado de datos: se definen las características (atributos) de cada objeto, formado a partir del flujo de información, y las relaciones entre ellos.
Modelado del proceso: las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos.
Generación de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de programas ya existentes o crea componentes reutilizables.
Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y probados, lo cual permite que el tiempo de duración de las pruebas sea menor. Todo esto no impide que se tenga que probar cada uno de los nuevos componentes.
Desventajas:
Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el número suficiente de equipos.
Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el tiempo necesario.
No es adecuado cuando los riesgos tecnicos son muy alto.
Representacion Gráfica del Modelo
jueves, 22 de septiembre de 2016
MODELOS DE PROCESOS DE SOFTWARE
DEFINICION DE MODELOS DE PROCESOS DE SOFTWARE
Un proceso de
desarrollo de software tiene como propósito la producción eficaz y eficiente de
un producto software que reúna los requisitos del cliente. Dicho proceso, en
términos globales . Este proceso es intensamente intelectual, afectado por la
creatividad y juicio de las personas involucradas . Aunque un proyecto de
desarrollo de software es equiparable en muchos aspectos a cualquier otro
proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos
adicionales, relativos esencialmente a la naturaleza del producto obtenido. A
continuación se explican algunas particularidades asociadas al desarrollo de
software y que influyen en su proceso de construcción.
Los modelos de
desarrollo de software son una representación abstracta de una manera en
particular. Realmente no representa cómo se debe desarrollar el software, sino
de un enfoque común. Puede ser modificado y adaptado de acuerdo a las
necesidades del software en proceso de desarrollo. 1
Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las
cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado
para sus necesidades. En ocasiones puede que una combinación de varios modelos
sea apropiado.
miércoles, 21 de septiembre de 2016
Nombre.- Cristian Flores Melgar
C.I.: 6844027 L.P.
C.I.: 6844027 L.P.
·
Definición de modelo de proceso de software.
Conjunto estructurado de actividades requeridas para
desarrollar un sistema software.
Ø
Especificación.
Ø
Diseño.
Ø
Validación.
Ø
Evolución.
Las actividades varían dependiendo de la organización y
del tipo de sistema a desarrollarse. Debe estar explícitamente modelado si va a
ser bien administrado.
Los modelos de proceso contienen las instrucciones para
desarrollar una aplicación.
Ø
Como descubrir que tiene que hacer la aplicación.
Ø
Como decidir cómo va a estar estructurada la aplicación.
Ø
Como asegurarse de que la aplicación funciona y hace lo
que tenía que hacer.
Ø
Como ocuparse de que la aplicación se pueda
ampliar/migrar/adaptar.
Los pasos de cada método no son iguales y además hay que
adaptarlas para cada caso, convienen que las instrucciones figuren por escrito.
·
Describir al menos 3 modelos de proceso SECUENCIAL.
Ø Modelos
de proceso Desarrollo rápido de aplicaciones (DRA)
El modelo de desarrollo rápido de
aplicaciones, DRA (RAD – Rapid Application Development) o modelo de la
caja de tiempo surgió como respuesta al modelo formal y al ciclo en espiral
Enfatiza un ciclo de desarrollo
extremadamente corto Modelo funcional en 60 ó 90 días
No es un modelo bien definido. Secuencia
de integraciones de un sistema evolutivo o de prototipos que se revisan con el
cliente descubrimiento de los requisitos.
Cada integración se restringe a un
período de tiempo bien definido (caja de
tiempo)
Características
Modelo secuencial: Separación en fases de cada caja de tiempo
Integraciones constantes
Centrado en el código más que en la documentación
Desarrollo basado en componentes
Uso efectivo de herramientas y frameworks
Modelos de proceso del software 18
Participación activa del usuario
·
Describir al menos 3 modelos de proceso EVOLUTIVO.
Ø
Modelo
Incremental
Es un modelo de tipo evolutivo que
está basado en varios ciclos Cascada realimentados aplicados
repetidamente, con una filosofía
iterativa. El Modelo Incremental combina elementos del MLS con la filosofía
interactiva de construcción de
prototipos.
En una visión genérica, el proceso se divide
en 4 partes: Análisis, Diseño, Código y Prueba.
Sin embargo, para la producción del
Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas
otras formas de programación. Con esto se mantiene al cliente en constante
contacto con los resultados obtenidos en cada incremento.
El Modelo Incremental se puede ver
aquí en forma gráfica:
- Se evitan proyectos largos y se
entrega algo de valor a los usuarios con cierta frecuencia.
- El usuario se involucra más.
- Difícil de evaluar el coste total.
- Difícil de aplicar a los sistemas
transaccionales que tienden a ser integrados y a operar como un todo.
- Requiere gestores experimentados.
- Los errores en los requisitos se
detectan tarde.
- El
resultado puede ser muy positivo.
Ø Modelo
evolutivo Basado en Componentes
Definición:
Un componente es una pieza de código
pre-elaborado que encapsula alguna funcionalidad expuesta a través de interfaces
estándar.
Etapas del modelo evolutivo Basado en
Componentes
PLANEACION: En esta etapa evalúa la
función y el rendimiento que se asignaron al Software durante la Ingeniería del
Sistema de Computadora para establecer un ámbito de proyecto que no sea
ambiguo, e incomprensible.
ANÁLISIS DE RIESGOS: En esta etapa l
analista se encarga de analizar los riesgos que el software a crear estará expuesto
y así encontrar la manera de corregirlos.
CONSTRUCCIÓN Y ADAPTACIÓN DE LA
INGENIERÍA: En esta etapa se construye el software, se prueba si no tiene algún
problema o para detectar errores, sé instala , y luego se le brinda soporte al
cliente.
VALUACIÓN DEL CLIENTE: El cliente
tiene la tarea de evaluar el software para verificar si este cumple con los
requisitos que este proporciono y está en todo la tarea de aprobar o rechazar
el software.
Características
• Es
evolutivo
• Posee un enfoque evolutivo para la
creación de software
• Comienza con la
identificación de las clases más importantes
• Examina los datos que se van a
manejar
• Permite la reutilización del
software
• El ensamblaje de los componentes
reduce el 70 del 100% del tiempo del ciclo del desarrollo del software y un 84
del 100% del costo del proyecto.
·
Describir al menos 3 modelos de proceso AGIL.
En una reunión celebrada en febrero de
2001 en Utah-EEUU, nace el término "ágil" aplicado al desarrollo de
software. En esta reunión participan un grupo de 17 expertos de la industria
del software, incluyendo algunos de los creadores o impulsores de metodologías
de software. Su objetivo fue esbozar los valores y principios que deberían
permitir a los equipos desarrollar software rápidamente y respondiendo a los
cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una
alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rígidos y dirigidos por la documentación que se genera
en cada una de las actividades desarrolladas.
Ø SCRUM
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle.
Define un marco para la gestión de proyectos, que se ha utilizado con éxito
durante los últimos 10 años. Está especialmente indicada para proyectos con un
rápido cambio de requisitos. Sus principales características se pueden resumir
en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints,
con una duración de 30 días. El resultado de cada sprint es un
incremento ejecutable que se muestra al cliente. La segunda característica
importante son las reuniones a lo largo proyecto. Éstas
Ø
Crystal Methodologies
Se trata de un conjunto de metodologías para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo (de
ellas depende el éxito del proyecto) y la reducción al máximo del número de
artefactos producidos.
Han sido desarrolladas por Alistair Cockburn. El desarrollo de
software se considera un juego cooperativo de invención y comunicación,
limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se
deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener
políticas de trabajo en equipo definidas.
Ø
Adaptive Software Development (ASD)
Su impulsor es Jim Highsmith. Sus principales características son:
iterativo, orientado a los componentes software más que a las tareas y tolerante
a los cambios. El ciclo de vida que propone tiene tres fases esenciales:
especulación, colaboración y aprendizaje. En la primera de ellas se inicia el
proyecto y se planifican las características del software; en la segunda desarrollan las
características y finalmente en la tercera se revisa su calidad, y se entrega
al cliente. La revisión de los componentes sirve para aprender de los errores y
volver a iniciar el ciclo de desarrollo.
Ø
Feature-Driven Development(FDD)
Define un proceso iterativo que consta de 5 pasos. Las iteraciones
son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación
del sistema partiendo de una lista de características que debe reunir el software.
Sus impulsores son Jeff De Luca y Peter Coad.
Ø
Lean Development(LD)
Definida por Bob Charette’s
a partir de su experiencia en proyectos con la industria japonesa del automóvil
en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en
Europa. En LD, los cambios se consideran riesgos, pero si se manejan
adecuadamente se pueden convertir en oportunidades que mejoren la productividad
del cliente. Su principal característica es introducir un mecanismo para implementar
dichos cambios.
Suscribirse a:
Entradas (Atom)