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.

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.

z Un grupo de desarrollo dentro de la empresa.

Obligación
z Contratarse a una empresa externa. contractual
z Pueden hacerse desarrollos para usuarios no Usuario
Usa el sistema. Necesidades
conocidos (paquetes).
z Según la alternativa las comunicaciones van Sistema de
Desarrollador
Construye el
Software
a ser diferentes. sistema.

Análisis y Diseño de Sistemas - Clase 5 3 Análisis y Diseño de Sistemas - Clase 5 4

Usuarios Clasificación de los Usuarios

z Persona/s para la que se construye el
sistema (“clientes”o “dueños del z Por categoría de trabajo
sistema”) z Usuarios Operativos.
z Entrevistar. z Usuarios Supervisores.
z Conformar. z Usuarios Ejecutivos.
z Existen sistemas donde no se conoce z Por nivel de experiencia en proyectos de
al usuario. desarrollo de software.
z Esto acarrea malos entendidos.
z Amateur.
z En estos casos es importante
z Novato.
documentar.
z Experto.
Análisis y Diseño de Sistemas - Clase 5 5 Análisis y Diseño de Sistemas - Clase 5 6

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

Gerentes (Clientes) Ejemplo

z Cuanto mayor sea el nivel de gerencia menos le z Para el desarrollo de un portal educativo para
interesará la tecnología informática. la UNS. Distintos niveles de usuarios:
z Sus prioridades pueden estar en conflicto con la z Alumnos.
de los usuarios. z Docentes de cátedra.
z Diferentes gerentes pueden tomar posiciones z Secretarios Académicos de Departamentos.
encontradas con relación al proyecto. z Rector
z Tienen la decisión sobre el futuro del proyecto.
z Les interesa las nuevas posibilidades de
negocio.
Análisis y Diseño de Sistemas - Clase 5 9 Análisis y Diseño de Sistemas - Clase 5 10

Auditores Personal de Operación

z Personal de control de calidad. z Responsables de la red, sistemas de
z Verifican que se respeten estándares. hardware,de backups.
z Tener en cuenta: z La comunicación solo se requiere para
z Pueden aparecer en juego tarde. coordinar tareas.
z Revisan modelos.
z Se ocupan demasiado de las formas.

Análisis y Diseño de Sistemas - Clase 5 11 Análisis y Diseño de Sistemas - Clase 5 12

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

El equipo de desarrollo de Diseño del Sistema

Diseñador
z Analista: trabaja con el cliente desglosando en desarrollo Diseño de
requerimientos separados lo que el cliente desea. Programas Programador
z Diseñador: a partir de los requerimientos Implementación de
documentados, generan una descripción de lo que programas

el sistema debe hacer. Prueba de

programa Testeador
z Programadores: a partir del diseño escriben el
código. Prueba de Sistema
z Testeadores: trabajan con el equipo de
implementación para verificar que el sistema se Entrega del Sistema
Capacitador
comporta de acuerdo a la especificación.
Análisis y Diseño de Sistemas - Clase 5 13 Mantenimiento
Análisis y Diseño de Sistemas - Clase 5 14

¿Por qué son importantes los

Requerimientos
z Cada sistema basado en software tiene un
propósito, usualmente expresado como algo
que el sistema debe hacer.
z Un requerimiento es:
z Una característica del sistema.
z Una descripción de algo que el sistema es capaz de
hacer con el objeto de satisfacer el propósito de
usuarios y cliente.
Análisis y Diseño de Sistemas - Clase 5
requerimientos? (lectura)
En 1994 el Standish Group hizo un estudio sobre 350
compañías y cerca de 8000 proyectos de software para
averiguar cómo les estaba yendo. Los resultados son
desencantadores. El 31% de los proyectos de
software fueron cancelados antes de completarse. Es
más, en las grandes compañías, sólo el 9% de los
proyectos fue entregado en término y dentro del costo
presupuestados; el 16% satisfizo esto, en pequeñas
empresas.
Para comprender el por qué, Standish (1995) pidió a los
participantes en el estudio que explicaran las causas de
los proyectos fallidos. Los principales factores fueron: …
15 Análisis y Diseño de Sistemas - Clase 5 16

