OBSERVACION ESTRUCTURADA

DEL AMBIENTE (STROBE)

 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.
 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.).
 Elementos STROBE
5. 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.
 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.
 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.
 Alternativas de aplicación
Desventajas:
1. El decidir que fotografiar.
2. A la larga puede probarse no obstruyente,
inicialmente si lo es.
Herramientas CASE
 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.
 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.).
 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.
 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.
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.
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.
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.
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
 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.
 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.
 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.
 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.
 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.
Desarrollo de prototipos
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.
 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.
 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.
 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.
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.
• 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.
• 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.
 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.
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
 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.
 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.