Herramientas CASE 2011

33
OBSERVACION ESTRUCTURADA DEL AMBIENTE (STROBE)

Transcript of Herramientas CASE 2011

Page 1: Herramientas CASE 2011

OBSERVACION ESTRUCTURADA DEL AMBIENTE (STROBE)

Page 2: Herramientas CASE 2011

OBSERVACION ESTRUCTURADA DEL AMBIENTE (STROBE)

Confirma o niega la narración organizacional de entrevistas o cuestionarios.

La observación es sistemática:1. Sigue una metodología estándar y una clasificación

estándar para el análisis de los elementos organizacionales que influencian la toma de decisiones.

2. Permite a otros analistas apliquen el mismo marco de trabajo analítico a la

misma organización.3. Limita el análisis a la organización a como existe durante la

etapa de su ciclo actual de vida.

Page 3: Herramientas CASE 2011

Elementos STROBE

1. Ubicación de la oficina. La ubicación de la oficia de un tomador de decisiones particular con respecto a las demás oficinas.

2. Ubicación del escritorio del tomador de decisiones. Proporciona pistas sobre el ejercicio de poder por el tomador de decisiones.

3. Equipo de oficina fijo. Se conforma de archiveros, libreros, etc.

4. Propiedades. Todo el equipo pequeño que se usa para procesar información (calculadoras, pantallas de video, lápices, etc.).

Page 4: Herramientas CASE 2011

Elementos STROBE5. Revistas y periódicos del negocio. Estas revelan si el

tomador de decisiones busca información externa o se apoya más en información interna.

6. Iluminación y color de la oficina. Nos indica la manera en que el tomador de decisiones recopila información.

7. Vestimenta usada por los tomadores de decisiones. El analista de sistemas puede obtener una comprensión de la credibilidad exhibida por los gerentes de la organización observando la vestimenta que usan en el trabajo.

Page 5: Herramientas CASE 2011

Elementos STROBE

Mediante el uso de STROBE el analista de sistemas puede obtener una mejor

comprensión sobre la manera en que los gerentes recopilan, procesan, almacenan y usan información.

Page 6: Herramientas CASE 2011

Alternativas de aplicación

Existen estrategias muy estructuradas, hasta sin estructura cuando se usa el enfoque STROBE.

• Análisis de fotografías. Consiste en fotografiar el ambiente de los tomadores de decisiones y análisis posterior de las mismas sobre los elementos STROBE.

• Ventajas:1. Se puede hacer un documento al que se pueda hacer referencia

repetidamente.

2. el fotógrafo se enfoca a los elementos STROBE.

3. Permite una comparación lado a lado de las organizaciones.

4. La fotografía proporciona detalles que se descuidan durante el contacto

personal.

Page 7: Herramientas CASE 2011

Alternativas de aplicaciónDesventajas:1. El decidir que fotografiar.2. A la larga puede probarse no obstruyente,

inicialmente si lo es.

Page 8: Herramientas CASE 2011

Herramientas CASE

Page 9: Herramientas CASE 2011

Introducción

• Herramientas CASE (Ingeniería Asistida por Computadora), con el fin de automatizar los aspectos clave de todo el proceso de desarrollo de un sistema, desde el principio hasta el final e incrementar su posición en el mercado competitivo

• Por otra parte, algunas herramientas CASE no ofrecen o evalúan soluciones potenciales para los problemas relacionados con sistemas o virtualmente no llevan a cabo ningún análisis de los requerimientos de la aplicación.

Page 10: Herramientas CASE 2011

Introducción

• Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software (Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.).

Page 11: Herramientas CASE 2011

Tecnología CASE

• La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información y se plantean los siguientes objetivos: – Mejorar la productividad en el desarrollo y

mantenimiento del software. – Aumentar la calidad del software. – Mejorar el tiempo y coste de desarrollo y

mantenimiento de los sistemas informáticos. – Mejorar la planificación de un proyecto – Aumentar la biblioteca de conocimiento informático de

