El documento describe dos enfoques para desarrollar un sistema de control de acceso de usuarios: 1) Un enfoque en cascada con especificación, análisis, diseño, implementación y pruebas. 2) Un enfoque incremental con dos fases, la primera para identificación de usuarios y la segunda para mensajes de error detallados.

1. Ejemplo Ciclos de vida

2. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Problema a resolver
Una empresa quiere implantar un sistema de control de acceso de
usuarios previo al arranque del resto de aplicaciones que tiene
instaladas. Cada usuario deberá indicar su nombre y palabra de paso
para poder tener acceso al resto del sistema.
El sistema de control de acceso permitirá un máximo de tres intentos
antes de bloquear el terminal durante cinco minutos.
El sistema deberá detectar que tanto el nombre como la palabra de paso
han sido rellenadas y que dichos valores se corresponden con los que
previamente han sido almacenados en la base de datos de control de
accesos.
Bajo ningún concepto, el nombre de usuario y la palabra de paso podrán
quedar sin rellenar.
En el caso de no poder realizar la identificación de los usuarios que
quieren acceder al sistema, deberá mostrarse un mensaje de error que
indique cual es la causa de fallo de identificación.

3. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en Cascada
Esta aproximación se basa en que hasta que no esté
terminada una fase no se puede comenzar la
siguiente.
Las fases que se plantean son:
– Especificación
– Análisis
– Diseño
– Implementación
– Pruebas
– Instalación
– Mantenimiento
(Las dos últimas se omiten en este ejemplo)

4. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en Cascada
Especificación de requisitos.
– Se han detectado los siguientes requisitos:
R1: El sistema debe permitir la identificación de usuarios
R2: Los usuarios están identificados por su nombre y palabra de
paso. En nombre no excederá la longitud de 15 caracteres y la
palabra de paso de 8.
R3: Es obligatorio que tanto el nombre como la palabra de paso
sean cumplimentados por el usuario
R4: Deberá comprobarse que el nombre de usuario y la palabra de
paso se corresponden con un usuario con autorización para
acceder al sistema, esta información ya habrá sido incorporada
previamente al mismo
R5: Cuando el usuario no esté autorizado se mostrará el mensaje
de error XX “ no tiene permiso para acceder a este sistema”
donde XX se corresponderá con el nombre que haya sido escrito

5. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en cascada
Especificación de requisitos
R6: Cuando no se haya introducido ningún valor para el nombre se mostrará
el mensaje: “Debe rellenar la información sobre su nombre”
R7: Cuando no se haya introducido ningún valor para la palabra de paso se
mostrará el mensaje: “Debe rellenar la información sobre la palabra de
paso”
R8: Cuando el usuario esté autorizado se mostrará una pantalla con el
mensaje: “Bienvenido XX” donde XX se corresponderá con el nombre que
haya sido escrito
R9: El sistema permitirá tres intentos para acceder como usuario identificado.
R10: Después del tercer intento el sistema quedará bloqueado durante cinco
minutos y se mostrará el mensaje “Terminal bloqueado. Quedan: YY
minutos” donde YY representa el número de minutos que resten de
bloqueo.
R11: No pueden existir dos pares nombre y clave repetidos en el sistema.

6. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en cascada
Fase de Análisis
– Se va a plantear como solución una visión
estructurada basada en diagramas
Entidad/Relación y diagramas de flujo de datos

7. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en Cascada
Modelo Entidad/Relación
– Sólo aparece una entidad que es Usuario con dos
atributos:
Nombre: de tipo cadena de caracteres de tamaño 15
Palabra de paso: de tipo cadena de caracteres de tamaño
8

8. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en cascada
Diagramas de flujos de datos
Contexto Nivel 1

9. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en Cascada
Diagramas de
Estructuras

10. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en Cascada
Diseño de pantallas Error1
Error3
Error2
Entrada
Bloqueado

11. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en Cascada
Plan de pruebas
– Deberán realizarse las siguientes pruebas
1. Dejar nombre y palabra de paso vacía, el resultado esperado es
la pantalla Error1
2. Dejar palabra de paso vacía, el resultado esperado es la pantalla
Error2
3. Poner un nombre y una palabra de paso incorrecta, el resultado
esperado es la pantalla Error3
4. Poner un nombre y una palabra de paso correcta, el resultado
esperado es la pantalla Entrada
5. Poner tres veces un nombre y palabra de paso incorrecta, el
resultado esperado es la pantalla Bloqueado

12. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación de Desarrollo Incremental
Se va a desarrollar el proyecto en dos fases:
– Fase 1: Identificación de usuario
– Fase 2: Mensaje de error de acceso detallado

13. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
FASE 1. Identificación de usuarios
Especificación de requisitos.
– Se han detectado los siguientes requisitos:
R1: El sistema debe permitir la identificación de usuarios
R2: Los usuarios están identificados por su nombre y palabra de paso. En
nombre no excederá la longitud de 15 caracteres y la palabra de paso de
8.
R3: Es obligatorio que tanto el nombre como la palabra de paso sean
cumplimentados por el usuario
R4: Deberá comprobarse que el nombre de usuario y la palabra de paso se
corresponden con un usuario con autorización para acceder al sistema,
esta información ya habrá sido incorporada previamente al mismo
R5: Cuando el usuario no esté autorizado se mostrará el mensaje de error
XX “ no tiene permiso para acceder a este sistema” donde XX se
corresponderá con el nombre que haya sido escrito

14. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación en cascada
Especificación de requisitos
R6: Cuando el usuario esté autorizado se mostrará una pantalla con el
mensaje: “Bienvenido XX” donde XX se corresponderá con el nombre que
haya sido escrito
R7: El sistema permitirá tres intentos para acceder como usuario identificado.
R8: Después del tercer intento el sistema quedará bloqueado durante cinco
minutos y se mostrará el mensaje “Terminal bloqueado. Quedan: YY
minutos” donde YY representa el número de minutos que resten de
bloqueo.
R9: No pueden existir dos pares nombre y clave repetidos en el sistema.

15. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Fase de Análisis
– Se va a plantear como solución una visión
estructurada basada en diagramas
Entidad/Relación y diagramas de flujo de datos

16. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Modelo Entidad/Relación
– Sólo aparece una entidad que es Usuario con dos
atributos:
Nombre: de tipo cadena de caracteres de tamaño 15
Palabra de paso: de tipo cadena de caracteres de tamaño
8

17. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Diagramas de flujos de datos
Contexto Nivel 1

18. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Diagramas de
Estructuras

19. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Diseño de pantallas
Error3
Entrada

20. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Plan de pruebas
– Deberán realizarse las siguientes pruebas
1. Poner un nombre y una palabra de paso incorrecta, el
resultado esperado es la pantalla Error3
2. Poner un nombre y una palabra de paso correcta, el
resultado esperado es la pantalla Entrada
3. Poner tres veces un nombre y palabra de paso incorrecta,
el resultado esperado es la pantalla Bloqueado

21. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
FASE 2. Mensaje de error de acceso detallado
Nuevos requisitos.
– Se han detectado los siguientes nuevos requisitos:
R10: Cuando no se haya introducido ningún valor para el
nombre se mostrará el mensaje: “Debe rellenar la
información sobre su nombre”
R12: Cuando no se haya introducido ningún valor para la
palabra de paso se mostrará el mensaje: “Debe rellenar la
información sobre la palabra de paso”

22. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Revisión del Análisis
– El modelo de datos no se ve alterado

23. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Diagramas de flujos de datos
Contexto Nivel 1

24. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Diagramas de
Estructuras

25. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Diseño de pantallas Error1
Error3
Error2
Entrada
Bloqueado

26. Ingeniería del Software © 2005Departamento de Organización y Estructura de la Información.
Universidad Politécnica de Madrid
Aproximación Incremental
Plan de pruebas
– Deberán realizarse las siguientes pruebas
1. Dejar nombre y palabra de paso vacía, el resultado esperado es
la pantalla Error1
2. Dejar palabra de paso vacía, el resultado esperado es la pantalla
Error2
3. Poner un nombre y una palabra de paso incorrecta, el resultado
esperado es la pantalla Error3
4. Poner un nombre y una palabra de paso correcta, el resultado
esperado es la pantalla Entrada
5. Poner tres veces un nombre y palabra de paso incorrecta, el
resultado esperado es la pantalla Bloqueado