Desarrollo de Software

Categorización de Defectos de Software: una propuesta

En la dinámica actual y especialmente en ciudades con alto grado de urbanización, nuestras vidas literalmente dependen del software. Los sistemas y las aplicaciones (en sus diferentes presentaciones) forman parte de nuestro día a día y una porción significativa de nuestar labor productiva, social, personal y hasta familiar pasa cotidianamente (como información) a través de ellas.

La certeza del correcto funcionamiento del software es algo que generalmente damos por sentado; sin embargo, siendo el éste (todavía) producto de humanos, también está sujeto a errores los cuales pueden tener diferentes fuentes y muy diversos efectos, desde cálculos erróneos, funcionalidad inhabilitada, imposibilidad de guardar cambios, hasta fuga de información. Dependiendo del contexto, tales efectos pueden pasar desapercibidos o poner en riesgo la vida de las personas.

Por esta razón la gestión de defectos (estén atentos sobre una próxima publicación sobre este tema) es un proceso fundamental en el desarrollo de software. Una parte de dicha gestión consta de analizar el orígen y causas del defecto (pronto viene una publicación sobre RCA) para entender cómo se gestó, qué impacto tuvo, cuál fue el proceso para su solución y cómo se pueden reducir errores similares en el futuro.

En mi experiencia con proyectos de software de diversas industrias, arquitecturas, tecnologías, plataformas y magnitudes, he compilado y desarrollado una clasificación de defectos relativos a su orígen que propicia las siguientes ventajas:

  • Ecualiza los defectos: Agrupa los defectos por causas, independientemente de sus consecuencias o la magnitud de su impacto.
  • Apoya en su priorización: permite realizar una comparativa de volúmenes entre categorías.
  • Aprovecha lecciones aprendidas: sirve como apoyo en el análisis de la ejecusión de medidas generales tanto correctivas como preventivas, por ejemplo relacionadas con las mejores prácticas asociadas a la categoría o que hayan sido aplicadas con anterioridad en defectos de la misma cateogoría.
  • Promueve procesos de mejora: sirve como base en la generación o derivación medidas correctivas o preventivas adicionales sobre una base probada y común.
  • Democratiza su gestión: al considerar que los defectos se producen por la interacción de los miembros de un equipo y no solo de un rol particular.

Las categorías propuestas obedecen a tres premisas fundamentales:

  • Atender a las causas del defecto y no a las consecuencias (causalidad)
  • Generar el menor traslape posible entre las categorías (segregación)
  • Procurar el agrupamiento de todos los defectos (universalidad)

Como veremos en la discusión posterior, en la práctica pueden ocurrir casos en los que sea difícil realizar clasificación del defecto, es principalmente por esta razón que la lista propuesta no pretende ser exahustiva ni definitiva, sino servir como guía para que cada equipo desarrolle su propio esquema de modo que se ajuste al contexto y las condiciones de sus proyectos.

Categorías para la clasificación defectos

Defectos causados por datos: este tipo de defectos tiene su origen en la fuente donde se almacena la información para su extracción y posterior procesamiento y/o despliegue. Por ejemplo: datos almacenados en formato incorrecto o con valores inapropiados, recursos (imágenes, documentos, tipografías) erroneos o no disponibles, etc.

Defectos causados por lógica de programación: este tipo de defectos causan problemas en la funcionaliad del software y son relativos a una mala implementación del algoritmo, o el proceso que puede estar relacionada con la falta de análisis de los datos de entrada, una intepretación incorrecta del requerimiento (procesamiento de datos y la salida del proceso), errores en la codificación (inicialización de variables, mal posicionamiento de elementos de inicio o fin de bloques de código, etc).

Defectos causados por procesos del SDLC: este tipo de defectos son causados por la falta de seguimiento (o la inexistente definición) de procesos relacionados con la generación y despliegue del código del software; por ejemplo, el seguimiento de estándares de codificación, el despliegue de elementos relacionados en conjunto (código adicional, archivos de configuración, recursos asociados o cambios en el esquema de bases de datos), ejecusión de pruebas (unitarias, de humo o de regresión), etc.

