lOMoARcPSD|2714810

Resumen Final Ade Sist - Apuntes 1,2,3,4,5

Análisis de Sistemas (Integradora) (Universidad Tecnológica Nacional)

StuDocu no está patrocinado ni avalado por ningún colegio o universidad.

Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

RESUMEN DE ANALISIS DE SISTEMAS PARA FINAL

PROGRAMA (UTN-FRBA-según la pagina oficial de la materia):

Unidad temática 1: El análisis de sistemas en la actividad profesional.

Conceptos básicos. Sistemas. Organizaciones. Jerarquías: sistemas y subsistemas. Concepto de información, dato, sistema
de información. Teoría general de sistemas. Vinculación de la materia Análisis de sistemas con las asignaturas Sistemas y
organizaciones y Diseño de sistemas. Importancia y aplicación en la actividad profesional.
Unidad temática 2: Filosofía del trabajo profesional de Análisis de sistemas.
Pensamiento lineal y pensamiento sistémico. Enfoque sistémico para la resolución de problemas. Importancia y
aplicación en la actividad profesional.
Unidad temática 3: Ciclo de vida.
Etapas metodológicas. Necesidad de planeamiento. Planeamiento del proyecto. Técnica de pert y gantt. Análisis y
definición de requerimientos. Relevamiento. Circuitos administrativos. Diagnóstico. Diseño. Codificación. Prueba.
Implementación. Mantenimiento. Fundamentos de la ingeniería del software. Auditoría. Importancia y aplicación en la
actividad profesional.
Unidad temática 4: Técnicas para obtener y documentar información.
Documentación asociada a las distintas etapas. Entrevistas. Encuestas. Cuestionarios. Muestreo. Censo. Estudio de la
documentación existente. Observación personal. Técnicas para deducción de requisitos. Análisis funcional. Diagrama de
contexto. Cuadro de eventos. Diagrama de flujos de datos. Diccionario de datos. Definición de procesos. Tablas de
decisión. Cursograma. Importancia y aplicación en la actividad profesional. Redacción de informes.
Unidad temática 5: Orientaciones para el análisis de sistemas de información.
Orientación por eventos. Orientación por funciones. Orientación por datos. Orientación a objetos. Componentes.
Similitudes y diferencias. Análisis por objetos, técnicas de documentación. Herramientas CASE.

Sistema:
Complejo de elementos que tienen aspectos en común (entre ello un objetivo), organizados interactuantes e interdependientes
que se relacionan formando un todo unitario y complejo cuyo objetivo es común. Cada parte cumple su función para obtener un
resultado final. Las partes se refieren al campo funcional (subsistemas). Se transforma dentro de ciertos límites de estabilidad
gracias a regulaciones internas que le permiten adaptarse a la variaciones de su entorno específico. Situado en un entorno con el
que interactúa. Todo sistema contiene otros sistemas y/o subsistemas y es contenido por otros de carácter superior (jerarquía
sistémica) . Todos los componentes de un sistema y sus interrelaciones actúan en función de los objetivos del sistema. Se deben
cumplir ciertas condiciones para considerarse subsistema: tener objetivos propios coherentes con los del sistema, estar sujetos a
interacción mutua con el sistema total, y estar incluidos en la estructura jerárquica dentro del sistema.
Contexto (o Ambiente): es lo externo al sistema, el conjunto de objetos exteriores que lo influyen y que son a su vez
influidos por él, la separación está dada por los grados de relación de los elementos que interactúan. El contexto a analizar
depende del foco (límite de interés en términos de sistemas).El límite es una “línea” que encierra elementos según el grado de
interdependencia interna con respecto a la externa, para determinar el límite se consideran dos etapas:
1-Determinación del contexto de interés (el famoso circulo con el que encerramos y delimitamos gráficamente al sistema, lo
que esté fuera de él no nos interesará)
2-Determinación del alcance del límite de interés entre el contexto y el sistema (es posible que sólo interesen algunas de las
relaciones entre el sistema y el contexto)
Abierto: la relación con su ambiente es fundamental, hay permeabilidad (comunicación, etc). Absolutamente abiertos no
existen, no tendría límites.
Cerrado: no intercambia con los medios, se auto-abastece. Realmente no existen, lo más próximo son los agujeros negros.
Características de un sistema:
•Propósito u objetivo: todos los sistemas poseen al menos uno
•Globalismo o totalidad : la estimulación de un componente afecta a los demás
•Entropía: tendencia de los sistemas al desgaste (y aumento de aleatoriedad) por el transcurso del tiempo o funcionamiento
del mismo. Si aumenta la información disminuye la entropía (NEGENTROPÍA), en sistemas altamente entropicos debe
tenerse rigurosos sistemas de control y revisión, re-elaboración y cambio.
•Homeostásis equilibrio dinámico entre las partes del sistema, propiedad de un sistema que define su nivel de respuesta y
adaptación al contexto, los sistemas altamente homeostáticos sufren transformaciones estructurales en igual medida en que
el contexto sufre transformaciones
•Todo sistema tiene un principio de organización (código) que cumple 3 funciones:
1)selección (de componentes)
2)relación (los componentes deben relacionarse)
3)Control

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

Entre más especializado sea un sistema menos capaz es de adaptarse a circunstancias diferentes, entre más general menos
óptimo.
Sistema de información: Sistema automatizado o manual que posee un conjunto de recursos humanos, tecnológicos,
materiales, financieros, y metodológicos organizados para brindar a quienes toman decisiones en una organización la
información necesaria para llevar a cabo sus respectivas funciones. No confundir con sistema informático (recibe éste nombre
cuando se incluyen computadores). Conjunto de subsistemas para recolectar, almacenar, procesar, y distribuir información para
la planificación, decisión y señalamiento de un sistema objeto (organización) del cual forma parte. Tipos:
-Sistemas de procesamiento de transacciones (TPS): realiza operaciones rutinarias brindando velocidad y exactitud (cálculos,
clasificación, ordenamiento, etc.) registrando todas las transacciones mejorando la calidad/velocidad del procesamiento
manual.
-Sistemas de información administrativa/gerencial (MIS): ayuda a tomar “decisiones estructuradas” a los directivos. Recurre a
los datos almacenados como consecuencia de los TPS combinándolos con otros de naturaleza externa. Toman un conjunto de
datos y les aplican un un criterio de agrupamiento y filtrado.
-Sistemas de soporte de decisiones (DSS): ayuda a los directivos a tomar “decisiones semi-estructuradas”, generan posibles
escenarios. Estos sistemas deben tener mayor flexibilidad. Ayuda pero no reemplaza el criterio del directivo, la decisión en sí
depende de la persona.
-Sistemas de automatización para oficina (OA): incluye todos los sistemas electrónicos formales e informales cuya función
principal es la comunicación de información entre personas internas y/o exógenas.
-Sistemas basados en el conocimiento o sistemas expertos o sistemas de inteligencia artificial (IA-SE): permite a las
organizaciones proveerse y usar el saber de expertos y especialistas para la solución de un problema, se adoptan
características propias de la inteligencia humana, a diferencia del DSS selecciona la mejor solución, explicando el por qué.
-Sistemas para ejecutivos (SIE): da información del comportamiento global de la empresa. Extrae y comprime un amplio
rango de información.
Rango: indica el nivel de relación de cada subsistema con el sistema mayor, marca claramente una dimensión que actúa como
indicador de las diferencias existentes entre subsistemas. Así, un subsistema de nivel 1 será distinto de otro de nivel 8, entonces
no pueden aplicarse los mismos modelos ni métodos.
Análisis de sistemas: proceso que sirve para recopilar e interpretar los hechos y diagnosticar problemas para mejorar el
sistema. Especifica qué es lo que el sistema debe hacer y cómo alcanzar los objetivos. Su responsabilidad es conducir el estudio
del sistema para conocer los hechos importantes en relación con la actividad del negocio.
Actividad profesional (de cualquier disciplina): resuelve problemas con los siguientes pasos:
-Análisis de la situación actual
-Elaboración y evaluación de soluciones
-Diseño
-Implementación
-Seguimiento y control
Entradas: ingresos del sistema (recursos materiales, humanos, e información), son las fuerzas de arranque, suminstra al
sistema sus necesidades operativas. Pueden ser:
-En serie (es la salida de un sistema anterior relacionado con él)
-Aleatoria (al azar)
-Retroacción (re-introducción de una parte de las salidas)
Caja negra: representa a los sistemas cuando no se sabe que elementos componen al sistema o proceso, aunque se sabe que a
determinadas entradas corresponden ciertas salidas
Salidas: resultados obtenidos al procesar entradas, pueden ser productos, servicios, e información. Son el resultado del
funcionamiento del sistema o, el propósito para el cual existe el sistema. Se convertirán en la entrada de otro sistema para luego
convertirse en salida y repetir el ciclo.
Relaciones: enlaces que vinculan objetos o subsistemas de un sistema complejo, pueden ser:
•Simbióticas: los sistemas conectados no pueden seguir funcionando solos, se clasifican en:
-Unipolar (parasitaria): un sistema (parásito) no puede vivir sin el otro (planta)
-Bipolar (mutual): ambos sistemas dependen entre sí
•Sinérgica: relación No necesaria para el funcionamiento pero sí útil. La Sinergia es la acción combinada (la acción
conjunta de subsistemas semi-independientes es mayor que la suma tomada independientemente)
•Superflua: aquellas que repiten otras relaciones. Basadas en la confiabilidad ya que aumenta la probabilidad de que un
sistema (y no una parte de él) funcione todo el tiempo
Atributos: definen al sistema tal como lo observamos, pueden ser:
-Definidores: aquellos sin los cuales una entidad no sería designada o definida tal como se lo hace
-Concomitantes: aquellos cuya presencia o ausencia no establece una diferencia significativa
Adaptabilidad: propiedad de aprender y modificar un proceso, estado o característica de acuerdo a las modificaciones de un
contexto. Para ello debe tener un fluído intercambio con el medio.
Matenibilidad: propiedad de un sistema de mantenerse en funcionamiento constantemente.
Estabilidad: un sistema es estable cuando puede mantenerse en equilibrio a través del flujo continuo de materiales, energía e
información.
Armonía: propiedad que mide el nivel de compatibilidad con su medio/contexto. Altamente armónico; sufre modificaciones en

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

su estructura, proceso o características en la medida en que se lo exige y es estático cuando el medio también lo es.
Optimización: modificación del sistema para lograr el alcance de los objetivos.
Suboptimización: es proceso inverso, se presenta cuando un sistema no alcanza sus objetivos por las restricciones del medio
o por que hay varios objetivos excluyentes entonces se deben restringir los alcances de los objetivos o eliminar los de menor
importancia.
Exito: la medida en que los sistemas alcanzan sus objetivos.
Organizaciones como sistemas: la organización es un sistema socio-técnico incluído en otro; la sociedad, con la que
interactúa influyéndose mutuamente. También la definimos como un sistema social, integrado por individuos y grupos de
trabajo que responden a una estructura y dentro de un contexto al que controla parcialmente, desarrollan actividades aplicando
recursos en pos de ciertos valores comunes. Subsistemas que forman la empresa:
-Psicosocial: compuesto por individuos y grupos en interacción. Formado por la conducta individual y la motivación, las
relaciones del estatus y el papel, la dinámica de grupos y los sistemas de influencia.
-Técnico: los conocimientos necesarios para el desarrollo de tareas, incluyendo las técnicas usadas para la transformación de
insumos en productos.
-Administrativo: relaciona a la organización con su medio y establece los objetivos, desarrolla planes de integración, estrategia
y operación, mediante el diseño de la estructura y el establecimiento de procesos de control.
Modelo de realidad:

universo
variable independiente (estímulo)
contexto límite

variable dependiente (rta.) frontera

Dato: aquello que una persona puede detectar a través de sus sentidos o que una computadora pede ingresar a través de sus
unidades de entrada. Medición de un aspecto determinado de la realidad, reflejo de la realidad, interese o no. Sólo depende del
hecho, de qué sucedió. Es un concepto plenamente objetivo.
Información: Datos+conocimientos del sistema+situación actual. Conjunto de datos que interesa en particular. Es un concepto
subjetivo, un significado que se le asigna a un dato (que éste informe o no sobre algo depende del receptor). Debe cumplir con:
1.Actualizada-2.Necesaria 3.Oportuna 4.Confiable 5.Explicable.
-Efectividad: debe llevar a cabo esos 5 puntos
-Eficiencia: debe ser positiva en relación con el factor costo/beneficio.
Su característica fundamental: sirve para tomar desiciones.
Variables: cada sistema o subsistema tiene un proceso interno dinámico que se desarrolla sobre la base de la acción,
interacción y reacción de distintos elementos. La varible es cada elemento que compone o existe dentro de los sistemas. No
todas tienen el mismo comportamiento, según el proceso y las carcterísticas del mismo asumen comportamientos distintos
dentro del mismo proceso de acuerdo a las circunstancias. Pueden ser: Controlables (de comportamiento predecible), o No
controlables (no se sabe cuando cambiarán, no son predecibles).
Parámetro: comportamiento de una variable, no tendrá cambios ante alguna circunstancia específica (no significa que sea
estática, sólo lo hace en una situación determinada).
Operadores: otro comportamiento de una variable. Activan a otras variables e influyen en el proceso para ponerlo en marcha.
Son líderes.
Retroalimentación: permite el control de los sistemas para tomar medidas de corrección. Se produce cuando las salidas del
sistema (o la influencia de éstas en el contexto) vuelven a ingresar al sistema como recurso o información.
Feed-Foward (alimentación delantera): forma de control de los sistema que se realiza a la entrada del sistema para que las
entradas no sean malas, entonces, al no ser malas las entradas las fallas serán consecuencia de los procesos que componen el
sistema.
Integración e independencia: un sistema integrado es aquél donde su nivel de coherencia interna hace que un cambio en uno
de sus subsistemas produce cambios en los demás. Un sistema es independiente si un cambio en él no afecta a los demás.
Centralización y des-centralización: centralizado cuando un núcleo comanda a los demás y los activa. Descentralizado cuando
el núcleo de comando y decisión está formado por varios subsistemas. Los centralizados son más fáciles de controlar, requieren
menos recursos y son más lentos en su adaptación al contexto.
Isomorfismo: construcción de modelos de sistemas similares al modelo original (hacer una copia o modelo de algo para
estudiarlo y extraer conclusiones).
Homomorfismo: al modelo aquí se le reducen sus variables.
Equifinalidad: sugiere que ciertos resultados pueden alcanzarse con distintas condiciones iniciales y por medios divergentes.
Teoría General de Sistemas: conceptualizado por Bertalanffy (años 50´s), quien percibe junto a otros científicos que en
varias disciplinas de la ciencia habían surgido concepciones y puntos de vista semejantes. Tratan de desarrollar una teoría
totalizadora e interdisciplinaria. El principio clave en el que se basa es la noción de “totalidad orgánica”. Se fundamenta en 3
premisas básicas:

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

