Conocimiento tácito y explícito

El conocimiento es generado por los seres humanos y se puede transmitir por distintos medios que no sean genéticos. Existen dos tipos de conocimiento que son aplicados regularmente por quiénes generan conocimiento, estos son el conocimiento tácito y el conocimiento explícito.

“La distinción entre conocimiento tácito y conocimiento explícito (o codificado) fue establecida por Polanyi”.

El conocimiento tácito es aquel usado por los individuos, organizaciones o empresas para lograr alcanzar un propósito práctico, pero este propósito no se puede explicar o comunicar de manera sencilla. Aquí entre la inteligencia de los individuos para interpretar la información o el conocimiento generado a partir de este. Quizá la única forma de comunicar este conocimiento es a través de relación “maestro-aprendiz”. Las habilidades de los individuos es una importante clase de conocimiento tácito, de aquí que nace la idea de la relación, con el fin de enseñar inteligentemente las habilidades que tiene un individuo a otro.

El conocimiento explícito en cambio, es aquel que puede ser representado o expresado formalmente de acuerdo a una codificación y que se puede comunicar fácilmente. Este tipo de conocimiento puede ser transmitido mediante lenguaje formal y de una forma estructurada. Los dos conocimiento son complementarios, el conocimiento explícito debe ser tácitamente entendido y aplicado, es decir, el conocimiento explícito debe aplicar mecanismos que permitan a los individuos aprender, interpretar y entender el contenido codificado.

En mi caso, tratándose del estudio de los sistemas informáticos, producción de software, análisis de sistemas, etc., aplicaría los dos conocimiento, el conocimiento tácito porque me permitiría aprender habilidades de otros individuos que no tienen la facilidad de comunicar lo que saben, pero que con cierta información lo podría aplicar, tal es el caso de la reparación de los equipos, no hace falta explicar detalladamente todo el proceso de reparación del mainboard por ejemplo, lo importante es identificar e interpretar la información que se tiene para luego aplicarla.

El conocimiento explícito lo aplicaría en las publicaciones de mis investigaciones, ahí necesito estructurar, explicar y comunicar formalmente el conocimiento que he adquirido, basándome en políticas o estándares definidos por comunidades científicas e ingeniería, calor está, expresado tácitamente, de tal forma que los usuarios puedan aprender de la propuesta que he desarrollado.

Los dos conocimientos son complementarios y por tanto se deben aplicar a cualquier forma de aprendizaje y de generación del propio conocimiento.

Modelos Ocultos de Markov – Arquitectura

Los Modelos Ocultos de Markov (HMM) representan un proceso en el cual se refleja un alto grado de probabilidades, probabilidades que generan una secuencia de acciones o eventos que se pueden observar, lo que no ocurre con el proceso de probabilidad utilizado, este no es observable, pero sí afecta directamente a la secuencia de acciones que lo son. Los Modelos Ocultos de Markov pueden ser definidos como un modelo de un proceso, el cual genera una secuencia de acciones o eventos de un dominio específico.

La principal meta de los HMM es identificar los valores desconocidos u ocultos de la secuencia de acciones generada a partir de valores o parámetros observables. “Un HMM se puede considerar como la red bayesiana dinámica más simple”. Los valores que se obtengan, son analizados y sus resultados pueden ser utilizados para desarrollarlas distintas aplicaciones como: reconocimiento de patrones, Traducción automática, Bioinformática, etc.

Según el desarrollo de dichas aplicaciones o el análisis que se requiera se utiliza una arquitectura de Modelos Ocultos de Markov. Esta arquitectura viene dada por el número de estados (variable aleatoria) que lo componen y las transiciones o conexiones entre los estados. De igual manera ocurre en las redes neuronales, su arquitectura depende mucho del número de neuronas (estados) y las transiciones entre estas (conexiones sinápticas). Existen dos modelos principales que representan la arquitectura de un HMM: Modelos HMM de izquierda a derecha y Modelos HMM ergódicos.

