Desarrollo de aplicaciones web en el entorno servidor

Desarrollo de aplicaciones
web en el entorno servidor
Programación web en el entorno servidor
02/11/2017
José Miguel Castillo Castillo

DESARROLLO DE APLICACIONES WEB EN EL ENTORNO SERVIDOR
1
INDICE DE CONTENIDO. DESARROLLO DE APLICACIONES WEB EN EL ENTORNO
SERVIDOR
1 EL PROCESO DEL DESARROLLO DE SOFTWARE
1.1 Modelos del ciclo de vida del software
1.2 Análisis y especificación de requisitos
1.3 Diseño
1.4 Implementación. Conceptos generales de desarrollo de software
1.5 Validación y verificación de sistemas
1.6 Pruebas de software
1.7 Calidad del software
1.8 Herramientas de uso común para el desarrollo de software
2 LA ORIENTACIÓN A OBJETOS
2.1 Principios de la orientación a objetos
2.2 Clases de objetos
2.3 Objetos
2.4 Herencias
2.5 Modularidad
2.6 Generalidad y sobrecarga
2.7 Desarrollo orientado a objetos
2.8 Lenguajes de modelización en el desarrollo orientado a objetos
3 ARQUITECTURAS WEB
3.1 Concepto de arquitectura web
3.2 El modelo de capas
3.3 Plataformas para el desarrollo en las capas servidor
3.4 Herramientas de desarrollo orientadas a servidor de aplicaciones web
4 LENGUAJES DE PROGRAMACIÓN DE APLICACIONES WEB EN EL LADO SERVIDOR
4.1 Características de los lenguajes de programación
4.2 Tipos y características de los lenguajes de uso común
4.3 Criterios en la elección de un lenguaje de programación
4.4 Características generales
4.5 Gestión de la configuración
4.6 Gestión de la seguridad
4.7 Gestión de errores
4.8 Transacciones y persistencia
4.9 Componentes en servidor
4.10 Modelos de desarrollo
4.11 Documentación del software. Inclusión en código fuente. Generadores de
documentación.

2
1. EL PROCESO DEL DESARROLLO DE SOFTWARE
Tanto en el proceso de desarrollo del software como del hardware se siguen unas fases de análisis,
diseño y desarrollo. En el caso de producción de hardware a gran escala, el coste del producto
depende del coste de los materiales empleados y del propio proceso de producción, no influyendo
tanto en el coste las fases previas de ingeniería. La situación del desarrollo de software es diferente
ya que la producción a gran o pequeña escala no influye en el impacto que tiene la ingeniería en el
coste, al ser un producto inmaterial.
Hay que destacar que el software no requiere un control de calidad individualizado, cosa que sí que
ocurre en el hardware, y los costes del software radican en el desarrollo de la ingeniería y no en la
producción.
1.1. Modelos del ciclo de vida del software
En cascada (waterfall).
Este es el más básico de todos los modelos. Su visión plantea un desarrollo basado en la secuencia
simple de fases que poseen un conjunto de metas bien definidas.
En la etapa final de cada una de las fases se reúne la documentación para garantizar que cumple con
las especificaciones y los requisitos antes de pasar a la siguiente fase.
Su punto débil es la habitual falta de comunicación con el usuario final y las características
primordiales son:
 Planear un proyecto antes de embarcarse en él.
 Definir el comportamiento externo antes de diseñar su arquitectura interna.
 Documentar los resultados de cada actividad.
 Diseñar un sistema antes de codificarlo.
 Testear el sistema después de construirlo.

3
Iterativo.
Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, un
constante análisis actualizado del sistema. El objetivo del diseño e implementación de cualquier
iteración debe ser simple, directa y modular.
El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El
análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las
funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad,
usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas).
Las normas básicas que deben regir los distintos análisis son:
 Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar
a la necesidad de rediseñar o vuelta a codificar.
 Las modificaciones deben ajustarse fácilmente a los módulos comunes y a los aislados.
 Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones.
 Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen
necesarios para evitar el rediseño durante una fase de implementación.
 La implementación existente debe ser analizada frecuentemente para determinar qué tal se
ajusta a las metas del proyecto.
 Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el
análisis de implementaciones parciales.
 La opinión del usuario debe ser solicitada y analizada para indicar deficiencias en la
implementación referida por él.
Incremental.
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes por lo que se usa
un desarrollo incremental como método de reducción de riesgos, construyendo sólo una parte del
sistema, reservando otros aspectos para niveles posteriores.
El desarrollo incremental es un proceso de construcción que paulatinamente va incrementando
subconjuntos de requerimientos del sistema.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
 Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
 Desarrollar parte de las funcionalidades es más sencillo de elaborar si los requerimientos
planeados para los niveles subsiguientes son correctos.
 Si un error importante es realizado, sólo la última iteración necesita ser descartada.
 Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema)
decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el
desarrollo.
 Si un error importante es realizado, el incremento previo puede ser usado.
 Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del
comienzo del próximo incremento.

4
En V.
Proporciona una guía para la planificación y realización de proyectos siguiendo un esquema similar a
la siguiente imagen.
Los siguientes objetivos están destinados a ser alcanzados durante la ejecución del proyecto:
 Minimización de los riesgos del proyecto.
Mejora la transparencia del proyecto y control del proyecto describiendo los resultados
correspondientes y funciones de responsabilidad.
Permite una detección temprana de las desviaciones y los riesgos y mejora la gestión de procesos,
reduciendo así los riesgos del proyecto.
 Mejora y Garantía de Calidad.
Asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada. Los
resultados provisionales definidos se pueden comprobar en una fase temprana.
La uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.
 Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida.
El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser
calculado, estimado y controlado de manera transparente mediante la aplicación de un modelo de
procesos estandarizados.
Se reduce la dependencia en los proveedores y el esfuerzo para las siguientes actividades y
proyectos.
Basado en componentes (CBSE).
La reutilización de software es un proceso de la Ingeniería de Software que conlleva al uso recurrente
de elementos o componentes software que están activos.
Según algunos autores, "un componente es una unidad de composición de aplicaciones software,
que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado,
adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en
tiempo y espacio”.

5
Las características de un componente se esquematizan bajo las siguientes premisas:
 Identificable. Debe tener una identificación que permita acceder fácilmente a sus servicios
que permita su clasificación.
 Contenido propio. Un componente no debe requerir de la utilización de otros para finiquitar
la función para la cual fue diseñado.
 Reemplazable. Se puede remplazar por nuevas versiones u otro componente que lo
remplace y mejore.
 Mantenimiento de servicios. Las funcionalidades ofrecidas en su interfaz no deben variar,
pero su implementación sí.
 Documentado. Un componente debe estar correctamente documentado para facilitar su
búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
 Genérico. Sus servicios deben servir para varias aplicaciones.
 Independiente de la plataforma.
El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo
en espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la creación del software.
El modelo de desarrollo basado en componentes conduce a la reutilización del software, y la
reutilización proporciona beneficios a los ingenieros de software.
Por ejemplo, según estudios de reutilización, QSM Associates, Inc. el ensamblaje de componentes
lleva a una reducción del 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 del coste del
proyecto y un índice de productividad del 26.2, comparado con la norma de industria del 16.9
Aunque estos resultados están en función de la robustez de la biblioteca de componentes, no hay
duda de que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros de
software.
El paradigma de ensamblar componentes y escribir código para hacer que estos componentes
funcionen se conoce como Desarrollo de Software Basado en Componentes. El uso de este
paradigma posee algunas ventajas:
 Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.
 Simplifica las pruebas.
 Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre
componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea
necesario, sin afectar otras partes del sistema.
 Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organización, la calidad de una aplicación basada en
componentes mejorará con el paso del tiempo.

6
De la misma manera, el optar por comprar componentes de terceros en lugar de desarrollarlos,
posee algunas ventajas:
 Ciclos de desarrollo más cortos.
 Mejor ROI.
 Funcionalidad mejorada.
Desarrollo rápido (RAD).
El desarrollo de software mediante métodos rápidos reduciendo el tiempo del ciclo de vida del
software (por lo tanto, acelerando el desarrollo) generando una versión prototipo y después
integrándola en el conjunto del proyecto de manera iterativa para satisfacer los requisitos del cliente
y controlar todo el ciclo de desarrollo.
Los métodos rápidos se originaron por la inestabilidad del entorno técnico y el hecho de que el
cliente a veces es incapaz de definir cada uno de los requisitos al inicio del proyecto.
El término rápido es una referencia a la capacidad de adaptarse a los cambios de contexto y a los
cambios de especificaciones que ocurren durante el proceso de desarrollo.
Los impulsores de este método redactaron un manifiesto en el que expresaron los siguientes puntos
principales:
 Individuos e interacciones en lugar de procesos y herramientas.
 Desarrollo de software en lugar de documentación exhaustiva.
 Trabajo con el cliente en lugar de negociaciones contractuales.
 Apertura para los cambios en lugar de cumplimiento de planes poco flexibles.
 Con la ayuda de los métodos rápidos, el cliente tiene control total de su proyecto y logra una
rápida implementación del software.
Ventajas e inconvenientes. Pautas para la selección de la metodología más adecuada
Hay distintos modelos de ciclo de vida que son utilizados para el desarrollo de un sistema software,
especificando el orden de las tareas o actividades involucradas, la coordinación entre ellas y la
posible realimentación. Es posible utilizar cualquier tipo ya existente o incluso elaborar uno propio.
Lo importante es optimizar el proceso de desarrollo conforme a los requerimientos que se nos piden
en el mismo logrando así desarrollar un programa de mayor calidad.

7
Los factores que influyen a la hora de elegir un ciclo de vida para resolver un problema son:
 Disponibilidad de recursos ya sean económicos, tiempo, equipos, humano, etc.
 Entender los requerimientos.
 Dominio del problema, si se tiene los conocimientos para dar solución al problema central.
 Complejidad y magnitud del proyecto.
