Clase 1: feriado

Clase 2: Necesidad de la sistematización del proceso de desarrollo

de software 4/4
Eficacia: grado con el cual uno cumple un objetivo

Eficiencia: costos con los cuales uno cumple un objetivo

Ingeniería: disciplina que resuelve problemas en los que todavía no hay solución específica. Un
ingeniero hace máquinas que resuelven algún problema.

Ingeniería informática: hace máquinas que tienen entradas, salidas, y procesos en el medio. Son
máquinas que tienen como entradas a datos, estos datos se procesan y se obtiene información
(salidas). Hacemos máquinas alimentadas con datos, que van a realizar sobre estos datos procesos,
y que van a generar a través de estos procesos información. Está información sirve para la toma de
decisiones.

Ingeniería de requisitos: una de las múltiples disciplinas que forman parte de la ingeniería
informática.

Proceso de ciclo de vida de desarrollo de SW (SDLC): nos lleva un tiempo, va a implicar varias
personas e involucra etapas. Según el autor pueden ser 5, 7 o 11 etapas. Para desarrollar SW como
mínimo necesito 3 etapas (análisis, diseño e implementación), c/u de estas fases tiene un objetivo:

❖ La fase de análisis: trata de descubrir lo que el cliente realmente necesita.

❖ La fase de diseño: se proyecta la mejor forma de construirlo (pero no lo va a construir).
❖ La fase de implementación: construir eso que se diseñó.

1
 Clase 3: Modelos prescriptivos del proceso de desarrollo de
software – los participantes 11/4
Roles en la ingeniería:
Los participantes los podemos dividir en 2 equipos:
➔ equipo de desarrollo:
◆ analista (lo que estamos estudiando en esta materia):
◆ diseñador:
◆ implementador:
◆ project manager (gestor):
➔ equipo del cliente:
◆ cliente: el que pone la plata, aquella persona que suele estar en los niveles
superiores de la organización del cliente, y tiene claro para que se quiere el sistema
que vamos a desarrollar (conoce los objetivos)
◆ usuario: el que interactúa constantemente con el sistema (puede haber distintos tipos
de usuarios)
◆ experto: puede o no ser el cliente, puede ser o no usuario; pero tiene una
característica que lo diferencia, conoce a fondo el negocio
◆ sponsor o facilitador o patrocinador: ayuda al equipo de desarrollo a que el proyecto
sea viable, por ejemplo nos ayuda convencer al experto que nos de la información
que necesitamos

Stakeholders: interesados, todos los involucrados en el desarrollo del sw, son tantos los del equipo
de desarrollo como los miembros del equipo del cliente. (Los usuarios son parte de los
stakeholders??? Ya que capaz ni sabían que se estaba desarrollando el sistema, pero después lo
usan)

Ciclo de vida de desarrollo de SW:

Proceso mediante el cual se produce un sistema (modelo en cascada, incremental, evolutivo)

Vimos el video ese que le piden al especialista realizar líneas // y rojas que haga 7 líneas todas
perpendiculares entre sí y lineas rojas pero de color verde, donde el cliente y el project manager ni
sabían lo que le pedían al experto (llama experto al analista en el video- aparte esta el experto de
parte del cliente)

Las materias introducción a los sistemas de información, introducción a los gestión de requisitos y
análisis de sistema se dedican a estudiar el análisis del sistema, buscando descubrir, entender
comprender lo que el cliente necesita.

Esta pirámide explica de modo comparativo cuanto nos sale corregir

un error dependiendo de cuando detectemos el error.

2
 Diagrama de cascada de errores

Diagrama de cascada de errores: si seguimos el camino vertical llegamos al diseño correcto (no se
cometieron errores en ninguna etapa), si no seguimos el camino vertical llegaremos a algún tipo de
error. Cuando partimos de especificaciones erróneas no satisfacemos las necesidades del cliente,
llegando a errores ocultos (que son el peor tipo de error que podemos cometer).

Si no funciona correctamente se pueden dar errores en 3 grados:

1. errores corregibles: son los más leves, se da cuando el programador comete errores de
programación (se da en la fase de implementación/codificación)
2. errores incorregibles: se dan cuando hay un diseño erróneo (se da en la fase de diseño)
3. errores ocultos: se dan por una especificación errónea (se da en la fase de especificación de
requisitos)

Los modelos prescriptivos del proceso de desarrollo de sw:

Desarrollar un sw implica necesariamente un proceso (ciclo de vida de desarrollo de sw)

