Apunte (Metodologias Avanzadas)

APUNTE METODOLOGÍAS AVANZADAS
Apunte Metodologías Avanzadas

Bibliografía
 Ingeniería de Software, de Ian Sommerville.
 Ingeniería de Software – Un enfoque práctico, de Roger S. Pressman
Definición de software
Se pueden encontrar varias definiciones del software:
 Serie de instrucciones (programas de cómputo) que cuando se ejecutan proporcionan

las características, función y desempeño buscados.
 Estructuras de datos que permiten que los programas manipulen en forma adecuada
la información.
 Conjuntos de información descriptiva tanto en papel como en formas virtuales que
describen la operación y uso de los programas.
La naturaleza del software

El software tiene una visión dual, se lo puede ver como:
 Producto: porque brinda el potencial de computo incorporado en el hardware de

computo o en redes de computadoras.
 Vehículo para entregar un producto: porque actúa como la base para el control de la
computadora (sistemas operativos), para la comunicación de información (redes) y
para creación y control de otros programas (herramientas o ambientes de software).
El software transforma los datos de modo que puedan ser más útiles en un contexto local y a su
vez, da mecanismos para distribuirla.
Preocupaciones sobre el software

Surgieron varias preocupaciones sobre el software, como el tiempo y el costo de desarrollo, la
detección de errores, el mantenimiento de programas ya existentes (debido al alto costo de
invertir en programas nuevos), o las dificultades para medir el avance mientras se desarrolla y
mantiene el software.
Estas preocupaciones llevaron a la industria en una situación de crisis, la llamada “crisis del
software”, lo cual dio lugar a la adopción de la ingeniería de software. En esta materia nos
enfocamos en las metodologías de esta ingeniería.
Características del software

 El software se desarrolla o modifica con intelecto, no se manufactura en el sentido
clásico, es decir, el producto del software no se puede “ver” como cualquier otro
producto físico resultado de otra ingeniería, son construcciones enteramente
conceptuales que se plasman en código.
 El software tampoco se “desgasta” por su uso como un producto físico, si no que se
deteriora en el paso del tiempo como consecuencia del cambio en el ambiente, es decir,
por los constantes cambios que se le hacen al software debido a nuevas necesidades.
CHIGAL, LAUTARO 1
Esta curva se puede contrastar con la curva de desgaste del hardware, que presenta una
alta tasa de fallas en su infancia que luego se corrigen, pero que con el tiempo y la
deterioración de los componentes físicos (debido a la suciedad, el abuso, o las
temperaturas extremas, por ejemplo), se comienza a desgastar.
De cualquier manera, si bien el software no se “desgasta”, si se deteriora debido a los

numerosos cambios que se realizan sobre él, lo que normalmente genera nuevos
errores que deben ser corregidos, y mientras estos son corregidos, suelen surgir nuevas
necesidades que fuerzan al software a cambiar nuevamente.
 Además, la mayor parte del software se construye para un uso individualizado, lo cual
dificulta la búsqueda de alternativas si se requiere cambiar el software. Si bien existe
software que es altamente reutilizable, un sistema grande incorpora muchos de éstos,
haciendo que su implementación sea mucho más específica.
El proceso del software

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a crearse
algún producto del trabajo. También se lo conoce como una metodología.
 Una actividad busca lograr un objetivo amplio independientemente del dominio, como
por ejemplo el análisis, que es una actividad obligatoria, pero se puede realizar de varias
maneras.
 Una acción es un conjunto de tareas que producen un producto de trabajo, están dentro
de las actividades, como, por ejemplo, el modelado de los casos de uso.
 Dentro de las actividades hay tareas que se centran en un objetivo pequeño, pero bien
definido, como la realización de una prueba unitaria.
CHIGAL, LAUTARO 2
En el contexto de la ingeniería de software, un proceso no es una prescripción rígida de cómo

elaborar software. Por el contrario, es un enfoque adaptable que permite que el equipo de
software busque y elija el conjunto apropiado de acciones y tareas para el trabajo. Se busca
siempre entregar el software en forma oportuna y con calidad suficiente para satisfacer a
quienes patrocinaron su creación y a aquellos que lo usarán.
Un modelo general de proceso

Un modelo de proceso es una representación simplificada de los procesos y definen un grupo
de actividades estructurales que sean aplicables a todos los proyectos del software.
Un modelo general, que contemplan la mayoría de los modelos de proceso, es:
 Comunicación: importante para entender los objetivos de los participantes respecto

del proyecto, para determinar los requisitos a cumplir.
 Planificación: define el trabajo de los ingenieros al describir tareas, riesgos, recursos
requeridos, etc. Esta planificación estará en base a la metodología utilizada.
 Modelado: se generan modelos para entender mejor los requerimientos del software y
el diseño correspondiente.
 Construcción: combina la generación del código y las pruebas que se requieran.
 Despliegue: el software se entrega al consumidor que lo evalúa y da retroalimentación
(mantenimiento).
Estas cinco actividades estructurales genéricas se usan durante el desarrollo de programas

pequeños y sencillos, en la creación de aplicaciones web grandes y en la ingeniería de sistemas
enormes y complejos basados en computadoras. Los detalles del proceso de software serán
distintos en cada caso, pero las actividades estructurales son las mismas.
Para muchos proyectos de software, las actividades estructurales se aplican en forma iterativa
a medida que avanza el proyecto. Es decir, se ejecutan a través de cierto número de repeticiones
del proyecto. Cada iteración produce un incremento del software que da a los participantes un
subconjunto de características y funcionalidad generales del software. Conforme se produce
cada incremento, el software se hace más y más completo.
Actividades sombrilla
Las actividades estructurales del proceso de ingeniería de software son complementadas por
cierto número de actividades sombrilla. Estas se aplican a lo largo de un proyecto de software
y ayudan al equipo que lo lleva a cabo a administrar y controlar el avance, la calidad, el cambio
y el riesgo. Son las siguientes:
 Seguimiento y control del proyecto de software: permite que el equipo evalúe el progreso
comparándolo con el plan del proyecto y tome cualquier acción necesaria para
apegarse a la programación de actividades.
 Administración del riesgo: evalúa los riesgos que puedan afectar el resultado del
proyecto o la calidad del producto.
 Aseguramiento de la calidad del software: define y ejecuta las actividades requeridas
para garantizar la calidad del software.
 Revisiones técnicas: evalúa los productos del trabajo de la ingeniería de software a fin
de descubrir y eliminar errores antes de que se propaguen a la siguiente actividad.
CHIGAL, LAUTARO 3
 Medición: define y reúne mediciones del proceso, proyecto y producto para ayudar al
equipo a entregar el software que satisfaga las necesidades de los participantes.
 Administración de la configuración del software: administra los efectos del cambio a lo
largo del proceso del software.
 Administración de la reutilización: define criterios para volver a usar el producto del
trabajo y establece mecanismos para obtener componentes reutilizables.
 Preparación y producción del producto del trabajo: agrupa las actividades requeridas para
crear productos del trabajo, tales como modelos, documentos, registros, formatos y
listas.
Modelos de proceso tradicionales

La elaboración de software de computadora es un proceso reiterativo de aprendizaje social, y
el resultado, el “capital de software”, es la reunión de conocimiento recabado, depurado y
organizado a medida que se realiza el proceso.
Se define proceso del software como una estructura para las actividades, acciones y tareas que
se requieren a fin de construir software de alta calidad.
Un modelo general de proceso

