NDICE

Tabla de contenido
1. UML Y EL PROCESO UNIFICADO......................................................................1

Desarrollo e
Implementacin
de
1.1.2
PRIMERAS METODOLOGAS.....................................................................1
1.1.3
ANTECEDENTES
UML.........................................................................2
Sistemas
deDEinformacin

1.1CONCEPTUALIZACIN DE UML......................................................................1

1.2 ESTANDARIZACIN UML................................................................................ 4

1.2.1 VISTAS.................................................................................................... 4
1.2.2 DIAGRAMAS............................................................................................ 5
1.2.3 ELEMENTOS DE MODELADO...................................................................8
1.2.4 MECANISMOS........................................................................................ 11
1.2.4 EXTENCIONES UML............................................................................... 12
1.3 HERRAMIENTAS CASE PARA EL DESARROLLO Y MODELADO DE SI..............12
1.3.1 DEFINICIN CASE.................................................................................. 13
1.3.2 CLASIFICACIN CASE............................................................................13
1.4 DIAGRAMAS................................................................................................. 14
1.4.1 ACTIVIDAD............................................................................................ 14
1.4.2 MODELADO A DISTINTOS NIVELES........................................................18
1.4.3 DIAGRAMAS DE CASO DE USO..............................................................18
1.4.4 RELACION CON LOS REQUISITOS..........................................................21
1.5 UTILIZACIN DE HERRAMIENTAS CASE......................................................23
1.5.1 PLANIFICACIN DE LOS SISTEMAS DE GESTIN.................................24
1.5.2 GESTIN DE PROYECTOS.....................................................................28
1.5.3 SOPORTE............................................................................................. 29
1.5.4 ANLISIS Y DISEO............................................................................... 30
1.5.6 INTEGRACIN Y PRUEBAS.....................................................................32
1.5.7 PROTOTIPOS......................................................................................... 33
1.5.8 MANTENIMIENTO.................................................................................. 34
2. DISEO DE SISTEMAS................................................................................... 38
2.1 DISEO ESTRUCTURADO DE SISTEMAS......................................................38
0

2.1.1 CONCEPTOS BSICOS...........................................................................39

2.1.2 DIAGRAMA DE FLUJO DE DATOS............................................................40
2.1.3 APLICACIONES PARA SISTEMAS DE TIEMPO REAL.................................42
2.2 DIAGRAMAS DE ITERACIN DE OBJETOS..................................................43
2.3 MODELO DE CLASES................................................................................... 59
2.3.1 CLASES................................................................................................. 59
2.3.1.2 PROPIEDAD........................................................................................ 60
2.3.3 INTERACCIN........................................................................................ 61
2.3.2 CARACTERSTICAS................................................................................ 63
2.3.1.3 ESTRUCTURAS JERRQUICAS.............................................................64
2.4 DIAGRAMAS DE IMPLEMENTACIN..............................................................69
2.4.1 DEFINICIN........................................................................................... 69
2.4.2 OBJETIVO.............................................................................................. 69
2.4.3 TIPOS.................................................................................................... 69
2.4.3.1 DIAGRAMA DE COMPONENTES...........................................................69
2.4.3.2 DIAGRAMA DE EJECUCIN..................................................................69
2.4.4 APLICACIONES...................................................................................... 69
2.4.5 ADAPTACIONES DE UML........................................................................70
2.5 DISEO DE INTERFAZ DE USUARIO.............................................................73
2.5.1 INTERACCION HOMBRE MAQUINA.........................................................73
2.5.2 DISEO DE INTERFAZ HOMBRE MAQUINA.............................................74
2.5.3 DIRECTRICES PARA EL DISEO DE INTERFACES....................................74
2.5.4 ESTANDARES DE INTERFAZ...................................................................75
2.6 DISEO DE LA BASE DE DATOS..................................................................77
2.6.1 OBJETIVOS............................................................................................ 78
2.6.2 ALMACEN DE DATOS............................................................................. 79
2.7 MTRICAS DEL DISEO............................................................................... 84
2.7.1 FACTORES QUE AFECTAN......................................................................87
2.7.2 PRODUCTIVIDAD................................................................................... 88
2.7.3 MEDIDAS RELACIONADAS.....................................................................89
2.7.3.1 TAMAO............................................................................................. 93
2.7.3.2 FUNCION............................................................................................ 94
2.7.3.3 PUNTOS DE OBJETO...........................................................................95
2.7.4 METRICAS DE DISEO ARQUITECTONICO.............................................95
2

2.7.5 METRICAS DE NIVEL DE COMPONENTES...............................................99

2.7.6 METRICAS DE DISEO DE INTERFAZ.....................................................99
3. IMPLEMENTACIN........................................................................................ 102
3.1 ELABORACION DE UN PROGRAMA DE IMPLEMENTACIN.........................102
3.1.1 OBJETIVO............................................................................................ 102
3.2 DESARROLLO DE SOFTWARE BASADO EN PROCESOS GILES..................103
3.2.1 DEFINICIN DE PROCESOS GILES.....................................................103
3.2.2 MODELOS DE PROCESOS GILES........................................................103
3.3 REUTILIZACIN DEL SOFTWARE................................................................106
3.3.1 USOS DE REUTILIZACIN....................................................................106
3.3.2 PATRONES DE DISEO........................................................................107
3.3.3 BASADA EN GENERADORES................................................................107
3.3.4 MARCOS DE TRABAJO.........................................................................108
3.3.5 SISTEMAS DE APLICACIONES..............................................................109
3.4 DOCUMENTACIN..................................................................................... 110
3.4.1 OBJETIVO E IMPORTANCIA...................................................................112
3.4.2 TIPOS.................................................................................................. 112
4. VERIFICACIN Y VALIDACIN......................................................................115
4.1 PRUEBAS................................................................................................... 115
4.1.1 OBJETIVO............................................................................................ 115
4.1.2 JUSTIFICACIN.................................................................................... 115
4.2 TIPOS DE PRUEBAS................................................................................... 117
4.2.1 INTEGRACION..................................................................................... 117
4.2.1.1 DESCENDENTE................................................................................. 117
4.2.1.2 ASCENDENTE................................................................................... 118
4.2.1.3 REGRESION...................................................................................... 119
4.2.2 VALIDACION........................................................................................ 119
4.2.2.1 ALFA................................................................................................. 120
4.2.2.2 BETA................................................................................................ 120
4.2.3 SISTEMA.............................................................................................. 121
4.2.3.1. RECUPERACIN............................................................................... 123
4.2.3.2 SEGURIDAD..................................................................................... 123
4.2.3.3. RESISTENCIA................................................................................... 123
4.2.3.4 RENDIMIENTO.................................................................................. 124
3

4.3 MANTENIMIENTO....................................................................................... 125

4.4.3 TIPOS DE MANTENIMIENTO.................................................................127
4.4.3.1 MANTENIMIENTO CORRECTIVO........................................................127
4.4.3.2 MANTENIMIENTO PREVENTIVO........................................................128
4.4.3.2 MANTENIMIENTO PREDECTIVO........................................................128
4.4 CARACTERSTICAS DEL MANTENIMIENTO..................................................129
4.4.1 COSTOS.............................................................................................. 129
4.4.2 EFECTOS............................................................................................. 131
4.4.3 TIPOS.................................................................................................. 132
4.4.3.1 MANTENIMIENTO CORRECTIVO........................................................134
4.4.3.2 MANTENIMIENTO PREVENTIVO/PERFECTIVO....................................135
4.4.3.2 MANTENIMIENTO ADAPTATIVO.........................................................136

UNID
AD 1.
UML Y
EL
PROC
ESO
UNIFI
CADO

1. UML Y EL PROCESO UNIFICADO

1.1CONCEPTUALIZACIN DE UML
Lenguaje Unificado de Modelado (UML) lenguaje grafico para visualizar,
especificar, construir y documentar un sistema.
Ofrece un estndar para escribir un "plano" del sistema (modelo), incluyendo
aspectos como procesos, funciones, expresiones, etc.
UML es un lenguaje de modelado, y no un mtodo. La mayor parte de los
mtodos consisten, al menos en principio, en un lenguaje y en un proceso para
modelar.

1.1.2 PRIMERAS METODOLOGAS

Segn [SGW94] una metodologa para el desarrollo de sistemas, entendida en
su sentido ms amplio, se compone de una combinacin completa y coherente
de tres elementos: un lenguaje de modelado, una serie de heursticas o pautas
de modelado y una forma de organizar el trabajo a seguir. Un cuarto elemento
que no es esencial pero que se hace ms que til necesario en todas las fases
y niveles del proceso de desarrollo, y que est ntimamente relacionado con la
metodologa a seguir, es la ayuda de una herramienta o grupo de ellas que
faciliten la automatizacin, el seguimiento y la gestin en la aplicacin de la
metodologa.
ROOM/UML-RT
Octopus/UML
COMET
HRT-HOOD
OOHARTS
ROPES
SiMOO-RT
Real-Time Perspectivede Artisan
Transformacin de modelos UML a lenguajes formales
El modelo de objetos TMO
ACCORD/UML

Sistema de Tiempo Real

Un sistema en el que el tiempo en que se produce su salida es significante.

Esto es debido a que generalmente la entrada corresponde a algn instante del
mundo fsico y la salida tiene relacin con ese mismo instante"

Una metodologa puede definirse como

"Una versin ampliada del ciclo de vida completo del desarrollo de sistemas,
que incluyen tareas o pasos para cada fase, funciones desempeadas en cada
tarea, productos resultantes, normas de calidad y tcnicas de desarrollo que se
utilizan en cada tarea".

COMET es una metodologa que emplea notacin UML, y est basada en un

ciclo de desarrollo iterativo, con las siguientes fases: modelado de requisitos,
anlisis, diseo, construccin e integracin incremental del software y
validacin del sistema. Los requisitos funcionales del sistema se especifican
mediante actores y casos de uso.

Octopus/UML es una metodologa de desarrollo orientado a objetos y utiliza

UML como notacin. Sin embargo, para algunos aspectos donde UML no
dispone de notacin especfica, utiliza la notacin original de Octopus.
ROPES emplea como notacin UML se basa en un proceso de desarrollo
iterativo (o en espiral). Est compuesto de diversas tendencias de la ingeniera
del software, tales como, anlisis de riesgo y calidad de software.

1.1.3 ANTECEDENTES DE UML

Grady Booch y Jim Rumbaugh comenzaron a unificar sus mtodos

(Octubre, 1994). OOD y OMT
Borrador de UML (versin 0.8) (Octubre, 1995)

Ivar Jacobson se une al proyecto (Noviembre, 1995) tres amigos.

Con el modelo OOES (OOSE: Object- Oriented Software Engineering).

UML 0.9 y se crea un consorcio (Junio, 1996)

OMG lanza una peticin para un lenguaje unificado (1996)

