El documento presenta los pasos para realizar un estudio de factibilidad de un sistema de información. Explica que un estudio de factibilidad comprime el proceso completo de análisis y diseño para determinar si un proyecto es factible técnica, económica y operacionalmente. Detalla los pasos típicos como definir objetivos, analizar el sistema existente, desarrollar soluciones alternativas y redefinir el problema con nuevos conocimientos. También introduce conceptos como el ciclo de vida de los sistemas, los modelos ló

1. Instituto Universitario de Tecnología
“Antonio José de Sucre”
Estudio De Factibilidad.
24/07/2013
Alberlis Vasquez 24.159.956
José Tua 20.017.686

2. Introducción
En la siguiente presentación de dará a conocer los casos de Estudio de
Factibilidad, su diseño, sus métodos, pasos, el Ciclo de Vida de lo Sistemas de
Información, el Estudio de Factibilidad en los Sistemas de Información, entre
otras cosas que verán mas adelante en la presentación realizada.

3. 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.
Al menos se pueden considerar tres tipos diferentes de factibilidad:
Técnica: ¿Puede implementarse el sistema usando la tecnología
actual?
Económica: ¿Los beneficios superan los costos?
Operacional u organizacional: ¿Puede implementarse el sistema en
esta organización?
Para cada solución factible, el analista prepara una planificación
preliminar de la implementaron, luego de esto se le presenta al gerente y
seguidamente al usuario.
Pasos para el estudio típico de Factibilidad.
Definir los alcances y objetivos del sistema.
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?.
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?.
Estudio del sistema existente
Esto se da 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 no de tendría que modificar nada si el programa o el sistema
existente esta en un buen estado y aun funciona como debe de funcionar.
Por consiguiente tenemos que analizar cuidadosamente los procedimiento y
la información escrita. Aprendamos que hace el sistema y el porque lo hace de
esa manera.

4. 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
Redefinir el problema a la luz de los nuevos conocimientos.
En este paso o fase el analista debe tener la definición del problema, el
alcance y los objetivos con el personal clave para esto. Si el analista no ha
entendido y el usuario tampoco o a pasa por alto algunas cosas, ahora es el
momento de solucionarlo
.
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.
“Piense a los primeros cuatro pasos del estudio de factibilidad
como un todo.”
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.
El estudio de Factibilidad de los S.I.
Diseños de Sistemas de Información.
A partir de este paso el analista y el diseñador del sistema en conjunto
con el usuario, deben de encontrar una solución que conviertan los requisitos
encontrado en la fase de análisis de sistema en un sistema real.
El análisis de sistema se centraba en lo que se debe hacer, es decir, en
los requisitos del sistema desde el punto de vista de los usuarios, mientras que
el diseño se enfoca en lo que se tiene que realizar. Por lo tanto en la etapa de
diseño se debe de investigar que datos se usaran y como se alcanzaran.

5. Inicio de un Nuevo Sistema
Planificacion de
Sistemas
Analisis del
Sistema aCTUAL
Analisis de
Requisitos
Diseño Logico
Diseño Fisico
Implementacion

6. Para el alcance de estos objetivos, la etapa de diseño esta comprendida
por 2 fases.
Diseño lógico del nuevo sistema.
Diseño físico del nuevo sistema.
Diseño lógico del nuevo sistema.
Es la fase donde se debe de enlazar o llevar a cabo lo que el usuario
desea, y de esta manera levarlo al la fase 2 que seria llevar el sistema a lo
físico, es decir, a lo que se llamaría sistema funcional.
Diseño físico del nuevo sistema.
Es donde el diseño lógico se pone en marcha donde se le harán
correcciones necesarias para que el usuario pueda disfrutar del sistema
correctamente.
Relación entre los sistemas.
Modelo Lógico Modelo Físico
Modelo de Datos Representación de la
estructura y la relación de
los datos esenciales
Representación de las
estructura y las relaciones
de los datos para la
implementación del
diseño lógico
Modelo de Procesos Representación de los
procesos y los flujos de
datos esenciales
Representación de los
flujos de los datos para
implementar el modelo
lógico de los datos del
proceso.

7. Ciclo de vida de un sistema informático
Estudio de
Factibilidad
Análisis de
Requerimiento
Diseños
Creación de
PROTOTIPOS
Implementación
Validación y Prueba
Operación y
Mantenimiento

8. Es el tiempo que vive un sistema desde el momento en que es pensado
hasta que muere o no es útil
Las actividades típicas del ciclo de vida son:
 Reconocimiento del problema
 Estudio de factibilidad
 Análisis
 Diseño
 Implementación (Codificación)
 Prueba
 Mantenimiento