1.2. Análisis y especificación de requisitos
El resultado del análisis de requisitos con el cliente debe quedar reflejado en un documento llamado
ERS (Especificación de Requisitos del Sistema) cuya estructura puede venir definida por varios
estándares, tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se
plasman las principales entidades que participarán en el desarrollo del software.
La captura, análisis y especificación de requisitos es fundamental puesto que de ello en gran medida
el logro de los objetivos finales.
La IEEE 830-1998 normaliza la creación de las especificaciones de requisitos de software (Software
Requirements Specification).
No siempre en la etapa de análisis de requisitos las distintas metodologías de desarrollo llevan
asociado un estudio de viabilidad y/o estimación de costes. El más conocido de los modelos de
estimación de coste del software es el modelo COCOMO.
La especificación de requisitos software es una descripción completa del comportamiento del
sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las
interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos
como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no
funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen
restricciones en el diseño o la implementación.
Por ejemplo, las restricciones en el diseño o en los estándares de calidad.
Tipos de requisitos.
En la ingeniería clásica, los requisitos se utilizan como datos de entrada en la etapa de diseño del
producto estableciendo qué debe hacer el sistema, pero no cómo hacerlo.
La fase de captura y registro de requisitos puede estar precedida por una fase de análisis conceptual
del proyecto. Esta fase puede dividirse en recolección de requisitos, análisis de consistencia e
integridad, definición en términos descriptivos para los desarrolladores y un esbozo de
especificación, previo al diseño completo.
En ingeniería de sistemas existen los siguientes tipos de requisitos:
1. Un requisito funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de
requisito específica algo que el sistema entregado debe ser capaz de realizar.
2. Un requisito no funcional especifica algo sobre el propio sistema, y cómo debe realizar sus
funciones.
Algunos ejemplos de estos aspectos son la disponibilidad, el testeo, el mantenimiento, la facilidad
de uso, etc.

8
3. Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto.
Por ejemplo, la compatibilidad con cierto sistema operativo o la adecuación a regulaciones
aplicables al producto.
Modelos para el análisis de requisitos.
Los modelos de análisis utilizan una mezcla de formatos en texto y diagramas para representar los
requisitos del software, las funciones y el comportamiento haciendo más fácil de comprender dicha
representación, ya que es posible examinar los requisitos desde diferentes puntos de vista
aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran
descuidos.
El modelo de análisis con UML comienza con la creación de escenarios en la forma de “los casos de
uso, diagrama de actividad y diagrama de carril”.
Este modelo en simples palabras sirve para una interacción más amena entre el sistema y el usuario.
 Caso de uso. Describe un escenario de un caso específico en un lenguaje directo desde el punto
de vista de un actor definido.
Por ejemplo,

9
 Diagrama de actividad. Es un modelo muy parecido al caso de uso pero mucho mejor
complementado y proporciona una representación del flujo de interacción dentro de un
escenario específico.
Por ejemplo,
 Diagrama de carril. Consiste en tomar el diagrama actividad y situarlo en filas o en carriles. En
este modelo los actores son fundamentales ya que en el diagrama de carril se especifica
claramente, con un carril, la responsabilidad a cada actor.
Por ejemplo,

10
Propiedades del DFD
 El nivel 0 del diagrama del flujo debe representar al software.
 La entrada y la salida primaria se deben establecer con cuidado.
 La refinación debe comenzar por el aislamiento de procesos, objetos de datos y almacenamiento
de datos candidatos a ser representados en el siguiente nivel.
 Todas las flechas y burbujas se deben rotular con el nombre.
 Se debe tener la continuidad de flujo al cambiar el nivel.
 La refinación de burbujas debe hacerse una por una.
Por ejemplo, este diagrama es orientado al tiempo y rendimiento.
 Modelos basados en clases.
Una clase orientada a objetos encapsula atributos de los datos pero también incorpora las
operaciones que manipulan los datos implicados por dichos atributos.
Por ejemplo,

11
Las clases se manifiestan en la siguiente forma: entidades externas, sucesos o eventos, cosas, papeles
o roles, unidades organizacionales, sitios y estructuras.
 Modelo CRC (clase-responsabilidad-colaborador).
El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio simple para
identificar y organizar las clases relevantes para los requisitos del sistema o producto.
Por ejemplo,
Un modelo CRC es una colección de tarjetas índices estándar que representan clases. La idea final es
poder desarrollar una representación organizada de las clases.
Existen diferentes categorías entre las clases que nos permite establecer la siguiente clasificación:
 Clases de entidad. Se extraen de manera directa del enunciado del problema.
 Clases de frontera. Se utilizan para crear la interfaz que el usuario ve y con la cual interactúa
cuando se utiliza el software.
 Clases de controlador. Manejan unidades de trabajo desde el inicio hasta el final.
 Responsabilidad. Son los atributos y las operaciones relevantes para la clase.
 Colaboradores. Son aquellas clases que se emplean para que una clase reciba la información
necesaria para completar una responsabilidad.
 Agregación. Son las subclases que forman parte de una clase, se conectan a través de una
relación de tipo "es parte de”.
 Diagrama de estado: Nos permiten representar los diferentes comportamientos de las clases.
Ejemplo de diagrama de estados,

12
 Diagrama de Secuencia: Representa el comportamiento al describir la forma en que las clases se
mueven de estado a estado.
Ejemplo de diagrama de secuencia.
Documentación de requisitos.
El objetivo principal de la tarea de documentar los requisitos del sistema es continuar con la
definición del sistema software a desarrollar, tomando como punto de partida los requisitos
generales y los casos de usos en su versión inicial, y considerando los objetivos de negocio y el
modelo de negocio a implantar.
Los casos de uso que se considere necesario se van completando con más información y los
requisitos generales se van detallando en requisitos funcionales, no funcionales, de integración y en
restricciones técnicas.
Por ejemplo,
Validación de requisitos.
Es muy importante asegurar la validez de los requisitos antes de comenzar estrictamente lo que es
un desarrollo de software. Para llevar a cabo tal tarea se suele realizar comprobando que el modelo
obtenido responde de la misma forma deseada que la que el cliente pide por un lado, y por otro a la
inversa si otras respuestas del modelo convencen al cliente. En algunos casos será necesario
construir prototipos con una funcionalidad similar muy reducida para que el cliente se haga una idea
aproximada del resultado.

13
Los parámetros a validar en los requisitos son:
 Validez. Hay que conocer a todos los potenciales usuarios ya que pueden tener puntos de vista
distintos y necesitar otros requisitos.
 Consistencia. No debe haber contradicciones entre unos requisitos y otros.
 Completitud. Deben estar todos los requisitos.
Esto es imposible en un desarrollo iterativo, pero, al menos, deben estar disponibles todos los
requisitos de la iteración en curso.
 Verificabilidad. Hay que comprobar que cada requisito se cumple.
Las principales técnicas de validación de requisitos son las siguientes:
- Dentro de los tipos principales de prototipos de interfaz de usuario los destacados son:
o Desechables. Se utilizan sólo para la validación de los requisitos y posteriormente se
desechan. Pueden ser prototipos en papel o en software.
o Evolutivos. Una vez utilizados para la validación de los requisitos, se mejora su calidad y se
convierten progresivamente en el producto final.
- Recorrido de casos de uso. El recorrido o walkthrough es una técnica de revisión de productos
tradicionalmente asociada a la inspección de código fuente. Su principal objetivo es encontrar
conflictos en el producto que se revisa, de forma que puedan plantearse alternativas y los
participantes aumenten su conocimiento del producto en cuestión.
Gestión de requisitos.
Entre los problemas del desarrollo de software destacan el inadecuado entendimiento de las
necesidades de los usuarios, la incapacidad de absorber cambios en los requisitos y las
insatisfacciones de los clientes.
Las principales causas de estas desavenencias son la administración insuficiente de requisitos, los
problemas que afectan la comunicación, las inconsistencias no detectadas entre requisitos, diseño y
programación, las validaciones tardías de requisitos, el enfrentamiento reactivo de riesgos y la
propagación de cambios sin control.
Podemos señalar entonces que los modelos de proceso de Ingeniería de Requisitos (IR) aún
presentan carencias. Es necesario proporcionar un procedimiento para efectuar la gestión de los
requisitos de un proyecto de software basado en la integración de las mejores prácticas, con un
enfoque holístico, proactivo y estratégico que potencie de manera efectiva el desempeño del
proceso de gestión de desarrollo del proyecto de software y la satisfacción del cliente.
Los principios para realizar la gestión de los requisitos del software son:
 El acuerdo de los requisitos es el puente entre el desarrollo de requisitos y la gestión de
requisitos.
 La gestión de requisitos incluye todas las actividades para mantener la integridad, exactitud y
difusión de los acuerdos de los requisitos durante la vida del proyecto.

14
1.3. Diseño
Según la IEEE610, el diseño se definido como: "El proceso de definición de la arquitectura,
componentes, interfaces y otras características de un sistema o componente que resulta de este
proceso".
Modelos para el diseño de sistemas.
Cada vez es mayor el número de organizaciones que son conscientes de la necesidad de gestionar su
información como un recurso de alto valor estratégico, pero que sin embargo tiene dificultades a la
hora de llevarla a la práctica.
A diferencia de lo que ocurre con otros ámbitos de gestión, no existen modelos formalizados para el
diseño e implementación de sistemas que gestionen la información.
La modelización presenta diferentes etapas:
 Investigación preliminar.
El objetivo de esta etapa es proporcionar a la organización la comprensión del contexto en el que
desarrolla su actividad lo que nos llevará a identificar los factores que más influyen en la creación de
un sistema de gestión de la información.
Se trata del punto de partida donde se recoge información sobre la visión que la entidad tiene
respecto al concepto y al valor de la información, ayudando a definir la situación en materia de
cultura de la información y a evaluar posibles carencias.
 Análisis de las actividades de la organización.
El objetivo de esta etapa consiste en desarrollar un modelo conceptual sobre qué hace una
organización y cómo lo hace.
Trata de medir el grado de satisfacción de sus necesidades de información sobre las áreas que deben
ser de su interés. Una cobertura oportuna de las áreas que deben ser conocidas y sobre las que hay
que disponer de la información relevante contribuirá a la toma de decisiones y a un posicionamiento
adecuado en el entorno.
 Identificación de los requisitos.