Defectos causados por Requerimientos incompletos: este tipo de defectos están relacionados con ambiguedades u omisiones en los requerimientos que dejan a la interpretación del lector aspectos importantes sobre la implementación y funcionalidad deseada. Por ejemplo en procesos ágiles es muy común que no se cumpla con el “Definition of Done” para las historias de usuario, y en equipos no muy maduros tiende a causar conflictos entre la intepretación de quien va a desarrollar la funcionalidad respecto a quien la va a probar. Una manera de identificar estos defectos es cuando en las discusiones entre los desarrolladores y los ingenieros de calidad aparecen fraces como: “es que yo pensé”, “lo que yo había entendido es”, o “como no decía, asumí”.

Defectos causados por las herramientas o el ambiente del SDLC: hay ocasiones en los que un defecto surge aún cuando tanto el código como los datos son correctos y se siguieron los procesos de manera correcta. Muchos de ellos son causados por inconsistencias en los ambientes en los que se despliega el código, configuraciónes erróneas, conflicto en versiones de software requerido, uso de herramientas no estandarizadas para el desarrollo o la promoción del código, etc.

Defectos Inválidos: esta categoría no obedece a una causa sino a la necesidad de agrupar los “defectos defectuosos”, es decir, aquellos defectos que luego de una revisión terminaron siendo funcionalidad esperada o se descarta su atención por no obedecer a una especificación o inclusive por ser trivial en el contexto. En muchos casos estos defectos son eliminados de la bitácora; sin embargo, es importante mantenerlos como evidencia tanto del esfuerzo invertido por quien lo registró como de que los ingenieros de pruebas también cometen errores.

Defectos Removidos: esta categoría no obedece a una causa sino a la necesidad de agrupar aquellos defectos que por cualquier causa no sean atendidos por el equipo que los generó, sino que son extraídos para su atención por otro equipo. En muchas ocasiones los equipos pierden visibilidad del destino de este tipo de defectos por lo que es importante mantener evidencia de su existencia y (en la mayoría de los casos) procurar su seguimiento para la correcta actualización de su estado (por ejemplo si está todavía abierto, en progreso o cerrado)

En efecto, se pudiera pensar (especialmente si comulga con la frase “todo se reduce a las matemáticas”), que las categorías pudieran reducirse también solo a “procesos, procesos, procesos”. En la práctica, el desarrollo de software es mucho más complejo. Esta visión reduccionista toma en cuenta que establecimiento y consecuente seguimiento de procesos previene fallas subsecuentes, de modo que si un defecto se presenta es por la falta de seguimiento o definición de un proceso.

Existen diversos modelos de desarrollo de softare que funcionan bajo esa premisa pero requiere que el equipo y los procesos sean maduros, y por lo tanto el número de defectos inyectados debría ser menor de manera proporcinal. Sin embargo, en el mundo ágil del desarrollo de software, simplemente no es el caso.

El contexto diverso de cada proyecto de software hace que la clasificación de un defecto dentro de una de las categorías propuestas pueda ser relativamente sencilla o muy compleja. Un ejemplo en el que se observa la complejidad de la clasificación es el siguiente:

Imagine un escenario donde una página web tiene un error en un texto legal donde algunas palabras cuentan con símbolos no alfanuméricos. Al ser un texto relativamente estático, de primera instancia se puede pensar que es un defecto de contenido relacionado con los datos pero al verificar el almacenamiento no se observan los símbolos mencionados.

Una investigación más profunda revela que el texto fue extraido desde la herramienta de gestión de requerimientos e insertada en el archivo de almacenamiento mediante un proceso copy-paste; sin embargo, el programa de edición de textos utilizado para actualizar el archivo de almacenamiento del texto resultó incompatible con el formato UTF, por lo que aparentemente el texto visualmente es correcto pero su representación binaria en el archivo causa la aparición de símbolos cuando se extrae el texto para su inserción en la página web.

Si existe una política definida para el equipo sobre el uso de herramientas para los procesos de extracción de texto, entonces es un defecto causado por no seguir los procesos del SDLC; de lo contrario es un defecto causado por las herramientas del SDLC y como medida de mitigacíón se establecería la política mencionada.

