ESCUELA POLITECNICA DEL EJÉRCITOESPE

CARRERATECNOLOGÍA EN COMPUTACIÓN

MATERIASOFTWARE II

SEMESTRE MARZ 2011 – SEP 2011

DESARROLLO DE GUIA

ACTIVIDAD DE APRENDIZAJE 1.1.

•Realice una comparación entre objeto representado y objeto representante.

El objeto representado son las entidades y atributos que un objeto pueda tener y el objeto representante se le dice a los datos que contienen los atributos de una entidad.

Por ejemplo:

LA ENTIDAD: PACIENTE Es un objeto representado, ya que representa a un objeto real)ATRIBUTOS: PAC_NOMBRE, DNI_PACIENTE.., etc. Representa una identidad diferente.

Se diferencian de los demás objetos.

En cambio el objeto representante, son los datos que tiene un atributo.

Por ejemplo:

PAC_NOMBRE : Cinthya Johanna DNI_PACIENTE: 00145

Los datos Cinthya Johanna y 00145 son objetos representantes de una entidad.

•Indique las semejanzas y diferencias entre clasificación y herencia

CLASIFICACIÓN HERENCIA

SEMEJANZAS•Comparten una estructura en común•Comparten atributos y operaciones en las clases

DIFERENCIAS

• •Especialización•Cada subclase hereda todas las propiedades de la superclase•Permite factorar propiedades las y operaciones comunes a diferentes clases y colocarlas dentro de una superficie común y utilizarlas después.

•Defina encapsulamiento y polimorfismo.

Encapsulamiento

Consiste en la separación de los aspectos externos de un objeto, accesibles por otros objetos, de los detalles internos de la implementación de aquel objeto, que quedan ocultos de los demás.

Hay muchos datos que no tiene por qué conocerlo, por ejemplo aquel que este usando la clase Persona; ya que son inherentes al objeto y solo controlan su funcionamiento interno; por ejemplo, cuando alguien te ve puede saber inmediatamente si eres hombre o mujer (propiedad) o puede hablarte y obtener una respuesta procesada (método); también puede conocer el color de tu cabello y ojos. En cambio, jamás sabrá que cantidad de energía exacta tienes o cuantas neuronas te quedan, ni siquiera preguntándote ya que ninguna de tus propiedades externas visibles o funciones de comunicación al público te permiten saber esos datos.

Esto es la encapsulación u ocultación; hacer las variables que son innecesarias para el tratamiento del objeto pero necesarias para su funcionamiento privadas, así como las funciones que no necesitan interacción del usuario o que solo pueden ser llamadas por otras funciones dentro del objeto (Como por ejemplo, palpitar).

Significa también que los datos y el código que los manipula son definidos juntos, y que

los datos no pueden ser separados de o accesados separadamente del código asociado, quiere decir que el dato se considera así encapsulado junto con el código.

Polimorfismo

El polimorfismo (o upcasting) consiste en la posibilidad de que una referencia a objetos de una clase pueda conectarse también con objetos de descendientes de ésta.

El sentido del polimorfismo es realizar una generalización, olvidar los detalles concretos de uno o varios objetos de distintas clases y buscar un punto común a todos ellos en un ancestro.Es la característica que permite en la OO tener operaciones con el mismo nombre asociadas a diferentes objetos (clases), pero actuando de forma diferente.

•Defina mensaje y explique cómo se implementa en un lenguaje de objetos.

Es la llamada a una operación de un objeto, realizada por otro objeto. El que llama se denomina objeto remitente y el que recibe el mensaje se denomina objeto receptor. Esta llamada contiene el nombre de la operación invocada junto con los parámetros de la misma. Un mensaje puede, opcionalmente, provocar un cambio de estado en el objeto receptor.

Ejemplo:

estudiante(númeroMatricula:String,nombrematerias:string,valorcosto:double)

Es un mensaje enviado, por ejemplo, desde un objeto estudiante a un objeto matricula.