1-Hay una jerarquía de sistemas: suprasistema (o metasistema), sistema, y subsistema.

2-Los sistemas son abiertos (consecuencia de la premisa anterior). Cada sistema (excepto el mayor o el menor) percibe y
descarga algo en otros sistemas, generalmente contiguos. Tienen un proceso de intercambio infinito con su ambiente, que son
otros sistemas, cuando el intercambio cesa el sistema se desintegra.
3-Las funciones de un sistema dependen de su estructura.
Bases: 1-Impulsar el desarrollo de una terminología general que permita describir características, funciones y comportamientos
sistémicos.2-Desarrollar leyes aplicables a éstos comportamientos. 3- Promover una formalización de éstas leyes (un
comportamiento matemático).

Pensamiento lineal:
•El primer paso es plantear o definir correctamente el problema.
•Buscar la/s causa/s del problema (número finito de causas), éstas deben tener una relación directa con el problema.
•La característica fundamental de este modelo mental es que para resolver el problema, se busca la solución eliminando la/s
causa/s del problema en cuestión, y luego se aplica.
La premisa de trabajo del pensador lineal es que la solución se “mantiene”, permanece por sí sola, vigente con el paso del
tiempo.

Definir el Buscar las Solución = eliminar Implementar la

problema causas las causas solución

Pensamiento Sistémico:aquí el objetivo es identificar las interrelaciones

Identificar y definir el problema (estudiando el contexto):
-Confeccionar un informe del problema existente: debe ser objetivo (sin inclinar la situación a favor de un enfoque u otro),
concreto y no ambiguo (identificar el problema en forma completa y debe tener una única interpretación), comprensible, y
no deben incluir causas de soluciones obvias.
-Determinar la situación deseada: establecer donde desea estar la organización cuando el problema se encuentre resuelto
(estado deseado).
Analizar las posibles causas: también trata de encontrar variables y constantes.
-Identificar las causas potenciales (todas las posibles, se puede confeccionar una lista con las 20 o 30 causas más probables)
-Determinar las causas más probables: cuáles de las anteriores son las más probables.
-Identificar el verdadero origen de las causas (analizar las anteriores para identificar sus orígenes, preguntándose varias
veces ¿por qué?)
Identificar alternativas de solución (soluciones más probables)
-Realizar un listado de soluciones posibles (generar ideas y alternativas, brain storming).
-Reducir el listado a algunas (4 s 6).
Seleccionar la mejor alternativa (solución a implementar)
-Establecer y determinar valores a los criterios de selección (determinar los criterios adecuados para seleccionar una
solución).
-Elegir la/s mejor/es solución/es.
Desarrollar el plan de acción(implementar la solución elegida).
-Dividir la solución en tareas consecutivas (pasos de acción, responsables, pasos, etc.).
-Desarrollar planes para contingencias (considerar situaciones de amenazas).
Implementar la solución y controlar (detectar el desvío y corregir el progreso).
-Obtener los datos de acuerdo con el plan de acción: a partir de un seguimiento se determina si se cumplen las tareas y
metas a corto plazo según lo planificado.
-Implementar los planes para contingencias: cuando las condiciones cambian durante el seguimiento y la evaluación de la
situación lo justifique se ponen en acción los planes de contingencia necesarios con el objetivo de continuar sosteniendo
como válido el estado obtenido adaptándose a las situaciones del entorno.
Evaluar los resultados: verificar que se ha logrado la situación deseada y si los planes actuales son adecuados para que el
problema no se repita.

Definir el Análisis de la Plantear una serie de Elegir en base al Implementar

situación alternativas para la análisis la solución
problema Controlar
(determinar las solución
causas)

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

Enfoque analítico Enfoque sistémico

• Aisla: se concentra sobre elementos individuales. • Relaciona: se concentra sobre las interacciones de los elementos.
• Considera la naturaleza de las interacciones. • Considera los efectos de las interacciones.
• Toma en cuenta los detalles. • Se basa en aspectos globales.
• La validación se realiza por pruebas experimentales • La validación se realiza por comparación del funcionamiento del
en el marco de una teoría. modelo con la realidad.
• Eficaz en el análisis de interacciones lineales o • Eficaz en NO lineales.
débiles.
• Conduce a una enseñanza por disciplinas. • Conduce una enseñanza multidisciplinaria.
• Hay gran conocimiento de los detalles, pero los • Los objetivos son claros, los detalles borrosos.
objetivos en general quedan mal definidos.
Pensamiento lineal Pensamiento sistémico
•Aisla los elementos que integran la realidad, •Identificar relaciones en lugar de asociar causa-efecto.
asignando siempre una causa a cada efecto.
•En un extremo está la causa y en el opuesto el efecto •Se define el problema, se analiza y se plantean soluciones de las
cuales se eligirá una para implementarla.

Ciclos de vida:

Ingeniería de software: métodos, técnicas y herramientas que controlan el proceso integral del desarrollo del software.
Abarca 4 elementos clave:
1-Métodos o técnicas: indican cómo construir técnicamente el software (incluye planificación, análisis de requisitos, diseño
de estructuras de datos programas y procedimientos, codificación, pruebas, y mantenimiento)
2-Herramientas: suministran un soporte automático (o semi) para los métodos (algunas reciben el nombre de CASE)
3-Procedimientos: combinación de técnicas y herramientas, definen la secuencia en que se aplican los métodos, entregas y
controles.
4-Paradigmas: enfoque o filosofía para la construcción de software
Metodología: aplicación de ciertos pasos, reglas, y herramientas en forma ordenada para cumplir con nuestro objetivo.
Enfoque para organizar, dirigir y realizar las actividades del ciclo de vida de un sistema de información, la vista en la
materia es la “Metodología Estructurada”.
Orientación a procesos Metodologías
Orientación a los resultados estructuradas
Orientación a datos
Orientación a objetos
Orientación a sucesos o eventos
Metodología de sistemas: divide el estudio, construcción y evolución del sistema de información en fases, indica etapas,
actividades y tareas de cada fase así como técnicas y herramientas de cada una. Define estándares de documentación
Modelo de ciclo de vida (iso 12207): marco de referencia que contiene los procesos, actividades, y tareas involucradas en
el desarrollo, explotación, y mantenimiento de un producto software (desde la definición de los requerimientos hasta la
finalización de su uso).
Ciclo de vida: conjunto de fases o etapas y sus transiciones por las que pasa un proyecto de software desde que se manifiesta
la necesidad hasta que deja de existir, existen varios modelos cada uno asociado a un paradigma (métodos, herramientas, y
procedimientos).
Introducción: en los 60´s comienza a hablarse de “ingeniería de software”, nunca se pudieron alcanzar niveles de eficiencia en
la construcción de software similares a los conseguidos en otras disciplinas, la construcción de software es un proceso complejo
debido a su naturaleza y a éstas características:
-Complejidad: no hay 2 partes iguales, no existen elementos repetitivos.
-Conformidad: el producto tiene que adherirse a estándares y normas.
-Cambiabilidad: los productos raramente no sufren cambios, ya que parece que es más fácil cambiar el software que un
producto físico.
-Invisibilidad: construcción abstracta, no puede examinarse en el plano físico.
En la construcción del software se distinguen dos tipo de tareas:
1-Esenciales: inherentes a la naturaleza del sistema a construir, relacionado con las necesidades del usuario (modelo abstracto
de solución).
2-Accidentales: relacionadas con la concreción del producto, como es llevado el sistema a la práctica.
1)Cascada puro-Waterfall: se separan 3 etapas principales (luego se fueron agregando etapas, no hay una cantidad establecida):
Definición (que es lo que hay que hacer)
Desarrollo (determinar el cómo) REQUERIMIENTO ANALISIS DISEÑO IMPLEMENTACION MANTENIMIENTO
Mantenimiento (centrado en el cambio)
Aquí un proyecto progresa a través de una secuencia ordenada de pasos, se realiza una revisión al final de cada etapa para

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

poder pasar a la siguiente, y es muy estricto en ese sentido (las etapas no se solapan), por ello el usuario debe conocer antes
todos los requerimientos detalladamente y éstos deberán ser estables. Está dirigido por documentos (son los productos
principales del trabajo y se intercambian entre etapas) y no se tiene un producto software hasta el final del proceso. Funciona
bien para sistemas complejos pero estables, en versiones finales de productos a largo plazo, y en productos complejos que se
entienden correctamente, cuando los requerimientos de calidad dominan sobre los de costes y planificación, también si se
dispone de personal poco calificado (minimiza el esfuerzo inútil). Desventajas: dificultad para especificar claramente los
requerimientos al comienzo del proyecto, antes de hacer cualquier trabajo posterior (diseño, codificación). Es difícil o no se
puede dar marcha atrás, costoso, no es flexible en los cambios y para proyectos de desarrollo rápido demanda documentación.
No genera signos visibles del progreso del proyecto.
2)Cascada modificado-Sashimi: permite un solapamiento mínimo entre las etapas en la revisión final de cada etapa, prueba y
juicio lo antes posible para volver a realizar modificaciones (cuanto más temprano se comete el error más costoso resulta). Se
reduce la documentación necesaria. Inconvenientes: los hitos son más ambiguos ya que es difícil determinar cuando finalizó
una etapa, por lo que se dificulta la correcta traza del progreso. La realización de actividades paralelas puede suponer mala
comunicación, suposiciones incorrectas e ineficiencia. Ideal para proyectos pequeños bien definidos.
3)Espiral: es un modelo de ciclo de vida orientado a riesgos (provee indicaciones tempranas de cualquier riesgo), es de los más
complejos y divide el proyecto software en mini-proyectos (cada uno se centra en uno o más riesgos hasta que se controlan),
riesgo puede referirse a requerimientos o arquitecturas poco comprensibles, problemas con la tecnología subyacente y demás.
La idea básica es que se parte de una escala pequeña al comienzo de la espiral, se localizan los riesgos, se genera un plan para
manejar los riesgos, se genera un entregable que sirve para continuar con la siguiente etapa y se establece una aproximación a
la siguiente iteración (en cada iteración el proyecto avanza un nivel). Cada iteración tiene etapas definidas y conlleva 6 pasos:
1.Determinar objetivos, alternativas , y límites.
2.Identificar y resolver riesgos.
3.Evaluar alternativas.
4.Generar las entregas y comprobar que son correctas.
5.Planificar la siguiente iteración.
6.Establecer el enfoque para la siguiente iteración.
Las primeras iteraciones son las menos costosas y se puede combinar con otros modelos de ciclos de vida.
Ventajas: mientras los costes suben los riesgos disminuyen (ideal para desarrollos rápidos).
Desventajas: modelo complicado, costoso de implementar y complicado de gestionar, requiere que ésta sea concienzuda,
atenta y con conocimientos profundos, es difícil definir hitos objetivos de comprobación para pasar a un nivel mayor.
Requiere mucha coordinación y conocimientos de management.
Util cuando; no se conoce el dominio de aplicación del problema, desarrolladores y usuarios con poca experiencia en el tema,
faltan presiciones sobre los problemas a resolver y la forma de hacerlo, requisitos inestables, recursos (tiempo y costos)
condicionados. Se obtiene una especificación y producto de mucha calidad.
4)Iterativo e incremental: Se divide el problema en partes, se planifican, y se integran todas al final del proceso. Iterativo ya que
este concepto es usado para corregir los errores del incremental, se aprende de lo hecho reservándose tiempo para volver sobre
lo hecho y mejorarlo.
5)Agile: surge en 2001, basado en el ciclo iterativo-incremental, va más allá y propone un cambio de cultura. Se basa en el
“Agile manifesto” y el libro “Extreme programming” teniendo como premisas:
-personas y sus interacciones por sobre los procesos y las herramientas
-el software que funciona por sobre la documentación exhaustiva
-colaboración con el cliente por sobre negociación contractual
-responder al cambio por sobre seguir un plan
Tres valores principales: Integridad (consistencia pensar-hacer), Transparencia (hablar, comunicar, si hay desvíos decirlo),
Compromiso (surge de los dos anteriores).
6)Prototipado evolutivo: habitualmente se comienza desarrollándose los aspectos más visibles del sistema y luego continúa con
el desarrollo del prototipo basándose en la retroalimentación recibida. Se captura un conjunto inicial de necesidades y se
implantan rápidamente con la intención de expandirlas a medida que aumenta la comprensión del sistema. Usado cuando hay
requerimientos cambiantes o el cliente no puede/quiere/sabe especificar los requerimientos, o cuando los desarrolladores no
están seguros de la arquitectura/algoritmo a usar. Genera signos visibles de progreso. No se puede proyectar cuanto va a llevar
el proyecto.
Inconvenientes: en la predicción de tiempos de creación de un producto aceptable. Terminar forzosamente al acabarse el
tiempo y dinero. Dificultades para mantenimiento. Expectativas poco eficientes de presupuesto.
Ventajas: facilidad para modificar el producto software si cambian los requisitos durante la construcción.
7)Prototipado desechable: se construye un prototipo del sistema lo antes posible para entender y validar los requerimientos y
una vez refinados se desecha el prototipo y se comienza a construir el sistema desde cero.
8)Entrega por etapas: se muestra sucesivamente al cliente el software (implementación incremental) el cual no se entrega “de
una” al final del proyecto sino por etapas sucesivas. Ventaja: permite proporcionar una funcionalidad útil al cliente antes de
entregar el total del producto. Da signos tangibles del proyecto. Reduce las posibilidades de que el sistema cambie durante el
desarrollo. Inconveniente: no funcionaría sin una planificación adecuada para niveles técnicos y/o de gestión (a nivel gestión
debe asegurarse que las etapas planificadas son significativas para el cliente asegurando tiempos de entrega).
9)Diseño por planificación: similar al anterior, la diferencia es que no siempre se conoce al principio si se tendrá el producto
para la última entrega. Se garantiza en una determinada fecha software en funcionamiento. Se priorizan y planifican las etapas
de modo que las primeras prestaciones sean las de mayor importancia (o críticas). Inconveniente: gastar tiempo en
prestaciones incompletas que no se van a entregar.
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

