1. Material de Estudio para la Evaluación
Prototipo: Los prototipos son una visión preliminar del sistema futuro que se implantara. La elaboración
de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de
información específica a cerca de los requerimientos de la información del usuario.
El proceso de desarrollo y empleo de prototipos tiene las siguientes características:
1. El prototipo es una aplicación que funciona
2. Los prototipos se crean con rapidez
3. Los prototipos evolucionan a través de un proceso iterativo
4. Los prototipos tienen un costo bajo de desarrollo
Clases de Prototipos
 Prototipo corregido: La primera clase de elaboración de prototipos tiene que ver con la construcción de
un sistema que funciona pero se corrige simultáneamente. En la ingeniería a este enfoque se le llama
elaboración de una tabla experimental: la creación, en una tableta de pruebas, de un modelo funcional de
un circuito integrado (que en la vida real sería microscópico). Un ejemplo en sistemas de información es
un modelo funcional que tiene todas las características necesarias pero es ineficiente. En este ejemplo de
elaboración de prototipos, los usuarios pueden interactuar con el sistema, acostumbrándose a la interfaz y
los tipos de salidas disponibles. Sin embargo, la recuperación y almacenamiento de información podrían
ser ineficientes, debido a que los programas se escribieron rápidamente con el objetivo de ser funcionales
en lugar de eficaces.
 Prototipo no funcional: El segundo tipo de prototipo es un modelo no funcional a escala configurado
para probar ciertos aspectos del diseño. Un ejemplo de este enfoque es un modelo a escala completa de
un automóvil que se usa para pruebas en un túnel de viento. El tamaño y forma del automóvil son
precisos, pero el automóvil no es funcional. En este caso sólo se incluyen las características del automóvil
que son fundamentales para la prueba en el túnel de viento.
Un modelo no funcional a escala de un sistema de información podría producirse cuando la codificación
requerida por las aplicaciones es demasiado extensa para incluirse en el prototipo pero cuando se puede
conseguir una idea útil del sistema a través de la elaboración de un prototipo de la entrada y la salida. En este
caso, el procesamiento, debido al excesivo costo y el tiempo requerido, no podría incluirse en el prototipo.
Sin embargo, aún se podrían tomar algunas decisiones sobre la utilidad del sistema con base en la entrada y la
salida incluidas en el prototipo.
 Primer prototipo de una serie: Un tercer tipo de prototipos involucra la creación de un primer modelo a
escala completa de un sistema, con frecuencia llamado piloto. Un ejemplo es la elaboración de un
prototipo del primer avión de una serie. El prototipo es completamente funcional y es una materialización
de lo que el diseñador espera será una serie de aviones con características idénticas. Este tipo de
elaboración de prototipos es útil cuando se planean muchas instalaciones del mismo sistema de
información. El modelo funcional a escala completa permite a los usuarios experimentar la interacción
real con el nuevo sistema, pero minimiza el costo de superar cualquier problema que se presente. La
creación de un modelo funcional es uno de los tipos de elaboración de prototipos que se hace con RAD.
Por ejemplo, cuando una cadena de tiendas de abarrotes minoristas considera el uso del EDI (intercambio
electrónico de datos) para comprobar los envíos de los proveedores a varias tiendas, se podría instalar un
modelo a escala completa en una tienda para resolver cualquier problema antes de que el sistema se
implemente en todas las demás tiendas. Otro ejemplo es el de las instalaciones bancarias para la transferencia
electrónica de fondos. Primero, se instala un prototipo a escala completa en una o dos sucursales, y si tiene
éxito, se instalan los duplicados en todas las sucursales con base en los patrones de uso de los clientes y en
otros factores importantes.

