RUP, ITIL Y NORMA ISO 9126: 1991

Presentado por LUIS CARLOS PULGARIN M

Presentado a: WILLMAR FERNANDO ALZATE CORREA

UNISARC
FACULTAD DE CIENCIAS Y TECNOLOGAS DE INFORMACIN Y COMUNICACIN
INGENIERIA DE SISTEMAS
SANTA ROSA DE CABAL
2015

RUP
Se ha establecido que una metodologa para desarrollar sistemas consta de dos
elementos fundamentales, un proceso y una notacin. El proceso es el conjunto de
pasos ordenados para realizar las actividades de desarrollo y la notacin representa las
reglas para especificar y modelar los resultados del proceso. En este captulo se ha
documentado el proceso de desarrollo del proyecto siguiendo las guas RUP (Proceso
Unificado Rational), particularizndolo para sistemas integrales hardware y software de
tiempo real. Los resultados del proceso, bsicamente especificados con UML,
constituyen los captulos restantes de esta memoria.

Enfoque del Proceso RUP

El objetivo del captulo es formalizar las actividades de desarrollo del proyecto. El
encuadre que se ha elaborado es resultado de un estudio para especializar el uso del
RUP orientado al tipo de sistemas que nuestro grupo de investigacin desarrolla.
Existen cuatro razones fundamentales por las que se ha concebido este captulo:
- Si bien el RUP permite gran flexibilidad para distintos sistemas, requiere de gran
esfuerzo para aplicarlo a otros de menor complejidad, debido a que se lo debe
comprender en detalle a fin de discriminar los elementos a utilizar.
- El RUP toma en cuenta slo de manera disgregada el tiempo real. En este documento
se han definido explcitamente las actividades especficas de la ingeniera de tiempo
real.
- Las guas RUP han sido concebidas para sistemas software. En nuestro enfoque se
han integrado los aspectos hardware y software del sistema.
- Este captulo pretende constituirse en un marco formal para que pueda hacerse
extensible como gua en el desarrollo de otros proyectos de este tipo.
Este es el Proceso Racional Unificado este es un proceso de desarrollo de software y
que junto con el Lenguaje Unificado de Modelado UML, constituye una
metodologa estndar para el anlisis, implementacin y documentacin de sistemas
orientados a objetos. Esta metodologa fue adaptada a las caractersticas de la
organizacin y se realizan ajustes en base a las caractersticas especficas de
cada proyecto. El conjunto de disciplinas bsico utilizado contempla

Realizacin de reuniones y entrevistas (preliminares y especficas) que son

documentadas , confeccin de un documento de visin a partir del proyecto base,
ajustando y precisando las necesidades de alto nivel en base a lo relevado en las
reuniones preliminares. Se focaliza en las necesidades de los stakeholders y los
usuarios finales y en porque esas necesidades existen.
Realizar el anlisis detallado, profundizando en cada una de las caractersticas
obteniendo los requerimientos funcionales y no funcionales que deben ser
atendidos.
Confeccionar un glosario: dada la necesidad de trabajar en forma interdisciplinaria
en prcticamente todo los proyectos es de vital importancia confeccionar un glosario o
diccionario que permita unificar el lenguaje a utilizar en la ejecucin del proyecto.
Este glosario se realiza con la tcnica de Lxico extendido del Lenguaje.
Confeccin del diagrama de casos de uso y determinacin de los casos de uso:
a travs del conocimiento de los requerimientos funcionales comenzar la
construccin del diagrama de casos de uso, determinacin de actores del sistema
y definir los atributos necesario que permitan ser utilizados para estimar el
esfuerzo para la construccin de la solucin.
La historias la historia de RUP. El antecedente ms importante se ubica en
1967 con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar
Jacobson, una aproximacin de desarrollo basada en componentes, que introdujo el
concepto de Caso de Uso. Entre los aos de 1987 a 1995 Jacobson fund la
Posteriormente en 1995 Rational Software Corporation adquiereentre 1995 y 1997
se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del
Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y Rumbaugh,
Rational Software desarroll e incorpor diversos elementos para expandir ROP,
destacndose especialmente el flujo de trabajo conocido como modelado del
negocio. En junio del 1998 se lanza Rational Unified Process.
Se han hecho las siguientes consideraciones para aplicar el RUP a este proyecto:

1. Tomando en cuenta el alcance de este proyecto, se han tomado tres Componentes

del Proceso del RUP: Requerimientos, Anlisis y Diseo e, Implementacin y dos Fases
del Proceso del RUP: Concepcin y Elaboracin.
2. El Componente de Implementacin no cubre la materializacin del sistema,
cubriendo solo la planificacin para abordar adecuadamente la implementacin.
3. En la parte de Componentes del Proceso se han documentado las Actividades y
Artefactos, no habindose detallado completamente, para lo cual debe referirse al
documento oficial del RUP.
4. En la documentacin de Actividades los campos de Propsito y Pasos han sido
elaborados de manera genrica para cualquier sistema. En el campo de Gua se
describen las consideraciones particulares para este proyecto.
5. En la documentacin de Artefactos el campo de Definicin ha sido elaborado de
manera genrica y los campos Rasgos Particulares y Referencias describen los
aspectos particulares para este proyecto.
Notacin RUP
El Proceso RUP se representa utilizando cuatro elementos bsicos de modelado:
1. Roles: Un rol define el comportamiento y las responsabilidades de una persona
trabajando en el proyecto.
2. Actividades: Una actividad representa una unidad de trabajo desempeada por un
determinado rol. El propsito de la actividad es crear artefactos.
3. Artefactos: Un artefacto es una pieza de informacin que se produce, modifica, o usa
por un proceso. Es el producto tangible del proyecto que puede ser:
a)

Un modelo o elemento de modelo, tal como Modelo de Casos de Uso,

b)

Un documento, tal como el documento de la Arquitectura del Sistema,

c)

Una Pieza Hardware o un Programa Ejecutable del Sistema.

4. Flujos de trabajos: Un flujo de trabajo es una secuencia de actividades que produce

resultados observables. Se representan dos tipos de flujos de trabajo:

a) Flujo de Trabajo Principal: Es una coleccin de actividades relacionadas, que

representa un componente del proceso de desarrollo RUP.
b) Flujo de Trabajo Detallado: Representan el desglosamiento de las actividades que
se muestran en el flujo de trabajo principal en otro grupo de actividades ms pequeas
que interactan con roles y artefactos.

El Proceso Unificado est centrado en la arquitectura

El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto
desempea en la construccin de edificios. El edificio se mira desde diferentes puntos
de vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor
ver una radiografa completa antes de empezar a construir. Similarmente, la
arquitectura en un sistema de software es descrita como diferentes vistas del sistema
que est siendo construido.
El concepto de arquitectura de software involucra los aspectos estticos y dinmicos
ms significativos del sistema. La arquitectura surge de las necesidades de la empresa,
tal y como las interpretan los usuarios y otros stakeholders, y tal y como estn
reflejadas en los casos de uso. Sin embargo, tambin est influenciada por muchos
otros factores, tales como la plataforma de software en la que se ejecutar, la
disponibilidad de componentes reutilizables, consideraciones de instalacin, sistemas
legados, requerimientos no funcionales (ej. desempeo, confiabilidad). La arquitectura
es la vista del diseo completo con las caractersticas ms importantes hechas ms
visibles y dejando los detalles de lado. Ya que lo importante depende en parte del
criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del
personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a
enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en
los cambios futuros (resilience) y reus.
Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin
y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar
balanceadas para obtener un producto exitoso. En este caso funcin corresponde a los
casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de
uso y arquitectura. Es un problema del huevo y la gallina. Por una parte, los casos de
uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la
arquitectura debe proveer espacio para la realizacin de todos los casos de uso, hoy y
en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en
paralelo.

El Proceso Unificado es dirigido por casos de uso

Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir
un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios
prospectos.
El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros
sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta
con el sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un
resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los
casos de uso juntos constituyen el modelo de casos de uso el cual describe la
funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin
funcional del sistema. Una especificacin funcional tradicional se concentra en
responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de
casos de uso puede ser definida agregando tres palabras al final de la pregunta: por
cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a
pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones
que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una
herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo,
implementacin y pruebas, esto es, dirigen el proceso de desarrollo.
An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada.
Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso
dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de
los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran
conforme avanza el ciclo de vida.

ITIL

Dado el grado de competitividad en los servicios de Tecnologas de la informacin, una

