Buscar este blog

miércoles, 18 de agosto de 2010

CAPITULO 1- INTRODUCCION A INGENIERIA DE SOFTWARE

La ingeniería de software es una disciplina de la ingeniería cuya meta es el desarrollo costeable de sistemas de ssoftware. Este es abstracto e intangible. Es una disciplina que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después  de que se utiliza.

EJERCICIOS:
 1.1 Haciendo referencia a la distribución de costos del software discutidos en la sección 1.1.7, explique por qué es apropiado considerar que el software es más que programas que son ejecutados por los usuarios finales de un sistema.

Rta: Porque el software no es sólo programas, sino todos los documentos asociados a la comfiguración de datos que se necesitan para hacer que estos programas operen de manera correcta ya que detras de la realización del software se pasan por las siguientes etapas: especificación, diseño, implementación e integración, las cuales tienen un costo que puede variar de acuerdo a la etapa por la que se está pasando, sin embargo aun no existe una respuesta sencilla a esta pregunta, ya que la distribución precisa del costo del software depende del proceso utilizado y del tipo que se vaya a desarrollar.

1.2 ¿Cuáles son los cuatro atributos importantes que todos los productos de software deben tener? sugiera otros cuatro atributos que pueden ser significativos.

Rta: Mantenibilidad: El software debe escribirse de tal forma que evolucione y cumpla las necesidades de los clientes.

Confiabilidad: El software debe ser fiable, seguro y debe ser con protección, y no causar daños físicos y económicos.

Eficiencia: Debe saber administrar los recursos del hardware y tener buen tiempo de respuesta.

Usabilidad: Debe ser fácil, sencillo, con una interfaz apropiada para el usuario.

Atributos sugeridos:

Economía: Costos accequibles para el público.
Fácil adquisición: Diferentes sistemas parar adquirir el software.
Compatibilidad: Que el software funcione en los diferentes sistemas operativos.
Conectividad: Se pueda manipular desde diferentes equipos.


1.3  ¿cuál es la diferencia entre el modelo del proceso del software y un proceso del software? sugiera dos formas en las que un modelo del proceso del software ayuda en la identificación de posibles mejoras del proceso.


Rta: La diferencia es que en el modelo se extrae del mundo real situaciones para plasmarlas en el papel y luego dar solución y el proceso del software, son las actividades y resultados que se desarrollan para obtener como resultado final el software solución. Dos formas que ayudan a identificar mejoras en el proceso son la recolección de requisitos y la identificación del problema.

1.4 Explique por qué los costos de pruebas del software son particularmente altos para productos de software genéricos que se venden a un mercado amplio. 

Rta: Porque el proceso de prueba del software genérico por buscar satisfacer al cliente una necesidad en común, lo cual exigen realiza cambios en el software de prueba incrementando asi los costos de esta etapa.


1.5 Los métodos de la ingeniería de software se empezaron a utilizar cuando la tecnología CASE  estuvo disponible para apoyarlos. Mencione cinco tipos de métodos de ayuda que proporcionan las herramientas CASE.


Rta: Los métodos de ayuda que proporcionan las herramientas Case son:


Análisis de herramientas, modelado de sistemas, la depuración, pruebas y generación de código. Actualmente todos los métodos vienen con tecnología CASE asociada  como los editores para las notaciones utilizadas en el método, módulos de análisis que verifican que el modelo de sistemas concuerde con las reglas del método y generadores de informes que ayudan a crear documentación del sistema.


1.6 Además de los retos de los sistemas heredados, le heterogeneidad y la rápida liberación, identifique otros problemas y retos que la ingeniería de software enfrentará en el siglo XXI.


Rta: Además de los tres retos mencionados a los que se debe enfrentar la ingeniería del software en el siglo XXI puede enfrentarse al reto de la USABILIDAD: Actualmente es mayor la población que hace uso de la ingeniería del software , para uso cotidiano, laboral, ocio; económico, social, y a la vez incrementa el número de personas de diferentes edades, razas, culturas, lenguajes, por lo que se requiere que sea de fácil uso para todo cliente , con una interfaz fácil de interpretar, para modificar la interfaz a una que sea mejor interpretable oara quien lo use.  El reto de la VULNERABILIDAD a virus informáticos; son mayoría notable los resultados de software afectados por virus informáticos, lo que lo hace poco confiable y fiable a los usuarios, pues no solo es falla para el software sino también para el sistema en que lo aplique o instale una notoria baja vulnerabilidad a los virus informáicos hace de éste un software  solución confiable y eficiente. El reto de la PROPIEDAD SEGURA, es tal vez justo los mas apetecido por la ingeniería de software. El trabajo , tiempo dedicado para la realización de un software en todo su ciclo de vida desde su etapa de especificación hasta la integración y las pruebas, tiene valor a la hora de examinar su proceso y desarrollo, por lo cual es seguro  y satisfactorio lograr en el desarrollo un sistema de alta seguridad a bloqueo contra la ejecución sin licencia.