Anteriormente se definió un proceso como la colección de actividades de trabajo, acciones y
tareas que se realizan cuando va a crearse algún producto terminado. Cada una de las
actividades, acciones y tareas se encuentra dentro de una estructura o modelo que define su
relación tanto con el proceso como entre sí.
CHIGAL, LAUTARO 4
Flujo de proceso
Como se dijo antes, una estructura general para la ingeniería de software define cinco
actividades estructurales. Además, a lo largo de todo el proceso se aplica un conjunto de
actividades sombrilla.
Un aspecto importante dentro del proceso del software es el flujo del proceso que describe la
manera en que están organizadas las actividades estructurales y las acciones y tareas que
ocurren dentro de cada una con respecto de la secuencia y el tiempo.
Un flujo de proceso lineal ejecuta cada una de las cinco actividades estructurales en secuencia,
comenzando por la comunicación y terminando con el despliegue.
Un flujo de proceso iterativo repite una o más de las actividades antes de pasar a la siguiente.
Un flujo de proceso evolutivo realiza las actividades en forma “circular”. A través de las cinco
actividades, cada circuito lleva a una versión más completa del software.
Un flujo de proceso paralelo ejecuta una o más actividades en paralelo con otras.
CHIGAL, LAUTARO 5
Modelos de proceso
Modelo de cascada
El modelo de la cascada sugiere un enfoque sistemático y secuencial para el desarrollo del
software, que comienza con la especificación de los requerimientos por parte del cliente y
avanza a través de la planeación, modelado, construcción y despliegue, para concluir con el
apoyo del software terminado.
Se le llama así debido a que se divide en varias etapas, en las cuales la salida de una es una
entrada de la siguiente etapa. Esto conlleva varios problemas en la realidad, debido a que en
ciertas fases se puede llegar a tener que iniciar todo el proceso desde el principio. Cuanto más
tarde se detecta un error, mayor será el costo de repararlo. Además, se suele llegar a ciertos
estados de bloqueo, en donde una actividad no puede empezar sin que termine la anterior, lo
cual es una pérdida substancial de tiempo. Esto también implica que el cliente no podrá ver una
versión funcional del sistema en mucho tiempo, por lo que tiene que ser paciente.
Modelos de proceso incremental

El modelo de proceso incremental se centra en que cada incremento se entrega un producto
que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero
proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación.
Es similar al modelo de cascada, pero con la diferencia que se subdivide en partes que se
desarrollan en paralelo, es decir, concurrentemente. El producto de cada “mini-cascada” se
acopla a los productos anteriores. Esto además se planea de forma que se pueda administrar
los riesgos técnicos.
CHIGAL, LAUTARO 6
Modelos de proceso evolutivo

El software evoluciona en el tiempo. Es frecuente que los requerimientos cambien conforme
avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria rectilínea hacia el
producto final; los plazos apretados del mercado hacen que sea imposible la terminación de un
software perfecto, pero debe lanzarse una versión limitada a fin de aliviar la presión de la
competencia o del negocio. En estas situaciones se necesita un modelo de proceso diseñado
para adaptarse a un producto que evoluciona con el tiempo.
Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten
desarrollar versiones cada vez más completas del software.
Prototipado
El prototipado no es una metodología en sí misma, sino una técnica complementaria.
1. Se reúne con otros participantes para definir los objetivos generales del software.
2. Identifica los requerimientos que conozca y detecta las áreas en las que es
imprescindible una mayor definición.
3. Se planea rápidamente una iteración para hacer el prototipo y se lleva a cabo el
modelado (en forma de “diseño rápido”). Éste se centra en la representación de
aquellos aspectos del software que serán visibles para los usuarios finales.
4. El diseño rápido lleva a la construcción de un prototipo que es evaluado por los
participantes que dan retroalimentación para mejorar los requerimientos.
El prototipado sirve para disminuir la brecha entre la expectativa del cliente y el desarrollo del
software, pero no son parte del software en sí.
El modelo espiral
El modelo espiral es un modelo evolutivo del proceso del software y se acopla con la naturaleza
iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada.
Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas.
Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las
CHIGAL, LAUTARO 7
iteraciones posteriores se producen versiones cada vez más completas del sistema cuya
ingeniería se está haciendo.
El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo,

que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas
intensivos en software. Tiene dos características distintivas principales. La primera es el
enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su
implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos
de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones
factibles y mutuamente satisfactorias.
El proceso unificado
El proceso unificado es un marco de desarrollo de software iterativo e incremental. Trata de
reunir los mejores rasgos y características de los procesos de software en una única
metodología. Orientada a grandes proyectos.
Sus características principales son:
 Es manejado por casos de uso. Se parte desde los casos de uso ya que sirven para
capturar los requerimientos del sistema, y no sólo eso, estos también se mantienen
como guía a seguir durante casi todo el ciclo de vida.
 Centrado en la arquitectura, es decir, la estructura del sistema en sí (si está distribuido,
centralizado, si utiliza Java con algún framework, etc.).
 Iterativo e incremental. El ciclo de vida se divide en fases, y cada fase está dividida en
iteraciones.
Fases del proceso unificado

El proceso unificado relaciona las actividades generales del proceso de desarrollo en distintas
“fases”.
La fase de concepción agrupa actividades tanto de comunicación con el cliente como de

planeación. Al colaborar con los participantes, se identifican los requerimientos del negocio, se
propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza
iterativa e incremental del proyecto. Los requerimientos fundamentales del negocio se
CHIGAL, LAUTARO 8
describen por medio de un conjunto de casos de uso preliminares que detallan las
características y funciones que desea cada clase principal de usuarios.
La fase de elaboración incluye las actividades de comunicación y modelado del modelo general
del proceso. Esto mejora y amplía los casos de uso preliminares desarrollados y aumenta la
representación de la arquitectura para incluir cinco puntos de vista distintos del software: los
modelos del caso de uso, de requerimientos, del diseño, de la implementación y del despliegue.
La fase de construcción es idéntica a la actividad de construcción definida para el proceso

general del software. Con el uso del modelo de arquitectura como entrada, la fase de
construcción desarrolla o adquiere los componentes del software que harán que cada caso de
uso sea operativo para los usuarios finales. Para lograrlo, se completan los modelos de
requerimientos y diseño que se comenzaron durante la fase de elaboración, a fin de que reflejen
la versión final del incremento de software, se plasman en código, y se realizan pruebas
unitarias para cada uno con los casos de uso como base.
La fase de transición incluye la entrega y parte de la retroalimentación de las actividades

generales. Se da el software a los usuarios finales para las pruebas beta, quienes reportan tanto
los defectos como los cambios necesarios. Además, se genera la documentación necesaria para
el uso del sistema (manuales, instrucciones de instalación, etc.).
La fase de producción coincide con la actividad de despliegue del proceso general. Durante
esta fase, se vigila el uso que se da al software, se brinda apoyo para el ambiente de operación
(infraestructura) y se reportan defectos y solicitudes de cambio para su evaluación.
Es probable que al mismo tiempo que se llevan a cabo las fases de construcción, transición y
producción, comience el trabajo sobre el siguiente incremento del software. Esto significa que
las cinco fases del PU no ocurren en secuencia, sino que concurren en forma escalonada.
Disciplinas
Las disciplinas son un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un
área específica dentro del proyecto total. Las más importantes son: requerimientos, análisis,
diseño, codificación y prueba.
CHIGAL, LAUTARO 9
Cada disciplina está asociada con un conjunto de modelos que desarrollan, y estos son los
resultados de cada disciplina (requerimientos: modelo de casos de uso, por ejemplo). Estos
modelos están compuestos por artefactos.
Desarrollo rápido de software