de las formas de diferenciacin es la adopcin de sistemas de gestin innovadores que
garanticen el mejor servicio a sus clientes y una actitud proactiva y donde impliquemos
a todos los factores en la realizacin y gestin de un servicio de asistencia TI (cliente,
proveedores, usuarios, etc.) en una actitud sinrgica en la mejor prestacin del servicio.
El principal desafo es alinear los servicios de TI con las necesidades de negocios con
eficiencia y de acuerdo a una relacin coste / beneficio aceptable. ITIL (IT
Infraestructura Library) es el Framework o marco de procesos de Gestin de Servicios
de TI que proporciona un conjunto de mejores prcticas recogidas por la Oficina
Gubernativa de Comercio Britnica y que describe los procesos necesarios para
administrar el rea de TI eficazmente con el fin de optimizar beneficios y garantizar la
integracin de los servicios en la cadena de valor de las unidades de negocio. El
conjunto de mejores prcticas de ITIL permite hacer ms eficiente la gestin de servicio
de TI, generar orden, lenguaje y procesos comunes, que establecen la mejor manera de
hacer las cosas. Este estndar no es una solucin en s; para lograrlo es fundamental
contar con personas con el conocimiento para aplicar las recomendaciones y procesos
necesarios. La metodologa ITIL se asienta sobre la base de una decena de procesos,
cuyos objetivos principales son: el incremento de la calidad de servicio y el control
eficaz de los costos.

En la dcada de 1980, el servicio prestado a los departamentos del gobierno britnico

por empresas de TI internas y externas era de tal calidad que la CCTA (Agencia Central
de Telecomunicaciones, actualmente Ministerio de Comercio, OGC) recibi el encargo
de desarrollar una metodologa estndar para garantizar una entrega eficaz y eficiente
de los servicios de TI. Esta metodologa deba ser independiente de los suministradores
(internos o externos). El resultado fue el desarrollo y publicacin de la Biblioteca de la
Infraestructura de Tecnologa de la Informacin (ITIL), que est formada por una serie
de Mejores Prcticas procedentes de todo tipo de suministradores de servicios de TI.
ITIL especifica un mtodo sistemtico que garantiza la calidad de los servicios de TI.
Ofrece una descripcin detallada de los procesos ms importantes en una organizacin
de TI, incluyendo listas de verificacin para tareas, procedimientos y responsabilidades
que pueden servir como base para adaptarse a las necesidades concretas de cada
organizacin. Al mismo tiempo, el amplio campo de aplicacin de ITIL la convierte en

una til gua de referencia en muchas reas, lo que puede servir a las organizaciones
de TI para definir nuevos objetivos de mejora que lleven a su crecimiento y madurez.
Con el paso de los aos, ITIL se ha convertido en mucho ms que una serie de libros
tiles sobre Gestin de Servicios de TI. El marco de trabajo para el desarrollo de
Mejores Prcticas en la Gestin de Servicios de TI no deja de crecer por la
contribucin de asesores, formadores y suministradores de tecnologas o productos.
Desde la dcada de 1990, ITIL ha dejado de ser slo un marco terico para convertirse
en una metodologa y una filosofa compartida por todos los que la utilizan en la
prctica. Al tratarse de un marco de trabajo de Mejores Prcticas para la Gestin de
Servicios de TI, ITIL presenta, como cualquier marco de trabajo, ventajas y desventajas;
as se describen en la Seccin 2.4. Por supuesto, ITIL se desarroll por las ventajas
anteriormente mencionadas. Muchas de las aplicaciones de Mejores Prcticas sirven
para evitar posibles problemas o para resolverlos en caso de que se produzcan.
ITIL y los Modelos de Gestin de TI ITIL Certificacin. ITIL es una marca registrada de
OGC. No cabe duda de la importancia que tiene la Gestin de Servicios TI hoy en da.
Mientras que hasta los aos 70 la mayor preocupacin estaba en la mejora y desarrollo
de nuevo hardware, y hasta bien entrados los 80, este inters era por el desarrollo del
software, la ltima dcada del pasado siglo se ha centrado en la Gestin de los
Servicios. Durante dcadas la Gestin de Servicios se ha visto como una continuacin
o extensin al desarrollo, pero en los ltimos aos se est cambiando esta situacin ya
que como corroboran estudios de consultora, entre 70% y 80% de los gastos en el
Ciclo de Vida de los sistemas de informacin son en la fase de explotacin. Esto se
puede ver reforzado con situaciones en las que el 60% del tiempo de los
desarrolladores es dedicado a tareas de mantenimiento, o que las actividades diarias
de la plantilla de TI parecen centrase en tareas de gestin. A la vista de esta situacin,
nos debemos preguntar lo que entendemos por Gestin de Servicios de TI. Algunas
definiciones que podemos dar a este concepto seran: El arte de gestionar el sector
TIC1 completo de una organizacin, su infraestructura y sus actividades as como un
conjunto coherente de procesos dirigidos a la provisin de servicios a la organizacin,
del World Class TI Service Management Guide 2000 ITSM es un conjunto de procesos
que cooperan para asegurar la calidad de servicios conectados y vivos, de acuerdo a
los niveles de servicios acordados con el cliente, sobrepuestos a los dominios de
gestin como la gestin de sistemas, la gestin de redes y el desarrollo de sistemas y a
otros mucho dominios de procesos como la Gestin de los Cambios, la Gestin de
Activos y la Gestin de Problemas. De otra manera, la Gestin de Servicios TI (ITSM)
es la alineacin sistemtica a la planificacin, desarrollo, entrega, y soporte de los