Hay que preguntarse cuanta confianza en la habilidad para planificar se tiene, ya que la usamos cuando no hay confianza.
10)Software comercial disponible: sólo recomendable por la inmediatez.
11)Code and Fix: poco útil, muy común, usado cuando no se elige ningún tipo de ciclo de vida, no hay previsibilidad no se sabe
cuando termina sólo se tiene una idea general de “que hacer”. Ventaja: no conlleva ninguna gestión, no se pierde tiempo en
planificación, documentación, control de calidad y todo lo que no sea codificación pura. Se muestra rápidamente el progreso,
requiere poca experiencia. Para proyectos pequeños (demostraciones o prototipos desechables)
Elegir un ciclo de vida es una decisión del proyecto, no hay “silver bullets” (soluciones idénticamente transferibles) se deben
entender ventajas y desventajas de cada tipo de ciclo de vida. Se debe comunicar y explicar al cliente para que se parte de la
toma de la decisión.

Planificación:
Proceso de seleccionar un método y un orden dentro de las posibles secuencias, actividad que ejercemos para adelantarnos a los
hechos. Pasos a seguir:
1-Tener en claro el objetivo del proyecto.
2-Subdividir el proyecto en tareas más simples.
3-Definir los recursos que se necesitan y los que están disponibles.
4-Establecer la secuencia de las tareas, sus duraciones, la precedencia entre ellas.
5-Definir hitos (puntos de verificación, fechas inalterables o puntos que deben cumplirse antes de continuar), también llamados
puntos de control.
6-Asignar recursos.
7-Revisar el plan.
Puntos de control/hitos: son muy importantes, no sólo es necesaria la creación del plan de trabajo sino también que se cumpla
según lo planeado. Los hitos son como tareas básicas reuniones de seguimiento de proyecto, presentación de informes, y/o
comunicación con el líder del proyecto, éstas tareas implican recolección de datos, clasificarlos y procesarlos para que se
conviertan en información y así poder tomar decisiones. Consumen tiempo y recursos que se le resta a la ejecución del
proyecto. Cuántos hitos programar?, depende del proyecto, permiten tener una retroalimentación de cómo va el proyecto, y los
desvíos. Algunas tareas necesitan más puntos, y otras menos, algunas distribuidas equidistantes en el tiempo y otras acumuladas
sobre los momentos más críticos del proyecto.
Recursos: personas, equipos, y cualquier elemento necesario para cumplir el trabajo cuya disponibilidad es limitada. Los no
limitados son insumos, impactan en los costos del proyecto pero no en su decisión.
Presupuesto: es un recurso de especial interés (tanto el económico como el financiero), en el estudio de factibilidad se hace un
análisis más profundo.
Si quién realiza el control es externo, es por: falta de recursos especializados, que no exista un departamento de planificación
que realice el seguimiento, y/o por seguridad.
Elección de fecha de comienzo: es un aspecto importante a definir, no sería conveniente por ejemplo iniciar en plenas
vacaciones. La orden de comienzo debería ser enviada por un responsable de la empresa (debe estar documentada). Si es
necesario se revisará el plan antes de ejecutarlo.
Herramientas:
Diagrama de GANTT: resuelve el problema de la programación de actividades (distribución respecto a un calendario)
visualizando fechas, duración, y también seguir el curso y porcentaje ejecutado o el adelanto o retraso. Las abscisas en el
calendario representa una escala de tiempo en cualquier unidad. Las ordenadas las actividades/tareas.
Símbolos convencionales: inicio/finalización de una actividad: barra indicando la duración (debajo puede haber una subbarra
con el porcentaje realizado).
Gantt permite identificar la actividad en la que se están usando cada uno de los recursos y la duración de su utilización, de
manera que pueden evitarse períodos ociosos innecesarios.
Puntos de control:
-Determinar el progreso de cada tarea periódicamente y entrar los datos al programa.
-Definir cambios y ajustes a la programación inicial (duración de tareas, cambios de dependencias, recursos asignados, cambio
de recurso a otra tarea).
-Producir informes de avance, estado de proyecto y variaciones del original
-Estudiar el estado del proyecto-> encaminarlo.
Será necesario reportar a la gerencia del proyecto el avance real de cada una de las tareas para cada fecha de corte, la mejor
forma de representarlo es con expresiones porcentuales.
Ventajas: su construcción requiere un nivel mínimo de planificación. Eficaces para representar un plan de
trabajo/controlarlo/ver desvíos para re-planificar.
Desventajas: no ofrece condiciones para el análisis de opciones, no toma en cuenta factores como el costo. No se visualizan
relaciones entre actividades cuando el número de ellas es grande. No se ven bien las dependencias.
Cuando hay muchas tareas entonces agruparlas y luego explotarlas.
PERT-CPM:
Método del camino crítico, 2 orígenes, usan diferentes métodos para las estimaciones de tiempos para las tareas, PERT usa
tiempos probabilísticos y CPM determinísticos. Exponen la ruta crítica de un proyecto (actividades que limitan la duración de
un proyecto). Las actividades no críticas tienen cierto margen. Son herramientas para controlar y monitorear el proyecto
contrastando con las duraciones reales de cada tarea.

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

PERT: el tiempo es una variable aleatoria descripta por una distribución de probabilidad. La distribución para cualquier
actividad se define por 3 tiempos estimados:
1)n: tiempo estimado+probable (tiempo de una actividad en condiciones normales
2)o: tiempo estimado+optimista Tiempo de la actividad: o+4n+p
3)p:tiempo estimado+pesimista 6
CPM:
identificacion del nodo identificación de la tarea
A
2 fecha
fecha fecha
temprana tardía duración de la tarea fecha tardía
de inicio de inicio temprana de finalización
de finalización

Ejemplo: se ve que cuando existen más de una opción de fecha

temprana de finalización de una tarea para un nodo, se elige la más
1 A 10 11
grande o tardía (sino estaríamos con una tarea todavía ejecutándose). 2 C
Cuando hay más de una opción para la fecha tardía se opta por la más 4
chica o menos tardía 6 7
D
B 1
3 7 11
3
Intervalo de flotamiento: tolerancia para el inicio de una tarea:
FECHA TARDÍA-FECHA TEMPRANA sí es 0 entonces es nodo es crítico.
Margen total: tiempo que una tarea se puede retrasar sin afectar el proyecto:
FECHA TARDÍA(NODO FINAL)-FECHA TEMPRANA(NODO INICIAL)-DURACION DE LA TAREA
Tarea crítica: margen total de la tarea es 0.
Margen libre: tiempo que tiene una tarea para terminar en las fechas tempranas:
FECHA TEMPRANA(NODO FINAL)-FECHA TARDIA(NODO INICIAL)-DURACION DE LA TAREA
Reglas de construcción: Dos tareas que comienzan en un mismo nodo no pueden terminar en otro las dos juntas, este caso se
soluciona creando una tarea ficticia y un nodo que se interponen entre una de las tareas y el nodo final a donde convergían las
tareas. Toda la red comienza en un único nodo y termina en otro único nodo.

Metodología de planificación:
1-Definición del proyecto: es una etapa previa que se desarrollará separadamente (no forma parte del método) donde también
puede usarse el método del camino crítico. Es una investigación de objetivos, métodos y elementos viables y disponibles.
Proyecto: combinación de actividades interrelacionadas que deben ejecutarse en cierto orden para terminar un trabajo.
Gestión del proyecto: elaboración del plan (documento que recopila el informe de gestión del proyecto) que fija los recursos
disponibles, divide el trabajo y crea un calendario. Consiste en una serie de actividades paralelas al proceso de desarrollo, se
orientan a:
-Estimación: de esfuerzo humano (personas por mes).
-Análisis de riesgos: evaluación de posibles problemas y sus costos. Se define la Gestión de riesgos. Se usan técnicas de
análisis de impacto, derivadas del enfoque sistémico. Se determinan:
Exposición al riesgo (probabilidad por impacto)
Probabilidad de ocurrencia (analizando el contexto)
Tratamiento de los riesgos:
1)Prevenir (mitigación del riesgo).
2)Controlar daño (contingencia del riesgo).
-Planificación temporal: identificar tareas, establecer la agenda
-Seguimiento: control de la evolución del proyecto. Se extiende a lo largo de todo el ciclo de vida.
La orden de comienzo del plan debe ser dada por un responsable de la empresa y debe estar documentada.
2-Lista de actividades: obtenida de las personas que intervienen en la ejecución del proyecto de acuerdo con la asignación de
responsabilidades y nombramientos hechos en la definición del proyecto. Actividad: serie de operaciones (físicas o mentales)
hechas por una/s persona/s en forma continua sin interrupciones en tiempo de inicio y fin determinables.
3-Definir la secuencia: mediante dos métodos:
-Por antecedentes: se pregunta a los responsables de los procesos cuáles actividades deben terminarse para ejecutarse otras,
cada una de las actividades tienen por lo menos un antecedente (excepto la inicial).
-Por secuencia: se pregunta a los responsables de la ejecución cuáles actividades deben hacerse al terminar cada una de las
que aparecen en la lista. Haciéndose una matriz de secuencia.
Si se hace una matriz de antecedentes es necesario hacer luego una matriz de secuencia (es la usada para dibujar la red). La
información obtenida como resultado de estos procedimientos (por antecedentes y por secuencia) se expresa primero en una
tabla llamada MATRIZ DE ANTECEDENCIAS , que parte de la lista de actividades, agregándole una columna de antecedentes
(todas menos la inicial deben tener una). Luego se hace una transposición de la información para convertirla en una MATRIZ
DE SECUENCIAS.
4-Definición de la duración de cada una de las tareas: se requieren tres cantidades estimadas por los responsables de los
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

procesos (tiempos: medio-oportuno-pésimo).

5-Red de actividades: red es la representación gráfica de las actividades que muestran sus eventos, secuencias interrelacionadas
y camino crítico. Evento: momento de iniciación o finalización de una actividad, llamado también “nodo”.
Tareas de la planificación:
-Definir y conocer el objetivo.
-Subdividir el proyecto en tareas más simples.
-Confeccionar la lista preliminar de requerimientos (necesidades de usuarios).
-Definir recursos necesarios y disponibles (personas, equipo, etc.->elementos limitados).
-Definir el ciclo de vida.
-Establecer secuencia precedencia de tareas:
Por antecedentes
Por secuencia: ídem. a la anterior sólo que son las actividades que deben hacerse al terminar cada una de las que aparecen en
la lista.
-Conocer la duración de cada una de las tareas. Hay 3 métodos para estimar: 1)histórico, basado en proyectos anteriores.
2)intuitivo. 3)estándar, basada en tiempos probables, pesimistas y optimistas.
-Definir hitos/puntos de control.
-Asignar los recursos, incluyendo las personas.
-Revisar el plan.

Etapas metodológicas:

Etapas metodológicas – Introducción:

1)Necesidades de un nuevo sistema de información:
•Problemas en el sistema actual: dejo de cumplir con los objetivos (eficiencia-eficacia).
-certeza: existe un problema real en el sistema actual.
-presunción: acción y efecto de presumir un problema.
-prevención: de un problema futuro.
•Oportunidades: optimización del sistema actual, mejora en los costos de operación.
•Requerimiento del negocio o nuevos desarrollos: hacer frente a nuevas necesidades.
•Un proyecto se emprende por las 5 “C”:
-Capacidad: de la organización para procesar transacciones con rapidez y eficiencia, los sistemas de información la mejorarán de 3 maneras:
1.aumenta la velocidad de procesamiento, 2.manejo de volúmenes crecientes, 3.recupera con rapidez la información.
-Control: para mejorar la exactitud y consistencia. Aumentar la seguridad de los datos más importantes.
-Comunicación: los sistemas de información bien desarrollados la amplían y facilitan la integración de funciones individuales. Aumento de la
comunicación, integración de distintas áreas en la empresa.
-Costos: vigilancia de los costos. Reducción de los costos.
-Competitividad: mejorar ante la competencia.
2)Conocer la organización donde se desenvuelve el sistema de información:
•Estudio preliminar.
•Reconocimiento ->resultado: informe de reconocimiento.
3)Conocer las necesidades del sistema de información:
•Relevamiento: conocimiento detallado ->resultado: requerimientos de sistema
4)Determinar la posibilidad de implementar la solución:
•Estudio de factibilidad:
-factibilidad técnica
-factibilidad operativa
-factibilidad económica
5)Desarrollar el modelo lógico de la solución
•Análisis ->modelo lógico (diagramas)
6)Puesta en funcionamiento
•Implementación/implantación
-implantación parcial
-implantación abrupta
-implantación en paralelo
7)Vida útil del sistema de información
•Control/Seguimiento/Auditoría
8)Necesidad de nuevas funcionalidades
•Retiro

Estudio Relevamiento Estudio de Análisis Diseño Implementación Seguimiento Retiro

preliminar factibilidad

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

Técnicas y etapas:
-Planificación
-CPM Todas las etapas -Cursograma Relevamiento
-GANTT
-Relevamiento -Análisis
-Entrevistas Estudio preliminar -DFD
-Cuestionarios Relevamiento -DD Análisis
-Redacción de informes -DER
-Encuestas -Tabla de decisión

Ciclo de vida de un sistema: el sistema tendrá un nacimiento, un desarrollo, una vida productiva, y un fin. El ciclo de vida se
divide en varias etapas:
1-ESTUDIO PREELIMINAR/RECOCONOCIMIENTO/RELEVAMIENTO GLOBAL
Recaudar información de la organización, conocimiento general de la misma. Interacción con el nivel directivo y/o gerencial.
2-RELEVAMIENTO
Se busca conocer los procesos en forma detallada, interacción con el nivel gerencial y/o operativo, pudiendo llegar al directivo
dependiendo hacia quién está orientado nuestro sistema.
3-ESTUDIO DE FACTIBILIDAD
Se proponen distintas soluciones para nuestro sistema y se analizan cuáles son las más viables, dando como resultado de
nuestro estudio una propuesta.
4-ANALISIS
Elaboración de un modelo lógico de la solución.
5-DISEÑO
Elaboración del modelo físico de lo producido en el análisis.
6-IMPLEMENTACION/IMPLANTACION
Se crea el sistema y se lo pone en funcionamiento.
7-CONTROL/SEGUIMIENTO/AUDITORIA
Control de que el sistema este cumpliendo con los objetivos para los que fue diseñado y se realizan las modificaciones
necesarias en caso de necesitarlas.
8-RETIRO
El sistema dejó de cumplir con sus objetivos y se lo prepara para poder desactivarlo dejando paso a un nuevo sistema.

Gráfica de interacción entre los usuarios

y el equipo de sistemas:
Debajo de la curva los recursos del
equipo de sistemas, encima de la curva
los recursos de los usuarios.
1 Estudio preliminar: el equipo recién se
forma, y la mayoría de los recursos son
aportados por los mismos usuarios.
2 Relevamiento: el equipo de sistemas
crece en proporción, aunque es necesario
un importante aporte de los usuarios (nos deben poner al tanto de las necesidades que debemos resolver)
3 Estudio de factibilidad: deberemos resolver cómo será la solución que propondremos. Es fundamental la desición que tome el
usuario para saber el camino a seguir.
4 Análisis: el usuario deberá formar parte del equipo de trabajo para validar los módulos que se propongan siendo el principal
generador de retro-alimentación.
5 Diseño: la participación del usuario deja de tener relevancia ya que es una etapa puramente técnica.
6 Implementación: los usuarios comienzan a probar el sistema (capacitación).
7 Seguimiento: aquí el sistema está en producción, la participación del equipo de sistemas deberá ser mínima; algunos trabajos
de mantenimiento o correcciones de nuevos requerimientos menores. La etapa que más tiempo ocupa del ciclo de vida.
8 Retiro: se detectó un crecimiento de las necesidades de correcciones, se necesitan cambios más profundos.
Mantenimientos:
-Preventivo: muchas veces relacionado con la operación del sistema (distinto a utilización). Ejemplo: depuración de base de
datos.
-Correctivo: modificación del sistema por un error no detectado en la etapa de pruebas (los errores en software existen desde su
nacimiento). La aparición de errores es inevitable, pero hay que intentar que sean lo menos posibles (indicativo de calidad de
software).
-Evolutivo: el sistema puede evolucionar desarrollando nuevas funcionalidades y cambios. Facilidad de realizar los
cambios=calidad de software.

Estudio preliminar: bajo ciertas condiciones ésta etapa puede suprimirse. Consiste en adquirir un conocimiento general de la
organización, de sus actividades, funciones, y objetivos. Con ello se logra una visión global, que permite identificar sus
necesidades. Habrá contactos con:
-Dirección: que tiene la visión estratégica de los objetivos de la empresa.
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

-Gerencia: es la que decide COMO llegar a cumplir esos objetivos.

Se usarán las herramientas: Entrevistas, Organigramas, Estatutos, Manuales de la organización (donde estarán los objetivos,
cómo se realizan las operaciones y qué es lo que se hace), Estudios de mercado, y otros para tener presente la revisión de los
datos de manera objetiva.
La duración del estudio preliminar (que es corto en relación a todo el proyecto) depende de:
-Tamaño de la organización o de la parte de ella afectada.
-Cuál será el límite del sistema (se debe respetar ese límite sin extenderse).
-Complejidad.
-Cantidad/calidad de los recursos humanos abocados.
Resultado de ésta etapa: INFORME ->Informe de reconocimiento. Contendrá:
-Diagnóstico del problema, característica.
-Recomendación:
cambio o reemplazo del sistema actual
modificación del sistema o parte de él
no innovación
-Si es el comienzo del proyecto:
propuesta de solución + difíciles de determinar por falta
estimado de costos/tiempos de la implementación del proyecto de información
otros estudios en proyectos similares
Sus objetivos son:
-Conocer la necesidad o requerimiento del cliente y sus expectativas en nosotros.
-Establecer restricciones o condicionantes del proyecto.
-Obtener un conocimiento general sobre el/las área/s afectadas al requerimiento.
-Conocer la estructura informal del organismo.
-Si fuimos contratados para una consultoría para determinar el problema aquí termina nuestro trabajo (en este caso el trabajo
será más extenso ya que se debería tener algún conocimiento un poco más allá del general).
El estudio preliminar se suprime si se le encarga el proyecto a un área interna de la organización, o si alguna otra organización
externa ya lo hizo, éstos motivos no son determinantes (puede que el área donde se aplica el sistema no tenga contacto con el
depto. de sistemas o no se conozcan particularidades de la necesidad).
Se debe considerar llamar a personal externo si:
-Falta de conocimiento para resolver el problema en particular
-Falta de recursos para encarar el proyecto (cantidad de conocimientos específicos)
-La información a manejar es demasiado sensible para el personal interno

Relevamiento: Se obtiene aquí un conocimiento exhaustivo del funcionamiento de la organización, será la base para el
desarrollo del sistema de información. Se recolectarán todos los antecedentes necesarios para conocer detalladamente el actual
sistema de información y el deseado así como aspectos a ser considerados por el sistema software. En ésta fase se da la mayor
recolección de datos, se orientará al usuario del sistema. Se obtiene: estructura formal hasta niveles operativos, circuitos y
procedimientos administrativos, documentación usada, requerimientos (base para la especificación de requisitos software) y si
existe descripción de software. Comienzo del proyecto propiamente dicho.
-Si el sistema está destinado al sector operativo (o los datos son generados por él)=> interacción con ese sector
-Si los resultados son interpretados por el sector gerencial => hay que conocer qué desean del sistema y en qué forma
-Si los informes apoyarán decisiones estratégicas => la dirección tendrá participación activa
Técnicas de relevamiento (reunir información de los requerimientos del sistema de información):
Observación personal: usado siempre que se interactúa con el usuario, requiere experiencia. La idea es relevar estadísticas,
entonces la observación debe ser sistemática y metódica. Implementación:
1-Observar por períodos a intervalos regulares (podría no observarse la totalidad del evento)
2-Observación continua de un proceso de principio a fin (puede perderse la aparición de casos particulares no frecuentes)
La observación de las actividades de los “tomadores de decisiones” es una manera de evaluar sus requerimientos de
información, tenemos dos focos de observación:
1-Del entorno físico, su lugar de trabajo: examinar sistemáticamente las oficinas de los tomadores de decisiones revela
mucho sobre la forma en que recopila, almacena y comparte la información.
2-Del comportamiento: ver las relaciones entre él y los demás. Ver más allá de los documentos, aspectos sobre su forma de
trabajo que no figura en ningún papel. Ver personalmente la forma en que recopila, procesa, comparte y usa la información
(pueden surgir formas mejores de presentarle la información)
Medición de tiempos: relacionado a la forma de ingresar los datos en un sistema, ver que tipos de datos son, puede sugerir un
rediseño del módulo para el ingreso de datos en función de cómo se le presentan al operador y que tanto papeleo debe hacer
para cargar una única operación/transacción/tarea.
Encuestas (cuestionarios): recolección de datos de forma masiva, generalmente en áreas operativas. Opción para cuando hay
un problema de acceso a la información con las entrevistas. Se debe planificar: qué se pregunta y cómo. Pensar cómo se
procesará luego esa información. Las preguntas serán precisas o “cerradas”, se deberá comprender la respuesta técnica. El
lenguaje usado generalmente no debería ser muy técnico, la respuesta puede sí contenerlo. Puede haber preguntas abiertas
pero son difíciles de procesar, el cuestionario no debe ser muy extenso (cansaría), y se debe tener en cuenta la forma de
distribución y recolección (Internet, formularios, correo, etc.).
Entrevistas: recolección de datos de forma selectiva, conversación dirigida con un propósito específico que usa un formato
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

de preguntas y respuestas, se necesita tener la opinión y el parecer acerca del estado actual del sistema, metas
organizacionales y personales y procedimientos informales. Es conveniente comenzar por los niveles más altos para obtener
cooperación y soporte de la dirección. Es importante captar opiniones, sentimientos, y actitudes. Se distinguen 3 etapas:
1-Planificación: definir a quién. Para elegir a alguien representativo debemos consultar a la gerencia/jefatura. La duración
no debe ser más de 1½ hs. se puede planificar una segunda. Cuando: buscar que el entrevistado no inicie su tarea diaria
pero dando un tiempo de “acomodo”, no hacerlas en períodos de trabajo intenso (liquidación, fin de mes, etc.). Sentido:
conocer opiniones sobre sistemas/métodos/objetivos actuales.
2-Desarrollo:
introducción: romper el hielo, presentación, motivos, descripción del proyecto, hacer sentir al usuario parte del
proyecto (política del usuario)
desarrollo: dos estilos
1.Estructurado: preparación de un cuestionario y su seguimiento paso a paso (puede haber otras preguntas)
2.No estructurado: sólo con una guía de temas, es necesaria mayor experiencia y puede obtenerse información
adicional
-Preguntas abiertas:
ventajas: entrevistado confortable/se recoge información del entrevistado, lenguaje, cultura/proporciona riqueza de
detalles/ revela el camino de preguntas posteriores/más espontáneo/más interesante para el entrevistado.
desventajas: puede dar detalles irrelevantes/puede perderse el control de la entrevista/respuestas pueden consumir
mucho tiempo y poca utilidad/pueden mostrar un entrevistador poco preparado/entrevistado puede pensar que se
busca un objetivo.
-Preguntas cerradas
ventajas: ahorra tiempo/entrevistas de fácil comparación/se mantiene el control/se tratan muchos temas/se obtienen
datos relevantes
desventajas: pueden ser aburridas/no se obtienen detalles extras/se dirige al entrevistado/se pierden las ideas
principales/puede no establecerse una relación armoniosa
Se deben evitar las preguntas conducentes (dirigen la respuesta) y preguntas dobles (dos preguntas en una)
-Estructuras: de embudo/de pirámide/de rombo
-Averiguaciones: expandir respuestas, demuestra interés y da la sensación de que se lo esta escuchando (ejemplos:
“¿por qué?” , “daría un ejemplo”
-Verificar autenticidad de las respuestas: cruzar información, ver documentación que respalde, repreguntando en otro
momento de la entrevista. Si se detecta falsedad => prepararse => en algunos casos es necesaria la presencia o
participación de un superior para que explique la situación y el compromiso de la org. con el nuevo sistema, si la
situación continúa se evalúa entrevistar a otra persona
cierre: distender la charla o fijar otra entrevista
-Registro: dos formas
1.Grabar:
ventajas: registro preciso y completo/permite mayor contacto visual y armonía/reproducirla a otros miembros/libera al
entrevistador y le permite escuchar y responder con mayor rapidez
desventajas: entrevistado puede ponerse nervioso y limita sus respuestas/entrevistador puede des-concentrarse al
suponer que todo queda grabado/si es extensa seleccionar partes importantes/costos de transcripción de grabaciones
2.Tomar notas:
ventajas: entrevistador se mantiene alerta/ayuda a recordar preguntas importantes/permite recordar tendencias
importantes de la entrevista/muestran interés del entrevistador/demuestran su preparación
desventajas: pérdida de contacto visual/pérdida de la continuidad de una conversación/temor a responder o hablar
mientras el entrevistador toma nota/mucha atención a los hechos y poca a opiniones y sentimientos
3-Informe: en él estará la información revelada, preguntas y respuestas. Se dará al entrevistado para que ratifique o
rectifique (se puede hacer por nota o email)

Requerimientos (nota: según el apunte las definiciones de requisitos y requerimientos son inversas o están permutadas)
Requisitos: necesidades expresadas por los usuarios de las funcionalidades del nuevo sistema, lo que el usuario quiere o
necesita. Cualidades del software para satisfacer los requerimientos del usuario. Nos ayudan a desarrollar el modelo lógico
aportando todas las funcionalidades necesarias. los requisitos se transformarán en requerimientos software Los
transformaremos en requerimientos del sistema. Los pasos entonces serán:
1.Obtener la lista de los requerimientos: no ambigua, correcta, completa, y consistente
2.Análisis y especificación de requerimientos: dividir el problema en etapas y tareas más sencillas para entender los
requerimientos, se busca definir los comportamientos o requerimientos:
a)Funcional: relacionado con las necesidades expresadas por los usuarios, las funciones que debe cumplir para llegar al
objetivo, especifican la función que un sistema o componente debe realizar, sus entradas y salidas.
b)No funcional: relacionado con las necesidades del entorno (como ser temas legales), características de funcionamiento o
ejecución que debe tener un sistema o componente (tiempo de respuesta, de servicio, requisitos de seguridad, interfaz,
estándares), propiedades emergentes que restringen a los funcionales.
Requerimientos del usuario: declaraciones en lenguaje natural y diagramas los servicios que espera que el sistema proporcione.
Requerimientos del sistema (o especificación funcional): es detallado y preciso, define exactamente que es lo que se va a
implementar.
Requerimientos del negocio: objetivos del nivel de la organización o cliente.
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