En los modelos de izquierda a derecha, los elementos o las probabilidades que genera las acciones o eventos deben cumplir con una condición Aij = 0, donde j<i. Esto significa que, si el modelo se encuentra en un determinado tiempo (t), en el siguiente instante (t+1), el modelo permanecerá con el mismo valor de probabilidad Aii, de no ocurrir esto, el modelo pasará a un estado j-ésino con una probabilidad Aij. Este modelo es idóneo para aquellas aplicaciones en los cuales se sigue un proceso secuencial, por ejemplo: la identificación de blancos aéreos, en los cuales se utiliza una secuencia de entrenamiento para cada objetivo basados en un conjunto de observaciones almacenadas en un array.

Lo contrario ocurre con los modelos ergódicos, estos pueden evolucionar desde cualquier estado a otro en un número finito de transiciones, todas las transiciones son posibles. Este modelo es aplicado en proceso en los cuales se produce una toma de decisiones, otro ejemplo claro, es el reconocimiento de gestos, en el cual se utiliza una base de entrenamiento construida en base a la información obtenida de los gestos, esta base se ajusta a los valores, se la interrelaciona y se obtiene los resultados.

Los modelos deben ser seleccionados según la aplicación, deben ser ejecutados adecuadamente y cumplir con las condiciones que en cada modelo se estimen pertinentes.

Publicado en eccutpl, IAA, Loja, Universidad, UTPL. Etiquetas: , , , , . 1 Comment »

Combinando disciplina con metodologías ágiles

Si bien es cierto que el desarrollo de software implica la ejecución de procesos y metodologías acordes a al desarrollo, es necesario la aplicación de procesos ágiles de desarrollo de software o también conocidos como metodologías liviana, con el fin de enfocarse en la gente que participa y en los resultados como mejoramiento de calidad de los productos, proceso, minimización de costos y tiempo. Las metodologías ágiles se centran en las iteraciones que se obtienen en cada una de las etapas del ciclo de vida del proceso de desarrollo: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación; y en la adaptabilidad de procesos para la construcción del software. La idea es que en cada iteración se obtenga un demo funcional, es decir, sin errores.

Por lo general estas metodologías son consideradas indisciplinadas por la falta de documentación técnica, pero las características que esta posee y la facilidad al aplicar las distintas metodologías como Programación extrema (XP), Crystal clear, Adaptived Software Development (ASD), Rational Unified Process (RUP) y otras, hacen que se torne disciplinaria. La disciplina consiste en la ejecución adecuada de dichas metodologías; tecnologías ágiles; integración de modelos como CMMI, Cobit, ISO; procesos adaptables y de mejores prácticas de desarrollo de software que pueden ser utilizadas desde la construcción de pequeñas aplicaciones y componentes de un sistema, hasta el desarrollo y construcción de un sistema empresarial completo. Una de las principales características de las metodologías ágiles es la insistencia en la planificación adaptable a cambios y enfocada a personas. Lo que significa un gran esfuerzo y agilidad de parte del equipo de desarrollo y el mejoramiento continuo de de sus procesos.

Como características de metodologías ágiles se tiene que:

  • Dan énfasis en las pruebas la aplicación en construcción y una continua integración de cada uno de sus componentes.
  • Mantiene sencillez en la definición, diseño y desarrollo de cada componente que constituye el software o producto.
  • Documenta solamente lo necesario, se centra en lo más importante del software o producto, el código fuente.
  • Permite validar la habilidad de desarrollar software en un equipo de ingeniería de software o en una organización a través de una evaluación estándar.
  • Permite establecer reuniones de avances y recopilación de requerimientos.
  • Se adaptan a las necesidades y entorno cambiante de los proyectos.


El hecho de aplicar metodologías ágiles a un determinado proyecto, no quiere decir que no se pueda aplicar otras, de hecho la combinación con metodologías tradicionales resulta muy interesante, se puede involucrar prácticas de ambas metodologías de tal forma que obtendríamos una metodología conjunta por cada proyecto. El único problema que existiría es definir cada una de las prácticas que se deben utilizar y, si es necesario definir parámetros para identificar cuál de ellas aplicar.

¿Pero, qué es ser ágil? La agilidad en el desarrollo de software se describe como un marco de trabajo en que se busca aplicar mejores prácticas para minimizar los riesgos de un proyecto a través de iteraciones muy cortas pero funcionales.