Son enfoques estructurados y sistemáticos que guían el desarrollo de software desde su concepción
hasta su entrega y mantenimiento. Estos modelos proporcionan una serie de fases, tareas y
actividades específicas que deben seguirse para asegurar la calidad y el éxito del proyecto.

1. Modelo en cascada (Secuencial): Es uno de los enfoques

más tradicionales y lineales. El ciclo de vida sigue una
secuencia lineal de fases, donde cada fase debe completarse
antes de pasar a la siguiente. Las etapas típicas incluyen el
análisis de requisitos, diseño, implementación, pruebas y
mantenimiento. Es un enfoque estructurado y se presta bien
cuando los requisitos son estables y se pueden definir
claramente desde el principio.

2. Modelo en espiral (iterativo evolutivo): Este modelo incorpora

elementos del modelo en cascada y agrega iteración y
retroalimentación continua. El proceso se organiza en ciclos
llamados "espirales", donde cada espiral representa una iteración a
través de las fases de análisis de riesgos, desarrollo y evaluación.
Este enfoque es adecuado para proyectos de mayor complejidad y
que requieren una gestión de riesgos más intensiva.

3
3. Modelo en prototipos (iterativo evolutivo): Se centra en la
construcción rápida de prototipos funcionales del software. El ciclo de
vida implica la creación de un prototipo inicial basado en los requisitos
iniciales del cliente, que luego se evalúa y se utilizan para refinar y
mejorar el diseño final del software. Es útil cuando los requisitos del
proyecto no están bien definidos y se requiere una mayor interacción
con el cliente para obtener retroalimentación y refinar los requisitos.

4. Modelo en incrementos (iterativo Incremental): Este enfoque

divide el desarrollo del software en incrementos o versiones
funcionales parciales. Cada incremento aborda una parte específica
del sistema y se desarrolla, prueba y entrega de manera incremental.
El desarrollo se lleva a cabo en iteraciones y cada incremento se
basa en el trabajo realizado en incrementos anteriores. Es
beneficioso cuando se desea una entrega temprana de partes
funcionales del software y permite una mayor flexibilidad en caso de
cambios en los requisitos.

5. Modelo en desarrollo ágil (Agile): El desarrollo ágil es un

enfoque colaborativo e iterativo que se centra en la entrega rápida y
continua de software de alta calidad. Los modelos ágiles más
conocidos son Scrum y Kanban. Estos enfoques valoran la
comunicación frecuente con el cliente, la colaboración del equipo, la
flexibilidad para adaptarse a cambios y la entrega de software en
incrementos cortos y frecuentes.

El alcance y la definición de los requisitos:

El alcance y la definición de los requisitos son fases cruciales en cualquier modelo de desarrollo de
software, ya que establecen las bases para el éxito del proyecto.

➢ Alcance del Proyecto: es la delimitación clara y precisa de todo el trabajo necesario para
completar el proyecto. Define qué se incluirá en el proyecto y qué quedará fuera de él.
Componentes del Alcance:
1. Objetivos del Proyecto: Declaraciones claras de lo que se espera lograr.
2. Entregables Principales: Productos o resultados tangibles que se deben entregar al
finalizar el proyecto.
3. Restricciones y Suposiciones: Factores que pueden limitar las opciones del equipo de
proyecto y los supuestos considerados durante la planificación.
4. Criterios de Aceptación: Condiciones que deben cumplirse para que los entregables sean
aceptados por el cliente o usuario final.

Proceso de Definición del Alcance:

1. Identificación de Stakeholders: Determinar quiénes serán los interesados y participantes
clave.
2. Recopilación de Requerimientos: Obtener una lista detallada de necesidades y
expectativas de los stakeholders.
3. Análisis de Viabilidad: Evaluar la factibilidad técnica y económica del proyecto.
4. Desglose del Trabajo (WBS): Dividir el trabajo del proyecto en tareas manejables.

Importancia:
● Ayuda a evitar el desvío del alcance (scope creep).
● Facilita la gestión y control del proyecto.
● Asegura que todos los participantes tengan una comprensión común del proyecto.

4
 ➢ Requisitos: Los requisitos son las características, funciones y restricciones que el sistema
debe tener para satisfacer las necesidades de los usuarios y stakeholders.
Tipos de Requisitos:
1. Requisitos Funcionales: Especifican las funciones que el sistema debe realizar. Ejemplo:
“El sistema debe permitir a los usuarios registrar nuevas cuentas.”
2. Requisitos No Funcionales: Describen las propiedades y restricciones del sistema, como
rendimiento, usabilidad, seguridad, etc. Ejemplo: “El sistema debe responder a las solicitudes
de los usuarios en menos de 2 segundos.”
3. Requisitos del Dominio: Especifican las características del entorno específico del dominio
en el que operará el sistema. (Esto me hace pensar en una regla de negocio así que busque
la diferencia)

