14-12-2016

Universidad
Tecnolgica de
la Selva.
Antologa: Ingeniera de
Software.

Docente: Ing. Jess Antonio Saldaa Espinosa.

Contenido
Introduccin a la asignatura. .......................................................................... 3
Unidad I. Metodologas de desarrollo de software. ................................................ 4
Metodologa de desarrollo de software .............................................................. 4
Clasificacin de las metodologas. .................................................................... 4
Metodologas estructuradas. ........................................................................... 5
Metodologas no estructuradas. ....................................................................... 5
Modelo en cascada. ...................................................................................... 6
Modelo basado en prototipos. ......................................................................... 9
Modelo incremental. ................................................................................... 11
Modelo en espiral. ...................................................................................... 14
Desarrollo rapido de aplicaciones (RAD). ........................................................... 18
Modelo RUP. ............................................................................................. 20
Programacin extrema (XP). .......................................................................... 22
Scrum ..................................................................................................... 23
CMMI ...................................................................................................... 27
Metodologa Moprosoft ................................................................................. 28
Agil MSF (Microsoft Solution FrameWork). .......................................................... 30
Otros enfoques de desarrollo de software. ......................................................... 32
Unidad II. Administracin de requerimientos. ..................................................... 33
Estudio de factibilidad. ................................................................................ 33
Factibilidad Tcnica. ................................................................................... 33
Factibilidad Econmica. ............................................................................... 37
Factibilidad Operativa. ................................................................................ 43
Obtencin y anlisis de requerimientos. ............................................................ 44
Validacin de Requerimientos. ....................................................................... 55
Unidad III. ................................................................................................ 57
Elementos de ayuda ................................................................................ 73
Diagramas de componentes........................................................................ 74
Diagramas de implementacin .................................................................... 74
Diagramas de relacin de entidad ................................................................. 74
Conceptos del diagrama de relaciones de entidades extendido (EER) ............................ 77
Introduccin a la asignatura.

Programar es divertido, pero desarrollar software de calidad es difcil. Entre las ideas esplendidas, los
requisitos o la visin, y un producto software funcionando, hay mucho ms que programar. El anlisis
y el diseo que definen cmo solucionar el problema, que programar, y la expresin de este diseo de
forma que sea fcil de comunicar, revisar, implementar y evolucionar constituyen la parte central de
este documento.

En la actualidad se cuenta con diversas tipos de metodologas para el desarrollo de software, lo cual
genera una gran problemtica obre cual debemos de utilizar a la hora de disear un software, para
esto es necesario conocer una, y as poder elegir correctamente la ms adecuada segn la necesidad
que se tenga. En el presente documento se dan a conocer las tecnologas de desarrollo de software
ms utilizadas as como su funcionamiento, con el fin de solucionar la necesidad de documentar un
proyecto de carcter tecnolgico.

La Ingeniera de software es una disciplina o rea de la Informatica o ciencias de la computacin que

ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelvan problemas
de todo tipo. Hoy en da es cada vez ms frecuentemente la consideracin de la Ingenieria del software
como una nueva rea de las Ingenieria, y el ingeniero del software comienza a ser una profesin
implantada en el mundo laboral internacional con derechos, deberes y responsabilidades que cumplir,
junto a una, ya, reconocida consideracin social ene l mundo empresarial y por suerte para esas
personas con brillante futuro.

La Ingenieria del software trata con reas muy diversas de la informtica y de las ciencias de la
computacin, tales como construccin de compiladores, siste mas operativos o desarrollos de
intranet/internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de
sistemas de informacin y aplicables a una infinidad de reas tales como: negocios, investigacin
cientfica, medicina y produccin, logstica, banca, control de trfico, meteorologa, el mundo del
derecho, la red de redes internet, redes intranet y extranet.

3
Unidad I. Metodologas de desarrollo de software.

Metodologa de desarrollo de software

Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se

basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental,
espiral entre otros). Adicionalmente una metodologa debera definir con precisin los artefactos, roles
y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la
metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el
trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o
algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o
diseo.

Una Metodologa de desarrollo de software es un conjunto de pasos y procedimientos que deben

seguirse para desarrollar software. Una metodologa est compuesta por:

Como dividir un proyecto en etapas.

Qu tareas se llevan a cabo en cada etapa.
Qu restricciones deben aplicarse.
Qu tcnicas y herramientas se emplean.
Cmo se controla y gestiona un proyecto.

Clasificacin de las metodologas.

Las metodologas se clasifican de la siguiente forma:

Estructuradas.

Orientadas a procesos.
Orientadas a datos.
Mixtas.

No estructuradas.

Orientadas a objetos.
Sistemas de tiempo real.

4
Metodologas estructuradas.

Se basan en la forma top-Down.

Metodologia orientada a procesos.

La ingeniera del software se basa en el modelo bsico de entrada/proceso/salida de un sistema. Est

compuesta por:

Diagrama de flujo de datos (DFD).

Diccionario de datos.
Especificacin de proceso.

Metodologas no estructuradas.

Metodologas orientadas a objeto.

La orientacin a objetos unifica procesos y datos encapsulndolos en el concepto de objetos.

Tiene dos enfoques distintos:

Revolucionario, puro u ortodoxo. Rompen con las metodologas tradicionales.

Ejemplos: Metodologas OOD de Booch, CRC/RDD de Wirfs-Brock.
Sintetiza o evolutivo. Toman como base los sistemas estructurados y conforman elementos de
uno u otro tipo.

Ejemplos: Metodologia OMT de Rumbourgh.

El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960 para
desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes conglomerados
empresariales. La idea principal era continuar el desarrollo de los sistemas de informacin en una muy
deliberada, estructurada y metdica, reiterando cada una de las etapas del ciclo de vida. Los sistemas
de informacin en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas
de clculo.

1970s.

Programacin estructurada desde 1969.

Programacin estructurada Jackson desde 1975.

5
1980s.

Structured Systems Analysis and Design Methodology (SSADM) desde 1980.

Structured Analysis and Design Technique (SADT) desde 1980.

Ingenieria de la informaicon (IE/IEM) desde 1981.

1990s.

Rapid application development (RAD) desde 1991.

Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90s.

Virtual finite state machine (VFSM) desde 1990s.

Dynamic Systems Development Method desarrollado en UK desde 1995.

Scrum (Desarrollo), en la ltima parte de los 90s.

Nuevo milenio.

Programacin extrema desde 1999.

Enterprise Unified Process (EUP) extensiones RUP desde 2002.

Rational Unified Process (RUP) desde 2003.

Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thrisson. Agile
Unified Process (AUP) desde 2005 por Scott Ambler.

Modelo en cascada.

En ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada, es el enfoque

metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal
forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.

6
 Diseo del programa.
Codificacin.
Pruebas.
Implantacin.
Mantenimiento.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al
rediseo y nueva programacin del codigo afectado, aumentando los costos del desarrollo. La palabra
cascada sugiere, mediante la metfora de la fuerza de la gravedad, es el esfuerzo necesario para
introducir un cambio en las fases ms avanzadas de un proyecto.

Si bin ha sido ampliamente criticado desde el mbito acadmico y la industria sigue siendo el
paradigma ms seguido al da de hoy.

Ilustracin 1 Estructura del modelo en cascada.

Este modelo utiliza tramos como puntos de transicin y de carga. Al usar el modelo de cascada, se
necesitara completar un conjunto de tareas en forma de fase para despus continuar con la fase
proxima. El modelo en cascada trabaja perfectamente para los proyectos en los cuales los requisitos
del proyecto se encuentran definidos claramente y no son obligados a futuras modificaciones. Ya que
este modelo est compuesto por puntos de transicion entre fases, se puede monitorear fcilmente ya
que asigna responsabilidades definidas.

Requerimiento

7
El analista debe comprender el mbito del software el proceso de los datos, el rendimiento y las
interfaces requeridas.

Diseo

El diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos,
la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz.

Implementacion

Una ves diseado el software en todos los aspectos mencionados se debe pasar a traducir este diseo
a lenguaje mquina, sta tarea ser ms fcil de realizar si se hizo un buen diseo.

Verificacin