La integración de modelos, metodologías, procesos mejorados y nuevas tendencias, seguramente incrementarán el nivel de éxito de los proyectos y la calidad de los productos. Pero sería importante tomar en cuenta la capacidad de comunicación y trabajo del equipo de desarrollo de software, además, de procesos o modelos de bajo nivel como Personal Software Process (PSP) para complementar los otros modelos y lograr un desarrollo de software eficaz y una respuesta adecuada e inmediata al cambio, principalmente en aquellos proyectos en los que intervienen requisitos inestables.

Lo más importante que toda organización o equipo de software debe tener en cuenta es que, no existe una metodología ideal para un proyecto en la que se aplique. La metodología seleccionada sea esta ágil o tradicional, siempre dependerá directamente del equipo de desarrollo, la organización, lo cambiante del entorno y lo primordial, la aceptación de los usuarios finales.

Gestión de Proyectos de Software

En todo proyecto de software existe la necesidad de tener una adecuada gestión de los proyectos, para esto se debe contar con el personal capacitado, seleccionar el mejor proceso de acuerdo al problema que se vaya a tratar, y por supuesto una excelente planificación, con el fin de obtener un producto a tiempo y de calidad.

Cuando se desea realizar una gestión adecuada, eficaz y eficiente en la gestión de proyectos de software, es necesario que se ponga en funcionamiento cuatro características muy importantes en esta gestión, las cuatro P: personal, producto, proceso y proyecto. El gestor de proyectos muchas de las veces se olvida que el éxito o fracaso de los proyectos depende fundamentalmente del equipo humano con el que trabaje. El gestor debe basarse en procesos válidos y que verdaderamente le sirvan a su proyecto, no construir soluciones elegantes para problemas equivocados. Todo proyecto debe tener consigo una planificación previa, no se debe aventurar al éxito sin antes conocer los beneficios, contras y coste de cada uno de los proyectos. La ejecución de las cuatro características marcará el rumbo del éxito del gestor y de sus proyectos.

EL PERSONAL

El factor humano siempre será el más importante en el desarrollo de soluciones software, muchos empresarios famosos, líderes de empresas tecnológicas, coinciden que el éxito que han alcanzado sus empresas no se debe a las herramientas que utilizan, es la gente y el trabajo en equipo.

El Instituto de Ingeniería de Software, al ver la importancia que tiene el factor humano en la construcción del software, ha desarrollado un modelo de madurez de la capacidad de gestión del personal, esto con el fin de ayudar a las organizaciones de software a incrementar la rapidez en el desarrollo de proyectos cada vez más complejos.

Gestión de Proyectos de Software

Al aplicar el modelo, la organización lograr atraer personal talentoso e inteligente que desea superarse y sobre todo, desea participar y trabajar en equipo para la consecución de los proyectos en los que participe. El reclutamiento y selección es fundamental en la gestión del personal, aquí se ve realmente cuáles son las personas que están en la capacidad de aportar a la organización, y no sólo eso, también se ve si pueden trabajar bajo presiones y en equipo. Para que el personal trabaje con ganas y pueda quedarse por un largo tiempo en la organización, sobre todo aquellos talentosos que siempre generan ideas innovadoras, deben ser motivados, sea esto económicamente, o con el buen trato de parte de sus superiores.

Es importante medir el desempeño del personal, así el gerente o dueño puede darse cuenta lo que realmente hacen sus trabajadores, es decir, si estos participan activamente en los proyectos que se están generando. A partir de esto, el gerente o dueño puede darse cuenta de que el equipo de trabajadores tiene suficiente capacidad y la responsabilidad de desarrollar sus tareas, o también, que a su gente le falta motivación y necesita algún estímulo para mejorar su rendimiento.

El proceso de software está integrado por participantes, líderes de equipo, etc. Los participantes se los puede clasificar en cinco categorías:

Gestores ejecutivo: Definen los aspectos del negocio.

Gestores del proyecto: Planifican, motivan, organizan y controlan a los profesionales que construyen el software.

Profesionales: Proporcionan las habilidades técnicas necesarias.

Clientes: Especifican los requerimientos.

Usuarios finales: Interactúan con el software.