servicios TI para la empresa. Une el espacio entre la comunidad dedicada al negocio y

el departamento de TI a travs de la facilitacin de la comunicacin y la creacin de una
asociacin de y para el negocio. Esta nueva actividad est cada da ms madura, y
prueba de esta madurez es la cantidad de marcos de trabajo tericos que surgen cada
da. En la relativa corta historia de la actividad de la Gestin de Servicio TI, una gua se
ha convertido en el estndar de facto de vario pases: ITIL v2 y en adelante ITIL v3.
Para comprobar la dimensin que est tomando la gestin de servicios en las empresas
basta con ver la cantidad de conferencias, estudios y publicaciones que alrededor de
este tema estn surgiendo en los ltimos aos. Las grandes organizaciones y los
principales proveedores estn invirtiendo mucho dinero en desarrollar sus propios
marcos de referencia para la Gestin de Servicios TI. Muchas de estas aproximaciones
que estn surgiendo estn muy relacionadas con las mejores prcticas definidas por
ITIL y profundizan en este tema. Cada marco de trabajo tiene sus propias ventajas
dependiendo de la situacin en la que se aplique, pero todo ellos estn diseados para
adoptar una alineacin orientada a procesos, dejando atrs los tiempos de la
orientacin a funciones y organizaciones.

ISO 9126: 1991

Hoy en da las compaas de todo el mundo industrializado reconocen que la calidad

