You are on page 1of 4

Analisis comparativo de la Guias SWEBOK 2004 y

2014
A. Gordillo, D. Lopez, R. Lopez.

ResumenLa evolucion del cuerpo de conocimiento para la


Ingeniera de Software fue prevista desde el inicio del proyecto.
Desde el lanzamiento de la version trial.en 1999, la Gua SWEBOK se ha convertido en una importante referencia en el mundo
de la Ingeniera de Software. La version 2004 [1]de SWEBOK
plantea 10 a reas de conocimiento que han evolucionado y se han
constituido en 15 a reas en la version 3 (2014) [2]. El documento
presenta un breve analisis de los mas importantes cambios y su
impacto en la Ingeniera de Software
Index TermsSWEBOK, ingeniera de software, comparativa,
analisis, versiones.

I.

I NTRODUCCI ON

a Gua SWEBOK es un documento creado por la Software Engineering Coordinating Committee, promovido
por la IEEE Computer Society, que se define como una gua
al conocimiento en el a rea de la Ingeniera del Software.
Representa un amplio consenso respecto a los contenidos de
la disciplina y aporta de manera importante al desarrollo de
la misma.
Cada una de las a reas de conocimiento en la Gua de
SWEBOK ha sido desarrollada por expertos de dominio y se
han sometido a una serie de ciclos de revision y pasos de consecucion de consenso dentro de la comunidad internacional.
Este trabajo investiga las diferencias mas notables entre la
gua de referencia SWEBOK 2004 y la denominada SWEBOK
V3.
II.

III.

REAS DE C ONOCIMIENTO
A

Los captulos de la gua SWEBOK dividen a la disciplina


de la ingenierpia de software en a reas de conocimiento. El
cuadro 1 muestra las a reas de conocimiento de la edicion
SWEBOK V3 y se destacan las 5 a reas anadidas desde la
version SWEBOK 2004.
SWEBOK 2004
Requisitos
Diseno
Construccion
Pruebas
Mantenimiento
Gestion de la configuracion
Gestion de la Ingeniera
de Software
Proceso de Ingeniera de
Software
Herramientas y metodos
Calidad del Software
-

SWEBOK V3
Requisitos
Diseno
Construccion
Pruebas
Mantenimiento
Gestion de la configuracion
Gestion de la Ingeniera
de Software
Proceso de Ingeniera de
Software
Herramientas y metodos
Calidad del Software
Practica Profesional de la
Ingeniera de Software
Economa de la Ingeniera
de Software
Fundamentos de Computacion
Fundamentos
Matematicos
Fundamentos de la Ingeniera
Cuadro I
REAS DE CONOMIMIENTO EN LAS 2 VERSIONES DE SWEBOK
A

O BJETIVOS DE SWEBOK

La Gua del Cuerpo de Conocimientos de la Ingeniera


de Software (Gua SWEBOK) se ha desarrollado con los
siguientes objetivos:
1. Para caracterizar los contenidos de la disciplina de la
ingeniera de software;
2. Promover una vision consistente de la ingeniera de
software en todo el mundo;
3. Proporcionar un facil acceso mediante las tematicas al
cuerpo de conocimiento de la ingeniera de software;
4. Para clarificar la posicion y establecer el lmite de la
ingeniera de software con respecto a otras disciplinas;
5. Proporcionar una base para su desarrollo curricular y la
creacion de material de certificacion [1].
Analisis Comparativo
A. Gordillo, Universidad Tecnica del Norte, Ibarra, Ecuador, alexacg@gmail.com
D. Lopez, Universidad Tecnica del Norte, Ibarra, danielopezh@gmail.com
R.
Lopez,
Universidad
Tecnica
del
Norte,
Ibarra,
e.roberto.lopez@gmail.com

IV.

D ISCIPLINAS R ELACIONADAS

Con el fin de circunscribir la ingeniera de software, SWEBOK identifica las disciplinas con las que la ingeniera de
software comparte una frontera comun. Las disciplinas relacionadas tambien comparten muchas fronteras comunes entre
ellas.
Las disciplinas relacionadas son las siguientes:
Ingeniera de Computadores
Ciencia de la Computacion
Gestion
Matematicas
Gestion de Proyectos
Gestion de la Calidad
Ergonoma del Software (se elimina en SWEBOK V3)
Ingeniera de Sistemas
incluye Sistemas de Informacion

V.

DE S OFTWARE
C ONSTRUCCI ON

Se refiere en detalle a la creacion de software a traves de