Requerimientos de usuario: tareas que el usuario debe poder realizar con el producto (pueden ser la descripción de casos de uso
o escenarios), se pueden agrupar en: condicionales, relacionado a una mayor calidad (nota: req. No funcionales?), escenciales ,
relacionado con lo que sí o sí debe tener (nota: req. Funcionales?), y opcionales (el usuario no los nota)
Requisitos del software: exactamente lo que el sistema debe hacer
Funcionales: describe los servicios (funciones) que se esperan del sistema
No funcionales: son restricciones sobre los requisitos funcionales
del producto: cualidades del software
del proceso: tiempo y forma en la que se implementan los estándares a cumplir
externos: deben cumplir las leyes, normas éticas, etc.
Características de una buena especificación de requerimientos:
-escrita en un lenguaje formal y siguiendo las técnicas de redacción de informes
-correcta
-consistente(sin contradicciones entre ellos y si las hay se resolverá en el momento de transformarlos en requerimientos
-no ambigua (podría llevarnos a resultados distintos de las necesidades pretendidas por los usuarios)
-verificable y validable (los requerimientos se obtuvieron a través de un proceso verificable, y los resultados se corresponden
con lo solicitado)
-tener trazabilidad (define la historia y orígenes de los requerimientos)
Concepto de ingeniería de requerimientos: actividades que intentan entender las necesidades de los usuarios y traducirlas en
afirmaciones precisas y no ambiguas. Tiene tres aspectos fundamentales: 1.comprender el problema 2.describir el problema
3.acordar sobre la naturaleza del problema. Las actividades a realizar son: aseguramiento de calidad

Educción Documentación Negociación Gestión de requisitos Análisis Verificación Validación

(junto al usuario) (+ el usuario) (+ el usuario)
Ingeniería de requisitos: tareas para comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente
quiere y cómo interactúan los usuarios finales con el software, define actividades a realizar, su secuenciamiento, entradas y
salidas de cada actividad, etc. consta de 4 etapas:
1-Educción de requisitos: descubrir los requisitos, identificación y primera aproximación con los interesados, fuentes:
interesados/afectados, metas, conocimiento del dominio de la aplicación, entorno físico del sistema, entorno
organizacional. Técnicas: preeliminares (pregunas libres), brainstorming, entrevistas, observaciones de tareas, escenarios.
2-Análisis y negociación de requisitos: los pasos serán
Análisis: analizar conflictos entre requisitos, límites y relación del entorno, traslado de requisitos de usuario al software
Clasificación: los requisitos deben ser anotados de acuerdo a:
-su funcionalidad: funcionales (capacidades) – no funcionales (restricciones)
-su importancia: obligatorios/esenciales – condicionados/deseados – opcionales
-su prioridad: alta – baja – media
-su estabilidad: volátiles/cambiantes – estables – moderados
-su costo
Modelación conceptual: aspectos de los requisitos que se expresan mediante modelos de datos, de objetos, etc. para
entender claramente el problema
Negociación de requisitos: aparecerán o se descubrirán conflictos de intereses, esto desemboca en una renegociación
para determinar qué requisitos se toman en cuenta y cuáles no
3-Documentación de requisitos: para guardar y comunicar requisitos, se usan dos documentos que pueden usar todo tipo de
notación pero tienen distinto nivel de detalle
1.Documento de requisitos de usuario (DRU): escrito desde el punto de vista del usuario o cliente. Bajo nivel de detalle.
Descripción del problema y metas deseadas. Descripción del dominio del problema.
2.Especificación de requisitos de software (ERS): desarrollo de los contenidos del DRU. Responder: ¿que característica
debe poseer el sistema para solucionar lo expuesto en el DRU?. Describe el dominio de la solución. Características
deseables de una ERS: no ambigua, completa, correcta, comprensible, verificable, consistente (no existe contradicción
entre requisitos), realizable, independiente del diseño, trazable (cada requisito se debe poder identificar de forma única),
modificable (facilidad de ser), almacenada electronicamente, ejecutable (por una herramienta software), anotada por
relativa importancia, no redundante, precisa, reutilizable, trazada, organizada, con referencias cruzadas.
4-Validación de requisitos: objetivo: descubrir problemas en el documento de requisitos antes de comprometer recursos
mediante revisiones (se incluye al usuario para hacerlas con él), se usan listas de comprobación (checklists) según los
sistemas.
Una vez validados se congelan y escribe la “linea base de requerimientos” que será un compromiso y se maneja por contrato.
Gestión de requisitos: de los cambios a éstos, consume grandes cantidades de tiempo y esfuerzo, abarca todo el ciclo de vida.
Necesario ya que los requisitos son volátiles, el entorno cambia, hay cambios de reglas y/o procesos de negocio
Linea base de los requerimientos: contiene todos los requerimientos identificados, clasificados, priorizados, y trazables para el
proyecto de sistemas de información. Se definen así porque sirven de base para el planteo del modelo lógico. Atributos de los
requerimientos:
-Tipo: funcional/no funcional
-Autor
-Estado:
-borrador (todavía no se terminó de escribir)
-propuesto (la definición es nueva y todavía no tiene la aprobación)

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

-aprobado (es aprobado formalmente por el usuario)

-rechazado (es descartado por el usuario)
-Origen: identifica al solicitante
-Prioridad: esencial, crítico, importante, deseable, trivial
-Estabilidad: un requerimiento es estable si no se esperan mayores modificaciones sobre él
-Responsable: nombre del responsable de crear la definición del requerimiento
Un requerimiento está bien escrito cuando: es claramente entendible por todos los interesados, contiene sentencias simples y
completas que identifican quien realiza la tarea y la tarea que se está realizando, el resultado de la tarea, el receptor del
resultado. Sin excepciones y/o conjunciones.
Manejo de requerimientos: las necesidades que el sistema debe satisfacer se entrelazan y relacionan entre sí (la forma mas
simple es de “cadena”: los distintos requerimientos dependen entre sí, es poco probable), si se formará una red de distintos
requerimientos entrelazados, esas relaciones definirán las dependencias y permitirán definir la trazabilidad horizontal, que
permite detectar qué requerimientos se afectan al cambiarlos por otros:

Administración de requerimientos: (corresponde en realidad a etapas posteriores)

Cuando es necesario hacer algún cambio en los requerimientos hay que aprovechar la trazabilidad horizontal para ver cómo
afectará el cambio a otros. Se debe dejar registrado por qué se originó el cambio, qué afecta, y quién ha aprobado continuar.
Esto se debe a que todo cambio implica realizar nuevamente alguna etapa y con ello consumo de dos recursos finitos: tiempo y
dinero. Los cambios implican una nueva versión/sub-versión del desarrollo, entonces se evalúa y define si se implementan los
cambios para generar una nueva versión o se postergan para una posterior evolución. La nueva versión, la imaginaríamos como
que se apilan (crecimiento vertical) las versiones, por ello el seguimiento de las versiones se hace por trazabilidad vertical:
Req.3.2

Req.1.2 Req.4.1

Req.3.1 Ver.2

Req.2.1
Ver.1
Req.4.1
Req.1.1

Req.2.1

Conclusión: a partir del relevamiento encontraremos los requisitos expresados por los usuarios, con ellos mediante una
clasificación, ordenamiento y más nueva información=requerimientos del sistema (funcionales/no funcionales)

Estudio de factibilidad: se contrasta si las primeras conclusiones del estudio preliminar siguen siendo válidas. Puntos del
estudio que se revisarán de nuevo:
-Ventajas/razones del nuevo proyecto
mejora en las funciones del sistema
reducción de errores, por ejemplo en la carga de datos
reducir costos
integrar subsistemas
mejoras en los servicios al cliente
optimización de funciones (acortar tiempos de procesamiento)
automatización de procesos, reduce errores, mejora el tiempo de respuesta
-Razones para no llevar a cabo el proyecto:
solo demostrar poder político, o automatizar procesos sólo por el hecho de automatizar.
La actividad en ésta parte del ciclo de vida es presentar soluciones que respondan a los objetivos del proyecto, el estudio de
factibilidad consiste en someter las soluciones a tres tipos de estudios:
1-Estudio de factibilidad técnica: viabilidad del proyecto analizando las variables externas a la organización e influirán en el
proyecto. Necesidades tecnológicas para resolver el problema (compatibilidades, tiempos de entrega, importacines, etc.). Evalúa
si el hardware y software requeridos están disponibles para su uso.
2-Estudio de factibilidad económica: se analiza si se justifica la implementación de la solución en base al análisis
costo/beneficio.
Estimación de costos:
Adquisición
Desarrollo
Operación y mantenimiento
Estimación de beneficios:
Beneficios tangibles (reducción de costos, crecimiento de ganancias)
Beneficios intangibles (calidad de la información, reconocimientos externos)
Aplicación de técnicas de planeamiento de capital:
Payback análisis: tiempo de recuperación de la inversión
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

Retorno de inversión: se calcula ROI (beneficios-costos)

Net Present Value (NPV): determina el valor presente neto de una serie de cash flows, ayuda a valorar teniendo en cuenta el
correr del tiempo si una inversión dará o no beneficios (idem. VAN?)
Participación interdisciplinaria de economistas. Análisis de posibilidades económicas de llevar a cabo el proyecto. Análisis
económicos y financieros, uso de las herramientas VAN (valor actual neto) y TIR (tasa interna de retorno).

VAN = -A + Q1/1+K1 + Q2/(1+K1)(1+K2) + ….....+Qn/(1+K1)+(1+K2)+...+(n+Kn)=∑ Qi/(1+l)i → elevado a la i

A: inversión inicial o capital inicial
Qn: flujos de cada período, los Qn son el capital futuro
Kn: tasa de retorno del período
VAN>0: significa que el proyecto generará un mejor rendimiento que si hubiéramos invertido nuestro capital a la tasa de
retorno solicitada (el K) por lo que es conveniente invertir en el proyecto.
VAN<0: el proyecto tiene un rendimiento menor a la tasa, entonces no es conveniente la inversión.
VAN=0: habría que decidir si invertir o no ya que sería lo mismo.

Cuando se define un proyecto se define la tasa que se va a usar para analizar el plan de negocios. En grandes organizaciones los
departamentos de finanzas son los que definen la tasa. Hay dos formas o fuentes de financiación de proyectos:
1.Internas (la organización), el valor de la tasa será el rendimiento que esperan los accionistas que den sus inversiones.
2.Externas, préstamos, la tasa estará compuesta por la tasa libre de riesgos (una inversión segura, como bonos) más el interés
que desee el inversionista y, puede incrementarse por el contexto de la inversión (tipo de negocio, si es nuevo, etc.)
3.Mixto, el valor se calcula por algun mix entre los aportes del capital

TIR: es el rédito de descuento (decremento de capital por unidad de tiempo), que iguala el valor actual de los egresos con el
valor futuro de los ingresos previstos, usado para decidir la aceptación de un proyecto de inversión. Para ello la TIR se compara
con una tasa mínima (si la TIR es mayor se acepta, sino se rechaza). El valor de TIR es el valor de la K en la fórmula de la VAN
haciendo que sea =0. Nos indica hasta que valor se puede exigir el rendimiento al proyecto. Gráficamente:
unidades: VAN

VAN: dinero
TIR: tasa (porcentaje) TIR

Período de repago: indica cuanto tiempo es necesario para recuperar la inversión (sin usar ningún ajuste de capital en el tiempo,
como el VAN).
La decisión sobre qué proyecto de los disponibles elegir la toma la organización, por lo cual la información deberá estar en el
informe del estudio de factibilidad.
3)Estudio de factibilidad operativa: se analizan las condiciones internas de la organización, se traduce a si el proyecto una vez
puesto en servicio los operarios de qué manera lo recibirán: conforme por que mejora su comodidad o al revés. Aquí se tienen
que tener en cuenta las tareas de capacitación necesarias (las capacidades de aprender y si se puede hacer a tiempo a todo el
personal).
Si varios proyectos pasan el estudio de factibilidad, se evalúan con la herramienta:
Matriz de decisión
Filas: propuestas
Columnas: características, ponderándose cada una modificando su “peso” (la evaluación la hace un equipo o se deberá a
razones que proporciona la propia organización).
El proyecto de mejor puntaje será el que se recomiende
Ejemplo:
Ponderación 30% 55% 5% 10%
Proyecto Hardware Licencias Capacitación Asistencia técnica total Total ponderado
ist. Sueldos/jornales 10 10 3 7 30 9,35
Sist. Liquid. haberes 8 7 10 7 32 7,45
Entonces el proyecto de liquidación de haberes hubiese sido nuestro elegido pero debido a la politica de la empresa le conviene
el proyecto de Sueldos/jornales.

