Técnicas de desarrollo – 2do Parcial

Introducción a la ingeniería de requerimientos

- Falta de comunicación
1. Introducción:

01 Síntomas y razones de una Ingeniería de Requisitos (IR) inapropiada.

Causas de proyectos fallidos  8.7% problemas técnicos, 10.6% falta de

recursos, 8.7% falta de gestión de TI, 7.5% el producto queda obsoleto, 8.2%
ausencia de apoyo de la dirección, 8.1% de planificación.
Causa de proyectos fallidos 44.1% Asociadas con IR.  9.9% Requisitos no
realistas, 8.7% cambios de requisitos, 13.1% requisitos incompletos, 12.4% falta
de implicación de los usuarios.
Desafíos para el análisis de requisitos  Objetivos inciertos, requisitos en
constante cambio, requisitos de poca calidad, atributos innecesarios, alta
complejidad, planificación poca precisa, diferentes usos de lenguaje.
Requisitos de poca calidad  requisitos faltantes, porque es “obvio”, porque se
debe hacer de inmediato, porque no se han utilizado todas las fuentes de
información.
Requisitos incorrectos  porque se han utilizado fuentes de información
incorrectos / equivocadas.
Contradicciones
Redundancias.
Ambiguos  Conduce a múltiples interpretaciones.
Diferentes Enfoques

 Requisitos completos y d alta calidad son la base del éxito de un

proyecto
 Los Requisitos faltantes deben ser detectados en forma temprana.
 A través de la IR se identifican los riesgos y pueden ser tratados de forma
temprana.

02 Las cuatro actividades principales de la IR

¿Que son los requerimientos?  Acción y efecto de requerir,

1.- Necesitar una persona o una cosa que se dedique algo

Juan necesita que Lucas

2.- Pedir alguna cosa a una persona

3.- Decir a una autoridad, a una persona que debe hacer algo.

¿Qué son los requisitos?  Una condición necesaria de una cosa

 1.- una condición o capacidad requerida por un usuario, una
persona o un sistema, para resolver problemas como un medio
para alcanzar un objetivo.

2.- una condición o capacidad q debe cumplirse o estar presente

en el sistema o subsistema para satisfacer un contrato,
estándar, una especificación u otro documento formal.

3.- una representación en forma de documento de una

condición o capacidad como las expresadas en 1 y 2.

Características del sistema q es una condición para su aceptación.

Propiedad q un sistema debería tener para lograr éxito en el entorno en

el q se usara

Ingeniería de requerimientos  IR es un enfoque sistemático y disciplinario para la

especificación y gestión de requisitos con los siguientes objetivos.

1. Conocer los requisitos relevantes, asegurar un consenso entre todos los implicados
acerca de estos, documentarlos de acuerdo a los estándares establecidos, y gestionados
automáticamente.
2. Entender y documentar los deseos y necesidades de los implicados, especificar y
gestionar los requerimientos para minimizar el riesgo de poner en producción un
sistema q no cumple con los deseos y necesidades de los stakeholders.

Porque es importantes los requerimientos?  La parte más difícil de construir un sistema

es precisamente saber q construir.

Porque importan los requerimientos?  Se deben describir antes de empezar a construir el

producto sw, y q puede ser algo q el producto sw debe hacer o una cualidad q el producto
sw debe tener. -- Más del 60% d los errores de diseño se originan durante las etapas de
requerimiento y análisis.

Un requerimiento existe ya sea xq el tipo de producto demanda ciertas funciones o

cualidades o xq el cliente quiere que ese requerimiento.

Las 4 actividades de la IR

1. Elicitar  extraer información/ requerimientos utilizando diferentes técnicas --

identificar, detallar y refinar.
2. Documentar  Definir la forma de documentar (lenguaje natural o modelado)
adecuado para el proyecto.
3. Verificar y ajustar  Asegurar la calidad en una fase temprana.
4. Administrar  Estructurar y organizar los requerimientos, gestionar su
disponibilidad, modificar los requerimientos en forma consistente e
implementarlos en el proyecto.

------------------------------------------------------ Primera prueba -------------------------------------------------

02 las cuatro actividades principales de ir

Modelo en cascada

Modelo scrum
Interactivo RUM

03 El papel de la comunicación de la IR

Los requisitos deben ser comunicados.

- Factores de los q depende:

o El lenguaje como medio para comunicar.
o La forma de comunicación elegida.
o Elección de las expresiones más sencillas.
o Conocimiento implícito (entender el negocio)

