domingo, 3 de febrero de 2013

¿QUÉ ES EL ESTUDIO DE FACTIBILIDAD DE UN SISTEMA?
Es una versión más corta de todo el proceso de análisis y diseño de un sistema. Este proceso comienza con la definición del problema o la deficiencia que tenga el sistema, se identifican los objetivos  y se revisa cualquier restricción impuesta sobre el sistema. Este estudio se realiza para saber si es viable la implementación de un nuevo sistema en una empresa u organización.
¿EXPLIQUE FACTIBILIDAD ECONÓMICA, FACTIBILIDAD OPERATIVA Y FACTIBILIDAD TÉCNICA?
Factibilidad Técnica.
Esta se hace para saber si es posible implementar el sistema mediante la  tecnología actual que existe en la empresa.
Factibilidad Económica.
Aquí determinamos si es posible adquirir económicamente el sistema, y si sus beneficios superan los cotos.
Factibilidad Operativa.
Aquí determinamos si el sistema se puede implementar en la empresa o organización.
¿QUÉ ES LA DESCOMPOSICIÓN FUNCIONAL?
Es una herramienta utilizada por los analistas de sistema para identificar y definir cada nivel del análisis y diseño de las funciones, operaciones o sub-problemas en los cuales se pueda dividir un problema. Y esto hace mucho más fácil que se resuelva el mismo.   

sábado, 2 de febrero de 2013


 Levantamiento de Informacion

Estudio del sistema actual

En todo caso lo que se pretende en intentar conocer cómo opera el sistema actual y efectuar los cambios necesarios de manera sistemática para lograr mejorar, o sustituir el sistema.
Para llevar a cabo un trabajo de esta naturaleza se necesita tener una pauta de operación; ninguna organización es igual a otra, ya que aún cuando tengan las mismas estructuras, el elemento humano dentro de ellas las hace diferentes ya que introduce elementos conductuales y de comportamiento que le confieren ese carácter distintivo a la organización.
Así que para poder modificar un sistema o subsistema organizativo es necesario determinar cómo opera el sistema actual.

El levantamiento de información es el proceso mediante el cual el analista recopila datos e información de la situación actual de un sistema, con el propósito de identificar problemas y oportunidades de mejora.

Para recopilar esta información se pueden utilizar diferentes métodos e instrumentos tales como:

  * Entrevistas.
  * Observación de actividades
  * Cuestionarios (Encuestas)
  * Inspección
  * Simulación

Entrevista: Consiste en una conversación dirigida con un propósito específico y se basa en un formato de preguntas y respuestas para conocer aspectos como: metas de la organización, metas personales, su opinión, procedimientos formales e informales. Existen diferentes modalidades de entrevistas; entre las más importantes en el trabajo de sistemas pueden mencionarse:

    * La entrevista estructurada
    * La entrevista no estructurada

La entrevista estructurada: Constituye un interrogatorio, para el cual se ha preparado
previamente un conjunto de preguntas, las preguntas se formulan siempre en el mismo orden y en los mismos términos, el interrogador anota las respuestas en forma textual o atendiendo a un código.
La entrevista no estructurada: deja al entrevistado mayor margen de libertad e iniciativa, se utilizan preguntas abiertas, no hay formas estándar.
Generalmente al iniciar el estudio de un sistema se usa la entrevista no estructurada con los niveles directivos más altos, para detectar algunos aspectos importantes que permitan posteriormente elaborar el listado de tópicos para una entrevista estructurada.
Para efectuar la entrevista deben tenerse en cuenta algunos detalles importantes a saber:
En el contacto inicial, establezca una atmósfera agradable y de confianza, no adopte postura de sabelotodo ni de experto. Es necesario lograr la colaboración del entrevistado y no el rechazo.
Aun cuando la entrevista sea estructurada es recomendable hacerles preguntas de una manera aparentemente informal, que el entrevistado no se sienta interrogado, el entrevistador debe evitar hacer gestos o expresiones que impliquen reprobación, critica, sorpresa.
Las preguntas deben hacerse en un tono natural y aun cuando se tenga el cuestionario (cedula) de preguntas como referencias, evite el tono de lectura o interrogatorio.
Se debe mantener el orden de las preguntas de acuerdo al cuestionario. (Esto no es válido para la entrevista no estructurada)
Se debe dar a la persona entrevistada, suficiente tiempo para pensar la respuesta.
Para pasar de conjunto de preguntas a otro:
Se recomienda usar frases de transmisión tales como; "muy bien", "bueno", continuando con….".
Las preguntas deben reunir el requisito de ser neutras, ejem.: ¿Qué opina ud. sobre?, ¿Cuál es su idea acerca del punto?, ¿Cómo explicaría ud. la situación?