ACTIVIDAD DE APRENDIZAJE 1.2.

•Para el desarrollo de software existe el PROCESO UNIFICADO RATIONAL (RUP), el que está dividido en fases y en flujos de trabajo. Se pide que el estudiante consulte las características de RUP, así como sus fases y sus flujos, y los describa completamente. También debe describir los Workers o Trabajadores, así como los Artefactos que se producen a lo largo del proceso.

El RUP, tiene dos estructuras:

•DINÁMICO•ESTATICO

1.- EL DINÁMICO, está dividido en ciclos:

•Fases•Iteraciones e hitos

El RUP divide un ciclo de desarrollo en cuatro fases:

•Fase de Iniciación •Fase de Elaboración•Fase de Construcción•Fase de Transición

Iteración de fase

Inicio Elaboración Construcción Transición

- Fase de Iniciación, el objetivo de esta fase es:

•Establecer un caso de negocio para el sistema•Identifica todas las entidades externas (personas y sistemas) que interactúan con el sistema.•Definir estas interacciones.

- Fase de Elaboración, se debe:

•Desarrollar una comprensión del dominio del problema•Establecer un marco de trabajo arquitectónico para el sistema•Desarrollar el plan de proyecto•Identificar los riesgos •Clave del proyecto REVISAR

//Al finalizar esta fase se debe obtener://*Un modelo de los requerimientos del sistema UML //*Descripción Arquitectónica//*Un Plan de desarrollo de Software

- Fase de Construcción, comprende el diseño del sistema con lo obtenido de las dos fases anteriores:

•La Programación•Las pruebas

- Fase de Transición, se ocupa de mover el sistema desde:

•La comunidad de desarrollo a la comunidad usuario y;•hacerlo trabajar en un entorno real.

ITERACIONES:

Cada fase puede ser dividida en iteraciones, y mediante el desarrollo incremental de iteración a iteración se obtiene el sistema final.Tiene las siguientes ventajas:

•Los cambios son más manejables•Un alto nivel de reúso•Mejor calidad global

2.- EL ESTÁTICO, se describe en términos de Componentes del proceso:

•Actividades•Flujos de trabajo•Artefactos•Trabajadores

Trabajador – WorkerDefine la conducta y las responsabilidades de un individuo, o un conjunto de individuos que trabajan en grupo.

Actividad – ActivyUna actividad de un Worker específico es una unidad de trabajo que un individuo puede realizar en ese rol. Tiene un propósito claro, de crear o actualizar algunos artefactos, como un modelo, una clase o un plan.

Artefacto - Artifac Es un fragmento de información que puede ser producido, modificado, o usado por un proceso.

Son los productos tangibles del proyecto, los objetos del proyecto se producen o se usan mientras se trabaja hacia el final del proyectoLos artefactos son usados por los Workers como entradas para realizar una actividad, y como salidas de resultados.

En diseño Orientado a Objetos, las actividades son las operaciones en un objeto activo (the Worker) y los artefactos son los parámetros de estas actividades que pueden tomar los siguientes estados:

•Un modelo, (como el modelo de casos de uso o de diseño)•Un documento, (como el documento d casos del negocio) •Código fuente y ejecutable.

Flujos de Trabajo – Workflows

La enumeración de todos los Workers, actividades y artefactos no constituyen un proceso realmente. Se necesita describir de manera significativa la secuencia de las actividades para producir resultados valiosos, y para mostrar las interacciones entre Workers.

Un Workflow es una secuencia de actividades que produce un resultado de valor observable y en términos de UML, un Workflow puede ser expresado como un diagrama de secuencia, un diagrama de colaboración, etc.

ACTIVIDAD DE APRENDIZAJE 1.3

Plan de Desarrollo de Software

Historial de revisionesVersión Fecha Descripción Autor<dd/mmm/yy> <x.x> <details> <name>

Tabla de contenidos

