A continuación se deja el CV de Judith del Rosario Barrios Albornoz
Para verlo hacer clic acá:
Curriculum Vitae
Read More
Para verlo hacer clic acá:
Curriculum Vitae
viernes, 7 de febrero de 2014
Metodología de Jonás Montilva
Es una metodología, estructurada para desarrollar sistemas de información en y para organizaciones de cualquier tipo.
Características:
1. ESTRUCTURADA:
• Utiliza diferentes métodos y técnicas estructuradas, que son propias de la ingeniería de la programación, y que han demostrado ser las más eficientes y eficaces para el desarrollo de sistemas programados.
• Guía paso a paso de arriba hacia abajo el grupo que la aplica explicando primero de forma muy general lo que debe hacerse para luego entrar en los detalles, a medida que se avanza hasta explicar las tareas esenciales que el grupo debe llevar a cabo para realizar el sistema de información.
2. COMPLETA: cubre todas las distintas fases del ciclo de desarrollo de un sistema de información, desde la definición del proyecto hasta la implantación del sistema en la organización. Guía al grupo de desarrollo a través de las fases, a un nivel bastante detallado, explicando las actividades que deben hacerse y en la mayoría de los casos, enumerando las tareas específicas que los miembros del grupo deben efectuar.
3. PARTICIONADA: a fin de manipular mejor la inherente a un proyecto de este tipo, la metodología se divide en fases, y cada una de las fases está compuesta por pasos los cuales están orientados a algún tipo de tópicos, aspecto o elemento de un sistema de información. Cada paso a su vez agrupa a un conjunto de actividades que han de ser realizadas por el grupo de desarrollo.
4. MODIFICABLE Y ADAPTABLE: el grupo de desarrollo puede modificar fácilmente la metodología, bien para introducir nuevos elementos como para eliminar algunos. De igual modo, puede adaptarla a las condiciones, exigencias y características de la organización donde se utilice o a cualquier otro tipo de proyecto de sistemas de información.
A su vez, MEDSI está principalmente diseñada para proyectos medianos y grandes, que ameriten la integración de grupos de desarrollo conformados por tres o más personas que puedan requerir para su desarrollo varios meses.
FASES DE LA METODOLOGÍA MEDSI.
FASE I: DEFINICIÓN DEL PROYECTO.
1) Determina la factibilidad de desarrollar un nuevo sistema de información y estimar los costos, tiempos y recursos requeridos de tal manera que las unidades interesadas puedan decidir si se ha de emprender o no el proyecto. Si se decide realizarlo se elabora el plan del proyecto.
2) Elabora el informe preliminar.
3) Discute el informe preliminar.
4) Planifica el estudio de factibilidad.
5) Estudio de factibilidad.
6) Determinan la factibilidad técnica
7) Determinan la factibilidad económica
8) Determinan la factibilidad psicosocial.
9) Elaborar informe de factibilidad.
10) Discutir el informe de factibilidad.
11) Planificación del proyecto.
FASE II: ANÁLISIS DE CONTEXTO.
En esta fase se busca ganar un sólido conocimiento del sistema ampliado dentro del cual se ubicará el nuevo sistema de información y determinar las deficiencias y problemas que presenta el actual sistema de información (Si existe). Realizando entonces los siguientes pasos:
1) Análisis documental.
2) Análisis del contexto.
3) Construir el modelo del sistema actual de información.
4) Identificar las situaciones problemáticas.
5) Elaborar el informe del sistema actual.
FASE III: DEFINICIÓN DE REQUERIMIENTOS.
Esta fase busca definir los requerimientos de los usuarios y establecer las funciones, restricciones y atributos que el nuevo sistema de información debe satisfacer.
1) Especificación de requerimientos de información.
2) Especificación funcional del nuevo sistema.
3) Especificación de restricciones y atributos.
4) Determinar interacción hombre–máquina.
5) Determinar atributos de calidad.
FASE IV: DISEÑO PRELIMINAR.
Esta fase se encarga de elaborar un diseño preliminar del sistema de información que satisfaga los requerimientos, restricciones y atributos establecidos en la fase III. El diseño preliminar consta de un prototipo o modelo físico que delinea la interacción hombre- máquina del sistema de información y describe, en forma general sus procesos automatizados.
FASE V: DISEÑADO DETALLADO.
Esta fase busca elaborar un diseño detallado del sistema de información que muestre como se construirán los subsistemas de datos y el subsistema programado. Esta fase produce el paquete de diseño, el cual contiene todas las especificaciones para la construcción del sistema, y el plan de pruebas que regirán las diferentes pruebas del sistema de información durante las fases de construcción, pruebas e implantación. Dentro de esta encontramos los siguientes pasos:
1) Diseño de entradas y salidas.
2) Diseñar dialogo hombre–máquina.
3) Diseñar las pantallas de entrada y salida.
4) Diseñar los reportes.
5) Diseño de datos.
6) Diseñar los programas de inicialización y mantenimiento de la base de datos.
7) Diseño de programas y procedimientos.
8) Diseñar la estructura del subsistema programado.
9) Diseñar cada módulo de la estructura.
10) Diseñar la documentación y los procedimientos manuales.
11) Ensamblaje del paquete de diseño.
12) Ensamblar el paquete de diseño.
13) Elaborar y discutir el informe del diseño detallado.
14) Planificación de pruebas.
15) Elaborar el plan de pruebas.
16) Discutir el plan de pruebas.
17) Planificar detalles de la próxima fase.
FASE VI. CONSTRUCCIÓN DEL SISTEMA.
Construir el subsistema de datos y el subsistema programado del sistema de información de acuerdo a lo especificado en el paquete de diseño. En esta fase se construyen y se prueban los diferentes módulos del subsistema programado; se construye subsistema de datos y los procedimientos manuales del sistema.
1) Diseño y construcción de las pruebas.
2) Realizar una revisión estructurada de las pruebas.
3) Construir los mecanismos y preparar los datos de pruebas.
4) Creación de la librería de programas.
FASE VII. CONTROL DE PROGRAMAS.
Durante esta actividad el grupo prueba los diferentes procedimientos de lenguajes de control de tareas que se hayan utilizado. Esta prueba se realiza inmediatamente después de las pruebas de subsistemas.
1) Prueba del sistema de información.
2) Preparación para la implantación.
3) Preparar el material de adiestramiento
FASE VIII. PRUEBA DE ACEPTACIÓN.
Durante esta fase los grupos de desarrollo y prueba se abocan a poner en operación y a efectuar la prueba de aceptación del sistema respectivamente. Esta prueba se realiza luego que el grupo de desarrollo a adiestrado a todos los usuarios en el uso; a continuación se realiza la conversión del viejo sistema al nuevo, mediante la actualización de la base de datos y el inicio de las actividades propias del sistema de información. Finalmente se realiza la entonación y la evaluación del sistema recientemente instalado.
Al realizar estos dos últimos pasos, la labor del todo el personal que participo en el proyecto puede considerarse terminada, marcando así el fin del proyecto de desarrollo y el inicio de una nueva etapa del ciclo de vida del sistema de información: la etapa de operación y mantenimiento.
1) Adiestramiento de usuarios.
2) Prueba de aceptación
Programación Extrema
Programación extrema o eXtreme Programming (XP)
Es una metodología de desarrollo ágil, una de las más exitosas en tiempo reciente. Su autor principal es Kent Beck, quien eligió algunas características de otras metodologías y las relacionó de forma que cada una complementara a la otra.
De esta forma, la XP se puede definir como un conjunto de pasos de diversas metodologías, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso común, para realizar un desarrollo más agradable y sencillo. Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del cliente.
Una programación extrema debe de tener las siguientes características:
Comunicación: Es muy importante que haya una comunicación constante con el cliente y dentro de todo el equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo de una manera sencilla, entendible y que se entregue al cliente lo que necesita.
Simplicidad: Sin importar qué funcionalidad requiera el usuario en su sistema, éste debe ser fácil. El diseño debe ser sencillo y amigable al usuario, el código debe ser simple y entendible, programando sólo lo necesario y lo que se utilizará.
Retroalimentación: Es la comunicación constante entre el desarrollador y el usuario.
Coraje: Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó con tanto esfuerzo; el desarrollador debe saber cuándo el código que desarrolló no es útil en el sistema y, por lo mismo, debe ser eliminado. También se refiere a tener la persistencia para resolver los errores en la programación.
Luego se encuentran los roles;
- • Programador: Escribe las pruebas unitarias y produce el código del sistema.
- • Cliente: Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.
- • Tester: Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
- • Tracker: Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
- • Entrenador (coach): Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.
- • Consultor: Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico.
- • Gestor (Big boss): Es el dueño del equipo y el vínculo entre clientes y programadores. Su labor esencial es la coordinación
Ventajas y desventajas:
Una de las ventajas de la programación extrema es que se adapta al desarrollo de sistemas pequeños y grandes; optimiza el tiempo de desarrollo; permite realizar el desarrollo del sistema en parejas para complementar los conocimientos; el código es sencillo y entendible, además de la poca documentación a elaborar para el desarrollo del sistema.
Las desventajas son que no se tiene la definición del costo y el tiempo de desarrollo; el sistema va creciendo después de cada entrega al cliente y nadie puede decir que el cliente no querrá una función más; se necesita de la presencia constante del usuario, lo cual en la realidad es muy difícil de lograr.
Otra desventaja es la programación en parejas, algunos desarrolladores son celosos del código que escriben y no les es grato que alguien más modifique las funciones que realizó o que su código sea desechado por no cubrir el estándar.
jueves, 6 de febrero de 2014
Sistemas Duros y Suaves
Peter Checkland (1930 Birmingham, Reino Unido) es un científico británico de gestión y profesor de Sistemas en la Universidad de Lancaster. Él es el promotor de la metodología de sistemas blandos o suaves (MSB)
Checkland se interesó en la aplicación de los sistemas de ideas a los problemas de gestión y desordenado en su trabajo como gerente en la industria. Sus ideas para la metodología de los sistemas blandos surgido de la incapacidad de la aplicación de lo que él llamó, "duros" en el diseño de los sistemas de gestión de los problemas desordenado. MSB desarrollado a partir de este ciclo continúo de la intervención en los malos estructurado de gestión de los problemas y aprender de los resultados. Sistemas blandos es una rama de la teoría de sistemas diseñados específicamente para su uso y aplicación en una variedad de contextos del mundo real.
Sistemas duros
Los sistemas duros se identifican como aquellos en que interactúan hombres y maquinas. En los que se les da mayor Importancia a la parte tecnológica en contraste con la parte social. La componente social de estos sistemas se considera como si la actuación o comportamiento del individuo o del grupo social solo fuera generador de estadísticas.
Generalmente, los sistemas duros admitirán procesos de razonamiento formales, esto es, derivaciones lógico-matemáticas. Los datos comprobados, como se presentan en esos dominios, generalmente son replicables y las explicaciones pueden basarse en relaciones causadas probadas. Muy a menudo las pruebas son exactas y las predicciones pueden averiguarse con un grado relativamente elevado de seguridad.
Es decir, el comportamiento humano se considera tomando solo su descripción estadística y no su explicación. En los sistemas duros se cree y actúa como si los problemas consistieran solo en escoger el mejor medio, el óptimo, para reducir la diferencia entre un estado que se desea alcanzar y el estado actual de la situación.
Características:
a.- El proceso de la toma de decisiones sea un proceso cuyas variables de decisión sean medibles, cuantitativas y fáciles de determinar.
b.- Cuando los estados futuros de lo que puede pasar son claramente identificables.
c.- Cuando la asignación de los recursos del sistema a las áreas que lo soliciten sean fácil y expedita.
d.- La objetividad de los sistemas duros proporciona además grandes ventajas para la aplicación de técnicas cuantitativas que requieren de variables fáciles de identificar y que representan la característica del sistema bajo consideración
Sistemas suaves están dotados con características conductuales, son vivientes y sufren un cambio cuando se enfrentan a su medio. Los sistemas suaves típicamente serian del domino de las ciencias de la vida y Ias ciencias conductual y social.
Sistemas suaves
Están dotados con características conductuales, son vivientes y sufren un cambio cuando se enfrentan a su medio. Los sistemas suaves típicamente serian del domino de las ciencias de la vida y Ias ciencias conductual y social.
Se identifican como aquellos en que se les da mayor importancia a la parte social. La componente social de estos sistemas se considera la primordial. El comportamiento del individuo o del grupo social se toma como un sistema teleológico, con fines, con voluntad, un sistema pleno de propósitos, capaz de desplegar comportamientos, actitudes y aptitudes múltiples.
1.- Los procesos de razonamiento informales, como el juicio y la intuición.
2.- El peso de los datos comprobados, derivados de unas cuantas observaciones y muy poca oportunidad de réplica.
3.- Las predicciones basadas en datos comprobados endebles, más que en explicaciones.
4.- Mayor discontinuidad de dominio y la importancia del evento único
EJEMPLO PRÁCTICO DE LA METODOLOGIA MEDSI
Es una metodología estructurada para desarrollar sistemas de información en y para organizaciones de cualquier tipo. Entre las características resaltantes de esta metodología podemos destacar
ES ESTRUCTURADA: esta característica se debe a dos razones esenciales:
Utiliza diferentes métodos y técnicas estructuradas, que son propias de la Ingeniería de la Programación, y que han demostrado ser las más eficientes y eficaces para el desarrollo de sistemas programados.
Guía paso a paso de arriba hacia abajo el grupo que la aplica explicando primero de forma muy general lo que debe hacerse para luego entrar en los detalles, a medida que se avanza hasta explicar las tareas esenciales que el grupo debe llevar a cabo para realizar el sistema de información.
ES COMPLETA. Cubre todas las distintas fases del ciclo de desarrollo de un sistema de información, desde la definición del proyecto hasta la implantación del sistema en la organización. Guía al grupo de desarrollo a través de las fases, a un nivel bastante detallado, explicando las actividades que deben hacerse y en la mayoría de los casos, enumerando las tareas específicas que los miembro del grupo deben efectuar.
ES PARTICIONADA. A fin de manipular mejor la inherente a un proyecto de este tipo, la metodología se divide en fases, y cada una de las fases esta compuesta por pasos los cuales están orientados a algún tipo de tópicos, aspecto o elemento de un sistema de información. Cada paso a su ves agrupa a un conjunto de actividades que han de ser realizadas por el grupo de desarrollo
(MEDSI), el cual orienta el desarrollo de sistemas informativos. Así como lo señala Colmenares (2001), quien agrega que es ”una metodología estructurada para desarrollar sistemas de información en organizaciones de cualquier tipo
” La misma esta estructurada en las siguientes fases:
Fase I. Definición del proyecto: consiste en prever si es factible o no el desarrollo del sistema informativo, se hace un diagnóstico de acuerdo a los gastos, tiempo y recursos que genera, de tal manera que se tome la decisión para desarrollar o no el proyecto dentro de Laser Airlines C.A; En esta investigación solo se utilizaron recursos informáticos y datos de otras investigaciones relacionadas con registros automatizados ,como enciclopedias web , trabajos de grado , el gestor de datos Visual Basic 6.0 y herramientas como Microsoft Word y Access.
Fase II. Análisis del Contexto: establece hacer la comparación del registro manual que se lleva actualmente en la Aerolínea ubicándola con la nueva propuesta del sistema a implementar. Se hace un análisis de los problemas que presenta y que puedan ser mejorables con la construcción del sistema automatizado, es decir cambiar el registro manual que se utiliza actualmente por un registro sistematizado.
Fase III. Definición de requerimientos: esta fase define la información que se tiene de la Empresa, así como las limitaciones y propiedades que debe ofrecer el sistema.
Fase IV. Diseño Preliminar: consiste en elaborar diferentes modelos previos al diseño que se va a implantar, de manera que brinde las expectativas de la institución. Para esta investigación se creó un modelo, lo que significa que no puede compararse con otros diseños preliminares.
Fase V. Diseño detallado: se elabora un diseño especificando los diferentes componentes del sistema, tomando como referencia el modelo preliminar el registro manual llevado actualmente el cual contiene la especificación de todos los datos necesarios para diseñar el sistema, es decir los datos que serán registrados.
Fase VI. Construcción del sistema: se procede a realizar la construcción del software de acuerdo a lo que se especificó en el paquete de diseño señalado en la fase anterior conjuntamente con las pruebas detalladas. Seguidamente se procede a la construcción del software informático, la construcción del presente sistema se realizo a través del lenguaje de programación Visual Basic 6.0.
Fase VII. Pruebas del Sistema: en esta fase se hace la prueba del sistema de acuerdo a lo especificado en las fichas que se usan actualmente para realizar el registro de las horas de entrada y salida. Se elabora el plan para la instalación y poner a funcionar el nuevo sistema.
Fase VIII. Implantación del sistema: en esta fase se instala el sistema automatizado luego de haber sido adiestrado los usuarios que van a utilizar el sistema. Se realiza la prueba de aceptación. Después de haberse instalado, la Aerolínea hace la evaluación y lo acepta. Esta fase actualmente no se ha ejecutado.
Asimismo, en su desarrollo interactúan dos tipos de herramientas: la primera sirve para realizar diseños gráficos y la segunda corresponde al lenguaje de alto nivel que codifica los eventos. Estas herramientas permiten desarrollar diversidades de aplicaciones basadas en el entorno. Además es importante señalar que dentro de este diseño se encuentran elementos que muestran
Teoría General de Sistemas y Enfoque de Sistemas
Enfoque del sistema
Es un esquema metodológico que sirve como guía para la solución de problemas, en especial hacia aquellos que surgen en la dirección o administración de un sistema, al existir una discrepancia entre lo que se tiene y lo que se desea, su problemática, sus componentes y su solución.
El enfoque de sistemas son las actividades que determinan un objetivo general y la justificación de cada uno de los subsistemas, las medidas de actuación y estándares en términos del objetivo general, el conjunto completo de subsistemas y sus planes para un problema específico.
El proceso de transformación de un insumo (problemática) en un producto (acciones planificadas) requiere de la creación de una metodología organizada en tres grandes subsistemas:
- Formulación del problema
- Identificación y diseño de soluciones
- Control de resultados
El enfoque de sistemas puede describirse como:
- Una metodología de diseño.
- Un marco de trabajo conceptual común.
- Una nueva clase de método científico.
- Una teoría de organizaciones.
- Dirección por sistemas.
- Un método relacionado a la ingeniería de sistemas, investigación de operaciones, eficiencia de costos, etc.
Características del enfoque de sistemas
Interdisciplinario: El enfoque al problema y su solución, no está limitado a una sola disciplina, sino que todas las pertinentes intervienen en la búsqueda de una solución.
Cualitativo y Cuantitativo a la vez: Se sirve de un enfoque adaptable, ya que el diseñador no aplica exclusivamente determinados instrumentos. La solución conseguida mediante los sistemas puede ser descrita en términos enteramente cualitativos, enteramente cuantitativos o con una combinación de ambos.
Organizado: El Enfoque de Sistemas es un medio para resolver problemas amorfos y extensos, cuyas soluciones incluyen la aplicación de grandes cantidades de recursos en una forma ordenada. El enfoque organizado, requiere que los integrantes del equipo de sistemas lo entiendan, pese a sus diversas especializaciones. La base de su comunicación es el lenguaje del diseño de sistemas.
Creativo: A pesar de los procedimientos generalizados ideados para el diseño de sistemas, el enfoque debe ser creativo, concentrándose en primer lugar en las metas propuestas y después en los métodos o la manera como se lograrán las mismas.
Teoría General de los Sistemas
TEORÍA DE SISTEMAS: son las teorías que describen la estructura y el comportamientode sistemas. La toería de sistemas cubre el aspecto completo de tipos específicos de sistemas, desde los sistemas técnicos (duros) hasta los sistemas conceptuales (suaves), aumentando su nivel de generalización y abstracción.
La Teoría General de Sistemas (TGS) ha sido descrita como: - una teoría matemática convencional - un metalenguaje - un modo de pensar - una jerarquía de teorías de sistemas con generalidad creciente. Ludwig von Bertalanffy, quien introdujo la TGS, no tenía intenciones de que fuera una teoría convencional específica. Empleó ese término en el sentido de un nombre colectivo para problemas de sistemas.
Enfoque reduccionista
Este enfoque estudia un fenómeno complejo a través del análisis de sus elementos o partes componentes. En este enfoque se trata de explicar que las ciencias o sistemas para su mejor entendimiento divididos a un grado tan elemental, separados de tal modo que facilitaran su estudio a un nivel tan especializado.
Biografía del padre de la teoría
Karl Ludwig von Bertalanffy (19 de septiembre, 1901, Viena, Austria - 12 de junio, 1972, Bufalo, Nueva York, Estados Unidos) fue un biólogo austríaco, reconocido por haber formulado la teoría de sistemas.
Estudió con tutores personales en su propia casa hasta sus 10 años, a partir de entonces fue a la escuela teniendo un nivel muy aventajado para su edad que le permitió acabar con honores su escolaridad.
Estudió historia del arte, filosofía y biología en la Universidad de Innsbruck y de Viena y, en ésta última finalizó el doctorado en 1926 leyendo su tesis doctoral sobre la psicofísica y Gustav Fechner.
En 1937 fue a vivir a Estados Unidos gracias a la obtención de una beca de la Fundación Rockefeller y así, estuvo 2 años en la Universidad de Chicago.
No pudo permanecer por más tiempo en Estados Unidos por no querer aceptar el subterfugio legal de declararse víctima del nazismo, así que vuelve a Europa[cita requerida].
Fue uno de los primeros en tener una concepción sistemática y totalizadora de la biología (denominada "organicista"), considerando al organismo como un sistema abierto, en constante intercambio con otros sistemas circundantes por medio de complejas interacciones. Esta concepción dentro de una Teoría General de la Biología fue la base para su Teoría General de los Sistemas. Esbozó dicha teoría en un seminario de Charles Morris en la Universidad de Chicago en 1937 y posteriormente en conferencias dictadas en Viena. Pero la publicación se tuvo que posponer a causa del final de la Segunda Guerra Mundial. Se desarrolló ampliamente en 1969 al publicar un libro titulado con el nombre de la teoría.
Suscribirse a:
Entradas (Atom)
