You are on page 1of 12

Metodología

Modelo en
cascada

Características
Similares
Las características de éste
modelo similares a otras
metodologías
son las
siguientes:
Inicia con la especificación de
requerimientos del cliente y
continúa con la planeación, el
modelado, la construcción y el
despliegue para culminar en el
soporte
del
software
terminado.
Las características similares
de ésta metodología a las
otras, se basa prácticamente
en el método que se usa y el
objetivo que se busca al
implementar ésta metodología
de Software.
Se puede decir que como las
demás metodologías tienen un
proceso
en
el
cual,
primeramente es la entrevista
con el usuario para establecer
las
necesidades
y

Características Principales
Desarrollo en cascada, también
llamado modelo en cascada, es el
enfoque metodológico que ordena
rigurosamente las etapas del
ciclo de vida del software, de tal
forma que el inicio de cada etapa
debe esperar a la finalización de
la inmediatamente anterior.

Es el más utilizado.

Es
una
visión
del
proceso de desarrollo de
software
como
una
sucesión de etapas que
producen
productos
intermedios.

Para que el proyecto
tenga
éxito
deben
desarrollarse todas las
fases.
Las fases continúan
hasta que los objetivos

1

Ventajas

Desventajas

Se tiene todo bien
organizado y no se
mezclan las fases.
Es perfecto para
proyectos que son
rígidos, y además
donde
se
especifiquen
muy
bien
los
requerimientos y se
conozca muy bien la
herramienta a utilizar.

La planificación
sencilla.

La
calidad
del
producto resultante
es alta.

Iteraciones costosas.

Los
problemas
presentan son
posteriormente.

Puede que el software no
cumpla con los requisitos.

Es difícil incorporar nuevas
cosas si se quiere actualizar.

Es normal detenerse en su
desarrollo y seguir con otras
fases.

Se tarda mucho tiempo en
pasar por todo el ciclo.

Las revisiones de proyectos
de gran complejidad son muy
difíciles.

es

Sus
fases
son
conocidas por los
desarrolladores.

que
se
corregidos

así también el Modelo en Cascada. comenzando por el bucle interior. Requiere una considerable habilidad para la evaluación del riesgo. El modelo en espiral puede aplicarse a lo largo de la vida del software. y cuenta con esta habilidad para el éxito. . Las actividades de este modelo se conforman en una espiral. Después de este ciclo se lleva a cabo otro en el cual después de ésta entrega y la valoración del usuario.requerimientos. se implementa y el usuario lo valida haciendo los comentarios y modificaciones pertinentes. para seguir con el diseño la codificación y la evaluación por parte del Cliente. Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Modelo de proceso adaptable. El desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. En cada giro se construye un 2 El modelo en espiral es un enfoque realista del desarrollo de sistemas. se realizan los mismos pasos desde el inicio para hacer una modificación o Los usuarios lo pueden comprender fácilmente. el producto final será de inferior calidad. Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori. de Análisis de requisitos Diseño del Sistema Diseño del Programa Codificación Pruebas Implantación Mantenimiento Es un modelo de proceso de software evolutivo. sino que las siguientes se eligen en función del análisis de riesgo. FASES Las fases del método desarrollo en cascada son:        Modelo Vida Espiral Las características similares de ésta metodología a las otras es que como en las demás se lleva acabo un etapa en la que se inicia con entrevistas al cliente o usuario. después se diseña. se han cumplido. indudablemente surgirán problemas. Si un riesgo importante no es detectado y gestionado a tiempo. Es nuevo y no se ha utilizado tanto como otros modelos de ciclo de vida.   Si se cambia el orden de las fases. desarrollado por primera vez por Barry Boehm en 1988.

