Transformar el conocimiento tácito en explícito para que éste pueda ser expresado y transmitido es una labor que por sí misma otorga beneficios a la organización. Los ingenieros de software dentro de las PYMEs que día a día construyen diversas soluciones se rigen principalmente por su experiencia al ejecutar su trabajo. Sin embargo, el conocimiento creado y adquirido se queda en las personas lo que lo hace volátil al no perdurar en la organización. Por otra parte, cuando la organización adopta un modelo o estándar "conocido" para regir su manera de trabajo, corre el riesgo de perder sus prácticas "propias" a favor de las estandarizadas. Expresar la manera de cómo trabajas realmente, es el primer paso para transformar el conocimiento y hacerlo tangible. A través de KUALI-BEH, parte normativa del estándar ESSENCE, se define un marco de trabajo Bottom-Up dirigido a los ingenieros de software que les permitirá definir su propio método de trabajo, a partir de sus prácticas tácitas, para así sentar los fundamentos de la base de conocimiento práctico de la organización.

1. ¿Cómo potenciar el conocimiento
existente dentro de mi organización?
Presentan:
Hanna Oktaba y Miguel Morales

2. ¿A quiénes y para qué?
 ¿Cómo puedo expresar las prácticas exitosas de mi
organización con apoyo de KUALI-BEH?
 Contexto
 Organización de desarrollo de software
 Trabajando de manera constante y con buenos resultados
 Sin un proceso de desarrollo definido formalmente
 Objetivo
 Presentar el marco de trabajo KUALI-BEH que permita definir
la manera de trabajo de la organización de manera explícita.

3. El conocimiento
 La Ingeniería de Software es una disciplina de
conocimiento intensivo.
 La creación, recolección y transferencia del conocimiento
son procesos continuos.
 Gran parte de ese conocimiento existe en forma tácita y
depende completamente de los practicantes.
Es necesario definir un mecanismo que permita transformar el
conocimiento tácito existente en explícito.

4. Proyectos de software
 Su ejecución requiere de un equipo de trabajo.
 El equipo de trabajo aplica sus conocimientos y
habilidades.
 El trabajo realizado permite el cumplimiento del objetivo
establecido.
 Para lograr lo anterior, los equipos de trabajo siguen
procesos de desarrollo.

5. Concepción de KUALI-BEH

6. Concepción de KUALI-BEH

7. Concepción de KUALI-BEH

8. Autoría de prácticas
1. Identificar a la unidad de trabajo
2. Expresarla utilizando los conceptos de
la práctica de Kuali-beh
3. Acordar con el resto del equipo que lo
expresado representa el cómo se
trabaja
4. Ejecutar la práctica
5. Optimizarla y adaptarla de ser
necesario
6. Consolidarla como la manera de
trabajo

9. Conocimiento explícito
1.3
Práctica
Análisis de Requerimientos
Objetivo
Entender la funcionalidad de los requerimientos para poder proponer una solución.
Entrada Resultado
Lista de Requerimientos [Generada] Esquema del Sistema [Inicial]
Criterios de Verificación
El esquema del sistema que se generó cubre las necesidades esperadas por el cliente.
Guía
Actividad 1 Analizar la lista de requerimientos
Input Output
Lista de requerimientos Boceto del sistema
Tareas
(opcional)
Herramientas
(opcional)
Conocimientos y
Habilidades
Métricas
1.Definir la
navegación del
sistema
2.Definir las pantallas
del sistema
 Análisis
 Creatividad
Actividad 2 Diseñar Esquema del sistema
Input Output
Boceto del sistema Esquema del sistema [Inicial]
Tareas
(opcional)
Herramientas
(opcional)
Conocimientos y
Habilidades
Métricas
1.Cotejar el esquema
diseñado con la
lista de
requerimientos
 Edraw  Manejo de
Herramientas de
diseño

10. Autoría de métodos
1. Identificar la manera de trabajo
2. Integrar las prácticas que la
conforman
3. Comprobar el cumplimiento de las
propiedades del método
4. Ejecutar el método
5. Optimizarlo y adaptarlo de ser
necesario
6. Consolidarlo como la manera de
trabajo organizacional

