Andrés

Álvarez Icaza Castañeda - 1217158

José Luís Pelayo Alvarado - 1221792
Guillermo N. Cabrera Zumaya - 1200209

27/02/2017

Análisis de Sistemas

Fases del Análisis de Sistemas

Emma Sofía Castillejos Caballero

Fase de Definición de Alcance

En esta fase es donde se plante a través de diferentes pasos si el proyecto a realizar
vale la pena. Esto se determina en función a la problemática planteada, las
oportunidades que se pueden lograr, así como los diferentes caminos que se pudieran
tomar a causa del proyecto.

Aquí se tiene como interés la visión del Propietario del sistema ya existente puesto que
es el que está lidiando con cierto problema y por eso requiere de ya sea una mejora o de
un sistema nuevo.

Con ayuda de diagramas de tarea se planifica el trabajo que debe ser elaborado para
completar esta fase y proseguir con la siguiente fase del análisis del sistema, esto ayuda
mucho ya que subdivide esta fase en subprocesos a completar para tener un éxito
garantizado puesto que no estaríamos saltándonos ningún paso necesario para finalizar
nuestro análisis de sistemas.























Como se muestra en el diagrama, el resultado de esta fase es un Diagrama de proyecto
en el cual se describe el alcance del proyecto, sus metodologías y los estándares que se
manejaran en este.

Esta fase puede ser completada en un lapso de 2 a 3 días, y comprende:

1.1 Identificar problemas y oportunidades

Se establece lo que es una base inicial, oportunidades y alcances que originan la idea
del proyecto.

La mayoría de los participantes se les hace llamar como propietarios del sistema a
excepción de los analistas de sistemas o administradores de proyecto; entre los cuales
están los patrocinadores ejecutivos, los administradores de un rango alto, que serán los
que o apoyen el proyecto o lo financien y también incluye a los administradores de
diferentes posiciones en la empresa.

Una solicitud de proyecto o asignación es la primera tarea a realizar y puede ser tan
simple como un memorándum de autoridad emitido por un comité de dirección de
sistemas de información o de una unidad de negocios que solicite el servicio.

El resultado de esta tarea es la Definición del problema y se guarda en el repositorio.

URGENCIA : ¿CUANTO TARDARA EN
RESOLVERSE EL PROBLEMA?

DEFINICION DEL PROBLEMA

VISIBILIDAD: ¿EN QUE PUNTO SERA

VISIBLE LA SOLUCION?

BENEFICIOS : ¿QUE TANTO

INCREMENTARA O REDUCIRA LA
SOLUCION LOS INGRESOS ANUALES Y
LOS COSTOS?

PRIORIDAD: ¿CUALES SON LAS

PRIORIDADES ACORDADAS?

SOLUCIONES POSIBLES: SE CONTESTAN

CON TERMINOS SIMPLES
1.2 Negociar el alcance base

Se definen los límites del proyecto; aspectos que se incluirán o no en el proyecto. Estos
pueden cambiar a lo largo del proceso, pero es muy necesario tener un límite
predeterminado para poder comenzar y saber desde un principio hasta donde podemos
llegar.

Aquí se toma la tarea Definición de problema preliminar generada en el paso anterior

puesto que nos ayudara a establecer una base del problema preliminar con alcance.

Se puede definir fácilmente dentro de términos del sistema de información, como:

¿Qué tipo de datos se usan para describir al sistema?
¿Qué procesos de negocios se incluyen en el sistema?
¿Cómo debe de ser la interfaz a utilizarse?

1.3 Evaluar el beneficio del proyecto

Aquí es donde los Propietarios del sistema incluyendo al patrocinador ejecutivo y los
gerentes y los de sistemas de información toman la decisión si el proyecto sigue adelante
o no. Y esto lo hacen en base a los datos recabados anteriormente. Es donde se
preguntan si vale la pena el proyecto o no. Si el proyecto es aprobado o cancelado se
entra en una negociación para poder llegar a un acuerdo y determinar el alcance del
proyecto y puede que aumente o también puede que disminuya de lo que se tenía
contemplado en un principio.

Apartar de la decisión si el proyecto se considera valioso podemos continuar con el

siguiente paso y a su vez podemos seguir con las siguientes fases del análisis del
sistema sino hasta aquí se deja y todo.

Independientemente del resultado se documenta todo y se guarda en el repositorio,

porque en el caso de que se haya rechazado o cancelado puede que en un futuro esa
información pueda servir de nuevo y queda registrada como antecedente.

