1.

Marco Terico
1.1. Modelo de procesos Prescriptivos
1.1.1. Modelo de Cascada
Es un enfoque metodolgico que ordena rigurosamente las etapas del
ciclo de vida del software, de tal forma que el inicio de cada etapa
debe esperar a la finalizacin de la inmediatamente anterior, quizs el
ms ampliamente utilizado. De esta forma, se reduce mucho la
complejidad de la gestin, ya que basta con no dar por terminada una
etapa hasta que haya cumplido totalmente con sus objetivos. De esta
forma, la siguiente puede apoyarse con total confianza en ella. A la
hora, por ejemplo, de fijar plazos, se podran establecer planes de una
forma totalmente secuencial, quedando perfectamente delimitadas las
responsabilidades de los equipos que desarrollen cada etapa.
En la realidad la aplicacin de este modelo no suele ser tan radical.
Aunque se intenta conseguir la mayor secuencialidad posible, es difcil
evitar las "vueltas atrs". Si despus de la terminacin de alguna etapa
los resultados no son los esperados, en la prctica es muy posible que
el problema est en la mala realizacin de una etapa anterior. Y esto
es as porque no sabemos cmo decidir con total certidumbre que una
etapa ha sido perfectamente desarrollada hasta que se observan las
consecuencias, quizs varias etapas y bastante tiempo despus de
que fue "cerrada". En estos casos, habr que volver a ella, refinando el
producto de una forma iterativa hasta que se considere que tiene la
calidad deseada.
El modelo de ciclo de vida cascada, captura algunos principios bsicos
Planear un proyecto antes de embarcarse en el.
Definir el comportamiento externo deseado del sistema antes de
disear su arquitectura interna.
Documentar los resultados de cada actividad
Disear un sistema antes de codificarlo
Testear un sistema despus de construirlo.

El modelo de cascada est basado en el ciclo convencional de una ingeniera,
el paradigma del ciclo de vida abarca las siguientes actividades:


Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte
de un sistema mayor el trabajo comienza estableciendo los requisitos de todos
los elementos del sistema y luego asignando algn subconjunto de estos
requisitos al software.

Anlisis de los requisitos del software: el proceso de recopilacin de los
requisitos se centra e intensifica especialmente en el software. El ingeniero de
software (Analistas) debe comprender el mbito de la informacin del
software, as como la funcin, el rendimiento y las interfaces requeridas.

Diseo: el diseo del software se enfoca en cuatro atributos distintos del
programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce
los requisitos en una representacin del software con la calidad requerida
antes de que comience la codificacin.
Ingeniera y Anlisis
del Sistema
Anlisis de los
Requisitos
Diseo
Codificacin
Prueba
Mantenimiento

Codificacin: el diseo debe traducirse en una forma legible para la mquina.
El paso de codificacin realiza esta tarea. Si el diseo se realiza de una
manera detallada la codificacin puede realizarse mecnicamente.

Prueba: una vez que se ha generado el cdigo comienza la prueba del
programa. La prueba se centra en la lgica interna del software, y en las
funciones externas, realizando pruebas que aseguren que la entrada definida
produce los resultados que realmente se requieren.

Mantenimiento: el software sufrir cambios despus de que se entrega al
cliente. Los cambios ocurrirn debido a que hayan encontrado errores, a que
el software deba adaptarse a cambios del entorno externo (sistema operativo
o dispositivos perifricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento.

CARACTERISTICAS
Es el ms utilizado.
Es una visin del proceso de desarrollo de software como una sucesin de
etapas que producen productos intermedios.
Para que el proyecto tenga xito deben desarrollarse todas las fases.
Las fases continan hasta que los objetivos se han cumplido.
Si se cambia el orden de las fases, el producto final ser de inferior calidad.

VENTAJAS

La planificacin es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco cualificado.

DESVENTAJAS

No refleja realmente el proceso de desarrollo del software
Se tarda mucho tiempo en pasar por todo el ciclo
Perpetua el fracaso de la industria del software en su comunicacin con el
usuario final
El mantenimiento se realiza en el cdigo fuente
Las revisiones de proyectos de gran complejidad son muy difciles
Impone una estructura de gestin de proyectos

1.1.2. Modelo de Proceso incremental
El modelo incremental fue propuesto por Harlan Mills en 1980. Surgi
el enfoque incremental como 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 adquirir experiencia 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 en cascada. Lo
lleva a cabo en forma iterativa, aplicando secuencias lineales de
manera escalonada conforme avanza el proyecto. Esto permite ir
aumentando gradualmente las capacidades del software.
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


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
producto completo. De esta forma el tiempo de entrega se reduce
considerablemente.

Es de naturaleza interactiva brindando al final de cada incremento la
entrega de un producto completamente operacional.
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.
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.

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

Caractersticas:
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios
con cierta frecuencia.
El usuario se involucra ms.
Difcil de evaluar el costo total.
Difcil de aplicar a los sistemas transaccionales que tienden a ser
integrados y a operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.
Ventajas:
Un proyecto se puede financiar por partes.
Es un modelo apropiado para proyectos grandes.
No es necesario disponer de todos los requerimientos funcionales al
comienzo del proyecto.
Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya
que se implementa la funcionalidad parcial.
Tambin provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada
realimentado, reduciendo sus desventajas slo al mbito de cada
incremento.
Resulta ms sencillo acomodar cambios al acotar el tamao de los
incrementos.

Desventajas:
El modelo incremental no es recomendable para casos de sistemas de
tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de
alto ndice de riesgos.
Requiere de mucha planeacin, tanto administrativa como tcnica.
Requiere de metas claras para conocer el estado del proyecto.
No est pensado para todo tipo de usuario o cliente,
Es verdaderamente til cuando el usuario solicite entregas rpidas,
aunque sean parciales.



1.1.3. Modelo de Proceso evolutivo
El modelo en espiral del proceso del software que originalmente fue
propuesto por Boehm (1988) (Ernest Teniente Lpez, 2003) El modelo
en espiral es una de las ms recomendables para el desarrollo y
creacin de un programa, ya que consta de pocas etapas o fases, las
cuales se van realizando en manera continua y cclica. (Sommerville,
2006)
Barry Boehm: Es un ingeniero informtico estadounidense y tambin
es profesor emrito de esta materia en el departamento de ciencias
tecnolgicas en la Universidad del Sur de California. Es conocido por
sus mltiples aportes a este campo.

Cada ciclo espiral se divide en 4 etapas:
DEFINICION DE OBJETIVOS: Para esta fase del proyecto se definen
los objetivos especficos, Se identifican las restricciones del proceso y
el producto, y es estipula un plan detallado de administracin. Se
identifican los riesgos, se planean estrategias alternativas,
EVALUACION Y REDUCCION DE RIESGOS: Se lleva a cabo un
anlisis detallado para cada uno de los riesgos del proyecto. Se
definen los pasos para reducir dichos riesgos, Por ejemplo si existe el
riesgo de tener requerimientos inapropiados, se desarrolla un prototipo
del sistema.
DESARROLLO Y VALIDACION: Despus de la evaluacin de riesgos
en la interfaz de usuario son dominantes, un modelo de desarrollo
apropiado podra ser la construccin de prototipos evolutivos Si los
riesgos de proteccin son la principal consideracin, un desarrollo
basado en transformaciones formales podra ser el ms apropiado, y
as sucesivamente. EI modelo de cascada es el ms apropiado para el
desarrollo si el mayor riesgo identificado es la integracin de los
subsistemas.
PLANEACION: El proyecto se revisa y se toma la decisin si se debe
continuar con un ciclo posterior de la espiral. Si se decide continuar,
se desarrollan los planes para la siguiente fase del proyecto. Con cada
iteracin alrededor de la espiral (comenzando en el centro y siguiendo
hacia el exterior), se construyen sucesivas versiones del software,
coda vez ms completa y, al final, el propio sistema software
totalmente funcional

TIPO DE METODOLOGA ESPIRAL
El modelo en espiral WINWIN de Boehm, define un conjunto de
actividades de negociacin al principio de cada paso alrededor de la
espiral. Ms que une simple actividad de comunicacin con el cliente
se definen las siguientes actividades:
Identificacin del sistema o subsistemas clave de los directivos.
Determinacin de les condiciones de victoria de les directivos.
Negociacin de les condiciones de victoria de los directivos para
reunirlas en un conjunto de condiciones para todos los afectados
(incluyendo el equipo del proyecto de software).
El modelo en espiral WINWIN introduce tres hitos en el proceso,
llamados puntos de fijacin que ayuden e establecer la completitud de
un ciclo alrededor del espiral y proporcionen hitos de decisin.
Un ciclo de espiral comienza con la elaboracin de los objetivos tanto
funcionales como de rendimiento. Despus se enumeran algunas
formas posibles de alcanzar estos objetivos identificando las fuentes
de riesgos posibles. EI siguiente paso es resolver estos riesgos y
llevar a cabo las actividades de desarrollo. Finalmente se planifica el
siguiente ciclo de la espiral. (Fernando Alonso, 2005)

CARACTERISTICAS
La principal caracterstica del modelo en espiral es la gestin de riesgo
de forma peridica del ciclo de desarrollo (Pressman, 1997)
Trata de mejorar los ciclos de vida clsicos y prototipos.
Este modelo puede combinarse con otros modelos de proceso de
desarrollo (cascada, evolutivo).
En cada giro se construye un nuevo modelo del sistema completo.
El anlisis de riesgo requiere la participacin de personal con alta
cualificacin.
Incorpora objetivos de calidad y gestin de riesgos
Elimina errores y alternativos no atractivas al comienzo
Permite iteraciones, vuelta atrs y finalizaciones rpidas
Cada ciclo empieza identificando:
Los objetivos de la porcin correspondiente
Las alternativas
Restricciones
VENTAJAS
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del
software de computadora.
Como el software evoluciona a medida que progresa el proceso, el
desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en
cada uno de los niveles evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de
construccin de prototipos en cualquier etapa de evolucin del producto.
El modelo en espiral demanda una consideracin directa de los riesgos
tcnicos en todas las tapas del proyecto y si se aplica adecuadamente debe
reducir los riesgos antes que se conviertan en problemas
DESVENTAJAS
Resulta difcil convencer a grandes clientes que el enfoque evolutivo es
controlable
Debido a su elevada complejidad no se aconseja utilizarlo en pequeos
sistemas u proyectos.
Genera mucho tiempo en el desarrollo de sistemas.


1.1.4. Modelos Concurrente
El modelo concurrente o tambin llamado ingeniera concurrente
(IC) prcticamente cuenta con una definicin por cada uno de los
acercamientos tericos o prcticos que sobre ella se han realizado;
existe una lista de nombres con los cuales se designan principios o
procesos bsicos de la IC tales como ingeniera simultnea,
ingeniera cooperativa, diseo integrado de procesos y productos,
diseo concurrente, etc. (Carlson, 2002).
Aunque las prcticas que son cobijadas por la IC son cada vez
ms frecuentes desde 1980, la primera definicin dada en 1986 por
el Instituto para Anlisis de Sistemas de Defensa de los EE. UU
fue: la ingeniera concurrente es una aproximacin al diseo
concurrente, integrado de productos y a sus procesos
relacionados, incluyendo fabricacin y soporte. Esta
aproximacin pretende que quienes desarrollan el producto
consideren todos los elementos del ciclo de vida del producto
desde su concepcin hasta su desaparicin, incluyendo
calidad, costo, tiempo y necesidades del usuario Est
definicin fue divulgada masivamente por Winner et al en 1988.
Otra definicin general es la de J. Cleetus (1992): La ingeniera
concurrente es un enfoque sistemtico para el desarrollo de
productos integrados que hace nfasis en la respuesta a las
expectativas del cliente. Involucra valores de equipo, como la
cooperacin, la confianza y el intercambio, de tal manera que
la toma de decisiones sea por consenso, con la participacin
de todas las perspectivas en paralelo, desde el comienzo del
ciclo de vida del producto. (Cleetus, 1992)

Rpidamente, y a partir de lo anterior, en 1993, Prasad (Prasad et
al., 1993) detecta los principios fundamentales que estn
contenidos en la IC, en virtud de los cuales tal mtodo logra sus
altos mrgenes de aceptacin entre los tericos. (Prasad, 1993)
La Integracin se da en relacin con el contenido y los procesos de
informacin y conocimiento, a) entre y dentro de las etapas del
proyecto, y b) de todas las tecnologas y herramientas
utilizadas en el proceso de desarrollo de productos. La
concurrencia, por su parte, es determinada por la forma en que las
tareas se programan y por las interacciones entre los diferentes
actores (personas y herramientas) en el proceso de desarrollo de
productos. (Anumba, 2007)
FUNDAMENTOS DE LA INGENIERA CONCURRENTE