- Influido por:
o Bagaje cultural (backgroud)
o Experiencias y educación
o Aspectos sociales.

04 Características de un ingeniero de requisitos.

Puesto clave en un proyecto, punto central en la recopilación y administrador de la

información.

{Organización  [dirección, marketing, gestión de calidad (ingeniero de

requisitos(nivel operativo) - cliente - jefe de proyectos - desarrolladores - arquitecto
de sistemas documentadores - Testeado)]} Legisladores abogados

1. Seguridad en sí mismo(autoconfianza)
 Justifica por su competencia y sobretodo x su competencia en
el negocio
 Determinación en el seguimiento y clarificación en puntos
abiertos
2. No debe sobreestimar sus propias capacidades.
 Como interlocutor en un debate con especialistas. ( no es
posible creer q tiene conocimiento d todo)
 Deberá mediar entre los puntos de vista de los distintos
interesados.
 Detectar resolver conflictos.

3. Habilidad para convencer.

 Comportamiento orientado a la solución

 No está abierto a compromisos corruptos
 Perseverancia

4. Habilidad para moderar y habilidad para empatizar.

 Disposición para ponerse en el lugar de otra persona.
 Negocia entre implicados.
 Reconoce los deseos del cliente/usuario
  Genera un proceso d aprendizaje común con el grupo d trabajo
 Asegura q se tomen decisiones y se obtienen resultados.

5. Pensamiento analítico
 Capturar conceptos complejos de negocios
 Descomponer los conceptos de negocios en sus partes más
básicas
 Reconocer las conexiones entre elementos
 Describir los conceptos de negocios sin dejar dudas y
suposiciones
6. Habilidad de comunicación
 Ser capaz de expresarse en el lenguaje del cliente / usuario
 También a nivel internacional

05 Los tres tipos de requisitos

1. Funcionales  un requisito con el resultado del comportamiento q debería

ser previsto por una función del sistema
2. De calidad  define una característica q un sistema o sus funciones, deben
tener y a menudo influyen en la decisión de la arquitectura del sistema. En
términos de requisitos de la calidad como: funcionalidad, usabilidad,
portabilidad, eficiencia, mantenibilidad.
3. Restricciones  Es un requerimiento de carácter técnico q limita el enfoque
de la solución. No puede estar influenciada por personas involucradas en
el proyecto. Se refiere al sistema y a procesos de la organización. No
son parte de la implementación pero la limitan / condicionan.

NO FUNCIONALES: Los requisitos de calidad y las condiciones o restricciones

también son llamados requisitos no funcionales. Otras posibles
calificaciones.

06 Noción del rol de los requisitos de calidad.

- SIGNIFICADO Y CONSECUENCIA.

Los requisitos de calidad, normalmente, son documentados por medio

del lenguaje natural.

Son Integrados/incorporados en “requisitos funcionales”

Debe asegurar la trazabilidad y testeabilidad (pruebas) de los requisitos

de calidad.

La testeabilidad requiere la cuantificación de los requisitos de calidad.

Determina principalmente la arquitectura del sistema.

 ¿Qué es la ingeniería de requerimientos?

Necesidades de los usuarios con el objeto de llegar a una definición del sistema (IEEE)

Proceso de describir, analizar, documentar, validar los servicios y restricciones del

sistema

Conjunto d actividades en las cuales, utilizando técnicas y herramientas, se analiza un

problema y se concluye con la especificación de una solución.

Actividades involucradas en el descubrimiento, documentación y mantenimiento.

Deben usar técnicas sistemáticas con la finalidad de asegurar q los requerimientos del
sistema sean completos y sean consistentes y relevantes.

¿Para qué sirven los requisitos?

- Para mostrar los resultados q los (Stakeholders) quieren
- Para dar a los interesados la oportunidad de describir lo q quieran.
- Para representar distintos puntos d vista
- Para revisar el diseño
- Para mediar el progreso
- Para aceptar productos respectos a un criterio preciso.

¿Para quién son los requisitos?

Usuario  alguien q está involucrado en el uso del sistema cuando esté trabajando

Desarrolladores. ----- alguien involucrado en el desarrollo de un sistema que satisfaga El

requerimiento de un cliente

Ingeniero de requerimientos. ---- alguien que ayuda a formular los requerimientos del
usuario

