Unidad 2. Requerimientos Para El Analisis Del Diseno Orientado a Objetos

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



Í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



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.



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 importante a 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.



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.



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:



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



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



Documentos de análisis

Contiene la documentación que aporta el 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.



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.



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



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ías Pesadas, 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.



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



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



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, el costo 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.



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.


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.




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



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

Unidad 2. Requerimientos Para El Analisis Del Diseno Orientado a Objetos

Documents

Transcript of Unidad 2. Requerimientos Para El Analisis Del Diseno Orientado a Objetos