El desarrollo prctico de la ingeniera concurrente a travs de los
aos le ha permitido a un importante nmero de tericos reunir en
categoras algunas de las cualidades ms destacables de esta
disciplina. En virtud de su naturaleza abstracta, estas cualidades
reciben el nombre de fundamentos, y son agrupadas en tres tipos
de categoras: principios, componentes y beneficios, los cuales,
aunque semejantes, definen caractersticas particulares de los
diversos escenarios en los que se desenvuelve la IC.

Principios Bsicos de la IC
Prasad (1996) presenta como los principios bsicos de la IC las
caractersticas generales que de modo transversal imprimen su
sello en cada uno de los procesos de la organizacin. En otras
palabras, son los conceptos-clave que permiten identificar un
proceso dentro de la ingeniera concurrente. (Prasad B. , 1996)

Trabajo estructurado.
Aprovechamiento del conocimiento comn entre los miembros de
cada equipo y entre los equipos de trabajo.
Estimulacin del trabajo en equipo.
Toma temprana de decisiones de fabricacin.
Descubrimiento temprano de problemas.
Conservacin del propsito por parte de todo el personal vinculado
a los procesos.
Sentido de propiedad, en tanto que el proyecto es resultado de la
concertacin.

Componentes de la IC
Los componentes de la ingeniera concurrente, son las caractersticas
que esta disciplina aporta a cualquier proceso que vaya a ser
desarrollado dentro del entorno empresarial. En otras palabras, son
las cualidades distintivas por las cuales se puede reconocer que este
o aquel proceso est fundamentado y est siendo desarrollado a partir
de la ingeniera concurrente. Prasad presenta tres componentes
centrales:

Inicio multidisciplinario tambin llamado equipo de desarrollo de
producto: La IC se estructura alrededor de equipos multifuncionales
que aportan el conocimiento especializado necesario para el diseo y
desarrollo del producto.

Sinergia y trabajo en equipo: La sinergia, que es la combinacin de
las capacidades de un equipo para producir resultados mayores que
los del esfuerzo de cualquier miembro aislado del equipo, es la piedra
angular de cualquier organizacin que trabaje bajo un enfoque de
ingeniera concurrente. Por su parte, el trabajo en equipo hace nfasis
en las relaciones interpersonales, la cooperacin, la negociacin y la
toma de decisiones conjunta. Las siete cualidades que deben estar
presentes en un equipo de IC son: empoderamiento, adecuada
seleccin de personal, organizacin, liderazgo, autolimitacin,
autonoma y memoria tcnica o know-how.

Participacin global: Un proceso de ingeniera concurrente no es tal
a menos que involucre todas las partes que son responsables por
cada instancia del proceso, sin importar qu vnculos administrativos
tengan. Para que la organizacin funcione como una unidad y para
que el producto est completo, cada participante tiene que saber qu
esperan de l los dems.

Beneficios de IC
Uno de los beneficios ms destacados de la IC es el que se refleja en
los grupos de trabajo dedicados al diseo y la fabricacin del producto.
En estos entornos la IC permite: trabajo en paralelo gracias a la
integracin entre los distintos departamentos, prevencin de los
errores y anticipacin de los problemas, flexibilidad para adaptarse a
los cambios, suministro de informacin y acceso a la misma sobre
todos los procesos y entrenamiento cruzado.

Una gran parte de estos beneficios estn asociados al funcionamiento
general de la organizacin y se agrupan alrededor del concepto de
racionalizacin de tiempos, costos y dems recursos. De la
racionalizacin de estos recursos se desprenden otros beneficios
como son la reduccin en el tiempo de desarrollo del producto, un
mayor control de costos de diseo y fabricacin, reduccin de la
prdida de tiempo causada por los problemas de comunicacin, los
productos llegan al mercado ms rpidamente con un menor costo y
un mejor uso de recursos tcnicos en pocas de escasez.


OBJETIVOS DE LA INGENIERA CONCURRENTE
Como se ha dicho, el objetivo bsico de la ingeniera concurrente es la
disminucin en el tiempo total transcurrido desde la deteccin de una
necesidad hasta la comercializacin de un producto. La importancia en
la aceleracin de este proceso radica, como es sabido, en la ventaja
competitiva que supone alcanzar el mercado antes que los
competidores consiguiendo as un mejor posicionamiento.

Este objetivo principal viene acompaado de otros objetivos parciales,
no por ello menos importantes, como son la reduccin de los costes
totales, el aumento de la calidad y fiabilidad global del producto as
como el incremento del valor aadido. Este ltimo aspecto implica un
cambio de enfoque radical por parte de los tcnicos, que deben
anteponer a su criterio la visin del producto por parte del cliente. Ello
conlleva elaborar un conjunto de requerimientos y condicionantes
mucho ms completos, y en definitiva un mejor conocimiento del
problema ya desde las etapas ms iniciales. (Hartley, 1994)

Los objetivos globales que se persiguen con la implementacin de la IC son:

o Acortar los tiempos de desarrollo de los productos.
o Elevar la productividad.
o Aumentar la flexibilidad.
o Mejor utilizacin de los recursos.
o Productos de alta calidad.
o Reduccin en los costos de desarrollo de los productos.
o Establecer conocimiento y cultura de Ingeniera Concurrente
o Integrar los departamentos de la empresa
o Asegurar el cumplimiento de los requerimientos y expectativas
del cliente

VENTAJAS / DESVENTAJAS
Ventajas Desventajas
Excelente para proyectos en los que se
conforman grupos de trabajo independientes.

Proporciona una imagen exacta del estado
actual de un proyecto.

Si no se dan las condiciones
sealadas no es aplicable.

Si no existen grupos de trabajo no
se puede trabajar en este mtodo



METODOLOGAS PARA LA IMPLEMENTACIN DE ENTORNOS DE
INGENIERA CONCURRENTE.
Metodologa RACE
La metodologa RACE (Evaluacin de la Situacin para la Ingeniera
Concurrente) fue desarrollada inicialmente por el Departamento de
Defensa de los EE.UU., en el Centro de Investigacin de Ingeniera
Concurrente El objetivo de RACE fue establecer una estrategia de
entornos de IC, que permitiera realizar una transicin adecuada de la
empresa hacia los nuevos modelos de desarrollo de producto. La
implementacin de ingeniera concurrente, requiere valorar el estado
actual de las prcticas de gestin en la organizacin, la cultura
organizativa y el soporte tecnolgico para el desarrollo de productos
que repercutirn en el cambio de las prcticas actuales. La propuesta
de RACE se basa en una estrategia propia de transformacin que
comprende cuatro etapas que conducen a la IC:
Conocimiento: En esta etapa se definen los planes de implantacin,
identificando las necesidades de formacin y de nuevas tecnologas
colaborativas. Asimismo, se detectan las posibles barreras al cambio
que pudieran existir en la empresa.
Anlisis de la situacin. En esta etapa se identifican los puntos crticos
(cuellos de botella) del proceso de desarrollo del producto a travs de
un modelo, que permitir el entendimiento compartido del mismo.
Despliegue: Realizacin del cambio aplicando las bases de la
reingeniera de procesos y gestionando el nuevo proceso de manera
eficiente.
Mejora: Seleccin sistemtica de Iniciativas de mejora basada en
aquellas que estn ms en la lnea de las directrices de la empresa.
Para controlarlas se definirn indicadores que permitan evaluar el
proceso de desarrollo del producto.


Metodologa RACE II
La metodologa elaborada en la Universidad Tecnolgica de
Eindhoven (Eindhoven Technologic University,Holanda), la cual
desarrolla su propuesta a partir de la metodologa de implantacin de
IC denominada RACE. La nueva metodologa de implantacin,
definida como RACE II por Robert de Graaf, adopta el marco global
RACE y su procedimiento a aplicar para la mejora del proceso de
desarrollo del producto.
Para sustentar este mtodo, De Graaf afirma que existen cuatro
cuellos de botella en el modelo RACE los cuales son: ausencia de
comunicacin sobre la estrategia, polticas inestables de producto,
tecnologas no definidas para el desarrollo del producto y
competencias no definidas. Para resolver esta carencia los engloba
dentro de un nuevo elemento crtico denominado Despliegue de la
Estrategia. A partir de ciertos anlisis, se estableci que los criterios
clave para este nuevo elemento crtico deban ser la estrategia de
planificacin del producto, la planificacin de la tecnologa para la
gestin estratgica y la planificacin de la cooperacin con terceros.

Metodologa del Centro para Estudios y Desarrollos Emprendedores.
El Centro para Estudios y Desarrollos Emprendedores (CESD, Center
for Entrepreneurial Studies and Development, Inc.) de la Universidad
de West Virginia (EE.UU.), ha desarrollado una metodologa para la
implantacin de la IC, basada tambin en los trabajos y experiencias
previas de RACE.
Su metodologa propone un mtodo de evaluacin que determine
bsicamente la capacidad de la organizacin para soportar la IC,
basndose en un modelo integrado de proceso de desarrollo de
producto. Esta metodologa se desarrolla en cuatro pasos
secuenciales

Esta metodologa propone adems una nueva serie de criterios sobre
los cuales realizar la evaluacin, abandonando en gran medida los
propuestos originalmente por RACE. Cabe destacar que desaparece
la dimensin Tecnologa de RACE, y se define un nuevo criterio
llamado Sistemas Tecnolgicos y Herramientas para la IC que
contempla todo lo relacionado con la ayuda de las Tecnologas de la
Informacin a la IC. En cuanto al resto de los criterios, podemos
destacar que la metodologa de CESD mantiene aquellos relacionados
con la evaluacin de la dimensin Proceso de RACE.
Metodologa de Carter y Baker. (Mentor Graphics Corporation).

