El documento describe los pasos típicos en un estudio de factibilidad para un nuevo sistema de información. Estos incluyen definir los objetivos y alcances del sistema, analizar el sistema existente, desarrollar un modelo lógico preliminar, redefinir el problema a la luz de los nuevos conocimientos, generar y evaluar soluciones alternativas, y analizar la factibilidad técnica, económica y operacional de cada solución viable. El estudio de factibilidad proporciona una evaluación inicial del proyecto y una recomendación
Ciclo de vida de los sistemas de informacionYaskelly Yedra
El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.
Ciclo de vida de los sistemas de informacionYaskelly Yedra
El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.
Pruebas de sistemas, pruebas de aceptacion, descripcion de cada uno de los tipos de pruebas . tambien vemos la imlementacion de las pruebas de sistemas y de pruebas de aceptacion.
Webinar: Cómo determinar la Capacidad de los Procesos en COBIT® 5
Objetivos del Webinar:
1. Entender la importancia de las evaluaciones de capacidad en COBIT 5.
2. Entender el enfoque de la norma ISO/IEC 15504 para la determinación de la capacidad de procesos.
3. Conocer el Modelo de Evaluación de Procesos (PAM) de COBIT 5.
El presente trabajo muestra los aspectos principales e importantes sobre lo referido al procesamiento electrónico de datos y su influencia en la auditoría de sistemas computacionales
Pruebas de sistemas, pruebas de aceptacion, descripcion de cada uno de los tipos de pruebas . tambien vemos la imlementacion de las pruebas de sistemas y de pruebas de aceptacion.
Webinar: Cómo determinar la Capacidad de los Procesos en COBIT® 5
Objetivos del Webinar:
1. Entender la importancia de las evaluaciones de capacidad en COBIT 5.
2. Entender el enfoque de la norma ISO/IEC 15504 para la determinación de la capacidad de procesos.
3. Conocer el Modelo de Evaluación de Procesos (PAM) de COBIT 5.
El presente trabajo muestra los aspectos principales e importantes sobre lo referido al procesamiento electrónico de datos y su influencia en la auditoría de sistemas computacionales
Se habla sobre la existencia de una dicotomía entre la teoría de sistemas duros, son típicamente los encontrados en las ciencias físicas y a los cuales se puede aplicar satisfactoriamente las técnicas tradicionales del método científico y del paradigma de ciencia.
Agregar a favoritos invitar a un amigo ayuda português
El estudio de factibilidad
1. ESTUDIO DE FACTIBILIDAD
El estudio de factibilidad
¿Qué es un estudio de Factibilidad?
Un estudio de factibilidad es una versión comprimida del proceso total
de análisis y diseño del sistema.
El estudio comienza clarificando la definición del problema. Se
confirma o se corrige la definición inicial de alcances y objetivos, y se
identifica cualquier restricción impuesta sobre el sistema.
Una vez que se ha generado una definición aceptable del problema, el
analista desarrolla un modelo lógico del sistema. Luego comienza la
búsqueda de soluciones alternativas, usando este modelo como
referencia.
Después se analizan cuidadosamente las alternativas para verificar su
factibilidad. Al menos se pueden considerar tres tipos diferentes de
factibilidad:
1. Técnica: ¿Puede implementarse el sistema usando la
tecnología actual?
2. Económica: ¿Los beneficios superan los costos?
3. Operacional u organizacional: ¿Puede implementarse el
sistema en esta organización? O a que nivel esta el personal
Para cada solución factible, el analista prepara una planificación
preliminar de la implementaron.
Los resultados del estudio de factibilidad se presentan al gerente y al
usuario. Casi siempre se requiere un informe escrito, y son comunes
las presentaciones orales. Una recomendación posible es “abandone
el proyecto”. Asumiendo que el analista ha encontrado una solución
factible, el estudio de factibilidad debe proporcionar un sentido de
dirección técnica para el proyecto; por ejemplo: un plan de avanzar.
¿Cuánto tiempo debe gastarse para el estudio de factibilidad? La
respuesta depende del alcance del proyecto. Para un cambio menor,
en el formato de un informe existente, puede ser adecuada una breve
conversación telefónica. Sobre un proyecto estimado de unos cuantos
miles de pesos para desarrollar un nuevo sistema contable, un
estudio de factibilidad de algunas semanas es probablemente
razonable. Para el desarrollo de un nuevo software para la compañía,
en un paquete millonario, puede tener sentido gastar seis meses o un
año diseñando t probando un prototipo del sistema. El costo del
estudio de factibilidad debe ser aproximadamente del 5 al 10% del
costo estimado total del proyecto.
En las próximas páginas, describimos los pasos involucrados en un
estudio típico de factibilidad. Utilice esta descripción como un
lineamiento general, pero recuerde que no hay dos sistemas iguales.
Los pasos describen un estudio de factibilidad de varios días de
duración.
Pagina: 1
2. ESTUDIO DE FACTIBILIDAD
Los pasos en un estudio típico de factibilidad
1. Definir los alcances y objetivos del sistema. Durante la
definición del problema, se preparó una definición de alcances y
objetivos. El analista debe confirmar la definición del problema,
el alcance anticipado del proyecto, y los objetivos del sistema.
Cualquier restricción debe identificarse claramente. Se requerirá
realizar entrevistas con personal clave y alguna revisión del
material escrito. Esencialmente, el analista intenta responder
una pregunta muy simple: ¿Estoy trabajando en el problema
correcto?. Debe hacerse la pregunta
2. Estudio del sistema existente (si hay uno). El sistema
existente es una fuente de información. Obviamente, si un
sistema se usa, debe estar realizando algún trabajo útil, y sus
funciones básicas deben incorporarse al nuevo sistema. Por otro
lado, si el sistema existente hace un trabajo correcto, no
tendríamos necesidad de un nuevo sistema; así, cualquier
problema identificado en el sistema viejo debe ser corregido.
Finalmente, el costo de operación del sistema existente
representa un nuevo objetivo económico; si el nuevo sistema
no proporciona beneficios adicionales y/o reducción de costos,
debe mantenerse el viejo sistema.
Analicemos cuidadosamente los procedimientos y la
documentación escrita. Entendamos también el sistema
informal. Sigamos el flujo de trabajo; un buen punto de
comienzo es la lista de distribución de los informes generados
por el sistema. Aprendamos que hace el sistema, y porque lo
hace así. Obtengamos datos de costos; sepamos el costo de
operar el sistema actual. Considere necesario entrevistar gente.
Recuerde que la relación entre un Analista de Sistemas y un
usuario es similar a la que existe entre un doctor y un paciente.
El usuario frecuentemente describe síntomas y no problemas
reales, y el analista debe interpretar esa información.
Un error común es gastar mucho tiempo en analizar el sistema
existente. El objetivo no es documentar lo que se hace, sino
entender lo que se hace. El analista no debe interesarse en
como trabaja el sistema, debe concentrarse en qué es lo que
hace.
Construya un diagrama de flujo de datos y un diccionario de
datos del sistema viejo; otra posibilidad es un diagrama de flujo
de datos del sistema de alto nivel. No gaste mucho tiempo en
detalles de implementación; por ejemplo, evite dibujar
diagramas de lógica de programas a menos que este tratando
de definir un algoritmo importante.
Pagina: 2
3. ESTUDIO DE FACTIBILIDAD
Pocos sistemas existen en el vacío; muchos hacen interfaz con
otros. Defina estas interfaces; ellas representan restricciones
muy importantes para el diseño del nuevo sistema.
3. Desarrolle un modelo lógico de alto nivel del sistema
propuesto. En este momento, el analista debe tener un buen
sentido de las funciones y restricciones del sistema nuevo. Un
modelo lógico del sistema nuevo puede construirse usando un
diagrama de flujo de datos y tal vez un diccionario de datos.
Más adelante, este modelo lógico puede usarse en el diseño del
sistema nuevo.
Viejo Nuevo
Lógico 1 3
Físico 2 4
Fig. 1: Un buen diseño comienza con el sistema físico existente,
desarrolla un modelo lógico de este sistema, usa el modelo para
construir un modelo lógico del sistema propuesto, y luego basa el
sistema físico nuevo en este modelo lógico.
4. Redefinir el problema a la luz de los nuevos conocimientos.
Desarrollando un modelo lógico del sistema propuesto, el
analista esta diciendo: “Esto es lo que yo pienso que el sistema
debe hacer”. ¿Esta el usuario de acuerdo? Esto es fácil de
descubrir. Pregunte.
En esta etapa, el analista debe revisar la definición del
problema, el alcance y los objetivos con el personal clave,
usando el diagrama de flujo de datos lógico y el diccionario de
datos como una base para la discusión. Si el analista no ha
comprendido, o el usuario ha pasado por alto algo, ahora es el
momento de descubrirlo. Piense a los primeros cuatro pasos del
estudio de factibilidad como un todo. El analista define el
problema, lo analiza, desarrolla una solución tentativa, redefine
el problema, lo reanaliza, revisa la solución, y continúa este
proceso cíclico hasta que el modelo lógico reúne los objetivos
del sistema.
Pagina: 3
4. ESTUDIO DE FACTIBILIDAD
5. Desarrollar y evaluar soluciones alternativas. Dado un
modelo lógico del sistema propuesto, el analista puede
comenzar a generar alternativas de soluciones físicas de alto
nivel. ¿Cómo hace un analista para generar estas alternativas?
Tal vez la propuesta más fácil es comenzar con la factibilidad
técnica, y pensar una variedad de formas en que el problema
pueda ser resuelto. Por ejemplo, a través del proceso de
identificar fronteras de automatización sobre un diagrama de
flujo de datos. Cada una de estas fronteras de automatización
representan una posible solución física; el analista puede definir
varios conjuntos de fronteras de automatización, y luego
determinar como puede implementarse el sistema con cada
conjunto.
Otra opción es usar una técnica conocida como Brainstorming.
Dado el modelo lógico del sistema y una o dos horas de tiempo
interrumpido, el analista y unos pocos colegas técnicos se
reúnen para soñar posibles soluciones. Las reglas son simples.
Todos contribuyen con posibles soluciones al problema. A nadie
se le permite criticar, y no se evalúan las sugerencias. La
cuestión es compilar simplemente una lista de ideas. Una sesión
de Brainstorming puede terminar en un tiempo predeterminado,
o cuando se ha generado un cierto número de alternativas.
Después de la sesión, el analista debe evaluar las sugerencias y
seleccionar unas pocas que parezcan razonables.
Muchos analistas prefieren usar una lista de control. Por
ejemplo, se pueden desarrollar diferentes tipos de sistemas
sobre diferentes tipos de computadoras; unos pocos
representativos se resumen en la fig. 2. Cada bloque en la
matriz es un tipo particular de sistema, un sistema batch sobre
un microcomputador, un sistema batch sobre un mainframe, un
sistema interactivo sobre un minicomputador, etc.
Usando la matriz como guía, el analista puede determinar un
sistema para cada bloque. Siempre deben considerarse dos
alternativas adicionales, el sistema existente y un sistema
manual.
Pagina: 4
5. ESTUDIO DE FACTIBILIDAD
Computador
Origen Tipo Microcom- Minicomputa- Main Servicio de Servicio de
putador dor frame computación Tiempo
compartido
Batch
Interno Interactivo
Tiempo real
Batch
Externo Interactivo
Tiempo real
Pre- Batch
planeado Interactivo
Tiempo real
Sistema Existente ______________________
Sistema Manual ______________________
Fig. 2: Un listado de control de tipos de sistemas.
Una vez que se ha generado un conjunto de alternativas básicas, la
elección inicial puede hacerse sobre la base de la factibilidad técnica.
Si, por ejemplo, un sistema requiere un tiempo de respuesta de entre
3 y 4 segundos, puede desecharse cualquier alternativa batch. Si los
programadores no están entrenados en programación interactiva,
deben descartarse los sistemas interactivos. Al final de este proceso,
el analista debe tener un conjunto de alternativas técnicas factibles.
Después debe considerarse la factibilidad operacional y
organizacional. Por ejemplo, el usuario puede oponerse por principio
a un servicio computarizado externo o un servicio de tiempo
compartido. Otra organización puede tener un prejuicio contra un
vendedor particular de hardware, o por un tipo particular de sistema.
La política de la compañía puede estar a favor o en contra de una
situación particular. Básicamente, el analista debe controlar cada
alternativa remanente contra el modo en que la organización hace el
trabajo, y eliminar cualquiera que pueda ser operacionalmente
inaceptable.
Consideremos después la factibilidad económica. Estimemos el costo
de desarrollo y operación de cada alternativa remanente. Estimemos
los ahorros de costos y/o incrementos
Solo debemos considerar en mayor profundidad aquellas
alternativas que producen un retorno positivo de la inversión.
Finalmente, desarrollemos un plan de implementaron, para cada
alternativa que pase las pruebas de factibilidad técnica, operacional y
económica. Este plan no tiene que ser detallado; vincúlelo al ciclo de
vida del sistema, y estime la fecha de terminación para cada fase.
Pagina: 5
6. ESTUDIO DE FACTIBILIDAD
6. Decidir sobre un curso de acción a recomendar. La decisión
clave que surge del estudio de factibilidad es si se continua o se
abandona el proyecto. Indique claramente esta recomendación
clave de “seguir / no seguir”. Asumiendo que la recomendación
es continuar con el proyecto, el analista debe seleccionar la
mejor alternativa, y justificar la elección.
7. Esbozar un plan de desarrollo. Asumiendo que la gerencia
aceptó el curso de acción recomendado, se debe desarrollar un
plan de implementación. Estimar requerimientos de personal, e
indicar cuando serán necesarios analistas, programadores y
otro personal técnico. Estimar el costo de cada etapa en el ciclo
de vida del sistema. Finalmente, provea un plan claro y
detallado y un conjunto de estimaciones de costo para la
próxima etapa, el análisis.
8. Redactar el estudio de factibilidad. Un modelo de un estudio de
factibilidad típico se ilustra en la fig. 3. Recuerde que todos los
estudios de factibilidad son diferentes; este modelo puede
usarse solo como una guía.
9. Presentar los resultados a la gerencia y usuario. La decisión de
asignar fondos al proyecto debe ser tomada por la gerencia, y
no por el analista.
Pagina: 6
7. ESTUDIO DE FACTIBILIDAD
A. Página del Título. Nombre del proyecto, título del informe, autor(es),
fecha.
B. Contenidos. Una lista de las secciones del informe con números de
páginas.
C. Definición del problema. Una descripción del problema clara, concisa
y en una página.
D. Resumen ejecutivo. Un resumen del estudio de factibilidad claro,
conciso y en una página, los resultados y las recomendaciones.
Incluye autorizaciones necesarias, fuentes claves de información,
alternativas consideradas, y alternativas rechazadas. Resalta los
costos, beneficios, restricciones, y tiempo planificado asociado con la
alternativa recomendada.
E. Método de estudio. Una descripción razonablemente detallada de la
estrategia y procedimientos usados en la conducción del estudio de
factibilidad. Mencione sus fuentes y referencias, e identifique al
personal clave. Describa brevemente el sistema existente (si es
apropiado). Gran parte de los detalles están en el apéndice: incluya
solo aquellos directamente relevantes al estudio o a sus conclusiones.
F. Análisis. Un análisis de alto nivel del sistema lógico propuesto.
Incluya una definición de los objetivos del sistema, restricciones, y
alcances; debe ser mas detallado que el desarrollado durante la
definición del problema. Incluye un diagrama de flujo de datos lógico
y tal vez un diccionario de datos elemental para el sistema propuesto.
Identifique interrelaciones claves con otros sistemas.
G. Alternativas consideradas. Para cada alternativa seriamente
considerada, incluya una definición de su factibilidad técnica,
operacional y económica, una estimación del plan de implementación,
un diagrama de flujo de sistema de alto nivel u otra descripción del
sistema. Sea completo, pero no exagere, gran parte del detalle esta
en el apéndice.
H. Recomendaciones. Establezca claramente el curso de acción
recomendado. Provea material para soportar y justificar sus
recomendaciones; en particular, provea un análisis de
costo/beneficio.
I. Plan de desarrollo. Incluya un plan proyectado y los costos
proyectados para cada etapa en el ciclo de vida del sistema,
asumiendo que se seguirá el curso de acción recomendado.
Proporcione estimaciones de tiempo y costo detallados para la
próxima etapa en el proceso, el análisis.
J. Apéndice. Cuadros, gráficos, estadísticas, listas de entrevistas,
resúmenes de entrevistas seleccionadas, diagramas, memos, notas,
referencias, contactos, etc.; en resumen, los detalles que soportan el
estudio. Considere tener el apéndice disponible cuando se necesite.
Fig. 3. Un modelo de un estudio de factibilidad típico.
Pagina: 7
8. ESTUDIO DE FACTIBILIDAD
FASES DEL ESTUDIO DE FACTIBILIDAD
DEFINIR ALCANCES Y OBJETIVOS
FASE 1
ESTUDIO DEL SISTEMA EXISTENTE
FASE 2
DESARROLLAR UN MODELO LÓGICO DEL
SISTEMA ACTUAL
FASE 3
REDEFINIR EL PROBLEMA
FASE 4
DESARROLLAR Y EVALUAR SOLUCIONES
ALTERNATIVAS
FASE 5
DECIDIR SOBRE UN CURSO DE ACCION A
RECOMENDAR
FASE 6
ESBOZAR UN PLAN DE DESARROLLO
FASE 7
REDACTAR EL ESTUDIO DE FACTIBILIDAD
FASE 8
PRESENTAR EL RESULTADO A LA GERENCIA Y
AL CLIENTE
FASE 9
Pagina: 8