IIS Unidad 3A Proceso de desarrollo de software

Introducción a la Ingeniería de Software Carrera de Software
Ph.D. Franklin Parrales 1
22/10/2021
Proceso de desarrollo de
software
Unidad 3A
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Introducción a la Ingeniería de Software

22/10/2021
Objetivo general de la Unidad 3
Describir el proceso de desarrollo de software
mediante las características de las fases de
análisis, diseño y pruebas para identificarlas
dentro de un proyecto de software.

22/10/2021
Contenido
• Análisis de requisitos
• Diseño del software
• Prueba del software
Unidad 3A

22/10/2021
Contenido
– Análisis de necesidades y estudio de viabilidad
del software
– Técnicas de recogida de la información
– Requisitos y análisis de requisitos
– Documentos de especificación de requisitos.
– Análisis de requerimiento: análisis estructurado,
casos de uso

22/10/2021
Stakeholders / Clientes / Usuarios
• Clientes:
– Definir responsable de:
• resolución de conflictos
• validación
– Planificar reuniones de
revisión de avance con el
responsable.
– Definir proceso de resolución
de conflictos pe. en alcance.
• Usuarios:
▪ dividirlos en clases
▪ definir representantes
▪ definir prototipos
▪ acordar responsabilidades y
estrategias de colaboración
con representantes
Stakeholders
Clientes
Usuarios

22/10/2021
Motivación

22/10/2021
Dificultades en la definición de las
necesidades
• Requisitos a veces no reflejan las necesidades
reales de los clientes
• Enunciados son inconsistentes y/o incompletos.
– Realizar cambios sobre los requisitos ya definidos es
muy costoso.
• Pueden existir malentendidos entre los
stakeholders, y los ingenieros de software.
• Imprecisión de los requisitos, lo cual provoca que
sean interpretados de diferentes formas por los
stakeholders.
• Frecuentemente no está clara la frontera entre
requisitos y diseño.

22/10/2021
Las dificultades en proyectos se deben a :
• Requerimientos no explícitos. Las necesidades reales
del usuario no son bien definidas.
• Los cambios en los requerimientos se hacen sin
considerar costos, tiempos, impacto en la calidad.
• No se administran los requerimientos durante el ciclo
de vida del proyecto.
• Mala comunicación entre las partes involucradas en el
proyecto (administrador, desarrollo, diseño, etc.)
• Métodos, técnicas , herramientas no son utilizadas.
• Al cliente no se lo involucra como parte del proyecto.
Se recurre a él al inicio y al final.

22/10/2021
Dificultades en la definición de las
necesidades
• Se trabaja en conjunto con los usuarios y clientes
• Problemas comunes:
– No saben lo que quieren del sistema, sólo en
términos generales, no conocen el costo de sus
peticiones
– Los requisitos están en sus términos y con
conocimiento implícito de su propio trabajo
– Distintos usuarios tienen distintos requisitos, se
deben encontrar todas las fuentes
– Influyen factores políticos
– La prioridad que se da a los requisitos varía con el
tiempo
– Aparecen nuevos requisitos

22/10/2021
Problemas en los requisitos
• La mayor consecuencia es el retrabajo (en
etapas más avanzadas del desarrollo o después
de liberar).
• Ejemplos:
– Poco involucramiento de los usuarios.
– Planes inadecuados – utilizar requisitos muy vagos
para crear planes.
– Recortes en los requisitos del usuario.
– Requisitos ambiguos.
– Gold plating – chapado en oro: requisitos que
creemos que el usuario va a amar.
– No identificar correctamente a los usuarios correctos.

22/10/2021
Brecha en la Comunicación (Scharer ’90)
Según desarrolladores, los usuarios... Según usuarios, los desarrolladores...
no saben lo que quieren no captan las necesidades operativas
no pueden articular lo que quieren ponen excesivo énfasis en aspectos meramente
técnicos
muchas necesidades por motivos políticos pretenden indicarnos cómo hacer nuestro trabajo
quieren todo ya no son capaces de traducir necesidades claramente
establecidas en un sistema
son incapaces de definir prioridades entre
sus necesidades
siempre dicen que no
rehúsan asumir responsabilidades por el
sistema
siempre están pasados del presupuesto
incapaces de dar un enunciado utilizable de
sus necesidades
siempre están atrasados
no están comprometidos con los proyectos
de desarrollo
nos exigen tiempo y esfuerzo aún a costa de las
obligaciones esenciales
no aceptan soluciones de compromiso establecen estándares no realistas para la definición
de requisitos
no pueden mantener el cronograma son incapaces de responder rápidamente a cambios
en las necesidades

22/10/2021
Comunicación
• Presentación de
requisitos
• Lenguaje accesible al
stakeholder
• Nivel de Abstracción
adecuado
• Participación e
integración
• Relacionada con etapa
de modelización

22/10/2021
Estudio de factibilidad (viabilidad):
• Entradas:
– Conjunto de requerimientos de negocio preliminares
– Descripción resumida del sistema
– Contribución pretendida del sistema a los procesos
del negocio
• Salida:
– Informe que indique si se debe realizar o no el
sistema.

22/10/2021
• Llevar a cabo un estudio de viabilidad comprende la evaluación y
recopilación de la in formación, y la redacción de informes.
• La fase de evaluación de la información identifica la información
requerida para contestar las tres preguntas anteriores.
• Una vez que dicha información se ha identificado, se debería hablar con
las fuentes de información para descubrir las respuestas a estas
preguntas.
• Algunos ejemplos de preguntas posibles son:
– ¿Cómo se las arreglaría la organización si no se implementara este sistema?
– ¿Cuáles son los problemas con los procesos actuales y cómo ayudaría un sistema
nuevo a aliviarlos?
– ¿Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos
del negocio?
– ¿La información se puede obtener y transferir a otros sistemas de la organización?
– ¿Requiere el sistema tecnología que no se ha utilizado previamente en la organiza-
ción?
– ¿A qué debe ayudar el sistema y a qué no necesita ayudar?

22/10/2021
Fuentes
-Jefes de departamentos donde se utilizara el sistema
-Ingenieros de software que están familiarizados
-Expertos en tecnología
-Expertos en el área
-Usuarios finales
Informe final:
-Recomendación para realizar o no el sistema
-Proponer cambios en el alcance, presupuesto y/o agenda
-Sugerir requerimientos adicionales

22/10/2021
Entregables usuales. Estudio de
viabilidad
• Descripción breve del sistema propuesto y sus
características.
• Descripción breve de las necesidades del negocio
en el sistema propuesto.
• Propuesta de organización del equipo de
desarrollo y definición de responsabilidades.
• Estudio de los costes, que contendrán
estimaciones groseras de la planificación y
fechas, tentativas, de entrega de los productos.
• Estudio de los beneficios que producirá el
sistema.

22/10/2021
Contenido
del software
casos de uso

22/10/2021
Elicitación de Requisitos
• To elicit: Descubrir, tornar explícito, obtener el máximo
de información para el conocimiento del objeto en
cuestión, en este caso los requisitos.
• Uno de los aspectos más cruciales y desafiantes en el
desarrollo de proyectos de software es la captura de
los requisitos para la aplicación propuesta.
• La elicitación consiste en identificar las fuentes de
obtención de requisitos y luego utilizando técnicas
evocar esas fuentes.
• La captura de requisitos es una actividad humana
intensa que se basa en la participación de los
stakeholders, como fuente principal de obtención de
requisitos.

22/10/2021
La elicitación de requisitos
Adquisición (elicitación) y análisis de requerimientos se refieren a un conjunto de
actividades realizadas para descubrir los requerimientos.
Se realiza después del estudio de factibilidad o viabilidad
No consiste solamente en preguntar a los usuarios lo que quieren !
Requiere un
minucioso
análisis
la
de
organización, el
de aplicación,
procesos que el
utilizará
dominio
y los
sistema

22/10/2021
Guías básicas de recolección de datos
• Enfocarse en identificar las necesidades de los
stakeholders estudiando su comportamiento y sus
herramientas de apoyo.
• Involucrar a todos los grupos de stakeholders
• Involucrar solo a un representante de cada grupo de
stakeholders no es suficiente, especialmente si es un
grupo grande ya que cada uno tendrá su propia
perspectiva de la situación, la tarea, su trabajo y como
otros trabajan con ellos.
• Usar una combinación de técnicas de levantamiento de
datos. Cada técnica involucra cierta clase de
información desde una cierta perspectiva.
• Completar las sesiones de levantamiento de datos con
cosas específicas tales como la descripción de tareas y
prototipos, si están disponibles.

22/10/2021
Grupos/Categorías de Stakeholders

22/10/2021
¿Cuáles son las categorías de los
stakeholders?
Hay tres categorías de actores: clientes, usuarios y otras partes
interesadas
Stakeholders
Clientes
Patrocinador
(Sponsor)
Product
Champions
Usuarios
Usuarios
Directos
Usuarios
Indirectos
Otros
Consejeros Proveedores

22/10/2021
Guías básicas de recolección de datos
• Organizar una sesión piloto, para asegurar que la sesión
de levantamiento de datos esta yendo como se la
planeo. Cualquier dato recolectado durante la sesión
piloto no puede ser tratado igual que los otros datos.
Después de realizar la sesión piloto es probable que
algunos cambios sean necesarios antes de organizar la
sesión real.
• El levantamiento de datos es una actividad muy cara y
que consume mucho tiempo y que usualmente se
restringe por los recursos disponibles.
• Como se registra los datos durante la sesión de
levantamiento de datos cara a cara es tan importante
como la técnica que se usa. Grabación de video, audio y
toma de notas son las principales opciones.

