Unidad_2 _Requerimientos_para_el_analisis_del_diseno_orientado_a_objetos

Vista previa del material en texto

Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 1 
 
 
 
Ingeniería en Desarrollo de Software 
Cuatrimestre 04 
 
 
 
Programa de la asignatura: 
Análisis y diseño orientado a objetos 
 
 
 
Unidad 2. Requerimientos para el análisis del diseño 
orientado a objetos 
 
 
 
Clave: 160920413 / 150920413 
 
 
 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 2 
Índice 
 
Unidad 2. Requerimientos para el análisis del diseño orientado a objetos ......................... 3 
Presentación de la unidad ........................................................................................................... 3 
Propósito ........................................................................................................................................ 4 
Competencia específica .............................................................................................................. 4 
2.1. Levantamiento de requerimientos ...................................................................................... 5 
2.1.1. Introducción a los requerimientos ................................................................................... 5 
2.1.2. Actividades para el levantamiento de requerimientos ................................................. 6 
Actividad 1. Análisis y diseño en un programa orientado a Objetos .................................... 7 
2.2. Documentación para levantamientos y especificaciones ............................................... 7 
2.2.1. Documentación .................................................................................................................. 8 
2.2.2. Especificaciones ................................................................................................................ 9 
2.3. Estándares de especificación ............................................................................................. 9 
2.3.1. Fases de la estandarización .......................................................................................... 10 
2.3.2. Análisis de restricciones ................................................................................................. 11 
Actividad 2. Requerimientos para diseñar un programa ...................................................... 11 
2.4. Modelos del desarrollo del software ................................................................................ 12 
2.4.1. Ágiles ................................................................................................................................. 13 
2.4.2. Predictivos ........................................................................................................................ 14 
Actividad 3. Listado de características de los modelos ágiles y predictivos ..................... 15 
Autoevaluación ........................................................................................................................... 16 
Evidencia de aprendizaje. Requerimientos para diseñar un programa con O O ............. 16 
Cierre de la unidad ..................................................................................................................... 17 
Fuentes de consulta ................................................................................................................... 17 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 3 
 
Unidad 2. Requerimientos para el análisis del diseño orientado a 
objetos 
 
Presentación de la unidad 
 
El trabajo de ir detallando la definición de un problema en forma de requisitos se realiza 
de manera repetitiva, progresiva, incremental. Por un lado, supone la planificación, 
realización y evaluación de las entrevistas con los clientes y usuarios finales del sistema, 
que son los portadores de la información necesaria para conocer el problema y definir el 
proyecto. Por otro lado, supone la identificación y descomposición reiterada (hasta el nivel 
de detalle que en cada caso sea necesario) de los problemas y necesidades expresados 
por el cliente y los usuarios, para así ir redactando un conjunto de requisitos formales. 
Principalmente, se utiliza la siguiente técnica: 
 
Entrevista. Es una conversación dirigida por objetivos entre un entrevistador, miembro del 
equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final. 
 
Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo 
siempre a las opiniones del entrevistado. Él es nuestra fuente de información principal y 
de la relación que establezcamos depende la facilidad o dificultad para conocer sus 
necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos; 
la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su 
futuro trabajo, expertos reticentes a compartir conocimientos. 
 
Durante la realización de una entrevista lo habitual es la toma de notas, para redactar más 
tarde el informe de evaluación de la misma. Para la grabación en audio o en video es 
preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si 
esto va a interferir en la entrevista, haciéndole sentir incómodo. Pese a su costo, se va 
generalizando el uso de videoconferencias para la realización de entrevistas remotas, con 
la consiguiente comodidad para ambas partes. 
 
Toda entrevista requiere de una preparación previa: establecer los objetivos, seleccionar 
al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir 
documentación, elegir el tipo de preguntas para finalmente utilizar la información recabada 
para lograr los fines. 
 
Según el tipo de preguntas, existen diferentes clases de entrevista: 
 
 Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la 
entrevista, hacia preguntas abiertas. 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 4 
 Deductiva: al principio se hacen preguntas abiertas y se va acotando con 