Consiste en identificar los requisitos que ha de cumplir la organización para hacer un seguimiento
estructurado y sistemático de la información. Los requisitos sobre la identificación y seguimiento de
las fuentes de información se definen a través de un análisis sistemático de las necesidades de la
organización. Esta etapa proporciona las razones para la identificación, seguimiento y análisis de las
fuentes de información, así como la base del diseño de los sistemas que se encargarán de
incorporarlas y mantenerlas.
 Evaluación de los sistemas existentes.
El objetivo de esta etapa consiste en analizar los procedimientos, herramientas y criterios empleados
para la clasificación, el almacenamiento, el acceso y la difusión de la información, con el fin de
valorar en qué medida la información se trata y se difunde de manera coherente con las actividades y
objetivos de la organización.

15
 Identificación de estrategias para cumplir los requisitos.
El objetivo de esta etapa consiste en evaluar el uso que la organización hace con la información
obtenida como herramienta para la toma de decisiones. A su vez, una adecuada puesta en valor de la
información debería facilitar las políticas, procedimientos, normas y planes que la organización
necesita para el éxito de su actividad.
Diagramas de diseño. El estándar UML.
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un
estándar para describir un modelo del sistema en el que se incorporan aspectos conceptuales como
los procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes
de programación, esquemas de bases de datos y compuestos reciclados.
UML es un lenguaje de modelado para especificar o para describir métodos o procesos.
Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y
construir.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado
de Modelado, no es programación, solo se esquematiza la realidad de una función o de un
requerimiento. En cambio, la programación estructurada es una forma de programar como lo es la
orientación a objetos. En cualquier caso, la programación orientada a objetos es un complemento
perfecto a UML.
Por ejemplo,
Documentación.
Los programas cuya única documentación es el código se quedan obsoletos rápidamente y es
imposible mantenerlos.
La falta de documentación no sólo genera trabajo adicional, sino que también tiende a dañar la
calidad del código. Si no se posee una nítida caracterización del problema, es imposible que
desarrolle una solución clara.

16
Es necesaria la formación específica para aprender a documentar software puesto que es una tarea
complicada y exige un criterio de ingeniería maduro.
Documentar de forma concisa es un error habitual pero el otro extremo puede resultar igual de
perjudicial.
Por ejemplo, si escribe documentaciones extensas atosigaremos a la persona que la consulta y
constituirán una carga a la hora de conservarlas. Es esencial documentar sólo los asuntos correctos.
La documentación no sirve de ayuda para nadie si su extensión desanima a la gente a la hora de
leerla.
Aunque algunas veces es conveniente posponer la tarea de la documentación mientras se realizan
experimentos, los programadores con experiencia suelen documentar de forma metódica incluso el
código provisional, los análisis de un problema inicial y los borradores de un diseño. Al tener la
creación de documentación como hábito les resulta normal documentar a medida que van
avanzando.
Es esencial que no se piense que la documentación es un asunto rutinario y aburrido.
1.4. Implementación. Conceptos generales de desarrollo de software
Una implementación o implantación es la realización de una aplicación, instalación o la ejecución de
un plan, idea, modelo científico, diseño, especificación, estándar, algoritmo o política.
En ciencias de la computación, una implementación es la realización de una especificación técnica o
algoritmos como un programa, componente software, u otro sistema de cómputo. Muchas
implementaciones son dadas según a una especificación o un estándar. Por ejemplo, un navegador
web respeta (o debe respetar) en su implementación, las especificaciones recomendadas según el
World Wide Web Consortium (W3C), y las herramientas de desarrollo del software contienen
implementaciones de lenguajes de programación.
Habitualmente, la implementación se refiere al proceso post-venta de guía de un cliente sobre el uso
del software o hardware que el cliente ha comprado. Esto incluye el análisis de requisitos, análisis del
impacto, optimizaciones, sistemas de integración, política de uso, aprendizaje del usuario, marcha
blanca y costes asociados.
La implementación de software comprende el trabajo de grupos de profesionales que son
relativamente nuevos en la economía basada en la gestión del conocimiento, tales como analista de
negocios, analistas técnicos, arquitecto de software, y directores de proyecto.
Principios básicos del desarrollo de software.
KISS es uno de los principales principios de desarrollo de software. Se puede resumir en que en
igualdad de condiciones la solución más sencilla es probablemente la correcta.
Los puntos básicos que lo definen son:
 Partes sencillas y comprensibles, que permite trabajar fácilmente en grupos de trabajo.
 Fácil mantenimiento y flexibilidad.
 Con errores de fácil detección y corrección.
 Descartar lo complejo e innecesario.

17
Los patrones de diseño son herramientas para mitigar la complejidad de los sistemas de software ya
que encapsulan modelos de resolver determinados tipos de problemas y es un elemento
fundamental de las buenas prácticas de programación. Básicamente ofrecen múltiples plantillas en
las que basar nuestros desarrollos.
 Fuente de información primaria.
Es aquella información que se obtiene directamente de la realidad misma, sin sufrir ningún proceso
de elaboración previa. Son las que el investigador recoge por sí mismo en contacto con la realidad.
 Fuente de información secundaria.
Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación
existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) y observación.
Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el
trabajo de cada una y ayudar a asegurar una investigación completa.
 Entrevista.
La entrevista se utiliza para recabar información en forma verbal, a través de preguntas que propone
el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales
del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán
datos o serán afectados por la aplicación propuesta.
El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren
este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no
siempre son la mejor fuente de datos de aplicación.
Dentro de una organización, la entrevista es la técnica más significativa y productiva de que dispone
el analista para recabar datos. En otras palabras, la entrevista es un intercambio de información que
se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para
obtener información acerca de las necesidades y la manera de satisfacerlas.
 Revisión Documental.
El objetivo de esta técnica es estar actualizado en el tema que se explora. Es requisito de la revisión
documental obtener la información de los archivos de bibliotecas y hemerotecas, archivos digitales
clasificados, revistas y publicaciones registradas y certificadas, archivos documentales de
instituciones y/o grupos reconocidos en el campo de investigación, entre otros.

18
La indagación sobre el conocimiento es necesaria para comprender el campo sobre el cual se
investiga. El estudio documental permite hacer una retrospección del tema en cuestión, permite
plantear comparaciones o relaciones entre las categorías que han sido definidas por el investigador,
para plantear hipótesis, con respecto al desarrollo del tema a investigar.
La revisión documental abarca información suficiente del tema, para captar el significado que se
trata de comprender y explicar sobre el tema planteado.
 Técnica de Costo-Beneficios.
Esta técnica se implementa habitualmente como guía para lograr una respuesta de viabilidad. Los
resultados no son definitivos pero ayudan a tomar decisiones posteriores ya que presentan un nivel
de certeza muy razonable.
Los resultados obtenidos no representan una regla a seguir por todo el mercado y ni por un sector en
particular. Sin embargo, las tendencias nos pueden decir mucho y referencias de organizaciones que
tomaron uno u otro camino son de gran ayuda el momento de decidir.
La disponibilidad de información histórica es otro elemento que determina el riesgo de la estimación,
donde las experiencias son más elocuentes que promesas infundadas de proveedores o entusiastas
tecnológicos.
Los elementos que intervienen en un análisis de Costo-Beneficio para una evaluación correcta son los
que a continuación se detallan.
Costos:
 Precio del Software (A).
 Infraestructura. Incluidos todos los componentes hardware y software (B).
 Implantación. Consultoría para instalación y puesta en funcionamiento (C).
 Entrenamiento de los usuarios de la aplicación (D).
 Costo Total de la Solución (CTS) = A + B + C + D
Beneficios:
 Mejora de Procesos. Permitiendo la reducción de tiempo y recursos (A).
 Disponer de Sistemas de Información. Mejora la toma de decisiones y obtención de ingresos
(B).
 Personal Motivado (C).
 Intangibles. Otros beneficios intangibles que sean identificados y cuantificables (D).
 Beneficio Total de la Solución (BTS) = A + B + C + D
Si CTS < BTS entonces la solución es Viable, en caso contrario no es recomendable.
Cada uno de los elementos a incluirse debe ser cuantificado y ponderado, de tal forma que el
agregado final determine un resultado tangible.
Técnicas de desarrollo de software.
El diagrama de flechas completo da una representación gráfica de las relaciones entre las actividades
del proyecto. La ventaja de esta etapa es que permite conocer con detalle las diversas actividades o
fases del proyecto y de esta manera se pueden sugerir mejoras antes de que el proyecto se ejecute.

19
EL diagrama debe comprender como mínimo las siguientes fases:
 Establecimiento de objetivos.
 Identificación de actividades principales: se identificarán aquellas fases necesarias para crear la
aplicación. Este punto estará referido al diseño y desarrollo de la aplicación y a la puesta en
común de las necesidades de recursos. Éstas como mínimo deberían ser:
 Diseño de la arquitectura.
 Diseño técnico.
 Implementación.
 Revisión y verificación de diseño.
 Creación documentación (manuales de usuario, de instalación, etc.).
 Implantación cliente.
 Creación de la estructura de proyecto: se definirán los responsables de ejecutar las actividades
planeadas, y se asignarán los recursos necesarios para cada una de ellas.
 Estimación de tiempos de actividad.
 Análisis y aprobación del plan.
Por ejemplo,
1.5. Validación y verificación de sistemas
Planificación.
El objetivo de planificación del proyecto de software es proporcionar un marco de trabajo que facilite
hacer estimaciones razonables en cuanto a los recursos, costo y planificación temporal. Estas
estimaciones se deben realizar dentro de un plazo de tiempo previamente establecido aunque se
deben permitir actualizaciones según vaya progresando el proyecto.
Estas estimaciones deberían definir los escenarios del " mejor caso " y " peor caso " de forma que los
resultados del proyecto puedan limitarse.

