Sie sind auf Seite 1von 31

Anlisis y Diseo de Sistemas

Examen privado Oral


TEORA GENERAL DE SISTEMAS
INTRODUCCION
La teora de la organizacin y la prctica administrativa han experimentado cambios sustanciales en aos
recientes. La informacin proporcionada por las ciencias de la administracin y la conducta ha enriquecido a la
teora tradicional. Estos esfuerzos de investigacin y de conceptualizacin a veces han llevado a descubrimientos
divergentes. Sin embargo, surgi un enfoque que puede servir como base para lograrla convergencia, el enfoque
de sistemas, que facilita la unificacin de muchos campos del conocimiento. Dicho enfoque ha sido usado por las
ciencias fsicas, biolgicas y sociales, como marco de referencia para la integracin de la teora organizacional
moderna.
El primer expositor de la Teora General de los Sistemas fue Ludwing von Bertalanffy, en el intento de
lograr una metodologa integradora para el tratamiento de problemas cientficos. Percibe que en varias disciplinas
de la ciencia moderna haban surgido concepciones y puntos de vista semejantes.
La meta de la Teora General de los Sistemas (TGS) no es buscar analogas entre las ciencias, sino tratar de
evitar la superficialidad cientfica que ha estancado a las ciencias. Para ello emplea como instrumento, modelos
utilizables y transferibles entre varios continentes cientficos, toda vez que dicha extrapolacin sea posible e
integrable a las respectivas disciplinas.
Los objetivos originales de la TGS enunciados por Bertalanffy son los siguientes:
1. Impulsar el desarrollo de una terminologa general que permita describir las caractersticas, funciones y
comportamientos sistmicos.
2. Desarrollar un conjunto de leyes aplicables a todos los comportamientos.
3. Promover una formalizacin (matemtica) de estas leyes.
Sobre estas bases se constituy en 1954 la Sociedad para la Investigacin General de Sistemas, cuyos
objetivos fueron los siguientes:
1. Investigar el isomorfismo de conceptos, leyes y modelos en varios campos y facilitar la transferencia entre
aquellos.
2. promocionar y desarrollar modelos tericos en campos que carecen de ellos.
3. Reducir la duplicacin de los esfuerzos tericos.
4. Promover la unidad de la ciencia a travs de principios conceptuales y metodolgicos unificadores

1.
2.
3.

La TGS se fundamenta en tres premisas bsicas:


Los sistemas, existen dentro de sistemas. Hay una jerarqua de sistemas: suprasistema, sistema y
subsistema.
Los sistemas son abiertos
Las funciones de un sistema dependen de su estructura.

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:

Anlisis y Diseo de Sistemas


Examen privado Oral
Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o informacin.
Las entradas constituyen la fuerza de arranque que suministra al sistema sus necesidades operativas. Las entradas
pueden ser:
En serie: es el resultado o la salida de un sistema anterior con el cual el sistema en estudio est
relacionado en forma directa.
Aleatoria: es decir, al azar, donde el termino "azar" se utiliza en el sentido estadstico. Las entradas
aleatorias representan entradas potenciales para un sistema.
Retroaccin: es la reintroduccin de una parte de las salidas del sistema en s mismo.
Proceso:
El proceso es lo que transforma una entrada en salida, como tal puede ser una mquina, un individuo, una
computadora, un producto qumico, una tarea realizada por un miembro de la organizacin, etc. En la
transformacin de entradas en salidas debemos saber siempre como se efecta esa transformacin. Con
frecuencia el procesador puede ser diseado por el administrador. En tal caso, este proceso se denomina "caja
blanca". No obstante, en la mayor parte de las situaciones no se conoce en sus detalles el proceso mediante el cual
las entradas se transforman en salidas, porque esta transformacin es demasiado compleja. Diferentes
combinaciones de entradas o su combinacin en diferentes rdenes de secuencia pueden originar diferentes
situaciones de salida. En tal caso la funcin de proceso se denomina una "caja negra".
Caja Negra:
La caja negra se utiliza para representar a los sistemas cuando no sabemos que elementos o cosas componen al
sistema o proceso, pero sabemos que a determinadas entradas corresponden determinadas salidas y con ello
poder inducir, presumiendo que a determinados estmulos, las variables funcionarn en cierto sentido.
Salidas:
Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas. Al igual que las entradas
estas pueden adoptar la forma de productos, servicios e informacin. Las mismas son el resultado del
funcionamiento del sistema o, alternativamente, el propsito para el cual existe el sistema. Las salidas de un
sistema se convierten en entrada de otro, que la procesar para convertirla en otra salida, repitindose este ciclo
indefinidamente.
Relaciones:
Las relaciones son los enlaces que vinculan entre s a los objetos o subsistemas que componen a un sistema
complejo. Podemos clasificarlas en:
Simbiticas: es aquella en que los sistemas conectados no pueden seguir funcionando solos. A su vez
puede subdividirse en unipolar o parasitaria, que es cuando un sistema (parsito) no puede vivir sin el otro
sistema (planta); y bipolar o mutual, que es cuando ambos sistemas dependen entre si.
Sinrgica: es una relacin que no es necesaria para el funcionamiento pero que resulta til, ya que su
desempeo mejora sustancialmente al desempeo del sistema. Sinergia significa "accin combinada". Sin
embargo, para la teora de los sistemas el trmino significa algo ms que el esfuerzo cooperativo. En las
relaciones sinrgicas la accin cooperativa de subsistemas semi-independientes, tomados en forma
conjunta, origina un producto total mayor que la suma de sus productos tomados de una manera
independiente.
Superflua: Son las que repiten otras relaciones. La razn de las relaciones superfluas es la confiabilidad.
Las relaciones superfluas aumentan la probabilidad de que un sistema funcione todo el tiempo y no una
parte del mismo. Estas relaciones tienen un problema que es su costo, que se suma al costo del sistema
que sin ellas puede funcionar.
Contexto:
Un sistema siempre estar relacionado con el contexto que lo rodea, o sea, el conjunto de objetos exteriores al
sistema, pero que influyen decididamente a ste, y a su vez el sistema influye, aunque en una menor proporcin,
influye sobre el contexto; se trata de una relacin mutua de contexto-sistema. Tanto en la Teora de los Sistemas
como en el mtodo cientfico, existe un concepto que es comn a ambos: el foco de atencin, el elemento que se
asla para estudiar. El contexto a analizar depende fundamentalmente del foco de atencin que se fije. Ese foco de
atencin, en trminos de sistemas, se llama lmite de inters. Para determinar este lmite se consideraran dos
etapas por separado: a) La determinacin del contexto de inters.
b) La determinacin del alcance del lmite de inters entre el contexto y el sistema.

Anlisis y Diseo de Sistemas


Examen privado Oral
a) Se suele representar como un crculo que encierra al sistema, y que deja afuera del lmite de inters a la parte
del contexto que no interesa al analista. b) Es lo que hace a las relaciones entre el contexto y los sistemas y
viceversa. Es posible que slo interesen algunas de estas relaciones, con lo que habr un lmite de inters
relacional.
Determinar el lmite de inters es fundamental para marcar el foco de anlisis, puesto que slo ser considerado lo
que quede dentro de ese lmite. Entre el sistema y el contexto, determinado con un lmite de inters, existen
infinitas relaciones. Generalmente no se toman todas, sino aquellas que interesan al anlisis, o aquellas que
probabilsticamente presentan las mejores caractersticas de prediccin cientfica.

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.

Anlisis y Diseo de Sistemas


Examen privado Oral

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

Anlisis y Diseo de Sistemas