Para registrar las respuestas a la entrevista se recomienda:

  * Tener el cuestionario en una posición que permita escribir y hace anotaciones sin distraerse.
  * Disponer los elementos de modo que pueda dominar visualmente al entrevistado y la encuesta.
  * Anotar todo aquello que pueda ser útil posteriormente, gestos, signos, de admiración, etc.
  * Al concluir la entrevista debe dejarse establecido si habrá otras entrevistas.

La entrevista será para la persona que trabaja en sistemas, un auxiliar poderoso para revelar información acerca de procesos y procedimientos.

Cuestionario (encuesta): el cuestionario en sistema puede ser utilizado como ayuda o complemento de las entrevistas y observaciones personales.
Los cuestionarios se clasifican de diferentes formas de acuerdo a variados criterios, así encontramos que de acuerdo a la presencia o no del encuestado hay:

Indicaciones sobre cuestionarios: en la elaboración de cuestionarios es recomendable:

  * Incluir sólo preguntas relacionadas con el problema.
  * No redundar incluyendo preguntas cuyas respuestas se pueda obtener en otras fuentes con más exactitud.
  * Las preguntas deben ser de fácil comprensión.
  * Las preguntas deben guardar secuencia lógica.
  * Las preguntas no deben ser muy numerosas, sobre todo cuando las encuestas van dirigidas a usuarios responsables o usuarios dueños ya que estos carecen de tiempo para responder cuestionarios.
 
  * Se pueden utilizar preguntas de control, (especialmente en las entrevistas no estructuradas) para verificar la veracidad de determinadas respuestas.
Ventajas y limitaciones del cuestionario: entre las ventajas se pueden mencionar:

  * Menor costo que la entrevista y otras técnicas.
  * Menores gastos y uso del personal y mayor cobertura respecto al número de personas y área física.
  * Menor peligro de distorsión en las respuestas, así como mayor tiempo para reflexionar los mismos.

Entre las limitaciones se pueden mencionar:

  * No se pueden solicitar aclaratorias a ciertas respuestas.
  * Dificultades para verificar la información.
  * Pueden haber un gran número de cuestionarios no respondidos.

Dada la importancia y frecuencia con la que se utilizan los cuestionarios (y encuestas) como instrumentos de levantamiento de información, es recomendable examinar cada pregunta del cuestionario previamente antes de su aplicación, a través de interrogantes sobre el contenido, forma y orden de las preguntas y algunas sobre las posibles respuestas.

Observación de actividades: los métodos de revelamiento de información se pueden dividir en estáticos y dinámicos, se denomina estáticos aquellos en los que las personas dicen lo que hacen, este es un corte estático de sus actividades, el cuestionario también es un método estático, sin embargo el revelamiento a través de la observación directa o la simulación es un revelamiento dinámico, por cuanto se obtiene lo que realmente hace la persona en cada caso.

