Ciclo de vida del desarrollo de software (SDLC).

El ciclo de vida del desarrollo de software tradicional(SDLC, por sus siglas en inglés) es el más utilizado para diseñar productos de software en tres partes principales: 

1. Análisis de requisitos 

2. Modelado de datos 

3. Normalización 

Durante la primera fase, el análisis de requisitos, el equipo de desarrollo y diseño lleva a cabo entrevistas con el fin de capturar todas las necesidades del negocio relacionadas con el sistema propuesto. La fase de modelado de datos consiste en la creación del modelo de datos lógico, que posteriormente se utilizará para definir el modelo de datos físico o las estructuras de la base de datos. Una vez que la base de datos ha sido modelada y diseñada, se implementa la fase de normalización para ayudar a eliminar o reducir tanto como sea posible cualquier dato redundante. A continuación, se presenta una descripción más específica de las actividades incluidas en el ciclo de desarrollo.

Desarrollo

El ciclo de vida del desarrollo incluye cuatro componentes generales. Desde esta perspectiva, el "desarrollo" consistiría en todos los pasos necesarios para llevar a cabo la creación de la aplicación.

Esto incluye la viabilidad, el análisis, el diseño y la codificación propiamente dicha. La viabilidad representa las tareas necesarias para determinar si el proyecto de desarrollo de software tiene sentido desde el punto de vista empresarial. La mayoría de las organizaciones integrarían el proceso de retorno sobre la inversión (ROI, por sus siglas en inglés) durante este paso.

El ROI consiste en los pasos financieros que determinan matemáticamente si el proyecto proporcionará los rendimientos monetarios necesarios para el negocio. Centrarse únicamente en los retornos monetarios puede ser una trampa grave, ya que hay muchos beneficios que pueden obtenerse a través de retornos no monetarios.

La viabilidad a menudo contiene lo que se conoce como un pronóstico o presupuesto de alto nivel. El "alto" representaría el "peor caso" en términos de costos y el "bajo", el mejor caso o el costo más bajo. La esperanza, por supuesto, es que el costo real y el cronograma queden en algún punto intermedio entre el alto y el bajo.

Pero la viabilidad va más allá del presupuesto; también representa si la empresa considera que el proyecto es alcanzable dentro de un cronograma específico. Por lo tanto, la viabilidad es una declaración tanto de los objetivos financieros como empresariales, y una creencia general de que el costo vale la recompensa.

 El análisis en el ciclo de vida del desarrollo de software

El análisis es el paso final para crear los requisitos lógicos detallados o la arquitectura de las aplicaciones y la base de datos. En última instancia, el analista crea un documento de requisitos que describe todas las necesidades para que los codificadores trabajen sin tener que regresar directamente a los usuarios en busca de aclaraciones.

El análisis, como responsabilidad arquitectónica en el ciclo de vida del desarrollo de software, se basa mucho en una progresión matemática de pasos predecibles. Estos pasos son bastante iterativos por naturaleza, lo que requiere que los profesionales comprendan la naturaleza gradual de la finalización de este paso vital en el desarrollo.

Otro aspecto de las matemáticas del análisis es la descomposición. La descomposición establece la creación de los componentes más pequeños que conforman el todo. Es como los huesos, la sangre y los músculos del cuerpo humano que, en última instancia, conforman lo que físicamente vemos en una persona.

Una vez que un sistema está descompuesto, el analista puede estar seguro de que las "partes" que componen el todo están identificadas y pueden reutilizarse en el sistema según sea necesario.

Estas partes descompuestas se denominan "objetos" y comprenden el estudio y la aplicación del análisis y diseño orientado a objetos. Por lo tanto, la base de trabajar con los usuarios lleva en última instancia a la creación de partes conocidas como objetos, que actúan como componentes intercambiables que pueden utilizarse cuando sea necesario.

Se puede pensar en los objetos, dentro del ciclo de vida del desarrollo de software, como en partes intercambiables de un automóvil. A veces se les llama "estándar", ya que pueden reutilizarse en múltiples modelos. Los beneficios son obvios. El mismo objetivo aplica al software: cuanto más reutilizable, más eficiente y rentable.

El diseño en el SDLC

El diseño es mucho menos lógico que el análisis, pero es un paso mucho más creativo. El diseño es la fase que requiere decisiones físicas sobre el sistema, desde qué lenguaje de programación utilizar, qué base de datos de proveedor seleccionar (por ejemplo, Oracle, Sybase, DB2), hasta cómo se identificarán las pantallas y los informes.

La fase de diseño también puede incluir decisiones sobre hardware y comunicaciones de red o la topología. A diferencia del análisis, el diseño requiere menos enfoque matemático e ingenieril, y más uno que realmente sirva a la perspectiva del usuario.