Examen privado Oral
controla parcialmente, desarrollan actividades aplicando recursos en pos de ciertos valores comunes. Subsistemas
que forman la Empresa:
a) Subsistema psicosocial: est compuesto por individuos y grupos en interaccin. Dicho subsistema est
formado por la conducta individual y la motivacin, las relaciones del status y del papel, dinmica de grupos y los
sistemas de influencia.
b) Subsistema tcnico: se refiere a los conocimientos necesarios para el desarrollo de tareas, incluyendo
las tcnicas usadas para la transformacin de insumos en productos.
c) Subsistema administrativo: relaciona a la organizacin con su medio y establece los objetivos,
desarrolla planes de integracin, estrategia y operacin, mediante el diseo de la estructura y el establecimiento
de los procesos de control.

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

Anlisis y Diseo de Sistemas


Examen privado Oral
implementacin de procesamiento automtico de informacin, establecimiento de seguridades a diferentes
niveles, y la auditabilidad de las actividades, especficamente identificando quin hizo qu, cuando y desde
donde. Las bases de datos actualmente proveen herramientas como la integridad referencial, sin embargo si no
hay conciencia en la necesidad de la calidad sobre la velocidad o facilidad de uso para el usuario, es probable
que el sistema de informacin quede produciendo a altas velocidades cifras irrelevantes que ocasionen errores
en las decisiones.
La ltima caracterstica necesaria es que la informacin pueda ser explicable. Es decir, se debe poder ver
a todos los niveles de detalle el origen de toda informacin. Para cada total, se tienen tambin los valores de los
componentes de estos totales. Adems se deber poder analizar la informacin en el tiempo por lo que se
requiere acceso a la informacin tanto presente como histrica.
No es difcil planificar estas caractersticas dentro de un sistema de informacin si se contemplan desde
el inicio. Es extremadamente complejo tratar de incorporarlas en sistemas ya existentes que non permiten este
tipo de ajustes, o que hacerlos costara ms que reemplazar el sistema.

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.

Anlisis y Diseo de Sistemas


Examen privado Oral

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.

3) Orientado a Objetos: se superponen aun ms el anlisis, el diseo y la implementacin.


Menos Tiempo, Costos e impaciencia.
Se superponen el modelo lgico y el fsico.
Hay que hacer uso de la abstraccin para realizar el modelo lgico.
Abstraccin: proceso mental que consiste en aislarnos de la realidad para poder entender el problema sin pensar
en las limitaciones tecnolgicas (lenguaje de programacin, condicionamientos de hardware, sistema operativo o
de base de datos)

Ventajas entre el 1 y el 2-3


Mayor participacin del usuario
Mayor comunicacin con el usuario
Permite una menor cantidad de error
Mejor definicin de los requisitos de mi sistema
Mayor documentacin del sistema (para el mantenimiento).
Top Down: Voy de lo general a lo particular, desde las funciones ms abarcativas a los subprocedimientos. Defino
al sistema como una caja negra, sin mayor detalle, y luego lo voy detallando cada vez ms.
En el enfoque estructurado, por ejemplo, realizo el diagrama de contexto y defino al sistema como un
nico proceso, que luego exploto para obtener un nuevo DFD que me da un mayor detalle del sistema. No
obstante sigo explotando los procesos hasta llegar al nivel de detalle que sea suficiente.
Bottom Up: voy de lo particular a lo general. Se definen las entidad y como interactan con detalle. A medida que
avanzo en el anlisis, las voy enlazando con otras para formar componentes ms grandes, que a su vez tambin se
enlazan, hasta llegar a formar el sistema completo.
Responde a la estructura orientada a objetos.

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.

Anlisis y Diseo de Sistemas


Examen privado Oral

Ventajas de utilizar un modelo fsico para realizar un DFD.


1. Aclarar qu procesos son manuales y cules son automatizados.
2. Describir los procesos con mayor detalle los DFDs lgicos.
3. Distribuir en un orden particular los procesos que se deben realizar.
4. Identificar los almacenes de datos temporales.
5. Especificar los nombres reales de archivos y documentos impresos.
6. Agregar controles para asegurar que los procesos se realicen adecuadamente.
Componentes de un DFD:

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

Anlisis y Diseo de Sistemas


Examen privado Oral

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.

Elemento de Datos: es la minima expresin que llego a definir.


Estructura de Datos: conjunto de elementos de datos relacionados en forma lgica.

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

Anlisis y Diseo de Sistemas


Examen privado Oral

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:

Cardinalidad: Establece el n mximo de instancias que se relacionan entre dos entidades


distintas. ( 1 o muchas de A, con 1 o muchas de B).
Modalidad: Establece el n minimo de instancias que se relacionan entre dos entidades distintas.
La relacion puede ser obligatoria (debe relacionarse al menos 1) u opcional (puede relacionarse
alguna o ninguna).

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.

Relacin unaria: cuando se relaciona consigo mismo (comportamiento recursivo).

no interesa el tipo de dato.


no refleja el comportamiento del sistema.

Ventajas del DER sectorizado:


movilidad de la base de datos
menos impacto a la hora de realizar cambios en una entidad determinada (que no impacte en la totalidad
de los datos).
Mayor flexibilidad del sistema.
DEBE ESTAR TODO LO ALMACENADO.
Realizar el DER y el DD sirven para balancear el sistema.
Balanceo: comparar los distintos diagramas para poder refinar y, a su vez, profundizar el anlisis. Mediante el
balanceo, corregimos errores y agregamos los datos que nos falta a nuestro sistema.
Paradigma Orientado a Objetos:
-Qu utiliza? En este enfoque, el principal bloque de construccin es el objeto que contiene datos y operaciones
para operar sobre los mismos. Decimos entonces que dichos datos y procedimientos estn encapsulados.
-Por qu es conveniente utilizarlo?
Facilita la construccin de software y mantenimiento del sistema (gracias al encapsulamiento de los
datos, solo corrijo errores en determinados objetos).
Mejora la captura y validacin de requisitos. Genero modelos ajustados al dominio del problema (es decir,
se ajusta mejor a las reglas de negocio).
Time to market: tiempo de respuesta que el usuario quiere.
Utilizacin de prototipos.
Mayor productividad (ms cdigo en menos tiempo, con menor costo y menor probabilidad de error)
gracias a la reutilizacin de Cdigo.

10

Anlisis y Diseo de Sistemas


Examen privado Oral
o

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

Instancia u ocurrencia: es una manifestacin concreta de una clase.


Herencia: el mecanismo mediante el cual se puede crear una nueva clase partiendo de una existente,
donde la nueva clase hereda las caractersticas de la existente aunque pudiendo aadir o modificar las que
tiene. Ayuda a la reutilizacin a nivel de datos y a reducir la redundancia
o Herencia Simple: toma las caractersticas de uno y solo un objeto padre
o Herencia multiple: puede tomar las caractersticas de ms de un objeto padre
Poliformismo: hace referencia a la posibilidad de que dos mtodos implementen distintas acciones, aun
teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o los parmetros que recibe.
Reutilizacin a nivel de procedimientos
Encapsulamiento: Es la idea de que un observador no ve todos los aspectos (internos) de un objeto sino
solamente aquellos que le sirven para interactuar con l.
Jerarqua: se refiere a la relacin de herencia entre objetos o clases. Una superclase tiene mayor jerarqua
que una subclase de ella.
Modularidad: es la capacidad del sistema de ser visto como la unin de partes(mdulos) que interactan
(se relacionan) entre si persiguiendo un objetivo en comn. Relaciones: Tiene y Usa.

-Es importante administrar un catlogo de objetos:


Catalogo de objetos: objetos predefinidos que uso sin necesidad de tener que crearlos.
o Tengo que aprovechar la Potencia de esta herramienta
o Ventajas: time to market, reduzco errores a la hora de codificar.
o Desventajas: licencia cara.

11

Anlisis y Diseo de Sistemas