¿Por qué son importantes los
requerimientos? (lectura) ...
Los principales factores fueron: …
z Requerimientos incompletos (13,1%).
z Falta de compromiso del usuario (12,4%).
z Falta de recursos (10,6%).
z Expectativas no realistas (9,9%).
z Falta de soporte ejecutivo (9,3%).
z Requerimientos y especificaciones cambiantes
(8,7%).
z Falta de planeamiento (8,1%).
z Fin de la necesidad del sistema (7,5%).
Análisis y Diseño de Sistemas - Clase 5
¿Por qué son importantes los
requerimientos? (lectura) ...
Notemos que cierta parte de las etapas de la
extracción, la definición, y la gestión del proceso de
los requerimientos participaron en casi todas estas
causas. La falta de cuidado en la comprensión, la
documentación y la gestión de los requerimientos
puede llevar a una gran cantidad de problemas:
construir un sistema que resuelve el problema
equivocado, que no funciona como se espera, o que
presenta dificultades para que los usuarios puedan
comprenderlo y utilizarlo. Es más un proceso de
requerimientos mediocre puede en realidad resultar
muy caro.
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.

¿Por qué son importantes los

requerimientos? (lectura) ...
En el trabajo de Boehm y Papaccio se consigna que si
cuesta 1$ localizar y subsanar un problema debido a
requerimientos, durante la etapa de definición; puede
costar 5$ repararlo durante el diseño; 10$ durante la
codificación; 20$ durante la prueba unitaria; y hasta
200$ después de la entrega del sistema.
Conclusión: es rentable tomarse el tiempo que sea
necesario para comprender el problema y su contexto, y
obtener los requerimientos correctos desde el primer
momento.
Ingeniería de Software – Shari Pfleeger – Pág. 157
Análisis y Diseño de Sistemas - Clase 5 19
Requerimientos
z La extracción de requerimientos tiene lugar después
de que es aceptado el estudio de factibilidad.
z El objetivo primario de la extracción de los
requerimientos: la comprensión de lo que los
clientes y usuarios esperan que haga el sistema.
z Los requerimientos deben ser documentados y
revisados con el cliente para comprobar exactitud y
completitud.
Análisis y Diseño de Sistemas - Clase 5 20

El proceso de Extracción de El proceso de determinación de

Requerimientos los Requerimientos
z Fases del proceso de extracción de Definición y
Extracción y Análisis de
requerimientos Requerimientos
Especificación de
Requerimientos
1. Trabajar con clientes y usuarios del sistema para
extraer los requerimientos. Análisis Descrip- Prototipa- Documen-
z Incluye formular preguntas, hacer demostraciones, del ción del do y tación y
prototipos, etc. Problema Problema prueba Validación
2. Documentar los requerimientos.
z Elegir descripciones matemáticas o gráficas. ¿Hemos ¿Estamos ¿La función es ¿Hemos
capturado todo usando las factible? capturado todo
3. Verificar los requerimientos. lo que el usuario técnicas o lo que el usuario
z Validar si son completos, exactos y consistentes. necesita? visiones espera?
correctas?

Análisis y Diseño de Sistemas - Clase 5 21 Análisis y Diseño de Sistemas - Clase 5 22

Extracción de Requerimientos Extracción de requerimientos

z Se trabaja con el cliente para extraer los z La extracción de requerimientos es crítica.
requerimientos. z Se debe analizar el problema antes de
z Formulando preguntas. considerar cualquier solución:
z Presenciando demostraciones de sistemas z Desglosar el problema en piezas más pequeñas
similares.
más fáciles de comprender.
z Desarrollando prototipos.
z Análisis del problema:
z Se capturan los requerimientos en una base de z Identificar las personas, los procesos y
datos o en documentos. recursos involucrados.
z Documentar las relaciones entre ellos
z Se validan los requerimientos.
Análisis y Diseño de Sistemas - Clase 5 23 Análisis y Diseño de Sistemas - Clase 5 24

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.

Extracción de requerimientos Extracción de Requerimientos