Es recomendable que sta etapa la realice el usuario ya que ste debe constatar si al ingresar los datos
establecidos al sistema, ste arroja el resultado esperado.

MANTENIMIENTO

Una vez entregado el sistema al cliente, el sistema sufrir pequeos cambios por peticin del cliente
como puede ser agregar pequeos mdulos, optimizar y obtener ms rendimiento, etc.

VENTAJAS

Se tiene todo bien organizado y no se mezclan las fases.

Es perfecto para proyectos que son rgidos, y adems donde se especifiquen muy bien los
requerimientos y se conozca muy bien la herramienta a utilizar.

DESVENTAJAS

Un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del
modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de
prueba y hasta que el software no est completo no se opera

8
Modelo basado en prototipos.

El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo evolutivo.

El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe
utilizar muchos recursos.

El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles
para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es
evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software
que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades
del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y
el cliente vea resultados a corto plazo.

Seleccin del modelo de prototipo.

Este modelo es recomendado cuando.

Los requerimientos no son conocidos al principio.

Coloca nfasis en la etapa de especificacin de requerimientos a travs de la construccin de

prototipos que aproximan al usuario a la idea final del sistema con el propsito de poder clarificar los
requerimientos.

Los usuarios lo prueban y aaden requerimientos. Se hace una implementacin parcial del
sistema y se prueba.

Se utiliza en sistemas complejos.

Etapas.

Plan rapido.
Modelado, diseo rpido.
Desarrollo, entrega y retroalimentacin.
Comunicacin.

9
 Entrega del desarrollo final.

Ilustracin 2 Estructura del modelo basado en prototipos.

La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se

emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de
cualquiera de los modelos del proceso expuestos. Sin importar la forma en que ste se aplique, el
paradigma de construccin de prototipos ayuda al desarrollador de software y al cliente a entender
de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos. De
esta manera, este ciclo de vida en particular, involucra al cliente ms profundamente para adquirir el
producto.

Ventajas

Reduccin de la incertidumbre y del riesgo, reduccin del tiempo y de costos, incrementos en la

aceptacin del nuevo sistema, mejoras en la administracin de proyectos, mejoras en la comunicacin
entre desarrolladores y clientes.

Desventajas

La dependencia de las herramientas de software para el xito ya que la necesidad de disminucin de

incertidumbre depende de las iteraciones del prototipo, entre ms iteraciones existan mejor y esto
ltimo se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente de
las mismas.

10
Modelo incremental.

En trminos generales, se puede distinguir, en la Figura 4, los pasos generales que sigue el proceso de
desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se identifican
claramente dichos pasos. La descripcin del sistema es esencial para especificar y confeccionar los
distintos incrementos hasta llegar al producto global y final. Las actividades concurrentes
(especificacin, desarrollo y validacin) sintetizan el desarrollo pormenorizado de los incrementos, que
se har posteriormente.

Ilustracin 3Diagrama genrico del desarrollo evolutivo incremental.

El incremental es un modelo de tipo evolutivo que est basado en varios ciclos Cascada Realimentados
aplicados repetidamente, con una filosofa iterativa. En la Figura 5 se muestra un refino del diagrama
previo, bajo un esquema temporal, para obtener finalmente el esquema del modelo de ciclo de vida
Iterativo Incremental, con sus actividades genricas asociadas. Aqu se observa claramente cada ciclo
cascada que es aplicado para la obtencin de un incremento; estos ltimos se van integrando para
obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por
simplicidad, en la Figura 5 se muestra como secuencial puro.

