Universidad Tecnolgica de la selva.

Antologa de la materia ingeniera de

software I.
Elaborado por:
Ing. Jess Antonio Saldaa Espinosa.

Diciembre del 2013.

NDICE.
Introduccin a la asignatura ................................................................................................................ 3
Metodologas de desarrollo de software. ........................................................................................... 4
Clasificacin de las metodologas.................................................................................................... 4
Metodologas estructuradas. .......................................................................................................... 4
Metodologas no estructuradas. ..................................................................................................... 5
Modelo en cascada.......................................................................................................................... 7
Modelo basado en prototipos. ........................................................................................................ 8
Modelo incremental. ....................................................................................................................... 9
Modelo en espiral.......................................................................................................................... 12
Desarrollo rapido de aplicaciones (RAD). ...................................................................................... 14
Modelo RUP. .................................................................................................................................. 16
Programacin extrema (XP). ......................................................................................................... 17
Agil MSF (Microsoft Solution FrameWork).................................................................................... 19
Otros enfoques de desarrollo de software.................................................................................... 22
Ventajas y desventajas. ................................................................................................................. 23
Unidad II. Administracin de requerimientos. .................................................................................. 27
Estudio de factibilidad. .................................................................................................................. 27
Factibilidad Tcnica. ...................................................................................................................... 27
Factibilidad Econmica. ................................................................................................................. 30
Factibilidad Operativa. .................................................................................................................. 37
Obtencin y anlisis de requerimientos........................................................................................ 38
Validacin de requerimientos. ...................................................................................................... 50
Unidad III. Anlisis y modelado de desarrollo de software con UML. .............................................. 52
Introduccin al UML. ..................................................................................................................... 52
Diagramas de casos de uso. .......................................................................................................... 53
Relaciones de Casos de Uso. ...................................................................................................... 54
Diagrama de clases. ....................................................................................................................... 56
Diagrama de secuencia. ................................................................................................................ 57
Diagrama de colaboracin............................................................................................................. 58
Diagrama de estado. ..................................................................................................................... 59
Bibliografa ........................................................................................................................................ 60

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 tecnologico.
La Ingenieria 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, sistemas 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.

Unidad I. Metodologas de desarrollo de software.

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

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.

Analisis de requisitos.
Dieo del sistema.
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.

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

Plan rapido.
Modelado, diseo rpido.
Desarrollo, entrega y retroalimentacin.
Comunicacin.
Entrega del desarrollo final.

Ilustracin 2. Estructura del modelo basado en prototipos.

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

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

10

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

11

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.

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.

12

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.

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

13

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

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

14

Ilustracin 6. Modelo para el desarrollo rapido de aplicaciones.

15

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

Ilustracin 7. Fases e interacciones de la Metodologia RUP.

16

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

17

Bases de la Metodologia XP.

Podemos encontrar que esta Metodologia est basada en:
Pruebas Unitarias: Se basan en las pruebas realizadas a los principales procesos, de tal manera que
adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir,
la refabricacin se basa en la reutilizacin de codigo, para lo cual se crean patrones o modelos
estndares, siendo ms flexible al cambio.

Programacin en pares la cual consiste en que dos desarrolladores participen en un

proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el
otro no est haciendo en ese momento.
Dentro de esta Metodologia existen las siguientes proposiciones:

Empieza en pequeo y aade funcionalidad con retroalimentacin continua.

El manejo del cambio se convierte en parte sustantiva del proceso.
El costo del cambio no depende de la fase o etapa.
No introduce funcionalidades antes que sean necesarias.
El cliente o el usuario se convierten en miembro del equipo.

Lo fundamental en este tipo de Metodologia es:

La comunicacin, entre los usuarios y los desarrolladores.
La simplicidad, al desarrollar y codificar los mdulos del sistema.
La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los
usuarios finales.

18

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

19

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

20

 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.

21

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

22

Ventajas y desventajas.
Modelo en cascada.
Variantes.
Existen variantes de este modelo; especialmente destacamos la que hace uso
de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento,
verificando que el sistema final est libre de fallos.
Desventajas.
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementacin del modelo, lo cual hace que lo lleve al fracaso.
En la vida real, 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. Esto es la base para que
funcione bin.
Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al
rediseo nueva programacin del codigo afectado, aumentando los costos del desarrollo.
Modelo basado en prototipos.
Ventajas.
Este modelo es til cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.
Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del
software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debera tomar la interaccin humanomquina.
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