la combinacion de codificacion, verificacion, pruebas unitarias,
pruebas de integracion y depuracion. Esta a rea de conocimiento KA se encuentra enlazada con todas las demas, pero aun
mas fuertemente con el Diseno y Pruebas de software ya que
esta a rea implica tambien diseno y pruebas. As la relacion es:
Produce un alto numero de objetos de configuracion
Software Configuration Management KA
Codigo (ultimo elemento de entrega en un proyecto)
Calidad de software (todas las KA)
Conocimiento de algoritmos y practicas de codificacion
Computing Foundations KA
V-A.

V-B0d. Reuso: Es necesario formalizar la practica de


creacion de software reusable incluyendolo en el proceso y
actividades del ciclo de vida del software. Se establecen las
siguientes actividades:
SWEBOK 2004
Seleccion de unidades reusables.
Evaluacion del codigo reusable.
Reportar la informacion del codigo
reusable, procedimientos o datos de
prueba.

Fundamentos de la construccion de Software

Los fundamentos para la construccion de software incluyen:


V-A0a. Reuso: La version 3 incluye dentro de los
fundamentos de la construccion del software la reutilizacion
del software. La reutilizacion se refiere a la utilizacion de los
activos existentes (bibliotecas, modulos, componentes, codigo
fuente, y comercial) en la solucion de diferentes problemas.
Esto permite lograr una productividad significativa de software, mejorar la calidad y los costos.
V-A0b. Estandares de contruccion: SWEBOK V3 incluye convenciones para la construccion de software.
SWEBOK 2004
Metodos de comunicacion(estandares)
Lenguages de programacion
Plataformas
Herramientas(Estandares de diagramacion, UML)

SWEBOK V3
Incluye:
Estandares de codificacion(convenciones)

Cuadro II

DE S OFTWARE
C UADRO COMPARATIVO E ST ANDARES
DE C ONSTRUCCI ON

V-B.

Cuadro IV
C UADRO COMPARATIVO R EUSO

Consideraciones Practicas

El desarrollo del software se ve afectado por muchas


limitaciones del mundo real que pueden llegar a ser caoticas,
estas restricciones pueden ser manejadas con las siguientes
consideraciones practicas:
V-B0c. Codificacion: Las diferencias se indican en el
cuadro III.
SWEBOK 2004
Consideraciones:
Uso de tecnicas para crear codigo
comprensible.
Uso de clases, tipos enumerados,
variables, etc.
Uso de estructuras de control.
Manejo de condiciones de error.
Prevencion de violaciones de seguridad a nivel de codigo.
Uso de mecanismos de exclusion y
disciplina en el acceso a recursos

SWEBOK V3
La Version 3 analiza un
poco mas a detalle esta
practica y la divide en dos:
- Construccion para reutilizacion: Se refiere a
la construccion del software para ser reutilizado,
generalmente encapsulado
en libreras o componentes bien estructurados. Se
establece las siguientes tareas:
Utilizacion
de
mecanismos como
parametrizacion.
Patrones de diseno,
etc.
Encapsulamiento
Pruebas del codigo
reusable
Descipcion y publicacion
-Construccion con reutilizacion: Se refiere a la
creacion de nuevo software con la reutilizacion de
software existente, como
libreras de codigo abierto.
Se establecen las siguientes tareas:
Seleccion de la unidad reusable
Evaluacion
del
codigo
Integracion del software reusable
Reporte de la informacion reusada

SWEBOK V3
Agrega:
Organizacion de codigo
fuente
Documentacion del codigo
Afinacion de codigo

Cuadro III

C UADRO COMPARATIVO C ODIFICACI ON

V-B0e. Integracion: Una parte clave de proceso de


construccion es la integracion de las clases, componentes, rutinas, subsistemas que han sido construidos por separado, sobre
todo si hay implicaciones tecnicas de software o hardware. La
version 3 establece 2 formas de integracion de software que
se muestran en el cuadro V.

V-C.

Gestion de la Construccion

Procedimientos para medir la eficiencia del codigo fuente: extension, reutilizacion, codigo destruido, complejidad,
estadsticas de inspeccion del codigo, tasa de rectificacion
y correccion de errores y los horarios. La medicion de la
construccion del software permite asegurar la calidad del
mismo.
V-C0f. Construccion en Modelos de Ciclo de Vida: El
cuadro VI muestra las principales diferencias relacionadas con
la construccion en ciclos de vida de software.

SWEBOK 2004
Una parte clave de proceso de
construccion es la integracion de
las clases, componentes, rutinas,
subsistemas que han sido construidos por separado, sobre todo si hay
implicaciones tecnicas de software
o hardware.

