lunes, 20 de julio de 2009

METODOLIGIAS PARA EL DESARROLLO DE SITEMAS :














METODO DE CASCADA PURA

En un modelo en cascada, un proyecto progresa a través de una secuencia ordenada de pasos partiendo de la especificación de requerimientos hasta el mantenimiento del mismo.
El método realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente etapa, por ejemplo, desde el análisis de requerimientos hasta el diseño.
Cuando la revisión determina que el proyecto no está listo pasar a la siguiente, permanece en la etapa actual hasta que esté preparado.
El modelo en cascada está dirigido por documentos:
• Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
• Ayuda a minimizar los gastos de la planificación porque permite realizarla sin planificación porque permite realizarla sin problemas.
• Funciona especialmente bien si se dispone de personal poco cualificado o dispone de personal poco cualificado o inexperto, porque presenta el proyecto inexperto, porque presenta el proyecto con una estructura que ayuda a minimizar con una estructura el esfuerzo inútil.
En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rápido. Incluso en los casos en los que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada (con retroceso) pueden funcionar mejor.
Las desventajas del modelo se centran en las dificultades para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningún trabajo de diseño y antes de escribir ningún código.
No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, métodos y actividades que abarcan varias etapas de la cascada.

METODO ESPIRAL

Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini−proyectos.
Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estén controlados.
Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada.
Método Desarrollo en Espiral
• Funcionamiento:
Se parte de una escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuación se establece una aproximación a la siguiente interacción.
Cada iteración supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel:
Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas.

En cada bucle alrededor del espiral, la culminación del análisis de riesgo resulta una decisión de seguir o no seguir.

Cada interacción en el método espiral lleva consigo los seis pasos que a continuación se nombran: Determinar objetivos, alternativas y límites, Identificar y resolver riesgos, Evaluar alternativas,

Generar las entregas de esa iteración, y comprobar que son correctas.
En el modelo en espiral, las primeras iteraciones son las menos costosas.
Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseño, la implementación del producto y la prueba del mismo.

En cada Cuadrante del Método espiral se realiza las siguientes actividades:
Planificación:
Determinación de objetivos, alternativas, restricciones, y elaboración del plan de desarrollo para el ciclo actual.
Análisis de Riesgos:
1. Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto
2. Ingeniería:
Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc. Evaluación por el cliente, Valoración de resultados.


METODO DE CODIFICAR Y CORREGIR

Es un modelo poco útil, pero sin embargo bastante común Se puede tener una especificación formal, o no tenerla Si no se ha utilizado formalmente un método, probablemente ya se esté usando el método Codificar y
Corregir en forma intuitiva Cuando se utiliza éste método se empieza con una idea general de lo que se necesita construir, Se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo.
• Ventajas:
No conlleva ninguna gestión; no se pierde tiempo en la planificación, en la documentación, en el control de calidad, en el cumplimiento de los estándares, o en cualquier otra actividad que no sea codificación pura.
Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso.
Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa está familiarizada con éste modelo.
Para proyectos pequeños que se intentan liquidar en un tiempo breve, o para modelos como programas de demostración o prototipos desechables, el modelo codificar y corregir puede ser útil.
Desventajas:
El modelo resulta peligroso para otro tipo de proyectos que no sean pequeños.
Puede que no suponga gestión alguna, pero tampoco ofrece medios de evaluación del progreso.
No proporciona medios de evaluación de la calidad o de identificación de riesgos.
Si al llevar tres cuartas partes de la codificación descubre que el diseño es incorrecto, no hay otra solución que desechar el trabajo y comenzar de nuevo.


METODO PROTOTIPO

Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño que cualquiera de los ya presentados. La construcción de prototipos es muy eficaz bajo las circunstancias correctas. Sin embargo, al igual que los otros métodos, el método es útil sólo si se emplea en el momento adecuado y en la forma apropiada.

¿Qué es un prototipo?

El prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, está constituido por software que acepta entradas, realiza cálculos, produce información ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versión, o iteración, de un sistema de información.
Lo usuarios evalúan el diseño y la información generada por el sistema. Lo anterior sólo puede hacerse con efectividad si los datos utilizados, al igual que las situaciones, son reales. Por otra parte, deben esperarse cambios a medida que el sistema es utilizado.
Razones para desarrollar prototipos de sistemas:
Los requerimientos de información no siempre están bien definidos. Es probable que los usuarios conozcan sólo ciertas áreas de la empresa donde se necesiten mejoras o cambios en los procedimientos actuales.
Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de diseñar e implantar sistemas no tienen información ni experiencia, o también donde existen situaciones de riesgo y costo elevados, y aquellas donde el diseño propuesto es novedoso y aún no se demuestra es la factibilidad de que los vendedores envíen ordenes de pedido al sistema de cómputo de la compañía desde el sitio donde efectúan la operación por medio de terminales portátiles enlazadas a teléfonos públicos. Para probar el concepto los administradores y encargados de sistemas pueden optar por construir una versión en pequeña escala del software, adquirir unas cuantas terminales y seleccionar un grupo de vendedores. El prototipo proporcionará información preliminar sobre la funcionalidad del concepto.
El prototipo es, en realidad, un modelo piloto o de prueba, en general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones:
Los encargados de diseñar e implantar sistemas nunca han desarrollado uno con las características del sistema propuesto.
• Se conoce sólo una parte de las características esenciales del sistema; las demás no son identificables a pesar de un cuidadoso análisis de requerimientos.
• La experiencia con el uso del sistema añadirá una lista significativa de requerimientos que el sistema debe satisfacer.
• Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus características.
• Los usuarios del sistema participan en el proceso de desarrollo.
Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes:
• Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes: ð Identificar los requerimientos de información que el usuario conoce junto con las características necesarias del sistema. Desarrollar un prototipo que funcione. Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista de los requerimientos de sistemas conocidos.
• Revisar el prototipo con base en la información obtenida a través de la experiencia del usuario.

METODO DE ANALISIS Y DISEÑO ESTRUCTURADO

• Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar ésa dificultad por medio de 1) la división del sistema en componentes y 2) la construcción de un modelo del sistema. El método incorpora elementos tanto de análisis como de diseño.

¿Qué es el análisis estructurado?

El análisis estructurado concentra en especificar lo que se requiere que haga el sistema o la aplicación. No se M establece cómo se cumplirán los requerimientos o la forma en que implantará la aplicación. Más bien permite
que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadoras, terminales, sistemas de almacenamiento, etc.) Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.
Elementos del análisis estructurado:
Los elementos esenciales son símbolos gráficos, diagramas de flujo de datos y diccionario centralizado de datos.
Descripción gráfica
Una de las formas de describir un sistema es preparar un bosquejo que señale sus características, identifique la función para la que sirve e indique cómo éste interactúa con otros elementos, entre otras cosas. Sin embargo, describir de esta manera un sistema grande es un proceso tedioso y propenso a errores ya que es fácil omitir algún detalle o dar una explicación que quizá los demás no entiendan.
En lugar de las palabras el análisis estructurado utiliza símbolos, o íconos, para crear un modelo gráfico del sistema. Los modelos de este tipo muestran los detalles del sistema. Si se seleccionan los símbolos y notación correctos entonces casi cualquier persona puede seguir la forma en que los componentes se acomodarán entre si para formar el sistema.
El diagrama lógico de flujo de datos muestra las fuentes y destinos de los datos, identifica y da nombre a los procesos que se llevan a cabo, identifica y da nombre a los grupos de datos que relacionan una función con otra y señala los almacenes de datos a los que se tiene acceso.
Diagrama de flujo de datos: El modelo del sistema recibe el nombre de diagrama de flujo de datos (DFD). La descripción completa de un sistema está formada por un conjunto de diagramas de flujo de datos.
Para desarrollar una descripción del sistema por el método de análisis estructurado se sigue un proceso descendente (TOP−down). El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujo de datos cada vez más detallados. Esta secuencia se repite hasta que se obtienen suficientes detalles que permiten al analista comprender en su totalidad la parte del sistema que se encuentra bajo investigación.

Diccionario de datos:

Todas las definiciones de los elementos en el sistema (flujo de datos, procesos y almacenes de datos) están descritos en forma detallada en el diccionario de datos. Si algún miembro del equipo encargado del proyecto desea saber alguna definición del nombre de un dato o el contenido particular de un flujo de datos, esta información debe encontrarse disponible en el diccionario de datos.