20
El objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que
lleve a estimaciones razonables.
La primera actividad de la planificación del proyecto de Software siempre es determinar el ámbito
del software por lo que debemos evaluar aspectos como la función, el rendimiento, las restricciones,
las relaciones entre partes del programa y la fiabilidad.
Ejemplo de aplicación para la planificación del desarrollo software, GanttProyect
Métodos formales de verificación.
Entre los métodos de verificación más utilizados se encuentra el de las aserciones E/S. Basado en la
lógica de Hoare se especifica mediante aserciones que relacionan las entradas y salidas del
programa. Se garantiza que si la entrada actual satisface las restricciones de entrada (precondiciones)
la salida satisface las restricciones de salida (poscondiciones).
Se utiliza una expresión del tipo P {programa} Q, siendo P y Q aserciones de la lógica, para indicar que
si P es cierto antes de la ejecución del programa y dicho programa termina, entonces Q es cierto tras
la ejecución de dicho programa. Este método permite tanto la corrección parcial como total de los
programas.
Un caso especial son los bucles, donde los predicados deben mostrar una relación invariante, es
decir, deben ser ciertos independientemente del número de vueltas del bucle, por lo tanto el
predicado debe cumplir lo siguiente:
 Es cierto a la entrada del bucle.
 Es cierto en cualquier paso del bucle.
 Junto con la negación de la condición del bucle, implica que el predicado se cumple a la salida del
bucle.
 Precondición más débil. Dada una proposición (P) S (Q) donde S es un conjunto de
sentencias de un módulo de un programa, y donde P y Q son los predicados que se cumplen
antes y después de S respectivamente, se dice que P es la precondición más débil (wp) de S,
si es la condición mínima que garantiza que Q es cierto tras la ejecución de S.

21
 Inducción estructural. La inducción estructural es una técnica de verificación formal que se
basa en el principio de inducción matemática.
Por ejemplo,
Dado un conjunto S con una serie de propiedades y una proposición P que se desea probar, la
inducción matemática:
* Demuestra que P es cierto para el mínimo número de elementos (o casos triviales) de S.
* Asume que P es cierto para un número de elementos (o casos posibles) de S menores o iguales a N.
* Demuestra que entonces P es cierto para el elemento N+11 de S.
Métodos automatizados de análisis.
El testeo automático, tanto funcional como unitario, se divide en dos fases:
 Estrategia y planificación. En esa primera fase, se investigan la necesidad y posibilidad del testeo
automático.
 Prototipo e implementación. En la segunda fase se realiza un prototipo del sistema de testeo
automático y se integra en el proceso de desarrollo.
1.6. Pruebas de software
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier
momento de dicho proceso de desarrollo.
Tipos.
Las pruebas en conjunto tienen como objetivo general verificar y validar un software,
independientemente de las características y el entorno donde se desarrollen, además de los recursos
y los factores vinculados al proceso de desarrollo.
Funcionalidad.
 Función: Pruebas fijando su atención en la validación de las funciones, métodos, servicios,
caso de uso.
 Seguridad: Asegurar que los datos o el sistema solamente es accedido por los actores
deseados.
 Volumen: Enfocada en verificando las habilidades de los programas para manejar grandes
cantidades de datos, tanto como entrada, salida o residente en la BD.
Usabilidad.
Prueba enfocada a factores humanos, estéticos, consistencia en la interfaz de usuario, ayuda
sensitiva al contexto y en línea, asistente documentación de usuarios y materiales de entrenamiento.

22
Fiabilidad.
 Integridad: Enfocada a la valoración exhaustiva de la robustez (resistencia a fallos).
 Estructura: Enfocada a la valoración a la adherencia a su diseño y formación. Este tipo de
prueba es hecho a las aplicaciones Web asegurando que todos los enlaces están conectados,
el contenido deseado es mostrado y no hay contenido huérfano.
 Stress: Enfocada a evaluar cómo el sistema responde bajo condiciones anormales. (extrema
sobrecarga, insuficiente memoria, servicios y hardware no disponible, recursos compartidos
no disponible).
Rendimiento.
 Benchmark: Es un tipo de prueba que compara el rendimiento de un elemento nuevo o
desconocido a uno de carga de trabajo de referencia conocido.
 Contención: Enfocada a la validación de las habilidades del elemento a probar para manejar
aceptablemente la demanda de múltiples actores sobre un mismo recurso (registro de
recursos, memoria).
 Carga: La variación en carga es simular la carga de trabajo promedio y con picos que ocurre
dentro de tolerancias operacionales normales.
Soportabilidad.
 Configuración: Enfocada a asegurar que funciona en diferentes configuraciones de hardware
y software. Esta prueba es implementada también como prueba de rendimiento del sistema.
 Instalación: Enfocada a asegurar la instalación en diferentes configuraciones de hardware y
software bajo diferentes condiciones (insuficiente espacio en disco, etc.)
Pruebas funcionales (BBT).
Las pruebas funcionales se desarrollan usando modelos de prueba que buscan evaluar cada una de
las opciones con las que cuenta el software a estudiar.
Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las
funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante
el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el
paquete informático. Con estas pruebas específicas podemos validar que el software hace lo que
debe, es decir, lo que se ha especificado previamente.
Pruebas estructurales (WBT).
Este tipo de pruebas son aplicables a varios niveles —unidad, integración y sistema— aunque
habitualmente se aplican a las unidades de software.
Su función principal es comprobar los flujos de ejecución dentro de cada unidad pero también
pueden analizar los flujos entre unidades durante la integración, e incluso entre subsistemas,
durante las pruebas de sistema.
Las principales técnicas de diseño de pruebas de caja blanca son:
 Pruebas de flujo de control.
 Pruebas de flujo de datos.
 Pruebas de bifurcación (branch testing).
 Pruebas de caminos básicos.

23
Un ciclo de vida incluye las siguientes fases:
Planificación
Análisis
Diseño
Ejecución
Ciclos
Pruebas finales e implementación
Producción
Comparativa. Pautas de utilización.
Planificación de las pruebas (Fase de definición del producto).
La fase de planificación de pruebas significa redactar el test plan ó plan de pruebas que es un
documento a alto nivel que describe las estrategias a seguir durante el desarrollo de las pruebas.
Análisis de pruebas (Fase de documentación).
La fase de análisis es una extensión de la fase de la planificación. Mientras que la fase de
planificación es a más alto nivel, la fase de análisis es donde se comienza a documentar los planes
detallados.
Se comienza a analizar los casos de prueba:
 Revisión de los inputs.
 Formatos. Generalmente en esta fase se crea una matriz de validación basada en los
requisitos.
 Test Cases (casos de prueba). Siguiendo la matriz de validación y otros documentos de
entrada (inputs), se escriben los test cases. Comenzamos también a vincular los requisitos
con cada test case.
 Automatización. Mientras se crean test cases, se identifican los casos que deben ser
automatizados. También se identifican las áreas para las pruebas de rendimiento, de carga y
de stress.
 Plan de Regresión: Los ciclos de pruebas, es decir, número de veces que se probará de nuevo
la aplicación para verificar que los defectos encontrados no han introducido nuevos errores.
Diseño de pruebas.
El ciclo de vida de las pruebas transcurre prácticamente en paralelo al de desarrollo.
Durante esta fase todos los planes, test cases, etc.… de la fase de análisis son revisados y finalizados.

24
Pueden ser añadidos nuevos elemento de prueba y preparar el documento de gestión de riesgos.
También se deben desarrollar los scripts de pruebas automáticas y, por supuesto, los informes de
pruebas, especialmente los informes sobre pruebas unitarias.
Ámbitos de aplicación.
Lo más recomendable es hacer un test de cualificación de la versión para evaluar que la aplicación es
lo suficientemente estable para comenzar la ejecución de las pruebas.
De nada serviría comenzar una ronda de test si con unas cuantas acciones la aplicación rompe. Es
necesario un mínimo de estabilidad.
Para llevar el seguimiento de la ejecución de los test cases se pueden utilizar alguna de las
herramientas comerciales que hay en el mercado ó utilizar una matriz de hoja de cálculo (Excel, Calc)
donde iremos apuntado nuestros PASSED o FAILED (OK or NOT).
Pruebas de Sistemas.
Las pruebas del sistema tienen un propósito particular que es comparar el sistema o el programa con
sus objetivos originales (requerimientos funcionales y no funcionales).
Partiendo de esta premisa se presentan dos implicaciones:
1. Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba
del sistema es el proceso de procurar demostrar cómo el programa, en su totalidad, no
resuelve sus objetivos o requerimientos.
2. Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por
escrito, mensurables para el producto.
Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la
integración del sistema de información globalmente, verificando el funcionamiento correcto de las
interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información
con los que se comunica.

25
Existen diferentes tipos de pruebas como podemos ver en la tabla siguiente.
Pruebas de comunicaciones.
Pruebas de rendimiento.
Pruebas de recuperación
Pruebas de volumen.
Pruebas de sobrecarga.
Pruebas de tensión.
Pruebas de disponibilidad de datos.
Pruebas de facilidad de uso.
Pruebas de operación.
Pruebas de entorno.
Pruebas de seguridad.
Pruebas de usabilidad.
Pruebas de almacenamiento.
Pruebas de configuración.
Pruebas de instalación.
Pruebas de la documentación.
Pruebas de componentes.
Se realizan pruebas de forma individual sobre componentes del software para los cual se dispone de
documentación con su especificación independiente.
Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo
objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la
parte interesada o stakeholder. Se trata de una actividad más en el proceso de control de calidad.
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier
momento de dicho proceso de desarrollo.

26
Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno
corresponde un nivel distinto de involucramiento en las actividades de desarrollo.
Pruebas estáticas.
Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación. Puede referirse a la
revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se pueden
realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.
Pruebas dinámicas.
Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación. Las pruebas
dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a la
naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el
comportamiento de la aplicación desarrollada.
Automatización de pruebas. Herramientas.
En el mercado existen variadas herramientas. Veamos alguna de ellas.
HP Quicktest Professional (QTP).
Proporciona la capacidad de automatizar pruebas funcionales y pruebas de regresión para software y
ambientes de prueba. Proporciona la capacidad de definir Scripts de prueba y posee una interfaz
gráfica que le permiten al usuario emular la funcionalidad que desea probar, incluyendo el uso de
interfaces de usuario de las aplicaciones a probar. Incluye características como: Vista de experto,
pruebas de procesos de negocio, grabado de pantalla (para captura de las evidencias de prueba),
entre otras posibilidades.