una empresa ayudando a la búsqueda de soluciones para los requisitos.

Page 12: Herramientas CASE 2011

Tecnología CASE– Automatizar, desarrollo del software,

documentación, generación de código, pruebas de errores y gestión del proyecto.

– Ayuda a la reutilización del software, portabilidad y estandarización de la documentación

– Gestión global en todas las fases de desarrollo de software con una misma herramienta.

– Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Page 13: Herramientas CASE 2011

Clasificación de las herramientas CASE.

• Podrían clasificarse atendiendo a: – Las plataformas que soportan.– Las fases del ciclo de vida del desarrollo de

sistemas que cubren.– La arquitectura de las aplicaciones que producen.– Su funcionalidad.

Page 14: Herramientas CASE 2011

Clasificación de las herramientas CASE.

• CASE es una combinación de herramientas software (aplicaciones) y de metodologías de desarrollo:

1. Las herramientas permiten automatizar el proceso de desarrollo del software.

2. Las metodologías definen los procesos automatizar.

Page 15: Herramientas CASE 2011

Clasificación de las herramientas CASE.

• Una primera clasificación del CASE es considerando su amplitud: – TOOLKIT: es una colección de herramientas

integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informático: Planificación estratégica, Análisis, Diseño, Generación de programas.

– WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable y su documentación.

Page 16: Herramientas CASE 2011

Clasificación de las herramientas CASE.

– Una segunda clasificación es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan: • UPPER CASE: Planificación estratégica, Requerimientos

de Desarrollo Funcional de Planes Corporativos. • MIDDLE CASE: Análisis y Diseño. • LOWER CASE: Generación de código, test e

implantación

Page 17: Herramientas CASE 2011

Orientadas a Objetos.

• Las herramientas CASE orientadas a objetos proporcionan el soporte para las metodologías y notaciones orientadas a objetos, e incluso permiten generar parte del código de las aplicaciones.

• Las nuevas versiones de las herramientas CASE orientadas a objetos están ya incorporando los nuevos lenguajes como Java.

• Muchas de estas herramientas también dan soporte a bases de datos relacionales, permitiendo el modelado y diseño lógico y en algunos casos el físico, de la base de datos, incluyendo la generación de esquemas e ingeniería inversa sobre tablas y otros elementos del RDBMS.

Page 18: Herramientas CASE 2011

Orientadas a Objetos.

• Para alcanzar el grado de abstracción necesario OOCASE permiten crear diagramas que representan el modelo de objetos utilizando los elementos notacionales de metodologías específicas como: – OMT (Object Modeling Technique), Booch - Jacobson – Use Cases – UML (Unified Modeling Language) o – Fusion.

• El soporte notacional es sólo una forma de clasificar las herramientas CASE.– Otras características a tener en cuenta son: el soporte de varios

lenguajes de programación, el uso de ficheros o bibliotecas para almacenar la información del modelo y la integración con software de control de versiones.

Page 19: Herramientas CASE 2011

Orientadas a Objetos.

• Otras características a tener en cuenta son: – El soporte de varios lenguajes de programación. – El uso de ficheros o bibliotecas para almacenar la

información del modelo. – La integración con software de control de

versiones.

Page 20: Herramientas CASE 2011

Orientadas a Objetos.

• Las herramientas OOCASE crean diagramas que representan el modelo de objetos utilizando los elementos notacionales de las diferentes metodologías.

• Estas notaciones representan gráficamente clases (incluyendo atributos, métodos y eventos), relaciones entre objetos (herencia, agregación, colaboración), y cardinalidad.

• Además la mayoría, aunque no todas, las herramientas OOCASE ofrecen la posibilidad de generar un esqueleto del código de la aplicación. Este esqueleto generalmente incluye la definición de las clases y los prototipos de las funciones.

Page 21: Herramientas CASE 2011

Orientadas a Objetos.