Los líderes de equipo son difíciles de conseguir en el proceso de software, por lo general las personas no tienen la capacidad para trabajar con el personal. El líder debe ser capaz de motivar al personal técnico para que produzca lo mejor en base a su capacidad. La organización es fundamental en un proceso, el líder debe adecuar los procesos para generar un producto final excelente. Lo más importante, debe generar nuevas ideas, ideas innovadoras que ayuden a su equipo y les permita dar solución a problemas sumamente complejos o darle un valor agregado al producto.

El equipo de software debe ser uno solo, es decir, funcionar como conjunto, apoyarse mutuamente con el fin de logar el cumplimiento de los objetivos planteados. Todos los miembros del equipo deben tenerse confianza y distribuir la carga de trabajo según el problema que se esté tratando. No todo equipo es eficiente, pero se puede logar esto con la suficiente motivación y el apoyo de un buen gestor de proyectos.

EL PRODUCTO

Muchas veces cuando un cliente pide que le construyan una solución, siempre pregunta ¿cuánto me va a costar? Pues bien, todo producto requiere estimaciones cuantitativas y una adecuada planificación. Una adecuada recolección de información y un análisis detallado de los requerimientos proporciona la información necesaria para dar una estimación del costo del producto. Antes de planear un proyecto, se debe establecer los objetivos y el alcance que tendrá el proyecto, además de sus restricciones técnicas y de gestión. Con una buena planificación se puede estimar el tiempo que tomará desarrollar o construir el producto y redimensionar el valor cuantitativo del producto.

El desarrollador del software debe reunirse con el cliente las veces que sean necesarias para definir el dominio y los objetivos del producto. Esta actividad, comienza con la aplicación del proceso de ingeniería de requisitos; captura, análisis y, validación y verificación.

Definidos los objetivos y el dominio del producto se determina soluciones alternativas y viables, estas soluciones permitirán a los gestores del proyecto seleccionar las mejores opciones que convengan para cumplir con las restricciones que tenga la construcción del producto, sean estas de tiempo, presupuestarias, de personal, etc.

Para lograr rapidez en la construcción del producto, se debe dividir la carga de trabajo entre el equipo de desarrollo, es decir, dividir el problema. Esto, con el fin de desarrollar con mayor eficiencia y eficacia y en el tiempo acordado con el cliente, el producto.

EL PROCESO

El proceso del software proporciona un marco de trabajo desde el cual se puede establecer un plan detallado para la construcción del software. Todas las actividades del marco de trabajo se las pueden aplicar a la mayoría de proyectos de software, sino es a todos. El equipo de desarrollo debe elegir el proceso adecuado y que le permita obtener una solución o producto que satisfaga las necesidades o requerimientos del cliente.

El gestor del proyecto debe elegir el modelo de procesos adecuado para ser aplicado en la construcción del software, y el adecuado para:

– Los clientes que han solicitado el producto y el personal que hará el trabajo.

– Las características del producto.

– El ambiente del proyecto en el que trabaja el equipo de desarrollo del software.

Seleccionado el modelo de procesos, se desarrolla una planeación preliminar del proyecto basado en las actividades del marco de trabajo. Esta planeación comienza con la combinación del producto y el proceso. Cuando el equipo de desarrollo de software ha definido correctamente el modelo proceso, este debe ser flexible y adecuado para el proyecto. El proceso se puede descomponer para logar ejecutar correctamente las actividades y tareas del marco de trabajo. Las actividades que se deben desarrollar son:

– Desarrollar una lista de conflictos que deben clasificarse.

– Reunirse con los clientes para abordar los conflictos que deben clasificarse.

– Desarrollar en conjunto un enunciado del ámbito.

– Revisar el enunciado del ámbito con todos los implicados.

– Modificar el enunciado del ámbito según lo requiera.

EL PROYECTO

Cuando se gestiona un proyecto exitoso, es necesario entender que este puede llegar a fracasar. Según John Reel, existen 10 razones por las cuales un proyecto puede fracasar:

1. El personal de software no entiende las necesidades del los clientes.

2. El ámbito del producto está mal definido.

3. Los cambios se gestionan mal.

4. La tecnología elegida cambia.

5. Las necesidades comerciales cambian.

6. Los plazos de entrega no son realistas.

7. Los usuarios se resisten a la utilización del software.