Requisito de Dominio: Son condiciones o capacidades que debe tener el sistema para cumplir con
las necesidades específicas de un dominio particular de conocimiento o negocio. Se centran en lo
que el sistema debe hacer, describiendo funcionalidades y comportamientos en un contexto
específico. Por ejemplo: "El sistema debe permitir a los usuarios buscar productos por categoría y
precio."
Regla de Negocio: Son directrices, restricciones o condiciones que rigen las operaciones del
negocio. Se utilizan para tomar decisiones y guiar comportamientos dentro de la organización. Se
centran en la política y los procedimientos de la organización, estableciendo cómo deben hacerse las
cosas. Por ejemplo: "Un cliente no puede realizar una compra a crédito si tiene una deuda pendiente
superior a 30 días."
En resumen, los requisitos de dominio especifican lo que el sistema debe hacer dentro de un
contexto específico, mientras que las reglas de negocio son directrices que definen cómo debe
operar el negocio.

Las reglas de negocio se convierten en requisitos cuando el sistema debe llevarlas a cabo. Por
ejemplo una si Rappi no admitiese la venta de alcohol a menores:

● Si el repartidor es el encargado de ver si el que está comprando sea mayor entonces es una
regla de negocio.
● Si la app verifica que el que está comprando sea mayor entonces es un requisito.

Proceso de Definición de Requisitos:

1. Elicitación de requisitos: Proceso de obtención de requisitos a través de entrevistas,
encuestas, talleres, etc.
2. Análisis de Requisitos: Evaluar y priorizar los requisitos obtenidos para asegurarse de que
sean claros, completos y factibles.
3. Documentación de requisitos: Registrar los requisitos en un formato claro y estructurado,
como especificaciones de requisitos del software (SRS).
4. Validación de requisitos: Asegurar que los requisitos definidos reflejen realmente las
necesidades de los stakeholders y que sean factibles de implementar.
5. Gestión de Requisitos: Controlar y gestionar los cambios en los requisitos a lo largo del
ciclo de vida del proyecto.

Herramientas y Técnicas:
● Entrevistas y Encuestas: Para recopilar información directa de los stakeholders.
● Talleres de Requisitos: Sesiones de trabajo colaborativo para identificar y priorizar
requisitos.
● Prototipos: Creación de modelos funcionales del sistema para clarificar y validar requisitos.
● Diagramas y Modelos: Uso de diagramas de casos de uso, diagramas de flujo, y modelos
UML para representar visualmente los requisitos.

Importancia:
● Asegura que el producto final cumpla con las expectativas del cliente y usuarios.
● Reduce el riesgo de errores y retrabajos durante el desarrollo.
● Proporciona una base para la planificación y estimación del proyecto.

5
 Clase 4: ingeniería de requisitos 18/4
Modelos de procesos de la Ingeniería de Requisitos:
de los requisitos del usuario a los requisitos del sistema

ERS (ingeniería de requisitos del sistema): tomamos los requerimientos del cliente y a través de la
ingeniería de requisitos obtenemos la ERS del sistema. Hay dos tipos de requisitos:
➔ requisitos del cliente: son aquellas cosas que el cliente manifiesta que él necesita del
sistema (no necesariamente lo vamos a satisfacer en el sistema que desarrollemos, pues el
cliente no siempre sabe lo que quiere)
➔ requisitos del sistema: especificación de requisitos que tiene que satisfacer el sistema

Cuando hablamos de ingeniería de requisitos vamos a trabajar para descubrir lo que el cliente
necesita formalizando a través de la ERS

Ingeniería de Requisitos: Concepto y definición

La ingeniería de requisitos es una disciplina fundamental dentro del proceso de desarrollo de
software que se centra en la identificación, documentación, análisis, verificación y gestión de los
requisitos de un sistema de software.

Concepto de Ingeniería de Requisitos: La ingeniería de requisitos es el conjunto de actividades y

técnicas utilizadas para identificar las necesidades y restricciones de los stakeholders, y traducirlas
en requisitos claros, completos y factibles que guiarán el diseño, desarrollo y mantenimiento de un
sistema de software.

Modelo de la Star Guide: La Ingeniería de Requisitos es el proceso en el cual se transforman los