El desarrollo y entrega rápida son los requerimientos fundamentales de los sistemas de
software, de hecho, muchas empresas están dispuestas a negociar la calidad del software y el
compromiso con los requerimientos, para lograr con mayor celeridad la implementación que
necesitan del software. Los negocios operan con requerimientos que cambian rápidamente y
es imposible obtener un conjunto estable de requerimientos de software, por lo que éste se ve
obligado a evolucionar rápidamente.
Para poder resolver este problema, recurrimos al desarrollo rápido de software. La

especificación, el diseño, y la implementación están entrelazadas. Los sistemas se desarrollan
como series de versiones (que los stakeholders evalúan) y las interfaces se desarrollan
utilizando un IDE y otras herramientas gráficas.
Características
Los procesos de desarrollo del software rápido se diseñan para producir rápidamente un
software útil. El software no se desarrolla como una sola unidad, sino como una serie de
incrementos, y cada uno de ellos incluye una nueva funcionalidad del sistema. Aun cuando
existen muchos enfoques para el desarrollo de software rápido, comparten algunas
características fundamentales:
 Los procesos de especificación, diseño e implementación están entrelazados. No existe

una especificación detallada del sistema, y la documentación del diseño se minimiza o
es generada automáticamente por el entorno de programación que se para
implementar el sistema. El documento de requerimientos del usuario define sólo las
características más importantes del sistema.
 El sistema se desarrolla en diferentes versiones. Los usuarios finales y otros
colaboradores del sistema intervienen en la especificación y evaluación de cada
CHIGAL, LAUTARO 10
versión. Ellos podrían proponer cambios al software y nuevos requerimientos que se

implementen en una versión posterior del sistema.
 Las interfaces de usuario del sistema se desarrollan usando con frecuencia un sistema de
elaboración interactivo, que permita que el diseño de la interfaz se cree rápidamente en
cuanto se dibujan y colocan iconos en la interfaz. En tal situación, el sistema puede
generar una interfaz basada en la Web para un navegador o una interfaz para una
plataforma específica.
Metodologías ágiles
La insatisfacción con los gastos involucrados en los modelos de diseño de software originales
llevó a la creación de los métodos ágiles. Estos métodos:
 Se centran en el código en lugar del diseño.

 Se basan en un enfoque iterativo e incremental.
 Están destinados a entregar software rápidamente y evolucionar de la misma manera.
Los métodos ágiles se apoyan universalmente en el enfoque incremental para la especificación,

el desarrollo y la entrega del software. Son más adecuados para el diseño de aplicaciones en
que los requerimientos del sistema cambian, por lo general, rápidamente durante el proceso de
desarrollo. Tienen la intención de entregar con prontitud el software operativo a los clientes,
quienes entonces propondrán requerimientos nuevos y variados para incluir en posteriores
iteraciones del sistema. Se dirigen a simplificar el proceso burocrático al evitar trabajo con valor
dudoso a largo plazo, y a eliminar documentación que quizá nunca se emplee.
La filosofía detrás de los métodos ágiles se refleja en el manifiesto ágil, que acordaron muchos
de los desarrolladores líderes de estos métodos. Este manifiesto afirma:
CHIGAL, LAUTARO 11
Principios de la agilidad
Aplicabilidad
Las metodologías ágiles no son para todos, pero podemos identificar situaciones en las que
pueden servir:
 Desarrollo de software pequeño o mediano.

 Desarrollo de sistemas personalizados dentro de una organización, donde el cliente
tiene un compromiso claro para involucrarse en el proceso.
Debido a su enfoque en equipos pequeños y estrechamente integrados, existen problemas para

escalar métodos ágiles a sistemas grandes.
Problemas
En la práctica, los principios que subyacen a los métodos ágiles son a veces difíciles de cumplir:
 Puede ser difícil mantener el interés de los clientes que participan en el proceso.
 Los miembros del equipo pueden ser inadecuados para la intensa participación que
caracteriza a los métodos ágiles.
 La priorización de cambios puede ser difícil cuando hay múltiples partes interesadas, es
decir, varios stakeholders con opiniones diferentes.
 Mantener la simplicidad requiere trabajo extra. Bajo la presión de fechas de entrega, es
posible que no haya tiempo para realizar las simplificaciones deseables al sistema.
 Muchas organizaciones pasan años cambiando su cultura, de tal modo que los procesos
se definan y continúen. Para ellas, resulta difícil moverse hacia un modelo de trabajo
donde los procesos sean informales y estén definidos por equipos de desarrollo.
Otro problema ocurre cuando el cliente acude a una organización externa para el desarrollo del
sistema. Por lo general, el documento de requerimientos del software forma parte del contrato
entre el cliente y el proveedor. Como la especificación incremental es inherente en los métodos
ágiles, quizá sea difícil elaborar contratos para este tipo de desarrollo.
CHIGAL, LAUTARO 12
El mantenimiento
Una enorme cantidad de esfuerzo en ingeniería de software se usa en el mantenimiento y la
evolución de los sistemas de software existentes, por lo que las organizaciones gastan más en
mantener el software existente que el desarrollo de software nuevo debido a sus altos costos.
Debido a esto, los métodos ágiles tienen que respaldar el mantenimiento y el desarrollo
original.
Se presentan entonces dos preguntas que deberían considerarse junto con los métodos y el
mantenimiento ágiles:
 ¿Los sistemas que se desarrollan usando un enfoque ágil se mantienen, a pesar del énfasis
en el proceso de desarrollo de minimizar la documentación formal?
 ¿Los métodos ágiles pueden usarse con efectividad para evolucionar un sistema como
respuesta a requerimientos de cambio por parte del cliente?
Se estima que la documentación formal describe el sistema y, por lo tanto, facilita la

comprensión a quienes cambian el sistema. Sin embargo, en la práctica, con frecuencia la
documentación formal no se conserva actualizada y, por ende, no refleja con precisión el código
del programa. Por esta razón, los apasionados de los métodos ágiles argumentan que escribir
esta documentación es una pérdida de tiempo y que la clave para implementar software
mantenible es producir un código legible de alta calidad.
Desarrollo planificado y desarrollo ágil

 Desarrollo impulsado por un plan:
o Etapas de desarrollo separadas con resultados que se producirán en cada una
de estas etapas planificadas por adelantado.
o No necesariamente representa un modelo de cascada: es posible un desarrollo
incremental.
o La iteración ocurre dentro de las actividades.
 Desarrollo ágil:
o La especificación, el diseño, la implementación y las pruebas están
entrelazadas y los resultados del proceso de desarrollo se deciden a través de
un proceso de negociación durante el proceso de desarrollo del software.
CHIGAL, LAUTARO 13
Cuestiones técnicas, humanas y organizativas

La mayoría de los proyectos incluyen elementos de procesos ágiles y basados en planes. Para
decidir sobre el equilibrio entre estos dos, se deben responder algunas preguntas técnicas,
humanas y organizacionales:
 ¿Es importante tener una especificación y un diseño muy detallados antes de pasar a la
implementación? Si es así, probablemente conviene un enfoque planificado.
 ¿Es una estrategia de entrega incremental, donde se entrega el software a los clientes y