El proceso de diseño es quizás el más iterativo, lo que podría requerir múltiples sesiones con los usuarios mediante un enfoque de prueba y error hasta que se complete la interfaz de usuario correcta y la selección del producto.

El diseño a menudo requiere "expertos" en diseño de bases de datos, arquitectura de pantallas, así como profesionales que comprendan las necesidades de rendimiento de los servidores de red y otros componentes de hardware requeridos por el sistema.

Codificación

La codificación representa otro enfoque arquitectónico y matemático. Sin embargo, sugiero que las matemáticas no son la descripción más precisa de una estructura de codificación, sino que se trata más bien de entender cómo opera la lógica.

Esta componente de las matemáticas se conoce como "álgebra booleana" o las matemáticas de la lógica. El álgebra booleana es la base de cómo el software se comunica con la máquina real. El software es la abstracción física que nos permite interactuar con la máquina de hardware.

Entonces, la codificación es la mejor manera de desarrollar realmente la estructura del programa. Se ha escrito mucho sobre estilos y formatos de codificación. El más conocido se llama "programación estructurada". La programación estructurada fue desarrollada originalmente para que los programadores crearan código cohesivo, es decir, que fuera autosuficiente.

La autosuficiencia en la codificación significa que el programa es autocontenido porque toda la lógica relacionada con sus tareas está dentro del programa. Lo opuesto a la cohesión es el acoplamiento.

El acoplamiento es la lógica de los programas que dependen unos de otros, lo que significa que un cambio en un programa implica un cambio en otro. El acoplamiento se considera peligroso desde una perspectiva de mantenimiento y calidad, simplemente porque los cambios causan problemas en otros sistemas dependientes o "acoplados".

La relación entre la codificación y el análisis puede ser crítica, dado que la decisión sobre qué código conformará un módulo puede determinarse durante el análisis en lugar de durante la codificación.

Artículos relacionados Aquí Ciclo de vida del desarrollo de software (SDLC).

Resumen De Metodologías De Desarrollo De Software

Usar metodologías de desarrollo de software es muy similar a usar un libro de recetas de concina. Cualquiera que intente hacer un pastel simplemente adivinando la receta y el método descubrirá muy rápidamente que el resultado puede no ser un buen pastel. La mayoría de nosotros recurriremos a algún tipo de recetario. De la misma manera, al embarcarse en un proyecto de desarrollo de software, usar una metodología para proporcionar un marco y un sentido de dirección asegurará un mejor resultado.

ENFOQUES DE DESARROLLODE SOFTWARE

En el corazón de un nuevo proyecto de desarrollo de software está la necesidad de resolver un problema identificado. ¿Pero cuál es la mejor manera de abordarlo y comunicar ideas? 

Lamentablemente, no existe un único marco, metodología o técnica "que sirva para todo" que resuelva todos tus problemas — ¡eso sería demasiado fácil! Además, diferentes organizaciones adoptan métodos y tácticas distintas para resolver sus problemas. Sin embargo, hay un punto de partida razonable, y ese es el ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés).

El ciclo de vida del desarrollo de software

Las metodologías de desarrollo de software en general es seguir un proceso establecido con una serie de pasos definidos (y predecibles). Esto se conoce como el ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés). Por lo general, comienza con la identificación de un problema interno o una aspiración, a menudo en forma de un breve documento inicial. La revisión del producto al final del ciclo de vida puede desencadenar un nuevo desarrollo. 

El ciclo de vida contiene una serie de fases, cada una de las cuales contribuye con un proceso al desarrollo.

La duración de un SDLC varía enormemente dependiendo de las metodologías de desarrollo de software utilizadas, del tamaño y la complejidad del problema que intenta resolver. A pesar de esto, la duración de cada fase generalmente permanece proporcional: por ejemplo, la fase de codificación es más larga (potencialmente varios meses) en comparación con un período más corto de diseño y arquitectura (quizás varias semanas). 

Los componentes básicos del ciclo de vida (hasta el punto del lanzamiento) son los siguientes.

Documento inicial (Brief) 

Este desencadena el proceso de desarrollo. Puede basarse en un problema con un sistema o proceso existente, algo nuevo que sea necesario para cumplir con un requisito empresarial o simplemente una respuesta a una oportunidad emergente basada en una nueva idea. Puede surgir como resultado de la aspiración de una organización de brindar una mejor experiencia al cliente, mejorar sus procesos o reducir costos (¡o las tres cosas!).

Esta es una investigación de alto nivel sobre el documento inicial (brief), que en esencia considera el problema a resolver e investiga posibles soluciones. Estas soluciones pueden incluir:

• Una solución lista para usar: un producto o aplicación existente que se puede comprar y utilizar sin necesidad de modificaciones. 
• Una solución adaptada: se utiliza una aplicación genérica para construir una solución adecuada (como una hoja de cálculo o un paquete de bases de datos), o bien una solución lista para usar se adapta añadiendo funcionalidades adicionales para satisfacer las necesidades de la organización. 
• Una solución personalizada: una solución que se escribe desde cero, con un proceso completo de investigación, diseño, desarrollo y pruebas antes de su implementación. 
• Ningún cambio: hay ocasiones en las que los costos de un proyecto de desarrollo superarían ampliamente los beneficios organizacionales que se obtendrían. Esto a menudo se mide financieramente en términos del posible retorno de la inversión (ROI). El ROI se calcula para evaluar qué tan bien rendirá (o ha rendido) una inversión particular. Un ROI bajo sugeriría que el desarrollo de software podría no ser factible.

Análisis

Una vez que se ha establecido que es necesario un desarrollo, se lleva a cabo un análisis completo del problema y del sistema existente (y de cómo este podría contribuir a la solución). Esto se documenta para asegurar que las decisiones posteriores puedan justificarse.

Planificación

Esta es una parte formal y muy necesaria del proceso que a veces puede pasar por alto. Aquí se identifican las actividades y procesos esperados necesarios para lograr la solución, junto con los plazos previstos. Luego, se establecen y asignan los recursos disponibles a las tareas que deberán realizarse.

Diseño 

La finalización del análisis conduce al diseño del nuevo sistema. Esto puede o no estar documentado formalmente (dependiendo de la naturaleza del desarrollo y de la metodología utilizada para enfocar las actividades).

Desarrollo 

Esta fase implica la codificación real de la nueva solución, sistema o servicio.

Pruebas 

En el desarrollo de software pueden aplicarse diversas estrategias de prueba. Algunas se realizan durante el desarrollo, otras cuando el desarrollo se considera relativamente completo, y otras durante un período de pruebas finales antes de que el sistema desarrollado sea entregado al cliente.

Implementación/Puesta en marcha 

Una vez que el código ha pasado las pruebas, funcionará sin problemas en un entorno de prueba (staging) y estará listo para entrar en producción ("live"). En este punto, el sistema se implementa (instala y prepara) para ser utilizado por clientes internos y/o externos.

El cliente buscará el consejo de los desarrolladores en cuanto a las metodologías de desarrollo de software sobre la implementación del sistema para que pueda integrarse adecuadamente en el negocio (a menudo llamado "estrategia de cambio"). No hay una única respuesta correcta a la pregunta de cómo debe implementarse la solución, por lo que el equipo de desarrollo debe considerar las necesidades del cliente, los factores de riesgo y la cantidad de trabajo adicional que generará la actividad de implementación al dar sus recomendaciones.

Común a todas las estrategias de cambio es la necesidad de que los datos de la organización se agreguen al nuevo sistema para que, cuando entre en funcionamiento, tenga algo con qué trabajar. Esto puede requerir cambios en los datos para prepararlos para la integración, como convertir formatos de datos o reorganizar los datos para prepararlos para la transferencia. Los datos generalmente se migrarán al nuevo sistema en un momento en que las transacciones comerciales normales están suspendidas porque la organización está cerrada. Esto puede ser más desafiante si el negocio opera en línea.

Fuente original Aquí Resumen De Metodologías De Desarrollo De Software

Tipos de proyectos de desarrollo de software

Los proyectos de desarrollo de software (SDPs, por sus siglas en inglés) no son homogéneos. Vienen en varios tamaños y tipos. Algunos ejemplos nos ayudarán a comprender la amplitud de los SDPs:

• Una organización desea trasladar un proceso empresarial del procesamiento manual de información al procesamiento informático. Este proyecto incluirá el estudio de los requisitos del usuario y la realización de todas las actividades necesarias para implementar el sistema basado en computadora.
• Una organización desea trasladar un proceso empresarial del procesamiento manual de información al procesamiento informático. La organización no quiere que el software se desarrolle "desde cero". Quiere utilizar un producto de software comercial listo para usar (COTS, por sus siglas en inglés). Este proyecto incluirá la implementación y quizás alguna personalización del producto COTS para adaptarlo a las necesidades de la organización.
• Una organización tiene un sistema basado en computadora que necesita ser trasladado a otro sistema informático porque el sistema existente se ha vuelto obsoleto y ya no hay soporte disponible para mantenerlo en funcionamiento. Este proyecto podría incluir la migración del código, la capacitación de los usuarios y la prueba de la nueva implementación.
• Una organización tiene un sistema basado en computadora y desea trasladarlo de un sistema de archivos planos a un sistema basado en RDBMS (sistema de gestión de bases de datos relacionales). Las actividades incluirán la conversión de datos además de otras tareas.
• Una organización tiene un sistema de procesamiento de información basado en computadora y necesita realizar modificaciones en el software o agregar funcionalidades adicionales. Las actividades incluyen añadir funcionalidades y realizar las modificaciones necesarias en el software de un tercero (si es necesario).
• Una organización ha desarrollado un sistema de procesamiento de información basado en computadora y quiere que sea probado exhaustivamente por una organización independiente. Las actividades incluirán las pruebas y la interacción entre las organizaciones.

