Análisis y modelado de sistemas de

software

Análisis de Requerimientos

Blanca A. Vargas Govea – vargasgovea@itesm.mx – Enero 29, 2013

Objetivos

2

• Conocer y aplicar las técnicas de análisis

de requerimientos

• Conocer y aplicar el estándar SRS830-

1998 IEEE

Ciclo de vida del desarrollo de sistemas

3

Fases

Análisis

Determinación de

requerimientos

Modelado funcional

Modelado estructural

Modelado de comportamiento

Diseño

Implementación

4

La fase de análisis contesta las preguntas de

¿quién usará el sistema?, ¿qué es lo que hará

el sistema? y ¿dónde? y ¿cuándo? será usado.

Análisis

5

Toma las ideas generales

en la solicitud del sistema

y se van refinando

En esta fase es muy fácil

que haya cambios pues

poco o ningún trabajo se

ha hecho aún

Determinación de requerimientos

6

Propósito: convertir la

explicación de alto nivel

de los requerimientos del

negocio en una lista

precisa de requerimientos

que puedan usarse como

entradas al resto del

análisis

Determinación de requerimientos

7

Paso crítico pues a partir

de aquí, los elementos del

sistema emergen

Más de la mitad de las

fallas son debidas a

problemas con los

requerimientos

Olvidé decir

que tenía que

ser posible

acceder vía

Web

Determinación de requerimientos

8

Requerimiento: es una

declaración de lo que el

sistema debe hacer o qué

características debe tener

Se enfocan en las

necesidades del usuario de

negocios

Se les conoce como

requerimientos de

negocios o requerimientos

de usuario

Definición de requerimientos

9

Reporte en texto que lista

los requerimientos

funcionales y no

funcionales en cierto

formato

Propósito: definir el

alcance del sistema

10

Técnicas de recolección de requerimientos

Técnicas de recolección de requerimientos

11

Analista → detective

Usuarios →

sospechosos elusivos

El analista debe

reconocer claves que

no siempre son obvias

Técnicas de recolección de requerimientos

12

Los mejores analistas usan varias técnicas

El objetivo es asegurarse de que los procesos y necesidades del nuevo sistema se entiendan bien antes de ir al diseño

Incluir a todas las partes interesadas:

Personas que pueden afectar al sistema

Personas que serán afectadas por el sistema

Si no, la persona puede sentirse relegada y puede

originar problemas durante la implementación

No me tomaron en

cuenta cuando dije que

los cacahuates eran

importantes

Técnicas de recolección de requerimientos

13

1. Entrevistas 2. Sesiones

JAD

3. Cuestionarios

4. Análisis de documentos

5. Observación

Join Application

Development

Cada técnica tiene

sus propias fuerzas

y debilidades

1. Entrevista

14

Técnica más común

Se hace generalmente 1-1

Selección de personas a entrevistar

Diseño de las preguntas

Preparación para la entrevista

Conducción de la entrevista

Seguimiento

Selección de personas a entrevistar

15

Calendario de entrevistas

Las personas se

seleccionan de acuerdo a

las necesidades del analista

Ordenar por prioridad y

elaborar la lista

Diseño de preguntas para entrevista

16

Tipos de preguntas

Cerradas

Abiertas

Exploratorias

Preguntas cerradas

17

Requieren una respuesta

específica

Ejemplo: ¿cuántas

solicitudes de tarjeta de

crédito reciben al día?

Incorrecta: ¿reciben

muchas solicitudes?

¿cuántas

órdenes

telefónicas se

reciben por

día?

¿cuántos

clientes hacen

pedidos en una

semana? ¿qué

información

falta en los

reportes

mensuales de

ventas?

Preguntas abiertas

18

Permiten que el

entrevistado explique

Dan a la persona mayor

control sobre la

información

¿qué piensa del

sistema actual?

¿qué

problemas

enfrenta

regularmente? ¿qué mejoras

le gustaría que

tuviera el

nuevo sistema?

Preguntas exploratorias

19

Dan seguimiento a lo que

se ha discutido para

aprender más

Alientan al entrevistado a

profundizar o confirmar la

información

¿por qué? ¿me puede dar

un ejemplo?

¿me podría

explicar con

mayor detalle?

Diseño de preguntas para entrevista

20

No se debería preguntar

información que está

disponible en otras

fuentes, por ejemplo, en

documentos

Ningún tipo de pregunta

es mejor que otra, se

recomienda combinarlas

Pero si eso

que quiere

saber viene en

los manuales…

Estrategias

21

Top-down: de lo general a lo específico

Bottom-up: de lo específico a lo general

Top-down es la apropiada para la mayoría de las entrevistas

Bottom-up es preferible cuando el analista ya tiene mucha información y solamente necesita llenar vacíos

Preparación para la entrevista

22

Preguntas, orden de los

entrevistados

Confirmar el área de

conocimiento del

entrevistado

Tomarse el tiempo para

preparar preguntas

