𝐀𝐆𝐄𝐓𝐈𝐂 𝐃𝐄𝐒𝐌𝐈𝐄𝐍𝐓𝐄 𝐀𝐓𝐀𝐐𝐔𝐄𝐒 INFORMATICOS

 La AGETIC aclara que, el 25 de abril, sus servicios se interrumpieron por una falla física en su centro de datos y desmiente presuntos ataques a su infraestructura y a los sistemas gubernamentales.

Comunicado

La Agencia de Gobierno Electrónico y Tecnologías de Información y Comunicación (AGETIC) informa a la población que aproximadamente a las 15:30 horas, del 25 de abril, los servicios que nuestra institución brinda a entidades públicas y ciudadanos quedaron temporalmente fuera de línea debido a una falla física en los dispositivos de comunicación del centro de datos.

Desde el primer momento, la AGETIC ha tomado medidas inmediatas para garantizar la integridad de los datos, investigar las causas y trabajar con la máxima prioridad en el restablecimiento de los servicios en el menor tiempo posible, además de notificar el problema a nuestras partes interesadas. Así mismo informamos que a partir de las 23:50 horas del sábado 27 de abril, se han ido restableciendo de forma gradual todos los servicios.

Queremos desmentir enfáticamente la información que circula en redes sociales sobre presuntos ataques a nuestra infraestructura y sistemas gubernamentales que habrían provocado un colapso generalizado. Hasta el momento, nuestro monitoreo continuo no ha detectado evidencias de intrusiones o accesos no autorizados. Sin embargo, algunos sitios web pueden experimentar problemas de disponibilidad que no están relacionados con ataques.

La seguridad de la información es nuestra principal preocupación, y estamos comprometidos con mejorar y mantener la seguridad de nuestra infraestructura tecnológica y la de las entidades públicas, de igual forma, realizamos pruebas continuas de seguridad informática a los sistemas de información y verificamos el cumplimiento de los planes institucionales de seguridad de la información a nivel Gubernamental.

Agradecemos su comprensión.

La Paz, 29 de Abril del 2024

www.agetic.gob.bo

Modelado visual con UML

El modelado visual es el modelado de una aplicación usando notaciones gráficas. Según Booch, en el libro escrito el año 1999 titulado “Arquitectura del software y el lenguaje de modelado unificado”, es sumamente importante construir el modelo de una aplicación, en este sentido comúnmente se hace la comparación hacia la arquitectura tradicional, en la construcción de casas. Aún cuando la construcción que se planee hacer sea una casa sencilla, el resultado será más satisfactorio si cuenta con todo un respaldo en un correcto diseño. Booch compara la construcción de software con la construcción de una casa para un perro, de una casa para tu familia y de un gran edificio. En el primer caso no será tan evidente la falta de un buen diseño, o al menos la mascota no se quejará demasiado. En el segundo caso, es humanamente posible hacer la construcción de una casa sin los planos adecuados, pero la casa resultante seguramente tendrá varias carencias, o en un peor caso, posiblemente no resistirá ciertas condiciones extremas como un temblor. En el caso del edificio, definitivamente sería un grave error comenzar la construcción sin los estudios y planos adecuados. En el caso del software, es curioso como muchos proyectos del tamaño de un rascacielos, son construidos como si se tratara de la casa de un perro. El modelado visual del software ayuda a capturar las partes esenciales de un sistema: (1) Se utiliza para capturar los procesos de negocios desde la perspectiva del usuario. (2) El modelado visual se utiliza para analizar y diseñar una aplicación, distinguiendo entre los dominios del negocio y los dominios de la computadora. (3) Ayuda a reducir la complejidad. (4) El modelado visual se realiza de manera independiente al lenguaje de implementación. (5) Promueve la reutilización de componentes.
En el libro escrito por la empresa Rational, en el año 1997 titulado “Análisis y diseño con UML”, podría decirse que el lenguaje de modelado unificado es una combinación de: (1) Conceptos de modelado de datos. (2) Modelado del negocio. (3) Modelado de objetos. (4) Modelado de componentes. Precisamente, el nombre del lenguaje de modelado unificado viene del esfuerzo de la compañía Rational de unificar todo el conjunto de métodos de análisis y diseño orientados a objetos. Las ideas principales pertenecen a los investigadores Grady Booch, James Rumbaugh e Ivar Jacobson, quienes trabajan para Rational Software. Además como complemento, también se propuso un proceso unificado, que sirva de complemento al lenguaje de modelado unificado, pero que no sería obligatorio utilizar, fue desarrollado también por Booch, Rumbaugh y Jacobson, y se conoce como “Proceso Unificado Racional”. Se vuelve a recalcar que el lenguaje unificado de modelado es un lenguaje de modelado visual para sistemas software. Los sistemas de software modernos normalmente requieren el soporte de herramientas. Según Arlow y Neustadt, en el libro escrito el año 2006 titulado “UML 2”, los diagramas del lenguaje de modelado unificado son legibles por las personas y las computadoras pueden mostrarlos fácilmente. Con ello, el lenguaje unificado de modelado proporciona una sintaxis visual que se puede utilizar para construir modelos. En muchos proyectos se realiza el modelado visual utilizando los diagramas de casos de uso, los diagramas de clases y los diagramas de secuencias como herramientas de modelado. La descripción de estos diagramas se realiza utilizando el libro escrito el año 2006 por los investigadores Booch, Rumbaugh y Jacobson titulado “El lenguaje de modelado unificado: Guía del usuario”.
En relación con los diagramas de casos de uso, Booch y sus colegas, en el libro citado anteriormente, mencionan que: Ningún sistema se encuentra aislado. Cualquier sistema interesante interactúa con actores humanos o mecánicos que lo utilizan con algún objetivo y que esperan que el sistema funcione de forma predecible. Un caso de uso especifica el comportamiento de un sistema o de una parte de éste, y es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor. Los casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cómo se implementa ese comportamiento. Los diagramas de clases brindan solución a esta necesidad al permitir comprender el modelo del negocio a partir de entidades, definiciones y sus relaciones. Un diagrama de secuencia es un diagrama de interacción que resalta la ordenación temporal de los mensajes.