22/10/2021
Técnicas de elicitación
• Técnicas básicas
– Observación in situ
– Inmersión/aprendizaje
– Estudio de la documentación
– Encuestas
• Glosario de términos
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Observación in situ
• La observación in situ consiste en la observación
directa de las prácticas profesionales que se
realizan habitualmente en la organización para la
que se va a desarrollar el software.
• Antes de celebrar una sesión de observación in
situ, se deben escoger un conjunto de prácticas
representativas del resto, que se lleven a cabo
con una frecuencia relativamente alta o que
presenten cierta complejidad de comprensión.
• Además, se debe intentar que los resultados de la
práctica profesional sean observables en el
entorno real de trabajo.

22/10/2021
Observación in situ
• Poco utilizado…
• Antes de usarlo
– Determinar información necesaria
– Comunicar a los involucrados
– Considerar períodos normales y atípicos
– Planificar las anotaciones
▪ Ventajas
▪ Confiable
▪ Muy rico
▪ Desarrolla empatía
▪ Desventajas
▪ Efecto Hawthorne
▪ Cuidado con generalizar
demasiado (sesgo
particular/local)
Efecto Hawthorne: Teoría que proviene de la psicología experimental, que
mantiene que una persona modificará su actitud si se siente observada,
intentando comportarse de la forma que supone que el observador espera.

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Inmersión/aprendizaje
• Existen algunas variantes de la
observación in situ como son:
– la inmersión dentro de la organización para la
que se va a desarrollar el software
– la realización de periodos de aprendizaje por
parte de los ingenieros de requisitos, en las
que:
• la observación pasiva se cambia por una
participación activa en los procesos a
observar como si fuera un miembro más del
personal de la organización bajo estudio.

22/10/2021
Etnografía
• Es una técnica de observación que se usa para entender
los procesos operacionales y ayudar a derivar
requerimientos de apoyo para dichos procesos
• Un analista se adentra en el ambiente laboral donde se
usará el sistema.
• Observa el trabajo diario y toma notas acerca de las
tareas existentes en que intervienen los participantes
• Motivación: Las personas con frecuencia encuentran
muy difícil articular los detalles de su trabajo, porque es
una segunda forma de vida para ellas
– Entienden su trabajo, pero tal vez no su relación con otras
funciones en la organización.
– Los factores sociales y organizacionales que afectan el
trabajo, que no son evidentes para los individuos, sólo se
vuelven claros cuando los percibe un observador sin
prejuicios

22/10/2021
Etnografía
La etnografía es muy efectiva
para descubrir dos tipos de
requerimientos:
1. Requerimientos que se
derivan de la forma en que
realmente trabaja la gente, en
vez de la forma en la cual las
definiciones del proceso
indican que debería trabajar.
2. Requerimientos que se
derivan de la cooperación y el
conocimiento de las
actividades de otras personas

22/10/2021
Etnografía
• La etnografía puede combinarse con la creación de
prototipos.
• La etnografía informa del desarrollo del prototipo, de modo
que se requieren menos ciclos de refinamiento del prototipo.
• Más aún, la creación de prototipos se enfoca en la etnografía
al identificar problemas y preguntas que entonces pueden
discutirse con el etnógrafo.
• Siendo así, éste debe buscar las respuestas a dichas
preguntas durante la siguiente fase de estudio del sistema
(Sommerville et al., 1993).
Análisis
etnográfico
Reuniones
de interrogatorio
Etnografía
enfocada
Evaluación
de prototipos
Desarrollo
del sistema genérico
Prototipo
del sistema

22/10/2021
Etnografía
• Los estudios etnográficos pueden revelar detalles
críticos de procesos, que con frecuencia se
pierden con otras técnicas de adquisición de
requerimientos.
• Sin embargo, debido a su enfoque en el usuario
final, no siempre es adecuado para descubrir
requerimientos de la organización o de dominio.
– No en todos los casos se identifican nuevas
características que deben agregarse a un sistema.
• En consecuencia, la etnografía no es un enfoque
completo para la adquisición por sí misma, y debe
usarse para complementar otros enfoques, como
el análisis de casos de uso.

22/10/2021
Enfoque antropológico (Técnicas de etnografía)
Se integra con el
medio ambiente, el
analista se
convierte en el
cliente.
▪ Ventajas
▪ Visión de dentro para afuera
▪ Visión muy contextualizada
▪ Desventajas
▪ Efecto Hawthorne
▪ Consume mucho tiempo
▪ Poca sistematización

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Investigar antecedentes - Documentación
Lectura de información
• Abarca la lectura de todos los
documentos disponibles en la
organización, intenta identificar
estructuras, hechos y vocabulario
similares.
• Tipo de lectura: diagramas
organizacionales, estándares,
modelos de procesos o manuales
de sistemas existentes.
• Fácil de obtener si hay
documentación, permite manejar
gran volumen.
• Provee información muy dispersa.
Gran trabajo para procesarlo.

22/10/2021
• Procedimientos y reglas son a menudo escritas
en manuales.
• Es una buena fuente de datos acerca de los
pasos envueltos en una actividad y regulaciones
que rigen una tarea.
• No debe ser usado como única fuente.
• Es bueno para entender la legislación, y para
obtener información en el trabajo.
• Este no envuelve el tiempo de los stakeholders,
el cual es un factor limitante en otras técnicas

22/10/2021
• Estudio, muestreo, visitas,…
• Buena forma de comenzar un proyecto
• Interna: estructura de la organización, políticas y
procedimientos, formularios e informes,
documentación de sistemas
• Externa: publicaciones de la industria y comercio,
Encuentros profesionales, visitas, literatura y
presentaciones de vendedores
▪ Ventajas
▪ Ahorra tiempo de otros
▪ Prepara para otros enfoques
▪ Puede llevarse a cabo fuera
de la organización
▪ Desventajas
▪ Perspectiva limitada
▪ Desactualizado
▪ Demasiado genérico

22/10/2021
• Ingeniería reversa
– Requiere que exista un sistema existente con
documentación (o código) disponible.
– Desventajas: no refleja la actualización de la
información, información muy detallada (a un bajo
nivel)
• Reuso
– Debe haber componentes reutilizables disponibles,
se debe definir lo que se va a reutilizar, necesita de
mecanismos de recuperación.
– Análisis de dominio
– Si bien favorece la calidad y la productividad, no
siempre es fácil de lograr en la realidad.

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Encuestas (cuestionario)
• Secuencia de preguntas que
exige un conocimiento mínimo.
• Facilitan la estructuración de
preguntas y un tratamiento
estadístico.
• Limita el tipo de respuestas
• Tienen poca participación e
interacción

22/10/2021
Encuestas (cuestionario)
• Consta de una serie de preguntas diseñadas para
obtener información específica.
• Las preguntas pueden requerir diferentes tipos de
respuestas como son:
– SI / NO
– Opción múltiple
– Largas o comentarios.
• Usualmente los cuestionarios son usados en conjunto
con otras técnicas.
• Pueden dar datos cualitativos o cuantitativos.
• Bueno para contestar preguntas especificas de un grupo
grande de personas o dispersado.

22/10/2021
Encuesta / Cuestionario
• No substituye la entrevista
• Antes de usar el enfoque:
– Determinar la información que se precisa
– Determinar el enfoque más adecuado:
• Abierto, cerrado, combinado
• Múltiple opción, valor en escala, orden relativo
– Desarrollar cuestionario
– Probarlo con perfil típico
– Analizar resultado de las pruebas
• Su principal uso es para validar asunciones y obtener
datos estadísticos sobre preferencias
▪ Ventajas
▪ Economía de escala
▪ Conveniente para quien contesta
▪ Respuestas anónimas
▪ Desventajas
▪ Menos rico
▪ Problemas por no-respuesta
▪ Esfuerzo de desarrollo

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Glosario
• Se lo considera como un diccionario de términos
comúnmente relevantes con respecto al producto
que se construye, se mejora o se compra.
• Los términos del glosario se utilizan a lo largo de
todo el proyecto.
• Su uso es necesario pues establece un
vocabulario común para los términos clave que
ayuda a los miembros del equipo a entender estos
términos.
– Diferentes Stakeholders pueden usar el mismo
término para explicar diferentes cosas
(ambigüedad), o pueden usar diferentes términos
para expresar la misma cosa, causando confusión y
gasto de energía a la hora de comunicar los
requerimientos.

22/10/2021
Beneficios del glosario
• Como resultado de construir un glosario se tiene:
– Proveer un conocimiento compartido del dominio del
problema.
– Permitir a los dueños del negocio informen al
personal técnico acerca de importantes conceptos del
negocio.
– Provee los fundamentos para definir modelos de
requerimientos tales como reglas de negocio,
modelos de datos y casos de uso.
– Ahorra tiempo y esfuerzo durante el desarrollo de
requerimientos, eliminando malos entendidos de lo
que realmente significan los conceptos del negocios.