La observación puede tener varias modalidades.
Una de esas
modalidades es la observación general: es aquella en la cual se pretende obtener una visión global del medio ambiente del sistema, en este tipo de observación si se revela información sobre factores como:

  * Movimiento del personal y documentos en general.
  * Tipos de maquinas y equipos de uso.
  * El ritmo de trabajo.
  * El nivel de desperdicio, de tiempo y recursos y sus posibles causas.
  * Número de asesores en el área.
  * Algunas apreciaciones sobre imprevistos y los problemas que pueden surgir.
  * Evaluar el grado en el cual un procedimiento se está llevando a cabo y cuáles son los factores que posiblemente requieran atención especial.

Otro tipo de observación: es la que se lleva a cabo sobre un personal seleccionado, ejemplo sobre los vendedores, los oficinistas, el personal de almacén, profesores, bedeles, o sobre aquel que labora en cualquier otra actividad específica.
En este tipo de observación se tratará de determinar:

La cantidad de tiempo perdido usado en cada tarea o actividad.

  * Tiempo usado en llevar formularios.
  * Tiempo empleado en el uso del teléfono.
  * Tiempo usado en traslados y otros movimientos.
  * Tiempo usado en tareas de archivos.

Este tipo de observación no implica medición de tiempos y movimientos como se utiliza en estudios de eficiencia, ya que en ese tipo de estudios se trata de determinar estándares de tiempo para cada operación, en la observación de la que aquí se trata lo que se pretende es obtener un valor aproximado de cuan productivo es un trabajador o una tarea, cuál es la estructura u organización de trabajo de una unidad administrativa, si hay superposición o traslape en las tareas, funciones y cuán importante es la cantidad de tiempo dedicada a cada tarea o actividad.
El tercer tipo de observación es el de la ruta o camino que sigue un documento o forma, qué pasos sigue, a qué procesos es sometido y por quién, en esta parte encontraremos un valioso auxiliar en los gráficos y diagramas.
Algunas características de este método de observación son:

  * Hay menos posibilidad de perder o dejar de observar actividades relacionadas con formas (formularios), ejemplo: chequear, analizar, calcular, archivar, etc.
  * Las unidades administrativas a través de las cuales pasa la forma, están identificadas y es posible establecer las idas y venidas e incluso medir los espacios recorridos.
  * Las demoras y retardos pueden ser determinadas y computadas.
  * Es más fácil identificar la fuente y el destino final de cada documento.

Inspecciones: las inspecciones consiste en revisar (previo permiso de las instancias correspondientes) otras fuentes de información como:

  * Reportes periodísticos (memorando y cuentas).
  * Reporte de auditoría.
  * Recortes de prensa.
  * Record de cantidad.
  * Sugerencias de los empleados.
  * Quejas de usuarios y clientes.
  * Organigramas (reales y aparentes).
  * Estructuras de control.
  * Archivos y manuales, etc.
 
 

Determinación de la Factibilidad


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.

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 las metas con los recursos actuales en las siguientes áreas.
a). Factibilidad Técnica.

    - Mejora del sistema actual.
    - Disponibilidad de tecnología que satisfaga las necesidades.
b).- Factibilidad Económica.

    - Tiempo del analista.
    - Costo de estudio.
    - Costo del tiempo del personal.
    - Costo del tiempo.
    - Costo del desarrollo / adquisición.
c).- Factibilidad Operativa.

    - Operación garantizada.
    - Uso garantizado.

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.

 Factibilidad Técnica


El análisis de factibilidad técnica evalúa si el equipo y software están disponibles (o, en el caso del software, si puede desarrollarse) y si tienen las capacidades técnicas requeridas por cada alternativa del diseño que se esté considerando. Los estudios de factibilidad técnica también consideran las interfases entre los sistemas actuales y nuevo. Por ejemplo, los componentes que tienen diferentes especificaciones de circuito no pueden interconectarse, y los programas de software no pueden pasar datos a otros programas si tienen diferentes formatos en los datos o sistemas de codificación; tales componentes y programas no son compatibles técnicamente. Sin embargo, puede hacerse una interfase entre los sistemas no compatibles mediante la emulación, la cual son circuitos diseñados para hacer que los componentes sean compatibles, o por medio de la simulación, que es un programa de cómputo que establece compatibilidad, pero con frecuencia estas formas de factibilidad técnica no están disponibles o son demasiado costosas.