Reconocimiento del problema: Surge cuando el usuario reconoce que
tiene problemas con los medios con que cuenta actualmente para llevar a
cabo su trabajo. Así comienza esta fase que trata de reemplazar el sistema
existente por otro. En esta fase interviene totalmente el usuario.
Estudio de la factibilidad: Se decide si el usuario necesita o no una
computadora. Este estudio sirve para:
- Identificar los problemas con el sistema actual.
- Identificar el alcance del sistema a ser estudiado.
-Identificar los principales objetivos del nuevo sistema.
- Identificar un número de soluciones que pueden satisfacer las necesidades
del usuario dentro de su esquema.
- Desarrollar estimados de los beneficios y desventajas de cada solución.
- Desarrollar esquemas de cómo puede llevarse a cabo el proyecto teniendo
una idea de los recursos que se requieren.
-Obtener puntos de vista del usuario y el administrador sobre las
Modificaciones.
- Obtener una decisión de si se lleva a cabo la parte de análisis.
Todo este estudio evitará el gasto de un análisis de un proyecto imposible. En
él intervienen el usuario y el analista.
Análisis: Es la fase de diseño externo. Consiste en cuestionar al usuario sobre
qué hace el sistema, qué características extras él quiere en su nuevo sistema y
qué restricciones debe satisfacer. La salida del análisis debe incluir una
especificación funcional y un análisis estructurado que contiene los
requerimientos para el nuevo sistema, los cuales el usuario debe leer, analizar
y señalar lo que él quiere.
Diseño: Es la fase de diseño interno. Consiste en definir cómo organizar lo
anterior de forma adecuada para la ejecución. Incluye la realización de

9. diagramas de estructura, explicaciones del programa, etc. (diseño
preliminar). Posteriormente se lleva a cabo un diseño detallado donde se
describen las especificaciones de los módulos.
Implementación: Es la fase de programación o escritura del código. Lo que se
produce en el diseño se lleva a código.
Prueba: En esta etapa se planea el diseño de casos de prueba con el fin
de "asegurar" la co-rectitud de los programas.
Modelos de caso de uso
Un caso de uso es una secuencia de interacciones que se desarrollarán
entre un sistema y sus actores en respuesta a un evento que inicia un actor
principal sobre el propio sistema.
Relación: es una conexión entre los elementos del modelo, por ejemplo la
especialización y la generalización son relaciones
Actor: es toda entidad externa al sistema que guarda una relación con este
y que le demanda una funcionalidad. Esto incluye a los operadores
humanos pero también incluye a todos los sistemas externos así como a
entidades abstractas como el tiempo.
Tipos de relaciones
Comunica (<<communicates>>): Asociación entre un actor y un caso de
uso que denota la participación del actor en dicho caso de uso.
usa (<<uses>>) (o<<include>> en la nueva versión de UML): Relación de
dependencia entre dos casos de uso que denota la inclusión del
comportamiento de un escenario en otro.
extiende (<< extends>>): Relación de dependencia entre dos casos de uso
que denota que un caso de uso es una especialización de otro. Por ejemplo,
podría tenerse un caso de uso que extienda la forma de pedir azúcar, para
que permita escoger el tipo de azúcar (normal, dietético o moreno) y
además la cantidad en las unidades adecuadas (cucharadas o bolsas).
“El modelo de casos de uso es la combinación de casos de uso y sus
correspondientes diagramas.”

10. Pasos para la Definición de un Caso de Uso:
ID
NOMBRE
REFERENCIAS CRUZADAS
CREADO POR
ULTIMA ACTUALIZACION POR
FECHA DE CREACION
FECHA DE ULTIMA ACTUALIZACION
ACTORES
DESCRIPCION
TRIGGER
PRE-CONDICION
POST-CONDICION
FLUJO NORMAL
FLUJOS ALTERNATIVOS
INCLUDES
FRECUENCIA DE USO
REGLAS DE NEGOCIO
REQUERIMIENTOS ESPECIALES
NOTAS Y ASUNTOS
Normas de aplicación
Los casos de uso pretenden ser herramientas simples para describir el
comportamiento del software o de los sistemas. Un caso del uso contiene una
descripción textual de todas las maneras que los actores previstos podrían
trabajar con el software o el sistema. Los casos del uso no describen ninguna
funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se
implementará. Simplemente muestran los pasos que el actor sigue para realizar
una tarea.
Un caso de uso debe:
describir una tarea del negocio que sirva a una meta de negocio
tener un nivel apropiado del detalle
ser bastante sencillo como que un desarrollador lo elabore en un único
lanzamiento
Situaciones que pueden darse:
Un actor se comunica con un caso de uso (si se trata de un actor primario la
comunicación la iniciará el actor, en cambio si es secundario, el sistema será el
que inicie la comunicación).
Un caso de uso extiende otro caso de uso