Factivilidad y manejo de un Proyecto

Factibilidad y análisis de datos de un proyecto.


Determinación de objetivo.

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos de costo y planificación temporal y se realizan dentro de un marco de tiempo limitado al comienzo de un proyecto de software.

Factibilidad del proyecto.
La factibilidad es aquello que se a planificado anteriormente ya organizado y estructurado para poder realizarlo o poner a cabo. Esta se clasifica de las siguientes formas:

1. Factibilidad operacional.
Se refiere al hecho de que si trabajará o no el sistema si este se llega a desarrollar, preguntas claves como son:Los métodos que actualmente se usan en la empresa, ¿son aceptados por los usuarios?

• ¿El sistema propuesto causará perjuicios?

• ¿Producirá resultados pobres en alguna área?

• ¿Se perderá control en alguna área específica?

• ¿Se perderá la facilidad de acceso a la información?

• ¿La productividad de los empleados será menor después de instalado el sistema?

• ¿Los clientes se verán afectados por la implantación?

2. Factibilidad Técnica.

Es una evaluación que demuestra que el negocio puede ponerse en marcha y mantenerse, mostrando evide
ncias de que se a planeado cuidadosamente

• ¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide?

• ¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos requeridos para usar el nuevo sistema?

• ¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin importar el número y ubicación de los usuarios?

• Si se desarrolla el sistema, ¿se puede crecer con facilidad?

• ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos?

3. Factibilidad financiera y económica.
Un sistema puede ser factible desde el punto de vista técnico y operacional, pero sino es factible económicamente para la organización no puede ser implantado. Las cuestiones económicas y financieras formuladas por los analistas deben incluir

• El costo de llevar a cabo la investigación completa de sistemas

• El costo del hardware y software para la aplicación

• Beneficios en la forma de reducción de costos o de menos errores costosos

• El costo si nada sucede (si el proyecto no se lleva a cabo)

Aprobación de la solicitud.

No todos los proyectos solicitados son factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que solo es posible atender unas cuantas. Sin embargo, aquellos casos que son deseables y factibles deben incorporarse en los planes de desarrollo de la organización, para ser atendidos lo más rápido posible, según los recursos de la organización. Dentro de los beneficios que el sistema podría brindar tenemos:

• Obtención de información no disponible actualmente

• Elaborac ión más oportuna de la información

• Mejoras en las operaciones de la organización

• Posibilidades de efectuar cálculos o estimaciones que actualmente no es posible

• Reducción de costo

• Obtención de una posición competitiva dentro del mercado

• Mejoras en la toma de decisiones.

• Mejoras en la imagen, atención, seguridad, etc.

Requerimientos básicos.

Los analistas estructuran su investigación al buscar respuestas de los proyectos a evaluar a las siguientes cuatro preguntas:

• ¿Cuál es el proceso básico de la empresa?
• ¿Qué datos utiliza o produce este proceso?
• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
• ¿Qué controles de desempeño utiliza?

Análisis de Flujo de Datos. La estrategia del flujo de datos muestra el empleo de éstos en forma gráfica. Las herramientas usadas para seguir esta estrategia muestran todas las características esenciales del sistema y la forma en que se ajustan entre sí. Puede ser difícil comprender
en su totalidad un proceso de la empresa si se emplea para ello solo una descripción verbal; las herramientas para el flujo de datos ayudan a ilustrar los componentes esenciales de un sistema junto con sus interacciones.
El análisis de flujo de datos usa las siguientes herramientas:

• Diagrama de flujo de datos
• Diccionario de datos
• Gráfica de estructura

Diagrama de flujo de datos. Son una de las cuatro herramientas del análisis estructurado. Es una herramienta gráfica que se emplea para describir y analizar el movimiento de los datos a través de un sistema, ya sea este manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Los DFD, como se les conoce popularmente son la herramienta más importante y la base sobre la cual se desarrollan otros componentes. La transformación de datos de entrada en salida por medio de procesos puede describirse en forma lógica e independiente de los componentes físicos (computadoras, gabinetes de archivos, y procesadores de texto) asociados con el sistema.

• Flujo de datos: movimiento de datos en determinada dirección, desde un origen hasta un destino en forma de documentos, cartas, llamadas telefónicas o virtualmente cualquier otro medio. El flujo de datos es un “paquete de datos”

• Procesos: personas procedimientos o dispositivos que usan o producen (transforman) datos.

• Fuente o destino de datos: fuentes o destinos externos de datos, que pueden ser personas, programas, organizaciones u otras entidades que interactúan con el sistema pero que se encuentran fuera de sus fronteras. La diferencia fundamental con los procesos es que las fuentes o destinos no transforman información, al menos no dentro de las fronteras del sistema que se está modelando

• Almacenamiento de datos: es el lugar donde se guardan los datos o al que referencian los procesos en el sistema. El almacenamiento de datos puede representar dispositivos tanto computarizados como no computarizados.
Los DFD se concentran en el movimiento de

