Capítulo 11

GESTIN DEL CONOCIMIENTO
PORTADA
GESTIN DEL
CONOCIMIENTO
INTRODUCCIN
- INTRODUCCIN - INGENIERA DEL SOFTWARE
- FBRICA DE EXPERIENCIAS
- FAMILIAS DE ESTUDIOS - CONCLUSIONES
INTRODUCCIN
INTRODUCCIN
NECESIDADES ORGANIZACIONALES
(Basili et al., 2001)
- Comprender
los procesos y productos
- Evaluar los xitos y fracasos - Aprender de las experiencias - Empaquetar experiencias exitosas - Reutilizar experiencias exitosas
INTRODUCCIN
- Experiencia perdida
- Un empleado se va y la organizacin pierde toda su experiencia y ni siquiera sabe la experiencia que ha perdido - Un empleado aprende mucho en un proyecto, pero no tiene tiempo de empaquetar y difundir su conocimiento - Un jefe de proyecto infravalora de nuevo el tiempo que requiere el desarrollo de un producto porque no dispone de datos recogidos de proyectos anteriores
INTRODUCCIN
- Experiencia redescubierta
- Un consultor invierte tres semanas en desarrollar un curso que ya existe porque no sabe que ya ha sido preparado
- Alguien repite un error de 35.000 euros para el cual existe una fcil solucin
INTRODUCCIN
- Desarrollo del negocio

- Un consultor hace una promesa a un cliente, pero ahora est ocupado con otro trabajo y nadie cumple la promesa porque nadie sabe nada acerca de la misma
- Desarrollo
del personal
- Se contrata un nuevo empleado pero se le considera una carga por mucho tiempo ya que necesita ayuda detallada de sus compaeros - Se rechaza una peticin de un empleado para asistir a un curso, ya que sera demasiado valioso en el mercado
FBRICA DE EXPERIENCIA
Arquitectura de Gestin de Conocimiento

(Lawton, 2001)
INTRODUCCIN
- INTRODUCCIN
- INGENIERA DEL SOFTWARE
ING. SOFTWARE
INGENIERA DEL SOFTWARE

(Lindvall y Rus, 2003)
producir mejor software, de una forma ms rpida y econmica, as como tomar mejores decisiones - Localizacin de fuentes de conocimiento - Reutilizacin de experiencias - Mejorar los procesos de desarrollo del software - Reutilizacin de artefactos del proceso de desarrollo
ING. SOFTWARE
Actividades generales de KM aplicables a IS

- reutilizacin de activos - gestin de documentacin - colaboracin - gestin de competencias
- redes de expertos
ING. SOFTWARE
KM en organizaciones software
- gestin de configuracin y control de versiones - design rationale - trazabilidad - informe de problemas y trazabilidad de defectos
- herramientas CASE y entornos de desarrollo de software

PROCESOS PRINCIPALES
ADQUISICIN SUMINISTRO DESARROLLO EXPLOTACIN MANTENIMIENTO
ING. SOFTWARE
PROCESOS DE SOPORTE
DOCUMENTACIN GESTIN DE CONFIGURACIN ASEGURAMIENTO DE CALIDAD VERIFICACIN VALIDACIN REVISIN CONJUNTA AUDITORA RESOLUCIN DE PROBLEMAS USABILIDAD EVALUACIN DE PRODUCTO
PROC. ORGANIZACIONALES
GESTIN INFRAESTRUCTURA MEJORA RECURSOS HUMANOS GESTIN DE ACTIVOS GEST. PROG. REUTILIZACIN INGENIERA DE DOMINIO
PROCESO DE ADAPTACIN
ING. SOFTWARE
PROCESOS ORGANIZACIONALES
Proceso de gestin Este proceso persigue organizar, monitorizar, y controlar el inicio y el desempeo de cualquier proceso para conseguir sus objetivos de acuerdo a los objetivos de negocio de la organizacin.
Proceso de mejora Este proceso sirve para establecer, evaluar, medir, control y mejorar los procesos del ciclo de vida del software. Se compone de tres subprocesos: establecimiento de procesos, evaluacin de procesos y mejora de procesos
ING. SOFTWARE
Proceso de infraestructura Este proceso permite mantener una infraestructura fiable y estable necesaria para soportar el desempeo de los otros procesos. Esta infraestructura puede incluir hardware, software, mtodos, herramientas, tcnicas, estndares y facilidades para el desarrollo, operacin o mantenimiento. Proceso de recursos humanos Este proceso sirve para proporcionar a la organizacin los recursos humanos adecuados y mantener su competencia, consistente con las necesidades de la empresa. Este proceso incluye tres subprocesos: Gestin de Recursos Humanos, Formacin y Gestin del Conocimiento.
ING. SOFTWARE
Proceso de gestin de activos Este proceso sirve para gestionar la vida de los activos reutilizables desde su concepcin hasta su retirada. Proceso de gestin del programa de reutilizacin Este proceso sirve para planificar, gestionar, controlar y monitorizar el programa de reutilizacin de una organizacin y explotar de forma sistemtica las oportunidades de reutilizacin. Proceso de ingeniera de dominio Este proceso sirve para desarrollar y mantener modelos de dominio, arquitecturas de dominio y activos para el dominio.
ING. SOFTWARE
Subproceso de gestin del conocimiento
Propsito: asegurar que el conocimiento, la informacin y las habilidades individuales se recogen, comparten, reutilizan y mejoran a lo largo de la organizacin.
Resultados: - se establece y mantiene una infraestructura para la comparticin de la informacin comn y de dominio a travs de la organizacin - el conocimiento se encuentra disponible readily y compartido a lo largo de la organizacin - la organizacin seleccionar la estrategia de gestin del conocimiento apropiada.
ING. SOFTWARE
Tareas relativas a la gestin del conocimiento
- el director planificar los requisitos para gestionar los activos de conocimiento de la organizacin, incluyendo la infraestructura y la formacin para soportar los contribuidores y los usuarios de los activos de conocimiento de la organizacin, el esquema de clasificacin y los criterios para estos activos. - el director establecer una red de expertos dentro de la organizacin y se asegurar que se mantiene actualizada. - el director establecer un mecanismo para soportar el intercambio de informacin entre expertos y el flujo de la informacin de los expertos en los proyectos de la organizacin. - se llevar a cabo la gestin de configuracin de los activos de acuerdo con el proceso de gestin de configuracin.
ING. SOFTWARE
TCNICAS
- modelos de prediccin
- lecciones aprendidas, patrones, y mejores prcticas

