Unidad 2. Requerimientos para El Analisis Del Diseno Orientado A Objetos

Anlisis y diseo orientado a objetos
Programa desarrollado
Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software 1

Ingeniera en Desarrollo de Software
Cuatrimestre 04

Programa de la asignatura:

Unidad 2. Requerimientos para el anlisis del diseo
orientado a objetos

Clave: 160920413 / 150920413

ndice

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos ......................... 3
Presentacin de la unidad ........................................................................................................... 3
Propsito ........................................................................................................................................ 4
Competencia especfica .............................................................................................................. 4
2.1. Levantamiento de requerimientos ...................................................................................... 5
2.1.1. Introduccin a los requerimientos ................................................................................... 5
2.1.2. Actividades para el levantamiento de requerimientos ................................................. 6
Actividad 1. Anlisis y diseo en un programa orientado a Objetos .................................... 7
2.2. Documentacin para levantamientos y especificaciones ............................................... 7
2.2.1. Documentacin .................................................................................................................. 8
2.2.2. Especificaciones ................................................................................................................ 9
2.3. Estndares de especificacin ............................................................................................. 9
2.3.1. Fases de la estandarizacin .......................................................................................... 10
2.3.2. Anlisis de restricciones ................................................................................................. 11
Actividad 2. Requerimientos para disear 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 caractersticas de los modelos giles y predictivos ..................... 15
Autoevaluacin ........................................................................................................................... 16
Evidencia de aprendizaje. Requerimientos para disear un programa con O O ............. 16
Cierre de la unidad ..................................................................................................................... 17
Fuentes de consulta ................................................................................................................... 17

Unidad 2. Requerimientos para el anlisis del diseo orientado a
objetos

Presentacin de la unidad

El trabajo de ir detallando la definicin de un problema en forma de requisitos se realiza
de manera repetitiva, progresiva, incremental. Por un lado, supone la planificacin,
realizacin y evaluacin de las entrevistas con los clientes y usuarios finales del sistema,
que son los portadores de la informacin necesaria para conocer el problema y definir el
proyecto. Por otro lado, supone la identificacin y descomposicin 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 tcnica:

Entrevista. Es una conversacin 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 informacin principal y
de la relacin 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 realizacin de una entrevista lo habitual es la toma de notas, para redactar ms
tarde el informe de evaluacin de la misma. Para la grabacin 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, hacindole sentir incmodo. Pese a su costo, se va
generalizando el uso de videoconferencias para la realizacin de entrevistas remotas, con
la consiguiente comodidad para ambas partes.

Toda entrevista requiere de una preparacin previa: establecer los objetivos, seleccionar
al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir
documentacin, elegir el tipo de preguntas para finalmente utilizar la informacin recabada
para lograr los fines.

Segn 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 ms 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 gustara 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?

Propsito

La especificacin de requisitos es la primera fase de todo ciclo de vida o metodologa de
desarrollo de un proyecto informtico. Dos son sus objetivos principales:

Identificar las necesidades del cliente, es decir, conocer y definir el problema.
Realizar un estudio de viabilidad econmico, tcnico y legal, a partir del cual se
pueda decidir sobre la continuacin del proyecto, teniendo en cuenta las
alternativas de construccin del mismo que se nos planteen.

Estos dos objetivos principales se concretan en una serie de acciones a realizar, unas
tcnicas a aplicar y unos productos a obtener. Resulta obvio (en cualquier contexto, no
solo en el terreno informtico) 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 definicin, desde el punto de vista puramente
tcnico, del proyecto. Un aspecto importante a tener en cuenta es la identificacin de los
tipos de usuarios potenciales que tendr el sistema.

Competencia especfica

Distinguir los requerimientos del sistema orientado a objetos en su etapa de anlisis para
definir su diseo mediante tcnicas y estndares de especificacin.

2.1. Levantamiento de requerimientos

A partir de las entrevistas, reuniones, etc., se ha definido el problema; es decir, se ha
obtenido la Especificacin 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. Introduccin a los requerimientos

Ahora, se va a realizar el siguiente paso del Ciclo de Vida: Anlisis del sistema. Consiste
en analizar los requisitos para centrarse en qu debe hacer el sistema.

Con el Anlisis del sistema se pretende:

Organizar la informacin; es decir, reflejar la informacin del problema en un
formato grfico, ms fcil de manejar. Este formato hace que los requisitos sean
entendibles para el diseador y, a la vez, facilita la comunicacin 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 ms fciles de resolver.