obtiene una respuesta rápida de ellos? De ser así, es útil un enfoque ágil.
 ¿Qué tan grande es el sistema que se está desarrollando? Los métodos ágiles son más
efectivos cuando el sistema se diseña con un pequeño equipo. Esto sería imposible para
sistemas más grandes que precisan equipos más amplios, en este caso, conviene un
enfoque planificado.
 ¿Qué tipo de sistema se desarrollará? Los sistemas que demandan mucho análisis antes
de la implementación, por lo general, necesitan un diseño bastante detallado para
realizar este análisis. En tales circunstancias, quizá sea mejor un enfoque basado en un
plan.
 ¿Cuál es la expectativa de duración del sistema? Los sistemas con lapsos de vida
prolongados podrían requerir más documentación de diseño, para comunicar al equipo
de apoyo los propósitos originales de los desarrolladores del sistema, y los métodos
ágiles no contemplan tanta documentación.
 ¿Qué tecnologías están disponibles para el soporte del desarrollo del sistema? Los
métodos ágiles se auxilian a menudo de buenas herramientas para seguir la pista de un
diseño en evolución.
 ¿Cómo está organizado el equipo de desarrollo? Si el equipo de desarrollo está
distribuido, o si parte del desarrollo se subcontrata, entonces tal vez se requiera
elaborar documentos de diseño para comunicarse a través de los equipos de desarrollo.
Quizá se necesite planear por adelantado cuáles son.
 ¿Existen aspectos de la cultura organizacional que pueden afectar el desarrollo del
sistema? Las organizaciones de ingeniería tradicionales presentan una cultura de
desarrollo basada en un plan, pues es una norma en ingeniería, y esto requiere de
mucha documentación que los métodos ágiles no plantean.
 ¿Cuán bueno son los diseñadores y programadores en el equipo de desarrollo? Se
argumenta en ocasiones que los métodos ágiles requieren niveles de habilidad
superiores a los enfoques basados en un plan, en que los programadores simplemente
traducen un diseño detallado en un código.
 ¿El sistema está sujeto a regulación externa? Si es así, tal vez se le requerirá
documentación detallada como parte del sistema de seguridad.
Programación extrema
La programación extrema (XP) es probablemente la metodología ágil más difundida. Toma un
enfoque “extremo” al desarrollo iterativo:
 Nuevas versiones pueden ser construidas varias veces por día.

 Los incrementos se despliegan al cliente cada dos semanas.
 Todas las pruebas deben ser ejecutadas para cada construcción y ésta será aceptada
solamente si el test es exitoso.
CHIGAL, LAUTARO 14
XP y los principios ágiles

La programación extrema incluye algunas prácticas, las cuales reflejan los principios de los
métodos ágiles:
 El desarrollo incremental es soportado a través de lanzamientos frecuentes y

pequeños.
 El involucramiento del cliente significa el compromiso a tiempo completo del cliente
con el equipo.
 Personas y no procesos a través de la programación de pares, propiedad colectiva y
procesos que evitan largas horas de trabajos.
 Los cambios son soportados a través de lanzamientos regulares.
 Mantenimiento de la simplicidad a través de una constante refactorización del código.
Ciclo de vida de XP
En la programación extrema, los requerimientos se expresan como escenarios (llamados
historias de usuario), que se implementan directamente como una serie de tareas. Los
programadores trabajan en pares y antes de escribir el código desarrollan pruebas para
cada tarea. Todas las pruebas deben ejecutarse con éxito una vez que el nuevo código se
integre en el sistema. Entre los lanzamientos del sistema existe un breve lapso.
CHIGAL, LAUTARO 15
Prácticas del XP
XP y el cambio
Un precepto fundamental de la ingeniería de software tradicional es que se tiene que diseñar
para cambiar. Esto es, deben anticiparse cambios futuros al software y diseñarlo de manera que
dichos cambios se implementen con facilidad. Sin embargo, la programación extrema descartó
este principio basada en el hecho de que al diseñar para el cambio con frecuencia se desperdicia
esfuerzo. No vale la pena gastar tiempo en adicionar generalidad a un programa para enfrentar
el cambio. Los cambios anticipados casi nunca se materializan y en realidad pueden hacerse
peticiones de cambio diametralmente opuestas. Por lo tanto, el enfoque XP acepta que los
cambios sucederán y cuando éstos ocurran realmente se reorganizará el software.
Modelado de sistemas
El modelado de sistemas es el proceso para desarrollar modelos abstractos de un sistema,
donde cada modelo presenta una visión o perspectiva diferente de dicho sistema. En general,
es un medio para representar el sistema usando algún tipo de notación gráfica, que casi siempre
se basa en notaciones en el Lenguaje de Modelado Unificado (UML).
CHIGAL, LAUTARO 16
Los modelos se usan durante el proceso de ingeniería de requerimientos para ayudar a derivar
los requerimientos de un sistema, durante el proceso de diseño para describir el sistema a los
ingenieros que implementan el sistema, y después de la implementación para documentar la
estructura y la operación del sistema.
Modelos de sistemas actual y nuevo
Es posible desarrollar modelos tanto del sistema existente como del sistema a diseñar:
 Los modelos de un sistema existente se utilizan durante la ingeniería de requerimientos,

ayudan a entender lo que el sistema actual hace y, además, sirven para identificar los
requerimientos del nuevo sistema.
 Los modelos del sistema nuevo se emplean durante la ingeniería de requerimientos para
ayudar a explicar los requerimientos propuestos a otros participantes del sistema
(tantos miembros del equipo de desarrollo y otros stakeholders). Los ingenieros usan
tales modelos para discutir las propuestas de diseño y documentar el sistema para la
implementación.
Perspectivas de un sistema
El aspecto más importante de un modelo del sistema es que deja fuera los detalles. Un modelo
es una abstracción del sistema a estudiar, y no una representación alternativa de dicho sistema.
Una representación de un sistema debe mantener toda la información sobre la entidad a
representar.
Desde diferentes perspectivas, se pueden desarrollar diferentes modelos para representar un

sistema. Por ejemplo:
1. Externa, donde se modelen el contexto o entorno del sistema.

2. Interacción, donde se modele la interacción entre un sistema y su entorno, o entre los
componentes de un sistema.
3. Estructural, donde se modelen la organización de un sistema o la estructura de datos
que procese el sistema.
4. Comportamiento, donde se modele el comportamiento dinámico del sistema y cómo
responde ante los eventos.
Tipos de diagramas UML

La mayoría de los usuarios del UML consideran que cinco tipos de diagrama podrían representar
lo esencial de un sistema.
1. Diagramas de actividad, que muestran las actividades incluidas en un proceso o en el

procesamiento de los datos, es similar a un DFD.
2. Diagramas de casos de uso, que exponen las interacciones entre un sistema y su
entorno, sirve para modelar requerimientos.
3. Diagramas de secuencias, que muestran las interacciones entre los actores y el
sistema, y entre los componentes del sistema.
4. Diagramas de clase, que revelan las clases de objeto en el sistema y las asociaciones
entre estas clases.
5. Diagramas de estado, que explican cómo reaccione el sistema frente a eventos
interno y externos.
CHIGAL, LAUTARO 17
Uso de modelos gráficos

