Tarea 2 Analisis PDF

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 11

ANALISIS Y SISTEMAS DE INFORMACION

TAREA Nro. 2

Alumno: Eleazar Alfredo, ALFRIADEZ YRIARTE


Código: 2016704633
Profesor: LIRA CAMARGO JORGE

Para poder dar respuesta a la siguiente tarea paso a brindar el siguiente concepto con
respeto a que es un requerimiento:

“Un requerimiento es una característica del sistema o una descripción de algo


que el sistema es capaz de hacer con el objeto de satisfacer el propósito del
sistema.”

Dicho de otra manera los requerimientos son lo que tantos los usuarios externos y /o
internos, clientes externos y/o internos esperan que haga el sistema.

Por lo tanto las personas encargadas de poder dar viabilidad al desarrollo de los
requerimientos (analistas), deben entender el problema de los usuarios en su cultura y
con su lenguaje y construir el sistema que resuelve sus necesidades.

Así mismo se puede entender que como objetivo de la resolución de un requerimiento


viene a hacer el resolver un problema existente.

Finalmente la elicitación de requerimientos debe ayudar a describir el problema que


motivará a los ingenieros de software a diseñar una solución software de calidad.

Las técnicas habituales pueden dejar de lado aspectos importantes de la organización


debido al enfoque hacia situaciones relacionadas con temas puntuales del entorno de
software.
1. Descripción de personas por medio de técnicas de análisis para el
análisis de los requerimientos (Describe persona by analysis technique to
analyze requirements).

Normalmente, la definición de los requerimientos está redactada en lenguaje natural,


mientras que la especificación de los requerimientos se redacta de una forma más
técnica, por ejemplo, puede definir un requerimiento que se hizo en lenguaje natural,
como una serie de ecuaciones, un diagrama de flujo de datos, casos de uso, etc.

A las personas que participan en esta etapa básicamente su quiere que se puedan
hacer lo siguiente:

Descubrir hechos.

Producir ideas (es la fase de tormenta de ideas propiamente dicha).

Descubrir soluciones.

El análisis estructurado es un método para el análisis de sistemas manuales o


automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o
para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas
abordan una situación poco familiar, siempre existe una pregunta sobre donde
comenzar el análisis. Una situación dinámica siempre puede ser vista como
abrumadora debido a que muchas de las actividades se llevan a cabo constantemente,
como señalo MARY HELEN es su seminario. El análisis estructurado permite el
analista conocer un sistema o proceso (actividad) en una forma lógica y manejable el
mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle
pertinente.

2. Descripción de procesos por medio de técnicas de análisis para el


análisis de los requerimientos (Describe process by analysis technique to
analyze requirements).

El análisis estructurado hace uso de los siguientes componentes.

1. símbolos gráficos

2. diccionario de datos

3. descripciones de procesos y procedimientos

4. reglas

Los métodos formales para el desarrollo de software o, simplemente métodos formales,


son métodos que se utilizan para todas las etapas del ciclo de desarrollo de software y
que tienen la característica que usan formalismos matemáticos para la representación
o derivación de los elementos involucrados en cada etapa.

Algunas de las ventajas que podemos nombrar sobre una especificación formal son las
siguientes:

Prototipado: Las especificaciones formales pueden llegar a ser ejecutables.

Corrección del programa: Verificación automática y formal de que el programa


funciona correctamente.

Reusabilidad: Posibilidad de usar la especificación formal en distintos ámbitos.

En cuanto a la notación, una descripción formal constará de cuatro partes:

•NOMBRE. Nombre genérico del TAD.

•CONJUNTOS. Conjuntos de datos que intervienen en la definición.

•SINTAXIS. Signatura de las operaciones definidas.

•SEMÁNTICA. Indica el significado de las operaciones.

Las distintas notaciones formales existentes difieren en la forma de definir la semántica:


Método axiomático o algebraico. Se establece el significado de las operaciones a
través de relaciones entre operaciones (axiomas). Significado implícito de las
operaciones.

Método constructivo u operacional. Se define cada operación por sí misma,


independientemente de las otras. Significado explícito de las operaciones.

El análisis de flujo de datos utiliza la siguiente. Herramientas.

1. Diagrama de flujo de datos

Una herramienta gráfica se emplea para describir y analizar el movimiento de datos a


través de un sistema, ya sea que este fuera manual o automatizado, incluyendo
procesos, lugares para almacenar datos y retrasos en el sistema. Estos diagramas
reciben el nombre de diagramas lógicos de flujo de datos.

2. Diccionario de datos

El diccionario contiene las características lógicas de los sitios donde se almacenan los
datos del sistema, incluyendo nombre, descripción, alias, contenidos y organización.
También identifica los procesos donde se emplea los datos y los sitios de donde se
necesitan el acceso inmediato a la información. Sirve como puerto de partida para
identificar los requerimientos de las bases de datos durante el diseño del sistema.

3. Diagrama de estructura de datos

Este diagrama es una descripción de la relación entre entidades (personas, lugares,


eventos y objetos) de un sistema y el conjunto de información relacionada con la
entidad. No considera el almacenamiento físico de los datos.

4. gráfica de estructura

Herramienta de diseño que muestra con símbolos la relación entre los módulos de
procesamiento y el software de la computadora describe la jerarquía de los módulos
componentes y los datos que serán transmitidos entre ellos. Incluye el análisis de las
transformaciones entrada - salida y el análisis de transacción.

Desarrollo de diagramas de flujo de datos

Para que de utilidad y proporcionan información los diagramas de flujo de datos deben
dibujarse en forma adecuada. Esta sección muestra como dibujarlos: donde comenzar,
como añadir detalles a las descripciones, cuando incorporar la información sobre el
control y como mantener la consistencia al asignar los nombre s de los objetos
incluidos en los diagramas. La presentación señala también errores comunes que
deben evitarse.

Los diagramas de flujo de datos son de dos tipos:


• Diagramas físicos de datos.

Proporciona un panorama del sistema en uso, que es dependiente de la implantación,


que muestra qué tareas se llevan a cabo y cómo

• Diagramas lógicos de flujo de datos

Proporcionan un panorama del sistema independiente de la implantación, que se centra


en el flujo de datos entre los procesos sin considerar los dispositivos específicos y la
localización de almacenes de datos o personas en el sistema. En este tipo de
diagramas no se indican las características físicas, lo cual si sucede con los diagramas
físicos de flujo.

Un diccionario de datos es un conjunto de metadatos que contiene las características


lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa,
incluyendo nombre, descripción, alias, contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los


analistas que participan en la determinación de los requerimientos del sistema, su
contenido también se emplea durante el diseño del proyecto.

Identifica los procesos donde se emplean los datos y los sitios donde se necesita el
acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y
auxilia a los analistas que participan en la determinación de los requerimientos del
sistema, su contenido también se emplea durante el diseño.

En un diccionario de datos se encuentra la lista de todos los elementos que forman


parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos
de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y
descripción de todos estos elementos

La especificación de procesos, es una herramienta de modelado de sistemas, que


permite definir qué sucede en los procesos o funciones de un sistema. El objetivo es
definir qué debe hacerse para transformar ciertas entradas en cierta salida. No hay una
única forma de realizar la especificación de procesos; existen múltiples herramientas
que facilitan esta tarea, aunque debería emplearse aquellas que permitan fácil
comprensión.

3. Descripción de procesos por medio de técnicas de elicitación para el


análisis de los requerimientos (Describe process by elicitation technique to
analyze requirements).

Este enfoque es el que se utiliza la teoría que presento BABOK (2009) manifiestan que
los requerimientos que podemos encontrar son los siguientes:

Requerimientos de Negocio.
Son declaraciones de alto nivel de metas, objetivos o necesidades de la
empresa.

Requerimientos de los Interesados.

Son declaraciones de las necesidades de un grupo de interesados especial o


clase de grupos de interesados.

Requerimientos de Solución.

Describen las características de una solución que satisface los requerimientos


de negocio y de los interesados.

 Requerimientos Funcionales.

Describen el comportamiento e información que la solución manejará.

 Requerimientos No Funcionales.

Captan las condiciones que no están directamente relacionadas al


comportamiento o funcionalidad de la solución, sino que describen
condiciones del entorno bajo el cual la solución deberá ser efectiva o las
cualidades técnicas que el sistema debe tener.

Requerimientos de Transición.

Describen las capacidades que la solución debe tener con el fin de facilitar la
transición del sistema actual hacia el estado futuro deseado.

Los procesos de negocios son parte de estas necesidades al igual que las estrategias,
la infraestructura o las metas de negocio. Un proceso de negocio es un conjunto
estructurado de actividades, diseñado para producir una salida determinada o lograr un
objetivo.

Los modelos de procesos de negocio se usan para mejorar la comunicación tanto entre
el analista y el desarrollador como entre el analista y el cliente:

En este punto presentare 2 modelos de representación de procesos para la descripción


de procesos por medio de las técnicas de elicitación como son:

El estándar BPMN (Business Process Modelling Notation) abarca los procesos de


negocio sin tener en cuenta otros modelos tales como los de estructura de la
organización, recursos, modelos de datos, estrategias o reglas de negocio.
En el modelado de BPMN se perciben distintos niveles de modelado de procesos
como:

Mapas de procesos.

Diagramas de flujo simples sin detalle con nombre de actividades.

Descripción de procesos.

Proporcionan información más detallada, personas, roles, datos e información.

Modelos de procesos.

Diagramas de flujo mucho más detallados con la intención de analizar el proceso


y simularlo.
Asi mismo se pueden emplear en este punto el mapeo de los procesos empleando
BIZAGI o la representación de casos de uso empleando UML:
4. Descripción de personas por medio de técnicas de elicitación para el
análisis de los requerimientos (Describe persona by elicitation technique to
analyze requirements).

Este enfoque es el más intuitivo y directo, dado que los usuarios tienen la posibilidad de
expresar qué quieren.

Sin embargo, en la práctica se presentan dificultades por diferentes motivos:

• Los usuarios no siempre tienen una idea clara de lo que quieren.

• Pueden presentar dificultad en expresar lo que quieren o en transmitir su


conocimiento.

• Pueden tener diferencias con el analista al utilizan un vocabulario diferente.

• Pueden no desear un sistema de software o un nuevo sistema de software.

Para superar estos problemas potenciales, existen técnicas que posibilitan y facilitan la
comunicación entre el analista y usuarios:

• Entrevistas de comienzo y final abierto: es la forma de interacción más simple


entre analistas y usuarios.

El analista simplemente permite que el usuario hable sobre sus tareas.

Son apropiadas para obtener una visión global de dominio de problema, pero
inadecuadas para obtener información detallada.

• Entrevistas estructuradas: direccionan al usuario hacia aspectos específicos de


requerimientos a elicitar, a través de la realización de preguntas cerradas, abiertas, de
sondeo y de guía. Son útiles para obtener información detallada.

• Brainstorming: el nombre "tormenta de ideas" pretende ser una traducción


circunstancial de "brainstorming" y dar una imagen de esfuerzo y creatividad
cooperativa con la finalidad de encontrar una trayectoria factible, consensual y efectiva
para un problema planteado.

Es una técnica de elicitación grupal, que permite generar numerosas alternativas


gracias al esfuerzo mental, y al aplazamiento del juicio o aceptación de las ideas
generadas, pues la creación de ideas es más productiva si se excluye la crítica.

También podría gustarte