27
Watir.
Forma parte de la familia de librerías Ruby de Código Abierto (Open Source) para la automatización
de navegadores web. Le permite a su usuario escribir pruebas fáciles de leer y mantener. Sencilla y
flexible. Tiene la capacidad de hacer clic en enlaces, llenar formularios de pantallas con datos y
presionar botones. Tiene la capacidad de enlazarse con bases de datos, leer archivos de datos y hojas
de cálculo, exportar XML y estructurar los códigos como librerías reutilizables.
Selenium.
Es un framework para pruebas de aplicaciones Web, descargable de forma gratuita desde su sitio
web. Proporciona una herramienta de grabación y playback, que permite desarrollar pruebas sin
necesidad de aprender un lenguaje de Scripting. Incluye características como grabación, playback,
selección de campos, auto completar formularios, pruebas de recorrido (Walkthrough), debug,
puntos de control, scripts ruby y otros formatos.

28
Visual Studio Test Proffessional.
Conjunto de herramientas de pruebas integradas desarrolladas por Microsoft, que proporcionan
soporte a todo el ciclo de planificación, ejecución y registro de pruebas, con facilidades de
colaboración entre analistas de prueba (testers) y desarrolladores en la herramienta. Proporciona
capacidad de realizar pruebas manuales, reutilización de pruebas manuales, integración con el “team
foundation server”, gestión de ciclo de vida de aplicaciones, entre otros.
Rational Functional Tester.
Herramienta de automatización de pruebas funcionales y de regresión. Proporciona capacidades de
pruebas de interfaz gráfica, pruebas manejadas por datos (Data Driven), pruebas funcionales y
pruebas de regresión. Algunas de sus características son: Simplificación de creación y visualización de
pruebas, pruebas de tipo storyboards, trazabilidad en todo el ciclo de vida, validación de data
dinámica (por medio de un wizard), e inclusive capacidad de definir scripts (por medio de lenguajes
de Scripting).

29
Estándares sobre pruebas de software.
Las pruebas de software son un elemento imprescindible y crítico para la validación de un producto
de software. Dichas pruebas de software deben apoyarse en estándares que revisan los aspectos
fundamentales que debe considerar todo proceso de pruebas.
El estándar ISO/IEC 29119 para pruebas de software es un referente internacional en el ámbito de las
pruebas software y permite eliminar las inconsistencias existentes entre las normas actuales.
La estructura de ISO/IEC 29119 consta de cuatro partes:
1. Conceptos y Vocabulario.
2. Proceso de Pruebas.
3. Documentación de Pruebas.
4. Técnicas de Prueba.
Las partes 2 (procesos) y 3 (documentación) han sido planificadas en una primera secuencia, que tras
sucesivas revisiones por expertos externos e internos a los diferentes comités producirán los
primeros borradores del comité (Committee Draft: CD) para continuar con los procesos de
tramitación y revisión habituales en la elaboración de los estándares ISO.
Son varias las normas que las principales organizaciones internacionales de normalización (ISO, IEEE,
BSI, etc.) han publicado relacionadas directa o indirectamente con las pruebas de software.
1.7. Calidad de software
En el desarrollo de software, la calidad de diseño debe acompañar al desarrollo de los requisitos,
especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado
principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante
cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de
carácter físico.

30
Principios de calidad del software.
Watts Humphrey, considerado padre de la calidad de los procesos software planteó seis principios de
la calidad:
1. Principio 1: Si un cliente no demanda calidad probablemente no la conseguirá.
2. Principio 2: Para obtener calidad de manera constante los desarrolladores deben gestionarla
en su trabajo.
3. Principio 3: Para gestionar la calidad los desarrolladores deben medirla.
4. Principio 4: La calidad de un producto la determina el proceso usado para desarrollarlo.
5. Principio 5: Ya que las pruebas solucionan solo una fracción de los defectos, debes tener
pruebas de calidad.
6. Principio 6: La calidad solo la producen profesionales motivados orgullosos de su trabajo.
Métricas y calidad del software.
Las posibilidades de que aparezca el fallo humano en el proceso de desarrollo de software son
enormes. Es complicado realizar un buen software, y muchos de los productos que se construyen
tienen calidad insuficiente, además de no acertar con las estimaciones de tiempo y recursos
inexactos para la construcción de los mismos.
Los responsables expertos de compañías reconocen que la alta calidad ahorro de coste y mejora
general. Además, todos los métodos, herramientas y procedimientos que constituyen la Ingeniería
del Software van orientados a un único fin: producir software de calidad.
La calidad del software es, según Pressman, la “concordancia con los requisitos funcionales y de
rendimiento, con los estándares de desarrollo y con las características implícitas que se espera del
software desarrollado profesionalmente”.
No existe una definición única de calidad debido a las siguientes cuestiones:
 Es un concepto relativo.
 Es un concepto multidimensional.
 Está ligada a restricciones (por ejemplo, el presupuesto).
 Está ligada a compromisos aceptables (por ejemplo, plazos de fabricación).
 No es ni totalmente subjetiva ni objetiva.
 Puede resultar transparente cuando está presente y reconocible cuando está ausente.
La calidad del software se plantea siempre a dos niveles:
1. A nivel de empresa: para conseguir software de calidad, las organizaciones deben tener una
estructura organizativa apropiada para fomentar el trabajo por la calidad de todas las
personas y departamentos de la empresa, además de fomentar procesos específicos para
asegurar la calidad.
2. A nivel de proyecto: se trata de llevar a la práctica en las actividades cotidianas las
disposiciones fijadas en el sistema de calidad. Se aplica durante todo el proceso de ingeniería
del software, es decir, en Análisis, Diseño, Codificación y Prueba.
Las métricas del software se aplican para valorar cualitativamente algún factor relativo al mismo. No
existen métricas generales y únicas, aún menos para la calidad, ya que se puede examinar el
software a través de múltiples perspectivas y con diferentes objetivos.

31
Las características que debe tener una buena métrica son:
 Simple y fácil de calcular.
 Empírica.
 Consistente y objetiva.
 Independiente del lenguaje de programación.
 Que proporcione información útil.
 Veremos las más representativas en cada fase del ciclo de vida.
No existen demasiadas métricas en esta etapa debido a que se están tratando temas de muy alto
nivel conceptual, difíciles de cuantificar. Las más representativas miden el tamaño del software a
desarrollar:
Esquemáticamente distinguimos un sistema complejo de uno sistema simple,
Otras métricas de complejidad son las de Card y Glass que se basan en dos factores, calculados para
cada módulo a partir del diagrama de estructuras:
 Complejidad estructural: número de módulos que controla un módulo dado
 Complejidad de datos: suma de variables de entrada y salida de un módulo (dividido por el
número de módulos que controla, para que no influya la complejidad estructural)
La complejidad del sistema se calcula como la suma de la complejidad estructural y la complejidad de
datos de cada módulo
Las métricas de cohesión y acoplamiento sirven para cuantificar la cohesión y acoplamiento de los
módulos en programación estructurada. A partir de los parámetros de entrada, los parámetros de
salida, las variables globales utilizadas y el fan-in y fan-out de los módulos, genera un valor que es
menor cuanto mejores son la cohesión y el acoplamiento.
Otro ejemplo de métrica para conocer la calidad del software es la profundidad árbol de herencia.
Cuanto mayor es la profundidad, menor es la calidad del software.

32
Concepto de métrica y su importancia en la medición de la calidad.
En el campo de la ingeniería del software una métrica es cualquier medida o conjunto de medidas
destinadas a conocer o estimar el tamaño u otra característica de un software o un sistema de
información, generalmente para realizar comparativas o para la planificación de proyectos de
desarrollo. Un ejemplo ampliamente usado es la llamada métrica de punto función .
Existen diferentes metodologías de medición, de las cuales la más popular es la mantenida por el
International Function Point Users Group (IFPUG).
Principales métricas en las fases del ciclo de vida software.
Para aplicar el sistema de calidad al ciclo de vida es necesaria la utilización de métricas adecuadas
que permitan medir la calidad del proyecto.
La medición es fundamental para cualquier disciplina de ingeniería, y la ingeniería del Software no es
una excepción.
Las métricas del Software se refieren a un amplio elenco de medidas para el Software de
computadora. La medición se puede aplicar al proceso de Software con el intento de mejorarlo sobre
una base continua.
Definimos las métricas o medidas de software como la aplicación continua de técnicas basadas en
las medidas de los procesos de desarrollo de Software y sus productos, para producir una
información de gestión significativa y a tiempo. Esta información se utilizará para mejorar esos
procesos y los productos que se obtienen de ellos.
Estas medidas son aplicables a todo el ciclo de vida del desarrollo, desde la iniciación, cuando
debemos estimar los costos, al seguimiento y control de la fiabilidad de los productos finales, y a la
forma en que los productos cambian a través del tiempo debido a la aplicación de mejoras.
Las medidas del software y los modelos de medida son entonces útiles para estimar y predecir costos
y para medir la productividad y la calidad del producto.
Un ingeniero del software recopila medidas y desarrolla métricas para obtener indicadores.
Estándares para la descripción de los factores de Calidad.
En un escenario en el que los sistemas de software se desarrollan y construyen por terceros
proveedores, el contratante del servicio, como primer receptor del mismo, en muchos casos debe
confiar en el buen hacer del proveedor seleccionado, especialmente si no dispone de los medios
apropiados para auditar la entrega y en su caso argumentar defectos en el proceso de desarrollo.
En general, una vez validado que el sistema responde a los principales requisitos funcionales
especificados, el usuario realizará las pruebas de aceptación, corrigiéndose los errores encontrados y
traspasándose al fin al entorno de producción. Sin embargo, en muy pocas ocasiones se validan de
manera rigurosa los requisitos funcionales y los no funcionales, o se ejecutan validaciones que
aseguren que el sistema es lo suficientemente robusto y estable como para pasar a un entorno
productivo con las garantías adecuadas.
Por ejemplo, no se realizan estimaciones de los recursos necesarios para el sistema, imprescindibles
para un adecuado dimensionamiento de los servidores, o se anticipan eventuales picos de trabajo, o
en resumen, todo aquello que al fin asegure la satisfacción total del usuario.