UNA PROPUESTA PARA LA ESTRUCTURA DE LA TESIS DE GRADO EN INGENIERÍA INFORMÁTICA

ESTRUCTURA BÁSICA DE LA TESIS La Estructura Básica de Tesis es la siguiente: 1. Introducción 2. Estado de la cuestión 3. Definición del problema 4. Solución propuesta 5. Resultados o verificación experimental 6. Conclusiones y futuras líneas de investigación 7. Bibliografía 8. Anexos 1. INTRODUCCIÓN Este capítulo debe reflejar a modo de resumen y presentación, todos los aspectos de relevancia que contiene la tesis. El lector ha de apreciar las razones que justifican la originalidad y la importancia del tema, y además hacerse una idea del carácter metódico del trabajo. Debe cubrir como mínimo los siguientes puntos: · Breve descripción del problema y su importancia. · Carácter del problema. · Motivación para abordarlo, resaltando la importancia de resolverlo. · Qué pasos se realizarán. · Criterios de éxito. 2. ESTADO DE LA CUESTIÓN Este capítulo debe reflejar la información recogida que se utilizó para establecer la situación actual de los trabajos en investigación y desarrollo sobre el área particular en la que se plantea y relaciona el problema. Deben quedar absolutamente establecidos y documentados a través de referencias y citas bibliográficas, los siguientes puntos: · Antecedentes relacionados con el problema. · Fundamentos teóricos y prácticos que cimientan las soluciones escogidas. · Que trabajos del tipo propuesto han sido o están siendo realizados (si existen). · Desarrollo actual de las técnicas, herramientas, etc., que sean requeridos en el tratamiento del problema. · Conjunto de referencias que amparan el problema. · Documentación del problema, citas bibliográficas. · Temas pendientes. 3. DEFINICIÓN DEL PROBLEMA En este capítulo debe responderse con toda precisión a las siguientes preguntas: ¿ Cuál es el problema que se pretende resolver? ¿Por qué este problema y no otro? ¿Cuál es su importancia en el contexto de estudio? Declarar los propósitos y objetivos, y justificar lo expresado. Para facilitar estas acciones se recomienda guiarse por las siguientes pautas: · Definir exactamente el problema. · Objetivos. · Restricciones o límites de trabajo. · Especificaciones aplicables. · Recursos. 4. SOLUCIÓN PROPUESTA En este capítulo debe responderse con toda precisión a la pregunta ¿Cómo se ha resuelto el problema? Constituye la parte central de la Tesis, por lo que su estructura y su contenido dependerán de cada caso, aunque en general debe incluir los siguientes aspectos: · Establecer y justificar la solución aportada. · Destacar el contenido de los conocimientos aportados. · Constatar la metodología y los métodos utilizados en la búsqueda de la solución. · Incluir las justificaciones teóricas que amparen la solución. 5. RESULTADOS O VERIFICACIÓN EXPERIMENTAL En este capítulo se debe poner: · Los experimentos y las pruebas realizadas, que corroboren la veracidad de lo propuesto. · Los resultados obtenidos, así como su grado de desvío respecto a los resultados esperados. · La calidad de los resultados en comparación con otras soluciones similares. · Una evaluación general de procedimientos, recursos y facilidades utilizados, anotar aciertos, errores, debilidades. · Dificultades no previstas encontradas y sus soluciones. 6. CONCLUSIONES Y FUTURAS LÍNEAS DE INVESTIGACIÓN En este capítulo se debe hacer hincapié en la contribución realizada a la solución del problema, y en la experiencia adquirida. Cuando ello sea procedente, es deseable que la Tesis abra o sugiera trabajos de investigación o desarrollos subsiguientes. Dichos trabajos deberán ser descritos, muy brevemente en este apartado. 7. BIBLIOGRAFIA Lista ordenada de todos los libros, revistas, etc., que han sido utilizados en el trabajo. 8. ANEXOS En los anexos, y separado por temas, se incluirá todo aquel material importante que no contribuya directamente a la presentación de la tesis o que, por su extensión, distraiga al lector de la línea principal de desarrollo de la misma. A manera de ejemplo, a continuación se muestra una lista de documentos que pueden ser incorporados a este nivel. · Test de evaluación realizados · Resultados de pruebas Herramientas utilizadas · Guía de usuario · Instrucciones de Operación · Etc.