You are on page 1of 73

1.

Marco Teórico
1.1. Modelo de procesos Prescriptivos
1.1.1. Modelo de Cascada
Es un enfoque metodológico que ordena rigurosamente las etapas del
ciclo de vida del software, de tal forma que el inicio de cada etapa
debe esperar a la finalización de la inmediatamente anterior, quizás el
más ampliamente utilizado. De esta forma, se reduce mucho la
complejidad de la gestión, 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 podrían establecer planes de una
forma totalmente secuencial, quedando perfectamente delimitadas las
responsabilidades de los equipos que desarrollen cada etapa.
En la realidad la aplicación de este modelo no suele ser tan radical.
Aunque se intenta conseguir la mayor secuencialidad posible, es difícil
evitar las "vueltas atrás". Si después de la terminación de alguna etapa
los resultados no son los esperados, en la práctica es muy posible que
el problema esté en la mala realización de una etapa anterior. Y esto
es así porque no sabemos cómo decidir con total certidumbre que una
etapa ha sido perfectamente desarrollada hasta que se observan las
consecuencias, quizás varias etapas y bastante tiempo después 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 básicos
 Planear un proyecto antes de embarcarse en el.
 Definir el comportamiento externo deseado del sistema antes de
diseñar su arquitectura interna.
 Documentar los resultados de cada actividad
 Diseñar un sistema antes de codificarlo
 Testear un sistema después de construirlo.

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


Ingeniería y Análisis 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 algún subconjunto de estos
requisitos al software.

Análisis de los requisitos del software: el proceso de recopilación de los
requisitos se centra e intensifica especialmente en el software. El ingeniero de
software (Analistas) debe comprender el ámbito de la información del
software, así como la función, el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del
programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño traduce
los requisitos en una representación del software con la calidad requerida
antes de que comience la codificación.
Ingeniería y Análisis
del Sistema
Análisis de los
Requisitos
Diseño
Codificación
Prueba
Mantenimiento

Codificación: el diseño debe traducirse en una forma legible para la máquina.
El paso de codificación realiza esta tarea. Si el diseño se realiza de una
manera detallada la codificación puede realizarse mecánicamente.

Prueba: una vez que se ha generado el código comienza la prueba del
programa. La prueba se centra en la lógica 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 después de que se entrega al
cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que
el software deba adaptarse a cambios del entorno externo (sistema operativo
o dispositivos periféricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento.

CARACTERISTICAS
 Es el más utilizado.
 Es una visión del proceso de desarrollo de software como una sucesión de
etapas que producen productos intermedios.
 Para que el proyecto tenga éxito deben desarrollarse todas las fases.
 Las fases continúan hasta que los objetivos se han cumplido.
 Si se cambia el orden de las fases, el producto final será de inferior calidad.

VENTAJAS

 La planificación 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 comunicación con el
usuario final
 El mantenimiento se realiza en el código fuente
 Las revisiones de proyectos de gran complejidad son muy difíciles
 Impone una estructura de gestión 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 repetición 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 también bajo las siguientes denominaciones:
 Método de las comparaciones limitadas sucesivas.
 Ciencia de salir del paso.
 Método 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 núcleo.

En una visión genérica, el proceso se divide en 4 partes:
 Análisis
 Diseño
 Código
 Prueba


Para la producción 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 dotación de
personal suficiente. Los primeros pasos los pueden realizar un grupo
reducido de personas y en cada incremento se añadirá personal, de
ser necesario.
Durante el proceso se trata de llevar a cabo al proyecto en diferentes
partes que al final terminará siendo la solución 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 más
urgencia, de los puntos más importantes del proyecto, los
requerimientos más básicos, difíciles 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 versión.
De este modo podemos terminar una aplicación ejecutable (primera
versión) que podrá ser entregada al cliente para que éste pueda
trabajar en ella y el programador pueda considerar las
recomendaciones que el cliente efectúe para hacer mejoras en el
producto. Estas nuevas mejoras deberán esperar a ser integradas en
la siguiente versión junto con los demás requerimientos que no fueron
tomados en cuenta en la versión 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 corrección 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 más
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 asignación 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.

Características:
 Se evitan proyectos largos y se entrega "algo de valor" a los usuarios
con cierta frecuencia.
 El usuario se involucra más.
 Difícil de evaluar el costo total.
 Difícil 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.
 También 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 sólo al ámbito de cada
incremento.
 Resulta más sencillo acomodar cambios al acotar el tamaño 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 planeación, tanto administrativa como técnica.
 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 rápidas,
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 López, 2003) El modelo
en espiral es una de las más recomendables para el desarrollo y
creación de un programa, ya que consta de pocas etapas o fases, las
cuales se van realizando en manera continua y cíclica. (Sommerville,
2006)
Barry Boehm: Es un ingeniero informático estadounidense y también
es profesor emérito de esta materia en el departamento de ciencias
tecnológicas en la Universidad del Sur de California. Es conocido por
sus múltiples aportes a este campo.

Cada ciclo espiral se divide en 4 etapas:
DEFINICION DE OBJETIVOS: Para esta fase del proyecto se definen
los objetivos específicos, Se identifican las restricciones del proceso y
el producto, y es estipula un plan detallado de administración. Se
identifican los riesgos, se planean estrategias alternativas,
EVALUACION Y REDUCCION DE RIESGOS: Se lleva a cabo un
análisis 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: Después de la evaluación de riesgos
en la interfaz de usuario son dominantes, un modelo de desarrollo
apropiado podría ser la construcción de prototipos evolutivos Si los
riesgos de protección son la principal consideración, un desarrollo
basado en transformaciones formales podría ser el más apropiado, y
así sucesivamente. EI modelo de cascada es el más apropiado para el
desarrollo si el mayor riesgo identificado es la integración de los
subsistemas.
PLANEACION: El proyecto se revisa y se toma la decisión 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
iteración alrededor de la espiral (comenzando en el centro y siguiendo
hacia el exterior), se construyen sucesivas versiones del software,
coda vez más completa y, al final, el propio sistema software
totalmente funcional

TIPO DE METODOLOGÍA ESPIRAL
El modelo en espiral WINWIN de Boehm, define un conjunto de
actividades de negociación al principio de cada paso alrededor de la
espiral. Más que une simple actividad de comunicación con el cliente
se definen las siguientes actividades:
 Identificación del sistema o subsistemas clave de los directivos.
 Determinación de les condiciones de victoria de les directivos.
 Negociación 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 fijación que ayuden e establecer la completitud de
un ciclo alrededor del espiral y proporcionen hitos de decisión.
Un ciclo de espiral comienza con la elaboración de los objetivos tanto
funcionales como de rendimiento. Después 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 característica del modelo en espiral es la gestión de riesgo
de forma periódica del ciclo de desarrollo (Pressman, 1997)
Trata de mejorar los ciclos de vida clásicos 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 análisis de riesgo requiere la participación de personal con alta
cualificación.
 Incorpora objetivos de calidad y gestión de riesgos
 Elimina errores y alternativos no atractivas al comienzo
 Permite iteraciones, vuelta atrás y finalizaciones rápidas
 Cada ciclo empieza identificando:
 Los objetivos de la porción 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
construcción de prototipos en cualquier etapa de evolución del producto.
El modelo en espiral demanda una consideración directa de los riesgos
técnicos en todas las tapas del proyecto y si se aplica adecuadamente debe
reducir los riesgos antes que se conviertan en problemas
DESVENTAJAS
Resulta difícil convencer a grandes clientes que el enfoque evolutivo es
controlable
Debido a su elevada complejidad no se aconseja utilizarlo en pequeños
sistemas u proyectos.
Genera mucho tiempo en el desarrollo de sistemas.


