Planificación

1. Proceso Orientado a Objetos Análisis OO Diseño OO Programación OO Pruebas OO Análisis de riesgos Planificación Identificar Clases candidatas Comunicación con el cliente Construir N-ésima Interacción del sistema Buscar clases en biblioteca Evaluación del cliente Extraer nuevas clases si existen Añadir las nuevas clases a la biblioteca Ingeniería Construcción y Terminación Desarrollar las clases si no existen

2. Conceptos Básicos Orientación a objetos = Objetos + clasificación + herencia + comunicación CLASE Concepto OO que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real OBJETOS Existen dentro de una clase y heredan los atributos y operaciones disponibles para la manipulación de atributos, en los cuales se pueden añadir atributos y operaciones “privadas” SUPERCLASE: Colección de clases SUBCLASE: Instancia de una clase

3. Conceptos Básicos ATRIBUTOS Característica binaria que puede verse como una relación binaria entre una clase y cierto dominio (característica) OPERACIONES, METODOS Y SERVICIOS Algoritmos que procesan los datos (atributos) encapsulados proporcionando una representación de los comportamientos del objeto MENSAJES Medio a tráves del cual los objetos interactúan. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor, el mismo que se realiza cuando se ejecuta una operación

4. Nombre de la clase (superclase) Nombre de la clase (superclase) Objeto B (receptor) Objeto A (emisor) Atributos Atributos Atributos Atributos Operaciones Operaciones Operaciones Operaciones Conceptos Básicos (A) (B) (A) Mensaje:[receptor, operación, parámetros] (B) Mensaje:[emisor, valores de retorno]

5. Conceptos Básicos • ENCAPSULAMIENTO • Detalles de implementación interna de datos y operaciones están ocultos al mundo exterior (reducción de propagación de defectos) • Las estructuras de datos y las operaciones que las manipulan están mezcladas en un entidad sencilla: la clase (reutilización) • Las interfaces entre objetos encapsulados están simplificados • HERENCIA • Una subclase Y hereda los atributos y operaciones de la superclase X. La jerarquía de clases se convierte en un mecanismo a tráves del cual los cambios pueden propagarse inmediatamente a través de todo el sistema • ANULACION: Cuando los atributos y operaciones de heredan de manera normal, pero después son notificados según las necesidades de una nueva clase

6. Conceptos Básicos HERENCIA MULTIPLE: Cuando se heredan atributos y operaciones de varias clases (no recomendada) POLIMORFISMO Generalización que contiene varias clase u objetos y mediante SOBRECARGA, cada subclase define operaciones similares que pueden ser llamadas mediante el objeto general

7. IDENTIFICACION DE CLASES Y OBJETOS • TIPOS DE OBJETOS • ENTIDADES EXTERNAS: Que producen o consumen información a usar por un sistema computarizado (sistemas, dispositivos, personas, etc.) • COSAS: Que son parte del dominio de información del problema (informes, cartas, señales, etc) • OCURRENCIAS O EVENTOS: Que ocurren dentro del contexto de operación del sistema (transferencia de propiedad, etc) • PAPELES O ROLES: Desempeñados por personas que interactuan coin el sistema (contador, vendedor, etc) • UNIDADES ORGANIZACIONALES: Que son relevantes en una aplicación (grupo, departamento, etc) • LUGARES: Que establecen el contexto del problema y la función general del sistema (planta, muelle, bodega) • ESTRUCTURAS: Que definen una clase de objetos, o en casos extremos, clases relacionadas de objetos (sensores, computadoras, etc.)

8. IDENTIFICACION DE CLASES Y OBJETOS • CARACTERISTICAS DE SELECCION • INFORMACION RETENIDA: El objeto será de utilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funcione • SERVICIOS NECESARIOS: El objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de los atributos • ATRIBUTOS MULTIPLES: Durante el análisis de requisitos, se debe centrar la atención en la información principal • ATRIBUTOS COMUNES: Puede definirse un conjunto de atributos para el objeto potencial, las cuales son aplicalbes a todas las ocurrencias del objeto • OPERACIONES COMUNES: Puede definirse un conjunto de operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto • REQUISITOS COMUNES: Entidades externas que aparecen en el espacio del problema y producen o consumen información esencial para la producción de cualquier solución para el sistema serán casi siempre definidas como objetos en el modelo de requisitos

9. IDENTIFICACION DE CLASES Y OBJETOS • ESPECIFICACION DE ATRIBUTOS • Los atributos describen un objeto que ha sido seleccionado para ser incluído en el modelo de análisis. • ¿Qué elementos (compuestos yo simples) definen completamente al objeto en el contexto del problema actual? • DEFINICION DE OPERACIONES • Operaciones que manipulan de alguna manera datos (añadir, eliminar, seleccionar, modificar) • Operaciones que realizan algún cálculo • Operaciones que monitorean un objeto frente a la ocurrencia de un suceso de control • OPERACIONES ADICIONALES: Historia de la vida del objeto y los mensajes que pasan entre objetos definidos por el sistema.

10. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS • Establecimiento de un MARCO DE PROCESO COMÚN (enfoque organizativo para el desarrollo y mantenimiento de software – por lo general modelo recursivo/paralelo) para el proyecto • Uso del marco y métricas históricas para desarrollar estimaciones de esfeurzo y tiempo • Especificación de productos de trabajo y avnaces que permitirían la medición del progreso • Definición de puntos de comprobación para asegurar la calidad y control • Gestión de los cambios que ocurren invariablemente al progresar el proyecto • Seguimiento, monitoreo y control del progreso

11. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS Planificación Análisis Diseño Primeras iteraciones en análisis / diseño Revisión y refinamiento Análisis Diseño Análisis Diseño Revisión y refinamiento Primer prototipo Planificación Análisis Diseño Extraer clases reutilizables Prototipo Probar Evaluación del cliente Revisión y refinamiento Siguiente incremento Planificación Análisis Diseño Extraer clases reutilizables Prototipo Probar Evaluación del cliente Revisión y refinamiento N-ésimo incremento Planificación Análisis Diseño Extraer clases reutilizables Prototipo Probar Evaluación del cliente

12. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS METRICAS Y ESTIMACION DE PROYECTOS ORIENTADOS A OBJETOS NUMERO DE GUIONES DE ESCENARIO Secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación. Cada guíon se organiza en tripletes de la forma {iniciador, acción, participante} Donde iniciador, objeto que solicita algún servicio; acción, resultado de la solicitud; particpante, objeto servidor Este número está directamente relacionado con el tamaño de la aplicación y el número de casos de prueba que se requieren

13. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS METRICAS Y ESTIMACION DE PROYECTOS ORIENTADOS A OBJETOS NUMERO DE CLASES CLAVE Componentes altamente independientes que son parte del dominio del problema. Este número es una indicación del esfuerzo necesario para desarrollar el software y de la cantidad potencial de reutilización a aplicarse durante el desarrollo NUMERO DE CLASES DE SOPORTE Clases necesarias que no están directamente relacionadas con el dominio del problema. Indicador de esfuerzo necesario requerido para para desarrollar el software y la cantidad potencial de reutilización a aplicarse durante el desarrollo

14. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS METRICAS Y ESTIMACION DE PROYECTOS ORIENTADOS A OBJETOS NUMERO PROMEDIO DE CLASES DE SOPORTE POR CLASE CLAVE Aplicaciones con IGU poseen entre dos y tres veces más clases de soporte que clases clave. Sin IGU, este número a lo sumo es de dos Sistema = clases clave + clases de soporte NUMERO DE SUBSISTEMAS Agregación de clases que dan soporte a una función visible al usuario final del sistema. Su identificación permite una mejor planificación

15. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS • ESTIMACIONES Y PLANIFICACION • Desarrollo de estimaciones usando la descomposición de esfuerzos, análisis de PF y cualquier otro método aplicable • Desarrollo de guiones de escenario y determinar una cuenta usando AOO. Considerar que el número puede variar en el tiempo • Determinar la cantidad de clases clave usando AOO • Clasificar el tipo de interfaz y para la aplicación y desarrollar un multiplicador para la clase de soporte (interfaz no gráfica, 2.0; interfaz basada en texto, 2,25; interfaz gráfica de usuario, 2,5; interfaz gráfica de usuario compleja, 3.09). Multiplicar el número de clases clave por el multiplicador para obtener una estimación • Multiplicar la cantidad total de clases (clave + soporte) por el número de unidades de trabajo por clase (entre 15 y 20 días/persona por clase) • Comprobar la estimación respecto a clases multiplicando el número promedio de unidades de trabajo por guíon de acción

16. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS ESTIMACIONES Y PLANIFICACION NUMERO DE ITERACIONES PRINCIPALES Una iteración principal corresponde a un recorrido de 360 grados de la espiral del modelo de desarrollo de objetos. El modelo recursivo/paralelo engendrá un número de mini-espirales que suceden durante el progreso de la iteración principal. Interaciones entre 2.5 y 4 meses de duración son más fáciles de gestionar NUMERO DE CONTRATOS COMPLETOS Grupo de responsabilidades públicas relacionadas generadas por los subsistemas y clases a sus clientes. Debe asociarse al menos un contrato por cada iteración del proyecto

17. GESTION DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS • SEGUIMIENTO DEL PROGRESO EN UN PROYECTO ORIENTADO A OBJETOS • ANALISIS OO TERMINADO • DISEÑO OO TERMINADO • PROGRAMACION OO TERMINADA • PRUEBA OO