martes, 20 de julio de 2021

 Cuando hablamos de switches de capa 2 y capa 3, en realidad nos referimos a las capas de un modelo de protocolo genérico: el modelo de interconexión de sistemas abiertos (OSI), el cual es comunmente utilizado para la descripción de las comunicaciones de red. La comunicación de datos entre redes diferentes no sería posible si no existiesen reglas compartidas para su transmisión y recepción. Estas reglas se conocen como protocolos, entre los cuales se distingue el Protocolo de control de transmisión (TCP)/Protocolo de internet (IP) por ser uno de los más utilizados. Este se usa popularmente en la descripción de la red y es más antiguo que el modelo OSI, ambos con muchas capas. A continuación explicaremos cuál es la diferencia entre ellos.

Capas del modelo OSI

El modelo OSI, de siete capas, es un modelo conceptual que caracteriza y estandariza la manera en la que los diferentes componentes de software y hardware involucrados en una comunicación de red deben dividir la mano de obra e interactuar entre sí. En la siguiente figura podrá ver los nombres y funciones básicas de cada una de las capas.

Los siete capas del modelo OSI

Capa 7: Capa de aplicación

La capa de aplicación del modelo OSI interactúa directamente con las aplicaciones de software para proporcionar funciones de comunicación según sea necesario, y es la más cercana a los usuarios finales. Las funciones de la capa de aplicación generalmente incluyen la verificación de la disponibilidad de los socios de comunicación y los recursos para respaldar cualquier transferencia de datos. Esta capa también define protocolos para aplicaciones finales, como sistema de nombres de dominio (DNS), protocolo de transferencia de archivos (FTP), protocolo de transferencia de hipertexto (HTTP), protocolo de acceso a mensajes de Internet (IMAP), protocolo de oficina postal (POP), transferencia de correo simple. Protocolo (SMTP), Protocolo simple de administración de red (SNMP) y Telnet (una emulación de terminal).

Capa 6: Capa de presentación

La capa de presentación verifica los datos para asegurarse de que sean compatibles con los recursos de comunicaciones. Traduce los datos a la forma que aceptan el nivel de aplicación y los niveles inferiores. La sexta capa también maneja cualquier formato de datos necesario o conversión de código, como convertir un archivo de texto codificado con código de intercambio decimal codificado en binario extendido (EBCDIC) en un archivo de texto codificado con código estándar americano para el intercambio de información (ASCII). También funciona para la compresión y el cifrado de datos. Por ejemplo, las videollamadas se comprimirán durante la transmisión para que se puedan transmitir más rápido y los datos se recuperarán en el lado receptor. Para los datos que tienen altos requisitos de seguridad, como un mensaje de texto que contiene su contraseña, se cifrarán en esta capa.

Capa 5: Capa de sesión

La capa de sesión controla los diálogos (conexiones) entre computadoras. Establece, gestiona, mantiene y, en última instancia, finaliza las conexiones entre la aplicación local y remota. El software de capa 5 también maneja las funciones de autenticación y autorización. También verifica que se entreguen los datos. La capa de sesión se implementa comúnmente de forma explícita en entornos de aplicaciones que utilizan llamadas a procedimientos remotos.

Capa 4: Capa de transporte

La capa de transporte proporciona las funciones y los medios para transferir secuencias de datos desde una fuente a un host de destino a través de una o más redes, mientras mantiene las funciones de calidad de servicio (QoS) y asegura la entrega completa de los datos. La integridad de los datos se puede garantizar mediante la corrección de errores y funciones similares. También puede proporcionar una función de control de flujo explícita. Aunque no se ajusta estrictamente al modelo OSI, TCP y los protocolos de datagramas de usuario (UDP) son protocolos esenciales en la capa 4.

Capa 3: Capa de red

La capa de red maneja el enrutamiento de paquetes a través de funciones de conmutación y direccionamiento lógico. Una red es un medio al que se pueden conectar muchos nodos. Cada nodo tiene una dirección. Cuando un nodo necesita transferir un mensaje a otros nodos, simplemente puede proporcionar el contenido del mensaje y la dirección del nodo de destino, luego la red encontrará la manera de entregar el mensaje al nodo de destino, posiblemente enrutando a través de otros nodos. Si el mensaje es demasiado largo, la red puede dividirlo en varios segmentos en un nodo, enviarlos por separado y volver a ensamblar los fragmentos en otro nodo.