1.1.4. Modelos Concurrente
El modelo concurrente o también llamado ingeniería concurrente
(IC) prácticamente cuenta con una definición por cada uno de los
acercamientos teóricos o prácticos que sobre ella se han realizado;
existe una lista de nombres con los cuales se designan principios o
procesos básicos de la IC tales como ingeniería simultánea,
ingeniería cooperativa, diseño integrado de procesos y productos,
diseño concurrente, etc. (Carlson, 2002).
Aunque las prácticas que son cobijadas por la IC son cada vez
más frecuentes desde 1980, la primera definición dada en 1986 por
el Instituto para Análisis de Sistemas de Defensa de los EE. UU
fue: la ingeniería concurrente “es una aproximación al diseño
concurrente, integrado de productos y a sus procesos
relacionados, incluyendo fabricación y soporte. Esta
aproximación pretende que quienes desarrollan el producto
consideren todos los elementos del ciclo de vida del producto
desde su concepción hasta su desaparición, incluyendo
calidad, costo, tiempo y necesidades del usuario” Está
definición fue divulgada masivamente por Winner et al en 1988.
Otra definición general es la de J. Cleetus (1992): “La ingeniería
concurrente es un enfoque sistemático para el desarrollo de
productos integrados que hace énfasis en la respuesta a las
expectativas del cliente. Involucra valores de equipo, como la
cooperación, la confianza y el intercambio, de tal manera que
la toma de decisiones sea por consenso, con la participación
de todas las perspectivas en paralelo, desde el comienzo del
ciclo de vida del producto”. (Cleetus, 1992)

Rápidamente, y a partir de lo anterior, en 1993, Prasad (Prasad et
al., 1993) detecta los principios fundamentales que están
contenidos en la IC, en virtud de los cuales tal método logra sus
altos márgenes de aceptación entre los teóricos. (Prasad, 1993)
La Integración se da en relación con el contenido y los procesos de
información y conocimiento, a) entre y dentro de las etapas del
proyecto, y b) de todas las tecnologías 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 INGENIERÍA CONCURRENTE

El desarrollo práctico de la ingeniería concurrente a través de los
años le ha permitido a un importante número de teóricos reunir en
categorías algunas de las cualidades más destacables de esta
disciplina. En virtud de su naturaleza abstracta, estas cualidades
reciben el nombre de „fundamentos‟, y son agrupadas en tres tipos
de categorías: principios, componentes y beneficios, los cuales,
aunque semejantes, definen características particulares de los
diversos escenarios en los que se desenvuelve la IC.

Principios Básicos de la IC
Prasad (1996) presenta como los principios básicos de la IC las
características generales que de modo transversal imprimen su
sello en cada uno de los procesos de la organización. En otras
palabras, son los conceptos-clave que permiten identificar un
proceso dentro de la ingeniería concurrente. (Prasad B. , 1996)

 Trabajo estructurado.
 Aprovechamiento del conocimiento común entre los miembros de
cada equipo y entre los equipos de trabajo.
 Estimulación del trabajo en equipo.
 Toma temprana de decisiones de fabricación.
 Descubrimiento temprano de problemas.
 Conservación del propósito por parte de todo el personal vinculado
a los procesos.
 Sentido de propiedad, en tanto que el proyecto es resultado de la
concertación.

Componentes de la IC
Los componentes de la ingeniería concurrente, son las características
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 ingeniería concurrente. Prasad presenta tres componentes
centrales:

Inicio multidisciplinario –también llamado equipo de desarrollo de
producto: La IC se estructura alrededor de equipos multifuncionales
que aportan el conocimiento especializado necesario para el diseño y
desarrollo del producto.

Sinergia y trabajo en equipo: La sinergia, que es la combinación 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 organización que trabaje bajo un enfoque de
ingeniería concurrente. Por su parte, el trabajo en equipo hace énfasis
en las relaciones interpersonales, la cooperación, la negociación y la
toma de decisiones conjunta. Las siete cualidades que deben estar
presentes en un equipo de IC son: empoderamiento, adecuada
selección de personal, organización, liderazgo, autolimitación,
autonomía y memoria técnica o know-how.

Participación global: Un proceso de ingeniería concurrente no es tal
a menos que involucre todas las partes que son responsables por
cada instancia del proceso, sin importar qué vínculos administrativos
tengan. Para que la organización funcione como una unidad y para
que el producto esté completo, cada participante tiene que saber qué
esperan de él los demás.

Beneficios de IC
Uno de los beneficios más destacados de la IC es el que se refleja en
los grupos de trabajo dedicados al diseño y la fabricación del producto.
En estos entornos la IC permite: trabajo en paralelo gracias a la
integración entre los distintos departamentos, prevención de los
errores y anticipación de los problemas, flexibilidad para adaptarse a
los cambios, suministro de información y acceso a la misma sobre
todos los procesos y entrenamiento cruzado.

Una gran parte de estos beneficios están asociados al funcionamiento
general de la organización y se agrupan alrededor del concepto de
racionalización de tiempos, costos y demás recursos. De la
racionalización de estos recursos se desprenden otros beneficios
como son la reducción en el tiempo de desarrollo del producto, un
mayor control de costos de diseño y fabricación, reducción de la
pérdida de tiempo causada por los problemas de comunicación, los
productos llegan al mercado más rápidamente con un menor costo y
un mejor uso de recursos técnicos en épocas de escasez.


OBJETIVOS DE LA INGENIERÍA CONCURRENTE
Como se ha dicho, el objetivo básico de la ingeniería concurrente es la
disminución en el tiempo total transcurrido desde la detección de una
necesidad hasta la comercialización de un producto. La importancia en
la aceleración 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 acompañado de otros objetivos parciales,
no por ello menos importantes, como son la reducción de los costes
totales, el aumento de la calidad y fiabilidad global del producto así
como el incremento del valor añadido. Este último aspecto implica un
cambio de enfoque radical por parte de los técnicos, que deben
anteponer a su criterio la visión del producto por parte del cliente. Ello
conlleva elaborar un conjunto de requerimientos y condicionantes
mucho más completos, y en definitiva un mejor conocimiento del
problema ya desde las etapas más iniciales. (Hartley, 1994)

Los objetivos globales que se persiguen con la implementación de la IC son:

o Acortar los tiempos de desarrollo de los productos.
o Elevar la productividad.
o Aumentar la flexibilidad.
o Mejor utilización de los recursos.
o Productos de alta calidad.
o Reducción en los costos de desarrollo de los productos.
o Establecer conocimiento y cultura de Ingeniería 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
señaladas no es aplicable.

Si no existen grupos de trabajo no
se puede trabajar en este método



METODOLOGÍAS PARA LA IMPLEMENTACIÓN DE ENTORNOS DE
INGENIERÍA CONCURRENTE.
Metodología RACE
La metodología RACE (Evaluación de la Situación para la Ingeniería
Concurrente) fue desarrollada inicialmente por el Departamento de
Defensa de los EE.UU., en el “Centro de Investigación de Ingeniería
Concurrente” El objetivo de RACE fue establecer una estrategia de
entornos de IC, que permitiera realizar una transición adecuada de la
empresa hacia los nuevos modelos de desarrollo de producto. La
implementación de ingeniería concurrente, requiere valorar el estado
actual de las prácticas de gestión en la organización, la cultura
organizativa y el soporte tecnológico para el desarrollo de productos
que repercutirán en el cambio de las prácticas actuales. La propuesta
de RACE se basa en una estrategia propia de transformación que
comprende cuatro etapas que conducen a la IC:
Conocimiento: En esta etapa se definen los planes de implantación,
identificando las necesidades de formación y de nuevas tecnologías
colaborativas. Asimismo, se detectan las posibles barreras al cambio
que pudieran existir en la empresa.
Análisis de la situación. En esta etapa se identifican los puntos críticos
(cuellos de botella) del proceso de desarrollo del producto a través de
un modelo, que permitirá el entendimiento compartido del mismo.
Despliegue: Realización del cambio aplicando las bases de la
reingeniería de procesos y gestionando el nuevo proceso de manera
eficiente.
Mejora: Selección sistemática de Iniciativas de mejora basada en
aquellas que están más en la línea de las directrices de la empresa.
Para controlarlas se definirán indicadores que permitan evaluar el
proceso de desarrollo del producto.