Los estudios de factibilidad técnica también consideran si la organización tiene el personal que posee la experiencia técnica requerida para diseñar, implementar, operar y mantener el sistema propuesto. Si el personal no tiene esta experiencia, puede entrenársele o pueden emplearse nuevos o consultores que la tengan. Sin embargo, una falta de experiencia técnica dentro de la organización puede llevar al rechazo de una alternativa particular.


Factibilidad Operacional


Esta factibilidad comprende una determinación de la probabilidad de que un nuevo sistema se use como se supone. Deberían considerarse cuatro aspectos de la factibilidad operacional por lo menos. Primero, un nuevo sistema puede ser demasiado complejo para los usuarios de la organización o los operadores del sistema. Si lo es, los usuarios pueden ignorar el sistema o bien usarlo en tal forma que cause errores o fallas en el sistema.

Segundo, 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. Para cada alternativa debe explorarse con cuidado la posibilidad de resistirse al cambio al nuevo sistema. Tercero, un nuevo sistema puede introducir cambios demasiado rápido para permitir al personal adaptarse a él y aceptarlo. 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.

Una última consideración es la probabilidad de la obsolescencia subsecuente en ele sistema. La tecnología que ha sido anunciada pero que aún no está disponible puede ser preferible a la tecnología que se encuentra en una o más de las alternativas que se están comparando, o cambios anticipados en las practicas o políticas administrativas pueden hacerse que un nuevo sistema sea obsoleto muy pronto. En cualquier caso, la implantación de la alternativa en consideración se convierte en impráctica.

Un resultado frecuente de hallazgos negativos acerca de la factibilidad operacional de un sistema es que éste no se elimina sino que se simplifica para mejorar su uso. Otras posibilidades son que los programas de relaciones públicas o de entrenamiento estén diseñados para enfocarse a sobreponerse a la resistencia a un nuevo sistema, o se desarrollan formas para hacer fases en el nuevo sistema en un largo periodo para que el cambio total, que traumatizaría a los usuarios u operadores, se convierta en una serie de pequeños cambios.

Factibilidad Económica


Los estudios de factibilidad económica incluyen análisis de costos y beneficios asociados con cada alternativa del proyecto. Con análisis de costos/beneficio, todos los costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se hace una comparación de ellos. Primero se comparan os costos esperados de cada alternativa con los beneficios esperados para asegurarse que los beneficios excedan a los costos. Después la proporción costo/beneficio de cada alternativa se compara con las proporcionan costo/beneficio de las otras alternativas para identificar la alternativa que sea más atractiva e su aspecto económico. Una tercera comparación, por lo general implícita, se relaciona con las formas en que la organización podría gastar su dinero de modo que no fuera en un proyecto de sistemas.

Los costos de implementación incluyen comúnmente el costo remanente de la investigación de sistemas (ara este propósito, los costos en los que ya se ha incurrido no son relevantes), los costos de hardware y software, los costos de operación del sistema para su vida útil esperada, y los costos de mano de obra, material, energía, reparaciones y mantenimiento. A través del análisis de costo/beneficio, la organización debe apoyarse en los conceptos tradicionales de análisis financiero y las herramientas como teoría del valor presente, análisis de costos diferenciales y análisis de flujos descontados.
Estudio de Factibilidad de un Sistema de Informacion.

  • Descripción del Entorno
    • Como quiera que se va a trabajar a posteriori en equipo, los analistas iniciales deben describir el entorno organizacional en donde se va a desarrollar el SI. Se debe hacer una breve reseña de la empresa (fecha de inicio de actividades, domicilio, ramo al cual se dedica, organigrama general), y una breve reseña de la Unidad Funcional específica a la cual se le desarrollará el SI.
    • En las fases de cualquier Metodología de Desarrollo de Sistemas de Información se deben emplear técnicas de recolección de información.
      • Entrevistas
        • Individuales o Grupales
        • Estructuradas o No Estructuradas
      • Cuestionarios
        • Abiertos o Cerrados
      • Observación
  • Identificación del Problema
    • Es primordial que se identifique el problema, para poder tener más claro cuáles pueden ser las posibles soluciones que se van a presentar.