Examen privado Oral
-Se da una comn unin entre el analista (nosotros) y el experto en el dominio (usuario) en la etapa de captura y
validacin de los requisitos.
-Etapas de O.O y relacin entre conceptos.

ANALISIS (que?): Investigar el problema una vez adquirido el dominio


Identificar y describir cuales van a ser los objetos que voy a utilizar

DISEO(como plantearlo): planteo la solucin lgica del problema


definir el comportamiento de cada objeto

CONSTRUCCIN (como lo paso a cdigo): construccin o generacin de cdigo definir las


relaciones entre los objetos (mtodos y mensajes)
IMPLEMENTAR

-Desventajas: Conceptual: la gente no esta acostumbrada a trabajar con objetos


Obliga a conocer las herramientas que vamos a utilizar.

UML (Lenguaje unificado de modelado)


-Es un lenguaje estndar para escribir planos de software.
-Ventajas
Es Estndar: permite unicidad y estandarizacin a la hora de hacer las notaciones, en cualquier
parte del mundo tiene la misma interpretacin.
No prescriptivo: no nos obliga a realizar de una determinada manera
Trabaja con Mltiples vistas del sistema
o Vista de casos de uso o de usuario: descripcin del comportamiento del sistema tal como
es percibido por usuarios finales, analistas y encargados de prueba.
o Vista de diseo: comprende las clases, interfaces y colaboraciones que forman el
vocabulario del problema y la solucion.
o Vista de procesos: cubre el funcionamiento, capacidad de crecimiento y el rendimiento
del sistema
o Vista de implementacin: comprende los componentes y los archivos que un sistema
utiliza para hacer disponible el sistema fisico
o Vista de despliegue: se preocupa principalmente de la distribucin, entrega e instalacin
de las partes que constituyen un sistema.
Existe gran variedad y cantidad de herramientas case para utilizar.
Nos da una amplia visin del proyecto
Es independiente de las herramientas de desarrollo y de las caracteristicas del proyecto.
Permite una mejor documentacin (mejor soporte) y una mejor comunicacin.
Hay un mayor gasto de tiempo en anlisis y en el diseo pero menos en construccin,
implantacin y mantenimiento ya que se realizan menos correcciones.
Alta Reutilidad.
-

Esta directamente relacionado con la programacin orientada a objetos.


Tiene un enfoque Bottom up.
Basicamente, define 3 tipos de diagramas:
De estructura: se concentran en la parte esttica del modelo y representan cosas que son
conceptuales o materiales.
o Diagrama de clases (muestra las clases, sus contenidos y la relacin entre ellos)
o Diagrama de objetos (muestra las instancias de las clases)
o Diagrama de componentes (muestra los elementos fsicos del sistema, que son todos los
tipos de elementos de software, y sus relaciones, que son los servicios ofrecidos entre
componentes)

12

Anlisis y Diseo de Sistemas


Examen privado Oral
o

Diagrama de despliegue ( configuracin de los componentes hardware y la distribucin de


los procesos en los mismos)
De comportamiento: son la parte dinmica de un modelo y representan el comportamiento en el
tiempo y en el espacio
o Diagrama de casos de uso: se utiliza para ilustrar los requerimientos funcionales del sistema,
y muestra como reacciona el mismo en respuesta a eventos que en l se producen por parte
de los actores.
Marca la frontera del sistema
El actor puede ser:
Rol de usuario
Apis
Sistema
Tiempo
til como documentacin de soporte
sirve para: capturar/definir/documentar/comunicar y validar requerimientos
se ocupa del QUE? A grandes rasgos y no del como.
o Diagrama de actividades (muestra el dibujo del algoritmo)
o Diagramas de estados ( Describe todos los estados posibles en los que puede entrar un
objeto en particular y la manera que cambia el estado del objeto como resultado de los
eventos que llegan a l. Vemos el comportamiento del sistema)
De interaccin: enfocado en los mensajes entre las partes.
o Diagramas de colaboracin (muestra los objetos en formato de red y sus relaciones entre s.
El tiempo no es explcito)
o Diagramas de secuencia (muestra las interacciones entre objetos de una aplicacin a travs
del tiempo)
o Diagramas de frecuencia. (muestra el orden de los mensajes/interacciones por tiempo)

Riesgos en el desarrollo de software: una oportunidad, no un problema


Antecedentes
Un riesgo no es un problema. Mejor dicho un riesgo es algo que puede ocurrir en el futuro: una
posibilidad, no una certeza. Para ser tcnicamente precisos, hay dos factores que comprenden a un riesgo:
1.

Probabilidad de ocurrencia.

2.

Consecuencias negativas de que ocurra.

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

inaceptable para el cliente.

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.

Llamamos a estos tres elementos administracin de riesgos. El corazn de la administracin de riesgos


es la toma de decisiones bajo incertidumbre. Se trata de ser activos no pasivos.

13

Anlisis y Diseo de Sistemas


Examen privado Oral
Estrategia del Programa de Riesgos
Elegimos concentrarnos en los riesgos tcnicos del desarrollo de software porque se entiende muy poco
de este tema. Sin embargo, para administrar los riegos adecuadamente se requiere de una perspectiva del
sistema, porque el software nunca existe en el vaco. Reconociendo esto, elegimos concentrarnos en los riesgos
tcnicos del software en el contexto de todo el sistema.

Fases del Programa de Riesgos


En la Fase 1 determinamos que la administracin de riesgos seria un rea efectiva.
En la Fase 2, desarrollamos un paradigma de administracin de riesgos y un proceso de evaluacin de
riesgos.
En la Fase 3, continuamos refinando nuestro paradigma, sus mecanismos y mtodos. El nfasis de la Fase
3 va desde la pruebas con evaluacin de riesgos hasta la esfuerzos piloto de mejora de capacidades.
Finalmente, en la Fase 4, vamos a cambiar de trabajar con programas individuales para trabajar con
organizaciones enteras.
Para el final de la Fase 4, habremos desarrollado y probado una aproximacin balanceada para la
administracin de riesgos del software, usando mtodos cualitativos y cuantitativos.

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.

Establecer una base para dirigir el riesgo relacionado con el software.

2.

Fortalecer la habilidad de las organizaciones para evaluar y administrar el riesgo relacionado con
el software.

Podemos resumir nuestra estrategia como:


1.

Definir la administracin de riesgos de software, investigando y entrevistando.

2.

Desarrollar un paradigma de administracin de riegos efectivo, probando y prototipando con


programas individuales.

3.

Transferir la administracin de riesgos de software desde programas individuales a una


comunidad mayor.

Paradigma de administracin de riesgos


Podemos resumir los elementos de nuestro paradigma como:

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.

Planificacin. Convertir la informacin en decisiones y acciones (presentes y futuras)

Seguimiento. Monitorear el estado de los riesgos y las acciones tomadas contra los riegos.

Control. Corregir las desviaciones de las acciones planeadas.

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

Anlisis y Diseo de Sistemas


Examen privado Oral
El anlisis de riesgos. El anlisis es la conversin de los datos del riesgo en informacin administrativa.
Cada riesgo debe ser comprndolo lo suficiente como para permitirle a un lder tomar decisiones. El anlisis toma
los riesgos conocidos, y ubica la informacin en las manos del quien toma las decisiones.
La planificacin de riesgos es necesaria despus de que un riesgo es identificado y analizado. Este
elemento incluye desarrollar acciones para dirigir cada riesgo, priorizando las acciones, y organizar el plan general
de administracin de riesgos. Un plan de accin para un riesgo puede tomar muchas formas, por ejemplo:

Mitigar el impacto del riesgo desarrollando un plan de contingencia.

Evitar el riesgo cambiando el diseo del producto.

