1 CAPTURA DE REQUISITOS.

INGENIERÍA DE
REQUERIMIENTOS
Captura de Requisitos: de la visión a los requisitos.
Requisitos: Una especificación de lo que se debería implementar. Son una declaración de lo
que debería hacer el sistema y no de cómo debería hacerlo.

Proceso de averiguar lo que se debe construir; las necesidades, metas objetivos.

La mayor dificultad es que el usuario no sabe lo que quiere. Debemos utilizar lenguaje de
cliente para que el mismo pueda comprender el funcionamiento /resultado. Es difícil porque
el cliente no sabe lo que quiere generalmente.

Visión general de la captura de requisitos.

- Listar requisitos candidatos

- Aportar ideas de cómo comprendemos el sistema
- Decidir si incorporarlas o no al sistema
- Hacer una lista de ideas que se considera un conjunto de requisitos
candidatos, algunos se convierten en requisitos propiamente y se transforman en
artefactos como casos de uso y algunos se dejan para una versión futura.
- Comprender/interpretar contexto del sistema
Hay 2 formas de expresar el contexto de un sistema:
- Modelo de dominio: Describe los conceptos importantes del contexto como
objetos , y los enlaza unos con otros.
- Modelo de negocios: Describe los procesos con el fin de comprenderlos y
especificar qué procesos de negocio soportará el sistema.

- Capturar requisitos funcionales

- Listar los CU

- Capturar requisito no funcionales

 - Especifican propiedades del sistema, como restricciones del entorno, de la
implementación, rendimiento, dependencias de la plataforma, aspectos
físicos y de interfaz.

Modelo de Dominio.
Es una representación visual de las clases conceptuales significativas u objetos del
mundo real en un dominio de interés. Captura los tipos más importantes de objetos en el
contexto del sistema. Los objetos del dominio representan las “cosas” que existen o los
eventos que suceden en el entorno del sistema. Las clases del dominio aparecen en tres
formas típicas:
● Objetos del negocio que representan cosas que se manipulan en el negocio, como
pedidos, cuentas y contratos.
● Objetos del mundo real y conceptos de los que el sistema debe hacer un
seguimiento como la aviación enemiga, misiles y trayectorias.
● Sucesos que ocurrirán o han ocurrido, como la llegada de un avión, su salida y la
hora de la comida.
Estas clases se relacionan a través de asociaciones.
Objetivo de modelado del dominio es comprender y describir las clases más
importantes dentro del contexto del sistema.

Modelo de Negocio.
Desarrollar un modelo de negocio es una alternativa más potente que desarrollar un
modelo de dominio. Modelar el negocio es una técnica para comprender los procesos de
negocio de la organización. El objetivo es identificar los casos de uso del SW y las
entidades de negocio relevantes que el SW debe soportar, de forma que podríamos
modelar sólo lo necesario para comprender el contexto. El resultado de esta actividad es un
modelo del dominio derivado de la comprensión del funcionamiento del sistema de negocio
que lo rodea.
Este modelo se describe mediante diagramas de casos de uso.
Desarrollo del modelo de negocio:
1. Confeccionar un modelo de casos de uso del negocio que identifique los actores del
negocio y los casos de uso del negocio que utilicen los actores.
2. Desarrollar un modelo de objetos del negocio compuesto por trabajadores, entidades
del negocio, y unidades de trabajo que juntos realizan los casos de uso del negocio.
El objetivo es crear trabajadores, entidades del sistema del negocio, y unidades de
 trabajo que realicen los casos de uso del negocio de la manera más eficaz posible,
es decir, rápidamente, con precisión y con un coste bajo.

Principales diferencias entre modelos de Negocios y Dominio:

- Las clases del dominio tienen atributos, pero la diferencia es que además, las de
negocio identifican las operaciones de cada entidad.
- Las clases del dominio se obtienen a partir del conocimiento de expertos, mientras
que las de negocio se derivan a partir de los clientes, identificando CU y luego
buscando entidades.

Clases Conceptuales
Es una idea, cosa u objeto.
Formalmente se puede considerar en términos de:
● Símbolo: que representa la clase.
● Intención: definición de la clase (propósito).
● Extensión: conjunto de ejemplos a los que se aplica la clase conceptual

Identificación de las clases conceptuales:

A partir de la descripción original de la situación del sistema. Se pueden usar 2
técnicas:
● Utilización de una lista de categorías.
 ● Identificación de frases nominales: Consiste en identificar las frases nominales
(sustantivos) en las descripciones de un problema y considerarlas conceptos o
atributos idóneos. Se deben identificar:
○ Sustantivos comunes.
○ Entidades físicas.
○ Entidades conceptuales
Ej: El cliente debe ingresar la tarjeta en el cajero automático para poder realizar una
extracción de su cuenta.
De las clases candidatas se selecciona aquellas que:
● Son relevantes al problema.
● Deben ser precisas.
● No deben:
○ ser roles de clases
○ ser redundantes
○ responder a un sistema completo
○ ser atributos de otras clases
○ corresponderse con actores

Tipos de Requisitos: Casos de Uso.

Un caso de uso especifica una secuencia de acciones que el sistema puede llevar a
cabo interactuado con sus actores, incluyendo alternativas dentro de la secuencia. Es una
especificación del comportamiento de “cosas” dinámicas, en este caso, de instancia de
casos de uso.
Una instancia de caso de uso es la realización de un caso de uso, otra forma de
decirlo es que una instancia de caso de uso es lo que el sistema lleva a cabo cuando
“obedece a un caso de uso”. Cuando se lleva a cabo una instancia de un caso de uso, ésta
interactúa con instancias de actores y una secuencia, especificada por el diagrama de
estados o un diagrama de actividad, de acciones es ejecutada según se especifica en el
caso de uso.
//esto no sé
Existen 2 tipos de requisitos:
● Los funcionales: qué comportamiento debería ofrecer el sistema.
● Los no funcionales : una propiedad específica o restricción del sistema.
Requisitos Adicionales:
Son requisitos No Funcionales que no pueden asociarse a un CU en concreto. Pueden ser:
- Requisito interfaz: Especifica la interfaz con un elemento externo con el cual debe
interactuar el sistema, o que establece factores de relevancia en esa interacción.
- Requisito Físico: Especifica una característica física que debe poseer un sistema
(material, forma, tamaño, peso)