El problema no puede ser que el sistema actual es manual o que no existe.  Se debe hallar el problema real (por ejemplo: lentitud en los procesos, inexactitud en los resultados, retrabajo, procesos engorrosos, etc.).

  • Identificación de los Procedimientos Actuales
    • Se deben identificar, a grosso modo, los procedimientos generales que se llevan a cabo actualmente en la Unidad Funcional.
  • Presentación de las Posibles Soluciones al Problema
    • Se deben presentar al menos tres (03) posibles soluciones al Problema identificado. El presentarle una sola solución al usuario o cliente es forzarle a elegir una única propuesta. Al ofrecer al menos tres (03) posibles soluciones el usuario se sentirá que tiene la libertad para seleccionar la que considere más conveniente.
    • Normalmente en el ámbito de Desarrollo de Sistemas de Información se pueden presentar tres (03) soluciones clásicas:
      • Optimizar el Sistema Actual (quizás mediante la elaboración de procedimientos escritos, formatos, establecimiento de controles)
      • Adquirir una aplicación existente en el mercado y adaptarla a la organización
      • Desarrollar una aplicación hecha a la medida
    • Normalmente el costo del Hardware no es pertinente en un desarrollo de S.I., ya que lo que si es importante es el Software
    • En caso de que el cliente o usuario requiera Hardware, se deberá colocar en otra propuesta aparte
    • Aún, en esta etapa, no se conocen a ciencia cierta los requerimientos exactos de Hardware
  • Validación de las Posibles Soluciones
    • Todas las Posibles Soluciones a presentar deben ser factibles, desde el punto de vista Operativo, Técnico y Económico.
      • Factibilidad Técnica (existe tecnología para realizar el S.I.?)
      • Factibilidad Operativa (habrá resistencia al cambio?)
      • Factibilidad Económica (relación beneficio/costo)
    • No se puede ofrecer una solución que no sea factible.
  • Ventajas y Desventajas de cada Posible Solución
    • Se presentan las ventajas y desventajas de cada Posible Solución, a fin de ofrecerle al cliente una base más sólida para la toma de decisiones y selección de la solución más adecuada.
  • Cuadro comparativo de Costos y Tiempos de Ejecución
    • Se elabora un cuadro comparativo, donde se presenta cada solución, con su respectivo costo y tiempo de ejecución, a fin de presentarle de manera más resumida al usuario las opciones disponibles.
  • Recomendación
    • De acuerdo a la experiencia del equipo de proyecto, se enuncia la solución más recomendada para ser desarrollada.
    • El Estudio de Factibilidad es una especie de “Presupuesto” que se le presenta al cliente o usuario
    • El Estudio de Factibilidad también puede conocerse como “Propuesta del Sistema”
    • Una vez aprobado el Estudio de Factibilidad por el Comité de Sistemas, clientes o usuarios, se procede con las siguientes etapas del Desarrollo.
La Carta Estructurada.

La carta estructurada tambien es conocida como el modelo de producto, es una metodologiá de análisis y diseño de sistemas de análisis estructurado, lo que muestra es un mapa de diseño de arriba hacia abajo (top-down) de tipo jerárquico en el que se asienta cómo será programado el proyecto, construido, integrado y probado.

Hay una herramienta CASE que se llama Visible Analyst y te permite modelar análisis estructurado y orientado a objetos.