11. Conocimiento explícito
Tic-Tac
Método
Tic-Tac KUALI-BEH
Propósito
Desarrollar módulos completos para conformar sistemas de software.
Entrada Resultado
Solicitud del Cliente
Datos Generales del Cliente
Formatos del Equipo
Manuales de Usuario
Manual Técnico
Trámites Administrativos
Sistema [Liberado]
Contrato de Satisfacción [Firmado]
Conjunto de Prácticas
Etapa 1
1.1 Recopilación de Información
1.2 Lista de Requerimientos
1.3 Análisis de Requerimientos
1.4 Modelo del Sistema
2.1Definición de funcionalidad de módulos
2.2Establecer Restricciones de los módulos
2.3Análisis del Entorno del Sistema
2.4 Plan de Desarrollo
Etapa 2
3.1 Diseño de Plantillas
3.2 Generación de Pantallas
3.3 Validación de pantallas
4.1 Jerarquización de Controles
4.2 Identificación de Fuentes de Datos
4.3 Identificación de Código Reusable
4.4 Codificación de Pantallas
4.5 Verificación General de Controles
Etapa 3
5.1 Diseño de Pruebas
5.2 Ejecución de Pruebas
5.3 Análisis y Corrección de Defectos
6.1 Definir la Estrategia de Migración
6.2 Producir Estrategia de Migración
Etapa 4
7.1 Liberación del Sistema
7.2 Documento de liberación del sistema
IB
Método
Desarrollo KUALI-BEH
Propósito
Lograr un desarrollo estructurado, sólido y coherente tanto para los objetivos del cliente como para los de
la organización, garantizando con ello una eficiencia en las tareas del proceso de desarrollo y
permitiendo una mayor versatilidad en los ajustes o tareas que se presenten no solo para los
involucrados directamente sino para todos aquellos que sigan la metodología.
Entrada Resultado
Repositorio de Proyectos
Documento que contenga el proceso a detalle del
requerimiento a sistematizar. Debe contener una
descripción de todos los Roles participantes, así
como al menos un ejemplo de los documentos o
formatos que intervienen en el proceso. (DS)
Versionamiento de código e instaladores.
Código fuente definitivo.
Ejecutables o instalador definitivos.
Carpeta Final del Proyecto.
Conjunto de Prácticas
PR-01 Análisis del problema
PR-02 Elección de la plataforma de desarrollo
PR-03 Diseño del repositorio de datos
PR-04 Distribución de funciones
PR-05 Diseño primera interfaz de usuario
PR-06 Construcción del repositorio de datos
PR-07 Definición de componentes a codificar
PR-08 Priorizar módulos
PR-09 Buscar código reutilizable
PR-10 Codificar componentes
PR-11 Pruebas
PR-12 Documentación
PR-13 Corrección de bugs

12. “Trabajamos bien, pero queremos
saber exactamente qué hacemos.”
 Empresa mexicana, 4
participantes
 Definición de su propia
manera de trabajo
 Programadores con
experiencia
 Directivos comprometidos

13. Beneficios
 Se tiene claridad sobre cómo trabaja el equipo, y
todo fue definido por ellos mismos.
 Pone orden en el desorden.
 El valor del experimento recae en los propios
practicantes.
 Se revaloraron varios aspectos y cosas que son
importantes.

14. Especificación de requerimientos
a través de juegos

15. Beneficios
 Reconocimiento de lo novedoso y eficiente que resultó
el método.
 Interés de investigadores extranjeros en una innovación
mexicana.
 Replicación del método en otras sedes de la empresa.
 El diseño del proyecto hoy en día es ofrecido como un
producto de la empresa.

16. Método definido por una célula
de desarrollo de software
 Equipo de trabajo formado por recién egresados.
 Reducción en el tiempo de capacitación.
 Participación activa de estudiantes y profesores.

17. Beneficios
 Podremos plantearnos cómo distribuir el método entre
los miembros de la organización para obtener mejoras y
unificación de la manera de trabajo.
 El tener definido un método que pertenece a la
organización permitirá instruir y capacitar de manera
interna a las personas de nuevo ingreso.
 Con tres niveles, método-práctica-actividad, es
suficiente para controlar el trabajo realizado en los
proyectos de la organización.

18. “La organización no contaba con la
documentación del desarrollo.”
1. Identificación de los métodos y prácticas.
2. Expresión de los métodos y prácticas.
3. Aplicación de los métodos y prácticas.
4. Definición de los productos de trabajo.
5. Validación de los métodos y prácticas.
 Obtener un método apegado a las actividades reales y
recurrentes que se llevan a cabo en la organización para
la producción de software.

19. Método de métodos

20. Beneficios
 Se logró documentar de manera ordenada a un proyecto
que dada su magnitud resultaba muy complicado de
comprender y controlar.
 A través de las prácticas de exploración expresamos
aquellas maneras de trabajo que se realizaban por
primera vez.
 Creamos un método organizacional para desarrollar
sistemas.
 Unificamos los productos de trabajo, lo que permitió
establecer plantillas genéricas para cada uno.

21. Esfuerzo requerido
 Entendimiento de KUALI-BEH por parte de los practicantes
 Una sesión de 60 minutos
 Descripción de la primera práctica
 De 60 a 120 minutos
 Esfuerzo total para la autoría de prácticas
 10, 26 y 44 horas respectivamente
 Promedio de esfuerzo por práctica
 46, 82 y 114 minutos respectivamente

22. Herramienta KUALIBS

23. Tu también puedes definir tus
prácticas
 ¿Por qué lo hago? ¿qué debería lograr con este trabajo?
 Objetivo de la práctica
 ¿Qué necesito para empezar?
 Entradas – productos de trabajo o condiciones
 ¿Qué voy a generar/producir?
 Salidas – productos de trabajo o condiciones
 ¿Cómo sé si concluí el trabajo de manera satisfactoria?
 Criterios de verificación
 ¿Qué hago primero? ¿y después?
 Guía – actividades y tareas
 ¿Con qué herramientas?
 Listado de herramientas
 ¿Es importante medir? ¿qué debo medir?
 Listado de métricas

24. ¿Quieres intentarlo?
 Puedes conocer más acerca del marco de trabajo
consultando el Anexo normativo B del estándar ESSENCE
– Kernel and Language for Software Engineering Methods
 http://www.omg.org/spec/Essence/1.0/
 Si quieres probar este marco de trabajo contáctanos!

25. @hannaoktaba
Hanna Oktaba y Miguel Morales
hanna.oktaba@ciencias.unam.mx
migmor@ciencias.unam.mx
http://kualikaans.fciencias.unam.mx