Capa 2: Capa de enlace de datos

La capa de enlace de datos proporciona transferencia de nodo a nodo, un enlace entre dos nodos conectados directamente. Maneja el empaquetado y desempaquetado de datos en marcos. Define el protocolo para establecer y terminar una conexión entre dos dispositivos conectados físicamente, como el Protocolo punto a punto (PPP). La capa de enlace de datos generalmente se divide en dos subcapas: capa de control de acceso a medios (MAC) y capa de control de enlace lógico (LLC). La capa MAC es responsable de controlar cómo los dispositivos en una red obtienen acceso a un medio y permiso para transmitir datos. La capa LLC es responsable de identificar y encapsular los protocolos de la capa de red y controla la verificación de errores y la sincronización de tramas.

Capa 1: Capa física

La capa física define las especificaciones eléctricas y físicas de la conexión de datos. Por ejemplo, la disposición de las clavijas del conector, los voltajes de funcionamiento de un cable eléctrico, las especificaciones del cable de fibra óptica y la frecuencia de los dispositivos inalámbricos. Es responsable de la transmisión y recepción de datos brutos no estructurados en un medio físico. El control de la tasa de bits se realiza en la capa física. Es la capa del equipo de red de bajo nivel y nunca se ocupa de los protocolos u otros elementos de la capa superior.

Capas del modelo TCP/IP

El modelo TCP/IP solamente tiene cuatro capas y es conocido generalmente como TCP/IP, ya que estos son sus dos protocolos más importantes.

Capa de aplicación

La capa de aplicación del modelo TCP/IP ofrece a las aplicaciones la capacidad de acceder a los servicios de las otras capas y define los protocolos que utilizan las aplicaciones para intercambiar datos. Los protocolos de la capa de aplicación más conocidos son HTTP, FTP, SMTP, Telnet, DNS, SNMP y el Protocolo de información de enrutamiento (RIP).

Capa de transporte

La capa de transporte se encarga de proporcionar comunicación de sesión y datagrama a la capa de aplicación de servicios . Los protocolos principales de esta capa son TCP y UDP. TCP proporciona un servicio de comunicaciones individual, fiable y orientado a la conexión. Es responsable de la secuenciación y detección de los paquetes enviados y de la recuperación de los paquetes perdidos en la transmisión. UDP proporciona un servicio de comunicaciones individual o grupal, sin conexión y poco fiable. Este se utiliza normalmente cuando la cantidad de datos a transferir es pequeña, como por ejemplo cuando estos caben en un solo paquete.

Capa de red

La capa de red es responsable de las funciones de direccionamiento, empaquetado y enrutamiento del host. Los protocolos centrales de la capa de Internet son IP, Protocolo de resolución de direcciones (ARP), Protocolo de mensajes de control de Internet (ICMP) y Protocolo de administración de grupos de Internet (IGMP). En esta capa, el IP agrega la cabecera a los paquetes, lo que se conoce como dirección IP. En la actualidad existen tanto dirección IPv4 (32 bits) como dirección IP IPv6 (128 bits). Más información: ¿Cómo podemos entender lo que significa la dirección IP y la máscara de subred?

Direcciones IPv4 y IPv6

Capa de acceso a la red

La capa de acceso a la red (o capa de enlace) es responsable de colocar los paquetes TCP/IP en el portador de datos de la red y recibir los paquetes TCP/IP situados fuera del mismo. El protocolo TCP/IP está diseñado para ser independiente del método de acceso a la red, el formato de la trama de red y el potador. En otras palabras, este protocolo es independiente de cualquier tecnología de red específica, lo que hace que este se pueda utilizar para conectar diferentes tipos de red, como Ethernet, Token Ring y Modo de transferencia asíncrono (ATM).

¿Cómo se procesan los datos durante la transmisión?


En un sistema de capas, los dispositivos de una capa intercambian datos en un formato diferente, lo que se conoce como unidad de datos de protocolo (PDU). La siguiente tabla muestra las PDU en las diferentes capas.

Tipo de modeloCapas del modelo OSIProtocolo Unidad de datos (PDU)Capas del modelo TCP/IP
Capas del hostCapa de aplicaciónDatosCapa de aplicación de datos
Capa de presentación


Capa de sesión


