You are on page 1of 7

Curso de Arquitecturas de Software

Conceptos

Modelos de Ciclo de Vida del software


Modelo en Cascada Modelo en Espiral

Programacin Orientada a Objetos Procesos de Desarrollo de Software

Rational Unified Process (RUP) Extreme Programming


Ciclo de Vida del software


Concepcin Infancia Adultez Retiro

Identificacin de Actividades de Desarrollo de SW


Anlisis de Requerimientos Cul es el problema? Diseo del Sistema Diseo de Programas Implementacin de Prog. Cul es la solucin? Dominio del Problema Cuales son los mecanismos que mejor solucionan el problema? Dominio de la Como se construye implementacin la solucin? Esta el problema resuelto? Es til lo entregado para el usuario? Se necesitan mejoras?

PreDesarrollo

Desarrollo

PostDesarrollo

Pruebas Entrega Mantenimiento

Modelo en Cascada
Iniciacin Exploracin de Conceptos Asignacin del Sistema Requerimientos Diseo Implementacin Verificacin & Validacin Instalacin Operacin & Soporte

Modelo en Cascada
Royce 1970

Las fases no inician hasta que las anteriores se han terminado completamente Se congelan partes del desarrollo como la especificacin, para continuar con las siguientes etapas Inflexibilidad : difcil de responder a los cambios del cliente

Modelo en Espiral de Boehm -Iteracin


Modelo en Espiral
Determine objectiv es, alternativ es, & constr aints
Risk analysis Risk analysis Risk analysis P1 Prototype2 Prototype1 Requirements plan Concept of operation Prototype3

Identifica riesgos y los prioriza Desarrollo de prototipos por clasificacin de riesgos Usa el modelo en cascada para cada ciclo Si un riesgo es resuelto, evaluar resultado del ciclo y planear el siguiente Si cierto riesgo no puede ser superado terminar el proyecto de inmediato

Evaluate alter nativ es, identify & resolv e r isks

Software Requirements

System Product Design P2 Unit Test

Development Requirements plan validation

Detailed Design

Code

Plan next phase

Integration plan

Design validation Acceptance Test

Develop & ver ify next level product

Integration & Test

Modelo Evolutivo

Madurez de un proceso

Se desarrolla una implementacin inicial que es expuesta a los comentarios del usuario y se refina a travs de versiones hasta llegar al sistema adecuado Tipos de desarrollo evolutivo :

CMM (Capability Maturity Model) del SEI y SPICE (software Process Improvement and Capability dEtermination) IEC 1504

Desarrollo exploratorio : Se trabaja con el cliente para entender los requerimientos y el producto evoluciona agregando nuevos atributos a partir de la constante evaluacin de dicho cliente. Prototipos desechables: Se construyen prototipos para los requerimientos que no se entienden del todo

Nivel Nivel Nivel Nivel Nivel

1 2 3 4 5

: : : : :

Inicial Repetible Definido (ISO 9001) Gestionado Optimizacin

Mtricas

Rational Unified Process


Iterativo e Incremental
Estimacin de Esfuerzo Manejo de Riesgos

Iterativo e incremental Manejo de los requerimientos de manera evolutiva Arquitectura basada en componentes Modelado visual : A model is a simplification of reality that completely describes a system from a particular perspective (Grady Booch) Continuamente hay verificacin de la calidad del software : Estudios han probado que mientras ms temprano se identifique un problema menos costosa es su solucin.

Evaluacin del resultado de pruebas con el cliente

Modelo de proceso - RUP


Disciplinas

Conceptos

Cada fase esta compuesta de ITERACIONES Iteracin: Ciclo completo de desarrollo que produce una versin (interna o externa) de un producto ejecutable (subconjunto de el producto final en desarrollo) Artefacto: elementos usados como entrada o salida para las actividades de el proceso (entregables)

1. Inicio

2. Elaboracin

Empezar a conocer el problema Identificar los beneficios e impacto del sistema a construir Identificar interfaces con otros sistemas Elaborar diseo global y arquitectura Estimar esfuerzo, tiempo (costo) y riesgos Definir el alcance del sistema Preparar entorno de desarrollo

Detallar los requerimientos Identificar y documentar todos los casos de uso Desarrollar el modelo de clases del mundo del problema Desarrollar plan para el manejo de los riesgos del proyecto (Negocio, Tecnolgicos, Recursos Humanos, funcionales) Definir plan de implementacin (iteraciones e incrementos)

Manejo del riesgo


Gestin del Riesgo


Mitigar el riesgo Hacer seguimiento al riesgo Manejar el riesgo (tener un plan B)

Incertidumbre : La probabilidad de que el riesgo se materialice Prdida : las consecuencias de que el riesgo se haya materializado Clasificacin general

riesgos genricos. riesgos especficos del proyecto

3. Construccin

4. Transicin
Pruebas de todo el sistema Configuracin y afinamiento de la plataforma de produccin Desarrollo de manuales de usuario final Desarrollo de manual de instalacin Capacitacin de usuarios finales

