esi 23 drspw-1-0

Post on 23-Jul-2015

123 Views

Category:

Education

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Enrique Sánchez Acosta Curso 20011/12

Departamento de Ingeniería Informática Universidad Francisco de Vitoria

Entornos de Sistemas de Información

Tema: Detailed Requirements

Specifications: Possibly

a Worst Practice?

1

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.

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

2

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?

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

3

Bibliografía recomendada

Detailed Requirements Specifications: Possibly a Worst Practice, by Scott W. Ambler

The Lean Startup, Eric Ries

Mies Van Der Rohe At Work, Peter Carter

Bibliografía básica.

Resaltada en negrita

Bibliografía

complementaria

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

4

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?

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

5

1. ¿De que va este caso?

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 proyectos

de SW analizados

Resultados Análisis de Scott W. Ambler

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

6

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?

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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

7

2. ¿Quién es Scott W. Ambler?

¿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?

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

8

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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?

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

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

10

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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?

4. Opiniones de Ambler y la metodología ágil.

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

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

12

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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?

4.1. BRUF es una mala idea

Detallar exhaustivamente los requisitos nos lleva a necesidades que luego no utilizaremos.

13

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

4.2. Just In Time

14

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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

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

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

16

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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?

5. Conclusiones ¿Y si Ambler se equivoca?

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

17

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

18

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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?

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”

19

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

“Él no cambia sus proyectos

con los requerimientos que

quiera añadir el cliente

cuando se le antoja”

5.1. Mies Van Der Rohe

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

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

5.1. Mies Van Der Rohe

“Dios está en los detalles”

Analicemos bien los requerimientos antes de

meternos con el proyecto.

21

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

Requerimientos

(Solicitado)

Requisitos

(Necesario)

22

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

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?

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

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

5.2. ¿Qué queremos ser?

– 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

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

5.2. ¿Qué queremos ser?

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

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

26

Tema: Detailed Requirements Specifications: Possibly a Worst Practice?

top related