Por colaboradores de Mundo Ingenio
Se debe destacar la importancia que representa el uso de diferentes tecnologías en la actualidad, son muchos los procesos y actividades que envuelven a estas con múltiples fines. Un fundamento de las tecnologías que ha sido una constante desde sus inicios, es la documentación con un propósito en específico; en el caso de los desarrollos de sistemas y/o programas, en sus distintas áreas de implementación, se mantiene este principio para obtener un resultado eficiente, para ahorrar recursos, desde económicos hasta tiempo. Una planificación efectiva desde el inicio de un proceso de proyecto, es significativo para generar confianza en los clientes finales, que son los que, en la mayoría de los casos, pagan por estos servicios; sin embargo, en cualquier caso es primordial una documentación efectiva de diseño de “software” y otros campos de la tecnología.
De manera general, la presente indagación de recolección de información referente al planteamiento y ejecución de un proyecto de desarrollo de “software”, reúne datos alusivos a este, donde se pone en práctica mediante ejemplos propuestos en el curso actual con nombre “Análisis y diseño de sistemas”, basados en el caso de uso de nombre “Oc2021”.
Específicamente, se plantea el análisis de diseño de sistemas a través de visualización del caso de uso, mencionado antes, con la puesta en práctica de plantillas estructuradas y diseños de diagramas, entre otras características relevantes. También, se expone el diseño de sistemas mediante observaciones, interacción, diagramas de estado, componentes del caso de uso, y describiendo los beneficios de este tipo de documentación.
La presente indagación se desarrolla de la siguiente forma, en primer lugar y como se propone en los objetivos específicos, el estudio de desarrollo de sistemas; conformado por utilización de plantillas estructuradas, modelado y redacción de funcionalidades de un caso de uso.
En segundo lugar, el planteamiento de sistemas. Esta sección la componen los siguientes elementos; un diagrama de clase UML, un diagrama de estados de un objeto determinado, objetivos de un diseño, un diagrama de subsistemas, y por último, una descripción de las ventajas de la correcta implementación de los procesos que implican las diferentes tareas y técnicas dentro del marco de diseño y análisis de sistemas.
Desarrollo
Primera parte – Sobre el análisis de sistemas
1. Plantee la visión del proyecto
A continuación se plantea la visión del proyecto con base en el caso de uso “Oc2021”. Se muestra una plantilla basada en los autores de IBM Corporation (2018), donde propone el manejo de un caso de usos con varias características. En primer lugar, se encuentra un elemento con nombre “Introducción” con varios otros subelementos que se mencionan y ponen en práctica con base en el caso de uso mencionado antes. En segundo lugar, está el posicionamiento, igualmente con sus subcomponentes, mismos que se nombran y ponen en práctica con el mismo caso de uso o ejemplo propuesto. Resumiendo, el objetivo de la documentación de visión de un proyecto es definir el alcance y propósitos de un programa o aplicación o proyecto, en cualquier caso ofrece una serie de pasos que permiten detallar el proceso y lo que involucra cada uno de ellos (IBM Corporation, 2018).
Plantilla IMB (secciones de Introducción y Posicionamiento únicamente)
Introducción
Objetivo: el propósito de este documento es involucrar a la población costarricense en el proceso de integrar al país al marco de carbono neutral y reducir la huella de carbono, reduciendo la emisión de gases de efecto invernadero, mediante el uso de una plataforma digital con características que faciliten este tipo de gestión.
Alcance: este documento de visión compromete a toda la población costarricense, la cual podrá contar con una aplicación disponible en una tienda respectiva, descargable para los usuarios finales (guardianes, oficiales, jueces), dichos usuarios con roles, los cuales les permite gestionar funciones distintas para denunciar problemas concernientes al medio ambiente. Por otra parte, una aplicación para otro tipo de usuario finales (administradores y consultantes), los cuales podrán administrar a los usuarios mencionados antes, al igual que gestionar la salud del sistema. También, la aplicación mediante el uso de la plataforma de Google Maps, podrá mostrar las denuncias.
Definiciones, acrónimos y abreviaturas:
- Carbono neutral/neutralidad: según el autor Iberdrola (2021),
“se alcanza cuando se emite la misma cantidad de CO2 a la atmósfera de la que se retira por distintas vías, lo que deja un balance cero también denominado huella de carbono cero” (parr. 4).
- Gases de efecto invernadero: según el autor GreenFacts (2021),
“Gases integrantes de la atmósfera, de origen natural y antropogénico, que absorben y emiten radiación en determinadas longitudes de ondas del espectro de radiación infrarroja emitido por la superficie de la Tierra, la atmósfera, y las nubes. Esta propiedad causa el efecto invernadero” (parr. 1).
- MINAE: significa (Ministerio de Ambiente y Energía de Costa Rica).
- BD: base de datos.
- BL: capa lógica del negocio.
- GPS: sistema de posicionamiento global.
- Aplicación Back Office: gestionamiento de un aplicativo interno administrativo.
- Live Map: mapas en tiempo real.
Visión general: el documento de visión se organiza y compone de los siguientes elemento; un propósito específico, una magnitud con una extensión definida, detalle de definiciones, siglas y abreviaciones entre otros conceptos importantes.
Posicionamiento
Oportunidad de negocio: este sistema posibilitará al país alcanzar el carbono neutral haciendo participar a la población costarricense, reforzando la integración nacional, a través de la relación que crea la plataforma, con beneficios para toda la población y sobre todo el medio ambiente.
Declaración del problema:
Tabla “Declaración del problema”
El problema de | En Costa Rica se está generando un aproximado de 12.44 millones de toneladas de gases de efecto invernadero.La comunidad costarricense no cuenta con un medio rápido y eficiente para reportar irregularidades relacionadas con la emisión de gases de efecto invernadero y las actividades que los involucra. |
Afecta a | Población costarricense.Ranking y participación de Costa Rica con objetivo de alcanzar carbono neutral. |
El impacto asociado es | Crear reportes de problemas relacionados con actividades que generan gases de efecto invernadero que afecta al medio ambiente. |
Algunos beneficios serian | La creación de aplicaciones con roles específicos, unos que puedan gestionar todo lo relacionado con las denuncias de los problemas hacia el ambiente, y otra para que administre a estos usuarios y la salud de la aplicación. Igualmente, mediante esta aplicación se podrán visualizar las denuncias en mapas virtuales. |
Tabla “Declaración del problema”
Autor: propio
Fuente: https://es.slideshare.net/SystemCampos/documento-vision-1
Declaración de posición de producto:
Tabla “Declaración de posición de producto”
Para | MINAE.Usuarios costarricenses integrados en la participación del país hacia el camino de Costa Rica carbono neutral. |
Quienes | Usuarios con roles que se encargan de reportar y administrar denuncias por parte de la población.Y usuarios con roles que se encargan de administrar a los usuarios y salud de la aplicación. |
El nombre del producto | Aplicación móvil y aplicación back office. |
Que | Móvil: Gestiona todo el proceso de denuncias, desde el reporte, hasta la confirmación y solución, entre otras.Back office, la administración de usuarios y salud del aplicativo. |
No como | El proceso actual, no informatizado y carente de respaldo y participación ciudadana. |
Nuestro producto | Va a permitir toda la administración relacionada con el reporte de actividades ciudadanas que causen y emitan a su vez gases de efecto invernadero, reduciendo la huella de carbono. |
Tabla “Declaración de posición de producto”
Autor: propio
Fuente: https://es.slideshare.net/SystemCampos/documento-vision-1
Es relevante destacar la importancia que representa la integración de un elemento como es “documento de visión” para un proyecto de programación u otra área, ya que este facilita información con referentes significativos para identificar los procesos correctos para evitar errores durante el proyecto, o inclusive al final de este. Con los datos recolectados y debidamente documentados es mucho más fácil manejar el proyecto sin “improvisar”, por ejemplo, alguna funcionalidad, tomando en cuenta los riesgos y posibles fallos del sistema, en el caso de ser del campo de tecnología, lo que permite visualizar el producto final desde el inicio del proyecto.
Por otra parte, el motivo de la realización de este tipo de documento es registrar información de componentes relevantes que pautan el desarrollo desde su base o el inicio del mismo. En otro orden de ideas, un proyecto sin bases sólidas va a generar errores anticipadamente; el fundamento para un desarrollo exitoso es la planificación óptima, el manejo de riesgos e identificación del problema, que se desea resolver realmente, y otras características que tiene un programa o aplicación u otra área, sin redundar o experimentar en funcionalidades que al final son parte del programa o proyecto; entonces, un documento como el “visión del proyecto”, que en conjunto con otros elementos que forman parte fundamental del proceso completo del mismo, va a dar una base consistente que garantiza el éxito del desarrollo de un sistema informático por ejemplo.
2. Diagrama de casos de uso
A continuación se presenta un diagrama de casos de uso según la notación UML. Se muestra en forma de imagen (Imagen 1) para una visualización entendible. La imagen es de autoría propia, creadas con el sistema en línea de “Miro” en su sitio web con dominio: “miro.com”. Se plantea el diagrama con base en los fundamentos y ejemplos de las lecturas de los autores Campderrich Falgueras (2013) y Bruegge y Dutoit (2002).
Se toman en cuenta las siguientes funcionalidades: Guardianes, los cuales podrán crear su cuenta, iniciar sesión y registrar denuncia. Oficiales, con la capacidad de consultar denuncias, filtrar denuncias, ver detalle de denuncia, crear cuenta, iniciar sesión y crear propuesta de solución para denuncia. Jueces, con la capacidad de crear cuenta, iniciar sesión, aprobar denuncias, denegar denuncias, aprobar propuesta de solución y rechazar propuesta de solución. Administradores, con la capacidad de registrar usuario, eliminar usuario, desactivar usuario y activar usuario. Consultante, con la capacidad de consultar el reporte general de usuarios, consultar reporte regional, consultar reporte general de denuncias, consultar reporte de cantidad de denuncias.
Imagen 1.
Diagrama “Casos de uso UML”
Autor: propio
Es necesario decir que hay, o puede haber relaciones entre casos de uso, siendo estas dependencias unas de otras, las cuales se representan mediante las palabras en inglés “include” y “extend”, con el objetivo de especificar a detalle dichas relaciones y mostrar un diagrama escrupuloso. En la Imagen 1, no se intenta extender mucho más estas relaciones, para mostrar de mejor forma el comportamiento del sistema externo, ya que existen otros diagramas donde se especifica a profundidad este tipo de proceso, algunos ejemplos son: colaboración, diagramas de interacción, secuencia, entre otros.
3. Funcionalidades
A continuación, se redactan los casos de uso para las funcionalidades: “Consultar denuncias”, “Proponer solución a denuncia”, “Aprobar denuncia”, “Rechazar propuesta de solución”, y “Registrar aporte a la carbono-neutralidad”. Basados en la lectura del autor Junta de Andalucía (s.f.) y el autor Canal Big Learning (s.f.), donde expresan la estructura para documentar de manera correcta un caso de uso, donde igualmente proponen modelos de plantillas con características específicas. La redacción se presenta en forma de tabla.
Tabla 1.
Caso de uso: | “Consultar denuncias” |
Requerimientos relacionados o dependencias | Registrar denuncia. |
Objetivo en contexto o descripción | Un usuario que ya existe con rol de Guardián y/o consulta las denuncias del sistema. |
Precondiciones | El usuario Guardián necesita registrar una denuncia con los parámetros establecidos. |
Final exitoso | Guardianes: el sistema muestra las lista de denuncias, donde el usuario puede modificarlas o eliminarlas.Jueces: el sistema muestra la lista de denuncias y puede reportarlas. |
Final Fallido | Guardianes: el sistema se cae y el usuario no puede visualizar la lista de denuncia, o no puede modificar ni eliminar denuncias.Jueces: el sistema se cae y el usuario no puede visualizar la lista de denuncias, o no puede reportarlas. |
Actores principales | Guardianes.Jueces. |
Actores secundarios | Oficiales. |
Evento de inicio | Los usuarios guardianes y jueces solicitan al sistema desplegar una lista de denuncias. |
Flujo principal | El Guardián solicita al sistema consultar una lista de denuncias.El Guardián puede modificar o eliminar una denuncia elegida y confirmar al sistema hacer la acción.Los Jueces pueden solicitar al sistema desplegar una lista de denuncias.Los Jueces pueden denegar o confirmar la denuncia elegida y confirmar al sistema el evento. |
Caso de uso: “Consultar denuncias”
Autor: propio
Tabla 2.
Caso de uso: | “Proponer solución a denuncia” |
Requerimientos relacionados | Confirmar denuncia. |
Objetivo en contexto | Un usuario Oficial puede visualizar una lista de denuncias confirmadas y proponer una solución para una denuncia y enviar una notificación a los Jueces. |
Precondiciones | Es necesario que el usuario Juez determine una denuncia con estado de “Confirmada”. |
Final exitoso | Una vez enviada la notificación de solución al Juez, este la determina como confirmada. |
Final Fallido | El juez determina como rechazada la propuesta de solución y el estado de la denuncia pasa a un estado de “En proceso” nuevamente. |
Actores principales | Oficiales |
Actores secundarios | Jueces |
Evento de inicio | Los Jueces determinan si una denuncia es confirmada y se notifica a los oficiales que solicitan al sistema desplegar una lista de denuncias en proceso. |
Flujo principal | Los jueces determinan si una denuncia es confirmada o no, si lo es, notifican a los oficiales.Los oficiales solicitan al sistema desplegar una lista de denuncias “En proceso”.Los oficiales determinan una propuesta de solución y envían una notificación a los jueces.Los jueces solicitan al sistema desplegar las notificaciones con una lista de denuncias con su respectiva solución.El juez determina si la propuesta es válida o no y determina la solución como rechazada o confirmada.Si la solución es conformada la denuncia cambia su estado a “Finalizada”. Si la solución es rechazada cambia su estado a “En proceso” de nuevo. |
Caso de uso: “Proponer solución a denuncia”
Autor: propio
Tabla 3.
Caso de uso: | “Aprobar denuncia” |
Requerimientos relacionados | Proponer una solución a la denuncia |
Objetivo en contexto | Consiste en que un usuario Juez puede solicitar al sistema desplegar una lista de denuncias con su respectiva solución para luego aprobar esta propuesta. |
Precondiciones | El usuario Oficial debe enviar una propuesta de solución y notificar la misma a los jueces. |
Final exitoso | La propuesta es confirmada y el estado de la solución a la denuncia pasa a “Finalizada”. |
Final Fallido | La propuesta es rechazada y el estado de la propuesta a la denuncia pasa a un estado de “En proceso” de nuevo para ser reevaluada otra vez. |
Actores principales | Jueces |
Actores secundarios | Oficiales |
Evento de inicio | Los jueces solicitan al sistema desplegar una lista de propuestas a denuncias con el fin de confirmar o rechazar dichas propuestas por los oficiales. |
Flujo principal | Los oficiales notifican a los jueces de las propuestas de solución a las denuncias en proceso.Los jueces despliegan una lista de notificaciones de propuestas de solución para denuncias.El juez determina como rechazada o confirmada la propuesta de solución.Si la solución es conformada el estado de la propuesta denuncia pasa a finalizada. |
Caso de uso: “Aprobar denuncia”
Autor: propio
Tabla 4.
Caso de uso: | “Rechazar propuesta de solución” |
Requerimientos relacionados | Proponer una solución a la denuncia |
Objetivo en contexto | Consiste en que un usuario Juez puede solicitar al sistema desplegar una lista de denuncias con su respectiva solución para luego rechazar esta propuesta. |
Precondiciones | El usuario Oficial debe enviar una propuesta de solución y notificar la misma a los jueces. |
Final exitoso | La propuesta es rechazada y el estado de la propuesta a la denuncia pasa a un estado de “En proceso” de nuevo para ser reevaluada otra vez. |
Final Fallido | La propuesta es confirmada y el estado de la solución a la denuncia pasa a “Finalizada”. |
Actores principales | Jueces |
Actores secundarios | Oficiales |
Evento de inicio | Los jueces solicitan al sistema desplegar una lista de propuestas a denuncias con el fin de confirmar o rechazar dichas propuestas por los oficiales. |
Flujo principal | Los oficiales notifican a los jueces de las propuestas de solución a las denuncias en proceso.Los jueces despliegan una lista de notificaciones de propuestas de solución para denuncias.El juez determina como rechazada o confirmada la propuesta de solución.Si la solución es rechazada el estado de la denuncia pasa a “En proceso” y es enviado al sistema para ser reevaluada otra vez. |
Caso de uso: “Rechazar propuesta de solución”
Autor: propio
Tabla 5.
Caso de uso: | “Registrar aporte a la carbono-neutralidad” |
Requerimientos relacionados | El usuario Guardián debe haberse registrado en el sistema. |
Objetivo en contexto | Los usuarios guardianes pueden hacer aportes referentes a actividades relacionadas con el carbono neutral y generar un reporte en el sistema. |
Precondiciones | El guardián debe tener creada una cuenta en el sistema, con los requerimientos establecidos y ser aprobado por el sistema. |
Final exitoso | El reporte o aporte se genera en el sistema. |
Final Fallido | El sistema presenta algún fallo y el reporte no se genera en el mismo. |
Actores principales | Guardianes |
Actores secundarios | – |
Evento de inicio | Los guardianes solicitan al sistema generar un aporte de carbono neutralidad al sistema con el fin de producir un reporte del mismo. |
Flujo principal | El guardián debe registrarse en la plataforma.El guardián puede solicitar al sistema agregar un reporte de carbono neutral.El sistema despliega un catálogo definido de aportes.El guardián debe generar un reporte de la actividad de carbono neutral con el aporte elegido y confirmarlo al sistema. |
Caso de uso: “Registrar aporte a la carbono-neutralidad”
Autor: propio
Segunda parte – Sobre el diseño de sistemas
4. Diagrama de clase UML
Seguidamente, se muestra un diagrama de clase UML que involucra la funcionalidad de “Proponer solución a denuncia”; tomando las características fundamentales y relevantes de las lecturas correspondientes de los autores Campderrich Falgueras (2013) y Larman (2003), donde detallan la estructura apropiada para el diseño y elementos que componen el diagrama de clase UML. Se utiliza el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”. El diagrama se presenta en forma de imagen (Imagen 2).
Imagen 2.
Diagrama de Clases UML: “Proponer solución a denuncia”
Autor: propio
En el caso de las clases que se califican como entidades son las siguientes; Persona y Usuario, donde Persona hereda de Usuario. En el caso de Denuncia y PropuestaSolucion son igualmente entidades, donde ambas poseen la capacidad y/o funcionalidad de poseer un estado u otro propio durante todo el proceso, dependiendo de las determinaciones por parte del Juez. Por otra parte, Juez y Oficial (entidades) heredan las características y métodos de Persona, con sus respetivos controladores (ControllerJuez y ControllerOficial) que les permiten, el primero determinar el estado de una Denuncia, sea Confirmar o Rechazar, y también determinar una Propuesta como Confirmada o Rechazada.
5. Diagrama de secuencia utilizando la notación UML
El siguiente es un diagrama de secuencia, donde los autores Campderrich Falgueras (2013) y Larman (2003), hace mención a características e interacciones entre objetos de clase, que cuentan con eventos que se generan las acciones de los usuarios. Se utiliza el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”. El diagrama se presenta en forma de imagen (Imagen 3).
Imagen 3.
Diagrama de Secuencia: “Proponer solución a denuncia”
Autor: propio
6. Diagrama de estado
A continuación, se muestra un diagrama de estado, con base en el objeto Denuncia; con base en la lectura del autor Campderrich Falgueras (2013), donde menciona algunas características referentes a la documentación de diagramas de tipo “estado”, tales como transiciones, estados, eventos, entre otros. Se utiliza el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”. El diagrama se presenta en forma de imagen (Imagen 4).
Imagen 4.
Diagrama de Estado: “Objeto Denuncia”
Autor: propio
7. 10 objetivos de diseño
Seguidamente, se describen 10 objetivos del proyecto, con base en el ejemplo práctico “Oc2021”, donde se propone la creación de una aplicación móvil para involucrar a la comunidad costarricense en el plan país en transición a pertenecer a una lista de naciones carbono neutral, pero sobre todo mejorar el medio ambiente para beneficio de todos los ciudadanos. Según el autor Sommerville (2011), cada sistema debe cumplir con una serie de estándares, mismos que un equipo de Gestión de Calidad revisa con el fin de que el aplicativo cumpla las expectativas de los usuarios finales y sea posible colocarla en producción; entre algunos de los estándares se encuentran, protección, seguridad, adaptabilidad, portabilidad, modularidad, usabilidad, eficiencia, entre otros. Los objetivos del proyecto “Caso Práctico OCc2021” según el autor Universidad Estatal a Distancia (2021):
- Seguridad: “se espera que se cuenten con mecanismos de protección de datos y encriptación” (pág. 3). [dominio de la aplicación].
- Confidencialidad: “se espera que se cuenten con mecanismos de protección de datos y encriptación” (pág. 3). [dominio de la aplicación].
- Tolerancia a fallos: “se espera que la aplicación tenga alguna modalidad que le permita recuperarse ante fallos” (pág. 3), como ejemplo si se cae la red, encolar las acciones registradas. [dominio de la aplicación].
- Eficiencia: “Es importante que la aplicación tenga una buena recepción por parte del público meta por lo que se espera que sea muy eficiente.” (pág. 3). [dominio de la aplicación].
- Funcionalidad: una de tantas funcionalidades que requiere el sistema “Para todo usuario de la aplicación se requiere tener acceso a sus datos personales básicos” (pág. 2). [se adecua el sistema al conjunto de funciones especificados por el usuario].
- Confiabilidad: una de las características de la aplicación se fundamenta en tolerar errores, como se menciona antes, y también la madurez de la misma, para manejar muchas excepciones del sistema que puedan generar errores, como la transferencia de datos sensibles de clientes. “Existirá una opción de inscripción en la aplicación móvil, donde los usuarios ingresen dichos datos personales”. [posibilidad de cambios por el equipo de desarrollo].
- Usabilidad: “La plataforma proveerá una aplicación móvil que será utilizada por una gran cantidad de usuarios”. (pág. 1). Es decir que la aplicación debe tener una interfaz gráfica amigable (entendible y atractiva para múltiples tipos de usuarios). [requerimiento no funcional].
- Adaptabilidad: “respaldarse en un proceso de desarrollo ágil que sea capaz de adaptarse a cambios en el proceso” (pág. 1). [adaptaciones hechas por los desarrolladores].
- Portabilidad: “En este se podrá visualizar de manera gráfica las denuncias de los usuarios a través de la aplicación Google Maps”. (pág. 4). Es decir, la capacidad que tiene el sistema para coexistir con otro software como la aplicación de Google Maps y todas sus funcionalidades. [un requerimiento funcionalidad].
- Modularidad: se plantea desde el inicio tres sistemas que funcionen en conjunto: Aplicación Móvil, Aplicación Back Office y Live Map; lo cual requiere de tres sistemas que resuelven el problema, pero cada uno de ellos con sus propias funciones y características, sin embargo trabajan en conjunto. [cambios hechos por el equipo de desarrollo].
8. Diagrama de subsistema
Ahora, se muestra un diagrama de estado, con base en el objeto Denuncia; con base en la lectura de los autores Bruegge y Dutoit (2002) y Ruiz (s.f.), donde menciona algunas propiedades alusivas a la información de diagramas de subsistemas, tales como clases, interfaces, entre otros. Se utiliza el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”. El diagrama se presenta en forma de imagen (Imagen 5).
Imagen 5.
Diagrama de subsistemas: “Oc2021”
Autor: propio
9. Importancia de las actividades de análisis y diseño y sus ventajas
En el área de desarrollo de sistemas, son varios campos los que trabajan en conjunto para que la entrega o desarrollo de un aplicativo sea exitoso. Concerniente al análisis y diseño de sistemas, abarca áreas fundamentales para el proceso de desarrollo de un sistema, donde en sus inicios se plantean acciones y tareas que se deben seguir para cumplir con las expectativas de calidad y seguridad del mismo. Por un lado, cuando se analiza el desarrollo de sistemas, se consideran actividades como la visualización de una o varias funcionalidades mediante el uso de casos de uso, diagramas donde se representan estas de forma visual y relativamente sencilla, documentación de requisitos de usuario, modelado del sistema a través de “software”, entre otras tareas que facilitan una planificación de la aplicación correcta.
Ahora, se mencionan una serie de beneficios de implementar el análisis y diseño correcto en el proceso de desarrollo de un sistema informático. Uno, posibilita el planteamiento eficiente del proyecto completo, es decir todo el ciclo de vidas se muestra claramente, y esto evita el acarreo de errores durante el proyecto. Dos, ciertamente se contesta a la pregunta de si el sistema esta realmente bien estructurado y va a ser comprensible para los usuarios finales. Tres, respecto al rendimiento, es verdad que el uso de técnicas de diseño y análisis, provee un rendimiento óptimo a largo plazo, independiente del sistema. Cuatro, clarifica desde el inicio las funcionalidades relevantes que se deben implementar en el aplicativo. Cinco, un sistema bien constituido, garantiza un sistema adaptable a requisitos durante el proceso de desarrollo, mismo que provee el análisis y diseño de sistemas (Summerville, 2011). Es claro, que estos y muchas otras son las ventajas que proporciona las diferentes herramientas y “software” relativos al diseño y análisis de sistemas, unos que se propusieron durante la presente indagación y puesta en práctica de ejercicios, y otros no; pero al final son un conjunto de actividades que confirma una consecución positiva del diseño de una aplicación programa informático.
Conclusiones
A continuación, se detallan las conclusiones más significativas propuestas en la presente investigación. En primer lugar, se logra alcanzar con éxito la compilación de información referente al campo de la programación dedicada al análisis y diseño de sistemas, donde se propone poner en práctica algunos ejemplos.
Además, exitosamente se obtienen con éxito la descripción del diseño de sistemas a través de la observación, la interacción, detalle de diagramas de estado, elementos del caso de uso, y especificación de algunas de las utilidades del proceso de diseño y análisis de programas tecnológicos.
Igualmente, es cierto que la adquisición de conocimiento sobre el tema en cuestión proporciona una mejora significativa al momento de poner la práctica sobre la teoría estudiada; en ocasiones es necesario implementar ejercicios, aunque sean ficticios, para el entendimiento real del uso correcto de un planteamiento de una proyección, y esta investigación no es la excepción. En fin, suma información realmente importante para futuros ingenieros donde se va a colocar en escenarios reales la teoría expuesta.
Por otra parte, claramente, es necesario tomar en cuenta varios factores que componen el planeamiento y diseño de un sistema informático, cada componente referente al tema expuesto e indagado, con el fin de conseguir resultados realmente eficientes.
Por último, es igual de importante aclarar que un elemento fundamental para el proceso de análisis y diseño de programas tecnológicos, que debe tener prioridad alta es el levantamiento de requisitos del programa que se va a desarrollar, un detalle y objetivos claros van a facilitar todo el proceso de diseño de aplicaciones y programas.
Referencias Bibliográficas
Bruegge, B. y Dutoit, A. (2002). Ingeniería de software orientado a objetos. Pearson
Educación. Recuperado de https://elibro-net.cidreb.uned.ac.cr/es/ereader/uned/74078?page=1
Campderrich Falgueras, B. (2013). Ingeniería del software. Editorial UOC. Recuperado de
https://elibro-net.cidreb.uned.ac.cr/es/ereader/uned/56294?page=1
Canal Big Learning. (s.f.). Descripción de Casos de Uso [Video]. YouTube. https://www.youtube.com/watch?v=0NxXtTMvMfE
GreenFacts. (2021). Gas de efecto invernadero. Recuperado de https://www.greenfacts.org/es/glosario/ghi/gas-efecto-invernadero.htm
Iberdrola. (2021). NEUTRALIDAD DEL CARBONO. Recuperado de https://www.iberdrola.com/sostenibilidad/que-es-carbono-neutralidad
IBM Corporation. (2018). Vision Document. Recuperado de https://www.ibm.com/docs/en/elm/6.0.6?topic=requirements-vision-document
Junta de Andalucía. (s.f.). Marco de Desarrollo de la Junta de Andalucía – Guía para la redacción de casos de uso. Recuperado de
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416
Larman, C. (2003). UML y Patrones – Una introducción al análisis y diseño orientado a objetos y al precio unificado. Recuperado de https://elibro-net.cidreb.uned.ac.cr/es/ereader/uned/45285?page=1
Ruiz, F. (s.f.). INGENIERÍA DEL SOFTWARE I – Tema 4 – Diseño de Software. [archivo PDF]. Recuperado de https://www.ctr.unican.es/asignaturas/is1/is1-t04-trans.pdf
Summerville, I. (2011). Ingeniería de Software. Recuperado de https://elibro-net.cidreb.uned.ac.cr/es/ereader/uned/37857?page=1
Universidad Estatal a Distancia. (2021). Instrumentos y Rubricas – Caso Práctico: “0c2021”. [archivo PDF]. Recuperado de https://aprende.uned.ac.cr/course/view.php?id=14396