Ingeniería de Requerimientos.
Proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un
sistema. Su objetivo es entregar una especificación de los requisitos de Sw completa.
Proceso de la Ingeniería de requerimientos:
Estudio de viabilidad
Tiene como entrada un conjunto de requerimientos de negocio preliminares, una
descripción resumida del sistema y cómo éste pretende contribuir a los procesos del
negocio. Los resultados del estudio deberían ser un informe que recomiende si merece o no
la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema.
¿Contribuye al sistema?¿Es asequible?¿Qué pasa si no se lo implementa?¿Tecnologías?
Obtención y análisis de requerimientos
Determina el dominio de la aplicación, qué servicios debe proporcionar el sistema, el
rendimiento requerido del sistema, las restricciones de HW, etc. Es un proceso iterativo y la
comprensión de los requerimientos mejora con cada vuelta.
Stakeholder: persona o grupo que se verá afectado por el sistema, directa o
indirectamente.
Actividades
● Descubrimiento de requerimientos: interactuar con stakeholders para recopilar sus
requerimientos.
● Clasificación y organización de requerimientos: Organización en grupos de los
requerimientos recopilados.
● Ordenación por prioridades y negociación de requerimientos: Ordenar
requerimientos prioritarios, encontrar y resolver req en conflicto a través de
negociación.
● Documentación de requerimientos: Documentar requerimientos y entrar en la
siguiente vuelta de la espiral.
Descubrimiento de requerimientos
Recoger información sobre el sistema propuesto y los existentes y extraer los
requerimientos del usuario y del sistema de esta información. Se analiza un enfoque que
ayuda a asegurar a que se consiga una amplia cobertura de stakeholders al descubrir
requerimientos, y se describen técnicas de descubrimiento de requerimientos.
Validación de requerimientos
Trata de mostrar que éstos realmente definen al sistema que el cliente desea. Es
importante ya que los errores en el documento de requerimientos pueden conducir a
importantes costos por repetición. Verificaciones de:
● Validez: el razonamiento y el análisis pueden identificar que se requieren funciones
adicionales o diferentes.
● Consistencia: los requerimientos no deben contradecirse.
● Completitud: debe incluir requerimientos que definan todas las funciones y
restricciones propuestas.
● Realismo: asegurar que se puedan implementar
● Verificabilidad: redactados de forma verificable, pruebas que demuestren que el
sistema va a cumplir con cada uno de los requerimientos.
Técnicas de validación:
● Revisiones de requerimientos: analizados sistemáticamente por equipo de revisores.
● Construcción de prototipos: modelo ejecutable.
● Generación de casos de prueba: probar requerimientos antes de escribir código.

Principales beneficios de la IR:

- Mejora la calidad del Sw
- Mejora la capacidad de predecir cronogramas de proyectos, así como sus
resultados.
- Disminuye los costos y retrasos, ya que evita posibles errores a reparar.
- Mejora la comunicación entre equipos, ya que hay un consenso entre usuarios /
desarrolladores.

Estudio de prefactibilidad:
Supone un análisis preliminar de una idea para determinar si es viable convertirla en un
proyecto.
Se analiza desde el punto de vista: - Económica: Beneficio>Costo.
- Técnica: Existencia de la tecnología necesaria.
- Operacional: Evalúa si el proyecto tiene apoyo.
- Legal: Aprobación legal del proyecto.

2 DEFINICIONES BÁSICAS. PRODUCTO Y

PROCESO. METODOLOGÌASEQUIPOS DE
TRABAJO
Concepto de Producto y Proceso.
Producto:
Es: - Software
- Programas
- Documentos
- Datos obtenidos

Proceso:
Serie de pasos a seguir para construir un producto. Lo desarrollan la Ingeniería de Sw y la
ingeniería en sistemas. Es importante porque da estabilidad y organización a las
actividades.

Proceso de Sw: Marco de trabajo de tareas requeridas para construir sw de calidad.

Proceso de Sistemas: Marco de trabajo de las tareas para construir

Se dice que el proceso proporciona una interacción entre

- Usuarios y diseñadores
- Usuarios y tecnología
- Diseñadores y Tecnología

Conceptos de Herramientas y utilización en cada Metodología

Las herramientas influyen en el proceso automatizando procesos repetitivos,
mantener las cosas estructuradas, gestionar grandes cantidades de info y para guiarnos a lo
largo de un camino de desarrollo concreto.
El proceso dirige a las herramientas. Especifica la funcionalidad de las herramientas,
los casos de uso de las herramientas. AUTOMATIZACIÓN. A su vez las herramientas
dirigen el desarrollo de un proceso. Deben tener un equilibrio.
La herramienta UML
La tecnología CASE supone la automatización del desarrollo del software,
contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de
información y se plantean los siguientes objetivos:
 ● Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser
realizadas con una herramienta se consigue agilizar el trabajo.
● Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
● Simplificar el mantenimiento de los programas.
● Mejorar y estandarizar la documentación.
● Aumentar la portabilidad de las aplicaciones.
● Facilitar la reutilización de componentes software.
● Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la
utilización de gráficos.
Automatizar:
Ø El desarrollo del software
Ø La documentación
Ø La generación del código
Ø El chequeo de errores
Ø La gestión del proyecto
Permitir:
Ø La reutilización del software
Ø La portabilidad del software
Ø La estandarización de la documentación

Introducción a Metodologías de Sistemas: Definiciones Básicas

Modelos Evolutivos: Incremental, Modelo Espiral, Modelos

Formales.
Modelos Evolutivos:
Consideran la naturaleza evolutiva del software.
Son:
- Iterativo
- Lineal Secuencial
- Desarrollan versiones más complejas

- Análisis: comprender funciones, comportamiento, rendimiento

 - Diseño: Traducir requisitos y definir estructura de datos, detalle de procedimientos.
- Código: Programación
- Pruebas: Detección de errores, control de resultados

Modelo Incremental:

- Cada secuencia produce un incremento de sw

- El primer Incremento es el producto básico
- Cada incremento entrega un producto operacional.

Modelo Espiral:
- Acompaña al Sw durante todo su ciclo de vida
- Entrega un producto básico que evoluciona con cada iteración

Estrategias: de Prototipado, de Ensamblaje de Componentes

Estrategias:
Plan para lograr un objetivo.
Hay 2 tipos:
- Prototipos (ensamblaje de componentes)
- Reutilización
Prototipos:
Versión incompleta de un sistema, que tiene como objetivo la rápida obtención de
información.
Tipos:
- Requisitos: Interfaces, pantallas
- Análisis: Arquitectura general
- Diseño: Comprensión del análisis
- Verticales: Analizar si parte de un problema tiene solución
- Factibilidad: Si es posible avanzar con el proyecto

Reutilización:
Explotación de componentes ya desarrollados.
- Bajo Nivel: Dentro del mismo sistema (herencia)
- Alto nivel: Entre sistemas (Bibliotecas, paquetes)

Proceso Unificado de Desarrollo de Software: centrado en la

arquitectura, iterativo e incremental y guiado por Casos de
Uso.
Proceso Unificado:
- Utiliza UML
- Basado en componentes

Puede ser:
- Dirigido por CU
- Centrado en Arquitectura
- Iterativo e Incremental

Dirigido por CU:

- CU es la interacción usuario-sistema
- El proceso se desarrolla siguiendo los flujos de trabajo de los CU
- Se debe construir el sistema para dar servicio a los usuarios

Centrado en Arquitectura:
- Describe al sistema desde distintos puntos de vista, incluyendo aspectos dinámicos
y estáticos
- Cada producto tiene una función (CU) y una forma (Arq)