El diseño modular te permite asentar "los módulos" en los que estará dividida tu aplicación, digamos que ordenas tus módulos de manera que puedas "dividir el trabajo". Por ejemplo, si vas a hacer un sistema administrativo para una empresa a lo mejor tienes tus módulos de nómina, personal, inventario, compras, ventas, etc por decir algo. A lo mejor tu cliente necesita urgentemente primero la nómina; entonces es necesario que hagas el diseño de los módulos de todo el sistema para que desde el principio se tome en cuenta su crecimiento, o para dividir en equipos de trabajo que desarrollen los módulos por separado y pueda existir comunicación, estén acordes los datos, entradas con salidas, etc.


sábado, 5 de enero de 2013

Metodologia de Kendall & Kendall

Metodologia kendall y kendal

Implementación y evaluación del sistema

1. Planificar gradualmente la conversión del sistema anterior.
2. Instalar los equipos de hardware necesarios para el funcionamiento del software creado.
3. Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados.
4. Evaluar la adaptabilidad de los usuarios al sistema.


Esta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas. Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en áreas del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases. El trabajo de sistemas es cíclico, cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar a regresar a la fase previa y modificar el trabajo realizado.

Prueba y mantenimiento del sistema

1. Realizar la programación de las pruebas del sistema.
2. Realizar un instrumento para evaluar el sistema de información
3. El programador deberá elaborar un resumen de las pruebas del sistema.
4. El analista deberá realizar un informe de sus pruebas y discutirlo con el programador
5. Elaborar la planificación de las horas del mantenimiento del sistema
6. Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos


Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios. Una parte de la pruebas la realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realizan las pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual. El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan de manera rutinaria durante toda su vida útil.

Desarrollo y documentación del software
1. Evaluar los procedimientos que va a ser desarrollados por el programador
2. Mostrar y explicar cada procedimiento, función y operación al programador
3. Elaborar manuales de procedimientos internos del sistema.
4. Elaborar manuales externos de ayuda a los usuarios del sistema.
5. Elaborar demostraciones para los usuarios y la interacción con distintas interfaces
6. Elaborar actualizaciones para los diferentes procedimientos
7. Elaborar un informe con el tiempo que se llevó construir cada procedimiento

En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y el pseudocódigo. Durante esta fase el analista trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en archivos “léame” que se integrarán al nuevo software. La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso.
Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo.
Diseño del sistema recomendado
1. Evaluar las tres fases anteriores.
2. Realizar el diseño lógico de todo el sistema.
3. Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de información
4. Elaborar el diseño de la base de datos.
5. Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o función.
6. Diseñar controles y procedimientos de respaldos que protejan al sistema y a los datos
7. Producir los paquetes específicos de programas para los programadores
8. Elaborar una lista de las funciones genéricas y de las que será obligatorio crear

En esta fase el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos. Facilita la entrada eficiente de datos al sistema de información mediantes técnicas adecuadas de diseño de formularios y pantallas. La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. La interfaz conecta al usuario con el sistema y por tanto es sumamente importante. También incluye el diseño de archivos o bases de datos que almacenarán gran parte de los datos indispensables para los encargados de tomar las decisiones en la organización. En esta fase el analista interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos. Finalmente el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento.

domingo, 14 de octubre de 2012


EL CICLO DE DESARROLLO DE LOS SISTEMAS

El analista debería aplicar un enfoque sistemático en el análisis y el diseño de los sistemas de información. El ciclo de desarrollo de los sistemas o ciclo de vida de los sistemas (SDLC: Systems Devetopment Life Cycle) es un enfoque por etapas de análisis y de diseño, que postula que el desarrollo de los sistemas mejora cuando existe un ciclo específico de actividades del analista y de los usuarios.
En general, los analistas no están de acuerdo respecto al número exacto de etapas que conforman el ciclo de desarrollo de los sistemas;  sin embargo, se reconoce la importancia de su enfoque sistemático.    Se dividirá   el ciclo de vida en siete etapas, que aunque se presentan de manera discreta, nunca se llevan a cabo    como     un     elemento Independiente. En lugar de ello. se realizan al mismo tiempo diversas actividades, y éstas llegan a repetirse. Por ello es de mayor utilidad suponer que e! ciclo de desarrollo de los sistemas transcurre en etapas (con actividades en acción que luego cesan poco a poco) y no como elementos separados.