Stakeholders. ----- alguien que tiene justificaciones para que se le permita influir sobre
los requerimientos

Cliente. ---

Tipos de Requisitos

Técnicos Funcionales: Describe la transformación q el sistema realiza

sobre las entradas y produce salidas

No Funcionales: restricciones de los servicios o funcione

q debe proveer el sistema.

No técnicos. Restricciones organizacionales o externas sobre el

producto a su provisión (legales, costo, tiempo….)
 Ejemplos de requisitos funcionales  El sistema deberá permitir localizar un cliente para
registrarle el cobro, utilizando criterios de búsqueda adecuada.

El sistema deberá permitir localizar un cliente para regístrale el cobro presionado un

botón que le permita buscar por el nombre del cliente y el identificador del cliente
(incluye detalles de implementación)

El sistema deberá permitir localizar un cliente para registrar el cobro, utilizando como
criterios de búsqueda el nombre del cliente y el identificador del cliente.

Características.
Completitud todos los servicios solicitados por el usuario deben estar definidos

Consistente. Los requerimientos no deben tener definidos contradictorias.

No Ambiguos.

No Funcionales

Pueden definirse como consideraciones o restricciones asociadas a un servicio

del sistema

Suelen llamarse también requerimientos de calidad.

Juegan un papel crucial en el diseño y desarrollo del sistema de información

Una falla en un requerimiento no funcional podría inutilizar el sistema.

Tipos de requerimientos no funcionales.

Requerimientos del producto  comportamiento del producto.

Requerimientos organizacionales  políticas y procedimientos existentes

Requerimientos externos Factores externos del sistema y su proceso de

desarrollo.

Ejemplos: Del Producto: la capacidad máxima de almacenamiento es 4MB

Organizacional: El proceso de desarrollo utilizado deberá apegarse

a los estándares definidos en la organización.

Externo: El sistema no deberá elevar a sus operadores

informaciones personales de los clientes excepto su nombre y
número de referencia.

Eficiencia y perfomance

------------------------------------------ Segunda Prueba---------------------------------------------------------

Políticas y norma de seguridad

Modelo de proceso de ingeniería de requerimientos

Modelo de procesos POHL

Elicitacion Negociacion

validacion y Especifiacion y
verificacion documentacion

Ingeniero de Requisitos

Expertos de marketing

Usuarios

Gente de calidad

Directores del proyecto

Programadores

Cliente

Expertos del dominio.

Elicitación de requisitos.

El objetivo de la elicitacion es hacer explícito el conocimiento oculto sobre las necesidades de

los clientes y usuarios y el sistema a desarrollar de forma que todos los participantes en el
problema sean capaces de entenderlo.

Aunque implícitamente en este modelo se asume que durante la realización de las actividades
de elicitacion es necesario.

 Identificar las fuentes de elicitacion es necesario

 Conocer lo mejor posible el dominio del problema
 Reutilizar especificaciones de requisitos similares en la medida de lo posible
 Utilizar la técnicas habituales de elicitacion como son las entrevistas casos de uso,
cuestionarios, prototipos, etc.
Negociación de requisitos

El objetivo de esta actividad es alcanzar acuerdos entre todos los participantes sobre los
requisitos elicitados en la actividad anterior.

Especificación/Documentos de requisitos

En esta actividad debe documentarse los requisitos elicitados y negociados para lo que Pohl
propone no se utilice una sola notación. Tantas como sean necesarias.

Validación/Verificación

El propósito de esta actividad es comprobar que los requisitos documentados corresponden con
las necesidades de los clientes y usuarios. (Validación) y comprobar que la especificación cumple
los criterios de calidad oportunos. (Verificación) Para los aspectos de validación puede recurrirse
a prototipos mientras que para la verificación puede utilizarse verificaciones formulas u otro
tipo de técnicas.

Modelo de proceso: Espiral

Modelo de procesos: Swebok

Es un proyecto conjunto del IEEE y de la ACM para producir un cuerpo de conocimiento sobre
ingeniería de software q siente las bases de dicha ingeniería como una profesión.

E licitación de requisitos  análisis y negociación de requisitos  Documentación de

requisitos validación de requisitos. 

Elicitación de requisitos

o Esta actividad se considera como la primera q es necesaria realizar para lograr

entender los problemas q hay q resolver, y es fundamentalmente una actividad
humana.
  Los Objetivos: pueden considerarse como lo requisitos de alto nivel q
