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

Análisis y diseño orientado a objetos Programa desarrollado

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

Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software

1


Í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 ........................................................................................................................... Evidencia de aprendizaje. Requerimientos para diseñar un programa con O O

16

............. 16

Cierre de la unidad .....................................................................................................................

17

Fuentes de consulta ...................................................................................................................

17


2


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.


3

Análisis y diseño orientado a objetos Programa desarrollado 



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. Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software

4


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. Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software

5


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:


6






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 Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software

7


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. Autor es • Fecha • Código de cada documento o diagrama


8

Análisis y diseño orientado a objetos Programa desarrollado 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.


9


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.


10


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). Ciencias Exactas, Ingenierías y Tecnología | Desarrollo de Software

11


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. Habitualm ente 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.


12


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 Mic rosoft. A fines de los 80’s comenzaron a consol idarse

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


13

Análisis y diseño orientado a objetos Programa desarrollado • • • •

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.


14


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.


15


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.


16


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


17


 



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


18

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

Recommend Documents