Hay tres formas en que los modelos gráficos se emplean con frecuencia:
1. Como medio para facilitar la discusión sobre un sistema existente o propuesto. Se pueden
utilizar modelos incompletos o incorrectos si el objetivo es servir de base para la
discusión.
2. Como una forma de documentar un sistema existente. Los modelos deben ser
representaciones correctas, pero no necesariamente completos.
3. Como una descripción detallada del sistema que sirve para generar una implementación
del sistema. Los modelos tienen que ser completos y correctos, ya que se usan como la
base para generar el código fuente del sistema.
Modelo de contexto
Los modelos de contexto se utilizan para ilustrar el contexto de operación de un sistema,
mostrando que se encuentra fuera de los límites del sistema. Esto implica trabajar con los
participantes del sistema para determinar cuál funcionalidad se incluirá en el sistema y cuál la
ofrece el entorno del sistema, quizás algunas actividades se beneficien de ser automatizadas y
otras no.
Límites del sistema

En general, los límites del sistema definen que se encuentra dentro y que fuera del sistema,
además, muestran otros sistemas utilizados o dependientes del sistema a desarrollarse. La
posición de los límites del sistema tiene un efecto profundo en los requerimientos del sistema
En algunos casos, la frontera entre un sistema y su entorno es relativamente clara, pero esto no
siempre es así. Los aspectos sociales y organizacionales pueden afectar la decisión de donde
colocar los límites del sistema considerando factores no técnicos como, por ejemplo, colocarlo
de modo que no se deba consultar a un administrador difícil de encontrar. Se puede decir que
definir un límite del sistema es un juicio político, puede incluso haber presiones para desarrollar
limites que incremente la carga de trabajo de diferentes partes de la organización.
Normalmente, producir un modelo arquitectónico simple es el primer paso en esta actividad,

como, por ejemplo, un diagrama de bloques.
Perspectiva de procesos
Los modelos de contexto muestran que el entorno incluye varios sistemas automatizados, pero
no presentan los tipos de relaciones entre los sistemas en el entorno y el sistema que se
especifica. Por consiguiente, los modelos de contexto simples se usan junto con otros modelos,
CHIGAL, LAUTARO 18
como los modelos de proceso empresarial. Éstos describen procesos humanos y automatizados
que se usan en sistemas particulares de software.
Diagramas de actividad UML

La figura debajo es un diagrama de actividad UML. Estos intentan mostrar las actividades que
incluyen un proceso de sistema, así como el flujo de control de una actividad a otra. El inicio de
un proceso se indica con un círculo lleno; el fin, mediante un círculo lleno dentro de otro círculo.
Los rectángulos con esquinas redondeadas representan actividades, esto es, los subprocesos
específicos que hay que realizar.
Las flechas representan el flujo de trabajo de una actividad a otra. Una barra sólida se emplea
para indicar coordinación de actividades. Cuando el flujo de más de una actividad se dirige a
una barra sólida, entonces todas esas actividades deben completarse antes del posible avance.
Cuando el flujo de una barra sólida conduzca a algunas actividades, éstas pueden ejecutarse en
forma paralela.
Modelos de interacción
El modelado de interacción del usuario es importante, pues ayuda a identificar los
requerimientos del usuario. El modelado de la interacción sistema a sistema destaca los
problemas de comunicación que se lleguen a presentar. El modelado de interacción de
componentes ayuda a entender si es probable que una estructura de un sistema propuesto
obtenga el rendimiento y la confiabilidad requeridos por el sistema.
Hay dos enfoques relacionados al modelado de la interacción en UML, los diagramas de caso de
uso y de secuencia.
Modelado de casos de uso

El modelado de casos de uso se utiliza ampliamente para apoyar la adquisición de
requerimientos. Un caso de uso puede tomarse como un simple escenario que describa lo que
espera el usuario de un sistema.
Cada caso de uso representa una tarea discreta que implica interacción externa con un sistema
y brindan un panorama bastante sencillo de una interacción, de modo que se tiene que ofrecer
más detalle de otra manera para entender lo que está implicado. Este detalle puede ser una
CHIGAL, LAUTARO 19
simple descripción textual, o una descripción estructurada en una tabla, o un diagrama de

secuencia.
Diagramas de secuencia
Los diagramas de secuencia en el UML se usan principalmente para modelar las interacciones
entre los actores y los objetos en un sistema, así como las interacciones entre los objetos en sí.
Como sugiere su nombre, muestran la sucesión de interacciones que ocurre durante un caso de
uso particular o una instancia de caso de uso.
A menos que se use diagramas de secuencia para la generación de código o documentación

detallada, en dichos diagramas no es necesario incluir todas las interacciones. Si se desarrolla
modelos iniciales de sistema en el proceso de desarrollo para apoyar la ingeniería de
requerimientos y el diseño de alto nivel, habrá muchas interacciones que dependan de
decisiones de implementación.
Modelos estructurales
Los modelos estructurales de software muestran la organización de un sistema, en términos
de los componentes que constituyen dicho sistema y sus relaciones. Los modelos estructurales
son modelos estáticos, que muestran la estructura del diseño del sistema, o modelos
dinámicos, que revelan la organización del sistema cuando se ejecuta.
Estos diagramas se crean cuando se discute y diseña la arquitectura del sistema.
Diagramas de clase
Los diagramas de clase pueden usarse cuando se desarrolla un modelo de sistema orientado a
objetos para mostrar las clases en un sistema y las asociaciones entre dichas clases. Una clase
de objeto puede considerarse como una definición general de un tipo de objeto de sistema.
Una asociación es un enlace entre clases que indica que existe alguna relación entre estas
clases.
Durante las primeras etapas del proceso de ingeniería del software, los objetos representan
algo en el mundo real, como un paciente, una receta, un médico, etc. Conforme se desarrolla
una implementación, por lo general se necesitan definir los objetos de implementación
adicionales que se usan para dar la funcionalidad requerida del sistema.
Modelos de comportamiento
Los modelos de comportamiento son modelos dinámicos del sistema conforme se ejecutan.
En ellos se muestra lo que sucede o lo que se supone que pasa cuando un sistema responde ante
un estímulo de su entorno. Tales estímulos son de dos tipos:
 Datos. Algunos datos que llegan se procesan por el sistema.

 Eventos. Algunos eventos activan el procesamiento del sistema. Los eventos pueden
tener datos asociados, pero esto no es siempre el caso.
Muchos sistemas empresariales son sistemas de procesamiento de datos que se activan

principalmente por datos. Son controlados por la entrada de datos al sistema con relativamente
poco procesamiento externo de eventos. Su procesamiento incluye una secuencia de acciones
sobre dichos datos y la generación de una salida. En cambio, los sistemas de tiempo real muchas
veces están dirigidos por un evento con procesamiento de datos mínimo.
CHIGAL, LAUTARO 20
Modelado dirigido por datos

Los modelos dirigidos por datos muestran la secuencia de acciones involucradas en el
procesamiento de datos de entrada, así como la generación de una salida asociada. Son
particularmente útiles durante el análisis de requerimientos, pues sirven para mostrar
procesamiento “extremo a extremo” en un sistema.
Los modelos dirigidos por datos están entre los primeros modelos gráficos de software, desde
1978 con la introducción de los diagramas de flujos de datos (DFD), pero UML no soporta estos
diagramas, puesto que originalmente se propusieron y usaron para modelar el procesamiento
de datos.
Sin embargo, como los sistemas dirigidos por datos son tan comunes en los negocios, UML 2.0
introdujo los diagramas de actividad, que son similares a los diagramas de flujo de datos.
Modelado dirigido por eventos