requerimientos declarados por los clientes, ya sean hablados o escritos, a especificaciones precisas,
no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones,
interfaces, rendimiento y limitaciones. Es el proceso mediante el cual se intercambian diferentes
puntos de vista para recopilar y modelar lo que el sistema va a realizar.

6
Modelo de Wiegers: plantea dividir el proceso de la ingeniería de requisitos en dos subprocesos
principales, el desarrollo de requisitos y la gestión de requisitos.

La gestión de los requisitos implica establecer y mantener un acuerdo con el cliente sobre los
requisitos para el proyecto. Este acuerdo se materializa en las especificaciones escritas de los
requisitos y los modelos anexos.

El desarrollo de requisitos lo divide en:

➔ elicitación: obtener información, más comprometida que relevar, no quedarse únicamente con
la información que nos da el cliente. Recolección activa y efectiva de información
➔ análisis: luego de obtener la información hay que tratar de comprenderla
➔ especificación: representar la información analizada en un documento, diagrama o maqueta
➔ validación: las especificaciones deben ser validadas por el cliente, usuario, experto
(comprobación externa)
Estas subdisciplinas abarcan todas las actividades involucradas en la obtención, evaluación y
documentación de los requisitos de un sistema.

La aceptación de los requisitos debe ser tanto por parte del cliente (validación) como por el equipo de
desarrollo (verificación). La validación busca saber si estamos construyendo el sistema
correctamente.

Modelo de Sommerville: define cuatro subprocesos de alto nivel. Comienza analizando si el sistema
es útil para el negocio (estudio de viabilidad); luego describe una fase de descubrimiento de
requerimientos (obtención y análisis de requerimientos), los cuales se transforman a formatos
estándar (especificación de requisitos) y por último se analiza que los mismos definan el sistema que
quiere el cliente (validación de requerimientos).
Sommerville junta los procesos a los que Wiegers llamó la elicitación y análisis de la información en
la obtención y análisis de los requerimientos. En cada etapa hay producción de distintos artefactos
(informe de viabilidad, modelos de sistemas, requerimientos del usuario y del sistema, documentos
de requerimientos). Además este modelo se caracteriza por la iteración.
La viabilidad (no entra en los ciclos iterativos) puede ser:
➢ técnica: que exista la tecnología
➢ económica: que se pueda financiar
➢ operacional: no se contraponga con las actividades que se van a realizar

7
Proceso Genérico de la Ingeniería de Requisitos: [Hadad, 2003] En la cátedra vamos a trabajar
sobre un proceso genérico para la Ingeniería de Requisitos, sin entrar en las visiones particulares de
cada autor. Este proceso incluye todas las actividades básicas de la ingeniería de requisitos.

Categorización de requisitos:
Los requisitos de un sistema pueden ser funcionales o no funcionales.
❖ Requisitos funcionales o funcionalidades: cosas que el sistema va a tener que hacer. Son
enunciados acerca de servicios que el sistema debe proveer, de cómo debería reaccionar el
sistema a entradas particulares y de cómo debería comportarse el sistema en situaciones
específicas. En algunos casos, los requerimientos funcionales también explican lo que no
debe hacer el sistema.
❖ Requisitos no funcionales: son limitaciones sobre servicios o funciones que ofrece el sistema.
Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas
por los estándares. Los requerimientos no funcionales se suelen aplicar al sistema como un
todo, más que a características o a servicios individuales del sistema.

Lenguaje de alto nivel: poco detalle.

Lenguaje de bajo nivel: mayor nivel de detalle, se especifica los distintos escenarios.

Lenguaje de Alto Nivel: Se refiere a una forma de documentar requisitos que es abstracta y general,
centrándose en los objetivos y necesidades del usuario o del negocio.

Características:
➔ Comprensible para Usuarios y Stakeholders No Técnicos: La redacción es clara y fácil de
entender para personas que no tienen conocimientos técnicos profundos.
➔ Enfoque en Qué y Por Qué: Describe qué debe hacer el sistema y por qué es necesario, sin
entrar en detalles técnicos.
➔ Ejemplo: "El sistema debe permitir a los usuarios registrarse y gestionar sus perfiles."

Lenguaje de Bajo Nivel: Se refiere a una forma de documentar requisitos que es más detallada y
específica, enfocándose en cómo se deben implementar los requisitos.
Características:
➔ Comprensible para Desarrolladores y Personal Técnico: La redacción incluye detalles
técnicos y especificaciones precisas.
➔ Enfoque en Cómo: Describe cómo se debe implementar una funcionalidad o cómo se debe
comportar el sistema.
➔ Ejemplo: "El sistema debe almacenar la información del perfil del usuario en una base de
datos relacional y garantizar que los datos se cifren utilizando el algoritmo AES de 256 bits."

