Requerimientos de software

Solo disponible en BuenasTareas
  • Páginas : 6 (1296 palabras )
  • Descarga(s) : 0
  • Publicado : 2 de junio de 2011
Leer documento completo
Vista previa del texto
Técnicas para la elicitación de requerimientos de  software
Laboratorio de Programación

Parte 1

Lorena Castañeda Bueno ‐ Universidad Icesi – Laboratorio de Programación ‐ 2010

Expresa las necesidades y restricciones sobre un  producto de software, que contribuye a la  solución de un problema del “mundo real”. l ió d bl d l“ d l” Propiedad que debe exhibir un producto de software para resolver un problema del “mundo  f l bl d l“ d real”. Ti di i f d dif Tiene distintas fuentes, de diferentes personas y  niveles de la organización.

Lorena Castañeda Bueno ‐ Universidad Icesi – Laboratorio de Programación ‐ 2010

IEEE/ANSI 830‐1998 IEEE/ANSI 830‐ /

Lorena Castañeda Bueno ‐ Universidad Icesi – Laboratorio de Programación ‐ 2010

Documentos investigados¿Cuál fue la fuente? ¿Qué partes tiene? ¿Cómo lo compara con el propuesto por la IEEE/ANSI  830? ¿Qué elementos le resultaron importantes de  considerar y por qué? considerar y por qué?

Lorena Castañeda Bueno ‐ Universidad Icesi – Laboratorio de Programación ‐ 2010

La elicitación de requerimientos es un paso del  li i ió d i i d l ciclo de vida de los requerimientos en el ciclo de vida del software. vida del software Consiste en la indagación ó levantamiento de los  requerimientos por medio de técnicas conocidas y  eque e tos po ed o de téc cas co oc das y Análisis. recomendadas. Elicitación  5 Técnicas de elicitación: de Req de Req.
Entrevista Escenarios Prototipos Reuniones moderadas Observación
Especificación Mantenmto De Req.. Verificac. De  Req.

Lorena Castañeda Bueno ‐Universidad Icesi – Laboratorio de Programación ‐ 2010

Cuando un proyecto está avanzado, después de que se han realizado  Cuando un proyecto está avanzado después de que se han realizado compromisos sobre el tiempo de entrega y las reputaciones y el dinero  están en juego, aparecen comentarios como: “Yo sé que usted piensa que entiende lo que estoy diciendo (dije), pero lo que usted no entiende es que lo que estoy diciendo no es realmente  lo que quiero (quise) decir” Aún si las condiciones son de colaboración, franqueza y transparencia,  los requerimientos y restricciones pueden cambiar con el tiempo. N b ti l f lid d No subestimar la formalidad: 
Usando una notación formal En su defecto, definiendo cuidadosamente un proceso y haciéndole  seguimiento g Las dos anteriores(Algunos no hacen ninguna de las anteriores…)

Reemplazar el “eso ya lo hacemos” por “eso ya lo tenemos certificado”
Lorena Castañeda Bueno ‐ Universidad Icesi – Laboratorio de Programación ‐ 2010

Lorena Castañeda Bueno ‐ Universidad Icesi – Laboratorio de Programación ‐ 2010

La elicitación no es una actividad pasiva… ni se toma a la  L li i ió i id d i i l ligera El elicitadorde requerimientos debe ser consciente de las  q restricciones de los usuarios (fuentes de información)
Dificultad del usuario para describir sus tareas Omisión de información Omisión de información Limitación de tiempo Reacio a colaborar

Deben existir políticas institucionales, difundidas: todas las  personas en algún proceso son clientes o proveedores de un proceso. Todos deben dedicar tiempo a algo importante:  un proceso Todos deben dedicar tiempo a algo importante: tiempo de vida del software, valor que aporta el software. Prioridades: cuántos usuarios se ven afectados? Cuál es la  importancia del efecto de la solución? i i d l f d l l ió ?
Lorena Castañeda Bueno ‐ Universidad Icesi – Laboratorio de Programación ‐ 2010

El objetivo es recoger necesidades, escenarios, características, funciones, restricciones. La elicitación empieza como un proceso de  L li it ió i d comunicación pero continúa con el análisis y  modelado de la solución (contexto de ingeniería). Por  modelado de la solución (contexto de ingeniería) Por lo tanto:
Se supone que se da en un contexto de colaboración y  p q y apertura (debe plantearse como regla de juego explicita)....
tracking img