- sistemas basados en casos - descubrimiento de conocimiento - Redes externas como Software Process Improvement Network (SPIN) o los grupos de inters especiales de IEEE o ACM. - Oracle Support Center
- Estndares de ISO, IEEE, etc.
ING. SOFTWARE
CARACTERIZACIN DEL CONOCIMIENTO EN DISEO DE MICRO ARQUITECTURAS OO

(Garzs y Piattini, 2005)
Malos Olores.
Principios. Defectos.
Patrones.
Refactorizaciones. Heursticas. Buenas Prcticas.
ING. SOFTWARE
SITUACIN
Los componentes del conocimiento en OOD son difusos, poco definidos, ambiguos
IMPACTO
Apenas existen catlogos para elementos que no sean los patrones

Los catlogos existentes, son complejos de aplicar y todos distintos Apenas existen mtodos para el uso del conocimiento, que lo relacionen, midan, etc. Respecto al conocimiento, es complejo saber qu, cundo, cmo, dnde y efecto
El conocimiento y experiencia prctica en OOD apenas se usa y apenas se conoce
En los proyectos se siguen repitiendo los mismos problemas de diseo, resueltos hace tiempo, implicando costes
ING. SOFTWARE
Conocimiento en Diseo de Micro Arquitecturas OO nombre propsito tambin conocido como motivacin aplicabilidad participantes colaboracin consecuencias diseo de ejemplo usos conocidos
est compuesto de
Declarativo
0..n
0..n Operativo
1..n
implica utilizar
0..n 0..n 0..n Patrn estructura 0..n 0..n
cumple
Regla 0..n recomendacin 0..n 0..n

es introducido por
Refactorizacin mecnica
implica utilizar
{ una, otra o las dos, pero siempre alguna}
es introducido por
ING. SOFTWARE
ING. SOFTWARE
TCNICAS
- modelos de prediccin
- lecciones aprendidas, patrones, y mejores prcticas

- sistemas basados en casos - descubrimiento de conocimiento - Redes externas como Software Process Improvement Network (SPIN) o los grupos de inters especiales de IEEE o ACM. - Oracle Support Services
- Estndares de ISO, IEEE, etc.
ING. SOFTWARE
ING. SOFTWARE
ING. SOFTWARE

SWG 5 Architecture Management Secretariat
ING. SOFTWARE
SWG 1 Business Planning Group
SC7
WG20 Software Engineering Body of Knowledge WG22 Vocabulary
WG19 ODP and Modeling Languages WG4 Tools And Environment
WG7 Life Cycle Management WG10 Process Assessment WG21 Asset Management WG23 Systems Quality Management
WG2 System Software Documentation WG6 Software Product Measurement and Evaluation WG12 Functional Size Measurement WG9 System Assurance
ING. SOFTWARE
Product
Product packaging
Systems Engineering
15288 Foundation 19759

Software Body of Knowledge (SWEBOK)
Process Implementation and Assessment

Process Assessment
9127
Documentation
19760
Software Engineering
15289
Product Evaluation
12182
Vocabulary
1550 4
Software Quality
12207 1527 1 90003
12119
9126 14598 14756

Software Functional size measurement
3535 14759
SC7s legacy
6592 9294 15910 18019

Documentation
15846
Configuration Management
16085 15026
Risk & Integrity
19770
Asset Management
14764
Software maintenance
16326
Project Management
15939
Measurement
14143 19761 20926 20968 24570
Tools, Methods
5806 5807 6593 8631 8790 11411
SC7 Legacy Standards
14102 14471 15940 18018

Tools and environment
10746, 13235 14750, 14752 14753, 14769 14771, 15414 15935, 19500
Specifications
14568 15474 15475 15476

CDIF
15437 15909 19501 8807

Modeling
ING. SOFTWARE
ING. SOFTWARE
ING. SOFTWARE
INTRODUCCIN
QIP (Quality Improvement Paradigm)

(Basili y Caldiera, 1995)
- Es un proceso soportado por una aproximacin dirigida por objetivos a la medicin y control, y por una infraestructura organizativa denominada factora de experiencia
QIP (Quality Improvement Paradigm)

(Basili y Caldiera, 1995)
Una Base de Experiencia debe: - Contener el conocimiento relevante para la organizacin - Residir en un marco de aprendizaje bien concebido - Disponer de metodologas que establezcan como se estructura la experiencia - Disponer de procesos, procedimientos y reglas que establezcan como se gestiona la experiencia diariamente - Estar automatizada lo mximo posible
Sistema de Gestin de Experiencias

- Caracterizar la organizacin e identificar los procesos y
conocimientos actuales - Identificar los usuarios y definir roles de usuario - Desarrollar casos de uso - Definir tipos de paquetes (taxonomas) - Generar los atributos que describen los tipos de paquete - Definir valores aceptables para cada atributo - Definir un documentos de requisitos para el SGE - Construir, integrar e instalar el SGE - Evaluar y hacer evolucionar el SGE
Conocimiento documentado
- Artculos - Propuestas - Presentaciones - Polticas de la organizacin
Fcil
Conocimiento explcito no documentado

- Informacin de proyectos - Informacin de clientes - Polticas de la organizacin - Experiencia de los empleados - Procedimientos para las reuniones - Procedimientos para la contratacin - Mejores prcticas para propuestas
Posible
Conocimiento tcito no documentado

- Mejores prcticas para proyectos - Mejores prcticas para atencin a clientes
Difcil
Beneficios para la organizacin

- establecer un proceso de mejora de software sustentado y controlado por datos cuantitativos
- producir un repositorio de datos y modelos software que estn basados empricamente en la prctica diaria - desarrollar una organizacin de soporte interno que limite la sobrecarga y proporcione beneficios sustanciales de desempeo de coste y calidad - proporcionar un mecanismo para identificar, valorar, e incorporar en los procesos nuevas tecnologas que hayan demostrado ser valiosas en contextos similares - incorporar y soportar la reutilizacin en el proceso de desarrollo de software
Aspectos de calidad de un repositorio

Schneider y von Hunnius (2003)
- gua al usuario, sobre todo para empezar reutilizando las experiencias - usabilidad, ya que una pobre usabilidad puede scare away al usuario - conformidad con el proceso, hacer de un proceso mejorado el centro del repositorio de experiencias, siguiendo la estructura del proceso subyacente
- mecanismos de realimentacin, pro medio de diferentes canales (correo electrnico, pizarras electrnicas, FAQ, contactos personales y telefnicos, etc.)
- mantenibilidad, para que las reestructuraciones sean fciles
Modelo dinmico de creacin de conocimiento de ingeniera del software.

