guia 1 software1

1. ESCUELA POLITECNICA DEL EJÉRCITO
ESPE
CARRERA
TECNOLOGÍA EN COMPUTACIÓN
MATERIA
SOFTWARE II
SEMESTRE MARZ 2011 – SEP 2011

2. 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
•Comparten una estructura en común
SEMEJANZAS •Comparten atributos y operaciones en las clases

3. • •Especialización
•Cada subclase hereda
DIFERENCIAS 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

4. 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.

5. •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

6. - 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.

7. 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 – Worker
Define la conducta y las responsabilidades de un individuo, o un conjunto de
individuos que trabajan en grupo.
Actividad – Activy
Una 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 proyecto
Los artefactos son usados por los Workers como entradas para realizar una actividad,
y como salidas de resultados.

8. 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.

9. ACTIVIDAD DE APRENDIZAJE 1.3
Plan de Desarrollo de Software
Historial de revisiones
Versión Fecha Descripción Autor
<dd/mmm/yy> <x.x> <details> <name>
Tabla de contenidos
1. Introducción 2
1.1 Objetivo 2
1.2 Alcance 2
1.3 Definiciones, acrónimos y abreviaturas 2
1.4 Referencias 2
1.5 Resumen 2
2. Descripción del proyecto 2
2.1 Proyecto Propósito, alcance y objetivos 2
2.2 Supuestos y limitaciones 2
2.3 Entregables del Proyecto 2
2.4 Evolución del Plan de Desarrollo de Software 2
3. Organización del Proyecto 2
3.1 Estructura de organización 2
3.2 Interfaces externa 2
3.3 Funciones y responsabilidades 2
4. Gestión de Procesos 2
4.1 Estimaciones del Proyecto 2
4.2 Plan del Proyecto 2
4.3 Seguimiento y Control 2
4.4 Requerimientos de Gestión 2
4.5 Control de Calidad 2
4.6 Presentación de informes y medición 2
4.7 Gestión del Riesgo 2
4.8 Gestión de la Configuración 2
5. Anexos 2

10. 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.

11. 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 proyecto
2.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

12. 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 Proyecto
3.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ón
Cualquier persona en el proyecto puede realizar cualquier actividad de funciones.
4. La gestión de procesos
4.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 rendimiento
Definir 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

13. 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 Manejo
El texto que sigue se proporciona como un ejemplo.]
4.4 Gestión de Requisitos
Los requisitos para este sistema son capturados en el documento Visión. Los cambios

14. 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 Calidad
Los 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ón
Estimaciones 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 Riesgos
Los 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ón
herramientas apropiadas serán seleccionados que proporcionan una base de datos de

15. 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. Anexos
material [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 revisiones
Versión Fecha Descripción Autor
<dd/mmm/yy> <x.x> <details> <name>
Tabla de contenidos
1. Introducción 2
1.1 Objetivo 2
1.2 Alcance 2
1.3 Definiciones, acrónimos y abreviaturas 2
1.4 Referencias 2

16. 1.5 Resumen 2
2. Riesgos 2
2.1 <Risk Identifier-a descriptivo nombre o <número 2
2.1.1 Magnitud de riesgo o Ranking 2
2.1.2 Descripción 2
2.1.3 Impactos 2
2.1.4 Indicadores de dos
2.1.5 Estrategia de Mitigación 2
2.1.6 Plan de Contingencia de dos
2.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. Riesgos
2.1 <Risk Identifier-a descriptivo nombre o <número

17. 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 Name
Magnit Impac Indica Mitigation Strategy /
Description
ude ts tor Contingency Plan