Analisis I - 2012-02

Anlisis y Diseo de Sistemas I
Prof. Marcelo Tadey

Ao 2012 Segundo Cuatrimestre
Sistemas en lnea
Es aquel que acepta material de entrada directamente del rea en dnde se cre. Tambin, , es el sistema en el q que el material de salida, , se devuelve directamente a donde es requerido Los datos almacenados usualmente se organizan de tal manera que los registros puedan ser recuperados modificados o ambas cosas:
Rpidamente Sin tener que efectuar accesos a otros componentes de informacin del sistema.
Son muy diferentes a los sistemas por lotes, puesto que estos acceden a la informacin de modo secuencial Como estos sistemas interactan directamente con las personas, personas es importante que el analista planee cuidadosamente la interfaz con el usuario Como los sistemas en lnea requieren recuperar datos con rapidez, rapidez es importante disear las bases de datos del modo ms eficiente posible.
Sistemas de tiempo real

Muchos lo consideran como una variante del sistema en lnea. lnea Sin embargo debemos distinguirlos Un sist. U i t de d tiempo ti reall controla t l un ambiente bi t recibiendo ibi d datos, d t procesndolos d l y devolvindolos con la rapidez como para influir en ese ambiente en ese momento. Se espera que muchos sistemas en lnea reaccionen en solo 1 o 2 segundos, aunque en otros casos, la respuesta debe ser casi inmediata. Los tipo de sistemas que requieren esta velocidad de respuesta son:
Sistemas de control de procesos Sistemas de cajeros automticos Sistemas de conmutacin telefnica Sistemas de vigilancia g de p pacientes ( (entre otros) )
Sistemas de tiempo real

Otra caracterstica es que adems de interactuar con los usuarios, interactan con un ambiente autnomo. Estos sistemas deben garantizar el tiempo de respuesta para evitar que el proceso quede fuera de control. Desde un punto de vista de puesta en prctica, los sistemas de tiempo real se caracterizan por:
Se llevan a cabo muchas actividades simultneas Se asignan prioridades a diferentes procesos Existe gran comunicacin entre tareas Existe acceso simultneo a datos comunes
Principales tipos de sistemas

Como en la organizacin existen distintos intereses, tambin existen diferentes clases de sistemas de informacin GRUPO TIPOS DE SISTEMAS Directores (nivel superior) Nivel estratgico g
Gerentes administrativos (nivel medio) Trabajadores del conocimiento y de datos Gerentes operativos Ventas Produccin Finanzas Contabilidad RRHH Marketing
Nivel administrativo
Nivel de conocimiento Nivel operativo
Principales tipos de sistemas

Sistemas de nivel operativo: apoyan a los gerentes a seguir las actividades y transacciones elementales de la organizacin. El fin es responder a las cuestiones de rutina Sistemas de nivel de conocimiento: la finalidad es ayudar a la empresa de negocios a integrar nuevos conocimientos Sistemas de nivel de conocimiento Sistemas de oficina Sistemas de nivel administrativo: Se disean para las actividades de seguimiento, , toma de decisiones y tareas administrativas de los g gerentes de nivel medio control, Sistemas de nivel estratgico: Ayudan a los directivos a atacar y dirigir cuestiones g , las tendencias a largo g p plazo y en el entorno de la institucin. estratgicas, Tambin se pueden diferenciar por su especialidad funcional
Principales tipos de sistemas Sistemas de procesamiento de transacciones

Sistemas bsicos que sirven al nivel operativo Efecta y registra las transacciones diarias y rutinarias Las tareas, los recursos y las metas estn predefinidos y son altamente es uc u ados estructurados Son importantes productores de informacin para los otros tipos de sistemas Ejemplos: sistemas de fijacin de precios (marketing), contabilidad general (contabilidad) calificaciones (universidad), (contabilidad), (universidad) sistemas de control de calidad (produccin)
TPS
Principales tipos de sistemas Sistemas de trabajo de conocimiento

Sistemas orientados al nivel de conocimiento Dirigidos a profesionales con profesin reconocida Ingenieros, doctores, abogados, arquitectos, etc Posibilitan la creacin de conocimientos nuevos Garantizan que el conocimiento nuevo se integre a la organizacin Ejemplos: j p sistemas de diseo g grfico, , sistemas legales, g , sistemas p para medicina
KWS
Principales tipos de sistemas Sistemas de trabajo de conocimientos

KWS
Principales tipos de sistemas Sistemas de automatizacin de oficinas

Sistemas orientados al nivel de conocimiento Dirigidos a personal que procesan informacin (en vez de crearla) Secretarias, administrativos. Apoyan a las actividades de coordinacin / comunicacin i i S di Se disean para aumentar t lla productividad d ti id d de d este t ti tipo d de empleados l d Ejemplos: sistemas de presentaciones grficas tipo Powerpoint, Powerpoint sistemas de correo electrnico, procesadores de texto.
OAS
Principales tipos de sistemas Sistemas de automatizacin de oficinas

OAS
Principales tipos de sistemas Sistemas de informacin gerencial

Sistemas orientados al nivel de administracin Proporcionan informacin resumida poco flexibles y capacidad analtica reducida Orientados a sucesos internos de la organizacin Resumen y preparan informes acerca de las operaciones bsicas de la compaa Responden a preguntas rutinarias Ejemplos: informes sinpticos y por excepcin, sistemas de planificacin, control de gestin y toma de decisiones
MIS
Principales tipos de sistemas Sistemas de informacin gerencial

MIS MIS
Datos de ventas Costo unitario de productos Datos de modificacin del producto Datos de Gastos Archivos MIS Gerentes
TPS
Sistema de proceso de pedidos Archivo de pedidos Sistema de planificacin de recursos materiales Archivo maestro de Produccin Sistema de contabilidad Archivo de Contabilidad
MIS
INFORMES
Principales tipos de sistemas Sistemas de apoyo a la toma de decisiones

Sistemas orientados al nivel de administracin Ayudan a a la toma de decisiones semiestructuradas, nicas o que cambian rpidamente Pueden contener informacin externa. Se nutren de TPS y MIS Tienen mayor capacidad analtica que los otros sistemas Construidos con modelos para analizar datos Ejemplos: sistemas de simulaciones, simulaciones sistemas de anlisis de datos para la toma de decisiones
DSS
Principales tipos de sistemas Sistemas de apoyo a la toma de decisiones

DSS
Archivo de ventas nacionales (fatura por factura) Archivo de ventas exterior PC
Archivo de compras Base de datos de modelos analticos
Grficos Informes
Archivo vendedores Archivo de regiones
Principales tipos de sistemas Sistemas de apoyo a ejecutivos

Sistemas orientados al nivel superior Utilizados principalmente para la toma de decisiones no rutinarias Pueden ser incorporados datos externos Filtran, comprimen y rastrean datos cruciales Se reducen tiempo y esfuerzo esfuerzo. Software grfico de alto nivel
ESS
Ejemplos: Simulaciones, sistemas de grficos avazados
Principales tipos de sistemas Relacin de integracin entre los sistemas

ESS
Los diversos sistemas de la organizacin se relacionan unos con otros
MIS
DSS
Los ESS son receptores de informacin que provienen de otros sistemas Los TPS son ideales para enviar informacin i f i a otros t sistemas i t
KWS OAS
TPS
Principales tipos de sistemas Las decisiones y los sistemas de Informacin

Operativo Conocimiento Administrativo Estratgico
Estructurada
TPS OAS MIS
Semi Estructurada
DSS
No Estructurada
KWS
ESS
Los participantes
Como analista de Sistemas, usted trabajar con variedad de personas que cambiarn, bi pero los l papeles l que desempeen d cada d uno de d ellos ll sern bastante constantes y se repetirn a lo largo de los proyectos Un analista con xito requiere mucho ms que una simple comprensin de la tecnologa. Se requiere adems de habilidades Interpersonales. Los principales actores son:
Usuarios Administracin Auditores, personas de control de calidad Analistas de Sistemas Diseadores de Sistemas P Programadores d Personal de Operaciones
Los participantes Usuarios

E ell participante Es ti i t ms importante i t t Es aquel para el que se construye el sistema Es la persona a entrevistar para conocer las caractersticas que deber tener el nuevo sistema. El usuario es dueo porque recibe el sistema cuando se termina El usuario es cliente en dos sentidos
El cliente siempre tiene la razn Es el que paga el sistema
Siempre que sea posible, posible el analista debe tomar contacto directo con el usuario. usuario Una buena opcin es que el usuario participe activamente en el proyecto.
Los participantes Administracin

Durante ell ciclo D i l de d vida id del d l proyecto, usted d tomar contacto con diversidad di id d de d administradores:
Ad i i t d Administradores usuarios i : son los l que estn t a cargo del d l rea que implementar i l t ell sistema. i t Administradores de informtica: son los responsables encargados del sistema Administracin general: Son los administradores de nivel superior, son los ms altos responsables de la organizacin. Se interesan mucho ms por los sistemas para la toma de decisiones
La principal interaccin del analista con este grupo de administradores, tiene que ver con los recursos que sern asignados al proyecto. Hay que tener en cuenta que cuanto ms alto nivel ocupen, es menos probable que sepan de la tecnologa. Por ello, hable solo de las caractersticas esenciales del sistema. Las metas y prioridades pueden entrar en conflicto con las de los usuarios. Pueden llegar a imponer algn sistema diferente al que define el usuario.
Los participantes Auditores y Control de Calidad

El objetivo general de este equipo es asegurar que el sistema se desarrolle de acuerdo con estndares o normas internos y y/o externos. Posiblemente tengan en cuenta estndares impuestos por dependencias gubernamentales reguladoras. reguladoras Cuando est trabajando con este grupo de personas, hay tres puntos a prever:
A menudo no se involucran hasta que el proyecto est en la etapa final. A menudo estn familiarizados con formatos o notacin antiguos. antiguos Muchas veces se interesan ms por la forma que por el contenido, por lo que si los documentos no tienen la forma exacta requerida, requerida podrn rechazarlos, rechazarlos
Los participantes Diseadores de Sistemas

Es el q que recibe el resultado del anlisis Debe transformar el p pedido libre de consideraciones de tecnologa, en un diseo de alto nivel que servir para el trabajo de los programadores. En muchos casos, el analista y el diseador pueden ser la misma persona. Pero si son personas diferentes, deben estar en contacto directo hasta que finalice el proyecto
Los participantes
Los participantes Analistas de Sistemas

E ell personaje Es j clave l en ell desarrollo. d ll Es el que tiene la labor de descubrir detalles y documentar la poltica de un negocio. Debe D b ser innovador i d , debe d b distinguir di ti i entre t sntomas, t problemas bl d l del usuario y causas. Debe ser mediador, puesto que muchas veces se encuentra en medio de usuarios y administradores. Debe lograr consenso. Muchas veces es el lder del proyecto. No aprenda solo DFD, aprenda sobre el manejo de personas, negociacin y sea metdico y organizado.
Roles del Analista de Sistemas
Rol que se da con mucha frecuencia, frecuencia para intentar solucionar los problemas de sistemas de una organizacin. Ventaja: tiene una perspectiva fresca e independiente. Desventaja: el consultor externo no conocer cultura ni procedimientos. Como consultor externo, el analista debe apoyarse en los usuarios para entender la cultura desde la p p perspectiva p de ellos.
El analista recurre a su experiencia con el hardware y software Con frecuencia, este tipo de trabajo no implica un proyecto completo de sistemas, sino de pequeas modificaciones. En este rol, el analista no est a cargo del proyecto. A veces implica la toma de decisiones tcnicas sobre el rea bajo estudio. estudio
Es el rol ms completo y de mayor responsabilidad. Un analista es un agente g de cambio si desempea p cualquiera q de las actividades del ciclo de vida del desarrollo de sistemas. Debe estar presente en la empresa por un largo perodo. En este tol, el analista coopera con los dems para producir el cambio. Es comn que el analista deba interactuar con los que deben cambias. usuarios Es tarea del analista ensear el proceso de cambio a los usuarios.
Cualidades del Analista de Sistemas

El analista exitoso debe contar con una amplia gama de cualidades: Debe ser solucionador de problemas. Debe tener la capacidad de afrontar sistemticamente cualquier situacin mediante la correcta aplicacin de herramientas. Debe ser un comunicador con capacidad de relacionarse con los dems. Debe tener tica personal y profesional firme que le ayude para sus relaciones con los clientes. Debe ser una persona autodisciplinada y automotivada, con la capacidad de coordinar los recursos de un proyecto
Segn Pungitore
Tcnicas de entrevistas
Las entrevistas son fundamentales en las etapas de anlisis global y anlisis detallado Una entrevista es una reunin entre dos o ms personas en dnde el encuentro es personal personal, estableciendo un complejo proceso de comunicacin que excede el lenguaje verbal Lenguaje g j corporal p Proceso de Tono de voz comunicacin Contenido Objetivo: recolectar datos del entrevistado bajo distintas formas
Reunin de informacin g general Opiniones o puntos de vista Planteo y clarificacin de inconsistencias
Tcnicas de entrevistas
Usuarios del sistema Generalmente, quin es el entrevistado? Analistas anteriores Proveedores

Rol pasivo: en la apreciacin general de un tema acti o Predominan las preguntas preg ntas Rol activo: Anlisis global: niveles gerenciales y de direccin vinculados al rea bajo estudio Anlisis detallado: niveles operativos y de supervisin
Rol del analista
Entrevista
Clasificacin de entrevistas
Contenido preparado niveles bajos
Estructuradas
El trabajo se invierte en el armado Es simple de evaluar La calidad de la informacin depende del entrevistador Ms difcil de evaluar Cerradas (entrevistas estructuradas)
No estructuradas
Respuestas
Abiertas (no estructuradas) Combinadas
Condiciones en que debe desarrollarse la entrevista