preguntas cada vez más cerradas. 
 Mixta: se utilizan ambos tipos de preguntas indistintamente 
 
Algunos ejemplos de Preguntas Abiertas son los siguientes: 
 
 ¿Qué le parece nuestra propuesta frente a otras que ha recibido? 
 ¿Qué servicios le gustaría recibir de su sistema? 
 
Para poder formular preguntas “cerradas” es necesario anticipar las posibles alternativas 
de respuesta. Algunos ejemplos de preguntas cerradas: 
 
 ¿Firmamos el contrato? 
 ¿Le gusta nuestro producto? 
 
 
Propósito 
 
La especificación de requisitos es la primera fase de todo ciclo de vida o metodología de 
desarrollo de un proyecto informático. Dos son sus objetivos principales: 
 
 Identificar las necesidades del cliente, es decir, conocer y definir el problema. 
 Realizar un estudio de viabilidad económico, técnico y legal, a partir del cual se 
pueda decidir sobre la continuación del proyecto, teniendo en cuenta las 
alternativas de construcción del mismo que se nos planteen. 
 
Estos dos objetivos principales se concretan en una serie de acciones a realizar, unas 
técnicas a aplicar y unos productos a obtener. Resulta obvio (en cualquier contexto, no 
solo en el terreno informático) que un primer paso necesario para solucionar un problema 
es tenerlo definido correcta y detalladamente. Esto implica dos cosas: 
 
Es fundamental centrar la necesidad del cliente para poder definir el problema que se va a 
resolver, tratando de dejar claro lo que queda dentro y fuera del alcance del mismo. En 
este momento se está hablando de la definición, desde el punto de vista puramente 
técnico, del proyecto. Un aspecto importantea tener en cuenta es la identificación de los 
tipos de usuarios potenciales que tendrá el sistema. 
 
 
Competencia específica 
 
Distinguir los requerimientos del sistema orientado a objetos en su etapa de análisis para 
definir su diseño mediante técnicas y estándares de especificación. 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 5 
 
 
2.1. Levantamiento de requerimientos 
 
A partir de las entrevistas, reuniones, etc., se ha definido el problema; es decir, se ha 
obtenido la Especificación de Requisitos. En ella se describe lo que el sistema nuevo 
debe realizar. Y se ha averiguado, mediante un estudio de viabilidad, si el sistema se 
puede desarrollar o no. 
 
 
2.1.1. Introducción a los requerimientos 
 
Ahora, se va a realizar el siguiente paso del Ciclo de Vida: Análisis del sistema. Consiste 
en analizar los requisitos para centrarse en qué debe hacer el sistema. 
 
Con el Análisis del sistema se pretende: 
 
 Organizar la información; es decir, reflejar la información del problema en un 
formato gráfico, más fácil de manejar. Este formato hace que los requisitos sean 
entendibles para el diseñador y, a la vez, facilita la comunicación con el usuario. 
 Depurar todo aquello que no interesa y concentrarse en lo que debe hacer el 
sistema. 
 Sacar a la superficie y resolver posibles conflictos. 
 Dividir el problema en sub-problemas más fáciles de resolver. 
 
Así pues, toda aplicación se apoya en tres pilares o consta de tres partes principales: 
 
 Procesos. Son la parte funcional de la aplicación. Reflejan las funciones o tareas 
que debe realizar la aplicación, muestran cómo se transforman los datos. 
 Datos. Son la parte estática de la aplicación. Se refieren a la información que se 
necesita almacenar. 
 Eventos. Son la parte dinámica de la aplicación. Muestran los aspectos del sistema 
que cambian con el tiempo. Provocan la ejecución de la operación adecuada en 
cada momento. Son los que activan la aplicación (la ponen en marcha) y propagan 
esa activación a lo largo de la aplicación, desencadenando la ejecución de otras 
operaciones. Los eventos llevan el control de la aplicación introduciendo el 
dinamismo necesario para su ejecución. Los eventos tienen mucha relación con la 
interfaz de la aplicación. Porque a través de la interfaz se introducen los eventos. 
 
Los procesos dicen qué hay que hacer. 
Los datos indican con qué hay que hacerlo. 
Y los eventos muestran cuándo hay que hacerlo. 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 6 
 