La dinámica del universo del desarrollo de software es en realidad más caótica e inexpugnable de lo que parece, por lo que para mí cualquier elemento de guía o apoyo puede hacer la diferencia entre encallar o llegar a buen pruerto.

Desarrollate, desarrollando!

Deja tus comentarios en Linkedin o en Twitter.

Desarrollo de Software

FinShape para Web ya está disponible

Después de un buen rato de no publicar en este espacio, decidí hacerlo con una excelente noticia 🙂

¡La versión de Web de FinShape ya está disponible!

FinShape es un software de uso libre para la medición de aletas dorsales de delfines, cuyo propósito es ayudar en la investigación de dichas especies sirviendo como apoyo para la foto identificación de individuos y poder asociarlos a groupos y regiones para estudiar aspectos como patrones de migración, su dinámica poblacional, hábitos, etc.

La iniciativa de este software fue de mi hermano Eduardo Morteo como uno de los resultados de su tesis de Mastría en 2001. Originalmente el software era una aplicacion computadoras Windows y tuvo un éxito moderado en la comunidad; sin embargo, debido a que las tecnologías con las que fue desarrollado se fueron haciendo obsoletas, la aplicación poco a poco fue cayendo en desuso.

A principios de 2017, durante una reunión informal nos llamó la atención conocer que había grupos de usuarios en la comunidad cinetífica que continuaban usando la aplicación original y que para ese exclusivo propósito mantenían corriendo una versión de Windows XP. Fue entonces (y en coincidencia con la curiosidad de un grupo de estudiantes universtarios por explorar tecnologías innovadoras) que surgió la idea de migrar la funcionalidad de FinShape hacia una plataforma Web.

Nuestra jornada dió inicio en abril de 2017, haciendo varias sesiones para explicar la funcionalidad, aportar ideas sobre cómo implementarla y sobre qué tecnologías, definiendo la arquitectura etc. El trayecto fue lento principalmente por la disponibilidad de tiempo de los participantes así como la curva de aprendizaje de técnicas, procesos y tecnologías nuevas. Pudimos experimentar con la creación de módulos con diferentes funcionalidades (que finalmente no formaron parte de la liberación de la aplicación) pero de las que sin lugar a dudas aprendimos mucho.

Hoy, tengo el ernorme gusto de presentar a la comunidad el fruto de este gran esfuerzo el cuál está disponible en FinShape.morteo.mx.

Quiero termnar esta publicación agradeciendo el enorme esfuerzo, la paciencia, pero sobre todo la confianza de todos aquellos quienes a lo largo de más de 3 años participaron y colaboraron en el equipo para hacer realidad esta idea.

Educación

El Acuerdo 592 y el articulo 3ro constitucional en el contexto de la educación superior en México

En virtud del Artículo 3ro constitucional y en relación con el Acuerdo 592 para la “Articulación de la educación básica” en México, se hace evidente la necesidad de una alineación formal, planeada y consensada de los perfiles de egreso de los diferentes niveles educativos (incluyendo aquellos no obligatorios como el nivel superior) de modo que se garanticen las características de la educación asentadas en nuestra Carta Magna: la laicidad, la incorporación del progreso científico, el combate a la esclavitud, la contextualización y el enfoque nacional, la convivencia, la inclusión, el respeto así como la calidad educativa.

Desde una perspectiva rigurosa, se advierte de forma inmediata una dislocación entre los perfiles egreso de la educación básica (obligatoria) con los de educación superior (y media superior en el caso de los preceptos legales y normativos vigentes, antes mencionados).