1.7 Discuta si los ingenieros profesionales deben certificarse de la misma forma que los doctores o abogados.


Rta: Si deben  certificarse ya que desempeña un oficio profesional, y hace manejo de productos, de software dedicado a solucionar problemas, y cumple dentro de una sociedad un importante rol de crear soluciones, innovar ideales, desarrollar ideas funcionales, además de q los ingenieros de software tiene responsabilidades de la profesión de la ingeniería y en la sociedad. No solo deben estar pendientes de los aspectos técnicos.


1.8 Para cada una de las cláusulas del código de Etica de la ACM/IEEE que se muestra en la figura 1.8, sugiera un ejemplo apropiado que ilustre esta cláusula.


Rta: Público: los ingenieros deben actuar consistenetemente con el interés público. Ejemplo: cuando el interés público está dirigido a una necesidad, por decir, el consumo de tiempo en la espera de respuesta del software en el sistema,el ingeniero de software debe actuar en la solución de la necesidad.


Cliente y empleador: Los ingenieros deben actuar de forma que responda a los intereses de sus clientes y empleadores siendo consistentes con el interés público público. ejemplo: el ingeniero siendo consistente con el interés publico que es adr al software capacidad de rápida respuesta, también actuará respondiendo al cliente y al emperador, pues el cliente tiene una necesidad distinta a la del empleador.


Producto: Los ingenieos deben asegurar que sus productos y las modificaciones asociadas cumplan los más altos etándares profesionales posibles. Ejemplo: El producto que realice el ingeniero debe dar la solución requerida a l anecesidad presentada y en su etapa de pruebas  logre suplir las fallas y errores que puede presentar en la etapa de integración hasta conseguir un alto estándar profesional posible.


Juicio:  Los ingenieros de software deberán mantener la integridad e independencia en su sjuicios profesionales. Ejemplo: cuando hay la situación d que un ingeniero ha cometido un error, que le puede poner entela de juicio su profesionalismo, en colaboración con el gremio, el no juzgar au actuar ni su profesionalismo es mantener la integridad en sus juicios profesionales.


Administración: Los gerentes y líderes ingenieros de software deberán suscribir y promocionar un enfoque ético en la administración del desarrollo y mantenimiento del software. ejemplo:Como rol de líder ingeniero de software debe advertir y promocionar un modelo seguro y eficaz de administración y mantenimiento, identificar y dar a conocer las necesidades técnicas y económicas del desarrollo y mantenimiento de forma ética.


Profesión:los ingenieros de software deberán mantener la integridad y reputación de la profesión acorde al interés público. ejemplo: el ingeniero no debe salir de su integridad profesional a la hora de actuar de acuerdo al interés público es decir, un ingeniero que tiene la tarea de dar actualización a un producto que ofreció a una empresa, debe cumplir con ello de manera profesional y ética.


Colegas: los ingenieros de software deberán ser imparciales y apoyar sus colegas. Ejmplo: en colaboraci´n con el gremio, el ingeniero de software debe colaorar a sus colegas en le momento  de verse necesitado por un aporte que brinde beneficio a su producto.


Personal: durante toda su existencia, los ingenieros de software deberan aprender lo concerniente a la práctica de su profesión y promocionar un enfoque ético  en la práctica de su profesión. ejemplo: Cada persona tiene diferentes experiencias y aprende en situaciones distintas, mientras tenga vida el ingeniero aprende practicando y asi mismo de loq eu aprende y enseña y pomueve para beneficio ético de la sociedad y sus colegas.

HISTORIA DE LAS COMPUTADORES

 Cronología general de las computadoras

3000 a.C.
  • Se inventa el ábaco, probablemente en Babilonia
1800 a.C.
  • Los matemáticos babilonios desarrollan algoritmos para resolver problemas numéricos
1642
  • Blaise Pascal construye la primera máquina calculadora numérica en París.