Dyb (2003)
C O N T E X T O O R G A N I Z A C I O N A L GENERACIN CONOCIMIENTO MEMORIA ORGANIZACIONAL D E S E M P E O INTERPRETACIN CONOCIMIENTO O R G A N I Z A C I O N A L
FACTORES FACILITADORES
CONOCIMIENTO LOCAL
FACTORES FACILITADORES
CONOC. LOCAL
GENERACIN CONOC.
MEMORIA ORGANIZ.
INTERPRET. CONOC.
Orientacin al negocio
Implicacin de los lderes
X
X XX
XX
X
Participacin de los empleados

Preocupacin por la medicin
XX
XX
XX
X
XX
Explotacin del conoc. existente

Exploracin de nuevo conoc.
X
XX
XX
X
XX
Modelo SEKS (Software Eng.Knowledge-Sharing)

Oliver et al. (2003)
OPORTUNIDAD DE APRENDER CULTURA SUPPORTIVE (NIVEL ORG. E INDIVIDUAL)
DESEO DE APRENDER
MOTIVACIN PARA DESCUBRIR CONOCIMIENTO
COMPARTICIN DEL CONOCIMIENTO EN INGENIERA DEL SOFTWARE
EXPERIENCIA PREVIA
Mejora de 1991 -1995
INTRODUCCIN
FAMILIAS DE ESTUDIOS
(BASILI ET AL., 2001)
Criterios para la construccin de cuerpos de conocimiento en reas de Ingeniera del Software:

1. Fijar hiptesis de alto nivel que sean de inters para la comunidad de Ingeniera del Software 2. Hiptesis detalladas escritas en un contexto que permitan un experimento bien definido 3. Variables de contexto, sugeridas por las hiptesis, que puedan modificarse para permitir variaciones en el diseo experimental 4. Una cantidad suficiente de informacin para que el experimento pueda ser replicado 5. Una comunidad de investigadores que comprendan la experimentacin, la necesidad de rplica y que estn dispuestos a colaborar y replicar
Kish (1959) divide las investigaciones empricas en:
Encuestas son investigaciones en las que los sujetos del estudio son una muestra representativa de la poblacin a la que pertenecen.
Casos de estudio son aquellos en los que no hay aleatoriedad de variables perturbadoras ni representatividad de los sujetos que componen la muestra de estudio.
Experimentos son las investigaciones en las que las posibles variables perturbadoras han sido aleatorizadas.
Factor Control de la ejecucin Control de la medicin Coste de la investigacin Facilidad de rplica
Encuesta NO NO BAJO ALTO
Caso de estudio NO SI MEDIO BAJO
Experimento SI SI ALTO ALTO
La experimentacin provee una manera sistemtica, disciplinada, cuantificable y controlada de evaluar actividades desarrolladas por humanos.
Wohlin et al. (2000)
Experimento Factores (tratamientos)
Variables independientes
Diseo del experimento
Variable dependiente
.....
.....
Proceso
Variables controladas
Variables dependientes (response, predictor)

variables que queremos estudiar para ver el efecto de los cambios en las variables independientes
Variables independientes (factor, state, predictand)
variables cuyos valores son cambiados para estudiar su efecto
Variables controladas (controlled)
variables independientes que son controladas en un nivel fijo
Variables enmascaradas (confounded)

variables no controladas que varan simultneamente con las variables independientes
Variables aleatorias (randomized)
Variables no controladas que se tratan como un error aleatorio.
Tratamientos
un determinado valor para un factor
Objetos
procesos, productos, recursos
Sujetos
Personas que aplican los tratamientos a los objetos
Experimento
consiste en una serie tests (llamados trials) donde cada test es una combinacin de tratamientoobjeto-sujeto
Evaluar el efecto de un nuevo mtodo de desarrollo en la productividad del personal: mtodo orientado a objetos en lugar de un mtodo estructurado
Variable dependiente: productividad Variable independiente: mtodo de desarrollo Otras variables independientes: experiencia, ambiente, tipo de producto. Utilizamos dos tratamientos del factor: mtodo viejo y nuevo Objetos: programas que deben ser desarrollados Sujetos: el personal de desarrollo Test: la persona N (sujeto) usa un nuevo mtodo de desarrollo (tratamiento) para desarrollar un programa A (objeto)
Proceso Experimental
(Wohlin et al., 2000)
Idea
Objetivos
Planificacin Planificacin
Diseo del experimento
Definicin Definicin Anlisis e e Anlisis Interpretacin Interpretacin
Operacin Operacin
Datos Estudio Estudio piloto piloto
Presentacin Presentacin Amenazas Amenazas y Difusin Difusin y Conclusiones
DEFINICIN
La plantilla GQM para definicin de objetivos: Mtodo orientado a objetos y estructurado Analizar <Objeto(s) de estudio>
(qu es lo que se estudia?)
Evaluar con el propsito de <Propsito>
(cul es la intencin?)
Productividad con respecto a <Enfoque de calidad>
(cul es el efecto estudiado?)
desde el punto de vista del Investigador <Perspectiva>

(a la vista de quin?)
en el contexto de <Contexto> Estudiantes de grado y postgrado

(dnde se lleva a cabo el estudio?)
Objeto de estudio Producto Proceso Modelo Mtrica Teora
Enfoque de Propsito calidad Caracterizar Efectividad Supervisar Costo Evaluar Fiabilidad Predecir Mantenibilidad Controlar Portabilidad Cambiar
Perspectiva Contexto Desarrollador Sujetos Mantenedor Objetos Director de proyectos Cliente Usuario Investigador
Off-line vs. On-line
Evitar riesgos Incrementa costes Reducir costes Facilitar el control Generalizacin? Reduce costes y tiempo Generalizacin? Reduce costes y tiempo Generalizacin?
Estudiantes vs. profesionales Problemas de jueguete vs. problemas reales Especficos vs. generales
Evaluacin de la validez
? Validez de constructo
Hasta qu punto las medidas seleccionadas miden las variables que aparecen en la hiptesis?
? Validez de las conclusiones

