Ingenieria de Software - Resumen - Modulo I

1
Contents
1 Conceptos Generales 4
1.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Tipos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Participantes del Desarrollo de Software . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Ingenierı́a de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Responsabilidades Éticas y Profesionales . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Conocimientos de un Ingeniero de Software . . . . . . . . . . . . . . . . . . . . . 5

2 Proceso de Software 6
2.1 Modelos de procesos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Tipos de modelos Tradicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Ejemplos de Modelos Tradicionales . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Metodologı́as Ágiles 7
3.1 Ejemplos de Metodologias Agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 eXtreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3 Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4 Adaptative software development (ASD) . . . . . . . . . . . . . . . . . . . . . . . 8

4 Elicitación de Requerimientos 9
4.1 Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Fuentes de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Puntos de Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Posibles problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1 Problemas de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2 Limitaciones cognitivas (por el lado del desarrollador) . . . . . . . . . . . . . . . 10
4.2.3 Conducta humana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.4 Técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Técnicas de elicitacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2 Cuestionarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.3 Muestreo de la documentación, las formas y los datos existentes . . . . . . . . . 12
4.3.4 Investigación y visitas al lugar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.5 Observación del ambiente de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.6 Planeación conjunta de requerimientos (JRP o JAD) . . . . . . . . . . . . . . . . 13
4.3.7 Lluvia de Ideas - Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Ingenierı́a de Requerimiento 14
5.1 Requerimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1 Requerimientos mal tomados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1 Estudio de Viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.2 Obtención y Análisis de requerimientos . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.3 Especificación de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.4 Validación de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Técnicas para especificar requerimientos 17

6.1 Estáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2 Dinámicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1 Tablas de decisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.2 Diagramas de transición de estados . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.3 Redes de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.4 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2
 6.2.5 Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Iniciativas 21
7.1 Épicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Mi ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3
1 Conceptos Generales
1.1 Software
El software se define (según la IEEE) como el conjunto de los programas de cómputo, procedimien-
tos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de
computación.
Si bien esta definición es importante no es necesario aprenderla de memoria, pero es importante
el concepto que conlleva: el software NO es solo un programa, el software debe entenderse como
un sistema integral que involucra tanto el producto final (los programas) como los elementos que
garantizan su correcta funcionalidad.

1.1.1 Tipos de software

• Genéricos: Sistemas aislados producidos por organizaciones desarrolladoras de software y que
se venden en un mercado abierto.
• Personalizados: Sistemas requeridos por un cliente en particular. Desarrollados por la propia
organización interesada o un contratista.

1.1.2 Caracterı́sticas
• Es un elemento lógico.
• El software se desarrolla, no se fabrica. Esto significa que, una vez creado, no es necesario
volver a producirlo desde cero para reutilizarlo; basta con adaptarlo. A diferencia de los productos
manufacturados, que requieren un nuevo proceso de fabricación para replicarse.
• El software no se desgasta con el tiempo. No sigue una curva clásica de envejecimiento. El
problema llega con los cambios.
• Se desarrolla mayoritariamente por componentes.

1.1.3 Participantes del Desarrollo de Software

• Cliente: Es quien patrocina el proyecto de software, proporcionando los recursos financieros
necesarios para su desarrollo.
• Usuario: Es la persona que utiliza el sistema y tiene la necesidad de interactuar con él para
cumplir con sus necesidades.
• Desarrollador: Es quien construye el software y lo proporciona al usuario, y tiene obligaciones
contractuales con el cliente para cumplir con los requisitos y expectativas establecidas.

1.2 Ingenierı́a de Software

Disciplina de la ingenierı́a que comprende todos los aspectos de la producción de software desde las
etapas iniciales hasta que el software muere (se deja de utilizar).
Otra definición posible es la de la IEEE: La Ingenierı́a de Software es el uso de métodos sistemáticos,
disciplinados y cuantificables para el desarrollo, operación y mantenimiento de software.

Caracterı́sticas:

• Usa métodos sistemáticos “Cuantificables”: Los métodos empleados son medibles, lo

que facilita su evaluación y optimización. Además, al ser sistemáticos, permiten que ante un
mismo problema se desarrolle una solución consistente, obteniendo resultados predecibles y re-
producibles.
• Dentro de tiempos y costos estimados: Un ingeniero de Software debe cumplir con los
tiempos establecidos, por lo que debe medir, estimar, planificar y administrar proyectos.

4
 • Para el “Desarrollo, operación y mantenimiento”: La Ingenierı́a de Software se ocupa de
todo el ciclo de vida de un producto, desde su etapa inicial de planificación hasta que el software
muere (debe sacarse de servicio por inutilización).

Al ser una ingenierı́a:

• Hace que las cosas funcionen.

• Se aplican teorı́as, métodos y herramientas.

1.2.1 Responsabilidades Éticas y Profesionales

La Ingenierı́a de Software se desarrolla en un marco económico, social y legal, lo que implica que los
Ingenieros de Software deben cumplir no solo con responsabilidades técnicas, sino también legales. Un
Ingeniero de Software debe cumplir con los siguientes principios:

Confidencialidad
Es fundamental respetar la confidencialidad de empleados y clientes, evitando la búsqueda de
información de usuarios que no está autorizada.

Competencia
Los Ingenieros de Software deben evitar falsificar su nivel de competencia y aceptar re-
sponsabilidades fuera de su capacidad. Esto implica no afirmar conocimientos o habilidades que
no se poseen, ya sea en una entrevista laboral o en una reunión con un cliente.

Derechos de Propiedad Intelectual

Es esencial conocer las leyes vigentes sobre patentes y derechos de autor (copyright). Los ingenieros
deben estar al tanto de las licencias bajo las cuales se encuentran las herramientas y librerı́as que
utilizan. Es fácil cometer errores en este aspecto, como utilizar librerı́as con licencias restrictivas, como
la GNU, que no permiten la comercialización, o copiar código de la web sin considerar las implicaciones
legales.

Utilización apropiada de las Computadoras