Iterativo e incremental:
- Dividir el proyecto en miniproyectos (iteración que resulta en incremento)
- Los incrementos hacen referencia al crecimiento del producto
Introducción a la Gestión de Equipos de Trabajos.
Durante el desarrollo de las actividades el líder tiene que entender que una de sus
principales prioridades es la delegación. La delegación exitosa requiere de:
● Determinación de un calendario de tareas.
● Definición de roles.
● Designación de responsabilidades.
Otra de las acciones ligadas a la gestión de equipos de trabajo es la puesta en
práctica de acciones de motivación. Motivar a los integrantes de un grupo es posible si:
● Se conoce a cada individuo.
● Se vela por su satisfacción laboral.
● Se le ha asignado una tarea para la que está preparado y que no le resulta, ni
demasiado fácil, ni inalcanzable.
● Se le han explicado los objetivos y éstos son realistas y están claros.

Equipos de Alto desempeño. Auto organización de equipos.

Se denomina Equipo de Alto Desempeño (EAD) a un grupo de individuos dentro de
una organización que tienen objetivos claros, conocen los pasos para lograrlos y obtienen
resultados positivos, que pueden ser sostenidos en el tiempo. Pueden estar especializados
en un área específica de trabajo o asumir retos nuevos para descifrar conflictos con los que
antes las organizaciones no se habían topado.

¿Cuáles son las características de un Equipo de Alto Desempeño (EAD)?

Son personas que se encuentran muy motivadas, altamente satisfechas con su

entorno laboral, con las relaciones interpersonales y con las recompensas acordes a su
desempeño.

Los EAD tienen claridad es los objetivos de cada uno de sus individuos, de su
equipo, de su área y de su organización. Esto les permite establecer metas y ciclos de
trabajo para lograr resultados en los tiempos establecidos.

Modelo de Desarrollo de equipos.

Fase 1: Forming (Formación)

En esta etapa el grupo está formándose por lo que se le llama también como etapa
de Preparación o de Orientación. Se caracteriza principalmente porque la gente trata de
destacar, asimismo se denota inseguridad y deficiencia entre los miembros del equipo.

Hay una alta dependencia en el líder en cuanto a guía y dirección. El líder dirige.

Fase 2: Storming (Enfrentamiento/Conflicto)

Los miembros luchan entre sí para adquirir posiciones mientras tratan de establecer
por sí mismos relaciones con otros miembros del equipo y con el líder. Se forman pandillas
y agrupaciones y se pueden dar luchas de poder. El líder actúa como coach.
Fase 3: Norming (Normalización)

Los conflictos se reducen y el grupo está ahora en la mente de sus miembros. Se

forma acuerdo y consenso dentro del equipo, el cual responde bien a la enseñanza del líder.
Roles y responsabilidades son claros y aceptados. El equipo lleva a cabo reuniones para
discutir y desarrollar sus procesos y su forma de trabajo. El líder es respetado por el equipo
y parte del liderazgo es compartido por el equipo. El líder actúa como facilitador.

Fase 4: Performing (Desempeño)

El equipo trabaja con un buen rendimiento y pocos conflictos, está ya preparado

para tomar decisiones sin la necesidad de la participación del líder. El enfoque está en
lograr resultados, el equipo tiene un alto grado de autonomía. Los desacuerdos ocurren
pero son resueltos positivamente dentro del equipo y los cambios necesarios al proceso y a
la estructura son realizados por el mismo.

El equipo requiere que el líder delegue tareas y proyectos pero no necesita ser
instruido o asistido. El líder delega.

Fase 5: Adjourning (Finalización/Disolución)

Esta última etapa, incluida en 1977, doce años después del modelo original ve al
grupo desde una perspectiva global e integradora, mas allá del propósito de las cuatro
primeras fases. En esta fase el grupo contempla su disolución y sus miembros se pueden
mover a nuevas tareas o proyectos, sintiéndose bien por lo que han conseguido.

Desde una perspectiva organizacional es importante destacar el reconocimiento de la

vulnerabilidad de las personas que se puede originar en la quinta etapa de Tuckman,
particularmente si los miembros del grupo han estado muy unidos y sienten inseguridad o
amenaza ante este cambio.

3 RECOPILACIÓN DE INFORMACIÓN:
HERRAMIENTAS Y TÉCNICAS DE
RELEVAMIENTO Y DE CAPTURA DE
REQUISITOS
Síntesis de Relevamiento: Técnicas de obtención de
información: entrevistas, encuestas, censos, observación
personal, cuestionarios, reuniones, análisis de documentación
existente en la organización.
Relevamiento:
Es un acercamiento a la organización con el objetivo de recopilar información necesaria
para realizar el análisis de sistemas, obteniendo información acerca de la situación actual y
requisitos futuros.
Herramientas de relevamiento:
- Cursogramas
- Tablas / Árboles / Matrices de decisión.

Técnicas de relevamiento (COJAME)

- Entrevista: Conversación con preguntas abiertas y cerradas. Se quiere obtener la
opinión del entrevistado y sus sentimientos acerca del estado actual del sistema, los
objetivos de la organización, los personales y los procedimientos informales.
- Joint Application Design: Conversación grupal en lugar de entrevistas de uno en uno
(Ahorra tiempo y Dinero). Mejora la calidad de los resultados, y logra que el usuario
se sienta más identificado con el nuevo sistema como consecuencia del proceso
participativo.
- Cuestionario: Grilla compuesta por preguntas abiertas/cerradas. Se utiliza porque es
una forma rápida de recolectar gran cantidad de información. Las preguntas pueden
ser abiertas (Permiten desarrollarse) o cerradas (Multiple choice, sí/no). Busca
actitudes, creencias, preferencias, etc.
- Observación personal:La observación tanto del tomador de decisiones como del
ambiente físico de éste son técnicas importantes de recopilación de información para
el analista de sistemas. El analista busca obtener una percepción de lo que
realmente se hace en la organización, y no sólo de lo que está documentado o
explicado. Además, examina los elementos físicos del espacio de trabajo del
tomador de decisiones para ver su influencia sobre el comportamiento del mismo.
Busca información de: Actividades, Mensajes, relaciones, influencias.
- Análisis de documentación: Se realiza sobre la documentación existente, para ver
las ver necesidades de la empresa. Se analizan Hechos y cifras, Información
financiera, contextos organizacionales.
La documentación puede ser cuantitativa (Reportes con objetivo y audiencia
específicos) y cualitativa (No siguen un formato pero permiten predecir
comportamientos.)
- Muestreo: Selecciona elementos representativos de una población y extrae
información de estos. Busca cifras, hechos, info financiera.
Pasos:
- Determinar datos buscados
- Determinar población
- Determinar tipo de muestra
- Determinar tamaño de muestra

Herramientas de Relevamiento: Diagramas (Modelado de

Procesos de Negocio), tablas de decisión, organigramas, etc.
Obtención de requerimientos mediante Casos de uso.
Documentación de entrevistas.
Nuevas Técnicas de Elicitación de Requerimientos:
Definición – Clasificación. Técnicas: Brainstorming,
HistoryMapping, Análisis de Documentos, FocusGroups,
Análisis de Interfaces, Talleres de Requerimientos, Prototipos.

4 METAMODELO – MODELOS
Concepto de Metamodelo.
Metamodelo:
Es un modelo de información para describir modelos. Con él se describen
categorizaciones, correspondientes al nivel de conceptualización. Se construye en un
lenguaje, como UML.
Este modelo de información consta de las siguientes entidades:
- Dominios
- Entidades
- Relaciones
- Atributos