Metodología RACE II
La metodología elaborada en la Universidad Tecnológica de
Eindhoven (Eindhoven Technologic University,Holanda), la cual
desarrolla su propuesta a partir de la metodología de implantación de
IC denominada RACE. La nueva metodología de implantación,
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 método, De Graaf afirma que existen cuatro
cuellos de botella en el modelo RACE los cuales son: “ausencia de
comunicación sobre la estrategia”, “políticas inestables de producto”,
“tecnologías no definidas para el desarrollo del producto” y
“competencias no definidas”. Para resolver esta carencia los engloba
dentro de un nuevo elemento crítico denominado Despliegue de la
Estrategia. A partir de ciertos análisis, se estableció que los criterios
clave para este nuevo elemento crítico debían ser la estrategia de
planificación del producto, la planificación de la tecnología para la
gestión estratégica y la planificación de la cooperación con terceros.

Metodología 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 metodología para la
implantación de la IC, basada también en los trabajos y experiencias
previas de RACE.
Su metodología propone un método de evaluación que determine
básicamente la capacidad de la organización para soportar la IC,
basándose en un modelo integrado de proceso de desarrollo de
producto. Esta metodología se desarrolla en cuatro pasos
secuenciales

Esta metodología propone además una nueva serie de criterios sobre
los cuales realizar la evaluación, abandonando en gran medida los
propuestos originalmente por RACE. Cabe destacar que desaparece
la dimensión Tecnología de RACE, y se define un nuevo criterio
llamado ‘Sistemas Tecnológicos y Herramientas para la IC’ que
contempla todo lo relacionado con la ayuda de las Tecnologías de la
Información a la IC. En cuanto al resto de los criterios, podemos
destacar que la metodología de CESD mantiene aquellos relacionados
con la evaluación de la dimensión Proceso de RACE.
Metodología 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 también hacia la ingeniería concurrente; afirman que los
entornos de desarrollo de producto están sometidos a continuos
cambios, debido a cinco grandes fuerzas : la tecnología (nuevas
tecnologías en la empresa), las nuevas herramientas (selección de las
más adecuadas), la distribución de tareas (gestión y división de
trabajos eficientemente), la potenciación del talento (motivación para
obtener las máximas capacidades de los empleados) y la gestión del
tiempo (reducción del tiempo de introducción del producto en el
mercado). La integración de estas cinco grandes fuerzas permitirá
transformar los procesos de desarrollo de producto en entornos de IC.
Carter y Baker proponen una metodología general que incluye un
análisis de la situación actual y un análisis del entorno deseado, que
permitirá sugerir el entorno de IC
.

MECANISMOS DE LA INGENIERÍA CONCURRENTE
La ingeniería concurrente se sustenta sobre tres pilares, o
mecanismos, básicos que le confieren sus especiales características.
Es importante señalar 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 ingeniería concurrente reciba el nombre de ingeniería
paralela o simultánea. El paralelismo reduce el tiempo global mediante
la realización simultánea de cuantas tareas sea posible.
Incrementar la efectividad mediante la realización de tareas en
paralelo es una idea compartida con otros campos tecnológicos como
por ejemplo el informático, donde los procesadores paralelos y las
técnicas de programación asociadas están suponiendo una verdadera
revolución.
Mediante el paralelismo se racionaliza la descomposición del trabajo,
evitando las pérdidas de tiempo inherentes a un enfoque secuencial.
Al mismo tiempo exige un mejor desarrollo y transferencia de la
información entre tareas.

Integración:
Al paralelismo debe añadirse otro mecanismo básico de la ingeniería
concurrente que es la integración. Uno de los grandes problemas del
enfoque clásico de la ingeniería es sin duda la división del trabajo en
compartimentos estancos y deficientemente comunicados. El
paralelismo fuerza la integración entre departamentos, especialmente
entre ingeniería y producción, lo que reduce el impacto de la división
de trabajo en áreas de especialización y gestión. Sólo mediante la
integración es posible tomar en consideración todo el conocimiento de
las disciplinas relevantes en cada fase del desarrollo del producto.
Además de mejorar la comunicación, la integración evita la repetición
innecesaria de tareas por diferencias de criterios y la suboptimización
derivada de enfoques excesivamente parciales.

Presciencia:
Los mecanismos de paralelismo e integración presentan substanciales
ventajas conceptuales respecto a un enfoque clásico de la ingeniería
de tipo secuencial, y definen por sí solos las características básicas de
un entorno de ingeniería concurrente. No obstante su aplicación
supone una serie de dificultades notables entre las que destaca un
aumento de la ambigüedad y de la incertidumbre en todas las fases
del desarrollo, siendo necesario tomar decisiones cada vez más
tempranas, y en base a información incompleta, situación que por otra
parte debe hacerse compatible con un aumento en la calidad y
fiabilidad del producto final.
En consecuencia debe añadirse un tercer mecanismo destinado a
disminuir el impacto de esta aparente contradicción. Dicho mecanismo
es la presciencia, o conjunto de técnicas cuya misión es avanzar el
curso de los hechos. Sólo a través de ellas es posible estar
preparados frente a posibles eventualidades mediante la exploración
temprana de las actividades futuras, tomando así las decisiones
adecuadas cuanto antes y al mínimo coste.
La presciencia es la clave para alcanzar el objetivo de conseguir el
resultado correcto al primer intento, evitando la repetición innecesaria
de tareas y la toma de decisiones erróneas.

TÉCNICAS Y HERRAMIENTAS DE LA INGENIERÍA CONCURRENTE
La implementación práctica de la Ingeniería concurrente supone el uso
de toda una serie de técnicas y herramientas especialmente
adaptadas para ella y sin las cuales no sería posible alcanzar los
niveles de eficacia exigidos. A continuación se enuncian y describen
brevemente dichas técnicas.

Técnicas
Se incluyen en este apartado una serie de técnicas con una incidencia
directa sobre la calidad de diseño. La calidad del diseño es un factor
clave del éxito puesto que limita la máxima calidad alcanzable por un
producto.


Brainstorming
El brainstorming es una técnica creativa para la búsqueda de
soluciones (o causas) a un problema dado. La principal característica
del método es la prohibición de efectuar críticas a las ideas expuestas
por los miembros del grupo de trabajo a fin de evitar la inhibición de
cualquiera de ellos. Dichas ideas son después agrupadas por
categorías y priorizadas por votación en orden a generar un plan de
actuación.

Diagramas Causa Efecto
El diagrama Causas-Efecto de Ishikawa consiste en la representación
gráfica, ordenada y lógica, de la cadena de causas que conducen a un
determinado efecto. Puede aplicarse como paso intermedio en la
aplicación de otras técnicas como el AMFE, o directamente para
buscar la solución a un determinado problema.

Despliegue de la función de calidad (QFD)
El QFD es una técnica sistemática para relacionar los requisitos
demandados por el mercado (voz del cliente) con las características
técnicas del producto a través de cada etapa de su creación, con la
participación de todas las funciones de la empresa que intervienen en
el mismo. La herramienta básica del QFD es la construcción de
matrices de interrelación a todos los niveles.

Análisis del Valor
Las técnicas de análisis del valor están orientadas también a la
satisfacción de las necesidades del cliente pero poniendo el énfasis en
la optimización simultánea de los costes y los procesos. Para ello se
separan los aspectos que generan “valor” de aquellos que sólo
generan coste, priorizando a los primeros sobre los segundos.