No se debe utilizar las habilidades técnicas para hacer un uso inapropiado de las computadoras.
Las computadoras tienen un propósito especı́fico, y en el contexto laboral, por ejemplo, deben usarse
exclusivamente para tareas relacionadas con el trabajo y no para actividades personales.

1.2.2 Conocimientos de un Ingeniero de Software

• Conocimientos cientı́ficos, metodológicos, tecnológicos1 y administrativos.
• Estar familiarizado con la aplicación de métodos formales: lógica, estadı́stica, simulación, etc.
• Poder aplicar metodologı́as de documentación, análisis, especificación, diseño, implementación y
prueba.
• Conocer las tecnologı́as y productos: sistemas operativos, lenguajes, herramientas, bases de
datos, sistemas generadores de interfaces, bibliotecas de código.
• Conocer técnicas de administración de proyectos: planificación, análisis de riesgos, control de
calidad, seguimiento de proyectos, control de subcontratistas, etc.

1 conocimientos de la ciencia de la computación.

5
2 Proceso de Software
Es un conjunto de actividades y resultados asociados que producen un producto de software.

2.1 Modelos de procesos de software

Es una descripción simplificada de un proceso de software que presenta una visión de ese proceso.

2.1.1 Tipos de modelos Tradicionales

• Modelos prescriptivos: Modelo que se realiza antes de la producción del software. Prescriben
un conjunto de elementos del proceso y como se relacionan entre si.
• Modelos descriptivos: Modelos que se realiza luego de la producción del software. Describen
en la forma en que se realizan en la realidad. Se busca que este modelo se parezca lo máximo al
prescriptivo2 .

2.1.2 Ejemplos de Modelos Tradicionales

• Modelo en Cascada: el proceso de desarrollo de software se representa como una serie de
fases secuenciales que siguen un orden en caı́da, como una cascada. Cada fase debe completarse
antes de que comience la siguiente. Aunque es útil para explicar a los clientes, las etapas
de un desarrollo de software, nunca se adapta a la realidad dinámica del desarrollo de
software, ya que no permite cambios fáciles en etapas anteriores una vez que se avanza a las
siguientes.
Existe una saliente de este modelo que es el modelo en cascada con prototipado, a diferencia
del modelo en cascada simple, este permite saltar a la primer etapa solo desde la etapa de prueba.
• Modelo en V: Este modelo enfatiza la vinculación entre las fases de desarrollo y las fases de
prueba. El proceso se representa como una ”V”, donde el lado izquierdo representa las etapas
de desarrollo (como análisis, diseño y codificación) y el lado derecho representa las etapas de
prueba (como verificación y validación). Si se encuentran problemas durante las pruebas, se
puede regresar al lado izquierdo de la ”V” para corregir los problemas, lo que permite una
retroalimentación y corrección durante el proceso. Este modelo muestra como se relaciona las
actividades de prueba con el análisis y diseño.
• Prototipado: El prototipado implica la creación de un prototipo, que es una versión prelim-
inar del sistema en desarrollo (Un MVP basicmente). Este prototipo permite a los clientes y
desarrolladores examinar y evaluar algunos aspectos del sistema propuesto. A través de la retroal-
imentación obtenida, se pueden realizar ajustes y mejoras antes de la finalización del producto.
El prototipado es útil para clarificar requisitos y ajustar el diseño según las necesidades reales
del usuario. Puede ser incremental (entrega de a subsistemas) o iterativo (entrega un sistema
completo).
• Desarrollo por Fases: el sistema se desarrolla y entrega en partes o fases. Cada fase pro-
porciona una funcionalidad completa que puede ser utilizada o evaluada por los usuarios. Esto
implica que existen dos sistemas operativos en paralelo: el sistema en uso y el sistema en de-
sarrollo. Este enfoque permite una implementación incremental y facilita la incorporación de
mejoras o cambios a lo largo del proceso. Existen dos tipos:
– Incremental: Se entregan subsistemas.
– Iterativo: Entrega un sistema completo.
• Modelo Espiral (Boehm): El modelo espiral combina elementos del modelo en cascada y del
prototipado. Cada ciclo del modelo espiral incluye una planificación, un análisis de riesgos, un
desarrollo y una evaluación (como un modelo en cascada). Al final de cada ciclo, se realiza una
revisión que incluye todo el ciclo anterior y se planifica el siguiente (en cada ciclo se tiene una
especie de prototipo). Esto permite una evaluación continua y ajustes incrementales, facilitando
la gestión de riesgos y la adaptación a cambios a lo largo del desarrollo.
2 Es imposible que sean iguales.

6
3 Metodologı́as Ágiles
Las metodologı́as ágiles se centran en la entrega rápida y continua de software. Estas metodologı́as
de desarrollo se basan en enfoques iterativos e incrementales, donde los requisitos y las soluciones
evolucionan a través de la colaboración de equipos autoorganizados y multidisciplinarios.

Los principios fundamentales de las metodologı́as ágiles incluyen:

• Individuos e interacciones sobre procesos y herramientas.

• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación contractual.
• Respuesta ante el cambio sobre seguir un plan.

3.1 Ejemplos de Metodologias Agiles

3.1.1 eXtreme Programming (XP)
Su acción consiste en llevar a todo el equipo reunido en la presencia de prácticas simples, con suficiente
información para que el equipo pueda ver dónde están y para ajustar las prácticas a su situación
particular. Entre sus prácticas clave se incluyen:

• Programación en Parejas: Los desarrolladores trabajan en parejas en una sola estación de

trabajo, lo que fomenta la colaboración, la revisión continua del código y el intercambio de
conocimientos.
• Desarrollo Iterativo e Incremental.
• Pruebas Unitarias Continuas: para asegurar que el código funcione correctamente y que los
cambios no introduzcan errores.