Estos ejemplos apenas rozan la superficie de la amplitud de los proyectos de software, y nuevos tipos de proyectos siguen apareciendo. Sin embargo, en todos los casos, los proyectos están relacionados con software, pero las tareas, actividades y, por lo tanto, el trabajo en cada uno de los proyectos son enormemente diferentes.

Clasificación de los tipos de proyecto 

Los proyectos de software pueden clasificarse de varias maneras. Por ejemplo, los proyectos de software pueden clasificarse como:

• Proyectos del ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés) 

  • Proyectos de ciclo de vida completo 
  • Proyectos de ciclo de vida parcial 

• Proyectos de desarrollo de software impulsados por enfoques 

  • Desarrollo “desde cero” (creación completa del software desde “cero”) 
  • Personalización/implementación de productos COTS (software comercial listo para usar) 
  • Portabilidad (Porting) 
  • Migración 
  • Conversión de software existente para cumplir con cambio de condiciones, como cuando se presentaron las conversiones al año 2000 (Y2K) y al euro respectivamente. 

• Proyectos de mantenimiento 

  • Reparación de defectos 
  • Expansión funcional 
  • Soporte operativo 
  • Corrección de comportamientos inusuales 
  • Modificación de software 

• Proyectos de aplicaciones web 
• Proyectos de desarrollo ágil

 Basado en el ciclo de vida del desarrollo de software

Software de ciclo de vida completo. Un proyecto de ciclo de vida completo es un proyecto que abarca todo el arco de la metodología que se está utilizando: comienza al inicio y termina al final. Un problema al discutir un proyecto de ciclo de vida completo es que no hay estandarización con respecto a qué constituye un ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés). Generalmente, se acepta que el análisis de los requisitos del usuario, el análisis de los requisitos del software, el diseño del software, la construcción y las pruebas (independientemente de cómo se llamen) son partes de un SDLC. Algunos de los componentes de un SDLC que aún están en debate incluyen:

• Un estudio de viabilidad que determine si el proyecto vale la pena.
• Pruebas especiales que van más allá de las pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación.
• Implementación, incluida la instalación de hardware, software del sistema, software de aplicación, etc.
• Puesta en marcha del software, incluida la creación de archivos maestros de datos, capacitación de usuarios, ejecuciones piloto, ejecuciones paralelas, etc.

En muchos casos, cuando el producto final se utiliza dentro de la misma organización, estos cuatro componentes se consideran parte del ciclo de vida del desarrollo de software (SDLC). Por otro lado, en otras circunstancias, estos componentes se excluyen para organizaciones que se especializan en el desarrollo de software y/o desarrollan software para ser utilizado por otra organización (a menos que se incluyan contractualmente o formen parte de una arquitectura de software como servicio).

Software de ciclo de vida parcial. Los proyectos de ciclo de vida parcial son aquellos que incluyen solo una parte del SDLC. En los proyectos de ciclo de vida parcial, pueden ocurrir diversas combinaciones, incluidas:

• Proyectos de pruebas en los que el alcance del trabajo consiste en realizar las pruebas especificadas o necesarias sobre el producto de software para certificar el producto. (Normalmente, las pruebas unitarias y las revisiones de código no están incluidas en este tipo de proyecto.)
• Proyectos de verificación y validación independientes (IV&V) en los que los proyectos van más allá de las simples pruebas, incluyendo revisiones de código y otras formas de validación para determinar la eficiencia de la codificación.
• Un proyecto dividido entre dos o más proveedores según la especialidad, para aprovechar las ventajas de las mejores prácticas desarrolladas a través de la especialización, lo que puede llevar a definir el proyecto por fases o por combinaciones de fases, como:

  • Análisis de requisitos 
  • Diseño 
  • Construcción del software 
  • Pruebas

Como se ha expuesto, los proyectos de desarrollo de software son diversos y pueden clasificarse según su enfoque, alcance y ciclo de vida. Cada tipo de proyecto implica tareas y actividades específicas, desde la creación de software desde cero hasta la personalización de productos comerciales, la migración de sistemas o el mantenimiento de software existente. Además, los proyectos pueden abarcar el ciclo de vida completo del desarrollo de software o solo una parte de él, dependiendo de los objetivos y necesidades de cada organización. Esta diversidad resalta la importancia de una planificación adecuada y de la selección de metodologías apropiadas para garantizar el éxito en la implementación y mantenimiento de los sistemas de software.

