Professional Documents
Culture Documents
Repaso – Ingeniero de
Software
Análisis y Diseño de
z Un Ingeniero de Software debe tener dominio
Sistemas sobre un amplio espectro de actividades.
Dpto. Ciencias e Ingeniería de la Computación z Habilidades interpersonales.
Universidad Nacional del Sur
z Las diferentes personas que interactúan con
Clase 5 – Jugadores y Definición de el sistema se pueden clasificar:
Requerimientos
z usuarios,
Lic. María Mercedes Vitturini
[mvitturi@cs.uns.edu.ar]
z gerentes, auditores,
z analistas y diseñadores, programadores,
1er. CUATRIMESTRE 2006 personal de operación, etc.
Análisis y Diseño de Sistemas - Clase 5 2
Participantes en el desarrollo
Repaso de software
z El desarrollo de sistemas puede estar a
cargo de (relación equipo de Cliente
Patrocina el desarrollo $$$, necesidades
desarrollo/empresa): del sistema.
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
1
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Usuarios
Usuarios Operativos
Usuarios Ejecutivos
z Tendrán contacto diario con el nuevo sistema. Usuarios Ejecutivos
z Se interesan por funciones e interfaz. z Dan iniciativa al proyecto.
z Tienen una visión local. z Se interesan por estrategias de mercado y
z Manejan términos físicos. ganancias/pérdidas.
Usuarios Supervisores z Tienen una visión global del sistema.
z A veces fueron usuarios operacionales. z Están familiarizados con modelos abstractos.
z Les interesa el aumento de productividad que
z Les interesa:
pueda darles el nuevo sistema.
z La información que puedan obtener del sistema.
z Puede negarse a que se entreviste a sus
operadores.
z Tiene una visión similar al usuario operador.
Análisis y Diseño de Sistemas - Clase 5 7 Análisis y Diseño de Sistemas - Clase 5 8
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
2
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Análisis y Definición
Analista
El equipo de Requerimientos
¿Por qué son importantes los ¿Por qué son importantes los
requerimientos? (lectura) ... requerimientos? (lectura) ...
Los principales factores fueron: … Notemos que cierta parte de las etapas de la
z Requerimientos incompletos (13,1%). extracción, la definición, y la gestión del proceso de
z Falta de compromiso del usuario (12,4%). los requerimientos participaron en casi todas estas
z Falta de recursos (10,6%).
causas. La falta de cuidado en la comprensión, la
documentación y la gestión de los requerimientos
z Expectativas no realistas (9,9%).
puede llevar a una gran cantidad de problemas:
z Falta de soporte ejecutivo (9,3%).
construir un sistema que resuelve el problema
z Requerimientos y especificaciones cambiantes equivocado, que no funciona como se espera, o que
(8,7%). presenta dificultades para que los usuarios puedan
z Falta de planeamiento (8,1%). comprenderlo y utilizarlo. Es más un proceso de
z Fin de la necesidad del sistema (7,5%). requerimientos mediocre puede en realidad resultar
muy caro.
Análisis y Diseño de Sistemas - Clase 5 17 Análisis y Diseño de Sistemas - Clase 5 18
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
3
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
4
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Ejemplo Requerimientos
z Supongamos una aplicación para proveer
servicios de correo electrónico: z Los requerimientos se agrupan en: Mo
d
z Requerimientos FUNCIONALES. Ca elo
z Requerimientos mandatorios: so
s
de
Us d e
z Facilidades para enviar y recibir mensajes, crear nuevos z Identificar
actores. o
mensajes, responder mensajes, etc. z Identificar
necesidades funcionales.
z Requerimientos deseables: z Revisar que no existan conflictos.
z Contar con un libreta de direcciones, facilidades filtrar z Requerimientos NO FUNCIONALES.
mensajes, etc.
z Identificar necesidades no funcionales.
z Requerimientos no prioritarios:
z Revisar que no existan conflictos
z Mostrar los mensajes con distinto tipo de letra según el
remitente.
Análisis y Diseño de Sistemas - Clase 5 27 Análisis y Diseño de Sistemas - Clase 5 28
Requerimientos NO
Requerimientos FUNCIONALES FUNCIONALES
z Un requerimiento funcional describe una interacción z Un requerimiento no funcional describe una
entre el sistema y su ambiente. restricción sobre el sistema que limita nuestras
z Para determinar los requerimientos funcionales se elecciones en la construcción de una solución al
deciden cuáles son los estados aceptables para el problema.
sistema. z Estas restricciones limitan la selección del lenguaje,
z Describen cómo debe comportarse el sistema ante plataforma, etc., sin embargo, la selección se realiza
determinados estímulos. en la etapa de diseño.
z Ejemplo: z Ejemplos:
z para un sistema de alumnos: ¿Cuándo un alumno pierde su z El sistema debe funcionar en el servidor..., el informe debe
regulariadad? ¿Cuándo ocurre? ¿Se generan reportes? salir después de 2 horas de..., las consultas en mostrador
no deben demorar más de...
Análisis y Diseño de Sistemas - Clase 5 29 Análisis y Diseño de Sistemas - Clase 5 30
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
5
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Propósito de los
requerimientos Extraer requerimientos
Algunos consejos
z Los requerimientos sirven tres propósitos: z Revisar la situación actual.
z Permiten que los desarrolladores expliquen cómo z Trabajar en el ámbito del usuario para comprender
han entendido lo que el cliente pretende del el contexto, los problemas y las relaciones.
sistema.
z Entrevistar a los usuarios actuales y potenciales.
z Indican a los diseñadores qué funcionalidad y z Realizar demostraciones de cómo podría funcionar
características va a tener el sistema resultante. el sistema.
z Indican a los testeadores qué demostraciones z Investigar los documentos existentes.
llevar a cabo para que el cliente se convenza de
z Realizar lluvia de ideas con los usuarios actuales y
que el sistema que se le entrega es lo que había potenciales.
solicitado.
z Observar las estructuras y los patrones.
Análisis y Diseño de Sistemas - Clase 5 31 Análisis y Diseño de Sistemas - Clase 5 32
Entrevistas – Consejos
Prácticos Consejos prácticos ...
z Estudiar previamente el dominio del problema. z Durante la entrevista:
z Determinar el objetivo y contenido de la entrevista. z Mantener la entrevista en foco.
z Seleccionar a las personas que se va a z Al finalizar, leer las conclusiones.
entrevistar. z Consensuar próximos pasos.
z Concertar la entrevista por anticipado. Indicar la z Solicitar ejemplos de documentos fuentes, salidas
del sistema, pantallas.
duración de la entrevista.
z Fijar roles en el equipo: secretario de actas,
controlador de tiempos, moderador
z Ser puntual – Respetar tiempos.
Análisis y Diseño de Sistemas - Clase 5 33 Análisis y Diseño de Sistemas - Clase 5 34
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
6
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Funcionalidad y
Usuarios y factores humanos Documentación
z ¿Quién usará el sistema? z Funcionalidad
z ¿Habrá varios tipos de usuarios? z ¿Qué hará el sistema?
z ¿Cuál es el nivel de habilidad de cada tipo de z ¿Cuándo lo hará?
usuario? z ¿Existen varios modos de operación?
z ¿Qué clase de entrenamiento requerirá cada tipo de z ¿Cómo y cuándo se puede cambiar o mejorar un sistema?
usuario? z ¿Existen restricciones de la velocidad de ejecución, tiempo
z ¿Cuán fácil le será a un usuario comprender y utilizar de respuesta o rendimiento?
el sistema? z Documentación
z ¿Cuán difícil le resultará a un usuario hacer un uso z ¿Cuánta documentación se requiere?
indebido del sistema? z ¿Debe estar en línea, en papel, o en ambos?
z ¿A qué audiencia está orientado cada tipo de información?
Análisis y Diseño de Sistemas - Clase 5 41 Análisis y Diseño de Sistemas - Clase 5 42
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
7
Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación
Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2006.
Datos Recursos
z ¿Cuál será el formato de los datos tanto para entrada z ¿Qué recursos materiales, personales o de otro tipo
como para salida? se requieren para construir, utilizar y mantener el
sistema?
z ¿Cuán a menudo serán recibidos o enviados?
z ¿Qué habilidades deben tener los desarrolladores?
z ¿Cuán exactos deben ser?
z ¿Cuánto espacio físico será ocupado por el sistema?
z ¿Con qué grado de precisión deben hacerse los z ¿Cuáles son los requerimientos de energía,
cálculos? calefacción o acondicionamiento de aire?
z ¿Cuántos datos fluyen a través del sistema? z ¿Existe un cronograma prescripto para el desarrollo?
z ¿Debe retenerse algún dato por algún período de z ¿Existe un límite sobre la cantidad de dinero a gastar
tiempo? en el desarrollo o en hardware o en software?
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
8