• Cuando decimos que una herramienta OOCASE ``genera código'', nos estamos refiriendo a cabeceras y prototipos en el caso de C++ o Java, y a información de esquema en el caso de bases de datos relacionales.

• O sea, se proporciona la base para clases, métodos, y atributos en aplicaciones orientadas a objetos, así como tablas, columnas y relaciones en DBMS relacional.

Page 22: Herramientas CASE 2011

Desarrollo de prototipos

Page 23: Herramientas CASE 2011

Para qué sirve el concepto de “Prototipo”.

• Los prototipos usualmente se usan para definir los diseños futuros de una marca y en otras ocasiones se utilizan solo para analizar la reacción del público ante una idea novedosa.

• Generalmente, el prototipo, es un puntapié inicial para generar innovación en los productos que finalmente llegan al usuario.

Page 24: Herramientas CASE 2011

Definición de “prototipo” orientado al software.

• Un prototipo es una representación de un sistema, aunque no es un sistema completo, que posee las características del sistema final o parte de ellas.

Page 25: Herramientas CASE 2011

Objetivos del prototipado.

• Establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de programación.

• Suministrar un continuo flujo de información que pueda conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus meritos y amos crean problemas.

Page 26: Herramientas CASE 2011

Todos los proyectos de ingeniería de software comienzan con una petición del cliente. Para construir un prototipo del software se aplican los siguientes pasos:

PASO 1. Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo.

PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos.

PASO 3. Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo.

El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado.

Page 27: Herramientas CASE 2011

PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen.

PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicación y sugiere modificaciones.

Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.

PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción.

Page 28: Herramientas CASE 2011

• Recolección y refinamiento de datos.- Aquí se debe reunir las características que debe tener el software a ser desarrollado, así como los requisitos del mismo.

• Diseño rápido.- Se realiza un bosquejo que puede ser realizado en papeles acerca del programa con las especificaciones obtenidas en la recolección y refinamiento de datos, este puede obtenerse en corto tiempo.

• Construcción del prototipo.- En esta etapa se realiza la codificación del programa luego de ver sido realizado el diseño la cual debe estar de forma legible para la máquina aunque no se puede realizar mecánicamente puesto que las especificaciones no son detalladas.

Page 29: Herramientas CASE 2011

• Evaluación del prototipo por el cliente.- En esta etapa ya se encuentra realizado un prototipo que puede ser ejecutado y probado por el cliente para que este pueda dar la aceptación o decidir que le falta o que ajustes se deben realizar al mismo.

• Refinamiento del prototipo.- Luego de verse realizado la evaluación del producto por el cliente en esta fase se analiza lo que le falta o lo que le hay que ajustar para pasar nuevamente al diseño rápido o si todo esta de acuerdo con el cliente este pasa a la etapa de producto de ingeniería.

• Producto de ingeniería.- Es la ultima etapa donde producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad.

Page 30: Herramientas CASE 2011

Ventajas

• No modifica el flujo del ciclo de vida• Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios• Reduce costos y aumenta la probabilidad de éxito• Exige disponer de las herramientas adecuadas• No presenta calidad ni robustez• Una vez identificados todos los requisitos mediante

el prototipo, se construye el producto de ingeniería.

Page 31: Herramientas CASE 2011

Para que un prototipo sea efectivo:• Debe ser un sistema con el que se pueda

experimentar.• Énfasis en la interfaz de usuario• Debe ser comparativamente barato (< 10%)• Equipo de desarrollo reducido• Debe desarrollarse rápidamente• Herramientas y lenguajes adecuados

Page 32: Herramientas CASE 2011

Inconvenientes

• El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “plastilina y alambres”, y puede desilusionarse al decirle que el sistema aun no ha sido construido.

• El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

Page 33: Herramientas CASE 2011

CONCLUSIONES

La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

• Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.

• Que el prototipo se construya de acuerdo a lo que el cliente vaya especificando para satisfacer cada una de sus necesidades.

• Que después se desarrolle el software real con un enfoque hacia la calidad manteniendo las ideas del cliente.