Trabajo Ingeniera de Software

Nombre: Marcelo Fuentes C.

Ramo: Ingeniera de Software
Fecha de entrega: 30-03-2015

ndice
Portada ---------------------------------------------------------------------------1
ndice

---------------------------------------------------------------------------2

Introduccin ---------------------------------------------------------------------3
Desarrollo ------------------------------------------------------------------------4
1

Ciclo de vida clsico o en cascada----------------------------------------4

Construccin de prototipos--------------------------------------------------5

Modelo evolutivo---------------------------------------------------------------6

Tcnicas de generacin CCMI---------------------------------------------10

Que es ITIL?---------------------------------------------------------------------12

Paradigma orientado a objetos---------------------------------------------17

Que es BPMN?-----------------------------------------------------------------18
Conclusin----------------------------------------------------------------------23
Bibliografa----------------------------------------------------------------------24

Introduccin

Actualmente el software se ha vuelto un elemento relevante en nuestra sociedad,

actuando como productor de servicios y facilitando actividades cotidianas y
profesionales del ser humano. En la industria del software las mejoras en el
hardware son apresuradas y para hacer uso de estas tecnologas se necesita de
un software de mayor complejidad. A parte de ms complejo, se necesita que sea
confiable, de calidad, que satisfaga al cliente y que se desarrolle en el menor
tiempo posible.
El termino ingeniera de software se refiere al establecimiento y uso de principios
robustos de la ingeniera a fin de obtener econmicamente software que sea fiable
y que funcione eficientemente sobre mquinas reales, los modelos descritos a lo
largo del trabajo nos guiaran al desarrollo correcto y eficiente de un software.

A)
Ciclo de vida clsico o en cascada
Este enfoque del desarrollo de software ha sido el ms utilizado y en la actualidad,
pese a la aparicin de metodologas giles, sigue siendo la solucin predominante,
si bien, en cada organizacin o en cada de proyecto se puede llevar a cabo con
ciertas variantes.
Anlisis: Esta fase comprendera desde la posible obtencin de unos objetivos o
requisitos iniciales para determinar la viabilidad del sistema y escrutar las distintas
alternativas de solucin, pasando por la elaboracin del catlogo de requisitos,
hasta la realizacin de casos de uso, prototipado de pantallas e informes, como
una primera especificacin del plan de pruebas.
Diseo: El anlisis describe el sistema sin entrar en caractersticas propias de la
implementacin, es en esta fase donde se adapta ese anlisis generalista a la
solucin concreta que se quiere llevar a cabo, definindose la arquitectura general
del sistema de informacin, su divisin en subsistemas de diseo, el modelo de
datos lgico, el modelo de clases (en el caso de un diseo orientado a objetos), la
especificacin detallada del plan de pruebas, etc
Codificacin: En esta fase se realiza la construccin del sistema de informacin
y las pruebas relacionadas con dicho proceso, como son las unitarias, integracin
y de sistema, as como otras actividades propias de las etapas finales de un
desarrollo como es la realizacin de la carga inicial de datos (si bien en muchos
casos se deja esto para cuando el producto est en produccin) y/o la
construccin del procedimiento de migracin.
Pruebas: En esta etapa se realizara la instalacin del sistema en un entorno de
pruebas lo ms parecido posible al de produccin (entorno de preproduccin)
donde se realizaran las pruebas de implantacin (que verifican principalmente
aspectos no funcionales) y las de aceptacin, donde los usuarios validan que el
sistema hace lo que realmente esperaban (sin que se deba olvidar que los lmites
los establecen los modelos realizados previamente y que han debido ser
validados). Por ltimo se realizara la implantacin del sistema en el entorno de
produccin.
Mantenimiento: Una vez que el sistema se encuentra en produccin, se
realizarn sobre el mismo diversas tareas4 de mantenimiento, que en funcin de su

naturaleza se clasifican en correctivos, evolutivos, adaptativos y perfectivos. Estas