22/10/2021
Ejemplo de un glosario
Término Definición Alias Ejemplos
Registro de
notas
Proceso que permite que los profesores ingresen las notas de los
estudiantes. Se puedenpresentarlossiguientescasos:
-Nota no ingresada en el sistema
-Nota registrada en el sistema difiere de la nota de la hoja de
resumen de notas.
-Nota de la evaluación difiere de la hoja de resumen denotas.
Registrode
notas
Registrode beca
El registro extemporáneo de becas se da cuando en el Departamento de
becas no se ha ingresado la beca de un estudiante, a pesar de que este ha
cumplido con todos los requisitos que se necesitapara aplicara una beca. Asignación
de beca
Anulación
académica
La anulación académica se presenta cuando el estudiante presenta
repeticiones en determinadas asignaturas (3 en adelante); en esta caso
se realiza una autorización para hacer la anulación del periodo
académico en el que el estudiante reprobó la asignatura solicitada para
anulación. Se debe tener presente que en esta anulación no existe
devolución económica
Anular
asignatura
Digitalización
Proceso por el cual se capturan los datos de un formato físico y se lo
expresa datos en forma digital.
Documento
digital
Cliente
Una persona o organización, interna o externa, quienes tienen la
responsabilidad financiera del sistema. El cliente es el receptor de los
productos desarrollados y sus entregables. Ver también stakeholder Estudiante
Defecto
Una anormalidad dentro de un producto. Ejemplos como: omisión e
imperfecciones encontradas durante fases tempranas del ciclo de vida.
Un defecto puede ser cualquier tipo de novedad que se requiera registrar
y resolverla. Ver también Requerimiento de cambios. Error

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Entrevista Individual / Grupal
• Usar para:
– Entender el problema
de negocio
– Entender el ambiente
de operación
– Evitar omisión de
requisitos
– Mejorar las relaciones
con el cliente
• Pasos para las Entrevistas
– Seleccionar participantes
• Aprender tanto como sea
posible de antemano
– Preparar la entrevista
• Utilizar un patrón de
estructura
– Conducirla
• Apertura, desarrollo,
conclusión
– Enviar un memo con resultado
– Seguimiento
▪ Ventajas
▪ Orientado a las personas
▪ Interactivo/flexible
▪ Rico
▪ Desventajas
▪ Costoso
▪ Depende de las habilidades
interpersonales

22/10/2021
Entrevista – Patrón para conducirla
• Datos de las Personas: usuarios, interesados, disparador del
proyecto
– ¿Qué trabajo realizan? ¿Para quién?
– ¿Qué interfiere con su trabajo?
– ¿Qué cosas hacen su trabajo mas fácil o mas difícil?
• Datos: entradas y salidas clave, datos ya existentes
– Listar las entradas y salidas
– ¿Cuál es el problema? ¿Cómo se resuelve ahora? ¿Como le gustaría
que se resolviera?
• Procesos: propósito, objetivos y metas
– ¿Quién necesita la aplicación?
– ¿Cuántos usuarios la van a usar y de qué tipo?
• Ubicaciones: lugares involucrados, contexto de los usuarios
– Entorno de los usuarios, computadoras, plataformas
– Aplicaciones relevantes existentes
– Experiencia de los usuarios con este tipo de aplicación, expectativas de
tiempo de entrenamiento

22/10/2021
Entrevista – Patrón para conducirla (2)
• Evaluar confiabilidad, desempeño y soporte necesario:
– ¿Cuáles son las expectativas respecto a la confiabilidad?
– ¿Y respecto a la performance?
– ¿Qué tipo de mantenimiento se espera?
– ¿Qué nivel de control y seguridad?
– ¿Qué requisitos de instalación existen?, ¿cómo se distribuye el
software? , ¿debe ser empaquetado?
• Otros
– ¿Existen requisitos legales, regulatorios u otros estándares que deban
ser tenidos en cuenta?
• Factores críticos de éxito:
– ¿Qué se considera una buena solución?
• Tener en cuenta:
– Si el entrevistado comienza a hablar sobre los problemas existentes, no
cortarlo con una próxima pregunta
– Luego de la entrevista y mientras los datos aún están en mente, resumir
los principales req. (aprox. 3) de este entrevistado

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
¿Qué es una reunión?
• Un suceso puntual en que un conjunto de
personas, que puede que no se conozcan
y no se vuelvan a ver, tratan sobre un
tema. Suelen tener un objetivo común.

22/10/2021
Reuniones
• Extensiones de entrevista. Muy activas. De corta
duración e intensas con un determinado foco
– Braisntorm: lluvia de ideas
– Workshop de requisitos: existe un moderador
– JAD(Join application design): se avanza en un
principio de construcción, más organizado y
racional con generación de documentos,
compromisos, fechas.
▪ Ventajas
▪ Favorecen la aparición de
múltiples opiniones,
creación, feedback y
consenso colectivo.
▪ Desventajas
▪ Puede haber dispersión,
incomodidad en el grupo.
▪ El pensamiento es generado
a nivel de grupo, eliminando
problemas particulares.
▪ Altos costo.

22/10/2021
Preparación de una reunión.
• Definir objetivos de la reunión.
• Seleccionar a los participantes.
• Planificar el desarrollo.
• Convocar a los participantes.
• Organizar el material para la reunión.

22/10/2021
Definir objetivos de la reunión.
• ¿Que resultados se desean alcanzar?
• ¿Se puede alcanzar por otro medio?
• Para buen clima, mejor una copas.
• Para informar el teléfono ¿?.
• Objetivos = Resultados
• definidos y anotados
• Priorizar los objetivos.
• Ineludible, además, secundario.
• Titulo, es muy importante.

22/10/2021
Seleccionar a los participantes.
• La reunión depende de ellos.
• Las personas que pueden aportar
– ¿Aportará información útil?
– ¿Aportará ideas?
– ¿Influirá en la decisión?
– ¿Dinamizará la reunión?
– ¿Problemas si no se le invita?
• Cantidad: de 8 a 10 participantes.

22/10/2021
Planificar el desarrollo.
• Crear el orden del día:
– Lista de temas
– Orden en que se abordaran.
– Tiempo asignado a cada tema.
• Detallar mucho el orden del día permitirá
preparar mejor los puntos.
• Si se conocen los tiempos, algunos
participantes solo estarán lo necesario.

22/10/2021
Convocar a los participantes.
• La convocatoria:
– ¿Suscita el interés de los asistentes?
– Debe justificar el porqué.
– Explicara el cómo se desarrollará.
– Informará
• Quien coordinará.
• Los asistentes y su participación.
• Fecha, hora y lugar.
• Debe resultar atractiva...

22/10/2021
Organizar el material para la reunión.
• No deben descuidarse:
– El material necesario para
presentar y distribuir.
– La sala, material de
proyección, limpieza, aire
acondicionado, situación
circular de los asientos,
Papelografos…

22/10/2021
Iniciar la reunión
• Presentar a los participantes.
• Generar un clima de confianza.
• Centrar el tema de la reunión.
• Fijar objetivos.
• Definir los métodos de trabajo.
• Definir el papel del secretario.

22/10/2021
Durante la reunión
• El moderador:
– Invitar a que la gente se exprese.
– Controlar el exceso de posesión de palabra.
– Facilitar un clima de confianza.

22/10/2021
Durante la reunión
• Los participantes:
– Utilizar el uso de la palabra de forma
consciente.
• Estimar el coste horario de una reunión.
– Tomar la palabra cuando se tiene algo que
decir… cualquier argucia es buena.
– No dejar la palabra hasta haber terminado de
decir lo que se desea.

22/10/2021
Finalización de la reunión.
• Hacer una síntesis y que sea
consensuada.
• Analizar la reunión.
• Explicar la forma en que se documentarán
los resultados.
• Dar feedback a los asistentes.

22/10/2021
Resumen
• Las reuniones son necesarias, pero
– A la gente no le gusta ir a una reunión si no
hace falta.
– Es importante invitar a los que hacen falta.
– El objetivo ha de estar claro.
– Las reuniones son muy caras.
– La organización de la reunión llevara a
reuniones más productivas.

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Reuniones para recoger información.
• El que convoca
necesita obtener
información de los
asistentes.
• Ejemplo:
– Responsable de
proyecto y situación
actual para visitar al
cliente.
Pregunta
información

22/10/2021
Joint Application Development (JAD)
• El JAD se basa en organizar reuniones integradas por
miembros del equipo de desarrollo y miembros de la
organización para la que se va a desarrollar el sistema
software.
• Los asistentes incluyen oficiales de administración de alto
nivel, quienes se aseguran de que el producto provea los
reportes y la información requerida al final.
• Durante una sesión de JAD, el coordinador plantea las
cuestiones a discutir para determinar los objetivos y
los requisitos generales del sistema a desarrollar y los
participantes contestan a dichas cuestiones.
– Si quedan temas abiertos, el coordinador de la sesión debe
documentarlo para programar otra reunión en la que se aborden
dichos temas.
– Si ya se dispone de los modelos de negocio del sistema a
desarrollar, este material puede resultar útil para consultar y
aclarar algunos aspectos durante la sesión.

22/10/2021
Componentes básicos de una sesión JAD
Los componentes básicos de una sesión JAD se enumeran a
continuación:
• Patrocinador ejecutivo: el ejecutivo que funda el proyecto, el
propietario del sistema. Deben ser lo suficientemente altos en la
organización para poder tomar decisiones y brindar los recursos y el
apoyo necesarios para el proyecto. Pueden asistir a la sesión de
apertura y clausura.
• Líder / gerente de PROYECTO: generalmente el líder del equipo de
desarrollo de aplicaciones responde preguntas sobre el proyecto con
respecto al alcance, tiempo, problemas de coordinación y recursos.
Pueden contribuir a las sesiones siempre que no inhiban a los
participantes.
• FACILITADOR / LÍDER DE LA SESIÓN: Preside la reunión y dirige el
tráfico manteniendo al grupo en la agenda de la reunión.
– El facilitador es responsable de identificar los problemas que se pueden resolver
como parte de la reunión y los que deben asignarse al final de la reunión para la
investigación de seguimiento y la resolución.
– El facilitador atiende a los participantes y no aporta información a la reunión.

