semat vision es
TRANSCRIPT
MÉTODO Y TEORÍA DE LA INGENIERÍA DE SOFTWARE
DECLARACIÓN DE LA VISIÓN Por Ivar, Bertrand y Richard
(Traducido1
por Leonardo Agudelo Marín y Luis Antonio Salazar Caraballo)
1 Propósito y alcance El llamado a la acción original del Semat dio una definición amplia del problema que la iniciativa
Semat pretende enfrentar:
Para desarrollar soluciones apropiadas necesitamos un marco de trabajo más preciso. La
definición de visión presente es ese marco de trabajo, similar a un “documento de definición de
requisitos” y a una “hoja de ruta” en el software, incluyendo la lista de objetivos para el primer
año.
1 Nota: Este documento fue traducido a partir de la publicación oficial de la Declaración de la Visión del SEMAT. El
documento original en inglés puede encontrarse en http://www.semat.org/pub/Main/WebHome/SEMAT-vision.pdf
Convocatoria a la acción
Hoy en día la ingeniería de software está gravemente obstaculizada por prácticas inmaduras.
Los problemas específicos incluyen:
La prevalencia de tendencias que son más comunes en la industria de la moda que en
una disciplina ingenieril.
La ausencia de unas bases teóricas ampliamente aceptadas y difundidas.
La gran cantidad de métodos y variantes de métodos, con diferencias poco entendidas
y ampliadas de forma artificial.
La carencia de evaluación y validación experimental creíble.
La división entre la práctica en la industria y la investigación académica
Apoyamos un proceso para refundar la ingeniería de software basada en una teoría sólida,
principios probados y mejores prácticas que:
Incluyan un kernel (núcleo) de elementos ampliamente aceptados, extensibles para
usos específicos.
Tengan en cuenta tanto las cuestiones de tecnología como de las personas.
Sean soportadas por la industria, la academia, los investigadores y los usuarios.
Soporten la extensión de cara a cambios en los requerimientos y en la tecnología.
Los participantes en el esfuerzo vienen de muchos frentes de la profesión; se incluyen
programadores profesionales, gerentes de proyecto, consultores y científicos de la computación.
Esperamos discusiones intensas, ya que la intención de la declaración de la visión no es imponer
una solución particular. Sin embargo, para funcionar correctamente, el grupo necesita compartir
una visión, estar de acuerdo en los objetivos comunes, definir los hitos iniciales y aceptar los
principios necesarios para alcanzar estos objetivos. El presente documento es un intento para
definir la visión (sección 2), los objetivos (sección 3), las reglas (sección 4), los principios (sección 5)
y los hitos para un año (sección 6). Puesto que se requiere más detalle para entender
completamente los cinco objetivos de la sección 3, se dedicó específicamente un apéndice a cada
uno de estos.
Estos objetivos de largo alcance y los hitos para un año de la sección 6 son complementos
indispensables el uno del otro: lograr cambios fundamentales, objetivo del Semat, tomará muchos
años; pero crear momentum requiere alcanzar resultados iniciales visibles en poco tiempo.
2 La visión La visión del Semat es doble:
Alcanzar las metas, como se describe más abajo y en los apéndices.
Crear una plataforma (kernel) permitiéndole a las personas describir sus prácticas,
patrones y métodos actuales y futuros, de modo que éstos puedan ser compuestos,
simulados, aplicados, comparados, evaluados, medidos, enseñados e investigados.
3 El núcleo (kernel) El llamado a la acción nos insta a ponernos de acuerdo en “un kernel de elementos ampliamente
aceptados, extensibles para usos específicos”. Para ser efectivo el kernel debe permanecer
concreto, enfocado y pequeño.
El alcance del kernel se limita a los elementos descritos en esta sección. En particular, el kernel no
es un intento de una metodología unificada.
El foco de los esfuerzos del kernel es identificar y describir los elementos esenciales para todas las
actividades de la ingeniería de software.
Los ejemplos típicos de lo que abarca el kernel son el trabajo en grupo, gestión de proyectos y
mejoramiento del proceso. El kernel también integrará conceptos de otras disciplinas de la
ingeniería.
El kernel debe acomodarse al cambio. La intención en los primeros doce meses es identificar un
kernel que capture los métodos, prácticas y patrones de interés (Fig. 1) usados en la actualidad en
la producción de software y que puedan ser adaptados para evoluciones futuras de la disciplina.
Figura 1: El diamante Semat
El kernel debe incluir una representación concreta de los actos y artefactos del desarrollo de
software, aplicables a un rango amplio de proyectos de software. También debe proveer un
lenguaje de extensión para la adaptación de métodos, prácticas y patrones específicos.
Para satisfacer estas necesidades, el kernel involucra tres grandes clases de elementos:
El kernel: aspectos universales (para todos los casos) y lenguaje del kernel (nivel 1 en la
Figura 1.).
Prácticas y patrones (nivel 2), definidos en términos del kernel.
Métodos, definidos como combinaciones de prácticas y patrones. (nivel 3).
El término “patrón” merece una definición específica. Se usa en el presente documento para
denotar un modo general de operación aplicado a través de las prácticas. Por ejemplo, muchas
prácticas involucran la organización de talleres, o confían en la auto-organización de los equipos.
Al describir estos conceptos como patrones, evitamos repetir sus detalles en la descripción de
prácticas específicas.
4 Las Metas El trabajo procederá a lo largo de cinco grupos de trabajo diferentes:
1. Definiciones: definen la ingeniería de software y otros conceptos esenciales de la disciplina.
2. Teoría: identifican las teorías (en particular las provenientes de las matemáticas) que proveen
una ayuda esencial.
Métodos
Prácticas Patrones
Aspectos universales Lenguaje del kernel
Nivel
3
2
1 El kernel
Compuesto de
Definido en términos de
3. Aspectos universales: identifican los aspectos universales (para todos los casos) en la ingeniería
de software, los cuales deben ser integrados en el kernel de Semat.
4. Lenguaje del kernel: definen el lenguaje para describir los aspectos universales, prácticas y
patrones.
5. Evaluación: técnicas para evaluar las prácticas y teorías de la ingeniería de software, incluyendo
los resultados de Semat.
Todos los grupos deberían producir algunos resultados visibles en doce meses2, pero el grado de
estos resultados puede variar ampliamente. Es necesario que los elementos 3 y 4 muestren
resultados más rápidamente, ya que debemos identificar los elementos del kernel que sirven de
base para el resto del trabajo, que ayuden a la industria del software a reducir la maraña de
métodos y a mejorar la enseñanza de la ingeniería de software.
Los apéndices proponen algunas ideas iniciales para cada uno de los elementos.
5 Los principios Dado que el modus operandi preciso del esfuerzo de Semat será determinado al inicio del trabajo,
un número de principios generales son esenciales para su éxito.
Los principios 1 al 9 se aplican para el final del resultado de Semat, es decir, para “el Kernel”. Los
principios 10 al 13 se aplican al proceso para lograr este resultado.
1. Calidad. El objetivo principal será el mejoramiento de los productos y los procesos de software.
2. Simplicidad. El kernel únicamente incluirá conceptos esenciales.
3. Teoría. El kernel se fundamentará en bases teóricas sólidas y rigurosas.
4. Realismo y escalabilidad. El kernel será aplicable por medio de proyectos prácticos, incluyendo
proyectos grandes, y basado en técnicas probadas siempre que sea posible.
5. Justificación. Cada recomendación debe ser justificada con un claro raciocinio.
6. Verificabilidad. Cada afirmación deberá ser objeto de evaluación y refutación experimental.
7. Perspectiva hacia el futuro. Teniendo en cuenta las elecciones metodológicas de las
generaciones previas, el kernel no deberá estar obligado a ser totalmente compatible.
8. Modularidad. Las prácticas y patrones se definen usando el kernel, pueden ser combinadas y
adaptadas para acomodarse a las necesidades de las organizaciones individuales.
2 NDT. La Declaración de la Visión del SEMAT fue publicada en febrero de 2010
9. Auto-mejoramiento. El kernel deberá acompañarse por mecanismos que permitan su propia
evolución.
10. Apertura. En el desarrollo del kernel, cada sugerencia provista de una manera apropiada por
esfuerzo de los miembros de Semat, será tenida en cuenta.
11. Justicia. Todas las ideas contribuidas deberán ser evaluadas por sus méritos. Ningún aspecto
deberá ser realizado para favorecer los intereses de individuos o comunidades particulares.
12. Objetividad. Las ideas deberán ser evaluadas en la base de criterios objetivos, claramente
definidos previamente.
13. Puntualidad. Los plazos deben ser respetados para permitir el progreso y entrega de
resultados del esfuerzo.
6 Hitos a un año3
Los resultados esperados un año después de iniciar el proyecto son los siguientes. Cada uno
corresponde a una de las cinco direcciones identificadas en los objetivos y representan el progreso
inicial objetivamente evaluable hacia la meta correspondiente.
6.1. Un conjunto de definiciones, incluyendo una definición del término ingeniería de software y
las definiciones de los conceptos fundamentales requeridos por las prácticas y los patrones.
6.2. La identificación de teorías específicas o áreas teóricas potencialmente útiles para Semat,
soportadas por ejemplos de su aplicación exitosa a prácticas específicas de la ingeniería de
software.
6.3. Un conjunto de aspectos universales y una demostración de que estos pueden ser validados
contra unas pocas prácticas específicas usadas por métodos importantes, incluyendo como
mínimo uno no usado en el desarrollo de los aspectos universales.
6.4. La definición de un lenguaje de kernel y su uso exitoso para describir los aspectos universales
en 6.3 y su composición, tal como se aplicó a los métodos seleccionados en 6.3.
6.5. Un conjunto de métricas, suficiente para evaluar las prácticas del software, los productos y las
personas, y soportada por la evidencia de su aplicación exitosa en algunos proyectos.
3 NDT. La Declaración de la Visión del SEMAT fue publicada en febrero de 2010
Apéndices
Los cinco apéndices detallan los cinco objetivos de la definición de la visión: Definiciones, Teoría,
Aspectos universales, Lenguaje del kernel y Evaluación.
Apéndice 1: Definiciones Muchos debates técnicos involucran tanto terminología como desacuerdos en la esencia. El grupo de Definiciones pretende lograr un consenso de las definiciones requeridas tempranamente en el proceso y rastrear y categorizar las definiciones que surgen de otros ítems en el tiempo.
A1.1 ¿Qué es la ingeniería de software?
Un buen punto de inicio y ejemplo representativo será la definición de ingeniería de software. La
definición obvia (“la ingeniería de software es la disciplina y la aplicación de métodos de ingeniería
para el campo del software”) es insuficiente para algunas personas, bien porque sienten que
“ingeniería” en general no está bien definida o porque falta una descripción de cómo la aplicación
al software afecta la definición básica. En el otro extremo, Wikipedia tiene una larga definición,
tomada del SWEBOK, el cuerpo de conocimiento de la ingeniería del software (“la ingeniería del
software es el estudio y la aplicación de enfoques sistemáticos, disciplinados y cuantificables al
desarrollo, operación y mantenimiento del software; esto es, la aplicación de la ingeniería al
software”). Esta definición es decepcionante: la lista de adjetivos es redundante (“disciplinado”
agrega poco a “sistemático”); la lista de actividades es arbitraria (¿por qué “operación” y no, por
ejemplo, documentación?); y el final “esto es…” cuestiona la utilidad de todo lo que lo precede.
Ha habido mucha discusión en el blog de Semat acerca de la definición del término ingeniería del
software. Un resumen de las posiciones:
La ingeniería de software es una disciplina que requiere estudio formal, experiencia,
respeto, creatividad y disciplina (ver esta pieza irónica en
http://parijatmishra.wordpress.com/2010/01/08/188/).
La definición de SWEBOK como se mencionó más arriba, usada por la Wikipedia.
El Consejo Americano de Ingenieros para el Desarrollo Profesional define "ingeniería" como la aplicación creativa de los principios científicos para diseñar o desarrollar estructuras, máquinas, aparatos o procesos de manufactura, o que trabaja usándolas individualmente o en combinación; o para construirlas u operarlas con el completo conocimiento de su diseño; o para predecir su comportamiento bajo condiciones operativas específicas en lo que respecta a una función deseada, operación económica y seguridad a la vida y la propiedad (ver http://www.sciencedaily.com/articles/e/engineering.htm, y claramente podemos sustituir “el software trabaja” por “trabaja” para definir ingeniería de software)
Un signatario criticó las definiciones dadas antes, sobre la base de que la ingeniería de
software debería integrar habilidades, juegos cooperativos, procesos y diseño flexibles, así
como adquisición de conocimiento (ver
http://alistair.cockburn.us/The+end+of+software+engineering+and+the+start+of+econom
ic-cooperative+gaming)
Quizás estas definiciones no están tan apartadas; todas comparten la idea general de aplicar
conocimiento científico y principios al software. Está entre los objetivos de la iniciativa Semat
reunir a muchos expertos con diferentes entrenamientos, pericia y experiencia para que se
pongan de acuerdo en una base única.
A1.2 Más allá de la definición básica
Junto con otros pocos conceptos fundamentales, la definición de ingeniería de software, o una
primera versión de esta, es parte de las metas iniciales a doce meses (sección 6).
Estos términos son solo un punto de partida y no es realista esperar el resto del trabajo de Semat,
en particular la definición del kernel, para la adopción de definiciones finales de todos los
conceptos involucrados en los componentes de Semat: métodos, prácticas, patrones, aspectos
universales y el lenguaje del kernel. El proceso de definición será continuo e iterativo, extendiendo
y refinando el repositorio de definiciones de Semat.
Apéndice 2: Teoría Una de las definiciones de ingeniería es que es la construcción de artefactos basada en principios
científicos y finalmente en las matemáticas. La ingeniería de software no debería ser la excepción.
Una fuerte base matemática es esencial para el esfuerzo del Semat.
Una base teórica considerable está disponible para la ingeniería del software. Una parte consiste
en teorías matemáticas existentes, ampliamente utilizadas sin cambios; por ejemplo muchas áreas
de la ingeniería de software hacen un buen uso de la probabilidad, las estadísticas y teorías de
colas (y prominentes investigadores repiten que deberíamos usar mucho más estas teorías). Otro
ejemplo es la teoría de categorías, la cual sirvió como inspiración para los tipos de datos abstractos
y la programación orientada a objetos (aunque pocos desarrolladores O-O lo saben). En otros
casos las aplicaciones de software han impulsado el desarrollo de nuevas teorías o un mayor
desarrollo de las que existen; los ejemplos incluyen la lógica, donde gran parte del impulso en las
últimas décadas proviene de la necesidad de lenguajes de programación, teorías de autómatas y
nuevos desarrollos como la verificación de modelos y la interpretación abstracta.
La ingeniería de software no se trata solo de tecnología, sino también de organización, gestión,
comunicación, colaboración y otras facetas del software donde los puntos de vista pueden venir
de disciplinas como la economía, la sociología y la psicología. La ingeniería de software necesita
también de teorías de estas áreas para soportar el desarrollo de métodos, prácticas, patrones y
aspectos universales.
El abismo entre los profesionales y los académicos es más pronunciado en el software que en
otras disciplinas de la ingeniería. Mientras que es difícil imaginar a un ingeniero eléctrico
asegurando que las ecuaciones de Maxwell son un ejercicio puramente académico irrelevante
para los profesionales, en los ingenieros de software y gerentes de proyectos es común escuchar
este tipo de comentarios acerca de las contribuciones teóricas (como las técnicas de verificación
formal) que son tan importantes en su campo. Con frecuencia, los profesionales ni siquiera han
oído hablar de dichas técnicas.
Los académicos no están enteramente libres de culpa: algunos investigadores se han concentrado
en problemas que suponen cambios científicos, pero que son difíciles de relacionar con las
preocupaciones de la industria.
La interacción entre los dos campos ha mejorado en años recientes. Los métodos formales, por
ejemplo, son cada vez más usados (a menudo en una forma disfrazada) en muchas áreas de
tecnologías de la información. Una de las metas de Semat es asegurarse de que la ingeniería de
software crezca al nivel de otras disciplinas y, sin remover enteramente las diferencias (una meta
que no es deseable, ya que la investigación y la aplicación no tienen roles idénticos), establecer
una relación sana entre la teoría y la práctica del software.
La misión del grupo de trabajo de Teoría es avanzar en esta meta. Esto incluye en el primer paso,
las siguientes tareas:
1. Identificar las áreas de la ingeniería de software que más necesitan teorías (y todavía no
están basadas en una teoría válida en los modos dominantes de operación de la
profesión).
2. Entre otras teorías que han sido aplicadas al software pero solo por una minoría de
proyectos, identificar aquellas que presentan el potencial más alto de aplicación de
beneficio generalizado.
3. Entre las áreas identificadas en la tarea 1, identificar aquellas para las que no hay teoría
disponible todavía.
4. Identificar los componentes del esfuerzo del Semat que requerirán de un soporte teórico
específico. En particular, definir la clase de teoría requerida para proveer el lenguaje del
kernel (apéndice 4) con una teoría bien definida.
Estas cuatro metas parecen ser alcanzables en un plazo fijado a un año para las etapas iniciales del
proyecto Semat.
El segundo paso involucra:
5. Desarrollar una Lista de Teorías Aplicables a la Ingeniería del Software (ROAST),
suministrando una lista de teorías útiles existentes (según se establece en el punto 2) y,
para cada una de éstas, una guía detallada para su aplicación a proyectos actuales.
6. Desarrollar la teoría para el lenguaje del kernel (ver el punto 4).
7. Elegir un pequeño número (probablemente no más de tres, y posiblemente tan pequeño
como uno) de teorías que necesiten ser desarrolladas y establecer las condiciones para su
desarrollo, así como, si es posible, los elementos básicos de estas teorías.
Apéndice 3: Aspectos universales4
Mantener el kernel concreto, enfocado y pequeño requiere identificar los reales aspectos
universales de la ingeniería de software. Mientras parece haber un consenso general acerca de la
existencia de estos elementos, esenciales para todos los esfuerzos en ingeniería de software,
aparentemente permanece mucha confusión acerca de lo que son y de cómo evaluamos lo que es
realmente esencial (una condición para incluirlo dentro del kernel). La tarea del grupo de Aspectos
Universales es identificar y definir estos elementos.
A3.1 Propiedades del kernel
Aquí hay unas pocas características candidatas que consideramos integrales para cualquier kernel
exitoso:
Conciso. El kernel debe enfocarse únicamente en el pequeño conjunto de elementos que son
realmente esenciales.
Escalable. El alcance del kernel debe extenderse desde los proyectos más pequeños hasta los
sistemas más grandes y a los sistemas de sistemas.
Extensible. El kernel debe proporcionar la habilidad para añadir prácticas, patrones, niveles de
detalle y modelos de ciclo de vida. Debe apoyar la adaptación a dominios específicos de
aplicación y a proyectos que involucran más que software.
Medible. El kernel debe proveer mecanismos para evaluar cuantitativamente todos los
artefactos relevantes de los procesos y productos de software.
Formalmente especificado. El kernel debe ser definido matemáticamente. La definición debe
ser desarrollada junto con el kernel en sí, no debe ser pospuesta a posteriores esfuerzos
hipotéticos. Esta meta debe llevarse a cabo en cooperación con el punto de Teoría.
Cubrimiento amplio de prácticas. El kernel debe soportar muchas prácticas diferentes, siempre
y cuando sean reconocidas como beneficiosas para segmentos significativos de la industria.
Cubrimiento amplio de ciclos de vida. El kernel se debe acomodar a varios modelos de ciclo de
vida reconocidos como beneficiosos para segmentos significativos de la industria.
Cubrimiento amplio de tecnología. El kernel debe ser adaptable a un amplio rango de
tecnologías de software (lenguajes de programación, lenguajes de especificación, notaciones
gráficas, herramientas de software) siempre y cuando éstas sean reconocidas como
beneficiosas para segmentos significativos de la industria.
A3.2 Rol
El kernel es donde se moldea la iniciativa de Semat porque determina la aplicabilidad de todos los
demás esfuerzos de Semat al trabajo práctico de los ingenieros de software. Proveerá un marco de
trabajo concreto que ellos pueden utilizar en cualquier proyecto, permitiéndoles identificar y
aplicar las prácticas que necesitan para ser exitosos en su contexto particular.
A3.3 Criterios para la inclusión
Las reglas básicas que caracterizan los elementos que merecen ser incluidos son las siguientes:
4 Escrito con la colaboración de Ian Spence
Universal: potencialmente aplicable a todos los esfuerzos de la ingeniería de software.
Significativo: tiene la habilidad de contribuir en un modo positivo y perceptible a la calidad de
los procesos o productos (o ambos) de software.
Relevante: disponible para la aplicación de todos los ingenieros de software, independiente de
su origen y campo metodológico (si lo tiene).
Definido con precisión.
Accionable: no solo palabras y conceptos, sino guías precisas que los proyectos puedan aplicar.
Evaluable: adecuado para la evaluación de su aplicación.
Integral. Este criterio aplica para la colección de elementos del kernel; juntos deben capturar
la esencia de la ingeniería de software, proveyendo un mapa que soporte las prácticas
cruciales, patrones y métodos de los equipos de ingeniería de software.
A3.4 Ejemplos y preguntas
En los diferentes blogs y discusiones acerca del kernel que aparecen en el sitio web de Semat, un
número de aspectos universales candidatos han sido identificados. Acá hay una corta discusión de
algunos ejemplos.
Algunos contribuyentes han sugerido que un aspecto universal de cualquier esfuerzo de ingeniería
de software son los programas que trabajan. ¿Qué es lo que esto significa exactamente:
programas que pasan el conjunto definido de pruebas? ¿Programas que cumplan los requisitos
definidos? ¿Programas que atiendan las necesidades reales de los clientes?
¿Qué pasa con los requisitos? ¿Son aspectos universales, o solo una de las prácticas usadas para
capturar las intenciones de los clientes?
Estas son las clases de preguntas que este grupo de trabajo tendrá que responder para crear un
kernel inicial que pueda ser usado para examinar algunas de las prácticas más populares y desafiar
nuestra definición de ingeniería de software.
Otros contribuidores han sugerido largas listas de aspectos universales incluyendo elementos
como:
Proyecto
Equipo
Experiencia de usuario
Sistema
Calidad
Intención
¿Son todos estos realmente aspectos universales? ¿Son realmente esenciales para la ingeniería de
software? ¿Están en el mismo nivel conceptual (“los mismos tipos de cosas”)? ¿Se relacionan con
cada uno de los otros y si es así, cómo se relacionan?
La meta de la tarea del kernel es producir un modelo concreto de ingeniería del software
respondiendo a todas estas preguntas, y proveyendo las bases para la definición, evaluación y
mejoramiento de las prácticas, patrones y métodos que nos permitirán profesionalizar la
comunidad de la ingeniería de software.
Apéndice 4: Lenguaje del Kernel Dado que la reflexión sobre el lenguaje del núcleo se encuentra en una etapa temprana, este
apéndice no define los requerimientos finales para el lenguaje, pero si da una idea en las
necesidades que este debe abordar.
El desarrollo del lenguaje del kernel requerirá de dos clases de contribuidores con experticia
diferente:
Algunos brindarán una extensa experiencia con elementos de métodos (un término usado en
este apéndice para denotar métodos, patrones y prácticas), para asegurar que el lenguaje del
kernel pueda cubrir las necesidades de los usuarios.
Otros brindarán experticia en el diseño de lenguajes.
Las dos secciones de este apéndice se refieren correspondientemente al uso del lenguaje del
kernel y a su diseño.
A4.1 Uso del lenguaje del Kernel
El rol del lenguaje del kernel es describir prácticas y patrones, y su composición en métodos. La
palabra “descripción” tal como se usa en esta sección denota una clase de descripción de un
elemento de un método (en el sentido anterior), expresada en el lenguaje del kernel.
Los principales usuarios del lenguaje del kernel son los proyectos que están buscando elementos
de método apropiados y los proyectos que están aplicando los elementos de método que han
elegido.
El lenguaje del kernel y las descripciones resultantes deben satisfacer las siguientes propiedades
para entregar el valor esperado a estos usuarios:
El lenguaje puede cubrir todas las prácticas y patrones relevantes, y su composición, en los
métodos actuales.
Soporta la composición de éstos en diferentes maneras para describir nuevos elementos de
método.
Es extensible, permitiendo la descripción de elementos de métodos aún no inventados, así
como sus elementos (tales como las prácticas individuales).
Las descripciones deben ser fáciles de entender; el lenguaje debe diseñarse para la comunidad
de desarrolladores (no solo para ingenieros de procesos y académicos).
El lenguaje soporta la comparación de elementos de métodos (una tarea muy compleja
actualmente)
Las descripciones se construyen en términos de aspectos universales identificados en el
esfuerzo de Semat (ver el apéndice A.3), colaborando con uno de los objetivos principales del
Semat: abolir la reinvención de prácticas, patrones y métodos.
El lenguaje y la descripción resultantes soportan la simulación de la aplicación de los
elementos de métodos.
Soportan la aplicación de estos elementos de método en proyectos reales.
Proveen mecanismos de validación, así que es posible evaluar cuando un proyecto que busca
aplicar un elemento de método (como se describe a través del lenguaje de kernel) lo hace
realmente, y no solo de labios para afuera. Este problema algunas veces se refiere a “cerrar la
brecha” (entre lo que los equipos de proyectos dicen que hacen y lo que realmente hacen).
El último requisito tiene implicaciones en la organización de equipos: cada equipo debe proveer
recursos apropiados para evaluar el desempeño actual del proyecto para los elementos de
método elegidos, tal como se describe en el lenguaje del kernel.
A4.2 Diseño del lenguaje del kernel
A pesar de que no existe un diseño preliminar para el lenguaje del kernel, se han identificado los
siguientes requisitos para su diseño.
Como cualquier otro lenguaje definido precisamente, el lenguaje del kernel tendrá una sintaxis
abstracta, reglas de validación (“semántica estática”) y semántica. Deberá tener al menos una
sintaxis concreta, pero puede llegar a tener muchas, por ejemplo una forma textual y una forma
gráfica.
El lenguaje del kernel prestará apoyo a cuatro aplicaciones principales:
Descripción de aspectos universales: prácticas y patrones, los cuales son los bloques de la
construcción, y los mecanismos de composición para construir los métodos de estos
elementos.
Simulación. La aplicación de las descripciones resultantes a un proyecto
Aplicación de las descripciones para un “cierre de brecha” real.
Evaluación de una simulación o aplicación para los elementos de método elegidos.
El concepto de estado juega un rol importante en el lenguaje del kernel para representar el
progreso del trabajo. Por ejemplo, la descripción de una práctica que involucre desarrollo iterativo
requiere la descripción de estados de inicio y finalización de cada iteración.
El lenguaje del kernel debe ser extensible; en particular, debe permitir la adición o modificaciones
de prácticas, patrones y posiblemente técnicas de composición.
Las siguientes reglas aplican para las prácticas:
Una práctica es un problema aparte de un método. Algunos ejemplos son: “el desarrollo de
requisitos para probar”, “desarrollo iterativo”, “desarrollo basado en componentes”.
Cada práctica debe describirse por sí misma, aparte de cualquier otra práctica.
Cada práctica, a menos de que esté definida como una actividad continua, tiene un inicio y fin
claros.
Cada práctica aporta valor a sus interesados.
Cada práctica debe ser evaluable; su descripción debe incluir criterios para su evaluación.
Donde se pueda aplicar, los criterios de evaluación deben incluir elementos cuantitativos;
correspondientemente, la descripción debe incluir sistemas de medición adecuados.
Los mecanismos de composición para prácticas incluyen fusión y extensión.
Las siguientes reglas aplican para los patrones:
Cada patrón (por su definición en la sección 3) debe ser aplicable a muchas prácticas
diferentes.
Cada patrón debe describirse por sí mismo, aparte de cualquier otro patrón y de cualquier
práctica para la que este aplique.
Apéndice 5: Evaluación5
El establecimiento de unas bases firmes para la ingeniería de software requiere un modo
sistemático de evaluar prácticas, patrones, métodos (todos juntos llamados “elementos de
método” en este apéndice) y las herramientas de soporte sobre la base de criterios objetivos.
Como en otras disciplinas de ingeniería, estos criterios deben ser cuantitativos; deben aplicar
teorías bien definidas (ver apéndice 2) y deben basarse en datos estadísticos sólidos.
Las preguntas fundamentales, tratadas en las tres secciones de este apéndice, son:
¿Cuáles son los objetivos de los elementos de método evaluados?
¿Cuál es el criterio para juzgar su calidad?
¿Cuál debe ser el proceso de medición?
A5.1 Objetivos de la evaluación
Una vez hemos definido el kernel, en particular los elementos del método relevantes (en el
sentido expuesto anteriormente), debemos dar a los usuarios criterios objetivos para evaluar si
estos elementos les ayudan con sus tareas. Esta observación plantea dos preguntas: ¿Quiénes son
los usuarios y cuáles son sus tareas previstas?
Las categorías de usuario de mayor relevancia directa, son:
Profesionales del software (ingenieros y administradores), quienes son pragmáticos y usarán
cualquier elemento de método que encuentren disponible y sea fácil de usar.
Sus clientes, que están generalmente preocupados por tener software con calidad, rápido, a
bajo costo y de un modo predecible.
Académicos, que enseñan o investigan ingeniería de software.
Todas estas categorías de usuarios tienen en cuenta todos los procesos tradicionales y las
cualidades del producto, incluyendo funcionalidad, disponibilidad, costo-efectividad, soporte,
usabilidad, confiabilidad, eficiencia, extensibilidad y reusabilidad.
Las tareas que serán objeto de evaluación incluyen todas las tareas importantes de la ingeniería de
software: tanto tareas técnicas (desde el análisis hasta el diseño, implementación, documentación,
verificación y validación, despliegue, operación entre otras) y tareas centradas en los humanos
tales como administración, entrenamiento, soporte y comunicación.
A5.2 Evaluación de la calidad
El método de evaluación debe ser aplicable a cualquier práctica y debe considerar todas sus
propiedades importantes:
5 Escrito con la colaboración de Watts Humprey
Funcionalidad: ¿La descripción del elemento del método hace posible medir la cobertura de la
funcionalidad prevista?
Usabilidad: ¿cómo se mide la usabilidad? Algunas técnicas posibles involucran un laboratorio
de usabilidad si está disponible, si no lo hay, se usan encuestas de usuario. Estas encuestas
deben ser definidas con precisión y deben ser repetibles de manera que una variedad de
situaciones de usuario puedan ser medidas y se obtengan datos objetivos y estadísticamente
útiles a partir de múltiples fuentes.
Confiabilidad: ¿El elemento del método siempre produce los resultados esperados o hay
variables de proyecto involucradas? y ¿cuáles son estas variables, su probabilidad e impacto?
Eficiencia: esta medida de productividad requiere datos acerca del tiempo invertido por uno o
más ingenieros de software en la aplicación del elemento de método, así como el volumen de
los productos de trabajo obtenidos.
Extensibilidad: este es un principio de diseño de sistemas donde la implementación tiene en
cuenta el crecimiento futuro. Es una medida sistemática de la habilidad para extender un
sistema y el nivel de esfuerzo requerido para implementar dicha extensión. Las extensiones
pueden realizarse por medio de adiciones de nuevas funcionalidades o a través de
modificaciones a funcionalidades existentes. ¿El elemento del método soporta el tema de
proveer cambios con un impacto mínimo a funciones de sistema existentes?
Reusabilidad: aquí hay cuatro tipos de criterios cuantitativos: reutilizar modelos de costo-
beneficio incluye análisis de costo-beneficio económico así como calidad y rentabilidad de la
productividad. Las métricas de cantidad de reutilización sirven para medir y monitorear un
esfuerzo de mejora de reusabilidad, rastreando porcentajes de reutilización de objetos del
ciclo de vida; las métricas de reusabilidad indican la probabilidad con la que un artefacto es
reutilizable; las métricas de reutilización de bibliotecas se usan para gestionar y rastrear el uso
de un repositorio de reutilización.
A5.3 Proceso de evaluación
La definición de un proceso de evaluación involucra tres aspectos: cómo elegir los proyectos para
evaluar los elementos del método; qué propiedades se deben medir y la organización del proceso.
Las siguientes subsecciones examinan estos asuntos.
A5.3.1 Elección de proyectos de ejemplo
Para evaluar las prácticas y otros elementos del método, se puede elegir un proyecto de software
industrial o unas pruebas controladas en un entorno experimental, por ejemplo con estudiantes.
Ninguna técnica es totalmente satisfactoria.
Los proyectos de la industria tienen dos grandes ventajas: tamaño (difícil de igualar en un contexto
académico) y realismo (ya que la intención es que se usen realmente). Estos, sin embargo,
enfrentan dos limitaciones principales. Primero, típicamente no soportan la reproductibilidad: el
tamaño de un proyecto industrial y su impacto económico implica que será generalmente un
esfuerzo de una sola vez, produciendo un conjunto de puntos de datos aislados con valor
estadístico cuestionable. Este problema puede ser superado recolectando datos de evaluaciones
de muchos proyectos en un contexto consistente, por ejemplo, proyectos de una misma
compañía, en la misma área general. La otra limitación es que en un proyecto industrial muchos
parámetros son establecidos por el contexto y más allá del control del procedimiento de
evaluación:
Producto nuevo frente a la modificación en un producto existente.
Auto contenido frente a parte de un sistema grande.
Interno frente a de uso comercial.
Desarrollo a la medida frente a producto de uso masivo.
Experticia, experiencia y entrenamiento de equipo tanto para el dominio de aplicación como
para los elementos de métodos que se están evaluando.
Modelo de costos: precio fijo, costo adicionado u otros.
Impacto del procedimiento de evaluación en sí (efecto “Heisenberg”).
Dado que los experimentos controlados son difíciles de realizar en el contexto de la industria,
usualmente tienen lugar en la academia usando estudiantes. La ventaja es que el experimentador
tiene un control mucho más afinado en los parámetros listados anteriormente y, más importante,
que es posible lograr algún grado de reproductibilidad y significancia estadística. La desventaja es
que, en general, los experimentos solo aplicarán para los elementos de métodos, planteando el
problema de la generalización a situaciones reales (escalabilidad) y que los estudiantes no son
necesariamente la representación de los ingenieros de software profesionales.
Ya que cada técnica –evaluación en proyectos reales y en un entorno académico- tienen ventajas y
limitaciones, una evaluación completamente convincente debería involucrar ambos: experimentos
controlados por investigadores, para obtener los conocimientos básicos; y la validación por medio
de algún proyecto industrial, para confirmar que esos conocimientos escalan al uso industrial real.
A5.3.2 Qué medir
El procedimiento de evaluación requiere una definición precisa de qué necesita medirse:
proyectos críticos y variables de desarrolladores, actividades, tiempo invertido para cada
actividad, defectos encontrados, productos de trabajo elaborados.
A5.3.3 Establecimiento de un sistema de evaluación
Para establecer una evaluación útil y efectiva se requiere la obtención del soporte de las dos
comunidades principalmente involucradas:
Debemos convencer a la comunidad de la ingeniería de software y a sus profesionales del
valor de evaluaciones objetivas y cuantitativas para los elementos de métodos y los artefactos
de la ingeniería de software (prácticas, patrones, métodos, herramientas).
Dada la importancia de los estudios académicos (5.3.1), debemos convencer a la comunidad
académica del valor de esta tarea y ayudar a los académicos a enseñar a sus estudiantes las
técnicas de recolección rigurosa de datos. También debemos asegurarnos de que el trabajo
resultante, que cae en el área general conocida como “ciencia de computación experimental”,
sea apropiadamente reconocido en la academia, de acuerdo con los criterios que le importan
a los académicos, en particular, la publicación. (Por ejemplo, las ciencias naturales tienen la
tradición de aceptar experimentos de reproductibilidad, donde un investigador confirma o
invalida un resultado previamente publicado, como digno de ser publicado, e incluso
potencialmente prestigioso. En general, las ciencias de la computación carecen de esta
tradición)