del producto se traduce en ahorro de costos y en una mejora general. La industria de
desarrollo de software no es la excepcin, por lo que en los ltimos aos se han
realizado intensos trabajos para aplicar los conceptos de calidad en el mbito del
software. Hablar de calidad del software implica la necesidad de contar con parmetros
que permitan establecer los niveles mnimos que un producto de este tipo debe
alcanzar para que se considere de calidad. El problema es que la mayora de las
caractersticas que definen al software no se pueden cuantificar fcilmente;
generalmente, se establecen de forma cualitativa, lo que dificulta su medicin, ya que
se requiere establecer mtricas que permitan evaluar cuantitativamente cada
caracterstica dependiendo del tipo de software que se pretende calificar. En este
sentido se han realizado muchos trabajos que establecen propuestas para el
establecimiento de los factores cualitativos que afectan la calidad del software. Entre los
principales estn los factores de calidad de McCall [1][4] y aquellos propuestos por
HewlettPackard (FURPS: Funcionality

Modelo de calidad para mtricas internas y externas

Funcionalidad Adecuacin Capacidad del producto software para proporcionar un
conjunto apropiado de funciones para tareas y objetivos de usuario especificados.
Exactitud Capacidad del producto software para proporcionar los resultados o efectos
correctos o acordados, con el grado necesario de precisin.
Interoperabilidad
Capacidad del producto software para interactuar con uno o ms sistemas
especificados. Seguridad de acceso Capacidad del producto software para proteger
informacin y datos de manera que las personas o sistemas no autorizados no puedan
leerlos o modificarlos, al tiempo que no se deniega el acceso a las personas o sistemas
autorizados Cumplimiento funcional Capacidad del producto software para adherirse a
normas, convenciones o regulaciones en leyes y prescripciones similares relacionadas
con funcionalidad.
Fiabilidad Madurez Capacidad del producto software para evitar fallar como resultado
de fallos en el software. Tolerancia a fallos Capacidad del software para mantener un
nivel especificado de prestaciones en caso de fallos software o de infringir sus

interfaces especificados. Capacidad de recuperacin Capacidad del producto software

para reestablecer un nivel de prestaciones especificado y de recuperar los datos
directamente afectados en caso de fallo. Cumplimiento de la fiabilidad Capacidad del
producto software para adherirse a normas, convenciones o regulaciones relacionadas
con la fiabilidad.
Usabilidad Capacidad para ser entendido Capacidad del producto software que permite
al usuario entender si el software es adecuado y cmo puede ser usado para unas
tareas o condiciones de uso particulares. Capacidad para ser aprendido Capacidad del
producto software que permite al usuario aprender sobre su aplicacin. Capacidad para
ser operado Capacidad del producto software que permite al usuario operarlo y
controlarlo. Capacidad de atraccin Capacidad del producto software para ser atractivo
al usuario. Cumplimiento de la usabilidad Capacidad del producto software para
adherirse a normas, convenciones, guas de estilo o regulaciones relacionadas con la
usabilidad. Eficiencia Comportamiento temporal Capacidad del producto software para
proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo
condiciones determinadas. Utilizacin de recursos Capacidad del producto software
para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo
su funcin bajo condiciones determinadas. Cumplimiento de la eficiencia Capacidad
del producto software para adherirse a normas o convenciones relacionadas con la
eficiencia.
Mantenibilidad Capacidad para ser analizado Es la capacidad del producto software
para serle diagnosticadas deficiencias o causas de los fallos en el software, o para
identificar las partes que han de ser modificadas. Capacidad para ser cambiado
Capacidad del producto software que permite que una determinada modificacin sea
implementada. Estabilidad Capacidad del producto software para evitar efectos
inesperados debidos a modificaciones del software. Capacidad para ser probado
Capacidad del producto software que permite que el software modificado sea validado.
Cumplimiento de la mantenibilidad Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la mantenibilidad.
Portabilidad Adaptabilidad Capacidad del producto software para ser adaptado a
diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de
aquellos proporcionados para este propsito por el propio software considerado.
Instabilidad Capacidad del producto software para ser instalado en un entorno
especificado. Coexistencia Capacidad del producto software para coexistir con otro
software independiente, en un entorno comn, compartiendo recursos comunes.

Capacidad para reemplazar Capacidad del producto software para ser usado en lugar
de otro producto software, para el mismo propsito, en el mismo entorno Cumplimiento
de la portabilidad Capacidad del producto software para adherirse a normas o
convenciones relacionadas con la portabilidad

La norma ISO/IEC 9126 (1991): Software Product Evaluation (Evaluacin de los

Productos de Software) indica las caractersticas de calidad y los lineamientos para su
uso, la cual fue desarrollada para dar soporte a esas necesidades, define seis
caractersticas de calidad y describe un modelo de procesos para la evaluacin de
productos
de
software.

Utilidad de las normas ISO / IEC 9126.

Este estndar est pensado para los desarrolladores, adquirentes, personal que
asegure la calidad y evaluadores independientes, responsables de especificar y evaluar
la calidad del producto software.
Por tanto, puede servir para validar la completitud de una definicin de requisitos,
identificar requisitos de calidad de software, objetivos de diseo y prueba, criterios de
aseguramiento de la calidad, etc.
La calidad de cualquier proceso del ciclo de vida del software (estndar ISO 12.207)
influye en la calidad del producto software que, a su vez, contribuye a mejorar la calidad
en el uso del producto.
La calidad del software puede evaluarse midiendo los atributos internos (medidas
estticas o productos intermedios) o atributos externos (comportamiento del cdigo
cuando se ejecuta).
El estndar ISO/IEC 9126-1 define un marco conceptual de calidad que considera los
siguientes factores: Calidad del Proceso, Calidad del Producto de Software (Calidad
Interna y Calidad Externa) y Calidad en Uso