Capa de transporteSegmento de capa de transporte(TCP)/Datagrama (UDP)Capa de transporte
Capas de mediosCapa de redPaqueteCapa de Internet
Capa de enlace de datosTramaCapa de acceso a la red
Capa físicaBit

Por ejemplo, cuando un usuario solicita navegar por un sitio web en su ordenador, el software del servidor remoto primero entrega los datos solicitados a la capa de aplicación, donde se procesa de capa a capa con cada capa realizando sus funciones designadas. Los datos posteriormente se transmiten a través de la capa física de la red hasta ser recibidos por el servidor de destino u otro dispositivo. En este punto, los datos pasan nuevamente a través de las capas, cada capa realiza sus operaciones asignadas hasta que finalmente el software receptor utilice los datos.

Durante la transmisión, cada capa agrega una cabecera, pie de página o ambos a la PDU proveniente de la capa superior, el cual dirige e identifica el paquete. Este proceso se llama encapsulación. La cabecera (y el pie de página) y el cuerpo forman la PDU para la siguiente capa. El proceso continúa hasta llegar a la capa de nivel más bajo (capa física o capa de acceso a la red), desde la cual los datos se transmiten al dispositivo receptor. El dispositivo receptor invierte el proceso, desencapsulando los datos en cada capa con la información de la cabecera y pie de página que dirige las operaciones. Finalmente la aplicación utiliza los datos y el proceso continúa hasta que todos los datos son transmitidos y recibidos.

Gracias a que se conoce el funcionamiento de la división de capas, es posible diagnosticar el problema cuando una conexión falla . La clave es comprobar el funcionamiento desde el nivel más bajo, en lugar de desde el nivel más alto, ya que cada capa atiende a su capa immediatamente superior, por lo que será más fácil tratar los problemas de la capa inferior. Por ejemplo, si su ordenador no puede conectarse a Internet, lo primero que debe hacer es verificar si el cable de red está conectado al mismo o si el punto de acceso inalámbrico (WAP) está conectado al switch.

Las diferencias entre modelo OSI y modelo TCP/IP

La capa de aplicación del modelo TCP/IP es similar a las capas 5, 6, 7 combinadas del modelo OSI, el modelo TCP/IP no tiene una capa de sesión. La capa de transporte de TCP/IP abarca las responsabilidades de la capa de transporte OSI y algunas de las responsabilidades de la capa de sesión OSI. La capa de acceso a la red del modelo TCP/IP abarca el enlace de datos y las capas físicas del modelo OSI.

Las diferencias entre el modelo OSI y el modelo TCP/IP

Considerando los significados de los dos modelos de referencia, el modelo OSI es solo un modelo conceptual. Se utiliza principalmente para describir, discutir y comprender funciones de red individuales. Sin embargo, TCP/IP está diseñado en primer lugar para resolver un conjunto específico de problemas, no para funcionar como una descripción de generación para todas las comunicaciones de red como modelo OSI. El modelo OSI es genérico, independiente del protocolo, pero la mayoría de los protocolos y sistemas se adhieren a él, mientras que el modelo TCP/IP se basa en protocolos estándar que Internet ha desarrollado. Otra cosa que debe tenerse en cuenta en el modelo OSI es que no todas las capas se utilizan en aplicaciones más simples. Si bien las capas 1, 2, 3 son obligatorias para cualquier comunicación de datos, la aplicación puede usar alguna capa de interfaz única para la aplicación en lugar de las capas superiores habituales en el modelo.

Importancia de TCP/IP y OSI para la resolución de problemas

Si tenemos en cuenta los significados de los dos modelos de referencia, el modelo OSI sería solo un modelo conceptual; este se utiliza principalmente para describir, discutir y comprender funciones de red individuales. Sin embargo, TCP/IP está diseñado para resolver un conjunto específico de problemas y no para funcionar como una descripción de generación para todas las comunicaciones de red, tal y como lo hace el modelo OSI. El modelo OSI es genérico e independiente del protocolo, aunque la mayoría de los protocolos y sistemas se adaptan a él,; mientras que el modelo TCP/IP se basa en protocolos estándar desarrollados por Internet. Otro factor a tener en cuenta en el modelo OSI es que, para las aplicaciones más simples, no todas las capas son utilizadas. Si bien las capas 1, 2, 3 son obligatorias para cualquier comunicación de datos, también existen aplicaciones que pueden usar ciertas capas de interfaz expecíficas en lugar de las capas superiores habituales del modelo.