El análisis de riesgo requiere la participación de personal con alta calificación. Elimina errores y alternativas no atractivas al comienzo. la construcción de prototipos se torna problemática por las siguientes razones:  El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido con “chicle y . Mejor modelo para el desarrollo de grandes sistemas. son apropiados. Sin embargo. Las iteraciones debe decidirlas el equipo de gestión de proyecto. Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada. Modelos evolutivos como el espiral.  No modifica el flujo del ciclo de vida. el desarrollador y el cliente definen los objetivos globales para el software. Trata de mejorar los ciclos de vida clásicos y prototipos. particularmente para el desarrollo de Sistemas OO. Incorpora objetivos de calidad y gestión de riesgos. Este es el enfoque más realista actualmente.reajuste al programa. Permite acomodar otros modelos.  Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. originándose un diseño rápido que se centra en una representación de esos aspectos del software que sean visibles para el usuario/cliente. evolutivo).  De este diseño surge la 3 Reduce costos y A los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Ayuda al desar rollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los Este modelo comienza con la recolección de requisitos. Modelo en Construcción de Prototipos Las características que hacen similar ésta metodología alas demás son las siguientes: Se puede utilizar como un modelo del proceso independiente. Más realista que el ciclo de vida clásico. nuevo modelo del sistema completo. 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. No hay un número definido de iteraciones.

 Exige disponer de las herramientas adecuadas. aumenta la probabilidad de éxito. cable para embalaje”.  El desarrollador puede caer en la tentación de aumentar el prototipo para construir el sistema final sin tener en cuenta las obligaciones de calidad y de mantenimiento que tiene con el cliente. de procesamiento distribuido. Se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido). Pero reutilizables. se construye el producto de ingeniería. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos es escrito al capturar todos los requerimientos 4 El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:  Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.requisitos estén satisfechos.  Una vez identificados todos los requisitos mediante el prototipo. Una forma de recudir los riesgos es construir solo una parte del sistema.  Modelo Incremental Se entrega software “por partes funcionales más pequeñas”. Este proceso se repite Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. a los cuales seles llama incrementos. de alto nivel de seguridad.  Al ir desarrollando parte de las El modelo incremental no es recomendable para casos de sistemas de tiempo real. reservando otros aspectos para niveles posteriores. La interacción ocurre cuando el prototipo satisface las necesidades del cliente.  No presenta calidad ni robustez.Esto se realiza al estar escuchando los requerimientos por parte del Usuario o por parte del Cliente construcción de un prototipo y este es evaluado por el cliente/usuario. y/o de alto índice de riesgos. y puede decepcionarse al indicarle que el sistema aun no ha sido construido. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). .

Así.  Si un error importante es realizado. El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos: Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande. El desarrollo incremental no demanda una forma especifica de observar el desarrolló de algún otro incremento. es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Al ir desarrollando parte de las funcionalidades. para el sistema completo. solo la última iteración necesita ser descartada. el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Si un error importante es 5 .después de la entrega de cada incremento mientras no se haya elaborado el producto completo. solo la última iteración necesita ser descartada. pueden ser arreglados antes del comienzo del próximo incremento. es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Cada incremento se construye sobre aquel que ya fue entregado. Aplica secuencias lineales de manera escalonada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremente del sistema decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.  Si un error importante es realizado. Si un error importante es realizado.  Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremente del sistema decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.  Los errores de desarrollo realizados en un incremento. funcionalidades. el incremento previo puede ser usado.

Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). pueden ser arreglados antes del comienzo del próximo incremento. Diseño.  Método pesado Por el grado de complejidad puede ser no muy adecuado.  En proyectos pequeños. Construcción y Transición. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos.  Por el grado de complejidad puede no resultar muy adecuado. es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios. Requiere conocimientos del proceso y de UML. El RUP es generalmente mal aplicado en el estilo cascada. 6 Coste del riesgo a un solo incremento. el incremento previo puede ser usado. Es un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Y también como característica similar a los de más es que ésta metodología es iterativo e incremental ya que después de cada siclo se le hacen modificaciones al programa  El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio. . Elaboración.realizado.  Se adapta mejor a las necesidades del cliente.  Hay certificaciones RUP.  Tiene las desventajas del modelo espiral debido a las iteraciones en cada ciclo y puede tomar mucho más tiempo. Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.  Reduce el riesgo de no sacar el producto en el calendario previsto. Proceso Unificado de Desarrollo Las siguientes características son las que hacen a ésta metodología muy similar a las demás: La arquitectura del proceso se modela con orientación a objetos. Los errores de desarrollo realizados en un incremento.  Acelera el ritmo de desarrollo.

acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso común. el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. el sistema va creciendo después de cada entrega al cliente y nadie puede decir que el cliente no querrá una función más. el código es sencillo y entendible. se necesita de la presencia constante del usuario. Orientado a Objetos. además de la poca documentación a elaborar Las desventajas son que no se tiene la definición del costo y el tiempo de desarrollo. lo cual en la realidad es muy difícil de lograr. algunos desarrolladores son . Programación Extrema X. pues este quién desde un principio establece y define los requisitos del Así. Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del cliente. para lograrlo se deben tomar en cuenta cuatro valores 7 Una de las ventajas de la programación extrema es que se adapta al desarrollo de sistemas pequeños y grandes. Otra desventaja es la programación en parejas. la XP se puede definir como un conjunto de pasos de diversas metodologías. para realizar un desarrollo más agradable y sencillo.  Preparado para desarrollar grandes y complejos proyectos. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas. permite realizar el desarrollo del sistema en parejas para complementar los conocimientos. Utiliza el UML como lenguaje de representación visual.  Unifica los mejores elementos de metodologías anteriores.P Las características similares de ésta metodología con algunas de las otras son las siguientes: Para el desarrollo de ésta aplicación se lleva a cabo una planificación en donde se tiene contacto directo con el cliente.Implementación y Prueba. optimiza el tiempo de desarrollo.

Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar. Durante la vida del Software se llevan a cabo pasos biendefinidos como cualquier otrametodología de programac ión endonde u para la elaboración de éste existe una organización de los desarrolladores fundamentales: Comunicación Es muy importante que haya una comunicación constante con el cliente y dentro de todo el equipo de trabajo. Satisfacción del programador. El diseño debe ser sencillo y amigable al usuario. También se refiere a tener la persistencia para resolver los errores en la programación. el código debe ser simple y entendible. entendible y que se entregue al cliente lo que necesita.Software. Menor taza de errores. Coraje. debe ser eliminado. por lo mismo. . Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó con tanto esfuerzo. éste debe ser fácil. de esto dependerá que el desarrollo se lleve a cabo de una manera sencilla. programando sólo lo necesario y lo que se utilizará. Retroalimentación Es la comunicación constante entre el desarrollador y el usuario. Simplicidad En la XP se refiere que ante todo y sin importar qué funcionalidad requiera el usuario en su sistema. celosos del código que escriben y no les es grato que alguien más modifique las funciones que realizó o que su código sea desechado por no cubrir el estándar. el desarrollador debe saber cuando el código que desarrolló no es útil en el sistema y. Dentro de la programación 8 para el desarrollo del sistema.    Programación organizada.

