UNIDAD N°1 – EL MODELO DE PROCESO DE NEGOCIO

SISTEMAS DE INFORMACIÓN Y SISTEMAS INFOR MÁTICOS

Sistema de Es un conjunto de acciones que generan información para cualquier uso que se quiera
información hacer de ella en una organización, las acciones son: Captar, procesar, almacenar y
distribuir.
Componentes de  Personas: Ingresan datos.
un sistema de  Procedimientos: Pasos para realizar una tarea
información  Software: Programas
 Hardware: Soporte físico del software
 Base de datos: Datos en espera de ser procesados
 Telecomunicaciones: Comunicación a distancia
Diferencias entre La diferencia entre un sistema de información y un sistema informático es que un
Sistema de sistema de información es un conjunto de elementos que interactúan entre sí para el
información y manejo de información y un sistema informático es un conjunto de hardware y software
sistema informático destinado al manejo de información, por lo tanto, se podría decir que un sistema
informático es una subclase de un sistema de información.
Ventajas de los  Facilidad de obtención, acceso y manejo de la información y mayor velocidad en
sistemas los procesos
informáticos  Menores costos
 Seguridad
 Optimizar y agilizar tareas monótonas
Etapa principal en En la primera etapa, se enfocaron en su empleo para reducir costos y mejorar
el uso de un productividad. La segunda etapa, orientada a la obtención de una ventaja competitiva,
Sistema de invirtiendo mucho dinero en sistemas de información. En la tercera etapa le prestan
información atención a las ventajas competitivas y a los costos, basados en la productividad, el
retorno de la inversión.
MODELOS

Modelo Representación abstracta de un objeto real que lo construimos con el propósito de

comprender lo modelado. Se pueden realizar diferentes modelos de un objeto.
Ayudan al analista a:
 Entender el comportamiento del sistema
 Sirven como base para la revisión
 Sirven como base para la etapa siguiente (Diseño)
Características de los modelos:
 Deben ser gráficos con detalles textuales acotados
 Deben permitir ser vistos en partes.
 Deben tener redundancia mínima
 Deben ayudar al lector a predecir el comportamiento
 Deben ser transparentes
Ventajas de utilizar un modelo:
 Permiten concentrarnos en lo importante dejando de lado afectos que no
interesan
 Permiten discutir cambios a bajo costo
 Permiten ahorrar tiempo
 Permiten contar con información documentada

Koppito
  Permiten analizar y experimentar situaciones complejas
 Permiten verificar si comprendimos la petición del usuario

Modelo de negocio El modelado de negocios es una técnica para comprender los procesos de negocios de la
organización y muestra el ambiente de la organización y cómo ésta actúa en relación con
el ambiente.
Importancia del modelado de negocios:
 Porque de allí se sacan los usuarios del sistema de información
 Porque vamos a poder conocer todos los procesos de negocios
 Porque vamos a poder conocer todos los tipos de documentos que se producen
y que se hace con cada uno de ellos.
Propósito del modelo de negocio
 Permiten entender la estructura dinámica de la organización
 Permiten comprender problemas reales e identificar potenciales mejoras
 Permiten asegurarnos el entendimiento común entre todas las personas
intervinientes
 Permiten derivar los requerimientos del sistema de información
El modelo de negocio está compuesto por:
1. Modelo de objeto continuo: La herramienta que se usa para este modelo es el
diagrama de clase (Vista estática) y el diagrama de comunicación (Vista
dinámica).
2. Modelo de procesos de negocio: La herramienta que se utiliza acá es BPMN.
BPMN (Business Es una disciplina que se ocupa de modelar, automatizar, manejar y optimizar procesos
Process Model and para incrementar la rentabilidad de un negocio.
Notation)
Promueve:
 Agregar valor al cliente
 Incorporar el concepto de calidad
 Tener procesos controlados
 Definir “algo” para medir el desempeño y la eficiencia
 Posibilitar una certificación en normas de calidad ISO 9001/2008
 Conocer lo que hacemos y cómo lo hacemos para mejorar continuamente
¿Por qué usar BPMN?
 Es un estándar internacional de modelado de procesos adaptado por la
comunidad
 Es independiente de cualquier metodología de modelado de procesos
 Permite un entendimiento a todas las personas de una organización al manejar
un lenguaje común.
GESTIÓN DE PROCESOS

Proceso Conjunto de actividades, interacciones y recursos con una finalidad común, transformar
las entradas en salidas que agreguen valor a los clientes. El proceso es una totalidad, de
inicio a fin el cliente debe obtener algo de valor.
Tipos de procesos Procesos de estrategia: Similares para todas las empresas y asimilables al círculo PDCA
para la mejora continua.

Koppito
  Planificar: Es realizar un proceso para obtener un plan estratégico. La guía es el
análisis de las necesidades de los clientes, incluye directrices y proyectos.
También la forma como se establece la visión, misión, valores, directrices
funcionales, objetivos corporativos, departamentales y personales y el
programa de acción. También contempla la forma como se comunica la
estrategia y la forma de motivar a todos los integrantes del a organización en
lograr sus definiciones.
 Implementar: Es llevar a la realidad el plan estratégico, contempla organizar,
dirigir, asignar recursos, supervisar la ejecución. Participa toda la organización
con apoyo externo. Requiere gestión de proyectos y seguimiento.
 Retroalimentar: Es capturar el aprendizaje para incluir en un nuevo ciclo de
procesos de la estrategia (gestión del conocimiento).
Procesos de negocio: Atienden directamente la misión de la empresa y se relacionan con
los clientes. A veces se llama procesos primarios o de misión. Mientras más focalizada se
encuentre la organización, menor es el número de procesos del negocio.
Procesos de apoyo: Son las acciones necesarias para realizar los procesos de negocio. A
veces se les llama procesos secundarios.
Gestión de Técnica de gestión que ayuda a los dueños de procesos identificar, diseñar, formalizar,
procesos controlar, mejorar y hacer más productivos los procesos de la organización para lograr la
confianza del cliente.
Conceptos  Proceso clave o críticos: Son procesos que se definen como vitales para el
utilizados en la funcionamiento del negocio desde las definiciones estratégicas. En esta
gestión de procesos categoría caen por derecho los procesos del negocio. Pueden cambiar y están
sujetos a condiciones de tiempo y espacio.
 Actividad: Es una acción que realiza un rol en un periodo de tiempo específico y
controlado. Tiene entradas y salidas precisas y está formado por un conjunto de
tareas concretas. La actividad sólo tiene sentido al interior del proceso. Las
actividades son parte del flujo del proceso y generalmente son realizadas por
una persona. Se escriben en modo verbal infinitivo.
 Tarea: Es el desarrollo de la actividad en acciones muy específicas. Están
incluidas en la descripción del proceso.
 Procedimiento: Es una descripción detallada de una parte del hacer de la
organización, puede ser un proceso, un grupo de procesos operativos o sólo
uno. Se usa decir procedimiento cuando hay varias actividades e interacción
entre roles.
 Protocolo o instructivo: Es un acuerdo interno mandatario y específico.
 Norma: Es una estandarización con el medio con mayor o menor grado de
obligatoriedad. Son normas tales como ISO o CMM. A veces son adhesiones
voluntarias y otras obligadas, como una norma legal de cuidado del ambiente.
Modelos para Mapa de procesos global
visualizar procesos
 Provee una visión de conjunto de todos los procesos de la organización
 Debe estar actualizado y disponible para todos
 Permite reconocer la totalidad y ubicarse en el contexto
 Es el requerimiento mínimo para realizar un análisis crítico.
 Es la cadena de valor de todas las actividades que se realizan en la empresa.
Mapa de ámbito
 Detalla parte de un proceso o describe un proceso completo.

Koppito
  Objetivo -> Desagregar hasta llegar al nivel de Procesos Operativos, es decir
hacer la segmentación de procesos, la cual facilita la intervención del prceos a
través de describir, mejorar o rediseñar.
 Es un mapa de procesos operativos
 Incluye todas las relaciones entre todos los procesos operativos identificados.