Resumen

El modelo TCP/IP y el modelo OSI son modelos conceptuales utilizados para la descripción de todas las comunicaciones de la red, a su vez, TCP/IP también es un protocolo importante que se utiliza en todas las operaciones de Internet. Generalmente, cuando hablamos de capa 2, capa 3 o capa 7 en las que funciona un dispositivo de red, nos referimos al modelo OSI. El modelo TCP/IP se usa tanto para modelar la arquitectura actual de Internet como para proporcionar un conjunto de reglas seguidas por todas las formas de transmisión a través de la red.




sábado, 17 de julio de 2021

 

Ingeniería de software



Es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad.

Esta ingeniería trata con áreas muy diversas de la informática y de las Ciencias de la Computación, tales como construcción de compiladores, Sistemas Operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Información y aplicables a infinidad de áreas (negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.).

Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

  • 1 - Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
  • 2 - Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976).
  • 3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
  • 4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U. S. Bureau of Labor Statistics) contó 760.840 ingenieros de software de computadora.[1] El término "ingeniero de software", sin embargo, se utiliza en forma genérica en el ambiente empresarial, y no todos los ingenieros de software poseen realmente títulos de Ingeniería de universidades reconocidas.

Algunos autores consideran que Desarrollo de Software es un término más apropiado que Ingeniería de Software (IS) para el proceso de crear software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el término IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos Ingeniería de Software o Ingeniería del Software. En hispanoamérica el término usado normalmente es el primero de ellos.

Implicaciones socioeconómicas

La ingeniería de software afecta a la economía y las sociedades de variadas formas.

Económicamente

En los EEUU, el software contribuyó a 1/4 de todo el incremento del PIB durante los 90's (alrededor de 90,000 millones de dólares por año), y 1/6 de todo el crecimiento de productividad durante los últimos años de la década (alrededor de 33,000 millones de dólares por año). La ingeniería de software contribuyó a $1 billón de crecimiento económico y productividad en esa década. Alrededor del globo, el software contribuye al crecimiento económico en formas similares, aunque es difícil de encontrar estadísticas fiables.

Socialmente

La ingeniería de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrónico (E-mail), la WWW y la mensajería instantánea permiten a la gente interactuar en nuevas formas. El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los proyectos exitosos donde se han usado métodos de ingeniería de software incluyen a Linux, el software del transbordador espacial, los cajeros automáticos y muchos otros.

La IS se puede considerar como la ingeniería aplicada al software, esto es, por medios sistematizados y con herramientas preestablecidas, la aplicación de ellos de la forma más eficiente para la obtención de resultados óptimos; objetivos que siempre busca la ingeniería. No es sólo de la resolución de problemas, sino más bien teniendo en cuenta las diferentes soluciones, elegir la más apropiada.

Metodología

Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.

Etapas del proceso

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:

Análisis de requisitos +

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de Requisitos.

La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification).

Especificación

Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las interfaces externas, que deben permanecer estables.

Diseño y arquitectura

Se refiere a determinar como funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.

Programación

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.

Modelos de desarrollo de software

La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

Naturaleza de la IS

La Ingeniería de Software tiene que ver con varios campos en diferentes formas:

Matemáticas

Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.

Creación

Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que encontramos en la IS.

Gestión de Proyectos

El software comercial (y mucho no comercial) requiere gestión de proyectos. Hay presupuestos y establecimiento de tiempos. Gente para liderar. Recursos (espacio de oficina, computadoras) por adquirir. Todo esto encaja apropiadamente con la visión de la Gestión de Proyectos.

Arte

Los programas contienen muchos elementos artísticos. Las interfaces de usuario, la codificación, etc. Incluso la decisión para un nombre de una variable o una clase. Donald Knuth es famoso porque ha argumentado que la programación es un arte.

Responsabilidad

La responsabilidad en la Ingeniería del Software es un concepto complejo, sobretodo porque al estar los sistemas informáticos fuertemente caracterizados por su complejidad, es difícil apreciar sus consecuencias.

En la Ingeniería del Software la responsabilidad será compartida por un grupo grande de personas, que comprende desde el ingeniero de requisitos, hasta el arquitecto software, y contando con el diseñador, o el encargado de realizar las pruebas. Por encima de todos ellos destaca el director del proyecto. El software demanda una clara distribución de la responsabilidad entre los diferentes roles que se dan en el proceso de producción.