11
 Ilustracin 4 Modelo iterativo incremental para el ciclo de vida del software.

Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo
o concurrentemente, as por ejemplo, en la Figura, mientras se realiza el diseo detalle del primer
incremento ya se est realizando en anlisis del segundo. La Figura 5 es slo esquemtica, un
incremento no necesariamente se iniciar durante la fase de diseo del anterior, puede ser posterior
(incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de
operacin y mantenimiento (indicada como Operacin en la figura), que es donde se produce la
entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de
varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos
totalmente independientes pueden ser fcilmente iniciados al mismo tiempo si se dispone de personal
suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc.

Bajo este modelo se entrega software por partes funcionales ms pequeas, pero reutilizables,
llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.6

Como se muestra en la Figura 5, se aplican secuencias Cascada en forma escalonada, mientras progresa
el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer
incremento es un sistema bsico, con muchas funciones suplementarias (conocidas o no) sin entregar.

El cliente utiliza inicialmente ese sistema bsico, intertanto, el resultado de su uso y evaluacin puede
aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Adems tambin

12
aportan a ese plan otros factores, como lo es la priorizacin (mayor o menor urgencia en la necesidad
de cada incremento en particular) y la dependencia entre incrementos (o independencia).

Luego de cada integracin se entrega un producto con mayor funcionalidad que el previo. El proceso
se repite hasta alcanzar el software final completo.

Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente
operacional en cada incremento, y no una parte que sea usada para reajustar los requisitos (como si
ocurre en el modelo de construccin de prototipos).

El enfoque incremental resulta muy til cuando se dispone de baja dotacin de personal para el
desarrollo; tambin si no hay disponible fecha lmite del proyecto por lo que se entregan versiones
incompletas pero que proporcionan al usuario funcionalidad bsica (y cada vez mayor). Tambin es un
modelo til a los fines de versiones de evaluacin.

Nota: Puede ser considerado y til, en cualquier momento o incremento incorporar temporalmente el
paradigma MCP como complemento, teniendo as una mixtura de modelos que mejoran el esquema
y desarrollo general.

El proceso se divide en 4 partes:

Anlisis
Diseo
Cdigo
Prueba

Ventajas

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa

la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes
operativas del Software.
El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo
sus desventajas slo al mbito de cada incremento.
Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada.
Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.
Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como
tcnico.

13
Desventajas

El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto

nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.

Modelo en espiral.

El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la
naturaleza iterativa del modelo MCP con los aspectos controlados y sistemticos del Modelo Cascada.
Proporciona potencial para desarrollo rpido de versiones incrementales. En el modelo Espiral el
software se construye en una serie de versiones incrementales. En las primeras iteraciones la versin
incremental podra ser un modelo en papel o bien un prototipo. En las ltimas iteraciones se producen
versiones cada vez ms completas del sistema diseado.

El modelo se divide en un nmero de Actividades de marco de trabajo, llamadas regiones de tareas.

En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la Figura 6 se
muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del
modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado ms reciente.

14
 Ilustracin 5 Modelo espiral para el ciclo de vida del software.

Las regiones definidas en el modelo de la figura son:

Regin 1 - Tareas requeridas para establecer la comunicacin entre el cliente y el

desarrollador.

Regin 2 - Tareas inherentes a la definicin de los recursos, tiempo y otra informacin

relacionada con el proyecto.

Regin 3 - Tareas necesarias para evaluar los riesgos tcnicos y de gestin del proyecto.

Regin 4 - Tareas para construir una o ms representaciones de la aplicacin software.

Regin 5 - Tareas para construir la aplicacin, instalarla, probarla y proporcionar soporte al

usuario o cliente (Ej. documentacin y prctica).

Regin 6 - Tareas para obtener la reaccin del cliente, segn la evaluacin de lo creado e
instalado en los ciclos anteriores.

15
1. Determinar o fijar los objetivos.

En este paso se definen los objetivos especficos para posteriormente identifica las

Limitaciones del proceso y del sistema de software, adems se disea una

Planificacin detallada de gestin y se identifican los riesgos.

2. Anlisis del riesgo.

En este paso se efecta un anlisis detallado para cada uno de los riesgos

Identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y

Luego del anlisis de estos riesgos se planean estrategias alternativas.

3. Desarrollar, verificar y validar.

En este tercer paso, despus del anlisis de riesgo, se eligen un paradigma para el

desarrollo del sistema de software y se lo desarrolla.

4. Planificar.

En este ltimo paso es donde el proyecto se revisa y se toma la decisin si se debe

continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan

los planes para la siguiente fase del proyecto.Las actividades enunciadas para el marco de trabajo son
generales y se aplican a cualquier proyecto, grande, mediano o pequeo, complejo o no. Las regiones
que definen esas actividades comprenden un conjunto de tareas del trabajo: ese conjunto s se debe
adaptar a las caractersticas del proyecto en particular a emprender. Ntese que lo listado en los tems
de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo
en s.

Proyectos pequeos requieren baja cantidad de tareas y tambin de formalidad. En proyectos mayores
o crticos cada regin de tareas contiene labores de ms alto nivel de formalidad. En cualquier caso se
aplican actividades de proteccin (por ejemplo, gestin de configuracin del software, garanta de
calidad, etc.).

16
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniera gira alrededor del espiral
(metafricamente hablando) comenzando por el centro (marcado con en la Figura 6) y en el sentido
indicado; el primer circuito de la espiral puede producir el desarrollo de una especificacin del
producto; los pasos siguientes podran generar un prototipo y progresivamente versiones ms
sofisticadas del software.

Cada paso por la regin de planificacin provoca ajustes en el plan del proyecto; el coste y planificacin
se realimentan en funcin de la evaluacin del cliente. El gestor de proyectos debe ajustar el nmero
de iteraciones requeridas para completar el desarrollo.

El modelo espiral puede ir adaptndose y aplicarse a lo largo de todo el Ciclo de vida del software (en
el modelo clsico, o cascada, el proceso termina a la entrega del software).

Una visin alternativa del modelo puede observarse examinando el eje de punto de entrada de
proyectos. Cada uno de los circulitos () fijados a lo largo del eje representan puntos de arranque de
los distintos proyectos (relacionados); a saber:

Un proyecto de desarrollo de conceptos comienza al inicio de la espiral, hace mltiples

iteraciones hasta que se completa, es la zona marcada con verde.

Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: Desarrollo de

nuevo Producto. Que evolucionar con iteraciones hasta culminar; es la zona marcada en color azul.

Eventual y anlogamente se generarn proyectos de mejoras de productos y de

mantenimiento de productos, con las iteraciones necesarias en cada rea (zonas roja y gris,
respectivamente).

Cuando la espiral se caracteriza de esta forma, est operativa hasta que el software se retira,
eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso
arranca nuevamente en el punto de entrada apropiado (por ejemplo, en mejora del producto).

El modelo espiral da un enfoque realista, que evoluciona igual que el software;11 se adapta muy bien
para desarrollos a gran escala.

El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolucin.
Mantiene el enfoque clsico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor
la realidad.

17
Este modelo requiere considerar riesgos tcnicos en todas las etapas del proyecto; aplicado
adecuadamente debe reducirlos antes de que sean un verdadero problema.

El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos
(complejos); tambin en sistemas de altos riesgos o crticos (Ej. navegadores y controladores
aeronuticos) y en todos aquellos en que sea necesaria una fuerte gestin del proyecto y sus riesgos,
tcnicos o de gestin.

VENTAJAS DEL MODELO ESPIRAL

No requiere una definicin completa de los requerimientos del software a desarrollar

para comenzar su funcionalidad.
En la terminacin de un producto desde el final de la primera iteracin es muy factible
aprobar los requisitos.
Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos
presentados tempranamente y existe la forma de poder corregirlos a tiempo.

DESVENTAJAS DEL MODELO ESPIRAL

Existe complicacin cuando se evala los riesgos.

Se requiere la participacin continua por parte del cliente.
Se pierde tiempo al volver producir inicialmente una especificacin completa de los
requerimientos cuando se modifica o mejora el software.

Desarrollo rapido de aplicaciones (RAD).

El desarrollo rpido de aplicaciones o RAD (acrnimo en ingls derapid application development) es

un proceso de desarrollo de software, desarrollado inicialmente por James Maslow en 1980. El mtodo
comprende el desarrollo interactivo, la construccin de prototipos y el uso de utilidades CASE
(Computer Aided Software Engineering). Tradicionalmente, el desarrollo rpido de aplicaciones tiende
a englobar tambin la usabilidad, utilidad y la rapidez de ejecucin.1 2

Hoy en da se suele utilizar para referirnos al desarrollo rpido de interfaces grficas de usuario tales
como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas ms conocidas
son Visual

18
Studio, Lazarus, Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo o Clarion. En el rea de la
autora multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen
plataformas de desarrollo rpido de aplicaciones, dentro de ciertos lmites.

Ilustracin 6 Modelo para el desarrollo rpido de aplicaciones.

El DRA comprende las siguientes etapas:

Modelado de Gestin: aqu se modela el flujo de informacin entre las funciones de gestin. Este flujo
debe "responder" a preguntas tales como Qu informacin conduce el proceso de gestin?, Quin
la genera?, A dnde va la informacin?, Quin la procesa?

Modelado de datos: se definen las caractersticas (atributos) de cada objeto, formado a partir del flujo
de informacin, y las relaciones entre ellos.

Modelado del proceso: las descripciones del proceso se crean para aadir, modificar, suprimir o
recuperar un objeto de datos.

Generacin de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de programas

ya existentes o crea componentes reutilizables.

Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y probados, lo
cual permite que el tiempo de duracin de las pruebas sea menor. Todo esto no impide que se tenga
que probar cada uno de los nuevos componentes.

Desventajas

19
 Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el
nmero suficiente de equipos.
Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el
tiempo necesario.
No es adecuado cuando los riesgos tcnicos son muy alto.

Ventajas

Comprar puede ahorrar dinero en comparacin con construir.

Los entregables pueden ser fcilmente trasladados a otra plataforma.
El desarrollo se realiza a un nivel de abstraccin mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor codificacin manual.
Mayor involucramiento de los usuarios.
Posiblemente menos fallas.
Posiblemente menor costo.
Ciclos de desarrollo ms pequeos.
Interfaz grfica estndar.

Modelo RUP.

El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente resumido como
RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software,
actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la
metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de
sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un
conjunto de metodologas adaptables al contexto y necesidades de cada organizacin.

Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que incluye
informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est
incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo con las
necesidades.

20
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una
especificacin ms detallada, el Rational Unified Process, que se vendiera como producto
independiente.

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado
en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles
del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que
desempea una persona en un determinado momento, una persona puede desempear distintos
roles a lo largo del proceso).

Principales caractersticas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

Faces de la metodologa RUP.

Fase de concepcin

Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores,
identificar los riesgos potenciales asociados al proyecto, proponer una visin muy general de la
arquitectura de software y producir el plan de las fases y el de iteraciones.

Fase de elaboracin

En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del
sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y
el primer anlisis del dominio del problema, se disea la solucin preliminar.

21
Fase de construccin

El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los
requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los
usuarios y se realizan las mejoras para el proyecto.

Fase de transicin

El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar
los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el
soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones
entregadas por las personas involucradas en el proyecto.

Ilustracin 7Fases e interacciones de la Metodologa RUP

Programacin extrema (XP).

La Metodologia consiste en una programacin rpida o extrema cuya particularidad es tener como
parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.

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.

22
Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a
los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms
realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus
en controlar los cambios en los requisitos.

Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de

desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera
dinmica durante el ciclo de vida del software.

Ilustracin 8 Estructura de la Metodologa XP.

Scrum

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prcticaspara

trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas
prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de
equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que
aportan al receptor del proyecto. Por ello, Scrum est especialmente indicado para proyectos en
entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovacin, la competitividad, laflexibilidad y la productividad
son fundamentales.

23
Scrum tambin se utiliza para resolver situaciones en que no se est entregando al cliente lo que
necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable,
cuando se necesita capacidad de reaccin ante la competencia, cuando la moral de los equipos es baja
y la rotacin alta, cuando es necesario identificar y solucionar ineficiencias sistemticamente o cuando
se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

Ver en detalle cuales son los beneficios de Scrum, sus fundamentos y sus requisitos.

El proceso

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural
y hasta de dos semanas, si as se necesita). Cada iteracin tiene que proporcionar un resultado
completo, un incremento de producto final que sea susceptible de ser entregado con el mnimo
esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que acta como plan del
proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a
su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar
la utilidad de lo que se desarrolla y el retorno de inversinmediante la replanificacin de objetivos del
producto, que realiza durante la iteracin con vista a las siguientes iteraciones.

Las actividades que se llevan a cabo en Scrum son las siguientes:

Planificacin de la iteracin

El primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene dos partes:

1. Seleccin de requisitos (4 horas mximo). El cliente presenta al equipo la lista de requisitos

priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los
requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser
entregados si el cliente lo solicita.

2. Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de tareas de la iteracin

necesarias para desarrollar los requisitos a que se ha comprometido. La estimacin de esfuerzo se
hace de manera conjunta y los miembros del equipo se autoasignan las tareas.

24
Ejecucin de la iteracin

Cada da el equipo realiza una reunin de sincronizacin (15 minutos mximo). Cada miembro del
equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia
el objetivo de la iteracin, obstculos que pueden impedir este objetivo) para poder hacer las
adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunin cada
miembro del equipo responde a tres preguntas:

Qu he hecho desde la ltima reunin de sincronizacin?

Qu voy a hacer a partir de este momento?

Qu impedimentos tengo o voy a tener?

Durante la iteracin el Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su
compromiso y de que no se merme su productividad.

Elimina los obstculos que el equipo no puede resolver por s mismo.

Protege al equipo de interrupciones externas que puedan afectar su compromiso o su

productividad.

Inspeccin y adaptacin

El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes:

1. Demostracin (4 horas mximo). El equipo presenta al cliente los requisitos completados en la

iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo.
En funcin de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto,
el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteracin,
replanificando el proyecto.

2. Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera de trabajar y cules
son los problemas que podran impedirle progresar adecuadamente, mejorando de manera continua
su productividad. El Facilitador se encargar de ir eliminando los obstculos identificado.

25
 Ilustracin 9 estructura scrum

Las ventajas

El proceso de Sprint permite "lo suficientemente bueno" el desarrollo que se traduce en un producto
vendible, incluso mientras el proyecto est en plena marcha. Este sistema de entrega incremental
acorta el tiempo de comercializacin y puede dar lugar a mayores ingresos, ya que cada cartera
completada representa una nueva versin del producto. Adems, la revisin de cada sprint antes de
pasar al siguiente significa que la prueba se lleva a cabo durante todo el proceso, lo que permite a los
equipos para cambiar el alcance o la direccin del proyecto en cualquier momento. Aunque el plazo y
el presupuesto son variables fijas, los requisitos del proyecto no lo son. De hecho, las partes
interesadas y participantes anticipan cambios en el camino. La participacin del propietario del
producto en el proceso de gestin de proyectos facilita estos cambio.

Desventajas

Puede ser difcil para el maestro Scrum para planificar, estructurar y organizar un proyecto que carece
de una definicin clara. Adems, los cambios frecuentes, la entrega del producto frecuente y la
incertidumbre en cuanto a la naturaleza precisa del producto terminado para hacer un ciclo de vida de
un proyecto bastante intenso para todos los involucrados. Por otra parte, las reuniones diarias de
Scrum y revisiones frecuentes requieren recursos sustanciales. Un proyecto exitoso depende de la
madurez y la dedicacin de todos los participantes, y su capacidad para mantener constantemente
altos niveles de comunicacin a travs de cada cartera y revisin.

26
CMMI

CMMI Modelo desarrollado por el SEI que sirve como gua para la implementacin de prcticas para
mejorar los procesos de las organizaciones. A partir de la versin 1.2, publicada en Agosto del 2006, se
crean las constelaciones: coleccin de componentes utilizados para construir modelos, materiales de
capacitacin y evaluacin en un rea de inters. Hasta la fecha existen tres constelaciones publicadas:

CMMI-DEV (Development) sirve como gua para medir, monitorear y administrar el proceso de
desarrollo y mantenimiento de productos y servicios.

CMMI-ACQ (Acquisition) sirve como gua para mejorar el proceso de adquisicin de productos y
servicios.

CMMI-SVC (Services) sirve como gua para gua para proporcionar servicios internos en una
organizacin y a clientes externos.

El modelo es ampliamente utilizado a nivel mundial y es reconocido como un estndar de facto en la

industria, principalmente de TI. Los modelos se pueden obtener de manera gratuita en
www.sei.cmu.edu/cmmi

COBIT: Conjunto de mejores prcticas para la tecnologa de la informacin (TI) creada por ISACA con
ITGI en 1996. Ofrece a los gerentes, auditores, y usuarios de TI un conjunto de medidas generalmente
aceptadas, indicadores, procesos y mejores prcticas para ayudarles a maximizar los beneficios
procedentes de la utilizacin de tecnologa de la informacin y el desarrollo adecuado del Gobierno de
TI y control en una empresa.

La versin actual 4.1 fue liberada en mayo del 2007. Ha sido utilizado principalmente por la comunidad
de TI, y se ha convertido en el marco internacionalmente aceptado para el gobierno y control. ISO /
IEC 27002:2007 (El Cdigo de Prcticas para la Gestin de Seguridad de la Informacin) tambin es una
norma internacional y es la mejor prctica para la aplicacin de gestin de la seguridad. Mayor
informacin en www.isaca.org

COSMIC: Mtodo de medicin de tamao funcional basado en los principios de ingeniera y en la

experiencia de los participantes, apegado a ISO/IEC 14143/1 Information Technology Software.

27
Metodologa Moprosoft

Es un modelo para la mejora y evaluacin de los procesos de desarrollo y mantenimiento de sistemas

y productos e software.

Desarrollado por la Asociacion Mexicana para la Calidad en Ingenieria de Software. Facultad de

Ciencias de la Universidad Autonoma de Mexico, a solicitud de la secretaria de economia con el fin de
obtener una norma apropiada a las caracteristicas de tamao de la gran mayoria de empresas
mexicanas de desarrollo y mantenimiento de software.

MOPROSOTF es el nombre del modelo en la comunidad universitaria y profesional , y a la norma

tecnica a la que da contenido es la NMX-059/01-NYCE-2005.

Considera que los modelos de evaluacion y mejora CMMI e ISO/IEC 15504 no resultan apropiados para
pequeas y medianas empresas de desarrollo y mantenimiento de software. Este modelo se desarrollo
sobre las areas de procesos delos niveles 2 y 3 del modelo SW-CMM e inspirandose en el marco de
ISO/IEC 15504.

Ventajas

Entre las ventajas a destacar de este modelo podemos mencionar la mejora la productividad de las
personas, mejora en los hbitos de programacin, se puede lograr una deteccin temprana de
defectos y riesgos lo que deriva en una disminucin de los defectos, una mejora en la calidad, y por lo
tanto, una reduccin en el ciclo de vida. Se trabaja con un plan con una base de estimacin mas certera
al ser realizada por el equipo; se logra una buena comunicacin entre los integrantes.

Desventajas

Las desventajas de este modelo es que es necesario que cada uno de los miembros tiene que tener el
compromiso y la disciplina de seguir el plan. Debe de llenar toda la documentacin requerida que
incluye sus registros, planificacin, las plantillas o formularios. Se debe de contar con un buen conjunto
de mtricas y parmetros de calidad, lo cual, para algunas organizaciones, puede ser difcil de definir.
Cada miembro debe de estar entrenado en el PSP, si algn miembro se va, es necesario entrenar a los
nuevos miembros. Algo que puede resultar una desventaja importante es que la Gerencia debe de
dejar trabajar a los equipos de trabajo autodirigidos de acuerdo a sus planes, algo que no muchos
resisten.

28
Caractersticas de MoProSoft

Es especfico para el desarrollo y mantenimiento de software.

Es sencillo de entender y adoptar.
Facilita el cumplimiento de los requisitos de otros modelos como ISO 9000:2000, CMM y
CMMI.
Se enfoca a procesos.
Se le considera prctico en su aplicacin, principalmente en organizaciones pequeas, con
bajos niveles de madurez.
Comprende un documento de menos de 200 pginas que, al compararlo con otros modelos y
estndares, lo hace bastante prctico.
Resulta acorde con la estructura de las organizaciones mexicanas de la industria de software.
Est orientado a mejorar los procesos, para contribuir a los objetivos de negocio, y no
simplemente ser un marco de referencia o certificacin.
Tiene un bajo costo, tanto para su adopcin como para su evaluacin.

Ilustracin 10 estructura moprosoft Scrum

29
Agil MSF (Microsoft Solution FrameWork).