z Se interroga a las personas involucradas y se
intenta determinar el límite del sistema.
z Resulta útil clasificar a los requerimientos en:
z Requerimientos que deben ser absolutamente
satisfechos (mandatorios).
z Requerimientos que son muy deseables pero no
indispensables (deseables).
z Requerimientos que son posibles, pero que
podrían eliminarse (no prioritarios).
Análisis y Diseño de Sistemas - Clase 5
z La clasificación de requerimientos es útil para:
z Que los participantes comprendan lo que
realmente se necesita.
z Cuando el proyecto está restringido en tiempo y
recursos, se eliminan los requerimientos de la
tercera categoría, y los de la segunda se
negocian
Recordar: los requerimientos apuntan al propósito del sistema, sin
considerar cómo se va a implementar. Deben concentrarse en el
cliente y en el problema, no sobre la implementación y la solución.
25 Análisis y Diseño de Sistemas - Clase 5 26

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 FUNCIONALES
z Un requerimiento funcional describe una interacción
entre el sistema y su ambiente.
z Para determinar los requerimientos funcionales se
deciden cuáles son los estados aceptables para el
sistema.
z Describen cómo debe comportarse el sistema ante
determinados estímulos.
z Ejemplo:
z para un sistema de alumnos: ¿Cuándo un alumno pierde su
regulariadad? ¿Cuándo ocurre? ¿Se generan reportes?
Análisis y Diseño de Sistemas - Clase 5 29
Requerimientos NO
FUNCIONALES
z Un requerimiento no funcional describe una
restricción sobre el sistema que limita nuestras
elecciones en la construcción de una solución al
problema.
z Estas restricciones limitan la selección del lenguaje,
plataforma, etc., sin embargo, la selección se realiza
en la etapa de diseño.
z Ejemplos:
z El sistema debe funcionar en el servidor..., el informe debe
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 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
z Los requerimientos sirven tres propósitos:
z Permiten que los desarrolladores expliquen cómo
han entendido lo que el cliente pretende del
sistema.
z Indican a los diseñadores qué funcionalidad y
características va a tener el sistema resultante.
z Indican a los testeadores qué demostraciones
llevar a cabo para que el cliente se convenza de
que el sistema que se le entrega es lo que había
solicitado.
Análisis y Diseño de Sistemas - Clase 5
Entrevistas – Consejos
Prácticos
z Estudiar previamente el dominio del problema.
z Determinar el objetivo y contenido de la entrevista.
z Seleccionar a las personas que se va a
entrevistar.
z Concertar la entrevista por anticipado. Indicar la
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
Documentos de requerimientos
z La extracción y el análisis del problema sirve a
dos propósitos diferentes, pero relacionados:
z La extracción permite escribir un documento de
definición de requerimientos (términos que el
cliente entiende).
z La extracción y el análisis permiten escribir la
especificación de requerimientos (términos
técnicos, que habilita el diseño del sistema).
z A veces un único documento sirve para ambos
propósitos.
Análisis y Diseño de Sistemas - Clase 5
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
Extraer requerimientos
Algunos consejos
z Revisar la situación actual.
z Trabajar en el ámbito del usuario para comprender
el contexto, los problemas y las relaciones.
z Entrevistar a los usuarios actuales y potenciales.
z Realizar demostraciones de cómo podría funcionar
el sistema.
z Investigar los documentos existentes.
z Realizar lluvia de ideas con los usuarios actuales y
potenciales.
z Observar las estructuras y los patrones.
31 Análisis y Diseño de Sistemas - Clase 5 32
Consejos prácticos ...
z Durante la entrevista:
z Mantener la entrevista en foco.
z Al finalizar, leer las conclusiones.
z Consensuar próximos pasos.
z Solicitar ejemplos de documentos fuentes, salidas
del sistema, pantallas.
33 Análisis y Diseño de Sistemas - Clase 5 34
Análisis de requerimientos
Revisar
z ¿Los requerimientos son correctos?.
z Cliente y analista deben revisarlos.
z ¿Los requerimientos son consistentes?.
z No poseen inconsistencia ni ambigüedades.
z ¿Los requerimientos son completos?.
z Todos los estados, cambios de estados, entradas,
productos y restricciones están descriptos.
35 Análisis y Diseño de Sistemas - Clase 5 36
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.

Análisis de requerimientos Temas de la clase de hoy

