Antologa

Ingeniera Informtica Gpo. 505-A

Prof. Jos Manuel Daz Rivera

Desarrollo e Implementacin de
Sistemas de informacin
PRLOGO
La siguiente antologa es un ejemplar de los temas que se llevan a cabo en la
materia Desarrollo e implementacin de sistemas de informacin, cuyo objetivo de
la materia es el de adoptar y obtener herramientas intelectuales que nos permitan
poner en marchar planes de creacin y aplicacin de los sistemas de informacin,
los cuales por muy pequeos o muy grandes que sean estos, tienen la importancia
necesaria para poder poner en marcha a las empresas u organizaciones que las
usan, y de esta manera, y dada la importancia de cada uno de estos, poseen la
necesidad de manejar informacin y deben facilitarse tanto como sea posible, y en
estos casos entramos los informticos, pero no es suficiente con estar dispuesto a
la resolucin de problemas en este sistema, hay que saber hacerlo y para ello
tenemos la recopilacin de esta antologa con los temas que se implantarn a lo
largo de la presente antologa.

NDICE

Tabla de contenido
1. UML Y EL PROCESO UNIFICADO.......................................................................1
1.1CONCEPTUALIZACIN DE UML.......................................................................1
1.1.2 PRIMERAS METODOLOGAS.....................................................................1
1.1.3 ANTECEDENTES DE UML..........................................................................2
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
2

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
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
3

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.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
4

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
5

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

UNIDA
D 1.
UML Y
EL
PROCE
SO
UNIFIC
ADO

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
1

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
2

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)

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

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.
5

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.
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:
9

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:

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

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

nmero fijo: m (m denota el nmero).

10

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).
11

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

12

Restricciones. Extiende la semntica de un bloque, aadiendo reglas o

modificando las existentes.

13

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.

14

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
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.
15

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

16

redondeadas adjuntando todas las acciones, flujos

de control y otros elementos que constituyen la
actividad.
Acciones
Una accin representa un solo

paso dentro de una actividad. Las

acciones

rectngulos

se

denotan

por

con

las

puntas

redondeadas.

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

17

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>>

Nodos de Decisin y Combinacin

18

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.

19

Gestores de Excepcin
Los gestores de excepcin se pueden modelar en
diagrama de actividad como en siguiente ejemplo.
Regin de Actividad Interrumpible
Una regin de actividad interrumpida rodea un grupo de
acciones que se pueden interrumpir.
Particin
Una particin de una actividad e muestra como calles
horizontales o 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

20

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.
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

21

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:
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:

22

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.
Limites del sistema: Resulta til dibujar los lmites
del sistema cuando se pretende hacer un diagrama
de casos de uso para parte del sistema.

23

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

24

25

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.

26

 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.

27

1.5.1 PLANIFICACIN DE LOS SISTEMAS DE GESTIN

1.
2.
3.
4.

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.
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:
28

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 subobjetivos 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.

29

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 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):
30

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 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.

31

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.
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
32

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.
1.5.4 ANLISIS Y DISEO
1. Planificacin y Especificacin de Requisitos: Planificacin, definicin de
requisitos, conocer los procesos del dominio, etc.

33

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:

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.
34

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.

35

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.

36

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.).
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.

37

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

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

38

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.

39

 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.
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.

40

UNIDA
D 2.
DISE
O DE
SISTE
MAS

41

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.
42

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 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
43

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..., 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.

44

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. 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
45

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.

Solaris,

c.

Lyns OS

d.

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.
a.
El SOTR debe ser multitarea y permisible
b.
c.

Un SOTR debe poder asignar prioridades a las tareas

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

46

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.
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

47

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

Clase Abstracta

atributo Derivado
operacin( )
48

Las clases se representan con rectngulos divididos en tres

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.
1

No ms de uno

0...1 Cero o uno

*

Empresa
1

Muchos

0...* Cero o muchos

1...*Uno o muchos

1...*
Empleado

49

Asociacin Tripartita

Clase A

Clase B

Asociacin Tripartita

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.
Todo

Todo

Parte

Parte

50

Generalizacin
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 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

51

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 tipo = Valor

Atributo tipo = Valor
Atributo tipo = Valor
Atributo tipo = 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.

52

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

Imprimir

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

53

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 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

Acelera

Eleva

Estado Inicial

Desciende