tareas de mantenimiento sern consecuencia de incidencias y peticiones
reportadas por los usuarios y los directores usuarios.
En el ciclo de vida clsico en funcin de las modificaciones y/o correcciones que
se realizan en una etapa ser necesario la vuelta a fases previas para hacer
coherente el proceso de desarrollo y los modelos.

CONSTRUCCION DE PROTOTIPOS
A menudo un cliente define un conjunto de objetivos generales para el software,
pero no identifica los requisitos detallados de entrada, procesamiento o salida. 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 humana mquina, entonces en este caso cuando utilizamos
la construccin de prototipos.

El paradigma de construccin de prototipos se inicia con la comunicacin. El

ingeniero de software y el cliente encuentran y definen los objetivos globales para
el software, identifican los requisitos conocidos y las reas del esquema en donde
es necesaria ms definicin. Entonces se5plantea con rapidez una iteracin de

construccin de prototipos y se presenta el modelado (en la forma de un diseo

rpido). El diseo rpido se centra en una representacin de aquellos aspectos del
software que sern visibles para el usuario final. El diseo rpido conduce a la
construccin de un prototipo. Despus, el prototipo lo evala el usuario y con la
retroalimentacin se refinan los requisitos del software que se desarrollar. La
iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del
cliente. Esto permite que al mismo tiempo se desarrollador entienda mejor lo que
se debe hacer.

7.1.1 MODELO EVOLUTIVO

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez
ms completas y complejas, hasta llegar al objetivo final deseado; incluso
evolucionar ms all, durante la fase de operacin. Los modelos Iterativo
Incremental y Espiral (entre otros) son dos de los ms conocidos y utilizados del
tipo evolutivo.
La idea detrs de este modelo es el desarrollo de una implantacin del sistema
inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que
se desarrolle el sistema adecuado.Una ventaja de este modelo es que se obtiene
una rpida realimentacin del usuario, ya que las actividades de especificacin,
desarrollo y pruebas se ejecutan en cada iteracin.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario

los requisitos hasta llegar a un sistema final. El desarrollo comienza con las
partes que se tiene ms claras. El sistema evoluciona conforme se aaden
nuevas caractersticas propuestas por el usuario.
Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario
y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no estn claros para el
usuario y se utiliza un prototipo para experimentar con ellos. El prototipo
ayuda a terminar de definir estos requisitos.

El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el

enfoque incremental de desarrollocomo una forma de reducir la repeticin del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirirexperiencia con el sistema. Este modelo
se conoce tambin bajo las siguientes denominaciones:

Mtodo de las comparaciones limitadas sucesivas.

Ciencia de salir del paso.

Mtodo de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la
filosofa interactiva de Construccin de Prototipos. Como se muestra en la Figura
1, el modelo incremental aplica secuencias lineales de forma escalonada mientras
progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento
del software. El primer incremento generalmente es un producto esencial
denominado ncleo.
En una visin genrica, el proceso se divide en 4 partes:

Anlisis

Diseo

Cdigo

Prueba

Sin embargo, para la produccin del Software, se usa el principio de trabajo en

cadena o Pipeline. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o
desecha elementos al final de cada incremento a fin de que el software se adapte
mejor a sus necesidades reales. El proceso se repite hasta que se elabora el
8

producto completo. De esta forma el tiempo de entrega se reduce

considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada
incremento la entrega de un producto completamente operacional. Este modelo es
particularmente til cuando no se cuenta con una dotacin de personal suficiente.
Los primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se aadir personal, de ser necesario. Por otro lado los incrementos
se pueden planear para gestionar riesgos tcnicos.
7.1.1.1.1 Durante el proceso se trata de llevar a cabo al proyecto en diferentes
partes que al final terminar siendo la solucin completa requerida por el
cliente, pero stas partes no se pueden realizar en cualquier orden, sino
que dependen de lo que el cliente este necesitando con ms urgencia,
de los puntos ms importantes del proyecto, los requerimientos ms
bsicos, difciles y con mayor grado de riesgo, ya que estos se deben
hacer al comienzo, de manera que se disminuya la dificultad y el riesgo
en cada versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que
podr ser entregada al cliente para que ste pueda trabajar en ella y el
programador pueda considerar las recomendaciones que el cliente efecte para
hacer mejoras en el producto. Estas nuevas mejoras debern esperar a ser
integradas en la siguiente versin junto con los dems requerimientos que no
fueron tomados en cuenta en la versin anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa
del sistema, seguido de sucesivos incrementos funcionales. Cada incremento
tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad
ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre
el mismo, sino nicamente correccin de errores. Dado que la arquitectura
completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos
completos al comienzo del desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos,
las funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de
requisitos funcionales y ser el cliente quien se encarga de priorizar que
funcionalidades son mas importantes. Con las funcionalidades priorizadas, se
puede confeccionar un plan de incrementos, donde en cada incremento se indica
un subconjunto de funcionalidades que el sistema entregar. La asignacin de
funcionalidades a los incrementos depende de la prioridad dada a los requisitos.
Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Tcnicas de generacin (CMMI, ITIL)