8. Se pierde el patrocinio.

9. El equipo del proyecto carece de personal con las habilidades apropiadas.

10. Los gestores evitan las mejores prácticas y las lecciones aprendidas.

Para tener éxito en la consecución de un proyecto es necesario comenzar con pie derecho, esto se lo logra trabajando duro para entender el problema y dar una solución adecuada. Se debe rastrear el proyecto conforme se elabora el producto y se aprueba por parte del grupo de control de calidad. Es importante que el gestor del proyecto tome decisiones inteligentes para no poner en riesgo el desarrollo de la solución. Por último, se debe analizar los resultados obtenidos para obtener la experiencia necesaria en la construcción de otros proyectos.

Aprendizaje Automático

El Aprendizaje Automático es una rama de la Inteligencia Artificial en la cual su principal objetivo es desarrollar técnicas que permitan a las computadoras aprender, es decir, se considera como un proceso de inducción del conocimiento. El aprendizaje automático se centra en el estudio de la Complejidad Computacional de los problemas. Muchos problemas son de clase NP-hard, por lo que las aplicaciones desarrolladas en aprendizaje automático están enfocadas al diseño de soluciones viables a esos problemas.

Dentro de las aplicaciones de aprendizaje automático están: motores de búsqueda, diagnósticos médicos, detección de fraude en el uso de tarjetas de crédito, análisis del mercado de valores, clasificación de secuencias de ADN, reconocimiento del habla y del lenguaje escrito, juegos y robótica.

Algunos expertos en el desarrollo de sistemas de aprendizaje automático han tratado de eliminar la intuición o el conocimiento de los procesos que se generan en la interacción hombre-máquina; otros, en cambio, tratan de establecer una colaboración entre estos dos elementos. La participación humana y sus intuición no puede ser remplazada por una máquina, el humano, es decir, el experto que desarrolla estos sistemas es quién hace el diseño y determina los procesos que debe realizar el sistema o la máquina. Por lo tanto no puede ser remplazado, a excepción de algunas tareas o procesos que son automatizados para mejorar el rendimiento de estos sistemas.

A través del aprendizaje automático se puede generar tres tipos de conocimiento, cada tipo dependerá del tema que se desee aprender:

1. Crecimiento
Es el que se adquiere de lo que nos rodea, el cual guarda la información en la memoria como si dejara huellas.

2. Reestructuración
Al interpretar los conocimientos el individuo razona y genera nuevo conocimiento al cual se le llama de reestructuración.

3. Ajuste
Es el que se obtiene al generalizar varios conceptos o generando los propios.

Existen algoritmos que son utilizados en el aprendizaje automático para la generación de conocimiento y el mejoramiento en el rendimiento de los sistemas computacionales. Son cinco los algoritmos utilizados, estos son:

1. Aprendizaje supervisado
Produce una función que establece una correspondencia entre las entradas y las salidas deseadas del sistema.

2. Aprendizaje no supervisado
Todo el proceso se lleva a cabo sobre un conjunto de ejemplos formado por entradas al sistema. No existe información de las categorías de esos ejemplos.

3. Aprendizaje por refuerzo
El algoritmo aprende observando el mundo que le rodea. Su información de entrada es la retroalimentación que obtiene del exterior en función de sus acciones.

4. Transducción
Similar al aprendizaje supervisado, pero no construye de forma explícita una función. Trata de predecir las categorías de los futuros ejemplos basándose en los ejemplos de entrada, sus respectivas categorías y ejemplos nuevos.

5. Aprendizaje multi-tarea
Métodos de aprendizaje que usan conocimiento previamente aprendido por el sistema con el fin de enfrentarse a problemas similares a los vistos.

El aprendizaje automático se ha convertido en un eje fundamental de la inteligencia artificial. En la construcción de sistemas inteligentes, es necesario que estos aprendan y vayan adquiriendo experiencia conforme realizan sus procesos sin la necesidad de una supervisión por parte de expertos.

Proceso de la Ingeniería de Requisitos