Aceptar el riesgo y no tomar accin alguna, aceptando la consecuencia si ocurre.

Estudiar el riesgo un poco mas, para obtener ms informacin y determinar mejor la


incertidumbre y la perdida asociada al mismo.

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:

Aplica los mecanismos de identificacin y anlisis de riesgos elegidos.

Consolida los resultados de los diferentes mecanismos.

Identifica posibles reas de riesgo para continuar investigando.

Informa a los integrantes del programa lo que se encontr en la Vista Rpida.

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:

Aplica a fondo los mecanismos de identificacin y anlisis de riesgos elegidos.

Analiza los riesgos identificados

Identifica posibles acciones que pueden tomarse.

15

Anlisis y Diseo de Sistemas


Examen privado Oral

Informa a los integrantes del programa lo que se encontr en la Investigacin.

Otra vez los resultados de la investigacin le pertenecen al administrador del programa.


Vista Rpida

Entrada

Participantes

Actividades

Investigacin

Participantes

Participantes

Propuesta

Documentos de diseo detallado

Documentos de requerimientos

Documentos de requerimientos

Documentos de diseo del sistema

Documentos de diseo del sistema

Ingenieros de sistemas

Ingenieros de sistemas

Ingenieros de software

Ingenieros de software

Especialistas del rea funcional

Especialistas del rea funcional

Administrador del programa

Administrador del programa

Identificacin

Identificacin

Anlisis (limitado)

Anlisis (limitado)
Planificacin de las acciones

Salida

reas de riesgo

Especificacin de riesgos

Posibles fuentes del riesgo

Posibles acciones

Tabla 1. Comparacin de la Vista Rpida y la Investigacin


Una vez que el periodo de Investigacin se termina, la evaluacin concluye informando los resultados de
la Vista Rpida y la Investigacin en un solo informe para el administrador del programa. Este paso de reporte es
solo el principio de nuestro proceso continuo. Nuestra estrategia es continuar trabajando con los clientes
evaluados para evaluar el impacto a largo plazo de la administracin de riesgos y para asistir a nuestros clientes a
adoptar la administracin de riesgos como una tarea rutinaria y regular.
Conclusin
El riesgo no tiene que ser negativo. De hecho, conocer nuestros riesgos, nos brinda oportunidades para
administrar y mejorar nuestras posibilidades de xito. Sin embargo, est visin del riesgo solo es posible en una
cultura conciente del riesgo donde los riesgos pueden ser comunicados libremente y abiertamente. Es ms,
cambiar la forma en que las personas trabajan y piensan no es una tarea fcil. Solo puede ser lograda
demostrando que la administracin de riesgos funciona, y demostrndolo de una manera que no sea amenazante
o agobiante para los lderes o desarrolladores.
La administracin de riesgos debe volverse una parte rutinaria dentro del proceso de desarrollo de
software. La clave para reducir las sorpresas en nuestros trabajos de desarrollo de software es incorporar un
enfoque disciplinado y sistemtico para administrar el riesgo tcnico dentro del proceso de desarrollo de
software. No podemos escapar al riesgo, pero la administracin de riesgos nos puede dar la posibilidad de manejar
de forma ms efectiva el futuro.

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

Anlisis y Diseo de Sistemas


Examen privado Oral
etapas ms tempranas y baratas del proyecto. Provee la estabilidad a los requerimientos que los desarrolladores
siempre ansan. Si estas construyendo un mantenimiento bien definido de un producto existente o migrando un
producto existente a otra plataforma, el modelo cascada puede ser la eleccin correcta para un desarrollo veloz.
Este modelo ayuda a minimizar el esfuerzo de planificacin porque puedes hacerla toda al principio. No provee
resultados tangibles en forma de software hasta el final, pero la documentacin que genera provee indicadores
significativos del progreso.

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

Anlisis y Diseo de Sistemas


Examen privado Oral
Espiral: Modelo muy sofisticado orientado a los riesgos que divide el proyecto en miniproyectos. Cada
miniproyecto mitiga uno o ms de los riesgos ms importantes hasta que todos hayan sido mitigados. Despus
que los riesgos ms importantes hayan sido mitigados, el espiral termina como un ciclo de vida en cascada.
La idea bsica es que empezs en una escala menor en el medio de la espina, exploras los riesgos, haces un
plan para manejarlos y luego te preparas para la prxima iteracin. Sacas una capa del rollo, te aseguras que es
lo que queras y empezs a trabajar en capa siguiente.
Cada iteracin involucra los seis pasos
1.

Determinar objetivos, alternativas y restricciones

2.

Identificar y resolver riesgos

3.

Evaluar alternativas

4.

Desarrollar los entregables para cada iteracin, y verificar que estn bien

5.

Planificar la prxima iteracin

6.

Prepararse para la prxima iteracin (si decides que va a haber otra)

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.

Cascada con Subproyectos


Otro problema con el modelo de cascada desde un punto de vista de desarrollo veloz es que se supone que
debes terminar completamente con el diseo arquitectnico antes de empezar con el diseo detallado, y se
supone que deber terminar completamente el diseo detallado para pasar a la codificacin y depuracin.

18

Anlisis y Diseo de Sistemas


Examen privado Oral
Por qu demorar la implementacin de las reas que son fciles de disear solo porque estamos esperando
el diseo de un rea difcil? Si la arquitectura dividi el problema en subsistemas independientes, podes separar en
subproyectos, cada uno puede proceder a su forma.
El principal riesgo de esta aproximacin son las interdependencias no detectadas.
Cascada con reduccin de riesgos
Otra de las debilidades el modelo de cascada es que requiere que definas completamente los riesgos antes de
empezar el diseo arquitectnico, lo cual parece razonable exceptuando que tambin requiere que los entiendas
por completo antes de empezar con el diseo arquitectnico. Modificar la cascada podes poner una espiral de
reduccin de riesgo para mitigar los riesgos asociados a los requerimientos. Podes desarrollar un prototipo de la
interfaz de usuario, entrevistar a los usuarios, filmar a los usuarios interactuando con el sistema viejo, o usar
cualquier otra practica de obtencin de requerimientos que pienses que es apropiada.
Prototipado Evolutivo
El prototipado evolutivo es un ciclo de vida en el cual desarrollas el concepto del sistema a medida que avanzas
en el proyecto. Usualmente empezas desarrollando los aspectos ms visibles del sistema. Le mostrar esa parte del
sistema al cliente y luego continuas desarrollando el prototipo basndote en la respuesta que recibs. En un cierto
punto, terminas cualquier trabajo que quede y lanzas el prototipo como producto final.
El prototipado evolutivo es especialmente til cuando es imposible saber al principio del proyecto cuanto
tomar crear un producto aceptable. Ni siquiera sabs cuantas iteraciones te va a llevar. Este problema es
mitigado con el hecho de que los clientes pueden ver signos de progreso estables y entonces tienden a estar
menos nerviosos sobre obtener un producto.
Desarrollo Incremental (Staged Delivery)
La entrega en etapas es otro ciclo de vida en el cual le mostrs software al cliente en etapas sucesivas. Pero a
diferencia del prototipado evolutivo, cuando usas entrega en etapas, sabes exactamente que vas a construir
cuando empezs.
La principal ventaja de este modelo es que permite poner funcionalidad til en las manos de los clientes ms
temprano que si entregars el 100 por ciento al final del proyecto. Si planeas tus etapas cuidadosamente, quizs
puedas entregar la funcionalidad ms importante al principio, y los clientes puedan empezar a usar el software en
ese punto.
La principal desventaja de este modelo es que no funcionar con una planificacin cuidadosa tanto a nivel
tcnico como administrativo.
Diseo al tiempo (Design-to-Schedule)
Este modelo es similar al desarrollo incremental en el sentido en que planificas el producto en diferentes
etapas. La diferencia es que al principio no sabes si vas ha hacer todo. Puede que tengas 5 etapas planificadas, por
solo llegues a terminar la tercera porque tienes una fecha de entrega inamovible.
Este ciclo de vida puede ser una estrategia viable para asegurar que vas tener un release para una fecha en
particular.
Uno de los elementos crticos es este ciclo de vida es que le es prioridades a las funcionalidades y planifiques tu
etapas para que en las primeras contengan las funcionalidades con mas prioridad.
La principal desventaja de esta aproximacin es que si no pasaste por todas las etapas, desperdiciaste el
tiempo especificando, realizando la arquitectura y diseando las funcionalidades que no entregaste.
Desarrollo evolutivo
Es un ciclo de vida en el cual desarrollas una versin completa de tu producto, se lo mostrs al cliente, y lo
refinas basado en su respuesta. Este modelo te da el control del desarrollo incremental y la flexibilidad del
prototipo evolutivo.