22/10/2021
Componentes básicos de una sesión JAD
• SCRIBE / MODELER / Recorder / Documentation Expert: Registra y
publica las actas de la reunión y no aporta información a la reunión.
• PARTICIPANTES: Clientes del área de negocio afectados directa o
indirectamente por este proyecto, que sean expertos en su campo y
puedan tomar decisiones sobre su trabajo. Son la fuente de información
para la sesión.
• OBSERVADORES: Generalmente miembros del equipo de desarrollo de
aplicaciones asignados al proyecto. Deben sentarse detrás de los
participantes y observar en silencio los procedimientos.
Además de las personas mencionadas anteriormente, cada sesión de JAD
tiene objetivos bien definidos, una agenda y directrices detalladas, ayudas
visuales y un documento final que contiene todas las decisiones tomadas por
el grupo.

22/10/2021
Joint Application Development (JAD)
• Conjunto de reuniones de 2 a 4 días.
• Cuatro principios: dinámica de grupo, uso de técnicas
audiovisuales, organización y documentación WYSIWYG.
• Roles en JAD
– Jefe de JAD: responsable general, controla las reuniones.
– Analista: responsable de la documentación generada.
– Patrocinador ejecutivo: decide si el proyecto se lleva a cabo o no.
– Representantes de los usuarios: directivos o futuros usuarios
finales.
– Representantes de sistemas de información: asesoran sobre las
posibilidades tecnológicas y de coste.
– Especialistas: asesoran en aspectos técnicos o del dominio del
problema.
▪ Ventajas
▪ Trabajo conjunto de
desarrolladores y clientes
▪ Documentación WYSIWYG
▪ Desventajas
▪ Se adapta mal a los horarios de
los clientes y usuarios, siendo
muy compleja de organizar

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Reuniones para generar ideas
• Son reuniones en
las que los
asistentes tienen
total libertad para
expresar sus ideas,
no se suelen criticar
pero si refinar.
Ideas

22/10/2021
Tormenta de ideas (Brainstorming)
• Generación de ideas.
• No se critican
• Creatividad.
• Genera ideas,… pero
para seleccionar…

22/10/2021
Brainstorming
• Desarrollado en 1941 por A. F. Osborne,
el brainstorming fue diseñado para:
– Alentar a expresar ideas
– Diferir el juicio crítico hasta más tarde.
• Todo el mundo ofrece ideas que se
relacionan, se combinan, se mejoran, y se
cambian en otras varias ideas.
• Al final, el grupo está de acuerdo en una
solución final.

22/10/2021
Brainstorming
• La idea es crear un entorno que no inhiba y que
aliente las ideas y pensamientos imaginativos.
• Los dos principios básicos del brainstorming
son:
– 1. La cantidad produce calidad. Cuantas más ideas
más probabilidades de llegar a la solución mejor.
– 2. Diferir el juicio. Es mejor revisar las ideas más
tarde con algo de objetividad.
• Ayuda a reeducar a la gente para que piense
positivamente en las ideas.

22/10/2021
Tormenta de Ideas (Brainstorming)
• Objetivo: Lograr consenso sobre los requisitos
• Ayuda a la participación de todos los involucrados
• Permite pensar en otras ideas
• Un secretario saca notas de todo lo discutido.
– Puede hacer uso de mapas mentales o brainwriting
• Reglas
– No se permite criticar ni debatir
– Dejar volar la imaginación
– Generar tantas ideas como sea posible
– Mutar y combinar ideas

22/10/2021
Tormenta de Ideas – Fase de Generación
• Los principales stakeholders se juntan en un
cuarto.
• Se explican las reglas.
• Se establece el objetivo:
– ¿Qué características esperan en el producto?
– ¿Qué servicios esperan que provea?
Los objetivos permiten decidir cuando terminar.
• Se pide que cada participante escriba sus
ideas, luego las ideas son leídas para que
otros piensen en ideas relacionadas y de esa
forma las ideas mutan y se combinan.

22/10/2021
Tormenta de Ideas – Fase de Reducción
• El secretario lee cada idea y pregunta si es válida
– Si hay cualquier desacuerdo, la idea se queda
• Agrupamiento de ideas
– Nombrar los grupos
• Definición
– Se escribe una breve descripción de lo que la idea significa para
la persona que la escribió
– Ayuda a tener un entendimiento común del requerimiento
– Lleva unos minutos por idea
• Priorización (opcional)
– Test de los $100: Cada persona tiene dinero para comprar
ideas, se ordena según ideas más compradas
• Solo se puede hacer una vez
• Se debe limitar la cantidad a gastar en 1 sola idea

22/10/2021
El procedimiento es:
• 1. Selección del problema, tan específicamente
como sea posible.
• 2. Elija a los participantes
– 6 a 12
– actitud mental positiva y ser unos pensadores fluidos
y flexibles.
– personalidades independientes y fuertes que se
entusiasmen participando y
– sientan una auténtica necesidad de mejorar los
bienes y servicios.

22/10/2021
• 3. Elija el entorno.
– una habitación confortable
– Crear las sensaciones de:
• Urgencia
• Hambre de ideas innovadoras
– permitir descansos frecuentes.

22/10/2021
• 4. Seleccione a un líder del grupo.
• habilidades interpersonales y ser capaz de parafrasear y de
encontrar analogías.
– Prepara por anticipado tanto como sea posible.
– Invita a gente de diversas áreas, Desanima a los observadores,
espectadores e invitados.
– Redacte un orden del día y mándala.
– Emplea variedad de técnicas de creatividad.
– Concéntrese en el asunto.
– Anime absolutamente todas las ideas, y cuanto más
extravagantes mejor.
– Prepárate para volver atrás y manipular ideas
– Enfatiza la contribución única de todo el mundo.

22/10/2021
• 5. Seleccione a un secretario.
– Después del brainstorming, ordenar las ideas en
grupos relacionados para priorizarlas y evaluarlas.
• 6. Seguimiento. celebrar los logros del grupo.
• 7. Evalúe las ideas. Si intenta usted obtener al
mismo tiempo agua caliente y agua fría de un
grifo, todo lo que consigue es agua tibia.

22/10/2021
Sesiones de Trabajo (Workshop)
• Ámbito para las tormentas de ideas
• Preparación
– Venderlo a los posibles miembros de la reunión
– Asegurarse que asisten los stakeholders correctos
– Estructurar la invitación, el lugar, etc.
– Enviar material previo a la reunión
• Doc de requisitos
• Entrevistas, defectos de los sistemas existentes, etc.
• Asegurarse de enviar lo necesario, sin exagerar
– Organizar la Agenda
• Introducción
• Tormenta de ideas – generación
• Tormenta de ideas – reducción
• Priorización
• Resumen

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Casos de Uso
Auxiliar médico
Administrador
Registrar
paciente
Ver
inf. personal Generar
reporte
Exportar
estadísticas
Enfermera
Médico
Ver
el registro
Editar
el registro
Establecer
la consulta

22/10/2021
Casos de Uso
• Formato simple y estructurado de descripción de tareas y
acciones, donde los usuarios y desarrolladores pueden
trabajar juntos
• No son de gran ayuda para identificar aspectos no
funcionales
• Mientras se definen los casos de uso, puede ser un buen
momento para definir pantallas u otros objetos con los que
el usuario interactúa
• Pueden ser usados en el diseño y en el testing del sistema
▪ Usarlo
▪ Cuando el sistema está
orientado a la funcionalidad,
con varios tipos de usuarios
▪ Cuando la implementación se
va a hacer OO y con UML
▪ No son la mejor elección:
▪ Sistemas sin usuarios y con
pocas interfaces
▪ Sistemas dominados
primariamente por requisitos
no funcionales y restricciones
de diseño

22/10/2021
– Encuestas
• Entrevistas
• Reuniones
– JAD
– Lluvia de ideas
• Casos de uso
• Prototipado

22/10/2021
Prototipado
• Implementación parcial, permite a los desarrolladores y
usuarios:
– entender mejor los requisitos
– cuáles son necesarios, deseables
– acotar riesgos
• Prototipo desechable: El propósito es solo establecer que
algo se puede hacer, luego se parte de cero en la
construcción, quedando el conocimiento aprendido
• Prototipo evolutivo: Es implementado sobre la
arquitectura del producto final, el sistema final se obtiene
de evolucionar el prototipo
• Aspectos para los que es frecuente construir prototipos:
– Apariencia y percepción de la interfaz de usuario
– Arquitectura (riesgos tecnológicos, tiempos de respuesta)
– Otros aspectos riesgosos

22/10/2021
Mismos datos, pero…
Ingrese
año: ____
mes: ____
día: ____
Julio 1998
1998 2025
1 31
Ene Dic
Martes 16 Oct. 2002

22/10/2021
Soporte al Usuario
• Sistema de ayuda debe proveer:
– Mensajes de error
• Amables, concisos, consistentes y constructivos, si es
posible incluir sugerencia para correción
– Ayuda en línea
• Páginas web con hipervinculos, ventanas múltiples
• Cuidar la estructura de navegación, si es compleja los
usuarios se pierden
– Documentación de usuario
• Incluyendo secciones de: instalación, descripción
general, descripción funcional, mensajes de error.