Paralelamente a las investigaciones desarrolladas en el CERC, Carter
y Baker de la empresa Mentor Graphics Corp. realizaron una
propuesta para innovar en el proceso de desarrollo de producto,
orientada tambin hacia la ingeniera concurrente; afirman que los
entornos de desarrollo de producto estn sometidos a continuos
cambios, debido a cinco grandes fuerzas : la tecnologa (nuevas
tecnologas en la empresa), las nuevas herramientas (seleccin de las
ms adecuadas), la distribucin de tareas (gestin y divisin de
trabajos eficientemente), la potenciacin del talento (motivacin para
obtener las mximas capacidades de los empleados) y la gestin del
tiempo (reduccin del tiempo de introduccin del producto en el
mercado). La integracin de estas cinco grandes fuerzas permitir
transformar los procesos de desarrollo de producto en entornos de IC.
Carter y Baker proponen una metodologa general que incluye un
anlisis de la situacin actual y un anlisis del entorno deseado, que
permitir sugerir el entorno de IC
.

MECANISMOS DE LA INGENIERA CONCURRENTE
La ingeniera concurrente se sustenta sobre tres pilares, o
mecanismos, bsicos que le confieren sus especiales caractersticas.
Es importante sealar que cada uno de estos tres mecanismos debe
estar presente e integrado de forma adecuada con los otros dos para
asegurar el xito.

Paralelismo:
El primero de ellos es el paralelismo, y de aqu que en determinados
sectores la ingeniera concurrente reciba el nombre de ingeniera
paralela o simultnea. El paralelismo reduce el tiempo global mediante
la realizacin simultnea de cuantas tareas sea posible.
Incrementar la efectividad mediante la realizacin de tareas en
paralelo es una idea compartida con otros campos tecnolgicos como
por ejemplo el informtico, donde los procesadores paralelos y las
tcnicas de programacin asociadas estn suponiendo una verdadera
revolucin.
Mediante el paralelismo se racionaliza la descomposicin del trabajo,
evitando las prdidas de tiempo inherentes a un enfoque secuencial.
Al mismo tiempo exige un mejor desarrollo y transferencia de la
informacin entre tareas.

Integracin:
Al paralelismo debe aadirse otro mecanismo bsico de la ingeniera
concurrente que es la integracin. Uno de los grandes problemas del
enfoque clsico de la ingeniera es sin duda la divisin del trabajo en
compartimentos estancos y deficientemente comunicados. El
paralelismo fuerza la integracin entre departamentos, especialmente
entre ingeniera y produccin, lo que reduce el impacto de la divisin
de trabajo en reas de especializacin y gestin. Slo mediante la
integracin es posible tomar en consideracin todo el conocimiento de
las disciplinas relevantes en cada fase del desarrollo del producto.
Adems de mejorar la comunicacin, la integracin evita la repeticin
innecesaria de tareas por diferencias de criterios y la suboptimizacin
derivada de enfoques excesivamente parciales.

Presciencia:
Los mecanismos de paralelismo e integracin presentan substanciales
ventajas conceptuales respecto a un enfoque clsico de la ingeniera
de tipo secuencial, y definen por s solos las caractersticas bsicas de
un entorno de ingeniera concurrente. No obstante su aplicacin
supone una serie de dificultades notables entre las que destaca un
aumento de la ambigedad y de la incertidumbre en todas las fases
del desarrollo, siendo necesario tomar decisiones cada vez ms
tempranas, y en base a informacin incompleta, situacin que por otra
parte debe hacerse compatible con un aumento en la calidad y
fiabilidad del producto final.
En consecuencia debe aadirse un tercer mecanismo destinado a
disminuir el impacto de esta aparente contradiccin. Dicho mecanismo
es la presciencia, o conjunto de tcnicas cuya misin es avanzar el
curso de los hechos. Slo a travs de ellas es posible estar
preparados frente a posibles eventualidades mediante la exploracin
temprana de las actividades futuras, tomando as las decisiones
adecuadas cuanto antes y al mnimo coste.
La presciencia es la clave para alcanzar el objetivo de conseguir el
resultado correcto al primer intento, evitando la repeticin innecesaria
de tareas y la toma de decisiones errneas.

TCNICAS Y HERRAMIENTAS DE LA INGENIERA CONCURRENTE
La implementacin prctica de la Ingeniera concurrente supone el uso
de toda una serie de tcnicas y herramientas especialmente
adaptadas para ella y sin las cuales no sera posible alcanzar los
niveles de eficacia exigidos. A continuacin se enuncian y describen
brevemente dichas tcnicas.

Tcnicas
Se incluyen en este apartado una serie de tcnicas con una incidencia
directa sobre la calidad de diseo. La calidad del diseo es un factor
clave del xito puesto que limita la mxima calidad alcanzable por un
producto.


Brainstorming
El brainstorming es una tcnica creativa para la bsqueda de
soluciones (o causas) a un problema dado. La principal caracterstica
del mtodo es la prohibicin de efectuar crticas a las ideas expuestas
por los miembros del grupo de trabajo a fin de evitar la inhibicin de
cualquiera de ellos. Dichas ideas son despus agrupadas por
categoras y priorizadas por votacin en orden a generar un plan de
actuacin.

Diagramas Causa Efecto
El diagrama Causas-Efecto de Ishikawa consiste en la representacin
grfica, ordenada y lgica, de la cadena de causas que conducen a un
determinado efecto. Puede aplicarse como paso intermedio en la
aplicacin de otras tcnicas como el AMFE, o directamente para
buscar la solucin a un determinado problema.

Despliegue de la funcin de calidad (QFD)
El QFD es una tcnica sistemtica para relacionar los requisitos
demandados por el mercado (voz del cliente) con las caractersticas
tcnicas del producto a travs de cada etapa de su creacin, con la
participacin de todas las funciones de la empresa que intervienen en
el mismo. La herramienta bsica del QFD es la construccin de
matrices de interrelacin a todos los niveles.

Anlisis del Valor
Las tcnicas de anlisis del valor estn orientadas tambin a la
satisfaccin de las necesidades del cliente pero poniendo el nfasis en
la optimizacin simultnea de los costes y los procesos. Para ello se
separan los aspectos que generan valor de aquellos que slo
generan coste, priorizando a los primeros sobre los segundos.

El valor es la suma de la impresin inicial del usuario ante el producto
y la satisfaccin durante el uso. El coste integra todas las
componentes desde el desarrollo inicial hasta el final de la vida til.

Anlisis de modos de fallo y sus efectos (AMFE)
El AMFE es una tcnica sistemtica para asegurar que todos los
modos de fallo que puede presentar un producto o un proceso han
sido analizados y prevenidos. Para ello se asocia cada modo de fallo
con sus causas y los efectos que producen. A partir de dicho anlisis
se establecen prioridades as como un plan de actuacin encaminado
a eliminar o minimizar las causas ms importantes de los fallos.

Diseo de experimentos (DOE)
Las tcnicas de diseo de experimentos estn encaminadas a la
planificacin estadstica de los ensayos a fin de maximizar la
informacin extrada (efecto de la variacin de los parmetros sobre el
comportamiento del sistema) minimizando el nmero de los mismos.
El diseo de experimentos se complementa con el anlisis de las
superficies de respuesta y las tcnicas de optimizacin. De entre las
tcnicas de optimizacin destacan los mtodos de diseo robusto de
Taguchi cuyo objetivo es minimizar la sensibilidad del comportamiento
del producto a las variaciones en los parmetros de entrada.

Diseo para la manufactura y el ensamblaje (DFMA)
Las tcnicas DFMA intentan asegurar una fabricacin ms fcil a
travs de la simplificacin de todas las operaciones. La idea bsica es
minimizar el nmero de piezas (piezas estandarizadas,
multifuncionales, etc. ) y conseguir que estas se puedan montar de
forma directa y sin errores (montaje con movimientos en una sola
direccin, ajuste fcil, piezas de sujecin separadas, etc).

Herramientas
La aplicacin de la ingeniera concurrente exige tambin la utilizacin
de una serie de herramientas basadas en la informtica y las
tecnologas de la informacin. Sin dichas herramientas es
prcticamente imposible conseguir los niveles de integracin,
comunicacin y prediccin exigidos por el enfoque concurrente.


Diseo y fabricacin asistidas (CAD/CAM)
El diseo asistido por ordenador (CAD) es indispensable en un
entorno de ingeniera concurrente, no slo por cuestiones de eficacia
operativa sino tambin para garantizar un intercambio gil y sin
errores as como una actualizacin constante de la informacin entre
los diversos grupos de trabajo implicados en el proyecto
(especialmente entre las ingenieras de producto y fabricacin). Con
una adecuada combinacin de hardware y software pueden
conseguirse drsticas reducciones en los plazos de ejecucin,
especialmente cuando se integra la informacin de diseo con la
generacin de programas de mecanizado (CAM).



Simulacin numrica (CAE)
La necesidad de la previsin forma ya parte del enfoque ingenieril
clsico en el que el desarrollo experimental juega, desde hace muchos
aos, un papel fundamental en orden a evitar problemas durante el
uso. En este sentido la experimentacin sobre prototipos fsicos
constituye una versin bsica de la presciencia, que distingue al
producto industrial del producto artesanal, cuya evolucin se produce
mediante un esquema de prueba, error y seleccin puramente
darwiniano.
Consecuencia de ello, los departamentos de ensayos tienen una larga
tradicin en todos los sectores industriales al tiempo que acumulan
una gran parte del conocimiento de la empresa sobre el producto y su
comportamiento real.
Sin embargo el actual nivel de exigencia en cuanto a disminucin de
costes y tiempos de desarrollo dificulta mucho la utilizacin de la
experimentacin como nica herramienta de la presciencia.
Afortunadamente los avances realizados en el mundo de la informtica
y de la simulacin numrica de los fenmenos fsicos ha permitido
incorporar al proceso un bucle rpido de valoracin y optimizacin
basado en las herramientas de simulacin.
La simulacin no slo es de utilidad en las etapas iniciales de
definicin del producto sino que tambin los es en el diseo y
desarrollo de los procesos de fabricacin. Hoy en da es posible
simular los procesos de inyeccin, fundicin, forja, conformado de
chapa y corte.
Mediante estas herramientas puede ponerse a punto el proceso de
fabricacin de forma virtual y antes de realizar importantes inversiones
en medios de produccin.

Ensayo (CAT)
Al tratarse de una tecnologa relativamente reciente, los
departamentos encargados de realizar los trabajos de simulacin
suelen estar desligados de los departamentos responsables de la
realizacin de los ensayos, crendose dos culturas diferentes que
dificultan la integracin.
Esta es una situacin claramente a evitar puesto que la mayor
efectividad conjunta de las herramientas de ensayo y simulacin slo
se alcanza aprovechando sus sinergias y a travs de un proceso de
adaptacin mutua en el que la experimentacin ya no juega el mismo
papel que anteriormente. A ttulo de ejemplo se apuntan seguidamente
algunos de los aspectos en los que la simulacin requiere un soporte
experimental adecuado, y que sin duda constituirn una rea de
crecimiento para las tcnicas experimentales en el futuro inmediato.