3.1.2 Scrum
Scrum es una metodologı́a ágil que organiza el trabajo en ciclos cortos llamados sprints (generalmente
de 2 a 4 semanas). Durante cada sprint, el equipo desarrolla una parte funcional del producto, pri-
orizando las caracterı́sticas más valiosas para el cliente. El Product Owner define y prioriza los
requerimientos, el Scrum Master facilita el proceso y elimina obstáculos, y el Scrum Team de-
sarrolla las funcionalidades comprometidas. Los artefactos como el Product Backlog y el Sprint
Backlog organizan el trabajo, mientras que herramientas como el Burndown Chart permiten mon-
itorear el progreso.

Los roles y artefactos principales en Scrum son:

• Roles:
– Product Owner (Propietario del Producto): Es responsable de definir y priorizar los
requisitos del proyecto, asegurando que el equipo de desarrollo trabaje en las funcionalidades
más valiosas para el cliente.
– Scrum Master: Facilita la aplicación de la metodologı́a Scrum, guı́a al equipo en las
reuniones y ayuda a resolver cualquier problema que pueda surgir. También actúa como un
escudo contra las presiones externas que podrı́an afectar al equipo.
– Scrum Team: Son los responsables de desarrollar y entregar la funcionalidad definida en
el Product Backlog. El equipo trabaja de manera autónoma para cumplir con los objetivos
del Sprint.
– Usuarios o Clientes: Son los beneficiarios finales del producto. Aportan ideas, sugerencias
y necesidades a medida que ven el progreso del desarrollo.

7
 • Artefactos:
– Product Backlog: Es una lista priorizada de todas las funcionalidades y requisitos desea-
dos para el producto. El Product Backlog es dinámico y se ajusta continuamente en función
de las necesidades del cliente y del negocio.
– Sprint Backlog: Es una lista de las funcionalidades y tareas que el equipo de Scrum se
compromete a desarrollar durante un Sprint especı́fico. Incluye las tareas necesarias para
completar las historias de usuario seleccionadas del Product Backlog.
– Burndown Chart: Es un gráfico que muestra el trabajo acumulado versus el trabajo
realizado a lo largo del tiempo del Sprint. Permite visualizar el progreso diario y ayuda a
identificar cualquier desviación del plan.

3.1.3 Crystal
3.1.4 Adaptative software development (ASD)

8
4 Elicitación de Requerimientos
Al iniciar un proyecto es necesario saber lo que el usuario quiere, cómo lo quiere (como lo planifico),
cuándo (en que plazos espera obtener la solución) y porqué (el porque nos ayudara a saber realmente
lo que quiere). Es por ello que la comunicación con el cliente/usuario es muy importante, para poder
entender los requerimientos del usuario.
La definición de elicitación de requerimientos es la siguiente:

La elicitacion de requisitos es el proceso de adquirir (“eliciting”) todo el conocimiento rele-

vante necesario para producir un modelo de los requerimientos de un dominio de problema.

El mismo busca:

• Conocer el dominio para poder comunicarse con los clientes y usuarios, y conocer sus problemas.
Básicamente, es entender el contexto de la problemática.
• Conocer el sistema actual, si es que existe.
• Identificar necesidades de los clientes y usuarios.

4.1 Requerimientos
Un requerimiento (o requisito) es una caracterı́stica del sistema o una descripción de algo que el sistema
es capaz de hacer con el objeto de satisfacer el propósito del sistema. Básicamente, se trata de una
necesidad del sistema, en términos menos técnicos.

4.1.1 Fuentes de requerimientos

Las fuentes de requerimientos son de donde vamos a sacar la información de como seran las caracter-
isticas del sistema:

• Documentación.
• Los stakeholders: cualquier persona o grupo que se vera afectado por el sistema, directa o
indirectamente. Por ej: Clientes, usuarios finales, gerentes, técnicos/ingenieros, etc.
• Especificaciones de sistemas similares.

4.1.2 Puntos de Vista

Los stakeholders pueden clasificarse según su punto de vista:

• Interactuadores: representan a las personas u otros sistemas que interactúan directamente con
el sistema.
• Indirecto: representan a los stakeholders que no utilizan el sistema ellos mismos pero que
influyen en los requerimientos de algún modo.
• Dominio: aspectos del entorno o el campo especı́fico en el que opera el sistema que afectan sus
requerimientos. Esto incluye las reglas, regulaciones, normas, o caracterı́sticas particulares del
sector o industria donde se implementa el sistema. No involucra a personas o usuarios, sino a
factores externos y abstractos que condicionan el desarrollo del sistema.

4.2 Posibles problemas

4.2.1 Problemas de comunicación
La elicitacion de requisitos es una actividad mas social y psicológica que técnica/tecnológica, es por
ello, que es necesario tener en cuenta los problemas de caracter social que pueden existir, los cuales
son la principal fuente de error.

9
Problemas de comunicación por parte del cliente
• Dificultad para expresar claramente las necesidades.
• No ser conscientes de sus propias necesidades: básicamente no saber que y porque lo quiere.
• No entender cómo la tecnologı́a puede ayudar.
• Miedo a parecer incompetentes por ignorancia tecnológica: no proponer soluciones tecnológicas
por miedo a parecer un burro.

Problemas de comunicación por parte del desarrollador

• Falta de previsión de las consecuencias (no entender alternativas o no tener una visión global).
• Cultura y vocabulario diferentes: principalmente el problema es hablar en vocabulario técnico
que el cliente no entienda.
• Intereses distintos en el sistema a desarrollar.
• Medios de comunicación inadecuados (diagramas que no entienden los clientes y usuarios).
• Conflictos personales o polı́ticos.

4.2.2 Limitaciones cognitivas (por el lado del desarrollador)

• No conocer el dominio del problema.
• Hacer suposiciones del dominio o de la solución que no fueron especificados.
• Hacer simplificaciones muy grandes.

4.2.3 Conducta humana

• Ambigüedad de roles. No se sabe quién es responsable de qué parte del sistema o quién toma
decisiones clave.
• Pasividad.
• Temor a que el nuevo sistema lo deje sin trabajo.

4.2.4 Técnicos
• Complejidad del dominio del problema.
• Complejidad de los requisitos.

4.3 Técnicas de elicitacion

Son las que nos permiten obtener los requerimientos.