33
Hay que considerar entonces que estas eventualidades además de provocar un coste económico
importante, principalmente por el elevado número de personas involucradas en su resolución,
también producen la pérdida de confianza de los usuarios en el sistema.
ISO-9126.
Esta norma definida por un marco conceptual basado en los factores tales como Calidad del Proceso,
Calidad del Producto del Software y Calidad en Uso; según el marco conceptual, la calidad del
producto, a su vez, contribuye a mejorar la calidad en uso.
La norma ISO/IEC 9126 presentan dos modelos de calidad, el primero referido a la calidad interna y
externa y el segundo modelo referido a la calidad en uso, a continuación se describe cada uno de
ellos.
La calidad externa se define como la totalidad de las características del producto software desde una
perspectiva externa. Es la calidad del software cuando es ejecutado, la cual es típicamente medida y
evaluada mientras se prueba en un ambiente simulado, con datos simulados y usando métricas
externas. Durante las pruebas, muchas fallas serán descubiertas y eliminadas. Sin embargo algunas
fallas todavía pueden permanecer después de las pruebas. Como es difícil corregir la arquitectura de
software u otros aspectos fundamentales del diseño del software, el diseño fundamental permanece
sin cambios a través de las pruebas.
Las características y cualidades de la calidad externa e interna pueden verse en el siguiente esquema,
Otros estándares. Comparativa.
NORMA ISO/IEC - 14598
Establece un marco de trabajo para evaluar la calidad de los productos de software proporcionando,
además, métricas y requisitos para los procesos de evaluación de los mismos.

34
La norma define las principales características del proceso de evaluación:
 Repetitividad.
 Reproducibilidad.
 Imparcialidad.
 Objetividad.
Para estas características se describen algunas medidas concretas:
 Análisis de los requisitos de evaluación.
 Evaluación de las especificaciones.
 Evaluación del diseño y definición del plan de evaluación.
 Ejecución del plan de evaluación.
 Evaluación de la conclusión.
NORMA ISO/IEC 25000 (SquaRE)
Su objetivo principal es guiar el desarrollo de los productos de software con la especificación y
evaluación de requisitos de calidad. Establece criterios para la especificación de requisitos de calidad
de productos software, sus métricas y su evaluación.
Al igual que la norma ISO/IEC 9126, este estándar define tres vistas diferenciadas en el estudio de la
calidad de un producto:
1. Vista interna: esta vista se ocupa de las propiedades del software como: el tamaño, la
complejidad o la conformidad con las normas de orientación a objetos.
2. Vista externa.
3. Vista en uso: mide la productividad y efectividad del usuario final al utilizar el software.
La primera puede utilizarse desde las primeras fases del desarrollo, permitiendo detectar deficiencias
en el software en edades muy tempranas del ciclo de vida del software.
La segunda, sin embargo, necesita que el producto software este completo y se utilizará por tanto en
el pase a producción del producto, siendo muy dependiente de la máquina donde se ejecute.
Por último la tercera vista que también estudia el producto software finalizado será dependiente del
usuario y estará condicionada a los factores personales del mismo.
1.8. Herramientas de uso común para el desarrollo de software
El proceso de desarrollo de aplicaciones de software normalmente involucra varias etapas. El
desarrollo de software puede ser una actividad compleja y larga, por lo que las herramientas
disponibles pueden reducir el estrés y aumentar el desempeño tanto de desarrolladores como de las
aplicaciones resultantes. Hay herramientas disponibles para cada etapa en el proceso de desarrollo
de software.
Editores orientados a lenguajes de programación.
Un editor es un programa que permite la creación y edición de archivos de texto. Para desarrollar un
programa basta con un simple editor como el bloc de notas de Windows.

35
Las características que aportan estos programas de forma genérica son:
 Coloreado de sintaxis
 Edición de múltiples archivos
 Formateo de textos
 Conexiones con repositorio o FTP
 Enlaces a otras herramientas como compiladores, repositorios, etc.
 Entre los más conocidos podemos destacar Notepad++ y SublimeText2.
Compiladores y enlazadores.
Un compilador es un programa que permite traducir el código fuente de un programa en lenguaje de
alto nivel, a otro lenguaje de nivel inferior (típicamente lenguaje de máquina). De esta manera un
programador puede diseñar un programa en un lenguaje mucho más cercano a cómo piensa un ser
humano, para luego compilarlo a un programa más manejable por una computadora.
Como parte importante de este proceso de traducción, el compilador informa a su usuario de la
presencia de errores en el programa fuente.
Un enlazador (en inglés, linker) es un programa que toma los objetos generados en los primeros
pasos del proceso de compilación, la información de todos los recursos necesarios (biblioteca), quita
aquellos recursos que no necesita, y enlaza el código objeto con sus bibliotecas con lo que finalmente
produce un fichero ejecutable o una biblioteca. En el caso de los programas enlazados
dinámicamente, el enlace entre el programa ejecutable y las bibliotecas se realiza en tiempo de carga
o ejecución del programa.
Generadores de programas.
Son herramientas que crean software basado en algún lenguaje de programación sin necesidad de
tener nociones del mismo.
Por ejemplo PHPRuner permite generar una interfaz plenamente funcional en PHP sobre una base de
datos partiendo de la misma.
Otros serían Adobe Muse que habilita al usuario para desarrollar un sitio web basado en la
combinación de HTMl5, CSS3 y Javascript.
Depuradores.
Un depurador (en inglés, debugger), es un programa usado para probar y depurar (eliminar los
errores) de otros programas (el programa "objetivo"). El código a ser examinado puede
alternativamente estar corriendo en un simulador de conjunto de instrucciones (ISS), una técnica que
permite gran potencia en su capacidad de detenerse cuando son encontradas condiciones específicas
pero será típicamente algo más lento que ejecutando el código directamente en el apropiado (o el
mismo) procesador. Algunos depuradores ofrecen dos modos de operación - la simulación parcial o
completa, para limitar este impacto.
Los depuradores también ofrecen funciones más sofisticadas tales como correr un programa paso a
paso (un paso o animación del programa), parar el programa (breaking), es decir, pausar el programa
para examinar el estado actual en cierto evento o instrucción especificada por medio de un
breakpoint, y el seguimiento de valores de algunas variables. Algunos depuradores tienen la
capacidad de modificar el estado del programa mientras que está corriendo, en vez de simplemente
observarlo.

36
La misma funcionalidad que hace a un depurador útil para eliminar errores permite ser usado como
herramienta de craqueo de software para evadir la protección anticopia, la gestión digital de
derechos, y otras características de protección de software. A menudo también lo hace útil como
herramienta general de verificación de pruebas, cobertura de fallas, o analizador de desempeño,
especialmente si son mostradas las longitudes de trayectoria de instrucción.
De prueba y validación de software.
Algunas herramientas ofrecen entornos integrados que soportan las pruebas y el desarrollo a lo largo
de la vida de un proyecto, desde la reunión de los requisitos hasta el soporte del funcionamiento en
vivo del sistema. Algunos proveedores se enfocan en una sola parte del ciclo de vida. La base de
conocimientos de las herramientas de prueba de software proporciona los criterios funcionales que
se esperan de una herramienta de pruebas, la infraestructura que la soporta y una idea de la posición
que ocupa el proveedor en el mercado.
Optimizadores de código.
Un compilador optimizador es un compilador que trata de minimizar ciertos atributos de un
programa informático con el fin de aumentar la eficiencia y rendimiento. Las optimizaciones del
compilador se aplican generalmente mediante una secuencia de transformaciones de optimización,
algoritmos que transforman un programa para producir otro con una salida semánticamente
equivalente pero optimizada.
Generalmente hay varios aspectos que se desean optimizar:
 Optimización temporal.
 Optimización espacial.
 Reducir el tamaño del programa.
 Minimizar la potencia consumida por un programa (debido a las computadoras portátiles).
Las tareas del front-end (exploración, análisis sintáctico, análisis léxico, análisis semántico) son bien
conocidas y, sin optimizar, la generación de código es relativamente sencilla. La optimización, por
otra parte, aún es un campo que no se ha terminado de desarrollar de forma completa.
Empaquetadores.
Estos paquetes están formados por los programas ejecutables de la aplicación, así como por todas las
bibliotecas de las que depende y otros tipos de ficheros (como imágenes, ficheros de audio,
traducciones y localizaciones, etc.), de forma que se proporcionan como un conjunto. Las bibliotecas
de las que depende el programa pueden haber sido enlazadas tanto de forma dinámica como
también estática. Por tanto, el usuario percibe que el paquete como un conjunto que representa al
programa en sí, cuando en realidad incluye varios ficheros.
El empaquetado de aplicaciones permite evitar los problemas de las dependencias tanto a la hora de
instalar la aplicación como a la hora de usarla, ya que cada paquete lleva consigo sus dependencias, y
la instalación o desinstalación de otro software no va a afectar a las dependencias de dicho paquete.
La principal ventaja del empaquetado de aplicaciones es precisamente que se evitan la problemática
de las dependencias, y que la aplicación se puede trasladar de un computador a otro sin necesidad
de reinstalarla, ya que el paquete de la aplicación contiene todos los ficheros necesarios para
ejecutarla. Sin embargo, como desventaja se presenta que estos paquetes ocupan mucho más
espacio en el disco, especialmente si el paquete incluye bibliotecas.

37
Generadores de documentación de software.
Un generador de documentación es una herramienta de programación que genera documentación
destinada a los programadores (documentación de API) o a usuarios finales, o a ambos, a partir de un
conjunto de código fuente especialmente documentado, y en algunos casos, archivos binarios.
Los tipos de documentos a los que nos referimos son:
 Documentos batch (documentos automatizados).
 Documentos interactivos (documentos que no pueden ser producidos automáticamente).
 Formularios (formularios para páginas web).