El valor es la suma de la impresión inicial del usuario ante el producto
y la satisfacción durante el uso. El coste integra todas las
componentes desde el desarrollo inicial hasta el final de la vida útil.

Análisis de modos de fallo y sus efectos (AMFE)
El AMFE es una técnica sistemática 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 análisis
se establecen prioridades así como un plan de actuación encaminado
a eliminar o minimizar las causas más importantes de los fallos.

Diseño de experimentos (DOE)
Las técnicas de diseño de experimentos están encaminadas a la
planificación estadística de los ensayos a fin de maximizar la
información extraída (efecto de la variación de los parámetros sobre el
comportamiento del sistema) minimizando el número de los mismos.
El diseño de experimentos se complementa con el análisis de las
superficies de respuesta y las técnicas de optimización. De entre las
técnicas de optimización destacan los métodos de diseño robusto de
Taguchi cuyo objetivo es minimizar la sensibilidad del comportamiento
del producto a las variaciones en los parámetros de entrada.

Diseño para la manufactura y el ensamblaje (DFMA)
Las técnicas DFMA intentan asegurar una fabricación más fácil a
través de la simplificación de todas las operaciones. La idea básica es
minimizar el número 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
dirección, ajuste fácil, piezas de sujeción separadas, etc…).

Herramientas
La aplicación de la ingeniería concurrente exige también la utilización
de una serie de herramientas basadas en la informática y las
tecnologías de la información. Sin dichas herramientas es
prácticamente imposible conseguir los niveles de integración,
comunicación y predicción exigidos por el enfoque concurrente.


Diseño y fabricación asistidas (CAD/CAM)
El diseño asistido por ordenador (CAD) es indispensable en un
entorno de ingeniería concurrente, no sólo por cuestiones de eficacia
operativa sino también para garantizar un intercambio ágil y sin
errores así como una actualización constante de la información entre
los diversos grupos de trabajo implicados en el proyecto
(especialmente entre las ingenierías de producto y fabricación). Con
una adecuada combinación de hardware y software pueden
conseguirse drásticas reducciones en los plazos de ejecución,
especialmente cuando se integra la información de diseño con la
generación de programas de mecanizado (CAM).



Simulación numérica (CAE)
La necesidad de la previsión forma ya parte del enfoque ingenieril
clásico en el que el desarrollo experimental juega, desde hace muchos
años, un papel fundamental en orden a evitar problemas durante el
uso. En este sentido la experimentación sobre prototipos físicos
constituye una versión básica de la presciencia, que distingue al
producto industrial del producto artesanal, cuya evolución se produce
mediante un esquema de prueba, error y selección puramente
darwiniano.
Consecuencia de ello, los departamentos de ensayos tienen una larga
tradición 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 disminución de
costes y tiempos de desarrollo dificulta mucho la utilización de la
experimentación como única herramienta de la presciencia.
Afortunadamente los avances realizados en el mundo de la informática
y de la simulación numérica de los fenómenos físicos ha permitido
incorporar al proceso un bucle rápido de valoración y optimización
basado en las herramientas de simulación.
La simulación no sólo es de utilidad en las etapas iniciales de
definición del producto sino que también los es en el diseño y
desarrollo de los procesos de fabricación. Hoy en día es posible
simular los procesos de inyección, fundición, forja, conformado de
chapa y corte.
Mediante estas herramientas puede ponerse a punto el proceso de
fabricación de forma virtual y antes de realizar importantes inversiones
en medios de producción.

Ensayo (CAT)
Al tratarse de una tecnología relativamente reciente, los
departamentos encargados de realizar los trabajos de simulación
suelen estar desligados de los departamentos responsables de la
realización de los ensayos, creándose dos “culturas” diferentes que
dificultan la integración.
Esta es una situación claramente a evitar puesto que la mayor
efectividad conjunta de las herramientas de ensayo y simulación sólo
se alcanza aprovechando sus sinergias y a través de un proceso de
adaptación mutua en el que la experimentación ya no juega el mismo
papel que anteriormente. A título de ejemplo se apuntan seguidamente
algunos de los aspectos en los que la simulación requiere un soporte
experimental adecuado, y que sin duda constituirán una área de
crecimiento para las técnicas experimentales en el futuro inmediato.

DISEÑO Y DESARROLLO MODULAR
Como ya se ha dicho, el principal objetivo de la Ingeniería Concurrente
en la entrega al mercado de productos nuevos más fiables y en menos
tiempo. La paralelización de los procesos es por ello fundamental. Sin
embargo, aún es posible conseguir mayor paralelización y en
consecuencia menor tiempo de desarrollo si se aplica la
modularización del producto.
La modularización del producto consiste en diseñar y desarrollar
productos considerándolos como la suma de grupos de elementos que
interaccionan, con una función común y cierta autonomía de conjunto.
A estos grupos les denomina módulos.
Cada módulo 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 reducción de plazos es evidente,
siempre y cuando la empresa disponga de recursos suficientes para
llevar a cabo los desarrollos simultáneos.
El desarrollo modular tiene otra ventaja. Si consideramos el producto
final como un conjunto de subsistemas, y se diseñan interfaces
robustas (que no se vean afectadas por las modificaciones en el
diseño), es mucho más fácil desarrollar cambios y mejoras en los
productos. Con una misma base, es posible crear toda una amplia
gama de productos cambiando algún o algunos módulos. Además las
mejoras en el producto se harán también de forma modular, con lo que
la probabilidad de fallar se reduce considerablemente. Todo esto
implica la posibilidad de crear nuevos productos con una inversión
más 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 creación e interconexión de componentes software, junto
con una colección 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 dinámicamente 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
heterogéneos ingresar o abandonar el sistema de forma dinámica.
Estas condiciones implican que los sistemas abiertos son
inherentemente evolutivos, y que la vida de sus componentes es más
corta que la del propio sistema.
Como consecuencia de dichas características, el desarrollo de
aplicaciones para este tipo de sistemas se ve afectado por una serie
de problemas específicos, como son la gestión de la evolución del
propio sistema y de sus componentes, la falta de una visión global del
sistema, la dificultad para garantizar la seguridad y confidencialidad de
los mensajes y errores de comunicación.
El tratamiento de estas situaciones es lo que ha hecho ver la
necesidad de nuevos modelos, pues la programación tradicional se ha
visto incapaz de tratarlos de una forma natural. Así la Programación
Orientada a Objetos (POO) ha sido el sustento de la ingeniería del
software para los sistemas cerrados.
Sin embargo, se ha mostrado insuficiencias al tratar de explicar sus
técnicas para el desarrollo de las aplicaciones en entornos abiertos.
A partir de estas restricciones es que nace la Programación Orientada
a Componentes (POC) como una extensión natural de la orientación a
objetos para los entornos abiertos. (Nierstrasz, 1995)
Este paradigma propugna el desarrollo y utilización de componentes
reutilizables dentro de lo que sería un mercado global de software.
Para hablar de la existencia de un mercado de componentes software
es necesario que los componentes estén empaquetados de forma que
permitan su distribución y composición con otros componentes,
especialmente con aquellos desarrollados por terceras partes. Esto
nos lleva a la definición 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 modificación según un
estándar de composición.
Esta definición se basa fundamentalmente en estándares, una unidad software que
se ajusta a estos estándares es un componente. Szyperski (Szyperski, 2002), sin
embargo, no menciona los estándares en su definición de componentes, sino que,
en vez de eso, se centra en las características clave de los componentes:
Un componente software es una unidad de composición con interfaces
especificadas contractualmente y dependencias de contexto explícitas únicamente.
Un componente software puede ser desplegado de forma independiente y está
sujeto a la composición por terceras partes.
Lo que tienen en común estas dos definiciones es que están de acuerdo en que los
componentes son independientes y que son unidades de composición
fundamentales en un sistema. Desde nuestro punto de vista, una definición
completa de componente puede derivarse desde ambas propuestas. (Sommerville,
2005)
Conceptos básicos
El modelo de desarrollo basado en componentes incorpora muchas de las
características del modelo espiral. Es de naturaleza evolutiva y demanda un
enfoque iterativo para la creación 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 construcción comienzan con la identificación
de candidatos de componentes. Éstos pueden diseñarse como módulos de
software convencional o clases orientadas a objetos o paquetes de clases.
Sin importar la tecnología usada para crear los componentes, el modelo de
desarrollo basado en componentes incorpora las etapas siguientes:
1. Se investiga y evalúan, para el tipo de aplicación de que se trate,
productos disponibles basados en componentes.
2. Se consideran los aspectos de integración de los componentes.
3. Se diseña una arquitectura del software para que reciba los componentes.
4. Se integran los componentes en la arquitectura.
5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad
apropiada.
El modelo del desarrollo basado en componentes lleva a la reutilización del
software, y eso da a los ingenieros de software varios beneficios en cuanto a
la mensurabilidad. Si la reutilización de componentes se vuelve parte de la
cultura, el equipo de ingeniería 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:
Análisis de Componentes: Dada la especificación de requerimientos, se
buscan los componentes para implementar esta especificación. Por lo general,
no existe una concordancia exacta y los componentes que se utilizan sólo
proporcionan parte de la funcionalidad requerida.
Modificación de Requerimientos: En esta etapa, los requerimientos se
analizan utilizando información 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
análisis de componentes se puede llevar a cabo nuevamente para buscar
soluciones alternativas.
Diseño del Sistema con reutilización: En esta fase se diseña o se reutiliza un
marco de trabajo para el sistema. Los diseñadores tienen en cuenta los
componentes que se reutilizan y organizan el marco de trabajo para que los
satisfaga. Si los componentes reutilizables no están disponibles, se puede tener
que diseñar nuevo software.
Desarrollo e Integración: 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 integración de sistemas es parte del proceso de
desarrollo, más que una actividad separada.
Beneficios del desarrollo de Software basado en componentes
Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización
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 débil acoplamiento
entre componentes, el desarrollador es libre de actualizar y/o agregar
componentes según 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 organización, la calidad de una
aplicación basada en componentes mejorará con el paso del
tiempo(SOMMERVILLE, 2005).