UML 1.0 es ofrecido al OMG (Enero, 1997

Se extiende el consorcio (EneroJulio, 1997)

UML 1.1 es ofrecido al OMG (Julio, 1997)

OMG adopta UML 1.1(Noviembre,1997)

Se crea el UML RTF (1998)

Aparece UML 1.3 (Mayo 1999)

UML 2.0 en 2001(se est revisando)

2

Versin UML 0.8 (octubre 1995) Mtodo Unificado

Versin UML 0.9 (junio 1996) Unin UML-OOSE

Versin UML 1.0 (enero 1997) Digital, HP, IBM, Microsoft, ORACLE,
Texas Inc., Unisys entre otros, es ofrecida a OMG

Versin UML 1.1 (julio 1997) es aprobada por la OMG convirtindose en

la notacin estndar de facto para el anlisis y el diseo orientado a

objetos.
Versin UML 1.2 (junio 1998) por OMG.
Versin UML 1.3 (junio 1999) por OMG.
Versin UML 2.0 (marzo 2005) por OMG.

1.2 ESTANDARIZACIN UML

Desde el ao 2005 UML es un estndar aprobado por la ISO como ISO/IEC
19501:2005 Information Technology- Open Distributed Processing- Unified
Modeling Language Versin 1.4.2.

1.2.1 VISTAS
UML es un lenguaje para visualizar. Para muchos programadores, la
diferencia entre pensar en una implementacin y transformarla en cdigo es
casi cero. Lo piensas, lo codificas. De hecho, algunas cosas se modelan mejor
directamente en cdigo. El texto es un medio maravilloso para escribir
expresiones y algoritmos de forma concisa y directa [Booch+2006].
Un lenguaje de modelado puede hacer de pseudo-cdigo, cdigo, imgenes,
diagramas, o una larga descripcin, de hecho, puede ser casi todo lo que le
ayuda a describir el sistema. Los elementos que componen un lenguaje de
modelado se llaman notacin.
UML es un lenguaje para especificar. Construir modelos precisos, no
ambiguos y completos. UML cubre la especificacin de todas las decisiones de
anlisis, diseo e implementacin que deben realizarse al desarrollar y
desplegar un sistema con gran cantidad de software.
UML es un lenguaje para construir de programacin visual, pero sus modelos
pueden conectarse de forma directa a una gran variedad de lenguajes de
programacin. Esto significa que es posible establecer correspondencias desde
un modelo UML a un lenguaje de programacin como JAVA, C++ o Visual Basic,
o incluso a tablas en una base de datos relacional o al almacenamiento
persistente de una base de datos orientada a objetos. Las cosas que se
expresan mejor grficamente tambin se representan grficamente en UML.
Esta correspondencia permite la ingeniera directa: la generacin de cdigo a
partir de un modelo UML en un lenguaje de programacin. Lo contrario tambin
es posible: se puede reconstruir un modelo en UML a partir de una
implementacin. La ingeniera inversa requiere, por tanto, herramientas que la
soporten e intervencin humana.

1.2.2 DIAGRAMAS
Un diagrama es la representacin grfica de un conjunto de elementos con sus
relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar.
Para poder representar correctamente un sistema, UML ofrece una amplia
variedad de diagramas para visualizar el sistema desde varias perspectivas.
UML incluye los siguientes diagramas:
Diagrama de casos de uso.
Diagrama de clases.
Diagrama de objetos.
4

 Diagrama de secuencia.
Diagrama de colaboracin.
Diagrama de estados.
Diagrama de actividades.
Diagrama de componentes.
Diagrama de despliegue.
Los diagramas ms interesantes (y los ms usados) son los de casos de uso,
clases y secuencia, por lo que nos centraremos en stos. Pare ello, se utilizar
ejemplos de un sistema de venta de entradas de cine por Internet.
El diagrama de casos de usos representa grficamente los casos de uso que
tiene un sistema. Se define un caso de uso como cada interaccin supuesta
con el sistema a desarrollar, donde se representan los requisitos funcionales.
Es decir, se est diciendo lo que tiene que hacer un sistema y cmo. En la
figura 3 se muestra un ejemplo de casos de uso, donde se muestran tres
actores (los clientes, los taquilleros y los jefes de taquilla) y las operaciones
que pueden realizar (sus roles).
El diagrama de clases muestra un conjunto de clases, interfaces y sus
relaciones. ste es el diagrama ms comn a la hora de describir el diseo de
los sistemas orientados a objetos. En la figura 4 se muestran las clases
globales, sus atributos y las relaciones de una posible solucin al problema de
la venta de entradas.
En el diagrama de secuencia se muestra la interaccin de los objetos que
componen un sistema de forma temporal. Siguiendo el ejemplo de venta de
entradas, la figura 5 muestra la interaccin de crear una nueva sala para un
espectculo.
El resto de diagramas muestran distintos aspectos del sistema a modelar. Para
modelar el comportamiento dinmico del sistema estn los de interaccin,
colaboracin, estados y actividades. Los diagramas de componentes y
despliegue estn enfocados a la implementacin del sistema.

1.2.3 ELEMENTOS DE MODELADO

Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y
de contenido.
Un diagrama de clases est compuesto por los siguientes elementos:

Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Clase. Es la unidad bsica que encapsula toda la informacin de un Objeto (un

objeto es una instancia de una clase). A travs de ella podemos modelar el
entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres
divisiones:

Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que

caracterizan a la Clase (pueden ser private, protected o public).

Inferior: Contiene los mtodos u operaciones, los cuales son la forma

como interacta el objeto con su entorno (dependiendo de la visibilidad:
private, protected o public).

Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el
grado de comunicacin y visibilidad de ellos con el entorno, estos son:
o

public (+): Indica que el atributo ser visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.

private (-): Indica que el atributo slo ser accesible desde dentro de la
clase (slo sus mtodos lo pueden accesar).

protected (#): Indica que el atributo no ser accesible desde fuera de la

clase, pero si podr ser accesado por mtodos de la clase adems de las
subclases que se deriven (ver herencia).

Los mtodos u operaciones de una clase son la forma en como sta interacta con su
entorno, stos pueden tener las caractersticas:

public (+): Indica que el mtodo ser visible tanto dentro como fuera de la clase,
es decir, es accsesible desde todos lados.

private (-): Indica que el mtodo slo ser accesible desde dentro de la clase (slo
otros mtodos de la clase lo pueden accesar).

protected (#): Indica que el mtodo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de mtodos de las
subclases que se deriven (herencia).
Relaciones entre Clases:

En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se

anotan en cada extremo de la relacin y stas pueden ser:
8

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n)

nmero fijo: m (m denota el nmero).

Herencia (Especializacin/Generalizacin): Indica que una subclase hereda los

mtodos y atributos especificados por una Super Clase, por ende la Subclase adems de
poseer sus propios mtodos y atributos, poseer las caractersticas y atributos visibles de
la Super Clase (public y protected), ejemplo:

Agregacin. Cuando se requiere componer objetos que son instancias de

clases definidas por el desarrollador de la aplicacin, tenemos dos
posibilidades:

Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto
incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de
relacin es comnmente llamada Composicin (el Objeto base se construye a
partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del

objeto incluido es independiente del que lo incluye. Este tipo de relacin es
comnmente llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).

Asociacin: La relacin entre clases conocida como Asociacin, permite

asociar objetos que colaboran entre s. Cabe destacar que no es una relacin
fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Dependencia o Instanciacin (uso): Representa un tipo de relacin muy

particular, en la que una clase es instanciada (su instanciacin es dependiente
de otro objeto/clase). Se denota por una flecha punteada. El uso ms particular
de este tipo de relacin es para denotar la dependencia que tiene una clase de
otra, como por ejemplo una aplicacin grafica que instancia una ventana (la
creacin del Objeto Ventana est condicionado a la instanciacin proveniente
desde el objeto Aplicacin):

1.2.4 MECANISMOS
Mecanismos de extensibilidad

Estereotipos. Extienden el vocabulario de UML, permitiendo aadir nuevos

tipos de bloques de construccin. Los estereotipos son el mecanismo de

extensibilidad incorporado ms utilizado dentro de UML. Un estereotipo
representa una distincin de uso.
Valores etiquetados. Extienden las propiedades de un bloque de
construccin, aadiendo nueva informacin
Restricciones. Extiende la semntica de un bloque, aadiendo reglas o
modificando las existentes.
10

11

1.2.4 EXTENCIONES UML

Permiten ser una especie de especificacin abierta que puede cubrir aspectos
de modelado no especificados. Estos mecanismos permiten extender la
notacin y semtica de UML.
Est dividido en 3 tipos los cuales son:

Estereotipos
Representa una distincin de uso. Puede ser aplicado a cualquier
elemento de modelado, incluyendo clases, paquetes, relaciones de
herencia.

Extensiones de Modelado de Negocio

Documento separado dentro de la especificacin UML define clases y
estereotipos de asociacin especficos que extienden UML hasta cubrir
conceptos de modelado de negocio.

Lenguaje restrictivo (constraint) de objetos (OCL)

Es un lenguaje formal diseado para ser fcil de leer y de escribir. OCL
es ms funcional que el lenguaje natural, pero no tan preciso como un
lenguaje de programacin.

1.3 HERRAMIENTAS CASE PARA EL DESARROLLO

Y MODELADO DE SI
Son diversas aplicaciones informticas destinadas a aumentar la productividad
en el desarrollo de software reduciendo el costo de las mismas en trminos de
tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos
del ciclo de vida de desarrollo del software en tareas como el proceso de
realizar un diseo del proyecto, clculo de costos, etc.

1.3.1 DEFINICIN CASE

Son un conjunto de programas y ayudas que dan asistencia a los analistas,
ingenieros de software y desarrolladores, durante todos los pasos de ciclos de
vida de desarrollo de un Software su ciclo de vida consiste en:

Investigacin preliminar
Anlisis
12

 Diseo
Implementacin
Instalacin

1.3.2 CLASIFICACIN CASE

Existen 3 tipos de clasificacin los cuales son los siguientes

Middle CASE
Lower CASE
Upper CASE
Estos se utilizan dependiendo de:

Plataformas de soporte
Las fases del ciclo de vida del desarrollo de sistemas que cubren
La arquitectura de las aplicaciones que se producen
Su funcionabilidad.

Algunas ventajas que pueden llegar a tener son las siguientes:

Permite lograr importantes mejoras de productividad a mediano plazo.

Permite un eficiente soporte al mantenimiento de sistemas.
Mantiene las consistencias de nivel de los sistemas operativos.
Permite lograr importantes mejoras de productividad a corto plazo.
Permite un eficiente soporte al mantenimiento de sistemas.

Algunas desventajas que pueden tener son las siguientes:

No garantizan las consistencias de los resultados a nivel corporativo.

No garantiza la eficiencia del anlisis y diseo.
No permite la integracin de ciclo de vida.

13

1.4 DIAGRAMAS
1.4.1 ACTIVIDAD
El diagrama de Actividad es un diagrama de flujo del proceso multi-propsito
que se usan para modelar el comportamiento del sistema. Los diagramas de
actividad se pueden usar para modelar un Caso de Uso, o una clase, o un
mtodo complicado.
En ULM un diagrama de actividad se usa para mostrar la secuencia de
actividades. Los diagramas de actividad muestran el flujo de trabajo desde un
punto de inicio hasta el punto final detallando muchas de las rutas de
decisiones que existen en el progreso de eventos contenidos en la actividad.
Estos tambin pueden usarse para detallar situaciones donde el proceso
paralelo puede ocurrir en la ejecucin de algunas actividades.

Las siguientes secciones describen los elementos que constituyen un diagrama

de actividades:
Actividades
Una actividad es la especificacin de una
secuencia parametrizada de comportamientos.
Una actividad muestra un rectngulo con las
puntas redondeadas adjuntando todas las
acciones, flujos de control y otros elementos que
constituyen la actividad.
Acciones
Las

Una accin representa un solo paso dentro de una actividad.

acciones se denotan por rectngulos con las puntas
redondeadas.

14

Restriccin de Accin
Las restricciones se pueden adjuntar a una accin.

Flujo de control
Un flujo de control muestra el flujo de control de una
accin a otra. Su notacin es una lnea con una punta de flecha.

Nodo inicial
Un nodo inicial o de comienzo se describe por un gran punto
negro.

Nodo Final
Hay dos tipos de nodos finales: nodos finales de
actividad y de flujo. El nodo final de actividad se describe
como un crculo con punto dentro del mismo.
El nodo final se flujo se describe
como un circulo con una cruz
dentro del mismo.

La diferencia entre los dos tipos de nodos es que el nodo

final del flujo denota el final de un solo flujo de control, y el nodo final de
actividad denota el final de todos los flujos finales dentro de la actividad.
Flujo de objetos y Objeto
Un flujo de objeto en la ruta a lo largo de la cual pueden
pasar objetos o datos. Un objeto se muestra cmo un
rectngulo. Un flujo de objeto se muestra como un
conector con una punta de flecha denotando la direccin
a la cual se est pasando el objeto.
Un almacn de clave se muestra como un objeto con las claves
<<datastore>>
15

Nodos de Decisin y Combinacin

Los nodos de decisin y combinacin tiene la
misma notacin: una forma de diamante. Los
dos de pueden nombrar. Los flujos de control
que provienen de un nodo de decisin tendrn
condiciones de guarda que permitirn el
control para fluir si la condicin de guara se
realiza. El siguiente diagrama muestra el uso
de un nodo de decisin y un nodo de
combinacin.
Nodos de Bifurcacin y Unin
Las bifurcaciones y uniones tienen la misma notacin: tanto una barra
horizontal como vertical (la orientacin depende de si el flujo de control va de
derecha a izquierda o hacia abajo y arriba. Estos indican el comienzo y final de
hilos actuales de control.
Una unin es diferente de una combinacin ya
que la unin sincroniza dos flujos de entrada y
produce un solo flujo de salida. El flujo de
salida desde una unin no se puede ejecutar
hasta que todos los flujos se hayan recibido.
Una combinacin pasa cualquier flujo de
control directamente a travs de esta. Si dos o ms flujos se hayan recibido.
Una combinacin pasa cualquier flujo de control directamente a travs de esta.
Si dos o ms flujos de entrada se reciben por un smbolo de combinacin, la
accin a la que el flujo de salida apunta se ejecuta dos o ms veces.
Regin de Expansin
Una regin de expansin es una regin de
actividad estructurada que se ejecuta muchas
veces. Los nodos de expansin de salida y entrada
se dibujan como un grupo de tres casillas
representando una seleccin mltiple de tems. La
clave reiterativa, paralelo, o flujo se muestra en la
esquina izquierda arriba de la regin.
Gestores de Excepcin
Los gestores de excepcin se pueden modelar en
diagrama de actividad como en siguiente ejemplo.
Regin de Actividad Interrumpible
16

Una regin de actividad interrumpida rodea un grupo

de acciones que se pueden interrumpir.
Particin
Una particin de una
calles horizontales o

actividad e muestra como

verticales.

1.4.2 MODELADO A DISTINTOS NIVELES

Los modelos a distintos niveles, conocidos tambin como lineales jerrquicos,
modelos anidados, modelos mixtos, entre otros nombres) son modelos
estadsticos de parmetro que varan en ms de un nivel. Estos modelos
pueden ser vistos como generalizaciones de modelos lineales, aunque tambin
pueden extender los modelos no lineales., aunque tambin pueden extender
los modelos no lineales. Aunque
Distintos niveles
Alto nivel en etapas tempranas

Destinado a Stakeholders no tcnicos

Exploracin Conceptual del Problema
Refinamiento va modelos medios detallados

Modelos de niveles medios

Especificacin de Capacidades escenciales del sistema

Historicamente: ERs, DFDs, , FSMs, etc.
Recientemente: Escenarios, Patrones de Diseo, etc.

Modelos Detallados
Modelos Formales

1.4.3 DIAGRAMAS DE CASO DE USO

Los diagramas de caso de uso documentan el comportamiento de un sistema
desde el punto de vista del usuario. Por lo tanto los casos de uso determinan
los requisitos funcionales del sistema, es decir, representan las funciones que
un sistema puede ejecutar.

17

Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean

especialmente tiles en la comunicacin con el cliente.

Elementos bsicos
Actores: Los actores representan un tipo de usuario del sistema. Se entiende
como usuario cualquier cosa externa que interacta con el sistema.
No tiene por qu ser un ser humano, puede ser otro sistema
informtico o unidades organizativas o empresas.
Siempre hay que intentar independizar los actores de la forma en
que se interacta con el sistema. Un actor en un diagrama de caso
de uso representa un rol que alguien puede estar jugando, no un individuo
particular por lo tanto puede haber personas particulares que pueda estar
usando el sistema de formas diferentes en diferentes ocasiones.
Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del
sistema que se est desarrollando. Se representa mediante un
ovulo. Cada caso de uso debe detallarse habitualmente
mediante una descripcin textual.

Asociaciones: hay una asociacin entre un actor y un caso de uso si el actor

interactua con el sistema para llevar a cabo el caso de uso. Un
caso de uso debe especificar un comportamiento deseado,
pero no imponer como se llevara a cabo ese comportamiento,
es decir, debe decir QU pero no CMO. Esto se realiza
utilizando escenarios.

Escenario: es una interaccin entre el sistema y los actores, que pueden ser
descritos mediante una secuencia de mensajes. Un caso de uso es una
generalizacin de un escenario.

Tipo de acciones.
Existen tres tipos de asociacin o relaciones en los diagramas de casos de uso:
18

Include: Se puede incluir una relacin entre dos casos de uso de tipo include
si se desea especificar comportamiento comn en dos o ms casos de uso.

Las ventajas de esta asociacin son:

Las descripciones de los casos de uso son ms cortas y se entienden

mejor.
La identificacin de funcionalidad comn puede ayudar a descubrir el
posible uso de componentes ya existentes en la implementacin.

Las desventajas son:

La inclusin de estas relaciones hace que los diagramas sean ms difcil

de leer, sobre todo para los clientes.

Extend: Se puede incluir una relacin entre dos casos de uso de tipo include
si se desea especificar diferentes variantes del mismo caso de uso. Es decir,
esta relacin implica que el comportamiento de un caso de uso es diferente
dependiendo de ciertas circunstancias. En principio esas variaciones pueden
tambin mostrarse como diferentes descripciones de escenarios asociadas al
mismo caso de uso.

Generalizaciones: En un diagrama de casos de uso tambin pueden mostrarse

generalizaciones (relaciones de herencia) para mostrar que diferentes
elementos estn relacionados como tipos de otros. Son aplicables a actores o
casos de uso, pero para estos ltimos la semntica es muy similar a las
relaciones extend.

19

Limites del sistema: Resulta til dibujar los lmites

del sistema cuando se pretende hacer un
diagrama de casos de uso para parte del sistema.

1.4.4 RELACION CON LOS

REQUISITOS
El objetivo principal de esta herramienta es poder
mostrar al usuario, desde los momentos iniciales
del diseo, el aspecto que tendr la aplicacin una
vez desarrollada. Ello facilitar la aplicacin de los cambios que se consideren
necesarios, todava en la fase de diseo.
La herramienta ser tanto ms til, cuanto ms rpidamente permita la
construccin del prototipo y por tanto antes, se consiga la implicacin del
usuario final en el diseo de la aplicacin. Asimismo, es importante poder
aprovechar como base el prototipo para la construccin del resto de la
aplicacin. Actualmente, es imprescindible utilizar productos que incorporen
esta funcionalidad por la cambiante tecnologa y necesidades de los usuarios.
Los prototipos han sido utilizados ampliamente en el desarrollo de sistemas
tradicionales, ya que proporcionan una realimentacin inmediata, que ayudan
a determinar los requisitos del sistema. Las herramientas CASE estn bien
dotadas, en general, para crear prototipos con rapidez y seguridad.
Tiene que existir una relacin con los requisitos en:

Dependencia
Asociacin
Generalizacin
Realizacin

20

1.5 UTILIZACIN DE HERRAMIENTAS CASE

Las herramientas
CASE (Computer Aided Software Engineering, Ingeniera
de
Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a
aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas
en trminos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los
aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar
un diseo del proyecto, clculo de costos, implementacin de parte del cdigo
automticamente con el diseo dado, compilacin automtica, documentacin o deteccin
de errores entre otras. Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje
y por lo tanto un producto que analizaba la relacin existente entre los requisitos de un
problema y las necesidades que stos generaban, el lenguaje en cuestin se denominaba
PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las
necesidades de los diseadores PSA (Problem Statement Analyzer).
Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos
proyectos informticos, la primera herramienta CASE fue Excelerator que sali a la luz en
el ao 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en
la que IBM haba conseguido una alianza con la empresa de software AD/Cycle para
trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que
abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido
siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto
completamente abriendo el mercado de diversas herramientas ms especficas para cada
fase del ciclo de vida del software.

Objetivos
Mejorar la productividad en el desarrollo y mantenimiento del software.
Aumentar la calidad del software.
Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas
informticos.
Mejorar la planificacin de un proyecto
Aumentar la biblioteca de conocimiento informtico de una empresa
ayudando a la bsqueda de soluciones para los requisitos.

21

 Automatizar el desarrollo del software, la documentacin, la generacin

de cdigo, las pruebas de errores y la gestin del proyecto.
Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la
documentacin
Gestin global en todas las fases de desarrollo de software con una
misma herramienta.
Facilitar el uso de las distintas metodologas propias de la ingeniera del
software.

Clasificacin
Aunque no es fcil y no existe una forma nica de clasificarlas, las
herramientas CASE se pueden clasificar teniendo en cuenta los siguientes
parmetros:
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.
La siguiente clasificacin es la ms habitual basada en las fases del ciclo de
desarrollo que cubren:

Upper CASE (U-CASE), herramientas que ayudan en las fases

de planificacin, anlisis de requisitos y estrategia del desarrollo, usando,
entre otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en

el anlisis y diseo de la aplicacin.

Lower CASE (L-CASE), herramientas que semi-automatizan la generacin

de cdigo, crean programas de deteccin de errores, soportan
la depuracin de programas y pruebas. Adems automatizan la
documentacin completa de la aplicacin. Aqu pueden incluirse las
herramientas de Desarrollo rpido de aplicaciones.

22

1.5.1 PLANIFICACIN DE LOS SISTEMAS DE GESTIN

Un Sistema de Gestin es un conjunto de etapas unidas en un proceso
continuo, que permite trabajar ordenadamente una idea hasta lograr mejoras y
su continuidad.
Se establecen cuatro etapas en este proceso, que hacen de este sistema, un
proceso circular virtuoso, pues en la medida que el ciclo se repita recurrente y
recursivamente, se lograr en cada ciclo, obtener una mejora.
1.
2.
3.
4.

Las cuatro etapas del sistema de gestin son:

Etapa de Ideacin
Etapa de Planeacin
Etapa de Implementacin
Etapa de Control

Sistema de gestin
Etapa de Ideacin:
El objetivo de esta etapa es trabajar en la idea que guiar los primeros pasos
del proceso de creacin que se logra con el sistema de gestin propuesto.
Existen varias metodologas para lograr refinar la idea. Sin embargo, se
recomienda una muy prctica:
23

Lluvia de ideas o Brainstorming:

Primero se debe generar el mximo de ideas para obtener un amplio espectro
de posibilidades en dnde atacar.
El proceso consiste en lo siguiente en que un grupo o una persona, durante un
tiempo prudente (de 10-30 minutos), se enfoca en generar o lanzar ideas sin
restricciones, pero que tengan cercana con el tema que se est tratando.
Una vez que se tenga un listado adecuado, se procede a analizar las ideas y a
pulir su cercana con lo que realmente se quiere.
La idea central de este proceso es que aqu se debe definir claramente el
objetivo perseguido, es decir el Qu queremos lograr?. Una vez definido, se
procede al Cmo lograrlo? y pasamos a la siguiente etapa.
Etapa de Planeacin (Planificacin):
Dentro del proceso, la planificacin constituye una etapa fundamental y el
punto de partida de la accin directiva, ya que supone el establecimiento de
sub-objetivos y los cursos de accin para alcanzarlos.
En esta etapa, se definen las estrategias que se utilizarn, la estructura
organizacional que se requiere, el personal que se asigna, el tipo de tecnologa
que se necesita, el tipo de recursos que se utilizan y la clase de controles que
se aplican en todo el proceso.

Proceso Formal de Planificacin

El proceso de planificacin contiene un nmero determinado de etapas que
hacen de ella una actividad dinmica, flexible y continua. En general, estas
24

etapas consideran, para cada una de las perspectivas mencionadas, el examen

del medio externo (identificacin de oportunidades y amenazas), la evaluacin
interna (determinacin de fortalezas y debilidades), y concluye con la
definicin de una postura competitiva sugerida (objetivos y metas).
A nivel corporativo, se obtienen como resultado las directrices estratgicas y
los objetivos de desempeo de la organizacin. Adems, se determina la
asignacin de recursos, la estructura de la organizacin (que se necesita para
poner en prctica exitosamente la estrategia definida), los sistemas
administrativos y las directrices para la seleccin y promocin del personal
clave.
A nivel de negocios y funcional, los resultados se enmarcan en propuestas de
programas estratgicos de accin y programacin de presupuestos. Estas
propuestas son, finalmente, evaluadas y consolidadas a nivel corporativo.
Etapa de Implementacin (Gestin):
En su significado ms general, se entiende por gestin, la accin y efecto de
administrar. Pero, en un contexto empresarial, esto se refiere a la direccin que
toman las decisiones y las acciones para alcanzar los objetivos trazados.
Es importante destacar que las decisiones y acciones que se toman para llevar
adelante un propsito, se sustentan en los mecanismos o instrumentos
administrativos (estrategias, tcticas, procedimientos, presupuestos, etc.), que
estn sistmicamente relacionados y que se obtienen del proceso de
planificacin. (Vase la figura: Esquema de gestin).

Esquema de Gestin

Etapa de Control:
Para este concepto se han desarrollado varias definiciones (Fuente: CABRERA,
E., Control [En lnea], Monografias.com, [citado en marzo de 2005].
Disponible en www.monografias.com/trabajos14/control/control.shtml), a lo

25

largo de su evolucin, sin embargo, todas se centran en la siguiente idea

general:
El control es una funcin administrativa, esencialmente reguladora, que
permite verificar (o tambin constatar, palpar, medir o evaluar), si el elemento
seleccionado (es decir, la actividad, proceso, unidad, sistema, etc.), est
cumpliendo sus objetivos o alcanzando los resultados que se esperan.
Es importante destacar que la finalidad del control es la deteccin de errores,
fallas o diferencias, en relacin a un planteamiento inicial, para su correccin
y/o prevencin. Por tanto, el control debe estar relacionado con los objetivos
inicialmente definidos, debe permitir la medicin y cuantificacin de los
resultados, la deteccin de desviaciones y el establecimiento de medidas
correctivas y preventivas.

1.5.2 GESTIN DE PROYECTOS

La gestin de proyectos tambin conocida como gerencia o administracin de proyectos
es la disciplina que gua e integra los procesos de planificar, captar, dinamizar, organizar
talentos y administrar recursos, con el fin de culminar todo el trabajo requerido para
desarrollar un proyecto y cumplir con el alcance, dentro de lmites de tiempo, y costo
definidos: sin estrs y con buen clima interpersonal. Todo lo cual requiere liderar los
talentos, evaluar y regular continuamente las acciones necesarias y suficientes.
Otras denominaciones equivalentes segn los pases: gerencia o gestin de proyectos,
gestin integral de proyectos, direccin integrada de proyectos (Espaa), etc. Es una
disciplina de gerencia y no una herramienta ingenieril, confusin derivada a su intenso uso
en proyectos civiles.
Caractersticas
Temporal significa que cada proyecto tiene un comienzo definido y un final
definido. El final se alcanza cuando se ha logrado alcance y objetivos del
proyecto o cuando queda claro que el alcance y objetivos del proyecto no sern
o no podrn ser alcanzados, o cuando la necesidad a satisfacer por el
proyecto- ya no exista y el proyecto sea cancelado. Temporal no
necesariamente significa de corta duracin; muchos proyectos duran varios
aos.
Un proyecto crea productos entregables bienes y/o servicios o resultados
nicos, pudiendo crear:
Un producto bien o artculo producido, que es cuantificable, y que puede ser
un elemento terminado o un componente o un servicio prestado.

26

 La capacidad de prestar un servicio como, por ejemplo, la capacidad de

produccin o de prestacin de servicio de las funciones del negocio, que
respaldan la produccin, la distribucin, etc.
Un resultado como, por ejemplo, salidas, documentos, ideas Por ejemplo,
de un proyecto de investigacin se obtienen conocimientos que pueden usarse
para determinar si existe o no una tendencia o si un nuevo proceso beneficiar
a la sociedad.
La singularidad es una caracterstica importante de los productos o entregables
de un proyecto. Por ejemplo, se han construido muchos miles de edificios de
oficinas, pero cada edificio individual es nico: diferente propietario, diferente
diseo, diferente ubicacin, diferente contratista, etc. Por otra parte se prestan
miles de horas de servicio de consultora, etc., pero cada consultora es
diferente, con diferentes clientes y diferentes consultores, resolviendo
situaciones diferentes, etc., etc. La presencia de elementos repetitivos en la
produccin de bienes o en la prestacin de servicios- no cambia la condicin
fundamental de nico

Elaboracin gradual

La elaboracin gradual es una caracterstica de los proyectos que acompaa a

los conceptos de temporal y nico. Elaboracin gradual significa desarrollar
en pasos e ir aumentando mediante incrementos. Por ejemplo, el alcance de un
proyecto se define de forma general al comienzo del proyecto, y se hace ms
explcito y detallado a medida que el equipo del proyecto desarrolla un mejor y
ms completo entendimiento de los objetivos y de los productos bienes y/o
servicios- y entregables asociados. La elaboracin gradual no debe confundirse
con lentitud ni corrupcin del alcance.

1.5.3 SOPORTE
El soporte para modelado UML e ingeniera inversa de NetBeans resulta muy
til, especialmente en el anlisis de grandes proyectos. Lamentablemente,
NetBeans ya no incluye un gestor de mdulos, y -en teora- nos tenemos que
limitar a los plugins del mismo, entre los que no se incluye dicha funcionalidad.
En ella, descargaremos el cluster UML, descomprimiendo su contenido en la
raz del directorio de instalacin de NetBeans. Una vez hecho, el directorio
uml (que contiene el cluster) debe quedar al mismo nivel que otros cluster
como java, profiler, etc. Listo! Tras reiniciar NetBeans, el mdulo estar
listo para usar.

27

1.5.4 ANLISIS Y DISEO

1. Planificacin y Especificacin de Requisitos: Planificacin, definicin de
requisitos, conocer los procesos del dominio, etc.
2. Construccin: La construccin del sistema. Se subdivide en las siguientes:
Anlisis: Se analiza el problema a resolver desde la perspectiva de los
usuarios y de las entidades externas que van a solicitar servicios al
sistema.
Diseo: El sistema se especifica en detalle, describiendo cmo va a
funcionar internamente para satisfacer lo especificado en el anlisis.
Implementacin: Se lleva lo especificado en el diseo a un lenguaje de
programacin.
Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el
software funciona correctamente y que satisface lo especificado en la
etapa de Planificacin y Especificacin de Requisitos.
3. Instalacin: La puesta en marcha del sistema en el entorno previsto de uso.
UML
El Unified Modeling Language (UML) define un lenguaje de modelado orientado
a objetos comn para visualizar, especificar, construir y documentar los
componentes de un sistema software OO.

El UML no es una metodologa, sino una notacin que trata de posibilitar

el intercambio de modelos de software.

Un modelo es una simplificacin de la realidad creada para comprender

mejor un sistema.

UML es un lenguaje de modelado visual, utiliza diagramas, para la

representacin de los sistemas.

Diagramas para modelar el Comportamiento del Sistema:

28

Diagrama de Casos de Uso: Muestra un conjunto de casos de uso y

actores y sus relaciones.

Diagrama de Secuencia: Diagrama de interaccin con la relacin

temporal de los mensajes y los objetos.

Diagrama de Colaboracin: Diagrama de interaccin que resalta la

organizacin estructural de los objetos que envan y reciben mensajes.

Diagrama de Estados: Muestra una mquina de estados, que consta de

estados, transiciones, eventos y actividades. Vista dinmica del sistema.

Diagrama de Actividades: Muestra el flujo de actividades dentro de un

sistema.

Diagramas para modelar la Estructura del Sistema:

Diagrama de Clases: Muestra un conjunto de clases, interfaces y

colaboraciones, as como sus relaciones.

Diagrama de Objetos: Muestra un conjunto de objetos y sus relaciones.

Diagrama de Componentes: Muestra la organizacin y las dependencias

entre un conjunto de componentes.

Diagrama de Despliegue: Representa la infraestructura de un sistema en

tiempo de ejecucin.

29

1.5.6 INTEGRACIN Y PRUEBAS

INTEGRACIN
En el nivel ms bajo del espectro de integracin est la herramienta
individual (solucin puntual). Cuando las herramientas proporcionan facilidades
para el intercambio de datos (la mayora lo hace), el nivel de integracin
aumenta ligeramente. Estas herramientas generan una salida en un formato
estndar compatible con otras herramientas que puedan leer ese formato. En
algunos casos, los que construyen herramientas CASE complementarias
trabajan juntos para establecer un puente entre ellas (p. ej.: una herramienta
de anlisis y diseo que se une a un generador de cdigo). Utilizando este
enfoque, la compatibilidad entre herramientas puede generar productos finales
que seran difciles de desarrollar utilizando cada herramienta por separado. La
integracin por fuente nica se da cuando un constructor de herramientas
CASE integra diferentes herramientas y las vende como un nico paquete.
Aunque este enfoque es bastante efectivo, la mayora de los entornos
provenientes de una misma fuente tienen una arquitectura cerrada que hace
difcil aadir nuevas herramientas de otros vendedores.

La principal ventaja de la utilizacin de una herramienta CASE, es la mejora

de la calidad de los desarrollos realizados y, en segundo trmino, el aumento
de la productividad. Para conseguir estos dos objetivos es conveniente contar
con una organizacin y una metodologa de trabajo adems de la propia
herramienta.

La mejora de calidad se consigue reduciendo sustancialmente muchos de

los problemas de anlisis y diseo, inherentes a los proyectos de mediano y
gran tamao (lgica del diseo, coherencia, consolidacin, etc.).
30

La mejora de productividad se consigue a travs de la automatizacin de

determinadas tareas como la generacin de cdigo y la reutilizacin de objetos
o mdulos.
PRUEBAS
Las pruebas son bsicamente un conjunto de actividades dentro del
desarrollo de software. Dependiendo del tipo de pruebas, estas actividades
podrn ser implementadas en cualquier momento de dicho proceso de
desarrollo.
Existen tres tipos de pruebas:
Por Programas Individuales: para realizar la prueba, se toma por separado
cada uno de stos y se ejecutan para comprobar que hagan lo esperado.
Por Secciones del Sistema: Una vez realizadas las pruebas a programas
individuales, deben realizarse pruebas a secciones del sistema. Por ejemplo dar
de alta, dar de baja y modificaciones de la informacin.
Por Sistema Total: en esta ltima prueba, una vez corroborado que el
sistema cumple con su objetivo, se libera y pasa a la etapa de implementacin.

1.5.7 PROTOTIPOS
Es un modelo a escala o facsmil de lo real, pero no tan funcional para que
equivalga a un producto final, ya que no lleva a cabo la totalidad de las
funciones necesarias del sistema final. Proporcionando una retroalimentacin
temprana por parte de los usuarios acerca del Sistema.
El principal propsito es obtener y validar los requerimientos esenciales,
manteniendo abiertas, las opciones de implementacin. Esto implica que se
debe tomar los comentarios de los usuarios, pero debemos regresar a sus
objetivos para no perder la atencin.
En la fase de Diseo, su propsito, basndose en los requerimientos
previamente obtenidos, es mostrar las ventanas, su navegacin, interaccin,
controles y botones al usuario y obtener una retroalimentacin que nos permite
mejorar el Diseo de Interfaz.

1.5.8 MANTENIMIENTO
Es importante considerar la evaluacin y el monitoreo de un sistema en
trminos del mantenimiento necesario y, en consecuencia, reducir o contener
los costos implcitos. El mantenimiento de sistemas puede clasificarse en
cuatro grupos, cada uno de los cuales repercute en el plan estratgico de
informacin institucional de diferentes maneras:
Mantenimiento correctivo. Independientemente de cun bien diseado,
desarrollado y probado est un sistema o aplicacin, ocurrirn errores
31

inevitablemente. Este tipo de mantenimiento se relaciona con la solucin o la

correccin de problemas del sistema. Atae generalmente a problemas no
identificados durante la fase de ejecucin. Un ejemplo de mantenimiento
correctivo es la falta de una caracterstica requerida por el usuario, o su
funcionamiento defectuoso.
Mantenimiento para fines especficos. Este tipo de mantenimiento se refiere a
la creacin de caractersticas nuevas o a la adaptacin de las existentes segn
lo requieren los cambios en la organizacin o los usuarios, por ejemplo, los
cambios en el cdigo tributario o los reglamentos internos de la organizacin
Mantenimiento para mejoras. Se trata de la extensin o el mejoramiento del
desempeo del sistema, ya sea mediante el agregado de nuevas
caractersticas, o el cambio de las existentes. Un ejemplo de este tipo de
mantenimiento es la conversin de los sistemas de texto a GUI (interfaz grfica
de usuarios).
Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno
de los ms eficaces en funcin de los costos, ya que si se realiza de manera
oportuna y adecuada, puede evitar serios problemas en el sistema.

3 IMPLEMENTACIN
Dentro del ciclo de vida se encuentra la fase de implementacin de un
sistema, es la fase ms costosa y que consume ms tiempo, se dice que es
costosa porque muchas personas, herramientas y recursos, estn involucrados
en el proceso y consume mucho tiempo porque se completa todo el trabajo
realizado previamente durante el ciclo de vida.
En la fase de implementacin se instala el nuevo sistema de informacin
para que empiece a trabajar y se capacita a sus usuarios para que puedan
utilizarlo.
La instalacin puede realizarse segn cuatro mtodos: Directo, paralelo,
piloto y en fases.
Mtodo directo: Se abandona el sistema antiguo y se adopta
inmediatamente el nuevo. Esto puede ser sumamente riesgoso porque si algo
marcha mal, es imposible volver al sistema anterior, las correcciones debern
hacerse bajo la marcha. Regularmente con un sistema nuevo suelen surgir
problemas de pequea y gran escala. Si se trata de grandes sistemas, un
problema puede significar una catstrofe, perjudicando o retrasando el
desempeo entero de la organizacin.
Mtodo paralelo: Los sistemas de informacin antiguo y nuevo operan
juntos hasta que el nuevo demuestra ser confiable. Este mtodo es de bajo
riesgo. Si el sistema nuevo falla, la organizacin puede mantener sus
actividades con el sistema antiguo. Pero puede representar un alto costo al
32

requerir contar con personal y equipo para laborar con los dos sistemas, por lo
que este mtodo se reserva especficamente para casos en los que el costo de
una falla sera
considerable.
Mtodo piloto: Pone a prueba el nuevo sistema slo en una parte de la
organizacin. Al comprobar su efectividad, se implementa en el resto de la
organizacin. El mtodo es menos costoso que el paralelo, aunque ms
riesgoso. Pero en este caso el riesgo es controlable al limitarse a ciertas reas,
sin afectar toda la empresa.
Mtodo en fases: La implementacin del sistema se divide en partes o
fases, que se van realizando a lo largo de un periodo de tiempo,
sucesivamente. Una vez iniciada la primera fase, la segunda no se inicia hasta
que la primera se ha completado con xito. As se contina hasta que se
finaliza con la ltima fase. Es costoso porque se hace ms lenta la
implementacin, pero sin duda tiene el menor riesgo.

33

UNID
AD 2.
DISE
O DE
SISTE
MAS

34

2. DISEO DE SISTEMAS
2.1 DISEO ESTRUCTURADO DE SISTEMAS
El diseo estructurado de sistemas se ocupa de la identificacin, seleccin y
organizacin de los mdulos y sus relaciones. Se comienza con la
especificacin resultante del proceso de anlisis, se realiza una descomposicin
del sistema en mdulos estructurados en jerarquas, con caractersticas tales
que permitan la implementacin de un sistema que no requiera elevados
costos de mantenimiento. La idea original del diseo estructurado fue
presentada en la dcada de los '70, por Larry Constantine, y continuada
posteriormente por otros autores: Myers, Yourdon y Stevens.
El diseo estructurado es un enfoque disciplinado de la transformacin de qu
es necesario para el desarrollo de un sistema, a cmo deber ser hecha la
implementacin. La definicin anterior implica que: el anlisis de
requerimientos del usuario (determinacin del qu) debe preceder al diseo y
que, al finalizar el diseo se tendr medios para la implementacin de las
necesidades del usuario (el cmo), pero no se tendr implementada la solucin
al problema. Cinco aspectos bsicos pueden ser reconocidos:
1. Permitir que la forma del problema gue a la forma de la solucin. Un
concepto bsico del diseo de arquitecturas es: las formas siempre siguen
funciones.
2. Intentar resolver la complejidad de los grandes sistemas a travs de la
segmentacin de un sistema en cajas negras, y su organizacin en una
jerarqua conveniente para la implementacin. 3. Utilizar herramientas,
especialmente grficas, para realizar diseos de fcil comprensin. Un diseo
estructurado usa diagramas de estructura (DE) en el diseo de la arquitectura
de mdulos del sistema y adiciona especificaciones de los mdulos y cumplas
(entradas y salidas de los mdulos), en un Diccionario de Datos (DD).
4. Ofrecer un conjunto de estrategias para derivar el diseo de la solucin,
basndose en los resultados del proceso de anlisis.
5. Ofrecer un conjunto de criterios para evaluar la calidad de un diseo con
respecto al problema a ser resuelto, y las posibles alternativas de solucin, en
la bsqueda de la mejor de ellas. El diseo estructurado produce sistemas
fciles de entender y mantener, confiables, fcilmente desarrollados, eficientes
y que funcionan.

2.1.1 CONCEPTOS BSICOS

Las diversas tecnologas y mtodos utilizados antiguamente para la
manipulacin y transmisin de comunicacin visual intencionada, han ido
35

modificando sucesivamente la actividad que hoy conocemos por diseo

grfico, hasta el extremo, de confundir el campo de actividades y
competencias que debera serle propio, incluyendo por supuesto, sus lejanas
fuentes originales.
El desarrollo de los productos y servicios ha crecido espectacularmente, lo que
les obliga a competir entre s para ocupar un sitio en el mercado. Es en este
momento cuando surge la publicidad, y con ella la evolucin del diseo grfico
como forma estratgica de comunicar, atraer y ganar la batalla frente a los
competidores.
El cmo se transmite una determinada informacin es un elemento
significativo trascendental para lograr persuadir, convencer, e incluso
manipular a gran parte de la sociedad.
El culto hacia los medios de comunicacin visual utilizados en la antigedad
(como mosaicos, pinturas, lienzos...) ha permitido sobrevivir a muchos de ellos
a la funcin temporal para la que fueron creados. Para estos objetos el medio
ha acabado por convertirse en obra de arte, es decir, en el autntico y
definitivo mensaje. La funcin del diseador es, transmitir una idea, un
concepto o una imagen de la forma ms eficaz posible.
Para ello, el diseador debe contar con una serie de herramientas como, la
informacin necesaria de lo que se va a transmitir, los elementos grficos
adecuados, su imaginacin y todo aquello que pueda servir para su
comunicacin. Nuestro diseo debe constituir un todo, donde cada uno de los
elementos grficos que utilicemos posean una funcin especfica, sin interferir
en importancia y protagonismo a los elementos restantes (a no ser quesea
intencionado).Un buen diseador debe comunicar las ideas y conceptos de una
forma clara y directa, por medio de los elementos grficos.
Por tanto, la eficacia de la comunicacin del mensaje visual que elabora el
diseador, depender de la eleccin de los elementos que utilice y del
conocimiento que tenga de ellos. Lo primero que hay que hacer para disear
algo ( un anuncio en revista, una tarjeta...), es saber que es lo que se quiere
transmitir al pblico y que tipo de pblico es ese, en definitiva, cual es la
misin que debe cumplir ese diseo. El dilema con el que se encuentra el
diseador es cmo elegir la mejor combinacin de los elementos y su ubicacin
(texto, fotografas, lneas, titulares...), con el propsito de conseguir comunicar
de la forma ms eficaz y atractiva posible. En esta parte empezaremos por
conocer los elementos bsicos del diseo, pero primero aclararemos un
trmino que facilitar nuestra comprensin del concepto que debemos tener
delos elementos.
La impresin o sensacin que causan dichos elementos, es decir la informacin
que transmiten .Los diseadores pueden manipular los elementos siempre que
tengan conocimiento de ellos y delo que en s representan, ya que en el mbito
del diseo es muy importante el factor psicolgico para conseguir el propsito
que se busca: Informar y Persuadir. Por tanto, hay que tener en cuenta lo que
puede llegar a expresar o transmitir, un color, una forma, un tamao, una
imagen o una disposicin determinada de los elementos que debemos incluir...,

36

ya que ello determinar nuestra comunicacin. En ambos casos, se consigue

por medio de la atraccin, motivacin o inters

2.1.2 DIAGRAMA DE FLUJO DE DATOS

Un diagrama de flujo de datos (DFD sus siglas en espaol e ingls) es una
representacin grfica del flujo de datos a travs de un sistema de informacin.
Un diagrama de flujo de datos tambin se puede utilizar para la visualizacin
de procesamiento de datos (diseo estructurado). Es una prctica comn para
un diseador dibujar un contexto a nivel de DFD que primero muestra la
interaccin entre el sistema y las entidades externas. Este contexto a nivel de
DFD se "explot"
Los diagramas de flujo de datos fueron inventados por Larry Constantine, el
desarrollador original del diseo estructurado, basado en el modelo de
computacin de Martin y Estrin: "flujo grfico de datos" . Los diagramas de flujo
de datos (DFD) son una de las tres perspectivas esenciales de Anlisis de
Sistemas Estructurados y Diseo por Mtodo SSADM. El patrocinador de un
proyecto y los usuarios finales tendrn que ser informados y consultados en
todas las etapas de una evolucin del sistema. Con un diagrama de flujo de
datos, los usuarios van a poder visualizar la forma en que el sistema funcione,
lo que el sistema va a lograr, y cmo el sistema se pondr en prctica. El
antiguo sistema de diagramas de flujo de datos puede ser elaborado y se
compar con el nuevo sistema de diagramas de flujo para establecer
diferencias y mejoras a aplicar para desarrollar un sistema ms eficiente. Los
diagramas de flujo de datos pueden ser usados para proporcionar al usuario
final una idea fsica de cmo resultarn los datos a ltima instancia, y cmo
tienen un efecto sobre la estructura de todo el sistema. La manera en que
cualquier sistema es desarrollado, puede determinarse a travs de un
diagrama de flujo de datos. modelo de datos.
niveles, los cuales son:

Nivel 0: Diagrama de contexto.

Nivel 1: Diagrama de nivel superior.

Nivel 2: Diagrama de detalle o expansin.

Caractersticas de los niveles

En el diagrama de contexto se caracterizan todas las interacciones que realiza
un sistema con su entorno (entidades externas), estas pueden ser otros
sistemas, sectores internos a la organizacin, o factores externos a la misma.
37

Se dibuja un slo proceso que representa al sistema en cuestin y se escribe su

nombre en dicha burbuja como un sustantivo comn ms adjetivos. De l
solamente parten los flujos de datos que denotan las interrelaciones entre el
sistema y sus agentes externos, no admitindose otros procesos ni
almacenamientos en el dibujo.
Resulta de gran utilidad para los niveles posteriores de anlisis como
herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos
DFD de Nivel "0"
Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen
al proceso principal. En este nivel los procesos no suelen interrelacionarse
directamente, sino que entre ellos debe existir algn almacenamiento o
entidad externa que los una. Esta regla de construccin sirve como ayuda al
analista para contemplar que en un nivel tan elevado de abstraccin (DFD
Nivel 1) es altamente probable que la informacin que se maneja requiera ser
almacenada en el sistema aunque no est especificado por un Requisito
funcional, siendo en realidad.
Diagrama de Detalle o Expansin: Nivel 2
En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a
los caminos principales de la informacin dado que aumenta progresivamente
el nivel de detalle. De aqu en adelante se permiten los flujos entre procesos. El
DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el mximo para
ser validado en forma conjunta con el usuario dado que en los niveles
posteriores el alto grado de complejidad del diagrama puede resultar de muy
difcil lectura para personas ajenas al equipo de sistemas. Tambin se
recomienda el diagrama de nivel superior.

2.1.3 APLICACIONES PARA SISTEMAS DE TIEMPO REAL

Los Sistemas Operativos de tiempo real son la plataforma para establecer
un sistema de tiempo real ya que en los SOTR no tiene importancia el usuario,
sino los procesos.
Algunos ejemplos de Sistemas Operativos de tiempo real son:
a.
VxWorks,
b.
c.
d.

Solaris,
Lyns OS
Spectra

Por lo regular Sistema Operativo de tiempo real suele tener la

misma arquitectura que un Sistema Operativo convencional, pero su diferencia
radica en que proporciona mayor prioridad a los elementos de control y
procesamiento que son utilizados para ejecutar los procesos o tareas.
38

a.

El SOTR debe ser multitarea y permisible

b.

Un SOTR debe poder asignar prioridades a las tareas

c.

El SOTR debe proporcionar medios de comunicacin y sincronizacin

entre tareas

d.

Un SOTR debe poder evitar el problema de inversin de prioridades

e.

El comportamiento temporal del SOTR debe ser conocido

Clasificacin de los sistemas de tiempo real

Los sistemas de tiempo real pueden ser de dos tipos, esto es en funcin de su
severidad en el tratamiento de los errores que puedan presentarse:
Sistemas de tiempo real blandos o Soft real-time systems: estos pueden tolerar
un exceso en el tiempo de respuesta, con una penalizacin por el
incumplimiento del plazo. Estos sistemas garantizan que las tareas crticas se
ejecutan en tiempo. Aqu los datos son almacenados en memorias no voltiles,
no utilizan tcnicas de memoria virtual ni tiempo compartido, estas tcnicas no
pueden ser implementadas en hardware.
Sistemas de tiempo real duros o Hard real-time systems: aqu la respuesta
fuera de trmino no tiene valor alguno, y produce la falla del sistema. Estos
sistemas tienen menos utilidades que los implementados por hard.

2.2 DIAGRAMAS DE ITERACIN DE OBJETOS

Diagramas de interaccin
Los diagramas de interaccin ilustran cmo interaccionan unos objetos con
otros, intercambiando mensajes.
39

Los diagramas de interaccin son importantes es aconsejable crearlos en

colaboracin con otros programadores. Elaborarlos implica asignar
responsabilidades a los objetos: sta no es una tarea fcil considerar patrones
de diseo puede ser til.
Estos son modelos que describen como los grupos de objetos que colaboran en
algunos ambientes. Por lo general, un diagrama de interaccin captura el
comportamiento de un nico caso de uso. Hay dos tipos de diagramas de
interaccin: diagramas de secuencia y diagramas de colaboracin.
Diagramas del UML
El UML est compuesto por diversos elementos grficos que se combinan para
conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas
para combinar tales elementos.
La finalidad de los diagramas es presentar diversas perspectivas de un
sistema, a las cuales se les conoce como modelo. Recordemos que un modelo
es una representacin simplificada de la realidad; el modelo UML describe lo
que supuestamente har un sistema, pero no dice cmo implementar dicho
sistema.

Diagramas ms comunes del UML

Diagrama de Clases
Los diagramas de clases describen la estructura esttica de un sistema.
Las cosas que existen y que nos rodean se agrupan naturalmente en
categoras. Una clase es una categora o grupo de cosas que tienen atributos
(propiedades) y acciones similares.
Un rectngulo es el smbolo que representa a la clase, y se divide en tres reas.
Un diagrama de clases est formado por varios rectngulos de este tipo
conectados por lneas que representan las asociaciones o maneras en que las
clases se relacionan entre s.
Nombre de Clase
atributo: Tipo /
atributo Derivado
operacin( )

Clase Abstracta
Las clases se representan con
rectngulos divididos en tres
40

reas: la superior contiene el nombre de la clase, la central

contiene los atributos y la inferior las acciones.
Asociaciones
Las asociaciones son las que representan a las relaciones estticas entre las
clases. El nombre de la asociacin va por sobre o por debajo de la lnea que la
representa. Una flecha rellena indica la direccin de la relacin. Los roles se
ubican cerca del final de una asociacin. Los roles representan la manera en
que dos clases se ven entre ellas. No es comn el colocar ambos nombres, el
de la asociacin y el de los roles a la vez. Cuando una asociacin es calificada,
el smbolo correspondiente se coloca al final de la asociacin, contra la clase
que hace de calificador.

Multiplicidad
Las notaciones utilizadas para sealar la multiplicidad se colocan cerca del final
de una asociacin. Estos smbolos indican el nmero de instancias de una clase
vinculadas a una de las instancias de la otra clase. Por ejemplo, una empresa
puede tener uno o ms empleados, pero cada empleado trabaja para una sola
empresa solamente.

No ms de uno

0...1 Cero o uno

*

Empresa
1

Muchos

0...* Cero o muchos

1...*Uno o muchos

1...*
Empleado

Asociacin Tripartita
Clase A

Clase B

Asociacin Tripartita

41
Clase A

Composicin y Agregacin
Composicin es un tipo especial de agregacin que denota una fuerte posesin
de la Clase Todo, a la Clase Parte. Se grafica con un rombo diamante
relleno contra la clase que representa el todo.
La agregacin es una relacin en la que la Clase Todo juega un rol ms
importante que la Clase "Parte", pero las dos clases no son dependientes una
de otra. Se grafica con un rombo diamante vaco contra la Clase Todo.

Generalizacin

Todo

Todo

Parte

Parte

Generalizacin es otro
nombre para herencia.
Se refiere a una relacin entre dos clases en donde una Clase Especfica es
una versin especializada de la otra, o Clase General. Por ejemplo, Honda es
un tipo de auto, por lo que la Clase Honda va a tener una relacin de
generalizacin con la Clase Auto

Clase
General

Clase
Especfica
Diagrama de Objetos
Los Diagramas de Objetos estn vinculados con los Diagramas de Clases. Un
objeto es una instancia de una clase, por lo que un diagrama de objetos puede
ser visto como una instancia de un diagrama de clases. Los diagramas de
42

objetos describen la estructura esttica de un sistema en un momento

particular y son usados para probar la precisin de los diagramas de clases.
Nombre de los objetos
Cada objeto es representado como un rectngulo, que contiene el nombre del
objeto y su clase subrayadas y separadas por dos puntos.
Nombre Objeto: Clase

Atributos
Como con las clases, los atributos se listan en un rea inferior. Sin embargo, los
atributos de los objetos deben tener un valor asignado
Nombre Objeto : Clase

Atributo
Atributo
Atributo
Atributo

tipo
tipo
tipo
tipo

=
=
=
=

Valor
Valor
Valor
Valor

Diagrama de Casos de Uso

Un caso de uso es una descripcin de las acciones de un sistema desde el

punto de vista del usuario. Es una herramienta valiosa dado que es una tcnica
de aciertos y errores para obtener los requerimientos del sistema, justamente
desde el punto de vista del usuario.
Los diagramas de caso de uso modelan la funcionalidad del sistema
usando actores y casos de uso. Los casos de uso son servicios o funciones
provistas por el sistema para sus usuarios.
Sistema
El rectngulo representa los lmites del sistema que contiene los casos de uso.
Los actores se ubican fuera de los lmites del sistema.

43

Casos de Uso
Se representan con valos. La etiqueta en el valo indica la funcin del
sistema.
Imprimi

Actores
Los actores son los usuarios de un sistema.

Relaciones
Las relaciones entre un actor y un caso de uso, se dibujan con una lnea simple.
Para relaciones entre casos de uso, se utilizan flechas etiquetadas "incluir" o
"extender." Una relacin "incluir" indica que un caso de uso es necesitado por
otro para poder cumplir una tarea. Una relacin "extender" indica opciones
alternativas para un cierto caso de uso.

<<
Caso de uso
<<Extender>>
Caso de uso

Caso de uso

Diagrama de Estados
En cualquier momento, un objeto se encuentra en un estado particular, la luz
est encendida o apagada, el auto en movimiento o detenido, la persona
44

leyendo o cantando, etc. El diagrama de estados UML captura esa pequea

realidad.
Estado
El estado representa situaciones durante la vida de un objeto. Se representa
con un rectngulo que tiene sus esquinas redondeadas.

Estado
Transicin
Una flecha representa el pasaje entre diferentes estados de un objeto. Se
etiqueta con el evento que lo provoca y con la accin resultante.
Evento / accin

Estado Inicial
Estado Final
Ejemplo de Diagrama de Estado

Acelera

Eleva

Desciende

Diagrama de Secuencias

Desacelera

Los diagramas de clases y los de objetos representan informacin esttica. No

obstante, en un sistema funcional, los objetos interactan entre s, y tales
interacciones suceden con el tiempo. El diagrama de secuencias UML muestra
la mecnica de la interaccin con base en tiempos.
Rol de la Clase
El rol de la clase describe la manera en que un objeto se va a comportar en el
contexto. No se listan los atributos del objeto.

45

Activacin
Los cuadros de activacin representan el tiempo que un objeto necesita para
completar una tarea.

Mensajes
Los mensajes son flechas que representan comunicaciones entre objetos. Las
medias flechas representan mensajes asincrnicos. Los mensajes asincrnicos

Son enviados desde un objeto que no va a esperar una respuesta del receptor
para continuar con sus tareas.
Lneas de Vida
Las lneas de vida son verticales y en lnea de puntos, ellas indican la presencia
del objeto durante el tiempo.

Lneas de Vida

46

Destruccin de Objetos
Los objetos pueden ser eliminados tempranamente usando una flecha
etiquetada "<<destruir>>" que apunta a una X.

Loops
Una repeticin o loop en un diagrama <<
de secuencias, es representado como un
rectngulo. La condicin para abandonar elDestruir
loop se coloca en la parte inferior
entre corchetes [ ].

Diagrama de Actividades
Un diagrama de actividades ilustra la naturaleza dinmica de un sistema
mediante el modelado del flujo ocurrente de actividad en actividad. Una
actividad representa una operacin en alguna clase del sistema y que resulta
en un cambio en el estado del sistema. Tpicamente, los diagramas de
actividad son utilizados para modelar el flujo de trabajo interno de una
operacin.
Estados de Accin
Los estados de accin representan las acciones no interrumpidas de los
objetos.
Actividad

Flujo de la Accin
j
Los flujos de accin, representados con flechas, ilustran las relaciones
entre los estados de accin.

Actividad

Actividad

[Condicin para
llir]
sa

Flujo de Objetos
El flujo de objetos se refiere a la creacin y modificacin de objetos por
parte de actividades. Una flecha de flujo de objeto, desde una accin a un
47

objeto, significa que la accin est creando o influyendo sobre dicho

objeto. Una flecha de flujo de objeto, desde un objeto a una accin, indica
que el estado de accin utiliza dicho objeto.
Actividad

Nombre Objeto : Clase

Estado Inicial
Estado inicial de un estado de accin.
Final State
Estado final de un estado de accin.

Ramificacin
Un rombo representa una decisin con camino.

Actividad

[ Condicin 1]
Actividad

Actividad

48

Sincronizacin

Una barra de sincronizacin ayuda a ilustrar la ocurrencia de transiciones

paralelas, as quedan representadas las acciones concurrentes.
Actividad

Actividad

Actividad

Actividad

Marcos de Responsabilidad
Los marcos de responsabilidad agrupan a las actividades relacionadas en una
misma columna.
.

Marco 1

Marco 2

Actividad

Objeto: Clase

Diagrama de Colaboraciones

Actividad

El diagrama de colaboraciones describe las interacciones entre los objetos en

trminos de mensajes secuenciados. Los diagramas de colaboracin
representan una combinacin de informacin tomada de los diagramas de
clases, de secuencias y de casos de uso, describiendo el comportamiento,
tanto de la estructura esttica, como de la estructura dinmica de un sistema.
Rol de la Clase
El rol de la clase describe cmo se comporta un objeto. Los atributos del objeto
no se listan.
49

Rol de las Asociaciones

Los roles de asociacin describen cmo se va a comportar una asociacin en
una situacin particular. Se usan lneas simple etiquetadas con un
estereotipo*.

Mensajes
Contrariamente a los diagramas de secuencias, los diagramas de colaboracin
no tienen una manera explcita para denotar el tiempo, por lo que entonces
numeran a los mensajes en orden de ejecucin. La numeracin puede
anidarse; por ejemplo, para mensajes anidados al mensaje nmero 1: 1.1, 1.2,
1.3, etc. La condicin para un mensaje se suele colocar entre corchetes. Para
indicar un loop se usa * despus de la numeracin.

Diagrama de Componentes
Un diagrama de componentes describe la organizacin de los componentes
fsicos de un sistema.
Componente
Un componente es un bloque de construccin fsica del sistema.
Componente

Interface
Una interface describe a un grupo de operaciones usada o creada por
componentes.

Dependencias

Componente

Las dependencias entre componentes se grafican usando flechas de puntos.

Componente

50
Componente

Dependencia

Diagrama de Distribucin
El diagrama de distribucin UML muestra la arquitectura fsica de un sistema
informtico. Puede representar a los equipos y a los dispositivos, y tambin
mostrar sus interconexiones y el software que se encontrar en cada mquina.
Nodo
Un nodo es un recurso fsico capaz de ejecutar componentes de cdigo.
(Procesador)

Asociacin
La asociacin se refiere a la conexin
fsica entre los nodos, como por ejemplo
Procesador
Ethernet.
Nombre

Nodo

Nodo

Componentes y Nodos
Nodo
Componente 1

2
AdaptacinComponente
del UML

Ahora que ha comprendido los diagramas del UML y su estructura, ya casi es

hora de ponerlo a funcionar. El UML es una herramienta maravillosa, pero no la
utilizar de manera aislada. El UML tiene la intencin de impulsar el desarrollo
de software, por ello, es necesario aprender los procesos y metodologas de
desarrollo como un vehculo para comprender el uso del UML en un contexto.
El mtodo antiguo Esta idea demasiado simplificada del proceso de desarrollo
podr darle una idea de que las etapas debern sucederse en lapsos

51

claramente definidos, una despus de otra. De hecho, las metodologas de

desarrollo iniciales se estructuraban de esa manera.

2.3 MODELO DE CLASES

2.3.1 CLASES
Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto
es una instancia de una clase). A travs de ella podemos modelar el entorno en
estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres
divisiones:

En donde:

Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que

caracterizan a la Clase (pueden ser private, protected o public).

Inferior: Contiene los mtodos u operaciones, los cuales son la forma

como interacta el objeto con su entorno (dependiendo de la visibilidad:
private, protected o public).

Ejemplo:
Una Cuenta Corriente que posee como caracterstica:

Balance

Puede realizar las operaciones de:

Depositar

Girar

y Balance

2.3.1.2 PROPIEDAD
Casos Particulares:

Clase Abstracta:
52

Una clase abstracta se denota con el nombre de la clase y de los mtodos con
letra "itlica". Esto indica que la clase definida no puede ser instanciada pues
posee mtodos abstractos (an no han sido definidos, es decir, sin
implementacin). La nica forma de utilizarla es definiendo subclases, que
implementan los mtodos abstractos definidos.

Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior

de la clase, en donde se especifican los parmetros que deben ser pasados a la
clase para que esta pueda ser instanciada. El ejemplo ms tpico es el caso de
un Diccionario en donde una llave o palabra tiene asociado un significado, pero
en este caso las llaves y elementos pueden ser genricos. La genericidad
puede venir dada de un Template (como en el caso de C++) o bien de alguna
estructura predefinida (especializacin a travs de clases).

2.3.3 INTERACCIN
Relaciones entre Clases:
Ahora ya definido el concepto de Clase, es necesario explicar como se pueden
interrelacionar dos o ms clases (cada uno con caractersticas y objetivos
diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML,
la cardinalidad de las relaciones indica el grado y nivel de dependencia, se
anotan en cada extremo de la relacin y stas pueden ser:

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n)

53

i.

nmero fijo: m (m denota el nmero).

Herencia (Especializacin/Generalizacin):

Indica que una subclase hereda los mtodos y atributos especificados por una
Super Clase, por ende la Subclase adems de poseer sus propios mtodos y
atributos, poseer las caractersticas y atributos visibles de la Super Clase
(public y protected), ejemplo:

En la figura se especifica que Auto y Camin heredan de Vehculo, es decir,

Auto posee las Caractersticas de Vehculo (Precio, VelMax, etc.) adems posee
algo particular que es Descapotable, en cambio Camin tambin hereda las
caractersticas de Vehculo (Precio, VelMax, etc.) pero posee como
particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo
Caracteristicas aplicable a instancias de Vehculo, Auto y Camin, pues tiene
definicin pblica, en cambio atributos como Descapotable no son visibles por
ser privados.
Agregacin:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que
proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se
requiere componer objetos que son instancias de clases definidas por el
desarrollador de la aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del
objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este
tipo de relacin es comnmente llamada Composicin (el Objeto base se
construye a partir del objeto incluido, es decir, es "parte/todo").

54

Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida

del objeto incluido es independiente del que lo incluye. Este tipo de relacin es
comnmente llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).
Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee
las referencias).
Cuando se destruye el Objeto Almacn tambin son destruidos los objetos
Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
La composicin (por Valor) se destaca por un rombo relleno.
La agregacin (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relacin indica la navegabilidad del objeto
referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.
Asociacin:
La relacin entre clases conocida como Asociacin, permite asociar objetos que
colaboran entre s. Cabe destacar que no es una relacin fuerte, es decir, el
tiempo de vida de un objeto no depende del otro.
Ejemplo:

Un cliente puede tener asociadas muchas rdenes de Compra, en cambio una

orden de compra solo puede tener asociado un cliente.
Dependencia o Instanciacin (uso):
Representa un tipo de relacin muy particular, en la que una clase es
instanciada (su instanciacin es dependiente de otro objeto/clase). Se denota
por una flecha punteada.
55

2.3.2 CARACTERSTICAS
Herencia.
La herencia define la relacin entre clases es un, donde una subclase hereda
de una o ms superclases.
La herencia implica una jerarqua de generalizacin/especializacin, en la que
una subclase especializa el comportamiento y/o la estructura, ms general, de
sus superclases.
Herencia simple.
La herencia simple se da cuando, en una jerarqua de clases, las subclases
solamente pueden heredar de una superclase.
Herencia mltiple.
A diferencia de la herencia simple, en la herencia mltiple las subclases
pueden heredar de ms de una superclase.
Polimorfismo.
La palabra polimorfismo tiene como origen las palabras griegas poli (muchos) y
moros (formas) y se utiliza para indicar que un nombre puede denotar
instancias (objetos) de clases diferentes que estn relacionadas por alguna
superclase comn.
El polimorfismo puede considerarse como la caracterstica ms potente de los
lenguajes orientados a objetos, despus de su capacidad para soportar la
abstraccin.
Existe polimorfismo cuando interactan las caractersticas de herencia y enlace
dinmico.
Enlace esttico y enlace dinmico
El enlace esttico (denominado tambin enlace temprano) consiste en la
asignacin esttica de tipos a todas las variables y expresiones, en tiempo de
compilacin.
El enlace dinmico (denominado tambin enlace tardo) consiste en asignar, en
tiempo de ejecucin, los tipos a las variables y expresiones.

2.3.1.3 ESTRUCTURAS JERRQUICAS

Segn el Diccionario of OT la jerarqua es cualquier clasificacin u ordenacin
de abstracciones en una estructura de rbol. Algunos tipos de Jerarqua son:
Jerarqua de agregacin, jerarqua de clases, jerarqua de herencia, jerarqua de
particin, jerarqua de especializacin, jerarqua de tipo. ste concepto es
sumamente importante ya que con ello conocemos la importancia de dividir los
problemas en una jerarqua de ideas.
Como se muestra en el ejemplo cada figura tiene su nivel de jerarqua a
continuacin se explicar ms detalladamente cada nivel. La clase es la que
contiene las caractersticas comunes a dichas figuras concretas por tanto, no
56

tiene forma ni tiene rea. Esto lo expresamos declarando como una clase
abstracta, declarando la funcin miembro rea abstract.
LAS CLASES ABSTRACTAS
Solamente se pueden usar como clases base para otras clases. No se pueden
crear objetos pertenecientes a una clase abstracta. Sin embargo, se pueden
declarar variables de dichas clases. La caracterstica de hacer una
Clase/Mtodo abstract reside en que no puede ser generada una instancia de la
misma, este comportamiento se demuestra en el mtodo principal (main).
Como se muestra en las figuras cada clase tiene diferentes niveles, por decirlo
as, de importancia de ah se desprenden los trminos de Superclase y
Subclases.
SUPERCLASE Y SUBCLASE
La clase Padre o Superclase se llama de ese modo debido a que de la misma
se desprenden otras clases llamadas Subclases las cuales heredarn sus
atributos y operaciones, una Superclase puede contener cualquier nmero de
Subclases.
CIRCULO
La Clase Circulo es una de las Subclases de la Superclase Figura, sta a su vez
puede convertirse en una Superclase si de ella se desprenden otras clases. La
misma posee su nivel de importancia y a su vez hereda los mtodos y atributos
dela superclase.
En ste segundo ejemplo podemos ver que al contrario del anterior del
anterior, que de una subclase pueden desprenderse otras subclases lo que
convierte a sta Subclase en una Superclase:
A es la superclase de B, C y D.
D es la superclase de E.
B, C y D son subclases de A.
E es una subclase de D. Una de las caractersticas que no se pueden apreciar
en stas figuras es que cada Subclase obtiene hereda, caractersticas de su
Clase Padre de aqu proviene el trmino de herencia que detallar a
continuacin.
HERENCIA
Es una propiedad esencial de la Programacin Orientada a Objetos que
consiste en la creacin de nuevas clases a partir de otras ya existentes stas
nuevas clases obtienen propiedades de sus clases padres, las cuales propagan
sus atributos y operaciones a sus subclases. Las Subclases admiten la
definicin de nuevos atributos, as como crear, modificar o inhabilitar
propiedades.
57

La herencia ofrece una ventaja importante, ya que permite la reutilizacin del

cdigo. Hay dos tipos de herencia las cuales son:
Herencia Simple y Herencia Mltiple
. La primera indica que se pueden definir nuevas clases solamente a partir de
una clase inicial mientras que la segunda indica que se pueden definir nuevas
clases a partir de dos o ms clases iniciales. Java slo permite herencia simple.
En la herencia los constructores no son heredados. El termino Herencia ha sido
tomado prestado de la Biologa donde por ejemplo afirmamos que un nio
tiene la cara de su padre, que ha heredado ciertas facetas fsicas o del
comportamiento de sus progenitores. Entre otras palabras son las diferentes
caractersticas que comparten unas clases con las otras.

2.3.4 Subsistemas
Objetos.
Los objetos, concretos y abstractos, estn a nuestro alrededor, forman nuestro
entorno. Podemos distinguir cada objeto en base a sus caractersticas y
comportamientos.
Por ejemplo, en el aula observamos los objetos:

alumno
profesor
mesa
silla
mesabanco
pizarrn
58

Abstraccin.
La abstraccin es una de las principales herramientas con que combatimos la
complejidad.
Una abstraccin denota las caractersticas esenciales de un objeto y
proporciona lmites conceptuales definidos respecto a la perspectiva del
observador.
En el modelo de objetos se persigue construir abstracciones que imiten
directamente el vocabulario de un determinado dominio de problema, por lo
que el problema central del diseo orientado a objetos es tomar la decisin
acerca del conjunto adecuado de abstracciones para ese dominio.
Comportamiento.
Los objetos no solamente poseen atributos, sino que tambin exhiben
comportamientos que manifiestan al interactuar con otros objetos en un
esquema cliente/servidor, donde un cliente es cualquier objeto que utiliza los
recursos de otro objeto denominado servidor.
Encapsulamiento.
El encapsulamiento es el proceso de almacenar en un mismo compartimento
los elementos de una abstraccin que constituyen su estructura y su
comportamiento; sirve para separar la interfaz contractual de una abstraccin
y su implementacin.
El encapsulamiento se consigue, a menudo, mediante la ocultacin de
informacin. Generalmente, la estructura de un objeto est oculta, as como la
implementacin de sus mtodos.
Modularidad.
La modularidad es la descomposicin de un sistema en un conjunto de
mdulos cohesivos y dbilmente acoplados.
La descomposicin de un sistema en componentes individuales ayuda a
manejar la complejidad. Sin embargo, una descomposicin desordenada puede
producir un efecto contrario que se puede contrarrestar reagrupando los
componentes en mdulos o paquetes. Cada mdulo debe contener
componentes con caractersticas afines, de tal manera que faciliten la
produccin de la arquitectura fsica de un sistema.

59

2.4 DIAGRAMAS DE IMPLEMENTACIN

2.4.1 DEFINICIN
Los diagramas de implementacin muestran las instancias existentes al
ejecutarse as como sus relaciones. Tambin se representan los nodos que
identifican recursos fsicos, tpicamente un ordenador as como interfaces y
objetos (instancias de las clases).

2.4.2 OBJETIVO

Muestran los aspectos de implementacin del modelo

Estructura del cdigo fuente y objeto

Estructura de la implementacin en ejecucin

2.4.3 TIPOS
Dos tipos de diagramas

2.4.3.1 DIAGRAMA DE COMPONENTES

Organizacin y dependencias entre los componentes software
Clases de implementacin
Artifactos binarios, ejecutables, ficheros de scripts

2.4.3.2 DIAGRAMA DE EJECUCIN

Configuracin de los elementos de proceso en tiempo de ejecucin y los
componentes software, procesos y objetos que viven en ellos
Distribucin de componentes

2.4.4 APLICACIONES
Visual Studio 2008
Los diagramas de implementacin evalan la implementacin de un sistema de
aplicaciones en un centro de datos lgico concreto. Existen dos maneras de
crear diagramas de implementacin. La primera es desde el Diseador de
aplicaciones, sin definir con anterioridad un sistema explcito. Los Diseadores
de sistemas distribuidos crean un sistema predeterminado mediante las
definiciones de aplicacin del diagrama de aplicaciones porque siempre se
requiere que un sistema describa una implementacin del sistema. La segunda
opcin es crearlo desde un sistema definido en el Diseador de sistemas.
Para crear un diagrama de implementacin desde el Diseador de aplicaciones
1.
En el Diseador de aplicaciones, elija Definir implementacin en el men
Diagrama.

60

Aparecer el cuadro de dilogo Definir implementacin. Se rellena

automticamente con el nombre de un diagrama de centros de datos lgicos, si
aparece uno en la solucin.
2.
Bajo Diagrama de centros de datos lgicos, elija un diagrama en la
solucin o haga clic en Examinar para buscar un diagrama (archivo .ldd) fuera
de la solucin.
3.

Haga clic en Aceptar.

Se abre el diagrama de implementacin en el Diseador de implementacin.

2.4.5 ADAPTACIONES DE UML

Existen dos tipos de metodologas: antiguas y recientes. Se entiende por
metodologa a la estructura y naturaleza de los pasos en un esfuerzo de
desarrollo. Pero antes de iniciar a programar los desarrolladores deben tener
claridad sobre el problema.
Mtodo antiguo
Las etapas deben suceder en lapsos definidos, una despus de otra. Obsrvese
el mtodo en cascada:
Este mtodo reduce el impacto de la comprensin obtenida en el proyecto. Si
el proceso no puede retroceder y volver a ver los primeros estados, es posible
que las ideas desarrolladas no sean utilizadas.
Mtodo reciente
Tiende a la colaboracin entre las fases de desarrollo esta moderna ingeniera
de programas, los analistas y diseadores hacen revisiones para desarrollar un
slido fundamento para los desarrolladores. Existe interaccin entre todo el
equipo de trabajo.
La ventaja es que conforme crece la comprensin, el equipo incorpora nuevas
ideas y genera un sistema ms confiable.
Lo que debe hacer un proceso de desarrollo
El equipo tiene que formarse de analistas para comunicarse con el cliente y
comprender el problema, diseadores para generar una solucin,
programadores para codificarla e ingenieros de sistemas para distribuirlas.
A su vez debe asegurar que sus fases no sean discontinuas.
GRAPPLE
Significa Guas para la Ingeniera de Aplicaciones Rpidas, tiene dentro de s
una condensacin de ideas de varias otras personas.
Consta de cinco segmentos en lugar de fases, cada segmento consta de
diversas acciones cada accin es responsabilidad de un jugador.
61

Los segmentos son: recopilacin, anlisis, diseo, desarrollo y distribucin. Lo

que otorga un acrnimo RADDD.
Recopilacin de necesidades
La funcin es comprender lo que desea el cliente.
Realice un anlisis del dominio
El objetivo es comprender de la mejor manera posible el dominio del cliente. El
analista debe acomodarse al cliente.
Descubra las necesidades del sistema
El equipo realiza su primera sesin de JAD(Desarrollo de conjunto de
aplicaciones).En dnde se rene a quienes toman las decisiones en la empresa
del cliente, a los usuarios potenciales y a los miembros de los equipos de
desarrollo.
Presentar los resultados al cliente
Cuando finaliza todas las acciones de Necesidades, el administrador de
proyectos presentar los resultados al cliente.
Anlisis
En este segmento aumenta la comprensin por parte del equipo. Se necesita
trabajar sobre: la comprensin del uso del sistema, hacer realidad de los casos
de uso, depurar los diagramas de clases, analizar cambios de estado en los
objetos, definir la comunicacin entre objetos, analizar la integracin con
diagramas de colaboraciones.
Diseo
El equipo trabajar con los resultados del segmento de Anlisis para disear la
solucin, en este punto se harn revisiones pertinentes hasta que el diseo se
haya completado. Contiene las siguientes fases: desarrollo y depuracin de
diagramas de componentes, desarrollo de diagramas de componentes,
planeacin para la distribucin, diseo y prototipos de la interfaz del usuario,
pruebas de diseo, iniciar la documentacin.
Desarrollo
De este segmento se encargan los programadores, debe realizarse con rapidez
y sin problemas.
Fases: generacin del cdigo, verificacin del cdigo, generacin de interfaces
del usuario y conexin con el cdigo, prueba, consumacin de la
documentacin.
Distribucin

62

En este segmento se distribuye en el hardware adecuado y se integra con los

sistemas cooperativos.
Fases: planeacin para copias de seguridad y recuperacin, instalacin del
sistema terminado en el hardware adecuado, verificacin del sistema instalado,
celebracin.

63

2.5 DISEO DE INTERFAZ DE USUARIO

El diseo de interfaz de usuario o ingeniera de la interfaz es el diseo
de computadoras, aplicaciones, mquinas, dispositivos de comunicacin mvil,
aplicaciones de software, y sitios web enfocado en la experiencia de usuario y
la interaccin.
Normalmente es una actividad multidisciplinar que involucra a varias ramas es
decir al diseo y el conocimiento como el diseo grfico, industrial, web, de
software y la ergonoma; y est implicado en un amplio rango de proyectos,
desde sistemas para computadoras, vehculos hasta aviones comerciales.
Su objetivo es que las aplicaciones o los objetos sean ms atractivos y adems,
hacer que la interaccin con el usuario sea lo ms intuitiva posible, conocido
como el diseo centrado en el usuario. En este sentido las disciplinas del
diseo industrial y grfico se encargan de que la actividad a desarrollar se
comunique y aprenda lo ms rpidamente, a travs de recursos como la
grfica, los pictogramas, los estereotipos y la simbologa, todo sin afectar el
funcionamiento tcnico eficiente.

2.5.1 INTERACCION HOMBRE MAQUINA

Todava no hay una definicin concreta para el conjunto de conceptos que
forman el rea de la interaccin persona-computador. En trminos generales,
podramos decir que es la disciplina que estudia el intercambio de
informacin mediante software entre las personas y las computadoras. Esta se
encarga del diseo, evaluacin e implementacin de los aparatos tecnolgicos
interactivos, estudiando el mayor nmero de casos que les pueda llegar a
afectar. El objetivo es que el intercambio sea ms eficiente: minimizar errores,
incrementar la satisfaccin, disminuir la frustracin y, en definitiva, hacer ms
productivas las tareas que rodean a las personas y los computadores.
Aunque la investigacin en este campo es muy complicada, la recompensa una
vez conseguido el objetivo de bsqueda es muy gratificante. Es muy
importante disear sistemas que sean efectivos, eficientes, sencillos y amenos
a la hora de utilizarlos, dado que la sociedad disfrutar de estos avances. La
dificultad viene dada por una serie de restricciones y por el hecho de que en
ocasiones se tienen que hacer algunos sacrificios. La recompensa sera: la
creacin de libreras digitales donde los estudiantes pueden encontrar
manuscritos medievales virtuales de hace centenares de aos; los utensilios
utilizados en el campo de la medicina, como uno que permita a un equipo de
cirujanos conceptualizar, alojar y monitorizar una compleja operacin
neurolgica; los mundos virtuales para el entretenimiento y la interaccin
social, servicios del gobierno eficientes y receptivos, que podran ir desde
renovar licencias en lnea hasta el anlisis de un testigo parlamentario; o bien
telfonos inteligentes que saben donde estn y cuentan con la capacidad de

64

entender ciertas frases en un idioma. Los diseadores crean una interaccin

con mundos virtuales integrndolos con el mundo fsico.

2.5.2 DISEO DE INTERFAZ HOMBRE MAQUINA

La sigla HMI es la abreviacin en ingles de Interfaz Hombre Maquina. Los
sistemas HMI podemos pensarlos como una ventana de un proceso. Esta
ventana puede estar en dispositivos especiales como paneles de operador o en
computadora. Los sistemas HMI en computadoras se les conoce tambin como
software HMI o de monitoreo y control de supervisin. Las seales del proceso
son conocidas al HMI por medio de dispositivos como tarjetas de entrada /
salida en la computadoras, PLCs (controladores lgicos programables), RTU
(unidades remotas I/O) o DRIVEs (variadores de velocidad de motores). Todos
estos dispositivos deben tener una comunicacin que entienda el HMI.

2.5.3 DIRECTRICES PARA EL DISEO DE INTERFACES

No forzar al usuario a leer grandes cantidades de texto, ya que la

lectura en un monitor de un computador es, aproximadamente, un
25% ms lenta que la lectura en papel.

Evitar los llamados iconos under construction, pues causan

expectacin y pueden decepcionar al usuario si el resultado final no
es el esperado.

La informacin importante debe colocarse dentro de las dimensiones

tpicas de la ventana del navegador, ya que los usuarios prefieren no
desplazarse sobre la ventana.

Los mens de navegacin y las barras de cabecera de las pginas

Web deben ser consistentes y aparecer en todas las pginas que se le
muestrean al usuario.

La esttica nunca debe sustituir a la funcionalidad.

2.5.4 ESTANDARES DE INTERFAZ

Muchas aplicaciones web obvian algunos de los principios de los que
hablaremos, y dichos principios no cambian aunque sea una aplicacin web,
todo lo contrario, respetarlos puede llegar a ser an ms importante y
necesario.
Las interfaces grficas efectivas son visualmente comprensibles y permiten
errores por parte del usuario, dndole una sensacin de control. Los usuarios
ven rpidamente el alcance de las opciones y comprenden como obtener sus
metas y realizar su trabajo.
Dichas interfaces ocultan al usuario el funcionamiento interno del sistema. El
trabajo se va guardando constantemente brindando una opcin de deshacer en
todo momento cualquier accin que se haya hecho. Las aplicaciones y servicios

65

efectivos realizan el mximo trabajo requiriendo la mnima informacin del

usuario.
Anticiparse.
Una buena aplicacin intentar anticiparse a las necesidades y deseos de los
usuarios. No esperes que el usuario busque o recuerde informacin o
herramientas. Muestra al usuario toda la informacin y herramientas
necesarias para cada etapa en su trabajo.
Autonoma.
El ordenador, la interfaz y el entorno de la tarea pertenecen al usuario, pero no
podemos abandonarlo.
Ante una interface, al usuario hay que darle cuerda para que investigue y
sienta que tiene el control del sistema. No obstante, hay que tener en cuenta
que los adultos nos sentimos ms cmodos en un entorno que no sea ni muy
restrictivo, ni demasiado grande, un entorno explorable pero no peligroso.
Mantn informado al usuario del estado del sistema.
No existe autonoma en ausencia de control; y el control no se puede tener sin
informacin suficiente. Comunicar el estado es fundamental para que el
usuario responda apropiadamente con la informacin disponible.
Ejemplo: los trabajadores sin informacin del estado del sistema, tienden a
mantenerse bajo presin durante cortos periodos de tiempo hasta que el
trabajo se termina. Un estrs y fatiga innecesarios por lo que cuando venga la
siguiente carga de trabajo, puede que los trabajadores no estn en las mejores
condiciones fsicas y mentales.
Los usuarios no tienen que buscar la informacin de estado. De un vistazo
deberan ser capaces de hacerse una idea aproximada del estado del sistema.
La informacin de estado pude ser bastante sutil: el icono de la bandeja de
entrada puede mostrarse vaca, media llena o hasta los topes, por ejemplo. Sin
embargo, no es conveniente abusar: En Mac se utiliz durante aos un icono
de la papelera que pareca que iba a estallar en cualquier momento, aunque
slo tuviese un documento. Los usuarios adquirieron la costumbre de vaciar la
papelera apenas contuviese un documento, convirtieron un proceso de un paso
en uno de dos (primero llevamos el documento a la papelera, luego lo
vaciamos). Esto tuvo el efecto negativo de reducir una de las funciones bsicas
de la papelera: la posibilidad de deshacer la accin.

66

2.6 DISEO DE LA BASE DE DATOS

Son muchas las consideraciones a tomar en cuenta al momento de hacer el
diseo de la base de datos, quizs las ms fuertes sean:

La velocidad de acceso.

El tamao de la informacin.

El tipo de la informacin.

Facilidad de acceso a la informacin.

Facilidad para extraer la informacin requerida.

El comportamiento del manejador de bases de datos con cada tipo de

informacin.

No obstante que pueden desarrollarse sistemas de procesamiento de archivo e

incluso manejadores de bases de datos basndose en la experiencia del equipo
de desarrollo de software logrando resultados altamente aceptables, siempre
es recomendable la utilizacin de determinados estndares de diseo que
garantizan el nivel de eficiencia ms alto en lo que se refiere a
almacenamiento y recuperacin de la informacin.
De igual manera se obtiene modelos que optimizan el aprovechamiento
secundario y la sencillez y flexibilidad en las consultas que pueden
proporcionarse al usuario.
El proceso de diseo de una base de datos se gua por algunos principios. El
primero de ellos es que se debe evitar la informacin duplicada o, lo que es lo
mismo, los datos redundantes, porque malgastan el espacio y aumentan la
probabilidad de que se produzcan errores e incoherencias. El segundo principio
es que es importante que la informacin sea correcta y completa. Si la base de
datos contiene informacin incorrecta, los informes que recogen informacin de
la base de datos contendrn tambin informacin incorrecta y, por tanto, las
decisiones que tome a partir de esos informes estarn mal fundamentadas.

2.6.1 OBJETIVOS
Un buen diseo de base de datos es, por tanto, aqul que:
Divide la informacin en tablas basadas en temas para reducir los datos
redundantes.
Proporciona a Access la informacin necesaria para reunir la informacin de las
tablas cuando as se precise.
Ayuda a garantizar la exactitud e integridad de la informacin.
67

Satisface las necesidades de procesamiento de los datos y de generacin de

informes.

El proceso de diseo consta de los pasos siguientes:

Determinar la finalidad de la base de datos:

Esto le ayudar a estar preparado para los dems pasos.
Buscar y organizar la informacin necesaria:
Rena todos los tipos de informacin que desee registrar en la base de datos,
como los nombres de productos o los nmeros de pedidos.
Dividir la informacin en tablas:
Divida los elementos de informacin en entidades o temas principales, como
Productos o Pedidos. Cada tema pasar a ser una tabla.
Convertir los elementos de informacin en columnas:
Decida qu informacin desea almacenar en cada tabla. Cada elemento se
convertir en un campo y se mostrar como una columna en la tabla. Por
ejemplo, una tabla Empleados podra incluir campos como Apellido y Fecha de
contratacin.

Especificar claves principales:

Elija la clave principal de cada tabla. La clave principal es una columna que se
utiliza para identificar inequvocamente cada fila, como Id. de producto o Id. de
pedido.

Definir relaciones entre las tablas:

Examine cada tabla y decida cmo se relacionan los datos de una tabla con las
dems tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar
las relaciones segn sea necesario.

Ajustar el diseo:
Analice el diseo para detectar errores. Cree las tablas y agregue algunos
registros con datos de ejemplo. Compruebe si puede obtener los resultados
previstos de las tablas. Realice los ajustes necesarios en el diseo.

68

Aplicar las reglas de normalizacin:

Aplique reglas de normalizacin de los datos para comprobar si las tablas estn
estructuradas correctamente. Realice los ajustes necesarios en las tablas.

2.6.2 ALMACEN DE DATOS

Los Almacenes de Datos son repositorios diseador para facilitar la confeccin
de los informes y la realizacin de anlisis; tal como ocurre con las bases de
datos, pueden ser completamente separados del sistema de informacin
principal; lo cual significa una ganancia enorme en el rendimiento de los
sistemas cuando se ejecuten las consultas.

El Procesamiento de Transacciones Online, usado normalmente por

aplicaciones orientadas a la transaccin como pueda ser vtiger CRM, no han
sido construidas teniendo en cuenta la creacin de bases de datos segregadas,
y los potenciales anlisis que puedan realizarse se hacen sobre los mismos
datos usados por la aplicacin, y tampoco han sido diseadas para situaciones
donde la cantidad de datos a ser analizados es considerable.

Modelo de Datos usado en OLTP (OnlineTransaction Processing).

69

Los Almacenes de datos (Datawarehouses) usados en OLAP (Analytical

Processing) utilizan un modelo de datos denominado multidimensional.

La topologa tpica usada para construir un almacn de datos se denomina

"modelo en forma de estrella": La tabla central se llama "tabla de hechos" y
referencia un nmero de "dimensiones" (que son las tablas que estn
alrededor). Usando este mtodo es posible producir informes que incluyan
informacin tal como, por ejemplo, la cantidad de procesador producidos en el
segundo cuatrimestre del 2006. Por esta razn se construyen (hiper)cubos, y
mediante este modelo de datos desde diferentes dimensiones (potencialmente
todas variables) pueden ser enlazadas todas juntas.

Modelo en forma de estrella usado en OLAP

Cubo OLAP con Tiempo, Cliente y Producto como dimensiones.

70

Finalmente indicar que los almacenes de datos crean versiones de la

informacin con el objeto de conservar "informacin histrica" en un intento de
dar coherencia a los informes a lo largo del tiempo. Por ejemplo, si el nombre
de una cuenta (cliente) cambia, el sistema BI crear una nueva versin
marcada con un nueva marca de tiempo de forma que las entidades que
existan antes del cambio sigan estando relacionadas con la misma cuenta
mientras que las nuevas entidades que se vayan a crear a partir de ahora se
relacionen con la nueva versin.

Para este proyecto vtiger CRM - BI hemos construido un almacn de datos

capaz de almacenar toda la informacin contenida dentro de un vtiger CRM en
produccin. Todas las entidades del sistema son almacenadas como tablas de
dimensiones y versionadas segn una serie de decisiones tomadas durante el
anlisis realizado. Por ejemplo, la cuenta ha sido versionada cada vez que la
ciudad, pas, provincia, cdigo postal, direccin, miembro de, correo y el campo
"asignado a" sean modificados.
Hemos creado las siguientes tablas de hechos:

Ventas (que pueden ser estudiadas por Factura o Lneas de factura)

Incidencias post-venta (HelpDesk)

Campaas

Potentiales

Tarifas

En la tabla de hechos de Ventas hemos aadido clculos especficos para

obtener informacin importante sobre beneficios y rentabilidades:

Cantidad: nmero de unidades en cada lnea

Precio unitario: precio de cada unidad en la lnea

Beneficio bruto por lnea

Descuento en lnea de venda por promociones. Aunque esto pueda ser

reflejado en vtiger CRM con las tarifas, no podemos saber si se ha
aplicado una tarifa en una lnea determinada ya que vtiger CRM no
guarda esta informacin (siempre ser cero).

Detalle de descuento por lnea

Margen neto por lnea

Coste interno de la lnea para la empresa.

Beneficio total de la venta.

71

Impuestos aplicados.

Una vez creado el almacn de datos, necesitamos crear los procesos ETL
(Extract-Transform-Load) que peridicamente extraern la informacin desde el
vtiger CRM en produccin y cargarn con ella el Almacn de Datos, para ser
usado por las diversas herramientas de confeccin de informes (reporting) y
anlisis disponibles. El procedimiento esencial se muestra en la imagen
siguiente:

Como puede verse, el almacn de datos refleja la lgica del negocio y debe ser
construida para adaptarse perfectamente a esta lgica. As pues, ser
necesario realizar cuantas adaptaciones sean necesarias, al almacn y al resto
de procesos, para conseguir esto y por consiguiente el mximo beneficio y
aprovechamiento de la herramienta BI.

72

2.7 MTRICAS DEL DISEO

Como ya se ha visto por las distintas mtricas estudiadas, la complejidad de un
programa crece con su tamao: los programas largos son ms difciles de
escribir y comprender, contienen habitualmente ms errores, y su
depuracin resulta ms compleja. Con objeto de reducir esta complejidad, los
diseadores de software han hecho un uso progresivo de tcnicas de
modularizacin y diseo estructurado. Entre las diversas ventajas de las
tcnicas de diseo se pueden destacar las siguientes:

Comprensibilidad: programadores
fcilmente la lgica del programa.

y usuarios pueden comprender

Manejabilidad: los gestores pueden asignar fcilmente personal

y recursos a los distintos mdulos representados por tareas.

Eficiencia: el esfuerzo de implementacin puede reducirse.

Reduccin de errores: los planes de prueba se simplifican notablemente.

Reduccin del esfuerzo de mantenimiento: la divisin en mdulos

favorece
que las distintas funciones las lleven a cabo mdulos
diferenciados.
Aunque estos beneficios tambin son discutidos y para ello se alega toda clase
de inconvenientes, en general se admite que el paso a la modularidad es un
gran salto adelante. Pero el problema que se plantea ahora se refiere a los
mdulos en si: Cul es el tamao idneo, la complejidad mxima, la extensin
adecuada de un mdulo?
Algunas de las mtricas vistas hasta el momento tratan este problema. As
algunos autores estiman que el tamao de un mdulo debe oscilar entre las
50-200 lneas de cdigo. Otros simplemente indican que un mdulo debe
completar una funcin por s solo. La complejidad lmite de un mdulo se fija en
algunos casos en un nmero de complejidad ciclomtica igual a 10.
Otras discusiones se centran en la organizacin de los mdulos en el
programa: estructuras en rbol, o lineales. Con objeto de obtener una
valoracin de los mdulos y una disposicin que pueda emplearse como base
para comparaciones, surgen las mtricas orientadas al diseo.
Muchas de estas mtricas son generalizaciones de otras referidas a mbitos
ms restringidos (nmeros de complejidad ciclomtica, mtricas de la ciencia
del software,...)
Uno de los estudios ms completos relativos a la cuestin de valorar los
mdulos software es el llevado a cabo por Troy y Zweben en el que se relaciona
una serie de mtricas bsicas con valores de calidad representados por la tasa
de modificaciones en pruebas.
73

En este estudio, un gran sistema fue dividido en mdulos usando varias

convenciones de diseo. Cada mdulo se codific, prob y prepar para
la integracin. Se registraron los cambios realizados en cada mdulo. Cada
implementacin de diseo se acompa de un grfico que representaba las
interconexiones entre los mdulos. En total se obtuvieron veintiuna mtricas
asociadas a cada grfico.
Los principios que dirigen estas mtricas son:

Acoplamiento: Se mide como el nmero de interconexiones entre

mdulos. El acoplamiento crece con el nmero de llamadas, o con la cantidad
de datos compartidos. Se supone que un diseo con un
acoplamiento alto puede contener ms errores. Se cuantifica como el
nmero de conexiones por nodo del grfico de diseo.

Cohesin: Valora las relaciones entre los elementos de un mdulo. En un

diseo cohesivo, las funciones estn ubicadas en un solo mdulo. Los
diseos con una cohesin baja contendrn ms errores. Las medidas que
valoren
la informacin compartida entre mdulos cuantificarn la
cohesin.

Complejidad: Un diseo debe ser lo ms simple posible. La complejidad

crece con el nmero de construcciones de control, y el nmero de
mdulos de un programa. Un diseo complejo contendr ms errores. La
complejidad se evidencia en el nmero de elementos del grfico de diseo.

Modularidad: El grado de modularidad afecta a la calidad del diseo. Es

preferible un exceso a un defecto de modularidad, pues en este ltimo caso
contendr ms errores. La cuantificacin de la modularidad se obtiene
midiendo la cantidad de elementos del grfico.

Tamao: Un diseo con grandes mdulos, o gran profundidad en su

grfico contendr ms errores. De hecho, complejidad y tamao estn muy
relacionados y las consecuencias de un exceso de cualquiera de los dos
principios tienen los mismos resultados.
Las conclusiones finales del estudio sugieren que a pesar de la correlacin
encontrada entre los factores estudiados y los errores encontrados, sigue
habiendo una serie de factores no detectados que determinan a su vez la
calidad de un diseo. De todas formas es posible afirmar que las
interconexiones entre mdulos, y la complejidad de los diseos aumentan
notablemente los errores, y disminuyen la calidad.
Otras mtricas del software.
Adems de las mencionadas, existen algunas otras mtricas que valoran
ciertos aspectos del software.
Las mtricas de reusabilidad tratan de medir el grado en que un elemento
software puede ser empleado por otros programas, en otras palabras, su
74

independencia. Debido a que es difcil valorar objetivamente esta

independencia, la referencia ms comn es la independencia del hardware
expresada en nmero de cambios en el cdigo al adaptar un programa a una
nueva plataforma. Esta medida puede ampliarse al nmero de cambios
realizados en el cdigo por lneas al adaptarlo a un nuevo sistema operativo,
o a un nuevo sistema grfico. Las mtricas de portabilidad valoran aspectos
muy similares.
Las mtricas de mantenibilidad se enuncian como funcin de los valores de
concisin, consistencia, instrumentacin, modularidad, auto documentacin
y simplicidad.
Las mtricas de testeabilidad (o capacidad de probar el software) son
funcin de la auditabilidad (capacidad de someter el software a
auditora), la complejidad de software (ciclomtica, contando los GOTO y
bucles, o segn los valores de la Ciencia del Software), instrumentacin,
modularidad, autodocumentacin y simplicidad.
Las de flexibilidad tienen como componentes a la complejidad, la
concisin, la consistencia, la expandibilidad, la generalidad, la
autodocumentacin, y la simplicidad.
La interpretacin que se da de los componentes de cada una de estas
mtricas es, no obstante, discutible e imprecisa, sin un mtodo definido
para obtener una valoracin. Tambin se carece de expresiones que
determinen el peso que cada componente tiene en la mtrica.

2.7.1 FACTORES QUE AFECTAN

McCall y Cavano [John A. McDermid 91 definieron un juego de factores de
calidad como los primeros pasos hacia el desarrollo de mtricas de la calidad
del software. Estos factores evalan el software desde tres puntos de vista
distintos:
(1) Operacin del producto (utilizndolo),
(2) revisin del producto (cambindolo) y
(3) transicin del producto (modificndolo para que funcione en un entorno
diferente, por ejemplo: portndolo) Los autores describen la relacin entre
estos factores de calidad (lo que llaman un marco de trabajo) y otros aspectos
del proceso de ingeniera del software:
En primer lugar el marco de trabajo proporciona al administrador identificar en
el proyecto lo que considera importante, como: facilidad de mantenimiento y
transportabilidad, atributos del software, adems de su correccin y
rendimiento funcional teniendo un impacto significativo en el costo del ciclo de
vida. En segundo lugar, proporciona un medio de evaluar cuantitativamente el
progreso en el desarrollo de software teniendo relacin con los objetivos de
calidad establecidos. En tercer lugar, proporciona ms interaccin del personal
de calidad, en el esfuerzo de desarrollo. Por ltimo, el personal de calidad
75

puede utilizar indicaciones de calidad que se establecieron como pobres para

ayudar a identificar estndares mejores para verificar en el futuro. Es
importante destacar que casi todos los aspectos del clculo han sufrido
cambios radicales con el paso de los aos desde que McCall y Cavano hicieron
su trabajo, teniendo gran influencia, en 1978. Pero los atributos que
proporcionan una indicacin de la calidad del software siguen siendo los
mismos. Si una 63 organizacin de software adopta un juego de factores de
calidad como una lista de comprobacin para evaluar la calidad del software,
es probable que el software construido hoy siga exhibiendo la buena calidad
dentro de las primeras dcadas del siglo XXI. Incluso, cuando las arquitecturas
del clculo sufran cambios radicales (como seguramente ocurrir), el software
que exhibe alta calidad en operacin, transicin y revisin continuar sirviendo
a sus usuarios.

2.7.2 PRODUCTIVIDAD
En el terreno de las metodologas de desarrollo de software, se aprecia una
necesaria mejora en la puesta en prctica de dichas metodologas de
desarrollo, as como la flexibilizacin de stas para potenciar la productividad
de las mismas sin renunciar a la calidad de los mismos.
Por esta razn se hace cada vez ms necesario disponer de herramientas
efectivas para aumentar la productividad, no solo desde un punto de vista
terico sino especialmente en la puesta en prctica de dichas metodologas,
consiguiendo que su despliegue impacte positivamente en el negocio de la
empresa.
La mejora de la efectividad y la productividad en el desarrollo de software est
ligada a la utilizacin de buenas prcticas de Ingeniera de Software. En la
actualidad es indiscutible que el uso de una metodologa apropiada es un
factor clave para el xito de cualquier esfuerzo de ingeniera y tambin debera
ser-lo en la ingeniera del software. La ingeniera de software, por su relativa
juventud como disciplina y por la altsima variabilidad de los productos que
gestiona, pocas organizaciones que desarrollen software utilizan metodologas
de forma sistemtica, aunque esta tendencia est cambiando da a da.
La Ingeniera de Procesos contribuye en esta lnea, diseando y construyendo
metodologas en funcin de las necesidades especficas de cada organizacin.
De este modo, de la misma forma que las metodologas deben responder a
multiplicidad de estndares, tambin deben adaptarse a las caractersticas
particulares de cada uno de los proyectos que se llevan a cabo en la
organizacin. La complejidad del proceso hace imprescindible que una gran
parte de las actividades del desarrollo de software se automatice.
Los modelos y las metodologas basadas en modelos son la herramienta para
abstraer de los detalles irrelevantes en un determinado contexto y poder
razonar sobre el sistema a construir. Los modelos estn demostrando ser una
herramienta de productividad, acercando los modelos a los expertos del
76

dominio de aplicacin. Este enfoque permite separar los modelos que

describen la solucin al problema en trminos de negocio, de los modelos que
describen la implementacin en trminos de la plataforma software. Esta
arquitectura de solucin separa los aspectos del negocio de la tecnologa de
implementacin facilitando que ambos evolucionen independientemente uno
de otro y posibilitando verdaderas factoras de software estructuradas por
dominio de aplicacin y por tecnologa de implementacin.

2.7.3 MEDIDAS RELACIONADAS

Aunque hay muchas medidas de la calidad de software, la correccin, facilidad
de mantenimiento, integridad y facilidad de uso suministran indicadores tiles
para el equipo del proyecto. Gilb [Len O. Ejiogo 90] sugiere definiciones y
medidas para cada uno de ellos, tales como:
Correccin: A un programa le corresponde operar correctamente o suministrar
poco valor a sus usuarios. La correccin es el grado en el que el software lleva
a cabo una funcin requerida. La medida ms comn de correccin son los
defectos por KLDC, en donde un defecto se define como una falla verificada de
conformidad con los requisitos. Facilidad de mantenimiento. El mantenimiento
del software cuenta con ms esfuerzo que cualquier otra actividad de
ingeniera del software. La facilidad de mantenimiento es la habilidad con la
que se puede corregir un programa si se encuentra un error, se puede adaptar
si su entorno cambia o optimizar si el cliente desea un cambio de requisitos. No
hay forma de medir directamente la facilidad de 64mantenimiento; por
consiguiente, se deben utilizar medidas indirectas. Una mtrica orientada al
tiempo simple es el tiempo medio de cambio (TMC), es decir, el tiempo que se
tarda en analizar la peticin de cambio, en disear una modificacin apropiada,
en efectuar el cambio, en probarlo y en distribuir el cambio a todos los
usuarios. En promedio, los programas que son ms fciles de mantener
tendrn un TMC ms bajo (para tipos equivalentes de cambios) que los
programas que son ms difciles de mantener. Hitachi ha empleado una
mtrica orientada al costo (precio) para la
capacidad de mantenimiento, llamada desperdicios. El costo estar en
corregir
defectos hallados despus de haber distribuido el software a sus usuarios
finales.
Cuando la proporcin de desperdicios en el costo global del proyecto se
simboliza como una funcin del tiempo, es aqu donde el administrador logra
determinar si la facilidad de mantenimiento del software producido por una
organizacin de desarrollo est mejorando y asimismo se pueden emprender
acciones a partir de las conclusiones obtenidas de esa informacin. Integridad
En esta poca de intrusos informticos y de virus, la integridad del software ha
llegado a tener mucha importancia. Este atributo mide la habilidad de un
sistema para soportar ataques (tanto accidentales como intencionados) contra
77

su seguridad. El ataque se puede ejecutar en cualquiera de los tres

componentes
del software, ya sea en los programas, datos o documentos. Para medir la
integridad, se tienen que definir dos atributos adicionales: amenaza y
seguridad. La amenaza es la probabilidad (que se logra evaluar o concluir de
la evidencia emprica) de que un ataque de un tipo establecido ocurra en un
tiempo establecido. La seguridad es la probabilidad (que se puede estimar o
65 deducir de la evidencia emprica) de que se pueda repeler el ataque de un
tipo establecido, en donde la integridad del sistema se puede especificar
como:
integridad = [1- amenaza x (1- seguridad donde se suman la amenaza y la
seguridad para cada tipo de ataque.
Facilidad de uso. El calificativo amigable con el usuario se ha transformado
universalmente en disputas sobre productos de software. Si un programa no es
amigable con el usuario, prcticamente est prximo al fracaso, incluso
aunque las funciones que realice sean valiosas. La facilidad de uso es un
intento de cuantificar lo amigable que pude ser con el usuario y se consigue
medir en funcin de cuatro caractersticas:

(1) destreza intelectual y/o fsica solicitada para aprender el sistema;

(2) el tiempo requerido para alcanzar a ser moderadamente eficiente en el uso
del sistema;
(3) aumento neto en productividad (sobre el enfoque que el sistema
reemplaza) medida cuando alguien emplea el sistema moderadamente y
eficientemente, y (4) valoracin subjetiva (a veces obtenida mediante un
cuestionario) de la disposicin de los usuarios hacia el sistema.
Los cuatro factores anteriores son slo un ejemplo de todos los que se han
propuesto como medidas de la calidad del software.
Medidas de fiabilidad y de disponibilidad. Los trabajos iniciales sobre fiabilidad
buscaron extrapolar las matemticas de la teora de fiabilidad del hardware a la
prediccin de la fiabilidad del software. La mayora de los modelos de fiabilidad
relativos al hardware van ms orientados a los fallos debidos al desajuste, que
a los fallos debidos a defectos de diseo, ya que son ms probables debido al
desgaste fsico (p. ej.: el efecto de la temperatura, del deterioro, y los golpes)
que los fallos relativos al diseo. Desgraciadamente, para el software lo que
ocurre es lo contrario. De hecho, todos los fallos del software, se producen por
problemas de diseo o de implementacin. Considerando un sistema basado
en computadora, una medida sencilla de la fiabilidad es el tiempo medio entre
fallos (TMEF) [Mayrhauser91], donde:
TMEF = TMDF+TMDR (4.2)
78

(TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparacin)).

Muchos investigadores argumentan que el TMDF es con mucho, una medida
ms til que los defectos/KLDC, simplemente porque el usuario final se
enfrenta a los fallos, no al nmero total de errores. Como cada error de un
programa no tiene la misma tasa de fallo, la cuenta total de errores no es una
buena indicacin de la fiabilidad de un sistema. Por ejemplo, consideremos un
programa que ha estado funcionando durante 14 meses. Muchos de los errores
del programa pueden pasar desapercibidos durante dcadas antes de que se
67 detecten. El TMEF de esos errores puede ser de 50 e incluso de 100 aos.
Otros errores, aunque no se hayan descubierto an, pueden tener una tasa de
fallo de 18 24 meses, incluso aunque se eliminen todos los errores de la
primera categora (los que tienen un gran TMEF), el impacto sobre la fiabilidad
del software ser muy escaso.
Adems de una medida de la fiabilidad debemos obtener una medida de la
disponibilidad. La disponibilidad (4.1.3.2) del software es la probabilidad de que
un programa funcione de acuerdo con los requisitos en un momento dado, y se
define como:
Disponibilidad = TMDF/(TMDF + TMDR) x 100 % (4.3)
La medida de fiabilidad TMEF es igualmente sensible al TMDF que al TMDR. La
medida de disponibilidad es algo ms sensible al TMDR ya que es una medida
indirecta de la facilidad de mantenimiento del software.

2.7.3.1 TAMAO
El proceso a seguir para realizar desarrollo orientado a objetos es complejo,
debido a la complejidad que nos vamos a encontrar al intentar desarrollar
cualquier sistema software de tamao medio-alto. El proceso est formado por
una serie de actividades y subactividades, cuya realizacin se va repitiendo en
el tiempo aplicado a distintos elementos.
En este apartado se va a presentar una visin general para poder tener una
idea del proceso a alto nivel, y ms adelante se vern los pasos que componen
cada fase.
Las tres fases al nivel ms alto son las siguientes:
Planificacin y Especificacin de Requisitos: Planificacin, definicin de
requisitos, construccin de prototipos, etc. 26 IV.1 Proceso de Desarrollo
Desarrollo Orientado a Objetos con UML Xavier Ferr Grau, Mara Isabel
Snchez Segura
Construccin: La construccin del sistema. Las fases dentro de esta etapa son
las siguientes:

79

- Anlisis: Se analiza el problema a resolver desde la perspectiva de los

usuarios y de las entidades externas que van a solicitar servicios al sistema.
- Diseo: El sistema se especifica en detalle, describiendo cmo va a funcionar
internamente para satisfacer lo especificado en el anlisis.
- Implementacin: Se lleva lo especificado en el diseo a un lenguaje de
programacin.
- Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el
software
funciona correctamente y que satisface lo especificado en la etapa de
Planificacin y
Especificacin de Requisitos.
Instalacin: La puesta en marcha del sistema en el entorno previsto de uso.
De ellas, la fase de Construir es la que va a consumir la mayor parte del
esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va
adoptar un enfoque iterativo, tomando en cada iteracin un subconjunto de los
requisitos (agrupados segn casos de uso) y llevndolo a travs del anlisis y
diseo hasta la implementacin y pruebas, tal y como se muestra en la
El sistema va creciendo incrementalmente en cada ciclo.
Con esta aproximacin se consigue disminuir el grado de complejidad que se
trata en cada ciclo, y se tiene pronto en el proceso una parte del sistema
funcionando que se puede contrastar con el usuario/cliente.

2.7.3.2 FUNCION
Hewlett-Packard ha desarrollado un conjunto de factores de calidad de software
al que se le ha dado el acrnimo de FURPS:
- Funcionalidad. Se aprecia evaluando el conjunto de caractersticas y
capacidades del programa, la generalidad de las funciones entregadas y la
seguridad del sistema global.
- Usabilidad (facilidad de empleo o uso) Se valora considerando factores
humanos, la esttica, consistencia y documentacin general.
- Fiabilidad. Se evala midiendo la frecuencia y gravedad de los fallos, la
exactitud de las salidas (resultados), el tiempo medio entre fallos (TMEF), la
capacidad de recuperacin de un fallo y la capacidad de prediccin del
programa.
- Rendimiento. Se mide por la velocidad de procesamiento, el tiempo de
respuesta, consumo de recursos, rendimiento efectivo total y eficacia. 75

80

- Capacidad de soporte. Combina la capacidad de ampliar el programa

(extensibilidad), adaptabilidad y servicios (los tres representan
mantenimiento), as como capacidad de hacer pruebas, compatibilidad,
capacidad de configuracin, la facilidad de instalacin de un sistema y la
facilidad con que se pueden localizar los problema

2.7.3.3 PUNTOS DE OBJETO

Para conocer Puntos funcin, No ajustados y factor de complejidad.
Es necesario detectar ciertos parmetros:
-Entradas externas: Se cuenta cada entrada de usuario que proporciona
diferentes datos orientados a la aplicacin. Las entradas se deberan
diferenciar de las peticiones, las cuales se cuentan de forma separada.
-Salidas externas: Se cuenta cada salida que proporciona al usuario
informacin
orientada a la aplicacin. En este contexto la salida se refiere a informes,
pantallas, mensajes de error, etc. Los elementos de datos particulares dentro
de un informe no se cuentan de forma separada.
-Archivos lgicos. Se cuenta cada archivo maestro lgico (esto es, un grupo
lgico de datos que puede ser una parte de una gran base de datos o un
archivo
independiente).
-Archivos externos de interface. Una peticin se define como una entrada
interactiva que produce la generacin de alguna respuesta del software
inmediata en forma de salida interactiva. Se cuenta cada peticin por
separado.
-Consultas externas. Se cuentan todas las interfaces legibles por la mquina
(por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir
informacin a otro sistema.

2.7.4 METRICAS DE DISEO ARQUITECTONICO

El diseo de ms alto nivel tambin es llamado: diseo general, arquitectnico
o conceptual. Tambin es una actividad de modelaje.
El objetivo del diseador: es producir un modelo o representacin del software
que se continuara ms adelante. El diseo del software es la primera de tres
(3) actividades tcnicas:
1) Diseo
2) Codificacin.
3) Prueba.

81

Diseo de Datos. Transforma el modelo del campo de informacin, creado

durante el anlisis, en las estructuras de datos que se van a requerir para
implementar el software.
Diseo Arquitectnico: Define las relaciones entre los principales elementos
estructurales del programa.
Diseo Procedimental: Transforma los elementos estructurales en una
descripcin procedimental del software. Se genera el cdigo fuente y para
integrar y validar el software, se llevan a cabo las pruebas.
Alcance del Diseo del Software:
1) Diseo de la arquitectura del sistema: Este es el proceso durante el cual se
produce una especificacin completa y verificada del hardware en general
2) Diseo detallado del software: Este ocurre cuando se producen
especificaciones verificadas de estructuras de datos.
La eleccin de un mecanismo de persistencia adecuado:1)El tipo de sistema de
base de datos a utilizar.
2) La forma en que la aplicacin se comunicar con el mismo.
3) La distribucin de la lgica: qu parte resolver la aplicacin y qu otra se
delegar a mecanismos propios del sistema elegido las bases de datos de
objetos (OODBMS). Como su nombre lo indica, la forma en la que stas
organizan y almacenan la informacin se acerca bastante a la manera en que
se trabaja con objetos y referencias en las aplicaciones orientada a objeto las
bases relacionales (RDBMS) han demostrado poseer caractersticas: 1)
Constituyen una aproximacin robusta y flexible para el manejo de los datos.
2) Se encuentran soportadas por una teora capaz de, entre otras cosas,
asegurar la integridad de la informacin.
3) Estn sustentadas por estndares
Ciertas cuestiones se delegan al motor:
1) Almacenamiento, organizacin y recuperacin de informacin estructurada.
2) Concurrencia e integridad de datos.
3) Administracin de los datos compartidos.
La arquitectura de software de un sistema de programa o computacin es la
estructura de las estructuras del sistema, la cual comprende los componentes
del software, las propiedades de esos componentes visibles externamente, y
las relaciones entre ellos.
La arquitectura Mas bien, es la representacin que capacita al ingeniero del
software para:
82