El modelado dirigido por eventos muestra cómo responde un sistema a eventos externos e
internos. Se basa en la suposición de que un sistema tiene un número finito de estados y que
los eventos (estímulos) pueden causar una transición de un estado a otro.
Diagramas de estado UML

UML soporta modelado basado en eventos usando diagramas de estado, que muestran
estados y eventos del sistema que causan transiciones de un estado a otro. No exponen el flujo
de datos dentro del sistema, pero suelen incluir información adicional acerca de los cálculos
realizados en cada estado.
En los diagramas de estado UML, los rectángulos redondeados representan estados del
sistema. Pueden incluir una breve descripción de las acciones que se tomarán en dicho estado.
Las flechas etiquetadas representan estímulos que fuerzan una transición de un estado a otro.
Los estados inicial y final se indican círculos rellenos.
Un problema es que el número de posibles estados se incrementa rápidamente. Por lo tanto,

para modelos de sistemas grandes, se necesita ocultar detalles en los modelos. Una forma de
hacer esto es mediante la noción de un súper-estado que encapsule algunos estados separados.
CHIGAL, LAUTARO 21
Ingeniería dirigida por modelos (MDE)

La ingeniería dirigida por modelos (MDE, por las siglas de Model-Driven Engineering) es
un enfoque al desarrollo de software donde los modelos, y no los programas, son las salidas
principales del proceso de desarrollo. Los programas que se ejecutan en una plataforma
hardware/software se generan automáticamente a partir de los modelos.
Los partidarios de la MDE argumentan que ésta eleva el nivel de abstracción en la ingeniería de
software, pues los ingenieros ya no tienen que preocuparse por detalles del lenguaje de
programación o las especificidades de las plataformas de ejecución.
La MDE tiene sus raíces en la arquitectura dirigida por modelos (MDA, por las siglas de Model-
Driven Architecture). Ambas parecen iguales, pero se considera que la MDE tiene un ámbito más
amplio. La MDA se enfoca en las etapas de diseño e implementación del desarrollo de software,
mientras que la MDE se interesa por todos los aspectos del proceso de ingeniería de software.
Pros y contras
Los principales argumentos a favor y en contra de MDE son:
 En favor de la MDE:
o Permite a los ingenieros pensar sobre sistemas en un nivel de abstracción
elevado, sin ocuparse por los detalles de su implementación.
o Reduce la probabilidad de errores, acelera el diseño y el proceso de
implementación, y permite la creación de modelos de aplicación reutilizables,
independientes de la plataforma de aplicación.
o Las implementaciones de sistema pueden generarse para diferentes
plataformas a partir del mismo modelo.
o Para adaptar el sistema a alguna nueva plataforma, sólo es necesario escribir
un traductor para dicha plataforma.
 En contra de la MDE:
o No siempre sucede que las abstracciones que soporta el modelo sean las
abstracciones correctas para la implementación.
o Los argumentos para independencia de plataforma sólo son válidos para
sistemas grandes de larga duración, donde las plataformas se vuelven
obsoletas durante el tiempo de vida de un sistema.
o La implementación no es el principal problema: ingeniería de requerimientos,
seguridad y confiabilidad, integración con sistemas heredados, y las pruebas
son más significativos.
o Los ahorros logrados por la generación de códigos pueden ser superados por
los costos de desarrollo de traductores para nuevas plataformas.
Arquitectura dirigida por modelos (MDA)

La arquitectura dirigida por modelos es un enfoque orientado a un modelo para el diseño y la
implementación de software, que usa un subconjunto de modelos UML para describir un
sistema. Aquí, se crean modelos a diferentes niveles de abstracción.
CHIGAL, LAUTARO 22
Tipos de modelos
El método de MDA recomienda la producción de tres tipos de modelo de sistema abstracto:
1. Un modelo independiente de computación (CIM) que modela las importantes

abstracciones de dominio usadas en el sistema. En ocasiones, los CIM se llaman
modelos de dominio. Es posible desarrollar varios CIM diferentes, que reflejen distintas
percepciones del sistema.
2. Un modelo independiente de plataforma (PIM) que modele la operación del sistema sin
referencia a su implementación. El PIM se describe usualmente mediante modelos
UML que muestran la estructura estática del sistema y cómo responde a eventos
externos e internos.
3. Modelos específicos de plataforma (PSM) que son transformaciones del modelo
independiente de plataforma con un PSM separado para cada plataforma de
aplicación. En principio, puede haber capas de PSM, y cada una agrega cierto detalle
específico de la plataforma.
Transformaciones de modelos
Las transformaciones entre los modelos planteados pueden definirse y aplicarse
automáticamente con herramientas de software. Esto se ilustra en la figura debajo, que
también muestra un nivel final de transformación automática. Una transformación se aplica al
PSM para generar un código ejecutable que opere en la plataforma de software designada.
Diseño arquitectónico
El diseño arquitectónico se interesa por entender cómo debe organizarse un sistema y
cómo tiene que diseñarse la estructura global del mismo. Es la primera etapa en el proceso de
diseño del software y el enlace crucial entre el diseño y la ingeniería de requerimientos, ya que
identifica los principales componentes estructurales en un sistema y la relación entre ellos. Su
salida consiste en un modelo arquitectónico que describe la forma en que se organiza el sistema
como un conjunto de componentes en comunicación.
CHIGAL, LAUTARO 23
Niveles de abstracción
Las arquitecturas de software se diseñan en dos niveles de abstracción:
1. La arquitectura en pequeño se interesa por la arquitectura de programas individuales.

En este nivel, uno se preocupa por la forma en que el programa individual se separa en
componentes.
2. La arquitectura en grande se interesa por la arquitectura de sistemas empresariales
complejos que incluyen otros sistemas, programas y componentes de programa, que
se distribuyen en distintas computadoras.
Ventajas de una arquitectura explícita

Se pueden identificar tres ventajas de diseñar y documentar de manera explícita la arquitectura
de software:
1. Comunicación con los participantes (stakeholders). La arquitectura es una presentación

de alto nivel del sistema, que puede usarse como un enfoque para la discusión de un
amplio número de participantes.
2. Análisis del sistema. En una etapa temprana en el desarrollo del sistema, aclarar la
arquitectura del sistema requiere cierto análisis. Las decisiones de diseño
arquitectónico tienen un efecto profundo sobre si el sistema puede o no cubrir
requerimientos críticos como rendimiento, fiabilidad y mantenibilidad.
3. Reutilización a gran escala. Un modelo de una arquitectura de sistema es una
descripción corta y manejable de cómo se organiza un sistema y cómo interoperan sus
componentes. Por lo general, la arquitectura del sistema es la misma para sistemas con
requerimientos similares y, por lo tanto, puede soportar reutilización de software a gran
escala.
Representación de arquitecturas mediante diagramas de bloques

Las arquitecturas de sistemas se modelan con frecuencia usando diagramas de bloques
simples. Cada recuadro en el diagrama representa un componente. Los recuadros dentro de
recuadros indican que el componente se dividió en subcomponentes. Las flechas significan que
los datos y/o señales de control pasan de un componente a otro en la dirección de las flechas.
Los diagramas de bloque presentan una imagen de alto nivel de la estructura del sistema e
incluyen fácilmente a individuos de diferentes disciplinas que intervienen en el proceso de
desarrollo del sistema, pero, estos han sido criticados porque carecen de semántica, no
CHIGAL, LAUTARO 24
muestran los tipos de relaciones entre entidades ni las propiedades visibles de las entidades en
la arquitectura.
Decisiones en el diseño arquitectónico