1.4 Desarrollar un programa y presupuesto

Como el proyecto se consideró valioso para la empresa se puede continuar y planearlo.
El proyecto inicial debe de contener lo siguiente:

• Un plan maestro preliminar donde se exponga cada programa y asignación de los

recursos que se necesitaran para poder completar el proyecto y se actualizara al
finalizar de cada fase, se le denomina Baseline Plan.
• De un plan detallado, así como su programa para poder completar la fase de
análisis del problema.

Aquí entra en juego el Administrador de proyectos y es útil que incluya elementos de los
Propietarios del sistema, así como de los usuarios, de los constructores y diseñadores
de sistemas, dando como salida El Plan Y Programa Del Proyecto Base 
y se anexa al
repositorio para seguirlo actualizarlo con forme avanzamos en el proyecto.

Este se puede hacer a partir de un software especializado en la administración de

proyectos.

1.5 Comunicar el plan de proyecto

Puesto que puede que no seamos los únicos con un proyecto aprobar en la organización
se hace una presentación formal y se justifica nuestro proyecto ante un Comité de
dirección para que lo apruebe; quienes también están al pendiente de su progreso.

Los integrantes del Comité de dirección pueden estar constituidos por ejecutivos o
administradores no relacionados con el área de sistemas de información. Hay
organizaciones que designan a alguien especialmente para que sea la persona
encargada de mantener informados al vicepresidente del comité de dirección.

Es importante mantener una comunicación constante para los proyectos con los diversos
miembros del Comité de direcciones y otros.

Puede ser mediante la elaboración de una página web y estarla actualizando con forme
avanza el proyecto.





Fase de Análisis del Problema
2.1 Entender el dominio del problema

En estos casos de dominios, se trabaja en equipos y el objetivo es conocer el sistema
actual. Se puede decir que el problema es las diferencias entre personas, como ejemplo,
las opiniones, percepciones, vocabulario y detalles. El equipo consta de propietario,
usuario y un analista de sistemas, pero a pesar de los problemas que se causan entre
sí, lo importante es entender y estudiar los problemas que persisten en dicho dominio.

Esta tarea se dirige por un administrador, donde el analista de sistemas coopera con la
tarea y ayuda a hacerlo más fácil. La manera en que pueden ayudar los analistas es por
la información que obtienen… Ellos son quienes participan en juntas, realizan entrevistas
y documentan la información.

Cuando se lleva a cabo un proyecto o una tarea, es importante asociar o incorporar a un

grupo de personas, entre ellos, los propietarios y los usuarios del sistema donde ellos
podrían apoyar al sistema, e inclusive se puede aceptar a usuarios “experimentados”
donde pueden hacer su papel de analistas durante el proyecto, pero estas acciones son
un poco raras de hacer.

Llega un punto donde ciertas decisiones tiene que ser tomadas por los propietarios para
saber si se seguirá avanzando con el proyecto o no, dependiendo de qué tanta ventaja
tenga el seguir o no de la tarea.

Para definir lo que es dominio del sistema, se parten en tres puntos, los cuales son
“conocimiento”, “procesos” y “comunicaciones”.

• Conocimiento se refiere al almacenamiento de datos, o sea, una base de datos.

Con esto se puede listar toda la información disponible de lo que se ha producido por el
sistema.
• Proceso define la respuesta para cada acción que se solicita en el sistema. Como
ejemplo, un negocio donde una clienta solicita de un nuevo pedido.
• Comunicaciones viene siendo la ubicación de cada sistema actual sobre cada
usuario en el sistema de un negocio.

Para facilitar la compresión de estas taras, lo que se puede realizar es una organización
de cómo se estructurará el sistema, para verificar que funcione y cumpla con los
requisitos que se piden. Para poder facilitar el desarrollo de la estructura, se pueden
realizar unos diagramas de flujo donde estas facilitan al equipo entender las entradas y
salidas de información del sistema. Esto no quiere decir que solamente se necesita de un
diagrama para realizar un sistema, pero es un “paso sólido”.

2.2 Analizar problemas y oportunidades

Nos podríamos cuestionar… ¿Qué no se supone que está la fase anterior para
diagnosticar problemas? En parte sí, pero en realidad no se analizan del todo los
problemas. Es difícil analizar los problemas porque es muy probable que la respuesta
sea errónea a lo que se cree que causa el problema. Lo que analistas intentan hacer, es
responder a los que los usuarios dicen, “necesitamos” o “queremos” y para esto lo que
se hace percibir las causas y efectos de la situación.