En este sentido y a pesar de que el sistema educativo nacional se encuentra inmerso en todos los niveles en el proceso de gestión, evaluación y cambio con base en la última reforma educativa (entre otras cosas homologando en un sentido general la educación, basándola en competencias para mejorar los logros y elevar la calidad educativa), no se encontró a la fecha ningun documento regulatorio garante de las características de la educación mencionadas anteriormente y previstas en la Constitución de los Estados Unidos Mexicanos para el nivel de educación superior (y media superior en su caso), lo cual abre una brecha de incertidumbre e introduce variabilidad para la instrumentación de procesos, políticas, contenidos (que no currícula en el caso de la educación media superior) y plantea serias dudas en aspectos fundamentales y muy delicados como lo es el caso de la formación profesional y la inclusión (abarcando la equidad de género, así como la no discriminación de grupos étnicos, sociales, y de personas con necesidades educativas especiales.

Asimismo, esta falta de alineación de los perfiles genera importantes y urgentes cuestionamientos pedagógicos (y en su caso andragógicos) cuyo impacto se percibe mayormente en los procesos áulicos, entre los cuales podemos mencionar la el cómo atender a la vasta diversidad (entendida como heterogeneidad) de los discentes y los grupos, cuál es el papel y la idoneidad del docente de tiempo completo comparado con el profesor de asignatura, cómo determinar la calidad, vigencia y pertinencia de los programas educativos (como por ejemplo, local, regional, nacional y global), cuál debe ser el involucramiento de la sociedad y principalmente la familia, y cómo influye la orientación institucional y social en el grado de afectación (positiva y negativa) de las TICs en las escuelas, entre otros.

Del mismo modo (y en un sentido estricto) se puede argumentar que la educación superior de manera general enfatiza y privilegia de forma inherente el conocimiento específico disciplinario de una forma procesal y técnica, dejando en muchos casos la formación “social y humana” (en la generalidad) supeditada a la filosofía institucional o a las costumbres sociales.

Por lo anterior y tomando en cuenta la tendencia actual hacia la profesionalización del docente (de cara a una nueva reforma educativa), se vislumbra una coyuntura que puede ser aprovechada como área de oportunidad para promover esta necesaria alineación entre los perfiles básicos y de la educación superior, en aras de no solo cumplir con los preceptos constitucionales en todos los niveles educativos, sino también para mejorar los logros y la calidad.

Finalmente, y en consecuencia de lo mencionado, también se abren interesantes oportunidades para la investigación y mejoramiento de los procesos de enseñanza aprendizaje, permitiendo una mayor comprensión y un mejor seguimiento del complejo y dinámico contexto tanto de cada nivel educativo como de los resultados generales y específicos, que a su vez nos permitirán evaluar las decisiones y políticas implementadas por las autoridades en búsqueda del perfeccionamiento de la educación Mexicana.

Desarrollo de Software

NodeJS en Ubuntu 14.4 con apt-get

Para aquellos que quieran instalar NodeJS en Ubuntu 14.4

Nota: se asume que tienen acceso una terminal y la contraseña para utilizar el comando “sudo”

Abra una terminal bash y ejecute los siguientes comandos en orden:
sudo apt-get install nodejs [enter]
sudo apt-get install npm [enter]
sudo npm install -g express [enter]
sudo npm install -g express-generator [enter]
sudo ln -s /usr/bin/nodejs /usr/bin/node [enter]

Si al utilizar el npm install obtienes un “Error: EACCES, mkdir” ejecuta los siguientes comandos:

sudo chown -R $USER:$GROUP ~/.npm
sudo chown -R $USER:$GROUP ~/tmp

Y ahora… disfruta nodejs.

Actualizacion:

para instalar paquetes debes user npm link:

sudo npm install -g link

Dentro del folder de la aplicación para instalar express por ejempo:

sudo npm link express
npm start

Desarrollo de Software

Contratos para Desarrolladores

Si bien, el título de esta publicación puede ser engañoso, me permito hacer la correspondiente aclaración para evitar confusiones: en efecto, no voy a mostrar ni a referir ejemplos del texto de los documentos legales para realizar proyectos de software (que en realidad puenden ser encontrados en otras partes); en cambio, realizaré una breve comparación entre estos documentos y los programas de cómputo; la cual  espero que sea de interés y utilidad para  mis colegas desarrolladores.

Como todos los lenguajes de programación, también todos los contratos legales tienen una estructura y sintaxis. Del mismo modo, en esencia, hay una serie de elementos requeridos que se aplican a todos y cada uno los contratos. Estos elementos se pueden comparar a elementos tomados del código fuente de un programa informático, específicamente los parecidos al lenguaje C.

Antes de comenzar, me gustaría indicar que así como es una buena práctica para los desarrolladores el nombrar a su proyecto de programación de acuerdo al objetivo que persigue y utilizar alguna convensión de denominación para nombrar los archivos, variables y procedimientos con base en el dominio del problema al que se adscribe; comparativamente, existen convenciones acerca de cómo se denominan los contratos en función de su finalidad y todos ellos utilizan términos legales comunes relacionados con el contexto específico de su aplicación.

Ahora, independientemente del orden de aparición de los elementos siguientes, en relación con sus contrapartes de programación, los elementos comparativos antes mencionados se describen a continuación:

  • Bibliotecas: En el espíritu de evitar tanto reinventar la rueda como las repeticiones innecesarias (fomentando la reutilización), los lenguajes de programación hacen uso de bibliotecas de código (o precompiladas) a través de declaraciones de uso o de inclusión. Estas declaraciones son comparables a citar las leyes o reglamentos en los contratos que se eligen en función de la finalidad del mismo y también, por lo general, se encuentran al principio del documento.
  • Declaración e inicialización de variables: Estos elementos definen los tipos de datos de las variables y constantes que se utilizarán, y los preparan con valores adecuados. Esto mismo ocurre con las cláusulas primarias o “Declaraciones” en un contrato. Lo anterior, incluye lo que en la jerga legal se conoce como la definición de “las partes”, es decir, identificar formalmente a las entidades físicas (personas) o morales (organizaciones) entre las cuales se celebra el contrato.
  • Procedimientos: Las funciones son principalmente lo que hace que un programa, haga tic tac y estas deben ser cuidadosamente estructuradas y ser particularmente escritas de manera clara y precisa con el fin de lograr los resultados previstos. También algunas funciones realizan llamadas (o hacen referencias) a otras funciones. Escribir las cláusulas de los contratos son el equivalente a programar las funciones en un programa.
  • Sintaxis y gramática: Cada uno de los lenguajes de programación tiene una sintaxis específica que define las estructuras utilizables (tipos de datos, clases, procedimientos, estructuras de datos, palabras reservadas, y la forma de redacción, puntuación, etc.). Como usted ya debe imaginarse, esto es comparable a las características del idioma en que un contrato está escrito; sin embargo, vale la pena mencionar que, al igual que con cualquier lenguaje de programación, el no conocer un grado decente del lenguaje y sus reglas, puede echar a la basura el resultado esperado del contrato, por ejemplo al cambiar de lugar una coma, u olvidar la declaración o inicialización (descripción) de un término, etc,.

Así como es recomendable utilizar números de línea al revisar los archivos de código fuente, también es sumamente recomendable utilizar números de cláusulas para facilitar la lectura de los contratos.

Adicionalmente un archivo de código fuente se encuentra suscrito a ubicación dentro del sistema de archivos (llámese directorio, folder o carpeta), y se le asigna una fecha de creación y el número de bytes de los que consta; del mismo modo los contratos se deben adscribir a una ubicación (localidad), deben tener una fecha de creación (y de vigencia) y un número de páginas (el cual es recomendable agregar en cada una de ellas).

En ocasiones, los archivos de código fuente especifican directivas que para su interpretación por un compilador específico. De la misma manera, algunos contratos adscriben la jurisdicción del mismo para su interpretación por ciertas autoridades específicas en una localidad o de cierta índole. Dicha situación es importante tomarla en cuenta porque (al igual que si no contamos con el compilador específico) esto puede resultar en una interpretación distinta del contenido del documento y la incursión de gastos importantes para las partes.

Por último, los certificados de programa son comparables a las firmas del contrato ya que dan cuenta de su legitimidad y validan su contenido.

Si están los contratos o el software están bien escritos, por lo general son  simples, elegantes, robustos y escalables. A este tipo de documentos se les llama con frecuencia “obras maestras”, como si fueran poemas dentro de  sus dominios respectivos.

Por desgracia para nosotros los desarrolladores no existen IDEs (fuera de los procesadores de palabras) ni compiladores que nos ayuden a escribir o revisar contratos, pero espero que este breve texto pueda servir a mis compañeros “codificadores” a por lo menos identificar las piezas faltantes y los errores comunes en estos documentos tan necesarios en nuestro quehacer profesional.

“Codificar o no codificar, es el dilema diario y permanente de los programadores…”

Educación

La Dialogicidad dentro de la teoría ecológica de la educación

En el estudio de la comunicación educativa, se observa de manera recurrente un fenómeno derivado de la reciprocidad en el intercambio de información entre los sujetos que participan en el proceso enseñanza-aprendizaje, especialmente en los ambientes colaborativos.

Como lo indica Freire (1970) “[…] el educador ya no es solo el que educa si no aquel que, en tanto educa, es educado a través del diálogo con el educando, quien, al ser educado, también educa. Así, ambos se transforman en sujetos del proceso en que crecen juntos y en el cual los argumentos de la autoridad ya no rigen”.

Desde una perspectiva fenomenológica, esta situación puede ser mejor entendida  a través del concepto de la dialogicidad, precisada como la esencia misma de la educación y que implica el encuentro de las personas mediante la praxis del diálogo mismo como un proceso transformador del individuo que engloba dos fases constitutivas e indisolubles: acción y reflexión (Cooperación en Red Euro Americana para el Desarrollo Sostenible, 2014)

“Hablar de dialogicidad en el campo educativo, es potenciar, además de la construcción de la voz de los sujetos, el encuentro y reconocimiento con el otro como sujeto, que interactúa con un saber particular y que proporciona una construcción colectiva del saber y de la intersubjetividad”. (Alvarez, 2012)

En otras palabras, en el contexto de la educación formal, es mediante este encuentro que se ejercita de manera activa y consiente la comunicación entre los interlocutores, procurando que su efectividad en términos de la satisfacción de las necesidades tanto colectivas como individuales identificadas por el docente y enmarcadas en el programa educativo correspondiente, al mismo tiempo que es se enlaza a los sujetos con su realidad cotidiana.

Las características principales de la dialogicidad, según (Alvarez, 2012) son: el reconocimiento y la apreciación de la voz de cada uno de los participantes, la actitud de escucha y el respeto por la posición de los demás, la construcción colectiva de saberes desde el acuerdo o la oposición, la importancia de la voz del otro para generar puntos de encuentro que respalden cada posición, el papel diferenciado del maestro y el estudiante desde un encuentro respetuoso, el valor de cada una de las ideas expresadas a partir de una producción de saber individual y colectiva y, la actitud reflexiva y crítica, problematizadora e investigativa.

Entendiendo la dialogicidad como un proceso pedagógico, se pueden identificar los roles o agentes involucrados, denominados mediador (o intermediario) y sujetos de saber. Estos últimos (bajo el amparo del primero) son responsables de su propia construcción del conocimiento y deben proporcionar sus ideas desde una argumentación sólida, con una postura determinada, pudiendo debatir, refutar y controvertir sin invalidar la palabra de otro sujeto (Alvarez, 2012).

Se advierte entonces que durante este proceso el papel del docente se vuelve multidimensional, pudiendo ser a la vez mediador y sujeto de saber.

Asimismo, Álvarez (2012) apunta que mediante la dialogicidad, el lenguaje verbal se constituye como una fuente de construcción de conocimientos, de identidades individuales y colectivas, de pertenencia al grupo, de participación, de reconocimiento de pautas sociales de interacción. Es decir, como resultado de este proceso se generan lo que se conoce como representaciones sociales.

Sin embargo; se destaca que la construcción o generación colectiva de estas representaciones compartidas socialmente no significa que se conviertan en concepciones universales de los objetos de la realidad social. Por el contrario, dichas representaciones cumplen una función más individual y práctica a modo de “anteojos” que guían la percepción y acción de los agentes, determinando la manera en la que estos se acercan a la realidad (Piñero Ramírez, 2008).

Siendo que “existe una correspondencia entre la estructura social y las estructuras mentales, entre las divisiones objetivas del mundo social […] y los principios de visión y división que les aplican los agentes” (Bourdieu, 1989) citado en (Piñero Ramírez, 2008), de acuerdo a la dinámica grupal con base en el modelo pedagógico formal y a la estructura instaurada por el docente durante el proceso pedagógico, el maestro tiene una influencia intrínseca en la generación de las representaciones.

De este modo, considerando que la escuela activa supone que ninguna experiencia educativa es definitiva (Wikipedia, 2014) y siendo la configuración social influida por quienes participan en la construcción de la realidad social (Piñero Ramírez, 2008) y viceversa, es en este punto que se advierte de forma incuestionable la magnitud del papel multidimensional del docente.

Dicho de otra manera, para maximizar el potencial de la dialogicidad como recurso pedagógico en el contexto de la educación formal y considerando la dinámica grupal, el docente debe aprovechar su rol para promover una especie de ciclo hamiltoniano enfatizando cada vértice temático y procurando a la vez la verificación de las representaciones generadas colectivamente para su reconocimiento individual por los agentes, sin que ello necesariamente signifique un consenso general en sus significados.

De acuerdo con Araya, 2002 e Ibáñez, 1994) citado en (Piñero Ramírez, 2008) “las representaciones sociales se expresan en proceso y en contenido: Como proceso, se refieren a las formas en que se adquiere y comunican conocimientos; en este proceso interviene el papel que desempeñan los distintos medios de comunicación para la creación, transmisión y reproducción de las formas simbólicas.