Artículos relacionados Aquí Tipos de proyectos de desarrollo de software

Desarrollo de software en proyectos complejos

En cuanto al desarrollo de software en proyectos complejos, la mayoría de los analistas, miembros del equipo y usuarios se preocupan por la complejidad de los mismos. Sus requisitos parecen completamente únicos para ellos, y por lo tanto parece que se requiere un enfoque muy especial. ¿Cuántas veces ha escuchado: "las herramientas y enfoques utilizados en otros lugares simplemente no funcionarán en este entorno"?

Sin embargo, la verdad es muy diferente: ¡los únicos proyectos de desarrollo de software verdaderamente complejos son aquellos que las personas hacen complejos! Es importante que el analista reconozca que los procedimientos utilizados, sin importar el tamaño del proyecto, deben permanecer fundamentalmente iguales.

El enfoque del analista para la implementación de cada proyecto debe adaptarse individualmente; sin embargo, los procedimientos para esta implementación deben permanecer constantes. Muy a menudo, la organización de entrevistas, la utilización de técnicas como el Desarrollo Conjunto de Aplicaciones (JAD), o la simple incorporación de más desarrolladores al proyecto pueden resolver problemas que parecen insuperables.

De hecho, la mayoría de los innumerables problemas que surgen en el desarrollo de software pueden atribuirse a dos cuestiones fundamentales: 

1. Las personas están tratando de resolver el problema equivocado, es decir, el problema identificado no es realmente lo que está mal. 

2. La solución al problema real suele ser mucho más sencilla de lo que parece a primera vista. 

Debido a que no hemos reconocido estos problemas, la frustración de la industria por desarrollar soluciones de software apropiadas ha sido crónica, y esta situación realmente no ha mejorado en los últimos 25 años. La pregunta es ¿por qué? 

Para ser directos, ¡los analistas de sistemas a menudo no hacen bien su trabajo! Tendemos a elaborar planes y cronogramas que están condenados al fracaso desde el principio.

El objetivo final del analista debe tener en cuenta la realidad del entorno en el que se realiza el trabajo. Recuerde, trabaja dentro del entorno. Deje que los usuarios decidan qué grado de cambio es apropiado para su propia operación; no le corresponde exigirles que cambien. 

Puede parecer atractivo, pero en realidad el plan de desarrollo de software que describe nunca podría llevarse a cabo. Enfóquese especialmente en la intersección entre el desarrollo de software y las actividades de aseguramiento de la calidad (QA). En un ejemplo de plan se podría especificar que una vez que se termina el desarrollo, los materiales se envían al equipo de QA para realizar pruebas. Sin embargo, esta secuencia asume que QA nunca encontrará un error y que, por lo tanto, los materiales nunca serán devueltos al equipo de desarrollo.

Cualquier analista sabe que este escenario es muy poco probable que ocurra. Una planificación tan deficiente provoca una asignación insuficiente de recursos al proyecto. Si se cumple con el cronograma de desarrollo, es muy probable que los recursos de programación se asignen a otros proyectos. Así, si QA encuentra errores (lo cual sin duda sucederá), reasignar estos recursos de programación se vuelve difícil y problemático. Y recuerde: a los programadores no les gusta regresar a un programa "viejo" para hacer mantenimiento o corregir errores.

Cronogramas de desarrollo de software realistas

No hay absolutamente ninguna razón por la que un cronograma no deba reflejar la realidad de lo que más probablemente ocurrirá. Los resultados son claros: una planificación realista proporciona un cronograma más confiable. Entre los muchos beneficios de un cronograma así están la confianza y el respeto ganados tanto por los usuarios como por el personal de desarrollo. No hay nada como elaborar un cronograma que refleje aquello en lo que todos están seguros de que ocurrirá. 

En este punto, sin duda los analistas experimentados se preguntarán: ¿qué sucede cuando la gerencia nos impone cuánto tiempo tenemos y no muestra flexibilidad ante los retrasos? Este problema, desafortunadamente, no es poco común y típicamente se ajusta a uno de estos tres escenarios:

1. La gerencia no tiene conocimiento sobre el análisis y la construcción de sistemas y simplemente no tiene idea de cuánto tiempo se necesita para completar el proyecto de desarrollo de software. En este caso, el analista deberá desarrollar una presentación convincente para la gerencia sobre los detalles de cómo se diseñan y desarrollan los sistemas. La presentación debe estar cuidadosamente documentada y hacer referencia a estadísticas de la industria para proyectos similares en empresas parecidas. Este tipo de documentación añade mucha credibilidad a la discusión. También puede considerar contar con una fuente independiente, como una firma de consultoría respetada, que respalde su posición. 