Hasta qu punto las conclusiones son estad sticamente vlidas?
? Validez interna
Causa realmente el tratamiento el efecto?
? Validez externa
Pueden generalizarse los resutados obtenidos?
Es necesario realizar una familia de experimentos para: Construir un cuerpo de conocimiento adecuado que nos permita extraer conclusiones tiles sobre algn tema en la ingeniera de software (Basili et al., 1999). Para integrar los resultados y extrapolar ese conocimiento
Varios estudios complementarios permiten obtener conclusiones ms robustas cuando cada uno de ellos trata de atacar los puntos dbiles del otro (Shull et al., 2002)
Es importante lograr la fiabilidad de un experimento mediante su replicacin (Brooks, et al., 1996): Rplicas internas: experimentos repetidos por los mismos investigadores que llevaron a cabo el original Rplicas externas: experimentos que son realizados por otros experimentadores, que no tiene nada que ver con los originales
Segn Basili et al. (1999), los tipos de rplicas se agrupan en tres categoras: 1. Rplicas que no hacen variar ninguna de las hiptesis de la investigacin.
1.1. Rplicas estrictas, que tratan de duplicar el experimento 1.2. Rplicas que varan la forma en que se ejecuta el experimento.
2. Rplicas que varan las hiptesis de la investigacin

2.1. Rplicas que modifican las variables independientes. 2.2. Rplicas que varan las variables dependientes. 2.3. Rplicas que modifican las variables de contexto en el entorno en que se evalu la solucin.
3. Rplicas que amplan la teora
Es necesario contar con laboratory packages

(Basili et al., 1999; Shull et al.; 2002; Ciolkowski et al., 2002)
Los laboratory packages se disean especficamente para dar soporte a la replicacin externa, pero tambin son valiosos para las rplicas internas Los laboratory packages deben contener el material relacionado con:

El anlisis y objetivos del experimento La motivacin a la hora de realizar las decisiones claves del diseo, etc. El diseo experimental, incluyendo las amenazas a la validez y los puntos fuertes del experimento El contexto en el cual se llev a cabo el experimento El proceso para ejecutar el experimento Los mtodos utilizados durante el anlisis de los datos empricos
Existe otro problema que Shull et al. (2002) llamaron conocimiento tcito, que afecta a la conformidad del proceso y, por tanto, a la posibilidad de comparar los resultados entre rplicas. Por lo tanto para que las rplicas sean efectivas se necesitan no slo los laboratory packages, sino tambin: Un proceso para la replicacin que involucre a los experimentadores originales para dar soporte a su instanciacin, evolucin y uso. Contar con una estructura colaborativa efectiva entre los experimentadores originales y los que realizarn la rplica para trasmitir el conocimiento tcito que es necesario para lograr la conformidad del proceso.
Central Research Institute of Electric Power Industry Contact: Mitsuhiro Takahashi Japan Daimler-Chrysler Research Center; Germany Contact: Frank Houdek Lucent Technologies - Bell Laboratories; USA Contact: Audris Mockus National Space Development Agency of Japan Contact: Masafumi Katahira SINTEF, Norway Contact: Tore Dyb Norway SUN Microsystems, USA Contact: Larry Votta VTT Electronics; Finland Contact: Seija
BTH Contact: Claes Wohlin Blekinge Institute of Technology Sweden Carleton University Contact: Lionel Briand Canada University of Castilla-La Mancha, Spain Contact: Mario Piattini Spain University of Maryland at College Park; USA Contact: Victor R. Basili USA University of Kaiserslautern; Germany Contact: H. Dieter Rombach Germany University of New South Wales; Australia Contact: Ross Jeffery
Grupo Alarcos
- Mtricas para modelos lgicos de BD - Mtricas para modelos conceptuales de BD - Mtricas para modelos UML
- Casos de uso - Modelos de clase - Diagramas de transicin de estados - Expresiones OCL
- Mtricas para almacenes de datos - Mtricas para modelos de proceso software
1. DEFINITION
Analyse UML class diagrams complexity metrics Evaluating The capability to be used as early quality indicators OOIS designers Undergraduate students and professors of the Software Engineering Area in the Department of Computer Science in the UCLM
For the purpose of With respect to

From the point of view of In the context of
2. PLANNING
Context selection
The experiment run off-line (not industrial software development) The subjects were 10 professors and 20 students enrolled in the final-year of Computer Science at the Department of Computer Science at the UCLM
Selection of subjects
The subjects are chosen for convenience
Variables selection The independent variable is the UML class diagram structural complexity The dependent variable is the UML class diagram maintainability Instrumentation The objects were UML class diagrams The independent variable was measured through the metrics The dependent variable was measured by the time spent doing the experiment, the maintenance time
Hypotheses formulation
Null hypothesis, H0: There is not a significant correlation between the structural complexity metrics we proposed and the maintenance time Alternative hypothesis, H1: There is a significant correlation between the structural complexity metrics we proposed and the maintenance time Experiment design
A within-subject design
3. OPERATION Preparation The material consists of nine UML class diagrams of different application domains The diagrams have different complexity, considering a broad range of metrics values
Each subject has to modify the class diagrams according to the new requirements and to write down the time spent in performing those modifications (maintenance time)
Execution
The subjects were given all the material. We explained to them how to carry out the experiment We allowed one week to do the experiment We collected all the empirical data Data Validation
We checked if the tests were complete and if the modifications were done correctly We discarded the test of seven subjects, because they included a required modification that was done incorrectly
4. ANALYSIS AND INTERPRETATION Our goal is to ascertain if any correlation exists between each of the proposed metrics and the maintenance time
For analysing the empirical data we used three techniques: Statistical techniques Fuzzy classification and regression trees (Linares et al., 1996) Fuzzy prototypical knowledge discovery (Olivas, 2000)
5. VALIDITY EVALUATION Threats to conclusion validity

The only issue that could affect the statistical validity of this study are the size of the sample data (243 values, 9 diagrams and 27 subjects)
Threats to construct validity

The dependent variable we used is the maintenance time, so we consider this variable constructively valid The construct validity of the measures used for the independent variables is guaranteed by Poels and Dedenes framework (Poels and Dedene, 1999; 2000a) used to validate them
Threats to internal validity

Differences among subjects Knowledge of the universe of discourse Precision in time values Learning effects Fatigue effects Persistence effects Subject motivation Other factors
Threats to external validity