deberá cumplir el sistema a desarrollar, por lo q es espacialmente critica
su identificación en los comienzos del proceso.
 Conocimiento del dominio: es fundamental conocer el dominio del
problema para ´poder inferir el conocimiento tácito q lo participantes
no suelen hacer explícito, además de para facilitar la comunicación.
 Participantes (Steaholders): es preciso conocer a todos los participantes
que tengan algún tipo de interés en el desarrollo y tener en cuenta los
puntos de vista de los distintos grupos.

 Entorno operacional: El sistema a desarrollar deberá funcionar en un

entorno q es necesario conocer para poder identificar las necesidades
de interoperabilidad con otros sistemas ya existentes

 Entorno Organizacional: el sistema afectará el entorno organizacional,

q es necesario conocer para evitar q surjan problemas con los procesos
de negocio (ejemplo de doble contabilidad en una empresa)

Análisis y negociación de requisitos

Pretende detectar y resolver los conflictos entre requisitos, determinar los

límites del sistema y como interactuar con su entorno y transforma lo requisitos
de usuario en requisitos de software

Se pretende q clasifiquen los requisitos, se realicen modelos conceptuales y se

negocien los conflictos detectados.

Clasificación de requisitos:

Los autores consideran importante clasificar los requisitos en la negociación, y

se clasifican en: capacidad/restricción, prioridad, coste/impacto,
volatilidad/estabilidad, y requisitos de producto/ requisitos de proceso.

Modelado conceptual:

Es ayudar a la comprensión del problema. No puede evitarse iniciar el diseño de

la solución. Existen múltiples modelos de modelo conceptual

Negociación de requisitos

Se ocupa de resolver los problemas q pueden surgir en los requisitos, bien xq

aya peticiones por parte del cliente y usuario q sean incompatibles.

Consultar con todos los participantes afectados y registrar las decisiones

tomadas y quien las tomó.

Documentar de requisitos.

Se remite a la gestión de requisitos para aspectos como el control de versiones

debido a los cambios hechos.
 Validación de requisitos.

Debe comprobar los documentos de requisitos para detectar omisiones,

conflictos y ambigüedad no detectada en el análisis y también se debe
comprobar q los requisitos siguen las normas de calidad establecidas.

Gestión de Requisitos.

Su objetivo es gestionar los cambios y el mantenimiento de los requisitos para q

representen el sistema q se va a desarrollar.

Rastreabilidad para poder realizar análisis de impacto cuando se producen

cambios.

Función tiene elementos de entrada y tiene una salida

E licitación de requisitos

La interacción con el negocio o el usuario no es una actividad trivial… es compleja.

Introducción

 Visión general de la actividad de e licitación con sus principales

características
 Principales problemas q suelen aparecer durante su realización
 Descripción d algunas técnicas empleadas habitualmente.
 Proponer una serie de plantillas y patrones lingüísticos pensados para
ser utilizados durante las sesiones de e licitación y como forma de
registrar requisitos-C.

Visión d E licitación

Considerar e licitación o educción de requerimientos como una actividad de la

ingeniería en la q los ingenieros de requisitos interactúan con el resto d
participantes para Obtener, registrar, y si es necesario negociar, los requisitos q
deberá satisfacer el sistema a desarrollar.

PROBLEMAS:

Problemas d articulación

Están relacionados con la expresión de sus necesidades por parte del cliente y
usuario y la comprensión d dicha necesidad.
 1. Los clientes y usuario pueden ser conscientes de sus necesidades pero no
ser capaces de expresarlas apropiadamente.
En lo q sociología se denomina el problema de decir – hacer y en filosofía se
denomina conocimiento tácito: Las personas saben cómo hacer muchas
cosas q no saben describir.
2. Los clientes y usuarios pueden no ser conscientes de sus necesidades y
puede q no entiendan como la tecnología puede ayudarla.
3. Algunos de los usuarios pueden no expresar sus necesidades por miedo a
parecer incompetentes antes los demás o porque los desarrolladores juegan
un papel excesivamente dominante en el proceso, provocando q la falta de
conocimiento tecnológico de los usuarios les haga sentir en inferioridad de
condiciones.
4. Los clientes pueden no llegar a tomar decisiones xq no pueden prever las
consecuencias de su decisión o xq no entienden las alternativas q se les
plantea.
5. Algunos desarrolladores no escuchan apropiadamente a los clientes y
usuarios bien xq creen haber entiendo sus necesidades rápidamente, bien
porque se dedican a pensar inmediatamente sobre aspectos de
implementación y no se ponen en el lugar de clientes y usuarios.