23

Modelo espiral.
Ventajas.
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.
Desventajas.

Requiere mucha experiencia y habilidad para la evaluacin de los riesgos, lo cual es

requisito para el xito del proyecto.

Es difcil convencer a los grandes clientes que se podr controlar este enfoque evolutivo.

Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no
se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difcil de
implementar y controlar.

Desarrollo Rapido de aplicaciones.

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.
Flexibilidad.
Mayor involucramiento de los usuarios.
Ciclos de desarrollos ms pequeos.

Desventajas.

Comprar puede ser ms caro que construir.

Costo de herramientas integradas y equipo necesario.
Progreso ms difcil de medir.
Menos eficiente.
Menos precisin cientfica.

24

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

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).
Programacin extrema.
Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes
de la codificacin. Vase, por ejemplo, las herramientas de prueba JUnit orientada
a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP.
Estas tres ltimas inspiradas en JUnit, la cual, a su vez, se insipir en SUnit, el
primer framework orientado a realizar tests, realizado para el lenguaje de
programacin Smalltalk.
Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a
cabo por dos personas en un mismo puesto. La mayor calidad del cdigo escrito de
esta manera -el cdigo es revisado y discutido mientras se escribe- es ms
importante que la posible prdida de productividad inmediata.
Frecuente integracin del equipo de programacin con el cliente o usuario. Se
recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer
entregas frecuentes.

25

 Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para
aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento.
Las pruebas han de garantizar que en la refactorizacin no se ha introducido
ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el
desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve
el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las
frecuentes pruebas de regresin garantizan que los posibles errores sern
detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando
todo funcione se podr aadir funcionalidad si es necesario. La programacin
extrema apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo
extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca
utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con
ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer.
Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que
lleva a una comunicacin ms completa, especialmente si se puede reducir el
equipo de programadores.

26

Unidad II. Administracin de requerimientos.

Estudio de factibilidad.
Estudio de factibilidad tambin conocido como estudio de viabilidad, es el anlisis amplio
de los resultados 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 generan ingreso, renta, salario y ganancia).
Factibilidad Tcnica.
La factibilidad tcnica consiste en realizar una evaluacion 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
mismo 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 implantacin del sistema de seguimiento y
control de las investigaciones cientficas de la universidad de Carabobo, se evalu bajos
dos enfoques: Hardware y software.
En cuanto a hardware, especificamente el servidor donde debe estar instalado el sistema
propuesto, este debe cubrir con los siguientes requerimientos mnimos.

Procesador Pentium 166 Mhz.

Tarjeta Madre.
64 MB de Memoria RAM.
Disco duro de 5 GB.
Unidad de disco 31/2.
Unidad de CD-ROMTarjeta de Red.
Tarjeta de Video.
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 existentes, ya que los mismos satisfacen
los requerimientos establecidos tanto para el desarrollo y puesta en funcionamiento del

27

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.

Ilustracin 11. Ejemplo de factibilidad operativa.

28

Por caractersticas fisicas 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 instituos con la Red Academica de
informacin Cientifica REDAIC, aprovechando para ello el Backbone o Red Dorsal de
Fibra ptica de Universidad. Para aquellos Centros y/o institutos de la red de investigacin,
que por su ubicacin geogrfica no pueden hacer uso de la Red Troncal para
interconectarse a la Red Academica, se prev realizar la interconexin va radio enlace o
por medio de una conexin telefnica.
Las caractersticas de red interna con que cuenta actualmente cada centro o instituto, se
detallan a continuacin.
Servidor: Equipo con precesador Penium II, de 300 MHz de velocidad, 64 MB de Memoria
Ram, Disco duro 4.3 GB, Tarjeta de red.
Concetrandores de puertos RJ-45.
Todas las estaciones de trabajo estn conectas al servidor a travs de una red de topologa
estrella, tulizando cable par trenzado sin apantallamiento UTP, de la categoria nmero
(5), segn las normas internacionales del Instituto de Ingenieros Elctricos y Electronicos
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 el software WWWSIS. Para el uso general de las estaciones
en actividades diversas se debe poseer las herramientas de escritorio y los navegadores
que existen en el mercado actualmente.