Los tres pilares son complementarios, no tiene más importancia uno que otro, se 
necesitan los tres. En algunos sistemas predomina más uno que otro, pero siempre están 
presentes los tres. 
 
Para especificar cada uno de los tres pilares se utilizan Modelos. Un Modelo es una 
representación abstracta de la realidad. Por tanto, como resultado del análisis se 
obtendrán: 
 
 Modelo de Procesos, de modelo de Datos y de modelo de Eventos 
 Modelo de Procesos: recoge qué funciones, actividades, tareas, acciones, debe 
realizar la aplicación y cómo manejar los datos. 
 Modelo de Datos: describe la información que maneja la aplicación, los datos que 
debe almacenar. Y muestra cómo organizarla. 
 Modelo de Eventos: Indica en qué momento debe ejecutarse cada acción. Para 
construir cada modelo hay diferentes técnicas, algunas son complementarias. 
 
 
Figura 2.1. Modelos. 
 
En la fase de análisis se pretende que los modelos (de procesos, de datos y de eventos) 
estén lo suficientemente detallados sin llegar a descender al diseño. 
 
El análisis tiene por objetivo entender el problema: las necesidades del cliente, las 
restricciones que se deben cumplir. 
 
El diseño pretende obtener una solución óptima que cumpla todos los requisitos. Se 
orienta hacia la máquina, centrándose en cómo crear un sistema software que reúna 
todas las necesidades y cumpla todas las restricciones. 
 
 
2.1.2. Actividades para el levantamiento de requerimientos 
 
El levantamiento de requerimientos incluye tres tipos de actividad: 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 7 
 Sacar requisitos: la tarea de comunicarse con los clientes y los usuarios para 
determinarse cuáles son sus requisitos. Esto a veces también se llama acopio de 
los requisitos. 
 Analizar requisitos: determinándose si los requisitos indicados son confusos, 
incompletos, ambiguos, o contradictorios, y después resolviendo estas ediciones. 
 Requisitos de la grabación: Los requisitos se pueden documentar en varias 
formas, tales como documentos de lenguaje natural, utilice los casos, historias del 
usuario, o especificaciones de proceso. 
 
 
Actividad 1. Análisis y diseño en un programa orientado a Objetos 
 
El propósito de esta actividad es que reflexiones acerca de los requerimientos para llevar 
a cabo un análisis y diseño orientado a objetos. Para ello: 
 
1. Retoma lo revisado en el tema 2.1.Levantamiento de requerimientos. 
 
2. Identifica todos los requerimientos que se deben cumplir antes de un análisis y diseño 
orientado a objetos. 
 
3. Ingresa al foro, genera una nueva entrada y participa. 
 
 
2.2. Documentación para levantamientos y especificaciones 
 
La documentación reúne todas las actividades dedicadas básicamente a planificar el 
proceso de ADOO y mantener los documentos necesarios para los desarrolladores y los 
usuarios. El esquema formal que debe tener una especificación de requisitos es el 
siguiente: 
 
1. Índice 
2. Descripción del ámbito y alcance del proyecto 
3. Lista de usuarios participantes 
4. Descripción del sistema actual 
5. Catálogo (priorizado) de requisitos del sistema 
a. Funcionales 
b. No funcionales 
i. Restricciones 
ii. De funcionamiento 
* Del sistema 
* Requisitos software 
* Requisitos hardware 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 8 
iii. Manejo de excepciones 
6. Análisis de alternativas 
a. Descripción de la alternativa 1 
b. Descripción de la alternativa 2 
c. Descripción detallada de la alternativa seleccionada 
i. Modelo lógico de procesos 
ii. Análisis costo-beneficio 
iii. Diferencias significativas con las demás alternativas 
7. Apéndices (si es necesario) 
 
 
2.2.1. Documentación 
 
La documentación de los requerimientos, es una de la parte importante durante en el 
análisis. En la práctica es común describir los requerimientos en un documento, llamado 
especificación de requerimientos del software, su principal objetivo es de comunicar de 
forma efectiva los requerimientos, objetivos del dominio. 
 