En la práctica, es importante utilizar ambos niveles de lenguaje para asegurar que los requisitos sean
comprendidos por todos los involucrados en el proyecto, desde los usuarios hasta los
desarrolladores.

8
Requerimientos no funcionales:
❖ de producto:
➢ Usabilidad: facilidad con la que el sistema se usa, por ej el sistema sube deberá ser
operado satisfactoriamente en al menos el 75% de los usuarios de una población
instruida entre los 6 y 90 años que haya recibido una capacitación virtual de X
tiempo. Otro ejemplo, en miel tal operación deberá resolverse en a lo sumo 5
pantallas o formularios.
➢ de eficiencia:
■ de rendimiento: tiempo de respuesta, por ej el sistema sube deberá
registrar el cobro del boleto en menos de 5 segundos. Otro ejemplo,
intraconsulta deberá poder resolver 5 consultas de distintos estudiantes al
mismo tiempo.
■ de espacio: tal app no puede ocupar más de X mb de memoria del sistema
android
➢ de confiabilidad: tiene que ver con la disponibilidad, que pueda cumplir con sus
funciones a lo largo del tiempo
➢ de seguridad: que no exponga información
❖ de la organización:
➢ ambientales: que el sistema funcione en tal medio
➢ operacionales: que necesita para funcionar el sistema
➢ de desarrollo: plazos estipulados de entrega, o un parámetro del desarrollo en
particular
❖ externos: básicamente son normativos, tienen que ver con regulaciones
➢ regulatorios: tienen que ver con una ley o disposición
➢ éticos:
➢ legales:
■ contables:
■ protección/seguridad:
Reglas de negocio:
Son las normas en las que se basa una organización, no necesariamente van de la mano con la ley.
Por ejemplo COTO no vende alcohol un domingo, la ley solo dice que no se puede vender después
de las 22 hrs o a menores de edad, pero no se especifica nada acerca de los domingos. Las reglas
de negocio en la ingeniería de requisitos son directrices o políticas que determinan cómo debe
funcionar un sistema dentro de una organización. Estas reglas son esenciales para asegurar que el
sistema cumpla con los objetivos comerciales y operacionales.

Las reglas de negocio se convierten en requisitos cuando el sistema debe llevarlas a cabo. Por
ejemplo si Rappi no admitiese la venta de alcohol a menores:

● Si el repartidor es el encargado de ver si el que está comprando sea mayor entonces es una
regla de negocio.
● Si la app verifica que el que está comprando sea mayor entonces es un requisito.

9
 Requisitos de alto y bajo nivel
En la ingeniería de requisitos, los requisitos se clasifican en dos niveles:
➔ Requisitos de Alto Nivel: también conocidos como requisitos de negocio, son aquellos que
describen las metas y objetivos generales del sistema desde una perspectiva del negocio o
del usuario. No entran en detalles técnicos, sino que se centran en lo que el sistema debe
lograr. Estos requisitos son la base para derivar los requisitos de bajo nivel.

Características de los Requisitos de Alto Nivel:

● Enfocados en el Negocio: Describen lo que el negocio o los usuarios necesitan del sistema.
● Generales: Son más abstractas y menos específicas en términos de implementación.
● Orientados a objetivos: Se centran en los resultados y beneficios esperados.
● Fáciles de Entender: Redactados en lenguaje claro y accesible para todas las partes
interesadas.

Ejemplos de Requisitos de Alto Nivel

1. Funcionales:
○ "El sistema debe permitir a los usuarios realizar compras en línea."
○ "El sistema debe generar reportes mensuales de ventas."
2. No Funcionales:
○ "El sistema debe ser accesible desde cualquier dispositivo con conexión a internet."
○ "El sistema debe ser capaz de manejar hasta 10,000 usuarios concurrentes."
➔ Requisitos de Bajo Nivel: conocidos como requisitos técnicos o detallados, especifican
cómo se deben implementar los requisitos de alto nivel. Proporcionan detalles precisos y
técnicos necesarios para el diseño y desarrollo del sistema.

Características de los Requisitos de Bajo Nivel

● Detallados: descripción técnica precisa de cómo se logrará un requisito de alto nivel.
● Específicos: Detallan aspectos técnicos específicos, como algoritmos, interfaces, bases de
datos, etc.
● Orientados a la Implementación: Describen cómo deben desarrollarse las funcionalidades.
● Utilizados por los Desarrolladores: Son esenciales para que los equipos de desarrollo puedan
construir y probar el sistema.

