MTODO Y TEORA DE LA INGENIERA DE SOFTWARE DECLARACIN DE LA VISIN

Por Ivar, Bertrand y Richard

(Traducido por Leonardo Agudelo Marn y Luis Antonio Salazar Caraballo)
1

Propsito y alcance

El llamado a la accin original del Semat dio una definicin amplia del problema que la iniciativa Semat pretende enfrentar: Convocatoria a la accin Hoy en da la ingeniera de software est gravemente obstaculizada por prcticas inmaduras. Los problemas especficos incluyen: La prevalencia de tendencias que son ms comunes en la industria de la moda que en una disciplina ingenieril. La ausencia de unas bases tericas ampliamente aceptadas y difundidas. La gran cantidad de mtodos y variantes de mtodos, con diferencias poco entendidas y ampliadas de forma artificial. La carencia de evaluacin y validacin experimental creble. La divisin entre la prctica en la industria y la investigacin acadmica

Apoyamos un proceso para refundar la ingeniera de software basada en una teora slida, principios probados y mejores prcticas que: Incluyan un kernel (ncleo) de elementos ampliamente aceptados, extensibles para usos especficos. Tengan en cuenta tanto las cuestiones de tecnologa como de las personas. Sean soportadas por la industria, la academia, los investigadores y los usuarios. Soporten la extensin de cara a cambios en los requerimientos y en la tecnologa.

Para desarrollar soluciones apropiadas necesitamos un marco de trabajo ms preciso. La definicin de visin presente es ese marco de trabajo, similar a un documento de definicin de requisitos y a una hoja de ruta en el software, incluyendo la lista de objetivos para el primer ao.
1

Nota: Este documento fue traducido a partir de la publicacin oficial de la Declaracin de la Visin del SEMAT. El documento original en ingls puede encontrarse en http://www.semat.org/pub/Main/WebHome/SEMAT-vision.pdf

Los participantes en el esfuerzo vienen de muchos frentes de la profesin; se incluyen programadores profesionales, gerentes de proyecto, consultores y cientficos de la computacin. Esperamos discusiones intensas, ya que la intencin de la declaracin de la visin no es imponer una solucin particular. Sin embargo, para funcionar correctamente, el grupo necesita compartir una visin, 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 visin (seccin 2), los objetivos (seccin 3), las reglas (seccin 4), los principios (seccin 5) y los hitos para un ao (seccin 6). Puesto que se requiere ms detalle para entender completamente los cinco objetivos de la seccin 3, se dedic especficamente un apndice a cada uno de estos. Estos objetivos de largo alcance y los hitos para un ao de la seccin 6 son complementos indispensables el uno del otro: lograr cambios fundamentales, objetivo del Semat, tomar muchos aos; pero crear momentum requiere alcanzar resultados iniciales visibles en poco tiempo.

La visin
Alcanzar las metas, como se describe ms abajo y en los apndices. Crear una plataforma (kernel) permitindole a las personas describir sus prcticas, patrones y mtodos actuales y futuros, de modo que stos puedan ser compuestos, simulados, aplicados, comparados, evaluados, medidos, enseados e investigados.

La visin del Semat es doble:

El ncleo (kernel)

El llamado a la accin nos insta a ponernos de acuerdo en un kernel de elementos ampliamente aceptados, extensibles para usos especficos. Para ser efectivo el kernel debe permanecer concreto, enfocado y pequeo. El alcance del kernel se limita a los elementos descritos en esta seccin. En particular, el kernel no es un intento de una metodologa unificada. El foco de los esfuerzos del kernel es identificar y describir los elementos esenciales para todas las actividades de la ingeniera de software. Los ejemplos tpicos de lo que abarca el kernel son el trabajo en grupo, gestin de proyectos y mejoramiento del proceso. El kernel tambin integrar conceptos de otras disciplinas de la ingeniera.