Flujograma de información
 Se dibuja un flujograma por cada proceso operativo
 Se busca la simplicidad, el “vistazo”
 Sigue el criterio del curso normal de eventos.
 No se diagrama las contingencias.
 Es un criterio práctico y profundo porque busca robustecer el hacer lo correcto.
Tareas de la actividad: Son los detalles de los modelos en forma de procedimientos, es
decir como descripción detallada de uno o un grupo de procesos operativos del proceso
completo, una vez que el proceso haya sido bien diseñado.

UNIDAD N° 2
COMERCIO ELECTRÓNICO

Comercio El comercio electrónico es la realización de actividades de negocio a través de internet,

electrónico extranet y redes corporativas.
Se puede dar:
 Negocio a negocio (B2B): Todos los participantes son organizaciones
 Negocio a consumidor (B2C): Los clientes negocian con una organización y
evitan intermedios.
 Consumidor a consumidor (C2C): Consumidores que venden a otros
consumidores.
 Gobierno electrónico (e-government): Uso de las tecnologías de información, y
comunicaciones para simplificar la distribución de información, acelerar
procesos y mejorar relación entre ciudadano y gobierno.
Retos para  Definir un modelo y estrategia efectos de comercio electrónico
implementar E-  Lidiar con las preocupaciones de la privacidad del cliente
Commerce  Superar la falta de confianza de los consumidores.
Comercio móvil El comercio móvil se basa en el uso de dispositivos inalámbricos móviles, como
asistentes personales digitales, teléfonos inteligentes para colocar pedidos y hacer
negocios.
Ventajas del  Reducción de costos: Al eliminar o bajar el consumo de tiempo y pasos del
comercio proceso más ventas se pueden hacer enel mismo tiempo y de forma más rápida.
electrónico y móvil  Rapidez en el flujo de bienes e información: Cuando las organizaciones se
conectan vía comercio electrónico la información se acelera, esta puede fluir
fácil, directa y rápido de comprador a vendedor.
 Aumento en precisión: Ver las especificaciones de productos, información del
pedido.
 Mejora en el servicio del cliente: Más información con detalles puede
aumentar la confiabilidad.

Koppito
 Retos y amenazas Retos:
comercio
 Retos culturales: Cuando se diseña el sitio web se hace con cuidado porque va a
electrónico – móvil
ser visto por personas de diferentes culturas, tiene que ser atractivo, fácil de
usar e inofensivo
 Retos del idioma: Debe tener la opción de múltiples idiomas ya que a tu sitio
pueden acceder personas de diferentes lados, y también tener en cuenta las
conversiones de medidas de cantidades.
 Retos de divisas: En los precios se debe indicar la divisa, la moneda que acepta
y ofrecer una herramienta para la conversión al a moneda del país del cliente.
Amenazas:
 Seguridad: Tener firewall, solicitar a los comerciantes proteger sus datos, para
aumentarla en aquellos sitios que usan tarjeta de crédito se usa un sistema de
verificación del número de la misma.
 Fraude: Se identifican fraudes como phishing, mensajes de una institución
supuestamente legítima para sacarles información e ir a sitios falsificados, casi
siempre disfrazados de pedido de donativos. También existen frades de
subastas en línea.
 Invasión de la privacidad del consumidor: Usan el clickstream que recopilan
datos de las bases de datos de los sitios que visitas e ítems sobre los que se da
click
 Falta de acceso a internet: Imposibilita el comercio a muchas personas en el
mundo. No sólo afecta a países más y menos desarrollados sino también entre
clases económicas y quienes viven en el campo.
SISTEMAS EMPRESARIALES

Sistema Sistema central de una organización que garantiza que la información se puede
empresarial compartir a través de todas las funciones de la empresa y todos los niveles de gestión
para soportar la operación y administración de una empresa.
Se clasifican en:
 Sistemas de procesamiento de transacciones: Captura y proceso de datos para
actualizar registros relacionados con operaciones fundamentales de la empresa.
 Planeación de recursos empresariales: Es un conjunto de programas integrados
que administran operaciones de negocios vitales de una compañía para toda
una organización global multisitio.
Características de Sistema de información transaccional: Tiene como objetivo reducir los costos mediante
los distintos tipos la automatización de numerosos sistemas administrativos de rutina. Una transacción es
de Sistemas una acción pequeña que se hace sobre una base de datos. Manejan gran volumen de
informáticos datos.
Sistema informático administrativo (MIS): Utilizan la información generada por los
anteriores para producir informes que contienen información más predeterminada, se
elaboran con regularidad y dan apoyo a decisiones estructuradas.
Sistema de apoyo para la toma de decisiones: Dan apoyo a la toma de decisiones que se
relacionan con problemas específicos el MIS contribuye a que una organización haga
correctamente las cosas, estos contribuyen a las cosas correctas.
Sistema de inteligencia artificial: Adoptan características de la inteligencia humana
habilitan a las computadoras para aprender de la experiencia y de sus errores. Hacen
sugerencias y ser expertos en un campo particular.

Koppito
 Métodos para Sistema de procesamiento por lotes: Se acumulan durante un periodo y se preparan
procesar para ser procesados como una sola unidad.
transacciones
Procesamiento por transacción en línea: Cada transacción se procesa de manera
inmediata, sin la demora de acumular lotes.
Proceso de Marco de trabajo para las tareas que se necesitan para construir un software de alta
software calidad
Ingeniería de Establecimiento y uso de principios de la ingeniería para tener un software confiable y
software que funcione eficientemente en máquinas reales.
Actividades para Análisis: Desde que se contacta el cliente hasta que se tiene el modelo lógico. Dentro de
construir un SI este encontramos:
- Comunicación: Comunicación con los clientes. Investigación de requisitos y
otras actividades relacionadas.
- Diagnóstico: Para determinar problemas y causas a partir de acá se plantea el
para que necesito el sistema.
- Planeación: Establecer un plan, describir tareas técnicas, riesgos y recursos
- Modelado lógico: Creación de modelos para entender mejor que necesita el
software.
Diseño: Se realiza el modelado físico, donde se modelan los datos que maneja el
sistema, modelos arquitectónicos como con cuantas PC se va a trabajar, se diseñan las
interfaces de E/S.
Construcción: Combina la generación de código y realización de pruebas. Se realiza el
despliegue donde se entrega el software al cliente quien evalúa el producto.
Mantenimiento: Es la etapa de eliminar errores, cambiar o agregar cosas.
Estudio de pre Sirve para ver si es viable el proyecto o no. Consta de tres aspectos:
factibilidad
- Técnico: Ver si está todo.
- Económico: Ver si cuento con los recursos económicos necesarios para realizar
el proceso.
- Operativo:
Método, Método (QUE): Conjunto de pasos para hacer algo.
Herramienta,
Técnica (COMO): Procedimiento detallado de una secuencia.
Técnica y
Metodología Herramienta (CON QUE): Elementos que me ayudan a construir un modelo.
Todo lo anterior forma una Metodología.
Importancia de usar Es importante utilizar metodologías estandarizadas porque facilita la comunicación entre
metodologías el equipo de desarrollo. Usa herramientas que fueron probadas, ahorra tiempo.
estandarizadas Aumenta la productividad del equipo de desarrollo.
Características de - Completa: Permite modelar toda la solución y dominio.
las metodologías - Verificable: Tanto por usuarios como por desarrolladores.
- Producir productos: Contra los cuales se pueda medir alcance, avance y tamaño
del proyecto.
- Ser fácilmente aprovechable en la etapa siguiente.
SISTEMAS DE INFORMACIÓN

Importancia de la La documentación permite ejercer control y comunicación entre los miembros del grupo
documentación en de trabajo y también comunicarle al usuario decisiones sobre el producto.
un SI

Koppito
 Se documenta para:
- Comprender los compromisos que se asumen
- Las políticas que se definen
- Los riesgos que se corren
- Comunicar información de un sector a otro
- Controlar las alternativas que sufre el proyecto
- Prevenir situaciones no deseadas
Que documentar:
- Todos los modelos y las decisiones
Como documentar:
- Mientras se toman decisiones o se construyen modelos
Quien documenta
- Se elige la persona que toma la información la ordena y hace que la misma
quede presentada
Calidad de un SI Muchos creen que el tema de la calidad inicia una vez generada el código la garantía de
calidad es una actividad de protección que se aplica a cada paso del proceso de
ingeniería. Engloba:
- Métodos y herramientas de análisis, diseño, codificación y pruebas.
- Revisiones formales a cada proceso
- Estrategia de prueba
- Control de la documentación y cambios realizados
- Mecanismos de medida (métricas)
Calidad y factores Se llama calidad en el software a la concordancia de los requisitos funcionales
que la determinan documentados (criterios que guían desarrollo) con características implícitas que se
en un software esperan de todos sistemas desarrollados profesionalmente.
Factores que determinan la calidad:
- Fiabilidad
- Integridad
- Facilidad de uso
- Facilidad de mantenimiento
- Flexibilidad
Características de Modelo en cascada:
modelos de
 Enfoque sistémico
proceso de
 Es el paradigma más antiguo
software
 No tiene retroalimentación
 Es la base de los modelos que siguen
 Hay que tener paciencia
 No es modelo apropiado para la actualidad
Modelo incremental
 Combina elementos del modelo en cascada usándolo en forma iterativa
 Los primeros incrementos son versiones incompletas del producto final
 Es útil cuando el personal necesario para implementación completa no está
disponible

Koppito
 Modelo DRA
 Es un modelo de proceso incremental
 Ciclo de desarrollo corto
 Permite crear un sistema completamente funcional en corto tiempo
Modelos evolutivos:
 Prototipo:
o Ofrece mejor enfoque cuando se está inseguro de la eficacia de un
algoritmo
o Ayuda a entender mejor cual será el resultado cuando tenga los
requisitos
o Se puede usar también como técnica dentro de los modelos antes
nombrados
 Espiral:
o Puede incorporar el uso de prototipos
o El software se desarrolla en una seria de entregas evolutivas
o Enfoque realista para sistemas muy grandes
o Mantiene enfoque sistemático
o Debe reducir los riesgos antes que se vuelvan problemáticos
Modelos de métodos formales
 Aplica notación matemática
 Eliminan muchos problemas difíciles de superar con otros paradigmas
 Ofrecen la promesa de software sin defectos
 Es cato y consume mucho tiempo
 Se requiere de cierta capacitación ya que es difícil de utilizar
Proceso unificado
 Intenta reunir las mejores características de modelos de proceso de software
 Es para el muy importante la comunicación con el cliente
 Enfatiza el papel de la arquitectura del software
 Sugiere un flujo de proceso iterativo e incremental
Importancia de Nos proporciona una guía para ordenar las actividades de un equipo. Dirige las tareas de
utilizar un proceso cada desarrollador por separado y del equipo como un todo. Especifica los artefactos
para desarrollar un que debe desarrollarse. Ofrece criterios para el control y la medición de los productos y
sistema actividades del proyecto.
PUD Un proceso de desarrollo de software es el conjunto de actividades necesarias para
transformar los requisitos de un usuario en un software. Basado en componentes.
Está dirigido por casos de uso, un caso de uso es un pedazo de la funcionalidad del
sistema que proporciona un resultado importante al usuario. Dirigido por caso de uso
quiere decir que el proceso sigue un hilo.
Centrado en la arquitectura, incluye tanto lo dinámico como estático más importantes
del sistema. La arquitectura surge de las necesidades de la empresa, como la perciben
usuarios e inversores y se refleja en casos de uso. El proceso ayuda al arquitecto en
centrarse en los objetivos adecuados.
Es iterativo e incremental, se divide en mini proyectos donde cada uno de ellos es una
iteración que resulta en un incremento. La iteración hace referencia a pasos en el flujo
de trabajo y los incrementos al crecimiento del producto.

Koppito
 Características del - Los procesos de especificación, diseño e implementación están entrelazados. La
proceso de documentación se minimiza, no hay detalle del sistema.
desarrollo rápido
- El sistema se desarrolla en diferentes versiones. Los usuarios finales y otros
colaboradores del sistema intervienen en la evaluación de cada versión, pueden
proponer cambios y nuevos requerimientos.
- Las interfaces del usuario se hacen usando un sistema iterativo permite que el
diseño de la interfaz se cree rápido.
Problemas al usar - Los representantes del cliente tienen otros compromisos y no pueden intervenir
metodologías ágiles completamente en el desarrollo del software
- Algunos miembros no tienen la personalidad para participar activamente de los
métodos ágiles y no podrán interactuar con los demás miembros del grupo.
- Priorizar cambios será difícil.
- Mantener la simplicidad implica trabajo extra. Cuando se tienen fechas de
entrega es imposible llegar a simplificar el sistema.
Consideraciones al - Tamaño de la organización
seleccionar una
- Tiempo de vida del sistema
metodología
- Complejidad del sistema
- Como está organizado el equipo del sistema
Extreme En XP los requerimientos se expresan como escenarios que se implementan como ciertas
Programming tareas. Trabaja en pares y antes de hacer el código hacen pruebas para cada tarea. Se
trabaja con historia de usuario. Los clientes intervienen en especificación y priorización
de los requerimientos.
SCRUM Administración iterativa del desarrollo y no en enfoques técnicos. Consta de tres fases:
1. Planeación del bosquejo: Se establecen objetivos generales del proyecto.
2. Ciclos sprint: Cada ciclo hace un incremento del sistema
3. Fase de cierre del proyecto: Se termina el proyecto, se completa la
documentación, manuales de usuario.
La característica novedosa son los ciclos sprint. La idea detrás de scrum es que debe
autorizarse a que todo el equipo pueda tomar decisiones.

UNIDAD N° 3 – PARADIGMA ORIENTADO A OBJETOS

Paradigma Es un camino a seguir para llegar a distintas soluciones, determina una forma de
entender el mundo, explicarlo y manipularlo. De acuerdo a Kuhn un paradigma es un
conjunto de prácticas que definen una disciplina científica durante un periodo de tiempo
específico.
Paradigma La OO es una metodología no algorítmica, identifica objetos que se comunican entre sí
orientado a objetos haciéndose peticiones. Cada uno de ellos encapsula atributos y operaciones. No hay
ejecución procedimental de tareas sino mensajes de un objeto a otro.
Tipos de software Software simple: Son aplicaciones altamente intrascendentes que son especificadas,
construidas, mantenidas y utilizadas por la misma persona, habitualmente el
programador aficionado o el desarrollador profesional que trabaja en solitario, tienen
propósito limitado, ciclo de vida corto, poca reutilización. Cuando es inútil se reemplaza.

Koppito
 Software complejo: El software también puede involucrar elementos de gran
complejidad, la complejidad que se encuentra aquí es de un tipo fundamentalmente
diferente. Resulta sumamente difícil para el desarrollador individual comprender las
utilidades de su diseño. La complejidad de tales sistemas excede la capacidad intelectual
humana. Con esencial quiere decirse que domina la complejidad, no la elimina.
Dificultades en el Aspectos de fondo:
desarrollo de
 Planificación y estimación de costos frecuentemente imprecisos
software
 Software que no se corresponde con lo pedido
 Calidad del software que no llega a ser a veces ni aceptable
Estos problemas se presentan por el propio carácter del software y por los errores de las
personas encargadas de su desarrollo.
Personas encargadas del desarrollo
 Falta de conocimiento del software
 Resistencia al cambio
 Falta de capacitación respecto a las nuevas técnicas de desarrollo de software
Complejidad del software
 Complejidad del dominio
 La dificultad de gestionar el proceso de desarrollo
