You are on page 1of 134

Proyecto Integrador

Unidad 1:
Introducción

1.1 ¿Que es el análisis y diseño
OO?
El marco de desarrollo de una aplicación
software estaría formado por las tres fases
tradicionales:
análisis,
diseño
e
implementación.
El análisis es la fase cuyo objetivo es
estudiar y comprender el dominio del
problema, es decir, el análisis se centra en
responder al interrogante ¿QUÉ HACER?
El diseño, por su parte, dirige sus esfuerzos
en desarrollar la solución a los requisitos

1.1 ¿Que es el análisis y diseño
OO?
La fase de implementación sería la
encargada de la traducción del diseño de la
aplicación al lenguaje de programación
elegido, adaptando por tanto la solución a
un entorno concreto.

.1.1 ¿Que es el análisis y diseño OO? La transición entre las fases de análisis y diseño en la orientación al objeto es muy suave lo que puede provocar confusión entre las etapas. siendo la frontera entre ambas fases totalmente inconsistente. Esto implica que sea difícil determinar donde acaba el Análisis Orientado a Objeto (AOO) y donde comienza el Diseño Orientado a Objeto (DOO). de forma que lo que algunos autores incluyen en el AOO otros lo hacen en el DOO.

para mejorar su reutilización y tomar ventaja de la herencia.1 ¿Que es el análisis y diseño OO? El objetivo del AOO es modelar la semántica del problema en términos de objetos distintos pero relacionados. el DOO conlleva reexaminar las clases del dominio del problema. extendiéndolas y reorganizándolas. El análisis casa con el dominio del problema y el diseño con el dominio de la solución. Por su parte.1. por lo tanto el AOO enfoca el problema en los . refinándolas.

es decir. en la identificación de las abstracciones que representen el significado de las especificaciones y de los requisitos del sistema. recibiendo el nombre de objetos semánticos porque ellos representan las abstracciones que encierran el significado del dominio del problema.1. El análisis se centra en la representación del problema.1 ¿Que es el análisis y diseño OO? Los objetos del dominio del problema representan cosas o conceptos utilizados para describir el problema. .

1 ¿Que es el análisis y diseño OO? El énfasis del diseño se centra en la definición de la solución. Los objetos del dominio de la solución incluyen: objetos de interfaz. Los objetos semánticos serán refinados durante la fase de análisis y de diseño. Éstos no forman parte directamente de los objetos del dominio problema. objetos de aplicación y objetos base o de utilidad.1. siendo completados con los objetos propios del dominio de la solución. pero representan la .

lo que incluye a las clases . AOO: Es el proceso que modela el dominio del problema identificando y especificando un conjunto de objetos semánticos que interaccionan y se comportan de acuerdo a los requisitos del sistema.1 ¿Que es el análisis y diseño OO? Una vez realizada esta introducción al AOO y al DOO se puede proceder a dar una definición más concreta de ambos procesos.1. DOO: Es el proceso que modela el dominio de la solución.