cerradas

Riesgo de no hacerlo:

requerir una nueva

entrevista

Creo que ya

tengo todo

listo

Conducción de la entrevista

23

Inspirar confianza en el

entrevistado

Iniciar con una explicación

del por qué se realiza

Escribir todo

Grabar o filmar: depende

de las políticas. Puede ser

intimidante

Explicar que seguirá

No hacer promesas sobre

el nuevo sistema

Seguimiento

24

Elaboración de reporte

Tiempo: dentro de las 48

horas después de la

entrevista

2. JAD (Joint Application Development)

25

Técnica que permite a los grupos de desarrollo, administración y clientes trabajar juntos para identificar los requerimientos del sistema

Desarrollada por IBM a finales de los 70s

Proceso estructurado en el cual se reúnen de 10 a 20 personas bajo la dirección de un facilitador

Duración: horas, días o semanas

Problemas tradicionales asociados a los grupos

JAD electrónico

3. Cuestionarios

26

Conjuntos de preguntas

Se usan cuando hay un gran número de personas de las cuales se necesita su información y opiniones

Aplicados comúnmente para sistemas cuyo uso es externo a la organización (clientes y vendedores) o cuyos usuarios están en diversas ubicaciones geográficas

Impresos, correo electrónico, vía Web

1. Empezar con preguntas interesantes y

no amenazadoras

2. Agrupar las preguntas en secciones

3. No poner asuntos importantes al

inicio

4. No saturar una página con muchas

preguntas

5. Evitar las abreviaciones

6. Preguntas objetivas, sin sesgo o

sugestivas

7. Poner número a las preguntas para

evitar confusiones

8. Probar el cuestionario para

identificar preguntas confusas

9. Proporcionar anonimidad a los que

responden

Buen diseño de cuestionarios

4. Análisis de documentos

27

Revisión de documentos

existentes

Reportes

Memorándums

Manuales de políticas

Manuales de entrenamiento

Gráficas de la organización

Buscar indicadores de lo

que debería cambiarse

5. Observación

28

Ver el proceso en

ejecución

Es un complemento a las

entrevistas

Compórtate,

estás en

inspección

Tabla de técnicas de recolección de requerimientos

29

Entrevistas JAD Cuestiona

rios

Análisis de

documentos

Observación

Tipo de

información

Sistema-actual,

mejoras,

sistema-futuro

Sistema-actual,

mejoras,

sistema-futuro

Sistema-

actual,

mejoras

Sistema-

actual

Sistema-

actual

Profundidad de

la información

Alta Alta Media Baja Baja

Alcance de la

información

Baja Medio Alta Alta Baja

Integración de

la información

Baja Alta Baja Baja Baja

Involucramient

o del usuario

Medio Alto Bajo Baja Baja

Costo Medio Bajo-Medio Bajo Baja Bajo-Medio

30

Uso de estándares

Beneficios de usar estándares

31

Habilidad de aplicar

metodologías de

mantenimiento y

desarrollo de software y

procedimientos de alto

nivel profesional

Mejorar el entendimiento

mutuo y coordinación

entre equipos de

desarrollo

Mayor cooperación entre

el desarrollador de

software y participantes

externos

Mejor entendimiento y

cooperación entre

proveedores y usuarios

Estándar SRS830-1998 IEEE

32

SRS (Software Requirements Specification)

Descripción completa del comportamiento de un sistema

Puede incluir casos de uso que describan interacciones

del usuario con el software

SRS830-1998 IEEE captura correcta y completamente los

requerimientos y necesidades de un sistema de software y

las expectativas de los usuarios potenciales

Actividad 5: individual Tarea 5: equipo

33

Eres el analista encargado de

desarrollar un nuevo sistema

para una tienda de libros

(dentro de la institución) en la

cual los estudiantes puedan

ordenarlos online y les sean

entregados en su casa o salón

de clases. Diseña un plan de

recolección de información

para el sistema.

Revisar el documento correspondiente al estándar SRS830-1998 IEEE y preparar la forma con la información de su proyecto. Anexo un ejemplo. En la página están los siguientes documentos:

SRS830.pdf

SRSExample-webapp.doc

No es necesario incluir casos de uso(por ahora).

Fecha de entrega: Febrero 1, 2013

Avisos

34

Próximo Viernes 1 de

Febrero, me ausentaré.

Sí habrá actividades a

realizar para esa sesión.

Se pondrán las actividades

en la página y el trabajo se

enviará por correo en el

horario correspondiente a

la clase.

El primer examen es el

Viernes 8 de Febrero.

Referencias

35

Dennis, Alan., Systems analysis and design with UML version 2.0 : an object-

oriented approach / Alan Dennis, Barbara Haley Wixom, David Tegarden.,

2nd ed., Hoboken, NJ : J. Wiley, 2005

Schach Stephen R., Introduction to object-oriented analysis and design,

Boston, Mass. ; Mexico City : McGraw-Hill, 2004