Ejemplos de Requisitos de Bajo Nivel

1. Funcionales:
○ "El sistema debe permitir que los usuarios agreguen productos a un carrito de
compras con un clic en el botón 'Agregar al carrito'."
○ "El reporte mensual de ventas debe incluir columnas para fecha, total de ventas
diarias, y número de transacciones, y debe estar disponible en formato PDF."
2. No Funcionales:
○ "El tiempo de respuesta del sistema debe ser menor a 2 segundos para cualquier
solicitud de usuario."
○ "La base de datos debe estar replicada en al menos tres ubicaciones geográficas
diferentes para asegurar alta disponibilidad."

Relación entre Requisitos de Alto y Bajo Nivel

● Derivación: Los requisitos de bajo nivel se derivan de los requisitos de alto nivel. Cada
requisito de alto nivel puede dar lugar a múltiples requisitos de bajo nivel.
● Trazabilidad: Es importante mantener la trazabilidad entre los requisitos de alto nivel y los de
bajo nivel para asegurar que todos los aspectos del negocio estén cubiertos por la
implementación técnica.
● Validación y Verificación: Los requisitos de alto nivel se validan con los interesados del
negocio, mientras que los requisitos de bajo nivel se verifican durante el desarrollo y las
pruebas.

10
 Clase 5: categorización de requisitos y reglas de negocio 25/4
Todo esto vimos la clase 4,
1. Categorización de los requisitos.
a. Requisitos funcionales: concepto y ejemplos.
b. Requisitos no funcionales: concepto, clasificación y ejemplos.
c. Requisitos de alto y bajo nivel.
2. Reglas del negocio: concepto, ejemplos y diferenciación respecto de los requisitos.

EN LA CLASE 5 NI IDEA QUE VIMOS!!!!!!!!!

Clase 6: Ejercitación e integración de contenidos. 2/5

➢ Modelo de examen

Clase 7: las especificaciones de un sistema en desarrollo 9/5

Especificación de requisitos estándar IEEE 830

Características de una ERS: completa, consistente,inequívoca, correcta, trazable, priorizable, modificable, verificable, clara.

11
 Referencias: vamos a buscar alguna tal o cual normativa.

Tipos de usuarios: revisor, validador. Tenemos que pensar en la experiencia técnica del usuario, sus limitaciones y preferencias.
ENTORNO: una app para android pero tenemos una RESTRICCIÓN: que se a partir de android 6

12
Plantilla-ERS-conforme-IEEE-830

13
14
15
16
17
 Historia de usuario (HU)

Características de HU: independientes, negociables, valoradas, estimables,pequeñas, verificables

18
19
Sprint: cantidad de historias que se pueden atender en X tiempo. Voy haciendo cosas en pasos, ejemplo: 1º entrego una
patineta, 2º entrego una bici, 3º entrego un auto.
Ejemplo: 1º con una app diferenciamos los colores, 2º con la app diferenciamos texturas.

Planilla Historias de usuarios:

20
 Clase 8: evaluación 16/5
Clase 9: Casos de Uso 23/5
➔ Se aclara todo lo que brinda el sistema (funcionalidades), por ejemplo si nos dice la fecha y la
hora, no es una f completa, pues lo hace en un contexto mayor, la funcionalidad es el despacho de
bultos. Funcionalidad completa: las f completas tienen un beneficio para quien las llama a
ejecución.
➔ Para trabajar con casos de uso lo primero que vamos a ver es analizar un sistema e identificar las
funcionalidades completas (muchas veces aglutinan funcionalidades más pequeñas) del caso de
uso.

En esta interfaz al despachante le pone a disposición es:

● La hora (pero esta funcionalidad no es una f completa)
● Listado con vuelos que salen en las prox 2 horas (no es una f completa)

La f completa es REGISTRAR EL DESPACHO DE BULTOS. No toda funcionalidad del sist es una f

completa. Cuando se habla de casos de usos necesariamente se habla de f completa (estas tienen
un beneficio para quien las llama de ejecución)
Diagramas de casos de uso:
Representa para un sistema todos los casos de uso (cu) que el sist tiene, es decir todas las f
completas

Los rectángulos son el sist

21
Los roles que hacen uso del sist (actor)
Los actores actúan directamente con el sist

En nuestro ej el despachante si es un actor, el pasajero no es un actor del sist porque no interactúa

con el sist.

Las funcionalidades completas son elipses

