Programa desarrollado
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.
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.
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.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.
10
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.
11
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.
12
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
13
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.
14
15
2. Guarda tu actividad con la nomenclatura DOO_U2_A3_XXYZ. 3. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.
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.
16
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
17
18