1-Analizar la efectividad del diseo para la consecucin de los requisitos

fijados.
2-Considerar las alternativas arquitectnicas en una etapa en la cual hacer
cambios en el diseo es relativamente fcil, y
3-Reducir los riesgos asociados a la construccin del software.
Porque es importante la arquitectura La arquitectura destaca decisiones
tempranas de diseo que tendrn un profundo impacto en todo el trabajo de
ingeniera del software que sigue
Sistemas basados en las arquitecturas de flujo de datos: Esta familia de estilos
enfatiza la reutilizacin y la modificabilidad. Es apropiada para sistemas que
implementan transformaciones de datos en pasos sucesivos. Histricamente l
se relaciona con las redes de proceso descriptas por Kahn hacia 1974 y con el
proceso secuenciales comunicantes (CSP) ideados por Tony Hoare cuatro aos
ms tarde.
Sistemas basados en arquitecturas de llamada y retorno (capas): Esta familia
de estilos enfatiza la modificabilidad y la escalabilidad. Son los estilos ms
generalizados en sistemas en gran escala. Existen dos subestilos dentro de
esta categora:
1-Arquitecturas de programa principal.
2-Arquitecturas de llamada de procedimiento remoto.
las concepciones formuladas por el patriarca Edsger Dijkstra en la dcada de
1960,
Sistemas basados en arquitectura heterognea: Es la familia ms fuertemente
referida en los ltimos tiempos, se incluyen en este grupo formas compuestas
o indciles a la clasificacin en las categoras habituales. Es por cierto
objetable y poco elegante que existan clases residuales de este tipo en una
taxonoma, pero ninguna clasificacin conocida ha podido resolver este dilema
conceptual
1-Sistemas de control de procesos: los sistemas de control de procesos se
caracterizan no slo por los tipos de componentes, sino por las relaciones que
mantienen entre ellos
2-Arquitecturas Basadas en Atributos: La arquitectura basada en atributos o
ABAS fue propuesta por Klein y Klazman. La intencin de estos autores es
asociar a la definicin del estilo arquitectnico un framework de razonamiento
basado en modelos de atributos especficos.
La arquitectura Cliente servidor el remitente de una solicitud es conocido
como cliente. Sus caractersticas son:
1-Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la
comunicacin
83