Es muy importante definir cuál es el proceso de ingeniería de requisitos ya que esto nos va a servir para la obtención correcta de los requerimientos. Se han definido diversos modelos a nivel de toda la Ingeniería de Software, así tenemos para el desarrollo de aplicaciones web, de escritorio, o sencillamente se ha definido un estándar, pero en general, la mayor parte de estos procesos tienen un símil y lo único que buscan es recopilar la mayor cantidad de requerimientos correctos para así conformar una buena estructura que servirá de base para el desarrollo de un proyecto.

Proceso de la Ingenier�a de Requisitos

 

En la figura, se muestra un esquema del proceso de la ingeniería de requisitos basado en la Ingeniería de Software de Gestión. El proceso se cumple en cinco fases: viabilidad, captura y análisis, especificación, validación y gestión de requisitos.

 

Estudio de viabilidad: Este permitirá rendir un informe tanto al equipo de desarrollo del proyecto como al usuario o cliente, donde se verificará si el proyecto vale la pena desarrollarlo. Es de vital importancia para la satisfacción de los objetivos del negocio.

 

Captura y Análisis: En esta fase el desarrollador o su equipo de desarrollo entran en contacto con el usuario final o con el cliente para determinar el alcance del proyecto o del sistema que se desea construir, además, se debe identificar cuáles son los servicios que prestará el sistema, su rendimiento, sus necesidades y restricciones, y cuáles son los objetivos esperados.

 

Especificación: Aquí se debe obtener un documento de especificación de requisitos, en cual se llega a definir de una forma completa, precisa y verificable cada uno de los requerimientos o necesidades que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones (software, hardware).

 

Validación: Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos definen el sistema o proyecto que se va a construir y que desea el cliente. En esta etapa solamente entran aquellos requisitos que se mencionaron ya en la especificación.

 

Gestión: Se realiza la comprensión y control de los cambios de cada una de los requisitos, sean estos requisitos estables (corresponden al estado del sistema) o volátiles (representan eventos que hacen que el sistema realice una función dada).

¿Qué es Ingeniería de Requisitos (IR)?

Existen varios conceptos o significados acerca de la ingeniería de requisitos que nos proporcionan varios autores según su nivel de experiencia, sentido común o simplemente por su forma de ver los requerimientos respecto al desarrollo de un determinado proyecto. En la ingeniería­ de requisitos principalmente se identifican dos aspectos muy importantes, el primero que es el propósito del sistema que se va a desarrollar y el segundo, el contexto en el que será usado. En base a estas características, se definen algunos conceptos como:

 

(i)     La ingeniería de requisitos o los requisitos en sí, constituyen el enlace entre las necesidades reales de los clientes, usuarios y otros participantes vinculados al sistema. La ingeniería de requisitos consiste en un conjunto de actividades y transformaciones que pretenden comprender las necesidades de un sistema software y convertir la declaración de estas necesidades en una descripción completa, precisa y documentada de los requerimientos del sistema siguiendo un determinado estándar.[1]

 

(ii)        La ingeniería de requisitos es un área de investigación que procura atacar un punto fundamental en el proceso, que es la definición de lo que se quiere producir.[2]

 

(iii)   Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Una representación documentada de una condición o capacidad de un sistema.[3]

 

La Ingeniería de Requerimientos en si cumple un papel primordial en el proceso de construcción y producción de un software, es decir que, estará basado en función de las necesidades planteadas por los clientes en un nivel muy general, donde se descubre, documenta, analiza y se define los servicios o componentes de lo que se desea producir, además de las restricciones que tendrá el producto o software. Su principal tarea consiste en la definición del proceso a seguir en la construcción de un software, y de facilitar la comprensión de lo que el cliente requiera. La obtención correcta de los requerimientos puede llegar a describir con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento de un sistema.

 

De tal manera que, basarse en la extracción de requisitos y sobre todo que sean correctos, lo único que se pretende en la construcción no solo de grandes sistemas software sino también simples, es la de minimizar los problemas relacionados al desarrollo de sistemas, claro está en proporción a la realidad de cada proyeto, con lo que se logra reducción de tiempo en la construcción, reducción de errores, y los más importante no solo para el cliente sino también para el desarrollador, evita gastar dinero más de lo planeado y determinado para el proyecto.


[1] José Manuel Márquez, Docente de la Universidad de Valladolid.

[2] Ing. Leidy Fernández Sánchez.

[3] IEEE.