agregaciones y asociaciones).1. El emplazamiento de las clases. atributos y servicios. .1 ¿Que es el análisis y diseño OO? En el AOO deben llevarse a cabo las siguientes actividades: La identificación de clases semánticas. La especificación del comportamiento dinámico mediante paso de mensajes. atributos y servicios Identificación de las relaciones entre clases (generalizaciones.

siendo recomendable llevarlas a cabo concurrentemente. Como resumen final.1 ¿Que es el análisis y diseño OO? En el DOO deben llevarse a cabo las siguientes actividades: Añadir las clases interfaz. base y utilidad. Refinar las clases semánticas. así el modelo de análisis no puede completarse en ausencia de un modelo de diseño. ni .1. se podría afirmar que el AOO y el DOO no deben verse como fases muy separadas.

1 El espacio del problema (análisis).1.2. 1992] . “El análisis orientado a objetos es el proceso que modela el dominio del problema identificando y especificando un conjunto de objetos semánticos que interaccionan y se comportan de acuerdo a los requisitos del sistema”. [Monarchi y Puhr.

¿Cuáles procesos de la institución se relacionan con su uso? Durante el análisis orientado a objetos se procura ante todo identificar y describir los objetos – o conceptos – dentro del dominio del problema. Identificar los requisitos: documentos de análisis. El análisis se centra en la investigación del problema.2. si se necesita un nuevo sistema de biblioteca. .1 El espacio del problema (análisis). Por ejemplo. no en la manera de definir la solución.1.

Analizar: Modelos de análisis. Documento técnico. etc. .1 El espacio del problema (análisis).2. orientados al flujo. Estudio de posibles escenarios: casos de uso. Especificar los requisitos: documento de especificación de requisitos.1. Validar. La especificación de requisitos describe el sistema en lenguaje natural. Organización y clasificación de los requisitos. Otras técnicas: fichas CRC.

1.1 El espacio del problema (análisis). .2.

.1.1 El espacio del problema (análisis).2.

Modelo de Objetos: diagramas de clases y objetos.1.2.1 El espacio del problema (análisis). Modelo de escenarios. análisis basado en Modelo funcional: casos de uso y escenarios. .

Casos de uso.1. Describen qué hace el sistema desde el punto de vista de un observador externo.2. Caso de uso: conjunto de escenarios (secuencias de interacción de los actores y . Actores: ¿quién interactúa con el sistema?. Un escenario es un ejemplo de lo que ocurre cuando uno o varios actores interactúan con el sistema. También pueden ser otros sistemas.1 El espacio del problema (análisis).

Identificar los actores principales.2. Pasos a seguir.1. identificar sus objetivos. Para cada uno. . Identificar los límites (alcance) del sistema.1 El espacio del problema (análisis). Definir casos de uso que satisfagan sus objetivos. Casos de uso.

2.1.1 El espacio del problema (análisis). .

1 El espacio del problema (análisis).1.2. .

2. .1 El espacio del problema (análisis).1.

Modelos de Análisis Basados en Clases. Clases que pertenecen al espacio de la solución vs. o casos de uso.): información que necesita el sistema.  Sucesos o eventos que ocurren durante la operación del sistema.  Papeles que desempeñan los usuarios. señales. etc. Analizar los documentos de análisis.2.  .  Cosas (informes.1. Aislar los sustantivos:  Entidades externas: producen o consumen información que usa el sistema. espacio del problema.1 El espacio del problema (análisis).

1. Diagrama de Clases Conceptuales.1 El espacio del problema (análisis).2. .

a. Tipos de clases: De entidad (a. De control. Realizan una “unidad de trabajo”: crean o actualizan objetos de .1. Representan información relevante para la aplicación. de modelo o de negocio). Clasificación de clases.a.2. De frontera (a.1 El espacio del problema (análisis). de contorno). Son clases que persisten durante la aplicación.k. Clases que crean la interfaz que el usuario ve y con la que interacciona.k.

1 El espacio del problema (análisis).1.2. . Caso de uso Procesar Venta. Diagrama de clases de análisis.

Una ficha por cada clase relevante. . Método de Clase-ResponsabilidadColaborador (CRC) Facilitan la colaboración entre desarrolladores. División de responsabilidades. Se identifican sus responsabilidades. relaciones de colaboración.2.1 El espacio del problema (análisis). Jerarquías de generalización/especialización.1.

Método de Clase-ResponsabilidadColaborador (CRC) .2.1.1 El espacio del problema (análisis).

dependencias entre ellos. etc. esto es del cómo.1.2. El modelo de análisis describe el sistema desde el punto de vista de los actores. Diseño del sistema: Objetivos de diseño que se deben optimizar (derivados de los requisitos no funcionales). Del Análisis al Diseño. . No contiene información de la estructura interna del sistema.1 El espacio del problema (análisis). Una arquitectura software: descomposición en subsistemas.

1. Diseño de las clases de la solución.1 El espacio del problema (análisis).2. interfaces. Diseño detallado (de objetos). . Del Análisis al Diseño. Refinamiento del diseño del sistema.

1. en lugar de aislar el procesamiento.2 El espacio de la solución (diseño). el DOO produce un diseño que interconecta objetos de datos y operaciones de procesamiento para esos objetos. que es el software. El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución. A diferencia con otros métodos de diseño. .2. de forma que se modulariza la información y el procesamiento.

Todos los métodos de diseño desarrollar software basándose en: intentan Abstracción. El AOO.2 El espacio de la solución (diseño).1.2. El DOO proporciona un mecanismo que permite al diseñador consigue estas tres características sin dificultad. Modularidad. el DOO y la POO comprenden un conjunto de actividades de la IS para la . Ocultamiento de información.

Para conseguir un DOO. El funcionamiento del software se consigue al actuar uno o más procesos sobre una estructura de datos de acuerdo con un procedimiento de invocación.1.2. Objetos. tenemos que establecer un mecanismo para: Representar la estructura de datos Especificar el proceso Realizar el procedimiento de invocación .2 El espacio de la solución (diseño). operaciones y mensajes.

2 El espacio de la solución (diseño). un objeto es un producto o consumidor de información. Cuando se hace corresponder un objeto con su realización software. En un Sistema de Información basado en Computador.1. implementamos una estructura de datos y usa serie de procesos . operaciones y mensajes. o un elemento de información. Objetos. Objeto: Componente del mundo real que se hace corresponder con el software.2.

Operaciones. . operaciones y mensajes. métodos o servicios: Procesos a los que se le permite transformar estructuras de datos. que se invocan mediante un mensaje. Objetos. Las operaciones contienen construcciones procedimentales y de control. Mensajes: Peticiones que se realizan a los objetos para que realicen alguna de sus operaciones.2 El espacio de la solución (diseño).1.2.

Objetos.2.2 El espacio de la solución (diseño). Mensajes. . operaciones y mensajes.1.

2. Al definir un objeto con parte privada y proporcionar mensajes para invocar al procedimiento adecuado conseguimos el ocultamiento de información.1. Los objetos con sus operaciones proporcionan una modularidad inherente. es decir los elementos del software (datos y procesos) . operaciones y mensajes. De esta forma dejamos ocultos al resto de los elementos de programa los detalles de implementación del objeto. Objetos.2 El espacio de la solución (diseño).

 Compresibilidad: Facilidad para comprender un componente del programa sin tener que hacer referencia a otros módulos. Meyer sugiere cinco criterios para evaluar la calidad de un método de diseño a partir de la modularidad.2 El espacio de la solución (diseño).2.  Continuidad: Capacidad de realizar cambios en un .  Componibilidad: Grado en el que un método de diseño permite la reutilizabilidad de módulos.1.  Descomponibilidad: Facilidad con la que un método de diseño ayuda al diseñador a descomponer un problema en sub-problemas más sencillos. Aspectos de diseño.

A partir de estos criterios. Meyer sugiere la derivación de cinco principios de diseño para arquitecturas modulares: Unidades modulares Pocas interfaces Interfaces pequeñas (acoplamiento débil) Interfaces explícitas Ocultamiento de información. Aspectos de diseño. .1.2 El espacio de la solución (diseño).2.

Para conseguir un acoplamiento débil. y no mediante una zona global de datos.1. se debe minimizar el número de interfaces entre módulos y minimizar la cantidad de información que se mueve a través de una interfaz.2. Siempre que los módulos tengan que comunicarse tiene que hacerlo de forma clara. ya que la .2 El espacio de la solución (diseño). mediante interfaces explícitas. Aspectos de diseño.

Clases.2. todos pertenecen a una clase superior.2 El espacio de la solución (diseño). instancias y herencia. vemos que existen motos. automóviles y camiones. Por ejemplo. .1. Muchos objetos del mundo real tienen características prácticamente iguales y realizan operaciones prácticamente similares. si observamos un conjunto de vehículos. llamada vehículo. Aunque todos estos objetos son diferentes.

Todos los objetos de la clase vehículo tienen atributos comunes (marca. . . Todos los objetos son miembros de una clase mayor y heredan la estructura de datos privada y las operaciones que se hayan .2 El espacio de la solución (diseño). Clases..). Las implementaciones en software de objetos del mundo real se hacen de forma muy similar. instancias y herencia.. modelo. frenar..1.) y realizan una serie operaciones comunes (acelerar.2..

1.2.2 El espacio de la solución
(diseño).
Clases, instancias y herencia.
Es decir una clase es un conjunto de objetos
que tienen las mismas características. Así, un
objeto es una instancia de una clase mayor.
Pero, ¿qué ocurre cuando una instancia de
una clase mayor contiene una serie de
atributos y/o operaciones que son propias de
la instancia?
La solución a este problema es la creación de
subclases, que heredaría los atributos y las
operaciones de la clase superior, y permite

1.2.2 El espacio de la solución
(diseño).
Clases, instancias y herencia.

1.2.2 El espacio de la solución
(diseño).
Clases, instancias y herencia.
El uso de clases, subclases y herencia tiene
mucha importancia
en la Ingeniería del
Software moderna.
La reutilización de componentes del software
(que
nos
permite
conseguir
la
componibilidad) se lleva a cabo creando
objetos (instancias) que se forman sobre los
atributos y las operaciones de una clase o
una subclase. Sólo hay que especificar cuáles

2. La descripción del diseño de un objeto (una instancia de una clase o de una subclase) está compuesta de dos partes: Descripción de la interfaz: Establece la interfaz del objeto. Descripciones de los objetos. definiendo los mensajes que puede recibir el objeto y las operaciones que puede realizar cuando el objeto recibe el mensaje.1.2 El espacio de la solución (diseño). Descripción de la implementación: Muestra los detalles de cada una de las operaciones .

2. La descripción de la interfaz son un conjunto de mensajes con sus comentarios correspondientes.2 El espacio de la solución (diseño). Descripciones de los objetos. Los detalles de implementación incluyen información sobre la parte privada del objeto.1. La descripción de la implementación debe contener la información suficiente para . los detalles de las estructuras de datos y los detalles procedimentales que describen las operaciones. es decir.

el paradigma orientado a objetos persigue el encapsulamiento.2 El espacio de la solución (diseño).1. es decir. A la diferencia entre la forma de especificar qué es lo que se desea y cómo se proporciona ese servicio es lo que se conoce como encapsulamiento. mostrar sólo las operaciones visibles. Descripciones de los objetos. Por tanto. creando una sensación de cajas negras a las . y ocultar los detalles de implementación.2.

se tiene que indicar las relaciones que existen entre ellos mediante una notación. Métodos de diseño Orientado a Objetos. y el Diseño Orientado a Objetos. .2 El espacio de la solución (diseño).1. Debemos comprender la diferencia entre el Análisis Orientado a Objetos.2. que es una actividad de clasificación. que define los objetos que se derivan de cada clase.

programación y pruebas.3. El desarrollo iterativo es un enfoque para construir software (o cualquier cosa) en el cual el ciclo de vida se compone por varias iteraciones en secuencia.1 Desarrollo Iterativo.1. El objetivo final de una iteración es obtener un release de iteración: un sistema . diseño. Cada iteración es un mini-proyecto autocontenido compuesto por actividades como análisis de requisitos.

1 Desarrollo Iterativo.3. . Es decir: Todo el software a través de todos los equipos de desarrollo se integra en un release en cada iteración. Los release pueden ser internos (para el equipo de desarrollo) o externos (para el cliente).1.

Muchos proyectos tienen al menos tres iteraciones antes de un release al público final.1 Desarrollo Iterativo. Longitud de las iteraciones. la longitud recomendada de una iteración oscila entre 1 y 6 semanas. En los métodos modernos. .3.1.

. Ejemplo.1. Desarrollo riesgos: iterativo dirigido por los Seleccione los elementos más riesgosos y difíciles para las primeras iteraciones.3.1 Desarrollo Iterativo. Los métodos IID promueven una combinación de prioridades dirigida por el cliente y por los riesgos.000 transacciones simultáneas” .Un cliente podría decir: “Deseo que las páginas Web sean verdes y que el sistema maneje 5.

3.1 Desarrollo Iterativo. De esta forma el cliente adaptativamente planea la selección para la siguiente iteración.1. solicitando las características que en ese momento considera de mayor valor. iteración por iteración. basado en la experiencia adquirida en la iteración previa. Desarrollo cliente: La iterativo dirigido por el elección de características para cada iteración debe venir del cliente –cualquiera que sea lo que él considera de mayor valor. más . brevemente antes de iniciarla. De esta forma el cliente conduce el proyecto.

1. .  Los desarrolladores no siempre aprecian lo que es de más alto valor para el negocio. Aplique ambas técnicas… Porque:  Los clientes no siempre son capaces de percibir lo que técnicamente es más difícil o riesgoso.1 Desarrollo Iterativo.3.

1. El principio de Timeboxing. Si eventualmente sucediera que las solicitudes hechas (ámbito) para una iteración no pueden satisfacerse dentro del timebox.3.1 Desarrollo Iterativo. entonces en lugar de cambiar la fecha final. el ámbito se reduce (colocando las prioridades de más bajo riesgo al final de . Este principio debería aplicar también para la fecha final de todo el proyecto. Es la práctica de mantener fija la fecha final de la iteración y no permitir cambios.

3. Esto con el fin de que se obtenga un sistema parcial (pero creciente) en un estado estable y probado. El principio de Timeboxing. . Si el paso normal de trabajo es insuficiente.1. haga menos.1 Desarrollo Iterativo. Es importante que el Timeboxing no se utilice para presionar a los desarrolladores para que trabajen largas horas para cumplir con la inminente fecha de terminación.

Como ya mencionamos la recomendada es: 1 a 6 semanas. El principio de Timeboxing.1. longitud . La segunda iteración 3 semanas.1 Desarrollo Iterativo.3. No todos los time-box necesitan ser iguales: La primer iteración puede ser 4 semanas. etc.

El principio de Timeboxing. Mejor retroalimentación.3. Menor riesgo. Más alta productividad. . Todos los métodos modernos (incluyendo Scrum.1. XP o UP) requieren o recomiendan aplicar timeboxing a las iteraciones. Se ha demostrado que Pasos cortos poseen: Menor complejidad.1 Desarrollo Iterativo. Mayor razón de éxito.

1 Desarrollo Iterativo. . El principio de Timeboxing.1.3.

Beneficios de Timeboxing.1 Desarrollo Iterativo.1. . Las personas recuerdan más fechas postergadas que características postergadas: es un capricho de la naturaleza humana.3. Enfoque: El enfoque psicológico que promueve una fecha de terminación fija de 3 semanas es muy diferente al que promueve una de 3 meses. Time boxing es un antidoto a la Ley de Parkinson: “El trabajo se expande para ocupar todo el tiempo disponible”.

Forza tempranamente a tomar decisiones difíciles y de compensación: se obliga a ser realista en lo que se hará y en lo que no se hará.1. Forzar a atacar niveles pequeños de complejidad: la investigación ha demostrado que pasos de complejidad baja se realizan más productivamente. Beneficios de Timeboxing. .3. Obliga al manejo de prioridades.1 Desarrollo Iterativo.

1.2 Desarrollo Evolutivo. Los métodos evolutivos son consistentes con el patrón de descubrimiento y cambio no .3. Los requisitos. planes. estimaciones y soluciones evolucionan o se refinan en el transcurso de las iteraciones. Desarrollo iterativo-evolutivo. En lugar de ser completamente definidos o “congelados” en un esfuerzo mayúsculo de especificación antes de que el desarrollo iterativo empiece.

testers. Implica que los elementos se adaptan en respuesta al “feedback” del trabajo anterior –”feedback” de usuarios. pero el nombre sugiere un mecanismo más fuerte de repuestafeedback en la evolución. . desarrolladores. Desarrollo adaptativo. etc.1. Es un término relacionado con evolutivo.2 Desarrollo Evolutivo. La intención es la misma que en el desarrollo evolutivo.3.

mucho del descubrimiento y refinamiento ocurre durante las primeras iteraciones.1. Al contrario. Análisis evolutivo de requisitos. La atención más temprana es dada a entender los requisitos arquitectónicamente más significativos . En el desarrollo evolutivo y adaptativo no se trata de que los requisitos están “sin límite” o “cambiantes continuamente”.3.2 Desarrollo Evolutivo.

Esto ha sido llamado el cono de . la planeación adaptativa y evolutiva no se trata de que los estimados y fechas se desconozcan por siempre. Esto es. Igual que con los requisitos.2 Desarrollo Evolutivo.3.1. Planeación evolutiva y adaptativa. debido a que los primeros requisitos son muy cambiantes (y a otros factores). existe una fase inicial de alto nivel de incertidumbre. la cual declinará conforme el tiempo avance y la información se acumule.

2 Desarrollo Evolutivo. .1. esfuerzo o tiempo hasta que unas pocas de las iteraciones han pasado. donde es común una fase exploratoria inicial.3. La respuesta iterativa a la incertidumbre es postergar los estimados semi-confiables de costo. Esto es consistente con otras prácticas administrativas en otros dominios de desarrollo de nuevos productos. Respuesta iterativa a la incertidumbre. Razonablemente un 10% o 20% del proyecto.

2 Desarrollo Evolutivo. se motiva a la planeación adaptativa más que a la planeación predictiva.3. de tal manera que el nivel de detalle y compromiso se consensa con la calidad de la información. Respuesta iterativa a la incertidumbre. . una planificación detallada no se crea hasta que se ha avanzado más allá de un breve tiempo.1. Es decir. Aún más.

algunos métodos. IID recomiendan realizar el proyecto en un contrato de dos fases. .1.2 Desarrollo Evolutivo. cada uno de múltiples iteraciones “timeboxed”.3. Con respecto a hacer una oferta de precio fijo y estimaciones evolutivas. Contratos de precio fijo.

se comparte con los clientes para el contrato de precio fijo de la segunda fase. con el objetivo de en unas cuantas iteraciones.2 Desarrollo Evolutivo.3.1. y precio fijo. desarrollo temprano (pero software y análisis evolutivo de El resultado de la fase –incluyendo el software base. Contrato de dos fases. . Primera fase: Un contrato relativamente pequeño de tiempo fijo cumplirse haciendo parcial) de requisitos.

. El refinamiento evolutivo de las especificaciones y código en la fase uno ofrece datos de mayor calidad para los estimadores de la fase dos y al mismo tiempo ofrece avances del software. Contrato de dos fases.2 Desarrollo Evolutivo.1.3.

Entrega Incremental.2 Desarrollo Evolutivo. Un ciclo de entrega de 6 meses podría componerse por 10 .1. Es una práctica promovida por los métodos ágiles e IID.3. Las entregas incrementales son en un rango de 3 a 12 meses. Esta práctica no debe confundirse con el desarrollo iterativo. Es la práctica de entregar repetidamente un sistema a producción (o al mercado) en una serie de capacidades extendidas.

2 Desarrollo Evolutivo.3. Con la diferencia de que aquí existe un interés muy marcado por obtener “feedback” respecto al producto instalado y usar este “feedback” para guiar la siguiente entrega. Es un refinamiento de la entrega incremental.1. Entrega Evolutiva. . El objetivo es conocer necesidades difíciles de predecir.

Su lema es: Enfrentar el cambio. Planeación adaptativa.3. Los métodos ágiles aplican: Desarrollo evolutivo e iterativo “timeboxed”.3 Desarrollo Ágil. Incluyen otros valores y prácticas que motivan la agilidad-respuestas rápidas y flexibles al cambio. Promueven entregas evolutivas. Su punto estratégico es: Maniobrabilidad .1.

3 Desarrollo Ágil. No es posible definir exactamente a los métodos ágiles. Refinamiento adaptativo y evolutivo de planes y objetivos . porque las prácticas varían. Pero las siguientes prácticas compartidas por diversos métodos: son Iteraciones pequeñas “timeboxed”.1.3.

3 Desarrollo Ágil. ligereza. programación sobre documentación y más. comunicación. equipos autodirigidos. Además los métodos ágiles promueven prácticas y principios que reflejan una “sensación de agilidad” como: simplicidad. Ejemplos de prácticas ágiles en Scrum son: Un lugar común para el proyecto.3.1. Equipos auto-dirigidos que se coordinan a través de reuniones diarias con preguntas .

Ejemplos de prácticas ágiles en XP son: Usar notas concisas en papel (story cards) para sumarizar requisitos. . Trabajar en un lugar común con participación de tiempo completo de “proveedores de requisitos” para que los requisitos escritos puedan complementarse con explicaciones verbales.1. Programar en parejas.3 Desarrollo Ágil.3.

ágil es más nuevo que el enfoque iterativo.3. la mayoría (por no decir todos) están adoptando los valores y prácticas ágiles –es raro que alguien promueva la no-agilidad. pero se pueden aplicar en un espíritu ágil. Aunque podríamos imaginar métodos IID noágiles. .3 Desarrollo Ágil. Muchos métodos IID (Evo o UP) no fueron diseñados como ágiles en su definición original. Como concepto de proceso de software.1.

Clasificación de los ceremonia y ciclos.1.3 Desarrollo Ágil. métodos por .3.

Nuestra más alta prioridad es satisfacer al cliente a través de entregas continuas y tempranas de software valuable. Prefiera escalas breves de tiempo.1. Los procesos ágiles aprovechan el cambio a favor de la ventaja competitiva del cliente. desde pocas semanas hasta pocos meses. 2.3.3 Desarrollo Ágil. Principios ágiles. . Bienvenidos los cambios de requisitos aún en etapas posteriores al desarrollo. Entrega frecuente de software trabajando. 1. 3.

.1. Dales el ambiente y soporte necesario y confía en que harán bien el trabajo. 6.3. 5. Construye el proyecto con gente motivada. La gente del negocio y los desarrolladores deben trabajar en conjunto diariamente a lo largo del proyecto. 4. El método más eficiente y efectivo para conllevar información hacia y dentro el equipo de desarrollo es la conversación cara-a-cara.3 Desarrollo Ágil. Principios ágiles.

3 Desarrollo Ágil. 9. Atención constante a la excelencia técnica y el buen diseño aumenta la agilidad. Los patrocinadores. 10. Los procesos ágiles promueven el desarrollo sustentable.3. . Principios ágiles.1. 7. 8. desarrolladores y usuarios deben mantener una paz constante indefinidamente. Software trabajando es la medida principal de progreso.

Principios ágiles. 11.3 Desarrollo Ágil. Las mejores arquitecturas.1. acorde a lo cual ajusta su comportamiento. A intervalos regulares. Simplicidad-el arte de maximizar el monto de trabajo no hecho-es esencial. . el equipo reflexiona sobre como ser más efectivo. 12. requisitos y diseños emergen a partir de equipos auto-organizados.3. 13.

3 Desarrollo Ágil. XP y Scrum son los métodos ampliamente utilizados. XP: es el método ágil más conocido. ágiles más Scrum: su énfasis distintivo entre los métodos es su fuerte promoción a los equipos auto-organizados. enfatiza la colaboración. Métodos ágiles específicos.3. De acuerdo a una encuesta de Shine.1. rápida y temprana . a la medición diaria de los equipos y el evitar seguir pasos predefinidos.

3. Métodos ágiles específicos. Retroalimentación Coraje o valor. .1.3 Desarrollo Ágil. Simplicidad. XP se fundamenta en 4 valores: Comunicación.

El Modelado Ágil promueve la creación colaborativa “low-tech.3. Sus prácticas promueven velocidad. simplicidad y creatividad . Es un conjunto de principios y prácticas para el análisis de requisitos y modelado que complementa a muchos métodos IID.1. Modelado Ágil.3 Desarrollo Ágil. high-touch” con modelos que ayuden más al entendimiento y la comunicación.

3. Prácticas del Modelado Ágil.3 Desarrollo Ágil.1. .

4 El Framework del UP .1.

Introducción ¿ Qué es Ingeniería de Software ? • El establecimiento y uso de principios de ingeniería robustos. disciplinado y cuantificable al desarrollo. (Fritz Bauer 1969) • La ingeniería de software es la aplicación de un enfoque sistemático. operación y mantenimiento del software. [IEEE93] . orientados a obtener software económico que sea fiable y funcione de manera eficiente sobre máquinas reales.

. Estos objetos existen en la naturaleza. Por eso no es sorprendente que se proponga una visión orientada a objetos para la creación de software de computadora. Pueden ser clasificados. descritos. combinados.Introducción Orientación a Objetos Vivimos en un mundo de objetos. manipulados y creados. una abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. en los negocios y en los productos que usamos. en entidades hechas por el hombre. organizados.

.Introducción Orientación a Objetos El término orientado a objetos significa que el software se organiza como una colección de objetos que contienen tanto estructuras de datos como comportamiento.

Introducción OBJETOS BICICLETA Bicicleta Se hace una abstracción que resulta en Tam. De la rueda marchas material Cambiar marcha() mover() reparar() .del cuadro Tam.

Introducción Orientación a Objetos El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Estos conceptos y herramientas orientados a objetos son tecnologías que permiten que los problemas del mundo real sean expresados de modo fácil y natural. .

hay mucho más que sólo programar: Debemos realizar los planos (análisis y diseño) que definen cómo solucionar el problema para obtener un producto software. Entre las ideas espléndidas. Diseñar la Base de Datos Etcétera.Introducción Programar es divertido. pero desarrollar software de calidad es difícil. los requisitos y un producto software funcionando. . Definir el modelo arquitectónico Aplicar la ingeniería de usabilidad.

Introducción ¿Qué es el análisis? Es el estudio de un dominio que da como resultado los modelos que describen sus características estáticas y dinámicas. en vez de ponerlos en una solución. “Análisis” es un término amplio. Se centra en las cuestiones del “que” en lugar del “como”. es más adecuado calificarlo como análisis de requisitos (un estudio de los requisitos) o análisis de objetos (estudios de objetos del dominio) ¿Qué es el análisis orientado a objetos? Es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se . Pone énfasis en una investigación del problema y los requisitos.

etc. Aseguradora. Cliente.… . Socio En el caso del sistema de vuelos: Pasajeros.Introducción Análisis Orientado a Objetos. En el caso del sistema de la biblioteca: Libro. Ejemplos: En el caso del sistema de renta de auto: Auto. Se presta especial atención a encontrar y describir los objetos en el dominio del problema. Aviones. Biblioteca.

Introducción Diseño:  Pone énfasis en una solución conceptual que satisface los requisitos.  Diseño orientado a objetos: Se presta especial atención a la definición de los objetos software y en cómo colaboran para satisfacer los requisitos. en vez de ponerlo en la implementación. Ejemplos: ESPACIO DE LA SOLUCIÓN Objeto LIBRO Titul o GetCap(int c) Atribut o Operación Una habilidad crítica en el desarrollo OO es la asignación inteligente de responsabilidades a los objetos software .

} } ..Introducción Análisis y Diseño Orientado a Objetos.. public List getFlightHistory() {. Plane tailNumber domain concept representation in an object-oriented programming language visualization of domain concept public class Plane { private String tailNumber.

Introducción Análisis y Diseño Orientado a Objetos. El análisis y diseño se han resumido en las freses: • Hacer lo correcto (análisis) • Hacerlo correcto (diseño) .

Requerimientos del usuario Proceso de Desarrollo de Software Sistema Software .Proceso de desarrollo de software Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema de software.

aunque éste sea cada vez más complejo. Esta tendencia también ha sido influenciada por el extensivo uso del internet para intercambiar todo tipo de información. En resumen queremos cada vez más. . la gente desarrolla software usando métodos que fueron usados desde hace 35 años.Proceso de desarrollo de software  Hoy en día la tendencia del software es hacia sistemas más grandes y complejos. Hoy en día. Nuestra demanda de software complejo y poderoso no concuerda con el cómo será desarrollado dicho software. el tiempo para construirlo es otro factor importante.  También lo queremos más rápido. Queremos software que esté mejor adaptado a nuestra necesidades.

Proceso de desarrollo de software La comunidad de desarrollo de software necesita una manera de controlar el trabajo. Se necesita un proceso que integre las muchas facetas del desarrollo de software. .

Especifique que artefactos deben ser desarrollados Ofrezca criterios para monitorear y medir las actividades y productos de un proyecto. un proceso que: Proporcione una guía para el orden de las actividades del equipo Dirija las tareas de los desarrolladores individualmente y del equipo como un todo.Proceso de desarrollo de software Necesitamos un método común. .

Unified Process (UP) Framework
La presencia de un proceso bien definido
y bien manejado es un discriminador
clave entre un proyecto productivo y
exitoso y uno que no lo es.
El proceso unificado, se ha convertido
en un proceso de desarrollo de software
de gran éxito para la construcción de
sistemas orientados a objetos.

Unified Process (UP) Framework
El UP utiliza el lenguaje unificado para la

creación de modelos (UML).

UML es una parte integral del Proceso

Unificado, fueron desarrollados a la par.

Los aspectos que realmente distinguen al

Proceso Unificado se capturan en tres
frases claves:
Conducido por casos de uso
Centrado en la arquitectura
Iterativo e incremental

El PU conducido por casos
de uso
Ejemplo: uso de un cajero automático.

El usuario inserta una tarjeta, responde a las
preguntas que emite el cajero en su pantalla
y recibe una suma de efectivo.
En respuesta a la tarjeta del usuario y sus
preguntas, el sistema realiza una secuencia
de acciones
que provee al usuario un
resultado de valor, llamado retiro de fondos.
Una interacción de este tipo es un caso de
uso.

construyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Los casos de uso capturan los requerimientos funcionales.El PU conducido por casos de uso Un caso de uso es una pieza de funcionalidad en el sistema que da al usuario un resultado de valor. . Todos los casos de uso juntos.

. también conducen su : Diseño. Es decir: Los casos de uso conducen el proceso de desarrollo.El PU conducido por casos de uso Los casos de uso no solo son una herramienta para especificar los requerimientos de un sistema. Prueba. Implementación y.

. servicios. El edificio es observado desde varios puntos de vista: estructura.El PU centrado en la arquitectura El rol de la arquitectura del software es similar en naturaleza al rol que juega la arquitectura en la construcción de un edificio. la arquitectura en un sistema de software se describe con diferentes vistas del sistema que será construido. Similarmente. electricidad. etc.

no Requerimientos no funcionales: en la ingeniería de software es un requerimiento que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos.  Consideraciones de distribución. ya que éstos corresponden a los requerimientos funcionales.  Bloques reusables disponibles.El PU centrado en la arquitectura La arquitectura está influenciada por otros factores tales como:  La plataforma sobre la cual se va a ejecutar el sistema.  Sistemas heredados y requerimientos funcionales. .

En este caso la función corresponde a los casos de uso y la forma a la arquitectura. la interacción entre los casos de uso y la arquitectura. Estas dos fuerzas deben estar balanceadas par obtener un producto exitoso. Uno o el otro no es suficiente. por lo tanto. . ¿Cómo se relacionan los casos de uso y la arquitectura? Cada producto tiene función y forma. en cambio. En cuánto tiempo debería el sistema actualizar su verificación interna de cantidad de datos es. un requerimiento no funcional. Se necesita.El PU centrado en la arquitectura A un sistema se le puede pedir que muestre en tiempo real la cantidad de datos de una base de datos: ése es un requerimiento funcional.

. sino a través de futuras generaciones. la arquitectura. que permita al sistema evolucionar. debe ser diseñada de manera tal. no solamente a través de su desarrollo inicial. los arquitectos deben tener un entendimiento general de las funciones claves. Esa forma. los casos de uso claves del sistema. Para encontrar tal forma.El PU centrado en la arquitectura El arquitecto moldea el sistema en una forma. esto es.

El resultado de cada uno es un sistema que puede ser probado. Cada iteración incluye sus propias actividades de análisis de requisitos. de duración fija (por ejemplo. . cuatro semanas) llamados iteraciones. diseño implementación y pruebas. integrado y ejecutado. el desarrollo se organiza en una serie de mini-proyectos cortos.El PU es iterativo e incremental Bajo este enfoque.

Esto es.  El sistema crece incrementalmente a lo largo del tiempo.El PU es iterativo e incremental  El ciclo de vida iterativo se basa en la ampliación y refinamiento sucesivos del sistema mediante múltiples iteraciones.  Proceso Iterativo Incremental: se dice que un proceso es iterativo incremental cuando en cada iteración de sus pasos se alcanza una mayor cercania con los objetivos finales. con retroalimentación cíclica y adaptación como elementos principales que dirigen para converger hacia un sistema adecuado. . iteración tras iteración. por eso se dice que es iterativo e incremental. se añade algo nuevo de valor en cada iteración.

Integración final & Pruebas de sistema 4 semanas (por ejemplo) Se fija la duración de Las iteraciones El sistema crece de manera incremental .Requisitos Requisitos Diseño Diseño Implementación & Prueba & Integración & más diseño TIEMPO Integración final & Pruebas de sistema Implementación & Prueba & Integración & más diseño La retroalimentación de la iteración N nos lleva a refinar y adaptar los requisitos y diseño de la iteración N+1.

pero incompleto. 10 o 15. y el desarrollo iterativo no es prototipado.El PU es iterativo e incremental El resultado de cada iteración es un sistema ejecutable. la salida es un subconjunto con calidad de producción del sistema final. La salida de una iteración no es un prototipo experimental o desechable. . no está preparado par ser puesto en producción. Más bien. El sistema estaría listo después de muchas iteraciones por ejemplo.

El PU es iterativo e incremental Los desarrolladores basan la selección de lo que será desarrollado en cada iteración tomando en cuenta dos factores: Primero: La iteración trata con un grupo de casos de uso que juntos amplían la utilidad del producto. . según lo desarrollado hasta ahora. Segundo: La iteración se ocupa de los riesgos más importantes.

usabilidad y demás).  El conocimiento adquirido en una iteración se puede utilizar metódicamente para mejorar el propio proceso de desarrollo.Beneficios del desarrollo iterativo  Mitigación tan pronto como sea posible de los riesgos altos (técnicos. requisitos.  Una temprana retroalimentación. compromiso de los usuarios y adaptación que nos lleva a un sistema refinado que se ajusta más a las necesidades reales del personal involucrado. iteración tras . objetivos. el equipo no se ve abrumado por la “parálisis del análisis” o pasos muy largos y complejos.  Gestión de la complejidad.  Progreso visible en las primeras etapas.

Son igualmente importantes. . El desarrollo es iterativo e incremental. La arquitectura proporciona la estructura en la cual se guía el trabajo en las iteraciones. mientras que los casos de uso definen las metas y conducen el trabajo de cada iteración.EN RESUMEN Los conceptos: Dirigido por casos de uso. El quitar una de estas tres ideas reduciría severamente el valor del proceso unificado. Centrado en la arquitectura.

estimaciones más realistas.  Transición: pruebas beta. Elaboración: visión refinada. análisis del negocio. Construcción: implementación iterativa del resto de requisitos de menor riesgo y elementos más fáciles. identificación de más requisitos y alcance. estimaciones imprecisas de plazos y costos. despliegue. preparación para el despliegue. .Las Fases del PU Un proyecto con el PU organiza el trabajo y las iteraciones en 4 fases fundamentales: Inicio: visión aproximada. Se define la viabilidad del proyecto. resolución de los riesgos altos. implementación iterativa del núcleo central de la arquitectura.

sino una fase donde se implementa de manera iterativa. . que constituye el núcleo central y se mitigan las cuestiones de alto riesgo. la arquitectura. sino una especie de fase de viabilidad. donde se lleva a cabo solo el estudio suficiente para decidir si continuar o no.Las Fases del PU La fase de inicio NO es una fase de requisitos. La fase de elaboración NO es la fase de requisitos o de diseño.

.La vida del PU Cada fase esta subdividida en iteraciones Inicio Iter. Transición Iter. #n-1 versiones Un ciclo con sus fases y sus iteraciones Iter. # 2. #n… . #1 Elaboración Construcción Iter.

The UP Disciplines Process Disciplines Phases Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Disciplines Configuration Mgmt Management Environment Preliminary Iteration(s) Iter. #m Iter. #1 Iter. #m+1 . #n+1 #n+2 Iterations Iter. #2 Iter. Iter. #n Iter.

Nos centraremos en 3 disciplinas: modelado del negocio. gráficos Web. En el PU. diagramas. requisitos y diseño. esquema de base de datos. un artefacto es el término general para cualquier producto del trabajo: código. modelos.Disciplinas del PU (flujos de trabajo) Informalmente una disciplina es un conjunto de actividades (y artefactos relacionados) en un área determinada como las actividades en el análisis de requisitos. etcétera. documento de texto. .

Disciplinas del PU (flujos de trabajo)
 Modelado del negocio

Una vez que los miembros del equipo de requisitos
se han familiarizado con el lenguaje, el siguiente
paso es:
 construir el modelo del negocio inicial, que es una

descripción de los procesos de una empresa (ejemplo: un
banco incluye aceptar depósitos de los clientes, conceder
préstamos a los clientes y hacer inversiones).

La razón para construir un modelo de negocios es
que proporciones una comprensión de los negocios
del cliente como un todo,
 con este conocimiento es posible aconsejar al cliente

respecto de qué porciones del sistema de información
computarizar.

Disciplinas del PU

modelado del

negocio

Ejemplo: los procesos de negocios de una empresa
de servicios de banquetes incluyen:
 comprar los ingredientes,
 preparar los alimentos,
 servir la comida

El proceso comprar ingredientes refinado
El encargado del servicio de banquetes ordena los
ingredientes a un mayorista
El mayorista entrega los ingredientes al encargado del
servicios de banquetes
 El mayorista envía una factura al encargado de banquetes
El encargado de banquetes paga la factura

Disciplinas del PU

modelado del

negocio

Pueden usarse una serie de técnicas para
obtener
información
necesaria
para
construir
el
modelo
de
negocios,
principalmente la entrevista.
Requisitos: análisis de requisitos para la
aplicación, escritura de casos de uso e
identificación de requisitos no funcionales.

Una manera de lograrlo es usar el PU. lo requisitos tienen que ser comprendidos por el cliente. Esto se logra al describir el sistema de información objetivo de una manera suficientemente clara y precisa como para que los dos involucrados principales (cliente y desarrolladores) puedan ponerse de acuerdo en lo que debe y no debe hacer el sistema de información. . Con el fin de lograr esto.Disciplinas del PU modelado del negocio El objetivo de esta disciplina es asegurar que los desarrolladores construyan el sistema de información correcto. porque sus diversos modelos ayudan al cliente a obtener la comprensión detallada necesaria de lo que se va a desarrollar.

Al hacerlo se logra la comprensión detallada de los requisitos que deben tener para desarrollar correctamente un sistema de información y darle mantenimiento con facilidad.Disciplinas del PU modelado del negocio Análisis. inglés. armenio.…). El propósito de esta disciplina es examinar y refinar los requisitos. ¿por qué tener la disciplina de análisis? El punto clave es que los artefactos de la disciplina de requisitos deben expresarse en el lenguaje del cliente. pero todos los lenguajes naturales de alguna manera son imprecisos y conducen a malas interpretaciones. . es decir en un idioma natural (español.

. Si el registro contiene la letra A justo después de la Q.” A primera vista ese requisito parece perfectamente claro. Con la disciplina de requisitos se formula en el lenguaje del cliente y la disciplina de análisis es un lenguaje más preciso que asegurará que las disciplinas de diseño e implementación se llevarán a cabo correctamente. Pero ¿a qué se refiere el “registro” (registro de partes o registro de plantas). “Un registro de partes y un registro de las planta de fabricación de las mismas se buscan en una base de datos.Disciplinas del PU Análisis Ejemplo: Se tiene el siguiente requisito. entonces se calcula el costo de transportar esa parte a la planta.

Disciplinas del PU Diseño. así como la reutilización y los problemas de portabilidad. incluyendo la elección del lenguaje de programación. Además una serie de requisitos necesitan familiarizarse en este momento. En esta disciplina se refina los artefactos del análisis hasta que el material esté en una forma en que los programadores puedan implementar. .

una vez que el programador está seguro de que el componente es correcto.Disciplinas del PU Implementación. El objetivo de esta disciplina es instaurar el sistema de información deseado en el lenguaje deseado. En cuanto el componente se ha codificado. se pasa al grupo de aseguramiento de la calidad para una prueba posterior. el programador lo prueba. .

Esta disciplina es responsabilidad del grupo de aseguramiento de la calidad. se prueba en conjunto: a esto se llama prueba de producto. . Cada componente que se ha terminado se prueba. se compilan y se ligan y luego se prueban con varios casos de prueba. Al final de cada iteración se realiza la prueba de integración. Cuando el producto parece estar completo.Disciplinas del PU Pruebas. Aquí los componentes que se han completado y a los cuales se les han aplicado las prueba de unidad. a esto se le llama prueba de unidad.

Disciplinas y modelos en el PU Requerimientos Modelo de casos de uso Análisis Modelo de análisis Diseño Modelo de diseño Modelo de distribución Implementación Modelo de implementación Prueba Modelo de pruebas .

con frecuencia y realistas. pruebas muy pronto.Buenas prácticas del PU adicionales  Lo fundamental para apreciar y aplicar el PU es el desarrollo iterativo (fijando iteraciones cortas) y adaptable.  Uso de tecnologías de objetos (A/DOO Y POO).  Abordar cuestiones de alto riesgo en las primeras iteraciones.  Gestionar los requisitos con cuidado. retroalimentación y requisitos.  Involucrar continuamente a los usuarios para evaluación.  Verificar la calidad continuamente.  Manejar peticiones de cambio y gestión de .  Modelar software visualmente (UML).  Aplicar casos de uso.  Construir en las primeras iteraciones una arquitectura que constituya un núcleo central consistente.