¿Que es el diseño estructurado?
Se enfoca en el desarrollo de especificaciones del software. La meta del diseño estructurado es crear programas formados por módulos independientes unos de otros desde el punto de vista funcional
El diseño estructurado es una técnica específica para el diseño de programas y no un método de diseño de comprensión. Esta técnica conduce a la especificación de módulos de programa que son funcionalmente independientes. La herramienta fundamental del diseño estructurado es el diagrama estructurado, los cuales son de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas. Los diagramas estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él. Estas especificaciones funcionales para los módulos se proporcionan a los programadores antes que dé comienzo la fase de escritura de código.
Empleo del Análisis estructurado con otros métodos de desarrollo:
El análisis estructurado se combina, con bastante frecuencia, con el método ya presentado de ciclo de vida clásico de desarrollo de sistemas. Por ejemplo, los analistas pueden optar más de flujo de datos como una forma para documentar las relaciones entre componentes durante la investigación detallada de algún sistema existente, Asimismo, se puede definir los archivos y datos en un diccionario centralizado de datos de acuerdo con las reglas de análisis estructurado.
Sin embargo muchas organizaciones optan por no utilizar este método de desarrollo.

Por ejemplo, los analistas deciden con frecuencia que el desarrollo de diagramas y esquemas es una área que consume mucho tiempo, sobre todo si el sistema es grande y complejo. (Es común que los diagramas tengan que dibujarse una y otra vez conforme se adquiere nueva información). Como se verá más adelante, se han desarrollado herramientas asistidas por computadora para superar este problema.
Otros analistas señalan que los elementos que faltan, tales como las personas y los procedimientos de control, son parte del sistema mismo

martes, 7 de julio de 2009

Sistema de Información Ejecutiva:
(Executive information system, EIS por sus siglas en inglés) es una herramienta de Inteligencia empresarial (Business Intelligence, BI), orientada a usuarios de nivel gerencial, que permite monitorizar el estado de las variables de un área o unidad de la empresa a partir de información interna y externa a la misma.
Se puede considerar que un EIS es un tipo de Sistema de Soporte a la Decisión (DSS) cuya finalidad principal es que el responsable de un departamento o compañía tenga acceso, de manera instantánea, al estado de los indicadores de negocio que le afectan, con la posibilidad de estudiar con detalle aquellos aspectos que no estén cumpliendo con los objetivos establecidos en su plan estratégico u operativo, y así determinar las medidas de contingencia más adecuadas.
Sistema de apoyo a las decisiones:

(DSS por sus siglas en inglés Decision support system) es muy amplio. Un DSS puede adoptar muchas formas diferentes. En general, podemos decir que un DSS es un sistema informático utilizado para servir de apoyo, más que automatizar, el proceso de toma de decisiones. La decisión es una elección entre alternativas basadas en estimaciones de los valores de esas alternativas. El apoyo a una decisión significa ayudar a las personas que trabajan solas o en grupo a reunir inteligencia, generar alternativas y tomar decisiones. Apoyar el proceso de toma de decisión implica el apoyo a la estimación, la evaluación y/o la comparación de alternativas.

Control de gestión:
Es un proceso que sirve para guiar la gestión empresarial hacia los objetivos de la organización y un instrumento para evaluarla.
Existen diferencias importantes entre las concepciones clásica y moderna de control de gestión. La primera es aquella que incluye únicamente al control operativo y que lo desarrolla a través de un sistema de información relacionado con la contabilidad de costos, mientras que la segunda integra muchos más elementos y contempla una continua interacción entre todos ellos. El nuevo concepto de control de gestión centra su atención por igual en la planificación y en el control, y precisa de una orientación estratégica que dote de sentido sus aspectos más operativos.





Mando Integral:
Impulsada por Norton y Kaplan, o bien a cualquier modelo estratégico de indicadores que maneje la compañía.








Tipos de Cuadros de Mando
Cuadro de Mando Operativo (CMO):
Es una herramienta de control enfocada al seguimiento de variables operativas, es decir, variables pertenecientes a áreas o departamentos específicos de la empresa. La periodicidad de los CMO puede ser diaria, semanal o mensual, y está centrada en indicadores que generalmente representan procesos, por lo que su implantación y puesta en marcha es más sencilla y rápida. Un CMO debería estar siempre ligado a un DSS (Sistema de Soporte a Decisiones) para indagar en profundidad sobre los datos.
Cuadro de Mando Integral (CMI):
Por el contrario, representa la ejecución de la estrategia de una compañía desde el punto de vista de la Dirección General (lo que hace que ésta deba estar plenamente involucrada en todas sus fases, desde la definición a la implantación). Existen diferentes tipos de cuadros de mando integral, si bien los más utilizados son los que se basan en la metodología de Kaplan & Norton. La principales características de esta metodología son que utilizan tanto indicadores financieros como no financieros, y que los objetivos estratégicos se organizan en cuatro áreas o perspectivas: financiera, cliente, interna y aprendizaje/crecimiento