CMMI (Capability Maturity Model Integration)
Qu es CMMI?
CMMI son las siglas de Capability Maturity Model Integration. Es un modelo
desarrollado por elSoftware Engineering Institute para la mejora de los procesos
de las empresas de software que califica las compaas segn su nivel de
madurez. Por proceso se entiende un conjunto de fases sucesivas que llevan a la
obtencin de un resultado, y por nivel de madurez, el grado de calidad que
alcanzan los procesos
CMMI establece una serie de buenas prcticas que las empresas deben cumplir
para ser consideradas de un grado de madurez determinado a la hora de generar
resultados. Pero ojo: CMMI no te dice cmo llevar a cabo estas prcticas,
simplemente te indica qu debes cumplir. Es cosa de cada empresa buscar el
modo de cumplir con dichas prcticas (y es aqu donde comienza el gran negocio
de los consultores en torno a CMMI
Existen tres tipos de CMMI, nombrados como constelaciones por algn gur de las
altas esferas. Est la constelacin CMMI for Acquisition, para la mejora de
procesos de contratacin externa, laCMMI for Services, para el establecimiento y
la entrega de servicios y CMMI for Development, para la mejora del desarrollo de
productos (software).

Los niveles de madurez de CMMI

CMMI est representado escalonadamente en 5 niveles de madurez, que califican
a las empresas segn la calidad de su proceso de produccin. Estos niveles,
adems de por su correspondiente ordinal (del 1 al 5), se conocen por el adjetivo
que los describe: Inicial, Gestionado, Definido, Cuantitativamente gestionado y el
ms alto de todos, Optimizado. Veamos brevsimamente en qu consiste cada uno
de ellos.
Nivel 1 (Inicial): La organizacin no sigue conscientemente las prcticas
especificadas en el modelo CMMI, pero de una forma u otra consigue que sus
10

productos salgan al mercado. Supone una gran dependencia de los llamados

hroes, profesionales sobresalientes que con su esfuerzo y habilidad personal
sacan a la empresa del atolladero. La organizacin no genera conocimiento y la
prdida de estos hroes supone generalmente la prdida de la capacidad
acumulada.

Nivel 2 (Gestionado): Supone el cumplimiento, por parte de cada proyecto, de

varias reas de proceso de CMMI relacionadas con la gestin de requisitos, la
planificacin, la monitorizacin, la gestin de la configuracin, el aseguramiento de
la calidad, el acuerdo con los proveedores y la medicin y anlisis de los procesos.
Se trata de asegurar que las buenas prcticas se mantengan independientemente
de los vaivenes coyunturales que afecten a la organizacin. El conocimiento reside
en la organizacin.
Nivel 3 (Definido): En este nivel, los procesos ya no slo se definen de manera
independiente para cada proyecto sino que toda la organizacin goza de unas
pautas comunes. Se instaura una serie de procesos que, llevando la explicacin al
paradigma de la orientacin a objetos, suponen la clase sobre la cual se instancian
los proyectos. En resumidas cuentas, la empresa goza de una plantilla bien
caracterizada que al ser aplicada a cada caso particular, genera un proyecto.
Nivel 4 (Cuantitativamente gestionado): Llegados a este punto, la organizacin ya
no slo gestiona los proyectos mediante procesos bien definidos, sino que
adems, se fijan objetivos tangibles que los procesos deben cumplir en lo relativo
a su calidad, de manera que se analizan estadsticamente los procesos,
propiciando una exactitud y predictibilidad, si se me permite el palabro, de la que
no goza el nivel anterior.
Nivel 5 (Optimizado): En el nivel ms alto de CMMI, la organizacin entera
experimenta una optimizacin continua de los procesos a travs de la innovacin
en los mismos y de las mejoras tecnolgicas. Se modifican y reconducen los
procesos en funcin de los defectos revelados durante el anlisis estadstico.
Y cmo se le reconoce oficialmente a una organizacin su nivel de
madurez?
La evaluacin, conocida como Appraisal, del grado de madurez de una empresa
es llevada a cabo por un equipo que debe estar formado, segn el
mtodo SCAMP(Standard CMMI Appraisal Method for Process Improvement), por
un evaluador oficial (Lead Appraiser) formado por el SEI y por un conjunto de
personas que deben haber recibido el curso de introduccin a CMMI y entre las
11

que se puede encontrar, y de hecho es lo habitual, personal de la propia

organizacin. Este enfoque de que gente de la propia organizacin evale el grado
de madurez que su empresa merece puede parecer chocante, y con razn. Sin
embargo de una forma u otra el complejo mtodo SCAMPI se las apaa para
asegurar la objetividad, o al menos eso garantiza el SEI.

Se trata de una prueba exigente, que puede llegar a durar varias semanas,
durante las cuales, entre otras cosas, se recogen y analizan las evidencias de
cumplimiento de las reas de proceso a evaluar y se entrevista a los involucrados
en la organizacin. Al finalizar la Appraisal, el evaluador emite un informe que
debe ser confirmado en Estados Unidos por nuestros amigos del SEI

ITIL (Information Technology Infrastructure Library)

Que es ITIL?
Los departamentos de informticas; por la complejidad de sus procesos, de sus
activos, de sus profesionales, de su deslinde del resto de la organizacin, y en
general, por su difcil e indescifrable entramado, requieren de un conjunto de
metodologas y herramientas que los ayuden a prestar sus servicios de una
manera eficaz y efectiva. Por muchos aos, todo estuvo centralizado y controlado
desde una especie de jefatura superior. Sin embargo, con el advenimiento de
Internet, la complejidad de los negocios, la globalizacin, la fuerte competencia, y
la necesidad de sobrevivir en un contexto cada vez ms enrarecido, los directores
de informtica han necesitado herramientas que les ayuden a aadir valor y al
mismo tiempo les permita gestionar sus recursos, en muchos casos intangibles y
estratgicos, de manera ptima. ITIL es una de esas herramientas que saltan a
la palestra para proporcionar al gerente IT la ayuda necesaria para que pueda
lograr los objetivos organizaciones de manera productiva.
ITIL (Information Technology Infrastructure Library) es un conjunto de mejores
prcticas (procedimientos, tcnicas, mtodos, o actividades eficientes y efectivos
en proporcionar un determinado resultado), enmarcadas en un conjunto de
procesos (biblioteca) cuyo objetivo es organizar de manera productiva y holstica
los diferentes servicios que proporciona el departamento de tecnologa de la
informacin (informtica) de una organizacin.

12

Definido en los aos 80 y popularizado durantes los

90s, ITIL trata de poner en cintura a los
departamentos de informtica, al organizar el caos
generado por la generacin Cliente/Servidor,
concepto que estuvo influenciado por la conocida
tendencia de sistemas abiertos (Open Systems),
compuesta por herramientas tecnolgicas (Hadware,
Software y Telecomunicaciones) integradas de manera armnica, e
interactuando perfectamente entre s. Todo despus de un fuerte dominio de
mercado por parte del gigante azul IBM.
Creado por la OGC (Office of Government Commerce) del Reino Unido
(www.itil.co.uk), y popularizado por analistas, consultores, y empresas de software,
ITIL se ha convertido en un estndar de facto, presenta entre sus principales
beneficios los siguientes: 1) abre el camino a un concepto en boga (el Gobierno
IT) que trata de auditar y controlar de alguna manera las decisiones de inversin y
presupuesto de muchos departamentos de IT, 2) introduce un orden en los
elementos tcnicos y tecnolgicos que conformar la infraestructura informtica de
una organizacin, relaciona esos elementos, facilitando la gestin y legalidad de
todos sus componentes, y en general, 3) trata de ahorrar el coste de la prestacin
de servicios de IT en el largo plazo. En resumen, se trata de una nueva moda
informtica, que trata de cubrir las mismas deficiencias que han prevalecido
siempre, y que de algn modo han legitimado la evolucin conceptual y
pragmtica de la informtica.
La visin que tiene ITIL de la informtica en la empresa, al menos hasta la versin
2, es en trminos de Servicios. Es decir, las unidades de negocios de cualquier
organizacin demandan y/o son usuarias de servicios informticos. Dichos
servicios son enumerados y reflejados en un catlogo de servicios, el cual es
negociado entre el cliente (el que paga por el servicio en la organizacin), y los
gestores informticos. A su vez dichos servicios son utilizados por los usuarios
finales (end-users) en los procesos neurlgicos y de apoyo de la organizacin.
Para poder cumplir con los acuerdos de servicios con los clientes
(denominados Service Level Agreements SLA), la biblioteca ITIL se divide en
dos (2) grandes bloques:
1) Soporte a los Servicios IT, y
2) Entrega o Provisin de Servicios.
A su vez, cada una de las dos (2) grandes bibliotecas que conforman ITIL se divide
en los siguientes procesos:

13

Cada uno de estos procesos tiene vida y/o autonoma propia. Organizndose de
acuerdo a sus necesidades. Quizs el ms popular y utilizado es el Service Desk
(el cual es una funcin organizacional), la gestin de incidencias, la de problemas
y gestin de cambios.
Reviste comentario especial la gestin de configuracin, la cual es la garante y
depositara de todos los tems de configuracin de la infraestructura, y todo lo
hace, almacenando y relacionando dicha informacin en una base de datos
conocida popularmente como la CMDB (Configuration Management Data Base).
Base de Datos que juega un rol estelar y central en la introduccin e implantacin
de ITIL en una organizacin.
ITIL es un intento interesante de organizar y poner en cintura a los
departamentos de informtica o IT. Persigue, entre otras cosas, el ahorre de
costes en el largo plazo, as como el incremento en productividad y eficiencia de
los informticos.
Algunas debilidades de ITIL se manifiestan en lo complejo y costoso que resulta su
implantacin en grandes organizaciones, no sin mencionar la cuasi imposible tarea
de mantener actualizada y perfectamente funcionando la CMDB, el control de los
cambios, y entornos multi-culturales, donde una vasta mayora de empresas
contratan outsourcing del Service Desk por razones de estrategia de negocios y
ahorro de costes.
Nuevas versiones de ITIL aparecern e irn realizando correcciones a las
mejores prcticas, el ciclo de la tecnologa seguir su curso, nuevos conceptos,
herramientas, tecnologas y tcnicas emergern, y validarn si el concepto de ITIL
es una intento vlido de mantener en orden, sin duda alguno, uno de los
departamentos ms difciles de gestionar para la alta gerencia de cualquier
organizacin.
Para clarificar el concepto, la figura 1 presenta una puesta en marcha estndar
simulada de ITIL en una organizacin. Tericamente se describen los puntos y
pasos para su efectiva implantacin.
Como funciona ITIL

14

Paso 1 y 2 (a) Todo comienza con la organizacin como gran demandante de