2-Espera y recibe las respuestas del servidor.

3-Por lo general, puede conectarse a varios servidores a la vez.
El diseo de un sistema de software se representa a travs de dos fases:
1-El diseo lgico: un diseo lgico escriben las especificaciones detalladas del
nuevo sistema, esto es, describen sus caractersticas como son: las salidas,
entradas, archivos, bases de datos y procedimientos; todas de manera que
cubran los requerimientos del proyecto.
2-El diseo fsico: El diseo fsico, actividad que sigue al diseo lgico, produce
programas de software, archivos y un sistema en marcha, las especificaciones
del diseo indican a los programadores qu debe hacer el sistema.
Diseo fsico deben delinearse las caractersticas de cada uno de los
componentes que se enumeran a continuacin:
1-Diseo de hardware: debe especificarse todo el equipo de cmputo, lo que
incluye todo dispositivo de entrada, procedimientos y salidas con sus
caractersticas de rendimiento
2- Diseo de software: deben especificarse las caractersticas de todo el
software
3-Diseo de base de datos: es necesario detallar el tipo estructura y funciones
de las base de datos, las relaciones de los elementos de datos establecidos en
el diseo lgico y fsico

2.7.5 METRICAS DE NIVEL DE COMPONENTES

Las mtricas de diseo a nivel de componentes se concentran en las
caractersticas internas de los componentes del software e incluyen medidas
de la cohesin, acoplamiento y complejidad del mdulo. Estas tres medidas
pueden 88 ayudar al desarrollador de software a juzgar la calidad de un diseo
a nivel de componentes. Las mtricas presentadas son de caja blanca en el
sentido de que requieren conocimiento del trabajo interno del mdulo en
cuestin. Las mtricas de diseo en los componentes se pueden aplicar una
vez que se ha desarrollado un diseo procedimental. Tambin se pueden
retrasar hasta tener disponible el cdigo fuente.