4.3.1 Entrevistas
La técnica de entrevistas busca recolectar información personal, como opiniones y sentimientos del
entrevistado, sobre un propósito especı́fico a través de preguntas. Aunque las entrevistas se realizan
preferentemente de manera cara a cara, también pueden llevarse a cabo de forma virtual.

Ventajas:
• Inclusión del entrevistado: El entrevistado se siente involucrado en el proyecto, lo que puede
aumentar la calidad de la información proporcionada.
• Retroalimentación directa: Permite obtener retroalimentación directa del entrevistado, lo
que facilita la comprensión de sus necesidades y opiniones.

10
 • Adaptación de preguntas: Las preguntas pueden adaptarse en función de las respuestas del
entrevistado, lo que permite explorar temas relevantes en profundidad.
• Información no verbal: Se puede captar información adicional a través de los gestos y expre-
siones del entrevistado, lo que es más fácil de observar en una entrevista cara a cara.

Desventajas:
• Costo: Tanto el entrevistado como el entrevistador deben dedicar tiempo y recursos humanos,
lo que puede hacer que las entrevistas sean costosas.
• Dependencia de habilidades: La calidad de la entrevista depende en gran medida de las
habilidades del entrevistador y de la disposición del entrevistado.
• Preferencia por reuniones presenciales: El mejor resultado se obtiene generalmente en
reuniones presenciales, donde se puede captar más información no verbal.

Tipos de Entrevistas:
• Estructuradas (Cerradas): El entrevistador tiene un conjunto especı́fico de preguntas para
hacer al entrevistado. Se enfoca en un requerimiento puntual y no permite adquirir un amplio
conocimiento del dominio.
• No Estructuradas (Abiertas): El entrevistador guı́a la conversación de manera más general.
No hay preparación de preguntas especı́ficas, y se inicia con preguntas generales para conocer el
problema, la gente involucrada, etc.

Tipos de Preguntas:
• Preguntas Abiertas: Permiten al entrevistado responder de manera libre y detallada.
– ¿Qué opinión tiene del sistema actual?
– ¿Cómo describe su trabajo?
• Preguntas Cerradas: Las respuestas son directas, cortas o de selección especı́fica.
– ¿Quién recibe este informe?
– ¿Cuántas personas utilizan el sistema?
• Preguntas de Sondeo: Permiten obtener más detalles sobre un tema especı́fico.
– ¿Podrı́a dar detalles sobre. . . ?
– ¿Podrı́a dar un ejemplo de. . . ?

Tipos de organizaciones:
• Inductiva: Comienza con preguntas especı́ficas y se amplı́a a conclusiones generales.
• Deductiva: Parte de principios generales y se aplica a casos especı́ficos.
• Diamante: Inicia con preguntas cerradas, sigue con abiertas para profundizar y concluye con
preguntas cerradas, enfocando de nuevo el análisis.

Cuidados a tener en cuenta:

• Escuchar activamente.
• Hacer una citación al entrevistado.
• Establecer y respetar el horario pactado.
• La entrevista se debe realizar en un lugar privado.
• Informar al entrevistado el tema a tratar antes de la reunión.

11
 • Se deben evitar preguntas sesgadas o con intención, amenazantes o crı́ticas.
• No incluir opinión como parte de la pregunta.
• Evitar realizar preguntas largas y complejas.

4.3.2 Cuestionarios
Documentos que permiten al analista recabar información y opiniones generalizadas de un gran número
de personas.

Ventajas:
• Respuesta rápida.
• Económicos.
• Anónimos.
• Ideal cuando las personas están dispersas.

Desventajas:
• No se puede analizar el lenguaje corporal.
• No se pueden aclarar respuestas incompletas.
• Difı́ciles de preparar.
Es importante que las preguntas de un cuestionario no limiten las respuestas de los encuestados.
Para lograr esto, se debe dejar suficiente espacio para que las personas puedan expresar sus ideas de
manera clara y detallada, evitando respuestas demasiado cortas o cerradas que restrinjan la información
obtenida. Además, es fundamental no apresurar a quien responde; cada persona necesita tiempo para
reflexionar y proporcionar respuestas completas.
El cuestionario debe ser diseñado para resultar ameno y no generar tensión o incomodidad. Las
preguntas deben estar formuladas de manera clara y amigable, evitando cualquier tono que pueda
percibirse como agresivo o intrusivo. Es crucial que las preguntas no sugieran respuestas o asuman
conocimientos previos que los encuestados podrı́an no tener, ya que esto puede sesgar las respuestas y
comprometer la imparcialidad del cuestionario.

4.3.3 Muestreo de la documentación, las formas y los datos existentes

Recolección de hechos a partir de la documentación existente:

• Documentos que describen la funcionalidad del negocio que esta siendo analizado: bases de datos,
formularios, sistemas en funcionamiento.
• Documentación de sistemas anteriores: Diagramas, repositorios del proyecto, manuales.

4.3.4 Investigación y visitas al lugar

• Investigar el dominio: investigar acerca de todo lo que rodea el mundo del cliente.
• Patrones de soluciones: que soluciones sirvieron para otras organizaciones.
• Revistas especializadas.
• Buscar problemas similares en internet.
• Consultar otras organizaciones.

4.3.5 Observación del ambiente de trabajo

El analista se convierte en observador de las personas y actividades con el objeto de aprender acerca
del sistema.

12
Ventajas:
• El analista puede ver exactamente lo que se hace (tareas difı́ciles de explicar con palabras).
• Análisis de disposiciones fı́sicas, tránsito, iluminación, ruido.
• Económica en comparación con otras técnicas.

Desventajas:

• La gente se siente incómoda siendo observada

• Algunas actividades del sistema pueden ser realizadas en horarios incómodos.
• Las tareas están sujetas a interrupciones.
• Tener en cuenta que la persona observada puede estar realizando las tareas de la forma “correcta”
y no como lo hace habitualmente.

4.3.6 Planeación conjunta de requerimientos (JRP o JAD)