22/10/2021
Mensajes de error
Error #27
Identificador de paciente no válido
?
El paciente J. Bates no está registrado
Seleccione:
Pacientes para listado de pacientes registrados
Reintentar para reingresar el nombre del paciente
Ayuda para más información
Pacientes
Mensaje orientado al sistema
Mensaje orientado al usuario
Ayuda Reintentar Cancelar
Aceptar Cancelar

22/10/2021
Cuidado…

22/10/2021
Prototipado: ¿Cuándo usarlo?
• Se puede usar cuando hay un alto grado de
incertidumbre en cuanto a los requisitos o
cuando se necesitan un temprano feedback de
los stakeholders.
• Se puede combinar con otras técnicas, por
ejemplo usar un prototipo para provocar una
discusión y feedback en una técnica de
elicitación grupal o ser la base para un
cuestionario o análisis de protocolo.

22/10/2021
Contenido
del software
casos de uso

22/10/2021
¿Qué es un requisito?
• Es una condición o capacidad que debe cumplir o
poseer un sistema o componente de un sistema
para satisfacer un contrato, Standard, o
especificación o algún otro documento impuesto.
• El conjunto de requisitos forma la base para el
desarrollo de un sistema o una componente de
sistema.

22/10/2021
¿Qué es un requisito?
Propiedades del dominio: “Cosas” en el dominio de aplicación
que son verdaderas independientemente que se construya o
no el sistema de software
Requisitos: “Cosas” en el dominio de aplicación que se desean
sean verdaderas mediante la construcción del sistema de
software
Especificación: descripción de comportamiento (y datos) que
el programa tiene que tener para cumplir los requisitos
– Sólo puede ser descrito en términos de los fenómenos compartidos por
la maquina y el dominio de aplicación

22/10/2021
Requisitos y análisis de requisitos
• Requisitos funcionales
• Requisitos NO funcionales
• Redactando requisitos

22/10/2021
Requerimientos funcionales
• Son declaraciones de los servicios que el sistema
debería proveer, cómo el sistema debería reaccionar
a entradas particulares y cómo debería comportarse
en situaciones particulares.
• Expresan la naturaleza del funcionamiento del sistema
(cómo interacciona el sistema con su entorno y cuáles
van a ser su estado y funcionamiento).
– NOTA: A veces, también es conveniente indicar lo que no
hará el sistema.
• Ejemplos:
– Un usuario podrá buscar en las listas de citas de todas las
clínicas.
– El sistema deberá generar cada día para cada clínica una
lista de pacientes que se espera asistan a la cita durante
ese día.

22/10/2021
Los requerimiento Funcionales definen:
Ejemplos de requerimientos funcionales:
Ejemplos para el sistema de control de maletas
• El sistema debe manejar hasta 20 maletas por segundo
• Si el suministro de corriente falla, el sistema debe apagarse de manera
ordenada en menos de 5 segundo.
• Cada usuario del sistema debe identificarse de manera única utilizando su
numero de empleado de 8 dígitos.
Cuáles entradas debe aceptar el sistema
Cuáles salidas debe producir el sistema
Qué datos debe almacenar el sistema que utilizarán otros sistemas
Qué operaciones debe realizar el sistema
La sincronización y cronometraje de las actividades anteriores.

22/10/2021

22/10/2021
Requerimientos NO funcionales
• Son restricciones a los servicios o funciones
provistas por el sistema, como restricciones de
tiempo, restricciones sobre el proceso de
desarrollo, estándares, etc.
• Generalmente son aplicables al sistema entero y
no a servicios o funciones en particular
• Por lo general:
– El Plan para implementar los requerimientos no
funcionales se detalla en la Arquitectura del
Sistema.
– El de los requerimientos funcionales se especifica
en el Diseño.

22/10/2021
Requerimientos NO funcionales
• Los requerimientos no funcionales:
– Definen las características o cualidades generales
que se esperan de un sistema
– Establecen restricciones sobre el producto, el
proceso de desarrollo de software
– Establecen restricciones externas que el software
debe lograr

22/10/2021
Algunas recomendaciones para determinarlos
Propiedad Medida
Rapidez
Transacciones procesadas por segundo
Tiempo de respuesta al usuario y a eventos
Tiempo de actualizacion de la pantalla
Tamaño
K Bytes
Numero de chips de RAM
Facilidad de Uso
Tiempo de entrenamiento
Número de pantallas de ayuda
Fiabilidad
Número promedio entre fallos
Probabilidad de no disponibilidad
Tasa de Ocurrencia de fallos
Disponibilidad
Robustez
Tiempo de reinicio entre fallos
Porcentaje de eventos que provocan fallos
Probabilidad de corrupcion de los datos
despues de fallos
Portabilidad
Porcentaje de declaraciones dependientes
de objetivos
Número de sistemas objetivo

22/10/2021
Requerimientos de Producto
▪ Eficiencia
– Desempeño (Ejemplo: Numero de maletas por minuto)
– Espacio (Ejemplo: Mínima cantidad de memoria requerida)
▪ Fiabilidad (tiempo mínimo antes de primera falla)
▪ Portabilidad (Puede usarse con otro S.O o con otro HW?)
▪ Usabilidad (Tiempo de entrenamiento requerido)
Requerimientos Organizacionales
▪Entrega (ejemplo: Fecha de entrega, fecha cuando
estará operacional, sesiones de entrenamiento,
actualizaciones)
▪ Implementación
▪ Estándares
Requerimientos Externos
▪Interoperabilidad (Ejemplo: Comunicación con otro
equipo).
▪ Éticos (Ejem: Seguridad para los operadores)
▪ Legislativos (Ejem: Reglas de privacidad)

22/10/2021
Ejemplos de requerimientos NO funcionales
de producto
• De eficiencia:
– El sistema debe ser capaz de procesar N
transacciones por segundo.
– Toda funcionalidad del sistema y transacción de
negocio debe responder al usuario en menos de
5 segundos.
– El sistema debe ser capaz de operar
adecuadamente con hasta 100.000 usuarios con
sesiones concurrentes.
– Los datos modificados en la base de datos deben
ser actualizados para todos los usuarios que
acceden en menos de 2 segundos.

22/10/2021
de producto
• De seguridad lógica y de datos:
– Los permisos de acceso al sistema podrán ser cambiados
solamente por el administrador de acceso a datos.
– El nuevo sistema debe desarrollarse aplicando patrones y
recomendaciones de programación que incrementen la
seguridad de datos.
– Todos los sistemas deben respaldarse cada 24 horas. Los
respaldos deben ser almacenados en una localidad
segura ubicada en un edificio distinto al que reside el
sistema.
– Todas las comunicaciones externas entre servidores de
datos, aplicación y cliente del sistema deben estar
encriptadas utilizando el algoritmo RSA.
– Si se identifican ataques de seguridad o brecha del
sistema, el mismo no continuará operando hasta ser
desbloqueado por un administrador de seguridad.

22/10/2021
de producto
• De seguridad industrial:
– El sistema no continuará operando si la temperatura externa es menor
a 4 grados Celsius.
– El sistema no continuará operando en caso de fuego. (Ej. Un ascensor).
• De usabilidad
– El tiempo de aprendizaje del sistema por un usuario deberá ser menor
a 4 horas.
– La tasa de errores cometidos por el usuario deberá ser menor del 1%
de las transacciones totales ejecutadas en el sistema.
– El sistema debe contar con manuales de usuario estructurados
adecuadamente.
– El sistema debe proporcionar mensajes de error que sean informativos
y orientados a usuario final.
– El sistema debe contar con un módulo de ayuda en línea.
– La aplicación web debe poseer un diseño “Responsive” a fin de
garantizar la adecuada visualización en múltiples computadores
personales, dispositivos tableta y teléfonos inteligentes.
– El sistema debe poseer interfaces gráficas bien formadas.

22/10/2021
de producto
• De dependibilidad:
– El sistema debe tener una disponibilidad del
99,99% de las veces en que un usuario intente
accederlo.
– El tiempo para iniciar o reiniciar el sistema no
podrá ser mayor a 5 minutos.
– La tasa de tiempos de falla del sistema no podrá
ser mayor al 0,5% del tiempo de operación total.
– El promedio de duración de fallas no podrá ser
mayor a 15 minutos.
– La probabilidad de falla del Sistema no podrá ser
mayor a 0,05.

22/10/2021
de producto
• Otros ejemplos de requerimientos de producto
– El sistema será desarrollado para las plataformas PC y
Macintosh.
– La aplicación debe ser compatible con todas las versiones
de Windows, desde Windows 95.
– La aplicación deberá consumir menos de 500 Mb de
memoria RAM.
– La aplicación no podrá ocupar más de 2 GB de espacio en
disco.
– La nueva aplicación debe manejar fuentes del alfabeto en
Inglés, Idiomas latinos (Español, Frances, Portugués,
Italiano), Arábico y Chino.
– La interfaz de usuario será implementada para
navegadores web únicamente con HTML5 y JavaScript.

22/10/2021
de organización
• El procedimiento de desarrollo de software a usar debe estar
definido explícitamente (en manuales de procedimientos) y
debe cumplir con los estándares ISO 9000.
• La metodología de desarrollo de software será Behaviour
Driven Development (BDD) apoyada en Cucumber.
• El sistema debe ser desarrollado utilizando las herramientas
CASE XYZ.
• El proceso de desarrollo se gestionará por medio de una
determinada herramienta web para gestionar el proceso de
desarrollo de software.
• Debe especificarse un plan de recuperación ante desastres
para el sistema a ser desarrollado.