Metamodelo de Requisitos y Metamodelo de Análisis.

IEEE
IEEE es un estándar que define las prácticas recomendadas para la correcta
especificación de requisitos software. El documento de requisitos software debe contar con
todos los requisitos a un nivel de detalle suficiente para que el diseño satisfaga los
requisitos y para que, a la hora de realizar un test, el sistema satisfaga tales requisitos.
La clasificación de requisitos establecida por este estándar cuenta con requisitos de
adaptación, de interfaces externos, funcionales, de ejecución, lógicos de las bases de datos,
de restricciones de diseño y relacionados con atributos del sistema. El metamodelo
asociado sólo permite representar tipos de requisitos mientras que las relaciones entre tales
tipos no están permitidas.

Requisitos:
Para lograr el objetivo de este proyecto debemos crear un metamodelo que
almacene las estructuras organizativas de tipos de requisitos propuestos por los estándares
estudiados. El metamodelo que envuelve o clasifica a todas las estructuras organizativas de
los estándares mencionados y que forma parte del patrón de clasificación de tipos, se
refleja, mediante un diagrama de clases

- Clase clasificación. Representa todos los posibles estándares estudiados para la

clasificación de requisitos: Common Criteria, ESA, IEEE, Métrica y RM-ODP. También
puede representar a estructuras organizativas generadas por distintas personas o
instituciones para luego reusarlas.
- Clase tipo. Representa a la generalización de los subtipos de requisitos.
- Clase subtipo. Representa todos los posibles tipos que en su momento son subtipos de
otro tipo. Los requisitos están contenidos dentro de los subtipos o tipo determinado.
- Clase relación. Es una clase asociación que representa todas las posibles relaciones entre
tipos de requisitos. Se usa el patrón composite para describir una composición recursiva
donde la clase subtipo se compone de objetos que, a su vez, tienen hijos

Modelización. Definiciones y clasificaciones. Distintos tipos de

Modelos.
Modelo:
Un modelo es una representación de algo, que capta los aspectos más importantes de lo
que se está modelando. Un modelo de sistemas de software está construído en UML. Para
algunos propósitos es mejor utilizar el modelo que el sistema final.
Contiene:
- Semántica: Capta el significado de una aplicación como una red de relaciones
lógicas
- Presentación: Muestra la semántica de modo comprensible y configurable para
humanos.
Los modelos sirven para:
● Captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento, de
forma que todos los implicados puedan entenderlos y estar de acuerdo con ellos.
● Pensar del diseño de un sistema
● Capturar decisiones del diseño en una forma mutable a partir de los requisitos.
● Generar productos aprovechables para el trabajo
● Organizar, encontrar, filtrar, recuperar, examinar, y corregir la información en
grandes sistemas.
● Explorar económicamente múltiples soluciones
● Domesticar los sistemas complejos.
Niveles (de abstracción) de modelos:
● Guías al proceso de pensamiento: Alto nivel. Principio del proyecto.
● Especificaciones abstractas de la estructura esencial de un sistema: Corregir los
aspectos abstractos del nivel alto.
● Ejemplos de sistemas típicos o posibles.
● Descripciones completas o parciales de sistemas.
Aspectos de un modelo:
● Abstracción frente al detalle: captura lo esencial y omite otros.
● Especificación frente a implementación: qué y cómo hace algo.
● Descripción frente a una instancia.
● Variaciones en la interpretación:

El entorno UML: componentes

Es un lenguaje porque tiene vocabulario y reglas para la comunicación, es utilizado para
visualizar, especificar, construir y documentar los artefactos de un sistema con gran
cantidad de Sw.

Posee 3 elementos principales:

❖ Bloques Básicos:
- Elementos:
 - Estructurales: son las partes estáticas de los modelos, conceptos,
clasificadores.
Pueden ser: Clase, Interfaz, Colaboración, Caso de Uso, Clase Activa,
Componente, Artefacto y Nodo.
- De Comportamiento: son las partes dinámicas de los modelos en el espacio y
en el tiempo. Pueden ser: Interacción, Máquina de Estados y Actividad.
- De Agrupación: son las partes organizativas de los modelos UML. Son las
partes en las que puede descomponerse. Pueden ser: paquetes.
- De Anotación: son las partes explicativas de los modelos UML. Pueden ser:
comentarios o notas.
- Relaciones:
- Dependencia: un cambio en un elemento afecta la semántica de otro
elemento. Se representa con líneas punteadas y una flecha en una punta.
- Asociación.
- Generalización (herencia).
- Realización: Es una relación semántica entre clasificadores, en donde un
clasificador especifica un contrato que otro clasificador garantiza que
cumplirá.
- Variaciones entre las cuatro anteriores: como la inclusión y la extensión.
- Diagramas: es una representación gráfica de elementos, como si fuera un grafo
conexo de nodos (elementos) y arcos (relaciones):
- De clases: muestra un conjunto de clases relacionadas entre sí.
- De objetos: muestra un conjunto de objetos y sus relaciones.
- De componentes: representa la encapsulación de una clase, sus interfaces y
estructura interna.
- De casos de uso: muestra un conjunto de CU, sus actores y relaciones.
Organizan el
comportamiento.
- De secuencia: interacción entre objetos por medio de mensajes,
- De Colaboración (comunicaciones): interacción que resalta la organización
estructural de los objetos.
- De estados: máquina de estados que muestra la vista dinámica de los
objetos, sus estados y transiciones.
- De actividades: muestra un proceso siguiendo un flujo de control y flujo de
datos.
- De Despliegue: configuración de nodos de procesamientos en tiempo de
ejecución y los artefactos que residen.
- De paquetes: descomposición

❖ Reglas de Combinación de Bloques: los bloques de construcción no se combinan

de cualquier manera, sino que sigue ciertas reglas sintácticas y semánticas para
lograr un modelo semánticamente autoconsistente. Tiene reglas para:
- Nombres: de los componentes.
- Alcance: contexto que da significado.
- Visibilidad: cómo se pueden ver y utilizar esos nombres.
- Integridad: cómo se relacionan los elementos consistentemente.
- Ejecución: qué significa ejecutar o simular un modelo dinámico.
 ❖ Mecanismos Comunes en UML: UML incorpora cuatro mecanismos comunes para
simplificar la modelización. Se utilizan para construir siguiendo un patrón de
características comunes que definen un estilo. Estos mecanismos se aplican a
través de todo el lenguaje.
- Especificaciones: implica la representación de un concepto mediante una
figura. Por ej: El óvalo de caso de uso, el rectángulo de una clase.
- Adornos: existen símbolos gráficos a los que se les agrega ciertos detallas
para especificar. Ej: Visibilidad: +público, #protegido, -privado.
- Divisiones comunes: Implica utilizar con una misma forma gráfica dos
conceptos.
- Mecanismos de Extensibilidad: UML permite extender el lenguaje de manera
controlada para expresar los modelos en todos los dominios.

Vista:subconjunto de UML que modela construcciones que representan una parte del
sistema

Área: Nivel superior de las vistas. Se clasifican en:

- Dinámica: Describe el comportamiento del sistema en el tiempo. Si vista puede ser
máquina de estados (DTE), actividad (Diagrama Actividad) o interacción (Diagrama
Secuencia).
- Estructural: Describe elementos del sistema y su relación con otros elementos. Su
vista puede ser Estática (D. Clases) o por casos de uso (DCU).
5 ANÁLISIS DE SISTEMAS. ANÁLISIS DE
SISTEMAS ORIENTADO A OBJETOS
Análisis de Sistemas orientados a Objetos: Conceptos, Flujo de
Trabajo

El diseño y la implementación son mucho más que el análisis (refinamiento y

estructuración de los requisitos), por lo que se requiere una separación de intereses.
● Un modelo de análisis ofrece una especificación más precisa de los requisitos que la
que tenemos como resultado de la captura de requisitos, incluyendo al modelo de
casos de uso.
● Un modelo de análisis se describe utilizando el lenguaje de los desarrolladores, y
puede por tanto introducir un mayor formalismo y ser utilizado para razonar sobre los
funcionamientos internos del sistema.
● Un modelo de análisis estructura los requisitos de un modo que facilita su
comprensión, se preparación, su modificación, y en general, su mantenimiento.
● Un modelo de análisis puede considerarse como una primera aproximación al
modelo de diseño (aunque es un modelo por sí mismo), y es por tanto una entrada
fundamental cuando se da forma al sistema en el diseño y en la implementación.
Esto se debe a que debería ser mantenible el sistema en su conjunto, y no sólo la
descripción.

Requisitos en el ciclo de vida del Software:

 - Fase de inicio: identificar la mayoría de los casos de uso y detallar los más críticos
(10%)
- Fase de elaboración: capturar hasta el 80% de requisitos (y tener el 5-10%
implementados)
- Fase de construcción: capturar e implementar el resto
- Fase de transición: no hay captura de requisitos
Flujo de trabajo

Primero el analista de sistema ejecuta la actividad de Encontrar Actores y Casos de

Uso para preparar una primera versión del modelo de CU, con los actores y los CU
identificados. Debe asegurarse de balancear el modelo de CU con modelo de dominio,
negocio y requisitos.
 El arquitecto identificará los CU relevantes arquitectónicamente hablando, para
proporcionar entradas a la priorización de los casos de uso que van a ser desarrollados en
la iteración actual.

Los especificadores de casos de uso describen todos los casos de uso que se
han priorizado.
 Paralelamente a los anteriores, los diseñadores de interfaces de usuario sugieren
las interfaces de usuario adecuadas para cada actor basándose en los casos de uso.

“Finalmente” el analista de sistemas reestructura el modelo de casos de uso

definiendo generalizaciones entre los CU para hacerlo lo más comprensible posible.
Modelo de Requerimientos. Realización de un Modelo de
Análisis. Trabajadores, Actividades.
Una realización de casos de uso - análisis es una colaboración dentro del modelo de
análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en
término de las clases del análisis y de sus objetos del análisis en interacción. Una
realización de caso de uso proporciona por tanto una traza directa hacia un caso de uso
concreto del modelo de casos de uso.
● Es una Colaboración dentro del modelo de Análisis que describe como se lleva a
cabo y se ejecuta un CU determinado en términos de las clases del análisis y de los
objetos del análisis en interacción
● Una realización de CU posee una descripción textual del flujo de sucesos,
diagramas de clases que muestran sus clases del análisis participantes, y diagramas
de interacción que muestran la realización de un flujo o escenario particular del CU
en términos de interacciones de objetos del análisis
● Se centra de manera natural en los requisitos funcionales, ya que se basa en las
clases del análisis, por lo tanto pospone el tratamiento de los NO Funcionales
Estereotipos de Clasificadores del Análisis.

Entidad: Modela información que posee una vida larga y que es a menudo
persistente. Las clases de entidad modelan la información y el comportamiento
asociado de algún fenómeno o concepto, como una persona, un objeto del mundo
real, o un suceso del mundo real.
● En la mayoría de los casos son derivadas directamente de las clases entidad del
negocio o dominio. Estos pueden capturar información que no es manipulada dentro
del sistema.
Muestran una estructura de datos lógica y contribuyen a entender que información
manipular.
Interfaz: modela la interacción entre el sistema y el actor.
● Recepción y presentación de información.
● Separan la interfaz del usuario o comunicación con el usuario.
● Representan abstracciones de ventanas, forms, paneles, sensores, API (sistemas
externos).
● No describe cómo la interacción es realizada físicamente.
● Está relacionada con al menos un actor, y un actor está relacionado con al menos
una clase límite.
●
 Control: Representan coordinación, secuencia, transacciones, y control de otros
objetos y se usan con frecuencia para encapsular el control de un caso de uso en concreto.
Las clases de control también se utilizan para representar derivaciones y cálculos
complejos, como la lógica del negocio, que no pueden asociarse con ninguna información
concreta, de larga duración, almacenada por el sistema (una clase de entidad concreta).
● Son usadas para encapsular el control relacionado a un CU.
● Usadas para representar derivaciones y cálculos complejos, tal como lógica
del negocio, que no puede ser representada por ninguna clase entidad
específica.
● La dinámica del sistema son modeladas por las clases control, dado que
manejan y coordinan los flujos de control y acciones principales y delegan
trabajo a otros objetos (clases entidad y límite).

Vistas de Análisis orientado a Objetos.

Áreas de UML aplicadas a Análisis de Sistemas Orientado a

Objetos
Vista de Casos de Uso. Vista estática y Vistas Dinámicas.
Diagramas de Casos de Uso, de Clases de realización de
Casos de Uso, de Clases, Máquina de Estados.

Objetos: Clasificación. Roles. Objetos, mensajes, jerarquía de

clases, herencia, polimorfismo.

El Modelo de Análisis. Generalización y especificación.

Totalidad y partes. Balanceo. Patrones de Análisis:
Generalización:
Relación taxonómica entre una descripción más general y una más específica, que
se construye sobre ella y la extiende. Su propósito es definir las condiciones bajo las cuales
una instancia de una clase puede ser utilizado cuando se declara una variable, conteniendo
valores de una clase dada.
Especificación:
Patrones de análisis:
Colaboración parametrizada.

Patrones de Arquitectura: Capas.

Solución:
● Organizar la estructura lógica de gran escala de un sistema en capas separadas de
responsabilidades distintas y relacionadas, con una separación clara y cohesiva de
intereses como que las capas “más bajas” son servicios generales de bajo nivel, y
las capas más altas son más específicas de la aplicación.
● La colaboración y el acoplamiento es desde las capas más altas hacia las más
bajas, se evita el acoplamiento de las capas más bajas a las más altas.
Las capas definen un modelo general de N-niveles para la arquitectura lógica,
produce una arquitectura en capas.
Problemas:
● Los cambios del código fuente se propagan a lo largo de todo el sistema.
● La lógica de la aplicación se entrelaza con la interfaz de usuario, entonces no se
puede reutilizar con una interfaz diferente, ni distribuirse a otro nodo de proceso.
● La lógica más específica de la aplicación se entrelaza con los servicios técnicos o la
lógica del negocio potencialmente generales, entonces no se puede reutilizar,
distribuir a otro nodo o reemplazar fácilmente con una implementación diferente.
● Existe un alto acoplamiento entre diferentes áreas de interés. Esto es por lo que es
difícil dividir el trabajo para diferentes desarrolladores mediante límites claros.
● Debido al alto acoplamiento y la mezcla de intereses, es difícil que la funcionalidad
evolucione, que el sistema crezca de forma proporcionada o que se actualice para
utilizar nuevas tecnologías.
6 PASANDO AL DISEÑO DE SISTEMAS
Definición de navegabilidad de las asociaciones.
La navegabilidad es una propiedad de la relación de asociación que indica la
posibilidad de navegar unidireccionalmente en una asociación, desde el objeto fuente hasta
el destino. Significa visibilidad, generalmente visibilidad de atributo.

