Idiomas
Páginas
Jurídico
UNIDAD 2Modelos de la ingeniería de Software
Unidad 22.1 MODELO DE CAPACIDAD DE
MADUREZ
INTRODUCCIÓN
El modelo de capacidad y madurez o mejor llamado CMM, CMMI o IMCM, es el modelo de evaluación de procesos de una organización.
Fue creado para los procesos elativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).
EL MODELO CMMI
A partir de Noviembre de 1986 el SEI desarrollo una definición de un modelado de madures, la cual fue publicada en 1987, esto a evolucionado hasta febrero de 1993.
Este modelo establece un conjunto de practicas o procesos clave agrupados en Áreas Clave del proceso (KPA-Key process Área). Para cada área de proceso define un conjunto de practicas que habrán de ser:
EL MODELO CMMI (CONT.)
Definidas en un
procedimiento
documentado
Provistas de los medios y formación necesarios
Ejecutadas de un modo sistemático, universal y uniforme
Medidas Verificadas
EL MODELO CMMI (CONT.)
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.
EL MODELO CMMI (CONT.)
Inicial
•Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.
Repetible
•En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.
Definido
•Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews).
Gestionado
•Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad.
Optimizado
•La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.
EL MODELO CMMI (CONT.)
CMMI es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para procesos eficaces. Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay dos áreas de interés cubiertas por los modelos de CMMI: Desarrollo y Adquisición.
CMMI para el Desarrollo (DEV-CMMI): En él se
tratan procesos de desarrollo de productos
y servicios.
CMMI para la adquisición (ACQ-CMMI): En él se tratan la gestión de la cadena de suministro,
adquisición y contratación externa en los procesos del
gobierno y la industria.
ÁREAS DEL PROCESO CMMI
Análisis de causalidad y solución Configuration Management Decisión de Análisis y Resolución Proyecto Integrado de Gestión Medición y Análisis Innovación organizacional y
Despliegue Definición de procesos
organizacionales Enfoque en procesos
organizacionales Rendimiento de procesos
organizacionales Entrenamiento organizacional
Vigilancia y Control de proyectos Planificación de proyectos Proceso y aseguramiento de
calidad del producto Integración de Producto Gestión de proyectos
Cuantitativos Gestión de requerimientos Requerimientos de Desarrollo Gestión de Riesgos Gestión de Proveedores Solución Validación Verificación
REPRESENTACIONES:
El modelo para ingeniería de sistemas (SE-CMM) establece 6 niveles posibles de capacidad para una de las 18 áreas de proceso implicadas en la ingeniería de sistemas.
No agrupa los procesos en 5 tramos para definir el nivel de madurez de la organización, sino que directamente analiza la capacidad de cada proceso por separado.
Es lo que se denomina un modelo continuo.
NIVELES DE CAPACIDAD DE LOS PROCESOS (REPRESENTACIÓN CONTINUA)
Incompleto: El
proceso no se realiza,
o no se consiguen
sus objetivos.
Ejecutado: El proceso se ejecuta y se logra
su objetivo.
Gestionado: Además
de ejecutarse, el proceso
se planifica,
se revisa y se evalúa
para comprobar que cumple
los requisitos.
Definido: Además de
ser un proceso
gestionado se ajusta a la política
de procesos que existe
en la organización
, alineada con las
directivas de la
empresa.
Cuantitativamente
gestionado: Además de
ser un proceso
definido se controla
utilizando técnicas
cuantitativas.
Optimizarte: Además de
ser un proceso
cuantitativamente
gestionado, de forma
sistemática se revisa y modifica o
cambia para adaptarlo a los objetivos del negocio.
Mejora continua.
DIAGRAMA
COMPONENTES REQUERIDOS
Objetivo genérico: Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad.
Objetivo específico: Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propósito del área de proceso.
COMPONENTES ESPERADOS
Práctica genérica: Una práctica genérica se aplica a cualquier área
de proceso porque puede mejorar el
funcionamiento y el control de cualquier
proceso.
Práctica específica: Una práctica específica es una actividad que se considera importante en
la realización del objetivo específico al cual está asociado.
COMPONENTES INFORMATIVOS
Propósito
Notas introductori
as
Nombres
Tablas de relaciones práctica - objetivo
Prácticas Productos típicos
Sub-prácticas
Ampliaciones de
disciplina
Elaboraciones de prácticas
genéricas
Unidad 22.2 MARCO DE TRABAJO PARA EL
PROCESO
INTRODUCCIÓN
En esta sección es fácil denotar que el marco de trabajo es sobre el cual se trabajara, ya que contiene el conjunto de actividades a realizar, de la cual se desprenden tareas individuales.
PARTES DEL MARCO DE TRABAJO DEL PROCESO
Comunicación: Esta actividad implica una intensa colaboración y comunicación con los clientes, abarcando la
investigación de requisitos y otras
actividades relacionadas.
Planeación: Describe las tareas técnicas que deben
realizarse, los riesgos probables, los recursos que serán requeridos, los productos del
trabajo que han de producirse y un
programa de trabajo.
Modelado: Abarca la creación de modelos que permiten al
desarrollador y al cliente entender
mejor los requisitos del software y el
diseño que lograra satisfacerlos.
Construcción: Combina la
generación del código y la
realización de pruebas
necesarias para descubrir errores
en el código.
Despliegue: El software se
entrega al cliente, quien evalúa el
producto recibido y proporciona información
basada en su evaluación.
PARTES DEL MARCO DE TRABAJO DEL PROCESO (CONT.)
Las actividades anteriores son útiles durante el desarrollo de programas pequeños, la creación de grandes aplicaciones en la red, y en la ingeniería de sistemas basados en computadoras grandes y complejas.
Los detalles del proceso del software serán muy diferentes en cada caso, pero las actividades dentro del marco permanecerán iguales.
ACTIVIDADES SOMBRILLA
Seguimiento y control del proyecto del
software
Gestión del riesgo
Aseguramiento de la
calidad del software
Revisiones técnicas formales
MediciónGestión de la configuración del software
Gestión de la reutilización
Preparación y producción del producto de trabajo
SEGUIMIENTO Y CONTROL DEL PROYECTO DEL SOFTWARE
Permite que el equipo de software evalué el progreso comparándolo con el plan del proyecto y así tomar las acciones necesarias para mantener el programa.
GESTIÓN DEL RIESGO
Evalúa los riesgos que pudieran afectar los resultados del proyecto o la calidad del producto
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
Define y conduce las actividades requeridas para asegurar la calidad del software
REVISIONES TÉCNICAS FORMALES
Evalúa los productos del trabajo de la ingeniería del software en un esfuerzo encaminado a describir y eliminar los errores antes de que estos se propaguen hacia la siguiente acción o actividad
MEDICIÓN
Define y recolecta mediciones del proceso, el proyecto y el producto para ayudar al equipo a entregar software que satisfaga las necesidades del cliente; se puede usar en conjunto con todas las otras actividades del marco de trabajo o actividades sombrilla
GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE
Maneja los efectos del cambio a través del proceso del software
GESTIÓN DE LA REUTILIZACIÓN
Define los criterios para la reutilización de productos del trabajo y establece mecanismos para la creación de componentes reutilizables.
PREPARACIÓN Y PRODUCCIÓN DEL PRODUCTO DE TRABAJO
Abarca las actividades requeridas para crear productos del trabajo como modelos, documentos, registros, formatos y listas.
La aplicación inteligente de cualquier modelo de proceso del software debe reconocer que la
adaptación es esencial para el éxito de esta actividad.
Las actividades sombrilla se aplican en el proceso del software.
Pero los modelos de
proceso difieren de
manera fundamental
en:
El flujo global de actividades y tareas, y las
interdependencias entre las
actividades y las tareas.
El grado en el cual las tareas de
trabajo están definidas dentro
de cada actividad del marco de
trabajo.
El grado en el cual se identifican y se solicitan los
productos de trabajo.
La forma en la que se aplican las
actividades de aseguramiento de
la calidad.
La manera en la que se aplican las
actividades de seguimiento y
control.
El grado general de detalle y el
rigor con el que se describe el
proceso.
El grado en el que los clientes están comprometidos con el proyecto.
El grado de autonomía otorgado al equipo de
proyectos de software.
El grado en el cual están definidos la
organización y las responsabilidades
en el equipo.
Unidad 22.3 MODELOS DE LA INGENIERÍA DEL
SOFTWARE:MODELO DE CASCADA, MODELO DE
PROTOTIPOS,MODELO DE ESPIRAL, MODELO DE PROCESO
UNIFICADO RACIONAL (RUP)
MODELOS DE LA INGENIERÍA DE SOFTWARE
Para el caso de la ingeniería de software los modelos nos ayudan a poder realizar en orden una a una las tareas, esto se logra a través de un ciclo de vida el cual nos ayuda a poder visualizar cualquier evento de forma anticipada y así poder llegar a un fin determinado, lo cual nos dará el producto deseado.
MODELO DE CASCADA
Mas que nada es un modelo que nos provee de lo que seria el control de las fechas de forma ordenada ya que muestra claramente la salida de una actividad y la entrada a la siguiente; también nos sirve a la gente con poca experiencia en el ramo, aunque presenta poca flexibilidad y no poder mostrar todo al cliente de forma anticipada y su impresión es lenta ante lo cual el cliente debe presentar paciencia.
MODELO DE CASCADA
Inicio
Análisis
Diseño
Código
Pruebas
Implementación
MODELO DE PROTOTIPOS
Versión preliminar de un sistema de información
con fines de demostración o
evaluación.
En si es un modelo menos formal ya que en cierta manera se puede
eliminar o se puede mejorar, y claro que es algo rápido pero suele crear falsas ilusiones al usuario con respecto al
tiempo
MODELO DE PROTOTIPOS
Identificación de
Requerimientos
Diseño Rápido
Utilizar el
Prototipo
Para construir
los prototipos
solo se necesita:
Revisar y Mejorar
MODELO EN ESPIRAL
Un modelo que es cíclico en todo sentido ya que se repiten procesos de forma constante, lo cual beneficia ya que así se corrigen errores en el camino aunque tenga de defecto su dificultad y sobre todo el no saber cuando definir los limites y los objetivos.
MODELO EN ESPIRAL
Requerimientos
Análisisde Riesgo
Prototipo
Requerimientosdel Software
Validación deRequerimientos
Plan de DesarrolloPrototipo
Diseño delProducto
Validación delDiseño
Pruebas deIntegración
Prototipo
MODELO DE PROCESO UNIFICADO RACIONAL (RUP).
Es un proceso de desarrollo que forma disciplinadamente la asignación de tareas y responsabilidades.
Se vigila el cumplimiento de los objetivos, gestión de riesgos y restricciones para desarrollaran producto que sea acorde a los requisitos de los clientes y los usuarios.
Proveer un marco de trabajo para gestionar
riesgos.
Configuración y control de cambios
El control de cambios permite mantener la
integridad de todos los artefactos que se
crean en el proceso, así como de mantener
información del proceso evolutivo que
han seguido.
La finalidad de esta actividad es dar
soporte al proyecto con las adecuadas
herramientas, procesos y métodos.
Brinda una especificación de las herramientas que se van a necesitar encada momento, así como definir la instancia concreta del proceso que se va a seguir.
Unidad 22.4 TENDENCIAS MODERNAS DE
MODELOS DE LA INGENIERÍA DEL SOFTWARE
XP (EXTREMA PROGRAMACIÓN)
La XP empieza con cuatro valores: comunicación,
retroalimentación, simplicidad y
coraje.
Construye sobre ellos una docena de prácticas que los proyectos XP deben seguir.
Muchas de estas prácticas son
técnicas antiguas, tratadas y
probadas, aunque a menudo
olvidadas por muchos,
incluyendo la mayoría de los
procesos planeados.
Además de resucitar estas
técnicas, la XP las teje en un todo sinérgico dónde
cada una refuerza a las demás.
XP (EXTREMA PROGRAMACIÓN) [CONT.]
En esta plataforma XP construye un proceso de diseño evolutivo que se basa en refractora un sistema simple en cada iteración.
Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras.
El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina con la adaptabilidad de una manera que indiscutiblemente la hace la más desarrollada entre todas las metodologías adaptables.
XP (EXTREMA PROGRAMACIÓN) [CONT.]
XP ha desarrollado un liderazgo amplio,
muchos de ellos provenientes del
proyecto fundamental c3.
Como resultado hay muchas fuentes
para más información.
Kent beck escribió extreme
programming explained, el
manifiesto clave de la xp que explica las razones detrás de la
metodología y bastante explicación
como para que la gente pueda saber si se interesan en
seguirla.
En el último par de años ha habido una epidemia de libros
sobre xp brillantemente coloreados la
mayoría de los cuales son bastante
similares en que describen el proceso
entero desde el punto de vista de varios seguidores
tempranos.
LA FAMILIA DE CRISTAL DE COCKBURN
Es una familia porque él cree que los tipos
diferentes de proyectos requieren tipos diferentes de
metodologías.
Él mira esta variación a lo largo de dos ejes:
el número de personas en el proyecto, y las
consecuencias de los errores.
Cada metodología encaja en una parte diferente de la reja,
de modo que para un proyecto de 40
personas que puede perder dinero
discrecionalmente tiene una
metodología diferente a la de un
proyecto vital de seis personas.
Los cristales comparten con la XP una orientación humana, pero esta
centralización en la gente se hace de una manera
diferente.
Alistair considera que las personas encuentran difícil
seguir un proceso disciplinado, así que más que seguir la alta
disciplina de la XP, Alistair explora la metodología menos
disciplinada que aun podría tener éxito, intercambiando
conscientemente productividad por facilidad de ejecución.
Él considera que aunque cristal es menos productivo
que la XP, más personas serán capaces de seguirlo.
Alistair también pone mucho peso en las revisiones al
final de la iteración,
animando al proceso a ser
automejorante.
Su aserción es que el
desarrollo iterativo está
para encontrar los problemas temprano, y
entonces permitir
corregirlos.
Esto pone más énfasis en la
gente supervisando su
proceso y afinándolo conforme
desarrollan.
CÓDIGO ABIERTO
Después de todo el código abierto es un estilo de software, no
tanto un proceso.
Sin embargo hay una manera
definida de hacer las cosas
haciendo en la comunidad de
código abierto, y mucho de su
acercamiento es tan aplicable a
los proyectos de código cerrado como a los de
código abierto.
En particular su proceso se engrana a equipos
físicamente distribuidos, lo
qué es importante porque la
mayoría de los procesos
adaptables exigen equipos
locales.
El mantenedor así es responsable de coordinar los parches y mantener la cohesión en el diseño del software.
Normalmente estos cambios son hechos en forma de archivos de parches que hacen este proceso más fácil.
La diferencia importante es que estas otras personas necesitan enviar su cambio al mantenedor que entonces lo revisa y lo aplica a la base del código.
Sin embargo otras personas pueden hacer cambios a la base del código.
Un mantenedor es la única persona a la que se le permite integrar un cambio en el almacén de código fuente.
La mayoría de los proyectos de código abierto tienen uno o más mantenedores.
Proyectos diferentes manejan el papel del mantenedor de diferentes maneras.
Algunos tienen un mantenedor para el proyecto entero, algunos lo dividen en módulos y tiene un mantenedor por módulo, algunos rolan el mantenedor, algunos tienen múltiples mantenedores sobre el mismo código, otros tienen una combinación de estas ideas.
La mayor parte de la gente de código abierto son de tiempo parcial, así que hay una duda en qué tan bien se coordina un equipo así para un proyecto de tiempo completo.
Un rasgo particular del desarrollo de
código abierto es que la
depuración es altamente
paralelizable.
Muchas personas pueden
involucrarse en el
depurado.
Cuando encuentran
un bug pueden enviar
el parche al mantenedor.
Esto es un buen papel para los no
mantenedores ya que la
mayor parte del tiempo se
gasta en encontrar
bugs.
También es bueno para gente sin mucha
destreza en programación.
El proceso para el código abierto aun no se escribe bien. La referencia más famosa es el artículo de Eric Raymond the catedral and the bazar, que aunque es una descripción excelente también es bastante informal.
El libro de karl fogel sobre el almacén de código cvs también contiene varios buenos capítulos sobre el proceso de código abierto que incluso serían interesantes para aquéllos que no quieren hacer una actualización cvs.
EL DESARROLLO DE SOFTWARE ADAPTABLE DE HIGHSMITH
No proporciona el tipo de prácticas detalladas como lo hace la XP, pero proporciona la base fundamental de por qué el desarrollo adaptable es importante y las consecuencias a los más profundos niveles de la organización y la gerencia.
Su reciente libro se enfoca en la naturaleza adaptable de las nuevas metodologías, con un énfasis particular en aplicar las ideas que se originaron en el mundo de los
sistemas complejos adaptables (normalmente conocida como teoría del caos.)
Él las desarrolló, instaló, enseñó, y concluyó que son profundamente defectuosas: particularmente para los negocios modernos.
Jim Highsmith ha pasado muchos años trabajando con metodologías predictivas.
En el corazón del ASD hay tres fases solapadas, no lineales: especulación, colaboración, y aprendizaje.
Ve la planificación como una paradoja en un ambiente adaptable, ya que los resultados son naturalmente imprevisibles. En la planificación tradicional, las desviaciones del plan son errores que deben corregirse. En un el ambiente adaptable, sin embargo, las desviaciones nos guían hacia la solución correcta.
En ambientes predictivos, el aprendizaje se desalienta a menudo. Las cosas se ponen de antemano y entonces se sigue ese diseño.
En un ambiente adaptable, aprender desafía a todos - desarrolladores y sus clientes - a examinar sus asunciones y usar los resultados de cada ciclo de desarrollo para adaptar el siguiente.
Se enfoca directamente en fomentar las partes difíciles del desarrollo adaptable, en particular cómo fomentar la colaboración y el aprendizaje dentro del proyecto (XP, FDD y cristal).
Como tal su libro ayuda a dar ideas para fomentar estas áreas "suaves" que hacen un buen complemento a los acercamientos basados en una práctica
SCRUM
Scrum ha estado durante algún tiempo en los círculos orientados a objetos, aunque confesaré que yo no estoy muy al tanto de su
historia o desarrollo. De nuevo se enfoca en el hecho de que
procesos definidos y repetibles sólo funcionan para atacar
problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles.
Scrum divide un proyecto en iteraciones (que ellos llaman
carreras cortas) de 30 días. Antes de que comience una carrera se define la funcionalidad requerida para esa carrera y entonces se
deja al equipo para que la entregue. El punto es estabilizar los requisitos durante la carrera.
La literatura de SCRUM se enfoca principalmente en la planeación
iterativa y el seguimiento del proceso. Es muy cercana a las otras metodologías agiles en
muchos aspectos y debe funcionar bien con las prácticas
de código de la xp.
Todos los días el equipo sostiene una junta corta (quince minutos), llamada SCRUM, dónde el equipo
discurre lo que hará al día siguiente.
DESARROLLO MANEJADO POR RASGOS
El desarrollo manejado por rasgos (FDD por sus siglas en inglés) fue desarrollado por Jeff de Luca y el viejo
gurú de la OO Peter Coad.
Como las otras metodologías adaptables, se enfoca en iteraciones
cortas que entregan funcionalidad tangible. En
el caso del FDD las iteraciones duran dos
semanas.
Desarrollar un
modelo global
Construir una lista
de los rasgos
Planear por rasgo
Diseñar por rasgo
Construir por rasgo
El FDD tiene cinco procesos. Los primeros tres se hacen al principio del
proyecto.
Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación.
Los desarrolladores entran en dos tipos: dueños de clases y programadores jefe.
Los programadores jefe son los desarrolladores más experimentados. A ellos se les asignan rasgos a construir.
Sin embargo ellos no los construyen solos.
Solo identifican qué clases se involucran en la implantación de un rasgo y juntan a los dueños de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe actúa como el coordinador, diseñador líder y mentor mientras los dueños de clases hacen gran parte de la codificación del rasgo.
DSDM (MÉTODO DE DESARROLLO DE SISTEMA DINÁMICO)
El estudio de negocio es una serie corta de talleres para entender el área de negocio dónde
tiene lugar el desarrollo. También propone arquitecturas de esbozos del sistema y un plan
del proyecto.
El método empieza con un estudio de viabilidad y negocio. El estudio de viabilidad considera si
DSDM es apropiado para el proyecto.
El resto del proceso forma tres ciclos entretejidos: el ciclo del modelo funcional produce documentación de análisis y prototipos, el ciclo de diseño del modelo diseña
el sistema para uso operacional, y el ciclo de
implantación se ocupa del despliegue al uso
operacional.
DSDM tiene principios subyacentes que incluyen una interacción activa del
usuario, entregas frecuentes, equipos
autorizados, pruebas a lo largo del ciclo. Como otros métodos ágiles usan ciclos de plazos cortos de entre
dos y seis semanas. Hay un énfasis en la alta calidad y
adaptabilidad hacia requisitos cambiantes.
MANIFIESTO PARA EL DESARROLLO DE SOFTWARE ÁGIL
Con tanta similitud entre estos métodos, sería justo un poco de
interés en alguna forma de trabajo
colaborativo.
Los representantes de cada una de estas
metodologías fueron invitados a un taller
de dos días en Snowbird, Utah en febrero de 2001.
Todos estábamos conscientes del hecho de
que había mucho en común, y este
reconocimiento era mucho mayor que las diferencias
entre los procesos.
Además de un contacto útil entre los líderes de
procesos, había también la idea de emitir una
declaración conjunta.
COMPROBACIÓN DIRIGIDA POR EL CONTEXTO
Desde el principio han sido los desarrolladores de software quienes han conducido a la comunidad ágil.
Sin embargo muchas otras personas envueltas en el desarrollo de software son afectadas por este nuevo movimiento.
Un grupo obvio es el de los verificadores que a menudo viven en un mundo dominado por el pensamiento de cascada.
Con pautas comunes que declaran que el papel de la comprobación es asegurar la conformidad del software con las especificaciones escritas de antemano, el papel de los verificadores en el mundo ágil esta lejos de ser claro.
En lo que se aclara eso, varias personas en la comunidad de verificadores han estado cuestionando mucho de la corriente principal del pensamiento en comprobación por un tiempo ya.
Esto ha llevado a un grupo conocido como la comprobación conducida por el contexto. La mejor descripción de esto es el libro lecciones aprendidas en comprobación de software.
Esta comunidad es también muy activa en la web, eche una mirada a sitios organizados por Brian Marick (uno de los autores del manifiesto ágil), Brett Pettichord, James Bach, y Cem Kaner.
Top Related