2.7.6 METRICAS DE DISEO DE INTERFAZ

Aunque existe una significativa cantidad de literatura sobre el diseo de
interfaces hombre-mquina, se ha publicado relativamente poca informacin
sobre mtricas que proporcionen una visin interna de la calidad y facilidad de
empleo de la interfaz.

84

Sears [Pressman 98] sugiere la conveniencia de la representacin (CR) como

una valiosa mtrica de diseo para interfaces hombre-mquina. Una IGU
(Interfaz Grfica de Usuario) tpica usa entidades de representacin, iconos
grficos, texto, mens, ventanas y otras para ayudar al usuario a completar
tareas. Para realizar una tarea dada usando una IGU, el usuario debe moverse
de una entidad de representacin a otra. Las posiciones absolutas y relativas
de cada entidad de representacin, la frecuencia con que se utilizan y el
costo de la transicin de una entidad de representacin a la siguiente
contribuir a la
conveniencia de la interfaz. Para una representacin especfica (p. ej.: un
diseo de una IGU especfica), se pueden asignar costos a cada secuencia de
acciones de acuerdo con la siguiente relacin:
Costos = [frecuencia de transicin (ki) x costos de transicin (ki)] (4.30)

donde k es la transicin i especfica de una entidad de representacin a la

siguiente cuando se realiza una tarea especfica. Esta suma se da con todas las
transiciones de una tarea en particular o conjunto de tareas requeridas para
conseguir alguna funcin de la aplicacin. El costo puede estar caracterizado
en trminos de tiempo, retraso del proceso o cualquier otro valor razonable, tal
como la distancia que debe moverse el ratn entre entidades de la
representacin.
La conveniencia de la representacin se define como:
CR = 100 x [(costo de la representacin ptima CR)/
(costo de la representacin propuesta)] .
(4.31) 95 donde CR = para una representacin ptima. Para calcular la
representacin ptima de una IGU, la superficie de la interfaz (el rea de la
pantalla) se divide en una cuadrcula. Cada cuadro de la cuadrcula representa
una posible posicin de una entidad de la representacin. Para una cuadrcula
con N posibles posiciones y K diferentes entidades de representacin para
colocar, el nmero posible de distribuciones se representa de la siguiente
manera [Pressman 98]:
Nmero posible de distribuciones = [N !/
(K! * (N - K)!] * K!
(4.32)
La CR se emplea para valorar diferentes distribuciones propuestas de IGU y la
sensibilidad de una representacin en particular a los cambios en las
descripciones de tareas (por ejemplo, cambios en la secuencia y/o frecuencia
de transiciones) Es importante apuntar que la seleccin de un diseo de IGU
85

puede guiarse con mtricas tales como CR, pero el rbitro final debera ser la
respuesta del usuario basada en prototipos de IGU.

86

3. IMPLEMENTACIN
3.1 ELABORACION DE UN PROGRAMA DE
IMPLEMENTACIN
3.1.1 OBJETIVO
Una implementacin es la realizacin de una aplicacin, instalacin o la
ejecucin de un plan, idea, modelo cientfico, diseo, especificacin, estndar,
algoritmo o poltica.
En ciencias de la computacin, una implementacin es la realizacin de una
especificacin tcnica o algoritmos como un programa, componente software,
u otro sistema de cmputo. Muchas implementaciones son dadas segn a una
especificacin o un estndar.
Por ejemplo, un navegador web respeta (o debe respetar) en su
implementacin, las especificaciones recomendadas segn el World Wide Web
Consortium, y las herramientas de desarrollo del software contienen
implementaciones de lenguajes de programacin.

87

3.2 DESARROLLO DE SOFTWARE BASADO EN

PROCESOS GILES
3.2.1 DEFINICIN DE PROCESOS GILES
El desarrollo gil de software son mtodos de ingeniera del software basado en
el desarrollo iterativo e incremental, donde los requerimientos y soluciones
evolucionan mediante la colaboracin de grupos autos organizados y
multidisciplinarios.
Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos
desarrollando software en lapsos cortos. El software desarrollado en una unidad
de tiempo es llamado una iteracin, la cual debe durar de una a cuatro
semanas.

3.2.2 MODELOS DE PROCESOS GILES

Lean software development

La metodologa de desarrollo de software Lean es una translacin de los
principios y prcticas de la manufactura esbelta hacia el dominio del
desarrollo de software. Adaptado del Sistema de produccin Toyota,
apoyado por una sub-cultura pro-lean que est surgiendo desde la
comunidad gil.

Programacin extrema
La programacin extrema o eXtreme Programming (XP) es una
metodologa de desarrollo de la ingeniera de software formulada por Kent
Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el ms destacado de los procesos
giles de desarrollo de software. Al igual que stos, la programacin
extrema se diferencia de las metodologas tradicionales principalmente en

que pone ms nfasis en la adaptabilidad que en la previsibilidad.

Mtodo de desarrollo de sistemas dinmicos
El mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic
Systems Development Method o DSDM) es un mtodo que provee un
88