1673
  • Gottfried Leibniz construye una máquina calculadora mecánica que multiplica, divide, suma y resta.  
1780
  • Benjamin Franklin descubre la electricidad
1805
  • Joseph Jacquard automatiza los telares mediante las cintas de papel perforado, que suministran los dibujos de las telas. Es el primer sistema automático de introducción de datos en una máquina.
1822
  • Charles Babbage construye la máquina de diferencias, que soluciona polinomios de segundo grado.
1833
  • Máquina Analítica de Babbage
1842
  • Ada Byron, Contesa de Lovelace e hija de Lord Byron, el poeta, documenta el trabajo de Babbage y escribe programas para la máquina. Es considerada la primera programadora de la historia
1875
  • Se patenta la rueda Odhner, industrializándose la producción de sumadoras. Barbour inventa el impresor de datos.
1884
  • Se introduce el teclado en las máquinas sumadoras.
1923
  • George Stibitz construye el Complex Calculator, la primera sumadora de relés.
1924
  • La empresa Tabulating Machine Company, fundada en 1896, cambia de nombre por el de International Business Machines Corporation (IBM).
1938
  • La compañía Hewlett-Packard se funda para  crear equipos electrónicos
1939
Primera Generación de Ordenadores
1941
  • Konrad Zuse construye el Z3, la primera calculadora Electromecánica de propósito general.
1942
  • ABC de Aransoffy y Berry
1944
  • Howard Aiken e I.B.M desarrollan el Mark-1, la primera calculadora                                                 electromecánica
La IBM Mark I construída en 1944
1946
  • Mauchly y Eckert construyen el ENIAC, el primer ordenador electrónico.
1947
  • Es inventado el transistor en los Laboratorios Bell
1948
  • IBM construye la SSEC (Selective Séquense Electronic Calculator) con 12.000 tubos de vidrio al vacío y 21.000 relés electromecánicos.
  • Es inventado el transistor por William Bradford Shockley
1949
  • Mauchly y Eckert construyen para la Remington Rand Co. el UNIVAC, el primer ordenador electrónico comercializable. John von Neumann consigue terminar el EDVAC, un ordenador electrónico con programación por cinta perforada.
1953
  • 701 de IBM
1957
Segunda Generación de Ordenadores
1957
  • PDP – 1 de la Digital Equpment Corporation (DEC)
  • Univac II
1958
  • Circuito Integrado por Jack Kilbry
Circuito integrado, llamado comunmente chip
1960
  • Aparece en el mercado el primer disquete
1962
  • IBM presenta su modelo 1311, usando disquetes
La IBM 311 y sus famosos discos removibles
1964
Tercera Generación de Ordenadores
1964
  • IBM 360 marca el inicio de la Tercera Generación
  • BASIC (Beginners All-purpose Symbolic Instruction Language) es creado por Tom Kurtz.
El primer modelo de la serie IBM 360
1965
·        Digital Equipment saca su primera mini computadora la PDP-8
1966
·        Texas Instruments lanza su primera calculadora de bolsillo en estado sólido
1971
Cuarta Generación de Ordenadores
1971
  • Procesador 4004 de Intel
  • Kenbak I
1972
  • Procesador 8008 de Intel
  • se inventa la primera calculadora de bolsillo, fabricada por Jack Kilby, Jerry Merryman y Jim Van Tassel
  • Gary Kildall escribe el PL/1, primer lenguaje de programación para el microprocesador Intel 4004
1974
  • Procesador 8080 de Intel
1975
  • Altair 8800 de Mits, se considera el primer microordenador o ordenador personal (PC). Antes de éste los ordenadores sólo estaban al alcance de las empresas por sus altos costos.
  • Bill Gates y Paul Allen crearon Basic para el Altair. Luego fue incluido en el equipo y con el tiempo se convirtió en un estándar para los PC
1976
  • Stephen Wozniak terminó la construcción de el ordenador Apple I para Hewlett-Packard. El equipo tenía procesador 6502  1 Mhz y 8K de RAM
  • En abril se crea Apple Computer
  • Procesador Z80 de Zilog
  • Shugart Associates intrujo el diskette de 5,25
  • Commodore International construye la Pet 2001. El Pet fue el primer ordenador personal con pantalla incorporada.
1977
·        Apple comercializa el Apple II. Tenía procesador MOS 6502, 16K de RAM, teclado, monitor, caja de plástico y conexión para cassette de cinta
1978
  • Apple y Radio Shack sacaron al mercado unidades de 5,25 pulgadas.
  • Epson saca la impresora matriz de punto MX – 80