2. La gerencia tiene poca confianza en el equipo de desarrollo. Sienten que elegir una fecha y ceñirse a ella es la mejor manera de terminar el proyecto. ¡Sí, esta es la técnica del matón! Generalmente, esto es el resultado de malas experiencias, probablemente al observar diagramas de Gantt poco realistas. En esta situación, el analista debe tomar medidas para ganarse la confianza de la gerencia. Usar las sugerencias mencionadas anteriormente sería un buen comienzo. Además, necesitará investigar y entender la historia de lo que hicieron sus predecesores para fomentar esta actitud desconfiada y dictatorial por parte de la gerencia, y encontrar una manera diplomática de abordar esos problemas. 

3. Lamentablemente, la mala gestión existe. Si no puede obtener ninguna concesión o comprensión por parte de la gerencia, es posible que se encuentre en lo que se conoce como el "escenario sin salida"; la gerencia simplemente no está dispuesta a asignar el tiempo adecuado para la finalización del proyecto de desarrollo de software y no están dispuestos a ser persuadidos de lo contrario. Cuando esta situación existe en el lugar de trabajo, el consejo es directo: puede irse o puede encontrar alguna manera de lidiar con esta limitación. En cualquier caso, tenga en cuenta que bajo el escenario sin salida, hay pocas esperanzas de que el proyecto resulte en el desarrollo de software de calidad. Esta perspectiva no es cínica, sino más bien realista: algunos proyectos están destinados al fracaso antes de comenzar.

Lo importante es que el analista reconozca, lo más temprano posible en el ciclo de vida de desarrollo de software, que el proyecto no puede tener éxito.

Más información relacionada Aquí Desarrollo de software en proyectos complejos

Microsoft Relanza Copilot para Empresas Gratuito

Microsoft está renovando su enfoque en la Inteligencia Artificial (IA) con el lanzamiento de Microsoft 365 Copilot Chat, un servicio gratuito diseñado para empresas. Este movimiento busca acercar la IA a los usuarios y convencerlos de adoptar la versión completa de Microsoft 365 Copilot, que tiene un costo mensual de 30 dólares por usuario.

¿Qué es Microsoft 365 Copilot Chat?

Según Jared Spataro, director de marketing de Inteligencia Artificial en el trabajo de Microsoft, Copilot Chat es “un chat de IA gratuito y seguro, impulsado por GPT”. Este servicio permite a los usuarios subir archivos y acceder a funciones comparables, e incluso superiores, a las de competidores como ChatGPT o Gemini de Google.

Copilot Chat es una evolución de Bing Chat Enterprise, pero ahora incorpora agentes de Inteligencia Artificial directamente en la interfaz del chat. Estos agentes actúan como colegas virtuales que pueden monitorear bandejas de entrada, automatizar tareas y facilitar el trabajo colaborativo.

Características Clave de Copilot Chat

Interacción con Agentes de Inteligencia Artificial:

Los usuarios pueden crear y utilizar agentes a través de Copilot Studio.

Agentes basados en datos web y datos laborales mediante Microsoft Graph.

Modelo de Pago Flexible:

Cobro por uso a través del medidor de Copilot Studio en Azure.

Opciones de paquetes de consumo para controlar gastos.

Capacidades Avanzadas:

Resumen de documentos de Word y análisis de datos en Excel.

Opciones adicionales dentro de Word y Excel para quienes adquieran la suscripción completa.

¿Cómo Funciona el Modelo de Cobro?

Microsoft mide el uso de los agentes de Inteligencia Artificial en mensajes:

Respuestas clásicas: 1 mensaje.

Respuestas generativas: 2 mensajes.

Consultas que acceden a Microsoft Graph: 30 mensajes.

Para facilitar el cálculo de costos:

1 mensaje equivale a 1 centavo.

Por ejemplo, un agente que use datos de Microsoft Graph para responder 200 preguntas generativas y 200 mensajes relacionados con el Graph costaría aproximadamente 64 dólares por un día.

Ventajas y Limitaciones

Copilot para empresas ofrece una experiencia mayormente inalterada en su versión gratuita, utilizando GPT-4 para consultas y permitiendo la subida de archivos. Sin embargo, funciones más avanzadas, como la integración directa en aplicaciones como Word y Excel, están reservadas para la versión completa.

Según Spataro, Microsoft no tiene planes de habilitar un modo de prueba para Microsoft 365 Copilot, lo que hace que Copilot para empresas sea una puerta de entrada para empresas interesadas en explorar las capacidades de la IA antes de comprometerse con una suscripción paga.

Impacto en el Mercado Empresarial