1) Identificación de problemas, oportunidades y objetivos.
En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se involucra en la identificación de los problemas, de las oportunidades y de los objetivos.  Esta fase es crucial para el éxito del resto del proyecto, pues  nadie estará dispuesto a desperdiciar su tiempo dedicándolo al problema equivocado.
La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto con los otros miembros de la organización hará notar los problemas.  Muchas veces esto ya fue realizado previamente: y por ello. es que se llega a invitar al analista.
Las oportunidades son  acuellas situaciones que el analista considera que pueden perfeccionarse mediante el uso de los sistemas de información computarizados. Al  aprovechar las oportunidades, la empresa puede lograr una ventaja competitiva o llegar a establecer un estándar industrial.
La identificación de objetivos también es un componente importante de la primera fase.  En un comienzo, el analista deberá descubrir lo que la empresa intenta realizar, y luego. estará en posibilidad de determinar si el uso de los sistemas de información apoyaría a la empresa para alcanzar sus   metas,   el   encaminarla   a problemas     u     oportunidades específicas.

2) Determinación de los requerimientos de información.
La siguiente etapa que aborda el analista, es la determinación de los requerimientos de información a partir de  los  usuarios  particularmente involucrados.   Para identificar los requerimientos de información dentro de ¡a empresa, pueden utilizarse diversos instrumentos, los cuales incluyen: el muestreo, el estudio de los datos y formas usadas por la organización,   la   entrevista,   los cuestionarios: la observación de la conducta   de   quien   toma   las decisiones, asi como de su ambiente: y también el desarrollo de prototipos.
En esta etapa el analista hace todo lo posible por identificar qué información requiere el usuario para desempeñar sus tareas. Puede ver, cómo varios de los métodos para establecer las necesidades  de  información,   lo obligan a relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la imagen que el analista tiene de la organización y de sus objetivos. En ocasiones, se llegan a concluir sólo las primeras dos etapas del ciclo de desarrollo de los sistemas.      El analista  es  e! especialista que emprende esta clase de estudios.

3) Análisis de las necesidades del sistema.
La siguiente etapa que ejecuta el analista de sistemas consiste en analizar las necesidades propias del sistema.    Una vez más, existen herramientas y técnicas especiales que facilitan al analista la realización de las determinaciones requeridas. Estas incluyen  el  uso de losdiagramas de flujo de datos (DFD)que cuentan con una técnica estructurada para representar en forma gráfica la entrada de datos de la empresa, los procesos y la salida de la información. A partir del diagrama de flujo de datos se desarrolla un diccionario de datos que contiene todos los elementos que utiliza el sistema, así como sus especificaciones,       si       son alfanuméricos,   descripción,   clave primaria, entre otros.
Durante esta fase. el analista de sistemas   también   analiza   las decisiones estructuradas por realizar, que  son  decisiones  donde  las condiciones, condiciones alternativas, acciones y reglas de acción podrán determinarse. Existen tres métodos para el análisis de las decisiones estructuradas:      el      lenguaje estructurado (en nuestro caso el español), las tablas de decisión y los árboles de decisión.

No todas   las decisiones en las empresas      se      encuentran estructuradas;   no   obstante,   es importante que las comprenda e! analista de sistemas. Las decisiones semiestructuradas (decisiones que se toman bajo nesgo) con frecuencia se apoyan en los Sistemas de Toma de Decisiones.    Cuando analiza las decisiones   semiestructuradas.   el analista las examina de acuerdo con el grado de complejidad del problema y con el  número de criterios considerados al llevar a cabo las decisiones.
El análisis de decisiones de criterio múltiple (aquellas decisiones donde numerosos  factores  tienen   que equilibrarse) también es parte de esta etapa.   Se disponen de muchas técnicas para e' análisis de decisiones de criterio múltiple; incluyendo entre otras, e! proceso de intercambio y la aplicación de métodos de ponderado.
A esta altura del ciclo de desarrollo del sistema, el analista prepara una propuesta del sistema que resume todo lo que ha encontrado, presenta un análisis costo / beneficio de las alternativas    y    plantea    las recomendaciones (si es que existen) de lo que deberá realizarse.  Si la dirección acepta alguna de las recomendaciones,     el     analista procederá de acuerdo con ella.