Su preparación exige: Diagramas de Interacción y Modelo de Clases de Análisis.

Con la navegabilidad se llega a un diagrama de clases de Diseño, en el que se tiene:

● Clases, asociaciones y atributos (esto lo tenemos del Modelo de clases del
análisis)
● Información sobre los tipos de atributos (se deben agregar los tipos de datos)
● Navegabilidad (se debe agregar la relación de navegabilidad)

A diferencia del Modelo de Clases de Análisis, el Modelo de Clases de Diseño

contiene definiciones de las entidades de software en vez de conceptos del mundo real.
Además de las asociaciones, atributos y métodos, se ha ampliado el diagrama para incluir
de cada clase la información sobre los tipos de atributos, su visibilidad y navegación entre
objetos.
Para elaborar un Diagrama de Clases del Diseño, sobre el Modelo de Clases del
Análisis se debe incorporar información sobre los tipos de atributos, completar los métodos
nuevos que surjan de las relaciones y agregar las flechas de navegabilidad a las
asociaciones para indicar la dirección de visibilidad de atributos.
*Cuando se implementa la navegabilidad, se interpreta como si la clase fuente
tuviese uno o varios atributos que se refieren a una instancia de la clase destino.

Los objetos colaboran para realizar las funciones del sistema. Esto significa que los
objetos forman vínculos a otros objetos y envían mensajes a lo largo de esos vínculos. Si un
objeto desea que otro objeto ejecute un método, le envía un mensaje que puede tener
información adicional en forma de parámetros. El aspecto dinámico de un sistema orientado
a objetos se observa a través del intercambio de mensajes entre objetos.

Situaciones que requieren definir navegabilidad.

Hay 3 casos:
1 - Una clase A envía un mensaje a una clase B
2- Una clase A crea una instancia de una clase B
3- Una clase A necesita mantener una conexión con una clase B
Visibilidad de Atributos. Introducción a los Diagramas
dinámicos de Interacción y a los Patrones de diseño
( Persistencia)
● La interpretación usual de una asociación con una flecha de navegabilidad es la
visibilidad del atributo, desde la clase fuente hasta la destino.
● Cuando se implementa un lenguaje de programación orientado a objetos, suele
traducirse como si la clase fuente tuviera un atributo que se refiere a una instancia
de la clase destino.
● La visibilidad y las asociaciones requeridas entre las clases se indican con los
diagramas de interacción.

DIAGRAMAS DE INTERACCIÓN

Conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar
entre ellos. Estos objetos interactúan para realizar colectivamente los servicios ofrecidos
por las aplicaciones. En sí, los diagramas de interacción muestran cómo se comunican los
objetos.

La vista de interacción describe secuencias de intercambios de mensajes entre los

roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente
"un rol", es la descripción de un objeto, que desempeña un determinado papel dentro de
una interacción, distinto de los otros objetos de la misma clase. Esta visión proporciona una
vista integral del comportamiento del sistema, es decir, muestra el flujo de control a través
de muchos objetos. La vista de interacción se exhibe en dos diagramas centrados en
distintos aspectos pero complementarios: centrados en los objetos individuales y centrados
en objetos cooperantes.

Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un

sistema, lo que conlleva modelar instancias concretas o prototípicas de clases interfaces,
componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de
un escenario que ilustra un comportamiento. En el contexto de las clases describen la forma
en que grupos de objetos colaboran para proveer un comportamiento. Mientras que un
diagrama de casos de uso presenta una visión externa del sistema, la funcionalidad de
dichos casos de uso se recoge como un flujo de eventos utilizando para ello interacciones
entre sociedades de objetos.

El flujo de eventos de un caso de uso puede recogerse en una especificación texto

acompañada de distintos escenarios especificados mediante diagramas de interacción
(interaction diagrams), donde cada diagrama será una visión gráfica de un escenario.

Patrones de diseño:
una solución a un problema de diseño. Para que una solución sea considerada un
patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su
efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser
reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas
circunstancias.

7 ANÁLISIS DE SISTEMAS USANDO OTRAS

METODOLOGÍAS Y ESTRATEGIAS.
Metodologías Ágiles. Elementos de la metodología. Manifiesto
Ágil. Método SCRUM, Kanban, entre otras
La metodología ágil pone énfasis en satisfacción del cliente y en la entrega rápida de
software incremental, métodos informales, mínima ingeniería de software. Enfatizan la
entrega sobre el análisis y el diseño, y la comunicación activa y continua entre
desarrollador-cliente.
Principios:
● La prioridad más alta es satisfacer al cliente a través de la entrega pronta y continua
de software valioso.
● Son bienvenidos los requerimientos cambiantes, aún en una etapa avanzada del
desarrollo. Los procesos ágiles dominan el cambio para provecho de la ventaja
competitiva del cliente.
● Entregar con frecuencia SW que funcione, de dos semanas a un par de meses, de
preferencia lo más pronto que se pueda.
● Las personas de negocios y los desarrolladores deben trabajar juntos, a diario y
durante el proyecto.
● Hay que desarrollar los proyectos con individuos motivados. Debe darse a éstos el
ambiente y el apoyo que necesiten, y confiar en que harán el trabajo.
● El método más eficiente y eficaz para transmitir información a los integrantes de un
equipo de desarrollo, y entre éstos, es la conversación cara a cara.
● La medida principal de avance es el software que funciona.
● Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,
desarrolladores y usuarios deben poder mantener un ritmo constante en forma
indefinida.
● La atención continua a la excelencia técnica y el buen diseño mejora la agilidad
● Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no realizado.
 ● Las mejores arquitecturas, requerimientos y diseños surgen de los equipos con
organización propia.
● El equipo reflexiona a intervalos regulares sobre cómo ser más eficaz, para después
afinar y ajustar su comportamiento en consecuencia.

Según el Manifiesto se valora:

◦ Los individuos y sus interacciones, sobre los procesos y las herramientas
◦ El software que funciona, más que la documentación exhaustiva
◦ La colaboración con el cliente, y no tanto la negociación del contrato
◦ Responder al cambio, mejor que apegarse a un plan

Las metodologías ágiles enfatizan en:

● Comunicación cara a cara,
● Software funcionando como la prueba fundamental del progreso,
● Técnicas de ingeniería,
● Demostración frecuente de progreso,
● Colaboración entre negocio y equipo de desarrollo,
● Retrospectivas y mejora continua.