1. Introducción 21.1 Objetivo 21.2 Alcance 21.3 Definiciones, acrónimos y abreviaturas 21.4 Referencias 21.5 Resumen 22. Descripción del proyecto 22.1 Proyecto Propósito, alcance y objetivos 22.2 Supuestos y limitaciones 22.3 Entregables del Proyecto 22.4 Evolución del Plan de Desarrollo de Software 23. Organización del Proyecto 23.1 Estructura de organización 23.2 Interfaces externa 23.3 Funciones y responsabilidades 24. Gestión de Procesos 24.1 Estimaciones del Proyecto 24.2 Plan del Proyecto 24.3 Seguimiento y Control 24.4 Requerimientos de Gestión 24.5 Control de Calidad 24.6 Presentación de informes y medición 24.7 Gestión del Riesgo 24.8 Gestión de la Configuración 25. Anexos 2

Plan de Desarrollo de Software

1. Introducción[La introducción del Plan de desarrollo de software ofrece una visión general de todo el documento. Incluye el propósito, alcance, definiciones, acrónimos, abreviaturas, referencias, y visión general de este Plan de Desarrollo de Software.]

1.1 Finalidad[Especifique el propósito de este Plan de desarrollo de software. El texto siguiente se proporciona como un ejemplo. ]El objetivo del Plan de desarrollo de software es recopilar toda la información necesaria para controlar el proyecto. En él se describe el enfoque en el desarrollo del software y es el plan de alto nivel generados y utilizados por los administradores para dirigir el esfuerzo de desarrollo.Las siguientes personas utilizar el Software Plan de Desarrollo:• El director del proyecto lo utiliza para planificar las necesidades de programación del proyecto y de recursos, y para seguir el progreso con el calendario.• Los miembros del equipo del proyecto se utilizan para comprender lo que tienen que hacer, cuándo deben hacerlo, y qué otras actividades que dependen.1.2 Alcance[Una breve descripción del ámbito de aplicación de este Plan de desarrollo de software, ¿qué proyecto (s) que está asociado y cualquier otra cosa que se vea afectada o influenciada por este documento. El texto siguiente se proporciona como un ejemplo.]Este Plan de Desarrollo de Software describe el plan general para ser utilizado por el proyecto <nombreDeProyecto>, incluido el despliegue del producto. Los detalles de las iteraciones individuales se describen en los planes de iteración.Los planes como se indica en este documento se basan en los requisitos del producto tal como se define en el documento de Visión.1.3 Definiciones, acrónimos y abreviaturas[Esta sección provee las definiciones de los términos, acrónimos y abreviaturas requeridas para interpretar apropiadamente el desarrollo de software de Plan. Esta información puede ser proporcionada por referencia al glosario del proyecto.]Véase el Glosario del proyecto.1.4 Referencias[Esta sección provee una lista completa de todos los documentos referenciados en cualquier lugar en el Plan de desarrollo de software. Identifique cada documento por su título, número de informe, si procede, fecha, y la organización que lo publica.

Especificar las fuentes de donde las referencias se pueden obtener. Esta información puede ser proporcionada por referencia a un apéndice oa otro documento.Para el Plan de Desarrollo de Software, la lista de artefactos referencia incluye:• Planes de Iteración• Caso de Desarrollo• Visión• Glosario• Cualquier otros planes de apoyo o de documentación.

1.5 Información general[Esta sección describe lo que el resto del Plan de desarrollo de software contiene y explica cómo se organiza el documento. El texto siguiente se proporciona como un ejemplo.]Este Plan de desarrollo de software contiene la siguiente información:Descripción del proyecto - proporciona una descripción del propósito del proyecto, el alcance y objetivos. También define que los productos que el proyecto se espera dar a luz.Organización del Proyecto - describe la estructura organizativa del equipo del proyecto.La gestión del proceso - explica el costo estimado y el calendario, define las fases y los hitos principales del proyecto, y describe cómo el proyecto será objeto de seguimiento.Planes y directrices aplicables - proporcionar una visión general del proceso de desarrollo de software, incluyendo métodos, herramientas y técnicas a seguir.2. Descripción del proyecto2.1 Proyecto Propósito, alcance y objetivos[Una breve descripción de la finalidad y los objetivos de este proyecto y una breve descripción de lo que las prestaciones del proyecto se espera dar a luz.]2.2 Supuestos y limitaciones[La lista de suposiciones que este plan se basa y las limitaciones eventuales, por ejemplo. personal, equipos, calendario, que se aplican al proyecto.]2.3 Entregables del proyecto[La lista de los artefactos que se creará durante el proyecto, incluyendo fechas de entrega de destino. El texto siguiente se proporciona como un ejemplo.]Entregables para cada fase del proyecto se identifican en el caso de Desarrollo. Entregables se entregan al final de la iteración, tal como se especifica en la sección 4.2.4 del proyecto Lista.2.4 Evolución del Plan de Desarrollo de Software[Una tabla de versiones propuestas del Plan de Desarrollo de Software, así como los criterios para la revisión no programada y la reedición de este plan. El texto siguiente se

proporciona como un ejemplo.]El Plan de Desarrollo de Software se revisará antes del inicio de cada fase de la iteración.3. Organización del Proyecto3.1 Estructura Organizacional[Describir la estructura organizativa del equipo del proyecto, incluida la gestión y las autoridades de otras revisiones.]3.2 Interfaces externos[Describa cómo el proyecto interactúa con grupos externos. Para cada grupo externo, identificar los nombres de los contactos internos y externos. Esto debe incluir las responsabilidades relacionadas con el despliegue y la aceptación del producto.]3.3 Funciones y responsabilidades[Identificar el proyecto de organización de unidades que se encargarán de cada una de las disciplinas, los detalles de flujo de trabajo y procesos de apoyo. El texto siguiente se proporciona como un ejemplo.]Persona Proceso Unificado de papel de la educaciónCualquier persona en el proyecto puede realizar cualquier actividad de funciones.

4. La gestión de procesos4.1 Estimaciones del Proyecto[Indicar el costo estimado y el calendario para el proyecto, así como la base para esas estimaciones, y los puntos y las circunstancias en el proyecto cuando se re-estimación se producirá.]4.2 Plan del Proyecto[Esta sección contiene el calendario y los recursos para el proyecto.]4.2.1 Fase del Plan[Incluya lo siguiente:• Un diagrama de Gantt que muestra la distribución del tiempo de las fases del proyecto (no necesariamente detallada al nivel de actividad, este tipo de Diagrama de Gantt proporciona junto con la iteración mismos planes; Proporcionar una visión general de la línea de tiempo del proyecto con las piedras grandes millas]• Identificar los principales hitos con sus criterios de rendimientoDefinir los puntos de liberación importante y demos.][Si está disponible, consulte con los documentos de Plan de iteración para obtener más detalles]4.2.2 Objetivos de iteración[Lista brevemente los objetivos a alcanzar para cada una de las iteraciones y consultar

con los documentos de Plan de iteración para obtener más detalles.]4.2.3 Emisiones[Una breve descripción de cada versión del software y si es demo, beta, etc.]4.2.4 Proyecto de Programa[Diagramas o cuadros que muestran las fechas previstas para la realización de iteraciones y fases, puntos de liberación, demostraciones y otros hitos.]4.2.5 Proyecto de Recursos [Indique el número y tipo de personal necesario aquí, incluyendo alguna habilidad especial o experiencia, prevista por la fase de proyecto o iteración.Haga una lista de especiales de capacitación miembros del equipo del proyecto requerirá, con plazos de cuando esta formación debe ser completada.]4.3 Seguimiento de Proyectos y Control [La siguiente es una lista de temas a considerar:• Gestión de Requisitos: Especificar los mecanismos de información y control que se recopila y se utiliza para medir, informar y controlar los cambios a los requisitos del producto.• Control de calidad: Describir el calendario y los métodos que se utilizan para controlar la calidad de los entregables del proyecto y cómo tomar medidas correctivas cuando sea necesario. Las técnicas incluyen, métricas, criterios y procedimientos utilizados para la evaluación-se incluirá tutoriales, inspecciones y revisiones. Tenga en cuenta que esto es en adición al plan de pruebas, que no se incluye en el Plan de desarrollo de software.• Presentación de informes y medición: Describir los informes que se generen. Especificar qué indicadores se deben recoger y por qué. O si la hay, se refieren a las mediciones del proyecto y el documento del proyecto mediciones• Gestión de Riesgos: Describir el enfoque que se utilizará para identificar, analizar, priorizar, monitorear y mitigar los riesgos. Si está disponible, consulte el documento de la lista de riesgos.• Gestión de la Configuración: Describir el proceso por el cual los problemas y los cambios se presenten, revisado y dispositioned. Describir la forma de los artefactos del proyecto o de productos son ser nombrado, marcados y numerados, incluyendo el software del sistema, planos, modelos, componentes, software de prueba, los resultados y de datos, ejecutables, etc. Descripción de las políticas de retención, y el desastre de respaldo, y los planes de recuperación. O si está disponible, consultar el documento de configuración Plan de ManejoEl texto que sigue se proporciona como un ejemplo.]4.4 Gestión de RequisitosLos requisitos para este sistema son capturados en el documento Visión. Los cambios

solicitados a los requisitos son capturados en solicitudes de cambio, y están aprobados como parte del proceso de Gestión de la Configuración.

4.5 Control de CalidadLos defectos serán registrados y rastreados como solicitudes de cambio, y las métricas defecto se reunieron ser (ver informes y medición más abajo).Todos los resultados están obligados a pasar por el proceso de revisión de su caso, como se describe en el caso de Desarrollo. La revisión es necesario para asegurar que cada entrega es de calidad aceptable, con directrices y listas de verificación.Los defectos encontrados durante la revisión que no se corrigen antes de lanzar para la integración debe ser capturado como solicitudes de cambio para que no se olvidan.

4.6 Presentación de informes y mediciónEstimaciones actualizadas de lo previsto, y los informes de métricas resumen, se generará al final de cada iteración.El conjunto mínimo de mediciones, como se describe en las Directrices RUP: Metrics se reunirán una vez por semana. Estos incluyen:Valor acumulado de las tareas completadas. Esto se utiliza para volver a calcular el calendario y el presupuesto para el resto del proyecto, y / o para determinar la necesidad de cambios en el alcance.Total de defectos abiertos y cerrados - se muestra como un gráfico de tendencia. Esto se utiliza para ayudar a estimar el esfuerzo restante para corregir defectos.Aceptación de los casos de prueba que pasa - se muestra como un gráfico de tendencia. Se utiliza para demostrar el progreso a los interesados.

Consulte el documento de proyecto mediciones (AAA-BBB-XYdoc) para obtener información detallada.

4.7 Gestión de RiesgosLos riesgos serán identificados en la Fase Inicial siguiendo los pasos señalados en el RUP de la Pequeña actividad Proyectos "Identificar y evaluar los riesgos". El riesgo del proyecto es evaluado por lo menos una vez por iteración y documentado en esta tabla.

Consulte la lista de riesgo de Documento (CCC-DDD-XYdoc) para obtener información detallada.

4.8 Gestión de la Configuraciónherramientas apropiadas serán seleccionados que proporcionan una base de datos de

solicitudes de cambio y un depósito controlado de versiones de los artefactos del proyecto.Todos los archivos de código fuente, scripts de prueba, y los datos se incluyen en las líneas de base. Documentación relacionada con el código fuente también se incluye en la línea de base, tales como documentación de diseño. Todos los artefactos de entrega al cliente están incluidos en la línea de base final de la iteración, incluyendo los ejecutables.Las solicitudes de cambio son revisadas y aprobadas por un miembro del proyecto, el Gerente de Control de Cambios papel.

Consulte el Plan de Gestión de la Configuración (EEE-FFF-XYdoc) para obtener información detallada.

5. Anexosmaterial [adicional de utilidad para el lector del Plan de desarrollo de software. De referencia o incluir todas las normas técnicas del proyecto y los planes que se aplican a este proyecto. Esto normalmente incluye las directrices de programación, directrices de diseño, y otras directrices proceso. El texto que sigue se proporciona como un ejemplo.]El proyecto seguirá el proceso UPEDU.Otros planes de proceso aplicable se enumeran en la sección de referencias, incluyendo directrices de programación.

Factores de Riesgo

Historial de revisionesVersión Fecha Descripción Autor<dd/mmm/yy> <x.x> <details> <name>

Tabla de contenidos1. Introducción 21.1 Objetivo 21.2 Alcance 21.3 Definiciones, acrónimos y abreviaturas 21.4 Referencias 2

1.5 Resumen 22. Riesgos 22.1 <Risk Identifier-a descriptivo nombre o <número 22.1.1 Magnitud de riesgo o Ranking 22.1.2 Descripción 22.1.3 Impactos 22.1.4 Indicadores de dos2.1.5 Estrategia de Mitigación 22.1.6 Plan de Contingencia de dos2.2 Riesgo <NEXT Identifier-a descriptivo nombre o <número 2 Factores de Riesgo

1. Introducción[La introducción de la lista de riesgos proporciona una visión general de todo el documento. Incluye el propósito, alcance, definiciones, acrónimos, abreviaturas, referencias, y visión general de esta lista de riesgos.]1.1 Finalidad[Especifique el propósito de esta lista de riesgos.]1.2 Alcance[: ¿Qué proyecto (s) que está asociado y cualquier otra cosa que se vea afectada o influenciada por este documento una breve descripción del alcance de esta lista de riesgos.]1.3 Definiciones, acrónimos y abreviaturas[Esta sección provee las definiciones de los términos, acrónimos y abreviaturas requeridas para interpretar apropiadamente la lista de riesgos. Esta información puede ser proporcionada por referencia al glosario del proyecto.]1.4 Referencias[Esta sección provee una lista completa de todos los documentos referenciados en cualquier lugar en la lista de riesgo. Identifique cada documento por su título, número de informe, si procede, fecha, y la organización que lo publica. Especificar las fuentes de donde las referencias se pueden obtener. Esta información puede ser proporcionada por referencia a un apéndice oa otro documento.]1.5 Información general[Esta sección describe lo que el resto de la lista de riesgos contiene y explica cómo se organiza el documento.]2. Riesgos2.1 <Risk Identifier-a descriptivo nombre o <número

2.1.1 Magnitud de riesgo o de Tráfico[Un indicador de la magnitud del riesgo que pueden ser destinados a mejorar el posicionamiento de los riesgos de más a menos perjudiciales para el proyecto.]2.1.2 Descripción[Una breve descripción del riesgo.]2.1.3 Impactos[Lista de los impactos sobre el proyecto o producto.]2.1.4 Indicadores[Describir la forma de vigilar y detectar que el riesgo se ha producido o está a punto de ocurrir. Incluya tales cosas como métricas y umbrales, resultados de las pruebas, eventos específicos, etc.]2.1.5 Estrategia de Mitigación[Describir lo que se hace actualmente en el proyecto para reducir el impacto del riesgo.]2.1.6 Plan de Contingencia[Describir lo que el curso de acción será si el riesgo se materialice. Solución alternativa, la reducción en la funcionalidad, y así sucesivamente]2.2 Riesgo <NEXT Identifiera descriptivo nombre o <número[...]

[También puede utilizar el siguiente formato de tabla para incluir los riesgos]

<Risk ID> - Descriptive NameMagnitude

DescriptionImpacts

Indicator

Mitigation Strategy / Contingency Plan