framework para el desarrollo gil de software, apoyado por su continua

implicacin del usuario en un desarrollo iterativo y creciente que sea
sensible a los requerimientos cambiantes, para desarrollar un sistema que
reuna las necesidades de la empresa en tiempo y presupuesto. Es uno de
un nmero de mtodos de desarrollo gil de software y forma parte de la
alianza gil.

89

UNID
AD 3.
IMPLE
MENT
ACIN

90

3.3 REUTILIZACIN DEL SOFTWARE

La reutilizacin de software es el proceso de implementar o actualizar sistemas
de software utilizando activos del mismo. Aunque al principio podra pensarse
que un activo de software es simplemente otro trmino para cdigo fuente,
ste no es el caso. Los activos de software o componentes incluyen todos los
productos derivados del mismo, desde requerimientos y propuestas,
especificaciones y diseos a manuales y juegos de prueba. Cualquier cosa que
sea producto de un esfuerzo de desarrollo de software potencialmente puede
ser reutilizada.

3.3.1 USOS DE REUTILIZACIN

Hay muchas metodologas para poner en prctica la reutilizacin de software.
Desde la reutilizacin de cdigo ad hoc, a prcticas de reutilizacin repetible,
donde la reutilizacin es dentro de un proyecto o en mltiples proyectos.
stos pueden ser resumidos dentro de dos categoras generales:
Prcticas de reutilizacin con desarrollo