Carácterísticas 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 algún 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 deberían hacerse explícitos 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 públicamente.
Ademas debe proporcionar acceso externo a la información sobre si mismo,
como por ejemplo a sus métodos y atributos.
Desplegable: Para ser desplegable, un componente debe ser independiente y
debe ser capaz de funcionar como una entidad autónoma 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 Métodos formales
Un método formal es una técnica basada en matemáticas, usada para
describir sistemas de hardware o software, (Wing, 1990). Los métodos
formales permiten representar la especificación del software,
verificación y diseño de componentes mediante notaciones
matemáticas. El uso de métodos formales permite plantear de manera
clara la especificación de un sistema, generando modelos que definen
el comportamiento en términos del “qué debe hacer” y no del “cómo lo
hace”. Gracias al correcto proceso de especificación, se pueden
verificar propiedades derivadas de cada módulo mediante técnicas de
razonamiento asociadas a los modelos formales, como probadores de
teoremas y verificadores de modelos (Hall, 1996).

El valor de los métodos formales radica en que proporcionan un medio
para examinar simbólicamente todos los espacios del estado de un
diseño digital y para establecer una propiedad segura de correctitud que
sea verdadera para todas las posibles entradas (Serna, 2010). Sin
embargo, en la práctica actual rara vez se hace debido a la enorme
complejidad de los sistemas reales. A pesar de que la Verificación
formal completa de un sistema complejo grande es poco práctica en
este momento, los métodos formales sustentan diversos aspectos o
propiedades de estos sistemas: a la especificación detallada, al diseño
y a la verificación de las partes críticas, como en la aviación, en los
sistemas aeroespaciales y en sistemas de seguridad crítica como el
monitoreo de la frecuencia cardíaca.
Para los procesos de especificación 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 lógica de
primer orden. La semántica de los lenguajes está basada en la teoría de
conjuntos. Ejemplos: VDM, Z, B, OCL.
 Lenguajes basados en especificaciones algebraicas.
Proponen una descripción 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 través de un conjunto de axiomas o ecuaciones que
especifican las restricciones que dében satisfacer las operaciones.
Algunos ejemplos: Larch, OBJ, TADs.
 Lenguajes de especificación de comportamiento:
Métodos basados en álgebra de procesos: modelan la interacción
entre procesos concurrentes. Esto ha potenciado su difusión en la
especificación de sistemas de comunicación (protocolos y servicios de
telecomunicaciones) y de sistemas distribuidos y concurrentes. Algunos
ejemplos son: CCS, CSP, Pi Calculus y LOTOS.
Métodos basados en Redes de Petri: una red de Petri es un
formalismo basado en autómatas, es decir, un modelo formal basado en
flujos de información. Permiten expresar eventos concurrentes. Los
formalismos basados en redes de Petri establecen la noción de estado
de un sistema mediante lugares que pueden contener marcas. Un
conjunto de transiciones (con pre y post condiciones) describe la
evolución del sistema entendida como la producción y consumo de
marcas en varios puntos de la red.
 Métodos basados en lógica temporal: se usan para especificar
sistemas concurrentes y reactivos. Los sistemas reactivos son aquellos
que mantienen una continua interacción con su entorno respondiendo a
los estímulos 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 ejecución no tiene por qué terminar

En cuanto al proceso de verificación se tienen básicamente dos
enfoques:

 Verificación de modelos: trabajan mediante una búsqueda
exhaustiva en los estados posibles de un modelo para encontrar
errores en la especificación.

 Prueba de teoremas: donde a partir de un conjunto de axiomas se
trata de probar si la especificación, extendida con algunos teoremas,
es válida


Los métodos formales en la Ingeniería de Software
En Ingeniería de Software, un método formal es un proceso que se aplica
para desarrollar programas, y que explota el poder de la notación y de las
pruebas matemáticas. Además, los requisitos, la especificación y el
sistema completo deben validarse con las necesidades del mundo real
(Kuhn, Chandramouli, & Butler, 2002). En la Ingeniería de Software los
métodos formales se utilizan para:

 Las políticas de los requisitos. En un sistema seguro se convierten
en las principales propiedades de seguridad que éste debe conservar -
el modelo de políticas de seguridad formal -, como confidencialidad o
integridad de datos
 La especificación. Es una descripción matemática basada en el
comportamiento del sistema, que utiliza tablas de estado o lógica
matemática. 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 críticas.
 Las pruebas de correspondencia entre la especificación y los
requisitos. Es necesario demostrar que el sistema, tal como se
describe en la especificación, establece y conserva las propiedades de
las políticas de los requisitos. Si están en notación formal se pueden
diseñar pruebas rigurosas manuales o automáticas.
 Las pruebas de correspondencia entre el código fuente y la
