GESTION DE PROYECTOS DE SISTEMAS DE INFORMACION.

 La información para la gestión y la gestión de la información son dos conceptos diferentes; la información para la gestión es un tipo de información (los datos); la gestión de la información es un tipo de gestión (el sistema). La gestión de la información es el proceso de analizar y utilizar la información que se ha recabado y registrado para permitir a los administradores (de todos los niveles) tomar decisiones documentadas. La información para la gestión es la información necesaria para tomar decisiones de gestión.
La supervisión proporciona información sobre el estado de cosas en el proyecto.
Esta información se recoge durante las fases de planificación e implementación. La información ayuda a detectar cualquier cosa que vaya mal en el proyecto. En consecuencia, los administradores pueden encontrar soluciones para asegurar el éxito.
La importancia de la información para la gestión:
La información para la gestión es importante para:

• Tomar las decisiones necesarias para mejorar la gestión de prestaciones y servicios
• Poner en práctica la planificación, implementación, supervisión y evaluación participativas.

Cómo gestionar la información:

Para poder utilizar la información para tomar decisiones de gestión, debe gestionarse la información (recabar, registrar y analizar). Aunque la gestión de la información (el proceso de recabar y guardar la información) y la información para la gestión (la información necesaria para tomar decisiones bien documentadas) son diferentes, se refuerzan entre sí y no pueden separarse en las operaciones cotidianas.
Por lo tanto, la gestión de la información implica:

• determinar la información que se precisa
• recoger y analizar la información
• registrarla y recuperarla cuando sea necesaria
• utilizarla
• divulgarla

 

Determinar la información necesaria para la gestión: 

 Durante la planificación, gestión y supervisión del proyecto se genera mucha información. Parte de ella es necesaria para tomar decisiones de gestión inmediatas, parte para decisiones de gestión posteriores.
Un buen sistema de gestión de la información debe, por lo tanto, ayudar a los administradores del proyecto a saber qué información necesitan recabar, para tomar diferentes decisiones en distintos momentos.

Obtener y analizar la información para gestionarla: 

 La información puede conseguirse de informes de técnicos, libros de registro, formularios de los diferentes ejecutantes, reuniones con la comunidad, entrevistas, observación y mapas comunitarios.

Registro de la información: 

Es importante guardar la información para futuras referencias. Puede guardarse en libros de registro locales, informes de progreso, formularios o incluso en la cabeza. El principio más importante del registro de informaciones es la facilidad con la que pueden recuperarse.

Empleo de la información: 

 Se puede utilizar para solucionar problemas comunitarios, determinar recursos (cantidad y naturaleza), solicitar apoyos y planear futuros proyectos.

Divulgación o flujo de información:

 Para que la información tenga un uso adecuado tiene que compartirse con los demás interesados o usuarios. Esta información puede ayudarles en sus decisiones de gestión y también puede ayudar al que la recoge a encontrar significados o usos relacionados con la gestión.
La información deben compartirla los miembros de la localidad, parroquia, comarca, distrito, ministerio, ONG y donantes. La información para la gestión forma parte de la supervisión porque dicha información surge de ella, y ayuda en la planificación y la implementación de las actividades de supervisión.

El sistema de información es:

“Un conjunto formal de procesos que, operando sobre una colección de datos estructurada según las necesidades de la empresa, recopilan elaboran y distribuyen la información (o parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de dirección y control correspondientes (decisiones) desempeñar su actividad de acuerdo a su estrategia de negocio”. 

ENFONQUE ESTRUCTURADO

En el Enfoque estructurado se usan los DFD (Diagrama de flujo de datos) como principal herramienta para entender al sistema antes de plasmarlo a codigo fuente. DFD es un diagrama en el q participan procesos (metodos), flujo de datos (argumentos) y archivos (base de datos). Hay de diferentes niveles dependiendo la complejidad del sistema q analiza. hablando de lenguajes Tiene muchas diferencia con la OO. un minimo cambio en el codigo puede llegar alterar al resto del programa cosa que en uno OO bien encarado eso no sucede lo cual es una ventaja por que asi no se pierde tiempo en arreglar cosas ya hechas. Otra desventaja es que una porcion de codigo en lenguaje estructurado es dificil que pueda servir en otros proyectos, esto si es habitual en lenguajes OO, con solo importar clases ya hechas se escribe menos codigo y se ahorra tiempo.

Diagrama de Flujo de Datos

º Un diagrama de flujo de datos (DFD) es un modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software.
Diccionario de Datos


º El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema.

  El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades.

Diseño de Modulos


º Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un Modelo de Datos permite describir:

 • Las estructura de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.

• Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.

• Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.
Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.

Proceso

º CONJUNTO DE TAREAS LOGICAMENTE RELACIONADAS QUE EXISTEN PARA OBTENER UN RESULTADO BIEN DEFINIDO DENTRO DE UN NEGOCIO

   

Orientación a Objetos

º La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan software que facilitan la construcción de sistemas complejos a partir de componentes.

ºAbstraccion:

La abstraccion es uno de los medios más importantes, mediante el cual nos enfrentamos con la complejidad inherente al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin preocuparse de las restantes características (no esenciales). Abstracción es la técnica de quitarle a una idea o a un objeto todos los acompañamientos innecesarios hasta que los deja en una forma esencial y mínima. Una buena abstracción elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes.

º Encapsulamiento

El Encapsulamiento o encapsulación es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulación (también se conoce como ocultación de la información), en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales.

º Modularidad:

La Modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.

 

º Jerarquía

La Jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos jerarquías más importantes de un sistema complejo son: estructura de clases (jerarquía “es-un” (is-a): generalización/especialización) y estructura de objetos (jerarquía “parte-de” (part-of): agregación).



 

º Polimorfismo

La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese momento.

 

º Clase

Una clase es esencialmente un proyecto, a partir del cual puede crear objetos. Una clase define las características de un objeto, incluyendo las propiedades que definen los tipos de datos que ese objeto puede contener y los métodos que describen el comportamiento del objeto. Estas características determinan la manera en que otros objetos pueden acceder y trabajar con los datos que se incluyen en el objeto.

PARADIGMAS DE LA INGENIERIA EN SOFTWARE

La Ingeniería de Software es reconocida como una disciplina legítima, digna de tener una investigación seria, un estudio cuidadoso y ha generando una gran controversia. En la industria el Ingeniero del software ha sustituido al programador como titulo de trabajo preferente. Los modelos de procesos de software, métodos de ingeniería de software y herramientas se han adoptado con éxito en el amplio espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la necesidad de un enfoque más disciplinado del software.

Un paradigma de programación es un modelo básico de diseño y desarrollo de programas, que permite producir programas con una directriz específica, tales como: estructura modular, fuerte cohesión, alta rentabilidad, etc.

Existen tres categorías de paradigmas de programación:

a)    Los que soportan técnicas de programación de bajo nivel (ejemplo: copia de ficheros frente estructuras de datos compartidos)

b)    Los que soportan métodos de diseño de algoritmos (ejemplo: divide y vencerás, programación dinámica, etc.)

c)    Los que soportan soluciones de programación de alto nivel, como los descritos en el punto anterior

Los paradigmas relacionados con la programación de alto nivel se agrupan en tres categorías de acuerdo con la solución que aportan para resolver el problema:

a)    Solución procedimental u operacional. Describe etapa a etapa el modo de construir la solución. Es decir señala la forma de obtener la solución.

b)    Solución demostrativa. Es una variante de la procedimental. Especifica la solución describiendo ejemplos y permitiendo que el sistema generalice la solución de estos ejemplos para otros casos. Aunque es fundamentalmente procedimental, el hecho de producir resultados muy diferentes a ésta, hace que sea tratada como una categoría separada.

c)    Solución declarativa. Señala las características que debe tener la solución, sin describir cómo procesarla. Es decir señala qué se desea obtener pero no cómo obtenerlo.

La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

• Modelo en cascada o Clásico (modelo tradicional) 