Materials and tasks used Subjects
EXPERIMENT CONCLUSIONS
NC, NA, NM, NAssoc, NAgg, NDep, NGen, NAggH, NGenH, MaxHAgg, MaxDIT are to some extent correlated with maintenance time
VALIDACIN EMPRICA: Experimento Relacional
Hiptesis
Hiptesis nula: Diferentes valores de las mtricas no afectan a la entendibilidad del esquema de la base de datos. Hiptesis alternativa 1: El valor de DRT afecta a la entendibilidad del esquema de la base de datos. Hiptesis alternativa 2: El valor de NFK afecta a la entendibilidad del esquema de la base de datos. Hiptesis alternativa 3: La combinacin de valores de DRT y NFK afecta a la entendibilidad del esquema de la base de datos.
Sujetos Alumnos de la E.S. Informtica de la Universidad de Castilla-La Mancha que cursaban una asignatura anual de bases de datos. Fue realizado por 60 alumnos, slo 59 fueron finalmente aceptados. Materiales del experimento La documentacin entregada a cada sujeto constaba de:
los esquemas de las bases de datos las tablas con su contenido la hoja de preguntas y respuestas
.
Se realizaron 4 tests diferentes con distintos valores para las mtricas Material: esquema de la BD, tablas, hoja de preguntas y respuestas Ejercicios: insercin, eliminacin y modificacin de la BD
Qu tablas y cuantas columnas por tabla se vern afectadas si borramos de la tabla 5
la columna con cod1=210? Tabla 1 Tabla 2 abla 3 Tabla 4 Tabla 5 Tabla 6
Qu tablas y cuantas columnas por tabla se vern afectadas si modificsemos la columna X de la fila con X=11 en la tabla 3?
Tabla 1
Tabla 2
Tabla 3
Tabla 4
Tabla 5
Tabla 6
Cuntas filas, de que tablas y cuantas columnas por tabla habra que modificar si
quisiramos aadir una nueva fila (con todos los datos nuevos en la base de datos) a la tabla 6? Tabla 1 Tabla 2 Tabla 3 Tabla 4 Tabla 5 Tabla 6
Factor B (NFK)
LOW HIGH
F a c t o r A
LOW
2,5
2,8
(DRT)
HIGH 5,5 5,8
Variables Independientes
Las variables independientes son DRT y NFK. Cada una de estas variables tiene dos niveles que son dos y cinco para DRT y cinco y ocho para NFK.
Variables Dependientes
Se calcula como el nmero de respuestas correctamente respondidas por cada sujeto en cada test. Dimos a los sujetos diez minutos por test evaluando despus el nmero de respuestas correctas obtenidas en ese intervalo de tiempo. El estudio se centr en el nmero de respuestas correctas obtenidas para cada test. nicamente se descart un test por estar en blanco.
Variables controladas
Intentamos minimizar la variabilidad entre sujetos escogindolos a todos del mismo curso y con los mismos conocimientos sobre bases de datos Los efectos de variables irrelevantes fueron minimizados haciendo los mismos tests a todos los participantes durante el mismo tiempo El orden de ejecucin de los cuatro tests vari de unos sujetos a otros para contrarrestrar los efectos producidos por el aprendizaje. Igualmente se hizo que cada uno de los cuatro test trabajara con el mismo nmero de tablas aunque se modificara el valor de las mtricas.
Procedimiento
Los tests se realizaron consecutivamente en el transcurso de una hora de clase. Antes de comenzar, fue explicado a los sujetos: tipo de ejercicios que deban realizar, material que se les iba a entregar, tipo de respuestas que deban dar y tiempo que tenan para realizar cada test del experimento. A cada sujeto se le entreg la documentacin completa para los cuatro tests Al finalizar el tiempo asignado a cada test, se inform a los sujetos que, inmediatamente, dejaban de trabajar en el test que estuvieran y pasaban al siguiente.
Resultados
Fuente de variacin DRT NFK Interaccin Error Total Grados de Libertad F-Ratio 1 1 1 1 232 1.67 2.84 48.1
F1,232=2.73
VALIDACIN EMPRICA: Rplica Relacional
Sujetos
Profesionales de una empresa espaola con una experiencia media de tres aos en el campo de las bases de datos. Once personas desarrollaron el experimento siendo todos ellos vlidos.
Variables Dependientes Considerando la amplia experiencia en bases de datos relacionales de los sujetos que iban a desarrollar el experimento, se decidi calcularla en funcin del tiempo necesario para realizar cada uno de los cuatro tests. De esta forma, los tests fueron tomados como vlidos siempre y cuando estuvieran completados. El estudio, por lo tanto, se centr en los tiempos obtenidos para cada test.
Procedimiento
Los tests se realizaron consecutivamente en el transcurso de una hora. Antes de comenzar, fue explicado a los sujetos, el tipo de ejercicios a realizar, el material que se les iba a entregar, y el tipo de respuestas a dar y cmo deban anotar el tiempo que invertan en resolver cada uno de los cuatro tests. Antes de comenzar a estudiar cada caso, los sujetos deban anotar la hora de comienzo; al finalizar los ejercicios correspondientes a un test, los sujetos tenan que anotar la hora de finalizacin. De esta forma, cuando un sujeto terminaba un test, poda pasar al siguiente sin necesidad de esperar al resto de compaeros.
Resultados
Fuente de variacin DRT NFK Interaccin Error Total Grados de Libertad 1 1 1 1 40 F-Ratio
5.98 6.47 0.469
F1,40=2.84
De ambos experimentos se deduce que la mtrica NFK parece ser un indicador slido de la entendibilidad del esquema mientras que resulta ms complicado obtener una conclusin para la mtrica DRT
Validez de constructo
Decidi medirse la entendibilidad de forma distinta la primera vez que para la rplica (nro de respuestas correctas dadas vs tiempo para determinar el estado final de la base de datostiempo de anlisis de la base de datos junto al tiempo de ejecucin) debido a la experiencia de los sujetos de la rplica. Sera conveniente hacer ms experimentos, variando las operaciones a realizar en la base de datos.
Validez interna
Diferencias entre los esquemas. Seis tablas con ms o menos claves ajenas. Dominio de los esquemas diferente. Esto pudo influir en los resultados obtenidos. Precisin de los valores del tiempo. En la rplica del experimento, era responsabilidad de los sujetos anotar los tiempos de comienzo y fin de cada test. Este procedimiento puede producir que algn sujeto introduzca alguna imprecisin. Efectos de aprendizaje. Los tests de cada experimento fueron colocados en distinto orden.
Validez interna
Efectos de fatiga. Tiempo medio de una hora por lo que estos efectos son, prcticamente, inexistentes. Adems, la diferencia en el orden ayuda a evitar este efecto. Efectos de persistencia. El segundo experimento se llev a cabo con un nuevo conjunto de sujetos. Motivacin de los sujetos. Alta en el caso de los alumnos ya que se realizaron ejercicios similares en el examen. En el caso de los profesionales, la motivacin poda ser menor. Otros factores. El plagio y la influencia entre los sujetos fueron controlados.
Validez externa
Materiales y tareas utilizados. Intentamos utilizar esquemas y operaciones representativos de casos reales aunque sera interesante realizar ms experimentos con bases de datos relacionales de mayor tamao y complejidad. Sujetos. Debido a la dificultad de conseguir profesionales, el experimento se realiz la primera vez con estudiantes. En este caso, las tareas a realizar no requeran de gran experiencia por lo que los resultados obtenidos con los estudiantes pueden ser considerados correctos (Basili et al., 1999).
Validez externa
En general, seran necesarios nuevos experimentos con un mayor nmero de sujetos, tanto con estudiantes como con profesionales y con una mayor diferencia entre los valores que toman las mtricas para poder concluir si la integridad referencial afecta o no a la entendibilidad de las bases de datos relacionales y, por tanto, su mantenibilidad. Intentamos aumentar la validez externa de las mtricas realizando el segundo experimento con los profesionales, con lo que los resultados obtenidos se han podido generalizar considerablemente.
RCOST - Grupo Alarcos