Scrum
 ● Define principios que guían las actividades del proceso: requerimientos, análisis,
diseño, evolución y entrega.
● Utiliza un conjunto de patrones de proceso para proyectos con tiempos apretados y
requerimientos cambiantes.
● Dentro de cada actividad se trabaja con un patrón de proceso: sprint o carrera.

Sprint: unidad de trabajo que debe ajustarse a una caja de tiempo (30 días). Durante el
sprint no se introducen cambios, lo que brinda un ambiente a corto plazo estable.
Retraso (backlog): lista de prioridades de los requerimientos, se pueden ir agregando otros
aspectos al retraso y el gerente evalúa las prioridades.
Las reuniones en el método Scrum son diarias con el equipo, cortas(15 min aprox) y
se discuten temas como: ¿Qué hiciste desde la última reunión? ¿Qué obstáculos estás
encontrando? ¿Qué planeas hacer mientras llega la siguiente reunión?

Criystal
Criystal es un conjunto de ejemplos de procesos ágiles que han demostrado ser
efectivos para diferentes tipos de proyectos.
Buenas prácticas
Programación de a Pares: Todo el software de producción se construye con dos
programadores en la misma máquina. Se hace una revisión online del código, resultando en
un mejor diseño, testing e implementación. Mejora la comunicación dentro del equipo.

Kanban
Técnicas de representación visual de información para mejorar la eficiencia en la
ejecución de las tareas.
 Su característica principal es el uso de pulsos de sprint, para emplear tiempo
prefijado (timeboxing) como motor de avance al ritmo marcado por la secuencia de sprints.
La táctica de timeboxing ayuda al equipo.

Kanban vs Scrum

Ingeniería de requisitos Ágil. Historias de Usuario, Epics,

Temas y Tareas.
Historias de usuario
Son utilizadas para la especificación de requisitos en los métodos ágiles, son una
descripción breve de una funcionalidad de software tal y como la percibe el usuario.
Cada historia de usuario debe ser limitada, debería poderse memorizar fácilmente y
escribir sobre una tarjeta card. Poco antes de ser implementadas, van acompañadas de
conversaciones con los usuarios y la definición de los criterios de validación asociados.
Como los cambios son bienvenidos en agilidad, no vale la pena profundizar antes, ya que
en el momento de la implementación estas pueden haber cambiado.
CARDS: Forma ágil de administrar los requisitos de los usuarios sin tener que
elaborar gran cantidad de documentos formales.
Ventajas de las historias de usuario:
● Al ser cortas, la representación de los requisitos del modelo de negocio
pueden implementarse rápidamente.
● Poco mantenimiento.
● Mantienen una relación cercana con el cliente.
● Permiten dividir los proyectos en pequeñas entregas.
● Permiten estimar fácilmente el esfuerzo de desarrollo.
● Son ideales para proyectos con requisitos volátiles o no muy claros.
EPICS: Son historias de usuario extensas reconocidas por el propio cliente. Se
suele descomponer por el equipo para su mejor administración.
 ● ID: Identificador de historia de usuario (único)
● DESCRIPCIÓN: Síntesis de la historia de usuario, responde 3 preguntas ¿Quién se
beneficia?¿Qué se quiere?¿Cuál es el beneficio?
● ESTIMACIÓN: Esfuerzo necesario en tiempo ideal de implementación.
● PRIORIDAD: Orden en el cual las historias de usuario deben ser implementadas.
Aconsejables:
● TÍTULO: Título descriptivo.
● VALOR: Maximizar el valor y la satisfacción percibida por el cliente.
● DEPENDENCIAS: IDs de las historias de las que depende.
● PERSONA ASIGNADA: Sugerir persona del equipo.
● CRITERIO DE FINALIZACIÓN: Criterios o actividades necesarias para dar por
terminada una historia de usuario.
● SPRINT: N° de sprint.
● RIESGO: técnico o funcional asociado a la implementación.
● MÓDULO: Parte del sistema al que pertenece.
● OBSERVACIONES: Aclarar o enriquecer la información.

Criterios de validación. Calidad de Historias de usuario

● CRITERIO DE VALIDACIÓN: Pruebas de aceptación consensuadas con el
cliente/usuario. Una vez superada se da como finalizada la implementación de
historia de usuario.
○ Specific
○ Measurable
○ Achievable
○ Relevant
○ Time-boxed
 ● CALIDAD DE HISTORIA DE USUARIO: método según Wake para asegurar la
calidad en la escritura de las historias de usuario:
○ I - Idependent: cada historia de usuario puede ser implementada y planificada
en cualquier orden
○ N - Negotiable: No incluye detalles, serán acordados.
○ V - Valuable: Si la escribe el usuario/cliente es valiosa para él
○ E - Estimable: ayuda a priorizar y planificar su implementación
○ S - Small:Facilita estimación, un par de semanas, quizás menos
○ T - Testable: si el cliente no sabe cómo probar la US no es del todo clara o
no es valiosa.

8 DETERMINACIÓN DE TAMAÑO Y ESFUERZO

DE PROYECTOS DE SOFTWARE
Análisis de Prefactibilidad - Factibilidad de Sistemas: Técnico,
Operativo, Económico-Financiero.
ESTUDIO DE FACTIBILIDAD
Después de definir la problemática presente y establecer las causas que ameritan de un
nuevo sistema, es pertinente realizar un estudio de factibilidad para determinar la
infraestructura tecnológica y la capacidad técnica que implica la implantación del sistema en
cuestión, así como los costos, beneficios y el grado de aceptación que la propuesta genera
en la institución. Este análisis permitió determinar las posibilidades de diseñar el sistema
propuesto y su puesta en marcha, los aspectos tomados en cuenta para este estudio fueron
clasificados en tres áreas, las cuales se describen a continuación:

● Factibilidad Técnica: Realizar una evaluación de la tecnología existente en la

organización, este estudio estuvo destinado a recolectar información sobre los
componentes técnicos que posee la organización y la posibilidad de hacer uso de los
mismos en el desarrollo e implementación del sistema propuesto y de ser necesario,
los requerimientos tecnológicos que deben ser adquiridos para el desarrollo y puesta
en marcha del sistema en cuestión.

● Factibilidad Económica: Se determinaron los recursos para desarrollar, implantar,

y mantener en operación el sistema programado, haciendo una evaluación donde se
puso de manifiesto el equilibrio existente entre los costos intrínsecos del sistema y
los beneficios que se derivaron de éste, lo cual permitió observar de una manera
más precisa las bondades del sistema propuesto.

● Factibilidad Operativa: Permite predecir, si se pondrá en marcha el sistema

propuesto, aprovechando los beneficios que ofrece, a todos los usuarios
involucrados con el mismo, ya sean los que interactúan en forma directa con este,
como también aquellos que reciben información producida por el sistema. Por otra
parte, el correcto funcionamiento del sistema en cuestión, siempre estará supeditado
a la capacidad de los empleados encargados de dicha tarea.

Tipos de Costos y tipos de Beneficios.