Descomposición Es una técnica para dominar la complejidad de los sistemas, su rol dentro de la
programación consiste en permitir la comprensión del sistema como un todo a partir de
entender unas pocas partes la descomposición ataca la complejidad forzando la división
de estados del software. Toda cuestión compleja debe poder ser separada en partes
para entenderla. Hay dos tipos:
Algorítmica: Se centra en procesos en los cuales sus módulos son pasos muy
importantes para un proceso global. El sistema divide los elementos funcionales
relacionados estructuralmente entre sí.
Orientada a objetos: Determina un conjunto de objetos que se relacionan entre sí para
lograr un comportamiento.
Características de Introduce varios elementos novedosos que se basan en estos modelos antores. El
las técnicas OO modelo de objetos proporciona una serie de beneficios significativos que otros modelos
simplemente no ofrecen. Conduce a la construcción de sistema que incluyen los cinco
atributos de los sistemas complejos bien estructurados. En primer lugar, ayuda a
explotar la potencia expresiva de los lenguajes de programación basados en objetos y
orientados a objetos.
En segundo lugar, las características más potentes de los lenguajes, sin la aplicación de
los elementos del modelado de objetos, se ignoran o bien se utilizan desastrosamente.
Por otra parte, el uso del modelo de objetos promueve la reutilización de software y de
diseños enteros, conduciendo a la creación de marcos de desarrollo de aplicaciones
reutilizables. Los sistemas orientados a objetos son frecuentemente más pequeños que
sus implantaciones equivalentes no orientadas a objetos. La mayor reutilización del
software también se traduce en beneficios de coste planificación.
En tercer lugar, el uso del modelo de objetos produce sistemas que se construyen sobre
formas intermedias estables que son más flexibles al cambio y evolucionan en el tiempo.
Finalmente, el modelo de objetos resulta atractivo para el funcionamiento de la
cognición humana ya que muchas personas que no tienen ni idea de cómo funciona una
computadora encuentran bastante natural la idea de los sistemas orientados a objetos.

Koppito
 Objetos Representan un elemento, unidad o entidad individual identificable, ya sea real o
abstracta, con un papel bien definido en el dominio del problema, tiene una identidad
única. Un objeto modela alguna parte de la realidad y es por tanto algo que existe en el
tiempo y el espacio.
Clase Es un conjunto de objetos que comparten una estructura en común y un
comportamiento común. Un objeto no es una clase, pero una clase puede ser un objeto.
Es una abstracción, los objetos son instancias de las clases.
Elementos Son cuatro los elementos fundamentales en el modelo de objetos:
fundamentales de
 Abstracción: Denota las características esenciales de un objeto que lo
un objeto
distinguen de todos los demás tipos de objeto y proporciona así fronteras
conceptuales nítidamente definidas respecto a la perspectiva del observador.
 Encapsulamiento: Oculta los detalles de implementación del objeto.
 Modularidad: Divide a un programa en módulos o unidades discretas que
pueden compilarse separadamente, pero que tienen conexiones con otros
módulos. Agrupa abstracciones relacionadas lógicamente.
 Jerarquía: Es una clasificación y ordenación de las abstracciones.
Vistas de una clase Las vistas de una clase son la interfaz y la implementación:
 Interfaz: Proporciona su visión externa y por lo tanto enfatiza la abstracción a la
vez que oculta su estructura y los secretos de su comportamiento.
 Implementación: Es la visión interna de una clase que engloba los secretos de
su comportamiento y su estructura interna.
Una clase se representa con una “caja” donde el primer rectángulo corresponde al
nombre de la clase, el segundo corresponde a los atributos de la misma y por último otro
rectángulo que incluye todas las operaciones que se distinguen por tener paréntesis al
final.
Operación Una operación es la implementación de un servicio que puede ser requerido a cualquier
objeto de la clase para que muestre un comportamiento.
Responsabilidad Una responsabilidad es un contrato u obligación de una clase. Estas responsabilidades se
traducen en conjunto de atributos y operaciones que mejor satisfagan las
responsabilidades de la clase. Es más abarcativa que la operación.
Colaboración Representa una solicitud de un cliente a un servidor para cumplir una responsabilidad
del cliente. Se dice que el objeto B colabora con A, si A para cumplir con su
responsabilidad necesita enviar algún mensaje a B solicitándole un servicio.
Relaciones entre  Generalización: Denota una relación “es un” la herencia es una relación
clase entre clases en la que una clase comparte la estructura y/o definido en una
(herencia simple) o más clases (herencia múltiple).
 Asociación: Denota alguna dependencia semántica entre clases de otro
modo independientes. Me indica que hay una relación. Dentro de ella está
la agregación, que denota una relación entre el todo y la parte.
 Agregación: Representa una relación estructural entre iguales, es decir,
ambas clases están conceptualmente en el mismo nivel, sin ser ninguna
más importante que la otra, a veces se desea modelar una relación
“todo/parte”, en la cual una clase representa una cosa grande “el todo”
que consta de elementos más pequeños “las partes”. Representa la
relación del tipo “tiene un”.

Koppito
  Dependencia: Relación de uso que declara un elemento y utiliza
información y los servicios de otro elemento, pero no necesariamente a la
inversa.
Polimorfismo Es un concepto de teoría de tipos en el que un nombre puede denotar instancias de
muchas clases diferentes en tanto en cuanto están relacionadas por alguna superclase
común. Cualquier objeto denotado por este nombre es capaz de responder a algún
conjunto común de operaciones de diversas formas.
Multiplicidad Es una relación estructural entre objetos. Señala cuantos objetos pueden asociarse,
representa un rango de enteros que especifica el tamaño posible del conjunto de
objetos, se escribe como una expresión con un valor mínimo y un valor máximo, que
pueden ser iguales.
Navegabilidad Se indica con el sentido de la flecha en la que se relaciona, determina “quien conoce a
quien” es decir el acceso de que clase a que clase.
Diagrama de clases Es un diagrama que muestra un conjunto de interfaces, colaboraciones y sus relaciones.
Lo que distingue a un diagrama de clases de los otros tipos de diagramas es su contenido
particular.
Contienen normalmente:
 Clases
 Interfaces
 Relaciones de dependencia, generalización y asociación.
 Para modelar el vocabulario de un sistema: Implica tomar decisiones sobre qué
abstracciones son parte del sistema en consideración y cuáles caen fuera de sus
límites.
 Para modelar colaboraciones simples: es una sociedad de clases, interfaces y
otros elementos que colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de todos los elementos.
 Para modelar un esquema lógico de base de datos: es un plano para el diseño
conceptual de una base de datos.
Modelado de Un modelo de objetos de dominio captura los tipos de objetos más importantes en el
objetos de dominio contexto del sistema. Los objetos del dominio representan cosas que existen o eventos
que suceden en el entorno en el que se desenvuelve el sistema.
Las clases del dominio aparecen como:
 Cosas que se manipulan en el negocio.
 Conceptos de los que el sistema debe hacer un seguimiento como artículos
o vehículos.
 Sucesos que ocurrirán o han ocurrido como la partida o llegada de un
avión, o un siniestro en una compañía de seguros.
El modelo de dominio ayuda a los usuarios, clientes, desarrolladores y otros
participantes del proyecto utilizar un vocabulario común.
UNIDAD N° 4 – INGENIERÍA DE REQUERIMIENT OS
Concepto de Es una cualidad o capacidad que necesita el cliente para resolver un problema o
requerimiento alcanzar un objetivo. Deben estar incluido en el sistema de información. Una cosa es la
necesidad real del cliente, otra es lo que el cliente cree que necesita y otra lo que le
transmite al profesional.
Categorías de 1. Requerimientos que deben ser absolutamente satisfechos
requerimiento 2. Requerimientos deseables pero no indispensables

Koppito
 3. Requerimientos posibles pero que pueden eliminarse.