22/10/2021
de organización
• Cada dos semanas deberán producirse reportes gerenciales
en los cuales se muestre el esfuerzo invertido en cada uno de
los componentes del nuevo sistema.
• Las pruebas de software se gestionaran con una herramienta
de gestión de software testing.
• Las pruebas de software se ejecutarán utilizando Selenium y
Ruby como herramienta y lenguaje Scripting para
automatización de software testing.

22/10/2021
externos
• Sistemas de datos médicos: El nuevo sistema y sus
procedimientos de mantenimiento de datos deben cumplir
con las leyes y reglamentos de protección de datos médicos.
• El nuevo sistema se acogerá a las reglas de las licencias
generales públicas (GNU), es decir será gratuito, código
abierto en el que cualquiera podrá cambiar el software, sin
patentes y sin garantías.
• Las páginas web a ser desarrolladas deben cumplir con la ley
de tratamiento en condiciones de igualdad para personas con
discapacidad.
• El sistema no revelara a sus operadores otros datos
personales de los clientes distintos a nombres y números de
referencia.

22/10/2021

22/10/2021
Falta de precisión en los requisitos
• La falta de precisión en los requisitos es la causa
de muchos problemas en la ingeniería de software.
• Los requisitos ambiguos pueden ser interpretados de
diferentes maneras por desarrolladores y usuarios.
Ejemplo:
– Un usuario podrá buscar en las listas de citas de todas las
clínicas.
Búsqueda dentro de
cada clínica por vez
Búsqueda dentro de
todas las clínicas a
la vez
Búsqueda por
nombre y apellido
Búsqueda por hora
de la cita

22/10/2021
Guía para escribir requisitos
• Crear un formato estándar y usarlo para todos los
requisitos.
• Usar un lenguaje de una manera consistente. El
lenguaje usado para requisitos obligatorios debe ser el
mismo que para requisitos deseables.
• Utilizar texto subrayado para identificar las partes
clave de los requisitos.
• Evitar el uso de jerga informática.
• Incluir una explicación (lógica) de porqué es necesario
un requisito.

22/10/2021
• Al describir requisitos se deben tener en cuenta los siguientes
aspectos:
• Ubicación y Entorno Físicos
– dónde, uno o varios, restricciones ambientales
• Interfaces
– Entrada de 1 o + sistemas, Salida a 1 o + sistemas, restricciones
de formato, soporte
• Usuarios y Factores Humanos
– capacidad de cada tipo de usuario, tipo de entrenamiento,
facilidad de uso, posibilidad de mal uso
• Funcionalidad y Restricciones asociadas
– qué debe hacer, cuándo, modos de operación, cómo y cuándo
se puede modificar el sistema, restricciones de velocidad,
tiempo de respuesta, capacidad de proceso

22/10/2021
• Documentación
– cuánta, formato, para quién
• Datos
– formatos E/S, frecuencia, fuentes, destinos, calidad
requerida, precisión en cálculos, flujo en el sistema
• Recursos
– materiales, personal y otros para construir, usar y
mantener el sistema, habilidades de los desarrolladores,
necesidades de espacio y ambientales, calendario
prescrito, limitaciones en presupuesto

22/10/2021
• Seguridad
– control de acceso a las funciones/datos, aislamiento de los
programas, respaldos-frecuencia, disponibilidad-,
seguridad física
• Aseguramiento de la Calidad
– Confiabilidad – tiempo medio entre fallas, robustez,
tolerancia a fallas
– Disponibilidad - tiempo para estar operativo luego de falla-
mantenimiento estando activo- tiempo máximo de no
disponibilidad
– Mantenibilidad
– Seguridad
– Portabilidad

22/10/2021
• Los requerimientos no funcionales…
– han de especificarse cuantitativamente,
siempre que sea posible (para que se pueda
verificar su cumplimiento).

22/10/2021
• MAL:
– Para facilitar el uso del editor gráfico, se
podrá activar y desactivar una rejilla que
permitirá alinear las figuras del diagrama.
Cuando se ajuste la figura al tamaño de la
pantalla, se reducirá el número de líneas de
la rejilla para que no se dificulte la
visualización del diagrama.
• ¿Por qué?
– Amalgama de varios requisitos.

22/10/2021
• BIEN
– El editor permitirá el uso de una rejilla de
líneas horizontales y verticales que
aparecerán dibujadas tras el diagrama.
Justificación: La rejilla facilita la creación de
diagramas cuidados en los que las figuras se
puedan alinear con facilidad
• ¿Por qué?
– Preciso, conciso y justificado correctamente.

22/10/2021
• MAL
– El sistema será lo más fácil de utilizar posible.
– El sistema proporcionará una respuesta
rápida al usuario.
– El sistema se recuperará automáticamente
tras producirse un fallo.
• ¿Por qué?
– Objetivos generales, vagos y abiertos a
distintas interpretaciones

22/10/2021
• BIEN
– Un usuario experimentado debe ser capaz de utilizar
todas las funciones del sistema tras un entrenamiento
de 2 horas, tras el cual no cometerá más de 3 errores
diarios en media.
– Cuando haya hasta 100 usuarios accediendo
simultáneamente al sistema, su tiempo de respuesta
no será en ningún momento superior a 2 segundos.
– Ante un fallo en el software del sistema, no se tardará
más de 5 minutos en restaurar los datos del sistema
(en un estado válido) y volver a poner en marcha el
sistema.
• ¿Por qué?
– Requisitos verificables.

22/10/2021
Algunas recomendaciones para especificar
requisitos NO funcionales
Propiedad Medida
Rapidez
Transacciones procesadas por segundo
Tiempo de respuesta al usuario y a eventos
Tiempo de actualizacion de la pantalla
Tamaño
K Bytes
Numero de chips de RAM
Facilidad de Uso
Tiempo de entrenamiento
Número de pantallas de ayuda
Fiabilidad
Número promedio entre fallos
Probabilidad de no disponibilidad
Tasa de Ocurrencia de fallos
Disponibilidad
Robustez
Tiempo de reinicio entre fallos
Porcentaje de eventos que provocan fallos
Probabilidad de corrupcion de los datos
despues de fallos
Portabilidad
Porcentaje de declaraciones dependientes de
objetivos
Número de sistemas objetivo

22/10/2021
• Problemas habituales:
– La existencia de un requerimiento ha de estar
debidamente justificada (debemos saber por
qué es un requisito del sistema).
– Un requerimiento es, a veces, difícil de
verificar (especialmente, si es un requisito no
funcional).
– Además, si somos incapaces de especificarlo,
¿cómo sabemos que realmente es un
requisito?

22/10/2021
EJEMPLO: REQUERIMIENTOS FUNCIONALES
Matriculación
• La matrícula será realizada de forma interactiva. Se le preguntará al alumno cuál
es el plan de estudios en que desea matricularse (pueden ser varios).
• Se podrá generar una copia impresa de la matrícula (sin valor oficial) en el
ordenador desde donde se realice el proceso de matriculación.
• Se podrá generar el impreso de pago debidamente cumplimentado.
• Para la matriculación se consultarán los datos del expediente y se realizarán las
validaciones necesarias, descritas a continuación…
• Pago de matrícula:
• La aplicación generará un impreso para que el alumno realice el pago
correspondiente a la matrícula en 1 ó 2 plazos (según las fechas
establecidas).
• Si el alumno tiene matrículas de honor de cursos anteriores o disfruta de
algún tipo de beca, la aplicación deberá calcular automáticamente los
descuentos correspondientes…
20
Organizados jerárquicamente
y desglosados en requisitos individuales

22/10/2021
Interfaces
• Hardware: El sistema se debe implementar sobre la infraestructura existente en
las aulas de prácticas de la E.T.S. Ingeniería Informática.
• Software:
• No existe posibilidad de adquirir licencias de software.
• La aplicación deberá funcionar sobre Oracle.

22/10/2021

22/10/2021
Análisis de Requisitos
“El análisis de requerimientos es una
actividad intensiva de comunicación.”
(Pressman, 1992)

22/10/2021
Análisis de Requisitos
• El análisis es “descomponer” un problema
o cosa para ver como trabaja.
• Responde a las preguntas:
– ¿Qué necesita hacer el sistema?
– ¿Cuáles son las funciones, qué reglas de
negocio y lógica deben implementarse?
– ¿Qué información debe contener el sistema?
– ¿Cuáles son las limitaciones bajo las cuales
debe operar el sistema?

22/10/2021
Proceso de análisis de requisitos
1. Identificar al cliente.
2. Entrevistar al cliente.
– Identificar deseos y necesidades.
– Utilizar las herramientas de expresión de requisitos (las
ofrecidas por UML).
– Bosquejar las interfaces de usuario (protocolos y GUIs)
– Identificar las plataformas hardware que debe soportar el
software.
3. Elaborar un documento de los requisitos de usuario
(Debe validarse con el cliente)
4. Inspeccionar los requisitos de usuario.
5. Elaborar los requisitos detallados mediante
documentos gráficos y textuales.

22/10/2021
Contenido
del software
casos de uso

22/10/2021
Recursos para la especificación de
requisitos del sistema
• Para la especificación del sistema se usan tres
tipos de recursos:
– Descripción del proyecto: Documento textual que
describe de forma concisa el objetivo del sistema, su
oportunidad de mercado y el análisis de riesgos.
– Análisis del contexto: Modelo de objetos que identifica
las interacciones externas y los mecanismos de
interacción física entre los actores que constituyen el
entorno y el propio sistema.
– Casos de uso: Recursos UML para describir la
funcionalidad del sistema. Identifican los límites del
sistema a través de la captura de los tipos de usuario, de
los elementos básicos de funcionalidad a través de casos
de uso, y de los protocolos de interacción a través de
diagramas de secuencia o de interacción.