DISEO Y DESARROLLO MODULAR
Como ya se ha dicho, el principal objetivo de la Ingeniera Concurrente
en la entrega al mercado de productos nuevos ms fiables y en menos
tiempo. La paralelizacin de los procesos es por ello fundamental. Sin
embargo, an es posible conseguir mayor paralelizacin y en
consecuencia menor tiempo de desarrollo si se aplica la
modularizacin del producto.
La modularizacin del producto consiste en disear y desarrollar
productos considerndolos como la suma de grupos de elementos que
interaccionan, con una funcin comn y cierta autonoma de conjunto.
A estos grupos les denomina mdulos.
Cada mdulo puede llegar a ser desarrollado, por equipos de
expertos, casi independientemente del resto, como si de un proyecto
aislado se tratara. De esta manera la reduccin de plazos es evidente,
siempre y cuando la empresa disponga de recursos suficientes para
llevar a cabo los desarrollos simultneos.
El desarrollo modular tiene otra ventaja. Si consideramos el producto
final como un conjunto de subsistemas, y se disean interfaces
robustas (que no se vean afectadas por las modificaciones en el
diseo), es mucho ms fcil desarrollar cambios y mejoras en los
productos. Con una misma base, es posible crear toda una amplia
gama de productos cambiando algn o algunos mdulos. Adems las
mejoras en el producto se harn tambin de forma modular, con lo que
la probabilidad de fallar se reduce considerablemente. Todo esto
implica la posibilidad de crear nuevos productos con una inversin
ms limitada, un tiempo de desarrollo menor y con mayor probabilidad
de xito.

1.2. Modelo de Procesos Especializados
1.2.1. Desarrollo Basado en componentes
Un sistema es un conjunto de mecanismos y herramientas que
permiten la creacin e interconexin de componentes software, junto
con una coleccin de servicios para facilitar las labores de los
componentes que residen y se ejecutan en l.
Un sistema se denomina independientemente extensible (Szyperski,
1996) si se puede ser dinmicamente extendido, y en donde pueden
combinarse extensiones independientemente desarrolladas por
distintas partes o entidades, sin conocimiento unas de otras.
Diremos que un sistema abierto si es concurrente, reactivo,
independientemente extensible, y permite a componentes
heterogneos ingresar o abandonar el sistema de forma dinmica.
Estas condiciones implican que los sistemas abiertos son
inherentemente evolutivos, y que la vida de sus componentes es ms
corta que la del propio sistema.
Como consecuencia de dichas caractersticas, el desarrollo de
aplicaciones para este tipo de sistemas se ve afectado por una serie
de problemas especficos, como son la gestin de la evolucin del
propio sistema y de sus componentes, la falta de una visin global del
sistema, la dificultad para garantizar la seguridad y confidencialidad de
los mensajes y errores de comunicacin.
El tratamiento de estas situaciones es lo que ha hecho ver la
necesidad de nuevos modelos, pues la programacin tradicional se ha
visto incapaz de tratarlos de una forma natural. As la Programacin
Orientada a Objetos (POO) ha sido el sustento de la ingeniera del
software para los sistemas cerrados.
Sin embargo, se ha mostrado insuficiencias al tratar de explicar sus
tcnicas para el desarrollo de las aplicaciones en entornos abiertos.
A partir de estas restricciones es que nace la Programacin Orientada
a Componentes (POC) como una extensin natural de la orientacin a
objetos para los entornos abiertos. (Nierstrasz, 1995)
Este paradigma propugna el desarrollo y utilizacin de componentes
reutilizables dentro de lo que sera un mercado global de software.
Para hablar de la existencia de un mercado de componentes software
es necesario que los componentes estn empaquetados de forma que
permitan su distribucin y composicin con otros componentes,
especialmente con aquellos desarrollados por terceras partes. Esto
nos lleva a la definicin de componentes:
Hay consenso general en la comunidad de que un componente es una unidad de
software independiente que puede estar compuesta por otros componentes y que
se utiliza para crear un sistema de software. Aparte de esto, sin embargo, distintas
personas han propuesto definiciones de un componente software. Councill y
Heineman (Councill y Heineman, 2001) definen un componente como:
Un elemento software que se ajusta a un modelo de componentes y que puede ser
desplegado y compuesto de forma independiente sin modificacin segn un
estndar de composicin.
Esta definicin se basa fundamentalmente en estndares, una unidad software que
se ajusta a estos estndares es un componente. Szyperski (Szyperski, 2002), sin
embargo, no menciona los estndares en su definicin de componentes, sino que,
en vez de eso, se centra en las caractersticas clave de los componentes:
Un componente software es una unidad de composicin con interfaces
especificadas contractualmente y dependencias de contexto explcitas nicamente.
Un componente software puede ser desplegado de forma independiente y est
sujeto a la composicin por terceras partes.
Lo que tienen en comn estas dos definiciones es que estn de acuerdo en que los
componentes son independientes y que son unidades de composicin
fundamentales en un sistema. Desde nuestro punto de vista, una definicin
completa de componente puede derivarse desde ambas propuestas. (Sommerville,
2005)
Conceptos bsicos
El modelo de desarrollo basado en componentes incorpora muchas de las
caractersticas del modelo espiral. Es de naturaleza evolutiva y demanda un
enfoque iterativo para la creacin de software. Sin embargo, el modelo de desarrollo
basado en componentes construye aplicaciones a partir de fragmentos de software
prefabricados.
Las actividades de modelado y construccin comienzan con la identificacin
de candidatos de componentes. stos pueden disearse como mdulos de
software convencional o clases orientadas a objetos o paquetes de clases.
Sin importar la tecnologa usada para crear los componentes, el modelo de
desarrollo basado en componentes incorpora las etapas siguientes:
1. Se investiga y evalan, para el tipo de aplicacin de que se trate,
productos disponibles basados en componentes.
2. Se consideran los aspectos de integracin de los componentes.
3. Se disea una arquitectura del software para que reciba los componentes.
4. Se integran los componentes en la arquitectura.
5. Se efectan pruebas exhaustivas para asegurar la funcionalidad
apropiada.
El modelo del desarrollo basado en componentes lleva a la reutilizacin del
software, y eso da a los ingenieros de software varios beneficios en cuanto a
la mensurabilidad. Si la reutilizacin de componentes se vuelve parte de la
cultura, el equipo de ingeniera de software tiene la posibilidad tanto de
reducir el ciclo de tiempo del desarrollo como el costo del proyecto
(PRESSMAN, 2010).
Etapas del Desarrollo de Software Basado en Componentes
Estas etapas son:
Anlisis de Componentes: Dada la especificacin de requerimientos, se
buscan los componentes para implementar esta especificacin. Por lo general,
no existe una concordancia exacta y los componentes que se utilizan slo
proporcionan parte de la funcionalidad requerida.
Modificacin de Requerimientos: En esta etapa, los requerimientos se
analizan utilizando informacin acerca de los componentes que se han
descubierto. Entonces estos componentes se modifican para reflejar los
componentes disponibles. Si las modificaciones no son posibles, la actividad de
anlisis de componentes se puede llevar a cabo nuevamente para buscar
soluciones alternativas.
Diseo del Sistema con reutilizacin: En esta fase se disea o se reutiliza un
marco de trabajo para el sistema. Los diseadores tienen en cuenta los
componentes que se reutilizan y organizan el marco de trabajo para que los
satisfaga. Si los componentes reutilizables no estn disponibles, se puede tener
que disear nuevo software.
Desarrollo e Integracin: Para crear el sistema, el software que no se puede
adquirir externamente se desarrolla, y los componentes y los sistemas COTS se
integran. En este modelo, la integracin de sistemas es parte del proceso de
desarrollo, ms que una actividad separada.
Beneficios del desarrollo de Software basado en componentes
Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin
de software.
Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando
cada uno de los componentes antes de probar el conjunto completo de
componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento
entre componentes, el desarrollador es libre de actualizar y/o agregar
componentes segn sea necesario, sin afectar otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego
mejorado continuamente por un experto u organizacin, la calidad de una
aplicacin basada en componentes mejorar con el paso del
tiempo(SOMMERVILLE, 2005).


Carctersticas del desarrollo basado en componentes
Estandarizado: La estandarizacion de componentes significa que un
componente usado en un proceso CBSE(Component-based software
engineering) tiene que ajustarse a algn modelo estandarizado de componentes.
Este modelo puede definir interfaces de componentes, metadatos de
componentes, documentacion, composicion y despliegue.
Independiente: Un componente deberia ser independiente, deberia ser posible
componerlo y desplegarlo sin tener que utilizar otros componentes especificos.
En las situaciones en las que el componente necesita servicios proporcionados
externamente, stos deberan hacerse explcitos en una especificacion de
interfaz del tipo <<requiere>>.
Componible: Para que un componente sea componible, todas las interacciones
externas deben tener lugar a traves de interfaces definidas pblicamente.
Ademas debe proporcionar acceso externo a la informacin sobre si mismo,
como por ejemplo a sus mtodos y atributos.
Desplegable: Para ser desplegable, un componente debe ser independiente y
debe ser capaz de funcionar como una entidad autnoma o sobre una
plataforma de componentes que implemente el modelo de componentes. Esto
normalmente significa que el componente es binario y que no tiene que
compilarse antes de ser desplegado.
Documentado: Los componentes tienen que estar completamente
documentados para que los usuarios potenciales puedan decidir si los
componentes satisfacen o no sus necesidades. La sintaxis e, idealmente, la
semantica de todas las interfaces de componentes tienen que ser
especificadas.





1.2.2. Modelo de Mtodos formales
Un mtodo formal es una tcnica basada en matemticas, usada para
describir sistemas de hardware o software, (Wing, 1990). Los mtodos
formales permiten representar la especificacin del software,
verificacin y diseo de componentes mediante notaciones
matemticas. El uso de mtodos formales permite plantear de manera
clara la especificacin de un sistema, generando modelos que definen
el comportamiento en trminos del qu debe hacer y no del cmo lo
hace. Gracias al correcto proceso de especificacin, se pueden
verificar propiedades derivadas de cada mdulo mediante tcnicas de
razonamiento asociadas a los modelos formales, como probadores de
teoremas y verificadores de modelos (Hall, 1996).

El valor de los mtodos formales radica en que proporcionan un medio
para examinar simblicamente todos los espacios del estado de un
diseo digital y para establecer una propiedad segura de correctitud que
sea verdadera para todas las posibles entradas (Serna, 2010). Sin
embargo, en la prctica actual rara vez se hace debido a la enorme
complejidad de los sistemas reales. A pesar de que la Verificacin
formal completa de un sistema complejo grande es poco prctica en
este momento, los mtodos formales sustentan diversos aspectos o
propiedades de estos sistemas: a la especificacin detallada, al diseo
y a la verificacin de las partes crticas, como en la aviacin, en los
sistemas aeroespaciales y en sistemas de seguridad crtica como el
monitoreo de la frecuencia cardaca.
Para los procesos de especificacin se reconoce las siguientes
clasificaciones:
Lenguajes basados en modelos y estados.
Permiten especificar el sistema mediante un concepto formal de
estados y operaciones sobre estados. Los datos y relaciones/funciones
se describen en detalle y sus propiedades se expresan en lgica de
primer orden. La semntica de los lenguajes est basada en la teora de
conjuntos. Ejemplos: VDM, Z, B, OCL.
Lenguajes basados en especificaciones algebraicas.
Proponen una descripcin de estructuras de datos estableciendo tipos y
operaciones sobre esos tipos. Para cada tipo se define un conjunto de
valores y operaciones sobre dichos valores. Las operaciones de un tipo
se definen a travs de un conjunto de axiomas o ecuaciones que
especifican las restricciones que dben satisfacer las operaciones.
Algunos ejemplos: Larch, OBJ, TADs.
Lenguajes de especificacin de comportamiento:
Mtodos basados en lgebra de procesos: modelan la interaccin
entre procesos concurrentes. Esto ha potenciado su difusin en la
especificacin de sistemas de comunicacin (protocolos y servicios de
telecomunicaciones) y de sistemas distribuidos y concurrentes. Algunos
ejemplos son: CCS, CSP, Pi Calculus y LOTOS.
Mtodos basados en Redes de Petri: una red de Petri es un
formalismo basado en autmatas, es decir, un modelo formal basado en
flujos de informacin. Permiten expresar eventos concurrentes. Los
formalismos basados en redes de Petri establecen la nocin de estado
de un sistema mediante lugares que pueden contener marcas. Un
conjunto de transiciones (con pre y post condiciones) describe la
evolucin del sistema entendida como la produccin y consumo de
marcas en varios puntos de la red.
Mtodos basados en lgica temporal: se usan para especificar
sistemas concurrentes y reactivos. Los sistemas reactivos son aquellos
que mantienen una continua interaccin con su entorno respondiendo a
los estmulos externos y produciendo salidas en respuestas a los
mismos, por lo tanto el orden de los eventos en el sistema no es
predecible y su ejecucin no tiene por qu terminar