4)    Diseño    del sistema recomendado.
En esta etapa del ciclo de desarrollo de los sistemas, el analista de sistemas usa la información que recolectó con anterioridad y elabora el diseño  lógico   del   sistema   de
información.    El analista diseña procedimientos precisos de captura de datos, con el fin de que los datos que se introducen al sistema sean los correctos. Ei analista también diseña accesos   efectivos al sistema de información, mediante el uso de las técnicas de diseño de formularios y de pantallas.
Una parte del diseño lógico del sistema de información es el diseño de la interfaz con el usuario.   La interfaz conecta al usuario con el sistema, y evidentemente, es de suma importancia. Serían ejemplos de interfaces para el usuario: el uso del teclado para introducir preguntas o respuestas, el uso de menús en la pantalla, con las opciones que tiene el usuario, el uso de dispositivos como el ratón (mouse) y muchos otros.
La etapa del diseño también incluye e! diseño de los archivos o la base de datos que almacenará aquellos datos requeridos  por quien toma  las decisiones en la organización. Una base de datos bien organizada es fundamental para cualquier sistema de información.  En esta etapa, el analista diseña la salida (en pantalla o impresa) hacia el usuario, de acuerdo con sus necesidades de información.
5) Desarrollo y documentación del software
En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con    los   programadores    para desarrollar todo el software original

que sea necesario.  Dentro de las técnicas estructuradas para el diseño y documentación de! software se tienen:   el   método   HIPO,   los diagramas de flujo. ios diagramas Nassi-Schneiderman, ios diagramas Warnier-Orr y el pseudocódigo. Aquí es donde, el analista de sistemas transmite   al   programador   los requerimientos de programación.
Durante esta fase, el analista también colabora con los usuarios para desarrollar    la    documentación indispensable     del     software, incluyendo los  manuales     de procedimientos. La documentación le dirá al usuario como operar el software, y así también, qué hacer en caso de presentarse algún problema.
6) Pruebas v mantenimiento del sistema.
El sistema de información debe probarse antes de utilizarlo. E! costo es  menor  si  se  detectan  los problemas antes cié la entrega del sistema.   El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboración con el analista de sistemas.   En un principio, se hace una serie de pruebas,  con  datos  tipo,   para identificar las posibles fallas del sistema: más adelante, se utilizarán los datos reales.
El mantenimiento del sistema y de su documentación empiezan justamente en esta etapa: y después,   esta función se realizará de forma rutinaria a lo largo de toda la vida del sistema. Las actividades de mantenimiento integran una buena parte de la rutina
del programador, que para las empresas    llegan    a    implicar importantes sumas de dinero.  Sin embargo, el costo del mantenimiento disminuye de manera importante cuando    el    analista    aplica procedimientos sistemáticos en el desarrollo de los sistemas.
7) Implantación v evaluación de sistema.
En esta última etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de   información.   Esto incluye el adiestramiento que el usuario requerirá. Si bien, parte de esta capacitación la dan las casas comerciales,   la   supervisión   del adiestramiento        es        una responsabilidad   del   analista   de sistemas.    Más aún, el analista necesita planear la suave transición que trae consigo un cambio de sistemas.
Aunque la evaluación del sistema se plantea como parte integrante de la última etapa del ciclo de desarrollo de los sistemas; realmente, la evaluación toma parte en cada una de las etapas.     Uno de los criterios fundamentales que debe satisfacerse, es que ei futuro usuario utilice el sistema desarrollado.