La categorización sirve para priorizar los requerimientos.
Propósito de Los requerimientos sirven para tres propósitos:
requerimientos
1. Permite a los desarrolladores explicar como han entendido lo que el cliente
pretende del sistema
2. Indica a los diseñadores que funcionalidad y características que va a tener el
sistema resultante.
3. Indican al equipo de prueba que demostraciones llevar a cabo para convencer al
cliente que el sistema entregado es el solicitado.
Lista de 1. ¿Son correctos? Tanto el desarrollador como el cliente deben revisarlos para
comprobación asegurarnos que no tienen errores.
2. ¿Son consistentes? Esto significa que no haya definiciones contradictorias o
ambiguas.
3. ¿Son completos? Significa que todos los servicios solicitados deben estar
definidos.
4. ¿Son realistas? Si el sistema puede hacer lo que el cliente pide.
5. ¿Son verificables? Significa poder demostrar a partir de las pruebas que se
cumplen los requerimientos.
6. ¿Son rastreables? Desde cada función del sistema se pueda ir hasta el conjunto
de requerimientos que la establece.
Tipos de Requerimientos funcionales: Se refieren a lo que el sistema debe hacer dpenden del
requerimientos tipo de software que se está desarrollando. Detallan las funciones del sistema, sus
entradas y salidas, sus excepciones, etc.
Requerimientos no funcionales: No se relacionan directamente con los servicios
específicos que el sistema entrega a los usuarios. Puede definir restricciones sobre la
implementación del sistema. Especifican o restringen características del sistema como un
todo.
Requerimientos del dominio: Se derivan del dominio de aplicación del sistema, más que
a partir de las necesidades del usuario.
Requerimientos duraderos: Se asocian con las actividades centrales, de lento cambio.
Requerimientos volátiles: Son más susceptibles al cambio, se asocian con las actividades
de apoyo. Son cuatro, los mutantes (cambian debido a los cambios del ambiente),
emergentes (surgen al incrementarse la comprensión del cliente en el desarrollo del
sistema), consecutivos (son el resultado de la introducción del sistema que puede
cambiar los procesos de la organización y abrir nuevas formas de trabajo que generan
nuevos requerimientos), y de compatibilidad (dependen de sistemas o procesos. Cuando
estos cambian, los requerimientos cambian).
Niveles de Se distinguen haciendo referencia a los requerimientos del usuario (enunciados en ,
descripción de servicios que los usuarios esperan en el sistema y las restricciones con las que opera), y
requerimientos requerimientos del sistema (descripción detallada de lo que el sistema debe hacer. Las
funciones, servicios y restricciones operacionales bien detalladas ).
Ingeniería de Los requerimientos para un sistema son descripciones de lo que el sistema debe hacer:
requerimientos el servicio que ofrece y las restricciones en su operación. Al proceso de descubrir,
analizar, documentar y verificar estos servicios y restricciones se llama Ingeniería de
requerimientos. Es un sub campo de la ingeniería de software.

Koppito
 Proceso de El proceso de ingeniería de requerimientos incluye cuatro actividades:
ingeniería de
 Estudio de factibilidad: Estudio enfocado que debe realizarse con
requerimientos
oportunidad en el proceso.
 Adquisición y análisis: Descubrir el dominio de la aplicación, que servicios
debe proporcionar el sistema, el desempeño requerido, las restricciones de
hardware, etc.
 Especificación (documentación): Pueden producirse documentos de
requerimientos formales e informales.
 Validación: Comprobar que los requerimientos definen realmente el
sistema que quiere el cliente.
Administrar Los requerimientos para los grandes sistemas de software siempre cambian. Existen
requerimientos muchas razones por las cuales estos cambian son inevitables:
a. Los ambientes empresariales y técnicos de los sistemas siempre cambian
después de la instalación.
b. Los individuos que pagan por un sistema y los usuarios de dicho sistema no son
los mismos.
c. Los requerimientos y prioridades de los distintos usuarios de sistemas grandes
pueden estar en conflicto o ser contradictorias.
UNIDAD N°5 – PROCESO DE ELICITACIÓN DE REQUERIMIENTOS
¿Por qué utilizar Se utiliza una estrategia de búsqueda para poder realizar la búsqueda de información de
una estrategia de manera ordenada.
búsqueda?
Una estrategia de búsqueda consiste en:
1. Identificar las fuentes de información:
a. Usuarios: Permiten identificar cuáles son los problemas actuales y
qué se espera del nuevo sistema de información.
b. Formularios y documentos: Expresan cómo se organiza la
información y cuál es la estructura de datos de la organización.
c. Sistema actual: Determina qué realiza, cuáles son sus funciones y
su interfaz.
d. Manuales:
i. Manual de la organización
ii. Manual de procedimientos y normas
iii. Manual de políticas
2. Establecer un proceso de búsqueda: Conjunto de pasos a seguir que
determinan por dónde comenzar a buscar información y cómo continuar.
3. Seleccionar técnicas o herramientas para recopilar información:
Entrevistas, cuestionarios, análisis de documentación y observación.
4. Utilizar modelos para darle sentido a la información recopilada: Serán
analizados a lo largo de la materia, entre ellos: Modelo de CU y de obj. De
dominio.
Muestreo Proceso consistente en seleccionar sistemáticamente elementos representativos de una
población. Si dichos elementos son elegidos con cuidado, el análisis de una muestra
brindará información sobre toda la población. El muestreo es importante porque:
1. Reduce costos: Analizar toda la población es costoso e innecesario.
2. Acelera la recopilación de datos.
3. Mejora la efectividad, ya que la información es más precisa y de mayor calidad.
4. Reduce la parcialidad (incrementa la objetividad de la información).

Koppito
 Para diseñar una muestra se siguen los siguientes pasos:
1. Determinar que datos van a ser recopilados.
2. Determinar de qué población se van a tomar las muestras.
3. Escoger el tipo de muestras:
a. “Conveniente”
b. “Intencional”
c. “Simple”
d. “Compleja”
4. Decidir el tamaño de la muestra, teniendo en cuenta el tiempo disponible
Entrevista Conversación dirigida a una o más personas con un propósito específico que utiliza un
formato de preguntas y respuestas orales. Permite obtener información cualitativa, es
decir, las opiniones de los entrevistados sobre el estado actual del sistema de
información.
Tipos de entrevistas:
1. Estructurada: Se realiza un esquema previo de preguntas, ideal para cuando los
entrevistadores tienen poca experiencia.
2. No estructurada: Las preguntas se realizan conforme avanza la conversación, de
manera espontánea. Requiere experiencia.
Etapas de una entrevista:
1. Preparación:
a. Analizar antecedentes
b. Establecer objetivos de la entrevista.
c. Decidir a quién entrevistar.
d. Prepara al entrevistado, informar fecha y hora.
e. Decidir el tipo de preguntas y la estructura de la entrevista.
2. Entrevista en sí: Explicar objetivo de la entrevista y del proyecto. Comenzar
con preguntas general si se posee poca experiencia. Adecuar vocabulario y
vestimenta al tipo de usuario. Evitar dar opinión personal. Garantizar la
confidencialidad de la entrevista.
3. Conclusión de la entrevista: Elaborar un informe que quede a disposición
del entrevistado para que éste pueda agregar, modificar o eliminar
información.
Tipos de preguntas:
1. Abierto: Entrevistado posee opciones abiertas para responder. Proporciona
muchos detalles pero se puede perder el control de la entrevista tomando
demasiado tiempo.
2. Cerradas: Existe un número finito de posibles respuestas. Ahorran tiempo y
permiten enfocarse en lo primordial pero no generan confianza.
3. Sondeo: Preguntar por qué y pedir ejemplos. Permite profundizar una pregunta
inicial.
¿A quién entrevistar? A aquellas personas que posean la información buscada, y que de
otra fuente dicha información no se podría obtener.
Cuestionario Encuesta. Técnica de recopilación de información que permite a los analistas estudiar
actitudes, creencias, comportamientos y características de las personas afectadas por el
SI propuesto en una organización. Se realizan por escrito y brindan información
cuantitativa de forma rápida.
Tipos de cuestionarios:

Koppito
 1. Con preguntas abiertas. Debemos ser capaces de anticipar la respuesta.