1979
  • Procesador 8088 de Intel, utilizado luego en el IBM PC
1980
  • Primer disco Duro para micros creado por Seagate Technology (5 MB)
  • Commodore VIC – 20 tenía procesador MOS 6502, 5K de RAM, almacenamiento en cassette, monitor a color y conexión para módem.
  • Apple III. No tuvo éxito ya que tenía muchos fallos.
  • Nace el MS-DOS
1981
La Generación del PC
1981
  • IBM saca al mercado el IBM/PC. Tenía  procesador 8088 de 4,8Mhz, 64K de RAM y una o dos unidades de disquete de 5,25 con 160K de capacidad, así mismo incluía el MS-DOS. 
  • Smartmodem 300 de Hayes. Llegó a ser estándar de la Industria de los módem.
  • Disquete de 3,5 pulgadas creado por Sony. Con el mismo tamaño que el actual aunque con menor capacidad.
  • Se vendieron 1,4 millones de ordenadores.
1982
  • Procesador 80286 de Intel
  • Primer clon del IBM PC desarrollado por Columbia Data Products
  • se crea Compaq Computer
1983
  • IBM XT. Versión mejorada del IBM PC.  Tenía disco duro de 10 MB y una versión un poco mejor del MS-DOS (2.0).
  • Lotus 1-2-3 desplaza a VisiCalc como hoja de cálculo preferida en el mercado
  • La venta total de ordenadores en EEUU excede los 10 millones de unidades
1984
  • Procesador 80486 de Intel
  • Complex de Headstar Tecnologies Primer ordenador con unidad de Cd Rom
  • El Tandy 100 se convierte en el nº1 en venta de PC compatibles en su primer año
1985
  • Sale a la venta el sistema operativo Microsoft, Windows 1.0 que incluye MS-DOS ,  calculadora, calendario, reloj, Panel de Control y Note Pad
  • Aldus introduce PageMaker para la Macintosh y empieza la era de la edición del escritorio
1987
  • Segunda versión de Windows, el Windows 2.0. Ofrece mejoras de uso, adicionar iconos y permitir la superposición de ventanas
  • IBM introduce en abril la serie PS/2 y vende 1 millón de unidades el primer año.
1988
  • Un gusano se difunde en Internet  infectando a más de 6.000 servidores.
1990
  • En mayo aparece Windows 3.0 con una interfaz mucho más importantes que la de sus antecesores
1991
  • Se creó el Multimedia PC
  • Advances Micro Devices anuncia su AMD 386 para competir con Intel 386
  • Microsoft lanza el MS-DOS  5.0 con gran éxito
1992
  • Llega la saga del Windows 3.1 y 3.11, así como su variante para trabajo en grupo.
  • Intel anuncia que su próximo microprocesador se llamará Pentium en lugar de 586
1993
  • Procesador Pentium de Intel con velocidades de 60 y 66 MHz
  • Unidades CD-R que permitía grabar datos en CD
  • Newton lanzado por Apple. Nueva generación de ordenadores denominados asistentes digitales personales (PDA)
  • Microsoft lanza Windows NT
1994
  • Compaq sobrepasó a IBM en ventas de PC en el mundo.
  • Sale a la venta el sistema operativo Linux 1.0
1995
  • Procesador Pentium Pro de Intel
  • Lanzamiento del sistema operativo Windows 95, un entorno multitarea con interfaz simplificada y con otras funciones mejoradas.
1997
  • Unidades de DVD-ROM
  • Unidades de CD-RW que permiten grabar y borrar información en CD
  • El 8 de enero de este año Intel anuncia el lanzamiento del microprocesador Pentium con tecnología MMX
1998
  • Procesador Pentium II de Intel
  • Procesador K6-2 de AMD
  • Apple lanzó el iMac con un diseño futurista
  • Unidades DVD-RAM que permiten escribir discos de DVD
  • Windows 98, con la integración del WEB en el escritorio, el active desktop, y la presencia del programa Internet Explorer 4.0.
1999
  • Procesador Pentium III de Intel
  • Procesador Althon de AMD
2000
  • Lanzamiento de  Windows 2000 y Me (Millenium Edition).
2001
  • Procesador Pentium IV de Intel
  • Último sistema operativo de la empresa Microsoft Windows  hasta el momento, el Windows XP (Experience)









 