Dentro de cada Sprint se denomina el Scrum 9 La primera y la que. Integración continúa 6. Problemas derivados de la comunicación oral. a partir del concepto o visión de la necesidad del cliente. Comparte los principios estructurales del desarrollo agial. algo dicho es muy fácil crear ambigüedad.extrema se tiene 12 principios que llevan o guían el desarrollo con esta metodología: 1. construye el producto de forma incremental a través de iteraciones breves que comprenden fases de especulación exploración y revisión. si quiere colaborar. implementación y demás cuestiones técnicas. estas iteraciones. prácticas de desarrollo. puede observar como va avanzando el proyecto. Scrum es Enfatiza valores y prácticas de gestión. conocidas como Sprint. Refactorización 7. es tan importante realizar una buena recolecta de requisitos. Metáfora 10. Proceso de planificación 3. Estándar de codificación 12. No hace falta decir que algo que está escrito “no se puede borrar”. Falta de reusabilidad derivada de la falta de documentación. es que estas metodologías ofrecen una rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo. opinar sobre su evolución gracias a las numerosas reuniones que Restricciones en cuanto a tamaño de los proyectos. Si un proyecto ágil fracasa no hay documentación o hay . Programación en parejas 5. Fuerte dependencia de las personas. El cliente. Entregas pequeñas 8. Al no haber documentación es el código (junto con sus comentarios) lo que se toma como documentación. sin pronunciarse sobre requerimientos. motivación. La semana de 40 horas Metodología SCRUM Esta metodología se caracteriza con las demás porque durante el desarrollo de Software hay etapas interactivas e incrementales basadas en practicas agiles. como después poder modificarlos evitando grandes pérdidas en cuanto a costes. Propiedad colectiva del código 11. y por supuesto. tiempo… Falta de documentación del diseño. El cliente en el lugar 4. Diseño simple 9. Problemas derivados del fracaso de los proyectos ágiles. El principio de pruebas 2. a mi parecer es la más importante. Desarrollo de software iterativo incremental basado en prácticas agiles Iteraciones de treinta días. aunque se pueden realizar con más frecuencia. Hace uso de Equipos autodirigidos y auto-organizados Puede ser aplicado teóricamente a cualquier contexto en donde un grupo de gente necesita trabajar junta para lograr una meta común. en cambio. Estas iteraciones (en Scrum llamadas sprints) se repiten de forma continua hasta que el cliente da por cerrado el producto.

los cambios que quiera realizar el cliente van a tener un menor impacto. Uniendo las dos anteriores. pero también tienen características 10 . lo mismo ocurre con el diseño. conlleve la pérdida de todo ese trabajo. se puede deducir que al utilizar estas metodologías. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Esto le da tranquilidad. y si éste quiere cambiarlo. Importancia de la simplicidad al eliminar trabajo innecesario ¿Qué es lo que pudiste observar mediante la tabla respecto a las características de los modelos? Las metodologías de desarrollo de Software son una herramienta indispensable para poder llevar a cabo el desarrollo de las aplicaciones. muy poca. eso quiere decir que el equipo ha estado trabajando meses para que luego un mínimo cambio que quiera realizar el cliente. ya que se va a entregar en un pequeño intervalo de tiempo un pequeño “trozo” del proyecto al cliente. solo se habrá perdido unas semanas de trabajo. Se convocan diariamente un “Scrum Daily Meeting” el cual representa una reunión de avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las tareas de los recursos y los obstáculos que se presentan. La comprensión del sistema se queda en las mentes de los desarrolladores. Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización de una gran parte del proyecto. Master al Líder de Proyecto quien llevará a cabo la gestión de la iteración. En la cual se responden preguntas como: ¿Qué has hecho desde el último encuentro? ¿Qué obstáculos hay para cumplir la meta? ¿Qué harás antes del próximo encuentro? realiza el equipo con el cliente. todas tienen una características principal que es lo que las hacen diferentes.un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto.