Diseño: transforma el modelo creado en el análisis en estructuras de datos requeridas para implementar el sistema y se definen
las relaciones entre los principales elementos. Se traducen los requisitos en una representación de software. Actividades:
-Definición de base de datos, de módulos, programas, interfaces, procedimientos administrativos.
-Adecuación de estructuras organizativas.
-Preparación de la estructura de los manuales de normas y procedimientos.
-Prediseño de documentos y formularios.
-Desarrollo/Codificación/Programación/Traducción a código: comprende los manuales de procedimientos y los programas.
Realización del diseño de documentos y formularios y redacción de manuales de normas y procedimientos administrativos.
Selección de un lenguaje adecuado para el diseño planteado. Hay herramientas CASE que llevan a cabo el diseño al lenguaje
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

máquina sin ninguna intervención humana.

-Pruebas/Aseguramiento de calidad.
-Instalación/Puesta en marcha/Implementación: debe considerarse la migración. La instalación puede ser total o gradual, se
recomienda el funcionamiento en paralelo. Se instrumentan las innovaciones tecnológicas, se adecuan procedimientos
administrativos y las estructuras organizativas. Capacitación de todos los usuarios.
-Mantenimiento:
Correctivo: corrección de errores no detectados.
Adaptativo: cambios producidos en el proceso o una vez entregado.
Perfectivo: nuevos requerimientos a partir del éxito del sistema.
Absorbe el 60-80 % de los recursos del área de sistemas, se mejora aplicando una adecuada gestión de configuración
(aplicación de procedimientos administrativos y técnicos en todo el ciclo de vida)
-Sustitución: planificada y realizada por fases.
-Auditoría: un experto no involucrado en el ajuste o uso del sistema para que examine la información y asegure su
confiabilidad.
Internos: estudian y supervisan los controles usados en el sistema de información.
Externos: usados cuando se trabaja con información delicada y confidencial.

Administración de Riesgos: procesos dirigidos hacia la administración efectiva de oportunidades potenciales y efectos
adversos
Riesgo: probabilidad de ocurrencia de un evento no deseado
-Política de administración de riesgos: debe ser definida por toda organización y comprendida, implementada, y mantenida en
todos los niveles de la organización.
Se debe definir y documentar la responsabilidad, autoridad, e interrelaciones del personal encargado. Identificar los
requerimientos de recursos y proveerlos. Revisar el sistema de administración de riesgos a intervalos específicos.
Elementos principales:
1-Establecer el contexto: definir parámetros básicos dentro de los que se administran los riesgos
-Contexto estratégico: identificar fortalezas, debilidades, oportunidades y amenazas de la org., aspectos financieros,
competitivos, sociales, legales.
-Contexto organizacional: comprender la org. (metas, objetivos y estrategias).
-Contexto de administración de riesgos: definir el proyecto, metas, y objetivos, extensión, estudios y sus alcances, roles y
responsabilidades, relaciones con otros proyectos.
-Desarrollar criterios de evaluación de riesgos:
Definir la estructura: separar la actividad o proyecto en un conjunto de elementos.
2-Identificación de riesgos: identificar que, por qué, y cómo pueden surgir todos los riesgos (causas y escenarios posibles)
3-Análisis de riesgos: distinguir riesgos menores aceptables y riesgos mayores. Se debe determinar los controles existentes,
consecuencias y probabilidades (se pueden usar análisis y cálculos estadísticos o estimaciones). Tipos de análisis:
cuantitativo, semicuantitativo, cualitativo. Análisis de sensibilidad.
4-Evaluación de riesgos: comparar el nivel de riesgo detectado durante el proceso de análisis con los criterios de riesgo
establecidos.
5-Tratamiento de riesgos: A)identificar el rango de opciones, las opciones incluyen; evitar el riesgo evitando la actividad
causante, reducir la probabilidad de ocurrencia, reducir las consecuencias, transferir los riesgos (uso de seguros), retener los
riesgos. B) evaluar opciones de tratamiento de riesgos: seleccionar las opciones más apropiadas. C) preparar planes de
tratamiento. D) implementar planes de tratamiento.
6-Monitoreo y revisión
7-Comunicación y consulta: desarrollar un plan de comunicación para los interesados internos y externos en la etapa más
temprana del proceso.
8-Documentación: de cada etapa del proceso de administración de riesgos.

Técnica de redacción de informes: clasificación

1)Orales: en presentaciones ante directivos en la etapa de estudio preliminar o relevamiento. No confundir con reuniones de
trabajo (la información fluye del orador a los oyentes). Es necesaria la preparación de material impreso.
->Información que da base a la presentación oral, organización de la presentación, tecnología disponible.
->Documentación:
para los asistentes
para soporte
(Los oyentes deben disponer de los datos usados para generar la presentación)
->Plantear su estructura: único/múltiple presentador/es o un sólo presentador y especialistas para ciertas consultas.
->Tips: siempre de frente, no leer en lo proyectado, en la presentación figura una síntesis y el orador completa los datos para
los asistentes, manejo de tiempo y práctica para determinar la duración.
2)Escritos: estará registrada la información obtenida en los relevamientos.
->Informes no-técnicos: clasificación en función de su alcance:
Notas: dirigidas a personas con alguna vinculación (dirección de compras, u otras).
Circulares: dirigidas a un grupo genérico de personas.
Memorandum: el más general y abarcativo.
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

Correo electronico: lista de distribución.

Deben contener: Fecha - Emisor - Destinatario - Motivo/Tema - Desarrollo - Firma/Certificación.
->Informes técnicos:
Contenido: Caratula – Título - Tabla de contenidos - Introducción (motivo del informe, resumen) – Desarrollo -
Conclusiones (puede ponerse en el resumen) - Anexos - Glosario - Referencia, documentación de apoyo - Indice.
->Presentación: en carpeta o algún tipo de encuadernación, claridad, ortografía, mismo tipo de letra y codificación.
->Redacción: cada párrafo una idea - Usar identación (numeración) - Evitar abreviaturas - Usar términos relativos
(porcentajes) - Algunos ejemplos son útiles.

Control de proyectos: para controlar es necesario medir cada dimensión.

Proyecto: es un esfuerzo temporal con un inicio y un fin definido, llevado a cabo para conseguir un fin último y temporal.
Esfuerzo premeditado.
Dimensiones: aspectos analizables y medibles
-Costo
-Recursos puede ser vista de 3 maneras distintas:
-Funcionalidad/Alcance -restriction (constraint) importanes
-Tiempo -guia (driver)
-Calidad->lo que uno espera recibir -variable con grado de libertad
Si es constraint no es negociable, hay que cumplir sí o sí con ese objetivo.
Si es driver tiene un pequeño margen de libertad.
Diagrama de flexibilidad:
Ciclo de control de un proyecto: un proyecto nace porque tiene un objetivo último que debe ser cuantificable. Se debe controlar
por que un sistema es complejo, tiene elementos complejos y tiende a desorganizarse.
Etapas:
INICIO PLANIFICACION

EJECUCION MONITOREO Y CONTROL CIERRE

Control de las dimensiones:

-Las desviaciones de un proyecto tienen un impacto en uno o más dimensiones
-La manera de controlar y corregir las desviaciones es administrando a cada una:
1.Administración de riesgos (todas las dimensiones).
2.Administración del plan (tiempo, detectar y corregir desvíos en el tiempo, establecer hitos contrastando la situación
actual con la deseada).
3.Administración de costos y revenue (costos, recursos).
4.Administración de calidad (calidad).
Riesgo: problema que todavía no ocurrió. Exposición del riesgo: impacto por probabilidad de ocurrencia.
Como determinar el grado de avance?-> “earned value”: se basa en estimar el valor que agrega cada tarea al total del proyecto.
Usado para comparar costos actuales y planificados, determinando cómo se comporta el proyecto (control de costos). Sirve
para medir “cuanto llevamos ganado” (medir el revenue generado hasta ahora).
Control de calidad: vive durante todo el proyecto. Midiendo producto entregado contra producto especificado, el diferencial es
la deficiencia de calidad.

Herramientas para la toma de desiciones:

Decisiones:
No programadas: típicas del nivel directivo (a veces gerencial), sin precedentes.
Programadas: ejecutadas por el nivel operativo, basadas en información previa suministrada por los niveles superiores.
Las herramientas se usan en la etapa de análisis, en base a información recolectada en el relevamiento.
-Árbol de decisión: basada en el grafo, crece de izquierda a derecha, la profundidad de las ramas puede no coincidir.
1)condiciones: raíz y ramas (círculos) 2)acciones: hojas (cuadrados) : si :entonces
Ejemplo:
semana
entrega en moto
día
fin de 12hs.
semana
-Tablas de decisión: Reglas

condiciones …............... . . . . .
acciones X -

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

Las condiciones y acciones pueden manifestar sus valores de dos formas:

1-Limitados (binariamente): se cumple
-condición no se cumple
se hace
-acciones no se hace A A>100 A<100 ….. . . . . .
2-Extendido: no hay límite. Ejemplo Bonificación 10% 33% ...... .. . . . .
Ambos tipos pueden usarse combinados de cualquier manera.
Pasos para la confección de la tabla:
1-Conocimiento exacto y completo de la situación.
2-Detectar cuáles son las condiciones (las que definen circunstancias que se necesitan para que se pueda tomar la desición) y
qué tipo y cantidad de valores puede tomar.
3-Encontrar las acciones que deben cumplirse para lograr tomar la desición.
4-Establecer combinaciones de valores para cada situación particular del problema.
5-Establecer para cada combinación que acciones realizar.
6-Depurar la tabla
6.1-Eliminar reglas absurdas.
6.2-Reglas con iguales S S S
acciones que difieren en el S S S o I (indiferente)
valor de una condición N C => -
X X X
- - -

7-Agregar una regla NO OPERATIVA que sirve de sumidero de las combinaciones de valores de las condiciones que no fueron
consideradas llamada “otros”. Cuando la combinación de condiciones es una nueva posibilidad que aparecerá en otro
momento → la acción debe ser “consultar”.
1 2 3 4 5 6 7
O
t
. r
. o
: s
Consultar X

Si la tabla tiene al menos una condición con más de dos posibilidades entonces se llama de registro extendido, sino es binaria.
->Cantidad de reglas: multiplicación entre las posibilidades de cada condición.
->Simplificación:
-condiciones de indeferencia: sólo se toman en cuenta las condiciones que definen las acciones, a las indiferentes se les coloca
un “-” (se deben simplificar de dos en dos)
-condición de exclusión mutua: >18 años X X
<18 años X X
no existe(no puede ser mayor y menor de 18 a la vez)=>se eliminan
-contradicciones: a mismas condiciones distintas acciones (error de construcción).
->Tabla concatenada: usado cuando el problema está formado por subproblemas independientes. Con una tabla de mayor nivel
jerárquico. Conjunto de tablas donde sólo se evalúan parte de las acciones en cada tabla y hay una acción para una regla que es
“EVALUAR EL RESTO DE LAS CONDICIONES EN OTRA TABLA”. En vez de una tabla de 8 condiciones=256 reglas
construimos 2 tablas más pequeñas.

Especificación de procesos: describe las actividades a realizar para transformar los datos de entrada en datos de salida.
Herramientas: tablas de decisión, árboles de decisión, lenguajes estructurados, pre/post condiciones, etc.

Modelo ambiental: determina en forma clara y precisa que es parte del sistema y que no. Herramientas: declaración de
propósitos (textual, breve, y concisa), lista de eventos, diagrama de contexto.
Modelo de comportamiento: describe cómo y que hace el sistema actual para cumplir con los propósitos, cuando ocurre un
evento, qué hace con las entradas y como produce las salidas de y hacia el modelo ambiental. Herramientas: diagrama de flujo
de datos. Diccionario de datos. Diagrama de entidad-relación. Diagrama de transición de estados (modela el control).

En la etapa de análisis se deja de lado el estudio de factibilidad (relacionado con la solución física donde se trabaja en función
de los requerimientos “reales” del sistema) y se trabaja en la solución ideal (abstrayéndose de las limitaciones tecnológicas)
centrándose en la lógica de funcionamiento (modelo lógico de la solución).

Diagrama de flujo de datos (DFD): El dfd es una herramienta gráfica de modelado que identificará cada una de las funciones
que debe cumplir el sistema.
Elementos del DFD:
-Entidades externas: sus nombres deben ser generales apuntando a la función → Cliente →(no Juan Perez)
-Flujo de datos: graficados con una flecha DD inscripción DD es una convención y significa “datos de”, el nombre del
flujo representa el contenido que transporta.

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