Se reúnen todos los interesados para poner en común los requerimientos. Es la mejor opción en cuanto
a resultados, pero también la más difı́cil de implementar, ya que es complicado organizar los horarios
y asegurar que los participantes sean organizados.

Participantes de JRP:

• Patrocinador: Miembro de la dirección con autoridad sobre los departamentos que participan.
Es el responsable del proyecto y toma las decisiones finales.
• Facilitador: Dirige las sesiones y tiene amplias habilidades de comunicación y negociación.
• Usuarios y Gerentes: Los usuarios comunican los requerimientos y los gerentes los aprueban.
• Secretarios: Llevan el registro de la sesión y publican los resultados utilizando herramientas
CASE.
• Equipos de IT: Escuchan y toman nota de los requerimientos.
Joint Requirements Planning. Se refiere a un proceso en el que los interesados se reúnen para
identificar y priorizar los requerimientos de un proyecto.
Joint Application Development. Se reúnen usuarios y desarrolladores para definir los requerimientos
y crear soluciones de manera conjunta.

4.3.7 Lluvia de Ideas - Brainstorming

Técnica para generar ideas al alentar a los participantes a ofrecer tantas ideas como sea posible en
un corto tiempo, sin ningún análisis hasta que se hayan agotado las ideas. Se realizan reuniones del
equipo involucrado en la resolución del problema.

Principios en los que se basa esta técnica:

• Cuantas más ideas se sugieren, mejores resultados se conseguirán.

• La producción de ideas en grupos puede ser más efectiva que la individual.
• Las ideas de una persona pueden hacer que aparezcan otras por “contagio”.
• A veces, las mejores ideas aparecen tarde.
• Es mejor elegir entre una variedad de soluciones.
Luego del surgimiento de ideas, se pueden filtrar para quedarse con las que son viables, y posteri-
ormente ordenar las ideas filtradas que queden según distintos criterios.

13
5 Ingenierı́a de Requerimiento
La ingenierı́a de requerimientos es la disciplina que recolecta, organiza y documenta requerimientos
de forma sistémica para desarrollar una especificación completa, consistente y no ambigua, la cual
servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen
las funciones que realizará el sistema. En pocas palabras, es el proceso mediante el cual se crean
especificaciones precisas acerca de los requerimientos.

5.1 Requerimiento
Un Requerimiento (o requisito) es una caracterı́stica del sistema o una descripción de algo que el
sistema es capaz de hacer con el objeto de satisfacer el propósito del sistema.

5.1.1 Requerimientos mal tomados

Los errores asociados a la toma de requerimientos son mas costosos (en tiempo y dinero) cuanto mas
tarde son detectados, es por ello, que es muy importante esta etapa. Si asociamos valores subjetivos
a la detección del error de requerimiento entonces obtenemos el siguiente esquema:

5.2 Proceso
El proceso que se lleva a cabo en la ingenierı́a de requerimientos para obtener un documento de
requerimientos puede describirse mediante el siguiente diagrama:

Estudio de Obtención y análisis Especificación de Validación de

viabilidad de requerimientos requerimientos requerimientos

Informe de
viabilidad Modelos del
sistema

Requerimientos del
usuario del sistema

Documento de
requerimientos

5.2.1 Estudio de Viabilidad

En esta etapa se debe realizar un informe acerca de la viabilidad del sistema a desarrollar (viabilidad
de los requerimientos del sistema). Esta etapa es fundamental para sistemas nuevos.
Responde a preguntas como:
• ¿El sistema contribuye a los objetivos generales de la organización?
• ¿El sistema se puede implementar con la tecnologı́a actual?
• ¿El sistema se puede implementar con las restricciones de costo y tiempo?

14
 • ¿El sistema puede integrarse a otros que existen en la organización?
• ¿El sistema se puede implementar con mis conocimientos?
• ¿El sistema se puede implementar legalmente?
Además de incluir toda esta información, se debe agregar al informe de viabilidad una
conclusión de si se debe realizar o no el proyecto, aunque este proceso no determina si se termina
realizando o no.

A la hora de redactar los requerimientos debemos asegurarnos que cada uno de ellos cumple con
las siguiente propiedades:

• Necesario: Su omisión provoca una deficiencia.

• Conciso: Fácil de leer y entender.
• Completo: No necesita ampliarse.
• Consistente: No contradictorio con otro.
• No ambiguo: Tiene una sola implementación.
• Verificable: Puede testearse a través de inspecciones, pruebas, etc.

5.2.2 Obtención y Análisis de requerimientos

Una vez obtenidos los requerimientos a partir de técnicas de elicitación es muy importante su análisis.
Es por ello que podemos hacer la siguiente clasificación:

• Requerimientos funcionales: caracterı́sticas de cómo el sistema debe comportarse o no

ante una interacción con un usuario. Algunos ejemplos son:

– El sistema debe permitir a los usuarios autenticarse con un nombre de usuario y contraseña.
– El sistema debe enviar notificaciones por correo cuando se actualice el perfil del usuario.
– El sistema no debe permitir el acceso a áreas restringidas a usuarios no autorizados.

• Requerimientos no funcionales: restricción sobre la implementación del sistema. Son carac-

terı́sticas que limitan el desarrollo de la solución. Algunos ejemplos:

– Software: el sistema debe utilizar el lenguaje de programación X, el motor de bases de

datos Y, o ciertas bibliotecas.
– Hardware: el sistema debe funcionar en dispositivos con X especificaciones mı́nimas de
hardware.
– Portabilidad: el sistema debe ser compatible con los sistemas operativos X, Y y Z.
– Legales: el sistema debe cumplir con las regulaciones de protección de datos, ser apto para
mayores de edad, etc.
– Diseño: se debe emplear el logo de la empresa, mantener una paleta de colores especı́fica,
entre otros.
– Estándares: el sistema debe seguir estándares de codificación, accesibilidad o seguridad
especı́ficos.
– Otros: fechas de entrega, tiempos de respuesta, etc.