Este análisis de causa y efecto, nos puede hacer entender ciertas cosas del sistema que
nos pueden hacer encontrar soluciones creativas y valiosas.

2.3 Analizar los procesos del negocio

Esta tarea se debe de realizar cunado hay problemas con procesos y se necesita
rediseñar.
Los analistas son quienes cooperan en esta tarea y los únicos participantes son los
propietarios y los usuarios de sistemas.

Para la solución de esta, no siempre se requiere de comprar tecnología, o personas

“sabelotodo”, solo con tener cierto conocimiento del dominio del problema basta.
Los productos de esta tarea son “modelos de procesos” y “análisis de procesos”.

Se pueden realizar muchos diagramas, pero a excepción de estos dos productos, se

muestra de manera característica, el volumen de datos, el tiempo de respuesta y “cuellos
de botella” en los sistemas. También se muestra el costo de cada proceso, el valor
agregado a cada profeso y las consecuencias de las eliminaciones de cada proceso.

2.4 Establecer objetivos de mejora del sistema

En esta tarea, la intención es tomar en cuenta todas las mejoras que puedan existir para
una mejora del sistema. Estas se basan por medio de objetivos, que estos representan
el intento de establecer expectativas de un sistema nuevo. “No todo es de color rosa”,
también hay restricciones que regulan a los objetivos llegar a una mejora.
Las restricciones se dividen en 4 categorías:
• Programa: Se debe establecer fechas límites
• Costo: Se debe establecer límites de costo
• Tecnología: Se deben de cumplir ciertos requisitos
• Política: Se debe manejar de cierta forma

2.5 Actualizar o refinar el plan del proyecto

En cuanto a alcance que se planea desde un principio, debemos de recordar que esta
puede cambiar conforme se cambian los planes en el desarrollo del sistema. El nuevo
sistema que se está implementando puede ser más grande de lo que se espera y puede
necesitar de la modificación del alcance para poder cumplir con los límites establecidos,
como la mayoría de casos, se refiere a que tiene una fecha límite.

Debemos de tomar en cuenta que únicamente los analistas de sistemas y los

propietarios, ellos son los individuos fundamentales para esta tarea.

2.6 Comunicar resultados y propuestas

¡Debemos recordar que la comunicación es clave para un proyecto exitoso!

Todos los usuarios, o, mejor dicho, cada integrante del equipo que se relaciona con el
proyecto, deberá de estar al tanto sobre los cambios que suceden. Hay muchas maneras
de facilitar esto, pero una de ellas y la más común, es el internet.

Los temas que se comunican, o por lo menos se deberían de comunicar, son los análisis
de problemas, modelo de sistemas y los objetivos de mejora de sistemas. Los trabajos o
presentaciones de estas pueden ser escritas o verbales siempre y cuando sea validado
por un auditor o grupo de compañeros, que en otras palabras se le llama “grupo de
revisión”.

Fase de Análisis de Requerimientos

Esta es una fase sumamente importante ya que en esta se lleva a cabo la definición de
los requerimientos del nuevo sistema para los negocios, principalmente esta fase
responde a las necesidades y deseos de los usuarios que esto conlleva al éxito de
cualquier nuevo sistema, aparte de que esta fase no se puede saltar por ningún motivo
por qué es lo que cumple la necesidad del cliente, en la siguiente figura se mostraran los
procesos básicos del análisis de requerimiento.

3.1 Identificar y expresar requerimientos del sistema

En esta tarea es la continuación del análisis de problemas cuando ya encontramos un
objetivo para mejorar, aunque en pocas palabras, esta tarea traduce los esquemas de
requerimiento funcional y no funcional, que son la definición de casi todos los
requerimientos del sistema a desarrollar, aunque no abarque todos esto ayudara a
enmarcar los próximos requerimientos.

Esta tarea empieza cuando se da la aprobación de mejora por parte de los propietarios,
los que están principalmente involucrado en el proceso de requerimientos son los
usuarios que lo utilizaran, pero en si el único objetivo de esta tarea es obtener los
requerimientos funcionales y no funcionales, a lo cual los analistas recientemente usan
un método de uso de caso en el requerimientos funcionales que conlleva a crear un
escenario para que se dé solución a un problema definitivo y a partir de ese dar inicio a
un nuevo sistema o mejor el establecido.

3.2 Priorizar los requerimientos de sistema