A pesar de algunos desafíos iniciales, como el cambio de nombre de Bing Chat Enterprise, Copilot para empresas ya ha ganado popularidad entre empresas que utilizan software de Microsoft. Spataro enfatiza que, una vez que los usuarios se familiarizan con el sistema, aprecian el valor que aporta a su trabajo.

Con esta estrategia, Microsoft busca consolidar su posición en el mercado de la IA y aumentar la adopción de Microsoft 365 Copilot. Copilot Chat podría ser el primer paso para muchas empresas en su camino hacia un entorno laboral más automatizado y eficiente.

Más información relacionada Aquí Microsoft Relanza Copilot para Empresas Gratuito

Supercomputadora de Inteligencia Artificial

El Despliegue de Clústeres de GPU más Grande del Mundo para lograr la Supercomputadora de Inteligencia Artificial a la fecha.

xAI, en colaboración con Supermicro y NVIDIA, ha dado un gran paso en la creación de la supercomputadora de inteligencia artificial (IA) más poderosa hasta la fecha. Este imponente sistema, ubicado en Memphis, TN, incluye más de 100,000 GPUs NVIDIA HGX H100, exabytes de almacenamiento y redes ultrarrápidas. Todo está diseñado para entrenar y alimentar a Grok, un chatbot generativo de IA desarrollado por xAI. Vamos a explorar cómo este gigante tecnológico se materializó en solo 122 días.

¿Cómo se Construye una Supercomputadora de IA?

Crear una supercomputadora de IA como la de xAI no es tarea fácil. Se necesita una enorme cantidad de poder de cómputo y una infraestructura completamente personalizada. En este caso, se utilizó una sala de datos común como base, pero el reto fue transformar este espacio vacío en un centro de supercomputación avanzado en tan solo 122 días.

Cada una de las cuatro salas de cómputo alberga alrededor de 25,000 GPUs de NVIDIA, así como almacenamiento, redes de fibra óptica de alta velocidad y energía integrada. Sin embargo, el proceso va mucho más allá de lo convencional.

Tecnología y Diseño Especializado para Inteligencia Artificial

El verdadero corazón de este sistema se encuentra en los racks refrigerados por líquido de Supermicro. Estos racks contienen ocho sistemas Supermicro 4U Universal GPU, que a su vez incluyen las poderosas GPUs NVIDIA HGX H100 de 8-GPU, todas refrigeradas por líquido. Cada rack aloja 64 GPUs NVIDIA Hopper, lo que contribuye a la impresionante capacidad de procesamiento de la supercomputadora.

Además de las GPUs, cada rack incluye dos CPUs x86 refrigeradas por líquido, lo que permite un rendimiento óptimo y una mayor eficiencia energética.

Sistema de Refrigeración Líquida

El sistema de refrigeración líquida es uno de los aspectos más innovadores de esta supercomputadora. Cada colector de distribución de refrigerante (CDM) transporta el líquido frío a las GPUs, mientras que los ventiladores del sistema mantienen el aire frío en el rack y expulsan el aire caliente a través de intercambiadores de calor refrigerados por líquido. Esta solución permite una mayor eficiencia en la refrigeración, lo que reduce el consumo de energía en comparación con servidores refrigerados por aire.

Además, el diseño permite un mantenimiento sencillo, ya que los componentes refrigerados por líquido se pueden retirar o reinstalar fácilmente sin necesidad de desarmar el sistema completo.

Red de Alta Velocidad y Escalabilidad

La infraestructura de red es otro aspecto clave para que este centro de datos funcione a su máxima capacidad. Utilizando la plataforma de redes NVIDIA Spectrum-X, las redes de este centro de datos permiten transferencias de datos ultrarrápidas y confiables. Esta tecnología es ideal para manejar las altas demandas de las cargas de trabajo de IA, gracias a características como el enrutamiento inteligente de datos, la reducción de retrasos y el control del tráfico de red.

El NVIDIA Bluefield-3 SuperNIC proporciona una red de 400 gigabits por segundo, lo que significa que cada servidor de cómputo puede manejar un ancho de banda de 3.6 Tbps. Además, el uso de la red RDMA (Remote Direct Memory Access) para las GPUs optimiza aún más el rendimiento de este sistema masivo.

Conmutadores Avanzados para la Supercomputadora de Inteligencia Artificial

Para garantizar que todas estas conexiones funcionen a la perfección, el sistema utiliza el conmutador Ethernet NVIDIA Spectrum SN5600. Este conmutador de 64 puertos y 800 Gb tiene la capacidad de dividir y gestionar 128 enlaces Ethernet de 400 gigabits. Su diseño avanzado permite que el clúster funcione a niveles máximos de rendimiento sin congestionar la red, lo que lo convierte en una pieza clave para el éxito de este centro de datos.