los datos a través del sistema, no en los dispositivos o el equipo. Los analistas identifican y describen, desde el inicio hasta del final proceso, para comprender un área de aplicación o los datos que fluyen por todo el sistema y entonces explican por qué los datos entran o salen y cuál es el procesamiento que se realiza con ellos. Es muy importante determinar cuándo entran los datos al área de aplicación y cuándo salen de ésta.
Primer nivel del DFD. En el primer nivel, es muy importante identificar los principales procesos, y flujos que dan en forma conjunta sentido operacional al sistema que se está modelando.
Algunos analistas consideran ventajoso trabajar primero con todos los flujos de datos y asignar, como ya se dijo nombres que sean significativos y descriptivos. Se identifican todos los procesos, como ya se mencionó pero no se les da nombre hasta que sean bien entendidos todos los flujos de datos. Después cuando se les ha asignado nombre a los procesos, si el analista tiene dificultas para ligar los flujos de datos con los nombres apropiados entonces esta situación indica que es necesario dividir aun más el proceso.
Expansión de los procesos a diagramas de mayor nivel. Una vez que se ha desarrollado el sistema como está descrito en el diagrama de primer nivel, es indudable que el analista formule preguntas en relación con la forma que se lleven a cabo los procesos. (Ver documento de determinación de requerimientos) En general se debe estar seguro de:

• Todos los flujos de datos que explican el proceso en el diagrama previo deben incluirse en el diagrama del siguiente nivel inferior

• Los flujos y almacenes de datos nuevo se añaden si son usados internamente por el proceso para eslabonar otros procesos introducidos por primera vez en la expansión de este nivel. Se deben mostrar los flujos y almacenes de datos originados en el proceso dentro en este nivel.

• Ninguna entrada debe contradecir las descripciones de los DFD de niveles más altos (si lo hacen uno o ambos son incorrectos y deben introducirse cambios)

Reglas adicionales para el dibujo de DFD. Una vez identificado la mayor parte de los lineamientos que se siguen para el dibujo de los DFD, he aquí algunas más:

• Cualquier flujo de datos que abandone un proceso debe estar basado en los datos que entran al proceso

• Todos los flujos de datos tienen un nombre que refleja los datos que fluyen entre procesos, almacenes de datos, fuentes o destinos

• Solo deben entrar al proceso, los datos necesarios para llevarlo a cabo

• Un proceso no debe saber nada de ningún otro en el sistema, es decir debe ser independiente, la única dependencia que debe existir es aquella basada en sus propios datos de entrada y salida

• Los procesos siempre están en continua ejecución, no se inician ni tampoco se detienen. Los analistas siempre deben suponer que un proceso está listo para ejecutar su trabajo

• La salida de los procesos puede tomar una de las siguientes formas

• Flujo de datos con información añadida por el proceso (i.e: una anotación a una factura)

• Una respuesta o cambio en la forma de los datos (i.e: un cambio en la forma de expresar las utilidades -de ¢ a $-)

• Un cambio de condición (i.e: de autorizado a no autorizado)

• Cambio de contenido (i.e: integración o separación de la información contenida en uno o más flujos entrantes de datos)

• Cambios en la organización (i.e: separación física o redondeo de datos)

• La norma común es definir cada nivel inferior en términos de 3 a 7 procesos para cada proceso de nivel superior, si son necesarios más detalles se puede hacer en el siguiente nivel.

• Los almacenes y flujos de datos que son relevantes solo para el interior del proceso, son ocultados hasta que el proceso se extiende con mayor detalle

• Los datos que fluyen hacia los procesos experimentan cambios. Por consiguiente, el flujo de datos de salida tiene un nombre diferente al de la entrada; si no se efectúa algún cambio en el flujo de datos, entonces ¿cuál es la finalidad del proceso?

• En cuanto a los nombres de los procesos lo más apropiado es escoger un verbo y un sujeto que reciba la acción y no nombre generales que no digan nada. Si un nombre de proceso es vago o complejo tal vez se deba subdividir el proceso aún más.

Diccionario de datos. Es un catálogo, un depósito, de los elementos de un sistema. Estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos y las necesidades de la organización. En él se encuentran la lista de todos los elementos que forman parte del flujo de datos en todo el sistema.
Estructuras de datos. Son un grupo de datos elementales que están relacionados con otros y que en conjunto describen un componente del sistema. Los flujos de datos, o los almacenes de datos son ejemplo de estructuras de datos. Dicho de otra forma si las estructuras están en movimiento reciben el nombre de flujos y si son estéticas son almacenes de datos. Se construyen sobre cuatro relaciones de componentes; que bien pueden ser datos o estructuras de datos también. Se pueden usar las siguientes combinaciones ya sea en forma individual o en conjunción con alguna otra:

• Relación secuencial
• Relación de selección
• Relación de iteración
• Relación opcional