Diseo con Herramientas (Design-to-tools)

19

Anlisis y Diseo de Sistemas


Examen privado Oral
El modelo diseo con herramientas puede proveer una velocidad excepcional de desarrollo, pero tpicamente
provee menos control sobre la funcionalidad de tus productos que otros ciclos de vida te daran.
Al decir herramientas, quiero decir cdigo y bibliotecas, generadores de cdigo, lenguajes de desarrollo
veloz, y otras herramientas de software que reducen drsticamente el tiempo de implementacin.
Software Comercial
Una alternativa que a veces es ignorada por el alboroto que provoca un nuevo sistema es la de comprar
software comercial. Este tipo de software raramente va a satisfacer tus necesidades, pero consider los siguientes
puntos.
Est disponible inmediatamente. En el tiempo entre que compras en software comercial y que puedas
entregarle el sistema hecho a medida, los usuarios estarn provistos de por lo menos algunas funcionalidades
valiosas. Pueden aprender a rodear las limitaciones del producto en el tiempo en que te tomara desarrollar el
sistema a medida. A medida que pase el tiempo, el software comercial puede ser revisado para satisfacer mejor
tus necesidades.
Eligiendo el Ciclo de Vida ms Veloz Para tu Proyecto
A continuacin estn las descripciones detalladas de cada criterio descrito en la Tabla 1:
Trabaja con requerimientos pobremente entendidos significa que tan bien el ciclo de vida trabaja cuando vos o
tu cliente no entienden bien los requerimientos del sistema o cuando tu cliente es propenso a cambiar los
requerimientos. Indica que tan bien esta hecho esta el modelo para el desarrollo de software exploratorio.
Trabaja con una arquitectura pobremente entendida significa que tan bien trabaja el modelo cuando estas
desarrollando en una nueva rea o cuando estas desarrollando en un rea familiar pero funcionalidades
desconocidas.
Produce un sistema muy confiable se refiere a cuantos defectos puede tener un sistema desarollado con este
ciclo de vida.
Produce un sistema con una gran tasa de crecimiento se refiere a que tan fcil te ser modificar el sistema en
su tamao y diversidad durante su vida. Esto incluye modificar el sistema en formas no anticipadas por los
diseadores originales.
Administra riesgos se refiere a la capacidad del modelo para identificar y controlar riesgos para el tiempo,
producto y otros.
Puede ser restringido a un tiempo predefinido significa que tan bien soporta el modelo la entrega de software
en una fecha inamovible.
Tiene poca sobrecarga se refiere a la cantidad de administracin y sobrecarga tcnica requerida para usar el
modelo con eficiencia. La sobrecarga incluye planificacin, seguimiento de del progreso, produccin de
documentos, y cualquier otra actividad que no est directamente involucrada con producir software.
Permite correcciones a mitad de camino se refiere a la habilidad de cambiar aspectos significativos del
producto a mitad de camino.
Le provee visibilidad al cliente se refiere a que tanto el modelo genera automticamente signos de progreso
que el cliente puede usar para saber el estado.
Le provee visibilidad al management se refiere a que tanto el modelo genera automticamente signos de
progreso que el management puede usar para saber el estado.
Requiere una poca sofisticacin del manager o el desarrollador se refiere al nivel de educacin y capacitacin
que necesitas para usar satisfactoriamente el modelo. Eso incluye el nivel de sofisticacin que necesitas para medir
el progreso, evitar riesgos inherentes al modelo, evitar desperdiciar el tiempo usando el modelo y darte cuenta de
los beneficios que hicieron que lo eligieras.

20

Anlisis y Diseo de Sistemas


Examen privado Oral
Capacidad del ciclo
de vida

Cascada
Pura

Code-andFix

Espiral

Cascadas
modificadas

Prototipado
Evolutivo

Trabaja con
requerimientos
pobremente
entendidos

Pobre

Pobre

Excelente

Entre
aceptable y
excelente

Excelente

Trabaja con una


arquitectura
pobremente
entendida

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

Requiere una poca


sofisticacin del
manager o el
desarrollador

Excelente

Excelente

Pobre

Entre pobre y
aceptable

Pobre

Fortalezas y debilidades de cada ciclo de vida.

Capacidad del ciclo


de vida

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

Trabaja con una


arquitectura
pobremente
entendida

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

Anlisis y Diseo de Sistemas


Examen privado Oral
Produce un sistema
con una gran tasa de
crecimiento

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

Requiere una poca


sofisticacin del
manager o el
desarrollador

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

Anlisis y Diseo de Sistemas


Examen privado Oral
Tipos de ciclo de vida: no por aplicar el mismo ciclo de vida se obtiene el mismo resultado. Es una gua que se
aplica de acuerdo al contexto y a lo que tiene, as como tambin las caractersticas del objeto.
Cascada: orden estructurado de pasos que concuerdan con los de metodologa de sistemas. Para pasar al
siguiente paso hay que terminar el anterior. Ventajas: simple/lgico. Desventajas: rigidez es por eso que se
adornan las cascadas (cascadas con ciclos, cascadas con retroceso, etc.).
Code-and-fix (no ciclo): es un no ciclo. Se aplica cuando no se aplica ningn ciclo. Puede ser posible si vos sos el
usuario, el desarrollo, etc todo junto. No se debe hacer.
Prototipo (herramienta): es una cascada. De esta manera se obtiene informacin valiosa por parte del cliente. Es
una herramienta que se puede aplicar en distintos ciclos de vida para darle una idea o un cliente. Puede ser
evolutivo o desechable.
Spiral: trabaja con prototipos, son ciclos que van conteniendo unos a otros e incluyen el concepto de riesgo. Se
utilizan las mtricas para saber cuantas vueltas voy a dar. Despus que se disea, el desarrollo, implementacin,
mantenimiento y sustitucin es una cascada. Los riesgos se analizan antes de dar otra vuelta ms para ver si vale la
pena. No es para desarrollos simples. ase de Florencia Pollo

Estudio de Factibilidad para un Proyecto de SW


Estudio de Factibilidad: medida de cuan beneficioso o prctico es desarrollar o adquirir un sistema para una
organizacin.
Cundo realizamos el Estudio de Factibilidad?

Tipos de Estudios de Factibilidad

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:

La solucin es tcnicamente implementable?

23

Anlisis y Diseo de Sistemas


Examen privado Oral

Puede integrarse con el resto de los sistemas de la organizacin?

Podemos llevar adelante la solucin?

existe el hardware y software requeridos?

Pueden ser desarrollados o adquiridos?

Factibilidad Operativa

Puede absorber el cambio la organizacin?

Determinar que podr ser operable dentro de la organizacin

Problemas Humanos y Sociales

Existe soporte gerencial?

Hay resistencia al cambio de los operadores y usuarios?