En cuanto al proceso de verificacin se tienen bsicamente dos
enfoques:

Verificacin de modelos: trabajan mediante una bsqueda
exhaustiva en los estados posibles de un modelo para encontrar
errores en la especificacin.

Prueba de teoremas: donde a partir de un conjunto de axiomas se
trata de probar si la especificacin, extendida con algunos teoremas,
es vlida


Los mtodos formales en la Ingeniera de Software
En Ingeniera de Software, un mtodo formal es un proceso que se aplica
para desarrollar programas, y que explota el poder de la notacin y de las
pruebas matemticas. Adems, los requisitos, la especificacin y el
sistema completo deben validarse con las necesidades del mundo real
(Kuhn, Chandramouli, & Butler, 2002). En la Ingeniera de Software los
mtodos formales se utilizan para:

Las polticas de los requisitos. En un sistema seguro se convierten
en las principales propiedades de seguridad que ste debe conservar -
el modelo de polticas de seguridad formal -, como confidencialidad o
integridad de datos
La especificacin. Es una descripcin matemtica basada en el
comportamiento del sistema, que utiliza tablas de estado o lgica
matemtica. No describe normalmente al software de bajo nivel, pero
s su respuesta a eventos y entradas, de tal forma que es posible
establecer sus propiedades crticas.
Las pruebas de correspondencia entre la especificacin y los
requisitos. Es necesario demostrar que el sistema, tal como se
describe en la especificacin, establece y conserva las propiedades de
las polticas de los requisitos. Si estn en notacin formal se pueden
disear pruebas rigurosas manuales o automticas.
Las pruebas de correspondencia entre el cdigo fuente y la
especificacin. Aunque muchas tcnicas formales se crearon
inicialmente para probar la correctitud del cdigo, pocas veces se
logra debido al tiempo y costo implicados, pero pueden aplicarse a los
componentes crticos del sistema.
Pruebas de correspondencia entre el cdigo mquina y el cdigo
fuente. Este tipo de pruebas raramente se aplica debido al costo, y a
la alta confiabilidad de los compiladores modernos.


1.2.3. Desarrollo de software orientado a aspectos
El desarrollo de software orientado a aspectos (DSOA) representa un nuevo
enfoque dentro de la Ingeniera del software. Est basado en la programacin
orientada a aspectos (POA) y centrado en la separacin de incumbencias
transversales o crosscuting concerns. Muchos conceptos y/o elementos de
modelacin se utilizan durante las diferentes etapas del DSOA, sin embargo, se
presentan ambigedades en cuanto a su semntica, no es claro cul de ellos debe
ser utilizado en cul etapa. (Aldawud, 2003)
Define un mecanismo que ayuda a resolver problemas complementarios de cdigo
disperso o scattered (un mismo servicio es invocado de manera similar desde
muchas partes del programa) y cdigo enmaraado o tangled (una misma
operacin tiene que acceder a varios servicios, adems de cumplir con su funcin
especfica).
Provee una unidad modular llamada aspecto y un mecanismo de composicin que
permite entremezclar unidades modulares de comportamiento comn con otras
unidades modulares bsicas del sistema. El desarrollo de software orientado a
aspectos (DSOA) se enfoca en crear una mejor abstraccin modular del sistema.
Incluye las siguientes fases:
- Captura de requisitos
- Anlisis
- Diseo
- Implementacin
- Pruebas
La primera fase trata la separacin de intereses tanto los funcionales como los no
funcionales; los requisitos funcionales son modelados con casos de uso que
representan la funcin bsica del sistema y los requisitos no funcionales se
representan con casos de uso de infraestructura. En el anlisis y el diseo los casos
de uso se representan en una estructura de composicin que se identifica con el
estereotipo <<use case slice>> y agrupa elementos de modelo que colaboran para
lograr los requisitos del sistema tanto funcionales como no funcionales. En la
implementacin se genera el cdigo de las clases y aspectos.
Por ltimo en las pruebas se disean las pruebas tanto para los casos de uso de la
aplicacin como para los casos de uso slice.





Captura de requisitos
En esta fase se identifican dos categoras de casos de uso: de aplicacin y de
infraestructura. Los casos de uso de aplicacin describen las funcionalidades
bsicas del sistema. Los casos de uso de infraestructura describen cmo el sistema
agrega cualidades como facilidad de uso, confiabilidad, de rendimiento y de soporte
para cada paso de un caso de uso de aplicacin.







La primera actividad consiste en entender los intereses de los stakeholders. El
resultado es obtener una lista de caractersticas del sistema la cual incluye
requisitos funcionales y no funcionales. A continuacin, se capturan los casos de
uso de la aplicacin. Esta actividad consiste en identificar actores y casos de usos a
partir de los requisitos funcionales de la lista de caractersticas, y describir los casos
de uso en las especificaciones de casos de uso contemplando posibles
extensiones. La descripcin de los casos de uso ayudar a identificar intereses de
corte transversal. En la ltima actividad se capturan los casos de uso de
infraestructura como extensiones modulares a los casos de uso de aplicacin. Para
ello, se revisa nuevamente la lista de caractersticas del sistema para identificar a
los requisitos no funcionales que afectan a algn paso de los casos de uso de
aplicacin, los cules sern tratados como casos de uso de transaccin (use-case
transaction si se tratan de requisitos de infraestructura para el sistema.
Esta actividad termina con la descripcin de estos tipos de casos de uso en una
especificacin contemplando tambin sus flujos alternativos)
Anlisis
Durante el anlisis se identifica la estructura de los elementos del anlisis en
trminos de capas, paquetes y clases (boundary, control y entity). Tambin se
identifican las estructuras de caso de uso conformados por paquetes estereotipados
con <<use-case slice>> y <<non-uc-specific slice>>.
Los paquetes use-case slice y non-uc-specific slice son unidades modulares
especficas y no especficas respectivamente que permiten organizar mucho mejor
el sistema.
Un use-case slice contiene elementos necesarios para un caso de uso especfico:
una colaboracin, que describe la realizacin de un caso de uso; una o ms clases
especficas, que son requeridas para la realizacin del caso de uso; y extensiones
de clase especficas para un cierto aspecto.
Un non-uc-specific slice contiene clases del dominio del problema que se usan en
muchos casos de uso.








Diseo
Aqu se incluyen actividades relacionadas a refinar las dos estructuras identificadas
en el anlisis incluyendo detalles del ambiente de implementacin. Mientras que la
estructura del modelo de anlisis es independiente de la plataforma (lenguajes de
programacin y tecnologa), el modelo de diseo es especfico a una plataforma
que ser utilizado en la implementacin.
El proceso de refinamiento consiste en refinar las clases con detalles de
implementacin y refinar los casos de uso slice incluyendo aspectos y las
extensiones de clases.










Implementacin
En esta etapa se genera el cdigo de las clases con un lenguaje de implementacin
como JAVA. Asimismo, se codifican los aspectos en un lenguaje orientado a
aspectos como AspectJ.

Pruebas
Las pruebas se llevan a cabo desde los requisitos hasta la codificacin. Se disean
pruebas para cada caso de uso y caso de uso slice. Por otro lado, se crean casos
de prueba slice que se puedan (Gianpaolo Cugola, 1999)
PROGRAMACION ORIENTADA A OBJETOS
POA: CONSIDERACIONES GENERALES
La idea central que persigue la POA es permitir que un programa sea construido
describiendo cada concepto separadamente. El soporte para este nuevo paradigma
se logra a travs de una clase especial de lenguajes, llamados lenguajes orientados
a aspectos (LOA), los cuales brindan mecanismos y constructores para capturar
aquellos elementos que se diseminan por todo el sistema. A estos elementos se les
da el nombre de aspectos. Una definicin para tales lenguajes sera: Los LOA son
aquellos lenguajes que permiten separar la definicin de la funcionalidad pura de la
definicin de los diferentes aspectos. Los LOA deben satisfacer varias propiedades
deseables, entre ellas:
- Cada aspecto debe ser claramente identificable.
- Cada aspecto debe auto-contenerse.
- Los aspectos deben ser fcilmente intercambiables.
- Los aspectos no deben interferir entre ellos.
- Los aspectos no deben interferir con los mecanismos usados para definir y
evolucionar la funcionalidad, como la herencia.
Qu es un aspecto?
Gregor Kickzales y su grupo, brinda un marco adecuado que facilita y clarifica la
definicin de un aspecto. Lo que propone es agrupar los lenguajes orientados a
objetos, los procedurales y funcionales como lenguajes de procedimiento
generalizado (LPG), ya que sus mecanismos claves de abstraccin y composicin
pueden verse como agrupados bajo una misma raz. Esa raz tendra la forma de un
procedimiento generalizado. Los mtodos de diseo que han surgido para los LPG
tienden a dividir el sistema en unidades de comportamiento o funciones. A este
estilo se lo conoce como descomposicin funcional (si bien la naturaleza exacta de
la descomposicin funcional difiere entre los paradigmas, para los propsitos de
este trabajo alcanza con agruparlos bajo LPG).
En general, decimos que dos propiedades se entrecruzan si al implementarse
deben componerse de manera diferente, y an deban ser coordinadas. Esto se
debe a que tienen un comportamiento en comn. Al proveer los LPG solamente un
nico medio de composicin, es el programador quien debe realizar la tarea extra
de co-componer manualmente las propiedades que se entrecruzan, lo cual lleva a
un oscurecimiento y a un aumento de la complejidad del cdigo.
Podemos diferenciar los aspectos de los dems integrantes del sistema: al
momento de implementar una propiedad, tenemos que la misma tomar una de las
dos siguientes formas:
Un componente: si puede encapsularse claramente dentro de un
procedimiento generalizado. Un elemento es claramente encapsulado si est
bien localizado, es fcilmente accesible y resulta sencillo componerlo.
Un aspecto: si no puede encapsularse claramente en un procedimiento
generalizado. Los aspectos tienden a ser propiedades que afectan la
performance o la semntica de los componentes en forma sistemtica
(Ejemplo: sincronizacin, manejo de memoria, distribucin, etc.)
A la luz de estos trminos, podemos enunciar la meta principal de la POA:
Brindar un contexto al programador que permita separar claramente componentes y
aspectos, separando componentes entre s, aspectos entre s, y aspectos de
componentes, a travs de mecanismos que hagan posible abstraerlos y
componerlos para producir el sistema completo. Tenemos entonces una importante
y clara diferencia respecto de los LPG, donde todos los esfuerzos se concentran
nicamente en los componentes, dejando de lado los aspectos. Una vez
diferenciados los aspectos de los componentes, estamos en condiciones de definir
a un aspecto como un concepto que no es posible encapsularlo claramente, y que
resulta diseminado por todo el cdigo. Los aspectos son la unidad bsica de la
programacin orientada a aspectos. Una definicin ms formal, y con la que se
trabaja actualmente es: Un aspecto es una unidad modular que se disemina por la
estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de
diseo como en la de implementacin. Un aspecto de diseo es una unidad
modular del diseo que se entremezcla en la estructura de otras partes del diseo.
Un aspecto de implementacin es una unidad modular del programa que aparece
en otras unidades modulares del programa.
FUNDAMENTOS DE LA POA
Los tres principales requerimientos de la POA son:
- Un lenguaje para definir la funcionalidad bsica, conocido como lenguaje base o
componente. Podra ser un lenguaje imperativo, o un lenguaje no imperativo (C++,
Java, Lisp, ML).
- Uno o varios lenguajes de aspectos, para especificar el comportamiento de los
aspectos. (COOL, para sincronizacin, RIDL, para distribucin, AspectJ, de
propsito general.)
- Un tejedor de aspectos (Weaver), que se encargar de combinar los lenguajes.
Tal proceso se puede retrasar para hacerse en tiempo de ejecucin o en tiempo de
compilacin.
Los lenguajes orientados a aspectos definen una nueva unidad de programacin de
software para encapsular aquellos conceptos que cruzan todo el cdigo. A la hora
de tejer los componentes y los aspectos para formar el sistema final, es claro que
se necesita una interaccin entre el cdigo de los componentes y el cdigo de los
aspectos. Tambin es claro que esta interaccin no es la misma interaccin que
ocurre entre los mdulos del lenguaje base, donde la comunicacin est basada en
declaraciones de tipo y llamadas a procedimientos y funciones. La POA define
entonces una nueva forma de interaccin, provista a travs de los puntos de enlace
(join points). Los puntos de enlace brindan la interfaz entre aspectos y
componentes; son lugares dentro del cdigo donde es posible agregar el
comportamiento adicional que destaca a la POA. Dicho comportamiento adicional
es especificado en los aspectos.
An nos falta introducir el encargado principal en el proceso de la POA. Este
encargado principal conocido como tejedor debe realizar la parte final y ms
importante: tejer los diferentes mecanismos de abstraccin y composicin que
aparecen tanto en los lenguajes de aspectos como en los lenguajes de
componentes, guiado por los puntos de enlace.
Estructura general
La estructura de una implementacin basada en aspectos es anloga a la
estructura de una implementacin basada en los LPG. Una implementacin basada
en LPG consiste en:
- Un lenguaje.
- Un compilador o intrprete para ese lenguaje.
- Un programa escrito en ese lenguaje que implemente la aplicacin.