Análisis de Costos:
El propósito de este es analizar no sólo los costos involucrados en el desarrollo del nuevo
sistema, sino los de instalarlo, operarlo y mantenerlo, como así también otros costos extras.
Los costos pueden ser:
- De construcción
- De instalación
- De dinero
- Operacionales
- De capital
- De fracaso.

- Costo de Construcción:
Se busca estimar la cantidad de tiempo y personas involucradas en el desarrollo del
sistema. Los costos involucrados son:
- Salarios y gastos
- Costos capacitación
- Tiempo de Computadora
- Instalación de oficinas
- Gastos de viajes

- Costo de Instalación:
 En un proyecto grande y complejo, el proceso de instalación es complejo e incluye
muchos gastos. Costos involucrados:
- Capacitación de usuarios
- Conversión de BD
- Gastos del equipo de desarrollo durante la instalación

- Costo del Dinero:

El dinero que se requiere para desarrollar e instalar un sistema no se da en los
árboles; la organización tiene que pedirlo prestado, o bien sacarlo de sus fondos
actuales. Por lo tanto existe un costo asociado con el uso del dinero. Generalmente
se debe recurrir al departamento de Contabilidad.

- Costos Operacionales:
Una vez instalado el sistema, al usuario le costará dinero continuar operándolo. Los
costos involucrados son:
- Hardware / Software
- Personal
- Mantenimiento de Hw y Sw

- Costos de Fracaso:
Es el costo de posibles fallas del nuevo sistema. Existen varias formas de fallas de
sistemas, las cuales tienen un costo asociado: costos de hardware, costos de
software, costos de personal relacionado con la corrección del error, costes legales
en el caso de que la falla del sistema haya ocasionado pérdidas financieras y costos
asociados con la posible pérdida de ganancias o pérdida de clientes.
Es importante realizar un análisis de riesgos.

- Costo de Capital:
Algunos costos se desembolsan durante el primer año de operación, pero otros se
capitalizan y se reparten durante varios años. Generalmente los costos de hardware
y equipamiento se consideran de capital.

Análisis de Beneficios:
El intento de calcular beneficios tangibles es el que ocasiona problemas. Cuando se habla
de beneficios se puede decir que tendremos:
- Mejor marco de toma de decisiones
- Mejor Control
- Información Oportuna
Los beneficios que existen son:
- Tácticos
- Estratégicos

- Beneficios Tácticos:
 Un beneficio táctico es aquel que permite que la organización siga con su negocio
pero con menores costos o mayores ganancias. Suelen asociarse principalmente
con la reducción de personal administrativo.
Son:
- Reducir costo de mantenimiento
- Ahorrar tiempo de procesamiento
- Ahorrar en mantenimiento y hardware
- Reducir costos de instalación de nuevos equipos

- Beneficios Estratégicos:
Estos representan la posibilidad de permitirle a la organización hacer cosas que le
serían imposibles con el sistema actúa.
Los beneficios estratégicos son más “atractivos” que los tácticos.
Éstos pueden ser:
- Identificar o llegar a nuevos clientes
- Identificar nuevos tipos de negocios
- Entrar a nuevos mercados
- Capacidad de proporcionar información que antes no se podía

Cómo expresar Costos y Beneficios:

Como los costos y los beneficios no se dan repentinamente, en un instante, se tendrá que
demostrar los costos y beneficios que da el sistema a lo largo de cierto período de tiempo.
Los métodos a utilizar son cuatro:
- Flujo de Efectivo
- Rendimiento de inversiones
- Tasa interna de rendimiento
- Valor neto actual

Análisis de Riesgos:
Como parte de los cálculos de costo-beneficios, se debe hacer un análisis de riesgos del
nuevo sistema, porque puede ser que los costos o beneficios no sean los estimados. La
mayor preocupación son los costos y que las cosas vayan peor de lo pretendido. Por esto
resulta importante saber las consecuencias de que las cosas no salgan bien y saber qué
cosas pueden ir mal.

- Situaciones que afectan costos:

- El vendedor de hardware entra en quiebra
- Gastos extra no considerados
- El equipo de proyecto no tiene los conocimientos técnicos necesarios de
aplicación.
- Problemas políticos o de contratos con sindicatos

- Situaciones que afectan beneficios:

- El sistema no tiene el rendimiento esperado
- Los usuarios encuentran el uso del sistema más difícil de lo esperado,
llevando a demoras/interrupciones
 - Podrían no ocurrir mejoras en participación de mercado. Tal vez no se
producen más clientes, pedidos, negocios, rendimientos.

Introducción a Métricas de costo y esfuerzo, usando Casos de

Uso (puntos de Casos de Uso). Introducción a métricas usando
Historias de Usuario (puntos de historia)
Técnicas de Punto Función:

1. Se deben revisar los aspectos clave de los requerimientos para calcular un recuento
de Puntos Caso de Uso sin ajustar (UUCP - Unadjusted Use Case Points).
2. Estudiar los factores técnicos y el entorno para crear los factores de ajuste.
3. Ajustar los factores para llegar a obtener los Puntos Caso de Uso ajustados (UCP),
que posteriormente se transformarán en una estimación de esfuerzo (horas hombre).

Cálculo de los puntos caso de uso sin ajustar:

1. Clasificar cada interacción entre actor y caso de uso según su complejidad y
asignarle un peso: Se debe determinar la forma en la que cada actor interactúa con
el sistema que se va a desarrollar.

2. Calcular la complejidad de cada caso de uso según el número de transacciones o

pasos del mismo: Determinar el número de transacciones, incluyendo los caminos
alternativos. Una transacción es un conjunto de actividades atómicas, donde se
ejecutan todas ellas o ninguna. Una vez clasificado cada caso de uso, según el
 número de transacciones, se le asigna el peso asociado a dicho número de
transacciones.

3. Calcular los Puntos Caso de Uso no ajustados (UUCP - Unadjusted Use Case
Points): Los UUCP se calculan sumando la dificultad de las interacciones y la
complejidad de los casos de uso, es decir, sumando el total de los pesos de los
actores (clasificados en el paso 1) y el total de los pesos para los casos de uso
(clasificados en el paso 2).

Ajustar los UUCP: Se deben tener en cuenta factores de ajuste, tanto factores técnicos
como factores de entorno.
TCF: Se le asigna un valor entre 0 y 5, dependiendo de su influencia en el proyecto.
En este sentido, asignar un valor 0 significa que el factor es irrelevante para el proyecto, un
valor 3 es promedio y un valor 5 significa que el factor es esencial.

EF: Se le asigna un valor entre 0 y 5 dependiendo de su influencia en el proyecto.

Asignar un valor 0 significa que el factor es irrelevante para el proyecto, un valor 3 es
promedio y un valor 5 significa que el factor es esencial.
Finalmente:

Esfuerzo = UCP * Factor de Productividad

Contar los factores de entorno entre R1 y R6 cuya influencia es inferior a 3 (influencia
promedio) y los factores de entorno entre R7 y R8 que son superiores a 3. Ver “factores de
entorno” en la Tabla 4, pág. 4.
Entonces:
● 20 horas-hombre por UCP si el valor es ≤2
● 28 horas-hombre por UCP si el valor es ≤4
● 36 horas-hombre por UCP si el valor es ≥5, en este caso se debería replantear el proyecto.