As pues, toda aplicacin se apoya en tres pilares o consta de tres partes principales:

Procesos. Son la parte funcional de la aplicacin. Reflejan las funciones o tareas
que debe realizar la aplicacin, muestran cmo se transforman los datos.
Datos. Son la parte esttica de la aplicacin. Se refieren a la informacin que se
necesita almacenar.
Eventos. Son la parte dinmica de la aplicacin. Muestran los aspectos del sistema
que cambian con el tiempo. Provocan la ejecucin de la operacin adecuada en
cada momento. Son los que activan la aplicacin (la ponen en marcha) y propagan
esa activacin a lo largo de la aplicacin, desencadenando la ejecucin de otras
operaciones. Los eventos llevan el control de la aplicacin introduciendo el
dinamismo necesario para su ejecucin. Los eventos tienen mucha relacin con la
interfaz de la aplicacin. Porque a travs 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 cundo hay que hacerlo.

Los tres pilares son complementarios, no tiene ms importancia uno que otro, se
necesitan los tres. En algunos sistemas predomina ms uno que otro, pero siempre estn
presentes los tres.

Para especificar cada uno de los tres pilares se utilizan Modelos. Un Modelo es una
representacin abstracta de la realidad. Por tanto, como resultado del anlisis se
obtendrn:

Modelo de Procesos, de modelo de Datos y de modelo de Eventos
Modelo de Procesos: recoge qu funciones, actividades, tareas, acciones, debe
realizar la aplicacin y cmo manejar los datos.
Modelo de Datos: describe la informacin que maneja la aplicacin, los datos que
debe almacenar. Y muestra cmo organizarla.
Modelo de Eventos: Indica en qu momento debe ejecutarse cada accin. Para
construir cada modelo hay diferentes tcnicas, algunas son complementarias.

Figura 2.1. Modelos.

En la fase de anlisis se pretende que los modelos (de procesos, de datos y de eventos)
estn lo suficientemente detallados sin llegar a descender al diseo.

El anlisis tiene por objetivo entender el problema: las necesidades del cliente, las
restricciones que se deben cumplir.

El diseo pretende obtener una solucin ptima que cumpla todos los requisitos. Se
orienta hacia la mquina, centrndose en cmo crear un sistema software que rena
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 cules son sus requisitos. Esto a veces tambin se llama acopio de
los requisitos.
Analizar requisitos: determinndose si los requisitos indicados son confusos,
incompletos, ambiguos, o contradictorios, y despus resolviendo estas ediciones.
Requisitos de la grabacin: 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. Anlisis y diseo en un programa orientado a Objetos

El propsito de esta actividad es que reflexiones acerca de los requerimientos para llevar
a cabo un anlisis y diseo 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 anlisis y diseo
orientado a objetos.

3. Ingresa al foro, genera una nueva entrada y participa.

2.2. Documentacin para levantamientos y especificaciones

La documentacin rene todas las actividades dedicadas bsicamente a planificar el
proceso de ADOO y mantener los documentos necesarios para los desarrolladores y los
usuarios. El esquema formal que debe tener una especificacin de requisitos es el
siguiente:

1. ndice
2. Descripcin del mbito y alcance del proyecto
3. Lista de usuarios participantes
4. Descripcin del sistema actual
5. Catlogo (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. Anlisis de alternativas
a. Descripcin de la alternativa 1
b. Descripcin de la alternativa 2
c. Descripcin detallada de la alternativa seleccionada
i. Modelo lgico de procesos
ii. Anlisis costo-beneficio
iii. Diferencias significativas con las dems alternativas
7. Apndices (si es necesario)

2.2.1. Documentacin

La documentacin de los requerimientos, es una de la parte importante durante en el
anlisis. En la prctica es comn describir los requerimientos en un documento, llamado
especificacin de requerimientos del software, su principal objetivo es de comunicar de
forma efectiva los requerimientos, objetivos del dominio.

En primera instancia la documentacin contiene la informacin que aporta el cliente que
encarga la aplicacin, contiene todos los registros de las reuniones de trabajo del grupo
de anlisis.
Documentos bsicos de anlisis orientado a objetos:

Documentos de anlisis
Especificacin de requisitos o requerimientos
Diagramas de casos de uso
Escenarios y sub-escenarios
Prototipos y su evaluacin

Todos los documentos deben estar identificados y codificados.

Identificacin

Es necesario identificar todos los elementos del proceso de desarrollo de software de una
forma nica.

El ttulo debe reflejar de la mejor forma posible sus fines y su funcionalidad.
Descripcin
Autores
Versin. Notacin decimal.
Revisin. Autores
Fecha
Cdigo de cada documento o diagrama

Documentos de anlisis

Contiene la documentacin que aporta el cliente que encarga la aplicacin. Tambin
contiene las actas de las reuniones de trabajo del grupo de anlisis, es necesario un
secretario que tome acta y es necesario aprobar el acta de cada reunin por todos los
miembros.

2.2.2. Especificaciones

Expresa las caractersticas esenciales de un objeto, las cuales distinguen al objeto uno de
otro. A parte de distinguir los objetos tambin provee lmites conceptuales, permitiendo
que se disponga de las caractersticas de un objeto que se necesite.

El objetivo principal de las especificaciones, es en entregar una especificacin de
requisitos que ayuden a determinar de forma completa y correcta el diseo orientado a
objetos.

2.3. Estndares de especificacin

Las especificaciones del software determina el proceso de comprensin y definicin
sobre los servicios que se requieren del sistema y de identificacin de las restricciones de
funcionamiento y desarrollo del mismo. La ingeniera de requerimientos es un proceso
crtico en el proceso del software, los errores en esta etapa originan problemas
posteriores en el diseo e implementacin del sistema.

En la siguiente figura se muestra el proceso de ingeniera de requerimientos. ste
conduce a la produccin de un documento de requerimientos, que es la especificacin del
sistema. Normalmente en este documento los requerimientos se presentan en dos niveles
de detalle. Los usuarios finales y los clientes necesitan una declaracin de alto nivel de
los requerimientos, mientras que los desarrolladores del sistema necesitan una
especificacin ms detallada de ste.


Figura 2.2. Estndares de especificacin.

2.3.1. Fases de la estandarizacin

Existen cuatro fases principales en el proceso de estndares de ingeniera de
requerimientos:

1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer
con las tecnologas 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
econmico de elaborar. EI resultado debe informar si se va a continuar con un anlisis
ms detallado.

2. Obtencin y anlisis de requerimientos. Es el proceso de obtener los requerimientos
del sistema por medio de la observacin de los sistemas existentes, discusiones con los
usuarios potenciales y proveedores, el anlisis de tareas, etctera. Esto puede implicar el
desarrollo de uno o ms modelos y prototipos del sistema que ayudan al analista a
comprender el sistema a especificar.

3. Especificacin de requerimientos. Es la actividad de traducir la informacin
recopilada durante la actividad de anlisis 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
descripcin ms detallada de la funcionalidad a proporcionar.

4. Validacin 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 anlisis de requerimientos contina durante la
definicin y especificacin, y a lo largo del proceso surgen nuevos requerimientos. Por lo
tanto, las actividades de anlisis, definicin y especificacin se entrelazan. En los
mtodos giles como la programacin extrema, los requerimientos se desarrollan de
forma incremental conforme a las prioridades del usuario, y la obtencin de
requerimientos viene de los usuarios que forman parte del equipo de desarrollo.

2.3.2. Anlisis de restricciones

Las restricciones son relaciones entre entidades de un modelo de objetos, el trmino de
entidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restriccin
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 despus 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 especficos 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 nmero de control.

Las restricciones simples pueden situarse en el modelo de objetos, restricciones
complejas aparecern en el modelo funcional. Las restricciones no tienen por qu
aparecer inicialmente en el modelo de objetos, estas irn aadindose conforme se vaya
concretando en la definicin del modelo.

Actividad 2. Requerimientos para disear un programa

Con el fin de aplicar cada uno de los conceptos bsicos de los estndares de
especificaciones de un anlisis, disea un programa con orientacin a objetos haciendo
un documento que sirva como base para conocer los requerimientos para disear el
programa de un saln de belleza.

1. Plantea una situacin hipottica o pregunta al encargado(a) de un saln de belleza
acerca de qu le gustara controlar por computadora (Obtencin y anlisis de
requerimientos).

2. Con base en la informacin obtenida, en un archivo de texto escribe los
requerimientos del usuario y del sistema (Especificacin de requerimientos).

3. Apunta si es viable o no (Validacin de requerimientos).

4. Guarda tu actividad con la nomenclatura DOO_U2_A2_XXYZ.

5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

2.4. Modelos del desarrollo del software

Las metodologas se centra en una serie de combinaciones de los modelos de proceso
genricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodologa debe
definir con precisin los roles y actividades involucradas, junto con prcticas, guas de
adaptacin.

Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas
asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo,
por ejemplo, suele hablarse de mtodos de anlisis y/o diseo.

La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la
diversidad de propuestas y diferencias en el grado de detalle, informacin 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 anlisis y diseo,
podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y
Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de
desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del
proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de
Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o
Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms
orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a
equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos
asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la
Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas primero
para el Diseo (por ejemplo: el diagrama de Estructura) y posteriormente para el Anlisis
(por ejemplo: Diagramas de Flujo de Datos). Estas metodologas son particularmente
apropiadas en proyectos que utilizan para la implementacin lenguajes de 3ra y 4ta
generacin.

Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE (Francia),
MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de propuestas de mtodos
estructurados en el mbito acadmico: Gane & Sarson, Ward & Mellor, Yourdon & De
Marco e Information Engineering.

Metodologas orientadas a objetos, va unida a la evolucin de los lenguajes de
programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a
fines de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y
actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a consolidarse
algunos mtodos Orientados a Objeto

En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de
conseguir una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a
un objetivo ms modesto, para dar lugar al Unified Modeling Language (UML), la notacin
OO ms popular en la actualidad (Booch-Grady, 1996)).