• Modelo en espiral (modelo evolutivo) 

• Modelo de prototipos 

• Desarrollo por etapas 

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos 

2. Diseño del Sistema 

3. Diseño del Programa 

4. Codificación 

5. Pruebas 

6. Implantación 

7. Mantenimiento

 

 

El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, cada bucle epresenta un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior

Determinar o fijar objetivos 

• Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario. 

• Fijar las restricciones. 

• Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. 

• Hay una cosa que solo se hace una vez: planificación inicial o previa. 

Análisis del riesgo 

• Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. 

Desarrollar, verificar y validar (probar) 

• Tareas de la actividad propia y de prueba. 

• Análisis de alternativas e identificación resolución de riesgos.

Planificar 

• Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. 

Modelo de prototipos

En Ingeniería de software el desarrollo con prototipación, también llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).

Desarrollo por etapas

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.

Pueden distinguirse las siguientes fases:

• Especificación conceptual 

• Análisis de requerimientos 

• Diseño inicial 

• Diseño detallado, codificación, depuración y liberación 

Estas diferentes fases se van repitiendo en cada etapa del diseño.

 

MODELO DE DESARROLLO CONCURRENTE

MODELO DEL DESARROLLO

 CONCURRENTE

El Modelo de Desarrollo Concurrente conocido además como Ingeniería Concurrente dado por Davis Sitaram, se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor.

Provee una meta-descripción del proceso del software. El modelo concurrente tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.

La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Un modelo de proceso concurrente está dirigido por las necesidades del usuario, las decisiones de la gestión y los resultados de las revisiones.

El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera.

Esto genera la corrección del modelo de análisis de sucesos, que disparará la actividad de análisis del estado hecho al estado cambios en espera. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.

Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones:

1. Dimensión de sistemas.

2. Dimensión de componentes.

Los aspectos del nivel de sistema se afrontan mediante tres actividades: diseño, ensamblaje y uso.
En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto.


La concurrencia se logra de dos formas: 

1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos.

2. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

Ventajas

• Excelente para proyectos en los que se conforman grupos de trabajo independientes.
• Proporciona una imagen exacta del estado actual de un proyecto.

Desventajas

• Si no se dan las condiciones señaladas no es aplicable.
• Si no existen grupos de trabajo no se puede trabajar en este método

MODELO EN ESPIRAL

MODELO EN ESPIRAL 

El modelo en espiral fue desarrollado por Boehm, quien lo describe así:

El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con muchos usuarios.

Se caracteriza principalmente por:

•   Un enfoque cíclico para el crecimiento incremental del grado de definición e implementación de un sistema, mientras que disminuye su grado de riesgo.
•   Un conjunto de puntos de fijación para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral captura algunos principios básicos:

•          Decidir qué problema se quiere resolver antes de viajar a resolverlo.
•       Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
•          Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
•       No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
•          Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles. 

Funcionamiento del modelo Espiral

 

En cada vuelta tomamos en cuenta:

•      Los Objetivos: Que necesidad debe envolver el programa.

1.       Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través de diferentes puntos como son:Características: experiencia del personal, exigencias a efectuar.
2. Formas de gestión del programa.
3. Riesgo tomado con cada alternativa.

•     Desarrollar y Verificar: Programar y probar el programa .
•       Se planificaran los siguientes pasos y se volverá a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones la radial y la angular:

1. Angular=Avance del proyecto Software, dentro de un ciclo.
2. Radial=Aumento del coste del proyecto, ya que con cada nueva interacción se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos largos como pueden ser la creación de un Sistema Operativo. Y que necesitan constantes cambios.

Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea capaz de detectar y catalogar correctamente dicho riesgo.

El modelo en espiral WINWIN

El modelo en espiral WINWIN de Boehm, define un conjunto de acciones de negociación al principio de casa paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:

• Identificación del sistema o subsistemas clave de los directivos.
• Determinación de las condiciones de victoria de los directivos.
• Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor del espiral y proporcionan hitos de decisión antes de continuar el proyecto de software.