En primera instancia la documentación contiene la información que aporta el cliente que 
encarga la aplicación, contiene todos los registros de las reuniones de trabajo del grupo 
de análisis. 
Documentos básicos de análisis orientado a objetos: 
 
 Documentos de análisis 
 Especificación de requisitos o requerimientos 
 Diagramas de casos de uso 
 Escenarios y sub-escenarios 
 Prototipos y su evaluación 
 
Todos los documentos deben estar identificados y codificados. 
 
Identificación 
 
Es necesario identificar todos los elementos del proceso de desarrollo de software de una 
forma única. 
 
El título debe reflejar de la mejor forma posible sus fines y su funcionalidad. 
• Descripción 
• Autores 
• Versión. Notación decimal. 
• Revisión. Autores 
• Fecha 
• Código de cada documento o diagrama 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 9 
 
Documentos de análisis 
 
Contiene la documentación que aportael cliente que encarga la aplicación. También 
contiene las actas de las reuniones de trabajo del grupo de análisis, es necesario un 
secretario que tome acta y es necesario aprobar el acta de cada reunión por todos los 
miembros. 
 
 
2.2.2. Especificaciones 
 
Expresa las características esenciales de un objeto, las cuales distinguen al objeto uno de 
otro. A parte de distinguir los objetos también provee límites conceptuales, permitiendo 
que se disponga de las características de un objeto que se necesite. 
 
El objetivo principal de las especificaciones, es en entregar una especificación de 
requisitos que ayuden a determinar de forma completa y correcta el diseño orientado a 
objetos. 
 
 
2.3. Estándares de especificación 
 
Las especificaciones del software determina el proceso de comprensión y definición 
sobre los servicios que se requieren del sistema y de identificación de las restricciones de 
funcionamiento y desarrollo del mismo. La ingeniería de requerimientos es un proceso 
crítico en el proceso del software, los errores en esta etapa originan problemas 
posteriores en el diseño e implementación del sistema. 
 
En la siguiente figura se muestra el proceso de ingeniería de requerimientos. Éste 
conduce a la producción de un documento de requerimientos, que es la especificación del 
sistema. Normalmente en este documento los requerimientos se presentan en dos niveles 
de detalle. Los usuarios finales y los clientes necesitan una declaración de alto nivel de 
los requerimientos, mientras que los desarrolladores del sistema necesitan una 
especificación más detallada de éste. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 10 
 
Figura 2.2. Estándares de especificación. 
 
 
2.3.1. Fases de la estandarización 
 
Existen cuatro fases principales en el proceso de estándares de ingeniería de 
requerimientos: 
 
1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer 
con las tecnologías actuales de software y hardware. El estudio analiza si el sistema 
propuesto será rentable desde un punto de vista de negocios y si se puede desarrollar 
dentro de las restricciones de presupuesto existentes. Este estudio debe ser relativamente 
económico de elaborar. EI resultado debe informar si se va a continuar con un análisis 
más detallado. 
 
2. Obtención y análisis de requerimientos. Es el proceso de obtener los requerimientos 
del sistema por medio de la observación de los sistemas existentes, discusiones con los 
usuarios potenciales y proveedores, el análisis de tareas, etcétera. Esto puede implicar el 
desarrollo de uno o más modelos y prototipos del sistema que ayudan al analista a 
comprender el sistema a especificar. 
 
3. Especificación de requerimientos. Es la actividad de traducir la información 
recopilada durante la actividad de análisis en un documento que define un conjunto de 
requerimientos. En este documento se pueden incluir dos tipos de requerimientos: los 
requerimientos del usuario, que son declaraciones abstractas de los requerimientos del 
cliente y del usuario final del sistema, y los requerimientos del sistema, que son una 
descripción más detallada de la funcionalidad a proporcionar. 
 
