Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos PDF

Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Conceptos de Diseño.  El Diseño de Software Diseño de Software es el es el conjunto de actividades en el que los requerimientos de un producto son transformados, a través de una serie de decisiones, en unas ab...

Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Conceptos de Diseño.  El Diseño de Software Diseño de Software es el es el conjunto de actividades en el que los requerimientos de un producto son transformados, a través de una serie de decisiones, en unas abstracciones que facilitarán al desarrollador la programación y pruebas del software. Estas abstracciones son el diseño y deben incluir, como mínimo: Las Partes principales del producto Cómo es la interacción entre las partes Cómo deben ensamblarse las partes para producir el producto final  El Diseño de Software Estas abstracciones deben poder ser, por un lado, evaluadas: Contra los requerimientos para ver si se podrán satisfacer en el código. Evaluadas contra criterios como acoplamiento, cohesión, separación de responsabilidades. Siempre se debe poder justificar una decisión de diseño. Por otro lado, deben: estar expresadas en términos no ambiguos y ser una guía clara para la implementación del producto, esto es, debe producir una especificación precisa y completa de cómo el producto será construido  Conceptos de Diseño El diseño de software agrupa el conjunto de principios, conceptos y prácticas que llevan al desarrollo de un sistema o producto de alta calidad. El objeto del diseño es producir un modelo o representación que tenga resistencia funcionalidad y belleza. El modelo del diseño proporciona detalles sobre la arquitectura del software, estructuras de datos, interfaces y componentes que se necesitan para implementar el sistema. También el diseño permite modelar el sistema o producto que se va a construir. Por último el diseño es el lugar en el que se establece la calidad del software.  Diseño en el contexto de la ingeniería de software El diseño de software comienza una vez que se han analizado y modelado los requerimientos, el diseño de software. Siempre debe comenzar con el análisis de los datos pues son el fundamento de todos los demás elementos del diseño. El diseño de la arquitectura define la relación entre los elementos principales de la arquitectura de software, los estilos y patrones de diseño de la arquitectura que pueden usarse para alcanzar los requerimientos definidos por el sistema y las restricciones que afectan la forma en que se implementa la arquitectura.  Diseño en el contexto de la ingeniería de software El diseño de la interfaz describe la forma en la que el software se comunica con los sistemas que interactúan con él y con las personas que lo utilizan. Una interfaz implica un flujo de información (por ejemplo, datos o control) y un tipo específico de comportamiento. Entonces los modelos de escenario de uso y de comportamiento dan mucha de la información requerida para diseñar la interfaz. La importancia del diseño del software se resume en la palabra: calidad. El diseño es el sitio en el que se introduce calidad de la ingeniería de software. Da representaciones del software que pueden evaluarse en su calidad.  Los retos del Diseño de Software La gran mayoría de los proyectos de desarrollo de software son proyectos de una gran incertidumbre en cuanto a muchos factores: los requerimientos, los usuarios, la tecnología, el equipo de desarrollo, etc. Estos proyectos son proyectos de construcción colectiva de conocimiento donde gradualmente se va disminuyendo la incertidumbre. Estos procesos graduales (iterativos, cíclicos) son más complejos que aquellos donde las etapas y los resultados de cada una son claros. Los proyectos de software serían más fáciles si se pudiera tener completa la especificación de los requerimientos en la etapa de análisis y luego un completo diseño en la etapa de diseño y luego la programación y las pruebas sin tener que volver atrás a cuestionar los requerimientos o los diseños. Lo usual es que los requerimientos sean cambiantes y que estos cambios afecten el diseño o que una vez en la programación descubramos que el diseño no era el adecuado o que la tecnología particular no soporta alguna idea de diseño que se tenía.  Los retos del Diseño de Software Algunos de los retos del Diseño de Software los podemos resumir de la siguiente manera: 1. Los Requerimientos las definidos o incompletos o cambiantes: Esto hará que el los diseños se deban estar a su vez cambiando, adaptando, manteniendo 2. Los Diseños no siempre se pueden separar de las tecnologías en las que se implementará la aplicación 3. La evaluación del diseño, la justificación. 4. La expresión del diseño (las abstracciones) 5. La evolución del diseño  El proceso de diseño El diseño de software es un proceso iterativo por medio del cual se traducen los requerimientos en un “plano” para construir el software. El diseño se representa en un nivel alto de abstracción, en el que se rastrea directamente el adjetivo especifico del sistema y los requerimientos más detallados de datos, funcionamiento y comportamiento.  Cómo expresar el diseño El resultado del diseño, dependiendo de la metodología utilizada, puede expresarse a través de distintos artefactos: diagrama de clases, de secuencia, de actividades, de procesos, especificaciones formales, simulaciones, etc. Independientemente de la metodología, necesitamos un mecanismos de refinamiento, es decir, una visión general del sistema que se va a construir donde podamos definir el sistema en algún conjunto de partes y luego, por cada parte, un diseño más detallado donde podamos expresar soluciones más concretas y específicas a algún problema particular. La visión global, se llama la arquitectura del software.  Arquitectura de Software La arquitectura de Sw debe ser un mecanismo de abstracción que permita razonar sobre el sistema que se va a construir o que se va a cambiar (anticipar consecuencias). También debe ayudar a guiar el desarrollo: Dividir trabajo Identificar y evaluar riesgos Determinar si se satisfacen los requerimientos y en especial los de Calidad Hay muchas definiciones de Arquitectura de software que pueden encontrarse en la literatura y en particular las recopiladas en Definiciones de Arquitectura de sw. Entre ellas se encuentra la siguiente definición que tiene mucho que ver con nuestros elementos básicos de diseño: ”… Software Architecture is the process of reducing coupling and improving cohesion at every level of granularity and from every perspective.” John Carter. Tomado de: Definiciones de Arquitectua de sw. Si necesitamos una definición de arquitectura que nos sirva para decidir cómo la expresamos podemos utilizar la siguiente: La arquitectura de software de un sistema es el conjunto de estructuras/vistas necesarias para razonar sobre el sistema, cada una comprende elementos de software, relaciones entre ellos y propiedades de ambos. [Bass et al. Software Architecture Third edition 2012].  Lineamientos y atributos de la calidad del software El proceso de diseño se evalúa la calidad de éste, de acuerdo con la serie de revisiones técnicas, las cuales se sugieren tres características que funcionan como guía para evaluar un buen diseño. Se deben implementar todos los requerimientos explícitos contenidos en el modelo de requerimientos y dar cabida a todos los requerimientos implícitos que desean los practicantes Debe ser una guía legible y comprensible para quienes generan el código y para los que lo prueban y dan el apoyo posterior. Debe proporcionar el panorama completo del software y abordar los dominios de los datos, las funciones y el comportamientos desde el punto de vista de la implementación.  Lineamientos de la calidad Evaluar la calidad del diseño, el equipo de software debe establecer los criterios técnicos de un buen diseño y se ha de considerar los siguientes lineamientos para un buen diseño Debe tener una arquitectura que se haya creado con el empleo de estilos y patrones arquitectónicos reconocibles que esté compuesta de componentes con buenas características de diseño y se implementen de forma evolutiva de modo que faciliten la implementación y las pruebas Debe ser modular, es decir el software debe estar dividido de manera lógica en elementos y subsistemas. Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes.  Lineamientos de la calidad Debe conducir a estructuras de datos apropiadas para las clases que se van a implementar y que surjan de patrones reconocibles de datos Debe llevar componentes que tengan características funcionales independientes Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes y el ambientes extremo Debe obtenerse con el empleo de un método repetible motivado por la información obtenida durante el análisis de los requerimientos del software Debe representarse con una notación que comunique con eficacia su significado  Evaluación de la calidad del diseño.la revisión técnica El diseño es importante porque permite que un equipo de software evalué la calidad. Durante el diseño, la calidad se evalúa por medio de la realización de una serie de revisiones técnicas, una revisión técnica es una reunión celebrada por miembros del equipo de software que en función del alcance de la información del diseño que se revisará. Cada persona tiene un papel importante: el líder de la revisión planea la reunión, establece la agenda y coordina la junta. el secretario toma notas para que no se pierda nada. el productor es la persona cuyo trabajo está en constante revisión. Antes de la revisión se entrega a cada persona del equipo una copia del producto del trabajo de diseño y se le pide que la lea y que busque errores, omisiones o ambigüedades, el objetivo en si al comenzar las reuniones es detectar todos los errores y problemas del producto de modo que puedan corregirse antes de que comience la implementación del mismo.  Atributos de calidad Hewlett-packard desarrolló un conjunto de atributos de la calidad del software a los que se dio el acrónimo FURPS: FUNCIONALIDAD, USABILIDAD, CONFIABILIDAD, RENDIMIENTO Y MANTENIBILIDAD. Los atributos de calidad FURPS representan el objetivo de todo diseño de software La funcionalidad se califica de acuerdo con el conjunto de características y capacidades del programa , la generalidad de las funciones que se entregan y la seguridad general del sistema La usabilidad se evalúa tomando en cuenta factores humanos ,la estética general ,la consistencia y la documentación La confiabilidad se evalúa con la medición de la frecuencia y gravedad de las fallas, la exactitud de los resultados que salen, el tiempo medio para que ocurra una falla ,la capacidad de recuperación ante esta y lo predecible del programa El rendimiento se mide con base en la velocidad de procesamiento, el tiempo de respuesta, el uso de recursos, el conjunto y la eficiencia La mantebilidad combina la capacidad del programa para ser ampliable, adaptable y servicial  La evolución del diseño del software La evolución del software que ya lleva casi seis décadas muestra que los primeros trabajos de diseño trabajaban con criterios para el desarrollo de programas modulares y en métodos para mejorar estructuras de software, los aspectos de procedimiento del diseño evolucionaron hacia una filosofía llamada programación estructurada. Los enfoque nuevos propusieron en un enfoque orientado a objeto para diseñar derivaciones. En la industria del software se aplican varios métodos de diseño no obstante todos estos métodos tienen algunas características en común 1. Un mecanismo para traducir el modelo de requerimientos en una representación del diseño 2. Una notación para representar los componentes funcionales y sus interfaces 3. Una heurística para mejorar y hacer particiones 4. Lineamientos para evaluar la calidad  Conjunto de tareas generales para el diseño 1. Estudiar el modelo de dominio de la información y diseñar las estructuras de datos apropiadas para los objetos de datos y sus atributos 2. Seleccionar un estilo de arquitectura que sea adecuada para el software con el uso del modelo de análisis 3. Hacer partición del modelo de análisis en subsistemas de diseño y asignar estos dentro de la arquitectura 4. Crear un conjunto de clases de diseños o componentes 5. Diseñar cualquier interfaces requerida con sistemas o dispositivos externos 6. Diseñar la interfaz de usuario 7. Efectuar el diseño en el nivel de componente 8. Desarrollar un nivel de despliegue GRACIAS  Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Conceptos de Diseño Componentes.  Concepto de diseño El principio de la sabiduría para ingeniero de software es reconocer la diferencia que hay entre hacer que un programa funcione y lograr que lo hagan bien los conceptos fundamentales del diseño del software provee la estructura necesaria para hacerlo bien  Abstracción Cuando se desarrollan niveles de abstracción distintos, se trabaja para crear abstracciones tanto de procedimiento como de datos. Una abstracción de procedimiento es una secuencia de instrucciones que tienen una función específica y limitada Existen diversos grados de abstracción, entre mayor sea el grado de la misma se considera una solución general, entre menor sea su grado se hace referencia a elementos de mayor especificidad. Abstracción procedimental: Permite describir procesos omitiendo detalles específicos. (ej.: encender automóvil) Abstracción de datos: Describe las características de un objeto. (automóvil, no siendo necesario describir en detalle su especificación para reconocerlo)  Arquitectura La arquitectura del software alude a la estructura general de este y a las formas en las que está la integridad conceptual a un sistema, la arquitectura es la estructura de organización de los componentes de un programa en módulos dadas por la siguientes propiedades Propiedades estructurales Propiedades extra estructurales Propiedades de familias de sistemas relacionados Dada la especificación de estas propiedades, el diseño arquitectónico se representa con el uso de uno más de varios modelos diferentes los modelos estructurales representan la arquitectura como un conjunto de organizado de componentes del programa Los modelos de marco aumentan el nivel de abstracción del diseño, al tratar de identificar patrones de diseño arquitectónico repetibles que se encuentran en tipos similares de aplicaciones Los modelos dinámicos abordan los aspectos estructurales del programa e indican como cambia la estructura o la configuración del sistema en función de eventos externos Los modelos del proceso se centran en el diseño del negocio o procesos técnico al que debe dar acomodo el sistema Los modelos funcionales se usan para representar la jerarquía funcional de un sistema  Patrones Un patrón de diseño describe una estructura de diseño que resuelve un problema particular del diseño dentro de un contexto específico y entre fuerzas que afectan la manera en la que se aplica y en la que se utiliza dicho patrón El objetivo de cada patrón de diseño es proporcionar una descripción que permita a un diseñador determinar 1. Si el patrón es aplicable al trabajo en cuestión 2. Si puede volverse a usar (con lo que se ahorra tiempo de diseño) 3. Si sirve como guía para desarrollar un patrón distinto en funciones y estructura  División de problemas La división de problemas es un concepto de diseño que sugiere que cualquier problema complejo puede manejarse con más facilidad si se subdivide el problema, a lo que también hace referencia a la modularidad lo que puede manejarse con más facilidad en problemas mucho más pequeños o subdivididos. Un problema es una característica o comportamiento que se especifica en el modelo de los requerimientos para el software, al separar un problema en sus piezas más pequeñas y por ello más manejables y con mayor facilidad de solución se requiere menos esfuerzo y tiempo para resolverlo.  Modularidad La modularidad es la manifestación más común de la división de problemas. El software se divide en componentes con nombres distintos y abordables por separado en ocasiones llamados módulos que se integran para satisfacer los requerimientos del problema  Ocultamiento de la información El objetivo de ocultar información es esconder los detalles de las estructuras de datos y el procesamiento tras una interfaz de modulo. Los módulos se caracterizan por ocultar las soluciones de diseño a otros Las pruebas y modificaciones se realizan de manera mas cómoda. Se evita el ingreso de errores de frontera o involuntarios al estar solucionando un problema.  Independencia funcional La independencia funcional se logra desarrollando módulos, de manera que cada módulo resuelva un subconjunto especifico de requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del programa. Con módulos independientes es más fácil de desarrollar porque su función se subdivide y las interfaces se simplifican, los módulos independientes son más fáciles de mantener debido a que los efectos secundarios causados por el diseño o par la modificación del código son más limitados, se reduce la propagación del error y es posible obtener módulos reutilizables. La independencia se evalúa con el uso de dos criterios cualitativos, la cohesión y el acoplamiento. La cohesión es un indicador de la fortaleza relativa funcional de un módulo. El acoplamiento lo es de la independencia relativa entre módulos. Un módulo cohesivo debe hacer solo una cosa aunque siempre debe tratarse de lograr mucha cohesión, con frecuencia es necesario y aconsejable hacer que un componente de software realice funciones múltiples.  Modelo Un modelo es una simplificación. Es una interpretación de la realidad que abstrae los aspectos relevantes para la solución de un problema. (Definición extraída de Domain Driven Design de Eric Evans.  Dominio Todo programa de software que se va a construir, surge como una idea, o una necesidad, que está relacionada con alguna actividad o interés. Estas “actividades” o “intereses” y el conjunto de reglas y características que lo componen, son el dominio de un problema. Cuando vayamos a construir un programa, debemos conocer y entender el dominio para poder encarar una solución al problema que tenemos. La información puede ser mucha, y en algunos casos difícil de entender, por lo que debemos crear modelos que simplifiquen, seleccionen y estructuren el conocimiento de manera de enfocarlo en lo que necesitamos para solucionar el problema.  Heurística La heurística es una medida. No es una medida cuantitativa como una longitud o un peso, sino una medida que me permite establecer un valor de referencia de una característica cualitativa. Podemos hablar de que una heurística es una buena práctica, que permite comparar dos objetos de estudio en base a una determinada característica. No vamos a poder establecer un valor numérico para compararlos pero igualmente nos va a poder permitir saber si un objeto es “más” o “menos” que el otro en ese aspecto. Por ejemplo, si hablamos de la simplicidad de un diseño, no podemos decir que un sistema tenga complejidad 3.5 complejidoñios; pero sí podemos decir que un diseño es más o menos simple que otro. Es equivocado buscar que una heurística se convierta en un número medible, eso resulta contradictorio por su propia definición. Por lo tanto, en elementos cualitativos, es imposible establecer medidas cuantitativas. Aunque resulte tentador convertir una heurística en una medición debemos evitar esa tentación a todo costo. Por ejemplo un error común es hablar de complejidad en número de clases o número de métodos, de la misma manera que no podemos medir la complejidad de una solución por la cantidad de líneas de código involucradas. Estas medidas son apenas indicios pero es necesario analizar las clases, los métodos, el código para poder determinar si efectivamente esa solución resulta más compleja que otra.  Cohesión Una clase es cohesiva si podemos definirle un objetivo claro y puntual. Un método es cohesivo si tiene un único objetivo. Emitir una factura y calcular el total de facturación está bueno que estén en diferentes métodos. En general, tener métodos con efecto colateral (emitir factura, realizar un descuento, firmar una libreta de un alumno, cambiar el sueldo básico a un empleado) y métodos que no tengan efecto (conocer el sueldo de un empleado, saber el promedio de notas de un alumno en finales, conocer el total de facturación de un mes para un cliente, etc.) es una buena práctica, también es bueno abstraer ideas que se repiten en la misma clase dándole un nombre y dejándolo en un método aparte. Así por un lado evitamos duplicar código y por otro aumenta la cohesión de un método: se concentra en hacer sólo una cosa por vez. Por eso mismo un Cliente representa todo lo que un cliente puede abstraer. Si hay una clase Empresa es porque representa para nosotros una abstracción importante en el sistema, no para que la Empresa tome decisiones que son del cliente. El cliente tiene atributos + comportamiento. Así aumentamos la cohesión de nuestro sistema. De lo contrario, la Empresa toma responsabilidades de un Cliente, de un Empleado, etc. y como hace muchas cosas a la vez, el objetivo que cumple es difuso y la consecuencia de esta menor cohesión es el impacto que tiene cualquier modificación de la estructura interna de un cliente, un empleado o una factura.  Acoplamiento Es el grado en que los componentes de un sistema se conocen. Un cliente conoce sus facturas para calcular el total, y está bien que las conozca. Lo que es nocivo para el cliente es conocer de más o de menos. De más porque si el cliente le pide las líneas (los renglones) a cada factura y luego a cada línea le pide el precio unitario de cada producto, cualquier modificación en el cálculo del precio de un producto (por ejemplo, descuento por cantidad dependiente del producto), el que se ve directamente afectado es el cliente.  Refinamiento Estrategia de diseño descendente, complemento de la abstracción. Inicia con el enunciado de una función que maneja un alto grado de abstracción y a medida que se producen nuevos detalles se va refinando el enunciado.  Refabricación Es el proceso de cambiar un sistema de software de tal forma que no altere el comportamiento externo de su código y aún así se mejore su estructura interna. Problemas de diseo: Renuncias Elementos inútiles Algoritmos innecesarios Estructuras de datos inapropiadas o mal construidas  Requerimientos y casos de uso Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Cuando hacemos especificaciones de los casos de uso definimos la interacción entre usuario y sistema, dejando claro el límite entre lo que debe proporcionar el usuario y lo que el sistema debe responder. Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema. Un requerimiento es algo que el sistema debe hacer para lograr el objetivo de un usuario.  Atributos de Calidad Funcionalidad Se estima al evaluar el conjunto de características y capacidades del programa, la generalidad de las funciones que se entregan y la seguridad del sistema en su totalidad Facilidad de uso Se valora al considerar los factores humanos, la estética, consistencia y documentación general. Confiabilidad Se evalúa al medir la frecuencia y severidad de las fallas, la precisión de los resultados de salida, la media del momento de fallas, la habilidad para recuperarse de las fallas y la previsibilidad del programa  Atributos de Calidad Desempeño Se mide con la velocidad de procesamiento, tiempo de respuesta, consumo de recursos, rendimiento y eficacia. Soportabilidad Factibilidad de mantenimiento Resistencia a pruebas Compatibilidad Configurabilidad Facilidad de instalación Facilidad localización de problemas GRACIAS  Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Modelo de Diseño Etapas -SDLC-.  Introducción Cuando hablamos de crear, delinear u organizar el ciclo de vida del desarrollo de software, nos referimos a trazar un mapa de cómo se creará y mantendrá un software específico. Si el equipo de desarrollo de software fuera un equipo de fútbol, ​el ciclo de vida del desarrollo de software sería su plan de juego. Revisaremos cada una de las etapas que componen un ciclo de vida de desarrollo de software saludable y veremos los modelos más populares utilizados para estructurarlo.  ¿Qué es el ciclo de vida del desarrollo de software? El Ciclo de Vida del Desarrollo de Sistemas o SDLC es un método que facilita el desarrollo de los sistemas de información. Entre sus funciones, sirve de soporte para que los gestores de un proyecto puedan planificar el proceso de diseño y puesta en marcha de cualquier sistema de información que deba reunir ciertos requisitos de cara a su usuario. También sirve de esquema para concretar los tiempos de desarrollo y la inversión del presupuesto. El administrador del proyecto puede gestionar del modo más efectivo cada tarea y detalle durante todo el proceso de diseño de los sistemas, proporcionándole un calendario de objetivos fundamentales para comunicar a todos los involucrados o interesados por el proyecto.  ¿Qué es el ciclo de vida del desarrollo de software? El ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés) es el proceso mediante el cual el software cobra vida. Puede variar según el marco elegido por el equipo, pero sea cual sea el camino que tome, el recorrido desde la idea hasta el software final en manos del usuario es lo que llamamos SDLC. Un SDLC completo tiene 7 etapas básicas: planificación, requisitos, diseño y prototipo, desarrollo de software, pruebas, implementación y mantenimiento. En algunos casos, dependiendo de diferentes variables (proyecto, equipo, gerente, etc.), ciertos pasos pueden omitirse, dividirse o combinarse. Un SDLC bien planificado ayuda a los equipos a reducir costos y lanzar software más rápido al tener un plan establecido al que adherirse (incluso si algunos marcos son más caóticos que otros, sigue siendo un caos controlado) y al brindar una "vista panorámica" clara para ayudar a identificar ineficiencias y obstáculos.  ¿Por qué es importante el SDLC? El desarrollo de software puede ser difícil de administrar debido a los requisitos cambiantes, los avances de la tecnología y la colaboración interfuncional. La metodología del ciclo de vida del desarrollo de software (SDLC) ofrece un marco de administración sistemático con entregas específicas en cada etapa del proceso de desarrollo de software. Como resultado, todas las partes interesadas establecen por adelantado los objetivos y requisitos de desarrollo del software y también cuentan con una planificación para conseguirlo. A continuación, se indican algunas ventajas del SDLC: Mayor visibilidad del proceso de desarrollo para todas las partes interesadas implicadas Una estimación, planificación y programación eficientes Mejoras en la administración de riesgos y estimación de costos Entregas de software sistemáticas y mayor satisfacción de los clientes  ¿Cómo funciona el SDLC? Hay siete fases del ciclo de vida del desarrollo de software, y deben abordarse de forma secuencial, aunque en algunos casos dos pueden ejecutarse simultáneamente (al igual que el desarrollo y las pruebas). El SDLC “funciona” cuando su equipo se organiza y ejecuta de acuerdo con esta secuencia; la forma en que aborden cada paso individual dependerá del marco que hayan elegido (más sobre esto más adelante). Por ahora, describamos lo que sucede en cada etapa/fase. Indistinto de la metodología de desarrollo que se quiera utilizar, estas pueden durar mayor o menor tiempo de ejecución, lo importante será la habilitad del equipo para comprender y realizar cada etapa, de ahí la importancia de la selección del equipo de trabajo.  1. Planificación Esta es la primera fase de toda vida de un desarrollo de sistemas. En ella, las personas que promueven el desarrollo del proyecto, junto a los interesados en su conclusión, definen los sistemas a diseñar y determinan el alcance de todo el proceso, permitiendo que se definan los límites para aspectos como los recursos materiales y humanos, el presupuesto y el tiempo para cada tarea. En esta fase el proyecto conduce a definir el propósito del proyecto y el resultado deseado.  1. Planificación Si el equipo está desarrollando para un cliente en lugar de para el mercado, el director de proyectos se reúne con ellos para hablar sobre el producto, su propósito y los resultados que quieren lograr. El equipo recopila toda la información posible sobre el producto que ofrece el cliente. Al final de la fase de planificación, los líderes del equipo deben tener una estimación de cuánto costará el proyecto y quiénes participarán en él. También establecen una fecha límite y los hitos del proyecto y, en general, crean la estructura básica del proyecto. Al final de esta fase (o al menos, de la siguiente), cada miembro del equipo debe comprender sus roles y tareas.  2. Requisitos Una vez que los interesados en el diseño definen el alcance del trabajo a realizar, los expertos en Tecnologías de la Información empiezan a relacionarse con los usuarios finales del sistema, a fin de definir los requisitos a cumplir por el proyecto finalizado. Una vez que se recaban todos los requisitos, los expertos de TI vuelven a reunirse con los usuarios para repasarlos en una fase de verificación. Esta fase termina cuando los usuarios finales validan los requisitos que se han definido.  2. Requisitos Esta segunda fase del ciclo de vida del desarrollo de software suele realizarse simultáneamente con la primera. En ella, el responsable del proyecto analiza los objetivos del producto o del cliente y decide las características que se pretenden alcanzar como objetivo final. La definición y el establecimiento de requisitos determinan lo que hará la aplicación una vez lanzada, los componentes necesarios y los recursos necesarios para lanzarla. Por ejemplo, si un equipo quiere desarrollar un software para controlar un robot que limpia, entonces el robot físico sería un requisito (componente) en el proceso.  3. Diseño y Prototipo Los trabajadores de TI empiezan a convertir los requisitos definidos en una realidad técnica. Es el momento de crear un diseño técnico con el que previsualizar el trato que se les darán a los requisitos definidos en el desarrollo del nuevo sistema. Después, se crea un diseño técnico más detallado en el que se da respuesta a todas las funciones tecnológicas que necesita el sistema para cumplir sus objetivos. Una vez comprendidas y establecidas las fases 1 y 2, los desarrolladores pueden comenzar a diseñar el software.  3. Diseño y Prototipo La fase de diseño define cómo funcionará una aplicación de software. Durante esta fase, los equipos deciden el lenguaje de programación, los diseños de pantalla y la documentación pertinente que utilizarán. Algunos de los aspectos fundamentales que los desarrolladores cubren durante esta fase son: Arquitectura: Los equipos definen si quieren un tipo específico de plantilla o si quieren implementar algún tipo de práctica de la industria. Interfaz de usuario: Los equipos definen la forma en que los usuarios interactuarán con la plataforma. Seguridad: los desarrolladores deben definir cómo mantendrán segura la aplicación. Esto significa que deben decidir cómo proteger los datos de los usuarios y los datos generales de la aplicación. Programación: Definir la tecnología y el conjunto de herramientas del proyecto.  3. Diseño y Prototipo El prototipado también forma parte de esta fase. Un prototipo es una idea básica de cómo se ve y funciona la aplicación. Los prototipos permiten a los clientes obtener una idea preliminar de cómo se verá su aplicación; incluso podrían descubrir que su idea original no es lo suficientemente buena y cambiarla durante esta fase.  4. Desarrollo de software Durante esta fase, los desarrolladores comienzan a programar. Si trabajan en un proyecto pequeño, un desarrollador se hace cargo de las tareas de codificación, mientras que en proyectos grandes, el código base puede ser trabajado por varios desarrolladores. Antes de comenzar a codificar, los equipos deben tener pautas claras y predefinidas para garantizar la calidad del código. En esta fase, los desarrolladores comienzan a construir todo el sistema y a darle forma al proyecto. Dependiendo del modelo de cada equipo, la fase puede realizarse en sprints (Agile) o en un solo bloque (Waterfall). Los equipos dedican la mayor parte de su tiempo durante esta fase a garantizar que la aplicación funcione de manera eficiente.  4. Desarrollo de software En esta fase los especialistas en TI empiezan a crear el sistema diseñado. Crean el software y la arquitectura física necesaria para albergar la base de datos del sistema. Una vez terminada la construcción de todos los componentes del sistema, empiezan a realizarse las pruebas, durante las cuales los responsables de la calidad se aseguran de que los requisitos de negocio se cumplen, usando un esquema detallado de testeo.  5. Pruebas A menudo, las pruebas se realizan en paralelo al desarrollo, mientras los desarrolladores escriben y prueban el código que han producido antes de pasar a la siguiente tarea de codificación. Durante esta fase, se realizan diferentes tipos de pruebas, como pruebas de calidad del código, pruebas unitarias, pruebas de integración, pruebas de rendimiento y pruebas de seguridad. Realizar pruebas en paralelo con el desarrollo significa que los errores se pueden corregir en el mismo sprint o bloque de tiempo, lo que es más eficiente que agregar un bloque completo de código para realizarlo al final del proyecto. También mitiga el problema de que las correcciones de errores generen nuevos errores.  6. Despliegue Los especialistas en TI ponen en manos de los usuarios finales el sistema completado, a fin de que puedan empezar a utilizarlo, suministrándoles, además, toda la documentación necesaria para aprender a utilizarlo correctamente. También suelen dedicarse algunas horas a formar en el uso. El proceso de implementación comienza una vez que finaliza la fase de prueba y no hay errores ni fallos en el backlog de desarrollo.  6. Despliegue El equipo se asegura de que el software esté actualizado y sea lo suficientemente seguro para los usuarios y lo envía desde el entorno de desarrollo a un entorno en vivo, generalmente una tienda de aplicaciones. Durante esta fase, el equipo de soporte técnico busca comentarios de los usuarios y se asegura de que lleguen al equipo de desarrollo.  7. Mantenimiento En este punto del ciclo SDLC, la aplicación se ha lanzado con éxito y se está utilizando. Sin embargo, esta última fase sigue siendo importante porque es probable que aparezcan errores o fallos que no se hayan detectado durante las pruebas. Al mismo tiempo, al estudiar el comportamiento y los comentarios de los usuarios, el equipo puede empezar a pensar en las actualizaciones y planificarlas.  7. Mantenimiento Durante una fase de operación total, los expertos desarrolladores controlan el sistema para asegurar que cumple los requisitos de negocio solicitados antes del diseño. Se ofrece un servicio de mantenimiento y de soporte a los usuarios para garantizar que el sistema sigue funcionando correctamente.  Disposición Esta fase comprende el fin del ciclo de vida del sistema y su retiro del funcionamiento. Se deben seguir unos pasos sistemáticos para finalizar el sistema en un entorno de seguridad, que permita conservar toda información útil o sensible de cara a continuar con los negocios en un sistema nuevo.  Seguridad Es importante saber que hoy en´día, un modelo de desarrollo seguro que incluya como uno de sus ejes principales, un ciclo de vida de desarrollo seguro (S-SDLC – Secure Software Development LifeCycle), contribuye a minimizar las posibilidades de ataques o intrusiones y a permitir una eficiente identificación y resolución de vulnerabilidades durante el proceso de construcción de software. GRACIAS  Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Modelo de Diseño Los Modelos -SDLC-.  Los modelos SDLC Un modelo de ciclo de vida del desarrollo de software (SDLC) presenta de manera conceptual un SDLC de manera organizada para permitir que las organizaciones lo implementen. Diferentes modelos disponen las fases del SDLC en diversos órdenes cronológicos para optimizar el ciclo de desarrollo. Los modelos que veremos ya son conocidos por todos, sin embargo, es importante tener una recapitulación y ver algunos detalles de estos. A continuación, se muestran algunos modelos SDLC conocidos.  Cascada El modelo en cascada fue el proceso original del ciclo de vida del desarrollo de software (SDLC). Este modelo divide el proyecto en fases discretas, cada una con sus propias tareas y objetivos. En este modelo, el equipo debe ejecutar cada etapa completamente, lo que significa que el resultado de una fase es la entrada de la siguiente. Si una fase no se completa, es imposible avanzar a la siguiente. Otra característica del modelo Waterfall es que está estrictamente documentado y tiene características predefinidas que se espera que se desarrollen en cada fase.  Cascada El modelo de cascada dispone todas las fases secuencialmente de modo que las nuevas fases dependan del resultado de la fase anterior. Desde un punto de vista conceptual, el diseño fluye desde una fase a otra inferior, como en una cascada. Ventajas y desventajas El modelo de cascada hace que la administración del proyecto sea muy estricta y proporciona un resultado tangible al final de cada fase. Sin embargo, hay poco margen de cambio una vez que una fase se considera completa, ya que los cambios pueden afectar al tiempo de entrega, al costo y a la calidad del software. Por lo tanto, el modelo es más adecuado para pequeños proyectos de desarrollo de software, donde las tareas se pueden organizar y administrar fácilmente y los requisitos se pueden predefinir con precisión. Cascada  Cascada Fases del Modelo Cascada: 1. Fase de Análisis: Planificación, análisis y especificación de los requerimientos. 2. Fase de Diseño: Diseño y especificación del sistema. 3. Fase de Implementación: Programación y pruebas unitarias. 4. Fase de Verificación: Integración de sistemas, pruebas de sistema e integración. 5. Fase de Despliegue: Despliegue de sistemas 6. Fase de Mantenimiento: Entrega, mantenimiento y mejora.  Cascada ¿Cuándo utilizar el modelo en cascada? Cuando se tiene una idea clara de cómo se quiere que sea el resultado final. Cuando los clientes no pueden modificar el alcance de un proyecto una vez que este ha comenzado. Cuando se trata del éxito, el concepto y la definición son cruciales (pero no la velocidad). Cuando no hay dudas sobre lo que se debe hacer.  Iterativo El modelo iterativo se basa en la repetición. En lugar de comenzar conociendo todos los requisitos, los desarrolladores implementan un conjunto de requisitos de software, los prueban y los mejoran. Esto sucede una y otra vez hasta que el proyecto finaliza. El proceso iterativo sugiere que los equipos comienzan el desarrollo de software con un pequeño subconjunto de requisitos.  Iterativo Posteriormente, se mejoran las versiones de manera iterativa a lo largo del tiempo hasta que el software final esté listo para pasar a producción. El equipo produce una nueva versión de software al final de cada iteración. Ventajas y desventajas Es fácil identificar y administrar riesgos, ya que los requisitos pueden cambiar entre cada iteración. Sin embargo, la repetición de los ciclos puede dar lugar a que cambien los objetivos y se subestimen los recursos. Iterativo  Iterativo ¿Cuándo utilizar el modelo incremental e iterativo? El modelo incremental e iterativo se puede utilizar en las siguientes situaciones: Se requiere la entrega rápida de funcionalidades críticas. Hay una nueva innovación tecnológica que se puede utilizar para llevar a cabo un proyecto. El grupo de trabajo no está familiarizado con el dominio. Hay una corporación que tiene grandes aspiraciones de mejora.  Espiral El modelo en espiral combina la arquitectura y la creación de prototipos en etapas. Este modelo permite lanzar y perfeccionar productos a través de cada fase en espiral. Además, es posible construir prototipos en cada fase, lo que permite detectar y gestionar riesgos. Esto supone una pérdida de tiempo de desarrollo y un aumento de costes, por lo que solo es viable para grandes organizaciones con presupuestos cuantiosos.  Espiral El modelo de espiral combina los pequeños ciclos repetidos del modelo iterativo con el flujo secuencial y lineal del modelo de cascada para dar prioridad al análisis de riesgos. Puede usar el modelo de espiral para garantizar la actualización y mejora graduales del software mediante la creación de prototipos en cada fase. Ventajas y desventajas El modelo de espiral es adecuado para proyectos grandes y complejos que requieren cambios frecuentes. Sin embargo, puede ser costoso para proyectos pequeños con objetivos muy concretos. Espiral  Espiral Las fases del modelo espiral son: Fase de planificación: El paso inicial es identificar y establecer objetivos y metas a alcanzar. Luego, como alternativas, se presentan las mejores formas potenciales de satisfacer los objetivos. Todo esto requiere una comunicación continua entre el cliente y el equipo de gestión del proyecto. Fase de análisis de riesgos: Durante la planificación y finalización de la estrategia de reducción de riesgos, se identifican los posibles peligros. Cada peligro destacado se somete a un examen minucioso. Se pueden crear prototipos para eliminar la posibilidad de requisitos ambiguos. Los riesgos se minimizan tomando precauciones. Fase de ingeniería: Implica la codificación, prueba e implementación del software. Después de una evaluación de riesgos, se adopta el modelo de desarrollo. El modelo a utilizar se determina en función del nivel de riesgo que se ha reconocido para esa fase. Fase de evaluación: Evaluación del programa por parte del cliente. Se decide si se repite o no el ciclo. Aquí se planifica la siguiente fase del proyecto.  Espiral ¿Cuándo utilizar el modelo en espiral? Las ventajas del modelo en espiral son más evidentes en situaciones en las que: Es deseable tener lanzamientos de software frecuentes. Se utilizan prototipos. La gestión de riesgos y gastos es fundamental. En proyectos con un riesgo medio-alto y un riesgo alto. Los criterios de exigencia son ambiguos y difíciles de entender. Hay muchos cambios en marcha y pueden ocurrir en cualquier momento. Ya sea por razones económicas o de otro tipo, el compromiso a largo plazo del proyecto se ve comprometido.  Ágil La metodología Agile SDLC hace especial hincapié en la comunicación entre el desarrollador y el cliente. El equipo acuerda un MVP (producto mínimo viable) con características esenciales e intenta alcanzarlo en la menor cantidad de iteraciones posible. Después de cada iteración de desarrollo, el cliente puede ver los resultados y comunicar al equipo si está satisfecho. Por lo tanto, el trabajo se realiza en ciclos iterados periódicamente que se identifican como sprints; los proyectos bajo el modelo Agile suelen durar entre dos y cuatro semanas. Este es uno de los modelos más populares para equipos remotos.  Ágil El modelo ágil dispone las fases del SDLC en varios ciclos de desarrollo. El equipo itera a través de las fases rápidamente y solo se hacen pequeños cambios progresivos de software en cada ciclo. Los requisitos, planes y resultados se evalúan continuamente para responder con rapidez a los cambios. El modelo ágil es iterativo y progresivo, por lo que es más eficiente que otros modelos de procesos. Ventajas y desventajas Los ciclos rápidos de desarrollo permiten a los equipos identificar y abordar problemas en proyectos complejos desde el principio y antes de que se conviertan en problemas graves. También promueven la partición de los clientes y las partes interesadas para que den su opinión en todo el ciclo de vida del proyecto. Sin embargo, depender en exceso de la opinión de los clientes puede hacer que los objetivos cambien drásticamente o dejar el proyecto a medias.  Ágil El modelo ágil dispone las fases del SDLC en varios ciclos de desarrollo. El equipo itera a través de las fases rápidamente y solo se hacen pequeños cambios progresivos de software en cada ciclo. Los requisitos, planes y resultados se evalúan continuamente para responder con rapidez a los cambios. El modelo ágil es iterativo y progresivo, por lo que es más eficiente que otros modelos de procesos. Ventajas y desventajas Los ciclos rápidos de desarrollo permiten a los equipos identificar y abordar problemas en proyectos complejos desde el principio y antes de que se conviertan en problemas graves. También promueven la partición de los clientes y las partes interesadas para que den su opinión en todo el ciclo de vida del proyecto. Sin embargo, depender en exceso de la opinión de los clientes puede hacer que los objetivos cambien drásticamente o dejar el proyecto a medias. Ágil Ágil  Ágil Los enfoques de desarrollo de software ágil, en particular, apuntan a ofrecer pequeñas porciones de software funcional en un corto período de tiempo para mejorar la satisfacción del cliente. Para lograr un desarrollo continuo, estas estrategias emplean enfoques flexibles y cooperación.  OTROS MODELOS Adicional a los modelos anteriores, existen otros modelos que también son utilizados. Estos modelos son menos conocidos pero  Modelo Prototipo En este modelo, se construye un prototipo completo antes de desarrollar el software. Los modelos de prototipos tienen capacidades funcionales limitadas y un rendimiento ineficiente en comparación con el software real. Sin embargo, son útiles cuando los equipos desean obtener comentarios valiosos del cliente. El proceso de este modelo comienza con una entrevista a los clientes y el desarrollo de un modelo incompleto con un prototipo inicial que admite la funcionalidad básica deseada por el cliente. El cliente evalúa y proporciona comentarios, y el equipo continúa trabajando en el prototipo. El proceso continúa hasta que el usuario aprueba el prototipo. Modelo Prototipo  Modelo Prototipo ¿Cuándo utilizar el modelo de prototipo? Cuando los requisitos del sistema deseado son inequívocos. Cuando las funciones básicas del sistema deseado aún están por evaluar. Si es necesario cambiar los requisitos del sistema resultante. Para mostrar las funcionalidades técnicas del producto deseado mediante la creación de un prototipo.  Modelo en V Este modelo SDLC también se conoce como modelo de validación y verificación porque se centra en probar cada etapa antes de pasar a la siguiente. Esto significa que cada etapa tiene un proceso de control para garantizar que se cumplan los hitos de desarrollo antes de que el equipo pueda comenzar la siguiente fase del proceso de desarrollo de software. Modelo en V  Modelo en V Fases del modelo V: Fase de verificación: Análisis de requisitos: el paso inicial de la fase de verificación es comprender las expectativas de los clientes sobre nuestros productos mediante una amplia comunicación con ellos. Diseño del sistema: después de la identificación de los requisitos y expectativas de los clientes sobre nuestros productos, se debe desarrollar el sistema de diseño detallado para el desarrollo del producto. Diseño arquitectónico: el diseño del sistema se divide en diferentes módulos según sus funcionalidades. Se reconoce la transferencia de datos entre los módulos internos y otros sistemas. Diseño del módulo: los diseños se dividen en módulos más pequeños y más detallados. Fases de validación: Pruebas unitarias: las pruebas unitarias eliminan errores a nivel de código o de unidad. Pruebas de integración: las pruebas de integración validan la comunicación interna entre los módulos dentro del sistema. Pruebas del sistema: las pruebas del sistema examinan los requisitos funcionales y no funcionales de la aplicación desarrollada. Pruebas de aceptación del usuario (UAT): las UAT validan la usabilidad del sistema desarrollado en el mundo real.  Modelo Scrum Al abordar desafíos, los proyectos que utilizan esta técnica valoran mucho el intelecto, la experiencia y las habilidades que aportan los miembros del equipo de desarrollo. Las actividades del proyecto se completan en ciclos cortos conocidos como sprints, que son relativamente manejables y están bien priorizados, lo que permite un fácil seguimiento del progreso. En comparación con otros modelos de desarrollo de software, esta estrategia beneficiaría a las iniciativas más grandes, y una de las razones es que los desarrolladores se sienten comprometidos con los objetivos y responsables del éxito de la iniciativa. Modelo Scrum  Modelo Scrum Fases del modelo ágil Scrum: Product Backlog: La fase de product backlog es cuando se determinan las tareas prioritarias y se recopila información concisa y completa sobre el proyecto que se va a crear. Sprint: El sprint es el corazón del proceso Scrum, un período de tiempo de un mes durante el cual se lleva a cabo la creación de un producto potencialmente entregable. Burn Down: El burn down es la fase en la que se mide el progreso de un proyecto Scrum. Cuando se completa cada sprint, el Scrum Master será responsable de actualizar los elementos visuales. ¿Cuándo utilizar el modelo ágil Scrum? Este enfoque se utiliza en situaciones en las que se requieren resultados inmediatos. En casos en los que hay mucha ambigüedad y las tareas no están bien definidas. Cuando un cliente solicita un enfoque de desarrollo altamente personalizado para un determinado producto.  Modelo Programación Extrema (XP) La técnica de Programación Extrema permite a los especialistas realizar cambios incluso después de que la iteración haya comenzado. Normalmente, se necesitan de 1 a 2 semanas para completar una iteración. El enfoque XP o Programación Extrema es una metodología de desarrollo ágil que tiene como objetivo desarrollar y gestionar proyectos con eficiencia, flexibilidad y control. Se basa en la comunicación, la reutilización del código generado y la retroalimentación. Modelo Programación Extrema (XP)  Modelo Programación Extrema (XP) Fases del modelo de programación extrema (XP): Planificación: Se priorizan las historias de usuario y se dividen en mini-versiones según su identidad. Se realizará una reevaluación de la planificación. Codificación: Se trabaja con un código simple en esta fase, realizando solo lo mínimo necesario para que funcione. Será posible obtener el prototipo. Prueba: La programación se realiza en parejas frente a la misma computadora, “a dos manos”. Es común que se alternen los compañeros. Esto garantiza que se cree un código más general, que cualquier otro programador pueda comprender y trabajar con él. Lanzar: Si llegamos a esta fase, indica que hemos probado con éxito todas las historias de usuario o mini-versiones teniendo en cuenta las necesidades del cliente.  Modelo Programación Extrema (XP) ¿Cuándo utilizar el modelo de programación extrema (XP)? Este enfoque se puede utilizar cuando se requieren los siguientes factores: La comunicación entre el cliente y el equipo de desarrollo siempre está abierta. El cambio constante requiere una reacción rápida. Con un calendario flexible de actividades, la planificación es abierta. El software funcional tiene prioridad sobre cualquier otra forma de documentación. Los principales criterios de éxito del proyecto son las necesidades del cliente y los esfuerzos del equipo del proyecto. Colaborar de forma remota en los proyectos.  Modelo Big Bang Uno de los modelos más simples de SDLC es el modelo Big Bang. Es un caos puro y simple: un proyecto apasionante, un enfoque de grupo de garaje para el proceso de desarrollo de software. Básicamente, comienza desde cero, ya que no tiene un proceso definido y estricto. No requiere mucha planificación ni programación. Sin embargo, requiere una gran cantidad de fondos (ya que nunca se sabe cuándo se realizarán las cosas y probablemente se cambiará de rumbo varias veces durante el proceso) y la codificación suele llevar más tiempo. El modelo Big Bang se utiliza principalmente en proyectos pequeños o con fines académicos. Es ideal para equipos que no tienen requisitos específicos ni una fecha de lanzamiento establecida. Modelo Big Bang  ¿Cómo aborda el SDLC la seguridad? En el desarrollo de software convencional, las pruebas de seguridad eran un proceso independiente del ciclo de vida del desarrollo de software (SDLC). El equipo de seguridad descubrió errores de seguridad solo después de crear el software. Esto dio lugar a una gran cantidad de errores que permanecían ocultos, así como mayores riesgos de la seguridad. En la actualidad, la mayoría de los equipos reconocen que la seguridad es una parte integral del ciclo de vida del desarrollo de software. Puede abordar cuestiones de seguridad en SDLC mediante prácticas de DevSecOps y llevar a cabo evaluaciones de seguridad durante todo el proceso del SDLC.  ¿Cómo aborda el SDLC la seguridad? DevSecOps DevSecOps es la práctica de integrar las pruebas de seguridad en cada etapa del proceso de desarrollo de software. Incluye herramientas y procesos que fomentan la colaboración entre los desarrolladores, los especialistas en seguridad y los equipos de operaciones para crear un software que pueda hacer frente a las amenazas actuales. Además, garantiza que las actividades de garantía de la seguridad, como revisión de código, análisis de arquitectura y pruebas de penetración, formen parte del proceso de desarrollo.  ¿Cómo se compara el SDLC con otras metodologías de administración del ciclo de vida? En el ámbito de la tecnología, el término ciclo de vida del desarrollo de software (SDLC) se refiere con frecuencia al proceso completo de innovación y asistencia tecnológica. A continuación, se indican otros términos similares. Ciclo de vida del desarrollo de sistemas La abreviatura SDLC se refiere en ocasiones al ciclo de vida del desarrollo de sistemas, es decir, el proceso de planificación y creación de un sistema de TI. El sistema incluye normalmente varios componentes de hardware y software que trabajan conjuntamente para llevar a cabo funciones complejas. Comparación entre el ciclo de vida del desarrollo de software y el ciclo de vida del desarrollo de sistemas El ciclo de vida del desarrollo de software solo aborda el desarrollo y pruebas de componentes de software. En cambio, el desarrollo de sistemas es un superconjunto más amplio que incluye la configuración y administración del software, hardware, personas y procesos que componen un sistema. Puede incluir tareas como políticas de administración de cambios y formación organizativa que no están dentro del ámbito del desarrollo de software.  ¿Cómo se compara el SDLC con otras metodologías de administración del ciclo de vida? Administración del ciclo de vida de aplicaciones La administración del ciclo de vida de aplicaciones (ALM) se refiere a la creación y mantenimiento de aplicaciones de software hasta que dejen de utilizarse. Implica varios procesos, herramientas y personas que trabajan conjuntamente para administrar todos los aspectos del ciclo de vida, como las ideas, el diseño y el desarrollo, las pruebas, la producción, la asistencia técnica y la posible redundancia. Comparación entre SDLC y ALM El SDLC describe la fase de desarrollo de una aplicación con mayor detalle. Forma parte de la ALM. La ALM comprende todo el ciclo de vida de la aplicación y trasciende el SDLC. La ALM puede incluir varios SDLC durante el ciclo de vida de una aplicación.  ¿Cómo aborda el SDLC la seguridad? DevSecOps DevSecOps es la práctica de integrar las pruebas de seguridad en cada etapa del proceso de desarrollo de software. Incluye herramientas y procesos que fomentan la colaboración entre los desarrolladores, los especialistas en seguridad y los equipos de operaciones para crear un software que pueda hacer frente a las amenazas actuales. Además, garantiza que las actividades de garantía de la seguridad, como revisión de código, análisis de arquitectura y pruebas de penetración, formen parte del proceso de desarrollo. GRACIAS  Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Diseño Físico de Datos -Etapas-.  ¿Qué es el diseño de base de datos? El diseño de base de datos es un proceso cuyo objetivo es definir la estructura adecuada para nuestro sistema de información. El diseño de base de datos es un proceso fundamental a la hora de modelar nuestros conjuntos de datos y definir las operaciones que queremos realizar sobre ellos. La información es el activo más importante de una organización. Los datos son el activo más importante y con una base de datos bien diseñada influye de forma directa en la eficiencia que obtendremos a la hora de almacenar, recuperar y analizar nuestros datos.  Ventajas del diseño de base de datos Un diseño de base de datos realizado de forma correcta nos proporciona unas ventajas fundamentales: Nos permite ahorrar espacio, mediante el diseño de base de datos optimizadas y sin datos duplicados. Nos ayuda a que se preserve la precisión e integridad de los datos y que no se pierda información. Agiliza de forma extrema el acceso y el procesamiento de los datos.  Los tres pilares del modelado de bases de datos El modelado de datos es una etapa fundamental en el desarrollo de cualquier sistema de información. A través de la creación de modelos, se define y estructura la información que se va a manejar, facilitando la comprensión, el análisis y la implementación del sistema. En este proceso, tres tipos de modelos se erigen como pilares fundamentales: el modelo conceptual, el modelo lógico y el modelo físico.  1. El modelo conceptual: la esencia del negocio El modelo conceptual se centra en la «qué» de la información. Es una representación abstracta, independiente de cualquier tecnología, que define los conceptos y las relaciones relevantes del negocio. Se asemeja a un mapa conceptual que describe la realidad del negocio en términos de entidades, atributos y relaciones. Su objetivo principal es comprender la naturaleza de la información y plasmarla en un lenguaje comprensible para las partes interesadas del proyecto.  2. El modelo lógico: un puente hacia la implementación El modelo lógico da un paso hacia la concreción. Tomando como base el modelo conceptual, define «cómo» se organizará la información de forma independiente de la tecnología específica que se utilizará. En este modelo se establecen las estructuras de datos, las reglas de negocio y las relaciones entre las entidades. Es un puente entre la visión conceptual y la implementación física, permitiendo a los técnicos comprender cómo se implementará la información en el sistema.  3. El modelo físico: la materialización de la información El modelo físico es la última etapa del modelado y se centra en el «cómo» de la implementación. Define cómo se almacenará la información en la base de datos, utilizando las características específicas del SGBD elegido. Se establecen detalles como los tipos de datos, las longitudes de los campos, las claves primarias y secundarias, entre otros aspectos. El modelo físico es la materialización de la información en la base de datos, lista para ser utilizada por el sistema. Un trabajo en equipo  Un trabajo en equipo La creación de los tres modelos no es un proceso aislado, sino que se realiza de forma secuencial y colaborativa. El modelo conceptual es la base sobre la que se construye el modelo lógico, y este a su vez define el modelo físico. Cada modelo aporta un nivel de detalle adicional y permite a los diferentes actores del proyecto trabajar en conjunto, desde las partes interesadas hasta los desarrolladores.  Beneficios de un modelado sólido Un modelado de datos bien realizado ofrece una serie de beneficios: Mejora la comunicación entre los diferentes actores del proyecto. Facilita la comprensión de la estructura de la información. Aumenta la calidad del sistema al reducir errores y redundancia. Agiliza el desarrollo al proporcionar una guía clara para la implementación. Reduce costes al evitar modificaciones costosas en etapas posteriores. Los modelos conceptual, lógico y físico son los tres pilares del modelado de datos. Cada uno aporta una perspectiva diferente y crucial para la construcción de un sistema de información robusto, eficiente y adaptado a las necesidades del negocio. La comprensión de estos tres modelos y su interrelación es fundamental para el éxito de cualquier proyecto de desarrollo.  Fases Principales del Diseño Como cada proceso, el diseño de base de datos está compuestos por distintas etapas secuenciales. Recopilación y análisis de requisitos Esta primera fase consiste en un paso previo obligatorio, para asegurarnos de que nuestra base de datos cumplirá con nuestros objetivos. Para ello, deberemos analizar distintos factores, entre los cuales: Los datos que necesitamos almacenar y de dónde provienen. La información que los datos describen. Los usuarios de la base de datos y sus necesidades a la hora de acceder a los datos. Diseño conceptual En esta fase se representan una descripción a alto nivel del contenido de la base de datos, independientemente del sistema de gestión de base de datos que se utilizará a continuación. Se definen en un dibujo las entidades, sus atributos y las relaciones entre ellas.  Fases Principales del Diseño Elección de un sistema de gestión de base de datos Es en esta fase donde elegiremos el sistema de gestión de bases de datos (SGBD) concreto que mejor se adapta a nuestro proyecto, como, por ejemplo, Oracle, MySQL, Microsoft SQL Server y PostgreSQL. Diseño lógico En esta fase, se traduce el modelo conceptual obtenido anteriormente a un esquema lógico, que describe la estructura de la base de datos. Se trata de la fase en la cual se diseñan las tablas propiamente dichas, con sus filas, columnas y relaciones. El modelo lógico depende del SGBD que se utilizará. Diseño físico En esta fase se definen las estructuras de almacenamiento de la base de datos de forma física. Es cuando se escribe el código (por ejemplo, SQL) para concretar el diseño en el motor de base de datos que hemos escogido. Implementación Finalmente, se crea y se compila el esquema de la base de datos, se generan los ficheros y las aplicaciones que implementan las transacciones.  Principios de diseño de base de datos Para que nuestra base de datos sea eficiente y responda a los requerimientos, es necesario seguir una serie de principios que deben guiar el proceso de diseño de base de datos. A continuación vamos a describir los principales: Organización eficiente de las tablas, las unidades fundamentales de la base de datos. Cada tabla se compone de filas, también llamadas registros, y columnas, conocidas como campos. En los campos debería almacenarse un solo tipo de información (parte lógica). También no deberían almacenarse datos que pueden ser obtenidos mediante cálculos sobre otros datos.  Principios de diseño de base de datos Diseño de las claves primarias y las claves externas. Las claves primarias (o PK), son columnas que identifican de forma única cada fila y permiten construir relaciones entre tablas. Las claves primarias nunca puede tener un valor nulo o duplicado. Por otro lado, las claves externas deben corresponder con las claves primarias de las tablas con la cual se relacionan. Diseño de las relaciones entre tablas, que pueden ser de uno a uno, de uno a muchos o de muchos a muchos. Las relaciones permiten organizar la información entre distintas tablas, optimizando el espacio disponible.  Principios de diseño de base de datos Normalización de la base de datos, que permite cumplir con los estándares de la industria. La normalización es necesaria si vamos a trabajar con una base de datos de tipo OLTP (Procesos de Transacciones en Línea) y las formas más comunes son: Primera forma normal: un solo valor para cada celda de una tabla. Segunda forma normal: los atributos deben depender de la clave primaria de la tabla. Tercera forma normal: cada columna que no contenga una clave tiene que ser independiente de las otras columnas.  Resumen de las diferencias Modelo de datos lógico Modelo de datos físico Base de datos dependiente de la No Sí plataforma Estructura de datos Entidades, atributos, PK y FK Tablas, filas, PK, FK y tipos de datos de bases de datos Características programáticas No Disparadores y procedimientos almacenados Objetivo Visualiza la lógica empresarial con Organiza la estructura de datos estructuras de datos para el diseño de bases de datos Creadores Analistas de negocios y arquitectos Desarrolladores de software, de datos programadores y administradores de bases de datos Complejidad Sencillo Complejo Cuándo utilizar Para entender los sistemas Para planificar, implementar y empresariales y las reglas de optimizar el almacenamiento de negocio datos al desarrollar aplicaciones  Creación de un modelo de datos lógico Siga estos pasos para crear un modelo de datos lógico: 1. Determine todas las entidades requeridas y sus atributos respectivos. 2. Elija las claves principales apropiadas como identificadores únicos para los grupos de atributos. 3. Normalice y desnormalice el modelo de datos de acuerdo con los requisitos operativos. 4. Establezca las relaciones entre las diferentes entidades comerciales del modelo de datos. 5. Valide las entidades de datos y sus relaciones para representar la lógica empresarial con precisión. Defina las relaciones entre entidades independientes. Algunas entidades están directamente asociadas entre sí y otras pueden vincularse a través de una entidad común. Se suele consultar a las respectivas partes interesadas para garantizar que las entidades estén conectadas correctamente de acuerdo con los requisitos empresariales. También puede duplicar algunas entidades y limitar estratégicamente otras a una sola instancia para mejorar la eficiencia de las consultas y minimizar el espacio de almacenamiento.  Creación de un modelo de datos físico Siga estos pasos para diseñar un modelo de datos físico: 1. Ajuste el modelo de datos local a la plataforma del proveedor de bases de datos elegido. 2. Asigne las entidades de datos a sus tablas respectivas. 3. Asigne y cree las claves primarias y externas en las tablas de la base de datos según sea necesario. 4. Verifique que la estructura de la base de datos esté correctamente normalizada para eliminar los datos redundantes y mejorar la integridad de los datos. 5. Agregue restricciones, reglas, particiones y características programáticas relevantes a la base de datos para respaldar el desarrollo de aplicaciones. 6. Compare el modelo de datos físico con el modelo de datos lógico para garantizar que los requisitos empresariales se entiendan correctamente. En algunos casos, una entidad se divide en varias tablas. Cada tabla contiene varias columnas que almacenan la información especificada por los atributos del modelo de datos lógico. En un modelo de datos físico, las columnas se diferencian por sus tipos de datos, como números enteros, varchar y booleanos.  Representación de un modelo de datos lógico Con un modelo de datos lógico, los analistas de negocios y los arquitectos de datos pueden visualizar los procesos operativos o transaccionales en un diagrama de relaciones entre entidades. Los modelos de datos lógicos definen cómo funcionan y realizan transacciones los objetos de datos de manera que las partes interesadas de la empresa entiendan. Por lo tanto, se diseñan de forma independiente de la base de datos real en la que se implementan más adelante. El siguiente diagrama muestra un ejemplo de un modelo de datos lógico para un sistema de venta de entradas deportivas.  Representación de un modelo de datos físico Los modelos de datos físicos proporcionan información detallada que ayuda a los administradores y desarrolladores de bases de datos a implementar la lógica empresarial en una base de datos física. Estos modelos ofrecen atributos adicionales no especificados en un modelo de datos lógico, como disparadores, procedimientos almacenados y tipos de datos. Dado que asignan los elementos de datos a una base de datos real, los modelos de datos físicos deben cumplir con las restricciones específicas de la plataforma, como las convenciones de nomenclatura y el uso de palabras reservadas. El siguiente diagrama muestra un ejemplo del modelo de datos físico para el mismo sistema de venta de entradas para eventos deportivos. GRACIAS  Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Diseño Físico de Datos -Alm a c e na m ie nto-.  SGBD El paso de un diseño lógico a físico requiere un conocimiento profundo del SGBD donde se vaya a implementar la base de datos. En particular, entre otros, se deberá tener un conocimiento de los siguientes elementos: Soporte ofrecido a la integridad referencial Tipos de índices disponibles Tipos de datos disponibles Tipos de restricciones de integridad disponibles Parámetros de configuración que puedan afectar al rendimiento, como por ejemplo el tamaño de página y la gestión de datos y de concurrencia utilizados Construcciones SQL disponibles de soporte al diseño físico Particularidades del SGBD utilizado (y en consecuencia del lenguaje SQL) en relación a la definición de elementos relacionados con el diseño físico de la base de datos  Entorno de almacenamiento No es lo mismo almacenar la base de datos en un PC, que en un servidor con múltiples discos u otros dispositivos de almacenamiento no volátiles, que en un sistema distribuido. El hardware disponible y sus capacidades (velocidad de acceso, sistemas de replicación, etc.) permitirán definir distintas configuraciones físicas para mejorar el rendimiento de la base de datos.  Almacenamiento y Explotación de datos Que permita el almacenamiento y explotación de los datos con un rendimiento adecuado: el objetivo del diseño físico es obtener un buen rendimiento de la base de datos en un entorno real. Con rendimiento nos referimos básicamente al tiempo de respuesta a operaciones de consulta o actualización, a la carga de transacciones a procesar y a la disponibilidad de la base de datos.  Elementos de diseño físico Los elementos ofrecidos por el SGBD para afinar el modelo físico de la base de datos son principalmente los siguientes: Espacios para tablas Índices Vistas materializadas Particiones  Espacios para tablas Un espacio para tablas, tablespace en inglés, es un componente del SGBD que indica dónde se almacenarán los datos de la base de datos y en qué formato. El espacio para tablas permite asociar un archivo físico a un conjunto de elementos de la base de datos (tablas, índices, etc.). Dicho archivo contendrá los datos correspondientes a los elementos de la base de datos asociados. El número de espacios para tablas a crear en una base de datos dependerá de las necesidades del diseño físico. Los espacios para tablas podrán ser simples cuando afecten a un solo elemento de la base de datos, o compuestos cuando afecten a distintos elementos de la base de datos. Además de indicar el fichero donde se almacenarán los datos, los espacios para tablas también permiten definir cómo será dicho archivo: espacio asignado inicialmente, espacio incremental cuando el espacio asignado se agota, memoria intermedia disponible, si se utilizarán técnicas de compresión al almacenar los datos, cómo gestionar el espacio libre del fichero, etc.  Índices Los índices son estructuras de datos que permiten mejorar el tiempo de respuesta de las consultas sobre los datos de una tabla. De manera intuitiva, se puede establecer un paralelismo entre los índices usados en una base de datos con los índices de conceptos clave que podemos encontrar en la mayoría de libros de texto. La idea es organizar (de manera alfabética en el caso del índice del libro) una serie de valores de interés (los conceptos clave elegidos en el caso del libro), conjuntamente con las páginas físicas (las páginas del libro) que contienen datos sobre el valor que está siendo indexado (en el caso del libro, se indican las páginas del libro que tratan sobre cada concepto clave que se decide indexar).  Índices Los índices mantienen los valores de una o más columnas de una tabla en una estructura que permite el acceso a las filas de la tabla. Cada posible valor v tiene correspondencia con la dirección (o direcciones) física que contiene las filas de la tabla que tienen a v como valor de la columna indexada. Esta estructuración de los datos permite un acceso rápido a los datos cuando se realizan búsquedas por valor o cuando se requiere la ordenación de las filas de una tabla de acuerdo a los valores de la columna indexada. En caso de no disponer de índices, cualquier consulta sobre una tabla de la base de datos requerirá, en el caso peor, un recorrido completo del contenido de la tabla.  Índices Los índices se pueden utilizar también como sistema de control de las restricciones de integridad de unicidad (claves primarias y alternativas), definiendo un índice único sobre las columnas con dicha restricción. De manera similar, también sirven para garantizar las restricciones asociadas a las claves foráneas. A pesar de que el uso de índices mejora el rendimiento de la consulta de datos de una base de datos, es necesario tener en cuenta que tienen asociado un coste de mantenimiento ante cambios en los datos. En consecuencia, es necesario estudiar cuidadosamente cuántos y qué índices crear.  Índices Existen distintos tipos de índice, como por ejemplo, los índices basados en árboles B+, en mapas de bits, en técnicas de dispersión (hash en inglés), en árboles R, etc. El índice más utilizado es el basado en árboles B+, ya que funciona relativamente bien en todo tipo de situaciones. No obstante, no hay un índice universal que funcione bien en todos los casos. En función de cada caso se deberá escoger entre un tipo de índice u otro, y con una configuración adecuada  Vistas materializadas Los resultados de las consultas sobre una o más tablas se pueden almacenar en vistas materializadas. A diferencia de las vistas convencionales, el conjunto de filas que conforma el contenido de una vista materializada se almacena físicamente en la base de datos, como las filas que conforman el contenido de una tabla. Este tipo de vistas pueden ser muy útiles para mejorar el rendimiento de consultas que se ejecutan repetidamente o de consultas basadas en datos agregados. En ambos casos, el uso de una vista materializada permite calcular la información a priori, ahorrándonos así calcular el contenido asociado a la vista (o a parte de ella) cada vez que el usuario lo solicite.  Vistas materializadas El tiempo de respuesta de la base de datos puede disminuir significativamente cuando se implementan las vistas materializadas adecuadas. No obstante, en su definición es necesario tener en cuenta sus costes: requiere espacio extra para almacenar el contenido asociado a las vistas materializadas y requiere mantener actualizado su contenido. Este último hecho, por ejemplo, desaconseja el uso de las vistas materializadas en casos donde los datos de origen tengan una frecuencia de actualización alta.  Particiones Las particiones permiten distribuir los datos de una tabla en distintos espacios físicos. Las particiones se pueden hacer de acuerdo a multitud de criterios: distribuyendo las filas de la tabla en función de los valores de una columna, o de un conjunto de ellas (fragmentación horizontal), distribuyendo los datos de las filas de una tabla entre distintos espacios en función de las columnas a las que pertenecen (fragmentación vertical), e incluso agrupando datos con características comunes, como es el caso de la distribución de los datos agrupados por dimensiones en los Data Warehouse.  Particiones Un buen diseño de las particiones permite reducir la carga de trabajo de los componentes hardware del sistema. Los motivos son que el particionamiento de tablas facilita que diferentes transacciones se ejecuten concurrentemente, incrementando así el rendimiento del SGBD y que las consultas a tablas de gran tamaño se puedan resolver mediante consultas más simples que se ejecutan de forma concurrente. Adicionalmente, en el caso de que la base de datos esté distribuida, el particionamiento permite acercar y adecuar los datos a las necesidades de los usuarios/aplicaciones, fomentando el paralelismo y disminuyendo el tráfico de datos a través de la red de comunicaciones. También permite distribuir los datos en dispositivos de almacenamiento más o menos rápidos según la importancia de los datos.  Componentes de almacenaje de una base de datos Antes de poder abordar el diseño físico de una base de datos es importante conocer cómo almacena y gestiona los datos un SGBD. La siguiente figura muestra, de forma simplificada, la arquitectura de almacenaje que utiliza. Componentes de almacenaje de una base de datos  Componentes de almacenaje de una base de datos Tal y como se puede ver en la figura, el almacenaje de datos persistentes en una base de datos se realiza en una arquitectura de tres niveles: Nivel lógico: son los elementos de la base de datos con los que trabaja el usuario: tablas, vistas, índices, restricciones de integridad, etc. Nivel físico: son las estructuras de datos utilizadas para almacenar los datos de la base de datos en dispositivos no volátiles. Este nivel incluirá los ficheros, las extensiones y las páginas. Nivel virtual: es un nivel intermedio entre los niveles físico y lógico que proporciona al SGBD una visión simplificada del nivel físico. Esto facilita el diseño físico de la base de datos. Desde un punto de vista teórico, en el modelo relacional, los datos se almacenan en relaciones, que normalmente corresponden a conceptos del dominio de interés.  Componentes de almacenaje de una base de datos Cada relación contiene tuplas, que se corresponden a las instancias (u ocurrencias) de un concepto. Las tuplas están compuestas por atributos, que son los que permiten representar las características (o propiedades) de los conceptos. Al implementar el modelo anterior en un SGBD relacional, las relaciones se representan mediante tablas, que contienen distintas filas, que corresponden a las tuplas de la relación. Cada tabla tiene un conjunto de columnas, que representan a los atributos del concepto a representar. Al implementar las tablas en ficheros, las filas se representan mediante registros y las columnas mediante campos. La siguiente tabla muestra un resumen de esta nomenclatura y la relación entre términos. Componentes de almacenaje de una base de datos  Nivel físico Los datos se almacenan en soportes no volátiles controlados por el sistema operativo (SO) de la máquina donde se alojan. Es el SO el encargado de efectuar las operaciones de lectura y escritura física de los datos. Los SGBD aprovechan las rutinas existentes de los SO para leer y escribir los datos de las bases de datos. Los SO gestionan los datos a partir de unas estructuras globales llamadas archivos. Normalmente el SO no reserva una gran cantidad de espacio destinada a satisfacer todas las necesidades futuras de almacenamiento en el dispositivo de almacenamiento no volátil, sino que realiza una asignación inicial y va adquiriendo más espacio a medida que lo necesita. La unidad de adquisición se denomina extensión. Una extensión es una agrupación de páginas consecutivas en el dispositivo de almacenamiento no volátil. A su vez, las páginas son el componente físico más pequeño. Las páginas son los elementos que finalmente contienen y almacenan los datos del nivel lógico.  Nivel físico La página es el componente más importante del nivel físico ya que es la unidad mínima de acceso y de transporte del sistema de entrada y salida (E/S) de un SGBD. Eso quiere decir que: La página es la unidad mínima de transferencia entre la memoria externa (no volátil) y la memoria interna (o memoria principal). En los SGBD el espacio en el dispositivo de almacenamiento no volátil siempre se asigna en un número múltiplo de páginas. Cada página puede ser direccionada individualmente.  Nivel virtual En este punto nos podríamos preguntar: ¿es realmente necesario el nivel virtual en una base de datos? ¿Qué proporciona realmente este nivel? En una primera aproximación podríamos pensar que cada tabla se almacena en un fichero, y que cada fichero solo almacena datos de una tabla. Es decir, podríamos pensar que siempre existe una relación biunívoca entre tabla y archivo, con lo cual desaparecería la necesidad de un nivel intermedio que haga corresponder componentes lógicos con componentes físicos, ya que dicha correspondencia sería fija.  Espacio para tablas Los espacios para tablas (tablespace en inglés) permiten definir dónde se almacenarán los datos de los objetos de la base de datos. Una vez creado, un tablespace puede referenciarse por su nombre cuando se crea un nuevo objeto en la base de datos.  Espacio para tablas El uso de los tablespaces permite un mayor control sobre cómo se distribuirán los datos de la base de datos en los dispositivos de almacenamiento no volátil disponibles (por lo general, discos). Facilitan en gran medida la redistribución de los datos de la base de datos en caso de necesidad, como por ejemplo, cuando un tablespace se ubica en un disco que está a punto de llenarse. En este caso, se podría fácilmente cambiar la ubicación de los objetos del tablespace simplemente asignando una nueva ubicación física al mismo. Aparte, los tablespaces nos permiten distribuir fácilmente los distintos objetos de la base de datos en distintos discos para mejorar el rendimiento. Así pues, podríamos ubicar los datos de un índice que se utilice frecuentemente en un disco de alta velocidad (como por ejemplo en un disco de estado sólido) para acelerar su acceso. Por otro lado, podríamos ubicar las tablas que no se usen muy frecuentemente en un disco más lento. GRACIAS  Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Diseño Físico de Datos -Índices-.  Índices Los índices son estructuras de datos que permiten mejorar el tiempo de respuesta de las consultas sobre los datos de una tabla. El índice de una base de datos es una estructura de datos que mejora la velocidad de las operaciones, por medio de un identificador único de cada fila de una tabla, permitiendo un rápido acceso a los registros de una tabla en una base de datos.  Índices De manera intuitiva, se puede establecer un paralelismo entre los índices usados en una base de datos con los índices de conceptos clave que podemos encontrar en la mayoría de libros de texto. La idea es organizar (de manera alfabética en el caso del índice del libro) una serie de valores de interés (los conceptos clave elegidos en el caso del libro), conjuntamente con las páginas físicas (las páginas del libro) que contienen datos sobre el valor que está siendo indexado (en el caso del libro, se indican las páginas del libro que tratan sobre cada concepto clave que se decide indexar). Los índices mantienen los valores de una o más columnas de una tabla en una estructura que permite el acceso a las filas de la tabla.  Indices Cada posible valor v tiene correspondencia con la dirección (o direcciones) física que contiene las filas de la tabla que tienen a v como valor de la columna indexada. Esta estructuración de los datos permite un acceso rápido a los datos cuando se realizan búsquedas por valor o cuando se requiere la ordenación de las filas de una tabla de acuerdo a los valores de la columna indexada. En caso de no disponer de índices, cualquier consulta sobre una tabla de la base de datos requerirá, en el caso peor, un recorrido completo del contenido de la tabla.  Índices Los índices se pueden utilizar también como sistema de control de las restricciones de integridad de unicidad (claves primarias y alternativas), definiendo un índice único sobre las columnas con dicha restricción. De manera similar, también sirven para garantizar las restricciones asociadas a las claves foráneas. A pesar de que el uso de índices mejora el rendimiento de la consulta de datos de una base de datos, es necesario tener en cuenta que tienen asociado un coste de mantenimiento ante cambios en los datos.  Tipos de índices según funcionalidad Hay distintos tipos de índices, a saber: 1) "primary key": es el que definimos como clave primaria. Los valores indexados deben ser únicos y además no pueden ser nulos. Una tabla solamente puede tener una clave primaria. 2) "index": crea un índice común, los valores no necesariamente son únicos y aceptan valores "null". Podemos darle un nombre, si no se lo damos, se coloca uno por defecto. "key" es sinónimo de "index". Puede haber varios por tabla. 3) "unique": crea un índice para los cuales los valores deben ser únicos y diferentes, aparece un mensaje de error si intentamos agregar un registro con un valor ya existente. Permite valores nulos y pueden definirse varios por tabla. Podemos darle un nombre, si no se lo damos, se coloca uno por defecto.  Tipos de Índices según uso Los índices son estructuras de datos que facilitan la búsqueda y el acceso a la información almacenada en una base de datos. Existen diferentes tipos de índices, cada uno con sus propias características y casos de uso. A continuación, se presentan algunos de los tipos de índices más comunes y cómo pueden mejorar el rendimiento de las aplicaciones de bases de datos:  1. Índice único Un índice único es un índice que garantiza que cada valor en una columna (o conjunto de columnas) sea único. Este tipo de índice es útil para mejorar la integridad de los datos, ya que evita que se inserten registros duplicados en la base de datos. Los índices únicos también pueden mejorar el rendimiento de las consultas al buscar información específica, puesto que el motor de la base de datos sabe que solo existe un registro que coincide con el valor buscado.  2. Índice compuesto Un índice compuesto es un índice que incluye múltiples columnas de una tabla. Este tipo de índice es especialmente útil cuando se realizan consultas que implican condiciones en varias columnas. Al utilizar un índice compuesto, el motor de la base de datos puede encontrar registros que coinciden con todas las condiciones de búsqueda de manera más eficiente, lo que reduce el tiempo necesario para recuperar la información.  3. Índice de texto completo Un índice de texto completo es un índice diseñado para mejorar el rendimiento de las consultas de búsqueda de texto. Este tipo de índice es especialmente útil en aplicaciones que requieren búsquedas de palabras clave o frases en grandes cantidades de texto, como motores de búsqueda o sistemas de gestión de documentos. Los índices de texto completo permiten que las consultas de búsqueda se ejecuten de manera rápida y eficiente, lo que mejora la experiencia del usuario y reduce la carga en el servidor de la base de datos.  4. Índice espacial Un índice espacial es un tipo de índice diseñado para mejorar el rendimiento de las consultas que involucran datos geográficos o espaciales. Este tipo de índice es común en aplicaciones de sistemas de información geográfica (GIS) y en aplicaciones que requieren búsquedas basadas en la ubicación. Los índices espaciales permiten que las consultas espaciales, como la búsqueda de puntos dentro de un área determinada o la búsqueda de la distancia entre dos puntos, se realicen de manera rápida y eficiente.  5. Índice de mapa de bits Un índice de mapa de bits es un tipo de índice que utiliza una estructura de datos compacta, llamada mapa de bits, para representar la información sobre la presencia o ausencia de valores específicos en una columna. Los índices de mapa de bits son especialmente útiles en columnas con un número limitado de valores distintos, como columnas booleanas o de categoría. Este tipo de índice puede mejorar significativamente el rendimiento de las consultas que involucran filtros o agregaciones en columnas con baja cardinalidad. Los índices son una herramienta esencial para optimizar el rendimiento de las aplicaciones de bases de datos y garantizar una rápida recuperación de la información. Al elegir el tipo de índice adecuado para cada caso de uso, los desarrolladores pueden reducir el tiempo de las consultas y mejorar la experiencia del usuario. Además, el uso de índices también puede mejorar la integridad y consistencia de los datos en la base de datos, lo que es crucial para el éxito de cualquier proyecto de desarrollo de software.  ¿Cuándo debemos usar los índices? El uso de los índices de tablas en bases de datos no siempre es la mejor opción para todas las situaciones, sino que hay que saber muy bien cuándo crearlos. Algunos escenarios donde los índices pueden ser útiles: Cuando tenemos consultas que devuelven un pequeño porcentaje del total de datos. Un índice puede localizar rápidamente las filas con los valores que estás buscando. Cuando ejecutamos regularmente operaciones de JOIN en varias tablas. Los índices sobre las columnas utilizadas en la condición JOIN pueden acelerar estas operaciones.  ¿Cuándo debemos usar los índices? Pero ¿qué sucede si abusamos de los índices de tablas en bases de datos? Siempre debemos recordar que los índices también consumen recursos, tanto de almacenamiento como de procesamiento. Cada vez que se insertan, actualizan o eliminan datos en la tabla, los índices correspondientes también deben actualizarse. Por tanto, si tenemos una base de datos con cargas masivas de información, tener varios índices puede ralentizar estas operaciones.  Plan de ejecución El plan de ejecución es una herramienta invaluable para entender cómo SQL Server ha interpretado tu consulta. Muestra cómo ha usado los índices en la consulta y si necesita hacer operaciones costosas, como los table scans. Si una consulta está tardando más de lo esperado, revisar el plan de ejecución puede darte pistas sobre dónde añadir o ajustar los índices. Trabajar con bases de datos y manejar correctamente un conjunto de datos puede parecer una tarea difícil, pero con las herramientas y conocimientos adecuados podemos dominarla. Y aunque los índices son solo una pequeña parte de la administración de una base de datos, son una parte esencial para garantizar su rendimiento óptimo.  Creación y eliminación de índices Crear índices de tablas en bases de datos es sencillo como utilizar la instrucción CREATE INDEX. Por ejemplo: CREATE INDEX idx_nombre ON series(nombre); Esto crea un índice en la columna nombre de la tabla series, que podría acelerar las consultas que buscan series por nombre. Pero, como hemos mencionado antes, no todos los índices de tablas en bases de datos son útiles todo el tiempo. Es posible que debamos eliminar los índices que ya no son necesarios o que están causando más daño que beneficio. Para esto, se usa la instrucción DROP INDEX.  Ejemplo Por ejemplo, para crear un índice sobre el atributo APELLIDO de la relación base EMPLEADO, podemos emitir el comando siguiente: El índice está en orden ascendente de los valores del atributo de indización. EMPLEADO NOMBREP INIC APELLIDO NSS FECHAN DIRECCION SEXO SALARIO NSSSUPER ND CREATE INDEX INDICE_APELLIDO ON EMPLEADO(APELLIDO)  Ejemplo También podemos crear un índice sobre una combinación de atributos. Por ejemplo, si queremos crear un índice basado en la combinación de NOMBREP, INIC y APELLIDO. APELLIDO se encontrará en orden ascendente y NOMBREP en orden descendente dentro del mismo valor de APELLIDO: EMPLEADO NOMBREP INIC APELLIDO NSS FECHAN DIRECCION SEXO SALARIO NSSSUPER ND CREATE INDEX INDICE_NOMBRES ON EMPLEADO(APELLIDO ASC, NOMBREP DESC, INIC)  Ventajas y Desventajas Ventajas Con los índices evitamos que la base de datos tenga que hacer lecturas secuenciales. Muy relacionado con el anterior… al evitar “escaneos completos de las tablas”, evitamos los siguientes problemas: Sobrecarga de CPU, sobrecarga de disco y concurrencia. Los índices nos permiten una mayor rapidez en la ejecución de las consultas tipo SELECT lo que sea WHERE. Los índices en vistas pueden mejorar de forma significativa el rendimiento si la vista contiene agregaciones, combinaciones de tabla o una mezcla de agregaciones y combinaciones.  Ventajas y Desventajas Desventajas Los índices también suponen una desventaja en tablas demasiado pequeñas puesto que no necesitaremos ganar tiempo en las consultas. Tampoco son muy aconsejables cuando pretendemos que la tabla sobre la que se aplica devuelva una gran cantidad de datos en cada consulta. Los índices son una desventaja en aquellas tablas en las que se utiliza frecuentemente operaciones de escritura (Insert, Delete, Update), esto es porque los índices se actualizan cada vez que se modifica una columna.  Consideraciones a tener en cuenta Hay que evitar crear demasiados índices en tablas que se actualizan con mucha frecuencia y procurar definirlos con el menor número de columnas posible. Es conveniente utilizar un número mayor de índices para mejorar el rendimiento de consultas en tablas con pocas necesidades de actualización, pero con grandes volúmenes de datos. Un gran número de índices contribuye a mejorar el rendimiento de las consultas que no modifican datos, como las instrucciones SELECT, ya que el [[optimizador de consultas]] dispone de más índices entre los que elegir para determinar el método de acceso más rápido. Se recomienda utilizar una longitud corta en la clave de los índices agrupados. Los índices agrupados también mejoran si se crean en columnas únicas o que no admitan valores NULL. Un índice único en lugar de un índice no único con la misma combinación de columnas proporciona información adicional al optimizador de consultas y, por tanto, resulta más útil. GRACIAS  Gestión de Indicadores de Rendimiento, Calidad y Seguridad de Base de Datos Diseño de Interfaces de usuario -Entornos y participantes-.  ¿Qué es la diseño de la interfaces gráficas? La interfaz gráfica de usuario, son todos los