The impact of educational background on design knowledge sharing during pair programming
3rd Conference
Professional Knowledge Management
Experiences and Visions
The current work is part of a family of experiments, aiming at evaluating the relationship between the paradigm practice of working in pairs applied to any phase of software process and knowledge building about the big picture of the system Experimento:
Hiptesis Ho: the difference in education between the pairs components does not affect the building of system knowledge realized by the pairs components. H1: the difference in education between the pairs components affects the building of system knowledge realized by the pairs components. Sujetos 4 couples with one MUTS student and one MUTEGS student; 5 couples with two MUTS students; 5 couples with two MUTEGS students; the other 16 subjects, MUTS and MUTEGS, worked as solo designers.
Standard Deviation
2 1,8 1,6 1,4 1,2 1 0,8 0,6 0,4 0,2 0 MUTS MUTS MUTEGS MUTS MUTEGS MUTEGS MUTS MUTEGS
First Replica Students enrolled at the Department of Computer Science at the University of Castilla-La Mancha in Spain Second Replica The subjects were students of the course Software Engineering, at the fifth and final year of the laurea degree in Computer Engineering at University of Naples, Federico II
Average
7,00 6,00 5,00 4,00 3,00 2,00 1,00 0,00 Naples Pairs Italian MUTS- Italian MUTSMUTS MUTEGS Italian MUTEGSMUTEGS Spanish Pairs
Outcomes of the family of the experiment The experiment permitted to drawn the following conclusions that can be taking into account especially for improving the team management:
When pairing developers owing the same kind of degree the effect on the knowledge building through the practice is significant.
When pairing developers owing different kinds of degree, the knowledge building seems to be strongly hindered: the drawback is that it does not help humanistic people in improving their knowledge and creates hurdles for scientific people to exploit their attitudes to build a deep knowledge through the practice.
The benefit of pair programming on knowledge transfer is completely lost
QU CUESTIONES
HAY QUE TENER

EN CUENTA A LA
HORA DE
EVALUAR UN
EXPERIMENTO?
CASO DE ESTUDIO
(Yin, 2003)
Una investigacin emprica que aborda un fenmeno contemporneo dentro de su contexto real, cuando: las fronteras entre el fenmeno y el contexto no son claramente evidentes trata con situaciones distintivas tcnicamente en las cuales habr muchas ms variables de inters que datos se basa en mltiples fuentes de evidencia, con datos necesarios para converger de una manera triangular se beneficia del desarrollo previo de proposiciones tericas para guiar la recogida y anlisis de datos.
Aplicaciones de los casos de estudio explicar los supuestos enlaces causales en intervenciones reales que son muy complejos para las estrategias de encuesta o experimento describir una intervencin y el contexto real en la que ha ocurrido ilustrar ciertos tpicos en una evaluacin, en modo descriptivo explorar las situaciones en las que la intervencin que est siendo evaluada no tiene un conjunto claro de resultados nicos estudiar un estudio de evaluacin (metaevaluacin)
A) Diseo de caso nico: es anlogo a un experimento nico y se justifica cuando: representa un caso crtico para probar una teora representa un caso extremo o nico representa un caso representativo o tpico es un caso revelador (una oportunidad de observar un fenmeno previamente inaccesible) es un caso longitudinal
B) Mltiples casos de estudio: se considera la evidencia ms slida y el estudio ms robusto. La lgica de replicacin es anloga a la utilizada en mltiples experimentos.
1. Preparacin en la recogida de datos
La primera fase de preparacin consta de diferentes tareas:

Formacin y preparacin para un caso de estudio especfico Protocolo del caso de estudio Llevar a cabo un caso de estudio piloto
Para mejorar la fiabilidad del caso de estudio debe establecerse un protocolo, con:
una visin general del proyecto de caso de estudio procedimientos de campo cuestiones de caso de estudio una gua para el informe del caso de estudio
Caso simple
CONTEXTO
caso
Caso mltiple
CONTEXTO caso CONTEXTO caso
Holstico
CONTEXTO
caso
CONTEXTO
caso
CONTEXTO caso
CONTEXTO caso
U. anlisis 1
CONTEXTO caso
U. anlisis 1
Embebido
Unidad de anlisis 1 Unidad de anlisis 2
U. anlisis 2
U. anlisis 2
CONTEXTO caso
U. anlisis 1 U. anlisis 2
CONTEXTO caso
U. anlisis 1 U. anlisis 2
Unidad de recogida de datos vs. la unidad de anlisis