4. Validación de requerimientos. Esta actividad comprueba la veracidad, consistencia y 
completitud de los requerimientos. Durante este proceso, inevitablemente se descubren 
errores en el documento de requerimientos. Se debe modificar entonces para corregir 
estos problemas. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 11 
Por supuesto, las actividades en el proceso de requerimientos no se llevan a cabo de 
forma estrictamente secuencial. El análisis de requerimientos continúa durante la 
definición y especificación, y a lo largo del proceso surgen nuevos requerimientos. Por lo 
tanto, las actividades de análisis, definición y especificación se entrelazan. En los 
métodos ágiles como la programación extrema, los requerimientos se desarrollan de 
forma incremental conforme a las prioridades del usuario, y la obtención de 
requerimientos viene de los usuarios que forman parte del equipo de desarrollo. 
 
 
2.3.2. Análisis de restricciones 
 
Las restricciones son relaciones entre entidades de un modelo de objetos, el término de 
entidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restricción 
reduce los valores que una entidad puede tomar. 
 
 Restricciones entre objetos. Determina el estado en el cual los objetos se 
diferencian uno al otro, ejemplo: Horario de entrada de un empleado de oficina no 
puede ser después de las 9:00, suponiendo que el horario de entrada al trabajo es 
a las 9:00. 
 Restricciones entre atributos de un objeto: Determina los atributos específicos de 
un objeto, ejemplo: El objeto alumno solo debe tener como atributos, nombre 
completo y no apellido paterno, apellido materno y nombre. 
 Restricciones sobre un objeto a lo largo del tiempo. Determina el estado del objeto 
donde especifica que nunca debe de cambiar su estado, ejemplo: El objeto alumno 
no puede aumentar su número de control. 
 
Las restricciones simples pueden situarse en el modelo de objetos, restricciones 
complejas aparecerán en el modelo funcional. Las restricciones no tienen por qué 
aparecer inicialmente en el modelo de objetos, estas irán añadiéndose conforme se vaya 
concretando en la definición del modelo. 
 
 
Actividad 2. Requerimientos para diseñar un programa 
 
Con el fin de aplicar cada uno de los conceptos básicos de los estándares de 
especificaciones de un análisis, diseña un programa con orientación a objetos haciendo 
un documento que sirva como base para conocer los requerimientos para diseñar el 
programa de un salón de belleza. 
 
1. Plantea una situación hipotética o pregunta al encargado(a) de un salón de belleza 
acerca de qué le gustaría controlar por computadora (Obtención y análisis de 
requerimientos). 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 12 
 
2. Con base en la información obtenida, en un archivo de texto escribe los 
requerimientos del usuario y del sistema (Especificación de requerimientos). 
 
3. Apunta si es viable o no (Validación de requerimientos). 
 
4. Guarda tu actividad con la nomenclatura DOO_U2_A2_XXYZ. 
 
5. Envía el archivo a tu Facilitador(a) para recibir retroalimentación. 
 
 
2.4. Modelos del desarrollo del software 
 
Las metodologías se centra en una serie de combinaciones de los modelos de proceso 
genéricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodología debe 
definir con precisión los roles y actividades involucradas, junto con prácticas, guías de 
adaptación. 
 
Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías 
asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, 
por ejemplo, suele hablarse de métodos de análisis y/o diseño. 
 
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la 
diversidad de propuestas y diferencias en el grado de detalle, información disponible y 
alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones 
utilizadas para especificar artefactos producidos en actividades de análisis y diseño, 
podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y 
Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de 
desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del 
proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de 
Metodologías Tradicionales (o peyorativamente denominada MetodologíasPesadas, o 
Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más 
orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a 
equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos 
asociados al trabajo en equipo e involucran activamente al cliente en el proceso. 
 
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la 
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas primero 
para el Diseño (por ejemplo: el diagrama de Estructura) y posteriormente para el Análisis 
(por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente 
apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta 
generación. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 13 
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia), 
MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos 
estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & De 
Marco e Information Engineering. 
 
Metodologías orientadas a objetos, va unida a la evolución de los lenguajes de 
programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a 
fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y 
actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse 
algunos métodos Orientados a Objeto 
 
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de 
conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a 
un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación 
OO más popular en la actualidad (Booch-Grady, 1996)). 
 
Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE 
(Jacobson), Coad&Yourdon, Shaler&Mellor y OMT (Rumbaugh). 
 
Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational 
Unified Process (RUP), OPEN, MÉTRICA (que también soporta la notación estructurada). 
 
 
2.4.1. Ágiles 
 