Hay conflictos organizacionales y polticos?

Cumple con los aspectos legales y las regulaciones actuales vigentes?

Factibilidad Econmica

Se analiza si se justifica la implementacin de la solucin en base a anlisis costo/beneficio.

Cul es la justificacin de negocio?

Anlisis Econmico

Anlisis Econmico

Estimacin de costos

Costos de Adquisicin o Desarrollo (por nica vez)

Costos de Mantenimiento (continuos)

Personal Afectado

Software Requerido

Equipamiento / Hardware Requerido

Estimacin de beneficios

Beneficios Tangibles

Beneficios Intangibles

Aplicacin de tcnicas de planeamiento de capital

Payback Anlisis: Determina la cantidad de tiempo en el que se recuperar la inversin (todas las
compaas desean el menor payback posible).

Return on Investment ROI (Retorno de Inversin): Determina el tiempo esperado de retorno


para recuperar la inversin.
ROI = Beneficios - Costos

Net present value (NPV): Determina el valor presente neto de una serie de cash flows. Ayuda a
valorar teniendo en cuenta el correr del tiempo si una inversin dar beneficios o no.

Si

Esto significa

Entonces

NPV > 0

La inversin agrega valor a la empresa

El proyecto puede ser aceptado

NPV < 0

La inversin resta valor a la empresa

El proyecto debe ser rechazado

24

Anlisis y Diseo de Sistemas


Examen privado Oral
NPV = 0

La inversin no resta ni agrega valor a la


empresa

Tenemos que ser indiferentes en la decisin de


aceptar o rechazar el proyecto. Este proyecto no
aporta ningn valor monetario. La decisin debe
estar basada en otros criterios, por ejemplo,
posicionamiento estratgico u otros factores no
incluidos explcitamente en el clculo.

Estimacin de Costos de Adquisicin

Revisin de las soluciones del mercado

Request for Proposal (RFP)

Request for Quote (RFQ)

Estimacin de Costos de Desarrollo

Divisin del Proyecto en Tareas

Estimar costos de cada tarea en forma independiente

Uso de life cycle cost model

Utilizacin de experiencia de proyectos similares

Estimacin de Costos de Operacin y Soporte

Costo de Clientes/Usuarios

Personal Tcnico

Software

Soporte del Equipamiento y el Software

Reparaciones

Actualizaciones

Estimacin de los Beneficios Tangibles

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

Estimacin de Beneficios Intangibles

Calidad de la informacin

Precisin

25

Anlisis y Diseo de Sistemas


Examen privado Oral

Tiempo

Integracin

Presentacin

Satisfaccin de Trabajo

Diseo participativo

Enriquecimiento del trabajo

Herramientas mejoradas

Reconocimientos Externos

Mejor tiempo de respuesta

Mejor imagen corporativa

KENDALL & KENDALL


COMO ASUMIR EL PAPEL DEL ANALISTA DE SISTEMAS.
a) LA INFORMACIN COMO UN RECURSO DE LAS ORGANIZACIONES.
Las organizaciones han reconocido, desde hace mucho, la importancia de administrar recursos principales tales
como la mano de obra y las materias primas. La informacin se ha colocado en un lugar adecuado como recurso
principal.
Los tomadores de decisiones estn comenzando a comprender que la informacin no es slo un subproducto de
la conduccin, sino que a la vez alimenta a los negocios y puede ser el factor crtico para la determinacin del xito
o fracaso de stos. Manejo de la informacin como recurso.
Para maximizar la utilidad de la informacin, un negocio la debe manejar correctamente tal como maneja los
dems recursos. Los administradores necesitan comprender que hay costos asociados con la produccin,
distribucin, seguridad, almacenamiento y recuperacin de toda informacin. Aunque la informacin se encuentra
a nuestro alrededor sta no es gratis, y su uso es estratgico para posicionar la competitividad de un negocio.
Manejo de la informacin generada por computadora.
El manejo de informacin generada por computadora difiere en forma significativa del manejo de datos
producidos manualmente. Por lo general, hay mayor cantidad de informacin de computadora a administrar. El
costo de organizarla y mantenerla puede crecer a tasas alarmantes, y los usuarios frecuentemente la tratan menos
escpticamente que la informacin obtenida por otras vas.
b) CONCEPTOS DE ANLISIS Y DISEO DE SISTEMAS.
Los sistemas de informacin son desarrollados con propsitos diferentes dependiendo de las necesidades del
negocio. Los sistemas de procesamiento de transacciones (TPS por sus siglas en ingls) funcionan al nivel
operacional de la organizacin, los sistemas de automatizacin de oficina (OAS por sus siglas en ingls) y los
sistemas de trabajo de conocimiento (KWS por sus siglas en ingls) que dan cabida al trabajo a nivel de
conocimiento.
Los sistemas de ms alto nivel incluyen a los sistemas de apoyo a decisiones (DSS por sus siglas en ingls) as como
a los sistemas de informacin gerencial (MIS por sus siglas en ingls). Los sistemas expertos aplican la experiencia
de los tomadores de decisiones para resolver problemas especficos estructurados. Al nivel estratgico de la
administracin encontramos sistemas de apoyo a ejecutivos (ESS por sus siglas en ingls) y los sistemas de apoyo
a decisiones de grupo (GDSS por sus siglas en ingls) ayudan a la toma de decisiones al mismo nivel, en una forma
sin estructura o semiestructurada.
Sistemas de procesamiento de transacciones.
Los sistemas de procesamiento de transacciones (TPS) son sistemas de informacin computarizados desarrollados
para procesar gran cantidad de transacciones rutinarias de los negocios. Los TPS eliminan el tedio de las
transacciones operacionales necesarias y reducen el tiempo que alguna vez se requiri para ejecutarlas
manualmente, aunque la gente todava debe alimentar datos a los sistemas computarizados.
Sistemas de automatizacin de oficina y sistemas de manejo de conocimiento.

26

Anlisis y Diseo de Sistemas


