UNIVERSIDAD DE CARABOBO

Facultad Experimental de Ciencias y Tecnología

Departamento de Computación

Construcción y Pruebas de Software

Elaborado por:

Gustavo Bazán
Francisco Rosas

Bárbula, Junio de 2012

Introducción
La construcción de software es el proceso en el cual se genera el programa que pueda ejecutarse,
esta construcción está altamente ligada al diseño del sistema y a su vez estará muy relacionado
con las prueba que validen la correctitud del sistema.

Debido a la facilidad con la que se pueden realizar proyectos de software enfocándose solo en los
aspectos de la construcción, este tipo de enfoque puede llegar a afectar la calidad del código, y
por ende la calidad del producto final.

Es por ello que la construcción debe tomar en cuenta sus relaciones con el diseño, y siempre
resultara de importancia la capacidad de poder verificar el software que se esta construyendo, es
en esta parte donde se emplean las pruebas, que permitirán comprobar el estado del software.

Construcción de Software
El término Software Construction (Construcción del software) se refiere a la creación de software
productivo y significativo a través de los procesos de codificación, verificación, pruebas unitarias,
pruebas de integración y depuración de errores.

El área del conocimiento de la 'construcción del software' está íntimamente relacionada a las otras
áreas del conocimiento del software como lo son: el diseño, las pruebas, la gestión de
configuraciones, la calidad y las herramientas y métodos

Los límites entre el diseño y la construcción variaran dependiendo del proceso de ciclo de vida del
software utilizado en el proyecto. Aunque ciertas tareas de diseño puedan ser desarrolladas antes
del proceso de construcción, gran parte del trabajo de diseño es realizado en si, durante el
proceso de construcción.

Software que se construye deberá ser validado y verificado, en esta área suelen emplearse
pruebas de software, mostrando así como la salida de la construcción será la entrada de las
pruebas.

Los ingenieros del software suelen realizar pruebas unitarias y pruebas de integración,
demostrando así la cercanía que existen entre el área de conocimiento de la 'construcción del
software' y el área de las 'pruebas del software'.

Típicamente la 'construcción del software' produce el mayor volumen de ítems configurables que
necesitan ser manejados en un proyecto de software (código fuente, contenido, casos de uso, etc).
Es por ello que el área de 'construcción del software' también está íntimamente relacionada con
el 'gerencia de configuraciones del software'.

Mientras la calidad del software es importante en todas las áreas del conocimiento, el código es
uno de los entregables primordiales en un proyecto de software, y por lo tanto la 'calidad del
software' está muy ligada a la 'construcción del software'.
Desde que la 'construcción del software' depende altamente en las herramientas y métodos, y es
probablemente el área de conocimiento que haga el uso más intensivo de herramientas. Esto
demuestra el enlace tan fuerte que tiene el área de 'construcción del software' con el área de
'herramientas y métodos del software’

La ingeniería de software dentro del área de la construcción busca, minimizar la complejidad,

anticipar los cambios, construir teniendo en cuenta la verificación, construir usando estándares.

Minimizar la complejidad
La necesidad de reducir la complejidad aplica esencialmente a cada aspecto de la 'construcción del
software', y es particularmente crítica en el proceso de verificación y pruebas. La reducción de la
complejidad se consigue haciendo énfasis en que el código creado tiene que ser sencillo y legible
más que inteligente. La aplicación de las buenas prácticas del lenguaje que se esté empleando así
como estándares de desarrollo suele ayudar a reducir la complejidad. Se debe considerar que la
legibilidad y sencillez de código puede afectar el rendimiento de la aplicación, es por ello que
resulta conveniente siempre evaluar los requisitos tanto funcionales como no funcionales en aras
de establecer un balance entre legibilidad y mantenibilidad contra rendimiento y tiempos de
respuesta y saber en donde es conveniente mantener mas de uno que otro.

Anticipar Cambios
La naturaleza de los proyectos de software hace que en su gran mayoría sean desarrollos un gran
número de cambios y nuevos requerimientos que van surgiendo durante la ejecución del mismo.
Es por ello que los ingenieros del software deben ser capaces de prever este tipo de situaciones y
planificar y gestionar el proyecto de forma tal que sea posible reaccionar a tiempo a estos
cambios, donde quien se ve mayor mente afectada es la fase de construcción quien puede tener
que re implementar funcionalidades o generar nuevas antes no contempladas. Este es uno de los
motivos por los cuales es importante desarrollar sistemas que puedan ser mantenibles, ya que
facilita estos procesos de modificación y actualización.

Construcción Según Modelos de Desarrollo

Lo que es considerado como 'construcción' dependerá en cierto grado del modelo de software
utilizado. Mientras más linear sea el enfoque más se tiende a enfatizar en las actividades que
preceden al proceso de construcción. Otros modelos son más iterativos y tienden a tratar el
proceso de construcción como una actividad que ocurre concurrentemente con otras actividades
del desarrollo del Software.

Planificación de la construcción
La elección del método de construcción afecta en cierta forma como son realizados los
prerrequisitos de la construcción, afecta la habilidad del proyecto de disminuir la complejidad,
anticipar el cambio, y la construcción en función de la verificación. Cada uno de estos objetivos
puede también ser considerados en el nivel del proceso, requerimientos o diseño; pero también
pueden ser influenciados por la elección del método de construcción. La planificación de la
construcción puede definir el orden en que los componentes del Software son creados e
integrados, los procesos de gestión de calidad del Software, el posicionamiento de las asignaciones
a los ingenieros del software, y otras tareas, de acuerdo obviamente al método elegido.

Medición de la construcción
Numerosas actividades de la construcción y ciertos artefactos deben ser medidos, incluyendo el
código desarrollado, el código modificado, el código re-usado, el código destruido, la complejidad
del código, las estadísticas del código, búsqueda y eliminación de errores, esfuerzo y calendario.
Estas medidas pueden ser útiles para los propósitos de la gerencia de la construcción, asegurando
la calidad durante la construcción, mejorando también el proceso de construcción.

La construcción es una actividad en la cual el Software tiene que lidiar con las restricciones
arbitrarias y caóticas provenientes del mundo real, y cumplirlas exactamente. Debido a la
proximidad con las restricciones del mundo real, la construcción es manejada por consideraciones
del orden práctico, y en medida muchas que otras áreas del conocimiento, y por lo tanto la
ingeniería del software es quizás mucho más artesanal en el área de 'construcción del software.'

Diseño de la Construcción
Algunos proyectos suelen colocar más actividades de diseño en la construcción, otros tienden a
tener una fase exclusivamente a diseño. Sin importar cuál es el carácter exacto, varios trabajos de
diseño ocurrirán en la construcción, y ese trabajo de diseño se regirá por los límites impuestos por
el problema de la vida real que está buscando resolver el software.

Lenguaje de Construcción
Los lenguajes de construcción incluyen todas las formas de comunicación por las cuales el ser
humano puede implantar una solución ejecutable al computador.

Se pueden dividir en:

 'lenguaje de configuración',
 Toolkits
 Lenguajes de programación.

Re-uso
Implementar el re-uso del software involucra mucho más que crear librerías. Requiere formalizar
la práctica del re-uso al integrar procesos de re-uso y actividades dentro del ciclo de vida del
software. Sin embargo, el re-uso es lo suficientemente importante en la construcción del software
que es incluido como un tópico.
Pruebas de Software
Las pruebas de Software tienen 2 objetivos:

 Demostrar al desarrollador y al cliente que el software alcanza sus requisitos. En el caso de

software hecho a la medida esto representa que debe existir al menos 1 prueba por cada
requerimiento. Para software preempaquetado significa que debe existir al menos 1
prueba por cada funcionalidad y sus combinaciones
 Descubrir situaciones donde el comportamiento del software es incorrecto, indeseable o
no esta ajustado a las especificaciones. Estas son las consecuencias de defectos del
software.

El primer objetivo lleva a la prueba de validación, donde se espera que el sistema funcione
correctamente usando casos de prueba específicos que reflejen el uso esperado del sistema. El
segundo objetivo lleva a la prueba de defectos, donde los casos de prueba son diseñados para
exponer potenciales errores. Los casos de prueba para detectar defectos, pueden ser
intencionalmente oscuros y no reflejar como es usado el sistema normalmente. Estos dos
enfoques de prueba no son exclusivos el uno del otro, y en ocasiones se encontraran defectos del
sistema durante pruebas de validación y viceversa.

Las pruebas no pueden demostrar que un software esta libre de defectos o que siempre se
comportara según lo especificado en cada circunstancia. Siempre es posible que una prueba que
se haya pasado por alto lleve a problemas con el sistema.

Las pruebas forman parte de un proceso mayor llamado verificación y validación.

 Validación: ¿Estamos construyendo el producto adecuado?

 Verificación: ¿Estamos construyendo bien el producto?

Este proceso de verificación y validación se asegura que el software desarrollado alcance las
expectativas de la gente que esta pagando por el producto. Este proceso se inicia tan pronto
existan requerimientos y continúa a lo largo de las etapas de desarrollo.

La verificación apunta a revisar que el producto alcance los requerimientos funcionales y no

funcionales. La validación sin embargo es un proceso más general donde se busca validar que el
software satisfaga las expectativas del cliente. Recordemos que los requerimientos no siempre
reflejan los deseos del cliente y es por ello que la validación es tan importante.

Adicionalmente de las pruebas de software el proceso de verificación y validación puede

involucrar inspecciones y revisiones de software, estas analizan y revisan los requerimientos de
sistema, los modelos de diseño, el código fuente e incluso las pruebas propuestas. Estas
inspecciones suelen enfocarse generalmente en el código fuente pero cualquier representación o
modelo del software es inspeccionable. Mediante el conocimiento del sistema, el dominio de la
aplicación, el lenguaje de programación o modelado se pueden llegar a descubrir errores.
Las inspecciones suelen representar en mayor parte la manera en la que se descubren fallas del
sistema, aun así estas no pueden remplazar las pruebas de software, debido a que no son buenas
para descubrir errores que pueden surgir de interacciones inesperadas, problemas de tiempo o
problemas de desempeño.

Pruebas de Desarrollo
El probador del software es usualmente el programador que desarrollo el producto, aunque este
no siempre es el caso. Suelen emplearse 3 niveles al momento de realizar las pruebas.

1. Pruebas Unitarias, donde partes individuales del programa u objetos de las clases son
probadas. Estas pruebas se deben enfocar en probar las funcionalidades de objetos o
métodos.
2. Pruebas de Componentes, donde varias pruebas unitarias son integradas para crear
componentes compuestos. Estas pruebas deben enfocarse en probar las interfaces de los
componentes.
3. Pruebas de Sistema, donde algunos o toso los componentes en un sistema son integrados,
probando el sistema como un todo. Estas pruebas se enfocan en probar las interacciones
de los componentes.

Test-Driven Development

El desarrollo orientado a pruebas (TDD) es un en foque de desarrollo donde se intercalan las

actividades de prueba y codificación. Esencialmente se desarrolla el código incrementalmente,
junto con una prueba para ese incremento.

Una de las ventajas de TDD es que ayuda a los programadores a entender lo que un segmento de
código debe hacer, y a su vez este entendimiento facilita la escritura del código.

Adicionalmente tenemos:

 Cobertura del código: como cada segmento de código debe tener al menos una prueba
asociada, podemos estar seguros que todo el código del sistema ha sido ejecutado. El
código es probado mientras se escribe por ende los defectos son encontrados en etapas
tempranas del desarrollo
 Pruebas de regresión: se pueden ejecutar pruebas anteriores, garantizando que cambios
en el programa no introduzcan nuevas fallas.
  Debugging simplificado: cuando una prueba falla debería ser obvio donde esta el
problema, El código recientemente escrito necesita ser revisado y modificado.
 Documentación del sistema: estas pruebas funcionan a su vez como documentación de lo
que el código debería estar haciendo

Pruebas de lanzamiento
Estas pruebas consisten en permitir que grupos ajenos al equipo de desarrollo interactúen y
evalúen el sistema desarrollado, estas pruebas suelen tener diferentes enfoques según lo que se
desee evaluar, ya sea validando contra los requisitos, simulando posibles escenarios de uso de la
aplicación brindando un aproximado de lo que será la implantación final del sistema, o bien
enfocarse en probar el rendimiento de la aplicación y se responde según los parámetros
establecidos para la prueba.

Pruebas de usuario
Consiste en permitir a los usuarios o clientes evaluar versiones preliminares de la aplicación para
poder recibir comentarios con respecto a funcionalidades o posibles fallas. Según el estado de
funcionalidad en el que se encuentre el sistema y el numero y tipo de usuario a los que este
dirigido estas pruebas pueden llamarse Alfa, para un muy reducido numero de usuarios y muchas
posibles fallas aun por corregir, o Beta, mayor numero de usuarios y una aplicación bastante
cercana a la aplicación final.

Conclusiones
Los proyectos de software tiene como finalidad la entrega de un producto funcional y que cubra
las expectativas del cliente, la mayor cantidad de esfuerzo a este tipo de proyecto suele darse a la
fase de construcción. Pero bien es cierto que grandes equipos de trabajo o recursos ilimitados
dedicados exclusivamente a la construcción de software sean garantía de alcanzar los objetivos
finales. Es por ello que es importante la relación que existe entre la construcción, el análisis y el
diseño de las diferentes funcionalidades, y la importancia de construir software empleando de la
mejor manera las herramientas disponibles así como los principios y métodos asociados a
lenguajes, frameworks y marcos de trabajo, para contar no solo con un buen producto sino con un
código que pueda ser mantenible a través del tiempo.

De igual manera una de las grandes herramientas en las cuales se puede apoyar la construcción
para mejorar la calidad del código esta en las pruebas de software, bien sea realizando pruebas al
final del proceso de construcción, o empleando técnicas de construcción orientada a pruebas, es
importante contar con formas de poder verificar el producto y que si bien no se podrá garantizar
este libre de fallas se estará seguro que el comportamiento será el deseado.

Al final de todos estos procesos lo importante será siempre validar con los clientes o usuarios que
sus expectativas han sido alcanzadas y se les esta brindando una herramienta con la cual obtienen
beneficio real al usar dicha herramienta.
Bibliografía
Beck, K. (2002). Test Driven Development: By Example. Addison-Wesley Longman.

Chelimsky, D., Astels, D., Dennis, Z., Hellesøy, A., Helmkamp, B., & North, D. (2010). The RSpec
Book. The Pragmatic Programmers LLC.

IEE Computer Society. (2004 ). Guide to the Software Engineering Body of Knowledge (SWEBOK).

North, D. (2006). DanNorth.net. Recuperado el 14 de Junio de 2012, de Introducing BDD:

http://dannorth.net/introducing-bdd/

Sommerville, I. (2010). Ingeniería del software. Adison Wesley.