Gestores y repositorios de paquetes. Versionado y control de dependencias.
Los paquetes incluyen información importante además del propio software, como pueden ser el
nombre completo, una descripción de su funcionalidad, el número de versión, el distribuidor del
software, la suma de verificación y una lista de otros paquetes requeridos para el correcto
funcionamiento del software. Esta metainformación se introduce normalmente en una base de datos
de paquetes local.
El versionado de software es el proceso de asignación de un nombre o número único a un software
para indicar su nivel de desarrollo. Generalmente se asigna dos números, mayor.menor (en inglés:
major.minor), que van incrementando conforme el desarrollo del software aumente y se requiera la
asignación de un nuevo nombre o número único. Aunque menos habituales, también puede
indicarse otro número más, micro, y la fase de desarrollo en que se encuentra el software.
De distribución de software.
Una distribución de software es un conjunto de software específico ya compilado y configurado.
Pueden tomar formas de licencia como son GPL u open source o también puede trabajar bajo una
distribución binaria, es decir, un instalador (.exe) que pueda ser descargado desde Internet.
Una licencia es un contrato entre el desarrollador de un software y el usuario, en el cual se definen
con precisión los derechos y deberes de ambas partes. Es el desarrollador, o aquél a quien éste haya
cedido los derechos de explotación, quien elige la licencia según la cual distribuye el software.
Por otro lado, una patente es el conjunto de derechos exclusivos garantizados por la autoridad al
inventor de un nuevo producto (material o inmaterial) susceptible de ser explotado industrialmente
para el bien del solicitante por un periodo de tiempo limitado.
Los derechos de autor o copyright es la forma de protección proporcionada por las leyes vigentes en
la mayoría de los países para los autores de obras originales incluyendo obras literarias, dramáticas,
musicales, artísticas e intelectuales, tanto publicadas como pendientes de publicar.
Habitualmente el software se distribuye en forma de paquetes, frecuentemente encapsulado en un
solo fichero. Estos paquetes incluyen otra información importante, además del software mismo,
como pueden ser el nombre completo, una descripción de su funcionalidad, el número de versión, el
distribuidor del software, la suma de verificación y una lista de otros paquetes requeridos para el
correcto funcionamiento del software.

38
Gestores de actualización de software.
Los sistemas operativos incluidos los smartphones disponen de una tienda de aplicaciones propia con
programas de actualización.
Es posible instalar programas que centralizan las renovaciones haciendo más cómoda su gestión al
usuario y mejoran el funcionamiento del móvil, portátil, PC o tablet.
Este proceso en los ordenadores es más complicado, al ser mayor el número de aplicaciones
instaladas. Habitualmente se recomienda configurarlas para que sólo se puedan actualizar de modo
manual y cuando el usuario lo indique.
En el sistema operativo GNU/Linux, este problema está resuelto con la utilización de Synaptic
Package Manager, un programa para la gestión de paquetes de aplicaciones. Utiliza los diferentes
repositorios de archivos para la gestión y actualización, mediante un entorno gráfico sencillo, de
todos los paquetes instalados en el sistema.
Los sistemas operativos Windows XP y Windows Vista, en cambio, disponen de un gestor de
actualizaciones que resulta muy útil para mantener el sistema operativo al día, pero que deja fuera
todas las aplicaciones de terceros instaladas en el ordenador. Para solucionarlo, diferentes
propuestas gestionan la actualización de los programas externos a Windows de forma sencilla.
Algunas aplicaciones populares para Windows son:
 SUMo (Software Updates Monitor) es una aplicación gratuita para los sistemas operativos
Windows que disponen de un método de detección automática del software instalado, para
buscar actualizaciones o parches. SUMo no realiza la puesta al día de software, sino que avisa
cuando la actualización es posible e indica al usuario la dirección de Internet donde descargar
e instalar la nueva versión.
 UpdateStar es un buscador de actualizaciones que almacena una gran cantidad de
programas en su base de datos para controlar las nuevas versiones.
 FileHippo Update Checker es una pequeña aplicación gratuita para el sistema operativo
Windows. El servicio revisa las aplicaciones e informa de cuáles requieren ser actualizadas.
De control de versiones.
Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los
elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un
producto, es el estado en el que se encuentra dicho producto en un momento dado de su desarrollo
o modificación. Aunque un sistema de control de versiones puede realizarse de forma manual, es
muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados
sistemas de control de versiones o SVC
Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase, Darcs,
Bazaar , Plastic SCM, Git, Mercurial, Perforce.
El control de versiones se realiza principalmente en la industria informática para controlar las
distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM
(siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a
otros ámbitos como documentos, imágenes, sitios web, etc.

39
Un sistema de control de versiones debe proporcionar:
 Mecanismo de almacenamiento de los elementos que deba gestionar (ej. archivos de texto,
imágenes, documentación...).
 Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones
parciales, añadir, borrar, renombrar o mover elementos).
 Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos
(normalmente pudiendo volver o extraer un estado anterior del producto).
Aunque no es estrictamente necesario, suele ser muy útil la generación de informes con los cambios
introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la
versión de un conjunto de ficheros, etc.
Entornos integrados de desarrollo (IDE) de uso común.
Un IDE es un entorno de programación que ha sido empaquetado como un programa de aplicación;
es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz
gráfica (GUI). Los IDEs pueden ser aplicaciones por sí solas o pueden ser parte de aplicaciones
existentes.
Por ejemplo, el lenguaje Visual Basic puede ser usado dentro de las aplicaciones de Microsoft Office,
lo que hace posible escribir sentencias Visual Basic en forma de macros para Microsoft Word.
Los IDE proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación
tales como C++, PHP, Python, Java, C#, Delphi, Visual Basic, etc. En algunos lenguajes, un IDE puede
funcionar como un sistema en tiempo de ejecución, en donde se permite utilizar el lenguaje de
programación en forma interactiva, sin necesidad de trabajo orientado a archivos de texto, como es
el caso de Smalltalk u Objective-C.
Los elementos que conforman estas herramientas suelen ser los siguientes:
 Un editor de texto.
 Un compilador.
 Un intérprete.
 Un depurador.
 Un cliente.
 Posibilidad de ofrecer un sistema de control de versiones.
 Factibilidad para ayuda en la construcción de interfaces gráficas de usuario.
1.9. Gestión de proyectos de desarrollo de software
Los proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniería
tradicional en la naturaleza lógica del producto software.
La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software, porque
cubre todo el proceso de desarrollo. Para conseguir un proyecto de software fructífero se debe
comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos
requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir.

40
Planificación de proyectos.
El objetivo de la planificación de proyectos es obtener una distribución de las actividades en el
tiempo y una utilización de los recursos que minimice el coste del proyecto cumpliendo con los
condicionantes exigidos (plazo de ejecución, tecnología a utilizar, recursos disponibles, nivel máximo
de ocupación de dichos recursos).
Por tanto la planificación de proyectos es una programación de actividades y una gestión de recursos
para obtener un objetivo de coste cumpliendo con los condicionantes exigidos por nuestro cliente.
La programación de actividades debe aportar al director de proyecto un calendario de ejecución del
proyecto donde se refleje la fecha de inicio y finalización de las distintas actividades en que se ha
descompuesto el proyecto.
Para poder definir dicho calendario se hace necesario conocer la duración de cada actividad y su
orden, así como la fecha de inicio del proyecto.
Por ejemplo,
Control de proyectos.
El control de proyecto tiene como objetivo principal el mantener el proyecto alineado con sus
objetivos. Todas las dimensiones del proyecto han de ser gestionadas de manera concurrente,
integrando costes, plazo, alcance y calidad en el método de control utilizado. De poco serviría un
producto que cumpliera con los objetivos de costes, plazos y alcance, pero que no tuviese la calidad
especificada, o un producto con la calidad adecuada pero con un coste o un retraso que le hagan no
ser competitivo.
Gracias al control de proyecto podemos comparar entre los valores planificados e incurridos:
 Evaluar la actuación o ejecución pasada en cualquier instante de la vida del proyecto.
 Analizar tendencias futuras que permitan estimar los costes y plazos de finalización del
proyecto (método del valor ganado).
Ejecución de proyectos.
Esta es la etapa de desarrollo del trabajo en sí. Esta etapa es responsabilidad del contratista, con la
supervisión del cliente. Durante la ejecución del proyecto, se debe poner énfasis en la comunicación
para tomar decisiones lo más rápido posible en caso de que surjan problemas.

41
Así, es posible acelerar el proyecto estableciendo un plan de comunicación, por ej., a través de:
 El uso de un tablero que muestre gráficamente los resultados del proyecto, permitiendo que
el director del proyecto arbitre en caso de variaciones.
 Un informe de progreso que permita a todas las personas involucradas en el proyecto estar
informadas sobre las acciones en progreso y aquellas terminadas. Generalmente, "informar"
incluye la preparación completa y la presentación de informes sobre las actividades.
Además, se deberán organizar regularmente (una vez por semana, preferentemente) reuniones para
administrar el equipo del proyecto, es decir, discutir regularmente el progreso del proyecto y
determinar las prioridades para las siguientes semanas.
Herramientas de uso común para la gestión de proyectos.
Las herramientas más habituales con las que podemos trabajar son:
 @Task
 AceProject.
 Dekker Trakker.
 ConceptDraw Project.
 VPMi Professional.
 Project Tracker.
 Intellisys Project Desktop.
 Infowit Creative Manager.

42
 MinuteMan.
 SmartWork Project Planner.
 YZ Project Manager.
 TargetProcess.
 Acteo.

43
Recuerda…
Entre los métodos de verificación más utilizados no se encuentra el de las oportunidades. Basado en
la lógica de Hoare se especifica mediante aserciones que relacionan las entradas y salidas del
programa.
El desarrollo incremental no es un proceso de construcción que incrementa de forma directa los
requerimientos del sistema.
En la especificación de requisitos los casos de uso también son conocidos como Requisitos
funcionales.
La llamada mejora y garantía de calidad asegura que los resultados que se proporcionan sean
completos y contengan la calidad deseada.
El concepto "informar" incluye la preparación completa y la presentación de informes sobre las
actividades.
Las posibilidades de que aparezca el fallo humano en el proceso de desarrollo de software son muy
altas.
La primera actividad de la planificación del proyecto de software siempre es determinar el ámbito del
software.
El enunciado "Para gestionar la calidad los desarrolladores deben medirla." pertenece a los principios
de calidad de Watts Humphrey.
La Prueba funcional está basada en la ejecución, revisión y retroalimentación de las funcionalidades
previamente diseñadas para el software
El diagrama de flechas completo da una representación gráfica de las relaciones entre las actividades
del proyecto.