Algunos mtodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE
(Jacobson), Coad&Yourdon, Shaler&Mellor y OMT (Rumbaugh).

Algunas metodologas orientadas a objetos que utilizan la notacin UML son: Rational
Unified Process (RUP), OPEN, MTRICA (que tambin soporta la notacin estructurada).

2.4.1. giles

Nuevas tcnicas para aplicar las prcticas esenciales de la programacin extrema y
mtodos giles para desarrollar sistemas orientados a objetos se encuentre la
metodologa gil. Es cuando el desarrollo de software es incremental (entregas pequeas
de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil
de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de
ltimo momento)

El modelado gil tambin abarca un conjunto de principios esenciales. Adems delos
principios esenciales de la programacin extrema, el modelado gil agrega principios tales
como "modelar con un propsito", "el software es su meta principal" y "viajar con poco
equipaje", una forma de decir que poca documentacin es suficiente.

Entre las metodologas giles identificadas:
Extreme Programming
Scrum
Familia de Metodologas Crystal
Feature Driven Development
ProcesoUnificado Rational, unaconfiguracingil
Dynamic Systems Development Method
Adaptive Software Development
Open Source Software Development

2.4.2. Predictivos

Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin
durante todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o
clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin
del sistema.

Todas las propuestas metodolgicas antes indicadas pueden considerarse como
metodologas tradicionales por el especial nfasis que presenta en cuanto a su
adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse),
realizando una configuracin adecuada, podra considerarse gil.

La inspiracin usual para las metodologas han sido disciplinas como las ingenieras civil o
mecnica. 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 cmo deben juntarse estas cosas. Muchas decisiones de diseo, 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
compaa diferente, para ser construidos. Se supone que el proceso de la construccin
seguir los dibujos. En la prctica los constructores se encuentran con algunos
problemas, pero stos son normalmente poco importantes.

Como los dibujos especifican las piezas y cmo deben unirse, actan como los
fundamentos de un plan de construccin 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 construccin razonablemente predecibles. Tambin
dice en detalle cmo deben hacer su trabajo las personas que participan en la
construccin. Esto permite que la construccin requiera menos pericia intelectual, aunque
se necesita a menudo mucha habilidad manual.

As que lo que vemos aqu son dos actividades fundamentalmente diferentes. El diseo,
que es difcil de predecir y requiere personal caro y creativo, y la construccin que es ms
fcil de predecir. Una vez que tenemos el diseo, podemos planear la construccin. Una
vez que tenemos el plan de construccin, podemos ocuparnos de la construccin de una
manera ms predecible. En ingeniera civil la construccin es mucho ms costosa y
tardada que el diseo y la planeacin.

As el acercamiento de muchas metodologas es: queremos un plan de trabajo predecible
que pueda usar gente del ms bajo nivel. Para hacerlo debemos separar el plan de la
construccin. Por consiguiente necesitamos entender cmo hacer el diseo de software
de modo que la construccin pueda ser sencilla una vez que el plan est hecho.

Qu forma toma este plan? Para muchos, ste es el papel de notaciones de diseo
como el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones
significativas usando UML, podemos armar un plan de construccin y entonces podemos
dar planes a los programadores como una actividad de construccin.