Examen privado Oral
Al nivel de conocimiento de la organizacin hay dos clases de sistemas. Los sistemas de automatizacin de oficina
(OAS) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino
que usan la informacin para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla
o diseminarla formalmente por toda la organizacin y algunas veces ms all de ella. Los sistemas de manejo de
conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como cientficos, ingenieros y doctores,
les ayudan a crear un nuevo conocimiento que contribuya a la organizacin o a toda la sociedad.
Sistemas de informacin gerencial.
Los sistemas de informacin gerencial (MIS) no reemplazan a los sistemas de procesamiento de transacciones,
sino que todos los MIS incluyen procesamiento de transacciones. Los MIS son sistemas de informacin
computarizada que trabajan debido a la interaccin resuelta entre gentes y computadoras. Requieren que las
gentes, el software (programas de computadora) y el hardware (computadoras, impresoras, etc.) trabajen al
unsono. Los sistemas de informacin dan soporte a un espectro ms amplio de tareas organizacionales que los
sistemas de procesamiento de transacciones, incluyendo el anlisis de decisiones y la toma de decisiones.
Sistemas be apoyo a decisiones.
Una clase de ms alto nivel en los sistemas de informacin computarizada son los sistemas de apoyo a decisiones
(DSS). El DSS es similar al sistema de informacin gerencial tradicional en que ambos dependen de una base de
datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de informacin gerencial tradicional
en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisin actual todava es del
dominio del tomador de decisiones.
Sistemas expertos e inteligencia artificial.
La inteligencia artificial (Al por sus siglas en ingls) puede ser considerada la meta de los sistemas expertos. Los
sistemas expertos son un caso muy especial de un sistema de informacin, cuyo uso ha sido factible para los
negocios a partir de la reciente y amplia disponibilidad de hardware y software. Un sistema experto (tambin
llamado un sistema basado en conocimiento) captura en forma efectiva y usa el conocimiento de un experto para
resolver un problema particular experimentado en una organizacin. Observe que a diferencia del DSS, que deja la
decisin final al tomador de decisiones, un sistema experto selecciona la mejor solucin a un problema o a una
clase especfica de problemas.
Sistemas de apoyo a decisiones de grupo.
Cuando los grupos necesitan trabajar juntos para tomar decisiones semiestructuradas o sin estructura, un sistema
de apoyo a decisiones de grupo puede plantear una solucin. Los sistemas de apoyo a decisiones de grupo (GDSS)
son usados en cuartos especiales, equipados en varias configuraciones diferentes, que permiten que los miembros
del grupo interacten con apoyo electrnico, frecuentemente en forma de software especializado y con una
persona que da facilidades al grupo. Los sistemas para decisiones de grupo estn orientados para reunir a un
grupo, a fin de que resuelva un problema con la ayuda de varios apoyos como votaciones, cuestionarios,
aportacin de ideas y creacin de escenarios.
Sistemas de apoyo a ejecutivos.
Cuando los ejecutivos se acercan a la computadora, frecuentemente estn buscando formas que les ayuden a
tomar decisiones a nivel estratgico. Un sistema de apoyo a ejecutivos (ESS) ayuda a stos, para organizar sus
interacciones con el ambiente externo, proporcionando apoyo de grficos y comunicaciones en lugares accesibles
tales como salas de juntas u oficinas personales corporativas.
En la figura se muestran la diversidad de sistemas de informacin que pueden desarrollar los analistas. Observe
que la figura presenta estos sistemas de abajo hacia arriba, indicando que el nivel operacional, o ms bajo, de la
organizacin est apoyado por el TPS, y el ms alto o estratgico, el de las decisiones semiestructuradas o sin
estructura, est apoyado por el ESS en la parte ms alta. Este texto usa los trminos sistema de informacin
gerencias, sistema de informacin, sistema de informacin computarizada
y sistema de informacin de negocios computarizado en forma indistinta para referirse a sistemas de informacin
computarizada que dan soporte al rango ms amplio de actividades de negocios por medio de la informacin que
producen.

27

Anlisis y Diseo de Sistemas


Examen privado Oral

Las necesidades del anlisis y diseo de sistemas


El anlisis y diseo de sistemas, tal como es ejecutado por los analistas de sistemas, busca analizar
sistemticamente la entrada de datos o el flujo de datos, el proceso o transformacin de los datos, el
almacenamiento de datos y la salida de informacin dentro del contexto de un negocio particular. Adems, el
diseo y anlisis de sistemas es usado para analizar, disear e implementar mejoras en el funcionamiento de los
negocios que pueden ser logradas por medio del uso de sistemas de informacin computarizados. La instalacin
de un sistema sin la planeacin adecuada lleva a grandes frustraciones, y frecuentemente causa que el sistema
deje de ser usado.
Usuarios finales.
Cualquiera que interacte con un sistema de informacin en el contexto de su trabajo en la organizacin puede ser
llamado un usuario final. A lo largo de los aos se han hecho borrosas las distinciones entre usuarios. Adems,
cualquier categora de usuarios empleada no debe ser vista como excluyente. Sin importar cmo se hayan
clasificado los usuarios finales, un hecho es pertinente al analista de sistemas: el involucramiento del usuario a lo
largo del proyecto, es crtico para el desarrollo exitoso de los sistemas de informacin computarizados. Los
analistas de sistemas, cuyos papeles dentro de la organizacin se tratan a continuacin, son el otro componente
esencial para el desarrollo de sistemas de informacin.
c) EL PAPEL DE EL ANALISTA DE SISTEMAS
El analista de sistemas como consultor.
El analista de sistemas frecuentemente acta como consultor y, por lo tanto, puede ser contratado
especficamente para que se encargue de los asuntos de los sistemas de informacin dentro de un negocio. Esto
puede ser una ventaja, debido a que los consultores externos pueden llevar con ellos una perspectiva fresca que
no poseen otros miembros de la organizacin. Pero tambin puede decirse que los analistas externos estn en
desventaja, debido a que la verdadera cultura organizacional nunca puede ser conocida por un extrao.
El analista de sistemas como experto de soporte.
Otro papel que tal vez requiera desarrollar es el de experto de soporte en un negocio donde se est empleado
regularmente en alguna actividad de sistemas. En este papel el analista se apoya en su experiencia profesional
relacionada con el hardware y software de computadora y su uso en el negocio. Este trabajo frecuentemente no
es un proyecto de sistema completo, sino solamente pequeas modificaciones o decisiones que afectan a un solo
departamento.
El analista de sistemas como agente de cambio.
El papel ms comprensivo y responsable que toma un analista de sistemas es el de agente de cambio, ya sea
interno o externo al negocio. Como analista se es un agente de cambio cada vez que se ejecuta cualquiera de las
actividades del ciclo de vida del desarrollo de sistemas (tratado en la siguiente seccin) y se est presente en el
negocio por un periodo extendido (desde dos semanas hasta ms de un ao). Un agente de cambio puede ser
definido como una persona que sirve de catalizador para el cambio, desarrolla un plan para el cambio y trabaja
junto con otros para facilitar ese cambio.

28

Anlisis y Diseo de Sistemas


Examen privado Oral
d) EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS.

Identificacin de problemas, oportunidades y objetivos.


En la primera fase del ciclo de vida del desarrollo de sistemas el analista tiene que ver con la identificacin de
problemas, oportunidades y objetivos. Esta etapa es crtica para el xito del resto de proyecto, debido a que nadie
quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado. La primera fase requiere que el
analista observe honestamente lo que est sucediendo en un negocio. Luego, junto con los dems miembros de la
organizacin, el analista hace resaltar los problemas. Frecuentemente estos ya han sido vistos por los dems, y
son la razn por la cual el analista fue llamado inicialmente. Las personas involucradas en la primera fase son los
usuarios, analistas y administradores de sistemas que coordinan el proyecto. Las actividades de esta fase consisten
en entrevistas a los administradores de los usuarios, sumarizacin del conocimiento obtenido, estimacin del
alcance del proyecto y documentacin de los resultados. La salida de esta fase es un estudio de factibilidad que
contiene una definicin del problema y la sumarizacin de los objetivos. Luego los administradores deben tomar
una decisin para ver si continan con el proyecto propuesto.
Determinacin de los requerimientos de informacin.
Entre las herramientas utilizadas para definir los requerimientos de informacin en el negocio se encuentran:
muestreo e investigacin de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores
de decisiones y su ambiente de oficina y hasta la elaboracin de prototipos. En esta fase el analista est
esforzndose por comprender qu informacin necesitan los usuarios para realizar su trabajo. Las personas
involucradas en esta fase son los analistas y los usuarios, tpicamente los administradores de las operaciones y los
trabajadores de las operaciones.
Anlisis de las necesidades del sistema.
La siguiente fase que realiza el analista de sistemas involucro el anlisis de las necesidades del sistema.
Nuevamente, herramientas y tcnicas especiales ayudan para que el analista haga las determinaciones de los
requerimientos. Una herramienta de stas es el uso de diagramas de flujo de datos para diagramar la entrada,
proceso y salida de las funciones del negocio en forma grfica estructurado. A partir de los diagramas de flujo de
datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, as como
sus especificaciones, si son alfanumricos y qu tanto espacio ocupan cuando se imprimen. Durante esta fase el
analista de sistemas tambin analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son
aquellas para las que pueden ser determinadas las condiciones como alternativas de condicin, acciones y reglas
de accin.
Hay tres mtodos principales para el anlisis de decisiones estructurales: lenguaje estructurado, tablas de decisin
y rboles de decisin.
Diseo del sistema recomendado.
En esta fase del ciclo de vida del desarrollo de sistemas, el analista usa la informacin recolectada anteriormente
para realizar el diseo lgico del sistema de informacin. El analista disea procedimientos precisos para la captura
de datos, a fin de que los datos que van a entrar al sistema de informacin sean correctos. Adems, el analista
tambin proporciona entrada efectiva para el sistema de informacin mediante el uso de tcnicas para el buen
diseo de formas y pantallas.
Desarrollo y documentacin del software.
En la quinta fase del ciclo de vida del desarrollo de sistemas el analista trabaja con los programadores para
desarrollar cualquier software original que se necesite. Durante esta fase, el analista tambin trabaja con los
usuarios para desarrollar documentacin efectiva para el software, incluyendo manuales de procedimientos. La