Problemas de Comunicación

1. Los clientes, usuarios y los desarrolladores tiene culturas y vocabularios

diferentes, con la posibilidad de q los mismo términos tengan significados
distintos en los distintos vocabularios, o q su significado se vea
enormemente afectado por el contexto.
2. Las preocupaciones sobre el sistema a desarrollar también suelen serlo. (El
cliente o usuario es la persona más importante involucrada en el proyecto)
3. El medio de comunicación q se utilice debe ser entendible por todos los
participantes. Se suele utilizar lenguaje natural porque es el único medio de
comunicación común a todos los participantes, a pesar de su inherente
ambigüedad.
En concreto el lenguaje natural para la audiencia de clientes y usuarias
(requisitos – C) y modelos conceptuales para la audiencia de los
desarrolladores (requisitos – D).
4. La comunicación puede verse afectada también por sus aspectos
puramente sociales.
El ingeniero d requisitos de ser capaz de comunicarse y tratar con todo tipo
de personas y ser capaz de manejar conflictos personales y políticos.

Problemas de limitaciones cognitivas.

1. El ingeniero d requisitos debe tener un conocimiento adecuado del dominio

del problema y no hacer suposiciones sobre ello, al igual q los clientes y
usuarios no deben hacer suposiciones sobre aspectos tecnológicos.
2. Cuando los problemas son grandes y complejos algunas personas tienden a
hacer simplificaciones no validas, a ignorar las partes más complejas o a
centrarse únicamente en los aspectos q más conoce o q más les afecta. El
 ingeniero d requisitos debe ser capaz de manejar problemas complejos y
asegurarse de q todos los temas importantes sean tratados.

Problemas de conducta humana

1. Puede haber conflictos y ambigüedad en los roles de cada persona debe

jugar en el proceso de e licitación. Dentro del grupo d clientes y usuarios,
algunos pueden pensar q, aunque conozcan ciertas necesidades o ciertos
aspectos importante, es responsabilidad de otros participantes más
afectados el hacerlas explicitas, con lo q el resultado final es q nadie dice
nada.

Otra situación similar puede producirse si algunos clientes y usuarios piensan q

los desarrolladores les harán todas las preguntas necesarias sobre el dominio
del problema y los desarrollados piensan q los clientes y usuarios les
proporcionarán toda la información necesaria sin necesidad d preguntar su
parte, con lo q puede quedar aspectos sin tratar.

2. La suposición o el temor a q el sistema a desarrollar cambie su forma de

trabajar o incluso ponga en peligro su puesto de trabajo, puede provocar q
algunos usuarios retengan información o incluso saboteen el desarrollo, por
ejemplo proporcionando información falsa. (Es fundamental q el ingeniero
conozca el entorno organizacional para poder detectar y tratar este tipo d
problema)

Problemas Técnicos

1. El software tiene q resolver problemas cada vez más complejos, por lo q sus
requisitos son también cada vez más complejos y contemplan detalles cada
vez más específicos y del dominio del problema
2.
3. Otra fuente de cambios es el echo d q el hardware y el software cambian
rápidamente, haciendo asequibles requisitos q antes eran inabordables por
su complejidad o por su coste.
4. También es necesario hacerlo con técnicos, personal de mantenimientos,
consultar normativas, estándares, etc.
5. Que los sistemas novedosos requieren un esfuerzo mucho mayor de e
licitación, y q las fuentes de información pueden ser muy distintas
dependiendo d la naturaleza del sistema a desarrollar.

Dominio del Problema

Forman parte de Procedimiento para identificar las necesidades de negocios de clientes

y usuarios del proceso de Ingeniería de Requisitos.

Definición: Área de experiencia o aplicación q necesita conocerse para resolver un

problema. Conjunto de concepto interrelacionados Si se va a desarrollar una aplicación
para la gestión de urgencias d un hospital, el dominio de problema sería todo el conjunto
de conceptos relacionados: urgencias, paciente, triage, ingreso, etc.

Introducción:

Técnicas de e licitación / captura de requisitos.

Sirve para: Conseguir q los interesados humanos articulen sus requisitos y…. Recopilar
el conocimiento sobre los requisitos del sistema.

Este conocimiento debe estar estructura por:

Partición  Agregando conocimiento relacionado