Tener en cuenta que un requerimiento no funcional se diferencia del funcional, en muchos casos,
por su escritura, ya que la mayorı́a de las veces estas limitaciones externas deben ser implementadas
en el sistema, lo que lo convertirı́a en una caracterı́stica de implementación del mismo, es decir, un
requerimiento funcional. Por ejemplo:

• Funcional: El sistema debe implementar una verificación de edad y prohibir el uso del sistema
para menores de edad.

15
 • No funcional: El sistema debe restringir el acceso a usuarios menores de 18 años.

Ejemplo personal: Se requiere una aplicación móvil para alquilar canchas de tenis de un club
especifico de la ciudad de La Plata. El club cuenta con dos canchas de tenis, las cuales se alquilan solo
entre las 8 y 21hs.

• Requerimientos funcionales: El sistema debe verificar que el usuario esté registrado antes
de permitirle alquilar una cancha; Los usuarios deben poder reservar una cancha seleccionando
la fecha y el horario; El sistema debe enviar una notificación por correo electrónico cuando se
confirme un alquiler, etc.
• Requerimientos no funcionales: La aplicación debe funcionar en celulares; El club de tenis
tiene dos canchas; La aplicación debe estar disponible durante el horario de funcionamiento de
las canchas; La interfaz del sistema debe respetar el logo del club y su paleta de colores; El
sistema debe estar listo para el arranque del próximo año, etc.

Otra posibilidad de clasificación de requerimientos es por requerimiento del dominio (caracterı́sticas

del dominio que influyen), requerimientos por prioridad (dependiendo que tan necesario son), requer-
imientos del usuario (escritos en lenguaje natural para que el usuario entienda) y requerimientos del
sistema (establecen con detalle caracterı́sticas del sistema).

5.2.3 Especificación de requerimientos

Una vez que tenemos los requerimientos y su correspondiente análisis, estamos listos para especificarlos
(decir cuales son, documentarlos). La especificación de requerimientos debe ser: correcta, no ambigua,
completa, verificable, consistente, comprensible por los consumidores, modificable, rastreable, inde-
pendiente del diseño, anotada, concisa, organizada y utilizable en operación y mantenimiento.

Se deben confeccionar tres documentos:

• Documento de definición de requerimientos: Listado completo de todas las cosas que el
cliente espera que haga el sistema propuesto.
• Documento de especificación de requerimientos: definición en términos técnicos.
• Documento de especificación de requerimientos de Software (IEEE).
Existen distintas técnicas para especificar requerimientos.

5.2.4 Validación de requerimientos

La validación de requerimientos es el proceso mediante el cual se asegura que los requerimien-
tos definidos son los que realmente necesita el usuario o cliente. Esta etapa es crucial porque
permite detectar y corregir errores en una etapa temprana, evitando que los costos de corrección au-
menten significativamente a medida que el desarrollo avanza. La validación solo puede hacerse con el
usuario.
Para entender la validación en su totalidad, es importante distinguirla de la verificación. La ver-
ificación se enfoca en determinar si un producto de software en una fase especı́fica cumple con los
requerimientos definidos en la fase anterior (¿estoy haciendo el software correctamente?). En otras
palabras, la verificación asegura que el producto se ha construido de acuerdo con las especificaciones
establecidas. Por otro lado, la validación se centra en evaluar si el software desarrollado cumple con
las necesidades y expectativas del usuario final (¿hice el software correcto?). Es decir, valida que el
software haga lo que el usuario realmente necesita y espera.
La validación generalmente implica primero revisiones informales, que consisten en reuniones
con los stakeholders para discutir y ajustar los requerimientos preliminares. Posteriormente, se realiza
una revisión formal donde el equipo de trabajo presenta al cliente una explicación detallada de los
requerimientos, asegurando que el cliente comprenda sus implicancias y que el software se alinee con
sus expectativas.

16
6 Técnicas para especificar requerimientos
6.1 Estáticas
Se describe el sistema a través de las entidades u objetos, sin describir como cambian con el tiempo,
ya que si no depende del tiempo es una descripción útil y adecuada.

Ejemplos de esta son las expresiones son:

• Referencia indirecta. Ej: ecuaciones.

• Relaciones de recurrencia. Ej: Fibonacci.
• Definición axiomática.
• Expresiones regulares.
• Abstracciones de datos.

6.2 Dinámicas
Se describe al sistema en función de los cambios que ocurren a lo largo del tiempo. Se considera que
el sistema está en un estado particular hasta que un estı́mulo lo obliga a cambiar su estado.

6.2.1 Tablas de decisión

Las tablas de decisión permiten resumir de forma concisa las reglas lógicas que determinan las acciones
a tomar según las condiciones de un problema.
Se estructuran en columnas que representan reglas. Cada fila contiene condiciones que pueden
ser verdaderas o falsas, y las acciones se marcan con una ”X” cuando deben ejecutarse según la regla
correspondiente.

REGLA 1 REGLA 2 ···

COND 1
COND 2
···
ACCIÓN 1
ACCIÓN 2
···

Table 1: Modelo de Tabla de Decisión completa.

La anterior tabla de decision es una tabla completa, puesto que describe las acciones a tomar
para todas las reglas posibles. Si hay redundancia en las reglas, algunas columnas pueden eliminarse,
ya que no dependen de todas las condiciones. Si la tabla tiene reglas que determinan las mismas
condiciones de acciones distintas entonces se trata de una tabla contradictoria.

6.2.2 Diagramas de transición de estados

Los diagramas de transición de estados utilizan máquinas de estados finitos para describir el compor-
tamiento de un sistema. En este enfoque, el sistema cambia de estado en respuesta a ciertos eventos
(externos o internos). P P
Se representan como una 5-tupla (S, , T, s, A), donde S es el conjunto de estados posibles, el
conjunto de eventos o alfabeto, T la función de transición, s el estado inicial y A el conjunto de estados
finales.

17
 Figure 1: Ejemplo de Transición de Estados.