servicios informticos, el cliente o el que asigna y decide el presupuesto para
estos servicios de la organizacin acuerda o negocia los acuerdos de servicios
(SLA) con la direccin de informtica. Se crea un catalogo de servicios, costes,
tiempos, y otras condiciones de los servicios que prestar informtica a la
organizacin. Por ejemplo, servicios de e-Mail, Intranet, ERP, CRM, Internet,
impresin, entre otros.
Paso 3 (b) Una vez puestos en marcha los servicios se define e instala un
departamento o unidad de Service Desk (escritorio de ayuda), el cual ser el punto
de contacto de los usuarios de los servicios con el departamento de informtica.
Se trata de un nico punto de comunicacin de los usuarios con informtica, en
donde se podrn abrir incidencias y nuevos requerimientos de servicios.
Paso 3 (c) Los responsables del Service Desk, reciben y registran las solicitudes
de los usuarios. En casos de incidentes de los servicios, primero buscan en la
base de datos de errores conocidos o una especie de base de datos de
conocimientos, para verificar si la solucin al incidente existe, y as dar la solucin
al usuario de forma inmediata.
Paso 3 (d) En caso de no poder solucionar el incidente al usuario, el operador de
Service Desk lo escala a la persona apropiada para que lo soluciones. En otras
palabras se pasa a la Gestin de Incidentes para que se busque la solucin al
usuario.
Paso 4 (e) Si el incidente es recurrente y/o no es encontrado, se pasa a la
Gestin de problemas en donde se buscar la solucin definitiva. De ser posible
se escala a proveedores externos (por ejemplo IBM, SUN, etc.) para que ayude en
la solucin del mismo. Una vez solucionado el problema, se documenta e
incorpora a la base de datos de errores conocidos.
Paso 4 (f) Muchas veces los usuarios solicitan nuevos servicios a la gerencia de
informtica. Service Desk en este caso abre una peticin de servicios y lo pasa a
la Gestin del Cambio para que se abra un Cambio y se proceda, previa
evaluacin por parte de un comit asesor (CAB), con su implementacin. Un
cambio es toda peticin de servicios que cambia la infraestructura informtica de
la organizacin.
Paso 4 (g) La gestin de versiones se refiere, como su nombre lo indica, al
mantenimientos de versiones de software por parte de la direccin informtica.
Abarca la gestin tecnolgica y control legal de las versiones de software
instaladas en la infraestructura de la organizacin.

15

Paso 4 (h) La base de datos de configuracin o CMDB mantiene el inventario de

todos los tems de configuracin (por ejemplo, PCs, impresoras, software,
documentacin, personas, etc.) de la organizacin, la cual es accedida y
actualizada por los diferentes procesos que conforman ITIL.
Pasos 2 (i), (j), (k) y (l) Son necesarios y estratgicos para mantener los
servicios informticos operando de manera efectiva y eficaz. Y tambin utilizan a la
CMDB como referencia y consulta de los componentes de la infraestructura
informtica.

Figura 1 Cmo funciona ITIL

B) Paradigma orientado a objetos
La programacin orientada a objetos o POO (OOP segn sus siglas en ingls) es
un paradigma de programacin que usa objetos y sus interacciones, para
disear aplicaciones y programas de computadoras. Est basado en varias
tcnicas, incluyendo herencia, abstraccin, polimorfismo y encapsulamiento.
Un paradigma de programacin representa un enfoque particular o filosofa
para la construccin del software. No es mejor uno que otro sino que cada uno
tiene ventajas y desventajas.
En la POO las entidades centrales son los objetos, que son tipos de datos que
encapsulan con el mismo nombre estructuras de datos, operaciones o
algoritmos que manipulan esos datos.
Objeto: Entidad provista de un conjunto16de propiedades o atributos (datos) y de

comportamiento o funcionalidad (mtodos) los mismos que consecuentemente

reaccionan a eventos. Se corresponde con los objetos reales del mundo que
nos rodea, o a objetos internos del sistema (del programa). Es una instancia a
una clase.
Propiedades de un Modelo