La metodologua MSF es del tipode metodologas agiles, esta enfocada a dirigir proyectos o soluciones
de innovacin, en ella no se detalla ni se hace nfasis de la organizacin ni el tamao del equipo de
desarrollo, esta mas bin centrada en la gestin y administracin del proyecto para lograr el impacto
deseado.

Involucra indudablemente la calidad ya que prevee liberar una solucin si esta aun tiene fallos o
desperfectos para ello propone seleccionar un grupo de prueba piloto el cual es una versin beta y
cumplido un tiempo de prueba ya es liberada la versin formal o VERSIN ALFA en la cual est
garantizada la calidad.

Ilustracin 11 caractersticas del msf

Visin: En esta fase se debe realizar un estudio de lo que pretendemos en el futuro que haga nuestra
aplicacin o nuestro proyecto para ello debemos realizar un documento de estrategia y alcance donde
debe quedar pactada la necesidad de funcionalidad y servicio que se debe contar en la solucin.
Debemos crear los equipos de trabajo junto con el plan de trabajo, Para asegurar el xito del proyecto
es importante tener en cuenta el anlisis de riesgos y plan de contingencia.

Planificacin: En esta fase bsicamente debemos concretar claramente cmo va a estar estructurada
nuestra solucin para ello debemos crear un documento de planificacin y diseo de la arquitectura,
30
disear las pruebas de concepto donde se plantean los diferentes escenarios para probar la validez de
los criterios utilizados para el diseo, debemos establecer mtricas.

Desarrollo: En la etapa de desarrollo debemos codificar las aplicaciones y realizar las configuraciones
necesarias para que la solucin funcione, es importante hacer pruebas continuamente as se verifica
la calidad del producto continuamente a lo largo del desarrollo y no nicamente al final del proceso.

Estabilizacin: Esta fase debemos seleccionar el entorno de prueba piloto y lo que pretendemos con
esto es identificar las deficiencias con un grupo reducido de usuarios para corregirlas y as en el futuro
no tener problemas cuando se use la solucin por todos, ocasionalmente a esta etapa se le llama BETA,
debemos crear un plan de gestin de incidencias, realizar una revisin de documentacin final de la
arquitectura y Elaboracin de plan de despliegue o implementacin.

Despliegue o Implementacin: En esta etapa final ya se ha comprobado la calidad de la solucin por lo

cual est lista para ser publicada, en este sentido debemos liberar la solucin y crear un registro de
mejoras y sugerencias, revisar las guas y manuales y entrega de proyecto final.

Este ciclo se puede llevar a cabo de forma iterativa, de manera que cuando liberamos una solucin
podemos iniciar nuevamente la Metodologia para darle ms funcionalidad.

Ilustracin 12 msf

Caractersticas del MSF.

MSF, tiene las siguientes caractersticas:

Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso
es limitado a un especfico lugar.

31
 Escalable: Puede organizar equipo tan pequeo entre 3 o 4 personas, asi como tambin
proyectos que requieren 50 personas a ms.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnologa Agnstica: Porque puede ser usada para desarrollar solucione basadas sobre
cualquier tecnologa.

Modelos de planificacin en MSF.

MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el
desarrollo de un proyecto: Modelo de Arquitectura del proyecto, modelo de equipo, modelo de
proceso, modelo de gestin del riesgo, modelo de diseo de proceso y finalmente el modelo de la
aplicacin.

Modelo de arquitectura del proyecto.

Diseado para acortar la planificacin del ciclo de vida. Este modelo define las pautas para construir
proyectos empresariales a travs del lanzamiento de versiones.

Modelo de equipo.

Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una
estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del
tamao del proyecto y del equipo de personas disponibles.

Modelo de proceso: Diseado para mejorar el control del proyecto, minimizando el riesgo, y aumentar
la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo
de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su
relacin con el modelo de equipo.

Otros enfoques de desarrollo de software.

Metodologias de desarrollo orientado a objetos, diseo orientado a objetos (OOD) de Grady Booch,
tambin conocido como, Analisis diseo orientado a objetos (OOAD). El modelo incluye seis
diagramas: de clase, objeto, estado de transicin, la interaccin, modulos y el proceso.

32
Proceso Unificado, es una metodologia de desarrollo de software, basad en UML. Organiza el
desarrollo de software en cuatro fases, cada una de ellas con la ejecucin de una o ms iteraciones de
desarrollo de softwar: Creacion, elaboracion, Constuccin, y las directrices. Hay una serie de
herramientas y productos diseados para facilitar la aplicacin. Una de las versiones ms populares es
la de Rational Unified Process.

Unidad II. Administracin de requerimientos.

Estudio de factibilidad.

Estudio de factibilidad tambin conocido como estudio de viabilidad, es el anlisis amplio de los
resultaos financieros, econmicos y sociales de una inversin (dada una opcin tecnolgica estudio
de pre-factibilidad). En la fase de pre-inversin la eventual etapa subsiguiente es el diseo final del
proyecto (preparacin del documento de proyecto), tomando en cuenta los insumos de un proceso
productivo, que tradicionalmente son: Tierra, trabajo y capital (que genera ingreso, renta, salario y
ganancia).

Factibilidad Tcnica.

La factibilidad tcnica consiste en realizar una evaluacin de la tecnologa existente en la organizacin,

este estudio estuvo destinado a recolectar informacin sobre los componentes tcnicos que posee la
organizacin y la posibilidad de hacer uso de los mismos en el desarrollo e implementacin del sistema
propuesto y de ser necesario, los requerimientos tecnolgicos que deben ser adquiridos para el
desarrollo y puesta en marcha del sistema en cuestin.

De acuerdo a la tecnologa necesaria para la implementacin del sistema de seguridad y control de las
investigaciones cientficas de la universidad de Carabobo, se evalu bajo do enfoques: Hardware y
software.

En cuanto a hardware, especficamente el servidor donde debe estar instalado el sistema propuesto,
este debe cubrir con los siguientes requerimientos mnimos.

Procesador Pentium 166Mhz.

Tarjeta Madre.
64 MB de Memoria RAM.
Disco duro de 5 GB.
Unidad de disco 31/2.
Unidad de CD-ROM-
Tarjeta de Red.
Tarjeta de Video.

33
 Monitor SVGA.
Mouse.
Unidad de proteccin UPS.

Evaluando el hardware existente y tomando en cuenta la configuracin mnima necesaria, la

institucin no requiri realizar inversin inicial para la adquisicin de nuevos equipos, ni tampoco para
repotenciar o actualizar los equipos existente, ya que los mismos satisfacen los requerimientos
establecidos tanto para el desarrollo y puesta en funcionamiento del sistema propuesto, adems hay
que agregar que estos componentes se encuentran en el mercado actualmente a unos precios bajos.

En el siguiente cuadro se muestra la descripcin del hardware disponible en la Organizacin y que fue
utilizado para el diseo, construccin y puesta en marcha del sistema REDAIC.

34
 Ilustracin 131. Ejemplo de factibilidad operativa.

Por caractersticas fsicas de la red de investigacin cientfica de la universidad, cada centro o instituto
debe contar con una red interna; que permita la interconexin de todos los componentes y/o usuarios
de estos centros e instituciones con la Red Acadmica de Informacin Cientfica REDAIC,
aprovechando para ello el Backbone o Red Dorsal de Fibra ptica de Universidad. Para aquellos Centros
y/o instituciones de la red de investigacin, que por su ubicacin geogrfica no pueden hacer uso de
la Red Troncal para interconectarse a la Red Acadmica, se prev realizar la interconexin va radio
enlace o por medio de una conexin telefnica.

Las caractersticas de re interna que cuenta actualmente cada centro o institucin, se detallan a
continuacin.

35
Servidor: Equipo con procesador Pentium II, de 300 MHz de velocidad, 64 MB de Memoria RAM, Disco
duro de 4.3 GB, Tarjeta de red.

Conectadores de puertos RJ-45.

Todas las estaciones de trabajo estn conectadas al servidor a travs de una red de topologa estrella,
utilizando cable par trenzado sin apantallamiento UTP, de la categora nmero (5), segn las normas
internacionales del instituto de Ingenieros Elctricos y Electrnicos IEEE.