SWEBOK V3
Indica ademas que la integracion del software puede ser de dos formas:
- Por fases: Retrasa la integracion hasta que todas
las piezas destinadas a la
liberacion esten completas.
- Incremental: Se escribe,
prueba e integra cada pieza de software a la vez.
Se cree que este tipo de
integracion permite la deteccion temprana de errores, mejora el monitoreo
del progreso, la entrega
del producto anterior y las
relaciones con los clientes.

Cuadro V

C UADRO COMPARATIVO I NTEGRACI ON


SWEBOK 2004
Establece que exiten numerosos
modelos de desarrollo de software.
Identifica modelos lineales como
metodologa en cascada que tienden a enfatizar en actividades que
preceden a la construccion, como
requerimientos y diseno. Nombra
modelos a giles como mas iterativos que enfatizan la construccion.
(SCRUM, XP)

SWEBOK V3
Generaliza los modelos a giles como
modelos iterativos.
Agrega Prototipado
evolutivo
Enfatiza que la contruccion no solo es
codificar y depurar

Cuadro VI
EN C ICLOS DE V IDA DE
C UADRO COMPARATIVO C ONSTRUCCI ON
S OFTWARE

V-D.

Tecnologas de Construccion
SWEBOK V3 agrega al a rea de conocimiento de Construccion el topico de Tecnologas para la Construccion de
Software.
V-D0g. Diseno y Uso de API: Se trata de un conjunto
funcionalidades expuestas como libreras que permiten la
construccion de aplicaciones propias. Debe tratar de ofrecer:
Facilidad de aprendizaje o memorizacion
Legible, seguro, extensible, completo y mantener compatibilidad hacia atras
Proveerse a traves de libreras o frameworks(Construccion con reuso)
V-D0h. Consideraciones de Entornos de Tiempo de
Ejecucion Orientados a Objetos: Los lenguajes orientados a
objetos proporcionan una serie de mecanismos de tiempo de
ejecucion tales como el polimorfismo y la reflexion, lo cual
proporciona flexibilidad y adaptabilidad.
Polimorfismo, propiedad por la que es posible enviar
mensajes sintacticamente iguales a objetos de tipos distintos.
Reflexion, capacidad de un objeto de observar y modificar su propia estructura y comportamiento.
V-D0i. Parametrizacion y Generalizacion: Conocidos
como genericos o plantillas, permite la definicion de tipos en
base a la asignacion que se realice en el punto de uso. Los tipos
parametrizados (tipos no especificados) permiten una tercera

forma de agregar comportamientos en el software orientado a


objetos.
V-D0j. Aserciones, Diseno por Contrato y Programacion Defensiva: Una afirmacion/asercion es un predicado
ejecutable que permite realizar comprobaciones en tiempo
de ejecucion de un programa. Permite a los programadores
eliminar errores en suposiciones al cambiar el codigo.
El diseno por contrato, es un enfoque de desarrollo en el
cual se incluye las pre/post condiciones para cada rutina, lo
cual provee de una precisa especificacion de la semantica de
la rutina y una mejora en el aseguramiento de calidad en la
construccion de software.
La programacion defensiva significa la proteccion del fallo
de una rutina debido a ingresos invalidos.
V-D0k. Manejo de Errores, Manejo de Excepciones y
Tolerancia a Fallos: La forma en que se realiza el manejo de
errores, afecta los aspectos del software relacionados con los
requerimientos no funcionales.
Las excepciones son usadas para la deteccion y proceso
de errores cuando ocurre un evento excepcional. (bloques trycatch)
Tolerancia a fallos, es una coleccion de tecnicas que incrementa la confiabilidad del software al detectar errores y
recuperarse si es posible. Estrategias comunes: respaldo y reintento.
V-D0l. Modelos Ejecutables: Los modelos ejecutables,
permiten abstraer los detalles especficos de los lenguajes
de programacion. A diferencia de los modelos tradicionales
de software, un especificacion construida en un lenguaje de
modelado ejecutable puede ser desplegado en varios ambientes
de software sin cambios.
Estos modelos son la base de la arquitectura dirigida por
el modelo y son una forma completa de especificacion de un
modelo independiente de la plataforma (PIM, no se basa en
ninguna tecnologa de implementacion).
V-D0m. Tecnicas de Construccion Basadas en Estado y
Dirigidas por Tablas: La programacion basada en estados, usa
las maquinas de estado finito para describir el comportamiento
de un programa. La idea principal es la construccion de
programas de la misma manera en que la automatizacion
tecnologica de procesos se realiza. Usualmente se relaciona
con la programacion orientada a objetos
El metodo dirigido por tablas, usa tablas para buscar informacion en lugar de declaraciones logicas (If-Case), este
metodo tiene dos cincuentones: que informacion almacenar
en las tablas y como acceder eficientemente a la informacion
de esas tablas.
La programacion basada en estados, usa las maquinas de
estado finito para describir el comportamiento de un programa.
La idea principal es la construccion de programas de la misma
manera en que la automatizacion tecnologica de procesos se
realiza. Usualmente se relaciona con la programacion orientada a objetos
El metodo dirigido por tablas, usa tablas para buscar informacion en lugar de declaraciones logicas (If-Case), este
metodo tiene dos cincuentones: que informacion almacenar
en las tablas y como acceder eficientemente a la informacion
de esas tablas.

V-D0n. Configuracion de Tiempo de Ejecucion e Internacionalizacion: La tecnica de configuracion en tiempo de


ejecucion, enlaza el valor de las variables con la configuracion
del programa cuando este se ejecuta.
La tecnica de internacionalizacion, permite hacer que un
programa tenga soporte interactivo de multiples lenguajes.
V-D0n. Procesamiento de Entrada Basado en Gramatica: Procesamiento de entrada basada en gramatica, incluye
el analisis (parsing) del flujo de tokens de entrada, el mismo
que crea una estructura de datos llamada arbol de analisis
que representa al ingreso de datos. Luego este a rbol es usado
como entrada de procesos computacionales.
V-D0o. Primitivas de concurrencia: Es una abstraccion
de la programacion que provee un lenguaje de programacion
o sistema operativa para facilitar la concurrencia y sincronizacion. Las primitivas de concurrencia bien conocidas son.
Semaforos, monitores y exclusion mutua.
Proveen control de acceso a recursos comunes.
V-D0p. Middleware: Es una clasificacion amplia de
para software que provee servicios sobre la capa del sistema
operativo y justo debajo de la capa de programacion. Se lo
puede mirara como un conector entre componentes de software proporcionando contenedores de ejecucion, persistencia,
comunicacion de mensajes, y localizacion transparente en una
red. Ejemplo de este tipo es un ESB.
V-D0q. Metodos de Construccion para Software Distribuido: Es una coleccion de sistemas computacionales posiblemente heterogeneos y fsicamente separados que proporcionan
acceso a los recursos que administra a traves de una red. Esta
construccion tradicional de software tiene problemas con el
paralelismo, la comunicacion y tolerancia a fallos. Este metodo
tpicamente falla en varias categoras basica arquitecturales:
cliente-servidor, 3-capas, n-capas, etc.
V-D0r. Construccion de sistemas heterogeneos: Consiste en una variedad diferente de unidades computacionales
con control independiente y comunicacion uno con otro. Los
sistemas embebidos tpicamente son sistemas heterogeneos. El
diseno de sistemas heterogeneos requiere la combinacion de
varios lenguajes especficos con el fin de disenar diferentes
partes del sistema. El problema clave aqu, es la validacion
del multilenguaje, la cosimulacion y la intercalacion.
V-D0s. Analisis y afinacion de desempeno: Es la investigacion del comportamiento de un programa usando la
informacion generada por la ejecucion del mismo, con el
objetivo de identificar posibles mejoras en puntos de riesgo.
La afinacion de codigo el cual permite mejorar el desempeno es una practica que se realiza con la modificacion del
codigo apropiado a fin de que se ejecute eficientemente. Para
tal efecto, se tiene multiples afinaciones como expresiones
logicas, repeticiones, etc. Otra tecnica comun es el uso de
lenguaje de bajo nivel.
V-D0t. Plataformas Estandar:
Las plataformas
estandar, permiten a los programadores desarrollar
aplicaciones portables que pueden ser ejecutadas en
ambientes compatibles sin la necesidad de realizar cambios.
Las plataformas incluyen un conjunto de servicios estandar
y APIs compatibles con la plataforma de implementacion
usada, Ejemplo: JEE.

V-D0u. Programacion Test-first: Conocido como TDD


(Desarrollo dirigido por pruebas), es un estilo de desarrollo popular en cual prioriza los casos de prueba sobre la
escritura de codigo. Esta programacion usualmente detecta
tempranamente defectos y los corrige mas facilmente que
la programacion tradicional, pero fuerza al programado a
pensar en los requerimientos y diseno antes de la codificacion,
exponiendo as antes los problemas de requisitos y diseno.
R EFERENCIAS
[1] Bourque P. y Durpuis R. (2004) Guide to the Software Engineering Body
of Knowledge Version 2004. IEEE
[2] Bourque P. y Farley R (2014). Guide to the Software Engineering Body
of Knowledge. Navarra, Espana.

Alexandra Gordillo Ingeniera de sistemas.

Daniel Lopez Ingeniero de sistemas.

Roberto Lopez Ingeniero de sistemas.

You might also like