2. JAIME ARROYO CRUZ
SAMANTA CRUZ PINEDO
BRANDON CEPEDA ROSALES
VALERIA ALEXANDRA DEL ANGEL ZAPATA
YARISEL AMAIRANI LARA MARTINEZ
FELIX FRANCISCO MARTINEZ GARCIA
BRYAN OLIVER PORTES ROBLES
3. investigación Preliminar
¿Cuántas veces se está en
situaciones en donde
la pregunta es si no existe
una mejor manera de hacer
algo?
Una organización en
crecimiento, puede
contemplar los sistemas de
información computarizados
como una forma de resolver
sus problemas sin tener
dificultades en sus procesos.
4. Por ejemplo La escuela “Héroes
de Puebla” actualmente
cuenta con 500 alumnos sin
embargo y las inscripciones
cada año son realizadas
manualmente por lo que al
requerir algún reporte en
específico éste es muy difícil de
elaborarlo. Tan solo basta que
alguna persona perteneciente
a la organización solicite un
sistema que permita agilizar el
proceso y genere los reportes
necesarios.
5. Es así como se inicia
esta primera fase del
análisis de sistemas
en el cual se debe
identificar los
problemas,
oportunidades y
objetivos.
Identificación de
problemas. El
analista deberá
observar en forma
objetiva lo que está
sucediendo en una
empresa o negocio,
para posteriormente
hacer resaltar los
problemas ante los
miembros de la
misma.
6. Si un proyecto de sistema
parece ser viable y tiene
suficiente prioridad, se
comienza la investigación
preliminar. Esta investigación
requiere uno o más analistas
de sistemas analizando el
“system request” para
determinar la verdadera
naturaleza y alcance del
problema y recomendar si es
que se debe continuar con el
proyecto.
7. 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:
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13.
Esta fase se ocupa de la
reunión y estudio a
detalle de los datos del
sistema en operación y la
especificación de los
nuevos requerimientos del
sistema a desarrollar.
Concluye en general con
un documento que
recoge el resultado del
análisis.
14. Con la recopilación de
datos se completan los
datos resultantes de la fase
1, añadiendo detalles sobre
el sistema actual. Son
medios comunes para
acometer tal recopilación:
Las entrevistas,
cuestionarios, encuestas a
usuarios finales, así como
también, las consultas a
documentos y manuales
que contengan
lineamientos de
funcionamiento o normas
de procedimientos de
operación
15. Existen varias técnicas y
herramientas útiles para el
análisis de datos. Una de
estas es el uso de diagramas
de flujo de datos para
diagramar la entrada,
proceso y salida de las
funciones de la organización
de manera grafica. Estos
diagramas sirven para
desarrollar el llamado
diccionario de datos, el cual
contiene la definición de los
datos usados en el sistema,
así como sus características
de tipo, tamaño, limitaciones
o especificaciones
especiales.
16. Estos diagramas sirven para desarrollar el
llamado diccionario de datos, el cual
contiene la definición de los datos usados
en el sistema, así como sus características de
tipo, tamaño, limitaciones o
especificaciones especiales.
17. La documentación de la
etapa de análisis recoge
la descripción del
sistema de información
en uso, los
requerimientos para el
nuevo sistema y un
probable plan de
desarrollo en un reporte
dirigido ala gerencia.
Este reporte permite
tomar la decisión de
proseguir o no con el
proyecto.
18. El aspecto más
importante de cualquier
propuesta es identificar y
comprender el
problema que el cliente
busca resolver. Uno de
los puntos del desarrollo
de una propuesta de
solución es presentar
una noción propia del
problema, así como la
propuesta para
resolverlo, con el fin de
convencer al cliente de
que tal propuesta es la
mejor.
19. Para ello, se presentara lo que implica
una descripción de los problemas:
1.- La Naturaleza del problema.
2.- La historia del problema.
3.- Las características del problema.
4.- Las soluciones alternas consideradas.
5.- La solución o la técnica
seleccionada
20. Factibilidad se refiere a la disponibilidad de
los recursos necesarios para llevar a cabo
los objetivos o metas señalados, la
factibilidad se apoya en 3 aspectos
básicos:
Operativo.
Técnico.
Económico.
El éxito de un proyecto esta determinado por
el grado de factibilidad que se presente en
cada una de los tres aspectos anteriores.
21.
22. Estudio de Factibilidad.
Sirve para recopilar datos
relevantes sobre el desarrollo
de un proyecto y en base a
ello tomar la mejor decisión,
si procede su estudio,
desarrollo o implementación.
Objetivo de un Estudio de
Factibilidad.
1.- Auxiliar a una
organización a lograr sus
objetivos.
2.- Cubrir la metas con los
recursos actuales en las
siguientes areas
23. a). Factibilidad Técnica.
Mejora del sistema
actual.
Disponibilidad de
tecnología que satisfaga
las necesidades.
24. b).- Factibilidad Económica.
- Tiempo del analista.
- Costo de estudio.
- Costo del tiempo del
personal.
- Costo del tiempo.
- Costo del desarrollo /
adquisición.
26. DEFINICIÓN DE OBJETIVOS.
La investigación de factibilidad en un
proyecto que consiste en descubrir
cuales son los objetivos de la
organización, luego determinar si el
proyecto es útil para que la empresa
logre sus objetivos. La búsqueda de
estos objetivos debe contemplar los
recursos disponibles o aquellos que la
empresa puede proporcionar, nunca
deben definirse con recursos que la
empresa no es capaz de dar.
27. Reducción de errores y mayor precisión en los
procesos.
· Reducción de costos mediante la optimizacion
o eliminación de recursos no necesarios.
· Integración de todas la areas y subsistemas de
la empresa.
· Actualización y mejoramiento de los servicios a
clientes o usuarios.
· Aceleración en la recopilación de datos.
· Reducción en el tiempo de procesamiento y
ejecución de tareas.
· Automatización optima de procedimientos
manuales.
28. La toma de decisiones es el proceso
mediante el cual se realiza una elección
entre las opciones o formas para resolver
diferentes situaciones de la vida en
diferentes contextos: a nivel laboral,
familiar, sentimental, empresarial (utilizando
metodologías cuantitativas que brinda la
administración). La toma de decisiones
consiste, básicamente, en elegir una
opción entre las disponibles, a los efectos
de resolver un problema actual o potencial
(aun cuando no se evidencie un conflicto
latente).
29. La toma de decisiones a
nivel individual se
caracteriza por el hecho
de que una persona haga
uso de su razonamiento y
pensamiento para elegir
una solución a un
problema que se le
presente en la vida; es
decir, si una persona tiene
un problema, deberá ser
capaz de resolverlo
individualmente tomando
decisiones con ese
específico motivo.
30. Para tomar una decisión, cualquiera
que sea su naturaleza, es necesario
conocer, comprender, analizar un
problema, para así poder darle
solución. En algunos casos, por ser
tan simples y cotidianos, este
proceso se realiza de forma implícita
y se soluciona muy rápidamente,
pero existen otros casos en los cuales
las consecuencias de una mala o
buena elección pueden tener
repercusiones en la vida y si es en un
contexto laboral en el éxito o fracaso
de la organización, para los cuales es
necesario realizar un proceso más
estructurado que puede dar más
seguridad e información para
resolver el problema. Las decisiones
nos atañen a todos ya que gracias a
ellas podemos tener una opinión
crítica.
31. Son aquellas que se toman
frecuentemente, es decir son repetitivas y
se convierte en una rutina tomarlas; como
el tipo de problemas que resuelve y se
presentan con cierta regularidad ya que se
tiene un método bien establecido de
solución y por lo tanto ya se conocen los
pasos para abordar este tipo de
problemas, por esta razón, también se las
llama decisiones estructuradas. La persona
que toma este tipo de decisión no tiene la
necesidad de diseñar ninguna solución,
sino que simplemente se rige por la que se
ha seguido anteriormente.
32. También denominadas no estructuradas,
son decisiones que se toman ante
problemas o situaciones que se presentan
con poca frecuencia, o aquellas que
necesitan de un modelo o proceso
específico de solución, por ejemplo:
“Lanzamiento de un nuevo producto al
mercado”, en este tipo de decisiones es
necesario seguir un modelo de toma de
decisión para generar una solución
específica para este problema en
concreto.
33. Las decisiones no programadas
abordan problemas poco
frecuentes o excepcionales. Si
un problema no se ha
presentado con la frecuencia
suficiente como para que lo
cubra una política o si resulta
tan importante que merece
trato especial, deberá ser
manejado como una decisión
no programada. Problemas
como asignar los recursos de
una organización, qué hacer
con una línea de producción
que fracasó, cómo mejorar las
relaciones con la comunidad –
de hecho, los problemas más
importantes que enfrentará el
gerente –, normalmente,
requerirán decisiones no
programadas.
34. Problemas como
asignar los recursos de
una organización, qué
hacer con una línea de
producción que
fracasó, cómo mejorar
las relaciones con la
comunidad –de hecho,
los problemas más
importantes que
enfrentará el gerente –,
normalmente,
requerirán decisiones
no programadas.
35. Es el estudio de un sistema para conocer
como trabaja y donde es necesario
efectuar mejoras
¿Como se determinan los requerimientos?
Se determina de forma para capturar o
procesar datos, producir información,
controlar una actividad empresaria o
brindar soporte a la gerencia.
36. Por qué es frecuente que
los analistas se
encuentren en
desventaja en relación
con los gerentes de
departamento cuando se
conducen una
investigación de
sistemas?
Los analistas corren el
riesgo de no comprender
adecuadamente la razón
de una actividad y darle
mayor o menor
importancia de la que
tiene en el sistema, a
menos que conozcan
que es lo que inicia la
actividad.
37. Ahora se trata de formalizar los
requerimientos; el documento
obtenido en la etapa anterior se
tomara como punto de partida
para esta fase. Su contenido es
aun insuficiente y lleno de
imprecisiones que será
necesario completar y depurar.
El aspecto fundamental del
análisis de sistemas es
comprender todas las facetas
importantes de la parte de la
empresa que se encuentra bajo
estudio. (Es por esta razón que
el proceso de adquirir
información se denomina, con
frecuencia, investigación
detallada). Los analistas, al
trabajar con los empleados y
administradores, deben estudiar
los procesos de una empresa
para dar respuesta a las
siguientes preguntas clave:
38. 1.- ¿Qué es lo que se hace?
2.- ¿Cómo se hace?
3.- ¿Con que frecuencia se presenta?
4.- ¿Qué tan grande es el volumen de
transacciones o de desisciones?
5.- ¿Cuál es el grado de eficiencia con
el que se efectúan las tareas?
6.- ¿Existe algún problema?
7.- Si existe un problema, ¿Qué tan serio
es?
8.- Si existe un problema, ¿Cuál es la
causa que lo origina?
39. Para contestar estas preguntas, al
analista conversa con varias
personas para reunir detalles
relacionados con los procesos de
la empresa, sus opiniones sobre
porque ocurren las cosas, las
soluciones que proponen y sus
ideas para cambiar el proceso. Se
emplean cuestionarios para
obtener esta información cuando
es posible entrevistar, en forma
personal, a los miembros de grupos
grandes dentro de la organización.
Asimismo, las investigaciones
detalladas requieren el estudio de
manuales y reportes, la
observación en condiciones reales
de las actividades del trabajo y, en
algunas ocasiones, muestras de
formas y documentos con el fin de
comprender el proceso en su
totalidad.
40. 1. Definir la metodología adecuada
para el desarrollo del software
41. 2. Obtener los requerimientos y realizar el
análisis de los mismos, puedes utilizar
Árbol de Decisiones o Tablas de
Decisión, diagrama de flujo de datos
entre otras.