ABSTRACCIN
Es la propiedad que permite representar las caractersticas esenciales de un
objeto sin preocuparse de las restantes caractersticas. Se centra en la vista
externa de un objeto de modo que sirve para separar el comportamiento
esencial de un objeto, de su implementacin.
ENCAPSULAMIENTO
Es la propiedad que permite asegurar que el contenido de la informacin de un
objeto esta oculta al mundo exterior, es decir el objeto A no conoce lo que hace
el objeto B y viceversa.
La encapsulacin permite la divisin de un programa en mdulos, esos
mdulos se implementan mediante clases, de forma que una clase representa
la encapsulacin de una abstraccin.
MODULARIDAD
Es la propiedad que permite subdividir una aplicacin en partes ms pequeas
llamadas mdulos, cada una de las cuales debe ser tan independiente como
sea posible de la aplicacin en si y de las partes restantes.
JERARQUIA
Es la propiedad que permite una ordenacin de las abstracciones, las dos
jerarquas ms importantes de un sistema complejo son:
Estructuras de clases (jerarqua Es-Un: Generalizacin/Especificacin)
Estructuras de objetos (jerarqua Parte-De: Agregacin)

C) BPMN
Que es BPMN?
es una notacin grfica estandarizada que permite el modelado de procesos de
negocio, en un formato de flujo de trabajo (workflow). BPMN fue inicialmente
desarrollada por la organizacin Business Process Management Initiative (BPMI),
y es actualmente mantenida por el Object Management Group (OMG), despus de
la fusin de las dos organizaciones en el ao 2005.
El principal objetivo de BPMN es proporcionar una notacin estndar que sea
fcilmente legible y entendible por parte de todos los involucrados e interesados
del negocio (stakeholders). Entre estos interesados estn los analistas de negocio
(quienes definen y redefinen los procesos), los desarrolladores tcnicos
(responsables de implementar los procesos) y los gerentes y administradores del
negocio (quienes monitorizan y gestionan los procesos). En sntesis, BPMN tiene
la finalidad de servir como lenguaje comn para cerrar la brecha de comunicacin
que frecuentemente se presenta entre el diseo de los procesos de negocio y su
implementacin.
17

Actualmente hay una amplia variedad de lenguajes, herramientas y metodologas

para el modelado de procesos de negocio. La adopcin cada vez mayor de la
notacin BPMN como estndar, ayudar a unificar la expresin de conceptos
bsicos de procesos de negocio as como conceptos avanzados de modelado

Simbologia
Eventos
Estn representados grficamente por un crculo y describen algo que sucede (lo
contrario de las Actividades que son algo que se hace). Los eventos tambin
pueden ser clasificados como Capturado o Lanzado.
Evento Inicial
Acta como un disparador de un proceso. Se representa grficamente por
un crculo de lnea delgada y dentro del crculo esta relleno de color verde.
Este evento permite Capturar.
Evento Final
Indica el final de un proceso. Est representado grficamente por un crculo
de lnea gruesa y dentro del crculo esta relleno del color rojo. Este evento
permite Lanzar.
Evento Intermedio
Indica que algo sucede entre el evento inicial y el evento final. Est
representado grficamente por un crculo de doble lnea simple y dentro del
crculo relleno de color naranja. Este evento puede Capturar o Lanzar.

Actividades
Se representan por un rectngulo con sus vrtices redondeados y describe el tipo
de trabajo que ser realizado.

Tarea

18

Una tarea representa una sola unidad de trabajo que no es o no se puede

dividir a un mayor nivel de detalle de procesos de negocio sin diagramacin
de los pasos de un procedimiento.
Subproceso
Se utiliza para ocultar o mostrar otros niveles de detalle de procesos de
negocio, cuando se minimiza un subproceso se indica con un signo ms
contra de la lnea inferior del rectngulo, cuando se expande el rectngulo
redondeado permite mostrar todos los objetos de flujo, los objetos de
conexin, y artefactos. Tiene, de forma auto-contenida, sus propios eventos
de inicio y fin; y los flujos de proceso del proceso padre no deben cruzar la
frontera.

Compuertas (Control de Flujo)

Se representan por una figura de diamante y determinan si se bifurcan o se
combinan las rutas dependiendo de las condiciones expresadas.