El servidor cumple las funciones de puerta de enlace entre estos y el resto de la red interna de la
universidad de Carabobo y por ende, a internet.

Esta configuracin permite que los equipos instalados en los centros e institutos, interacten con el
sistema REDAIC, Adems cualquier persona que tenga una conexin a internet, puede desde cualquier
punto acceder a los servicios que el sistema ofrece a los usuarios.

Software.

En cuanto al software, la institucin cuenta con todas las aplicaciones que emplearon para el desarrollo
del proyecto y funcionamiento del sistema, lo cual no amerita inversin alguna para la adquisicin de
los mismos. Las estaciones de trabajo, operan bajo ambiente Windows, el servidor requiere el sistema
operativo Linux, el cual es una variante de Unix, y como plataforma de desarrollo de software
WWWSIS. Para el uso general de las estaciones en actividades diversas debe de poseer las
herramientas de escritorio y los navegadores que existen en el mercado actualmente.

Ilustracin 14 Factibilidad Operativa II.

Como resultado de este estudio se determin que en los actuales momentos, la institucin posee la
infraestructura tecnolgica (Hardware y Software) necesaria para el desarrollo y puesta en
funcionamiento el sistema propuesto.

36
Factibilidad Econmica.

A continuacin se presenta un estudio que dio como resultado la factibilidad econmica del desarrollo
del nuevo sistema de informacin. Se determinaron los recursos para desarrollar, implantar y
mantener en operacin el sistema programado, haciendo una evaluacin donde se puso de manifiesto
el equilibrio existente entre los costos intrnsecos del sistema y los beneficios que se derivaron de este,
lo cual permiti observar de una manera ms precisa las bondades de sistema propuesto.

Anlisis costos Beneficios.

Este anlisis permiti hacer una comparacin entre la relacin costos del sistema actual, y los costos
que tendra un nuevo sistema, conociendo de antemano los beneficios que la ciencia de la informtica
ofrece.

Como se mencion anteriormente en el estudio de factibilidad tcnica, la organizacin contaba con

las herramientas necesarias para la puesta en marcha del sistema, por lo cual el desarrollo de la
propuesta no requiri de una inversin inicial.

A continuacin se presenta un resumen de los costos intrnsecos de sistema propuesto y una lista de
los costos que conlleva implantar el mismo, y los costos de operacin. Luego a travs de un anlisis de
valor se determinaron los beneficios que no necesariamente para el nuevo sistema son monetarios o
cuantificables.

El resumen del anlisis costos. Beneficios se definieron a travs de una comparacin de los costos
implcitos, tanto del sistema actual como del propuesto y su relacin con los beneficios expresados en
forma tangible.

37
Ilustracin 15 Costo del sistema actual.

Ilustracin 16 Costo del personal.

38
Costo del sistema propuesto:

El sistema de informacin automatizado para el seguimiento y control de las investigaciones

Cientficas de la Universidad de Carabobo, REDAICUC, involucra los siguientes costos.

Costos generales.

Al lograr optimizar los procesos, agilizando el flujo y manejo de la informacin de las actividades de
seguimiento y control de las investigaciones cientficas de la universidad de Carabobo, no es
necesario la ejecucin de mltiples actividades y tareas para a alcanzar los resultados esperados,
aunado a que las solicitudes de subvencin pueden realizarse de forma automatizada, lo que se
traduce en un ahorro de accesorios y material de oficina de uso diario.

Ilustracin 17 Costo de papelera

39
Ilustracin 18 Seguimiento.

40
Ilustracin 19 Salario del personal.

41
Ilustracin 20 Costo benfico del sistema propuesto y el sistema actual.

42
Factibilidad Operativa.

La factibilidad operativa permite predecir, si se pondr en marcha el sistema propuesto, aprovechando

los beneficios que ofrece, a todos los usuarios involucrados con el mismo, ya sean los que interactan
en forma directa con este, como tambin aquellos que reciben informacin producida por el sistema.
Por otra parte, el correcto funcionamiento del sistema en cuestin, siempre estar supedito a la
capacidad de los empleados encargados de dicha tarea.

Ilustracin 21 Factibilidad Operativa.

43
Obtencin y anlisis de requerimientos.

La siguiente etapa del proceso de ingeniera de requerimientos es la obtencin y anlisis de

requerimientos. En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios
finales del sistema para determinar el dominio de la aplicacin, que servicios deben proporcionar el
sistema, el rendimiento requerido del sistema, las restricciones hardware.

La obtencin y anlisis de requerimientos pueden afectar a varias personas de la organizacin. El

termino stakeholder se utiliza para referirse a cualquier persona o grupo que se ver afectado por el
sistema, directa o indirectamente.

Entre los stakholders se encuentran los usuarios finales que interactan con el sistema y todos aquellos
en la organizacin que se pueden ver afectados por su instalacin. Otros stakholders del sistema
pueden ser los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los
gerentes del negocio, los expertos en el dominio del sistema y los representantes de los trabajadores.

Ilustracin 22 Especificacin de requerimientos.

44
Ilustracin 23 Proceso y obtencin de requerimientos.

45
Adems de los stakholders de los sistemas, ya hemos visto que los requerimientos pueden venir del
dominio de la aplicacin y de otros sistemas que interactan con el sistema a especificar. Todos estos
se deben considerar durante el proceso d obtencin de requerimientos.

46
Ilustracin 24 Anlisis de requisitos.

47
Ilustracin 25 Anlisis de requisitos II.

48
Ilustracin 26 Proceso de anlisis de requisitos.

49
Ilustracin 27 Ingeniera de requisitos.

50
Ilustracin 28 Ingeniera de requisitos parte II.

51
Ilustracin 29 Ingeniera de requisitos parte III.

52
Ilustracin 30 Ingeniera de requisitos parte IV.

53
Ilustracin 31 Tipos de requerimientos no funcionales.

54
Validacin de Requerimientos.

Ilustracin 32 Validacin de requerimientos.

55
Ilustracin 33 Validacin de requerimientos parte II.

56
Unidad III.

Anlisis y modelado de desarrollo de software con UML

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es
el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est
respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar,
especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases
de datos y compuestos reciclados.

El lenguaje unificado de diagrama o notacin (UML) sirve para especificar, visualizar y documentar
esquemas de sistemas de software orientado a objetos. UML no es un mtodo de desarrollo, lo que
significa que no sirve para determinar qu hacer en primer lugar o cmo disear el sistema, sino que
simplemente le ayuda a visualizar el diseo y a hacerlo ms accesible para otros. UML est controlado
por el grupo de administracin de objetos (OMG) y es el estndar de descripcin de esquemas de
software.

UML est diseado para su uso con software orientado a objetos, y tiene un uso limitado en otro tipo
de cuestiones de programacin.

UML se compone de muchos elementos de esquematizacin que representan las diferentes partes de
un sistema de software. Los elementos UML se utilizan para crear diagramas, que representa alguna
parte o punto de vista del sistema. Umbrello UML Modeller soporta los siguientes tipos de diagramas:

Diagrama de casos de uso que muestra a los actores (otros usuarios del sistema), los casos de
uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones.
Diagrama de clases que muestra las clases y la relaciones entre ellas.
Diagrama de secuencia muestra los objetos y sus mltiples relaciones entre ellos.
Diagrama de colaboracin que muestra objetos y sus relaciones, destacando los objetos que
participan en el intercambio de mensajes.
Diagrama de estado muestra estados, cambios de estado y eventos en un objeto o en parte
del sistema.

57
 Diagrama de actividad que muestra actividades, as como los cambios de una a otra actividad
junto con los eventos que ocurren en ciertas partes del sistema.
Diagrama de componentes que muestra los componentes de mayor nivel de la programacin
(cosas como Kparts o Java Beans).
Diagrama de implementacin que muestra las instancias de los componentes y sus relaciones.
Diagrama de relaciones de entidad que muestra los datos y las relaciones y restricciones entre
ellos.

Ilustracin 34 Presentacin UML

Diagrama de casos de uso.

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de
uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso no estn pensados para representar el diseo
y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para
facilitar la comunicacin con los futuros usuarios del sistema, y con el cliente, y resultan especialmente

58
tiles para determinar las caractersticas necesarias que tendr el sistema. En otras palabras, los
diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo.