Fuente de recogida de datos De un individuo D I S E O Acerca de Comportamiento un individuo individual Actitudes individuales Percepciones individuales Acerca de una organizaci n Cmo trabaja la organizacin Por qu trabaja la organizacin De una organizacin Registros de archivo Otros comportamientos, actitudes y percepciones reportadas Polticas de personal Productos de la organizacin Si el caso de estudio es un individuo Conclusiones del estudio
Si el caso de estudio es una organizacin
2. Recogida de evidencias
Fuente de evidencia Documentacin Ventajas Estable: se puede revisar de manera repetida No intrusiva: no creada como resultado del caso de estudio Exacta: contiene nombres y referencias exactas y detalles de un evento Amplia cobertura: larga extensin de tiempo, muchos eventos, y muchos entornos (Los mismos de la documentacin) Precisa y cuantitativa Centradas: directamente en el tema del caso de estudio Proporciona inferencia causal inferida Inconvenientes Recuperabilidad: puede ser baja Selectividad sesgada: si la recogida es incompleta Sesgo al informar: refleja el sesgo (desconocido) del autor Acceso: puede ser bloqueado deliberadamente
Registros de archivos
(Los mismos de la documentacin) Accesibilidad debida a razones personales Sesgo debido a cuestiones pobremente construidas Sesgo en las respuestas Inexactitudes debidas a pobre recuerdo Reflexividad: el entrevistado da al entrevistador lo que quiere oir
Entrevistas
Fuente de evidencia Observacin directa
Ventajas Realidad: abarca eventos en tiempo real Contextual: abarca el contexto del evento
Inconvenientes Consume tiempo Selectividad: excepto una amplia cobertura Reflexividad: un evento puede desarrollarse de forma diferente por ser observado Coste: horas necesarias para los observadores humanos (Los mismos de la observacin directa) Sesgo debido a la manipulacin de los eventos por parte del investigador Selectividad disponibilidad
Observacin participante
(Los mismos de la observacin directa) Da ideas de comportamientos y motivos personales Iluminador en caractersticas culturales Iluminador en operaciones tcnicas
Artefactos fsicos
4. Elaboracin del informe del caso de estudio

audiencia: colegas acadmicos, practicantes, grupos especiales (tribunales de tesis), patrocinadores de subvenciones si se trata del informe de un caso de estudio que forma parte de un estudio ms amplio multimtodo la estructuras elegida para el caso de estudio
TIPO DE ESTRUCTURA PROPSITO DEL CASO DE ESTUDIO EXPLICATIVO ANALTICA-LINEAL COMPARATIVA CRONOLGICA X X X DESCRIPTIVO X X X EXPLORATORIO X X X
CONTRUCCIN DE TEORA
SUSPENSO NO SECUENCIAL
X
X X
5. Validacin del caso de estudio
Para que un caso de estudio sea ejemplar, debe poseer ciertas caractersticas como:
Ser significativo Ser completo Considerar perspectivas alternativas Mostrar suficiente evidencia Debe componerse en una manera atractiva
Validez de los casos de estudio

Pruebas Tctica de caso de estudio
usar varias fuentes de evidencia establecer una cadena de evidencias hacer que informadores clave revisen el borrador del informe de caso de estudio
Hacer pattern-matching Hacer construccin de explicaciones Abordar las explicaciones rivales Utilizar modelos lgicos Utilizar teora en casos de estudio nicos Utilizar lgica de replicacin en casos mltiples Utilizar protocolo de caso de estudio Desarrollar una base de datos de casos de estudio
Fase de la investigacin en que ocurre la tctica

Recogida de datos Recogida de datos Composicin
Validez de constructo
Validez interna
Anlisis de datos Diseo de la investigacin
Validez externa
Fiabilidad
Recogida de datos
realizar 1 caso de estudio seleccionar casos desarrollar teora disear protocolo de recogida de datos realizar 2 caso de estudio
escribir Informe de caso individual
obtener conclusiones intercasos
modificar teora
desarrollar implicaciones polticas
realizar restantes caso de estudio
escribir conclusiones intercasos
QU COMPONENTES
TENDRA UN MARCO
PARA LA RECOGIDA
Y ANLISIS DE
INFORMES DE CASOS
DE USO
INDUSTRIALES?
ENCUESTAS
(Yin, 2003)
1. Fijar objetivos especficos y medibles 2. Planificar la encuesta
3. Asegurar que estn disponibles los recursos adecuados 4. Disear la encuesta 5. Preparar el instrumento de recogida de datos 6. Validar el instrumento 7. Seleccionar los participantes 8. Administrar y puntuar el instrumento 9. Analizar los datos 10. Informar sobre los resultados
TIPOS DE ENCUESTAS Recoge informacin con la intencin de describir

Puede ser supervisada o no Compara conocimientos, actitudes, comportamientos Fijar sentencias claras sobre el resultado esperado Proporcionar objetivos claros y medibles Analizar y producir resultados significativos
DISEO DE ENCUESTAS - Similar a un experimento

- Describir un fenmeno de inters Proporcionar ms detalles acerca de un proceso - Evaluar el impacto de una intervencin Examinar la efectividad de la tcnica
- Efectivo: resistente a sesgos, apropiada, en coste
DISEOS DESCRIPTIVOS
1. Cross-sectional: pedir informacin una vez
2. Cohorte: observar el cambio en el tiempo

3. Caso de control: examen retrospectivo
En Ing. del Sw. Se usa una combinacin de 1) y 3)
DISEO EXPERIMENTALES
- Estudios de control concurrentes - asignacin al azar a los grupos - asignacin no al azar - Estudios de autocontrol - pre y post pruebas en una clase - Estudios de control histricos - Estudios de combinacin de tcnicas
TAMAO DE LA MUESTRA - NO ES FACTIBLE QUE RESPONDA TODO EL MUNDO

- Se quiere un tamao de muestra representativo - Prevenir inexactitudes en la muestra - Restricciones por coste - HAY QUE ASEGURAR QUE LA GENTE:
- Puede contestar las preguntas

- Quieren contestar las preguntas - Estn motivados para contestar
CONSTRUCCIN DEL INSTRUMENTO

- Bsqueda de la literatura para encuestas similares - Seleccin de preguntas es crucial: - Comprender a los que responden - Preguntar un n adecuado de cuestiones
- Estandarizar los formatos de respuesta

- Construccin de preguntas: - cuestiones adecuadas
- cuestiones concretas
- mejorar la construccin de preguntas
TIPOS DE PREGUNTAS
- Abiertas o cerradas
- Escalas balanceadas - Formato del cuestionario
- Instrucciones:
- Explicar el propsito del estudio
- Describir el patrocinador
- Incluir datos de contacto

- Explicar cmo y porqu han sido seleccionados - Explicar cmo devolver el cuestionario
- Proporcionar estimacin realista de tiempo
EVALUACIN DEL CUESTIONARIO

