TIPOS DE MODELOS
- Modelo clásico o en cascada.
- Modelo incremental.
- Modelo de desarrollo evolutivo.
- Modelo de prototipado de requerimientos.
- Modelo de espiral.
- Modelo de construcción de prototipos.
- Modelo de síntesis automática de software.
- Modelo de sistemas suaves (soft)
MODELO CASCADA
El modelo en cascada (o waterfall model en inglés) fue el primer método ampliamente utilizado en la industria del software. Como enfoque tradicional, no es repetitivo en contraste con los modelos ágiles con sprints simples, pero puede ser complementado con bucles de retroalimentación y loopbacks. Todavía se utiliza hoy en día en varias versiones si los requisitos y características de un software pueden ser claramente definidos durante la fase conceptual.
Funcionamiento
El modelo original en cascada consta de siete fases sucesivas:
- Requisitos del sistema: La primera fase se ocupa de los requisitos que no están relacionados con el producto digital en sí, sino más bien con aspectos relevantes para la empresa como el precio y la disponibilidad. Aquí también se especifican los aspectos de documentación y seguridad. En general, aquí se mencionan los requisitos no funcionales.
- Requisitos de software: Los requisitos funcionales del software se definen en la segunda fase. La pregunta sobre lo que el software debe ser capaz de hacer se responde aquí y se aclara en "especificaciones", que también incluye los resultados de la primera fase.
- Análisis de requerimientos: En la fase de análisis de requisitos, las funciones del software se diseccionan y estructuran de modo que los elementos funcionales individuales y las unidades funcionales puedan separarse entre sí. El análisis de necesidades tiene por objeto examinar la viabilidad e importancia de las funciones. Los resultados de esta fase son las especificaciones que contienen los requisitos que hay que desarrollar.
- Diseño de programas: El diseño técnico se implementa ahora con la ayuda de estas especificaciones de requisitos. Los componentes de esta fase también incluyen decisiones sobre la arquitectura de la información y las tecnologías aplicadas, tales como lenguajes de programación, bibliotecas de clases y secuencias de programas. El resultado del diseño del programa se registra generalmente en diagramas que describen el comportamiento teórico del software.
- Implementación: Durante la implementación, las estructuras y los flujos de trabajo se implementan teniendo en cuenta las condiciones marco y los objetivos sistémicos. El diseño de software se convierte en un programa directamente relacionado con un sistema operativo, uno o más lenguajes de programación y la infraestructura. El resultado suele ser un software operativo, a menudo en versión beta.
- Probando: La fase de implementación es seguida por la prueba de todos los componentes de software, módulos y todo el sistema. También se comprueba la integración en sistemas operativos específicos. Si se producen errores y conflictos, deben repararse inmediatamente. Esto podría dar lugar a un aumento de los costes globales, ya que los posibles errores pueden atribuirse a diferentes fases y no siempre se producen en la fase anterior.
- Lanzamiento: El software se implementa después de la aceptación por parte del cliente. Las actualizaciones y el mantenimiento pueden ser necesarios antes de que el producto entre en una tienda o se entregue al cliente.
Ventajas
- Debido a la estructura lógica del modelo, a menudo se pueden evitar errores conceptuales.
- El modelo conduce a una extensa documentación técnica, que es un alivio para los nuevos programadores y desarrolladores y también es útil en la fase de prueba.
- El progreso del proyecto puede ser monitoreado usando metas.
- El coste total puede estimarse con relativa precisión si no hay conflictos.
- La definición de productos es estable cuando se entiende bien las tecnologías.
- Es la cualidad de tener un buen enfoque de los costos y tiempos.
- Tener un buen personal técnico
- Tener un buen equipo
- Trabaje de forma eficiente.
Desventajas
- Los conflictos, bugs y errores de programación a veces conducen a un aumento de los costes y a una cantidad considerable de tiempo. Lo mismo se aplica si los clientes no están satisfechos.
- Las especificaciones que se hacen inicialmente son a menudo difíciles de entender para los clientes porque son más abstractas de lo que se supone que el software debe hacer. Especialmente en proyectos subcontratados, esto puede ser una desventaja decisiva, ya que la fecha de lanzamiento debe posponerse y el mercado puede haber cambiado durante este tiempo.
- La entrega del software lleva más tiempo porque los departamentos no trabajan simultáneamente y cada fase sólo puede comenzar cuando se ha completado la fase anterior.
- No es flexible entre su inicio y terminación.
- Dificultad de definir todos los requerimientos de una sola.
- Puede producir excesiva documentación.
- Pobre visibilidad de signos de progreso hasta el final.
Modelo de Síntesis automática de software
- Se define el sistema utilizando un lenguaje formal.
- La implementación es automática, asistida por el Ordenador.
- La documentación se genera de forma automática.
- El mantenimiento se realiza “por sustitución” no mediante “parches”.
- Dificultad en la participación del usuario.
- Diseños poco optimizados.
Modelo de construcción de Prototipos
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.
- 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
- Se puede reutilizar el código.
- Es interesante usarlo cuando:
- Cambios rápidos de requerimientos
- No hay compromiso del cliente
- Cuando el dominio del problema no es óptimo.
- La construcción de prototipos se puede utilizar como un modelo del proceso independiente
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 aras 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.
- Dificultad en la estimación de tiempos
- Si solo se usa este modelo, puede pasar errores graves.
Modelo DRA (Desarrollo de aplicaciones rápidas)
Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite crear un sistema completamente funcional en un periodo muy corto.
Es utilizado para periodos de desarrollo corto (60 a 90 días), generalmente para aplicaciones puntuales de sistemas de información.
Los pasos a seguir son:
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?.
- 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 Procesos: 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).
- 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.
- Los entregables pueden ser fácilmente trasladados a otra plataforma.
- El desarrollo se realiza a un nivel de abstracción mayor.
- Entrega temprana al cliente.
- Compromiso del cliente con el sistema.
- 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.
- Se recomienda su uso para pequeños proyectos.
- Generalmente el usuario es el cliente.
- Se necesita de personal conocedor de la herramienta.
Desventajas
- Tiene inconvenientes para proyectos grandes, necesita suficientes recursos humanos para crear el número correcto de equipos.
- Si los desarrolladores y clientes no se comprenden con las actividades necesarias para completar el sistema, los proyectos fallarán.
- Un alto costo de herramientas integradas y equipo necesario.
- Progreso más difícil de medir.
- Menos eficiente y con menor precisión científica.
- Es un modelo de inicio y fin, sin retroalimentación.
- No ofrece el uso de “mejores prácticas”
- No funciona para proyectos grandes
Modelos evolutivos de construcción de software - Modelo Incremental
Sugirió el enfoque incremental de desarrollo como 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 adquirir experiencia con el sistema
Combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos.
El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un «incremento» del software [MDE93].
El modelo de gestión incremental no es un modelo necesariamente rígido, es decir, que puede adaptarse a las características de cualquier tipo de proyecto, existen al menos 7 fases que debemos tener en cuenta a la hora de implementarlo:
- Requerimientos: son los objetivos centrales y específicos que persigue el proyecto.
- Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el siguiente paso es hacer una lista de tareas y agruparlas en las iteraciones que tendrá el proyecto. Esta agrupación no puede ser aleatoria. Cada una debe perseguir objetivos específicos que la definan como tal.
- Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será la evolución del producto en cada una de ellas. Cada iteración debe superar a la que le ha precedido. Esto es lo que se denomina incremento.
- Desarrollo del incremento: posteriormente se realizan las tareas previstas y se desarrollan los incrementos establecidos en la etapa anterior.
- Validación de incrementos: al término de cada iteración, los responsables de la gestión del proyecto deben dar por buenos los incrementos que cada una de ellas ha arrojado. Si no son los esperados o si ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de ello.
- Integración de incrementos: una vez son validados, los incrementos dan forma a lo que se denomina línea incremental o evolución del proyecto en su conjunto. Cada incremento ha contribuido al resultado final.
- Entrega del producto: cuando el producto en su conjunto ha sido validado y se confirma su correspondencia con los objetivos iniciales, se procede a su entrega final.
El modelo incremental entrega el software en partes pequeños, pero utilizables, llamadas (incrementos). En general, cada incremento se construye sobre aquél que ya ha sido entregado
Características
- 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 costo 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 positivo.
- 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.
- Construir un sistema pequeño es menos riesgoso que construir un sistema grande.
- Ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
- Reduciendo el tiempo de desarrollo de un sistema por incrementos, decrecen las probabilidades que esos requerimientos de usuario puedan cambiar durante el desarrollo.
- Si un error importante es detectado, sólo la última iteración necesita ser descartada.
- Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.
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.
- Serios problemas de integridad, tanto a nivel de código como a nivel de datos, peor cuando parte del proceso es reemplazar a sistemas funcionando.
Modelo Espiral
El modelo espiral en el desarrollo del software es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro; además en cada ejecución del desarrollo se sigue cuatro pasos principales:
1- Determinar o fijar los objetivos.
En este paso se definen los objetivos específicos para posteriormente identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación detallada de gestión y se identifican los riesgos.
2- Análisis del riesgo.
En este paso se efectúa un análisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de estos riesgos se planean estrategias alternativas.
3- Desarrollar, verificar y validar.
En este tercer paso, después del análisis de riesgo, se eligen un paradigma para el desarrollo del sistema de software y se lo desarrolla.
4- Planificar.
En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto.
Con cada iteración alrededor de la espiral, se crean sucesivas versiones del software, cada vez más completas y, al final, el sistema de software ya queda totalmente funcional.
La diferencia principal entre el modelo espiral y los modelos anteriores (ej.: cascada, evolutivo, incremental, etc.) es la evaluación del riesgo.
Características
- Es considerado como un modelo evolutivo ya que combina el modelo clásico con el diseño de prototipos. Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente.
- Este modelo es el indicado para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de PC´s.
- La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.
- Este es el enfoque más realista actualmente
El modelo en espiral esta compartida en varias actividades estructurales, también llamadas regiones de tareas. Existen seis regiones de tareas que son:
• Comunicación con el Cliente: Esta es una tarea requerida para establecer comunicación entre el desarrollador y el cliente.
• Planificación: Esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos.
•Análisis de Riesgos: Esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto.
• Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la aplicación.
• Construcción y Adaptación: Esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario.
• Evaluación del Cliente: Esta también es una tarea principal, necesaria para adquirir la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de implementación creada durante la etapa de instalación.
Ventajas
- No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.
- En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.
- Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.
- Decidir qué problema se quiere resolver antes de ir a resolverlo.
- Examinar las múltiples alternativas de acción y elegir la más conveniente.
- Examinar lo que tienes hecho y lo que te falta por hacer
- Conocer los riesgos del proyecto en cada vuelta
- Incremento en el costo y decremento en el riesgo
- Existe complicación cuando se evalúa los riesgos.
- Se requiere la participación continua por parte del cliente.
- Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando se modifica o mejora el software.
- Más complejo
- Requiere más administración
Modelos evolutivos de construcción de software - Modelo Espiral ganar-ganar
El modelo Win-Win deriva su nombre del objetivo de estas negociaciones, es decir, "ganar-ganar". El cliente recibe el producto que satisface la mayoría de sus necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de entrega. Para lograr este objetivo, se realizan varias actividades de negociación al principio de cada paso alrededor de la espiral.
Ventajas
- El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.
- Reduce riesgos del proyecto
- Incorpora objetivos de calidad
- Integra el desarrollo con el mantenimiento, etc.
- Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.
Desventajas
- Genera mucho tiempo en el desarrollo del sistema
- Modelo costoso
- Requiere experiencia en la identificación de riesgos
Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia.
Modelo en V
Es una representación gráfica del ciclo de vida del desarrollo de sistemas. En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el marco del sistema informático de validación.
Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Se describen las actividades y resultados que deben producirse durante el desarrollo del producto. El lado izquierdo de la V representa la descomposición de las necesidades, y la creación de las especificaciones del sistema. El lado derecho de la V representa la integración de las piezas y su verificación. V significa «Verificación y validación». Es muy similar al modelo de la cascada clásico ya que es muy rígido y contiene una gran cantidad de iteraciones.
Objetivos
El Método-V fue desarrollado para regular el proceso de desarrollo de software por la Administración Federal Alemana. Describe las actividades y los resultados que se producen durante el desarrollo del software.
Proporciona una guía para la planificación y realización de proyectos. Los siguientes objetivos están destinados a ser alcanzados durante la ejecución del proyecto:
- Minimización de los riesgos del proyecto: Mejora la transparencia del proyecto y control del proyecto, especificando los enfoques estandarizados, describe los resultados correspondientes y funciones de responsabilidad. Permite una detección temprana de las desviaciones y los riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.
- Mejora y Garantía de Calidad: Como un modelo de proceso estándar, asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada. Los resultados provisionales definidos se pueden comprobar en una fase temprana. La uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.
- Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida: El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y controlado de manera transparente mediante la aplicación de un modelo de procesos estandarizados. Reduciendo la dependencia en los proveedores y el esfuerzo para las siguientes actividades y proyectos.
- Mejora de la comunicación entre todos los inversionistas: La descripción estandarizada y uniforme de todos los elementos pertinentes y términos es la base para la comprensión mutua entre todos los inversionistas. De este modo, se reduce la pérdida por fricción entre el usuario, comprador, proveedor y desarrollador.
• El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.
• El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema.
• El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa.
Ventajas
• Diseñado para pruebas.
• Enfatiza verificación y validación en todas las fases.
• Es una buena opción para sistemas que necesitan alta confiabilidad, como los sistemas de control.
Desventajas
• No maneja interacciones
• Los cambios pueden ser manejados con mucha dificultad
COTS “Commercial-off-the-shelf systems”)
Es un término del Reglamento Federal de Adquisiciones (FAR), que define un elemento no-desarrollativo (NDI) de suministro, que es a la vez comercial y se vende en grandes cantidades en el mercado comercial, y que puede ser adquirido o utilizado bajo contrato gubernamental de la misma forma exacta a como está disponible al público en general. Por ejemplo, para los elementos relacionados con la tecnología, tales como programas informáticos, sistemas de hardware o de software libre con apoyo comercial y materiales de construcción están calificados así, pero carga a los productos a granel, tales como los productos agrícolas y el petróleo.
Las compras COTS son alternativas a desarrollos caseros. COTS típicamente requiere una configuración que se adapta para usos específicos. El uso de COTS ha recibido el mandato a través de muchos programas de gobierno y de negocios, ya que estos productos pueden ofrecer un ahorro significativo en la contratación, el desarrollo y mantenimiento.
Ventajas
• Se pueden compran componentes de software.
• Cada vez hay más estandarización.
• Disponibilidad inmediatamente
• Potencialmente de bajo costo
Desventajas
• No está hecho a la medida de los requerimientos
XP: EXTREME PROGRAMMING
Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.
Valores
Los valores originales de la programación extrema son:
- Simplicidad : La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hace que la complejidad aumente exponencialmente.
- Comunicación: La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método.
- Retroalimentación (feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante.
- Coraje o valentía: Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementarán más fácilmente. Otro ejemplo de valentía es saber cuándo desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente.
- Respeto: El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código.
• No es un producto de Microsoft.
• Es parte de un movimiento llamado “Agile Development”.
• Es una metodología ligera.
• Es una corriente en boga.
• Utiliza un modelo incrementar/Interactivo.
• Trabaja con el cliente en sitio.
• Control de cambios, es incremental.
• Se programa entre dos personas.
• Los requerimientos se construyen a través de experiencias.
• Una buena técnica para un buen desarrollador.
Desventajas
• No funciona como industria.
• No funciona cuando se trabaja con equipos de trabajo grandes.
Otras “Agile” Metodologías
• Features 30-day “Sprint” cycles
Feature Driven Development (FDD)
• XP with more emphasis on docs and process
Adaptive Software Development (ASD)
• Book, site
Dynamic System Development Method (DSDM)
• Popular in Europe
Ventajas
• Similar al XP, puede reducir procesos
• Sensible a la retroalimentación con el usuario
• Receptivo a los cambios
Desventajas
• Se requiere cerrar en algún momento los requerimientos.
• Puede que no haya fin en proyectos largos
• Frecuentemente requiere calidad de los desarrolladores.
• Y de una contratación continua.
RUP - Rational Unified Process
RUP es una implementación específica del Proceso Unificado .
Estructura del proceso
El proceso puede ser descrito en dos dimensiones o ejes:
• Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases, iteraciones e hitos que RUP consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Como se mencionó anteriormente cada fase se subdivide a la vez en iteraciones.
• Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles.
Ventajas
• Desarrollo iterativo.
• Utilizan la metodología UML (Unified Modeling Language).
• Produce artefactos (Componentes).
• Modelo de software visual.
• Proceso complejo.
• Conveniente para sistemas grandes.
Desventajas
• No tener personal preparado en la metodología.
• Deber ir en consistencia con la gestión del proyecto.
Elegir el ciclo de vida
• Dependerá del proyecto?
• Cómo son los requerimientos?
• Cuales son los riesgos?
• Son fijos los tiempos?
• Cuál es la experiencia del equipo y del cliente?
No hay comentarios:
Publicar un comentario