Esi 23 drspw-1-0

Entornos de Sistemas de Información

Tema: Detailed Requirements
Specifications: Possibly
a Worst Practice?

Departamento de Ingeniería Informática Enrique Sánchez Acosta
Universidad Francisco de Vitoria Curso 20011/12

Objetivos del tema
 Ubicación
 Tema 4: Gobierno, Desarrollo SW, Optimización
– Caso 23: Detailed Requirements Specifications – Possibly a Worst
Practice

 Objetivos
 Entender conceptos como BRUF, JIT, y metodologías ágiles
 Conocer quien es Scott W. Ambler y su opinión acerca de la
especificación detallada de requerimientos.
 Presentar otra alternativa a las ideas de Scott Ambler.

1
Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

Contenido

1. ¿De que va este caso?
2. ¿Quién es Scott W. Ambler?
3. ¿Qué es BRUF?
4. Opiniones de Ambler y la metodología ágil.
1. BRUF es una mala idea
2. Just In Time
3. Ventajas de no usar BRUF
5. Conclusiones ¿Y si Ambler se equivoca?
1. Mies Van Der Rohe
2. ¿Qué queremos ser?

2

Bibliografía recomendada
 Detailed Requirements Specifications: Possibly a
Worst Practice, by Scott W. Ambler

Bibliografía básica.
Resaltada en negrita

 The Lean Startup, Eric Ries
 Mies Van Der Rohe At Work, Peter Carter

Bibliografía
complementaria

3

3. ¿Qué es BRUF?
2. Just In Time

4

 Realizar o no una especificación detallada de los requisitos, esta
es la cuestión del caso.
 Una empresa líder del SW decide realizar un estudio con cientos de
sus proyectos para analizar los resultados.
 Scott W. Ambler analiza dichos resultados y nos da su valoración.
Veremos si acertada o no.

Cientos de
Análisis de
proyectos
Resultados Scott W.
de SW
Ambler
analizados

5

3. ¿Qué es BRUF?
2. Just In Time

6


 Canadiense(1966)
 Ha trabajado con OO desde 1990 con diferentes
metodologías.
 Trabaja como “Practice Leader Agile Development“ en IBM
 Uno de los “gurús” de la
Metodología ágil

¿cómo estimar el desarrollo de un software
siendo suficientemente flexible para
incorporar nuevos requerimientos,
adecuando el plazo pero no el valor final
del software?

7

3. ¿Qué es BRUF?
2. Just In Time

8

3. ¿Qué es BRUF?

 Big Requirements Up Front (BRUF) Approach

La toma de requisitos no es tan fácil
como parece

Veamos un video explicativo:

http://youtu.be/glnrQ2fymSg

9

3. ¿Qué es BRUF?
2. Just In Time

10

 Según los resultados del estudio:

 Utilizar BRUF es una mala idea.
– Los requisitos cambian realmente.
– La comprensión de la gente cambia con el tiempo.
 Ej: Silla roja
– Las personas reconstruyen los requisitos con el tiempo.
 ¿Que habrá dentro de 4 años? Proyecto de las Olimpiadas

 JIT (Just In Time)
– Es mejor usar un enfoque JIT

 Demos el poder a los StakeHolders
– Tendrán el control del alcance del proyecto
– Controlan el presupuesto y el calendario
– Ellos deciden sus prioridades

11

3. ¿Qué es BRUF?
2. Just In Time

12

4.1. BRUF es una mala idea
 Detallar exhaustivamente los requisitos nos lleva a
necesidades que luego no utilizaremos.

13

4.2. Just In Time
 Nos permite centrarnos solo en los aspectos
fundamentales del sistema
 Puede hacer una estimación inicial en tiempo y coste
 Los desarrolladores se harán mejores preguntas
 Las partes interesadas darán mejores respuestas

14

4.3. Ventajas de no usar BRUF
 Las partes interesadas del proyecto:

 Tendrán el control del alcance del proyecto
 Controlan el presupuesto y el calendario
 Ellos deciden sus prioridades

15

3. ¿Qué es BRUF?
2. Just In Time

16

Scott W. Ambler nos da unas pautas de actuación sobre el
caso, pero …

17

3. ¿Qué es BRUF?
2. Just In Time

18

5.1. Mies Van Der Rohe
 Alemania (1886) – Illinois, Chicago(1969)
 Uno de los maestros de la arquitectura moderna.
 En su vida se basó la película “El manantial”

“Él no cambia sus proyectos
con los requerimientos que
quiera añadir el cliente
cuando se le antoja”
19

 Frases de Van Der Rohe
 “Menos es más” (aplicado a la “ingeniería”
del Software)
Demos al cliente lo que necesita, no lo que quiere.

20

“Dios está en los detalles”
Analicemos bien los
requerimientos antes de
meternos con el proyecto.

Requerimientos Requisitos
(Solicitado) (Necesario)

21

3. ¿Qué es BRUF?
2. Just In Time

22

5.2. ¿Qué queremos ser?
 Ideas de Scott W. Amber:
 Utilizar BRUF es una mala idea.
– Los requisitos cambian realmente. ¿Ah si? Las necesidades NO
varían, cambian los requerimientos.
– La comprensión de la gente cambia con el tiempo.
 ¿Estamos seguros? ¿O es que no hemos revisado bien los detalles?
 Ej: Silla roja
• Necesitamos hacer 100 sillas como esta.
• Harán falta: Madera suficiente, y pintura roja suficiente.
• Hemos hecho 50 y ahora nos damos cuenta que la parte de
abajo es verde.
• La pintura verde no estará hasta la semana que viene, se nos va
de fecha.
• Decisión del cliente, todo en rojo.
• Resultado: Un montón de sillas rojas (100) a las que hay que
añadir otro proyecto de pintado de la parte de abajo en verde
para venderlas. (Más dinero)

23

– Las personas reconstruyen los requisitos con el tiempo.
¿Seguro? ¿No será que siempre quieren mas y no les queda otro
remedio que eliminar otros?
 ¿Que habrá dentro de 4 años? Proyecto de las Olimpiadas
• Desarrollando todo el proyecto planificado de las olimpiadas de
Londres 2012, se dan cuenta en el ultimo año que quedaría muy
moderno verlo en 3D.
• Como no hay tiempo, hay que modificar los requerimientos o
requisitos. Habrá que quitar algo.
• Lo correcto sería inyectar mas dinero para hacerlo, u otro
proyecto separado, no quitar cosas.
• Por ejemplo quitamos el dinero invertido a un deporte
minoritario.
• Total, al final ven 4 la tele en 3D y hemos perdido miles de
usuarios del deporte minoritario

24

 Seamos una ciencia.
 Seamos una ingeniería: No nos convirtamos en
artesanos.
 Seamos honestos: Al que beneficia la metodología ágil es
a los desarrolladores, no al cliente.

Digamos

25

26

Esi 23 drspw-1-0

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (18)

Último

Último (20)

Esi 23 drspw-1-0