Se mencionan en su terminación en infinitivo

Cuando queremos poner de manifiesto quien pone en funcionamiento la f usamos una linea (quien lo
inicia)

Si queremos mostrar lo que es común a dos actores ponemos una flecha entre los dos actores
(GENERALIZACIÓN)

Los actores pueden ser un sistema, es decir que un sist inicia una funcionalidad.

22
 Clase 10: Estándares de especificación de los req de sw 30/5
Los cu como por ejemplo, iniciar sesión, cerrar sesión son cu f simple.
La f completa sería registrar el despacho de bultos, dentro de ellas hay otras funcionalidades más
sencillas, por ej al momento al despachar bultos el sist puede ofrecer al despachante el registro de
los vuelos en las próximas 2 hs.
Actor no es toda persona, sist ni sensor que interactúa con el sist, ACTOR ADEMÁS DE
INTERACTUAR CON EL SIST DEBE INICIAR UN CU.
Los cu se escriben en infinitivo, tenemos que pensar todos los cu como 4:
1. Registrar
2. Eliminar
3. Actualizar
4. Consultar
Por ejemplo si inicio sesión es registrar iniciar sesión. La mayoría de los cu se clasifican como
REGISTRAR. Eliminar cuenta es (casi siempre) ACTUALIZAR.
La eliminación es una f completa que no se suele dar. El objetivo de los sist casi siempre es registrar.

El registro de inicio de sesión lo hace un actor anónimo, un visitante si estamos en un sitio web,
entonces que una vez que iniciamos sesión la f de registro de inicio de sesión ya no nos va aparecer,
solo nos aparecen las f que vamos a usar. Mientras sea un actor anónimo solo nos debe permitir
iniciar sesión.
Teniendo en cuenta esto podemos pensar en 3 tipos de sist:
1. Los sist que no piden ningún tipo de identificación para ninguna tarea.
2. Los sist que exigen identificación pero permiten registrarse.
3. Los sist que exigen identificación pero no permiten registrarse, por ejemplo nos da de alta
algún supervisor.

23
Planilla de especificación de caso de uso:

24
Esta plantilla no es universal, los elementos comunes son:
● Interfaz tentativa de análisis:(no es como se va a ver la aplicación) esta planilla sólo nos sirve
para ver la secuencia de pasos que se desarrollan. Los estereotipos son dibujo que vamos a
utilizar para representar
Especificación del Caso de Uso:
Nombre: Caso de uso nº1
Tipo: [Base, Incluido o Extendido].
Descripción General: Un párrafo que explique muy por arriba qué es lo que hace el caso de uso, no
tiene detalle, lo puedo pensar como un requisito funcional de alto, de alto nivel o de medio nivel.
Ejemplo general, el DESPACHANTE seleccionará los bultos que se quieren envía. Este lo registrará,
los pesará y le dará un comprobante. Pegará un código QRA cada bulto y le da un comprobante al al
cliente, al al pasajero. Listo, dice, y bueno, pero ahí no tiene en cuenta que pasa si tal cosa, si tal otra
no queda claro con qué datos opera. No dice qué datos ingresa primero y cuál se selecciona
después.Eso no importa, no es el objetivo de eso, todo eso va a venir después.
Actores principales: son los que inician el cu
Actores Secundarios: [Si los hubiera]. los que participan en el proceso pero no lo inician,
interactúan con el sist pero no lo ponen en marcha. Si no actúan el sist queda parado, los actores
secundarios por lo general dan autorizaciones, validaciones o aceptaciones. Por ej en el sist sube el
pasajero es un actor secundario, ya que solo apoya la tarjeta (está aceptando que se le cobre el
viaje) pero él no inicia el cu.
Autor: [Su nombre]. Quién lo creó
Fecha de Creación: [Del documento]
Precondiciones: [Puede ser una, varias o ninguna]. Otro cu de este sist, es un caso de uso que
tuvo que haber precedido anteriormente (solo el inmediatamente anterior)
Puntos de Extensión: [Indica en qué puntos se extiende a otros casos de uso]....
Descripción Detallada o Flujo Normal. El paso a paso de lo que sucede en el sist
● 1. El actor principal hace.
● 2. El sistema responde.
● 3. El actor principal hace.
● 4. El sistema responde.
● 5. …
● 6. [Se incluye al Caso de Uso: “XX”].
● 7. …
● 8. El actor principal hace.
● 9. El sistema responde
● 10. fin del caso de uso.
o Flujos Alternativos.
● A0 “Cancelación”.
● (*) En cualquier momento antes del paso X:
● (*).1. El actor principal oprime “Cancelar”.
● (*).2. El sistema finaliza el caso de uso.
● A1 [nombre del camino alternativo].
● N.1 [es un camino alternativo que se desprende del punto N del flujo
● normal]
● N.2 …………………..….
● N.3 [Continua por el punto x del flujo normal] o [Finaliza el caso de uso].
Post-condición [Beneficio para el actor principal][Descripción del estado del sistema después
de la ejecución del caso de uso]. Es lo que busca el actor principal, por ejemplo la post condición
del despachante de bulto busca que el despacho de bultos quede registrado.