Preparacin de la entrevista Acudir con un esquema armado Obj ti preciso, Objetivo i no perderlo d l d de vista i t Abordar directamente los temas definidos (luego de la presentacin)
Identificar a los entrevistados Anticipar el motivo de la reunin Cantidad C tid d de d personas, no excederse d
Condiciones para desarrollar la entrevista

Desarrollo de la entrevista
No debe parecer un interrogatorio Elegir lugar y hora adecuados Planear la duracin de la entrevista Sintona - empata Crear condiciones para que no se sientan presionados Perfil profesional no mostrar emociones No grabar No tomar apuntes en forma excesiva
Documentacin
Hacer una minuta provisoria y una definitiva Poner expresamente lo que se habl en la reunin
Segn Kendall & Kendall
Tcnicas de Entrevistas
Segn Kendall, una entrevista es una conversacin dirigida con un propsito especfico fi en la l que se utiliza tili un formato f t de d preguntas t y respuestas t TIPS S pa para au una a bue buena ae entrevista: t e sta
Busque opiniones del entrevistado: Estas podran ser ms reveladoras que los hechos Capte los sentimientos del entrevistado: va a poder entender la cultura de la i i de d manera ms completa l t organizacin Releve las metas: revelan el futuro de la organizacin Establezca confianza y entendimiento sin perder el control de la entrevista Planifique la entrevista antes de realizarla
Cinco pasos para preparar una Entrevista

1) Leer los antecedentes
Buscar informacin en sitios Web, informes anuales, boletines corporativos y otras publicaciones. Poner atencin al lenguaje utilizado. Con esto crear un lenguaje comn que le servir para poder formular preguntas. Maximizar el tiempo de la entrevista porque evitar it las l preguntas t generales. l
2) Establecer los objetivos de la entrevista 3) Decidir a quin entrevistar

Incluir a las p personas clave de todos los niveles. Busque q el equilibrio. q
4) Preparar al entrevistado
Hablar por anticipado o enviar un mail para que pueda pensar la entrevista. entrevista Si la entrevista ser muy profunda, se pueden enviar las preguntar por anticipado
5) Decidir el tipo de preguntas y la estructura

Escribir preguntas que abarquen las reas clave
Preguntas Abiertas
Algunas Ventajas
Hacen que el entrevistado est a gusto El entrevistador puede entender el vocabulario Proporcionan gran cantidad de detalles Transforman la entrevista ms interesante Permiten la espontaneidad Son un buen recurso si el entrevistador no est preparado Algunas Desventajas Pueden proporcionar detalles irrelevantes Podra perderse el control de la entrevista Da la impresin de ser un entrevistador no experimentado Las respuestas pueden tomar ms tiempo
Preguntas Cerradas
Algunas Ventajas
Ahorran tiempo p Permite comparar las entrevistas fcilmente Se mantiene el control de la entrevista Consigue datos relevantes Algunas Desventajas Aburren al entrevistado No permiten obtener demasiados detalles No favorecen una relacin cercana entre el entrevistado y el entrevistador
Sondeos
El propsito del sondeo es ir ms all de la respuesta inicial para conseguir mayor significado, clarificar, ampliar la opinin. L sondeos Los d pueden d constar t de d preguntas t abiertas bi t o cerradas. d Algunos ejemplos de preguntas de sondeos:
Por qu? Me lo puede explicar con ms detalle? Muchas veces, los entrevistadores inexpertos no desean usar este tipo de preguntas, t aceptando t d respuestas t superficiales. fi i l
Uso de Cuestionarios y Planificacin

Tcnica de recopilacin de informacin para estudiar actitudes, comportamiento, caractersticas de personas de la organizacin que pueden resultar afectadas por la solucin propuesta. Permiten encuestar a una cantidad considerable de personas, para intentar detectar problemas antes de la realizacin de entrevistas. Es conveniente usar cuestionarios y entrevistas en conjunto, j ,p porque q se complementan. p El desarrollo de cuestionarios implica una considerable cantidad de tiempo de planeacin. Considere el uso de cuestionarios si:
Los entrevistados se encuentran en ubicaciones dispersas Est haciendo un estudio general y desea medir la opinin general antes de determinar el rumbo del proyecto. Se desea tener la certeza de identificar los problemas relacionados.
Redaccin de Preguntas
La principal diferencia entre las preguntas de entrevistas y de cuestionarios, es que las entrevistas permiten la interaccin. En una entrevista, el entrevistador puede refinar una pregunta, definir un trmino confuso, cambiar el rumbo. En cambio, en los cuestionarios no todas estas oportunidades pueden aprovechadas Por ello, ello las preguntas deben ser claras, claras el flujo del ser aprovechadas. cuestionario debe ser convincente, y el cuestionario debe planearse al detalle. Al igual que en las entrevistas, se utilizan preguntas abiertas y cerradas. cerradas
Eleccin del Vocabulario

Las p preguntas g deben reflejar j la p propia p terminologa g del negocio. g Puede ser conveniente tomar algunas preguntas como piloto, para robar su eficacia. Lineamientos para el uso del vocabulario
1. 2. 3. 4. 5. 6. 6 7. 8. Usar el lenguaje de los encuestados siempre que sea posible. Ser especfico en la redaccin (sin exagerar). Hacer preguntas breves No subestimar a los encuestados con preguntas de bajo nivel. Evitar parcialidad en la redaccin Dirigir las preguntas a los entrevistados adecuados Asegurar que los aspectos tcnicos sean precisos Puede ser conveniente utilizar un corrector de ortografa
Uso de escalas
Es asignar nmeros o smbolos a atributos o caractersticas para realizar una medicin. Pueden utilizarse dos tipos de escalas
Escalas Nominales Escalas de Intervalos
Las escalas nominales se utilizan para clasificar cosas. Por ejemplo:

Qu materia te gusta ms?
1. 1 2. 3. Contabilidad C t bilid d Anlisis Matemtico Administracin
Las escalas L l nominales i l son formas f d medicin de di i dbiles. dbil C ellas Con ll solo l se pueden d obtener totales para poder clasificar. En las escalas por intervalos, los intervalos entre cada uno de los nmeros son iguales. Esto permite la realizacin de operaciones matemticas con los datos del cuestionario.
Cun completa es la bibliografa de la biblioteca? Incompleta Muy completa 1 2 3 4 5
Diseo de Cuestionarios
Algunas reglas:
Dejar bastante espacio en blanco Proporcionar suficiente espacio para responder las respuestas Facilitar la marcacin de la respuesta con claridad Mantener un estilo consistente
Estas reglas son vlidas tanto para formulario impresos como para formularios Web C h una manera de d ordenar d id d como la l mejor, j debe d b pensar en los l Como no hay considerada objetivos que persigue con el cuestionario, y luego determinar la funcin que cumple cada pregunta
Colocar primero las preguntas ms importantes para los encuestados Agrupar los elementos de contenido similar Incorporar primero las preguntas menos polmicas
Aplicacin de Cuestionarios
En conjunto, establecer los objetivos y las personas que recibirn el cuestionario S deben Se d b elegir l i suficientes fi i t personas para que se obtenga bt una muestra t razonable bl Existen varias opciones para aplicar el cuestionario
Citar al mismo tiempo a todos los entrevistados Entregar personalmente los formularios en blanco y luego pasar a recogerlos Permitir que los encuestados lo completen en su trabajo y que lo dejen en algn lugar definido Enviar los cuestionarios por correo e indicarles fecha lmite, instrucciones y los sobres para la devolucin Aplicar el cuestionario a travs de un correo electrnico o la web
Existen ventajas y desventajas, desventajas pero es importante decidir qu mtodo usar en funcin al objetivo, entrevistados, etc.. Cuando C d se debe d b garantizar ti la l confidencialidad fid i lid d (o ( anonimato), i t ) puede d ser interesante i t t dejar d j que lo contesten en cuanto deseen y lo dejen en un punto central.
Necesidad de una metodologa
Modelos segmentables en forma descendente
El sistema debe poder mostrarse en forma descendente La idea es poder moverse de una parte a otra del sistema en forma ordenada Si el sistema cambia, debe cambiar el modelo para mantenerse actualizado
Introduccin
Necesidad de una metodologa
Una metodologa es el medio de comunicacin bsico entre integrantes de un equipo afectado al anlisis, desarrollo y mantenimiento de sistemas. Se permite la transmisin de rdenes, recepcin de informacin acerca de la marcha de la tarea, percepcin de estndares de calidad, etc. La metodologa a seleccionar debe ser nica, aceptada y reconocida por los integrantes del equipo de trabajo. Debe ser simple y sencilla y a su vez poderosa para poder atacar con xito cualquier clase de problema que se presente. El no seguir una metodologa traer las siguientes consecuencias No haber comprendido el objetivo y el alcance Haber realizado tareas no necesarias No haber realizado tareas necesarias No estar en condiciones de emitir una opinin adecuadamente fundad en los temas en cuestin
Introduccin Acotamiento del campo de accin

Es indispensable fijar claramente la metodologa a utilizar utilizar, de modo de poder delinear las reas que quedarn comprendidas dentro del trabajo. Hay que determinar claramente: Lmites Alcances reas, misiones y rutinas afectadas Para: Fijar el campo de accin y acotarlo Determinar con precisin las reas de la empresa involucradas Identificar a los usuarios dentro del lmite y cules son de sus tareas las comprendidas en nuestro trabajo Tener presente el motivo por el cual nos encomendaron la tarea
Introduccin
Metodologa para el anlisis, desarrollo, y mantenimiento de sistemas
Conocimiento Construccin Validacin y puesta en marcha Seguimiento
Anlisis de la naturaleza de los cambios a introducir DAM MC Anlisis global Anlisis detallado
Manteni -miento
Prueba Reforma
Implan tacin
Mant. Y control
Nuevo diseo DAMC: Decisin alternativa ms conveniente
La Etapa de Anlisis
Esta es la etapa de:
Conocimiento del sistema vigente Observacin de puntos fuertes y dbiles Necesidades de los usuarios y su grado de satisfaccin respecto de los servicios recibidos Luego, seguir el diagnstico Aplicaremos el enfoque TOP DOWN TOP-DOWN El especial inters se centra en los aspectos que no funcionan bien, o que funcionan por debajo de la medida necesaria
Anlisis Global
Objetivo
Obtener una visin global del sistema que estamos analizando Este objetivo no muere en esta etapa sino que es el marco de referencia para el anlisis detallado
Tareas a desarrollar
Visualizacin del sistema en operacin Entrevistas Familiarizarse con el sistema sistema, con el negocio y con el ambiente empresario Es importante conocer sistemas similares que operen en el mercado Se debe conocer la legislacin vigente Publicaciones especializadas sobre la actividad de la empresa Experiencias de otros profesionales Interiorizarse acerca del software existente
Anlisis Global
C fid i lid d de Confidencialidad d la l informacin i f i recogida id

Se debe ser reservado en cuanto al tratamiento de la informacin recogida evitando la divulgacin voluntaria o involuntaria La informacin solo estar disponible solo a los integrantes del equipo que tengan necesidades laborales
Control peridico del proyecto

na tarea del jefe del pro ecto (control peridico y de recursos) rec rsos) Esta es una proyecto
Resultado
El resultado de la etapa es un informe acerca del grado de avance, tareas realizadas, recursos afectados, inconvenientes Se debe describir globalmente el sistema bajo estudio
Anlisis Detallado
El objetivo de esta subetapa es analizar en detalle el sistema bajo estudio y realizar el diagnstico correspondiente Se parte desde el anlisis global Los analistas deben hacer uso de herramientas y tcnicas especficas para poder lograr el total conocimiento del sistema bajo estudio Es esperable (y deseable) que los analistas adquieran igual o mayor conocimiento que los usuarios
Tareas a desarrollar en el Anlisis Detallado
1 Recolectar las necesidades de los usuarios que no estn siendo satisfechas 1. por el sistema vigente (o necesidades de mejora) 2. Analizar sectores y locaciones fsicas que tengan participacin en el sistema bajo estudio. Tambin analizar la forma en que las necesidades de comunicacin estn siendo satisfechas actualmente 3. Obtener el detalle de la significatividad y del volumen de la informacin a recolectar, y de la actividad de esos sectores que la generan. 4. Relevar el flujo de informacin utilizando herramientas adecuadas
Cursogramas Diagramas de redes DFD, etc
Tareas a desarrollar en el Anlisis Detallado

4. Relevar el diseo y contenido de los formularios involucrados 6. Tener en cuenta los archivos de formularios (que circulan a travs de los distintos sectores que usan la informacin) y los registros (que permanecen sin movimiento capturando detalles del flujo que pasan por all) 7 Practicar el proceso de consistencia en entradas / salidas a detalle, 7. detalle en los sistemas complejos. En el resto, recomendar su cumplimiento 7. Anlisis A li i del d l ambiente bi f i en ell que se desarrollan fsico d ll las l tareas 8. Anlisis del ambiente humano en el q que se desarrollan las tareas 9. Anlisis crtico de la informacin recogida 10. Emisin del diagnstico
Naturaleza de los Cambios a Introducir
No siempre la insatisfaccin de los usuarios deriva en un nuevo diseo Un anlisis de costo / beneficio podra hacer no aconsejable el nuevo diseo Considerando la naturaleza de los cambios a introducir y a la profundidad de los mismos, el cambio puede consistir en:
Mantenimiento del sistema: Cambios leves, pequeas adecuaciones, etc. Reforma del sistema: La estructura bsica no necesita ser modificada, solo se trata de hacerlo ms eficiente Cambio del sistema: Necesidad de un nuevo sistema. Se considera irrecuperable la estructura del sistema, sistema ya que no da respuesta a los objetivos originales, originales o stos han sido ampliados o reemplazados por otros, los que obviamente no fueron tenidos en cuenta al momento del diseo
Mantenimiento
Se podra sugerir mantenimiento en las siguientes situaciones: El sistema fue descuidado en un tiempo p en el q que se p produjeron j cambios que afectaron su forma, y al haberse acumulado, implica una traba para la eficacia operativa Se produjeron cambios en la legislacin vigente, y cambi la forma en que han de presentarse y documentarse las transacciones El sistema necesitaba mantenimientos p peridicos y estos no se han realizado
Reforma
Se p podra sugerir g reforma en las siguientes g situaciones:
Los cambios a introducir no afectan ni a la estructura ni a las definiciones bsicas, sino a aspectos secundarios Se observa ineficiencia en la operatoria del sistema, pese a cumplirse los objetivos originales No est claramente definido el sentido de algunas funciones y/o controles, o la naturaleza no es de conocimiento del personal que lo opera S observa b d ilf d recursos y falta f lt de d racionalidad i lid d de d uso Se despilfarro de Se intenta realizar un nuevo diseo, pero para evitar resistencia en la empresa, se hace a travs de reformas sucesivas Las entradas y salidas estn OK, pero es conveniente cambiar los mtodos utilizados para el p p procesamiento de la informacin
Nuevo Diseo
Se podra sugerir Nuevo Diseo en las siguientes situaciones:

En funcin E f i all tiempo ti t transcurrido, id ell sistema i t qued d desvirtuado. d i t d Los L objetivos bj ti iniciales ya no estn vigentes o fueron desplazados por otros Se produjeron cambios en los mtodos de procesamiento que afectan a las rutinas administrativas, controles internos, etc., resultando necesario definir nuevos roles y responsabilidades p Se est ante un tpico caso de reforma, pero debido a problemas de falta de documentacin, mala calidad de la documentacin, o falta de actualizacin de la documentacin, se deriva inevitablemente en un caso de nuevo diseo
Ventajas y desventajas de cada alternativa
Ventajas de una reforma sobre un nuevo diseo:

Generalmente no es tan costosa como un nuevo diseo Se atempera la resistencia al cambio Se puede llegar a implantar en perodos muy cortos
Desventajas de una reforma sobre un nuevo diseo:

Como generalmente constituye una solucin fcil al problema, existe una tendencia sus virtudes t d i a sobrestimar b ti it d En algunos casos no constituye la solucin final a un problema, sino un calmante momentneo
La Construccin Global
Caractersticas Generales:
E la Es l etapa t creativa ti En ella se planifica como va a ser realizado el sistema costos personal necesario, necesario tiempos y plazos de ejecucin y se Se calcularn costos, determinar la naturaleza de los cambios a introducir en:
La estructura El personal Equipamiento y oficinas Superficie de oficinas Hardware y Software C Comunicaciones i i
Objetivo:
Obtencin de la propuesta global de la solucin al problema que nos aqueja
Tareas a realizar:
Preparacin de la propuesta de la solucin: Preparar la alternativa propuesta un estudio de desarrollo global conteniendo principalmente: Costo de los especialistas afectados al proyecto Posible vida til de la solucin propuesta Comparacin de costos respecto del sistema vigente (cambios de personal hardware, personal, hardware software, software comunicaciones, comunicaciones etc) etc )
Tareas a realizar:
Ponderacin de objetivos mltiples: Evaluar comparativamente las propuestas ponderando cada uno de los tems. Con el objeto de ponderar objetivos mltiples, se recomienda:
A i Asignar puntajes t j altos lt a los l aspectos t importantes, i t t y bajos b j a los l no importantes. i t t Asignar puntajes altamente negativos a los tems que no cumplan con especificaciones imprescindibles. Las desventajas tolerables no deben tener puntajes descalificadotes Esquema propuesto:
30: 3: - 3: - 1000: aspectos crticos resueltos satisfactoriamente aspectos no crticos resueltos satisfactoriamente aspectos no crticos no resueltos satisfactoriamente aspectos no resueltos t crticos ti lt satisfactoriamente ti f t i t
Nos aseguramos que toda propuesta con aspectos crticos no resueltos tenga puntaje negativo.
Aprobacin de los usuarios: El usuario debe aprobar la alternativa elegida. Esta sub-etapa es de
importancia estratgica, ya que en ella se definen el perfil y las caractersticas del cambio
Tareas a realizar en caso de mantenimiento

Precisar el objetivo a lograr y tareas a realizar, indicando plazo de ejecucin Mostrar al usuario la solucin propuesta y obtener su aprobacin explcita Ejecutar la tarea en tiempo y forma Ejecutar las etapas de prueba e implantacin. La profundidad de esta tarea estar en funcin a la extensin de los cambios introducidos Obtener aprobacin final de la tarea ejecutada. El usuario debe manifestar total conformidad con el trabajo realizado. Ventajas
El usuario se asegurar que la tarea est bien realizada antes de firmar Quedar documentada la naturaleza del trabajo, el tiempo insumido por el especialista que realiza el mantenimiento Fecha de finalizacin de la tarea Se evita la friccin entre las partes
Tareas a realizar en caso de reforma

Explicitar p el objetivo j a lograr g y tareas a realizar, , indicando p plazo de ejecucin j Mostrar al usuario la solucin propuesta y obtener su aprobacin explcita Ejecutar la tarea en tiempo y forma. Esto puede consistir en: 1. Reformar las salidas (ABM) Campos, cuestiones estticas o de distribucin de informacin en listados y / o pantallas, cantidad de copias y/o destinatarios, frecuencias de emisin / recepcin por parte de los usuarios Reformar las entradas (ABM): Campos contenidos, sectores que emiten la informacin, frecuencias de emisin / recepcin para su procesamiento Reformar el almacenamiento de la informacin: toda reforma debe apuntar a que la recuperacin sea fcil, econmica y aportante. Algunas de las tareas pueden ser:
2. 3.
Tareas a realizar en caso de reforma

4. Reformar los p procesos en los q que no interviene el computador p
Introducir cambios en rutinas de oficina, alternado flujos de informacin para lograr eficiencia Introduciendo cambios en los mtodos, sugiriendo cambios en los computadores por ejemplo
5.
Reformar los procesos en los que interviene el computador

Cambios en el software para adaptarlo a cambios en entradas / salidas y almacenamiento Modificaciones que impliquen mayor eficiencia en el procesamiento, ganando comodidad y reduciendo tiempos de proceso
6.
Reformar la estructura organizativa: seguramente estos cambios sern poco profundos y consistirn en:
Cambios en la denominacin de las tareas Agrupamiento o segregacin de sectores Redefinicin de algunas funciones de algunos sectores
Tareas a realizar en caso de nuevo diseo

La magnitud y profundidad de los cambios a introducir hacen sumamente necesaria la planificacin de actividades y de los recursos a afectar p Parte del sistema en que no interviene el computador
Determinacin de una nueva estructura, estructura de los puestos de trabajo y del personal que los efectuar Redaccin de manuales y normas administrativas Diseo de los formularios que intervendrn Ajuste final con la parte del sistema en que si interviene el
Parte del sistema en que interviene el computador. Las tareas se realizan en el orden siguiente:
Diseo de los diagramas de entidad relacin Diseo de los diagramas de flujo relativos a los procesos definidos Diseo de los archivos que intervienen en el proceso Programacin Prueba de los programas

Tareas independientes de la participacin del computador
Provisin del hardware, software, muebles, tiles, instalaciones, etc. Reclutamiento y/o capacitacin del personal afectado TI tiene la responsabilidad del seguimiento y control de estas tareas
Consideraciones C id i acerca de d la l provisin i i de d hardware. h d El equipamiento i i t necesario i puede d ser obtenido segn las siguientes modalidades:
Compra Alquiler con opcin a compra (leasing) Alquiler (muy til ante incidentes que requieren un equipo urgente) Uso compartido del computador: generalmente lo hacen empresas de un mismo grupo Service: un tercero que ejecuta en equipos de su propiedad: ideal para empresas pequeas

Consideraciones acerca de la provisin de software. Puede ser obtenido segn las siguientes modalidades: Desarrollo a medida: diseos especficos y el desarrollo puede ser interno o externo. Tiene la gran ventaja de que el sistema estar en un todo de acuerdo con las necesidades de la empresa
A veces contratar personal externo para el desarrollo puede contener la intencin de transferencia de tecnologa al personal interno Se debe conocer muy bien que es lo que estamos adquiriendo: propiedad total del desarrollo, desarrollo propiedad de uso y modificacin, o cesin de uso.
Software pre-planeado: software que generalmente tiene ciertas funciones muy bien desarrolladas y puede ser adaptado a necesidades particulares con relativa sencillez. La adopcin de esta modalidad puede reducir en un 50% las tareas necesarias para llegar a la total utilizacin, debido a que:
Se eliminan tareas de programacin Los principales problemas tcnicos fueron resueltos por el proveedor a travs de la experiencia E experiencia i i reduce d d prueba b e implantacin i l i Esa costos de Generalmente la contratacin de pre-planeados implica solo la cesin de uso no exclusiva

Software enlatado: generalmente no permite adaptaciones y se utiliza en el estado en que est. est
Su precio es bastante ms econmico, y tiene mucho xito en empresas medianas y chicas La puesta en marcha es mucho ms rpida que en las otras dos modalidades
Ventajas y desventajas de cada modalidad

Variable Precio Posibilidad de adaptaciones a medida Entrega de documentacin del sistema Oportunidades en el que el sistema fue probado Puesta en marcha Desarrollo a medida El ms alto Es a medida Generalmente se entrega y puede ser necesario un pago adicional Nunca fue probado lenta Pre-planeado p Precio intermedio Se pueden realizar Se entrega en forma opcional debiendo ser opcional, necesario pagar un adicional Las partes comunes ya fueron probadas media Enlatado El ms bajo Generalmente no contempla esta posibilidad No se entrega
El software se encuentra muy probado Rpida
La Prueba
Objetivos anteriores a la puesta en marcha Probar el sistema Realizar los ltimos ajustes Se debe procesar un caso de prueba completo para asegurarnos:
del correcto funcionamiento del software acople de las partes en los que si interviene, y en los que no interviene el computador adecuada capacitacin de los usuarios terminacin y ajuste de los manuales de operacin y de procedimientos administrativos
Existe un concepto que dice que la prueba debe desarrollarse en condiciones ptimas de fracaso, quiere decir que el analista no debe estar presente en el momento de realizacin de la prueba, para evitar influir en el desarrollo de la misma
La Prueba
Tareas a desarrollar: Preparacin de un caso de prueba entre el analista y el usuario en conjunto. Que contenga la mayor cantidad de alternativas posibles. Este caso de prueba debe ser severo Procesar el caso de prueba simulando situaciones cercanas a la realidad. Se debe hacer fluir la informacin por todos los sectores que intervendrn en la operatoria. Analizar los resultados efectivos en funcin a los resultados tericos esperados. En caso que surjan errores, se harn las correcciones en:
Manuales de operacin Manuales de procedimientos administrativos Programas Diseos de archivos Formularios intervinientes, etc..
Se recomienda que el paso anterior se ejecutado cada vez que se encuentren errores, para evitar que la correccin de un error, no provoque nuevos errores.
La Implantacin
Objetivos y comentarios generales: El objetivo es poner el equipo en marcha Para que esta etapa funcione, todas las etapas anteriores deben haber funcionado El producto final es la consecuencia de la correcta realizacin de todas las tareas que componen la metodologa. Tareas a desarrollar: Previsin de los recursos necesarios para el sistema: Sistemas debe controlar que los responsables de obtener los citados recursos lo hayan hecho en tiempo y forma Conversin y/o preparacin de los archivos necesarios para comenzar con el funcionamiento en forma regular del nuevo sistema
La conversin de archivos (en un sistema que reemplaza a uno existente) La preparacin de archivos (en un sistema que arranca por primera vez sin precedentes)
La Implantacin
Ejecucin del sistema en paralelo
El sistema vigente y el sistema a implementar coexisten durante un lapso de tiempo, tiempo de forma tal de asegurarnos que el sistema cumpla con todas las exigencias Este proceso proporciona seguridad pero por otro lado, mientras dure el paralelo, las tareas administrativas se vern resentidas La gran ventaja es que se pueden analizar los resultados de ambos sistemas con un mismo lote de datos Este proceso debe ser seguido de cerca por los analistas, quienes deben colaborar en todo momento con los usuarios
Implantacin de un sistema en unidades regionales