2. Con preguntas cerradas: Debemos listar todas las posibles respuestas
Conviene usar cuestionarios cuando la población es grande o dispersa, cuando
necesitamos información cuantitativa o cuando hay mucha gente involucrada en el
estudio.
Formato:
1. Colocar primero las preguntas más importantes para los encuestados.
2. Agrupar elementos de contenido familiar.
3. Incorporar primero las preguntas menos polémicas
Aplicación:
1. Citar al mismo tiempo a todos los encuestados.
2. Entregar personalmente los cuestionarios y luego recogerlos.
3. Permitir que los encuestados llenen el cuestionar io en el trabajo y luego lo
depositen en una caja.
4. Mandar cuestionario por correo e indicar fecha límite.
5. Aplicar el cuestionario por email o vía web.
Análisis de Acción de descubrir y analizar datos investigando en las evidencias de una organización.
documentación Puede brindar información cuantitativa (Informes, Registros y Formularios) o
información cualitativa (Memorandos, Carteles, Webs y Manuales).
Observación: Método no intrusivo que permite evaluar y poner de manifiesto
requerimientos de información.
¿Qué observar? La toma de decisiones (sobre actividades y comportamientos), el
entorno físico (oficina, equipos, accesorios) y cómo circula la información en la
organización. ¿Cómo observar? 1. De forma participativa o NO participativa. 2. Por
tiempo (pequeño período de una actividad) o por evento (observar toda la actividad
completa).
Informe Relación de ciertos hechos ya analizados con vista a orientar al destinatario hacia una
acción determinada.
Etapas:
1. Preparación del Trabajo: Recopilar datos de entrada.
2. Redacción de las PARTES:
a. Objeto: Debe definir claramente el motivo del informe.
b. Cuerpo: Descripción de los hechos (tal cual ocurrieron) y opinión
personal del analista.
c. Conclusión: Explicita resultado final
UNIDAD N°6 – PROCESO DE ESPECIFICACIÓN DE REQUERIMIENTOS
Especificación de La especificación de requerimientos es el proceso de escribir en un documento de
requerimientos requerimientos, los requerimientos del usuario y del sistema.
Requerimientos del usuario: Incluyen tanto los requisitos funcionales como no
funcionales, poseen un bajo nivel de descripción de detalle y se encuentran en lenguaje
natural.
Requerimientos del sistema: Son el punto de partida para el diseño del sistema, poseen
un nivel de descripción alto y se encuentran en un lenguaje técnico.
La especificación de requerimientos se realiza durante la etapa de análisis.

Koppito
 Perspectivas para Perspectiva Externa: Se ve el contexto o entorno del SI
modelar un SI
Perspectiva de Comportamiento: Modela el comportamiento del SI.
Perspectiva Estructural: Modela la arquitectura del SI o la estructura de datos.
Modelo de Casos Describe la funcionalidad completa de un Si, detallando todo lo que éste va a realizar
de Uso (incluye requerimientos funcionales en términos de CU). El modelo de casos de uso está
formado por el diagrama de CU y por la descripción de los CU. Esta descripción puede
realizarse de distintas formas, la utilizada por la cátedra es la “Plantilla de CU” pero
también podría realizarse, por ejemplo, con Diagramas de Flujo.
Caso de Uso Un CU es una porción de funcionalidad, un proceso del SI. Describen una secuencia de
acciones ejecutadas por el SI y que producen valor para un actor.
Escenario Un escenario es cada una de las posibles variantes de un CU, representa una de las
formas o caminos a seguir en los que se puede dar un CU.
Componentes Casos de Uso: Se representan gráficamente como elipses ubicadas dentro del
gráficos del rectángulo. Cada CU tiene un nombre.
Diagrama de CU
Tipos de CU: Permiten detectar funcionalidades y priorizar actividades,
atacando la complejidad de un sistema.
1. Esenciales: CU que describen funciones vitales, primordiales del SI.
2. De Soporte: CU de menor complejidad, que permiten llevar a cabo los
esenciales.
Actores: Se representan gráficamente como un monigote fuera de la frontera. Son
usuarios humanos o computarizados del SI: Cada actor refleja un ROL e interactúa
directamente con un CU.
Tipos de Actores: Principal (Instancia CU) y Secundario (Es instanciado por un
CU).
Relaciones entre CU: Se representan mediante distintos tipos de flechas dentro de la
frontera:
1. Extensión: Un CU extiende a otro cuando presenta una variante del mismo,
es decir, que si durante la ejecución del CU base se cumple cierta condición,
se ejecutará el CU que lo extiende.
2. Inclusión: Por motivos de disminuir la complejidad o para reutilizar un CU,
un CU base puede incluir a otro. Significa que el CU base no puede cumplir
con su objetivo sin el CU incluido.
3. Generalización: Relación “es un”. Dos CU pueden generalizarse o heredar
de otro.
Paquetes: Permiten agrupar, y a la vez organizar, los distintos CU del diagrama.
Flujo de eventos Un flujo de eventos se utiliza para especificar el comportamiento de un CU, incluyendo
cómo y cuándo empieza y acaba dicho CU, cuando interactúa con los actores y qué
objetos se intercambian.
Tipos de flujo de eventos:
1. Principal: Describe los pasos que se sucederían en el escenario del “mundo
perfecto”. Es un camino simple, sin ramificaciones.
2. Excepcional: Descube otros escenarios, variantes del CU. Son flujos
independientes que describen el comportamiento del CU ante ciertos

Koppito
 acontecimientos que pueden significar una bifurcación del curso normal o
principal.
Relación entre CU y Un CU captura el comportamiento esperado del sistema, sin especificar cómo se
colaboraciones implementa ese comportamiento. Las colaboraciones definen la implementación de un
CU, especificando cómo se llevará a cabo el mismo y cuál será su estructura dinámica y
estática.
Modelamiento de En UML el contexto de un sistema se puede modelar con un diagrama de CU, destacando
un CU los actores entorno al sistema. Debemos:
1. Identificar fronteras del sistema, decidiendo qué comportamientos serán
ejecutados por él y cuáles por entidades externas. Define el sujeto.
2. Identificar actores en torno al sistema, considerando los grupos que ellos van
formando y las funciones que ejecutan estos grupos.
3. Organizar actores similares en jerarquías de generalización/especialización.
4. Proporcionar un estereotipo para cada actor, ayudando a entender el sistema.
Estructuramiento Estructurar el modelo de CU significa establecer los 3 tipos de relaciones mencionadas.
del modelo de CU Es un paso posterior a la construcción del modelo inicial, se realiza cuando se comienza a
ver que los CUs tienen definiciones compartidas, semejantes o dependientes. Casos:
Generalización de actores, de CUs, extensión e inclusión de CUs.
Se realiza para:
1. Aumentar la facilidad de comprensión de los CUs.
2. Facilitar el mantenimiento de las partes del modelo.
3. Permitir la reutilización de los flujos de trabajo.
Ingeniería directa Proceso de transformar un modelo en código a través de una correspondencia con un
lenguaje de implementación. Permite generar pruebas de los CU.
Ingeniería inversa Proceso de transformar código en un modelo mediante un lenguaje de implementación
específico. Es posible realizar sólo de manera manual, es complicado.
Documento de El ERS es un comunicado oficial de lo que deben implementar los desarrolladores del
especificación de sistema. Incluye los requerimientos del usuario y una especificación detallada de los
requerimientos requerimientos del sistema. La información presentada por el ERS debe ser:
1. Completa
2. Precisa
3. Verificable
4. Cierta y coherente
Características de la 1. No ambiguo
ERS 2. Consistente
3. Fácil de modificar
4. Fácil de identificar el origen y consecuencia de cada requerimiento
5. Fácil de verificar
6. Los requerimientos deben estar clasificados por importancia
7. Fácil de utilizar
Categorías de Patrones de desarrollo: Describen características de prácticas de escritura de CU
patrones de CU probadas y ofrece criterios para medir la calidad del proceso de escritura de CU. Se
subdividen en Patrones de Equipo y Patrones de Proceso.

Koppito
 Patrones Estructurales: Describen los componentes básicos de los CU explicando cómo
deberían ser organizados y ofrecen criterios para juzgar un CU. Se subdividen en:
Patrones de Conjunto de CU, de CU, de Escenarios y Pasos, de Relaciones de CU.
UNIDAD N°7 – VALIDACIÓN DE REQUERIMIENTOS
Validación de Es el proceso de verificar que los requerimientos definen realmente el sistema que en
requerimientos verdad quiere el cliente. Es importante porque los errores en un documento de
requerimientos pueden conducir a grandes costos por tener que rehacer, cuando dichos
problemas se descubren durante el desarrollo del sistema o después de que éste se halla
en servicio.
Tipos de  Comprobación de validez: Verificar que lo que el cliente cree querer es lo que
Verificaciones realmente necesita.
 Comprobación de consistencia: No debe haber restricciones contradictorias o