La reutilizacin de software es ms comnmente referida dentro del

contexto de reutilizacin durante el desarrollo. Hay muchos enfoques
hacia la reutilizacin de software durante el desarrollo.
Tecnologas orientadas a objetos: Un concepto clave en las tecnologas
de objetos es la idea de objeto. Los objetos caracterizan el dominio del
problema, cada uno teniendo atributos y comportamientos especficos.
Los objetos son manipulados con una coleccin de funciones y se
comunican unas con otras utilizando un protocolo de mensajes, y estn
organizados dentro de clases y subclases.

Desarrollo con reutilizacin, reutilizacin oportunista.

En una organizacin de desarrollo que practica reutilizacin oportunista,

sta es ad hoc, cuando la oportunidad para reutilizacin se presenta por
s misma, es explotada. Por ejemplo, si una organizacin estuviera
construyendo un sistema, y encuentra que durante el diseo o
desarrollo, se podra ahorrar tiempo debido a que uno de sus
subsistemas puede heredar las propiedades de otro, entonces esa
organizacin est practicando reutilizacin oportunista.

Desarrollo con reutilizacin: reutilizacin sistemtica.

La reutilizacin sistemtica est enfocada al dominio. Se basa en un

proceso repetible, y de manera primaria relacionada con la reutilizacin
de los artefactos del ciclo de vida de ms alto nivel, tales como:
requerimientos, diseos y subsistemas. La idea detrs de la reutilizacin
sistemtica de software es que la reutilizacin no debera ser ad hoc,
91

sino debera ser implementada dentro de la organizacin como parte del

desarrollo de procesos.
Prcticas de reutilizacin sin desarrollo con reutilizacin del software.

Hay otras clases de reutilizacin en relacin con el desarrollo de

software. Uno de estos tipos es la reutilizacin del producto, la que se
refiere a la reutilizacin de un sistema entero. Esencialmente, en vez de
construir un sistema especfico para un slo cliente, se construye un
sistema ms general que puede ser utilizado por muchos clientes. El
ejemplo ms obvio de reutilizacin de producto son los sistemas
operativos para PC de escritorio en el mundo, tales como los productos
Windows de Microsoft.

3.3.2 PATRONES DE DISEO

Un patrn de diseo es bsicamente una solucin (un diseo) que surge de la
experimentacin prctica con varios proyectos, y los equipos de desarrollo han
encontrado que se puede aplicar en diversos contextos. Cada patrn de diseo
describe a un conjunto de objetos y clases comunicadas. El conjunto se ajusta
para resolver un problema de diseo en un contexto especfico.
Se dividen en tres categoras: 1) Patrones de creacin que ataen al proceso de
creacin de objetos, 2) Patrones de estructura que se orientan a la composicin
de clases y objetos, y 3) Patrones de comportamiento que especifican la forma
en que las clases u objetos interactan y distribuyen la responsabilidad.

3.3.3 BASADA EN GENERADORES

El conocimiento reutilizable se captura en un sistema generador de programas
que puede ser programado por expertos en el dominio utilizando un lenguaje
orientado a dominios o una herramienta CASE interactiva que soporte la
generacin de sistemas. La descripcin de la aplicacin especfica, de forma
abstracta, qu componentes reutilizables tienen que usarse y cmo tienen que
ser combinados y parametrizados. Utilizando esta informacin se puede
generar un sistema software operativo.

Generadores de analizadores para el procesamiento del

lenguaje. La entrada del generador es una gramtica que describe el
lenguaje que va a ser analizado, y la salida es el analizador del lenguaje.
Esta aproximacin se incluye en sistemas tales como lex y yace para C y
Java CC, un compilador de Java.

Generadores de cdigo en herramientas CASE. La entrada de estos

generadores es un diseo software y la salida es un programa que
implementa el sistema diseado. Pueden basarse en modelos UML y,
dependiendo de la informacin en los modelos UML, generar un
programa completo o componente, o bien un esqueleto de cdigo. El
desarrollador del software a continuacin aade detalles para completar
el cdigo.
92

3.3.4 MARCOS DE TRABAJO

Un marco de trabajo (o marco de trabajo de aplicaciones) es un diseo de un
subsistema formado por una coleccin de clases concretas y abstractas y la
interfaz entre ellas (Wir Brock y Johnson, 1990). Los detalles particulares del
subsistema de aplicacin son implementados aadiendo componentes y
proporcionando implementaciones concretas de las clases abstractas en el
marco de trabajo. Los marcos de trabajo raramente son aplicados por s
mismos. Las aplicaciones se construyen normalmente integrando varios
marcos trabajo.

Marcos de trabajo de infraestructura de sistemas. Estos marcos de

trabajo soportan desarrollo de infraestructuras de sistemas tales como
comunicaciones, interfaces de usuario y compiladores (Schmidt, 1997).

Marcos de trabajo para la integracin de middleware. Consisten

en un conjunto de estndares y clases de objetos asociados que
soportan la comunicacin de componentes y el intercambio de
informacin. Ejemplos de este tipo de marcos son COF BA, COM+ de
Microsoft y Enterprise Java Beans. Estos marcos proporcionan soporte
para modelos de componentes estandarizados.

Marcos de trabajo de aplicaciones empresariales. Se refieren a

dominios de aplicaciones especficos tales como telecomunicaciones o
sistemas financieros (Baumer al, 1997). Estos marcos de trabajo
93

encapsulan el conocimiento del dominio de la aplicacin y soportan el

desarrollo de aplicaciones para los usuarios finales.

3.3.5 SISTEMAS DE APLICACIONES

La totalidad de un sistema de aplicaciones puede ser reutilizada incorporndolo
sin ningn cambio en otros sistemas, configurando la aplicacin para diferentes
clientes o desarrollando familias de aplicaciones que tienen una arquitectura
comn pero que son adaptadas a clientes particulares.
Reutilizacin de productos cots

La denominacin producto COTS se aplica a un sistema software que

puede utilizarse sin cambios por su comprador. Virtualmente todo el
software de sobremesa y un gran nmero de productos servidores son
software COTS. Debido a que este software se disea para uso general,
normalmente incluye muchas caractersticas y funciones para que sea
potencialmente reutilizable en diferentes aplicaciones y entornos. Si bien
puede haber problemas con esta aproximacin para la construccin de
sistemas (Tracz, 2001), existe un nmero creciente de experiencias con
xito que demuestran su viabilidad (Baker, 2002; Balk y Kedia, 2000;
Pfarr y Reis, 2002).

Lneas de productos software

Una de las aproximaciones ms efectivas para la reutilizacin es la

creacin de lneas de productos software o familias de aplicaciones. Una
lnea de productos es un conjunto de aplicaciones con una arquitectura
comn especfica de dichas aplicaciones.

Cada aplicacin especfica se especializa de alguna manera. El ncleo

como de la familia de aplicaciones se reutiliza cada vez que se requiere
una nueva aplicacin. El nuevo desarrollo puede implicar una
configuracin especfica de componentes, implementacin de
componentes adicionales y adaptacin de algunos componentes para
satisfacer las nuevas demandas.

3.4 DOCUMENTACIN
La documentacin de sistema de informacin es el conjunto de informacin
que nos dice qu hacen los sistemas, como lo hacen y para quin lo hacen. La
documentacin es un material que explica las caractersticas tcnicas y la
operacin de un sistema de informacin.
Hay varios tipos de documentacin como:

94

La primera es la informacin acerca de programas, que explica la lgica de un

programa e incluye descripciones, diagramas de flujo, listados de programas y
otros documentos.
La segunda es referente a los usuarios que contienen de forma general
la naturaleza y capacidades del sistema.

Segn la norma IEEE 830, debe contener los siguientes puntos:

I. Introduccin (Se definen los fines y los objetivos del software)
A. Referencia del sistema
B. Descripcin general
C. Restricciones del proyecto
II. Descripcin de la informacin (Descripcin detallada del problema,
incluyendo el HW y SW necesario)
A. Representacin del flujo de la informacin.
1. Flujo de datos
2. Flujo de control
B. Representacin del contenido de la informacin.
C. Descripcin de la interfaz del sistema.
III. Descripcin funcional (Descripcin de cada funcin requerida, incluyendo
diagramas)
A. Particin funcional
B. Descripcin funcional
1. Narrativa de procesamiento
2. Restricciones/Limitaciones.
3. Requisitos de rendimiento.
4. Restricciones de diseo
5. Diagramas de soporte
C. Descripcin del control
1. Especificacin del control
2. Restricciones de diseo.
IV. Descripcin del comportamiento (comportamiento del SW ante sucesos
externos y controles internos)
95

A. Estados del sistema

B. Sucesos y acciones
V. Criterios de validacin.
A. Lmites de rendimiento
B. Clases de pruebas
C. Respuesta esperada del SW
D. Consideraciones especiales
VI. Bibliografa
VII. Apndice.

3.4.1 OBJETIVO E IMPORTANCIA.

Dentro del ciclo de vida se encuentra la fase de implementacin de un sistema,
es la fase ms costosa y que consume ms tiempo, se dice que es costosa
porque muchas personas, herramientas y recursos, estn involucrados en el
proceso y consume mucho tiempo porque se completa todo el trabajo realizado
previamente durante el ciclo de vida.
En la fase de implementacin se instala el nuevo sistema de informacin para
que empiece a trabajar y se capacita a sus usuarios para que puedan utilizarlo.

3.4.2 TIPOS
Mtodo directo: Se abandona el sistema antiguo y se adopta
inmediatamente el nuevo. Esto puede ser sumamente riesgoso porque si algo
marcha mal, es imposible volver al sistema anterior, las correcciones debern
hacerse bajo la marcha. Regularmente con un sistema nuevo suelen surgir
problemas de pequea y gran escala. Si se trata de grandes sistemas, un
problema puede significar una catstrofe, perjudicando o retrasando el
desempeo entero de la organizacin.
Mtodo paralelo: Los sistemas de informacin antiguo y nuevo operan juntos
hasta que el nuevo demuestra ser confiable. Este mtodo es de bajo riesgo. Si
el sistema nuevo falla, la organizacin puede mantener sus actividades con el
sistema antiguo. Pero puede representar un alto costo al requerir contar con
personal y equipo para laborar con los dos sistemas, por lo que este mtodo se
reserva especficamente para casos en los que el costo de una falla sera
considerable.
Mtodo piloto: Pone a prueba el nuevo sistema slo en una parte de la
organizacin. Al comprobar su efectividad, se implementa en el resto de la
organizacin. El mtodo es menos costoso que el paralelo, aunque ms
riesgoso. Pero en este caso el riesgo es controlable al limitarse a ciertas reas,
sin afectar toda la empresa.

96

Mtodo en fases: La implementacin del sistema se divide en partes o fases,

que se van realizando a lo largo de un periodo de tiempo, sucesivamente. Una
vez iniciada la primera fase, la segunda no se inicia hasta que la primera se ha
completado con xito. As se contina hasta que se finaliza con la ltima fase.
Es costoso porque se hace ms lenta la implementacin, pero sin duda tiene el
menor riesgo.

97

UNID
AD 4.
VERIF
IACI
NY
VALID
ACIN

98

4. VERIFICACIN Y VALIDACIN
4.1 PRUEBAS
4.1.1 OBJETIVO
Las pruebas de software (en ingls software testing) son las investigaciones
empricas y tcnicas cuyo objetivo es proporcionar informacin objetiva e
independiente sobre la calidad del producto a la parte interesada o stakeholder.
Es una actividad ms en el proceso de control de calidad.
Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo
de software. Dependiendo del tipo de pruebas, estas actividades podrn ser
implementadas en cualquier momento de dicho proceso de desarrollo
El objetivo de las pruebas es presentar informacin sobre la calidad del
producto a las personas responsables de este.
Teniendo esta afirmacin en mente, la informacin que puede ser requerida es
de lo ms variada. Esto hace que el proceso de testing sea completamente
dependiente del contexto1 en el que se desarrolla.
A pesar de lo que muchos promueven, no existen las "mejores prcticas" como
tal. Toda prctica puede ser ideal para una situacin pero completamente intil
o incluso perjudicial en otra.
Por esto, las actividades, tcnicas, documentacin, enfoques y dems
elementos que condicionarn las pruebas a realizar, deben ser seleccionados y
utilizados de la manera ms eficiente segn contexto del proyecto.

4.1.2 JUSTIFICACIN
Los principales objetivos que se buscan con la prueba de software suelen ser:
Conocer el nivel de calidad de productos intermedios, para actuar a tiempo
(v.gr. rehacer un componente); esto facilita una administracin realista del time
to market del producto en cuestin.
No pagar por un producto de software sino hasta que alcance el nivel de
calidad pactado; esto eleva el nivel de certidumbre en el comprador de
software, y minimiza riesgos.
Disminuir la penosa y costosa labor de soporte a usuarios insatisfechos,
consecuencia de liberar un producto inmaduro. Esto puede mejorar la imagen
de la organizacin desarrolladora (y la credibilidad en ella).
Reducir costos de mantenimiento (la fase ms costosa del desarrollo de
software), mediante el diagnstico oportuno de los componentes del sistema
(v.gr. seguimiento a estndares, legibilidad del cdigo, integracin adecuada de
99

los componentes, rendimiento apropiado, nivel y calidad del reuso, calidad de

la documentacin, etc.).
Obtener informacin concreta acerca de fallas, que pueda usarse como apoyo
en la mejora de procesos, y en la de los desarrolladores (v.gr. capacitacin en
reas de oportunidad).
Entre ms pronto se apliquen mecanismos de prueba en el proceso de
desarrollo, ms fcilmente podr evitarse que el proyecto se salga del tiempo y
presupuesto planeado, pues se podrn detectar ms problemas originados en
las fases tempranas del proceso, que son los que mayor impacto tienen.

100

4.2 TIPOS DE PRUEBAS

Las pruebas de validacin en la ingeniera de software son el proceso de
revisin que verifica que el sistema de software producido cumple con las
especificaciones y que logra su cometido. Es normalmente una parte del
proceso de pruebas de software de un proyecto, que tambin utiliza tcnicas
tales como evaluaciones, inspecciones y tutoriales. La validacin es el proceso
de comprobar que lo que se ha especificado es lo que el usuario realmente
quera.

4.2.1 INTEGRACION
La prueba de integracin es una tcnica sistemtica para construir la
estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas
para detectar errores asociados con la interaccin. El objetivo es tomar los
mdulos probados en unidad y estructurar un programa que est de acuerdo
con el que dicta el diseo. La integracin puede ser descendente si se integran
los mdulos desde el control o programa principal, o bien, ascendente, si la
verificacin del diseo empieza desde los mdulos ms bajos y de all al
principal. La seleccin de una estrategia de integracin depende de las
caractersticas depende de las caractersticas del software y, a veces, del plan
del proyecto, en algunos de los casos se puede combinar ambas estrategias.
Pruebas de integracin.
Errores.

comunicacin a travs de la interface.

efectos colaterales perniciosos.
acumulacin notable de errores de clculo.
acceso incoherente a estructuras de datos globales.
tiempos de respuesta.

4.2.1.1 DESCENDENTE

De arriba hacia abajo, avanzado.

primero en profundidad.
primero en anchura.
tomamos el mdulo principal como driv er.
Substituimos los mdulos dependientes por stubs.

Estrategia descendente (cont).

Realizando pruebas especficas para el modulo

Repitiendo las realizadas previamente (pruebas regresivas)
101

 Progresamos sustituyendo stubs por mdulos reales.

4.2.1.2 ASCENDENTE

Agrupamos los mdulos inferiores (segn funcionabilidad p.e.)

Preparamos un driver para cada grupo y realizamos las pruebas.
Progresamos sustituyendo los driver por mdulos reales.
Realizamos pruebas especficas y regresivas.

Descendente.
A favor:
Se prueban antes los mdulos ms importantes,
si primero en profundidad quedan probadas antes ramas completas.
En contra:
Elaboracin stubs.

Ascendente.
En contra:
Gran incertidumbre hasta el final.

102

4.2.1.3 REGRESION

Regresin (informtica): las pruebas de regresin son cualquier tipo

de pruebas de software que intentan descubrir las causas de nuevos errores
(bugs), carencias de funcionalidad, o divergencias funcionales con respecto
al comportamiento esperado del software, inducidos por cambios
recientemente realizados en partes de la aplicacin que anteriormente al
citado cambio no eran propensas a este tipo de error.

4.2.2 VALIDACION
Las pruebas de validacin en la ingeniera de software son el proceso de revisin que
verifica que el sistema de software producido cumple con las especificaciones y que logra
su cometido. Es normalmente una parte del proceso de pruebas de software de un
proyecto, que tambin utiliza tcnicas tales como evaluaciones, inspecciones y tutoriales.
La validacin es el proceso de comprobar que lo que se ha especificado es lo que
el usuario realmente quera.
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para
determinar si satisface los requisitos iniciales. La pregunta a realizarse es: Es esto lo que
el cliente quiere?

Comprobar que se satisfacen los requisitos:

Se usan la mismas tcnicas, pero con otro objetivo.

No hay programas de prueba, sino slo el cdigo final de
la aplicacin.
Se prueba el programa completo.

Uno o varios casos de prueba por cada requisito o caso

de uso especificado.

Se prueba tambin rendimiento, capacidad, etc. (y no

slo resultados correctos).
103


Pruebas alfa (desarrolladores) y beta (usuarios).
4.2.2.1 ALFA
Las pruebas de tipo alfa son la que se realizan con una muestra de datos
reales.
A prueba alfa se lleva a cabo, por un cliente, en el mismo lugar de desarrollo.
Se usa el software de forma natural con el desarrollador como observador
del usuario y registrando los errores y problemas de uso. Las pruebas alfa se
llevan a cabo en un entorno controlado.
Alfa de prueba se hace antes de que el software se ponga a disposicin
del pblico. Por lo general, los desarrolladores se realicen la prueba alfa
utilizando tcnicas de pruebas de caja blanca. Caja posterior negro y tcnicas
de caja gris se llevar a cabo despus. La atencin se centra en la simulacin
de los usuarios reales mediante el uso de estas tcnicas y la realizacin de
tareas y operaciones que un usuario tpico podra llevar a cabo. Normalmente,
las pruebas alfa en s se llevarn a cabo en un entorno de tipo de laboratorio y
no en el lugar de trabajo habitual. Una vez que estas tcnicas se han cumplido
satisfactoriamente, la prueba alfa se considera completa.

