Prototipo_de_framework_para_pruebas_de_u

Vista previa del material en texto

UNIVERSIDAD CATÓLICA BOLIVIANA “SAN PABLO” 
UNIDAD ACADÉMICA REGIONAL COCHABAMBA 
Departamento de Ciencias Exactas e Ingeniería 
Carrera de Ingeniería de Sistemas 
 
 
 
 
Prototipo de framework para pruebas de unidad para 
desarrolladores de aplicaciones web 
 
 
Proyecto de Grado de Licenciatura en Ingeniería de Sistemas 
 
 
Jorge Rodrigo Leon Riguera 
Mauricio Derek Valdez Arratia 
 
Cochabamba – Bolivia 
Enero de 2013
 
TRIBUNAL EXAMINADOR 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
______________________ 
Ing. Omar Rodríguez 
Profesor Guía 
 
 
 
 
 
 
____________________ 
Mgr. Johnny Herrera 
Director de Carrera 
 
 
 
 
 
 
 
______________________ 
Ing. Carlos Canedo 
Profesor Relator 
 
 
 
 
 
 
______________________ 
Mgr. Alfonso Vía Reque 
Rector Regional 
 
 
 
 
 
 
 
Agradecimientos 
 
 
 
 
 
 
Agradecer a todas las personas que nos brindaron su apoyo 
 
Muchas gracias a todos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Resumen 
 
 
El presente proyecto de grado es un prototipo de framework que presenta una 
abstracción de diferentes tipos de prueba de unidad que ayuda a desarrolladores de 
aplicaciones web a probar distintas funcionalidades de una aplicación web en un 
tiempo reducido, además de poder ver el rendimiento de dichas funcionalidades 
estresándolos y obtener el resultado del performance. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Palabras clave: Framework, pruebas de unidad, estrés, performance, interface. 
 
Abstract 
 
This graduation project is a prototype framework that presents an abstraction of different 
types of unit test that helps web developers to test different features of a web application 
in a short time, besides being able to see the performance of these functions stressing 
and get the result of the performance. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Keywords: Framework, unit tests, stress, performance, interfaces. 
 
ÍNDICE 
 
INTRODUCCIÓN ............................................................................................................. 1 
Antecedentes .................................................................................................................. 2 
Situación problemática ................................................................................................... 2 
Formulación del problema ............................................................................................. 3 
Objetivos ........................................................................................................................ 3 
Objetivo general ......................................................................................................... 3 
Objetivos específicos .................................................................................................. 3 
Justificación .................................................................................................................... 3 
Alcances ......................................................................................................................... 4 
Limitaciones ................................................................................................................... 4 
CAPÍTULO 1. MARCO TEÓRICO ................................................................................. 5 
1.1. Ingenieria del software ............................................................................................ 5 
1.2. Proceso de software ................................................................................................. 5 
1.2.1 Atributos de un buen software ........................................................................... 6 
1.3. Modelos del proceso del software ........................................................................... 6 
1.3.1 Modelo de desarrollo en cascada ....................................................................... 7 
1.3.2 Modelo de desarrollo evolutivo ......................................................................... 7 
1.3.3 Modelo de desarrollo basado en componentes .................................................. 8 
1.4 Actividades del proceso ......................................................................................... 10 
1.4.1 Especificación del software ............................................................................. 10 
1.5 Diseño e implementación del software .................................................................. 12 
1.5.1 Evolución del software .................................................................................... 14 
1.5.2 Verificación y validación ................................................................................ 15 
1.6 Desarrollo de aplicaciones web .............................................................................. 17 
1.7 Framework ............................................................................................................. 31 
1.7.1 Tipos de framework ......................................................................................... 32 
1.7.2 Propiedades de un framework ......................................................................... 33 
1.7.3 Arquitectura de un framework ......................................................................... 34 
 
1.7.4 Desarrollo de un framework ............................................................................ 35 
1.7.5 Diseño e implementación ................................................................................ 35 
1.7.6 Instanciación y testeo ...................................................................................... 36 
1.7.7 Documentación de un framework ................................................................... 36 
1.8 TPL ......................................................................................................................... 37 
1.9 Pruebas de unidad .................................................................................................. 39 
1.9.1 Pruebas de Unidad en desarrollo de aplicaciones web .................................... 40 
1.9.2 Pruebas de unidad en procesos agiles .............................................................. 40 
1.9.3 Tipos de prueba de unidad ............................................................................... 41 
1.9.4 Pruebas de unidad de Estrés/Performance ....................................................... 42 
1.10 Prototipo del framework ...................................................................................... 44 
CAPÍTULO 2. MARCO PRÁCTICO ............................................................................. 45 
2.1 Planificación de incrementos ................................................................................. 47 
2.1.1 Primer incremento ........................................................................................... 47 
2.1.2 Segundo incremento ........................................................................................ 47 
2.1.3 Tercer incremento ............................................................................................ 48 
2.1.4 Cuarto incremento ........................................................................................... 49 
2.2 Primer Incremento .................................................................................................. 49 
2.2.1 Análisis de requerimientos .............................................................................. 49 
2.2.2 Análisis ............................................................................................................ 53 
2.2.3 Implementación ............................................................................................... 55 
2.3 Segundo incremento ...............................................................................................57 
2.3.1 Análisis de requerimientos .............................................................................. 57 
2.3.2 Análisis ............................................................................................................ 62 
2.3.3 Desarrollo ........................................................................................................ 67 
2.4 Tercer incremento .................................................................................................. 76 
2.4.1 Análisis de requerimientos .............................................................................. 76 
2.4.2 Análisis ............................................................................................................ 82 
2.4.3 Implementación ............................................................................................... 86 
2.5 Cuarto incremento .................................................................................................. 91 
 
2.5.1 Análisis de requerimientos .............................................................................. 91 
2.5.2 Análisis ............................................................................................................ 95 
2.5.3 Implementación ............................................................................................... 97 
2.6 Caso de uso final .................................................................................................. 101 
CONCLUSIONES Y RECOMENDACIONES ............................................................ 102 
Conclusiones .............................................................................................................. 102 
Recomendaciones ....................................................................................................... 102 
BIBLIOGRAFÍA ........................................................................................................... 104 
Anexos ........................................................................................................................... 106 
Anexo A ..................................................................................................................... 106 
Anexo B ..................................................................................................................... 114 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ÍNDICE DE FIGURAS 
 
Modelo de desarrollo cascada ............................................................................................ 7 
Modelo de desarrollo evolutivo ......................................................................................... 8 
Modelo de desarrollo basado en componentes .................................................................. 9 
Proceso de la ingeniería de requerimientos ..................................................................... 12 
Etapas de proceso de prueba de validación ..................................................................... 14 
Las fases de prueba en le proceso del software ............................................................... 15 
Evolución del sistema ...................................................................................................... 15 
El proceso de depuración ................................................................................................. 17 
Ejemplo de documento HTML ........................................................................................ 19 
Configuración de una aplicación web .............................................................................. 20 
Generación dinámica por cada solicitud .......................................................................... 21 
DHTML DOM [Document Object Model] ..................................................................... 22 
Funcionamiento de las paginas ASP ................................................................................ 24 
Componentes cuando cliente solicita servicios a servidor ............................................... 24 
Ejemplo de código básico ASP ........................................................................................ 25 
Ejemplo de pagina ASP.NET .......................................................................................... 26 
Plataforma .NET .............................................................................................................. 27 
Eventos en ASP.NET ....................................................................................................... 28 
ASP.NET se encarga de mostrar formularios web de la plataforma que resulte mas 
adecuada para el navegador que utilice el usuario final de la aplicación ................ 29 
MVC ................................................................................................................................ 31 
 
Arquitectura de un framework ......................................................................................... 34 
Task Parallel Library ....................................................................................................... 37 
Ejemplo paralelismo de datos .......................................................................................... 38 
Ejemplo paralelismo de tareas ......................................................................................... 39 
Estructura del framework de pruebas de unidad para desarrolladores de aplicaciones web
 ................................................................................................................................. 45 
Flujo de creación de framework ...................................................................................... 46 
Crear plantilla .................................................................................................................. 50 
Obtener información de CPU y Memoria ........................................................................ 50 
Almacenar los datos de porcentaje de uso de CPU vs Tiempo y Memoria vs Tiempo ... 51 
Graficar datos almacenados ............................................................................................. 51 
Diagrama de clases (primer incremento) – Modulo de pruebas de unidad de 
estrés/performance ................................................................................................... 53 
Diagrama de secuencia: Obtener información de HW y graficar con los datos 
almacenados ............................................................................................................. 54 
Interacción con los componentes básicos ........................................................................ 57 
Validación de un componente individual ........................................................................ 57 
Ejecutar prueba de unidad por un intervalo de tiempo .................................................... 58 
Ejecutar prueba de unidad en múltiples sesiones ............................................................. 58 
Ejecutar una prueba de unidad en múltiples sesiones en un intervalo de tiempo ............ 59 
Diagrama de clases (segundo incremento) – Modulo de pruebas de unidad de interfaz de 
usuario ...................................................................................................................... 62 
Diagrama de clases (segundo incremento) – Modulo de pruebas de unidad de 
estrés/performance ................................................................................................... 64 
 
Diagrama de secuencia: Validación de componentes ...................................................... 65 
Diagrama de secuencia: Validación de componentes ...................................................... 66 
Validación de un formulario completo ............................................................................ 76 
Navegación básica ...........................................................................................................76 
Reportes de interacciones de componentes ..................................................................... 77 
Ejecutar distintas pruebas de unidad ................................................................................ 77 
Ejecutar distintas pruebas de unidad en múltiples sesiones ............................................. 78 
Ejecutar distintas pruebas de unidad en múltiples sesiones en un intervalo de tiempo 
secuencialmente ....................................................................................................... 78 
Diagrama de clases (tercer incremento) – Modulo de pruebas de unidad de interfaz de 
usuario ...................................................................................................................... 82 
Diagrama de clases (tercer incremento) – Modulo de pruebas de unidad de 
estrés/performance ................................................................................................... 84 
Diagrama de secuencia: Navegación e interacciones con componentes ......................... 85 
Reporte de navegación ..................................................................................................... 91 
Ejecutar distintas pruebas de unidad en múltiples sesiones en un intervalo de tiempo 
paralelamente ........................................................................................................... 92 
Ejecutar una prueba de unidad hasta el porcentaje de uso de CPU llegue a un porcentaje 
de CPU definido por desarrollador .......................................................................... 93 
Diagrama de clases (cuarto incremento) – Modulo de pruebas de unidad de interfaz de 
usuario ...................................................................................................................... 95 
Diagrama de clases (cuarto incremento) – Modulo de pruebas de unidad de 
estrés/performance ................................................................................................... 96 
Caso de uso final ............................................................................................................ 101 
 
 
ÍNDICE DE TABLAS 
 
Descripción caso de uso: Crear plantilla....……………………………….………….…50 
Descripción caso de uso: Obtener información de CPU y Memoria……..……….……51
Descripción caso de uso: Graficar datos almacenados….….…………….…….………51 
Descripción caso de uso: Interacción con los componentes básico.……….….……..…56 
Descripción caso de uso: Validación de un componente individual….…..…………….57
Descripción caso de uso: Ejecutar prueba de unidad por un intervalo de tiempo…...…57 
Descripción caso de uso: Ejecutar prueba de unidad en múltiples sesiones……………58 
Descripción caso de uso: Ejecutar prueba de unidad en múltiples sesiones en un 
intervalo de tiempo……………………………………………………………………...58
Descripción caso de uso: Validación de formulario completo...………..………………69 
Descripción caso de uso: Navegación básica...…………………………………………69 
Descripción caso de uso: Reportes de interacciones de componentes….………………69
Descripción caso de uso: Ejecutar distintas pruebas de unidad.…..……………………70
Descripción de caso de uso: Ejecutar distintas pruebas de unidad en múltiples 
sesiones………………………………………………………………………………….80 
Descripción caso de uso: Ejecutar distintas pruebas de unidad en múltiples sesiones en 
un intervalo de tiempo secuencialmente...………...……………………………….……71
Descripción caso de uso: Validación de formulario completo……….…………………79 
Descripción caso de uso: Ejecutar distintas pruebas de unidad en múltiples sesiones en 
un intervalo de tiempo paralelamente…………..………..………………...……………80 
Descripción caso de uso: Ejecutar una prueba de unidad hasta que el porcentaje de uso 
de CPU llegue a un porcentaje definido por desarrollador………………………...……81 
 
1 
 
INTRODUCCIÓN 
Framework es una estructura de soporte definida, en la cual otro proyecto de software 
puede ser organizado y desarrollado, diseñado con la intención de facilitar el desarrollo 
de software, permitiendo a los diseñadores y programadores pasar más tiempo 
identificando requerimientos de software que tratando con los tediosos detalles de bajo 
nivel de proveer un sistema funcional. 
Prueba de unidad es un método de prueba que verifica qué componentes individuales del 
código fuente funcionan correctamente. Para ello, el desarrollador que crea las pruebas, 
implementa ejemplos de uso directamente en código fuente que es ejecutado durante el 
proceso de pruebas. Si la ejecución no obtiene los resultados esperados se dice que la 
prueba falla o no pasa, y por lo tanto se considera que el código probado es incorrecto. 
La prueba de unidad de interfaz de usuario se utilizar para evitar los pasos repetitivos al 
momento de validar el cambio desarrollado. Esta prueba de unidad sigue una serie de 
pasos definidos has re direccionar al componente o pantalla que desea validar, además 
que al tener pasos automatizados, estos ayudaran al desarrollador a posicionarse en el 
punto deseado de debug. 
La prueba de unidad de estrés se utiliza para probar la robustez de una unidad de código 
en la que se está trabajando. Se va doblando el número de usuarios que se agregan a la 
unidad de código y se ejecuta una prueba de carga. Este tipo de prueba se realiza para 
determinar la solidez de una unidad de código en los momentos de carga extrema. 
Además, ayuda a los desarrolladores para determinar si la unidad de código rendirá lo 
suficiente en caso de que la carga real supere a la carga esperada, en el ambiente del 
desarrollador. 
La prueba de unidad de performance son pruebas que se realizan, desde una perspectiva, 
para determinar lo rápido que ejecuta una unidad de código en condiciones particulares 
de trabajo. También puede servir para validar y verificar otros atributos de calidad de las 
unidades de código, en el ambiente del desarrollador. 
Los sistemas informáticos tiene un ciclo de vida cambiante en especial por los 
requerimientos que se van presentando ya sea al inicio o en el transcurso del proceso de 
desarrollo; Las pruebas de unidad se utilizan para garantizar que los cambios en los 
requerimientos no vayan a romper la integridad del sistema. Adicionalmente, cuando 
existen requerimientos para mejorar o corregir problemas de performance/estrés, se 
pueden crear pruebas de unidad que validen la estabilidad/integridad del sistema después 
de los cambios (Pruebas a pequeña escala). 
2 
 
Antecedentes 
Las pruebas unidad sobre interfaz de usuario no son agradables para los desarrolladores, 
por el hecho de que son más complejas y/o tediosas a la hora de crearlas, por esto los 
desarrolladores son más reacios a hacerlas. 
No es común entre los desarrolladores crear pruebas de unidad que ayuden a validar 
cambios o arreglos relacionados con requerimientos de performance/estrés. 
Si bien existen mecanismos, tecnologías para realizar pruebas de unidad estas no están 
diseñadas específicamente para realizar pruebas para interfaz de usuario y/o pruebas 
para performance/estrés. 
 
Situación problemática 
Actualmente, en nuestro medio existen empresas que se están dedicando al desarrollo de 
software para el exterior. Este tipo de software demanda mejores medidas de calidad que 
garanticen la calidad de la programación del software. Esto implica, que los 
desarrolladores prueben software intensa y extensamente de tal forma que garantice 
mantenibilidad del código. 
Cuando un desarrollador web esta implementado una interfaz de usuario, debe ir 
verificando sus cambios, para lo cual se realizan varios pasos repetitivos aunque el 
cambio sea muy pequeño, más aun si el cambio o implementación está relacionado con 
una corrección de error o con una nueva funcionalidad de extensión de un módulo. Los 
pasos repetitivos para una simple validación pueden ser tediosos. 
Las pruebas de unidad de estrés y/o performance generalmente son realizadas cuando el 
sistemadesarrollado entra en producción. Es en este punto cuando se detectan los 
módulos con problemas de estrés y performance y se reporta como errores (bugs) a los 
desarrolladores. 
 
 
 
 
3 
 
Formulación del problema 
- Las pruebas de unidad de interfaz de usuario son tediosas y complejas para 
desarrolladores web. 
- Cuando varias personas están involucradas en un mismo producto existe la 
posibilidad de ruptura de código. 
- Los mecanismos para hacer pruebas de unidad de interfaz de usuario y/o de 
performance/estrés son complejos. 
- En nuestro entorno los desarrolladores no están acostumbrados a realizar pruebas 
de unidad de performance/estrés. 
- Desarrollador que quiere realizar sus propias pruebas, las tienes que crear 
artesanalmente. 
 
Objetivos 
Objetivo general 
- Desarrollar un prototipo de framework para pruebas de unidad de interfaz de 
usuario y de performance/estrés durante el desarrollo de aplicaciones web. 
Objetivos específicos 
1. Desarrollar una librería para pruebas de unidad de interfaz de usuario. 
2. Desarrollar una librería para pruebas de unidad de performance/estrés. 
3. Aportar a la mantenibilidad/portabilidad de las pruebas de unidad mediante la 
estandarización de su generación. 
4. Implementar demostración de la arquitectura del framework. 
 
Justificación 
El comportamiento, rendimiento y pruebas del código desarrollado son muy importantes 
para garantizar un software de calidad. La creación de un framework que integre los 
objetivos específicos mencionados, permitirá mejorar la tarea de los desarrolladores 
teniendo así un producto de mayor calidad y reduciendo la complejidad en la creación de 
pruebas de unidad de interfaz de usuario y performance/estrés. 
4 
 
Alcances 
Las pruebas de unidad contemplarán los siguientes puntos: 
- Reconocimiento de componentes 
- Generación de rutas de navegación automatizada 
- Validación de rutas de navegación(Completadas o No) 
- Validación de Componentes individuales en un formulario (ASP) 
- Validación de vistas completas 
- Generación de reportes sobre fallas, pruebas de unidad y reconocimiento de 
componentes. 
Las pruebas de performance/estrés contemplaran los siguientes puntos: 
- Se incluirá la carga de volumen de datos unitarios. 
- Se abordara la carga de volumen de datos paralelo. 
- Se proporcionara la carga de volumen de datos con tecnología TPL (Task 
Parallel Library). 
- Se proporcionara estadísticas de uso de recursos de hardware del sistema con 
tecnología WMI. 
- Generación de reportes sobre el rendimiento de la unidad de código. 
Reporte sobre componentes y utilizaremos la tecnología .net con el lenguaje C# con la 
versión de visual estudio 2012. 
 
Limitaciones 
- Las pruebas de unidad se realizaran sobre Interfaz de usuario a nivel de 
componentes. 
- Las pruebas de performance/estrés están enfocadas al entorno del desarrollador y 
no así a una aplicación en producción. 
- Trabajar con aplicaciones web específicamente con aplicaciones desarrolladas en 
ASP. 
- No se incluirá otro tipo de pruebas aparte de las mencionadas. 
 
 
5 
 
CAPÍTULO 1. MARCO TEÓRICO 
1.1. Ingenieria del software 
Disciplina de la ingeniería que comprende todos los aspectos de la producción de 
software desde las etapas iniciales de la especificación del sistema, hasta el 
mantenimiento de éste. 
(IanSommerville,2005) 
 
En esta definición, existen dos frases 
1. Disciplinas que involucran a la Ingeniería. Los involucrados hacen que las cosas 
funcionen. Aplican teorías, métodos y herramientas donde sean convenientes y cuando 
sean convenientes, pero las utilizan de forma selectiva y siempre tratando de descubrir 
soluciones a los problemas, aun cuando no existan teorías y métodos aplicables para 
resolverlos. 
2. Aspectos de producción de software. Actividades tales como la gestión de proyectos 
de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción 
de software. 
 
1.2. Proceso de software 
Son un conjunto de actividades y resultados asociados que generan un producto final de 
software. Estas actividades son llevadas a cabo por los ingenieros de software. Podemos 
resaltar cuatro actividades fundamentales. 
 
- Especificación del software, Clientes e ingenieros definen los alcances del 
software a producir y las limitaciones sobre su operación. 
 
- Desarrollo del software, El software se diseña y programa. 
 
- Validación del software, El software se valida para asegurar que es lo que el 
cliente requiere según los requerimientos previamente solicitados. 
 
- Evolución del software, El software se modifica para adaptarlo a los cambios 
requeridos por el cliente y/o el mercado. 
 
http://www.software-engin.com/
6 
 
Diferentes tipos de sistemas necesitan diferentes procesos de desarrollo. Estas 
actividades genéricas pueden organizarse de diferentes formas y describirse en 
diferentes niveles de detalle para diferentes tipos de software. Sin embargo, el uso de un 
proceso inadecuado del software puede reducir la calidad o la utilidad del producto de 
software que se va a desarrollar y/o incrementar los costes de desarrollo. 
(Ian Sommerville, 2005) 
1.2.1 Atributos de un buen software 
Los atributos de un buen software se reflejan su comportamiento durante su ejecución y 
en la estructura y organización del programa fuente y en la documentación asociada. 
Entre los atributos podemos resaltar los siguientes cuatro: 
Mantenibilidad: El Software debe escribirse de tal forma que pueda evolucionar y no 
sufra grandes impactos en las etapas de cambio. Este es un atributo crítico debido a que 
el cambio en el Software es una consecuencia inevitable de un cambio en el entorno de 
negocios 
Confiabilidad: El Software no debe causar daños económicos y/o físicos en caso de una 
falla del sistema. 
Eficiencia: No se deben malgastar recursos del sistema, como memoria y los ciclos de 
procesamiento. La eficiencia incluye tiempos de respuesta y de procesamiento. 
Usabilidad: Debe ser fácil e intuitivo al momento de su uso por el usuario. Esto 
significa que debe tener una interfaz apropiada y una adecuada documentación. 
 
1.3. Modelos del proceso del software 
Un modelo del proceso del software es una representación abstracta de un proceso del 
software. Cada modelo de proceso representa un proceso desde una perspectiva 
particular, y así proporciona sólo información parcial sobre ese proceso. 
(IanSommerville, 2005) 
 
http://www.software-engin.com/
http://www.software-engin.com/
7 
 
Los modelos generales no son descripciones finales ni definitivas de los procesos del 
Software. Más bien, son abstracciones de procesos del sistema que se pueden utilizar o 
servir para explicar diferentes enfoques para el desarrollo del mismo. Se puede decir que 
son marcos de trabajo del proceso que pueden ser extendidos y adaptados para crear 
procesos más específicos. 
Los más utilizados son los siguientes: 
1.3.1 Modelo de desarrollo en cascada 
Considera una de sus actividades como fases separadas, estas actividades son: 
desarrollo, validación y evolución. 
Figura 1 
Modelo de desarrollo cascada 
 
 
Fuente: 
http://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Modelo_Cascada_Sec
uencial.jpg/350px-Modelo_Cascada_Secuencial.jpg 
 
1.3.2 Modelo de desarrollo evolutivo 
El sistema se desarrolla rápidamente a partir de especificaciones abstractas. Estas se 
refinan basándose en las peticiones del cliente generando un sistema que satisfaga sus 
necesidades. 
El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen 
cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia 
http://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Modelo_Cascada_Secuencial.jpg/350px-Modelo_Cascada_Secuencial.jpg
http://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Modelo_Cascada_Secuencial.jpg/350px-Modelo_Cascada_Secuencial.jpg8 
 
hacen que no sea posible esperar a poner en el mercado un producto absolutamente 
completo, por lo que se debe introducir una versión funcional limitada de alguna forma 
para aliviar las presiones competitivas. 
En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso 
que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los 
requisitos centrales son conocidos de antemano, aunque no estén bien definidos a nivel 
detalle. 
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más 
completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más 
allá, durante la fase de operación. Los modelos “Iterativo Incremental” y “Espiral” 
(entre otros) son dos de los más conocidos y utilizados del tipo evolutivo. 
Figura 2 
Modelo de desarrollo evolutivo 
 
Fuente: http://www.ecured.cu/images/7/71/Pds1.JPG 
 
1.3.3 Modelo de desarrollo basado en componentes 
 
Se enfoca en la existencia de componentes reutilizables. Se enfoca en integrar 
componentes y reutilizarlos más que desarrollarlos de cero. Esta cultura de reutilización 
es esencial en casi todas las organizaciones que desarrollan software. Sin embargo, la 
mayoría de los desarrolladores de software suelen utilizar métodos de desarrollo internos 
a la organización que conducen, en la mayoría de los casos, a aplicaciones mal 
construidas, retrasos en los plazos de finalización del proyecto, y un aumento en los 
costes finales del desarrollo. Esto se debe a la falta de procesos y técnicas bien definidas 
que guíen a los desarrolladores de software durante la construcción de la aplicación 
basada en reutilización. (Luis F. Iribarne Martínez, 2003) 
9 
 
Figura 3 
Modelo de desarrollo basado en componentes 
 
 
Fuente: 
http://www.itpuebla.edu.mx/Alumnos/Cursos_Tutoriales/Ana_Sosa_Pintle/SISTE
MAS/ARCHIVOS_FUNDAMENTOS/ARCHIVOS/U5_6_clip_image001.gif 
 
Estos modelos se utilizan ampliamente en la práctica actual de la ingeniería del software. 
No se excluyen y a menudo se utilizan juntos, especialmente en proyectos de sistemas 
grandes. 
 
 
 
 
 
10 
 
1.3.3.1 Iteración de procesos 
Los cambios existen y son inevitables en cualquier proyecto de software. Los 
requerimientos cambian cuando el cliente lo solicite es por esto que las prioridades de 
gestión cambian. Cuando se tienen nuevas tecnologías, cambian los diseños y la 
implementación. Significa que el proceso de software no es un proceso único. Más bien, 
las actividades se repiten regularmente según el sistema sufra cambios. 
La esencia de los procesos iterativos es que la especificación se desarrolla junto con el 
software. 
Sin embargo, esto crea conflictos con el modelo de obtención de muchas organizaciones 
donde la especificación completa del sistema es parte del contrato de desarrollo del 
mismo. En el enfoque incremental, no existe una especificación completa del sistema 
hasta que el incremento final se especifica. 
(Ian Sommerville, 2005). 
 
1.4 Actividades del proceso 
Podemos identificar cuatro actividades básicas: especificación del software, desarrollo, 
validación y evolución se organizan de forma distinta en diferentes procesos del 
desarrollo. 
 
En la modelo de desarrollo en cascada están organizadas secuencialmente, mientras que 
en el modelo de desarrollo evolutivo se entrelazan. Estas pueden variar dependiendo del 
tipo de software final, las personas, la estructura organizativa implicada y el ambiente. 
No existe una forma correcta o incorrecta de organizar estas actividades. 
1.4.1 Especificación del software 
La especificación del software es el proceso de definición y comprensión de los 
servicios que necesita el cliente o el entorno para el sistema además que se identifican 
las limitaciones de funcionamiento. 
 
Es una etapa crítica en el proceso del software ya que si existen errores en esta etapa 
originan inevitablemente problemas posteriores en el diseño y la implementación del 
sistema. 
http://www.software-engin.com/
11 
 
En esta etapa se deben distinguir tres actores principales: 
Los usuarios finales y los clientes que necesitan de una declaración de alto nivel de los 
requerimientos. Los desarrolladores del sistema necesitan una especificación más 
detallada de éste, orientado al funcionamiento y lógica de negocio. 
Podemos distinguir cuatro fases principales en este proceso: 
1. Análisis de viabilidad. Se verifica que las necesidades del usuario se puedan 
satisfacer con las tecnologías existentes de hardware y software. Además de analizar si 
el sistema propuesto será rentable desde un punto de vista de negocios y si se puede 
desarrollar dentro de las restricciones planteadas. Este estudio debe ser relativamente 
económico y rápido. 
2. Captación y análisis de requerimientos. Es el proceso de obtener los requerimientos 
del sistema por medio de la observación de los sistemas existentes, discusiones con los 
usuarios potenciales y proveedores, el análisis de tareas, etcétera. Esto puede implicar el 
desarrollo de uno o más modelos y prototipos del sistema que ayudan al analista a 
comprender el sistema a especificar. 
3. Especificación de requerimientos. Se deben traducir todos los datos obtenidos 
durante el análisis en un documento que define un conjunto de requerimientos. 
4. Validación de requerimientos. Se comprueba la veracidad y completitud de 
requerimientos. Durante esta etapa se deben corregir problemas de malentendidos en la 
captación de datos y requerimientos. 
No se debe tomar estrictamente de forma secuencial estas etapas. El análisis de 
requerimientos puede ser una fase continua durante la definición y especificación del 
producto y a lo largo del proceso de este surgen nuevos requerimientos. 
Por lo tanto, las actividades de análisis, definición y especificación se entrelazan. En los 
métodos ágiles como la programación extrema, los requerimientos de desarrollan de 
forma incremental conforme a las prioridades del usuario, y la obtención de 
requerimientos viene de los usuarios que forman parte del equipo de desarrollo. 
(Ian Sommerville, 2005). 
 
 
 
 
http://www.software-engin.com/
12 
 
Figura 4 
Proceso de la ingeniería de requerimientos 
 
Fuente: (Ian Sommerville, 2005) 
 
1.5 Diseño e implementación del software 
En esta etapa se convierte una especificación en un sistema ejecutable. Implicando los 
procesos de diseño y desarrollo, también puede implicar un refinamiento de la 
especificación del software. 
 
Un diseño de software es una descripción de la estructura de este, los datos que son parte 
del sistema, interfaces, y algunas veces los algoritmos involucrados. Por lo general esto 
es realizado de manera iterativa a través de diversas versiones y/o entregables. 
 
Puede implicar el desarrollo de distintos modelos del sistema con diferentes niveles de 
abstracción. Mientras se van descomponiendo los diseños, se descubren errores y/o 
omisiones realizadas en etapas previas. Esto permite mejorar los diseños previos. 
 
La retroalimentación entre etapas y la consecuente repetición del trabajo es inevitable en 
todos los procesos de diseño. El resultado final del proceso contiene especificaciones 
detalladas de los algoritmos y las estructuras de datos implementadas. 
 
 
http://www.software-engin.com/
13 
 
Las actividades específicas del proceso de diseño son: 
1. Diseño arquitectónico. Se identifican y documentan todos los subsistemas o módulos 
que forman el sistema final. 
2. Especificación abstracta. Para cada subsistema se produce una especificación 
abstracta 
de sus servicios y las restricciones bajo las cuales debe funcionar. 
3. Diseño de la interfaz. Cada subsistema debe tener su diseño y documentación de las 
interfaces que lo componen. Esta debe ser clara y precisa ya que permite que el 
subsistema sea utilizado sin conocimiento de su funcionamiento.4. Diseño de componentes. Se diseñan las interfaces además de asignar los servicios a 
los componentes. 
5. Diseño de la estructura de datos. Se especifica y diseña la estructura de datos que va 
ser utilizada en el sistema. 
6. Diseño de algoritmos. Se especifican y se diseñan los algoritmos que serán utilizados 
en el sistema. 
Validación del software 
La validación de software es utilizado para mostrar que el sistema se ajusta a su 
especificación y que cumple las expectativas del usuario o usuarios que lo utilizaran. 
Esto implica que los procesos de comprobación y revisión sean constantes hasta el 
desarrollo del programa. La mayoría de los costos de validación aparecen después de la 
implementación, cuando se prueba el funcionamiento del sistema por completo. 
A excepción de los programas pequeños, los sistemas no se deben validar como una 
simple unidad de código, sino que, deben ser comprobados a un nivel más profundo. 
Existen tres etapas en la cual se prueban los componentes del sistema, la integración del 
sistema y, finalmente, el sistema con los datos del cliente. 
Las etapas del proceso de prueba son: 
1. Prueba de componentes o unidades. Se prueban los componentes individuales para 
asegurarse que funcionan correctamente. Cada uno se prueba de forma independiente, 
sin los otros componentes del sistema. Los componentes pueden ser entidades simples 
como funciones o clases de objetos. 
14 
 
2. Prueba del sistema. Este proceso comprende encontrar errores que son el resultado 
de interacciones no previstas entre los componentes y su interfaz. También comprende 
validar que el sistema cumpla sus requerimientos funcionales y no funcionales y probar 
las propiedades emergentes del sistema. 
3. Prueba de aceptación. Esta es la etapa final en el proceso de pruebas antes de que se 
acepte que el sistema entre a producción. Esta prueba con los datos proporcionados por 
el cliente más que con datos de prueba simulados. 
Figura 5 
Etapas de proceso de prueba de validación 
 
Fuente: (Ian Sommerville, 2005) 
 
1.5.1 Evolución del software 
La flexibilidad de los sistemas en el caso de cambios de requerimientos, es una de las 
principales razones por la cual este atributo es incorporado a los sistemas grandes y 
complejos. Realizar cambios en un hardware es muy costoso. Sin embargo, se pueden 
hacer cambios al software en cualquier momento durante o después de la etapa de 
desarrollo. 
Siempre ha existido una separación entre el proceso de desarrollo y el proceso de 
evolución de software. Muchos consideran el desarrollo de software como una actividad 
creativa en la cual un sistema de software se desarrolla desde un concepto inicial hasta 
que se pone en funcionamiento. A veces se consideran el mantenimiento del software 
como algo aburrido y sin interés, aunque los costos de mantenimiento son a menudo 
varias veces los costos iniciales de desarrollo. El proceso. Esta distinción entre el 
desarrollo y el mantenimiento es cada vas más irrelevante. Hoy en día, pocos sistemas 
de software son completamente nuevos, lo que implica que tiene más sentido ver el 
desarrollo y el mantenimiento como actividades continuas. Más que dos procesos 
separados, se considera a la ingeniería de software como un proceso evolutivo en la cual 
http://www.software-engin.com/
15 
 
el software cambia continuamente durante su periodo de vida como respuesta a los 
requerimientos cambiantes y necesidades del usuario. 
Figura 6 
Las fases de prueba en le proceso del software 
 
Fuente: (Ian Sommerville, 2005) 
 
Figura 7 
Evolución del sistema 
 
Fuente: (Ian Sommerville, 2005) 
 
1.5.2 Verificación y validación 
El programa que se está desarrollando debe ser comprobado para asegurar que satisface 
su especificación y entrega la funcionalidad esperada por el cliente. La verificación y 
validación tiene un lugar en cada etapa del proceso de software, comienza por revisiones 
de los requerimientos y continúa con revisiones del diseño e inspecciones de código 
http://www.software-engin.com/
http://www.software-engin.com/
16 
 
hasta la prueba del producto. La verificación y la validación no son lo mismo, aunque a 
menudo se confunden. Validación: ¿Estamos construyendo el producto correcto?, 
Verificación: ¿Estamos construyendo el producto correctamente? 
Estas definiciones nos dicen que el papel de la verificación implica comprobar que el 
software está de acuerdo con su especificación. Debería comprobarse que satisface los 
requerimientos funcionales y no funcionales. La validación, es un proceso más general, 
su objetivo es asegurar que el sistema software satisface las expectativas del cliente. 
El último objetivo del proceso de verificación y validación es establecer la seguridad de 
que el sistema software está «hecho para un propósito. Lo que significa que el sistema 
debe ser lo suficientemente bueno para su uso. El nivel de confianza requerido depende 
del propósito del sistema, las expectativas de los usuarios del sistema y el entorno de 
mercado actual del sistema: 
Función del software, el nivel de confianza requerido depende de lo crítico que sea el 
software para una organización. Por ejemplo, el nivel de confianza requerido para el 
software que se utiliza para controlar un sistema de seguridad crítico es mucho más alto 
que el requerido para un prototipo de un sistema software que ha sido desarrollado para 
demostrar algunas ideas nuevas. 
Expectativas del usuario, una reflexión lamentable sobre la industria del software es 
que muchos usuarios tienen pocas expectativas sobre su software y no se sorprenden 
cuando éste falla durante su uso. Están dispuestos a aceptar estos fallos del sistema 
cuando los beneficios de su uso son mayores que sus desventajas. Actualmente es menos 
aceptable entregar sistemas no fiables, por lo que las compañías de software deben 
invertir más esfuerzo para verificar y validar. 
Entorno de mercado, Cuando un sistema se comercializa, los vendedores del sistema 
deben tener en cuenta los programas competidores, el precio que sus clientes están 
dispuestos a pagar por el sistema y la agenda requerida para entregar dicho sistema. 
Las pruebas de validación intentan demostrar que el software es el que el cliente quiere 
que satisfaga sus requerimientos. Como parte de la prueba de validación, se pueden 
utilizar pruebas estadísticas para probar el rendimiento y la fiabilidad de los programas, 
y para comprobar cómo trabaja en ciertas condiciones operacionales. Sin embargo, la 
verificación, validación y la depuración tienen diferentes objetivos: 
1. Los procesos de verificación y validación intentan establecer la existencia de 
defectos en el sistema software. 
2. La depuración es un proceso que localiza y corrige estos defectos. 
17 
 
 
Localizar los defectos en un programa no es un proceso sencillo, ya que el defecto puede 
no estar cerca del punto en el que falló el programa. Para localizar un defecto de un 
programa, se puede tener que diseñar pruebas adicionales que reproduzcan el defecto 
original y que determinen con precisión su localización en el programa. Se puede tener 
que hacer manualmente una traza del programa, línea por línea. Las herramientas de 
depuración que recopilan información sobre la ejecución del programa también pueden 
ayudar a localizar la fuente de un problema. 
Figura 8 
El proceso de depuración 
 
 
Fuente: (Ian Sommerville, 2005) 
 
1.6 Desarrollo de aplicaciones web 
Actualmente es común implementar la interfaz de una aplicación utilizando páginas web 
en vez de las ventanas y controles convencionales específicos de un sistema operativo 
como puede ser Windows, en muchas situaciones es preferible crear aplicaciones web a 
las que se accede a través de Internet. 
Se denominan aplicaciones web a aquellas aplicaciones cuya interfaz se construye a 
partir de páginas web. Las páginas web no solo son ficheros de textoplano en un 
formato estándar denominado HTML [HyperText Markup Language]. Estos ficheros se 
almacenan en un servidor web al cual se accede utilizando el protocolo HTTP 
[HyperText Transfer Protocol], es suficiente tener instalado un navegador web en esa 
máquina, Desde la máquina cliente, donde se ejecuta el navegador, se accede a través de 
http://www.software-engin.com/
18 
 
la red al servidor web donde está alojada la aplicación y de esa forma, se puede utilizar 
la aplicación web sin que el usuario tenga que instalarla previamente en su máquina. 
Si las páginas desarrolladas son realizadas exclusivamente en HTML estándar, podemos 
conseguir que esta funcione prácticamente sobre cualquier plataforma, siempre y cuando 
se disponga de un navegador web. Una interfaz construida de esta manera nos permite 
olvidarnos de los detalles específicos de los diferentes entornos gráficos existentes. 
Evolución de las aplicaciones web 
La característica más destacable de las páginas web es la de enlazar un texto con otro 
para crear un hipertexto. El éxito de este es relativamente reciente, se remontan al 
sistema Memex ideado por Vannevar Bush ("As we may think", Atlantic Monthly, julio 
de 1945). El término hipertexto como tal lo introdujo Ted Nelson en 1965 haciendo 
referencia a una colección de documentos (nodos) con referencias cruzadas (enlaces), 
esto se podía explorar con la ayuda de un navegador que nos permitiese movernos 
fácilmente entre documentos. 
La versión que conocemos actualmente del hipertexto proviene del interés de los 
científicos en compartir sus documentos y hacer referencias a otros documentos. Este 
interés propició la creación de la "tela de araña mundial" (World-Wide Web, WWW) en 
el Centro Europeo para la Investigación Nuclear (CERN). Tim Berners-Lee, uno de los 
científicos que trabajaba allí, ideó el formato HTML para representar documentos con 
enlaces a otros documentos. Dicho formato fue posteriormente establecido como 
estándar por el W3C (World-Wide Web Consortium, http://www.w3c.org/), el organismo 
creado por el MIT que fija los estándares utilizados en la web desde 1994. 
(Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
HTML 
El servicio de Internet sin duda es más utilizado hoy en día es la World Wide Web 
(WWW), esta es una aplicación que nos permite enlazar documentos fácilmente. Para 
generar estos documentos web, más conocidos como páginas web, se utiliza un formato 
conocido como HTML [HyperText Markup Language]. 
HTML es un fichero de texto normal plano y corriente (fichero ASCII, por lo general). 
Este fichero incluye una serie de marcas o etiquetas, estas indican al navegador cómo 
debe ser visualizado el documento. Las etiquetas llevan un formato similar a un 
documento XML, ya que por lo general van en parejas. 
 
19 
 
Cualquier documento en formato HTML, delimitado por la pareja de etiquetas <HTML> 
y </HTML>, tiene dos partes principales: 
1. La cabecera (entre <HEAD> y </HEAD>) contiene información general sobre el 
documento que no se muestra en pantalla: título, autor, descripción, etc. 
2. El cuerpo (entre <BODY> y </BODY>) donde se definen todo el cuerpo del 
documento 
Figura 9 
Ejemplo de documento HTML 
 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
El cuerpo en sí es la parte esencial ya que contiene toda la lógica y estructura que se 
mostrara al usuario final. 
 
HTML estático 
 
Al inicio, las páginas web se limitaban a tener ficheros almacenados en formato HTML 
[HyperText Markup Language]. Estos documentos no son más que ficheros de texto a 
los que se le añaden una serie de etiquetas. Estas etiquetas delimitan los fragmentos del 
texto que han de ser mostrados al usuario, en un formato determinado y también sirven 
para crear enlaces entre documentos. 
Hoy en día, una aplicación se encarga de generar los documentos HTML con el formato 
establecido más adecuado para nuestro sitio web. Dichos documentos HTML son 
almacenados de forma permanente en ficheros y el usuario accede a estos directamente. 
20 
 
Pero en realidad, el usuario no accede directamente a los ficheros que contienen los 
documentos HTML, utilizan un traductor (navegador) para visualizar cómodamente 
dichas páginas web. Un navegador es una aplicación cliente que utiliza el protocolo 
HTTP [HyperText Transfer Protocol] para acceder a la máquina que aloja nuestros 
ficheros en formato HTML. 
 
Para que los usuarios puedan acceder a nuestras páginas web, sólo necesitaremos un 
servidor web que atienda las peticiones HTTP generadas por el navegador web del 
usuario. Por el lado del servidor HTTP que utilicemos, este le enviará al navegador los 
documentos que haya solicitado. 
Figura 10 
Configuración de una aplicación web 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
Aplicaciones web 
La creación de aplicaciones web, requiere la existencia de un software corriendo en la 
maquina servidor, que genere automáticamente los ficheros HTML que se visualizan en 
el navegador del usuario. De la misma forma que cuando utilizábamos páginas estáticas 
en formato HTML, la comunicación entre el cliente y el servidor se sigue realizando a 
través del protocolo HTTP. La única diferencia consiste en que, ahora, el servidor HTTP 
delega en otros módulos la generación dinámica de las páginas HTML que se envían al 
cliente. Aunque, desde la perspectiva del cliente, la conexión se realiza de la misma 
forma. 
Desde el punto de vista del programador, puede optar por desarrollar software que se 
ejecute en el servidor o, incluso, en la propia máquina del usuario. 
21 
 
Las páginas web que son mostradas por el navegador al usuario se generan 
dinámicamente en el lado del servidor, si bien también se puede introducir cierto 
comportamiento dinámico en el navegador del cliente, se puede llegar a perder 
independencia entre el navegador y nuestra aplicación web. 
Figura 11 
Generación dinámica por cada solicitud 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
Desarrollo de aplicaciones Web 
Actualmente existe una tendencia marcada que fomenta la utilización de estándares de 
Internet para el desarrollo de aplicaciones. Si nos centramos en el desarrollo del interfaz 
de usuario de estas aplicaciones, nos encontramos es un uso extensivo de los estándares 
abiertos utilizados en la web, estos que son promovidos por el W3C. 
Las aplicaciones web comparten una característica la que es de centralizar el software, 
esto para facilitar las tareas de mantenimiento y actualización de grandes sistemas. Evita 
tener copias del sistema en todos los puestos de trabajo ya que esto nos garantiza que 
todos los usuarios estén con la última versión y que esta funcione correctamente. 
 
Podemos diferenciar dos tipos de aplicaciones, aplicaciones del lado del cliente, 
aplicaciones del lado del servidor. 
Toda aplicación web se puede desarrollar de tal forma que el trabajo lo realice el 
servidor y que el navegador se limite a mostrar páginas HTML. Sin embargo, esta 
opción no resulta atractiva del lado del cliente, hace difícil, sino imposible, construir 
interfaces de usuario amigables restringiéndose a esta opción. 
Es por esta razón que se debe diferenciar características que deben ser ejecutadas del 
22 
 
lado del cliente y las que serán ejecutadas y procesadas por el lado del servidor. 
Se debe tener cuidado en qué tipo de operaciones se realizarán en el lado del cliente, ya 
que si involucra criterios de acceso a información sensible, esta puede ser robada o 
utilizada de forma inadecuada. 
 
HTML dinámico y JavaScript 
La Herramienta más utilizada al momento de dar nuestras páginas HTML cierto 
comportamiento dinámico. El HTML dinámico (DHTML) se basa en construir un 
modelo final basado en objetos que son componentes de la estructura HTML. 
La modificaciónde estos se realiza a través de macros o scripts que por lo general son 
incluidos en el mismo fichero, lo mejor es separar estos scripts del HTML para no 
mezclar los detalles del HTML de la interfaz con la lógica de dichos scripts. 
Figura 12 
DHTML DOM [Document Object Model] 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
Cada etiqueta HTML se convierte en un objeto que cuenta con sus respectivas 
propiedades y eventos. Los scripts han de proporcionarle al navegador el código 
correspondiente para los distintos eventos que puedan surgir en la interacción con cada 
uno de los objetos que lo componen. 
23 
 
Por cuestiones de portabilidad, los scripts son usualmente realizados utilizando 
JavaScript, esto por cuestiones de portabilidad, aunque existe un estándar oficial de 
JavaScript ratificado por ECMA (por lo que se le suele llamar ECMAScript), cada 
navegador implementa versiones modificadas diferentes de JavaScript. 
 
ASP: Active Server Pages 
 
ASP es la tecnología de Microsoft que permite desarrollar aplicaciones web que ejecuten 
en el servidor HTTP de Microsoft. El desarrollo de aplicaciones utilizando páginas ASP 
consiste, básicamente, fragmentos de código dentro de los documentos HTML que 
sirven para crear las interfaces de usuario de las aplicaciones web. Los fragmentos de 
HTML proporcionan la parte estática de lo que ve el usuario mientras que los 
fragmentos de código generar la parte dinámica. Esto suele conducir a mezclar los 
detalles de la interfaz con la lógica de la aplicación, algo que, repetimos, no suele ser 
demasiado recomendable. 
 
Una página ASP no es más que un fichero HTML con extensión .asp (.aspx en el caso de 
ASP.NET) al que le añadimos algo de código. Este código se puede implementar 
utilizando distintos lenguajes interpretados. Por lo general, se emplea una variante de 
Visual Basic conocida como VBScript [Visual Basic Script]. Cuando alguien accede a la 
página, el Internet Information Server interpreta el código que incluye la página y 
combina el resultado de su ejecución con la parte estática de la página ASP (la parte 
escrita en HTML convencional). Una vez interpretada la página ASP, el resultado final 
es lo que se envía al navegador web instalado en la máquina del usuario que accede a la 
aplicación. (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006). 
 
 
 
 
 
 
 
24 
 
Figura 13 
Funcionamiento de las paginas ASP 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
Podemos nombrar cinco componentes esenciales en la interacción cliente/servidor al 
momento en que un cliente solicita servicios a un servidor. 
Figura 14 
Componentes cuando cliente solicita servicios a servidor 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
Solo basta con escribir una página ASP y guardarla en algún directorio que se pueda 
acceder a través del Internet Information Server, sin tener que compilarlas previamente. 
 
 
25 
 
Un ejemplo básico de código ASP es el siguiente: 
Figura 15 
Ejemplo de código básico ASP 
 
 
Fuente: Elaboración Propia 
 
El código que se encuentra entre los tags <% y %> contiene la parte de la página ASP, 
este es interpretado en el servidor antes de enviarle una respuesta al navegador del 
cliente. 
 
El código incluido en páginas ASP más complejas resulta más extenso y poco legible, 
esto hace que sea mucho más difícil de mantener ya que se encuentra mezclado con el 
código HTML de la interfaz de usuario. En ASP, el fragmento de código debe ser 
colocado en el sitio donde queremos que su salida aparezca, lo que hace imposible 
separar los detalles de la interfaz con la lógica de negocio. 
Esto dificulta la reutilización de código y su mantenimiento, también complica el 
soporte de nuestra aplicación para los distintos navegadores del mercado. 
 
ASP.NET: Aplicaciones web en la plataforma .NET 
ASP.NET es el nombre con el que se conoce la parte de la plataforma .NET que permite 
el desarrollo y ejecución tanto de aplicaciones web como de servicios web. Igual que 
sucedía en ASP, ASP.NET se ejecuta en el servidor. En ASP.NET, no obstante, las 
aplicaciones web se suelen desarrollar utilizando formularios web, que están diseñados 
para hacer la creación de aplicaciones web tan sencilla como la programación en Visual 
Basic (.NET, claro está). (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 
2006). 
 
26 
 
Figura 16 
Ejemplo de pagina ASP.NET 
 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
Podemos apreciar ciertos puntos en el código anterior, las etiquetas HTML no se 
encuentran mezcladas con el código. 
 
ASP.NET es parte de la tecnología .NET, los formularios Windows y los formularios 
ASP.NET son las herramientas principales para construir interfaces de usuario en .NET. 
Pero esto no quiere decir que podamos mezclarlos. 
 
 
 
 
 
 
27 
 
Figura 17 
Plataforma .NET 
 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
La programación en ASP.NET se basa en el uso de eventos y controles, implementan su 
funcionalidad en fragmentos de código que son ejecutados como respuesta a eventos, 
estos eventos a su vez se encuentran asociados a controles de la interfaz. Esto 
proporciona un mayor nivel de abstracción, requiere menos código y permite crear 
aplicaciones más modulares, legibles y mantenibles. 
 
 
 
 
 
28 
 
Figura 18 
Eventos en ASP.NET 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
El código se ejecuta en el lado del servidor en función a los eventos que definamos para 
los controles y páginas que conforman la interfaz de nuestra aplicación web. 
ASP.NET es el encargado de convertir las etiquetas y tags en código HTML que resulte 
más adecuado para mostrar los controles dependiendo del navegador que sea utilizado 
por el cliente. De esta forma, ASP.NET garantiza la compatibilidad de los controles de 
nuestra aplicación web con distintos navegadores, sin que el programador tenga que 
preocuparse demasiado de las diferencias existentes entre los diferentes navegadores 
web que puede emplear el usuario final para acceder a nuestra aplicación. (Fernando 
Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006). 
 
 
 
 
 
 
29 
 
Figura 19 
ASP.NET se encarga de mostrar formularios web de la plataforma que resulte mas 
adecuada para el navegador que utilice el usuario final de la aplicación 
 
Fuente: (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006) 
 
Creación de páginas ASP.NET 
La biblioteca provista por la tecnología .NET incluye una amplia gama de controles que 
podremos utilizar en la construcción de interfaces web para nuestras aplicaciones, 
controles tales como botones, cajas de texto, listas o tablas. 
Una aplicación web está formada por varios formularios web. Cada uno de estos serán 
implementados como paginas ASP.NET, estas se construye creando clases derivadas de 
System.Web.UI.Page. Dicha clase proporciona la base sobre la que construiremos 
nuestras páginas ASP.NET, que implementaremos como subclases de 
System.Web.UI.Page en las que incluiremos la funcionalidad requerida por nuestras 
aplicaciones. 
Para mantener la independencia entre la interfaz de usuario y la lógica asociada a la 
aplicación, la página ASP.NET será divida en dos ficheros. El primero con extensión 
.aspx, donde especifica el aspecto de la interfaz, utilizando etiquetas HTML. En segundo 
un .cs, en el que utilizaremos código C#, donde implementaremos la lógica de la 
aplicación. 
 
30 
 
 
Organización de la interfaz de usuario 
La principal tentación de un programador de aplicaciones web es la de escribir todo el 
código en la propia página ASP.NET. El problema que lleva esta acción es más notorio 
cuando la aplicación empiezaa crecer y/o se agrega nueva funcionalidad, empiezan a 
aparecer ciertas redundancias, código duplicado. El mantenimiento de la aplicación y la 
realización de nuevas mejoras se convierten en un dolor de cabeza. 
 
Cuando estas situaciones se presentan, la mejor opción es la de encapsular la lógica en 
componentes independientes. Esto elimina la redundancia e incrementa la complejidad 
de la aplicación. Claro que introduciendo complejidad a la aplicación, esta será más 
difícil de entender por otros programadores. 
Para este caso existen soluciones que consiguen dotar a nuestras aplicaciones de cierta 
flexibilidad sin incrementar excesivamente la complejidad. Tal es el caso del modelo 
MVC [Model-View-Controller], en el que se distinguen tres componentes bien 
diferenciados: 
- Modelo. Encapsula los datos y el comportamiento de la aplicación. Este trabaja 
independientemente de cómo los datos van a ser mostrados. 
 
- Vista. Estas consultan el estado del modelo para mostrárselo al usuario. 
 
- Controlador. Encargado de permitir al usuario de realizar acciones, estas pueden 
involucrar solamente a la vista o incluir operaciones sobre el modelo. 
 
 
 
 
 
 
 
 
31 
 
 
Figura 20 
MVC 
 
 
Fuente: http://www.judavi.com/media/2011/10/image10.png 
 
En MVC, las vistas y los controladores dependen del modelo, pero el modelo no 
depende de la vista ni del controlador. Esto permite que el modelo sea totalmente 
independiente de la presentación visual, de tal forma que, el modelo pueda ser 
reutilizado en diferentes vistas. El modelo MVC ayuda a modularizar correctamente una 
aplicación en la cual el usuario manipula datos a través de una interfaz. Si el usuario 
puede trabajar con los mismos datos de distintas formas, lo habitual es encapsular el 
código compartido en un módulo aparte con el fin de evitar la existencia de código 
duplicado. (Fernando Berzal, Francisco J. Cortijo, Juan Carlos Cubero, 2006). 
 
1.7 Framework 
Nos referimos a framework a una estructura software compuesta de componentes 
personalizables e intercambiables para el desarrollo de una aplicación. Un framework, es 
la estructura de un software que debe ser adaptado a la medida por el programador de la 
aplicación. También incorpora las partes esenciales y comunes de una familia de 
aplicaciones de un dominio determinado. 
 
32 
 
La construcción de frameworks ha seguido un diseño orientado a objetos, aunque no 
necesariamente. Esta consiste de muchas clases que a diferencia de una librería de 
clases, colaboran según un orden o lógica prestablecida que por un lado la limita en 
cuanto al tipo de aplicación a desarrollar, al mismo tiempo que hace posible verla como 
una solución genérica a un conjunto de aplicaciones. 
 
Las ventajas de un framework, son que permiten desarrollar aplicaciones de calidad a un 
menor costo y menor tiempo, ya que se pueden reutilizar fácilmente los algoritmos, 
análisis de requerimientos, esquemas de base de datos o promover buenas prácticas de 
desarrollo. 
1.7.1 Tipos de framework 
Se pueden clasificar a los frameworks según la forma en que se construye, la forma en 
que se puede desarrollar aplicaciones a partir de él, podemos distinguir tres tipos de 
frameworks: 
Frameworks de Caja Blanca 
La instanciación del framework es posible a través de la creación de nuevas clases. Estas 
clases y el código correspondiente se pueden introducir por herencia o composición. Se 
agregan nuevas funcionalidades creando una subclase de una clase que ya existe en el 
framework. Para usar frameworks de caja blanca el desarrollador de aplicaciones debe 
conocer muy bien cómo funciona el framework. 
 
Frameworks de Caja Negra 
 
Este tipo producen instancias usando scripts de configuración del framework, con los 
que se configura la aplicación final. Tienen la ventaja que no se requiere que el 
desarrollador de aplicaciones conozca los detalles internos del framework, por lo cual 
son mucho más fáciles de utilizar. 
 
 
Frameworks de Caja Gris 
La mayoría de los frameworks son de Caja Gris, ya que son aquellos que contienen 
elementos de Caja Blanca y Caja Negra, algunas partes se implementan vía herencia o 
composición, y otras a través de configuración de parámetros. 
 
33 
 
1.7.2 Propiedades de un framework 
 
Los frameworks son hechos para ser utilizados en aplicaciones específicas, por lo cual lo 
más importante que debe cumplirse es la reusabilidad, en otras palabras, las ideas, el 
diseño y el código son desarrollados una vez, y luego usados para resolver muchos 
problemas, consiguiendo así productividad, confiabilidad y calidad. Las propiedades de 
un framework son: 
Fácil de Usar 
Se refiere a la capacidad que tiene el desarrollador de aplicaciones para usar el 
framework, el cual debe ser comprensible y debe facilitar el desarrollo de aplicaciones. 
Los frameworks son para ser reusados, pero aún uno muy bien diseñado, puede no ser 
usado si es difícil de entender. Para ayudar a la comprensión, el framework debe ser 
documentado con ejemplos de aplicaciones y ejemplos que el desarrollador pueda usar. 
Extensibilidad 
Si nuevos componentes o propiedades pueden ser agregados a un framework fácilmente, 
se dice que este es extensible. Un framework aunque sea fácil de usar, debe ser 
extensible. Puede contar con una lista definida y acotada de características, y puede ser 
muy fácil de comprender y usar, pero su reusabilidad es mayor si es fácilmente 
extensible para incluir nuevas operaciones. 
Flexibilidad 
Los frameworks que pueden ser usados en múltiples dominios, como por ejemplo un 
framework de interfaz de usuario, son especialmente flexibles. Si un framework es 
aplicable a un dominio amplio, o a varios dominios, entonces este será re-usado por más 
desarrolladores. Sin embargo, la flexibilidad debe ser balanceada con la facilidad de uso. 
Completitud 
La completitud se refiere a que el framework cubra todos los posibles problemas del 
dominio especificado. Aunque los frameworks generalmente sean incompletos, ya que 
no cubren todas las posibles variaciones de un dominio, cierta completitud es una 
propiedad deseable. 
 
 
34 
 
Consistencia 
Debe haber convenciones respecto a los conceptos y definiciones que se usan a lo largo 
del framework. Se debe usar nombres consistentemente en todo el framework, para 
facilitar la comprensión de los desarrolladores y ayudarlos a reducir errores en su uso. 
 
1.7.3 Arquitectura de un framework 
Se puede identificar partes en una aplicación desarrollada a partir de un framework. 
Figura 21 
Arquitectura de un framework 
 
Fuente: 
http://htmlimg4.scribdassets.com/8fk416n9q81eqmnl/images/21c58180dc0d.jpg 
 
- Core del framework, consiste de clases abstractas, que definen la estructura 
genérica, el diagrama de flujo y el comportamiento del framework. Este forma la 
base de la aplicación desarrollada a partir del framework. 
- Biblioteca del framework, consiste de componentes concretas que puedan ser 
usadas con pequeñas modificaciones por las aplicaciones desarrolladas del 
framework. 
- Extensiones de la aplicación, son extensiones específicas de la aplicación hechas 
al framework. 
- Aplicación, consiste del core del framework, de las partes usadas de la biblioteca 
del framework, y algunas extensiones específicas necesarias para la aplicación. 
- Clases no usadas de la librería, no todas las clases de un framework serán 
necesarias en una aplicación desarrollada a partir de un framework. 
35 
 
1.7.4 Desarrollo de un framework 
 
En general un desarrollo orientado a objeto, y en particular el desarrollo de un 
framework requiere un enfoque iterativo o cíclico, en el cual el framework es definido, 
testeado y refinado un número de veces. 
 
Las metodologías usuales de diseño orientado a objeto no son suficientes para los 
frameworks, ya que difieren al menos en dos aspectos. Primero el nivel deabstracción es 
distinto, ya que los frameworks proveen una solución para un dominio entero de 
problemas, mientras que las aplicaciones resuelven un problema concreto. Segundo, los 
frameworks son por naturaleza incompletos, a diferencia de una aplicación, lo que 
genera complicaciones, por ejemplo, en la etapa del testeo, ya que un framework no se 
puede probar directamente, sino que a través de aplicaciones que se derivan de él. 
 
1.7.5 Diseño e implementación 
 
El diseño e implementación del framework están relacionados. Las abstracciones pueden 
ser difíciles de diseñar apropiadamente la primera vez y partes del framework deben ser 
re-diseñadas y re-implementadas. Partes del framework pueden sufrir rediseño mientras 
otras partes están siendo implementadas. Existen técnicas específicas que ayudan a la 
etapa de diseño del desarrollo de los frameworks, teniendo en común algunos consejos: 
- Reducir el número de clases y métodos que el usuario debe sobrescribir. 
- Simplificar la interacción entre el framework y las extensiones que hace la 
aplicación. 
- Aislar el código dependiente de la plataforma. 
- Consolidar funcionalidades similares en una sola abstracción. 
- Romper grandes abstracciones en pequeñas con gran flexibilidad. 
- Usar composición más que herencia. 
 
 
36 
 
 
1.7.6 Instanciación y testeo 
La instanciación se refiere a desarrollar aplicaciones a partir del framework, por medio 
de la implementación de los métodos. Hay dos formas de testear un framework. Primero, 
testear aisladamente, sin alguna aplicación que lo instancie. Testear por sí mismo el 
framework ayuda a identificar defectos, ya que se pueden separar los defectos, de los 
errores que pueden ser causados por una aplicación. Es importante detectar los defectos 
en un framework, ya que estos serán traspasados a todas las aplicaciones desarrolladas 
utilizando este. Segundo, el verdadero test de un framework ocurre sólo cuando éste es 
usado para desarrollar o probar aplicaciones. Instanciar el framework ayuda a exponer 
áreas donde el framework está incompleto y ayuda a mostrar áreas donde el framework 
necesita ser más flexible y fácil de usar. Las aplicaciones producidas por este tipo de 
testeo pueden ser parte de la documentación del framework, ya que indican cómo este se 
usa. 
 
1.7.7 Documentación de un framework 
La documentación de un framework puede ayudar en todos los aspectos de su uso. Ya 
que los creadores del framework no estarán siempre disponibles, la documentación pasa 
a ser el elemento clave, a través del cual los usuarios (desarrolladores de aplicaciones 
específicas) pueden aprender sobre él. Los comentarios del código y la 
documentación son parte necesaria de cualquier proyecto de programación, pero estos 
son especialmente necesarios cuando se está desarrollando un framework. Si los 
desarrolladores de aplicaciones no comprenden el framework, simplemente no lo usarán. 
 
Por eso se debe proveer bastante información para que los desarrolladores comprendan 
cómo usarlo, y así puedan conseguir la solución que ellos buscan. Hay que dejar claro 
qué clases pueden ser usadas directamente, qué clases pueden ser instanciadas y qué 
clases deben ser sobrescritas. Los desarrolladores están interesados en resolver su 
problema particular, por lo que no son tan importantes los detalles de la implementación 
del framework. 
 
 
37 
 
1.8 TPL 
Muchos equipos de trabajo tienen dos o cuatro núcleos, que permiten ejecutar varios 
subprocesos simultáneamente. Se espera que los equipos en un futuro tengan 
significativamente más núcleos. Para aprovecharse del hardware de hoy y de un futuro, 
puede paralelizar el código para distribuir el trabajo entre varios procesadores. En el 
pasado, el paralelismo requería manipulación de bajo nivel de los subprocesos y 
bloqueos. Visual Studio 2010 y .NET Framework 4 mejoran la compatibilidad para la 
programación paralela proporcionando un nuevo runtime, nuevos tipos de biblioteca de 
clases y escalable, de forma natural sin tener que trabajar directamente con subprocesos 
ni el bloque de subprocesos. 
Figura 22 
Task Parallel Library 
 
 
Fuente: 
http://htmlimg1.scribdassets.com/97h89st4jk17paid/images/12340c1b159.png 
 
La biblioteca TPL (Task Parallel Library, biblioteca de procesamiento paralelo basado 
en tareas) es un conjunto de API y tipos públicos de los espacios de nombres 
38 
 
System.Threading.Task y System.Threading de .NET Framework 4. La biblioteca TPL se 
la creo con el propósito de aumentar la productividad de los desarrolladores al 
simplificar el proceso de agregar paralelismo y simultaneidad a las aplicaciones. 
Además, la biblioteca TPL se encarga de la división del trabajo, la programación de los 
subprocesos en ThreadPool, la compatibilidad con la cancelación, la administración de 
los estados y otros detalles de bajo nivel. Al utilizar TPL, el usuario puede optimizar el 
rendimiento del código mientras se centra en el trabajo del programa que está diseñado. 
Paralelismo de datos 
El paralelismo de datos hace referencia a los escenarios en los que la misma operación 
realiza simultáneamente en elementos de una colección o matriz de origen. Varias 
sobrecargas de los métodos Foreach y For admiten el paralelismo de los datos con 
sintaxis imperativa en la clase System.Threading.Task.Parallel. En las operaciones 
paralelas de datos, se crean particiones de la colección de origen para que varios 
subprocesos puedan funcionar simultáneamente en segmentos diferentes. 
TPL admite el paralelismo de datos a través de la clase System.Threading.Task.Parallel. 
Esta clase proporciona las implementaciones paralelas basadas en método de los bucles 
For y Foreach. Se escribe la lógica del bucle para un bucle Parallel.For y 
Parallel.Foreach, de forma muy similar a como se escribía en un bucle secuencial. Por 
ejemplo: 
Figura 23 
Ejemplo paralelismo de datos 
 
Fuente: Elaboración propia. 
Cuando un bucle paralelo se ejecuta, la TPL crea particiones del origen de datos para 
que el bucle pueda funcionar simultáneamente en varias partes. En segundo plano, el 
programador de tareas crea particiones de la tarea según los recursos del sistema y la 
carga de trabajo. 
39 
 
Paralelismo de tareas 
Esta hace referencia a la ejecución simultanea de una o varias tareas independientes. 
Una tarea es una operación asíncrona, esta se asemeja a la creación de un nuevo 
subproceso o elemento de trabajo ThreadPool, pero con un nivel de mayor abstracción. 
Estas tareas dan dos ventajas fundamentales: 
- El uso eficaz y mucho más escalable de los recursos de los sistemas. En segundo 
plano, las tareas se ponen en la cola del elemento ThreadPool, que se a mejorado 
con algoritmos que determinan y ajustan el número de subprocesos con el que se 
maximiza el rendimiento. Esto hace que las tareas resulten relativamente ligeras y 
que, por tanto, pueda crearse un gran número de ellas para habilitar un 
paralelismo por menor. 
- Un mayor control mediante programación donde se puede conseguir con un 
subproceso o un elemento de trabajo. 
Crear y ejecutar tareas implícitamente, el método Parallel.Invoke proporciona una mejor 
manera de ejecutar cualquier número de acciones arbitrarias simultáneamente. Pase a un 
delegado Action por cada elemento de trabajo. Por ejemplo: 
Figura 24 
Ejemplo paralelismo de tareas 
 
 
Fuente: Elaboración propia. 
 
 
1.9 Pruebas de unidad 
Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de 
cada componente individualmente una vez que ha sido codificado. Las pruebas de 
unidad son un proceso para probar los subprogramas, los procedimientos individuales o 
las clases en un programa. 
40 
 
Es decir, es mejor probar primero los bloques desarrollados más pequeños del programa, 
que inicialmente probar el software en su totalidad. Las motivaciones para hacer esto