descripciones distintas sobre una misma función.
 Comprobación de totalidad o integridad: El documento debe incluir todas las
funciones y restricciones pretendidas por el usuario del sistema.
 Comprobación de realismo: Comprobar que la tecnología disponible permite la
implementación de los requerimientos y también considerar el presupuesto.
 Verificabilidad: Los requerimientos deben poder escribirse de forma que sean
verificables para reducir el potencial de disputas entre cliente y contratista.
Técnicas de  Revisión de requerimientos: Se analizan sistemáticamente cuando un equipo
validación de revisores que verifican errores e inconsistencias.
 Creación de prototipos: Se muestra un modelo de usuarios finales y clientes
para que experimenten con el mismo y constatar así si cubre sus necesidades
reales.
 Generar casos de prueba: Las pruebas para los requerimientos se diseñan como
parte del proceso de validación, esto revela con frecuencia problemas con los
requerimientos.
Prototipo Un prototipo es un modelo de comportamiento del sistema que puede ser usado para
entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos. Un
prototipo es una representación de un sistema, aunque no es siempre un sistema
completo, posee las características del sistema final o parte de ellas.
Utilidad de  Validación de requerimientos
prototipos  Obtener requerimientos que se pasaron por alto
 Capacitar a los usuarios
 Probar el sistema
Beneficios de  Mejora la usabilidad del sistema
trabajar con  Mejora el acoplamiento entre el sistema y las necesidades del usuario
prototipos  Mejora la calidad del diseño
 Mejora el mantenimiento
 Reduce el esfuerzo del desarrollo
Tipos de prototipos Evolutivo: Se desarrolla a medida que avanza el proyecto. Se empieza con los aspectos
más importantes, con retroalimentación con el cliente se continúa el diseño y se termina
con el sistema listo. No existe una especificación detallada y en muchos casos no existe
un documento formal de requerimientos.
Desechables: Ayudan a refinar y clarificar la especificación del sistema. El prototipo se
escribe, evalúa y modifica. Una vez redactada la especificación, el prototipo ya no es útil
y se desecha. El objetivo es validar o derivar los requerimientos del sistema.

Koppito
UNIDAD N° 8 – NO ME ACUERDO EL TITULO
Proceso Unificado Es una metodología que nos dice los RRHH, las actividades y artefactos que necesitamos
de Desarrollo utilizar, desarrollar o crear para modelar un sistema de software. Posee las siguientes
características:
 El PUD está dirigido por casos de uso: Una interacción de este tipo es un caso
de uso. Identifica los requerimientos hasta los casos de prueba.
 El proceso unificado está centrado en la arquitectura: El concepto de
arquitectura de software incluye los aspectos estáticos y dinámicos más
significativos del sistema. La arquitectura surge de las necesidades de la
empresa, como las perciben los usuarios y los inversores, y se reflejan en los
casos de uso. Los arquitectos modelan el sistema para darle una forma. Es esta
forma, la arquitectura, la que debe diseñarse para permitir que el sistema
evolucione a lo largo de futuras generaciones. Para encontrar esta forma, los
arquitectos deben trabajar sobre la comprensión general de las funciones clave,
es decir, sobre los casos de uso del sistema.
 El proceso unificado es iterativo e incremental: Es práctico dividir el trabajo en
partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que
resulta en un incremento. Estas iteraciones hacen referencia a los pasos del
flujo de trabajo. La iteración trata un grupo de casos de uso que juntos amplían
la utilidad del producto desarrollado hasta ahora y tratan los riesgos más
importantes.
Forma de trabajo La particularidad del PUD es que divide el tiempo total de desarrollo en cuatro fases, en
de PUD donde cada una se divide normalmente en iteraciones, a su vez cada iteración atraviesa
cinco flujos de trabajo: Requisitos, Análisis, Diseño, Implementación y Prueba.
Las fases del PUD son:
 Fase de inicio: Desarrolla una descripción del producto formal y presenta el
análisis para el producto. Su objetivo es establecer: principales funciones
del sistema, arquitectura posible, plan y presupuesto del producto.
 Fase de elaboración: Especifica los CU y diseña la arquitectura del sistema
en forma de vistas de cada modelo. Permite planificar las actividades y
estimar los requisitos reales para terminar el proyecto.
 Fase de construcción: Se crea el producto mediante la evolución de la
descripción del sistema. Al final de esta fase, el producto contiene todos los
casos de uso, pero puede tener defectos.
 Fase transición: Periodo donde el producto se convierte en beta. Implica:
Corrección de errores, incorporación de mejoras, capacitación del cliente y
mantenimiento.
Conceptos básicos  Proyecto: Elemento organizativo a través del cual se gestiona el desarrollo
de PUD de software, el resultado del proyecto es una versión del producto.
 Producto: Artefacto que se crea durante la vida del proyecto como el
modelo de documentación y código.
 Artefacto: Productos tangibles resultantes del proceso de desarrollo de
software, permiten describir, identificar y explicar los actores y casos de
uso en relación a otras construcciones de UML.
 Trabajadores: Se los puede asignar una persona real, son responsables de
los artefactos y representan una abstracción del ser humano con
conocimiento y habilidades necesarios para el proyecto.

Koppito
  Workflow: Secuencia de actividades ordenadas, que cada actividad
produce una salida que sirve de entrada para la siguiente.
Flujos El artefacto más importante que se construye en cada uno de los flujos es el nombre del
fundamentales modelo que se especifica a continuación, per eso no significa que sea el único que se
construye:
Requisitos -> Modelo de Casos de Uso.
Análisis -> Análisis
Diseño -> Diseño
Diseño -> Despliegue
Implementación -> Implementación
Prueba -> Prueba
Propósito del flujo El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia
de trabajo de el sistema correcto. Esto se consigue mediante una descripción de los requisitos del
requisitos sistema suficientemente buena como para que pueda llegarse a un acuerdo entre el
cliente y los desarrolladores sobre qué debe qué no debe hacer el sistema.
¿Cómo se  Enumerando los requisitos candidatos: Mantenemos una lista de ideas que
descubren los consideramos como un conjunto de requisitos candidatos que podemos
requisitos? decidir implementar en una versión futura del sistema.
 Comprendiendo el contexto del sistema: El objetivo del modelado de
negocio es describir los procesos, a medida que esto ocurre, los analistas
aprenden mucho sobre el contexto del sistema software. El modelo del
negocio especifica que proceso de negocio soportará el sistema. Aparte de
identificar los objetos del dominio o negocio implicados en el mismo, este
modelo también establece competencias requeridas en cada proceso: Sus
trabajadores, sus responsabilidades y las operaciones que llevan a cabo.
 Capturar requisitos funcionales y no funcionales: Se basa en los casos de
uso.
Papel de los Durante la fase de inicio, los analistas identifican la mayoría de los casos de uso para
requisitos en el delimitar el sistema y el alcance del proyecto y para detallar los más importantes.
ciclo de vida del
Durante la fase de elaboración, los analistas capturan la mayoría de los requisitos
software
restantes para que los desarrolladores puedan estimar el tamaño del esfuerzo de
desarrollo que se requerirá. El objetivo es haber capturado sobre un 80% de los
requisitos y haber escrito la mayoría de los CU al final de esta fase.
Los requisitos restantes se capturan e implementan durante la fase de construcción.
Casi no hay captura de requisitos en la fase de transición, a menos que haya requisitos
que cambien.
Descripción del Se describe en tres pasos:
flujo de trabajo de
 Los artefactos creados en el flujo de trabajo de los requisitos.
requisitos
 Los trabajadores participantes en el flujo de trabajo de los requisitos.
 El flujo de trabajo de captura de requisitos, incluyendo cada actividad es
más detalle.
Artefactos que se  Modelo de casos de uso: Permite que los desarrolladores de software y los
crean durante el clientes lleguen a un acuerdo sobre los requisitos. Sirve como acuerdo
flujo de trabajo de entre cliente y desarrolladores y proporciona una entrada fundamental
requisitos para el análisis, el diseño y las pruebas.

Koppito
  Descripción de la arquitectura: Contiene una vista de la arquitectura del
