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)....
Regístrate para leer el documento completo.