-Procesos: el nombre o identificador del proceso en el nivel 0 (también llamado diagrama de contexto) será uno que represente
lo que hace el sistema en general (ej.: “sistema de inscripciones”), en los siguientes niveles debe ser un verbo en infinitivo más
un sustantivo (ej.:“verificar fecha”), tratando de evitar verbos como “procesar” o “hacer”.
2.2 identifica el nº de proceso y da una idea del nivel en el que se está trabajando, cuando se realiza el diagrama de
contexto irá el número 0, en el nivel 1 cada uno de los proceso tendrá una numeración de un dígito (1, 2, 3,
..etc.), en el nivel 2 será de dos dígitos ya que habrá procesos que se constituyen por la división de un proceso
del nivel 1 (así por ejemplo el proceso de nivel 1 identificado con el número 2 llamado “controlar pedido” se
dividirá en el nivel 2 en dos procesos: el 2.1 llamado “chequear stock” y el 2.2 llamado “chequear cliente”). Si
el proceso es temporal se le agrega una “T” o un pequeño circulo con una “T” del que sale una pequeña flecha
que apunta al proceso.
-Almacenamientos o demoras: identificación identificadas con un nombre en plural del contenido del almacenamiento.
Construcción:
1.Creación de lista de eventos.
2.Análisis de las funciones que debe realizar el sistema para cumplir el objetivo.
3.Creación de una tabla de eventos que los ordena, ésta debe ser de la manera:
Tipo Descripción Estímulo Respuesta Entidad externa Nombre
“flujo” o Se describe que Nombre del flujo Los nombres de los Nombres de las entidades a Nombre
“temporal” es lo que hace que activa o flujos de salida del donde se dirigen los flujos asignado al
el proceso gatilla al proceso proceso que salen del proceso proceso

4.Se desarrolla gráficamente lo hecho en la tabla.

5.Si alguno de los procesos detallados en la tabla puede descomponerse en otros se repite el ciclo, desarrollando un nivel más.
Recomentdaciones:
-Las comunicaciones entre entidades externas no interesan (no tenemos control sobre ellas y no interactúa con nuestro sistema).
-Estímulo: flujo de entrada que permite que el evento comience a cumplir con el objetivo (desencadena el proceso).
-En el dfd no se tienen en cuenta los tiempos que tarda cada proceso, ni el orden. No se usan más de 6-7 proceso por nivel.
-Ninguna entidad externa tendrá acceso a medios de almacenamiento del sistema, un proceso intermedio le proveerá tal
información (a veces el almacenamiento forma parte de la entidad externa => no se grafica).
-No deben existir procesos sumideros: ni fuentes:
-No debe haber comunicación entre almacenamientos.
-Se recomienda una sutil diferencia entre flujos entrantes y salientes en los procesos que hacen validaciones. X X
no es recomendable. Rta.
-Cuando una entidad externa requiere información es necesario informar al sistema QUÉ necesita. Pregunta
-Requerimiento de información de un almacenamiento
-Actualización de un almacenamiento
-Nombre de entidad: un sustantivo singular.
-Lista de eventos: lista de los estímulos (acontecimiento que activa, dispara, obliga a actuar) que ocurren en el mundo exterior a
los que el sistema debe responder
-Tipos de eventos: temporales, de flujo.

Diccionario de datos (DD): es un listado organizado de todos los datos pertinentes al sistema con definiciones precisas y
rigurosas para que tanto usuario como analista tengan un entendimiento común de todas las entradas, salidas, componentes de
almacenes y cálculos intermedios. Conjunto ordenado alfabéticamente de definiciones, cada definición corresponderá a un flujo
de datos o almacenamiento. Elimina ambigüedades de interpretación de los flujos, no es una herramienta completa para
describir el sistema, su utilidad se halla cuando se usa junto al dfd y al der.
Simbología:
= : compuesto por
+ : concatenación de datos
cant. mínima{}cant. máxima : repetición de elementos (en cualquier orden)

[|] : situaciones disyuntivas (una u otra)

() : componentes opcionales (pueden o no estar presentes)
* *:comentarios, aclaraciones
@ :marca el identificador (campo clave) en los almacenes
alias : indican misma estructura con distintos nombres
Ventajas del DD: se consigue mayor presición, genera documentación, elimina redundancia e incongruencia.
Desventajas: difícil de chequear inconsistencias, mantenimiento y confección tediosa.
Ejemplos:
Apellido(FD) = A..Z+{a..z}
Número = [0..9]
Nro.Calle = {Número}4
Segundos = [0..59]
caracteres = [A..Z|a..z|0..9]
títuloCD = {caracteres}22
temamusical = títuloCD + Segundos

Descargado por ornella Pandolfi (p.sofia92@gmail.com)

 lOMoARcPSD|2714810

Diagrama entidad relación (DER): representa cómo se agrupan los datos que se definieron en el DD y la relación entre ellos.
Representa la estructura de los datos que maneja el sistema.
-Entidades: son las ideas sobre las cuáles se desea guardar información que debe perdurar en el tiempo, representan las ideas
del negocio (negocio=lo que hace el sistema)
-Relaciones: vinculan las entidades según la lógica que maneja el sistema.
-Atributos: componen las entidades. Sólo pertenecen a una entidad.
-Instancia: elemento particular de cada entidad formada por uno o más :
atributos
identificador: formado por uno o más atributos, sirve para diferenciar una instancia de otra.
unívoco: uno a cada instancia
mínimo: compuesto por la menor cantidad de atributos posibles
familiar
Clasificación de entidades:
Fundamental => identificador: atributos propios.
Dependencia simple => identificador: uno o más atributos y al menos una relación.
Asociativa => identificador: sólo relaciones.
Atributivas => identificador: todos sus atributos.

-Relaciones: por ellas viaja el identificador de las entidades (así se compone el identificador). Como los atributos pertenecen a
una entidad, cuando se necesita ese atributo en otra, lo que se realiza es la relación de la entidad que posee al atributo a otra
“destino”.
-Cardinalidad: representa el número máximo de instancias de una entidad que puede relacionarse con instancias de otra entidad.
-Modalidad: representa el número mínimo de instancias de una entidad que se puede relacionar con el número de instancias de
otra entidad. Puede ser opcional u obligatoria

Alumnos (nombre y legajo) notas (legajo, tipo, calificación, y fecha) NOTAS

josé 001 001 tp 3 8/11 ALUMNOS R1 *R1
juan 002 004 tp 4 5/6 NOMBRE *TIPO CARDINALIDAD
ana 004 001 parcial 6 7/5 *LEGAJO FECHA
CALIFICACION
nº máximo de instancias de ALUMNOS que se relacionan
con instancias de NOTAS = 1.

NOTAS obligatoriamente una instancia de NOTAS

ALUMNOS R1 *R1 tendrá relación con una instancia de ALUMNOS, o
NOMBRE *TIPO es necesario que en la entidad NOTAS aparezca el MODALIDAD
*LEGAJO FECHA atributo de la entidad ALUMNOS, o una instancia
CALIFICACION de NOTAS tiene que estar relacionada como mínimo
con una de ALUMNOS.
Sentido del viaje del identificador:
R1 R1 R1???

Relación muchos a muchos: no puede determinarse el sentido

R1 R1 R2
R1 R2

no puede graficarse de ésta manera debe ser

Si entre dos entidades existe una relación 1 a 1 con modalidad obligatoria, entonces es posible que se pueda generar como una
única entidad y que por alguna necesidad particular del sistema se encuentran en dos entidades separadas.

Representación de una entidad Subtipo/Supertipo: CLIENTE

1-Debe existir un identificador único (codCliente) PERSONAS EMPRESAS
2-Debe haber un atributo discriminador (tipo cliente)
3-Debe haber atributos excluyentes (cuit,razonSocial/dni,nombre)

Representación de por ejemplo la entidad MATERIA y la relación CORRELATIVAS

Los DER son los modelos lógicos más cercanos a los físicos (hay herramientas informáticas que a partir de un der generan
código para crear las tablas para motores de bases de datos). Entre un DER y DFD debe coincidir la cantidad de atributos.

Modelado: los modelos proporcionan una visión del sistema, pueden ser expresados a diferentes niveles de presición.
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

Razones para el modelado:

-Tener una mayor comprensión del sistema ya que los modelos ayudan a visualizar cómo es o queremos que sea nuestro sistema
y permite especificar su comportamiento.
-Focalizándose en un sólo aspecto cuando no se pueden comprender sistemas en su totalidad debido a su complejidad.
Importante para sistemas grandes y pequeños.

Técnica de modelado de objetos (OMT): procedimiento que aplica el enfoque orientado a objetos a todo el proceso de
desarrollo de software. Los métodos de análisis y diseño que propone son independientes del lenguaje viendo el problema y su
solución como objetos y clases que interactúan entre sí.
-Objeto: unidad atómica que posee un estado (determinado por el valor de sus atributos en un instante) y un comportamiento.
Representa una entidad física o abstracta. Son instancias de una clase.
-Encapsulamiento: permite determinar qué información es publicada y cuál ocultada, presentando sus métodos como interfaces
públicas y sus atributos como datos privados. Las clases se tratarán como cajas negras.
-Asociación: forma de interacción entre objetos. Dos objetos están asociados cuando uno usa servicios u operaciones que otro
brinda.
-Agregación: tipo de asociación. Se refiere a definir un objeto en término de sus componentes (“tiene un ...”).
-Composición: tipo de asociación. Indica que un objeto no puede existir sin contener a otro (“contiene ...”).
-Cohesión: grado de relación entre clases en relación al propósito dentro del sistema (recomendable: alta).
-Acoplamiento: indica el nivel de dependencia entre objetos (recomendable: bajo).
-Herencia: permite definir una nueva clase en términos de otra ya existente.
-Polimorfismo: mecanismo que permite redefinir una operación para dos o más clases relacionadas por herencia.

UML(unified modelling languaje) (orientado a objetos): es un lenguaje en gran parte gráfico, es independiente del proceso, no
está ligado a ningún modelo de ciclo de vida, cada diagrama muestra una vista del sistema, no es necesario realizar todos los
diagramas sino aquellos que son representativos para el problema que se está tratando.
-Diagramas estáticos: usados para visualizar, especificar, construir y documentar los aspectos estáticos (estables) del sistema
1.Diagrama de clases:
-Clase: conjunto de objetos que tienen los mismos atributos, operaciones, comportamiento, relaciones, y semántica. Los
atributos identifican los datos de los objetos de la clase y los métodos sus operaciones/procedimientos. Instancias
son los objetos que componen cada clase.
Clase abstracta: no crean instancias de sí mismas, pueden contener métodos abstractos (cuyo comportamiento NO
está definido en ésta clase).
Clase concreta: aquella de la que pueden generarse instancias particulares (objetos).
Superclase: clase de donde se heredan comportamientos y/o estructuras.
Subclase
Clase de asociación: no aparecen “físicamente” entre las clases del sistema.
Interfaz: conjunto de operaciones que especifícan un servicio de una clase (es un tipo especial de clase).
Colaboración: elementos del sistema que brindan un comportamiento cooperativo mayor a la suma de los comportamientos
de los elementos.
Responsabilidades: de un objeto son todos los servicios que él provee.
El diagrama de clases describe las clases que se deben crear en el sistema junto con las relaciones entre ellas. Figurarán
todas las clases con sus atributos y métodos, se modelarán las colaboraciones y el esquema lógico de la base de datos.
Tipos:
Diagrama de clase conceptual: construido en la etapa de análisis (sin atributos ni métodos).
Diagrama de implementación: construido en la etapa de diseño (se agregan los atributos y métodos).
Dos clases pueden relacionarse mediante una asociación (las relaciones entre clases surgen del documento de requerimientos
y del dominio del problema)
Multiplicidad: ESTUDIANTE 5..* Cursa 0..* MATERIA un estudiante cursa 0 o muchas materias, 1
materia tiene al menos 5 estudiantes.
2-Diagrama de objetos: mostrará un conjunto de objetos junto a sus relaciones (es una foto del diagrama de clases en un
instante) nomb.objeto:clase
valores D asociación
atributos
3-Diagrama de componentes (partes físicas del sistema): el componente es un conjunto de clases agrupadas físicamente juntas
en el momento de implementarlas. Representación gráfica de la vista de implementación estática del sistema. Permite modelar
los elementos físicos (tablas, archivos). Suelen construirse en la fase de Diseño.
4-Diagrama de distribución/despliegue (deployment): muestra un conjunto de nodos relacionados, nodo es el elemento físico
que representa un recurso computacional que puede tener capacidad de procesamiento. Muestra distintos componentes físicos
involucrados (pc, servidores, etc.).

Diagramas de comportamiento: usados para visualizar, especificar, construir y documentar aspectos dinámicos (mutables del
sistema):
1.Diagrama de casos de uso: no tiene que ver con entender al sistema como objetos (se usa tanto para paradigmas de objetos
como estructurados), el caso de uso ( ) es una descripción de un conjunto de secuencias de acciones (interacciones actores-
sistemas) que ejecuta un sistema para obtener un resultado de valor para el actor. Es iniciado por un actor, que con otros más
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