25
26
Esta interfaz es tentativa, la uso para imaginarme el proceso. Por cada cu se hace una sola interfaz.
Etiquetas: salidas de información, el sist muestra la información.

27
 Clase 11: Especificación de cu 6/6

El objetivo de la interfaz tentativa de análisis es ser una especie de boceto de lo que puede hacer el
sistema, sirve tanto para los analistas como para los usuarios.
Es común modificar los casos de uso, obteniendo distintas versiones.
Hoy vemos 2 tipos de relaciones:
★ Las que se establece entre el actor y el caso de uso (REALIZACIÓN)

★ Las que se establece entre actores (GENERALIZACIÓN)

Hace lo mismo que a quien apunta (No es adecuado llamarlo HERENCIA, por si preguntan en el
parcial)

Además se pueda dar relaciones entre casos de uso, que tiene dos modalidades:
○ Extensión:
○ Inclusión:
ejemplo:

28
RELACIÓN DE INCLUSIÓN: Si dentro de A o de B hay un conj de usos contenidos en C, entonces
podemos decir que el caso de uso C está incluido en el cu A

C está incluido en A
C está incluido en B

<<incluye>>

CARACTERÍSTICAS:
● Cuando se haga el caso de uso A si o si se ejecuta el caso de uso C
● La intersección es lo común a dos casos de uso

Un cu como consultar vuelo es un proceso común entre dos o más casos de usos.
La cantidad mínima para que haya una inclusión son 2, por ejemplo el caso de uso P está incluido en
el caso de uso Q, pero P existe por sí solo.
Los casos de uso tiene que poder realizarse independiente por algún actor.

EL CASO DE USO INCLUIDO ES LO COMÚN A LOS DOS CASOS DE USOS INCLUYENTES.

Hay una ley en teoría de conj que dice que todo conj está incluido en sí mismo, por lo tanto la
cantidad mínima para que haya una inclusión es 2 casos de usos.

RELACIÓN DE EXTENSIÓN: tiene 2 características:

1. Solo necesita un caso de uso
2. Opcionalidad: no es obligatorio
Dentro del caso de uso A se puede ejecutar el caso de uso B (la extensión es un agregado que
puede ser opcional)

29
<<extend>>

En la extensión y la inclusión se ponen en marcha por otro caso de uso.

Un caso de uso puede ser una funcionalidad completa para un usuario y/o puede ser una extensión
de otro caso de uso.

El cu CONSULTAR CONTRASEÑA es un cu base porque lo puede iniciar el Gerente de Operaciones

o el vendedor, pero tmb es una extensión del cu REGISTRAR INICIO DE SESIÓN.

30
 DIAGRAMA DE DESPLIEGUE:
Son dos diagramas al mismo tiempo, el diagrama de despliegue habla del “hardware”

DIAGRAMA DE COMPONENTES:
Muestra un poco el software dentro del hardware.

Técnicamente hablando es lo más importante que hay que mencionar en el diagrama de despliegue
que tenía los componentes de hardware, ahora agregamos los componentes software. Ahora
agregamos en el disp móvil se está ejecutando la app, conectada a través de la web API, utilizando el
lenguaje JSON. Se puede agregar info, por ejemplo si hay otro componente en el dispositivo móvil
ejecutándose, por ejemplo el sistema operativo.

Los diagramas de despliegue y componentes sirven para entender el contexto en el que va a operar
el sistema.

31
Clase 12: adquisición de conocimientos 13/6
Adquisición de conocimientos

En toda fase de desarrollo hay adquisición de conocimientos.

32
*dominio: porción de la realidad donde funciona el sistema

33
34
35
36
37
38
 Técnicas de educción
Técnicas de educción: entrevistas, cuestionarios/encuestas, card storing, observación, braintorming

39
40
41
42
43
Metodologías ágiles(no lo vimos en clase, solo lo nombramos)

44
45
46
47
48
49
50
51
52
53