2.4.- DETERMINAR LOS PROGRAMAS A DESARROLLAR
Concepto general de contabilidad. Definición de controlabilidad del estado. Teorema 5-1. Observabilidad de sistemas lineales. Definición de Observabilidad. Teoremas Invariantes sobre contabilidad y observabilidad. Los conceptos de controlabilidad y observabilidad presentados primero por Kalman juegan un papel importante en los aspectos teórico y práctico, del control moderno. Las condiciones sobre controlabilidad y observabilidad gobiernan la existencia de una solución de un problema de control óptimo. Esto parece ser la diferencia básica entre la teoría de control óptimo y la teoría clásica de control. Esto En esta última, las técnicas de diseño son dominadas por métodos de prueba y error, por lo que dado un conjunto de especificaciones de diseño, el diseñador desconoce en el inicio si existe solución. Por otro lado, la teoría de control óptimo para la mayor parte de los problemas, cuenta con criterios para determinar desde el inicio si la solución de diseño existe o no para los parámetros del sistema y los objetivos del diseño.Independencia de datos y tratamiento.Cambio en datos no implica cambio en programas y viceversa (Menor coste de mantenimiento).
Coherencia de resultados. Reduce redundancia :
Acciones logicamente unicas.
Se evita inconsistencia.
Mejora en la disponibilidad de datos
No hay dueño de datos (No igual a ser publicos).
Ni aplicaciones ni usuarios.Guardamos descripción (Idea de catalogos).
Cumplimiento de ciertas normas.
Restricciones de seguridad.
Accesos (Usuarios a datos).
Operaciones (Operaciones sobre datos).
domingo, 22 de marzo de 2009
2.5 DISEÑAR UNA BASE DE DATOS AL MODELO ENTIDAD/RELACION
2.5 DISEÑAR UNA BASE DE DATOS AL MODELO ENTIDAD/RELACION
Modelaje: es el proceso mediante el cual podemos identificar las propiedades dinàmicas ò estàticas de un dominio de aplicación con mira a su transformación en un diseño interpretable en un sistema computarizado. Es el plasmar los requerimientos de los usuarios en un programa para poder implementarlo.Entidad: es el objeto sobre el cual se requiere mantener ò almacenar información.Relaciòn: es la asociación significativa y estable entre dos entidadesAtributo: son las propiedades que describen y califican una entidad. Ej: Entidad cliente(nombre, apelliido, direcciòn, edad, sexo)Las entidades se las representa mediante cajas que se colocan el nombre de la entidad con letras mayùsculas.Las relaciones se representan con lìneas que conectan las cajas de las entidades.Los atributos se incluyen dentro de las cajas de las entidades y se escriben con minùsculas.Entidades: se puede considerar entidades a los sujetos, objetos, a los eventos, a los lugares y a los abstracciones.Relaciones: las relaciones tiene tres propiedades ò caracterìsticas:Grado ò Cardinalidad: que se clasifica en:Opcionalidad: es la participación obligatoria u opcional en la entidad de la relaciòn.Leyenda: es una expresión que escribe el rol de cada entidad en la relaciòn.Como se lee el Grado ò Cardinalidad:Uno a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidadMuchos a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B y una instancia de la entidad B se relaciona con uno ò màs instancias de le entidad B.Uno a uno: una instancia de la entidad A se relaciona con uno y sòlo unainstancia de la entidad B.Relaciòn RecursivaUna instancia de una entidad se asocia con instancia de si misma, es opcional en los dos extremos,es decir, no hay el carácter de obligatorio.Atributo:Los atributos son empleados para identificar, describir, calificar ò expresar el estado de una entidad.Todo entidad posee un atributo ò combinación de atributos que se denomina "clave primaria" y que emplea para diferenciar cada instancia de los demàs.Adicionalmente los atributos pueden ser obligatoriou opcionales.A los atributos que forman parte de la clave primaria se los identifica anteponiendoles el signo de numero (#).A los atributos obligatoriose les antepone el asterisco (*).A los atributos opcionales se les antepone un circulo (o).Ejemplo:En un diagrama entidad-relaciòn tambièn puede agrupar las entidades en supertipo y en subtipo.Los supertipo agrupa a dos ò màs entidades subtipo.Los subtipo heredan los atributos de las entidades supertipo.Cada subtipo puede tener relaciones propias independientes del supertipo.Los subtipos se representan como cajas dibujadas dentro de la caja del supertipo.
Modelaje: es el proceso mediante el cual podemos identificar las propiedades dinàmicas ò estàticas de un dominio de aplicación con mira a su transformación en un diseño interpretable en un sistema computarizado. Es el plasmar los requerimientos de los usuarios en un programa para poder implementarlo.Entidad: es el objeto sobre el cual se requiere mantener ò almacenar información.Relaciòn: es la asociación significativa y estable entre dos entidadesAtributo: son las propiedades que describen y califican una entidad. Ej: Entidad cliente(nombre, apelliido, direcciòn, edad, sexo)Las entidades se las representa mediante cajas que se colocan el nombre de la entidad con letras mayùsculas.Las relaciones se representan con lìneas que conectan las cajas de las entidades.Los atributos se incluyen dentro de las cajas de las entidades y se escriben con minùsculas.Entidades: se puede considerar entidades a los sujetos, objetos, a los eventos, a los lugares y a los abstracciones.Relaciones: las relaciones tiene tres propiedades ò caracterìsticas:Grado ò Cardinalidad: que se clasifica en:Opcionalidad: es la participación obligatoria u opcional en la entidad de la relaciòn.Leyenda: es una expresión que escribe el rol de cada entidad en la relaciòn.Como se lee el Grado ò Cardinalidad:Uno a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidadMuchos a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B y una instancia de la entidad B se relaciona con uno ò màs instancias de le entidad B.Uno a uno: una instancia de la entidad A se relaciona con uno y sòlo unainstancia de la entidad B.Relaciòn RecursivaUna instancia de una entidad se asocia con instancia de si misma, es opcional en los dos extremos,es decir, no hay el carácter de obligatorio.Atributo:Los atributos son empleados para identificar, describir, calificar ò expresar el estado de una entidad.Todo entidad posee un atributo ò combinación de atributos que se denomina "clave primaria" y que emplea para diferenciar cada instancia de los demàs.Adicionalmente los atributos pueden ser obligatoriou opcionales.A los atributos que forman parte de la clave primaria se los identifica anteponiendoles el signo de numero (#).A los atributos obligatoriose les antepone el asterisco (*).A los atributos opcionales se les antepone un circulo (o).Ejemplo:En un diagrama entidad-relaciòn tambièn puede agrupar las entidades en supertipo y en subtipo.Los supertipo agrupa a dos ò màs entidades subtipo.Los subtipo heredan los atributos de las entidades supertipo.Cada subtipo puede tener relaciones propias independientes del supertipo.Los subtipos se representan como cajas dibujadas dentro de la caja del supertipo.
2.5 DISEÑAR UNA BASE DE DATOS AL MODELO ENTIDAD/RELACION
2.5 DISEÑAR UNA BASE DE DATOS AL MODELO ENTIDAD/RELACION
Modelaje: es el proceso mediante el cual podemos identificar las propiedades dinàmicas ò estàticas de un dominio de aplicación con mira a su transformación en un diseño interpretable en un sistema computarizado. Es el plasmar los requerimientos de los usuarios en un programa para poder implementarlo.Entidad: es el objeto sobre el cual se requiere mantener ò almacenar información.Relaciòn: es la asociación significativa y estable entre dos entidadesAtributo: son las propiedades que describen y califican una entidad. Ej: Entidad cliente(nombre, apelliido, direcciòn, edad, sexo)Las entidades se las representa mediante cajas que se colocan el nombre de la entidad con letras mayùsculas.Las relaciones se representan con lìneas que conectan las cajas de las entidades.Los atributos se incluyen dentro de las cajas de las entidades y se escriben con minùsculas.Entidades: se puede considerar entidades a los sujetos, objetos, a los eventos, a los lugares y a los abstracciones.Relaciones: las relaciones tiene tres propiedades ò caracterìsticas:Grado ò Cardinalidad: que se clasifica en:Opcionalidad: es la participación obligatoria u opcional en la entidad de la relaciòn.Leyenda: es una expresión que escribe el rol de cada entidad en la relaciòn.Como se lee el Grado ò Cardinalidad:Uno a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidadMuchos a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B y una instancia de la entidad B se relaciona con uno ò màs instancias de le entidad B.Uno a uno: una instancia de la entidad A se relaciona con uno y sòlo unainstancia de la entidad B.Relaciòn RecursivaUna instancia de una entidad se asocia con instancia de si misma, es opcional en los dos extremos,es decir, no hay el carácter de obligatorio.Atributo:Los atributos son empleados para identificar, describir, calificar ò expresar el estado de una entidad.Todo entidad posee un atributo ò combinación de atributos que se denomina "clave primaria" y que emplea para diferenciar cada instancia de los demàs.Adicionalmente los atributos pueden ser obligatoriou opcionales.A los atributos que forman parte de la clave primaria se los identifica anteponiendoles el signo de numero (#).A los atributos obligatoriose les antepone el asterisco (*).A los atributos opcionales se les antepone un circulo (o).Ejemplo:En un diagrama entidad-relaciòn tambièn puede agrupar las entidades en supertipo y en subtipo.Los supertipo agrupa a dos ò màs entidades subtipo.Los subtipo heredan los atributos de las entidades supertipo.Cada subtipo puede tener relaciones propias independientes del supertipo.Los subtipos se representan como cajas dibujadas dentro de la caja del supertipo.
Modelaje: es el proceso mediante el cual podemos identificar las propiedades dinàmicas ò estàticas de un dominio de aplicación con mira a su transformación en un diseño interpretable en un sistema computarizado. Es el plasmar los requerimientos de los usuarios en un programa para poder implementarlo.Entidad: es el objeto sobre el cual se requiere mantener ò almacenar información.Relaciòn: es la asociación significativa y estable entre dos entidadesAtributo: son las propiedades que describen y califican una entidad. Ej: Entidad cliente(nombre, apelliido, direcciòn, edad, sexo)Las entidades se las representa mediante cajas que se colocan el nombre de la entidad con letras mayùsculas.Las relaciones se representan con lìneas que conectan las cajas de las entidades.Los atributos se incluyen dentro de las cajas de las entidades y se escriben con minùsculas.Entidades: se puede considerar entidades a los sujetos, objetos, a los eventos, a los lugares y a los abstracciones.Relaciones: las relaciones tiene tres propiedades ò caracterìsticas:Grado ò Cardinalidad: que se clasifica en:Opcionalidad: es la participación obligatoria u opcional en la entidad de la relaciòn.Leyenda: es una expresión que escribe el rol de cada entidad en la relaciòn.Como se lee el Grado ò Cardinalidad:Uno a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidadMuchos a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B y una instancia de la entidad B se relaciona con uno ò màs instancias de le entidad B.Uno a uno: una instancia de la entidad A se relaciona con uno y sòlo unainstancia de la entidad B.Relaciòn RecursivaUna instancia de una entidad se asocia con instancia de si misma, es opcional en los dos extremos,es decir, no hay el carácter de obligatorio.Atributo:Los atributos son empleados para identificar, describir, calificar ò expresar el estado de una entidad.Todo entidad posee un atributo ò combinación de atributos que se denomina "clave primaria" y que emplea para diferenciar cada instancia de los demàs.Adicionalmente los atributos pueden ser obligatoriou opcionales.A los atributos que forman parte de la clave primaria se los identifica anteponiendoles el signo de numero (#).A los atributos obligatoriose les antepone el asterisco (*).A los atributos opcionales se les antepone un circulo (o).Ejemplo:En un diagrama entidad-relaciòn tambièn puede agrupar las entidades en supertipo y en subtipo.Los supertipo agrupa a dos ò màs entidades subtipo.Los subtipo heredan los atributos de las entidades supertipo.Cada subtipo puede tener relaciones propias independientes del supertipo.Los subtipos se representan como cajas dibujadas dentro de la caja del supertipo.
2.5 DISEÑAR UNA BASE DE DATOS AL MODELO ENTIDAD/RELACION
Modelaje: es el proceso mediante el cual podemos identificar las propiedades dinàmicas ò estàticas de un dominio de aplicación con mira a su transformación en un diseño interpretable en un sistema computarizado. Es el plasmar los requerimientos de los usuarios en un programa para poder implementarlo.Entidad: es el objeto sobre el cual se requiere mantener ò almacenar información.Relaciòn: es la asociación significativa y estable entre dos entidadesAtributo: son las propiedades que describen y califican una entidad. Ej: Entidad cliente(nombre, apelliido, direcciòn, edad, sexo)Las entidades se las representa mediante cajas que se colocan el nombre de la entidad con letras mayùsculas.Las relaciones se representan con lìneas que conectan las cajas de las entidades.Los atributos se incluyen dentro de las cajas de las entidades y se escriben con minùsculas.Entidades: se puede considerar entidades a los sujetos, objetos, a los eventos, a los lugares y a los abstracciones.Relaciones: las relaciones tiene tres propiedades ò caracterìsticas:Grado ò Cardinalidad: que se clasifica en:Opcionalidad: es la participación obligatoria u opcional en la entidad de la relaciòn.Leyenda: es una expresión que escribe el rol de cada entidad en la relaciòn.Como se lee el Grado ò Cardinalidad:Uno a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidadMuchos a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B y una instancia de la entidad B se relaciona con uno ò màs instancias de le entidad B.Uno a uno: una instancia de la entidad A se relaciona con uno y sòlo unainstancia de la entidad B.Relaciòn RecursivaUna instancia de una entidad se asocia con instancia de si misma, es opcional en los dos extremos,es decir, no hay el carácter de obligatorio.Atributo:Los atributos son empleados para identificar, describir, calificar ò expresar el estado de una entidad.Todo entidad posee un atributo ò combinación de atributos que se denomina "clave primaria" y que emplea para diferenciar cada instancia de los demàs.Adicionalmente los atributos pueden ser obligatoriou opcionales.A los atributos que forman parte de la clave primaria se los identifica anteponiendoles el signo de numero (#).A los atributos obligatoriose les antepone el asterisco (*).A los atributos opcionales se les antepone un circulo (o).Ejemplo:En un diagrama entidad-relaciòn tambièn puede agrupar las entidades en supertipo y en subtipo.Los supertipo agrupa a dos ò màs entidades subtipo.Los subtipo heredan los atributos de las entidades supertipo.Cada subtipo puede tener relaciones propias independientes del supertipo.Los subtipos se representan como cajas dibujadas dentro de la caja del supertipo.
Modelaje: es el proceso mediante el cual podemos identificar las propiedades dinàmicas ò estàticas de un dominio de aplicación con mira a su transformación en un diseño interpretable en un sistema computarizado. Es el plasmar los requerimientos de los usuarios en un programa para poder implementarlo.Entidad: es el objeto sobre el cual se requiere mantener ò almacenar información.Relaciòn: es la asociación significativa y estable entre dos entidadesAtributo: son las propiedades que describen y califican una entidad. Ej: Entidad cliente(nombre, apelliido, direcciòn, edad, sexo)Las entidades se las representa mediante cajas que se colocan el nombre de la entidad con letras mayùsculas.Las relaciones se representan con lìneas que conectan las cajas de las entidades.Los atributos se incluyen dentro de las cajas de las entidades y se escriben con minùsculas.Entidades: se puede considerar entidades a los sujetos, objetos, a los eventos, a los lugares y a los abstracciones.Relaciones: las relaciones tiene tres propiedades ò caracterìsticas:Grado ò Cardinalidad: que se clasifica en:Opcionalidad: es la participación obligatoria u opcional en la entidad de la relaciòn.Leyenda: es una expresión que escribe el rol de cada entidad en la relaciòn.Como se lee el Grado ò Cardinalidad:Uno a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidadMuchos a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B y una instancia de la entidad B se relaciona con uno ò màs instancias de le entidad B.Uno a uno: una instancia de la entidad A se relaciona con uno y sòlo unainstancia de la entidad B.Relaciòn RecursivaUna instancia de una entidad se asocia con instancia de si misma, es opcional en los dos extremos,es decir, no hay el carácter de obligatorio.Atributo:Los atributos son empleados para identificar, describir, calificar ò expresar el estado de una entidad.Todo entidad posee un atributo ò combinación de atributos que se denomina "clave primaria" y que emplea para diferenciar cada instancia de los demàs.Adicionalmente los atributos pueden ser obligatoriou opcionales.A los atributos que forman parte de la clave primaria se los identifica anteponiendoles el signo de numero (#).A los atributos obligatoriose les antepone el asterisco (*).A los atributos opcionales se les antepone un circulo (o).Ejemplo:En un diagrama entidad-relaciòn tambièn puede agrupar las entidades en supertipo y en subtipo.Los supertipo agrupa a dos ò màs entidades subtipo.Los subtipo heredan los atributos de las entidades supertipo.Cada subtipo puede tener relaciones propias independientes del supertipo.Los subtipos se representan como cajas dibujadas dentro de la caja del supertipo.
martes, 3 de marzo de 2009
TOMA DE DESICIONES
Para la toma de decisiones sabemos que es necesario hacer uso de la información como, el uso de teorías, que tiene como consecuencia el acierto, la incertidumbre y el riesgo, es por eso que debemos diferenciar si el tomador de decisiones en analítico o heurístico y es importante que estos tomen en cuenta las fases de solución como son la inteligencia, la selección y el diseño, tal como se le da soporte en los sistemas de apoyo a decisiones.
LA TOMA DE DECISIONES BAJO RIESGO
Las decisiones son tomadas por lo general bajo tres condiciones importantes como lo es la: certidumbre, incertidumbre y el riego.
La certidumbre es aquella que nos muestra todo por anticipado antes de la decisión, los resultados, las consecuencias y según sean las necesidades presentadas por el usuario.
La incertidumbre es lo contrario de la certidumbre, no tenemos resultados, ni probabilidades o las consecuencias de las decisiones.
Entre estos dos aspectos o condiciones tienen por medio el riesgo, es decir que tenemos el conocimiento (certidumbre) de las alternativas (variables controlables), existen sólo las estimaciones y no está en nuestras manos el controlar (variables ambientales) y de las que no estamos seguros de su resultado (variables dependientes). Bajo estas alternativas que tenemos muchas de las tomas de decisiones en las empresas o negocios se realizan bajo riesgo.
EL ESTILO DE LA TOMA DE DECISIONES
Por lo general la información se recolecta, procesa y se usa en forma de parámetro según sea el estilo de la toma de decisiones. Y es por eso que los tomadores de decisiones son analíticos o heurísticos.
Un tomador de decisiones analítico se apoya en la información que es adquirida y evaluada sistemáticamente para estrechar las alternativas y tomar una selección que esté basada en información. En donde los tomadores de decisiones analíticos valoran la información cuantitativa y los modelos que la generan y la usan. Como comentario adicional, utilizan matemáticas para el modelo del problema y usan algoritmos para resolverlos.
Un tomador de decisiones heurístico se hace ayudar de lineamientos (reglas), aunque no se adapte, bajo conciencia o un sistema, esto es que la heurística se basa en la experiencia. Estos tomadores de decisiones aprenden bajo las actuaciones, es decir mediante la prueba y el error hasta encontrar la solución. Y su apoyo es el sentido común para que los guíe.
Para la toma de decisiones sabemos que es necesario hacer uso de la información como, el uso de teorías, que tiene como consecuencia el acierto, la incertidumbre y el riesgo, es por eso que debemos diferenciar si el tomador de decisiones en analítico o heurístico y es importante que estos tomen en cuenta las fases de solución como son la inteligencia, la selección y el diseño, tal como se le da soporte en los sistemas de apoyo a decisiones.
LA TOMA DE DECISIONES BAJO RIESGO
Las decisiones son tomadas por lo general bajo tres condiciones importantes como lo es la: certidumbre, incertidumbre y el riego.
La certidumbre es aquella que nos muestra todo por anticipado antes de la decisión, los resultados, las consecuencias y según sean las necesidades presentadas por el usuario.
La incertidumbre es lo contrario de la certidumbre, no tenemos resultados, ni probabilidades o las consecuencias de las decisiones.
Entre estos dos aspectos o condiciones tienen por medio el riesgo, es decir que tenemos el conocimiento (certidumbre) de las alternativas (variables controlables), existen sólo las estimaciones y no está en nuestras manos el controlar (variables ambientales) y de las que no estamos seguros de su resultado (variables dependientes). Bajo estas alternativas que tenemos muchas de las tomas de decisiones en las empresas o negocios se realizan bajo riesgo.
EL ESTILO DE LA TOMA DE DECISIONES
Por lo general la información se recolecta, procesa y se usa en forma de parámetro según sea el estilo de la toma de decisiones. Y es por eso que los tomadores de decisiones son analíticos o heurísticos.
Un tomador de decisiones analítico se apoya en la información que es adquirida y evaluada sistemáticamente para estrechar las alternativas y tomar una selección que esté basada en información. En donde los tomadores de decisiones analíticos valoran la información cuantitativa y los modelos que la generan y la usan. Como comentario adicional, utilizan matemáticas para el modelo del problema y usan algoritmos para resolverlos.
Un tomador de decisiones heurístico se hace ayudar de lineamientos (reglas), aunque no se adapte, bajo conciencia o un sistema, esto es que la heurística se basa en la experiencia. Estos tomadores de decisiones aprenden bajo las actuaciones, es decir mediante la prueba y el error hasta encontrar la solución. Y su apoyo es el sentido común para que los guíe.
ESTUDIO DE FACTIBILIDAD
En primer lugar, la arquitectura del equipo que analizamos, esto implica evaluar cual es la arquitectura que mejor se adapta para el procesamiento de las aplicaciones que pensamos desarrollar en nuestro futuro equipo.
En este punto, debemos evaluar la filosofía con que fue construida la computadora y la orientación técnica de sus componentes, en relación con el tipo de procesamiento para el que fue pensado originalmente.
Según la filosofía de su construcción, el procesamiento puede ser: centralizado, descentralizado o distribuido, y de acuerdo a la envergadura de algunas compañías, una mezcla e ellos.
La complejidad que presenta la evaluación de un proyecto de inversión como la toma de un computador, impone la utilización de una metodología que establezca una disciplina de trabajo que permita el planeamiento y control del proyecto, facilite la asignación de tareas y mejorar las estimaciones, y en definitiva nos permita reducir el riesgo.
En el presente trabajo se formula una metodología para efectuar un Estudio de Factibilidad para la toma de un computador que contempla los aspectos mencionados anteriormente, si bien este no es el único proyecto de inversión en informática que requerirá ser evaluado, también se pueden dar los siguientes casos:
Reemplazo del actual computador
Reestructuración del área de sistemas
Revisión parcial de la instalación
Procesamiento de determinadas aplicaciones
Aplicaciones especificas (Robótica, Sistemas Expertos, etc.)
En cada caso, se deberá evaluar que etapas y fases de la metodología se deberán utilizar, pero el común denominador será que el Estudio de Factibilidad tiene por objeto transformar un acto aventurado de inversión, en una decisión de riesgo calculado.
La ausencia de una metodología se debe más a la falta de apreciación del riesgo involucrado, que a la dificultad para su formulación y posterior ejecución.
En primer lugar, la arquitectura del equipo que analizamos, esto implica evaluar cual es la arquitectura que mejor se adapta para el procesamiento de las aplicaciones que pensamos desarrollar en nuestro futuro equipo.
En este punto, debemos evaluar la filosofía con que fue construida la computadora y la orientación técnica de sus componentes, en relación con el tipo de procesamiento para el que fue pensado originalmente.
Según la filosofía de su construcción, el procesamiento puede ser: centralizado, descentralizado o distribuido, y de acuerdo a la envergadura de algunas compañías, una mezcla e ellos.
La complejidad que presenta la evaluación de un proyecto de inversión como la toma de un computador, impone la utilización de una metodología que establezca una disciplina de trabajo que permita el planeamiento y control del proyecto, facilite la asignación de tareas y mejorar las estimaciones, y en definitiva nos permita reducir el riesgo.
En el presente trabajo se formula una metodología para efectuar un Estudio de Factibilidad para la toma de un computador que contempla los aspectos mencionados anteriormente, si bien este no es el único proyecto de inversión en informática que requerirá ser evaluado, también se pueden dar los siguientes casos:
Reemplazo del actual computador
Reestructuración del área de sistemas
Revisión parcial de la instalación
Procesamiento de determinadas aplicaciones
Aplicaciones especificas (Robótica, Sistemas Expertos, etc.)
En cada caso, se deberá evaluar que etapas y fases de la metodología se deberán utilizar, pero el común denominador será que el Estudio de Factibilidad tiene por objeto transformar un acto aventurado de inversión, en una decisión de riesgo calculado.
La ausencia de una metodología se debe más a la falta de apreciación del riesgo involucrado, que a la dificultad para su formulación y posterior ejecución.
INVESTIGACIÓN PRELIMINAR
Por cualquiera que sea la estrategia mediante la cual se va a desarrollar el sistema (SDLC, prototipos, análisis estructurado, o por una combinación de éstos) primero es necesario revisar la solicitud del proyecto. La elección de una estrategia es secundario, lo importante es determinar si la solicitud merece o no la inversión de recursos en un proyecto de sistemas de información. El tiempo estimado es aproximadamente entre 4 a 6 seis días.
El propósito de la investigación preliminar es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación preliminar debe cumplir con los siguientes cinco objetivos:
1. Entender la naturaleza del problema – Es el primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, o sea, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer. La limitación puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas fases de desarrollo – Se debe presentar un estimado del tiempo que tomará realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – y los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
Por cualquiera que sea la estrategia mediante la cual se va a desarrollar el sistema (SDLC, prototipos, análisis estructurado, o por una combinación de éstos) primero es necesario revisar la solicitud del proyecto. La elección de una estrategia es secundario, lo importante es determinar si la solicitud merece o no la inversión de recursos en un proyecto de sistemas de información. El tiempo estimado es aproximadamente entre 4 a 6 seis días.
El propósito de la investigación preliminar es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación preliminar debe cumplir con los siguientes cinco objetivos:
1. Entender la naturaleza del problema – Es el primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, o sea, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer. La limitación puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas fases de desarrollo – Se debe presentar un estimado del tiempo que tomará realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – y los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
Suscribirse a:
Entradas (Atom)