Revisar z Usuarios del Sistema.
z Clasificación.
z ¿Los requerimientos son realistas?
z Requerimientos
z Es posible cumplir con los requerimientos. z Extracción de requerimientos. Fases. Objetivos.
Requerimientos Funcionales y No funcionales.
z ¿Describe cada requerimiento algo que es z Documentación de requerimientos.
necesario para el usuario? z Análisis de Requerimientos.
z Existen requerimientos que se puedan eliminar z Bibliografía.
z ¿Los requerimientos son verificables? z Análisis Estructurado Moderno – Edward Yourdon. Capítulo 3.
z Ingeniería de Software -Teoría y práctica” - Shari L. Pfleeger.
z Se necesitan pruebas que los demuestren Capítulos 1 y 4.

Análisis y Diseño de Sistemas - Clase 5 37 Análisis y Diseño de Sistemas - Clase 5 38

Apéndice Ambiente físico e Interfaces

Tipos de Requerimientos
z Los documentos de definición y especificación
de requerimientos describen cómo el sistema
interactúa con su ambiente, incluyendo los
siguientes aspectos:
z Ambiente físico, Interfaces, Usuarios y factores
humanos, Funcionalidad, Documentación, Datos,
Recursos, Seguridad, Aseguramiento de la calidad.
Análisis y Diseño de Sistemas - Clase 5
z Ambiente Físico
z ¿Dónde está el equipamiento que necesita el sistema para
funcionar?
z ¿Existe una localización o varias?
z ¿Existen restricciones ambientales: temperatura, humedad,
o interferencia magnética?
z Interfaces
z ¿La entrada proviene de uno o más sistemas?
z ¿La salida va a uno o más sistemas?
z ¿Existe una manera prescripta en que deben formatearse
los datos?
z ¿Existe un medio prescripto que los datos deban utilizar?
39 Análisis y Diseño de Sistemas - Clase 5 40

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
z ¿Cuál será el formato de los datos tanto para entrada
como para salida?
z ¿Cuán a menudo serán recibidos o enviados?
z ¿Cuán exactos deben ser?
z ¿Con qué grado de precisión deben hacerse los
cálculos?
z ¿Cuántos datos fluyen a través del sistema?
z ¿Debe retenerse algún dato por algún período de
tiempo?
Análisis y Diseño de Sistemas - Clase 5
Seguridad
z ¿Debe controlarse el acceso al sistema o a la
información?
z ¿Cómo se podrán aislar los datos de un usuario de los
de otros?
z ¿Cómo podrán aislarse los programas de usuario de
los otros programas y del sistema operativo?
z ¿Con qué frecuencia deben hacerse las copias de
respaldo?
z ¿Dónde se almacenarán las copias de respaldo?
z ¿Se deben tomar precauciones contra el fuego, el
daño provocado por agua, o el robo?
Análisis y Diseño de Sistemas - Clase 5
Aseguramiento de la calidad ...
z ¿Existe un tiempo máximo permitido para la
recuperación del sistema después de una falla?
z ¿Qué medidas de eficiencia se aplicarán al uso de
recursos y al tiempo de respuesta?
z ¿Cuán fácil debe ser de mover el sistema de una
ubicación a otra o de un tipo de computadora a otra?
Análisis y Diseño de Sistemas - Clase 5
Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.
Recursos
z ¿Qué recursos materiales, personales o de otro tipo
se requieren para construir, utilizar y mantener el
sistema?
z ¿Qué habilidades deben tener los desarrolladores?
z ¿Cuánto espacio físico será ocupado por el sistema?
z ¿Cuáles son los requerimientos de energía,
calefacción o acondicionamiento de aire?
z ¿Existe un cronograma prescripto para el desarrollo?
z ¿Existe un límite sobre la cantidad de dinero a gastar
en el desarrollo o en hardware o en software?
43 Análisis y Diseño de Sistemas - Clase 5 44
Aseguramiento de la calidad
z ¿Cuáles son los requerimientos para la confiabilidad,
disponibilidad, facilidad de mantenimiento, seguridad, y
los restantes atributos de calidad?
z ¿Cómo deben demostrarse las características del
sistema a terceros?
z ¿Debe el sistema detectar y aislar defectos?
z ¿Cuál es el promedio de tiempo prescripto entre fallas?
z ¿Cómo puede el sistema incorporar los cambios al
diseño?
z ¿El mantenimiento sólo corregirá errores o incluirá
evolución?
45 Análisis y Diseño de Sistemas - Clase 5 46
47
8