En esta tarea lo primordial es dar satisfacción al usuario y al propietario con sus
requerimientos, en caso de que estemos atrasados o estemos cortos de presupuesto,
ellos mismos no tienen que ayudar a priorizar, una vez hecho esto se es más fácil trabajar
con los requerimientos con una técnica llamada “timeboxing” que simplemente es acotar
y aclarar definitivamente pequeñas partes de los requerimientos.

Un punto de apoyo en acotar o priorizar los requerimientos son los analistas junto al
grupo de propietarios y usuarios, pero esto conlleva a dos tipos de requerimientos el
obligatorio es que se tiene que estar solucionado desde la versión 1.0 del sistema para
que no se tengan problemas y el deseable que este nos dice que no están esencial pero
que si se tiene que solucionar en alguna de las versiones futuras.

3.3 Actualizar o refinar el plan del proyecto

Una vez que ya se hayan definido correctamente los requerimientos de sistemas
tenemos que tomar un retorno a alcance del proyecto y redefinirlo o actualizarlo ya sea
porque el nuevo sistema poder ser más grande de lo que se pensó en un principio y el
presupuesto o el tiempo pueden variar, ya que se haya hecho esto se necesita una
revisión para su aprobación por parte del propietario o administrador del proyecto ya que
los requerimientos pueden exceder una visión que tenían a un principio y para esto deber
acortar el alcance o incrementar el presupuesto para realizar el trabajo.
3.4 Comunicar la definición de requerimientos

Esta tarea es la que más continuidad tiene durante el proyecto, es en la cual se
comunican entre sí los administradores del proyecto, el patrocinador, y los usuarios, que
ayudar a medir las diferentes opiniones del trabajo, en ciertas empresas incluso se llega
a tener un portal por medio de la intranet para que este proceso o tarea se facilite
transmitiendo mensajes o documentos, para así, poder realizar correctamente esta tarea
en la cual se debe tener habilidades interpersonales.

3.5 Manejo de requerimientos permanentes

En esta parte nos menciona que se solían dejar los requerimientos de manera estática
para poder pasar a las siguientes fases del proyecto, pero en la economía actual un
negocio tiene que tener la capacidad de adaptarse o actualizarse con rapidez que esto
conlleva que los requerimientos también tienen que ser flexibles, pero para esto se tiene
que llevar con control de registro, rastreo y ver cuando se evaluaran para posteriormente
satisfacer esta necesidad.


Para retocar ciertos puntos de los ya mencionados, se indagó en el internet y libros
electrónicos para obtener una información más completa sobre cómo es que funciona o
se llevan a cabo estos temas.

Diseño Lógico

Se podría decir que un diseño lógico es lo que hace funcionar un negocio. La razón por
la cual se dice que lo hace funcionar, es porque le facilita al usuario la manera de usar el
programa, así logrando sus deberes en su trabajo. Lo que sucede al momento de usar
un programa, es que todo está de manera gráfica, mientras que este tiene una acción
para cada botón.

Lo que está sucediendo al momento que se usa un programa, es que cada botón tiene
una acción. Esto quiere decir que en un segundo plano se ejecuta un código orientado a
objetos, así elaborando una base de datos.

En esta etapa se relaciona con la creación de los esquemas conceptuales y externos de

las bases de datos.

Está el modelo racional, donde los datos son organizados y representados en forma de
relaciones o en tablas… Ej. la vez que se nos pidió realizar una tabla sobre las diferentes
fases y relacionarlas entre cada una o de igual manera, se puede imaginar una base de
datos de Access (programa de Microsoft Office).

A continuación, se mostrará un ejemplo gráfico para entender el concepto de este modelo

racional.

Representación Lógica Representación Física Modelo Relacional

Archivo Secuencial Relación

Tabla

Registro Tupla
Fila

Campo Atributo
Columna
Nota: Tupla en cuanto programación, se refiere a la agrupación de ciertos valores que deben de ir
juntos. Como ejemplo, puede ser el nombre y apellido de una persona.



¿Qué significa la relación de Atributo, con dominio y Tupla?

La relación de atributo es elemento capaz de obtener el valor de las columnas de la tabla.

El dominio es el grupo de elementos que puede tomar el atributo donde se puede tomar
en cuenta un infinito de elementos y la tupla es la petición de cada relación de los
elementos.

Validación de Requerimientos Funcionales

Antes de que el programa esté listo para su uso, se debe de asegurar que este pueda
ejecutarse sin problema alguno. La interacción con los usuarios que son quienes suelen
usar en la mayor parte del tiempo el programa del que se habla, puede ser de gran
utilidad.