modelo de casos de uso, que representa los casos de uso significativos para
la arquitectura. La arquitectura del modelo de CU debería incluir los CU que
describan alguna funcionalidad importante o crítica o impliquen algún
requisito importante que deba desarrollarse pronto en el ciclo de vida del
software.
 Glosario: Se usa para definir términos comunes importantes que los
analistas utilizan para describir el sistema. Es útil para alcanza un consenso
entre desarrolladores relativo a la definición de conceptos para reducir el
riesgo de confusiones.
 Prototipo de interfaz de usuario: Nos ayuda a comprender y especificar las
interacciones entre actores humanos y el sistema durante la captura de
requisitos. No sólo ayuda a desarrollar una interfaz gráfica mejor sino
también a comprender mejor los casos de uso.
Trabajadores que  Analista de sistemas: Responsable del conjunto de requisitos que están
intervienen en el modelados en los casos de uso, lo que incluye todos los requisitos
flujo de trabajo de funcionales y no funcionales. Es responsable de delimitar el sistema,
requisitos encontrando los actores y los casos de uso y asegurando que el modelo de
casos de uso es completo y consistente, dirige el modelado.
 Especificadores de casos de uso: Asume la responsabilidad de las
descripciones detalladas de uno o más CU. Necesita trabajar
estrechamente con los usuarios reales de los CU.
 Diseñador de interfaz de usuario: Dan forma a la visual de las interfaces de
usuario. Lo que implica el desarrollo de prototipos de interfaces de usuario
para algunos casos de uso.
 Arquitectos: Describe la vista de la arquitectura del modelo de casos de
uso, prioriza los casos de uso.
Actividades que se  Encontrar actores y CU: Identificar los roles de quienes interactuarán con el
llevan a cabo en el sistema e identificar las funcionalidades que tendrá el mismo. Lo realiza el
flujo de trabajo de analista.
requisitos  Estructurar el modelo de CU: Aplicar los tres tipos de relaciones a los casos
de uso para volverlo más fácil de entender y de trabajar. Lo realiza el
analista.
 Detallar CU: Describir el flujo de sucesos en detalle, incluyendo como
comienza, termina e interactúan con los actores. Lo realiza el especificador
de CU.
 Prototipar la interfaz: Se realiza el prototipo de la interfaz del sistema. Lo
realiza el diseñador de interfaz.
 Priorizar los CU: Se categorizan los casos de uso según la necesidad de su
inmediata implementación. Lo realiza el arquitecto para luego realizar la
descripción de la arquitectura.
Propósito del flujo Su propósito es hacer una comprensión más precisa de los requisitos financiándolos y
de trabajo de estructurarlos y una descripción para facilitar el mantenimiento y ayudar a estructurar el
análisis sistema (identificar clases y paquetes). Analizar los requerimientos con mayor
profundidad utilizando un lenguaje de desarrolladores para describirlos.
Características del  Descripto con un lenguaje de desarrollador.
modelo de análisis  Vista interna del sistema
 Estructurado por clases y paquetes estereotipados, proporciona la estructura y
vista externa.

Koppito
 Artefactos  Modelo de análisis: Es una jerarquía de paquetes de análisis que contienen
construidos clases del análisis y realizaciones de casos de uso. La utilización de paquetes de
durante el flujo de análisis es una forma de organizar el modelo de análisis en partes más
trabajo de análisis manejables que representas abstracciones de clases y posiblemente de
subsistemas.
 Clase de análisis: Representa una abstracción de una o varias clases y/o
subsistemas del diseño del sistema. Se centra en el tratamiento de los requisitos
funcionales y posponen los no funcionales. Define atributos, aunque esos
atributos también son de un nivel bastante alto, esos atributos son
conceptuales y reconocibles en el dominio del problema. Participa en
relaciones, aunque esas relaciones son más conceptuales que sus
contrapartidas de diseño e implementación. Siempre encajan en uno de los tres
estereotipos básicos: Clase de interfaz: Se utilizan para modelar la interacción
entre el sistema y sus actores. Esta interacción a menudo implica recibir y
presentar información y peticiones de y hacia los usuarios y sistemas externos.
Clases de entidad: Se utilizan para modelar información que posee una vida
larga y que es a menudo persistente. Clases de control: Representan
coordinación y control de otros objetos.
 Relación caso 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 s de análisis y de sus objetos de análisis
en interacción.
 Paquete de análisis: Proporcionan un medio para organizar los artefactos del
modelo de análisis en piezas manejables. Un paquete de análisis puede constar
de clases de análisis, de realizaciones de casos de uso y de otros paquetes,
recursivamente.
 Descripción de la arquitectura: Contiene una vista de la arquitectura del
modelo de análisis, que muestra sus artefactos significativos para la
arquitectura
Trabajadores que  Arquitecto: Es responsable del modelo de análisis, garantizando que este sea
intervienen en el correcto, consistente y legible como un todo.
flujo de trabajo de  Ingeniero de casos de uso: Es responsable de la integridad de una o más
análisis realizaciones de caso de uso, garantizando que cumplen los requisitos que
recaen sobre ellos.
 Ingeniero de componentes: Define y mantiene las responsabilidades, atributos,
relaciones y requisitos especiales de una o varias clases de análisis,
asegurándose de que cada clase del análisis cumple los requisitos que se
esperando ella de acuerdo a las realizaciones de CU en las que participa.
Actividades que se  Análisis de la arquitectura: Esbozar el modelo de análisis y la arquitectura
llevan a cabo mediante la identificación de paquetes del análisis, clases análisis evidente y
durante el flujo de requisitos especiales comunes.
trabajo de análisis  Analizar un caso de uso: Identificar las clases del análisis cuyos objetos son
necesarios para llevar a cabo el flujo de sucesos del caso de uso, distribuir el
comportamiento del CU entre los objetos del análisis que interactúan y capturar
requisitos especiales sobre la realización de un CU.
 Analizar una clase: Identificar y mantener las responsabilidades de una clase del
análisis, basadas en su papel en las realizaciones de caso de uso. Identificar y
mantener los atributos y relaciones de la clase del análisis y capturar requisitos
especiales sobre la realización de la clase del análisis.
 Analizar un paquete: Garantizar que el paquete del análisis es tan
independiente de otros paquetes como sea posible (bajo acoplamiento y alta

Koppito
 cohesión), garantizar que el paquete cumple su objetivo de realizar algunas
clases del dominio o CU y describir las dependencias de forma que pueda
estimarse el efecto de los cambios futuros.
Diagramas de Los diagramas de secuencia y los diagramas de comunicación (ambos llamados
interacción diagramas de interacción) son dos de los tipos de diagramas de UMML que se utilizan
para modelar los aspectos dinámicos de los sistemas. Un diagrama de interacción
muestra una interacción, que consiste en un conjunto de objetos y sus relaciones,
incluyendo los mensajes que se pueden enviar entre ellos.
Un diagrama de secuencia es un diagrama que destaca la orientación temporal de
mensajes.
Los diagramas de interacción se usan para modelas los aspectos dinámicos de un
sistema.
Diagrama de Un diagrama de comunicación destaca la organización estructural de los objetos que
colaboración o de envían y reciben mensajes. Una de sus características es el camino. El camino se dibuja
comunicación haciéndolo corresponder con una asociación. Un camino representa una fuente de
conocimientos de un objeto. En segundo lugar, el número de secuencia. Para indicar la
ordenación temporal de un mensaje, se procede de un número que se incrementa
secuencialmente por cada nuevo mensaje en el flujo de control.
Interacción Se utilizan para modelar el flujo de control dentro de una operación, una clase, un
componente, un CU o el sistema completo
Enlace Es una conexión semántica entre objetos. En general, un enlace es una instancia de
asociación. Siempre que una clase contenga una asociación con otra clase, puede existir
un enlace entre las instancias de las dos clases; siempre que haya un enlace entre dos
objetos, un objeto puede enviar mensajes al otro.
Mensaje Es la especificación de una comunicación entre objetos que transmiten información, con
la expectativa de que desencadenará una actividad. La recepción de una instancia de un
mensaje puede considerarse una ocurrencia de un evento.

Koppito