martes, 10 de agosto de 2010

INGENIERIA DE REQUISITOS

Introduccion:



Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas de computadoras), que un gran número de los proyectos de software fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos. Dentro de esa mala administración se pueden encontrar factores como la falta de participación del usuario, requerimientos incompletos y el mal manejo del cambio a los requerimientos.



La Ingeniería de Requerimientos (IR) cumple un papel primordial en el proceso de producción de software, ya que se enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, las necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestión de los requerimientos en el desarrollo de sistemas.



Definicion: Requerimientos



• Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. [Std 610.12-1900, IEEE: 62]



• Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. [Std 610.12-1900, IEEE: 62]



• Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. [Sommerville, 2005: 108]



Definicion: Ingenieria de Requerimientos



• Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software. [Pressman, 2006: 155]



• La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. [Sommerville, 2005: 82]



• La Ingeniería de Requerimientos se define, como un conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una). [Ortas 1997]



Actividades de la Ingenieria de Requerimientos:



• Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema.



• Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento.



• Especificación: En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.



• Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.



Técnicas y Herramientas utilizadas en las actividades de Ingenieria de Requerimientos:



• Entrevistas y cuestionarios



• Sistemas existentes



• Grabaciones de video y de audio



• Brainstorming (tormenta de ideas)



• Arqueología de documentos



• Aprendiz.



• Observación



• Run Use Case WorkShop (talleres de trabajo basados en los Casos de Uso)



• Prototipos



• Análisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas)



• Cadena de valor



• Modelo de clase conceptual, Diagrama Conceptual, Diagrama de Clases Conceptual



• Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone Diagram)



• Glosario



• Diagrama de actividad



• Documento ESRE, Casos de uso



• Lista de requerimientos



• Casos de uso



• Casa de calidad o QFD (Quality Function Deployment)



• Checklist (lista de verificación)







 Proceso de estudio de las necesidades de los usuarios con el objeto de llegar a una definición del sistema hw/sw.


 Condición o aptitud necesaria para resolver un problema o alcanzar un objetivo.



 Condición o facilidad que debe proporcionar un sistema o algunos de sus subsistemas para satisfacer un contrato, norma, especificación o cualquier otra condición impuesta formalmente a través de un documento.

Tipos de requisitos




  • Funcionales : Describen los servicios o funciones del sistema.




  • No funcionales: Describen las restricciones del sistema o del proceso de desarrollo: Niveles de servicio, interfaz, atributos de calidad, etc. En general, los requisitos no funcionales son más difíciles de cuantificar.



Recoleccion de Requisitos



 Definición de requisitos



Expresa en lenguaje natural o con diagramas los servicios y restricciones operacionales del sistema. Se genera con la información proporcionada por el cliente.



 Especificación de Requisitos



Documento estructurado que describe con detalle los servicios del sistema. A veces llamado especificación funcional. Escrito como contrato con el cliente.



 Especificación de software




Escrito para los diseñadores. Sirve de base para el diseño y desarrollo del sistema.





En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los años, la Ingeniería de Software ha introducido y popularizado una serie de estándares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y artículos relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y estándares de calidad.



Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen tantos proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad? ¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema?



Tal vez suene ilógico pero, a pesar de los avances que ha dado la tecnología, aún existen procesos de producción informales, parciales y en algunos casos no confiables.



La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.



La razón principal para escoger este tema se fundamentó en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto común la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas.



Tal "personalización", la mayoría de las veces, termina retrasando el proyecto en meses, o incluso en años. La problemática del año 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados.



El reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definición de los requerimientos.



Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos.



Con este trabajo se pretende alcanzar los siguientes objetivos:



• Resaltar la importancia que tiene la Ingeniería de Requerimientos dentro del ciclo de desarrollo.



• Dar a conocer las diferentes alternativas que existen para identificar requerimientos.



• Ayudar a comprender la diferencia que existe entre las diferentes técnicas utilizadas en la IR.



• Minimizar las dudas que se tiene sobre los casos de uso.



• Mostrar la utilización de herramientas CASE dentro de la administración de requisitos.

TODO SOBRE UNA ENTREVISTA

¿QUÉ ES UNA ENTREVISTA?