La introduccin de un sistema que afectar a varias regiones, presenta un esquema especial. Es conveniente concentrar todos los esfuerzos de instalacin en una nica unidad, para que posteriormente sus resultados sean traspasados a todas las restantes. Algunas personas sugieren Al i que la l unidad id d a seleccionar l i no sea de d las l ms representativas t ti para la organizacin. De este modo, de existir problemas, sern de menor impacto.
La Implantacin
Comentarios adicionales: En el momento de la implantacin es cuando pueden surgir las mayores dificultades. En esos momentos reina el nerviosismo y la intranquilidad. Es importante entonces que exista un alto espritu de cooperacin. Aspectos que facilitarn la implantacin:
El computador debe ser alejado en un sitio tranquilo y solo accesible a las personas que lo operarn. Las conexiones y el tendido de cables debern hacerse de manera prolija. Realizar una adecuada disposicin de las oficinas p Los servicios relacionados con el computador y con las personas que trabajan en l, merecern especial cuidado. Servicios especiales para las personas: luz, agua, calefaccin, refrigeracin, Servicios especiales para el computador: energa elctrica, refrigeracin, detectores de humo y calor Capacitacin adecuada a usuarios
Diagramas Entidad - Relacin
Los diagramas de entidad relacin, son una herramienta de modelado de datos, para documentarlos. Presentaremos al modelado de datos como una tcnica para definir los requerimientos del negocio de una base de datos.
CLIENTE Primary Key "Numero de cliente" [PK1] Non-Key Attributes "Nombre del cliente" "Direccion de envio" "Direccion Direccion de la facturacion" facturacion "Saldo deudor"
ha colocado
ORDEN Primary Key "Nunmero de orden" [PK1] Non-Key Attributes "Fecha de la orden" "C t total "Costo t t l de d la l orden" d " "Numero de cliente"
Entidades
Los datos describen cosas. Entonces necesitamos un concepto que represente en forma abstracta todas las instancias de un grupo de cosas semejantes. Ese concepto es el que llamaremos ENTIDAD. Una entidad es algo g acerca de lo cual el negocio g necesita almacenar datos. Segn el libro de Bentley, la entidad se representar por medio de un rectngulo con bordes redondeados. Una INSTANCIA de entidad, es una ocurrencia individual de una entidad. Por ejemplo, la entidad estudiante, tiene instancias mltiples, Jos Perez, Alberto Gmez. En el modelado de datos no nos preocupamos por las instancias, lo hacemos por las entidades. id d
CLIENTE
Atributos
Los ATRIBUTOS son los datos especficos que queremos almacenar acerca de una entidad. Dentro del dibujo de una entidad, entidad los atributos se colocan debajo del nombre de la entidad. Algunos atributos pueden agruparse lgicamente en superatributos, llamados ATRIBUTOS COMPUESTOS. Por ejemplo, el nombre de un estudiante puede d ser un atributo ib compuesto que consta de Apellido Paterno, Apellido Materno, Nombres. Segn este libro, a cada atributo simple que depende de uno compuesto, se le coloca un punto adelante.
CLIENTE Primary Key "N "Numero d de cliente" li t " [PK1] Non-Key Attributes "Nombre del cliente" "Direccion de envio" "Direccion de la facturacion" "Saldo deudor"
Atributos
Cuando analizamos un sistema, debemos definir para un atributo, aquellos valores que consideramos legtimos o que tienen sentido para el negocio. negocio Entoces los valores para un atributo se definen mediante tres propiedades: DATOS DOMINIO Y POR OMISIN. DATOS,
TIPO DE
El TIPO DE DATOS define la clase de datos que pueden guardarse en ese atributo.
Tipo de Dato Lgico Nmero Texto Memo Fecha Tiempo Si / No C j t de Conjunto d valores l Imagen Significado lgico de Negocios Cualquier nmero real o entero Cadena de caracteres (incluye nmeros) Similar al texto, pero con tamao indeterminado q fecha con cualquier q formato Cualquier Cualquier hora con cualquier formato Atributo que puede adoptar solo alguno de estos dos valores C j t finito Conjunto fi it de d valores l (ejemplo ( j l esquemas d de cdigos) di ) Cualquier ilustracin o imagen
Dominios de los Atributos

El DOMINIO define los valores que puede adoptar el atributo.
Ti de Tipo d Dato D t L Lgico i Nmero T t Texto Memo Fecha Tiempo Si / No Conjunto de valores D i i Dominio Para los enteros, especificar rango Para los reales especificar rango y precisin T Tamao mximo i d dell atributo t ib t No aplicable Variacin del Formato MMDDYYYY Para horarios AM/PM Para horarios militares Si/No {valor1, valor2, valor3} Tabla de cdigos y significados Ej Ejemplo l {10 99} {10,00 999.999,99} TEXTO (30) No aplicable DDMMYYYY MMYYY HHMMT HHMM {si / no} {on / off} {abierto, cerrado, pendiente} A = abierto C = Cerrado C d P = Pendiente No aplicable
Imagen
No aplicable
El VALOR POR OMISIN representa el valor que adopta el atributo si no es especificado por el usuario
Identificacin
Como una entidad tiene muchas instancias, se deben poder identificarlas de forma nica. Por ello, una entidad debe tener una CLAVE. Cuando para identificar las instancias se necesita un grupo de atributos, se llama CLAVE CONCATENADA. Un atributo puede tener ms de una clave. Entonces cada una de estas claves puede convertirse primaria. Se llaman CLAVES CANDIDATAS. en clave p La CLAVE PRIMARIA es la clave candidata que ms comnmente se utiliza para identificar de manera nica a la infancia. El valor por omisin de una clave primaria, siempre debe ser NOT NULL. Las claves candidatas que no estn seleccionadas para convertirse en primarias, se llaman CLAVES ALTERNAS. Tambin se llaman CLAVES SECUNDARIAS Todos los atributos que no son parte de la clave primaria se llaman ATRIBUTOS SIN CLAVE. Si necesitamos identificar un subconjunto de instancias, debemos elegir un CRITERIO DE SUBCONJUNTOS. A veces, esto se llama ENTRADA INVERSA.
Relaciones
Entidades y atributos no existen en forma aislada. Interactan entre si p para soportar p la misin del negocio. Una RELACIN es una asociacin natural de negocios que existe entre una o ms entidades. E t relacin Esta l i puede d representar t una evento t que enlaza l entidades tid d o una afinidad fi id d lgica. l i Ejemplos: Ej l
Un estudiante se registra en uno o ms planes de estudios Un plan de estudios est siendo estudiado por cero, cero uno o ms estudiantes
Las expresiones subrayadas definen las relaciones de negocios que existen entre las dos entidades.
Estudiante est inscripto en est siendo atendido por Plan de estudios
Todas las relaciones son implcitamente bi-direccionales, por lo que pueden interpretarse en ambas direcciones.
Cardinalidad
La CARDINALIDAD define los nmeros mnimo y mximo de ocurrencias de una entidad que pueden relacionarse con una ocurrencia individual de la otra entidad. La cardinalidad debe definirse en ambas direcciones para cada relacin
Interpretacin de la cardinalidad Instancias mnimas 1 Instancias mximas 1 Notacin grfica
Exactamente uno (uno y solo uno)
Cero o uno
Uno o ms
Muchos
Cero, uno o ms
Muchos
M d Ms de uno
>1 1
>1 1
Grado
El GRADO de una relacin es el nmero de entidades que participan en la relacin. Las relaciones BINARIAS contienen a dos entidades que participan en la relacin. Pueden existir relaciones entre las diferentes instancias de la misma entidad. Esta relacin se denomina RECURSIVA.
Curso Non-Key Attributes "Identificacion del curso" ". Abreviatura de la materia" ". Numero del curso" "Titulo del curso" "Creditos del curso"
es un prerrquisito de
tiene un prerrequisito
Tambin pueden existir relaciones entre ms de dos diferentes Estas son las relaciones de orden N. entidades diferentes. Para ello se debe construir una nueva entidad. Esta entidad se denomina ENTIDAD ASOCIATIVA y hereda su clave primaria de ms de una entidad diferente (llamadas padres). Cada parte de esa clave concatenada seala a una y solo una instancia de cada una de las entidades conectadas.
Claves Forneas
Una relacin significa que las instancias de una entidad se relacionan con las instancias de otra entidad. Una CLAVE FORNEA es una clave primaria de una entidad que se duplic en otra entidad para identificar las instancias de una relacin. Una clave fornea en una entidad hijo siempre responde a una clave primaria en la entidad padre. Esto quiere decir que la clave primaria siempre es aportada del padre al hijo. Por otro lado, las claves forneas nunca son originadas del hijo al padre.
Departamento Primary Key "Numero de departamento" [PK1] Non-Key Attributes "Nombre Nombre de departamento" departamento
ofrece
Entidad Padre
Plan de estudios Primary Key "Codigo de programa de estudio" [PK1] Non-Key Attributes "Titulo del programa" "Numero de departamento" [FK]
La cardinalidad mxima de departamento es 1. L cardinalidad La di lid d mxima i d de Plan Pl de d estudios t di es muchos. En este caso, la entidad padre es departamento y la hijo es plan de estudios. Ahora, una instancia de plan de estudios ahora tiene una clave fornea nmero de departamento, cuyo valor seala la instancia de departamento que ofrece ese plan de estudios.
Entidad HIjo
Claves Forneas
En el ejemplo anterior la relacin se denomina SIN IDENTIFICACIN porque cada una de las propia p clave p primaria independiente. p entidades tiene su p Esto quiere decir que ningn atributo de la clave primaria es compartido. Otras veces la clave fornea puede participar como parte de la clave primaria de la entidad hijo. hijo
En este caso, para identificar cada instancia de sala, uso el nmero de edificio y el nmero de sala.
EDIFICIO Primary Key "Numero de edificio" [PK1] contiene SALA Primary Key "Numero de sala" [PK1] "N "Numero d de edificio" difi i " [PK2] [FK] Non-Key Attributes "Descripcion de la sala"
Esta
una IDENTIFICACIN.
es
RELACIN
DE
Entidad Padre
Entidad HIjo
En estos casos, la entidad hijo se llama ENTIDAD DBIL porque su identificacin depende de la existencia de la entidad padre.
Claves Forneas
Entidad Fuerte
PASAJERO Primary Key "Identificacion del pasajero" [PK1] Non-Key Attributes "Nombre del pasajero"
Entidad Fuerte
VUELO Primary Key "Numero de vuelo" [PK1] Non-Key Attributes "Fecha de salida del vuelo"
Esta simbologa es la que se utiliza en el software SYSTEM ARCHITECT. La lnea segmentada identifica a las relaciones sin identificacin. La lnea continua se usa para las relaciones de identificacin. Como la asignacin de asientos es una entidad dbil (porque recibe la clave primaria para componer p su p propia p clave de vuelo p primaria). La entidad dbil se representa por un rectngulo de bordes redondeados dentro de otro rectngulo redondeado.
contiene
Relaciones sin Identificacin
ASIGNACION DE ASIENTOS Pi Primary K Key "Identificacin del asiento" [PK1] "Numero de vuelo" [PK2] [FK] Non-Key Non Key Attributes "Identificacion del pasajero" [FK]
tiene
Relaciones de Identificacin
Entidad Dbil
Relaciones
A veces no se p puede diferenciar entre p padre e hijo. j En el ejemplo j p siguiente, g , se ve q que un p plan p puede contener cero, uno o ms estudiantes, pero al mismo tiempo un estudiante se puede inscribir en uno o ms planes de estudio. Esta es una relacin de muchos. Esta es una RELACIN NO ESPECFICA. Estas relaciones solo son adecuadas para los modelos preliminares, por lo que deben resolverse lo antes posible.
ESTUDIANTE Primary Key "Numero de estudiante" [PK1] Non-Key Attributes Nombre Direccion Telefono "Fecha de nacimiento" Sexo Raza "Promedio General"
est inscripto en
PLAN DE ESTUDIOS Primary Key "Codigo de programa de estudios" [PK1] Non-Key Attributes "Titulo del programa" "Tipo de grado"
Muchas relaciones no especficas pueden resolverse en un par de relaciones de uno a muchos.
Relaciones
ESTUDIANTE Primary Key "Numero de estudiante" [PK1] Non-Key Attributes Nombre Direccion Telefono "Fecha de nacimiento" Sexo Raza "Promedio General"
ESPECIALIDAD Primary Key "Numero de estudiante" [PK1] ha declarado [FK] "Codigo de programa de [PK2] ] [FK] [ ] estudios" [ Non-Key Attributes "Identificacin de la especialidad"
tiene
PLAN DE ESTUDIOS Primary Key "Codigo de programa de estudios" [PK1] Non-Key Attributes "Titulo del programa" "Tipo de grado"
Las entidades estudiante y p plan de estudios se convirtieron en p padre. Se ha creado una entidad nueva, asociativa, que es hija de las otras. Para las entidades asociativas, la cardinalidad del hijo al padre es solo y solo uno. La cardinalidad de padre a hijo depende de la regla de negocios. Las entidades asociativas heredan las claves primarias de los padres, por ello siempre son dbiles.
Generalizacin
La GENERALIZACIN .es una tcnica a travs de la cual los atributos que son comunes para varias entidades, se agrupan en una nueva entidad, llamada SUPERTIPO. Por ejemplo, una universidad ingresa estudiantes y contrata empleados. Existen varios atributos comunes, como nombre DNI, nombre, DNI sexo, sexo fecha de nacimiento, nacimiento etc. etc Entonces esos atributos comunes se ponen en una nueva entidad, llamada por ejemplo persona (entidad supertipo). Entonces, las entidades supertipos contendrn aquellos atributos comunes a todas las entidades subtipos. Un SUBTIPO es una entidad cuyas instancias heredan algunos atributos comunes y luego suma atributos propios y nicos de esa entidad. En nuestro ejemplo, un atributo comn a estudiante puede ser cantidad de materias aprobadas, que no aplica a empleado. La herencia nos sirve para reducir el nmero de atributos mediante el uso compartido. Adems de heredar los atributos, los subtipos tambin heredan las relaciones con otras entidades.
Generalizacin
Estudiante y Empleado heredarn los atributos d persona de Estudiante y Empleado heredarn tambin la relacin entre t persona y direccin di i
Una entidad puede ser supertipo y subtipo a la vez
Estas entidades heredan los atributos de persona y estudiante
Esta relacin con contrato no aplica a los estudiantes
Solo un ex alumno puede relacionarse con Grado Todas las entidades subtipo son dbiles
El proceso del modelado lgico de datos
Los modelos de datos son progresivos. No hay un modelo de datos final para un negocio o aplicacin. Un modelo de datos debe considerarse como un documento vivo que cambiar como respuesta a un negocio cambiante. E ideal id l que los l modelos d l de d datos d t se almacenen l it i Es en un repositorio a fin que puedan recuperarse, expandirse y editarse con el paso del tiempo. tiempo

EL MODELADO ESTRATGICO DE DATOS: DATOS:
Un proyecto debe generar un plan estratgico de sistemas de informacin que define una vista global y la arquitectura de los sistemas. Casi siempre, la arquitectura de los sistemas incluye un modelo de datos de la empresa. Este modelo identifica solo lo fundamental de las entidades. Estas entidades p por lo g general estn definidas pero no descriptas en trminos de claves o atributos. El modelo de datos de la empresa puede incluir (o no) a las relaciones. Si se incluyen las relaciones, muchas de ellas no sern especficas. Tambin p parte de la estrategia g del p plan de informacin identifica los p proyectos y de desarrollo de aplicaciones p y los prioriza de acuerdo con criterios propios de la empresa. A medida que los proyectos comienzan, los subconjuntos apropiados de la arquitectura de sistemas, incluyendo un subconjunto de modelo de datos, datos se suministran al equipo de desarrollo como un conjunto de partida.

EL MODELADO DE DATOS DURANTE EL ANLISIS DE SISTEMAS: SISTEMAS:
El modelado lgico de datos generalmente se llama modelo de datos para la aplicacin. No siempre ocurre que el modelado de datos se asocie con la fase de anlisis (esto es lamentable). L modelos Los d l de d datos d t son superiores i a otros t diagramas di por lo l siguiente: i i t
1. 2. 3. 4. Ayudan a los analistas a identificar rpidamente el vocabulario de negocios Casi siempre se construyen ms rpidamente que los modelos de procesos Pueden llegar a caber en una sola hoja de papel Los modeladores de procesos suelen enredarse en detalles innecesarios
El modelos en la fase de anlisis solo incluye entidades y relaciones, relaciones pero ningn atributo. atributo Esto recibe el nombre de modelo de datos de contexto.

EL MODELADO DE DATOS DURANTE EL ANLISIS DE SISTEMAS: SISTEMAS:
El anlisis de requerimientos debe concluir en un modelo lgico de datos que se desarrolla en etapas:
1. 2 2. Primero se construye el modelo de datos de contexto para establecer el alcance del proyecto Luego se desarrolla un modelo basado en claves. claves Se eliminan las relaciones no especficas, especficas se agregan entidades asociativas y se incluyen claves primarias y alternas. Incluir las cardinalidades y las jerarquas de generalizacin. Se construye el modelo integral de datos, que incluir todos los atributos descriptivos El modelo de datos terminado se analiza con respecto a la adaptabilidad y flexibilidad a travs de un proceso llamado normalizacin. normalizacin El modelo final se llama modelo normalizado de datos.
3. 4.
El modelo lgico se transformar luego en un modelo fsico de datos, que es el esquema de base de datos. Este modelo reflejar las limitaciones y capacidades de la tecnologa de base de datos elegida.

HERRAMIENTAS AUTOMATIZADAS PARA EL MODELADO DE DATOS: DATOS:
El modelo de datos est formado por un metadata, que es la informacin acerca de los datos del negocio. Las tecnologas CASE proveen el repositorio para almacenar el modelo de datos y sus descripciones detalladas. Estas herramientas evitan el trabajo de dibujar y mantener estos modelos. d l Al usar un producto CASA, se pueden crear modelos profesionales, sin el uso de papel y lpiz. varios Los modelos pueden ser modificados fcilmente para reflejar correcciones y cambios varios. Se pueden comprobar errores de integridad y consistencia. Algunas herramientas CASE soportan la ingeniera inversa, traduciendo el modelo fsico en lgico. Obviamente se puede generar un modelo fsico a partir de un modelo lgico. De todos modos, algunas herramientas CASE no soportan todas las convenciones de modelado, adoptando nociones ligeramente diferentes.
Cmo construir modelos de datos

1) DESCUBRIMIENTO DE LAS ENTIDADES: ENTIDADES:
Es la primer tareas, y es considerada como relativamente fcil. Se necesita descubrir las entidades fundamentales del sistema. sistema Pueden ser utilizadas varias tcnicas:
Durante las entrevistas, prestar atencin a las palabras clave. Durante las entrevistas, pedir a los dueos del sistema y a los usuarios que identifiquen cosas acerca de las cuales les gustaran capturar, almacenar y producir informacin. formularios archivos e informes existentes. existentes Tambin se pueden estudiar formularios, En los documentos, buscar los sustantivos. Cada sustantivo es una entidad potencial, o en su defecto un posible atributo.
Una vez elegidas las entidades, es importante pedir a algn usuario que le diga la cantidad de instancias de cada entidad. Una entidad verdadera tiene mltiples instancias. Sino, la entidad no existe. existe Los nombres deben ser en sustantivos singular
2) EL MODELO DE DATOS DE CONTEXTO CONTEXTO: :