Una implementacin basada en POA consiste en:
- El lenguaje base o componente para programar la funcionalidad bsica.
- Uno o ms lenguajes de aspectos para especificar los aspectos.
- Un tejedor de aspectos para la combinacin de los lenguajes.
- El programa escrito en el lenguaje componente que implementa los componentes.
- Uno o ms programas de aspectos que implementan los aspectos.
Grficamente, se tiene una estructura como la siguiente:


Cabe notar que la funcin que realizaba el compilador se encuentra ahora incluida
en las funciones del tejedor. (Contreras, 2002)


1.3. Proceso Unificado
El proceso unificado es un proceso de desarrollo de software. Un proceso e
desarrollo de software es el conjunto de actividades necesarias para
transformar los requisitos de un usuario en un sistema software. Sin
embargo, el proceso unificado es ms que un simple proceso; es un marco
de trabajo genrico que puede especializarse en una gran variedad de
sistema software, para diferentes areas de aplicacin, diferentes tipos de
organizaciones, diferentes niveles de aptitudes y diferentes tamaos de
proyecto. (Jacobson/Booch/Rumbauch, 2000)

Proceso Unificado Racional (RUP)
Es un proceso de la Ingeniera de Software propuesto por Rational Software
Corporacin Inc. Para la construccin completa del ciclo de ingeniera del
software. Permite la productividad en equipo y la realizacin de mejores
prcticas de software a travs de plantillas y herramientas que lo guan en
todas las actividades de desarrollo crtico del software, alineando un
disciplinado enfoque a la asignacin de tareas y responsabilidades dentro de
una organizacin de desarrollo.
Es un nuevo producto que unifica, en mucho, las disciplinas en lo que a
desarrollo de software se refiere, incluyen modelado de negocio, manejo y
configuracin de cambios y pruebas, cubriendo todo el ciclo de vida, manejo,
configuracin de cambios y pruebas, cubriendo todo el ciclo de vida de los
proyectos basados en construccin de componentes y maximizando el uso del
UML (Unified Modeling Language).

Un proceso define quien est haciendo que, y cuando, adems dice
como alcanzar un determinado objetivo. En la ingeniera de software el
objetivo es construir un producto de software (Jacobson/Booch/Rumbauch,
2000), vale decir, que todos los proyectos necesitan de un proceso que gui
sus actividades.
Segn Jacobson en sus libros El procesos Unificado de desarrollo de
Software, unos procesos efectivos proporcionan normas para el desarrollo
eficiente de Software de calidad, captura y presenta las mejores prcticas
que la tecnologa permite. Por tanto reduce el riesgo y hace el proyecto
ms predecible.

Proceso de Desarrollo de Software


Requisitos del usuario Procesos de desarrollo de
Software

Software


Fuente: (Jacobson/Booch/Rumbauch, 2000)

Entre muchos investigadores de la orientacin a objetos hay tres autores que
se han destacado por sus contribuciones al uso del paradigma en todo el
proceso de desarrollo: Ivar Jacobson, Grady Booch y James Rumbaug h.
Luego de muchos aos de trabajo individual desarrollado y difundido sus
propios mtodos, han unido sus teoras y su experiencia, y se han puesto a la
cabeza de un formidable grupo de investigadores para contribuir dos
herramientas con las cuales buscan estandarizar y por ende facilitar el uso
de los objetos en la programacin: El lenguaje Unificado de Modelo
(UML Unified Modeling Language) y el proceso unificado rotacional para el
desarrollo de programas (RUP, Rational Unified Process ) mientras que UML,
es ya un lenguaje maduro que ha logrado la aceptacin de amplios sectores
de las industria y la academia, RUP sigue siendo an una propuesta que
deber depurarse y templarse al calor de la experiencia de su aplicacin en el
campo y los portes de los casos de estudio (Jacobson/Booch/Rumbauch,
2000) (ver Figura. 1.2).
Figura 1.2 Historial de Procesos Unificados

(Jacobson/Booch/Rumbauch, 2000)
RUP y UML estn estrechamente relacionados entre si, pues mientras
el primero establece las actividades y los criterios para conducir un sistema
desde su mximo nivel de abstraccin, el segundo ofrece la notacin grfica
necesaria para representar los sucesos, modelos, que se obtienen de
procesos de refinamiento.
RUP se define como un proceso dirigido por:
Casos de Uso

Centrado en la Arquitectura

Iterativo e Incremental


a. Caractersticas Principales:
- Es un proceso incremental
- Sus actividades destacan en la creacin y mantenimiento de modelos
ms documentos sobre papel.
- Su desarrollo est centrado en arquitectura.
- Sus actividades estn dirigidas a los Use Case.
- Soportan las tcnicas orientadas a objetos.
- Es un proceso configurable.
- Impulsa un control de calidad y una gestin del riesgo de objetivos.

b. Principales Ventajas:
El Proceso Unificado de Rational basado en el enfoque iterativo tiene
las siguientes ventajas:

- El riesgo se mitiga tempranamente.
- El cambio es ms manejable.
- Hay un nivel ms alto de rehuso.
- El equipo de proyecto aprende a lo largo del camino.
- El producto tiene mejor calidad total.

c. Flujos Centrales del RUP:
Hay nueve flujos de trabajo centrales en el RUP, y ellos representan el
particionamiento de todos los Workers y actividades dentro del
agrupamiento lgico. Los flujos de trabajo centrales estn divididos
dentro de seis flujos de trabajo de ingeniera y tres flujos de trabajo de
soporte.
Los flujos de trabajo de ingeniera son los siguientes:
1. Flujos de trabajo del modelado de negocio.
2. Flujos de trabajo de requerimientos.
3. Flujos de trabajo de anlisis y diseo.
4. Flujos de trabajo de implementacin.
5. Flujos de trabajo de prueba.
6. Flujos de trabajo de despliegue.
Los tres flujos de trabajo centrales de soporte son:
1. Flujos de trabajo de administracin de proyecto.
2. Flujos de trabajo de administracin de configuracin y cambio.
3. Flujos de trabajo de ambiente.

d. Flujos de Trabajo del Modelado de Negocio
Es el estudio de los aspectos operacionales de una actividad de
trabajo: cmo se estructuran las tareas, cmo se realizan, cul es su
orden correlativo, cmo se sincronizan, cmo fluye la informacin que
soporta las tareas y cmo se le hace seguimiento al cumplimiento de
las tareas.
Una aplicacin de Flujos de Trabajo automatiza la secuencia de
acciones, actividades o tareas utilizadas para la ejecucin del proceso,
incluyendo el seguimiento del estado de cada una de sus etapas y la
aportacin de las herramientas necesarias para gestionarlo.
Se pueden distinguir dos tipos de actividad:
Actividades colaborativas: Un conjunto de usuarios trabajan sobre
un mismo repositorio de datos para obtener un resultado comn. Tiene
entidad el trabajo de cada uno de ellos en s mismo.
Actividades cooperativas: Un conjunto de usuarios trabajan sobre su
propio conjunto particular, estableciendo los mecanismos de
cooperacin entre ellos. No tiene entidad el trabajo de ninguno de
ellos si no es visto desde el punto de vista global del resultado final.

e. Flujos de Trabajo de Requerimientos:
Las metas del flujo de requerimientos son las siguientes:
- Establecer y mantener un acuerdo con los clientes y los usuarios
finales sobre lo que el sistema debe hacer y por qu.
- Proveer a los desarrolladores del sistema un mejor entendimiento de
los requerimientos del sistema.
- Definir los lmites del sistema.
- Proveer una base para el planeamiento de contenidos tcnicos de las
iteraciones.
- Proveer una base para estimar los costos y tiempo de desarrollo del
sistema.
- Definir una interfaz de usuario para el sistema, enfocndolas sobre las
necesidades y metas de los usuarios.

f. Flujos de Trabajo de Anlisis y Diseo:
El propsito de flujos de trabajo del anlisis y diseo es el traducir los
requerimientos dentro de una especificacin que describe cmo
implementar el sistema. Para hacer esta traduccin, se deben
entender los requerimientos y transformarlos dentro de un sistema de
diseo, seleccionando la mejor estrategia de implementacin.
Se debe establecer en el proyecto una arquitectura robusta para poder
disear un sistema que sea fcil entender, construir y evolucionar.

g. Flujos de Trabajo de Implementacin:
El flujo de trabajo de implementacin tiene cuatro propsitos:
- Definir la organizacin del cdigo en trminos de subsistemas de
implementacin organizados en capas.
- Implementar clases y objetos en trminos de componentes (archivos
fuente, binarios, ejecutables y otros)
- Probar el desarrollo de los componentes como unidades.
- Integrar en un sistema ejecutable los resultados producidos por
implementadores individuales o equipos.



