Webml

SEMINARIO DE

SISTEMAS






Programación Extrema (XP)
&
Scrum















Una aplicación Práctica sobre el Boletín Oficial de la provincia de Salta







Indice

1) TEMA DEL SEMINARIO 1
2) OBJETIVO DEL SEMINARIO 2
3) DESCRIPCIÓN DEL SISTEMA OBJETO 2
3.1 Caso de Estudio 3
4) ALCANCE DEL PROYECTO 8
5) DESCRIPCIÓN DE POSIBLES APLICACIONES PRÁCTICASO UTILIDAD DEL RESULTADO DEL SEMINARIO 8
6) PROCESOS, METODOLOGÍAS Y/O TÉCNICAS A UTILIZAR 9
6.1 Requerimientos 9
6.2 Ingeniería de Requerimientos 10
6.3 Proceso de Análisis de Requerimientos 11
6.4 Técnicas de Elicitación de Requerimientos 11
6.5 Línea Base de Requerimientos 13
6.6 Universo del Discurso 14
6.7 Léxico Extendido del Lenguaje (LEL) 15
6.7.1Proceso de Construcción del LEL 16
6.8 Escenarios 17
6.8.1 Traceability 18
6.8.2 Descripción de escenarios 19
6.8.3 Construcción de Escenarios 20
6.9 Tarjetas CRC’S 20
6.10 Programación Extrema 21
6.10.1 Valores de la Programación Extrema 21
6.10.2 Principios de la Programación Extrema 22
6.10.3 Prácticas de la Programación Extrema 22
6.10.4Resumen 24
7) ESTUDIO DE FACTIBILIDAD 24
7.1 Factibilidad Económica 24
7.2 Factibilidad Técnica 28
7.3 Factibilidad Operativa 29
7.4 Factibilidad Legal 29
8) PLAN DE ACTIVIDADES Y CALENDARIO 29
9) GLOSARIO 30
10) REFERENCIAS 31









ANTEPROYECTO DEL SEMINARIO DE SISTEMAS


1) TEMA DE ESTE SEMINARIO


Tradicionalmente se ha tendido a tratar la captura y lagestión de requisitos de una manera que, cada vez más, se demuestra errónea. Se ha entendido la captura de los requisitos del proyecto como una fase temprana del mismo que una vez se completaba nos daba la fotografía exacta de que necesitaba nuestro cliente. Luego la única labor del gestor del proyecto era tratar de evitar que se produjesen cambios en el conjunto de requisitos y tratar que, cuandoestos se producían el cliente asumiese el coste económico de los mismos.
El problema es que el esfuerzo que supone hacer una captura detallada de todos los requisitos de un proyecto es enorme. Tan enorme que rara vez justifica el resultado. Además otra realidad es que casi nunca nuestro cliente conoce sus propias necesidades con la profundidad suficiente como para definirlas a priori y a esto seune que, a menudo, durante la vida del proyecto, las necesidades y prioridades de nuestros clientes cambian. Además nuestros clientes a menudo necesitan ver lo que somos capaces de hacer y como resolvemos sus necesidades a nivel técnico para poder descubrir nuevas necesidades u oportunidades que desconocían que éramos capaces de implementar. Podemos tratar de protegernos de estos cambiosestableciendo mecanismos de control, pero este enfoque a menudo nos lleva a clientes poco satisfechos, que verán el desarrollo del proyecto como algo rígido que no se adapta a sus necesidades y que si lo hace es repercutiendo costes añadidos al presupuesto del proyecto.

En Scrum los requisitos se expresan como elementos del Product Backlog. El Product Backlog es una lista viva de requisitos funcionales yno funcionales priorizados por su valor para el cliente. Al decir que se trata de una lista viva, dejamos claro que los requisitos que en ella aparecen y el orden de los mismos es cambiante a lo largo de la vida del proyecto. En Scrum, los requisitos se van abordando en Sprints en el orden en que aparecen en el Product Backlog.

Utilizar el Product Backlog como principal artefacto para lagestión de requisitos nos permite atajar los problemas relacionados con la gestión de requisitos que antes hemos descrito.

Aunque construir y mantener el Product Backlog es una tarea ardua, es mucho más simple que hacer una captura de requisitos tradicional. El motivo es simple, solo hay que expresar a grandes rasgos en que consiste el requisito, no es necesario un nivel de detalle muy elevado....