especificación. Aunque muchas técnicas formales se crearon
inicialmente para probar la correctitud del código, pocas veces se
logra debido al tiempo y costo implicados, pero pueden aplicarse a los
componentes críticos del sistema.
 Pruebas de correspondencia entre el código máquina y el código
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 Ingeniería del software. Está basado en la programación
orientada a aspectos (POA) y centrado en la separación de incumbencias
transversales o crosscuting concerns. Muchos conceptos y/o elementos de
modelación se utilizan durante las diferentes etapas del DSOA, sin embargo, se
presentan ambigüedades en cuanto a su semántica, no es claro cuál de ellos debe
ser utilizado en cuál etapa. (Aldawud, 2003)
Define un mecanismo que ayuda a resolver problemas complementarios de código
disperso o scattered (un mismo servicio es invocado de manera similar desde
muchas partes del programa) y código enmarañado o tangled (una misma
operación tiene que acceder a varios servicios, además de cumplir con su función
específica).
Provee una unidad modular llamada aspecto y un mecanismo de composición que
permite entremezclar unidades modulares de comportamiento común con otras
unidades modulares básicas del sistema. El desarrollo de software orientado a
aspectos (DSOA) se enfoca en crear una mejor abstracción modular del sistema.
Incluye las siguientes fases:
- Captura de requisitos
- Análisis
- Diseño
- Implementación
- Pruebas
La primera fase trata la separación de intereses tanto los funcionales como los no
funcionales; los requisitos funcionales son modelados con casos de uso que
representan la función básica del sistema y los requisitos no funcionales se
representan con casos de uso de infraestructura. En el análisis y el diseño los casos
de uso se representan en una estructura de composición 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
implementación se genera el código de las clases y aspectos.
Por último en las pruebas se diseñan las pruebas tanto para los casos de uso de la
aplicación como para los casos de uso slice.





Captura de requisitos
En esta fase se identifican dos categorías de casos de uso: de aplicación y de
infraestructura. Los casos de uso de aplicación describen las funcionalidades
básicas del sistema. Los casos de uso de infraestructura describen cómo el sistema
agrega cualidades como facilidad de uso, confiabilidad, de rendimiento y de soporte
para cada paso de un caso de uso de aplicación.







La primera actividad consiste en entender los intereses de los stakeholders. El
resultado es obtener una lista de características del sistema la cual incluye
requisitos funcionales y no funcionales. A continuación, se capturan los casos de
uso de la aplicación. Esta actividad consiste en identificar actores y casos de usos a
partir de los requisitos funcionales de la lista de características, y describir los casos
de uso en las especificaciones de casos de uso contemplando posibles
extensiones. La descripción 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 aplicación. Para
ello, se revisa nuevamente la lista de características del sistema para identificar a
los requisitos no funcionales que afectan a algún paso de los casos de uso de
aplicación, los cuáles serán tratados como casos de uso de transacción (use-case
transaction si se tratan de requisitos de infraestructura para el sistema.
Esta actividad termina con la descripción de estos tipos de casos de uso en una
especificación contemplando también sus flujos alternativos)
Análisis
Durante el análisis se identifica la estructura de los elementos del análisis en
términos de capas, paquetes y clases (boundary, control y entity). También 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
específicas y no específicas respectivamente que permiten organizar mucho mejor
el sistema.
Un use-case slice contiene elementos necesarios para un caso de uso específico:
una colaboración, que describe la realización de un caso de uso; una o más clases
específicas, que son requeridas para la realización del caso de uso; y extensiones
de clase específicas para un cierto aspecto.
Un non-uc-specific slice contiene clases del dominio del problema que se usan en
muchos casos de uso.








Diseño
Aquí se incluyen actividades relacionadas a refinar las dos estructuras identificadas
en el análisis incluyendo detalles del ambiente de implementación. Mientras que la
estructura del modelo de análisis es independiente de la plataforma (lenguajes de
programación y tecnología), el modelo de diseño es específico a una plataforma
que será utilizado en la implementación.
El proceso de refinamiento consiste en refinar las clases con detalles de
implementación y refinar los casos de uso slice incluyendo aspectos y las
extensiones de clases.










Implementación
En esta etapa se genera el código de las clases con un lenguaje de implementación
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 codificación. Se diseñan
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 través 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 definición para tales lenguajes sería: Los LOA son
aquellos lenguajes que permiten separar la definición de la funcionalidad pura de la
definición 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 fácilmente 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
definición 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 abstracción y composición
pueden verse como agrupados bajo una misma raíz. Esa raíz tendría la forma de un
procedimiento generalizado. Los métodos de diseño que han surgido para los LPG
tienden a dividir el sistema en unidades de comportamiento o funciones. A este
estilo se lo conoce como descomposición funcional (si bien la naturaleza exacta de
la descomposición funcional difiere entre los paradigmas, para los propósitos 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 aún deban ser coordinadas. Esto se
debe a que tienen un comportamiento en común. Al proveer los LPG solamente un
único medio de composición, 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 código.
Podemos diferenciar los aspectos de los demás 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 fácilmente 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 semántica de los componentes en forma sistemática
(Ejemplo: sincronización, manejo de memoria, distribución, etc.)
A la luz de estos términos, 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 través 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 código. Los aspectos son la unidad básica de la
programación orientada a aspectos. Una definición más 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
diseño como en la de implementación. Un aspecto de diseño es una unidad
modular del diseño que se entremezcla en la estructura de otras partes del diseño.
Un aspecto de implementación 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 básica, conocido como lenguaje base o
componente. Podría 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 sincronización, RIDL, para distribución, AspectJ, de
propósito general.)
- Un tejedor de aspectos (Weaver), que se encargará de combinar los lenguajes.
Tal proceso se puede retrasar para hacerse en tiempo de ejecución o en tiempo de
compilación.
Los lenguajes orientados a aspectos definen una nueva unidad de programación de
software para encapsular aquellos conceptos que cruzan todo el código. A la hora
de “tejer” los componentes y los aspectos para formar el sistema final, es claro que
se necesita una interacción entre el código de los componentes y el código de los
aspectos. También es claro que esta interacción no es la misma interacción que
ocurre entre los módulos del lenguaje base, donde la comunicación está basada en
declaraciones de tipo y llamadas a procedimientos y funciones. La POA define
entonces una nueva forma de interacción, provista a través de los puntos de enlace
(join points). Los puntos de enlace brindan la interfaz entre aspectos y
componentes; son lugares dentro del código donde es posible agregar el
comportamiento adicional que destaca a la POA. Dicho comportamiento adicional
es especificado en los aspectos.
Aún nos falta introducir el encargado principal en el proceso de la POA. Este
encargado principal conocido como tejedor debe realizar la parte final y más
importante: “tejer” los diferentes mecanismos de abstracción y composición 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 implementación basada en aspectos es análoga a la
estructura de una implementación basada en los LPG. Una implementación basada
en LPG consiste en:
- Un lenguaje.
- Un compilador o intérprete para ese lenguaje.
- Un programa escrito en ese lenguaje que implemente la aplicación.







Una implementación basada en POA consiste en:
- El lenguaje base o componente para programar la funcionalidad básica.
- Uno o más lenguajes de aspectos para especificar los aspectos.
- Un tejedor de aspectos para la combinación de los lenguajes.
- El programa escrito en el lenguaje componente que implementa los componentes.
- Uno o más programas de aspectos que implementan los aspectos.
Gráficamente, se tiene una estructura como la siguiente:


Cabe notar que la función 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 más que un simple proceso; es un marco
de trabajo genérico que puede especializarse en una gran variedad de
sistema software, para diferentes aéreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de aptitudes y diferentes tamaños de
proyecto. (Jacobson/Booch/Rumbauch, 2000)

Proceso Unificado Racional (RUP)
Es un proceso de la Ingeniería de Software propuesto por Rational Software
Corporación Inc. Para la construcción completa del ciclo de ingeniería del
software. Permite la productividad en equipo y la realización de mejores
prácticas de software a través de plantillas y herramientas que lo guían en
todas las actividades de desarrollo crítico del software, alineando un
disciplinado enfoque a la asignación de tareas y responsabilidades dentro de
una organización 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
configuración de cambios y pruebas, cubriendo todo el ciclo de vida, manejo,
configuración de cambios y pruebas, cubriendo todo el ciclo de vida de los
proyectos basados en construcción de componentes y maximizando el uso del
UML (Unified Modeling Language).