Pero aqu surgen preguntas cruciales. Es posible armar un plan que sea capaz de
convertir el cdigo en una actividad de construccin predecible? Y en tal caso, es la
construccin suficientemente grande en costo y tiempo para hacer valer la pena este
enfoque?

Todo esto trae a la mente ms preguntas. La primera es la cuestin de cun difcil es
conseguir un diseo UML en un estado que pueda entregarse a los programadores. El
problema con un diseo tipo UML es que puede parecer muy bueno en el papel, pero
resultar seriamente fallido a la hora de la programacin. Los modelos que los ingenieros
civiles usan estn basados en muchos aos de prctica guardados en cdigos
ingenieriles. Adems los problemas importantes, como el modo en que juegan las fuerzas,
son dciles al anlisis matemtico. La nica verificacin que podemos hacer con los
diagramas UML es la revisin cuidadosa. Mientras esto es til trae errores al diseo que
slo se descubren durante la codificacin y pruebas. Incluso los diseadores
experimentados se sorprenden a menudo cuando convierten dichos diseos 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 construccin.
En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Se
sugiere que para un proyecto grande, slo 15% del proyecto son cdigo y pruebas
unitarias, una inversin casi perfecta de las proporciones de la construccin del puente.
Aun cuando se consideren las pruebas parte de la construccin, el plan es todava 50%
del total. Esto genera una pregunta importante sobre la naturaleza del diseo en software
comparado con su papel en otras ramas de la ingeniera.

Actividad 3. Listado de caractersticas de los modelos giles y
predictivos

Como parte de la evaluacin realiza la siguiente actividad cuyo propsito 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.


Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
segunda unidad del curso, es necesario que resuelvas la autoevaluacin. Recuerda que
es muy importante leer cuidadosamente los planteamientos indicados y elegir la opcin
adecuada para cada uno.

Evidencia de aprendizaje. Requerimientos para disear un programa
con O O

Como parte de la evaluacin de esta unidad, debes llevar a cabo esta actividad cuyo
propsito es aplicar los conceptos aprendidos en la unidad.

1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con los
estndares para disear un programa con OO para el control de una papelera y
menciona el modelo de software a aplicar en la misma.

2. Consulta la Escala de evaluacin.

3. Guarda la evidencia con el nombre DOO_U2_EA_XXYZ.



Autorreflexiones

Adems de enviar tu Evidencia de aprendizaje, es importante que ingreses al foro
Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a) presente, a
partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado
DOO_U2_ATR_XXYZ. Posteriormente enva 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 documentacin de
requerimientos para el anlisis orientado a objetos, comenzando con la parte de
levantamiento de requerimientos, que incluye el describir cules son los requerimientos y
que actividades necesitas realizar para el levantamiento de los mismos.

Tambin identificas cual es la documentacin para el levantamiento y que
especificaciones debe cumplir considerando sus estndares, divididos en sus fases y
anlisis 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
ests preparado(a) para seguir con la unidad 3, en donde continuars con la
Metodologas de Diseo para la Generacin 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 Anlisis y diseo orientado a objetos.

Fuentes de consulta

Booch-Grady (1996) Anlisis y Diseo Orientado a Objetos con Aplicaciones. Mxico:
Pearson Educacin.
Cueva, J. (2005) Ingeniera del Software. Madrid: Pearson Educacin.
Cueva, J. (2005) Anlisis 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 metodologa. Traduccin de Alejandro Sierra para
programacionextrema.org. Recuperado el 22 de julio de 2011 de:
http://www.programacionextrema.org/articulos/newMethodology.es.html
Garca, S. y Morales, E. (2003) Desarrollo de aplicaciones informticas. Anlisis y
diseo detallado de aplicaciones informticas de gestin. Mxico: Ed. Thompson.
Kendall, E. (2005) Anlisis y Diseo de sistemas. Mxico: Pearson Educacin.
Letelier, P. y Penads, M. (s/f) Metodologas giles para el desarrollo de software:
eXtremeProgramming (XP). Universidad Politcnica de Valencia. Recuperado el 22
de julio de 2011 de: http://www.willydev.net/descargas/masyxp.pdf
WorldLingo (2011) Anlisis de requisitos. WorldLingoTranslations LLC. Recuperado el
22 de julio de 2011 de:
http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis

Unidad 2. Requerimientos para El Analisis Del Diseno Orientado A Objetos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 2. Requerimientos para El Analisis Del Diseno Orientado A Objetos

Cargado por

Copyright:

Formatos disponibles

Anlisis y diseo orientado a objetos

También podría gustarte