Pero por esto pueden llegar a pasarse por alto la calidad del software global o el mantenimiento a largo plazo. Y tiene un alto grado de participación del usuario. El primer incremento satisface los requisitos más críticos. El MODELO BASADO EN PROTOTIPOS. .Puede ser difícil ajustar los requisitos a los incrementos. constituye la metodología estándar más utiliza para el análisis. cliente debe ser gran conocedor del sistema. se enfoca fuertemente sobre la arquitectura del software. La metodología que creo que es la más funcional es la metodología RUP esto porque la metodología de RUP (Scrum) y junto con el lenguaje Unificado de Modelado UML. yo veo que cualquiera de ellas puedes usarse para el desarrollo de una aplicación pero si estas se analizan detalladamente se da uno cuenta que tiene ventajas y desventajas y es cuando el desarrollador tiene que dedicarle mucho estudio en cual es la que mas le conviene tanto a uno como programador y poder establecer y seguidamente cuál va a ser la mejor metodologías para que se le pueda adaptar al proyecto del cliente o usuario. las reglas del juego. Originalmente se diseñó un proceso genérico y de dominio público. Los primeros incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos. implementación y documentación de sistemas orientados a objetos. Empezaremos con el modelo en cascada es muy interesante porque desde el principio se tiene contacto con el cliente y se va desarrollando el Software por etapas que esto es lo interesante pero ya esta metodología ya casi no se esta usando ya que los actuales software requieren de metodologías mas avanzadas para que soporten programas más elaborados para que se vayan involucrando más programadores. La programación extrema es una programación que se plantea muy interesante. La clave del éxito de este modelo consiste en definir bien. sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Cada una de estas metodología tienen sus particularidades. desde el principio. esto debido a que durante la programación se involucra al Cliente o al Usuario y se siente parte del equipo de trabajo y se tiene la información a la mano de los requerimientos que deberá llevar el Software a desarrollarse. la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Optimiza los tiempos de respuesta a los requerimientos del cliente y facilita la labor del programador pues hay un alto aprovechamiento del código. hasta que el cliente acepta la aplicación y se da por concretado el proyecto. El MODELO INCREMENTAL O EVOLUTIVO. Requiere comunicación permanente con el cliente por lo tanto si se cambia el contacto con el cual se realiza desarrollo es necesario que esté al tanto de lo realizado y lo pendiente. El cliente puede hacer pensar que el prototipo es una versión acabada. Las herramientas elegidas pueden ser inadecuadas. Existe un riesgo bajo de fallar en el proyecto total. para su implementación se hace a través de cuatro etapas o fases y en cada una de estas etapas es desarrollada mediante el ciclo de iteraciones. Los servicios del sistema con la prioridad más alta tienden a ser los más probados . El MODELO BASADO EN COMPONENTES (ORIENTADO A OBJETOS). Los clientes no tienen que esperar hasta tener el sistema completo. El RUP no es un sistema con pasos firmente establecidos.similares que por lo general éstas características establecen la vida del Software ya que se considera desde que se tiene la idea de crear una aplicación. este tiene grandes 11 . El MODELO ESPIRAL.

blogspot. Martin.blogspot.com/MODELO+DE+PROTOTIPOS Fuentes: Beck.html https://sisteminformacii. Teoría y Práctica.html http://www.mx/2012/10/caracteristicas-scrum. La programacion extrema en la practica.es/i2007-10/ http://frios334. Addison Wesley.uv. http://boyso. Shari Lawrence Peleeger. Fuentes Consultadas. Ingeniería de software.blogspot. REFERENCIAS BIBLIOGRÁFICAS. K. Sin duda RUP es una de las metodologías más completas y satisfactorias que se puede usar para el desarrollo de un Software. Extreme Programming Explained. 12 . Pressman Mc Graw Hill. J. ya que se enfoca en los requisitos y el diseño. & Newkirk.com/2008/04/29/ciclo-de-vida-de-los-sistemas-modelo-por-prototipos/ http://scruz334.ventajas con respectos a XP. Pearson Addison-Wesley.wikispaces.es/i2007-04/ Administración de Proyectos.mx/universo/486/infgral/infgral_15.wordpress. Un enfoque práctico Roger S.. A. R. 8 http://desarrollodefw. (2002). así como también el cliente interactúa con el equipo de desarrollo mediante reunionesa diferencia de la metodología XP que el cliente es parte del equipo. (2004).