Abstracción  Reconocimiento de generalidades

Proyección  Organizándolo de acuerdo a una perspectiva.

Talleres de discusión, entrevistas, cuestionario o fichas, tormenta de ideas, storyboards

(flujo de trabajo), prototipos, escenarios (casos de uso)

Entrevistas: son las técnicas de e licitación mas utilizada, son prácticamente inevitables
en cualquier desarrollo ya q son una de las formas de comunicación más naturales entre
personas.

Tres fases: Preparación -- Realización – Análisis.

Fase 1 – Preparación de entrevistas

No deben improvisarse, por lo q convine realizar las siguientes tareas precias:

o Estudiar el dominio del problema

o Seleccionar a las personas a las q se va a entrevistar
o Determinar el objetivo y contenido de las entrevistas
o Planificar las entrevistas.

Preparación de entrevistas.

Estudiar el dominio.

Generar con los clientes y usuarios la confianza de que el ingeniero de requisitos

entiende sus problemas.

Para conocer el dominio del problema se puede recurrir a:

o Técnicas de estudio de documentación

o Bibliografías sobre el tema
o Documentación del proyecto similares realizados anteriormente.
o La inmersión dentro del a organización para la q se va a desarrollar.
o Periodos de aprendizaje por parte de los ingenieros.
 Seleccionar a las persona a entrevistar.

1. Se debe minimizar el número de entrevistas a realizar, por lo q es

fundamental seleccionar a las personas a entrevistar.
2. Se comienza por los directivos, y continúa con los futuros usuarios,
y con el personal técnico.
3. Conviene a estudiar el perfil de los entrevistados, buscando puntos
en común con el entrevistador q ayuden a romper el hielo.

Determinar el objetivo y contenido de las entrevistas.

 Para minimizar el tiempo de la entrevista es fundamental fijar el

objetivo q se pretenda alcanzar y determinar previamente su contenido
 Se puede mandar un cuestionario q los futuros entrevistados deben
llenar y devolver
 ¡Que decir! como decirlo! ¡a quien decirlo! cuando decirlo! ¡donde
decirlo!
 Es importante que si se preparan cuidadosamente teniendo en cuenta
quien los va a responder y no incluir conceptos q se asumen contenidos
q puedan no serlo.

Planificación de la entrevista
La fecha, hora, lugar y duración de las entrevistas deben fijarse teniendo
en cuenta la agenda del entrevistado.
Tener en cuenta el lugar en donde se va a realizar la entrevista.

Fase 2 – Realización de entrevistas

APERTURA -----DESARROLLO----TERMINACION

Apertura:

El entrevistador debe presentarse e informar al entrevistado sobre la razón de

la entrevista, que se espera conseguir, como se utilizara la información, lo
mecánica de las preguntas, etc.

Si se utiliza alguna notación grafica o matemática explicar al entrevistado antes

de utilizarlas.

Causar buena impresión en los primeros minutos.

Desarrollo:

La entrevista en si no debería durar más de dos horas, distribuyendo el tiempo

en un 20% para el entrevistador y un 80% para el entrevistado.

Se deben evitar los monólogos y mantener el control por parte del

entrevistador, contemplando la posibilidad de q una tercera persona tome notas
durante la entrevista o grabar la entrevista en cinta de video o audio, siempre
que el entrevistado este de acuerdo.

1. Preguntas abiertas
 Estas preguntas no pueden responder con un SI o un No, permiten una
mayor comunicación y evitan la sensación de interrogatorio.

Ej.: ¿Qué se hace para registrar un pedido? -- ¿Cómo se rellena un albarán?

2. Utilizar palabras apropiadas.

Se deben evitar tecnicismos q no conozca el entrevistado y palabras o frases

q puedan perturbar emocionalmente la comunicación

3. Mostrar interés en todo momento.

Comunicación no verbal durante la entrevista: tono de voz, movimiento,

expresión facial, etc.

Terminación:

Al terminar la entrevista se debe recapitular para confirmar q no ha habido

confusiones en la información recogida

Agradecer al entrevistado su colaboración y citarle para una nueva entrevista si

fuera necesario, dejando abierta la posibilidad de contactarse con esa persona.

Fase 3 – Análisis de la entrevista.

1. Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas
a limpio (minutas), reorganizar la información, contrastara con otras
entrevistas o fuentes de información, etc.
2. Una vez elaborada la información, se puede enviar al entrevistado para
confirmar los contenidos. También es importante evaluar la propia
entrevista para determinar los aspectos mejorables.
Resumen
Preparación:
Investigar la situación
Identificar las personas a entrevistar
Preparación del objetivo y contenido
Planificar el lugar y hora

Conducción / realización:
Apertura
Desarrollo
Tiempo entrevistado 80%
Terminación

Análisis:
Pasar a limpio las notas
Reorganizar la información y contrastarla
Evaluar la entrevista tendiente a mejora de aspectos.

JAD

¿Qué es el JAD?
 (Joint Appication Development, desarrollo de conjunto de aplicación),
desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales q
se desarrolla a lo largo de un conjunto de reuniones en grupo durante un
periodo de 2 a 4 días.

En estas reuniones se ayuda a los clientes y usuarios a formular problemas y

explorar posibles soluciones

Principios

1. Dinámica de grupo
2. Uso de ayudas visuales para mejorar la comunicación (diagramas,
transparencias, multimedia, herramientas CASE, etc).
3. Mantener un proceso organizado y racional.
4. Filosofía de documentación WYSIWYG (What you see is what you get, lo q
se ve es lo q se obtiene), por la que durante de reuniones se trabaja
directamente sobre los documentos a genera.

Pasos

1. JAD/Plan cuyo objetivo es e licitar y especificar requisitos

2. JAD/Design, en el q se aborda el diseño de software.

Ventajas y desventajas

Ventajas:

o Ahorrar tiempo al evitar q las opciones de los clientes se contrasten por

separado
o Todo el grupo, incluyendo los clientes y futuros usuarios revisar la
documentación
o Implica más a los clientes y usuarios a desarrollar.

Desventajas:

o No suele adaptarse bien al horario.

o No suele emplearse con frecuencia
o A muchos les parece una técnica difícil

Participantes

Jefe de JAD:

Es el responsable de todo el proceso y asume el control durante las reuniones.

Debe tener dotes de comunicación y liderazgo.

1. Entender y promover la dinámica del grupo

 2. Iniciar y centrar discusiones
3. Reconocer cuando la reunión se está desviando del tema y reconducirla.
4. Majear distintas personalidades y formas de ser de los participantes.
5. Evitar q decaiga la reunión aunque sea larga y difícil.

Analistas:

Es el responsable de la producción de los documentos q se deben generar

durante las sesiones JAD.

Debe tener la habilidad de organizar bien las ideas y expresarlas claramente por
escrito.

Si se usa un software durante las sesiones, debe ser capaz de manejar

eficientemente.

Patrocinador ejecutivo.

Es el q tiene la decisión final de q se lleve a cabo el desarrollo. Debe proporcionar

a los demás participantes información sobre la necesidad del nuevo sistema y
los beneficios q se espera obtener de él.

Representantes de sistemas de información: Son personas expertos en el

sistema de información q deben ayudar a los usuarios a comprender q es o no
factible con la tecnología actual y el esfuerzo q implica.

Representantes de los usuarios:

Jad Plan  suelen ser directivos con visión global del sistema

Jad Desing  suelen incorporarse futuros usuarios finales

Especialistas:

Personas q puede proporcionar información detallada sobre aspectos concretos

Desde el punto d vista de usuario porque conocen muy bien el funcionamiento

de una parte de organización.

Desde el punto de vista de los desarrolladores porque conocen perfectamente

ciertos aspectos técnicos de la instalación hardware de la organización.

---------------------------------------------------- Tercera Prueba-------------------------------------------

FASES DEL JAD

ADAPTACION, CELEBRACION DE LAS SESIONES, CONCLUSION.

JAD – Fase de Adaptación

El jefe del JAD es quien debe adaptar la sesión a las características propias del
proyecto en curso para ello:

1. Documentarse sobre la organización y el proyecto

 2. Decidir cuestiones organizadas sobre sesiones JAD: Numero y duración,
lugar (mejor es fuera de la empresa para evitar interrupciones), fechas, etc.
3. Seleccionar a los participantes adecuados para cada reunión.

JAD – Fase de Sesiones

Esta dividía en una serie de pasos:

Presentación: el jefe de JAD y el patrocinador ejecutivo se presentan. El

patrocinador explica los motivos, el jefe JAD explica la mecánica de la
reunión.

Definición de requisitos de alto nivel: El jefe JAD hace preguntas del