Un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. El

Lenguaje de Modelado Unificado (UML), define una notacin grfica para representar casos de uso
llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los
casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso
de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o
un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos
de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados
que los diagramas de casos de uso.

Ilustracin 35 Grafica de caso de uso

59
 Ilustracin 36 caso de uso

Caso de uso.

Un caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de un sistema
que produce un resultado concreto y tangible.

Los casos de uso son descriptores de las interacciones tpicas entre los usuarios de un sistema y ese
mismo sistema. Representan el interfaz externo del sistema y especifican qu requisitos de
funcionamiento debe tener este (recuerde, nicamente el qu, nunca el cmo).

Cuando se trabaja con casos de uso, es importante tener presentes algunas sencillas reglas:

Cada caso de uso est relacionado como mnimo con un actor

Cada caso de uso es un iniciador (es decir, un actor)
Cada caso de uso lleva a un resultado relevante (un resultado con valor intrnseco)

60
Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones ms
comunes entre casos de uso son:

<<include>> que especifica una situacin en la que un caso de uso tiene lugar dentro de otro
caso de uso
<<extends>> que especifica que en ciertas situaciones, o en algn punto (llamado punto de
extensin) un caso de uso ser extendido por otro.
Generalizacin que especifica que un caso de uso hereda las caractersticas del super caso
de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las
herencias entre clases.

Actor

Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y
normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios
del sistema), otros ordenadores o eventos externos.

Los actores no representan a personas fsicas o a sistemas, sino su rol. Esto significa que cuando una
persona interacta con el sistema de diferentes maneras (asumiendo diferentes papeles), estar
representado por varios actores. Por ejemplo, una persona que proporciona servicios de atencin
telefnica a clientes y realiza pedidos para los clientes estara representada por un actor equipo de
soporte y por otro actor representante de ventas.

Descripcin de casos de uso

Las descripciones de casos de uso son reseas textuales del caso de uso. Normalmente tienen el
formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los
procesos o actividades que tienen lugar en el caso de uso.

Diagrama de clases.

Los diagramas de clases muestran las diferentes clases que componen un sistema y cmo se relacionan
unas con otras. Se dice que los diagramas de clases son diagramas estticos porque muestran las
clases, junto con sus mtodos y atributos, as como las relaciones estticas entre ellas: qu clases

61
conocen a qu otras clases o qu clases son parte de otras clases, pero no muestran los mtodos
mediante los que se invocan entre ellas.

Ilustracin 37 presentacin grafica de clases

Ilustracin 38 Diagrama de clases

Clase

62
Una clase define los atributos y los mtodos de una serie de objetos. Todos los objetos de esta clase
(instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada
objetos tiene el suyo propio). En ocasiones se utiliza el trmino tipo en lugar de clase, pero recuerde
que no son lo mismo, y que el trmino tipo tiene un significado ms general.

En, las clases estn representadas por rectngulos, con el nombre de la clase, y tambin pueden
mostrar atributos y operaciones de la clase en otros dos compartimentos dentro del rectngulo.

Representacin visual de una clase en UML

Atributos

En UML, los atributos se muestran al menos con su nombre, y tambin pueden mostrar su tipo, valor
inicial y otras propiedades. Los atributos tambin pueden ser mostrados visualmente:

+ Indica atributos pblicos

# Indica atributos protegidos
- Indica atributos privados

Operaciones

Las operaciones (mtodos) tambin se muestran al menos con su nombre, y pueden mostrar sus
parmetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar
visualmente:

+ Indica operaciones pblicas

# Indica operaciones protegidas
- Indica operaciones privadas

Plantillas

63
Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de
plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas
existen en C++ y se introducirn en Java 1.5 con el nombre de Genricos.

Asociaciones de clases

Las clases se puede relaciones (estar asociadas) con otras de diferentes maneras:

Generalizacin

La herencia es uno de los conceptos fundamentales de la programacin orientada a objetos, en la que

una clase recoge todos los atributos y operaciones de la clase de la que es heredera, y puede
alterar/modificar algunos de ellos, as como aadir ms atributos y operaciones propias.

En UML, una asociacin de generalizacin entre dos clases, coloca a estas en una jerarqua que
representa el concepto de herencia de una clase derivada de la clase base. En UML, las
generalizaciones se representan por medio de una lnea que conecta las dos clases, con una flecha en
el lado de la clase base.

Representacin visual de una generalizacin en UML

Asociaciones

Una asociacin representa una relacin entre clases, y aporta la semntica comn y la estructura de
muchos tipos de conexiones entre objetos.

Las asociaciones son los mecanismos que permite a los objetos comunicarse entre s. Describe la
conexin entre diferentes clases (la conexin entre los objetos reales se denomina conexin de objetos
o enlace).

64
Las asociaciones pueden tener un papel que especifica el propsito de la asociacin y pueden ser
unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relacin pueden
intercambiar mensajes entre s, o es nicamente uno de ellos el que recibe informacin del otro). Cada
extremo de la asociacin tambin tiene un valor de multiplicidad, que indica cuntos objetos de ese
lado de la asociacin estn relacionados con un objeto del extremo contrario.

En UML, las asociaciones se representan por medio de lneas que conectan las clases participantes en
la relacin, y tambin pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La
multiplicidad se muestra como un rango [mn...mx] de valores no negativos, con un asterisco (*)
representando el infinito en el lado mximo.

Representacin visual de una asociacin en UML

Acumulacin

Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no
tienen un estado igual, pero constituyen una relacin completa. Una acumulacin describe cmo se
compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las
acumulaciones, la clase que acta como completa, tiene una multiplicidad de uno.

En UML, las acumulaciones estn representadas por una asociacin que muestra un rombo en uno de
los lados de la clase completa.

Representacin visual de una relacin de acumulacin en UML

Composicin

Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que
las composiciones tambin forman relaciones completas, pero dichas relaciones son tan fuertes que

65
las partes no pueden existir por s mismas. nicamente existen como parte del conjunto, y si este es
destruido las partes tambin lo son.

En UML, las composiciones estn representadas por un rombo slido al lado del conjunto.

Otros componentes de los diagramas de clases

Los diagramas de clases pueden contener ms componentes aparte de clases.

Interfaces

Las interfaces son clases abstractas, lo que significa que no es posible crear instancias directamente a
partir de ellas. Pueden contener operaciones, pero no atributos. Las clases pueden heredar de las
interfaces (a travs de una asociacin de realizacin) y de estos diagramas s es posible crear instancias.

Tipo de datos

Los tipos de datos son primitivas construidas normalmente en algunos lenguajes de programacin.
Algunos ejemplos comunes son los enteros y los booleanos. No pueden tener relacin con clases, pero
las clases s pueden relacionarse con ellos.

Enumeraciones

Las enumeraciones son simples listas de valores. Un ejemplo tpico de esto sera una enumeracin de
los das de la semana. Las opciones de una enumeracin se llaman literales de enumeracin. Al igual
que los tipos de datos, no pueden relacionarse con las clases, pero las clases s pueden hacerlo con
ellos.

Paquetes

Los paquetes, en lenguajes de programacin, representan un espacio de nombres en un diagrama se

emplean para representar partes del sistema que contienen ms de una clase, incluso cientos de ellas.

66
Diagrama de secuencia

Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan)
en un momento dado. Los diagramas de secuencia ponen especial nfasis en el orden y el momento
en que se envan los mensajes a los objetos.

En los diagramas de secuencia, los objetos estn representados por lneas intermitentes verticales,
con el nombre del objeto en la parte ms alta. El eje de tiempo tambin es vertical, incrementndose
hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los
nombres de la operacin y los parmetros.

Ilustracin 39 Presentacin grafica secuencia

67
 Ilustracin 40 diagrama de secuencia

Los mensajes pueden ser o bien sncronos, el tipo normal de llamada del mensaje donde se pasa el
control a objeto llamado hasta que el mtodo finalice, o asncronos donde se devuelve el control
directamente al objeto que realiza la llamada. Los mensajes sncronos tienen una caja vertical en un
lateral del objeto invocante que muestra el flujo del control del programa.

Diagrama de colaboracin