22/10/2021
➢ Definir plantillas estándares para
describir los requisitos.
➢ Usar un lenguaje simple,
consistente y conciso.
➢ Usar diagramas apropiadamente.
➢ Suplementar el lenguaje natural
con otras descripciones de
requisitos.
Sommerville (2002)
FICHA DE REQUISITO
Proyecto: ___________________________
Fecha: __/__/____
Ingeniero de Requisitos: ________________
Descripción:__________________________________
____________________________________________
____________________________________________
____________________________________________
Prioridad: Obligatorio Deseado
Tipo: RF RNF: _____________
Fuente de Información: ________________________
Etapa del Proyecto: ___________________________
Observación: ________________________________________
____________________________________________

22/10/2021
IEEE Std. 830-1998
• El IEEE Std. 830-1998 se encarga de
proporcionar unas normas para la
creación de la Especificación de
Requisitos Software (SRS, Software
Requirements Specification)

22/10/2021
Tabla de contenidos
1. Introducción
1.1 Propósito
1.2 Alcance
1.3 Definiciones, acrónimos
y abreviaturas
1.4 Referencias
1.5 Resumen
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del
usuario
2.4 Restricciones
2.5 Supuestos y
dependencias
2.6 Requisitos futuros
3. Requisitos específicos
3.1 Interfaces externos
3.2 Funciones
3.3 Requisitos de rendimiento
3.4 Requisitos lógicos de la base
de datos
3.5 Restricciones de diseño
3.6 Atributos del sistema
software
Apéndices
Índice
Estándar IEEE Std 830-1998, para la
especificación de requerimientos

22/10/2021
Ejemplo: requerimiento funcional
Número: RF-1
Título: Ingreso de colegiados.
Texto: El sistema debe permitir el ingreso de los datos de los colegiados designados por la Federación
Española de Fútbol.
Tipo: Funcional - Datos
Detalles de
requisitos y
restricciones:
El sistema debe permitir el registro de la siguiente información sobre los colegiados:
• Nombre. Deberá contener un máximo de 32 caracteres, incluyendo mayúsculas y minúsculas.
• Apellido. Deberá contener un máximo de 28 caracteres, incluyendo mayúsculas y minúscula.
• Edad. La edad de los colegiados será únicamente escrita en números.
• Años de Experiencia. Deberá ser escrito solo en números.
• Formación académica. No tendrá un límite de caracteres, contemplará mayúsculas,
minúsculas, números y símbolos.
• Sexo. Indicará si el sexo es femenino o masculino
• Estado de colegiados (habilitado o no habilitado)
• Correo Electrónico. Deberá contener un máximo de 32 caracteres, incluyendo números y
símbolos.
• Usuario. Deberá contener un máximo de 12 caracteres incluyendo minúsculas, mayúsculas,
números y símbolos.
Fecha de revisión
y versión:
26/12/2020
Versión1.0
Prioridad: Alta
Requerimiento
de usuario
Especificación del
requerimiento (req.
de sistema)

22/10/2021
Ejemplo: requerimiento funcional
Número: RF- 2
Título: Registro de propietarios de vehículos
Texto: El sistema deberá permitir registrar nuevos propietarios de vehículos por parte de la secretaria.
Tipo: Funcional – datos
Detalles de
requisitos y
restricciones
:
Para registrar nuevos propietarios de vehículos en el sistema se tendrán en cuenta los siguientes parámetros:
• Nombre del propietario: Máximo de 20 caracteres alfabéticos. Dato tipo String.
• Apellido del propietario: Máximo de 20 caracteres alfabéticos. Dato tipo String.
• Cédula de Identidad del propietario: Máximo de 11 caracteres numéricos. Dato tipo String.
• Número celular del propietario: Máximo de 11 caracteres numéricos. Dato tipo String.
• Número convencional del propietario: Máximo de 8 caracteres numéricos. Dato tipo String.
• Número de placa del coche del propietario. Máximo de 10 caracteres alfanuméricos y especiales. Dato tipo
String.
• Modelo del coche del propietario. Máximo de 30 caracteres alfanuméricos y especiales. Dato tipo String.
• Correo electrónico del propietario. Máximo de 20 caracteres alfanuméricos y especiales. Dato tipo String.
• Tipo de pago. Combo box con 2 opciones.
• Pago domiciliado. Dato tipo String. Máximo 17 caracteres alfabéticos.
• Pago no domiciliado. Dato tipo String. Máximo 20 caracteres alfabéticos
En caso de que el propietario de vehículo tenga domiciliado el pago se agregaran los siguientes datos:
• Nombre de entidad bancaria empleada por el propietario del vehículo. Máximo de 40 caracteres alfabéticos.
Dato tipo String.
• Número de cuenta bancaria. Máximo de 11 caracteres numéricos. Dato tipo String.
Para todos los datos se usará la fuente de texto Arial, tamaño 12.
Fecha de
revisión y
versión:
10/12/2020
Versión1.0
Prioridad: Alta

22/10/2021
Ejemplo: requerimiento NO funcional
Número: RNF – 1
Título: Tiempo de corrección de fallos inesperados en el sistema.
Texto: Se deben corregir los fallos que surjan en el sistema en un tiempo
máximo de 30 minutos tras el surgimiento del fallo.
Tipo: No funcional – Del producto
Detalles de
requisitos y
restricciones:
Ante un fallo en el sistema, no se tardará más de 30 minutos en
restablecer el sistema a un estado operacional y volver a poner en
marcha el sistema.
Fecha de
revisión y
versión:
9/12/2020
Versión1.0
Prioridad: Alta
Requerimiento de
sistema (con jerga
técnica)
Requerimiento
de usuario (sin
jerga técnica)

22/10/2021
Ejemplo: requerimiento NO funcional
Número: RNF – 2
Título: Facilidad de uso del sistema.
Texto: Un usuario del sistema no debe cometer más de tres errores diarios
en media.
Tipo: No funcional – Del producto
Detalles de
requisitos y
restricciones:
Un usuario experimentado debe ser capaz de utilizar todas las
funciones del sistema tras un entrenamiento de 2 horas, tras el cual
no cometerá más de 3 errores diarios en media
Fecha de
revisión y
versión:
9/12/2020
Versión1.0
Prioridad: Alta

22/10/2021
Contenido
del software
casos de uso

22/10/2021
Análisis de requerimiento
• Análisis estructurado
• Casos de uso

22/10/2021
PROCESOS DATOS
Análisis Estructurado
• Métodos Orientados a la Estructura de los Datos
• Métodos de flujo de datos

22/10/2021
– Diagrama de actividades
• Casos de uso

22/10/2021
• ¿Qué son los diagramas de actividad?
–Es una notación que forma parte de UML y que se utiliza
principalmente para modelar procesos de negocio, especificando:
✓ La secuencia de actividades que componen los procesos de
negocio.
✓ Los actores que realizan las actividades (opcional).
✓ La información que fluye de unas actividades a otras
(opcional).
–Dentro del proceso de ingeniería de requisitos, se utilizarán para
modelar los procesos de negocio, tanto actuales como a
implantar, de la organización para la que se va a desarrollar el
sistema software.
–A partir del modelo del negocio al que el sistema software debe
dar soporte, se plantean los objetivos y requisitos del sistema a
desarrollar.
Diagrama de Actividades

22/10/2021
Gestión de Pedidos
Ejemplo:
gestión
de
pedidos
Recibir Pedido
Enviar
Factura
Factura
Recibir
Pago
Satisfacer
Pedido
Pedido
Cerrar Pedido
Producción
Actividad inicial
Indica el comienzo del
proceso de negocio.
Actividad final
Indica el final del
proceso de negocio.
Calles
Permiten especificar qué
actividades hace cada actor.
Nodo de objeto
Representa información
o documentos (objetos)
que se generan en una
actividad y se
consumen en otra.
Comienzo de
paralelismo
Indica que a partir
de ahí se realizan
varias actividades en
paralelo.
Fin de paralelismo
Indica la terminación
de todas las
actividades que se
realizaban en
paralelo.
Transición
Indica que una
actividad ha
terminado y se pasa
a la siguiente.
Flujo de objeto
Representa un
flujo de
información
(objetos) entre
actividades.
Actividad compleja
Son actividades
complejas que
necesitan un
diagrama de
actividades propio
para ser descritas.
Facturación
Servicio al Cliente
Entregar
Pedido
Actividad
Representa un paso
en el proceso de
negocio.

22/10/2021
• Actividades
– Una actividad representa un paso dentro de
proceso de negocio.
• Su nombre, que debe ser siempre una forma
verbal, debe ser representativo y coherente
dentro del proceso de negocio.
• Si una actividad es compleja, puede ser necesario
mostrar su descomposición en actividades más
simples en otro diagrama.
• En cada diagrama de actividades, las actividades
deben tener un nivel de abstracción similar.
• Actividades iniciales y finales
– La actividad inicial, que debe ser única, indica dónde
comienza el proceso de negocio.
– Una actividad final, de las que puede haber varias o
ninguna (proceso sin fin), indica dónde puede
terminar el proceso
Actividad
Actividad
compleja
Actividad
inicial
Actividad
final