El Futuro de la Supercomputación

Con esta supercomputadora, xAI, junto con Supermicro y NVIDIA, ha establecido un nuevo estándar en la supercomputación. El Clúster xAI Colossus no solo está empujando los límites de lo que es posible hoy en día, sino que también abre las puertas a nuevas posibilidades en el área de la inteligencia artificial y otras sectores tecnológicos.

Este logro de la creación de una Supercomputadora de Inteligencia Artificial es solo el comienzo. A medida que la tecnología continúa avanzando, estaremos atentos a cómo este clúster sigue evolucionando y llevando a cabo tareas cada vez más complejas. Sin duda, xAI, Supermicro y NVIDIA están liderando el camino hacia una nueva era de supercomputación.

Leer más Aquí Supercomputadora de Inteligencia Artificial

La Estrategia Empresarial: Más Allá de las Finanzas

Comprender la Estrategia

La estrategia empresarial debe estar fundamentada en comprender quién es la organización, el lugar que ocupa en el mundo y a quién le importa más. Este enfoque permite crear valor, capturarlo y protegerlo en un entorno cambiante. El desarrollo de la estrategia sigue un proceso lineal que ayuda a una empresa a alcanzar su propósito, y consta de tres pasos básicos:

1. Comprender las circunstancias operativas.

2. Tomar decisiones prioritarias que impulsen el crecimiento y la diferenciación.

3. Elaborar un plan de ejecución.

Finanzas vs. Estrategia

Las finanzas no deben ser el motor del pensamiento estratégico. Aunque son una consideración importante y el resultado de una buena estrategia es la creación de valor financiero, la estrategia debe enfocarse en la búsqueda de valor. Este valor se articula a través de un propósito definitorio, una "estrella del norte", que sitúa al usuario final y a otras partes interesadas en el centro de la estrategia.

Más que Objetivos

Una estrategia empresarial efectiva no es simplemente un conjunto de objetivos financieros o de satisfacción del cliente. Es una narración bellamente estructurada con la sustancia necesaria para ser ejecutada, incluyendo investigación, planes de acción, recursos y gobernanza. La estrategia puede existir en múltiples niveles dentro de una organización: general, de línea de negocio y funcional. Si estos niveles no están alineados, se corre el riesgo de una "disfunción estratégica".

Lo Digital como Habilitador

Lo digital no es la estrategia en sí misma, pero la habilita. Comprender cómo lo digital y la estrategia se complementan es crucial para el éxito, por lo tanto la estrategia digital por si misma no puede existir.

El Modelo 6D para la Estrategia Moderna

Este modelo consiste en seis pasos secuenciales que te ayudarán a desarrollar y refinar tu estrategia:

1. Descubrir: Entender el mercado, la posición de tu negocio y las ambiciones internas.

2. Detectar: Identificar tendencias externas e internas que puedan influir en el mercado futuro.

3. Diagnosticar: Evaluar la información recopilada para identificar temas críticos y oportunidades de creación de valor.

4. Dirigir: Priorizar los temas estratégicos y definir los impulsores necesarios.

5. Entregar: Traducir los temas estratégicos en planes de acción concretos respaldados por la gobernanza.

6. Destreza: Evaluar y recalibrar continuamente, utilizando los pasos anteriores para mantener la estrategia actualizada.

Integración y Ejecución

En su núcleo, la estrategia empresarial debe estar guiada por un propósito convincente. Este propósito debe ser constante y servir como piedra angular de la intención estratégica. La estrategia se complementa con la monitorización constante de tendencias y dinámicas competitivas para detectar oportunidades y amenazas.

En un entorno colaborativo, como una asociación o ecosistema, el diagnóstico, dirección y entrega pueden ser desarrollados conjuntamente por todas las partes involucradas. Diferentes enfoques pueden ser útiles en distintas fases, como la Escuela Cognitiva para el diagnóstico o la Escuela de Posicionamiento para la entrega en startups.

Ajuste Iterativo

Cada negocio tiene su conjunto único de circunstancias, por lo que el modelo 6D debe verse como un marco flexible que permite ajustes iterativos a medida que la estrategia madura. La frecuencia de los ciclos internos y externos debe adaptarse a las necesidades del negocio, y la sexta dimensión, la destreza, permite una recalibración continua.

El Modelo 6D para la Estrategia Empresarial Moderna entrelaza las dinámicas internas y externas de la estrategia de una organización. Usar este enfoque te ayudará a evaluar tu empresa en su contexto, desarrollar una estrategia sólida y ajustarla iterativamente para asegurar su éxito a largo plazo.

Originalmente publicado Aquí La Estrategia Empresarial: Más Allá de las Finanzas