Los diagramas de colaboracin muestran las interacciones que ocurren entre los objetos que
participan en una situacin determinada. Esta es ms o menos la misma informacin que la mostrada
por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el
tiempo, mientras que los diagramas de colaboracin fijan el inters en las relaciones entre los objetos
y su topologa.

68
En los diagramas de colaboracin los mensajes enviados de un objeto a otro se representan mediante
flechas, mostrando el nombre del mensaje, los parmetros y la secuencia del mensaje. Los diagramas
de colaboracin estn indicados para mostrar una situacin o flujo programa especficos y son unos
de los mejores tipos de diagramas para demostrar o explicar rpidamente un proceso dentro de la
lgica del programa.

Ilustracin 41 presentacin grafica colaboracin

Ilustracin 42 diagrama de colaboracin

69
Diagrama de estado

Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estmulos
que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como mquinas de estado o autmatas finitos que pueden
estar en un conjunto de estados finitos y que pueden cambiar su estado a travs de un estmulo
perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su
vida uno de los siguientes estados:

Listo
Escuchando
Trabajando
Detenido

y los eventos que pueden producir que el objeto cambie de estado son

Se crea el objeto
El objeto recibe un mensaje de escucha
Un cliente solicita una conexin a travs de la red
Un cliente finaliza una solicitud
La solicitud se ejecuta y ser termina
El objeto recibe un mensaje de detencin

70
 Ilustracin 43 diagrama de estado

Ilustracin 44 ejemplo diagrama de estado

Estado

71
Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente una clase
y representa un resumen de los valores y atributos que puede tener la clase. Un estado UML describe
el estado interno de un objeto de una clase particular

Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar representados
por estados, sino nicamente aquellos cambios que pueden afectar significativamente a la forma de
funcionamiento del objeto

Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no hay ningn
evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no hay ningn
evento que pueda sacar a un objeto de su estado de fin.

Los diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de
actividad son una forma especial de los diagramas de estado, que nicamente (o mayormente)
contienen actividades.

Diagrama de actividad

Ilustracin 45 diagrama de actividad

72
Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que
todas las actividades estn claramente unidas a objetos.

Los diagramas de actividad siempre estn asociados a una clase, a una operacin o a un caso de uso.

Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecucin
paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas,
no importa en qu orden sean invocadas (pueden ser ejecutadas simultneamente o una detrs de
otra).

Actividad

Una actividad es un nico paso de un proceso. Una activa es un estado del sistema que actividad
interna y, al menos, una transicin saliente. Las actividades tambin pueden tener ms de una
transicin saliente, si tienen diferentes condiciones.

Las actividades pueden formar jerarquas, lo que significa que una actividad puede estar formada de
varias actividades de detalle, en cuyo caso las transiciones entrantes y salientes deberan coincidir
con las del diagrama de detalle.

Elementos de ayuda

Existen unos pocos elementos en UML que no tiene un valor semntico real en la maqueta, pero que
ayudan a clarificar partes del programa. Estos elementos son

Lnea de texto
Notas de texto y enlaces
Cajas

Las lneas de texto son tiles para aadir informacin textual a un diagrama. Es texto es libre y no tiene
ningn significado para la maqueta.

Las notas son tiles para aadir informacin ms detallada de un objeto o una situacin especfica.
Tienen la gran ventaja de que se pueden anclar a los elementos UML para mostrar que una nota
pertenece a un objeto o situacin especficos.

73
Las cajas son rectngulos repartidos libremente que pueden usarse para juntar objetos haciendo los
diagramas ms legibles. No tienen significado lgico en la maqueta.

Diagramas de componentes

Los diagramas de componentes muestran los componentes del software (ya sea las tecnologas que lo
forman como Kparts, componentes CORBA, Java Beans o simplemente secciones del sistema
claramente distintas) y los artilugios de que est compuesto como los archivos de cdigo fuente, las
libreras o las tablas de una base de datos.

Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que permiten
asociaciones entre componentes.

Diagramas de implementacin

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

Diagramas de relacin de entidad

Los diagramas de relaciones de entidad (diagramas ER) muestran el diseo conceptual de las
aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema de informacin
y las relaciones y restricciones existentes entre ellas. Una extensin de los diagramas de relaciones de
entidad llamado diagramas de relaciones de entidad extendida o diagramas de relaciones de
entidad mejoradas (EER), se utiliza para incorporar las tcnicas de diseo orientadas a objetos en los
diagramas ER.

74
 Ilustracin 46 diagrama de entidad relacion

Entidad

Una Entidad es cualquier concepto del mundo real con una existencia independiente. Puede ser un
objeto con una existencia fsica (ejemplo, mquina, robot) o puede ser un objeto con una existencia
conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de atributos que describen
las propiedades de la entidad.

Nota: No existen notaciones estndar para representar los diagramas ER. Los diferentes textos sobre
este asunto utilizan diferentes notaciones. Los conceptos y notaciones para los diagramas EER
utilizados en Umbrello provienen del siguiente libro: Elmasri R. y Navathe S. (2004). Fundamentals of
Database Systems 4 ed. Addison Wesley (Fundamentos de los sistemas de bases de datos)

En un diagrama ER, las entidades se representan como rectngulos, con el nombre de la clase, y
tambin pueden mostrar atributos y operaciones de la clase en otros dos compartimentos dentro
del rectngulo.

75
Representacin visual de una entidad en un diagrama ER

Atributos de la entidad

En los diagramas ER, los atributos de la entidad se muestra con su nombre en un compartimento
diferente de la entidad a la que pertenecen.

Restricciones

Las restricciones en los diagramas ER especifican las restricciones de los datos en el esquema de
informacin.

Existen cuatro tipos de restricciones soportadas por Umbrello:

Clave primaria: El conjunto de atributos declarados como clave primaria es nica para la
entidad. Solo puede haber una clave primaria en una entidad y ninguno de los atributos que
la componen puede ser NULL.
Clave nica: El conjunto de atributos declarados como nica son nicos para la entidad.
Pueden haber muchas restricciones nicas en una entidad. Los atributos que lo componen
pueden tener el valor NULL. Las claves nicas y primarias identifican de forma nica una fila
de una tabla (entidad)
Clave externa: Una clave externa es una restriccin referencia entre dos tablas. La clave
externa identifica una columna o un conjunto de columnas una tabla (referenciada) que
referencia una columna o conjunto de columnas en otra tabla (referenciada). Las columnas en
la tabla referenciada deben formar una clave primaria o una clave nica.
Restriccin de comprobacin: Una restriccin de comprobacin (tambin conocida como
restriccin de comprobacin de tabla) es una condicin que define los datos vlidos cuando
se aaden o actualizan datos en una tabla de la base de datos relacional. Se aplicar una
restriccin a cada fila de la tabla. La restriccin debe ser un predicado. Puede referirse a una
o varias columnas de la tabla.

76
 Ejemplo: precio >= 0

Conceptos del diagrama de relaciones de entidades extendido (EER)

Especializacin

La especializacin es una manera de formar nuevas entidades utilizando entidades que ya se hayan
definido. Las entidades nuevas, conocidas como entidades derivadas, asumir (o heredar) atributos de
las entidades que ya existan, y que se refieren a las entidades base. Se pretende ayudar a reutilizar
datos con pequeas o ninguna modificacin.

Especializacin disjunta

Una especializacin disjunta especifica que las subclases de una especializacin deben ser disjuntas,
es decir, una entidad puede ser miembro, como mximo, de una de las derivadas en la especializacin.

Ilustracin 47 especializacin disjunta

Especializacin de solapamiento

Cuando las entidades derivadas no son obligatoriamente disjuntas, el conjunto de entidades se

denomina una especializacin por solapamiento, lo que significa que una entidad puede pertenecer
a ms de una entidad derivada de la especializacin.

77
 Ilustracin 48 especializacin de solapamiento

Categora

Una entidad derivada se considera una Categora cuando representa una coleccin de objetos que es
un subconjunto de la unin de varios tipos de entidades. Una categora se modela cuando se necesita
una relacin nica superclase/subclase con ms de una superclase, donde la superclase representa
diferentes tipos de entidades (similar a la herencia mltiple en Programacin Orientada a Objetos).

78
79