h. Flujos de Trabajo de Prueba:
El propsito de la prueba es evaluar la calidad del producto. Esto no
solamente involucra en el producto final, sino que empieza
tempranamente en el proyecto con la evaluacin de la arquitectura y
contina a travs de la evaluacin del producto final entregado a los
clientes.
Involucra los siguientes puntos:
- Verificar la interaccin de componentes.
- Verificar la integracin apropiada de los componentes.
- Verificar que todos los requerimientos hayan sido correctamente
implementados.
- Identificar y asegurar que todos los defectos descubiertos sean
corregidos.
- Antes de que el software sea desplegado.

i. Flujos de Trabajo de Despliegue:
El propsito del Workflow de despliegue es repartir el producto a los
usuarios finales.
El Workflow de despliegue involucra varias actividades, como:
- Probar el software en su entorno operacional final. (Prueba Beta).
- Empaquetar el software.
- Distribuir el software.
- Instalar el software.
- Proporcionar ayuda y asistencia a los usuarios.
- Entrenar a los usuarios o la fuerza de ventas.
- Planear y conducir las pruebas Beta.
- Migracin de data o Software existente. (MOSQUEIRA, 2003)

DIRIGIDO POR CASOS DE USO
Procesos de desarrollo de software utiliza los casos de uso como una
herramienta para la obtencin de requisitos de usuario. Donde los casos
de uso son para definir la funcionalidad del sistema, y guan al desarrollador
en la construccin de la arquitectura del sistema.
La descripcin obtenida de los requerimientos debe ser comprendida por
casos de uso que nos ayudan a recopilar la informacin acerca de la
interaccin que tiene los usuarios en este caso actores con el sistema. Un
caso de uso es una secuencia, reacciones que el sistema lleva a cabo para
ofrecer un resultado de valor a algn actor, que sirven para realzar pruebas
sobre los componentes desarrollados (ver Figura. 1.3). Los casos de uso
enlazan los flujos de trabajo fundamntales. El proyecto progresa a
travs de estos flujos de trabajo, que inician en los casos de uso
(Jacobson/Booch/Rumbauch, 2000)


Figura 1.3 Casos de uso que en laza los flujos de trabajo
fundamental


Requisitos Anlisis Diseo Implementacin
Pruebas


(Carig, 1999)



LENGUAJE DE MODELADO UNIFICADO (UML)
UML, emergi en los '9 0 luego de la bsqueda de un lenguaje de
modelamiento que unificara a la industria, que sigui a la "guerra de
mtodos" de los '70 y '80. A pesar de que UML evolucion primeramente de
varios mtodos orientados al objeto de segunda generacin (en nivel de
notacin), UML no es simplemente un lenguaje para modelamiento
orientado al objeto de tercera generacin. Su alcance extiende su uso
ms all de sus predecesores. Y es la experiencia, experimentacin y una
gradual adopcin del estndar lo que revelar su verdadero potencial y
posibilitara a las organizaciones darse cuenta de sus beneficios.
DE



EVIDENTE Debe realizarse y el usuario debera saber que se ha realizado


OCULTA
Debe realizarse, aunque no es visible para el usuario. Esto hace

muchos servicios tcnicos , como guardar informacin en
un mecanismo persistente


Funciones
Son acciones o procesos a ser realizados para lograr alcanzar un objetivo
que presenta el proyecto. Las funciones pueden ser organizadas de dos
tipos.

Tabla 1.1 Categora de las Funciones





Fuente: (Carig, 1999)

Diagramas de Casos de Uso
Los casos de uso no son propiamente un caso de anlisis, se limitan a
describir Procesos de dominio que pueden expresarse en forma narrativa en
un formato estructurado de prosa y pueden ser eficaces en un proyecto de
tecnologa no orientada a objetos. No obstante, constituyen un paso
preliminar muy til porque describen las especificaciones de un sistema.
(Jacobson/Booch/Rumbauch, 2000)
a) Actores
El actor es una entidad externa del sistema que de alguna manera participa
en la historia del cado de uso. Por lo regular, estimula el sistema con
eventos de entrada o recibe algo de l. Los actores est n representados por
el papel que desempean en el caso: Cliente, tcnico u otro. Conviene
escribir su nombre con mayscula en la narrativa del caso para facilitar la
identificacin (ver Figura 1.5).
Figura 1.5 Actor
Fuente: (Carig, 1999)

b) Caso de uso
El caso de uso es un documento narrativo que describe la secuencia de
eventos de un actor (agente externo) que utiliza un sistema para completar
un proceso (Jacobson/Booch/Rumbauch, 2000) Los casos de uso son
historias o casos de utilizacin de un sistema, no son exactamente los
requerimientos, ni las especificaciones funcionales, sino que ejemplifican
e incluyen tcticamente los requerimientos en las historias que narran (ver
Figura. 1.6).

Figura 1.6 Caso de Uso

Fuente: (Carig, 1999)

c) Relacin
Si un caso de uso inicia o contiene el comportamiento de otro se dice que
usa el segundo caso, eso es una relacin unidireccional. Esta relacin puede
presentar uno de los siguientes tipos:
La relacin usa, se utiliza cuando se quiere reflejar un
comportamiento comn en varios casos de uso (ver Figura. 1.7).
La relacin extiende, se utiliza cuando se requiere reflejar un
comportamiento opcional de un caso de uso, es decir, es cuando tiene
un caso similar a otro, cuyo contexto tiene mucho ms detalle.
Figura 1.7 Relacin de usos

Fuente: (Carig, 1999)



1.4. Modelo de Procesos Personal y de equipo
1.4.1. Proceso Personal del Software (PPS)
Antecedentes
PPS, es uno de los 3 vrtices donde descansa un proceso de mejora que
trabaja sobre 3 niveles de la organizacin, los otros 2 son CMM y TSP

CMM se enfoca a nivel organizacional
TSP se enfoca a un proceso de grupos de trabajo
PPS se enfoca a nivel personal
"PPS cubre 12 de los 18 KPAs (reas claves de procesos del CMM) y
materializa lo que han querido decir CMM, ISO 9000 y SQA (software
quality assurance)"
David F. Rico

Qu es PPS?
El proceso personal de software es un conjunto de prcticas disciplinadas
para la gestin del tiempo y mejora de la productividad personal de los
programadores o ingenieros de software, en tareas de desarrollo y
mantenimiento de sistemas. Est alineado y diseado para emplearse en
organizaciones con modelos de procesos CMMI o ISO 15504. Fue
propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A
partir de 1997 con el lanzamiento del libro "An introduction to the
Personal Software Process" (Humphrey, Introduction to the Personal
Software Process, 1997) se dirige ahora a ingenieros junior.

Se puede considerar como la gua de trabajo personal para ingenieros de
software en organizaciones que emplean un modelo CMMI con nivel de
madurez o de capacidad de procesos que implica la medicin cualitativa y
mejora de procesos.

Uno de los mayores problemas que tiene es la gran cantidad de datos que
hay que tomar. El PPS tiene obsesin por la toma de datos y elaboracin
de tablas. El PSP se orienta el conjunto de reas clave del proceso que
debe manejar un desarrollador cuando trabaja de forma individual.

Niveles
Nivel 0:
proceso actual.
Registro de tiempos.
Registro de defectos.
Nivel 0.1 :
Estndares de cdigo.
Medicin de tamao.
Nivel 1 - Inicial:
Estimacin de tamao.
Reporte de pruebas.
Nivel 1.1:
Calendario de planeacin de tareas.
Nivel 2 - Repetible:
Revisin de diseo y cdigo.
Nivel 2.1:
Plantillas de Diseo.
Nivel 3
Mejora el ciclo, mejora del proceso en trminos de hacerlo repetible
(cclico):
Para aplicacin a programas de mayor tamao
Registro del seguimiento de asuntos importantes
Anlisis del resumen de la planeacin, tiempos, tamaos y
defectos por cada ciclo
(Humphrey, PSP: A Self-Improvement Process for Software Engineers, 2005)

Objetivos de PSP

Lograr una disciplina de mejora continua en el proceso de desarrollo.
Medir, estimar, planificar, seguir y controlar el proceso de desarrollo.
Mejorar la calidad del proceso de desarrollo.
En general, PSP provee calidad y productividad.
(Will Hayes, 1997)


Desventajas de Aplicar PSP

El tiempo requerido para conocerlo.
El costo emocional por mantener una disciplina.
El ego del cambio en las costumbres.

Ventajas de Aplicar PSP

La idea de que ganamos en talento y habilidad
La estimulacin por nuevas ideas
Una estructura de trabajo de mejoramiento personal
Tomar control del propio trabajo
La sensacin de logro
Una base mejorada para el trabajo en grupo (TSP)
La conviccin de que es lo mejor que se puede hacer
(Jesse Russell, 2012)

PASOS PARA IMPLANTACION PPS

1. Los ingenieros deben ser entrenados por un instructor calificado de
PSP.
2. La Capacitacin es sobre grupos o equipos, y sern grupos que as lo
han sido y seguirn siendo.
3. Requiere un fuerte soporte de administracin, en este sentido es
necesario que los administradores entiendan el PSP, saber cmo
apoyarlos y como monitorear sus avances, sin un adecuado monitoreo
los ingenieros caern otra vez en los malos hbitos.
4. Despus de ser bien entrenados y bien administrados lo que sigue es
optimizar la interaccin entre equipos y aqu entrara Team Software
Process, el TSP extiende y refina los mtodos de CMM y PSP sobre
desarrollo y mantenimiento de equipos, y llegar a lo que se le llama un
equipo auto dirigido. (Humphrey, The Personal Software Process(sm)
(PSP(sm)), 2000)

1.4.2. Proceso del equipo de Software
Debido a que muchos proyectos de software industrial son elaborados por un
equipo de profesionales, Watts Humphrey extendi las lecciones aprendidas de la
introduccin del PPS y propuso un proceso del equipo de software (PES). El
objetivo de ste es construir un equipo autodirigido para el proyecto, que se
organice para producir software de alta calidad. Humphrey [Hum98] define los
objetivos siguientes para el PES:
Formar equipos autodirigidos que planeen y den seguimiento a su trabajo.
Que establezcan metas y que sean dueos de sus procesos y planes.
stos pueden ser equipos de software puros o de productos integrados
(EPI) constituidos por 3 a 20 ingenieros.
Mostrar a los gerentes cmo dirigir y motivar a sus equipos y cmo
ayudarlos a mantener un rendimiento mximo.
Acelerar la mejora del proceso del software, haciendo del modelo de
madurez de la capacidad, CMM,23 nivel 5, el comportamiento normal y
esperado.
Brindar a las organizaciones muy maduras una gua para la mejora.
Facilitar la enseanza universitaria de aptitudes de equipo con grado
industrial. Un equipo autodirigido tiene la comprensin consistente de sus
metas y objetivos generales; define el papel y responsabilidad de cada
miembro del equipo; da seguimiento cuantitativo a los datos del proyecto
(sobre la productividad y calidad); identifica un proceso de equipo que sea
apropiado para el proyecto y una estrategia para implementarlo; define
estndares locales aplicables al trabajo de ingeniera de software del
equipo; evala en forma continua el riesgo y re- acciona en consecuencia; y
da seguimiento, administra y reporta el estado del proyecto.
El PES define las siguientes actividades estructurales: inicio del proyecto,
diseo de alto nivel, implementacin, integracin y pruebas, y post mrtem.
Como sus contrapartes del PPS (observe que la terminologa es algo
diferente), estas actividades permiten que el equipo planee, disee y construya
software en forma disciplinada, al mismo tiempo que mide cuantitativamente el
proceso y el producto. La etapa post mrtem es el escenario de las mejoras del
proceso. El PES utiliza una variedad amplia de scripts, formatos y estndares
que guan a los miembros del equipo en su trabajo. Los scripts definen
actividades especficas del proceso (por ejemplo, inicio del proyecto, diseo,
implementacin, integracin y pruebas del sistema, y post mrtem), as como
otras funciones ms detalladas del trabajo (planeacin del desarrollo,
desarrollo de requerimientos, administracin de la configuracin del software y
prueba unitaria) que forman parte del proceso de equipo.
El PES reconoce que los mejores equipos de software son los autodirigidos.
Los miembros del equipo establecen los objetivos del proyecto, adaptan el
proceso para que cubra las necesidades, controlan la programacin de
actividades del proyecto y, con la medida y anlisis de las mediciones
efectuadas, trabajan de manera continua en la mejora del enfoque de
ingeniera de software que tiene el equipo. Igual que el PPS, el PES es un
enfoque riguroso para la ingeniera de software y proporciona beneficios
distintivos y cuantificables en productividad y calidad. El equipo debe tener un
compromiso total con el proceso y recibir capacitacin completa para asegurar
que el enfoque se aplique en forma apropiada. (Roger S. Pressman, 2010)