Análisis de Decisión
La pretensión del análisis de decisión es identificar las alternativas presentes y
analizarlas. Una vez analizadas se podrá recomendar que opción es la mejor para cierto
caso y después se podría implementar un diseño y/o estructura de datos para realizar
una mejora en el sistema o programa.

Lo que funciona muy bien en estas tareas son las ideas. Los analistas de sistemas son
quienes colaboran la mayor parte en estos casos, mientras que las ideas provienen de
diseñadores, constructores de sistemas, usuarios y propietarios.

Una base de datos relacional es un conjunto de datos con unos requisitos necesarios,
estos son: restricción de integración y esquema de la base de datos.
La restricción de integración es lo que mantiene el lenguaje o código de una base de
datos en consistencia. Lo que se quiere realizar es mantener una seguridad en los datos
de las bases de datos para evitar perdida de información, aunque sea eliminada por
personas autorizadas para modificar dicho código.

Después de tener todas las soluciones alternativas, se deberán de comparar y elegir una
o más opciones como las mejores. Esta o estas opciones elegidas se deberán de
recomendar a los propietarios y usuarios. Nota, las soluciones que se encuentran como
no factibles se tendrán que eliminar para cualquier consideración futura.

En caso de que se establezcan más de una solución, se deberán de poner de acuerdo

el personal y establecer prioridades en cuanto a la selección de solución.

Esta tarea solamente se puede considerar formal cunado es aprobada por el proyecto
de la fase de análisis de requerimientos.

Diseño Físico e Integración

El diseño físico, se encarga o se enfoca en los aspectos técnicos o de implantación del
sistema. Por razones obvias, los diseñadores son quienes se encargan de esta tarea y
los analistas de sistemas son quienes cooperan con ideas. Nuestra lógica o forma de
pensar nos puede hacer imaginar los trazos de esquemas para su implementación y
desarrollo de programadores, pero también se diseñan entradas, la forma de las bases
de datos, las entradas y salidas de archivos, etc.

Cuando se habla sobre diseños, los diseñadores ahora prefieren usar prototipos. Los
prototipos crean una estrategia en usar un proceso iterativo que tiene ciertas ventajas.

Para iniciar con una elaboración de prototipos, pues esta se puede iniciar a lápiz y hoja,
no necesariamente a computadora. Los analistas planean ciertas formas en establecer
entradas y salidas de información y bases de datos para así poder realizar un diagrama
de flujo y ciertos procedimientos.

Las desventajas que pueden tener estas elaboraciones es que pueden ser muy tardadas,
con muchos errores, omisiones, etc., pero también tiene muchas ventajas las cuales,
algunas de ellas son las siguientes:

 • La colaboración de los usuarios con el proyecto puede ser de una mejora de
estado de ánimo.
• En muchas ocasiones, hay cambios de parecer a última hora, pero ahora, con los
prototipos se pueden hacer ajustes de manera fácil y rápida donde pueden
convertir un programa justo a sus necesidades.
• Los errores se pueden detectar con mayor anticipación.
• Puede aumentar la creatividad y así aumentar la productividad o llegar a mejores
soluciones.

A continuación, se demuestra un diagrama para una mayor comprensión.

El objetivo a seguir, es que se genere el diseño de la base de datos. Se deben de
asegurar que la base de datos sea capaz de aceptar los requerimientos y expansiones
del programa. Los analistas de sistemas son quienes pueden cooperar o brindar ayuda
para facilitar esta tarea, mientras que los diseñadores de sistemas son quienes se
encargan de terminarla.
En esta parte de la tarea, es donde los diseñadores tienen una carga importante de
trabajo. Sus objetivos son implementar ciertos diálogos en el programa para facilitar el
uso y sea más fácil de comprender para los usuarios.
Bibliografía

Tuplas:
Tuplas. (n.d.). Retrieved February 27, 2017, from
http://progra.usm.cl/apunte/materia/tuplas.html

Diseño Lógico:
Berzal Galiano, F. Diseño Lógico. Retrieved February 27, 2017, from Elvex,
http://elvex.ugr.es/idbis/db/docs/design/5-logical.pdf

Restricciones de Integridad:
Caballero Roldán, R. Restricciones de Integridad. Retrieved February 27, 2017, from
http://gpd.sip.ucm.es/rafa/docencia/bdsi/apuntes/TEMA05.pdf

Análisis de Sistemas:
Whitten, J. L., & Bentley, L. D. (2008). Análisis de sistemas: diseño y métodos. México:
McGraw Hill.