Representaciones posibles:
• Gráfico en persiana: Esta representación muestra los estados y las transiciones del sistema
en una estructura de tipo persiana, donde los estados se presentan en filas y las transiciones se
indican entre ellos mediante flechas o lı́neas. Cada transición se activa en función de un evento
o condición externa. Este formato permite una visualización clara y ordenada de los posibles
cambios de estado de un sistema.
• Diagrama de transición y estado (DTE): Los diagramas de transición extendidos (DTE) son
una versión más detallada de los diagramas de transición de estados convencionales. Además de
los estados y las transiciones, un DTE incluye condiciones adicionales, como acciones asociadas
a las transiciones o eventos externos que influyen en los cambios de estado.
Para construir un DTE se siguen los siguientes pasos:
1. Identificar los estados principales del sistema.
2. Si un estado es complejo, se puede descomponer en subestados o detallar sus transiciones
internas.
3. Desde el estado inicial, identificar los cambios de estado mediante flechas, especificando las
transiciones entre ellos.
4. Analizar las condiciones y acciones que determinan cuándo y cómo se produce cada tran-
sición.
5. Verificar la consistencia del diagrama:
– Asegurarse de que todos los estados estén debidamente definidos.
– Comprobar que todos los estados son alcanzables desde el estado inicial.
– Verificar que se pueda salir de todos los estados, evitando situaciones de bloqueo.

6.2.3 Redes de Petri

Las redes de Petri son un modelo que se utiliza para analizar sistemas con tareas concurrentes o
paralelas, donde la importancia radica en la sincronización. Pueden representarse con una 4-tupla
C = (P, T, I, O) donde P son los sitios, T las transiciones, I son las funciones de entrada y O la
función de salida.

¿Como funciona?

• Los eventos se representan mediante transiciones.

• Los estados se representan mediante sitios.
• Los arcos indican a través de una flecha la relación entre sitios y transiciones y viceversa.

18
 • A los sitios se les asignan tokens que se representan mediante un número o puntos dentro del
sitio. Esta asignación de tokens a lugares constituye la marcación y es util para la coordinación
de eventos y estados.
• Una vez que ocurre un evento, un token puede “viajar” de uno de los estados a otro.
• Una transición está habilitada cuando cada sitio de entrada tiene al menos un token, igualando
la cantidad de tokens como arcos hacia la transición existen.
• Disparar una transición habilitada implica remover tokens de los lugares de entrada (uno por
cada sitio de entrada) y distribuir tokens en los lugares de salida (un token por cada sitio de
salida).

Paso a paso de funcionamiento general de una red de Petri:

1. A cada sitio de entrada se le asignan tokens, los cuales representan el estado inicial del sistema.
2. Una transición estará habilitada si cada sitio de entrada tiene al menos tantos tokens como arcos
que lo conectan a la transición. Es decir, si un sitio tiene n arcos hacia una transición, debe
contener al menos n tokens para habilitar dicha transición, teniendo en cuenta que todos los
estados de entrada deben tener al menos un token.
3. Una vez habilitada la transición, se dispara. Esto significa que se elimina 1 token a cada estado
de entrada.
4. Tras el disparo de la transición, los tokens se distribuyen en los sitios de salida. La cantidad de
tokens que recibe cada sitio de salida depende del número de arcos que conectan la transición a
dicho sitio: por cada arco, se agrega un token al sitio de salida correspondiente.

6.2.4 Casos de Uso

Los casos de uso son una herramienta clave para capturar los requerimientos funcionales de un
sistema. Reflejan la interacción entre un usuario y el sistema, destacando cómo se utilizan las
funcionalidades del sistema para cumplir con los objetivos del usuario. Cada caso de uso se centra en
una única funcionalidad.

Este modelo puede representarse como:

• Diagrama de Casos de Uso: Ilustra visualmente las interacciones entre el sistema y los actores.
• Escenarios (narración del CU): Describen de manera detallada la secuencia de acciones entre
el actor y el sistema para realizar una funcionalidad.

Elementos del diagrama:

• Caso de Uso: Representa un objetivo o funcionalidad especı́fica del sistema. Describe la

secuencia de actividades necesarias para lograr dicho objetivo.
• Actores: Son quienes interactúan con el sistema, iniciando una actividad. Los actores pueden
ser usuarios, otros sistemas o dispositivos externos.
• Relaciones:
– Asociaciones: Vı́nculos entre actores y casos de uso. Se indican con una flecha si el actor
indica el caso de uso, y con una linea si el caso de uso interactúa con el actor.
– Extensiones (Extends): Se representan con una flecha etiquetada como <<extension>>
e indican una excepción o variación en un caso de uso.
– Uso o Inclusión (Uses): Flechas con <<usos>>, que indican tareas comunes que com-
parten dos casos de uso. Deben ser accedidos por lo menos desde dos CU (en caso contrario
no tendrı́a sentido).
– Dependencia (Depends): Flechas con <<dependen de>>, que señalan que un caso de
uso no puede realizarse sin completar otro antes.

19
 – Herencia: Relación entre actores, donde un actor hereda funcionalidades de otros.

A partir del diagrama completo se pueden realizar los escenarios.

Beneficios de Casos de Uso:

• Descompone el alcance del sistema en piezas mas manejables.

• Medio de comunicación con los usuarios: utiliza lenguaje común y fácil de entender por las partes.
• Permite estimar el alcance del proyecto y el esfuerzo a realizar.
• Define una lı́nea base para la definición de los planes de prueba.
• Define una lı́nea base para toda la documentación del sistema.
• Proporciona una herramienta para el seguimiento de los requisitos.

6.2.5 Historias de Usuario

Una historia de usuario es una forma concisa de describir un requisito de software, utilizando el lenguaje
común del usuario. Generalmente, se expresa en una o dos frases y se complementa con discusiones
con los usuarios y pruebas de validación. Las historias de usuario permiten gestionar los requisitos de
manera rápida3 , sin necesidad de extensos documentos formales ni grandes inversiones de tiempo.

Formato de una Historia de Usuario:

Las historias de usuario suelen redactarse con la siguiente estructura4 : “Como (rol) quiero (algo)
para poder (beneficio)”.