Desacelera

54

Estado Final
Ejemplo de Diagrama de Estado

Diagrama de Secuencias
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.

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

55

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.
j

Lneas de Vida

56

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

Loops

<< Destruir

Una repeticin o loop en un diagrama de secuencias, es representado como un

rectngulo. La condicin para abandonar el 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
j

Los estados de accin representan las acciones no interrumpidas de los

objetos.

Actividad

Flujo de la Accin
57para
[Condicin
llir]
sa

Los flujos de accin, representados con flechas, ilustran las relaciones entre
los estados de accin.
Actividad

Actividad

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 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
Actividad
Estado final de un estado de accin.

[ Condicin 1]
Actividad

58
Actividad

Ramificacin
Un rombo representa una decisin con camino.

59

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

Actividad

60

Diagrama de Colaboraciones
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.

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.

61

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
Las dependencias entre componentes se grafican usando flechas de puntos.
Componente
Componente

Componente

Dependencia

62

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

Procesador
Nombre

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

Nodo

Nodo

Componentes y Nodos

Nodo

Componente 1

Componente 2

Adaptacin 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 claramente
63

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
64

y Balance

2.3.1.2 PROPIEDAD
Casos Particulares:

Clase Abstracta:

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
65

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)

nmero fijo: m (m denota el nmero).

i.

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:

66

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").
67

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:

68

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.
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.
69

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 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
70

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

71

atributos y operaciones a sus subclases. Las Subclases admiten la definicin de

nuevos atributos, as como crear, modificar o inhabilitar propiedades.

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
72

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
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
73

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

paquetes.

Cada

mdulo

debe

contener

componentes

con

caractersticas afines, de tal manera que faciliten la produccin de la arquitectura

fsica de un sistema.

74

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,
75

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.
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.
76

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.
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
77

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

78

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.

79

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
80

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
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.

81

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
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.
82

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.

83

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

84

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.
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:
85

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.

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.

86

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).

87

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.

88

Modelo en forma de estrella usado en OLAP

Cubo OLAP con Tiempo, Cliente y Producto como dimensiones.

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.

89

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.

90

Beneficio total de la venta.

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.

91

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

usuarios

pueden

comprender

fcilmente la lgica del programa.

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

favorece

que

del esfuerzo de mantenimiento: la divisin en mdulos

las

distintas

funciones

las

lleven

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 50200 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.
92

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.
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.

93

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
calidad de un diseo.
interconexiones

De

no detectados que determinan

todas

formas

es

posible

a su vez la

afirmar

que

las

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 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

94

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:
95

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 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
96

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 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.

97

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
98

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 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)

99

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)
(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.

100

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:
- 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.
101

- 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.
102

- 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
- 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.

103

-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.
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.

104

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:
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
105

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

106

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
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

107

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.
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
108

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
109

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 puede
guiarse con mtricas tales como CR, pero el rbitro final debera ser la respuesta
del usuario basada en prototipos de IGU.

110

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.

111

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

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.
112

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
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.

113

UNIDA
D 3.
IMPLE
MENTA
CIN

114

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.

115

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, 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
116

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.

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.

117

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
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
118

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:
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)
119

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.

120

IV. Descripcin del comportamiento (comportamiento del SW ante sucesos

externos y controles internos)
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.
121

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.
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.

122

UNIDA
D 4.
VERIFI
ACIN
Y
VALID
ACIN

123

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.
124

 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 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.

125

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.
126

Substituimos los mdulos dependientes por stubs.

Estrategia descendente (cont).

Realizando pruebas especficas para el modulo
Repitiendo las realizadas previamente (pruebas regresivas)
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.

127

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.

128

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).

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.
129

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 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)

130

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.
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.

131

 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.

132

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, 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

133

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.

134

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.
135

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.
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

136

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.
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

137

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

ensayos no destructivos con equipos sofisticados a todas aquellas partes de la

maquinaria susceptibles

deterioro, pudiendo con ello aplicarse

castratofica. La mayora de estas mediciones

a la falla

se efectan con el equipo en

marcha y sin interrumpir la produccin.

MANTENIMIENTO PROACTIVO
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.

138

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:
139

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
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.
140

- 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.
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.

141

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.

Los fallos en un sistema software pueden ser:

142

- 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:

143

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.

144

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.

145

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 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.

146

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.
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.

147