Un proceso define quien está haciendo que, y cuando, además dice
como alcanzar un determinado objetivo. En la ingeniería 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.
Según 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 prácticas
que la tecnología permite. Por tanto reduce el riesgo y hace el proyecto
más 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 orientación 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 años de trabajo individual desarrollado y difundido sus
propios métodos, han unido sus teorías 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 programación: 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 aceptación de amplios sectores
de las industria y la academia, RUP sigue siendo aún una propuesta que
deber á depurarse y templarse al calor de la experiencia de su aplicación 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 están estrechamente relacionados entre si, pues mientras
el primero establece las actividades y los criterios para conducir un sistema
desde su máximo nivel de abstracción, el segundo ofrece la notación gráfica
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. Características Principales:
- Es un proceso incremental
- Sus actividades destacan en la creación y mantenimiento de modelos
más documentos sobre papel.
- Su desarrollo está centrado en arquitectura.
- Sus actividades están dirigidas a los Use Case.
- Soportan las técnicas orientadas a objetos.
- Es un proceso configurable.
- Impulsa un control de calidad y una gestión 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 más manejable.
- Hay un nivel más 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 lógico. Los flujos de trabajo centrales están divididos
dentro de seis flujos de trabajo de ingeniería y tres flujos de trabajo de
soporte.
Los flujos de trabajo de ingeniería son los siguientes:
1. Flujos de trabajo del modelado de negocio.
2. Flujos de trabajo de requerimientos.
3. Flujos de trabajo de análisis y diseño.
4. Flujos de trabajo de implementación.
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 administración de proyecto.
2. Flujos de trabajo de administración de configuración 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: cómo se estructuran las tareas, cómo se realizan, cuál es su
orden correlativo, cómo se sincronizan, cómo fluye la información que
soporta las tareas y cómo se le hace seguimiento al cumplimiento de
las tareas.
Una aplicación de Flujos de Trabajo automatiza la secuencia de
acciones, actividades o tareas utilizadas para la ejecución del proceso,
incluyendo el seguimiento del estado de cada una de sus etapas y la
aportación 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 común. 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
cooperación 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 límites del sistema.
- Proveer una base para el planeamiento de contenidos técnicos de las
iteraciones.
- Proveer una base para estimar los costos y tiempo de desarrollo del
sistema.
- Definir una interfaz de usuario para el sistema, enfocándolas sobre las
necesidades y metas de los usuarios.

f. Flujos de Trabajo de Análisis y Diseño:
El propósito de flujos de trabajo del análisis y diseño es el traducir los
requerimientos dentro de una especificación que describe cómo
implementar el sistema. Para hacer esta traducción, se deben
entender los requerimientos y transformarlos dentro de un sistema de
diseño, seleccionando la mejor estrategia de implementación.
Se debe establecer en el proyecto una arquitectura robusta para poder
diseñar un sistema que sea fácil entender, construir y evolucionar.

g. Flujos de Trabajo de Implementación:
El flujo de trabajo de implementación tiene cuatro propósitos:
- Definir la organización del código en términos de subsistemas de
implementación organizados en capas.
- Implementar clases y objetos en términos 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 propósito 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 evaluación de la arquitectura y
continúa a través de la evaluación del producto final entregado a los
clientes.
Involucra los siguientes puntos:
- Verificar la interacción de componentes.
- Verificar la integración 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 propósito 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.
- Migración 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 obtención de requisitos de usuario. Donde los casos
de uso son para definir la funcionalidad del sistema, y guían al desarrollador
en la construcción de la arquitectura del sistema.
La descripción obtenida de los requerimientos debe ser comprendida por
casos de uso que nos ayudan a recopilar la información acerca de la
interacción 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 algún actor, que sirven para realzar pruebas
sobre los componentes desarrollados (ver Figura. 1.3). Los casos de uso
enlazan los flujos de trabajo fundaméntales. El proyecto progresa a
través 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 Análisis Diseño Implementación
Pruebas


(Carig, 1999)



LENGUAJE DE MODELADO UNIFICADO (UML)
UML, emergió en los '9 0 luego de la búsqueda de un lenguaje de
modelamiento que unificara a la industria, que siguió a la "guerra de
métodos" de los '70 y '80. A pesar de que UML evolucionó primeramente de
varios métodos orientados al objeto de segunda generación (en nivel de
notación), UML no es simplemente un lenguaje para modelamiento
orientado al objeto de tercera generación. Su alcance extiende su uso
más allá de sus predecesores. Y es la experiencia, experimentación y una
gradual adopción del estándar lo que revelará su verdadero potencial y
posibilitara a las organizaciones darse cuenta de sus beneficios.
DE



EVIDENTE Debe realizarse y el usuario debería saber que se ha realizado


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

muchos servicios técnicos , como guardar información 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 Categoría de las Funciones





Fuente: (Carig, 1999)

Diagramas de Casos de Uso
Los casos de uso no son propiamente un caso de análisis, 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
tecnología 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 desempeñan en el caso: Cliente, técnico u otro. Conviene
escribir su nombre con mayúscula en la narrativa del caso para facilitar la
identificación (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 utilización de un sistema, no son exactamente los
requerimientos, ni las especificaciones funcionales, sino que ejemplifican
e incluyen tácticamente los requerimientos en las historias que narran (ver
Figura. 1.6).

Figura 1.6 Caso de Uso

Fuente: (Carig, 1999)

c) Relación
Si un caso de uso inicia o contiene el comportamiento de otro se dice que
usa el segundo caso, eso es una relación unidireccional. Esta relación puede
presentar uno de los siguientes tipos:
 La relación “usa”, se utiliza cuando se quiere reflejar un
comportamiento común en varios casos de uso (ver Figura. 1.7).
 La relación “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 más detalle.