- MOTIVACIN - SESGO DEL INVESTIGADOR
- La manera de preguntar
- El n de cuestiones - El rango y tipo de categoras de respuestas - Las instrucciones para responder
PRETESTING DEL INSTRUMENTO

- Verificar que las preguntas se entienden
- Evaluar la ratio de respuesta y la efectividad de los procedimientos de seguimiento

- Asegurar la fiabilidad y la validez del instrumento - Asegurar que las tcnicas de anlisis de datos sirven para las respuestas esperadas
TIPOS DE FIABILIDAD
- Confianza si los resultados se repiten
- Forma alterna: mltiples formas de expresin
- Consistencia interna: cuestiones repetidas

- Intra-observador: mismas respuestas cada vez
- Inter-observador/inter-rater: respuestas similares para las mismas condiciones
TIPOS DE VALIDEZ
- Validez de forma: extremadamente subjetiva
- Validez de contenido: cmo de apropiado
- Validez de criterio: cmo se compara con otros

- Validez de constructo: cmo se comparte en la prctica
MUESTREO
- Grandes poblaciones son prohibitivas en coste
- Usar un subconjunto reduce el coste
- Cautela al seleccionar a los representativos -> o se invalida la fiabilidad

- Ms fcil de seguir a pocas personas -> el seguimiento puede ser crtico
MTODOS DE MUESTREO PROBABILSTICOS

- Aleatorio simple: igual probabilidad
- Aleatorio estratificado: separados en grupos
- Sistemtico: selecconar cada X miembros

- Basado en clusters: pertenecer a un grupo especfico
MTODOS DE MUESTREO NO PROBABILSTICOS

- Conveniencia: disponibles y dispuestos
- Bola de nieve: recomendaciones de otros
- Cuota: estratificado hasta que se alcanza proporciones

- Focus groups: representante de un grupo
VALIDACIN DE DATOS
- Examen de datos post-mortem

- Verificar consistencia y complecin
- Se puede necesitar particionar las respuestas: - agrupar demogrficamente - ayuda a evitar errores de diseo
ANLISIS DE DATOS
QU FALLOS Y
QU ACIERTOS SE
PUEDEN
IDENTIFICAR EN
LAS SIGUIENTES
ENCUESTAS?
INTRODUCCIN
CONCLUSIONES
Necesidades de una organizacin de software relacionadas con el conocimiento

Aurum et al. (2003)
- disminuir el tiempo de desarrollo y el coste y aumentar la calidad

- tomar mejores decisiones - conocimiento sobre nuevas tecnologas - conocimiento sobre el dominio del problema - conocimiento acerca de polticas, prcticas y proyectos pasados locales
- ubicar fuentes de conocimiento

- necesidad de compartir el conocimiento de forma distribuida
CONCLUSIONES
Factores que posibilitan el proceso de gestin del conocimiento en las organizaciones de software - tecnologa que enlaza los desarrolladores y crea un repositorio de memoria organizacional accesible a toda la organizacin - liderazgo que impulsa la gestin de conocimiento en el desarrollo de productos y servicios software as como en los procesos de trabajo
- cultura organizacional que soporte la comparticin de conocimiento, experiencias, tecnologas e innovacin
CONCLUSIONES
Un soporte de conocimiento efectivo en el desarrollo de software requiere el soporte tanto de la gestin como de los niveles tcnicos - soporte del proceso software, modelos de mejora de procesos, actividades, resultados de los procesos, etc.
- soporte del producto software, diseo, ingeniera, modelado, - soporte al personal, adaptar un workflow, etc.
CONCLUSIONES
Modelo de gestin del conocimiento adecuado

Ebert et al. (2003)
Estrategia de negocio Reduccin de costes
Modelo de gestin
Organizacin
Conceptos Base de informacin Procesos comunes
Tipo de conoc. Explcito
Productividad Compartir, evitando redundancia Mejores prcticas
Especializacin Calidad Innovacin Creatividad
Explcito
Integracin y Conocimiento Tcito combinacin de dinmico conocimiento
CONCLUSIONES
Conocimiento del dominio del problema
Conocimiento del dominio de la solucin
Conocimiento del producto Conocimiento del proceso
Conocimiento del proyecto
CONCLUSIONES
Dificultades mayores
- hacer tcito el conocimiento explcito - mantener actualizado el conocimiento explcito
- llevar a cabo familias de estudios que aporten evidencias fiables

Capítulo 11

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo 11

Cargado por

Copyright:

Formatos disponibles

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

- INTRODUCCIN - INGENIERA DEL SOFTWARE

GESTIN DEL CONOCIMIENTO

- INTRODUCCIN - INGENIERA DEL SOFTWARE

GESTIN DEL CONOCIMIENTO

los procesos y productos

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

- Desarrollo del negocio

GESTIN DEL CONOCIMIENTO

Arquitectura de Gestin de Conocimiento

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

INGENIERA DEL SOFTWARE

GESTIN DEL CONOCIMIENTO

Actividades generales de KM aplicables a IS

GESTIN DEL CONOCIMIENTO

- herramientas CASE y entornos de desarrollo de software

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

- lecciones aprendidas, patrones, y mejores prcticas

- Estndares de ISO, IEEE, etc.

GESTIN DEL CONOCIMIENTO

CARACTERIZACIN DEL CONOCIMIENTO EN DISEO DE MICRO ARQUITECTURAS OO

Refactorizaciones. Heursticas. Buenas Prcticas.

GESTIN DEL CONOCIMIENTO

Apenas existen catlogos para elementos que no sean los patrones

El conocimiento y experiencia prctica en OOD apenas se usa y apenas se conoce

GESTIN DEL CONOCIMIENTO

0..n 0..n 0..n Patrn estructura 0..n 0..n

Regla 0..n recomendacin 0..n 0..n

{ una, otra o las dos, pero siempre alguna}

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

- lecciones aprendidas, patrones, y mejores prcticas

- Estndares de ISO, IEEE, etc.

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

WG20 Software Engineering Body of Knowledge WG22 Vocabulary

WG19 ODP and Modeling Languages WG4 Tools And Environment

GESTIN DEL CONOCIMIENTO

15288 Foundation 19759

Process Implementation and Assessment

12207 1527 1 90003

9126 14598 14756

6592 9294 15910 18019

14143 19761 20926 20968 24570

14102 14471 15940 18018

14568 15474 15475 15476

15437 15909 19501 8807

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO

GESTIN DEL CONOCIMIENTO