El kernel debe acomodarse al cambio. La intencin en los primeros doce meses es identificar un kernel que capture los mtodos, prcticas y patrones de inters (Fig. 1) usados en la actualidad en la produccin de software y que puedan ser adaptados para evoluciones futuras de la disciplina. Nivel 3 Mtodos Compuesto de Definido en trminos de

Prcticas

Patrones

Aspectos universales

Lenguaje del kernel

El kernel

Figura 1: El diamante Semat El kernel debe incluir una representacin concreta de los actos y artefactos del desarrollo de software, aplicables a un rango amplio de proyectos de software. Tambin debe proveer un lenguaje de extensin para la adaptacin de mtodos, prcticas y patrones especficos. 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.). Prcticas y patrones (nivel 2), definidos en trminos del kernel. Mtodos, definidos como combinaciones de prcticas y patrones. (nivel 3).

El trmino patrn merece una definicin especfica. Se usa en el presente documento para denotar un modo general de operacin aplicado a travs de las prcticas. Por ejemplo, muchas prcticas involucran la organizacin de talleres, o confan en la auto-organizacin de los equipos. Al describir estos conceptos como patrones, evitamos repetir sus detalles en la descripcin de prcticas especficas.

Las Metas

El trabajo proceder a lo largo de cinco grupos de trabajo diferentes: 1. Definiciones: definen la ingeniera de software y otros conceptos esenciales de la disciplina. 2. Teora: identifican las teoras (en particular las provenientes de las matemticas) que proveen una ayuda esencial.

3. Aspectos universales: identifican los aspectos universales (para todos los casos) en la ingeniera de software, los cuales deben ser integrados en el kernel de Semat. 4. Lenguaje del kernel: definen el lenguaje para describir los aspectos universales, prcticas y patrones. 5. Evaluacin: tcnicas para evaluar las prcticas y teoras de la ingeniera de software, incluyendo los resultados de Semat. Todos los grupos deberan 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 ms rpidamente, 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 maraa de mtodos y a mejorar la enseanza de la ingeniera de software. Los apndices proponen algunas ideas iniciales para cada uno de los elementos.

Los principios

Dado que el modus operandi preciso del esfuerzo de Semat ser determinado al inicio del trabajo, un nmero 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. Teora. El kernel se fundamentar en bases tericas slidas y rigurosas. 4. Realismo y escalabilidad. El kernel ser aplicable por medio de proyectos prcticos, incluyendo proyectos grandes, y basado en tcnicas probadas siempre que sea posible. 5. Justificacin. Cada recomendacin debe ser justificada con un claro raciocinio. 6. Verificabilidad. Cada afirmacin deber ser objeto de evaluacin y refutacin experimental. 7. Perspectiva hacia el futuro. Teniendo en cuenta las elecciones metodolgicas de las generaciones previas, el kernel no deber estar obligado a ser totalmente compatible. 8. Modularidad. Las prcticas y patrones se definen usando el kernel, pueden ser combinadas y adaptadas para acomodarse a las necesidades de las organizaciones individuales.

NDT. La Declaracin de la Visin del SEMAT fue publicada en febrero de 2010

9. Auto-mejoramiento. El kernel deber acompaarse por mecanismos que permitan su propia evolucin. 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 debern ser evaluadas por sus mritos. Ningn aspecto deber ser realizado para favorecer los intereses de individuos o comunidades particulares. 12. Objetividad. Las ideas debern 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.

Hitos a un ao

Los resultados esperados un ao despus 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 definicin del trmino ingeniera de software y las definiciones de los conceptos fundamentales requeridos por las prcticas y los patrones. 6.2. La identificacin de teoras especficas o reas tericas potencialmente tiles para Semat, soportadas por ejemplos de su aplicacin exitosa a prcticas especficas de la ingeniera de software. 6.3. Un conjunto de aspectos universales y una demostracin de que estos pueden ser validados contra unas pocas prcticas especficas usadas por mtodos importantes, incluyendo como mnimo uno no usado en el desarrollo de los aspectos universales. 6.4. La definicin de un lenguaje de kernel y su uso exitoso para describir los aspectos universales en 6.3 y su composicin, tal como se aplic a los mtodos seleccionados en 6.3. 6.5. Un conjunto de mtricas, suficiente para evaluar las prcticas del software, los productos y las personas, y soportada por la evidencia de su aplicacin exitosa en algunos proyectos.