Figura 1.7 Relación 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 vértices donde descansa un proceso de mejora que
trabaja sobre 3 niveles de la organización, 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 KPA’s (á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 prácticas disciplinadas
para la gestión 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 diseñado 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 guía 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 medición 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 obsesión por la toma de datos y elaboración
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 :
 Estándares de código.
 Medición de tamaño.
 Nivel 1 - Inicial:
 Estimación de tamaño.
 Reporte de pruebas.
 Nivel 1.1:
 Calendario de planeación de tareas.
 Nivel 2 - Repetible:
 Revisión de diseño y código.
 Nivel 2.1:
 Plantillas de Diseño.
 Nivel 3
 Mejora el ciclo, mejora del proceso en términos de hacerlo repetible
(cíclico):
 Para aplicación a programas de mayor tamaño
 Registro del seguimiento de asuntos importantes
 Análisis del resumen de la planeación, tiempos, tamaños 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 estimulación por nuevas ideas
• Una estructura de trabajo de mejoramiento personal
• Tomar control del propio trabajo
• La sensación de logro
• Una base mejorada para el trabajo en grupo (TSP)
• La convicción 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 Capacitación es sobre grupos o equipos, y serán grupos que así lo
han sido y seguirán siendo.
3. Requiere un fuerte soporte de administración, en este sentido es
necesario que los administradores entiendan el PSP, saber cómo
apoyarlos y como monitorear sus avances, sin un adecuado monitoreo
los ingenieros caerán otra vez en los malos hábitos.
4. Después de ser bien entrenados y bien administrados lo que sigue es
optimizar la interacción entre equipos y aquí entraría Team Software
Process, el TSP extiende y refina los métodos 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
introducción 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 dueños 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 cómo dirigir y motivar a sus equipos y cómo
ayudarlos a mantener un rendimiento máximo. •
 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 guía para la mejora.
 Facilitar la enseñanza universitaria de aptitudes de equipo con grado
industrial. Un equipo autodirigido tiene la comprensión 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
estándares locales aplicables al trabajo de ingeniería de software del
equipo; evalúa 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,
diseño de alto nivel, implementación, integración y pruebas, y post mórtem.
Como sus contrapartes del PPS (observe que la terminología es algo
diferente), estas actividades permiten que el equipo planee, diseñe y construya
software en forma disciplinada, al mismo tiempo que mide cuantitativamente el
proceso y el producto. La etapa post mórtem es el escenario de las mejoras del
proceso. El PES utiliza una variedad amplia de scripts, formatos y estándares
que guían a los miembros del equipo en su trabajo. Los scripts definen
actividades específicas del proceso (por ejemplo, inicio del proyecto, diseño,
implementación, integración y pruebas del sistema, y post mórtem), así como
otras funciones más detalladas del trabajo (planeación del desarrollo,
desarrollo de requerimientos, administración de la configuración 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 programación de
actividades del proyecto y, con la medida y análisis de las mediciones
efectuadas, trabajan de manera continua en la mejora del enfoque de
ingeniería de software que tiene el equipo. Igual que el PPS, el PES es un
enfoque riguroso para la ingeniería de software y proporciona beneficios
distintivos y cuantificables en productividad y calidad. El equipo debe tener un
compromiso total con el proceso y recibir capacitación completa para asegurar
que el enfoque se aplique en forma apropiada. (Roger S. Pressman, 2010)

1.5. Metodologías Agiles
1.5.1. Programación Extrema
 La Programación Extrema o eXtreme Programming (XP) es un
enfoque de la Ingeniería de Software formulado por Kent Beck, autor
del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el más destacado de los procesos ágiles
de desarrollo de software. Al igual que estos, la programación extrema
se diferencia de las metodologías tradicionales principalmente en que
pone más é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 aproximación mejor y más realista que intentar definir todos los
requisitos al comienzo del proyecto e invertir esfuerzos después de
controlar los cambios en los requisitos. Se puede considerar la
programación extrema como la adopción de las mejores metodologías
de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del
software.
(Pressman, 1997)
Valores
Los valores originales de la programación extrema son: simplicidad,
comunicación, retroalimentación (feedback) y coraje. Un quinto valor,
respeto, fue añadido en la segunda edición de Extreme Programming
Explained. Los cinco valores se detallan a continuación:
Simplicidad
La simplicidad es la base de la programación extrema. Se simplifica el diseño
para agilizar el desarrollo y facilitar el mantenimiento. Para mantener la
simplicidad es necesaria la refactorización del código, ésta es la manera de
mantener el código simple a medida que crece. También se aplica la
simplicidad en la documentación, de esta manera el código debe comentarse
en su justa medida, intentando eso sí que el código esté autodocumentado.
(Pressman,
Ingeniería del software: un enfoque práctico, 1997)
Comunicación
La comunicación se realiza de diferentes formas. Para los programadores, el
código comunica mejor cuanto más simple sea. Si el código es complejo hay
que esforzarse para hacerlo inteligible. La comunicación con el cliente es
fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide
que características tienen prioridad y siempre debe estar disponible para
solucionar dudas(Pressman, Ingeniería del software: un enfoque práctico,
1997)
Retroalimentación (feedback)
Al estar el cliente integrado en el proyecto, su opinión 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 más importante (Pressman, Ingeniería del software: un enfoque
práctico, 1997)
Coraje o Valentía
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y
programar para hoy y no para mañana. Esto es un esfuerzo para evitar
empantanarse en el diseño y requerir demasiado tiempo y trabajo para
implementar todo lo demás del proyecto (Pressman, Ingeniería del software:
un enfoque práctico, 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 compañeros.
(Pressman, Ingeniería del software: un enfoque práctico, 1997)
Características
Las características fundamentales del método son:
 Desarrollo iterativo e incremental: pequeñas mejoras, unas tras
otras.
 Pruebas unitarias continuas: frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresión.
 Programación en parejas: se recomienda que las tareas de
desarrollo se lleven a cabo por dos personas en un mismo
puesto.
 Frecuente integración del equipo de programación con el cliente o
usuario.
 Corrección de todos los errores antes de añadir nueva
funcionalidad.
 Refactorización del código, es decir, reescribir partes del código
para aumentar su legibilidad y mantenibilidad pero sin modificar
su comportamiento.
 Propiedad del código compartida: en vez de dividir la
responsabilidad en el desarrollo de cada módulo en grupo de
trabajo distinto, este método promueve el que todo el personal
pueda corregir y extender cualquier parte del proyecto.
 Simplicidad en el código: es la mejor manera de que las cosas
funcionen. Cuando todo funcione se podrá añadir funcionalidad si
es necesario (Mann, 2000)



1.5.2. SCRUM
SCRUM es una metodología de desarrollo muy simple que requiere trabajo
duro porque no se basa en el seguimiento de un plan, sino en la adaptación
continua a las circunstancias de la evolución del proyecto.

(Toro López, 2013)
Visión General del Modelo
La adaptación a los cambios es el fuerte de la metodología, esto
porque no existe una etapa de levantamiento de requerimientos sino que se
van construyendo en la ejecución del proyecto, la incertidumbre es un factor
clave por eso se está preparado para asumir cualquier cambio, eliminando
los obstáculos de los proyectos.

(Toro López, 2013)
Roles
 Product Owner (Dueño 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 obstáculos que impiden que el equipo alcance
el objetivo.
- No es el líder del equipo, sino que actúa como una
protección 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 (diseñador,
desarrollador, etc.)
Ventajas
 Es fácil de aprender.
 Requiere muy poco esfuerzo para comenzarse a utilizar.
 Permite abarcar proyectos donde los requisitos de negocio están
incompletos.
 Permite el desarrollo, testeo y correcciones rápido.
 Mediante las reuniones diarias se ven claramente los avances y
problemas.
 Como toda metodología á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 pedirán
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 pequeños y ágiles.
 Se requieren miembros del equipo experimentados.
 Solo funciona cuando el Scrum Manager confía en su equipo.
 Que un miembro abandone el equipo durante el desarrollo puede
conllevar grandes problemas(Pressman, Ingeniería del software: un
enfoque práctico, 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). Programación Orientada a Aspectos: Análisis del Paradigma . Buenos
Aires-Argentina .
Ernest Teniente López, D. C. (2003). Especificación de sistemas software en UML. Barcelona:
Ediciones Universidad Politécnica de Catalunya SL.
Fernando Alonso, L. M. (2005). Introducción a la Ingeniería 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). Ingeniería Concurrente. Productivity Press, Ed. TGP-Hoshin.
Humphrey, W. S. (1997). Introduction to the Personal Software Process. Míchigan: 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). Ingeniería de Software. España.
MOSQUEIRA, E. (2003). PRINCIPIOS DE ANALISIS INFORMATICO. MADRID- ESPAÑA: 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). Ingeniería del software: un enfoque práctico.
Pressman, R. S. (1997). Ingeniería del software: un enfoque práctico. España.
Pressman, R. S. (2005). Ingenieria del Software. Un enfoque practico.
PRESSMAN, R. S. (2010). Ingeniería del Software. Un enfoque prático. México: 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 Práctico. Distrito Federal -
Mexico: Mc Graw Hill.
Rumbaugh, J. (2005). UML - pasos y patrones. New Yoirk: iberoamericana.
Senn, J. A. (s.f.). Analisis y diseño de Sistemas de informacion. Mexico: McGraw.
senn, j. (s.f.). analisis y diseños de sistemas de informacion.
Serna, E. M. (2010). Métodos formales e Ingeniería de Software. Revista Virtual Universidad
Católica, 1-26.
SOMMERVILLE, I. (2005). Ingenieria del Software. Madrid: PEARSON EDUCACIÓN, S.A.
Sommerville, I. (2005). INGENIERÍA DEL SOFTWARE, Séptima Edición. Madrid(España): PEARSON
EDUCACIÓN S.A.
Sommerville, I. (2006). Ingeniería 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 López, F. (2013). Administración de proyectos de informática. 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 Specifier’s Introduction to Formal Methods. Pittsburgh: Carnegie Mellon
University.