29

Ilustracin 12. Factibilidad Operativa II.

Como resultado de este estudio tcnico 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.

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 ste, lo cual permiti observar de una
manera ms precisa las bondades del 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.

30

A continuacin se presenta un resumen de los costos intrnsecos del 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.

Ilustracin 13. Costo del sistema actual.

31

Ilustracin 14. Costo del personal.

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 el material de oficina de uso diario.

32

Ilustracin 15. Costo de papelera.

33

Ilustracin 16. Seguimiento.

34

Ilustracin 17. Salario del personal.

35

Ilustracin 18. Costo beneficio del sistema propuesto y el sistema actual.

36

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 supeditado a la capacidad de los empleados
encargados de dicha tarea.

Ilustracin 19. Factibilidad Operativa.

37

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, qu 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 vera afectado por el sistema, directa o indirectamente.
Entre los stakeholders 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
stakeholders del sistema pueden ser los ingenieros que desarrollan o dan mantenimiento
a otros sistemas relacionados, los gerentes del negocio, los expertos en e dominio del
sistema y los representantes de los trabajadores.

38

Ilustracin 20. Especificacin de requerimientos.

39

Ilustracin 21. Proceso y obtencin de requerimientos.

40

Adems de los stakeholders del sistema, 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
stos se deben considerar durante el proceso de obtencin de requerimientos.

41

Ilustracin 22. Anlisis de requisitos.

42

Ilustracin 23. Anlisis de requisitos II.

43

Ilustracin 24. Proceso de anlisis de requisitos.

44

Ilustracin 25. Ingenieria de requisitos.

45

Ilustracin 26. Ingenieria de requisitos parte II.

46

Ilustracin 27. Ingenieria de requisitos parte III.

47

Ilustracin 28. Ingenieria de requisitos parte IV.

48

Ilustracin 29. Tipos de requerimientos no funcionales.

49

Validacin de requerimientos.

Ilustracin 30. Validacin de requerimientos.

50

Ilustracin 31. Validacin de requerimientos II.

51

Unidad III. Anlisis y modelado de desarrollo de

software con UML.
Introduccin al 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.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para
describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje
en el que est descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a
una metodologa de desarrollo de software (tal como el Proceso Unificado Racional
o RUP), pero no especifica en s mismo qu metodologa o proceso usar.

Ilustracin 32. UML.

52

Diagramas de casos de uso.

Ilustracin 33. Caso de uso.

En el Lenguaje de Modelado Unificado, 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.

La descripcin escrita del comportamiento del sistema al afrontar una tarea de

negocio o un requisito de negocio. Esta descripcin se enfoca en el valor suministrado
por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organizacin, un conjunto de casos de uso coherente y consistente
promueven una imagen fcil de comprender del comportamiento del sistema, un
entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.

53

En esta prctica es comn crear especificaciones suplementarias para capturar detalles de

requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de
esos temas incluyen restricciones de diseo como: rendimiento, temas de
escalabilidad/gestin, o cumplimiento de estndares.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy

simple. Los casos de uso estn representados por elipses y los actores estn, por ejemplo,
los casos de uso se muestran como parte del sistema que est siendo modelado, los
actores no.
La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin
es esencial para una descripcin coherente del comportamiento deseado, quizs los
lmites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la
interaccin entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin
embargo, los actores son una especie de rol, un usuario humano u otra entidad externa
pueden jugar varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma
persona.
Relaciones de Casos de Uso.
Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML,
el cual describe notacin grfica para esas relaciones. Veamos una revisin de ellas a
continuacin:
Inclusin (include o use).
Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro caso de
uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto
es til para extraer comportamientos verdaderamente comunes desde mltiples casos de
uso a una descripcin individual (si el actor realiza el caso de uso base tendra que realizar
tambin el caso de uso incluido), desde el caso de uso. El estndar de Lenguaje de
Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos
de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin
pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la
notacin grfica y las descripciones esto no sirve.
Extensin (extend).
Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a otro.
Esta relacin indica que el comportamiento del caso de la extensin se utiliza en casos de
uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. El caso de uso
extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La

54

notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso
extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para
lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento
del sistema y su extensin.
"La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la
extensin son los ejemplos o instancias de los conceptos."
Documentan el comportamiento de un sistema desde el punto de vista de un usuario
En otras palabras ser utilizado cuando un caso de uso sea similar a otro pero con ciertas
variaciones, un ejemplo claro es que se necesite comprar azcar y podemos seleccionar de
entre azcar rubia, blanca o su unidad de medida bolsa, kilo.
Generalizacin.
"Entonces la Generalizacin es la actividad de identificar elementos en comn entre
conceptos y definir las relaciones de una superclase (concepto general) y subclase
(concepto especializado). Es una manera de construir clasificaciones taxonmicas entre
conceptos que entonces se representan en jerarquas de clases. Las subclases
conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y
extensin."
En la tercera forma de relaciones entre casos de uso, existe una relacin
generalizacin/especializacin. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notacin es una lnea slida terminada en un
tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se
asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til
factorizar comportamientos comunes, restricciones al caso de uso general, describirlos
una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

55

Diagrama de clases.

Ilustracin 34. Diagrama de clases.

Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de

un sistema mostrando sus clases, orientados a objetos.
Propiedad de objetos que tienen propiedades y/u operaciones que contienen un contexto
y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lgica de
negocio, dependiendo de quin disee el sistema se pueden unir los datos con las
operaciones.
El diagrama de clases incluye mucha ms informacin como la relacin entre un objeto y
otro, la herencia de propiedades de otro objeto, conjuntos de operaciones, propiedades
que son implementadas para una interfaz grfica.
El diagrama de clases incluye mucha ms informacin como la relacin entre un objeto y
otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades
que son implementadas para una interfaz grfica.

56

Diagrama de secuencia.

Ilustracin 35. Diagrama de secuencia

.

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre

objetos en un sistema segn UML.
Utilidad.
Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una
aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que
el diagrama de casos de uso permite el modelado de una vista business del escenario, el
diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los
objetos y clases que se usan para implementar el escenario y mensajes intercambiados
entre los objetos.
Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos son
necesarios para la implementacin del escenario. Si se dispone de la descripcin de
cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre"
esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos.
Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas
discontinuas verticales, y los mensajes pasados entre los objetos como flechas
horizontales.

57

Diagrama de colaboracin.

Ilustracin 36. Diagrama de colaboracin.

Un diagrama de colaboracin en las versiones de UML 1.x es esencialmente un diagrama

que muestra interacciones organizadas alrededor de los roles. A diferencia de los
diagramas de secuencia, los diagramas de colaboracin, tambin llamados diagramas de
comunicacin, muestran explcitamente las relaciones de los roles. Por otra parte, un
diagrama de comunicacin no muestra el tiempo como una dimensin aparte, por lo que
resulta necesario etiquetar con nmeros de secuencia tanto la secuencia de mensajes
como los hilos concurrentes.

Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un
objetivo comn.
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de
un objeto a otro. Dicha implementacin es llamada "enlace".

Un diagrama de comunicacin es tambin un diagrama de clases que contiene roles de

clasificador y roles de asociacin en lugar de slo clasificadores y asociaciones. Los roles
de clasificador y los de asociacin describen la configuracin de los objetos y de los

58

enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicacin. Cuando
se instancia una comunicacin, los objetos estn ligados a los roles de clasificador y los
enlaces a los roles de asociacin. El rol de asociacin puede ser desempeado por varios
tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales
del procedimiento. Los smbolos de enlace pueden llevar estereotipos para indicar enlaces
temporales.

Diagrama de estado.

Ilustracin 37. Diagrama de estado.

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto
durante su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes
recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. Tambin
ilustran qu eventos pueden cambiar el estado de los objetos de la clase. Normalmente
contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez,
eventos, acciones y actividades, vamos a ver primero sus definiciones.
Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas
explicativas y restricciones.

59

Bibliografa
Booch G. Rumbaugh j., J. I. (2000). El lenguaje Unificado de Modelado. Guia del usuario. Madrid:
Addison Wesley.

Drake, J. M. (2008). Ingenieria de programacion . Madrid: Santander.

Larman, C. (2003). IEEE recommended practice for software requierements specifications (8301998). Espaa: IEEE Computer Society.

Larman, C. (2012). UML y PATRONES. PEARSON Prentice Hall.

Pressman, R. (2010). Ingenieria del software. McGrawHill.

Sommerville, I. (2005). Ingenieria del software. Espaa: Addison Wesley.

60