Escoger un conjunto de casos de uso Refinar Casos de uso (requerimientos funcionales) Refinar Modelo de clases para los casos de uso Programar los casos de uso elegidos Pruebas unitarias Ajustes Pruebas de Integracin de todo el software
IR AVANZANDO DE MANERA ITERATIVA E INCREMENTAL

Pruebas

Qu es eXtreme Programming ?
XP es una metodologa liviana Deliberada y disciplinada Para equipos de trabajo no demasiado grandes

Unitarias, de integracin y del sistema Para las unitarias de caja blanca hay herramientas que automatizan las pruebas como JUnit Para las unitarias de caja negra se utilizan los casos de prueba Para las de integracin tambin se usan los casos de prueba

Origen de XP

Problemas de las metodologias tradicionales...


A principios de 1990 Kent Beck propone cambios a las metodologias tradicionales. En 1996 se realiza una prueba exitosa, a este proyecto se le llamo DaimlerChrysler y dio origen a XP.

Concepto del costo del cambio en el tiempo mal interpretado

...problemas
Inversin alta en los inicios del proyecto (Peligroso) Perdida de tiempo tratando de implementar funcionalidad que ser til en el futuro. Metodologas orientadas a documentos no a satisfaccin del cliente

...problemas
Diseo complejo e Innecesario Desarrolladores con poca libertad Trabajo solitario Inconformidad con el cargo. Un proceso estandarizado no significa que sea optimo

Valores de XP
COMUNICACIN SIMPLICIDAD FEEDBACK CORAJE

COMUNICACION
Facilidad de comunicacin entre los desarrolladores. Una de las personas del equipo tiene la tarea de facilitar esta comunicacin cuando no se esta dando Coach.

SIMPLICIDAD
Realizar las tareas de la forma mas simple que pueda funcionar Evitar el miedo a la curva del costo del cambio en el tiempo. Hacer una tarea simple HOY y no una complicada que no ser usada.

FEEDBACK
Obtener retroalimentacin de manera constante, (Unit Tests) Cualquier integrante del equipo puede revisar cualquier parte del cdigo en cualquier momento. Retroalimentacin del cliente.

CORAJE
No continuar si las pruebas unitarias no funcionan. No dudar en desechar cdigo que se sospecha no va a funcionar. Simplificar al mximo

Propuestas de XP
Contratar programadores talentosos es indispensable para el proceso. Iteraciones: 1 - 4 Semanas - Tareas de 1 a 3 das mximo. Pruebas de integracin varias veces al da. Realizar cambios de manera incremental. Carga liviana

eXtreme Programming

Practicas de XP
Juego de planeacion: Determinar el alcance del siguiente release. Lanzamientos pequeos: Sistema simple en produccin lo mas rpido posible Metfora: guiar al equipo con una historia sencilla que describe el sistema

El Juego de la Planeacin (The Planning Game) Pequeas versiones (Small Releases). Diseo Simple (Simple Design). Pruebas (Testing). Refactoring. Programacin en Parejas (Pair Programming). Propiedad Colectiva del cdigo (Collective ownership). Continua Integracin (Continuos integration). Del lado Cliente (On side Customer). Estndares de Codificacin (Coding Standards).

Practicas de XP
Diseo simple Pruebas Refactoring: Reestructurar el sistema sin cambiar su comportamiento. Programacin en parejas: Todo el cdigo de produccin es escrito por dos programadores

Practicas de XP
Propiedad colectiva: Cualquiera puede cambiar el cdigo en cualquier momento. Integracin Continua: Cada vez que se completa una tarea. 40 horas por semana: Mximo numero de horas a trabajar.

Practicas de XP
Cliente en el sitio: Cliente real de la aplicacin en el lugar del desarrollo. Estndares de programacin: Determinar reglas al principio del proyecto

Programacin en parejas

Diferentes formas de solucionar problemas algortmicos, facilitan la escogencia de la solucin ms eficaz al programar. Calidad del software. Aprovechamiento del aprendizaje en parejas en el manejo de las herramientas informticas y de los temas del problema

Del lado cliente


Referencias

La delimitacin del proyecto tiene que estar dada primordialmente por el aspecto financiero. Se debe especificar un esquema de contratacin por hora/ingeniero. El perfil del usuario ideal para XP seria alguien que maneje o conozca algn sistema de informacin. La interaccin con el usuario es constante, el cliente debe contar con un mnimo de tiempo disponible semanal para la supervisin y aprobacin de las pequeas versiones.

Booch G. et.al, El Lenguaje Unificado de Modelado, Ed. Addison Wesley Iberoamericana, Madrid 1999 eXtreme Programming www.extremeprogramming.org Larman C., UML y Patrones, Prentice Hall, Segunda Edicin, 2003 Bruegge B., Ingenieria de Software Orientada a Objetos, Ed. Prentice Hall, Mexico 2002

You might also like