Una entrevista es un diálogo entablado entre dos o más personas: el entrevistador o entrevistadores que interrogan y el o los entrevistados que contestan. La palabra entrevista deriva del latín y significa "Los que van entre sí". Se trata de una técnica o instrumento empleado para diversos motivos, investigación, medicina, selección de personal. Una entrevista es un diálogo interesado, con un acuerdo previo y unos intereses y expectativas por ambas partes. También la entrevista puede significar mucho para otras personas ya que pueden ayudar a conocer personas de máxima importancia. El diccionario de la real academia española define la palabra Entrevista como: la conversación que tiene como finalidad la obtención de información. La misma proviene del francés entrevoir que significa lo que se entrevé o lo que se vislumbra.  (1)

La realización de entrevistas es uno de los procesos críticos de la consultoría, debido a la importancia de las evaluaciones que podemos articular a partir de las conversaciones con clientes, pares, etc. Aprender a hacer una entrevista se puede decir que es un arte, y al mismo tiempo es fundamental que los consultores manejen.

 
¿En qué consiste una entrevista?

Una entrevista consiste en hacer que el cliente (entrevistado) nos comparta los juicios acerca de un determinado problema o fenómeno, es decir, cómo se le aparece a él la situación en la que estamos indagando.


Imagina una situación donde hay fuego, el fuego es un fenómeno y lo que necesitamos conocer son los juicios sobre ese tema; si está muy caliente, quién lo encendió, si fue intencional, etc. El entrevistador está interesado en conocer los juicios del entrevistado, pero a nosotros no nos interesan los juicios puros, sino que hay que fundamentarlos. ¿Por qué buscar los fundamentos?, porque lo juicios para la gente que no tiene entrenamiento apuntan pobremente a los fenómenos.

No todos los clientes pueden articular sus juicios, por lo que la habilidad del entrevistador se sustenta en lograr que a través de los juicios del entrevistado ir encontrando los fundamentos. Hacer preguntas como por ejemplo “¿dónde se manifiestan?”, “¿cuándo es más probable observar esa situación?”, etc., o solicitar ejemplos. Lo que estamos buscando siempre son las afirmaciones, que son el único medio válido para fundamentar un juicio.


¿Cómo fundamentar los juicios?

Lo primero es tener clara la distinción de operación, juicio-afirmación. Si por ejemplo alguien dice “lo que pasa es que esta persona le dijo a otra”, entonces se podrían hacer preguntas tales como “¿qué le dijo?, ¿cuándo se lo dijo?, ¿cuál es la situación?”; cuando estás fundamentando juicios en otros juicios es una conversación sin valor para el entrevistador, o más bien, es una interpretación infundada. Lo importante es saber llevarlos a ese territorio, al de las afirmaciones, con el fin de lograr obtener los juicios ya fundamentados en la afirmación.


¿Qué preguntas se deben hacer?

Nosotros no compramos juicios, vendemos juicios, lo que hacemos es dar o quitar fundamento a los juicios que los clientes hacen, nosotros verificamos la validez de un juicio en su fundamento, nunca lo transformamos en afirmación. Transformar juicios en afirmaciones puede ser más potente a la hora del proceso de evaluación o diagnóstico. ¿Cómo nos aproximamos a este ejercicio de fundamentación?, debemos irnos por la línea de hacer preguntas que creen conversación, hacer preguntas neutras, por ejemplo:

  • ¿Cómo está el nivel de coordinación?
  • ¿Qué prácticas tienen ustedes con ellos?
  • ¿Me puedes dar más detalle?
  • ¿Qué prácticas tienen para coordinarse?

Hacer preguntas del tipo “¿tienen juntas?, ¿hacen minutas?”, son preguntas débiles porque ponen la posibilidad de que el entrevistado te responda “sí tengo juntas y se hace minuta”, entonces finalmente son respuestas que no apoyan al proceso de evaluación y fundamentación. Preguntas mejor enfocadas para indagar en el tema de juntas serían del tipo:

  • ¿Cómo hacen las juntas?
  • ¿Quién las convoca?
  • ¿Qué prácticas tienen durante la junta?
  • ¿Tienen alguna forma de llevar la relación?
  • ¿Quién hace la minuta?

Lo que hacemos, por decirlo de una manera gráfica, es parecer ignorante. Cuando uno no aparece como ignorante da la impresión que acusa sobre el “por qué” de las situaciones y en la respuesta no está indagando. Este ejercicio consiste en indagar, buscar el “¿qué quiere decir?”, suspender las propias convicciones y evaluaciones acerca del tema.