22/10/2021
• Transiciones
– Indican la secuencia de actividades que componen el proceso de
negocio.
– Cuando una actividad termina de realizarse se produce la
transición hacia la siguiente actividad.
• Transiciones condicionales
– Indican que la siguiente actividad a realizar depende de
cierta condición.
– Como mínimo y como máximo, sólo puede haber una opción
válida al evaluar la condición
Actividad 1 Actividad 2
– El símbolo de
condición se puede
usar también para
unir varios caminos
condicionales
(opcional).
Entrega de pedido
[otro caso] [urgente]
Entrega
Ordinaria
Entrega
Urgente

22/10/2021
Ejemplo: Cajero ATM
Se abren Flujos
Paralelos
Sincronización
Guarda de
decisión

22/10/2021
Ejemplo
Diagrama de Actividad
para calcular el Fibonacci
de un numero.

22/10/2021
• Paralelismo
– A veces, algunos pasos de un proceso de
negocio se realizan simultáneamente (en
paralelo) o sin un orden definido.
– Para indicar que comienzan varias actividades
a la vez se usa un símbolo de comienzo de
paralelismo (fork), al que llega una transición
y del que salen varias (al menos dos).
– Para indicar que todas las actividades que
se hacían en paralelo han terminado se usa
un símbolo de fin de paralelismo (join), al
que llegan varias transiciones (al menos
dos) y del que sale una sola transición.
– La transición de salida del join sólo se realiza
cuando han terminado todas las actividades
que se realizaban en paralelo.
Realizar Práctica*
Seleccionar
Sistema
Presentar
Práctica
Estudiar
Negocio
Elaborar
Requisitos
Realizar
Modelos
*Proceso muy, muy simplificado.

22/10/2021
• Calles (marcos de responsabilidad)
– La división en calles permite asociar actividades con aquellos actores
que las realizan. Cada calle corresponde a un actor del proceso de
negocio.
Gestión de fondos bibliotecarios
Director Bibliotecario Usuario
Catalogar
nuevo libro
Registrar
préstamo
Leer libro
Registrar
devolución
[libro OK]
Retirar
libro
[libro deteriorado]

22/10/2021
• Flujos de objetos
– Lo normal es que fluya información entre las
actividades de un proceso de negocio.
– En el caso de que resulte interesante mostrar ese flujo (no
siempre lo es), se pueden usar flujos de objetos.
– Si la información de salida de una actividad es la entrada de
otra actividad, se asume que existe una transición implícita
entre ambas.
Aseguramiento de la calidad de losrequisitos
Validación
Verificación
Requisitos
[borrador]
Requisitos
[analizados]
Requisitos
[verificados]
Requisitos
[validados]
Análisis
transiciones implícitas
(no es necesario dibujarlas)

22/10/2021
Ejemplo:
venta
por
caja
Cliente Banco
Incluir compras
del carrito
Calcular tasas
ydescuentos
Recibo
Caja
Carrito
Solicitar
Autorización
Pago
[pago al
contado] [otro caso]
Autorizar
pago
Emitir
Recibo
Comprar y
llenar carrito
Entregar
compras
Venta por caja
Cajero

22/10/2021
• Casos de uso

22/10/2021
• Casos de uso
– Definición de caso de uso
– Conceptos
• Diagramas
• Actores
• Relaciones
• Diagrama de contexto
– Detalle de casos de uso
– Guiones

22/10/2021
Casos de uso
• Casos de uso son ideados por Jacobson a
principios de los noventa.
• Inspirados en el concepto de escenario.
• Escenarios habían sido utilizados para describir
procesos.
Emisor Centralita Receptor
listo( )
tono
marcar_numero
tono_sonando
timbre_sonando
telefono_cogido
para_tono
para_timbre
Ejemplo
de
Escenario

22/10/2021
Definición de casos de uso
• Un caso de uso es la secuencia de transacciones
en un sistema cuya tarea es producir un resultado
con valor medible para un actor del sistema (I.
Jacobson)
– Secuencia de transacciones: Serie de interacciones
entre el sistema y el actor que lo usa.
– Sistema: Entidad encapsulada cuyos requerimientos
han sido descritos (programa, computador)
– Resultado con valor medible: objetivo logrado con
valor no trivial para el actor.
– Actor: Entidad fuera del sistema que interactúa con
este (usuario, otro sistema).

22/10/2021
Definición de casos de uso
• Los casos de uso sirven para encontrar y capturar
los requerimientos (especialmente los funcionales)
• Son descripciones narrativas en lenguaje natural de
los procesos en un formato estructurado de prosa.
• Los casos de uso no son propiamente un elemento
del análisis y diseño orientado a objetos (pueden
ser utilizados en análisis no orientados a objetos).
• Tienen la gran virtud de mantener la información
descrita de forma simple y comprensible por ambas
partes
• Son denominados por un VERBO. Ejemplo:
“Comprar producto”.

22/10/2021
Casos de Uso
• El conjunto de casos de uso puede ser
utilizado para documentar los requerimientos
operacionales del sistema.
• Los casos de uso describen el
comportamiento del sistema bajo la forma de
acciones y reacciones desde el punto de
vista del usuario.
• Los casos de uso describen la funcionalidad
del sistema sin dar detalles de
implementación.

22/10/2021
Ejemplo: Jugar Binario
• Se tiene un juego de dados llamado
“Binario” en que un jugador lanza 2 dados.
Si el resultado suma 7 entonces Gana si
no Pierde.
• Jugar Binario:
– Este caso de uso comienza cuando el jugador
recoge y tira 2 dados.
– Si los puntos suman siete, gana y pierde si
suman cualquier otro número.

22/10/2021
Caso de uso, ejemplo corto
• Recibir pedido en restaurante:
– Un cliente solicita atención (ya leyó la carta).
– El mesero llega a la mesa y anota en su PDA
el número.
– El mesero responde consultas sobre el menú.
– El mesero anota el pedido.
– El Sistema toma razón del pedido final.
• Es una prosa descriptiva (en este ejemplo
faltó escribir el objetivo)

22/10/2021
Casos de Uso
• Los casos de uso permiten que los
desarrolladores puedan comunicarse con
los usuarios del sistema.
• Los casos de uso bien estructurados
denotan comportamientos esenciales
solamente.
• Los casos de uso permiten definir:
– los límites de un sistema, y
– las relaciones entre el sistema y el entorno

22/10/2021
• Casos de uso
– Conceptos
• Diagramas
• Actores
• Relaciones
– Guiones

22/10/2021
Diagramas de casos de uso
• Se utiliza durante la obtención
de requisitos para representar
el comportamiento externo.
• Actores: representan roles, es
decir, un tipo de usuario del
sistema
• Casos de uso: representan
una secuencia de interacción
para un tipo de funcionalidad
• El modelo de casos de uso es
el conjunto de todos los
casos de uso. Es una
descripción completa de la
funcionalidad del sistema y su
entorno.
Pasajero
Compra de pasaje

22/10/2021
Diagramas Casos de Uso
• Es una colección de actores, casos de
uso y las relaciones entre estos.
• Los diagramas de casos de uso son útiles
para:
– Determinar los requerimientos
– Comunicación entre los desarrolladores y los
usuarios.
– Generación de casos de prueba.

22/10/2021
Actores
• Un actor modela una entidad externa que
se comunica con el sistema:
– Usuarios
– Sistema externo
– Entorno físico
• Un actor tiene un nombre único y una
descripción opcional (será obligatorio en
este curso).
• Ejemplos:
– Pasajero: una persona en el tren
– Satélite GPS: proporciona al sistema
coordenadas GPS
Pasajero

22/10/2021
Caso de uso
Un caso de uso representa una clase
de funcionalidad proporcionada por
el sistema como un flujo de eventos.
Un caso de uso consta de:
• Nombre único
• Actores participantes
• Condiciones de entrada
• Flujo de eventos
• Condiciones de salida
• Requisitos especiales
Compra de
pasaje

22/10/2021
Ejemplo de diagrama de caso de uso
Sistema
Caso de Uso
Serie de transacciones de valor para el actor
Entidad fuera del sistema
quien interactúa con este
Actor

22/10/2021
Diagramas de Casos de Uso
• Notación
Caso de Uso
cliente
actor
Solicitar préstamo
Sistema

22/10/2021
Diagramas de Casos de Uso
• Un caso de uso describe una interacción entre el sistema y un agente
externo que se denomina actor:
– Un caso de uso capta siempre una función visible para el usuario.
– Un caso de uso logra un objetivo concreto y específico para el
usuario.
– Un caso de uso puede ser algo simple o algo complejo, en este
caso se puede formular en función de otros casos de uso.
• Los diagramas de casos de uso son recursos UML destinados a:
– Delimitar que partes pertenecen al sistema y cuales son externas a él.
– Captura los elementos de funcionalidad del sistema.
– Identifica y clasifica los elementos externos que interaccionan con él.
– Formula los protocolos de interacción entre actores y sistema.
• Los diagramas de casos de uso hacen referencia a la funcionalidad del
sistema y no hacen referencia a la implementación.
• Los casos de uso constituyen una representación de la funcionalidad
que se utiliza como guía de las restantes fases (análisis, diseño,
codificación, prueba y despliegue)

IIS Unidad 3A Proceso de desarrollo de software

IIS Unidad 3A Proceso de desarrollo de software

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie IIS Unidad 3A Proceso de desarrollo de software

Ähnlich wie IIS Unidad 3A Proceso de desarrollo de software (20)

Mehr von Franklin Parrales Bravo

Mehr von Franklin Parrales Bravo (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

IIS Unidad 3A Proceso de desarrollo de software