Beruflich Dokumente
Kultur Dokumente
1.
2.
3.
La Teora General de los Sistemas se basa en dos pilares bsicos: aportes semnticos y aportes
metodolgicos.
APORTES SEMANTICOS
Las sucesivas especializaciones de las ciencias obligan a la creacin de nuevas palabras, estas se acumulan
durante sucesivas especializaciones, llegando a formar casi un verdadero lenguaje que slo es manejado por los
especialistas. De esta forma surgen problemas al tratarse de proyectos interdisciplinarios, ya que los participantes
del proyecto son especialistas de diferentes ramas de la ciencia y cada uno de ellos maneja una semntica
diferente a los dems.
La Teora de los Sistemas, para solucionar estos inconvenientes, pretende introducir una semntica
cientfica de utilizacin universal.
Sistema:
Es un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan formando un
todo unitario y complejo. Cabe aclarar que las cosas o partes que componen al sistema, no se refieren al campo
fsico (objetos), sino ms bien al funcional. De este modo las cosas o partes pasan a ser funciones bsicas
realizadas por el sistema. Podemos enumerarlas en: entradas, procesos y salidas.
Entradas:
Rango:
En el universo existen distintas estructuras de sistemas y es factible ejercitar en ellas un proceso de definicin de
rango relativo. Esto producira una jerarquizacin de las distintas estructuras en funcin de su grado de
complejidad. Cada rango o jerarqua marca con claridad una dimensin que acta como un indicador claro de las
diferencias que existen entre los subsistemas respectivos. Esta concepcin denota que un sistema de nivel 1 es
diferente de otro de nivel 8 y que, en consecuencia, no pueden aplicarse los mismos modelos, ni mtodos
anlogos a riesgo de cometer evidentes falacias metodolgicas y cientficas. Para aplicar el concepto de rango, el
foco de atencin debe utilizarse en forma alternativa: se considera el contexto y a su nivel de rango o se considera
al sistema y su nivel de rango.
Refirindonos a los rangos hay que establecer los distintos subsistemas. Cada sistema puede ser fraccionado en
partes sobre la base de un elemento comn o en funcin de un mtodo lgico de deteccin. El concepto de rango
indica la jerarqua de los respectivos subsistemas entre s y su nivel de relacin con el sistema mayor.
Subsistemas:
En la misma definicin de sistema, se hace referencia a los subsistemas que lo componen, cuando se indica que el
mismo esta formado por partes o cosas que forman el todo. Estos conjuntos o partes pueden ser a su vez sistemas
(en este caso seran subsistemas del sistema de definicin), ya que conforman un todo en s mismos y estos seran
de un rango inferior al del sistema que componen. Estos subsistemas forman o componen un sistema de un rango
mayor, el cual para los primeros se denomina macrosistema.
Retroalimentacin:
La retroalimentacin se produce cuando las salidas del sistema o la influencia de las salidas del sistema en el
contexto, vuelven a ingresar al sistema como recursos o informacin. La retroalimentacin permite el control de
un sistema y que el mismo tome medidas de correccin en base a la informacin retroalimentada.
Feed-forward o alimentacin delantera:
Es una forma de control de los sistemas, donde dicho control se realiza a la entrada del sistema, de tal manera que
el mismo no tenga entradas corruptas o malas, de esta forma al no haber entradas malas en el sistema, las fallas
no sern consecuencia de las entradas sino de los proceso mismos que componen al sistema.
Homeostasis:
La homeostasis es la propiedad de un sistema que define su nivel de respuesta y de adaptacin al contexto. Es el
nivel de adaptacin permanente del sistema o su tendencia a la supervivencia dinmica. Los sistemas altamente
homeostticos sufren transformaciones estructurales en igual medida que el contexto sufre transformaciones,
ambos actan como condicionantes del nivel de evolucin.
Entropa:
La entropa de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por el
funcionamiento del mismo. Los sistemas altamente entrpicos tienden a desaparecer por el desgaste generado
por su proceso sistmico. Los mismos deben tener rigurosos sistemas de control y mecanismos de revisin,
reelaboracin y cambio permanente, para evitar su desaparicin a travs del tiempo. En un sistema cerrado la
entropa siempre debe ser positiva. Sin embargo en los sistemas abiertos biolgicos o sociales, la entropa puede
ser reducida o mejor aun transformarse en entropa negativa, es decir, un proceso de organizacin ms completo
y de capacidad para transformar los recursos. Esto es posible porque en los sistemas abiertos los recursos
utilizados para reducir el proceso de entropa se toman del medio externo. Asimismo, los sistemas vivientes se
mantienen en un estado estable y pueden evitar el incremento de la entropa y aun desarrollarse hacia estados de
orden y de organizacin creciente.
Sinergia:
Es la caracterstica de los sistemas que define que la capacidad de actuacin de un sistema es superior a la de sus
componentes sumados individualmente.
Permeabilidad:
La permeabilidad de un sistema mide la interaccin que este recibe del medio, se dice que a mayor o menor
permeabilidad del sistema el mismo ser ms o menos abierto. Los sistemas que tienen mucha relacin con el
medio en el cul se desarrollan son sistemas altamente permeables.
A partir de esto se podemos clasificar a los sistemas en:
Abiertos: sistemas que tienen algn grado de permeabilidad, es decir que est relacionado con su
ambiente pero adems sta vinculacin es fundamental para su funcionamiento, crecimiento y
transformacin.
Cerrado: no intercambia nada con el ambiente; no es permeable. En general son considerados como una
abstraccin intelectual
Otra clasificacin que podemos mencionar es:
Reales: aquellos sistemas que pueden describirse
Ideales: son construcciones simblicas, Por ej. Lgica y matemtica.
Modelos: abstracciones de la realidad.
Isomorfismo:
Isomorfismo significa con una forma similar y se refiere a la construccin de modelos de sistemas similares al
modelo original. Por ejemplo, un corazn artificial es isomrfico respecto al rgano real: este modelo puede servir
como elemento de estudio para extraer conclusiones aplicables al corazn original.
Homomorfismo:
El modelo ya no es similar, sino una representacin donde se ha efectuado un reduccin de variables, de muchas a
una. Este modelo es muy til en ciencias tales como la economa (cuando se desea, por ejemplo realizar
proyecciones o anlisis)
Equifinalidad:
La equifinalidad sugiere que ciertos resultados podrn ser alcanzados con diferentes condiciones iniciales y por
medios divergentes. Este punto de vista indica que los sistemas sociales, tales como las organizaciones, pueden
lograr sus objetivos con entradas diversas y con actividades internas y variadas.
Adaptabilidad:
Es la propiedad que tiene un sistema de aprender y modificar un proceso, un estado o una caracterstica de
acuerdo a las modificaciones que sufre el contexto. Esto se logra a travs de un mecanismo de adaptacin que
permita responder a los cambios internos y externos a travs del tiempo. Para que un sistema pueda ser adaptable
debe tener un fluido intercambio con el medio en el que se desarrolla.
Mantenibilidad:
Es la propiedad que tiene un sistema de mantenerse constantemente en funcionamiento. Para ello utiliza un
mecanismo de mantenimiento que asegure que los distintos subsistemas estn balanceados y que el sistema total
se mantiene en equilibrio con su medio.
Estabilidad: Un sistema se dice estable cuando puede mantenerse en equilibrio a travs del flujo continuo de
materiales, energa e informacin. La estabilidad de los sistemas ocurre mientras los mismos pueden mantener su
funcionamiento y trabajen de manera efectiva (mantenibilidad).
LAS ORGANIZACIONES COMO SISTEMAS
Una organizacin es un sistema socio-tcnico incluido en otro ms amplio que es la sociedad con la que
interacta influyndose mutuamente. Tambin puede ser definida como un sistema social, integrado por
individuos y grupos de trabajo que responden a una determinada estructura y dentro de un contexto al que
DATO E INFORMACIN
DATO:
Es lo objetivo, lo que una persona puede detectar a travs de sus cinco sentidos o lo que una computadora puede
ingresar a travs de sus unidades de entrada de datos. Tambin lo que un hombreo una computadora pueden
emitir.
INFORMACIN:
Significado que una persona asigna a un dato, es decir el aumento de conocimiento que cada dato proporciona a
su receptor. Por lo tanto que un dato informe de algo o no lo haga, depende del receptor y de sus exclusivos y
personales conocimientos e interpretacin.
CARACTERSTICAS DE LA INFORMACIN
Mucho se ha escrito sobre el cambio de la era industrial a la era del conocimiento, era esta manejada casi
que en su totalidad inicialmente por el acceso a la informacin y ms recientemente por el uso que se le de a la
informacin. En el afn de establecer sistemas de informacin para toma de decisiones que generen resultados,
se escatima esfuerzo en disear exactamente qu se entiende por informacin y en cumplir con las cinco
caractersticas requeridas de tal manera que sta informacin cumpla con su objetivo.
En primer lugar, la informacin debe estar actualizada, lo que implica que sta es capturada cuando se
genera y no un tiempo despus mediante procesos adicionales. Es decir, cuando se factura en un almacn, se
debe descargar del inventario y contabilizar con la misma transaccin (no necesariamente en tiempo real, pero
no debe involucrar procesos manuales adicionales). Tambin debe haber una conectividad con entidades
externas como clientes, proveedores, entidades de gobierno entre otras, de tal manera que la informacin que
deba circular por fuera de la empresa, tambin lo haga de manera gil permitiendo la actualizacin
permanente.
Ante tanta informacin disponible, la que se presente para tomas de decisiones debe ser relevante, es
decir, ni ms ni menos que la necesaria. Para poder proveer la cantidad exacta de informacin, se debe contar
con sistemas que permitan tener anlisis a diferentes niveles de detalle: unas bases de informacin consolidada
para la gestin, y unas bases de informacin de produccin para el manejo de las transacciones. Se debe
proveer el mecanismo ms gil disponible para el acceso a esta informacin y garantizar que haya conectividad
entre las diferentes bases de informacin.
La velocidad de los negocios exige una oportunidad en esta informacin, lo que implica tener una alta
velocidad de acceso a la informacin la cual se puede proveer con conexiones permanentes en "lnea" a las
bases de datos. Adicionalmente, la oportunidad exige disponibilidad de alto nivel, lo que ocasiona el
establecimiento de planes de continuidad que garanticen el acceso a la misma.
Si bien es importante el manejo de la cantidad de la informacin y el acceso a la misma, es tal vez ms
importante la calidad de la informacin que se presente en sus niveles de confiabilidad. Es decir, qu tanto se
puede creer en la informacin que se est recibiendo. Afortunadamente este factor se disea mediante la
Enfoques Metodolgicos
1. Tradicional
2. Estructurado
3. Orientado a objetos.
4. Multimediales
1) Tradicional: estructura RADI (reconocimiento anlisis diseo implementacin)
Caractersticas:
No hay superposicin de etapas
No se trabaja con modelos
Problema de tiempos, porque si hay un error tengo q volver a la etapa y resolverlo. Esto aumenta
la impaciencia del usuario.
Tiene problemas de costos
2) Estructurado: estructura RADI
Caractersticas:
Hay superposicin de etapas
Se reducen tiempos y costos en relacin con el modelo tradicional
El usuario se impacienta menos
Se implementa el concepto de modelo fsico y modelo lgico
Modelo: es una simplificacin de la realidad en donde se proporcionan los planos de un sistema.
Un buen modelo incluye los elementos claves y omite los menos relevantes.
Objetivos: Construimos modelos para comprender mejor el sistema que estamos desarrollando. Conseguimos 4
objetivos puntuales:
Nos ayudan a visualizar como es o queremos que sea un sistema.
Nos permiten especificar la estructura o el comportamiento de un sistema.
Proporcionan plantillas que nos guan en la construccin del sistema
Documentan las decisiones que se toman.
Existen 4 principios bsicos para el modelado:
La eleccin de modelos a crear influye en la como se acomete un problema y como se le da forma
a una solucin.
Todo modelo puede ser expresado a diferentes niveles de precisin
Los mejores modelos estn ligados con la realidad
Un nico modelo no es suficiente si el sistema no es trivial. Es preferible abordarlo con pequeos
modelos casi independientes.
Modelo Lgico: me interesa pensar en la solucin lgica del sistema, es decir, NO tener en cuenta COMO se
construir, sino que debo concentrarme en determinar los eventos que ocurren y en los datos requeridos y
producidos por cada evento.
Modelo Fsico: se piensa una solucin fsica para el sistema, es decir, COMO se va a construir el sistema, incluyendo
la tecnologa que se va a utilizar, los archivos y el personal. Es una descripcin fsica del sistema.
Relacin entre el modelo Lgico y el Fsico: de un modelo lgico pueden surgir varios modelos fsicos.
Enfoque Estructurado
Dos tipos de modelados:
Modelado de funciones:
o Diagrama de contexto o DFD0
o Diagrama de Flujo de Datos
Modelado de Datos
o Diccionario de Datos
o Diagrama de Entidad-Relacin
Ventajas de usar un modelo lgico para realizar un DFD.
1. Mejor comunicacin con los usuarios.
2. Sistemas ms estables.
3. Mejor entendimiento del negocio por parte de los analistas.
4. Flexibilidad y mantenimiento.
5. Eliminacin de redundancias y creacin ms sencilla del modelo fsico.
Proceso o Funcin: Muestra una parte del sistema que transforma entradas en salidas. El nombre del
proceso describe QU es lo que se hace (debe describir una accin). Debe tener un ndice(no tiene nada
que ver con el orden y describe el nivel de detalle) y puede estar representado mediante un valo o un
crculo
Flujo de Datos: Describe el movimiento de bloques o paquetes de informacin mediante una flecha.
Representan la informacin en movimiento. Tambin muestran la direccin desde donde se estn
moviendo los datos hacia donde se dirigen. Flujo Activador: es el que desencadena el resto de las
funciones.
Almacenes: Se utiliza para modelar una coleccin de datos en reposo. Se denota por dos lneas paralelas
y el nombre que se utiliza es el plural de los datos que ingresan y salen del almacn.
Entidad Externa: es cualquier entidad que est fuera del control del sistema y con el cual dicho sistema se
comunica. Puede ser una persona, un grupo de gente u otro sistema y puede ser interna o externa a la
compaa.
Diagrama de contexto: define el sistema como un nico proceso, donde se muestra la relacin o interaccin con
su entorno (exterior).
Caractersticas:
Maneja informacin, no Documentos
Es ajeno a soportes fsicos.
Muestra las entidades externas y los flujos principales de datos. NO ALMACENAMIENTOS.
Superficial y amplio
Objetivos:
o Ayudar a entender el movimiento de datos de una manera muy general
o Establecer las fronteras del sistema.
Listas de acontecimientos: lista narrativa de los estmulos que ocurren en el exterior y a los que el sistema debe
responder.
Diagrama de flujos de Datos lgico: es un modelado de funciones que se utiliza para documentar el sistema
(tcnica de documentacin).
En este diagrama:
Se muestra el movimiento de datos en el sistema
Se muestra la transformacin de los datos.
Se describen los eventos que ocurren y los datos requeridos y producidos por cada evento.
No es necesario finalizar el relevamiento para comenzar el modelado. Al terminar el DFD se valida con el usuario
(se interacta con el para darnos cuenta si se debe incorporar info).
Distintos grupos de trabajo pueden llegar a distintos niveles de detalle, por la experiencia o el
conocimiento.
Los niveles de detalle donde tiene sentido que el usuario participe son el 1 y como mximo el 2.
Tcnicamente debo seguir analizando
Es importante documentar el sistema para conocerlo y poder realizar el mantenimiento (es un indicador
de calidad).
Errores en un DFD:
Un proceso no posee flujo de salida ( no se esta procesando la informacin)
No puede haber flujo de datos entre entidades externas representadas en el diagrama ( si conocemos el
enunciado y falta un proceso, entonces tambin es error de lgica)
Un proceso no posee ndice.
No hay flujo de activacin
No se especifica un evento
No se especifica el flujo de datos (no se sabe que datos se estn enviando)
Un proceso no posee flujo de entrada, es decir, le faltan estmulos.
No se puede acceder a un almacenamiento desde una entidad externa
No se pueden enviar datos entre dos procesos si antes no se almacenan (convencin de la ctedra).
No se procesa la informacin (flujo de entrada= flujo de salida)
El flujo temporal no esta determinado como una frecuencia de tiempo.
Diccionario de Datos (modelado de Datos): Es una lista ordenada en forma alfabtica de los datos asociados al
sistema con definiciones precisas y rigurosas de entrada, salidas, almacenamiento y tendiente a una comunicacin
con el equipo tcnico. Eventualmente puede llegar a intervenir el usuario (poco comn). Tecnica de
Documentacin.
Identificador: registro nico para una bsqueda (se relaciona con DER), forma de acceder al registro.
Desventajas: Escritura Tediosa, actualizacin permanente
Ventajas: comunicacin, Documentacin.
Diagrama Entidad- Relacin: (modelado de Datos) representa entidades de datos y sus relaciones. Tecnica de
documentacin.
NO NOS INTERESAN LOS FLUJOS
Elementos que lo componen:
Entidades: cualquier objeto, real o abstracto, que existe en un contexto determinado o puede
llegar a existir y del cual deseamos guardar informacin. Es el elemento atmico de un dato.
Representan los datos PROPIOS del sistema.
Atributos: son caractersticas o propiedades asociadas a la entidad, que toman valor en una
instancia particular (datos que nos interesa conocer).
Relaciones: asociacin entre entidades.
Clave: me identifica unvocamente un solo registro por campo.
Objetivos en el Anlisis de Sistemas:
Generar un modelo de los datos que persisten en el sistema y ver la relacin entre dichos datos.
Realizar una representacin por entidades y relaciones, y no enfocarnos en los flujos.
Clave principal: al atributo o conjunto mnimo de atributos (uno o ms campos) que permiten identificar en forma
nica cada instancia de la entidad, es decir, a cada registro de la tabla. En un principio se puede identificar ms de
un atributo que cumpla
las condiciones para ser clave, los mismos se denominan Claves candidatas.
Clave principal: 3 caracteristicas:
Unicidad: la propiedad de identificar a un nico registro entre muchos determinando los valores
de la clave
Minimalidad: se refiere a que si la clave es un conjunto de atributos (es decir, es una clave
compuesta) cualquier subconjunto de esos atributos no es clave ya que pierde la unicidad
Que haya sido elegida: es decir, el analista ha elegido la clave para que sea principal de entre las
candidatas.
Clave Fornea: atributo que es clave en otra entidad con la que se relaciona.
Relaciones:
Importancia de la modalidad y cardinalidad en el anlisis de sistemas: nos permite determinar la unidad minima de
datos que me interesa conocer para la definicin de mi sistema. Me permite determinar la cantidad indispensable
de informacion que debo mover.
Entidades
Fundamentales o Fuertes:
cuya clave esta compuesta por atributos propios. Ej: factura
Dbiles: tienen al menos una relacin con otra clave
o Asociativa: su clave principal no tiene atributos propios, son las de las entidades que se
relaciona.
o Hay al menos un atributo propio.
10
Reutilizacin: utilizar cdigo que ya hemos hecho (esta probado y funciona). Tambin es una
ventaja a la hora de la construccin del sistema.
Es conveniente para sistemas muy complejos.
Tiene mayor Portabilidad: se utiliza la misma solucin lgica para distintas plataformas tecnolgicas
(portarlo a distintas plataformas).
Posee mayor nivel de documentacin.
(Cumplir con las reglas de negocio y con el time to market es una manera de asegurar la inversin)
-Conceptos de Objetos:
o Objeto: cualquier ente real o abstracto que existe fsica o virtualmente y tiene una responsabilidad.
Contienen datos y operaciones (sobre los datos). Tienen:
Identidad: pueden nombrarse o distinguirse de otros objetos
Atributos: propiedades del objeto y conocimiento de los objetos con los que colabora.
Comportamiento: forma en que responde a un mensaje (mtodos).
o Clase: descripcin de un conjunto de objetos similares. Permite modelar la estructura y comportamiento
comn de varios objetos. Es un molde o planilla para la creacin de objetos.
o Relacin entre clases:
Asociacin simple: representa una relacin general entre objetos. Ej trabaja para entre
la clase Empleado y la clase Departamento.
Agregacin: representa la relacin parte de y cada parte tiene significado por si sola.
(EJ: PC formada por CPU, monitor, teclado,etc),
Composicin: representa la relacin parte de entre objetos, pero cada una de las
partes no tiene significado por si sola (ej: camisa formada por bolsillo, cuello, manga)
o Mensajes: las solicitudes que invocan a los mtodos.
o Atributo: Caracterstica concreta de una determinada clase. Puede ser:
o De clase: compartidos por todas las instancias de una misma clase
o De instancia: cada instancia de una clase posee una copia local de los mismos.
o Mtodo: operacin concreta de una determinada clase. Define el comportamiento. En un lenguaje de
programacin, es la implementacin del mensaje. Puede ser:
De Clase: responde a la clase sin ser instanciada.
De instancia: responde a una instancia en particular.
o Pblicos: me muestra la relacin con otros objetos
o Privados: funcionamiento propio del objeto.
o
o
o
o
o
11
12
Probabilidad de ocurrencia.
2.
Qu es un riego tcnico? Es la posibilidad de que la aplicacin de la teora, los principios y las tcnicas del
desarrollo de software no puedan lograr el producto adecuado. El riesgo tcnico consta de factores tecnolgicos
que pueden hacer que el producto sea:
muy caro,
entregado tarde, o
Qu hay que hacer para controlar un riesgo tcnico de software? Creemos que hay tres elementos claves:
1.
Identificar. Debemos encontrar los riesgos mientras estemos a tiempo para tomar acciones. Esto
incluye mirar al futuro y considerar el camino que elegimos desde una perspectiva del riesgo.
2.
Comunicar. Debemos aceptar que ese riesgo existe y comunicarlos riesgos a aquellos encargados
de resolverlos.
3.
Resolver. Debemos tomar una decisin deliberada para actuar sobre los riesgos. Esto significa
convertir al riesgo en una oportunidad para mejorar las chances de xito.
13
Para lograr nuestra meta de ayudar a los programas a ser exitosos usando la administracin de riesgos,
hemos establecido dos objetivos. Estos objetivos son:
1.
2.
Fortalecer la habilidad de las organizaciones para evaluar y administrar el riesgo relacionado con
el software.
2.
3.
Identificacin. Descubrir los riesgos antes que se vuelvan problemas y afecten al programa.
Anlisis. Convertir los datos de los riesgos a informacin que permita tomar decisiones.
Seguimiento. Monitorear el estado de los riesgos y las acciones tomadas contra los riegos.
Comunicacin. Proveer una respuesta sobre las tareas activas, los riesgos actuales y emergentes
por todos los elementos del paradigma y en el programa.
La identificacin de riesgos. Antes de que los riegos puedan ser administrados, deben ser identificados.
La identificacin apunta a mejorar los riesgos ms importantes antes de que afecten al programa. Estamos
desarrollando tcnicas para descubrir riesgos al explotar y comunicar el conocimiento sobre riesgos del equipo.
14
La clave de la planificacin de acciones es considerar las consecuencias futuras de cada decisin hecha
hoy.
El seguimiento de riesgos es requerido para asegurar la implementacin efectiva del plan de accin. Esto
significa que debemos elegir las mtricas del riesgo y los eventos disparadores necesarios para asegurar que los
planes funcionan correctamente.
El control de riesgos. La administracin de riesgos se une al programa de administracin y confa en el
proceso de control de dicho programa para controlar los planes de accin, corregir variaciones, responder a los
eventos disparadores y mejorar el proceso de administracin de riesgos.
Finalmente, la comunicacin de riesgos esta en el centro de nuestro paradigma porque, sin una
comunicacin efectiva, no hay ningn enfoque de administracin de riesgos que sea viable. Los riesgos deben ser
comunicados a los niveles apropiados de la organizacin asi pueden ser analizados y administrados de manera
efectiva. Esto incluye a los niveles dentro de la organizacin de desarrollo, el cliente y mas especialmente, en el
umbral entre el cliente y el desarrollador.
Proceso de Evaluacin de Riesgos
El proceso de evaluacin empieza con el compromiso y la cooperacin de los ejecutivos. Solo ellos tienen
la autoridad para hacer que la administracin de riesgos sea un xito.
La evaluacin de riesgos empieza con el entrenamiento del equipo. El equipo se rene para capacitarse en
los detalles de nuestro paradigma y en el proceso de evaluacin.
La primera actividad que se realiza en las oficinas del cliente se denomina Vista Rpida. La Mirada Rpida
es diseada para ser solo una mirada por encima del programa completo.
Durante la Vista Rpida, el equipo evaluador:
La Vista Rpida termina con un informe que incluye las reas donde el equipo evaluador siente que se
necesita ms investigacin. La decisin final de cuando y con que reas proseguir es del administrador del
programa.
El periodo de Investigacin es una investigacin a fondo dentro de las reas de riesgo seleccionadas por el
administrador del programa. Durante la Investigacin, el equipo evaluador:
15
Entrada
Participantes
Actividades
Investigacin
Participantes
Participantes
Propuesta
Documentos de requerimientos
Documentos de requerimientos
Ingenieros de sistemas
Ingenieros de sistemas
Ingenieros de software
Ingenieros de software
Identificacin
Identificacin
Anlisis (limitado)
Anlisis (limitado)
Planificacin de las acciones
Salida
reas de riesgo
Especificacin de riesgos
Posibles acciones
Ciclos de Vida:
Cascada Pura: El proyecto progresa a travs de una secuencia de pasos ordenados desde la idea inicial hacia la
prueba de sistema. El modelo de cascada esta dirigido por documentos, lo que significa que los productos que son
transportados de una fase a otra son principalmente documentos. En el modelo de cascada pura, las fases son
discontinuas, no se solapan. Este modelo funciona bien en ciclos donde ya tens una definicin estable y cuando
estas trabajando con metodologas bien entendidas. En esos casos el modelo te ayuda detectar errores en las
16
El modelo de cascada funciona bien en los proyectos que son bien entendidos pero complejos, porque podes
beneficiarte de abordar la complejidad de una manera ordenada. Funciona bien cuando la calidad domina al costo
y el tiempo. La eliminacin de cambios de idea a la mitad elimina una gran fuente de errores potenciales.
El modelo de cascada funciona especialmente bien si tenemos un staff dbil o sin experiencia, porque provee
al proyecto con una estructura que ayuda a minimizar el esfuerzo desperdiciado.
Las desventajas de este modelo, provienen de la dificultad de podes especificar completamente los
requerimientos al principio del proyecto, antes de que el diseo se haya hecho y el cdigo se haya escrito.
Si ests usando un modelo de cascada, olvidarse algo puede ser un error muy caro. No te dars cuenta hasta
que llegues a la prueba de sistema y veas que un requerimiento estaba mal o faltaba.
Entonces, el primer gran problema del modelo de cascada es que no es flexible. Algunas personas criticaron el
modelo de cascado por no permitir volver atrs para corregir los errores. Esto no es tan as: volver atrs est
permitido, pero es difcil y costoso.
El modelo de cascada tiene otras deficiencias. Algunas herramientas, mtodos, y actividades tiene fases del
ciclo de cascada; es difcil acomodarlas en el/las fases separadas del modelo. Para un desarrollo veloz, el modelo
de cascada puede prescribir una cantidad excesiva de documentacin. Si estas tratando de tener flexibilidad,
actualizar la especificacin se vuelve una tarea de tiempo completo. El modelo genera muy pocos signos visibles
de progreso antes del final. Esto puede crear la percepcin de un desarrollo lento, aunque no sea cierto. A los
clientes les gusta tener seguridades tangibles de que su proyecto va a estar terminado a tiempo.
En resumen, las debilidades del modelo de cascada pura lo vuelven poco acorde para desarrollos rpidos.
Incluso en los casos en que las ventajas superan a las desventajas, las cascadas modificadas pueden funcionar
mejor.
Code-and-Fix: El modelo code-and-fix, es un modelo que rara vez es til, pero es comn. Cuando usas code-andfix empiezas con una idea general de lo que vas a hacer. Tal vez tengas una especificacin formal, o tal vez no.
Despus usas cualquier combinacin de diseo informal, codificacin, depuracin y metodologas de prueba hasta
que tu producto este listo. Code-and-Fix es un modelo informal que es de uso comn porque es simple, no porque
funcione bien.
Este modelo tiene dos ventajas, Primero no tiene sobrecarga: no desperdicias tiempo planificando,
documentando, o con cualquier otra actividad que no sea codificar. Como saltas directamente al cdigo, podes
mostrar signos de progreso inmediatamente. Segundo, solo se requiere poca de experiencia.
Para proyectos chicos que van a durar poco, programas que sirvan como prueba de concepto, para demos o
para prototipos desechables es til. Para cualquier tipo de proyecto que no sea chico, este modelo es peligroso.
17
2.
3.
Evaluar alternativas
4.
Desarrollar los entregables para cada iteracin, y verificar que estn bien
5.
6.
En el modelo de espiral, las iteraciones del principio son las ms baratas Puedes modificar cada iteracin para
que se ajusten a las necesidades de tu proyecto.
En el modelo de espiral, empezs con poco y vas expandiendo el alcance del proyecto. Solo expands el alcance
despus de reducir los riesgos a un nivel aceptable.
Se puedes combinar este modelo con otros ciclos de vida en muchas formas y tambin se puede incorporar
otros ciclos de vida como iteraciones dentro del espiral.
Una de las ventajas ms importantes del modelo en espiral es que costo se incrementa como el riesgo se
reduce. Cuanto mas dinero y tiempo gastes, estars tomando menos riesgos. El modelo en espiral provee como
mnimo tanto control de administracin como el de cascada. Tens hitos al final de cada iteracin. Como el modelo
esta orientando a riegos, te provee indicaciones tempranas de cualquier riesgo insuperable. Si el proyecto no se
puede hacer por alguna razn, te dars cuanta rpido, y no te costar mucho. La nica desventaja de este modelo
es que es complicado.
Cascadas Modificadas: Las actividades del modelo de cascada pura son intrnsecas al desarrollo de software.
No se pueden evitar. La mayora de las debilidades de la cascada pura no son culpa de estas actividades
(arquitectura, requerimientos, diseo, codificacin) sino de tratar esas actividades como actividades separadas y
secuenciales. Esto se puede modificar con pequeos cambios: fases solapadas, reducir nfasis en la
documentacin o facilitar la vuelta atrs.
** Sashimi (Cascada con Fases Solapadas): Podes superar algunas limitaciones del modelo cascada al solapar
sus etapas, pero la aproximacin crea nuevos problemas.
El modelo tradicional de cascada permite un mnimo solapamiento entre fases, al final de la revisin de fase.
En el modelo de cascada pura, la documentacin ideal es la que un equipo le puede entregar a otro
completamente separado entre dos fases. La pregunta es Por qu? Si podes contar con el mismo personal entre
cada fase no necesitas tanta documentacin. Podes seguir una cascada modificada y reducir sustancialmente la
documentacin requerida.
El modelo sashimi no carece de programas. Como hay un solapamiento entre fases, los hitos son ms
ambiguos, y es ms difcil medir el progreso con precisin. Realizar actividades en paralelo puede llevar a la
incomunicacin, suposiciones errneas, e ineficiencia. Si ests trabajando en un proyecto chico y bien definido,
algo mas cercano a la cascada pura puede ser el modelo ms eficiente.
18
19
20
Cascada
Pura
Code-andFix
Espiral
Cascadas
modificadas
Prototipado
Evolutivo
Trabaja con
requerimientos
pobremente
entendidos
Pobre
Pobre
Excelente
Entre
aceptable y
excelente
Excelente
Pobre
Pobre
Excelente
Entre
aceptable y
excelente
Entre pobre y
aceptable
Produce un sistema
muy confiable
Excelente
Pobre
Excelente
Excelente
Aceptable
Produce un sistema
con una gran tasa de
crecimiento
Excelente
Entre pobre
y aceptable
Excelente
Excelente
Excelente
Administra riesgos
Pobre
Pobre
Excelente
Aceptable
Aceptable
Puede ser
restringido a un
tiempo predefinido
Aceptable
Pobre
Aceptable
Aceptable
Pobre
Tiene poca
sobrecarga
Pobre
Excelente
Aceptable
Excelente
Aceptable
Permite correcciones
a mitad de camino
Pobre
Entre pobre
y excelente
Aceptable
Aceptable
Excelente
Le provee visibilidad
al cliente
Pobre
Aceptable
Excelente
Aceptable
Excelente
Le provee visibilidad
al management
Excelente
Pobre
Excelente
Entre
aceptable y
excelente
Aceptable
Excelente
Excelente
Pobre
Entre pobre y
aceptable
Pobre
Desarrollo
Incremental
Desarrollo
Evolutivo
Diseo al
tiempo
Diseo con
herramientas
Software
Comercial
Trabaja con
requerimientos
pobremente
entendidos
Pobre
Entre
aceptable y
excelente
Entre pobre
y aceptable
Aceptable
Excelente
Pobre
Pobre
Pobre
Entre pobre y
excelente
Entre pobre y
excelente
Produce un sistema
muy confiable
Excelente
Entre
aceptable y
excelente
Aceptable
Entre pobre y
excelente
Entre pobre y
excelente
21
Excelente
Excelente
Entre
aceptable y
excelente
Pobre
N/A
Administra riesgos
Aceptable
Aceptable
Entre
aceptable y
excelente
Entre pobre y
aceptable
N/A
Puede ser
restringido a un
tiempo predefinido
Aceptable
Aceptable
Excelente
Excelente
Excelente
Tiene poca
sobrecarga
Aceptable
Aceptable
Aceptable
Entre aceptable y
excelente
Excelente
Permite correcciones
a mitad de camino
Pobre
Entre
aceptable y
excelente
Entre pobre
y aceptable
Excelente
Pobre
Le provee visibilidad
al cliente
Aceptable
Excelente
Aceptable
Excelente
N/A
Le provee visibilidad
al management
Excelente
Excelente
Excelente
Excelente
N/A
Aceptable
Aceptable
Pobre
Aceptable
Aceptable
Clase 3
Metodologa de Sistemas: Conjunto de pasos que me permiten construir un objeto cuyo buen uso solucionan un
problema aplicando una metodologa que aplica herramientas y tcnicas fundamentas en principios de las ciencias
basicas.
Modelo de anlisis: representacin parcial de la realidad para detectar los problemas que este tiene. A partir de
estor problemas se determinan posibles soluciones hasta que se prioriza una de ellas tras el estudio de factibilidad.
Entonces esa solucin se aplica en el modelo de diseo para comprobar si funciona. Al comprobar su
funcionamiento se obtiene el objeto concreto que soluciona el problema encontrado de la realidad. En Ing. De
sist. Se realizan modelos de modelos, que son metamodelos (se abstrae algo que ya es abstracto). Dentro de la
solucin si hay desarrollo de SW se introduce la ing del SW y surge la etapa de anlisis de requisitos.
Sistema: (elementos/interrelaciones/objetivo) **Objetivo: es lo que determina la existencia del sistema. Lo que lo
hace ser. El sistema tiene un solo obj del cual se decantan varios. Cuando cambia el obj, el sistema desaparece
como tal y/o se reformula. Vida til: es siempre limitada. Se divide (til/desarrollo), til: se contempla el
mantenimiento y sustitucin. Desarrollo: se realizan las etapas hasta el desarrollo.
Ciclo de vida: son los estados intermedios por los que va transitando algn elemento a lo largo de su vida til. El fin
es claro, es cuando caduca->se termina el objetivo. En cambio, el inicio es siempre ms difuso y confuso. Esto
tambin se traslada a los proyectos.
Mapa de actividades: es la combinacin de los hitos con las actividades bsicas definidas en el ciclo de vida. Este
mapa da como resultado el proceso de sistemas (procesa software).
Como surgen los proyectos: a-misin-objetivos: la misin se mantiene en el tiempo no as los objetivos (corto
plazo).b -planificacin estratgica: es la interpretacin de la misin y los objetivos para las distintas estrategias.
Ing en sistemas: el producto solucin es un paquete que suele incluir SW, para el desarrollo de estos objetivos se
llama a la ingeniera en SW (construir SW de calidad).
La Ing. conocimiento (informtica) es distinta a la ing. en sistemas de informacin (informacin en gral, puede o
no usar tecnologa informtica)
22
Factibilidad Tcnica
Evala si el hardware y el software requeridos estn disponibles para su uso, pueden comprarse
o desarrollarse y cuentan con las capacidades, funcionalidades y/o caractersticas necesarias para
soportar la solucin propuesta.
Evala si la organizacin cuenta con personal con la experiencia tcnica necesaria para
desarrollar, implementar, operar y mantener la solucin/sistema propuesto o si cuenta con la
capacidad de conseguirlo.
Responde a la preguntas:
23
Factibilidad Operativa
Factibilidad Econmica
Anlisis Econmico
Anlisis Econmico
Estimacin de costos
Personal Afectado
Software Requerido
Estimacin de beneficios
Beneficios Tangibles
Beneficios Intangibles
Payback Anlisis: Determina la cantidad de tiempo en el que se recuperar la inversin (todas las
compaas desean el menor payback posible).
Net present value (NPV): Determina el valor presente neto de una serie de cash flows. Ayuda a
valorar teniendo en cuenta el correr del tiempo si una inversin dar beneficios o no.
Si
Esto significa
Entonces
NPV > 0
NPV < 0
24
Costo de Clientes/Usuarios
Personal Tcnico
Software
Reparaciones
Actualizaciones
Reduccin de Costos
Operaciones manuales
Operaciones automatizadas
Decisiones Programadas
Crecimiento de Ganancias
Nuevos servicios
Diferenciacin de productos
Rapidez de entrega
Mejor calidad
Mayor market-share
Calidad de la informacin
Precisin
25
Tiempo
Integracin
Presentacin
Satisfaccin de Trabajo
Diseo participativo
Herramientas mejoradas
Reconocimientos Externos
26
27
28
29
30
31