Este proceso consiste en indagar, explorar, mostrar interés, lograr que el entrevistado se abra, comparta sus juicios y lograr de esta forma hilar la conversación que traen. Es importante producir confianza para lograr la apertura de la conversación.

Las conversaciones son un fenómeno

Las conversaciones son un fenómeno. ¿Qué quiere decir esto?, que uno las puede caracterizar, las puede mirar, puede diseñar la forma de aproximarse, pero lo que nunca puede hacerse es anticipar el resultado real. La gente puede decir “yo manipulo el fuego” y ¿cuánta gente no se ha quemado con el fuego?, ¿por qué?, porque al final tiene algo fenomenológico, algo incontrolable por los seres humanos.


Por lo tanto, puedes diseñar una conversación, ir a realizarla y resulta que puede pasar algo que no estaba en tus planes y en ese momento se estropea la conversación, o dices algo que le gatilla desconfianza y te dice que no quiere ser grabado y por otro lado, hay que estar muy preparados porque el entrevistado tiene juicios de lo que va a hacer el entrevistador antes de que llegue.


¿Cómo estructuramos una entrevista?


Es muy importante la construcción de un contexto, se hace relevante el mostrar al entrevistado cómo embonamos todo esto en la situación, y luego le platicamos de qué queremos hablar, definir el tema de conversación o marcar las expectativas, lo que deseamos explorar con él.


Primero que nada debes conocer desde donde hablas tú, cuál es tu rol. Todas esas preguntas que vas haciendo como un checking, uno compromete todo el cuerpo y la emoción, pero tiene que ser un proceso gradual, y se debe aprender a observar siempre, siempre puedes hacer un gráfico de cada estado de ánimo.


El mood del entrevistado es siempre de menos a más, por lo que normalmente en la etapa de contextualización hay que explorar, hacer que la persona tenga una mínima apertura para recibir las preguntas. Hay que dejarlo hablar, escucharlo, mostrar interés en lo que está diciendo y hacerle más preguntas de cómo, cuándo, dónde, que muestren que es importante su experiencia, su manera de observar y fundamentar.


Si consideramos que una entrevista dura en tiempo de cero a una hora, normalmente los últimos veinte minutos son los más productivos y es cuando el entrevistado ya tiene su cuerpo acoplado a la situación. La idea principal es llevarlo al pico lo antes posible, y para eso hay que tener un alto sentido de escucha y preguntas abiertas.


Uno puede llevar una pauta de 10 preguntas y no traer nada de vuelta. La idea es que el entrevistador pueda explorar en el mundo del cliente, por eso debemos parecer “ignorantes” al momento de llevar la conversación, todo lo que el entrevistado pudiera decir de alguna manera el entrevistador lo hubiera podido suponer, pero el valor real de traernos la fuerza de su observación está en indagar, sacarle situaciones y que muestre quiénes son esas personas de las que habla, quién es el de procesos comerciales, nombres y apellidos de quienes están ahí, es decir una caracterización de los actores en el mundo del entrevistado.


Luego le preguntas al de la mesa de al lado y esa otra configuración, para luego ir sacando conclusiones sobre las interpretaciones, como por ejemplo que los problemas son la mecánica de los commitments.


Las pautas para las entrevistas

En todo el tema de las pautas, los diseños, los que hacen los diseños, lo que hacen es generar un estado de ánimo de resolución de entrar en una conversación.


Las pautas lo que logran es ponerte en la situación, tú empiezas a anticipar un poco de qué íbamos a conversar, cómo lo voy a guiar, en qué mundo está, en que cosas el cliente puede hacer juicios.

Entonces, empiezas a conectar esas preguntas de cómo te vas a mover, de lo que te produce el estado de ánimo y te da un cierto orden para la conversación, una estructura de llevar los temas, y así puedes recordar lo que inicialmente querías investigar, lo que querías producir. Por esto, tu estado de ánimo, tus principales juicios, te dan una interpretación de lo que vive el entrevistado y con eso la posible dificultad que tiene para coordinar o propiciar quiebres. (2)


Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.
Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevistas es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.
Preparación de la Entrevista
  1. Determinar la posición que ocupa de la organización el futuro entrevistado, sus responsabilidades básicas, actividades, etc. (Investigación).
  2. Preparar las preguntas que van a plantearse, y los documentos necesarios (Organización).
  3. Fijar un límite de tiempo y preparar la agenda para la entrevista. (Sicología).
  4. Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad (Sicología).
  5. Hacer la cita con la debida anticipación ( Planeación).