intercambiarán datos con el sistema. Especifican un comportamiento deseado (el qué) pero no imponen cómo se llevará a
cabo. Define los límites del sistema y las relaciones con el entorno. Están expresados desde el punto de vista del actor,
documentado con texto informal. Usados para: modelar el contexto del sistema, identificar y organizar actores, modelar y
documentar los requisitos del sistema, documentar funciones del sistema y roles de cada actor.
Documentación: cómo comienza y termina el caso de uso (pre y post-condiciones). Realizar un flujo normal de eventos.
Realizar un flujo alterno de eventos. Detallar excepciones al flujo de eventos. Actores del sistema.
En un sistema puede haber casos de usos incluidos en, o que existen en otros casos de usos. Una relación de inclusión
(INCLUDE) significa que un caso de uso incorpora explícitamente el comportamiento de otro (para evitar describir el mismo
flujo de eventos). En la relación de extensión (EXTEND) un caso incorpora pero implícitamente, a diferencia de include
cuenta con una condición a ser evaluada (extend es usada para modelar la parte de un caso de uso que el usuario puede ver
como comportamiento opcional del sistema).
-Actores ( ): un actor representa uno o un conjunto de roles que son llevados a cabo por un dispositivo hardware, persona, u
otro sistema, y para el caso de una persona ésta puede representar a varios actores. Se conectan a los casos mediante
ASOCIACIONES que indican una relación y la posibilidad de intercambiar mensajes. Son externos al sistema (al
identificarlos delimitamos al sistema). Un actor es una clase de rol, un usuario es una persona que cuando usa el sistema
asume un rol.
2-Diagrama de secuencia: creado durante el análisis, muestra objetos, sus relaciones, mensajes que se envían, destacándose el
ORDEN TEMPORAL de ello. Modelan la ejecución de un caso de uso (escenario) al pasar el tiempo. Para cada escenario se
hará un diagrama de secuencias diferente. Comúnmente se hace sólo el correspondiente al escenario exitoso. Para
confeccionarlo debe estar terminado el diagrama de clases y desarrollados los casos de uso (no necesariamente refinados). Se
refinan durante el diseño (para asignar métodos y descripciones a las clases).
-Poseen “lineas de vida”: lineas verticales, discontinuas que implica la existencia del objeto a lo largo de un período de tiempo.
-Poseen “foco de control”(activación): rectángulo delgado que implica un período de tiempo durante el cual un objeto ejecuta
una acción.
-Interacciones actores-objetos son flechas horizontales (que puede tener una descripción que el actor u objeto origen realiza
sobre el objeto destino) → a + refinamiento éstos serán los métodos.
-Los objetos que ya existían antes de comenzar la ejecución del escenario se dibujan en la parte superior del diagrama, los
demás se dibujan a la altura de su creación en el tiempo, los eliminados son marcados con una X.
Ejemplo: actor1 objeto1: clase1 objeto2: clase2 DIFERENCIAS
El de secuencia representa escenarios.
tarea1 tarea2 El de colaboración representa flujo completo de 1
caso de uso.
respuesta1 respuesta2 El de secuencia modela interacciones entre objetos
al pasar el tiempo.
eliminar El de colaboración se enfatiza en el pasaje de
información entre objetos.
3-Diagramas de colaboración: muestra un conjunto de objetos y sus relaciones. Contienen: objetos, mensajes, y enlaces.
Alternativa para los diagramas de secuencia. Creados en el Análisis y refinados en el Diseño. Se genera uno por cada caso de
uso mostrando todos los flujos de ejecución posibles (escenarios). Las tareas se indican con flechas (enlaces con mensajes), el
orden temporal con un número. No hay mensajes de respuesta (se hacen con asignaciones a pseudo-variables). El anidamiento
de tareas (niveles de profundidad) se representa con un número.
Bifurcaciones (cada una indicada con una letra): la condición va entre corchetes junto al nombre de la tarea.
Iteraciones: marcadas con *.
Apertura cuenta retiro (montoRetiro>saldo) transición de estado
crédito sobrecargada
depósito (montoDeposito>saldoNegativo)
crearCuenta estado
final descripción del evento que motiva el cambio de estado
4-Diagrama de actividades: muestra el flujo de actividades dentro de un sistema que tienen lugar a lo largo del tiempo.
Describen diferentes rumbos de ejecución (alternativas). Estado inicial: punto de comienzo del diagrama. Estado final. Usado
para modelar procesos/actividades/flujos presentes en un caso de uso.
Bifurcación: [TRUE] [FALSE] Conjunción: la ejecución del flujo puede venir desde 2 rumbos =

Fork: una tarea se divide en varios rumbos de Join total: la ejecución continúa luego de que han
ejecución paralelos (no necesariemente llegado las distintas ejecuciones (tareas)
concurrentes)
Join parcial: No es necesario que lleguen todos Separadores: % secciones dependiendo quién esté a cargo de
los recursos ejecutar el flujo

Análisis orientado a objetos

→ Diagramas de caso de uso
→ Diagramas de clase
→ Diagramas de secuencia
Fase de Análisis:
-Determinar QUÉ objetos
-Determinar la responsabilidad de cada objeto
-Determinar qué objetos trabajan en conjunto para cumplimentar un caso de uso
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

-Polimorfismo: habilidad de ocultar distintas implementaciones detrás de una misma interfaz. Una operación tiene igual
nombre en distintas clases y funciona distinto en cada una. Los objetos responden de distinta forma al mismo mensaje.
-Herencia: una subclase hereda de una (herencia simple) o varias (herencia múltiple → problemas:colisiones de nombres de
clases padres, herencia repetida) clases, atributos, operaciones y restricciones reutilizándolas.
-Abstracción: denota características esenciales de un tipo de objeto que lo distinguen de los demás y proporciona una frontera
conceptual. El método de abstracción procede de la identificación de características comunes a un conjunto de elementos,
hacia la descripción condensada de éstas características.
1.Asociaciones de clase: asociaciones a nivel de clase, ejemplo: asociaciones de herencia.
2.Asociaciones de instancia: generadas en los objetos creados a partir de clases
Cardinalidad de asociaciones: una instancia de la clase A se asocia con 0,1, o más instancias de la clase B.
-Clase: son una matriz para la creación de nuevos objetos. Define los atributos que los objetos deben tener y las operaciones
con las que se podrán comunicar los objetos. Usada para agrupar elementos similares y distinguir estructuras de mayor nivel
de abstracción despojada de detalles.
-Encapsulamiento: ocultamiento de la funcionalidad interna de sus operaciones. Da lugar a distinguir dos partes de una clase:
1)Pública (interfaz), 2)Privada (implementación). Un objeto entonces sólo es manipulado por medio de la interfaz que provee
al resto de los objetos.
-Método: conjunto de colaboraciones que tiene un objeto para cumplir una responsabilidad en respuesta a la recepción de un
mensaje. Los mensajes representan la parte pública del objeto, los métodos representan la parte privada.
-Colaboración entre objetos: es la acción de envío de mensajes entre objetos. Define un contrato entre el objeto que envía la
info. (cliente) y el que la recibe (servidor).
Un sistema orientado a objetos es un conjunto de objetos que trabajan en conjunto para alcanzar un objetivo en común.
Objeto: Atributos (almacenan información) → operaciones: nombres de acciones que se envían a los objetos
Un objetos tiene un ESTADO, exhibe algún tipo de COMPORTAMIENTO bien definido y tiene una IDENTIDAD única.
Representa una entidad física y/o conceptual. Es un concepto, abstracción con límites definidos con significado para un dominio
en estudio, puede contener info. y tiene un comportamiento definido.
Un modelo de objetos de un sistema consiste en un set de clases y un set de asociaciones de dichas clases (ANALISIS
ORIENTADO A OBJETOS → DISEÑO ORIENTADO A OBJETOS → PROGRAMACION ORIENTADA A OBJETOS)

CASOS DE USO: son una descripción de un conjunto de secuencia de acciones (interacciones con elementos externos al
sistema) que ejecuta el sistema para obtener un resultado que agregue valor. Son una técnica de “redacción” del conjunto de
secuencias de acciones que ejecuta el sistema. Son independientes del paradigma adoptado. No son una herramienta propia de
UML.
→ Describen tanto lo que hace el usuario como lo que hace el sistema cuando interactúa con él, pero poniendo énfasis en la
interacción.
→ Proporciona un medio para capturar los requerimientos funcionales (enfocándose en el punto de vista del usuario).
→ Permite que desarrolladores y clientes lleguen a un acuerdo sobre los requisitos del sistema (contrato).
→ Permite generar la documentación de usuario y pruebas funcionales del sistema en paralelo con el desarrollo.
Documentación: una vez identificados los casos de uso se comienzan a documentar sus pasos. El documento se crea para cada
caso de uso detallando lo que el sistema da al actor. Podría consistir en:
-Nombre
-Descripción
-Describir cómo comienza y termina el caso de uso
-Realizar un flujo normal de eventos
-Realizar un flujo alternativo de eventos
-Detallar las excepciones al flujo de eventos
-Precondiciones
-Post-condiciones
UML: lenguaje de modelado visual usado para especificar, visualizar, construir y documentar artefactos de un sistema de
software.
→ Flujo: un caso de uso está compuesto por un flujo principal (ejecución del curso normal del caso de uso) y uno o más
alternativos (desviaciones del curso normal por aparición de errores o excepciones).
→ Precondiciones: es única en un caso de uso y refleja el estado en que debe estar el sistema y su entorno para que pueda
comenzar la ejecución del caso de uso. Se asumen como verdaderas.
→ Post-condiciones: reflejan el estado en el que queda el sistema y su entorno luego de la ejecución del caso de uso (qué debe
cumplirse al completarse un caso de uso con éxito).
→ Escenario: camino concreto que puede tomar un caso de uso. Junto a los casos de uso son la base de otros diagramas UML
(actividad, secuencia y colaboración). Cada uno de los escenarios servirá como caso de prueba a la hora de hacer testing (test
funcional) del sistema. El desarrollo de un caso de uso es un conjunto de todos los escenario posibles que se puedan presentar.
→ Niveles de detalle de los casos de uso:
Alto: similar a un documento de requerimientos, donde se detallan: el dominio del sistema (lo que debe hacer), los usuarios,
requerimientos funcionales y no del sistema.
Desarrollo expandido: incluye todos los escenarios posibles, descripto desde el punto de vista del usuario.
Desarrollo real: muestra como debería comportarse internamente el sistema.
→ Relaciones entre los casos de uso:
Descargado por ornella Pandolfi (p.sofia92@gmail.com)
 lOMoARcPSD|2714810

1-Relación de extensión (extend): una relación de extensión se puede usar para modelar la parte de un caso de uso que el
usuario puede ver como comportamiento opcional del sistema. Se usa para indicar que mientras se está ejecutando un caso
de uso se puede opcionalmente usar otro en algún punto de la ejecución del primero. Algunos flujos alternativos pueden
representar un comportamiento opcional seleccionado por el usuario, cuando ese comportamiento puede usarse por
separado entonces es mejor extraerlo a un nuevo caso de uso relacionándolo como extensión del original. Lo que motiva
esencialmente el uso de extensiones es cuando NO es conveniente modificar el caso de uso base. Ejemplo:
ingresar -Representan una parte de la funcionalidad del caso que no siempre ocurre
pedido -Son un caso de uso en sí mismo
Revisar presentación <<extend>> -No necesariamente provienen de un error o una excepción
de nuevos productos Es distinto a una alternativa (la alternativa no es un caso de uso, alternativa es una
excepción o un error, la extensión puede no serlo)
2-Relación de inclusión (include): evita describir el mismo flujo de eventos repetidas veces, poniendo un comportamiento
común en un caso de uso y relacionándose luego mediante <<include>>. Usado cuando un comportamiento se está repitiendo
en dos o más casos de uso separados. O cuando se descompone un caso de uso largo o complejo.

Actores: conjunto de roles que los usuarios de los casos de uso juegan al interactúar con ellos. Ejemplos:
1)Juan y Pablo son operadores (usuarios) del sistema de compras, entonces, modelando:
encargar ASOCIACIÓN: intercambian mensajes
mercadería
operador hacer corregir
2)María es ayudante de cátedra y estudia en la facultad: T.P. T.P.
estudiante ayudante
Identificación de actores:
Quién: proveerá, usará, eliminará info., usará ésta funcionalidad, está interesado en cierto requerimiento, dará soporte y
mantenimiento, dará soporte y mantenimiento al sistema, qué áreas de la org. usará el sistema.
-Usuarios que ejecutan las funciones principales del sistema (en un sistema de mantenimiento de maquinaria hay varias
categorias de usuarios: operarios, supervisores, etc. cada uno tiene roles específicos por lo que se representan como actores
por serparado).
-Usuarios que ejecutan funciones secundarias del sistema, tales como administración del sistema (en una máquina de reciclaje
de latas, cliente: actor principal ya que el sistema se construye para él, pero alguien la maneja, el operario).
-El sistema interactúa con hardware externo (los sensores de un sistema de ventilación que controla la temperatura de un
edificio se representan con un actor).
-El sistema interactúa con otro sistema (sistema de control de stock → pide algo al sistema de compras)
Descripción del actor:
-qué y quién representa al actor
-por qué es necesario ese actor
-qué intereses tiene el actor en el sistema
→ Chequeo de actores: chequear si se consideraron y modelaron todos los roles (se describieron todos los casos de uso). Quitar
actores no asociados a un caso de uso. Combinar en un actor a aquellos actores que desempeñan roles similares. Un actor usa
el sistema de varias maneras o tiene varios y distintos propósitos para usar el caso de uso, entonces se debería tener más de un
actor en ese caso.
→ Relaciones:
Relación de generalización (herencia): usado cuando hay actores con roles parecidos y con algunas diferencias:

ingresar pedido
empleado de venta

autorizar pedido
(hereda de..)
supervisor de venta
Diagrama: muestra un conjunto de casos de uso, actores y relaciones, usado para visualizar el comportamiento de un
sub/sistema. Pasos para su generación: 1.identificar actores 2.identificar casos de uso 3.Priorizar casos de uso 4.Especificar
casos de uso (descripción detallada de un caso de uso) 5.Crear interfaz de usuario 6.Organización de la especificación
(estructurar el modelo).

Descargado por ornella Pandolfi (p.sofia92@gmail.com)