NDT. La Declaracin de la Visin del SEMAT fue publicada en febrero de 2010

Apndices
Los cinco apndices detallan los cinco objetivos de la definicin de la visin: Definiciones, Teora, Aspectos universales, Lenguaje del kernel y Evaluacin.

Apndice 1: Definiciones
Muchos debates tcnicos involucran tanto terminologa 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 ingeniera de software? Un buen punto de inicio y ejemplo representativo ser la definicin de ingeniera de software. La definicin obvia (la ingeniera de software es la disciplina y la aplicacin de mtodos de ingeniera para el campo del software) es insuficiente para algunas personas, bien porque sienten que ingeniera en general no est bien definida o porque falta una descripcin de cmo la aplicacin al software afecta la definicin bsica. En el otro extremo, Wikipedia tiene una larga definicin, tomada del SWEBOK, el cuerpo de conocimiento de la ingeniera del software (la ingeniera del software es el estudio y la aplicacin de enfoques sistemticos, disciplinados y cuantificables al desarrollo, operacin y mantenimiento del software; esto es, la aplicacin de la ingeniera al software). Esta definicin es decepcionante: la lista de adjetivos es redundante (disciplinado agrega poco a sistemtico); la lista de actividades es arbitraria (por qu operacin y no, por ejemplo, documentacin?); y el final esto es cuestiona la utilidad de todo lo que lo precede. Ha habido mucha discusin en el blog de Semat acerca de la definicin del trmino ingeniera del software. Un resumen de las posiciones: La ingeniera de software es una disciplina que requiere estudio formal, experiencia, respeto, creatividad y disciplina (ver esta pieza irnica en http://parijatmishra.wordpress.com/2010/01/08/188/). La definicin de SWEBOK como se mencion ms arriba, usada por la Wikipedia. El Consejo Americano de Ingenieros para el Desarrollo Profesional define "ingeniera" como la aplicacin creativa de los principios cientficos para disear o desarrollar estructuras, mquinas, aparatos o procesos de manufactura, o que trabaja usndolas individualmente o en combinacin; o para construirlas u operarlas con el completo conocimiento de su diseo; o para predecir su comportamiento bajo condiciones operativas especficas en lo que respecta a una funcin deseada, operacin econmica 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 ingeniera de software) Un signatario critic las definiciones dadas antes, sobre la base de que la ingeniera de software debera integrar habilidades, juegos cooperativos, procesos y diseo flexibles, as como adquisicin de conocimiento (ver http://alistair.cockburn.us/The+end+of+software+engineering+and+the+start+of+econom ic-cooperative+gaming)

Quizs estas definiciones no estn tan apartadas; todas comparten la idea general de aplicar conocimiento cientfico 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 Ms all de la definicin bsica Junto con otros pocos conceptos fundamentales, la definicin de ingeniera de software, o una primera versin de esta, es parte de las metas iniciales a doce meses (seccin 6). Estos trminos son solo un punto de partida y no es realista esperar el resto del trabajo de Semat, en particular la definicin del kernel, para la adopcin de definiciones finales de todos los conceptos involucrados en los componentes de Semat: mtodos, prcticas, patrones, aspectos universales y el lenguaje del kernel. El proceso de definicin ser continuo e iterativo, extendiendo y refinando el repositorio de definiciones de Semat.

Apndice 2: Teora
Una de las definiciones de ingeniera es que es la construccin de artefactos basada en principios cientficos y finalmente en las matemticas. La ingeniera de software no debera ser la excepcin. Una fuerte base matemtica es esencial para el esfuerzo del Semat. Una base terica considerable est disponible para la ingeniera del software. Una parte consiste en teoras matemticas existentes, ampliamente utilizadas sin cambios; por ejemplo muchas reas de la ingeniera de software hacen un buen uso de la probabilidad, las estadsticas y teoras de colas (y prominentes investigadores repiten que deberamos usar mucho ms estas teoras). Otro ejemplo es la teora de categoras, la cual sirvi como inspiracin para los tipos de datos abstractos y la programacin orientada a objetos (aunque pocos desarrolladores O-O lo saben). En otros casos las aplicaciones de software han impulsado el desarrollo de nuevas teoras o un mayor desarrollo de las que existen; los ejemplos incluyen la lgica, donde gran parte del impulso en las ltimas dcadas proviene de la necesidad de lenguajes de programacin, teoras de autmatas y nuevos desarrollos como la verificacin de modelos y la interpretacin abstracta. La ingeniera de software no se trata solo de tecnologa, sino tambin de organizacin, gestin, comunicacin, colaboracin y otras facetas del software donde los puntos de vista pueden venir de disciplinas como la economa, la sociologa y la psicologa. La ingeniera de software necesita tambin de teoras de estas reas para soportar el desarrollo de mtodos, prcticas, patrones y aspectos universales. El abismo entre los profesionales y los acadmicos es ms pronunciado en el software que en otras disciplinas de la ingeniera. Mientras que es difcil imaginar a un ingeniero elctrico asegurando que las ecuaciones de Maxwell son un ejercicio puramente acadmico irrelevante para los profesionales, en los ingenieros de software y gerentes de proyectos es comn escuchar este tipo de comentarios acerca de las contribuciones tericas (como las tcnicas de verificacin formal) que son tan importantes en su campo. Con frecuencia, los profesionales ni siquiera han odo hablar de dichas tcnicas. Los acadmicos no estn enteramente libres de culpa: algunos investigadores se han concentrado en problemas que suponen cambios cientficos, pero que son difciles de relacionar con las preocupaciones de la industria. La interaccin entre los dos campos ha mejorado en aos recientes. Los mtodos formales, por ejemplo, son cada vez ms usados (a menudo en una forma disfrazada) en muchas reas de tecnologas de la informacin. Una de las metas de Semat es asegurarse de que la ingeniera de software crezca al nivel de otras disciplinas y, sin remover enteramente las diferencias (una meta que no es deseable, ya que la investigacin y la aplicacin no tienen roles idnticos), establecer una relacin sana entre la teora y la prctica del software. La misin del grupo de trabajo de Teora es avanzar en esta meta. Esto incluye en el primer paso, las siguientes tareas:

1. Identificar las reas de la ingeniera de software que ms necesitan teoras (y todava no estn basadas en una teora vlida en los modos dominantes de operacin de la profesin). 2. Entre otras teoras que han sido aplicadas al software pero solo por una minora de proyectos, identificar aquellas que presentan el potencial ms alto de aplicacin de beneficio generalizado. 3. Entre las reas identificadas en la tarea 1, identificar aquellas para las que no hay teora disponible todava. 4. Identificar los componentes del esfuerzo del Semat que requerirn de un soporte terico especfico. En particular, definir la clase de teora requerida para proveer el lenguaje del kernel (apndice 4) con una teora bien definida. Estas cuatro metas parecen ser alcanzables en un plazo fijado a un ao para las etapas iniciales del proyecto Semat. El segundo paso involucra: 5. Desarrollar una Lista de Teoras Aplicables a la Ingeniera del Software (ROAST), suministrando una lista de teoras tiles existentes (segn se establece en el punto 2) y, para cada una de stas, una gua detallada para su aplicacin a proyectos actuales. 6. Desarrollar la teora para el lenguaje del kernel (ver el punto 4). 7. Elegir un pequeo nmero (probablemente no ms de tres, y posiblemente tan pequeo como uno) de teoras que necesiten ser desarrolladas y establecer las condiciones para su desarrollo, as como, si es posible, los elementos bsicos de estas teoras.

Apndice 3: Aspectos universales4

Mantener el kernel concreto, enfocado y pequeo requiere identificar los reales aspectos universales de la ingeniera de software. Mientras parece haber un consenso general acerca de la existencia de estos elementos, esenciales para todos los esfuerzos en ingeniera de software, aparentemente permanece mucha confusin acerca de lo que son y de cmo evaluamos lo que es realmente esencial (una condicin 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 caractersticas candidatas que consideramos integrales para cualquier kernel exitoso: Conciso. El kernel debe enfocarse nicamente en el pequeo conjunto de elementos que son realmente esenciales. Escalable. El alcance del kernel debe extenderse desde los proyectos ms pequeos hasta los sistemas ms grandes y a los sistemas de sistemas. Extensible. El kernel debe proporcionar la habilidad para aadir prcticas, patrones, niveles de detalle y modelos de ciclo de vida. Debe apoyar la adaptacin a dominios especficos de aplicacin y a proyectos que involucran ms 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 matemticamente. La definicin debe ser desarrollada junto con el kernel en s, no debe ser pospuesta a posteriores esfuerzos hipotticos. Esta meta debe llevarse a cabo en cooperacin con el punto de Teora. Cubrimiento amplio de prcticas. El kernel debe soportar muchas prcticas 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 tecnologa. El kernel debe ser adaptable a un amplio rango de tecnologas de software (lenguajes de programacin, lenguajes de especificacin, notaciones grficas, 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 dems esfuerzos de Semat al trabajo prctico de los ingenieros de software. Proveer un marco de trabajo concreto que ellos pueden utilizar en cualquier proyecto, permitindoles identificar y aplicar las prcticas que necesitan para ser exitosos en su contexto particular. A3.3 Criterios para la inclusin Las reglas bsicas que caracterizan los elementos que merecen ser incluidos son las siguientes:
4

Escrito con la colaboracin de Ian Spence

Universal: potencialmente aplicable a todos los esfuerzos de la ingeniera 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 aplicacin de todos los ingenieros de software, independiente de su origen y campo metodolgico (si lo tiene). Definido con precisin. Accionable: no solo palabras y conceptos, sino guas precisas que los proyectos puedan aplicar. Evaluable: adecuado para la evaluacin de su aplicacin. Integral. Este criterio aplica para la coleccin de elementos del kernel; juntos deben capturar la esencia de la ingeniera de software, proveyendo un mapa que soporte las prcticas cruciales, patrones y mtodos de los equipos de ingeniera 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 nmero de aspectos universales candidatos han sido identificados. Ac hay una corta discusin de algunos ejemplos. Algunos contribuyentes han sugerido que un aspecto universal de cualquier esfuerzo de ingeniera 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 prcticas 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 prcticas ms populares y desafiar nuestra definicin de ingeniera de software. Otros contribuidores han sugerido largas listas de aspectos universales incluyendo elementos como: Proyecto Equipo Experiencia de usuario Sistema Calidad Intencin

Son todos estos realmente aspectos universales? Son realmente esenciales para la ingeniera de software? Estn en el mismo nivel conceptual (los mismos tipos de cosas)? Se relacionan con cada uno de los otros y si es as, cmo se relacionan?

La meta de la tarea del kernel es producir un modelo concreto de ingeniera del software respondiendo a todas estas preguntas, y proveyendo las bases para la definicin, evaluacin y mejoramiento de las prcticas, patrones y mtodos que nos permitirn profesionalizar la comunidad de la ingeniera de software.

Apndice 4: Lenguaje del Kernel

Dado que la reflexin sobre el lenguaje del ncleo se encuentra en una etapa temprana, este apndice 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 brindarn una extensa experiencia con elementos de mtodos (un trmino usado en este apndice para denotar mtodos, patrones y prcticas), para asegurar que el lenguaje del kernel pueda cubrir las necesidades de los usuarios. Otros brindarn experticia en el diseo de lenguajes.

Las dos secciones de este apndice se refieren correspondientemente al uso del lenguaje del kernel y a su diseo.

A4.1 Uso del lenguaje del Kernel El rol del lenguaje del kernel es describir prcticas y patrones, y su composicin en mtodos. La palabra descripcin tal como se usa en esta seccin denota una clase de descripcin de un elemento de un mtodo (en el sentido anterior), expresada en el lenguaje del kernel. Los principales usuarios del lenguaje del kernel son los proyectos que estn buscando elementos de mtodo apropiados y los proyectos que estn aplicando los elementos de mtodo 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 prcticas y patrones relevantes, y su composicin, en los mtodos actuales. Soporta la composicin de stos en diferentes maneras para describir nuevos elementos de mtodo. Es extensible, permitiendo la descripcin de elementos de mtodos an no inventados, as como sus elementos (tales como las prcticas individuales). Las descripciones deben ser fciles de entender; el lenguaje debe disearse para la comunidad de desarrolladores (no solo para ingenieros de procesos y acadmicos). El lenguaje soporta la comparacin de elementos de mtodos (una tarea muy compleja actualmente) Las descripciones se construyen en trminos de aspectos universales identificados en el esfuerzo de Semat (ver el apndice A.3), colaborando con uno de los objetivos principales del Semat: abolir la reinvencin de prcticas, patrones y mtodos.

El lenguaje y la descripcin resultantes soportan la simulacin de la aplicacin de los elementos de mtodos. Soportan la aplicacin de estos elementos de mtodo en proyectos reales. Proveen mecanismos de validacin, as que es posible evaluar cuando un proyecto que busca aplicar un elemento de mtodo (como se describe a travs 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 organizacin de equipos: cada equipo debe proveer recursos apropiados para evaluar el desempeo actual del proyecto para los elementos de mtodo elegidos, tal como se describe en el lenguaje del kernel.

A4.2 Diseo del lenguaje del kernel A pesar de que no existe un diseo preliminar para el lenguaje del kernel, se han identificado los siguientes requisitos para su diseo. Como cualquier otro lenguaje definido precisamente, el lenguaje del kernel tendr una sintaxis abstracta, reglas de validacin (semntica esttica) y semntica. Deber tener al menos una sintaxis concreta, pero puede llegar a tener muchas, por ejemplo una forma textual y una forma grfica. El lenguaje del kernel prestar apoyo a cuatro aplicaciones principales: Descripcin de aspectos universales: prcticas y patrones, los cuales son los bloques de la construccin, y los mecanismos de composicin para construir los mtodos de estos elementos. Simulacin. La aplicacin de las descripciones resultantes a un proyecto Aplicacin de las descripciones para un cierre de brecha real. Evaluacin de una simulacin o aplicacin para los elementos de mtodo elegidos.

El concepto de estado juega un rol importante en el lenguaje del kernel para representar el progreso del trabajo. Por ejemplo, la descripcin de una prctica que involucre desarrollo iterativo requiere la descripcin de estados de inicio y finalizacin de cada iteracin. El lenguaje del kernel debe ser extensible; en particular, debe permitir la adicin o modificaciones de prcticas, patrones y posiblemente tcnicas de composicin. Las siguientes reglas aplican para las prcticas: Una prctica es un problema aparte de un mtodo. Algunos ejemplos son: el desarrollo de requisitos para probar, desarrollo iterativo, desarrollo basado en componentes. Cada prctica debe describirse por s misma, aparte de cualquier otra prctica.

Cada prctica, a menos de que est definida como una actividad continua, tiene un inicio y fin claros. Cada prctica aporta valor a sus interesados. Cada prctica debe ser evaluable; su descripcin debe incluir criterios para su evaluacin. Donde se pueda aplicar, los criterios de evaluacin deben incluir elementos cuantitativos; correspondientemente, la descripcin debe incluir sistemas de medicin adecuados. Los mecanismos de composicin para prcticas incluyen fusin y extensin.

Las siguientes reglas aplican para los patrones: Cada patrn (por su definicin en la seccin 3) debe ser aplicable a muchas prcticas diferentes. Cada patrn debe describirse por s mismo, aparte de cualquier otro patrn y de cualquier prctica para la que este aplique.

Apndice 5: Evaluacin

El establecimiento de unas bases firmes para la ingeniera de software requiere un modo sistemtico de evaluar prcticas, patrones, mtodos (todos juntos llamados elementos de mtodo en este apndice) y las herramientas de soporte sobre la base de criterios objetivos. Como en otras disciplinas de ingeniera, estos criterios deben ser cuantitativos; deben aplicar teoras bien definidas (ver apndice 2) y deben basarse en datos estadsticos slidos. Las preguntas fundamentales, tratadas en las tres secciones de este apndice, son: Cules son los objetivos de los elementos de mtodo evaluados? Cul es el criterio para juzgar su calidad? Cul debe ser el proceso de medicin?

A5.1 Objetivos de la evaluacin Una vez hemos definido el kernel, en particular los elementos del mtodo relevantes (en el sentido expuesto anteriormente), debemos dar a los usuarios criterios objetivos para evaluar si estos elementos les ayudan con sus tareas. Esta observacin plantea dos preguntas: Quines son los usuarios y cules son sus tareas previstas? Las categoras de usuario de mayor relevancia directa, son: Profesionales del software (ingenieros y administradores), quienes son pragmticos y usarn cualquier elemento de mtodo que encuentren disponible y sea fcil de usar. Sus clientes, que estn generalmente preocupados por tener software con calidad, rpido, a bajo costo y de un modo predecible. Acadmicos, que ensean o investigan ingeniera de software.

Todas estas categoras 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 sern objeto de evaluacin incluyen todas las tareas importantes de la ingeniera de software: tanto tareas tcnicas (desde el anlisis hasta el diseo, implementacin, documentacin, verificacin y validacin, despliegue, operacin entre otras) y tareas centradas en los humanos tales como administracin, entrenamiento, soporte y comunicacin.

A5.2 Evaluacin de la calidad El mtodo de evaluacin debe ser aplicable a cualquier prctica y debe considerar todas sus propiedades importantes:

Escrito con la colaboracin de Watts Humprey

Funcionalidad: La descripcin del elemento del mtodo hace posible medir la cobertura de la funcionalidad prevista? Usabilidad: cmo se mide la usabilidad? Algunas tcnicas posibles involucran un laboratorio de usabilidad si est disponible, si no lo hay, se usan encuestas de usuario. Estas encuestas deben ser definidas con precisin y deben ser repetibles de manera que una variedad de situaciones de usuario puedan ser medidas y se obtengan datos objetivos y estadsticamente tiles a partir de mltiples fuentes. Confiabilidad: El elemento del mtodo siempre produce los resultados esperados o hay variables de proyecto involucradas? y cules son estas variables, su probabilidad e impacto? Eficiencia: esta medida de productividad requiere datos acerca del tiempo invertido por uno o ms ingenieros de software en la aplicacin del elemento de mtodo, as como el volumen de los productos de trabajo obtenidos. Extensibilidad: este es un principio de diseo de sistemas donde la implementacin tiene en cuenta el crecimiento futuro. Es una medida sistemtica de la habilidad para extender un sistema y el nivel de esfuerzo requerido para implementar dicha extensin. Las extensiones pueden realizarse por medio de adiciones de nuevas funcionalidades o a travs de modificaciones a funcionalidades existentes. El elemento del mtodo soporta el tema de proveer cambios con un impacto mnimo a funciones de sistema existentes? Reusabilidad: aqu hay cuatro tipos de criterios cuantitativos: reutilizar modelos de costobeneficio incluye anlisis de costo-beneficio econmico as como calidad y rentabilidad de la productividad. Las mtricas de cantidad de reutilizacin sirven para medir y monitorear un esfuerzo de mejora de reusabilidad, rastreando porcentajes de reutilizacin de objetos del ciclo de vida; las mtricas de reusabilidad indican la probabilidad con la que un artefacto es reutilizable; las mtricas de reutilizacin de bibliotecas se usan para gestionar y rastrear el uso de un repositorio de reutilizacin.

A5.3 Proceso de evaluacin La definicin de un proceso de evaluacin involucra tres aspectos: cmo elegir los proyectos para evaluar los elementos del mtodo; qu propiedades se deben medir y la organizacin del proceso. Las siguientes subsecciones examinan estos asuntos. A5.3.1 Eleccin de proyectos de ejemplo Para evaluar las prcticas y otros elementos del mtodo, se puede elegir un proyecto de software industrial o unas pruebas controladas en un entorno experimental, por ejemplo con estudiantes. Ninguna tcnica es totalmente satisfactoria. Los proyectos de la industria tienen dos grandes ventajas: tamao (difcil de igualar en un contexto acadmico) y realismo (ya que la intencin es que se usen realmente). Estos, sin embargo, enfrentan dos limitaciones principales. Primero, tpicamente no soportan la reproductibilidad: el tamao de un proyecto industrial y su impacto econmico implica que ser generalmente un esfuerzo de una sola vez, produciendo un conjunto de puntos de datos aislados con valor

estadstico cuestionable. Este problema puede ser superado recolectando datos de evaluaciones de muchos proyectos en un contexto consistente, por ejemplo, proyectos de una misma compaa, en la misma rea general. La otra limitacin es que en un proyecto industrial muchos parmetros son establecidos por el contexto y ms all del control del procedimiento de evaluacin: Producto nuevo frente a la modificacin 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 aplicacin como para los elementos de mtodos que se estn evaluando. Modelo de costos: precio fijo, costo adicionado u otros. Impacto del procedimiento de evaluacin en s (efecto Heisenberg).

Dado que los experimentos controlados son difciles 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 ms afinado en los parmetros listados anteriormente y, ms importante, que es posible lograr algn grado de reproductibilidad y significancia estadstica. La desventaja es que, en general, los experimentos solo aplicarn para los elementos de mtodos, planteando el problema de la generalizacin a situaciones reales (escalabilidad) y que los estudiantes no son necesariamente la representacin de los ingenieros de software profesionales. Ya que cada tcnica evaluacin en proyectos reales y en un entorno acadmico- tienen ventajas y limitaciones, una evaluacin completamente convincente debera involucrar ambos: experimentos controlados por investigadores, para obtener los conocimientos bsicos; y la validacin por medio de algn proyecto industrial, para confirmar que esos conocimientos escalan al uso industrial real. A5.3.2 Qu medir El procedimiento de evaluacin requiere una definicin precisa de qu necesita medirse: proyectos crticos y variables de desarrolladores, actividades, tiempo invertido para cada actividad, defectos encontrados, productos de trabajo elaborados. A5.3.3 Establecimiento de un sistema de evaluacin Para establecer una evaluacin til y efectiva se requiere la obtencin del soporte de las dos comunidades principalmente involucradas: Debemos convencer a la comunidad de la ingeniera de software y a sus profesionales del valor de evaluaciones objetivas y cuantitativas para los elementos de mtodos y los artefactos de la ingeniera de software (prcticas, patrones, mtodos, herramientas). Dada la importancia de los estudios acadmicos (5.3.1), debemos convencer a la comunidad acadmica del valor de esta tarea y ayudar a los acadmicos a ensear a sus estudiantes las tcnicas de recoleccin rigurosa de datos. Tambin debemos asegurarnos de que el trabajo resultante, que cae en el rea general conocida como ciencia de computacin experimental,

sea apropiadamente reconocido en la academia, de acuerdo con los criterios que le importan a los acadmicos, en particular, la publicacin. (Por ejemplo, las ciencias naturales tienen la tradicin 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 computacin carecen de esta tradicin)