29

Anlisis y Diseo de Sistemas


Examen privado Oral
documentacin le dice al usuario la manera de usar el software y tambin qu hacer si se suceden problemas con
el software.
Pruebas y mantenimiento del sistema.
Antes de que pueda ser usado, el sistema de informacin debe ser probado. Es mucho menos costoso encontrar
problemas antes de que el sistema sea entregado a los usuarios. Algunas de las pruebas son realizadas por los
programadores solos, y otras por los analistas de sistemas junto con los programadores. Primero se ejecuta una
serie de pruebas para que destaquen los problemas con datos de ejemplo y eventualmente con datos reales del
sistema actual. El mantenimiento del sistema y de su documentacin comienza en esta fase y es efectuado
rutinariamente a lo largo de la vida del sistema de informacin.
Implementacin y evaluacin del sistema.
En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de informacin. Esto incluye el
entrenamiento de los usuarios para que manejen el sistema. Algn entrenamiento es hecho por los proveedores,
pero la supervisin del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista
necesita un plan para una conversin suave del sistema antiguo al nuevo. La evaluacin se muestra como parte de
esta fase final de ciclo de vida del desarrollo del sistema, principalmente para efectos de discusin. De hecho, la
evaluacin se realiza durante cada fase. Un criterio principal que debe ser satisfecho es si los usuarios pretendidos
ya estn usando el sistema.
La importancia del mantenimiento.
Despus de que el sistema est instalado se le debe dar mantenimiento, esto significa que los programas de
computadora deben ser modificados y mantenidos actualizados. La figura muestra la cantidad promedio de
tiempo empleada en mantenimiento en una instalacin MIS tpica. El mantenimiento se realiza por dos razones. La
primera de estas es para corregir errores de software. Sin importar que tan completamente se pruebe el sistema,
se deslizan errores en los programas de computadora. Los errores del software
Comercial para
microcomputadoras son a veces documentados como "anomalas conocidas", y son corregidos cuando son
lanzadas nuevas versiones del software o versiones intermedias. En el software personalizado los errores deben
ser corregidos conforme son detectados.
La otra razn para realizar el mantenimiento del sistema es para mejorar las capacidades del software en
respuesta a las necesidades organizacionales cambiantes y, por lo general, involucran algunas de las siguientes
tres situaciones:
1. Los usuarios frecuentemente solicitan caractersticas adicionales despus de que se familiarizan con el
sistema de cmputo y sus capacidades. Estas caractersticas solicitadas pueden ser tan simples como el
desplegado de totales adicionales en un reporte o tan complicadas como el desarrollo de nuevo software.
2. El negocio cambia a travs del tiempo. Se debe modificar el software para abarcar cambios tales como
nuevos requerimientos de reportes gubernamentales o corporativos, la necesidad de producir nueva
informacin para clientes, etctera.
3. El hardware y software estn cambiando a un ritmo acelerado. Un sistema que usa tecnologa antigua
puede ser modificado para usar las capacidades de una tecnologa ms nueva. Un ejemplo de tal cambio
es el remplazo de una terminal de macrocomputadora con una estacin de trabajo de microcomputadora,
o una microcomputadora con una computadora de escritorio.
La figura ilustra la cantidad de recursos, por lo general tiempo y dinero, gastados en el desarrollo y mantenimiento
del sistema. El rea bajo la curva representa la cantidad total de dlares gastada. Se puede ver que a lo largo del
tiempo es probable que el costo de mantenimiento exceda al del desarrollo del sistema. En cierto punto es ms
conveniente realizar un nuevo estudio del sistema, debido a que el costo de mantenimiento continuado es
claramente mayor que la creacin de un sistema de informacin completamente nuevo.
Resumiendo, el mantenimiento es un proceso continuo a lo largo del ciclo de vida de un sistema de informacin.
Despus de que es instalado el sistema de informacin, el mantenimiento por lo general toma la forma de
correccin de errores de programa no detectados previamente. Una vez que son corregidos, el sistema alcanza un
estado estable proporcionando servicios contables a sus usuarios. El mantenimiento durante este periodo puede
consistir en la eliminacin de unos cuantos errores no detectados anteriormente y la actualizacin del sistema con
una cuantas mejoras menores. Sin embargo, conforme pasa el tiempo y cambia el negocio y la tecnologa, los
esfuerzos de mantenimiento se incrementan dramticamente.

30

Anlisis y Diseo de Sistemas


Examen privado Oral

e) USO DE LAS HERRAMIENTAS CASE.


A lo largo de este libro enfatizamos la necesidad de un enfoque sistemtico y profundo al anlisis, diseo e
implementacin de los sistemas de informacin. Reconocemos que para ser productivos los analistas de sistemas
deben ser organizados, precisos y completos en lo que se proponen hacer. En los ltimos aos los analistas han
comenzado a beneficiarse de nuevas herramientas de productividad que han sido creadas implcitamente para
mejorar su trabajo rutinario mediante un apoyo automatizado. A estas se les llama herramientas CASE, que
significa herramientas para ingeniera de software asistido por computadora. Los analistas se apoyan en las
herramientas CASE para aumentar la productividad, comunicarse ms efectivamente con los usuarios e integrar el
trabajo que realizan en el sistema, desde el principio hasta el fin del ciclo de vida.
Aumento de la productividad del analista.
Estas herramientas permiten que sus usuarios tracen y modifiquen diagramas fcilmente. Por nuestra definicin, el
analista puede entonces llegar a ser ms productivo simplemente por la reduccin del tiempo considerable que es
gastado tpicamente en el trazo manual de diagramas de flujo de datos hasta que son aceptados.
Mejora de la comunicacin del analista-usuario.
Para que el sistema propuesto se convierta en realidad y sea usado de hecho, es esencial una comunicacin
excelente entre los analistas y usuarios a lo largo del ciclo de vida del desarrollo del sistema. El xito de una
eventual implementacin del sistema depende de la capacidad de los analistas y usuarios para comunicarse en una
forma significativa. Hasta ahora los analistas que actualmente usan las nuevas herramientas CASE han
experimentado que su uso promueve una comunicacin mayor y ms significativa entre usuario y analistas.
Integracin de las actividades del ciclo de vida
La tercera razn para el uso de herramientas CASE es para integrar las actividades y proporcionar continuidad de
una fase a la siguiente a lo largo del ciclo de vida del desarrollo de sistemas. Las herramientas CASE son
especialmente tiles cuando una fase particular del ciclo de vida requiere varias interacciones o retroalimentacin
y modificacin.
Evaluacin precisa de los cambios del mantenimiento
La cuarta razn, y posiblemente una de las ms importantes para el uso de herramientas CASE, es que permite que
los usuarios analicen y valoren el impacto de los cambios de mantenimiento. Por ejemplo, puede ser que el
tamao de un elemento, tal como un nmero de cliente, necesite ser agrandado.

31

Das könnte Ihnen auch gefallen