El ingeniero del Sofware tiene una responsabilidad moral y legal limitada a las consecuencias directas.

 

Ciclo de vida del software

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

·         Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.

·         Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.

·         Diseño general: requisitos generales de la arquitectura de la aplicación.

·         Diseño en detalle: definición precisa de cada subconjunto de la aplicación.

·         Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.

·         Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.

·         Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.

·         Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.

·         Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.

·         Implementación

·         Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

Modelos de ciclo de vida

Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante).

Modelo en cascada

El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

Descripción: ciclo de vida en cascada

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.

Descripción: Ciclo de vida V

 

 

Métodos rápidos

"El desarrollo de software de "métodos rápidos" (también denominado Modelo rápido o abreviado AG) reduce el tiempo del ciclo de vida del software (por lo tanto, acelera el desarrollo) al desarrollar, en primera instancia, una versión prototipo y después integrar la funcionalidad de manera iterativa para satisfacer los requisitos del cliente y controlar todo el ciclo de desarrollo.

Los métodos rápidos se originaron por la inestabilidad del entorno técnico y el hecho de que el cliente a veces es incapaz de definir cada uno de los requisitos al inicio del proyecto. El término "rápido" es una referencia a la capacidad de adaptarse a los cambios de contexto y a los cambios de especificaciones que ocurren durante el proceso de desarrollo. Por lo tanto, en el año 2001, 17 personas redactaron el manifiesto ágil, en el que expresaron los siguientes puntos principales:

·         individuos e interacciones en lugar de procesos y herramientas

·         desarrollo de software en lugar de documentación exhaustiva

·         trabajo con el cliente en lugar de negociaciones contractuales

·         apertura para los cambios en lugar de cumplimiento de planes poco flexibles

Con la ayuda de los métodos rápidos, el cliente tiene control total de su proyecto y logra una rápida implementación del software. De esta forma, se permite al usuario involucrarse desde el inicio del proyecto.

RAD - Desarrollo rápido de aplicaciones

El Desarrollo rápido de aplicaciones (o RAD) definido por James Martin a principios de la década de 1980, consiste en un ciclo de desarrollo corto basado en tres fases (Requisitos, Diseño y Construcción) con un plazo de entrega ideal de 90 a 120 días como máximo.

DSDM

El DSDM (Método de Desarrollo de Sistema Dinámico) se desarrolló para completar lo que le faltaba al método RAD al proporcionar una estructura que tome en cuenta el ciclo de desarrollo completo.

Las características principales del método DSDM son las siguientes:

·         Participación del usuario

·         Desarrollo iterativo y creciente

·         Frecuencia de entrega mejorada

·         Pruebas integradas en cada fase

·         La aceptación de los productos entregados depende directamente del cumplimiento de los requisitos.

UP - Proceso unificado

El método proceso unificado (UP) es un proceso de desarrollo iterativo y creciente. Esto significa que el proyecto se divide en fases más cortas y que se envía una nueva versión gradual al final de cada fase.

Este enfoque está basado en el modelo UML para la descripción de la arquitectura del software (funcional, de aplicación y física) y para el desarrollo del caso del usuario. Dicho modelo describe los requisitos y las demandas del usuario.

RUP - Proceso unificado racional

RUP (Proceso unificado racional) es un método de desarrollo iterativo promovido por la compañía Rational Software, que fue comprada por IBM.

El método RUP especifica, principalmente, la constitución del equipo y las escalas de tiempo, así como un número de modelos de documento.

XP - Programación extrema

El método XP (Programación extrema) define un conjunto de prácticas óptimas para el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo una cercana relación con dicho cliente.

La Programación extrema se basa en los siguientes conceptos:

·         Los equipos de desarrollo trabajan directamente con el cliente durante ciclos cortos de una o dos semanas como máximo.

·         La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos para maximizar la interacción con el usuario.

·         Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja en el código.

·         El código se prueba y depura a lo largo del proceso de desarrollo.

·         Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de desarrollo.

·          

Para obtener más información:

·         http://www.agilealliance.com/

·         http://www.agilemodeling.com/

·         http://www.extremeprogramming.org/

·         http://www.rad.fr/

·         http://www.dsdm.org/