44
2. LA ORIENTACIÓN A OBJETOS
La programación estructurada anima al programador a pensar sobre todo en términos de
procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos
manejan.
En la programación estructurada solo se escriben funciones que procesan datos. Los programadores
que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles
que realicen sus métodos por sí mismos.
2.1. Principios de la orientación a objetos. Comparación con la programación estructurada
Ocultación de información (information hiding).
En informática denominamos principio de ocultación de información a la desaparición controlada y
temporal de decisiones de diseño en un programa con la idea de proteger a otras partes del código.
Proteger una decisión de diseño supone proporcionar una interfaz estable que proteja el resto del
programa de la implementación (y que sean susceptible de cambios).
Por ejemplo la encapsulación, que en los lenguajes de programación modernos es una forma de
expresión del principio de ocultación de información.
El término encapsulación a menudo se utiliza como sinónimo de la ocultación de información pero
tan similitud no se ajusta exactamente a la realidad.
No existe un acuerdo sobre las diferencias, siendo común la idea de que la ocultación de información
es el principio mientras que la encapsulación es la técnica.
Por ejemplo, un módulo de software oculta información encapsulándola en otro módulo u otra
construcción con la que se comunica mediante una interfaz.
El uso más común de la ocultación de información es ocultar el diseño del almacenamiento físico de
los datos, de manera que si dicho diseño es modificado solamente afecte a un pequeño subconjunto
del programa total.
Por ejemplo, si un punto tridimensional de coordenadas (x, y, z) es representado en un programa con
tres variables escalares de coma flotante y posteriormente dicha representación es modificada a una
variable array de tamaño 3, un módulo diseñado mediante la ocultación de información en principio
protegería al resto del programa de este cambio.
El tipo abstracto de datos (ADT). Encapsulado de datos.
En programación orientada a objetos, se denomina encapsulamiento al ocultamiento del estado, es
decir, de los datos miembro de un objeto de manera que sólo se pueda cambiar mediante las
operaciones definidas para ese objeto.
Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un
agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados de un objeto
contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios
e interacciones.

45
Con esto se consigue que la clase pueda obviar la implementación de los métodos y propiedades
para concentrarse sólo en cómo usarlos así como evitar que el usuario pueda cambiar su estado de
maneras imprevistas e incontroladas.
Las formas de encapsular conocidas son:
 Estándar (Predeterminado).
 Abierto: El miembro de la clase puede ser accedido desde el exterior de la clase o desde
cualquier parte del programa.
 Protegido: Sólo es accesible desde la propia clase y desde las clases que heredan (a cualquier
nivel).
 Semi cerrado: Sólo es accesible desde la clase heredada.
 Cerrado: Solo es accesible desde la propia clase.
En el encapsulamiento hay analizadores que pueden ser semánticos y sintácticos.
Paso de mensajes.
MPI (Message Passing Interface, Interfaz de Paso de Mensajes) es un estándar que define la sintaxis y
la semántica de las funciones contenidas en una biblioteca diseñada para ser usada en programas
que trabajen con múltiples procesadores.
Su principal característica es que no precisa de memoria compartida por lo que es muy habitual su
uso en la programación de sistemas distribuidos.
Los elementos principales que intervienen en el paso de mensajes son:
 El proceso que envía.
 El proceso que recibe.
 El mensaje.
Dependiendo de si el proceso que envía el mensaje espera a que el mensaje sea recibido, se puede
hablar de paso de mensajes síncrono o asíncrono.
En el paso de mensajes asíncrono, el proceso que envía, no espera a que el mensaje sea recibido, y
continúa su ejecución, siendo posible que vuelva a generar un nuevo mensaje y a enviarlo antes de
que se haya recibido el anterior. Esta es la razón por la que se utilizan buzones, en los que se
almacenan los mensajes a espera de que un proceso los reciba. Generalmente empleando este
sistema, el proceso que envía mensajes sólo se bloquea o para, cuando finaliza su ejecución, o si el
buzón está lleno.
En el paso de mensajes síncrono, el proceso que envía el mensaje espera a que un proceso lo reciba
para continuar su ejecución. Este método es conocido como técnica encuentro. Dentro del paso de
mensajes síncrono se engloba a la llamada a procedimiento remoto, muy habitual en las
arquitecturas cliente/servidor.

46
2.2. Clases de objetos
Atributos, variables de estado y variables de clase.
Un objeto es una instancia de una clase, por lo que se pueden intercambiar los términos objeto o
instancia.
Una clase se compone de dos partes:
 Atributos (denominados, por lo general, datos miembros. Son los datos que hacen referencia
al estado del objeto.
 Métodos (denominados, por lo general, funciones miembros). Son funciones que pueden
aplicarse a objetos
Por ejemplo, si tenemos una clase llamada auto, los objetos SEAT y AUDI serán instancias de esa
clase. También puede haber otros objetos SEAT León, diferenciados por su número de modelo.
Asimismo, dos instancias de una clase pueden tener los mismos atributos, pero considerarse objetos
distintos independientes.
Los atributos que asociamos a una clase, dependen en gran medida del uso que le daremos dentro
del sistema que diseñamos actualmente, pero también pueden ser definidos pensando en futuras
implementaciones. También son conocidos como variables de estado (o variables de instancia)
puesto que su valor define el estado del objeto.
Métodos. Requisitos e invariantes.
En la programación orientada a objetos, un método es una subrutina asociada exclusivamente a una
clase (llamados métodos de clase o métodos estáticos) o a un objeto (llamados métodos de
instancia).
Un método consiste en una serie de sentencias para llevar a cabo una acción, un juego de
parámetros de entrada que regularán dicha acción y un valor de salida (o valor de retorno) de algún
tipo. Este último elemento es opcional.
En lenguajes compilados, los métodos pueden ser objetos de primera clase, y en este caso se puede
compilar un método sin asociarse a ninguna clase en particular, y luego asociar el vínculo o contrato
entre el objeto y el método en tiempo de ejecución.
En cambio en lenguajes no compilados dinámicamente (conocidos también como tipados
estáticamente) se acude a precondiciones para regular los parámetros del método y postcondiciones
para regular su salida (en caso de tenerla). Si alguna de las precondiciones o postcondiciones es falsa
el método genera una excepción. Si el estado del objeto no satisface la invariante de su clase al
comenzar o finalizar un método, se considera que el programa tiene un error de programación.
La diferencia entre un procedimiento (generalmente llamado función si devuelve un valor) y un
método es que éste último, al estar asociado con un objeto o clase en particular, puede acceder y
modificar los datos privados del objeto correspondiente de forma tal que sea consistente con el
comportamiento deseado para el mismo.
Hay que entender la idea de método no como una secuencia de instrucciones sino como la forma en
que el objeto hace su trabajo. Y partiendo de esta premisa considerar al método como el pedido a un
objeto para que realice una tarea determinada o como la vía para enviar un mensaje al objeto y que
éste reaccione acorde a dicho mensaje.

47
Gestión de excepciones.
Estas condiciones de error pueden ser errores en la lógica del programa como un índice de un array
fuera de su rango o una división por cero o errores disparados por los propios objetos que denuncian
algún tipo de estado no previsto.
La idea general es que cuando un objeto encuentra una condición que no sabe manejar crea y
dispara una excepción que deberá ser capturada por el que le llamó. Las excepciones son objetos que
contienen información del error que se ha producido. Si nadie captura la excepción interviene un
manejador por defecto que normalmente imprime información que ayuda a encontrar quién produjo
la excepción.
Existen dos categorías de excepciones:
1. Excepciones verificadas. El compilador obliga a verificarlas. Son todas las que son lanzadas
explícitamente por objetos de usuario.
2. Excepciones no verificadas. El compilador no obliga a su verificación. Son excepciones como
divisiones por cero, excepciones de puntero nulo, o índices fuera de rango.
Una excepción es una condición anormal que surge en una secuencia de código durante la ejecución
de un programa. O sea, es un error en tiempo de ejecución.
La gestión de excepciones usa las palabras reservadas try, catch, throw, throws y finally.
try {
// bloque de código
}
catch (TipoExcepcion1 obEx){
// gestor de excepciones para TipoExcepcion1
}
catch (TipoExcepcion2 obEx){
// gestor de excepciones para TipoExcepcion2
}
// ...
finally {
// bloque de código que se ejecutara antes de
// que termine el bloque try
}

48
Agregación de clases.
Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de
agregación o de varias asociaciones de agregación distintas). La destrucción del compuesto no
conlleva la destrucción de los componentes. Habitualmente se da con mayor frecuencia que la
composición.
La agregación se representa en UML mediante un diamante de color blanco colocado en el extremo
en el que está la clase que representa el "todo”.
Veamos el siguiente ejemplo, donde tenemos una clase empresa, una clase cliente una empresa
agrupa a varios clientes.
2.3. Objetos
Los objetos interactúan unos con otros, en contraposición a la visión tradicional en la cual un
programa es una colección de subrutinas (procedimientos), o más sencillamente, una lista de
instrucciones para el computador. Cada objeto es capaz de recibir mensajes, procesar datos y enviar
mensajes a otros objetos de manera similar a un servicio.
En la programación orientada a objeto, un objeto es el resultado de la instanciación de una clase que
queda implementada sólo al crear una instancia de la clase, en la forma de un objeto.
Por ejemplo: dado un plano para construir mesas (una clase de nombre clase_mesa), entonces una
mesa concreta, en la que podemos colocar cosas encima, construida a partir de este plano, sería un
objeto de clase_mesa. Es posible crear (construir) múltiples objetos (mesas) utilizando la definición de
la clase (plano) anterior.
Los conceptos de clase y objetos son análogos a los de tipo de datos y variable; es decir, definida una
clase podemos crear objetos de esa clase, igual que disponiendo de un determinado tipo de dato
(por ejemplo el tipo entero), podemos definir variables de dicho tipo:
int a,b;
Creación y destrucción de objetos.
Técnicamente, el dominio de la programación orientada a objetos está formado por los tipos
abstractos de datos, la herencia y el polimorfismo, pero las formas de crear objetos es también muy
importante.
Es especialmente importante la forma en que se crean y se destruyen los objetos. Dependiendo de
los lenguajes de programación se trabaja bajo distintas filosofías al respecto.

Desarrollo de aplicaciones web en el entorno servidor

Desarrollo de aplicaciones web en el entorno servidor

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Desarrollo de aplicaciones web en el entorno servidor

Similar a Desarrollo de aplicaciones web en el entorno servidor (20)

Más de Jomicast

Más de Jomicast (20)

Último

Último (20)

Desarrollo de aplicaciones web en el entorno servidor