Debe incluir las entidades fundamentales del negocio g Tambin debe incluir las relaciones naturales Las relaciones deben nombrarse con expresiones que cuando se combinen con los nombres de entidad, formen oraciones simples de negocios Algunas herramientas CASE permiten nombrar a las relaciones en ambas direcciones. De lo contrario se deben nombrar las relaciones de padre a hijo. Una vez que se van mapeando los atributos, podrn aparecer nuevas relaciones y entidades.

Una orden, muchas transacciones posibles (nueva orden, orden cancelada, orden cambiada, cambiada etc etc.) )
U promocin Una i genera muchas rdenes. El cero es porque una orden puede ser generada directa por un miembro) directa
Un miembro puede no haber hecho ninguna transaccin
Un prod producto cto p puede ede o no estar presente en una promocin

3) EL MODELO DE DATOS BASADO EN CLAVES: CLAVES:
Ahora debemos identificar las claves de cada entidad
1. 2. 3. El valor de una clave no deber cambiar durante la duracin de la vida de una instancia. El valor de una clave no puede ser nulo. Deben instalarse controles para asegurar que el valor de una clave es vlido
Bentley sugiere los siguientes lineamientos para crear un esquema de cdigo de l claves:
Los cdigos debieran ser extensibles para permitir el crecimiento El cdigo completo debe dar como resultado un valor nico para cada instancia. Los cdigos deben ser lo suficientemente grande como para describir las caractersticas distintivas pero no demasiado, para que puedan ser interpretados por una persona sin computadora. Una instancia nueva deber ser fcil de crear

Muchas entidades tienen una clave primaria simple, de un solo atributo
Se resolvi la relacin no especfica entre orden y producto, introduciendo una entidad asociativa
Tambin se resolvi esta relacin l i no especfica fi
Importante: si no puede definir las claves para una entidad, puede ser que realmente la entidad no exista Importante: Si dos o ms entidades tienen claves idnticas, seguro son la misma entidad

4) LAS JERARQUAS GENERALIZADAS GENERALIZADAS: :
System Architect dibuja una lnea punteada alrededor de la jerarqua de generalizacin Subtipos heredan claves de supertipos
La relacin se desconect de producto para ser conectada a un supbitpo y se cre una entidad asociativa

5) EL MODELO INTEGRAL DE DATOS: DATOS:
Ahora se deben identificar los atributos restantes. Si existe un modelos de datos de la empresa, seguramente algunos atributos ya hayan sido identificados y registrado en un repositorio. Lineamientos:
Algunas organizaciones tienen estndares para asignar nombres y abreviaciones Escoger cuidadosamente los nombres de los atributos. Como un proyecto no est aislado de otros, los nombres de los atributos deben poder diferenciarse entre proyectos. proyectos Cada atributo debe mapearse a una sola entiadd.
Diccionario de datos
Es un listado organizado de todos los datos pertinentes del sistema. sistema Posee definiciones rigurosas y Precisas, para que usuarios y analistas tengan un entendimiento comn de todas las entradas, salidas, archivos y clculos intermedios. Una razn importante para mantener un diccionario de datos, es mantenerlos ordenados. El diccionario de datos ideal es automatizado, interactivo, en lnea y evolutivo. Cada C d vez que ell analista li t va descubriendo d b i d cosas nuevas, se van agregando d all diccionario de datos. El diccionario no es un fin en si mismo.
Diccionario de Datos
El Diccionario de datos define los datos haciendo lo siguiente:

Describe el significado de los flujos y archivos que se muestran en los DFD. Describe D ib la l composicin i i de d los l datos d t que se mueven a lo l largo l d los de l flujos. Describe la composicin de los paquetes de datos que estn en los archivos. Describe los detalles de las relaciones entre archivos, que se enfatizan en los diagramas de entidad entidad-relacin relacin.
Los diccionarios de datos automatizados (por ejemplo los que forman parte de las herramientas CASE) son valiosos porque permiten hacer referencias cruzadas de los datos y el lugar que p g en q se utilizan. Si fuera necesario hacer cambios, estos diccionarios de datos permiten hacer las modificaciones en todos los programas que tienen el elemento a cambiar en comn. comn Los diccionarios de datos automatizados, automatizados se vuelven muy importantes para los grandes sistemas que producen miles de elementos de datos.
Adems de proporcionar documentacin y eliminar la redundancia, el diccionario de datos se puede usar para:
Validar la integridad g y exactitud de los DFD Dar un punto de partida para desarrollar pantallas e informes Determinar el contenido de los datos almacenados en archivos Desarrollar la lgica para los procesos de los DFD
Los diccionarios de datos tienen cuatro categoras:
Definicin de los Flujos de Datos

Son los primeros elementos que se definen. Los datos que podran contener son: ID, nmero de identificacin Un nombre descriptivo p para el flujo, p j ,q que debe aparecer p en el diagrama. g Debe ser nico Una descripcin general de flujo de datos La fuente del flujo (entidad externa, externa proceso o almacn) El destino del flujo (entidad externa, proceso o almacn) I di d que muestre t sii es un registro i t que entra t o sale, l o contiene ti i f Indicador un informe, formulario o pantalla Nombre de la estructura de datos que describe los elementos encontrados en el flujo Volumen por unidad de tiempo (ejemplo: registros por da) Comentarios adicionales
Definicin de las Estructuras de Datos
Existen muchos esquemas de notacin comunes que son utilizados por el analista de sistemas. El que se muestra a continuacin es uno de los ms comunes y utiliza varios smbolos sencillos: = : est compuesto de +:y ( ) : optativo (puede estar presente o ausente) { } : iteracin, elementos repetitivos [ ] : seleccionar una de varias alternativas | : Separa opciones alternativas en la construccin (o)
Definicin de las Estructuras de Datos
Pedido del cliente =
Nro. de cliente + Nombre de cliente + Direccin + Telfono + Fecha del pedido (Artculos disponibles) + Importe total + (Impuestos) + Forma de Pago + (Tipo de tarjeta) Nombre + (Inicial 2do nombre) + Apellido Calle + (Departamento) (D t t )+ Ciudad + Cdigo Postal + (Pas) [Cheque | Crdito | Giro] [Amex | Visa | Mastercard]
Nombre del cliente =
Direccin =
Forma de Pago = Tipo de tarjeta =
Estructuras lgicas y fsicas
Cuando se definen las estructuras, primero se definen los elementos de datos que ve el usuario. Este es el diseo lgico, mostrando los datos que necesita el negocio para la p operacin. Luego se disea la estructura de datos fsica, que incluyen elementos adicionales necesarios para implementar el sistema. Ejemplos de elementos del diseo fsico: Campos clave Cdigos (para identificar tipos g de transaccin (p p distintos de registros) g ) Entradas de grupos de repeticin (para contar los elementos) Los lmites sobre el nro de elementos aceptables en un grupo Contraseas
Estructuras de Datos Fsicas
Estado facturacin =
Elemento de repeticin. Sus lmites son entre 1 y 5 artculos.
Fecha actual + Numero de cliente + Nombre de cliente + Direccin + 5 1 {Lnea del Pedido} + Fecha del pedido (Artculos disponibles) + (Cantidad del Pago anterior) + C tid d a Pagar Cantidad P + (Comentarios) Nmero del Pedido + Fecha del Pedido + Total del Pedido
Si el nro se remite un nro fijo de veces, por ejemplo 12, si hubiese colocado: 12{Lnea del Pedido} Si ell nro de d repeticiones i i fuese indefinido: {Lnea del Pedido} { }
Lnea del Pedido =
Elementos de Datos
Los elementos de datos se deben definir una vez en el diccionario. Podra tenerse un formulario para esta tarea, tarea el que podra contener lo siguiente: ID del elemento (entrara opcional que permite construir entradas automticas en el diccionario). Nombre del elemento. elemento Alias. Sinnimos y otros nombres para el elemento. Descripcin del elemento. elemento Indicador si es base o derivado. Base es el elemento que se ingresa en el sistema, y derivado es el que es resultado de un clculo. Longitud del elemento. Tipo de datos. Numrico, fecha, alfabtico, etc Los formatos de entrada y salida. Los criterios de validacin. Se debe asegurar que el sistema capture los datos correctos. Valores predeterminados que pudiera tener el elemento. rea adicional para comentarios.
Elementos de Datos
Ejemplo con Visible Analyst
Almacenes de Datos
Los almacenes de datos se crean para cada entidad de datos diferente que se almacenar. Un formulario para la incorporacin de un almacn de datos, podra contener: El ID del almacn de datos Nombre Alias Breve descripcin Ti de Tipo d Archivo A hi (manual ( l o computadorizado) t d i d ) Nmero mximo y promedio de registros. Crecimiento anual. La estructura de datos que se utilice debe usar un nombre que est definido en el diccionario.
Creacin del diccionario

Las entradas al diccionario pueden crearse luego de completar el DFD, o en paralelo. Con las primeras entrevistas, entrevistas se puede ir confeccionando un primer DFD, DFD e ingresar los primeros flujos de datos al diccionario. Luego de realizar una mayor cantidad de entrevistas para descubrir los detalles del sistema, seguramente se crearn nuevos flujos. Como los DFD se desarrollan por niveles, es importante que los flujos de los DFD hijos, estn g en el p padre. contenidos como elementos o registros
Registro del empleado = Nro del empleado + Informacin personal + Informacin de sueldo Reg. de hs trabajadas = Nro del empleado + Nombre del empleado + Horas Trabajadas
Rec de nmina del emp = Nro del empleado + Nombre del empleado + Direccin + Monto del sueldo
Anlisis de las Entradas y Salidas
Los formularios L f l i de d entradas t d y salidas lid sirven i para organizar i l informacin la i f i obtenida en las entrevistas y anlisis de documentos. Estos formularios pueden contener los siguientes datos: Nombre descriptivo para la entrada y /o salida. Usuario de contacto para clarificar de detalles adicionales Especificacin si los datos son de entrada o salida Formato del flujo de datos Elementos que indican la secuencia de datos en un informe o pantalla Una lista de elementos incluyendo nombres, longitudes, si son base o derivados. derivados
Otras Definiciones de Diccionario de Datos
Segn Wikipedia, un diccionario de datos es un conjunto de datos que contiene las caractersticas lgicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripcin, alias, contenido y organizacin. Estos diccionarios se desarrollan durante el anlisis de flujo de datos y ayuda a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea p durante el diseo del p proyecto y Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, , se desarrolla durante el anlisis de flujo j de datos y auxilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripcin de todos estos elementos.
Introduccin
El modelo esencial
El modelo esencial del sistema es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mnimo posible acerca de cmo se implantar Se deben evitar los detalles de implantacin tales como:
Secuenciado arbitrario de las actividades en un modelo de flujo de datos Archivos innecesarios Revisin de errores y validaciones innecesarias de datos y p procesos dentro del sistema Datos redundantes o derivados
Componentes del modelo esencial
El modelo esencial consta de dos componentes principales:

Modelo ambiental (que modela el exterior) Modelo de comportamiento (que modela el interior)
El modelo ambiental define la frontera entre el sistema y el resto del d mundo El modelo de comportamiento describe el comportamiento que q e se requiere del sistema para que interacte de manera exitosa con el ambiente
El modelo ambiental
Para el analista, la labor ms difcil en la especificacin p de un sistema es a menudo determinar qu es parte del sistema y qu no. El modelo ambiental es el primer modelo importante que se debe desarrollar. Define las interfaces entre el sistema y el resto del universo Lo que se necesita saber es qu informacin entra al sistema desde el ambiente exterior, y qu informacin produce como salida al ambiente externo Otro aspecto del modelo ambiental es identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema
El sistema El ambiente
El modelo ambiental
A menudo existe un rea g gris, q que frecuentemente est abierta a negociaciones, es decir un rea sobre la cual el usuario:
No est seguro No haba pensado Tena algunas g ideas p preconcebidas q que reflexionar
El sistema El ambiente
El modelo ambiental
Si el analista elige g una p perspectiva p demasiado p pequea q para p un proyecto, est condenado al fracaso puesto que puede haber omitido funciones imprescindibles del sistema Si escoge una perspectiva demasiado amplia, tambin se condena al fracaso, fracaso puesto que tratar con una poltica bastante ms compleja y estar intentado desarrollar un sistema demasiado grande Por ello es importante dedicar bastante tiempo y tener suficiente participacin del usuario en la eleccin de una frontera apropiada para el sistema
Herramientas utilizadas para definir el ambiente

El modelo de ambiente consta de:
Declaracin de propsitos: Declaracin breve dirigida al nivel administrativo superior. superior Debe ocupar solo un prrafo, puesto que la intencin no es proporcionar una descripcin completa y detallada del sistema Diagrama de Di d contexto t t : Es E un caso especial i l del d l diagrama di d flujo de fl j de d datos, d t en donde d d una sola l burbuja representa a todo el sistema. Este diagrama enfatiza varias caractersticas importantes
Las personas, organizaciones y sistemas con los que se comunica el sistema Los datos que recibe del mundo exterior Los datos que produce y enva al exterior Los archivos principales La frontera entre el sistema y el resto del mundo
Lista de acontecimientos: Es una lista narrativa de los estmulos que ocurren en el mundo p Ejemplos: j p exterior a los cuales el sistema debe responder.
Un cliente hace un pedido Un cliente cancela un pedido
Componentes adicionales del modelo ambiental

Diccionario de datos que define los flujos y archivos externos El modelo entidad-relacin de archivos externos
Modelo de comportamiento
Define el comportamiento del sistema para manejar con xito el ambiente. Se deben desarrollar diagramas de flujo, diagramas entidad relacin preliminares, adems de las entradas iniciales del diccionario La idea es dibujar una burbuja para la respuesta del sistema ante cada acontecimiento que se detall en las lista de acontecimientos Luego se dibujan los archivos para modelar los datos Luego se dibujan los flujos de entrada y salida a las burbujas y se compara con el diagrama de contexto para asegurar la coherencia y consistencia Luego se hace un proceso de limpieza para producir un modelo organizado del proceso y un modelo d l de d datos d t para ser presentado t d all usuario i final fi l Lo que se busca es un desarrollo descendente del modelo de comportamiento
Introduccin
Diagramas de flujo de datos Otras formas posibles para describir un sistema

Lenguaje corriente: Poco claro, ambiguo y superficial. No contiene grficos ni esquemas que faciliten su comprensin Cursogramas: Muy tiles para mostrar la circulacin de informacin a travs de sectores, sectores pero no tienen la capacidad para reflejar procesos computadorizados. Diagramas de sistemas: Aptos para mostrar procesos por lotes. Muy orientados a los especialistas en el tema. Pero no son convenientes para encarar un nuevo diseo. diseo
Necesidad de una herramienta adecuada
Diagramas de flujo de datos
Herramienta utilizada tanto por el anlisis como por el diseo estructurados. Trata de independizar la descripcin lgica del sistema, de los elementos fsicos que le dan soporte (personas, archivos, computadoras). Por ello, ello a nivel lgico, lgico los DFD de un mismo sistema conceptual implantado en dos empresas distintas, necesariamente han de ser iguales Son muy tiles para preparar especificaciones funcionales de sistemas, que pueden ser apreciadas por los usuarios, usuarios que pueden expresar opiniones y determinar requerimientos lgicos sin caer en detalles de la implantacin fsica
Diagramas de flujo de datos Cuatro ventajas j p principales p Libertad conceptual: no hace falta comprometerse con la realizacin tcnica Permite comprender las interrelaciones entre sistemas y subsistemas Puede ser usado para interactuar con los usuarios Permite realizar un anlisis para asegurarse que toda la salida necesaria i pueda d ser obtenida b id
Diagramas de flujo de datos Simbologa a utilizar

Gane & Sarson Yourdon / De Marco
Proceso
Flujo de datos
Entidad externa
Almacenamiento
Diagramas de flujo de datos Graficacin de un DFD
Proceso
1 Validacin
Dpto. alumnos
P t partes: t identificacin, id tifi i descripcin d i i y sector t Posee tres que la realiza Nosotros no vamos a utilizar la ltima seccin El nombre del proceso debe ser claro y debe explicar l funcin la f i que se realiza li
Entidad externa
Alumno
Puede dibujarse ms de una vez, para evitar el cruce de lneas. En estos casos, suele cruzarse con un lnea diagonal Pese a ser utilizada como fuente, es externa al estudio
Diagramas de flujo de datos Graficacin de un DFD Poseen dos secciones: la identificacin y la descripcin En la identificacin, se comienza con la letra D (de DATA), seguida por un nmero. Esto es importante para el diccionario de datos Puede dibujarse ms de una vez
Archivos
D1 Alumnos
Flujo de datos
Solicitudes pendientes
Muestran el flujo de informacin a travs del sistema La punta de flecha es fundamental, puesto que indica el sentido de la informacin
Modelos segmentables en forma descendente
El sistema debe poder mostrarse en forma descendente La idea es poder moverse de una parte a otra del sistema en forma ordenada Si el sistema cambia, debe cambiar el modelo para mantenerse actualizado
Diagramas de flujo de datos Ejemplo j p

D1 Alumnos
Carrera
Alumno
Cdigo de alumno
D1 Alumnos
Cdigo de alumno
Si es necesario para la claridad del diagrama, pueden repetirse entidades externas y archivos
D2 Alumnos D1 Materias
Notas
Certificado
Alumno
Diagramas de flujo de datos Numeracin Nivel 0

1 0
Nivel 1
0
2
Diagramas de flujo de datos Numeracin Nivel 1

1.1 0
1 2
Nivel 2
1
1.2
1.3
1.4
Diagramas de flujo de datos Ms sobre los diagramas La idea es ir conociendo el detalle de nuestro sistema, yendo de lo general a lo particular Cada vez que hacemos una explosin de un nuevo nivel de detalle, debemos garantizar que todos los flujos de informacin d l nivel del i l anterior, t i aparezcan en ell nivel i l siguiente i i t El procesos consiste i t en mirar i all sistema i t con un ZOOM. ZOOM Cada C d nivel de detalle siguiente, implica aumentar la precisin de ese ZOOM ZOOM
Diagramas de flujo de datos Continuemos con el ejemplo

D1 Alumnos
Al agregar un nivel de detalle detalle
0
Notas Alumno Cdigo de alumno Carrera
Pueden aparecer nuevos flujos

D2 Al M mnos t i Materias D1 Alumnos
1
Consulta alumnos
2
Emisin certificado Certificado
D1 Alumnos
Cdigo de alumno
Alumno
Los flujos continan hacia los nuevos procesos
Diagramas de flujo de datos Errores comunes al dibujar un DFD

Olvidar la inclusin de un flujo de datos o colocar una flecha en la direccin errnea Un proceso transforma datos, debe recibir entradas y producir salidas. Si el proceso no cumple esto (solo entradas o solo salidas) hay error
1
Solicitudes pendientes Notas Solicitudes pendientes
1 Validacin
D t alumnos Dpto. l
Notas
Validacin
Dpto alumnos Dpto.
Etiquetado incorrecto de procesos y/o flujos de datos
Diagramas de flujo de datos Errores comunes al dibujar un DFD (cont.)

Entidades externas y/o archivos no pueden conectarse directamente entre si. si Deben hacerlo a travs de un proceso
Alumno D1
Alumnos
Alumno
Profesor
Bifurcacin de flujos
Diagramas de flujo de datos Ejemplo: Sistema de depsitos por cajero automtico

D1
Clave de acceso Tarjetas Datos de acceso
Cliente
Datos de tarjeta y clave de acceso D Datos d de d depsito i
0
Sistema de depsitos por cajero j automtico Saldo anterior al depsito validado Ticket depsito Cliente
Saldo anterior Depsito al depsito validado
D2
cuentas t
Diagramas de flujo de datos Ejemplo: Sistema de depsitos por cajero automtico

D1 Tarjetas j
Sistema de depsitos por cajero automtico

Datos de acceso Clave d Cl de acceso
1
Cliente Datos de tarjeta y clave de acceso Control de acceso
Tarjeta y clave vlidas
2
Verificacin de saldo Tarjeta y clave vlidas con saldo
3
Datos de depsito Validacin de depsitos
Saldo anterior al depsito validado
Ticket de depsito
Cliente
Saldo anterior al depsito
Depsito validado
D2
cuentas
Introduccin
Calendarizacin de proyectos de software

Conceptos p bsicos Los motivos ms frecuentes de retraso en un proyecto de software son:
Fecha lmite irrealizable, establecida e impuesta por algn externo al grupo Cambio en los requisitos del cliente que no se reflejan en la calendarizacin Subestimacin de esfuerzo y recursos Riesgos (predecibles o impredecibles) que no se consideraron al inicio Dificultades tcnicas que no pudieron preverse Dificultades f humanas imprevisibles Falta de comunicacin en el personal del proyecto Falla en la gestin por no reconocer retrasos ni emprender una accin correctiva
Las fechas lmite muy audaces son un hecho comn en el negocio del software En esta etapa el objetivo del Director es:
Definir todas las tareas del proyecto Construir una red que muestre sus interdependencias (PERT / CPM) Id tifi las l tareas t ti d t de d la l red d Identificar crticas dentro Seguir el proceso
Para lograr esto, el Director de tener una calendarizacin que est definida para poder supervisar el progreso y controlar el proyecto

La calendarizacin del proyecto de software es una actividad que distribuye estimaciones de esfuerzo a travs de la duracin planificada del proyecto al asignar el esfuerzo a tareas especficas de la Ingeniera de Software La calendarizacin evoluciona a lo largo del tiempo
Al inicio, es una estimacin macro Cuando va transcurriendo el proyecto, cada entrada de la calendarizacin macro se refina en una ms detallada
L calendarizacin l d i i puede d verse desde d d dos d perspectivas: ti La

Con una fecha de finalizacin ya establecida. Aqu nos vemos obligados a distribuir las tareas en el tiempo establecido. Se han comentado los lmites de tiempo aproximados, pero la fecha final la establece el Director del Proyecto
Por desgracia, la primer situacin se encuentra ms frecuentemente que la segunda
Relacin entre personal y esfuerzo

El mito es pensar que si el proyecto se retrasa podemos incorporar ms programadores y recuperarnos ms adelante Agregar g g ms p personas en etapas p tardas tiene un efecto p perturbador, , lo q que p puede p provocar que la calendarizacin se retrase an ms Esto sucede porque las personas tienen que aprender el sistema, sistema cuando la gente que le ensea es la misma que est trabajando l largo l d los l aos se ha h demostrado d t d que las l calendarizaciones l d i i l ti A lo de son elsticas. Es posible comprimir en cierta medida la fecha de terminacin deseada (al aadir recursos adicionales) Es posible extender la fecha de terminacin deseada (al reducir los recursos)
Definicin de un conjunto de tareas

Ningn conjunto de tareas que pueda definirse es apropiado para todos los proyectos Un proceso de software eficaz debe definir un conjunto de tareas diseadas para satisfacer las necesidades particulares El desarrollo de la calendarizacin requiere distribuir las tareas a lo largo de una lnea de tiempo Muchos factores influyen en la eleccin de las tareas
Tamao del proyecto Nmero de usuarios potenciales Lo crucial de la misin (los objetivos principales) Duracin de la aplicacin Estabilidad de los requisitos Factibilidad de comunicacin con el desarrollador o el usuario Madurez de la tecnologa aplicable Restricciones del desempao
Ejemplo conjunto de tareas

El conjunto de tareas depender tambin del modelo de ciclo de vida elegido El proyecto ejemplo es del tipo desarrollo del concepto, que son proyectos para explorar algunas aplicaciones o conceptos de negocio de alguna tecnologa Las tareas principales podran ser las siguientes:
1 1 Determinacin del mbito del concepto 1.1 1.2 Planeacin preliminar del concepto 1 3 Valoracin Vl i del d l riesgo i d la l tecnologa t l 1.3 de 1.4 Prueba del concepto 1.5 Implementacin del concepto 1.6 Reaccin del cliente
Ejemplo Refinamiento de las tareas principales

Las tareas principales pueden utilizarse para una calendarizacin macro Refinar la calendarizacin significa crear otra detallada Ejemplo para la tarea 1.1 Determinacin del mbito del concepto
1.1.1 Identificar necesidades, , beneficios y clientes p potenciales 1.1.2 Definir eventos de salida / control y entrada deseados que impulsen la aplicacin 1.1.2.1 RTF: Revisar la descripcin escrita de la necesidad 1 1 2 2 Derivar una lista de entradas / salidas visibles al cliente 1.1.2.2 1.1.2.3 RTF: Revisar entradas / salidas con el cliente y modificar 1.1.3 Definir la funcionalidad / comportamiento para cada funcin principal 1.1.3.1 RTF: Revisar los objetos de datos de salida y entradas derivados en la tarea 1.1.2 1.1.3.2 Derivar un modelo de funciones / comportamientos 1.1.3.3 RTF: Revisar funciones / comportamientos con el cliente y modificar 1.1.4 Aislar aquellos elementos de la tecnologa que se implementar en el software 1.1.5 Disponibilidad de investigacin del software existente 1 1 6 Definir factibilidad tcnica 1.1.6 1.1.7 Realizar estimacin rpida del tamao 1.1.8 Crear una definicin del mbito
Ejemplo Definicin de una red de tareas

Esto se realizar en funcin a las interdependencias Una red de tareas (tambin denominada red de actividad) es una representacin grfica del flujo de tareas de un proyecto En su forma ms simple, una red de tareas muestra las principales tareas de un proyecto Como las tareas paralelas no ocurren al mismo tiempo, el planificador debe analizar para asegurar el progreso continuo hacia la finalizacin Tambin se deben determinar las tareas que se encuentran en el camino crtico
1.1 Determinacin bit mbito concepto 1.2 Planeacin concepto 1.3a Evaluacin riesgo tec. 1.3b Evaluacin riesgo tec. 1.3c Evaluacin riesgo tec. 1.5a Implement. Implement concepto 1.5b Implement. concepto 1.5c Implement. concepto
1.4 1 4 Prueba concepto
Integracin I t i a,b,c 1.6 Reaccin cliente
Calendarizacin
PERT / CPM son dos mtodos de calendarizacin q que aplican p para los proyectos de software Estas dos tcnicas permiten al planificador de software
Determinar el camino crtico Cadena de tareas que determinan la duracin del proyecto Tareas q que de retrasarse, demoran la finalizacin total del p proyecto y
Establecer las estimaciones de tiempo ms probables para las tareas individuales Calcular los tiempos lmite que definen la ventana de tiempo para una tarea en particular
Cronogramas
El cronograma g que se g q genera en cada p proyecto, y , se denomina g grfico de Gantt
Seguimiento de la Calendariazacin
Los hitos y tareas se deben seguir y controlar conforme avanza el proyecto. Este seguimiento se puede hacer de varias maneras
Realizacin peridica de reuniones Evaluacin de los resultados de todas las revisiones realizadas Determinacin del cumplimiento de los hitos formales Comparacin de la fecha real con la de inicio p prevista p Reuniones informales con los colaboradores Evaluacin E l i cuantitativa tit ti del d l progreso
Cuando ocurren problemas o desvos, el director del proyecto debe j t l para solucionarlos l i l tan t pronto t como sea posible ibl ejercer control
Ejemplo de Calendarizacin
Supongamos que tenemos que calendarizar un proyecto de construccin de una casa Tambin supongamos que las grandes tareas son:
Tarea Tarea 1 - Preparar el lugar Tarea 2 - Construir el exterior Tarea 3 - Terminar el interior
Es evidente que no podemos calendarizar con estas tareas puesto que son demasiado globales E t Entonces, t tenemos que refinar, fi abriendo b i d en subtareas bt
Tarea Tarea 1 - Preparar el lugar 1.1 Agrimensura 1.2 Solicitar permisos 1 3 Excavar para cimientos 1.3 1.4 Comprar materiales Tarea 2 - Construir el exterior 2.1 Colocar los cimientos 22C 2.2 Construir i paredes d externas 2.3 Instalacin plomera externa 2.4 Instalacin elctrica externa 2.5 Terminar p paredes externas 2.6 Pintar el exterior 2.7 Colocar puertas y marcos 2.8 Colocar el techo Tarea 3 - Terminar el interior 3.1 Instalacin plomera interior 3.2 Instalacin elctrica interior 3.3 Colocar tabiques 3.4 Pintar el interior 3.5 Colocar pisos 3.6 Colocar puertas y marcos Hito Agrimensura completa Permisos obtenidos Excavacin completa Materiales adquiridos
Predece- Tiempo Inicio soras estimado temprano p Inicio tardo
Holgura
11 1 1.1, 1.2 2 Ahora si, si con estas tareas podemos 1.3 comenzar nuestras tareas de Cimientos preparados 1.4 15 36 36 calendarizacin Paredes P d exteriores i completas l Plomera exterior completa Instalacin exterior completa Terminaciones completas p Exterior pintado Puertas y marcos colocados Techo terminado
3 15 10 10
1 1 16 26
13 1 16 26
12 12 12 12 12 15 12 -
Dentro de los desarrollos de software, al finalizar cada tarea se suele cerrar con un hito, que generalmente es un entregable que sirve adems como documentacin realizacin de la Plomera interior completa 2.2 de la 12 71 71 Instalacin interior completa 3.1 15 83 83 tarea Tabiques colocados 3.2 9 98 98
Interior pintado Pisos colocados Puertas y marcos colocados 3.3 3.3 3.5 18 11 7 107 107 118 107 107 118
2.1 2 1 2.2 2.3 2.4 2.5 2.6 2.6
20 10 10 8 5 6 9
51 1 71 81 91 99 104 104
51 1 83 93 103 111 119 116
Tarea Tarea 1 - Preparar el lugar 1.1 Agrimensura 1.2 Solicitar permisos 1 3 Excavar para cimientos 1.3 1.4 Comprar materiales Tarea 2 - Construir el exterior 2.1 Colocar los cimientos 22C 2.2 Construir i paredes d externas 2.3 Instalacin plomera externa 2.4 Instalacin elctrica externa 2.5 Terminar p paredes externas 2.6 Pintar el exterior 2.7 Colocar puertas y marcos 2.8 Colocar el techo Tarea 3 - Terminar el interior 3.1 Instalacin plomera interior 3.2 Instalacin elctrica interior 3.3 Colocar tabiques 3.4 Pintar el interior 3.5 Colocar pisos 3.6 Colocar puertas y marcos Hito Agrimensura completa Permisos obtenidos Excavacin completa Materiales adquiridos Cimientos preparados P d exteriores Paredes i completas l Plomera exterior completa Instalacin exterior completa Terminaciones completas p Exterior pintado Puertas y marcos colocados Techo terminado Plomera interior completa Instalacin interior completa Tabiques colocados Interior pintado Pisos colocados Puertas y marcos colocados
Holgura
1.1, 1 1 1 1.2 2 1.3 1.4 21 2.1 2.2 2.3 2.4 2.5 2.6 2.6 2.2 3.1 3.2 3.3 3.3 3.5
Debemos conocer cuales son las tareas 15 36 36 predecesoras p

20 10 10 8 5 6 9 51 1 71 81 91 99 104 104 51 1 83 93 103 111 119 116
3 15 10 10
1 1 16 26
13 1 16 26
12 -
Estas son tareas que deben estar totalmente terminadas antes de comenzar la tarea a analizar 12 71 71 15 9 18 11 7 83 98 107 107 118 83 98 107 107 118 -
12 12 12 12 15 12
Holgura
1.1, 1 1 1 1.2 2 1.3 1.4 21 2.1 2.2 2.3 2.4 2.5 2.6 2.6 2.2 3.1 3.2 3.3 3.3 3.5
3 15 10 10 15 20 10 10 8 5 6 9 12 15 9 18 11 7
1 1 16 26 36 51 1 71 81 91 99 104 104
13 1 16 26 36 51 1 83 93 103 111 119 116
12 12 12 12 12 15 12
Luego, tenemos que asignar a cada tarea su duracin
71 83 98 107 107 118
71 83 98 107 107 118
Holgura
1.1, 1 1 1 1.2 2 1.3 1.4 21 2.1 2.2 2.3 2.4 2.5 2.6 2.6 2.2 3.1 3.2 3.3 3.3 3.5
3 15 10 10 15 20 10 10 8 5 6 9 12 15 9 18 11 7
1 1 16 26 36 51 1 71 81 91 99 104 104 71 83 98 107 107 118
13 1 16 26 36
12 -
Estamos en 51 1 83 condiciones 12 93 12 de armar la 103 12 111 12 red PERT 119 15

116 71 83 98 107 107 118 12 -
Armamos un PERT
Los diagramas de PERT / CPM son ideales para encadenar las tareas en el tiempo apuntando al orden de precedencia tiempo, Si bien existen diversos modos de armar un PERT, les propongo el siguiente mtodo: La red se compone de arcos (tareas) y nodos (hitos) Los hitos son puntos de fin y comienzo de las tareas longit d de cada arco no guarda g arda relacin con la duracin d racin de la tarea La longitud Los objetivos de un PERT son:
Conocer la duracin total del proyecto Conocer las fechas tempranas y tardas Detectar las tareas crticas
Armamos un PERT
Todo PERT comienza en un nodo inicial en el que las fechas tempranas y tardas coinciden (y valen 0) Dentro de cada nodo, se consignan las fechas tempranas y tardas La fecha temprana es la duracin acumulada en la que alcanzaremos el final de cada tarea (suponiendo que no existen demoras). Se calcula como la duracin acumulada en ell nodo d anterior t i ms la l duracin d i de d la l tarea. t Si para alcanzar l ell final fi l de d una etapa t se necesitan realizar dos o ms tareas que ocurren en forma paralela, la fecha temprana de finalizacin estar dada por la duracin mayor. La fecha tarda es la duracin acumulada hasta la que se pueden extender la terminacin de las tareas SIN DEMORAR LA FINALIZACIN DEL PROYECTO. Partiendo del nodo final (en dnde la fecha temprana y la tarda coinciden), iniciamos el camino inverso. Tomando la fecha tarda de cada nodo y restndole la duracin de las que lo anteceden llegamos g a la fecha tarda del nodo anterior. Si hay y dos o ms tareas q tareas que ocurren en forma paralela, tomamos la fecha tarda ms baja.
Armamos un PERT
La diferencia entre las fechas temprana y tarda da el GRADO DE TOLERANCIA A LAS DEMORAS. En los nodos en los que la fecha tarda es mayor a la fecha temprana, indica que tenemos alguna libertad en la concrecin de la tarea El INICIO TEMPRANO de la tarea es la fecha en la que se est en condiciones de comenzar con la tarea El TIEMPO DE INICIO MAS TARDO indica el ltimo plazo para comenzar la tarea sin demorar la finalizacin La HOLGURA DE TIEMPO se puede calcular de dos modos:
Como la diferencia entre el tiempo de inicio ms tardo menos el tiempo de inicio temprano tarea ms uno Como la diferencia entre la fecha tarda menos la duracin de la tarea,
Armamos un PERT
El CAMINO CRTICO est formado por las tareas crticas Una TAREA CRTICA es aquella que entre sus nodos final e inicial no existe grado de tolerancia a las demoras y que la resta de la fecha temprana del nodo final menos la fecha temprana del nodo inicial es igual a la duracin de la tarea (tambin se puede calcular con las fechas tardas) Si una tarea crtica se retrasa, se demora la finalizacin total del proyecto La sumatoria de las duraciones de las tareas crticas da la duracin total del proyecto p y
Armamos un PERT
7
2.3 10
80 2.4 92 10
90 2.5 102 8
98 11 110
2.6
13 103 115
2.8
2.7
6 9
0 0
11 1.1
13 15 1.3 15 10
14 25 1.4 25 10
21 35 2.1 35 15
22 50 2.2 50 20
70 70
15 124 124
1.2
15
3.1 12
3.4
18
32 82 3.2 82 15
Armamos la red Colocamos las duraciones de las tareas Calculamos fechas tempranas Calculamos Fechas Tardas
10
33 97 3.3 97 9
3.6
12 106 106
3.5 11
14 117 117
Armamos un PERT
7
2.3 10
80 2.4 92 10
90 2.5 102 8
98 11 110
2.6
13 103 115
2.8
2.7
6 9
0 0
11 1.1
13 15 1.3 15 10
14 25 1.4 25 10
21 35 2.1 35 15
22 50 2.2 50 20
70 70
15 124 124
1.2
15
3.1 12
3.4
18
32 82 3.2 82 15
Camino crtico
10
33 97 3.3 97 9
3.6
12 106 106
3.5 11
14 117 117
Holgura
1.1, 1 1 1 1.2 2 1.3 1.4 21 2.1 2.2 2.3 2.4 2.5 2.6 2.6 2.2 3.1 3.2 3.3 3.3 3.5
3 15 10 10 15 20 10 10 8 5 6 9 12 15 9 18 11 7
1 1 16 26 36 51 1 71 81 91 99 104 104 71 83 98 107 107 118
13 1 16 26 36 51 1 83 93 103 111 119 116 71 83 98 107 107 118
12 12 12 12 12 15 12 -
Introduccin
Estimacin de recursos
La estimacin de recursos, recursos costo y programa de trabajo requiere

Experiencia Acceso a buena informacin histrica (mtricas) Valor para comprometerse con predicciones cuantitativas
La estimacin implica riesgo y ste conduce a la incertidumbre J Davidson Da idson Frame, Frame la gran mayora ma ora de los proyectos pro ectos que q e se Segn J. llevan a cabo, reciben entre el 20% y 30% menos de los recursos de que se necesitan los q En cierta medida, cada incumplimiento de presupuesto y plazos se puede atribuir a una falla en la estimacin previa
Causas de las malas estimaciones