1.5. Metodologas Agiles
1.5.1. Programacin Extrema
La Programacin Extrema o eXtreme Programming (XP) es un
enfoque de la Ingeniera de Software formulado 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 estos, 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 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 de
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.
(Pressman, 1997)
Valores
Los valores originales de la programacin extrema son: simplicidad,
comunicacin, retroalimentacin (feedback) y coraje. Un quinto valor,
respeto, fue aadido en la segunda edicin de Extreme Programming
Explained. Los cinco valores se detallan a continuacin:
Simplicidad
La simplicidad es la base de la programacin extrema. Se simplifica el diseo
para agilizar el desarrollo y facilitar el mantenimiento. Para mantener la
simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de
mantener el cdigo simple a medida que crece. Tambin se aplica la
simplicidad en la documentacin, de esta manera el cdigo debe comentarse
en su justa medida, intentando eso s que el cdigo est autodocumentado.
(Pressman,
Ingeniera del software: un enfoque prctico, 1997)
Comunicacin
La comunicacin se realiza de diferentes formas. Para los programadores, el
cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay
que esforzarse para hacerlo inteligible. La comunicacin con el cliente es
fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide
que caractersticas tienen prioridad y siempre debe estar disponible para
solucionar dudas(Pressman, Ingeniera del software: un enfoque prctico,
1997)
Retroalimentacin (feedback)
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del
proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los
cuales se muestran resultados, se minimiza el tener que rehacer partes que
no cumplen con los requisitos y ayuda a los programadores a centrarse en lo
que es ms importante (Pressman, Ingeniera del software: un enfoque
prctico, 1997)
Coraje o Valenta
Muchas de las prcticas implican valenta. Una de ellas es siempre disear y
programar para hoy y no para maana. Esto es un esfuerzo para evitar
empantanarse en el diseo y requerir demasiado tiempo y trabajo para
implementar todo lo dems del proyecto (Pressman, Ingeniera del software:
un enfoque prctico, 1997)
Respeto
Los miembros del equipo se respetan los unos a otros, porque los
programadores no pueden realizar cambios que hacen que las pruebas
existentes fallen o que demore el trabajo de sus compaeros.
(Pressman, Ingeniera del software: un enfoque prctico, 1997)
Caractersticas
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.
Programacin en parejas: se recomienda que las tareas de
desarrollo se lleven a cabo por dos personas en un mismo
puesto.
Frecuente integracin del equipo de programacin con el cliente o
usuario.
Correccin de todos los errores antes de aadir nueva
funcionalidad.
Refactorizacin del cdigo, es decir, reescribir partes del cdigo
para aumentar su legibilidad y mantenibilidad pero sin modificar
su comportamiento.
Propiedad del cdigo compartida: en vez de dividir la
responsabilidad en el desarrollo de cada mdulo en grupo de
trabajo distinto, este mtodo promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto.
Simplicidad en el cdigo: es la mejor manera de que las cosas
funcionen. Cuando todo funcione se podr aadir funcionalidad si
es necesario (Mann, 2000)



1.5.2. SCRUM
SCRUM es una metodologa de desarrollo muy simple que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en la adaptacin
continua a las circunstancias de la evolucin del proyecto.

(Toro Lpez, 2013)
Visin General del Modelo
La adaptacin a los cambios es el fuerte de la metodologa, esto
porque no existe una etapa de levantamiento de requerimientos sino que se
van construyendo en la ejecucin del proyecto, la incertidumbre es un factor
clave por eso se est preparado para asumir cualquier cambio, eliminando
los obstculos de los proyectos.

(Toro Lpez, 2013)
Roles
Product Owner (Dueo del producto)
- Representa la voz del cliente.
- Se asegura de que el equipo Scrum traba de forma
adecuada desde la perspectiva del trabajo.
Scrum Manager (Facilitador)
- Eliminar los obstculos que impiden que el equipo alcance
el objetivo.
- No es el lder del equipo, sino que acta como una
proteccin entre el equipo y cualquier influencia que le
distraiga.
- Se asegura de que el proceso Scrum se utiliza como es
debido (es decir que se cumplan las reglas).
Team (Equipo)
- Tiene la responsabilidad de entregar el producto.
- Formado por personas con las habilidades transversales
necesarias para realizar el trabajo (diseador,
desarrollador, etc.)
Ventajas
Es fcil de aprender.
Requiere muy poco esfuerzo para comenzarse a utilizar.
Permite abarcar proyectos donde los requisitos de negocio estn
incompletos.
Permite el desarrollo, testeo y correcciones rpido.
Mediante las reuniones diarias se ven claramente los avances y
problemas.
Como toda metodologa gil, obtiene mucho feedback del cliente
Facilita la entrega de productos de calidad a tiempo
Desventajas
Si no se define una fecha de fin, los stakeholders siempre pedirn
nuevas funcionalidades.
Si una tarea no est bien definida puede incrementar costes y
tiempos.
Si el equipo no se compromete, hay mucha posibilidad de fracasar.
Solo funciona bien en equipos pequeos y giles.
Se requieren miembros del equipo experimentados.
Solo funciona cuando el Scrum Manager confa en su equipo.
Que un miembro abandone el equipo durante el desarrollo puede
conllevar grandes problemas(Pressman, Ingeniera del software: un
enfoque prctico, 1997)

BIBLIOGRAFIA
Aldawud, O. E. (2003). A uml profile for aspect oriented software development. AO Modeling
Proceeding.
Anumba, J. K. (2007). Concurrent Engineering in Construction Projects. New York: Taylor and
Francis.
Carig, L. (1999). UML y Patrones. Mexico.
Cleetus, J. (1992). Definition of concurrent engineering. In: CERC Technical Report CERC-TR-RN-92-
003. West Virginia University: Morgantow.
Contreras, F. A.B. (2002). Programacin Orientada a Aspectos: Anlisis del Paradigma . Buenos
Aires-Argentina .
Ernest Teniente Lpez, D. C. (2003). Especificacin de sistemas software en UML. Barcelona:
Ediciones Universidad Politcnica de Catalunya SL.
Fernando Alonso, L. M. (2005). Introduccin a la Ingeniera de Software - Modelos de Desarrollos
de Programas. Mostoles: Grefol S.A.
FOX, J. (1982). SOFTWARE AND ITS DEVELOPMENT. Prentice-Hall.
Gianpaolo Cugola, C. G. ( 1999). Language Support for Evolvable Software: An initial Assessment of
Aspect-Oriented . IWPSE99.
Hall, A. (1996). Using Formal Methods to Develop an ATC. IEEE Softw vol13, 66-76.
Hartley, J. R. (1994). Ingeniera Concurrente. Productivity Press, Ed. TGP-Hoshin.
Humphrey, W. S. (1997). Introduction to the Personal Software Process. Mchigan: Addison-Wesley
Professional.
Humphrey, W. S. (2000). The Personal Software Process(sm) (PSP(sm)). Carnegie Mellon University,
Software Engineering Institute, 2000.
Humphrey, W. S. (2005). PSP: A Self-Improvement Process for Software Engineers. Addison-Wesley
Professional.
Jacobson/Booch/Rumbauch. (2000). El Procesos Unificado de desarrollo de Software. Madrid.
Jesse Russell, R. C. (2012). Personal Software Process. Book on Demand.
Kuhn, R., Chandramouli, R., & Butler, R. (2002). Cost Effective Use of Formal Methods in
Verification and Validation. Laurel, Maryland: Foundations for Modeling and Simulation
Verification and Validation the 21st Century.
Mann, M. (2000). Ingeniera de Software. Espaa.
MOSQUEIRA, E. (2003). PRINCIPIOS DE ANALISIS INFORMATICO. MADRID- ESPAA: ADDYSON
WESLEY.
Nierstrasz, O. (1995). Requirements for a Composition Language. New York: Square Bracket
Associates.
Prasad, B. (1993). Information management for concurrent engineering: Research Issues,
Concurrent Engineering: Research and Applications.
Prasad, B. (1996). Concurrent engineering fundamentals, vol 1: Integrated products and process
organization. Prentice Hall.
Pressman, R. S. (1997). Ingeniera del software: un enfoque prctico.
Pressman, R. S. (1997). Ingeniera del software: un enfoque prctico. Espaa.
Pressman, R. S. (2005). Ingenieria del Software. Un enfoque practico.
PRESSMAN, R. S. (2010). Ingeniera del Software. Un enfoque prtico. Mxico: INTERAMERICANA
EDITORES, S.A.
Presuman, R. S. (s.f.). Ingenieria del Software. Un enfoque practico.
Roger S. Pressman, P. (2010). Ingenieria del Software - Un enfoque Prctico. Distrito Federal -
Mexico: Mc Graw Hill.
Rumbaugh, J. (2005). UML - pasos y patrones. New Yoirk: iberoamericana.
Senn, J. A. (s.f.). Analisis y diseo de Sistemas de informacion. Mexico: McGraw.
senn, j. (s.f.). analisis y diseos de sistemas de informacion.
Serna, E. M. (2010). Mtodos formales e Ingeniera de Software. Revista Virtual Universidad
Catlica, 1-26.
SOMMERVILLE, I. (2005). Ingenieria del Software. Madrid: PEARSON EDUCACIN, S.A.
Sommerville, I. (2005). INGENIERA DEL SOFTWARE, Sptima Edicin. Madrid(Espaa): PEARSON
EDUCACIN S.A.
Sommerville, I. (2006). Ingeniera del Software.Septima Edicion. Madrid: PEARSON EDUCACION
S.A.
Szyperski. (1996). Independently Extensible System - Software Engineering Potential and
Challenges. Melbourne: Australasian Computer Science Conference.
Toro Lpez, F. (2013). Administracin de proyectos de informtica. Colombia: ECOE EDICIONES.
WEITZENFELD, A. (2004). Ingenieria del software orientada a objetos con UML. Mexico: Thomson.
Will Hayes, C.-m. u. (1997). The Personal Software Process (PSPSM): An Empirical Study of the
Impact of PSP on Individual Engineers. Carnegie-mellon univ pittsburgh pa software
engineering ins.
Wing, J. M. (1990). A Specifiers Introduction to Formal Methods. Pittsburgh: Carnegie Mellon
University.