Nuevas técnicas para aplicar las prácticas esenciales de la programación extrema y 
métodos ágiles para desarrollar sistemas orientados a objetos se encuentre la 
metodología ágil. Es cuando el desarrollo de software es incremental (entregas pequeñas 
de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos 
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil 
de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de 
último momento) 
 
El modelado ágil también abarca un conjunto de principios esenciales. Además delos 
principios esenciales de la programación extrema, el modelado ágil agrega principios tales 
como "modelar con un propósito", "el software es su meta principal" y "viajar con poco 
equipaje", una forma de decir que poca documentación es suficiente. 
 
Entre las metodologías ágiles identificadas: 
• Extreme Programming 
• Scrum 
• Familia de Metodologías Crystal 
• Feature Driven Development 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 14 
• ProcesoUnificado Rational, unaconfiguraciónágil 
• Dynamic Systems Development Method 
• Adaptive Software Development 
• Open Source Software Development 
 
 
2.4.2. Predictivos 
 
Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación 
durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o 
clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción 
del sistema. 
 
Todas las propuestas metodológicas antes indicadas pueden considerarse como 
metodologías tradicionales por el especial énfasis que presenta en cuanto a su 
adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), 
realizando una configuración adecuada, podría considerarse Ágil. 
 
La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o 
mecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Los 
ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que 
construir y cómo deben juntarse estas cosas. Muchas decisiones de diseño, como la 
manera de controlar la carga sobre un puente, se toman conforme los dibujos se 
producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una 
compañía diferente, para ser construidos. Se supone que el proceso de la construcción 
seguirá los dibujos. En la práctica los constructores se encuentran con algunos 
problemas, pero éstos son normalmente poco importantes. 
 
Como los dibujos especifican las piezas y cómo deben unirse, actúan como los 
fundamentos de un plan de construcción detallado. Dicho plan define las tareas que 
necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un 
plan de trabajo y un presupuesto de construcción razonablemente predecibles. También 
dice en detalle cómo deben hacer su trabajo las personas que participan en la 
construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque 
se necesita a menudo mucha habilidad manual. 
 
Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño, 
que es difícil de predecir y requiere personal caro y creativo, y la construcción que es más 
fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una 
vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una 
manera más predecible. En ingeniería civil la construcción es mucho más costosa y 
tardada que el diseño y la planeación. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 15 
Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible 
que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la 
construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software 
de modo que la construcción pueda ser sencilla una vez que el plan esté hecho. 
 
¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño 
como el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones 
significativas usando UML, podemos armar un plan de construcción y entonces podemos 
dar planes a los programadores como una actividad de construcción. 
 
Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de 
convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la 
construcción suficientemente grande en costo y tiempo para hacer valer la pena este 
enfoque? 
 
Todo esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es 
conseguir un diseño UML en un estado que pueda entregarse a los programadores. El 
problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero 
resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros 
civiles usan están basados en muchos años de práctica guardados en códigos 
ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas, 
son dóciles al análisis matemático. La única verificación que podemos hacer con los 
diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que 
sólo se descubren durante la codificación y pruebas. Incluso los diseñadores 
experimentados se sorprenden a menudo cuando convierten dichos diseños en software. 
 
Otro problema es el costo comparativo. Cuando se construye un puente, elcosto del 
esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construcción. 
En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Se 
sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas 
unitarias, una inversión casi perfecta de las proporciones de la construcción del puente. 
Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50% 
del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software 
comparado con su papel en otras ramas de la ingeniería. 
 
 
Actividad 3. Listado de características de los modelos ágiles y 
predictivos 
 
Como parte de la evaluación realiza la siguiente actividad cuyo propósito es distinguir 
entre modelos ágiles y predictivos. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 16 
1. En un archivo de texto, realiza un listado comparativo de los modelos ágiles y 
predictivos, teniendo en cuenta las definiciones vistas en los temas anteriores. 
 
Ejemplo: 
 
 
 