Conducción de la Entrevista
  1. Explicar con toda amplitud el propósito y alcance del estudio (Honestidad).
  2. Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (Imparcialidad).
  3. Hacer preguntas específicas para obtener respuestas cuantitativas (Hechos).
  4. Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (habilidad).
  5. Evitar el cuchicheo y las frases carentes de sentido (Claridad).
  6. Ser cortés y comedio, absteniéndose de emitir juicios de valores. (Objetividad).
  7. Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión.
  8. Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas (Comunicación).
Secuela de la Entrevista
  1. Escribir los resultados (Documentación).
  2. Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. (Profesionalismo).
  3. Archivar los resultados de la entrevista para referencia y análisis posteriores (Documentación).
Recabar datos mediante la Entrevista
La entrevista es una forma de conversación, no de interrogación, al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no están disponibles en ningún otra forma.
En las investigaciones de sistema, las formas cualitativas y cuantitativas de la información importantes. La información cualitativa está relacionada con opinión, política y descripciones narrativas de actividades o problemas, mientras que las descripciones cuantitativas tratan con números frecuencia, o cantidades. A menudo las entrevistas pueden ser la mejor fuente de información cualitativas, los otros métodos tiende a ser más útiles en la recabación de datos cuantitativos.
Son valiosas las opiniones, comentarios, ideas o sugerencia en relación a como se podría hacer el trabajo; las entrevistas a veces es la mejor forma para conocer las actividades de las empresas. La entrevista pueden descubrir rápidamente malos entendidos, falsa expectativa o incluso resistencia potencial para las aplicaciones de desarrollo; más aún, a menudo es más fácil calendarizar una entrevista con los gerentes de alto nivel, que pedirle que llenen cuestionario.
Determinación del tipo de Entrevista
La estructura de la entrevista varia. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de pregunta sin estructura, con una sesión de preguntas y respuesta libres
Las entrevistas estructuradas utilizan pregunta estandarizada. El formato de respuestas para las preguntas pueden ser abierto o cerrado; las preguntas para respuestas abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiado. Pueden contestar por completo con sus propias palabras. Con las preguntas para respuesta cerradas se proporcionan al usuario un conjunto de respuesta que se pueda seleccionar. Todas las personas que respondes se basan en un mismo conjunto de posible respuestas.
Los analistas también deben dividir el tiempo entre desarrollar preguntas para entrevistas y analizar respuesta. La entrevista no estructurada no requiere menos tiempos de preparación, porque no necesita tener por anticipado las palabras precisas de las preguntas. Analizar las respuestas después de la entrevista lleva más tiempo que con la entrevista estructuradas. El mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para preguntas cerradas.

Selección de Entrevistados

Realizar entrevistas toma tiempo; por lo tanto no es posible utilizar este método para recopilar toda la información que se necesite en la investigación; incluso el analista debe verificar los datos recopilados utilizando unos de los otros métodos de recabación de datos. La entrevista se aplican en todos los niveles gerencial y de empleados y dependa de quien pueda proporcionar la mayor parte de la información útil para el estudio los analistas que estudian la adminisración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal de almacén y a los supervisores de los diferentes turnos, es decir. Aquellas personas que realmente trabajan en el almacén, también entrevistarán a los gerentes más importante.

Realización de Entrevista

La habilidad del entrevistador es vital para el éxito en la búsqueda de hecho por medio de la entrevista. Las buenas entrevista depende del conocimiento del analista tanto de la preparación del objetivo de una entrevista específica como de las preguntas por realizar a una persona determinada.
El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, analista que trabaja en la aplicación enfocada a la reducción de errores (captado por la gerencia de alto nivel) probablemente no tendría éxito si llegara a una oficina de gerencia de nivel medio con la presentación equivocada, ejemplo "Estamos aquí para resolver su problema".
A través de la entrevista, los analistas deben preguntarse a sí mismo las siguientes preguntas:
  • ¿Qué es lo que me está diciendo la persona?
  • ¿Por qué me lo está diciendo a mí ?
  • ¿Qué está olvidando?
  • ¿Qué espera está persona que haga yo? (3)
 
(1) http://es.wikipedia.org./wiki/entrevista_period%C3%ADstica
(2) www.theparadigmagate.com/espanol/.../Como_Hacer_Entrevistas.pdf 
(3) http://www.monografias.com/trabajos12/recoldat/recoldat.shtml#entrev