2.  Prototipo de características seleccionadas: Una cuarta concepción de la elaboración de prototipos
involucra la creación de un modelo funcional que incluya algunas, pero no todas, de las características
que tendrá el sistema final. Una analogía sería que un nuevo centro comercial minorista abriera antes de
que se terminara la construcción de todas las tiendas. Cuando se elaboran prototipos de los sistemas de
información de esta manera, se incluyen algunas de las características principales, aunque no todas. Por
ejemplo, en la pantalla podría aparecer un menú del sistema que muestre seis características: agregar un
registro, actualizar un registro, eliminar un registro, buscar una palabra clave en un registro, listar un
registro o examinar un registro. Sin embargo, en el prototipo del sistema tal vez sólo estén disponibles
tres de las seis características, de manera que el usuario podría agregar un registro (característica 1),
eliminar un registro (característica 3) y listar un registro (característica 5).
Cuando se recurre a este tipo de elaboración de prototipos, el sistema se completa por módulos de forma
que si las características que se incluyen en los prototipos se evalúan exitosamente, se puedan incorporar en
el sistema final más grande sin necesidad de realizar demasiado esfuerzo en la interacción. Los prototipos
hechos de esta forma son parte del sistema real. No son sólo un modelo como en el caso de los prototipos no
funcionales que se describieron antes.
- ¿Qué es R.A.D? El desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application
development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980.
El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE
(Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a
englobar también la usabilidad, utilidad y la rapidez de ejecución.
Entre las principales características del RAD tenemos:
a. Equipos Híbridos: Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y
usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos. Los
desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.
b. Herramientas Especializadas
• Desarrollo "visual"
• Creación de prototipos falsos (simulación pura)
• Creación de prototipos funcionales
• Múltiples lenguajes
• Calendario grupal
• Herramientas colaborativas y de trabajo en equipo
• Componentes reusables
• Interfaces estándares (API)
• Control de versiones
c. "Timeboxing": Las funciones secundarias son eliminadas como sea necesario para cumplir con el
calendario.
d. Prototipos Iterativos y Evolucionarios
• Reunión JAD (Joint Application Development): Se reúnen los usuarios finales y los
desarrolladores. Lluvia de ideas para obtener un borrador inicial de los requisitos.

3. • Iterar hasta acabar:
o Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.
o Los diseñadores revisan el prototipo.
o Los clientes prueban el prototipo, depuran los requisitos.
o Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar
solicitudes de cambios.
o Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es
necesario para cumplir el calendario.
• El Facilitador
Mantiene al grupo enfocado:
• Tiene claras las metas sobre la información que se necesita recabar.
• Prepara una agenda de asuntos antes de la reunión.
• Asegura que la discusión adecuada cubra cada asunto.
• Asegura que todos participen.
• Escribe un reporte al final de la reunión.
• Restricciones importantes
• El "ajuste a un propósito de negocios" tiene que ser el criterio de aceptación de los entregables.
• Todas las áreas que pueden afectar los requisitos debe estar involucradas a lo largo del proceso.
• Clientes, desarrolladores y gerencia deben aceptar entregables informales:
• Prototipos en papel en lugar de sistemas a gran escala.
• Notas de las reuniones con usuarios en lugar de documentos de requisitos formales.
• Notas de las reuniones de los diseñadores en lugar de documentos de diseño formales.
• Principio: crear el mínimo de documentación necesaria para facilitar el desarrollo futuro y el
mantenimiento.
Notas:
o Cada iteración dura entre un día y tres semanas.
o Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.
Esta metodología consta de 4 etapas a saber:
1) Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de
los procesos de la compañía determinen cuales serán las funciones del sistema. Debe darse una discusión
estructurada sobre los problemas de la compañía que necesitan solución.
2) Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al
sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la
informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se

4. completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data.
3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los
usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una
serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.
4) Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del
viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
Definición: La programación extrema es un enfoque de la ingeniería de softwar formulado por Kent Beck,
autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el
más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema
se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad
que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son
un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y
más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en
controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de
las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y
aplicarlo de manera dinámica durante el ciclo de vida del software.
Roles de la Programación Extrema (XP).
Según la propuesta de Beck los roles que nos podemos encontrar son los siguientes:
• Programador: El programador escribe las pruebas unitarias y produce el código del sistema.
• Cliente: Escribe las historias de los usuarios y las pruebas funcionales para validar su
implementación. El cliente da una gran prioridad a las historias de usuarios y decide cual implementar
en cada iteración centrandose en aportar mayor valor al negocio.
• Encargado de Pruebas: Ayuda al cliente a escribir las pruebas funcionales. Se encarga de ejecutar las
pruebas con regularidad, difunde los resultados obtenidos al equipo y es el responsable de las
herramientas que dan soporte a las pruebas.
• Encargado de Seguimiento: Es el que proporciona la realimentación al equipo. Realiza el seguimiento
del proceso de cada iteración y verifica el grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado en ello para la mejora de futuras estimaciones.
• Entrenador: Es el responsable del proceso global. Se encarga de proveer guias al equipo de forma que
se apliquen las practicas XP y se vaya siguiendo el proceso correctamente.
• Consultor: Es un miembro externo del equipo con un conocimiento especifico en algún tema que es
necesario para el proyecto, en el que surjan problemas.
• Gestor: Es el vinculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente
creando las condiciones adecuadas. Su labor esencial es la de coordinación

5. Procesos de XP: El Cliente pone a disposición del equipo de Programacion Extrema a un representante del
Cliente en la modalidad de tiempo completo (XpOnSiteCustomer). Su función es la de escribir
comprobaciones de aceptación a nivel de sistema, responder preguntas del equipo y proveer las prioridades.
La presencia del XpOnSiteCustomer determina la velocidad del equipo de trabajo. Durante el
desarrollo del software, aparecen muchas dudas y preguntas cuya decisión puede darse en términos de
minutos, horas o días, de acuerdo al mecanismo que se use para responderlas. En Programacion Extrema se
cuenta con el Cliente dentro del equipo, y por lo tanto las decisiones son todo lo rápidas que se puede desear.
«Si el cliente no le proporciona un miembro destacado de tiempo completo, retírese del proyecto. El
cliente no es serio.» [_The professional Service Firm 50_, pág. 106, citado en XP Explored, William C.
Wake]
Hay dos niveles de comprobaciones del software en un proyecto de ProgramacionExtrema:
1. Comprobaciones de aceptación de la entrega (escritas por el XpOnSiteCustomer).
2. Comprobaciones a nivel de unidad (escritas por el XpProgramador).
El Cliente construye comprobaciones para cada historia que solicita. El equipo de Programacion
Extrema mide el grado de avance verificando cuántas de estas comprobaciones satisface el sistema. Se debe
lograr a toda costa que estas comprobaciones se puedan llevar a cabo de manera automatizada.
La planificación de las entregas (desde semanas hasta meses) y de las iteraciones de trabajo (una a
tres semanas) se denomina el XpPlanningGame.
En el juego de planificación de entrega la meta es definir el conjunto de características que entrarán
en la siguiente entrega. El Cliente escribe historias de usuario (XpUserStories), el XpProgramador las estima
y el Cliente planifica la entrega en general.
El juego de planificación de la iteración es similar. El Cliente elige las XpUserStories para la iteración
y los xpProgramadores estiman y aceptan las XpProgrammingTask
Programación Orientada a Objeto: Es un paradigma de programación que usa objetos y sus interacciones,
para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia,
abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años
1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.
Características de la POO
 Objetos: Existen muchas definiciones que se le ha dado al Objeto. Primero empecemos entendiendo que
es un objeto del mundo real. Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor.

6. Digamos que para leer este artículo lo hacemos a través del monitor y una computadora, ambos son
objetos, al igual que nuestro teléfono celular, un árbol o un automóvil.
Analicemos un poco más a un objeto del mundo real, como la computadora. No necesitamos ser
expertos en hardware para saber que una computadora está compuesta internamente por varios componentes:
la tarjeta madre, el chip del procesador, un disco duro, una tarjeta de video, y otras partes más. El trabajo en
conjunto de todos estos componentes hace operar a una computadora.
Internamente, cada uno de estos componentes puede ser sumamente complicado y puede ser fabricado
por diversas compañías con diversos métodos de diseño. Pero nosotros no necesitamos saber cómo trabajan
cada uno de estos componentes, como saber que hace cada uno de los chips de la tarjeta madre, o cómo
funciona internamente el procesador. Cada componente es una unidad autónoma, y todo lo que necesitamos
saber de adentro es cómo interactúan entre sí los componentes, saber por ejemplo si el procesador y las
memorias son compatibles con la tarjeta madre, o conocer donde se coloca la tarjeta de video. Cuando
conocemos como interaccionan los componentes entre sí, podremos armar fácilmente una computadora.
¿Qué tiene que ver esto con la programación? La programación orientada a objetos trabaja de esta
manera. Todo el programa está construido en base a diferentes componentes (Objetos), cada uno tiene un rol
específico en el programa y todos los componentes pueden comunicarse entre ellos de formas predefinidas.
Todo objeto del mundo real tiene 2 componentes: características y comportamiento.
Por ejemplo, los automóviles tienen características (marca, modelo, color, velocidad máxima, etc.) y
comportamiento (frenar, acelerar, retroceder, llenar combustible, cambiar llantas, etc.).
Los Objetos de Software, al igual que los objetos del mundo real, también tienen características y
comportamientos. Un objeto de software mantiene sus características en una o más "variables", e implementa
su comportamiento con "métodos". Un método es una función o subrutina asociada a un objeto.
Para redondear estas ideas, imaginemos que tenemos estacionado en nuestra cochera un Ford Focus
color azul que corre hasta 260 km/h. Si pasamos ese objeto del mundo real al mundo del software, tendremos
un objeto Automóvil con sus características predeterminadas:
5. Marca = Ford
6. Modelo = Focus
7. Color = Azul
8. Velocidad Máxima = 260 km/h
Cuando a las características del objeto le ponemos valores decimos que el objeto tiene estados. Las
variables almacenan los estados de un objeto en un determinado momento.

7. Definición teórica: Un objeto es una unidad de código compuesto de variables y métodos
relacionados.
 Clases.
En el mundo real, normalmente tenemos muchos objetos del mismo tipo. Por ejemplo, nuestro
teléfono celular es sólo uno de los miles que hay en el mundo. Si hablamos en términos de la programación
orientada a objetos, podemos decir que nuestro objeto celular es una instancia de una clase conocida como
"celular". Los celulares tienen características (marca, modelo, sistema operativo, pantalla, teclado, etc.) y
comportamientos (hacer y recibir llamadas, enviar mensajes multimedia, transmisión de datos, etc.).
Cuando se fabrican los celulares, los fabricantes aprovechan el hecho de que los celulares comparten
esas características comunes y construyen modelos o plantillas comunes, para que a partir de esas se puedan
crear muchos equipos celulares del mismo modelo. A ese modelo o plantilla le llamamos CLASE, y a los
equipos que sacamos a partir de ella la llamamos OBJETOS.
Esto mismo se aplica a los objetos de software, se puede tener muchos objetos del mismo tipo y
mismas características.
Definición teórica: La clase es un modelo o prototipo que define las variables y métodos comunes a
todos los objetos de cierta clase. También se puede decir que una clase es una plantilla genérica para un
conjunto de objetos de similares características.
Por otro lado, una instancia de una clase es otra forma de llamar a un objeto. En realidad no existe
diferencia entre un objeto y una instancia. Sólo que el objeto es un término más general, pero los objetos y
las instancias son ambas representación de una clase.
Definición Teórica: Una instancia es un objeto de una clase en particular.

8.  Herencia
La herencia es uno de los conceptos más cruciales en la POO. La herencia básicamente consiste en que
una clase puede heredar sus variables y métodos a varias subclases (la clase que hereda es llamada superclase
o clase padre). Esto significa que una subclase, aparte de los atributos y métodos propios, tiene incorporados
los atributos y métodos heredados de la superclase. De esta manera se crea una jerarquía de herencia.
Por ejemplo, imaginemos que estamos haciendo el análisis de un Sistema para una tienda que vende y
repara equipos celulares.
En el gráfico vemos 2 Clases más que posiblemente necesitemos para crear nuestro Sistema. Esas 2
Clases nuevas se construirán a partir de la Clase Celular existente. De esa forma utilizamos el
comportamiento de la SuperClase.
En general, podemos tener una gran jerarquía de Clases tal y como vemos en el siguiente gráfico:
 Abstracción: La abstracción consiste en captar las características esenciales de un objeto, así como su
comportamiento. Por ejemplo, volvamos al ejemplo de los automóviles, ¿Qué características podemos
abstraer de los automóviles? O lo que es lo mismo ¿Qué características semejantes tienen todos los
automóviles? Todos tendrán una marca, un modelo, número de chasis, peso, llantas, puertas, ventanas,
etc. Y en cuanto a su comportamiento todos los automóviles podrán acelerar, frenar, retroceder, etc.
En los lenguajes de programación orientada a objetos, el concepto de Clase es la representación y el
mecanismo por el cual se gestionan las abstracciones.
Por ejemplo, en Java tenemos:

9. public class Automovil {
// variables
// métodos
}
 Encapsulamiento: El encapsulamiento consiste en unir en la Clase las características y
comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los
lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la
abstracción y el ocultamiento que veremos a continuación.
La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las
Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es
conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.
 Ocultamiento: Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y
exponer sólo los detalles que sean necesarios para el resto del sistema.
El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habrá cierto
comportamiento privado de la Clase que no podrá ser accedido por otras Clases. Y controlar porque daremos
ciertos mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dónde se validarán
que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public,
private y protected delante de las variables y métodos.