2. Guarda tu actividad con la nomenclatura DOO_U2_A3_XXYZ. 
 
3. Envía el archivo a tu Facilitador(a) para recibir retroalimentación. 
 
 
Autoevaluación 
 
Para reforzar los conocimientos relacionados con los temas que se abordaron en esta 
segunda unidad del curso, es necesario que resuelvas la autoevaluación. Recuerda que 
es muy importante leer cuidadosamente los planteamientos indicados y elegir la opción 
adecuada para cada uno. 
 
 
Evidencia de aprendizaje. Requerimientos para diseñar un programa 
con O O 
 
Como parte de la evaluación de esta unidad, debes llevar a cabo esta actividad cuyo 
propósito es aplicar los conceptos aprendidos en la unidad. 
 
1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con los 
estándares para diseñar un programa con OO para el control de una papelería y 
menciona el modelo de software a aplicar en la misma. 
 
2. Consulta la Escala de evaluación. 
 
3. Guarda la evidencia con el nombre DOO_U2_EA_XXYZ. 
 
4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 17 
 
Autorreflexiones 
 
Además de enviar tu Evidencia de aprendizaje, es importante que ingreses al foro 
Preguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a) presente, a 
partir de ellas, debes elaborar tu Autorreflexión en un archivo de texto llamado 
DOO_U2_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta 
Autorreflexiones. 
 
 
Cierre de la unidad 
 
Has concluido la unidad 2 del curso a lo largo de esta trabajaste con la documentación de 
requerimientos para el análisis orientado a objetos, comenzando con la parte de 
levantamiento de requerimientos, que incluye el describir cuáles son los requerimientos y 
que actividades necesitas realizar para el levantamiento de los mismos. 
 
También identificas cual es la documentación para el levantamiento y que 
especificaciones debe cumplir considerando sus estándares, divididos en sus fases y 
análisis de restricciones. Por último en esta unidad debes distinguir que modelos del 
desarrollo de software se manejan y si son ágiles o predictivos. 
 
Es aconsejable que revises nuevamente la unidad en caso de que los temas que se 
acaban de mencionar no te sean familiares o no los recuerdes, de no ser este tú caso, ya 
estás preparado(a) para seguir con la unidad 3, en donde continuarás con la 
Metodologías de Diseño para la Generación de Sistemas Orientados a Objetos, tales 
como Bosh, OOC, OMT y UML. Todo ello con el fin de terminar la última unidad del curso 
de Análisis y diseño orientado a objetos. 
 
 
Fuentes de consulta 
 
 Booch-Grady (1996) Análisis y Diseño Orientado a Objetos con Aplicaciones. México: 
Pearson Educación. 
 Cueva, J. (2005) Ingeniería del Software. Madrid: Pearson Educación. 
 Cueva, J. (2005) Análisis orientado a objetos, en: El proceso de desarrollo de 
software. Recuperado el 22 de julio de 2011 de: 
http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf 
 Fowler, M. (2003) La nueva metodología. Traducción de Alejandro Sierra para 
programacionextrema.org. Recuperado el 22 de julio de 2011 de: 
http://www.programacionextrema.org/articulos/newMethodology.es.html 
http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf
http://www.programacionextrema.org/articulos/newMethodology.es.html
Análisis y diseño orientado a objetos 
Programa desarrollado 
Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software 18 
 García, S. y Morales, E. (2003) Desarrollo de aplicaciones informáticas. Análisis y 
diseño detallado de aplicaciones informáticas de gestión. México: Ed. Thompson. 
 Kendall, E. (2005) Análisis y Diseño de sistemas. México: Pearson Educación. 
 Letelier, P. y Penadés, M. (s/f) Metodologías ágiles para el desarrollo de software: 
eXtremeProgramming (XP). Universidad Politécnica de Valencia. Recuperado el 22 
de julio de 2011 de: http://www.willydev.net/descargas/masyxp.pdf 
 WorldLingo (2011) Análisis de requisitos. WorldLingoTranslations LLC. Recuperado el 
22 de julio de 2011 de: 
http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis 
 
http://www.willydev.net/descargas/masyxp.pdf
http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis