Metodologas Anlisis diseo y documentacin de sistemas

FACULTA DE INGENIERIA INDUSTRIALNivel:CUARTO SEMESTREGrupo:4 NOCTURNOCarrera:LICENCIATURA EN SISTEMAS DE INFORMACINPresentado por:AVILES SANTILLAN SHIRLEY KATHIUSKACAMACHO TRUJILLO JOSE RICARDO (lder)ESTEVES BETANCUR GUILLERMO RAMONGARCIA OBREGON ESTHER NOEMI

Asignatura:ANLISIS DISEO Y DOCUMENTACIN DE SISTEMAS II

Ttulo:METODOLOGAS ANLISIS DISEO Y DOCUMENTACIN DE SISTEMAS Docente: MBA. SILVIA AGUILERA MONTEROSFecha: 12/05/2015FACULTA DE INGENIERIA INDUSTRIALNivel:CUARTO SEMESTREGrupo:4 NOCTURNOCarrera:LICENCIATURA EN SISTEMAS DE INFORMACINPresentado por:AVILES SANTILLAN SHIRLEY KATHIUSKACAMACHO TRUJILLO JOSE RICARDO (lder)ESTEVES BETANCUR GUILLERMO RAMONGARCIA OBREGON ESTHER NOEMI

Asignatura:ANLISIS DISEO Y DOCUMENTACIN DE SISTEMAS II

Ttulo:METODOLOGAS ANLISIS DISEO Y DOCUMENTACIN DE SISTEMAS Docente: MBA. SILVIA AGUILERA MONTEROSFecha: 12/05/2015

Tabla de contenidoIntroduccin1Objetivos generales1Objetivos especficos1Marco terico2Conclusin7Bibliografa7

IntroduccinEl presente trabajo detallara las dos metodologas principales para el anlisis, diseo y documentacin de sistemas, las dos metodologas que vamos a estudiar en el siguiente trabajo de investigacin son: Metodologa gil y Metodologa orientada a objetos.

Objetivos generalesEl objetivo principal de la investigacin es el de conocer y estudiar las metodologas principales para el anlisis, diseo y documentacin de sistemas, para as poder aplicarla en futuros proyectos de desarrollo de sistemas.Objetivos especficos Metodologa gil Metodologa Orientada a objetos

Marco tericoMetodologas gilesHoy en da con el auge de la tecnologa, y con el objetivo de agilizar y automatizar los procesos en el desarrollo de software, nos vemos en la necesidad de implantar Metodologas de Desarrollo de Software que nos ayuden a entregar un producto de calidad en tiempo y costo estimados, las metodologas giles de desarrollo de software han despertado inters gracias a que proponen simplicidad y velocidad para crear sistemas. Las metodologas tradicionales no se adaptan a las nuevas necesidades o expectativas que tienen los usuarios hoy en da, en parte que los mtodos usados no son flexibles ante la posibilidad de la exigencia de nuevos requerimientos. Estos cambios generalmente implican altos costos, demanda de tiempo y la reestructuracin total del proyecto que se est llevando; en contra parte, los mtodos giles permiten un desarrollo iterativo y adaptable que permite la integracin de nuevas funcionalidades a lo largo del desarrollo del proyecto; para que tanto el cliente como el desarrollador queden satisfechos porque el producto final Tiene una calidad adecuada.DescripcinUn proceso es gil 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 simple, fcil de aprender y modificar. Est bien documentado y es adaptable. Permite realizar cambios de ltimo momento).

Fases de metodologa gil

Sus elementos claves son: Poca documentacin Simplicidad Anlisis como una actividad constante Diseo evolutivo Integraciones Testeo diario

Cuando usar metodologas gilesNo existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto (recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema). Histricamente, las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y con requisitos muy cambiantes. Las metodologas giles ofrecen una solucin casi adecuada para una gran cantidad de proyectos. Sin embargo existen mtodos ms generales y con mejores resultados que otros. Saber qu reglas y metodologas aplicar en cada caso es ms importante y til que seguir ciegamente siempre las mismas.Ventajas de las metodologas gilesLas metodologas giles presentan diversas ventajas como:- Rpida respuesta a cambios de requisitos a lo largo del desarrollo.- Entrega continua y en plazos cortos de software funcional.- Trabajo conjunto entre el cliente y el equipo de desarrollo.- Minimiza los costos frente a cambios.- Importancia de la simplicidad, al eliminar el trabajo innecesario.- Atencin contina a la excelencia tcnica y al buen diseo.- Mejora continua de los procesos y el equipo de desarrollo.- Evita malentendidos de requerimientos entre el cliente y el equipo.- El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones innecesariamente generales y complejas que en realidad no son un requisito del cliente.- Cada componente del producto final ha sido probado y satisface los requerimientos.Desventajas de los mtodos giles.Como en cualquiera otra metodologa, tambin hay desventajas y problemas que surgen a la hora de implementarlas:- Falta de documentacin del diseo. El cdigo no puede tomarse como una documentacin. En sistemas de tamao grande se necesitar leer los cientos o miles de pginas del listado de cdigo fuente.- Problemas derivados de la comunicacin oral. Este tipo de comunicacin resulta difcil de preservar cuando pasa el tiempo y est sujeta a muchas ambigedades.- Falta de calidad. Probar el cdigo de forma constante no genera productos de calidad, slo revela falta de anlisis y diseo.- Fuerte dependencia de las personas. Como se evita en lo posible la documentacin y los diseos convencionales, los proyectos giles dependen crticamente de las personas.- Falta de procesos de revisin del cdigo. Con mtodos como el PSP o TSP se han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La programacin en parejas tiene resultados del 20 al 40%, que no es mucho frente al 10 y el 25% de un programador.- Falta de reusabilidad. La falta de documentacin hace difcil que pueda reutilizarse el cdigo gil.- Sobre costos y retrasos derivados de la refactorizacin continua. Para un sistema de ciertas proporciones, los costos y retrasos derivados de la refactorizacin no pueden despreciarse.

ANLISIS Y DISEO DE SISTEMAS ORIENTADO A OBJETOSEl anlisis y diseo de sistemas orientado a objetos (O-O) es una metodologa diseada para facilitar el desarrollo de sistemas que deben cambiar con rapidez en respuesta a los entornos empresariales dinmicos. El captulo 10 le ayudar a comprender lo que es el anlisis y diseo de sistemas orientado a objetos, la diferencia entre esta metodologa y la metodologa estructurada del SDLC y cundo puede ser apropiado utilizar una metodologa orientada a objetos.

Se cree que las tcnicas orientadas a objetos funcionan bien en situaciones en las que los sistemas de informacin complejos pasan a travs de un continuo proceso de mantenimiento, adaptacin y rediseo. Las metodologas orientadas a objetos utilizan el estndar de la industria para modelar sistemas orientados a objetos, conocido como lenguaje de modelado unificado (UML), para descomponer un sistema en un modelo de caso de uso.

La programacin orientada a objetos difiere de la programacin tradicional por procedimientos en cuanto a que examina a los objetos que forman parte de un sistema. Cada objeto es una representacin computacional de una cosa o evento real. Los objetos pueden ser clientes, artculos, pedidos, etctera. Los objetos se representan y agrupan mediante clases, las cuales son ideales para la reutilizacin y la facilidad de mantenimiento.

Una clase define el conjunto de atributos y comportamientos compartidos que se encuentran en cada objeto de la clase.Las fases en el UML son similares a las del SDLC. Como estos dos mtodos comparten un modelado rgido y exigente, se realizan a un ritmo ms lento y reflexivo que las fases del modelado gil. El analista pasa por las fases del problema y de identificacin, una fase de anlisis y una fase de diseo, como se muestra en la figura 1.8. Aunque gran parte de los detalles especficos los veremos en los captulos 2 y 10, los siguientes pasos muestran una descripcin breve del proceso del UML.

1. Definir el modelo de caso de uso.En esta fase, el analista identifica a los actores y los eventos principales iniciados por los actores.A menudo el analista empieza por dibujar un diagrama con figuras hechas con lneas que representan a los actores y flechas que muestran las relaciones entre ellos. A esto se le conoce como diagrama de caso de uso (captulo 2) y representa el flujo estndar de eventos en el sistema. Despus de esto, el analista por lo general escribe un escenario de caso de uso (captulo 2), que describe con palabras los pasos que se llevan a cabo comnmente.

2. Durante la fase de anlisis de sistemas, empezar a dibujar diagramas de UML.En la segunda fase (captulo 10) el analista dibujar Diagramas de actividad, los cuales ilustran todas las principales actividades en el caso de uso. Adems el analista crear uno o ms diagramas de secuencia para cada caso de uso, los cuales muestran la secuencia de actividades y su sincronizacin. sta es una oportunidad para regresar y revisar los casos de uso, replantearlos y modificarlos si es necesario.

3. Continuar en la fase de anlisis, desarrollar diagramas de clases.Los sustantivos en los casos de uso son objetos que se pueden agrupar potencialmente en clases. Por ejemplo, todo automvil es un objeto que comparte caractersticas con otros automviles. En conjunto conforman una clase.

4. An en la fase de anlisis, dibujar diagramas de estado.Los diagramas de clases se utilizan para dibujar diagramas de estado, los cuales ayudan a comprender procesos complejos que no se pueden derivar completamente mediante los diagramas de secuencia. Los diagramas de estado son en extremo tiles para modificar los diagramas de clases, por lo que contina el proceso iterativo de modelado de UML.

5. Empezar el diseo de sistemas mediante la modificacin de los diagramas de UML; despus, completar las especificaciones.

El diseo de sistemas significa modificar el sistema existente, para lo cual hay que modificar los diagramas que se dibujaron en la fase anterior. Es posible usar estos diagramas para derivar clases, sus atributos y mtodos (stos son simplemente operaciones). El analista tendr que escribir especificaciones de clase para cada una de las clases e incluir los atributos, mtodos y sus descripciones. Tambin desarrollar especificaciones de los mtodos en las que se detallen los requerimientos de entrada y salida para cada mtodo, junto con una descripcin detallada del procesamiento interno del mtodo.

6. Desarrollar y documentar el sistema.UML es, obviamente, un lenguaje de modelado. Un analista podr crear modelos maravillosos, pero si el sistema no se desarrolla no tiene mucho sentido crearlos. La documentacin es imprescindible. Entre ms completa sea la informacin que usted proporcione al equipo de desarrollo por medio de la documentacin y los diagramas de UML, ms rpido ser el desarrollo y ms slido ser el sistema de produccin final.

(KENDALL, 2011)ConclusinNo existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto (recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.)

BibliografaKENDALL, K. E. (2011). Anlisis y diseo de sistemas. . Mexico: Pearson.

ANLISIS DISEO Y DOCUMENTACIN DE SISTEMAS II1