tipo. ¿Porque se construye el sistema?, ¿q beneficios se esperan del
nuevo sistema?, como puede beneficiar la organización a futuro, es
importante la seguridad de los datos.

El analista debe ir documentando, Una posibilidad es utilizar plantillas.

Delimitar el ámbito del sistema: cuando se ha reunido un conjunto de

requisitos se lo puede organizar y decidir el ámbito del sistema. En el
caso de los sistemas de información, es útil identificar a los usuarios
potenciales y determinar q tarea les ayudara a realizar (casos d uso).

Documentar temas abiertos: si un tema queda sin resolver se debe

documentar para otra sesión y asignar una persona responsable de su
solución, para ello puede utilizarse las plantillas de conflictos.

Concluir la sesión: El jefe JAD hace un repaso de la información obtenida

con los participantes.

Se da la oportunidad a toso los participantes para expresar cualquier

consideración adicional.

JAD – Conclusión

Se trata de producir un documento con la información recabada en la fase

anterior. Hay tres partes:

1. Compilar la documentación: La documentación recogida se redacta en un

documento normalizado
2. Revisar la documentación: Se envía la documentación a los participantes
para q efectúen correcciones.
3. Validación de documentos: El patrocinador ejecutivo da su aprobación. Una
vez aprobado el documento se envían copias definitivas a cada uno d los
participantes.

Brainstorming (Tormenta de ideas)

Es una técnica de reuniones en grupo cuyo objetivo es generación de ideas en un

ambiente libre de críticas o juicios.
Suelen estar formadas por un número de 4 a 10 participantes. Jefe es encargado de
comenzar la sesión que de controlarla.

Puede ayudar cuando los requisitos son todavía muy difusos.

Ventaja

El brainstoring es muy fácil de aprender y requiere poca organización, hay

propuestas de realización por video-conferencia a través d internet.

Desventaja

Puede no producir resultados con la misma calidad nivel de detalle de otras

técnicas.

Brainstorming – fases.

Preparación

Se seleccione a los participantes y al jefe de sesiones, citarlos, y preparar la sala

donde se llev ara a cabo la sesión.

Los participantes son normalmente: Clientes, usuarios, ingeniero d requisitos,

desarrolladores, y si es necesario algún experto en temas relevantes para el
proyecto.

Generación

El jefe abre la sesión exponiendo un enunciado general del problema a tratar.

Los participantes aportan libremente nuevas ideas.

El jefe es siempre el responsable para dar la palabra a un participante. Este

proceso continua hasta q el jefe decida parar, bien porque no estén generando
ideas, o porque el número de ideas sea suficientes para pasar a la siguiente fase.

Se debe tener en cuenta las siguientes reglas.

 Se prohíbe la crítica de ideas.

 Se fomentan las ideas más avanzadas, estimula a los participantes a
explorar nuevas soluciones más creativas.
 Se debe generar un gran número de ideas.
 Alentar a los participantes a combinar o completar las ideas d otros
participantes.
 Ir identificando los requisitos.

Consolidación

Se deben organizar y evaluar las ideas generadas durante la fase anterior.

Revisar ideas: se revisan las ideas generadas para clasificarlas.

 Descartar ideas: Aquellas ideas q los participantes consideren excesivamente
avanzadas se descartan.

Priorizar ideas: Se priorizan las ideas restantes identificando las esenciales, a las
que estarían bien pero no son esenciales, las q podrían ser apropiadas para una
próxima versión. Del sistema

Documentación

Después d la sesión, el jefe produce la documentación oportuna conteniendo

las ideas priorizadas y comentarios generados durante la consolidación.

Casos de Uso

Son una técnica para la especificación de requisitos funcionales, q actualmente

forman parte de la propuesta de UML.

Extend es ocasional

Include

Deber para el viernes 12 -06 2015

Verbos de boll

Mapa conceptual de la ética del ingeniero de software.

Deber para el viernes 19 -06 2015

2 ejemplos. Cada uno (esta en presma)

Del producto  usabilidades eficiencia (de performance, de espacios)

Confiabilidad portabilidad

De organización  de entregas implementación d estándares

Externos 

Viernes 26-06- 2015

Visualización con las manos y con el cuerpo

Expresiones corporales apropiadas he inapropiadas en una exposición.

 Taller en grupo

 Considere realizar una entrevista

 A quien va dirigida
 Preguntas al usuario
 Preguntas al proceso
 Preguntas al producto