Presentación guía sencilla en Microsoft Excel.pptx
análisis y diseño de sistemas
1. DETERMINACIÓN DE LOS REQUERIMIENTOS Y
REQUERIMIENTOS DEL USUARIO.
• La etapa de análisis de un ciclo de vida del desarrollo de un sistema de información
comprende diversas actividades que servirán como fundamento para la
elaboración de las fases posteriores. Dentro de las primeras actividades que se
realizan en esta etapa están: determinar las razones y el alcance que va a tener el
análisis, es decir, los motivos que lo están provocando, así como también conocer
los puntos críticos de los procesos que se tienen en una organización, delimitando
que partes o departamentos de una organización se ven involucradas en el análisis.
Lo anterior con el objeto de que el analista se prepare para realizar el análisis y
pueda definir el problema que tiene la organización, identificando el objetivo a
seguir y seleccionando la información que le sea necesaria para conocer todo
acerca del problema definido. Esta recopilación de la información la ejecutará
utilizando técnicas especiales para este trabajo. Si el analista conoce la gama de
técnicas que tiene para aplicar, podrá escoger la adecuada de acuerdo a la
organización y a la problemática en cuestión. Una vez recopilados los datos se
trabaja en el análisis de los mismos. INTRODUCCIÓN AL ANÁLISIS.
2. DETERMINACIÓN DE LOS REQUERIMIENTOS Y
REQUERIMIENTOS DEL USUARIO.
• La determinación de requerimientos es el conjunto de actividades orientadas
a obtener las características necesarias que deberá poseer el nuevo sistema,
es el estudio de un sistema, actividad o proceso, para comprender como
trabaja y donde es necesario efectuar mejoras o cambios considerables.
Es importante ya que nos permite saber cual es la necesidad del cliente, y así
poder definir alternativas de solución a dicho problema o necesidad y además
es una gran responsabilidad para los analistas de sistemas ya que así pueden
construir su base.
6. DETERMINACIÓN DE LOS REQUERIMIENTOS Y
REQUERIMIENTOS DEL USUARIO.
• Son declaraciones, en lenguaje natural y diagramas, de los servicios
que el sistema proporcione y de las restricciones bajo las cuales deben
funcionar.
7. DETERMINACIÓN DE LOS REQUERIMIENTOS Y
REQUERIMIENTOS DEL USUARIO.
• Requerimiento del usuarios
• Es cualquier acción, característica y regla de negocio dándole la importancia a la
creación del sistema.
• Estos requerimientos se dividen en dos:
• Las funcionales que es toda aquella capacidad de un sistema así mejorando la
necesidad del negocio.
• Las no funcionales se refiere a definiciones adicionales que envuelven los diseños
de las funciones de negocio.
• Dentro de los requerimientos encontramos:
• Acciones, características y reglas de negocio.
8. DETERMINACIÓN DE LOS REQUERIMIENTOS Y
REQUERIMIENTOS DEL USUARIO.
• El análisis comprende un conjunto de procedimientos para determinar
hechos, principios y reglas que se clasifican para disponerlas de manera
ordenada y así mostrar un plan lógico que muestre la unión de las partes en
estudio, también puede definirse como un método, plan o procedimiento de
clasificación para hacer algo o un conjunto o arreglo de elementos para
realizar un objetivo predefinido en el procesamiento de la Información
9. ESTRATEJIA DE FLUJO DE DATOS
• Examina el empleo de los datos para llevar acabo procesos especificación de la
empresa dentro del ámbito de investigación de sistemas.
• Abarca tanto la determinación de los requerimientos como el diseño de
sistemas actual y su análisis por todos los participantes en el proceso
determinado
10. ESTRATEJIA DE FLUJO DE DATOS
• VENTAJAS DEL ANALISIS DE FLUJO DE DATOS
• Los analistas puedes trabajar con los usuarios y lograr que participe en el
estudio.
• Se pueden efectuar las correcciones necesarias al sistema antes de concluirlo.
11. ESTRATEJIA DE FLUJO DE DATOS
• HERRAMIENTAS DE LA ESTRATEGIA DE FLUJO DE DATOS
• 1- Diagrama de flujo de datos
• 2-.Diccionario de datos
• 3-. Diagrama de estructura de Datos
• 4-. Grafica de la Estructura
12. ESTRATEJIA DE FLUJO DE DATOS
• CARACTERÍSTICAS DE LA
ESTRATEGIA DE FLUJO DE DATOS
1.Flujo de datos
2. Procesos
3. Fuente o destino de los datos
4. Almacenamiento de datos
13. FACTIBILIDAD
• Se refiere a la disponibilidad de los recursos necesarios para llevar a
cabo los objetivos o metas señaladas. Generalmente la factibilidad se
determina sobre un proyecto.
• Estos resultados se entregan a la gerencia, quienes son los que
aprueban la realización del sistema informático.
• El estudio de factibilidad, es una tarea que suele estar organizada y
realizada por los analistas de sistemas.
14. FACTIBILIDAD
• Debe mostrarse que el proyecto es factible económicamente, lo que significa
que la inversión que se está realizando es justificada por la ganancia que se
generará. Para ello es necesario trabajar con un esquema que contemple los
costos y las ventas:
Costos: Debe presentarse la estructura de los costos contemplando costos
fijos y variables.
Ventas: En este punto el precio del producto o servicio es fundamental, ya que
determina el volumen de ventas, por lo que debe explicarse brevemente
cómo se ha definido éste. Debe mostrarse también estimaciones de ventas
(unidades y en dinero) para un periodo de al menos 1 año, justificando cómo
se han calculado (a través de investigaciones de mercado, estadísticas
anteriores...)
15. FACTIBILIDAD
• TÉCNICA
• Es una evaluación que demuestre que el negocio puede ponerse en
marcha y mantenerse, mostrando evidencias de que se ha planeado
cuidadosamente, contemplado los problemas que involucra y
mantenerlo en funcionamiento.
16. FACTIBILIDAD
• D E T I E M P O
• En ella se verifica que se cumplan los plazos entre lo planeado y lo real, para
poder llevar a cabo el proyecto cuando se necesite.
17. FACTIBILIDAD
• FACTIBILIDAD LEGAL
• Se trata de determinar la inexistencia de trabas legales tanto en la
etapa
de inversión como en la ejecución del proyecto.
§ASPECTOS AMBIENTALES
§ASPECTOS TRIBUTARIOS
§EN LA PUBLICIDAD
§EN EL USO DEL PRODUCTO
§TÍTULOS DE PROPIEDAD
§REGISTROS DE MARCAS a futuro
18. FACTIBILIDAD
• O P E R A C I O N A L
• Un sistema puede hacer que los usuarios se resistan a él como
consecuencia de una técnica de trabajo, miedo a ser
desplazados, intereses en el sistema antiguo u otras razones.
• Un cambio repentino que se ha anunciado, explicado y
“vendido” a los usuarios con anterioridad puede crear
resistencia. Sin importar qué tan atractivo pueda ser un sistema
en su aspecto económico si la factibilidad operacional indica
que tal vez los usuarios no aceptarán el sistema o que uso
resultará en muchos errores o en una baja en la moral, el sistema
no debe implantarse.
19. REQUERIMIENTO DE ENTRADA
• Es el enlace que une al sistema de información con el mundo y sus usuarios, en esta existen aspectos generales que todos los
analistas deben tener en cuenta estos son:
• Objetivos del diseño de Entrada.
• Captura de Datos para la Entrada.
• Objetivo del Diseño de Entrada
Consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los procesos
necesarios para poner los datos de transacción en una forma utilizable para su procesamiento así como la entrada de los datos
se logra al instruir a la computadora para que lea ya sea documentos escritos, impresos ó por personas que los escriben
directamente al sistema.
Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos, controlar los errores y mantener la
sencillez de los pasos necesarios, estos son:
• Control de la calidad de Entrada
• Evitar los Retrasos
• Evitar los errores en los datos
• Evitar los pasos adicionales
• Mantener la Sencillez del Proceso
20. REQUERIMIENTO DE ENTRADA
• Objetivo DE DISEÑO DE ENTRADA
• Evitar los Retrasos:
También conocido con el nombre de cuello de botella son siempre uno de los
objetivos que el analista evita al diseñar la entrada, una forma de evitarle es
utilizar los documentos de retorno.
Evitar los errores en los datos:
La tasa de errores depende de la cantidad de datos, ya que entre más
pequeña sea esta menores serán las oportunidades para cometer errores. Es
común encontrar en las operaciones de ventas por lo menos un 3% de errores
en las operaciones de entrada de datos.
Evitar los Pasos Adicionales:
21. REQUERIMIENTOS DE ENTRADA
• Es el enlace que une al sistema de información con el mundo y sus usuarios,
en esta existen aspectos generales que todos los analistas deben tener en
cuenta estos son:
• Objetivos del diseño de Entrada.
• Captura de Datos para la Entrada.
22. REQUERIMIENTOS DE ENTRADA
• Objetivo del Diseño de Entrada
• Consiste en el desarrollo de especificaciones y procedimientos para la preparación
de datos, la realización de los procesos necesarios para poner los datos de
transacción en una forma utilizable para su procesamiento así como la entrada de
los datos se logra al instruir a la computadora para que lea ya
sea documentos escritos, impresos ó por personas que los escriben directamente al
sistema. Existen cinco objetivos que controlan la cantidad de entrada requerida, a
enviar los retrasos, controlar los errores y mantener la sencillez de los pasos
necesarios, estos son:
• Control de la Calidad de Entrada
• Evitar los Retrasos
• Evitar los errores en los datos
• Evitar los pasos adicionales
• Mantener la Sencillez del Proceso
23. REQUERIMIENTOS DE ENTRADA
• Control de la Calidad de Entrada:
Existen varias razones por las cuales un buen diseñador debe controlar la
cantidad de datos en la entrada:
- Las Operaciones de preparación y entrada dependen de las personas dado
que los costos de mano de obra son altos y la preparación de ingreso de los
datos también lo son.
- La fase de entrada puede ser un proceso lento que toma mucho mas tiempo
que el que necesitan las computadoras para realizar sus tareas.
24. REQUERIMIENTOS DE ENTRADA
• Evitar los Retrasos:
• También conocido con el nombre de cuello de botella son siempre uno de los
objetivos que el analista evita al diseñar la entrada, una forma de evitarle es
utilizar los documentos de retorno.
Evitar los errores en los datos:
La tasa de errores depende de la cantidad de datos, ya que entre mas
pequeña sea esta menores serán las oportunidades para cometer errores. Es
común encontrar en las operaciones de ventas por lo menos un 3% de errores
en las operaciones de entrada de datos
25. REQUERIMIENTOS DE ENTRADA
• Eviar los Pasos Adicionales:
• Algunas veces el volumen de transacciones y la cantidad de datos en
preparación es algo que no se puede controlar por ello el analista
experimentado, evitara diseños para la entrada que traigan una mayor
cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se alimenta un
proceso muchas veces al transcurso de un día.
En una transacción existen datos importantes y otros que no, el analista debe
saber cuales utilizará y cuales en realidad deben formar la entrada. Existen dos
tipos de datos:
• datos variables
• datos de identificación
26. REQUERIMIENTOS DE SALIDA
• El diseño de sistema se representa a través de dos fases: el diseño lógico y el
diseño físico.
Cuando los analistas formulan un diseño lógico; escriben las especificaciones
detalladas del nuevo sistema; esto es, describen sus características: las
salidas, entradas, archivos y bases de datos y procedimientos; todos de
manera que cubran los requerimientos del proyecto.
El diseño lógico de un sistema de información es como el plano de
un ingeniero para armar un automóvil: muestra las características
principales(motor, transmisión y área para los pasajeros)y como se
relacionan unas con otras(donde se conectan entre sí los componentes del
sistema, o por ejemplo, cuan separadas están las puertas.
27. REQUERIMIENTOS DE SALIDA
• Diseño lógico
• El diseño lógico traduce los escenarios de uso creados en el diseño
conceptual en un conjunto de objetos de negocio y sus servicios. El
diseño lógico se convierte en parte en la especificación funcional que
se usa en el diseño físico. El diseño lógico es independiente de la
tecnología. El diseño lógico refina, organiza y detalla la solución de
negocios y define formalmente las reglas y políticas específicas de
negocios.
28. REQUERIMIENTOS DE SALIDA
• Diseño físico
• El diseño físico es el proceso de traducción del modelo lógico abstracto
a un diseño técnico específico para el nuevo sistema. Produce las
especificaciones reales para el hardware, software y bases de datos
físicas, medios de entrada/salida, procedimientos manuales y controles
específicos.
29. REQUERIMIENTOS DE SALIDA
• Requerimientos de almacenamientos
La memoria de la computadora (RAM) es un lugar provisional de
almacenamiento para los archivos que usted usa. La mayoría de la
información guardada en la RAM se borra cuando se apaga la computadora.
Por lo tanto, su computadora necesita formas permanentes de
almacenamiento para guardar y recuperar programas de software y archivos
de datos que desee usar a diario. Los dispositivos de almacenamiento
(también denominados unidades) fueron desarrollados para satisfacer esta
necesidad.
Los siguientes constituyen los tipos más comunes de dispositivos de
almacenamiento:
Unidades de:
•Disco duro
•Disquete
•Compresión ZIP
•CD
•DVD
30. •
• El volumen de información que se puede visualizar y procesar depende del
módulo seleccionado y del punto de vista desde el que se consulta la
información del módulo. El volumen total de información se obtiene haciendo
la llamada desde la ventana online de la tabla de configuración o desde la
ventana del proyecto. Se puede alcanzar un ámbito limitado de información
con la ventana "Estaciones accesibles".
31. Esta sección debe contener las reglas de negocio que deba cumplir el sistema a
desarrollar, especificadas mediante las plantillas para reglas de negocio propuestas
en MADEJA(Cualquier cosa que está muy enredada, confusa o desordenada.).
Estos requisitos deben especificar qué reglas de negocio debe respetar el sistema,
evitando que se incumplan durante su funcionamiento.
32. •
Requisitos de fiabilidad
Esta sección debe contener los requisitos de fiabilidad que se hayan identificado,
especificados mediante la plantilla para requisitos no funcionales propuestas
en MADEJA(Cualquier cosa que está muy enredada, confusa o desordenada.).
Estos requisitos deberán establecer, de la manera más objetiva y medible
posible, los niveles que debe cumplir el sistema a desarrollar en aspectos como
recuperabilidad y tolerancia a fallos. El sistema deberá tardar un máximo de 10
minutos para la recuperación de un fallo de caída total, en el 95% de las
ocasiones.
33. •
También es importante asegurarse de que los métodos de recolección de
información sean exactos (válidos). La exactitud (validez) se refiere a que un
instrumento o método verdaderamente mida lo que uno cree que está
midiendo. Los investigadores quieren procedimientos exactos o válidos para un
estudio, de manera que los resultados de éste sean útiles y significativos.
Hay muchos elementos que pueden afectar la exactitud (validez) de un
instrumento o método. Entre otros, la adecuación cultural, las bases teóricas
usadas para desarrollar un instrumento o método, y la adecuación del método o
forma de prueba para las capacidades del participante.
34. •
• Los criterios de análisis tecnológico y la posición tecnológica de la empresa
conforman un análisis cualitativo del marco en el que se va a desarrollar el
proyecto. Sin embargo, cualquier directivo reclamará algunos elementos más
para poder tomar una decisión respecto a cada uno de los proyectos de I+D
que se quieran abordar. Esos elementos tienen que definir y valorar de alguna
manera cómo el proyecto contribuye al desarrollo económico de la empresa y
a qué riesgos la somete.
35. •
MANTENIMIENTO
En el ciclo de vida de un proyecto de aplicación informática: software, podemos
caer en el error de pensar que tras la puesta en marcha del proyecto el ciclo
termina junto con los costes del mismo.
APOYO
es una asistencia que brindan las empresas para que sus clientes puedan hacer
uso de sus productos o servicios. La finalidad del soporte técnico es ayudar a los
usuarios para que puedan resolver ciertos problemas.
36. REQUISITOS DE SISTEMAS
• En ingeniería de sistemas existen tres tipos de requerimientos
• Un requerimiento funcional puede ser una descripción de lo que un sistema
debe hacer. Este tipo de requerimiento específica algo que el sistema
entregado debe ser capaz de realizar
37. REQUISITOS DE SISTEMAS
• Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica
algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos
ejemplos de aspectos solicitables son la disponibilidad, el testeo, el
mantenimiento, la facilidad de uso, etc.
• Otros tipos de limitaciones externas, que afectan en una forma indirecta al
producto. Estas pueden ir desde la compatibilidad con cierto sistema
operativo hasta la adecuación a leyes o regulaciones aplicables al producto
38. REQUISITOS DE SISTEMAS
• Una colección de requerimientos describe las características o atributos del
sistema deseado. Se omite el cómo debe lograrse su implementación, ya que
esto debe ser decidido en la etapa de diseño por los diseñadores.
39. •RECQaraUctIeSríIsTticOasS DE SISTEMAS
Los requerimientos bien formulados deben satisfacer varias características. Si no lo
hacen, deben ser reformulados hasta hacerlo
• Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
• No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
• Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de
uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos
importantes
• Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento
diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos
requerimientos debe ser consistente también.
• Completo: Los requerimientos deben contener en sí mismos toda la información
necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
• Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con
el dinero, el tiempo y los recursos disponibles.
• Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue
satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis,
demostración o testeo.
40. REQUISITOS DE SISTEMAS
• Fases de implementación
•
Desde un punto de vista conceptual, las actividades son de 5 clases.
• Obtener requerimientos: A través de entrevistas o comunicación con clientes o usuarios, para
saber cuáles son sus deseos.
• Analizar requerimientos: Detectar y corregir las falencias comunicativas, transformando los
requerimientos obtenidos de entrevistas y requerimientos, en condiciones apropiadas para
ser tratados por el diseño.
• Documentar requerimientos: Igual que todas las etapas, los requerimientos deben estar
debidamente documentados.
• Verificar los requerimientos: Consiste en comprobar el correcto funcionamiento de un
requerimiento en la aplicación
• Validar los requerimientos: Comprobar que los requerimientos implementados se
corresponden con lo que inicialmente se pretendía.