Caracterı́sticas de las Historias de Usuario:

• Independientes entre si.

• Negociables: no deben considerarse como especificaciones cerradas. En lugar de eso, son puntos
de partida para el diálogo entre los desarrolladores y los usuarios o stakeholders.
• Valoradas por clientes/usuarios.
• Estimables: Permiten estimar el tiempo necesario para completarlas, lo que facilita la planifi-
cación del proyecto (en general, de 10hs a 2 semanas).
• Pequeñas: Información limitada.
• Verificables: Deben cubrir requisitos funcionales que se pueden verificar.

Ventajas: Pueden implementarse rápidamente, necesitan poco mantenimiento, mantiene relación

cercana al cliente , etc; siendo ideal para proyectos con requisitos volátiles.
Desventajas: Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones, se re-
quiere un contacto permanente con el cliente (los desarrolladores deben tener la posibilidad de dis-
cutirlas con los clientes), podrı́a resultar difı́cil escalar a proyectos grandes y requiere desarrolladores
muy competentes.

3 Son utilizadas en las metodologı́as de desarrollo ágiles para la especificación de requisitos.

4 Deben responder a: ¿Quién se beneficia?, ¿qué se quiere? y ¿cuál es el beneficio?

20
7 Iniciativas
Las iniciativas son grandes objetivos estratégicos que buscan alcanzar un cambio significativo o una
mejora importante dentro de una organización, proyecto o equipo de trabajo. Se definen a un nivel
alto, es decir, no se centran en detalles especı́ficos, sino en resultados amplios y de impacto. Una
iniciativa puede abarcar varios proyectos o actividades y suele estar alineada con la visión y misión de
la organización o equipo.
En muchos casos, las iniciativas buscan ser ambiciosas, especialmente si el contexto lo permite.
La idea es que actúen como metas desafiantes que impulsen a los involucrados a innovar y esforzarse
más allá de los lı́mites habituales. Las iniciativas pueden ser el primer paso para movilizar recursos y
definir prioridades, ya que proporcionan una visión clara de hacia dónde se quiere dirigir el esfuerzo
colectivo.

Ejemplos de iniciativas:

• Transformación digital completa de la empresa: Impulsar la adopción de tecnologı́as

emergentes para mejorar la eficiencia operativa y la experiencia del cliente. Reducción del im-
pacto ambiental: Implementar polı́ticas y prácticas más sostenibles en todos los niveles de la
organización, con el objetivo de reducir la huella de carbono en un 40% en los próximos cinco
años.
• Expansión a nuevos mercados internacionales: Aumentar la presencia en mercados clave
de Asia y Europa, buscando duplicar los ingresos provenientes del exterior en los próximos tres
años.

7.1 Épicas
Las épicas son desgloses más concretos y especı́ficos de una iniciativa. Funcionan como grandes bloques
de trabajo que descienden desde el objetivo principal para hacerlo más manejable y realizable. Las
épicas bajan ”a tierra” el propósito abstracto de la iniciativa, permitiendo que se puedan definir y
ejecutar acciones más concretas. Cada épica puede incluir a su vez varias tareas o historias de usuario
más detalladas que permitan llevar a cabo el trabajo de manera efectiva.
Al dividir una iniciativa en varias épicas, se facilita la organización y seguimiento del progreso,
permitiendo gestionar los recursos de manera más eficiente y asegurando que se estén dando pasos
reales hacia la consecución del objetivo general. Las épicas suelen estar orientadas a resultados más
tangibles y pueden medir el avance de la iniciativa en términos claros y concretos.
Ejemplos de épicas:

• Para la iniciativa de ”Transformación digital completa de la empresa”:

– Implementación de un sistema de CRM automatizado: Selección, integración y
capacitación del personal en una plataforma de gestión de relaciones con clientes que auto-
matice procesos clave.
– Desarrollo de una aplicación móvil para clientes: Crear una aplicación que permita
a los usuarios realizar pedidos, rastrear envı́os y gestionar sus cuentas de manera eficiente.
– Capacitación digital del personal: Programas de formación para que todos los emplea-
dos se adapten a las nuevas herramientas tecnológicas implementadas.
• Para la iniciativa de ”Expansión a nuevos mercados internacionales”:

– Estudio de mercado en Asia y Europa: Investigación de los mercados locales para

identificar oportunidades y adaptar productos y servicios.
– Apertura de oficinas regionales: Establecer oficinas en ciudades clave para mejorar la
presencia local y facilitar las operaciones.
– Contratación de equipos locales: Formar equipos con talento local para manejar las
operaciones y adaptarse a las particularidades de cada mercado.

21
7.2 Mi ejemplo
Se requiere una aplicación móvil para alquilar canchas de tenis de un club especifico de la ciudad de
La Plata. El club cuenta con dos canchas de tenis, las cuales se alquilan solo entre las 8 y 21hs.
Iniciativa 1: Sistema de Reserva en Lı́nea
Épicas:

• Visualización interactiva de disponibilidad: Crear una interfaz interactiva que permita a

los usuarios ver en tiempo real la disponibilidad de las canchas de tenis y elegir el horario que
deseen entre las 8 y 21 hs.
• Integración con notificaciones: Enviar notificaciones automáticas a los usuarios para recor-
darles sus reservas y alertarles sobre la proximidad del inicio de su tiempo de uso.
• Cancelación y modificación de reservas: Habilitar a los usuarios para que puedan cancelar
o modificar sus reservas en función de la disponibilidad actual de las canchas.
Iniciativa 2: Gestión de Pagos y Facturación
Épicas:

• Integración de métodos de pago: Implementar pasarelas de pago que permitan a los usuarios
abonar el alquiler de la cancha directamente desde la aplicación.
• Generación de facturas electrónicas: Automatizar la creación de facturas electrónicas al
completar el pago, con opción de enviar por correo electrónico al usuario.
• Historial de transacciones: Crear un módulo donde los usuarios puedan consultar su historial
de reservas y pagos realizados, proporcionando transparencia y control.

22