El diseño arquitectónico es un proceso creativo en el cual se diseña una organización del sistema
que cubrirá los requerimientos de éste. Debido a esto, sus actividades dependen del tipo de
sistema que se va a desarrollar, la experiencia del arquitecto del sistema, y los requerimientos
específicos del sistema. Por lo tanto, es útil pensar en el diseño arquitectónico como un
conjunto de decisiones a tomar en vez de una secuencia de actividades:
1. ¿Existe alguna arquitectura de aplicación genérica que actúe como plantilla para el
sistema que se está diseñando?
2. ¿Cómo se distribuirá el sistema?
3. ¿Qué patrones o estilos arquitectónicos pueden usarse?
4. ¿Cuál será el enfoque usado para estructurar el sistema?
5. ¿Cómo se descompondrá el sistema en módulos?
6. ¿Qué estrategia se usará para controlar la operación de los componentes?
7. ¿Cómo se evaluará el diseño arquitectónico?
8. ¿Cómo se documentará la arquitectura del sistema?
Reutilización de arquitectura
Aunque cada sistema de software es único, los sistemas en el mismo dominio de aplicación
tienen normalmente arquitecturas similares que reflejan los conceptos fundamentales del
dominio. Cuando se diseña una arquitectura de sistema, debe decidirse qué tienen en común el
sistema y las clases de aplicación más amplias, con la finalidad de determinar cuánto
conocimiento se puede reutilizar de dichas arquitecturas de aplicación.
La arquitectura de un sistema de software puede basarse en un patrón o un estilo

arquitectónico particular. Un patrón arquitectónico es una descripción de una organización del
sistema, tal como una organización cliente-servidor o una arquitectura por capas. Los patrones
arquitectónicos captan la esencia de una arquitectura que se usó en diferentes sistemas de
software.
Arquitectura y características del sistema

Debido a la estrecha relación entre los requerimientos y la arquitectura de software, el estilo y
la estructura arquitectónicos particulares que se elijan para un sistema dependerán de ciertos
requerimientos:
 Rendimiento. La arquitectura debe diseñarse para localizar operaciones críticas dentro

de un pequeño número de componentes, con todos estos componentes desplegados
en la misma computadora en vez de distribuirlos por la red. Estos componentes deben
ser grandes y no de grano fino.
 Seguridad. Será necesario usar una estructura en capas para la arquitectura, con los
activos más críticos protegidos en las capas más internas, y con un alto nivel de
validación de seguridad aplicado a dichas capas.
 Protección. la arquitectura debe diseñarse de modo que las operaciones relacionadas
con la protección se ubiquen en algún componente individual o en un pequeño número
de componentes.
CHIGAL, LAUTARO 25
 Disponibilidad. La arquitectura tiene que diseñarse para incluir componentes

redundantes de manera que sea posible sustituir y actualizar componentes sin detener
el sistema.
 Mantenibilidad La arquitectura del sistema debe diseñarse usando componentes auto
contenidos de grano fino que puedan cambiarse con facilidad.
Vistas arquitectónicas
Es imposible representar toda la información relevante sobre la arquitectura de un sistema en
un solo modelo arquitectónico, ya que cada uno presenta únicamente una vista o perspectiva
del sistema. Debido a esto, surgen dos cuestiones:
1. ¿Qué vistas o perspectivas son útiles al diseñar y documentar una arquitectura del
sistema?
2. ¿Qué notaciones deben usarse para describir modelos arquitectónicos?
Modelo de vista 4 + 1
El modelo de vista 4 + 1 sugiere que deben existir cuatro vistas arquitectónicas fundamentales,
que se relacionan usando casos de uso o escenarios:
1. Una vista lógica, que indique las abstracciones clave en el sistema como objetos o clases
de objeto.
2. Una vista de proceso, que muestre cómo, en el tiempo de operación, el sistema está
compuesto de procesos en interacción.
3. Una vista de desarrollo, que muestre cómo el software está descompuesto para su
desarrollo.
4. Una vista física, que exponga el hardware del sistema y cómo los componentes de
software se distribuyen a través de los procesadores en el sistema.
5. Otros autores sugieren una vista conceptual (+1), una vista abstracta del sistema que
puede ser la base para descomponer los requerimientos de alto nivel en
especificaciones más detalladas. Se puede relacionar con los casos de uso.
Patrones arquitectónicos
Los patrones arquitectónicos son una forma de presentar, compartir y reutilizar el
conocimiento sobre los sistemas de software. Se pueden considerar como una descripción
abstracta estilizada de buena práctica, que se ensayó y puso a prueba en diferentes sistemas y
entornos.
Estos patrones deben incluir información sobre cuándo es y cuándo no es adecuado usar dicho
patrón, así como sobre las fortalezas y debilidades del patrón.
CHIGAL, LAUTARO 26
Patrón MVC
Su organización se puede representar de la siguiente manera:
Arquitectura en capas
La arquitectura en capas se utiliza para modelar la interfaz de los subsistemas. Organiza el
sistema en un conjunto de capas (o máquinas abstractas), cada una de las cuales proporciona
un conjunto de servicios.
Esta arquitectura soporta el desarrollo incremental de subsistemas en diferentes capas. Cuando

cambia una interfaz de capa, sólo se ve afectada la capa adyacente.
CHIGAL, LAUTARO 27
Un ejemplo de una arquitectura en capas es:
Diseño e implementación
El diseño y la implementación del software es la etapa del proceso de ingeniería de software
en que se desarrolla un sistema de software ejecutable.
Las actividades de diseño e implementación de software son invariablemente entrelazadas. El

diseño de software es una actividad creativa en la que se identifica los componentes de software
y sus relaciones, sobre la base de los requisitos del cliente. La implementación es el proceso de
realización del diseño como un programa.
Desarrollar o comprar
Una de las decisiones de implementación más importantes, que se toman en una etapa
inicial de un proyecto de software, consiste en determinar si debe comprar o diseñar el
software de aplicación. Ahora es posible comprar sistemas comerciales (COTS) que se adapten
y personalicen según los requerimientos de los usuarios, y esto puede ser más barato y más
rápido.
Al desarrollarse de esta forma una aplicación, el proceso de diseño se preocupa sobre cómo
usar las características de configuración de dicho sistema, para entregar los requerimientos del
CHIGAL, LAUTARO 28
mismo. Por lo general, no se desarrollan modelos de diseño del sistema, como los modelos de
los objetos del sistema y sus interacciones.
Un proceso de diseño orientado a objetos

Los procesos de diseño orientados a objetos suponen el desarrollo de una serie de diferentes
modelos de sistemas.
Requieren un gran esfuerzo para el desarrollo y el mantenimiento de estos modelos y, para

sistemas pequeños, esto puede no ser rentable.
Para grandes sistemas desarrollados por diferentes modelos de diseño de grupos son un
mecanismo de comunicación importante.
Etapas del proceso

Para desarrollar un diseño de sistema desde el concepto hasta el diseño detallado
orientado a objetos, hay muchas cuestiones por hacer:
 Comprender y definir el contexto y las interacciones externas con el sistema.

 Diseñar la arquitectura del sistema.
 Identificar los objetos principales en el sistema.
 Desarrollar modelos de diseño.
 Especificar interfaces.