Adivinos inexpertos Discontinuidad entre preadjudicacin y postadjudicacin Malas estimaciones tcnicas Cambios en el proyecto Factores psicolgicos El optimista del 10 por ciento A t bajo Apuntar b j Poltica
Fuente: La Nueva Direccin de Proyectos J Davidson Frame

Adivinos inexpertos: Una de las principales causas de las malas estimaciones es que la gente que las lleva a cabo no sabe lo que hace. hace Es comn que un director inexperto les pida a sus colaboradores que estimen tiempo y recursos de la parte que les toca realizar. Entonces, casi nunca se obtiene bti una visin i i de d conjunto. j t Los L aficionados, fi i d suelen l caer en las l siguientes i i t trampas:
Tienden a ser optimistas, optimistas subestimando problemas potenciales Tienden a olvidar cosas No siguen una metodologa coherente, por lo que resulta difcil poder recrear la lgica que utilizaron
Entonces, primero se los debe capacitar Luego, la organizacin debe crear mtodos de clculo de costos y plazos

Discontinuidad entre preadjudicacin y posadjudicacin: Con frecuencia, los vendedores prometen a los clientes componentes y servicios que el personal del proyecto no puede proveer Cuando el equipo de proyecto se hace cargo de la tarea, tarea se encuentra en una situacin en la que no puede ganar
El precio del servicio puede ser ms bajo del costo para la compaa Pueden prometerse mejoras tecnolgicas que estn fuera de las posibilidades S pueden d tomar t i l b d Se compromisos con plazos absurdos
Malas estimaciones tcnicas: La planificacin cuidadosa puede evitar muchas sorpresas desagradables Ligado con el anlisis de riesgo, no es una mala idea que el planificador suponga lo peor. peor Se deben establecer mrgenes de contingencia

Cambios en el proyecto: Existen continuas presiones por cambios en el proyecto t
Competidor introduce un producto que puede cambiar las condiciones del mercado Cambio de regulaciones que haga cambiar el desarrollo del equipo de trabajo Fluctuaciones macro econmicas Problemas tcnicos pueden detener el proyecto L clientes li t pueden d solicitar li it modificaciones difi i Los
El problema del cambio es que frecuentemente se producen aumento de costos y extensin de plazos Los estimadores deben incluir estos efectos en sus clculos

Factores psicolgicos:
El nuevo proyecto puede presentar interesantes desafos tcnicos y de marketing Puede ofrecer las perspectiva de aumentar notoriamente las ganancias Entonces, puede generarse un compromiso psicolgico a favor de concretar el proyecto, que puede impedir que se vea el verdadero alcance
El impacto del optimismo sin lmites sobre la estimacin de costos y plazos puede llegar a ser enorme Entonces se producen distorsiones sutiles que no son fciles de descubrir

El optimista del diez por ciento: Veamos el ejemplo de un estimador que est enamorado de su proyecto:
Inconscientemente exagera sus beneficios en la pequea suma del 10% Tambin subestima los costos en 10% Pareciera que las consecuencias son mnimas, pero en realidad pueden ser dramticas Estima sus ventas en MM$ 1.1 (cuando en realidad sern de MM$ 1.0) Estima que las ganancias sern 11% de las ventas (M$ 121), en realidad sern 10% (M$ 100) Del anlisis de riesgo determina que la probabilidad de xito ser del 88% obteniendo una ganancia de M$ 106.48. En realidad la probabilidad de xito es 80% (ganancia de M$ 80) Estima los costos en M$ 81, cuando en realidad ser de M$ 90 Calcula la tasa de costo/beneficio en $1.31 (M$106.48 / M$ 81), cuando la verdadera es $ 0.89 (M$ 80 / M$ 90) El 10% de optimismo convirti en exitoso un proyecto que dar prdidas

Apuntar bajo Es prometer un proyecto por menos de su costo real Esto suele realizarse porque:
Tienen la esperanza que el bajo precio les consiga el negocio U vez que lo Una l tengan, t piensan i ganar con los l cambios bi que se hagan h all proyecto t Piensan que obtendrn futuros negocios con el cliente
Poltica Ocasionalmente, buenas estimaciones no se tienen en cuenta por cuestiones polticas Estas situaciones, pueden darse en busca de apoyo a los proyectos. Entonces las estimaciones se acomodan a gusto de los actores importantes
Un Proceso de Estimacin
Especificacin de requerimientos
Requisitos a cumplir Descomponer en fases y Estimacin tareas del esfuerzo
Tareas a realizar
Medir lo que quiere el usuario Medida de lo que quiere el usuario
Estimar el esfuerzo (lo que costar)
Datos histricos
Segunda tarea: Recursos

La siguiente tarea es la estimacin de los recursos para completar el desarrollo del software
Personal Entorno S ft Software reutilizable tili bl
Ubicacin Herram. de software ft Hardware
Nmero Habilidades
Personal
Entorno
Recursos de red
Cada recurso se especifica con 4 caractersticas: t ti

Descripcin del recurso Informe de disponibilidad Cundo se requerir q el recurso Duracin de la utilizacin
Compon. ya desarroll
Proyecto
Software reutilizable
Nuevos componentes
Compon. Experimentados
Compon. Experiecia parcial
Recursos
Recursos Humanos El planificador comienza:
Evaluando el mbito del software S l i Seleccionando d las l habilidades h bilid d requeridas id para completar l t ell desarrollo d ll Especificando la posicin organizacional (directo, ingeniero, programador) Especificando la especialidad (telecomunicaciones, base de datos,)
El nmero de personas que requiere un proyecto solo se determina luego de hacer una estimacin del esfuerzo de desarrollo
Recursos
Recursos de Software reutilizables Bennatan sugiere cuatro categoras de recursos de software que deben considerarse conforme avanza la planificacin:
Componentes ya desarrollados: software existente que se puede adquirir de un tercero o de un desarrollo previo Componentes experimentados: especificaciones, diseo, cdigo o datos de p prueba existentes q que se desarrollaron p para p proyectos previos similares. y p Los modificaciones son de bajo riesgo Componentes de experiencia parcial: especificaciones, diseo, cdigo o datos de prueba existentes que se desarrollaron para proyectos previos pero que requieren modificaciones sustanciales Componentes C t nuevos: El equipo i debe d b construir t i los l componentes t de d software especficamente para las necesidades del proyecto actual
Recursos
Recursos del entorno
El planificador del proyecto debe prescribir la ventana de tiempo requerida por el hardware y el software y verificar que estos recursos estarn disponibles Cuando un sistema basado en computadora (que incorpora p (q p software y hardware especializados) se somete a Ingeniera, quizs el equipo requiera acceso a elementos de hardware que estn de t utilizando tili d otros t equipos i d trabajo t b j
Introduccin
La Evaluacin de Proyectos
A travs de la evaluacin podemos medir el avance de acuerdo con los criterios preestablecidos Si se hacen evaluaciones a plazos regulares podemos descubrir los problemas cuando no son grandes y podemos manejarlos Una limitacin para las evaluaciones es que pueden provocar miedo, puesto q que suponen el anlisis de rendimiento de p personal p p El objetivo de la evaluacin es buscar problemas La evaluacin depende de crear un clima no amenazante de modo que las personas se sientan dispuestas para brindar detalles de los problemas
Qu es la evaluacin?
Supone la evaluacin peridica de la situacin del proyecto Al evaluar, damos un paso atrs y preguntamos si estamos cumpliendo con el conjunto de datos establecidos La evaluacin es un mecanismo para incorporar el seguimiento i i t a la l direccin di i de d proyectos t Definir las metas no es suficiente, suficiente debe probarse que se estn cumpliendo
Introduccin
Control y Seguimiento del Proyecto
Una de U d las l responsabilidades bilid d primordiales i di l del d l Director Di t del d l Proyecto es el seguimiento y control Esto requiere adoptar medidas correctoras para corregir los desvos, de ser necesario Un control (de cualquier tipo) solo podr ser necesario si previamente se han definido claramente los objetivos del proyecto El control consiste en comparar la realidad con lo que se h b estimado haba ti d (o ( presupuestado), t d ) y tomar t l decisiones las d i i d de correccin
Control de los plazos del Proyecto

La buena planificacin es la base para controlar la duracin del proyecto Si la p planificacin no existe, posible , este control no ser p Lo importante es conocer las desviaciones que se estn produciendo para poder actuar en consecuencia Lo que se debe evitar es realizar un PERT demasiado complejo que luego no sea actualizado por nadie Los diagramas de PERT permitirn hacer foco sobre las tareas crticas de modo de evitar los retrasos en ellas crticas, Los hitos de control son de gran valor para el seguimiento del proyecto, t debiendo d bi d establecerse t bl t d los todos l que sean necesarios i para garantizar el xito del proyecto
Control de los costos del Proyecto

Aqu se parte del presupuesto elaborado y se debe mantener informacin acerca de los costos reales para poder comprar desvos Al igual que con la planificacin, el presupuesto debe hacerse con el suficiente detalle y escollo radica en no disponer p En materia de control, el mayor de informacin de suficiente calidad Existen algunos conceptos de costos sobre los cuales se debe g p prestar especial atencin a la hora de controlar
Mano de obra propia Subcontrataciones (tercerizaciones) Compras p Materiales

Curva ABC de costos
80%
La esencia del control de costos es poder conocer con suficiente prontitud y confiabilidad los costos producidos de cada una de las actividades Los costos externos son los ms fciles de conocer puesto que generalmente se reflejan en una factura o documento Los costos internos en general son los peor puesto q que no existe una factura controlados p formal
Primeros comentarios
Si un Director de proyecto no sabe cunto trabajo se ha realizado, realizado no pueden saber si se ha gastado de ms o de menos Tradicionalmente los datos del rendimiento del trabajo se recogen Tradicionalmente, haciendo que el personal del proyecto informe sobre el porcentaje de la tarea cumplida Adems, por lo general se permite que cada una de las personas libremente lo q que esto significa comprenda p g En este sentido, la mayora cumple con esta tarea en funcin a su propia p p experiencia p
Este mtodo es de baja confiabilidad Es muy probable que las persones usen parmetros de estimacin diferentes
Mtodo integrado para el control
Si hacemos una cuenta que dice que tenemos una variacin positiva del 10% en los costos, no debemos apresurarnos y pensar que ahorramos dinero Puede ser que tengamos ese resultado porque no realizamos alguna tarea A l t tener t i i de d costos t negativa, ti no Anlogamente, una variacin quiere decir que hemos gastado de ms Esto sugiere que las variaciones de costos y tiempo de j deben analizarse en conjunto j ejecucin
Mtodo integrado para el control

Planificado Hoy Real

Analisis I - 2012-02

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis I - 2012-02

Enviado por

Direitos autorais:

Formatos disponíveis

Anlisis y Diseo de Sistemas I

Prof. Marcelo Tadey

Anlisis y Diseo de Sistemas I

Sistemas de tiempo real

Sistemas de tiempo real

Anlisis y Diseo de Sistemas I

Principales tipos de sistemas

Nivel de conocimiento Nivel operativo

Principales tipos de sistemas

Principales tipos de sistemas Sistemas de procesamiento de transacciones

Principales tipos de sistemas Sistemas de trabajo de conocimiento

Principales tipos de sistemas Sistemas de trabajo de conocimientos

Principales tipos de sistemas Sistemas de automatizacin de oficinas

Principales tipos de sistemas Sistemas de automatizacin de oficinas

Principales tipos de sistemas Sistemas de informacin gerencial

Principales tipos de sistemas Sistemas de informacin gerencial

Principales tipos de sistemas Sistemas de apoyo a la toma de decisiones

Principales tipos de sistemas Sistemas de apoyo a la toma de decisiones

Archivo de compras Base de datos de modelos analticos

Archivo vendedores Archivo de regiones

Principales tipos de sistemas Sistemas de apoyo a ejecutivos

Ejemplos: Simulaciones, sistemas de grficos avazados

Principales tipos de sistemas Relacin de integracin entre los sistemas

Principales tipos de sistemas Las decisiones y los sistemas de Informacin

TPS OAS MIS

Anlisis y Diseo de Sistemas I

Los participantes Usuarios

Los participantes Administracin

Los participantes Auditores y Control de Calidad

Los participantes Diseadores de Sistemas

Los participantes Analistas de Sistemas

Roles del Analista de Sistemas

Roles del Analista de Sistemas

Roles del Analista de Sistemas

Cualidades del Analista de Sistemas

Anlisis y Diseo de Sistemas I

Usuarios del sistema Generalmente, quin es el entrevistado? Analistas anteriores Proveedores

Rol del analista

Abiertas (no estructuradas) Combinadas

Condiciones en que debe desarrollarse la entrevista

Condiciones para desarrollar la entrevista

Anlisis y Diseo de Sistemas I

Segn Kendall & Kendall

Cinco pasos para preparar una Entrevista

2) Establecer los objetivos de la entrevista 3) Decidir a quin entrevistar

5) Decidir el tipo de preguntas y la estructura

Anlisis y Diseo de Sistemas I

Uso de Cuestionarios y Planificacin

Eleccin del Vocabulario

Las escalas nominales se utilizan para clasificar cosas. Por ejemplo:

Anlisis y Diseo de Sistemas I

Necesidad de una metodologa

Modelos segmentables en forma descendente

Introduccin Acotamiento del campo de accin

Nuevo diseo DAMC: Decisin alternativa ms conveniente

Anlisis y Diseo de Sistemas I

Anlisis y Diseo de Sistemas I

C fid i lid d de Confidencialidad d la l informacin i f i recogida id

Control peridico del proyecto

Anlisis y Diseo de Sistemas I

Tareas a desarrollar en el Anlisis Detallado

Tareas a desarrollar en el Anlisis Detallado

Anlisis y Diseo de Sistemas I