Por lo anterior, lejos de desestimarse la influencia que tienen los medios de comunicación, deben incluirse en el proceso pedagógico a través de lo que hoy se conoce como alfabetización mediática e informacional (UNESCO, 2014).

Como contenido, las representaciones sociales se manifiestan a través de tres dimensiones: la actitud (proceso afectivo), la información (formas de explicación que el agente posee acerca del objeto) y el campo de representación (la forma en que se organizan los diversos elementos que la estructuran (Piñero Ramírez, 2008).

La convergencia de estas tres dimensiones tiene implicaciones individuales endógenas  y exógenas por lo que hace sentido analizar e proceso de construcción de representaciones sociales tanto en proceso como en contenido desde una perspectiva ecológica.

Esta perspectiva se adscribe en los términos de una visión integradora, que sitúe al individuo dentro de su entorno y considere sus relaciones e interacciones, con el propósito de comprender su dinámica individual, grupal y como parte de un ecosistema social.

En 1987 Urie Bronfenbrenner propuso una perspectiva del desarrollo humano en la que su ambiente se concibe como un conjunto de estructuras anidadas en cuyo núcleo se encuentra el individuo rodeado a su vez por el “micro sistema” o nivel más inmediato de las estructuras (usualmente entorno familiar), este es cubierto por el mesosistema (que comprende las esferas sociales en las el sujeto se encuentra insertado), la siguiente estructura anidada o capa corresponde al exosistema (integrado por contextos más amplios donde el sujeto no se percibe necesariamente como activo) y finalmente se describe la estructura del macrosistema que incluye la cultura y subcultura en la que se desenvuelve tanto el individuo como las personas que conforman su sociedad (Bronfenbrenner , LA ECOLOGIA DEL DESARROLLO HUMANO, 1987). Adicionalmente se describe al cronosistema que atribuye una dimensión temporal al modelo (Bronfenbrenner, Ecological Models of Human Development, 1994).

Por lo tanto, considerando a la educación como un factor transversal en la estructura  propuesta por Bronfenbrenner, se debe concebir el modelo pedagógico ecológico como la convergencia entre los aspectos tanto formales como informales del proceso de enseñanza/aprendizaje.

Estableciendo que un individuo mantiene un proceso educativo permanente desde su gestación, hasta su defunción (Bacre Parra, 2001), es comprensible la necesidad de guiar este proceso para que sea significativo y se oriente hacia las necesidades individuales y sociales.

Sin embargo; desde el punto de vista pedagógico es inconcebible el intento de educar a un sujeto, en cualquier nivel, en contra de su voluntad; empero, la educación (entendida como un proceso y no como un producto) es la única forma promover la supervivencia individual y social.

“Numerosos estudios han puesto de manifiesto que los alumnos que aprenden de manera más significativa son aquellos que reconocen qué les pretende enseñar el profesor o la profesora y de qué manera lo piensa hacer” (Jorba & Sanmarti, 1993).

En este orden de ideas, y en virtud de lo anteriormente expuesto, hace sentido promover entonces el recurso pedagógico de la dialogicidad contextualizada en la realidad de los agentes involucrados y en el marco de la temática formal pretendida por el docente para el cumplimiento del modelo formal, de manera consciente y en la concepción de un entorno didáctico ecológico.

Referencias

Alvarez, J. (2012). La dialogicidad en el aula. Obtenido de javeriana: http://www.javeriana.edu.co/blogs/perezr/files/Alvarez-Jenny-2012.pdf

Bacre Parra, V. M. (Mayo/Junio de 2001). Didáctica de la Comunicación: ¿Enseñar a comunicar? (La computadora en la creación de espacios significativos de aprendizaje). EGE, 13-18.

Bronfenbrenner , U. (1987). LA ECOLOGIA DEL DESARROLLO HUMANO. PAIDOS IBERICA.

BRONFENBRENNER, U. (1987). LA ECOLOGIA DEL DESARROLLO HUMANO. PAIDOS IBERICA.

Bronfenbrenner, U. (1994). Ecological Models of Human Development. International Encyclopedia of Education, 3, 2nd. Ed., 37-43.

Cooperación en Red Euro Americana para el Desarrollo Sostenible. (8 de 10 de 2014). La dialogicidad – Paulo Freire. Obtenido de Creadess: http://www.creadess.org/index.php/informate/desarrollo-humano1/educacion/22154-la-dialogicidad-paulo-freire

FREIRE, P. (1970). Pedagogía del Oprimido. México: Editores S.A. de C.V.

Jorba, J., & Sanmarti, N. (1993). Aula de Innovación Educativa. Revista Aula de Innovación Educativa 20.

Piñero Ramírez, S. L. (2008). La teoría de las representaciones sociales y la perspectiva de Pierre Bourdieu: Una articulación conceptual. Revista de Investigación Educativa 7, 1-19. Recuperado el 05 de 10 de 2014, de http://www.uv.mx/cpue/num7/inves/pinero_epresentaciones_bourdieu.html

UNESCO. (10 de 10 de 2014). Programa de Formación en Alfabetización Mediática e Informacional destinado a los adolescentes. Obtenido de UNESCO: http://www.unesco.org/new/fileadmin/MULTIMEDIA/HQ/CI/CI/pdf/media_and_information_literacy_curriculum_for_teachers_es.pdf

Wikipedia. (9 de 10 de 2014). Pedagogía Progresista. Obtenido de Wikipedia: http://es.wikipedia.org/wiki/Pedagog%C3%ADa_progresista

 

Anuncios generales

Cursos restaurados

Aside

Estimados miembros de la comunidad:

Tal como lo habíamos comunicado, debido a una actualización del servidor, el servicio de Moodle no estuvo disponible durante el fin de semana (26 y 27 de abril de 2014).

Por este medio les informamos que el servicio ha sido restaurado y funciona normalmente.

Agradecemos su comprensión y apoyo.

Saludos cordiales.

Anuncios generales

Nuevo servicio (Moodle) disponible a la comunidad

Estimados usuarios, es muy grato para mi anunciarles que a partir del 20 de marzo se encuentra instalada la plataforma Moodle en la dirección: http://cursos.morteo.mx, en la cual podrán agregar cursos curriculares o de actualización para que sean impartidos en línea por ustedes y para sus estudiantes.

Para obtener acceso y consultar material sobre el uso de la plataforma, así como para verificar las políticas del servicio por favor ponte en contacto con nosotros.

¡Ánimo!

Un espacio para todos