Contexto del sistema y las interacciones

La compresión de las relaciones entre el software que se está diseñando y su entorno externo
es esencial para decidir la manera de proporcionar la funcionalidad requerida del sistema y
como estructurar el sistema para comunicarse con su entorno.
La comprensión del contexto también le permite establecer los límites del sistema, lo cual
ayuda a decidir sobre las características que se implementarán en el sistema que se va a diseñar,
así como sobre las de otros sistemas asociados.
Los modelos de contexto del sistema y los modelos de interacción presentan vistas
complementarias de las relaciones entre un sistema y su entorno:
 Un modelo de contexto del sistema es un modelo estructural, que muestra los otros
sistemas en el entorno del sistema a desarrollar.
 Un modelo de interacción es un modelo dinámico que indica la forma en que el sistema
interactúa con su entorno conforme se utiliza.
El modelo del contexto de un sistema puede representarse mediante asociaciones, las cuales
muestran simplemente que existen algunas relaciones entre las entidades que intervienen en
la asociación. Es posible documentar el entorno del sistema con un simple diagrama de bloques,
que manifieste las entidades en el sistema y sus asociaciones.
Al modelar las interacciones de un sistema con su entorno, se debe usar un enfoque abstracto
que no contenga muchos detalles. Una forma de hacerlo es usar un modelo de caso de uso.
CHIGAL, LAUTARO 29
Diseño arquitectónico
Se identifican los principales componentes que conforman el sistema y sus interacciones, y
luego organizar los componentes utilizando un patrón arquitectónico, como un modelo en
capas o cliente-servidor.
Identificación de la clase objeto

En esta etapa del proceso de diseño, es necesario tener algunas ideas sobre los objetos
esenciales en el sistema que se diseña. Conforme aumente su comprensión del diseño,
corregirá estas ideas de los objetos del sistema. La descripción del caso de uso ayuda a
identificar objetos y operaciones del sistema.
Hay varias propuestas sobre cómo identificar las clases de objetos en los sistemas
orientados a objetos:
 Análisis gramatical.
 Detectar entidades tangibles (cosas).
 Análisis basado en escenarios.
Modelos de diseño
Los modelos de diseño o sistema muestran los objetos o clases de objetos en un sistema.
También indican las asociaciones y relaciones entre tales entidades. Dichos modelos son el
puente entre los requerimientos y la implementación de un sistema. Deben ser abstractos, de
manera que el detalle innecesario no oculte las relaciones entre ellos y los requerimientos del
sistema. Sin embargo, deben incluir suficiente detalle para que los programadores tomen
decisiones de implementación.
En las primeras fases del proceso de diseño, se considera que existen tres modelos que son
útiles particularmente para agregar detalle a los modelos de caso de uso y arquitectónico:
 Modelos de subsistema, que exponen los agrupamientos lógicos de objetos en

subsistemas coherentes. Se representan mediante una forma de diagrama de clase en
el que cada subsistema se muestra como un paquete con objetos encerrados. Los
modelos de subsistema son modelos estáticos (estructurales).
 Modelos de secuencia, que ilustran la secuencia de interacciones de objetos. Se
representan mediante una secuencia UML o un diagrama de colaboración. Los
modelos de secuencia son modelos dinámicos.
 Modelos de máquina de estado, que muestran cómo los objetos individuales cambian su
estado en respuesta a eventos. Se representan en UML a través de diagramas de
estado. Los modelos de máquina de estado son modelos dinámicos.
Especificación de interfaz
Una parte importante de cualquier proceso de diseño es la especificación de las interfaces
entre los componentes en el diseño. Es necesario especificar las interfaces de modo que
los objetos y subsistemas puedan diseñarse en paralelo.
El diseño de interfaz se preocupa por la especificación del detalle de la interfaz hacia

un objeto o un grupo de objetos. Esto significa definir las firmas y la semántica de los servicios
que ofrecerá el objeto o un grupo de objetos. Las interfaces pueden especificarse en el UML con
la misma notación de un diagrama de clase.
CHIGAL, LAUTARO 30

Apunte (Metodologias Avanzadas)

Cargado por

Copyright:

Formatos disponibles

Apunte (Metodologias Avanzadas)

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apunte (Metodologias Avanzadas)

Cargado por

Copyright:

Formatos disponibles

APUNTE METODOLOGÍAS AVANZADAS

Apunte Metodologías Avanzadas

 Serie de instrucciones (programas de cómputo) que cuando se ejecutan proporcionan

La naturaleza del software

 Producto: porque brinda el potencial de computo incorporado en el hardware de

Preocupaciones sobre el software

Características del software

De cualquier manera, si bien el software no se “desgasta”, si se deteriora debido a los

El proceso del software

En el contexto de la ingeniería de software, un proceso no es una prescripción rígida de cómo

Un modelo general de proceso

Un modelo general, que contemplan la mayoría de los modelos de proceso, es:

 Comunicación: importante para entender los objetivos de los participantes respecto

Estas cinco actividades estructurales genéricas se usan durante el desarrollo de programas

Modelos de proceso tradicionales

Un modelo general de proceso

Modelos de proceso incremental

Modelos de proceso evolutivo

El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo,

Sus características principales son:

Fases del proceso unificado

La fase de concepción agrupa actividades tanto de comunicación con el cliente como de

La fase de construcción es idéntica a la actividad de construcción definida para el proceso

La fase de transición incluye la entrega y parte de la retroalimentación de las actividades

Desarrollo rápido de software

Para poder resolver este problema, recurrimos al desarrollo rápido de software. La

 Los procesos de especificación, diseño e implementación están entrelazados. No existe

versión. Ellos podrían proponer cambios al software y nuevos requerimientos que se

 Se centran en el código en lugar del diseño.

Los métodos ágiles se apoyan universalmente en el enfoque incremental para la especificación,

 Desarrollo de software pequeño o mediano.

Debido a su enfoque en equipos pequeños y estrechamente integrados, existen problemas para

Se estima que la documentación formal describe el sistema y, por lo tanto, facilita la

Desarrollo planificado y desarrollo ágil

Cuestiones técnicas, humanas y organizativas

 Nuevas versiones pueden ser construidas varias veces por día.

XP y los principios ágiles

 El desarrollo incremental es soportado a través de lanzamientos frecuentes y

 Los modelos de un sistema existente se utilizan durante la ingeniería de requerimientos,

Desde diferentes perspectivas, se pueden desarrollar diferentes modelos para representar un

1. Externa, donde se modelen el contexto o entorno del sistema.

Tipos de diagramas UML

1. Diagramas de actividad, que muestran las actividades incluidas en un proceso o en el

Uso de modelos gráficos

Límites del sistema

Normalmente, producir un modelo arquitectónico simple es el primer paso en esta actividad,

Diagramas de actividad UML

Modelado de casos de uso

simple descripción textual, o una descripción estructurada en una tabla, o un diagrama de

A menos que se use diagramas de secuencia para la generación de código o documentación

Estos diagramas se crean cuando se discute y diseña la arquitectura del sistema.

 Datos. Algunos datos que llegan se procesan por el sistema.

Muchos sistemas empresariales son sistemas de procesamiento de datos que se activan

Modelado dirigido por datos

Modelado dirigido por eventos

Diagramas de estado UML

Un problema es que el número de posibles estados se incrementa rápidamente. Por lo tanto,

Ingeniería dirigida por modelos (MDE)

Arquitectura dirigida por modelos (MDA)