Objetos de conexin permitirn conectar cada uno de los objetos de flujo. Hay
tres tipos: Secuencias, Mensajes y Asociaciones.
Flujo de Secuencia
Est representado por lnea simple continua y flechada; y muestra el orden
en que las actividades se llevarn a cabo. El flujo de secuencia puede
tener un smbolo al inicio, un pequeo diamante indica uno de un nmero
de flujos condicionales desde una actividad, mientras que una barra
diagonal (slash) indica el flujo por defecto desde una decisin o actividad
con flujos condicionales.
Flujo de Mensaje
Est representado por una lnea discontinua con un crculo no relleno al
inicio y una punta de flecha no rellena al final. Esto nos dice, que el flujo de
mensaje atraviesa la frontera organizativa (por ejemplo, entre piscinas). Un
flujo de mensaje no puede ser utilizado para conectar actividades o eventos
dentro de la misma piscina

Asociaciones
19

Se representan por una lnea punteada. Se suele usar para conectar

artefactos o un texto a un objeto de flujo y puede indicar muchas
direccionalidades usando una punta de flecha no rellena (hacia el
artefacto ). La no direccionabilidad podra usarse con el artefacto o un
texto est asociado con una secuencia o flujo de mensaje

Los Carriles de Nado son un mecanismo visual de actividades organizadas y categorizadas,

basados en organigramas funcionales cruzados y en BPMN consta de dos tipos:
Piscina
Representa los participantes principales de un proceso, por lo general, separados por
las diferentes organizaciones. Una piscina contiene uno o ms carriles (en la vida real,
como una piscina olmpica). Una piscina puede ser abierta (por ejemplo, mostrar el
detalle interno), cuando se presenta como un gran rectngulo que muestra uno o ms
carriles, o cerrada (por ejemplo, esconder el detalle interno), cuando se presenta como
un rectngulo vaco que se extiende a lo ancho o alto del diagrama.

Carril
Usado para organizar y categorizar las actividades dentro de una piscina de acuerdo a
su funcin o rol; y se presenta como un rectngulo estrecho de ancho o de alto de la
piscina. Un carril contiene objetos de flujo, objetos de conexin y artefactos.

Los Artefactos permiten a los desarrolladores llevar algo ms de informacin al

modelo o diagrama. De esta manera, el modelo o diagrama se hace ms legible. Son
tres artefactos predefinidos y son:
Objetos de Datos
Muestra al lector cual es el dato que deber ser requerido o producido en una
actividad.

20

Grupos
Se representan por un rectngulo de lneas discontinuas y vrtices redondeados. El
Grupo se utiliza para agrupar diferentes actividades pero no afecta al flujo dentro de un
diagrama.

Anotacin
Se utiliza para darle al lector una descripcin entendible del modelo o diagrama

21

EJEMPLO

22

Conclusin

Como conclusin se puede entender que trabajar con software tiene su grado de
dificultad y todo lleva un proceso, es muy bueno que mtodos habituales como
modelos nutran la administracin y las practicas tcnicas deficientes de
programadores y teniendo un mejor enfoque de la empresa y sus procesos. Cabe
destacar que el primer paso hacia la formulacin de soluciones prcticas para la
ingeniera de software es el compromiso de las realidades en este campo.

23

Bibliografa

http://es.wikipedia.org/wiki/Business_Process_Model_and_Notation
https://www.bizagi.com/docs/BPMNbyExampleSPA.pdf
http://www.eduardoriol.com/cmmi-para-principiantes-y-iii/
http://www.eduardoriol.com/cmmi-para-principiantes-i/
http://www.itmadrid.com/blog/que-es-itil/
http://www.notodocodigo.com/blog/paradigma-orientado-a-objetos/
http://www.monografias.com/trabajos14/paradigma/paradigma.shtml
http://procesosoftware.wikispaces.com/Modelo+Espiral
http://www.academia.edu/6362716/METODO_EN_CASCADA
http://tema3isoftware.blogspot.com/p/modelos-de-desarrollo-tecnicas-y.html
http://procesosoftware.wikispaces.com/Modelo+Incremental
http://es.slideshare.net/NesMey/paradigma-orientado-a-objetos-4954115

24