4.2.2.2 BETA
La prueba beta es la que se lleva a cabo por los usuarios finales del
software en los lugares de trabajo de los clientes. A diferencia de la prueba
alfa, el desarrollador no est presente. As, la prueba beta es una
aplicacin en vivo del software en un entorno que no puede ser controlado por
el desarrollador. El cliente registra todos los problemas que encuentra durante
la prueba beta e informa a intervalos regulares al desarrollador.
Hay muchos ejemplos de programas en fase beta, uno de ellos es el Minecraft,
un juego que se encuentra en fase beta y que est en constante actualizacin
y correcin de bugs (errores/fallos). Normalmente los programas en fase beta
suelen distribuirse gratuitamente, en este caso el Minecraft empez igual pero
ahora para coger la fase beta tienes que comprar el juego, pero con la promesa
de que cuando salga la versin final tendrs el juego gratis y las
actualizaciones futuras tambin sern gratis. Adems el juego te cuesta un
25% ms barato que cuando salga la versin final. En el caso del Minecraft los
usuarios que prueban el juego en fase beta reportan los fallos al desarrollador,
y este va publicando en su blog en los errores que est trabajando y en las
mejoras que va a implementar.
A diferencia de las pruebas alfa, la gente fuera de la empresa se incluye
para realizar las pruebas. Como el objetivo es hacer una simple comprobacin
antes del lanzamiento de productos, es posible que los defectos encontrados
durante esta etapa, por lo que la distribucin del software se limita a una
seleccin de los usuarios de fuera de la empresa. Por lo general, las empresas
subcontratadas se utilizan como pruebas de su opinin es independiente y
desde una perspectiva diferente que la de los empleados de la compaa de
104

desarrollo de software. Los comentarios se pueden utilizar para corregir los

defectos que se perdieron, ayudar en la preparacin de equipos de apoyo para
temas que se espera o en algunos casos incluso imponer cambios de ltima
hora a la funcionalidad.

4.2.3 SISTEMA
Verifica el sistema completo o su aplicacin como tal. Se toma un punto de
vista del usuario final y los casos de uso de pruebas ejecutando acciones
tpicas de usuario.

RUEBAS DE SOFTWARE: VERIFICACIN Y VALIDACIN (V y V)

Nuestros servicios de Verificacin y Validacin (Pruebas de Software) son la
respuesta a su necesidad de contar con aplicaciones confiables, reducir sus
costos de desarrollo y de mantenimiento y que, adems, permitan mejorar la
calidad de sus procesos de desarrollo y optimizar recursos para efectos futuros.

Nuestra propuesta consiste en acompaar el Ciclo de Vida del Software

CVS con un Proceso Planeado de Verificacin y Validacin ejecutado
porun Grupo Independiente de Verificacin y Validacin GIVV, lo cual
tiene las siguientes ventajas:

Identificar defectos en etapas tempranas

Mejorar la calidad del producto

Mejorar la calidad del proceso

Importancia del Grupo Independiente de Verificacin y

Validacin GIVV.
Ser un equipo independiente de los grupos de desarrollo nos permite realizar
nuestra tarea con absoluta objetividad. Esta independencia da como resultado
la eliminacin de cualquier conflicto de inters provocado por tener otras
actividades como prioritarias (desarrollo en s) o por el apego a los programas
producidos.

105

Nuestros Testers estn especialmente capacitados en tcnicas de identificacin

de defectos y realizan su trabajo de manera profesional, tica y con respeto
hacia las personas de desarrollo.
Asegurar la apropiada navegacin dentro del sistema, ingreso de datos,
procesamiento y recuperacin.
deben enfocarse en requisitos que puedan ser tomados directamente de
casos de uso y reglas y funciones de negocios
Ejecute cada caso de uso, flujo bsico o funcin utilizando datos vlidos
e invlidos

4.2.3.1. RECUPERACIN.
Verificar que los procesos de recuperacin (manual o automatica) restauran
apropiadamente la Base de datos.
Estas pruebas aseguran que una aplicacin o sistema se recupere de una
variedad de anomalas de hardware, software o red con perdidas de datos o
fallas de integridad.
Se deben utilizar las pruebas creadas para la Funcionalidad del sistema y
Procesos de Negocios para crear una serie de transacciones

4.2.3.2 SEGURIDAD
Nivel de seguridad de la aplicacin: Verifica que un actor solo pueda acceder a
las funciones y datos que su usuario tiene permitido
Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios e
incluyendo accesos remotos
Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones
y datos a los que se debe autorizar.

4.2.3.3. RESISTENCIA.
Estas pruebas se disean para enfrentar a los sistemas a situaciones
anormales, es decir ejecutar el sistema en forma que demande recursos en
cantidad, frecuencia o volmenes anormales. Igualmente busca validar el
correcto funcionamiento del sistema bajo las condiciones de carga normales
para la operacin para concluir sobre variables como: el tiempo de respuesta,

106

carga de procesamiento, trabajo por unidad de tiempo y utilizacin de

recursos.

Stress:
Verificar que el sistema funciona apropiadamente y sin errores
Las pruebas de stress se proponen encontrar errores debidos a recursos
bajos o completitud de recursos
Use los scripts utilizados en las pruebas de desempeo
Carga:
Validar el tiempo de respuesta para las transacciones
miden tiempos de respuesta, ndices de procesamiento de transacciones
y otros requisitos sensibles al tiempo
Modifique archivos de datos (para incrementar el nmero de
transacciones) o los scripts para incrementar el nmero de veces que
ocurre cada transaccin

4.2.3.4 RENDIMIENTO
Son las pruebas que se realizan, desde una perspectiva, para determinar lo
rpido que realiza una tarea un sistema en condiciones particulares de trabajo.
Tambin puede servir para validar y verificar otros atributos de la calidad del
sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. Las
pruebas de rendimiento son un subconjunto de la ingeniera de pruebas, una
prctica informtica que se esfuerza por mejorar el rendimiento, englobndose
en el diseo y la arquitectura de un sistema, antes incluso del esfuerzo inicial
de la codificacin.

107

4.3 MANTENIMIENTO
Es el trabajo emprendido para cuidar y restaurar hasta un nivel econmico,
todos y cada uno de los medio de produccin existentes en una planta .
Podemos definir el mantenimiento como el conjunto de actividades que deben
realizarse a instalaciones y equipos con el fin de corregir o prevenir fallas,
buscando que estos continen prestando el servicio para el cual fueron
diseados.
Como los equipos no se pueden mantener en buen funcionamiento por si solos,
se debe contar con un grupo de personas que se encarguen de ello,
conformando as el departamento de mantenimiento de nuestras empresas.

OBJETIVOS DEL MANTENIMIENTO INDUSTRIAL

En cualquier empresa, el mantenimiento debe cumplir con los dos objetivos
fundamentales: reducir costos de produccin y garantizar la seguridad
industrial.
Cuando se habla de reducir los costos de produccin se deben tener en cuenta
los siguientes aspectos:

Optimizar la disponibilidad de equipos e instalaciones para la produccin.

Se busca reducir los costos de las paradas de produccin ocasionadas por
deficiencia en el mantenimiento de los equipos, mediante la aplicacin de
una determinada cantidad de mantenimiento

en los momentos ms

apropiados.
Incrementar la vida til de los equipos
Uno de los objetivos evidentes del mantenimiento es el de procurar la
utilizacin de los equipos durante toda su vida til. La reduccin de los
factores de desgastes, deterioros y roturas garantiza que los equipos
alcancen una mayor vida til.
Maximizar el aprovechamiento de los recursos disponibles para la funcin
del mantenimiento.
Es aqu donde se debe analizar la convivencia o no de continuar prestando
el servicio de mantenimiento a una mquina que presenta problemas de
funcionamiento buscar su reemplazo.

108

La planificacin del mantenimiento reduce los costos de operacin y

reparacin de los equipos industriales. Los programas para la lubricacin,
limpieza y ajustes de los equipos permiten una reduccin notable en el
consumo de energa y un aumento en la calidad de los productos
terminados. A mayor descuido en la conversacin de los equipos, mayor
ser la produccin de baja calidad.
Para cumplir estos objetivos es necesario realizar algunas funciones
especficas a travs del departamento de mantenimiento, tales como:
Administrar el personal de mantenimiento
Programar los trabajos de mantenimiento
Establecer los mecanismos para retirar de la produccin aquellos equipos
que presenten altos costos de mantenimiento
Proveer al personal de mantenimiento de la herramienta adecuada para sus
funciones
Mantener actualizadas las listas de repuestos y lubricantes
Adiestrar al personal de mantenimiento sobre los principios y normas de
seguridad industrial.
Disponer adecuadamente de los desperdicios y del material recuperable

4.4.3 TIPOS DE MANTENIMIENTO

4.4.3.1 MANTENIMIENTO CORRECTIVO
Es aquel mantenimiento encaminado a corregir una falla que se presente en
determinado momento. Se puede afirmar que es el equipo quien determina
cuando se debe parar. Su funcin principal es poner en marcha el equipo lo
ms rpido posible y al mnimo costo posibles.
Este mantenimiento es comn encontrarlo en las empresas pequeas y
medianas, presentando una serie de inconvenientes a saber:

Normalmente cuando se hace una reparacin no se alcanzan a detectar

otras posibles fallas porque no se cuenta con el tiempo disponible.
109

 Por lo general el repuesto no se encuentra disponible porque no se tiene un

registro del tipo y cantidad necesarios
Generalmente la calidad de la produccin cae debido al desgaste
progresivo de los equipos

MANTENIMIENTO PERIODICO
Este mantenimiento se realiza despus de un periodo de tiempo relativamente
largo (entre seis y doce meses).su objetivo general es realizar operaciones
mayores e los equipos .para implementar este tipo de mantenimiento se debe
contar con una excelente planeacin y una coordinacin con las diferentes
reas de la empresa para lograr que las reparaciones se efecten en el menor
tiempo posible.

MANTENIMIENTO PROGRAMADO
Este tipo de mantenimiento basa su aplicacin en el supuesto de que todas las
piezas se desgastan en la misma forma y en el mismo periodo de tiempo, no
importa que se est trabajando en condiciones diferentes
Para implementar el mantenimiento programado se hace un estudio de todos
los equipos de la empresa y se determina con la ayuda de datos estadsticos
de los repuestos y la informacin del fabricante, cuales piezas se deben
cambiar en determinados periodos de tiempo.

4.4.3.2 MANTENIMIENTO PREVENTIVO

Este tipo de mantenimiento tiene su importancia en que realiza inspecciones
peridicas sobre los equipos, teniendo en cuenta que todas las partes de un
mecanismo se desgastan en forma desigual y es necesario atenderlos para
garantizar su buen funcionamiento.
El mantenimiento previo se hace mediante un programa de actividades
(revisiones y lubricacin), con el fin de anticipar a las posibles fallas en el
equipo. Tiene en cuenta cuales actividades se deben realizar sobre el equipo
en marcha o cuando este detenido.

4.4.3.2 MANTENIMIENTO PREDECTIVO

Este tipo de mantenimiento consiste en efectuar una serie de mediciones o
ensayos no destructivos con equipos sofisticados a todas aquellas partes de la
maquinaria susceptibles deterioro, pudiendo con ello aplicarse a la falla
castratofica. La mayora de estas mediciones se efectan con el equipo en
marcha y sin interrumpir la produccin.

MANTENIMIENTO PROACTIVO

110

Selecciona aquellos lubricantes y procedimientos ptimos donde se logra

incrementar la produccin, disminuyendo los costos directos de energa y
prolongando la vida til de los equipos.

111

4.4 CARACTERSTICAS DEL MANTENIMIENTO

No es el mismo tipo de mantenimiento el del software que el de hardware,
como primera aproximacin al mantenimiento del software lo definiremos
como el conjunto de medidas que hay que tomar para que el sistema siga
trabajando correctamente. Entre las caractersticas sobresalientes del
mantenimiento del software destacan:
- El software no envejece.
- El mantenimiento del software supone adaptar el paquete o sistema objeto
del mismo a nuevas situaciones como:
Cambio de hardware.
Cambio de software de base (S.O.).
- Todo sistema software conlleva mejoras o aadidos indefinidamente.
Al cerrar todo proyecto se debe considerar y preveer las normas del
mantenimiento del sistema (tanto en connotaciones hardware como software).

4.4.1 COSTOS
El coste del mantenimiento de un producto software a lo largo de su vida til
es superior al doble de los costes de su desarrollo.

Por norma general, el porcentaje de recursos necesarios en el mantenimiento

se incrementa a medida que se genera ms software. A esta situacin se le
conoce como
Barrera de Mantenimiento.
Las causas a las que se debe este incremento de trabajo de mantenimiento
son:
1) Gran cantidad de software antiguo (ms de 10 aos); an siendo
construidos con las mejores tcnicas de diseo y codificacin del momento
(rara vez), su creacin se produjo con restricciones de tamao y espacio de
almacenamiento y con herramientas desfasadas tecnolgicamente.
2) Los programas sufren migraciones continuas de plataformas o SSOO.
3) El software ha experimentado modificaciones, correcciones, mejoras y
adaptaciones a nuevas necesidades de los usuarios. Adems, estos cambios se
112

realizaron sin tcnicas de reingeniera o ingeniera inversa, dando como

resultado sistemas que funcionan con baja calidad (mal diseo de estructuras
de datos, mala codificacin, lgica defectuosa y escasa documentacin).
Como consecuencia de estos grandes costes, es que el coste relativo de
reparar un error aumenta considerablemente en las ltimas fases del ciclo de
vida del software. Las razones por las que es menos costoso reparar defectos
en las primeras fases del ciclo de vida software son:
- Es ms sencillo cambiar la documentacin que modificar el cdigo.
- Un cambio en las fases posteriores puede repercutir en cambiar toda la
documentacin de las fases anteriores.
- Es ms sencillo detectar un error en la fase en la que se ha introducido que
detectarlo y repararlo en fases posteriores. - Un defecto se puede ocultar en la
inexistencia o falta de actualizacin de los documentos de especificacin o
diseo.
Existen otra serie de costes intangibles del mantenimiento del software, que
son:
- Oportunidades de desarrollo que se han de posponer o que se pierden debido
a los recursos dedicados a las tareas de mantenimiento.
- Insatisfaccin del cliente cuando no se le satisface en un tiempo debido una
solicitud de reparacin o modificacin.
- Los cambios en el software durante el mantenimiento tambin introducen
errores ocultos.
- Perjuicios en otros proyectos de desarrollo cuando la plantilla tiene que
dejarlos o posponerlos debido a una solicitud de mantenimiento.
En conclusin, la productividad en LDC (lneas de cdigo) por persona y mes
durante el proceso de mantenimiento puede llegar a ser 40 veces inferior con
respecto al proceso de desarrollo.

4.4.2 EFECTOS
En el mantenimiento del software existe el riesgo del llamado efecto bola de
nieve; que consiste en que los cambios introducidos por una peticin de
mantenimiento conllevan efectos secundarios que implican futuras peticiones
de mantenimiento.
Efectos secundarios sobre el cdigo:
1.- Cambios en el diseo que suponen muchos cambios en el cdigo.
2.- Eliminacin o modificacin de un subprograma.
3.- Eliminacin o modificacin de una etiqueta.

113

4.- Eliminacin o modificacin de un identificador.

5.- Cambios para mejorar el rendimiento.
6.- Modificacin de la apertura/cierre de ficheros.
7.- Modificacin de operaciones lgicas.
Efectos secundarios sobre los datos:
1.- Redefinicin de constantes locales o globales.
2.- Modificacin de los formatos de registros o archivos.
3.- Cambio en el tamao de una matriz u otras estructuras similares.
4.- Modificacin de la definicin de variables globales.
5.- Reinicializacin de indicadores de control o punteros.
6.- Cambios en los argumentos de los subprogramas. Es importante una
correcta documentacin de los datos.

Efectos secundarios sobre la documentacin:

1.- Modificar el formato de las entradas interactivas.
2.- Nuevos mensajes de error no documentados.
3.- Tablas o ndices no actualizados.
4.- Texto no actualizado correctamente.

4.4.3 TIPOS
Existen 4 tipos de mantenimiento:
Correctivo.
Adaptativo.
Perfectivo.
Preventivo.
Mantenimiento correctivo:
Tiene por objetivo localizar y eliminar los posibles defectos de los programas.
Un defecto en un sistema es una caracterstica del sistema con el potencial de
provocar un fallo. Un fallo se produce cuando el comportamiento de un sistema
difiere con respecto al comportamiento definido en la especificacin.

114

Los fallos en un sistema software pueden ser:

- Procesamiento (salidas incorrectas de un programa).

- Rendimiento (tiempo de respuesta demasiado alto).
- Programacin (inconsistencias en el diseo).
- Documentacin (inconsistencias entre la funcionalidad de un programa y el
manual de usuario).
Mantenimiento adaptativo:
Consiste en la modificacin de un programa debido a cambios en el entorno
(hardware o software) en el que se ejecuta. Desde cambios en el sistema
operativo, pasando por cambios en la arquitectura fsica del sistema
informtico, hasta en el entorno de desarrollo del software. Este tipo de
mantenimiento puede ser desde un pequeo retoque hasta una reescritura de
todo el cdigo.
Los cambios en el entorno de desarrollo del software pueden ser:
-

En el entorno de los datos (p.e. cambiar sistema de ficheros por BD

relacional).
En el entorno de los procesos (p.e. migracin a plataforma con procesos
distribuidos).

Este mantenimiento es cada vez ms frecuente debido a la tendencia actual de

Actualizacin de hardware y SSOO cada poco tiempo.
Mantenimiento perfectivo:
Conjunto de actividades para mejorar o aadir nuevas funcionalidades
requeridas por el usuario.
Se divide en dos:
- Mantenimiento de Ampliacin: incorporacin de nuevas Funcionalidades.
- Mantenimiento de Eficiencia: mejora de la eficiencia de ejecucin.
Mantenimiento preventivo:
Modificacin del software para mejorar las propiedades de dicho software
(calidad y mantenibilidad) sin alterar sus especificaciones funcionales. Incluir
sentencias que comprueben la validez de los datos de entrada,
reestructuracin de los programas para aumentar su legibilidad o incluir
nuevos comentarios. Este tipo de mantenimiento utiliza las tcnicas de
ingeniera inversa y reingeniera.
115

116

4.4.3.1 MANTENIMIENTO CORRECTIVO

Consiste en la reparacin de alguno de los componentes de la computadora,
puede ser una soldadura pequea, el cambio total de una tarjeta (sonido,
video, SIMMS de memoria, entre otras), o el cambio total de algn dispositivo
perifrico como el ratn, teclado, monitor, entre otros.
Resulta mucho ms barato cambiar algn dispositivo que el tratar de repararlo
pues muchas veces nos vemos limitados de tiempo y con sobre carga de
trabajo, adems de que se necesitan aparatos especiales para probar algunos
dispositivos.
As mismo, para realizar el mantenimiento debe considerarse lo siguiente:
En el mbito operativo, la reconfiguracin de la computadora y los principales
programas que utiliza.
Revisin de los recursos del sistema, memoria, procesador y disco duro.
Optimizacin de la velocidad de desempeo de la computadora.
Revisin de la instalacin elctrica (slo para especialistas).
Un completo reporte del mantenimiento realizado a cada equipo.
Observaciones que puedan mejorar el ambiente de funcionamiento.
Criterios que se deben considerar para el mantenimiento a la PC.
La periodicidad que se recomienda para darle mantenimiento a la PC es de una
vez por trimestre, esto quiere decir que como mnimo debe drsele cuatro
veces al ao, pero eso depender de cada usuario, de la ubicacin y uso de la
computadora.

4.4.3.2 MANTENIMIENTO PREVENTIVO/PERFECTIVO

El mantenimiento preventivo en general se ocupa en la determinacin de
condiciones operativas, de durabilidad y de confiabilidad de un equipo en
mencin este tipo de mantenimiento nos ayuda en reducir los tiempos que
pueden generarse por mantenimiento correctivo.
En lo referente al mantenimiento preventivo de un producto software, se
diferencia del resto de tipos de mantenimiento (especialmente del
mantenimiento perfectivo) en que, mientras que el resto (correctivo, evolutivo,
perfectivo, adaptativo...) se produce generalmente tras una peticin de cambio

117

por parte del cliente o del usuario final, el preventivo se produce tras un
estudio de posibilidades de mejora en los diferentes mdulos del sistema.
Aunque el mantenimiento preventivo es considerado valioso para las
organizaciones, existen una serie de fallas en la maquinaria o errores humanos
a la hora de realizar estos procesos de mantenimiento. El mantenimiento
preventivo planificado y la sustitucin planificada son dos de las tres polticas
disponibles para los ingenieros de mantenimiento.
Algunos de los mtodos ms habituales para determinar que procesos de
mantenimiento preventivo deben llevarse a cabo son las recomendaciones de
los fabricantes, la legislacin vigente, las recomendaciones de expertos y las
acciones llevadas a cabo sobre activos similares.
El primer objetivo del mantenimiento es evitar o mitigar las consecuencias de
los fallos del equipo, logrando prevenir las incidencias antes de que estas
ocurran. Las tareas de mantenimiento preventivo incluyen acciones como
cambio de piezas desgastadas, cambios de aceites y lubricantes, etc. El
mantenimiento preventivo debe evitar los fallos en el equipo antes de que
estos ocurran.

4.4.3.2 MANTENIMIENTO ADAPTATIVO

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de
forma incorrecta confundindose muy a menudo con el mantenimiento
evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.
Lo mejor es recordar las definiciones que Mtrica V.3, hace de cada uno de estos
mantenimientos:
- Mantenimiento evolutivo: Incorporaciones, modificaciones y eliminaciones necesarias
en un producto software para cubrir la expansin o cambios en las necesidades del
usuario.
- Mantenimiento adaptativo: Modificaciones que afectan a los entornos en los que el
sistema opera, por ejemplo, cambios en la configuracin del hardware, software de base,
gestores de bases de datos, comunicaciones, etc.

118

Con las definiciones por delante resulta bastante sencillo discernir un tipo de
mantenimiento de otro, ya que el primero est centrado en un cambio en las necesidades
del usuario o lo que es lo mismo, en una modificacin de los requisitos funcionales de la
aplicacin (por muy pequeos o grandes que sean) y el segundo se basa en los cambios
en cualquiera de los elementos que conforman el entorno sobre el que funciona el
programa, a los ejemplos que indica Mtrica V.3, yo aadira los servidores de
aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si
una aplicacin se comunica con otra por servicios web y sta modifica la interfaz el
cambio a realizar en la aplicacin es de carcter adaptativo ya que el requisito funcional
(que es comunicarse con ese tercer sistema) no ha variado.

119